C'est la vie !

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:

Posted at 08:53PM Jan 14, 2008 by Hubert A. Le Van Gong in Identity  |  Comments[3]

RESTful Identity Services - Core Scenario

In yesterday's post I introduced the work we're doing at Sun's CTO labs on integrating identity concepts within a RESTful framework. Before I post more technical details on how we do that I thought it would be better to give an overview of our core scenario.

Let's imagine the following scenario: I book a trip on a Travel.com. Part of the features that makes this site attractive to me is that it can automatically update my online calendar, which it offers to do as soon as I have purchased my ticket. It is important to note that my calendar service (let's call Calendar.com) has no particular relationship with the travel service I use to book my trip. In fact I could change my calendar service at any time (or use another travel site). This scenario is quite simple but it will allow me to go through the various phases that need to take place.

At the highest level, 4 steps need to take place:

1. I visit Travel.com and book a ticket.
2. Travel.com offers to update my online calendar, should I have one. Since I do have such service (at Calendar.com), I accept the offer.
3. Travel.com finds out that my calendar service is hosted at Calendar.com and figures out the specifics of this service (more details on that later).
4. Travel.com contacts Calendar.com and updates my calendar there (on my behalf).
   

Many things need to happen under the hood, but one of the most interesting aspects of this scenario is the fact that we want services to be able to discover various other services that are associated with my (online) identity. In this case, the Travel site does not want to discover any calendar service, it wants to discover my calendar service.

How do we go about solving this discovery problem? One solution, proposed by Liberty Alliance, is the concept of a Discovery service. A Discovery service is an online service where a user can federate many services around his identity thus enabling their discovery. This is a powerful concept and our RESTful solution uses the same concept.

At a slightly more technical level, by including the Discovery Service notion we now have the following steps:

