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.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
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