15-12-2016 Deliverable DSA1.2: First report on the pilots ... · 15-12-2016 Deliverable DSA1.2:...

15-12-2016

DeliverableDSA1.2:FirstreportonthepilotsdeployedbySA1

Deliverable DSA1.2

Contractual Date: 31-07-2016 Actual Date: 15-12-2016 Grant Agreement No.: 653965 Work Package: SA1 Task Item: T2 Lead Partner: SURFnet Document Code: DSA1.2 Authors: P. van Dijk (SURFnet)

© GÉANT on behalf of the AARC project. The research leading to these results has received funding from the European Community’s Horizon2020 Programme under Grant Agreement No. 653965 (AARC).

Abstract

This document provides an overview of the pilots undertaken in Year 1 by AARC Service Activity 1. It summarises the overall pilot approach, outlines the technical platform and support infrastructure established, and gives a structured description of the pilots running within each Task, including the use case, requirements, components being used, results and plans for Year 2.

Deliverable DSA1.2 First report on the pilots deployed by SA1 Document Code: DSA1.2

ii

TableofContents

ExecutiveSummary 4

1 Introduction 51.1 PilotApproach 51.2 InthisDocument 6

2 Year1ResultsfromTask0–ActivityLeadership 82.1 FocusinTask0 82.2 ThePilotPlatform 82.3 AdditionalFeaturesandResources 92.4 PilotsStarted 10

3 Year1ResultsfromTask1GuestAccess 123.1 FocusinTask1 123.2 ResearchLibraryRequirements 123.3 PilotedLibrarySolutions 143.4 NewPilotsStartedinTask1 18

4 Year1ResultsfromTask2–AttributeManagement 204.1 FocusinTask2 204.2 AttributeManagementRequirements 204.3 OngoingPilotsinTask2 21

4.3.1 Pilot1–EGIe-Infrastructure 214.3.2 Pilot2–BBMRIERIC 224.3.3 Observations 23

5 Year1ResultsfromTask3–AccesstoResources 255.1 FocusinTask3 255.2 AccesstoNon-WebResourcesRequirements 255.3 OngoingPilotsinTask3 26

5.3.1 Pilot1–CILogon 265.3.2 Pilot2–LDAP-Facade 285.3.3 Pilot3–Unity-IdM 305.3.4 Pilot4–ORCID 30

Contents


iii

5.3.5 Observations 32

6 Conclusions 33

References 35

Glossary 37

TableofFigures

Figure1.1:ExamplesofAARCdeliverablesandmilestonesguidingpilotswithcommunities 6Figure2.1:Stillfromscreen-capturevideoonusingCOmanagetoprovideself-serviceaccesstoaLinuxserver 9Figure2.2:ScreenshotoftheAARCpilotGitLabstagingarea 10Figure3.1:Screenshotofthelibrarywalk-byusersadminportal 16Figure3.2:Screenshotofthedemolibraryserviceproviderportal 18Figure5.1:ScreenshotoftheRCauth.euwhite-labelCAserviceforEurope 28Figure5.2:ScreenshotoftheLDAP-Facadepilotservice 30Figure5.3:ScreenshotoftheORCIDSAMLconnection 32

TableofTables

Table3.1:Functionalrequirementsforlibrarypilots 14Table3.2:Task1,Pilot1–SAML/IPBridge 15Table3.3:Task1,Pilot2–Walk-byusers 16Table3.4:Task1,Pilot3–IdP/SPproxyforlibraryconsortia 17Table4.1:Functionalrequirementsforattributemanagementpilots 21Table4.2:Task2,Pilot1–AttributemanagementinthecontextoftheEGIcommunity 22Table4.3:Task2,Pilot2–AttributemanagementinthecontextofBBMRI-ERIC 23Table5.1:Functionalrequirementsforaccesstonon-webresources 26Table5.2:Task3,Pilot1–Accesstonon-webresources–CILogon 27Table5.3:Task3,Pilot2–Accesstonon-webresources–LDAP-Facade 29Table5.4:Task3,Pilot4–Accesstoresources–ORCID 31


4

Executive Summary

ThisdocumentprovidesanoverviewofthepilotsundertakeninYear1withinAARCServiceActivity1Pilots(SA1).

ThefirstcycleofpilotshastakenasinputtheresultsfromkeydeliverablesandmilestonesproducedbyotherActivities, includingtheuserandserviceproviderrequirementsandAARCblueprintarchitecture(fromJointResearch Activity 1 Architectures (JRA1)) and the preliminary results from Networking Activity 3 PolicyHarmonisation(NA3).

AfterthefirstyearofAARC,morethaneightpilotsarerunning.TheworkhasbeenorganisedaccordingtothethematicTasksinSA1:

• Task0–WorkPackageLeadership.• Task1–GuestAccess.• Task2–AttributeManagement.• Task3–AccesstoResources.

Someofthepilots,suchasSAML/IPBridge,Walk-byUsersandIdP/SPProxyforLibraryConsortiawithinTask1, are close to finalisation, and one, CILogon, within Task 3, has already been handed over to NA3 forsustainabilityandoperationalmodelstobedevelopedfortheservice.

Basedonthepilots,SA1hasidentifiedinterestingideasforsolutions,andalsoanumberofchallenges.Plansare inplace toextendandbuildon thepilots inYear2, including jointTaskworkon solutions forbridgingtowardssocialande-governmentalidentities,andfurthertokentranslationandORCIDsolutions.

ThedeliverableprovidesageneraloverviewoftheSA1Year1pilots.EachsectioncoversoneTaskandfollowsasimilarstructure,providingabriefdescriptionoftheusecase,thecomponentsbeingused,andpilotresults.Amorein-depthdescriptionoftheAARCpilotsisavailableintheAARCpublicWiki[AARCWiki].


5

1 Introduction

Service Activity 1 Pilots (SA1) aims to facilitate research by providing access management tools and aframework to support collaboration in a distributed environment. To this end, the Activity demonstratesthrough(pre-)productionpilotsthat:

• Existing authentication and authorisation infrastructures (AAIs) and authentication sources can beleveragedtoenable(singlesign-on(SSO))access,withappropriatelevelofassurance,foranynaturalperson(bothwithinandoutsideacademia),tosharedresourcesofferedbydifferente-infrastructureprovidersandcommunities.

• Authoritative decisions and user/group context can be based on distributed group managers andattributeproviders.

• Access to non-web and commercial services can be enabled. This requires the bridging of securityassertion markup language (SAML)-based infrastructures (the national research and educationnetwork (NREN) world) and token/certificate-based services as commonly delivered by e-infrastructureproviders.

1.1 Pilot Approach

TheAARCpilotsaredrivenbytwomainusecases:

• Research communities that require access to services offered by different research or e-infrastructuresandwishtousetheirexistingcredentials.

• Researchand/ore-infrastructuresthatwanttobuildanAAIandarelookingforrecommendationsandbestpracticestodothatinthemosteffectiveandinteroperableway.

TheapproachfollowedbytheAARCpilotsistodeployexistingtechnicalcomponentsasidentifiedwithinJointResearchActivity1Architectures(JRA1),andtointegrateaselectionofthesecomponentsinlinewiththeusecases and according to a common blueprint architecture proposed by AARC. As part of the pilots, policyaspectselaboratedinNetworkingActivity3PolicyHarmonisation(NA3)arealsotested.

Tothispurpose,SA1establishedastablepilotenvironmentwithsolutionstobeassessedbythestakeholders(e.g. research library communities, ELIXIR, BBMRI and EGI) of research communities. A more detaileddescriptionoftheaimsandapproachofthepilotactivityisavailableinMilestoneMSA1.1:SpecifytheworktobeundertakenincollaborationwithJRA1andNA3[MSA1.1].

As soon as the research community requirements became available (August 2015) and as soon as otherdocuments concerning the blueprint architecture and the policy harmonisation work were produced, the

Introduction


6

AARCpilotteamstartedtoscopethepilotsandtodefinetheplatformtoexecutethem.Themostinfluentialdocumentsforthepilotsarelistedbelow:

