IBM Cloud Docs
Angepasste Identität

Angepasste Identität

Wenn Sie sich authentifizieren, können Sie Ihren eigenen angepassten Identitätsprovider verwenden. Ihr Identitätsprovider kann jedem Authentifizierungsmechanismus entsprechen, der nicht speziell von IBM Cloud® App ID unterstützt wird (einschließlich proprietärer oder traditioneller Provider).

Übersicht

Wenn Sie einen eigenen Identitätsprovider verwenden, können Sie einen angepassten Authentifizierungsablauf erstellen, der Ihre eigenen Protokolle verwendet. Sie haben dann mehr Kontrolle, z. B. Informationen, die Sie gemeinsam nutzen möchten, oder Informationen, die gespeichert werden.

Stellen Sie sicher, dass Sie Ihren angepassten Provider konfigurieren, bevor Sie ihn Ihrer Anwendung hinzufügen.

Wann kann ich diesen Ablauf einsetzen?

Wenn App ID keine direkte Unterstützung für einen bestimmten Identitätsprovider bereitstellt, können Sie den angepassten Identitätsablauf verwenden, um das Authentifizierungsprotokoll mit dem vorhandenen Authentifizierungsablauf von App ID zu verbinden. Beispiel: Sie möchten GitHub oder LinkedIn verwenden, um Ihren Benutzern die Anmeldung zu ermöglichen. Sie können das vorhandene SDK des Identitätsproviders verwenden, um die Benutzerauthentifizierungsinformationen zu vereinfachen, bevor sie mit App ID gepackt und ausgetauscht werden.

Es gibt zahlreiche Szenarios, in denen ein anderer Authentifizierungsablauf erforderlich ist:

  • Proprietäre interne Identitätsprovider
  • Identitätsprovider anderer Anbieter
  • Komplexe Authentifizierungsabläufe, zu denen auch proprietäre Mehrfaktormechanismen gehören können

Gelegentlich verwendet ein traditioneller Provider sein eigenes Authentifizierungsprotokoll. Da der angepasste Identitätsablauf die Authentifizierung vollständig von der Autorisierung entkoppelt, können Sie jedes Authentifizierungsverfahren Ihrer Wahl anwenden und dann die resultierenden Authentifizierungsdaten für App ID bereitstellen. Dazu sind keine Benutzerberechtigungsnachweise erforderlich.

Wie funktioniert dieser Ablauf in technischer Hinsicht?

Der benutzerdefinierte Identitäts-Workflow basiert auf dem JWT-Bearer-Erweiterungstyp, der in Assertion Framework for OAuth 2.0 Authorization Grants [RFC7521 ] definiert ist. Zum Austauschen von Benutzerinformationen für App ID-Token stellt Ihre Authentifizierungsarchitektur eine Vertrauensbeziehung mit App ID her und verwendet dafür ein asymmetrisches RSA-Schlüsselpaar. Sobald die Vertrauensbeziehung hergestellt ist, können Sie den "JWT-Bearer"-Grant-Typ verwenden, um verifizierte Benutzerinformationen in einem signierten JWT für App ID-Token auszutauschen.

Wie sieht der Ablauf aus?

Wie bei allen Authentifizierungsabläufen erfordert die angepasste Identität, dass die Anwendung in der Lage ist, eine Vertrauensbeziehung zu App ID herzustellen, um die Integrität der Benutzerinformationen des Identitätsproviders sicherzustellen. Die angepasste Identität verwendet ein asymmetrisches RSA-Paar aus öffentlichem und privatem Schlüssel, um die Vertrauensbeziehung aufzubauen. Abhängig von Ihren Architekturanforderungen unterstützt die angepasste Identität zwei Vertrauensmodelle, die sich nur in der Speicherposition und der Verwendung des privaten Schlüssels unterscheiden.

Fluss der benutzerdefinierten
Anforderungsflüsse für die benutzerdefinierte

Vom Identitätsanbieter signierter Fluss
  1. Signierung durch Identitätsprovider