1. At some point in time (prior to my ticket purchase) I visited Calendar.com and was asked if I wanted to associate this service with my account (i.e. my identity) at my Discovery service (I'll leave the details on how the Calendar service knows about my Discovery service out for now).
2. When I consent, Calendar.com sends a request to associate itself with my identity there. Doing so, my calendar resource becomes discoverable by other services that can talk to my Discovery service.
3. I visit Travel.com, purchase a ticket and accept the offer to update my online calendar.
4. Travel.com performs a lookup query at my Discovery service to find out where my calendar service resides and retrieve details about it.
5. After it gets the information, Travel.com can now update my calendar that is hosted at Calendar.com.
   

In order for the last step to be possible, Travel.com needs information (metadata) about my calendar service (where it is, the security mechanisms it supports, etc.). We thus need to add a preliminary step to this sequence: Calendar.com registers its metadata at my Discovery service.

This scenario highlights the 3 core steps I described in my previous blog entry:

1. A service provider (e.g. Calendar.com) registers itself at my Discovery service and then associates itself with my identity there (at my Discovery Service)
2. A service consumer (e.g. Travel.com) discovers the location and metadata of the service that it wants to access on my behalf
3. This service consumer invokes the service provider to carry out some function (e.g. update my calendar).
   

This 3-step process corresponds to the core use case provided by Liberty's ID-WSF framework. It is also the core scenario we aim at enabling in a RESTful manner.

Posted at 10:03AM Jan 12, 2008 by Hubert A. Le Van Gong in Identity  |  Comments[2]

RESTful Identity Services

One of the interesting evolution of online services is this sort of schism between 2 camps: the XML/SOAP based web services camp and the REST camp that's based on HTTP. For having spent considerable time in Liberty Alliance (working on ID-WSF etc.) I've noticed however that the notion of identity has not yet fully permeated into the REST world the way it did with a framework like Liberty's ID-WSF. In this post and the following ones I'd like to introduce some work we've been working on at Sun: a RESTful approach for identity-based services.

Our approach has been to leverage core use case that Liberty's ID-WSF supports and see how one would go about enabling such use case in a RESTful manner. Initially, we addressed the 3 following core phases that take place in such scenario, that is:

1. Service Registration & Association with a principal's identity
   
2. Service Discovery
3. Service Invocation

These phases can be described as follows:

• Service Registration addresses the ability of a service provider to register itself at a Discovery Service (explained later) thus making itself discoverable by other services. It also enables a principal to associate services around his identity.
• Service Discovery is about the ability of a service (consumer) to discover services associated with a principal's identity.
• Finally Service Invocation is about accessing the service that has been looked up (discovered).

It is important to note that this is more of an R&D project for now. Our goal is to figure out how identity can be fully leveraged in a RESTful approach and get as much feedback as possible.

In the following posts I will detail each of the 3 aforementioned phases.

Posted at 08:56AM Jan 10, 2008 by Hubert A. Le Van Gong in Identity  |  Comments[1]

OS X - We want Java 1.6!!

Finally Leopard's arrived and I successfully upgraded my powerbook. I have not experienced any compatibility issue so far, so I'm quite pleased with it.

The only thing that really bugs me is the absence of Java 6 - still not there!

No need to say this was quite disappointing as the rest of the Java world (that is almost every other platform - Solaris of course but also Windows and Linux) has now moved on to Java 6. It's even more surprising as I've been told that Apple's server market is doing well so one would think that keeping their Java release on par with the competition is important. Unfortunately, as JamesG explained here there's nothing we can do here at Sun. So please Apple, hurry up and release Java 6!

And just to make sure we have a better chance of being heard, my colleague Henry Story has created a string we should all post on our blogs so here we go:

13949712720901ForOSX

The first part of the string is the decimal notation for CAFEBABE - of course
If you're interested in using Java 6 on OS X I highly recommend you do the same and soon enough googling for this string in your  prefered search engine will give you all the blogs that discuss this issue.

 

Posted at 03:51PM Nov 02, 2007 by Hubert A. Le Van Gong in Java  |  Comments[3]

OpenID @ Work - Infrastructure Description

In my previous post I described our OpenID@Work overall architecture and flow. In this post I describe the deployment we adopted for this. A picture being worth a thousand words, here's an illustration of our deployment:

All traffic arrives through a load balancer that also serves as firewall and SSL terminator. The servers behind the firewall are run on a VIP. Server 1 runs Web Server 7 (more info here) on which we run the 2 instances of OpenSSO, the OpenID extension and the OpenID pages server (see previous post for details). Server 2 is a mirror of Server 1, mostly for load balancing and failover if needed. The users accounts are stored mirrored LDAP servers (servers 3 & 4). We use Sun Directory Server and plan to move to OpenDS soon.

For those of you interested, our servers specs are:

x2200 M2 with the following specs:
- 2 dualcore AMD Opteron Model 2218
- 8GB RAM (4x2GB DIMM)
- 2x250GB SATA HDD

Posted at 11:03PM Jun 14, 2007 by Hubert A. Le Van Gong in Identity  |  Comments[0]

OpenID @ Work - Architecture

We finally officially launched our OpenID@Work identity provider for Sun employees (last week)!

I now have some time to describe in more details what we our service is and its architecture. This blog entry will describe the architecture we have put in place and to some extent explain our choices.

First off, here's a high-level overview of the OpenID protocol flow.

The steps are as follows:

1. The user visits a web site (relying party - RP) that requires authentication. The web site being OpenID enabled, the user enters her OpenID identifier.
2. The RP retrieves the corresponding html page. That page contains information on where the OpenID@Work provider (OP) is.
3. The RP redirects the user's browser to the OP
4. OpenID@Work performs authentication of the user
5. Upon successful authentication, the user's browser is redirected to the RP and logged in.

Now back to Sun's OpenID deployment. Below is the list of constraints we put on this deployment:

• The OpenID@Work service is only for Sun employees.
• This is an opt-in program so Sun employees that want a Sun OpenID need to register.
• OpenID@Work is an OpenID provider, not a relying party.

Now onto the architecture of our deployment. The figure below describes the overall architecture of our deployment.

 

The steps are the following:

1. Registration phase - the user needs to go through a specific phase to register and obtain his/her Sun OpenID ID. The main difference with a standard registration is that Sun needs to make sure the principal is indeed a Sun employee. I'll describe those steps later on. This step leverages the OpenSSO's Membership module and is run in a separate instance.
   
2. The user visits the RP and provides his/her OpenID ID (the URL).
3. The RP obtains the URL from a web server instance (HTTP based) that only serves OpenID IDs (and FAQs)
4. The RP talks to the OpenID module (an extension to OpenSSO) to create association key etc.
5. The RP redirects the principal's browser to the OpenID instance for authN. The OpenID module will communicate with the second OpenSSO module and, if there is no valid session, OpenSSO will prompt the principal for authentication.
6. The principal can at anytime log into the second OpenSSO instance to manage his/her profile (e.g. change password etc.).

In my next postings I will describe in more details some of the aspects mentioned above.

Posted at 03:21AM Jun 14, 2007 by Hubert A. Le Van Gong in Identity  |  Comments[2]

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.

 

Posted at 09:55AM May 07, 2007 by Hubert A. Le Van Gong in Identity  |  Comments[1]

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...

 

Posted at 10:24AM Mar 02, 2007 by Hubert A. Le Van Gong in Identity  |  Comments[2]

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 3^rd 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!

 

Posted at 10:00AM Dec 22, 2006 by Hubert A. Le Van Gong in Identity  |  Comments[1]

Too Tagged To Ignore It...

Okay, I've now been tagged by at least 3 different esteemed colleagues (Conor, Gerry and Paul - alphabetical order so as to not favor anyone) so I guess I need to act upon it. So here we go:

1. My paternal grandfather (Dr. Nguyen Van Thach) was a politician in Vietnam (Saigon). Although he too was favoring independence (from the French) he got assassinated by the Communists in 1946 hence triggering the exodus of my family to France.
2. I always wanted to be a fighter pilot but my eyes failed me...
3. My favorite seasoning is the nuoc-mam (aka. fish sauce). My wife always complains that I put it on every dish thus ruining them (what can I do? I grew up with that!)
4. I may have some British ancestor (shocking!)
5. Here's a secret recipe for beautiful children: ethnic mixity. Mine are half French, a quarter Cantonese and a quarter Vietnamese and they're beautiful! 

I guess I should tag other people now...hmm...since I've waited too long it seems pretty much everyone in Identity has been tagged already!
Wait I know who has been spared so far: Brett, Timo, Takashi You're it!

Posted at 04:41PM Dec 20, 2006 by Hubert A. Le Van Gong in General  |  Comments[0]

WS-Federation version 1.1 is out, 3 years after...

So, it seems Microsoft, IBM & al. have decided to release a new version of WS-Federation, more than 3 years after their first version. I've done a quick read on it and listed some of the most noticeable changes below:

• Structurally there is now only one document. The passive, active and various interoperability profiles have all been combined in this single document. I tend to think this is a good thing since all these profiles were certainly creating confusion. IMHO they were also showing a certain lack of testing before the first publication hence leading to the need for additional interoperability profiles (but I'm being controversial here...).
• All the protocols have been combined in a single big section (13)
• The focus seems to be more on the active requestor rather than the passive profile which is mainly addressed in section 13.6

There are some new features in this spec too:

• Federation metadata: with the concept of context to describe the fact of belonging to one or more federation (what SAML or Liberty Alliance calls Circle of Trust (CoT))
• Authorization service & Pseudonym service: these are basically specialized versions of an STS in order to be able to include either attributes or pseudonyms along with the token that's being issued.

At this point it really looks like WS-Federation 1.1 is mimicking most of SAML2.0 functionalities although I think there are a few differences that I'll explore in a forthcoming post.
Finally, can someone tell me why in a world they decided to expand SSO as single sign-out when everyone else in the industry understands it as single sign-on ?!  Talk about confusing people...

 

Posted at 03:09PM Dec 20, 2006 by Hubert A. Le Van Gong in Identity  |  Comments[3]

HOWTO: Creating & Mounting a Solaris partition on a USB disk drive

For a change, this entry will not be about web services or identity management. It's all about using Solaris commands to create a Solaris partition on a USB removable disk drive. Since I didn't find anything that looked like a short HOWTO for this I thought I'd create a post on that so here we go:

1. /etc/init.d/volmgt stop

   This turns off vold - not always friendly with usb mass storage devices)

2. svcs volfs

   It should show volfs as disabled (after step 1).

3. rmformat -l

   To list the removable devices; this allows to figure out where is my usb disk! (/dev/rdsk/c4t0d0p0 in this example).

4. fdisk /dev/rdsk/c4t0d0p0

   To create the main Solaris partition. If no partition were initially present, just answering yes to the subsequent question will assign 100% of the disk to Solaris.
   side note: some of you may remember that Linux & Solaris did not like to be on the same disk since Solaris uses the same file format type number than Linux...Well the good news is that one can (and should) use the Solaris2 type so as to avoid those conflicts.

5. /rmformat -s /tmp/my_slices /dev/rdsk/c4t0d0p0

   Where my_slices is a text file that describes my slices in the partition. Note Solaris has one "main" partition that you divide in slices (8 max). The slice #2 represents the entire filesystem while others are your own partition). An example of such file would be:
   

   slices:    2 = 0, 350GB, "wm" "backup" :
                  8 = 0, 350GB, "wm", "name"

6. prtvtoc /dev/rdsk/c4t0d0p0

   To display the toc on the usb disk and make sure the change took effect.

7. newfs -v /dev/rdsk/c4t0d0s8

   Assuming you've labeled your partition as #8 (like in the example above).

8. mount /dev/dsk/c4t0d0s8 /mnt

   Note that it is 'dsk' and not 'rdsk' since we're now addressing the disk in block mode and not the raw disk when we wanted to format it.

 

That's it, you now can stuff this partition with plenty big files or use it as a backup media (my case).

 

 

 

Posted at 09:20AM Dec 19, 2006 by Hubert A. Le Van Gong in General  |  Comments[5]

IIW2006b - SAML / Liberty presentation

Today was the initial "level-setting" day at the Internet Identity Workshop in Mountain View, California. Some interesting presentations (e.g. Osis or OpenID) although the bulk of the discussions will be happen tomorrow and the day after.

Of special interest (Yes this is a biased statement) is Eve's presentation on SAML and Liberty. I think this is a great (short) primer on what OASIS (SAML) and Liberty Alliance (ID-WSF) have done. The slide set ends on a topic we hope will generate more and more excitement in the near future: a convergence path between SAML and OpenID.

Stay tune!

 

Posted at 10:26PM Dec 04, 2006 by Hubert A. Le Van Gong in Identity  |  Comments[1]

Java is now Open Source!

Posted at 09:00AM Nov 13, 2006 by Hubert A. Le Van Gong in Java  |  Comments[0]

Federation Manager Bootcamp - we have contact...

Posted at 02:17PM Nov 07, 2006 by Hubert A. Le Van Gong in Identity  |  Comments[1]