• MilestoneMSA1.1:SpecifytheworktobeundertakenincollaborationwithJRA1andNA3[MSA1.1].• DeliverableDJRA1.1:Analysisofusercommunityandserviceproviderrequirements[DJRA1.1].• MilestoneMJRA1.1:ExistingAAIandavailabletechnologiesforfederatedaccess[MJRA1.1].• MilestoneMJRA1.2:DesignforDeployingSolutionsfor“GuestIdentities”[MJRA1.2].• MilestoneMJRA1.3:DesignfortheintegrationofanAttributeManagementTool[MJRA1.3].

• MilestoneMJRA1.4:FirstDraftoftheBlueprintArchitecture[MJRA1.4].

Figure1.1:ExamplesofAARCdeliverablesandmilestonesguidingpilotswithcommunities

Withthefeedbackfrommembersofthecommunity,lessonslearnedandthecreationofmanuals,SA1closesapilotcycleandhandsover theresultsof successfulpilots to NA3toworkonsustainabilityaspects [NA3-WIKI-SOM]. NA3 has a Task dedicated to providing recommendations for adoption by operationalinfrastructures,andguidanceastowhichmodelisapplicablegiventheoperatingmodelofacommunity.Itsfindings are being documented inDeliverable DNA3.3: Recommendation for service operationalmodels forenablingcross-domainsustainableservices,dueinM21.Withthoserecommendationsathand,theNA3andtheSA1teamswillprovidesuggestionsforoperationalmodelsforthepilotedsolutions.

1.2 In this Document

ThisdocumentprovidesanoverviewofthepilotsundertakenbySA1inYear1.ItisstructuredbyTask,ineachcase(exceptTask0ActivityLeadership)covering:

• Usecasefocusedon.• Requirementstobemet.• Foreachpilot,atablesummarisingand/orprovidinglinksto:

○ Focus.○ Approach/AARCidentifiedsolution.○ Componentspiloted.

RequirementsUserCommunity

OverviewAvailableAAIComponents

(Draft)BlueprintArchitecture

TestingWith

Communities

PlanningPilots

DeployingTools

Inputfor

Training

Creationof

Manuals

Feedbackby Community

RunningPilotsWithCommunities

Introduction


7

○ Gainforendusers/administrators.○ Demo/video.○ Detailedtechnicaldescription.○ Documentationofcomponents.○ Softwaresources.○ Lead.○ Communitypartners.○ Status.

• Observations.

ThedocumentendswithabriefConclusionssection,summarisingandevaluatingtheprogressmadetodate.

Amorein-depthdescriptionoftheAARCpilotsisavailableintheAARCpublicwiki[AARCWiki].


8

2 Year 1 Results from Task 0 – Activity Leadership

2.1 Focus in Task 0

Tofullysupportallpilotactivitiesandtoprovideajumpstartforeachpilotsub-task,SA1hascreatedapilotplatform.Thisplatformisastagingareaandcanbeusedtotestanddeployservicesandtopilotserviceswiththe communities. It is not considered as a production facility.Nevertheless, ample attention has still beenpaidtooperationalaspects,includingsecurity,updatesanddeployabilityofsoftwarecomponents.

2.2 The Pilot Platform

Atechnicalplatformhasbeendeliveredby~okeanos[~okeanos],theGRNETInfrastructureasaService(IaaS)platform.ForAARC,30virtualmachines(VMs)areavailablewithappropriatespecificationstorunthepilots.Theplatformhasbeendesigned in linewithAARC’sblueprintarchitecture[MJRA1.4]. Itcombinestheopensource software OpenConext [OpenConext] and the collaboration management platform COmanage[COmanage]toleverageaserviceprovider(SP)proxyscenariothatcanserveAARCitself.COmanageisusedtocentrallymanagespecificvirtualorganisation(VO)groupsandattributes, includingsecureshell(SSH)andvirtualprivatenetwork(VPN)provisioning;OpenConexttakescareoftheSPproxy.AttributeaggregationfromCOmanage and other sources (e.g. ORCID [ORCID]) and OpenConext authorisation are used to testauthorisationscenariosonbehalfoftheservicesoftheVO.Thisapproachhasbeendemonstratedatseveraloccasions e.g. inmeetingswith research community representatives. The team delivered a screen-capturevideo[PilotPlatformVideo]anddocumentationfortheOpenConextandCOmanagecomponentsbeingused.

Year 1 Results from Task 0 – Activity Leadership


9

Figure2.1:Stillfromscreen-capturevideoonusingCOmanagetoprovideself-serviceaccesstoaLinuxserver

Oneyearon fromthestartof theAARCproject,27outof the30VMsare inuse for11differentpilots.Toensure secure access to these VMs, the pilot platform was equipped with ZeroTier VPN [ZeroTier]. OnlyregisteredclientswillobtainaccesstothevirtualpilotLAN.

2.3 Additional Features and Resources

A top-level domain has been created for the pilot projects: *.pilots.aarc-project.eu, to ensure that thetargetedAARCcommunitiescaneasilyfindandaccessAARCpilotsetupsanddemonstrators.

Tofacilitateanytestingbycommunities,aSimpleSAMLphpDIYtestidentityproviderhasbeenincludedinthisenvironment.Thisidentityproviderisnamed“DIYIdP”andisavailableasatestIdPforAARCpilotprojects.ItallowsthetestingofvariousloginandattributescenariosthatarecommonwhendealingwithSAMLidentityproviders.

Code,configurationdata,resultsanddocumentationforthepilotprojectscanbestoredinthecentralAARCpilot Git repository [AARCGit]. For more sensitive data, such as specific configuration data, keys andcertificates,aprivateGitLabrepositoryisavailable[AARCPrivate].

First-linesupportforusingthepilotinfrastructure,e.g.tojointheZeroTiernetwork,isprovidedbySURFnetstaff.FurtherdetailsonthepilotinfrastructureareavailableintheAARCpublicWiki[AARCWiki].



10

Figure2.2:ScreenshotoftheAARCpilotGitLabstagingarea

2.4 Pilots Started

Basedon information from thedeliverables andmilestones from theAARCArchitectures (JRA1) andPolicyHarmonisation(NA3)Activities,SA1commencedthefirstcycleofpilotsasfollows:

• InTask 1GuestAccess, apilothas started that involves libraries in the identificationandhands-onimplementationofrelevantsolutionstosupporttheirmigrationfromIPaddress-basedauthenticationagainst publishers’ online resources to a SAML-/federated-based approach. This work focuses onembracing:

1. Allpossibleuserswhoneedaccesstolibraryresources,includingso-calledwalk-byusers,whomaybecitizenscientists.

2. All relevant service providers, including those who only support IP-address based accesscontrol.

Theaimofthispilotistoshowthatitispossibletoapplytheprincipleofinclusivenessandatthesamehidecomplexityforusersandlibrarians.

• In Task 2 Attribute Management, a pilot has started that tests the use of SAML-based attributeauthorities to provide authoritative information to be consumed by cloud services offered by e-infrastructures and other providers (e.g. at EGI). Attribute authority components tested so far arePerun[Perun]andCOmanage[COmanage].AttributeaggregationcomponentsusedareOpenConext[OpenConext]andSimpleSAMLphp [SimpleSAMLphp]. Ina laterphase theTaskaims toaddressandpilotscenarioswhereattributesfrommultipleattributeauthorities(andprobablymultipleVOs)flow



11

into services; for example, a cloud provider that serves several virtual organisations, managed bydifferentvirtualorganisationmanagerentities.

• In Task 3 Access to Resources, token translation services have been established and piloted. TwopilotsarerunningaspartofthisTask:

1. Onepilot focuses on developing a CILogon pilot service for Europe [CILogon] based on thecomponentsdevelopedbytheCILogonserviceintheUS.Severalextensionshavebeenaddedtothecodeandacertificationauthority(andtherelevantpolicies)havealsobeencreatedaspart of the pilot. The CILogon pilot works as a token translation service to bridge the gapbetweenSAML-basedauthentication(NRENs)andcertificate-basedauthentication(e-scienceande-infrastructureproviders).

2. A second pilot, on access to resources, assesses the feasibility of enabling non-web singlesign-onbasedonLDAP-Facade [LDAPFacade],a tooldevelopedby theKarlsruhe InstituteofTechnology(KIT),whichisparticipatinginAARC.

