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)

 

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 – 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