JRA1.4 Models for implementing Attribute Providers and Token Translation Services Andrea Biancini

JRA1.4 Main activities - 1/2 1.AAs for authorisation: ○Compare different existing technologies to implement AAs, for instance: Grouper/COmanage, Perun, Hexxa, VOMS-SAML ○Assess the existing AA in federated environments and identify the missing features in respect with the guidelines for AAs developed within EGI ○Model and identify possible solutions to overtake existing technical limitations 2.Token Translation Services: ○Investigate different existing solutions for TTS, for instance: TCS (to release user certificates after a federated login) and the use of Science Gateways (to broker the access to different services), OpenID-SAML gateway. ○Open the investigation to new schemas used in different contexts (like OAuth2 used in the social world).

JRA1.4 Main activities - 2/2 3.Provide a blueprint architecture document, including: ○Comparison of different technical solutions (with strengths and weaknesses) to integrate different communities in existing federations ○Guidelines about how to manage authorisation leveraging AAs ○Opportunities and critical aspects in using TTS 4.Follow-up and support the PoC and piloting activities to prove designed architectures.

Advancement ●To facilitate the creation of a shared vision we concentrate on creating a common understanding of the architectural elements. ●For this reason two documents has collaboratively been created: o “Information flows for AAs” with the intent to describe the possible flows and high level use cases of user interactions involving Attribute Authorities. o “Terms and definitions” with the intent to describe the main terms and concepts regarding AAI to be shared among all participants.

Next Steps ●Define a TOC for the blueprint document. This document is intended to suppot the goals and objectives of the AARC projects in different ways: o Call objective 3: Overcome technical, organisational and legal obstacles for the implementation of an integrated and interoperable authentication and authorisation infrastructure. o Call objective 4: Enable the interoperability of different AAIs by researching the use of security token translation services and accounting services. ●KPI defined for the activity: Number of models for implementing attribute providers and token translation services. (Target: 3)

Blueprint TOC - Sections 1.Introduction and existing work. This section will define the context of current AAI and will give some general information about the current AAI systems supporting different communities and projects. 2.Proposed concept and architecture. This section will describe the main concept about the attribute management tool subject of this deliverable. 3.Adaptation to existing use-cases. This section will test the solution described in the document and describe how it will simplify existing user interactions. Starting from real use cases, this section will prove the efficacy of the architecture described in regards to user experience. 4.Benefits, problems and conclusions. This section will offer a conclusion showing benefits and problems of the solution proposed. It will also draw some conclusion and eventually identify possible directions for future works.

How to move forward ●Common revision of this TOC ( Comments, suggestions, corrections are REALLY WELCOME! ●Definition of participants and people engaged with the task. ●Parallel work on the different sections of this document.

Major terms agreed – 1/3 ●Identity Federation: A collection of organisations that agree to interoperate under a certain rule, a federation policy, set to authenticate and authorize users. Federations are usually circles of trust in which the different organisations agree to trust the Identity Management of the others belonging to the same federation. ●Virtual Organisation (VO): A Virtual Organisation (VO) describes an organisational entity. This entity represents a group of users that want to collaboratively use resources for a common purpose. Before entering a VO a user may be requested users to sign its “Acceptable use Policy” (AUP). Acceptance of a user to enter the VO, or membership, may be subject to approval based on various criteria.

Major terms agreed – 2/3 ●Identity Provider: An Identity Provider (IdP), also known as Identity Assertion Provider, is responsible for (a) providing identifiers for subjects looking to interact with a system, and (b) asserting to such a system that the identifier presented by a user is known to the provider. ●Attribute Authority: An Attribute Authority (AA) is the party responsible for managing the binding between subjects and attributes. As we have seen before, many IdPs operate as AA after authentication to release information about the logged in user. There are also generic AAs that usually are not operating any authentication but are only providing attributes of the user’s digital identity obtained from a different authenticating IdP.

Major terms agreed – 3/3 ●Attribute Aggregation: Attribute Aggregation is the process that permits a Service Provider to retrieve different attributes from different IdPs or AAs and aggregate them in a consistent way to build a coherent digital identity for the user. In general we can have different models to aggregate the attributes: ○Mesh: in which each service itself contacts relevant IdPs and AAs and collects attributes for the user. ○Proxy: in which a single entity, a proxy, collects attributes at relevant sources on behalf of the services, and then passes the combined set towards the actual service. ○Mesh with proxies: in this case the aggregation happens in a meshed way but some of the entities (either IdPs or SPs) operates as proxies.