Thursday Sep 20, 2007

WSRP 1.0 beta part of Java Application Platform SDK Update 3 Beta release



OpenPortal WSRP 1.0 beta is now integrated into the Java Application Platform SDK Update 3 Beta release. The WSRP implementation provided over the OpenPortal Portlet Container 2.0 beta which is also available in the same Java Application Platform SDK bundle.


Portlet Container 2.0 beta implements some of the JSR286 features based on the early access draft , its available as a preview in the above bundle.


Here is the location to get all the details about this bundle ( download, release notes, install instructions, articles and more).  


Tuesday Sep 11, 2007

Migrating from JAX-RPC to JAX-WS

Here is some of the issues that we encountered during migration of the OpenPortal WSRP Project from JAX-RPC to JAX-WS. The following note does not go into details on why these changes are required and the concepts behind it, rather helps you to deal with migrating your application from the older webservice stack to new stack.

Consider leaving a note if you have faced a different issue and solved it, so that it would benefit other.

[Read More]

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.

Wednesday Jan 31, 2007

Short trip

It was end of the year (last day of 2006), We (myself and some of my friends from Sun) decided to go on a short trip to get some pictures. Thought we'll specifically capture some butterflies and birds, preferably in-flight this time. There are 2 places near Bangalore where we can get close to birds, Rangantittu and Kokerebelluru. One of our friend suggested that there is a place in Mysore where there are some butterflies, its called Karanji kere/lake.   All these three places are on the way to Mysore from Bangalore, so decided to cover all three of them.

The plan is to start as early as possible in the morning reach Karanjikere, shoot the butterflies and then the birds. The best time to capture butterflies is early morning as they tend to become more active with bright sun light. Here are some picture from this trip. All the shots were taken with the 135-400mm lens, justifying the purchase :-)

Butterfly 2
DSC_0104 Tiger Type butterfly DSC_0092 Tiger Type DSC_0109 Tiger Type DSC_0041 DSC_0002 Butterfly Pelicans Landing... DSC_0188 DSC_0187 DSC_0186 fishing Spoonbill DSC_0165 DSC_0134 Take off DSC_0225 DSC_0223 DSC_0151 DSC_0230 Arms wide open Dry me DSC_0128

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.

Tuesday Dec 26, 2006

A proposal for Portlet Repository Protocol

Here is the excerpt on the proposal that I wrote earlier on using the existing Registry Information Model (RIM) and Maven repository for the Portlet Repository Protocol (PRP) definition. Note : The following content is just a proposal for PRP that I sent earlier on the PRP mailing list by no means a agreed interface.

The Portlet Repository Protocol (PRP) is a initiative that tries to define a set of agreed interfaces and meta-data for implementing portlet repositories. The intent of PRP is facilitate distribution of portlets binaries over the wire, where an administrator or a user can download and install portlets by a look-up or search on a PRP based repository.  Its a cross-vendor initiative and more vendors interested in the definition. We encourage you to join the alias and contribute to this definition.

The proposal is based on using the existing standard's and infrastructure rather than building everything from scratch. The proposal uses/builds-upon on the the following infrastructure.

  1. Maven repository infrastructure and its dependency resolution mechanism for download and install &
  2. The standard webservices (WS) registry infrastructure for meta-data definition/search/publish functionalities.

Here are more details/steps of the proposal on PRP in using the existing WS & maven infrastructure.

A. Steps for publishing a portlet:

  1. The portlet-binary /war would be published to a maven repository.
  2. A meta data about the above portlet would be published to the standard WS registry.

B. Download & install:

  1. If the client knows the artifact id i.e not interested in searching the repository.
  2. It can use the standard maven way of downloading the artifact by specifying it in the pom.
  3. A mvn plugin can be provided to install the above artifact on to the portal server ( Note:  Each vendor can provide their own maven plugin for installation, hence it also solve the problem of where each vendor have their own way of deploying a portlet)