Apilottotestathirdsolution,Unity-IdM[Unity-IdM],isinpreparation.

A fourth pilot, using ORCID [ORCID] to showcase federated access to third-party services, is alsounderway.

A general overviewof theAARCpilots is given in the following sections. Each section coversoneTask andfollowsasimilarstructure,providingabriefdescriptionoftheusecase,thecomponentsbeingused,andpilotresults.Amorein-depthdescriptionoftheAARCpilotsisavailableintheAARCpublicWiki[AARCWiki].


12

3 Year 1 Results from Task 1 Guest Access

3.1 Focus in Task 1

ThisTaskdealswiththepilotworktobesetupforAARCinthedomainofguestidentities.ItliaiseswiththeAARCArchitectures(JRA1)andPolicyHarmonisation(NA3)Activities inordertoeffectivelydemonstratethevalidityofthecomponentsselectedandarchitecturedesigned,andthebestpracticesandrecommendationsidentified.

TheTaskconsistsofseveralsub-taskswithdifferentfocusareas:

• Long Tail of Science – This work area deals with bridging the NREN world towards social andgovernmentalIDs,usinglevelofassurance(LoA)-enhancingmechanismstoenablethemtomakeuseoffederatedservices(SPs).

• Catch-allFederationandGuestIdP/CloudIdP–ThisworkareadealswiththeenrolmentofnewIDsina federated model, creating a catch-all federation for IdPs without a reference federation, andprovidinganewIdPthroughthecloud.

• Libraries–Thisworkareadealswithpilotingsolutionsto lowerthethresholdfor inclusionof librarytools,includingthosehandlingaccessbasedonIPaddresses,andaworkflowintoafederatedmodelfor identitymanagement,with support for librarywalk-byusers (e.g. citizen scientists)whoarenotregisteredinthecampusidentitymanagementsystems.

Duringthefirst12monthsoftheAARCprojectthemainfocusoftheSA1Task1teamhasbeenonpilotsforlibraryusecases.Theresultspresented inthissectionthereforemainlyconcernpilotsolutions for libraries.Anotherdeliverable,DSA1.1Pilots to support guest users solutions, that is due tobe released at the sametimeasthisone,providesamoreextensiveandin-depthdescriptionoftheresultsachievedinSA1Task1sofar.

3.2 Research Library Requirements

OneofthegoalsofAARCistoimproveaccesstodigitalresourcesofferedbylibraries.Thisworktakesplaceincollaboration with AARC partners Ligue des Bibliothèques Européennes de Recherche – Association ofEuropean Research Libraries (LIBER), the Moravian Library (MZK) and several other national bodiesrepresenting research libraries in Greece, Italy and The Netherlands. Several pilots have been started toaddresstheneedsandproblemsfacedbylibrariesandlibraryconsortia.

TheTaskidentifiedthreedifferentbutrelatedissuesthathampertheadoptionoffederatedaccessandaccesscontrolintheworldofresearchlibraries:

Year 1 Results from Task 1 Guest Access


13

• First, to date, many library resources, such as journals and tools, are not accessible with aninstitutionalaccount.Torestrictaccesstosuchresources,librariesstillrelyonIPaddress-basedaccesscontrol.Althoughthismethodofaccesscontrolisinuseatmanylibrariesworldwide,libraryICTstaffmembers need to maintain the correct IP address ranges and regard this approach as too labourintensiveandinaccurate.

• Second, many librarians are broadening access to their own and remote resources to the generalpublic, inlinewiththeiraimtoshareknowledgewithawidecommunity.Thisincludes,forexample,citizenscientistswhoarenotaffiliatedwithaninstitutionandlackaverified institutionalaccounttoobtain access to restricted library sources. Up until now, most libraries offer access for any uservisiting the library. This type of user is called a “walk-by user”. For access to content based on IPaddressranges,thisisnotaproblem,butassoonasfederatedaccess-basedsolutionsareintroducedas a replacement for IP address-based access, non-academic users are no longer able to accessrestrictedresources.Therefore,forproviderssupportingSAML-basedaccessonly,asolutiontoservewalk-byusersisneeded.

• Athirdobservationthatemergedwasthat insomecountries librariesmaintainamesh-basedSAMLfederationparallel tonational identity federations.Thisapproach introducesa lotofcomplexity, forexampleintermsofthenumberofinteractionsbetweenIdPsandSPsthatneedtobemaintained.Byintroducingaproxycomponent, librariansandlibraryconsortiacandrasticallyreducethenumberofend-point interactions.Atthesametime,toolsandfacilitiesbecomeavailabletobrandandarrangetheauthenticationflowinaconsistentandtrustworthyway.

Asaresultoftheabove-mentionedissues,usersarecurrentlyconfrontedwithinconsistentandconfusing(“ifthisthenthat”)userinterfacesdependingonwhotheyare(academic/non-academic),theresourcetheywanttoaccessandthelocationatwhichtheyreside(athomeoroncampus).

The Task translated these issues into requirements, which have been described in detail in DeliverableDJRA1.1:Analysisofusercommunityandserviceproviderrequirements[DJRA1.1].Thatdocumentprovidesadedicateddescriptionofthe issuesresearchcommunities(including librarians)currentlyfacewithregardtofederated identitymanagement. Requirements R1, R2, R7 and R_P_6, summarised in Table 3.1 below, areapplicableto librariesandhavebeenguidingthework inthispilot. (“R”denotesarchitecturalandtechnicalrequirements;“R_P”denotespolicyandbestpracticerequirements.)

ID Title Description

R1 Userfriendliness The Federated AAI framework should provide simple and intuitivetoolsthatareabletoaddresstheneedsofuserswithdifferentlevelsofICTliteracy

R2 Homelessusers The Federated AAI framework should support users without afederated institutional IdP, suchas citizen scientists and researcherswithoutformalassociationtoresearchlaboratoriesoruniversities

R7 Federation solutions basedon open and standards-basedtechnologies

Open and standards-based AAI technologies should be used by thedifferent communities to allow for interoperability by means ofsuitabletranslationservices



14


R_P_6 Simplified process forjoiningidentityfederations

The bureaucracy involved in joining identity federations should bereduced

Table3.1:Functionalrequirementsforlibrarypilots

3.3 Piloted Library Solutions

Threelibrarysolutionshavebeenpiloted:

• SAML/IPbridge.• Walk-byusers.• IdP/SPproxyforlibraryconsortia.

Eachoftheseisdescribedbelow.

3.3.1.1 Pilot 1 – SAML/IP Bridge

Task1establishedapilotproxytobeusedbylibrariestogiveaccesstorestrictedcontentnomatterwhetherthe(content)providersupportsSAMLornot.ThisapproachisnotnewandinfactanexistingsolutioncalledEZproxy[EZproxy]offersfunctionalitytobridgeSAMLtoIP.EZproxyisacomprehensiveproductprovidedbytheOnlineComputerLibraryCentre(OCLC)[OCLC],afullyfledgedrewritingproxycapableofmanagingbothSAML- and IP-based authentication for users against online SPs. It also foresees the option to provide theproductinahostedfashion,ifneeded.Itallowstheproxyadministratorstoconfigureresourcesthatneedtobeaccessedinafederatedfashion–providedauserisauthenticatedonalocalIdP–andthosethatwillbeaccessed inan IP-proxy fashion,basedonthesource IPof theEZproxy tool itself.Asummary,with links tomoredetails,isgiveninTable3.2below.

Task1,Pilot1 SAML/IPBridge

Focus Support access to federated and non-federated library resources – bridgingSAML-andIPaddress-basedaccessmethods(SAMLtoSAML+SAMLtoIP)

Approach/AARCidentifiedsolution

Establish a proxy to bridge SAML and IP address access methods, a so-calledaccessmodeswitch

Componentspiloted EZproxyforSAML-IPbridge

Gainforendusers/administrators

• Same entry point for users regardless of the type of authenticationtechnologyrequiredbytheserviceprovider

• Abetteruserexperience• An easy way for technical administrators at the libraries to introduce

federatedaccesswithoutdisruptingaccesstoservicesthatonlysupportIP-basedauthentication



15

Task1,Pilot1 SAML/IPBridge

Demo/video • Demo• Flow• Video

