There are a number of places where APS and a User Management tool must integrate.
Out of the box, APS does provide the Help Desk Interface (See Help Desk Interface (APSAdmin).). However, this is not a full-function tool. It is really designed to simplify existing user management applications or to provide a tool to aid in APS testing.
APS provides a wealth of options for enabling and disabling user accounts. There are specific ways in which APS can disable accounts during processing and APS can recognize a large number of site-defined mechanisms. Any User Management application should recognize all of the reasons used by a site (including those configured for APS to use). These tools should be able to enable and disable accounts for those mechanisms in use at the site.
User passwords should always conform to the password content rules configured to APS in its Configuration File. This applies not only to ongoing user password changes, but to administrator password resets and initial passwords (during account registration) as well.
Normally, ongoing password changes are handled by the APS Change Password Interface (SmCPW) and CA highly recommends that it be used.
Out of the box, APS supports password change forms written in any language. It merely requires that the form POST to the Change Password Interface (SmCPW). Non-web based change password applications can call the APSAPI to perform this function.
Some sites want to put the change password fields onto another form, often the Change Profile form. This is usually very confusing to users. It is often better to put a "Change Password" link on a page rather than trying to incorporate both profile and password updates on the same form. Part of the problem is handling errors that might occur in one update or the other.
It is not possible for an application to perform all of its own password updates. The password history field is not accessible to applications; it is stored in encrypted, compressed format.
During user registration (account creation), the account's initial password should conform to the password content rules imposed at the site.
Initial registration creates some interesting problems for password validation:
Some sites modify their User Management tool to call the APSAPI's IsPasswordValid function to determine the initial password's validity, then just saves the password (possibly updating other APS attributes as well). Sites that do this need to be aware of the above limitations.
Another method, which has been used quite successfully, is to save the initial user record with a dummy (very random) password and a "state" flag, then call ChangePassword in the APSAPI to actually set the password. Once ChangePassword has been called successfully, the state is changed to enable the record. This bypasses the above limitations, but may leave your directory in an inconsistent state if the user abandons the process.
Another method is to set the initial password to some known (or random) value, then either give it to the user or use SiteMinder Auto-Login process (similar to how FPS can do it in the CONFIRM phase), then force the user to change their password immediately. If a site does this, it should use the smapsMustLoginBy attribute to ensure that this known password is used within a short timespan and the smapsImmediateChange attribute to cause APS to force the user to change this password (these attributes are described in Schema & Storage).
The Forgotten Password Services (FPS) functionality of APS can use information stored in the user record to interactively help a user reset their own password. However, APS provides no interface that can be used by the Users to maintain this information.
APS must be configured to tell it the name of the attribute(s) to use for this customer interaction and, for certain configurations, how that information is stored.
It is important that the user management application allow users to maintain this data. It is critical that the APS configuration correspond to the actual method used.
Some information on strategies is contained in How Do I: Get the FPS challenge questions into the User Directory?.
APSExpire processes events based on the value of smapsNextAction. Every time APS touches a user record, it ensures that the value of this field is accurate at that time. Some of the settings in the APS configuration file used to calculate this date may be dependent on attributes in the user record. For example:
Password Expiration={userType="Admin"} 30
Password Expiration=60
If the user's type is changed to or from Admin, the effective password expiration date changes and APS may need to update the value of smapsNextAction.
However, any User Management tool should not need to be aware of the conditions that APS uses to make these determinations.
There is a very simple way to handle this issue. Every time a user management tool modifies a user entry, it should delete the contents of smapsNextAction. APSExpire, scheduled to run daily, will recalculate the date on its next execution. Since user management is an extremely low volume operation, the impact on performance should be nominal.
|
Copyright © 2014 CA.
All rights reserved.
|
|