BMC ITSM Single Sign On Overview

Outline

Organisations which have deployed Enterprise wide IT applications, such as BMC ARS and the ITSM Suite, will often have the requirement to implement a Single Sign On solution to reduce the burden on IT support and to improve the end user experience.

 We have to accept that SSO is complex, different conventions for user name formats between systems, different repositories of Application and User credential means finding an out-of-the-box SSO solution is a challenge. It is a difficult but necessary balancing act of infrastructure platform and application support, customisations and security concerns.

There are a number of different architectural options when discussing SSO, the selection you make will affect the implementation and support of your solution. This is further complicated because SSO has a range of meanings. In a BMC Remedy context SSO will typically include an authentication against any system which is not Remedy.

This article describes the SSO architecture for Windows Active directory web clients of the BMC ARS Mid-Tier.  It also highlights feature support if a commercial solution is to be sought.

What is Single Sign-On (SSO)?

 Single Sign-On (SSO) is a means of access control of multiple related, but independent software systems. The process authenticates the user for all the applications they have been given rights to and eliminates further prompts when starting those applications during a particular session.

Benefits include:

• Reduce time spent re-entering passwords for the same identity
• Reduce password fatigue from different user name and password combinations
• Can support conventional authentication such as Windows credentials (i.e., username/password)
• Potential for ‘seamless’ or transparent logons where the client technology supports automated forwarding of ‘logged in user’ credentials
• Reduce IT costs due to lower number of IT help desk calls about passwords

 Context Diagram

The diagram below shows the system context at a high level

Sequence of Events

 The sequence of events for an SSO enabled login are:

1. User authenticates themselves into Windows on the Client.
2. The user navigates to Mid-Tier in their browser
3. A customized Mid-Tier login servlet extracts a user token from the HTTP request (if not present then it is requested as part of the authentication with the browser)
4. The browser sends a user token (no user interaction required)
5. The customized login servlet extracts the username and may perform username mapping if the Windows login name format does not exactly match the Remedy login name format
6. The Mid-Tier forms an ARS login request and calls ARS
7. ARS dispatches the login to the AREA plugin.
8. The AREA SSO plug-in validates the Mid-Tier IP and a shared key

Below is a UML sequence diagram that shows the order of events in detail.  The components (actors) are described in more detail in the section “BMC Remedy Enterprise SSO Architecture”

BMC Remedy Enterprise SSO Architecture

 The logical architecture diagram below depicts all the components involved when implementing an ARS Mid-Tier based SSO solution typically seen in BMC Enterprise deployments.   The items highlighted in yellow indicate components that would either be built in a bespoke solution or would be provided and configured when installing a commercial solution.

 The diagram also shows the numerous configuration touch points also described in the sections below.

Browser  

This would typically be IE v6 or later and it must treat the Mid-Tier as a trusted site in order for IE to seamlessly send the user token.  The token exchange between the browser and web server is done using Microsoft NTLMv2.

In a typical enterprise environment the rollout of the change could be implemented via a Group policy change centrally and pushed globally and not individually on each client.

It is possible to configure other browsers (e.g. Firefox) on Windows to do similar, but not via automatic rollout using group policy settings; such a change needs to be performed individually for each installed browser.

 Load Balancer

In enterprise deployment a load balancer typically sits between all of the clients and the web tier.  There are User token passing technologies that are stateless and introducing a load balancer has no significant impact to an SSO solution.  However, NTLM is stateful (i.e. Capable of maintaining the status of a process or transaction)and requires that the load balancer supports:

• Client IP forwarding
• Session affinity

 Failure to support these properties will result in needless re-authentication between the browser and the web tier.  The impact on performance depends on the number of users and concurrent requests.

Additionally, if the production architecture has load balancers between the Mid-Tier and the ARS servers then it is critical that the Mid-Tier server IP addresses are preserved.

Apache HTTPD

Although the Tomcat Java Application server is also an HTTP server it is recommended by Apache to front Tomcat by a dedicated HTTP server, such as Apache HTTPD. Without going into great detail this guidance is based on the dedicated HTTP server implementations being more robust to high volumes for serving static data and better handling of clients with sub-optimal session closedown behaviour.

Apache Tomcat          

Apache Tomcat is the J2EE WebApp container that hosts the Remedy Mid-Tier WebApp.

There is often no need to change the server configuration.  However, the Mid-Tier web app will need modifications.

Security Filter

