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/
>/etc. Enter and confirm a password, then click OK to export the certificate.
Import WebSphere Application Server certificate into IHS
In the WebSphere Application Server admin console, navigate to Servers > Web Servers, and then click on the name of your Web server. On the next page, choose Plug-in properties from the Additional Properties list in the left pane. Click on Manage keys and certificates.
On the next page, click Signer Certificates and then select Add from the button menu.
In the subsequent dialog, enter the alias for the certificate and the file name under which you stored it, then click OK.
Return to Servers > Web servers > your_server_name > Plug-in properties and click Copy to Web server key store directory. Next, restart IHS.
Update LotusConnections-config.xml for all features
Each of the Connections components has a service reference in the LotusConnections-config.xml file. Below is an example showing Activities. Use the wsadmin command line tool to check out the file, then modify the <webserver> settings below.
<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>
Continue to Part 2 .