Home

Define trusted and nontrusted Web sites for Communities

 

+

Search Tips   |   Advanced Search

 

Overview

The Ajax proxy configuration for all the IBM Lotus Connections features is defined in the proxy-config.tpl template file. To specify different Ajax proxy settings for Communities only, create a Communities-specific version of this file.

If you have 4 different apps on a page, and each app has a different host or root context, you may run into problems where the site prevents the execution of content on a page from accessing each other. It is meant to prevent cross-site scripting.

Common work-around is to use an Ajax Proxy

Same Origin security policy in browsers blocks loading content from multiple orgins to the same page...

Danger here is that you can expose access to material that should not be exposed.

Solution: Use a proxy in the base application that loads the content from external sources and returns the data to the browser. The browser see all data coming from the same origin

Use proxy-config.tpl to secure...

Community members can add feeds to a community to keep informed with up-to-the minute information from a Web site without leaving the community. By default, community members can only add publicly available feeds to a community; authenticated feeds are not allowed.

Lotus Connections uses a single proxy configuration file for all features by default.

This file is initially deployed as a template file...

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 do so by editing settings in this file. However, if you want to allow Communities 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 Communities by creating a proxy-communities-config.tpl file that contains the customization that you want. At startup, Lotus Connections looks for customized template files and, if 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:

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 policy that supports it.


Add a proxy policy for Communities only

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

    For example:

      C:\IBM\WebSphere\AppServer\profiles\AppSrv01\config\cells\cell_name\LotusConnections-config

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

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

  4. Check out the proxy configuration file...

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

    where:

    • <working-directory> is the temporary working directory to which the configuration TPL and XSD files are copied. The files are kept in this working while you change 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-communities-config.tpl file in a text editor.

  6. Edit the file to specify a proxy policy for Communities, 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 the following: 

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

    • To pass all headers and all cookies to a trusted site, add a policy like the following example: 

        <proxy:policy url="http://example.internalserver.com/*" acf="none">
    <proxy:actions>
        <proxy:method>GET</proxy:method>
    </proxy:actions>
</proxy:policy>

      This policy allows GET operations to example.internalserver.com and forwards all cookies and headers.

    • 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://my.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 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://my.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 Non-secure 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. After making your changes, save and close the proxy-communities-config.tpl file.

  8. To check in the proxy-communities-config.tpl file...

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

  9. To exit the wsadmin client, type

    exit

    at the prompt.

  10. Stop and restart the Communities server.


Securing proxy access

 

Related tasks

Apply property changes

Configure the AJAX proxy