Self-service password reset is defined as any process or technology that allows users who have either forgotten their password or triggered an intruder lockout, to authenticate with an alternate factor, and repair their own problem, without calling the help desk. It is a common feature in identity management software.
Typically users who have forgotten their password launch a self-service application from an extension to their workstation login prompt, using their own or another user's web browser, or through a telephone call. Users establish their identity, without using their forgotten or disabled password, by answering a series of personal questions, using a hardware authentication token, and responding to a password notification e-mail. Users can then either specify a new, unlocked password, or ask that a randomly generated one be provided. OpenSSO currently provides the option of sending a random password after answering the personal questions correctly.
OpenSSO provides a feature-rich web application that can be customized to let the end users reset their forgotten password. An administrator can automatically redirect their login failed users to this page in order to enable the users to reset their password without the administrator's intervention.
The OpenSSO password reset application will be deployed as part of the services deployment. Unlike the Access Manager the password reset application is embedded as part of the OpenSSO web application itself, no special deployment task is required to get the application. Before starting off with the password reset application configuration, the following prerequisites must be met:
- OpenSSO deployed and configured with Access Manager Repository plugin or a Supported Data Store
- Valid e-mail address for the users who want their password to be reset through this service
- Valid SMTP service host and port configured in the OpenSSO Server
- User Data store must be Sun Directory Server Enterprise Edition or OpenDS
You need to also pay attention to update the amPasswordResetModuleMsgs_en.properties (or the appropriate locale) file to provide a valid name for the property lockOutE-mailFrom, as the default value<Password-Administrator> will cause sendmail problems.
The OpenSSO password reset service can be configured to work in association with the backend data stores' password policy controls, and so it will be honored by OpenSSO. As I have described earlier, the password reset application can be configured with the Sun Directory Server or OpenDS besides the Access Manager Repository plugin. In this section I am going to use OpenDS-based configuration, so that others can easily replicate the procedure in their environment as OpenDS is freely available. You can find more details on these user data stores in Chapter 8.
Password reset is one of the services that can be assigned for each realm. In order to start the process, first select the password reset service for the realm and provide necessary details for the service attribute as shown in the following screenshot. It is implicit that the OpenSSO server will be configured with a data store that is pointing to the OpenDS server. Refer to Chapter 8 for learning about supported identity stores.
To assign the password reset service, log in as top level administrative user, and assign the service as shown in the following screenshot:
Once the service is selected, you will be asked a series of questions pertaining to the password reset service in the next screen, including the account lockout feature that will be applied when the end user enters an incorrect answer. This is analogous to the invalid password attempt discussed in the previous section of this chapter.
The service attribute values are self-explanatory. However, there is one particular attribute that decides whether OpenSSO would honor the password policy of the backend data store. The attribute Force Change Password on Next Login determines whether to look for the password control from the backend data store. In the same manner, checking on Personal Question attribute enables the end user to provide their own question besides selecting administrator-provided choices. The end configuration of the password reset service will look as shown in the following screenshot:
With that, we complete the configuration of the OpenSSO password reset service. Now let us create a user identity jdoe and prepare that identity to be used with the password reset application to change the password of the user jdoe. To create the user, you can use either of the interfaces provide by the OpenSSO. The profile will appear like the following screenshot, from the console:
Please note that the user profile consists of a valid e-mail address. This is the key for the password reset application to reset and send the new password to the end user. This e-mail should be accessible by the end user with a username and password that is not the same as the one being reset. According to the configuration, the end user should be able to add their own question to their password reset profile. Let us add a custom question for the user jdoe as shown in the following screenshot:
This screen can be arrived at by logging into the end user's account and by clicking on profile | Password Reset Options link:
These configurations are sufficient for the end user to reset his/her forgotten password using the OpenSSO password reset application. In this example, by accessing the URL http://opensso.packt-services.net:9090/opensso/password/.
Upon invoking the preceding URL you will be asked a series of questions as configured in the system and as the one configured in your profile. The following sequence of screenshots shows the actions that occur when the user initiates the password reset process.
As you will notice, the two questions are shown to the user—one that the OpenSSO administrator configured and the other added by the end user, jdoe. The administrator can add as many as five questions to the system. The end user is only allowed to add one question in the default configuration.
The password of the user will be reset once the questions are answered correctly. If not, they will be asked again until they are answered correctly or locked out if lockout is enabled. You will be given warning about the lockout as shown in the following screenshot:
If the password is reset, then two e-mails will be sent to the e-mail address in the user's profile—one e-mail will inform the user that there was an attempt to reset his account, and the other mail will contain the actual system generated password. If an e-mail does not exist in the user's profile or a problem arises with the SMTP server or the e-mail address is invalid, appropriate information will be printed on the browser screen. A typical message will be, "Your password has been reset but we are unable to send it to you. Contact your administrator". In this case, you should contact the administrator.
A success message will appear somewhat as given in the following screenshot:
After this process, you can log in to your e-mail account to get the temporary system-generated password. You must change the password after logging into the OpenSSO. Often, users fail to change the password that was generated by the system. This could be a potential security vulnerability as the password has been e-mailed. It could be read by any malicious user. To circumvent these kinds of issues, the backend directory servers enforce a mechanism to change the password at the first login attempt. The OpenSSO password reset feature can honor this if the backend directory has been setup with a password policy to force the users to change the password during the first login attampt.
Now let us see how one can configure the OpenDS server to enforce the password change after an Administrator Reset.
The OpenSSO password reset application works with and even without enabling the OpenDS password policy. If the OpenSSO server is configured such that it does not force the user to change his password through the password reset application, then there is no need to create this policy in the OpenDS server. However, the said configuration is highly discouraged from a deployment perspective, so exercise caution while unchecking this box in the password reset service configuration.
To create the OpenDS password to force the password change after an admin reset, one can use the dsconfig utility. There is lot of documentation available on the Internet on how to create the password policies. Here is the simple command line to create the policy:
dsconfig create-password-policy
-set default-password-storage-scheme: Salted SHA-1
--set password-expiration-warning-interval: 86400
--set password-attribute: userpassword
--set force-change-on-reset: true
--set max-password-age: 172800
--type generic
--policy-name OpenSSO Users Policy
--hostname opends.packt-services.net
--trustAll
--port 5519
--bindDN cn=Directory Manager
--bindPassword ******
--no-prompt
--set force-change-on-reset: true is the key part of this policy. This tells the OpenDS that users who belong to this policy will have to reset their password after an administrator changes their password.
Once you create the preceding policy, it appears in the config.ldif of OpenDS in the following form:
# OpenSSO Users Policy, Password Policies, config dn: cn=OpenSSO Users Policy,cn=Password Policies,cn=config objectClass: ds-cfg-password-policy objectClass: top ds-cfg-default-password-storage-scheme: cn=Salted SHA-1,cn=Password Storage Sc hemes,cn=config ds-cfg-password-expiration-warning-interval: 86400 s ds-cfg-password-attribute: userpassword cn: OpenSSO Users Policy ds-cfg-force-change-on-reset: true ds-cfg-max-password-age: 172800 s
After the policy has been created in the backend data store, in this case OpenDS, we need to assign this policy to a user or group so it will take effect for those assigned entries. These policies can be assigned to groups or individual entries. Here, for simplicity let us assign the policy to our jdoe user. This assignment can be done using the ldapmodify tool as mentioned here:
ldapmodify -h opends.packt-services.net -p 5389 -D"cn=directory manager" -w dssecret12 -c -f /tmp/mod
where the file /tmp/mod contains:
dn: uid=jdoe,ou=people,dc=opensso,dc=java,dc=net changetype:modify add: ds-pwp-password-policy-dn ds-pwp-password-policy-dn: cn=OpenSSO Users Policy,cn=Password Policies,cn=config
This will complete assignment of the policy to the end user identity.
Now let us revisit the password reset initiate process by invoking the password reset application URL http://opensso.packt-services.net:9090/opensso/password. Go ahead; answer the questions correctly for the user jdoe as you did in the earlier section. Once you successfully reset the password, go to your e-mail and get the temporary system generated password, and try to log in to the server. At this point you will notice two kinds of behaviors—either your authentication with the new password will repeatedly fail or you will see a new screen, as follows:
If you see the password reset screen as shown in the preceding screenshot, then that is the correct behavior. It means OpenSSO honors the force password change control coming from the OpenDS. It is important that you enable the Force Change Password on next login in the password reset service configuration otherwise OpenSSO will not know about the password reset control coming from OpenDS. Well, what if you keep on failing the authentication with the new system generated password? It is very likely that your default authentication service for the realm has been set to something other than the LDAP module. You must use the LDAP authentication module in order see this force password change screen. This LDAP instance must point to the OpenDS server where the user profile is located.
Once you reset the password of the user, you will see that the pwdreset attribute will set to true in the profile of that user identity. This is the key information for the OpenSSO LDAP authentication module to render the force password change page for the end user. Before the password is changed by the end user the pwdreset attribute will be preset in the profile with a value true:
ldapsearch -h opends.packt-services.net -p 5389 -D"cn=directory manager" -w dssecret12 -b"dc=opensso,dc=java,dc=net" "uid=jdoe" pwdreset
dn: uid=jdoe,ou=people,dc=opensso,dc=java,dc=net
pwdreset: true
After performing the force password change through the OpenSSO LDAP authentication module, the pwdreset attribute will be removed from the profile of the end user:
ldapsearch -h opends.packt-services.net -p 5389 -D"cn=directory manager" -w dssecret12 -b"dc=opensso,dc=java,dc=net" "uid=jdoe" pwdreset
dn: uid=jdoe,ou=people,dc=opensso,dc=java,dc=net
The questions and the answers configured by the administrator and the users are stored as part of the user profile data. These are stored in an encrypted form in order to maintain privacy and secrecy. The attributes that store these questions and answers are part of the OpenSSO identity schema. There is no option to store them in existing user attributes. Here is the how user entry jdoe appears in the backend data store:
dn: uid=jdoe,ou=people,dc=opensso,dc=java,dc=net
postalAddress: 6151 Al way
inetUserStatus: Active
uid: jdoe
userPassword: {SSHA}GxEwEI8lnuVfcNqW8CDu/g1vxVEPyyPl1GqHNg==
sunAMAuthInvalidAttemptsData:: PEludmFsaWRQYXNzd29yZD48SW52YWxpZENvdW 50PjA8L0
ludmFsaWRDb3VudD48TGFzdEludmFsaWRBdD4wPC9MYXN0SW52YWxpZEF0PjxMb2NrZWR vdXRBdD
4wPC9Mb2NrZWRvdXRBdD48QWN0dWFsTG9ja291dER1cmF0aW9uPjA8L0FjdHVhbExvY2 tvdXREdX
JhdGlvbj48L0ludmFsaWRQYXNzd29yZD4=
objectClass: iplanet-am-auth-configuration-service
objectClass: sunIdentityServerLibertyPPService
objectClass: sunAMAuthAccountLockout
objectClass: sunFederationManagerDataStore
objectClass: iplanet-am-managed-person
objectClass: iPlanetPreferences
objectClass: sunFMSAML2NameIdentifier
objectClass: person
objectClass: inetorgperson
objectClass: organizationalperson
objectClass: inetuser
objectClass: iplanet-am-user-service
objectClass: top
givenName: John
iplanet-am-user-password-reset-question-answer: AQICedz7aDUl9rJQbVekeLksWS2zr+
x80x30S63PCVSLKGBr3rVNbJDYiiFEle7YnzEm
iplanet-am-user-password-reset-question-answer: AQICedz7aDUl9rJ0C5mnO1eJvv1Rj8
jqqY5KpkV6Ts5T3wGDXcDb3WGz4fRedJ7gxLvJcFNdPkUENpFv/zvqTUwgUg==
cn: John Doe
telephoneNumber: 408-276-0000
sn: Doe
iplanet-am-user-password-reset-force-reset: true
mail: [email protected]