Policy standards

The web technical community groups, W3C and OASIS, have created standards to service the requirement to define the policy applicable to Web services.

Examples of specifications that define domain-specific policy assertions: For more information about WS-MediationPolicy, see ftp://public.dhe.ibm.com/software/solutions/soa/pdfs/WSMediationPolicy1.6-20120124.pdf.
The WS-Policy Data Model includes:
The following example, Figure 1, shows a security policy expression using assertions defined in WS-Security and WS-SecurityPolicy:
Figure 1. Use of Web Services Policy with security policy assertions.
(01) <wsp:Policy
   xmlns:sp=http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
   xmlns:wsp=http://www.w3.org/ns/ws-policy
   xmlns:wsu=http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
   wsu:Id="SecureMessages">  <!-- policy expression -->
(02)   <wsp:ExactlyOne>
(03)     <wsp:All>    <!-- policy alternative #1 -->
(04)       <sp:SignedParts>;   <!-- policy assertion -->
(05)         <sp:Body>   <!-- policy assertion parameter --> 
(06)       </sp:SignedParts>
(07)     </wsp:All> 
(08)     <wsp:All>    <!-- policy alternative #2 -->
(09)       <sp:EncryptedParts> <!-- policy assertion -->
(10)         <sp:Body/>   <!-- policy assertion parameter -->
(11)       </sp:EncryptedParts> 
(12)     </wsp:All> 
(13)   </wsp:ExactlyOne> 
(14) </wsp:Policy>

Lines (03-07) represent one policy alternative for signing a message body.

Lines (08-12) represent a second policy alternative for encrypting a message body.

Lines (02-13) show the ExactlyOne policy operator. Policy operators group policy assertions into policy alternatives. A valid interpretation of the policy above would be that an invocation of a Web service will either sign or encrypt the message body, but not both.

Figure 2 shows a policy definition.
Figure 2. Overview of Policy structureInside a policy definition, conditions, schedules, and actions are listed within the <wsmp:Rule> and </wsmp:Rule> tags. Conditions are optional can be listed between the <wsmp:Condition> and </wsmp:Condition> tags. Schedules are optional and can be listed between the <wsmp:Schedule> and </wsmp:Schedule> tags within the Condition tags. Actions follow the conditions, and can be listed between the <wsmp:Action> and </wsmp:Action> tags.

Policy Attachment

The Policy Attachment Document role is to associate a set of WS-Policy policies with a specific service attachment point for enforcement such as a Web Services attachment point.
For example, the Web Services platforms can support attachment points based on:
  • WSDL Element URI 1.1 elements
  • WS-Addressing elements
The syntax is defined in the WS-PolicyAttachment specification:
Figure 3. WS-PolicyAttachment specification
<wsp:PolicyAttachment>
    <wsp:AppliesTo>


    </wsp:AppliesTo>
    <wsp:Policy>


    </wsp:Policy>
</wsp:PolicyAttachment>

WSRR exposes REST interfaces to acquire the appropriate policy attachments in an SLA model. Information on the Consumer-Provider pair to which the policy applies is passed to the ESB in WS-PolicyAttachment format. The syntax is defined in the WS-PolicyAttachment: Message Content Filters specification.

The policy can be specified for a provider service only, for a specific consumer-provider pair, or for Anonymous consumers. Anonymous consumers provide a way of defining a default policy that only applies to consumers for which no other policies apply.

In Figure 3, the domain-specific policy subject to which the policy applies (the provider) is contained in the <wsp:AppliesTo> section followed by the consumer-context filter to which the policy applies (consumer). Then, in the <wsp:Policy> section, the policy or policies are declared or referenced.


Concept Concept

Feedback

Timestamp icon Last updated: Thursday, 3 July 2014
http://publib.boulder.ibm.com/infocenter/prodconn/v1r0m0/topic/com.ibm.scenarios.soawdpwsrr.doc/topics/csoa2_SOA_policystandards.htm