RFI und Kostenkalkulationen

Warum Open Source für eine Business Strategie immer wichtiger wird!

In dem Video bringt Scott McNealy dies sehr gut auf den Punkt:

  1. Die meisten Kosten Betrachtungen fokussieren sich heute auf Produkt-, Service- und Implementierungskosten. Kosten die für einen eventuellen Ersatz einer Technologie oder Produktes entstehen, werden nicht betrachtet. Diese können ein Vielfaches der Gesamtkostenbetrachtung sein. Ich denke, es gibt hier bestimmt, das eine oder andere Beispiel, das Ihnen hierzu einfällt, wo Sie – gezwungen oder nicht -ein Produkt ablösen mussten. Hier kann Open Source Abhilfe schaffen, denn ein „Replacement“ eines mit offenen Standards arbeitenden Open Source Produktes ist hier weitaus günstiger.
  2. Open Source kann ein sogenanntes „Vendor Lockin“ verhindern (bzw. abmildern).
  3. Open Source ist bei weitem sicherer als jede propritäre Software (Dies wissen wir nicht nur seit der NSA Snowden Affaire). In einem Open Source Produkt z. B. eine Backdoor einzubauen ist sehr schwierig und wird über kurz oder lang auffallen. Einige Open Source Software Hersteller haben hierzu ein neues Modell entwickelt (z.B. auch als Commercial Open Source bezeichnet), dass in Summe die Software noch sicherer macht (In der „Enterprise“ Version sichern strenge Software Entwicklungs- und Sicherungsmaßnahmen ein Produkt Release)

 

Stateless Tokens im bevorstehenden neuen Release OpenAM 13

Orginalbeitrag von Simon Moffatt 

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

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)

 

Digitale Business Transformierung unterstützen

Einer der wichtigsten IT Bewegungen ist sicherlich „Digital Business Transformation“, also eine komplett Neuausrichtung einer Unternehmens IT im gesamten Kontext gesehen.

Was ist passiert?

  • Über 40 Jahre wurden die IT Systeme für Interne Dienste ausgerichtet (z.B. Versicherungssummen kalkulieren, Berechnungen aller Arten, Lieferungen erfasst, Rechnungen kalkuliert und gedruckt etc.)
  • Vorraussetzungen für ein neuer Service kann sich während der Implementierung ändern.
  • „Gewachsene“ Systeme können nur schwer nach „neuen Kundenbedürfnissen“ ausgerichtet werden
  • „Kunden“-Kommunikation verändert sich durch die Änderung von Technologien (Internet, Mobile Welt und Cloud). Diese ist nicht mehr aufzuhalten!

Maßnahmen, um diese Transformierung zu unterstützen:

  • Standardisierung
  • Simplifizierung
  • Kunden in den Mittelpunkt stellen
  • Agile Technologie einsetzen

Hier einige Bespiele, wie wir diese wichtige Bewegung unterstützen können:

 

Was ist der Unterschied von Identity Management zu Identity Relationship Management?

Traditionelles Identity und Access Management vergessen oftmals die Belange eines Identity Relationship Managements. Um hier mithalten zu können, sollten wichtige Aspekte bei der Auswahl von Lösungen berücksichtigt werden.

Gründe für eine beschleunigtes Umdenken zu sind:

  • Integration von Partner und Konsumenten
  • Integration von „Internet of Things“, ja, hier meine ich auch online/offline „Dinge“
  • IRM wird als Business „enabler“ gesehen, nicht so sehr als „Kostenblock“

Was sind hier die Wichtigsten Eigenschaften, die ein IRM unterstützen sollte:

  • Möglichkeiten der Skalierung

Reine Stückzahlen Betrachtung lässt uns schnell im Kontext von Partner/Konsumenten und „Internet der Dinge“ schnell > 100 Millionen Einträge erreichen. Sie sollten also auf eine Technologie setzen, die diese Skalierung zulässt. Wenn Authorisierungsdaten hinzukommen, kann sich diese Zahl auch schnell verdoppeln!

  • Schnelle Umsetzung (agile deployment)

Um hier Ihr Business zu unterstützen, sollen neue Services die Sie Partnern/Kunden zur Verfügung stellen wollen, schnell umzusetzen sein. Es sollte also eine Lösung sein, die es Ihnen ermöglicht in Tagen und nicht in Monaten zu einem neuen Service zu kommen, um so kein Business zu verlieren/zu verhindern.

  • Leichtgewichtig (Light-weight)

„Light-weight“ bedeutet im Kontext zu IRM, das die Lösung Ressource schonend (Hardware Voraussetzung/offen für alle Plattformen) zu betreiben ist. Auch für eine Skalierbarkeit ist es wichtig ein offenes und „leichtgewichtiges“, genügsames System zu haben.

  • Modularität

Benötigen Sie für diesen konkreten Service ALLE Module/Funktionen einer Lösung, oder reicht bereits ein kleinerer Ausschnitt daraus. Es sind nicht nur Kosten damit verbunden, sondern auch Komplexität und Kosten des Betriebs (Staging…. Administration etc.). Kann die eingesetzte Lösung nach meinen Bedürfnissen wachsen, ohne dabei die existierenden Funktionen zu verlieren?

  • Schnelles berechnen von Authorisierungsdaten

Zu den Identitäten gehört nicht nur die Relation zu den „Dingen“, Authorisierungsdaten müssen ebenso berücksichtigt werden. Diese können nicht, wie bei einem traditionellen IAM bearbeitet werden, zumindest solange es keine Quantencomputer zur allgemeinen Verfügarkeit gibt ;-). Das System würde sehr schnell an seine Grenzen stoßen.