Wie bei herkömmlichen OAuth 2.0-Abläufen erstellt das sicherste Vertrauensmodell eine Beziehung zwischen Ihrem Identitätsprovider und dem Autorisierungsserver (in diesem Fall App ID direkt). Bei diesem Modell ist Ihr Identitätsprovider für das Speichern des privaten Schlüssels und das Signieren der JWT-Zusicherungen verantwortlich. Wenn diese Zusicherungen an App ID übergeben werden, werden sie mit dem übereinstimmenden öffentlichen Schlüssel validiert. Dadurch wird sichergestellt, dass die Benutzerinformationen des Identitätsproviders während der Übertragung nicht unbefugt geändert wurden.
Signierter Ablauf der Anwendung
  1. Signierung durch Anwendung
Alternativ kann Ihr Vertrauensmodell auf der Beziehung zwischen Ihrer App und App ID basieren. In diesem Workflow wird Ihr privater Schlüssel in Ihrer serverseitigen Anwendung gespeichert. Nach einer erfolgreichen Authentifizierung ist Ihre App für das Konvertieren der Antwort des Identitätsproviders in ein JWT und das Signieren mit dem privaten Schlüssel verantwortlich, bevor die App das Token an App ID sendet. Da dieser Identitätsprovider keine Beziehung zu App ID hat, wird durch diese Architektur ein schwächeres Vertrauensmodell erstellt. Auch wenn App ID den Informationen vertrauen kann, die von der serverseitigen Anwendung gesendet werden, kann nicht davon ausgegangen werden, dass es sich um die Daten handelt, die ursprünglich vom Identitätsprovider gesendet wurden.

JSON Web Token generieren

Sie können Ihre verifizierten Benutzerdaten in ein benutzerdefiniertes Identitäts-JWT umwandeln, indem Sie ein JSON-Web-Token generieren. Das Token muss mit dem privaten Schlüssel signiert werden, der mit dem vorkonfigurierten öffentlichen Schlüssel übereinstimmt. Eine Liste von Bibliotheken zum Signieren von Token finden Sie unter https://jwt.io/.

Beispiel für ein JWT-Format

{
  // Header
  "alg": "RS256",
  "typ": "JOSE",
  // Payload
  // Required
  "iss": "String", // Should reference your identity provider
  "aud": "String", // Must be the OAuth server URL name
  "exp": "Int",    // Should be a value with a short lifespan
  "sub": "String", // Must be the unique user ID provided by your identity provider

  // Normalized claims (optional)
  "name": "String",
  "email": "String",
  "locale": "String",
  "picture": "String",
  "gender": "String",

  // Custom Scopes to add to access token (optional)
  scope="custom_scope1 custom_scope2"

  // Other custom claims (optional)
  role="admin"
}
JWS-Felder
Feld Beschreibung
iss Muss einen Verweis auf Ihren Identitätsprovider enthalten.
aud Die URL des OAuth-Servers. Format: https://<region>.appid.cloud.ibm.com/oauth/v4/<tenantID>.
exp Die Zeitdauer, für die das Token gültig ist. Aus Sicherheitsgründen sollte das Token eine kurze Lebensdauer haben und spezifisch sein.
sub Die eindeutige Benutzer-ID, die vom Identitätsprovider bereitgestellt wird.
Normalisierte Claims Alle normalisierten Claims werden in dem Identitätstoken bereitgestellt, das als Antwort auf diese Anforderung zurückgegeben wird. Weitere angepasste Claims können mithilfe des Endpunkts /userinfo lokalisiert werden.
Bereich

Standardmäßig enthalten alle App ID-Token eine Gruppe voreingestellter Bereiche (Scopes). Sie können zusätzliche Bereiche anfordern, indem Sie einen der folgenden Schritte ausführen:

  • Geben Sie den Bereich im Bereichsfeld Ihres JWS-Tokens an.
  • Geben Sie den Bereich über den Bereichsparameter 'url-form' der Anforderung /token an.

App ID-Token abrufen

Um die Verbindung zwischen Ihrem angepassten Provider und App ID zu ermöglichen, müssen Sie über App ID-Token verfügen. Um Service-Tokens zu erhalten, tauschen Sie Ihre verifizierten Benutzerinformationen über den Endpunkt /token aus.

Post /token
Content-Type: application/x-www-from-urlencoded
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<payload>
scope="<spaceSeparatedScopeArray>"
Erforderliche Anforderungsvariablen
Variable Beschreibung
Content-type applications/x-www-from-urlencoded
grant_type urn:ietf:params:oauth:grant-type:jwt-bearer
assertion Eine JWS-Nutzdatenzeichenfolge.
Bereich Eine Liste der angepassten Bereiche (durch Leerzeichen getrennt).