SSO Intergration by Danny Kellett

by Danny Kellett

The Remedy Action Request System provides hooks, or integration points, to implement Single Sign On (SSO) solutions. Understanding how to use these has taken me almost two years – rereading the various white papers listed below in addition to the installation/configuration guides many times.

My attempt to simplify it follows:

Remedy provides hooks for implementing SSO in two locations; I’m going to call them the front end (the user side), and the back end (the Remedy Application server side).

 

The user’s credentials – username, password, an optional Authorization string (often used to specify a Domain) are entered on the front end – the familiar Remedy login screen (login.jsp) for Mid-Tier users, or the Login dialog box on the Windows User Tool.

This can be replaced by writing a custom, alternate logic in Java (Remedy calls it “an implementation of the com.remedy.arsys.session.Authenticator” for Mid-Tier users – or a custom dll (written in C++) for Windows User Tool users.

 

Obviously the Mid-Tier implementation would be easier to deploy – requiring one install on a web server, as opposed to installing on many user’s computers locally.

 

Despite the painstakingly tedious explanations, all these replacments need to do is to capture a user name and password (and optionally, some more info – domain to login to, etc).

 

The back end – Remedy calls it the AREA plug-in –  is used to Authenticate and can be used to Authorize the user;

in other words, decide from the username and password if this is a legitimate Remedy user (authentication), and (optionally) what rights (licenses they have, groups they belong to, etc) (authorization).

 

Problem/challenges:

 

There are few good examples of the custom, alternate logic in Java.  I finally found AREA_SSO_ALL_v206MT_v209AREA.zip on the BMC Support site, I believe. This includes examples on how to use the config properties file that can be passed to the init() method and how to use the mid-tier logging.

 

Remedy provides a sample at the back of the white paper “Integrating BMC� Remedy� Action Request System� with Single Sign-On (SSO) Authentication Systems and Other Client-Side Login Intercept Technologies” but it has a notable error (*1).

 

The front end can be used with a Single Sign-On system which provides a user name, password and/or Authorization string (such as a Kerberos ticket) or login token), but the Remedy Windows User Tool until ARS 7.0p2 cannot pass an authorization string longer than 254 bytes. This is a problem as some SSO tokens can be up to 4096 bytes.

 

The DoD PKI CAC uses an X509 cert which provides a user name, but no password or authorization string or token. The format is LASTNAME.FIRSTNAME.M.1391489113 and as our Remedy user accounts don’t follow this, we’d need to change user names to conform everywhere including ticket data.

 

Again, there is no password to pull from the information available to the Mid-Tier at this point.

The common approaches appear to be:

1) pull password information for the account from another location than the Remedy User form (the passwords in the Remedy User form cannot be extracted directly, only verified against by the API).

