Caching Internet password changes for SSO

When Web users change their Internet passwords, the IBM® Domino® HTTP server remembers the new Internet password in its cache. Caching is required because it can take some time for the password change to take effect, as the change must be processed by the Domino® administration server and replicated throughout the Domino® environment.

Caching of the user's new password allows the HTTP server to immediately recognize the user's new Internet password and accept it for login, even though the password change information may not be finished replicating in the Domino® environment.

Password changes are cached when the HTTP server is configured for SSO. This means that users can log in to an SSO environment, change their Internet password, log out, and log in again using the new Internet password while the change is still replicating throughout the system.

Caching location and duration

The user's cached new Internet password is only stored on the HTTP server where the password change was requested. Other servers in the SSO environment do not have access to this cached information; therefore if the user is prompted for a password by any of these other servers, the user may have to supply the old password rather than the new one. On servers that do not have the cached information, the user must provide the password that matches password information found by that server in the directory.

Note that for SSO users, initial log in provides access to the entire SSO environment. Therefore, users will have no problem if all log in activity can be done consistently at the server that cached the new password. The user can attempt to access a URL on the target server and be prompted for a password by that server, rather than opting to supply a password to a server that does not have the cached new password.

By default, the cached new Internet password is honored by the HTTP server for 48 hours. The length of time that the information is cached can be configured using the server NOTES.INI parameter HTTP_PWD_CHANGE_CACHE_HOURS. Once the information times out from the cache, the user can only login using the password that can be verified against the password information found by the server in the Domino® Directory.

Note: If the HTTP server is restarted, the cached password information will be discarded. Again, the user must provide the password that matches password information found by the server in the Domino® Directory.

Password caching and SSO login name

Use of the new password relies on the HTTP server finding the user in its cache. In order for the cached new Internet password to work, the user must login with the same spelling of the user name that the user logged in as before. For example, if the user logged in previously as "John Doe" when changing the password, the user can't login later with the new password and a valid other name such as "jdoe". The user must login with the new password using "John Doe" as before.

Best practices for SSO password caching

You should instruct your users to follow these steps for best results:

Log in to a Domino® HTTP server that supports SSO password caching.
Submit the Internet password change request by invoking the ChangePassword URL on the server. For example:
```
http://myserver.mycompany.com/names.nsf?changepassword) 
```

Note: IBM® iNotes® users can also use the Change Password button.

It may take some time for the password change to take effect on all the servers in the SSO environment. During this time, whenever users login, they should always log in first to the server where they requested the password change, using the same user login name as before and providing the new password.

If for some reason, a user's new password is not accepted on the server to which the password change was requested, the user should try again using the new password and their user name in distinguished name format (for example, John Doe/MyCompany).

Troubleshooting Internet password caching for SSO

The following list describes some common problems with setting up and using Internet password caching in an SSO environment.

User provides alternate spelling of name. Suppose the user does attempt to login as "jdoe" (after having logged in previously as "John Doe" and requested a password change). The user "jdoe" must provide the password that matches the password information in the directory, which might be the user's old password.
User initially logs-in to one SSO server, then requests password change on another server. When a user logs in to an SSO server, the user's browser receives an SSO token that allows him to access other servers in the configuration without having to login again. If the user then accesses a second server on which the password change is requested, this second server receives the user's SSO token and knows the user only by what is stored in that token. The second server is not aware of the name the user provided at login time.
If the user changes his password on the second server, the second server will cache the new Internet password for this user. In this case, the server does not have the user's login name, because the user logged in somewhere else first. The second server remembers the new password, but remembers that the new password applies to the user with the corresponding Domino® distinguished name. If the user logs out and later wants to login directly to this server with the new Internet password, the user must provide their distinguished name (for example John Doe/MyCompany).
The user's initial login authentication is completed by a DSAPI filter library. The HTTP server can be extended by the addition of one or more DSAPI filter libraries, which can be configured to require the HTTP server to pass authentication requests to the DSAPI libraries. A DSAPI library may only control a subset of the server URLs. If the URL that the user enters to access a server is associated with a particular DSAPI library; the user's login name (e.g. "John Doe") and password may be passed to the DSAPI library so that this library can decide whether the user can be authenticated. When authentication is approved, the DSAPI library passes back to the HTTP server the name of the user that has just been authenticated. Generally the name that is passed to the HTTP server is a Domino® distinguished name. This name is what the user is known by to the HTTP server, that is to say that the HTTP server may not know the user as "John Doe", but instead knows the user as "John Doe/MyCompany". After the user has been authenticated by a DSAPI filter library at login, user might then proceed to request a password change.
Note: The password change information about the requested new password is not passed to any DSAPI library, and while a password change affects the Domino® Directory information for this user, the password change likely does not change the DSAPI library's notion of the user's password.
When a user requests a password change, the HTTP server caches the new Internet password for this user, using the name it knows for this user. If the user logs out and later wants to login with the new password to a URL on the server not associated with the DSAPI library, the HTTP server will attempt to verify the user's name and password. If the password change to the directory is still pending, the HTTP server can verify the user's new password only if it is found in the cache. In order to find the user in the cache, the user must provide the name that matches the name in the cache, namely, the one passed from DSAPI, for example "CN=John Doe/O=MyCompany".