ShowTable of Contents
Introduction
This article describes how to restrict the access to Lotus Connections 2.5 to a specific group of people when you have LTPA SSO in place and a large Domino LDAP directory.
In some cases, you might find Lotus Connections 2.5 becomes very slow in loading pages on the first access of each user. I found this situation at a customer site. After some investigation, I found that this problem appeared only after a change in the WebSphere Application Server Security configuration, due to a specific request (i.e. the customer was trying to restrict access to Lotus Connections using the standard “user/group mapping” method). To better understand the problem and the solution adopted, I will briefly describe the customer environment. Note that the screenshots displayed in this document are not taken from the actual customer environment but from a demo environment.
The environment
The customer already had LTPA SSO set up between their Domino environment (iNotes, Sametime, Quickr) and the WebSphere Application Server environment (Portal and Connections). The typical use case is that every user (in this example, Frank Adams) logs into Portal each morning (Figure 1) and displays the Portal home page where a “Useful Links” list profiled for his job is located (Figure 2).
Figure 1
Figure 2
Every application listed in the “Useful Links” page is configured with the LTPA SSO, so the user can click on each link and move to the related application without having to log in again. (Figures 3 and 4).
Figure 3
Figure 4
Note that in this specific use case, the LTPA token is generated by the Portal WebSphere Application Server environment.
In a second use case, users log in directly to iNotes each morning (Figure 5) and then move to the other application using direct links that they stored as bookmarks in their browsers.
Figure 5
Note that in this case, the LTPA token is generated by the Domino environment and that users typically use direct links to access other applications.
The Lotus Connections security request
The specific security request related to Lotus Connections was to restrict the access only to a specific group of people belonging to the Human Resource department, without removing the LTPA SSO configuration (as described in the previous section), which would allow access to Lotus Connections for everyone that was previously logged into Portal or iNotes.
The first thing that was done to address this requirement was to introduce a
visibility rule in the “Useful Links” page that displayed a Lotus Connections link to a select group of users. (Figures 6 and 7).
Figure 6 – Frank Adams is allowed to see the Lotus Connections 2.5 link
Figure 7 – Sally Thomas is not allowed to see the link because the visibility rule hides it.
This configuration is obviously not going to address the requirement because it does not prevent direct access to Lotus Connections applications.
The initial security configuration that the customer put in place to prevent direct access was the
user/group role mapping in WebSphere Application Server. The configuration was set up such as that at the application level for access control appeared similar to Figure 8. Note that this configuration was repeated for each Lotus Connections application.
Figure 8 - Initial security configurationMoreover, to complete this configuration , the
LotusConnections-config.xml was modified to set
service_extension_auth for Communities and Profiles to “DSX-Admin.” For example:
<sloc:serviceReference communities_directory_service_extension_auth="DSX-Admin" communities_directory_service_extension_auth_alias="connectionsAdmin" communities_directory_service_extension_enabled="true" communities_directory_service_extension_href="http://lotusconnections.ibm.com/communities/dsx/" profiles_directory_service_extension_auth="DSX-Admin" profiles_directory_service_extension_auth_alias="connectionsAdmin" profiles_directory_service_extension_enabled="true" profiles_directory_service_extension_href="http://lotusconnections.ibm.com/profiles/dsx/" serviceName="directory"/>
With this security configuration in place, restricted Lotus Connections users who attempted to access Lotus Connections with a direct link, received a “Page Cannot be displayed” error (Figure 9).
Figure 9
Therefore, this security configuration addressed the customer security requirement, but it led to unacceptable slow downs in page loading.
After some investigation, I noticed that for each occurrence, for each user, for each session, and for each Lotus Connections application, WebSphere Application Server was performing group security checking. This is not good behavior in general, but to compound this issue, the Domino LDAP directory used by Lotus Connections was very large (more than 17KB users and 3400 groups) and the groups were classic Domino flat groups (CN=LotusConnectionsUsers). This made the search among these groups very inefficient.
The solution adopted
The security configuration that addresses the customer requirement, but eliminates these unacceptable performance slow downs, uses the concept of
LDAP entity type search filter. To achieve this, you need to first identify Lotus Connections users with an LDAP attribute (for example, in my use case I set the LDAP “homephone” attribute, which was unused, to something similar to “LC”). This is because LDAP filters based on attributes are much faster than the ones based on groups (especially if they are flat). Next, you need to simply complete this configuration on the WebSphere Application Server administration console as shown in Figure 10.
Figure 10 – The complete filter is (&(uid=*)(homephone=*)(objectclass=dominoPerson))
The interesting thing about this configuration is that if a user does not match with the filter you set up, the
LTPA token is discarded and the user cannot log in to Connections even if he has the previously generated (and valid for your environment) LTPA token. In addition, if a user is not authorized and the LTPA is discarded, he does not receive an anonymous “Page cannot be displayed” error page, but he is redirected to the Lotus Connections authentication form (Figure 11). If he tries to log in again, he receives the error shown in Figure 12.
Figure 11
Figure 12
In addition to much faster performance, there are a few interesting improvements to the new approach. First, this configuration is much faster and lighter than the original configuration. You do not need to repeat the user/group mapping for every Lotus Connections application. Secondly, the access denied is handled with a verbose error description and not with the “Page cannot be displayed – error 403” error page. Lastly, this configuration takes place only at the WebSphere Application Server level, so it is not Lotus Connections specific and can be reproduced for similar requirements for every WebSphere Application Server application.
Author:
Elena Sangalli
Lotus Client Technical Professional
IBM Italy