C. Search, Download and Install :

  1. A WS client may search the registry based on various query parameters and search for a portlet on the WS registry (this would be a maven plugin too)
  2. It obtains the maven repository and the artifact id as the response of the query.
  3. The client uses the search results to download the maven artifact from the maven repository.
  4. As indicated above the maven plugin to deploy the portlet could be used

D. Supporting preview for a portlet :

  1. While publishing a portlet the administrator could publish the WebService for Remote Portlets(WSRP) artifacts associated with the portlet  (WSRP artifact meaning WSRP Registry Information Model-RIM defined by OASIS). We can even think even about PRP as an add-on to the WSRP RIM or vice versa.
  2. The WSRP artifact points to the WSRP Producer which offers this portlet
  3. The client which is interested in a preview of the portlet could use the standard WSRP interfaces to get the content.

Note : The above need not be limited to preview mode as WSRP supports all modes. So rather than a preview we could call it as "test drive" a portlet.

Note : The above could be a extension and not mandated in the RIM. So this would be a optional meta-data.

E. Cross referencing.

  1. It MAY be possible to cross reference registries that would allow us to import all the data from other vendor hence offering more portlet (Need to check on cross referencing feature in registry)
  2. Worst case importing the meta-data from other registries and importing to our registry would work.

Advantages :

  1. We'd using the standard WS infrastructure (defining metadata, searching and publishing to the registry)
  2. We can take advantage of the maven dependency resolution mechanism ie. a portlet may depended on some software that needs to be in the server classpath etc which can be resolved by the POM.
  3. No need to invent any on the wire protocol rather use maven + WS registry infrastructure.
  4. We can take advantage of the mvn distribution (i.e. we need not write new client or cli etc)
  5. Everything defined above are based on standards so any one can implement their own solution . All we have to agree upon is the meta data.

Items to be done:

  1. Define a meta data for the PRP
  2. Write maven plugins for
    1. publish
    2. search
    3. install of the portlet

If you have any comments or want to see the responses for the above proposal. Pls join the mailing list for PRP.

Monday Dec 11, 2006


Did had a chance to travel a bit this year and capture some of the work of monsoon. The travel was mostly restricted in and around the Western Ghats (South India). Here are some of the pictures.



Oh BTW still trying to experiment with the equipment I bought, Here is the spec

  1. Nikon D50
  2. AF-S DX 18 - 55 mm F3.5 - F5.6G ED
  3. Sigma 135-400 MM f/4.5-5.6 ASP AF APO

Monday Nov 27, 2006

WSRP milestone 1 preview available

Aligned with the announcement on WSRP milestone build 1, the milestone 1 "preview" is available. This preview delivers a installable WSRP components that allows users to try out the planned features of milestone 1. As the project stabilizes we plan to tag the codebase as milestone 1 build by end of December. The milestone 1 build tries to deliver a implementation that consists of
  1. WSRP Producer    -  Allows creation of multiple producers.
  2. WSRP Consumer   - Deliver a Container API implementation  that can be used by any aggregators
  3. WSRP Test Driver  - Use the above WSRP Consumer Container API and deliver a test driver based on portlet container test driver
  4. WSRP Admin Portlets - Provide an user interface for the WSRP Mbeans.
  5. WSRP Mbeans with sample admin server - Export WSRP administrative interface as Mbeans and provide a sample Mbean server.
The WSRP functionality is built over the  Portlet Container Open Source Project.

You can get the Install and User guide for this preview build which is available at the project site.  If you have questions on how to use the WSRP Project and other comments/suggestions/requests, we urge you to join the Project mailing alias.

Screencast and other materials would be available soon.

Monday Nov 20, 2006

WSRP and Portlet Container OSP dependencies

The following section describes the refactoring that we are in the process of doing to the Portlet Container Open source Project (OSP) and the dependencies between the WSRP OSP and the Portlet Container OSP. The design of WSRP OSP to some extent addresses the possibility of supporting other portlet container and not just Portlet Container OSP.

