Identity Management and Authorization EUDAT B2ACCESS Identity Management and Authorization Johannes Reetz / Willem Elbers / Sander Apweiler EOSCpilot AAI session 24 July 2017

Agenda EUDAT Service Suite B2ACCESS - EUDAT FIM Proxy B2ACCESS Attributes Integration Scenarios Authorization RCAuth

EUDAT Service Suite

Collaborative Data Infrastructure Operational, Central and Support services Thematic Service Providers Generic Service Providers providing PIDs

B2ACCESS - EUDAT FIM Proxy low LoA low LoA medium - high LoA

B2ACCESS - Architecture

The main product currently used: Unity http://www.unity-idm.eu/

The service (portal) hosted by FZ Juelich https://b2access.eudat.eu

e.g. login into gitlab.eutdat.eu

B2ACCESS loging with x.509 cert

B2ACCESS primary IdPs (Status June‘17) B2ACCESS LOGIN (username/password, self-service, email- confirmation) eduGain IdPs (SAML) Specific “community” IdPs (SAML) ARIA CLARIN ELIXIR IdP (pilot) Social IdPs (OAuth2) Facebook GitHub Google Microsoft Live ORCID IdP X.509 personal certificates (IGTF, GEANT, DFN Global)

B2ACCESS - Attributes Attributes: Persistent id Firstname / Lastname Email Organization/Affiliation Level of assurance Use available information supplied by upstream IdP Request missing information from user during initial registration Currently Level of Assurance (LoA) per upstream IdP (federation)

B2ACCESS Attributes (cont.) Name Mandatory multi- valued Description urn:oid:2.5.4.49 distinguishedName YES 2 The destinguished name. It occurs twice, once with the OID as attribute name and once with DN unity:persistent   1 The persistent EUDAT identifier urn:oid:2.5.4.3 cn YES? 0..2 Common name. Occurs twice. urn:oid:1.2.840.113549.1.9.1 userName Principal. A single value of the formuser@domain, where domain is (typically) a DNS-like subdomain representing the security domain of the user (e.g., "osu.edu") and user is generally a username, NetID, UserID, etc. of the sort typically assigned for authentication to network services within the security domain. Occurs twice. email email address memberOf NO 0..* A list of strings denoting group memberships of EUDAT communities, roles in EUDAT itself, and roles associated with EUDAT services E.g. /CLARIN, /ENES for the communities, /EUDAT-Staff for members of the EUDAT project, and /eudat:b2safe, /eudat:/b2share for people with roles associated with the services.

B2ACCESS – Self Service

B2ACCESS – Self Service

Technical workflow

Level of Assurance LoA per IdP not sufficient. Attributes provided by other sources? Feature has been requested by Service Providers Investigating LoA per attribute (at least for "high-value" attributes) Build on existing work (NIST, AARC, IETF, InCommon, ...) Outcomes: LoA per attribute definition, specification and implementation

B2ACCESS Challenges NREN opt-in policy End-user's don’t understand why it is not working CLARIN SPF as a solution, but there are legal challenges Attribute release and Trust into Attribute providers

Integration Scenarios External EUDAT CDI SP 1 IDP 1 SP 2 IDP 2 SP 3 In this scenario, which is how B2ACCESS is currently deployed, integration is only allowed for service providers (SPs) which are part of the EUDAT CDI and identity providers selected by the EUDAT project. A community can only use B2ACCESS if one or more of its IDPs are connected to B2ACCESS, this should be easy to extend and request, and they can only use B2ACCESS to access EUDAT B2 services. This is the current deployment Allows EUDAT CDI Service Providers EUDAT Identity Provider EUDAT Selected external Identity Providers Communities can use B2ACCESS if they have IDPs connected to B2ACCESS Benefits for the community: Access to the EUDAT services Potential issues no potential issues TODO: Say something about contract requirements for each of the options SP n IDP n EUDAT IDP

Integration Scenarios External EUDAT CDI IDP 1 IDP 2 IDP n SP 1 SP 2 SP 3 SP n EUDAT IDP Community 1 Community n In this scenario communities are allowed to integrate their own SPs into B2ACCESS. Those SPs, despite not being part of the EUDAT CDI, ultimately become accessible to all communities within EUDAT. EUDAT collects information from users which is sometimes not released by their organizational IDPs. This extra information is potentially privacy sensitive and thus cannot be released to external entities without reviewing the Code of Conduct and Data Privacy Statement. An alternative to avoid this issue could be to only release a small subset of non privacy related attributes to such external SPs. Allows integration of community Service Providers, not part of the EUDAT CDI Benefits for the community Allow access to their services for the EUDAT user base Potential Issues Attribute release is a potential issue in this scenario Investigate if signing the Code of Conduct is sufficient EUDAT endorses these external services TODO: Say something about contract requirements for each of the options

