Single sign-on (SSO) can be complex to configure, but it is beneficial to users who otherwise become annoyed when repeatedly queried for login information. Using the new home page feature in Lotus Connections 2.0, you can easily switch between different features, but you must enable SSO to connect to them seamlessly.

Understanding SSO

SSO is a method of access control that enables you to log in once and gain access to the resources of multiple applications without being prompted to log in again. SSO authenticates you to access all the applications that you have been authorized to access and eliminates future authentication requests when you switch applications during that particular session.

Usually, when we talk about SSO, we're talking about the Web user experience (see figure 1). For example, suppose you browse to your favorite URL and are prompted to log in. The Web application server verifies your password and allows access to the URL. Now you are recognized in the SSO environment, so that when you browse to another URL in the environment, you don't need to repeat the login steps.

Of course, for SSO to be successful, it is critical that SSO servers and applications recognize users after they have logged in. In a Web environment, the "magic" used behind the scenes to achieve SSO is Lightweight Third-Party Authentication (LTPA). The LTPA technology allows SSO servers to reuse a user’s authentication after the user has logged in. We discuss LTPA technology in more detail below.

To have an SSO environment, you must verify the following:

• All servers are configured as part of the same root domain. The domain names on each system are case-sensitive and must match identically. For example, if the root domain is specified as ibm.com, then SSO is effective with any IBM WebSphere® Application Server on a host that is part of the ibm.com domain, for example, a.ibm.com and b.ibm.com.
• All servers share the same registry. This registry can be either a supported Lightweight Directory Access Protocol (LDAP) directory server such as IBM Tivoli® Directory Server or a Sun Directory.
• HTTP cookies are enabled in browsers because the authentication information that is generated by the server is sent to the browser in a cookie. The cookie is used to propagate the user's authentication information to other servers.
• Basic authentication (user ID and password) using the basic and form-log-in mechanisms is supported.

Back to top

Understanding LTPA

LTPA is critical in the SSO world. LTPA is intended for distributed, multiple WebSphere Application Server and system environments, and it supports forwardable credentials and SSO. LTPA can support security in a distributed environment through cryptography, thereby permitting LTPA to encrypt, digitally sign, and securely transmit authentication-related data, and then later decrypt and verify the signature.

When LTPA is used, a token is created with the user's information and an expiration time, and it is signed by the keys. The LTPA token is time-sensitive, so all servers that participate in a particular domain must have their time, date, and time zone synchronized. If they do not, the LTPA token appears prematurely expired and can cause authentication or validation failures.

The token passes through cookies to other servers, in the same cell or in a different cell, through cookies and is then validated to ensure that it has not expired and that the user information in the token is valid in its registry. If validation is successful, the resources in the receiving servers are accessible as well.

All the WebSphere Application Server processes in a cell (deployment application servers) share the same set of LTPA keys. To support SSO in all the processes across multiple cells, the LTPA keys must be shared between different cells. You can export LTPA keys from one cell, then import them to other cells. For security purposes, the exported keys are encrypted with a user-defined password, and this same password is needed when importing the keys into other cells.

Back to top

Configuring SSO with LTPA for Lotus Connections 2.0

Lotus Connections is social software for business that empowers you to be more innovative more quickly by using dynamic networks of coworkers, partners, and customers. Lotus Connections 2.0 includes a home page feature that delivers an aggregated view of the latest updates from all subscribed Lotus Connections features.

You can easily switch to different features through home page; however, SSO enablement is required after you install the home page feature on different profiles. Lotus Connections 2.0 supports three methods of configuring SSO in WebSphere Application Server V6.1.0.13:

• Using LTPA
• Using an authenticating reverse proxy
• Using Java™ Authentication and Authorization Service (JAAS) and Java Authorization Contract for Containers (JACC)

In this article, we address the first method: using LTPA to implement SSO.

Lotus Connections 2.0 supports two typical installation scenarios. In the first scenario, all the features of Lotus Connections 2.0 are installed on one Profile, with different features installed on different server instances (see figure 2).

In the second scenario, different features of Lotus Connections 2.0 are installed on different Profiles and on the default server instance (see figure 3).

Let's discuss how to configure SSO according to these two installation scenarios.

Back to top

Basic steps to configure SSO (required for both installation scenarios)

After installing Lotus Connections 2.0, complete the following steps to use SSO LTPA keys.

Modify the LotusConnections-config.xml file

To modify the LotusConnections-config.xml file, use the wsadmin command to export this file, modify some configuration about SSO in the file, and import this configuration file into WebSphere Application Server. In this case, we cover only the configuration steps for a stand-alone deployment.

1. Open a command window, and start the wsadmin command line tools, using one of the following commands:
   
   • Windows: <$WAS_HOME>\profiles\<profile_name>\bin\wsadmin.bat -lang jython -user <wasadmin> -password <adminpassword>
   • Linux or AIX: <$WAS_HOME>\profiles\<profile_name>>bin\wsadmin.sh -lang jython -user <wasadmin> -password <adminpassword>

   where <wasadmin> is the user who can access the administrative console and <adminpassword> is the password of the <wasadmin> user.

2. Run the following command in the command window:
   execfile("connectionsConfig.py")
