Policy standards

The web technical community groups, W3C and OASIS, created standards to define the policies 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.7-20130506.pdf.
The WS-Policy Data Model includes the following entities:
The following example, Figure 1, shows a security policy expression that uses 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 is that an invocation of a web service either signs or encrypts 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 that are 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 applies only 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. It is 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.soawdpwsrr25.doc/topics/csoa2_SOA_policystandards.htm