Security knowledge transfer for Lotus Connections 2.5 (Part 1) 

This document responds to several specific questions about handling security in Connections 2.5 and how it differs from Connections 2.0.1. This is part 1 of 2 .

The Active Content Filter

Connections has included some version of the Active Content Filter (ACF) for several releases. The ACF was developed by the IBM Tokyo Research Laboratory. It is used to render malicious script harmless, or to eliminate it entirely in some instances. Connections 2.5 uses the ACF on its rich text editors and input boxes to help prevent cross site scripting attacks.

The ACF version 2.2 adds the ability to filter malicious parameters from embedded flash animations. In Connections 2.5, users may add embedded flash videos to blog entries and wikis. The ACF displays the video in an <iframe

 

to isolate the video from the page DOM (Document Object Model), which helps prevent a malicious user from gaining access to data on the page. The ACF also strips off any malicious parameters, such as javascript, from the video object definition.



The ACF is enabled by default. If you wish to disable it, you must disable it for each component in Connections. For example:

CommunitiesConfigService.updateConfig("activeContentFilter.enabled", "false")

Details on how to modify the component configuration files are available in the Lotus Connections Information Center under Administering

 

Administering features

 

Editing configuration files.

In addition to the ACF, Connections 2.5 uses a Java utility to normalize URLs to prevent URL-based XSS attacks and directory navigation attacks.

Security Roles

The security roles are J2EE aliases defined in WebSphere Application Server. They allow applications to define authorization levels for the product - each role governs a certain authorization level. WebSphere Application Server supports assigning individual user names and groups to the various role names, although there are some known problems that occur in Connections 2.5 when this capability is used for some roles.

This screenshot shows the roles defined for the Blogs application as displayed in the WebSphere Application Server admin console.

Role names and definitions

• everyone
  Can access public pages only (for example, the login page) - This role should not be modified from the default.
• reader
  Has read-only access to Connections (default setting is "Everyone"). Setting this to "All authenticated" forces login for all aspects of the product,
• person
  Has read/write access to Connections (default setting is "All authenticated").
• search-admin
  Used by Search to create search indexes from public and private information.
• widget-admin
  Used by widget containers to send events alerting widget applications of container changes.
• files-owner
  Has all the privileges of someone in the person role, but can also upload files.
• dsx-admin
  Used by the directory services extensions to access Profiles and Communities user information.

Not all roles are used by all Connections components. For example, only Files and Wikis use the files-owner role. The admin role is listed on the Activities roles page in the WebSphere Application Server admin console, but Activities does not make use of this role in Connections 2.5.

The search-admin and widget-admin roles are set by the installer to include the WebSphere Application Server administrative user. All other roles do not initially have associated users or groups.

The admin role for Blogs must be set to a valid user name. You must log in as this user to set the frontpage blog.

Known Issues

• Users exclusively in the reader role cannot always log in.
  Homepage and Activities do not support read-only users. For most other components, after you authenticate via Profiles, you can use the component in a read-only capacity. For example, log in to Profiles and then click on the Communities tab as a user in the reader role.
• If you are in the reader role, but the component grants you higher authorization, the behavior of the product is undefined.
  For example, if a user is in the reader role but an Activities owner has granted that user edit rights, the behavior of the component is undefined.
• Users in the reader role can open and enter data in the "Start a Wiki" dialog, but nothing happens when the user clicks the "create wiki" button in the dialog.
  No error message is presented, and the dialog box does not close.

More detail about the security roles and their use in each of the components is available in the Lotus Connections Information Center under Administering

 

Administering all Lotus Connections features

 

Roles.

Admin support for security

Most Lotus Connections configurations can be modified via the wsadmin command line tool. Details for using this are available in the Lotus Connections Information Center under Administering

 

Administering features.

Note that there is no wsadmin support for modifying antivirus support settings. These must be manually modified in the LotusConnections-config.xml file. Details about these settings can be found in the information center under Security

 

Enabling virus scanning.

Disabling Flash support in Blogs and Wikis

Connections 2.5 adds the ability to embed Flash animations in Blogs and Wikis. This support is enabled by default. Some customers might want to disable this support, either permanently or until an updated version of the Flash player has been installed.

The command to disable Flash support is as follows:

LCConfigService.updateConfig("allowedContent.contentType.enabled", "false")

At the moment, since Flash is the only video format supported by Lotus Connections, there is no reference to the format in this command. In a future release, when other video formats are supported, this command will be changed to reference the video format being enabled or disabled.

Changing the DSX-admin alias

When you change the dsx-admin alias, there are two configuration items in the LotusConnections-config.xml file that you must change to match. These are:
LCConfigService.updateConfig("communities.directory.service.extension.auth.alias", "<alias_you_created"

 

)
and
LCConfigService.updateConfig("profiles.directory.service.extension.auth.alias", "<alias_you_created"

 

)

Note that if you set the reader role to "All authenticated", you must also set the following:
LCConfigService.updateConfig("profiles.directory.service.extension.auth", "DSX-Admin")

This setting is "None" by default. The communities.directory.service.extension.auth is set by the installer to DSX-Admin.

New SSO configuration

