Thursday Apr 17, 2008

OpenPortal WSRP v2 milestone 4 now available for download

The OpenPortal WSRP v2 milestone 4  is now available for download, milestone 4 is the last feature preview binary from the OpenPortal WSRP v2 project. The OpenPortal WSRP is feature complete from the WSRP 2.0 spec perspective by implementing all the mandatory and most of the optional features.

This milestone previews the following optional WSRP v2 features

  1. WSRP 2.0 CC/PP Capability
  2. WSRP 2.0 Leasing
    1. Registration Leasing
  3. Interoperability Fixes


Here are the links to the binary and documents associated with this milestone.

A. Binary download

  1. WSRP version 2.0 milestone 4 binary  requires
  2. Portlet Container 2.0  16 April 2008 binary

B. OpenPortal WSRP documents:

  1. Whats new in Milestone 4
  2. Glassfish Install Instructions
  3. Tomcat Install Instructions
  4. User Guide
  5. WSRP v2 milestone 4 samples
  6. Sample Portlets

Wednesday Mar 12, 2008

WSRP 2.0 Resource serving and Caching


Checkout the following announcements on the release of a new milestone binary from OpenPortal WSRP Project.

  1. Project Announcement : OpenPortal WSRP version 2.0 milestone 3 now available   or
  2. Blog on PortalPost .


This new milestone 3 supports the following feature set

  1. WSRP 2.0 getResource
  2. WSRP 2.0 Caching
    1. Markup Caching
      1. Expiration Markup Caching
      2. Validation Markup Caching
    2. Resource Caching
      1. Expiration Resource Caching
      2. Validation Resource Caching
  3. Tomcat 5.5 support
  4. Migrated code to the latest WSRP 2.0 schema


Pls note that the previous milestones have already provided the following WSRP  version 2.0  feature sets.

  1. WSRP 2.0 Eventing.
  2. Shared/Public render parameters.


The above links also provides sample portlets and configuration instructions to try out these features. If you have questions on how to use the OpenPortal WSRP Project and other comments/suggestions/requests, consider joining the alias.

Tuesday Feb 12, 2008

WSRP Eventing and Shared Render parameter preview

Just a repost of the information on Portal Post w.r.t to WSRP version 2.0 milestone 2 binary. Here is the actual post  

The OpenPortal WSRP version 2.0 milestone 2 binary is now available for download. The binary along with install instruction is available on the Open Portal WSRP download pageThis is the second milestone release from the OpenPortal WSRP Project that implements the OASIS WSRP version 2.0 specification. The main intent of this release is to preview the following optional features defined in the WSRP version 2.0 of OASIS specification.

  1. WSRP Eventing
  2. Shared/Public render parameters
Pls follow the instructions in coordination preview document on how to test and use these features that'll help you to understand the implementation.

Here are the links to the complete set of documents for this milestone.
  1. Install Instructions
  2. User Guide
  3. WSRP v2 Coordination samples
Stay tuned for more optional feature implementation in the future milestones of the OpenPortal WSRP version 2.0 project. If you would like to keep track of future announcements and additions to the OpenPortal WSRP Project, please subscribe to the alias.

If you have questions on how to use the OpenPortal WSRP Project and other comments/suggestions/requests, we urge you to join the alias.

Please report any issues that you encounter while trying OpenPortal WSRP version 2.0 milestone 2 to

Tuesday Jan 08, 2008

WSRP 2.0 milestone 1 preview download

The OpenPortal WSRP version 2.0 milestone 1 binary is now available for download, checkout the following announcement on the OpenPortal WSRP project

Here are the links to install and user guide.

 The above WSRP binary works over the latest OpenPortal Portlet Container 2.0 beta 2 binary, checkout the  following announcement with respect to OpenPortal Portlet Container binary. Here are some links to the Portlet Container documents

Stay tuned for future announcements on OpenPortal WSRP Project on other WSRP version 2.0 feature implementation, Please subscribe to

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>



« July 2016