OWSM Permission based Authorization in SOA - 11g
By Prakash Yamuna-Oracle on Dec 03, 2012
Just came across a nice blog post on how to do authorization in SOA using the OWSM permission based authorization policy.
One big caveat is in order: SOA does not support the concept of "Application Roles". So the grant is done to the enterprise role (i.e. ldap group). If I get sometime I will post more about the differences b/w doing grants for Application Roles vs. Enterprise Roles.
Update: So I added a big caveat while linking to the above blog post but did not add any explanation. This had folks confused - since the blog post explicitly talks about Application Roles!
Well if you look at the blog post - it talks about Application Roles in the "soa-infra" Application stripe. The "soa-infra" Application Stripe is the stripe of the SOA Suite container.
I would NOT recommend using the SOA Suite container's Application Stripe for SOA Composite Applications for a couple of reasons:
a) The lifecycle aspects become horrendously complicated when you mix Application Roles applicable for SOA Composite applications that a customer builds in the same stripe that is used by the SOA container. For ex: In a future release the SOA container might decide to use a different stripe for it's application roles - if a customer is using this stripe then all the authorizations for SOA Composite applications would start failing when they upgrade to the new release. You can potentially also cause the SOA container to stop working - if you delete or modify the Application Roles that it ships. Fundamentally - the soa-infra stripe is owned by the SOA container for it's working and customers should not be using it for their own composite apps.
The closest analogy to what is being done in the blog post would be a comparison b/w WLS Application Server and J2EE Apps. I would not recommend mixing the security artifacts that ship with the Application Server for it's own internal working with the security artifacts that is required for a customer developed J2EE application. Patching, Upgrade, T2P, etc are all very different.
b) The other reason of course is this is no really scalable. You can have hundreds of composite applications. If you use a single application stripe "soa-infra" - then there is impact when you move let's say one composite application from Test to Production. How do you move the corresponding application roles that are relevant for only that particular composite app. In addition there are performance implications - if you have hundreds of composite applications and each composite application defines it's own Application Role - then you end up defining hundreds of Application Roles.
So in order to avoid getting into the above type of issues - I recommend customers stick to enterprise roles (ldap groups).
Note: This recommendation to avoid Application Roles and use Enterprise Roles (Ldap Groups) is only for SOA composite applications. For JEE Applications - using Application Roles is beneficial and the lifecycle issues that I describe above don't exist.
In a future blog post - I will describe the advantage of Application Roles.