Web Services For Remote Portlets (WSRP)

 

+
Search Tips   |   Advanced Search

 

  1. Overview
  2. Producer
  3. Consumer
  4. How WSRP is implemented
  5. Prerequisites for WSRP
  6. Configure WSRP
  7. Use WSRP :
  8. Producer tasks
  9. Consumer tasks
  10. WSRP Markup Caching
  11. Security considerations for using WSRP :
  12. Enable Portal Access Control for WSRP
  13. Customize the WSRP configuration of the portal:
  14. Known limitations
  15. Troubleshooting
  16. Abbreviations
  17. Related information

 

Overview

The Web Services for Remote Portlets (WSRP) specification from OASIS enables integration of remote content and applications.

WSRP leverages Web services to allow users to interact with remote portlets in the same way they do with local portlets.

The WSRP services appear and operate to portal users exactly like local portlets.

Presentation-oriented services, as standardized by WSRP, allow Producer portals to deliver the data and presentation information to the Consumer portal. Previously, these services delivered the data only, and the portal administrators had to provide the logic for how to present the data.

No service-specific adapters are required. A single, service-independent adapter on the portal side is sufficient to integrate any WSRP services.

Custom interface coding is not required.

Portal administrators do not have to keep the WSRP services code locally on their storage devices.

 

Producer

Portals that provide WSRP services are called Producers. The Producer is the "server" of the WSRP communication.

A WSRP Producer provides one or more portlets as WSRP services for invocation by Consumer applications that reside at remote sites.

The Producer provides a set of interfaces as defined in the WSRP standard. The Producer can expose some or all of these interfaces to the Consumers as appropriate.

Property Description Required
Service Description Self-description of the Producer and its available portlets. Yes
Markup Interface for requesting and interacting with markup fragments. Yes
Portlet Management Grants access to the life cycle of the hosted portlets and to their persistent state. No
Registration Not supported by the current implementation of WSRP in WebSphere@reg; Portal. However, the Consumer can handle Producers that support WSRP registration interfaces. No

The Producer describes these WSRP interfaces in the Web Services Description Language (WSDL) document, which provides general technical information about how the Consumer connects to the Producer and the related infrastructure.

The Producer portal receives the requests from the Consumer to the WSRP service and generates the markup accordingly.

 

Consumer

A WSRP Consumer is a portal that wants to integrate WSRP services and consume them as remote portlets from portals that provide them. The Consumer is the WSRP client. The Consumer selects the WSRP service and integrates it into the Consumer portal as a remote portlet. The Consumer portal receives the markup from the remote WSRP service and presents it to its users.

 

How WSRP is implemented in WebSphere Portal

In WebSphere Portal, the WSRP implementation enables the portal to...

  • Provide portlets as WSRP services for remote invocation.

  • Integrate WSRP services as remote portlets.

These portlets behave like local portlets that comply with the standard portlet API, independent of their implementation on the Producer side.

 

Prerequisites for WSRP in WebSphere Portal

To use WSRP with the IBM@reg; WebSphere Portal, have the appropriate level of IBM WAS installed.

 

Configure WSRP in the portal

To configure WSRP in a portal, use one of the following...

For details about the changes that have been made in the XML configuration interface for using WSRP, refer to...

Changes in XML for WebSphere Portal V6.0

...under the section about...

Changes for the support of WSRP

For details on customizing the WSRP configuration...

Customize the WSRP configuration of a portal

 

Use WSRP with WebSphere Portal

To perform the administrative tasks related to WSRP and remote portlets...

 

Producer tasks

The tasks a Producer can perform...

  • Provide a portlet
  • Withdraw a portlet
  • Determine group IDs and handles.

To provide portlets for consumption by Consumer portals, or to withdraw portlets, use either of...

The current implementation of the WSRP Producer in WebSphere Portal does not support the WSRP registration interface. However, the WSRP Consumer in WebSphere Portal can handle Producers that support WSRP registration interfaces.

 

WSRP service description

WSRP service Consumers need information about how to bind to the provided WSRP services. This information is described in the WSDL document of the Producer. The Consumer can use the information in the WSDL document to bind to the Producer and retrieve the Producer's service description for further details about the Producer.

The WSRP service description provides information about various aspects and properties of the Producer:

  • The relationship to the Consumer
  • The capabilities of the Producer
  • The Web services that the Producer provides
  • Whether the Producer requires registration
  • Some WSRP-specific details.

If the WSRP service Producer is an IBM WebSphere Portal, then Consumers of WSRP services can access the WSDL document of the Producer at the following URL:

http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl

If the communication with the Producer is set up to use SSL communication, use https to address this URL:

https://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl

If the WSRP service Producer is not a WebSphere Portal, then the owner or administrator of the Consumer portal needs to get the information by some other means, such as fax, phone, or e-Mail.

 

Providing or withdrawing a portlet

By providing a portlet for WSRP services, a Producer makes the portlet available remotely to Consumers. Consumer portals can then integrate it into their portal and use it as a remote portlet. By withdrawing a portlet, the Producer cancels the service that was provided by the portlet.

Use the Manage Portlets portlet to provide or withdraw a portlet,

To provide or withdraw the portlet using the XML configuration interface, specify the provided attribute to the portlet tag:

Attribute to the portlet tag Possible values Description
provided true|false If the provided attribute is set to true, then the portlet is provided.

The following two XML samples show you how to use the XML configuration interface to provide a portlet that complies with the IBM portlet API and a portlet that complies with the standard portlet API.

The first XML sample shows you how to provide an IBM portlet:

Here and in the following sections and examples, IBM portlet has the following meaning:

  1. The IBM portlet API is the API version that applies to the Versions 4 and 5 of the IBM WebSphere Portal.

  2. This portlet does not comply with the standard portlet API (JSR 168 or later standards).

 

Portlet written according to the IBM portlet API.

<!-- 
Provide a portlet as a WSRP producer. 
-->

<?xml version="1.0" encoding="UTF-8" ?>

<request type="update" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd">

   <portal action="locate">

      <!-- 
      uid must match uid attribute of portlet-app in portlet.xml       -->

      <web-app action="locate" 
         active="true" 
         uid="com.ibm.wps.portlets.reminder">

      <!-- 
      uid must match uid attribute of concrete-portlet-app in portlet.xml 
      -->

      <portlet-app action="update" 
      uid="com.ibm.wps.portlets.reminder.1">

      <!-- 
      Name must match the content of the portlet-name subtag of concrete-portlet 
      in portlet.xml.

      To actually provide the portlet, the provided attribute is set to true. 
      -->

      <portlet action="update" name="Reminder" provided="true" /> 

         </portlet-app>

      </web-app>

   </portal>

</request>
 

Portlet that complies with the standard portlet API

<!-- 
Provide standard API compliant portlet as a WSRP producer. 
--> 

<?xml version="1.0" encoding="UTF-8" ?>

