Policy Limitations
This topic describes known limitations of the policy implementation within the Web Services Enhancements for Microsoft .NET (WSE).
Policy Limitations
- No dynamic mechanism is provided for SOAP senders to retrieve a Web service's policy
WSE 2.0 does not provide a built-in mechanism for policy discovery, such as that described in the WS-MetadataExchange specification. For more information about retrieving a Web service's policy, see Getting a Web Service's Policy
- Policy files are not validated on application startup
WSE does not attempt to validate the policy for an endpoint when the application is started. Therefore, when a policy file contains a set of policy assertions for an endpoint that could never be satisfied, WSE will not generate an error or SOAP fault until a SOAP message is sent or received. For example, when the policy for an endpoint requires that SOAP requests must not contain UsernameToken security tokens and that SOAP requests must be signed using UsernameToken security tokens, no exception is raised. Instead, SOAP messages sent to the endpoint are rejected as not satisfying the policy.
- Policy is not enforced for intermediaries
If SOAP messages contain an intermediary destination, WSE only enforces the policy for the ultimate destination.
- Policy cannot specify whether a message can be signed or encrypted first
When the policy for an endpoint requires that outgoing SOAP requests are both signed and encrypted, WSE does not allow you to specify whether WSE signs or encrypts the SOAP message first.
- Policy does not verify that a KerberosToken security token matches the specified service principal name
During policy verification of incoming SOAP messages, WSE does not verify that a KerberosToken security token matches the specified service principal name. However, the service principal name is enforced for outgoing SOAP messages during policy enforcement.
- <OneOrMore> is the only supported operator within the <TokenInfo> Element and <KeyInfo> Element (WSE for Microsoft .NET) (1) elements
The <OneOrMore> operator allows you to specify multiple ways to satisfy a policy assertion. For example, a <OneOrMore> operator within a <TokenInfo> Element element can specify a set of security tokens that can be used to sign a SOAP message. WSE throws a fault if a SOAP message is received for a policy file that contains any other operator within the <TokenInfo> Element and <KeyInfo> Element (WSE for Microsoft .NET) (1) elements. For an example of how to use the <OneOrMore> operator, see the code example in the <Policy> Element (WSE for Microsoft .NET) (1) topic.
- Multiple <MessageParts> elements within policy operators are not supported
Multiple <MessageParts> Element for <Integrity> Element elements may appear, and they will be concatenated. However, multiple <MessageParts> elements within operators will result in an error.
- The URI attribute of the <Algorithm> element is required
WSE requires that the <Algorithm> Element for <Integrity> element have a Uniform Resource Identifier (URI) attribute.
- SOAP faults are thrown during policy verification or enforcement
WSE throws one of the following exceptions during policy verification or enforcement: PolicyVerificationException, PolicyEnforcementException, PolicyParserException, and PolicyDocumentException. This is not the complete list of SOAP faults that are specified in the WS-Security specification and it is not possible to return custom SOAP faults using policy.
- Supported values for the Usage attribute on policy assertions are Required and Rejected
WSE only supports the Required and Rejected values for the Usage attribute on policy verification of incoming SOAP messages. For policy enforcement of outgoing SOAP messages, Required is the only supported value. Any policy assertion with a Usage attribute set to Rejected is ignored for policy enforcement.