From 76ee7b768603988e4a6ca59011eee2b7dd33fa21 Mon Sep 17 00:00:00 2001 From: Klaus Stranacher Date: Wed, 24 Apr 2013 16:46:35 +0200 Subject: Update Dokumentation --- spss/handbook/handbook/config/config.html | 105 +++++++++---- spss/handbook/handbook/install/install.html | 20 ++- spss/handbook/handbook/usage/usage.html | 107 ++++++------- .../resources/data/deploy/tomcat/server.mod_jk.xml | 166 -------------------- .../resources/data/deploy/tomcat/server.xml | 169 --------------------- 5 files changed, 142 insertions(+), 425 deletions(-) delete mode 100644 spss/server/serverlib/resources/data/deploy/tomcat/server.mod_jk.xml delete mode 100644 spss/server/serverlib/resources/data/deploy/tomcat/server.xml (limited to 'spss') diff --git a/spss/handbook/handbook/config/config.html b/spss/handbook/handbook/config/config.html index 2421deb1b..6809c143d 100644 --- a/spss/handbook/handbook/config/config.html +++ b/spss/handbook/handbook/config/config.html @@ -46,8 +46,13 @@
  1. Allgemeines Parameter
    1. Hardwarebasiertes Kryptographiemodul
      2. -
    2. Auflösen externer URIs
      3. -
    +
  2. Auflösen externer URIs +
      +
    1. Blacklisting
      2. +
    2. Whitelisting
      3. +
    +
    3. +
  • Parameter für MOA SS
    1. Schlüsselspeicher
        @@ -61,6 +66,7 @@
      1. Parameter für XML-Signaturen
      2. Profil für Transformationen
      3. Profil für Signaturumgebung
        4. +
      4. XAdES Version
    2. Parameter für MOA SP
        @@ -108,14 +114,13 @@
    -
    +

    1 Übersicht

    Dieses Handbuch beschreibt detailliert die Konfigurationsmöglichkeiten für MOA SP/SS. Wenn nicht anders angegeben, beziehen sich die Erläuterungen sowohl auf die Konfiguration des Webservices als auch auf die Konfiguration von MOA SP/SS für den Einsatz als Klassenbibliothek.

    1.1 Allgemeines

    1.1.1 Namenskonventionen

    Folgende Namenraum-Präfixe werden in diesem Handbuch zur Kennzeichnung der Namenräume - von XML-Elementen verwendet:

    -

    TODO Weitere Namespaces? Aktuell?

    + von XML-Elementen verwendet:

    @@ -130,7 +135,7 @@ - + @@ -213,8 +218,14 @@
    Präfixhttp://www.w3.org/2000/09/xmldsig#
    moamoa http://reference.e-government.gv.at/namespace/moa/20020822#
    -

    2.1.2 Auflösen externer URIs

    -

    TODO Update Whitelisting

    +

    2.1.2 Auflösen externer URIs

    +

    Standardmäßig ist das Auflösen von externen URIs (inkl. localhost) deaktiviert (d.h. keines der nachfolgenden Konfigurationselement cfg:PermitExternalUris bzw. cfg:ForbidExternalUris existiert). Es gibt jedoch zwei Möglichkeiten das Auflösen zu aktivieren bzw. zu

    + +

    Diese beiden Möglichkeiten stehen wahlweise zur Verfügung, d.h. es kann entweder Blacklisting oder Whitelisting konfiguriert werden.

    +

    2.1.2.1 Blacklisting

    @@ -226,7 +237,7 @@ -
    Name
    Erläuterung

    Mit diesem Element wird MOA SP bzw. SS mitgeteilt ob das Auflösen externer URIs (inkl. localhost) erlaubt ist. Fehlt dieses Element, so ist das Auflösen externer URIs deaktiviert. Ist dieses Element vorhanden, so ist das Auflösen aller externer URIs aktiviert. Durch einen Blacklist-Mechanismus kann jedoch eingeschränkt werden, dass bestimmte URIs, die sich auf dieser Blacklist befinden, nicht aufgelöst werden. Diese Blacklist kann in dem folgenden Kindelement angegeben werden:

    +

    Mit diesem Element wird MOA SP bzw. SS mitgeteilt, dass das Auflösen externer URIs (inkl. localhost) erlaubt ist. Ist dieses Element vorhanden, so ist das Auflösen aller externer URIs aktiviert. Durch einen Blacklist-Mechanismus kann jedoch eingeschränkt werden, dass bestimmte URIs, die sich auf dieser Blacklist befinden, nicht aufgelöst werden. Diese Blacklist kann in dem folgenden Kindelement angegeben werden:

    • Element cfg:BlackListUri: Dieses optionale und unbegrenzten Element gibt einen Blacklist-Eintrag an und besteht aus folgenden zwei weiteren Kindelementen:
        • @@ -245,6 +256,28 @@
    +

    2.1.2.2 Whitelisting

    + + + + + + + + + + + + + +
    Namecfg:Common/cfg:ForbidExternalUris
    GebrauchNull mal bis einmal
    Erläuterung

    Mit diesem Element wird MOA SP bzw. SS mitgeteilt, dass das Auflösen externer URIs (inkl. localhost) zwar verboten ist, aber durch eine Whitelist entsprechende Ausnahmen angeben werden können. D.h. URIs, die sich auf dieser Whitelist befinden werden aufgelöst. Diese Whitelist kann in dem folgenden Kindelement angegeben werden:

    +
      +
    • Element cfg:WhiteListUri: Dieses optionale und unbegrenzten Element gibt einen Whitelist-Eintrag an und besteht aus folgenden zwei weiteren Kindelementen:
      • +
        +
      • Element cfg:IP: Dieses Element vom Type xs:string gibt eine IP-Adresse (z.B.: 127.0.0.1) oder einen IP-Adress-Bereich (z.B.: 192.168) an. Bei Angabe einer IP-Adresse werden nur URIs mit exakt dieser IP-Adresse aufgelöst. Bei Angabe eines IP-Adress-Bereichs werden sämtliche URIs, die mit diesem IP-Bereich beginnen aufgelöst (z.B.: alle IPs im Bereich 192.168.0.0 bis 192.168.255.255)
        • +
      • Element cfg:Port: Dieses optionale Element vom Typ xs:int legt eine bestimmte Portnummer fest. Ist eine Portnummer angegeben werden alle URIs mit obiger IP-Adresse und dieser Portnummer aufgelöst. Ist Portnummer angegeben, sind alle Portnummern offen.
        • +
      +

    2.2 Parameter für MOA SS

    2.2.1 Schlüsselspeicher

    2.2.1.1 Hardware-Schlüsselspeicher

    @@ -327,17 +360,16 @@ Erläuterung -

    TODO Update DigestMethod

    -

    Mit diesem Element wird in MOA SS eine Schlüsselgruppe definiert. Eine Schlüsselgruppe +

    Mit diesem Element wird in MOA SS eine Schlüsselgruppe definiert. Eine Schlüsselgruppe ist eine Zusammenfassung von einem oder mehreren privaten Schlüsseln, die in Hardware- bzw. Softwareschlüsselspeichern (vergleiche Abschnitte 2.2.1.1 bzw. 2.2.1.2) verwaltet werden. Die Schlüsselgruppe wird vom Kunden von MOA SS über einen eindeutigen Bezeichner im Request zur Signaturerstellung angesprochen.

    -

    Sinn der Zusammenfassung von mehreren privaten Schlüsseln zu einer Schlüsselgruppe ist +

    Sinn der Zusammenfassung von mehreren privaten Schlüsseln zu einer Schlüsselgruppe ist es, dass MOA SS selbst entscheidet, welcher konkrete Schlüssel aus der Schlüsselgruppe zur Erstellung der Signatur verwendet wird. Durch die somit mögliche Parallelisierung (mehrere private Schlüssel werden parallel für Anfragen, die auf die gleiche Schlüsselgruppe - referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern.

    + referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern.

    Das Element cfg:SignatureCreation/cfg:KeyGroup hat folgenden Element-Inhalt:

    • +
  • Element cfg:DigestMethodAlgorithm: Dieses optionale Element spezifiert einen Digest-Algorithmus, der für das Erstellen von XML-Signaturen mittels dieser Schlüsselgruppe verwendet werden soll. Der Default-Wert bzw. ein allfällig in Abschnitt "Parameter für XML-Signaturen" definierter Wert, werden dadurch für diese Schlüsselgruppe überschrieben. Mögliche Werte sind dem Element cfg:SignatureCreation/cfg:XMLDSig/cfg:DigestMethodAlgorithm ebenfalls in Abschnitt "Parameter für XML-Signaturen" zu entnehmen.

    • Um auf einfache Weise für alle in Ihren Schlüsselspeichern enthaltenen privaten Schlüssel die jeweiligen Werte für dsig:X509IssuerName und dsig:X509SerialNumber zu - erhalten, gehen Sie am besten wie folgt vor:

    +

    1. Erfassen Sie in der zentralen Konfigurationsdatei alle Ihre Schlüsselspeicher mit Hilfe der Konfigurationselemente cfg:SignatureCreation/cfg:KeyModules/cfg:HardwareKeyModule bzw. cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule.
      2. @@ -466,7 +499,8 @@ IssuerDN (RFC2253) : Erläuterung -

      Als Inhalt des Elements kann der Kanonisierungs-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:

      +

      TODO: Kanonisierungs-Algorithmen entsprechend Kommissionsentscheidung?

      +

      Als Inhalt des Elements kann der Kanonisierungs-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:

      http://www.w3.org/TR/2001/REC-xml-c14n-20010315 
      http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments 
      http://www.w3.org/2001/10/xml-exc-c14n# 
      http://www.w3.org/2001/10/xml-exc-c14n#WithComments

      Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:

      @@ -484,15 +518,16 @@ IssuerDN (RFC2253) : Erläuterung -

      TODO Update Beschreibung hinsichtlich XAdES 1.4.2

      -

      Als Inhalt des Elements kann der Digest-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:Reference/dsig:DigestMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:

      -

      - 

      http://www.w3.org/2000/09/xmldsig#sha1
-
      -

      -

      Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:

      -

      TODO Default-wert wenn XAdES 1.4.2?

      - 
      http://www.w3.org/2000/09/xmldsig#sha1

      Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.

      +

      Als Inhalt des Elements kann der Digest-Algorithmus, der für das Erstellen von XML-Signaturen verwendet werden soll und in der Signatur als Inhalt von dsig:Signature/dsig:SignedInfo/dsig:Reference/dsig:DigestMethod aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden: +

      + 
      http://www.w3.org/2000/09/xmldsig#sha1
+http://www.w3.org/2000/09/xmldsig#sha256
      http://www.w3.org/2000/09/xmldsig#sha384
      http://www.w3.org/2000/09/xmldsig#sha512
      + Wird das Element nicht angegeben, wird - abhängig von der konfigurierten XAdES-Version (siehe XAdES-Version)- folgender Wert als Default-Wert verwendet: +

      Für XAdES Version 1.1.1:

      + 
      http://www.w3.org/2000/09/xmldsig#sha1
      +

      Für XAdES Version 1.4.2:

      +
      http://www.w3.org/2000/09/xmldsig#sha256
      +

      Für die genaue Bedeutung der Werte siehe die Spezifikation für XML-Signaturen.

      2.2.5 Profil für Transformationen

      @@ -551,7 +586,7 @@ IssuerDN (RFC2253) : eingefügt werden soll, sowie allenfalls für die Verarbeitung des bestehenden XML-Dokuments notwendige Ergänzungsobjekte (z.B. ein XML-Schema für das validierende Parsen des bestehenden XML-Dokuments).

      -

      cfg:CreateSignatureEnvironmentProfile weist folgende obligatorische Kindelemene +

      cfg:CreateSignatureEnvironmentProfile weist folgende obligatorische Kindelemente auf:

      -

      TODO XAdES 1.4.2 Möglichkeit

      +

      2.2.7 XAdES Version

      + + + + + + + + + + + + + +
      Namecfg:SignatureCreation/cfg:XAdES
      GebrauchNull mal bis einmal
      Erläuterung

      MOA SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur (das Attribut SecurityLayerConformity im CreateXMLSignatureRequest ist auf false gesetzt) oder einer XAdES-Signatur (SecurityLayerConformity=true) gemäß der Security-Layer Spezifikation V1.1. Dieses Element gibt nun an welche XAdES-Version in diesem Fall eingesetzt werden soll. Bei Nichtvorhandensein des Elements wird die bisherige Standardversion XAdES 1.1.1 verwendet. Im folgenden Kindelement kann jedoch eine andere XAdES-Version konfiguriert werden. cfg:XAdES weist daher folgendes obligatorische Kindelement + auf:

      +
        +
      • Element Version: Dieses Element vom Typ xs:token gibt die zu verwendende XAdES-Version an. Derzeit kann nur die Version 1.4.2 angegeben werden.
        • +

      2.3 Parameter für MOA SP

      2.3.1 diff --git a/spss/handbook/handbook/install/install.html b/spss/handbook/handbook/install/install.html index 7c78969c3..57da2b55c 100644 --- a/spss/handbook/handbook/install/install.html +++ b/spss/handbook/handbook/install/install.html @@ -21,14 +21,14 @@

      Inhalt

      1. -

        Übersicht

        +

        Übersicht

      2. Webservice

        1. Basisinstallation
            -
          1. Einführung
            2. +
          2. Einführung
          3. Installation
            1. Vorbereitung
              2. @@ -105,12 +105,12 @@
            2. Referenzierte Software
            -

            1 Übersicht

            +

            1 Übersicht

            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 Installation der beiden Module als Webservice oder als Klassenbibliothek, sowie die Einrichtung der Systemumgebung.

            2 Webservice

            Dieser Abschnitt beschreibt die Installation von MOA SP/SS als Webservice. Im ersten Unterkapitel wird eine minimale Basisinstallation beschrieben. Das zweite Unterkapitel zeigt eine Reihe von optionalen Erweiterungsmöglichkeiten auf.

            2.1 Basisinstallation

            -

            2.1.1 Einführung

            +

            2.1.1 Einführung

            Die Basisinstallation des Webservices stellt einerseits die minimalen Anforderungen für den Betrieb von MOA SP/SS als Webservices dar, andererseits dient sie als Ausgangspunkt für optionale Erweiterungsmöglichkeiten.

            Die Mindestanforderungen für die Basisinstallation sind:

              @@ -142,11 +142,10 @@

              2.1.2.2 Konfiguration von Apache Tomcat

              -

              Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast enthält und viele Ports offen lässt.

              +

              Die zentrale Konfigurations-Datei von Tomcat ist $CATALINA_HOME/conf/server.xml. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert.

              2.1.2.2.1 Konfiguration des HTTP Connectors
              -

              TODO: server.xml auf 7 umstellen

              -

              Die Datei $MOA_SPSS_INST/tomcat/server.xml enthält eine minimale Tomcat-Konfiguration für Apache Tomcat 7, die ausschließlich den Connector für HTTP auf Port 8080 freischaltet. Durch Kopieren dieser Datei nach $CATALINA_HOME/conf/server.xml kann Tomcat mit dieser Konfiguration gestartet werden. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.

              -
              2.1.2.2.2 Konfiguration des HTTPS Connectors
              +

              Die Tomcat Default-Konfiguration schaltet ausschließlich den Connector für HTTP auf Port 8080 frei. Wir empfehlen diese Konfiguration nur für Fälle, in denen das MOA SP/SS Webservice in einer abgeschlossenen Netzwerkumgebung betrieben wird.

              +
              2.1.2.2.2 Konfiguration des HTTPS Connectors

              Wird das MOA SP/SS Webservice in einer nicht abgeschlossenen Umgebung (z.B. Erreichbarkeit über das Internet) betrieben, ist die gegenseitige Identitätsfeststellung von Kunde und Webservice essentiell:

              • Nutzt ein Kunde MOA SP, ist es für ihn wichtig, die Identität des Webservice eindeutig feststellen zu können, denn er vertraut dem Webservice ja die Prüfung einer elektronischen Signatur an.
                • @@ -306,11 +305,10 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null>
                2.2.1.1.1 Konfiguration von mod_jk im MS IIS

                Für die Kommunikation des MS IIS mit dem im Tomcat eingerichteten MOA SP/SS Webservice wird das ISAPI-Modul von mod_jk im MS IIS installiert und konfiguriert. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk IIS HowTo. Beispiele für workers.properties und uriworkermap.properties Dateien liegen im Verzeichnis $MOA_SPSS_INST/tomcat bei.

                2.2.1.1.2 Konfiguration von Tomcat
                -

                TODO: Update server.mod_jk.xml

                -

                Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels mod_jk weiterleitet werden, muss in $CATALINA_HOME/conf/server.xml der AJP 1.3 Connector aktiviert werden. Im Gegenzug können die Konnektoren für HTTP und HTTPS deaktiviert werden. Das geschieht am einfachsten durch Ein- bzw. Auskommentieren der entsprechenden Connector Konfigurations-Elemente in dieser Datei. Die Datei $MOA_SPSS_INST/tomcat/server.mod_jk.xml enthält eine Konfiguration, die ausschließlich den Port für den AJP 1.3 Connector offen lässt.

                +

                Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels mod_jk weiterleitet werden, muss in $CATALINA_HOME/conf/server.xml der AJP Connector aktiviert werden. Im Gegenzug können die Konnektoren für HTTP und HTTPS deaktiviert werden. Das geschieht am einfachsten durch Ein- bzw. Auskommentieren der entsprechenden Connector Konfigurations-Elemente in dieser Datei.

                2.2.1.1.3 Konfiguration von SSL

                Die Dokumentation zum Einrichten von SSL auf dem MS IIS steht nach Installation des IIS unter http://localhost/iisHelp/ oder aber auch auf den Webseiten von Mircrosoft zur Verfügung.

                -

                2.2.1.2 Apache

                +

                2.2.1.2 Apache

                Den MOA SP/SS Webservices kann ein Apache Webserver vorgeschaltet sein. Das Prinzip funktioniert wie bei MS IIS, auch hier wird mod_jk für die Kommunikation zwischen Webserver und Tomcat eingesetzt. Die angeführten Konfigurationsschritte gehen von einer Standard-Installation des Apache Webservers aus.

                2.2.1.2.1 Konfiguration von mod_jk im Apache

                Um das MOA-SPSS Webservice hinter einem Apache Webserver zu betreiben, ist die Konfiguration des Apache-Moduls mod_jk erforderlich. Eine detaillierte Installations- und Konfigurationsanleitung gibt das mod_jk Apache HowTo. Ein Beispiel für eine workers.properties Datei liegt im Verzeichnis $MOA_SPSS_INST/tomcat bei.

                diff --git a/spss/handbook/handbook/usage/usage.html b/spss/handbook/handbook/usage/usage.html index 1ac817a45..bafb6da29 100644 --- a/spss/handbook/handbook/usage/usage.html +++ b/spss/handbook/handbook/usage/usage.html @@ -27,19 +27,27 @@

                Verwendung des Webservices

                1. XML-Requests
                    -
                  1. Erstellung einer XML-Signatur
                      +
                    1. Erstellung einer CMS bzw. CAdES-Signatur
                      2. +
                        +
                      1. Einfaches Beispiel
                        2. +
                      2. Erweitertes Beispiel
                        3. +
                      +
                    2. Erstellung einer XML bzw. XAdES-Signatur +
                      1. Einfaches Beispiel
                      2. Angabe der zu signierenden Daten
                      3. Transformationen
                      4. Ergänzungsobjekte
                        5. -
                      +
                    2. -
                  2. Prüfung einer CMS-Signatur
                      +
                    1. Prüfung einer CMS bzw. CAdES-Signatur +
                      1. Einfaches Beispiel
                      2. Erweitertes Beispiel
                      2. -
                    2. Prüfung einer XML-Signatur
                        +
                      1. Prüfung einer XML bzw. XAdES-Signatur +
                        1. Einfaches Beispiel
                        2. Erweitertes Beispiel
                        3. Prüfung eines XMLDSIG-Manifests
                          4. @@ -79,21 +87,28 @@

                          2.1 XML-Requests

                          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.

                          Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf localhost, z.B. http://localhost:8080/referencedData/Text.txt. Wenn Sie diese Beispiele ausprobieren möchten, müssen Sie dafür sorgen, dass MOA SS bzw. SP diese Daten auch tatsächlich auflösen kann. Wenn Sie Ihre Tomcat-Installation auf localhost:8080 betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation referencedData.war in das Verzeichnis webapps Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen.

                          -

                           

                          -

                          TODO Erstellung einer CMS/CAdES Signatur

                          -

                          2.1.1 Erstellung einer XML-Signatur

                          -

                          2.1.1.1 Einfaches Beispiel

                          +

                          2.1.1 Erstellung einer CMS bzw. CAdES-Signatur

                          +

                          2.1.1.1 Einfaches Beispiel

                          +

                          TODO

                          + +

                          2.1.1.1 Erweitertes Beispiel

                          + +

                          TODO

                          +

                          2.1.2 Erstellung einer XML bzw. XAdES-Signatur

                          +

                          MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der Security-Layer Spezifikation V1.1. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute SecurityLayerConformity im Signaturerstelltungs-Request (siehe auch folgende Beispiele).

                          +

                          Im Falle einer XAdES-Signatur, kann entweder eine XAdES-Signatur in der Version 1.1.1 oder in der Version 1.4.2 erstellt werden. Dies hängt von der in der MOA-SS Konfiguration angegeben XAdES-Version ab (siehe hierzu Konfiguration der XAdES Version).

                          +

                          2.1.2.1 Einfaches Beispiel

                          Request

                          CreateXMLSignatureRequest.Simple.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">
+  
                           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 (=eine XAdES Signatur).
                          
+
                              <DataObjectInfo Structure="enveloping">
       <DataObject>
         <XMLContent>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). 
                          