<request type="update" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd">


   <portal action="locate">

      <!-- 
      uid must match the uid of the portlet application appended with .webmod 
      --> 

      <web-app action="locate" 
               active="true" 
               uid="stdTestsuite.war.webmod">

      <!-- 
      uid must match the optional portlet-app id attribute from the portlet.xml. 
      If this is not set, the .war file name must be supplied. 
      --> 

      <portlet-app action="update" 
                   uid="stdTestsuite.war">

      <!--
          Name must match the portlet-name tag in the portlet.xml file. 
      --> 

      <portlet action="update" 
               name="TestPortlet1" 
               provided="true" /> 

         </portlet-app>

      </web-app>

   </portal>

</request>

To withdraw the portlet, set the provided attribute to false instead of true.

 

Determining group IDs and handles

When Consumer portal administrators integrate a remote portlet into the portal, they need to specify the handle and groupid of the remote portlet. They need to get that information from the Producer portal owner or administrator.

If you are a Producer and you use WebSphere Portal as the Producer portal to provide the portlets, we can obtain this information by exporting all portlets that you provide using the XML configuration interface.

To export all provided portlets, use the XML input file...

...and look for portlets that have the provided attribute set to true.

 

Consumer tasks

To use a remote WSRP service in a portal, create a Producer instance and specify which services from that Producer you want to consume.

The tasks that a Consumer can perform...

To create a Producer or to consume a WSRP service as a remote portlet in the Consumer portal, use either of the following tools:

 

Create a Producer

Creating a Producer in the Consumer portal makes that Web service Producer known to a portal. If required, you also register with the Producer.

There are different scenarios for creating a Producer, depending on whether you work online or offline:

  1. If you work online when creating the Producer, we can connect to the Producer. In this case use either the Web Service Configuration portlet...

    ...or the XML configuration interface to create the Producer.

  2. If you work offline, that is we cannot connect to the Producer, we can only use the XML configuration interface to create the Producer.

The current implementation of the WSRP Producer in WebSphere Portal does not support the WSRP registration interface. However, the WSRP Consumer in WebSphere Portal can handle Producers that support WSRP registration interfaces.

When you specify user attributes make sure to avoid any of the following:

  • Send security relevant attributes, such as passwords, over unsecured network connections

  • Pass sensitive data about the users to the Producer.

 

Create a Producer online

If you work online when creating the Producer, we can connect to the Producer and access the Producer's WSDL document. This means that you only need to specify the location of the WSDL document of the Producer, rather than having to specify the Service Description and Markup interfaces of the Producer.

The URLs of the Producer WSRP interfaces are then taken from that WSDL document. The portal sends the required data to the Producer immediately. Optionally, we can define which user attributes you want to have transferred in the WSRP communication with the Producer.

In this case use either the Web Service Configuration portlet or the XML configuration interface to create the Producer

There are three different scenarios, depending on the type of Producer you want to create:

  1. The Producer does not require registration.

    In this case specify following information when creating the Producer in the Consumer portal:

    Property Required
    URL for the WSDL of the Producer Yes
    A name Yes
    description. No
    User attributes No

    The values for the selected user attributes are later passed on to the Producer when portal users use the Producer's Web service. For example, if you select the attribute for user name, then the Producer's Web service can address portal users by their name. By selecting specific attributes you prevent sensitive data about the users from being passed to the Producer.

    The registration handle and registration properties are not required.

  2. The Producer requires registration and is enabled for WSRP registration.

    In this case the Producer provides a registration port. As a Consumer, specify...

    Property Required
    URL for the WSDL of the Producer Yes
    Name Yes
    Description No
    Registration properties No
    User attributes No

    The registration properties are passed on to the Producer during the registration. For example, they can provide information about the geographical location, such as the postal code. The Producer can then adapt the Web service to the location. If you live near the mountains, the Producer might then provide information or offers for ski vacation or hiking.

    The registration handle is not required in this case. After the Consumer has completed the registration with the Producer, the Producer passes the registration handle to the Consumer, where it is stored in the Consumer portal database.

  3. If the Producer requires registration and is not enabled for WSRP registration...

    1. The owner of the Consumer portal registers with the owner of the Producer portal using...

      • e-Mail
      • mail
      • fax
      • phone
      • passenger pigeon

      The Consumer portal owner can provide registration properties. The Consumer portal owner receives the registration handle from the Producer portal owner.

    2. The Consumer portal administrator creates the Producer and provides the following information:

      Property Required
      URL for the WSDL of the Producer Yes
      Name Yes
      Description No
      Registration handle that the Consumer received from the Producer by outside communication. Yes
      User attributes No

      Note that Consumer provides no registration properties during creation because the Producer personnel already received this information during the registration by outside communication.

 

Use the Web Service Configuration portlet to create a Producer online

If you use the Web Service Configuration portlet to create a new Producer...

  1. Define the name for the new Producer
  2. Give a description for the Producer
  3. Specify the URL for the WSDL service definitions of the Producer
  4. Specify the registration handle for the Producer.

Optionally, we can also perform the following tasks:

  1. Set registration properties for the Producer.
  2. Set user attributes that you want to be passed on to the Producer.
  3. Set language-specific names and descriptions of the Producer.
  4. Assign access permission to users on a Web service Producer.
  5. Delete a Producer from the portal.

 

Create a Producer offline

If you are working offline we can only use the XML configuration interface to create the Producer.

Specify the URLs to the Service Description and Markup interfaces of the Producer. If the Producer supports the two optional WSRP interfaces, specify them as well.

If the Producer requires certain registration properties with the registration by the Consumer, you have to specify these properties also.

The XML configuration interface writes all parameters that you provide into the portal database. This includes all of the following information:

  • The URL for the Producer's WSDL service definitions
  • A name
  • A description
  • The registration handle received from the Producer by outside communication
  • The registration properties
  • The user attributes.

Except for the user attributes, the portal transfers these parameters to the Producer at a later time when both of the following conditions apply:

  1. You are working online.

  2. You update the portal configuration with an XML script that includes consuming a Web service as a remote portlet.

The user attributes are sent to the Producer with every markup or action request, that is when a user interacts with a remote portlet of that Producer.

 

Use the XML configuration interface to create a Producer

The main tag to specify when you use the XML configuration interface to create a Producer is the wsrp-producer tag.

The following table lists possible subtags we can specify with the wsrp-producer tag:

Possible subtag for the wsrp-producer tag Description
wsdl-url URL to the Producer's WSDL document.

This is the only tag that is required for creating a producer when using an online connection. The other URLs are extracted from this WSDL file.

service-description-url Producer's service description URL.

Required for offline creation.

markup-url Producer's markup URL.

Required for offline creation.

registration-url Producer's registration URL.

Required for offline creation.

portlet-mgt-url Producer's portlet management URL.

Required for offline creation.

parameter Used for registration properties.
preferences Used for user attributes.
localedata Specify NLS names and titles.
access-control Specify access control.
portlet-app Used to integrate portlets.