2) Use the same password for all PKI users (if a valid (*3) DoD PKI CAC has been used, return the user name (or some variation) from the userCN , and the same password.

 

Approach #1 makes password maintenance more difficult – each user password now has to be updated in multiple locations when changed; the new locations tend to be insecure.

 

Approach #2 seems more manageable, if done correctly – hardcoding this password into the Java code would require recompiling the code if the password is ever changed. Using the config properties file to hold the password would simply require updating the password in that one place, and stopping and restarting the Mid-Tier service (or more properly, the Servlet container – ServletExec or Tomcat).

 

The user name can be manipulated to put the name parts in a more suitable order (FIRST.LAST) and drop the EDIPI, but name collisions could occur. A better approach  might be to lookup the full LASTNAME.FIRSTNAME.M.1391489113 against a list of Remedy User names and their PKI CAC alias. Using the Remedy ARS Java API to do this from a regular Remedy form has proved challenging but possible (tested and working in ARS 6.3).

 

Finding an elegant way to capture new users’ PKI CAC alias and associate them with their Remedy User name is still under development.


The back end

Remedy calls an authentication plugin implemented on the back end an “AR System External Authentication” plugin, or AREA plugin, for short.

Remedy emphasizes (by repeating several times) that a SSO implementation (the front end) must be matched or paired with an AREA plugin on the back end. When properly set up and configured, this plugin will be executed when a user name and password is received, and there is a corresponding user account in Remedy with a blank password entry.

(What might happen if a user name is received but the password is left blank needs to be tested – will the plugin be called, or will the plugin simply be skipped)

The plugin then attempts to verify the username and password in an external system, usually a network directory (such as an LDAP or Active Directory).

User Fixed licenses, or Remedy Application licenses, cannot be supplied by such an external system, so some users must have their information kept in Remedy.

A working AREA plugin is supplied by Remedy – an AREA LDAP plugin, but not its source code. A sample source code is provided as a skeleton, and a usable plugin can be created with it, though not all the features are illustrated by the sample.

In our case, no such external system exists.

One approach is to create a plugin that dead-ends – perhaps only verifies that the password received (supplied, one hopes, by the SSO implementation on the front end) is the one expected (eg, use the same password for all SSO users). With no external system to hold other authorization information for that user (licenses they have, groups they belong to, etc), none can be provided by the plugin so it returns immediately. Remedy and the plugin must then be configured so all that other information is provided by the standard Remedy processes from the standard Remedy User form.

This has been tested and works (in ARS6.3).

While this can be done, it will be easier (less maintenance) to simply not use an AREA plugin at all; simply set the password for each user to be the password that will be supplied by the front end (custom, alternate logic in Java ) on seeing a valid CAC. The other authorization information will be provided by the standard Remedy processes from the standard Remedy User form, as usual.

This has been tested and works (in ARS6.3).

One challenge not yet overcome is how to encrypt the password(s) kept in the config properties file for the (custom, alternate logic in Java on the) front end so it can still be used by the initialization code (in other words, how to accomplish what Remedy does several places: passwords in config files are entered in plain text, but encrypted and written back to the file encrypted, the first time the application runs, so the passwords don’t remain in plain text long.

footnotes:

(*1) The sample Java authenticator returns a “NULL” if the user info is not found, rather than the required object UserCredentials with null parameters. This causes the login to hang. It is supposed to cause the default Authenticator to fire, presenting the usual Login page (login.jsp).

To fix this, change the final “return null;” to “return new UserCredentials(null, null, null);”

 

(*2) The CN in a DoD PKI certificate contains last name, first name, middle initial or middle name and a unique identifier. In the case of CAC-based certificates, the unique identifier will be the Electronic Data Interchange Personal Identifier (EDIPI) value from the certificate holder�s DEERS data.

 

(*3) a valid DOD PKI CAC – assumes that the web server has been set to REQUIRE user certs; non-DOD Root Certs have been removed from the Trusted Certs repositories for the web server, the web server Certificate Trust List (CTL) has been set to only allow DOD-issued certs, and a working Certificate Revocation checking system is in place – Tumbleweed Validator using OCSP, or something similar.

Resources

ARSList ARchive at GMANE

Integrating ARSystem with Single Sign-On (SSO) authentication systems – March 1, 2005 – written for ARS v 6.3

Integrating BMC Remedy Action Request System with Single Sign-On (SSO) Authentication Systems and Other Client-Side Login Intercept Technologies – July 2006, written for ARS up to version 7.0

 

Integrating with Plug-ins and Third-Party Products – Aug 2007, written for ARS version 7.1.00

C-API Ref or Guide for each version

The front end can be used with a Single Sign-On system which provides a user name, password and/or Authorization string (such as a Kerberos ticket) or login token), but the Remedy Windows User Tool until ARS 7.0p2 cannot pass an authorization string longer than 254 bytes. This is a problem as some SSO tokens can be up to 4096 bytes.

Just as a foot note. There is a bug SW00324515, on successful login, if there is more than 31 charaters in the authentication string, then the user tool crashes.

 

http://www.javasystemsolutions.com/jss/ssoplugin

 

Just a quick note to say that the JSS SSO Plugin v3.3 will fully support X509 client side certs out of the box, mapping the certificate name with an entry in the User form, and hence is the ideal tool for DoD SSO solutions for the AR System.