portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ate Douma <...@douma.nu>
Subject [J2] JS2-151 security features, part 3: password change requirements implemented
Date Thu, 25 Nov 2004 02:29:49 GMT
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


Mime
View raw message