Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Attribute Authorities (AAs) play one of the most critical security roles in the infrastructure. The data they issue and information they assert must be highly trusted by the parties relying upon it. To that end, AARC recommends that certain practices be adopted by the operators of such services: AARC-G071 Guidelines for Secure Operation of Attribute Authorities. The requirements listed include best practices in encryption, hosting environments, logging and attribute management to name but a few. 

Collaborations can either host their own AA, or - more commonly - engage the services of an AA operator or an AAI platform to host their collaboration structure. In this latter case, most of the onus of securing and operating the AA falls on the operator, and implementing the AA service is part of the Snctfi requirements.

For the AA platform operator and those collaborations hosting their own service, to

Authentication sources and Collaboration Management should abide by the minimum requirements and recommendations for the secure operation of Attribute Authorities [see Resources], and similar services providing statements for obtaining access to Infrastructure services.

To make safe authorisation decisions, Relying Parties need to be able to identify and trust the issuer or provider of an attribute assertion, and know to which Collaboration it pertains. In a typical scenario, a Collaboration designates one or more AA Operators to operate AAs, and informs Relying Parties of any related metadata necessary for Relying Parties to connect to or use the AA. The attributes are securely held by the AA and delivered on request to authorised Relying Parties, either directly or by way of the user. Authentication sources and Collaboration Management should abide by the minimum requirements and recommendations for the secure operation of Attribute Authorities [see AARC-G071 Resources], and similar services providing statements for obtaining access to Infrastructure services.

These attributes may be aggregated with identity assertions, such as delivered from a directory or group management system, or with attribute or capability tokens as asserted by an AARC BPA Proxy.

Stated compliance with these the AAOPS guidelines may help to establish trust between the Community and Collaboration and its AA, and Relying Parties. In the interest of scalability, these guidelines are intended to facilitate to facilitate the assessment of AA Operators rather than individual AAs or CommunitiesCollaborations. This document The document does not provide guidance on the management (life cycle, technical implementationtechnical implementation, exchange protocols etc.) of attributes nor the processes by which attributes are attributes are entered into the AA.

...

How should I adopt AARC-G071?

In AARC-G071 Guidelines for Secure Operation of Attribute Authorities the requirements are included in purple boxes, with additional information included around it. Importantly a distinction is made between "pull" and "push" attribute assertion. 

  • attribute authorities that permit binding of properties to entities by means of lookup in which the entity whose properties are sought is the key in the look-up (‘pull model’)
  • attribute authorities that issue (usually integrity-protected and, optionally, confidentiality-protected) statements in which attributes are asserted (‘push model’)

If you are running your own AAI should go through each requirement and analyse if your infrastructure supports it. In many cases, Research Communities choose to outsource their AAI to a trusted operator who should also support these requirements.

Recommendations:

  • AA Operators should abide by the requirements of AARC-G071, to attain and maintain the trust of their relying parties.

Resources