Web Services Security and More: The Global XML Web Services Architecture (GXA), Page 2
Policy-Related Extensions to WS-Security: WS-SecurityPolicy
In message exchange, it would be very advantageous if the "sender" Web service knew what the "receiver" Web service required or expected regarding items such as token types, or what portions of a message must be signed or encrypted. This is addressed by the WS-SecurityPolicy specification, released in December by 2002 by Microsoft, IBM, Verisign, and RSA Security.
WS-SecurityPolicy builds on WS-Security by defining how to describe policies related to various features defined in the WS-Security specification, and is therefore considered an "addendum" to the WS-Security specification. It defines several types of policy assertions that represent an individual preference, requirement, capability, or other property of a Web service. The following are examples of the types of policy assertions that are specified by WS-SecurityPolicy:
- SecurityToken Assertion: Specifies security token types required/accepted by a Web service.
- Integrity Assertion: Specifies that specific portions of a message must be signed, and specific algorithms/keys to be used (for example, the SHA-1 algorithm and the RSA key).
- Message Age Assertion: Specifies the acceptable time period before messages are declared "stale" and discarded.
XML Example: SecurityToken Assertion
The following example illustrates a "SecurityToken" assertion that specifies that the Web service accepts X.509 certificates for authentication (the "Preference" attribute will be described later in this article):
<wsse:SecurityToken TokenType="wsse:X509v3" wsp:Usage="wsp:Required" wsp:Preference="50"/>
The WS-SecurityPolicy specification can be found at http://msdn.microsoft.com/ws/2002/12/ws-security-policy.
Expressing Enterprise Security Policies: WS-Policy
Policy assertions by themselves cannot be acted upon. Rather, they need to be aggregated into units called policy expressions, which are then used as a framework for the creation of policies. This is the focus of the WS-Policy specification, released in December by 2002 by Microsoft, IBM, BEA Systems, and SAP.
WS-Policy describes a policy hierarchy whose base is a policy assertion, and which contains the following components:
- Policy Statement: A group of policy assertions.
- Policy: A set of domain-specific policy statements.
- Policy Expression: An XML serialization that represents one or more policy statements.
The figure below represents the above concepts in a graphical form:
XML Example: Policy Expression
The following example illustrates a policy expression that uses "SecurityToken" assertions:
<wsp:Policy> <wsp:ExactlyOne> <wsse:SecurityToken TokenType="wsse:X509v3" wsp:Usage="wsp:Required" wsp:Preference="50"/> <wsse:SecurityToken TokenType="wsse:Kerberosv5TGT" wsp:Usage="wsp:Required" wsp:Preference="10"/> </wsp:ExactlyOne> </wsp:Policy>
In the above example, the <wsp:ExactlyOne> element (known as a "policy operator") indicates that a valid policy that is constructed from this policy expression can contain any (but not more than one) of the assertions listed in the policy expression. That is, a Web service that uses the above policy expression to construct a policy can accept either X.509 certificates or Kerberos tickets for authentication. Additionally, the "preference" of this policy is that an X.509 certificate is used for authentication, due to its higher "Preference" value of 50.
In addition to the "ExactlyOne" policy operator, values of "All" (all child elements must be satisfied) or "OneOrMore" (at least one of the child elements must be satisfied) may be used.
The WS-Policy specification can be found at http://msdn.microsoft.com/ws/2002/12/Policy.
Message-Related Assertions: WS-PolicyAssertions
There are additional types of assertions specified within GXA that are not directly related to security, but rather to aspects such as character encoding, natural (spoken) language, and specification versions. These types of assertions are described in the WS-PolicyAssertions specification, released in December by 2002 by Microsoft, IBM, BEA Systems, and SAP.
WS-PolicyAssertions specifies policy assertions such as the following:
- TextEncoding Assertion: Indicates which character encodings (for example, ISO-8859-1, UTF-8, and UTF-16) are supported by a Web service.
- Language Assertion: Specifies supported (spoken) natural languages.
- SpecVersion Assertion: Indicates which versions of a specification a Web service supports.
- MessagePredicate Assertion: Expresses predicates (pre-conditions) to which a message must conform.
XML Example: TextEncoding Assertion
The following example illustrates a "TextEncoding" assertion that specifies that the Web service supports the ISO-8859-5 character set:
<wsp:TextEncoding wsp:Usage="wsp:Required" Encoding="iso-8859-5"/>
XML Example: MessagePredicate Assertion
The following example illustrates the use of the "MessagePredicate" assertion to express that messages to which this assertion applies must contain exactly one WS-Security <Security> header element:
<wsp:MessagePredicate wsp:Usage="wsp:Required"> count(wsp:GetHeader(.)/wsse:Security) = 1 </wsp:MessagePredicate>
In the above example, the "wsp:GetHeader (node)" function is one of several normative functions for use with XPath defined in the WS-PolicyAssertions specification. It returns the SOAP envelope <Header> element from the specified Envelope element. The following are some of the other functions that are specified:
- wsp:IsInHeader (node): Returns true if the specified node is in the SOAP envelope <Header> element from the specified Envelope element.
- wsp:IsMandatoryHeaderBlock (node): Returns true if the specified node is in the SOAP envelope <Body> element from the specified Envelope element.
- wsp:IsRoleURIForUltimateReceiver (node, string): Returns true/false depending on whether or not the specified role maps to the predefined "ultimate receiver" for the version of SOAP used by the supplied message.
XML Example: Policy Expression
Finally, the following example illustrates a policy expression that includes the two assertions shown above:
<wsp:Policy> <wsp:All> <wsp:TextEncoding wsp:Usage="wsp:Required" Encoding="iso-8859-5"/> <wsp:MessagePredicate wsp:Usage="wsp:Required"> count(wsp:GetHeader(.)/wsse:Security) = 1 </wsp:MessagePredicate> </wsp:All> </wsp:Policy>
The WS-PolicyAssertions specification can be found at http://msdn.microsoft.com/ws/2002/12/PolicyAssertions.
Policies Applied: WS-PolicyAttachment
Now we begin to answer the question: How can all of the policy concepts presented above be associated with Web service definitions such as those described by WSDL and UDDI? This is the focus of the WS-PolicyAttachment specification, released in December by 2002 by Microsoft, IBM, BEA Systems, and SAP.
WS-PolicyAttachment describes three specific "attachment mechanisms" for using policy expressions with existing XML Web service technologies:
- How to reference policies from WSDL definitions
- How to associate policies with specific instances of WSDL services
- How to associate policies with UDDI entities
XML Example: WSDL Endpoint
WS-PolicyAttachment defines a <wsp:PolicyAttachment> element to associate a policy expression with a resource, independently of the definition and/or representation of that resource. In the following example, a policy expression is associated with a WSDL endpoint.
<wsp:PolicyAttachment> <wsp:AppliesTo> <wsp:EndpointReference> <wsp:ServiceName Name="InventoryService"/> <wsp:PortType Name="InventoryPortType"/> <wsp:Address URI="http://www.xyz.com/acct"/> </wsp:EndpointReference> </wsp:AppliesTo> <wsp:PolicyReference Ref="http://www.xyz.com/acct-policy.xml"/> </wsp:PolicyAttachment>
In the above example, the policy expression referred to in the <wsp:PolicyReference> element will apply to all output resources of a service that implements the "InventoryPortType" portType on the "InventoryService" service located at address http://www.xyz.com/acct.
Additionally, policy expressions can be associated with wsdl:message and wsdl:part elements, for more "granular" policy attachment.