@@ -122,7 +137,7 @@
     </dsig:Signature>
                            </SignatureEnvironment>
                          </CreateXMLSignatureResponse>

                          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.

                          -

                          2.1.1.2 Angabe der zu signierenden Daten

                          +

                          2.1.2.2 Angabe der zu signierenden Daten

                          Request

                          Dieses Beispiel stellt die vielfältigen Möglichkeiten vor, wie MOA SS mitgeteilt werden kann, welche Daten signiert (wenn keine Transformationen angegeben werden) bzw. als Eingangsdaten für die Berechnung der Transformationen verwendet werden sollen (wenn Transformationen angegeben werden).

                          Mit CreateXMLSignatureRequest.Refs.xml sollen insgesamt neun Datenobjekte signiert werden:

                          @@ -420,7 +435,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </dsig:Object>

                          Das fünfte dsig:Object enthält das dsig:Manifest, das von MOA SS auf Grund des ersten bzw. fünften DataObjectInfo des Requests erstellt wurde. Darin enthalten sind die zum ersten und fünten DataObjectInfo korrespondierenden dsig:Reference Elemente. Die Daten für die erste im dsig:Manifest enthaltene dsig:Reference wurden aus dem Base64Content Element des ersten DataObjectInfo entnommen, jene für die zweite dsig:Reference aus dem Base64Content Element des fünften DataObjectInfo. Der Wert des URI Attributs der zweiten dsig:Reference wurde aus dem DataObject/@Reference des fünften DataObjectInfo übernommen.

                          -

                          2.1.1.3 Transformationen

                          +

                          2.1.2.3 Transformationen

                          Request

                          Dieses Beispiel (CreateXMLSignatureRequest.Transforms.xml) stellt die wichtigsten Transformationen vor, die von MOA SS bei der Erstellung einer Signatur verwendet werden können. Eine Transformation bzw. eine Kette mehrerer hintereinandergeschalteter Transformationen werden auf die Referenz-Eingangsdaten (also jene Daten, die in DataObjectInfo/DataObject angegeben werden) angewendet; das Ergebnis fließt dann in die Hashwert-Berechnung ein. 

                          <CreateXMLSignatureRequest
