Thursday Jul 11, 2013

How To - OWSM 12.1.2 Installation

As I mentioned in my previous blog post FMW 12.1.2 was released today. There are a few things that are different in terms of installation for OWSM in 12.1.2 compared to 11g. So I have created a fairly detailed Install How-To with screen shots. This complements the 12.1.2 Install guide.

Note: The How To does not describe all scenarios/topologies. It is mainly intended for demo installs and to give you a quick overview of key steps.

Tuesday Apr 16, 2013

.NET interoperability, Kerberos, SPNEGO, Id Propagation - All things Microsoft! - OWSM 11g - Revisited

In a previous blog post - I briefly talked about interoperability with Microsoft and support for Kerberos, SPNEGO, NTLM, etc in OWSM. So I wanted to revisit that post and address a few aspects:

SPNEGO support

In that blog post - I mentioned that SPNEGO is something we don't support in OWSM.

In PS6 with the introduction of the support for REST security - we also added support for SPNEGO. While the key driver was REST services and securing REST services - we support SPNEGO policies for HTTP/SOAP services as well.

In fact one of things customers will notice is that many of the policies introduced for securing REST services are also supported for HTTP/SOAP web services.

SPNEGO support is documented here:

Note: OWSM still doesn't support NTLM.

Interoperability with Microsoft environments.

One of the most common questions from customers is around can we use SAML to do identity propagation b/w Microsoft and Oracle based environments and the use of ADFS as the STS for enabling SAML based identity propagation.

In PS6 - we have certified with ADFS ( in addition to the certification with Oracle STS, OpenSSO STS).

Client side Kerberos support

It appears that many people looked at the figures in the previous blog post and assume we don't support Kerberos on the client side in OSB. I just wanted to clarify that we do in fact support Kerberos policies on the client side - so for - you can do the following:

The key limitation is that you cannot use kerberos across multiple hops as I mentioned in the previous blog post. However you can definitely use Kerberos policies to secure your web services clients.

Friday Feb 15, 2013

Dynamic Policy Selection among alternatives - 11g - follow up

Just a couple of quick follow up points to my blog post on Dynamic Policy Selection.

First a shout out to Chris's blog post on this topic - I missed it since he blogged about it more than 2.5 years back! He is a doing a lot of creative things in that blog post. My post was more around what is supported by OWSM out of the box.

Second - a clarification - the Dynamic Policy Selection is supported only on the service side currently.

Thursday Feb 07, 2013

When to use Oracle STS (OSTS)?

I have been meaning to do a blog post on this front for quite sometime but just haven't had the cycles. So this a very rushed blog post - please excuse typos!!

The basic question that seems to come up is when to use an STS in general and OSTS in particular. So here are my thoughts on the matter.

To me there are - three main scenarios for using a STS:

  • Token Exchange/Conversion
  • Federation
  • Centralized Trust

In this post I will cover Token Exchange and Federation very briefly.

Token exchange/conversion

So the first set of scenarios is around the need to be able to exchange one kind of token with another type of token. Ex: You want to exchange a Kerberos Token with a SAML token. Here is a picture that demonstrates this scenario (click on the image for a large image):

STS Token Exchange Use-case

In the  above scenario a customer has a Desktop Application (ex: Say Outlook or some other .NET Web Service) that is talking to a backend Web Service let's say hosted on Oracle Fusion Middleware that can accept SAML Token.

User "joe" logs into his Desktop and a Kerberos Ticket is created. When user opens the Desktop application and performs an operation this results in a backend web service call and we want to propagate the identity of "joe" to the backend application. However the token we have is a Kerberos Token on the client side and the backend Web Service only accepts a SAML token. One can use an STS to do a token conversion or token exchange (assuming the STS is capable of such a conversion).

Web Service Federation

The second scenario where a STS is very useful and probably the most important scenario in my mind is when you need to do Federation. For those of you who are not familiar with Federation - I suggest reading up on Federation in general and Web Service Federation in particular. The picture below depicts this use-case.

STS - Federation Use-case

The use-case is similar to a Token Exchange use-case. We have a Desktop Application (say Outlook) that needs to invoke a backend Web Service. However the backend Web Service is running in the Cloud (Public or Private Cloud).

The key issue here is that the user "joe" is unknown in the Cloud.

