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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
