Einführung in verschlüsselte authentifizierte Token

Der Identitätsdienst unterstützt Token verschiedener Typen und Formate um es einem Benutzer zu ermöglichen, sich bei einem bestimmten Rackspace Technology Cloud-Dienst zu authentifizieren.

• Der Token-Typ gibt an, ob der Benutzer bereitgestellt oder verbunden ist.
• Das Token-Format gibt die Zusammensetzung des Tokens selbst an.

Identity hat das Format des Authentifizierungstokens von UUID auf Authenticated Encryption (AE) umgestellt. Rackspace-Ingenieure haben das neue Token-Format im Identitätssystem-Backend implementiert, und die Änderung hat nur minimale Auswirkungen auf Rackspace-Kunden. Der Hauptunterschied besteht darin, dass der vom Identitätsdienst zurückgegebene Authentifizierungstokenwert ein anderes Muster und eine andere Länge hat als die zuvor ausgegebenen UUID-Tokenwerte.

Hinweis: Stellen Sie sicher, dass Sie Best Practices für den Umgang mit Authentifizierungstoken (weiter unten in diesem Artikel) befolgen, insbesondere wenn Sie SDK- oder CLI-Tools verwenden, um mit der RackspaceCloud zu interagieren.

In diesem Artikel werden die beiden unterschiedlichen Token-Formate erläutert und Best Practices für die Arbeit mit Authentifizierungstoken im Allgemeinen bereitgestellt.

Was ist ein AE-Token?

Durch die Verwendung der authentifizierten Verschlüsselung wird ein AE-Token generiert. Die authentifizierte Verschlüsselung gibt eine Möglichkeit an, eine Nachricht zu sichern, sodass andere sie nicht fälschen, ändern oder lesen können.

Authentifizierte Verschlüsselung generiert nicht persistent Token für die Benutzerauthentifizierung. Ein AE-Token enthält alle notwendigen Daten, um zu bestimmen, ob ein gegebenes Token gültig ist, anstatt auf diese Daten zu zeigen. AE-Token haben alle verschlüsselten Metadaten im Token selbst. Da AE-Token alle relevanten Daten enthalten, müssen die Token nicht dauerhaft gespeichert werden. Wenn der Server das Token empfängt, kann er die Token-Metadaten parsen, um festzustellen, ob sie gültig sind.

Aufgrund der Verschlüsselung variiert die Größe eines AE-formatierten Tokens. Der Identitätsdienst begrenzt die Größe von AE-formatierten Token auf 250 Bytes.

Das folgende Beispiel zeigt ein Token-Objekt aus der Authentifizierungsantwort mit einer AE-Token-ID.

