From 1c900609d64445040e8c5bdbfa01ae1a0f563f43 Mon Sep 17 00:00:00 2001 From: gregor Date: Wed, 28 Feb 2007 13:17:57 +0000 Subject: Initial commit git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@806 d688527b-c9ab-4aba-bd8d-4036d912da1d --- erecht.client.ss/handbook/system/system.html | 529 +++++++++++++++++++++++++++ 1 file changed, 529 insertions(+) create mode 100644 erecht.client.ss/handbook/system/system.html (limited to 'erecht.client.ss/handbook/system/system.html') diff --git a/erecht.client.ss/handbook/system/system.html b/erecht.client.ss/handbook/system/system.html new file mode 100644 index 000000000..e4924f5fb --- /dev/null +++ b/erecht.client.ss/handbook/system/system.html @@ -0,0 +1,529 @@ + + + + + + MOA SL - Systemhandbuch + + + + + + + + + + + + + + + + + + + + + + + + +
Logo BKAOpen +Source
+ +für das E-Government		Logo MOA
+ +
+

MOA: +Serverseitige Signaturprüfung (SL), V 1.1

+ +

Systemhandbuch

+ +
+

Inhalt

+ +
    + +
  1. +

    Einführung

    + +
    2. + +
  2. Überblick
    3. + +
  3. Komponenten +
      + +
    1. Der +Filter SL2MOAFilter +
      2. + +
    2. Das +Servlet MOAServlet +
      3. + +
    3. Die +JSP-Seite resultOverview.jsp +
      4. + +
    4. Das +Servlet HashInputDataServlet
      5. + +
    5. Das +Servlet ReturnServlet
      6. + +
    6. Die +Klasse URLRewriter
      7. + +
    7. Der +Deployment Descriptor web.xml
      8. + +
    + +
    4. + +
  4. Zusammenspiel der +Komponenten +
      + +
    1. Basisablauf
      2. + +
    2. Ablauf mit Rewrite-Proxy
      3. + +
    + +
    5. + +
+ +
+

1 +Einführung

+ +

Das Modul Serverseitige +Signaturprüfung (MOA SL) ist als +plattformunabhängiges Modul ausgelegt, das als Webservice +über HTTP bzw. HTTPS angesprochen werden kann.

+ +

Dieses Handbuch beschreibt den Aufbau von MOA SL. Abschnitt 2 +bietet einen groben Überblick über die Funktionsweise +von MOA SL. Abschnitt 3 beschreibt die einzelnen Komponenenten, aus +denen MOA SL aufgebaut ist. Abschnitt 4 schließlich +beschreibt das Zusammenspiel der einzelnen Komponenten.

+ +

Für die Installation und die Konfiguration von MOA SL +siehe Betriebshandbuch. +

+ +

2 +Überblick

+ +

Das Modul Serverseitige +Signaturprüfung (MOA SL) bietet für +Signaturprüfung eine serverseitige Implementierung einer +Bürgerkarten-Umgebung entsprechend den Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2.

+ +

Der Funktionsumfang von MOA SL kann wie folgt zusammengefasst +werden:

+ + + +

3 +Komponenten

+ +

3.1 +Der Filter SL2MOAFilter

+ +

Die Klasse SL2MOAFilter +ist ein +Filter, +der einerseits +den HttpServletRequest +verändert, bevor er an das Servlet MOAServlet +weitergeleitet wird, und andererseits den HttpServletResponse +verändert, nachdem er vom Servlet MOAServlet +bearbeitet wurde.

+ +

Der HttpServletRequest +enhält ja zunächst den Request zur Prüfung +der XML-Signatur in einem Format entsprechend der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2 (SL-Request). Das MOAServlet +erwartet sich jedoch den +Request zur Prüfung der XML-Signatur in einem Format +entsprechend der Webservice-Schnittstelle für das Basismodul +MOA SP (MOA-Request). Aufgabe des SL2MOAFilters +ist es daher, vor der Ausführung des MOAServlets +für eine passende Umsetzung des SL-Requests in den +entsprechenden MOA-Request zu sorgen.

+ +

