Java web services: Modeling and verifying WS-SecurityPolicy

justforregister · 发表于 2011-5-31 00:08

The Listing 1 policy document consists mostly of alternating layers of WS-Policy elements (only the <wsp:Policy> element, in this case) and WS-SecurityPolicy elements (using the sp prefix). Unfortunately, XML Schema is unable to represent this type of structure. Each schema definition deals with a single namespace, and although it can reference and use elements defined in another namespace, it cannot define a substructure for those elements. So the schema definition for WS-Policy can define a general structure, and the WS-SecurityPolicy schema can define elements intended to be used in combination with that structure, but there's no way to define the interactions between these two sets of elements.
Because XML Schema is unable to define the structure of documents, the text of the WS-SecurityPolicy standard uses the same syntax representation as the WS-Policy recommendation to show the intended structure of documents. Listing 2 shows a sample taken from the standard, for the <sp:SymmetricBinding> element used in Listing 1:

justforregister · 发表于 2011-5-31 00:08

Listing 2. WS-SecurityPolicy syntax sample
<sp:SymmetricBinding xmlns:sp="..." ... > <wsp:Policy xmlns:wsp="..."> ( <sp:EncryptionToken ... > <wsp:Policy> ... </wsp:Policy> </sp:EncryptionToken> <sp:SignatureToken ... > <wsp:Policy> ... </wsp:Policy> </sp:SignatureToken> ) | ( <sp:ProtectionToken ... > <wsp:Policy> ... </wsp:Policy> </sp:ProtectionToken> ) <sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite> <sp:Layout ... > ... </sp:Layout> ? <sp:IncludeTimestamp ... /> ? <sp:EncryptBeforeSigning ... /> ? <sp:EncryptSignature ... /> ? <sp:ProtectTokens ... /> ? <sp:OnlySignEntireHeadersAndBody ... /> ? ... </wsp:Policy> ...</sp:SymmetricBinding>

justforregister · 发表于 2011-5-31 00:08

The syntax used in Listing 2 should be fairly easy for most developers to understand: using parenthesis to delimit groupings, | characters to indicate choices between alternatives, and ? to indicate optional components. (The full syntax also uses * for zero or more occurrences, and + for one or more.) It's not a standard for XML grammars, though, so there's no way to use it directly to validate instance documents.
Structure errors
Given the complexity of WS-SecurityPolicy and the difficulty of checking documents against the standard, it's not surprising that one of the most common problems in working with documents is to add assertions at the wrong point. For instance, if you were to move the <EncryptedParts> element (near the end of Listing 1) inside the preceding <SymmetricBinding> element's Policy, you'd have a structure that doesn't match the WS-SecurityPolicy standard. The interpretation of this incorrectly structured policy would be undefined and at the whim of each web services stack — it might work as hoped on one, but would likely not be interoperable with other stacks.

justforregister · 发表于 2011-5-31 00:08

Web services stacks may or may not report structure errors to users. When I tried the above example of a misplaced EncryptedParts element with the latest versions of the three open source web services stacks (Apache Axis2 1.5.4, Metro 2.1, and Apache CXF 2.3.3) evaluated in earlier articles of this series, only Metro reported an error and refused to operate. Axis2 and CXF both accepted the policy without complaint but operated without encrypting the message bodies. This type of silent failure makes it hard to diagnose problems caused by policy structure errors.
Version conflicts
Namespaces are an especially messy issue with WS-Policy and WS-SecurityPolicy. The standardization of both WS-Policy and WS-SecurityPolicy took years, and earlier versions of the technologies became widely used before the standards were released. The official standards mostly follow the XML structure of the earlier versions but use different namespaces so that it's clear which set of rules apply to a particular document.

justforregister · 发表于 2011-5-31 00:08

Most tools support both the official recommendations and the earlier versions of WS-Policy and WS-SecurityPolicy, allowing the versions to be used interchangeably. (Axis2 is the exception, supporting only the submission version of WS-Policy as of the current 1.5.4 release.) Despitethis flexibility, using different namespaces within a single document can create problems. There's no reason to mix WS-Policy or WS-SecurityPolicy namespaces deliberately, but it can easily happen by accident when you're combining portions of other policies in order to construct a new policy. The resulting conflicts can include both the namespaces used for elements and, in the case of token-inclusion values, the actual text values. For instance, both WS-SecurityPolicy 1.2 and 1.3 use the value http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always to say that a token should always be included in messages. The older 1.1 version instead used the value http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always for the same purpose.
Because the meanings of XML elements are largely unchanged across versions of these standards, individual tools may choose to ignore the namespace differences when working with policy documents. Tools taking this approach will probably accept policies mixing namespaces, without any errors. In general, though, it's best to stay with the official recommendation namespace and, especially, to avoid mixing components from earlier namespaces with those from the recommendation namespace.

