Authentication and Authorisation for Research and Collaboration JRA
Authentication and Authorisation for Research and Collaboration JRA 1: Integrated AAI Developments Nicolas Liampotis AARC 2 Final AHM 20 Mar, 2019 Abingdon, UK http: //aarc-project. eu
Agenda • Structure • Team (tasks and TLs) • Objectives • Achievements • Conclusions • Summary • Looking ahead – Remaining work http: //aarc-project. eu 2
Team Activity Leader Bla bla Nicolas Liampotis GRNET T 1: Tools and Services for Interoperable Infrastructures T 2: SP Architectures and Auth. Z in Multi. SP Environments Diego Scardaci EGI Marcus Hardt KIT T 3: Models for the Evolution of the AAIs for Research Collabs T 4: Scalable VO platforms Name Davide Vaghetti GARR Jensen STFC Partners http: //aarc-project. eu 3
Tasks • Community feedback and requirements about cross-infra interoperability • Mapping of user and community specific attributes among infrastructures • Cross-infrastructure operations of central AAI services T 2 - SP Architectures and Authorisation in Multi-SP Environments • Scalable and consistent auth. Z across multi-SP environments • SPs using alternative mechanisms and protocols for federated access • SPs requiring step-up auth. N / higher levels of assurance T 3 - Models for the Evolution of the AAIs for Research Collaborations • Challenges and solutions for interoperable cross sector AAI implementations • Technologies and architectures for OIDC federated environments • Tools and architectures for the management of multi-protocol AAIs T 4 - Scalable VO platforms • Technical means to support VO policies and operations • Combining group membership and role information in multi-AA environments • Scalable account (de)provisioning of VO members • Implementing, operating and using VO platforms http: //aarc-project. eu Evolution of the Blueprint Architecture T 1 - Tools and Services for Interoperable Infrastructures 4
Objectives Address the integration aspects of the blueprint architecture and its components into the existing AAIs Explore scalable authorisation solutions in multi-service provider environments Integration of additional technical components in the AAI design to support a wider range of use-cases than to date Cross-sector interoperation http: //aarc-project. eu 5
Integrated AAI Developments Task 1 Tools and Services for Interoperable Infrastructures http: //aarc-project. eu 6
Achievements – JRA 1. 1 Collect community feedback and requirements about cross-infrastructure interoperability DJRA 1. 1 Use-Cases for Interoperable Cross-Infrastructure AAI Analysis of research community specific use cases of crossinfrastructure access to services/resources: Generic use cases DARIAH Life Science EPOS. . . http: //aarc-project. eu 7
Achievements – JRA 1. 1 Collect community feedback and requirements about cross-infrastructure interoperability DJRA 1. 1 Use-Cases for Interoperable Cross-Infrastructure AAI Generic Use Case 1 - Research Infrastructure users accessing e-Infrastructure services http: //aarc-project. eu Generic Use Case 2 - Research Infrastructure services accessing e- Infrastructure resources on behalf of the user 8
Achievements – JRA 1. 1 Mapping of user and community specific attributes among infrastructures AARC-G 002 “Guidelines for expressing group membership and role information” • Standardise the way group membership information is expressed: <NAMESPACE>: group: <GROUP>[: <SUBGROUP>*][: role=<ROLE>]#<GROUP-AUTHORITY> • Express VO/group membership and role information S I G AE • Support group hierarchies in group membership information • Indicate the entity that is authoritative for each piece of group membership information • Supersedes AARC-1 version (March 2017) • Endorsed by AEGIS and implemented by EGI, EUDAT, GÉANT, ELIXIR http: //aarc-project. eu 9
Achievements – JRA 1. 1 Mapping of user and community specific attributes among infrastructures AARC-G 025 “Guidelines for expressing affiliation information” • Affiliation is used by service providers for controlling access to resources • Not just membership – it can also include the type of membership or role in the organization • Challenge: • Define how to express researcher’s affiliation within their: 1. Home Organisation, such as a university, research institution or private company (e. g. faculty@example -uni. eu) 2. Community (e. g. affiliate@research-infra. eu) • How should SP-Id. P-Proxies transport attribute values scoped at the user’s Home Organisation? • How to express the affiliation “freshness”? http: //aarc-project. eu 10
Achievements – JRA 1. 1 Mapping of user and community specific attributes among infrastructures AARC-G 025 “Guidelines for expressing affiliation information” Federated identity protocol Affiliation within Home Organisation Affiliation within Community SAML vo. Person. External. Affiliation edu. Person. Scoped. Affiliation OIDC voperson_external_affiliation eduperson_scoped_affiliation http: //aarc-project. eu 11
Achievements – JRA 1. 1 Mapping of user and community specific attributes among infrastructures AARC-G 025 “Guidelines for expressing affiliation information” Value Description $AARC-PREFIX$/ATP/e. PA-1 m reflects user’s departure from the Community within 31 days time $AARC-PREFIX$/ATP/e. PA-1 d reflects user’s departure from the Community within one day $AARC-PREFIX$/ATP/v. PEA-1 m reflects user’s departure from the Home Organisation within 31 days time $AARC-PREFIX$/ATP/v. PEA-1 d reflects user’s departure from the Home Organisation within one day. To be reviewed by AEGIS http: //aarc-project. eu 12
Achievements – JRA 1. 1 Mapping of user and community specific attributes among infrastructures AARC-G 026 “Guidelines for expressing community unique user identifiers” • Challenge • How to express community user identifiers across AARC BPA-compliant AAIs? • e. PUID, e. PPNs, e. PTIDs/SAML Name. IDs, Subject. ID, … • Goal L L A C T S LA • Propose identifier schema based on combination of two distinguishable components: • <unique. ID> • <scope> • Propose different strategies for generating globally unique, nontargeted, persistent and non-reassignable user identifiers http: //aarc-project. eu To be submitted to AEGIS 13
Integrated AAI Developments Task 2 Service Provider Architectures and Authorisation in Multi. SP Environments http: //aarc-project. eu 14
Achievements – JRA 1. 2 Scalable and consistent authorisation across multi. SP environments DJRA 1. 2 Authorisation models for SPs • Goal: Identify authorisation models for managing access across large groups of SPs in a consistent, secure and scalable manner • Methodology: Analyse infrastructure auth. Z use-cases in collaboration with SA 1 http: //aarc-project. eu 15
Achievements – JRA 1. 2 Scalable and consistent authorisation across multi. SP environments DJRA 1. 2 Authorisation models for SPs: Observed models Resource-local policy management and decision making Centralised policy information point Centralised policy management and decision making Hierarchical policy management and decision making Distributed policy enforcement http: //aarc-project. eu 16
Achievements – JRA 1. 2 Scalable and consistent auth. Z across multi-SP environments AARC-G 027 “Specification for resource capabilities” • Challenge: • How to define the resource(s) a user is allowed to access? “Capabilities” • Goal: • Standardise syntax of Capabilities: S I G AE <NAMESPACE>: res: <RESOURCE>[: <CHILD-RESOURCE>]. . . [: act: <ACTION>[, <ACTION>]. . . ]#<AUTHRTY> • Supports resource hierarchies, i. e. resource parent-child relationships • Supports specifying arbitrary list of actions the user is entitled to perform http: //aarc-project. eu 17
Achievements – JRA 1. 2 Scalable and consistent authorisation across multi. SP environments DJRA 1. 2 Authorisation models for SPs AARC-I 047 - Implementing scalable and consistent authorisation across multi-SP environments Authorization information is classified into two types: 1. User attributes: • Group and role information (AARC-G 002) <NAMESPACE>: group: <GROUP>[: <SUBGROUP>*][: role=<ROLE>]#<GROUP-AUTHORITY> • Assurance information (AARC-G 021) • Affiliation with the home organization and/or community (AARC-G 025) 2. Capabilities (AARC-G 027) <NAMESPACE>: res: <RESOURCE>[: <CHILD-RESOURCE>]. . . [: act: <ACTION>[, <ACTION>]. . . ]#<AUTHRTY> http: //aarc-project. eu 18
Achievements – JRA 1. 2 Scalable and consistent authorisation across multi. SP environments DJRA 1. 2 Authorisation models for SPs AARC-I 047 - Implementing scalable and consistent authorisation across multi-SP environments Centralised Policy Information Point Centralised Policy Management and Decision Making and Enforcement http: //aarc-project. eu 19
Achievements – JRA 1. 2 Service Providers requiring step-up auth. N / higher levels of assurance AARC-G 029 “Guidelines on stepping up the authentication component in AAIs implementing the AARC BPA” • Challenge: • Access to sensitive resources requiring users to authenticate using more than one type of credentials (e. g. password + physical object such as a phone or usb stick that generates tokens/pins, etc) • SPs requiring an already logged in user to re-authenticate using a stronger authentication mechanism when accessing sensitive resources L A FIN • Goal: • Provide implementation recommendations for stepping up of the original authentication strength • Describe a proposed authentication step-up model via multifactor authentication (MFA) http: //aarc-project. eu Reviewed by AEGIS 20
Achievements – JRA 1. 2 AARC-G 049 “A specification for Id. P hinting” • Challenge: • How to help users choose the right identity provider? • How to enable services to send user to a specific home-Id. P • E. g. to update linked accounts • Goal: • Standardise “Id. P hinting” protocol: • Federation protocol (SAML/OIDC) agnostic • Supports chained hinting • Supports specifying multiple Id. Ps S I G AE • Example https: //example. service. edu/? idphint=https%3 A%2 F%2 Fhome-idp. org%2 Fidp%2 Fsaml http: //aarc-project. eu 21
Integrated AAI Developments Task 3 Models for the Evolution of the AAIs for Research Collaborations http: //aarc-project. eu 22
Achievements – JRA 1. 3 Challenges and solutions for interoperable cross sector AAI implementations AARC-G 031 Guidelines for the evaluation and combination of the assurance of external identities • Challenge: • How to evaluate the assurance components in the absence of assurance information from the Credential Service Provider ? • How to evaluate the combined assurance of linked identities (e. g. institutional & social)? Identifier uniqueness Identity proofing and credential issuance, renewal and replacement (IAP) Attribute quality and freshness (ATP) http: //aarc-project. eu 23
Achievements – JRA 1. 3 Challenges and solutions for interoperable cross sector AAI implementations ARC-G 031 Guidelines for the evaluation and combination of the assurance of external identities Compensatory controls for identifier uniqueness User account belongs to single natural person Person to whom the account is issued can be contacted im_a_person R&S_EC contacts Combined evaluation: http: //aarc-project. eu 24
Achievements – JRA 1. 3 Challenges and solutions for interoperable cross sector AAI implementations ARC-G 031 Guidelines for the evaluation and combination of the assurance of external identities Compensatory controls for low Identity proofing and credential issuance, renewal and replacement Kantara level 1 IGTF level DOGWOOD conf_email IGTF level ASPEN Combined evaluation: Equivalent to the value of the effective identity http: //aarc-project. eu 25
Achievements – JRA 1. 3 Challenges and solutions for interoperable cross sector AAI implementations ARC-G 031 Guidelines for the evaluation and combination of the assurance of external identities S I G AE http: //aarc-project. eu 26
Achievements – JRA 1. 3 Technologies and architectures for OIDC federated environments AARC-G 032 Guidelines for registering OIDC Relying Parties in AAIs for international research collaboration • Challenge: • Open. ID Providers currently adopt different client registration approaches depending on the deployment environment: • Testing/Development env Automatic registration • Production env Approval-based registration • Automatic registration is not a trusted approach • Approval-based approaches are trusted but cannot scale (manual intervention by administrators for every OIDC client registration request) Y P P HA ND? E • Goal: “Scalable” and “Trusted” dynamic registration mechanism for OIDC clients: • OAuth 2. 0 protected dynamic registration • Open. ID Connect Federation Pilot 2018 Q 4 http: //aarc-project. eu 27
Integrated AAI Developments Task 4 Scalable VO platforms http: //aarc-project. eu 28
Achievements – JRA 1. 4 Technical means to support VO policies and operations DJRA 1. 3 VO Platforms for Research Collaborations Recommendations: • VO Lifecycle and Scalability • VO Operations • Attributes Make it easy for users to discover existing VOs and their purpose Use standard schemata (inet. Org. Person, edu. Person, vo. Person) and their semantics, and standard protocols, or at least documented interfaces Support lightweight collaborations Support RBAC/ABAC, and provide features to implement scalable RBAC/ABAC, e. g. by scoping roles (if necessary) separately Provide user-friendly role management (discovery, application, notification, etc. ), both for the applicant and the people who approve/deny the request http: //aarc-project. eu 29
Achievements – JRA 1. 4 Technical means to support VO policies and operations DJRA 1. 3 VO Platforms for Research Collaborations Provide features for delegation and automation of tasks, and support role constraints (e. g. “there must be a security contact at all times”) Provide APIs for services and automation Support the AUP process – tracking users signing and re-confirming all relevant AUPs Make the workflow needed to join a VO as clear as possible Support user traceability, particularly if the user’s identity is hidden from the infrastructure Facilitate compliance with the GDPR Ensure compliance with SNCTFI with the VO Platform as an infrastructure constituent [SNCTFI] of all infrastructures used by the members of the VO http: //aarc-project. eu 30
Achievements – JRA 1. 4 Technical means to support VO policies and operations DJRA 1. 3 VO Platforms for Research Collaborations Prevent account reallocation Provide means for relying parties to check freshness of authorisation attributes Consider integration of VO platform with account/quota management Ensure user’s activities in the VO platform are logged, so the platform can participate, if needed, in the resolution of security incidents Make it easy for users to discover documentation and get support Assess VO Platform for usability, both for the end users and for administrators http: //aarc-project. eu 31
Achievements – JRA 1. * Evolution of the Blueprint Architecture “Community-first” BPA approach • Researchers sign in using their institutional (edu. GAIN), social or community-managed Id. P via their Research Community AAI • Community-specific services are connected to a single Community AAI • Generic services (e. g. RCauth. eu Online CA) can be connected to more than one Community AAI proxies • e-Infra services are connected to a single e-infra SP proxy service gateway, e. g. B 2 ACCESS, Check-in, Identity Hub, etc http: //aarc-project. eu AARC-G 045 – Coming soon… 32
Achievements – JRA 1. * Evolution of the Blueprint Architecture http: //aarc-project. eu 33
Tools and Services for Interoperable Infrastructures DJRA 1. 1 Analyses of Use-Cases for Interoperable Cross-Infrastructure AAI Guidelines for expressing group membership and role information Guidelines for expressing affiliation information Guidelines for expressing unique user identifiers SP Architectures and Authorisation in Multi-SP Environments DJRA 1. 2 Authorisation models for SPs Guidelines on stepping up the authentication component in AAIs implementing the AARC BPA Specification for resource capabilities Implementing scalable and consistent authorisation across multi-SP environments Specification for Id. P hinting Models for the Evolution of the AAIs for Research Collaborations Guidelines for the evaluation and combination of the assurance of external identities Analyses of registration mechanisms for Open. ID Connect Relying Parties in AAIs for international research collaboration Scalable VO platforms DJRA 1. 3 Scalable VO Platforms http: //aarc-project. eu Initial evolution of the Blueprint Architecture Conclusions – Main achievements 34
Conclusions – Remaining work Tools and Services for Interoperable Infrastructures • Guidelines for expressing community user identifiers • Guidelines for federated access to non-web services across different operational domains SP Architectures and Authorisation in Multi-SP Environments • Best practices for integrating Open. ID Connect / OAuth 2 based end services Models for the Evolution of the AAIs for Research Collaborations • Guidelines for registering Open. ID Connect Relying Parties in AAIs for international research collaboration? • Proof of concept implementation of assurance evaluation and combination model? Scalable VO platforms DJ RA 1. 4 Evo luti on of the Blu epr int Arc hit ect ure • Guidelines for scalable account (de)provisioning of VO members http: //aarc-project. eu 35
Thank you Any Questions? nliam@grnet. gr © GEANT on behalf of the AARC project. The research leading to these results has received funding from the European Union’s Horizon 2020 research and innovation programme under Grant Agreement No. 730941 (AARC 2). http: //aarc-project. eu
- Slides: 36