Randy Watler wrote:
Ate,
+1 from me.... that will get you to maybe +3.5 then. :)
Thanks for your support too Randy!
BTW, we do our login from the decorator and do not depend on the login portlet. We do not require password changes and other admin functions from the decorator, (we can certainly put those functions in a real page), but we want to continue to use login/logout from there. Just FYI,
You won't be harmed by these enhancements which will be optional and not default enabled.
Randy
Ate Douma wrote:
Having received a positive response from Roland S. Ong, a further +3 (mine included)
and no other reactions I'll create an new feature issue for this and start
working on it right away.
Regards,
Ate
Ate Douma 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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
