AAI stands for Authentication and Authorisation Infrastructure. It is a set of software systems that help users to login to services easily. Like any good infrastructure, you should barely notice an AAI system, until it is not available.
Examples of common AAI use cases for research communities include:
It is not enough for an AAI to simply grant access - it must enable researchers to securely access trusted services, comply with required policies and experience minimal friction throughout the process. Without an AAI to connect services and researchers, each service may require its own separate account and authorisation process, frustrating users and reducing security and efficiency as identity management tasks are duplicated.
Research collaborations are typically federated; the researchers’ identities are managed by their home organisations (e.g. universities) but their authorisation in the research context is managed within the collaboration itself. The systems they use may be hosted by multiple institutes but should share a common access control mechanism. There are even scenarios where AAIs themselves must be federated, i.e. each AAI in a federation trusts the users and attributes released by the others. As a result of these requirements, research AAIs must support many workflows not commonly found in commercial systems that primarily serve single organisations. Over the years, the AARC community has developed best practices to support such scenarios.
Ideally, an AAI is one of the first systems established in a new research community, allowing other services to plug in directly and benefit from unified identity and access management from the outset. If your community missed that opportunity, the second-best time to adopt an AAI is now. Read on to learn from communities who have already navigated the challenges so you can avoid their mistakes and get your AAI running smoothly.
Certain research requirements are not supported by common commercial software (i.e. enterprise Identity and Access Management (IAM) systems or Single Sign-Ons) that you would use in a single-domain organisation. For example: globally federated access; verified membership management; token translation and compatibility with other research collaborations.