justforregister · 发表于 2011-5-31 00:09

Modeling WS-Policy and WS-SecurityPolicy
Modeling WS-Policy and WS-SecurityPolicy in the Java language presents an entirely different set of challenges from those involved in modeling WSDL 1.1, as discussed in "Understanding and modeling WSDL 1.1." Whereas the main issue with modeling WSDL is to allow for the many element-ordering variations in common use, WS-Policy and WS-SecurityPolicy ignore element ordering completely, instead providing a loose structure with many rules imposed on top. This means that the expected content of a <wsp:Policy> element (or any of the other WS-Policy operator variations) is completely dependent on the element's context. Listing 1 demonstrates this, with different content models for almost all of the 15 <wsp:Policy> elements in the document.

justforregister · 发表于 2011-5-31 00:09

Data model
WS-SecurityPolicy assertions are mostly of two types: marker assertions (empty elements), which just by their presence indicate some quality or feature; or structured assertions, with a nested policy containing other assertions. The structured assertions are where the complexity comes in, of course.
Handling for structured assertions builds on the model's NestedPolicy base class and the associated VerificationHandler interface, shown in Listing 3:

justforregister · 发表于 2011-5-31 00:09

Listing 3. NestedPolicy and VerificationHandler

public abstract class NestedPolicy extends AssertionBase { /** Nested policy definition. */ private Policy m_policy; /** Arbitrary extension elements. */ private List<Element> m_extensions = new ArrayList<Element>(); ... /** * Create a handler instance for a set of assertions. * * @return instance */ public abstract VerificationHandler createHandler(); /** * Verify policy goodness. This uses a handler supplied by the {@link * #createHandler()} method to verify all the assertions within the nested policy in * the context of this assertion. * * @param vctx */ public void verify(ValidationContext vctx) { for (Set<AssertionBase> asserts : m_policy.getAlternatives()) { VerificationHandler handler = createHandler(); for (AssertionBase asser : asserts) { if (asser instanceof ExtensibleMarker) { handler.addMarker((ExtensibleMarker)asser, vctx); } else { handler.addGeneral(asser, vctx); } } handler.complete(vctx); } }}public interface VerificationHandler{ /** * Add marker assertion. * * @param marker * @param vctx */ public abstract void addMarker(ExtensibleMarker marker, ValidationContext vctx); /** * Add general assertion (anything that's not a marker). * * @param asser * @param vctx */ public abstract void addGeneral(AssertionBase asser, ValidationContext vctx); /** * Check that the assertions included in this collection fulfill all requirements for * the policy. This method is only used when verifying a complete policy (one * particular combination of alternatives, when using alternatives). * * @param vctx * @return <code>true</code> if no errors, <code>false</code> * if error */ boolean complete(ValidationContext vctx);}

justforregister · 发表于 2011-5-31 00:09

All structured assertions extend the NestedPolicy class, implementing the createHandler() method to return an instance of the VerificationHandler interface tailored to the specific assertion structure. The VerificationHandler provides methods for accumulating and verifying the assertions contained within the nested policy, so that's where the details of the structured assertion handling are implemented. Where policy alternatives are present, the NestedPolicy.verify() method creates a separate VerificationHandler instance for each alternative.
Listing 4 and Listing 5 together show a concrete example of how this works, in the form of the classes used to represent and verify a SymmetricBinding assertion. The SymmetricBinding class shown in Listing 4 is pretty simple, just defining an inner class based on the BindingAssertionHandler class shown in Listing 5 for the verification handling:

justforregister · 发表于 2011-5-31 00:09

Listing 4. SymmetricBinding
public class SymmetricBinding extends NestedPolicy { public VerificationHandler createHandler() { return new AssertionHandler(); } private static class AssertionHandler extends BindingAssertionHandler { /** Containing element name. */ private static final String ELEMENT_NAME = "SymmetricBinding"; /** Names of allowed token role elements. */ private static final Set<String> TOKEN_ROLES = VerificationHandlerBase.buildNameSet("EncryptionToken|...|ProtectionToken"); protected AssertionHandler() { super(ELEMENT_NAME, TOKEN_ROLES, BindingAssertionHandler.ENCRYPTION_BINDING_MARKERS); } public boolean complete(ValidationContext vctx) { boolean good = true; Map<String, TokenProperty> tokens = getRoleTokens(); if (tokens.containsKey("ProtectionToken")) { if (tokens.containsKey("EncryptionToken")) { vctx.reportError("sp:ProtectionToken conflicts ...", this); good = false; } if (tokens.containsKey("SignatureToken")) { vctx.reportError("sp:ProtectionToken conflicts ...", this); good = false; } } else if (!tokens.containsKey("EncryptionToken") && !tokens.containsKey("SignatureToken")) { vctx.reportWarning("No tokens defined for binding", this); } return super.complete(vctx) && good; } }}