Message: A new issue has been created in JIRA.
--------------------------------------------------------------------- View the issue: http://issues.apache.org/jira/browse/JS2-151 Here is an overview of the issue: --------------------------------------------------------------------- Key: JS2-151 Summary: Security enhancements for password validation and enable/disable principals Type: Improvement Status: Open Priority: Major Project: Jetspeed 2 Components: Security Versions: 2.0-M1 Assignee: Ate Douma Reporter: Ate Douma Created: Tue, 19 Oct 2004 2:44 PM Updated: Tue, 19 Oct 2004 2:44 PM Description: As proposed on the list (see: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=22&msgNo=18415) several security enhancements will be implemented: Allow: 1) storing password encoded (initially using Base64) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password and preventing a user to reuse one from this queue (with a configurale queue size) 4) automatically expire password after a configurable time 5) warning a user its password is going to be expired (with a configurable time before) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) disable a password after a certain number of failures to authenticate, reset check after success 9) enable/disable principals: users,groups,roles (see also earlier and never implemented issue http://issues.apache.org/jira/browse/JS2-27) This will be implemented using the the following enhancements: - 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*. - 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) --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
