IAM4NFDI Service Onboarding Handbook

IAM4NFDI IAM4NFDI - Service Onboarding Handbook Contents 1 Introduction .......................................................................................................................................... 2 2 Technical basics of the NFDI-AAI .......................................................................................................... 2 2.1 Architecture and protocols............................................................................................................ 3 2.2 Attributes ....................................................................................................................................... 4 2.3 Authorization ................................................................................................................................. 5 2.3.1 Virtual Organisation ............................................................................................................... 5 2.3.2 Resource capabilities .............................................................................................................. 6 2.3.3 Home-IdP based authorisation ............................................................................................... 6 2.3.4 Assurance based authorisation .............................................................................................. 6 2.4 Policies ........................................................................................................................................... 6 2.4.1 Incident Response .................................................................................................................. 7 2.5 Metadata management in the NFDI-AAI ....................................................................................... 7 2.5.1 Federations and Community AAIs .......................................................................................... 7 2.5.2 Community AAIs and associated services .............................................................................. 8 2.5.3 Community AAIs and infrastructure proxy ............................................................................. 8 2.5.4 Infrastructure proxy and services to be connected to it ........................................................ 8 2.6 Comparison of connection as a community service vs. NFDI infrastructure service .................... 8 2.6.1 Connection as a community service vs. NFDI infrastructure service: .................................... 8 2.6.2 Connection to one community vs. connection to several communities ................................ 9 3 Service integration................................................................................................................................ 9 3.1 General procedure for service integration .................................................................................... 9 3.2 Connection to the NFDI infrastructure proxy .............................................................................. 10 3.3 Connection to the community AAIs ............................................................................................ 10 3.3.1 AcademicID ........................................................................................................................... 11 3.3.2 didmos .................................................................................................................................. 11 3.3.3 Reg-APP ................................................................................................................................ 12 3.3.4 Unity ..................................................................................................................................... 12 4 Need Support with IAM4NFDI? .......................................................................................................... 12 Page 2/12 1 Introduction As part of the NFDI, an authentication and authorization infrastructure (“NFDI-AAI”) has been established, which is harmoniously integrated into the research federation (“DFNAAI”) operated by the DFN via corresponding standards. There are various options for providers of services in the context of data-driven research infrastructures to connect their services to this NFDI-AAI. This document serves as a source of information and a decision-making aid for these service providers. The NFDI-AAI is a hierarchical system in which not only the user administrations of individual NFDI consortia or individual so-called Virtual Organizations (VO), each of which belongs to an NFDI consortium, are integrated, but also central components, in particular the identity provider proxy DFN eduID and an NFDI infrastructure proxy for generic NFDI services. The first decision to be made for a service provider is based on the intended target group for the service: 1) should the service be available only to a single VO, 2) to an entire NFDI specialist consortium or 3) to all NFDI specialist consortia simultaneously. If 1.) or 2.) is the case, the service should be connected to one of the subject-specific CAAIs; if 3.) is the case, it should be integrated with the infra proxy. The following text first discusses the general technical basics, such as the architecture, attributes, authorization, policies, incident response, federation and finally the various levels at which a service can be integrated, namely the individual CAAIs and the infrastructure proxy. The second main chapter then deals explicitly with the service connection itself, again subdivided into the connection to the infrastructure proxy and the four different CAAI solutions (AcademicID, didmos, RegApp and Unity) in the sense of a practical guide. This document is only intended as an introduction to the topic; detailed technical instructions are maintained in the project documentation. Page 3/12 2 Technical basics of the NFDI-AAI 2.1 Architecture and protocols Figure 1: Architecture NFDI-AAI Page 4/12 The architecture of the NFDI CAAI essentially consists of the following two components: • CAAIs: Services that are to be available to individual specialist consortia or VOs are connected here. On the one hand, the consortia and communities can manage their members here. This saves having to do this process separately in each connected service. Secondly, the CAAIs have a proxy component that can be used to translate between different protocols, in particular SAML and OpenID Connect/OAuth2 (see below). • NFDI infrastructure proxy: Services that are aimed at several or all consortia are connected to this proxy, which reduces the technical requirements. It also makes it easier to manage people working in several consortia and to authorise the services. More details and information about the connected components that are outside the IAM4NFDI project can be found here: https://doc.nfdi-aai.de/architecture/. The SAML (Security Assertion Markup Language) and OIDC (OpenID Connect) protocols are used for secure and smooth integration with identity providers (IdP) and seamless authentication and authorization for applications. SAML enables a secure single sign-on, a network across different applications and platforms as well as the exchange of user authentication and authorization information in a standardized way and ensures smooth communication between services and IdPs. The OIDC protocol is an identity layer built on top of the 0Auth 2.0 framework. It extends the 0Auth 2.0 framework with an additional authentication protocol that allows third-party applications to verify the identity of end users and obtain basic user profile information. Information is exchanged between the client application and the OpenID Provider (OP) using JSON Web Tokens (JWTs). 2.2 Attributes The mandatory and optional attributes and claims that the proxy component of a community AAI transmits to the connected services and, if applicable, to the infrastructure proxy are documented in the current version of the NFDI Infrastructure Attribute Policy (IAP), see https://doc.nfdi-aai.de/policies/ and https://doc.nfdiaai.de/attributes/. Due to the current international activities (end of 2024), particularly in the AARC community, it can be assumed that the attribute lists listed in the above-mentioned policy document will have to be adapted again with the adoption of guideline G056: AARC Profile for expressing identity attributes in order to remain internationally compatible. In the context discussed here, those in Section 4 of the above-mentioned policy document, Community Attribute Profiles Attributes available from the Community AAIs, are relevant. Page 5/12 Services can generally expect the following user information to be transmitted by the CAAI: • Name(s) of the person concerned • e-mail address • Identifier, generated by o the identity provider of the home institution o the edu-ID system o the community AAI • Domain name of the home institution • Affiliation, i.e. information on the status of the person concerned within their home institution and/or community AAI (student, staff, member, etc.) • Assurance, i.e. information on the reliability of the information Optional information • Service/community-specific authorizations and group memberships • Other identifiers such as ORCID • Consent already given to Acceptable Use Policies and other terms of use or acknowledgement thereof If a service requires additional information, the relevant attributes/claims can be documented in a service access policy. The template required for this is linked at https://doc.nfdi-aai.de/policies/. 2.3 Authorization There are different opportunities to realize the authorisation. You can use virtual organisations, resource capabilities, home-idp based authorisation and assurance-based authorisation 2.3.1 Virtual Organisation In this authorisation type, services provide resources to Virtual Organisations. Membership is managed by the community itself, e.g. by VO administrators that add (or remove) users to their VO. The VO membership is transmitted via entitlements claims and the group keyword (see AARC-G069. This and the already registered VOs are defined at the Community AAI instances. Users can be organised in hierarchical (tree-topology) groups (i.e. VOs and sub-VOs). Example: “urn:geant:dfn.de:nfdi.de:<consortium>:group:<vo-name>:<sub-vo>#login.antmaster.de”, Page 6/12 2.3.2 Resource capabilities Some services or Communities require an additional authorisation structure, that shifts the authorisation decision away from the service towards the Community-AAI. Then, the Community AAI makes specific statements about what a user may do, e.g. whether or not to start VMs, or which datasets may be accessed. This information is also transmitted via the entitlements claim, but then using the res keyword (see AARC-G027). Example: "urn:geant:dfn.de:nfdi.de:<consortium>:res:ant-dataset-42:read#login.antmaster.de", "urn:geant:dfn.de:nfdi.de:<consortium>:res:start-vm#login.antmaster.de", 2.3.3 Home-IdP based authorisation Enables authorisation based on attributes that are administered by a Home-IdP. This includes what kind of status or affiliation a person has (e.g. student) or whether specific access legitimation was given to a user. Attributes and values used in this case need to be agreed upon between Identity Providers and Services. In addition, a Home-IdP may communicate entitlements such as VO membership or Resource capabilities. In order to prevent conflicting statements, this should be done in close collaboration between the administrators of Home-IdPs, Community-AAIs, VO Admins and Services. 2.3.4 Assurance based authorisation Assurance describes the quality of an identity. This enables to differentiate between specific quality levels of an identity. IdPs provide assurance information on the identity of the user, for example stating that a photo ID has been checked and/or that multi factor authentication is employed. This is expressed by the user’s Home organisation and forwarded within the AAI. If the organisation provides only the assurance information but not the fulfilled profiles, the AAI adds the profile information. The REFEDS Assurance Framework (RAF) defines individual assurance components that describe a users identity. This allows for differentiation between the quality of the IDVetting, the attribute freshness and the uniqueness of the identifiers used. 2.4 Policies The NFDI-AAI Policy Framework addresses organizational, legal and technical aspects of the operation of Community AAIs and their superordinate infrastructure, concerning • the management of Virtual Organizations (VOs) o Top Level Policy o VO Membership Management Policy (VOMMP) Page 7/12 o VO Lifecycle Policy • attribute/claim profiles - Infrastructure Attribute Policy (IAP), see above, section 'Attributes' • data protection - Policy on Processing of Personal Data (PPPD), mandatory for all participants and service operators, in addition to this o Templates for data protection notices and procedure directories • security Incident Response Procedure (SIRP), mandatory for all participants and service operators • acceptable Use Policies (AUPs) o Templates for VOs, CAAIs and services While the assignment of a service to one or more Community AAIs generally does not require a separate decision-making process, there may be several Virtual Organizations (VOs) to choose from in the context of the Community AAI(s). In particular, an assignment can be made based on the information from the relevant VO lifecycle policies and the associated AUPs. Service-specific features, such as special attributes/claims not covered by the IAP or special authorizations, can be documented in an optional Service Access Policy (SAP). If the higher-level AUPs are not considered sufficient, they can be supplemented with additional, service-specific conditions using a Service Acceptable Use Policy template. In any case, the provision of data protection information for the use of the respective service is mandatory. There are templates in German and English for this purpose. 2.4.1 Incident Response Compliance with the Security Incident Response Procedure (SIRP) is mandatory for all participants in the NFDI-AAI. This policy document is based on the AARC guideline AARCI051 Guide to Federated Security Incident Response for Research Collaboration, which in turn further specifies the communication processes for security incidents defined in the Security Incident Response Trust Framework for Federated Identity (Sirtfi). In this respect, compliance with the Sirtfi framework must also be ensured for the relevant service and service operator. One of the most important points here is the provision of a security contact, ideally a functional email address, which must be entered in the SAML metadata of the relevant service provider (if available) and subscribed to the [email protected] mailing list. 2.5 Metadata management in the NFDI-AAI In this context,the term metadata refers to the technical and organisational information provided in a standardised syntax that is necessary for IdPs and SPs to be able to communicate with each other. Due to the different levels of the NFDI-AAI architecture, metadata management takes place in different places: 2.5.1 Federations and Community AAIs Ideally, the edu-ID system is used as an interface between the home IdPs from eduGAIN/DFN-AAI and the community AAIs. This is the only way to ensure that users Page 8/12 can be uniquely identified throughout their academic life and across the various community AAIs. In this respect, the service provider components of the Community-AAI proxies must be registered like normal service providers in the “edu-ID” federation. This is done via the administration interface of the DFN-AAI metadata administration. Details on edu-ID onboarding are documented at https://doku.tid.dfn.de/de:aai:eduid:spconfig. 2.5.2 Community AAIs and associated services See the relevant subsection of “Connection to the Community AAIs”. 2.5.3 Community AAIs and infrastructure proxy The “NFDI” federation, which is also managed via the DFN-AAI metadata administration, exists to connect the identity provider components of the community AAI proxies and the service provider component of the infrastructure proxy. The URL of this NFDI federation metadata is: https://www.aai.dfn.de/metadata/dfn-aai-nfdi-metadata.xml The certificate for signature validation of this metadata is the same as that provided for the DFN-AAI federation metadata, see https://doku.tid.dfn.de/de:metadata. The attributes of the currently valid attribute profile (see above, Attributes) must be released for the SP component of the infrastructure proxy with the entity ID https://infraproxy.nfdi-aai.dfn.de/idp/shibboleth. 2.5.4 Infrastructure proxy and services to be connected to it As mixed operation of SAML and OpenID Connect/OAuth2-capable services is expected here, the connection is currently (end of 2024) still direct and manual. 2.6 Comparison of connection as a community service vs. NFDI infrastructure service 2.6.1 Connection as a community service vs. NFDI infrastructure service: Connection as a community service • Advantages: o Simple connection to a community o Fast implementation o Flexibility in configuration o Chargeable • Disadvantages o Dependence on the community o Any changes to the community interface can lead to problems o No guarantee for the availability and reliability of the community interface Connection to an NFDI infrastructure service Page 9/12 • Advantages: o Standardized interface for all NFDI infrastructures o Guarantee for the availability and reliability of the interface o Simple scalability and maintenance o Cost-neutral • Disadvantages: o More complex implementation o Dependence on the NFDI infrastructure o Any changes to the NFDI interface can lead to problems 2.6.2 Connection to one community vs. connection to several communities When connecting a service to federated identity or authorisation infrastructures, the question arises as to whether a single community or several communities should be integrated. Both approaches have different requirements, advantages and challenges, which are compared below. Connection to one community Connecting to just one community is usually simple and straightforward. As only one interface needs to be integrated, the implementation can usually be realised quickly. This approach also allows a high degree of flexibility in configuration, as the requirements and framework conditions of the selected community can be specifically addressed. However, it should be noted that this approach can be costly - for example, due to licence costs or fees for support and integration. Connection to multiple communities In contrast, connecting to multiple communities involves a significantly more complex implementation. Different interfaces, protocols and authorisation concepts must be taken into account and coordinated. This also results in a dependency on several external partners, which can increase the maintenance effort. It can be particularly problematic if changes are made to the interfaces of individual communities - such adjustments must then be taken into account by the system. On the other hand, this approach is often cost-neutral as long as no commercial services or additional services are required. 3 Service integration 3.1 General procedure for service integration The SAML2.0 or OpenID Connect (OIDC) protocols can be used to connect a service to the NFDI-AAI. All community AAIs and the NFDI infrastructure proxy support the connection via these two SSO protocols. Due to the architecture of the NFDI AAI, the community AAIs and the infrastructure proxy are each individual IdPs that hide the complexity of the federation world. It is therefore sufficient if a service to be connected