Zur Erfüllung dieser +Aufgabe bedient sich der SL2MOAFilter +der Klasse SL2MOA, +in der die Request-Transformation gekapselt ist. Zunächst wird eine einfache Transformation des SL-Requests in den MOA-Request durchgeführt, +indem die Namen der XML-Elemente entsprechend angepasst werden. Danach werden am dadurch entstandenen MOA-Request noch folgende Modifikationen +durchgeführt: +

+

+ +

Das MOAServlet +würde dann die Antwort des Basismoduls MOA SP in einem Format +entsprechend der Webservice-Schnittstelle für das Basismodul +MOA SP (MOA-Response) retournieren. Die Anwendung, die das MOAServlet +aufruft, erwartet sich jedoch die Antwort auf den Request zur +Prüfung +der XML-Signatur in einem Format entsprechend der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2 (SL-Response). Aufgabe des SL2MOAFilters +ist es daher, nach der Ausführung des MOAServlets +für eine passende Umsetzung der MOA-Response in die +entsprechende SL-Response zu sorgen. Zur Erfüllung +dieser +Aufgabe bedient sich der SL2MOAFilter +der Klasse MOA2SL, +in der die +Response-Transformation gekapselt ist.

+ +

Eine weitere Aufgabe der Klasse SL2MOAFilter +ist es schließlich, die JSP-Seite resultoverview.jsp +einzubinden, die für eine benutzertaugliche HTML-Darstellung +der SL-Response sorgt. Diese benutzertaugliche Darstellung wird dann +tatsächlich als finales Resultat des MOAServlets +an die Anwendung zurückübermittelt. Bevor die +JSP-Seite eingebunden wird, erzeugt SL2MOAFilter +Java Beans aus den Informationen der SL-Response und speichert sie im +Request Scope bzw. Session Scope. Diese Java Beans werden dann von der +JSP-Seite zum +Aufbau der benutzertauglichen HTML-Darstellung herangezogen. +Für weitere Informationen zur JSP-Seite sowie zu den von ihr +verwendeten Java Beans siehe Abschnitt 3.3. +

+ +

3.2 +Das Servlet MOAServlet

+ +

Die Klasse +MOAServlet ist ein HttpServlet +und als solches für die Kommunikation mit dem Basismodul MOA +SP verantwortlich.

+ +

Das Servlet liest aus dem ServletInputStream +des HttpServletRequests +den MOA SP Request +zur Prüfung der XML-Signatur und sendet diesen XML-Request +unter Verwendung der Webservice-Schnittstelle von MOA SP an das +Basismodul MOA SP.

+ +

Danach liest das Servlet die vom Basismodul MOA SP auf den +Request zur Prüfung der XML-Signatur +rückübermittelte Response und schreibt diese +XML-Response in den ServletOutputStream +der HttpServletResponse.

+ +

Das MOAServlet bedient sich zur Kommunikation mit MOA SP der +Klasse +MOAInvoker, in der die +Funktionalität des Webservice-Clients für MOA SP +gekapselt ist.

+ +

3.3 Die JSP-Seite resultOverview.jsp

+ +

Die JSP-Seite resultOverview.jsp ist +verantwortlich für die Aufbereitung +einer benutzertauglichen HTML-Darstellung der SL-Response, die +das Servlet MOAServlet +im Zusammenspiel mit dem Filter SL2MOAFilter +erzeugt. 

+ +

Die für die Aufbereitung erforderlichen Informationen +werden der JSP-Seite in Form von Java Beans zur Verfügung +gestellt, die zuvor vom SL2MOAFilter +erzeugt worden sind (vergleiche Abschnitt 3.1). +Folgende Java Beans stehen der JSP-Seite zur Verfügung:

+ + + +

Die JSP-Seite resultOverview.jsp +erzeugt aus den mittels der erwähnten Java Beans zur +Verfügung gestellten Informationen eine HTML-Darstellung. +Diese HTML-Darstellung ist in die folgenden Informationsblöcke +unterteilt:

+ + + +

Ein Beispiel für die resultierende HTML-Darstellung +befindet sich hier.

