Der Dialog Single Sign-On Konfiguration dient der Konfiguration und damit der Anbindung eines vorgeschalteten SSO-Systems.

SAML 2.0

Vorbereitung

Vor Konfigurationsbeginn von SAML 2.0 als Single Sign-On Methode (im folgenden SSO) sollten ein paar Vorbereitungen getroffen werden.

Identity Provider

Für die Konfiguration von SAML 2.0 ist es notwendig die Metadaten des Identity Providers (im Folgenden IdP) zu ermitteln. Die Metadaten werden im XML-Format bereitgestellt und enthalten Informationen über die Kommunikation zum IdP.

Beispiel einer IdP metadata.xml:

Service Provider

Entity ID und Basis URL

Vor Einrichtung sollte mit der entsprechenden SAML Abteilung (i.d.R auch zuständig für den IdP) abgeklärt werden, wie die Entity ID des Portals heißen soll und wie die Basis URL lauten wird. Gewöhnlich wird als Entity ID einfach "portal" und als Basis URL die Root Domain des Tools gewählt. Sollte es zur Entity ID und Basis URL keine Richtlinien geben, können Sie beides einfach festlegen.

Zertifikat

Um die Kommunikation zwischen dem Portal und dem IdP zu sichern kann im Portal ein Zertifikat hinterlegt werden. Das Zertifikat sollte vor der SSO Konfiguration beschafft werden und in p12-Keystoreformat vorliegen. Passend zum p12-Keystore wird das Keystorepasswort und der Key Alias benötigt.

Übermittlung Login Name

Die Übermittlung des Login Namen durch eine SAML-Antwort ist nicht eindeutig. Daher muss geklärt werden wie der Login Name zu ermitteln ist. Im Regelfall wird der Login Name in das NameID-Feld des Subject-Tags der SAML Antwort geschrieben. Ist dem nicht so, muss geklärt werden, wie der Name des Assertion-Feldes lautet, in dem der Login Name steht.

Konfiguration

Die zuvor ermittelten Daten werden nun im Portal unter Administration → Single Sign-On Konfiguration → Tab SAML 2.0 eingetragen.

Identity Provider

Die Metadaten des IdP können auf zwei Arten eingetragen werden:

1. Als Text in das Metadaten Textfeld kopieren
2. Als XML-Datei über das Feld Metadata XML Datei auswählen und über den Button SAML 2.0 IdP-Metadaten hochladen in das Metadaten Feld einfügen

Service Provider

Entity ID und Basis URL

Tragen Sie die festgelegte Entity ID in das Feld Entity ID und die festgelegte Basis URL in das Feld Basis Url ein.

Sollten das Portal über verschiedene URLs sowohl über das Inter- als auch das Intranet erreichbar sein, können noch alternativen zu den beiden Feldern angegeben werden: alternative Entity ID und alternative Basis Url. Hier wird beim Login Aufruf geprüft, ob die aufgerufene URL mit der alternative Basis Url als Präfix übereinstimmt. Wenn dem so ist, wird für den SAML-Aufruf die alternative Entity ID und alternative Basis Url verwendet, ansonsten die original Entity ID.

Zertifikat

Im Abschnitt KeyStore wird, sofern gewünscht, das Zertifikat konfiguriert. Wählen Sie im Feld Datei die zu verwenden p12-Datei aus und laden Sie diese über den Button SAML 2.0 SP-KeyStore hochladen hoch. Geben Sie anschließend in das Feld KeyStore Passwort das Passwort und in das Feld Key Alias den Alias ein.

Metadaten

Nachdem Sie alle Daten für den Service Provider eingegeben und den Dialog gespeichert haben, können Sie die Metadaten des Service Providers exportieren.

Klicken Sie dazu einfach auf den Button SAML 2.0 SP Metadaten. Daraufhin wird ein neuer Browser Tab geöffnet. Den Inhalt des neuen Tabs können Sie kopieren und ihrer SAML Abteilung zur Einspielung übergeben.

Benutzereinstellungen

Im Abschnitt Benutzereinstellungen können die folgenden Einstellungen vorgenommen werden:

Loggineinstellungen

1. Anmeldung mit Benutzername/Passwort zulassen: Wird hier der Haken gesetzt, kann ein Benutzer sich sowohl über SSO, als auch mit Benutzername und Passwort über den Portal-Logindialog anmelden. Um den Logindialog aufzurufen, gibt es zwei Möglichkeiten:
   
   1. Ein Benutzer meldet sich "regulär" über SSO an, meldet sich anschließend ab und klickt im darauf folgenden "Abgemeldet"-Dialog auf den Link "Zur Anmeldeseite". Der Link "Anmelden" führt erneut die SSO Anmeldung durch.
   2. Ein Benutzer ruft die login URL des Portals mit Query Parameter usePortalDialog=true (resultierende URL "/login?usePortalDialog=true") auf.

Mapping Loginname

1. Subject-NameID entspricht Login Name: Wenn der Login Name aus dem NameID-Feld des Subject-Tags ermittelt werden soll, so muss hier der Haken gesetzt werden.
2. Assertion Login Name: Wenn das Subject-NameID-Feld nicht dem Loginnamen entspricht, muss hier der Name des Assertion-Tags angeben, in dem der Login Name übermittelt wird.

Automatische Benutzeranlage

Im Bereich "Automatische Benutzeranlage" können Sie definieren ob, ein Benutzer nach dem Login automatisch angelegt wird, sofern diese nicht existiert.