Detailedtechnicaldescription

AARCWiki

Documentationofcomponents

DocumentationforEZproxyaccessmodeswitch

Softwaresource(s) EZproxy

Lead GARR

Communitypartners IT:GARR,LibraryNL:UKBlibraryconsortium

Status Closetofinalisation.Awaitingfinalphaseoffeedbackfromcommunities.

Table3.2:Task1,Pilot1–SAML/IPBridge

3.3.1.2 Pilot 2 – Walk-by Users

Toaddresstheneedtomaintainthecurrentpracticeofopeningupresourcestoanyonewhoneedsscientificinformation, includingcitizenscientistsnotaffiliatedwithan institution (“walk-byusers”), theTaskaddedacomponent that is able to handle access requests fromwalk-by users (e.g. citizen scientists). The IP-basedauthenticationpluginofShibbolethIdPv3[Shibboleth]canbeusedtoauthenticatelocalwalk-byusersbasedontheIPaddressoftheterminalusedatthelibrary.Theuserchoosesthelibrarywalk-byShibbolethIdPand,incasetheterminalresideswithinavalidIPaddressrange,theIdPprovidesanattributewiththeentitlement“walk-by user”. Based on this attribute, a service provider can authorise the user to access restrictedresources.MoredetailsaboutthispilotareavailableinTable3.3below.

Task1,Pilot2 Walk-byUsers

Focus Supportauthorisedaccessforcitizenscientiststolibraryresources(SAML+IPtoSAMLwithAuthZ)


Establish a guest SAML IdP that adds attributes to authorise non-institutionalusers.Inaddition,exploreexploitationmodels:perlibraryorpernationallibraryconsortiumdeployment.

Componentspiloted Shibbolethv3forIdPwithIP-basedAuthZattribute


• Moreconsistentinterfacenomatterwhichresourceisbeingapproached• Abilitytousethisaccessmethodandatthesametimemaintainfullprivacy• Admininterfaceforlibrarianstoscope/configurevalidIPranges

Demo/video • Flow• Demoadminportal



16

Task1,Pilot2 Walk-byUsers

• Demouserportal


AARCWiki


Documentationforwalk-byuseraccesscomponent,accesscontrolWiki

Softwaresource(s) Shibbolethv3forwalk-byuseraccess

Lead GARR/DAASI

Communitypartners IT:GARR,LibraryNL:UKBlibraryconsortium

Status Closetofinalisation.Awaitingfinalphaseoffeedbackfromcommunities.

Table3.3:Task1,Pilot2–Walk-byusers

Figure3.1:Screenshotofthelibrarywalk-byusersadminportal

3.3.1.3 Pilot 3 – IdP/SP Proxy for Library Consortia

Toaddressthemany-to-manySAMLinteractionstopicthatsomelibraryconsortiaaredealingwith,theTaskpilotedthesuitabilityofanIdP/SPproxysolution.MoredetaileddescriptionsandlinksaregiveninTable3.4below.



17

Task1,Pilot3 IdP/SPProxyforLibraryConsortia

Focus Showcase amodel for library consortia to reduce the number of interactionsbetweenIdPsandSPsfromatechnicalandtrustpointofviewwhilepreservingtheprivacyofusers


EstablishaproxyasasinglepointforinteractionbetweenIdPsandSPs,brandedasaHEAL-Linkinitiative

Componentspiloted SimpleSAMLphpasIdP/SPproxy


• Moreconsistentinterfacenomatterwhichresourceisbeingapproached• Betterservicetoendusers,standardisedaccessmethod• Lessefforttomaintainandadministeraccessforlibraryadministrators• Allowspublishercontractstobemanagedcentrallybytheconsortium• EasiertoimplementandmanagetrustrelationshipsamongIdPsandSPs• Libraryconsortiumwillretaincontrolonbrandingandpolicies• Morepreciseandeasiertoproducestatistics

Demo/video • Flow• Demo


AARCWiki


DocumentationfortheHEAL-Linkproxy

Softwaresource(s) SimpleSAMLphpfortheIdP/SPproxyMemcachedShibboleth

Lead GARR/GRNET

Communitypartners GR:HEAL-LinkconsortiumGR:AristotleUniversityofThessaloniki(identityprovider)US:WileyOnlineLibrary(serviceprovider)

Status The IdP/SPproxyhas joinedtheGRNETfederationandthe loginworkflowhasbeen tested using the production IdP of one of the participating academicorganisations, namely the Aristotle University of Thessaloniki. Theinterconnection of the proxy with the (pre-production) SP of Wiley OnlineLibrary(partnerswithHEAL-Link)isclosetofinalisation.

Table3.4:Task1,Pilot3–IdP/SPproxyforlibraryconsortia



18

Figure3.2:Screenshotofthedemolibraryserviceproviderportal

3.3.1.4 Observations

Overall,with theapproachesandsolutionsprovidedabove,usersof library resourceswillhavea smootherexperience while accessing resources, irrespective of the authenticationmethod that is supported. At thesametime,thesesolutionsofferopportunitiestoreducetheadministrativeburdenoflibrarystaffinrelationtomanagingSAMLconnectionsandmaintainingaccesstorestrictedlibraryresources.

3.4 New Pilots Started in Task 1

Atthetimeofwriting,severalpilots inthecategory“guestaccess”havebeenstartedandarestillongoing.Theseinclude:

• Pilotingsolutionsforbridgingtowardssocialande-governmentalidentities.Thesocialidentitiespilotisbeingcarriedout incollaborationwithTask2. Itsgoalsaretodemonstratetheactual inclusionofguest identities(e.g.Google ID,FacebookID,etc.) intheprovisioningandconsumptionof federatedservices and to provide pragmatic suggestions for vetting the identity of users authenticating withsocial IDs.SuchasetupcanbeachievedbyestablishinganIdP/SPproxybridgingOAuth2[OAuth2]/OIDC [OIDC] and SAML, an attribute authority (based on the COmanage component), providingadditionalattributestotheID.

• Inparallel,asecondsocialIDpilothasstarted.Inthispilotthefocusisonestablishingatransparentexternalidentityproxy(TEIP)basedontheworkoftheGN4-1SA5VirtualOrganisationPlatformasaService (VOPaaS) project [VOPaaS]. With this pilot the Task hopes to show that the VOPaaS TEIPapproach provides useful possibilities for handling social IDs in a generic and consistent way. Forexample, it features functionalitiesto feed inmanydifferent IDs (eduID,Feide.id,Google ID,etc.), itassesses and applies level of assurance (LoA) according to the eIDAS EU Regulation [eIDAS] and itprovidesasingleuniqueidentifier.

• Some first steps have been taken to pilot with e-governmental IDs as well. For cross-borderauthentication using eIDs, the eIDAS EU regulation is being followed. eIDAS developed the “eIDASInteroperability Framework”, which foresees an infrastructure based on national gateways



19

implemented at the EUmember states. The eIDAS framework is intended to provide a means formemberstatestorecogniseeachother’seIDstoaccesspublicservices.AARC isworkingwitheIDAS representatives inorder toestablishapilotactivity thatwill assess theinteroperabilityof thetechnical implementationsandpolicy frameworkandthatwill investigate theuseofeIDASasoneofthepotentialsolutionsforguestidentitiesandforstep-upauthentication.


20

4 Year 1 Results from Task 2 – Attribute Management

4.1 Focus in Task 2

This Task deals with the deployment of pilots to establish an attribute management framework forcollaborative single sign-on (SSO) scenarios. Based on the tools, methodology and blueprint architectureidentifiedbyJRA1,theTaskstartedtopilotandtestanumberofsolutionsthatfacilitateandenable:

• Attributemanagement. Toolsandservices thatbetter support the registrationandmanagementofattributesbytheresearchcommunities.Basedontherequirements,asdefinedinJRA1,at leasttwotools are being selected for a pilot. The tools support standard interfaces to be used by usercommunitiesande-infrastructureserviceproviders.

• Attribute aggregation.Multiple scenarios for attribute aggregation are expected to result from theattributeframeworkdefinition.Thisworkitemaimstovalidateatleasttwobasicmodels,ahubmodelandameshmodel.Fromaprotocolperspective,thesameopenstandardscanbeusedtoengageinattributedistribution.Thisworkitemisinvestigatingfeasibility,securityandprivacyimplicationsofatleasttwoprotocols.

