Home

 

Define trusted and nontrusted Web sites for Profiles

Overview

The Ajax proxy configuration for all the IBM Lotus Connections features is defined in the proxy-config.tpl file. To specify different Ajax proxy settings for Profiles, create a proxy-profiles-config.tpl file that contains the customizations that you want.

To edit configuration files, use the IBM WebSphere Application Server wsadmin client. See Start the wsadmin client for details.

Lotus Connections uses a single proxy configuration file for all features by default. This file is initially deployed as a template file, proxy-config.tpl. When a Lotus Connections server is started, it reads information about the features from the LotusConnections-config.xml file, and, based on the rules defined in the proxy-config.tpl template file, creates a proxy-config.xml file that governs requests sent from other servers to Lotus Connections. When you want to secure the same URL for all the Lotus Connections features, you edit the settings in the template file.

By default, the Lotus Connections Ajax proxy is configured to allow cookies, headers, or mime.types, and all HTTP actions to be exchanged between the Lotus Connections features. However, it only allows HTTP GET requests from non-Lotus Connections services, and it prevents all cookies or headers from being directed to the features. To change the traffic that is allowed from other services, explicitly configure it.

To allow Profiles only to allow a specific Web site to pass cookies to Lotus Connections and you want the other Lotus Connections features to use the default settings, you can override the default settings for Profiles by creating a proxy-profiles-config.tpl file. At startup, Lotus Connections looks for customized template files and, when they are found, uses them to configure the proxy. When Lotus Connections is installed, the default policy in the proxy-config.tpl file looks as follows:

    <proxy:policy url="*" acf="none">
        <proxy:actions>
        <proxy:method>GET</proxy:method>
        <proxy:headers/>
        <proxy:cookies/>
    </proxy:policy>

This policy specifies that feeds and widgets from non-Lotus Connections servers can only exchange GET methods with Lotus Connections servers. The empty <proxy:cookies/> and <proxy:headers/> elements mean that cookies and headers are not allowed. When you want to allow a host to exchange cookies or headers, or to perform PUT, POST, or DELETE methods, you need to add a new policy that supports it.

Add a proxy policy for Profiles only

1. Navigate to the location on the Lotus Connections server where the configuration XML and TPL files are stored.

   For example:

   C:\IBM\WAS\profiles\AppSrv01\config\cells\cell_name\LotusConnections-config

2. Copy the existing proxy-config.tpl file to proxy-profiles-config.tpl.

3. Use the wsadmin client to access the Lotus Connections configuration files:

   • Stand-alone deployment:

     execfile("profilesAdmin.py")

   • Network deployment:

     execfile("WAS_HOME/profiles/Dmgr01/config/bin_lc_admin/profilesAdmin.py")

4. Check out the Lotus Connections proxy configuration file...

   ProfilesConfigService.checkOutProxyConfig("<working-directory>", "<cell-name>")

   where:

   • <working-directory> is the temporary working directory to which the configuration XML and TPL files are copied. The files are kept in this working while you make changes to them.

   • <cell-name> is the name of the WebSphere Application Server cell hosting the Lotus Connections feature. This argument is required even in stand-alone deployments. This argument is also case-sensitive, so type it with care.

5. Go to your temporary working and open the proxy-profiles-config.tpl file in a text editor.

6. Edit the file to specify a proxy policy for Profiles, making sure to insert the custom policy earlier in the code than the default policy. For example, you can do the following:

   • To explicitly refuse all traffic from a specific site, add a policy like this example:

     <proxy:policy url="www.malicious.example.com" acf="none">
         <proxy:actions/>
         <proxy:headers/>
         <proxy:cookies/>
     </proxy:policy>
     

   • To allow a particular service in your network to display a custom widget, you can add the following policy entry to the file.

     <proxy:policy url="http://www.example.com/widget/*" acf="none">
         <proxy:actions>
             <proxy:method>GET</proxy:method>
         </proxy:actions>
         <proxy:headers>
             <proxy:header>User-Agent</proxy:header>
             <proxy:header>Accept*</proxy:header>
             <proxy:header>Content*</proxy:header>
             <proxy:header>Authorization*</proxy:header>
         </proxy:headers>
         <proxy:cookies>
             <proxy:cookie>JSESSIONID</proxy:cookie>
         </proxy:cookies>
     </proxy:policy>
     

     This policy allows the HTTP GET method, passes JSESSIONID cookies, and the named headers, but it does not allow anything else.

   • To add the two LTPA cookies to the policy, add the following to the <proxy:cookies> section:

     <proxy:cookie>LtpaToken</proxy:cookie>
     <proxy:cookie>LtpaToken2</proxy:cookie>
     

     For example, the following policy allows a particular service to run on your network and pass cookies for LTPA tokens to the features:

     <proxy:policy url="http://www.example.com/service/*" acf="none">
         <proxy:actions>
             <proxy:method>GET</proxy:method>
         </proxy:actions>
         <proxy:headers>
           <proxy:header>User-Agent</proxy:header>
           <proxy:header>Accept*</proxy:header>
           <proxy:header>Content*</proxy:header>
           <proxy:header>Authorization*</proxy:header>
         </proxy:headers>
         <proxy:cookies>
           <proxy:cookie>JSESSIONID</proxy:cookie>
           <proxy:cookie>LtpaToken</proxy:cookie>
           <proxy:cookie>LtpaToken2</proxy:cookie>
         </proxy:cookies>
     </proxy:policy>
     

   Depending on your configuration, the <proxy:policy> section might require more or less detail. The following table lists some common cookies and headers that might be required under different configurations.

   Cookie/Header	Description
   SMSESSION	SiteMinder session cookie that passes SiteMinder credentials to IBM Lotus Quickr.
   PD-H-SESSION-ID	Nonsecure IBM Tivoli Access Manager session cookie that passes Tivoli Access Manager credentials to Lotus Quickr.
   PD-S-SESSION-ID	Secure Tivoli Access Manager session cookie that passes the secure version of the Tivoli Access Manager cookie to Lotus Quickr.
   WWW-AUTHENTICATE	SSL header that passes SSL authentication when connecting to a secure Lotus Quickr deployment.

7. Optional: Repeat the previous step for each URL that you want to make untrusted.

8. To check in the proxy-profiles-config.xml file...

   ProfilesConfigService.checkInProxyConfig(<working-directory>, <cell-name>)

9. To exit the wsadmin client, type

   exit

   at the prompt.

10. Stop and restart the Profiles server.

Administer Profiles

 

Related tasks

Apply property changes

Configure the AJAX proxy

---

+

Search Tips   |   Advanced Search