Configuring Single Sign On (SSO) from NetIQ Access Manager and LiveTime ITSM

Background

LiveTime Service Manager is a complete IT service management solution that can be used for 11 ITIL processes from Service Request Management through to Change and Release Management. It provides various end-user roles (customers, Supervisors, Technician, Partner, etc) who can access the web based portal & manage service requests.

LiveTime Service Manager includes support for SAML based Single Sign-On (SSO). With this addition of SAML support LiveTime can streamline end user’s experience without forcing the user to re-authenticate at application. Access Manager is a product which facilitates secure access to LiveTime & can leverage the SAML based SSO support in Service Manager to provide seamless experience to end users.

Service Manager allows SSO from Open Source solutions such as Shibboleth, JOSSO, OpenSSO etc as well as commercial vendors like NetIQ Access Manager, CA Siteminder, Oracle Identity Manager etc. In this article we will focus on configuration for SAML based SSO from NetIQ Access Manager to LiveTime Service Manager.

Glossary of Terms

SAML – Secure Assertion Markup Language
SSO – Single Sign On
NAM – NetIQ Access Manager
NAM-IDP – NAM Identity Provider
NAM-AG – NAM Access Gateway

Understanding SSO Configuration

Service Manager manages HTTP session headers from the provider (web access gateway) to enable seamless access for user to application. The Login session is managed by Identity Provider (IdP) and the access to resource is managed by Service Provider (SP). This session information & associated user data is then filtered down to the protected application which uses the given data for granting access to user & bypass authentication.

For the above scenario in this document, Identity Provider is NAM-IDP, Service Provider is NAM-AG & the protected application is LiveTime Service Manager. Configuration for SSO in LiveTime is located at (Setup > Authentication > SSO) as shown in Figure-1. There are three configurations to enable SSO, all of which are mandatory (as explained in following table):

Parameter Description
Session ID This is the name of HTTP header passed to NSD which contains Session ID for the logged in user.
Username Name of the HTTP header which contain login name of the user attempting to access NSD
Email Name of the HTTP header which contain email of the user attempting to access NSD. This email value is used to validate the username.

Preparations for Configuration

SSO Setup Screen with SAML2

Figure 1:SSO Setup Screen with SAML2

This document specifically focuses on SAML based SSO related configuration, so it is assumed that other parts of setup are already available & few key configurations are already done before we proceed. These are few per-requisites before we proceed with further configuration:

  • LiveTime Service Manager is installed & configured with appropriate user store.
  • NetIQ Access Manager is installed & configured with appropriate user store.
  • Both LiveTime & NAM share the same user store OR the user credentials/data is synced among the both user stores.
  • Basic reverse proxy service is configured on NAM for LiveTime (LiveTIme is added as path based OR domain based protected resource).

Configuring NAM for SAML based SSO

As discussed above it is assumed that LiveTime has been configured as protected resource (path based OR domain based). The next step is to configure an Identity Injection policy which injects appropriate headers into the HTTP requests to LiveTime as required for SAML based SSO. Following are the steps to configure the Identity Injection policy for LiveTime.

Steps to Configure Identity Injection Policy for LiveTime

  1. Go to iManager (Access Manager > Policies) & add a new Policy of type – “Access Gateway: Identity Injection”
  2. On the “Edit Rule” page provide description for your policy (Optional)
  3. Create “New” action & select – “Inject Into Custom Header”. In the details select value as “Credential Profile”, then select “SAML Credentials” > “SAML Assertion” (as shown in Figure-2).

    NAM Identity Injection SAML

    Figure 2: NAM Identity Injection Policy – SAML Assertion

  4. Create “New” action & select – “Inject Into Custom Header”. In the details select value as “Credential Profile”, then select “LDAP Credentials” > “LDAP User Name” (as shown in Figure-3).

    NAM Identity Injection LDAP

    Figure 3: NAM Identity Injection Policy – LDAP User Name

  5. Create “New” action & select – “Inject Into Custom Header”. In the details select value as “LDAP Attribute”, then select “mail” (as shown in Figure-4).

    NAM Identity Injection email

    Figure 4: NAM Identity Injection Policy – User eMail

  6. Once all the above configuration are done the identity injection policy will look as shown in Figure-5.

    NAM Identity Injection SSO

    Figure 5: NAM Identity Injection Policy for SAML SSO to NSD

  7. Enable this Identity Injection policy for the protected resource configured for LiveTime.

Configuring LiveTime for SSO

Once we are done with NAM configuration now the setup is ready for enabling LiveTime configuration. It is recommended (not mandatory) that Identity Injection to LiveTime is already enabled & the administrator can verify the HTTP headers received by LiveTime while configuring SSO.

Following are steps to configure SSO on LiveTime:

  1. Login to LiveTime as Administrator & open SSO configuration at (Setup > Authentication > SSO)
  2. Edit the configuration & Select “On” for ‘Active’ field.
  3. If you have login to LiveTime through NAM with Identity Injection policy enabled – Click on the icon to review HTTP headers passed through Access Gateway (NAM).
  4. Configure HTTP header name for SAML Assertion as ‘Session ID’ (e.g. ‘samlsession’ as shown in Figure-5)
  5. Configure HTTP header name for current logged in user as ‘Username’ (e.g. ‘username’ as shown in Figure-5)
  6. Configure HTTP header name for user email as ‘Email’ (e.g. ‘useremail’ as shown in Figure-5)
  7. Once all the above configuration are done the identity injection policy will look as shown in Figure-6.
  8. Save the configuration & validate SSO through NAM.

    SAML SSO NAM HTTP Headers

    Figure 6: LiveTime Configuration for SAML SSO with injected NAM HTTP Headers

