Java Solaris Communities About Sun How to Buy My Sun Connection Cart United States Worldwide

BigAdmin System Administration Portal
Feature Article
Print-friendly VersionPrint-friendly Version

Administering Web Services for Remote Portlets for Sun Java System Portal Server 7.1

Sunil Bhaskaran, July 2007

This article provides information on administering Web Services for Remote Portlets (WSRP) in Sun Java System Portal Server 7.1 (Portal Server). It is assumed that the readers have basic knowledge about the producer and consumer concept in WSRP. The article describes how to use WSRP and the guidelines and best practices for using WSRP.

Contents


Overview of WSRP

WSRP is a standard that provides web service-based access capability to portlets and provides interoperability among different portal server solutions. WSRP is a presentation-oriented web service. Unlike common web services that carry only the raw data as the result of a request, a WSRP response carries fully rendered markup to be included within a portal page.

See see the oasis-open.org web site for the WSRP v.1 OASIS 200304 standard, FAQs, and white papers.

WSRP has two key elements: producer and consumer.

  • Producer

    A presentation-oriented web service that hosts portlets that are able to render markup fragments and process user interaction. A producer offers one or more portlets and implements various WSRP interfaces and operations. Depending on the implementation, a producer might offer one portlet or might provide a runtime environment (or a container) for deploying and managing several portlets.

  • Consumer

    A web service client, typically a portal, that invokes the producer to provide an environment for users to interact with portlets offered by one or more producers.


Administering WSRP Producers for Portal Server

Create a producer if you want to offer locally deployed portlets remotely to other portals that act as WSRP consumers. A portal can host multiple producers and each producer can export multiple remote portlets. A producer is a grouping mechanism that exports any number of portlets. The consumer can consume remote portlets offered by a producer. Based on the portlets that you want to provide to WSRP consumers, you can create one or more producers.

A producer might require consumers to register with it. Registration is a process in which the consumer and the producer enter into a relationship that enables the producer to identify the consumer. A producer either supports registration or it does not support registration. If a producer supports registration, consumers must register to work with the producer. If a producer does not support registration, it is referred to as a registration-less producer and does not require registration.

This section contains the following tasks that need to be performed at the Portal Server producer to offer locally deployed portlets to a consumer:

Task
Description
Instruction
1. Create a producer that supports registration if you want the consumer to customize the remote portlets. Select the registration mechanism (in-band registration or out-of-band registration) based on the communication that you want to have with the consumer.
If the producer requires registration and enabled in-band registration: The consumer can provide the details required by the producer through the WSRP interface and register with the producer. The registration happens during the consumer creation. The consumer provides the attributes requested by the producer and submits the attributes. This communication is called in-band communication, because the communication happens through the WSRP protocol. The consumer is also provided an option to register through out-of-band communication. The administrator of the consumer contacts the administrator of the producer and obtains a registration handle. A registration handle is a string representation of the consumer-producer relationship. This communication is called out-of-band communication because the communication is not through the WSRP protocol.

If the producer requires registration and enabled out-of-band registration: Out-of-band registration happens with manual intervention such as phone calls, emails, and so on. For a producer that supports out-of-band registration, the producer gets the details about the consumer through out-of-band communication, and the producer creates a registration handle for the consumer that the consumer uses for further communication with the producer. The registration handle is communicated to the consumer through out-of-band communication. For more information on creating a registration handle, see To Generate a Registration Handle.

To Create a Producer That Supports Registration
2. Create a producer that does not support registration if you do not want the consumer to customize the remote portlets.
For a producer that does not support registration, a consumer is not required to enter any information or get any information through out-of-band communication. The consumer can not customize or edit the portlets offered by the producer. The producer that does not support registration provides read-only portlets to the consumers.
To Create a Producer That Does Not Support Registration
3. Publish locally deployed portlets to the producer and enable the producer so that the consumer can access the locally deployed portlets as remote portlets.
A newly created producer by default is disabled because it does not export any local portlet as a remote portlet. It should be enabled for a consumer to register. A producer must be enabled by exporting one or more portlets as a remote portlet.

A producer can be disabled at any point. All of the consumers registered with the disabled producer will not be able to access the portlets offered by the producer.
To Publish Portlets and Enable a Producer
4. (Optional) Generate a registration handle if the newly created producer supports only out-of-band communication for registration.
A registration handle is a unique representation of the consumer-producer relationship that is formed during the registration process.

  • If a producer supports only out-of-band registration, you must generate a registration handle.

  • If a producer supports in-band registration, you are not required to generate a registration handle.

