« Configuring Self... | Main | A 2001 Holiday Party... »
Tuesday Sep 29, 2009

Don't Be Tardy: Configure Password Expiration with OpenSSO and Identity Manager

In a deployment architecture that includes OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October) it is possible to configure user password reset based on the password's expiration date, or a help desk administrator's action. In the former use case, when a password is close to expiration, the user data store (which must be an LDAP directory server) can send a warning to the user based on the time configured in the assigned password policy. Upon accessing a resource protected by OpenSSO, the user would be redirected to Identity Manager to change the password. The URL of the protected resource is saved as a value of the goto parameter and the user will be redirected to this location after changing the password.

For the latter use case, if the user allows the password to expire, a help desk administrator can initiate the reset of the expired password by flagging the account and adding a temporary password to the user's profile. The administrator will then communicate the temporary password to the user (by email, for example). Upon logging into OpenSSO with this temporary password, the user will be directed to Identity Manager where the password is reset and the flag is removed.

The procedures documented will enable these use cases. Note that they only support the LDAP authentication module. The following sections contain the configuration procedures.

Configuring the LDAP Directory Server

For this procedure to work it is assumed that a password policy has been configured and assigned to the test user's LDAP profile in the directory server. The password policy should have the following controls related to password expiration set:
  • Set Password Expiration (LDAP attribute: passwordexp, passwordmaxage)
  • Set Expiration Warning (LDAP attribute: passwordwarning)
  • Warning Duration (LDAP attribute: passwordExpireWithoutWarning)
It should also have the following controls set to allow for administrator-driven password reset:
  • Require Password Change at First Login and After Reset (LDAP attribute: passwordchange, passwordmustchange)
  • Allow Users to Change Their Passwords (LDAP attribute: pwdallowuserchange)
The passwordPolicySubentry attribute in the test user's LDAP profile should also be defined with the DN of the password policy to denote that the password policy has been assigned. See the documentation for your specific directory server for instructions on how to do these configurations.

Configuring OpenSSO

Only the OpenSSO LDAP authentication module supports the password change controls enforced by most directory servers. The following sections contain OpenSSO configurations.

To Enable LDAP Authentication

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name.
  4. Click the Authentication tab.
  5. Click New in the Authentication Chaining section to create a new authentication chain.
  6. Enter a name for the chain and click OK.
    For this example use idmauth.
  7. On the new chain's Properties page, add the LDAP module as REQUIRED and click Save.
  8. Click Back to Authentication.
  9. Select the service just created as the value for Organization Authentication Configuration.
  10. Click LDAP in the Module Instances section.
  11. Customize the LDAP properties to reflect your directory - at minimum:
    • Primary LDAP Server
    • DN to Start User Search
    • DN for Root User Bind
    • Password for Root User Bind
    • Password for Root User Bind (confirm)
  12. Save the changes.
  13. Logout from the OpenSSO console.
Note: Following this configuration:
  • Use /opensso/console to log in to the OpenSSO console (not /opensso/UI/Login) to ensure that the authentication module configured for the OpenSSO administrator is used and not the LDAP module just configured.

  • Login to the Identity Manager console and expand the OpenSSO resource listing to view the OpenSSO objects. If you receive an error, you may need to reconfigure the OpenSSO adaptor to use a delegated administrator rather than amadmin to connect to OpenSSO. The Identity Manager adaptor for OpenSSO authenticates to OpenSSO using the authentication configuration for the realm which is now different from the configuration for the OpenSSO console. Thus, amadmin will no longer work. See Delegating Administrator Privileges for information on delegating administrative privileges to a group.