The following table lists possible attributes that we can specify with the wsrp-producer tag:

Possible attribute for the wsrp-producer tag Possible values Description
registration-required true|false Indicates whether the producer requires registration.
force true|false Forces creation of the producer.
default true|false Set to true if this is the default producer.

The following attributes are just listed for the sake of completeness. Do not change them.

Possible attribute for the wsrp-producer tag Possible values Description
The following attributes are just listed for the sake of completeness. Do not change them.
state (binary data) The Producer's state. This is specified as Base64 encoded binary data. It is usually only used during export and update by the XML configuration interface.
cookiepolicy One of: none per_user per_group undefined The Producer's cookie policy. The policy and possible values are defined in the WSRP specification.
wspproducer true|false This identifies whether this is a Web services Producer on the Producer side (specified locally) or on the Consumer side (specified as a remote Producer).

The following XML sample shows how to use the XML configuration interface to create a Producer... 

<?xml version="1.0" encoding="UTF-8" ?> 

<request type="update" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd" 
         create-oids="true">

   <portal action="locate">

      <wsrp-producer action="update" 
                     uniquename="wps.myProducer1">

         <service-description-url>
            http://portal_host:port/wp_contextRoot/WSRPServiceDescriptionService          </service-description-url>

         <markup-url>
            http://portal_host:port/wp_contextRoot/WSRPBaseService          </markup-url> 

         <localedata locale="en">
             <title>Producer 1</title> 
         </localedata>

      </wsrp-producer>

   </portal>

</request>

Replace...

http://portal_host:port/wp_contextRoot

...with the appropriate values for the environment.

The following XML sample shows how you use the XML configuration interface to create a Producer that requires registration.

We can use this sample if you work online and have access to the Producer's WSDL document. 

<?xml version="1.0" encoding="UTF-8" ?>

<request type="update" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd" 
         create-oids="true">

   <portal action="locate">

      <wsrp-producer action="update" 
                     registration-required="true" 
                     uniquename="wps.myProducer2">

         <wsdl-url>  
             http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl          </wsdl-url>

         <parameter name="regprop1" 
                    type="string" 
                    update="set">value1
         </parameter>

         <parameter name="regprop2" 
                    type="string" 
                    update="set">value2</parameter>

         <preferences name="userattributes" update="set">
             <value>cn</value>
             <value>o</value>
             <value>uid</value>
         </preferences>

         <localedata locale="en">
            <title>Producer 2</title>
         </localedata>

      </wsrp-producer>

   </portal>

</request>

Replace...

http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl

...with the appropriate values for the environment.

To use this sample with WebSphere Portal, set...

registration-required="false"

...and remove the parameter tags. This step is necessary because the WebSphere Portal Producer does not support registration.

After creating a Producer instance, we can proceed to integrating the WSRP services that are provided by that Producer into the Consumer portal.

 

Export a Producer using the XML configuration interface

The following example shows how you use the portal XML configuration interface to export a WSRP Producer. You might, for example, export the Producer from a test portal in order to update the production portal with it later. 

<?xml version="1.0" encoding="UTF-8" ?> 

<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd" 
         type="export">

   <portal action="locate">

      <wsrp-producer action="export" 
                     objectid="*" /> 

   </portal>

</request>

 

Consume a WSRP service

After you have created a Producer instance, we can proceed to consuming the WSRP services that are provided by that Producer, that is, integrating them into the Consumer portal as remote portlets.

On the Consumer side, all WSRP services that you consume as remote portlets behave like standard API compliant portlets, independent of their implementation on the Producer side.

To consume a WSRP service as a remote portlet in the Consumer portal, use either of the following tools:

 

Consume a WSRP service using the XML configuration interface

To consume a WSRP service using the XML configuration interface, for the remote portlet, specify...

Property Tag
groupid portlet-app
handle portlet
Both values are required and are defined by the owner of the Producer portal.

The Producer portal owner provides the handle and group ID to you by appropriate means, such as...

  • fax
  • phone
  • e-Mail

If we cannot access this information, use external tools such as the Apache WSRP to find out which WSRP services the Producer has to offer.

Producers with an IBM WebSphere Portal Producer can obtain this information by exporting all provided portlets on their Producer portal using the XML configuration interface

subtag Attribute for the subtag Description
portlet-app groupid As provided by the Producer
portlet handle As provided by the Producer

After successful integration, the remote portlets are available in the portal administration. They are handled in the same manner as local portlets.

We can consume a WSRP service only if you work online and can access the Producer's WSDL document.

The WSRP implementation of WebSphere Portal does not yet make use of public WSRP services registries, such as UDDI, to discover and consume WSRP services. Instead, it uses the discovery mechanism of WSRP services that is defined in the WSRP standard to obtain a list and descriptions of the WSRP services that a certain Producer provides.

An integrated portlet is always treated as a standard API compliant portlet.

To delete integrated remote portlets, use the portal administration portlets.

If you consume the WSRP service in an XML script that has already created the Producer, you only need to specify the following items in the XML script:

  1. A locate action on the Producer.
  2. The portlet-app subtag with the groupid attribute.
  3. The portlet subtag with the handle attribute.

The following XML sample shows how you use the XML configuration interface to integrate a WSRP service as a remote portlet: 

<?xml version="1.0" encoding="UTF-8" ?>

<request type="update" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_1.2.1.xsd">

   <portal action="locate">

      <wsrp-producer action="locate" 
                     uniquename="wps.myProducer1">

         <portlet-app action="update" 
                      active="true" 
                      groupid="_2_00KJL5N5NE0U0FIA_LT">

              <portlet action="update" 
                       active="true" defaultlocale="en" 
                       handle="_5_00KJL5N5NE0U0FIA_FN" 
                       name="WSRP_Reminder">

              <localedata locale="en">
                 <title>WSRP Reminder</title>
                 <description>Simple Reminder portlet as Web service</description>
              </localedata>

         <access-control externalized="false" 
                         owner="undefined" 
                         private="false"/>
         </portlet>

         </portlet-app>

      </wsrp-producer>

   </portal>

</request>

 

WSRP Markup Caching

The WSRP implementation in WebSphere Portal uses expiry-based markup caching for remote portlets to improve performance. This reduces the number of interactions between the Consumer and the Producer and enables the use of remote caches for pages containing remote portlets.

Markup caching for remote portlets is performed automatically and does not require any WSRP configuration. The Consumer caches remote portlet content in the dynamic fragment cache based on the cache-control data structure that the Producer provides as part of its response.

The Producer derives the WSRP cache control from the cache settings of the local standard API portlet. These settings are specified statically in the portlet definition or dynamically through the Portlet API during runtime. If the local portlet is not a standard API portlet, the Producer does not return any cache control information and thus disables caching for this portlet.

The cache control contains two parameters which control markup caching:

  • Expiration specifies the duration in seconds that markup fragment remains valid. A value of -1 indicates that the markup fragment will never expire. The Consumer uses this value to configure fragment caching for the proxy portlet. The Producer derives this parameter from the local portlet definition.

    If a value of -1 is specified the Consumer and all remote caches will cache the content for unlimited time. This means the content will never be update because the Producer will not be able to order the Consumer to refresh the cached markup.

  • Scope specifies a string indicating when the cached markup may be used by various users. The markup is either cached specifically for one user or for all users. This parameter is relevant for remote caching.

You enable and disable WSRP markup caching by setting the portal service configuration parameter wsrp.caching.enabled. The default for this parameter is true. This means that WSRP markup caching is enabled, if the parameter is not set.

  • To disable WSRP markup caching set the following parameter to false: wsrp.caching.enabled = false.
  • To enable WSRP markup caching again, set the same parameter to true: wsrp.caching.enabled = true.

 

Security considerations for using WSRP with WebSphere Portal

When using WSRP with WebSphere Portal, we can configure security and provide authentication by one of the following two options:

  • Authentication of the end user using LTPA token forwarding:

    In this case the Consumer portal passes requests from individual users on to the Producer portal under separate user IDs.

    For this option the Consumer and Producer portal need to share the same user registry.

  • Authentication of consumer portal using SSL Client Certificate Authentication:

    In this case the Consumer portal channels all requests by its users under the same preset shared user ID and passes them on to the Producer portal.

    For this option the Consumer and Producer portal can have shared or separate user registries.

When you configure security between the WSRP portals by one of these options, you also need to configure Portal Access Control for the Consumer portal users on the Producer portal. The following sections include the steps for how to do this.

 

Secure WSRP services by using LTPA token authentication

The WSRP Web service client and server of WebSphere Portal comply with the JSR 109 standard and can exploit the Web service security features of WAS.

Configure the client for LTPA token authentication only if the authentication mechanism configured in WAS is LTPA for both the Consumer Portal and the Producer Portal.

When a client authenticates to a Consumer portal using the LTPA authentication mechanism, a unique LTPA token is created for this client and used in subsequent client requests. When the Consumer portal calls a WSRP Producer, we can configure the Consumer portal to forward the LTPA token from the originating client. For the Producer portal to validate the LTPA token, the LTPA keys on both servers must be the same. By using this mechanism, the WSRP request and invocation of remote portlets on the Producer side run within the same security context as on the Consumer side.

The following sections describe how you configure the WSRP Consumer and Producer to use LTPA token authentication to secure WSRP services.

 

Prerequisites

LTPA token authentication for securing Web services has the following prerequisites:

  • The WAS LTPA authentication must be enabled on both sides, the Producer and the Consumer portal.

  • The same LTPA keys must be set up on the Producer portal and all participating Consumer portals. You need to exchange the LTPA keys between Producer and Consumer machines.

  • Producer portal and Consumer portal must use the same LTPA domain.

  • If the Producer and Consumer portals want to set LTPA authentication, they must be configured with the same user registry...

    • DBCUR
    • LDAP

  • The same LTPA password must be set on the Consumer and Producer portals.

To fulfill these prerequisites, administrators need to perform a set of tasks for both the Producer and Consumer portals. Most of the tasks are the same for both types of portals, but the tasks for modifying the Web Services Security Extensions and the Web Services Bindings differ between the Consumer and Producer portals.

 

Configure the Producer portal for LTPA token authentication

  1. Export the portal EAR file.

  2. Import the portal EAR file into an Assembly Tool.

  3. Configure the Producer portal for LTPA token authentication:

    1. Modify the Web services security extensions on the Producer portal to specify the LTPA authentication.

    2. Modify the Web services security bindings on the Producer portal.

  4. Export the modified portal EAR file.

  5. Redeploy the modified portal EAR file.

  6. After completing these two steps for a portal, restart the portal for the changes to take effect.

These tasks are described in detail in separate sections.

 

Configure the Consumer portal for LTPA token authentication

The following list gives an overview of the steps that are required to configure a Consumer portal for LTPA token authentication.

  1. Export the portal EAR file.

  2. Import the portal EAR file into an Assembly Tool.

  3. Configure the Consumer portal for LTPA token authentication:

    1. Modify the Web service client security extensions on the Consumer portal to specify the LTPA authentication.

    2. Modify the Web service client security binding information on the Consumer portal.

    3. If required, we can have the Consumer portal support different Web services security configurations for Producers.

  4. Export the modified portal EAR file.

  5. Redeploy the modified portal EAR file.

  6. After completing these two steps for a portal, restart the portal for the changes to take effect.

These tasks are described in detail in separate sections.

 

Known limitations with securing WSRP services by using LTPA token authentication

  • All-or-nothing setup:

    Producer portals that have been configured to do LTPA authentication will reject all SOAP messages that do not carry the valid LTPA token.

  • Consumer portals provide LTPA token in all cases:

    Consumer portals that have been configured to provide the LTPA token will do so for all target Producers, independent of whether the Producer requires the token or not. This can expose security issues if the token is unintentionally provided to other Producers.

  • IBM LTPA token is proprietary:

    The security setup of WSRP services by using LTPA token authentication uses a proprietary IBM LTPA token.

Consumer and Producer must be in the same LTPA cookie domain: The security setup of WSRP services by using LTPA token authentication works only if the Consumer and Producer portals are set up in the same LTPA cookie domain.

 

Export the portal EAR file

Before starting this task, verify the administrative server of the application server (the default name is server1) is started.

Export the WebSphere Portal EAR file, wps.ear, according to the network configuration. If you have a cluster environment, the WebSphere Portal EAR must be exported from the Network Deployment machine.

  1. At a command line, change to...

    was_profile_root/bin

    ...or, if you have a portal cluster installation, change to...

    dmgr_profile_root/bin

  2. Invoke the wsadmin command to export the wps.ear to a temporary directory...

      ./wsadmin.sh -user admin_user_id -password admin_password -c '$AdminApp export wps directory/wps.ear'

 

Import the portal EAR file into an assembly tool

  1. Assembly Tools

  2. Configure Web services security while assembling Web services applications

 

Configure the Producer portal for LTPA token authentication

The following sections describe how you configure the Producer portal for LTPA token authentication. To do this, use the tools provided by the Application Server Toolkit (AST). This is provided with the portal on a separate set of CDs.

 

Specify LTPA authentication for the Producer portal

See Configure Web services security while assembling Web services applications