Configuration for Simultaneous Logout

In this scenario ‘Simultaneous Logout’ is the ability to logoff from NAM session whenever user clicks Logout on LiveTime portal. LiveTime Service Manager does not have specific configuration to enable Simultaneous Logout with web access gateways (for example this configuration is available for applications like GroupWise, Vibe etc). So in order to enable simultaneous logout for LiveTime one must configure Form Fill policy as follows.

  1. Create a new FormFill policy for LiveTime simultaneous logout.
  2. On the “Edit Policy” page provide description for your policy (Optional)
  3. Create ‘New’ action & select – Form Login Failure
  4. In “Page Matching Criteria” field configure following text from LiveTime logout page – “Your session has ended. Please use the button below to login again.”
  5. In “Redirect to URL” field configure the Logout URL for your setup e.g. https://mynam.com/AGLogout
  6. Once all the above configuration are done the Form Fill policy will look as shown in Figure-7.

    NAM Fill Policy

    Figure 7: NAM Form Fill Policy for Simultaneous Logout from LiveTime-NAM

  7. Enable this Form Fill policy for the protected resource configured for LiveTime.

Conclusion

This article demonstrates that it is possible to leverage SAML based SSO support on LiveTime Service Manager to allow SSO configuration using NetIQ Access Manager.

Enabling SSL with LiveTime or Novell Service Desk Installer

In order to activate the HTTPS protocol on LiveTime or Novell Service Desk after using the Installer, you first need create a public and private key pair to be used for encryption. You can use keytool command to generate a key pair. The following sequence of commands show you how to do it:

shell> keytool -genkey -alias livetime -keyalg RSA

keytool -genkey -alias livetime -keyalg RSA
Enter keystore password:  changeit
Re-enter new password:
What is your first and last name?
  [Unknown]:  localhost
What is the name of your organizational unit?
  [Unknown]:  MIS
What is the name of your organization?
  [Unknown]:  LiveTime Software
What is the name of your City or Locality?
  [Unknown]:  Newport Beach
What is the name of your State or Province?
  [Unknown]:  California
What is the two-letter country code for this unit?
  [Unknown]:  US
Is CN=localhost, OU=MIS, O=LiveTime Software, L=Newport Beach, ST=California, C=US correct?
  [no]:  yes

Enter key password for
	(RETURN if same as keystore password):
Re-enter new password:

Note:

  • Type password for keystore, which is “changeit”.
  • [firstname and lastname] give the fully qualified host name. In this project, you will have to use localhost becuase this is the machine name that you use to access the Tomcat server from the VM.
  • You need type some information about your organization, location, etc. (You can make it up as you like)

When you execute the above command, keytool will generate a public key and private key pair and store it to your keystore file. More precisely, the generated public key is stored in the form of certificate. A certificate is nothing more than a statement like “the name of this host is localhost and its public key is XX:XX:…:XX:XX. This certificate is valid from XX/XX/XX until XX/XX/XX”. All certificates need to be signed by a certificate authority (CA), but since you have not asked any third party CA to sign your certificate, it has been signed “by itself” at this point. This type of certificate is often referred to as a “self-signed certificate”.

If you are running windows you will need to copy the .keystore file to the root of your hard drive.

Enable SSL on LiveTime

Now that your key pair is ready, the final step is to change your $LIVETIME_HOME/Server/conf/server.xml file to enable the SSL connection, An exampleelement for an SSL connector is already included in the default server.xml file, which looks something like this:


<!-- Define a SSL HTTP/1.1 Connector on port 8443 -->
    <!-- Delete
    <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" />
    --> Delete

Remove the comment around node to enable SSL.

Windows users will also need to remove the $LIVETIME_HOME/Server/bin/tcnative-1.dll file in order to process SSL requests.

Restart LiveTime or Novell Service Desk

Use the System Preference on MacOS X or Start Menu Item on Windows to restart the application.

LiveTime MacOS X

Test HTTPS

You should now be able to see the application on HTTPS byusing the following URL:

https://localhost:8443

Note that most browsers will provide a warning when hitting this URL becuase it has been self signed. You can simply ignore this warning and proceed by adding a “security exception”.

Install a trusted certificate

Next let’s get your certificate signed by a trusted CA to avoid this warning in future. The first step to obtaining a trusted certificate (your certificate signed by one of the trusted CA) is to create the “certificate signing request”.

shell> keytool -certreq -keyalg RSA -alias tomcat -file certreq.txt

If you run the above command, you will see that a request file, named certreq.txt, is generated in your current directory. A request file is nothing more than your public key together with some information about your site (like the fully qualified name of your site and other information that you provided when you created your public key/private key pair).

Next you we need to obtain the trusted certificate from the CA by sending this file to the provider. Once authorized you will receive the certificate which you will then install. Now that you have a trusted certificate, import it to your keystore, so that the LiveTime server can use it.

shell> keytool -import -alias tomcat -file <downloaded, signed cert file>

Now you can restart the LiveTime application as before and you can open the same URL as you did before, but this time you will not get the security exception.

You are now running under SSL.