Browse Prior Art Database

WS-Policy Enforcement in a distributed Web Services processing system Disclosure Number: IPCOM000191157D
Original Publication Date: 2009-Dec-18
Included in the Prior Art Database: 2009-Dec-18
Document File: 3 page(s) / 73K

Publishing Venue



A method is disclosed to allow distributed nodes forming a single Web Services processing end point to enforce WS-Policy[1] constraints. This method allows such constraints to be enforced even in cases where the individual nodes do not have the capability to act on the full set of desired constraints. This is achieved by having each node derive and propogate a set of WS-Policy assertions which represent the most specific Policy which could result in the message being processed by this node and any such assertions received from previous nodes in the distributed end point. The final node in the endpoint can then perform complete WS-Policy enforcement checking despite not having dealt with (or seen) the message constructs or elements that embody the Policy assertions handled by previous nodes.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 56% of the total text.

Page 1 of 3

WS-Policy Enforcement in a distributed Web Services processing system

A method is disclosed to allow distributed nodes forming a single Web Services processing end point to enforce WS-Policy[1] constraints.


    WS-Policy[1] provides a standard mechanism for a Web Services Provider to describe these functional and non-functional requirements and capabilities.

    In general WS-Policy is used by a Web Services provider to communicate these requirements to a requester and sometimes by a requester to validate that a given provider meets some level of required behaviour.

    An additional use is for a provider to police (enforce) that the requester has in fact sent a message that conform to one of the valid combinations of policy assertions. In particular these assertion sets can be made up of assertions taken from a number of different problem spaces (i.e. Security assertions & transaction assertions). A requester must only satisfy these assertions in the allowed combinations.

    Where the provider is entirely implemented within a single system this is (relatively) straight forward. A WS-Policy Agent in that system can collect together a view of the assertions and validate it against the Policy for the given service/operation/etc before allowing the request to continue. A growing pattern for Web Service implementations, however, involves distributing the responsibility for certain types of processing of the message across specialist nodes and systems. A good example of this would be using a specialist node to implement WS-Security processing before connecting on to a application owning system to process the WS-AtomicTransactions headers and the main business logic.

    The standard pattern used here is to treat the service exposed by the initial provider as different from that in the second. In terms of WS-Policy enforcement this is problematic as each distinct service has it's own policy to check and relationships between these Policy Assertions (combinatorial ones) cannot be tested against or enforced.

    A standard (non-distributed) Policy enforcement algorithm works by building a single assertion set which matches the implied Policy used by the client (i.e A & B) and then tests to see if it intersects with the policy set allowed for this Service/Operation (i.e A&C, A&D). (In this case (A &C , is not allowed so the request should be rejected). Full details of Policy matching in this fashion are found in the WS-Policy[1] and related specifications.

WS-Policy Enforcement in a distributed end point:

    The method disclosed allows this checking to be done where the end point is comprised of multiple distinct processing nodes. These nodes are distinct in that they do not share any out of band data on a per-request basis.

    To allow this Policy enforcement each system involved in acting as the distributed Service Provider has...