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-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Date Tue, 06 Sep 2005 00:47:30 GMT
     [ http://issues.apache.org/jira/browse/JS2-359?page=all ]

Ate Douma updated JS2-359:
--------------------------

    Description: 
The default password credential validation and handling is rather (military) strict in that
it
- enforces a password change on first login
- keeps a history of already used (and thus not allowed to be used again) passwords
- sets a max lifespan on each password
- requires a minimum length of 6 with at least 2 digits.

All these rules and features are already configurable through springframework right now.
But because these are enforced by an interceptor hierarchy, disabling one rule like max lifespan
or required password change on first login, 
requires replacing an interceptor or modifying the interceptor hierarchy.

I'm going to provide a more flexible solution by changing the DefaultCredentialHandler to
accept a list of InternalPasswordCredentialInterceptors in its constructor.
The DefaultCredentialHandler will then invoke each provided interceptor in the list .
And I will breakdown the current complex interceptors into simple interceptors which each
only providing/enforcing only one rule or feature:
- password encoder: encodes a not-yet-encoded password on first load  
- password history: configurable history of passwords which cannot be reused
- change password on first use (note: the password encoder interceptor will enforce this when
the not-yet-encoded password turns out to be invalid)
- password expiration: configurable password max lifespan
- max authentication failures: configurable number of validation errors (in a row) allowed

Once this is in place and working we can decide which of these interceptors should be used
in the default configuration for Jetspeed-2.
And I will provide a document how to use these interceptors including an example how to enforce
the same strict rules of our current configuration.

Further enhancements I'd like to implement are:
- only temporarily disabling of a credential after max authentication failures (like 30 minutes)
- disable password expiration for certain credentials (for example an admin credential) and/or
certain users/groups/roles
But I'm not sure yet I'll be able to provide these additional features without database model
enhancements.

  was:
The default configuration is furthermore rather (military) strict in that it
- enforces a password change on first login
- keeps a history of already used (and thus not allowed to be used again) passwords
- sets a max lifespan on each password
- requires a minimum length of 6 with at least 2 digits.

All these rules and features are already configurable through springframework right now.
But because these are enforced by an interceptor hierarchy, disabling one rule like max lifespan
or required password change on first login, 
requires replacing an interceptor or modifying the interceptor hierarchy.

I'm going to provide a more flexible solution by changing the DefaultCredentialHandler to
accept a list of InternalPasswordCredentialInterceptors in its constructor.
The DefaultCredentialHandler will then invoke each provided interceptor in the list .
And I will breakdown the current complex interceptors into simple interceptors which each
only providing/enforcing only one rule or feature:
- password encoder: encodes a not-yet-encoded password on first load  
- password history: configurable history of passwords which cannot be reused
- change password on first use (note: the password encoder interceptor will enforce this when
the not-yet-encoded password turns out to be invalid)
- password expiration: configurable password max lifespan
- max authentication failures: configurable number of validation errors (in a row) allowed

Once this is in place and working we can decide which of these interceptors should be used
in the default configuration for Jetspeed-2.
And I will provide a document how to use these interceptors including an example how to enforce
the same strict rules of our current configuration.

Further enhancements I'd like to implement are:
- only temporarily disabling of a credential after max authentication failures (like 30 minutes)
- disable password expiration for certain credentials (for example an admin credential) and/or
certain users/groups/roles
But I'm not sure yet I'll be able to provide these additional features without database model
enhancements.


Small correction to an accidentally to quickly submitted issue description.

> Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
> -------------------------------------------------------------------------------------------------------
>
>          Key: JS2-359
>          URL: http://issues.apache.org/jira/browse/JS2-359
>      Project: Jetspeed 2
>         Type: Improvement
>   Components: Security
>     Versions: 2.0-M4
>     Reporter: Ate Douma
>     Assignee: Ate Douma
>     Priority: Minor
>      Fix For: 2.0-M4

>
> The default password credential validation and handling is rather (military) strict in
that it
> - enforces a password change on first login
> - keeps a history of already used (and thus not allowed to be used again) passwords
> - sets a max lifespan on each password
> - requires a minimum length of 6 with at least 2 digits.
> All these rules and features are already configurable through springframework right now.
> But because these are enforced by an interceptor hierarchy, disabling one rule like max
lifespan or required password change on first login, 
> requires replacing an interceptor or modifying the interceptor hierarchy.
> I'm going to provide a more flexible solution by changing the DefaultCredentialHandler
to accept a list of InternalPasswordCredentialInterceptors in its constructor.
> The DefaultCredentialHandler will then invoke each provided interceptor in the list .
> And I will breakdown the current complex interceptors into simple interceptors which
each only providing/enforcing only one rule or feature:
> - password encoder: encodes a not-yet-encoded password on first load  
> - password history: configurable history of passwords which cannot be reused
> - change password on first use (note: the password encoder interceptor will enforce this
when the not-yet-encoded password turns out to be invalid)
> - password expiration: configurable password max lifespan
> - max authentication failures: configurable number of validation errors (in a row) allowed
> Once this is in place and working we can decide which of these interceptors should be
used in the default configuration for Jetspeed-2.
> And I will provide a document how to use these interceptors including an example how
to enforce the same strict rules of our current configuration.
> Further enhancements I'd like to implement are:
> - only temporarily disabling of a credential after max authentication failures (like
30 minutes)
> - disable password expiration for certain credentials (for example an admin credential)
and/or certain users/groups/roles
> But I'm not sure yet I'll be able to provide these additional features without database
model enhancements.

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