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.

Sunday Jul 29, 2012

OPSS vs. OWSM 11g

Have been a bit busy and so blogging has been slow - but I recently came across this blog entry and I thought it would be worth clarifying about the relationship between OPSS and OWSM.

OPSS - Oracle Platform Security Services - provides a security framework and acts as the underlying security layer that addresses both FMW security requirements as well as the base for all the Identity and Access Management products.

Details can be found here.

There is a nice white paper accompanying the recent IDM 11gR2 release - that describes the foundational nature of OPSS. (Yet more material on IDM 11gR2 can be found here.)

The primary security services provided by OPSS include:

a) Authentication Services via Login Modules

b) Keystore Service

c) Credential Store Service - used for storing secrets like passwords (credentials).

d) Audit service

e) Authorization

OWSM is primarily focused on security for Web Services and provides a policy based security model. OWSM implements the various WS-* standards and  leverages OPSS authentication service, Keystore service, Audit service, credential store service, authorization service, etc.

Wednesday Sep 07, 2011

Custom Policies & Custom Assertions - 11g

I came across this blog entry by Izzak de Hullu on OWSM Custom Policies; while I really appreciate Izzak's inventiveness and feedback and we are working on improving things here - I thought I should comment on a few things.

The first thing to note about the blog entry is you can actually sign only particular elements in the SOAP message rather than the entire body. While it is true that the out of the box policies only support signing/encrypting the body of the message, like I mentioned in the OWSM Concepts - 11g post - you can define new OWSM policies using FMWCTL.

So to achieve the use-case Izzak was attempting - To sign/encrypt particular elements - you can do the following:

  1. make a copy of "oracle/wss11_message_protection_service_policy" - let's call it "acme/wss11_message_protection_elements_service_policy". (See section "Creating a Web Service Policy from an Existing Policy"
  2. edit the policy to remove signing/encryption of the body and add elements to be signed and encrypted. This is described in the Security and Administrator's Guide unfortunately - it is in the appendix under the section "Predefined Assertion Templates". See Table titled "Request, Response, and Fault Message Signing and Encryption Settings"

The second and probably the more important thing to note is that Izzak is using some methods that are not exposed by the OWSM Extensibility Guide. This is not something I would recommend - as these methods are subject to change.

In a future post I hope to have a sample how to that describes this in detail.

Tuesday Sep 06, 2011

OWSM Concepts - 11g

Jiandong has posted a number of articles introducing OWSM 11g at http://blogs.oracle.com/wssi/.

This post elaborates on some of the aspects discussed in those posts. There are three aspects to securing a web service using OWSM

  1. Defining Policies
  2. Attaching Policies
  3. Setup Configuration required for Policies
(Note: While this post focuses on security, this is true for other policies like WS-RM, etc as well)

Defining Policies

Policies in OWSM are defined generically without context i.e. in general they are not App specific. There are some types of security policies that tend to be App specific - we will blog about this in a future post.

How to define policies?

You typically define policies using FMWCTL (Fusion Middleware CTL). The Security And Administrators Guide provides detailed documentation on how to define policies. (See Section Managing Web Service Policies ).

A Policy can be composed of a number of "Assertions". Typically you will have atleast one Assertion in a Policy.

Attaching Policies to Policy Subjects

Once a Policy is defined - you can "attach" the Policy to a Policy Subject. A Policy Subject is either a Web Service or a Web Service Client. OWSM supports a variety of Web Services [ex: Oracle Infrastructure Web Services, SOA Web Services, ADF BC Web Services, OSB Proxy Service, WLS JEE JAX-WS, Oracle WebCenter WSRP, etc] and Web Service Clients [ex: SOA References, ADF Web Service Data Control (WSDC), OSB Business Service, WLS JEE JAX-WS Clients, WebCenter Portal, etc]

How to attach Policies?

There are three ways to attach OWSM Policies:

a) Via IDE's - ex: JDeveloper

b) Via Command Line Tooling - ex: WLST

c) Via Web based user interface - ex: FMWCTL

(b) and (c) are discussed in detail in the Security And Administrator's guide. Specifically see Section "Attaching Policies to Web Services" for details.

Note: WLST is not support for OSB and WLS Web Services/Web Service Clients as of 11.1.1.5.0.

Setup Configuration required for Policies

 Most Policies (esp. "security policies";) require additional configuration. For example:

  1. Message protection policies require Keystore setup.
  2. Passwords require OPSS Credential store setup,
  3. Authentication policies require Identity Store setup
  4. WS-Trust based policies require STS

This is discussed in detail in the Section "Setting Up Your Environment for Policies".

From our interactions with customers, support, etc - it appears most people seem to trip up on the last aspect. In future blog posts we will elaborate on some of the concepts introduced in this blog post as well as describe in detail the "Setting Up Your Environment for Policies".

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