Norm 270 Abbildung von Individualitäten

Transkript

1 1 Norm 270 Abbildung von Individualitäten 2 3 Release und Version Release 1, Version 1.0, vom 19. Juni Status Offizielle Norm 6 7 Editor Thomas Belting, RheinLand Gruppe Autoren Markus Heussen, RheinLand Gruppe (markus.heussen@creditlife.net) Marc Pellmann, inubit AG (marc.pellmann@inubit.com) Sascha Klose, VHV Versicherung (sklose@vhv.de) Dr. Dieter Ackermann, VOLKSWOHL BUND (dieter.ackermann@volkswohl-bund.de) Dr. Thomas Kippenberg, Nürnberger (thomas.kippenberg@nuernberger.de) Dr. Torsten Schmale, inubit AG (ts@inubit.com) Jörg Treiner, IDEAL Gruppe (treiner@ideal-versicherung.de) Stefan Hauptmann, VDV Klaus Reimer GmbH (stefan.hauptmann@v-d-v.de) John Bodenstein, AssFiNET AG (john.bodenstein@assfinet.de) Sören Chittka, VOLKSWOHL BUND, (soeren.chittka@volkswohl-bund.de) Thomas Belting, RheinLand Gruppe, (thomas.belting@rheinland-versicherungen.de) Gegenstand der Norm Die Norm 270 definiert wie BiPRO-konforme Schnittstellen die Individualitäten von Service Providern abbilden können und welche technischen Mechanismen hierbei verwendet werden müssen. Neben Individualitäten im zu übertragenden Datenmodell und damit verbundenen Plausibilitäten werden auch Festlegungen hinsichtlich Ausprägung des angebotenen Security Token Service eines BiPRO-konformen Service Porviders definiert Voraussetzung Norm 210, Release 1 Version 2 Norm 260 Release 1 Version 4 - Seite 1 von 17 -

2 Hinweis zur Veröffentlichung Die anliegend überreichte Norm ist urheberrechtlich für die BiPRO geschützt. Das Dokument wird Ihnen im Rahmen Ihrer Mitgliedschaft bei der BiPRO und damit als Mitglied dieses geschlossenen Empfängerkreises überlassen. Dementsprechend stellt die Überlassung an Sie keine Erstveröffentlichung der Norm dar. Zur Erstveröffentlichung gegenüber Dritten bleibt somit die BiPRO alleine berechtigt. Die Veröffentlichung erfolgt gemäß Norm100. Aufgrund der besonderen Wertigkeit der Normen für die Mitglieder sind wir gehalten, Verstöße gerichtlich zu ahnden Seite 2 von 17 -

3 41 Inhaltsverzeichnis Norm 270 Abbildung von Individualitäten... 1 Inhaltsverzeichnis... 3 Allgemeines... 4 Redefinition eines BiPRO-Standards... 4 Template xsd:redefine... 4 Template xsd:complextype... 5 Bildung von BiPRO-Standards über Redefinition... 6 Service Policies... 8 Inhaltsbezogene Policies Security Policy des Security-Token-Service Security Policy der Business-Services Seite 3 von 17 -

4 Allgemeines Redefinition eines BiPRO-Standards Ein Service Provider hat im Regelfall Bedarf, individuelle Erweiterungen am Standard vorzunehmen. Die Ursachen sind verschiedene. Für diese Fälle sieht die BiPRO eine Möglichkeit vor, diese Individualitäten standardisiert zu beschreiben. Hierfür wird das Element xsd:redefine der XML Schema-Spezifikation verwendet. Das Schema, das die zu erweiternden Objekte enthält, DARF NICHT über xsd:include, sondern MUSS mittels xsd:redefine in das Provider-spezifische Schema eingeladen werden Beispiel <xsd:schema... <xsd:include schemalocation= /> <xsd:include schemalocation= /> <xsd:redefine schemalocation= > <!-- Objekte definieren, die zu erweitern sind -->... </xsd:redefine>... </xsd:schema> Template xsd:redefine Alle Objekte, die im Kontext des Elementes xsd:redefine beschrieben werden, werden um die hier beschriebenen Merkmale erweitert. Die Redefinition eines Objektes MUSS unter Anwendung des folgenden Templates erfolgen. Hierdurch wird das Standard-Objekt um die Objekt-Eigenschaft ${X3}Erweiterung ergänzt. Diese Objekt-Eigenschaft verweist wiederum auf das eigentliche individuelle Objekt, dass alle Attribute definiert, die vom Standard abweichen. <xsd:redefine schemalocation= ${X1} > <xsd:complextype name= ${X2} > <xsd:complexcontent> <xsd:extension base= bipro:${x2} > <xsd:sequence> <xsd:element name= ${x3}erweiterung type= bipro:${x2}erweiterung /> </xsd:sequence> </xsd:extension> </xsd:complexcontent> </xsd:complextype> - Seite 4 von 17 -

