Friday Feb 15, 2013

Dynamic Policy Selection among alternatives - 11g - follow up

Just a couple of quick follow up points to my blog post on Dynamic Policy Selection.

First a shout out to Chris's blog post on this topic - I missed it since he blogged about it more than 2.5 years back! He is a doing a lot of creative things in that blog post. My post was more around what is supported by OWSM out of the box.

Second - a clarification - the Dynamic Policy Selection is supported only on the service side currently.

Friday Feb 08, 2013

Dynamic Policy Selection among alternatives - 11g

A few weeks back I was discussing some requirements a few teams had within Oracle and I thought it would be a good topic to address on this blog. One of the most common scenarios that customers seem to run into is the following:

Let's say you have a Web Service. The Web Service supports SAML. Now if Web Service Clients are able to support SAML you are in good shape and they can talk to your Web Services. However if a Web Service Client cannot support SAML then you have a problem. Let's assume for  a second that the Web Service Client can support Kerberos but not SAML.

This mismatch in security capabilities is a fairly common occurrence. 

Before I talk about the specific feature of Dynamic Policy Selection that is supported in OWSM - let's see what are the various ways to solve this problem:

a) Option#1: Use Oracle STS to do Token Exchange/Conversion

b) Option#2: Build SAML capability in the Web Service Client or use Web Services Security technology that supports SAML

c) Option#3: Add Kerberos support to the Web Service.

Here we have two scenarios:

Scenario#3.1: Expose two Web Service Ports one using SAML and the other using Kerberos.

Scenario#3.2: Dynamic Policy Selection on the Service

d) Option#4: Use Oracle Enterprise Gateway or Oracle Service Bus

I will describe briefly each of the options and the advantages and disadvantages of each option.

So a customer has four options. Different options have different implications on different parties.

Option#1: Use Oracle STS to do Token Exchange/Conversion

As I mentioned in a previous blog post - you can use a Oracle STS. Just to reiterate - this will look as follows:

Oracle STS - Token Exchange/Conversion

Advantages:

a) The Security story on the Web Service side is fairly simple - you can standardize on one particular token - ex: SAML that all clients need to adhere to...

Disadvantages:

a) The onus is on the Client to bridge the difference b/w what the Web Service supports and what the client supports.

b) The Client needs to have the capability to be able to talk to an STS.

Option#2: Build SAML capability in the Web Service Client or use Web Services Security technology that supports SAML

 Well this fairly self evident - if you can add the SAML support on the client - then there is not mismatch! Ex: use OWSM for example to secure your Web Service client and viola problem solved :-)

Advantages:

a) The Security story on the Web Service side is fairly simple - you can standardize on one particular token - ex: SAML that all clients need to adhere to...

b) No new components into the mix - ex: Oracle STS

Disadvantages:

a) It may not always be possible to add SAML support - depending on the technology stack being used on the Web Service Client side!

Option#3: Add Kerberos support to the Web Service

In this approach instead of client changing, the service side is modified to add Kerberos support. There are two ways to address this:

Scenario#3.1: Expose two Web Service Ports one using SAML and the other using Kerberos.

This is shown in the figure below (click for larger image).

different web service ports for different security

Advantages

a) The advantage of this approach is the clients are not impacted.

Disadvantages

a) The Web Service has to support multiple web services - one for each security token or security requirement.

b) More overhead in terms of maintaining, testing.

c) If a technology stack does not support adding Web Service Ports dynamically  - then the application has to go back to the Development and so the administrator cannot address this requirement.

d) Assumes the Web Service/Web Service Security stack on the service side can support Kerberos.

Scenario#3.2: Dynamic Policy Selection on the Service

OWSM - Dynamic Policy Selection

In this model the Web Service is configured with a policy that basically supports both SAML "OR" Kerberos [1]. When the Web Service Client invokes the Web Service - based on the contents of the message the appropriate option is selected. So if the Desktop application sends Kerberos Token - then the Kerberos Option in the policy is executed. If the On Premise App sends the SAML token in the SOAP message the SAML Option in the policy is executed.

High level Description:

So the way to achieve this in OWSM is by constructing an ExactlyOne Policy which contains two assertions - one is a SAML authentication assertion and the other is the Kerberos Authentication assertion.

<ExactlyOne>

<SAML Authentication>

<Kerberos Authentication>

</Kerberos>

You can author such a policy using Enterprise Manager Fusion Middleware Control as described in the OWSM documentation here.

Advantages:

a) No changes to the Web Service/Application itself. So a customer does not have to go back to the Development teams to add new Web Service Port every time the security requirement changes.

b) Administrator can make the changes by creating new combinations based on requirements

c) Web Service Clients  are not impacted

Disadvantages:

a) The customer hosting the Web Service has to still test two security models! So there is still some testing, maintenance overhead.

b) Assumes the Web Service/Web Service Security stack on the service side can support Kerberos and Dynamic Policy Selection.

Notes:

[1] For purposes of simplicity - I use the terminology "OR" above but "OR" operator and ExactlyOne are not identical in semantics.

[2] OWSM currently ships a few policies Out of the box (OOTB) that have this capability. Ex: See here and here. This section in the OWSM doc - describes the client policy and service policy compatibility which provides you a good overview.

Option#4: Use Oracle Enterprise Gateway or Oracle Service Bus

In this option OEG or OSB will act as an intermediary and do the token conversion - potentially in conjunction with an STS.

OEG as an intermediary for token mediation

Advantages

a) No impact for Client or the actual backend Web Service. The onus shifts to the intermediary in this case OEG or OSB.

b) If the Client cannot be modified or the backend Web Service cannot be modified - this is pretty much becomes the only option!

Disadvantages

a) You need a new component - OSB or OEG in the mix

b) The intermediary has to easily support Scenario#3.1 or Scenario#3.2 itself - otherwise we have just shifted the problem to a different layer!

 In this blog post - I took a concrete example - i.e. Kerberos and SAML - but the concept applies in general to any mismatch in security capabilities that customers may find between a Web Service Client and Web Service.

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.

Wednesday Aug 15, 2012

OWSM Gateway vs. OEG - OWSM 11g

I came across this blog post http://www.narendranaidu.com/2011/11/oracle-web-service-manager-vs-oracle.html about confusion b/w OWSM Gateway and OEG and I thought I would post a quick clarification.

I have already described earlier about OWSM vs. OEG here and Oracle's vision for layered security here. However I didn't address OWSM Gateway vs. OEG!

As many of you know in OWSM 11g - there is no OWSM Gateway - we have only OWSM Agents. The OWSM Gateway Narendra is talking about is referring to the OWSM 10g Gateway. OEG is the 11g successor to the OWSM 10g Gateway.

Hope that clarifies any confusion!

Update#1: Here is a document that describes how to migrate from OWSM 10g Gateway to OES OEG 11g.

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.

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.

Note:

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.

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