Java web services: Modeling and verifying WS-SecurityPolicy

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

The SymmetricBinding.AssertionHandler inner class defines the set of token roles defined for the <sp:SymmetricBinding> and also implements the VerificationHandler.complete() method to check that at least one type of token is present and no conflicting tokens are present. (<sp:SymmetricBinding> allows either an <sp:ProtectionToken>, with is used for both signing and encrypting messages, or separate <sp:EncryptionToken> and/or <sp:SignatureToken>s.)
BindingAssertionHandler, shown in Listing 5, is a common base for handling verification of all three types of binding assertions (transport, asymmetric, and symmetric). These each define one or more marker assertions, one or more token roles, a required <sp:AlgorithmSuite>, and an optional <sp:Layout> (the last two being assertions with child marker assertions but no nested policy).

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

Listing 5. BindingAssertionHandler
public class BindingAssertionHandler extends VerificationHandlerBase { /** Names of marker elements allowed in <TransportBinding>. */ public static final Set<String> TRANSPORT_BINDING_MARKERS = VerificationHandlerUtils.buildNameSet("IncludeTimestamp"); /** Names of marker elements allowed in ... or <SymmetricBinding>. */ public static final Set<String> ENCRYPTION_BINDING_MARKERS = VerificationHandlerUtils. buildNameSet("IncludeTimestamp|...|OnlySignEntireHeadersAndBody"); /** Actual element name. */ private final String m_elementName; /** Roles allowed for tokens. */ private final Set<String> m_tokenRoles; /** Token properties for binding. */ private final Map<String,TokenProperty> m_roleTokens; /** Marker assertions allowed in policy. */ private final Set<String> m_knownMarkers; /** Marker token assertions. */ private final Map<String,ExtensibleMarker> m_nameMarkers; ... protected BindingAssertionHandler(String name, Set<String> roles, Set<String> markers) { m_elementName = name; m_tokenRoles = roles; m_roleTokens = new HashMap<String,TokenProperty>(); m_knownMarkers = markers; m_nameMarkers = new HashMap<String,ExtensibleMarker>(); } ... public void addMarker(ExtensibleMarker marker, ValidationContext vctx) { String name = marker.getName(); if (m_knownMarkers.contains(name)) { // generate warning for duplicate assertion VerificationHandlerUtils.checkRepeat(marker, m_nameMarkers, vctx); } else { vctx.reportError("Assertion not allowed as child of sp:" + m_elementName, marker); } } public void addGeneral(AssertionBase asser, ValidationContext vctx) { if (asser instanceof TokenProperty) { TokenProperty token = (TokenProperty)asser; String name = token.getName(); if (m_tokenRoles.contains(name)) { TokenProperty prior = m_roleTokens.get(name); if (prior == null) { m_roleTokens.put(name, token); } else { vctx.reportError("Duplicate token ", asser); } } else { vctx.reportError("Token not allowed as child of sp:" + m_elementName, asser); } } else if (asser instanceof AlgorithmSuite) { ... } else { vctx.reportError("Assertion not allowed as child of sp:" + m_elementName, asser); } } public boolean complete(ValidationContext vctx) { if (m_algorithmSuite == null) { vctx.reportError("Missing required sp:AlgorithmSuite property", this); return false; } else { return true; } }}

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

Both Listing 4 and Listing 5 use a VerificationHandlerUtils.buildNameSet() to construct a set of names from a string value. This method breaks the input string at | (pipe) characters to find the individual names to be added to the set, resulting in much more concise code than if the names were passed individually. The sets of names are then used to check assertions allowed in the nested policy.
Unmarshalling the model
The use of multiple namespaces with basically the same data creates some major problems for XML data binding. Most data binding tools could only deal with these multiple namespaces by creating separate sets of classes for each namespace. JiBX data binding can do better, by using multiple bindings to the same classes. Each binding can use the same element names for each class, but in a different namespace.
The loose structure of WS-Policy and WS-SecurityPolicy also causes problems for data binding, but here again JiBX can cleanly handle the data with a little added effort. JiBX supports user extension code for unmarshalling (and marshalling) data structures that otherwise cannot be bound to XML. I used several custom unmarshallers to handle the WS-Policy and WS-SecurityPolicy data. Probably the most interesting one is OperatorUnmarshaller, used to unmarshal any of the WS-Policy operators and their child assertions. Listing 6 shows the code for this unmarshaller:

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

Listing 6. OperatorUnmarshaller
public class OperatorUnmarshaller implements IUnmarshaller, IAliasable { ... public boolean isPresent(IUnmarshallingContext ictx) throws JiBXException { UnmarshallingContext ctx = (UnmarshallingContext)ictx; ctx.toTag(); if (PolicyNamespace.LOOKUP.getNamespace(ctx.getElementNamespace()) != null) { String name = ctx.getElementName(); return "Policy".equals(name) || "ExactlyOne".equals(name) || "All".equals(name); } return false; } public Object unmarshal(Object obj, IUnmarshallingContext ictx) ... { if (isPresent(ictx)) { return unmarshalOperator((UnmarshallingContext)ictx); } else { return null; } } private OperatorBase unmarshalOperator(UnmarshallingContext ctx) ... { // create the instance to be returned NamespaceInfo ns = PolicyNamespace.LOOKUP. getNamespace(ctx.getElementNamespace()); if (ns == null) { throw new IllegalStateException("Internal error - ..."); } Policy policy = Policy.getNestedPolicy(ctx); PolicyNamespace prior = policy == null ? null : (PolicyNamespace)policy.checkNamespace(ns); Policy policy = Policy.getNestedPolicy(ctx); String name = ctx.getElementName(); OperatorBase operator; if ("Policy".equals(name)) { policy = new Policy(policy, ns); operator = policy; } else if ("ExactlyOne".equals(name)) { operator = new OperatorBase.ExactlyOne(ns); } else { operator = new OperatorBase.All(ns); } // check for namespace conflict if (prior != null && ns != prior) { ((ValidationContext)ctx.getUserContext()).reportError("Policy namespace " + ns.getUri() + " conflicts with containing policy namespace " + prior.getUri(), operator); } // track object and handle all attributes ctx.pushTrackedObject(operator); operator.readAttributes(ctx); ctx.nextToken(); // process all child elements while (ctx.toTag() == IXMLReader.START_TAG) { if (isPresent(ctx)) { // unmarshal child policy operator operator.getChildOperators().add(unmarshalOperator(ctx)); } else { String uri = ctx.getElementNamespace(); name = ctx.getElementName(); IUnmarshaller unmarshaller = ctx.getUnmarshaller(uri, name); if (unmarshaller == null) { // treat unmapped element from known namespace as marker assertion ns = policy.getNamespace(uri); if (ns != null) { operator.getChildAssertions().add (ExtensibleMarkerUnmarshaller.unmarshal(ctx, ns)); } else { // just use DOM for element from unknown namespace ... } } else { // unmarshal known child element as policy assertion Object object = unmarshaller.unmarshal(null, ctx); if (object instanceof AssertionBase) { operator.getChildAssertions().add((AssertionBase)object); } else { throw new JiBXException("Internal error - child element ..."); } } } } ctx.nextToken(); ctx.popObject(); return operator; }}

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

The IUnmarshaller interface only defines two methods: isPresent() to check if the current element start tag is handled by the unmarshaller, and unmarshal() to unmarshal the data from an element. In the Listing 6 code, the isPresent() method just checks if the current element namespace matches one of the WS-Policy versions, and then if the element name matches any of the three policy-operator names (Policy, ExactlyOne, or All).
The unmarshal() method is also simple, but only because it delegates all the work to the unmarshalOperator() method. unmarshalOperator() assumes that you're positioned at one of the policy-operator elements, and starts by creating an instance of the matching operator class using the appropriate WS-Policy namespace (verifying that the namespace used on this operator matches that on the containing <wsp:Policy> element, if any). It then executes a loop to unmarshal all child elements. There are four ways of handling child elements:

If the child is another policy operator, recursively call unmarshalOperator().
If there's an unmarshaller for this element (meaning the binding definition contains a mapping definition for the element), call that unmarshaller.
If the element namespace is recognized as a policy-extension namespace, unmarshal as an empty marker assertion.
Otherwise, just treat as an unclassified extension element and use a DOM representation.

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

The third option means that marker elements don't need to be named in the JiBX binding definitions, which helps keep the bindings relatively simple (and also don't require individual classes, which keeps the data structures relatively simple). These bindings do need to define JiBX mapping definitions for all the nonmarker assertions, though, and separate bindings must be used for each namespace. Listing 7 shows the top-level binding, containing common abstract mappings (not associated with any element name, and hence reusable across namespaces) for both WS-Policy and WS-SecurityPolicy:

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

Listing 7. Top-level unmarshal binding definition

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

Listing 8 shows a pair of the namespace version-specific bindings referenced by <include> elements in the Listing 7 binding, one for a WS-Policy namespace and one for a WS-SecurityPolicy namespace. These associate the namespace version-independent data model classes with element names in a particular namespace, while either passing the handling on to specific unmarshaller classes (in the case of the WS-Policy operator elements, the Listing 6 OperatorUnmarshaller class) or delegating to one of the abstract mappings from the Listing 7 binding.

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

Listing 8. WS-Policy and WS-SecurityPolicy unmarshal binding definitions

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

Even with JiBX, a fair amount of complexity is involved in unmarshalling WS-Policy and WS-SecurityPolicy documents. But the combination of binding definitions with user extension code for unmarshalling makes the task much easier than would be the case with data binding tools that take a more rigid approach to handling XML.