The Container API is the common abstraction that the portlet container and the WSRP Consumer implements. The Container API abstracts the local or remote execution of the portlet and provides a uniform interface for the content aggregators. The Portlet Container driver which is a test environment for these portlet uses this abstraction and display content of local or remote portlets.

The Container Context is the newly refactored abstraction on which is work in progress, this abstracts the dependencies of WSRP (producer and consumer) on the content aggregator. WSRP depends certain functionality of the aggregator rather than just depending the Container API.

The Portlet Container which is the implementation of the Container API provides the execution environment for local portlets. The WSRP Consumer provides another implementation for the Container API which executes/routes request to remote producers and provides content to the aggregators. Apart from providing an implementation of the Container API the  WSRP Consumer also provides the following functionality's.
  1. An implementation of Container API which any aggregators can use (where Container API is the exposed/public interface)
  2. A Resource Proxy Servlet - Which is responsible for getting resources that a portlet refers too ( for fetching images, scripts etc. from the producer)
  3. Some implementation of the portlet container test driver interfaces - This can be replaced by other aggregators.

The following diagram shows the web-apps that are deployed on an web container and some of the high level component dependency with interfaces that are defined in the system. The direction of arrow shows the dependency.


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

Friday Nov 03, 2006

Administrative interface for WSRP Open Source Project

Here is a note on the administrative structure that is planned for the Enterprise class WSRP Open Source Project (OSP) on The intent is to provide flexibility in system composition such that the WSRP component could be used without much modification to adapt to new environments.

The administrative interface is provided in terms of Mbeans. These Mbeans that can be deployed on any/existing Mbean server that enables management of the WSRP component.  The user interface (UI)  for these Mbeans (clients) are provided as portlets. Since the user interface is provided as portlets, these portlets can be deployed on to any standard portlet container.

The above componentization provides flexibility in terms of recomposing  and integrating the WSRP project into any environment or existing system that suites a variety of needs. For e.g. it allows the Mbeans to be deployed on an existing Mbean server that manages a larger set of services which is integrated with WSRP.

To be more specific the WSRP OSP project would provide the following MBeans for managing the WSRP Producer and Consumer separately. These Mbeans could be reused when deploying or recomposing the system other than the default bundled configuration/deployment.
  1. WSRP Producer Mbeans
    • WSRPProducerManagerMBean
    • WSRPProducerMBean
  2. WSRP Consumer
    • ConsumerMbean
    • ConfiguredProducerMBean
    • RemotePortletManagerMBean
Apart from providing the above Mbeans.  The WSRP OSP project as such will provide a default sample Mbean server that demonstrates the deployment and management of these Mbeans on to a Mbean server which runs as a separate process.

The user interface for above Mbeans is provided in terms of portlets namely
  1. WSRP Producer Admin  Portlet and
  2. WSRP Consumer Admin  Portlet.
The administrative portlets could be deployed on to any standard Portlet Container that  provides an environment for executing these portlets. Again providing the UI in terms as portlets also provides the flexibility to reuse and recompose the system to suite various needs.

The portlet administrative interface is a demonstration on the usage of public WSRP OSP Mbeans that are exported by the system. Its be possible to write a CLI (command line interface) that uses these same Mbeans also opens up the possibility of integrating the WSRP OSP with existing systems where an unified admin console of CLI would be required.

The default deployment architecture of the WSRP OSP project is as follows.
  1. The system provides a default Mbean server where the WSRP OSP Mbeans are deployed, this runs as an independent process.
  2. The WSRP Producer and the Consumer are deployed over a web container along with the Portlet Container. This is where the WSRP environment exists.
  3. The WSRP OSP admin portlets are deployed over any standard portlet container that provides the UI for the above deployed Mbeans.
The pictorial representation is as shown below :

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

