• OpenID Connect Provider

  • The OpenID Connect Provider provides authentication and authorization services for web-based single sign-on and for distributed API integration. A self-service web portal for session and token management is also provided.

General

With the OpenID Connect and OAuth2 standards, it is possible to authenticate oneself to an application (e.g., website, desktop application, or mobile app) and, if necessary, also to allow this application to access other HTTPS-based services without having to entrust the application with one's own credentials. In OAuth, such applications are called Relying Party or simply Client. This corresponds to a service provider in the SAML2/Shibboleth environment.

Users are first redirected to a login page via their standard browser, authenticate themselves there, and are redirected back to the application or website after confirming the released attributes and roles. The data released by the identity provider is packaged in signed JSON Web Tokens (JWT). OAuth2-enabled service interfaces accept such a token as authentication, verify its signature, interpret the content, and grant (or deny) access according to the attributes (the so-called claims) stored there.

In this way, pure standalone applications or mobile apps can be given temporary or permanent access to various service interfaces without having to save the personal credentials within these applications. This also makes it possible to create single-page JavaScript applications or other services that integrate various service interfaces on behalf of the user.

The tokens have different validity periods (short- or long-term authentication) and functions (identification, access and token refresh). In addition to user attributes and roles, they contain various data about IdP and Relying Party as well as validity period and an RSA-based digital signature. Depending on the usage scenario, they can also be stored permanently in the respective application and revoked at any time.

Attributes

By default, the following attributes are listed in ID and Access tokens (where possible, attributes are delivered according to the OpenID Connect standard claims and otherwise with the common SAML2 or LDAP/AD identifiers):

  • preferred_username: KIT user login
  • eduperson_principal_name: KIT user login with domain statement
  • eduperson_scoped_affiliation: Affiliation within KIT (only for current employment contract or student enrollment)

If requested by the client application, additional attributes such as primary email address, last name, first name, display name, and organizational unit are shared. Other attribute shares such as group memberships, authorizations (so-called "Entitlements"), subject of study or ORCID iD as well as person-independent service and offline accesses and can also be set up on request.

Operation at the SCC

The SCC operates an OpenID Connect provider, which performs the actual authentication via Shibboleth, thus realizing a cross-protocol SingleSignOn for all central KIT accounts. In addition to OpenID Connect and OAuth2 access points, there is also a web portal for session and token management. Here, the respective released attributes, roles, and long-term tokens can be revoked for each service. KIT-wide two-factor authentication and authorization services based on affiliations or group memberships are also available.

Further links