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.
|
Beispiel-Programme 
Zurück|
|
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.
|
|
|
Beispiel-Programme Im folgenden werden vier Beispiele für Client-Applikationen beschrieben:
|
|
|
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:
|
|
|
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
Folgende VM-Properties müssen gesetzt sein um das API Beispiel
ausführen zu können.
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:
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:
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:
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:
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
|