Logo BKA Dokumentation Logo EGIZ

MOA-ID (Identifikation)

Informationen für Modul-Entwickler

Inhalt

  1. Übersicht

  2. Prozesse

    1. Aufgaben (Tasks)
    2. Transitions

  3. Module

    1. Metadaten und Prozessauswahl

    2. Discovery

      1. Service Loader Mechanismus
      2. Spring Bean Discovery

  4. Hinweise

1 Übersicht

MOA-ID ab Version 2.2 ermöglicht die dynamische Erweiterung um zusätzliche Funktionalität durch die Nutzung der integrierten Modularchitektur.
Entwickler können nun eigene Prozesse, um die MOA-ID erweitert werden soll, definieren (z.B. Unterstützung eines speziellen Authentifizierungsworkflows, Erweiterung um Vollmachten oder ausländische Identitäten etc). MOA-ID bietet eine Ablaufsteuerung ("ProcessEngine"), die einzelne Aufgaben (Tasks) entsprechend einer vorgegebenen Prozessdefinition abarbeiten kann.

Mehrere Prozesse können zu einzelnen Modulen zusammengefasst werden. Ein Modul, typischerweise repräsentiert durch eine separate JAR-Datei, wird automatisch erkannt, sobald sich dieses im Classpath der Anwendung befindet. Damit stehen die in diesem Modul definierten Prozesse MOA-ID automatisch zu Verfügung.

Beim Starten eines Authentifizierungsvorgangs speichert MOA-ID die zu diesem Zeitpunkt zu Verfügung stehenden Informationen (Ergebnis der BKU-Auswahl, Auswahl des Herkunftslandes, Wunsch nach Vollmachten-Nutzung etc.) in eine Datenstruktur ("ExecutionContext"). Module entscheiden dann auf Basis dieser Informationen, ob sie entsprechende Prozesse für den gegebenen Kontext anbieten können. Sobald ein passender Prozess gefunden wurde, beginnt die MOA-ID ProcessEngine mit der Ausführung der darin definierten Aufgaben.

Bei diesen Aufgaben handelt es sich typischerweise um einzelne synchrone oder asynchrone Schritte eines kompletten Authentifizierungsvorgangs wie z.B. das Erstellen eines HTML-Formulars zum Auslesen der Personenbindung (synchron), das Empfangen und Verarbeiten einer Personenbindung (asynchron), das Aushandeln einer Session mit dem Vollmachtenportal (synchron) etc. Jeder Task erhält bei Ausführung automatisch Zugriff auf den ExecutionContext, der von Task zu Task weitergereicht, zum Austausch bzw. Akkumulieren von Daten dient und schließlich auch persistiert wird. Darüber hinaus steht jeweils HttpServletRequest und HttpServletResponse zu Verfügung.

2 Prozesse

Ein Prozess definiert sich primär über seine Tasks, die es in einer bestimmten Abfolge abzuarbeiten gilt. Um welche Tasks es sich handelt und wie die Abfolge unter welchen Bedingungen aussieht wird in einer ProzessDefinition in Form eines XML-Dokuments festgelegt.

Siehe ProcessDefinition.xsd.
 

Die folgende Prozessdefinition zeigt als Beispiel den internen Standard-Authentifizierungsprozess von MOA-ID. Dieser unterstützt Vollmachten uns ausländische Identitäten:
 

<?xml version="1.0" encoding="UTF-8"?> <pd:ProcessDefinition id="DefaultAuthentication" xmlns:pd="http://reference.e-government.gv.at/namespace/moa/process/definition/v1"> <pd:Task id="createIdentityLinkForm" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.CreateIdentityLinkFormTask" /> <pd:Task id="verifyIdentityLink" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.VerifyIdentityLinkTask" async="true" /> <pd:Task id="verifyAuthBlock" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.VerifyAuthenticationBlockTask" async="true" /> <pd:Task id="verifyCertificate" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.VerifyCertificateTask" async="true" /> <pd:Task id="getMISSessionID" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.GetMISSessionIDTask" async="true" /> <pd:Task id="certificateReadRequest" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.CertificateReadRequestTask" /> <pd:Task id="prepareAuthBlockSignature" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.PrepareAuthBlockSignatureTask" /> <pd:Task id="getForeignID" class="at.gv.egovernment.moa.id.auth.modules.internal.tasks.GetForeignIDTask" async="true" /> <pd:StartEvent id="start" /> <pd:Transition from="start" to="createIdentityLinkForm" /> <pd:Transition from="createIdentityLinkForm" to="verifyIdentityLink" /> <pd:Transition from="verifyIdentityLink" to="certificateReadRequest" conditionExpression="!ctx['identityLinkAvailable'] || ctx['useMandate']" /> <pd:Transition from="verifyIdentityLink" to="prepareAuthBlockSignature" /> <pd:Transition from="prepareAuthBlockSignature" to="verifyAuthBlock" /> <pd:Transition from="certificateReadRequest" to="verifyCertificate" /> <pd:Transition from="verifyCertificate" to="verifyAuthBlock" conditionExpression="ctx['useMandate']" /> <pd:Transition from="verifyCertificate" to="getForeignID" /> <pd:Transition from="verifyAuthBlock" to="getMISSessionID" conditionExpression="ctx['useMandate']" /> <pd:Transition from="verifyAuthBlock" to="end" /> <pd:Transition from="getMISSessionID" to="end" /> <pd:Transition from="getForeignID" to="end" /> <pd:EndEvent id="end" /> </pd:ProcessDefinition>

 

