You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Ate Douma <at...@douma.nu> on 2004/11/25 03:29:49 UTC

[J2] JS2-151 security features, part 3: password change requirements implemented

I've implemented a third set of JS2-151 features:
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

This leaves only the last feature:
9) enable/disable principals: users,groups,roles

This time I had to change and extend the SECURITY_CREDENTIAL once more:
- renamed column LAST_LOGON_DATE to LAST_AUTH_DATE
- added column PREV_AUTH_DATE, TIMESTAMP, NULL

I don't expect to need more changes to this table anytime soon.

The new password change requirement features are implemented using a new PasswordCredentialValve
and a special Profiling rule.

A user who logs on the first time is automatically redirected to the (new) My Account page
and forced to change its password (or log off).

Furthermore, the PasswordCredentialValve can be configured (through jetspeed-spring.xml) to
check for password expiration within a set of defined days (expirationWarningDays).
This set is currently defined as [7,3,2] meaning:
- When a user logs the first time 7, 3 or 2 days or less before expiration the profiler will
   redirect once more to the My Account page to allow the user to change its password.
   This is *not* required though.
- When a user logs on after receiving such a warning in the period between on of these
   expirationWarningDays, no further warning will be given.
- When a user logs on 1 day before password expiration, the profiler will again redirect to
   the My Account page and now the user is *forced* to change its password.

The page the user is redirected to is defined by the security profiling rule.
Its page rule criteria (of resolver type 'hard.coded') sets the specific page.

I also modified the handling of the anonymous user which originally was defined (and could be
configured differently) in the Profiler.
Because the anonymous user is meant to be used as a build in user only, I moved the definition
to the UserManager and the default ("guest") can now be configured differently there.
This allowed me to protect the anonymous user which now cannot be used to logon and/or change its password.

Furthermore, retrieving this anonymous user from the UserManager (if defined in the database) will *not*
return its credentials anymore (which caused problems with the above features in that the guest user was
also required to change its password).
I'm not sure though if this would interfere with the SSO functionality Roger is developing, which also used
the credentials I think. Roger, please let me know in that case. We will then have to discuss how to fix this otherwise.

Finally, I modified the UserDetailsPortlet to suppress the Password tab for the anonymous user as it should
not be defined, nor modified anymore.
I also removed the default security_credential for the guest user from the default userinfo population script.

I'll have to postpone the implementation of the remaining feature from JS2-151, enable/disable principals for a short while
because my free time available for J2 is much more limited the next few weeks.
I don't expect to be able to work on it or complete it in time before the M1 release, so for now, the current implemented
features will have to do.

Regards,

Ate



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