5 </xsd:redefine> Variable Wert ${X1} Absoluter Pfad auf das einzuladene BiPRO Standard-Schema, z.b. ${X2} Name des Standard-Objektes (definiert im eingeladenen Schema), das individuell erweitert werden soll, z. B. CT_Produkt. HINWEIS: Im Abschnitt xsd:redefine können beliebig viele Objekte redefiniert werden. ${X3} wie ${X2}, jedoch ohne den Prefix CT_; z.b. Produkt Template xsd:complextype Während einer Redefinition wird also das Standard-Objekt der BiPRO um eine Eigenschaft ergänzt, die selbst ein individuelles Objekt darstellt. Dieses individuelle Objekt MUSS anschließend (außerhalb des Kontextes der xsd:redefine-anweisung) mit den üblichen Standard-Templates der BiPRO zur Bildung von Objekten definiert werden Beispiel <xsd:schema... <xsd:include... <xsd:redefine </xsd:redefine> <xsd:complextype name= CT_ProduktErweiterung > <xsd:sequence> <xsd:element name= Paket type= bipro:st_produktpaket /> </xsd:sequence> </xsd:complextype> <xsd:simpletype name= ST_Produktpaket > <xsd:restriction base= xsd:string > <xsd:enumeration value= 1 > <xsd:annotation> <xsd:documentation xml:lang= de > Standard</xsd :documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value= 2 > <xsd:annotation> - Seite 5 von 17 -

6 <xsd:documentation xml:lang= de > Plus</xsd :documentation> </xsd:annotation> </xsd:enumeration> </xsd:restriction> </xsd:simpletype>... </xsd:schema> Bildung von BiPRO-Standards über Redefinition Neben der Individualisierung von BiPRO-Standards auf Seiten der Service Provider MUSS die Redefinition auch bei der Bildung von BiPRO-Schemas im Rahmen der TAG Interaktion angewendet werden. Hintergrund: Die FAG Datenmodellierung sieht im Daten- bzw. Objektmodell Beziehungen zwischen allgemeinen und kontextspezifischen (z. B. spartenspezifischen) Objekte vor. Die technische Realisierung SOLLTE dieser fachlichen Kategorisierung folgen. Folgt sie dieser, so MUSS eine Splittung der in XML Schema realisierten Objekte in verschiedene Schema-Dateien erfolgen. Die Beziehungen zwischen den Objekten stellten hier zunächste ein Problem dar, das über die Anwendung einer Redefinition gelöst werden konnte Beispiel Das Objekt Produkt gehört fachlich in die Kategorie der allgemeinen Objekte und befindet sich damit in der XML Schema-Datei bipro-objekte-allgemein-x.x.xsd. Dieses Objekt hat Beziehungen zu spartenspezifischen Objekten wie z. B. zum Objekt VersichertePerson. Dieses Objekt ist jedoch in der spartenspezifischen XML Schema-Datei bipro-objekteunfall-x.x.xsd definiert. Laut Norm MUSS jedes XML Schema unabhängig von anderen Schemas sein und damit für sich gesehen die Eigenschaften wellformed und valid erfüllen. Hierfür MUSS folgende Verfahrensweise angewendet werden: Definition eines abstrakten Objektes Damit das allgemeine XML Schema trotz der Beziehung zu Objekten, die in einem externen Schema definiert wurden, gültig ist, MÜSSEN die Objekte des allgemeinen Schemas, die eine Beziehung zu kontextspezifischen Schemas haben, als abstrakte Objekte definiert werden. <complextype name="ct_produkt" abstract="true" final="restriction"> <annotation> <documentation xml:lang="de">produkt</documentation> </annotation> <complexcontent> <extension base="bipro:ct_produktbaustein"> <sequence> - Seite 6 von 17 -