Jede Prozessbeschreibung muss zwingend ein StartEvent und ein EndEvent enthalten. Einzelne Aufgaben sind durch Task-Elemente gekennzeichnet, wobei via Attribut async festgelegt wird ob es sich dabei um einen synchronen (Standardeinstellung) oder um einen asynchronen Task handelt (siehe auch Abschnitt 2.1).

2.1 Aufgaben (Tasks)

Aus technischer Sicht sind Aufgaben einfache Klassen, die die abstrakte Klasse at.gv.egovernment.moa.id.process.springweb.MoaIdTask (moa-id-lib-xy.jar) implementieren. Diese definiert lediglich eine execute-Methode, die aufgerufen wird, sobald der Task von der ProcessEngine gestartet wird. Über diese Methode erhält der Task Zugriff auf den ExecutionContext sowie auf HttpServletRequest und HttpServletResponse. Der HttpServletRequest und der ExecutionContext können nun ausgewertet, bzw. falls notwendig der ExecutionContext und die HttpServletResponse auch manipuliert werden.

Synchrone Tasks werden hintereinander ausgeführt. Trifft die Process Engine auf einen asynchronen Task wird dieser nicht gleich ausgeführt, sondern der Prozess wird zunächst angehalten. Bei asynchronen Tasks handelt es sich meist um Tasks, die zuvor eine Benutzerinteraktion erfordern (z.B. Signatur mit Bürgerkartenumgebung).
Als Beispiel eines asynchronen Tasks wäre ein VerifyIdentityLinkTask zu nennen, der nach Eintreffen der Antwort der Bürgerkartenumgebung auf der DataURL aufgeweckt wird, um eine InfoBoxReadResponse mit der Personenbindung entgegen zu nehmen, diese zu parsen und zu validieren.

Die Aufgabe eines (DataURL-)Servlets, das den jeweiligen Prozess aufweckt, um die Ausführung eines nachfolgenden asynchronen Tasks zu bewirken, übernimmt das interne Servlet at.gv.egovernment.moa.id.auth.servlet.ProcessEngineSignalServlet, das auf die URL /signalProcess gemappt wurde.

Hinweis: Das interne ProcessEngineSignalServlet bzw. dessen Methode getMoaSessionId(HttpServletRequest request) können bei Bedarf durch eine Modulspezifische Implementierung überschrieben werden, um ggf. speziellen Anforderungen in Bezug auf die Ermittlung der jeweiligen MOA Session Id Rechnung zu tragen (STORK PEPS unterstützen keine Parameter wie MOASessionID in der assertion consumer url).
Als Beispiel dazu kann das Servlet at.gv.egovernment.moa.id.auth.modules.stork.STORKProcessEngineSignalServlet des STORK-Moduls dienen.

 
Als Beispiele typischer Tasks können die Klassen im package at.gv.egovernment.moa.id.auth.modules.internal.tasks herangezogen werden.

2.2 Transitions

Die Abfolge der einzelnen Task wird in der Prozessbeschreibung durch die Transition-Elemente bestimmt. Diese weisen die zwei verpflichtenden Attribute from und to auf, die jeweils einen Task (oder StartEvent) referenzieren von (from) dem die ProzessEngine zu (to) weiteren Task (oder EndEvent) traversiert. Betrachtet man einen Prozess als Graphen, dann sind die Tasks als Knoten und die Transitions als Kanten anzusehen.

Jede Prozessausführung beginnt mit dem StartEvent. Von diesem ausgehend werden alle möglichen Transitions zu anderen Tasks untersucht. Die erste Transition, die eine gültige Verbindung zu einem anderen Task aufweist wird für die weitere Prozessausführung herangezogen. Transitions können über das Attribut conditionExpression mit einer Art Policy ausgestattet werden, die festlegt, ob eine Transition verwendet werden kann oder nicht. Dies ermöglicht eine bedingte Ausführung von Tasks.

Expressions müssen sich in eine booleschen Wert auflösen lassen: true (genauso wie ein nicht gesetztes conditionExpression-Attribut) bedeutet, dass die Transition verwendet werden kann, false bedeutet, dass die Transition nicht verwendet wird. Bei den Expressions handelt es sich um Spring EL Expressions, die einen leichten Zugriff auf den ExecutionContext, HttpServletRequestParameter sowie beliebige Spring-Beans ermöglichen:

