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.
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.
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.
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.
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.
|
Copyright © 2014 CA.
All rights reserved.
|
|