ShowTable of Contents
Summary: IBM® Lotus® Connections 2.5 offers many security configuration options; some are enabled by default, while many can be configured by an administrator. This document describes the various options, how they are delivered by default, and why you might want to change them.
Security roles
Lotus Connections uses J2EE roles to authorize various users to perform a variety of functions. These roles are configured in the WebSphere® Application Server administrative console. Each Lotus Connections feature is configured individually. To see this, follow these steps:
1. Open the WebSphere Application Server administrative console.
2. Expand the Applications category in the menu on the left-hand side of the window.
3. Select Enterprise Applications and then the server you wish to configure; the window shown in figure 1 displays.
Figure 1. Security role to user/group mapping window
The roles shown in the above figure are defined below. Note that not every role is used by every Lotus Connections feature.
Roles for ordinary users
Person. A user in the person role has read/write access to Lotus Connections. By default, this role is set to “All authenticated?.” If you change this to “Everyone?”, then all users will have read/write access to all areas of Lotus Connections without authentication. This is not advisable for servers that are in any publically accessible environment.
Everyone. This role refers to unauthenticated users, who have access to only a few public pages, such as the log-in page. This role is set to “Everyone?” by default and should not be modified.
Reader. Users in this role have read-only access to Lotus Connections. This role is set to “Everyone?” by default; however, in a production environment, you might wish to set this role to “All authenticated?”, to require authentication even for read-only access.
Additionally, if you have Lotus Connections deployed on an Internet-facing system, it's very important to set this role to “All authenticated?” because the reader role also controls access to the Ajax proxy. If the reader role is set to “Everyone?”, then unauthenticated users can access through the proxy URLs that they should not be able to view.
Files-owner. A user in this role has all the privileges of someone in the person role and can also upload files. This role is used only in the Files and Wikis components of Lotus Connections and is set to “All authenticated?” by default. You can change this setting to named users if you wish to specify which users can upload files.
Roles for administrative users
There are a number of administrative roles in Lotus Connections, not all of which pertain to all of the Lotus Connections features:
Admin. Users in the admin role can perform certain administrative functions defined by the features that use it. It is blank by default, but for the Blogs feature, you must set this role to a valid user, to set up the front page blog. A user with this role in the Homepage feature can add new widgets, enable and disable existing widgets, and can view the server metrics link in the Homepage footer.
Search-admin. This role is used by the Search feature to create search indexes from public and private information to support advanced searches across the product. It is set by default to the user identified during the Lotus Connections installation as the WebSphere administrator.
Widget-admin. Widget containers use the widget-admin role to send events alerting widget applications of container changes. As with the search-admin role, this is set by default to the WebSphere administrative user.
Dsx-admin. This role is used by the directory services extensions to access Profiles and Communities user information. It is defined only in the Profiles and Communities features. By default, it is blank in Profiles and is set to the WebSphere administrative user in Communities.
You should set it to a valid user name in Profiles, if you plan to configure Lotus Connections to hide email addresses or to force users to authenticate before they can use the product.
Forcing users to authenticate
By default, Lotus Connections permits unauthenticated users to view certain information, including public communities and public blogs. You may, however, wish to require all users to authenticate before they can view any data on your Lotus Connections deployment.
To do this, perform these configuration steps in each Lotus Connections server you have defined:
1. In the WebSphere Application Server administrative console, expand the Applications category in the menu on the left-hand side of the window.
2. Select Enterprise Applications and then the application you wish to configure.
3. Locate the reader role, and click the box under the column “All authenticated?”
4. Click OK and save your changes.
Perform Steps 2 through 4 for each Lotus Connections server for which you want to require authentication, and then restart the servers.
NOTE: You should not perform these configuration steps if you are using the Lotus Connections Multi-Service Portlet or the Lotus Connections Plug-in for Sametime. These features do not function properly when authentication is enforced.
Configuring SSL settings
Lotus Connections does not enable Secure Sockets Layer (SSL) by default, so that administrators can configure the product in a simpler state, making troubleshooting less complex. Additionally, some users have hardware SSL accelerators and might want to save the processing time required by software SSL handling.
If you do not have an SSL accelerator and do not enable software support for SSL in Lotus Connections, then your users' credentials will be sent over HTTP in clear text.
To configure Lotus Connections to require SSL:
- If you are using IBM HTTP Server (IHS) or Microsoft's® Internet Information Services (IIS), you must configure it to work with SSL and exchange a certificate between WebSphere Application Server and IHS or IIS. Also, you must update the LotusConnections-config.xml file with the new URLs for the features (for example, http://myWebServer.ibm.com/activities).
The following two bulleted steps are optional, and either one or both can be done. You would do the first if you wanted to force all traffic over SSL; you would do the second if you wanted to force cookies to be sent only over HTTPS.
- You can update the Lotus Connections configuration to set “forceConfidentialCommunications” to true, using the following command in the wsadmin command-line tool:
LCConfigService.updateConfig(“force.conf.comm.enabled”, “true”)
This forces all Lotus Connections traffic, not just authentication data, over SSL.
- You can configure WebSphere Application Server to require cookies to use SSL. Without this setting, cookies can be transmitted over HTTP, unencrypted. To do this:
1. In the WebSphere Application Server administrative console, expand the “Servers” category in the menu on the left-hand side of the window.
2. Click Application Servers, and select the name of the server you wish to configure.
3. Under “Container Settings” on the right-hand side of the window, expand Web Container Settings and click Web container.
4. Under “Additional Properties” on the right-hand side of the next window, select Session management and then click “Enable cookies”.
5. Click the check box next to “Restrict cookies to HTTPS sessions” (see figure 2); click OK, save, and restart your server.
Details on how to perform all these steps can be found in the Lotus Connections Information Center topic, “Forcing traffic to be sent over SSL.”
Figure 2. Enabling the Restrict cookies to HTTPS sessions option
- Finally, you can configure single sign-on (SSO) to require SSL, ensuring that the LTPA tokens are sent only over SSL. To do this:
1. In the WebSphere Application Server administrative console, expand the “Security” category in the menu on the left-hand side.
2. From here, select “Secure administration, applications, infrastructure,” and then expand Web Security (found under the “Authentication” heading on the right-hand side of the window).
3. Click “single sign-on (SSO)” and click the check box next to “Requires SSL” (see figure 3). Click OK, save, and restart the server.
Figure 3. Enabling the "Requires SSL" option
Ajax proxy settings
Lotus Connections uses an Ajax proxy to circumvent the browser's same-domain policy, thus allowing selected widgets and feeds to appear as though they are an integral part of the product.
The default Ajax proxy settings allow all Lotus Connections URLs to communicate among themselves without restrain. They also restrict all other URLs to the HTTP GET method and prevent them from requesting or exchanging cookies or HTTP headers.
You should not configure unknown URLs to be allowed to pass authentication requests to your users because you open your users to the threat of phishing attacks through forged sites.
If you wish Lotus Connections to display a custom widget or feed, you must add a policy to the Ajax proxy configuration template file, proxy-config.tpl. This policy should explicitly name the URL to be enabled and list any cookies and headers the widget needs to behave properly. You should enable widgets only from trusted sites.
For example:
<proxy:policy url="http://my.network.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:header>If-.*</proxy:header>
<proxy:header>Pragma</proxy:header>
<proxy:header>Cache-Control</proxy:header>
</proxy:headers>
<proxy:cookies>
<proxy:cookie>JSESSIONID</proxy:cookie>
</proxy:cookies>
</proxy:policy>
If your widget requires users to authenticate, you can allow basic authentication requests by modifying the policy header like this:
Custom policies should be added to the template file above the default policy.
By default, the Ajax proxy is configured to support self-signed certificates. This is useful when setting up the system on an internal network but should be disabled for production systems.
To disable support for self-signed certificates, change the following setting in the proxy-config.tpl file to “false”:
<proxy:meta-data>
<proxy:name>unsigned_ssl_certificate_support</proxy:name>
<proxy:value>true</proxy:value>
</proxy:meta-data>
For further details, refer to the Lotus Connections Information Center topic, “Configuring the AJAX proxy.”
Mitigating cross site scripting attacks
Here we discuss some options for mitigating cross-site scripting attacks.
The active content filter
Lotus Connections uses the active content filter (ACF) to protect against malicious active content in the product. For example, suppose a malicious Blogs user attempts to steal a user's JSESSIONID cookie, as shown in figure 4.
Figure 4. Attempt to steal user's JSESSIONID
The ACF will remove the malicious code, rendering the blog entry harmless. Figure 5 shows sanitized blog entry from figure 4, in which the malicious “onclick” content has been removed.
Figure 5. Sanitized blog entry
When we view the page source for the blog entry, we see the following:
<a href="#" onclick=""><wbr>Check this out!</a><wbr>
If you are deploying Lotus Connections on an internal, trusted network, and you are willing to assume the security risks of doing so, you can disable the ACF to improve server performance. When the ACF is disabled, any user-generated active content such as JavaScriptTM will be displayed, including malicious content.
You can disable the ACF via the wsadmin command line tool; for example, to disable the ACF in Activities, you would perform the following in wsadmin:
ActivitiesConfigService.updateConfig("activeContentFilter.enabled", "false")
This needs to be done individually for each Lotus Connections feature.
The details for disabling the ACF in each of the Lotus Connections features can be found in the Information Center topic, “Turning off active content filtering.”
The ACF is also configured in the Blogs and Wikis features to filter malicious parameters from embedded Flash animations. (The other features do not enable this because they do not allow raw HTML to be added to the pages.)
For example, the following embed string includes JavaScript to display the user's cookies:
After passing through the ACF, the malicious JavaScript has been removed, and the embed has been changed to an iframe, further limiting the access the animation has to the page's Document Object Model (DOM):
You may want to have the ACF strip all Flash animations from the product, for example, when a new Flash exploit has been identified and you want to disable Flash animations until you can apply a patch to your systems. In this case, you can turn off Flash support in Lotus Connections, using the wsadmin command-line tool:
LCConfigService.updateConfig("allowedContent.contentType.enabled","false")
For further details, refer to the Information Center topic, “Disabling support for Flash animations.” Note that any Flash animations already present in the product must be manually removed.
Set up applications in separate domains
If you've configured a feature not to use active content filtering, consider setting it up in a separate domain from the other features. This enables the features to take advantage of the browser's same-domain policy, isolating the impact of any active content attack.
Download files to a separate domain
Consider configuring your IHS or IIS to download attachments to a separate domain. This ensures that when the file is opened, the features are protected by the browser's same-domain policy from any active content they might contain.
For details on how to configure IHS and set up a separate domain for downloading attachments, refer to the Information Center topic, “Specifying a separate file download domain.”
Turn off single sign on
If you've disabled active content filtering, you should disable SSO between the Lotus Connections features. This ensures that a malicious script in one feature cannot access another without authentication.
If you choose to enable SSO while active content filtering is disabled, you can contain cross-site scripting attacks by setting WebSphere Application Server to use HTTP-only cookies for the SSO cookies. To do this:
1. In the WebSphere Application Server administrative console, expand the “Security” category in the menu on the left-hand side
2. From here, select “Secure administration, applications, and infrastructure,” and then choose Custom properties on the resulting page.
3. Click New and enter “addHttpOnlyAttributeToCookies” in the Name field and “true” in the Value field (see figure 6).
4. Click OK, save your changes, and restart the server.
Figure 6. Name and Value fields
Mitigating phishing attacks
Lotus Connections uses email addresses to identify users in many different contexts; for example, they can be used to identify users when adding members to a Community, or to identify which user is making the request when two features communicate.
In a deployment open to public access, you may want to hide these email addresses to protect your users from malicious users who might collect them for the purposes of launching phishing attacks or for spam. If you choose to hide email addresses, intra-service communication will be performed via some other type of information, such as a user ID.
For further details, refer to the Information Center topic, “Hiding e-mail addresses.”
NOTE: If you are using one of the Lotus Connections extensions, such as the plug-in for Lotus Notes®, you cannot hide email addresses. These plug-ins require the use of the email address to identify users.
Antivirus support
Lotus Connections can be configured to send attachments to a virus scanner that supports the ICAP protocol. Lotus Connections 2.5 is certified to work with Symantec AntiVirus Scan Engine 5.1 and McAfee Web Security Appliance (3400) and (3300).
By default Lotus Connections is not configured for any virus scanning support. You must enable this support through configuration settings in the LotusConnections-config.xml file. If you do not enable virus scanning in Lotus Connections, then attachments made to features will be stored in the system without first being checked for viruses.
To configure antivirus support:
1. Search for the following entry in LotusConnections-config.xml:
<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>
-->
2. Remove the empty element, and uncomment the populated copy.
3. Replace “myscanner.host.com” with the name of the server hosting your virus scanner.
4. Replace “myScannerService” with “AVSCAN” if you are using Symantec AntiVirus Scan Engine, or “RESPMOD” if you are using the McAfee Web Security Appliance.
Details for this process can be found in the Information Center topic, “Enabling virus scanning.”
Restricting file attachments to specific types
The Blogs and Activities components both permit the administrator to restrict the types of attachments that users can upload. A Blogs administrator can specify the allowed file extensions in the administration page on the Lotus Connections client:
1. Log in as a Blogs administrative user and click the Administration tab in the Blogs feature (see figure 7).
Figure 7. Administration tab
2. Navigate to “File Upload Settings.” On this page, you can either “whitelist” or “blacklist” file extensions (see figure 8). By default, files with .jpg, .jpeg, .gif and .png extensions can be uploaded.
Figure 8. Specifying file extensions
The Activities component specifies file type restrictions in the oa-config.xml file. A WebSphere administrative user can edit this file after checking it out, using the wsadmin command line tool. Details for performing file check-out and check-in can be found in the Information Center topic, “Administering features.”
Search for the sizeLimits section in the oa-config.xml file:
<sizeLimits>
<limit mimeFilenameRegex=".*\.exe">0</limit>
<limit mimeFilenameRegex=".*\.bat">0</limit>
<limit mimeFilenameRegex=".*\.sh">0</limit>
<limit mimeFilenameRegex=".*\.oa">0</limit>
<limit mimeFilenameRegex=".*">10485760</limit>
</sizeLimits>
To blacklist a particular file extension, set its limit to 0. By default, exe, bat, sh, and oa files are restricted from upload; all other file types are restricted to 10 MB.
Conclusion
There are many options available for securing Lotus Connections and, depending on your deployment scenario, you should now be able to choose which ones—if not all—are right for you.
Resources
Lotus Connections 2.5 Information Center:
http://publib.boulder.ibm.com/infocenter/ltscnnct/v2r0/index.jsp?topic=/com.ibm.connections.25.help/
developerWorks® Lotus Connections product page:
https://www.ibm.com/developerworks/lotus/products/connections/?S_TACT=105AGX13&S_CMP=LP
Lotus Connections forum:
http://www-10.lotus.com/ldd/lcforum.nsf?OpenDatabase&S_TACT=105AGX13&S_CMP=LP
About the author
Annette S. Riffe
IBM Software Group
Advisory Software Engineer - Lotus Connections
Littleton, MA
Annette Riffe has been with IBM since 1999, currently working as an Advisory Software Engineer in the IBM Littleton Software Lab. She is the lead security engineer for Lotus Connections.