Bezeichner Beispiel Bedeutung
ctx !ctx['identityLinkAvailable'] Erlaubt das Auswerten einzelner Variablen aus dem ExecutionContext, in diesem Fall einer booleschen Variable identityLinkAvailable
requestParameter requestParameter['myParam'] != null Greift auf RequestParameter aus dem HttpServletRequest zurück und ermöglicht so eine Requestparameter abhängige Abfolge von Tasks.
@ @mySpringBean.isFoo() Greift auf ein Bean (in diesem Fall mit dem Namen mySpringBean) aus dem Spring ApplicationContext zurück.

3 Module

Bei einem Modul handelt es sich grundsätzlich lediglich um eine logische Gruppierung von Prozessen. Module sind bedingt durch ihr automatisches Discovery als eine Art Plug-in zu betrachten, weshalb sie typischerweise auch in eigene JAR-Dateien ausgelagert vorliegen.

Als Beispiel eines solchen Moduls kann das STORK-Modul (moa-id-module-stork-xy.jar) gesehen werden.

3.1 Metadaten und Prozessauswahl

Jedes Modul muss das Interface at.gv.egovernment.moa.id.auth.modules.AuthModule implementieren, über das der ProcessEngine zum einen Metadaten zu Verfügung gestellt werden, diese zum anderen aber auch die Prozessauswahl (siehe Abschnitt 1) abgewickelt wird.

int getPriority()
Über diese Methode gibt das Modul seine Priorität bekannt. Dies beeinflusst die Reihenfolge des Moduls bei der Abfrage nach passenden Prozessen beim Starten eines Authentifizierungsprozesses.
Standardpriorität ist 0. Module die vorgereiht werden sollen, müssen eine höhere Priorität aufweisen.
String[] getProcessDefinitions()
Hierüber gibt das Modul die Prozessdefinitionen (bzw. ResourceUris zu den entsprechenden XML-Dateien) bekannt. Diese werden automatisch von MOA-ID geparst und registriert.
String selectProcess(ExecutionContext context)
Diese Methode wird von MOA-ID beim Starten eines Authentifizierungsprozesses aufgerufen. Der ExecutionContext wird mit den in oben in Abschnitt 1 erwähnten Informationen befüllt und dieser dann der selectProcess-Methode übergeben. Diese entscheidet, ob ein passender Prozess zu Verfügung steht oder nicht. Eine eventuelle modulinterne Priorisierung muss das Modul selbst vornehmen.

Als Beispiel kann die Implementierung des STORK-Moduls herangezogen werden: at.gv.egovernment.moa.id.auth.modules.stork.STORKAuthModuleImpl
Nähere Informationen sind der Javadoc Dokumentation des AuthModule Interfaces zu entnehmen.

3.2 Discovery

Das bereits erwähnte automatische Discovery von Modulen beschränkt sich nun auf das automatische Auffinden der jeweiligen AuthModule-Implementierung. MOA-ID sieht zwei Varianten vor, derartige Implementierung aufzufinden. Welche der beiden zur Anwendung kommt (es können notfalls auch beide kombiniert werden), bleibt dem Modulentwickler überlassen.

3.2.1 Service Loader Mechanismus

Diese Variante sieht vor, dass jedes Modul (d.h. jede JAR-Datei) eine Datei META-INF/services/at.gv.egovernment.moa.id.auth.modules.AuthModule enhält, das die vorhandenen AuthModule-Implementierungen auflistet: 

at.gv.egovernment.moa.id.auth.modules.internal.DefaultAuthModuleImpl
at.gv.egovernment.moa.id.auth.modules.mymodule.MyAuthModuleImpl

Nähere Informationen zu diesem Mechanismus können hier entnommen werden: Javadoc ServiceLoader bzw. Java Tutorials: Creating Extensible Applications

3.2.2 Spring Bean Discovery

Für den Fall, dass Module auf Basis des Spring Frameworks entwickelt werden, kann die AuthModule-Implementierung auch als Spring Bean erfolgen.

MOA-ID sucht beim Starten im Classpath nach Bean-Definitionen, die der Dateinamenskonvention *.authmodule.beans.xml entsprechen und importiert diese. Über diesen Mechanismus können modulspezifische Spring Beans geladen bzw. initialisiert werden, u.a. auch AuthModule-Beans.
 

Beispiel: STORK.authmodule.beans.xml
 

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:context="http://www.springframework.org/schema/context" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd"> <context:annotation-config /> <bean id="storkAuthModule" class="at.gv.egovernment.moa.id.auth.modules.stork.STORKAuthModuleImpl"> <property name="priority" value="0" /> </bean> </beans>

 

4 Hinweise

Um einzelne Funktionen als Plug-In umzusetzen, muss nicht unbedingt ein ganzer Prozess definiert werden. MOA-ID ab Version 2.2 unterstützt die Servlet 3.0 API, was u.a. den Einsatz von @WebServlet-Annotations ermöglicht. Damit entfällt eine statische Registrierung von Servlets im web.xml.

Am Beispiel des MonitoringServlets (at.gv.egovernment.moa.id.auth.servlet.MonitoringServlet), das als separates JAR (moa-id-module-monitoring-xy.jar) ausgeführt wurde, kann dies anschaulich beobachtet werden.