There is a good reason why the user "joe" is unknown in the Cloud. Since an application running in the cloud may be used by multiple customers say "Acme Inc" or "Foobar Inc" both of which may user called "joe" the Cloud cannot have a single user named "joe" in it's Directory instead it would need to distinguish "Acme Inc" user "joe" (let's call him "acme.joe" ) from "Foobar Inc" user "joe" (let's call him "foobar.joe" ).

So now in the Cloud we actually have two users "acme.joe" and "foobar.joe" - so the Desktop Application (running within Acme Inc) needs to map "joe" to "acme.joe" - before it talks to the Cloud. This mapping is where an STS comes in handy! as shown in the picture.

So not only are we converting the token from Kerberos to SAML we are also now mapping "joe" to "acme.joe" in the STS.

  1. The picture depicts Oracle Public Cloud - but the concept applies to any Cloud (Public/Private) or in fact across Partner systems.
  2. The picture depicts Fusion CRM - but the concept applies to any Web Service
  3. I make no guarantees that what is shown in the picture above is necessarily what is implemented in the Oracle Public Cloud and I have used the example for purely illustrative purposes!

In a future blog post I will elaborate further on some of the scenarios and also the Centralized Trust scenario.

Finally - one last parting shot - the scenarios and use-cases for an STS and OSTS are fairly extensive and in this blog post - I am trying to illustrate some very simple scenarios. Please consult the Oracle STS documentation for all the features.

Tuesday Aug 14, 2012

Custom Assertion in OWSM - OES, OSDT (Oracle Security Developer Toolkit) & OWSM - 11g

Another quick note on OES, OSDT and OWSM. As I have mentioned in a previous post here, OWSM provides an Extensibility Guide that allows customers to build custom policies and custom assertions. 

So the question is: When should one have to build a custom assertion in OWSM 11g?

The short answer is when something is not supported in OWSM directly.

Here are a few scenarios:

a) If you want to build say OES integration for fine grained authorization based on content. OWSM in 11gR1 as of the writing of this post does not provide OES integration, but you can build an OES integration using the custom assertion support in OWSM 11g.

Here is an example that illustrates OWSM-OES integration using the custom assertion support in OWSM 11g. There is another example in the OWSM Extensibility Guide.

b) Another example would be - if you want to build OAuth support to secure your services with OAuth. OWSM 11g currently does not have OAuth support - but if you wanted to secure your services with OAuth - you could build a custom assertion to do the same.

c) Or you want to use a particular canoncalization method (ex:. The OOTB policies, assertion templates do not provide the flexibility of implementing your own canoncalization method) or want to use particular security transformations.

d) You wanted Liberty support in OWSM, etc.

In the rest of the post I will focus on building custom assertions that require a particular type of signing or encryption.

Custom Assertion, Signing, Encryption

Now one of things one has to worry about when building a custom assertion that deals with signing, encryption, etc is what XML security toolkit to use.

As you will notice - the OWSM Extensibility Guide does NOT provide any APIs that you can use for signing, encryption, etc.

The good news is you can use OSDT (Oracle Security Developer Toolkit) that actually exposes a lot of APIs to perform various XML security operations including signing, encryption, decryption, signature validation, etc.

Here are some doc pointers to OSDT:

Here are some OSDT javadocs:

Web Services Security:

XML Security:

JCE Crypto APIs:

SAML related APIs:

Liberty APIs :

Note: The combination of OSDT and OWSM Extensibility Guide provides you a really powerful APIs and toolkits to build various types of security policies that deal with either XML security or Web Services (SOAP) security.

WARNING: You really need to know what you are doing when using these APIs. These are fairly low level APIs and the docs expect the developer using these APIs to be extremely knowledgeable about security technologies and concepts and how to use the various low level building blocks.

Hopefully this provides some guidance on how one can use OWSM custom assertion and OSDT to build various types of policies in OWSM.

Sunday Jul 29, 2012

OPSS vs. OWSM 11g

Have been a bit busy and so blogging has been slow - but I recently came across this blog entry and I thought it would be worth clarifying about the relationship between OPSS and OWSM.

OPSS - Oracle Platform Security Services - provides a security framework and acts as the underlying security layer that addresses both FMW security requirements as well as the base for all the Identity and Access Management products.

Details can be found here.

There is a nice white paper accompanying the recent IDM 11gR2 release - that describes the foundational nature of OPSS. (Yet more material on IDM 11gR2 can be found here.)

The primary security services provided by OPSS include:

a) Authentication Services via Login Modules

b) Keystore Service

c) Credential Store Service - used for storing secrets like passwords (credentials).

d) Audit service

e) Authorization

OWSM is primarily focused on security for Web Services and provides a policy based security model. OWSM implements the various WS-* standards and  leverages OPSS authentication service, Keystore service, Audit service, credential store service, authorization service, etc.

Sunday Mar 18, 2012

How To - Securing a JAX-WS with OWSM Message Protection Policy in JDeveloper - 11g

As promised in this post, here is a How-To that describes how to secure a simple HelloWorld JAX-WS with OWSM message protection policy and test it with SOAP UI.

The How-To reuses the picture I posted earlier about the relationship and interplay b/w Keystore, Credential store, jps-config.xml ,etc.

One of the other more frequent requests I hear from folks within Oracle and customers is how to test OWSM with SOAP UI. SOAP UI in general works very well as testing tool for web services secure with wss10 policies.

Saturday Mar 17, 2012

Keystore and Credential Store interplay in OWSM - 11g

One of the most common problems faced by customer's is the use of the keystore and it's interplay with the credential store.Here is a picture that describes these relationships.(Click on the picture for a larger image). The picture makes some assumptions in describing the relationship. Some of assumptions are:

a) the key used for signing and encryption are the same.

b) A keystore can have multiple keys and each key can have it's own alias. In the picture I show only a single key with alias "orakey".

c) The keystore being described here is a JKS keystore. Things can vary slightly for other type of keystores.

I hope to have a detailed How To that provides the larger picture and then shows these relationships in that context and this picture was created in the context of that How-To. However I think people will find this picture useful on a standalone basis as well. The <serviceInstance> is the entry you will find in jps-config.xml

Keystore, Credential Store, jps-config.xml

Tuesday Oct 11, 2011

When to use OWSM? - 11g

