WS-Policy Driven Architecture
The WS-Policy specification describes how Web services can publish requirements and validate messages against those requirements. This goes beyond Web services Description Language (WSDL) that describes only wire-format. A policy might explicitly reject messages based on content or make certain message parts optional. WS-Policy provides a general XML grammar for describing policy assertions. Other specifications, such as WS-PolicyAssertions and WS-SecurityPolicy, provide specific applications of this grammar for their domains. WSE 2.0 provides rich support for WS-SecurityPolicy as will be demonstrated in this article.
WSE 2.0 automatically generates XML policy files that can contain WS-Policy descriptions for one or more Web service endpoints. This policy XML is used by the WSE run time to validate incoming messages (for example, to ensure that the message is properly signed), and to apply policies to outgoing messages (for example, to encrypt responses). XML policy is also used to publish policy information to calling clients. When WSE 2.0 is enabled for a client application, the run time can apply policy to outgoing messages, and validate messages returning from a Web service invocation.
This is all automatically handled by a set of pipeline filters included in the Microsoft.Web.Services.Policy namespace. PolicyVerificationInput and PolicyEnforcementOutput filters ingest policy XML to verify and enforce policy for incoming and outgoing messages, which means that we write less code. So, although the industry has yet to formally include WS-Policy within a standards organization, the application of WS-Policy at the tool level makes it possible for tools like WSE to automate policy-driven behavior.
WS-PolicyAttachments is a related WS-Policy specification for that describes how policies can be bound to WSDL or published through a UDDI interface. This part of the WS-Policy specification is not supported by tools today, so supplying Web service clients with a policy document is currently a manual process.
Support for OASIS WS-Security
WSE 1.0 supported a few core facets of the initial WS-Security specification; we were able to sign and encrypt messages with username token or digital signatures. Now that the WS-Security specification has stabilized and OASIS (Organization for the Advancement of Structured Information Standards) has it under its wing, we need an updated tool to support additional token formats, secure conversations, and to expose policy bindings as specified in the WS-SecurityPolicy specification.
One of the primary goals of the WS-Security specification is to provide an open specification that can support cross-platform security tokens and encryption standards. WSE 2.0 still supports username and X.509 tokens, but also adds support for Kerberos, security contexts compliant with WS-SecureConversation and WS-Trust, and extensibility to support XrML and SAML for single sign-on solutions.
I will show you how to apply several features of the specification for business scenarios that require a layered approach to Web services security. By the end of this article, you'll know how to apply WSE 2.0 to achieve the following results in a single solution:
- Identify application users for audit trail and authorization
- Control message privacy with encryption
- Verify message integrity by ensuring a trusted source
- Prevent message replay attacks
I'll also show you how much you can automate with WS-Policy support and where you have to write some code to fill in the missing pieces.