Secure WSRP by SSL for a Producer portal

Secure WSRP by SSL for a Producer portal

As a Producer, you can ensure security for the WSRP services that you provide by configuring Producer portal for Secure Socket Layer (SSL) with Client Certificate Authentication.
J2EE allows only for one authentication mechanism per WAR file. To allow you to use SSL for WSRP and continue using other means of authentication for the rest of the portal, WSRP introduces a second WAR file for the Producer portal. This second WAR file is named wps_facade.war . It contains servlets that work as a facade interface web application that channels the WSRP requests to the Producer's access points.
This allows you to simultaneously use both SSL client certificate authentication for the WSRP Producer portal and other method of authentication for the rest of the portal, for example form based authentication. You set this up as follows:

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

Configure SSL client certificate authentication for the web.xml file 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. You can configure this context root as required in the following ways:

Modify the property uri.context.path.facade to a different value in the portal Config Service in the administrative console. For details about how to change portal service configuration parameters refer to the topic about setting configuration properties.

Use the modify-servlet-path configuration task to automatically change the context path for the WSRP context root, as described in Change the portal URI.

Security notice: Do not use portlets that use the Credential Vault over WSRP in conjunction with SSL client certificate authentication. If you configure SSL client certificate authentication for WSRP services, the Consumer portal uses a proxy user ID to authenticate on behalf of its individual users. You configure the proxy user ID by consumer-side SSL client certificate. This means that the WSRP Consumer provides the individual personalization information to the WSRP Producer, but authenticates for all users by using the same identity information. Consequently, if a portlet on the Producer portal uses 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. Therefore, do not use portlets that use the Credential Vault over WSRP in conjunction with SSL client certificate authentication.
To configure the portal for securing WSRP services by Secure Socket Layer...
Configure WAS for SSL support.

For the latest information about configuring WAS for LDAP over SSL refer to http://www.redbooks.ibm.com/ and search for security handbook.
Proceed as follows:

Enable security.

Enable SSL ID tracking. To do this, perform the appropriate steps, access the administrative console and click Servers -> Server Types -> WebSphere application servers -> WebSphere_Portal -> Web Container Settings -> Web Container -> Session Management, then enable SSL ID tracking.

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 (DN) from the subject field of the certificate to a corresponding Distinguished Name in 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 Distinguished Name in 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 Distinguished Name to identify the users. For example, the filter uid=${SubjectCN} maps the SubjectCN field of the client certificate to the uid attribute in LDAP.

Define a new virtual host alias. Click Environment -> Virtual Hosts -> default_host -> Host Aliases -> New, and define SSL communication port. You can use an asterisk ( * ) as a wild card for the hostname.

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

Regenerate the plug-in. To do this, click Servers -> Server Types -> Web Servers.

Select the web server and click Generate Plug-in.

Update the HTTP server with the generated plug-in.

Create the server certificates in the keystore of HTTP server.

Export the server certificates from the HTTP server.
You will later give that information to the WSRP Consumer.

Restart the HTTP server for the changes to take effect.

Enable client certificate authentication in web server. For IBM HTTP Server (IHS), refer to http://www.redbooks.ibm.com/ and search for security handbook for the latest information about WAS.
Add new tags to the web.xml file. Proceed by the following steps:
Export the portal EAR file wps.ear according to network configuration. If you have a cluster environment, export the file from the WAS Network Deployment machine.
Proceed as follows:

From a command line cd was_profile_root/bin .

Export the file wps.ear to a temporary directory by using the command wsadmin . - Invoke the command as follows:

UNIX™: ./wsadmin.sh -user admin_user_id -password foo -c '$AdminApp export wps temp_directory/wps.ear'

i: wsadmin -profileName profile_root -user admin_user_id -password foo -c '$AdminApp export wps temp_directory/wps.ear'

Where:

For i: profile_root is the name of the WAS profile directory where the portal is installed; for example wp_profile.

admin_user_id is the WAS administrator user ID.

foo is the WAS administrator password.

temp_directory is the temporary directory to which you export the portal EAR file.

Create a subdirectory wps_expanded .

Expand the contents of the exported EAR file. To do this, use the tool EARExpander. It is located at was_profile_root/bin . - Invoke the command as follows:

UNIX: ./EARExpander.sh -ear directory/wps.ear -operationDir directory/wps_expanded -operation expand

i: EARExpander.sh -ear directory/wps.ear -operationDir directory/wps_expanded -operation expand

Edit the file web.xml . It is located at the directory wps_expanded/wps.ear/wps.war/WEB-INF .
Add a new login-config tag for the client certificate authentication method with a new unique ID.
For example, this can be as follows:
<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 WSRPBaseService, WSRPServiceDescriptionService, and WSRPPortletManagementService URL patterns.
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 changes.

Redeploy the portal EAR file wps.ear .
Proceed as follows:

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

Collapse the EAR directory back into an EAR file. To do this, use the following EARExpander command: - Invoke the command as follows:

UNIX: ./EARExpander.sh -ear directory/wps.ear -operationDir directory/wps_expanded -operation collapse

i: EARExpander.sh -ear directory/wps.ear -operationDir directory/wps_expanded -operation collapse

Update the portal EAR file by using the command wsadmin .
If you have a managed cell, with or without a cluster, perform this step on the dmgr machine.

- Invoke the command as follows:

UNIX: ./wsadmin.sh -user admin_user_id -password foo -c '$AdminApp install directory/wps.ear {-update -appname wps -nodeployejb}'

i: wsadmin -profileName profile_root -user admin_user_id -password foo -c '$AdminApp install directory/wps.ear {-update -appname wps -nodeployejb}'

Where:

For i: profile_root is the name of the WAS profile directory where the portal is installed; for example wp_profile.

admin_user_id is the WAS administrator user ID.

foo is the WAS administrator password.

temp_directory is the temporary directory from where you import the updated the portal EAR file.
Update the affected parameters as required:

To enable Portal Access Control for the Producer portal, set the following property to true in the portal Config Service in the administrative console: wsrp.security.enabled = true .
For details about how to do this refer to the topic about setting configuration properties.

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. For details about how you can change these URLs refer to the topic about setting the WSRP SOAP ports.

Restart the portal for the changes to take effect.
Parent
Prepare security for a WSRP Producer portal

Related tasks

Change the portal URI

http://www.redbooks.ibm.com/

+
Search Tips | Advanced Search