I came across this interesting blog post from Gaurav Sharma that describes why he was initially skeptical of using OWSM to secure web services that are hosted in the intranet and what changed his mind.

What were the things that I found interesting?

  1. Gaurav focuses mainly on securing the message in transit
  2. His main concern even when discussing about securing messages when they are in transit is focused on apps handling sensitive information like financial information.
  3. If you are really a security fanatic - you will pick up on a third interesting tidbit - related to #2 - is that his main concern is around ensuring components outside the intranet are not in a position to access the sensitive information.
  4. Discussion about the performance implications

I think there is a broader list of security aspects that you need to consider - many of these were discussed a long time back in an article I co-authored and is available here. I have re-enumerted them here for convenience.

  • Authentication  (AuthN for short)
  • Authorization (AuthZ for short)
  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of Service
  • Replay attacks
  • Virus attacks and Intrusion Detection

The list of security issues is pretty comprehensive for the most part - but I will elaborate on two - Authentication, Authorization here:

If you need AuthN - there are some additional considerations that need to be considered in this space:

  • Does your Web Service need to support Identity propagation?.
  • Does your  Web Service need to support Brokered AuthN?
  • Does your Web Service need to support Federated Identity scenarios?

If you need AuthZ - there are few additional considerations as it relates to AuthZ:

  • Does your Web Service need to support Role based AuthZ?
  • Does your Web Service need to support Permission based AuthZ?
  • Does your Web Service need to support Fine grained AuthZ?
  • Does your Web Service need to support Context aware AuthZ and in general Context-aware Security? (Here is an article on the need for Context aware security)

Now not all of these security aspects are not necessarily relevant; if you have web services that are exposed in the intranet or these are departmental web services.

However you do need to consider the surface area of exposure for your web services - especially with what is being termed as the "Consumerization of IT" and the security challenges this presents.

Even assuming your departmental web services are do no have a large exposure and are accessible only via the corporate intranet - they typically require authentication and authorization. In addition auditing is also typically required to address compliance needs mandated by various regulatory requirements.

It is worth noting that OWSM does not necessarily address all the security issues - especially relating to Virus attacks, Throttling of requests, Intrusion Detection, etc.

Oracle's SOA Security Strategy is shown in the below embedded picture.

SOA Security Strategy

Here is a link to this image.  Hopefully this post helps people in considering the various security challenges and how the different Oracle products address these security challenges.

Updated: Corrected typos.

Sunday Oct 09, 2011

SAML support in OWSM - Best Practices - Part#1 - 11g

As mentioned in my past posts Ediwn Beimond has a great post on SAML support in OWSM. He covers the following scenarios:

  • A basic SAML authentication with 2 OWSM Servers.
  • Change the default SAML issuer name.
  • Allow only trusted SAML clients.
  • SAML Identity switching.
  • Virtual Users with User roles.

His post provides a detailed How-To describing things step by step on how to use these features. I thought I can perhaps shed some light on when to use these features and the best practices around usage of SAML. In addition starting with Oracle FMW 11gR1 PS3 - OWSM started supporting SAML 2.0 in addition to the SAML 1.1 - I will also discuss when to use SAML 1.1 vs. SAML 2.0.

The SAML wiki provides a good general overview.

SAML versions:

There are many blog posts on the topic of what is available in SAML 1.1. vs. SAML 2.0 - so I won't go into the technical differences here. If you are interested here is a document that describes the differences. (Of course you can search with your favorite search engine for additional materials).

The general SAML specs apply for a wide variety of scenarios - beyond Web Services Security. So some of the technical differences are not relevant. The OASIS WS-Security SAML Token 1.1 Profile specification describes the relevant differences from a WS-Security perspective. (See section 3.2).

In general I would recommend people use SAML 2.0 where possible.

The technical differences maybe one of the factors that you can use to make a determination. However there are probably other aspects that may drive this decision for you. The most frequent ones we encounter are:

  1. If you are in the Government or Department of Defense sector - then in most cases SAML 2.0 is mandated.
  2. If you need interoperability with "legacy" Web Service Security stacks - then you may need to consider using SAML 1.1 as it is more prevalent. 
So to summarize - in some cases - the version you end up using may be determined by what the "other side" your partner or external entity your web service is talking to supports.

SAML Confirmation Types:

The WS-Security spec defines 3 confirmation methods for SAML:

a) Sender vouches (SAML SV for short)

b) Holder of Key (SAML HOK for short)

c) Bearer

The table below tries to summarize the key differences b/w the three confirmation methods (I copied this table from this blog as it provides a pretty succinct summary of the differences):


Spec Description

English Description




The holder of a specified key is considered to be the subject of the assertion by the asserting party

“Verify this signed blob to reconfirm the subject”

Strong authentication by the receiver  of the subject.

Additional per-message signature verification processing. Requires additional trust processing for the public key;


Indicates that no other information is available about the context of use of the assertion

“Just trust me”

Fast and simple, no additional signature processing; if you trust the sender no additional processing is required

No additional confirmation possible; may require out-of-band or additional authentication


The subject of the assertion is the bearer of the assertion, subject to some optional constraints

“I am the subject”

Fast and simple, no additional signature processing

No additional confirmation possible; may require additional out-of-band or additional authentication