To specify the LTPA authentication for a Producer portal, modify the Web Service Client Security Extensions in the Assembly Tool. Proceed by the following steps:

  1. In the J2EE perspective, project explorer, expand...

    WebServices | Clients

    • Open the service descriptor WSRPService with the WebServices Client Editor (it is the default).

    • Alternatively, we can open the service descriptor by opening...

      Dynamic Web Projects | wps.war | Web Content | WEB-INF | webservices.xml

      ...where wps.war is the war name you assigned in the import step.

  2. In the Web Services Client editor navigate to the tab Extensions.

  3. For every port that requires LTPA token authentication, select the port in the Port Component Binding section. Click...

    Request Consumer Service Configuration Details | Required Security Token | Add

    ...to add a new token. In the pop-up Required Security Token dialog, proceed with the following steps:

    1. Assign the token a unique name.

    2. Select LTPA token as the token type in the drop-down list.

    3. Click OK to leave the dialog.

  4. For every port that requires LTPA token authentication, select the port in the Port Component Binding section. Under...

    Request Consumer Service Configuration Details | Caller Part

    ...click add to add a caller part definition. In the pop-up Caller Part dialog, proceed with the following steps:

    1. Assign the caller a unique name.

    2. Select LTPA token as the token type in the drop-down list.

    3. Click OK to leave the dialog.

  5. Click Save to save the changes.

 

Modify the security binding information for the Producer portal

This section describes how you add the necessary Producer security binding information for each WSRP portType. We can do this one of the following ways:

  • Using the Assembly Tool's Web Services Editor.

  • Using WAS Administrative Console.

    This can only be done after you have modified the Web Services Client Security Extensions in an earlier step and redeployed the WebSphere Portal EAR file.

To specify the security binding information for a Producer portal, modify the Web Service Client Security Extensions in the Assembly Tool. Proceed by the following steps:

  1. In the J2EE perspective, project explorer, expand...

    WebServices | Services

    • Open the service descriptor WSRPService with the WebServices Client Editor (it is the default).

    • Alternatively, we can open the client descriptor by opening...

      Dynamic Web Projects | wps.war | Web Content | WEB-INF | webservices.xml

      ...where wps.war is the war name you assigned in the import step.

  2. In the Web Services editor navigate to the tab Binding Configurations.

  3. For every port that requires LTPA token authentication select the port in the Port Component Binding section. Click...

    Request Consumer Binding Configuration Details | Token Consumer Add

    ...to add a new token consumer. In the pop-up Token Consumer Dialog, proceed with the following steps:

    1. Assign the token consumer a unique name.

    2. Select...

      com.ibm.wsspi.wssecurity.token.LTPATokenConsumer

      ...as the token consumer class from the drop-down list.

    3. Select the security token to which this token consumer applies. The securtiy token is the name of the token you assigned in the Web Service Security Extensions for the portType you are configuring.

    4. Select LTPA token as the value type in the drop-down list.

    5. Click OK to leave the dialog.

  4. Click Save to save the changes in the service descriptor.

  5. Export the modified portal EAR file.

  6. Redeploy the modified portal EAR file.

To enable Portal Access Control for the Producer portal, set...

wsrp.security.enabled=true

...in Configuration Service, as described in Setting configuration properties.

After you have specified the LTPA authentication and modified the authentication method information for the Producer portal, restart the portal for the changes to take effect.

 

Configure the Consumer portal for LTPA token authentication

The following sections describe how you configure the Consumer portal for LTPA token authentication. To do this, use the tools provided by the Application Server Toolkit (AST). This is provided with the portal on a separate set of CDs.

 

Modify the client security extensions to specify LTPA authentication for the Consumer portal

To specify the LTPA authentication for a Consumer portal, modify the Web Service Client Security Extensions in the Assembly Tool...

  1. In the J2EE perspective, project explorer, expand...

    WebServices | Clients

    • Open the client descriptor wps.ear:

      service/WSRPService

      ...with the WebServices Client Editor (it is the default), where the wps.ear is the imported EAR name you assigned in the import step.

    • Alternatively, we can open the client descriptor by opening...

      Dynamic Web Projects | wps.war | Web Content | WEB-INF | webservicesclient.xml

      ...where wps.war is the war name you assigned in the import step.

  2. In the Web Services Client editor navigate to the tab WS Extension.

  3. For every port that requires LTPA token authentication select the port in the Port Qname Bindings section. Under...

    Request Generator Configuration | Security Token

    ...click add to add a new token. In the pop-up Security Token Dialog, proceed with the following steps:

    1. Assign the token a unique name.

    2. Select LTPA token as the token type in the drop down list.

    3. Click OK to leave the dialog.

  4. Click Save to save the changes.

 

Modify the client security binding information for the Consumer portal

This section describes how you add the necessary Consumer security binding information for each WSRP portType. We can do this by one of the following two ways:

  • By using the Web Services Client Editor of the Assembly Tool.

  • By using the WAS Administration Console.

    This can only be done after you have modified the Web Services Client Security Extensions in the previous step and redeployed the WebSphere Portal EAR file.

To specify the security binding information for a Consumer portal, modify the Web Service Client Security Extensions in the Assembly Tool. Proceed by the following steps:

  1. In the J2EE perspective, project explorer, expand...

    WebServices | Clients

    • Open the client descriptor wps.ear:

      service/WSRPService

      ...with the WebServices Client Editor (it is the default), where the wps.ear is the imported EAR name you assigned in the import step.

    • Alternatively, we can open the client descriptor by opening...

      Dynamic Web Projects | wps.war | Web Content | WEB-INF | webservicesclient.xml

      ...where wps.war is the war name you assigned in the import step.

  2. In the Web Services Client editor navigate to the tab WS Extension.

  3. For every port that requires LTPA token authentication select the port in the Port Qname Bindings section. Under...

    Request Generator Configuration | Security Token

    ...click add to add a new token. In the pop-up Security Token Dialog, proceed with the following steps:

    1. Assign the token generator a unique name.

    2. Select...

      com.ibm.wsspi.wssecurity.token.LTPATokenGenerator

      ...as the token generator class from the drop-down list.

    3. Select the token name to which this token generator applies. The token name is the name you assigned in the Web Service Client Security Extension for the portType you are configuring.

    4. Select LTPA token as the token type in the drop-down list.

    5. Select...

      com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler

      ...as the callback handle from the drop-down list.

    6. Click OK to leave the dialog.

  4. Click Save to save the changes.

  5. Export the modified portal EAR file.

  6. Redeploy the modified portal EAR file.

 

Modify the Consumer portal for using different WS-Security configurations for Producers

This section describes how you customize the Consumer portal to use different security settings for different WS-Security configurations for Producers.

These settings overwrite the security settings configured in the Web Service Client Security Extensions and Web Service Client Bindings . This task is accomplished by generating custom...

  • ibm-webservicesclient-ext.xmi
  • ibm-webservicesclient-bnd.xmifiles

Only one port can be described in each set of extension and binding files. For each portType, a pair of files...

  • ibm-webservicesclient-ext.xmi
  • ibm-webservicesclient-bnd.xmifiles

...needs to be created which contain only one portType definition. Therefore, if the ws-security settings for all producers are different, repeat steps 3 to 5 and specify the settings respectively.