7 </extension> </complexcontent> </complextype> <element name="sparte" type="bipro:st_sparte" minoccurs="0"> <annotation> <documentation xml:lang="de">sparte</documentation> </annotation> </element> Ableitung des abstrakten Objektes und Bildung einer Beziehung Das kontextspezifische XML Schema bipro-objekte-unfall-x.x.xsd MUSS nun über die Anwendung einer Redefinition das abstrakte Objekt zu einem nicht abstrakten festlegen und damit das abstrakte Objekt zu einem für den Nachrichtenaustausch einsetzbaren Objekt gestalten. In dem konkreten Objekt kann jetzt die Beziehung zu einem Objekt in einem externen Schema bzw. zu einem kontextspezifischen XML Schema angelegt werden. <complextype name="ct_produkt" abstract="false" final="restriction"> <complexcontent> <extension base="bipro:ct_produkt"> <sequence> <element name="versicherteperson" type="bipro:ct_versicherteperson" maxoccurs="unbounded"> </element> </sequence> </extension> </complexcontent> </complextype> Seite 7 von 17 -

8 186 Service Policies Der generelle Ansatz der BiPRO besteht darin, die größtmögliche Festlegung der Prozessschnittstelle zu erreichen und zugleich die notwendigen VU-spezifischen Erweiterungen oder Präzisierungen zu ermöglichen (wie sie z.b. für VU-spezifische Tarife etc. benötigt werden) dies ist einer der fundamentalen Unterschiede zu Standards wie GDV und anderen, die eine Einheitlichkeit über alle VUs erzwingen Das allgemeine BiPRO Schema besteht daher überwiegend aus einer Vielzahl von Optionen, die in sich verbindlich sind, wenn sie denn von einem VU benötigt werden. Diese VU- Individualitäten werden durch Policies eindeutig zum Ausdruck gebracht und sind, dann verbindliche Bestandteile einer BiPRO-konformen VU-Schnittstelle Dieser Mechanismus der Präzisierung von VU-Individualitäten gilt sowohl für inhaltliche Objekte, Attribute und Beziehungen (Inhaltliche Policies) als auch für die tatsächlich unterstützten bzw. benötigten Authentifizierungsmechanismen (Security Policies) eines VUs Eine Policy konkretisiert damit eine BiPRO-konforme Schnittstelle. Ohne diese Konkretisierung ist eine BiPRO-konforme Schnittstelle in der Regel unvollständig und damit auch nicht verwendbar. Der in der BiPRO verwendete Policy-Mechanismus ist konform zu den WebService-Basisstandards und Bestandteil der WSDL-Datei der WebService-Schnittstelle eines VUs. Eine VU-spezifische Policy ist damit auch für den Consumer zugänglich und maschinell verarbeitbar In einer BiPRO-konformen Implementierung von BiPRO-Normen MUSS ein Service Consumer die Policy des Providers hinreichend berücksichtigen. Ein Service Provider SOLLTE vor der Verarbeitung eines WebService-Requests eine Validierung des definierten Schemas als auch der definierten Policy durchführen Policy-Bestandteile einer BiPRO-konformen VU-Schnittstelle wirken sich daher auch direkt oder indirekt auf die GUI einer Service Consumer Implementierung aus. Sie wirken sich jedoch genauso auf eine rein maschinelle Imlementierung eines Service Consumers aus, d.h. eine Implementierung ohne GUI und direkte Benutzerinteraktion WS-Policy beschreibt Anforderungen, Fähigkeiten und Zusicherungen eines Web Services. Dies kann etwa bedeuten, dass ein Web Service nur eingehende Anfragen akzeptiert, wenn diese eine bestimmte Authentifizierung enthalten oder ein spezifisches Inhaltselement - Seite 8 von 17 -

9 vorhanden ist. Die Spezifikation WS-PolicyAttachment spezifiziert, wie die Policies mit der WSDL Servicebeschreibung verknüpft werden können. In diesem Dokument wird definiert welche Art der Verknüpfung von der BiPRO verwendet wird Die eigentlichen Assertions, welche verwendet werden können, sind wiederum in weiteren Spezifikationen wie WS-SecurityPolicy und WS-PolicyAssertions definiert. Die für die BiPRO relevanten Assertions werden in diesem Dokument dargestellt Es werden folgende Web Service Standards verwendet um die Serviceanforderungen über Policies zu beschreiben: WS-Policy (Version 1.2) WS-PolicyAttachment (Version 1.2) WS-SecurityPolicy (Version 1.1) WS-PolicyAssertions (Version 1.1) Policies MÜSSEN auf oberster Ebene der WSDL des Services definiert werden. Diese Policies MÜSSEN dann an den Stellen innerhalb der WSDL referenziert werden auf die sie sich beziehen sollen. Die Policies die sich auf die im BiPRO Standard definierten Services beziehen MÜSSEN unterhalb des Binding-Element (wsdl:binding) referenziert werden Die generelle Struktur innerhalb einer WSDL ist damit wie folgt: <wsdl:definitions xmlns:wsp="${x1}" xmlns:sp="${x2}"> ${X3}... <wsdl:binding> <wsdl:operation> <wsdl:input>${x4}</wsdl:input> <wsdl:output>${x4}</wsdl:output> <wsdl:fault>${x4}</wsdl:fault> </wsdl:operation> </wsdl:binding> 243 Variable Wert ${X1} Namespace WS-Policy - Seite 9 von 17 -