I will cover more on the SAML subject confirmation methods in the future - but the above table should be a good starting point. SAML HOK is probably most secure and provides centralized trust but is also has more performance impact and requires an STS.

In general - for public facing web services (i.e. web services) made available over the internet - I would recommend using SAML HOK. For departmental web services or web services used within the intranet - SAML SV or SAML Bearer maybe more appropriate.

SAML Identity switching

SAML is typically used for identity propagation, not for identity switching. However there are scenarios - where you may need to switch identities because you have the user id but not the password.

In general this would not a common scenario and if you want to switch identities - the general recommendation would be to use username token (or perhaps x509 token) policies.

Another thing to note is that when using SAML Identity switching policy - there is a limitation in that we don't allow propagating user roles and user attributes from the client to the service (as I mentioned in this blog post).

In a future blog post - I plan to discuss use-cases where SAML based Identity switching would be appropriate - rather than username token or x509 token.

SAML Issuer List & SAML Trusted DN

As a best practice - I would recommend people configure the SAML issuer list and the Trusted DN's for that issuer list.

The out of the box value for the list of trusted issuers is "" and I highly recommend that you change this in your environment to right SAML Issuer. While OWSM provides you the flexibility of configuring the issuer of a SAML assertion on a per client basis - I would recommend configuring the issuer at the domain level (just from a manageability perspective).

Virtual User

The virtual user functionality is typically useful for products that act as intermediaries. (ex: OSB, OEG, etc). In the virtual user scenario - the user in the SAML assertion is not validated against an identity store (hence the name virtual user).

If you are using intermediaries like OSB, OEG to front-end many web services belonging to different security domains, where each domain has it's own identity store (user repository), then trying to validate the user in OSB, OEG is not very meaningful.

In a future blog post I plan to provide additional information around use-cases where virtual user functionality is typically used - but for now the key takeaway is - it is typically not useful to use this functionality for back-end web services.

Fusion Apps and OWSM - 11g

Now that Fusion Apps 11g is generally available - I thought I would share some experiences in terms of how Fusion Apps leverages OWSM for it's Web Services security needs.

Fusion Apps is built on Fusion Middleware and mentioned in the various keynotes - there were a few key design principles that played a significant role. These are:

a) Secure By Default

b) Externalize Security from Applications and Declarative Security via Policies

c) Open and Standards based

d) Ease of Management

Secure By Default

I described "secure by default" in one of my earlier blog posts. This is a key design principle that drives the security architecture for Fusion Apps. Given that there are more than 100+ modules in Fusion Apps and more than 2000+ Web Services and Web Service Clients - as more and more modules and web services are deployed - the ability to have security by default is a key consideration.

Why do we need "secure by default"?

In in Fusion Applications we have products like ERP, HCM, etc that provide mission-critical capabilities to many organizations. Protecting data and business transactions is critical to reducing security risk;

How does Fusion Apps address "secure by default"?

Fusion Applications leverage the Global Policy Attachments (GPA) feature in OWSM to address this design goal. In addition, there are certain Web Services (Web Service Clients) in Fusion Apps that integrate with Partner systems - in this case the security requirements are different and hence LPA is used to secure these Web Services and Web Service Clients at Design Time in JDeveloper.

Externalize Security  from Applications & Declarative Policy based Security

Fusion Applications provide a lot of functionality - however we seed that:

a) Companies - extend Fusion Applications by building their own applications and integrating their applications with Fusion Applications.

b) The security requirements of Applications change over a period of time - these can be due to regulatory needs, integration needs, etc

Building security into the applications layer makes it brittle when the security requirements change, thus rather than building security into the applications layer - it is built into the Middleware layer and externalized from the Applications layer. This enables new applications that customer's may build to extend Fusion Apps to leverage the same capabilities. In addition, if the security requirements change, declarative policy based security allows one to make changes without having to change any code either in the Middleware layer or in the applications layer.

How does Fusion Apps address this design goal?

Fusion Apps leverages OWSM. OWSM provides a declarative policy based approach to addressing Web Services Security and allows one to externalize the security from Applications.

Open and Standards based

As mentioned earlier Fusion Applications expose a lot of functionality as Web Services. Many of the modules of Fusion Applications integrate with other modules via standards based Web Service interfaces. The rationale for this architecture is multi-fold:

a) Exposing functionality as Web Service interfaces - enables customer's to integrate their custom applications with Fusion Applications via Standards based interfaces.

b) Using Web Service interfaces to connect between modules enables us to build a more modular, less decoupled system and leverage the advantages of a SOA based architecture.

c) Exposing functionality as Web Service interfaces - makes it easier to deploy Fusion Apps in mixed topologies (some modules maybe on-premise and some maybe on-cloud) and still be able to integrate b/w the

d) Exposing functionality as Web Service interfaces - makes it easier to integrate/interoperate with Partner systems or other Oracle Applications - ex: Siebel, Peoplesoft systems - thus allowing customer's the choice for incremental uptake of Fusion Application modules.

These Web Services are also secured via standard Web Services Security policies - thus allowing for:

a) Standards based security.

b) Standards based interoperability with Partner systems.

How does Fusion Apps address this design goal?

Fusion Apps primarily leverage SAML token based policies for identity propagation. However not all Partner systems may support SAML - thus - Fusion Apps also support - Username Token.

