portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ate Douma (JIRA)" <jetspeed-...@portals.apache.org>
Subject [jira] Updated: (JS2-151) Security enhancements for password validation and enable/disable principals
Date Wed, 26 Oct 2005 13:34:56 GMT
     [ http://issues.apache.org/jira/browse/JS2-151?page=all ]

Ate Douma updated JS2-151:
--------------------------

    Fix Version: 2.0-FINAL
    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.

  was:
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.

        Version: 2.0-FINAL
                     (was: 2.0-M1)
    Environment: 

> Security enhancements for password validation and enable/disable principals
> ---------------------------------------------------------------------------
>
>          Key: JS2-151
>          URL: http://issues.apache.org/jira/browse/JS2-151
>      Project: Jetspeed 2
>         Type: Improvement
>   Components: Security
>     Versions: 2.0-FINAL
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>      Fix For: 2.0-FINAL

>
> 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.

-- 
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
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org


Mime
View raw message