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

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

3. EUDAT Service Suite

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

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

6. B2ACCESS - Architecture

7. The main product currently used: Unity

8. The service (portal) hosted by FZ Juelich

9. e.g. login into gitlab.eutdat.eu

10. B2ACCESS loging with x.509 cert

11. B2ACCESS primary IdPs (Status June‘17)
B2ACCESS LOGIN (username/password, self-service, - 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)

12. B2ACCESS - Attributes Attributes: Persistent id Firstname / Lastname
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)

13. B2ACCESS Attributes (cont.)
Name
Mandatory
multi- valued
Description
urn:oid:
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: cn
YES?
0..2
Common name. Occurs twice.
urn:oid:
userName
Principal. A single value of the 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.
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.

14. B2ACCESS – Self Service

15. B2ACCESS – Self Service

16. Technical workflow

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

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

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

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

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

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

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

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

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

26. RCAuth Replace current, contrail based, CA. No embedded attributes
Clarify policy requirements
AARC Architecture:

27. 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, , and a LoA provided by the specific IDM.
EUDAT B2
ACCESS
... …
AAI
eudat/1234
.../1234

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