Identitätsanbieter verwalten
Konfiguriere benutzerdefinierte Identitätsanbieter (IdPs) für SAML- oder OIDC-Single-Sign-On, damit sich die Benutzer deiner Organisation mit ihren bestehenden Unternehmensanmeldedaten authentifizieren können.
Die Verwaltung von Identitätsanbietern steht ausschließlich Admins des Enterprise-Plans zur Verfügung.
Konfiguriere einen benutzerdefinierten Identitätsanbieter (IdP), um Single Sign-On (SSO) für deine Organisation zu aktivieren. Wenn du einen IdP konfigurierst, leitet Bob dich bei der Anmeldung bei IBM Bob in der IDE, Bob Shell und Bob Web zur Authentifizierung dorthin weiter.
Mit Bob kannst du SAML- und OpenID Connect (OIDC)-Identitätsanbieter konfigurieren. Verwende das Protokoll, das zur Identitätsplattform deiner Organisation passt.
SSO-Protokollkompatibilität
IBM Bob ist mit den folgenden SSO-Protokollen kompatibel:
- SAML (Security Assertion Markup Language)
- OIDC (OpenID Connect)
Verifizierte OIDC-Anbieter
Du kannst zwar andere OIDC-Anbieter verwenden, die die Konfigurations- und Token-Anforderungen erfüllen, aber die folgenden Plattformen sind verifiziert:
- Auth0
- Keycloak
- Okta
- PingOne
Einen Identitätsanbieter hinzufügen
Das Hinzufügen eines IdPs ist ein zweistufiger Prozess. Zuerst konfigurierst du den IdP und speicherst ihn. Dann fügst du die E-Mail-Domains hinzu, die ihn verwenden.
Schritt 1: Den Identitätsanbieter konfigurieren
Öffne die IBM Bob Administration-Seite.
Wähle die Registerkarte Authentication aus.
Klicke auf Add IdP. Gib einen Namen für den IdP ein. Wähle den IdP-Typ aus: SAML oder OIDC. Generiere deine Service Provider (SP) Credentials.
Bob benötigt einen SP Private Key und ein SP-Zertifikat, um SAML-Authentifizierungsanfragen zu signieren. Du musst diese selbst mit dem openssl Command-Line-Tool generieren.
Wenn du bereits ein SP-Schlüsselpaar und -Zertifikat hast, überspringe den nächsten Schritt.
Führe den folgenden Befehl aus, um den SP Private Key zu generieren:
openssl genrsa -out sp_private_key.pem 2048Führe dann diesen Befehl aus, um das SP-Zertifikat aus dem Private Key zu generieren. Ersetze die /CN-, /O- und /C-Werte durch einen beschreibenden Zertifikatsnamen, deinen Organisationsnamen und deinen zweistelligen Ländercode:
openssl req -new -x509 -key sp_private_key.pem -out sp_certificate.pem -days 365 -subj "/CN=Bob SAML SP/O=IBM/C=US"Die Datei sp_certificate.pem muss auch zu deinem IdP hochgeladen werden, damit dieser Signaturen von Anfragen von Bob verifizieren kann.
Gib die Konfigurationsdetails für den IdP ein. Überprüfe die protokollspezifischen Anforderungen in den folgenden Abschnitten. Klicke auf Save.
Der IdP wird erstellt und erscheint in der Tabelle auf der Registerkarte Authentication.
SAML-Konfiguration
SAML erfordert die folgenden Konfigurationsdetails:
Identity Provider-Felder — beziehe diese von deinem IdP:
idp_entity_id— die eindeutige Kennung für den IdP (zum Beispielhttps://idp.example.com)idp_sso_url— die SSO-URL, an die Bob Authentifizierungsanfragen sendetidp_certificate— das PEM-kodierte X.509-Zertifikat, das zur Verifizierung von SAML-Antworten vom IdP verwendet wird
Service Provider-Felder — verwende die im vorherigen Schritt generierten Dateien:
sp_private_key— der Inhalt vonsp_private_key.pemsp_certificate— der Inhalt vonsp_certificate.pem
Optionale Felder:
idp_slo_url— die Single Logout-URL des IdPs. Single Logout ist in Bob noch nicht vollständig implementiert.
Ordne im Abschnitt Attribute mapping die Benutzerattribute des IdPs den Benutzerfeldern von IBM Bob zu. Das Mapping-Format ist Bob-Attributname → IdP-Attributname oder URI. Überprüfe deine IdP-Konfiguration für die korrekten Attributnamen.
email(erforderlich) — die E-Mail-Adresse des Benutzersname(optional) — der vollständige Anzeigename des Benutzersgiven_name(optional) — der Vorname des Benutzersfamily_name(optional) — der Nachname des Benutzersgroups(optional) — die Gruppen des Benutzers
IDP-Administrator: Registrierung eines neuen OIDC-Clients
Bevor ein Bob-Instanzadmin einen OIDC-IdP-Datensatz in Bob konfigurieren kann, muss ein IdP-Administrator zuerst eine OIDC-Anwendung (Client) im Identity Provider erstellen. Die dabei erzeugten Werte gibt der Bob-Instanzadmin beim Hinzufügen des IdP in Bob ein.
Anwendungstyp und Grant Type
Erstelle im Identity Provider eine Web-Anwendung (serverseitig / vertraulicher Client) und aktiviere den Grant Type Authorization Code. Bob verwendet ausschließlich den Authorization Code Flow — wähle nicht Implicit, Device Code oder Client Credentials.
Redirect-URI
Registriere die folgende Callback-URL in der OIDC-Anwendung. Die meisten Anbieter prüfen die Zeichenkette exakt, kopiere sie daher genau:
https://api.us-east.bob.ibm.com/authn/v1/auth/callbackScopes, die am Client aktiviert werden müssen
| Scope | Zweck | Erforderlich |
|---|---|---|
openid | Aktiviert den OIDC-Modus und gibt einen id_token zurück | Ja |
email | Stellt die E-Mail-Adresse des Benutzers im id_token oder über den Userinfo-Endpunkt bereit | Ja |
offline_access | Erteilt einen refresh_token zusammen mit dem Access Token | Ja, für die meisten Anbieter |
Bob erfordert, dass bei jeder Authorization-Code-Exchange-Antwort ein refresh_token vorhanden ist. Wenn dein Anbieter Refresh Tokens über einen anderen Mechanismus ausstellt (z. B. einen anbieterspezifischen Scope oder bedingungslos bei jedem Code-Austausch), konfiguriere dies entsprechend — stelle aber sicher, dass der Client Refresh Tokens empfangen darf. Wenn kein refresh_token zurückgegeben wird, wird die Anmeldung abgebrochen.
Authentifizierungsmethode am Token-Endpunkt
Konfiguriere die Authentifizierungsmethode am Token-Endpunkt der OIDC-Anwendung auf client_secret_post. Bob sendet client_id und client_secret als Formular-Body-Parameter bei jeder Token-Anfrage. client_secret_basic, private_key_jwt und none werden nicht akzeptiert.
Token-Einstellungen
| Einstellung | Erforderlicher Wert |
|---|---|
| Access-Token-Format | Beliebig (JWT oder opaque — Bob wertet das IdP-Access-Token nicht direkt aus) |
| ID-Token | Muss bei jedem Authorization-Code-Austausch und bei jeder Token-Erneuerung ausgestellt werden |
| ID-Token-Signaturalgorithmus | RS256, ES256 oder PS256 |
| Refresh-Token-Rotation | Du kannst Refresh-Token-Rotation verwenden. Bob speichert das neue Token bei jeder Erneuerung. Wenn dein Anbieter Refresh Tokens rotiert, stelle sicher, dass der Anbieter das vorherige Token erst nach dem Empfang des Ersatztokens durch Bob ungültig macht (Standard-Rotationsverhalten, kein Einmal-Use ohne Toleranzfenster). |
Werte, die an den Bob-Instanzadmin übergeben werden
Sobald die Client-Anwendung erstellt wurde, übergib dem Bob-Instanzadmin die folgenden Werte:
| Wert | Wo zu finden | Bob-Konfigurationsfeld |
|---|---|---|
| Client-ID | Seite mit Anwendungszugangsdaten | client_id |
| Client-Secret | Seite mit Anwendungszugangsdaten | client_secret |
| Authorization-Endpunkt-URL | OIDC-Endpunkte des Anbieters oder .well-known/openid-configuration | authorization_endpoint |
| Token-Endpunkt-URL | OIDC-Endpunkte des Anbieters oder .well-known/openid-configuration | token_endpoint |
| JWKS-URI | OIDC-Endpunkte des Anbieters oder .well-known/openid-configuration | jwks_uri |
| Issuer-URL | OIDC-Endpunkte des Anbieters oder .well-known/openid-configuration | issuer |
| Userinfo-Endpunkt-URL (optional) | OIDC-Endpunkte des Anbieters oder .well-known/openid-configuration | userinfo_endpoint |
Die meisten Anbieter veröffentlichen alle Endpunkt-URLs unter https://<deine-anbieter-domain>/.well-known/openid-configuration.
OIDC-Konfiguration
Du kannst OIDC Provider Discovery nutzen. Klicke auf die Schaltfläche Retrieve configuration, um die Endpunktfelder automatisch aus dem .well-known/openid-configuration-Dokument deines Anbieters zu befüllen, oder gib jede Endpunkt-URL manuell ein.
OIDC erfordert die folgenden Konfigurationsdetails:
| Feld | Erforderlich | Beschreibung |
|---|---|---|
client_id | Ja | Die bei deinem Identitätsanbieter registrierte Client-ID. |
client_secret | Ja | Das Client-Secret für die registrierte Anwendung. Bob speichert dies sicher und gibt es niemals in API-Antworten zurück. |
scopes | Ja | Die während des Autorisierungsablaufs angeforderten Scopes. Diese Liste muss openid enthalten. Sie enthält normalerweise auch email und den anbieterspezifischen Scope zur Ausstellung eines Refresh-Tokens, wie z. B. offline_access. |
authorization_endpoint | Ja | Die HTTPS-Autorisierungs-URL, zu der Bob Benutzer zur Anmeldung weiterleitet. |
token_endpoint | Ja | Die HTTPS-Token-URL, die zum Austausch des Autorisierungscodes gegen Tokens verwendet wird. |
jwks_uri | Ja | Die HTTPS-URL des JSON Web Key Set (JWKS), das zur Verifizierung der Signatur von id_token-Antworten verwendet wird. |
issuer | Nein | Die HTTPS-Issuer-ID für den Identitätsanbieter. |
prompt | Nein | Der OIDC-prompt-Wert, der an die Autorisierungsanfrage weitergeleitet wird. |
OIDC verwendet kein Attribute mapping. Bob liest die E-Mail-Adresse des Benutzers direkt aus dem email-Claim im id_token.
OIDC-Beispielkonfiguration
{
"authorization_endpoint": "https://corp.okta.com/oauth2/default/v1/authorize",
"token_endpoint": "https://corp.okta.com/oauth2/default/v1/token",
"issuer": "https://corp.okta.com/oauth2/default",
"client_id": "0oa1b2c3d4e5f6g7h8i9",
"client_secret": "super-secret-value",
"scopes": ["openid", "email", "offline_access"]
}OIDC-Anforderungen und -Einschränkungen
- Bob benötigt ein
refresh_tokenin der Antwort des Autorisierungscode-Austauschs. Wenn dein Anbieter keines zurückgibt, schlägt die Anmeldung fehl. - Bei den meisten Anbietern löst das Hinzufügen von
offline_accesszuscopesdie Ausstellung von Refresh-Tokens aus. Einige Anbieter verwenden ein anderes Verhalten, überprüfe daher die Dokumentation deines Anbieters. - OIDC-Back-Channel-Logout ist nicht verfügbar.
- Wenn dein Anbieter seine Endpunkt-URLs ändert, aktualisiere die IdP-Konfiguration in Bob.
Schritt 2: Domain-Filter hinzufügen
Füge nach dem Speichern des IdPs die E-Mail-Domains hinzu, die ihn zur Authentifizierung verwenden sollen.
Suche auf der Registerkarte Authentication den soeben erstellten IdP und öffne seine Einstellungen. Füge im Abschnitt Domain filters die E-Mail-Domains hinzu, die diesen IdP verwenden sollen. Benutzer, deren E-Mail-Adressen einer konfigurierten Domain entsprechen, werden bei der Anmeldung zu diesem IdP weitergeleitet. Speichere deine Änderungen.
Jede E-Mail-Domain kann nur einem IdP zugeordnet werden. Wenn eine Domain bereits von einem anderen IdP verwendet wird, kann die Konfiguration erst gespeichert werden, wenn der Konflikt behoben ist. Jede Domain muss außerdem verifiziert werden, bevor SSO erzwungen wird. Siehe Domain-Eigentümerschaft verifizieren.
Domain-Eigentümerschaft verifizieren
IBM Bob verlangt, dass du nachweist, dass deine Organisation jede Domain besitzt, bevor SSO für sie erzwungen wird. Die Verifizierung erfolgt durch Hinzufügen eines DNS-TXT-Eintrags zu deiner Domain.
Öffne die IBM Bob Administration-Seite. Wähle die Registerkarte Authentication aus. Wähle den IdP aus, der die Domain enthält, die du verifizieren möchtest. Suche im Abschnitt Domain filters die Domain und kopiere den angezeigten Verifizierungscode. Füge bei deinem DNS-Anbieter einen TXT-Eintrag für die Domain im folgenden Format hinzu:
bob-verify=<verification-code>Ersetze verification-code durch den aus dem Abschnitt Domain filters kopierten Code. Kehre zur Registerkarte Authentication zurück und klicke für die Domain auf Check verification.
Der Domain-Verifizierungsstatus wird auf Verified aktualisiert, sobald IBM Bob den TXT-Eintrag erfolgreich erkennt. DNS-Änderungen können sich einige Zeit lang ausbreiten.
Einen Identitätsanbieter entfernen
Öffne die IBM Bob Administration-Seite. Wähle die Registerkarte Authentication aus. Suche den IdP, den du entfernen möchtest, und klicke auf Delete. Klicke im Bestätigungsdialog auf Confirm.
Durch das Löschen eines IdPs wird die SSO-Konfiguration für alle zugehörigen Domains entfernt. Benutzer, die sich über diesen IdP authentifiziert haben, müssen sich mit einer anderen Methode anmelden. Eine Warnung wird angezeigt, wenn der IdP verifizierte Domains hat.
Erstellen und Konfigurieren von Teams
Richten Sie Teams ein, um Benutzer zu organisieren und Ausgaben für verschiedene Gruppen in Ihrer IBM Bob Enterprise-Organisation zu kontrollieren.
Aktivitätsprotokoll prüfen
Lade Audit-Log-Dateien für deine IBM Bob Enterprise-Organisation herunter und prüfe sie, um Authentifizierungsereignisse und Administratoraktivitäten zu überwachen.