This parser shows how to use the generic Policy implementation to read, process, and decide on policies. The generic Policy implementation provides the framework to read, normalize, merge, and intersect policies. The generic implementation follows the specifications laid down in the document Web Services Policy Framework.

The Parser for Web Services Security Policy Language uses the generic policy implementation to read, normalize, and merge Web Service Sercurity policy files. The parser then parses and processes the specific Web Services Security Policy assertions. The document Web Services Security Policy Language defines the specific Web Service Security Policy assertions.

This is an example and the parser provides a skeleton for further development. Currently the processing methods of all assertions return true, that is every assertion is accepted.

Prerequisties

To be able to run the generic Policy implementation and the associated examples you need several additonal Jar files from the current Axis2 development because some examples use the StAX API and the OM XML datamodell implemented in Axis2. Currently you need In addition you also need the ubiquitous log4j, junit and commons-logging jars. At least this is the enviroment I currently use. For the Axis2 files you may use the according *SNAPSHOT.jar files as well.

How does it work

The main class is WSSpolicyProcessor. At first it populates the top level token with all security policy tokens/assertions known at the top level. All tokens/assertions are pre-initialized in the SecurityPolicy class file. We always use copies of the pre-initialized token structures. During setup the parser initializes the top level tokens with the objects that contain the processing methods for the tokens.

There are two types of security policy tokens: simple tokens and complex tokens. Simple tokens stand for themself and do not contains subtokens or assertions. Simple tokens switch on properties of define a specific behaviour. Complex token contain other tokens and assertions. At the top level we only have complex tokens (refer to the setup method).

When the parser finds a security policy assertion (PrimitiveAssertion) it starts a policy transaction (startPolicyTransaction). The start policy transaction checks if the current token contains this assertion as a child assertin. If the parser finds the assertion it sets up the parser context and calls the assertion's processing function. The processing functions use the following naming pattern: use the token's name and prepend this name with the string do. For example: the processing method of the X509Token has the name doX509Token. Each processing function of a complex token initializes its child tokens on the first call of the processing function (lazy initialization).

If all children of an assertion/token are processed the policy transaction is either committed or aborted depending on the outcome of the processing of the child tokens. During commit transaction the information gathered during the processing of the child tokens can be check, validated, and mixed with other data. These functions are not implemented in this example. If a transaction has to be aborted you can perform some cleanup.

All policies are parsed recursively. If a policy containes alternatives the first alternative that matches or can be processed is chosen.

Missing stuff

As noted before this is an example and provides some ideas how to implement a security policy parser. Not all top level tokens are implemented as processors (all assertions/tokens are pre-initialized in SecurityPolicy). The following processors are currently missing: @since Parser for Web Services Security Policy Language 1.0