For a producer that supports out-of-band registration, the registration handle must be generated for a specific consumer. After you generate the registration handle, it needs to be communicated to the consumer through out-of-band communications, such as emails and phone calls. The consumer needs to enter the registration handle while registering with the producer. For more information on how to register with a producer using the registration handle, see To Add a Configured Producer.
To Generate a Registration Handle
5. (Optional) Publish the details of the newly created producer if you want to make the producer discoverable through a search by the consumer.
Publishing a producer stores producer details in a repository, such as Service Registry (available with Sun Java Enterprise System) or ebXML Registry Server, and allows a consumer to search for producer details. Producer details include information such as the producer name, portlets, Web Services Definition Language (WSDL) URL, and the organization using the application interface or the command-line interface. Publishing a producer enables consumers to be aware of the producers that offer remote portlets.
To Configure Portal Server to Use Service Registry
6. (Optional) Configure Portal Server to use Service Registry if the Service Registry is deployed on a different network.
If Portal Server and Service Registry are on different networks in your deployment, you must configure Portal Server to use Service Registry to publish producer details. For details on setting up Service Registry Server, refer to the Service Registry 3.1 Administration Guide.
To Configure Portal Server to Use Service Registry
7. (Optional) Search for a producer's details using the command-line interface.
After a producer's details are published, a consumer can search for the details of the producer using the application interface or using the command-line interface.

Searching for producer details allows the consumer to discover the WSDL URL of a producer based on the organization, description, or portlets.
To Search for Producer Details

To Navigate to the WSRP Producer Options in the Portal Server Administration Console

1. Log in to the Portal Server administration console.

2. In the Portal Server administration console, click the Portal tab.

The screen displays available portals.

3. Click the portal name hyperlink.

4. Click the WSRP tab.

5. Click Producer tab.

To Create a Producer That Supports Registration

1. If you are not on the Producer tab, see To Navigate to the WSRP Producer Options in the Portal Server Administration Console.

2. Select the organization's distinguished name (DN) where you want to create a producer and click the Producer tab.

Each organization can offer any number of WSRP producers. The WSRP Producers table displays all producers that already exist. Select the DN (Distinguished Name)of an organization or sub-organization based on the availability of portlets.

Note - Organizations are created in Sun Java System Identity Server.

3. Click New to create a new producer.

4. Type a name to identify the producer.

The name of the producer should be unique and should contain valid characters. The producer name is used to create the WSDL URL of this producer.

5. Select Required for Registration to create a producer that supports registration.

If a producer does not support registration, it cannot identify the consumer because the producer does not build a relationship with the consumer. Hence the consumer can not customize the portlets that are offered by the producer. Select Support Registration if you want the producer to support customization of portlets.

6. Select Supported for Inband Registration if you want the consumer to enter the details using the Portal Server application interface.

7. To add a registration property, click Add Row. Enter the values. Enter the name of the registration property and description.

Registration properties are the details that you want to get from the consumer when the consumer registers to a specific producer. The registration properties entered by the consumer can be validated through the Registration Validation class.

8. Select Supported for out-of-band Registration if you want the consumer to provide the details through out-of-band communication, such as phone calls, emails, and so on.

9. Click Next.

The Review screen displays the details that you entered. Review the details. You can click Previous and change the details you entered.

10. Click Finish to create the producer.

To Create a Producer That Does Not Support Registration

1. If you are not on the Producer tab, see To Navigate to the WSRP Producer Options in the Portal Server Administration Console.

2. Select DN.

The WSRP Producers table displays all producers that are already configured.

3. Click New to create a new producer.

4. Type a name to identify the producer.

The name of the producer should be unique and should contain valid characters. The producer name is used to create the WSDL URL of this producer.

5. Select Registration Not Required.

6. Click Finish.

To Publish Portlets and Enable a Producer

1. If you are not on the Producer tab, see To Navigate to the WSRP Producer Options in the Portal Server Administration Console.

2. In the Producer tab, click the producer name hyperlink.

The Edit Properties screen appears. The screen displays the WSDL URL, which is a unique URL for a specific producer through which the consumer accesses the producer.