Ease of Management and Being Able to Modify Default Security Posture

Fusion Apps has nearly 2000+ web services and web service clients. Fusion Apps ships with a default security posture. This default security posture may not be suitable for all companies. Given the number of Web Services and Web Service clients, being able to change the security policies if the security requirements of a company or organization change - is critical. However changing the security requirements needs to be easy and cost effective.

How does Fusion Applications address this design goal?

Fusion Apps again leverage Global Policy Attachments to address this design goal.

In a future blog post - I will discuss more concrete use-cases and lessons learnt from the Fusion Apps - which I hope customer's will find useful.

Friday Sep 16, 2011

Maintaining OWSM Policy Repository - Best Practices - 11g

OWSM provides a number of WLST commands that can help in maintaining the WSM Policy Repository. This includes upgrading the repository, rebuilding the repository, etc.

These are documented in the section "Maintaining the Oracle WSM Repository" . In this post I will briefly examine when one should consider using this based on a customer interaction.

Recently an OWSM customer ran into the issue where one of the policies we ship Out of the Box disappeared from the WSM Policy Repository in the customer installation. Unfortunately - this policy was being used to secure some of the web services in the installation.

So the first question is when may this occur?

  1. Well the Out of the Box policies we ship can be deleted. So somebody may have deleted it! [Side Note: I think we need to see if we need to improve our story here in future releases]. OR
  2. Something may have failed when we initially seed the repository with the Out of the Box policies.
If it is due to (1) - My first tip - This an excellent reason to leverage the OWSM Auditing capabilities. If somebody deleted the policy, then OWSM would have audited this operation if the Oracle FMW Audit framework had been set up in the installation.

In any case how do we recover from this? There are two WLST commands that you should be aware of that might be helpful:

a) upgradeWSMPolicyRepository() - the details of how to use this command are here.

b) resetWSMPolicyRepository(false) and resetWSMPolicyRepository(true) - the details of how to use this command are here.

In this case the customer ran the resetWSMPolicyRepository(true) command. The customer got the missing Out of the Box policies back but LOST all the custom policies that they had in the repository

First the customer should have used resetWSMPolicyRepository(false) command rather than resetWSMPolicyRepository(true). There is no way to undo this operation! Hence my next tip:

ALWAYS take a backup of the repository before you run these commands! How do you take a backup? There are several ways:

  • You can take a database backup
  • You can take a backup by exporting out the contents of the WSM Policy Repository (see this section for more details)
These commands are manipulating the entire repository, since they are dealing with the entire repository - if something goes wrong - there is no time travel here! - no way to go back to the original state!!! So backup is your best friend here and is worth the time and effort!

SAML Identity switching policy - Limitations - 11g

This post from Edwin Beimond talks about the various SAML features in OWSM. However there is one quick thing I wanted to note: The inclusion of user attributes and roles is NOT supported when you are using the SAML Identity switching policy in the current release (

The documentation is not necessarily very clear on this front.

Note: This may change in a future release - however for now the above limitation exists.

Wednesday Sep 14, 2011

Global Policy Attachments - Inheritance rules - Part#2 - 11g

In this blog post i briefly mentioned about GPA vs. LPA and when to use GPA. As I mentioned the key difference between GPA and LPA is around granularity (or scope of the policy attachment). So what are inheritance rules - if we define GPA that applies to say "all domains" vs. a GPA for "domain1" vs. a GPA for "app1", etc then the inheritance rules determine which policy get's enforced for a particular web service.

Broadly speaking there are two types of inheritance rules:

  1. Overriding rule
  2. Additive rule.

So here is a simple scenario.

Scenario#1: We have a deployment with two weblogic domains (Domain#1, Domain#2). We want to secure all web services (SOA, ADF, etc) in this deployment with wss11_username_token_with_message_protection_service_policy as shown in the figure below.

GPA all domains

Click here for a larger image.

Here are the WLST commands to setup GPA for the above scenario:


'ws-service', 'Domain("*")')

$>setPolicySetDescription('Default policies for web 

services in any domain')


See here for detailed description of these commands.

GPA Overriding rules

Scenario#2: If we now want to consider a scenario where in for a particular app (let's say "GeneralLedger" needs to be secured with oracle/wss11_x509_token_with_message_protection_service_policy) - then we need to define a new GPA. This is shown in figure below:

overriding rules

Click here for a larger image.

Here are the set of commands to define the GPA for GeneralLedger app to be secured with oracle/wss11_x509_token_with_message_protection_service_policy.


'ws-service', 'Application("GeneralLedger")')
$>setPolicySetDescription('Policies for web services in General ledger app')

In the scenario above - for Web Services in GeneralLedger the policy oracle/wss11_x509_token_with_message_protection_service_policy will be applied. Thus the application specific GPA overrides the deployment wide GPA. So we have the first rule which is basically that the more specific GPA overrides the more generic GPA.

GPA Additive rules

Scenario#3: Now let's consider a scenario where an application with a single WS (say "Reliable & Secure WS" - for lack of a better name!) want's security and WS-RM. Also we want the security to be the same as the deployment wide posture i.e. the app needs to be secured with oracle/wss11_username_token_with_message_protection_service_policy. In this scenario - all you need to do is attach oracle/ws_reliable_messaging_policy via LPA to the "Reliable & Secure WS". In this case OWSM recognizes that the "category" of the policy defined at the GPA level is "security" and specifically it is "authentication" and "message protection" subcategories under security and this in this case adds the policies such that the policies applied for "Reliable & Secure WS" is both oracle/wss11_username_token_with_message_protection_service_policy and oracle/ws_reliable_messaging_policy.

