Schloss Symbol

Dienst für Beschäftigte

Anmelde- und Authentifizierungsdienst (Single Sign On - SSO)

Das TIK stellt einen zentralen Identity Provider (IDP) bereit, über den sich Nutzer mit ihrem vom Identity Management (SIAM) vergebenen Nutzeraccount gegenüber Diensten authentifizieren können.

Funktionsumfang

Dieser TIK-Dienst wendet sich an Administratoren / Beschäftigte, die Software bzw. einen Dienst betreiben und diesen an den zentralen Identity Provider (IDP) anbinden möchten. 

Das TIK stellt einen zentralen Identity Provider (IDP) bereit, über den sich Nutzer mit ihrem vom Identity Management (SIAM) vergebenen Nutzeraccount gegenüber Diensten authentifizieren können. Viele zentrale Dienste sind hier bereits angeschlossen (SAP, C@MPUS, WebEx, Matrix, …). Es ist ausdrücklich gewünscht, dass weitere Dienste den zentralen Login per Single Sign On über den Identity Provider nutzen und auf lokal gepflegte Accounts oder eine LDAP-Authentifizierung verzichten.
Voraussetzungen für die Anbindung an den IDP ist eine dienstliche Notwendigkeit des Dienstes. Falls bei der Anmeldung an den Dienst in diesem automatisch lokale Nutzerkonten erzeugt werden sollten, müssen Sie dafür sorgen, dass diese Nutzerkonten wieder gelöscht werden, wenn das zugehörige Nutzerkonto in SIAM gelöscht wird.
Eine Anbindung eines Dienstes am IDP kann durch eine der beiden Protokolle erfolgen:   

  • OpenID-Connect (OIDC) oder
  • SAML (Shibboleth).

Üblicherweise stellt eine Software / ein Dienst bereits eine dieser beiden Möglichkeiten bereit. Wenn Ihre Software dies nicht erfüllen sollte, können sie eine generische Software einsetzen:

Wurde die Anmeldung an einen Dienst über den IDP konfiguriert, erfolgt die Anmeldung nach folgendem Schema:

  • der Nutzer ruft die Loginseite des Dienstes / der Webseite / der Applikation auf
  • der Dienst leitet die Anmeldung an den IDP des TIK weiter
  • der Nutzer gibt seinen Nutzernamen, sein Kennwort und evtl. einen 2. Faktor auf der Anmeldeseite des IDP ein
  • der IDP überprüft die Anmeldeinformationen
  • meldet dem Dienst bei Erfolg die erfolgreiche Anmeldung des Nutzers zurück und
  • übermittelt (falls der Nutzer zugestimmt hat) eine spezielle Menge von Attributen (z.B. Name, E-Mail-Adresse, Nutzerkennung, … )

Wenn Sie die Anmeldung an ihren Dienst über den IDP absichern möchten und hierzu eine Beratung benötigen, dann stellen Sie bitte eine Anfrage an: shibboleth-support@tik.uni-stuttgart.de

Die Informationen, die wir von Ihnen benötigen, unterscheiden sich je nach gewünschtem Protokoll:

Sollte Ihre Software beide Protokolle unterstützen, empfehlen wir OIDC, da dies sowohl in der Einrichtung wie auch der Wartung weniger aufwändig ist.

Anbindung mit OIDC

Im Kontext von OIDC werden Dienste, also die Software die Sie anbinden möchten, Relying Party (RP) genannt. Jede RP hat eine eindeutige Client-ID und der IDP eine Issuer-ID. Die Konfiguration des IDP kann von folgenden URLs geladen werden:

Manche RP-Software kann aus der obenstehenden URL die benötigten Parameter extrahieren. Wenn nicht, werden Sie wahrscheinlich folgendes in ihrem SP angeben / konfigurieren müssen:

  • issuer
  • authorization_endpoint, token_endpoint, userinfo_endpoint
  • jwks_uri

Die OIDC Kommunikation wird über einen gemeinsamen Schlüssel abgesichert (nicht über Zertifikate). Dieses ‚Secret‘ werden wir Ihnen bei der Einrichtung mitteilen.

Wenn Sie einen Dienst über OIDC anbinden wollen, schreiben sie uns eine Anfrage an (shibboleth-support@tik.uni-stuttgart.de) mit folgenden Informationen:

  • Den Namen und Anwendungszweck des Dienstes
  • Einen Ansprechpartner mit Kontaktinformationen
  • Die URL, unter der sich Nutzer am Dienst anmelden können
  • Die Rücksprungadresse/-en (redirect-URL), die der IDP nach erfolgter Anmeldung im RP aufrufen soll
  • Attribute, die minimal vom IDP benötigt werden (Datensparsamkeit beachten)