3. Add one or more published portlets to the producer.

The Unpublished Portlet list displays a list of local portlets that are available in the system and can be exported as remote portlets.

Note - The producer must have at least one published portlet to enable it.

4. Select a portlet, and click Add to add the portlets to the producer.

5. Edit the Registration Validation Class field if you want to validate the registration properties.

The RegistrationValidator class is used to validate the registration properties that are entered by the consumer.

You can customize the RegistrationValidator class. Using this class, you can process the registration properties, for example, verifying the zip code of the consumer. RegistrationValidator is the SPI for registration validation in the WSRP producer. For more information on customizing the validation class, see http://server/portal/javadocs/desktop. You can also refer to Chapter 14, "WSRP: Validating Registration Data," in the Sun Java System Portal Server 7 Developers Guide.

6. Click Save to save the changes and edit the Enable check box.

7. Select Enable to enable the producer and click Save.

To Generate a Registration Handle

1. If you are not on the Producer tab, see To Navigate to the WSRP Producer Options in the Portal Server Administration Console.

2. Click the producer name for which you want to create a registration handle.

3. Click the Consumer Registration tab.

The screen displays all consumers that are registered to the specific producer.

4. Click New to create a new registration handle.

5. Type details, such as name, status, consumer agent, and method.

  • Consumer name: A unique name to identify the consumer.

  • Status: A consumer can be Enabled or Disabled. A consumer can access the remote portlets offered by the producer only if the status is enabled.

  • Consumer Agent: Specifies the name and version of the consumer's vendor. Type the Consumer Agent Name in the form ProductName.MajorVersion.MinorVersion, where ProductName identifies the product the consumer installed for its deployment, and MajorVersion and MinorVersion are vendor-defined versions of the vendor's product. This string can contain any additional characters and words the product or consumer wants to supply.

  • Method: Specifies whether the consumer has implemented portlet URLs in a manner that supports HTML markup containing forms with the get method.

6. Click Next.

The screen displays the registration property values that you specified while creating the producer. Review the details and change the details if required.

7. Click Finish to create a registration handle.

To Publish Producer Details to the Service Registry

1. Create an organization data file and a producer data file that include the organization and producer details to publish to the service registry.

The organization data file can contain the following entries:

org.name=organization-name

org.description=organization-description

org.primarycontact.name=contact-name

org.primarycontact.phoneno=telephone-number

org.primarycontact.email=email-address

Note - The org.name and org.description entries must be the same as the entries used in Identity Server unless the Service Registry is deployed internally.

The producer data file should have the following entries:

producer.name=producer-name

producer.description=producer-description

producer.id=producer-ID

Note - To be able to search for the details of producer, organization, or portlet, you must create at least one data file associated with.

2. Stop and restart the common agent container using the following commands:

/opt/SUNWcacao/bin/cacaoadm stop

/opt/SUNWcacao/bin/cacaoadm start

3. To publish the producer details to the Service Registry, use the following command:

../psadmin publish-registry -u amadmin -f password-file
-p portal1 -m producer -U producer-data-filename
-O organization-data-filename -T portlet-file
-L --debug

Note - The portlet-file file specifies the portlets that are offered by the WSRP producer. Type the portlets list as a string within double quotes with the elements separated by a space, for example, "NotepadPortlet BookmarkPortlet WeatherPortlet".

You can check the log file by using the following command: 

more var/opt/SUNWportal/logs/admin/portal.admin.cli.0.0.log

Note - For more information on the psadmin publish-registry commands, refer to psadmin publish-registry in the Sun Java System Portal Server 7 Command-Line Reference.

To Configure Portal Server to Use Service Registry

1. On the machine where Portal Server is installed, create the directory, /soar/3.0/jaxr-ebxml/security.

2. Copy keystore.jks from Registry Server's /var/opt/SUNWsrvc-registry/3.0/data/security directory to the /soar/3.0/jaxr-ebxml/security directory.

3. In the Sun Java System Portal Server Portal Server administration console, click the Portal tab. Click the SSO Adapter tab.

4. Click JES-REGISTRY-SERVER.

The Edit Meta-adapter - JES-REGISTRY-SERVER screen appears.

5. Type the following details.

