From ece7d18cf35374bf4e26d041799cda8f791c89f8 Mon Sep 17 00:00:00 2001 From: gregor Date: Mon, 7 Jul 2003 10:58:37 +0000 Subject: Initial commit git-svn-id: https://joinup.ec.europa.eu/svn/moa-idspss/trunk@2 d688527b-c9ab-4aba-bd8d-4036d912da1d --- spss.server/doc/moa_spss/sp-anwendung.htm | 1079 +++++++++++++++++++++++++++++ 1 file changed, 1079 insertions(+) create mode 100644 spss.server/doc/moa_spss/sp-anwendung.htm (limited to 'spss.server/doc/moa_spss/sp-anwendung.htm') diff --git a/spss.server/doc/moa_spss/sp-anwendung.htm b/spss.server/doc/moa_spss/sp-anwendung.htm new file mode 100644 index 000000000..4adccb46d --- /dev/null +++ b/spss.server/doc/moa_spss/sp-anwendung.htm @@ -0,0 +1,1079 @@ + + + MOA SP/SS-Anwendung + + + + + + + + + +
+ + +
+ Module für Online-Applikationen +
+
+  +
+
+Projekt moa  +
+
+ + + + + + +
+
MOA-SP/SS

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

+		 +
MOA SP/SS-Anwendung
+

+Die Module Signaturprüfung (SP) und Serversignatur (SS) sind als plattformunabhängige Module ausgelegt, die über ein +Webservice bzw. ein Java-API verwendet werden können. +

+Dieses Handbuch beschreibt die Verwendung der SP/SS-Module anhand einfacher exemplarischer Anwendungen: +

    +
  • HTTPClientExample.java
    Aufruf des Webservice über HTTP
    • +
  • HTTPSClientExampleServerAuth.java
    Aufruf des Webservice über eine TLS-Verbindung mit serverseitiger Authentisierung
    • +
  • HTTPSClientExampleClientAuth.java
    Aufruf des Webservice über eine TLS-Verbindung mit client- und serverseitiger Authentisierung
    • +
  • APIClientExample.java
    Aufruf des API
    • +
+Weiters werden folgende Beispiel-Requests beschrieben: +
    +
  • einfache Requests für die Erstellung und Überprüfung einer XML-Signatur
    • +
  • umfassende Requests für die Erstellung und Überprüfung einer XML-Signatur
    • +
  • ein Request für die Überprüfung einer CMS-Signatur
    • +
+ +

+
+ + +
+ + + +
+

 

+ +		 +

Voraussetzungen

+
+Die folgende Liste enthält die erforderlichen Java-Bibliotheken, um die Beispielprogramme auszuführen. +Die angeführten Versionsnummern bezeichnen jene Versionen dieser Java-Bibliotheken, mit denen die +Beispielprogramme getestet wurden. +

+ + + + + + + + + + + + + + + + + + + +
Java-BibliothekVersionBemerkung
JDK1.3+Java Development Kit
Xerces
XML Parser		2.0.2+nicht nötig wenn JDK 1.4 verwendet wird
+ Download: xml.apache.org/xerces2-j
AXIS Framework1.0+Download: xml.apache.org/axis
JSSE1.0.3+wenn eine SSL Verbindung verwendet wird, nicht nötig wenn JDK 1.4 verwendet wird
Download: java.sun.com/products/jsse
Servlet API2.3+nicht nötig wenn AXIS 1.1 verwendet wird
+Download: java.sun.com/products/servlet
+
+
+

+ + + +
+ + + +
+

 

+

 

+		 +

Beispiel-Programme

+
Im folgenden werden vier Beispiele für Client-Applikationen beschrieben:
+
    +
  • HTTPClientExample
    +Aufruf des Webservice über HTTP
    • +
  • HTTPSClientExampleServerAuth
    +Aufruf des Webservice über eine TLS-Verbindung mit serverseitiger Authentisierung
    • +
  • HTTPSClientExampleClientAuth
    +Aufruf des Webservice über eine TLS-Verbindung mit client- und serverseitiger Authentisierung
    • +
  • APIClientExample
    +Aufruf des API
    • +
+
+

+ + + +
+ + + +
+

 

+ +		 +

Beispiel HTTPClientExample