+ +

3.4 Das Servlet HashInputDataServlet

+ +

Das Servlet HashInputServlet +ist +für die Verfügbarkeit der von der geprüften +XML-Signatur gesicherten Dokumente verantwortlich. 

+ +

In der HTML-Aufbereitung der SL-Response, die von der +JSP-Seite resultOverview.jsp erzeugt wird, +(vergleiche Abschnitt +3.3) befinden sich Links auf alle gesicherten Dokumente. +Diese Links führen jeweils auf das Servlet HashInputServlet. 

+ +

Das Servlet entnimmt aus der aufgerufenen URL die Parameter +zum Auffinden des Session Scopes sowie die fortlaufende Nummer des +gesicherten Dokuments. Im Session Scope ist als Attribut die in Abschnitt 3.3 +erwähnte DataInfoBean: +gespeichert, die alle notwendigen Informationen enthält, damit +das Servlet das angefragte gesicherte Dokument aus dem Filesystem lesen +und als Ergebnis an den Browser zurückliefern kann. Je nach +dem, ob es sich beim gesicherten Dokument um ein SLXHTML-Dokument +handelt oder nicht, wird der Content-Type Header der HTTP Response an +den Browser passend gesetzt.

+ +

3.5 +Das Servlet ReturnServlet

+ +

Das Servlet ReturnServlet +ist nach Quittierung der HTML-Darstellung zur geprüften +XML-Signatur durch den Benutzer für die Weiterleitung der +SL-Response an den DataURL-Server sowie für die Weiterleitung +der daraus resultierenden Antwort des DataURL-Servers an den Benutzer +verantwortlich.

+ +

Damit verhält sich MOA SL genau wie in der +Spezifikation Transportprotokolle +Security-Layer (Teil der Spezifikationen +zur österreichischen Bürgerkarte in der +Version 1.2) in Abschnitt +3.2.3 für den Fall 5e beschrieben ist: Wenn der +Benutzer die HTML-Aufbereitung der Ergebnisse der geprüften +XML-Signatur gesichtet hat und durch Verfolgung des darin enthaltenen +Links quittiert, sendet das ReturnServlet +die SL-Response an den DataURL-Server. Die URL des DataURL-Servers +wurde von der Anwendung im ursprünglichen Request an das MOAServlet +als Formular-Parameter angegeben. Der DataURL-Server antwortet auf das +Eintreffen der SL-Response mit einem HTTP-Response an das ReturnServlet, +diese wird vom ReturnServlet +als Antwort auf das Quittieren der HTML-Darstellung an den Browser +weitergeleitet. 

+ +

Nachdem mit diesem Schritt die Bearbeitung der zur +Prüfung übermittelten XML-Signatur durch MOA-SL +abgeschlossen ist, wird am Ende des ReturnServlet +die Session und damit alle gespeicherten Informationen zur +geprüften XML-Signatur gelöscht. 

+ +

3.6 +Die Klasse URLRewriter

+ +

Die Klasse URLRewriter +ist +für das Umschreiben von URLs verantwortlich die in der +HTML-Aufbereitung der SL-Response enthalten sind, die dem Benutzer in +seinem Webbrowser angezeigt wird.

+ +

MOA SL kann so konfiguriert werden, dass die in der +HTML-Aufbereitung der SL-Response enthaltenen +URLs nicht direkt +auf +Ressourcen von MOA SL (z.B. die von der Signatur gesicherten +Dokumente), sondern auf einen Rewrite-Proxy +verweisen. Die URL auf die eigentliche Ressource von MOA SL ist in dem +umgeschriebenen Link als URL-Parameter kodiert. Der Rewrite-Proxy sorgt +für die Umsetzung des aus dem umgeschriebenen Link +resultierenden +Requests an ihn selbst in einen Request an MOA SL. 

+ +

Sinnvoll ist diese Konfigurationsvariante dann, wenn MOA SL +nicht direkt vom Internet aus erreichbar sein soll, sondern nur auf dem +Umweg über einen dedizierten Webserver, dem Rewrite-Proxy.

+ +