If you are accessing Service Registry through a proxy server, type the following details:

  • http.proxy.host: The host name of the proxy server.

  • http.proxy.password: The proxy password if proxy server required authentication.

  • http.proxy.port: The port on which proxy server is available.

  • http.proxy.user: The proxy user name if proxy server required authentication.

If you do not use a proxy server, type the following information:

  • registry.keypassword: The password that is required to get the key from the keystore.

  • registry.keystorealias: The key alias that is present in the keystore that is to be used for authenticating with the registry server.

  • registry.keystorelocation: The location of the keystore relative to the /soar/3.0/jaxr-ebxml directory.

  • registry.keystorepassword: The password used to open the keystore.

  • registry.publishurl: The URL of the registry server where the publish request should be sent and should accept SOAP requests.

  • registry.queryurl: The URL of the registry server where the search request should be sent and should accept SOAP requests.

6. In Access Manager, add SSO Adapter Service to the Access Manager administrator.

To Search for Producer Details

1. Create a search producer data file that contains the details that you want to search.

The search producer data file can contain any of the following:

producer.name=producer-name

producer.description=producer-description

Note - The search producer data file contains a description of the producer in the registry. Use the percentage sign (%) for a wildcard search. For example, use %acme% in producer-name searches for a WSRP producer that contains the string "acme" in its name.

2. To search for a producer in the registry, use the following command:

../psadmin search-registry -m consumer -u amadmin
-f ps-password -C search-producer-datafile -p portal1

Administering WSRP Consumers for Portal Server

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:

  • By entering the registration property values (in-band registration)

  • By entering the registration handle (out-of-band registration)

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 enable an Identity Propagation Mechanism if you want to federate the consumer identity from the consumer portal to the producer portal.
To Add a Configured Producer
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.
To Create User Credentials Using WebServices SSO Portlet
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 through a gateway if the producer is outside the network where a consumer portal is deployed.
You must configure proxies if Portal Server is used as a 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, the web container needs to have the same proxy settings in its configuration.
To Access a Producer Through a Gateway
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.
To Update the Service Description
6. (Optional) Export roles as user categories in the 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 to 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 Manager of the producer.
To Export Roles as User Categories in 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 to 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 attributes to the corresponding WSRP attributes using the Sun Java System Access Manager administrator console. For more information, see Mapping Consumer Attributes.
To Map User Categories to a Role

To Navigate to the WSRP Consumer Options in the Portal Server Administration Console

1. Log in to the Portal Server administration console.

2. Click the portal name hyperlink.

3. Click the WSRP tab.

To Add a Configured Producer

1. If you are not on the Producer tab, see To Navigate to the WSRP Consumer Options in the Portal Server Administration Console.

2. Select DN. Click New to create a new configured producer.

3. 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 to federate their identity from the consumer portal to the producer portal. For more details on identity propagation mechanism, see Identity Propagation Mechanism.

4. Type the WSDL URL and click Next.

Note - 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 the 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 Producer Details.

5. (Optional) If the producer requires registration, you can register the producer using either of two methods:

  • Enter the registration property values (in-band registration)

  • Enter the registration handle (out-of-band registration)

6. Click Next.

7. If you selected the first method in Step 5, 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.

8. Review the details and click Finish.

To Create Channels to Display Remote Portlets on the Portal Desktop

1. Log in to the Portal Server administration console.

2. Click the portal name hyperlink.

3. Select the DN on which you want to create a remote portlet.

4. Click Manage Channels and Containers.

5. Select the container to which you want the remote portlet to appear.

6. Click New Channel or Container on the right tab.

A wizard appears.

7. Select portal, DN, and Channel.

8. Click Next and select WSRP Remote Portlet Channel.

9. Click Next.

The screen displays the list of available configured producers.

10. Select the configured producer and click Next.

The Remote Portlet list displays the list of remote portlets that the producer offers.

11. Select the remote portlet and click Next.

12. Provide a local channel name for the remote portlet.

13. Click Finish to create a remote portlet on your portal desktop.

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

To Access a Producer Through a Gateway

1. In a text editor, edit the following file:

/var/opt/SUNWappserver/domains/domain1/config/domain.xml

2. Set the following Java Virtual Machine (JVM) options: Dhttp.proxyHost, Dhttp.proxyPort, Dhttp.proxyUser, and Dhttp.proxyPassword.

3. Save the file.

To Update the Service Description

