Montag, 7. März 2016

Stateless Tokens im bevorstehenden neuen Release OpenAM 13

Die instabile OpenAM Nightly Build Version 13, enthält einige interessante, neue Funktionen: die Fähigkeit, Stateless oder Client-Token zu erstellen.
Dies bringt eine Reihe neuer Anwendungsfälle im Bereich Access Management mit sich: verbesserte Skalierung (weniger Server Speicher, weniger CTS-Replikation (CoreTokenService) und weniger benötigten Server-RAM) und das Potenzial für "offline" Token Introspection für die Autorisierung. Stateless vermisst natürlich einige der wichtigen Funktionen gegenüber Stateful Architekturen.
Was ist ein stateless Token?
Das stateless Token ist im Grunde ein JWT Token, das in die bestehende iPlanetDirectoryPro Cookie gespeichert wird (wenn Zugriff über einen Browser erfolgt ist) oder innerhalb der TokenID Antwort, wenn die Authentifizierung über REST erfolgt ist. Das JWT enthält also alle Inhalte, die auf der Serverseite in einer Stateful Session gespeichert werden würde - dies sind Informationen, wie z.B. Unique Identitfier, Verfallsdatum (uid, ExpiryTime) und andere Profil- oder Session-Attribute die Sie definiert haben.
Um meine Kollegin Ashley Stevenson zu zitieren: "Stateful ist ein Telefonanruf und Stateless ist eine SMS-Nachricht"!
Das Token kann auch unterzeichnet werden und / oder verschlüsselt unter Verwendung von Standard-Algorithmen wie HS256 oder RS256 (die eine öffentliche / private Schlüssel Combo verwendet), so das Hinzufügen ein bisschen Sicherheit (die einen gemeinsamen geheimen Schlüssel verwendet).
Config kann auf Bereichsebene zu tun, was für einen flexiblen Ansatz für die Bereiche an, Benutzern und Anwendungen sollte es zu benutzen macht.
Offline-Authentifizierung
Ein interessantes Nebenprodukt der Verwendung von stateless Token, ist, dass Introspektion kann auf dem Token durchgeführt werden, ohne dass man wieder an den ursprünglichen Quelle - dh OpenAM. Sobald OpenAM gibt das Token (dies würde sein müssen, mindestens kryptografisch signiert und idealerweise verschlüsselt, wenn sie sensible PII für die Zulassung erforderlich enthalten), Prüfung und Dekodierung des Tokens kann durch eine 3rd-Party-Anwendung durchgeführt werden. Das ist ziemlich geradlinig zu tun, wie OpenAM nutzt offene Standards wie JSON Web Tokens (JWT) mit Standard-Signatur und Verschlüsselungsalgorithmen.
Ich eine schnelle Proben node.js Anwendung, die genau das tut erstellt. Es führt die folgenden einfach mit ein paar Zeilen JavaScript und können über eine Befehlszeile für die Prüfung ausgeführt werden.
Authentifiziert sich der vorkonfigurierte stateless Reich in OpenAM über REST
Empfängt die JSON Antwort mit der TokenID Wert und streift die JWT Komponente
Überprüft die Signatur mit Schwanz HS256 und ein gemeinsames Geheimnis von OpenAM konfiguriert, um den Token zu beweisen hat nicht manipuliert wurde
Decodiert das Token von base64 und Introspektion die JSON Inhalte
Der Code ist hier verfügbar.
Die Introspektion Aspekt in Schritt 4, könnte leicht erweitert werden, um zusätzliche Abfragen der Inhalte, wie zum Beispiel auf der Suche nach bestimmten Forderungen oder Profil Attribute, die von einer Anwendung verwendet werden könnte, durchzuführen, um eine Entscheidung über die Genehmigung durchzuführen.
Sehen Sie im folgenden Entwurf Dokumentation für weitere Informationen zu Konfiguration des staatenlosen Tokens und die Auswirkungen der Ansatz über Stateful - http://openam.forgerock.org/doc/bootstrap/admin-guide/index.html#chap-session-state