• Attribute-basedauthorisation.Serviceproviderswillbaseauthorisationonacombinationofidentityprovider(IdP)andcommunity-providedattributes.ThisworkitemvalidatestheinvestigationsdoneinJRA1 with at least two real service providers as they exist in participating R&E communities. IncollaborationwithNA3,levelofassurance(LoA)requirementswithregardtoauthorisationattributesarebeingconsideredandtested.

4.2 Attribute Management Requirements

Based on questionnaire responses and interviews with representatives of research communities and e-infrastructureproviders, theTask identified several key requirements regardingattributemanagement thatneed to bemet. The requirements have been described in detail inDeliverable DJRA1.1: Analysis of user-communityandserviceproviderrequirements[DJRA1.1],andaresummarisedinTable4.1below.(“R”denotesarchitecturalandtechnicalrequirements;“R_P”denotespolicyandbestpracticerequirements.)


R1 Userfriendliness The Federated AAI framework should provide simple and intuitivetoolsthatareabletoaddresstheneedsofuserswithdifferentlevelsofICTliteracy

R3 DifferentLevelsofAssurance Credentials issued under different policies and procedures should

Year 1 Results from Task 2 – Attribute Management


21


includetheprovenanceofthelevelunderwhichtheywereissued

R5 Flexibleandscalableattributereleasepolicies

Flexiblenegotiationmechanismsarerequiredtogovernthereleaseofidentityattributes

R7 Federationsolutionsbasedonopenandstandards-basedtechnologies

Openand standards-basedAAI technologies shouldbeusedby thedifferent communities to allow for interoperability by means ofsuitabletranslationservices

R8 Persistentuseridentifiers TheFederatedAAIframeworkshouldreferencethedigitalidentitiesofusersthroughlong-lastingidentifiers

R9 Uniqueuseridentities Each user should have a single digital identity to allow SPs touniquelyidentifytheirusers

R_P_3 Sufficientattributerelease ThesetofattributesreleasedtoSPsshouldbeextended,primarily,toallowconsumingservicestooperateand,also,toallowformoreadvancedfeatures,suchaspersonalisationofservices

Table4.1:Functionalrequirementsforattributemanagementpilots

4.3 Ongoing Pilots in Task 2

Currently,twoattributemanagementpilotsarerunning,totestcomponentsinthecontextof:

• EGIe-infrastructure.• BBMRI-ERIC.

Eachoftheseisdescribedbelow.

4.3.1 Pilot 1 – EGI e-Infrastructure

ThefirstpilotistotestcomponentsforattributemanagementinthecontextoftheEGIe-infrastructureanditscommunity.

Principlesappliedinthiscontextare:

• Access to the various services should be grantedbasedon the virtual organisation (VO) roles usershave.

• Rolesshouldbeexpressedinattributes.• Back-endservicesshouldnothavetodealwiththecomplexityofmultipleIdPs/federations/attribute

authorities/technologies.Therefore,anattributeaggregationscenarioispreferred.



22

Table4.2belowprovidesfurtherinformationandlinkstodetailedresourcesonthispilot.

Task2,Pilot1 AttributeManagementintheContextoftheEGICommunity

Focus InvestigateandpilottheusabilityofSAML-basedAAIcomponentstouseexternallymanagedattributestoprovideandrestrictaccesstocloudservices


EstablishanAAIinfrastructureofIdPsandexternalattributeauthorities;aggregateattributesfromthesesourcestofeedthemtocloudserviceproviders

Componentspiloted PerunAAandSimpleSAMLphpasattributeaggregatorcomponent.AtalaterstagethecomponentsOpenConext,COmanageandCILogonwillbeadded to thispilotsetup


• Consistentaccessprocedureswhenaccessing(shared)cloudservices• Abilitytocontrolaccesstosharedresourcesonaresearchcommunitylevel• Abilitytoexternaliseanddelegatethemanagementofattributestodifferent

partnersandsources• Ability tomix,matchandusedifferent resources sideby side (IdPs,AAsand

SPs)• AbilitytoutiliselevelofassuranceprovidedbyIdPs

Demo/video Notavailableyet


AARCWiki


PerunSimpleSAMLphpIntegrationofbothcomponentsintheEGIinfrastructureisexpectedsoon

Softwaresource(s) PerunSimpleSAMLphp

Lead EGI

Communitypartners EGI

Status DeploymentoftheEGIattributemanagementframeworkisinprogress.Attributeauthorities have been set up (Perun,GOCDB) and SimpleSAMLphp is in place tomanage aggregation. COmanage will be added as a 3rd attribute source andOpenConext will be deployed to handle attribute aggregation. In addition, theCILogonsetupdescribedinSection5.3.1isinplaceandwillbeusedinthiscontextaswell.

Table4.2:Task2,Pilot1–AttributemanagementinthecontextoftheEGIcommunity

4.3.2 Pilot 2 – BBMRI ERIC

InthesecondpilottheTaskhasstartedtotestcomponentsforattributemanagementinthecontextofthebiomedical Biobanking and BioMolecular resources Research Infrastructure – European Research



23

InfrastructureConsortium(BBMRI-ERIC).HeretheaimistoestablishafullyfledgedstandardisedAAIfortheBBMRI-ERICcommunitytoenableaccessandauthorisationtosharedbiomedicalresourceswithappropriatelevel(s)ofassurance.LinksandfurtherdescriptionsaregiveninTable4.3below.

Task2,Pilot2 AttributeManagementintheContextoftheBBMRI-ERIC

Focus Establish a fully fledged standardised AAI for the BBMRI-ERIC community toenable access and authorisation to shared biomedical resources withappropriatelevel(s)ofassurance


Basedonexistinginfrastructures(eduGAIN,NRENfederations)andcomponentsanentireAAIarchitecturewillbepiloted

Componentspiloted PerunTEIPcomponents


• Consistent access and authorisation flows when accessing (shared)biomedicalresources

• AsinglestandardisedAAIwithsufficientlevelsofassuranceandwaystoon-boardallrelevantmembersofthecommunities

Demo/video Notavailableyet


Notavailableyet


Inprogress

Softwaresource(s) Inprogress

Lead CESNET/BBMRI-ERIC

Communitypartners BBMRI-ERIC