This is depicted in the figure below:

additive inheritance rules

Click here for a larger image.

Since the inheritance rules change based on the "category" of the policy and it may not always be clear as to which policy is being applied to a particular web service - OWSM provides what I call the "Effective Policy View" i.e. the set of policies that will be applied to a Web Service after applying of the inheritance rules I just described above. You can view the "effective policies" either in EM or via WLST. See this section in the documentation for a description around "Effective Policies".

Note: GPA is currently as of 11gR1 PS4 not supported for WLS WS and OSB.

Policy Attachment - GPA vs LPA - Best Practice - Part#1 - 11g

In a previous post I briefly mentioned about the fact that in OWSM 11g - we support Global Policy Attachments (GPA) and Local Policy Attachments (LPA) or sometimes also referred to as Direct Policy Attachments (DPA). In this post - I will provide some best practice guidelines on when to use GPA vs. LPA.

For those who are not familiar - in the case of LPA you attach it to a WSDL Port - so the policy applies to WSDL Port. GPA allows you to attach a policy to more coarse grained entities - ex: it can be to a Weblogic Domain - in which case the policy applies to all WSDL Ports running in that weblogic domain. Or the policy can be attached to an application - in which case the policy applies to all WSDL Ports that are part of that application (ex: ear). etc...

So the first main difference b/w GPA and LPA is the granularity. So when would one use GPA? Basically two scenarios:

a) You want a "Secure by Default" story

b) Ease of management for large deployments.

Secure by Default

So what do I mean by "Secure by Default"? Let's say you develop a web service in your favorite IDE. You can secure it at Design Time. However let's say you decide not to secure it at design time. Now the app is deployed - this app is not secure unless somebody goes and secures it post deployment in EM or via WLST. If there are no strict controls and processes in place - that ensures that app is secured before it is made available to the outside world - then you have a potential for vulnerability in that the app is running unsecured.

Improved manageability

Let's say you have a large deployment - 100's of web services - lots of WLS servers, multiple weblogic domains, etc. In this case going and securing each of the 100's of web services can be tedious, time-consuming, and error prone - especially if you want to ensure there are no web services that are unsecured. In such cases, if you have standardized on the security posture of your web services - GPA can be a life saver!.

You can define a GPA that says "all web services (WSDL Port) in all domains" in your deployment use let's say wss11_username_token_with_message_protection_service_policy!

Now whenever a new app is deployed to one of the domains in your deployment - it will "automatically inherit" the oracle/wss11_username_token_with_message_protection_service_policy and you don't have to go into individual web service and secure it. Let's say a year from now - you decide to change the default security posture to say all oracle/wss11_x509_token_with_message_protection_service_policy - then all you need to do is change it your GPA definition - in one place and all the web services in your deployment will be secured with this new policy!

When should you not use GPA?

  1. if you have not standardized on a security postured for your web services - then GPA is not very useful!
  2. Using GPA for role based authorization policies is not very useful. Typically different web services will be accessible by different roles. (Note: It would be ok to use GPA for permission based authorization policies).
  3. If your policy has app specific aspects - then GPA is not appropriate.
    • If you want specific parts of the message to be signed or encrypted as discussed in this post
  4. If a policy has expectations around how code is written by developers then GPA is not appropriate.
    • Ex: Using GPA for MTOM or WS-RM may not be appropriate. Not all web services support attachments - especially MTOM attachments. Also in many cases WS-RM or MTOM may require some coding considerations by developers.
Here are some pointers to the OWSM documentation on GPA and LPA.



Note: The documentation uses the terminology PolicySet for GPA. PolicySet is the underlying implementation model for supporting Global Policy Attachments!

GPA is extremely powerful - but you need to really understand the pros & cons before you decide to use this feature. In future posts - I will discuss:

a) some of the inheritance rules, etc associated with GPA and also what happens when you have GPA and LPA in a deployment or what happens when you want to mix policies from different categories - ex: Security and WS-RM.

b) When to combine different granualrities

c) Life-cycle aspects of GPA and how it differs from LPA.

Saturday Sep 10, 2011

Importing/Exporting OWSM Policies - 11g

Recently there was customer question around importing/exporting OWSM policies and I thought of addressing it in a wider context. There are basically two ways to import/export OWSM policies.

a) You can use FMWCTL to import/export policies

b) You can use WLST to import/export policies

Import/Export via FMWCTL
In FMWCTL you can import/export policies one at a time. This is described in the Security And Administrator's guide in the section "Managing Web Service Policies". Import is covered here. Export is covered here.

Import/Export via WLST

You can use WLST to perform bulk import/export of policies (and other documents). This is again described in the Security And Administrator's guide under the title "Importing and Exporting Documents in the Repository".

OWSM Policy Repository in JDeveloper - 11g

As mentioned in this post JDeveloper supports only attaching policies to Web Services. Quite a few people - are curious and have enquired from where exactly JDeveloper display's the list of OWSM Policies?

