r10 - 2016-07-18 - 17:33:58 - ShubjitNaikYou are here: TWiki >  Deployment Web > DeploymentInstallingUpgradingAndMigrating > ConfigureSSOforLibertyProfile

new.png Configuring Single Sign On (SSO) across WebSphere Liberty Profiles

Authors: ShubjitNaik
Build basis: Rational solution for Collaborative Lifecycle Management 6.0.x, WebSphere Liberty 8.5.x,.


Single Sign-On (SSO) authentication is a mechanism where multiple related but independent software applications are configured so that a user logs in once and gains access to all systems, without the need to re-authenticate. Rational® solution for Collaborative Lifecycle Management (CLM) supports several types of single sign-on authentication which is listed on our online help, including our new solution introduced with 6.x, Jazz Security Architecture.


This article will focus on configuring SSO on WebSphere Liberty Profile. Users can configure SSO in a distributed environment on WebSphere Liberty by using the LTPA authentication protocol. With LTPA, a user's login credentials are stored in a session cookie that is available for the current browser session only. This cookie contains the LTPA token. Users can share authentication tokens on multiple CLM applications that are installed on different servers within the same domain.


From CLM version 6.0.1 onwards, we bundle WebSphere Liberty as the default application server with CLM. There would be instances where users would setup multiple Liberty Profiles to distribute CLM applications. Following are a few scenarios :

  • Deploy a distributed setup using WebSphere Liberty where each CLM application is setup on its own Liberty Profile
  • Deploy one or a set of applications (example DCC and JRS) on a separate Liberty Profile and the core CLM applications resides on WAS Full Profile
  • Adding additional application instances such as CCM1 / RQM1 / RM1 with the bundled Liberty server connecting to JTS/CCM/RQM residing on WAS Full Profile or on the bundled Liberty Profile

In the above Scenarios, it is critical to configure Single Sign-On between these application servers such that a user only needs to log into one of the application and subsequent access to the other applications will not require re-authentication.

Prerequisites and Assumptions


Scenario: CLM distributed on multiple Liberty Profiles

By default, Liberty uses SSO when all applications are on a single Liberty Profile. If you are installing the JTS or other CLM applications on separate Liberty Profiles, follow this procedure:
  1. Enable SSO on each of the Liberty Servers by adding additional parameters in server.xml
  2. Export LTPA keys from Liberty Profile hosting JTS application and import them to Liberty Profiles hosting rest of the CLM applications

Enable SSO on each instance of Liberty Profile

  • Edit server.xml file on each Liberty server to include additional SSO parameters
  • Location: [JAZZ_HOME]/server/liberty/servers/clm/server.xml
  • Scroll down until you find
    <webAppSecurity ssoRequiresSSL="true"/>
  • Add the following parameters (change example.com to your domain)
    <webAppSecurity singleSignonEnabled="true"/>
    <webAppSecurity ssoDomainNames="example.com" />
    <ltpa keysFileName="resources/security/ltpa.keys" keysPassword="WebAS" expiration="120" />
  • Save the changes

The default LTPA keys filename is ltpa.keys, password is WebAS and location is [JAZZ_HOME]/server/liberty/servers/clm/resources/security

Export/Import LTPA keys from Liberty

  • Export or copy the LTPA keys (ltpa.keys) from Liberty Profile hosting the JTS Application
  • Default Location: [JAZZ_HOME]/server/liberty/servers/clm/resources/security/ltpa.keys
  • Backup and rename the ltpa.keys on the Liberty Profiles hosting rest of the CLM applications
  • Import/Copy the ltpa.keys exported from the JTS server into all other profiles
  • If there is change in the name of the LTPA keys imported, modify the keysFileName parameter in the respective server.xml file
    <ltpa keysFileName="resources/security/<imported_ltpa_key_file_name>" keysPassword="WebAS" expiration="120" />

Scenario: CLM Distributed on WAS Full Profile and Liberty Profile

In this scenario we consider CLM is installed on WAS Full Profile and we are now including DCC/JRS which installed using the default Liberty Profile. Following is the procedure:

  1. Enable SSO on WAS Full Profile hosting CLM applications
  2. Export LTPA Keys from WAS Full Profile hosting the JTS application
  3. Enable SSO on Liberty Profile by adding additional parameters in server.xml
  4. Import/Replace LTPA keys to the Liberty Profile

Enable SSO on WAS Profile/s hosting CLM (JTS)

  • Login to the WebSphere Application Server Integration Solutions Console
  • Open the Global Security section from the Security menu in the left sidebar
  • In the Authentication section, expand Web and SIP Security
  • Click Single sign-on
  • Enter and make a note of the domain name (example.com)
  • Select Requires SSL
  • Click OK; then, click Save

Export LTPA Keys from WAS Profile hosting JTS

  • Login to the WebSphere Application Server Integration Solutions Console
  • Open the Global Security section from the Security menu in the left sidebar
  • Click LTPA under the Authentication section
  • Create a new password and confirm it (example WebAS)
  • Enter a name for the LTPA keys (example jtsltpa.keys)
  • Click Export Keys to export the keys to the file system.
  • Click OK; then, click Save.
  • Move these keys to the Liberty server hosting DCC/JRS

Import/Copy the LTPA keys to Liberty Profile

  • Copy the jtsltpa.keys file to the default location on Liberty Profile hosting DCC/JRS
  • Location: [JAZZ_HOME]/server/liberty/servers/clm/resources/security/

Enable SSO on the Liberty Profile

  • Edit server.xml file
  • Location: [JAZZ_HOME]/server/liberty/servers/clm/server.xml
  • Scroll down until you find
    <webAppSecurity ssoRequiresSSL="true"/>
  • Add the following parameters
    <webAppSecurity singleSignonEnabled="true"/>
    <webAppSecurity ssoDomainNames="example.com" />
    <ltpa keysFileName="resources/security/jtsltpa.keys" keysPassword="WebAS" expiration="120" />
  • Save the changes

General Guidelines for SSO Configurations with Liberty Profile

  • Make sure that each instance of WebSphere Liberty/Full Profile is using the same user registry (ideally LDAP). The user registry settings must be identical on all servers for SSO to work.
    • The LTPA keys file will include the LDAP (user registry) realm and it has to match with the Liberty profile LDAP configuration.
    • Example: com.ibm.websphere.ltpa.Realm=9.124.289.68\:389
    • If the IP Address is used in LDAP configurations, all Profiles should use the IP Address to connect to LDAP server.
  • The LTPA keys from the Profile hosting JTS application is the one that needs to be exported/imported into other profiles
  • If the Liberty Profiles are installed on 2 different filesystem types, example Windows and Linux, you may have to remove the hidden Windows characters post copying over the ltpa.keys on the Linux machine. Try one of the following:
    • Instead of copying the file over, edit the ltpa.keys file on the Windows machine using Notepad, copy the content and paste it to a new file on the Linux machine OR
    • If you unable to copy the contents and are forced to copy the file to the Linux machine, run dos2unix or similar commands on the file post copy

Related topics: Configure SSO on WebSphere Application Server Full Profile, Configure LDAP on Liberty Profile, CLM Distributed Setup on Liberty Profiles

External links: IBM

Additional contributors: DineshKumar, PaulEllis
Edit | Attach | Printable | Raw View | Backlinks: Web, All Webs | History: r10 < r9 < r8 < r7 < r6 | More topic actions
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Ideas, requests, problems regarding the Deployment wiki? Create a new task in the RTC Deployment wiki project