Ate, +1. I believe this would be a great enhancements to the current framework.
Regards, David. --- Ate Douma <[EMAIL PROTECTED]> wrote: > I've the requirement to implement an enhanced > security model for J2 concerning password > validation. > I must meet the following requirements: > 1) storing password encoded (Base64 will do for now) > 2) requiring a minimum length and a minimum number > of numeric characters in a password > 3) keeping a history (queue) of previously used > password (10) and preventing a user to reuse one > from this queue > 4) automatically expire password after a certain > time (60 days) > 5) warning a user its password is going to be > expired (configurable time before, 10 days) > 6) locking a user out when the current password is > expired > 7) forcing a user to change a password on first use > 8) three strikes out: disable a password after three > (or another number of) failures to authenticate, > reset check after success > > 9) Furthermore, I must implement enable/disable of > principals (users,groups,roles). > > We already had a first version of the password > validation implemented partly *outside* J2 using > triggers on the SECURITY_CREDENTIAL table > (we are using oracle) and a custom UserManagerImpl. > > But, since the refactoring of the Security with the > new Handlers e.a. our implementation doesn't work > anymore anymore. > > So, I'm faced with fixing our current implementation > or writing a new one myself which I then would like > to integrate into J2. > I think this would be a great (optional) enhancement > for most (company) portal implementations. > > To be able to integrate this into J2 though, I will > need a few enhancements to the security object > model. Those enhancements won't need to > be used by the simple default security handlers but > would be available when needed *and* used/enforced > when set in a non-default way. > > The needed enhancements I now foresee are: > > - boolean enabled attribute for principals and > credentials > false: principal/credential is *never* used in > security checks, meaning: > - user cannot log in if its user principal is > disabled > - user cannot log in if no credential is > enabled > - disabled groups or roles will not be > added to a subject > Usage for administrative purposes in *not* > to be limited by this: > A administrator can still assign disabled > groups/roles to a user/group/role or whatever. > They just won't have any effect *yet*. > Note, I created an issue for this feature > (on groups and roles) quite some time ago already: > > http://issues.apache.org/jira/browse/JS2-27 > I just never got around implementing it > yet. > > - int authentication failures attribute on > PasswordCredential (0 as default or for other type > of credentials): > -1 means never tried yet (to indicate enforce > change password on first use) > 0 means none or last time was successful > > 0 number of failures (to allow disable after > configurable failures) > > - boolean valid attribute on PasswordCredential > (default = true, or only false if null/empty): > Allows for password sanity check before even > trying to authenticate or set/change a password. > A specific PasswordCredential implementation (see > next feature) then could check against above > mentioned rules like minimum length, > number of numeric characters, a regular > expression, etc. > > - Define a > PasswordCredentialComponent/Provider/Factory to > allow specialized versions of PasswordCredential to > be used > as describe above, instead of the current > implementations which does hardcoded > PasswordCredential instantiations. > > - Date expiration date attribute on > PasswordCredential indicating the lifespan of a > password, > null in the default implementation indicating > never > > - boolean expired attribute indicating on > PasswordCredential, default false: > true: non-valid PasswordCredential because a > newer PasswordCredential is defined or the lifespan > had ended. > > - An enhanced CredentialHandler enforcing most of my > above requirements, configurable through the > jetspeed-spring.xml > with parameters like: password history size, > password expiration time and max authentication > failures. > > - A new pipeline security value (in addition to the > current one) which checks on a authenticated user > (Subject) > - if a password change is required: force the > user to a change password page/portlet > - if a password is about to be expired: inject > some sort of warning message into the aggregated > output > (I don't have clue yet how to do that, probably > some kind of javascript message, maybe need an > additional valve for that) > > Not sure if I got everything needed now specified > above, but this is the general idea. > > I need to start with this real soon and if > considered a + will get it in J2 before the upcoming > release. > Anyone cares to comment/vote? > > Regards, > > Ate > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
