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.

    Quite frequently we hit this problem while developing code for enterprise class systems. Finally decided to term this as an "Antipattern" and write a blog about it. Not necessarily following any template for documenting this antipattern but in random order. The problem becomes eminent especially when we are trying to develop a client application which itself is a server.

Static Configuration Antipattern:

Context:

    There are instances where an API or infrastructure software that are used by clients depends on certain configuration information The configuration information is provided in some form of properties which can be configured by the client system. There instances where such configurations inhibits the usage of the API or the infrastructure in multi threaded environments where each thread would need to have a different configuration.

Problem:

    The usage of system wide configuration inhibits the ability of the client to specify multiple configurations per client thread and also does not allow dynamic changes to these configuration during runtime rather requiring the whole system to be brought down in event of an changed configuration to take effect.

Solution:

    Whenever providing API that depend on configurations, also provide additional API that allow each client thread to set the configuration property rather than assuming that there exists only one configuration per process or per thread. These additional API should allow the the client to set the context in which the actual API's are invoked and it should be possible to set these configuration for each thread from within the client application.

    It should be possible for the client to use the API in different context within the same process without each context interfering with each other. Also it should support the  possibility of creating and associating these context dynamically at runtime without requiring a restart or some sort of shutdown, redeploy etc.

Citation:

    Until J2SE 1.4 The -Dhttp.proxy parameters that are used by the protocol handlers were the only way a proxy can be set, this is a best examples of this Antipattern. This inhibits the ability for the client to specify different proxies for each destination server dynamically.

Note: J2SE 5.0 has overcome this problem by providing API's for doing the same. Pls see the note here.

Variants:

     There are many variants of this antipattern, there are instances where some of these configurations require the whole  system to be brought down or redeployed for the changed configuration to take place and does not allow per client thread customizations.

The initial version of WSRP Consumer source code is now available on  Java.net repository.  The repository already hosts the WSRP Producer source code.

This initial WSRP Consumer implementation provides

1. A WSRP Consumer in the form of a Container for portal to consume WSRP (Container is an implementation of the Container API right now exposed by the portlet container project ).
2. A file store implementation for creating and storing 'n' number of  Consumer.
3. A resource proxy for fetching resources from the Producer.
4. The Consumer rewriting infrastructure.
   
5. Some infrastructure for providing a WSRP test driver.

Here is the official project announcement.

Soon we'll have an infrastructure for managing/creating both the WSRP Consumer and Producer and ofcourse a UI for the same.

There has been quite a number of queries on proxy setting for WSRP, so decided to write a note about it. This blog talks about setting proxies for various usecases of the WSRP implementation provided by Sun Java System Portal server.

Case 1 : External Producer :

    In this cases the the Sun Portal could be used as WSRP Consumer which is deployed in an internal network and the WSRP Producer resides outside the firewall.

a. Setting the proxy for CACAO:

    Sun Portal uses the CACAO as the management server for managing all of the portal functionality. When an administrator creates a WSRP Consumer it a management functionality. These as handled by the Mbeans that run inside the CACAO.

Hence for creating a a WSRP Consumer in Sun Java System Portal set the proxies for the

CACAO. Here is the recommended way to set these proxies

• Stop the cacaoadm
• cacaoadm get-param java-flags
• cacaoadm set-param java-flags="<above-returned-value> -Dhttp.proxyHost=<your_proxy> -Dhttp.proxyPort=<your_proxy_port>"
• Start the cacaoadm
  

With the above setting you should be able to create a WSRP Consumer

b. Setting the proxy for Webcontainer :

    Once the WSRP Consumer is created, You could create "Remote channels"  WSRP channels on the Portal desktop. The Portal server runs inside the webcontainer. Hence to fetch the contents from the remote WSRP Producer. The webcontainer needs to have the same proxy settings in its configuration.

    Adding proxy settings to the webcontainer is specific to the container on which your are running. In most of the cases its a matter of adding -Dhttp.proxyHost and -Dhttp.proxyPort as JVM parameters to the configuration files of the webcontainer.

Case 2 : External Registry Server

    In this case the Sun Java System Service Registry (ebXML implementation) may be residing in a network that is not the same as that of the Portal Server. Sun Portal Server uses the Registry Server for publishing and discovering WSRP artifacts on the Registry Server.  

    For Registry Server configuration, The Sun Java System Portal uses the SSOAdapter configuration to specify the proxy settings.

Logon to psconsole.--> Choose the SSOAdapter tab --> Choose JES-REGISTRY-SERVER Meta adapter

Specify the proxy setting in the provided UI and use the psadmin cli for publish and discovery.

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

This is the followup to my previous blog entry on WSRP and ebXML.

The Sun Java System Service Registry (Registry Server) can be installed on the same node as that of the Sun  Java System Portal Server or on a separate node using the JES installer. While installing the Portal Server the only Registry Server component that is required by the Portal Server is the Registry Server SDK. The SDK is the SPI for the JAXR API.  The SDK is automatically installed by the JES installer when installing the Portal Server.

Now in order to publish or discover WSRP artifacts, you'd need a Registry Server installed somewhere. Upon successful installation and configuration of the registry server, you should configure the Portal server so that it can authenticate to the Registry server to perform its tasks. Here are some highlevel configuration tasks.

Obtaining the Credentials :

    Registry Server uses certificates for authenticating the incoming request. The client of the Registry Server (which in our case is the Portal Server) should have a client certificates to authenticate itself to Registry Server. Follow the instructions here for creating an user and obtaining the certificate from the Registry Server.

Creating the keystores:

    Once the client certificate is available, We need to create a keystore some where in the /soar/3.0/jaxr-ebxml/security directory and import the certificate into the keystore. Use the standard java "keytool" command line interface to create the keystore and import the certificate into the keystore.

Configuring the Portal Server:    

    The Portal Server provides the SSOAdapter Service which allows services/users within the portal server to authenticate with an external service. There is an SSOAdapter named JES-REGISTRY-SERVER at the top level .

• Populate the values that are required in this SSOAdapter service.
• Make sure that the "amadmin" user has SSOAdapter service assigned.
• Finally restart  the cacao server.
  

Note on Configuration:

The JES-REGISTRY-SERVER has a property called "registry.keystorelocation" which is the location of the keystore relative to /soar/3.0/jaxr-ebxml/. So do not provide fullpath to the keystore

Publish and Search :

The psadmin command that portal provides has the following 2 subcommands

1. search-registry
2. publish-registry

these commands allows the administrator to publish/search for WSRP artifacts from the registry.

Note on Organizations:

In the previous blog, I did talk about Organizations, For those of you who were familiar with the Sun Java System Portal Server you may tend to think an Organization as an "org" as defined in the  Access Manager product. This does not necessarily map to this. For eg: If you are publishing the WSRP artifacts onto to a internet facing registry then it would make sense to put the actual organization name like "Sun Microsystems" , else if you are publishing to an intranet registry you may want to map it to Access Manager "Org".