Identity Management and Authorization EUDAT B2ACCESS Identity Management and Authorization Johannes Reetz / Willem Elbers IG FIM@RDA 9th Plenary meeting, Barcelona, Spain, 6 April 2017

Agenda EUDAT Service Suite B2ACCESS - EUDAT FIM Proxy B2ACCESS Attributes B2ACCESS Challenges 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

B2ACCESS - Architecture

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

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

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)

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 Integrating non services like WebDav or other desktop client, while supporting SSO

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 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

Summary In production since October 2015 Working well but there are still issues to solve (IdP attribute release, NREN opt-in) Improve user interface and log-in workflow connected with Facebook, Google, Live, GitHub, ORCID IdPs Working on a number of new features: Integration with RCAuth Integration with token translation services Sirtfi readiness 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