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.