To generate these files, perform the following steps for each portType:

  1. Export the WebSphere Portal EAR file as described in Export the WebSphere Portal.

  2. Import the WebSphere Portal EAR file into an Assembly Tool as described under Import the EAR file into an Assembly Tool.

  3. Modify the Web Service Client Security Extensions:

    1. In the J2EE perspective, project explorer, expand...

      WebServices | Clients

      • Open the client descriptor wps.ear:

        service/WSRPService

        ...with the WebServices Client Editor (it is the default), where the wps.ear is the imported EAR name you assigned in the import step.

      • Alternatively, we can open the client descriptor by opening...

        Dynamic Web Projects | wps.war | Web Content | WEB-INF | webservicesclient.xml

        ...where wps.war is the war name you assigned in the import step.

    2. In the Web Services Client editor navigate to the tab WS Extension.

    3. In the Port Qname Bindings section, remove all portTypes except the one you intend to configure.

    4. Follow the description in Specifying LTPA authentication for the Consumer portal to configure the...

      Request Generator Configuration | Security Token

    5. Save the changes in the client descriptor.

  4. Modify the Web Service Client Bindings:

    1. In the Web Services Client editor navigate to the WS Binding tab.

    2. In the Port Qname Binding section remove all portTypes except the one you intend to configure.

      It has to be same portType that you configured in the Web Service Client Security Extensions tab.

    3. Follow the description in Modifying the security binding information for the Consumer portal to configure the...

      Security Request Generator Binding Configuration | Token Generator

    4. Save the changes in the client descriptor.

  5. Copy and rename the changed files...

    • ibm-webservicesclient-ext.xmi
    • ibm-webservicesclient-bnd.xmi

      ...to a location of the choice in the file system. To do this:

      1. Select both files in the...

        Project Explorer | Dynamic Web Projects | wps.war | Web Content | WEB-INF

      2. Right-click, select...

        Export | File System

      In a cluster environment place the file at the same directory location in each cluster node.

    • After you have created all necessary files, add the following WSRP configuration properties of the portal Resource Environment Provider WSRPWebServiceSecurity in the WAS Administrative Console.

      With the configuration of this Resource Environment Provider we can assign the Web service client and Web service extension files for each port to a Producer. We can configure the following custom properties:

      reloadInterval =(900)

      Reload time interval by which the Consumer loads this property file into its memory.

      Optional. Specify a value in seconds. A value of zero or less will stop reloading the configuration. The default value is 900 seconds (= 15 minutes).

      producerToken.wsdl

      URL to the Producer WSDL file.

      Mandatory if port definitions for this Producer are available. The value of this property has to be unique in this file.

      producerToken.WSRPBaseService.WSClientExtension

      File location of the Web service client extension file for the WSRPBaseService. This property is optional.

      producerToken.WSRPBaseService.WSClientBinding

      File location of the Web service client binding file for the WSRPBaseService.
      Replace producerToken with a unique, freely definable group identifier.

      The security configuration with the binding and extension files for...

      • WSRPServiceDescriptionService
      • WSRPPortletManagementService
      • WSRPRegistrationService

      ...needs to follow the rules of the WSRPBaseService.

      The following shows an example configuration of the WSRP Resource Environment Provider with two Producers and a Producer security configuration for the WSRPServiceDescriptionService and WSRPBaseService:

      Property name Property value 

      producer1.wsdl                
producer1.WSRPBaseService.WSClientExtension    
producer1.WSRPBaseService.WSClientBinding        
producer1.WSRPServiceDescriptionService.WSClientExtension producer1.WSRPServiceDescriptionService.WSClientBinding    

producer2.wsdl                
producer2.WSRPServiceDescriptionService.WSClientExtension    
producer2.WSRPServiceDescriptionService.WSClientBinding    


      http://www.portal.com:10038/wps/wsdl/wsrp.wsdl c:/portal/p1_bs_ext.xmi c:/portal/p1_bs_bnd.xmi c:/portal/p1_sd_ext.xmi c:/portal/p1_sd_bnd.xmi 
http://foreignhost:80/portal/wsdl/file.wsdl c:/portal/p2_sd_ext.xmi c:/portal/p2_sd_bnd.xmi

 

Export the modified portal EAR file from the assembly tool

  1. Assembly tools

  2. Configure Web services security while assembling Web services applications

 

Redeploy the portal EAR file

Before starting this task, verify the application server's administrative server (the default name is server1) is started. For UNIX and Windows:

  1. Delete the original the wps.ear file from the directory where you initially exported it.

  2. Copy the modified wps.ear file into your export directory.

  3. Use the wsadmin command to update the WebSphere Portal EAR file. If you have a cluster environment, update the EAR file on the primary portal node to synchronize the update across all nodes in the cluster.

    ./wsadmin.sh -user admin_user_id -password admin_password -c '$AdminApp install directory/wps.ear {-update -appname wps -deployejb -deployejb.classpath wps.home /shared/app/wp.base.jar}'

  4. Restart WebSphere Portal. In a cluster configuration, restart WebSphere Portal on each node.

Updates to the configuration of a WebSphere Portal cluster must occur on the Deployment Manager and be resynchronized with the other nodes in the cluster. If updates are made to individual nodes in the cluster, the updates will be lost when the master configuration on the Deployment Manager resynchronizes with the nodes again.

 

Secure WSRP by using SSL

We can enable security for the WSRP implementation by using SSL with Client Certificate Authentication....

  1. Set up the portal for SSL support.
  2. Enable the WSRP Consumer portal to use HTTPS for communication with Producers.

If you configure the WSRP Consumer for SSL client authentication, the WSRP Consumer uses a proxy user ID to authenticate on behalf of the individual users.

Configure the proxy user ID by consumer-side SSL client certificate. The WSRP Consumer provides individual personalization information, but authenticates for all users by using the same identity information.

Do not use portlets that utilize the Credential Vault over WSRP in conjunction with SSL client authentication. If a portlet on the Producer portal utilizes the Credential Vault, all users from one Consumer portal access the same credential slot and can read and override individual settings in the credential slot.

As J2EE allows only for one authentication mechanism per WAR file, WSRP introduces a second WAR file for the Producer portal. This WAR file is named wps_facade.war, which contains servlets that work as a facade interface Web application, channeling the WSRP requests to the Producer's access points.

We can now simultaneously use both SSL client authentication for the WSRP Producer portal and other means of authentication for the rest of the portal, for example form based authentication. You do this as follows:

  • Configure the primary portal WAR file for use of other means of authentication, for example form based authentication.

  • Configure SSL client authentication for the web.xml of the facade WAR file for the WSRP Producer.

This second WAR file for the Producer requires a separate context root for the Producer. The default value for this second context root is wsrp to give the full context root...

http://my.portal.com:myport/wsrp

We can configure this context root as required. To do this, modify the property...

uri.context.path.facade

...to a different value in Configuration Service.

 