Wir werden Ihnen dann folgende Informationen liefern:

  • Client-ID
  • Secret
  • Liste der verfügbaren Scopes und Claims (Attribut-Sets und Attribute)

Ein Beispiel der bei uns für eine RP hinterlegten Daten:

"client_id":        "mein-dienst.tik.uni-stuttgart.de"
"scope":             "openid profile email"
"client_secret": "ABC…XYZ"
"response_types":         ["code"]
"grant_types":  ["authorization_code"]
"token_endpoint_auth_method":          "client_secret_basic"
"redirect_uris": ["https://mein-dienst.tik.uni-stuttgart.de/auth/oidc/"]
"client_uri":       https://mein-dienst.tik.uni-stuttgart.de/login

Beispiel von benötigten Attributen: Nachname, Vorname, E-Mail-Adresse, eindeutige anonymisierte Nutzer-ID

Anbindung mit SAML

Innerhalb von SAML wird ein angeschlossener Dienst Service Provider (SP) genannt. Damit ein SP den IDP kontaktieren kann, benötigt dieser die Metadaten des IDP. Diese können von folgenden URLs geladen werden:

Manche SP-Software kann aus der obenstehenden URL die benötigten Parameter extrahieren. Wenn nicht, werden Sie wahrscheinlich folgende Parameter in ihrem SP angeben / konfigurieren müssen:

  • entityID
  • X509Certificate
  • SingleSignOnService

Damit kennt Ihr SP den IDP und kann diesen kontaktieren. Damit andersherum auch der IDP die Anfragen des SP erkennen und beantworten kann, benötigen wir von Ihrem SP ebenso Metadaten. Diese werden üblicherweise in Form einer XML-Datei auf dem SP bereitgestellt. Die URL zu dieser Datei muss vom IDP aufgerufen werden können / erreichbar sein.

Als Teil dieser Metadaten benötigen Sie für die SAML-Kommunikation zwischen SP und IDP ein Schlüsselpaar und das dazugehörigen Zertifikat. Dieses SAML-Zertifikat darf max. 39 Monate lang gültig sein, kann aber selbst-signiert sein. Wenn Sie einen Web-basierten Dienst anbinden wollen, wird darüber hinaus auch noch ein SSL-Zertifikat für den passenden DNS-Namen benötigt.

Wenn Sie einen Dienst über SAML anbinden wollen, schreiben sie uns eine Anfrage an (shibboleth-support@tik.uni-stuttgart.de) mit folgenden Informationen:

  • Den Namen und Anwendungszweck des Dienstes
  • Einen Ansprechpartner mit Kontaktinformationen
  • Die URL zu dem Metadaten (oder die XML Datei selbst)
  • Die URL, unter der sich Nutzer am Dienst anmelden können
  • Die Information wer sich auf dem Dienst anmelden können soll (nur Uni-Stuttgart Mitglieder oder auch externe Nutzer aus der DFN-AAI (https://download.aai.dfn.de/ws/2019/Grundlagen.pdf Seite 8))
  • Attribute, die minimal vom IDP benötigt werden (Datensparsamkeit beachten)

Beispiel von SP Metadaten:

<?xml version="1.0" encoding="UTF-8"?>
<md:EntityDescriptor entityID="https://mein-dienst.hier.uni-stuttgart.de/shibboleth" xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" >
     <md:SPSSODescriptor AuthnRequestsSigned="false" WantAssertionsSigned="true" protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
           <KeyDescriptor use="signing">
                <ds:KeyInfo>
                      <ds:X509Data>
                           <ds:X509Certificate>MIIFJ ... Uzega8</ds:X509Certificate>
                      </ds:X509Data>
                </ds:KeyInfo>
           </KeyDescriptor>
           <KeyDescriptor use="encryption">
                <ds:KeyInfo>
                      <ds:X509Data>
                           <ds:X509Certificate>MIIFJ ... Uzega8</ds:X509Certificate>
                      </ds:X509Data>
                </ds:KeyInfo>
                <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes256-cbc"/>
                <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
           </KeyDescriptor>
           <AssertionConsumerService index="1" isDefault="true" Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location="https://mein-dienst.hier.uni-stuttgart.de/shibboleth/saml/assertion"/>
     </md:SPSSODescriptor>
</md:EntityDescriptor>

Assurance Level im Shibboleth Verfahren

Auf folgender Seite finden Sie Informationen zu Assurance Leveln im Shibboleth Verfahren.

Weiterführende Informationen

Support
Zum Seitenanfang