Single Sign On (SSO / dt. Einmalanmeldung) ist ein Verfahren, welches eine Anmeldung auf Fremddiensten anhand einer Anmeldung eines primären Dienstes ermöglicht. Der primäre Dienst - IdP (Identity Prodiver) genannt - authentifiziert den Nutzer anhand der Anmeldung und übermittelt die Authentifizierung
Authentifizierung an den Fremddienst - Service Provider (SP) genannt - , sodass eine Authentifizierung beim Fremddienst nicht nötig ist. Die Standards, die zur Kommunikation zwischen SP und IdP genutzt werden sind bspw. SAML und Shibboleth.
...
Die Konfiguration von SSO wid hauptsächlich durch die Konfiguration der *Basiskonfiguration für Provider*-Datensätze (ConfigJoinSsoProvider) durchgeführt. Diese Datensätze enthalten folgende Eigenschaften.
Bezeichnung | Beschreibung |
|---|---|
Anzeigename | Der Anzeigename wird über ein einfaches Textfeld definiert. Er dient nur zur einfacheren Zuordnung des Datensatzes und wird den Schaltflächen in der Anwendung vergeben. |
Service Provider ID | Eine ID, die genutzt wird, um den Service Provider (eindeutig) zu identifizieren. Wird automatisch vom System generiert. |
Nutzerentität | Die gewünschte Zielentität, auf die ein authentifizierter Nutzer gemappt werden soll. Hierbei handelt es sich um eine Auswahl der verschiedenen Nutzertypen in brandbox. |
Callback | Der Callback wird über ein Auswahlfeld definiert. Der Callback definiert, welcher SP sich um die Authentifizierung/Autorisierung kümmert. Hierbei handelt es sich um Fremdschlüssel auf die Tabelle *Callbacks* (ssoProviderCallback). |
Konfiguration | Eine Konfiguration im JSON Format. Diese Konfiguration kann genutzt werden, um die Callbacks und das Mapping der Nutzerdaten zu konfigurieren. Die Konfiguration der Callbacks hängt stets von den Callbacks selbst ab, es wird aber stets der Key |
config |
genutzt. Für die Konfiguration des Mappings sollte hier weitergelesen werden: |
Metadata XML | Eine XML Datei, die vom IdP bereitgestellt wird. Diese XML Datei muss über das Dateifeld hochgeladen werden. Auf Basis dieser XML-Datei werden die nötigen Daten zur Kommunikation mit dem IdP erstellt (Schlüssel, Zertifikate etc.). |
Im Shop sichtbar | Steuert, ob im Shop Schaltflächen für den Login über SSO dargestellt werden sollen. |
Im Backend sichtbar | Steuert, ob im administrativen Bereich Schaltflächen für den Login über SSO dargestellt werden sollen. |
Beim Speichern dieser Datensätze wird über die Save-Events von brandbox ggf. Zusatzlogik ausgeführt. Handelt es sich bspw. um den SAML2-Callback, werden die für SAML2 bennötigen Dateien generiert (Zertifikate, Schlüssel, Konfigurationsdateien etc.) Zertifikate und Schlüssel sind für zwei Jahre gültig. Sie müssen also rechtzeitig durch das Speichern des Datensatzes neu generiert werden.
...
Join/SsoSaml2 nutzt die PHP Bibliothek simplesamlphp/simplesamlphp. Sie wird über component/simplesamlphp installiert. component/simplesamlphp bringt außer dem requirement auf simplesamlphp/simplesamlphp noch Logik mit, welche das Konfigurationsdaten-Handling betrifft. Über Update-/Installationsroutine von composer werden Events ausgelöst, auf die component/simplesamlphp reagiert. Die Eventlistener erstellen in diesem Zug Symlinks von temp/cache/ in das remote-Verzeichnis von simplesamlphp/simplesamlphp. Dies ist nötig, um die von brandbox generierten Konfigurationsdateien nutzen zu können.
Beispiel
YAML, die das Mapping angibt und weitere Informationen enthält, die ein Provider braucht.
...
| language | js |
|---|---|
| theme | RDark |
| title | YAML-Konfiguration |
...
.
...