Single-Sign-On#

Der OAuth- und Open-ID-Connect-Server ermöglicht es anderen Anwendungen IServ zur Anmeldung zu verwenden. Damit Anwendungen IServ zur Anmeldung verwenden können, müssen diese unter Verwaltung -> System -> Single-Sign-On registriert werden.

Hinweis

Für die generelle Verwendung von OAuth muss dem Benutzer das Recht OAuth verwenden zugewiesen sein.

Clients registrieren#

Klicken Sie auf Hinzufügen und geben dann die notwendigen Informationen ein.

Allgemein#

  • Name: Ein aussagekräftiger Name der die Anwendung beschreibt.

  • Vertrauenswürdig: Hiermit bestimmen Sie, ob eine Loginanfrage der Clientanwendung ohne die Zustimmung des Benutzers direkt akzeptiert wird. Sie sollten diese Option nur auf Ja setzen wenn Sie die Anwendung selber betreiben und sicher gestellt ist das die Informationen nicht ohne Zustimmung an Dritte gelangen können.

  • Client-ID und Client-Geheimnis: Diese Informationen müssen Sie in der Clientanwendung eintragen damit sich diese später authentifizieren kann.

Rechte#

Möchten Sie den Zugriff auf die entsprechende Clientanwendung auf Gruppen oder Rollen beschränken, so tragen Sie diese hier entsprechend ein. Wenn Sie diese Felder leer lassen dürfen alle Benutzer auf die Clientanwendung zugreifen.

Beschränkungen#

Diese Angaben beschreiben, wie sich die Clientanwendung authentifizieren muss und welche Informationen an den Client übermittelt werden sollen.

Erlaubte Grant-Typen#

Mindestens einer der folgenden Typen muss ausgewählt sein damit sich die Clientanwendung anmelden kann.

  • Autorisierungs-Code: Dies ist die vielseitigste Möglichkeit und wird von den meisten Anwendungen unterstützt.

  • Implizit: vereinfachte Variante für Clients, die direkt im Browser ausgeführt werden, z.B. Javascript-basierte Anwendungen

  • Passwort: Hierbei werden der Benutzername und das zugehörige Passwort zur Authentifizierung verwendet. Dies sollte nur genutzt werden wenn die sichere Übertragung dieser Daten garantiert werden kann, z.B. bei intern laufenden Anwendungen

  • Client-Anmeldedaten: Hierbei werden die unter Allgemein erwähnte Client-ID samt Client-Geheimnis für das Erlangen eines Access Token verwendet.

  • Erneuerungs-Token: Dieses lange gültige Token wird zur Erlangung eines neuen Access Tokens verwendet.

Auf Scopes beschränken#

Hiermit bestimmen Sie auf welche Bereiche/Informationen die Clientanwendung zugreifen darf. Wenn Sie keine Auswahl treffen ist der Zugriff auf alle Beriche erlaubt.

  • OpenID: Pseudonymisierte ID des Benutzers. Notwendig für OpenID Connect.

  • E-Mail: Die IServ-E-Mail-Adresse des Benutzers.

  • Profil: Allgemeine Informationen des Benutzers (Vor- und Nachname).

  • Gruppen: Die Gruppenmitgliedschaften des Benutzers.

  • Rollen: Die Rollenzugehörigkeiten des Benutzers.

  • UUID: Die global eindeutige UUID des Benutzers.

Anwendung#

  • Weiterleitungs-URIs: Die URIs auf die weitergeleitet werden soll, wenn die Bestätigung der Anmeldung durch den User erfolgt ist, dient zur Verifizierung, die genaue Weiterleitungs-URI teilt der Client in der Anmeldeanforderung mit. Dies ist in der Dokumentation der Clientanwendung nachzulsesen.

Login mit IServ#

Login mit IServ ist ein Dienst, der es ermöglicht, Single-Sign-On mit einer Anwendung durchzuführen, ohne dass die Anwendung für jeden angeschlossenen IServ konfiguriert werden muss. Mit einem Klick auf „Einstellungen für login.iserv.eu“ ist es möglich, zu konfigurieren, welche Anwendungen über „Login mit IServ“ mit Ihrem IServ interagieren können.

Der Ablauf für den Benutzer ist sehr ähnlich zum Single-Sign-On-Prozess. Der einzige Unterschied besteht darin, dass der Benutzer die Adresse des IServs in der vorgeschalteten Maske von „Login mit IServ“ eingeben muss.

../../../_images/loginwithiserv.png

Sie sind Anbieter einer Anwendung und möchten diese mit „Login mit IServ“-Funktionalität anbinden? Schreiben Sie uns eine E-Mail an info@iserv.eu.

Entwicklung und Integration#

Endpunkte#

Unter dem Endpunkt mein-iserv.de/.well-known/openid-configuration befindet sich die Konfiguration für OpenID. Dort werden die verschiedenen Endpunkte aufgelistet:

Scopes und Claims#

Hiermit bestimmen Sie auf welche Bereiche/Informationen die Clientanwendung zugreifen darf. Wenn Sie keine Auswahl treffen ist der Zugriff auf alle Beriche erlaubt.

openid#

Wir implementieren den standardisierten Scope openid mit folgenden Claims:

  • Issuer iss: URI zum IServ

  • Audience aud: Client-ID des anfragenden Clients

  • Subject sub: Pseudonymisierte ID des Benutzers

profile#

Wir implementieren den standardisierten Scope profile mit folgenden Claims:

  • Benutzername preferred_username: Accountname

  • Anzeigename name: Voller Name

  • Nickname nickname: Vorname

  • Vorname given_name: Vorname

  • Familienname family_name: Nachname

  • Sprache locale: Sprachpräferenz

email#

Wir implementieren den standardisierten Scope email mit folgenden Claims:

  • E-Mail email: E-Mail des Benutzers

  • Verifizierung email_verified: Verifizierungsstatus des Benutzers. Aktuell immer true

uuid#

Wir implementieren den nicht-standardisierten Scope uuid mit folgenden Claims:

  • UUID uuid: Eindeutige UUID des Benutzers

groups#

Wir implementieren den nicht-standardisierten Scope groups mit folgenden Claims:

  • Gruppen groups: Liste der Gruppen

Jeder Eintrag der Liste enthält folgende Felder:

  • Eindeutige ID id

  • UUID uuid

  • Accountname act

  • Anzeigename name

roles#

Wir implementieren den nicht-standardisierten Scope roles mit folgenden Claims:

  • Rollen roles: Liste der Rollen

Jeder Eintrag der Liste enthält folgende Felder:

  • Eindeutige UUID uuid

  • ID id: Veraltete ID

  • Anzeigename name

Sonstiges#

Weiterführende Informationen und einen guten Einstieg in das Thema OAuth und OpenID-Connect bietet der Atikel unter https://www.heise.de/developer/artikel/Flexible-und-sichere-Internetdienste-mit-OAuth-2-0-2068404.html?seite=all.