Weitere spannende Themen (diese würde ich mir gerne für die nächsten Post aufheben) sind: Datenschutz (Ihre Kunden wollen nicht immer „alles“ preisgeben, um bei Ihnen Schuhe zu kaufen), besonders sehe ich hierzu den Kontext zur „anonymen“ Bezahlung. Können Sie den heutigen Datenschutz noch nachkommen, wo befinden sich hier im Kontext von IRM die „Fallstricke“.

Die Säulen eines IRM (von der Kantara Initiative gesehen!

Identity Relationship Management – die neue IAM Evolution?

Identity Management wird heute immer noch stark im Bereich der Verwaltung von internen Mitarbeitern gesehen, doch heute finden sich viele interessante Projekte und Initiativen um Mitarbeiter, Kunden und Partner stärker in Beziehungen miteinander zu bringen.

Viele neue Treiber spielen hier eine Rolle, um diesen Wechsel hin zur „Öffnung“ von Identitäten voranzutreiben:

  • Kunden & „Dinge“ (Internet of Things) über „nur“ interne Mitarbeiter
  • Entwickelte über statische Beziehungen
  • Geschäftseinnahmen über reine „Betriebsaufwendungen“
  • Geschwindigkeit über Prozesse und Tools

Welche Herausforderungen muss sich ein Identity Relationship Management sich heute stellen:

  • Internet mäßige Skalierung, also die Möglichkeit ein IDM mit >Mio. Identitäten auszubauen
  • Grenzenlos über Perimeter, also über Netzwerke, Plattformen (go Mobile) und andere „Grenzen“ hinweg
  • Kontext über Statisch (Adaptive Authentifizierung), also keine starre sondern auch eine riskio-bewertende Authentifizierung)
  • Common API über mehrfache APIs, also offene APis (eigentlich für Alles)
  • Modular über monolithisch, also kein starres Konstrukt, sondern jederzeit erweiterbar
  • Geschwindigkeit über Integration

In den nächsten Beiträgen möchte ich gerne noch ausführlicher auf die einzelnen Punkte eingehen.

Wenn diese Punkte erfüllt sind, kann man von einem  sprechen.

 

 

Detaillierter Beschreibung von IRM

Identity in the Cloud – Heute schon Realität?

Identity Management in the ?! Was bedeutet dies und was ist heute schon realisierbar bzw. sinnvoll?

Gerade noch investierten wir in ein zentrales IdM System, dass wir mit großer Anstrengung mehr oder weniger gut im Griff haben. Was bedeutet jetzt  Identity in the Cloud und was sind aus heutiger Sicht Beweggründe, die für eine Identity in the Cloud sprechen:

  • Betriebskosten senken
  • Immer aktuelle Software / Dienste
  • Näher an Kunden und Lieferanten
  • Synchronisation aller IDs (auch Kunden und andere Externe)
  • Neue Services ermöglichen / beschleunigen
  • Single Signon über Unternehmensgrenzen hinweg

Worauf sollte man achten?
Weiterlesen

Wikipedia Artikel über die Cloud!

Identity in the Cloud – Neuer Blog und alte Schläuche?

20 Jahre ist es bereits her, damals waren noch Schlagworte wie X.500, X.400 und Directory Services absolut Hipp. Die Konzentration verlief hauptsächlich auf das gegenseitige „Anschreien“ von Standards, ob im Messaging oder im Directory Bereich. Dann kam die „Killer“ Anwendung: Meta Directory. Plötzlich sprechen wir miteinander, tauschen Daten aus, finden ganz plötzlich die richtige Telefonnummer des Kollegen. Ja, das waren noch echte Ereignisse und Glücksgefühle!

Wir waren zwar noch sehr begrenzt mit unserer „internen“ Kommunikation und internem Datenaustausch beschäftigt. Konnten wir ja noch gar nicht ahnen, was Google und Co. noch mit uns vorhaben. Man kam allerdings schnell auf das Bedürfnis zu wissen, wer hat wann auf welche Daten von uns zugegriffen. Datenbanken wurden immer Mächtiger und füllten sich stündlich mit unseren Kundendaten, Geschäftsgeheimnissen und Zahlungsdaten. Jemand kam dann auf die Idee diese Daten könnten ja verknüpft miteinander für mein Geschäft ein zusätzlicher Mehrwert darstellen. Buchungsdaten wurden den Kundendaten zugespielt. Der Vertrieb konnte quasi in Echtzeit Vertriebszahlen einsehen und auswerten. Doch wie steht es heute um die Sicherheit dieser Daten? Haben wir es noch im Griff? Wissen wir, wer und wann auf unsere Daten in der Cloud zugreifen? Sollen meine Daten überhaupt in die Cloud?

In meinem neuen Blog möchte ich auf existierende und kommende Themen rund um das Identity Management aufmerksam machen und mich auf folgende Themen konzentrieren:

  • Identity in the Cloud (natürlich ist das auch der Titel meines Blogs ;-))
  • Identity und Social Media
  • Optimierung von Identity Management
  • Selbstservice Dienste
  • Big Data und Identity Management
  • Mobile Computing (BYOD und IdM etc.)
  • BYOID („Bring your own Identity“)
  • Access Governance
  • Entitlement Warehouse
  • Was heißt hier eigentlich adaptive Authentifizierung?
  • Security-as-a-Service – ist das überhaupt möglich?
  • u.v.a.m.

Ich hoffe Sie haben viel Spaß beim Lesen.

Ihr Hanns Nolan