| Tip | ||
|---|---|---|
| ||
The first version purpose of the draft AARC Blueprint Architecture has been released. The working document of the ‘AARC Blueprint Architecture’ is available on Google Docs and we would like to encourage the technical architects and implementers in the various research and e-infrastructure and scientific communities to review it, and provide their feedback either in the document itself or via the public AARC Connect mailing list.(BPA) is to provide set of interoperable architectural building blocks for software architects and technical decision makers, who are designing and implementing access management solutions for international research collaborations. |
JRA1: Architectures for an integrated and interoperable AAI
...
High-level Objectives
focus on the integration aspects of the blueprint architecture
provide recommendations and guidelines for implementers, service providers and infrastructure operators on implementing scalable and interoperable AAIs across e-infrastructures and scientific communities
work in close collaboration with the policy, pilots, and the training and outreach activities of AARC2
work on the evolution of the blueprint architecture, with a focus on identity provider / service provider (IdP/SP) proxies, scalable authorisation solutions for multi-service provider environments and other solutions for integrating with R&E federations and cross-sector AAIs
Documents
| ID | Title | Summary | Links |
|---|---|---|---|
| AARC2-JRA1.1A | Guidelines for interoperable exchange of user and community information between AAIs | ||
| AARC2-JRA1.1B | Guidelines for the discovery of authoritative attribute providers across different operational domains | ||
| AARC2-JRA1.1C | Guidelines for handling user registration and user consent for releasing attributes across different operational domains | ||
| AARC2-JRA1.1D | Guidelines for federated access to non-web services across different operational domains | ||
| AARC2-JRA1.2A | Guidelines for scalable and consistent authorisation across multi-SP environments | ||
| AARC2-JRA1.2B | Requirements and guidelines for SPs using alternative mechanisms and protocols for federated access | ||
| AARC2-JRA1.2C | Step-up authentication requirements and guidelines for SPs | ||
| AARC2-JRA1.3A | Guidelines for account linking & LoA elevation in cross-sector AAIs | ||
| AARC2-JRA1.3B | Guidelines for registering OIDC Relying Parties in AAIs for international research collaboration | ||
| AARC2-JRA1.3C | Guidelines for AAI interoperability with non-R&E Identity Providers in support of international research collaboration | ||
| AARC2-JRA1.3D | Guidelines for AAI interoperability with eIDAS Identity Providers in support of international research collaboration | ||
| AARC2-JRA1.3E | AAI tools & technologies enabling OIDC for international research collaboration | ||
| AARC2-JRA1.4A | Roles, responsibilities and security considerations for VOs | ||
| AARC2-JRA1.4B | Guidelines for combining group membership and role information in multi-AA environments | ||
| AARC2-JRA1.4C | Guidelines for scalable account (de)provisioning of VO members | ||
| AARC2-JRA1.4D | Guidelines for implementing, operating and using VO platforms |
analyse how much has been developed to leverage federated access with other authentication systems used in the R&E communities, in the eGov space and in the commercial sector;
research a possible solution to link identities in the contest of higher levels of assurance, attribute providers and guest identities;
assess existing technologies to provide SSO for non-Web applications (cloud, storage and so on) and offer recommendations for their usage;
develop a risk-based model for existing AAI solutions;
propose models for supporting guest identities (NRENs’ in-house solutions vs commercially-offered solutions should be explored);
define a blueprint architecture to enable web and non-web SSO capabilities across different infrastructures, integrating attribute providers/group management tools operated by user-communities;
provide models for federated authorisation: how to integrate attributes and permissions from diverse communities, making them available at the federation level in a consistent and secure way.
Structure of the activity
| Task ID | Task | Leader |
|---|---|---|
| Task 0 (JRA1.0) | Activity Management | Christos Kanellopoulos (grnet) (GRNET) |
| Task 1 (JRA1.1) | Requirements Gathering | Peter Solagna (EGI.eu) |
| Task 2 (JRA1.2) | Blueprint Architectures | Marcus Hardt (KIT) |
| Task 3 (JRA1.3) | Guest Identities | Jens Jensen - STFC UKRI (STFC) |
| Task 4 (JRA1.4) | Models for implementing Attribute Providers and Token Translation Services | Davide Vaghetti (GARR) |
Structure of the Architecture activity
...