...
| Tip | ||
|---|---|---|
| ||
The purpose of the AARC Blueprint Architecture (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. |
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
AARC1 Documents – Shouldn't we move the old stuff to the bottom?
| ID | Title | Summary | Links | Status | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| AARC-JRA1.4A | Guidelines on expressing group membership and role information | Information about the groups a user is a member of is commonly used by SPs to authorise user access to protected resources. Apart from the group information that is managed by the user’s home IdP, research communities usually operate their own group managing services. Such services often act as Attribute Authorities, maintaining additional information about the users, including VO membership, group membership within VOs, as well as user roles. It is therefore necessary that all involved SPs and IdPs/AAs can interpret this information in a uniform way. Specifically, the following challenges are addressed by this document:
| AARC-JRA1.4A (201710) [PDF] Older versions AARC-JRA1.4A (1.0) [PDF] |
| ||||||
| AARC-JRA1.4B | Guidelines on attribute aggregation |
| ||||||||
| AARC-JRA1.4C | Guidelines on token translation services |
| ||||||||
| AARC-JRA1.4D | Guidelines on credential delegation |
| ||||||||
AARC-JRA1.4E | Best practices for managing authorisation |
| ||||||||
| AARC-JRA1.4F | Guidelines on non-browser access |
| ||||||||
| AARC-JRA1.4G | Guidelines for implementing SAML authentication proxies for social media identity providers |
| ||||||||
| AARC-JRA1.4H | Account linking and LoA elevation use cases and common practices for international research collaboration |
| ||||||||
| AARC-JRA1.4I | Best practices and recommendations for attribute translation from federated authentication to X.509 credentials |
|
AARC2 Documents
Deliverables
| ID | Title | Summary | Links | Status | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AARC2-DRJA1.1 | ||||||||||||||||||
| Authorisation Models for SPs | This deliverable describes possible authorisation models for SAML-SPs and OIDC-RPs in a proxied environment. We provide an overview about available and upcoming technologies currently in use or development for community and research infrastructures. Input is taken from the AARC pilots, such as the pilot for the Life Science AAI, experiences at WLCGCERN with VOMS as well as their current move towards token based approaches, and further examples from the federated research infrastructure / research community space. These user-community views are complemented by the experience of the first year of the AARC2 project, in which different levels of assurance, LoA step-up, account linking and various authorisation models have been analysed. |
Due: |
Documents
...