Monday Jan 14, 2008

RESTful Identity Services - Service Registration

Alright, so in the previous 2 posts I described our overall approach for RESTful identity services and the core scenario we're thinking about. In this post I'm going to explore in a bit more details what happens during the first phase of our scenario: service registration.

One word of caution: this work is evolving quite rapidly so things I present here MAY (and will) change...

In our scenario, our service provider Calendar.com needs to registers itself at our Discovery service. To do so, Calendar.com needs to upload metadata that describes its service at a well known endpoint of the Discovery service. The service metadata we use is derived from what Liberty defines in ID-WSF2.0 although we have simplified it quite a bit. We describe RESTful services with the following metadata:

  • Abstract: some text describing the service
  • ProviderID: a URI that (uniquely) identifies the service (e.g. something like http://Calendar.com in our example)
  • ServiceContext is a complex type with the following elements:
    • ServiceType: this is the type of service. An example of this would be "calendar".
    • OneTimeURI: this is an element that describes whether this service supports our 1-time URI mechanism or not (described in a subsequent post)
    • RegURI: this is the registration URI. This element, assigned by the DS, contains the URI that points to the service metadata. Since it is a resource (in the REST sense) it can be acted upon (e.g. an HTTP DELETE on this URI corresponds to an unregistration).
    • SecurityMechID: this describes the security mechanisms supported by Calendar.com.  For instance whether it support HTTPS or not.
    • Options: used to describe optional features of the service

So, to register its service at the DS, Calendar.com generates the above metadata and send it to the DS at the /SvcMDRegister URI as shown in the illustration below:

Service Metadata Registration


Monday May 07, 2007

OpenID at Sun

This is what I've been working on for the last (many) weeks:

Sun is deploying an OpenID enabled Identity Provider (OP in OpenID jargon) for its employees. Any Sun employee will be able to create an OpenID identifier and use it with OpenID enabled relying parties (RP).

Our primary objective is to figure out adequate uses of OpenID in the enterprise context. As SAML and Liberty supporters we know OpenID (1.1) is addressing a different market when it comes to delegated authentication. Its lack of trust establishment between the IdP and the RP is, in my opinion, one of the challenge OpenID is facing in a B2B scenario. By placing the IdP within Sun's DNS and controlling the OpenID identifier format we inject some of that trust in the authentication process. Consider the scenario where a company that does business with Sun offers a discount to Sun employees. In order for me to have access to the employee discount pages at their web site, Company A, in addition to my identity needs to know that I am indeed a Sun employee. I think combining OpenID and a certain for of trust of the IdP is ideal for that kind of scenario.

Our OpenID deployment (1.1 & Simple Reg.) is based on the module that was recently written by Paul Bryan as part of our open source effort OpenSSO. In my next blogs, I'll be posting a lot of tips and howtos directly related to this deployment.

 


Friday Mar 02, 2007

Deep-dive on SAML 2.0 vs. WS-Federation

After my previous blog entries on WS-Federation I received some requests for a more in-depth analysis of WS-Federation and in particular how it compares to SAML 2.0. It took me a while to get to it but I finally manage to spend some time  to do just that.

Below is a table where I compare both specs on various features and technical details. Note that each blue highlight identifies what I think is a plus for the specification (when compared to the other).


Topic

WS-Federation

SAML 2.0

Target

- Browser Redirect (messages in URL)

- Browser POST (messages in HTML form)

- SOAP (over HTTP)

- Artifact

- Browser Redirect (messages in URL)

- Browser POST (messages in HTML form)

- Artifact (reference to assertion + SOAP call)

- SOAP (over HTTP)

- Reverse SOAP (over HTTP)

Security tokens supported

- Those supported by WS-Trust (SAML assertions, X509 certificates, kerberos...)

- SAML assertions

- Any other token types (embedded in a SAML assertions via the SubjectConfirmation element)

Dependencies

- WS-Trust [1], WS-Policy, WS-SecurityPolicy.

- WS-Eventing to subscribe to Single Sign Out messages.

- WS-Transfer & WS-ResourceTransfer.

- None!

Identity federation

- Performed by the Pseudonym service (optional...) which provides identity mapping and its management.

- A Pseudonym service may be independent of an IP/STS and could store tokens associated to a pseudonym. 

- Identity mapping is part of the IdP. Although less (?) flexible it avoids the need for yet another protocol between the pseudonym service and the assertion generator (IP/STS in WS-\*).

- Mapping can be created either by the requestor (principal...) or the owner of the resource (SP).

- Mapping is created by the IdP but can be changed by either the IdP or an SP.


- All operations on pseudonyms (get, set, create or delete) are done via WS-Transfer (and its extension WS-ResourceTransfer to filter the scope of these operations).

- Client-based pseudonyms: a requestor can specify (in an RST) ad-hoc data for a pseudonym it wants to be used by the STS (e.g. PPID, DisplayName, email...)

- SAML does not provide a similar concept to the ClientPseudonym in its AuthNRequest. Is this one of the active requestor “benefit”?
The Name ID management protocol (and SPProviderID) is not meant for transient ID mapping.

Metadata

- Description of the federation metadata format.

- Description of a secure transfer of this metadata.

- Can hold info about several federations.

- Description of metadata for SSO and more.

- Organized by roles (IdP, SP, Attribute requester, PDP...)

Single Logout

- Can be initiated by either an SP or the (primary) STS which will send sign-out messages to all RP.

- Similar

Artifact

- Based on the use of a reference token (i.e. an EPR to which a WS-Transfer GET can be made to retrieve the actual token).

- Artifact profile (complete SAML response)

- URI binding (to only obtain SAML assertion)

- SAML also defines mechanisms to request or query existing assertions (by subject or statement type).

Authorization service

- Again a specialized STS.

- Concept of authorization context (name-scope-value) to condition the issuance of a token.

- The context seems to be a kind of pendant to the SAML2 XACML profile...

Authentication freshness

- A requestor can specify its freshness requirements (allow caching of security tokens etc.)

- Similar with Conditions and ForceAuthN

Authentication level

- WS-Trust defines the parameter (AuthenticationType). WS-Fed specifies predefined values (e.g. Ssl, SslSndKey, smartcard).

- SAML 2.0 offers a much broader & extensible set of authentication contexts.

Privacy

- A requestor can express its protection requirements for security tokens it requests (protectData w/h claims & confirmation from STS).


- Privacy statements can be retrieved via WS-Transfer.

- SAML offers a range of options to constraint the use & scope of an assertion (audience, advice, proxyRestriction, oneTimeUse, condition) [2]


- Those constraints can originate from both the SP or the IdP.

 
[1] WS-Federation basically extends WS-Trust to allow the issuance of tokens that can carry attributes or pseudonyms.

[2] One would argue that this could be achieved with WS-Policy but SAML has the advantage of offering built-in ones.

 
So what to think of all that? Well as already mentioned in previous blog I find WS-Federation to be very similar to SAML. I also think SAML is a more self contained specification; because of its composability approach, WS-Federation allows you to tune your deployment in many ways but it is done at the expense of simplicity. One has to go tweak WS-Trust or WS-Policy etc.

Some examples of what I can easily do with SAML 2.0:

  • I want to silently check whether the user is authenticated (I don't want the IdP to perform authN): set <IsPassive> to TRUE

  • I need an assertion with constrained validity or use: apply SAML's <Conditions>

  • I only accept authentication assertion from a list of IdPs: use <Scoping>

  • etc.

I have no doubt you can achieve this with the "right" combination of WS-Fed / WS-Trust / WS-Policy (and probably other specs) but with SAML it's all there...

 



Friday Dec 22, 2006

SAML vs. WS-Federation

Following my recent post on the (very) quiet publication of W-Federation, I was pointed at this excellent document that compares SAML and WS-Federation and explains why SAML is a better choice. This document is even more remarkable when one notices that it has been written by people working for the Government of Denmark obviously an impartial 3rd party.

I highly recommend this reading if you're in the process of selecting technology for identity federation or if you're just interested in understanding both specifications and some of their key differences. For those who don't have time I'm reproducing the main table in the Danish document below (I did not ask for permission but hopefully it's ok...):

 requirements  SAML2.0  WS-Federation
 Functionality related to requirements
Equal Equal 
 Support of the standard in commercially available products
 Advantage  
 Microsoft support
   Advantage
 Proven usability from use in solutions in production
 Advantage  
 Assessments by analyst companies
 Advantage  
 Based on an adopted standards (e.g. within OASIS)
 Advantage  
 Interaction with the other adopted standards, XACML and SPML  Advantage  
 Future development of the standard  Consolidation is expected
 Consolidation is expected
 Third party Interop Testing/Interoperability Certification  Advantage  

 

The document goes into more detail for each of those requirements and how the came to the conclusion presented in the table. I think this is a fair assessment of the situation!

 

About

hubertsblog

Search

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