Wednesday Aug 22, 2007

OpenPortal WSRP Project consumed by OpenPortal


The OpenPortal WSRP project is consumed or integrated into the OpenPortal project, Here is a note on some of the integration that was done.

Java Persistence API based (JPA) based datastore :

Added a new datastore for storing WSRP Producer and WSRP Consumer related configurations The file based datastore that OpenPortal WSRP Project is unacceptable as the configurations stored in file would be local to specific portal server node. The JPA based WSRP datastore implementation by default uses derby as backend to store all the WSRP Producer and Consumer related configuration information.


Note : The source code for this resides in the OpenPortal WSRP Project as this can be used outside of the OpenPortal. Watch this space for more details on how to use it in OpenPortal WSRP Project.

User Management:

The OpenPortal project customizes the user datastore of the OpenPortal WSRP Project, its provides user store where WSRP users are created and managed on to the LDAP server that is used by the OpenPortal installation. OpenPortal project creates creates people container under organizational units for each consumer registration The people container is used for creating phantom users that are specific to a consumer registration.


Note : Pls see the other entries on WSRP User Identity Propagation to know more about phantom users and identity propagation techniques

Role Management :

OpenPortal uses roles in LDAP/Access Manager to store explicitly cloned portlets. Explicit clones are portlet clones that are created by consumers that needs to be shared by all the users. Hence the cloned portlet is stored on to the role and all users under that consumer registration are assigned to this role, which makes the portlet clone available to all the users under this consumer registration.


Here is a simple representation, the WSRP Producer and WSRP Consumer stores configuration onto a database. The WSRP Producer uses the AM /LDAP  server to create users and roles for the above mentioned functionalities.


Single SignOn Token(SSOToken) Identity Propagation:

OpenPortal uses AccessManager(AM) to authenticate users, authenticated users are represented by a Single SignOn Token(SSOToken) in AM. Since SSOToken is used only in OpenPortal, the SSO identity propagation is added as an extension by the OpenPortal Project to WSRP Project.


When this option is selected the SSOToken associated with the user is propagated as an UserContext extension by the WSRP Consumer to the WSRP Producer which represents a user. 


Note : This identity propagation mechanism assumes that both Consumer and Producer Portal are OpenPortal installations. Pls see this entry for more details

WSRP Mbeans :

The OpenPortal WSRP Project Mbeans are consumed by the OpenPortal and integrated into the OpenPortal Portal Administration Server (PAS) module, the WSRP Mbeans are deployed on to the Common Agent Container for APG and Orion/Common Agent Container (CACAO/CAC) management server. The OpenPortal administrative console (psconsole) provides a user interface for WSRP administrative purposes using the above Mbeans.


Note: Pls see the architecture here and the intent of this design.

WebService Single Sign On (WSSSO) Portlet :

The OpenPortal project provides a portlet/user-interface that allows users to add/provide Single SignOn information in the form of a username and password. This portlet stores the user credentials that is used by the WSRP Consumer to create a OASIS Username Token profile and propagate the user identity to the WSRP Producer portal.


Note : The WSSSO Portlet uses the SSOAdapter infrastructure to store user credentails, Pls see here for more information on SSO Adapter.


Wednesday May 23, 2007

Article on WSRP

We have put together an article on the Open Portal WSRP Project titled "Open-Source Portal Initiative at Sun, Part 4: Web Services for Remote Portlets".  This article provides an overview about the Open Portal WSRP Project and some details about its architecture, deployment, build process and usage instructions.

Following are the links to all the article in this series

Monday May 07, 2007

OpenPortal is the new name

The Enterprise class Portal Server Project now has a new name, its called OpenPortal. It also has a brand new logo. All the subproject are now referred with OpenPortal prefixed to them. For e.g. the Enterprise-class WSRP Open Source Project is now called OpenPortal WSRP Project.


Apart from this, the Sun Java System Portal Server 7.1 source code is also available for download on the OpenPortal Project, check out the download page for more details.  Please keep a watch on the Portal Post for announcements related to the OpenPortal Project. 

Thursday Apr 26, 2007

WSRP 2.0 - A Sneak Peek

