In the default OpenSSO configuration, the user account lockout feature is disabled by default. This feature can be enabled using the administrative console or the ssoadm command line tool. From the console, navigate to Access Control | (Top Level Realm) | Authentication | All Core Settings. Then enable account lockout by checking the box as shown in the following screenshot:
When enabled, e-mail notifications are sent to administrators regarding any account lockouts as well as those recorded by the Logging Service. In order to get the e-mail notification, the administrator must configure the SMTP server name and port properly in the server configuration; otherwise the e-mail notification feature will not work (Please refer to the next section for more details on SMTP configuration.) Here is a simple way to set these properties using the ssoadm tool:
./ssoadm update-server-cfg -s http://opensso.packt-services.net:9090/opensso -u amadmin -f /tmp/pass -a com.iplanet.am.smtphost=smtphost.packt-services.net com.iplanet.am.smtpport=25
Only authentication modules that throw an invalid password exception can leverage the account locking feature. These include Active Directory, Data Store, HTTP Basic, JDBC, LDAP, RADIUS, SafeWord, SecurID, and Unix.
OpenSSO supports two types of account lockout:
- Physical lockout
- In-memory lockout
Both of these have their own merits. It is up to the deployment requirements, based on which, one or the other mode could be employed. Let us briefly look at the features of each mode.
This is the default lockout behavior, initiated by changing the status of a specified LDAP attribute in the user's profile to inactive. The specified LDAP attribute (in this example it is inetuserstatus) is defined as the value of the Lockout Attribute Name attribute in the Core authentication module as shown in the preceding screenshot. When physical account lockout is enabled, an attribute in the user data store (in this case sunAMAuthInvalidAttemptsData) is used to hold information regarding the authentication attempts. This information includes:
- Invalid attempts count
- Last failed time
- Lockout time
- Lockout duration
Here is the typical XML message that gets stored in the attribute sunAMAuthInvalidAttemptsData:
<InvalidPassword><InvalidCount>2</InvalidCount><LastInvalidAt>1282421717450</LastInvalidAt><LockedoutAt>0</LockedoutAt><ActualLockoutDuration>0</ActualLockoutDuration></InvalidPassword>
Note
Physical lockout can be enforced in the multi-server environment or in a site with more than one OpenSSO server, serving for high availability, because the invalid attempts data are persisted as part of the user profile attribute. However, in-memory lockout is server-specific. Even though they belong to a site, each server could potentially hold different invalid attempt counts for a given user.
In-memory lockout is enabled by changing the value of the Login Failure Lockout Duration attribute (which defines how long a user must wait after a lockout, before attempting to authenticate again) to a value greater than 0. This is in addition to enabling the Login Failure Lockout Mode check box. The user's account is then locked in memory (stored in the container's memory) for the number of minutes specified. The account is unlocked after the time period has passed. There are special considerations when using the memory locking feature:
- If the OpenSSO server is restarted, all accounts locked in memory are unlocked because the stored data is lost due to server restart
- If a user's account is locked in memory and the administrator resets the account lockout mechanism to physical lockout (by changing the value of the Login Failure Lockout Duration to 0), then the user's account will be unlocked in memory and the lock count reset
- If the
Failure URLattribute in the user's profile is defined, neither the lockout warning message nor the message indicating that the account has been locked will be displayed; the user will be redirected to the defined failure URL as expected
Once the lockout mode is enabled based on this configuration, the OpenSSO server authentication service will throw warning messages before locking out due to an invalid password attempt. Here is a typical message that will be shown to the user who entered an invalid password for a valid account.
Customers will be able to employ any one of these solutions based on their nature of usage. In a deployment where high availability is a requirement, it would be wise to deploy the physical lockout because it is enforced in multiple server environments.