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.

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.

Thursday May 31, 2012

Identity Propagation across Web and Web Service - 11g

I was on a customer call recently and this topic came up. In fact since this topic seems to come up fairly frequently - I thought I would describe the recommended model for doing SSO for Web Apps and then doing Identity Propagation across the Back end web services.

The Image below shows a typical flow:

Here is a more detailed drill down of what happens at each step of the flow (the number in red in the diagram maps to the description below of the behind the scenes processing that happens in the stack).

[1] The Web App is protected with OAM and so the typical SSO scenario is applicable. The Web App URL is protected in OAM. The Web Gate intercepts the request from the Browser to the Web App - if there is an OAM (SSO) token - then the Web Gate validates the OAM token. If there is no SSO token - then the user is directed to the login page - user enters credentials, user is authenticated and OAM token is created for that browser session.

[2] Once the Web Gate validates the OAM token - the token is propagated to the WLS Server where the Web App is running. You need to ensure that you have configured the OAM Identity Asserter in the Weblogic domain. If the OAM Identity Asserter is configured, this will end up creating a JAAS Subject.

Details can be found at:

http://docs.oracle.com/cd/E23943_01/doc.1111/e15478/webgate.htm#CACIAEDJ

[3] The Web Service client (in the Web App) is secured with one of the OWSM SAML Client Policies. If secured in this fashion, the OWSM Agent creates a SAML Token from the JAAS Subject (created in [2] by the OAM Identity Asserter) and injects it into the SOAP message.

Steps for securing a JEE JAX-WS Proxy Client using OWSM Policies are documented at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/attaching.htm#BABBHHHC

Note: As shown in the diagram - instead of building a JEE Web App - you can also use WebCenter and build portlets. If you are using WebCenter then you can follow the same architecture. Only the steps for securing WebCenter Portlets with OWSM is different.

http://docs.oracle.com/cd/E23943_01/webcenter.1111/e12405/wcadm_security_wss.htm#CIHEBAHB

[4] The SOA Composite App is secured with OWSM SAML Service policy. OWSM Agent intercepts the incoming SOAP request and validates the SAML token and creates a JAAS Subject.

[5] When the SOA Composite App tries to invoke the OSB Proxy Service, the SOA Composite App "Reference" is secured with OWSM SAML Client Policy. Here again OWSM Agent will create a new SAML Token from the JAAS Subject created in [4] by the OWSM Agent and inject it into the SOAP message.

Steps for securing SOA Composite Apps (Service, Reference, Component) are documented at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/attaching.htm#CEGDGIHD

[6] When the request reaches the OSB Proxy Service, the Proxy Service is again secured with the OWSM SAML Token Service Policy. So the same steps are performed as in [4]. The end result is a JAAS Subject.

[7] When OSB needs to invoke the Business App Web Service, it goes through the OSB Business Service. The OSB Business Service is secured with OWSM SAML Client Policy and step [5] is repeated.

Steps for securing OSB Proxy Service and OSB Business Services are document at:

http://docs.oracle.com/cd/E23943_01/admin.1111/e15867/proxy_services.htm#OSBAG1097

[8] Finally when the message reaches the Business App Web Service, this service is protected by OWSM SAML Service policy and step [4] is repeated by the OWSM Agent.

Steps for securing Weblogic Web Services, ADF Web Services, etc are documented at:

http://docs.oracle.com/cd/E23943_01/web.1111/b32511/attaching.htm#CEGCJDIF

In the above description for purposes of brevity - I have not described which OWSM SAML policies one should use; OWSM ships with a number of SAML policies, I briefly described some of the trade-offs involved with the various SAML policies here.

The diagram above and the accompanying description of what is happening in each step of the flow - assumes you are using "SAML SV" or SAML Bearer" based policies without an STS.

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