Status A pilot infrastructure has been established, Perun has been deployed(https://perun.bbmri-eric.eu) and registration processes have been defined.Selected applications from the BBMRI-ERIC community are in process of on-boardingtothepilotedAAI.Preparationsarecurrentlyunderwaytopilotwithauthenticationandauthorisationlevelofassuranceandpersistentidentificationapproachesacrosse-infrastructures.

Table4.3:Task2,Pilot2–AttributemanagementinthecontextofBBMRI-ERIC

4.3.3 Observations

InbothpilotstheIdP/SPproxyapproachhasbeenadoptedtohandleallcomplexity.TheTaskrecognisesthatthetwopilotssharemanyrequirementsandcomponents.Theteamsshareideasandinteractoftentomakesurethatacommonandgenericapproachresultsfromtheirworkandthatduplicationofeffortisprevented.



24

In the second year of AARC thework of these pilotswill be extended by adding components from Task 1(guest access), e.g. to enable access for users with a social or e-governmental ID, and Task 3, to includesolutionsfornon-web-basedaccess,e.g.secureshell(SSH)andX.509access.


25

5 Year 1 Results from Task 3 – Access to Resources

5.1 Focus in Task 3

ThisTaskaimstoimproveaccesstorelevantnon-webresourceslocatedoutsidethehomeorganisationoftheuser.ThemainimprovementistomakeuseofexistingAAIsthatprovideverifiedinstitutionalusercredentialsand (external) authorisation attributes instead of local user management. While many successfulimplementationsexistalreadyforwebportals,thetechnologyfornon-webscenarios(e.g.secureshell(SSH)orX.509access)isstill immature.Asaresult,theuseofinstitutionalcredentialsforresearchinfrastructuresandresearchservicesisstilllacking.ThefocusofthisTaskisthereforeonsuitableapproachesandservicesfortokentranslationtobridgebothworlds.

AnotherfocusinTask3isthatofaccessto(commercial)third-partyservices.Section5.3.4belowsummarisestheworkthathasbeendonesofar.

5.2 Access to Non-Web Resources Requirements

The requirements relevant to accessing non-web resources are described in detail inDeliverable DJRA1.1:Analysisofusercommunityandserviceproviderrequirements[DJRA1.1]andsummarisedinTable5.1below.(“R”denotesarchitecturalandtechnicalrequirements.)


R1 Userfriendliness The Federated AAI framework should provide simple and intuitivetoolsthatareabletoaddresstheneedsofuserswithdifferentlevelsofICTliteracy.Thereshouldbenoneedtoinstalladditionalsoftwareontheuserside.Thereshouldbenoneedtomaintainlocalaccountsoneachresourcemanually.

R4 Community-basedauthorisation

TheFederatedAAIframeworkshouldenablecommunitiestomanagethe assignment of attributes to their members for authorisationpurposes

R11 Up-to-dateidentityinformation

The up-to-dateness of identity attributes should be guaranteedthroughanon-demandand/orrecurringverificationprocess

R12 Usergroupsandroles The Federated AAI framework should support the assignment ofgroupstousers,aswellastheassignmentofrolestouserswithintheirgroups.Thisalsoappliestonon-webscenarios.

Year 1 Results from Task 3 – Access to Resources


26


R14 Browser-&non-browser-basedfederatedaccess

The Federated AAI framework should provide federated access tobothweb-basedandnon-web-basedservices/applications

Table5.1:Functionalrequirementsforaccesstonon-webresources

5.3 Ongoing Pilots in Task 3

Toaddress the token translation topic, theTask started twopilots: theCILogonpilot and the LDAP-Facadepilot. For both, preliminary results are available already. Preparation for a third pilot, with the Unity-IdMcomponent, has started recently; first resultswill be available at a later stage. A fourth pilot, that aims toimprove and showcase federated access to third-party services, is also underway. Each of these pilots isdescribedbelow.

5.3.1 Pilot 1 – CILogon

The CILogon pilot aims to test the feasibility of providing a more advanced online service for producingcertificatesbasedonaninstitutional loginanddelegatingaproxycertificatetoanon-webback-endservice,withouttroublingtheuserwithcertificate-relatedcomplexity.Publickeyinfrastructures(PKIs)workverywellforexpertswhoareusedtohandlingcertificatesandprivatekeys,butareconsideredtobeverydifficultbymost end users. For automated systems, certificate-based authentication is, however, fast, reliable, wellsupported,wellunderstoodfromasecuritypointofview,etc.

Thepilotsetuproughlyfallsintothreeseparateparts:

• Acentralonlinecertificationauthority(CA)withawebfrontend.• Acachingandcredential-handlingmasterportal.• Sciencegatewaysrunbyvirtualorganisations(VOs)(VOportals).

The end user interacts almost exclusively with the science gateway. As a result of this pilot and thecomponentstested,theteamestablishedawhite-labelResearchandCollaborationAuthenticationCAServicefor Europe (RCauth.eu) [RCauth]. This online CA service hides complexity for users, is InteroperableGlobalTrustFederation(IGTF)[IGTF]accredited,andcomplieswithSecurityIncidentResponseTrustFrameworkforFederated Identity (Sirtfi) [Sirtfi], theREFEDSResearchandScholarshipspecifications [REFEDS-R&S]andtheeduGAIN 2.0 declaration [eduGAIN]. Because of those features it is already recognised as an attractivesolutionforresearchcollaborationsande-infrastructurestosharetheirresourceswiththeircommunities.

AsummaryofthepilotandlinkstofurtherdetailareprovidedinTable5.2below.



27

Task3,Pilot1 AccesstoNon-webResources–CILogon

Focus Pilot a combination of solutions (workaround) to enable access to non-web,X.509-based resources that are common in the GRIDworld with SAML-basedcredentialsinanend-user-friendlyway


CILogonisthecentralcomponentinthispilot,whichprovidesX.509certificatesusingOpenIDConnectandaSAML-basedfederatedidentity.Endusersinteractwithwebportals (sciencegateways),whicharerepresented in thepilot in theformofademonstrator“VOPortal”.Additionalcomponents,suchasaseparate“Master Portal”, have been introduced to hide complexity for the users andscience gateways and to provide sufficient scalability. At the same time,interfacingwith theVirtualOrganisationMembership Service (VOMS) [VOMS]asanattributeproviderisbeinginvestigatedandpiloted.

Componentspiloted CILogonsoftware(includingOA4MP,Shibboleth,MyProxy,SimpleCA),VOportal+MasterPortal,VOMS(interfacewith)


• ProvidingX.509-basedaccesscapabilitiestotheenduserwithouttheneedforthemtomaintainorunderstandPKI

• Noneedtohelpenduserswithdifficult-to-managecertificatecredentials• Asingleentrypointcanprovideaccesstoawiderangeofresources,both

web-andnon-web-based

Demo/video • Aclearexplanationofthiseffortisprovidedasablogwiththetitle“Digitalcertificatesbehindthescenes:theAARCCILogonpilot”ontheAARCprojectwebsitehere.

• Demo


• FOM-NIKHEFAARCpilotWiki• RCauth.eupresentation


SeeFOM-NIKHEFAARCpilotWiki

Softwaresource(s) Seewww.rcauth.euand.RCauth.eugithub

Lead FOM-NIKHEF

Communitypartners ELIXIR,EGI,CESNET,CSC

Status AftersuccessfulpilotswiththeELIXIRandEGIcommunity,awhite-labelCApilotservice has been created: RCauth.eu. In a next step, command line access toproxycredentialsusingSSHkeyswillbepiloted.

Table5.2:Task3,Pilot1–Accesstonon-webresources–CILogon



28

Figure5.1:ScreenshotoftheRCauth.euwhite-labelCAserviceforEurope

WithregardtoAARC’saimtodevelopsustainabilityandoperatingmodelsforemerging(AARCpilot)services,the CILogonpilotwas a firstling. As part of theNA3 PolicyHarmonisationActivity, the ServiceOperationalModelsTask(Task3)hasstartedtodescribemodelsandscenariosforthispilot.SeeSustainabilitymodelsfortheAARCCILogon-likeTTSPilotandRCauth.eu[CILogon-Models]formoreinformation.

5.3.2 Pilot 2 – LDAP-Facade

Thesecondtokentranslationpilot,basedontheLDAP-Facadecomponent,aimstoprovideaccesstonon-webresources (e.g. SFTP, SSH console) for non-grid users by exploiting the existing AAIs, without the need toobtainusercertificates.AsummaryofthepilotandlinkstofurtherdetailareprovidedinTable5.3below.

Task3,Pilot2 AccesstoNon-webResources–LDAP-Facade

Focus Thepilotaimstoprovideaccesstonon-webresources(e.g.SFTP,SSHconsole)tonon-gridusersusingexistingAAIs,withoutneedingtoobtainusercertificates


LDAP-Facadeisasinglesoftwarecomponent,whichneedstobeinstalledattheSP.Itmakesuseofthelocalaccountspreparedduringtheregistrationstep.ThesoftwareisabletoreplacethetraditionalLDAPserver,asitprovidesthesameinterface.Asaresult,LDAP-Facadecanbeusedasalocalusermanager,aswellasanauthenticationandauthorisationcomponent,withoutanymodificationtoservers (not only is core code unchanged, even implementing a specialisedpluginisnotnecessary).Ontheotherside(collaborationwithexternalIdP),thedeploymentisthesameasforanyotherSAML-basedSP.

Componentspiloted LDAP-Facade



29

Task3,Pilot2 AccesstoNon-webResources–LDAP-Facade


• Noneedtoinstalladditionalsoftwareonuserside• Limiteduseofusergroups(dependsonavailableattributes)• Federatedaccesstonon-webservices• Noneedtomanuallymaintainlocalaccountsoneachresource• Nomodificationtoserversoftware• Up-to-dateidentity information(requiresEPCorAQSAMLprofilessupport

bytheIdP.Workaroundshavebeenproposedbutarenotyetimplemented)

Demo/video Demo(seeflowdescriptionandinstructionshere)


AARCWiki


LDAP-FacadeWikiatKIT

Softwaresource(s) GitatKIT

Lead PSNC,KIT

Communitypartners PSNC,KIT

Status Finalised.TheLDAP-Facadeportalisworking.ItispossibletologinthereusingeduGAINcredentialsandregistertoatestservice.Theuseristhenabletologintotheresourceusingalocalpassword.Limitation:theuser’scredentialsarenotcheckedagainsthis/herIdPwhileloggingintotheresource.

Table5.3:Task3,Pilot2–Accesstonon-webresources–LDAP-Facade



30

Figure5.2:ScreenshotoftheLDAP-Facadepilotservice

5.3.3 Pilot 3 – Unity-IdM

Unity-IdM[Unity-IdM] isathirdpotentialsolutionforbridgingSAML-basedidentitiesandattributestonon-webresources,whichtheTaskaimstoassessinthesecondyearoftheAARCproject. It iscurrentlyusedatEUDATasthecorecomponentfortheirB2ACCESSservice[EUDAT-B2ACCESS].Atthesametime,EUDAT,aswellasPRACEandEGI,areinterestedinapplyingtheRCauth.euservices.TheTaskthereforeaimstoinitiateacollaborativepilotwithEUDATAAI,PRACEandEGI.Thiseffortiscurrentlyinpreparation.

5.3.4 Pilot 4 – ORCID

Task3alsohasafocusonimprovingandshowcasingfederatedaccesstothird-partyservices.TheORCIDpilotisoneexampleofathird-partyservicethathasbeentestedinthecontextofAARC.Thepilotconsistsofthreesteps:

1. ORCIDasaserviceprovider(SP).2. ORCIDasanidentityprovider(IdP)(inprogress).3. ORCIDasanattributeauthority(OAuth2-basedsetup,aspartofTask2).

The first step has been piloted and finalised. Federated access to ORCID is now in production andwidelyavailable to the community. Preparations to pilot the use of ORCID as an authentication and/or attributeauthorityproviderhavestartedandresultsareexpectedsoon.



31

AsummaryofthepilotandlinkstofurtherdetailareprovidedinTable5.4below.

Task3,Pilot4 AccesstoNon-webResources–ORCID

Focus ThispilotshowcasestheintegrationbetweenfederatedidentityandORCID.orgtoobtain a persistent life-long identifier anduse that identifier as part of thefederatedidentity


TobeabletousetheORCIDAPI,somecustomisationofAARC’sAAIsolutionsisneeded.InafirststepORCIDhasbecomeavailableasaneduGAINSP.

Componentspiloted Inthebasicsetupalinkingservicewillbeintroduced(developedintheVOPaaSproject)andtested.IntheadvancedsetupanSPproxytoaggregateattributesfrominstitutions,ORCIDandothersourceswillbeintroducedandtested.


• Ability to reuse a single persistent identifier and linkmultiple accounts tothissingleidentifier

• Ability to identify a single/unique user no matter whether this userauthenticateswithaccountAoraccountB

Demo/video • Demoproductionservice(atORCID.org)• Blogwithfurtherdescription


AARCWiki


SeetheSURFnetORCIDWiki

Softwaresource(s) SeetheSURFnetORCIDWiki

Lead SURFnet

Communitypartners NLandITlibrariesandresearchcommunities

Status InthefirststeptheTaskestablishedasetupwithORCIDasanSP. Inasecondstep,ORCIDwillactasanattributeauthority.Forthis(second)purpose,auser’sinstitutional account needs to be linked to an ORCID account. An initial pilotsetupwascreatedandtestedwiththeDutchfederationSURFconext.Theworkwill continue by showcasing integratedORCID attribute aggregationflows intoVOattributemanagementplatforms.Thiswill takeplaceduringthesecondyearofAARC.

Table5.4:Task3,Pilot4–Accesstoresources–ORCID



32

Figure5.3:ScreenshotoftheORCIDSAMLconnection

5.3.5 Observations

Task3activitiesinthesecondyearofAARCwillfocusonacomparisonofdifferenttokentranslationservices,testingofproposedsetupswithcommunitiesandadoptionbycommunities.


33

6 Conclusions

Throughitspilots,SA1aimstodemonstratethat:

• Existing authentication and authorisation infrastructures (AAIs) and authentication sources can beleveragedtoenable(singlesign-on(SSO))access,withappropriatelevelofassurance,foranyuser,tosharedresourcesofferedbydifferente-infrastructureprovidersandcommunities.

• Authoritative decisions and user/group context can be based on distributed group managers andattributeproviders.

• Accesstonon-webandcommercialservicescanbeenabled.

Having first setupa technicalplatform, top-leveldomain,DIY test identityprovider, central repositoryandfirst-linesupporttofacilitatethetesting,deploymentandpilotingofservices,SA1hasstarted–and,incertaincases, finalised – a number of pilots that, at the end of Year 1, mean the Activity is well on the way toachievingthoseaims.

Task1GuestAccesshaspilotedthreesolutionsforlibraryusecases,allofwhichareclosetofinalisation:

• SAML/IPbridge,toallowaccesstorestricted libraryresourceswhetherornottheprovidersupportsSAML.

• Walk-by users, to support authorised access to library resources for anyone who needs scientificinformation,includingcitizenscientistsnotaffiliatedwithaninstitution.

• IdP/SPproxyforlibraryconsortia,toreducethenumberofinteractionsbetweenIdPsandSPsfromatechnicalandtrustpointofviewwhilepreservingtheprivacyofusers.

Together,thesesolutionswillgiveusersoflibraryresourcesasmootherexperiencewhileaccessingresources,irrespective of the authentication method that is supported. They also offer opportunities to reduce theadministrative burdenof library staff in relation tomanaging SAML connections andmaintaining access torestrictedlibraryresources.

Task2AttributeManagement focusesonestablishinga framework forcollaborativeSSOscenarios,pilotingsolutions to facilitate and enable attribute management, attribute aggregation and attribute-basedauthorisation. Pilots are in progress testing components in the context of two infrastructures andcommunities:

• EGI e-infrastructure, investigating and piloting the usability of SAML-based AAI components to useexternallymanagedattributestoprovideandrestrictaccesstocloudservices.

• BBMRI-ERIC,establishingafullyfledgedstandardisedAAItoenableaccessandauthorisationtosharedbiomedicalresourceswithappropriatelevel(s)ofassurance.

Conclusions


34

InbothpilotstheIdP/SPproxyapproachhasbeenadoptedtohandleallcomplexity.Theteamsshare ideasand interact often to make sure that a common and generic approach results from their work and thatduplicationofeffortisprevented.

Task 3 Access to Resources focuses on improving access to non-web resources through token translationsolutions,andonaccessingthird-partyservices.Fourpilotsare inprogress,withpreliminaryresultsalreadyavailableforthreeofthem:

• CILogon,totestacombinationofsolutionstoenableaccesstonon-web,X.509-basedresourceswithSAML-basedcredentialsinanend-user-friendlyway.NA3hasalreadystartedtodevelopsustainabilityandoperationmodelsforthisservice.

• LDAP-Façade, toprovideaccess tonon-webresources tonon-gridusersusingexistingAAIs,withoutneedingtoobtainusercertificates.Finalised.

• Unity-IdM,totestathirdpotentialsolutionforbridgingSAML-basedidentitiesandattributestonon-webresources.Thispilotisatthepreparationstage.

• ORCID,toshowcasetheintegrationbetweenfederatedidentityandORCID.orgtoobtainapersistentlife-longidentifierandusethatidentifieraspartofthefederatedidentity.

Through thiswork SA1 has identified interesting ideas for solutions, and also a number of challenges thatneedtobesolvedtobeabletoincreaseuserfriendlinessandtobridgedifferentresearchinfrastructuresandcommunities. Plans are in place to extend and build on the pilots in Year 2, including joint Task work onsolutionsforbridgingtowardssocialande-governmentalidentities,additionaltokentranslationsolutionsandfurtherintegrationwithORCID.


35

References

[~okeanos] https://okeanos.grnet.gr/home/[AARCGit] https://github.com/AARCProject[AARCPrivate] https://gitlab.pilots.aarc-project.eu[AARCWiki] https://wiki.geant.org/display/AARC/AARC+Pilots[BBMRI] http://www.bbmri-eric.eu/[CILogon] https://cilogon.org[CILogon-Models] SustainabilitymodelsfortheAARCCILogon-likeTTSPilotandRCauth.eu

https://wiki.geant.org/download/attachments/56918657/AARC-sustainability-models-for-RCauth-20160506.pdf?version=1&modificationDate=1462630136894&api=v2

[COmanage] http://www.internet2.edu/comanage[DJRA1.1] DeliverableDJRA1.1:Analysisofusercommunityandserviceproviderrequirements

https://aarc-project.eu/wp-content/uploads/2015/10/AARC-DJRA1.1.pdf[eduGAIN] http://www.edugain.org/[eIDAS] http://www.mizs.gov.si/fileadmin/mizs.gov.si/pageuploads/

Informacijska_druzba/eIDAS/DrugiDok/LOA_Guidance_vFinal.pdf[ELIXIR] http://www.elixir-europe.org/[EUDAT-B2ACCESS] https://www.eudat.eu/services/b2access[EZproxy] https://www.oclc.org/ezproxy.en.html[IGTF] https://www.igtf.net[LDAPFacade] http://wiki.data.kit.edu/index.php/LDAP-Facade[MJRA1.1] MilestoneMJRA1.1:ExistingAAIandavailabletechnologiesforfederatedaccess

https://aarc-project.eu/wp-content/uploads/2016/01/MJRA1.1-Existing-AAI-and-available-technologies.pdf

[MJRA1.2] MilestoneMJRA1.2:DesignforDeployingSolutionsfor“GuestIdentities”https://aarc-project.eu/wp-content/uploads/2016/06/MJRA1.2-Design-for-Deploying-Solutions-for-Guest-Identities.pdf

[MJRA1.3] MilestoneMJRA1.3:DesignfortheintegrationofanAttributeManagementToolhttps://aarc-project.eu/wp-content/uploads/2016/06/MJRA1.3-Design-for-the-integration-of-an-Attribute-Management-Tool.pdf

[MJRA1.4] MilestoneMJRA1.4:FirstDraftoftheBlueprintArchitecturehttps://aarc-project.eu/wp-content/uploads/2016/08/MJRA1.4-First-Draft-of-the-Blueprint-Architecture.pdf

[MSA1.1] MilestoneMSA1.1:SpecifytheworktobeundertakenincollaborationwithJRA1andNA3https://aarc-project.eu/wp-content/uploads/2015/10/MSA1.1-v8FINAL.pdf

[NA3-WIKI-SOM] https://wiki.geant.org/x/5oc0Aw[OAuth2] https://oauth.net/2/[OCLC] http://www.oclc.org/

References


36

[OIDC] http://openid.net/connect/[OpenConext] http://www.openconext.org[ORCID] http://orcid.org/[Perun] http://perun.cesnet.cz[PilotPlatformVideo] https://aarc-project.eu/aarc-pilot-platform-approaching-take-off/[RCauth] http://rcauth.eu[REFEDS-R&S] https://refeds.org/category/research-and-scholarship[Shibboleth] https://wiki.shibboleth.net/confluence/x/i4EEAQ[SimpleSAMLphp] https://simplesamlphp.org[Sirtfi] https://refeds.org/sirtfi[Unity-IdM] http://unity-idm.eu[VOMS] https://italiangrid.github.io/voms/[VOPaaS] https://wiki.geant.org/display/gn41sa5/Task+4+-+FaaS[ZeroTier] https://www.zerotier.com/index.shtml


37

Glossary

AA AttributeAuthorityAAI AuthenticationandAuthorisationInfrastructureAARC AuthenticationandAuthorisationforResearchandCollaborationAPI ApplicationProgrammingInterfaceAQ AttributeQueryAuthZ AuthorisationBBMRI BiobankingandBioMolecularresourcesResearchInfrastructureBBMRI-ERIC BiobankingandBioMolecularresourcesResearchInfrastructure–EuropeanResearch

InfrastructureConsortiumCA CertificationAuthorityCILogon CILogonenablesuserstoauthenticatewiththeirhomeorganisationandobtainacertificate

forsecureaccesstoCyberInfrastructure(CI)DIY Do-It-YourselfeduGAIN Internationalinterfederationserviceinterconnectingresearchandeducationidentity

federationsEGI EuropeanGridInfrastructureeID ElectronicIdentificationeIDAS EURegulationNo910/2014onelectronicidentificationandtrustservicesforelectronic

transactionsintheEuropeaninternalmarketEPC EndPointCriterionGit AfreeandopensourcedistributedversioncontrolsystemGOCDB GridOperationsConfigurationDatabase,anEGIserviceIaaS InfrastructureasaServiceICT InformationandCommunicationsTechnologyIdP IdentityProviderinthecontextofSSOscenarios,suchassupportedbyShibbolethIGTF InteroperableGlobalTrustFederation–abodytoestablishcommonpoliciesandguidelines

thathelpestablishinteroperable,globaltrustrelationsbetweenprovidersofe-infrastructuresandcyberinfrastructures,identityproviders,andotherqualifiedrelyingparties

IP InternetProtocolJRA1 JointResearchActivity1ArchitecturesKIT KarlsruheInstituteofTechnologyLAN LocalAreaNetworkLDAP LightweightDirectoryAccessProtocolLIBER LiguedesBibliothèquesEuropéennesdeRecherche–AssociationofEuropeanResearch

LibrariesLoA LevelofAssurance–degreeofcertaintythattheuserhaspresentedacredentialthatrefersto

thatuser’sidentityM ProjectMonthMZK MoravskázemskáknihovnavBrně–MoravianLibrary

Glossary


38

NA3 NetworkingActivity3PolicyHarmonisationNREN NationalResearchandEducationNetworkOA4MP OAuthforMyProxyprovidesanOAuth-compliantRESTwebinterfacetotheMyProxyservice

forprovidingusercertificatestosciencegatewaysOAuth OAuthisanopenstandardforauthorisationOCLC OnlineComputerLibraryCentreOIDC OpenIDConnectORCID Anot-for-profitorganisationthatprovidesauniqueidentifierforindividualstousewiththeir

nameastheyengageinresearch,scholarship,andinnovationactivitiesacrossdisciplines,bordersandtime

Perun Awidesystemprovidingusermanagementanduser-connectedservicestovarioustypesoffacilitiesinvariousinfrastructuresizes

PKI PublicKeyInfrastructureR&E ResearchandEducationRCauth.eu Thewhite-labelResearchandCollaborationAuthenticationCAServiceforEuropeREST RepresentationalStateTransferSAML SecurityAssertionMarkupLanguageisanXML-based,open-standarddataformatfor

exchangingauthenticationandauthorisationdatabetweenparties,inparticular,betweenanidentityproviderandaserviceprovider

SA1 ServiceActivity1PilotsSFTP SSHFileTransferProtocolSirtfi SecurityIncidentResponseTrustFrameworkforFederatedIdentitySP ServiceProviderinthecontextofSSOscenarios,suchassupportedbyShibbolethSSH SecureShellSSO SingleSign-OnTEIP TransparentExternalIdentityProxyTTS TokenTranslationService.RCauth.euisaTokenTranslationServicethattranslatesSAMLto

X509VM VirtualMachineVO VirtualOrganisation–adynamicsetofindividualsorinstitutionsdefinedaroundasetof

resource-sharingrules.Resourcesharingis,necessarily,highlycontrolled,withresourceprovidersandconsumersdefiningclearlyandcarefullyexactlywhatisshared,whoisallowedtoshare,andtheconditionsunderwhichsharingoccurs

VOMS VirtualOrganisationMembershipServiceVOPaaS VirtualOrganisationPlatformasaServiceVPN VirtualPrivateNetworkX.509 StandardforapublickeyinfrastructuretomanagedigitalcertificatesXML ExtensibleMarkupLanguage

15-12-2016 Deliverable DSA1.2: First report on the pilots ... · 15-12-2016 Deliverable DSA1.2:...

Documents

Transcript of 15-12-2016 Deliverable DSA1.2: First report on the pilots ... · 15-12-2016 Deliverable DSA1.2:...