AuthenticationServer.verifyIdentityLink(String sessionID,
- String xmlInfoboxReadResponse)
-
-
- Processes an <InfoboxReadResponse> sent by the
- security layer implementation.
-
- Validates given <InfoboxReadResponse>
- Parses identity link enclosed in <InfoboxReadResponse>
- Verifies identity link by calling the MOA SP component
- Checks certificate authority of identity link
- Stores identity link in the session
- Creates an authentication block to be signed by the user
- Creates and returns a <CreateXMLSignatureRequest>
- containg the authentication block, meant to be returned to the
- security layer implementation
-
AuthenticationServer.verifyAuthenticationBlock(String sessionID,
- String xmlCreateXMLSignatureReadResponse)
-
-
- Processes a <CreateXMLSignatureResponse> sent by the
- security layer implementation.
-
- Validates given <CreateXMLSignatureResponse>
- Parses <CreateXMLSignatureResponse> for error codes
- Parses authentication block enclosed in
- <CreateXMLSignatureResponse>
- Verifies authentication block by calling the MOA SP component
- Creates authentication data
- Creates a corresponding SAML artifact
- Stores authentication data in the authentication data store
- indexed by the SAML artifact
- Deletes authentication session
- Returns the SAML artifact, encoded BASE64
-
-Holds configuration data concerning an online application for use by the MOA-ID Proxy component.
- These include the login type (stateful or stateless), the HTTP authentication type,
- and information needed to add authentication parameters or headers for a URL connection
- to the remote online application.
-
buildConnection(javax.servlet.http.HttpServletRequest request,
- String publicURLPrefix,
- String realURLPrefix,
- javax.net.ssl.SSLSocketFactory sslSocketFactory)
-
-
- Builds an HttpURLConnection to a URL which is derived
- from an HttpServletRequest URL, by substitution of a
- public URL prefix for the real URL prefix.
- The HttpURLConnection has been created by URL.openConnection(), but
- it has not yet been connected to by URLConnection.connect().
- The field settings of the HttpURLConnection are:
-
- allowUserInteraction = false
- doInput = true
- doOutput = true
- requestMethod = request.getMethod()
- useCaches = false
-
Builds an HttpURLConnection to a URL which is derived
- from an HttpServletRequest URL, by substitution of a
- public URL prefix for the real URL prefix.
- The HttpURLConnection has been created by URL.openConnection(), but
- it has not yet been connected to by URLConnection.connect().
- The field settings of the HttpURLConnection are:
-
-
allowUserInteraction = false
-
doInput = true
-
doOutput = true
-
requestMethod = request.getMethod()
-
useCaches = false
-
-
Parameters:
request - the incoming request which shall be forwarded
publicURLPrefix - the public URL prefix to be substituted by the real URL prefix
realURLPrefix - the URL prefix to substitute the public URL prefix
sslSocketFactory - factory to be used for creating an SSL socket in case
- of a URL for scheme "https:";
- if null, the default SSL socket factory would be used
Returns:
a URLConnection created by URL.openConnection(), connecting to
- the requested URL with publicURLPrefix substituted by realURLPrefix
Throws:
IOException - if an I/O exception occurs during opening the connection
Returns authentication headers to be added to a URLConnection.
-
Parameters:
authConf - configuration data
authData - authentication data
clientIPAddress - client IP address
Returns:
A map, the keys being header names and values being corresponding header values.
- In case of authentication type "basic-auth", header fields
- username and password.
- In case of authentication type "header-auth", header fields
- derived from parameter mapping and authentication data provided.
- Otherwise, an empty map.
Returns request parameters to be added to a URLConnection.
-
Parameters:
authConf - configuration data
authData - authentication data
clientIPAddress - client IP address
Returns:
A map, the keys being parameter names and values being corresponding parameter values.
- In case of authentication type "param-auth", parameters
- derived from parameter mapping and authentication data provided.
- Otherwise, an empty map.
-This API (Application Programming Interface) document has pages corresponding to the items in the navigation bar, described as follows.
-Package
-
-
-
-Each package has a page that contains a list of its classes and interfaces, with a summary for each. This page can contain four categories:
-
Interfaces (italic)
Classes
Exceptions
Errors
-
-
-Class/Interface
-
-
-
-Each class, interface, inner class and inner interface has its own separate page. Each of these pages has three sections consisting of a class/interface description, summary tables, and detailed member descriptions:
-
Class inheritance diagram
Direct Subclasses
All Known Subinterfaces
All Known Implementing Classes
Class/interface declaration
Class/interface description
-
-
Inner Class Summary
Field Summary
Constructor Summary
Method Summary
-
-
Field Detail
Constructor Detail
Method Detail
-Each summary entry contains the first sentence from the detailed description for that item. The summary entries are alphabetical, while the detailed descriptions are in the order they appear in the source code. This preserves the logical groupings established by the programmer.
-
-Use
-
-Each documented package, class and interface has its own Use page. This page describes what packages, classes, methods, constructors and fields use any part of the given class or package. Given a class or interface A, its Use page includes subclasses of A, fields declared as A, methods that return A, and methods and constructors with parameters of type A. You can access this page by first going to the package, class or interface, then clicking on the "Use" link in the navigation bar.
-
-Tree (Class Hierarchy)
-
-There is a Class Hierarchy page for all packages, plus a hierarchy for each package. Each hierarchy page contains a list of classes and a list of interfaces. The classes are organized by inheritance structure starting with java.lang.Object. The interfaces do not inherit from java.lang.Object.
-
When viewing the Overview page, clicking on "Tree" displays the hierarchy for all packages.
When viewing a particular package, class or interface page, clicking "Tree" displays the hierarchy for only that package.
-
-
-Deprecated API
-
-The Deprecated API page lists all of the API that have been deprecated. A deprecated API is not recommended for use, generally due to improvements, and a replacement API is usually given. Deprecated APIs may be removed in future implementations.
-
-Index
-
-The Index contains an alphabetic list of all classes, interfaces, constructors, methods, and fields.
-
-Prev/Next
-These links take you to the next or previous class, interface, package, or related page.
-Frames/No Frames
-These links show and hide the HTML frames. All pages are available with or without frames.
-
-
-Serialized Form
-Each serializable or externalizable class has a description of its serialization fields and methods. This information is of interest to re-implementors, not to developers using the API. While there is no link in the navigation bar, you can get to this information by going to any serialized class and clicking "Serialized Form" in the "See also" section of the class description.
-
-
-
-This help file applies to API documentation generated using the standard doclet.
-
-
-
Builds an HttpURLConnection to a URL which is derived
- from an HttpServletRequest URL, by substitution of a
- public URL prefix for the real URL prefix.
- The HttpURLConnection has been created by URL.openConnection(), but
- it has not yet been connected to by URLConnection.connect().
- The field settings of the HttpURLConnection are:
-
- allowUserInteraction = false
- doInput = true
- doOutput = true
- requestMethod = request.getMethod()
- useCaches = false
-
-
Processes a <CreateXMLSignatureResponse> sent by the
- security layer implementation.
-
- Validates given <CreateXMLSignatureResponse>
- Parses <CreateXMLSignatureResponse> for error codes
- Parses authentication block enclosed in
- <CreateXMLSignatureResponse>
- Verifies authentication block by calling the MOA SP component
- Creates authentication data
- Creates a corresponding SAML artifact
- Stores authentication data in the authentication data store
- indexed by the SAML artifact
- Deletes authentication session
- Returns the SAML artifact, encoded BASE64
-
-
Processes an <InfoboxReadResponse> sent by the
- security layer implementation.
-
- Validates given <InfoboxReadResponse>
- Parses identity link enclosed in <InfoboxReadResponse>
- Verifies identity link by calling the MOA SP component
- Checks certificate authority of identity link
- Stores identity link in the session
- Creates an authentication block to be signed by the user
- Creates and returns a <CreateXMLSignatureRequest>
- containg the authentication block, meant to be returned to the
- security layer implementation
-
-
-
-
-
-
-
-
diff --git a/id.server/doc/api-doc/index.html b/id.server/doc/api-doc/index.html
deleted file mode 100644
index 7eb5deff7..000000000
--- a/id.server/doc/api-doc/index.html
+++ /dev/null
@@ -1,22 +0,0 @@
-
-
-
-
-
-
-MOA ID API
-
-
-
-
-<H2>
-Frame Alert</H2>
-
-<P>
-This document is designed to be viewed using the frames feature. If you see this message, you are using a non-frame-capable web client.
-<BR>
-Link to <A HREF="at/gv/egovernment/moa/id/data/AuthenticationData.html">Non-frame version.</A>
-
diff --git a/id.server/doc/api-doc/overview-tree.html b/id.server/doc/api-doc/overview-tree.html
deleted file mode 100644
index bcd54df75..000000000
--- a/id.server/doc/api-doc/overview-tree.html
+++ /dev/null
@@ -1,101 +0,0 @@
-
-
-
-
-
-
-MOA ID API: Class Hierarchy
-
-
-
-
-
-
-
-
Lokal installiertes MOA-ID und Microsoft Internet Explorer
-
-Aufgrund eines Fehlers in Microsofts Internet Explorer kann es beim Testen eines lokal installierten Tomcat mit den MOA-ID-Modulen zu Fehlern kommen, da ein Redirect von der Auth-Komponente zur Proxy-Komponente nicht ausgeführt wird.
-
-
-Als Workaround empfiehlt es sich, zum lokalen Testen einen alternativen Browser wie Opera, Mozilla oder Netscape zu verwenden, da diese Probleme dort nicht auftreten.
-
-
-
Lokale Proxy-Komponente und HTTPS
-
-Wenn die Proxy-Komponente lokal läuft und per TLS/SSL aufgerufen wird, kommt es zu einer Fehlermeldung.
-
-
-Workaround: Wenn in der Konfiguration statt 'localhost' der eigene Rechnername verwendet wird, funktioniert die Proxy-Komponente wie gewohnt.
-Zum Herausfinden des Rechnernamens wechselt man unter Windows auf die Kommandozeile und kann mittels 'ipconfig /all' den Rechnernamen herausfinden.
-Unix/Linux-Anwender sehen bspw. mittels 'cat' in der Datei /etc/hosts nach, der Texteintrag hinter der eigenen IP-Adresse spezifiziert den Rechnernamen.
-
-
-
Tomcat und starke Verschlüsselung (>100 Bit)
-
-Serverseitig kann keine starke Verschlüsselung (seitens Tomcat) erzwungen werden.
-
-
-Als Workaround empfiehlt es sich, einen Web-Server wie Apache oder den Microsoft Internet-Information-Server für das SSL-Handling vorzuschalten und dort in der jeweiligen Konfiguration starke Verschlüsselung zu erzwingen.
-
-Die Komponenten des Moduls Identifikation (MOA-ID), MOA-ID-AUTH und MOA-ID-PROXY, sind als plattformunabhängige Webapplikationen ausgelegt.
-MOA-ID-AUTH ist die Basiskomponente des Moduls, und MOA-ID-PROXY ist eine optionale Zusatzkomponente.
-Für den Betrieb dieser Webapplikationen wird eine Java Virtual Machine und ein Java Servlet Container vorausgesetzt.
-
-Dieses Handbuch beschreibt die Installation und Konfiguration von MOA-ID-AUTH und von MOA-ID-PROXY, und die Einrichtung der Systemumgebungen.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Übersicht
-
-Für den Betrieb von MOA-ID-AUTH sind unterschiedliche Szenarien möglich, die unterschiedliche Möglichkeiten bieten und die Installation unterschiedlicher Software- und Hardware-Komponenten erfordern. Dieser Abschnitt gibt einen kurzen Überblick über die notwendige Basis-Installation und optionale weitere Konfigurationsmöglichkeiten.
-
-
-
-
-
-
-
-
-
-
-
-
Basis-Installation von MOA-ID-AUTH
-
-Die Basis-Installation stellt einerseits die minimalen Anforderungen für den Betrieb von MOA-ID-AUTH dar, andererseits dient sie als Ausgangspunkt für weitere (optionale) Konfigurations-Möglichkeiten.
-
-Folgende Software ist Voraussetzung für die Basis-Installation:
-
-
-
JDK 1.3.1 oder JDK 1.4.1
-
Tomcat 4.1.18
-
MOA-ID-AUTH 1.0
-
MOA SP/SS 1.0 (entweder als WebService oder direkt als interne Bibliothek)
-
-
-Um möglichen Versionskonflikten aus dem Weg zu gehen sollten stets die neuesten Versionen von MOA-ID als auch von MOA-SP/SS verwendet werden.
-In diesem Betriebs-Szenario wird MOA-ID-AUTH in Tomcat deployt. Tomcat fungiert gleichzeitig als HTTP- und HTTPS-Endpunkt für MOA-ID-AUTH. Beide Protokolle werden direkt in Tomcat konfiguriert.
-
-Die Webapplikation verwendet Log4j als Logging Toolkit.
-
-
-
-
-
-
-
-
-
-
-
-
Basis-Installation von MOA-ID-PROXY (optional)
-
-Einer Online-Applikation, für die MOA-ID-AUTH die Authentisierung übernimmt, kann die Komponente MOA-ID-PROXY vorgeschaltet werden. Diese Komponente übernimmt die Anmeldedaten von MOA-ID-AUTH, führt die Anmeldung an der Online Applikation durch und schleust in der Folge Daten an die Online-Applikation und Daten an den Benutzer durch.
-
-Die Basis-Installation von MOA-ID-PROXY geschieht im Wesentlichen analog zur Basis-Installation von MOA-ID-AUTH.
-
-MOA-ID-AUTH und MOA-ID-PROXY können in verschiedenen Konstellationen zum Einsatz gebracht werden:
-
-
auf verschiedenen Rechnern
-
auf ein und demselben Rechner in verschiedenen Java Servlet Containern
-
auf ein und demselben Rechner in ein und demselben Java Servlet Container
-
-
-Ausgehend von der Basis-Installation können die optionalen Konfigurationen, die in den nachfolgenden Abschnitten beschrieben werden, unabhängig und in beliebiger Kombination aufgesetzt werden.
-
-
-
-
-
-
-
-
-
-
-
-
Konfiguration mit vorgeschaltetem Webserver (optional)
-
-Den MOA ID Webapplikationen kann jeweils optional ein Webserver vorgeschaltet sein. Unter Microsoft Windows ist das im Regelfall der Microsoft Internet Information Server (MS IIS), auf Unix-Systemen kommt üblicherweise der Apache Webserver zum Einsatz.
-
- Folgende Software ist unter Windows Voraussetzung:
-
-
-
MS IIS 5.0
-
Jakarta mod_jk 1.2.2
-
-
Folgende Software ist unter Unix/Linux Voraussetzung:
-
-
Apache Webserver 2.0.x mit mod_SSL
-
Jakarta mod_jk 1.2.2
-
-
In diesem Fall übernimmt der vorgeschaltete Webserver die Funktion des HTTP- und HTTPS-Endpunktes. Beide Protokolle werden im Webserver konfiguriert.
-
-Mittels mod_jk werden die Webservice-Aufrufe, die im vorgeschalteten Webserver eintreffen, an Tomcat weiter geleitet, bzw. die Antwort von Tomcat wieder an den Webserver zurück übermittelt.
-
-
-
-
-
-
-
-
-
-
-
-
Konfiguration mit PostgreSQL (optional)
-
-Das MOA ID Webservice kann eine PostgreSQL Datenbank nutzen, um:
-
-
-
Log-Meldungen zu speichern
-
-
Für den Zugriff auf PostgreSQL ist die Installation folgender Software Voraussetzung:
-
-
PostgreSQL 7.3
-
-
-
-
-
-
-
-
-
-
-
-
Zusammenfassung
-
-Notwendig für den Betrieb von MOA ID ist eine Basis-Installation. Weitere optionale Konfigurationen können unabhängig und in beliebiger Kombination miteinander durchgeführt werden, um eine bessere Integration der MOA ID Webapplikationen in die vorhandene Betriebs-Infrastruktur zu erreichen.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Referenzierte Software
-
-Die Versionsangaben beziehen sich auf die Versionen, mit denen die MOA ID Webapplikationen entwickelt und getestet wurde. Geringfügig andere Software-Versionen stellen üblicherweise kein Problem dar.
-
-Bei der Basis-Installation von MOA-ID-AUTH und von MOA-ID-PROXY ist grundsätzlich gleichartig vorzugehen.
-Unterschiede sind in der Installationsanweisung angeführt.
-
-
Vorbereitung
-
-Installation des JDK
-Installieren Sie das JDK 1.3.1 oder JDK 1.4.1 in ein beliebiges Verzeichnis. Das Wurzelverzeichnis der JDK-Installation wird im weiteren Verlauf als $JAVA_HOME bezeichnet.
-
-Installation von Tomcat
-Installieren Sie Tomcat in ein Verzeichnis, das keine Leerzeichen im Pfadnamen enthält. Das Wurzelverzeichnis der Tomcat-Installation wird im weiteren Verlauf als $CATALINA_HOME bezeichnet. Hinweis: Tomcat wird in einer Distribution für JDKs ab Version 1.2 und in einer Distribution speziell für JDK 1.4 ausgeliefert. Installieren Sie die zur Version Ihres JDK passende Tomcat-Version.
-
-Entpacken der MOA ID Webapplikation
-Entpacken Sie die ausgelieferten Dateien der Webapplikation (moa-id-auth-x.y.zip oder moa-id-proxy-x.y.zip; ersetzen Sie x.y durch die Releasenummer von MOA-ID-AUTH bzw. MOA-ID-PROXY) in ein beliebiges Verzeichnis. Diese Verzeichnisse werden im weiteren Verlauf als $MOA_ID_INST_AUTH bzw. $MOA_ID_INST_PROXY bezeichnet.
-
-Installation der IAIK JCE, des IAIK LDAP Protocol Handlers und von JSSE (JDK 1.3.1)
-Da Java in der Version 1.3.1 ohne Unterstützung für Kryptographie, LDAP und SSL ausgeliefert wird, müssen diese Funktionalitäten nachträglich installiert werden. Es stehen hierfür zwei Möglichkeiten zur Verfügung:
-1. Installation innerhalb des JDK 1.3.1:
-Die Dateien aus dem Verzeichnis $MOA_ID_INST_AUTH/ext13 (oder $MOA_ID_INST_PROXY/ext13) müssen in das Verzeichnis $JAVA_HOME/jre/lib/ext kopiert werden. Anschließend steht eine Unterstützung für Kryptographie und SSL jeder Java-Anwendung die dieses JDK verwendet zur Verfügung.
-2. Installation ausschließlich für Applikationen innerhalb von Tomcat:
-Um die o.g. Unterstützung nur Tomcat-Anwendungen zu ermöglichen, können die Dateien aus dem Verzeichnis $MOA_ID_INST_AUTH/ext13 (oder $MOA_ID_INST_PROXY/ext13) in ein beliebiges Verzeichnis kopiert werden. Im Folgenden wird dieses Verzeichnis $MOA_ID_EXT genannt. Anschließend muss der Tomcat-Klassenpfad angepasst werden:
-Für Windows-Betriebssysteme ist dafür die Datei $CATALINA_HOME\bin\setclasspath.bat anzupassen:
-Hinter 'set CLASSPATH=%JAVA_HOME%\lib\tools.jar' müssen nun jeweils mit Semikolon getrennt, die Dateien aus $MOA_ID_EXT inklusive der vollständigen Pfadangaben angefügt werden.
-Anschließend sieht diese Zeile beispielsweise folgendermaßen aus:
-
-($MOA_ID_EXT ist durch den tatsächlichen Pfad zu ersetzen)
-Unix/Linux-Anwender verfahren analog mit der Datei $CATALINA_HOME/bin/setclasspath.sh wobei ';' durch ':' zu ersetzen ist.
-Installation der IAIK JCE und des IAIK LDAP Protocol Handlers (JDK 1.4.1)
-Die Dateien aus dem Verzeichnis $MOA_ID_INST_AUTH/ext14 (oder $MOA_ID_INST_PROXY/ext14) müssen in das Verzeichnis $JAVA_HOME/jre/lib/ext kopiert werden. Anschließend steht eine Unterstützung für Kryptographie und SSL jeder Java-Anwendung die dieses JDK verwendet zur Verfügung.
-Zusätzlich müssen die so genannten "Unlimited Strength Jurisdiction Policy Files 1.4.1" heruntergeladen, entpackt und ins Verzeichnis $JAVA_HOME/jre/lib/security kopiert werden. Der Download für diese Dateien findet sich am unteren Ende der Download-Seite für das JDK 1.4.1 in der Sektion "Other Downloads".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Konfiguration von Tomcat
-
-Minimale Konfiguration
-Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. Tomcat wird grundsätzlich mit
-einer funktionierenden Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast enthält und viele Ports
-offen lässt. Die Datei $MOA_ID_INST_AUTH/tomcat/server.xml (bzw. $MOA_ID_INST_PROXY/tomcat/server.xml) enthält eine minimale
-Tomcat-Konfiguration, die je einen Connector für HTTP und für HTTPS freischaltet.
-SSL
-Für den sicheren Betrieb von MOA-ID-AUTH ist die Verwendung von SSL Voraussetzung, sofern nicht ein vorgelagerter WebServer (Apache oder IIS) das SSL-Handling übernimmt.
-Ebenso kann SSL auch für MOA-ID-PROXY verwendet werden.
-Das Dokument Tomcat SSL Configuration HOW-TO gibt einen guten Überblick über die Konfiguration von SSL in Tomcat. Da die für SSL notwendigen Bibliotheken bereits im Abschnitt "Vorbereitung" eingebunden wurden, sind nur noch folgende Schritte notwendig:
-
-
-
Erstellung eines Server-Keystores, welches den privaten Schlüssel des Servers sowie das Server-Zertifikat enthält,
-z.B. mit dem Java Keytool.
-Hinweis: Standardmäßig wird beim Erzeugen eines neuen Keystores im Home-Verzeichnis des Benutzers die Datei ".keystore" angelegt. Möchte man den Dateinamen und Pfad ändern, kann man das dem SSL-Connector in $CATALINA_HOME/conf/server.xml durch hinzufügen des Attributes keystoreFile="NAME DES KEYSTORES" im Element <Factory> bekannt machen. Das zum Keystore gehörende Passwort übergibt man Tomcat mittels des Attributes keystorePass= "PASSWORT DES KEYSTORES" im Element <Factory>.
-
Erstellung eines Keystores mit vertrauenswürdigen Client-Zertifikaten, z.B. mit dem Java Keytool (nur, wenn SSL Client-Authentisierung verwendet werden soll)
-
Falls eine Client-Authentisierung gewünscht ist, muss die Konfiguration des SSL-Connectors in $CATALINA_HOME/conf/server.xml angepasst werden.
-
-
-
-MOA Administrator
-Der Aufruf der URL für die dynamische Konfiguration von MOA-ID-AUTH ist durch eine Passwort-Abfrage geschützt, und kann nur von Benutzern aufgerufen werden, die der Benutzer-Rolle moa-admin zugeordnet werden können.
-Um diese Benutzer-Rolle und einen oder mehrere Benutzer einzurichten, müssen in der Datei $CATALINA_HOME/conf/tomcat-users.xml unter dem Element <tomcat-users> sinngemäß folgende Einträge hinzugefügt werden:
-
-Um MOA-ID-AUTH in Tomcat für den Ablauf vorzubereiten, sind folgende Schritte notwendig:
-
-
Die Datei $MOA_ID_INST_AUTH/moa-id-auth.war wird ins Verzeichnis $CATALINA_HOME/webapps kopiert. Dort wird sie beim ersten Start von Tomcat automatisch ins Verzeichnis $CATALINA_HOME/webapps/moa-id-auth entpackt.
-
Die MOA-ID Konfigurationsdatei und die zugehörigen Verzeichnisse "certs" und "transforms" werden in ein beliebiges Verzeichnis im Filesystem kopiert (z.B. $CATALINA_HOME/conf/moa-id). In $MOA_ID_INST_AUTH/conf/moa-id befindet sich eine funktionsfähige Konfiguration, die als Ausgangspunkt für die Konfiguration von MOA-ID-AUTH dienen kann.
-
Die endorsed Libraries für Tomcat müssen aus dem Verzeichnis $MOA_ID_INST_AUTH/endorsed in das Tomcat-Verzeichnis $CATALINA_HOME/common/endorsed kopieren werden. Folgende Libraries sind für das Deployment im endorsed Verzeichnis vorgesehen:
-
-
Xerces-J-2.0.2 (bestehend aus xercesImpl.jar und xmlParserAPIs.jar)
-
-Eventuell vorhandene Dateien mit dem gleichen Namen müssen ersetzt werden.
-
-
Folgende Java System Properties sind zu setzen:
-
-
moa.id.configuration=Name der MOA ID Konfigurationsdatei. Eine beispielhafte MOA ID Konfiguration ist in $MOA_ID_INST_AUTH/conf/moa-id/ SampleMOAIDConfiguration.xml enthalten.
-
log4j.configuration=URL der Log4j Konfigurationsdatei. Eine beispielhafte Log4j-Konfiguration ist in $MOA_ID_INST_AUTH/conf/moa-id/log4j.properties enthalten.
-
javax.net.ssl.trustStore=Name des Truststores für vertrauenswürdige SSL Client-Zertifikate (optional; nur, wenn SSL Client-Authentisierung durchgeführt werden soll).
-
-Diese Java System-Properties werden Tomcat über die Umgebungsvariable CATALINA_OPTS mitgeteilt
-(siehe Beispiele für Windows und für Linux).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Deployment von MOA-ID-PROXY in Tomcat
-
-Um MOA-ID-PROXY in Tomcat für den Ablauf vorzubereiten, sind folgende Schritte notwendig:
-
-
Die Datei $MOA_ID_INST_PROXY/moa-id-proxy.war wird in ein beliebiges Verzeichnis (bspw. $CATALINA_HOME) kopiert. HINWEIS: Das Verzeichnis darf NICHT $CATALINA_HOME/webapps sein!
- Anschliessend muss in der Datei $CATALINA_HOME/conf/server.xml der Tomcat-Root-Context auf diese Datei gesetzt werden: wenn das war-file sich in $CATALINA_HOME befindet, geschieht dies mit dem Einfügen von folgendem Element innerhalb von <Server>...<Service>...<Engine>...<Host>:
-Anmerkung: Der Root-Context von Tomcat ist normalerweise auskommentiert.
-
Die MOA-ID Konfigurationsdatei und die zugehörigen Verzeichnisse "certs" und "oa" werden in ein beliebiges Verzeichnis im Filesystem kopiert (z.B. $CATALINA_HOME/ conf/moa-id).
-In $MOA_ID_INST_PROXY/conf/moa-id befindet sich eine funktionsfähige Konfiguration, die als Ausgangspunkt für die Konfiguration von MOA-ID-PROXY dienen kann.
-
Die endorsed Libraries für Tomcat müssen aus dem Verzeichnis $MOA_ID_INST_PROXY/endorsed in das Tomcat-Verzeichnis $CATALINA_HOME/common/endorsed kopiert werden. Folgende Libraries sind für das Deployment im endorsed Verzeichnis vorgesehen:
-
-
Xerces-J-2.0.2 (bestehend aus xercesImpl.jar und xmlParserAPIs.jar)
-
-Eventuell vorhandene Dateien mit dem gleichen Namen müssen ersetzt werden.
-
-
Folgende Java System Properties sind zu setzen:
-
-
moa.id.configuration=Name der MOA ID Konfigurationsdatei. Eine beispielhafte MOA ID Konfiguration ist in $MOA_ID_INST_AUTH/conf/moa-id/ SampleMOAIDConfiguration.xml enthalten.
-
log4j.configuration=URL der Log4j Konfigurationsdatei. Eine beispielhafte Log4j-Konfiguration ist in $MOA_ID_INST_AUTH/conf/moa-id/log4j.properties enthalten.
-
javax.net.ssl.trustStore=Name des Truststores für vertrauenswürdige SSL Client-Zertifikate (optional; nur, wenn SSL Client-Authentisierung durchgeführt werden soll).
-
-Diese Java System-Properties werden Tomcat über die Umgebungsvariable CATALINA_OPTS mitgeteilt
-(siehe Beispiele für Windows und für Linux).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Starten und Stoppen von Tomcat
-
-Nach dem Deployment und der Konfiguration kann Tomcat aus seinem Wurzelverzeichnis mit
-
-erreichbar. Die Verfügbarkeit der Anwendung kann überprüft werden, indem die URLs mit einem Web-Browser aufgerufen werden.
-
-
-Dynamische Konfigurations-Updates
-Dynamische Konfigurations-Updates können für MOA-ID-AUTH durch den Aufruf der URL http://hostname:port/moa-id-auth/ConfigurationUpdate (z.B. durch Eingabe in einem Browser) durchgeführt werden. Analog wird die Konfiguration von MOA-ID-PROXY mittels http://hostname:port/ConfigurationUpdate aktualisiert.
-Hinweis: Konfigurationsänderungen für die Online-Applikationen betreffen grundsätzlich sowohl die Auth- als auch die Proxy-Komponente.
-Wenn bspw. das publicURLPrefix der OA geändert wird, muss sowohl für die Auth- als auch für die Proxy-Komponente ein ConfigurationUpdate durchgeführt werden.
-Konnte MOA-ID-AUTH bzw. MOA-ID-PROXY nicht ordnungsgemäß konfiguriert und gestartet werden, geht das aus der Log-Meldung hervor:
-
-FATAL | 03 13:19:06,924 | main | Fehler
- beim Starten des Service MOA ID Authentisierung
-
-bzw.
-
-FATAL | 03 13:19:06,924 | main | Fehler
- beim Starten des Service MOA ID Proxy
-
-In diesem Fall geben die WARN bzw. ERROR Log-Meldungen unmittelbar davor Aufschluss über den genaueren Grund.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Logging
-
-Die MOA ID Webapplikation verwendet Jakarta Log4j für die Ausgabe von Log-Meldungen am Bildschirm bzw. in Log-Dateien. Log4j bietet zahlreiche Konfigurationsmöglichkeiten, die ausführlich im Log4j Handbuch beschrieben sind. Unter anderem gibt es die Möglichkeit, folgende Einstellungen vorzunehmen:
-
-
Das verwendete Log-Level (DEBUG, INFO, WARN, ERROR, FATAL).
-
Name und maximale Größe der Log-Datei(en).
-
Das Aussehen der Log-Einträge.
-
-Es werden folgende Log-Hierarchien verwendet:
-
-
-
moa.id.auth für alle Log-Meldungen aus dem MOA-ID-AUTH Modul
-
moa.id.proxy für alle Log-Meldungen aus dem MOA-ID-PROXY Modul
-
moa.spss.server für alle Log-Meldungen aus dem MOA-SPSS Modul
-
iaik.server für alle Log-Meldungen aus den IAIK Kryptographie-Modulen
-
-
-Als Ausgangspunkt für die Logging-Konfiguration liegt die Datei $MOA_ID_INST_AUTH/conf/moa-id/log4j.properties (bzw. $MOA_ID_INST_PROXY/conf/moa-id/log4j.properties) bei.
-Wird diese Datei als Logging-Konfiguration verwendet, so werden alle Log-Meldungen sowohl in die Konsole, als auch in die Datei $CATALINA_HOME/logs/moa-id.log geschrieben.
-
-Format der Log-Meldungen
-Anhand einer konkreten Log-Meldung wird das Format der MOA ID Log-Meldungen erläutert:
-
- INFO | 09 08:23:59,385 | Thread-8 |
- Anmeldedaten zu MOASession -5468974113772848113
- angelegt, SAML Artifakt
- AAF/BrdRfnMaQVGIbP/Gf9OwDUwwsXChb7nuT+VXQzOoHbV
-
-
-Der Wert INFO besagt, dass die Log-Meldung im Log-Level INFO entstanden ist. Folgende Log-Levels existieren:
-
-
DEBUG: Log-Meldungen im Log-Level DEBUG geben Auskunft über die innere Arbeitsweise des Systems. Sie sind hauptsächlich für Entwickler interessant.
-
INFO: Diese Log-Meldungen geben informative Status-Informationen über den Ablauf der Webapplikation, wie z.B., dass eine neue Anfrage eingelangt ist.
-
WARN: Bei der Ausführung einer Operation sind leichte Fehler aufgetreten. Der Ablauf der Webapplikation ist nicht weiter beeinträchtigt.
-
ERROR: Die Ausführung einer Operation musste abgebrochen werden. Die Webapplikation ist davon nicht beeinträchtigt.
-
FATAL: Es ist ein Fehler aufgetreten, der den weiteren Betrieb der Webapplikation nicht mehr sinnvoll macht.
-
-Der nächste Wert 09 08:23:59,385, gibt den Zeitpunkt an, an dem die Log-Meldung generiert wurde (in diesem Fall den 9. Tag im aktuellen Monat, sowie die genaue Uhrzeit).
-Der Rest der Zeile einer Log-Meldung ist der eigentliche Text, mit dem das System bestimmte Informationen anzeigt. Im Fehlerfall ist häufig ein Java Stack-Trace angefügt, der eine genauere Ursachen-Forschung ermöglicht.
-
-
-
-Wichtige Log-Meldungen
-Neben den im Abschnitt "Starten und Stoppen von Tomcat" beschriebenen Log-Meldungen, die anzeigen, ob die Webapplikation
-ordnungsgemäß gestartet wurde, geben nachfolgenden Log-Meldungen Aufschluss über die Abarbeitung von Anfragen.
-Die Annahme einer Anfrage wird beispielsweise angezeigt durch:
-
-Die 1. Log-Meldung besagt, dass sich ein Benutzer an MOA-ID-AUTH angemeldet und eine eindeutige SessionID zugewiesen bekommen hat.
-Die 2. Log-Meldung informiert darüber, dass die Anmeldedaten des Benutzers unter dem angezeigten SAML Artifakt abgeholt werden können.
-
-Wenn nun versucht wird, eine Transaktion mit einer ungültigen SessionID fortzusetzen erhält man folgende Log-Meldung:
-
-In diesem Fall gibt der mitgeloggte Stacktrace Auskunft über die Art des Fehlers. Der Aufrufer der MOA ID Webapplikation bekommt einen Fehlercode sowie eine kurze Beschreibung des Fehlers als Antwort zurück.
-
-Die Tatsächlich übertragenen Anfragen bzw. Antworten werden aus Effizienzgründen nur im Log-Level DEBUG angezeigt.
-
-Die Konfiguration von MOA ID wird mittels einer XML-basierten Konfigurationsdatei, die dem Schema
-MOA-ID-Configuration-1.1.xsd entspricht, durchgeführt.
-
-Der Ort der Konfigurationsdatei wird im Abschnitt Deployment der Web-Applikation
-in Tomcat beschrieben.
-
-Die folgenden Abschnitte erläutern das Format der Konfigurationsdatei.
-MOA-ID-Configuration.xml zeigt ein Beispiel
-für eine umfassende Konfigurationsdatei.
-
-Enthält die Konfigurationsdatei relative Pfadangaben, werden diese relativ zum Verzeichnis, in dem Tomcat gestartet wurde, interpretiert.
-
-
-
-ConnectionParameter
-Das Element ConnectionParameter enthält Parameter, die MOA-ID für den Aufbau von Verbindungen zu anderen Komponenten
-benötigt. Dieses Element tritt mehrfach in der Konfigurationsdatei auf und wird daher vorab detailliert beschrieben.
-
-Das Attribut URL enthält die URL der Komponente zu der die Verbindung aufgebaut werden soll.
-Wird das Schema https verwendet, können die Kind-Elemente AcceptedServerCertificates
-und ClientKeyStore angegeben werden. Wird das Schema http verwendet müssen keine Kind-Elemente
-angegeben werden bzw. werden diese nicht ausgewertet. Andere Schemas werden nicht unterstützt.
-
-Wird die Verbindung über TLS aufgebaut und erfordert der TLS-Server eine Client-Authentisierung
-mittels Zertifikate, dann muss das Kind-Element ClientKeyStore spezifiziert werden, und es muss
-eine URL enthalten, die einen PKCS#12-Keystore mittels URL-Schema 'file:' referenziert.
-Diesem Keystore wird der private Schlüssel für die TLS-Client-Authentisierung entnommen.
-Das Passwort zum Lesen des privaten Schlüssels wird im Attribut ClientKeyStore/@password konfiguriert.
-Aufgrund der Tatsache, dass starke Verschlüsselung eine Voraussetzung für MOA-ID darstellt, werden clientseitig nur die folgenden Cipher Suites unterstützt:
-
-
SSL_RSA_WITH_RC4_128_SHA
-
SSL_RSA_WITH_RC4_128_MD5
-
SSL_RSA_WITH_3DES_EDE_CBC_SHA
-
-Im Kind-Element AcceptedServerCertificates kann ein Verzeichnisname angegeben werden, in dem die
-akzeptierten Zertifikate der TLS-Verbindung hinterlegt sind. Dieses Verzeichnis wird mittels URL-Schema 'file:' referenziert. In diesem Verzeichnis werden nur Serverzertifikate
-abgelegt. Fehlt dieser Parameter wird lediglich überprüft ob ein Zertifikatspfad zu den im Element <TrustedCACertificates> angegebenen Zertifikaten erstellt werden kann. Falls dies nicht möglich ist, kommt es zu einem Fehlerfall.
-
-
-
-
-
-AuthComponent
-AuthComponent enthält Parameter, die nur die MOA-ID Authentisierungskomponente betreffen.
-Das Element ist optional und muss nicht verwendet werden, wenn auf dem Server keine MOA-ID Authentisierungskomponente
-installiert wird.
-
-Das Element AuthComponent hat vier Kind-Element:
-
-
BKUSelection (optional)
-
SecurityLayer
-
MOA-SP
-
IdentityLinkSigners
-
-
-
-
-
-AuthComponent/BKUSelection
-Das optionale Element BKUSelection enthält Parameter zur Nutzung eines Auswahldienstes für eine
-Bürgerkartenumgebung (BKU). Wird das Element nicht angegeben, dann wird die lokale Bürgerkartenumgebung
-auf http://localhost:3495/http-security-layer-request verwendet.
-
-Das Attribut BKUSelectionAlternative gibt an welche Alternative zur BKU-Auswahl verwendet werden soll. MOA-ID
-unterstützt die Werte HTMLComplete (vollständige HTML-Auswahl) und HTMLSelect (HTML-Code für Auswahl)
-["Auswahl von Bürgerkartenumge-bungen", Arno Hollosi].
-
-Das Kind-Element ConnectionParameter spezifiziert die Verbindung zum Auswahldienst (siehe
-ConnectionParameter), jedoch kann das Kind-Element ClientKeyStore
-nicht angegeben werden.
-
-
-
-
-AuthComponent/SecurityLayer
-Das Element SecurityLayer enthält Parameter zur Nutzung des Security-Layers.
-
-Das Kind-Element TransformsInfo spezifiziert eine Transformation, die für die Erstellung der Signatur
-des AUTH-Blocks als Parameter in den CreateXMLSignatureRequest des Security-Layers integriert werden muss.
-Mehrere unterschiedliche Implementierungen des Security-Layer können durch die Angabe mehrerer TransformsInfo-Elemente unterstützt werden.
-
-Das Attribut TransformsInfo/@filename verweist auf eine Datei, die das globale Element TransformsInfo vom Typ
-TransformsInfo enthält. Das Encoding dieser Datei muss (anders als im Beispiel) UTF-8 sein.
-
-AuthComponent/MOA-SP
-Das Element MOA-SP enthält Parameter zur Nutzung von MOA-SP. MOA-SP wird für die überprüfung der Signatur
-der Personenbindung und des AUTH-Blocks verwendet.
-
-Wird das Kind-Element ConnectionParameter angegeben, dann wird MOA-SP über das Webservice angesprochen, andernfalls
-wird MOA-SP über das API angesprochen.
-
-Das Kind-Element VerifyIdentityLink/TrustProfileID spezifiziert eine TrustProfileID, die für den
-VerifyXMLSignatureRequest zur überprüfung der Signatur der Personenbindung verwendet werden muss.
-
-Die Kind-Elemente VerifyAuthBlock/TrustProfileID und VerifyAuthBlock/VerifyTransformsInfoProfileID
-spezifizieren eine TrustProfileID und eine ID für ein Transformationsprofil, die für den
-VerifyXMLSignatureRequest zur überprüfung der Signatur des Auth-Blocks verwendet werden müssen.
-
-
-
-
-AuthComponent/IdentityLinkSigners
-Dieses Element gibt an von welchen Signatoren die Signatur des IdentityLink erstellt werden musste
-damit der IdentityLink akzeptiert wird. Für jeden Signator muss der X509SubjectName nach RFC 2253
-spezifiziert werden.
-
-ProxyComponent
-ProxyComponent enthält Parameter, die nur die MOA-ID Proxykomponente betreffen.
-Das Element ist optional und muss nicht verwendet werden, wenn auf dem Server keine MOA-ID Proxykomponente
-installiert wird.
-
-Das Element ProxyComponent hat nur das Kind-Element AuthComponent, das die Verbindung zur
-Authentisierungs-komponente beschreibt.
-
-Baut die Proxykomponente die Verbindung zur Authentisierungs-komponente
-über ein Webservice auf, dann muss das Element ConnectionParameter spezifiziert werden.
-
-Baut die Proxykomponente die Verbindung zur Authentisierungs-komponente
-über das API auf, dann wird das Element ConnectionParameter nicht spezifiziert.
-
-
-
-
-OnlineApplication
-Für jede Online-Applikation, die über MOA-ID authentisiert wird, gibt es ein Element OnlineApplication.
-Die Parameter betreffen teils die MOA-ID Authentisierungskomponente, teils die MOA-ID Proxykomponente, teils beide.
-
-Das Attribut OnlineApplication/@publicURLPrefix entspricht dem URL-Präfix der nach außen sichtbaren
-Domäne der Online-Applikation, welcher von der MOA-ID Proxykomponente durch den URL-Präfix der wirklichen
-Domäne (Attribut OnlineApplication/ProxyComponent/ConnectionParameter/@URL) ersetzt wird.
-Es dient als Schlüssel zum Auffinden der Konfigurationsparameter zur Online-Applikation.
-
-Das Element OnlineApplication hat optional zwei Kind-Elemente: AuthComponent und ProxyComponent.
-
-
-
-
-OnlineApplication/AuthComponent
-Das Element OnlineApplication/AuthComponent muss verwendet werden wenn auf dem Server die Authentisierungskomponente
-installiert wird. Es enthält Parameter, die das Verhalten der Authentisierungskomponente bezüglich der Online-Applikation
-konfiguriert.
-
-Das Attribut provideZMRZahl bestimmt, ob die ZMR-Zahl in den Anmeldedaten aufscheint.
-Analog steuern die Attribute provideAUTHBlock und provideIdentityLink, ob die Anmeldedaten
-den Auth-Block bzw. die Personenbindung enthalten. Alle Attribute sind optional und haben den Default-Wert false.
-
-
-
-
-
-OnlineApplication/ProxyComponent
-Das Element OnlineApplication/ProxyComponent muss verwendet werden wenn auf dem Server die Proxykomponente
-installiert wird.
-
-Das optionale Attribut configFileURL verweist auf eine Konfigurationsdatei die dem Schema
-MOA-ID-Configuration-1.1.xsd entspricht mit Dokument-Element
-Configuration.
-Default-Wert: http://<realURLPrefix>/MOAConfig.xml
- (<realURLPrefix> entspricht dem Wert von OnlineApplication/ProxyComponent/ConnectionParameter/@URL)
-
-Das optionale Attribut sessionTimeOut legt das Timeout einer Benutzersession in der
-Proxykomponente in Sekunden fest.
-Default-Wert: 3600
-
-Im optionalen Attribut loginParameterResolverImpl kann der Klassenname eines
-zu verwendenden LoginParameterResolver angegeben werden, welcher die Defaultimplementierung ersetzt.
-
-Im optionalen Attribut connectionBuilderImpl kann der Klassenname eines zu verwendenden
-ConnectionBuilder angegeben werden, welcher die Defaultimplementierung ersetzt.
-
-Im Kind-Element ConnectionParameter ist konfiguriert, wie MOA-ID-PROXY zur Online-Applikation verbindet.
-
-
-
-
-ChainingModes
-Das Element ChainingModes definiert, ob bei der Zertifikatspfad-überprüfung das Kettenmodell
-("chaining") oder das Modell nach PKIX RFC 3280 ("pkix") verwendet werden soll.
-
-Das Attribut systemDefaultMode spezifiziert das Modell, das im Standardfall verwendet werden soll.
-
-Mit dem Kind-Element TrustAnchor kann für jeden Trust Anchor ein abweichendes Modell spezifiziert werden.
-Ein Trust Anchor ist ein Zertifikat, das in TrustedCACertificates spezifiziert ist.
-Ein Trust Anchor wird durch den Typ <dsig:X509IssuerSerialType> spezifiziert.
-Das für diesen Trust Anchor gültige Modell wird durch das Attribut mode spezifiziert.
-
-Gültige Werte für die Attribute systemDefaultMode und mode sind "chaining" und "pkix".
-
-TrustedCACertificates
-Das Element TrustedCACertificates enthält eine URL, die auf ein Verzeichnis verweist, das jene Zertifikate
-enthält, die als vertrauenswürdig betrachtet werden. Diese URL muss mittels URL-Schema 'file:' referenziert werden. Im Zuge der Überprüfung der TLS-Serverzertifikate wird die
-Zertifikatspfaderstellung an einem dieser Zertifikate beendet.
-
-
-
-
-GenericConfiguration
-Das Element GenericConfiguration ermöglicht das Setzen von Namen-Werte Paaren mittels der Attribute
-name und value. Die folgende Liste spezifiziert
-
-
gültige Werte für das name-Attribut,
-
eine Beschreibung
-
gültige Werte für das value-Attribut und (falls vorhanden)
-
den Default-Wert für das value-Attribut.
-
-
-
-
name: DirectoryCertStoreParameters.RootDir
-
-Gibt den Pfadnamen zu einem Verzeichnis an, das als Zertifikatsspeicher im Zuge der TLS-Server-Zertifikatsüberprüfung
-verwendet wird.
-
-value:
-Gültige Werte: Name eines gültigen Verzeichnisses
-Dieser Parameter muss angegeben werden.
-
-
-
-
-
name: AuthenticationSession.TimeOut
-
-Gibt die Zeitspanne in Sekunden vom Beginn der Authentisierung bis zum Anlegen der Anmeldedaten an.
-Wird die Angegebene Zeitspanne überschritten wird der Anmeldevorgang abgebrochen.
-
-
-value:
-Gültige Werte: positive Ganzzahlen
-Default-Wert: 120
-
-
-
-
-
name: AuthenticationData.TimeOut
-
-Gibt die Zeitspanne in Sekunden an, für die die Anmeldedaten in der Authentisierungskomponente zum Abholen
-durch die Proxykomponente oder eine nachfolgende Applikation bereitstehen. Nach Ablauf dieser Zeitspanne werden die Anmeldedaten gelöscht.
-
-value:
-Gültige Werte: positive Ganzzahlen
-Default-Wert: 600
-
-
-
-
-
name: TrustManager.RevocationChecking
-
-Für die TLS-Server-Authentisierung dürfen nur Server-Zertifikate verwendet werden, die eine CRLDP-Extension enthalten (andernfalls kann von MOA-ID keine CRL-überprüfung durchgeführt werden).
- Soll das RevocationChecking generell ausgeschaltet werden, ist dieses Attribut anzugeben und auf "false" zu setzen.
-
-
-value:
-Gültige Werte: true, false
-Default-Wert: true
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Konfiguration der Online-Applikation
-
-Die Konfiguration der OA beschreibt die Art und Weise, wie die Proxykomponente die Anmeldung an der Online-Applikation
-durchführt.
-
-Der Name der Konfigurationsdatei wird in der Konfiguration von MOA-ID als Wert des Attributs
-configFileURL des Elements MOA-IDConfiguration/OnlineApplication/ProxyComponent hinterlegt.
- Ist dieses Attribut nicht gesetzt, dann wird die Datei von http://<realURLPrefix>/MOAConfig.xml geladen,
-wobei <realURLPrefix> dem Konfigurationswert OnlineApplication/ProxyComponent/ConnectionParameter/@URL entspricht.
-
-Die Konfigurationsdatei ist eine XML-Datei, die dem Schema
-MOA-ID-Configuration-1.1.xsd mit dem Wurzelelement
-Configuration entspricht.
-
-
-
-
-LoginType
-Das Element LoginType gibt an, ob die Online-Applikation ein einmaliges Login erwartet (stateful),
-oder ob die Login-Parameter bei jedem Request mitgegeben werden müssen (stateless). Im Fall einer stateful
-Online-Applikation werden die in der HTTP-Session der Proxykomponente gespeicherten Anmeldedaten nur für den Aufruf
-des Login-Scripts verwendet. Unmittelbar nach dem Aufruf werden sie gelöscht.
-
-Default-Wert: stateful
-
-
-
-
-
-ParamAuth
-Konfiguriert die übergabe der Authentisierungs-Parameter an die Online-Applikation mittels URL-Parametern. Das Element
-kann ein oder mehrere Kind-Elemente <Parameter> beinhalten.
-
-
-
-
-
-ParamAuth/Parameter
-Das Element <Paramter> enthält die Attribute Name und Value.
-
-Das Attribut Name beschreibt den Namen des Parameters und ist ein frei zu wählender String.
-
-Das Attribut Value beschreibt den Inhalt des Parameters und kann einen der durch MOAAuthDataType beschriebenen
-Werte annehmen. Gültige Werte von MOAAuthDataType sind:
-
-
MOAGivenName - der Vorname des Benutzers, wie in der Personenbindung enthalten
-
MOAFamilyName - der Nachname des Benutzers, wie in der Personenbindung enthalten
-
MOADateOfBirth - das Geburtsdatum des Benutzers, wie in der Personenbindung enthalten
-
MOAVPK - die verfahrensspezifische Personenkennzeichnung des Benutzers, wie von der
-Authentisierungskomponente berechnet
-
MOAPublicAuthority - wird durch true ersetzt, falls der Benutzer mit einem Zertifikat signierte,
-welches eine Behördenerweiterung beinhaltet. Andernfalls wird false gesetzt
-
MOABKZ - das Behördenkennzeichen (nur sinnvoll, wenn MOAPublicAuthority den Wert true
-ergibt)
-
MOAQualifiedCertificate - wird durch true ersetzt, falls das Zertifikat des Benutzers
-qualifiziert ist, andernfalls wird false gesetzt
-
MOAZMRZahl - die ZMR-Zahl des Benutzers; diese ist nur dann verfügbar, wenn die Online-Applikation
-die ZMR-Zahl bekommen darf (und daher in der Personenbindung enthalten ist)
-
MOAIPAddress - IP-Adresse des Client des Benutzers.
-
-
-Anhand der <Parameter>-Elemente wird der Request für den Login-Vorgang (für stateful Online-Applikationen)
-folgendermaßen zusammenge-stellt:
-
-Die <login-url> ergibt sich aus dem Parameter OA des Aufrufs von MOA-ID-AUTH,
-zusammen mit der Konfiguration von OnlineApplication/@publicURLPrefix und von OnlineApplication/ProxyComponent/ConnectionParameter/@URL.
- Der Wert resolvedValue wird in MOA-ID-PROXY je nach Wert des Platzhalters eingesetzt.
-
-
-
-
-BasicAuth
-Das Element BasicAuth konfiguriert die übergabe der Authentisierungs-Parameter an die Online-Appliktion
-mittels HTTP Basic Authentication. Es enthält zwei Kind-Elemente.
-
-Das Element UserID gibt die UserId des zu authentisierenden Benutzers an und kann einen der durch
-MOAAuthDataType beschriebenen Werte annehmen.
-
-Das Element Password gibt das Passwort des zu authentisierenden Benutzers an und kann einen der durch
-MOAAuthDataType beschriebenen Werte annehmen.
-
-
-
-
-
-HeaderAuth
-Das Element HeaderAuth konfiguriert die übergabe der Authentisierungs-Parameter an die Online-Applikation
-in HTTP Request Headern. Das Element kann ein oder mehrere Kind-Elemente <Header> beinhalten.
-
-
-
-
-
-HeaderAuth/Header
-Das Element <Header> enthält die Attribute Name und Value.
-
-Das Attribut Name beschreibt den Namen des Header und ist ein frei zu wählender String.
-
-Das Attribut Value beschreibt den Inhalt des Header und kann einen der durch MOAAuthDataType
-beschriebenen Werte annehmen.
-
-Die Header werden folgendermaßen in den Request an die Online-Applikation eingefügt:
-
-Der Wert resolvedValue wird in der Proxykomponente je nach Wert des Platzhalters eingesetzt.
-Etwaige Header aus dem ursprünglichen Request an die Proxykomponente, die denselben Namen haben, müssen
-überschrieben werden.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Konfiguration von MOA-SP
-
-
-
-MOA-ID überprüft die Signaturen der Personenbindung und des AUTH-Blocks mit dem VerifyXMLSignatureRequest
-von MOA-SP. Dazu muss MOA-SP wie unten beschreiben konfiguriert werden.
-
-Ein Auszug einer beispielhaften MOA-SP Konfigurationsdatei, die diese Konfigurationsparameter enthält ist in
-$MOA_ID_INST_AUTH/conf/moa-spss/ SampleMOASPSSConfiguration.xml enthalten.
-
-
-
-
-
-VerifyTransformsInfoProfile
-Der Request zum überprüfen der Signatur des AUTH-Blocks verwendet ein vordefiniertes VerifyTransformsInfoProfile.
-Die im Request verwendete Profil-ID wird in der MOA-ID Konfigurationsdatei
-im Element /MOA-IDConfiguration/ AuthComponent/MOA-SP/VerifyAuthBlock/ VerifyTransformsInfoProfileID definiert.
-Entsprechend muss am MOA-SP Server ein VerifyTransformsInfoProfile mit gleichlautender ID definiert werden. Die
-Profiledefinition selbst ist in der Auslieferung von MOA-ID in $MOA_ID_INST_AUTH/conf/moa-spss/profiles/MOAIDTransformAuthBlock.xml
-enthalten. Diese Profildefinition muss unverändert übernommen werden.
-
-
-
-
-
-TrustProfile
-Die Requests zur überprüfung der Signatur verwenden vordefinierte TrustProfile.
-Die im Request verwendete Profil-IDs werden in der MOA-ID Konfigurationsdatei
-in den Elementen /MOA-IDConfiguration/AuthComponent/MOA-SP/VerifyIdentityLink/ TrustProfileID und
-/MOA-IDConfiguration/AuthComponent/MOA-SP/VerifyAuthBlock/TrustProfileID definiert. Diese beiden Elemente
-können unterschiedliche oder identische TrustProfileIDs enthalten.
-Am MOA-SP Server müssen TrustProfile mit gleichlautender ID definiert werden.
-Die Auslieferung von MOA-ID enthält das Verzeichnis $MOA_ID_INST_AUTH/conf/moa-spss/trustprofiles/MOAIDBuergerkarteRoot,
-das als TrustProfile verwendet werden kann. Weitere Zertifikate können als vertrauenswürdig hinzugefügt werden.
-
-
-
-
-
-Certstore
-Zum Aufbau eines Zertifikatspfades können benötigte Zertifikate aus einem Zertifikatsspeicher verwendet werden.
-Die Auslieferung von MOA-ID enthält das Verzeichnis $MOA_ID_INST_AUTH/conf/moa-spss/certstore, das als initialer
-Zertifikatsspeicher verwendet werden kann.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Änderung der Konfiguration während des Betriebs
-
-Der Inhalt dieser Konfiguration, bzw. jene Teile, auf die indirekt verwiesen wird, können während des laufenden
-Betriebes des MOA-Servers geändert werden. Der Server selbst wird durch den Aufruf einer URL
-(im Applikationskontext von MOA ID) dazu veranlasst, die geänderte Konfiguration neu einzulesen.
-Im Falle einer fehlerhaften neuen Konfiguration wird die ursprüngliche Konfiguration beibehalten.
-
Konfiguration des Microsoft Internet Information Server (optional)
-
-Vor MOA-ID-AUTH oder MOA-ID-PROXY kann optional ein MS IIS vorgeschaltet sein. In diesem Fall übernimmt der MS IIS die HTTP bzw. HTTPS-Kommunikation mit dem Aufrufer des Webservices. Die Kommunikation zwischen MS IIS und dem in Tomcat deployten Webservice wird durch Jakarta mod_jk durchgeführt.
-Konfiguration von Jakarta mod_jk im MS IIS
-Für die Kommunikation des MS IIS mit dem im Tomcat deployten Webservice wird das ISAPI-Modul von Jakarta mod_jk im MS IIS installiert und konfiguriert. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk IIS HowTo. Beispiele für workers.properties und uriworkermap.properties Dateien liegen im ausgelieferten moa-id-auth-x.y.zip bzw. moa-id-proxy-x.y.zip, Verzeichnis tomcat bei.
-
-Konfiguration von Tomcat
-Damit Tomcat die Aufrufe, die von MS IIS mittels Jakarta mod_jk weiterleitet, entgegennehmen kann, muss in $CATALINA_HOME/conf/server.xml der AJP 1.3 Connector aktiviert werden. Im Gegenzug können die Connectoren für HTTP und HTTPS deaktiviert werden. Das geschieht am einfachsten durch ein- bzw. auskommentieren der entsprechenden Connector Konfigurations-Elemente in dieser Datei.
-
-
-
-Konfiguration von SSL
-Die Dokumentation zum Einrichten von SSL auf dem MS IIS steht nach Installation des IIS unter http://localhost/iisHelp/ bzw. online zur Verfügung.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Konfiguration des Apache Webservers (optional)
-
-Vor MOA-ID-AUTH oder MOA-ID-PROXY kann ein Apache Webserver vorgeschaltet sein. Das Prinzip funktioniert wie bei MS IIS, auch hier wird Jakarta mod_jk für die Kommunikation zwischen Webserver und Tomcat eingesetzt.
-
-Konfiguration von Jakarta mod_jk im Apache Webserver
- Um MOA-ID-AUTH oder MOA-ID-PROXY hinter einem Apache Webserver zu betreiben, ist die Konfiguration des Apache-Moduls mod_jk erforderlich. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk Apache HowTo. Ein Beispiel für eine workers.properties Datei liegt im Verzeichnis $MOA_SPSS_INST/conf/moa bei.
-Um MOA-ID-AUTH oder MOA-ID-PROXY dem Apache Webserver bekannt zu machen, muss folgender Eintrag in die Apache Konfigurationsdatei gemacht werden:
-
- JkMount /moa-id-auth/* moaworker
-
-oder für die Proxy-Komponente
-
- JkMount /* moaworker
-
-
-
-Konfiguration von Tomcat
-Die Konfiguration von Tomcat ist analog wie im Abschnitt über den MS IIS durchzuführen.
-
-
-Konfiguration von SSL mit mod_SSL
-Apache kann in Verbindung mit mod_SSL als SSL-Endpunkt für das MOA-ID-AUTH Webservice fungieren. In diesem Fall entfällt die SSL-Konfiguration in Tomcat, da Apache und Tomcat auch im Fall von SSL Daten via mod_jk austauschen. Eine detaillierte Installations- und Konfigurationsanleitung von mod_SSL gibt die Online-Dokumentation.
-
-Bei der Verwendung von Client-Authentisierung muss darauf geachtet werden, dass mod_ssl die HTTP-Header mit den Informationen über das Client-Zertifikat exportiert. Dies wird durch Angabe der Option
-
- SSLOptions +ExportCertData +StdEnvVars
-
-in der Apache-Konfiguration erreicht.
-Weiters muss Jakarta mod_jk angewiesen werden, die SSL Schlüssellänge zu exportieren. Dies geschieht mit der Direktive:
-
-MOA-ID-AUTH bzw. MOA-ID-PROXY kann PostgreSQL zum Abspeichern von Log-Meldungen verwenden. Hierfür wird eine installierte und konfigurierte Datenbank vorausgesetzt. Eine detaillierte Übersicht über die Installation und Konfiguration von PostgreSQL gibt die Online-Dokumentation.
-Logging
-Für das Logging in eine PostgreSQL Datenbank mittels Jakarta Log4j muss zunächst eine Tabelle für die Log-Meldungen angelegt werden. Dies kann mit folgendem SQL-Statement erreicht werden:
-
-Um das Logging in die Datenbank Log4j bekannt zu machen, muss die Log4j-Konfiguration adaptiert werden. Die Datei $MOA_SPSS_INST/conf/moa/log4.properties enthält bereits eine beispielhafte Jakarta Log4j-Konfiguration für das Logging in eine PostgreSQL Datenbank, die standardmäßig ausgeschaltet ist. Hinweis: Bei Tests hat sich das Logging in eine Datenbank mit Jakarta Log4j als Performance-Engpaß herausgestellt. Es wird deshalb empfohlen, auf dieses Feature zu verzichten.
-
MOA-ID-AUTH wird durch einen Verweis von einer Webseite aufgerufen.
-Diese Webseite kann z.B. Teil eines Portals sein.
-
Nach erfolgter Authentisierung holt die OA die bereitgestellten Anmeldedaten zum Bürger von MOA-ID-AUTH ab.
-Dies kann unter Mithilfe der Webapplikation MOA-ID-PROXY geschehen, die für diesen Zweck installiert und für die OA konfiguriert werden muss.
MOA-ID-AUTH wird immer durch eine andere (verweisende) Webseite aufgerufen. Diese Webseite kann z.B. Teil eines Portals sein.
-Der Aufruf erfolgt durch einen Verweis der Form:
Angabe, für welches Verfahren der Benutzer authentisiert werden soll (siehe TODO: Link auf Verzeichnis der Geschäftsbereich)
-
-
-
OA=<oa-url>
Webseite, auf die der Browser nach erfolgter Authentisierung weitergeleitet werden soll
-
-
-
Template=<template-url>
optional; HTML-Vorlage für der Anmeldeseite von MOA-ID-AUTH, über die der Bürger den Authentisierungsvorgang startet. Über diesen Parameter kann das Aussehen der Anmeldeseite an das Aussehen der Online-Applikation angepasst werden.
-
-
-
-
-
-Template
-Ein Template für die Anmeldeseite von MOA-ID-AUTH kann aus folgender Grundstruktur aufgebaut werden:
Innerhalb dieser <form>-Elemente können Texte, Beschriftungen und Styles modifiziert werden,
-und es können zusätzliche Elemente darin aufgenommen werden.
-
-Die vorgegebene Grundstruktur ist aber in jedem Fall einzuhalten, und es müssen die speziellen
-Tags <BKU> (kommt 2x vor), <XMLRequest>, <DataURL>, <CertInfoXMLRequest> und <CertInfoDataURL>
-darin enthalten sein.
-
-
-
-
-BKU-Auswahl
-MOA-ID-AUTH bietet die Möglichkeit, die Bürgerkartenumgebung (BKU) auszuwählen, über die in weiterer Folge die Bürgerkarte ausgelesen wird. Der Aufruf erfolgt dann durch einen Verweis der Form:
optional; HTML-Vorlage für der BKU-Auswahlseite von MOA-ID-AUTH.
-Über diesen Parameter kann das Aussehen der BKU-Auswahlseite an das Aussehen der Online-Applikation angepasst werden.
Innerhalb dieser <form>-Elemente können Texte, Beschriftungen und Styles modifiziert werden,
-und es können zusätzliche Elemente darin aufgenommen werden.
-
-Auch dabei ist die vorgegebene Grundstruktur einzuhalten, die speziellen Tags <StartAuth> und <BKUSelect> sind verpflichtend.
-
Nach erfolgter Authentisierung stehen in MOA-ID-AUTH Anmeldedaten zum Abholen bereit,
-und MOA-ID-AUTH veranlasst einen Redirect zur Online-Applikation (OA).
-
-In diesem Redirect werden der Geschäftsbereich und ein SAML-Artifact als Parameter übergeben.
-
URL, der beim Aufruf von MOA-ID-AUTH als Parameter "OA" übergeben wurde
-
Target=<geschäftsbereich>
Parameter, der beim Aufruf von MOA-ID-AUTH übergeben wurde
-
SAMLArtifact=<saml-artifact>
SAML-Artifact, das von MOA-ID-AUTH zu den Anmeldedaten erstellt wurde.
-Mithilfe dieses SAML-Artifacts kann die OA die Anmeldedaten von MOA-ID-AUTH abholen.
-
-
-
Grundsätzlich stehen einer OA mehrere Arten zum Abholen der Anmeldedaten von MOA-ID-AUTH zur Verfügung:
-
-
Die Applikation ruft selbst das MOA-ID-AUTH Web Service auf.
- Die Implementierung dieser Variante wird empfohlen, insbesondere für Online-Applikationen, die neu erstellt werden.
-
-
Es wird die MOA-ID-PROXY Webapplikation eingesetzt, um die Anmeldedaten abzuholen und an die OA zu übergeben.
- Aus Sicht von MOA-ID-PROXY ist bedeutsam, ob die OA die Anmeldedaten nach Abarbeitung des HTTP-Requests behält.
-
-
Stateful OA: MOA-ID-PROXY übergibt einmalig die Anmeldedaten an die OA, und die OA speichert die Anmeldedaten, typischerweise unter Einsatz von Cookies.
-
Stateless OA: MOA-ID-PROXY übergibt die Anmeldedaten bei jedem HTTP-Request vom Browser des Bürgers an die OA.
-
-Diese Variante ist vorzuziehen, wenn
-
-
für die Plattform, auf der die OA aufbaut, Web Service-Schnittstellen nicht verfügbar sind
-
das nötige Web Service-Know How nicht zur Verfügung steht
-
die Implementierung von Variante 1 zu aufwändig wäre
-
eine Anpassung der OA aus bestimmten Gründen nicht möglich ist
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Aufruf des MOA-ID-AUTH Web Service
-
Das MOA-ID-AUTH Web Service wird über einen <samlp:Request> aufgerufen.
-Der <samlp:Request> enthält in einem <samlp:AssertionArtifact> das von MOA-ID-AUTH übergebene SAML-Artifact.
-
-MOA-ID-AUTH liefert als Antwort einen <samlp:Response>. Die Anmeldedaten sind im <samlp:Response> in Form einer <saml:Assertion> enthalten.
-
-Das Abholen der Anmeldedaten durch Aufruf des Web Service von MOA-ID-AUTH wird anhand eines beispielhaften Java Servlet gezeigt.
-Das LoginServletExample wird in einer Stateful OA von MOA-ID-AUTH nach erfolgter Authentisierung über Redirect aufgerufen.
-
-Das Beispiel demonstriert insgesamt die Integration von MOA-ID-AUTH in die OA:
-
-
-
Parameterübergabe von MOA-ID-AUTH an die OA
-
Aufruf des MOA-ID-AUTH Web Service mittels des SOAP Frameworks "Apache AXIS"
-
Parsen der Anmeldedaten mittels der XPath Engine "Jaxen"
-
Speichern der Anmeldedaten in der HTTPSession
-
Redirect auf die eigentliche Startseite der OA
-
-
-
-Voraussetzungen
-
Die folgende Liste enthält die für das Beispiel erforderlichen Java-Bibliotheken. Die angeführten Versionsnummern bezeichnen jene Versionen dieser Java-Bibliotheken, mit denen das Beispiel getestet wurde.
Einsatz von MOA-ID-PROXY zum Abfragen der Anmeldedaten von MOA-ID-AUTH
-
-Anstatt den Aufruf des MOA-ID-AUTH Web Service in der OA zu implementieren, kann die MOA-ID-PROXY Webapplikation eingesetzt werden, um dies für die OA zu erledigen. MOA-ID-PROXY muss für die OA konfiguriert werden, so wie in MOA-ID-Administration beschrieben.
-
-Bei der Konfiguration ist speziell zu beachten:
-
-Konfigurationsdatei zur OA
-Der LoginType (stateful oder stateless) ist gemäß dem Applikationstyp zu setzen.
-
ParamAuth: Übergabe über Requestparameter (Beispiel)
-
HeaderAuth: Übergabe über Requestheader (Beispiel)
-
-
-
-LoginParameterResolver
-Das Übergabe der Anmeldedaten an die OA über Request Parameter oder Header geschieht in einer Standardimplementierung des Interface
-
-Falls die Erfordernisse der OA mittels Konfiguration nicht abgedeckt werden können,
-so kann eine maßgeschneiderte Implementierung von LoginParameterResolver erstellt und zusammen mit MOA-ID-PROXY zum Einsatz gebracht werden
-(siehe API).
-
-ConnectionBuilder
-Das Herstellen einer URL-Verbindung von MOA-ID-PROXY zur OA geschieht einer Standardimplementierung des Interface
-
at.gv.egovernment.moa.proxy.ConnectionBuilder
-Falls nötig, kann eine maßgeschneiderte Implementierung von ConnectionBuilder erstellt und zusammen mit MOA-ID-PROXY zum Einsatz gebracht werden
-(siehe API).
-
-Dieses Dokument enthält die Dokumentation für das Modul
-
-
MOA-ID (Identifikation)
-
-
-
-
-
-
-
-
-
-
-
-
-
-Das Modul Identifikation stellt Online-Applikationen Funktionalität zur Verfügung zu stellen, damit diese
-eine Benutzer-Identifikation und -Authentisierung mit Hilfe der Bürgerkarte und deren Signaturfunktion
-realisieren können.
-
-Das Modul besteht aus zwei Komponenten:
-
-
Die Authentisierungskomponente (MOA-ID-AUTH) führt die eigentliche Authentisierung des Benutzers durch und übergibt der
-Proxykomponente die Anmeldedaten.
-
Die Proxykomponente (MOA-ID-PROXY) übernimmt die Anmeldedaten von der Authentisierungskomponente,
-führt die Anmeldung an der Online Applikation durch und schleust in der Folge Daten an die Online-Applikation
-und Daten an den Benutzer durch.
-
-Diese beiden Komponenten können auf unterschiedlichen Rechnern
-oder auf dem gleichen Rechner eingesetzt werden.
-
-Die Funktionalität und der Aufbau der Schnittstelle zu MOA-ID ist in der
-Spezifikation Version 1.1 detailliert beschrieben.
-
-Für den Betrieb von MOA-ID ist der Einsatz von MOA-Signaturprüfung (MOA-SP) erforderlich.
-
-
-
-
Ablauf einer Anmeldung
-
-
-
-
-
-
-
-
1
-
Der Benutzer verbindet sich zu einem Web-Portal, über das die verfügbaren Online-Applikationen (OA) erreichbar
-sind. Jeder Link zu einer OA verweist auf die Authentisierungs-komponente.
-
-
-
-
-
2
-
Der Benutzer verbindet sich mit MOA-ID-AUTH, die die Authentisierung des
-Benutzers durchführt:
-
-
-
-
2.1
-
MOA-ID-AUTH bietet dem Benutzer optional eine Auswahl von verfügbaren Bürgerkartenumgebungen (engl. Bezeichnung: Security-Layer) an.
-
-
-
-
2.2
-
MOA-ID-AUTH erzeugt eine HTML-Seite mit einem <InfoboxReadRequest>
- zum Auslesen der Personenbindung. Diese HTML-Seite wird an den Browser geschickt.
-
-
-
-
2.3
-
Der Browser schickt den <InfoboxReadRequest> an den ausgewählten Security-Layer. Der Security-Layer liest die
-Personenbindung von der Bürgerkarte und sendet diese an MOA-ID-AUTH, die die Signatur der Personenbindung durch
-einen Aufruf von MOA-SP überprüft.
-
-
-
-
-
2.4
-
MOA-ID-AUTH erstellt den AUTH-Block. Der AUTH-Block enthält
-
-
Vor- und Nachname aus der Personenbindung,
-
URL von MOA-ID-AUTH,
-
URL und Geschäftsbereich der Online-Applikation,
-
die aktuelle Zeit.
-
-Anschließend wird
-eine XML Antwortseite, die das Kommando zum Signieren (<CreateXMLSignatureRequest>) des generierten
-AUTH-Blocks enthält, an den ausgewählten Security-Layer gesendet.
-
-
-
-
2.5
-
Der Request wird vom Security-Layer verarbeitet. Die signierten Daten werden an
-MOA-ID-AUTH zurückgesendet.
-
-
-
-
2.6
-
MOA-ID-AUTH überprüft den signierten AUTH-Block und legt für den Benutzer die Anmeldedaten
-an. Die Anmeldedaten enthalten
-
-
die verfahrensspezifische Personenkennzeichnung (VPK),
-
den signierten AUTH-Block (optional),
-
die Personenbindung (optional),
-
die PersonData-Struktur aus der Personenbindung (optional),
-
die Information, ob die Signatur des AUTH-Blocks mit einem qualifiziertem Zertifikat erfolgte,
-
Informationen zur Behörde, falls die Signatur mit einem Behördenzertifikat erzeugt wurde.
-
-
-
-
-
-
2.7
-
Ist der obige Authentisierungsvorgang erfolgreich, dann wird eine Redirect-Seite
-zum Browser gesendet.
-
-
-
-
3
-
Der Browser führt das Redirect zur Proxykomponente durch. Als Parameter wird das von MOA-ID-AUTH
-erzeugte SAML-Artifact übergeben.
-
-
-
-
4
-
Die Proxykomponente verwendet dieses eindeutige SAML-Artifact, um die Anmeldedaten
-von MOA-ID-AUTH zu erhal-ten. Danach werden die Anmeldedaten in MOA-ID-AUTH gelöscht.
-
-
-
-
5
-
MOA-ID-PROXY liest die Konfigurationsdatei der zugehörigen Online-Applikation, die beschreibt, wie die Anmeldedaten
-an die nachfolgende Applikation übergeben werden müssen, und meldet den Benutzer bei der Applikation an.
-
-
-
-
6
-
Ist die betreffende OA als stateless konfiguriert, so werden in weiterer Folge die Antworten der OA
-an den Benutzer weitergeleitet und die Anfragen des Benutzers an die OA weitergeleitet.
- Zurück
- Übersicht
- Basis-Installation
-
-
-