The answer: JDeveloper ships with an embedded OWSM Policy Repository. The embedded OWSM Policy Repository is a File based Policy Repository. You can check the location of this File Repository in JDeveloper. To do so Open JDeveloper, Click on the "Tools" menu, then click on "Preferences" menu item (Tools->Preferences). This will open a dialog as show below:

Viewing the location of the OWSM File Policy Repository in JDeveloper

Click here for a larger snapshot.

As you can see from the snapshot - the out of the box policies that ship with OWSM are installed as part of the JDeveloper in my case at the following location: "C:\Documents and Settings\pyamuna.ST-USERS\Application Data\JDeveloper\system11.\DefaultDomain\oracle\store\gmds"

Note: This location will vary by platform (Windows vs. Linux).

Below is a snapshot of the contents of the folder "C:\Documents and Settings\pyamuna.ST-USERS\Application Data\JDeveloper\system11.\DefaultDomain\oracle\store\gmds":

Folder contents of OWSM File Policy Repository

Note: Sometimes the folder will be empty. This is because the OWSM Policy Repository has not been initialized. You can trigger the initialization of the Policy Repository by trying to attach an OWSM policy to a Web Service. See this post by Jiandong on how to do this.

In future blog posts I will describe some of the features/options JDeveloper provides as it pertains to the OWSM Policy Repository and when to use these options - but hopefully this blog post solves the mystery of the OWSM Policy Repository in JDeveloper.


in this blog post

Friday Sep 09, 2011

Logging SOAP messages to DB - 11g

Quick note: If you were a 10g OWSM customer and were using the feature that allowed Logging SOAP messages to DB - you might have realized that there is no equivalent functionality in 11g. In 11g, OWSM supports logging SOAP messages to a file but not to a DB. If you want to log messages to the DB, you have two options:

a) You can write a custom assertion that logs the messages to DB.

b) Build some kind of an automation tool that can take messages logged to the file and upload it to the DB.

If you build a custom assertion - I suggest you use the category for the assertion as "security/logging". This will enable you to add the custom assertion before and after a security assertion - similar to the out of the box "oracle/security_log_template".

If you do decide to write a custom assertion - you will need to take into consideration a couple of key aspects:

  • Performance implication - doing a synchronous write to the DB may be expensive - you may need some kind of an asynchronous mechanism to the write the message to the DB
  • DB growth - if you have logging of SOAP messages enabled in a system dealing with huge volume of transactions - then the growth of the DB is a significant issue that you will need to consider.

Thursday Sep 08, 2011

Scope of OWSM Policy Repository, Policy Manager app

As i have mentioned in my previous posts Edwin has some really great posts on how to use OWSM policies. Another post that is really great is his post on SAML support in OWSM. However as I was going through his post I noticed a few things that I thought are worth clarifying/commenting...

First is the following comment:

For OWSM, every domain need to have it's own MDS repository to store all the OWSM policies and for SOA Suite you also need a soa-infra database repos.

Turns out this is not entirely accurate. For OWSM, the recommended topology is for "every domain to have it's own Policy Manager application", however it is not necessarily the case that each domain needs to have it's own Policy Repository (a.k.a MDS repository). In fact the Policy Manager app in Domain1 and Domain2 can share the same Policy Repository. This can be visualized as shown in in the below figure.

Multiple WLS Domains sharing the same OWSM Policy Repository

In future blog posts - I will try to provide some insight on when to use the various SAML features that Edwin presents in his blog post.

Vanishing Policy Attachments - Troubleshooting - 11g

It appears quite a few people run into the issue of the "vanishing policy attachments". Here are some typical scenarios where people run into the "vanishing policy attachments" issue:

Scenario#1:  Redeploying the app causes policy attachments to vanish

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS
  3. User secures the app by attaching an OWSM policy using FMWCTL
  4. User makes changes to the app in JDeveloper. User redeploys the app. The policy attached in step#3 has vanished!

Scenario#2: Moving the app from Dev->Test->Production causes policy attachments to vanish

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS in the Dev environment
  3. User secures the app by attaching an OWSM policy using FMWCTL
  4. User than "moves" the app to Test environment - by deploying the app to WLS running in Test environment. The policy attached in step#3 has vanished!

In both these scenarios - the vanishing of the policy attachments is expected behavior! If you make changes to the app post deployment - then you need to user either deployment plans to migrate/retain the changes or use import/export facilities based on the type of technology being used to develop web services.

The exact terminology used in Oracle FMW documentation varies from technology to technology. For ex: SOA Suite uses import/export, where as WLS uses deployment plan terminology. However irrespective of terminology the broad concept is the same - your original app (.ear or .war or .sar) is not modified directly when you do changes post deployment. So to retain the changes you need to do the following:

Revised Scenario#1:  Redeploying the app without losing policy attachments.

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS
  3. User secured the app by attaching an OWSM policy using FMWCTL
  4. User makes changes to the app in JDeveloper. 
  5. Export out the changes made to the app in step#3.
  6. User redeploys the app with changes made in step#4 + imports the changes saved in step#5.

Revised Scenario#2: Moving the app from Dev->Test->Product causes policy attachments to vanish

  1. User develops an app (say SOA Composite app).
  2. User deploys the app to WLS in the Dev environment
  3. User secured the app by attaching an OWSM policy using FMWCTL
  4. Export out the changes made to the app in step#3.
  5. User than "moves" the app to Test environment - by deploying the app + imports the changes saved in step#4 to WLS running in Test environment.

