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.

Tuesday Jun 12, 2012

Identity Propagation for Web Service - 11g

I came across this post from Beimond on how to do identity propagation using OWSM.As I have mentioned in the past here, here and here - Beimond has a number of excellent posts on OWSM. However I found one part of his comment puzzling. I quote:

"OWSM allows you to pass on the identity of the authenticated user to your OWSM protected web service ( thanks to OPSS ), this username can then be used by your service. This will work on one or between different WebLogic domains. Off course when you don't want to use OWSM you can always use Oracle Access Manager OAM which can do the same." The sentence in red highlights the issue i find puzzling.

In fact I just discussed this particular topic recently here.

So let me try and clarify on a few points:

a) OAM is used for Web SSO.

b) OWSM is used for securing Web Services. You cannot do identity propagation using OAM for Web Services.

c) You use SAML to do identity propagation across Web Services. OAM also supports SAML - but that is the browser profile of SAML relevant in the context of Web SSO and is not related to the SAML Token Profile defined as part of the WS-Security spec.


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.

Thursday May 24, 2012

SSL vs. Non-SSL OWSM Policies - 11g

I was having a conversation with a colleague and we were discussing about OWSM SSL policies vs. Non-SSL policies. For the uninitiated - here is the OWSM documentation that talks about the pre-defined OWSM policies. 

So I thought I would share that conversation with this quick post...

As you can see from the list OWSM ships a bunch of policies that require SSL. The discussion we were having was what is the benefit of using OWSM SSL policies vs. using OWSM Non-SSL Policies over SSL.

The first thing to note about OWSM SSL Policies (ex:oracle/wss_username_token_over_ssl_service_policy) is they don't automatically enable SSL!

You still need to enable SSL at the Application Server level ex: in WLS or WAS.

The second thing to note is that OWSM Non-SSL Policies can be used over SSL.

So if the OWSM SSL Policies don't enable SSL automatically why use them?

The OWSM SSL Policies enable three things at a very high level:

a) The SSL Policies ensure that SSL is actually enabled. If SSL is not enabled the requests will fail. Certain SSL Policies require two-way SSL (where as others required one-way SSL), for the SSL policies that require two-way SSL - they check to ensure two-way SSL is enabled - otherwise the requests will fail.

b) WS-SecurityPolicy standards compliance. WS-SecurityPolicy defines standards in terms of what exists in the WSDL when you are using SSL. The OWSM SSL Policies ensure that what is "advertized" in the WSDL is WS-SecurityPolicy compliant. This will ensure clients that understand WS-SecurityPolicy can comply with what is described in the WSDL. (ex: Microsoft)

c) In some cases the SSL Policies sign the SAML token, etc. So for ex: if you have configured oracle/wss10_saml_token_service_policy over SSL it is not equivalent to using oracle/wss_saml_token_over_ssl_service_policy

For these reasons if you are using SSL as Transport layer security - I recommend using the OWSM SSL policies rather than using the Non-SSL policies over SSL.

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

Podcast on SOA Governance and OWSM - 11g

Anand Kothari the Product Manager for OWSM has a great podcast on SOA Governance and how OWSM, OEG help the SOA Governance story.


About

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

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today