Sunday Aug 11, 2013

How To - Identity Propagation for REST using OWSM - 12.1.2

This is a follow up to my previous blog post, in that post I provided step by step instructions on how to secure a REST service and client built using Jersey JAX-RS technology that ships with Weblogic.

In this post I am providing a pointer to a detailed step-by-step instructions on how to do identity propagation for REST.

I strong encourage people read up on the previous How Tos covered in the following blog posts before attempting the How to provided in this post:

https://blogs.oracle.com/owsm/entry/how_to_owsm_12_1

https://blogs.oracle.com/owsm/entry/how_to_securing_rest_services

https://blogs.oracle.com/owsm/entry/how_to_securing_rest_clients

Tuesday Jun 18, 2013

REST security and Federation - 11g

In my previous blog post on REST security I talk about how one could do identity propagation. That post generated some comments around how one could do federation for REST services.

The short answer is it depends on the type of client:

a) For non-browser type of clients - you can leverage an STS for doing federation for REST similar to SOAP services.

b) For browser type of clients - you could leverage Web Federation models.

STS based REST federation:

REST security federation

In this model however you will need to create a SOAP RST/RSTR to talk to an STS. There are some recent standards where you can talk to Security services that provide equivalent functionality as STS via REST binding instead of SOAP binding (Open ID Connect, etc). [Note: These are currently not supported by Oracle.]

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.

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.

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.

Monday Apr 16, 2012

Oracle BPM and OWSM - 11g

The Oracle BPM team has an article on how to use OWSM with Oracle BPM. The article covers specifically how to use OWSM SAML based identity switching policy (I briefly talked about the SAML identity switching feature in OWSM in the blog post).

Hope people find it useful! (There is a typo in the title it should say BPM 11g: Configuring SAML Web Service Clients for Identity Switching without Message Protection).

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.

Sunday Oct 09, 2011

SAML support in OWSM - Best Practices - Part#1 - 11g

As mentioned in my past posts Ediwn Beimond has a great post on SAML support in OWSM. He covers the following scenarios:

  • A basic SAML authentication with 2 OWSM Servers.
  • Change the default SAML issuer name.
  • Allow only trusted SAML clients.
  • SAML Identity switching.
  • Virtual Users with User roles.

His post provides a detailed How-To describing things step by step on how to use these features. I thought I can perhaps shed some light on when to use these features and the best practices around usage of SAML. In addition starting with Oracle FMW 11gR1 PS3 - OWSM started supporting SAML 2.0 in addition to the SAML 1.1 - I will also discuss when to use SAML 1.1 vs. SAML 2.0.

The SAML wiki provides a good general overview.

SAML versions:

There are many blog posts on the topic of what is available in SAML 1.1. vs. SAML 2.0 - so I won't go into the technical differences here. If you are interested here is a document that describes the differences. (Of course you can search with your favorite search engine for additional materials).

The general SAML specs apply for a wide variety of scenarios - beyond Web Services Security. So some of the technical differences are not relevant. The OASIS WS-Security SAML Token 1.1 Profile specification describes the relevant differences from a WS-Security perspective. (See section 3.2).

In general I would recommend people use SAML 2.0 where possible.

The technical differences maybe one of the factors that you can use to make a determination. However there are probably other aspects that may drive this decision for you. The most frequent ones we encounter are:

  1. If you are in the Government or Department of Defense sector - then in most cases SAML 2.0 is mandated.
  2. If you need interoperability with "legacy" Web Service Security stacks - then you may need to consider using SAML 1.1 as it is more prevalent. 
So to summarize - in some cases - the version you end up using may be determined by what the "other side" your partner or external entity your web service is talking to supports.

SAML Confirmation Types:

The WS-Security spec defines 3 confirmation methods for SAML:

a) Sender vouches (SAML SV for short)

b) Holder of Key (SAML HOK for short)

c) Bearer

The table below tries to summarize the key differences b/w the three confirmation methods (I copied this table from this blog as it provides a pretty succinct summary of the differences):


Method

Spec Description

English Description

Benefits

Drawbacks

holder-of-key


The holder of a specified key is considered to be the subject of the assertion by the asserting party

“Verify this signed blob to reconfirm the subject”


Strong authentication by the receiver  of the subject.


Additional per-message signature verification processing. Requires additional trust processing for the public key;

sender-vouches


Indicates that no other information is available about the context of use of the assertion


“Just trust me”


Fast and simple, no additional signature processing; if you trust the sender no additional processing is required

No additional confirmation possible; may require out-of-band or additional authentication

bearer


The subject of the assertion is the bearer of the assertion, subject to some optional constraints

“I am the subject”

Fast and simple, no additional signature processing

No additional confirmation possible; may require additional out-of-band or additional authentication

I will cover more on the SAML subject confirmation methods in the future - but the above table should be a good starting point. SAML HOK is probably most secure and provides centralized trust but is also has more performance impact and requires an STS.

In general - for public facing web services (i.e. web services) made available over the internet - I would recommend using SAML HOK. For departmental web services or web services used within the intranet - SAML SV or SAML Bearer maybe more appropriate.

SAML Identity switching

SAML is typically used for identity propagation, not for identity switching. However there are scenarios - where you may need to switch identities because you have the user id but not the password.

In general this would not a common scenario and if you want to switch identities - the general recommendation would be to use username token (or perhaps x509 token) policies.

Another thing to note is that when using SAML Identity switching policy - there is a limitation in that we don't allow propagating user roles and user attributes from the client to the service (as I mentioned in this blog post).

In a future blog post - I plan to discuss use-cases where SAML based Identity switching would be appropriate - rather than username token or x509 token.

SAML Issuer List & SAML Trusted DN

As a best practice - I would recommend people configure the SAML issuer list and the Trusted DN's for that issuer list.

The out of the box value for the list of trusted issuers is "www.oracle.com" and I highly recommend that you change this in your environment to right SAML Issuer. While OWSM provides you the flexibility of configuring the issuer of a SAML assertion on a per client basis - I would recommend configuring the issuer at the domain level (just from a manageability perspective).

Virtual User

The virtual user functionality is typically useful for products that act as intermediaries. (ex: OSB, OEG, etc). In the virtual user scenario - the user in the SAML assertion is not validated against an identity store (hence the name virtual user).

If you are using intermediaries like OSB, OEG to front-end many web services belonging to different security domains, where each domain has it's own identity store (user repository), then trying to validate the user in OSB, OEG is not very meaningful.

In a future blog post I plan to provide additional information around use-cases where virtual user functionality is typically used - but for now the key takeaway is - it is typically not useful to use this functionality for back-end web services.

Friday Sep 16, 2011

SAML Identity switching policy - Limitations - 11g

This post from Edwin Beimond talks about the various SAML features in OWSM. However there is one quick thing I wanted to note: The inclusion of user attributes and roles is NOT supported when you are using the SAML Identity switching policy in the current release (11.1.1.5.0).

The documentation is not necessarily very clear on this front.

Note: This may change in a future release - however for now the above limitation exists.

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