Re: [J2] Security enhancements proposal
Randy Watler wrote: Ate, +1 from me that will get you to maybe +3.5 then. :) Thanks for your support too Randy! BTW, we do our login from the decorator and do not depend on the login portlet. We do not require password changes and other admin functions from the decorator, (we can certainly put those functions in a real page), but we want to continue to use login/logout from there. Just FYI, You won't be harmed by these enhancements which will be optional and not default enabled. Randy Ate Douma wrote: Having received a positive response from Roland S. Ong, a further +3 (mine included) and no other reactions I'll create an new feature issue for this and start working on it right away. Regards, Ate Ate Douma wrote: I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). We already had a first version of the password validation implemented partly *outside* J2 using triggers on the SECURITY_CREDENTIAL table (we are using oracle) and a custom UserManagerImpl. But, since the refactoring of the Security with the new Handlers e.a. our implementation doesn't work anymore anymore. So, I'm faced with fixing our current implementation or writing a new one myself which I then would like to integrate into J2. I think this would be a great (optional) enhancement for most (company) portal implementations. To be able to integrate this into J2 though, I will need a few enhancements to the security object model. Those enhancements won't need to be used by the simple default security handlers but would be available when needed *and* used/enforced when set in a non-default way. The needed enhancements I now foresee are: - 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*. Note, I created an issue for this feature (on groups and roles) quite some time ago already: http://issues.apache.org/jira/browse/JS2-27 I just never got around implementing it 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
Re: [J2] Security enhancements proposal
Ate, +1 from me that will get you to maybe +3.5 then. :) BTW, we do our login from the decorator and do not depend on the login portlet. We do not require password changes and other admin functions from the decorator, (we can certainly put those functions in a real page), but we want to continue to use login/logout from there. Just FYI, Randy Ate Douma wrote: Having received a positive response from Roland S. Ong, a further +3 (mine included) and no other reactions I'll create an new feature issue for this and start working on it right away. Regards, Ate Ate Douma wrote: I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). We already had a first version of the password validation implemented partly *outside* J2 using triggers on the SECURITY_CREDENTIAL table (we are using oracle) and a custom UserManagerImpl. But, since the refactoring of the Security with the new Handlers e.a. our implementation doesn't work anymore anymore. So, I'm faced with fixing our current implementation or writing a new one myself which I then would like to integrate into J2. I think this would be a great (optional) enhancement for most (company) portal implementations. To be able to integrate this into J2 though, I will need a few enhancements to the security object model. Those enhancements won't need to be used by the simple default security handlers but would be available when needed *and* used/enforced when set in a non-default way. The needed enhancements I now foresee are: - 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*. Note, I created an issue for this feature (on groups and roles) quite some time ago already: http://issues.apache.org/jira/browse/JS2-27 I just never got around implementing it 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 additiona
Re: [J2] Security enhancements proposal
Having received a positive response from Roland S. Ong, a further +3 (mine included) and no other reactions I'll create an new feature issue for this and start working on it right away. Regards, Ate Ate Douma wrote: I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). We already had a first version of the password validation implemented partly *outside* J2 using triggers on the SECURITY_CREDENTIAL table (we are using oracle) and a custom UserManagerImpl. But, since the refactoring of the Security with the new Handlers e.a. our implementation doesn't work anymore anymore. So, I'm faced with fixing our current implementation or writing a new one myself which I then would like to integrate into J2. I think this would be a great (optional) enhancement for most (company) portal implementations. To be able to integrate this into J2 though, I will need a few enhancements to the security object model. Those enhancements won't need to be used by the simple default security handlers but would be available when needed *and* used/enforced when set in a non-default way. The needed enhancements I now foresee are: - 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*. Note, I created an issue for this feature (on groups and roles) quite some time ago already: http://issues.apache.org/jira/browse/JS2-27 I just never got around implementing it 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) Not sure if I got everything needed now specified above, but this is the general idea. I need to start with this real soon and if considered a + will get it in J2 before the upcoming release. Anyone cares to comment/vote? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For a
Re: [J2] Security enhancements proposal
David Sean Taylor wrote: Ate Douma wrote: I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). +1 on the overall proposal. Thats a lot features, quite a few more than in Jetspeed-1. Will these features be applied system wide, or per user, per group Just system wide for now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [J2] Security enhancements proposal
Ate Douma wrote: I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). +1 on the overall proposal. Thats a lot features, quite a few more than in Jetspeed-1. Will these features be applied system wide, or per user, per group -- David Sean Taylor Bluesunrise Software [EMAIL PROTECTED] [office] +01 707 773 4646 [mobile] +01 707 529 9194 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [J2] Security enhancements proposal
Ate, +1. I believe this would be a great enhancements to the current framework. Regards, David. --- Ate Douma <[EMAIL PROTECTED]> wrote: > I've the requirement to implement an enhanced > security model for J2 concerning password > validation. > I must meet the following requirements: > 1) storing password encoded (Base64 will do for now) > 2) requiring a minimum length and a minimum number > of numeric characters in a password > 3) keeping a history (queue) of previously used > password (10) and preventing a user to reuse one > from this queue > 4) automatically expire password after a certain > time (60 days) > 5) warning a user its password is going to be > expired (configurable time before, 10 days) > 6) locking a user out when the current password is > expired > 7) forcing a user to change a password on first use > 8) three strikes out: disable a password after three > (or another number of) failures to authenticate, > reset check after success > > 9) Furthermore, I must implement enable/disable of > principals (users,groups,roles). > > We already had a first version of the password > validation implemented partly *outside* J2 using > triggers on the SECURITY_CREDENTIAL table > (we are using oracle) and a custom UserManagerImpl. > > But, since the refactoring of the Security with the > new Handlers e.a. our implementation doesn't work > anymore anymore. > > So, I'm faced with fixing our current implementation > or writing a new one myself which I then would like > to integrate into J2. > I think this would be a great (optional) enhancement > for most (company) portal implementations. > > To be able to integrate this into J2 though, I will > need a few enhancements to the security object > model. Those enhancements won't need to > be used by the simple default security handlers but > would be available when needed *and* used/enforced > when set in a non-default way. > > The needed enhancements I now foresee are: > > - 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*. > Note, I created an issue for this feature > (on groups and roles) quite some time ago already: > > http://issues.apache.org/jira/browse/JS2-27 > I just never got around implementing it > 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) > > Not sure if I got everything needed now specified > above, but this is the general idea. > > I need to start with this real soon and if > considered a + will get it in J2 before
RE: [J2] Security enhancements proposal
Great features! That would be a perfect compliance to Sarbanes-Oxley (SOX) audit. .roland Vishay Phils.,Inc. -Original Message- From: Ate Douma [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 19, 2004 8:11 AM To: Jetspeed Developers List Subject: [J2] Security enhancements proposal I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). We already had a first version of the password validation implemented partly *outside* J2 using triggers on the SECURITY_CREDENTIAL table (we are using oracle) and a custom UserManagerImpl. But, since the refactoring of the Security with the new Handlers e.a. our implementation doesn't work anymore anymore. So, I'm faced with fixing our current implementation or writing a new one myself which I then would like to integrate into J2. I think this would be a great (optional) enhancement for most (company) portal implementations. To be able to integrate this into J2 though, I will need a few enhancements to the security object model. Those enhancements won't need to be used by the simple default security handlers but would be available when needed *and* used/enforced when set in a non-default way. The needed enhancements I now foresee are: - 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*. Note, I created an issue for this feature (on groups and roles) quite some time ago already: http://issues.apache.org/jira/browse/JS2-27 I just never got around implementing it 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) Not sure if I got everything needed now specified above, but this is the general idea. I need to start with this real soon and if considered a + will get it in J2 before the upcoming release. Anyone care
[J2] Security enhancements proposal
I've the requirement to implement an enhanced security model for J2 concerning password validation. I must meet the following requirements: 1) storing password encoded (Base64 will do for now) 2) requiring a minimum length and a minimum number of numeric characters in a password 3) keeping a history (queue) of previously used password (10) and preventing a user to reuse one from this queue 4) automatically expire password after a certain time (60 days) 5) warning a user its password is going to be expired (configurable time before, 10 days) 6) locking a user out when the current password is expired 7) forcing a user to change a password on first use 8) three strikes out: disable a password after three (or another number of) failures to authenticate, reset check after success 9) Furthermore, I must implement enable/disable of principals (users,groups,roles). We already had a first version of the password validation implemented partly *outside* J2 using triggers on the SECURITY_CREDENTIAL table (we are using oracle) and a custom UserManagerImpl. But, since the refactoring of the Security with the new Handlers e.a. our implementation doesn't work anymore anymore. So, I'm faced with fixing our current implementation or writing a new one myself which I then would like to integrate into J2. I think this would be a great (optional) enhancement for most (company) portal implementations. To be able to integrate this into J2 though, I will need a few enhancements to the security object model. Those enhancements won't need to be used by the simple default security handlers but would be available when needed *and* used/enforced when set in a non-default way. The needed enhancements I now foresee are: - 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*. Note, I created an issue for this feature (on groups and roles) quite some time ago already: http://issues.apache.org/jira/browse/JS2-27 I just never got around implementing it 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) Not sure if I got everything needed now specified above, but this is the general idea. I need to start with this real soon and if considered a + will get it in J2 before the upcoming release. Anyone cares to comment/vote? Regards, Ate - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