Die Methode rewrite der Klasse URLRewriter +wird bei der Erstellung der HTML-Aufbereitung der SL-Response durch die +JSP-Seite resultOverview.jsp jedenfalls +aufgerufen; die Entscheidung, ob die in die Methode übergebene +URL tatsächlich umgeschrieben wird oder nicht, entscheidet die +Methode auf Grund der Konfigurationseinstellungen von MOA SL.

+ +

3.7 +Der Deployment Descriptor web.xml

+

+Im Deployment Descriptor web.xmldes +Web Archives (WAR-File) von MOA SL sind im Wesentlichen folgende +Konfigurationen eingerichtet, die im Normalfall nicht verändert +werden müssen:

+ + +

4 +Zusammenspiel der Komponenten

+ +

4.1 Basisablauf

+

Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus Abschnitt 3 mit dem Anwender und dem DataURL-Server dar.

+

Zusammenspiel der Komponenten - Basisablauf

+ + + + + + + + + + + + + + + +
1, 2 +

Prüfung der Signatur: Anfrage wird eigentlich an MOAServlet gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der SL2MOAFilter dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom SL2MOAFilter an die JSP-Seite resultOverview.jsp delegiert.

+
3,4 +

Über die HTML-Ansicht der SL-Response kann der Anwender +die einzelnen, von der XML-Signatur gesicherten Dokumente abrufen. +Die Links für die Dokumente verweisen auf das HashInputServlet, die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).

+
5, 6, 7, 8 +

In Schritt 5 quittiert der Anwender die HTML-Darstellung der +SL-Response. Das Quittieren funktioniert über einen Link in der +HTML-Darstellung, der auf das ReturnServlet verweist. Das ReturnServlet +sendet die SL-Response an den DataURL-Server. Der DataURL-Server +antwortet entsprechend auf die übermittelte SL-Response; diese +Antwort wird vom ReturnServlet unverändert an den Antwender weitergeleitet.

+
+

4.2 Ablauf mit Rewrite-Proxy

+Die nachfolgende Grafik stellt das Zusammenspiel der Komponenten aus +Abschnitt 3 mit dem Anwender und dem DataURL-Server dar, wobei die +Anfragen vom Anwender nicht direkt an MOA SL, sondern indirekt +über einen Rewrite-Proxy gestellt werden.
+
Zusemmenspiel der Komponenten - mit Rewrite-Proxy
+
+ + + + + + + + + + + + + + + +
1, 2 +

Prüfung der Signatur: Anfrage wird eigentlich an MOAServlet gerichtet, durch die Filter-Konfiguration über den Deployment-Descriptor web.xml wird jedoch vorher und nachher der SL2MOAFilter dazwischengeschalten. Die Aufbereitung der HTML-Darstellung der SL-Response wird vom SL2MOAFilter an die JSP-Seite resultOverview.jsp delegiert. Die Anfrage des Anwenders wird nicht direkt an das MOAServlet gerichtet, sondern über den Rewrite-Proxy, der die Anfrage-URL passend umschreibt.

+
3,4 +

Über +die HTML-Ansicht der SL-Response kann der Anwender die einzelnen, von +der XML-Signatur gesicherten Dokumente abrufen. Die Links für die +Dokumente verweisen nicht direkt auf das HashInputServlet, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das HashInputServlet umsetzt. Die Zuordnung im Servlet passiert über URL-Parameter (Session-ID, fortlaufende Nummer des Dokuments).

+
5, 6, 7, 8 +

In +Schritt 5 quittiert der Anwender die HTML-Darstellung der SL-Response. +Das Quittieren funktioniert über einen Link in der HTML-Darstellung, +der nicht direkt auf das ReturnServlet verweist, sondern zunächst auf den Rewrite-Proxy, der die Links passend auf das ReturnServlet  umsetzt. Das ReturnServlet +sendet die SL-Response an den DataURL-Server. Der DataURL-Server +antwortet entsprechend auf die übermittelte SL-Response; diese Antwort +wird vom ReturnServlet unverändert an den Antwender weitergeleitet.

+
+
+
+ + -- cgit v1.2.3