Open Source
für das E-Government
|
Open Source
für das E-Government |
MOA: Serversignatur (SS) und Signaturprüfung (SP), V 1.2
Anwendung
Die Module Signaturprüfung (SP) und Serversignatur (SS) sind als plattformunabhängige Module ausgelegt, die entweder als Webservice über HTTP bzw. HTTPS oder als Klassenbibliothek über ein API angesprochen werden können. Dieses Handbuch beschreibt die Anwendung der beiden Module auf jede dieser beiden Arten.
Dieser Abschnitt beschreibt die Verwendung der Module SP und SS über die Webservice-Schnittstelle. Im ersten Unterabschnitt werden typische XML-Requests zur Signaturerstellung mittels SS bzw. zur Signaturprüfung mittels SP vorgestellt, wie sie an das Webservice gesendet werden können. Der zweite Unterabschnitt stellt beispielhafte Implementierungen eines Webservice-Clients in Java vor.
Dieser Abschnitt stellt typische XML-Requests für die Erstellung einer XML-Signatur mittels SS bzw. zur Prüfung einer CMS- bzw. XML-Signatur mittels SP vor. Zu jedem Request wird jeweils auch eine typische Response des Services besprochen.
CreateXMLSignatureRequest1.xml ist ein einfacher XML-Request zur Erzeugung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert:
<KeyIdentifier>KG_allgemein</KeyIdentifier>
KG_allgemein bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen.
<SingleSignatureInfo SecurityLayerConformity="false">
Für jedes SingleSignatureInfoElement wird eine eigene XML-Signatur erzeugt. Wird das Attribut SecurityLayerConformity auf true gesetzt, dann wird eine XML-Signatur gemäß Security-Layer Spezifikation V1.1 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">
<DataObject>
<XMLContent xml:space="preserve">Diese Daten werden signiert.<XMLContent>
</DataObject>
Für jedes Daten-Objekt, das in die XML-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 sollen (Structure="enveloping"), oder über einen URL referenziert werden sollen (Structure="detached").
Im Fall von Structure="enveloping" muss im nachfolgenden DataObject Element entweder das Attribut Reference (enthält eine URL, von der SS die Daten beziehen soll) gesetzt sein, oder aber die zu signierenden Daten werden explizit in einem der Elemente Base64Content (enthält Daten in Base64 kodierter Form) oder XMLContent (enthält Daten als beliebiges XML-Fragment) oder LocRefContent (enthält eine URL, von der SS die Daten beziehen soll; in diesem Fall also gleichwertig wie ein gesetztes Attribut Reference) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut Reference und gleichzeitig einem der Elemente Base64Content oder XMLContent oder LocRefContent ist nicht erlaubt.
Im Fall von Structure="detached" muss das Attribut Reference im nachfolgenden DataObject Element gesetzt sein. Es enthält jene URL, die zur Referenzierung der Daten als Wert von dsig:Reference/@URI in die XML-Signatur aufgenommen wird. Die Angabe eines der Element Base64Content oder XMLContent oder LocRefContent ist optional. Unterbleibt die Angabe, bezieht SS die Daten von der URL im Attribut Reference. Wird eines der Elemente verwendet, bezieht SS die Daten durch Analyse des angegebenen Elements (siehe obiger Absatz).
Im konkreten Beispiel sollen die Daten in ein dsig:Object Element integriert werden (Structure="enveloping"). Die Daten werden mittels XMLContent als XML-Fragment (ein einfacher Textknoten) angegeben.
<CreateTransformsInfoProfile>Zu jedem Daten-Objekt können optional Transformationen (z.B. XPath, XSLT, Base64-Decodierung, etc.) angegeben werden. Werden - wie hier im Beispiel - keine Transformationen angegeben, so muss zumindest der MIME-Type der zu signierenden Daten spezifiziert werden.
<CreateTransformsInfo> <FinalDataMetaInfo> <MimeType>text/plain<MimeType> </FinalDataMetaInfo> </CreateTransformsInfo> </CreateTransformsInfoProfile>
CreateXMLSignatureRequest1.resp.xml ist eine typische Response des SS Webservice auf den obigen Request. Sein Aufbau wird nachfolgend analysiert:
<CreateXMLSignatureResponse xmlns="http://reference.e-government.gv.at/namespace/moa/20020822#"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<SignatureEnvironment>
<dsig:Signature Id="signature-1-1" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<dsig:SignedInfo> ... <dsig:Reference Id="reference-1-1" URI="#xpointer(id('signed-data-1-1-1')/node())"> ... </dsig:Reference> ... </dsig:SignedInfo> ... <dsig:Object Id="signed-data-1-1-1">Diese Daten werden signiert.</dsig:Object> </dsig:Signature>
</SignatureEnvironment>
</CreateXMLSignatureResponse>
Bitte beachten Sie, dass der die oben dargestellte Response zur bessernen Lesbarkeit eingerückt und gekürzt wurde. CreateXMLSignatureResponse enthält je erzeugter Signatur ein Element SignatureEnvironment (in diesem Fall genau ein Element). SignatureEnvironment enthält die von SS erzeugte XML-Signatur, die im obigen Request spezifiziert wurde. Man erkennt, dass die XML-Signatur genau ein Daten-Objekt unterzeichnet (ein dsig:Reference Element ist enthalten). Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (enveloping), und zwar in einem dsig:Object Element.