Thursday Sep 07, 2006

WSRP and User Identity Propagation

The WSRP Specification as such does not talk about real user identity instead it talks about a notion of user (in the terms of userContext). This notion does not imply that its the actual user who is accessing the service rather a unique representation of the user within a Consumer.  So when a Producer receives a request from the Consumer saying get the content for this portlet for this user, The  Producer has no mechanism by which it can identify the user who is accessing the portlet/service offered by it.

In a relationship between the Consumer and the Producer, the Consumer propagates to the Producer a notion of user identity (but not necessarily the exact end user's identity). The Producer uses this notion to recognize and maintain distinction among users accessing portlets and to maintain and store portlet-preferences/persistent-state for those users. Essentially, the Producer may creates proxy user accounts on the fly and maintains those accounts to represent the real user at the Consumer Portal. Note : Even though true user identity is not sent across to the Producer end, the user profile items are passed to the Producer in accordance with the WSRP 1.0 specification.

One of the problems with this approach is that. A user may have account/identity in both the Consumer and the Producer portal, but when he is logged in into the Consumer portal and since the Consumer has relationship with the Producer, it shows some content from the Producer. This content will not be the same content that this user would see if he is directly logged in to Producer portal. This is because when the user access the Producer portal via the consumer he is represented by a notion of his identity and not the real identity, but when he login into the Producer portal he uses the actual identity. So a single user have 2 different identity on the same Producer Portal and hence 2 different contents.

Identity Propagation :

Identity Propagation is a mechanism by which the Consumer portal supplies the true or actual identity of the user to the Producer portal whereby a Producer portal may recognize the end user. This makes more sense as said earlier when a user has an identity in both the Consumer and Producer portals and would like to access/see the same content when he is on both the portals.

Identity propagation can be thought of an federation mechanism where the identity of the user is propagated and recognized by both the Consumer and Producer portals. The implementation may provide options to the user to federate his identity or the federation can be implicit, configured by the administrators within the same organization. Upon successful federation the Consumer portal propagates the user identity to the producer portal, the Producer portal upon receiving the the user credentials validates the credentials and allows or denies access to the resource in that specified user identity.

This User identity propagation mechanism provides a sort of Single Sign-on mechanism for the user whereby once he is login into Consumer portal he is automatically logged in to the Producer portal. The same content is offered by a producer portal when the user is logged in directly to the Producer portal or if the user is accessing the content as an federated user i.e. via the consumer portal.

The changes that the user makes using his federated identity would be available to the same user when he log-in to the producer portal as that user. In essence the end user has 2 identities for each portal i.e. Producer and Consumer portal. He federates those identities using the identity propagation mechanism provided . He sees the same content on both  the portals as if he would logged in with 2 different identities

When we talk about federation mechanism between portals there are different specifications could be implemented to do the same. To name a few
  1. OASIS UserName token profile
  2. OASIS X509 profile
  3. OASIS SAML token profile
These are different specification from OASIS that WSRP recommends for propagating user identity. As the name implies  the specification recommend sending user and password in the case of UserName token profile or certificates in the case of X509 profile or as SAML tokens between the Producer and Consumer Portals.

The Sun Java System Portal Server provides some user identity propagation mechanism which I'll try to post later..
<script type="text/javascript" src=""> </script> <script type="text/javascript"> _uacct = "UA-898027-1"; urchinTracker(); </script>



« August 2016