This section explains the tasks that need to be performed to configure Portal Server to consume remote portlets offered by the producer.
Task |
Description |
Instruction |
1. Add a configured producer at the consumer so that the consumer can access the remote portlets offered by the producer. If the producer supports registration, provide the consumer details required by the producer or provide a registration handle obtained from the producer. |
A configured producer is a single consumer instance that consumes portlets from a consumer. Portal Server allows you to create any number of configured producers that point to the same producer or different producers. A consumer needs to add a configured producer to communicate with the portlets offered by the producer. If a producer supports registration, add a configured producer using the following methods:
If the producer does not support registration, the consumer is not required to enter any details while adding a configured producer. When you add a configured producer, Portal Server interface provides you the options based on the registration mechanism supported by the producer. You can also enables an Identity Propagation Mechanism if you want to federate the consumer identity from the consumer portal to the producer portal. | |
2. (Optional) Create user credentials using the WebServices SSO portlet if the consumer wants to enable an identity propagation mechanism for the users of the consumer. |
If the consumer enables an identity propagation mechanism, the end user can provide the credentials for single sign on using the WebService SSO Portlet. WebServices SSO Portlet is based on the SSO Adapter Service available on Portal Server. This service provides a mechanism to manage and authenticate the users to the remote services that are used by Portal Server. You can define the user name and password for a specific web service offered by the producer. | |
3. Create channels to display remote portlets on the portal desktop of the consumer so that the users of the consumer portal can access the remote portlets. |
After you add a configured producer, you must create a channel to display the remote portlets offered by the producer on the consumer's desktop. Users of the consumer portal can view the remote portlets on their desktop. |
To Create Channels to Display Remote Portlets on the Portal Desktop |
4. (Optional) Access a producer trough a gateway if the producer is outside of the network where a consumer portal is deployed. |
You must configure proxies if Portal Server is used as WSRP consumer that is deployed in an internal network and the producer is outside the firewall. After a WSRP consumer is created, you need to create Remote WSRP channels on the Portal desktop. Portal Server runs inside the web container. To fetch the contents from the remote WSRP Producer, web container needs to have the same proxy settings in its configuration. | |
5. Update the service description of the consumer to update the changes the producer made after adding a configured producer. |
The WSRP protocol does not have a notification mechanism to make consumers aware of attribute changes that a producer makes after a consumer adds a configured producer. After the consumer configures the producer, use the Update Service Description option to update any changes made to the producer later. | |
6. (Optional) Export roles as user categories in producer so that the consumer can map the user categories to a locale role. |
Mapping user categories to the roles allows the consumer to map the roles that are defined in the consumer portal to the roles that are defined in the producer, so that the producer can provide the portlets based on the user roles. Portal Server maps Sun Java System Access Manager's roles to the portlet's roles. These roles can be mapped to the corresponding WSRP user categories. A producer can export the list of roles it supports as user categories. The consumer can optionally choose to map the local roles it has to these user categories that are exported by the producer. This mapping enables the consumer portal to indicate the producer portal that this user belongs to certain user categories that the remote portlet exposes, so that the producer can provide the portlets based on the user categories of the consumer. Roles can be defined in the portlet while deploying the portlet. Note – The roles defined in the portlet must exist in the Access Manger of the producer. | |
7. (Optional) Map user categories of the producer portlets to the consumer roles, so that remote portlets can be accessed based on the access privileges of the consumer roles. |
A consumer can map the user categories exported by the producer to local roles. If the user belongs to any local role, then the consumer can use this mapping and indicate the producer that this user belongs to this user category, so that the producer can offer portlets based on the user categories of the consumer. If a consumer portlet uses any of the attributes that are not specified in the LDAP schema, you can map consumer attribute to the corresponding WSRP attribute using Sun Java System Access Manager administrator console. For more information, see Mapping Consumer Attributes. |
Log in to the Portal Server administration console.
Click the portal name hyperlink.
Click the WSRP tab.
If you are not on the Producer tab, see To Navigate to the WSRP Consumer Options in the Portal Server Administration Console.
Select DN (Distinguished Name). Click New to create a new configured producer.
Type the configured producer name. Select the identity propagation mechanism. By default, None is selected.
An identity propagation mechanism allows the users of the consumer portal to present their credentials to the producer portal and allows the users federate their identity from the consumer portal to the producer portal. For more details on identity propagation mechanism, see Identity Propagation Mechanism.
Type the WSDL URL and click Next.
You can search for a WSDL URL based on the producer or portlet if you do not know the WSDL url of the producer. The search result displays WSDL URL of a producer only if the producer is published. For more information on how to search for a producer using the command line interface, see To Search for a Producer Details.
(Optional) If the producer requires registration, you can register the producer in two methods:
Enter the registration property values (in-band registration)
Enter the registration handle (out-of-band registration)
Click Next.
If you selected the first method in step 7, enter the registration properties and click Next. If you selected the second method, enter the registration handle obtained through out-of-band communication, and click Next.
Review the details and click Finish.
Log in to the Portal Server administration console.
Click the portal name hyperlink.
Select the DN on which you want to create a remote portlet.
Click Manage Channels and Containers.
Select the container to which you want the remote portlet to appear.
Click New Channel or Container on the right tab.
A wizard appears.
Select portal, DN, and Channel.
Click Next and select WSRP Remote Portlet Channel.
Click Next.
The screen displays the list of available configured producers.
Select the configured producer and click Next.
The Remote Portlet list displays the list of remote portlets that the producer offers.
Select the remote portlet and click Next.
Provide a local channel name for the remote portlet.
Click Finish to create a remote portlet on your portal desktop.
Log in to portal desktop as a user and select the container or tab on which you created the remote portlet. The portlet is visible on your portal page.
In a text editor, edit the following file:
/var/opt/SUNWappserver/domains/domain1/config/domain.xml
Set the following JVM options: Dhttp.proxyHost, Dhttp.proxyPort, Dhttp.proxyUser, and Dhttp.proxyPassword.
Save the file.
If you are not on the Consumer tab, see To Navigate to the WSRP Consumer Options in the Portal Server Administration Console.
Select DN (Distinguished Name).
Click the configured producer hyperlink.
In the Edit Configured Producer screen, click Update Service Description.
Check the local repository/cache for the new portlets offered by this producer.
Create a new channel to see if any new portlets are offered by the producer.
In the Access Manager administrator console, create a role and add a user.
While deploying the portlet in webxml of the portlet application, add the following code:
<security-role> <role-name>PS_TEST_DEVELOPER_ROLE<role-name> </security-role> |
Add the following lines in the portlet.xml file of the portal.
<security-role-ref> <role-name>PS_TEST_DEVELOPER_ROLE<role-name> <role-link>PS_TEST_DEVELOPER_ROLE<role-link> </security-role-ref> |
Create the portlet application war file.
Create a roles file with the following entry.
cn\=AM_TEST_DEVELOPER_ROLE,o\=PortalSample,dc\=domain, dc\=domain,dc\=com=PS_TEST_DEVELOPER_ROLE
Deploy the portlet using the following command.
/opt/SUNWportal/bin/psadmin deploy-portlet -u amadmin -f ps-password -d "o=PortalSample,dc=domain,dc=domain,dc=com"-p portal1 -i portlet-name --rolesfile roles-file test-portlet-war-file
This task deploys a portlet. All roles associated with the portlet are automatically exported as user categories in the producer.
If you are not on the Consumer tab, see To Navigate to the WSRP Consumer Options in the Portal Server Administration Console.
In the Consumer tab, click the configured producer name hyperlink.
User Category displays the roles in the producer portlet. Local Roles displays the roles that are defined for the consumer's Access Manager.
In the User Categories to Role Mapping section, map user categories to the roles defined at the consumer
Click OK to save the details.
The producer does not have any real user identity and does not have any data associated with the user. The consumer propagates the common user details known as user profiles. The consumer chooses some of the common attributes such as name, address, and so on and optionally propagates these attributes to the producer. The producer can generate some meaningful data based on the user.
The Portal Server implementation of WSRP Consumer maps common user attributes stored in the user entry on the Sun Java System Directory Server to the standard set of user attributes that the WSRP specification mandates.
If a consumer portlet uses any of the attributes that are not specified in the LDAP schema, create a custom object class to store these attributes and add this object class to the user entry. After you create the attributes, map the LDAP attribute to the corresponding WSRP attribute using Sun Java System Access Manager administrator console. Mapping the LDAP attribute to the corresponding WSRP attribute allows the consumer to propagate custom user profile data that might be required by the producer.
Identity propagation is a mechanism by which the WSRP consumer supplies the identity of the user to the WSRP producer web service. Users federate their identity between the consumer and producer. After a successful federation, the consumer portal propagates the user identity to the producer portal. The WSRP producer, after receiving the user credentials from the consumer, validates the credentials and allows or denies access to the resource in the specified user context.
The user has two identities for each portal: one for producer portal and the other for the consumer portal. Users federate these identities using the identity propagation mechanism, which provides single-sign on for the consumer and the producer portal. When the user logs into the portal through the consumer portal, the user gets the content that the user gets when logs directly into the producer portal. The changes that the user makes using the federated identity would be available when the user logs into the producer portal.
The consumer can set the identity propagation because the consumer has knowledge about end users. There are two phases in setting up the identity propagation:
Administrator Setup: Administrator of the consumer portal discovers that the producer supports specific identity propagation mechanisms. Then, the administrator set up the system that allows the user to use identity propagation.
User Setup: The end user federates its identity by populating the credentials.
The WSRP Producer available through Portal Server supports the following identity propagation mechanisms:
SSO Token: Select if both the producer portal and the consumer portal are connected to the same Access Manager instance. Use when both the producer portal and consumer portal are deployed within the same organization. This option does not allow the end user to federate the identity because user identity from consumer and producer is accepted by the same Access Manager instance. This mechanism is not interoperable with other portal vendors.
WSS User Name Token Profile (Username only): Uses the WSS specification where the user name is propagated as WS Security headers from the consumer portal to the producer portal.
WSS User Name Token Profile (With password digest): WS Security headers send the user ID that is targeted at the producer with the password in the Digest form.
WSS User Name Token Profile (With password text): WS Security headers send the user's user ID that is targeted at the producer with the password in the Text form.
No Identity Propagation: This is the default behavior of WSRP as specified by the WSRP specification. This is the default option in Portal Server. A consumer created by default settings does not have identity propagation.
In the above list, WSS User Name Token Profile (Username only), WSS User Name Token Profile (With password digest), and WSS User Name Token Profile (With password text) implement the OASIS WSS Username token profile specification. This specification describes how to use the Username Token with web Services. The WSS specification describes how a web service consumer can supply a Username Token by identifying the requestor by username, and optionally using a password to authenticate that identity to the web service producer.
After the consumer is created, the administrator has to create remote channels based on the identity propagation mechanism supported by the consumer. After the channels are available on the user desktop, they are ready to accept identity propagation.
Log in to Portal Server.
In the WebServices SSO Portlet section, click Edit.
In the Create NewToken Profile section, select the WebService URL for which you want to create a user token profile.
Type the user name and password. Click Add to add the user name and password.
You can also edit or remove an existing user token profile.
The identity propagation mechanism is set at the producer automatically. Portal Server supports the following identity propagation mechanisms: Sun SSO Token, OASIS user name token (all its variants), and No identity propagation.
Only the newly created users, after running the configuration command to store the LDAP passwords in plain text, are able to use the Digest Password facility.
Creation of a consumer involves selecting the WSSO Username Token Profile (with Digest Password) option for User Identity Propagation Mechanism.
The Web Services SSO Portlet must be edited to select the appropriate Web service URL (producer) and the newly created username and password must be provided.
Run the following command to change the password storage scheme of the Directory Server so that plain text passwords are stored.
/opt/SUNWdsee/ds6/bin/dscfg set-server-prop pwd-storage-scheme:CLEAR
Create a new user in the Access Manager console to ensure that the Username Token Profile with Password Digest can be used.
When using the WSS User Name Token Profile (With password text), make sure that the communication between the producer portal and consumer portal is secure, because the password is sent in plain text between the consumer and the producer.
Do not have two different consumers that point to the same producer URL using different identity propagation mechanism types.
Do not switch to another identity propagation mechanism after a consumer has been created and is using an identity propagation mechanism, because the user's portlets preferences are stored based on the identification of the user, and switching to another identity propagation results in a loss of user customization.