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

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.


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