aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorKlaus Stranacher <kstranacher@iaik.tugraz.at>2013-04-24 16:46:35 +0200
committerKlaus Stranacher <kstranacher@iaik.tugraz.at>2013-04-24 16:46:35 +0200
commit76ee7b768603988e4a6ca59011eee2b7dd33fa21 (patch)
tree116ed802151f2acf100987eac3c00eef627202c5
parent0d6ea7472c4a76deb68687dbc601337b93bf8e8f (diff)
downloadmoa-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.html105
-rw-r--r--spss/handbook/handbook/install/install.html20
-rw-r--r--spss/handbook/handbook/usage/usage.html107
-rw-r--r--spss/server/serverlib/resources/data/deploy/tomcat/server.mod_jk.xml166
-rw-r--r--spss/server/serverlib/resources/data/deploy/tomcat/server.xml169
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&ouml;sen externer URIs</a></li>
- </ol>
+ <li><a href="#konfigurationsparameter_allgemein_externaluris">Aufl&ouml;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&uuml;r MOA SS</a> <ol>
<li><a href="#konfigurationsparameter_ss_keymodules">Schl&uuml;sselspeicher</a> <ol>
@@ -61,6 +66,7 @@
<li><a href="#konfigurationsparameter_ss_xmldsig">Parameter f&uuml;r XML-Signaturen</a> </li>
<li><a href="#konfigurationsparameter_ss_createtransformsinfoprofile">Profil f&uuml;r Transformationen</a></li>
<li><a href="#konfigurationsparameter_ss_createsignatureenvironmentprofile">Profil f&uuml;r Signaturumgebung </a></li>
+ <li><a href="#konfigurationsparameter_ss_xades">XAdES Version</a></li>
</ol>
</li>
<li><a href="#konfigurationsparameter_sp">Parameter f&uuml;r MOA SP</a> <ol>
@@ -108,14 +114,13 @@
</ol>
</li>
</ol>
- <hr/>
+<hr/>
<h1><a name="übersicht" id="übersicht"></a>1 &Uuml;bersicht </h1>
<p>Dieses Handbuch beschreibt detailliert die Konfigurationsm&ouml;glichkeiten f&uuml;r MOA SP/SS. Wenn nicht anders angegeben, beziehen sich die Erl&auml;uterungen sowohl auf die Konfiguration des Webservices als auch auf die Konfiguration von MOA SP/SS f&uuml;r den Einsatz als Klassenbibliothek.</p>
<h2><a name="&uuml;bersicht_allgemeines" id="&uuml;bersicht_allgemeines"></a>1.1 Allgemeines</h2>
<h3><a name="&uuml;bersicht_allgemeines_namenskonventionen" id="&uuml;bersicht_allgemeines_namenskonventionen"></a>1.1.1 Namenskonventionen </h3>
<p>Folgende Namenraum-Pr&auml;fixe werden in diesem Handbuch zur Kennzeichnung der Namenr&auml;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&auml;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&ouml;sen externer URIs</h3>
- <p>TODO Update Whitelisting</p>
+ <h3><a name="konfigurationsparameter_allgemein_externaluris" id="konfigurationsparameter_allgemein_externaluris"></a>2.1.2 Aufl&ouml;sen externer URIs</h3>
+ <p>Standardm&auml;&szlig;ig ist das Aufl&ouml;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&ouml;glichkeiten das Aufl&ouml;sen zu aktivieren bzw. zu </p>
+ <ul>
+ <li>Blacklisting: Hierbei wird das Aufl&ouml;sen von externen URIs erlaubt. Es kann jedoch durch die Angaben einer Blacklist der Zugriff auf bestimmte URIs eingeschr&auml;nkt werden.</li>
+ <li>Whitelisting: Hierbei ist das Aufl&ouml;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&ouml;glichkeiten stehen wahlweise zur Verf&uuml;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&auml;uterung</td>
- <td><p>Mit diesem Element wird MOA SP bzw. SS mitgeteilt ob das Aufl&ouml;sen externer URIs (inkl. localhost) erlaubt ist. Fehlt dieses Element, so ist das Aufl&ouml;sen externer URIs deaktiviert. Ist dieses Element vorhanden, so ist das Aufl&ouml;sen aller externer URIs aktiviert. Durch einen Blacklist-Mechanismus kann jedoch eingeschr&auml;nkt werden, dass bestimmte URIs, die sich auf dieser Blacklist befinden, nicht aufgel&ouml;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&ouml;sen externer URIs (inkl. localhost) erlaubt ist. Ist dieses Element vorhanden, so ist das Aufl&ouml;sen aller externer URIs aktiviert. Durch einen Blacklist-Mechanismus kann jedoch eingeschr&auml;nkt werden, dass bestimmte URIs, die sich auf dieser Blacklist befinden, nicht aufgel&ouml;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&auml;uterung</td>
+ <td><p>Mit diesem Element wird MOA SP bzw. SS mitgeteilt, dass das Aufl&ouml;sen externer URIs (inkl. localhost) zwar verboten ist, aber durch eine Whitelist entsprechende Ausnahmen angeben werden k&ouml;nnen. D.h. URIs, die sich auf dieser Whitelist befinden werden aufgel&ouml;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&ouml;st. Bei Angabe eines IP-Adress-Bereichs werden s&auml;mtliche URIs, die mit diesem IP-Bereich beginnen aufgel&ouml;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&ouml;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&uuml;r MOA SS</h2>
<h3><a name="konfigurationsparameter_ss_keymodules" id="konfigurationsparameter_ss_keymodules"></a>2.2.1 Schl&uuml;sselspeicher</h3>
<h4><a name="konfigurationsparameter_ss_keymodules_hardwarekeymodule" id="konfigurationsparameter_ss_keymodules_hardwarekeymodule"></a>2.2.1.1 Hardware-Schl&uuml;sselspeicher</h4>
@@ -327,17 +360,16 @@
</tr>
<tr>
<td>Erl&auml;uterung</td>
- <td><p>TODO Update DigestMethod</p>
- <p>Mit diesem Element wird in MOA SS eine Schl&uuml;sselgruppe definiert. Eine Schl&uuml;sselgruppe
+ <td><p>Mit diesem Element wird in MOA SS eine Schl&uuml;sselgruppe definiert. Eine Schl&uuml;sselgruppe
ist eine Zusammenfassung von einem oder mehreren privaten Schl&uuml;sseln, die in Hardware- bzw. Softwareschl&uuml;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&uuml;sselgruppe wird vom Kunden von MOA SS &uuml;ber einen eindeutigen Bezeichner
im Request zur Signaturerstellung angesprochen. </p>
- <p>Sinn der Zusammenfassung von mehreren privaten Schl&uuml;sseln zu einer Schl&uuml;sselgruppe ist
+<p>Sinn der Zusammenfassung von mehreren privaten Schl&uuml;sseln zu einer Schl&uuml;sselgruppe ist
es, dass MOA SS selbst entscheidet, welcher konkrete Schl&uuml;ssel aus der Schl&uuml;sselgruppe
zur Erstellung der Signatur verwendet wird. Durch die somit m&ouml;gliche Parallelisierung (mehrere
private Schl&uuml;ssel werden parallel f&uuml;r Anfragen, die auf die gleiche Schl&uuml;sselgruppe
- referenzieren) l&auml;sst sich der Durchsatz der erstellten Signaturen verbessern. </p>
+ referenzieren) l&auml;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&auml;lt
@@ -370,10 +402,11 @@
</li>
</ul>
</li>
+ <li>Element <code>cfg:DigestMethodAlgorithm</code>: Dieses optionale Element spezifiert einen Digest-Algorithmus, der f&uuml;r das Erstellen von XML-Signaturen mittels dieser Schl&uuml;sselgruppe verwendet werden soll. Der Default-Wert bzw. ein allf&auml;llig in Abschnitt &quot;<a href="#konfigurationsparameter_ss_xmldsig">Parameter f&uuml;r XML-Signaturen</a>&quot; definierter Wert, werden dadurch f&uuml;r diese Schl&uuml;sselgruppe &uuml;berschrieben. M&ouml;gliche Werte sind dem Element <code>cfg:SignatureCreation/cfg:XMLDSig/cfg:DigestMethodAlgorithm</code> ebenfalls in Abschnitt &quot;<a href="#konfigurationsparameter_ss_xmldsig">Parameter f&uuml;r XML-Signaturen</a>&quot; zu entnehmen. </li>
</ul>
<p>Um auf einfache Weise f&uuml;r alle in Ihren Schl&uuml;sselspeichern enthaltenen privaten Schl&uuml;ssel
die jeweiligen Werte f&uuml;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&uuml;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&auml;uterung</td>
- <td><p> Als Inhalt des Elements kann der Kanonisierungs-Algorithmus, der f&uuml;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&uuml;rfen verwendet werden:</p>
+ <td><p>TODO: Kanonisierungs-Algorithmen entsprechend Kommissionsentscheidung?</p>
+ <p>Als Inhalt des Elements kann der Kanonisierungs-Algorithmus, der f&uuml;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&uuml;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&auml;uterung</td>
- <td><p>TODO Update Beschreibung hinsichtlich XAdES 1.4.2</p>
- <p>Als Inhalt des Elements kann der Digest-Algorithmus, der f&uuml;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&uuml;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&uuml;r die genaue Bedeutung der Werte siehe die <a href="http://www.w3.org/TR/xmldsig-core/" target="_blank">Spezifikation f&uuml;r XML-Signaturen</a>.</p></td>
+ <td><p>Als Inhalt des Elements kann der Digest-Algorithmus, der f&uuml;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&uuml;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&auml;ngig von der konfigurierten XAdES-Version (siehe <a href="#konfigurationsparameter_ss_xades">XAdES-Version</a>)- folgender Wert als Default-Wert verwendet:
+ <p>F&uuml;r XAdES Version 1.1.1:</p>
+ <pre>http://www.w3.org/2000/09/xmldsig#sha1</pre>
+ <p>F&uuml;r XAdES Version 1.4.2:</p>
+<pre>http://www.w3.org/2000/09/xmldsig#sha256</pre>
+<p>F&uuml;r die genaue Bedeutung der Werte siehe die <a href="http://www.w3.org/TR/xmldsig-core/" target="_blank">Spezifikation f&uuml;r XML-Signaturen</a>.</p></td>
</tr>
</table>
<h3><a name="konfigurationsparameter_ss_createtransformsinfoprofile" id="konfigurationsparameter_ss_createtransformsinfoprofile"></a>2.2.5 Profil f&uuml;r Transformationen</h3>
@@ -551,7 +586,7 @@ IssuerDN (RFC2253) :
eingef&uuml;gt werden soll, sowie allenfalls f&uuml;r die Verarbeitung des bestehenden XML-Dokuments
notwendige Erg&auml;nzungsobjekte (z.B. ein XML-Schema f&uuml;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&auml;lt
@@ -566,7 +601,25 @@ IssuerDN (RFC2253) :
</ul></td>
</tr>
</table>
- <p>TODO XAdES 1.4.2 M&ouml;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&auml;uterung</td>
+ <td><p>MOA SS erm&ouml;glicht die Erstellung einer herk&ouml;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&auml;&szlig; 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&uuml;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="#&#220;bersicht">&Uuml;bersicht</a></p>
+ <p><a href="#uebersicht">&Uuml;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&#252;hrung">Einf&uuml;hrung</a></li>
+ <li><a href="#webservice_basisinstallation_einfuehrung">Einf&uuml;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 &Uuml;bersicht</h1>
+ <h1><a name="uebersicht" id="uebersicht"></a>1 &Uuml;bersicht</h1>
<p> Die Module Signaturpr&uuml;fung (SP) und Serversignatur (SS) sind als plattformunabh&auml;ngige Module ausgelegt, die entweder als Webservice &uuml;ber HTTP bzw. HTTPS oder als Klassenbibliothek &uuml;ber ein API angesprochen werden k&ouml;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&ouml;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&uuml;hrung </h3>
+ <h3><a name="webservice_basisinstallation_einfuehrung" id="webservice_basisinstallation_einfuehrung"></a>2.1.1 Einf&uuml;hrung </h3>
<p> Die Basisinstallation des Webservices stellt einerseits die minimalen Anforderungen f&uuml;r den Betrieb von MOA SP/SS als Webservices dar, andererseits dient sie als Ausgangspunkt f&uuml;r optionale <a href="#webservice_erweiterungsmoeglichkeiten">Erweiterungsm&ouml;glichkeiten</a>.</p>
<p>Die <strong>Mindestanforderungen</strong> f&uuml;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&auml;tzlich mit einer funktionierenden Default-Konfiguration ausgeliefert, die jedoch einiges an Ballast enth&auml;lt und viele Ports offen l&auml;sst. </p>
+ <p>Die zentrale Konfigurations-Datei von Tomcat ist <code>$CATALINA_HOME/conf/server.xml</code>. Tomcat wird grunds&auml;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&auml;lt eine minimale Tomcat-Konfiguration f&uuml;r Apache Tomcat 7, die ausschlie&szlig;lich den Connector f&uuml;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&uuml;r F&auml;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&szlig;lich den Connector f&uuml;r HTTP auf Port 8080 frei. Wir empfehlen diese Konfiguration nur f&uuml;r F&auml;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 &uuml;ber das Internet) betrieben, ist die gegenseitige Identit&auml;tsfeststellung von Kunde und Webservice essentiell: </p>
<ul>
<li> Nutzt ein Kunde MOA SP, ist es f&uuml;r ihn wichtig, die Identit&auml;t des Webservice eindeutig feststellen zu k&ouml;nnen, denn er vertraut dem Webservice ja die Pr&uuml;fung einer elektronischen Signatur an.</li>
@@ -306,11 +305,10 @@ INFO | 01 21:25:26,540 | Thread-3 | TID=1049225059594-100 NID=&lt;null&gt;
<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&uuml;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&uuml;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&ouml;nnen die Konnektoren f&uuml;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&auml;lt eine Konfiguration, die ausschlie&szlig;lich den Port f&uuml;r den <span class="term">AJP 1.3 Connector</span> offen l&auml;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&ouml;nnen die Konnektoren f&uuml;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&uuml;gung. </p>
- <h4><a name="webservice_erweiterungsm&ouml;glichkeiten_webserver_apache" id="webservice_erweiterungsm&ouml;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&uuml;r die Kommunikation zwischen Webserver und Tomcat eingesetzt. Die angef&uuml;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&uuml;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&auml;nzungsobjekte</a> </li>
- </ol>
+ </ol>
</li>
- <li><a href="#webservice_xmlrequests_pruefungcms">Pr&uuml;fung einer CMS-Signatur </a> <ol>
+ <li><a href="#webservice_xmlrequests_pruefungcms">Pr&uuml;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&uuml;fung einer XML-Signatur </a> <ol>
+ <li><a href="#webservice_xmlrequests_pruefungxml">Pr&uuml;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&uuml;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&uuml;r die Erstellung einer XML-Signatur mittels SS bzw. zur Pr&uuml;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&ouml;chten, m&uuml;ssen Sie daf&uuml;r sorgen, dass MOA SS bzw. SP diese Daten auch tats&auml;chlich aufl&ouml;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&uuml;ssen Sie zus&auml;tzlich die URLs in den Requests anpassen. </p>
- <p class="remark">&nbsp;</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&ouml;glicht die Erstellung einer herk&ouml;mmlichen XML-Signatur und einer XAdES-Signatur&nbsp;gem&auml;&szlig; 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&ouml;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&auml;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> &lt;KeyIdentifier&gt;KG_allgemein&lt;/KeyIdentifier&gt; </pre>
<p><code>KG_allgemein</code> bezeichnet eine Schl&uuml;sselgruppe, aus der SS einen Signaturschl&uuml;ssel selektieren soll und muss einer in der SP/SS-Konfigurationsdatei definierten Schl&uuml;sselgruppe entsprechen. </p>
<pre> &lt;SingleSignatureInfo SecurityLayerConformity="false"&gt;</pre>
- <p> F&uuml;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&auml;&szlig; <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&uuml;r die Signatur&uuml;berpr&uuml;fung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten) und ein Manifest, das alle implizite Transformationsparameter enth&auml;lt, zur Signatur hinzugef&uuml;gt. </p>
- <pre> &lt;DataObjectInfo Structure="enveloping"&gt;
+ <p> F&uuml;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&auml;&szlig; <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&uuml;r die Signatur&uuml;berpr&uuml;fung zu verwendende Zertifikat, Metainformationen zu den signierten Datenobjekten) und ein Manifest, das alle implizite Transformationsparameter enth&auml;lt, zur Signatur hinzugef&uuml;gt (=eine XAdES Signatur).</p>
+<pre> &lt;DataObjectInfo Structure="enveloping"&gt;
&lt;DataObject&gt;
&lt;XMLContent&gt;Diese Daten werden signiert.&lt;XMLContent&gt;
&lt;/DataObject&gt;</pre>
- <p> </p>
+<p> </p>
<p> F&uuml;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 &uuml;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&auml;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&auml;lt Daten in Base64 kodierter Form) oder <code>XMLContent</code> (enth&auml;lt Daten als beliebiges XML-Fragment) oder <code>LocRefContent</code> (enth&auml;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 &uuml;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&auml;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 @@
&lt;/dsig:Signature&gt;<br> &lt;/SignatureEnvironment&gt;<br>&lt;/CreateXMLSignatureResponse&gt;</pre>
<p></p>
<p><code>CreateXMLSignatureResponse</code> enth&auml;lt je erzeugter Signatur ein Element <code>SignatureEnvironment</code> (in diesem Fall genau ein Element). <code>SignatureEnvironment</code> enth&auml;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&auml;ltigen M&ouml;glichkeiten vor, wie MOA SS mitgeteilt werden kann, welche Daten signiert (wenn keine Transformationen angegeben werden) bzw. als Eingangsdaten f&uuml;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.&lt;/doc:Paragraph&gt;
&lt;/dsig:Object&gt;
</pre>
<p>Das f&uuml;nfte <code>dsig:Object</code> enth&auml;lt das <code>dsig:Manifest</code>, das von MOA SS auf Grund des ersten bzw. f&uuml;nften <code>DataObjectInfo</code> des Requests erstellt wurde. Darin enthalten sind die zum ersten und f&uuml;nten <code>DataObjectInfo</code> korrespondierenden <code>dsig:Reference</code> Elemente. Die Daten f&uuml;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&uuml;r die zweite <code>dsig:Reference</code> aus dem <code>Base64Content</code> Element des f&uuml;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&uuml;nften <code>DataObjectInfo</code> &uuml;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&ouml;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&szlig;t dann in die Hashwert-Berechnung ein. </p>
<pre>&lt;CreateXMLSignatureRequest
@@ -536,7 +551,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.&lt;/doc:Paragraph&gt;
&lt;/dsig:Reference&gt;
</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> &uuml;bernommen und die drei Transformationen wie im Request angegeben eingef&uuml;gt wurden. </p>
-<h4><a name="webservice_xmlrequests_erstellungxml_ergaenzungsobjekte"></a>2.1.1.4 Erg&auml;nzungsobjekte </h4>
+<h4><a name="webservice_xmlrequests_erstellungxml_ergaenzungsobjekte"></a>2.1.2.4 Erg&auml;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&auml;nzungsobjekten vor. Ein Erg&auml;nzungsobjekt betrifft entweder ein zu signierendes Datum (Zusammenhang mit einem <code>DataObject</code>) oder jenes Dokument, in das eine zu erzeugende Signatur eingef&uuml;gt werden soll (Zusammenhang mit <code>CreateSignatureEnvironment</code>). Es muss dann angegeben werden, wenn in einem zu signierenden Datum bzw. im Einf&uuml;gedokument auf Daten per Referenz verwiesen wird, diese referenzierten Daten aber von MOA SS nicht aufgel&ouml;st werden k&ouml;nnen. Das Erg&auml;nzungsobjekt enth&auml;lt dann genau diese Daten, die nicht von MOA SS aufgel&ouml;st werden k&ouml;nnen.</p>
<pre>
@@ -602,8 +617,8 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.&lt;/doc:Paragraph&gt;
<p>Auch f&uuml;r das Aufl&ouml;sen eines Verweises in einer DTD kann in analoger Weise von Erg&auml;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&auml;her analysiert, da er keine f&uuml;r das Thema des Beispiels relevanten Besonderheiten aufweist.</p>
-<h3><a name="webservice_xmlrequests_pruefungcms" id="webservice_xmlrequests_pruefungcms"></a>2.1.2 Pr&uuml;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&uuml;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&uuml;fung einer CMS-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der nachfolgende Ausschnitt aus dem Request aus Gr&uuml;nden der &Uuml;bersichtlichkeit gek&uuml;rzt wurde.</p>
<pre>
@@ -650,7 +665,7 @@ O=A-Trust Ges. f&uuml;r Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT&lt;
&lt;/CertificateCheck&gt;
</pre>
<p>Abschlie&szlig;end enth&auml;lt die Response mit <code>CertificateCheck/Code</code> das Resultat der Pr&uuml;fung des Signatorzertifikats. Zun&auml;chst pr&uuml;ft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugeh&ouml;rigen Vertrauensprofil konfigurierten sog. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die G&uuml;ltigkeit jedes Zertifikats dieser Kette &uuml;berpr&uuml;ft. In unserem Beispiel enth&auml;lt <code>Code</code> den Wert <code>1</code>, d. h. MOA SP konnte die oben erl&auml;uterte Zertifikatskette nicht bilden. F&uuml;r eine &Uuml;bersicht der m&ouml;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&uuml;fung einer CMS-Signatur (<a href="../../clients/webservice/resources/requests/VerifyCMSSignatureRequest.Extended.xml" target="_blank"><code>VerifyCMSSignatureRequest.Extended.xml</code></a>) demonstriert die Pr&uuml;fung mehrerer Signatoren einer CMS-Signatur, die Angabe des Pr&uuml;fzeitpunkts sowie die Pr&uuml;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&uuml;ssen. </p>
<pre>
@@ -672,8 +687,8 @@ O=A-Trust Ges. f&uuml;r Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT&lt;
<p>Das optionale Element <code>DataObject</code> muss dann angegeben werden, wenn eine <span class="term">Detached Signature</span> gepr&uuml;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&auml;her analysiert, da er keine f&uuml;r das Thema des Beispiels relevanten Besonderheiten aufweist.</p>
-<h3><a name="webservice_xmlrequests_pruefungxml"></a>2.1.3 Pr&uuml;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&uuml;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&uuml;fung einer XML-Signatur. Sein Aufbau wird nachfolgend analysiert. Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit einger&uuml;ckt und gek&uuml;rzt wurde.</p>
<pre>
@@ -748,7 +763,7 @@ O=A-Trust Ges. f&uuml;r Sicherheitssysteme im elektr. Datenverkehr GmbH,C=AT&lt;
&lt;/CertificateCheck&gt;
</pre>
<p>Abschlie&szlig;end enth&auml;lt die Response mit <code>CertificateCheck/Code</code> das Resultat der Pr&uuml;fung des Signatorzertifikats. Zun&auml;chst pr&uuml;ft MOA SP, ob ausgehend vom Signatorzertifikat eine Zertifikatskette zu einem im zugeh&ouml;rigen Vertrauensprofil konfigurierten sog. <span class="term">Trust Anchor</span> gebildet werden kann. Gelingt dies, wird die G&uuml;ltigkeit jedes Zertifikats dieser Kette &uuml;berpr&uuml;ft. In unserem Beispiel enth&auml;lt <code>Code</code> den Wert <code>0</code>, d. h. MOA SP konnte die Kette bilden, und alle Zertifikate der Kette sind g&uuml;ltig. F&uuml;r eine &Uuml;bersicht der m&ouml;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&uuml;fung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.Enveloped.xml" target="_blank"><code>VerifyXMLSignatureRequest.Enveloped.xml</code></a>) demonstriert die Pr&uuml;fung einer <span class="term">Enveloped Signature</span>, d. h. einer Signatur, die in ein XML-Dokument integriert ist, die Angabe des Pr&uuml;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&auml;sentiert, die auf das beinhaltende <code>dsig:Manife
&lt;/VerifyXMLSignatureResponse&gt;
</pre>
<p>Die Elemente <code>SignatureCheck</code> und <code>CertificateCheck</code> enthalten die Resultate der kryptographischen Pr&uuml;fung der Signatur sowie der Zertifikatspr&uuml;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&uuml;fung eines XMLDSIG-Manifests </h4>
+<h4><a name="webservice_xmlrequests_pruefungxml_xmldsigmanifest"></a>2.1.4.3 Pr&uuml;fung eines XMLDSIG-Manifests </h4>
<h5>Request</h5>
<p>Dieses Beispiel zur Pr&uuml;fung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.XMLDSigManifest.xml" target="_blank"><code>VerifyXMLSignatureRequest.XMLDSigManifest.xml</code></a>) demonstriert die Pr&uuml;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&uuml;ckt und gek&uuml;rzt wurde.</p>
<pre>
@@ -892,7 +907,7 @@ positive Ganzzahl repr&auml;sentiert, die auf das beinhaltende <code>dsig:Manife
&lt;/VerifyXMLSignatureResponse&gt;
</pre>
<p>Das Element<code> CertificateCheck</code> enth&auml;lt das Resultat der Zertifikatspr&uuml;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&auml;nzungsobjekte </h4>
+<h4><a name="webservice_xmlrequests_pruefungxml_ergaenzungsobjekte"></a>2.1.4.4 Erg&auml;nzungsobjekte </h4>
<p>Dieses Beispiel zur Pr&uuml;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&auml;nzungsobjekten. Ein Erg&auml;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&uuml;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&ouml;st werden kann. Das Erg&auml;nzungsobjekt enth&auml;lt dann genau diese Daten die nicht von MOA SS aufgel&ouml;st werden k&ouml;nnen.</p>
<p>Bitte beachten Sie, dass der dargestellte Request zur bessernen Lesbarkeit einger&uuml;ckt und gek&uuml;rzt wurde.</p>
<pre>
@@ -960,7 +975,7 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.&lt;/doc:Paragraph&gt;
<p>Das zweite Element <code>SupplementProfile</code> enth&auml;lt analog das Erg&auml;nzungsobjekt f&uuml;r das oben beschriebene XML-Schema. <code>Content/@Reference</code> enth&auml;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&auml;her analysiert, da er keine f&uuml;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&uuml;fung einer XML-Signatur (<a href="../../clients/webservice/resources/requests/VerifyXMLSignatureRequest.SigManifest.xml" target="_blank"><code>VerifyXMLSignatureRequest.SigManifest.xml</code></a>) demonstriert die &Uuml;berpr&uuml;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&uuml;r die <code>dsig:Reference</code>-Elemente einer XML-Signatur. Mit Hilfe dieser Pr&uuml;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&uuml;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&auml;llen sinnvoll, in denen die Anwendung grunds&auml;tzlich mit XML-Daten arbeitet, diese Daten jedoch f&uuml;r das Signieren durch eine Person in ein f&uuml;r diese Person verst&auml;ndliches Format wie z.B. HTML umgewandelt werden sollen.</p>
<pre>
@@ -1139,28 +1154,23 @@ Ich habe weiters ein eigenens ID-Attribut bekommen.&lt;/doc:Paragraph&gt;
<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&auml;chst einmal ben&ouml;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&ouml;her; nicht n&ouml;tig wenn JDSE 1.4.2 oder h&ouml;her verwendet wird. </TD>
+ <TD>XML-Parser, Version 2.0.2 oder h&ouml;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&ouml;her; nur notwendig f&uuml;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.&lt;/doc:Paragraph&gt;
<li>Der zweite Kommandozeilenparameter enth&auml;lt Pfad und Dateiname einer Java-Properties-Datei, die die weiteren Konfigurationsparameter f&uuml;r den Webservice-Client enth&auml;lt. Ein relativer Pfad wird als relativ zum Arbeitsverzeichnis der Java Virtual Machine interpretiert. Genaue Infos zu den m&ouml;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&auml;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 &uuml;ber HTTPS.</p>
-<p>Die Konfiguration von JSSE (Speicher f&uuml;r die vertrauensw&uuml;rdigen Serverzertifikate, Typ dieses Speichers, Passwort f&uuml;r diesen Speicher) wird mittels zus&auml;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&auml;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&uuml;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 &uuml;ber HTTPS.</p>
+<p>Die entsprechende Konfiguration (Speicher f&uuml;r die vertrauensw&uuml;rdigen Serverzertifikate, Typ dieses Speichers, Passwort f&uuml;r diesen Speicher) wird mittels zus&auml;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&auml;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&uuml;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 &uuml;ber HTTPS.</p>
-<p>Die gegen&uuml;ber <a href="#webservice_clients_httpsserverauth">Abschnitt 2.2.3</a> zus&auml;tzlich notwendige Konfiguration von JSSE (Speicher f&uuml;r das SSL-Client-Zertifikat sowie den dazugeh&ouml;rigen privaten Schl&uuml;ssel, Typ dieses Speichers, Passwort f&uuml;r diesen Speicher) wird mittels zus&auml;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&auml;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 &uuml;ber HTTPS.</p>
+<p>Die gegen&uuml;ber <a href="#webservice_clients_httpsserverauth">Abschnitt 2.2.3</a> zus&auml;tzlich notwendige Konfiguration (Speicher f&uuml;r das SSL-Client-Zertifikat sowie den dazugeh&ouml;rigen privaten Schl&uuml;ssel, Typ dieses Speichers, Passwort f&uuml;r diesen Speicher) wird mittels zus&auml;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&auml;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&ouml;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.&lt;/doc:Paragraph&gt;
<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.&lt;/doc:Paragraph&gt;
<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>&nbsp;</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>
-