• OpenID Connect Provider

  • Der OpenID Connect Provider bietet Authentifizierungs- und Autorisierungsdienste für Web-basiertes Single Sign On und zur verteilten API-Integration. Ein Self-Service Webportal zur Session- und Tokenverwaltung wird ebenfalls zur Verfügung gestellt.

Allgemeines

Mit den Standards OpenID Connect und OAuth2 ist es möglich, sich einer Anwendung (z. B. Webseite, Desktopanwendung oder mobile App) gegenüber zu authentifizieren und ggf. zusätzlich dieser Anwendung den Zugriff auf weitere, HTTPS-basierte, Dienste zu erlauben, ohne der Anwendung die eigenen Zugangsdaten anvertrauen zu müssen. Derartige Anwendungen heißen bei OAuth Relying Party oder schlicht Client. Dies entspricht einem Serviceprovider im SAML2/Shibboleth-Umfeld.

Nutzerinnen und Nutzer werden zunächst über ihren Standardbrowser auf eine Login-Seite weitergeleitet, authentifizieren sich dort und werden nach Bestätigung der freigegebenen Attribute und Rollen zur Anwendung oder Webseite zurückgeleitet. Die vom Identity Provider freigegebenen Daten werden dabei in signierte JSON Web Tokens (JWT) verpackt. OAuth2-fähige Dienstschnittstellen akzeptieren ein solches Token als Authentifizierung, verifizieren dessen Signatur, interpretieren den Inhalt und gewähren (bzw. verbieten) entsprechend den dort hinterlegten Attributen (den sogenannten Claims) den Zugriff.

So kann man auch reinen Standalone Anwendungen oder mobilen Apps temporär oder dauerhaft Zugriff auf verschiedene Dienstschnittstellen ermöglichen, ohne dass diese Anwendungen die persönlichen Zugangsdaten speichern müssen. Das Erstellen von Single-Page JavaScript Anwendungen oder sonstigen Diensten, die im Namen der Nutzerin bzw. des Nutzers verschiedene Dienstschnittstellen integrieren, wird damit ebenfalls möglich.

Die Tokens haben unterschiedliche Gültigkeitsdauer (Kurz‑ bzw. Langzeitauthentifizierung) und Funktionen (Identifikation, Zugriff und Token-Refresh). Neben den Nutzerattributen und Rollen enthalten sie verschiedene Daten über IdP und Relying Party sowie Gültigkeitsdauer und eine RSA-basierte digitale Signatur. Sie können je nach Nutzungsszenario auch dauerhaft in der jeweiligen Anwendung gespeichert und jederzeit widerrufen werden.

Attribute

Standardmäßig werden die folgenden Attribute in ID- und Access-Tokens aufgeführt (hierbei werden die Attribute möglichst entsprechend den OpenID Connect Standardclaims und ansonsten mit den gängigen SAML2- bzw. LDAP/AD-Bezeichnern ausgeliefert):

  • preferred_username: KIT-Login
  • eduperson_principal_name: KIT-Login mit Domänenangabe
  • eduperson_scoped_affiliation: Zugehörigkeiten innerhalb des KIT (nur bei laufendem Arbeitsvertrag bzw. Immatrikulation)

Sofern von der Client-Anwendung angefordert, werden weitere Attribute wie die primäre Email-Adresse, Nachname, Vorname, Anzeigename und Organisationseinheit freigegeben. Weitere Attributfreigaben wie Gruppenmitgliedschaften, Berechtigungen (sogenannte "Entitlements"), Studienfach oder ORCID iD sowie personenunabhängige Dienstzugänge und Offline-Zugriff können ebenfalls nach Anfrage eingerichtet werden.

Betrieb im SCC

Das SCC betreibt einen OpenID Connect Provider, der die eigentliche Authentifizierung über Shibboleth durchführt, womit ein protokollübergreifendes SingleSignOn für alle zentralen KIT-Konten realisiert wird. Neben OpenID Connect und OAuth2-Zugangspunkten existiert auch ein Webportal zur Session- und Tokenverwaltung. Hier lassen sich jedem Dienst die jeweils freigegebenen Attribute, Rollen und Langzeittokens wieder entziehen. Die KIT-weite Zwei-Faktor-Authentifizierung sowie Autorisierungsdienste auf Basis von Zugehörigkeiten oder Gruppenmitgliedschaften stehen ebenfalls zur Verfügung.

Weiterführende Links