@@ -536,7 +551,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
         </dsig:Reference>

                          Die zweite dsig:Reference wurde auf Grund des zweiten DataObjectInfo im Request erstellt. Man erkennt auch hier gut, dass die URL auf die Referenz-Eingangsdaten (Wert des Attributs dsig:Reference/@URI) aus DataObject/@Reference übernommen und die drei Transformationen wie im Request angegeben eingefügt wurden.

                          -

                          2.1.1.4 Ergänzungsobjekte

                          +

                          2.1.2.4 Ergänzungsobjekte

                          Request

                          Dieses Beispiel (CreateXMLSignatureRequest.Supplements.xml) stellt die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem DataObject) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit CreateSignatureEnvironment). Es muss dann angegeben werden, wenn in einem zu signierenden Datum bzw. im Einfügedokument auf Daten per Referenz verwiesen wird, diese referenzierten Daten aber von MOA SS nicht aufgelöst werden können. Das Ergänzungsobjekt enthält dann genau diese Daten, die nicht von MOA SS aufgelöst werden können.

                          @@ -602,8 +617,8 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
                          Auch für das Auflösen eines Verweises in einer DTD kann in analoger Weise von Ergänzungsobjekten Gebrauch gemacht werden. 
                          
 
                          Response
                          
 
                          CreateXMLSignatureRequest.Supplements.resp.xml ist eine typische Response des SS Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
                          
