Continuation of Connections 2.5 security knowledge transfer
Part 1 .
Forcing Secure Sockets Layer (SSL)
You might want to force all Lotus Connections communications over SSL. To effect this, use the following steps:
1. Set Connections to require SSL. Use the wsadmin command line tool and run the following command:
LCConfigService.updateConfig("force.conf.comm.enabled", "true")
2. Set cookies to require HTTPS. In the WebSphere Application Server admin console, navigate to Servers
Application Servers. Click on the name of your server in the list. On the subsequent page, expand Web Container Settings, listed under Container Settings, and then click Web container.
3. Under Additional Properties, select Session management, and then click Enable cookies under General Properties.
4. On the next page, select the check box labeled Restrict cookies to HTTPS sessions. Click OK and save your changes.
5. As an optional step, you can set SSO to require SSL. This protects the LTPA tokens. To do so, from the WebSphere Application Server admin console, navigate to Security
Secure administration, applications and infrastructure. Expand Web Security and then click single sign-on (SSO).
6. On the next page, click the check box labeled Requires SSL. Click OK and save your changes.
7. If you are using IBM HTTP Server (IHS), configure it to use SSL as described in the previous section. If you have Files or Wikis deployed, add the following statements to the IHS httpd.conf file:
Redirect /files/basic/api https://<servername
:<port
/files/basic/api
Redirect /wikis/basic/api https://<servername
:<port
/wikis/basic/api
where
<servername
and
<port
are the host name and the SSL port defined for your deployment.
8. Restart WebSphere Application Server and IHS.
Specifying a separate download domain
Files attached to a blog, activity, or stored in the Files component have the potential to contain malicious content that can be executed by some browsers. To minimize this risk, it is best to set up a separate domain for downloaded files. This causes the browser to enforce the same origin policy, in which code in one domain cannot access information in another.
The process for setting up this separate domain is described in the Lotus Connections Information Center under Security
Securing features from malicious attack
Mitigating a cross-site scripting attack
Specifying a separate file download domain.
Securing an extranet deployment
Best practices for extranet deployments include the following:
- Setting the reader role to "All authenticated." This permits only authenticated users to see "public" data (for example, public communities or bookmarks). It also protects against unauthenticated users accessing the Ajax proxy. Without this setting in place, an unauthenticated user could use the proxy to access any URL in your intranet.
- Disabling self-signed certificates in the proxy-config.tpl, proxy-search-config.tpl and any customized proxy template files. The Ajax proxy is deployed with "unsigned_ssl_certificate_support" set to "true" to simplify initial setup and testing. This should be set to "false" for production deployments.
- Force SSL, whether via software configuration or via a hardware SSL accelerator.
Troubleshooting
It is extremely valuable to be able to analyze network traffic when working with the Ajax proxy, widgets, SSO and feeds. There are various tools available to enable you to capture network traffic, including Firebug (available only for Firefox), Wireshark (http://www.wireshark.org/">http://www.wireshark.org/) and Fiddler (http://fiddler2.com/Fiddler2/version.asp">http://fiddler2.com/Fiddler2/version.asp). Using these tools allows you to identify cookies or headers that your request might be sending, but that are being blocked by the Ajax proxy. They allow you to determine if a hostname has been misconfigured, so that Connections is sending traffic to the wrong DNS. They show whether traffic is flowing between hosts as expected.
Enabling WebSphere Application Server tracing is also extremely valuable. Some trace settings you might find useful are shown below.
|
|
|
|
com.ibm.ws.security.*=all:com.ibm.websphere.securit
y.*=all
|
Helps determine issues with SSO, especially concerning feeds.
|
Check that cookies (especially LTPA) and TAI are being handled properly.
|
com.ibm.lconn.core.web.request.*=all
|
Used in diagnosing reverse proxy configuration issues.
|
Look for the contents of the "VIA" header, ensure that the reverse proxy name is correct.
|
com.ibm.ws.ajaxproxy.*=all:org.apache.commons.http
client.HttpClient=finest: httpclient.wire.header=finest
|
Used in diagnosing forward proxy configuration issues.
|
Check that the Ajax proxy is forwarding all necessary headers and cookies, and that the proxied URL is correct.
|
com.ibm.connections.directory.services.*=all:com.ibm
.websphere.wim.*=all:com.ibm.ws.wim.*:com.ibm.conn
ections.httpClient.*=all
|
Helps locate problems in directory services when users are not being retrieved properly.
|
Check the configuration settings reported by directory services, be sure to enable this trace when sending any issues to support or development.
|
Author: Annette Riffe is an Advisory Software Engineer at IBM working on the Lotus Connections team as the Security Lead.