+
+1. Einlesen des XML-Request aus einer Datei
+
+    FileInputStream inputStream = 
+        new FileInputStream("example_request.xml");
+

+ +2. Aufbau der DOM-Struktur
+Erstellen der BuilderFactory für den Parser +
+    DocumentBuilderFactory factory = 
+        DocumentBuilderFactory.newInstance();
+
+Namespaces müssen im Request definiert sein, darum +
+    factory.setNamespaceAware(true);
+
+Einen neuen Builder instanzieren +
+    DocumentBuilder builder = 
+        factory.newDocumentBuilder();
+
+XML-Datei einlesen und parsen +
+    Document root_request = 
+        builder.parse(inputStream);
+
+

+ +3. AXIS Service instanzieren
+Service erstellen. SERVICE_QNAME ist entweder SignatureCreation oder SignatureVerification. +
+    Service service = 
+        ServiceFactory.newInstance().
+            createService(SERVICE_QNAME);
+
+Call Object erstellen +
+    Call call = service.createCall();
+
+Ein SOAP Body Objekt erzeugen und mit dem Request aus der Datei füllen +
+    SOAPBodyElement body = 
+        new SOAPBodyElement(root_request.
+            getDocumentElement());
+    SOAPBodyElement[] params = 
+        new SOAPBodyElement[] {body};
+
+Serviceendpunkt einstellen. URL zum Server mit dem Webservice z.b. http://localhost:8080/moa-spss/services/SignatureCreation. +
+    call.setTargetEndpointAddress(ENDPOINT);
+
+

+ +4. Service aufrufen
+Request durchführen (Parameter werden als Array von SOAPBodyElement-Objekten übergeben) +
+    Vector responses = (Vector)call.invoke(params);
+
+Response auslesen +
+    SOAPBodyElement response = 
+        (SOAPBodyElement) responses.get(0);
+
+Response-Document auslesen +
+    Document root_response = response.getAsDocument();
+
+

+ +5. Exceptions behandeln
+Folgende Exceptions können auftreten und müssen bei der Dokumentverarbeitung +behandelt werden:
+ + + + + + + + + + + + + + + + + +
ExceptionBeschreibung
FileNotFoundExceptionDatei kann nicht gefunden werden
IOExceptionDatei kann nicht gelesen werden
ParserConfigurationExceptionParsereinstellungen nicht korrekt
xxSAXExceptionFehler beim Parsen (z.b. XML-Fehler in der Eingabedatei)
ServiceExceptionFehler beim Durchführen des AXIS Request
RemoteExceptionProbleme mit der Verbindung
+ +
+
+

+ + + +
+ + + +
+

 

+ +		 +

Beispiel HTTPSClientExampleServerAuth

+
+Zusätzlich zu HTTPClientExample:

+Erst werden die Konstanten für die Systemproperties gesetzt +
+    handler = "java.protocol.handler.pkgs";
+    trustStore = "javax.net.ssl.trustStore";
+    trustStorePassword = 
+      "javax.net.ssl.trustStorePassword";
+
+Hinzufügen des SSL-Providers in das Systemobjekt Security +
+    Security.addProvider(
+      new com.sun.net.ssl.internal.ssl.Provider());
+
+Setzen der Systemproperties für den SSL-Provider +
+    System.setProperty(
+      handler,"com.sun.net.ssl.internal.www.protocol");
+    System.setProperty(
+      trustStore, "client.keystore");
+    System.setProperty(trustStorePassword, "changeit");
+
+ +Danach muß nur noch der Endpunkt umgestellt werden von ENDPOINT zu SECURE_ENDPOINT +
+    "http://localhost:8080/moa-spss/
+            services/SignatureCreation"
+
+wird zu +
+    "https://localhost:8443/moa-spss/
+            services/SignatureCreation"
+
+AXIS erkennt das es sich um eine sichere Verbindung handelt und initialisert die Verbindung über einen SecureSocket. +
+
+

+ + + +
+ + + +
+

 

+ +		 +

Beispiel HTTPSClientExampleClientAuth

+
+Zusätzlich zu HTTPSClientExampleServerAuth:

+Für Clientauthorisierung kommen noch folgende Properties hinzu +
+    keyStore = "javax.net.ssl.keyStore";
+    keyStorePassword = "javax.net.ssl.keyStorePassword";
+    System.setProperty(
+        keyStore, "client.keystore");
+    System.setProperty(keyStorePassword, "changeit");
+
+
+
+

