Monday Dec 03, 2012

OWSM Permission based Authorization in SOA - 11g

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.

Monday Jun 11, 2012

Permission based Authorization vs. Role based Authorization - Best Practices - 11g

In previous blog posts here and here I have alluded to the support in OWSM for Permission based authorization and Role based authorization support. Recently I was having a conversation with an internal team in Oracle looking to use OWSM for their Web Services security needs and one of the topics was around - When to use permission based authorization vs. role based authorization?

As in most scenarios the answer is it depends! There are trade-offs involved in using the two approaches and you need to understand the trade-offs and you need to understand which trade-offs are better for your scenario.

Role based Authorization:

  • Simple to use. Just create a new custom OWSM policy and specify the role in the policy (using EM Fusion Middleware Control).
  • Inconsistent if you have multiple type of resources in an application (ex: EJBs, Web Apps, Web Services) - ex: the model for securing EJBs with roles or the model for securing Web App roles - is inconsistent.
  • Since the model is inconsistent, tooling is also fairly inconsistent.
  • Achieving this use-case using JDeveloper is slightly complex - since JDeveloper does not directly support creating OWSM custom policies.

Permission based Authorization:

  • More complex. You need to attach both an OWSM policy and create OPSS Permission authorization policies. (Note: OWSM leverages OPSS Permission based Authorization support).
  • More appropriate if you have multiple type of resources in an application (ex: EJBs, Web Apps, Web Services) and want a consistent authorization model.
  • Consistent Tooling for managing authorization across different resources (ex: EM Fusion Middleware Control).
  • Better Lifecycle support in terms of T2P, etc.
  • Achieving this use-case using JDeveloper is slightly complex - since JDeveloper does not directly support creating/editing OPSS Permission based authorization policies.

Wednesday Mar 14, 2012

How To - SOA Component level Role based Authorization using OWSM - 11g

Here is another How-To that provides detailed instructions for How To perform role based authorization for a SOA Composite app.

These are fairly large documents since I am providing a detailed step by step instructions. If you are familiar with some or all of the technologies - you can jump around the How-To to the relevant sections.


In many cases the How-To's may have typos and other mistakes - please let me know if you see any issues in the How-To and I will try and fix them.

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.


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


« April 2014