• Home
• Activities
• AA-RR

Introduction

AA-RR (Authentication and Authorization Requester-Responder) is a tool conceived to help in the validation of the interoperability of a certain AA component with other(s). The main purpose is to have an easy way of describing different AA components and all possible forms of interoperability between them, and a good set of tests to check this interoperability. Its main goals are:

• Easier interoperability efforts: it is easier not to test against infrastructures in use, or avoid the requirement for installing additional software just for testing.
• A coherent collection of profile data, applicable not only to different pieces of software but to whole infrastructures.
• Simpler (con-)federation mechanisms, since requirements on syntax and semantics can be published and shared in a normalized way.

The system is built according to the following assumptions:

• AA interactions are based on the (trusted) exchange of properties (that we'll call attributes) about users, either humans or applications, and resources.
• There is a common consensus in using open standards to guide AA interactions, not only in the middleware NREN community, but also in the Grid community and the industry.
• Any standard leaves much open issues, so different profles can be applicable to accomplish a certain task.

The AA-RR will be able to use specific definitions to simulate the external behavior of different components of several infrastructures in order to assess the interoperability of a certain element with them. This implies that the AA-RR can be used to learn of those elements it connects to, enhancing its knowledge base. There are three types of components that the AA-RR will be able to impersonate, each one corresponding to one of the components in a general AA architecture:

• Attribute sources (like a Shibboleth AA, a A-Select server, a PAPI AAAS, or an Athens XAP). These are, esentially, entities able to accept attribute queries from attribute requesters (entities of the second type), validate the queries according to their privacy-protection rules, and respond with attribute information.
• Attribute requesters (like a Shibboleth SHAR, a VOMS server, a PAPI PoA, or a Athens DSP entry point). These entities perform requests about user attributes to attribute sources (entities of the first type) and make an authorisation decision on them, possibly querying an authorisation engine (an entity of the third type).
• Authorization engines (like Permis or SPCOP). These entities make decisions from the requests they receive from attribute requesters (entities of the second type) and their internal configuration. They return a simple (yes/no) or complex (for example, a SPOCP "blob") answer to the query.

The broad application fields to which AA interactions are aimed implies a diverse variety of potential protocols to be used, specially if we take into account that currently none of the proposed standards is clearly dominant over the others. Therefore, the AA-RR will be built using a protocol-agnostic approach, providing a neutral format for defining its behaviour, and using open libraries to implement protocol bindings.