10 ${X2} Namespace WS-SecurityPolicy ${X3} Policy Definition siehte unten ${X4} Binding Point für implementierungsabhängige Policies Inhaltsbezogene Policies Inhaltsbezogene Einschränkungen für VU-Individualitäten MÜSSEN mit diesen Policies dargestellt werden. Der Name dieser Policy-Assertion ist MessagePredicate. Angegeben wird ein XPath, welcher einen Wahrheitswert zurück liefert Innerhalb der BiPRO MUSS immer die Methode wsp:body() verwendet werden um sich auf den Body-Teil der Nachricht zu beziehen. 250 Folgende XPath-Ausdrücke dürfen in BiPRO-konformen Policies verwendet werden: XPath Typ Erläuterung 1 Zweck Ein optionales Element aus dem Schema wird zu einem Pflichtelement. Syntax wsp:body()/a/b/c/d GUI Das Element wird als Pflichtfeld gekennzeichnet und muss ausgefüllt werden. 2 Zweck Ein optionales Element aus dem Schema wird verboten. Syntax not(wsp:body()/a/b/c/d) GUI Das Element wird in der Maske nicht dargestellt. 3 Zweck analog #1 und #2 um mehrere Objekte zu erreichen. Syntax wsp:body()/*/*/b/c bzw. not(wsp:body()/*/*/b/c) GUI siehe #1 und #2 - Seite 10 von 17 -

11 4 Zweck analog #3 aber nur auf einige Elemente beschränkt Syntax wsp:body()/*/*[local-name()="c" or local-name()="b"]/d/e GUI analog #3 5 Zweck Einschränkung von Wertelisten, die in einem Element erlaubt sind Syntax wsp:body()/a/b/c/d[.="01" or.="02"] GUI Die Werteliste enthält nur die in der Policy angegebenen Werte aus der Grundgesamtheit 6 Zweck Einschränkung von Wertelisten, die in einem Element erlaubt sind (über Negativauswahl) Syntax not(wsp:body()/a/b/c/d[.="01" or.="02"]) GUI Die Werteliste enthält die Werte aus der Grundgesamtheit abzüglich der angegebenen Werte. 7 Zweck Wertelisten auf bestimmte Werte oder gar keinen Wert einschränken Syntax wsp:body()/a/b/c[.="030 or.="040"] or not(wsp:body()/a/b/c) GUI Die Auswahlbox erhält neben den Werten (030,040) noch eine weitere Auswahl, die für die Nichtauswahl steht. 8 Zweck Beschränkung der Kardinalität von Elementen Syntax count(wsp:body()/a/b/c)=1 GUI Es darf nur genau ein Element davon angezeigt werden 9 Zweck Ein optionales Element aus dem Schema wird, in Abhängigkeit der Auswahl in der Werteliste eines anderen Elements, zu einem Pflichtelement. - Seite 11 von 17 -

