Advanced Password Services (APS) Guide › Best Practices for Storing Legacy/Back-End Credentials

Best Practices for Storing Legacy/Back-End Credentials

This section contains the following topics:

Executive Summary

SiteMinder is often used to protect legacy or database applications that require their own user credentials. These applications are usually front-ended by a web application that must log in (authenticate) to the legacy application, behind the scenes, using these user credentials.

As SiteMinder and other Single Sign-on (SSO) solutions have been implemented within large organizations for large commercial application, tight integration has been undertaken by CA and those applications' vendors. When such integration is available, SSO can be a boon to productivity and reliability.

When such integration is not yet available or is not possible, application developers and integrators sometimes request that SiteMinder supply a user's LDAP credentials (user id and password) to their application so that they can perform this login. This is unnecessary and, from the security and data maintenance standpoints, this is a very bad idea for a number of reasons:

If one application becomes compromised, all applications at the site become compromised.
Due to architectural limitations of SiteMinder, all protected pages in the original authentication realm may receive the password (all pages receive the user id anyway). Note the word "may", SiteMinder only guarantees that the first page receives the value; others might as well, depending on a large number of factors. If a user logs into one realm, it is not available to other realms unless stored elsewhere, such as within a custom cookie or session storage.
Password policies must conform to a "least common denominator" format. That is, password construction must conform to the limitations of the simplest application. For example, if an application can only handle 6 character, case-insensitive passwords, then the user's site password can only be subject to that limitation.
Password synchronization is very non-robust and difficult to implement. When the user's site password changes, the change must be replicated to all back-end systems. This operation is very error prone, due to outages. As additional applications that require this service are installed, performance (during password change) suffers as well.
SiteMinder authentication will require a password, since this password will be used elsewhere on the site. In other words, all of the other authentication options, such as tokens and certificates, will be unavailable to the site.

A more secure, robust and reliable solution meeting application integration requirements has been developed and deployed.

Essentially, the legacy application requires a set of credentials, not the set of credentials. The site should store the alternative credentials in the user's directory entry, encrypted, and supply them to the single application only. This has several significant advantages:

Each application has its own unique password (and, possibly, user id). If one application becomes compromised, no other application is at risk.
Each application can receive its own credentials when it needs them, regardless of how authentication took place: which realm or what authentication scheme was used.
Each application's credentials can be subject to its own format restrictions.
No password synchronization is required.
Since SiteMinder authentication does not use the same credentials as the applications, the site may use any of the many authentication options that SiteMinder supports, such as certificates, without impacting any applications whatsoever. In addition, the site may "mix and match", meaning that different users may use different authentication methods. These methods may be implemented later, as the site matures and requirements change, without impact.
Application passwords can be changed by a background process as needed. Users need not know that their back-end credentials have even changed.

This solution does not work in all cases. We have encountered at least one site where it does not work. That site had the additional requirement that the legacy application be accessible internally using a thick client. When the employees authenticated using the thick client, the user was required to entire the credentials. Our customer wanted those credentials to be the same as those used for the web site. That was a special case, however, and should not be considered typical.

Details

There are several possible implementations. This document describes the idea and only one possible implementation. The implementation described here was selected because it scales well and because it can be used on an incomplete site. That is, as new applications are SiteMinder enabled at a site, little additional programming and no directory schema changes are required.

The basic solution requires that the credentials for a specific application be stored in the User's Directory Entry. For the purposes of this discussion, let us assume that the User Directory is an LDAP directory. It does not have to be; it could be any SiteMinder-supported User Directory, with the exception of Windows NT Domains, since there is no place in an NT Domain entry to store additional credentials and the schema cannot be extended.

The credentials for a given application should be encrypted. It is up to the application to decide how and to do so. Encryption keys should be different for each application so that if the keys are compromised, they do not compromise another application at the site.

All credentials for all applications should be stored in a single, multi-valued attribute in the user's entry, prefixed by the application name. For example, a record might contain the following entries:

HRAPP=UhdNoiHhs4hjkj
CRMAPP=(JH)h9kdYhUKK-

Using a tool such as CA Professional Service's SmWalker (and its KeyValue function), you can retrieve the value associated with a given key as the result of an Active Expression. The Human Resources application can then be passed the (encrypted) credentials as a header variable. Note that the credentials remain encrypted; the application itself is responsible for decrypting them, if required.

Alternatively, each application's credentials can be stored in individual user attributes, each specific to the application. While this simplifies updating application credentials (see next section) and retrieving the value for the application (no active expression is needed), this does not scale. As new applications are added to the system, additional attributes are needed, resulting in schema changes and possible data conversions, depending on the underlying user directory.

Updating Application Credentials

The application credentials can and should be changed on a regular basis. However, users need not know that this is being done, nor do they need to know what the new credentials are. For that matter, no human needs to know them and, depending on the back-end system, they may not even be human-readable.

Each application can change their credentials independently, on their own cycle (frequency).

To change the credentials requires a batch job (e.g. cron on Solaris, At on Windows) that generates the new credentials, updates the back-end system and updates the directory entry for the user. Without cross-database transactions this can be error-prone; however, the process can be rerun and restarted without user notification or affect. It is important that these scheduled tasks not run concurrently, as they could end up interfering with each other. For example, if two separate jobs attempted to update the same user's record simultaneously, some data loss may occur.

The generator will need to encrypt the value in a way compatible with the data consumer.

If credentials are stored as multiple values in a user's entry, then care must be taken to preserve the credentials of other applications. Fortunately, if code is written well, these other values cannot be lost, since, while LDAP does not support transactions, it does guarantee "all or nothing" updates, meaning that all values for the attribute will be replaced or none of them will.

Updating User Credentials

Users can change their directory passwords (used by SiteMinder) at any time without any impact. As additional applications are added to the site, even if they require legacy credentials, they do not add overhead to the change process (since there is no synchronization). Applications do not care when the user's base password changes.

Additional Advantages

Password Format & Lifetime

Because the user's base password is separate from application credentials, it can be forced to conform to any Password Policies that the site sees fit to implement. Password Services or Advanced Password Services can require very complex formats and/or lifetimes with no impact on legacy applications.

Alternative Authentication Schemes

The credentials used by SiteMinder and the applications need not even be the same type. Whereas the application(s) need passwords, a site could use any of the alternate authentication mechanisms that SiteMinder supports, including token cards and certificates.

Note that while an initial implementation at a site may not require this level of security, it may become an issue later, as more applications, perhaps requiring a greater level of security, are integrated into the site.

Summary

Application designers often ask for SiteMinder to supply a user's credentials (user id and password) to their application so that the application can perform a login against a back-end system.

This document has presented an alternative design to store a separate set of credentials for each application, encrypted, and provide those credentials only to that application as needed.