Integration Scenarios Community Branded but run by EUDAT External Community n IDP 1 IDP n SP 1 SP 1 External Community 1 IDP 1 SP 1 IDP n SP 1 External EUDAT CDI SP 1 In this scenario EUDAT will deploy and maintain a dedicated B2ACCESS instance for a community. The community should be responsible for integrating IDPs and SPs as they see fit. This dedicated B2ACCESS instance should be branded for the specific community, however it should be made clear that it is run and provided by the EUDAT project. EUDAT will provide technical support and keep the system up to date. The community is responsible for managing the instance. This is very similar to a SaaS business model. Maintenance, the required infrastructure and knowledge is provided by EUDAT. The system is proven to run reliably in the EUDAT CDI. This is a huge benefit for communities without the resources of running and developing such infrastructure themselves. Aka. B2ACCESS as a Service Allows communities to use an EUDAT provided and maintained AAI service for their community EUDAT should be responsible for running and maintaining the service Communities are responsible for configuration and administration of users, groups, attributes, … EUDAT to define a SaaS business model Benefits for the community Maintenance Technical support Potential issues This scenario requires more, probably the most, resources from EUDAT TODO: Say something about contract requirements for each of the options IDP 1 SP 2 IDP 2 SP 3 SP n IDP n EUDAT IDP

Authorization (in work) A federated authorization solution supporting authorization records from external communities Attribute based access control (ABAC) instead of Role based access control (RBAC) because of increased flexibility Based on XACML Split policy repository per service, avoiding single point of trust Demonstrator up-and-running, evaluating openConext openAZ fork

Authorization Central policy repository on the service level One management location Should support bulk ingest from external (community) sources Replicate central repository to data centers Prevents single point of failure PDP using local PRP Risk of getting out-of-sync

Authorization (XACML framework) Based on XACML standard Policy Repository (PRP) is distributed from the central service to each data center. This allows authZ decisions at the local data center even if the central service is unavailable. If the central service is unavailable importing and managing the policies is not possible. HA setups of the central services will be investigated PAP: Policy administration point PRP: Policy repository PIP: Policy information point PDP: Policy decision point PEP: Policy enforcement point

Authorization Based on XACML standard Policy Repository (PRP) is distributed from the central service to each data center. This allows authZ decisions at the local data center even if the central service is unavailable. If the central service is unavailable importing and managing the policies is not possible. HA setups of the central services will be investigated PAP: Policy administration point PRP: Policy repository PIP: Policy information point PDP: Policy decision point PEP: Policy enforcement point

RCAuth Replace current, contrail based, CA. No embedded attributes Clarify policy requirements AARC Architecture: https://wiki.nikhef.nl/grid/AARC_Pilot_-_Architecture

Outlook A single european AAI solution is not very realistic Interoperability between infrastructures is needed Interoperable technologies Interoperable user IDs Harmonize minimal set of attributes EGI egi/1234 EGI AAI Johannes: In principle there should be several trustworthy AAI systems in EUROPE (so that the EGI and the EUDAT AAI can coexists and the users can decide, which one to use). The only prerequisite would be namespaces (=prefixes) So I propose to draw a picture with >2 IDM solutions that, similar to the Handle system, share the same prefix/suffix format for Identifiers (each IDM with a different prefix and an organisation that makes sure that a prefix is not misused). These systems should also share the same kind of minimal metadata such as: first name & last name, email, and a LoA provided by the specific IDM. EUDAT B2 ACCESS ... … AAI eudat/1234 .../1234

Summary In production since October 2015 Working well but still challanges to solve (IdP attribute release, NREN opt-in) improving user interface and log-in workflow connected with Facebook, Google, Live, GitHub, ORCID IdPs, … SIRTFI v1 ready Working on a number of new features: Integration with RCAuth Integration with token translation services LoA per attribute Continuous integration of new (Community) IdPs and SPs Interoperability with other infrastructures such as EGI Cleanup of personal attributes after account deactivation