-
                          2.1.2 Prüfung einer CMS-Signatur
                          
-
                          2.1.2.1 Einfaches Beispiel
                          
+
                          2.1.3 Prüfung einer CMS bzw. CAdES-Signatur
                          
+
                          2.1.3.1 Einfaches Beispiel
                          
 
                          Request
                          
 
                          Dieses Beispiel (VerifyCMSSignatureRequest.Simple.xml) ist ein einfacher Request zur Prüfung einer CMS-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der nachfolgende Ausschnitt aus dem Request aus Gründen der Übersichtlichkeit gekürzt wurde.
                          
 
                          @@ -650,7 +665,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
   </CertificateCheck>
 
                          
 
                          Abschließend enthält die Response mit CertificateCheck/Code das Resultat der Prüfung des Signatorzertifikats. Zunächst prüft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugehörigen Vertrauensprofil konfigurierten sog. Trust Anchor gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält Code den Wert 1, d. h. MOA SP konnte die oben erläuterte Zertifikatskette nicht bilden. Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
                          
-
                          2.1.2.2 Erweitertes Beispiel
                          
+
                          2.1.3.2 Erweitertes Beispiel
                          
 
                          Request
                          
 
                          Dieses erweiterte Beispiel zur Prüfung einer CMS-Signatur (VerifyCMSSignatureRequest.Extended.xml) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer Detached Signature, d. h. einer Signatur, in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. 
                          
 
                          @@ -672,8 +687,8 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
 
                          Das optionale Element DataObject muss dann angegeben werden, wenn eine Detached Signature geprüft werden soll, d. h. wenn in der CMS-Signatur die signierten Daten nicht mitkodiert sind. In DataObject/Content/Base64Content sind in einem solchen Fall diese Daten in base64 kodierter Form bereit zu stellen.
                          
 
                          Response
                          
 
                          VerifyCMSSignatureRequest.Extended.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
                          