To Define Identity Manager URLs as Not Enforced

  1. Login to the OpenSSO console as administrator.
  2. Click the Access Control tab.
  3. Click the appropriate realm name and navigate to the Agents profile for the policy agent that protects Identity Manager.
  4. Under the agent profile, click the Application tab.
  5. Add the following URIs to the Not Enforced URIs property.
    • /idm/authutil/
    • /idm/authutil/*
    • /idm/authutil/*?*
  6. Click Save.
  7. Logout of OpenSSO.

To Create ChangePassword.jsp

This procedure documents how to create ChangePassword.jsp, a custom JSP for redirecting a user to Identity Manager for password change events. (By default, the user would be directed to the OpenSSO password change page.) ChangePassword.jsp will forward the following information to Identity Manager:
  • The original URL requested by the user and defined as the value of the goto parameter.
  • The user identifier defined as the value of the accountId parameter

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample ChangePassword.jsp.
  2. Modify the Identity Manager URL in the JSP based on your deployment.
  3. Copy ChangePassword.jsp to /web-container-deploy-base/opensso/config/auth/default/ and to /web-container-deploy-base/opensso/config/auth/default_en/.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.

Modifying the LDAP Authentication Module XML Service File

This procedure documents how to modify LDAP.xml to use ChangePassword.jsp. There are two options to consider when deciding how to modify LDAP.xml. You can manually change the deployed LDAP.xml file, or you can use the sample LDAP.xml included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
To Manually Modify a Deployed LDAP.xml
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed LDAP.xml page.
  2. Open LDAP.xml in an editor and add the section of code displayed in yellow in admin_pwd_reset_ldap.html on the OpenSSO web site.
  3. Change to the /web-container-deploy-base/opensso/config/auth/default_en/ directory to access the second copy of LDAP.xml and make the same change.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.
To Use the Sample LDAP.xml

  1. Change to the opensso/integrations/idm/xml/ directory in the decompressed opensso.zip to access the sample LDAP.xml.
  2. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/LDAP.xml with the sample LDAP.xml in two directories:
    • /web-container-deploy-base/opensso/config/auth/default/
    • /web-container-deploy-base/opensso/config/auth/default_en/
    If you replace your existing LDAP.xml with the sample LDAP.xml you will lose any custom changes made to the existing LDAP.xml.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  4. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Modifying the OpenSSO Login Page

This procedure documents how to modify Login.jsp with the necessary code to save the URL value of the goto parameter in the HTTP request. This saved URL is required by the ChangePassword.jsp. The saved URL (which is the original location desired by the user) will be passed to Identity Manager and used to redirect the user after unlocking has been completed.

There are two options to consider when deciding how to embed code into the OpenSSO Login.jsp. You can manually change the deployed Login.jsp file, or you can use the sample Login.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.
To Manually Modify a Deployed Login.jsp
  1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed Login.jsp page.
  2. Open Login.jsp in an editor and add the two (2) sections of code displayed in yellow in admin_pwd_reset_login.html on the OpenSSO web site.
  3. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  4. Restart the OpenSSO web container after making the changes.
To Use the Sample Login.jsp

  1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample Login.jsp.
  2. Change the Identity Manager URL embedded in the sample Login.jsp to reflect the Identity Manager system URL of your architecture.
    You can search for the string /idm to locate the URLs.
  3. Replace your deployed /web-container-deploy-base/opensso/config/auth/default/Login.jsp with the sample Login.jsp.
    If you replace your existing Login.jsp with the sample Login.jsp the following will occur.
    • You will lose any custom changes made to the existing Login.jsp.
    • You will inherit changes that might have been previously made to the sample Login.jsp to incorporate requirements for other use cases related to the OpenSSO integration with Identity Manager.
  4. Remove the web containers temporary, compiled JSP to ensure that the changes made are picked up.
    For example, if using Glassfish, the temporary, compiled classes can be found under glassfish-home/domains/your-domain/generated/.
  5. Restart the OpenSSO web container after making the changes.
Optionally, you can run diff between both files and make the necessary changes manually.

Testing The Configurations

Perform the tests in the order in which they are described to understand and verify the behavior for each stage of this use case.

A. Testing Password Warning Expiration

Perform the following actions after the time the password expiration warning, as defined in the password policy, would take effect.
  1. Access a URL protected by OpenSSO.
    The OpenSSO login page is displayed.
  2. Enter the test user name and password.
    You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
    • The URL is the one configured in ChangePassword.jsp.
    • The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
    • The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.

B. Testing Password Expiration

Perform the following actions after the time the password should have expired, as defined in the password policy.
  1. Access a URL protected by OpenSSO.
    The OpenSSO login page is displayed.
  2. Enter the test user name and password.
    An error page is displayed informing the test user that the password has expired. The user will be instructed to have the administrator reset the password.

C. Testing Administrator Password Reset

  1. Refer to your directory server documentation to enable audit and logging.
    Monitor the directory server audit log as you finish the test.
  2. Login as the directory administrator and change the password for a test user.
    This simulates the password reset by a help desk administrator.
  3. Verify that the user's userPassword attribute was modified and the pwdreset was set to TRUE using the audit log.
    The pwdreset attribute will force the user to change the password at the next login. The audit log might resemble this sample. 
    time: 20090713074720
dn: uid=idmuser1,dc=sun,dc=com
changetype: modify
replace: userPassword
userPassword: {SSHA}4Bgy/HF9SGN9nnS4Ii6/KJj9ktFdAxQUIDvwVQ==
-
replace: modifiersname
modifiersname: cn=admin,cn=administrators,cn=dscc
-
replace: modifytimestamp
modifytimestamp: 20090713144720Z
-
replace: passwordexpirationtime
passwordexpirationtime: 19700101000000Z
-
replace: pwdreset
pwdreset: TRUE
  4. Access the Identity Manager user URL.
    You will be redirected to OpenSSO for login.
  5. Enter the test user name and password.
    You will be redirected to Identity Manager to change your password. Note the following about the Identity Manager URL:
    • The URL is the one configured in ChangePassword.jsp.
    • The user will be forwarded to the value of the goto parameter after the password has been successfully changed.
    • The value of the accountId parameter determines the account for which the password needs to be changed. Identity Manager will make the changes to the password on both Identity Manager and OpenSSO.
For those fans of The Real Housewives of Atlanta, here's a fan-made video of Kim Zolciak's (Don't Be) Tardy for the Party. (I added the parentheticals to make it seem official.) Kandi Burress produced a dance floor smash for the woman who can not sing! Who knew?

Posted at 08:25AM Sep 29, 2009 by Michael Teger in Sun  |  Comments[0]

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed