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 needs to registers itself at our Discovery service. To do so, 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 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  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, generates the above metadata and send it to the DS at the /SvcMDRegister URI as shown in the illustration below:

Service Metadata Registration

Saturday Jan 12, 2008

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 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 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 and book a ticket.
  2. offers to update my online calendar, should I have one. Since I do have such service (at, I accept the offer.
  3. finds out that my calendar service is hosted at and figures out the specifics of this service (more details on that later).
  4. contacts 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 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, 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, purchase a ticket and accept the offer to update my online calendar.
  4. 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, can now update my calendar that is hosted at
In order for the last step to be possible, 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: 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. registers itself at my Discovery service and then associates itself with my identity there (at my Discovery Service)
  2. A service consumer (e.g. 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.

Thursday Jan 10, 2008

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.




« October 2016