1. Soll ein Benutzer automatisch im System angelegt werden, kann im Feld Benutzer bei erfolgreicher Anmeldung automatisch im System anlegen ein Haken gesetzt werden.
2. Trifft 1) zu, kann im Feld Benutzer als archiviert anlegen festgelegt werden, ob ein automatisch angelegter Benutzer direkt im System eingeloggt oder archiviert wird.
3. Assertion Mapping (optional)
   
   1. Vorname: Name des Assertion-Tags, das den Vornamen des Benutzers enthält. Der Wert wird beim automatischen Anlegen in die Detailinformationen des Benutzers geschrieben.
   2. Nachname: Name des Assertion-Tags, das den Nachnamen des Benutzers enthält. Der Wert wird beim automatischen Anlegen in die Detailinformationen des Benutzers geschrieben.
   3. E-Mail Adresse: Name des Assertion-Tags, dass die E-Mail Adresse des Benutzers enthält. Der Wert wird beim automatischen Anlegen in die Detailinformationen des Benutzers geschrieben.

Rollen Mapping 

Im Bereich "Rollen Mapping" können Sie definieren ob und wie Rollen automatisch einem Benutzer zugewiesen werden sollen.

1. Soll einem Benutzer beim Login automatisch eine oder mehrere Rollen zugewiesen werden, kann im Feld Rollen automatisch beim Login zuweisen ein Haken gesetzt werden.
2. Trifft 1) zu, können Sie in der Zeile Assertion-Attributname der Rollen über das Plus beliebig viele Eingabefelder dem Formular hinzufügen. Pro hinzugefügtem Eingabefeld können Sie einen Namen eines Assertion-Attributs konfigurieren, welches die Rollenzuordnung für den Benutzer enthält.
3. Nach der Konfiguration der Attributnamen definieren Sie wie die Werte der Assertion-Attribute auf einen potenziellen Template Benutzer gemappt werden sollen:
   1. Attribut enthält Template-User Loginname: Setzen Sie hier einen Haken, wenn die Werte der Assertion-Attribute für die Rollenzuweisung direkt den Loginnamen eines Template Benutzer enthält.
   2. Attributwert für Template-User Mapping: Ist a) nichtzutreffend, können Sie hier die potenziellen Werte der Assertion-Attribute manuell einem Template Benutzer zuweisen. Fügen Sie dazu über das Plus eine neue Zuweisung dem Formular hinzu. Geben Sie anschließend in das Eingabefeld den Wert des Attributs ein und wählen darunter einen Template Benutzer aus. Sollte sich ein Attributwert nicht eindeutig bestimmen lassen, können Sie den Attributwert auch als regulären Ausdruck angeben. Setzen Sie dazu den Haken bei Regulärer Ausdruck. Über das Plus können Sie beliebig viele Zuweisungen vornehmen.

Meldet sich ein Benutzer nun am System an, wird ermittelt, ob eine automatische Rollenzuweisung vorliegt. Wenn dem so ist, wird der (oder die) passende Template Benutzer ermittelt und die damit verknüpften Rollen ermittelt. Diese Rollen werden dann dem angemeldeten Benutzer zugewiesen.

Konfigurationsbeispiel

Angenommen der SAML-Response enthält folgende Attribute

<saml:AttributeStatement>
	<saml:Attribute Name="uid" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
		<saml:AttributeValue xsi:type="xs:string">1</saml:AttributeValue>
	</saml:Attribute>
	<saml:Attribute Name="eduPersonAffiliation" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
		<saml:AttributeValue xsi:type="xs:string">group1</saml:AttributeValue>
	</saml:Attribute>
	<saml:Attribute Name="email" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
		<saml:AttributeValue xsi:type="xs:string">user1@example.com</saml:AttributeValue>
	</saml:Attribute>
</saml:AttributeStatement>

Die Rolleninformationen können beispielsweise in dem Attribut "eduPersonAffiliation" in Zeile 5 stehen.

Mögliche Werte des Attributs sind in diesem Beispiel neben "group1" noch "group2" und "groupAdmin".

Als Template Benutzer wurden die Benutzer "Administrator" und "StandardUser" angelegt.

Eine gültige Konfiguration wäre nun:

Aktivierung

Nachdem die Konfiguration vollständig durchgeführt wurde und die Metadaten des Service Providers erfolgreich im IdP hinterlegt wurden, kann SAML 2.0 als SSO aktiviert werden. Wählen Sie dazu in der Dropdown-Box Single Sign-On Typ oberhalb des SAML 2.0 Tabs den Eintrag SAML 2.0 aus und speichern Sie den Dialog.

Template Benutzer

Ein Template Benutzer definiert einen Benutzer, der ausschließlich als Vorlage für die automatische Rollenzuweisung dient. Ein Template Benutzer kann nicht am System angemeldet werden, verfügt jedoch über Rollen und damit über Berechtigungen.

Um einen Template Benutzer zu definieren, aktivieren Sie SAML 2.0 als SSO (siehe Abschnitt Aktivierung) und legen Sie einen neuen Benutzer an. Durch die Aktivierung von SAML 2.0 erscheint im Benutzer-Dialog eine neue Zeile Template Benutzer. Setzen Sie hier den Haken.

Weisen Sie anschließend im Dialog Rollenzuweisung dem Template Benutzer passende Rollen zu. 

Änderungsprotokoll 

Der Änderungsprotokoll Dialog enthält eine vollständige Änderungshistorie eines jeden SSO-Datensatzes. Um das Änderungsprotokoll aufzurufen, klicken Sie auf den Button Änderungsprotokoll.

Für weitere Informationen zur Funktionsweise des Dialogs klicken Sie hier.