Core Token Service – Verwendungsbeispiele

Was ist ein Core Token Service (CTS) und wie sieht deren Verwendung in der Praxis aus?

Übergeordnete Rollen eines CTS und wie sollte dieser optimal eingesetzt werden:

  • Sollte Zukunftssicher sein und Token in Generischem Format speichern
  • Sollte keine Speicherinformationen an den Caller geben
  • Sollte ein einfaches Token Format besitzen (Einfaches Namens/Value Paar)
  • Es sollte ein CRUD API Interface besitzen
  • Sichere Einschließung von Speicherinformationen und Abrufinfos für einen Caller
  • Gute Performance liefern und der Service sollte scalierbar sein
  • Einfache Handhabung der gespeicherten Token
  • Administration über einen REST Endpoint zur Verfügung stellen

Unterschiede von HA (High Availability) und Session Fail Over (SFO) Funktionalität?

  • HA bietet bei reduzierter Kapazität ein weiteres Erreichen des Services, auch wenn eine Instanz nicht mehr erreichbar sein sollte
  • SFO bietet  eine spezifische Funktionalität das es erlaubt, bei nicht erreichen des Home Token Services, daß sich ein Benutzer nicht mehr neu einloggen muss.

Es sollte also immer an erster Stelle stehen, ob man HA überhaupt benötigt.

Ein CTS sollte aber immer folgende Grundfunktionalität bieten:

  • Session Failover: User Session sind persistent im CTS
  • OAuth 2.0: Access Token sind persistent als Teil des Authorisation Grant Flow.
  • SAML Federation: generierte Assertions im Prozess sind persistent.
  • UMA: Privacy Grant Decisions sind persistent.

Interne Funktionen werden benötigt, um eine gute Performance zu erreichen. Ein CTS sollte also immer Konfigurations- und Tuning Optionen enthalten. Jede Änderung der Session muss also im persistenten CTS Store geändert werden. Es handelt sich im Wesentlichen um diese Funktionen:

  1. User Login -> CTS Operation = CREATE
  2. User Logout = DELETE
  3. Policy Agent Validate = UPDATE
  4. REST Authenticate = CREATE
  5. REST Validate = UPDATE
  6. REST isActive (refresh = false) = NONE (Caching)

Hier einige Empfehlungen für eine bessere Session Performance:

  • Einsatz von „Sticky Load Balancing„: amlbcookie setzt Session auf einen Home CTS für das Routing des Load Balancers.
  • Reduzierter Crosstalk verhindert Performance Einbußen bei extensiven Einsatz von REST calls.
  • Session Inhalte: Reduzierung der CTS Token Größe

Meine persönliche Empfehlung für den Einsatz eines CTS:

Verhindere Überkompliziertheit also nutzen Sie das KISS Prinzip immer zuerst! (Keep it simple and stupid!). Je komplexer Sie die Architektur Ihres HA CTS Clusters wählen, desto schwieriger werden deren Handhabung und Betrieb.

(Beispiel Konfiguration eines CTS finden Sie hier im Link)

 

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.