The following issue has been updated:
Updater: Ate Douma (mailto:[EMAIL PROTECTED])
Date: Tue, 19 Oct 2004 2:46 PM
Changes:
description changed from 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)
to 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)
The above implementations will initially only be available as system wide features,
not (yet?) per user, group or role.
---------------------------------------------------------------------
For a full history of the issue, see:
http://issues.apache.org/jira/browse/JS2-151?page=history
---------------------------------------------------------------------
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:46 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)
The above implementations will initially only be available as system wide features,
not (yet?) per user, group or role.
---------------------------------------------------------------------
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]
