Donnerstag, 18. Mai 2017

ForgeRock IDM Docker Beispiel


Einfaches Beispiel wie man Docker Container erstellen kann.

Hierzu benötigen wir einfach lokal Docker installieren.

Forgerock IDM 5.0 kann über Backstage heruntergeladen werden und muss im Dockerfile Verzeichnis als ZIP zur Verfügung stehen

Viel Spaß beim Testen.


Beispiel Dockerfile:

# Copyright (c) 2016-2017 ForgeRock AS. Use of this source code is subject to the
#FROM openjdk:8-jre
FROM openjdk:8-jre-alpine

WORKDIR /opt

# no need to copy Dockerfile!
# ADD Dockerfile /

# Override these to change the JVM:
# ENV JAVA_OPTS -Xmx1024m -server -XX:+UseG1GC

# giving IDM 2GB
ENV JAVA_OPTS -Xmx2048m -server -XX:+UseG1GC

# copy location of the project IDM config
# ENV PROJECT_DIR $PROJECT_DIR


# Download or add OpenIDM nightly build and unzip.
#
# COPY openidm-4.5.0.zip /var/tmp/openidm.zip
COPY IDM-5.0.0.zip /var/tmp/openidm.zip

# libc6-compat is needed by OrientDB as it uses the snappy Java shared library.
# mysql-client will be used for checking if mysql is running.

RUN apk add --no-cache su-exec libc6-compat mysql-client && \
   adduser -D -h  /opt/openidm openidm openidm && \
   unzip -q /var/tmp/openidm.zip && \
   rm -f /var/tmp/openidm.zip  && rm -fr /opt/openidm/samples && rm -f /opt/openidm/conf/repo.orientdb.json && \
   mkdir /opt/openidm/data && mkdir /opt/openidm/workflow

# make all the projects files available in the image
# change this to the config dir you want to test!
COPY ./projects/5conf-managed-object/ /opt/openidm/conf/

# copy workflow files to the project folder
COPY ./projects/workflow/ /opt/openidm/workflow/

# copy scripts for workflow and others into script folder
COPY ./projects/script/ /opt/openidm/script/
#copy data (csv etc.) to the projct folder
COPY ./projects/data/ /opt/openidm/data/
# copy mysql jar
COPY ./bundle/*.jar /opt/openidm/bundle/


COPY docker-entrypoint.sh /opt/openidm/docker-entrypoint.sh
RUN    chown -R openidm:openidm /opt/openidm
WORKDIR /opt/openidm
ENTRYPOINT ["/opt/openidm/docker-entrypoint.sh"]
CMD ["openidm"]
 Beispiel entrypoint.sh


#!/bin/sh
# Docker entry point for OpenIDM.
if [ "$1" = 'openidm' ]; then
    PROJECT_HOME="${PROJECT_HOME:-/opt/openidm}"

    if [ -z "$LOGGING_CONFIG" ]; then
      if [ -n "$PROJECT_HOME" -a -r "$PROJECT_HOME"/conf/logging.properties ]; then
        LOGGING_CONFIG="-Djava.util.logging.config.file=$PROJECT_HOME/conf/logging.properties"
      elif [ -r "$OPENIDM_HOME"/conf/logging.properties ]; then
        LOGGING_CONFIG="-Djava.util.logging.config.file=$OPENIDM_HOME/conf/logging.properties"
      else
        LOGGING_CONFIG="-Dnop"
      fi
    fi
   HOSTNAME=`hostname`
   NODE_ID=${HOSTNAME}
   # set by docker-compose
   # REPO_HOST="${MYSQL_SERVICE_HOST:-mysql}"
   # REPO_PORT="${MYSQL_SERVICE_PORT:-3306}"
   # REPO_USER="openidm"
   # REPO_PASSWORD="openidm"
   KEYSTORE_PASSWORD=changeit
   # Check for secret volumes and use those if present.
   if [ -r secrets/keystore.pin ]; then
      KEYSTORE_PASSWORD=`cat secrets/keystore.pin`
   fi
   O1="-Dopenidm.keystore.password=${KEYSTORE_PASSWORD} -Dopenidm.truststore.password=${KEYSTORE_PASSWORD}"
  # If secrets keystore is present copy files from the secrets directory to the standard location.
  if [ -r secrets/keystore.jceks ]; then
    cp secrets/*  security
    chown -R openidm:openidm security
  fi
  # copy/override the projects files to the existing conf
  # cp /opt/openidm/projects/${with-conf-to-use=5conf}/ /opt/openidm/conf/
  # wait for mysql to start
  while ! mysqladmin ping -h"$REPO_HOST" -u"$REPO_USER" -p"$REPO_PASSWORD" --silent; do
    echo "wating for mysql at $REPO_HOST to wake up..."
    sleep 5
  done
  # should put in a wait for DJ as well!!

   O2="-Dopenidm.repo.host=$REPO_HOST -Dopenidm.repo.port=$REPO_PORT -Dopenidm.repo.user=${REPO_USER} -Dopenidm.repo.password=${REPO_PASSWORD}"
   O3="-Dopenidm.node.id=$NODE_ID"
   # This is the default
   O4="-Dopenidm.fileinstall.enabled=true"
   OPENIDM_OPTS="$O1 $O2 $O3 $O4"
   echo "Using OPENIDM_OPTS:   $OPENIDM_OPTS"
   CLOPTS="-p ${PROJECT_HOME}"
   LAUNCHER="org.forgerock.commons.launcher.Main"
   # For OpenIDM-5.5.0 use the following:
   # LAUNCHER="org.forgerock.openidm.launcher.Main"

    echo "Starting OpenIDM"
    echo "maybe this helps: cd $PROJECT_HOME"
    # starting path should be the openidm PROJECT_HOME
    cd $PROJECT_HOME

   # The openidm user can not mount the hostPath volume in Minikube due to VirtualBox permissions,
   # so we run as root for now.
   #exec su-exec openidm java
   exec java \
        "${LOGGING_CONFIG}" \
        ${JAVA_OPTS} ${OPENIDM_OPTS} \
       -Djava.endorsed.dirs="$JAVA_ENDORSED_DIRS" \
       -classpath /opt/openidm/bin/*:/opt/openidm/framework/* \
       -Dopenidm.system.server.root=/opt/openidm \
       -Djava.endorsed.dirs= \
       -Djava.awt.headless=true \
       ${LAUNCHER}  -c /opt/openidm/bin/launcher.json ${CLOPTS}
fi
exec su-exec openidm "$@"



Montag, 10. April 2017

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.

Montag, 13. März 2017

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:

Montag, 6. Februar 2017

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 Die Säulen eines IRM (von der Kantara Initiative gesehen!) 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".

Montag, 2. Januar 2017

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 [tippy title="Identity Relationship Management" href="https://kantarainitiative.org/irmpillars/"] Detaillierter Beschreibung von IRM [/tippy] sprechen.

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

Montag, 15. Juni 2015

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)