[J2] Security component updated again: table structure changes required!!!

[Ate Douma <at...@douma.nu>]

Hi All,

I've implemented and checked in a major part of the JS2-151 (http://issues.apache.org/jira/browse/JS2-151) feature list.
1) storing password encoded
2) requiring a minimum length and a minimum number of numeric characters in a password
4) automatically expire password after a configurable time
6) locking a user out when the current password is expired
8) disable a password after a certain number of failures to authenticate, reset check after success

The other items below I will hopefully finish soon. Part of it, data and object model and some behavior is already in place though.
3) keeping a history (queue) of previously used password and preventing a user to reuse one from this queue (with a configurable queue size)
5) warning a user its password is going to be expired (with a configurable time before)
7) forcing a user to change a password on first use
9) enable/disable principals: users,groups,roles

As result of the above changes, a two security tables have additional columns:
Table SECURITY_CREDENTIAL:
- column UPDATE_REQUIRED, BIT, NOT NULL
- column IS_ENCODED, BIT, NOT NULL
- column IS_ENABLED, BIT, NOT NULL
- column AUTH_FAILURES, SMALLINT, NOT NULL
- column IS_EXPIRED, BIT, NOT NULL
- column LAST_LOGON_DATE, TIMESTAMP, NULL
- column EXPIRATION_DATE, DATE, NULL

Table SECURITY_PRINCIPAL:
- column IS_ENABLED, BIT, NOT NULL

As default configuration (just temporary, just to let you guys test this) I've defined the following:
- 1) a SHA-1 encoder for the passwords: MessageDigestCredentialPasswordEncoder
- 2) no requirements for password length or number of digits, but
      I've supplied a SimpleCredentialPasswordValidator which can do so.
      See: TestPasswordCredentialProvider and its security context definition spcpv.xml
- 4) a maxLifeSpanInDays of 60 for password (expiration) and,
   6) a maxNumberOfAuthenticationFailures of 3, and
   8) disable a password after a certain number of failures to authenticate, reset check after success
      with: InternalPasswordCredentialStateHandlingInterceptor

Because this configuration will encode passwords, getting the correct values into the database from
outside Jetspeed might seem a bit of a problem, but it isn't!
When inserting data in the SECURITY_CREDENTIAL table itself, use the plain text value for the VALUE column and
for IS_ENCODED 0 (zero, false). As soon as a credential is loaded by Jetspeed it will be encoded.
Same goes for EXPIRATION_DATE: if you leave that null, Jetspeed will fill it in on first access.

I've also added a Password tab to the User Details Portlet through which an administrator can set new password,
enabled/disable a password and toggle the update password required flag (item 7 from the list above).

Be warned now: try a wrong password three times in a row and your locked out. Lucky, the User Browser Portlet
isn't secured yet, so fixing it (setting the user password enabled again) is still easy.
(guys, we have to think about a build in/predefined admin role or permissions to secure this thing)

Regards, Ate




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org