-
                          2.1.3 Prüfen einer XML-Signatur
                          
-
                          2.1.3.1 Einfaches Beispiel
                          
+
                          2.1.4 Prüfen einer XML-Signatur
                          
+
                          2.1.4.1 Einfaches Beispiel
                          
 
                          Request
                          
 
                          VerifyXMLSignatureRequest.Simple.xml ist ein einfacher XML-Request zur Prüfung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
                          
 
                          @@ -748,7 +763,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT<
   </CertificateCheck>
 
                          
 
                          Abschließend enthält die Response mit CertificateCheck/Code das Resultat der Prüfung des Signatorzertifikats. Zunächst prüft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugehörigen Vertrauensprofil konfigurierten sog. Trust Anchor gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält Code den Wert 0, d. h. MOA SP konnte die Kette bilden, und alle Zertifikate der Kette sind gültig. Für eine Übersicht der möglichen Kodes siehe Security-Layer 1.2.
                          
-
                          2.1.3.2 Erweitertes Beispiel 
                          
+
                          2.1.4.2 Erweitertes Beispiel 
                          
 
                          Request
                          
 
                          Dieses erweiterte Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.Enveloped.xml) demonstriert die Prüfung einer Enveloped Signature, d. h. einer Signatur, die in ein XML-Dokument integriert ist, die Angabe des Prüfzeitpunkts sowie die Anweisung an MOA SP, in der Response die von der Signatur abgedeckten Daten zu retournieren.
                          
 
                          @@ -816,7 +831,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife
 </VerifyXMLSignatureResponse>
 
                          
 
                          Die Elemente SignatureCheck und CertificateCheck enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe Einfaches Beispiel).
                          
