DocTeger

OpenSSO Technical Information

And a Spoonful of Music

To Make the Medicine Go Down

Configuring Self Unlock After Account Lockout Using OpenSSO and Identity Manager is Fun

User account lockout in OpenSSO can happen in either of the following ways:

• Memory account lockout occurs when the user has exceeded the allowed number of failed attempts to log in as configured in the password policy. The user may remain locked out for a set period of time and can only reset the password after that period has passed. The locked state of the user account is maintained in memory and no information is written to the user's LDAP profile.
• Physical account lockout occurs when the status of a specified LDAP attribute in the user’s profile is explicitly changed to Inactive, either by an administrator or as a result of some automated processes. (The specified LDAP attribute is defined as the value of the Lockout Attribute Name attribute in the Core authentication module.) By default it is inetuserstatus.

When a user's account is locked, it is possible to allow the user to unlock the account without intervention from an administrator. The procedures documented will enable this for a deployment with OpenSSO Enterprise 8.0 and Identity Manager 8.1.0.5 (to be released sometime in October). Note that memory account lockout in OpenSSO must be disabled using the OpenSSO console as the account lockout controls in the user data store will be used. Using this feature in a deployment with OpenSSO and Identity Manager only supports the LDAP authentication module. The following sections contain the configuration procedures.

• Configuring the LDAP Directory Server
• Configuring OpenSSO
• Testing the Configurations

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 set:

• Enable Account Lockout (LDAP attribute: passwordLockout)
• Failures Before Lockout (LDAP attribute: passwordMaxFailure)
• Failure Count Reset (LDAP attribute: passwordResetFailureCount)
• Set Limit on Lockout Duration (LDAP attribute: passwordUnlock)
• Lockout Duration (LDAP attribute: passwordLockoutDuration)

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 for instructions on how to do these configurations.

Configuring OpenSSO

The OpenSSO LDAP authentication module supports the account lockout controls enforced by most directory servers. The following sections contain OpenSSO configurations.

• To Enable LDAP Authentication
• To Define Identity Manager URLs as Not Enforced
• Modifying the OpenSSO Login Page
• Modifying the OpenSSO Account Lockout Message Page

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. Save the changes.
11. 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.

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.

Modifying the OpenSSO Login Page

This procedure documents how to modify Login.jsp with the necessary code for this use case. The code will save the value of the goto parameter in the HTTP request. This saved URL is required by the user_inactive.jsp created in the next procedure. 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
• To Use the Sample Login.jsp

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 account_unlock_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.

Modifying the OpenSSO Account Lockout Message Page

This procedure documents how to modify user_inactive.jsp, the JSP that notifies the user that the account is locked. You will modify the page to include a redirect to an Identity Manager page that will enable the user to unlock the account. user_inactive.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

There are two options to consider when deciding how to embed code into the OpenSSO user_inactive.jsp. You can manually change the deployed user_inactive.jsp file, or you can use the sample user_inactive.jsp included with the opensso.zip download. They are mutually exclusive so choose only one of these procedures.

• To Manually Modify the Account Lockout Message Page
• To Use the Account Lockout Message Page

To Manually Modify the Account Lockout Message Page

1. Change to the /web-container-deploy-base/opensso/config/auth/default/ directory to access the deployed user_inactive.jsp page.
2. Open user_inactive.jsp in an editor and add the two (2) sections of code displayed in yellow in account_unlock_inactive.html on the OpenSSO web site.
   Embedded in the JSP, you will see the URL to the Identity Manager page that allows the account unlock. You should modify this URL as per your deployment.
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.

Note: The Identity Manager URL used in the sample refers to anonResetPassword.jsp. You might, however, direct the user to questionLogin.jsp, the forgotten password page because if a user has accidentally locked an account it may be because of a forgotten password.

To Use the Sample Account Lockout Message Page

1. Change to the opensso/integrations/idm/jsps/ directory in the decompressed opensso.zip to access the sample user_inactive.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/user_inactive.jsp with the sample user_inactive.jsp.
   If you replace your existing user_inactive.jsp with the sample user_inactive.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

The following procedures document testing these configurations for memory account lockout and physical account lockout.

• To Test Memory Account Lockout
• To Test Physical Account Lockout

To Test Memory Account Lockout

1. Configure the password policy and assign the policy to the test user.
   This is done using the user data store.
2. Access a resource protected by OpenSSO to get redirected to the login page.
3. Login to OpenSSO using an incorrect password.
   Do this consecutively until the account gets locked and the error page is displayed. This will be dependent on the number of attempts configured in the password policy.
4. Click the hyperlink on the page.
   You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
5. Change your password.
   Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.

To Test Physical Account Lockout

1. Set the value of the inetuserstatus attribute in the test user's profile in the user data store to Inactive.
2. Access a resource protected by OpenSSO to get redirected to the login page.
3. Login to OpenSSO.
   An error page will be displayed informing you that the account has been locked.
4. Click the hyperlink on the page.
   You will be redirected to an Identity Manager page on which you will be required to change your password. Note that the URL is the one configured in the user_inactive.jsp.
5. Change your password.
   Identity Manager determines the account from the accountID parameter and will change the password on both OpenSSO and Identity Manager. After a successful modification, the user will be redirected to the original URL defined in the goto parameter.

And now here are some girls doing it for themselfes: Cyndi Lauper, Ann Wilson, Nancy Wilson, Wynona Judd, Amy Grant and Destiny's Child (Beyonce, Kelly Rowland and Michelle Williams) performing a live version of Hey Now (Girls Just Wanna Have Fun).

Posted at 12:00AM Sep 28, 2009 by Michael Teger in Sun  |  Comments[5]