1. If you are not on the Consumer tab, see To Navigate to the WSRP Consumer Options in the Portal Server Administration Console.

2. Select DN (Distinguished Name).

3. Click the configured producer hyperlink.

4. In the Edit Configured Producer screen, click Update Service Description.

5. Check the local repository/cache for the new portlets offered by this producer.

6. Create a new channel to see if any new portlets are offered by the producer.

To Export Roles as User Categories in Producer

1. In the Access Manager administrator console, create a role and add a user.

2. While deploying the portlet in webxml of the portlet application, add the following code:

security-role>
role-name>PS_TEST_DEVELOPER_ROLErole-name>
/security-role>

3. Add the following lines in the portlet.xml file of the portal.

security-role-ref>
role-name>PS_TEST_DEVELOPER_ROLErole-name>

role-link>PS_TEST_DEVELOPER_ROLErole-link>
/security-role-ref>

4. Create the portlet application WAR file.

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

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

To Map User Categories to a Role

1. If you are not on the Consumer tab, see To Navigate to the WSRP Consumer Options in the Portal Server Administration Console.

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

3. In the User Categories to Role Mapping section, map user categories to the roles defined at the consumer.

4. Click OK to save the details.

Mapping Consumer Attributes

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 the 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 Mechanism

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 the 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 directly logged in to the producer portal. The changes that the user makes using the federated identity would be available when the user logs in to the producer portal.

Identity Propagation Mechanism at the Consumer of Portal Server

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: The administrator of the consumer portal discovers that the producer supports specific identity propagation mechanisms. Then, the administrator sets 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 previous 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 user name token with web services. The WSS specification describes how a web service consumer can supply a user name token by identifying the requestor by user name, 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.

To Create User Credentials Using WebServices SSO Portlet

1. Log in to Portal Server.

2. In the WebServices SSO Portlet section, click Edit.

3. In the Create NewToken Profile section, select the WebService URL for which you want to create a user token profile.

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

Identity Propagation at Producer

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.

Configuring the Sun Java System WSRP Producer to Accept Digest Passwords

  • 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 user name and password must be provided.

To Configure the Sun Java System WSRP Producer to Accept Digest Passwords

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

2. Create a new user in the Access Manager console to ensure that the Username Token Profile with Password Digest can be used.

Best Practices for Using Identity Propagation Mechanism

  • 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. Switching to another identity propagation results in a loss of user customization.


Accessing Sun Resources Online

The docs.sun.com web site enables you to access Sun technical documentation online. You can browse the docs.sun.com archive or search for a specific book title or subject. Books are available as online files in PDF and HTML formats. Both formats are readable by assistive technologies for users with disabilities.

Sun Welcomes Your Comments

Sun is interested in improving its documentation and welcomes your comments and suggestions. For documentation feedback, use this form.


For More Information

For more resources, see the Sun Java Enterprise System hub on the BigAdmin portal for systems administrators: http://www.sun.com/bigadmin/hubs/javaes/.

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.


Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments:
Your email address (no reply is possible without an address):
Sun Privacy Policy

Note: We are not able to respond to all submitted comments.
 BigAdmin
  
»  Search the HCL
 
BigAdmin Subscriptions
»   BigAdmin Newsletter
»   BigAdmin Blog
»   BigAdmin Wiki
»   RSS Feeds
BigAdmin Areas
»   All Topics/Sections
»   Articles and FAQs
»   Blogs and Wikis
»   Discussions
»   Documentation
»   Features
»   HCL
»   Multilingual
»   Patches
»   Products and Tech
»   Resources
»   Scripts
»   Software/Tools
»   Solaris 10 Apps
»   ShellCmds
»   Submit Content
»   Suggestions
»   SysAdmin Jobs
»   SysAdmin Topics
»   Tech Tips
BigAdmin Sun Center
»   Register Your System
»   Solaris Developer Center
»   Sun Support
»  Sun Doc Highlights
»  Sun Tech Days
»   Sun Advisory Panel for System Admins
»   Training and Certification
BigAdmin Topics
»   DST
»   DTrace
»   Interoperability
»   Networking
»   Predictive Self-Healing
»   ZFS
»  Zones
 
 
Would you recommend this Sun site to a friend or colleague?
Contact About Sun News & Events Employment Site Map Privacy Terms of Use Trademarks Copyright Sun Microsystems, Inc.