The section "Migrating Deployment Descriptors" in the Security And Administrator's Guide provides pointers on this subject.

Wednesday Sep 07, 2011

OWSM Licensing - 11g

A quick note on OWSM Licensing - there are two options to license OWSM:

(1)    Get OWSM via SOA Suite, which includes full use license;


(2) Get OWSM via AM Suite Plus, which includes a restricted use license. OWSM should be used in conjunction with another AM suite component.

Custom Policies & Custom Assertions - 11g

I came across this blog entry by Izzak de Hullu on OWSM Custom Policies; while I really appreciate Izzak's inventiveness and feedback and we are working on improving things here - I thought I should comment on a few things.

The first thing to note about the blog entry is you can actually sign only particular elements in the SOAP message rather than the entire body. While it is true that the out of the box policies only support signing/encrypting the body of the message, like I mentioned in the OWSM Concepts - 11g post - you can define new OWSM policies using FMWCTL.

So to achieve the use-case Izzak was attempting - To sign/encrypt particular elements - you can do the following:

  1. make a copy of "oracle/wss11_message_protection_service_policy" - let's call it "acme/wss11_message_protection_elements_service_policy". (See section "Creating a Web Service Policy from an Existing Policy"
  2. edit the policy to remove signing/encryption of the body and add elements to be signed and encrypted. This is described in the Security and Administrator's Guide unfortunately - it is in the appendix under the section "Predefined Assertion Templates". See Table titled "Request, Response, and Fault Message Signing and Encryption Settings"

The second and probably the more important thing to note is that Izzak is using some methods that are not exposed by the OWSM Extensibility Guide. This is not something I would recommend - as these methods are subject to change.

In a future post I hope to have a sample how to that describes this in detail.

Tuesday Sep 06, 2011

Handling Passwords in OWSM - Best Practices - 11g

I came across some excellent blogs on the net that talk about OWSM and how to use OWSM to secure your web services/web service clients.

Here are some examples that I see on the net: by Ediwin Beimond.  by Jiandong Guo

Edwin Beimond has some excellent posts in terms of providing a detailed step-by-step How To describing how to use various OWSM policies. However one of things I have noticed is that people end up specifying passwords in the clear as part of their code snippets.

This is something I would strongly discourage customer's from adopting. Passwords in the clear in code is a recipe for security vulnerabilities. It also results in brittle code - if the passwords change - you need to change code.

Oracle FMW provides a credential store framework (CSF) to enable storing passwords in a secure fashion and I encourage people to use CSF rather than specifying passwords in the clear.

In future blog posts I will discuss how to use CSF instead of clear text passwords.

OWSM Concepts - 11g

Jiandong has posted a number of articles introducing OWSM 11g at

This post elaborates on some of the aspects discussed in those posts. There are three aspects to securing a web service using OWSM

  1. Defining Policies
  2. Attaching Policies
  3. Setup Configuration required for Policies
(Note: While this post focuses on security, this is true for other policies like WS-RM, etc as well)

Defining Policies

Policies in OWSM are defined generically without context i.e. in general they are not App specific. There are some types of security policies that tend to be App specific - we will blog about this in a future post.

How to define policies?

You typically define policies using FMWCTL (Fusion Middleware CTL). The Security And Administrators Guide provides detailed documentation on how to define policies. (See Section Managing Web Service Policies ).

A Policy can be composed of a number of "Assertions". Typically you will have atleast one Assertion in a Policy.

Attaching Policies to Policy Subjects

Once a Policy is defined - you can "attach" the Policy to a Policy Subject. A Policy Subject is either a Web Service or a Web Service Client. OWSM supports a variety of Web Services [ex: Oracle Infrastructure Web Services, SOA Web Services, ADF BC Web Services, OSB Proxy Service, WLS JEE JAX-WS, Oracle WebCenter WSRP, etc] and Web Service Clients [ex: SOA References, ADF Web Service Data Control (WSDC), OSB Business Service, WLS JEE JAX-WS Clients, WebCenter Portal, etc]

How to attach Policies?

There are three ways to attach OWSM Policies:

a) Via IDE's - ex: JDeveloper

b) Via Command Line Tooling - ex: WLST

c) Via Web based user interface - ex: FMWCTL

(b) and (c) are discussed in detail in the Security And Administrator's guide. Specifically see Section "Attaching Policies to Web Services" for details.

Note: WLST is not support for OSB and WLS Web Services/Web Service Clients as of

Setup Configuration required for Policies

 Most Policies (esp. "security policies";) require additional configuration. For example:

  1. Message protection policies require Keystore setup.
  2. Passwords require OPSS Credential store setup,
  3. Authentication policies require Identity Store setup
  4. WS-Trust based policies require STS

This is discussed in detail in the Section "Setting Up Your Environment for Policies".

From our interactions with customers, support, etc - it appears most people seem to trip up on the last aspect. In future blog posts we will elaborate on some of the concepts introduced in this blog post as well as describe in detail the "Setting Up Your Environment for Policies".


In this blog I will discuss mainly features supported by Oracle Web Service Manager (OWSM).


« April 2014