Single Sign On

Wenn Sie die SQUILD Sovereign Cloud (Openstack; im Folgenden SQSC) nutzen, gibt es zwei Möglichkeiten, wie Sie sich in der Verwaltungs-Konsole (Skyline) anmelden können und wie Sie weiteren Benutzern auf die Konsole Zugriff gewähren können:

1. Benutzer können direkt in der SQSC angelegt werden. Dies geschieht durch den SQUILD Support.
2. Wenn Sie bereits über eine eigene Benutzerverwaltung verfügen (z.B. Keycloak, Zitadel, ActiveDirectory oder EntraID), können Sie diese als Identity Provider für die SQSC anlegen.

Im Folgenden ist erklärt, wie Sie Ihre eigene Benutzerverwaltung an die SQUILD Sovereign Cloud anbinden können und wie Sie die Berechtigungen Ihrer Benutzer in der SQSC einstellen können.

Hinweis

Dieser Single Sign On funktioniert nur an der SQSC Konsole von SQUILD. Die Anmeldung an anderen System der sqCloud (z.B. sqCloudControl) funktioniert damit nicht.

Anwendungsbeispiel

Wenn Sie Ihre Benutzerverwaltung als einen Identity Provider bei uns angelegt haben, dann funktioniert die Anmeldung an der SQSC Konsole (Skyline) wie folgt:

(In diesem Beispiel gehen wir davon aus, dass in Ihrer Benutzerverwaltung der Benutzer Max Muster mit dem Benutzernamen mmuster existiert, und Ihr Unternehmen als E-Mail-Domäne mycompany.de benutzt)