+ +
+ + + +
+

 

+
+Beispiel:
+APIClientExample
+

+
+		 +

Beispiel APIClientExample

+
+Folgende VM-Properties müssen gesetzt sein um das API Beispiel +ausführen zu können.

+ + + + + + + + + + + + + +
moa.spss.server.configuration
Pfad zur Konfiguration von MOA-SPSSBeispiel C:\moa\ConfigurationTest.xml
log4j.configuration
Pfad zu einer gültigen Log4J KonfigurationBeispiel file:/C:/moa/log4j.properties
+
+Serverfunktionshandler instanzieren +
	SPSSFactory spf = 
+		SPSSFactory.getInstance();
+ +Signaturedaten in ein Contentobjekt einbinden +
	byte[]data = 
+		"Dies sind Testdaten".getBytes("UTF-8");
+	ByteArrayInputStream bis = 
+		new ByteArrayInputStream(data);
+	Content cont = 
+		spf.createContent(bis,"http://uri.data.org");
+ +Beschreibungselement zu den Daten erstellen +
	MetaInfo mi = 
+	spf.createMetaInfo("text/plain","Testdaten",null);
+ +Transformationen erstellen +
	CreateTransformsInfo cti = 
+		spf.createCreateTransformsInfo(null,mi);
+	CreateTransformsInfoProfile ct = 
+		spf.createCreateTransformsInfoProfile(
+			cti,
+			null);
+ +Datenobjekt aufbauen +
	DataObjectInfo doi = 
+		spf.createDataObjectInfo(
+			DataObjectInfo.STRUCTURE_DETACHED,
+			false,
+			cont,
+			ct);
+	List dataobjectinfolist = new ArrayList();
+	dataobjectinfolist.add(doi);
+ +alles zusammenpacken zu einer SingleSignature +
	SingleSignatureInfo ssi = 
+		spf.createSingleSignatureInfo(
+			dataobjectinfolist,
+			null,
+			false);
+	List singlesignatureinfolist = new ArrayList();
+	singlesignatureinfolist.add(ssi);
+die Signatur in einen Request einbetten +
	CreateXMLSignatureRequest cxsreq = 
+		spf.createCreateXMLSignatureRequest(
+			"PKCS12RSAKey1",
+			singlesignatureinfolist);
+ +Signatureerstellungsservice instanzieren +
	SignatureCreationService scs = 
+		SignatureCreationService.getInstance();
+ +Signatureerstellungsservice aufrufen +
	CreateXMLSignatureResponse cxsres = 
+		scs.createXMLSignature(cxsreq);
+ +Response auswerten +
	List elements = cxsres.getResponseElements();
+	
+	SignatureEnvironmentResponse ser = 
+	(SignatureEnvironmentResponse)elements.get(0);
+ +Responsetyp lesen +
	int response_type = ser.getResponseType();
