Concepts

The Helmholtz ID is organised in Virtual Organisations (VOs), and based on the Proxy Concept introduced by the AARC Blueprint.

The Virtual Organisation (VO) Concept

Virtual Organisations (i.e. research groups) are the key element of authorisation in the Helmholtz Cloud.

The classical Virtual Organisation (VO) concept applies to High-Performance-Computing (HPC) but also to the grid world (distributed computing on different systems):

• Each VO consists of a number of users.
• A VO is supported by an arbitrary number of services, that for example can be used for collaboration, grant access to computing infrastructure and much more.
• VOs are managed by VO administrators (aka Principal Investigators). Administrators of Virtual Organisations are responsible for services in their VO (e.g. by writing proposals for HPC computing time, or by otherwise obtaining quotas on specific pieces of infrastructure).
• VO administrators are also responsible for managing the VO’s members by means of the Group Management interface of Helmholtz ID

In Helmholtz ID we maintain a List of VOs that indicates each VO’s contact and the assurance level required to join.

Further information about the VO concept, can be found here.

The SP-IdP-Proxy Concept

The Helmholtz AAI is modular in the sense that it involves one SP-IdP proxy and optionally site-local proxies.

According to the AARC Blueprint, an SP-IdP proxy is a software stack which can be used for hierarchical organisation of an Authentication and Authorisation Infrastructure (AAI). The SP-IdP Proxy addresses three common challenges in this field:

1. With growing numbers of SPs and IdPs it becomes very difficult to maintain a consistent attribute release from each IdP to every SP. The Proxy reduces this n:m mapping to a n:1:m mapping.
2. Some authorisation attributes can not be maintained at home IdPs. For example, group membership needs to be managed by the head of a group and not by administrative personnel operating a home IdP.
   • Some authentication patterns, in which access to individual datasets is required, may be supported by specialised SP-IdP-Proxy implementations.
3. Additionally, a proxy, once in place, allows translation between different AAI protocols. At this moment, proxies can enable smooth interoperation between X.509 certificates, SAML and OpenID Connect.

A typical use case would be, for example, if a service is not able to directly address SAML- or OpenID Connect-federated Identity Providers. In such case, a so-called SP-IdP proxy can mediate the services native protocol on the one end, and handle the complexity of a federation on the other end. This is achieved by offering the services suitable SSO access points, and by acting as a service provider to the federation, redirecting authentication towards the central login proxy or in some cases forwarding the users to their home IdPs for authentication.

Central and distributed proxies

Advanced configurations allow hierarchical interconnections between multiple proxies (as illustrated in this article). The top of such a hierarchy is a community AAI, which can support services directly, just as it can support infrastructure proxies, that have additional services connected to it. For a given community, there is one (central) software stack implementing the SP-IdP-Proxy for the community (which is why it is also called “Community-AAI”).

The central Community AAI in Helmholtz AAI is based on Unity, operated by FZJ, which serves as the primary login authority and group management platform.

Additional “Infrastructure Proxies” are operated at various sites as a central gate for accessing services at centres infrastructure. For example FELS at KIT (based on own developed Reg-App) or DESY Keycloak.

Unity, Reg-App (and in many cases also other SP-IdP Proxies / software stacks) provide first-class support for the OIDC and SAML protocols. They can connect SAML Identity Providers, OIDC Providers, SAML Service Providers and OIDC Relying Parties, thus enabling teams to use their preferred identity sources and services, regardless of the authentication protocol.

The services and Identity Providers shown in the diagram are only examples.

Discovery services

The Proxies are responsible for aggregating the user attributes from various identity sources, enforcing community and platform wide policies and providing one persistent user identifier and a harmonised set of attributes to the connected services. The discovery services provide a web interface for users to search and select their preferred identity provider.

The discovery services are integrated with the proxies and enable them to operate with all identity providers supported in the same way. For this they aggregate the metadata of all the SAML Identity and Service Providers that are connected to the platform. This is done by aggregating the metadata feed of eduGAIN, while allowing the platform administrators to also configure other local or remote metadata sources, like social providers. The meta data service is an essential component of the platform directly connected to the proxies.