1. Max Muster möchte sich in der SQSC Konsole anmelden (https://skyline.sqsc.sqcloud.net)
2. Auf der Login-Seite klickt er nun auf den Knopf "Single Sign On", anstatt seine Anmeldedaten anzugeben
3. Er wird auf die SSO-Seite weitergeleitet. Dort gibt er seine E-Mail-Adresse ein (z.B. mmuster@mycompany.de)
4. Er wird daraufhin zu Ihrer Benutzerverwaltung weitergeleitet, wo er sich authentifizieren muss (z.B. per Passwort).
5. Wenn die Authentifizierung erfolgreich war, wird er zurück zu der SQSC Konsole weitergeleitet, wo er jetzt auch angemeldet ist.

Grundlagen

Stark vereinfacht funktioniert die SSO-Authentifizierung folgendermaßen

Voraussetzungen

Um Ihre eigene Benutzerverwaltung an die SQSC anbinden zu können, müssen folgende Voraussetzungen erfüllt sein:

1. Ihre Benutzerverwaltung muss aus dem Netzwerk von SQUILD aus erreichbar sein.
2. Ihre Benutzerverwaltung unterstützt entweder SAML 2.0 oder OIDC 1.0
3. Sie müssen die Berechtigung haben in Ihrer Benutzerverwaltung neue Clients/ neue Vertrauensstellungen anzulegen
4. Ihre Benutzer müssen über eine E-Mail-Adresse verfügen in Ihrer Benutzerverwaltung. Diese E-Mail-Adresse wird später zur Anmeldung benutzt.

info

Diese Dokumentation beinhaltet nur eine Erklärung, wie ein Identity Provider auf unserer Seite angelegt werden kann.

Wenn der Provider auf unserer Seite angelegt wurde, muss auf Ihrer Seite in Ihrer Benutzerverwaltung ebenfalls ein Client (o.ä.) angelegt werden. Wie dies funktioniert, entnehmen Sie bitte der Dokumentation Ihrer Benutzerverwaltung. (Die notwendigen Daten zum Anlegen dieses Clients stellen wir Ihnen zur Verfügung, während Sie den IdentityProvider auf unserer Seite anlegen.)

Einschränkung

Wir erlauben nur einen IdentityProvider je Unternehmen.

Anlegen von IdentityProvidern

Sie können Ihren Identity Provider in sqCloudControl hier anlegen und verwalten:

Über Hinzufügen gelangen Sie zum Formular zum Anlegen Ihres Identity Providers.

Das Anlegen des Identity Providers erfolgt in mehreren Schritten:

1. Allgemeine Daten
2. Setup-Informationen zum Anlegen des Clients in Ihrer Benutzerverwaltung
3. Konfiguration abhängig vom verwendeten Protokoll (SAML oder OIDC)
4. Definition der Berechtigungen

Allgemeine Daten

1. Ein beliebiger, sinnvoller Name, unter dem der Identity Provider in sqCloudControl angelegt werden soll (z.B. Zitadel-OIDC oder AD_SAML)
2. Die E-Mail-Domänen die von Ihrem Unternehmen genutzt werden. Es muss mindestens eine Domäne angeben werden. (Über das + können weitere Domänen hinzugefügt werden)
3. Soll die SQUILD eigene Multifaktor-Authentifizierung aktiviert werden?

Multifaktor-Authentifizierung

Wenn dies aktiv ist, dann müssen Ihre Benutzer sich nach der Authentifizierung an Ihrer Benutzerverwaltung noch mit einem zweiten Faktor authentifizieren, z.B. mit einem Passkey, YubiKey, oder einer 2FA App. Die Infrastruktur für diese MFA wird in dem Fall von SQUILD bereitgestellt.

Wenn Sie in Ihrer Benutzerverwaltung bereits einen MFA-Mechanismus aktiviert haben, würden Ihre Benutzer sich sowohl mit der MFA von Ihrer Benutzerverwaltung, als auch von SQUILD anmelden müssen.

Setup-Informationen zum Anlegen des Clients

Bitte erstellen Sie nun einen SAML oder OIDC Client in Ihrer Benutzerverwaltung (manchmal auch Vertrauensstellung, Anwendung oder App genannt). Hierfür können Sie die hier angezeigten Informationen verwenden. Je nachdem wie Sie den Client einrichten und welches Protokoll Sie verwenden, sind nicht unbedingt alle hier angezeigten Informationen zur Einrichtung notwendig.

Das Zertifikat können Sie zur Signatur-Validierung in Ihrem Client angeben.

E-Mail-Attribut

Bitte beachten Sie den Hinweis zur Einrichtung des Clients, so dass dieser bei der Authentifizierung die E-Mail-Adresse des Benutzers mit überträgt.

Login-URL

Die Login-URL ist für unseren Single Sign On tatsächlich gar nicht notwendig. Manche Identity Provider verlangen diese aber zur Einrichtung des Clients.

Spezielle Daten je nach Protokoll

Den Client, der von Ihnen im vorangegangenen Schritt eingerichtet wurde, muss die E-Mail-Adresse der User im Token übertragen. Der Attribut-/Claim-Name, der diese E-Mail Adresse enthält, muss im Email-Attribut-Feld eingetragen werden.

Email-Attribut

Es kann sich dabei um einen einfachen Bezeichner (z.B. emailaddress) oder um eine URL (z.B. http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress) handeln.

Mit dem Auswahlfeld Variante kann SAML bzw. OIDC ausgewählt werden. Je nach Variante unterscheiden sich die weiteren benötigten Daten. (siehe unten)

OIDC

Importieren von Einstellungen (OIDC)

Der OIDC Spezifikation nach gibt es einen sogenannten Metadata Discovery Endpoint (o.ä.), über den verschiedene Daten zu Ihrer Benutzerverwaltung geladen werden können. Dies erleichtert die Einrichtung des Identity Providers.

Der Discovery Endpoint sollte so oder so ähnlich aussehen:

https://[IhreBenutzerverwaltung]/.well-known/openid-configuration

(Der Discovery Endpoint ist erkennbar an dem hinteren Teil dieser URL (/.well-known/openid-configuration))

Bitte ziehen Sie die Dokumentation Ihrer Benutzerverwaltung zu Rate, um den Discovery Endpoint Ihrer Benutzerverwaltung in Erfahrung zu bringen.

Discovery Endpoint

Wenn Sie eine .well-known-URL gefunden haben, können Sie diese testweise in einem Internetbrowser aufrufen. Es sollte Ihnen ein Text-Dokument mit JSON formatierten Daten angezeigt werden.

Wenn Sie die .well-known-URL gefunden haben, können Sie diese in das URL-Feld (siehe Screenshot oben) eingeben und die Daten laden. Die Konfiguration sollte dann schon mit sinnvollen Daten ausgefüllt werden, die zu Ihrer Benutzerverwaltung passen.

Kontrollieren Sie die Konfiguration bitte, bevor Sie zum nächsten Schritt wechseln.

Erklärung zu den Konfigurations-Möglichkeiten (OIDC)

Name	Erklärung	Besonderheit
Validate Signature	Wenn aktiv, werden die Signaturen der ID Tokens validiert	Ein Public Key zur Validierung muss zur Verfügung gestellt werden (siehe folgende Punkte)
Use JWKS URL	Bestimmt, ob zur Signatur-Validierung ein Public Key direkt angegeben wurde (siehe Felder Validating public key und Validating public key id) oder ob der Public Key über die JWKS URL bezogen werden soll	Nur sichtbar, wenn Validate Signature aktiv ist
Validating public key	Der Public Key in pem-Format, der zur Signatur-Validierung genutzt werden soll	Nur sichtbar, wenn Validate Signature aktiv und Use JWKS URL inaktiv ist
Validating public key id	Die ID des Public Keys, der zur Signatur-Validierung genutzt wird.	Nur sichtbar, wenn Validate Signature aktiv und Use JWKS URL inaktiv ist. (Kann auch leer bleiben.)
JWKS URL	Die URL, über die der Public Key für die Signatur-Validierung bezogen werden kann.	Nur sichtbar, wenn sowohl Validate Signature als auch Use JWKS URL aktiv sind.
Metadata Descriptor URL	Die .well-known URL (Erklärung siehe oben)
User Info URL	Die URL, über die UserProfil-Informationen bezogen werden können
Token URL	Die URL, über die Token bezogen werden können
Authorization URL	Die URL, über die die Autorisierung erfolgt
Logout URL	Die URL, mit ein User seine Session beenden kann	optional
Issuer	Eine URL, mit der Ihre Benutzerverwaltung identifiziert werden kann / Die URL des Identitäts-Ausstellers
PKCE	Proof Key for Code Exchange; Ein Sicherheitsmechanismus, um mögliche Angreifer daran zu hindern, legitime Tokens zu erhalten	Kann ungenutzt sein, oder entweder per S256 oder plain implementiert sein.
Client Authentication Method	Es gibt vier Optionen: Client Secret über Basic Auth, Client Secret über POST, JWT signiert mit Client Secret oder JWT signiert mit Private Key (weitere Erklärung siehe unten)
Client ID	Die ID des Clients, den Sie in Ihrer Benutzerverwaltung für diesen Identity Provider angelegt haben	(Bitte ziehen Sie die Dokumentation Ihrer Benutzerverwaltung zur Rate, um herauszufinden wie ein Client angelegt wird und wo die ClientID gefunden werden kann.)
Client Secret	Das zur ClientID gehörige ClientSecret in Ihrer Benutzerverwaltung	(Bitte ziehen Sie die Dokumentation Ihrer Benutzerverwaltung zur Rate, um herauszufinden wie ein Client angelegt wird und wo das Secret gefunden werden kann.)
Client Assertion Signing Algorithm	Der Algorithmus, der zum Erstellen der JWT Assertion genutzt werden soll. (weitere Erklärung siehe unten)
Client Assertion Audience	Hiermit können die beabsichtigten Empfänger der Autorisierungs-Tokens eingeschränkt werden. Dies kann als Sicherheitsmechanismus dienen.	Ist nur sichtbar, wenn als Client Authentication Method eine der JWT Methoden gewählt wurde.
Add X.509 Headers to JWT	Wenn aktiv, wird der x5t header zum JWT hinzugefügt, andernfalls wird die Key ID genutzt.	Nur sichtbar, wenn als Client Authentication Method die Methode JWT signiert mit Private Key gewählt wurde

Client Authentication Method und Client Assertion Signing Algorithm

Methode	Erklärung
Client Secret über Basic Auth	Die Client-Zugangsdaten werden per HTTP Basic Authentication übertragen
Client Secret über POST	Die Client-Zugangsdaten werden im POST-Körper übertragen
JWT signiert mit Client Secret	Die Autorisierung des Clients erfolgt per JWT (JSON Web Token), welches mit dem Client Secrets signiert wurde
JWT signiert mit Private Key	Wie JWT signiert mit Client Secret aber signiert mit einem public-private Schlüssel-Paar

Wenn eine der beiden JWT-Methoden gewählt wurde, MUSS ein Client Assertion Signing Algorithm angegeben sein. Im Falle der Private Key-Methode ist RS256 der Default-Wert. Im Falle der JWT Client Secret-Methode ist HS256 der Default.

SAML

Importieren von Einstellungen (SAML)

Wahrscheinlich bietet Ihre Benutzerverwaltung einen SAML entity descriptor an. Dies ist eine URL mit der verschiedene Metadaten zu Ihrer Benutzerverwaltung geladen werden können.

Im Falle von ADFS ist dies beispielsweise:

https://[IhreBenutzerverwaltung]/FederationMetadata/2007-06/FederationMetadata.xml

Bitte ziehen Sie die Dokumentation Ihrer Benutzerverwaltung zu Rate, um den SAML Entity Descriptor Ihrer Benutzerverwaltung in Erfahrung zu bringen.

SAML Entity Descriptor

Wenn Sie die Entity Descriptor URL gefunden haben, können Sie diese testweise in einem Internetbrowser aufrufen. Es sollte dann ein XML-Dokument heruntergeladen werden, in dem die Metadaten beschrieben werden.

Wenn Sie die Entity Descriptor URL gefunden haben, können Sie diese in das URL-Feld (siehe Screenshot oben) eingeben und die Daten laden. Die Konfiguration sollte dann schon mit sinnvollen Daten ausgefüllt werden, die zu Ihrer Benutzerverwaltung passen.

Kontrollieren Sie die Konfiguration bitte, bevor Sie zum nächsten Schritt wechseln.

Erklärung zu den Konfigurations-Möglichkeiten (SAML)

Name	Erklärung	Besonderheit
Validate Signature	Falls aktiv, wird erwartet, dass die Anfragen und Antworten des Identity Providers digital signiert sind.
Use Metadata Descriptor URL	Wenn aktiv, werden die Zertifikate, die zur Signatur-Validierung benötigt werden, von der Metadata Descriptor URL heruntergeladen.	Nur sichtbar, wenn Validate Signature aktiv ist.
Signing Certificate	Das X.509 öffentliche Zertifikat, welches zur Signatur-Validierung genutzt werden soll.	Nur sichtbar, wenn Validate Signature aktiv und Use Metadata Descriptor URL inaktiv sind. Es können mehrere Zertifikate angegeben werden (mit Komma getrennt)
Metadata Descriptor URL	Die URL Ihrer Benutzerverwaltung, von der die Zertifikate für die Signatur-Validierung heruntergeladen werden können.	Nur sichtbar, wenn sowohl Validate Signature und Use Metadata Descriptor URL aktiv sind.
(HTTP) POST Binding Logout	Wenn aktiv wird HTTP POST Binding für Logout Requests genutzt, ansonsten REDIRECT Binding.
(HTTP) POST Binding Response	Wenn aktiv, wird HTTP POST Binding genutzt für SAML Anfragen, andernfalls REDIRECT Binding.
Single Logout Service URL	Dir URL, über die der Logout durchgeführt wird.
Name ID Policy Format	URI Referenz, die einem Name Identifier Format entspricht (Default ist Persistent)
IdP Entity ID	Wird genutzt um den Aussteller von SAML Assertions zu validieren	Wenn nicht angegeben, wird keine Aussteller-Validierung durchgeführt.
Login Hint	Wenn aktiv, wird das Login-Formular Ihrer Benutzerverwaltung bereits mit den bekannten Benutzerdaten vor ausgefüllt.
(HTTP) POST Binding Authn Request	Wenn inaktiv, wird REDIRECT Binding genutzt für SAML Anfragen, andernfalls HTTP POST Binding.
Single Sign On Service URL	Die URL mit dem der Authentifizierungs-Prozess gestartet wird.
Want Authn Request Signed	Wenn aktiv wird ein public-private Schlüsselpaar genutzt, um SAML-Anfragen an Ihre Benutzerverwaltung zu signieren	Nach Einrichtung des Identity Providers geben wir Ihnen in den Setup Informationen einen public Key, den Sie in Ihrer Benutzerverwaltung hinterlegen müssen.
Signature Algorithm	Der Algorithmus, der zur Signierung benutzt wird.	Nur sichtbar, wenn Want Authn Request Signed aktiv ist.
SAML signature key name	Wenn Sie ADFS verwenden ist dies wahrscheinlich Cert_Subject. Im Falle von Keycloak/ RedHat-SSO wahrscheinlich KEY_ID	Nur sichtbar, wenn Want Authn Request Signed aktiv ist.
Add Extensions Element With Key Info	Wenn aktiv, wird die Authentifizierungsanfrage ergänzt mit Informationen zu den verwendeten Schlüsseln
Encryption Public Key	Der öffentliche Schlüssel, der für die Verschlüsselung/Entschlüsselung verwendet werden soll.
Artifact Binding Response	Wenn inaktiv, wird (HTTP) POST Binding ausgewertet
Artifact Resolution Service URL	Die URL, die genutzt werden muss, um SAML Assertions von Artefakten zu erhalten
Backchannel Supported	Wenn Ihre Benutzerverwaltung "Backchannel Logout" unterstützt, kann dies aktiviert werden.
Send ID Token On Logout	Wenn aktiv, wird bei Logout-Requests ein id_token_hint mitgesendet
Send Client ID On Logout	Wenn aktiv, wird bei Logout-Requests die Client ID mitgesendet
Sign Service Provider Metadata	Wenn aktiv, werden die Metadaten der Metadata Descriptor URL mit einem Schlüsselpaar signiert.	Die Descriptor-URL und den zugehörigen öffentlichen Schlüssel erhalten Sie in den Setup-Informationen
Principal Type	Spezifiziert wie der User in der SAML Assertion identifiziert werden soll.	Subject NameID kann nicht zusammen mit dem NameID Policy Format Transient gesetzt werden.
Principal Attribute	Der Attribut-Name, der zum Identifizieren des Users in der SAML Assertion genutzt werden soll, wenn Principal Type entweder Attribute Name oder Attribute Friendly Name ist	Nur sichtbar, wenn Principal Type entweder Attribute Name oder Attribute Friendly Name ist

Definition der Berechtigungen

Diese Einstellungen sind notwendig, damit die User in Openstack auch die korrekten Berechtigungen in ihren Projekten haben (und sie überhaupt Openstack-Projekte sehen können.)

Dies funktioniert so, dass bestimmte Attribute der User in Ihrer Benutzerverwaltung bei der Anmeldung an Openstack mit übertragen werden und je nach Attribut-Wert wird dem User eine bestimmte Rolle in einem bestimmten Openstack-Projekt zugewiesen.

Ein Fallbeispiel:

• Sie haben in Openstack ein Projekt namens A000XXX-1 und wollen dem User jsmith aus Ihrer Benutzerverwaltung lesenden Zugriff auf dieses Projekt geben.
• Hierfür erstellen Sie in Ihrer Benutzerverwaltung eine Gruppe namens SQSC-lesend (Der Name ist frei wählbar) und weisen jsmith dieser Gruppe zu.
• Im Client, den sie entsprechend den Angaben oben in Ihrer Benutzerverwaltung eingerichtet haben, stellen Sie nun ein, dass die Gruppenmitgliedschaften bei der Anmeldung mit übertragen werden. (Genau so, wie Sie auch eingestellt haben, dass die E-Mail-Adresse des Benutzers übertragen wird.) Sie stellen dies so ein, dass die Mitgliedschaften im Attribut groups stehen.
• In sqCloudControl können Sie nun in diesem Berechtigungsformular folgende Angaben machen:
  • Attribut-Name: groups
  • Attribut-Wert: SQSC-lesend (Je nachdem wie Ihre Benutzerverwaltung funktioniert, kann es auch sein, dass hier ein Pfad, eine UUID oder ähnliches anzugeben ist)
  • Projekt: A000XXX-1
  • Rolle: reader

Bearbeiten von Identity Providern

Um den Identity Provider zu bearbeiten oder seine Einstellungen zu überprüfen, klicken Sie in der Identity Provider Liste in sqCloudControl auf das drei-Punkte-Menü des Providers und wählen Details.

Sie haben hier die Möglichkeiten:

• Die SQUILD-Multifaktor-Authentifizierung zu (de)aktiveren (Im Reiter Allgemein)
• Domänen zu bearbeiten (Im Reiter Domänen)
• Die Konfigurations-Einstellungen zu prüfen und zu aktualisieren (Im Reiter Daten)
• Die Berechtigungen zu ändern (Im Reiter Berechtigungen)