From 1d918b4e05d06ed39f6215fd70ce375a38a300b8 Mon Sep 17 00:00:00 2001 From: Klaus Stranacher Date: Thu, 16 May 2013 09:35:16 +0200 Subject: New design MOA-ID and MOA-SPSS documentation --- id/server/doc/moa_id/id-anwendung_2.htm | 368 +++++++++++++------------------- 1 file changed, 149 insertions(+), 219 deletions(-) (limited to 'id/server/doc/moa_id/id-anwendung_2.htm') diff --git a/id/server/doc/moa_id/id-anwendung_2.htm b/id/server/doc/moa_id/id-anwendung_2.htm index 4e2e89d74..68c055059 100644 --- a/id/server/doc/moa_id/id-anwendung_2.htm +++ b/id/server/doc/moa_id/id-anwendung_2.htm @@ -1,246 +1,176 @@ - MOA ID-Anwendung + MOA-ID Anwendung - - - - - + - -
- - -
- Module für Online-Applikationen -
-
-  -
-
-Projekt moa  -
-
- - - - - + +
-
MOA-ID

- - - -
- -

-
-Abfragearten: -
-Web Service
-MOA-ID-PROXY
-
-
+ + + + + +
Logo BKADokumentationLogo EGIZ
+
+

MOA: Identifikation (ID)

+

Basis-Installation

+
+

Inhalt

+
    +
  1. +

    Übersicht

    +
    2. +
  2. +

    Aufruf des MOA-ID-AUTH Web Service

    +
    3. +
  3. +

    Einsatz von MOA-ID-PROXY zum Abfragen der Anmeldedaten von MOA-ID-AUTH

    +
    4. +
+
- -

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

1 Übersicht

+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:
+ + + + + + + + + + + + + + + +
<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. +
  3. 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.
    4. +
  4. Es wird die MOA-ID-PROXY Webapplikation eingesetzt, um die Anmeldedaten abzuholen und an die OA zu übergeben.
    + Aus Sicht von MOA-ID-PROXY ist bedeutsam, ob die OA die Anmeldedaten nach Abarbeitung des HTTP-Requests behält. +
      +
    • Stateful OA: MOA-ID-PROXY übergibt einmalig die Anmeldedaten an die OA, und die OA speichert die Anmeldedaten, typischerweise unter Einsatz von Cookies.
      • +
    • Stateless OA: MOA-ID-PROXY übergibt die Anmeldedaten bei jedem HTTP-Request vom Browser des Bürgers an die OA.
      • +
    + Diese Variante ist vorzuziehen, wenn +
      +
    • für die Plattform, auf der die OA aufbaut, Web Service-Schnittstellen nicht verfügbar sind
      • +
    • das nötige Web Service-Know How nicht zur Verfügung steht
      • +
    • die Implementierung von Variante 1 zu aufwändig wäre
      • +
    • eine Anpassung der OA aus bestimmten Gründen nicht möglich ist
      • +
    +
- - - -
- - - -
-

 

-
-

-
-		 -

Aufruf des MOA-ID-AUTH Web Service

-
Das MOA-ID-AUTH Web Service wird über einen <samlp:Request> aufgerufen. -Der <samlp:Request> enthält in einem <samlp:AssertionArtifact> das von MOA-ID-AUTH übergebene SAML-Artifact. -

-MOA-ID-AUTH liefert als Antwort einen <samlp:Response>. Die Anmeldedaten sind im <samlp:Response> in Form einer <saml:Assertion> enthalten. -

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

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

    -
  • 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
    • +
  • + SAML 1.0 Protocol Schema
    +
    • +
  • +SAML 1.0 Assertion Schema

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

Der detaillierte Aufbau der <saml:Assertion> zu den Anmeldedaten ist in der Spezifikation MOA-ID 1.4 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.4.0+, 1.5.0Java Development Kit
Xerces
XML Parser		2.0.2+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
Servlet API2.3+Download: java.sun.com/products/servlet
Java-BibliothekVersionBemerkung
JDK1.4.0+, 1.5.0Java Development Kit
Xerces
+ XML Parser		2.0.2+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
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. -
+

3 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)
    • +
  • 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 + 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). -
-
- - - - - -

 -
-
© 2012
-
- - -
+ Falls nötig, kann eine maßgeschneiderte Implementierung von ConnectionBuilder erstellt und zusammen mit MOA-ID-PROXY zum Einsatz gebracht werden + (siehe API). -- cgit v1.2.3