-
                          2.1.3.3 Prüfung eines XMLDSIG-Manifests 
                          
+
                          2.1.4.3 Prüfung eines XMLDSIG-Manifests 
                          
 
                          Request
                          
 
                          Dieses  Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.XMLDSigManifest.xml) demonstriert die Prüfung eines in der  XML-Signatur vorhandenden Manifests nach XMLDSig. Bitte beachten Sie, dass  der  dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
                          
 
                          @@ -892,7 +907,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende dsig:Manife
 </VerifyXMLSignatureResponse>
 
                          
 
                          Das Element CertificateCheck enthält das Resultat der Zertifikatsprüfung (siehe Einfaches Beispiel).
                          
-
                          2.3.1.4 Ergänzungsobjekte 
                          
+
                          2.1.4.4 Ergänzungsobjekte 
                          
 
                          Dieses Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.Supplements.xml) demonstriert die Verwendung von Ergänzungsobjekten. Ein Ergänzungsobjekt betrifft entweder ein signiertes Datum (Zusammenhang mit einem dsig:Reference der XML-Signatur) oder jenes Dokument, in dem sich die zu prüfende XML-Signatur befindet (Zusammenhang mit VerifySignatureEnvironment). Es muss dann angegeben werden, wenn auf ein signiertes Datum bzw. in einem signierten Datum bzw. in dem die XML-Signatur enthaltenden XML-Dokument auf weitere Daten  per Referenz verwiesen wird, diese Referenz aber von MOA SP nicht aufgelöst werden kann. Das Ergänzungsobjekt enthält dann genau diese Daten die nicht von MOA SS aufgelöst werden können.
                          
 
                          Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.
                          
 
                          @@ -960,7 +975,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
                          Das zweite Element SupplementProfile enthält analog das Ergänzungsobjekt für das oben beschriebene XML-Schema. Content/@Reference enthält die Referenz genau so, wie sie oben im Attribut xsi:schemaLocation angegeben wurde. 
                          
 
                          Response
                          
 
                          VerifyXMLSignatureRequest.Supplements.resp.xml ist eine typische Response des SP Webservices auf den obigen Request. Er wird an dieser Stelle nicht näher analysiert, da er keine für das Thema des Beispiels relevanten Besonderheiten aufweist.
                          