12 Syntax wsp:body()/a/b[c/d="09"]/e GUI Das Element wird als Pflichtfeld gekennzeichnet und muss ausgefüllt werden. 10 Zweck Ein optionales Element aus dem Schema wird, in Abhängigkeit der Auswahl in der Werteliste eines anderen Elements, verboten. Syntax not(wsp:body()/a/b[c/d="09"]/e) GUI Das Element wird in der Maske nicht dargestellt Standardmäßig sind die <wsp:messagepredicates> in einer Policy logisch UND verknüpft (entsprechend <wsp:all>). Sollen zwei der vorstehend definierten XPATH-Ausdrücke über ODER miteinander verknüpft werden, so MUSS dies in der Policy mittels <wsp:exactlyone> wie folgt durchgeführt werden: <wsp:exactlyone> <wsp:messagepredicate>/a/b/c[.="030 or.="040"]</wsp:messagepredicate> <wsp:messagepredicate>not(/a/b/c)</wsp:messagepredicate> </wsp:exactlyone>... Eine mehrstufige Verschachtelung von <wsp:exactlyone> und <wsp:all> ist im Rahmen der BiPRO NICHT erlaubt Beispiel einer Positiv-Policy: <wsp:policy wsu:id="erforderlicheattribute"> <wsp:messagepredicate> wsp:body()/bipro:getquote/bipro:request/bipro:tarifierung/bipro:tarifinfo/bipro:gebaeud e/bipro:wohnflaeche </wsp:messagepredicate> <wsp:messagepredicate> wsp:body()/bipro:getquote/bipro:request/bipro:tarifierung/bipro:tarifinfo/bipro:gebaeud e/bipro:bauartklasse </wsp:messagepredicate> Beispiel einer Negativ-Policy: <wsp:policy wsu:id="verboteneattribute"> - Seite 12 von 17 -

13 <wsp:messagepredicate> not(wsp:body()/bipro:getquote/bipro:request/bipro:tarifierung/bipro:nummervu) </wsp:messagepredicate> <wsp:messagepredicate> not(wsp:body()/getquote/bipro:request/bipro:tarifierung/bipro:nummervm) </wsp:messagepredicate> Referenzierung der Policies in den WSDL Elementen: <wsdl:binding name="tarifierungbinding" type="bipro:tarifierungporttype"> <soapbind:binding style="document" transport=" <wsdl:operation name="getquote"> <soapbind:operation soapaction="" style="document"/> <wsdl:input name="getquoterequest"> <wsp:policyreference URI= #VerboteneAttribute /> Hinweise zur Verarbeitung auf Provider-Seite: In der Serververarbeitung dienen die inhaltsbezogenen Policies zur zusätzlichen Validierung der eingehenden Nachrichten. Über die XML-Schema Validierung hinaus kann auf die VU- individuellen erforderlichen Felder und die verbotenen Felder geprüft werden. 296 Hinweise zur Verarbeitung auf Consumer-Seite: Dem Consumer wird über die Policies mitgeteilt welche im XML-Schema als optional gekennzeichneten Datenfelder, Wertebereiche und Kardinalitäten er für diesen Provider liefern muss, darf bzw. welche nicht geliefert werden dürfen. Diese Informationen SOLLTEN schon innerhalb des GUI-Clients ausgewertet werden, um die entsprechenden Felder ein- bzw. auszublenden, um die Eingabe von Requestdaten bzw. Ausgabe von Responsedaten übersichtlich und intuitiv zu gestalten und Fehleingaben zu verhindern. Der jeweilige XPath der Policy kann dabei als Identifier des Feldes betrachtet werden Wird der Client dynamisch (Generischer Client) aus dem Schema und den Policies erstellt, kann bei jedem Feld, das aus der Hierarchie des XML Schema erstellt wird, noch einmal gegen den XPath der Policy geprüft werden. In Abhängigkeit vom Ergebnis ist dann das jeweilige Feld mit in den Client aufzunehmen oder wegzulassen bzw. um Abhängigkeiten der Felder in der Dynamik des Clients umzusetzten Gemäß der Spezifikation WS-PolicyAssertions 1.1 (Kap. 3.4 Message Predicate Assertion) können der Assertion MessagePredicate optional zusätzlich spezifizierte Elemente - Seite 13 von 17 -

14 mitgegeben werden. Um einem Client die dynamische Interpretation der Policies zu ermöglichen, KANN es sinnvoll sein der inhaltsbezogenen Policy-Assertion (MessagePredicate) das optionale BiPRO Fehler Attribut bipro:annotation zuzuweisen. Hinweis: Das optionale BiPRO Fehler Attribut bipro:annotation ist nicht Bestandteil der BiPRO Schema Definition. <wsp:policy wsu:id="erforderlicheattribute"> <wsp:messagepredicate bipro:annotation="bei der Antragserstellung ist bei der Zahlungsart Lastschrift die Angabe der Kontonummer erforderlich."> wsp:body()/*/*/bipro:antrag[bipro:zahlungsart ="1"]/*[local-name()="Person" or local-name()="juristischeperson"]/bipro:bankverbindung/bipro:kontonummer </wsp:messagepredicate> Security Policy des Security-Token-Service Zur Spezifikation, welche Authentifizierungsverfahren erlaubt sind um ein SecurityContext- Token beim STS eines spezifischen Providers zu beziehen, werden Security Policies eingesetzt. Die Security-Policy des STS MUSS unter Anwendung des folgenden Templates beschrieben und innerhalb der WSDL-Datei zum Service veröffentlichet werden Das folgende Template zeigt eine Policy, die alle vier verschiedenen Authentifizierungsmethoden (Username-Passwort, Username-Passwort-OTP, X509 Token und VDG-Ticket) unterstützt. Je nach Provider können dies auch weniger sein, es MUSS jedoch mindestens eine der möglichen BiPRO Authentifizierungsarten angegeben werden. <!-- Policy fuer STS, der alle vier BiPRO Authentifizierungsverfahren unterstuetzt--> <wsp:exactlyone> <wsp:all> <!-- Definition des Transportbindings als HTTPS --> <sp:transportbinding> <sp:transporttoken> <sp:httpstoken RequireClientCertificate="false"/> </sp:transporttoken> </sp:transportbinding> <!-- Definition der moeglichen Tokens, je nach Anbieter auch nur einer - Seite 14 von 17 -

15 Teilmenge derselben--> <sp:supportingtokens> <wsp:exactlyone> <!-- Authentifizierung mit Username und Passwort --> <wsp:all> <sp:usernametoken wsu:id="biprobasictoken"/> </wsp:all> <!-- Authentifizierung mit Username, Passwort und Token --> <wsp:all> <sp:usernametoken wsu:id="biprootptoken"/> </wsp:all> <!-- Authentifizierung mit X509 Zertifikat --> <wsp:all> <sp:x509token sp:includetoken=" ystorecipient"> <sp:wssx509v3token11/> </sp:x509token> </wsp:all> <!-- Authentifizierung mittels VDG Ticket --> <wsp:all> <sp:issuedtoken> <sp:issuer> <wsa:address>${x1}</wsa:address> </sp:issuer> </sp:issuedtoken> </wsp:all> </wsp:exactlyone> </sp:supportingtokens> </wsp:all> </wsp:exactlyone> Die Unterscheidung, ob ein UsernameToken ein One-Time-Password enthalten soll, wird über das Attribut wsu:id getroffen. Dieser Umweg ist derzeit nötig, da die Spezifikation WS- Security-Policy derzeit keine Methoden anbietet, exlipizit die geforderten Claims zu spezifizieren. Variable Wert ${X1} URL des zugehörigen Providers im Fall eines VDG-Tickets - Seite 15 von 17 -

16 Die Referenzierung im binding Element erfolgt mit: <wsdl:binding> <wsp:policyreference URI="#BiPROAuthSecurityPolicy" /> <wsdl:operation.../> </wsdl:binding> Security Policy der Business-Services Die Sicherheitsanforderung des jeweiligen BiPRO Services MUSS ebenfalls durch eine Policy definiert werden, die festlegt, dass ein SCT übertragen werden muss. Der SCT MUSS vom STS stammen. Die Angabe eines Issuers ist nötig, da ein Provider evtl. verschiedene STS zur Verfügung stellt. <!-- Policy fuer Business Service --> <wsp:policy wsu:id="biprosecuritypolicy"> <wsp:exactlyone> <wsp:all> <!-- Definition des Transportbindings als HTTPS --> <sp:transportbinding> <sp:transporttoken> <sp:httpstoken RequireClientCertificate="false"/> </sp:transporttoken> </sp:transportbinding> <!-- Definition der Anforderung an ein SecurityContext Token --> <sp:supportingtokens> <sp:secureconversationtoken sp:includetoken=" ystorecipient"> <sp:issuer> <wsa:address>${x2}</wsa:address> </sp:issuer> </sp:secureconversationtoken> </sp:supportingtokens> </wsp:all> </wsp:exactlyone> - Seite 16 von 17 -

17 431 ${X2} Adresse des STS, der das benötigte SecurityContext-Token austellt Die Referenzierung im binding Element erfolgt mit: <wsdl:binding> <wsp:policyreference URI="#BiPROSecurityPolicy" /> <wsdl:operation.../> </wsdl:binding> Hinweis: Der Name der Policy (SecureConversationToken) ist missverständlich, da er die Anforderung nach einem SecureConversation-Token suggeriert. Tatsächlich entspricht die Policy jedoch der Anforderung nach einem SecurityContext-Token unter Angabe des Issuers Anmerkung: WS-SecureConversation begreift ein SCT als einen Kontext, der Informationen zur Sicherung (Verschlüsselung) der Nachricht enthalten kann. Im Kontext der BiPRO wird das SCT lediglich als ein Identifier verwendet. - Seite 17 von 17 -