Using the SAML protocol, basic information about the Service Provider or
Identiy Provider are exposed in the metadata of the provider. This metadata can be used for a simplified connection between Service Prodvider and Identity Provider. For the integration of multiple Service Provider and Identity Provider at the same time, the metadata of all providers can be aggregated in the federation metadata. This is a list which contains all the metadata from participating providers. Such federations are typically build the the Nation Research & Education Networks (NREN), like DFN. Since research and colaboration do not stop at national borders, the eduGAIN service. This service collects the federation metadta from all participating NRENs and provide additional federation metadata for all NRENs, which contains providers from the other countries.

The Identity Assurance Concept

The REFEDS Assurance Framework (RAF) defines individual assurance components that describe a users identity. This allows for differentiation between the quality of the ID-Vetting, the attribute freshness and the uniqueness of the identifiers used. Based on this information, services know how reliable the information about an user are. Accounts, having more reliable information, may have more premissions, than accounts with a low reliability.

Since today none of the existing IdPs support RAF, the idea is to do this on the proxy level. I.e. Helmholtz ID will convey information about the upstream authentication of the user. This is hard coded configuration that contains a priori knowledge about the upstream IdP and its procedures. For example will this allow us to characterise the upstream authentication and# Concepts

The Helmholtz ID is organised in Virtual Organisations (VOs), and based on the Proxy Concept introduced by the AARC Blueprint.

The Virtual Organisation (VO) Concept

Virtual Organisations (i.e. research groups) are the key element of authorisation in the Helmholtz Cloud.

The classical Virtual Organisation (VO) concept applies to High-Performance-Computing (HPC) but also to the grid world (distributed computing on different systems):

• Each VO consists of a number of users.
• A VO is supported by an arbitrary number of services, that for example can be used for collaboration, grant access to computing infrastructure and much more.
• VOs are managed by VO administrators (aka Principal Investigators). Administrators of Virtual Organisations are responsible for services in their VO (e.g. by writing proposals for HPC computing time, or by otherwise obtaining quotas on specific pieces of infrastructure).
• VO administrators are also responsible for managing the VO’s members by means of the Group Management interface of Helmholtz ID

In Helmholtz ID we maintain a List of VOs that indicates each VO’s contact and the assurance level required to join.

Further information about the VO concept, can be found here.

The SP-IdP-Proxy Concept

The Helmholtz AAI is modular in the sense that it involves one SP-IdP proxy and optionally site-local proxies.

According to the AARC Blueprint, an SP-IdP proxy is a software stack which can be used for hierarchical organisation of an Authentication and Authorisation Infrastructure (AAI). The SP-IdP Proxy addresses three common challenges in this field:

1. With growing numbers of SPs and IdPs it becomes very difficult to maintain a consistent attribute release from each IdP to every SP. The Proxy reduces this n:m mapping to a n:1:m mapping.
2. Some authorisation attributes can not be maintained at home IdPs. For example, group membership needs to be managed by the head of a group and not by administrative personnel operating a home IdP.
   • Some authentication patterns, in which access to individual datasets is required, may be supported by specialised SP-IdP-Proxy implementations.
3. Additionally, a proxy, once in place, allows translation between different AAI protocols. At this moment, proxies can enable smooth interoperation between X.509 certificates, SAML and OpenID Connect.

A typical use case would be, for example, if a service is not able to directly address SAML- or OpenID Connect-federated Identity Providers. In such case, a so-called SP-IdP proxy can mediate the services native protocol on the one end, and handle the complexity of a federation on the other end. This is achieved by offering the services suitable SSO access points, and by acting as a service provider to the federation, redirecting authentication towards the central login proxy or in some cases forwarding the users to their home IdPs for authentication.

Central and distributed proxies