Set up the portal for SSL support

  1. Configure the portal for SSL communication between the Web browser and WebSphere Portal.

  2. Configure WAS for SSL support.

    1. Enable security.

    2. Enable SSL ID tracking...

      Application Servers | WebSphere_Portal | Web Container | Session Management

    3. Configure the advanced LDAP security settings.

      Certificate-based authentication requires that you configure the authentication mechanism so that one of the following conditions apply:

      • WAS maps the entire Distinguished Name from the subject field of the certificate to a corresponding DN in the LDAP.

        To use this option, set the mapping technique in the LDAP configuration panel to exact.

      • WAS maps the entry in the subject field to a different attribute than the DN in the user registry.

        To use this option, set up the mapping technique in the LDAP configuration panel to use the certificate filter option. Using the certificate filter option allows you more flexibility in using other attributes than the DN to identify the users. For example, the filter...

        uid=${SubjectCN}

        ...maps the SubjectCN field of the client certificate to the uid attribute in the LDAP.

      If you are using an LDAP with realm support on the producer, define the certificateFilter attribute at the wmm tag in...

      portal_server_root/wmm/wmm.xml

      ...for example...

      certificateFilter="uid=${SubjectCN}"

    4. Define a new virtual host alias. Click...

      Environment | Virtual Hosts | default_host | Host Aliases | New

      ...and define the SSL communication port. We can use an asterisk ( * ) as a wild card for the hostname.

  3. If you use an external HTTP server, perform the following additional steps:

    1. Regenerate the plug-in. To do this, click...

      Servers | Web Servers

      ... Select the Web server and click Generate Plug-in. Update the HTTP server with the generated plug-in.

    2. Restart the HTTP server for the changes to take effect.

    3. Enable client authentication in the Web server.

      See www.redbooks.ibm.com/ for more information.

    4. Exchange the public certificates to be used for the SSL connection between the Consumer and the HTTP servers and import them into the corresponding trust stores.

  4. Edit...

    was_config_root/cells/cell/applications/wps.ear/deployments/wps/wps_facade.war/WEB-INF/web.xml

    If you have a portal cluster installation, perform this step on the Network Deployment server. Add the following tags to the web.xml file:

    • Add a new login-config tag for the client certificate authentication method with a new unique ID, for example: 

      <login-config id="LoginConfig_your_id_number">
   <auth-method>CLIENT-CERT</auth-method>
   <realm-name>WPS_FACADE</realm-name>
</login-config>

    • Add new security-constraint tags with unique IDs for the URL patterns...

      WSRPBaseService
      WSRPPortletManagementService

      The following example shows the WSRPBaseService URL pattern: 

      <security-constraint id="SecurityConstraint_your_id_number">
   <web-resource-collection id="WebResourceCollection_your_id_number">
      <web-resource-name></web-resource-name>
      <url-pattern>/WSRPBaseService</url-pattern>
      <http-method>GET</http-method>
      <http-method>POST</http-method>
      <http-method>PUT</http-method>
   </web-resource-collection>
   <auth-constraint id="AuthConstraint_your_id_number">
      <description></description>
      <role-name>All Role</role-name>
   </auth-constraint>
   <user-data-constraint id="UserDataConstraint_your_id_number">
      <transport-guarantee>CONFIDENTIAL</transport-guarantee>
   </user-data-constraint>
</security-constraint>

    Save the changes.

  5. Update the affected properties in Configuration Service, as described in Setting configuration properties, to the following values:

    1. To enable Portal Access Control for the Producer portal, set the following parameter to true:

      wsrp.security.enabled = true

    2. If the URLs of the WSRP ports have to point to different locations or use different ports, configure them accordingly. By default, the URLs of the WSRP ports are the same as the URLs by which the Web services WSDL document is addressed by Consumers.

  6. Restart the portal for the changes to take effect.

For more details about how to perform these steps, see the following topics:

 

Enable the WSRP Consumer portal to use HTTPS for communication with Producers

Enable transport layer security in the WAS Administrative Console for each of the four WSRP ports.

  1. Click...

    Applications | Enterprise Applications | wps | Web Module | wps.war | Web Services: Client Security Bindings | HTTP SSL Configuration | Edit...

  2. Activate HTTP SSL enabled

  3. Select the appropriate HTTP SSL configuration. Perform this step for each of the four WSRP ports.

If the communication with the Producer is set up to use Secure Socket Layer communication, use https to address the Producer URL:

https://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl

 

Configure WSRP Consumer portal if you use client authentication to integrate Producers

If the WebSphere Portal acts as a WSRP Consumer and uses client authentication to integrate other Producers, configure the portal as follows:

  1. Create the client certificate for the proxy user ID.

  2. Add the client certificate into the keystore on the Producer side.

  3. Add the required client certificate to the key store that is defined for the SSL configuration of the Web service ports on the Consumer side.

  4. Add the required client certificate to the default trust or key store as configured for JSSE (usually CACERTS) on the Consumer side.

  5. If you have configured the ContentAccessService for a different SSL trust or key store, you also need to add the required client certificates to the trust or key store that you have configured for ContentAccessService.

 

Enable Portal Access Control for WSRP with WebSphere Portal

If you are using one of the authentication mechanisms described above, we can configure Portal Access Control for the Producer. To enable Portal Access Control when using WSRP with WebSphere Portal...

  1. Activate the WSRP security by setting the property...

    wsrp.security.enabled=true

    ...in Configuration Service, as described in Setting configuration properties.

  2. Assign access rights based on the authentication information:

    • If you use LTPA token authentication, assign access rights to the actual Consumer portal users.

    • If you use SSL client certificate authentication, assign access rights to the shared user ID as specified in the client certificate.

For more details and considerations about Portal Access Control, refer to Configuring security and Manage access, users, and groups.

 

Customize the WSRP configuration of the portal

 

Set the WSRP SOAP ports

URLs for WSRP SOAP ports can be changed in the Producer WSDL document.

For example, to provide Web services under different virtual Producers, provide different ports on different machines or use different proxy servers through which Consumers can access the Producer portal.

Modify the configuration properties of the Configuration Service Environment Resource Provider in the WAS admin console.

We can specify three different port URLs for HTTP and three different port URLs for HTTPS to be used with SSL.

  • Each of the URLs must include the protocol, such as HTTP or HTTPS, the name or the IP address of the host, and the context root of the Producer portal. We can configure this context root as required.

  • To be able to support different authentication mechanisms for the regular portal and the WSRP Producer, the WSRP Producer uses a different Web module with a different context root.

  • The URLs must not end with a path separator slash ( / ).

  • The URLs can contain a port number.

An example of a valid URL is shown here:

http://my.portal.com:myport/wp_facade_contextRoot

The keys for the HTTP WSRP SOAP URLs...

The keys for the secured HTTPS WSRP SOAP URLs ...

To use different authentication mechanisms for the regular portal and the WSRP Producer, use a different Web module with a different context root for the WSRP Producer.

 

Proxy settings

