Tuesday Apr 16, 2013

.NET interoperability, Kerberos, SPNEGO, Id Propagation - All things Microsoft! - OWSM 11g - Revisited

In a previous blog post - I briefly talked about interoperability with Microsoft and support for Kerberos, SPNEGO, NTLM, etc in OWSM. So I wanted to revisit that post and address a few aspects:

SPNEGO support

In that blog post - I mentioned that SPNEGO is something we don't support in OWSM.

In PS6 with the introduction of the support for REST security - we also added support for SPNEGO. While the key driver was REST services and securing REST services - we support SPNEGO policies for HTTP/SOAP services as well.

In fact one of things customers will notice is that many of the policies introduced for securing REST services are also supported for HTTP/SOAP web services.

SPNEGO support is documented here:

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/policies.htm#CHDEJIIF

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/assertions.htm#CHDBICJC

http://docs.oracle.com/cd/E28280_01/web.1111/b32511/policies.htm#CJAIEDEG

Note: OWSM still doesn't support NTLM.

Interoperability with Microsoft environments.

One of the most common questions from customers is around can we use SAML to do identity propagation b/w Microsoft and Oracle based environments and the use of ADFS as the STS for enabling SAML based identity propagation.

In PS6 - we have certified with ADFS ( in addition to the certification with Oracle STS, OpenSSO STS).

Client side Kerberos support

It appears that many people looked at the figures in the previous blog post and assume we don't support Kerberos on the client side in OSB. I just wanted to clarify that we do in fact support Kerberos policies on the client side - so for - you can do the following:


The key limitation is that you cannot use kerberos across multiple hops as I mentioned in the previous blog post. However you can definitely use Kerberos policies to secure your web services clients.

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.

Wednesday Aug 15, 2012

.NET interoperability, Kerberos, SPNEGO, Id Propagation - All things Microsoft! - OWSM 11g

One of the most common questions I run into relates to .NET/WCF interoperability with OWSM.

First - officially OWSM certifies a few interop scenarios with .NET. These are covered in the OWSM Interop guide

They key scenarios certified for interop involve Username Token, X509 Token and Kerberos Token via the WS-Security Kerberos Token Profile.

The next question I hear is around how do we do Identity Propagation when we have .NET.

Scenario#1: Identity Propagation b/w WCF Client and OWSM/Fusion Middleware using Kerberos and SAML with OSB as active intermediary


Note: Instead of OSB you can use SOA Suite as well and that would work as well.

Scenario#2: Identity Propagation b/w WCF Client and OWSM/Fusion Middleware using Kerberos with OSB as passive intermediary


Note: The passive intermediary model applies for OSB (or OEG) but not for SOA, since SOA does not support passive intermediary model.

Scenario#3: Kerbeors based Multi-hop Identity Propagation b/w WCF Client & OWSM/Fusion Middleware and OSB as active intermediary


In this scenario - customer's want to use Kerberos for Identity propagation across multiple hops. This is currently not supported.

Scenario#4: Kerbeors based Multi-hop Identity Propagation b/w WCF Client & WCF Service and OSB as active intermediary


In both scenario#3 and scenario#4 in order to use Kerberos for multi-hop end-user identity propagation, you need to support either the end user TGT or the S4U Extension. Neither of these are currently supported in OWSM.

Scenario#5: Using SAML for end-to-end identity propagation.


So another way to do end-to-end identity propagation that will work with OSB or SOA Suite is to SAML. WCF/.NET supports talking to an STS to exchange a kerberos token for a SAML token and then SAML can be used across multiple hops.

Note:

1) While this scenario has not been certified explicitly by OWSM, it should work since OWSM supports WS-Trust.

2) In the diagram I use Oracle STS but any STS can be used as long as that STS supports exchanging a Kerberos token for SAML token.

I have not listed all the possible scenarios here - but hopefully this provides a sense of what is possible today and what is not possible.

SPNEGO

I also see a lot of questions around SPNEGO support. OWSM currently does not support SPNEGO. You can read all about SPNEGO here

One could build a custom assertion to add SPENGO support in OWSM. However you need to keep in mind that with SPNEGO unlike the WS-Security Kerberos Token Profile, the Kerberos Token is actually in the HTTP reader rather than in the SOAP WS-Security header.

So the Kerberos token is wrapped in the HTTP header under the auth-scheme called "Negotiate". The WWW-Authenticate and Authorization headers are used to communicate the SPNEGO token between client and service. This is explained in the steps below:

  1. The client requests access to a protected document on the server without any Authorization Header.
  2. Since there is no Authorization Header in the request, server responds with 401 Unauthorized and WWW-Authenticate: Negotiate.
  3. The client will use the user credentials to obtain the token and then send it to the server in the Authorization header of the new request.For e.g.,   Authorization: Negotiate a87421000000492aa874209
  4. The server will decode this token by passing it to the acceptSecContext() GSSAPI. If the context is not complete (in the case of Mutual Authentication) the server will respond with a 401 status code with a WWW-Authenticate header containing the GSS-API data. For e.g., WWW-Authentiate: Negotiate 74900a2a...
  5. The client will decode this data and send new data back to the server. This cycle will continue until the security context is established.

Since there is request/challenge model - typically the SPNEGO security model is harder to accomplish in intermediaries like OSB/OEG - if they are acting as "passive intermediaries". An active intermediary model maybe more appropriate.

For OSB itself there may be an alternate model to supporting SPNEGO. There is an excellent post from the A-Team on OSB & SPNEGO (Note: It deals with OSB 10gR3). Here is another post that covers SPNEGO

NTLM

The next question that often comes up is around NTLML support.OWSM currently does not support NTLM. As this wikipedia entry on SPENGO describes - NTLM is a variant.As you can see Microsoft no longer recommends NTLM. However if customers really want to support NTLM - they can build a custom policy.

About

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

Search

Categories
Archives
« July 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
31
  
       
Today