-
                          2.1.3.5 Signatur-Manifest des Security-Layers 
                          
+
                          2.1.4.5 Signatur-Manifest des Security-Layers 
                          
 
                          Request
                          
 
                          Dieses Beispiel zur Prüfung einer XML-Signatur (VerifyXMLSignatureRequest.SigManifest.xml) demonstriert die Überprüfung des Zusammenhangs zwischen den Referenz-Eingangsdaten und den Hash-Eingangsdaten für die dsig:Reference-Elemente einer XML-Signatur. Mit Hilfe dieser Prüfung kann eine Anwendung feststellen, ob bei der Erstellung einer XML-Signatur jene Transformationen bzw. auch jene inkludierten Stylesheets (vgl. Implizite Transformationsparameter) einer XSLT-Transformation angewendet wurden, welche die Anwendung vorgegeben hat. Bei erfolgreicher Prüfung dieses Zusammenhangs kann die Anwendung die Referenz-Eingangsdaten einer dsig:Reference als gesichert ansehen, obwohl eigentlich die Hash-Eingangsdaten durch die Signatur gesichert sind. Dies ist jenen Fällen sinnvoll, in denen die Anwendung grundsätzlich mit XML-Daten arbeitet, diese Daten jedoch für das Signieren durch eine Person in ein für diese Person verständliches Format wie z.B. HTML umgewandelt werden sollen.
                          
 
                          @@ -1139,28 +1154,23 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
 
                          2.2.2 Gemeinsamkeiten
                          
 
                          Dieser Abschnitt beschreibt die Gemeinsamkeiten aller drei Varianten des Webservice-Clients. 
                          
 
                          Zunächst einmal benötigen alle drei Varianten die folgenden Java-Bibliotheken, die im Ordner clients/webservice/lib/ dieses Handbuchs bereits enthalten sind:
                          
-
                          TODO Update Versions
                          
-
                          TODO kein lib Verzeichnis
                          
 
-    
-      
-      
+    
+      
+      
+    
-      
+      
-      
-    
-    
-      
-      
+      
                          
   
     
                          
       Java-Bibliothek
       Bemerkung
                          J2SE J2SE 1.3.1 SDK oder J2SE 1.4.2 SDK oder J2SE 5.0 SDK. 
     
                          Java SEJava Standard Edition (Software Development Kit bzw. Java Runtime Environment) 
                          
     
                          
       Apache XercesXML-Parser, Version 2.0.2 oder höher; nicht nötig wenn JDSE 1.4.2 oder höher verwendet wird. XML-Parser, Version 2.0.2 oder höher
     
                          
     
                          
       AXIS FrameworkWebservice-Framework, Version 1.1.
                          JSSEJava Secure Socket Extension, Version 1.0.3 oder höher; nur notwendig für die Varianten HTTPServerAuth und HTTPClientAuth.Webservice-Framework, ab Version 1.1.
     
                          
                             
 
                          
