Introduction

From a technical point of view, DFN-AAI is a specific type of web-based single sign-on (web SSO). This procedure allows users to log in to internal and external services (authentication) with the user credentials with which they are registered at their home institution (usually user name and password) and - provided they have the appropriate authorizations (authorization) - to use these services. The infrastructure required for this, AAI (= Authentication and Authorization Infrastructure), is traditionally implemented within the framework of national Federations and is usually operated by the respective research networks. In the case of the Federal Republic of Germany, this is the DFN-Verein.

The technical basis for such infrastructures is the exchange of metadata, in which the identity providers (IdP) of the home organizations (educational and research institutions) participating in the AAI and the service providers (SP) of the participating service providers (content providers, e-learning platforms, scientific services, etc.) are registered. There are also external attribute sources, so-called attribute authorities, which an SP can use to retrieve additional, usually project-specific user data that is not maintained by the home institution. Such instances (IdP, SP, Attribute Authorities) are also referred to as entities. The information stored in the metadata includes both administrative (organization, contact data) and technical data (service endpoints, certificates, etc.) that are required for the entities to communicate with each other. SAML (Security Assertion Markup Language) has established itself as the standard across the board. The task of the respective federation is to maintain these data records, keep them up to date and ensure that a secure and trustworthy exchange of information takes place within the federation. The technical backbone of such a federation is therefore the metadata signed by the federation operator signed Metadata.

Further and more detailed information can be found on the page Weitere Informationsquellen and in this slideset.

A federation acts as a Trusted Third Party, which ensures compliance with the technical and legal framework conditions and thus establishes a relationship of trust. In this role, the federation operator (DFN) takes on various tasks:

• Contracts with all participating institutions and service providers, see under Registration
• Creating guidelines (policies) and monitoring compliance with them
• Operation of central localization services: Discovery services, also called “WAYF” (Where Are You From), see under Productive operation
• Metadata management
• Support for technical problems and questions related to AAI, see Contact
• Training for participating institutions and service providers (please send training requests to hotline@aai.dfn.de)

See also the presentation of the Dienstportfolios der DFN-AAI.

Within a federation, it is assumed that all participating institutions and service providers comply with common security standards in at least the following areas:

• Authentication and authorization of users,
• Access control to resources,
• Organizational and technical processes that are run through when a person is admitted to the institution, changes role within the institution or leaves the institution.

Providers of resources such as a commercial database are referred to as service providers in the AAI context. Service providers trust that the agreed license agreement will be adhered to. If a certain database is only available to students, for example, it is important that a person is no longer allowed to access this database after de-registration. If the license agreement states that only students of a certain subject may access the resource, these attributes (here: subject) must also be kept up to date and changed promptly in the event of a change of subject.

Institutions whose members want to use resources/services available within the AAI act as identity providers and are responsible for authentication and attribution. Identity providers are required to operate an identity management system, or at least a trustworthy user administration system with a consistent and up-to-date database. An identity management system does not have to be a commercial product; systems with automated processes that are implemented in open source software, for example, are considered equivalent. There must be common data schemas for the exchange of attributes. The mandatory and optional attributes to be used are documented at documented here.

A good introduction to the topic of identity management and AAI can be found in the Präsentation von Thorsten Michels (Uni Kaiserslautern).

The operation of an identity management system or at least a trustworthy user administration system in which identities are managed according to the following principles is a prerequisite:

• Persons who are admitted to an institution are assigned a digital identity.
• Identities are assigned attributes that correspond to the person's current role.
• If a person's role or authorizations are changed, the identity information is adjusted promptly.
• For people who leave the institution, the identity with all rights and roles is promptly deleted or changed (e.g. students → alumni).
• The common attribute schemas of the DFN-AAI must be supported.
• The resource provider (service provider) can rely on all changes being carried out promptly.
• The processes must be documented in writing to the extent that the security level can be derived from the documentation.

See also under Identity Assurance.

The motivation to create an AAI for the German university and research community goes back to the BMBF-funded AAR project (authentication, authorization and rights management), which started in 2005. The main aim of the project was to enable web SSO access to licensed electronic content (journals, databases, books, etc.), which offers significant advantages over conventional methods of access protection (IP control, VPN, proxies). In the fall of 2007, the DFN-AAI was put into regular operation and has since been available to DFN users as a so-called value-added service. Initially, the university libraries were the driving force behind the DFN-AAI, but other areas of application were quickly added: distribution of licensed software, internal university services (local SP) and various e-learning platforms. At the latest with the emergence of federated (i.e. AAI-capable) HPC, storage, communication (web conferencing) and campus services, university data centers also developed an interest in the operation of AAI-relevant components and local services. In recent years, various state projects and initiatives such as bwIDM, the Bavarian Virtual University (VHB), Nds-AAI, SaxID, Ministries of Education and Cultural Affairs and others have established themselves as additional players, each making their services available at state level. With international research networks and infrastructures that want to offer and use their services cross-federation (eduGAIN), the DFN-AAI has gained another important target group in recent years, whose needs pose new challenges for the traditional AAI. Examples include CLARIN (language resources), DARIAH (humanities), ELIXIR (life sciences) and LIGO (gravitational wave research).