Connections 2.5 adds support for SPNEGO, allowing users to perform single sign-on via the Windows® desktop. Details are in the information center under Security

 

Configuring single sign-on

 

Enabling single sign-on for the Windows desktop.

The other SSO environments that continue to be supported by Connections 2.5 are Tivoli Access Manager and Siteminder.

Antivirus Support

Lotus Connections 2.5 does not provide internal antivirus scanning. You must have an ICAP-capable virus scanning engine installed and configured to work with Connections. Connections 2.5 supports Symantec AntiVirus Scan Engine 5.1 and McAfee Web Security Appliance (3400) and (3300).

As noted above, there is no wsadmin command line support for modifying the antivirus configuration settings. Use the wsadmin tool to check out the LotusConnections-config.xml file and then use a text editor to make changes.

The initial settings in the LotusConnections-config.xml file look like this:

 



<!-- 

To enable virus scanning, first delete the empty avFilter element below. 

Then, uncomment the avFilter in the comment and replace hostname as appropriate 

Replace myScannerService with the appropriate name for your scanner (eg 

AVSCAN for Symantec, RESPMOD for McAfee) 

--
  

<avFilter
  

</avFilter
  

<!-- <avFilter class="AVScannerICAP"
  

<property
 av.scanner.servers=myscanner.host.com</property
  

<property
 exception.on.virus=yes</property
  

<property
 av.scanner.service=myScannerService</property
  

</avFilter
  

--
  

The empty <avFilter

 

element is present to assist migration from 2.0 to 2.5. It must be removed and the subsequent section uncommented. Replace myscanner.host.com with the name of your antivirus scanner host. Replace myScannerService with AVSCAN if you are using a Symantec scanner or RESPMOD if you are using McAfee.

Optional antivirus configuration settings to support scanning large files are as follows:

<property

 

av.chunk.size=50000</property

 

the number of bytes sent to the scanner at a time
<property

 

first.read.timeout=120000</property

 

the number of milliseconds to wait for a response from the scanner

Phishing prevention

By default, certain elements of the API use e-mail addresses for user identification. In an extranet deployment, these e-mail addresses could be harvested by spammers.

To hide email addresses, start the wsadmin command line tool and issue the following commands:

LCConfigService.updateConfig("email.expose.enabled","false")
LCConfigService.updateConfig("profiles.directory.service.extension.auth", "dsx-admin")

Ajax proxy configuration

Lotus Connections 2.0 had three proxy configuration files: proxy-config.xml, proxy-homepage-config.xml and proxy-profiles-config.xml. In Connections 2.5, all components share a single file with the exception of Search, which uses its own configuration file.

The Ajax proxy configuration is now stored in the proxy-config.tpl file. Search uses proxy-search-config.tpl and does not include the default policy, so any URL not explicitly specified in the Search proxy config will not be accessible via the Search proxy. If you want to customize the configuration for one of the other components, create a file called proxy-componentname-config.tpl, eg proxy-homepage-config.tpl. The exception to this rule is Bookmarks, which would be customized in a file called proxy-dogear-config.tpl.

Sample proxy policy template

The proxy-config.tpl file is a template. The variables in the template file are replaced at system start-up with values from the LotusConnections-config.xml file. For example, the following is the template for the Activities component. The activities setting is the template variable indicating this policy applies to the Activities component.

 



<proxy:policy url="{activities}/*" acf="none" basic-auth-support="true"
  

<proxy:actions
  

<proxy:method
 GET</proxy:method
  

<proxy:method
 POST</proxy:method
  

<proxy:method
 PUT</proxy:method
  

<proxy:method
 DELETE</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:header
 If-.*</proxy:header
  

<proxy:header
 Pragma</proxy:header
  

<proxy:header
 Cache-Control</proxy:header
  

</proxy:headers
      

</proxy:policy
  

On start-up, Connections examines the LotusConnections-config.xml for the href and ssl_href values defined for the component - in this case, activities. If either is enabled, a policy for that URL is written out. If one is not enabled, that policy is not created. There can be a maximum of two policies for each component - one for http and one for https. This policy passes all the HTTP methods available, any cookies sent with the request, and the headers defined in the <proxy:headers

 

section. Some of the components include different headers, depending on what testing has shown to be necessary for their proper behavior.

Default policy

The default policy in the template file is used to process any URL received that has not been defined earlier in the configuration and should always be the final policy in the file. This policy permits only the GET method, and passes no headers or cookies from the request.

<proxy:policy url="*" acf="none"
  

<proxy:actions
  

<proxy:method
 GET</proxy:method
  

</proxy:actions
  

<proxy:headers/
  

<proxy:cookies/
  

</proxy:policy
  

Sample custom policy

A sample whitelisted widget would have a policy that looks like this:

 

<proxy:policy url="http://www.mysite.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 only the GET method, passes the named headers, and allows the JSESSIONID cookie.

If you want to blacklist "mysite.com", you would write a policy that looks like this:

 



<proxy:policy url="http://www.mysite.com/*" acf="none"
  

<proxy:actions/
  

<proxy:headers/
  

<proxy:cookies/
  

