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

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

6. B2ACCESS - Architecture

7. The main product currently used: Unity

8. The service (portal) hosted by FZ Juelich

9. 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)

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

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

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

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

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

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

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

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

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

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