Sunday Jun 09, 2013

Identity Propgation for REST APIs - 11g

In a previous blog post - I described the support we added in OWSM for securing REST APIs. There have been a few questions about OWSM support for REST security and also how we can do identity propagation and SSO for REST APIs.

Before I dwell into how one can do Identity Propagation for REST APIs. It will help to identity the different type of clients that can invoke REST APIs. In my mind - the clients can be categorized into the following:

a) Server (JEE REST) Clients - these can be built using the standard REST stacks like Jersey JAX-RS/JBoss REST Easy/etc

b) Browser Clients

c) Thick Clients like Outlook

d) JSE Clients (or clients running in a non-server and non-browser environments)

e) Mobile Clients

The security requirements vary a bit based on the type of client.

JEE Clients - Server to Server communication

For Server to Server REST communication - if you want to do Identity Propagation - I recommend using SAML. OWSM supports SAML bearer tokens. OWSM currently doesn't support securing REST clients. However you can build REST clients using programmatic models and use libraries like OPSS Trust APIs or OpenSAML, etc to construct the necessary SAML tokens and inject it into the HTTP header. This is depicted in the picture below.

You can click on the picture to see a larger image or click here.

For those who have been following my blog - this picture is very analogous to how we handle things for SOAP as described in this blog post. The only difference is there is no OWSM Agent support for securing the REST Clients and so you need to use some other libraries/toolkit.

You actually have two variants for securing REST APIs invoked by Browser based Clients:

a) Use OAM only

b) Use OAM + OWSM

If the only client for your REST APIs is a browser based client, then OAM is sufficient to secure your REST APIs.

SSO for REST APIs

Identity Propagation vs. SSO

It is important to note that Identity Propagation and SSO are not equivalent - although many people use the terms interchangeably. Although the net effect of both is the same i.e the identity of the user is available to the application - there is one significant difference.

In the case of Identity Propagation - there is no concept of Login/Logout - which basically means there is no concept of Web SSO Sessions.

If you have different type of clients invoking your REST APIs and one of the types is a browser based clients, then OAM + OWSM is a better combination.


Thick Clients like Outlook, etc

If it is Microsoft technology based clients then instead of SAML you can use SPNEGO to perform Identity Propagation.

JSE Clients

Typically Identity Propagation is not a big use-case for JSE Clients - however you can follow a similar approach to JEE Clients.

Mobile Clients

I will address Mobile Clients in a future blog post.

Thursday Apr 04, 2013

Identity Context support in OWSM - 11g

Here is another quick post about yet another new feature in PS6. As many of you know we have supported identity propagation for a long time. However as things have evolved - it is clear that propagating just identities is not sufficient. We need to propagate additional contextual information - this may include for ex:

a) In the Mobile world - for example this can include whether the user is using a device that is jail broken or not

b) In the Banking space - the geo-location from where an ATM debit card or credit card might be getting used by the user.

In fact Marc Boroditsky spoke about this in Oracle Open World 2012.

This sets up the need for propagating not just the identity but the entire context! In PS6 we have taken a step in this direction.

Note: There are still some limitations - SOA Suite/OSB - for example don't yet support the ability to propagate the entire identity context.

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.

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.


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 May 23, 2012

WLS Custom Authenticator, OPSS Custom Identity Store Service, OWSM Custom Assertion - custom everything!! - 11g

Between WLS, OWSM, OPSS - Oracle supports a lot of flexibility in building custom security. However sometimes customer's maybe overwhelmed and find all this very confusing. This post provides a brief overview of the purpose of each and when to use them.

WLS Custom Authenticator (or Custom Authentication Provider)

Weblogic provides the ability to build Custom Authentication Providers. WLS documentation describing how to build "Security Providers" is described here.

When should you build it?

Typically you build a custom authentication provider - when your users are stored in "custom" repository.

Ex#1: Let's say you have users in a mainframe repository and you cannot use the OOTB Ldap or SQL Authentication Providers.

Ex#2: The users are stored in DB but the schema is custom and so the OOTB SQL Authentication Provider does not work.

We will use the terminology "Identity Store" to identify a repository where users are stored.

OPSS Custom Identity Store Service

OPSS supports the ability to configure the "Identity Store" service as part of a weblogic domain via the "jps-config.xml". OPSS OOTB currently does not support Oracle DB as an "Identity Store". If you have users in a DB or mainframe system - you may want to build a custom identity store service.

 

When should you build it?

The OPSS Identity Store service can be used to retrieve user profile information. Ex: If you want to retrieve the email of user in the "Identity Store".

OPSS provides what is called User/Role APIs and these APIs ultimately need to talk to the "Identity Store" to retrieve user profile information.

You can find details about the OPSS Identity Store service here.

OWSM Custom Assertion

I have briefly described about OWSM Custom Assertion/Policy support in this blog post.

When should you build it?

There are many scenarios where you may want to build a custom assertion.

Ex#1: Let's say you need to support a proprietary token (ex: CA SiteMinder Token) in your Web Services for authentication.

Ex#2: You want to support say a JWT token for your Web Services for authentication.

Hopefully this clarifies some of the confusion.

Note: There are a lot of nuances to each of the scenarios described in this post. I have tried to keep the post at a high level and gloss over many of nuances for purposes of brevity.

Friday Mar 30, 2012

OSB Security using OWSM - 11g

Here is a very nice video showing how OWSM can be used to secure OSB from Oracle.
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