If configure the proxy settings of a Consumer portal for the WSRP communication, use the settings of the ContentAccessService to do this. For more details see Portal service configuration.

 

Parallel portlet rendering

To enable parallel portlet rendering in the portal, set one or both of the parameters for parallel portlet rendering to true. You change the values for these parameters in the PortletContainerService as described under Setting configuration properties. The settings depend on the type of portlets you use and on whether you consume Web services as remote portlets or not:

The settings that you specify do not influence the invocation via WSRP of portlets that you provide as a Producer. This is because the Consumer always sends a separate WSRP request for each single portlet.

 

Switching the caching off and on

By default, the portal caches the WSRP service descriptions from Producers whose portlets the Consumer has integrated. The caching increases performance and reduces network traffic.

If you encounter problems, or for any other reason want to turn off caching of the service description, edit the file...

CacheManagerService.properties

...and set the parameter...

cacheinstance.wsrp.cache.servicedescription.enabled=false

This file is located in the following directory:

portal_server_root/shared/app/config/services

 

Customize the WSRP resource proxy for HTTP basic authentication

To customize the WSRP resource proxy for HTTP basic authentication, set the following property in the Configuration Service.

wsrp.resourceproxy.basic.auth.credentialslot = your_credential_slot

Use this property to specify a credential vault slot that contains the user ID and password credentials. The resource proxy servlet will use the credentials from the credential vault slot when fetching resources that are protected by HTTP basic authentication. The user ID an password will be sent to all remote resources that are referenced in the markup of the remote WSRP portlet.

 

Known limitations

This section lists hints and tips for using WSRP with WebSphere Portal.

Remote portlets on unauthenticated pages

If you add remote portlets to unauthenticated pages that have public sessions switched off, this has the following two consequences:

  1. Session data is lost for each request.

  2. An additional request to the Producer is submitted to establish a session.

If you add remote portlets to unauthenticated pages, switch on public sessions. This way we can benefit portal performance and avoid unexpected behavior resulting from the lost session data.

 

Rendering URLs for forms

Submitting data to a portlet through forms is semantically an action as the state of the portlet is changed by this request. WSRP strongly enforces the separation of action and render requests according to the corresponding semantics. It prevents the submission of form data through render requests.

This means that portlets that use render URLs to submit form data do not work remotely.

 

Portlets using portal internals

With WSRP we cannot use portal internals in portlets, such as...

Portlets that use such internals do not work remotely as WSRP does not supply the infrastructure required for this.

 

Dynamic titles for remote portlets

The WSRP proxy portlet is written according to the standard portlet API. As the implementation of the standard API portlet container does not support dynamic titles for WebSphere Portal, dynamic titles do not work, even if the remote portlet is written according to the IBM portlet API. This includes calls to the methods of the IBM portlet API PortletTitleListener interface.

 

Invocation of minimized portlets

The WSRP proxy portlet is written according to the standard portlet API. As the implementation of the standard API portlet container does not support the invocation of minimized portlets for WebSphere Portal, a minimized portlet is not called even if the remote portlet is written according to the IBM portlet API.

 

Remote Portlet Web Services (RPWS)

WebSphere Portal Version 6.0 does not support the IBM proprietary Remote Portlet Web Services (RPWS) that WebSphere Portal Version 4 supported. (This is not the same as WSRP - Web Services for Remote Portlets.)

 

Compatibility of portlets with WSRP

Some portlets cannot be provided as WSRP services, as some additional WebSphere Portal concepts and features are not reflected by the current WSRP standard yet. This includes all portal administration portlets and some other portlets that are provided as part of the portal.

 

Wires are not supported with WSRP

The use of wires is not supported with portlets provided or consumed with WSRP.

Consumer-side configuration of consumed portlets that do not support shared configuration is not supported with WSRP.

The configuration of the edit_defaults_compatibility portlet mode as described under Configuring portlets to support shared configuration is not supported for portlets that are consumed by using WSRP.

 

The PUMA SPI cannot be used with WSRP.

The PUMA SPI does not allow use with remote portlets.

 

Troubleshoot

To ease debugging and monitoring of the WSRP communication, the servlet that generates the WSDL document of a WebSphere Portal Producer accepts the optional URL parameter port. Use this parameter to modify the ports of the WSRP interfaces that are exposed by that Producer. Specify this parameter as an addition to the URL for the Producer's WSDL document.

Here is an example of a Web address that we can enter in the browser, with the port parameter added:

http://portal_host:port/wp_contextRoot/wsdl/wsrp_service.wsdl?port=portValue

Adding this parameter does not configure the actual ports of the WSRP interfaces. A direct communication against these ports will fail. This parameter only changes the values that appear in the WSDL document. Therefore use it to monitor the WSRP communication. If the port parameter is missing, then the correctly configured ports of the WSRP interfaces are exposed in the generated WSDL document.

 

Set traces and using the WebSphere Portal run-time log file for WSRP diagnosis

To diagnose problems that might occur during the use of WSRP with WebSphere Portal, we can set WSRP specific traces and enable run-time logs for the Consumer, Producer, and administration components of the WSRP implementation. Use the portal administration portlet Enable Tracing to do this.

We can enable the following trace loggers for the WSRP implementation:

Component Trace string
Administration com.ibm.wps.command.wsrp.*=all=enabled com.ibm.wps.wsrp.cmd.*=all=enabled
Consumer com.ibm.wps.wsrp.consumer.*=all=enabled
Producer com.ibm.wps.wsrp.producer.*=all=enabled
XMLAccess com.ibm.wps.command.xml.*=all=enabled

 

Monitor WSRP messages between the Consumer and Producer

Use the TCPMon tool to monitor the WSRP messages between the Consumer and Producer, as described in the WAS Information Center topic Tracing Web services messages. To do this, configure the TCPMon tool to listen on the port that you specified for the optional port parameter. Also, set the target port to the actual port values of the Producer's WSRP interfaces. For the WebSphere Portal Producer, these are the ports that appear in the WSDL file when requesting the WSDL without the port parameter. Run the TCPMon tool using the following command:

java -cp app_server_root/lib/webservices.jar com.ibm.ws.webservices.engine.utils.tcpmon

 

Parallel portlet rendering with remote portlets

If you encounter errors with parallel portlet rendering of remote portlets in the Consumer portal, try to improve this situation by further increasing the value of the timeout parameter parallelRenderingTimeOut beyond the value of 10000 given further above.

 

Abbreviations

J2EE

Java 2 Platform, Enterprise Edition

JSSE

Java Secure Socket Extension

JSTL

JSP Standard Tag Library

SOAP

Simple Object Access Protocol

UDDI

Universal Description, Discovery, and Integration

WSRP

Web Services for Remote Portlets

WSDL

Web Services Description Language

WSIA

Web Services for Interactive Applications

 

Related information

 

Parent topic:

Administering

 

Related concepts


Set up the Common PIM portlets as remote portlets