From 4075bf26b65cf2be4c55f2e9cbdc1b854a41dbce Mon Sep 17 00:00:00 2001 From: pdanner Date: Wed, 5 Sep 2007 10:02:19 +0000 Subject: removed obsolete files git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@990 d688527b-c9ab-4aba-bd8d-4036d912da1d --- spss.slinterface/handbook/system/system.html | 529 --------------------------- 1 file changed, 529 deletions(-) delete mode 100644 spss.slinterface/handbook/system/system.html (limited to 'spss.slinterface/handbook/system/system.html') diff --git a/spss.slinterface/handbook/system/system.html b/spss.slinterface/handbook/system/system.html deleted file mode 100644 index 7831b7eb6..000000000 --- a/spss.slinterface/handbook/system/system.html +++ /dev/null @@ -1,529 +0,0 @@ - - - - - - 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