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

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.