</proxy:policy
  

This instructs the proxy not exchange perform any HTTP actions on and not to exchange any cookies or headers with this URL.

Optional settings

Optional settings in the proxy-config.tpl file are configured as follows:

 



<proxy:meta-data
  

<proxy:name
 maxconnectionsperhost</proxy:name
  

<proxy:value
 20</proxy:value
  

</proxy:meta-data
    

The optional settings are defined in this table (note that some of the optional values are defined in the proxy-config.tpl file with values other than the listed defaults):

Name	Default value	Definition
maxconnectionsperhost	2	Specifies the maximum number of connections kept alive for any host or port combination.
maxtotalconnections	5	Specifies the maximum number of connections supported by the proxy.
unsigned_ssl_certificate_support	false	Indicates whether self-signed certificates are supported by this deployment.
connection-timeout	none	Specifies the timeout in milliseconds for connections.
socket-timeout	none	Specifies the timeout in milliseconds for sockets.
circular_redirects	true	Allows redirects to the same URL. This is necessary when a component redirects to the same URL, but with different parameters.
max_circular_redirects	100	Limits how many redirects are allowed before a failure.

Configuring the Ajax proxy with a pass-through proxy

The Ajax proxy has optional settings to support a pass-through or forward proxy. The following is an example of configuration settings for a fictitious pass-through proxy:

 



<proxy-meta-data
  

<proxy:name
 passthru_host</proxy:name
  

<proxy:value
 9.17.237.132</proxy:value
  

</proxy-meta-data
  

<proxy-meta-data
  

<proxy:name
 passthru_port</proxy:name
  

<proxy:value
 3128</proxy:value
  

</proxy-meta-data
  

<proxy-meta-data
  

<proxy:name
 passthru_realm</proxy:name
  

<proxy:value
 MyRealm</proxy:value
  

</proxy-meta-data
  

<proxy-meta-data
  

<proxy:name
 passthru_username</proxy:name
  

<proxy:value
 username</proxy:value
  

</proxy-meta-data
  

<proxy-meta-data
  

<proxy:name
 passthru_password</proxy:name
  

<proxy:value
 password</proxy:value
  

</proxy-meta-data
  

passthru_host, passthru_username and passthru_password are required values. If passthru_port is not specified, it is set to the default value of 80. If a passthru_realm parameter is not set then credentials are sent for all authentication attempts. passthru_realm should always be used in a production environment to protect user credentials.

Setting up WebSphere Application Server and IBM HTTP Server to use Secure Socket Layer

Configure IBM HTTP Server to use SSL

You must first configure IHS to use SSL. Select Expand Servers

 

Web Servers in the left pane of the WebSphere Application Server admin console. From the list of Web servers, choose the one that you defined for this profile. In the example screenshot below, its name is webserver. Click on the Edit button to open the httpd.conf file. (Note that you can also navigate to the location of this file on the disk and edit it with a text editor.)



At the end of the httpd.conf file, add the following content:

 



LoadModule ibm_ssl_module modules/mod_ibm_ssl.so 

<IfModule mod_ibm_ssl.c
  

Listen 0.0.0.0:443 

<VirtualHost *:443
  

ServerName <server_name
  

DocumentRoot C:\IBM\HTTPServer\htdocs 

SSLEnable 

</VirtualHost
  

</IfModule
  

SSLDisable 

Keyfile "<path_to_key_file
 " 

SSLStashFile "<path_to_stash_file
 " 

Replace <server_name

 

with the name of your Web server, <path_to_key_file

 

with the path to the plugin-key.kdb file, and <path_to_stash_file

 

with the path to the plugin-key.sth file.

Export certificate from WebSphere Application Server

Your WebSphere Application Server deployment comes with a default self-signed certificate, which is used in the examples below. The process is the same for signed certificates.

Navigate to Security

 

SSL certificate and key management in the left pane of the WebSphere Application Server admin console menu. From the Related Items list in the right pane of the window, select Key stores and certificates. From the list, click on the name of the default key store ("NodeDefaultKeyStore" in the screenshot).



Under Additional Properties in the left pane of the next window, choose Personal certificates for self-signed certificates; otherwise, choose signer certificates. Select the certificate that you want to export by selecting the check box next to its name and then click Export in the button menu above the list.


In the subsequent dialog, assign the certificate an alias and fill in a file name to which you want the certificate stored. If you do not specify a full path, the extracted certificate is stored in <app_server_root

 

/profiles/ 

 



<sloc:serviceReference enabled="true" 

person_card_service_name_js_eval= 

"generalrs.label_personcard_activitieslink" 

person_card_service_url_pattern= 

"/service/html/mainpage#dashboard%2Cmyactivities 

%2Cuserid%3D{userid}%2Cname%3D{displayName}" 

serviceName="activities" 

ssl_enabled="true"
  

<sloc:href
  

<sloc:hrefPathPrefix
 /activities 

</sloc:hrefPathPrefix
  

<sloc:static href="http://<webserver
 /activities" 

ssl_href="https://hostname/activities"/
  

<sloc:interService href="https://<webserver
 "/
  

</sloc:href
  

</sloc:serviceReference