Identity Providers und Protokolle
English | Deutsch
INHALTSVERZEICHNIS
Voraussetzung für eine erfolgreiche Anbindung an eine bestehende IAM/SSO-Lösung ist, dass die bestehende IAM/SSO-Lösung in der Lage ist, Applikationen über SAML 2.0 oder OpenID connect anzubinden. Darüber hinaus muss sie öffentlich und nicht nur in Ihrem internen Netzwerk oder Infrastruktur verfügbar sein.
Identity Providers
Eine Liste der Identity Povidern, die üblicherweise von Tivian-Kunden verwendet werden:
Azure AD B2C
Okta
Azure AD
Active Directory + ADFS
Die Produkte bzw. Services, die die benötigten Protokolle OIDC Federation oder SAML Federation unterstützen, können ebenfalls in Betracht gezogen werden
OIDC Federation
Open ID Connect (OIDC) ist ein Authentifizierungs- und Autorisierungsprotokoll, das verwendet werden kann, um Authentifizierungsvorgänge zu vereinigen. Ein OIDC IdP kann verwendet werden, um es mit Okta zu verbinden.
OIDC Spec | |
OAuth 2.0 (Basis von OIDC) |
In unserem Fall schafft der OIDC-Verband ein ‘Vertrauensverhältnis’ zwischen Okta und einem externen OIDC-IDP. Daher verweist Okta eine bestimmte Gruppe von Benutzern an das externe IdP, um sich zu authentifizieren und ein vertrauenswürdiges Ergebnis dieser Authentifizierung zu erhalten, das einige Benutzerinformationen enthält.
Bei Verwendung von OIDC kann ein Discovery-Dokument verwendet werden, um die grundlegenden Informationen über die unterstützten Authentifizierungs- und Autorisierungsvorgänge zu erhalten. Es ist in der Regel öffentlich zugänglich, da es nur öffentliche Informationen enthält.
Welche Werte werden für Föderation verwendet und was bedeuten sie?
Discovery Document
Was | Bedeutung | Beispiel |
|---|---|---|
token_endpoint | Endpunkt, um neue Token für die verschiedenen Vorgänge zu erhalten. In unserem Fall ein Endpunkt, um einen Code gegen ein Token auszutauschen. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/oauth2/v2.0/token |
authorization_endpoint | Endpunkt zur Authentifizierung/Autorisierung eines Benutzers. Ein Benutzer wird zur Authentifizierung an diesen Endpunkt verwiesen. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/oauth2/v2.0/authorize |
jwks_uri | Ort, an dem die Schlüssel für die OpenID-Verbindung gespeichert werden. Diese Schlüssel können sich abwechseln. Aus diesem Grund ist das Dokument nicht dauerhaft statisch. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/discovery/v2.0/keys |
issuer | Ein Wert, um zu überprüfen, wer Wertmarken ausgegeben hat. | https://login.microsoftonline.com/dc79dd1a-883e-438c-b396-dc9fb7f66bf1/v2.0 |
scopes | Eine Reihe von "Themen", nach denen bei der Authentifizierung gefragt werden könnte. Nach der Beglaubigung ergibt sich eine Reihe von Ansprüchen (bestimmte Werte). | ["openid","profile","email","offline_access"] |
Externer Identity Provider
Was | Bedeutung | Beispiel |
|---|---|---|
client id | Eine ID zur Identifizierung der Verbindung zwischen Okta und dem externen Identity Provider. |
|
client secret | Eine Geheimsache, um Vertrauen zwischen Okta und dem externen Identity Provider zu schaffen. |
|
SAML Federation
Security Assertion Markup Language (SAML) ist ein standardisierter Ansatz zur Lösung der Authentifizierung, Autorisierung und Föderation einer Identität. Es handelt sich um ein XML-basiertes Protokoll, das mehr Freiheit, aber auch mehr Komplexität bietet als Protokolle wie OIDC.
Weitere Informationen und Spezifikationen finden Sie über die Links:
Glossar für SAML
IdP: Identity Provider (externes System)
SP: Service Provider (Tivians Federation Identity Provider - Okta)
In unserem Fall wird SAML nur für die Föderation verwendet. Es wird daher nur für die Verbindung von unserem Identity Provider (Okta) zu einem externen Identity Provider verwendet. Angegebene Benutzergruppen authentifizieren sich nicht direkt bei unserem Identitätsprovider, sondern werden unter Verwendung des SAML-Protokolls an den externen Identitätsprovider gesendet.
Im Föderationsszenario fungiert unser Identity Provider als Service Provider (SP), der die Identitäten von einem externen Identity Provider (IdP) zusammenführt. Die Verbindung wird durch den Austausch von Metadaten-Informationen aufgebaut, die sowohl die Abbildung der beiden Dienste als auch Sicherheitsinformationen wie Zertifikate enthalten.
Unsere Identitätslösung - Okta - ist nicht in der Lage, einen Weg zu Metadateninformationen bereitzustellen - sie muss heruntergeladen und auf andere Weise weitergegeben werden.
Externe Identitätsanbieter müssen eine E-Mail-Adresse angeben
Die Konfiguration des Dienstanbieters könnte ein mehrstufiger Prozess sein - er könnte auch das Einfügen von Dummy-Werten in die Okta-Konfiguration und deren späteres Ausfüllen beinhalten.
Wie bei allen Föderationen sollten die E-Mail-Adressen in Kleinbuchstaben gespeichert werden.
Welche Metadateninformationen im aktuellen Fall wichtig sind:
Quelle: SP Metadata / IdP Response | Was | Bedeutung | Beispiel |
|---|---|---|---|
(angefordertes) Attribut | Vorname | Vornahme des Nutzers. Dieser wird mit Oka synchronisiert | Max |
(angefordertes) Attribut | Nachname | Nachname des Nutzers. Dieser wird mit Oka synchronisiert | Mustermann |
(angefordertes) Attribut | E-Mail-Adresse | Einzigartige E-Mail-Adresse. Diese wird mit Okta synchronisiert | |
Attribut (optional) | Mobil-Phone-Nummer |
| 12345-56780907 |
| NameID | Die NameID muss eine eindeutige E-Mail-Adresse des Benutzers sein. Über diese E-Mail-Adresse erhält der Benutzer Sicherheitsinformationen. |
|
© 2022 Tivian XI GmbH