Here is the list of features that WSRP 2.0  addresses or adds over WSRPv1 specification. We'll try to contrast and compare with the JSR286 specification in some places and see how these two specifications compliment each other. Here is the list of new stuffs that WSRP v2 brings to the table.

[Read More]

Wednesday Mar 14, 2007

Deploying WSRP Producer and Consumer independently

Here are the steps for deploying WSRP Producer and WSRP Consumer separately on two different boxes or instances.  The deployment diagram is as shown below

To create this deployment configuration, Lets say we have 2 boxes
  1. Producer box
  2. Consumer box

as shown in the below image. We install just the WSRP Producer on the Producer box and WSRP Consumer on the Consumer box




Note on WSRP binary :

When you build the WSRP trunk binary. It would have create a "dist" directory with the following contents

  1. wsrp-configurator.jar
  2. wsrp - binary directory
The wsrp-configurator.jar is for the Java App Platform SDK distribution of the wsrp binaries that  are under the "wsrp" directory.  The configurator provides a java wrapper over the setup.xml that would be invoked by the Java App Platform SDK installer.

The wsrp-configurator.jar has a file that has all the content of the "wsrp" binary directory.  You can choose to directly use the wsrp binary directory or even unzip the contents from wsrp-configurator.jar and use it.

For sake of simplicity choose to copy the dist/wsrp directory to a machine where you want to install the WSRP Producer and WSRP Consumer and follow the below mentioned  instructions.

Deploying the WSRP Producer :

On the Producer box
  1. Deploy glassfish
  2. Deploy portlet container
  3. To deploy WSRP Producer follow the below instructions
Use the following command to deploy the WSRP Producer :
ant -verbose -f setup.xml deploy-producer -DSERVER_HOME=/opt/SDK1/  -DSERVER_DOMAIN=/opt/SDK1/domains/domain1/

Use the following command to deploy the WSRP Producer admin portlet
ant -verbose -f setup.xml deploy-producer-admin-portlet -DSERVER_HOME=/opt/SDK1/  -DSERVER_DOMAIN=/opt/SDK1/domains/domain1/

Deploying the WSRP Consumer:

On the Consumer box
  1. Deploy glassfish
  2. Deploy portlet container
  3. To deploy WSRP Consumer follow the below instructions
Use the following command to deploy the WSRP Consumer :
ant -verbose -f setup.xml deploy-consumer -DSERVER_HOME=/opt/SDK2/  -DSERVER_DOMAIN=/opt/SDK2/domains/domain1/

Use the following command to deploy the WSRP Consumer admin portlet
ant -verbose -f setup.xml deploy-consumer-admin-portlet -DSERVER_HOME=/opt/SDK2/  -DSERVER_DOMAIN=/opt/SDK2/domains/domain1/

That's it you can access the http://<your-host>:<your-port>/portletdriver/dt on the WSRP Consumer and Producer boxes and administer the respective components.  You can point the Consumer to the Producer installation and render the remote portlets exported by the WSRP Producer.

Tuesday Jan 23, 2007

Interoperability with Netunity

The Enterprise class WSRP Open Source Project is in a reasonable shape so decided to do some interoperability testing with other vendors. Interoperability is a key to any WSRP implementation and we have done such exercise with most of the vendors for Sun Portal Server releases in the past. Eventhough the Enterprise class WSRP OSP Project code base is derived from Sun Portal Server 7.x, there is some considerable changes in the code to support a light weight driver and to be integrated in the future releases of Sun Portal Server, so decided to try some interop tests.

Considering that I am behind a firewall,  I could test only the consumer interoperability to start with, since there is no need to host a producer machine external to the firewall. The initial try is to point the Consumer implementation to Netunity interop server, here is the WSDL URL 

To get the initial consumer creation going, I had to do 2 things which is not different from my previous blog entry on configuring proxies for WSRP.

  1. Set proxies for webcontainer (add -D http parameters to domain.xml of glassfish)
  2. Set the proxies for the admin mbean server (required only if you are running the Mbean server)
    •  Eg : ant -f run.xml -Dhttp.proxyHost=<proxyHost> -Dhttp.proxyPort=<proxyPort> 

