Page tree


Deliverable JRA1.4-1:
Flows for Attribute Authorities

Deliverable JRA1.4-1

Contractual Date:


Actual Date:


Grant Agreement No.:


Work Package:


Task Item:


Lead Partner:

Consortium GARR

Document Code:

Andrea Biancini, Michal Prochazka, Niels Van Dijk

Document Code (Word):




© GÉANT on behalf of the AARC project.

The research leading to these results has received funding from the European Community’s Horizon2020 Programme under Grant Agreement No. 653965 (AARC).


This is a working document which will intend to describe the possible flows and high level use cases of user interactions involving Attribute Authorities. It is intended to be an outline/draft for people to work on and will provide input to a one pager describing the main terms and concepts regarding AAs to be shared among all participants.

Document Revision History

<This section to be deleted or hidden before publication of document>



Description of change




Initial outline (draft)

A. Biancini



Added asynchronous attributes

M. Prochazka



Added mesh and proxy

N. Van Djik



Shared with the community







Executive Summary

AARC JRA1 Task 1.4: Models for implementing attribute providers and token translation service

Flows for AAs


This is a working document which will intend to describe the possible flows and high level use cases of user interactions involving Attribute Authorities. It is intended to be an outline/draft for people to work on and will provide input to a one pager describing the main terms and concepts regarding AAs to be shared among all participants.


Task/Document/Deliverable Participants: GRNET (2), EGI (3), PSNC (3), KIT (1), DAASI (3), GAAR (3) , STFC (1.5), JUELICH (2), CESNET (3)


1                        Flows for AAs

In authentication and authorization systems, attribute authorities are entities which are able to provide attributes to a user identity describing some characteristics of the user after his identification.


Since the very general definition, AAs can assolve different goals and provide different kinds of attributes. In the following of this working document, the main flows where attributes and AAs are involved in AAI systems are presented.


The document will try to be as technology agnostic as possible not to bind any specific flow or process to a given technology.

1.1                Attributes provided at login

When a user interacts with an AAI system to authenticate, he may end up with a set of attributes related to the user and collected by the system that provides the authentication assertion. Some of these attributes may be required to prove the actual authentication of the user and can store some information about him.


In this sense the role of the AA providing such attributes, is mixed with the role of authenticating the user and the two processes can difficulty being separated. Examples of this flows are represented by all IdPs in eduGAIN. Every IdP, after authentication, may provide the user with some attribute (usually at least one attribute needs to be released for a proper authentication at the SP’s web server end).


From a procedural point of view, it is important to notice that in this case the AA releasing attributes will be operated by the same organization or institution performing the authentication (in fact AA and authenticating systems will coincide).


There are quite some IdPs that only authenticate and do not provide any attributes to the service. In this case, the user identity must be deduced from an identifier of the subject (in the SAML world this id is called NameId), leaving it a provisioning / background  task, de-coupled from authentication, to provide the attributes to the service.

1.2                Attributes provided for authorization

A different case is when an AA is used to provide additional information to a user identity for authorization purposes. In this case, after login a AA is contacted to obtain additional information to be used for user authorization to the service.


Common examples of this flow are represented by group management systems providing group memberships for users. In this case the AAI process, after having logged the user in, will contact a AA providing membership information or other additional attributes that can be used for authorization.


From a procedural point of view it is important to notice that such an AA can either be operated by the same organization performing the authentication; by the same organization providing the service; or by a third organization different from the first two. Usually, however, it is possible to think that the three organizations outlined will be part of the same community.

1.3                Additional attributes provided within a community

Another flow, similar to the previous one, is the one in which the AA is used to enrich user’s digital identity. Also in this case, as in the previous, after login the AA is contacted to obtain additional information. This time, however, the additional information obtained will not necessarily be relevant for authorization but could be of any kind.


Common examples of this flow are represented by an AA created within a community to provide additional information to its users. In this case the users will authenticate to the systems of their organization, and after login the AA will be contacted to obtain more information pertaining their participation to the community.


