MOA-ID - Informationen f�r Modul-Entwickler

+ MOA-ID ab Version 2.3 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. +

+ 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. +

+ 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. +

+ 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: +

+ 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.
+

<?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> +

Inhalt

+ 1 Übersicht +