WS-Policy


Mit der Spezifikation WS-Policy können Richtlinien bezüglich Sicherheit oder auch Qualität von WebServices bereitgestellt werden. Dabei realisiert eine sogenannte Policy welche Anforderungen an die Interaktion der Anbieter des Services vorsieht. So kann diese beispielsweise eine Verschlüsselung der Informationen vorsehen oder aber auch die Zusicherung, innerhalb von einer gewissen Zeitspanne zu antworten.

Nachfolgend wir ein kleiner Überblick über die verwendete Terminologie im Zusammenhang mit WS-Policy gegeben:
  • Policy: Eine Policy ist eine Menge (kann auch leer sein) von Policy Alternatives
  • Policy Alternative: Eine mögliche leere Menge von Policy Assertions
  • Policy Assertion: Repräsentiert eine Anforderung, eine Fähigkeit oder eine andere Eigenschaft eines Verhaltens
  • Policy Assertion Type: Eine Klasse von Policy Assertions und impliziert ein Schema für die Assertion und Assertion-spezifischer Semantiken.
  • Policy Vocabulary: Eine Reihe von allen in der Policy genutzen Policy Assertion Types
  • Policy Subject: Eine Entität (z.B. Endpoint, Nachrricht, Ressource) mit der eine Policy assoziiert werden kann

Assertions

Wie aus der oberen Terminologie bekannt, stellt eine Assertion eine Anforderung oder auch eine Fähigkeit dar. Policy Assertions sind typ-gebunden und werden allein über ihren qualifizierenden Namen (Qname) identifiziert, mit Ausnahme möglicher geschachtelten Kind Policy Expressions (nested policy expressions). Diese Tatsache spielt insbesondere bei der Policy Intersection eine Rolle. Bevor wir aber auf die Policy Intersection kommen, muss man sich erst einmal die Normalform und Kompaktform von Policies anschauen.

Normalform und Kompaktform

Policies können in zwei Formen vorliegen: in der Normalform oder in der Kompaktform. Wie die Bezeichnung schon andeutet, ist die Policy in der Kompaktform tatsächlich kürzer als in der Normalform.

Um Interoperabilität zu erreichen wurde die Normalform spezifiziert. Ihr Schema sieht dabei folgendermaßen aus:

(01) <wsp:Policy ... >
(02) <wsp:ExactlyOne>
(03) ( ( <Assertion ...> ... </Assertion> )* </wsp:All> )*
(04) </wsp:ExactlyOne>
(05) </wsp:Policy>

Die Normalform beinhaltet also alle Policy Wrapper-Elemente und hat ein ExactlyOne Child-Element. Dieses wiederum hat entweder keines oder mehrere All-Kindelemente. Jedes dieser All-Elemente hat wiederum keine oder mehr Policy Assertions.

Die Kompaktform stellt eine Policy kompakter dar wie die Normalform und muss eben nicht dem oberen Schema der Normalform entsprechen. Sie erlaubt alle gültigen Schachtelungen von Operatoren. Darüber hinaus gibt es mit wsp:Optional ein weiteres Attribut mit dem man festlegen kann, dass eine Asertion optional ist. Man kann jederzeit eine Kompaktform in die Normalform überführen (normalisieren).

Normalisierung

Mit der „Normalisierung“ kann eine Policy von der Kompaktform in die Normalform umgewandelt werden. Benötigt wird die Normalform beispielsweise für die Operationen „Schnitt“ (Intersection) und „Verschmelzung“ (Merge) Im ersten Schritt der Normalisierung löst man erst einmal alle evtl. vorhandene „wsp:Optional“-Attribute der Kompaktform auf. Anschließend können im zweiten Schritt die Policy Operatoren zusammengelegt werden. Durch Transformationsgesetze werden dabei die Policy Operatoren von innen nach außen rekursiv zusammengelegt. Am Ende gibt es nur noch ein wsp:Exactly One Operator.

Schnitt (Intersection

Beim „Schnitt“ wird aus zwei Policies durch einen Vergleich eine Policy. Ziel ist es dabei, alle gemeinsamen Policy Alternativen zu ermitteln. Nötig ist das beispielsweise dann, wenn unterschiedliche Parteien ihre Policies auf gemeinsame kompatible Policy Alternnatives einzuschränken versuchen. Grundlage hierfür ist, dass alle Policies in Normalform vorliegen. Dementsprechend wird auch das Ergebnis normalisiert sein. Anschließend wird festgestellt, welche Policy Alternativen zueinander kompatibel sind. Dabei verfolgt der Schnittprozess dem Muster des kartesischem Produkts, in dem jede Policy Alternative aus der einen Policy mit jeder anderen Policy Alternativen aus der anderen Policy verglichen wird. Eine Voraussetzung, dass die beiden Policy Alternatives zueinander kompatibel sind, ist das sie das gleiche Vokabular besitzen. So werden die Qnames von beiden Policy Assertions verglichen, gibt es eine Übereinstimmung, werden die Policy Alternativen zueinander hinzugefügt. Ist dies nicht der Fall, funktioniert auch der Schnitt nicht. Als Resultat kann die durch den Schnitt entstandene Policy Alternative mehrere Instanzen des gleichen Types besitzen.

Verschmelzung (Merge)

Das Verschmelzen läuft ähnlich ab wie der „Schnitt“. Bei der Merge-Operation muss allerdings nicht geprüft werden, ob die Policy Alternativen überhaupt zueinander kompatibel sind. Auch nach dem Grundprinzip des kartesischen Produkts wird bei den zwei normalisierten Policies jeweils jede Policy Alternative aus der einen Policy mit jeder anderen Policy Alternativen aus der anderen Policy vereinigt und bildet so zusammen eine neue Policy Alternative, in der alle Policy Assertions aus den beiden Policy Alternativen enthalten sind. Hat Policy A also n Policy Alternatives und Policy B m Policy Alternatives, dann hat die neue Policy m x n Policy Alternatives.

Policy Referenzierung

Auf Policies kann auch referenziert werden. Das ermöglicht einen modularen Aufbau, bei dem eine sehr große Policy in mehreren kleineren Policies aufgeteilt werden kann, um anschließend auf diese zu referenzieren. Das erhöht die Wiederverwendbarkeit und Wartbarkeit der Policies. Dabei kann die referenzierte Policiy entweder im gleichen Dokument wie du referenzierende Policy liegen oder aber auch in einem separaten Dokument. Je nach Fall, muss die URI entsprechend angepasst werden. Das Schema lautet dabei folgendermaßen:

(01) <wsp:PolicyReference
(02) URI="xs:anyURI"
(03) ( Digest="xs:base64Binary" ( DigestAlgorithm="xs:anyURI" )? )?
(04) ... >
(05) ...
(06) </wsp:PolicyReference>


Quellen:



Artikel vom 09.06.2014

Kommentare zum Artikel

comments powered by Disqus