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.

Thursday Feb 07, 2013

When to use Oracle STS (OSTS)?

I have been meaning to do a blog post on this front for quite sometime but just haven't had the cycles. So this a very rushed blog post - please excuse typos!!

The basic question that seems to come up is when to use an STS in general and OSTS in particular. So here are my thoughts on the matter.

To me there are - three main scenarios for using a STS:

  • Token Exchange/Conversion
  • Federation
  • Centralized Trust

In this post I will cover Token Exchange and Federation very briefly.

Token exchange/conversion

So the first set of scenarios is around the need to be able to exchange one kind of token with another type of token. Ex: You want to exchange a Kerberos Token with a SAML token. Here is a picture that demonstrates this scenario (click on the image for a large image):


STS Token Exchange Use-case

In the  above scenario a customer has a Desktop Application (ex: Say Outlook or some other .NET Web Service) that is talking to a backend Web Service let's say hosted on Oracle Fusion Middleware that can accept SAML Token.

User "joe" logs into his Desktop and a Kerberos Ticket is created. When user opens the Desktop application and performs an operation this results in a backend web service call and we want to propagate the identity of "joe" to the backend application. However the token we have is a Kerberos Token on the client side and the backend Web Service only accepts a SAML token. One can use an STS to do a token conversion or token exchange (assuming the STS is capable of such a conversion).

Web Service Federation

The second scenario where a STS is very useful and probably the most important scenario in my mind is when you need to do Federation. For those of you who are not familiar with Federation - I suggest reading up on Federation in general and Web Service Federation in particular. The picture below depicts this use-case.

STS - Federation Use-case

The use-case is similar to a Token Exchange use-case. We have a Desktop Application (say Outlook) that needs to invoke a backend Web Service. However the backend Web Service is running in the Cloud (Public or Private Cloud).

The key issue here is that the user "joe" is unknown in the Cloud.

There is a good reason why the user "joe" is unknown in the Cloud. Since an application running in the cloud may be used by multiple customers say "Acme Inc" or "Foobar Inc" both of which may user called "joe" the Cloud cannot have a single user named "joe" in it's Directory instead it would need to distinguish "Acme Inc" user "joe" (let's call him "acme.joe" ) from "Foobar Inc" user "joe" (let's call him "foobar.joe" ).

So now in the Cloud we actually have two users "acme.joe" and "foobar.joe" - so the Desktop Application (running within Acme Inc) needs to map "joe" to "acme.joe" - before it talks to the Cloud. This mapping is where an STS comes in handy! as shown in the picture.

So not only are we converting the token from Kerberos to SAML we are also now mapping "joe" to "acme.joe" in the STS.

Notes:
  1. The picture depicts Oracle Public Cloud - but the concept applies to any Cloud (Public/Private) or in fact across Partner systems.
  2. The picture depicts Fusion CRM - but the concept applies to any Web Service
  3. I make no guarantees that what is shown in the picture above is necessarily what is implemented in the Oracle Public Cloud and I have used the example for purely illustrative purposes!

In a future blog post I will elaborate further on some of the scenarios and also the Centralized Trust scenario.

Finally - one last parting shot - the scenarios and use-cases for an STS and OSTS are fairly extensive and in this blog post - I am trying to illustrate some very simple scenarios. Please consult the Oracle STS documentation for all the features.

About

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

Search

Categories
Archives
« February 2013 »
SunMonTueWedThuFriSat
     
1
2
3
4
5
6
9
10
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
  
       
Today