diff options
| author | Klaus Stranacher <kstranacher@iaik.tugraz.at> | 2013-04-24 16:46:35 +0200 |
|---|---|---|
| committer | Klaus Stranacher <kstranacher@iaik.tugraz.at> | 2013-04-24 16:46:35 +0200 |
| commit | 76ee7b768603988e4a6ca59011eee2b7dd33fa21 (patch) | |
| tree | 116ed802151f2acf100987eac3c00eef627202c5 | |
| parent | 0d6ea7472c4a76deb68687dbc601337b93bf8e8f (diff) | |
| download | moa-id-spss-76ee7b768603988e4a6ca59011eee2b7dd33fa21.tar.gz moa-id-spss-76ee7b768603988e4a6ca59011eee2b7dd33fa21.tar.bz2 moa-id-spss-76ee7b768603988e4a6ca59011eee2b7dd33fa21.zip | |
Update Dokumentation
| -rw-r--r-- | spss/handbook/handbook/config/config.html | 105 | ||||
| -rw-r--r-- | spss/handbook/handbook/install/install.html | 20 | ||||
| -rw-r--r-- | spss/handbook/handbook/usage/usage.html | 107 | ||||
| -rw-r--r-- | spss/server/serverlib/resources/data/deploy/tomcat/server.mod_jk.xml | 166 | ||||
| -rw-r--r-- | spss/server/serverlib/resources/data/deploy/tomcat/server.xml | 169 |
5 files changed, 142 insertions, 425 deletions
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 @@ <ol> <li><a href="#konfigurationsparameter_allgemein">Allgemeines Parameter</a> <ol> <li><a href="#konfigurationsparameter_allgemein_hardwarecryptomodule">Hardwarebasiertes Kryptographiemodul</a></li> - <li><a href="#konfigurationsparameter_allgemein_permitexternaluris">Auflösen externer URIs</a></li> - </ol> + <li><a href="#konfigurationsparameter_allgemein_externaluris">Auflösen externer URIs</a> + <ol> + <li><a href="#konfigurationsparameter_allgemein_externaluris_blacklisting">Blacklisting</a></li> + <li><a href="#konfigurationsparameter_allgemein_externaluris_whitelisting">Whitelisting</a></li> + </ol> + </li> + </ol> </li> <li><a href="#konfigurationsparameter_ss">Parameter für MOA SS</a> <ol> <li><a href="#konfigurationsparameter_ss_keymodules">Schlüsselspeicher</a> <ol> @@ -61,6 +66,7 @@ <li><a href="#konfigurationsparameter_ss_xmldsig">Parameter für XML-Signaturen</a> </li> <li><a href="#konfigurationsparameter_ss_createtransformsinfoprofile">Profil für Transformationen</a></li> <li><a href="#konfigurationsparameter_ss_createsignatureenvironmentprofile">Profil für Signaturumgebung </a></li> + <li><a href="#konfigurationsparameter_ss_xades">XAdES Version</a></li> </ol> </li> <li><a href="#konfigurationsparameter_sp">Parameter für MOA SP</a> <ol> @@ -108,14 +114,13 @@ </ol> </li> </ol> - <hr/> +<hr/> <h1><a name="übersicht" id="übersicht"></a>1 Übersicht </h1> <p>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.</p> <h2><a name="übersicht_allgemeines" id="übersicht_allgemeines"></a>1.1 Allgemeines</h2> <h3><a name="übersicht_allgemeines_namenskonventionen" id="übersicht_allgemeines_namenskonventionen"></a>1.1.1 Namenskonventionen </h3> <p>Folgende Namenraum-Präfixe werden in diesem Handbuch zur Kennzeichnung der Namenräume - von XML-Elementen verwendet: </p> - <p>TODO Weitere Namespaces? Aktuell?</p> + von XML-Elementen verwendet: </p> <table class="fixedWidth" border="1" cellpadding="2"> <tr> <th scope="col">Präfix</th> @@ -130,7 +135,7 @@ <td><code>http://www.w3.org/2000/09/xmldsig#</code></td> </tr> <tr> - <td>moa</td> + <td><code>moa</code></td> <td><code>http://reference.e-government.gv.at/namespace/moa/20020822#</code></td> </tr> <tr> @@ -213,8 +218,14 @@ </tr> </table> - <h3><a name="konfigurationsparameter_allgemein_permitexternaluris" id="konfigurationsparameter_allgemein_permitexternaluris"></a>2.1.2 Auflösen externer URIs</h3> - <p>TODO Update Whitelisting</p> + <h3><a name="konfigurationsparameter_allgemein_externaluris" id="konfigurationsparameter_allgemein_externaluris"></a>2.1.2 Auflösen externer URIs</h3> + <p>Standardmäßig ist das Auflösen von externen URIs (inkl. localhost) deaktiviert (d.h. keines der nachfolgenden Konfigurationselement <code>cfg:PermitExternalUris</code> bzw. <code>cfg:ForbidExternalUris</code> existiert). Es gibt jedoch zwei Möglichkeiten das Auflösen zu aktivieren bzw. zu </p> + <ul> + <li>Blacklisting: Hierbei wird das Auflösen von externen URIs erlaubt. Es kann jedoch durch die Angaben einer Blacklist der Zugriff auf bestimmte URIs eingeschränkt werden.</li> + <li>Whitelisting: Hierbei ist das Auflösen von externen URIs weiterhin verboten. Es kann jedoch durch die Angabe einer Whitelist der Zugriff auf bestimmte URIs gestattet werden.</li> +</ul> +<p>Diese beiden Möglichkeiten stehen wahlweise zur Verfügung, d.h. es kann entweder Blacklisting oder Whitelisting konfiguriert werden.</p> +<h4><a name="konfigurationsparameter_allgemein_externaluris_blacklisting" id="konfigurationsparameter_allgemein_externaluris_blacklisting"></a>2.1.2.1 Blacklisting</h4> <table class="fixedWidth" border="1" cellpadding="2"> <tr> <td>Name</td> @@ -226,7 +237,7 @@ </tr> <tr> <td>Erläuterung</td> - <td><p>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:</p> + <td><p>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:</p> <ul> <li>Element <code>cfg:BlackListUri</code>: Dieses optionale und unbegrenzten Element gibt einen Blacklist-Eintrag an und besteht aus folgenden zwei weiteren Kindelementen:</li> <ul> @@ -245,6 +256,28 @@ </tr> </table> + <h4><a name="konfigurationsparameter_allgemein_externaluris_whitelisting" id="konfigurationsparameter_allgemein_externaluris_whitelisting"></a>2.1.2.2 Whitelisting</h4> +<table class="fixedWidth" border="1" cellpadding="2"> + <tr> + <td>Name</td> + <td><code>cfg:Common/cfg:ForbidExternalUris</code></td> + </tr> + <tr> + <td> Gebrauch</td> + <td>Null mal bis einmal </td> + </tr> + <tr> + <td>Erläuterung</td> + <td><p>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:</p> + <ul> + <li>Element <code>cfg:WhiteListUri</code>: Dieses optionale und unbegrenzten Element gibt einen Whitelist-Eintrag an und besteht aus folgenden zwei weiteren Kindelementen:</li> + <ul> + <li>Element <code>cfg:IP</code>: Dieses Element vom Type <code>xs:string</code> 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)</li> + <li>Element <code>cfg:Port</code>: Dieses optionale Element vom Typ <code>xs:int</code> 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.</li> + </ul> + </ul></td> + </tr> +</table> <h2><a name="konfigurationsparameter_ss" id="konfigurationsparameter_ss"></a>2.2 Parameter für MOA SS</h2> <h3><a name="konfigurationsparameter_ss_keymodules" id="konfigurationsparameter_ss_keymodules"></a>2.2.1 Schlüsselspeicher</h3> <h4><a name="konfigurationsparameter_ss_keymodules_hardwarekeymodule" id="konfigurationsparameter_ss_keymodules_hardwarekeymodule"></a>2.2.1.1 Hardware-Schlüsselspeicher</h4> @@ -327,17 +360,16 @@ </tr> <tr> <td>Erläuterung</td> - <td><p>TODO Update DigestMethod</p> - <p>Mit diesem Element wird in MOA SS eine Schlüsselgruppe definiert. Eine Schlüsselgruppe + <td><p>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 <a href="#konfigurationsparameter_ss_keymodules_hardwarekeymodule">2.2.1.1</a> bzw. <a href="#konfigurationsparameter_ss_keymodules_softwarekeymodule">2.2.1.2</a>) verwaltet werden. Die Schlüsselgruppe wird vom Kunden von MOA SS über einen eindeutigen Bezeichner im Request zur Signaturerstellung angesprochen. </p> - <p>Sinn der Zusammenfassung von mehreren privaten Schlüsseln zu einer Schlüsselgruppe ist +<p>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. </p> + referenzieren) lässt sich der Durchsatz der erstellten Signaturen verbessern. </p> <p>Das Element <code>cfg:SignatureCreation/cfg:KeyGroup</code> hat folgenden Element-Inhalt:</p> <ul> <li>Element <code>cfg:Id</code>: Dieses obligatorische Element vom Typ <code>xs:token</code> enthält @@ -370,10 +402,11 @@ </li> </ul> </li> + <li>Element <code>cfg:DigestMethodAlgorithm</code>: 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 "<a href="#konfigurationsparameter_ss_xmldsig">Parameter für XML-Signaturen</a>" definierter Wert, werden dadurch für diese Schlüsselgruppe überschrieben. Mögliche Werte sind dem Element <code>cfg:SignatureCreation/cfg:XMLDSig/cfg:DigestMethodAlgorithm</code> ebenfalls in Abschnitt "<a href="#konfigurationsparameter_ss_xmldsig">Parameter für XML-Signaturen</a>" zu entnehmen. </li> </ul> <p>Um auf einfache Weise für alle in Ihren Schlüsselspeichern enthaltenen privaten Schlüssel die jeweiligen Werte für <code>dsig:X509IssuerName</code> und <code>dsig:X509SerialNumber</code> zu - erhalten, gehen Sie am besten wie folgt vor:</p> +</p> <ol> <li>Erfassen Sie in der zentralen Konfigurationsdatei alle Ihre Schlüsselspeicher mit Hilfe der Konfigurationselemente <code>cfg:SignatureCreation/cfg:KeyModules/cfg:HardwareKeyModule</code> bzw. <code>cfg:SignatureCreation/cfg:KeyModules/cfg:SoftwareKeyModule</code>. </li> @@ -466,7 +499,8 @@ IssuerDN (RFC2253) : </tr> <tr> <td>Erläuterung</td> - <td><p> 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 <code>dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod</code> aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:</p> + <td><p>TODO: Kanonisierungs-Algorithmen entsprechend Kommissionsentscheidung?</p> + <p>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 <code>dsig:Signature/dsig:SignedInfo/dsig:CanonicalizationMethod</code> aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:</p> <p> <pre>http://www.w3.org/TR/2001/REC-xml-c14n-20010315 <br>http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments <br>http://www.w3.org/2001/10/xml-exc-c14n# <br>http://www.w3.org/2001/10/xml-exc-c14n#WithComments </pre> <p></p> <p>Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:</p> @@ -484,15 +518,16 @@ IssuerDN (RFC2253) : </tr> <tr> <td>Erläuterung</td> - <td><p>TODO Update Beschreibung hinsichtlich XAdES 1.4.2</p> - <p>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 <code>dsig:Signature/dsig:SignedInfo/dsig:Reference/dsig:DigestMethod</code> aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden:</p> - <p> - <pre>http://www.w3.org/2000/09/xmldsig#sha1 -</pre> - <p></p> - <p>Wird das Element nicht angegeben, wird folgender Wert als Default-Wert verwendet:</p> - <p>TODO Default-wert wenn XAdES 1.4.2?</p> - <pre>http://www.w3.org/2000/09/xmldsig#sha1</pre> <p>Für die genaue Bedeutung der Werte siehe die <a href="http://www.w3.org/TR/xmldsig-core/" target="_blank">Spezifikation für XML-Signaturen</a>.</p></td> + <td><p>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 <code>dsig:Signature/dsig:SignedInfo/dsig:Reference/dsig:DigestMethod</code> aufscheint, spezifiziert werden. Folgende Werte dürfen verwendet werden: +</p> + <pre>http://www.w3.org/2000/09/xmldsig#sha1 +http://www.w3.org/2000/09/xmldsig#sha256<br>http://www.w3.org/2000/09/xmldsig#sha384<br>http://www.w3.org/2000/09/xmldsig#sha512 </pre> + Wird das Element nicht angegeben, wird - abhängig von der konfigurierten XAdES-Version (siehe <a href="#konfigurationsparameter_ss_xades">XAdES-Version</a>)- folgender Wert als Default-Wert verwendet: + <p>Für XAdES Version 1.1.1:</p> + <pre>http://www.w3.org/2000/09/xmldsig#sha1</pre> + <p>Für XAdES Version 1.4.2:</p> +<pre>http://www.w3.org/2000/09/xmldsig#sha256</pre> +<p>Für die genaue Bedeutung der Werte siehe die <a href="http://www.w3.org/TR/xmldsig-core/" target="_blank">Spezifikation für XML-Signaturen</a>.</p></td> </tr> </table> <h3><a name="konfigurationsparameter_ss_createtransformsinfoprofile" id="konfigurationsparameter_ss_createtransformsinfoprofile"></a>2.2.5 Profil für Transformationen</h3> @@ -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).</p> - <p><code>cfg:</code><code>CreateSignatureEnvironmentProfile</code> weist folgende obligatorische Kindelemene + <p><code>cfg:</code><code>CreateSignatureEnvironmentProfile</code> weist folgende obligatorische Kindelemente auf: </p> <ul> <li>Element<code> Id</code>: Dieses Element<code></code> vom Typ <code>xs:token</code> enthält @@ -566,7 +601,25 @@ IssuerDN (RFC2253) : </ul></td> </tr> </table> - <p>TODO XAdES 1.4.2 Möglichkeit</p> + <h3><a name="konfigurationsparameter_ss_xades" id="konfigurationsparameter_ss_xades"></a>2.2.7 XAdES Version</h3> + <table class="fixedWidth" border="1" cellpadding="2"> + <tr> + <td>Name</td> + <td><code>cfg:SignatureCreation/cfg:XAdES</code></td> + </tr> + <tr> + <td>Gebrauch</td> + <td>Null mal bis einmal</td> + </tr> + <tr> + <td>Erläuterung</td> + <td><p>MOA SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur (das Attribut <code>SecurityLayerConformity</code> im <code>CreateXMLSignatureRequest</code> ist auf <code>false</code> gesetzt) oder einer XAdES-Signatur (<code>SecurityLayerConformity=true</code>) gemäß der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20020831/core/Core.html#signaturerstellungNachXMLDSIGAntwort" target="_blank">Security-Layer Spezifikation V1.1</a>. 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. <code>cfg:</code><code>XAdES</code> weist daher folgendes obligatorische Kindelement + auf: </p> + <ul> + <li>Element<code> Version</code>: Dieses Element<code></code> vom Typ <code>xs:token</code> gibt die zu verwendende XAdES-Version an. Derzeit kann nur die Version 1.4.2 angegeben werden.</li> + </ul></td> + </tr> + </table> <h2><a name="konfigurationsparameter_sp" id="konfigurationsparameter_sp"></a>2.3 Parameter für MOA SP </h2> <h3> <a name="konfigurationsparameter_sp_certificatevalidation" id="konfigurationsparameter_sp_certificatevalidation"></a>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 @@ <h1>Inhalt</h1> <ol> <li> - <p><a href="#Übersicht">Übersicht</a></p> + <p><a href="#uebersicht">Übersicht</a></p> </li> <li> <p><a href="#webservice">Webservice</a></p> <ol> <li><a href="#webservice_basisinstallation">Basisinstallation</a> <ol> - <li><a href="#webservice_basisinstallation_einführung">Einführung</a></li> + <li><a href="#webservice_basisinstallation_einfuehrung">Einführung</a></li> <li><a href="#webservice_basisinstallation_installation">Installation</a> <ol> <li><a href="#webservice_basisinstallation_installation_vorbereitung">Vorbereitung</a></li> @@ -105,12 +105,12 @@ <li><a href="#referenzierte_software">Referenzierte Software</a></li> </ol> <hr/> - <h1><a name="übersicht" id="übersicht"></a>1 Übersicht</h1> + <h1><a name="uebersicht" id="uebersicht"></a>1 Übersicht</h1> <p> 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.</p> <h1><a name="webservice"></a>2 Webservice </h1> <p>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.</p> <h2><a name="webservice_basisinstallation" id="webservice_basisinstallation"></a>2.1 Basisinstallation</h2> - <h3><a name="webservice_basisinstallation_einführung" id="webservice_basisinstallation_einführung"></a>2.1.1 Einführung </h3> + <h3><a name="webservice_basisinstallation_einfuehrung" id="webservice_basisinstallation_einfuehrung"></a>2.1.1 Einführung </h3> <p> 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 <a href="#webservice_erweiterungsmoeglichkeiten">Erweiterungsmöglichkeiten</a>.</p> <p>Die <strong>Mindestanforderungen</strong> für die Basisinstallation sind: </p> <ul> @@ -142,11 +142,10 @@ </dd> </dl> <h4><a name="webservice_basisinstallation_installation_tomcatconfig" id="webservice_basisinstallation_installation_tomcatconfig"></a>2.1.2.2 Konfiguration von Apache Tomcat</h4> - <p>Die zentrale Konfigurations-Datei von Tomcat ist <code>$CATALINA_HOME/conf/server.xml</code>. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast enthält und viele Ports offen lässt. </p> + <p>Die zentrale Konfigurations-Datei von Tomcat ist <code>$CATALINA_HOME/conf/server.xml</code>. Tomcat wird grundsätzlich mit einer funktionierenden Default-Konfiguration ausgeliefert. </p> <h5><a name="webservice_basisinstallation_installation_tomcatconfig_httpconn" id="webservice_basisinstallation_installation_tomcatconfig_httpconn"></a>2.1.2.2.1 Konfiguration des HTTP Connectors</h5> -<p><strong>TODO: server.xml auf 7 umstellen</strong></p> -<p> Die Datei <code>$MOA_SPSS_INST/tomcat/server.xml</code> 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 <code>$CATALINA_HOME/conf/server.xml</code> 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. </p> - <h5><a name="webservice_basisinstallation_installation_tomcatconfig_httpsconn" id="webservice_basisinstallation_installation_tomcatconfig_httpsconn"></a>2.1.2.2.2 Konfiguration des HTTPS Connectors</h5> +<p>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. </p> +<h5><a name="webservice_basisinstallation_installation_tomcatconfig_httpsconn" id="webservice_basisinstallation_installation_tomcatconfig_httpsconn"></a>2.1.2.2.2 Konfiguration des HTTPS Connectors</h5> <p>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: </p> <ul> <li> 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.</li> @@ -306,11 +305,10 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=<null> <h5><a name="webservice_erweiterungsmoeglichkeiten_webserver_iis_jk" id="webservice_erweiterungsmoeglichkeiten_webserver_iis_jk"></a>2.2.1.1.1 Konfiguration von <span class="term">mod_jk</span> im MS IIS</h5> <p> Für die Kommunikation des MS IIS mit dem im Tomcat eingerichteten MOA SP/SS Webservice wird das <span class="term">ISAPI</span>-Modul von <span class="term">mod_jk</span> im MS IIS installiert und konfiguriert. Eine detaillierte Installations- und Konfigurationsanleitung gibt das <span class="term"><a href="http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html" target="_blank">mod_jk</a></span><a href="http://tomcat.apache.org/connectors-doc/webserver_howto/iis.html" target="_blank"> IIS HowTo</a>. Beispiele für <code>workers.properties</code> und <code>uriworkermap.properties</code> Dateien liegen im Verzeichnis <code>$MOA_SPSS_INST/tomcat</code> bei.</p> <h5><a name="webservice_erweiterungsmoeglichkeiten_webserver_iis_tomcat" id="webservice_erweiterungsmoeglichkeiten_webserver_iis_tomcat"></a>2.2.1.1.2 Konfiguration von Tomcat</h5> - <p><strong>TODO: Update server.mod_jk.xml </strong></p> - <p>Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels <span class="term"> mod_jk</span> weiterleitet werden, muss in <code>$CATALINA_HOME/conf/server.xml</code> der <span class="term">AJP 1.3 Connector</span> 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 <code>Connector</code> Konfigurations-Elemente in dieser Datei. Die Datei <code>$MOA_SPSS_INST/tomcat/server.mod_jk.xml</code> enthält eine Konfiguration, die ausschließlich den Port für den <span class="term">AJP 1.3 Connector</span> offen lässt.</p> + <p>Damit Tomcat die Aufrufe entgegennehmen kann, die von MS IIS mittels <span class="term"> mod_jk</span> weiterleitet werden, muss in <code>$CATALINA_HOME/conf/server.xml</code> der <span class="term">AJP Connector</span> 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 <code>Connector</code> Konfigurations-Elemente in dieser Datei.</p> <h5><a name="webservice_erweiterungsmoeglichkeiten_webserver_iis_ssl" id="webservice_erweiterungsmoeglichkeiten_webserver_iis_ssl"></a>2.2.1.1.3 Konfiguration von SSL</h5> <p> 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. </p> - <h4><a name="webservice_erweiterungsmöglichkeiten_webserver_apache" id="webservice_erweiterungsmöglichkeiten_webserver_apache"></a>2.2.1.2 Apache</h4> + <h4><a name="webservice_erweiterungsmoeglichkeiten_webserver_apache" id="webservice_erweiterungsmoeglichkeiten_webserver_apache"></a>2.2.1.2 Apache</h4> <p>Den MOA SP/SS Webservices kann ein Apache Webserver vorgeschaltet sein. Das Prinzip funktioniert wie bei MS IIS, auch hier wird <span class="term"> mod_jk</span> für die Kommunikation zwischen Webserver und Tomcat eingesetzt. Die angeführten Konfigurationsschritte gehen von einer Standard-Installation des Apache Webservers aus.</p> <h5><a name="webservice_erweiterungsmoeglichkeiten_webserver_apache_jk" id="webservice_erweiterungsmoeglichkeiten_webserver_apache_jk"></a>2.2.1.2.1 Konfiguration von <span class="term"> mod_jk</span> im Apache </h5> <p>Um das MOA-SPSS Webservice hinter einem Apache Webserver zu betreiben, ist die Konfiguration des Apache-Moduls <span class="term">mod_jk</span> erforderlich. Eine detaillierte Installations- und Konfigurationsanleitung gibt das <span class="term"><a href="http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html" target="_blank">mod_jk</a></span><a href="http://tomcat.apache.org/connectors-doc/webserver_howto/apache.html" target="_blank"> Apache HowTo</a>. Ein Beispiel für eine <code>workers.properties</code> Datei liegt im Verzeichnis <code>$MOA_SPSS_INST/tomcat</code> bei.</p> 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 @@ <p><a href="#webservice">Verwendung des Webservices</a></p> <ol> <li><a href="#webservice_xmlrequests">XML-Requests</a> <ol> - <li><a href="#webservice_xmlrequests_erstellungxml">Erstellung einer XML-Signatur</a> <ol> + <li><a href="#webservice_xmlrequests_erstellungcms">Erstellung einer CMS bzw. CAdES-Signatur</a></li> + <ol> + <li><a href="#webservice_xmlrequests_erstellungcms_einfach">Einfaches Beispiel</a></li> + <li><a href="#webservice_xmlrequests_erstellungcms_erweitert">Erweitertes Beispiel</a></li> + </ol> + <li><a href="#webservice_xmlrequests_erstellungxml">Erstellung einer XML bzw. XAdES-Signatur</a> + <ol> <li><a href="#webservice_xmlrequests_erstellungxml_simple">Einfaches Beispiel</a></li> <li><a href="#webservice_xmlrequests_erstellungxml_daten">Angabe der zu signierenden Daten</a></li> <li><a href="#webservice_xmlrequests_erstellungxml_transformationen">Transformationen</a></li> <li><a href="#webservice_xmlrequests_erstellungxml_ergaenzungsobjekte">Ergänzungsobjekte</a> </li> - </ol> + </ol> </li> - <li><a href="#webservice_xmlrequests_pruefungcms">Prüfung einer CMS-Signatur </a> <ol> + <li><a href="#webservice_xmlrequests_pruefungcms">Prüfung einer CMS bzw. CAdES-Signatur </a> + <ol> <li><a href="#webservice_xmlrequests_pruefungcms_einfach">Einfaches Beispiel</a></li> <li><a href="#webservice_xmlrequests_pruefungcms_erweitert">Erweitertes Beispiel</a> </li> </ol> </li> - <li><a href="#webservice_xmlrequests_pruefungxml">Prüfung einer XML-Signatur </a> <ol> + <li><a href="#webservice_xmlrequests_pruefungxml">Prüfung einer XML bzw. XAdES-Signatur </a> + <ol> <li><a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a></li> <li><a href="#webservice_xmlrequests_pruefungxml_erweitert">Erweitertes Beispiel</a></li> <li><a href="#webservice_xmlrequests_pruefungxml_xmldsigmanifest">Prüfung eines XMLDSIG-Manifests</a></li> @@ -79,21 +87,28 @@ <h2><a name="webservice_xmlrequests" id="webservice_xmlrequests"></a>2.1 XML-Requests </h2> <p>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. </p> <p class="remark">Bitte beachten Sie: Einige der vorgestellten Requests referenzieren beispielhafte Daten auf <code>localhost</code>, z.B. <code>http://localhost:8080/referencedData/Text.txt</code>. 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 <code>localhost:8080</code> betreiben, ist es ausreichend, wenn sie die diesem Handbuch beiliegende Webapplikation <code><a href="../../clients/common/referencedData/referencedData.war">referencedData.war</a></code> in das Verzeichnis <code>webapps</code> Ihrer Tomcat-Installation kopieren. Ansonsten müssen Sie zusätzlich die URLs in den Requests anpassen. </p> - <p class="remark"> </p> - <p class="remark">TODO Erstellung einer CMS/CAdES Signatur</p> -<h3><a name="webservice_xmlrequests_erstellungxml" id="webservice_xmlrequests_erstellungxml"></a>2.1.1 Erstellung einer XML-Signatur</h3> - <h4><a name="webservice_xmlrequests_erstellungxml_simple" id="webservice_xmlrequests_erstellungxml_simple"></a>2.1.1.1 Einfaches Beispiel</h4> + <h3><a name="webservice_xmlrequests_erstellungcms" id="webservice_xmlrequests_erstellungcms"></a>2.1.1 Erstellung einer CMS bzw. CAdES-Signatur</h3> + <h4><a name="webservice_xmlrequests_erstellungcms_einfach" id="webservice_xmlrequests_erstellungcms_einfach"></a>2.1.1.1 Einfaches Beispiel</h4> + <p>TODO</p> + + <h4><a name="webservice_xmlrequests_erstellungcms_erweitert" id="webservice_xmlrequests_erstellungcms_erweitert"></a>2.1.1.1 Erweitertes Beispiel</h4> + +<p> TODO</p> +<h3><a name="webservice_xmlrequests_erstellungxml" id="webservice_xmlrequests_erstellungxml"></a>2.1.2 Erstellung einer XML bzw. XAdES-Signatur</h3> +<p>MOA-SS ermöglicht die Erstellung einer herkömmlichen XML-Signatur und einer XAdES-Signatur gemäß der <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20020831/core/Core.html#signaturerstellungNachXMLDSIGAntwort" target="_blank">Security-Layer Spezifikation V1.1</a>. Die Auswahl ob eine herkömmliche XML oder eine Security-Layer konforme XAdES-Signatur erstellt wird, erfolgt durch das Attribute <code>SecurityLayerConformity</code> im Signaturerstelltungs-Request (siehe auch folgende Beispiele). </p> +<p>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 <a href="../config/config.html#konfigurationsparameter_ss_xades">Konfiguration der XAdES Version</a>).</p> +<h4><a name="webservice_xmlrequests_erstellungxml_simple" id="webservice_xmlrequests_erstellungxml_simple"></a>2.1.2.1 Einfaches Beispiel</h4> <h5>Request</h5> <p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Simple.xml" target="_blank">CreateXMLSignatureRequest.Simple.xml</a></code> ist ein einfacher XML-Request zur Erzeugung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert:</p> <pre> <KeyIdentifier>KG_allgemein</KeyIdentifier> </pre> <p><code>KG_allgemein</code> bezeichnet eine Schlüsselgruppe, aus der SS einen Signaturschlüssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schlüsselgruppe entsprechen. </p> <pre> <SingleSignatureInfo SecurityLayerConformity="false"></pre> - <p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene XML-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine XML-Signatur gemäß <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20020831/core/Core.html#signaturerstellungNachXMLDSIGAntwort" target="_blank">Security-Layer Spezifikation V1.1 </a> 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. </p> - <pre> <DataObjectInfo Structure="enveloping"> + <p> Für jedes <code>SingleSignatureInfo</code>Element wird eine eigene XML-Signatur erzeugt. Wird das Attribut <code>SecurityLayerConformity</code> auf <code>true</code> gesetzt, dann wird eine XML-Signatur gemäß <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20020831/core/Core.html#signaturerstellungNachXMLDSIGAntwort" target="_blank">Security-Layer Spezifikation V1.1 </a> 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).</p> +<pre> <DataObjectInfo Structure="enveloping"> <DataObject> <XMLContent>Diese Daten werden signiert.<XMLContent> </DataObject></pre> - <p> </p> +<p> </p> <p> Für jedes Daten-Objekt, das in die XML-Signatur als <code>dsig:Reference</code> aufgenommen werden soll, muss ein <code>DataObjectInfo</code> Element spezifiziert werden. Das Attribut <code>Structure</code> gibt an, ob die Daten in die Signatur in ein <code>dsig:Object</code> Element integriert werden sollen (<code>Structure="enveloping"</code>), oder über einen URL referenziert werden sollen (<code>Structure="detached"</code>). </p> <p> Im Fall von <code>Structure="enveloping"</code> muss im nachfolgenden <code>DataObject</code> Element entweder das Attribut <code>Reference</code> (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 <code>Base64Content</code> (enthält Daten in Base64 kodierter Form) oder <code>XMLContent</code> (enthält Daten als beliebiges XML-Fragment) oder <code>LocRefContent</code> (enthält eine URL, von der SS die Daten beziehen soll; in diesem Fall also gleichwertig wie ein gesetztes Attribut <code>Reference</code>) spezifiziert sein. Die Angabe der zu signierenden Daten über das Attribut <code>Reference</code> und gleichzeitig einem der Elemente <code>Base64Content</code> oder <code>XMLContent</code> oder <code>LocRefContent</code> ist nicht erlaubt.</p> <p>Im Fall von <code>Structure="detached"</code> muss das Attribut <code>Reference</code> im nachfolgenden <code>DataObject</code> Element gesetzt sein. Es enthält jene URL, die zur Referenzierung der Daten als Wert von <code>dsig:Reference/@URI</code> in die XML-Signatur aufgenommen wird. Die Angabe eines der Element <code>Base64Content</code> oder <code>XMLContent</code> oder <code>LocRefContent</code> ist optional. Unterbleibt die Angabe, bezieht SS die Daten von der URL im Attribut <code>Reference</code>. Wird eines der Elemente verwendet, bezieht SS die Daten durch Analyse des angegebenen Elements (siehe obiger Absatz). </p> @@ -122,7 +137,7 @@ </dsig:Signature><br> </SignatureEnvironment><br></CreateXMLSignatureResponse></pre> <p></p> <p><code>CreateXMLSignatureResponse</code> enthält je erzeugter Signatur ein Element <code>SignatureEnvironment</code> (in diesem Fall genau ein Element). <code>SignatureEnvironment</code> 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 <code>dsig:Reference</code> Element ist enthalten). Das unterzeichnete Datenobjekt ist in der Signaturstruktur selbst enthalten (<code>enveloping</code>), und zwar in einem <code>dsig:Object</code> Element. </p> - <h4><a name="webservice_xmlrequests_erstellungxml_daten" id="webservice_xmlrequests_erstellungxml_daten"></a>2.1.1.2 Angabe der zu signierenden Daten </h4> + <h4><a name="webservice_xmlrequests_erstellungxml_daten" id="webservice_xmlrequests_erstellungxml_daten"></a>2.1.2.2 Angabe der zu signierenden Daten </h4> <h5>Request</h5> <p>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).</p> <p>Mit <a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Refs.xml" target="_blank"><code>CreateXMLSignatureRequest.Refs.xml</code></a> sollen insgesamt neun Datenobjekte signiert werden:</p> @@ -420,7 +435,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </dsig:Object> </pre> <p>Das fünfte <code>dsig:Object</code> enthält das <code>dsig:Manifest</code>, das von MOA SS auf Grund des ersten bzw. fünften <code>DataObjectInfo</code> des Requests erstellt wurde. Darin enthalten sind die zum ersten und fünten <code>DataObjectInfo</code> korrespondierenden <code>dsig:Reference</code> Elemente. Die Daten für die erste im <code>dsig:Manifest</code> enthaltene <code>dsig:Reference</code> wurden aus dem <code>Base64Content</code> Element des ersten <code>DataObjectInfo</code> entnommen, jene für die zweite <code>dsig:Reference</code> aus dem <code>Base64Content</code> Element des fünften <code>DataObjectInfo</code>. Der Wert des <code>URI</code> Attributs der zweiten <code>dsig:Reference</code> wurde aus dem <code>DataObject/@Reference</code> des fünften <code>DataObjectInfo</code> übernommen. </p> -<h4><a name="webservice_xmlrequests_erstellungxml_transformationen" id="webservice_xmlrequests_erstellungxml_transformationen"></a>2.1.1.3 Transformationen</h4> +<h4><a name="webservice_xmlrequests_erstellungxml_transformationen" id="webservice_xmlrequests_erstellungxml_transformationen"></a>2.1.2.3 Transformationen</h4> <h5>Request</h5> <p>Dieses Beispiel (<a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Transforms.xml" target="_blank"><code>CreateXMLSignatureRequest.Transforms.xml</code></a>) 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. </p> <pre><CreateXMLSignatureRequest @@ -536,7 +551,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> </dsig:Reference> </pre> <p>Die zweite <code>dsig:Reference</code> wurde auf Grund des zweiten <code>DataObjectInfo</code> im Request erstellt. Man erkennt auch hier gut, dass die URL auf die Referenz-Eingangsdaten (Wert des Attributs <code>dsig:Reference/@URI</code>) aus <code>DataObject/@Reference</code> übernommen und die drei Transformationen wie im Request angegeben eingefügt wurden. </p> -<h4><a name="webservice_xmlrequests_erstellungxml_ergaenzungsobjekte"></a>2.1.1.4 Ergänzungsobjekte </h4> +<h4><a name="webservice_xmlrequests_erstellungxml_ergaenzungsobjekte"></a>2.1.2.4 Ergänzungsobjekte </h4> <h5>Request</h5> <p>Dieses Beispiel (<a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.xml" target="_blank"><code>CreateXMLSignatureRequest.Supplements.xml</code></a>) stellt die Verwendung von Ergänzungsobjekten vor. Ein Ergänzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem <code>DataObject</code>) oder jenes Dokument, in das eine zu erzeugende Signatur eingefügt werden soll (Zusammenhang mit <code>CreateSignatureEnvironment</code>). 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.</p> <pre> @@ -602,8 +617,8 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <p>Auch für das Auflösen eines Verweises in einer DTD kann in analoger Weise von Ergänzungsobjekten Gebrauch gemacht werden. </p> <h5>Response</h5> <p><code><a href="../../clients/webservice/resources/requests/CreateXMLSignatureRequest.Supplements.resp.xml" target="_blank">CreateXMLSignatureRequest.Supplements.resp.xml</a></code> 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.</p> -<h3><a name="webservice_xmlrequests_pruefungcms" id="webservice_xmlrequests_pruefungcms"></a>2.1.2 Prüfung einer CMS-Signatur</h3> -<h4><a name="webservice_xmlrequests_pruefungcms_einfach" id="webservice_xmlrequests_pruefungcms_einfach"></a>2.1.2.1 Einfaches Beispiel</h4> +<h3><a name="webservice_xmlrequests_pruefungcms" id="webservice_xmlrequests_pruefungcms"></a>2.1.3 Prüfung einer CMS bzw. CAdES-Signatur</h3> +<h4><a name="webservice_xmlrequests_pruefungcms_einfach" id="webservice_xmlrequests_pruefungcms_einfach"></a>2.1.3.1 Einfaches Beispiel</h4> <h5>Request</h5> <p>Dieses Beispiel (<a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Simple.xml" target="_blank"><code>VerifyCMSSignatureRequest.Simple.xml</code></a>) 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.</p> <pre> @@ -650,7 +665,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< </CertificateCheck> </pre> <p>Abschließend enthält die Response mit <code>CertificateCheck/Code</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. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält <code>Code</code> den Wert <code>1</code>, d. h. MOA SP konnte die oben erläuterte Zertifikatskette nicht bilden. Für eine Übersicht der möglichen Kodes siehe <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2</a>.</p> -<h4><a name="webservice_xmlrequests_pruefungcms_erweitert" id="webservice_xmlrequests_pruefungcms_erweitert"></a>2.1.2.2 Erweitertes Beispiel</h4> +<h4><a name="webservice_xmlrequests_pruefungcms_erweitert" id="webservice_xmlrequests_pruefungcms_erweitert"></a>2.1.3.2 Erweitertes Beispiel</h4> <h5>Request</h5> <p>Dieses erweiterte Beispiel zur Prüfung einer CMS-Signatur (<a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.xml" target="_blank"><code>VerifyCMSSignatureRequest.Extended.xml</code></a>) demonstriert die Prüfung mehrerer Signatoren einer CMS-Signatur, die Angabe des Prüfzeitpunkts sowie die Prüfung einer <span class="term">Detached Signature</span>, d. h. einer Signatur, in der die signierten Daten nicht enthalten sind und daher extra angegeben werden müssen. </p> <pre> @@ -672,8 +687,8 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< <p>Das optionale Element <code>DataObject</code> muss dann angegeben werden, wenn eine <span class="term">Detached Signature</span> geprüft werden soll, d. h. wenn in der CMS-Signatur die signierten Daten nicht mitkodiert sind. In <code>DataObject/Content/Base64Content</code> sind in einem solchen Fall diese Daten in base64 kodierter Form bereit zu stellen.</p> <h5>Response</h5> <p><code><a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.resp.xml" target="_blank">VerifyCMSSignatureRequest.Extended.resp.xml</a></code> 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.</p> -<h3><a name="webservice_xmlrequests_pruefungxml"></a>2.1.3 Prüfen einer XML-Signatur</h3> -<h4><a name="webservice_xmlrequests_pruefungxml_einfach"></a>2.1.3.1 Einfaches Beispiel</h4> +<h3><a name="webservice_xmlrequests_pruefungxml"></a>2.1.4 Prüfen einer XML-Signatur</h3> +<h4><a name="webservice_xmlrequests_pruefungxml_einfach"></a>2.1.4.1 Einfaches Beispiel</h4> <h5>Request</h5> <p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Simple.xml" target="_blank">VerifyXMLSignatureRequest.Simple.xml</a></code> 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.</p> <pre> @@ -748,7 +763,7 @@ O=A-Trust Ges. für Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT< </CertificateCheck> </pre> <p>Abschließend enthält die Response mit <code>CertificateCheck/Code</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. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die Gültigkeit jedes Zertifikats dieser Kette überprüft. In unserem Beispiel enthält <code>Code</code> den Wert <code>0</code>, 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 <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturpruefungNachCMSAntwort" target="_blank">Security-Layer 1.2</a>.</p> -<h4><a name="webservice_xmlrequests_pruefungxml_erweitert"></a>2.1.3.2 Erweitertes Beispiel </h4> +<h4><a name="webservice_xmlrequests_pruefungxml_erweitert"></a>2.1.4.2 Erweitertes Beispiel </h4> <h5>Request</h5> <p>Dieses erweiterte Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Enveloped.xml" target="_blank"><code>VerifyXMLSignatureRequest.Enveloped.xml</code></a>) demonstriert die Prüfung einer <span class="term">Enveloped Signature</span>, 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.</p> <pre> @@ -816,7 +831,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende <code>dsig:Manife </VerifyXMLSignatureResponse> </pre> <p>Die Elemente <code>SignatureCheck</code> und <code>CertificateCheck</code> enthalten die Resultate der kryptographischen Prüfung der Signatur sowie der Zertifikatsprüfung (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>).</p> -<h4><a name="webservice_xmlrequests_pruefungxml_xmldsigmanifest"></a>2.1.3.3 Prüfung eines XMLDSIG-Manifests </h4> +<h4><a name="webservice_xmlrequests_pruefungxml_xmldsigmanifest"></a>2.1.4.3 Prüfung eines XMLDSIG-Manifests </h4> <h5>Request</h5> <p>Dieses Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.XMLDSigManifest.xml" target="_blank"><code>VerifyXMLSignatureRequest.XMLDSigManifest.xml</code></a>) demonstriert die Prüfung eines in der XML-Signatur vorhandenden <a href="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/#sec-Manifest" target="_blank">Manifests nach XMLDSig</a>. Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.</p> <pre> @@ -892,7 +907,7 @@ positive Ganzzahl repräsentiert, die auf das beinhaltende <code>dsig:Manife </VerifyXMLSignatureResponse> </pre> <p>Das Element<code> CertificateCheck</code> enthält das Resultat der Zertifikatsprüfung (siehe <a href="#webservice_xmlrequests_pruefungxml_einfach">Einfaches Beispiel</a>).</p> -<h4><a name="webservice_xmlrequests_pruefungxml_ergaenzungsobjekte"></a>2.3.1.4 Ergänzungsobjekte </h4> +<h4><a name="webservice_xmlrequests_pruefungxml_ergaenzungsobjekte"></a>2.1.4.4 Ergänzungsobjekte </h4> <p>Dieses Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.xml" target="_blank"><code>VerifyXMLSignatureRequest.Supplements.xml</code></a>) demonstriert die Verwendung von Ergänzungsobjekten. Ein Ergänzungsobjekt betrifft entweder ein signiertes Datum (Zusammenhang mit einem <code>dsig:Reference</code> der XML-Signatur) oder jenes Dokument, in dem sich die zu prüfende XML-Signatur befindet (Zusammenhang mit <code>VerifySignatureEnvironment</code>). 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.</p> <p>Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit eingerückt und gekürzt wurde.</p> <pre> @@ -960,7 +975,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <p>Das zweite Element <code>SupplementProfile</code> enthält analog das Ergänzungsobjekt für das oben beschriebene XML-Schema. <code>Content/@Reference</code> enthält die Referenz genau so, wie sie oben im Attribut <code>xsi:schemaLocation</code> angegeben wurde. </p> <h5>Response</h5> <p><code><a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Supplements.resp.xml" target="_blank">VerifyXMLSignatureRequest.Supplements.resp.xml</a></code> 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.</p> -<h4><a name="webservice_xmlrequests_pruefungxml_signaturmanifest" id="webservice_xmlrequests_pruefungxml_signaturmanifest"></a>2.1.3.5 Signatur-Manifest des Security-Layers </h4> +<h4><a name="webservice_xmlrequests_pruefungxml_signaturmanifest" id="webservice_xmlrequests_pruefungxml_signaturmanifest"></a>2.1.4.5 Signatur-Manifest des Security-Layers </h4> <h5>Request</h5> <p>Dieses Beispiel zur Prüfung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.SigManifest.xml" target="_blank"><code>VerifyXMLSignatureRequest.SigManifest.xml</code></a>) demonstriert die Überprüfung des Zusammenhangs zwischen den <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#glossar_Referenz-Eingangsdaten" target="_blank">Referenz-Eingangsdaten</a> und den <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#glossar_Hash-Eingangsdaten" target="_blank">Hash-Eingangsdaten</a> für die <code>dsig:Reference</code>-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. <a href="http://www.buergerkarte.at/konzept/securitylayer/spezifikation/20040514/core/Core.html#signaturerstellungNachXMLDSIGAntwortImplTransParam" target="_blank">Implizite Transformationsparameter</a>) einer XSLT-Transformation angewendet wurden, welche die Anwendung vorgegeben hat. Bei erfolgreicher Prüfung dieses Zusammenhangs kann die Anwendung die Referenz-Eingangsdaten einer <code>dsig:Reference</code> 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.</p> <pre> @@ -1139,28 +1154,23 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <h3><a name="webservice_clients_gemeinsamkeiten" id="webservice_clients_gemeinsamkeiten"></a>2.2.2 Gemeinsamkeiten</h3> <p>Dieser Abschnitt beschreibt die Gemeinsamkeiten aller drei Varianten des Webservice-Clients. </p> <p>Zunächst einmal benötigen alle drei Varianten die folgenden Java-Bibliotheken, die im Ordner <a href="../../clients/webservice/lib/">clients/webservice/lib/</a> dieses Handbuchs bereits enthalten sind:</p> -<p>TODO Update Versions</p> -<p>TODO kein lib Verzeichnis</p> <table class="fixedwidth" border="1" cellpadding="2"> <TBODY> <TR> <TH>Java-Bibliothek</TH> <TH>Bemerkung</TH> - </TR><TR> - <TD><a href="#referenzierte_software">J2SE</a></TD> - <TD> J2SE 1.3.1 SDK oder J2SE 1.4.2 SDK oder J2SE 5.0 SDK. </TD> </TR> + <tr class="fixedWidth"> + <td><a href="http://java.com/" target="_blank">Java SE</a></td> + <td>Java Standard Edition (Software Development Kit bzw. Java Runtime Environment) </td> + </tr> <TR> <TD><a href="#referenzierte_software">Apache Xerces</a></TD> - <TD>XML-Parser, Version 2.0.2 oder höher; nicht nötig wenn JDSE 1.4.2 oder höher verwendet wird. </TD> + <TD>XML-Parser, Version 2.0.2 oder höher</TD> </TR> <TR> <TD><a href="#referenzierte_software">AXIS Framework</a></TD> - <TD>Webservice-Framework, Version 1.1.</TD> - </TR> - <TR> - <TD><a href="#referenzierte_software">JSSE</a></TD> - <TD>Java Secure Socket Extension, Version 1.0.3 oder höher; nur notwendig für die Varianten <code>HTTPServerAuth</code> und <code>HTTPClientAuth</code>.</TD> + <TD>Webservice-Framework, ab Version 1.1.</TD> </TR> </TBODY> </TABLE> @@ -1178,13 +1188,13 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <li>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. <a href="../../clients/webservice/conf/http.properties"><code>http.properties</code></a> enthält eine auf dieses Handbuch abgestimmte Konfiguration.</li> </ol> <h3><a name="webservice_clients_httpsserverauth" id="webservice_clients_httpsserverauth"></a>2.2.3 Besonderheiten von <code>HTTPSServerAuth.java</code></h3> -<p>Diese Variante des Webservice-Clients verwendet JSSE, um im Schritt 3 des Kernablaufs aus <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> 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.</p> -<p>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 <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von <code><a href="../../clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTPSServerAuth.java">HTTPSServerAuth.java</a></code>. <a href="../../clients/webservice/conf/http.properties"><code>http.properties</code></a> enthält eine auf dieses Handbuch abgestimmte Konfiguration.</p> -<p>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 <code><a href="../../clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTPSServerAuth.java">HTTPSServerAuth.java</a></code> bereits enthalten, jedoch auskommentiert. Suchen Sie einfach nach dem String <code>javax.net.debug</code>, um zur entsprechenden Stelle im Quellcode zu gelangen. </p> +<p>Diese Variante des Webservice-Clients baut im Schritt 3 des Kernablaufs aus <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> 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.</p> +<p>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 <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von <code><a href="../../clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTPSServerAuth.java">HTTPSServerAuth.java</a></code>. <a href="../../clients/webservice/conf/http.properties"><code>http.properties</code></a> enthält eine auf dieses Handbuch abgestimmte Konfiguration.</p> +<p>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 <code><a href="../../clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTPSServerAuth.java">HTTPSServerAuth.java</a></code> bereits enthalten, jedoch auskommentiert. Suchen Sie einfach nach dem String <code>javax.net.debug</code>, um zur entsprechenden Stelle im Quellcode zu gelangen. </p> <h3><a name="webservice_clients_httpsclientauth" id="webservice_clients_httpsclientauth"></a>2.2.4 Besonderheiten von <code>HTTPSClientAuth.java</code> </h3> -<p>Diese Variante des Webservice-Clients verwendet JSSE, um im Schritt 3 des Kernablaufs aus <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> 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.</p> -<p>Die gegenüber <a href="#webservice_clients_httpsserverauth">Abschnitt 2.2.3</a> 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 <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von <code><a href="../../clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTPSClientAuth.java">HTTPSClientAuth.java</a></code>. <a href="../../clients/webservice/conf/http.properties"><code>http.properties</code></a> enthält eine auf dieses Handbuch abgestimmte Konfiguration.</p> -<p>Beachten Sie bitte auch den Hinweis zum JSSE Logging aus <a href="#webservice_clients_httpsserverauth">Abschnitt 2.2.3</a>.</p> +<p>Diese Variante des Webservice-Clients baut im Schritt 3 des Kernablaufs aus <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> 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.</p> +<p>Die gegenüber <a href="#webservice_clients_httpsserverauth">Abschnitt 2.2.3</a> 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 <a href="#webservice_clients_gemeinsamkeiten">Abschnitt 2.2.2</a> besprochenen Java-Properties-Datei vorgenommen. Genaue Infos zu diesen Konfigurationsparametern entnehmen Sie bitte der Quellcodedokumentation von <code><a href="../../clients/webservice/src/main/java/at/gv/egovernment/moa/spss/handbook/clients/webservice/HTTPSClientAuth.java">HTTPSClientAuth.java</a></code>. <a href="../../clients/webservice/conf/http.properties"><code>http.properties</code></a> enthält eine auf dieses Handbuch abgestimmte Konfiguration.</p> +<p>Beachten Sie bitte auch den Hinweis zum SSL Logging aus <a href="#webservice_clients_httpsserverauth">Abschnitt 2.2.3</a>.</p> <h1><a name="klassenbibliothek" id="klassenbibliothek"></a>3 Verwendung der Klassenbibliothek</h1> <p>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. </p> <h2><a name="klassenbibliothek_vorbereitung" id="klassenbibliothek_vorbereitung"></a>3.1 Vorbereitung</h2> @@ -1205,7 +1215,6 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <p> <h1><a name="referenzierte_software" id="referenzierte_software"></a>A Referenzierte Software</h1> <p>Auf folgende Software-Pakete wird in diesem Handbuch verwiesen:</p> -<p>TODO Update Versions</p> <table class="fixedWidth" border="1" cellpadding="2"> <tbody> <tr> @@ -1217,21 +1226,13 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.</doc:Paragraph> <td>XML-Parser aus dem Apache Project</td> </tr> <tr> - <td><a href="http://xml.apache.org/axis/">Apache Axis</a></td> + <td><a href="http://axis.apache.org/axis/">Apache Axis</a></td> <td>Webservice-Framework aus dem Apache Project</td> </tr> <tr> - <td><a href="http://java.sun.com/j2se/1.4.2/" target="_blank">J2SE 1.4.2 SDK/JRE</a></td> - <td>Java 2 Standard Edition in der Version 1.4.2 (Software Development Kit bzw. Java Runtime Environment) </td> - </tr> - <tr> - <td><a href="http://java.sun.com/j2se/1.5.0/" target="_blank">J2SE 5.0 SDK/JRE</a> </td> - <td>Java 2 Standard Edition in der Version 5.0 (Software Development Kit bzw. Java Runtime Environment) </td> - </tr> - <tr> - <td><a href="http://java.sun.com/products/jsse/">JSSE</a></td> - <td>Java Secure Socket Extension </td> - </tr> + <td><a href="http://java.com/" target="_blank">Java SE</a></td> + <td>Java Standard Edition (Software Development Kit bzw. Java Runtime Environment) </td> + </tr> </tbody> </table> <p> </p> 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 @@ -<!-- Alternate Example-less Configuration File --> -<!-- Note that component elements are nested corresponding to their - parent-child relationships with each other --> - -<!-- A "Server" is a singleton element that represents the entire JVM, - which may contain one or more "Service" instances. The Server - listens for a shutdown command on the indicated port. - - Note: A "Server" is not itself a "Container", so you may not - define subcomponents such as "Valves" or "Loggers" at this level. - --> - -<Server port="8005" shutdown="SHUTDOWN" debug="0"> - - - <!-- Uncomment this entry to enable JMX MBeans support --> -<!-- - <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" - debug="0" port="-1" login="admin" password="admin"/> ---> - - - <!-- A "Service" is a collection of one or more "Connectors" that share - a single "Container" (and therefore the web applications visible - within that Container). Normally, that Container is an "Engine", - but this is not required. - - Note: A "Service" is not itself a "Container", so you may not - define subcomponents such as "Valves" or "Loggers" at this level. - --> - - <!-- Define the Tomcat Stand-Alone Service --> - <Service name="Tomcat-Standalone"> - - <!-- A "Connector" represents an endpoint by which requests are received - and responses are returned. Each Connector passes requests on to the - associated "Container" (normally an Engine) for processing. - - By default, a non-SSL HTTP/1.1 Connector is established on port 8080. - You can also enable an SSL HTTP/1.1 Connector on port 8443 by - following the instructions below and uncommenting the second Connector - entry. SSL support requires the following steps (see the SSL Config - HOWTO in the Tomcat 4.0 documentation bundle for more detailed - instructions): - * Download and install JSSE 1.0.2 or later, and put the JAR files - into "$JAVA_HOME/jre/lib/ext". - * Execute: - %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) - $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) - with a password value of "changeit" for both the certificate and - the keystore itself. - - By default, DNS lookups are enabled when a web application calls - request.getRemoteHost(). This can have an adverse impact on - performance, so you can disable it by setting the - "enableLookups" attribute to "false". When DNS lookups are disabled, - request.getRemoteHost() will return the String version of the - IP address of the remote client. - --> - - <!-- Define a Coyote/JK2 AJP 1.3 Connector on port 8009 --> - <!-- - <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" - port="8009" minProcessors="5" maxProcessors="75" - enableLookups="true" redirectPort="8443" - acceptCount="10" debug="0" connectionTimeout="0" - useURIValidationHack="false" - protocolHandlerClassName="org.apache.jk.server.JkCoyoteHandler"/> - --> - - <!-- Define an AJP 1.3 Connector on port 8009 --> - <Connector className="org.apache.ajp.tomcat4.Ajp13Connector" - port="8009" minProcessors="5" maxProcessors="75" - acceptCount="10" debug="0"/> - - <!-- An Engine represents the entry point (within Catalina) that processes - every request. The Engine implementation for Tomcat stand alone - analyzes the HTTP headers included with the request, and passes them - on to the appropriate Host (virtual host). --> - - <!-- Define the top level container in our container hierarchy --> - <Engine name="Standalone" defaultHost="localhost" debug="0"> - - <!-- The request dumper valve dumps useful debugging information about - the request headers and cookies that were received, and the response - headers and cookies that were sent, for all requests received by - this instance of Tomcat. If you care only about requests to a - particular virtual host, or a particular application, nest this - element inside the corresponding <Host> or <Context> entry instead. - - For a similar mechanism that is portable to all Servlet 2.3 - containers, check out the "RequestDumperFilter" Filter in the - example application (the source for this filter may be found in - "$CATALINA_HOME/webapps/examples/WEB-INF/classes/filters"). - - Request dumping is disabled by default. Uncomment the following - element to enable it. --> - <!-- - <Valve className="org.apache.catalina.valves.RequestDumperValve"/> - --> - - <!-- Global logger unless overridden at lower levels --> - <Logger className="org.apache.catalina.logger.FileLogger" - prefix="catalina_log." suffix=".txt" - timestamp="true"/> - - <!-- Because this Realm is here, an instance will be shared globally --> - - <Realm className="org.apache.catalina.realm.MemoryRealm" /> - - <!-- Replace the above Realm with one of the following to get a Realm - stored in a database and accessed via JDBC --> - - <!-- Define the default virtual host --> - <Host name="localhost" debug="0" appBase="webapps" - unpackWARs="true" autoDeploy="true"> - - <!-- Normally, users must authenticate themselves to each web app - individually. Uncomment the following entry if you would like - a user to be authenticated the first time they encounter a - resource protected by a security constraint, and then have that - user identity maintained across *all* web applications contained - in this virtual host. --> - <!-- - <Valve className="org.apache.catalina.authenticator.SingleSignOn" - debug="0"/> - --> - - <!-- Access log processes all requests for this virtual host. By - default, log files are created in the "logs" directory relative to - $CATALINA_HOME. If you wish, you can specify a different - directory with the "directory" attribute. Specify either a relative - (to $CATALINA_HOME) or absolute path to the desired directory. - --> - <Valve className="org.apache.catalina.valves.AccessLogValve" - directory="logs" prefix="localhost_access_log." suffix=".txt" - pattern="common"/> - - <!-- Logger shared by all Contexts related to this virtual host. By - default (when using FileLogger), log files are created in the "logs" - directory relative to $CATALINA_HOME. If you wish, you can specify - a different directory with the "directory" attribute. Specify either a - relative (to $CATALINA_HOME) or absolute path to the desired - directory.--> - <Logger className="org.apache.catalina.logger.FileLogger" - directory="logs" prefix="localhost_log." suffix=".txt" - timestamp="true"/> - - <!-- Define properties for each web application. This is only needed - if you want to set non-default properties, or have web application - document roots in places other than the virtual host's appBase - directory. --> - - <!-- Tomcat Root Context --> - <!-- - <Context path="" docBase="ROOT" debug="0"/> - --> - - </Host> - - </Engine> - - </Service> - -</Server> - 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 @@ -<!-- Alternate Example-less Configuration File --> -<!-- Note that component elements are nested corresponding to their - parent-child relationships with each other --> - -<!-- A "Server" is a singleton element that represents the entire JVM, - which may contain one or more "Service" instances. The Server - listens for a shutdown command on the indicated port. - - Note: A "Server" is not itself a "Container", so you may not - define subcomponents such as "Valves" or "Loggers" at this level. - --> - -<Server port="8005" shutdown="SHUTDOWN" debug="0"> - - - <!-- Uncomment this entry to enable JMX MBeans support --> -<!-- - <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" - debug="0" port="-1" login="admin" password="admin"/> ---> - - - <!-- A "Service" is a collection of one or more "Connectors" that share - a single "Container" (and therefore the web applications visible - within that Container). Normally, that Container is an "Engine", - but this is not required. - - Note: A "Service" is not itself a "Container", so you may not - define subcomponents such as "Valves" or "Loggers" at this level. - --> - - <!-- Define the Tomcat Stand-Alone Service --> - <Service name="Tomcat-Standalone"> - - <!-- A "Connector" represents an endpoint by which requests are received - and responses are returned. Each Connector passes requests on to the - associated "Container" (normally an Engine) for processing. - - By default, a non-SSL HTTP/1.1 Connector is established on port 8080. - You can also enable an SSL HTTP/1.1 Connector on port 8443 by - following the instructions below and uncommenting the second Connector - entry. SSL support requires the following steps (see the SSL Config - HOWTO in the Tomcat 4.0 documentation bundle for more detailed - instructions): - * Download and install JSSE 1.0.2 or later, and put the JAR files - into "$JAVA_HOME/jre/lib/ext". - * Execute: - %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows) - $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix) - with a password value of "changeit" for both the certificate and - the keystore itself. - - By default, DNS lookups are enabled when a web application calls - request.getRemoteHost(). This can have an adverse impact on - performance, so you can disable it by setting the - "enableLookups" attribute to "false". When DNS lookups are disabled, - request.getRemoteHost() will return the String version of the - IP address of the remote client. - --> - - <!-- Define a non-SSL Coyote HTTP/1.1 Connector on port 8080 --> - <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" - port="8080" minProcessors="5" maxProcessors="75" - enableLookups="true" redirectPort="8443" - acceptCount="100" debug="0" connectionTimeout="20000" - useURIValidationHack="false" disableUploadTimeout="true" /> - <!-- Note : To disable connection timeouts, set connectionTimeout value - to -1 --> - - <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> - <!-- - <Connector className="org.apache.coyote.tomcat4.CoyoteConnector" - port="8443" minProcessors="5" maxProcessors="75" - enableLookups="uri" - acceptCount="100" debug="0" scheme="https" secure="true" - useURIValidationHack="false" disableUploadTimeout="true"> - <Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory" - clientAuth="false" protocol="TLS"/> - </Connector> - --> - - <!-- An Engine represents the entry point (within Catalina) that processes - every request. The Engine implementation for Tomcat stand alone - analyzes the HTTP headers included with the request, and passes them - on to the appropriate Host (virtual host). --> - - <!-- Define the top level container in our container hierarchy --> - <Engine name="Standalone" defaultHost="localhost" debug="0"> - - <!-- The request dumper valve dumps useful debugging information about - the request headers and cookies that were received, and the response - headers and cookies that were sent, for all requests received by - this instance of Tomcat. If you care only about requests to a - particular virtual host, or a particular application, nest this - element inside the corresponding <Host> or <Context> entry instead. - - For a similar mechanism that is portable to all Servlet 2.3 - containers, check out the "RequestDumperFilter" Filter in the - example application (the source for this filter may be found in - "$CATALINA_HOME/webapps/examples/WEB-INF/classes/filters"). - - Request dumping is disabled by default. Uncomment the following - element to enable it. --> - <!-- - <Valve className="org.apache.catalina.valves.RequestDumperValve"/> - --> - - <!-- Global logger unless overridden at lower levels --> - <Logger className="org.apache.catalina.logger.FileLogger" - prefix="catalina_log." suffix=".txt" - timestamp="true"/> - - <!-- Because this Realm is here, an instance will be shared globally --> - - <Realm className="org.apache.catalina.realm.MemoryRealm" /> - - <!-- Define the default virtual host --> - <Host name="localhost" debug="0" appBase="webapps" - unpackWARs="true" autoDeploy="true"> - - <!-- Normally, users must authenticate themselves to each web app - individually. Uncomment the following entry if you would like - a user to be authenticated the first time they encounter a - resource protected by a security constraint, and then have that - user identity maintained across *all* web applications contained - in this virtual host. --> - <!-- - <Valve className="org.apache.catalina.authenticator.SingleSignOn" - debug="0"/> - --> - - <!-- Access log processes all requests for this virtual host. By - default, log files are created in the "logs" directory relative to - $CATALINA_HOME. If you wish, you can specify a different - directory with the "directory" attribute. Specify either a relative - (to $CATALINA_HOME) or absolute path to the desired directory. - --> - <Valve className="org.apache.catalina.valves.AccessLogValve" - directory="logs" prefix="localhost_access_log." suffix=".txt" - pattern="common"/> - - <!-- Logger shared by all Contexts related to this virtual host. By - default (when using FileLogger), log files are created in the "logs" - directory relative to $CATALINA_HOME. If you wish, you can specify - a different directory with the "directory" attribute. Specify either a - relative (to $CATALINA_HOME) or absolute path to the desired - directory.--> - <Logger className="org.apache.catalina.logger.FileLogger" - directory="logs" prefix="localhost_log." suffix=".txt" - timestamp="true"/> - - <!-- Define properties for each web application. This is only needed - if you want to set non-default properties, or have web application - document roots in places other than the virtual host's appBase - directory. --> - - <!-- Tomcat Root Context --> - <!-- - <Context path="" docBase="ROOT" debug="0"/> - --> - - </Host> - - </Engine> - - </Service> - -</Server> - |