Previous Topic: Verify FormsNext Topic: APS Application Programming Interface

Advanced Password Services (APS) Guide › Forgotten Password (FPS) Interface (Forgot) › Change Pages

Change Pages

At the end of the verify phase, FPS is certain of the identity of the user. Some sites may allow the user to change their password to a known value at this time. This is one of the big potential security holes in your site. If this functionality is desired, the Change forms (defined in the Change section) will be used. If change password is not desired, the Change section should be omitted from the APS configuration file.

URL

This URL is the form used to request the password change from the user. It requires exactly two input fields called NewPassword and VerifyPassword. They should be password fields.

As usual, the form posts to the FORGOT stub.

Just like the Identify and Verify forms, this could very simply be an HTML form. However, since FPS will return the user to this URL when there is a problem with password content (the error message, localized, will be passed as the query string), a server-side scripting language is desirable in order to process (display) a query string, if one exists.

It is especially important that this page expire and prevent reviewing/reposting using the BACK button. Without taking these preventative measures, after a user has successfully used FPS, another user may be able to press the BACK button to change the password again.

Timeout URL

This setting specifies a page to send the user to when the form is not submitted within the period specified by the Timeout setting ("You did not answer quickly enough").

This is a terminal condition (FPS processing terminates - the user cannot use FPS at this time).

This could be a static HTML page. It could also be Forgot itself (or an intervening page with a message) so that the user can restart the FPS process.

The user is not locked out of FPS.

Confirm Pages

There are several different strategies to finishing the FPS process, all configured using the Confirm section of the APS configuration file.

One way to do confirmation at the end of the FPS process is to send the information to the user via email. If this is to be done, the confirm page should say something like "The information that you requested has been sent to the email addressuser@somesite.com".

To pass information to a custom Confirm page, specify the Initial setting in the Confirm section. Unlike the similar keyword in the Verify section, this information will not be passed in a cookie (there would be no way to destroy the cookie when weíre done with it). Instead, the information is passed to the Confirm URL in its query string (in exactly the same format as the cookie).

To pass the new password, use password in the Initial setting instead of userPassword (the actual LDAP attribute name), since userPassword will be encrypted (actually, hashed).

CA strongly recommends that the user id and password not be presented to the user in the same medium. Send one via mail and display the other.

Another option is to display HalfPassword1 on the custom page and send HalfPassword2 via email. These macros return, in clear text, either the first half or the second half of the user's password. Of course, either the mail or the custom page will have to instruct the user that the two halves must be put together before using.

If you do not wish this information appear in the query string, put the ultimate target URL in the confirm URL setting and put an asterisk in front of it. FPS will dynamically build a page to display the confirmation message (and the initial data will not be placed in the query string). The message will come from the translation for CONFIRM_MESSAGE (the title of the page coming from CONFIRM_TITLE). Macros will be replaced in the confirmation message, including Password, uid, HalfPassword1, HalfPassword2, and OneShotPassword.

It is possible to automatically log the user in at the completion of the process. There are several ways to do this. The easiest (but least secure) way to do it, that works with all releases of SiteMinder, is to take the Initial information, pre-populate input fields on a login form, and POST to an FCC. This is not very secure, in that the password appears not only in the query string, but in the initial values for the input fields as well. By pressing the BACK button and View Source, this information is very visible, even in an SSL environment. The exception would be to use OneShotPasswords.

Instead of using the "real" password, use the OneShotPassword instead. FPS creats a single-use password when the macro "OneShotPassword" is referenced in a mail file or in an initial setting for the confirmation page. The OneShotPassword requires special set up to use (See Authentication Scheme.) but it is more secure than using a multiple use password, even if you allow the user to select their own password (since you will never show the selected password).

SiteMinder FCCís support a special keyword called "@loginonget" which allows an fcc to be used to authenticate a user without displaying a form (simply a redirect). FPS fully supports this option, using the following steps:

  1. On your Web Server, create a file called oneshotfps.fcc. This file should be in your fcc directory, usually <SiteMinder Web Agent home directory>/samples/forms.

    This file should contain exactly the following text:

    @target=/FPSOneShot/DoesNotExist
@username=%uid%
@password=%OneShotPassword%
@loginonget
  2. In APS.cfg, in the [FPS-Confirm] section, place the lines: 
    URL=/siteminderagent/forms/oneshotfps.fcc
Initial=uid;OneShotPassword

    The actual URL to the FCC should be used.

  3. In the SiteMinder Policy Server User Interface, create an authentication scheme called "FPS One Shot" as directed on Unsupported "Page" Cross-Reference (no params, library="smaps").
  4. Create a realm called "FPS One Shot". Its filter is /FPSOneShot/ on the correct agent(s). The Authentication Scheme is the one created above ("FPS One Shot".)
  5. Create a rule under the "FPS One Shot" Realm called "FPS One Shot Trigger". The filter is DoesNotExist and the action is GET.
  6. Create a rule under the "FPS One Shot" Realm called "FPS One Shot Redirect". This is an OnAuthAccept rule.
  7. Create a response called "FPS One Shot Redirect". This response should have a single OnAcceptRedirect value of the real URL where the user should end up (typically your site's home page).
  8. Create a policy called "FPS One Shot". The Users tab should be all users allowed to use One Shot (ODBC and LDAP only). Attach BOTH rules created above. Attach the "FPS One Shot Redirect" response to the "FPS One Shot Redirect" rule.

If different users are to go to different ultimate targets, then different policies can be used for the "FPS One Shot Redirect" rule, for different users, with different responses controlling the actual URL.

Error Pages

If FPS encounters any error during processing for which there is no specific setting to handle, the user will be redirected to the page identified as the Error URL. Most errors are of two types:

Actual error text will passed to the page in the query string (URL encoded).

Generally, the message should be displayed to the user, and the user should be referred to the Help Desk.

Support personnel can obtain additional information about the error from the Console Logs.

Mail Error Pages

The Mail URL page exists only to prevent a problem where we are unable to send mail to the user that is required for the FPS process. The cause of the failure will be one of the following:

Note that a non-existent target address will not cause a failure in any case, since it wonít be detected at send time.

This URL should typically just display an internal error-style message, referring the user to the Help Desk.