@@ -1178,13 +1188,13 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>
   
                        4. Der zweite Kommandozeilenparameter enthält Pfad und Dateiname einer Java-Properties-Datei, die die weiteren Konfigurationsparameter für den Webservice-Client enthält. Ein relativer Pfad wird als relativ zum Arbeitsverzeichnis der Java Virtual Machine interpretiert. Genaue Infos zu den möglichen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation der jeweiligen Variante des Webservice-Clients. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.
                          5.

                        2.2.3 Besonderheiten von HTTPSServerAuth.java

                        -

                        Diese Variante des Webservice-Clients verwendet JSSE, um im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server-Authentifizierung zum MOA SP/SS Server aufzubauen. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.

                        -

                        Die Konfiguration von JSSE (Speicher für die vertrauenswürdigen Serverzertifikate, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSServerAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.

                        -

                        Falls Sie Probleme beim SSL-Verbindungsaufbau zwischen Webservice-Client und MOA SP/SS Webservice haben, empfiehlt sich die Aktivierung des JSSE Loggings. Das Setzen der dafür notwendigen Java System Property ist im Quellcode von HTTPSServerAuth.java bereits enthalten, jedoch auskommentiert. Suchen Sie einfach nach dem String javax.net.debug, um zur entsprechenden Stelle im Quellcode zu gelangen.

                        +

                        Diese Variante des Webservice-Clients baut im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server-Authentifizierung zum MOA SP/SS Server auf. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.

                        +

                        Die entsprechende Konfiguration (Speicher für die vertrauenswürdigen Serverzertifikate, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSServerAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.

                        +

                        Falls Sie Probleme beim SSL-Verbindungsaufbau zwischen Webservice-Client und MOA SP/SS Webservice haben, empfiehlt sich die Aktivierung des SSL Loggings. Das Setzen der dafür notwendigen Java System Property ist im Quellcode von HTTPSServerAuth.java bereits enthalten, jedoch auskommentiert. Suchen Sie einfach nach dem String javax.net.debug, um zur entsprechenden Stelle im Quellcode zu gelangen.

                        2.2.4 Besonderheiten von HTTPSClientAuth.java

                        -

                        Diese Variante des Webservice-Clients verwendet JSSE, um im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server- und Client-Authentifizierung zum MOA SP/SS Server aufzubauen. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.

                        -

                        Die gegenüber Abschnitt 2.2.3 zusätzlich notwendige Konfiguration von JSSE (Speicher für das SSL-Client-Zertifikat sowie den dazugehörigen privaten Schlüssel, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSClientAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.

                        -

                        Beachten Sie bitte auch den Hinweis zum JSSE Logging aus Abschnitt 2.2.3.

                        +

                        Diese Variante des Webservice-Clients baut im Schritt 3 des Kernablaufs aus Abschnitt 2.2.2 eine SSL-Verbindung mit Server- und Client-Authentifizierung zum MOA SP/SS Server auf. In dieser SSL-Verbindung sendet der Webservice-Client dann den erstellten SOAP-Request über HTTPS.

                        +

                        Die gegenüber Abschnitt 2.2.3 zusätzlich notwendige Konfiguration (Speicher für das SSL-Client-Zertifikat sowie den dazugehörigen privaten Schlüssel, Typ dieses Speichers, Passwort für diesen Speicher) wird mittels zusätzlicher Parameter in der in Abschnitt 2.2.2 besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von HTTPSClientAuth.java. http.properties enthält eine auf dieses Handbuch abgestimmte Konfiguration.

                        +

                        Beachten Sie bitte auch den Hinweis zum SSL Logging aus Abschnitt 2.2.3.

                        3 Verwendung der Klassenbibliothek

                        Neben dem Betrieb von MOA SP/SS als Webservice ist als Alternative auch die Verwendung von MOA SP/SS als Klassenbibliothek möglich, also die direkte Einbindung in ein Java-Programm unter Verwendung des Application Programmers Interface (API) von MOA SP/SS.

                        3.1 Vorbereitung

                        @@ -1205,7 +1215,6 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph>

                        A Referenzierte Software

                        Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:

                        -

                        TODO Update Versions

                        @@ -1217,21 +1226,13 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> - + - - - - - - - - - - - + + +
                        XML-Parser aus dem Apache Project
                        Apache AxisApache Axis Webservice-Framework aus dem Apache Project
                        J2SE 1.4.2 SDK/JREJava 2 Standard Edition in der Version 1.4.2 (Software Development Kit bzw. Java Runtime Environment)
                        J2SE 5.0 SDK/JRE Java 2 Standard Edition in der Version 5.0 (Software Development Kit bzw. Java Runtime Environment)
                        JSSEJava Secure Socket Extension
                        Java SEJava Standard Edition (Software Development Kit bzw. Java Runtime Environment)

                         

                        diff --git a/spss/server/serverlib/resources/data/deploy/tomcat/server.mod_jk.xml b/spss/server/serverlib/resources/data/deploy/tomcat/server.mod_jk.xml deleted file mode 100644 index e6035b8be..000000000 --- a/spss/server/serverlib/resources/data/deploy/tomcat/server.mod_jk.xml +++ /dev/null @@ -1,166 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - diff --git a/spss/server/serverlib/resources/data/deploy/tomcat/server.xml b/spss/server/serverlib/resources/data/deploy/tomcat/server.xml deleted file mode 100644 index 3e5966ca9..000000000 --- a/spss/server/serverlib/resources/data/deploy/tomcat/server.xml +++ /dev/null @@ -1,169 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -- cgit v1.2.3