Tuesday Sep 26, 2006

WSRP and User Identity Propagation (cont..)

This is the continuation to the previous entry on WSRP and User Identity Propagation. Sun Java System Portal Server provides a two step/phase configuration for the identity propagation mechanism it supports. In the first phase the administrator of the WSRP Consumer sets up the relationship with the WSRP Producer and allows the end user to do federation with the remote WSRP Producer service. In the second phase the end-user may optionally federate his remote identity with the local identity for Single-Signon with the remote producer. This two phase configuration provides control to both the administrator and the enduser in federating the identity of the enduser.

    The following sections specifically talks about the identity propagation mechanism setup at the WSRP Consumer end. This is because the Consumer is the one which has the knowledge about the actual user and decides to propagate the user identity. The two phase configuration along with the subsequent request/response is as follows.

Phase 1 : Administrator Setup
  • The administrator of the Consumer Portal discovers that the Producer Portal supports certain identity propagation mechanism.
  • The Consumer Portal administrator setups the system that may optionally allows the user to use identity propagation mechanism.
Phase 2 : User setup
  • The enduser see that he has access to a remote WSRP Producer services and may decide to federate his identity.
  • The enduser federates his identity by populating his remote credentials
This normal request/response  processing :
  • The Consumer Portal WSRP infrastructure uses the user remote credentials and propagates the identity to the WSRP Producer upon user specific operations.
  • The Producer Portal WSRP infrastructure accepts/validates and provides content for the propagated remote identity.
  • The Consumer Portal presents the content delivered by the  Producer Portal  to the enduser.
    In essence the two phase configuration allows the administrator decides whether to use an identity propagation mechanism available at the Producer Portal and he also determines the type of identity propagation mechanism that the Consumer Portal should use. The user decides whether he want to use the identity propagation mechanism made available to him by the administrator and federates his identity if required.
Sun Java System Portal Servers WSRP implementation support the following different types of identity propagation mechanisms,
  1. SSO Token:  Where the SSOToken associated with the user is propagated from the WSRP Consumer to the WSRP Producer
  2. WSS User Name Token Profile (Username only): It uses the WSS (Webservices Security) specification where the user name is propagated as WS Security headers from the WSRP Consumer to the WSRP Producer.
  3. WSS User Name Token Profile (With password digest): The WS Security headers contain user name in plain text and password in the digest form to the WSRP Producer.
  4. WSS User Name Token Profile (With password text): The WS Security headers contain user name and password in the plain text form to the WSRP Producer.
  5. No Identity Propagation : This defaults to the behavior where  there will be no user identity propagation mechanism from the WSRP Consumer to the WSRP Producer

No Identity Propagation :

    This is the default behavior of WSRP as indicated in the WSRP specification, The WSRP consumer propagates a notion of user to the WSRP Producer and there is no real user identity play in the system when this option is used. This is the default option in Sun Java System Portal Server, so any consumer that is created by default will not have any identity propagation mechanism.

SSOToken Identity Propagation :

    Sun Java System Portal Server uses Sun Java System Access Manager for authenticating users and for Single Signon. This options assumes that both the Producer and Consumer are Sun Java System Portal Server, Make sure you use this option only  if both the Producer portal and Consumer portal are configured to use the same Access Manager instance. Typically recommended in configurations where both the Producer Portal and Consumer Portal are  deployed within the same organization.

    This option does not provide the end users with the options to federate their identities. This is because the same user identity is accepted by both the Consumer and the Producer portal as they point to the same Access Manager instance.

    Note this identity propagation mechanism will not interoperate with other Portal vendors and also will not work if the Producer Portal and Consumer Portal are not pointing to the same Access Manager.