Advanced configurations allow hierarchical interconnections between multiple proxies (as illustrated in this article). The top of such a hierarchy is a community AAI, which can support services directly, just as it can support infrastructure proxies, that have additional services connected to it. For a given community, there is one (central) software stack implementing the SP-IdP-Proxy for the community (which is why it is also called “Community-AAI”).

The central Community AAI in Helmholtz AAI is based on Unity, operated by FZJ, which serves as the primary login authority and group management platform.

Additional “Infrastructure Proxies” are operated at various sites as a central gate for accessing services at centres infrastructure. For example FELS at KIT (based on own developed Reg-App) or DESY Keycloak.

Unity, Reg-App (and in many cases also other SP-IdP Proxies / software stacks) provide first-class support for the OIDC and SAML protocols. They can connect SAML Identity Providers, OIDC Providers, SAML Service Providers and OIDC Relying Parties, thus enabling teams to use their preferred identity sources and services, regardless of the authentication protocol.

The services and Identity Providers shown in the diagram are only examples.

Discovery services

The Proxies are responsible for aggregating the user attributes from various identity sources, enforcing community and platform wide policies and providing one persistent user identifier and a harmonised set of attributes to the connected services. The discovery services provide a web interface for users to search and select their preferred identity provider.

The discovery services are integrated with the proxies and enable them to operate with all identity providers supported in the same way. For this they aggregate the metadata of all the SAML Identity and Service Providers that are connected to the platform. This is done by aggregating the metadata feed of eduGAIN, while allowing the platform administrators to also configure other local or remote metadata sources, like social providers. The meta data service is an essential component of the platform directly connected to the proxies.

Using the SAML protocol, basic information about the Service Provider or
Identity Provider are exposed in the metadata of the provider. This metadata can be used for a simplified connection between Service Provider and Identity Provider. For the integration of multiple Service Provider and Identity Provider at the same time, the metadata of all providers can be aggregated in the federation metadata. This is a list which contains all the metadata from participating providers. Such federations are typically build the the Nation Research & Education Networks (NREN), like DFN. Since research and collaboration do not stop at national borders, the eduGAIN service. This service collects the federation metadata from all participating NRENs and provide additional federation metadata for all NRENs, which contains providers from the other countries.

The Identity Assurance Concept

The REFEDS Assurance Framework (RAF) defines individual assurance components that describe a users identity. This allows for differentiation between the quality of the ID-Vetting, the attribute freshness and the uniqueness of the identifiers used. Based on this information, services know how reliable the information about an user are. Accounts, having more reliable information, may have more premissions, than accounts with a low reliability.

Since today none of the existing IdPs support RAF, the idea is to do this on the proxy level. I.e. Helmholtz ID will convey information about the upstream authentication of the user. This is hard coded configuration that contains a priori knowledge about the upstream IdP and its procedures. For example will this allow us to characterise the upstream authentication and differentiate between ORCID users and those from (for example) KIT.

Currently defined are:

• ID-Uniqueness:

  • $PREFIX$/ID/unique
  • $PREFIX$/ID/no-eppn-reassign
  • $PREFIX$/ID/eppn-reassign-1y

• ID-Proofing:

  • $PREFIX$/IAP/low
  • $PREFIX$/IAP/medium
  • $PREFIX$/IAP/high
  • $PREFIX$/IAP/local-enterprise

• Attribute freshness:

  • $PREFIX$/ATP/ePA-1m
  • $PREFIX$/ATP/ePA-1d

Need help?

Contact us if you need help. differentiate between ORCID users and those from (for example) KIT.

Currently defined are:

• ID-Uniqueness:

  • $PREFIX$/ID/unique
  • $PREFIX$/ID/no-eppn-reassign
  • $PREFIX$/ID/eppn-reassign-1y

• ID-Proofing:

  • $PREFIX$/IAP/low
  • $PREFIX$/IAP/medium
  • $PREFIX$/IAP/high
  • $PREFIX$/IAP/local-enterprise

• Attribute freshness:

  • $PREFIX$/ATP/ePA-1m
  • $PREFIX$/ATP/ePA-1d

Need help?

Contact us if you need help.