This is an optional component and is not required if the user token is easily extracted from the HTTP headers. When dealing with NTLMv2 though, this component is a J2EE Servlet filter that challenges the browser client for the NTLM token – the NTLM challenge is a multi-step (and stateful) process that is defined in a protocol specification by Microsoft.  It is a non-trivial protocol that has been implemented by the likes of the commercial Jespa Java library discussed later.

 In a J2EE environment NTLMv2 can be implemented by the Jespa Component. ( http://ioplex.com/) Implementing the browser NTLM challenge in a Filter simplifies downstream processing in the custom Mid-Tier authentication servlet.

 Alternatively, if Microsoft IIS is used then it is possible to extract the username from the HTTP session and forward this on to Tomcat.  As NTLMv2 token extraction is alien to a Java stack it removes the reliance on a commercial 3^rd party library to perform the extraction.

 Mid-Tier Servlet  

This is the out-of-the-box Mid-Tier J2EE Servlet based entry point.  By default it will dispatch to the standard login page servlet.  To replace the standard Mid-Tier login process a custom login servlet can be specified in the Mid-Tier configuration file. [see the section named ' Configuring the User Name Alias’ in the BMC document “BMC Remedy Action Request System - Configuration Guide”]

 Custom Auth  

This bespoke or 3rd party component overrides the default Mid-Tier Authentication mechanism via a BMC extensibility mechanism. The component implements a BMC Remedy API and is responsible for extracting the username from the user token and obtaining the Mid-TierShared Key.  The Mid-Tier shared key is a common password shared between all Mid-tiers and the SSO plug-in that runs on the ARS server.  It is important that this shared key is stored encrypted.  A shared key is required because at no point is the user password transmitted.  In fact, in order to enable SSO within BMC Remedy the user must have no password defined in the User form.

 The username of the Active Directory user needs to correlate to the BMC Remedy login (or alias, see the BMC document  “Integrating BMC® Remedy® Action Request System® with Single Sign-On (SSO) Authentication Systems and Other Client-Side Login Intercept Technologies”)

 The actual Active Directory username can be obtained from the token in any one of 3 standard formats:

1. Username - only username, for example.: joeuser
2. Backslash - username + domain name separated by a symbol '\'
         For example.: example\joeuser
3. Principal - username + full domain name separated by a symbol '@'
         For example.: joeuser@example.com

It is at this point any custom transformations or other lookup can be performed, if required, in a bespoke implementation.

If a commercial SSO product is being used it is important to understand what transformations are supported at this step when considering how to map from Active Directory to BMC Remedy users.  Also bear in mind that there is username aliasing support in ARS too [see Integrating BMC® Remedy® Action Request System® with Single Sign-On (SSO) Authentication Systems and Other Client-Side Login Intercept Technologies]

 ARS  

A bespoke or commercial solution will need to provide an AREA plugin and therefore the ARS server config file (arg.cfg or ar.conf) will need to be modified accordingly. 

If the mapping from user token login names to Active Directory login names is required then it is possible to add an additional filed to the standard ARS User form to accomplish this. See "Configuring the User Name Alias" in the "ARS 7.5 Configuration guide.pdf".

 AREAHUB    

This OOTB component is a plugin that allows Remedy to support more than one authentication mechanism.  Note: ARS versions >= v7.6 may eventually support multiple AREA plugins.          

AREA,  AREASSO and the AREALDAP and will consult each one in turn when a user logs in.

 AREASSO  

This plug-in will be called by the ARS login mechanism any time an user attempt to authenticate, in either a bespoke or commercial solution this plug-in has 2 main tasks:

1. validates the request has come from a mid-tier IP and
2. validate the request has the correct shared key, by comparing what came from the CustAuth config to the shared key stored as part of the plugin configuration

If those 2 checks pass the user is authenticated and the plug-in simply responds with either a YES or NO.

It is important that this shared key is stored encrypted to ensure casual browsing of the filesystem does not expose this ‘global’ password.

NOTE: If a bespoke solution is to be built BMC provide an example C based SSO plug-in, search the support forums for: AREA_SSO_ALL_v206MT_v209AREA

 Any commercial solution will need to supply you with either a native or a Java plug-in; so you should check platforms and version support if it’s a native plug-in.

 However at the time of writing ARS only supports 1 AREA plug-in. This restriction is alleviated by the AREAHUB plug-in; as the area AREAHUB plug-in is native, you will not be able to use a Java based AREA SSO plug-in.  

 AREALDAP  

The out-of-the-box  BMC LDAP plug-in used to validate usernames and passwords again LDAP repositories (e.g. Microsoft Active Directory).  This may be required if, for example, only your MidTier users are using SSO and your User Tool users do not have the necessary client SSO DLL’s rolled out to the native clients.

 Active Directory

This component represents Microsoft Active Directory.  For a SSO solution based around NTLMv2 authentication and the Java JESPA library the Mid-tier component will need to be given its own AD ‘computer’ login as the Jespa implementation appears to Active Directory as a ‘machine’

Conclusion

As you can see from the myriad of configuration touch points and security concerns, implementing a bespoke SSO solution is a significant undertaking and a commercial option should be considered before going down that route.  Hopefully this technical dive into BMC ARS Mid-Tier SSO can help shine a light into a dark area and will help you when you need to design and/or troubleshoot the chosen implementation.

 Further Information

BMC have recently released BMC Single Sign-On product.  At the time of writing it does not support the transparent extraction of the Windows users’ credentials in the NTLM  token therefore they will get prompted for a login.  Support of such functionality is on the product roadmap.

If you would like to discuss your specific requirements, or have issues with your current SSO solution please feel free to contact us at info@alderstone.com