+	if(response_type == 
+		SignatureEnvironmentResponse.ERROR_RESPONSE)
+	{
+		...
+	}
+
+Fehlerfall +
	System.out.println("Bei der Erstellung der 
+	Signatur ist ein Fehler aufgetreten");
+
+Signaturerstellung erfolgreich +
	Element se = ser.getSignatureEnvironment();
+	System.out.println(
+		"Signaturerstellung erfolgreich");
+	displayTree(se);
+
+ +
+
+

+ + +
+ + + +
+

 

+		 +

Beispiel-Requests

+
+In den folgenden Abschnitten werden einfache und umfassende Beispiele für Requests beschrieben, die an MOA-SP/SS +gesendet werden können. Damit soll der Anwendungsentwickler einen Überblick über die +Möglichkeiten von MOA-SP/SS vermittelt bekommen. Die detaillierte und vollständige Beschreibung +des Funktionsumfangs ist in den Spezifikationen von MOA-SP/SS und des Security-Layers enthalten. +
+
+

+ + + +
+ + + +
+

 

+
+Beispiel:
+Request
+Response
+

+
+		 +

Beispiel:
einfacher CreateXMLSignatureRequest

+
+Das Beispiel in CreateXMLSignatureReqest1.xml zeigt einen +einfachen <CreateXMLSignatureRequest>. Die Bedeutung der einzelnen Elemente +wird im folgenden beschrieben: +
+  <KeyIdentifier>PKCS12RSAKey1</KeyIdentifier>
+
+PKCS12RSAKey1 bezeichnet eine Schlüsselgruppe aus der MOA-SS einen Signaturschlüssel selektieren soll +und muss einer im Konfigurationsfile definierten <KeyGroup> entsprechen. +
+  <SingleSignatureInfo SecurityLayerConformity="false">
+
+Für jedes <SingleSignatureInfo>-Element wird eine eigene XML-Signatur erzeugt. Wird das +Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur +gemäß Security-Layer Spezifikation erzeugt; d.h. es werden signierte Properties (Zeitpunkt +der Signaturerstellung, +das für die Signaturüberprüfung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten) und ein +Manifest, das alle implizite Transformationsparameter enthält, zur Signatur hinzugefügt. +
+    <DataObjectInfo Structure="enveloping">
+
+Für jedes Daten-Objekt, das in die Signatur als dsig:Reference aufgenommen werden soll, muss ein +DataObjectInfo-Element spezifiziert werden. Das Attribut Structure gibt an, ob die Daten +in die Signatur in ein <dsig:Object>-Element integriert werden soll +(Structure="enveloping") oder via eine URL referenziert werden soll (Structure="detached"). +

+Im Fall von Structure="enveloping" muss im nachfolgenden DataObject Element entweder das +Attribut Reference gesetzt sein oder die zu signierenden Daten explizit im Element Base64Content oder +XMLContent spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference +und gleichzeitig dem Element Base64Content oder XMLContent ist nicht erlaubt. +

+Im Fall von Structure="detached" muss das Attribut Reference im nachfolgenden DataObject +Element gesetzt sein. Die Angabe der Elemente Base64Content oder XMLContent ist optional. +
+      <DataObject>
+        <XMLContent xml:space="preserve">
+          Diese Daten werden signiert.
+        <XMLContent>
+      </DataObject>
+
+Die zu signierenden Daten werden im Element <DataObject> spezifiziert und können entweder als +<XMLContent> oder <Base64Content> oder über das Attribut Reference +angegeben werden. +
+      <CreateTransformsInfoProfile>
+        <CreateTransformsInfo>
+          <FinalDataMetaInfo>
+            <MimeType>text/plain<MimeType>
+          </FinalDataMetaInfo>
+        </CreateTransformsInfo>
+      </CreateTransformsInfoProfile>
+
+Zu jedem Daten-Objekt können optional Transformationen (z.B. XPath, XSLT, Base64-Decodierung, etc.)angegeben werden. +Werden keine Transformationen angegeben so muss zumindest der MIME-Type der zu signierenden Daten spezifiziert werden. +

+Die von diesem Request erzeugt Response ist in CreateXMLSignatureResponse1.xml abgelegt. +

+
+

+ + +
+ + + +
+

 

+
+Beispiel:
+Request
+Response
+

+
+		 +

Beispiel:
einfacher VerifyXMLSignatureRequest

+
+Die oben erzeugte XML-Signatur kann mit dem in VerifyXMLSignatureReqest1.xml gezeigten +einfachen <VerifyXMLSignatureRequest> wieder überprüft werden. +
+<VerifyXMLSignatureRequest
+  xmlns="http://reference.e-government.gv.at/
+                namespace/moa/20020822#"
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  
+  <VerifySignatureInfo>
+    <VerifySignatureEnvironment>
+      <XMLContent>
+        <dsig:Signature
+          Id="signature-1"
+          xmlns:dsig="http://www.w3.org/2000/09/
+                             xmldsig#">
+          .........
+        </dsig:Signature>
+      </XMLContent>
+    </VerifySignatureEnvironment>
+
+ +Im Element VerifySignatureInfo wird zuerst die zu überprüfende Signatur im Element +VerifySignatureEnvironment angegeben. Im Beispiel wird die Signatur als Kind-Element von +<XMLContent> spezifiziert. Alternativ könnte die Signatur in Base64-Kodierung +im Element <Base64Content> oder mit dem Attribut Reference über eine URL +referenziert werden. + +
+    <VerifySignatureLocation>
+      //dsig:Signature
+    </VerifySignatureLocation>
+    
+  </VerifySignatureInfo>
+
+ +Weiters muss mittels eines XPath-Ausdrucks im Element <VerifySignatureLocation> +die Position der zu prüfenden Signatur spezifiziert werden. Werden im XPath-Ausdruck +Namespace-Prefixes verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext +des Elements VerifySignatureLocation bekannt sein. Im Beispiel wird das Prefix dsig +verwendet, das im Element <VerifyXMLSignatureRequest> deklariert wird. + +
+  <TrustProfileID>TrustProfile1<TrustProfileID>
+
+Abschließend wird im Element <TrustProfileID> ein Trustprofile spezifiziert, das am MOA-SP Server +definiert ist und jene Zertifikate enthält, die für diesen Request als vertrauenswürdig gelten. +

+Die von diesem Request erzeugt Response ist in VerifyXMLSignatureResponse1.xml abgelegt. Die Response enthält das Ergebnis der Signaturprüfung +im Element <SignatureCheck>, das Ergebnis der Zertifikatsprüfung im Element +<CertificateCheck> und Informationen über den Signator im Element +<SignerInfo>/<X509Data>. Die Informationen über den Signator bestehen aus den Elementen +<X509SubjectName>, <X509IssuerSerial> und <X509Certificate>. + +

+
+

+ + +
+ + + +
+

 

Beispiel:
Request
+Response +


+
+

Beispiel:
umfassender CreateXMLSignatureRequest

Das Beispiel in CreateXMLSignatureReqest2.xml zeigt einen umfassenden +<CreateXMLSignatureRequest>. +

+Das Beispiel benötigt zwei Dateien, die über die URL +http://localhost:8080/TestDatenGenerator/resources/<Dateiname> erreichbar sind. +Bevor der Beispiel-Request ausgeführt wird, muss daher +TestDatenGenerator.zip +entpackt und in $CATALINA_HOME/webapps kopiert werden. Voraussetzung ist, dass Tomcat auf Port 8080 läuft. + +
+<CreateXMLSignatureRequest
+  xmlns="http://reference.e-government.gv.at/
+      namespace/moa/20020822#"
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  <KeyIdentifier>PKCS12RSAKey1</KeyIdentifier>
+  <SingleSignatureInfo SecurityLayerConformity="false">
+    <DataObjectInfo Structure="enveloping" 
+    ChildOfManifest="true">
+      <DataObject>
+        <XMLContent>Diese Daten werden 
+        signiert.</XMLContent>
+      </DataObject>
+      <CreateTransformsInfoProfile>
+        <CreateTransformsInfo>
+          <FinalDataMetaInfo>
+            <MimeType>text/plain</MimeType>
+          </FinalDataMetaInfo>
+        </CreateTransformsInfo>
+      </CreateTransformsInfoProfile>
+    </DataObjectInfo>
+  </SingleSignatureInfo>
+
+ +Der Anfang des Requests ist identisch mit dem einfachen CreateXMLSignatureRequest. +Als Variation wurde <ChildOfManifest= "true"> gesetzt. + +Damit wird spezifiziert, dass die zugehörige <dsig:Reference> nicht in das Element +<SignedInfo> sondern in ein XMLDSig-Manifest eingefügt werden soll. + +Wird das Attribut <ChildOfManifest> nicht gesetzt, dann +wird kein XMLDSig-Manifest erzeugt. + +
+  <SingleSignatureInfo SecurityLayerConformity="true">
+
+ +Anschließend wird angegeben, dass eine zweite Signatur erstellt werden soll. +SecurityLayerConformity="true" gibt an, dass die Signatur entsprechend der Security-Layer +Spezifikation Version 1.1 erstellt werden muss, d.h. es werden Signaturattribute und gegebenenfalls ein + +Signatur-Manifest erzeugt. Wird eine Security-Layer konforme Signatur erzeugt, dann +darf <ChildOfManifest="true"> nicht gesetzt sein. +

+Die zweite Signatur soll zwei Datenobjekte enthalten: + +

+    <DataObjectInfo Structure="detached">
+
+ +Für das erste Datenobjekt sollen die signierten Daten nicht in der Signatur enthalten sein (Structure="detached"). + +
+      <DataObject
+        Reference="http://localhost:8080/TestDatenGenerator
+                   /resources/testDaten.txt">
+        <Base64Content>
+          RGllcyBz........DQphdXM=
+        </Base64Content>
+      </DataObject>
+      <CreateTransformsInfoProfile>
+        <CreateTransformsInfo>
+          <FinalDataMetaInfo>
+            <MimeType>text/plain</MimeType>
+          </FinalDataMetaInfo>
+        </CreateTransformsInfo>
+      </CreateTransformsInfoProfile>
+    </DataObjectInfo>
+
+ +Die zu signierenden Daten sind in Base64-Kodierung angegeben und werden in der Signatur über die URL, die im +Attribut Reference angegeben ist, referenziert. Diese URL wird im Zuge der Signaturerstellung +nicht aufgelöst, da die Daten bereits explizit im Request angegeben sind. Es werden keine weitere +Transformationen für das Datenobjekt angegeben. + +
+    <DataObjectInfo Structure="enveloping">
+      <DataObject>
+        <XMLContent xml:space="preserve">
+          <data:book
+            xmlns:data="http://uri.data.org"
+            data:hardback="yes">
+            <data:title>
+              Gesundheitliche Auswirkungen 
+              elektronischer Signaturen
+            </data:title>
+            <data:first-name>Ellipse</data:first-name>
+            <data:last-name>Kurvenreich</data:last-name>
+            <data:birth-date>1951-04-16</data:birth-date>
+            <data:birth-location>
+              Hinterm Berg
+            </data:birth-location>
+            <data:register-number>
+              6-930-21512-12
+            </data:register-number>
+          </data:book>
+        </XMLContent>
+      </DataObject>
+
+ +Das zweite Datenobjekt, das signiert werden soll ist eine XML-Struktur. +

+Für die XML-Struktur wird eine Transformation spezifiziert, die angewendet werden muss, bevor die Daten signiert +werden: +

+      <CreateTransformsInfoProfile>
+
+Transformationen können entweder explizit im Request im Element <CreateTransformsInfoProfile> +angegeben werden oder mit dem Element <CreateTransformsInfoProfileID> über eine am MOA-SS-Server +konfigurierte Profil-ID referenziert werden. +
+        <CreateTransformsInfo>
+
+Im Transformationsprofil werden im Element <CreateTransformsInfo> die Transformationskette +(<dsig:Transforms>) und optionale Ergänzungsobjekte (<Supplement>) angegeben. +
+          <dsig:Transforms>
+            <dsig:Transform
+              Algorithm="http://www.w3.org/TR/
+                1999/REC-xslt-19991116">
+              <xsl:stylesheet
+                xmlns:xsl="http://www.w3.org/
+                   1999/XSL/Transform"
+                version="1.0">
+                <xsl:include
+                  href="http://localhost:8080/
+                        TestDatenGenerator/resources/
+                        CX1_book_not_here.xsl"/>
+              </xsl:stylesheet>
+            </dsig:Transform>
+          </dsig:Transforms>
+
+Im Beispiel besteht die Transformationskette aus einer XSLT-Transformation, die ein weiteres XSLT Stylesheet inkludiert. +MOA-SS unterstützt alle Transformationen aus der XMLDSig-Spezifikation sowie Exclusive XML Canonicalization 1.0 und +XPath Filter 2.0. + +
          
+          <FinalDataMetaInfo>
+            <MimeType>text/html</MimeType>
+          </FinalDataMetaInfo>
+        </CreateTransformsInfo>
+
+<FinalDataMetaInfo> gibt den MIME-Type der Daten an, die das Ergebnis der Transformation bilden und +tatsächlich signiert werden. +

+Weiters können optional Ergänzungsobjekte angegeben werden, die Daten enthalten, die von MOA-SP zur +Signaturerstellung verwendet werden sollen: +

+        <Supplement>
+          <Content Reference="http://localhost:8080/
+                              TestDatenGenerator/resources/
+                              CX1_book_not_here.xsl">
+            <Base64Content>PHhzbDpzdHls.....eWxlc2hlZXQ+
+            </Base64Content>
+          </Content>
+        </Supplement>
+      </CreateTransformsInfoProfile>
+    </DataObjectInfo>
+
+Im aktuellen Beispiel wird ein Ergänzungsobjekt für jenes Stylesheet angegeben, das im Stylesheet der oben +spezifizierten XSLT-Transformation referenziert wird. MOA-SS wird die angegebene URL nicht auflösen sondern +stattdessen die im Ergänzungsobjekt enthaltenen Daten verwenden. +

+

+    <CreateSignatureInfo xmlns:env="http://uri.env.org">
+
+Abschließend wird hier noch mittels des optionalen Elements <CreateSignatureInfo> festgelegt, +dass die zu erzeugende Signatur in ein bereits bestehendes XML-Dokument eingebettet werden soll. Im Beispiel +wird das Namespace-Prefix env hier deklariert, da es weiter unten im Element +CreateSignatureLocation verwendet werden wird. +
+      <CreateSignatureEnvironment>
+        <XMLContent>
+          <env:Document
+            xmlns:env="http://uri.env.org"
+            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+            xsi:schemaLocation="http://uri.env.org
+                                http://anyhost/envSchema.xsd">
+            nach diesem Text wird die Signatur in das Dokument
+            eingefügt
+          </env:Document>
+        </XMLContent>
+      </CreateSignatureEnvironment>
+
+Im Element <CreateSignatureEnvironment> wird das XML-Dokument angegeben. +
+      <CreateSignatureEnvironmentProfile>
+        <CreateSignatureLocation Index="1">
+          /env:Document
+        </CreateSignatureLocation>
+      </CreateSignatureEnvironmentProfile>
+
+Anschließend wird im Profil angegeben an welcher Position des XML-Dokuments die Signatur eingefügt werden +soll. Im Element <CreateSignatureLocation> wird ein XPath-Ausdruck angegeben, der das +Element selektiert, als dessen Kind die Signatur eingefügt werden soll. Das Attribut Index spezifiziert +die Position innerhalb dieses Elements, an der die Signatur eingefügt werden soll. "0" gibt an, +dass die Signatur als erstes Kind eingefügt werden soll. +
+    </CreateSignatureInfo>
+  </SingleSignatureInfo>
+</CreateXMLSignatureRequest>
+
+Abschließend müssen alle Elemente wieder geschlossen werden. +

+Die von diesem Request erzeugt Response ist in +CreateXMLSignatureResponse2.xml abgelegt. Die Response enthält zwei Elemente SignatureEnvironment, die die +beiden erzeugten Signaturen enthalten. +

+
+

+ +
+ + + + + +
+

 

+
+Beispiel:
+Request
+Response
+

+
+		 +

Beispiel:
umfassender VerifyXMLSignatureRequest

+
+Das Beispiel in +VerifyXMLSignatureReqest2.xml zeigt wie die im obigen Beispiel erzeugte zweite Signatur +überprüft werden kann. +
+<VerifyXMLSignatureRequest
+  xmlns="http://reference.e-government.gv.at/
+     namespace/moa/20020822#"
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
+  <DateTime>2003-03-24T12:41:54+01:00</DateTime>
+
+Optional kann ein Datum und eine Uhrzeit angegeben werden, für die die Überprüfung durchgeführt werden soll. + +
  
+  <VerifySignatureInfo>
+    <VerifySignatureEnvironment>
+     <XMLContent>
+       <env:Document xmlns:env="http://uri.env.org" .....>
+         nach diesem Text ..... Dokument eingefuegt
+         <dsig:Signature .....>.....</dsig:Signature>
+       </env:Document>
+      </XMLContent>
+    </VerifySignatureEnvironment>
+
+Die Signatur inklusive des umgebenden XML-Dokuments wird im Element <VerifySignatureEnvironment> +angegeben. +
    
+    <VerifySignatureLocation>
+      //dsig:Signature
+    </VerifySignatureLocation>
+  </VerifySignatureInfo>
+
+Die zu prüfende Signatur aus dem Element <VerifySignatureEnvironment> wird über einen XPath-Ausdruck +spezifiziert. + +Enthält die Signatur ID-Attribute, die referenziert werden, dann muss das XML-Dokument validierend geparst werden können. +Im Beispiel-Request wird die URL des Schemas für das Element env:Document im Attribut xsi:schemaLocation +spezifiziert (http://anyhost/envSchema.xsd). Soll MOA-SP diese URL nicht selbst auflösen, dann kann das +Schema kann im Element SupplementProfile übergeben werden: + +
+  <SupplementProfile>
+    <Content Reference="http://anyhost/envSchema.xsd">
+      <XMLContent xml:space="preserve">
+        <xsd:schema
+          targetNamespace="http://uri.env.org"
+          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+          xmlns:xsd="http://www.w3.org/2001/XMLSchema"
+          elementFormDefault="qualified"
+          attributeFormDefault="unqualified">
+          <xsd:element name="Document">
+            <xsd:complexType mixed="true">
+              <xsd:sequence minOccurs="0"
+                            maxOccurs="unbounded">
+                <xsd:any namespace="##any"
+                         processContents="lax"/>
+              </xsd:sequence>
+            </xsd:complexType>
+          </xsd:element>
+        </xsd:schema>
+      </XMLContent>
+    </Content>
+  </SupplementProfile>
+
+ +
+  <ReturnHashInputData/>
+
+Das Element gibt an, dass für jedes dsig:SignedInfo/dsig:Reference Element jene Daten, die für die +Hash-Berechnung der Signatur als Eingangsdaten verwendet werden, in der Antwort returniert werden sollen. + +
+  <TrustProfileID>TrustProfile1</TrustProfileID>
+</VerifyXMLSignatureRequest>
+
+Abschließend wird ein am MOA-SP Server definiertes Profil angegeben, dass jene Zertifikate umfasst, die für +diesen Request als vertrauenswürdig anzusehen sind. +

+ +Die von diesem Request erzeugt Response ist in +VerifyXMLSignatureResponse2.xml abgelegt. Zusätzlich zu den Daten der Response des einfachen +VerifyXMLSignatureRequests enthält diese Response für jedes dsig:SignedInfo/dsig:Reference Element +ein HashInputData Element. +

+
+

+ + + + + +
+ + + +
+

 

+
+Beispiel:
+Request
+Response
+

+
+		 +

Beispiel:
VerifyCMSSignatureRequest

+
+Das Beispiel in VerifyCMSSignatureRequest.xml zeigt einen +einfachen <VerifyCMSSignatureRequest>. Die Bedeutung der einzelnen Elemente +wird im folgenden beschrieben: +
+<VerifyCMSSignatureRequest
+  xmlns="http://reference.e-government.gv.at/
+    namespace/moa/20020822#"
+  xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"
+  Signatories="1">
+
+Das optionale Attribut Signatories enthält eine Liste von positiven Ganzzahlen und gibt an, welche Signaturen +im CMS-Datenobjekt überprüft werden sollen. Signatories="1" gibt an, dass die erste Signatur geprüft +werden soll. +Wird das Attribut nicht spezifiziert, dann wird ebenfalls die erste Signatur geprüft. Signatories="all" +gibt an, dass alle im CMS-Objekt enthaltene Signaturen geprüft werden sollen. + +
+  <DateTime>2003-04-04T09:30:47-05:00</DateTime>
+
+Das optionale Element <DateTime> gibt an für welchen Zeitpunkt die Signaturüberprüfung +durchgeführt werden soll. Ist das Element nicht im Request enthalten, dann wird die aktuelle Systemzeit +verwendet. + +
+  <CMSSignature>MIIGAAYJKo...mT9fmvKwdJOiA==</CMSSignature>
+
+Das Element <CMSSignature> enthält das CMS-Signaturobjekt in Base64-Kodierung. +

+Sind die signierten Daten nicht in der CMS-Signatur enthalten, müssen sie im DataObject-Element +angegeben werden. Optional kann der MIME-Type dieser Daten spezifiziert werden. Die eigentlichen Daten +müssen im Base64Content-Element in Base64-Kodierung vorliegen. + +
+  <TrustProfileID>TrustProfile1<TrustProfileID>
+
+ +TrustProfile1 referenziert ein im Konfigurationsfile des MOA-Server definiertes Profil, das +jene Zertifikate umfasst, die für diese Überprüfung als vertrauenswürdig gelten. + + +

+Die von diesem Request erzeugt Response ist in +VerifyCMSSignatureResponse.xml abgelegt. Die Response enthält die selben Informationen wie die Response zum +einfachen VerifyXMLSignatureRequest. +

+
+

+ + + + + + +

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