1. https://aarc-project.eu Authentication and Authorisation for Research and Collaboration Peter Solagna, Nicolas EGI AAI integration experiences AARC Project

2. https://aarc-project.eu 2 Where is EGI in terms of federated AAI integration?

3. https://aarc-project.eu 3 Where is EGI in terms of federated AAI integration #2? Central IdP Discovery Service User Enrolment/Account Linking User Consent Support for LoA CoCo & R&S compliance Attribute Aggregation SAML2.0 Attribute Query, REST, LDAP Support for OIDC/OAuth2 Social IDs Support for SAML STORK eGOV IDs (Experimental)

4. https://aarc-project.eu IdP/SP proxy available in a production-like deployment High availability Load balancing Connection available with the CI Logon TTS To migrate to the accredited online CA Integration with IdPs EGI SSO ELIXIR IdP Proxy Social IdPs: Google, Facebook, LinkedIn ORCID (See demo) Integration with the EGI Operational tools (SPs) Virtual Machine images DB (AppDB) Configuration database (GOCDB) Federated Cloud (FedCloud) (SAML tested / OIDC underway) Users can authenticate using the IdP Proxy in the tools EGI specific information (e.g. status of Site security officer) are now available as entitlement in the authentication assertion through the EGI IdP/SP proxy Community attributes consumed by EGI ELIXIR collaboration 4 Where is EGI in terms of federated AAI integration? #3

5. https://aarc-project.eu Through the IdP/SP proxy EGI can easily integrate new IdPs All SPs in EGI are encouraged to authenticate users only through the EGI IdP Proxy Still not mandatory, but we will get there So far not yet integrated in eduGAIN as a SP Mostly my (Peter’s) fault But… are things going to be really different as eduGAIN SP? Still the release of attributes by IdPs may not be uniform  some glue work for the EGI IdP/SP proxy User experience still not optimal Selection of the IdP may still be awkward For the users it’s easier to choose the VO rather than the IdP In many cases it’s not even their institutional IdP, but their collaboration IdP/proxy Automation must be improved The less the users have to select/choose, the less they can do wrong easier is to access the services Branding Research infrastructures want to keep their users always linked to their community: users should always know that they are accessing services on behalf of their community 5 Integrating IdPs

6. https://aarc-project.eu Previously EGI was only using X509 certificates released by IGTF for authentication In some use cases holding an X509 certificate was enough to authorize the user to perform certain actions If a user goes through the hassle process of obtaining an IGTF personal certificate they must be interested in scientific computing, EGI or related activities Authentication through institutional IdPs changes the scenario: From 20k potential users to hundreds of thousand users For every action EGI will have to attach some attributes to the user to qualify them to perform the action E.g. who can access in read-only to configuration management database of EGI services LoA (eduPersonAssurance) VO membership/role (scoped eduPersonEntitlement) Challenge: Scalable attribute aggregating from various source / Efficient behind- the-scenes discovery of AAs / Performance Attribute Query methods 6 Who can be trusted?

7. https://aarc-project.eu Not as much to report as I would like Federated AAI  X509 CI Logon has not been tested with real users, yet. No feedback here OIDC  SAML See Nicolas’ presentation SAML  OIDC We have some new services that speak only OIDC, and we plan to deploy a first instance of OIDC IdP connector during the summer 7 Token translation

8. https://aarc-project.eu The federation (EGI) needs to control the attributes and entitlements that are provided to the services For the authorization, services expect to receive certain attributes and entitlements with values in a given format Uniform attributes semantic and syntax across multiple communities/infrastructures will never happen Solution: funnelling all AuthN AuthZ through an IdP/SP proxy allows us to rename/edit/control the attributes Attributes values EGI may need the group information to be provided in a different syntax than stored by the communities Entitlements scoping As discussed yesterday the infrastructure needs to make sure that the grouping/linking encapsulation of entitlement is correctly done Scoping can be also used to make sure that community attribute authorities do not break the infrastructure Proposed syntax: urn:mace:egi.eu: :[ [: :…]]: @ is the FQDN of the authoritative source for the entitlement value is the name of the Virtual Organisation is the name of a group in the identified ; specifying a group is optional the list of components represents the hierarchy of subgroups in the the component is scoped to the rightmost (sub)group; if no group information is specified, the role applies to the VO 8 Handling attributes provided by communities and IdP

9. https://aarc-project.eu So far so good Services are being hooked to the AAI one by one For the resource access we will use the X509 credentials It is a great added value to be able to hook with existing AAI services of research communities CoCo/R&S compliance facilitates attribute release (e.g. ELIXIR AAI integration) Still we have to experience the support with federated identity providers on a bigger scale and find possible bottlenecks Future challenge: Interconnect EGI AAI as an IdP proxy with other e- infras (e.g. EUDAT) Data privacy / policy harmonisation: Sharing EGI user ID/attributes with external SPs 9 Conclusions

10. https://aarc-project.eu © GÉANT on behalf of the AARC project. The work leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 653965 (AARC). Thank you Any Questions? https://aarc-project.eu karl.meyer@geant.org