"token": {
      "id": "ABCDEF7RbnU-LLWJ1J8PeHRGMz2Cf3rPUG_a25hQRWTcL7tH231H7ubr6y1EkRi_curq6PqJV-pCiIADZrwFtCexcy9MVO3eckgGWqDqnxvXaUMF7XA_reFwwp3pNu_7p9uXofGmiueccwrA",
      "expires": "2015-08-20T23:51:19.055Z",
       "tenant": {
       "id": "123456",
       "name": "123456"
         }

Was ist ein UUID-Token?

Authentifizierungstoken, die das UUID-Tokenformat verwenden, sind dauerhaft Token. Wenn sich ein Benutzer erfolgreich authentifiziert, generiert der Identitätsdienst einen 32-stelligen UUID-Tokenwert und speichert ihn in einer dauerhaften Speichereinheit am Back-End. Der Dienst speichert auch Metadaten zu diesem Token, z. B. Ablaufzeitstempel, an wen das Token ausgestellt wurde usw. Anschließend gibt der Dienst den Tokenwert an den Benutzer zurück, der ihn in nachfolgende Anfragen an Rackspace Cloudservices aufnehmen kann, um die Identität zu bestätigen.

Wenn der Benutzer eine Anfrage mit dem Token sendet, validiert der Identitätsdienst den Tokenwert anhand der im dauerhaften Speicher gespeicherten Daten, um zu bestätigen, dass der Benutzer berechtigt ist, den Vorgang auszuführen. Wenn ein UUID-Token abläuft, muss sich der Benutzer erneut authentifizieren. Dann stellt der Identitätsdienst ein neues Token aus und löscht auch das abgelaufene Token aus der persistenten Back-End-Speichereinheit.

Das folgende Beispiel zeigt ein Token-Objekt aus der Authentifizierungsantwort mit einer UUID-Token-ID.

"token": {
      "id": "b726839ca0fd4d9ead8edbb73f123456",
      "expires": "2015-08-20T23:48:50.793Z",
      "tenant": {
      "id": "123456",
      "name": "123456"
         }

Was ist der Unterschied zwischen UUID- und AE-Tokens?

UUID- und AE-Token unterscheiden sich in ihrer Persistenz, Länge und Speicherung.

• UUID-Token sind persistent . AE-Token sind nicht persistent . Mit einem UUID-Token erhalten Sie bei der Authentifizierung einen Token. Dieses Token bleibt 24 Stunden lang im Back-End-Speicher und das System gibt bei jeder Authentifizierung denselben Wert zurück, bis das Token abläuft. Bei AEtokens ist der Wert nicht persistent, was bedeutet, dass der Wert nicht im Backend gespeichert wird und der Identitätsdienst jedes Mal, wenn sich der Benutzer authentifiziert, einen neuen Tokenwert generiert und zurückgibt.
• UUID-Token sind 32 Zeichen lang. AE-Token variieren in der Größe, aber für den Identitätsdienst haben sie eine Beschränkung von 250 Byte.2 Bei der Implementierung von AE-Token werden Sie feststellen, dass der bei der Authentifizierung zurückgegebene Tokenwert erheblich länger ist als der Wert, der zurückgegeben wird, wenn der Identitätsdienst UUID-Tokens ausgestellt hat.
• Das System speichert die UUID-Token im Identitätsdienst-Backend mit den Metadaten zur Authentifizierung. AE-Token stellen die erforderlichen Authentifizierungsmetadaten innerhalb des verschlüsselten Tokenwerts bereit. Der Identitätsdienst speichert den AE-Tokenwert nicht im Backend-System.

Best Practices für den Umgang mit Authentifizierungstoken

Im Folgenden finden Sie einige Best Practices für den Umgang mit Authentifizierungstoken.

• Achten Sie bei der Authentifizierung beim Identitätsdienst darauf, den zurückgegebenen Tokenwert zwischenzuspeichern.

  Der Identitätsdienst validiert das Authentifizierungstoken in jeder API-Anfrage, bevor er versucht, den Vorgang abzuschließen. Um Ihre API-Operationen zu optimieren und die Systemlast zu reduzieren, speichern Sie das Authentifizierungstoken in einem sicheren Cache oder einer sicheren Datenbank, damit Anwendungen den gespeicherten Wert verwenden können, anstatt dass die Anwendung vor jeder API-Operation eine Authentifizierungsanforderung ausgeben muss. Sie können den zwischengespeicherten Tokenwert wiederverwenden, solange er gültig bleibt.

  Hinweis: Ein Beispiel für das Zwischenspeichern von Anmeldeinformationen mit einem SDK finden Sie unter Zwischenspeichern von Anmeldeinformationen in der php-opencloud-Dokumentation.

• Entwerfen Sie Anwendungen, die sich nach Erhalt eines 401 Unauthorized erneut authentifizieren {.code}-Antwort von einem Dienstendpunkt oder um den Ablauf des Tokens zu überprüfen und sich erneut zu authentifizieren, bevor das Token abläuft.

• Um die Verwaltung von Authentifizierung, Anmeldedaten und Token zu vereinfachen, verwenden Sie eine OpenStack-Befehlszeilen-Client-Anwendung.

Weitere Informationen finden Sie im Abschnitt Authentifizierungstoken verwalten im Identity API 2.0-Handbuch.

Verwenden Sie die Registerkarte „Feedback“, um Kommentare abzugeben oder Fragen zu stellen. Sie können auch mit uns ins Gespräch kommen.