Working with OWSM Policies – Part 1 of some

In this post I discuss the available options to work with OWSM (Oracle Web Services Manager) policies in JDeveloper and Enterprise Manager. OWSM is a component available along with the Oracle SOA Suite and provides policy enforcement point (PEP) agents for SOAP-based messages.

Typically, a service policy is attached to a service endpoint to enforce some pre-defined rules (like enforcing a SAML token, Kerberos token, message confidentiality, SSL, etc). And a corresponding client policy is attached to the client in order to transform the outgoing SOAP message, making it suitable to be enforced in the server side.

OWSM Policies in JDeveloper

OWSM supports two types of repositories for its policy files: file system or database.
When working with JDeveloper, you can choose which one you want to use.
By default, JDeveloper reads policies from the file system. To check that out, go to Tools –> Preferences –>WS Policy Store (on left).



The File Store Default Location refers to DefaultDomain oracle/store/gmds directory under $JDEV_USER_DIR’s systemxx.x.x.x.xx.xx.xx folder. Policies are under owsm/policies and assertions are under owsm/assertiontemplates.



The App Server Connection option actually refers to a running Weblogic instance that ultimately gets the policies from a database.

Development groups working with custom policies may like the idea of having policies defined in a central location so that everyone can be sure to work against the very same version of policies. The drawback is that you’ll need that server up and running all the time.

When working with SOA and web services, JDeveloper exposes OWSM policies graphically so they can be picked up with a single click. A description of what the policy does is also shown. I strongly recommend reading it, since it can clarify many questions you might have about the policy. If you're writing a web service proxy and wants to attach a policy, there is no UI and you should know the policy name. Speaking of names, one good aspect is that OWSM policies are named in a very intuitive way. For example, wss11_saml_token_with_message_protection_client_policy says that it is a client policy implementing message protection for SAML 1.1 tokens. In other words, it adds an encrypted and signed SAML 1.1 token to the outgoing SOAP message.

OWSM Policies in Enterprise Manager

JDeveloper is not the single option for policy attachment. Organizations may decide to take such task off developers hands and defer it to sysadmins. That's accomplished with Enterprise Manager. You navigate to the attachment point and simply pick the policy you want. Policy enforcement starts immediately.

Besides that, Enterprise Manager provides some very convenient ways for working with policies.
There’s a “Create Like” option serving as a template mechanism. During policy creation, you can change several attributes of the original policy as well as add, change or remove specific assertions. By the way, a policy is composed of one or more assertions, who are the ones that actually do the “heavy-lifting”, containing the necessary logic to deal with the SOAP message.

By saving the policy, it gets persisted into the policy repository.

You then have the option to export it to a file. This is useful if you want to consume it directly from the file system (as JDeveloper does by default) and want to add your own assertion implementation class (which is typically the case when you’re developing a custom policy).

When exporting the file, notice that Enterprise Manager messes up with the file name a bit, by changing the “/” (slash) symbol following the “oracle” prefix to an “_” (underscore). You must rename the file, by cutting “oracle_” off the file name. Then simply copy the file to the oracle folder under the gmds/owsm/policies folder mentioned before.



If you want to separate out the custom files from the ones shipped by Oracle, you can even create a new folder under gmds, say “custom”, and put your custom policy there. JDeveloper will automatically acknowledge that.

Another very interesting feature I should mention is that Enterprise Manager implements a web service client, allowing  OWSM policies to be tested. For example, let's say you develop a pair of policies to implement WSS digest-based authentication. Upon attaching the service-side policy to your deployed web service, you should be able to use EM's testing page to attach the client-side policy to the outgoing SOAP message and verify if your policies are ok.

Next time I will cover how to write custom OWSM policies, including the main java APIs developers should be aware of.