WSS User Name Token Profiles :

    The following options are implementations of the OASIS WSS Username token profile specification.  This specification describes how to use the UsernameToken with the Web Services Security (WSS) specification; more specifically, it describes how a web service consumer can supply a UsernameToken as a means of identifying the requester by 'username', and optionally using a password, to authenticate that identity to the web service producer.
  1. WSS User Name Token Profile (Username only)
  2. WSS User Name Token Profile (With password digest)
  3. WSS User Name Token Profile (With password text)
    Since this is a standard specification from OASIS, various portal vendors support and implement it. Use one of the above options when interpretability is required. i.e., it allows portal implementations from 2 different vendors to exchange user identity.

    This option provides both the end user and the administrator the flexibility to configure  and control the identity propagation scheme that is in effect.  The following section details with the step by step instructions for doing the above mentioned configurations in Sun Java System Portal Server

Administrator Setup :
  Here are the specific steps for administrator to do the administrator setup phase explained above
  1. Log on to portal server admin console (psconsole)
  2. Click on the WSRP Tab
  3. Choose the org on to which you want create a consumer
  4. Click on new consumer
  5. Enter the name of the consumer
  6. Specify the identity propagation mechanism
  7. Continue with the rest of the  wizard to create a consumer
Step 6 is the choice where the  administrator chooses an sets up an  identityppropagationmechanism for the end-users.  Once the consumer is created. The administrator has to create remote channels based on the above created consumer

User setup : Federating  identity

    The end user logs on to the portal server, clicks on edit of the WS-SSO (Web Services Single Signon Portlet) to provide the the remote WSRP Producers credentials for Single Sign on

WS-SSO Portlet :

    The WS-SSO Portlet is based on the SSOAdapter service that is available on the Sun Java System Portal Server. The SSOAdapter service provides a mechanism to manage and authenticate users to the remote services that are used by the Sun Java System Portal Server.

    The WS-SSO Portlet provides a user interface that allows end users to populate values on to the SSOAdapter. The WS-SSO Portlet uses an SSOAdapter named OASIS-USERNAME-TOKENPROFILE. The values populated by the end user are stored in this SSOAdapter which is used by the WSRP Consumer to obtain the user credentials if exists and propagate to the WSRP Producer service.

WSRP Request/Response :

    Once the credentials are made available by the user, For the subsequent requests when the user views any of the remote portlets that are available on the desktop the user identity is propagated by the WSRP Consumer to the Producer. The Producer based on the identity generates contents for the user

Configuring the WSRP Producer :

 This section specifically talks about the WSRP Producer configuration.

    The identity propagation mechanism is set at the producer automatically, no need for the administrator to set it manually. The Producer checks for user identity headers in the following order 
  1. Sun SSO Token,
  2. OASIS user name token profile (all the variants of it )
  3. No Identity Propagation mode. (default behavior if none of the headers are found).

Notes/Recommendations :
  • Sun Java System Portal Server provides both a WSRP Producer and a WSRP Consumer implementation. This section deals with the support for each of the above mentioned options 
    • Sun Java System Portal Server WSRP Producer supports all the above mentioned Identity Propagation Mechanisms except  WSS User Name Token Profile (Username only).
    • Sun Java System Portal Server WSRP Consumer supports all the above mentioned Identity Propagation Mechanisms. i.e..  Sun SSO Token,  WSS User Name Token Profile (With password text), WSS User Name Token Profile (With digest text), WSS User Name Token Profile (Username only) and no identity propagation.
  • When using the WSS User Name Token Profile (With password text) it is recommended that the communication between the producer portal and consumer portal is secured via HTTPS, this is essential as the password is sent in plain text between the consumer and the producer.
  • It is not recommended to have 2 different consumers that point to the same producer URL to have different identity propagation mechanism types.   
  • It would not be recommended to switch identity propagation types once the consumer is created and used, this is because the users portlets preferences are stored based on the identification of user, switching the identity propagation mechanism would mean loss of user customization.
<script src="" type="text/javascript"> </script> <script type="text/javascript"> _uacct = "UA-898027-1"; urchinTracker(); </script>



« July 2016