From a procedural point of view it is important to notice that such an AA will quite for sure operated at a community level so not by the organization performing the authentication and neither by the same organization providing the service. The community by itself, or some organization operating on its behalf, will provide this AA.

1.4                Additional attributes provided for general purpose

Probably the more generic and complex flow, is the one in which the AA will provide additional attributes to users for general purposes. In this case the AA is contacted after authentication the user with its organizational system. The attributes provided by the AA, however, are not specific to the authorization within a specific application or to the role within a specific community. They will be general purpose and thus could be used by different services in different ways.


An example of this flow could be a system in which authentication is performed by a central (maybe governmental) system. After this login activities we can imagine to have different AAs providing different attributes:

      AAs operated by universities describing the graduation subject and year of the user;

      AAs operated by research institution describing affiliations of the user;

      AAs operated by projects or communities describing the participation of the user;

      AA operated by ORCID describing the user's ORCID identifier;



From a procedural point of view, this flow is the more general because it permits to enrich user identity with additional information retrieved, potentially, from different (and numerous) AAs. These AAs, then, will be operated by different organizations and so, together with the adequate trust level, also privacy and security aspects need to be considered very thoroughly.

1.5                Asynchronously provided attributes

Some services, especially those used for collaboration, need to know information about the users in advance (e.g. mail), before user logs into the system for the first time. Some other services need to check users information regularly or even be notified by the AA that there is a change. AA should provide such possibility. In this case, technical mechanisms must be put in place to deny services to get information they actually don’t need, or they are not entitled to get at all. One of these mechanisms could leverage a delegation mechanism for authorization so that the IdP authenticating the user can delegate, in a secure way, to the service (or to the SP) the possibility to retrieve information about the logged-in user from the AA.


From a procedural point of view, this flow requires very strict access control on data provided by AA to the services, because there is no explicit binding with the user authentication. Privacy issues are also very important because of exchanging user's data in the background, users must be able to revoke that permission.

1.6                Mesh and proxy flows

In all of the above flows, a service needs to learn about both the authentication as well as the set(s) of attributes. Two models exist to aggregate the attributes:

1)      "Mesh": Each and every Service itself contacts relevant AAs and collects attributes for the user. For this to work, a certain amount of negotiation needs to take place to establish technical connections and trust. This model works well in scenarios where there is little trust between entities, and it has excellent ways of preserving privacy. The cost of this is added complexity as now multiple technical and trust relations need to be maintained between multiple parties.

2)      "Proxy": A single entity, a proxy, collects attributes at relevant sources on behalf of the Services, then passes the combined set towards the Service. For this to work a central entity must be operated and both services as well as Identity providers need to trust the operator of the entity. In VO scenarios, it would be feasible for the VO to operate the proxy. The proxy takes away a lot of the complexity as now the number of interactions on the technical and trust level are reduced to connecting to the central proxy for all entities. This approach, however, may bring in some concerns about privacy. In fact the information about the user (conceptually exchanged between an IdP or an AA and the SP or service the user is accessing) in this case transit and is managed also by the Proxy, being a different third party component in the architecture. So this approach can be implemented only in the cases in which there is a significant trust on the entity operating the proxy.
Theoretically the technical scalability of a proxy model is less as compared to the mesh model. However, given the size of current communities and the state of technology, this is not a problem (e.g Hub for SURFconext federation takes care of ~ 200K logins/day from ~100K users, significantly more than what would be needed for most VOs).


SP Service Provider. The system component that evaluates the Digital Identity of an accessing Subject for controlling access to protected Services.

IdP 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. The IdP will ensure proper authentication of the subject and then can provide other information about the authenticated  in the form of attributes.


AA An Attribute Authority (AA) is the part 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. It is, instead, not true the opposite: generic AAs usually are not operating any authentication but they are only providing attributes of the user’s digital identity obtained from a different authenticating IdP.