The above steps are required only if you are running a consumer behind a proxy i.e. the consumer can reach the producer directly but it can reach it only via a proxy server.

Netunity hosts a producer which supports in-band registration with no registration properties, The registration with the producers went fine and I could create a consumer one pointing to Netunity interop server.  This test validated that there are no issues with both Registration and ServiceDescription Ports.

The next step was to create remote channels,  Upon channel creation was running some basic tests discovered the following issues and fixed them

Issue 1:  For any operation that involves saving preferences both the producers were throwing PortletStateChange required. This is obvious since I was accessing the portlets  as a authless user. The portlet container driver provides a option to login as a user by providing a FORM based authentication. So this was NOT really a issue, upon user login the issue vanishes.

Issue 2:  There were some problem with templates that a consumer generate for rewriting. This problem was easily reproducible with the local producer itself, the fix for this issue is checked in to the code base.

Issue 3: The last issue was a bit hard to crack, since any changes that a users does by editing the portlet did not get saved, nailed the issue to persisting of portletHandle. The fix is to allow persistence of portletHandle for each user. The fix for this is also checked into the code based.

Here is screenshot of the rendered portlets from Netunity producer.

If you are interested in trying the above interop tests. Make sure you have the bits/code after 22nd Jan. The next step is to reiterate the above process for other vendors, will try to post on how stuff goes.

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>

Wednesday Aug 16, 2006

WSRP and ebXML

The Sun Portal Server 7 is integrated out-of-the-box with Sun Service Registry which allows WSRP artifacts to be published and discovered from the Service Registry. The integration implements some of the usecase mentioned in the ebXML-WSRP integration technote from OASIS

Sun Service Registry is a ebXML based implementation of an webservices registry server. In short Registry Server its a repository of metadata of contents. The registry also offers
  1. Validation, Cataloging, Versioning & Lifecycle Management Service
  2. Notification Service
  3. Discovery & adhoc Query Service
  4. Federated and inter registry links
  5. Access Control Digital Signature etc.
  6. Taxonomies, Classification etc.
A webservice is represented in an ebXML Registry through what is known as a Registry Information Model (ebRIM). Think of the ebRIM as a schema which describes how a service can be represented inside the ebXML registry.

The WSRP - ebXML Registry Technical note is the one which maps the WSRP artifacts to the ebRIM, It also defines some of the usecase on how these WSRP artifacts can be manipulated on the registry server.

To be more specific about WSRP artifacts representation with ebXML registry. The integration/technote allows publishing and discovery of the following WSRP artifacts
  1. A WSRP Producer
  2. A WSRP Portlet
Both the above artifacts are defined as "Services" using the ebRIM.

Apart from the above defined WSRP artifacts the specification allows binding or creating association with the following ebXML artifacts
  1. An Organization
  2. An Administrator/User
The relationship between the objects is as follows
  • An Organization can have 'n' number of Producers (offers Producer Service)
  • A Producer can offer 'n' number of Portlets
  • An Organization can have 'n' number of administrators/users associated with it
The WSRP-ebXML tech note does not mandate that a Producer service should publish all the portlets that are available within the Producer. This is attributed to the fact that given a Producer service a Consumer can discover all the Portlets that are available in other words the WSRP Protocol itself provides discovery of Portlets published by an Producer.

Despite the above discovery mechanism supported by the Producer, there may be a need publish a portlet apart from the Producer that offers the portlets. This is mainly to facilitate finer search criteria's for a Consumer, while searching for portlets.

With the above defined bindings to the registry. A WSRP Producer Portal would have ability to
  • Publish for a WSRP Producer
  • Optionally publish or associate an Organization that offers this Producers
  • Optionally publish the Portlets that this Producer Offers
  • Optionally publish a user/administrator who is associated with the Organization
Alongside an WSRP Consumer Portal would have the ability to
  • Search for a WSRP Producer
  • Search for the WSRP Portlet
  • Search for an Organization that offers WSRP Services
That wraps up short summary of the technote. Will try to post something on Sun Portal specific configuration and steps for doing the above sometime later.

<script type="text/javascript" src=""> </script> <script type="text/javascript"> _uacct = "UA-898027-1"; urchinTracker(); </script>



« November 2015