3. View the Lotus Connections configuration file, using the following command:
   LCConfigService.checkOutConfig(<work_directory',<cell_name>)

   where <working_directory> is the temporary working directory to which the configuration is copied, and <cell_name> is the name of the WebSphere Application Server cell hosting the Lotus Connections feature. If you don't know the cell name, check the directory name:

   <$WAS_HOME>\profiles\>profile_name>\config\cells\
4. To enable SSO LTPA, make sure that the sso_ltpa_token_enabled attribute is set to true (which is the default) in the LotusConnections-config.xml file.
   
   

   NOTE: By default, the Profiles feature uses lazy authentication, and the waltz_profiles_integration_auth attribute is set to none. If you want, you can force authentication for Profiles by setting the value of the waltz_profiles_integration_auth attribute to SSO and the sso_ltpa_token_enabled to true. In the administrative console, you can see in figure 4 when you set the lazy authentication for the Profiles feature.

   
   
   Figure 4. Lazy authentication for Profiles
   
   
   

   Also note that, if you want, you can disable private membership for the Communities feature by setting the value of the waltz_communities_integration_auth attribute to none.

5. Save and close the LotusConnections-config.xml file.
6. Check in the LotusConnections-config.xml file, using the following command:
   LCConfigService.checkInConfig()
7. Restart WebSphere Application Server.

Set up SSO in the administrative console

To configure a domain name for SSO, perform the following steps in the administrative console:

1. Log in to the WebSphere Application Server Integrated Solutions Console.
2. Select Security - Secure Administration, applications, and infrastructure.
3. Expand Web security and select the single sign-on (SSO) option.
4. Type your domain name in the Domain name field, ensuring that you add a dot (.) before the domain name (see figure 5). If you install all features on one Profile, you can type the IP address in Domain name field, for example:
   9.186.10.87
5. Select the Interoperability Mode and Web inbound security attribute propagation fields.
   
   
   Figure 5. Configure SSO
   
   
   
6. Restart all your installed features, and make sure that you can switch between them without authenticating more than once.

Back to top

Advanced steps to configure SSO (required only for the second installation scenario)

In the second scenarion, a different feature is installed on different Profiles (one Profile means one cell in WebSphere Application Server), and for the first installation scenario this step can be skipped.

To support SSO in WebSphere Application Server across multiple WebSphere Application Server cells, you must share the LTPA keys and password among the cells. To do this task, complete the following configuration steps in the administrative console.

Export the LTPA key

First, export the LTPA key from one cell, to be shared among the other cells. To export the key file, follow these steps:

1. Enter http://server_name:port_number/ibm/console in a Web browser to access the administrative console.
2. Select Security - Secure administration, applications, and infrastructure - Authentication mechanisms and expiration.
3. In the Password and Confirm password fields, enter the password that is used to encrypt the LTPA keys (see figure 6). Remember the password so that you can use it later when the keys are imported into the other cell.
   
   
   
   Figure 6. Export LTPA key file
   
   
   
4. In the Fully qualified key file name field, specify the fully qualified path to the location where you want the exported LTPA keys to reside. You must have write permission to this file.
5. Click Export keys to export the keys to the location that you specified in the Fully qualified key file name field. If the action is successful, the following message displays:
   The keys were successfully exported to the file c:/profile1.key.
6. Click OK and save.

Import the LTPA keys

After you export the LTPA keys from one cell, you must import these keys into another cell. To do this task, you must know the password for the exported key file, so that you can access the LTPA keys, and you must complete the following steps in the administrative console:

1. Access the administrative console for the cell that receives the imported keys by typing http://server_name:port_number/ibm/console in a Web browser.
2. As you did in the previous section, select Security - Secure administration, applications, and infrastructure - Authentication mechanisms and expiration.
3. In the Password and Confirm password fields, enter the password that is used to decrypt the LTPA keys. This password must match the password that was used in the cell from which you are importing the keys.
4. In the "Fully qualified key file name" field, specify the fully qualified path to the location where the signer keys reside. You must have write permission to this file.
5. Click Import keys to import the keys to the location that you specified in the "Fully qualified key file name" field. If the action successful, the message shown in figure 7 displays.
   
   
   
   Figure 7. Import key file Success message
   
   
   
6. Click Save to save the changes to the master configuration. It is important to save the new set of keys to match the new password so that you do not encounter any problems when you start the servers later.

Back to top

Troubleshooting

If you have issues with SSO for Lotus Connections 2.0, ensure the following:

1. The format of LotusConnections-config.xml file is correct. You can open this file with Internet Explorer to verify its format.
2. You are using the same LDAP directory for all WebSphere Application Server profiles.
3. The fully qualified host addresses are used in URLs when accessing the protected resource from a browser. The LTPA cookies are generated only for requests that specify a fully qualified host address.
4. The user registry (LDAP directory) contains the attributes that satisfy the search filters used for authentication.
5. The time zones are specified correctly for the servers in the SSO environment.
6. You reimport the LTPA keys to other profiles, if the LTPA key is changed in one profile.
7. You restart WebSphere Application Server after any change to the SSO configuration, for example, any modification to the LotusConnections-config.xml file or to the SSO configuration in the administrative console.

Back to top

Conclusion

Single sign-on uses centralized authentication servers that are used by all other applications for authentication purposes. When combined with LTPA techniques, SSO ensures that users don't need to enter their credentials more than once. We have provided the detailed steps that you need to configure SSO for Lotus Connections 2.0, so that a user can log in to one feature of Lotus Connections 2.0 and then switch to other features easily, without needing to reauthenticate.

Resources

• Participate in the discussion forum.
  
  
• Refer to the IBM Lotus Connections Information Center.
  
  
• Refer to the IBM Lotus Connections wiki.
  
  
• Refer to the IBM Lotus Connections product page.
  
  
• Refer to the WebSphere Application Server V6.1 Information Center.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Understanding SSO
• Understanding LTPA
• Configuring SSO with LTPA for Lotus Connections 2.0
• Basic steps to configure SSO (required for both installation scenarios)
• Advanced steps to configure SSO (required only for the second installation scenario)
• Troubleshooting
• Conclusion
• Resources
• About the authors
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into Lotus on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers