From dd45e938564249a5e6897bd92dd29808d8990868 Mon Sep 17 00:00:00 2001 From: rudolf Date: Fri, 24 Oct 2003 08:34:56 +0000 Subject: MOA-ID version 1.1 (initial) git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@19 d688527b-c9ab-4aba-bd8d-4036d912da1d --- .../doc/moa_id/examples/BKUSelectionTemplate.html | 4 + id.server/doc/moa_id/examples/ChainingModes.txt | 6 + .../doc/moa_id/examples/IdentityLinkSigners.txt | 3 + .../doc/moa_id/examples/LoginServletExample.txt | 171 ++++++ id.server/doc/moa_id/examples/Template.html | 23 + .../moa_id/examples/TransformsInfoAuthBlock.txt | 63 +++ .../moa_id/examples/conf/MOA-ID-Configuration.xml | 54 ++ .../doc/moa_id/examples/conf/OAConfBasicAuth.xml | 12 + .../doc/moa_id/examples/conf/OAConfHeaderAuth.xml | 17 + .../doc/moa_id/examples/conf/OAConfParamAuth.xml | 14 + id.server/doc/moa_id/examples/moa-id-env-linux.txt | 1 + .../doc/moa_id/examples/moa-id-env-windows.txt | 1 + id.server/doc/moa_id/faqs.htm | 109 ++++ id.server/doc/moa_id/id-admin.htm | 283 ++++++++++ id.server/doc/moa_id/id-admin_1.htm | 400 +++++++++++++ id.server/doc/moa_id/id-admin_2.htm | 623 +++++++++++++++++++++ id.server/doc/moa_id/id-admin_3.htm | 187 +++++++ id.server/doc/moa_id/id-anwendung.htm | 104 ++++ id.server/doc/moa_id/id-anwendung_1.htm | 182 ++++++ id.server/doc/moa_id/id-anwendung_2.htm | 249 ++++++++ id.server/doc/moa_id/links.htm | 141 +++++ id.server/doc/moa_id/moa-id-ablauf.jpg | Bin 0 -> 15550 bytes id.server/doc/moa_id/moa.htm | 247 ++++++++ 23 files changed, 2894 insertions(+) create mode 100644 id.server/doc/moa_id/examples/BKUSelectionTemplate.html create mode 100644 id.server/doc/moa_id/examples/ChainingModes.txt create mode 100644 id.server/doc/moa_id/examples/IdentityLinkSigners.txt create mode 100644 id.server/doc/moa_id/examples/LoginServletExample.txt create mode 100644 id.server/doc/moa_id/examples/Template.html create mode 100644 id.server/doc/moa_id/examples/TransformsInfoAuthBlock.txt create mode 100644 id.server/doc/moa_id/examples/conf/MOA-ID-Configuration.xml create mode 100644 id.server/doc/moa_id/examples/conf/OAConfBasicAuth.xml create mode 100644 id.server/doc/moa_id/examples/conf/OAConfHeaderAuth.xml create mode 100644 id.server/doc/moa_id/examples/conf/OAConfParamAuth.xml create mode 100644 id.server/doc/moa_id/examples/moa-id-env-linux.txt create mode 100644 id.server/doc/moa_id/examples/moa-id-env-windows.txt create mode 100644 id.server/doc/moa_id/faqs.htm create mode 100644 id.server/doc/moa_id/id-admin.htm create mode 100644 id.server/doc/moa_id/id-admin_1.htm create mode 100644 id.server/doc/moa_id/id-admin_2.htm create mode 100644 id.server/doc/moa_id/id-admin_3.htm create mode 100644 id.server/doc/moa_id/id-anwendung.htm create mode 100644 id.server/doc/moa_id/id-anwendung_1.htm create mode 100644 id.server/doc/moa_id/id-anwendung_2.htm create mode 100644 id.server/doc/moa_id/links.htm create mode 100644 id.server/doc/moa_id/moa-id-ablauf.jpg create mode 100644 id.server/doc/moa_id/moa.htm (limited to 'id.server/doc/moa_id') diff --git a/id.server/doc/moa_id/examples/BKUSelectionTemplate.html b/id.server/doc/moa_id/examples/BKUSelectionTemplate.html new file mode 100644 index 000000000..11c9352d2 --- /dev/null +++ b/id.server/doc/moa_id/examples/BKUSelectionTemplate.html @@ -0,0 +1,4 @@ +
+ + + diff --git a/id.server/doc/moa_id/examples/ChainingModes.txt b/id.server/doc/moa_id/examples/ChainingModes.txt new file mode 100644 index 000000000..820b60d06 --- /dev/null +++ b/id.server/doc/moa_id/examples/ChainingModes.txt @@ -0,0 +1,6 @@ + + + CN=A-Trust-nQual-0,OU=A-Trust-nQual-0,O=A-Trust,C=AT + 536 + + diff --git a/id.server/doc/moa_id/examples/IdentityLinkSigners.txt b/id.server/doc/moa_id/examples/IdentityLinkSigners.txt new file mode 100644 index 000000000..faed15030 --- /dev/null +++ b/id.server/doc/moa_id/examples/IdentityLinkSigners.txt @@ -0,0 +1,3 @@ + + CN=zmr,OU=BMI-IV-2,O=BMI,C=AT + diff --git a/id.server/doc/moa_id/examples/LoginServletExample.txt b/id.server/doc/moa_id/examples/LoginServletExample.txt new file mode 100644 index 000000000..e085e4126 --- /dev/null +++ b/id.server/doc/moa_id/examples/LoginServletExample.txt @@ -0,0 +1,171 @@ +import java.io.IOException; +import java.util.Vector; + +import javax.servlet.ServletException; +import javax.servlet.http.HttpServlet; +import javax.servlet.http.HttpServletRequest; +import javax.servlet.http.HttpServletResponse; +import javax.servlet.http.HttpSession; +import javax.xml.namespace.QName; +import javax.xml.parsers.DocumentBuilder; +import javax.xml.parsers.DocumentBuilderFactory; +import javax.xml.rpc.Call; +import javax.xml.rpc.Service; +import javax.xml.rpc.ServiceFactory; + +import org.apache.axis.message.SOAPBodyElement; +import org.apache.xml.serialize.LineSeparator; +import org.apache.xml.serialize.OutputFormat; +import org.apache.xml.serialize.XMLSerializer; +import org.jaxen.JaxenException; +import org.jaxen.SimpleNamespaceContext; +import org.jaxen.dom.DOMXPath; +import org.w3c.dom.Attr; +import org.w3c.dom.Document; +import org.w3c.dom.Element; +import org.w3c.dom.Node; +import org.w3c.dom.NodeList; + +/** + * Beispiel für ein Login-Servlet, das von MOA-ID-AUTH über einen Redirect aufgerufen wird. + * Es werden demonstriert: + * - Parameterübergabe von MOA-ID-AUTH + * - Aufruf des MOA-ID-AUTH Web Service zum Abholen der Anmeldedaten über das Apache Axis Framework + * - Parsen der Anmeldedaten mittels der XPath Engine "Jaxen" + * - Speichern der Anmeldedaten in der HTTPSession + * - Redirect auf die eigentliche Startseite der OA + * + * @author Paul Ivancsics + */ +public class LoginServletExample extends HttpServlet { + + // Web Service QName und Endpoint + private static final QName SERVICE_QNAME = new QName("GetAuthenticationData"); + private static final String ENDPOINT = + "http://localhost:8080/moa-id-auth/services/GetAuthenticationData"; + // NamespaceContext für Jaxen + private static SimpleNamespaceContext NS_CONTEXT; + static { + NS_CONTEXT = new SimpleNamespaceContext(); + NS_CONTEXT.addNamespace("saml", "urn:oasis:names:tc:SAML:1.0:assertion"); + NS_CONTEXT.addNamespace("samlp", "urn:oasis:names:tc:SAML:1.0:protocol"); + NS_CONTEXT.addNamespace("pr", "http://reference.e-government.gv.at/namespace/persondata/20020228#"); + } + + /** + * Servlet wird von MOA-ID-AUTH nach erfolgter Authentisierung über ein Redirect aufgerufen. + */ + protected void doGet(HttpServletRequest req, HttpServletResponse resp) + throws ServletException, IOException { + + // Parameter "Target" und "SAMLArtifact" aus dem Redirect von MOA-ID-AUTH lesen + String target = req.getParameter("Target"); + String samlArtifact = req.getParameter("SAMLArtifact"); + + try { + // DOMBuilder instanzieren + DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); + factory.setNamespaceAware(true); + DocumentBuilder builder = factory.newDocumentBuilder(); + + // zusammenstellen und in einen DOM-Baum umwandeln + String samlRequest = + "" + + samlArtifact + + ""; + Document root_request = builder.parse(samlRequest); + + // Neues SOAPBodyElement anlegen und mit dem DOM-Baum füllen + SOAPBodyElement body = new SOAPBodyElement(root_request.getDocumentElement()); + SOAPBodyElement[] params = new SOAPBodyElement[] { body }; + + // AXIS-Service für Aufruf von MOA-ID-AUTH instanzieren + Service service = ServiceFactory.newInstance().createService(SERVICE_QNAME); + + // Axis-Call erzeugen und mit Endpoint verknüpfen + Call call = service.createCall(); + call.setTargetEndpointAddress(ENDPOINT); + + // Call aufrufen und die Antwort speichern + System.out.println("Calling MOA-ID-AUTH ..."); + Vector responses = (Vector) call.invoke(params); + + // erstes BodyElement auslesen + SOAPBodyElement response = (SOAPBodyElement) responses.get(0); + + // als DOM-Baum holen + Document responseDocument = response.getAsDocument(); + Element samlResponse = responseDocument.getDocumentElement(); + + // auf System.out ausgeben + System.out.println("Response received:"); + OutputFormat format = new OutputFormat((Document) responseDocument); + format.setLineSeparator(LineSeparator.Windows); + format.setIndenting(true); + format.setLineWidth(0); + XMLSerializer serializer = new XMLSerializer(System.out, format); + serializer.asDOMSerializer(); + serializer.serialize(responseDocument); + + // auslesen + Attr statusCodeAttr = (Attr)getNode(samlResponse, "/samlp:Response/samlp:Status/samlp:StatusCode/@Value"); + String samlStatusCode = statusCodeAttr.getValue(); + System.out.println("StatusCode: " + samlStatusCode); + + // auslesen + if ("samlp:Success".equals(samlStatusCode)) { + Element samlAssertion = (Element)getNode(samlResponse, "/samlp:Response/saml:Assertion"); + + // FamilyName aus der parsen + Node familyNameNode = getNode(samlAssertion, "//saml:AttributeStatement/saml:Attribute[@AttributeName=\"PersonData\"]/saml:AttributeValue/pr:Person/pr:Name/pr:FamilyName"); + String familyName = getText(familyNameNode); + System.out.println("Family name: " + familyName); + + // weitere Anmeldedaten aus der parsen + // ... + + // Anmeldedaten und Target in der HTTPSession speichern + HttpSession session = req.getSession(); + session.setAttribute("UserFamilyName", familyName); + session.setAttribute("Geschaeftsbereich", target); + + // weitere Anmeldedaten in der HTTPSession speichern + // ... + + // Redirect auf die eigentliche Startseite + resp.sendRedirect("/index.jsp"); + } + } + catch (Exception ex) { + ex.printStackTrace(); + } + } + /** Returns the first node matching an XPath expression. */ + private static Node getNode(Node contextNode, String xpathExpression) throws JaxenException { + DOMXPath xpath = new DOMXPath(xpathExpression); + xpath.setNamespaceContext(NS_CONTEXT); + return (Node) xpath.selectSingleNode(contextNode); + } + /** Returns the text that a node contains. */ + public static String getText(Node node) { + if (!node.hasChildNodes()) { + return ""; + } + + StringBuffer result = new StringBuffer(); + NodeList list = node.getChildNodes(); + for (int i = 0; i < list.getLength(); i++) { + Node subnode = list.item(i); + if (subnode.getNodeType() == Node.TEXT_NODE) { + result.append(subnode.getNodeValue()); + } else if (subnode.getNodeType() == Node.CDATA_SECTION_NODE) { + result.append(subnode.getNodeValue()); + } else if (subnode.getNodeType() == Node.ENTITY_REFERENCE_NODE) { + // Recurse into the subtree for text + // (and ignore comments) + result.append(getText(subnode)); + } + } + return result.toString(); + } +} diff --git a/id.server/doc/moa_id/examples/Template.html b/id.server/doc/moa_id/examples/Template.html new file mode 100644 index 000000000..97e54c6af --- /dev/null +++ b/id.server/doc/moa_id/examples/Template.html @@ -0,0 +1,23 @@ +
+ + + +
+
+ + + Hier finden Sie weitere Informationen zur Überprüfung der Zertifikate.
+ +
\ No newline at end of file diff --git a/id.server/doc/moa_id/examples/TransformsInfoAuthBlock.txt b/id.server/doc/moa_id/examples/TransformsInfoAuthBlock.txt new file mode 100644 index 000000000..396d0faea --- /dev/null +++ b/id.server/doc/moa_id/examples/TransformsInfoAuthBlock.txt @@ -0,0 +1,63 @@ + + + + + + + + +Bitte bestätigen Sie mit Ihrer Unterschrift folgende Angaben: +
+ + + + + + + + + + + + + + + + + + + + + +
+ Name: + + +
+ Zeit: + + .., :: +
+ Applikation: + + +
+ Geschäftsbereich: + + +
+ Anmeldeserver: + + +
+ + + + + + + + + text/html + + diff --git a/id.server/doc/moa_id/examples/conf/MOA-ID-Configuration.xml b/id.server/doc/moa_id/examples/conf/MOA-ID-Configuration.xml new file mode 100644 index 000000000..6ce00228c --- /dev/null +++ b/id.server/doc/moa_id/examples/conf/MOA-ID-Configuration.xml @@ -0,0 +1,54 @@ + + + + + + + + + + + + + file:/home/moa/id/jakarta-tomcat-4.1.18/conf/moa-id/certs/server-certs + file:/c:/ + + + TrustProfile1 + + + TrustProfile1 + TransformsInfoProfile1MOAID + + + + CN=Test Signaturdienst Personenbindung,OU=Zentrales Melderegister,O=Bundesministerium f\C3\BCr Inneres,C=AT + + + + + + http://www.altova.com + http://www.altova.com + + + + + + + + file:/home/moa/id/jakarta-tomcat-4.1.18/conf/moa-id/oa/server-certs/tomcat + URL:toClientKeystoreOA + + + + + + CN=A-Trust-nQual-0,OU=A-Trust-nQual-0,O=A-Trust,C=AT + 536 + + + + + + diff --git a/id.server/doc/moa_id/examples/conf/OAConfBasicAuth.xml b/id.server/doc/moa_id/examples/conf/OAConfBasicAuth.xml new file mode 100644 index 000000000..0e4508036 --- /dev/null +++ b/id.server/doc/moa_id/examples/conf/OAConfBasicAuth.xml @@ -0,0 +1,12 @@ + + + stateful + + MOAFamilyName + MOADateOfBirth + + + + \ No newline at end of file diff --git a/id.server/doc/moa_id/examples/conf/OAConfHeaderAuth.xml b/id.server/doc/moa_id/examples/conf/OAConfHeaderAuth.xml new file mode 100644 index 000000000..c1a1964bf --- /dev/null +++ b/id.server/doc/moa_id/examples/conf/OAConfHeaderAuth.xml @@ -0,0 +1,17 @@ + + + stateful + + + + + + + + + \ No newline at end of file diff --git a/id.server/doc/moa_id/examples/conf/OAConfParamAuth.xml b/id.server/doc/moa_id/examples/conf/OAConfParamAuth.xml new file mode 100644 index 000000000..18e0a109c --- /dev/null +++ b/id.server/doc/moa_id/examples/conf/OAConfParamAuth.xml @@ -0,0 +1,14 @@ + + + stateful + + + + + + + + + \ No newline at end of file diff --git a/id.server/doc/moa_id/examples/moa-id-env-linux.txt b/id.server/doc/moa_id/examples/moa-id-env-linux.txt new file mode 100644 index 000000000..995d0b4d4 --- /dev/null +++ b/id.server/doc/moa_id/examples/moa-id-env-linux.txt @@ -0,0 +1 @@ +export CATALINA_OPTS="-Dmoa.id.configuration=/home/moa/jakarta-tomcat-4.1.18/conf/moa-id/MOAIDConfiguration.xml -Dlog4j.configuration=file:/home/moa/jakarta-tomcat-4.1.18/conf/moa-id/log4j.properties" diff --git a/id.server/doc/moa_id/examples/moa-id-env-windows.txt b/id.server/doc/moa_id/examples/moa-id-env-windows.txt new file mode 100644 index 000000000..109c196cf --- /dev/null +++ b/id.server/doc/moa_id/examples/moa-id-env-windows.txt @@ -0,0 +1 @@ +set CATALINA_OPTS=-Dmoa.id.configuration=c:\jakarta-tomcat-4.1.18\conf\moa-id\MOAIDConfiguration.xml -Dlog4j.configuration=file:c:\jakarta-tomcat-4.1.18\conf\moa-id\log4j.properties diff --git a/id.server/doc/moa_id/faqs.htm b/id.server/doc/moa_id/faqs.htm new file mode 100644 index 000000000..ed386e11e --- /dev/null +++ b/id.server/doc/moa_id/faqs.htm @@ -0,0 +1,109 @@ + + + FAQs - Häufig gestellte Fragen + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
FAQs

+ +
+ +		 +
FAQs - Häufig gestellte Fragen
+ +

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

+
+
+ + + + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file diff --git a/id.server/doc/moa_id/id-admin.htm b/id.server/doc/moa_id/id-admin.htm new file mode 100644 index 000000000..718f0cd03 --- /dev/null +++ b/id.server/doc/moa_id/id-admin.htm @@ -0,0 +1,283 @@ + + + MOA ID-Administration + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
MOA-ID

+
+ Übersicht
+ + + +
+ +
+		 +
MOA ID-Administration v.1.1
+

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

+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +
KomponenteVersion
JDK 1.3.1_07  
JDK 1.4.1 
Tomcat 4.1.18 
MOA-ID-AUTH 1.0 
MOA-ID-PROXY 1.0 
MOA-SPSS 1.0 
Apache Webserver 1.3.23  
Microsoft Internet Information Server 5.0  
mod_SSL (*) 
Jakarta mod_jk 1.2.2 
Jakarta Log4j 1.2.7 
PostgreSQL 7.3 
+
+

+ +
+(*) passend zur Version des Apache Webservers +
+
+

+ + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file diff --git a/id.server/doc/moa_id/id-admin_1.htm b/id.server/doc/moa_id/id-admin_1.htm new file mode 100644 index 000000000..f56338747 --- /dev/null +++ b/id.server/doc/moa_id/id-admin_1.htm @@ -0,0 +1,400 @@ + + + MOA ID-Administration + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
MOA-ID

+ +
+ Basis-Installation
+ + +
+ +

+ +		 +

Basis-Installation v.1.1

+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: +
+	set CLASSPATH=%JAVA_HOME%\lib\tools.jar;
+		      $MOA_ID_EXT\iaik_jce_full.jar;
+		      $MOA_ID_EXT\iaik_ldap.jar;
+		      $MOA_ID_EXT\jcert.jar;
+		      $MOA_ID_EXT\jnet.jar;
+		      $MOA_ID_EXT\jsse.jar 
+
+($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: +
+<role rolename="moa-admin"/>
+<user username="moa" password="moa" roles="moa-admin"/>
+
+
+
+ +
+ + +
+

 

+
+

+
+		 +

Deployment von MOA-ID-AUTH in Tomcat

+
+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>:
    • +
    <Context path="" docBase="../moa-id-proxy.war" debug="0"/>
    +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
+
+    bin\catalina start (unter Windows) oder 
+    bin/catalina.sh start (unter Unix/Linux) 
+
+gestartet werden. Das Stoppen von Tomcat erfolgt analog mit
+
+    bin\catalina stop  (unter Windows) oder 
+    bin/catalina.sh stop (unter Unix/Linux) 
+
+Ein erfolgreicher Startvorgang von MOA-ID-AUTH ist an folgender Log-Meldung ersichtlich:
+
+    INFO | 08 13:33:38,497 | main | 
+    	MOA ID Authentisierung wurde 
+    	erfolgreich gestartet
+
+Analog bei MOA-ID-PROXY:
+
+    INFO | 08 13:35:49,876 | main | 
+    	MOA ID Proxy wurde erfolgreich gestartet
+
+ +Nach dem erfolgreichen Starten von Tomcat steht MOA-ID-AUTH unter der URL +
+http(s)://host:port/moa-id-auth/StartAuthentication    
+
+zur Verfügung. Der WebService ist unter +
+http(s)://host:port/moa-id-auth/services/GetAuthenticationData  
+
+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: +
+
+    INFO | 09 08:37:17,663 | Thread-9 | 
+      MOASession 6576509775379152205 angelegt  
+     	
+    INFO | 09 08:37:20,828 | Thread-9 | 
+      Anmeldedaten zu MOASession 6576509775379152205 
+      angelegt, SAML Artifakt 
+      AAF/BrdRfnMaQVGIbP/Gf9OwDUwwsXChb7nuT+VXQzOoHbV
+    
+
+ +
+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:
+
+    ERROR | 09 09:34:27,105 | Thread-8 | 
+	at.gv.egovernment.moa.id.AuthenticationException: 
+	MOASessionID ist unbekannt 
+	(MOASessionID=-8650403497547200032)
+
+
+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. +
+
+

+ + + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file diff --git a/id.server/doc/moa_id/id-admin_2.htm b/id.server/doc/moa_id/id-admin_2.htm new file mode 100644 index 000000000..b4e22a36b --- /dev/null +++ b/id.server/doc/moa_id/id-admin_2.htm @@ -0,0 +1,623 @@ + + + MOA ID-Administration + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
MOA-ID

+ + +
+ Konfiguration
+ +
+ +

+ + +		 +
Konfiguration von MOA ID v.1.1
+ +
+

Konfiguration von MOA ID v.1.1

+

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

+Beispiel für eine TransformsInfo-Datei +

+ +
+

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

+Beispiel +

+

+ +
+

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

+Beispiel +

+ +
+

+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:
+
+GET https://<login-url>?
+  <p1.name=p1.resolvedValue>&
+  <p2.name=p2.resolvedValue>... +
+

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

+
+ + +
+ + +
+ + + +
+

 

+
+

+
+		 +

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

+ + + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file diff --git a/id.server/doc/moa_id/id-admin_3.htm b/id.server/doc/moa_id/id-admin_3.htm new file mode 100644 index 000000000..92d13aa6a --- /dev/null +++ b/id.server/doc/moa_id/id-admin_3.htm @@ -0,0 +1,187 @@ + + + MOA ID-Administration + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
+
MOA-ID

+ + + +
+ Optionale
    Komponenten
+
+ +
+
+Optionale
Komponenten
+IIS
+Apache
+PostgreSQL
+
+		 +

Konfiguration der optionalen Komponenten

+

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: +
+    JkOptions +ForwardKeySize 
+              +ForwardURICompat 
+              -ForwardDirectories
+
+
+
+

+ + +
+ + + +
+

 

+		 +

Konfiguration von PostgreSQL

+
+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: +
+    create table spss_log 
+      (log_time timestamp, 
+       log_level varchar(5), 
+       log_msg varchar(256));
+
+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. +

+
+ +
+

+ + + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file diff --git a/id.server/doc/moa_id/id-anwendung.htm b/id.server/doc/moa_id/id-anwendung.htm new file mode 100644 index 000000000..6e33f40e8 --- /dev/null +++ b/id.server/doc/moa_id/id-anwendung.htm @@ -0,0 +1,104 @@ + + + MOA ID-Anwendung + + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
MOA-ID

+
+ Übersicht
+ + +
+ +
+		 +
MOA ID-Anwendung
+

+MOA-ID führt für eine Online-Applikation (OA) die Benutzeridentifizierung und -authentisierung mit Hilfe der Bürgerkarte durch. +

+

Übersicht

+Um diese Funktionalität verfügbar zu machen, ist folgendermaßen vorzugehen:
+

+
    +
  • Die OA muss als Webapplikation installiert werden.
    • +
  • MOA-ID-AUTH muss als Webapplikation installiert und für die OA konfiguriert werden.
    • +
  • 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.
    • +
+
+
+ + + + + + +

 +
+
© 2003
+
+
+ + +
+ + diff --git a/id.server/doc/moa_id/id-anwendung_1.htm b/id.server/doc/moa_id/id-anwendung_1.htm new file mode 100644 index 000000000..81c4ecc9e --- /dev/null +++ b/id.server/doc/moa_id/id-anwendung_1.htm @@ -0,0 +1,182 @@ + + + MOA ID-Anwendung + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + + +
+
MOA-ID

+ + + +
+ +

+		 +

Aufruf von MOA-ID-AUTH

+
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:
+
<a href="https://<moa-id-server-und-pfad>/
+StartAuthentication?Target=<geschäftsbereich>
+&OA=<oa-url>&Template=<template-url>">
+ + + + + + + + + + + + + + +
<moa-id-server-und-pfad>Server und Pfad, wo MOA-ID-AUTH installiert ist
Target=<geschäftsbereich>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:
+
+<form name="CustomizedForm" action="<BKU>" method="post">
+ <input type="hidden"
+        name="XMLRequest"
+        value="<XMLRequest>"/>
+ <input type="hidden"
+        name="DataURL"
+        value="<DataURL>"/>
+ <input type="submit" value="Bürgerkarte lesen"/>
+</form>
+<form name="CustomizedInfoForm"
+ action="<BKU>"
+ method="post">
+ <input type="hidden"
+        name="XMLRequest"
+        value="<CertInfoXMLRequest>"/>
+ <input type="hidden"
+        name="DataURL"
+        value="<CertInfoDataURL>"/>
+Hier finden Sie weitere Informationen 
+zur Überprüfung der Zertifikate.<br/>
+ <input type="submit" value="Weitere Info"/>
+</form>
+
+ +
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:
+
<a href="https://<moa-id-server-und-pfad>/
+SelectBKU?Target=<geschäftsbereich>
+&OA=<oa-url>&Template=<template-url>
+&BKUSelectionTemplate=<bku-template-url>">
+ + + + + +
BKUSelectionTemplate= <bku-template-url>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.
+

+ +
+BKUSelectionTemplate

+Ein Template für die BKU-Auswahl von MOA-ID-AUTH kann aus folgender Grundstruktur aufgebaut werden:
+
+<form name="CustomizedForm" method="post" action="<StartAuth>">
+ <BKUSelect>
+ <input type="submit" value="Auswählen"/>
+</form>
+
+
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. +
+

+ + +
+ + + + + + +

 +
+
© 2003
+
+
+ + +
+ + diff --git a/id.server/doc/moa_id/id-anwendung_2.htm b/id.server/doc/moa_id/id-anwendung_2.htm new file mode 100644 index 000000000..1ffeb4c08 --- /dev/null +++ b/id.server/doc/moa_id/id-anwendung_2.htm @@ -0,0 +1,249 @@ + + + MOA ID-Anwendung + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + + +
+
MOA-ID

+ + + +
+ +

+
+Abfragearten: +
+Web Service
+MOA-ID-PROXY
+
+		 +

Abfrage der Anmeldedaten von MOA-ID-AUTH

+
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. +
+
<a href="https://<oa-url>
+?Target=<geschäftsbereich>
+&SAMLArtifact=<saml-artifact>">
+ + + + + +
<oa-url>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:
+
    +
  1. 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. +
    2. +
  2. 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
      • +
    +
    3. +
+
+ + + +
+ + + +
+

 

+
+

+
+		 +

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

+SAML 1.0 Protocol Schema +
+SAML 1.0 Assertion Schema +
+Der detaillierte Aufbau der <saml:Assertion> zu den Anmeldedaten ist in der Spezifikation MOA-ID 1.1 beschrieben. +

+

Beispiel LoginServletExample

+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.
+
+ + + + + + + + + + + + + + + + + + + + + + +
Java-BibliothekVersionBemerkung
JDK1.3 bzw. 1.4.1Java Development Kit
Xerces
XML Parser		2.0.2+nicht nötig wenn JDK 1.4 oder höher verwendet wird
+ Download: xml.apache.org/xerces2-j
AXIS
SOAP Framework		1.0+Download: xml.apache.org/axis
Jaxen XPath Engine1.0+Download: http://jaxen.sourceforge.net
JSSE1.0.3+wenn eine SSL Verbindung verwendet wird, nicht nötig ab JDK 1.4
Download: java.sun.com/products/jsse
Servlet API2.3+Download: java.sun.com/products/servlet
+
+Code
+LoginServletExample + +
+ +
+ + + +
+ + +
+

 

+
+

+
+		 +

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

+Die Übergabe der Anmeldedaten ist in Form und Inhalt zu konfigurieren. +
+
    +
  • BasicAuth: HTTP Basic Authentication (Beispiel)
    • +
  • 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 +
at.gv.egovernment.moa.proxy.LoginParameterResolver
+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). +
+
+ + + + + +

 +
+
© 2003
+
+
+ + +
+ + diff --git a/id.server/doc/moa_id/links.htm b/id.server/doc/moa_id/links.htm new file mode 100644 index 000000000..c5a9b7113 --- /dev/null +++ b/id.server/doc/moa_id/links.htm @@ -0,0 +1,141 @@ + + + MOA Grundlagen + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
MOA Links

+ + + + +
+ +
+ +		 +
MOA Links
+ +
+ + + + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file diff --git a/id.server/doc/moa_id/moa-id-ablauf.jpg b/id.server/doc/moa_id/moa-id-ablauf.jpg new file mode 100644 index 000000000..0585664f4 Binary files /dev/null and b/id.server/doc/moa_id/moa-id-ablauf.jpg differ diff --git a/id.server/doc/moa_id/moa.htm b/id.server/doc/moa_id/moa.htm new file mode 100644 index 000000000..4ffab01d5 --- /dev/null +++ b/id.server/doc/moa_id/moa.htm @@ -0,0 +1,247 @@ + + + MOA Module fuer Online Applikationen + + + + + + + + + +
+ + + + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + + + +
+
MOA-ID

+
+ Allgemein
+ + + + + +
+ +
+
+
+		 + +
Allgemein v.1.1
+

+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
+
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
1Der 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. +
2Der Benutzer verbindet sich mit MOA-ID-AUTH, die die Authentisierung des +Benutzers durchführt:
2.1MOA-ID-AUTH bietet dem Benutzer optional eine Auswahl von verfügbaren Bürgerkartenumgebungen (engl. Bezeichnung: Security-Layer) an.
2.2MOA-ID-AUTH erzeugt eine HTML-Seite mit einem <InfoboxReadRequest> + zum Auslesen der Personenbindung. Diese HTML-Seite wird an den Browser geschickt.
2.3Der 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.4MOA-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.5Der Request wird vom Security-Layer verarbeitet. Die signierten Daten werden an +MOA-ID-AUTH zurückgesendet.
2.6MOA-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.7Ist der obige Authentisierungsvorgang erfolgreich, dann wird eine Redirect-Seite +zum Browser gesendet.
3Der Browser führt das Redirect zur Proxykomponente durch. Als Parameter wird das von MOA-ID-AUTH +erzeugte SAML-Artifact übergeben.
4Die 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.
5MOA-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.
6Ist 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.
+ + +
+

+ + + + + +

 +
+
© 2003
+
+
+ + +
+ + \ No newline at end of file -- cgit v1.2.3