You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by "Ate Douma (JIRA)" <je...@portals.apache.org> on 2005/09/06 02:43:30 UTC
[jira] Created: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
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
Assigned to: Ate Douma
Priority: Minor
Fix For: 2.0-M4
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.
--
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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12322702 ]
Ate Douma commented on JS2-359:
-------------------------------
What kind of feature would your interceptor provide?
Maybe it could be of interest to the Jetspeed community too ...
> 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
[jira] Closed: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=all ]
Ate Douma closed JS2-359:
-------------------------
Resolution: Fixed
> 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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12322700 ]
Ate Douma commented on JS2-359:
-------------------------------
James,
The interceptor used is currently set (and configured) through Spring too.
So, you could already provide your own interceptor by writing one from scratch or extend an existing one.
But after my refactorings, you can mix in your own interceptor while also using one or more of the (new) standard provided interceptors.
> 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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "James Liao (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12322701 ]
James Liao commented on JS2-359:
--------------------------------
Ate,
Great, can't wait to see it. If it works, I will replace my current solution by implement my own interceptor and mix with the standard one.
> 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
[jira] Resolved: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=all ]
Ate Douma resolved JS2-359:
---------------------------
Resolution: Fixed
> 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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "James Liao (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12322703 ]
James Liao commented on JS2-359:
--------------------------------
Ate,
I think the above you list is enough for the general purpose.
To me, the situation is a little complex. I have two authentication provider, the one provided by j2 and the one implemented by my own. I have some special logic for the user credential of my authentication repository.
> 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
[jira] Reopened: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=all ]
Ate Douma reopened JS2-359:
---------------------------
Sorry, didn't want to close but first only resolve this issue to allow feedback and possible changes be recorded against this issue.
> 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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12330234 ]
Ate Douma commented on JS2-359:
-------------------------------
Sorry, I mentioned the wrong issues in my previous comment: off by 100 :-)
Following is a corrected version of what I wanted to say (would be nice if JIRA allowed editing comments as well):
For password expiration management as well as setting the default for "Change Password on first Login" for newly created Users, I created a separate issue: JS2-371.
And for the simplification of the default Jetspeed security configuration issue: JS2-372
> 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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "James Liao (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12322698 ]
James Liao commented on JS2-359:
--------------------------------
+1. Thanks ate!
Correct me if I got misunderstanding. That is to say I can implement my own interceptor to satisfy my customer's special requirement and configuration through Spring without any hack code to j2.If it is true, that is great.
> 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
[jira] Commented: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ http://issues.apache.org/jira/browse/JS2-359?page=comments#action_12330233 ]
Ate Douma commented on JS2-359:
-------------------------------
For password expiration management as well as setting the default for "Change Password on first Login" for newly created Users, I created a separate issue: JS2-271.
And for the simplification of the default Jetspeed security configuration issue: JS2-272
> 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
[jira] Updated: (JS2-359) Provide a more flexible and less strict default configuration of InternalPasswordCredentialInterceptors
Posted by "Ate Douma (JIRA)" <je...@portals.apache.org>.
[ 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