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.

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.

Friday Mar 16, 2012

OWSM Policy Repository in JDeveloper - Tips & Tricks - 11g

In this blog post I discussed about the OWSM Policy Repository that is embedded in JDeveloper. However some times people may run into issues with the embedded repository. Here is screen snapshot that shows the error you may run into (click on the image for larger image):

If you run into "java.lang.IllegalArgumentException: WSM-04694 : An invalid directory was provided to connect to a file-base MDS repository." this caused due to spaces in the folder name. Here is a quick way to workaround this issue by running "Jdeveloper.exe - su".

Hope people find this useful!

Saturday Sep 10, 2011

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

Tuesday Sep 06, 2011

Attaching OWSM Policies - Best Practices - 11g

As mentioned in previous post - there are three ways to attach Policies in OWSM 11g.

a) at Design Time (DT) in an IDE - ex: JDeveloper

b) Post Deployment - using WLST or FMWCTL

One of the questions that pop up from time to time is around when to use what - in this post I provide some guidelines that can help in deciding which is the best methodology.

Before I actually layout some guidelines - we need to discuss a related feature supported in OWSM 11g - this relates to the fact that attaching a policy at DT does not prevent you from changing it post deployment. So (a) and (b) are not necessarily mutually exclusive. The reason OWSM provides this flexibility is in many organizations - administrators (either app administrators or security administrators) decide on the security posture and hence the ability to change the security posture by changing the policy of a Web Service or Web Service Client is an important consideration [1].

So if your organization is more attuned to the process of standardizing security upfront and communicating it to your developers then developers can secure it at DT, test it early to ensure all aspects are working before the app gets deployed to a testing, staging, production environments. In general I would recommend some level of testing with security enabled in your DT environment. (a) is helpful in those scenarios.

(b) is relevant in two scenarios:

i) you have unsecure apps that need to be secured by the administrators post deployment.

ii) you have secure apps but they don't adhere ot the security guidelines standardized by the organization and hence you need to change the policy attached to the WS/WS Client.

Using WLST vs. FMWCTL:

WLST is more suited if you would like to script things out (in addition some administrators like command line tooling while others prefer a Web based user interface).

FMWCTL is more suited for people who prefer a Web based user experience or for non-scripting scenarios.

In future blog posts I will discuss guidelines around when to use Direct Policy Attachments (or Local Policy Attachments) vs. Global Policy Attachments (GPA).


[1] In - WLS JAX-WS Client support only a programmatic model of attaching the policy to the client app. In this scenario - one cannot change the policy post deployment.


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


« April 2014