Re: Consolidate the security properties in roller.properties?
Team, if no objections, I'm going to go ahead tomorrow with the new
"authentication.method" flag, replacing the three below.
Regards,
Glen
On 07/30/2014 01:38 PM, Glen Mazza wrote:
Actually, this could wait for a future patch release, 5.1.1 or
whatever, if desired. Requiring a major release whenever we need to
have users make a minor change to their roller-custom.properties file
as a part of a Roller upgrade, as I suggested below, is major overkill
for a small project such as ours.
Glen
On 07/29/2014 04:35 PM, Glen Mazza wrote:
Hi Team, it may be a good time for us to consolidate our security
settings in roller.properties from our current three properties to
just one. It would be best to get such a change into Roller 5.1
because for backward compatibility reasons we're not going to be able
to put it into a subsequent minor patch release.
Presently we have three different security flags:
authentication.cma.enabled = true/false (i.e., tomcat-users.xml file)
users.sso.enabled = true/false (i.e., LDAP)
authentication.openid = disabled/hybrid/only (Roller DB only, either
Roller DB or OpenID, OpenID only)
The problem with coding three properties where one will do is that
security holes start to develop as we code with just one or two of
the properties where we actually need all three. Also, users may
inadvertently set unsupported combinations of the three and as a
result not get the security they're expecting. Finally, it's not
obvious as it could be from the above settings the type of security
offered by each setting.
I propose we switch to one flag in 5.1 called "authentication.method"
and it will have only one of five possible values:
db (use roller database, this will be the default value defined in
roller.properties)
ldap (equivalent to old users.sso.enabled=true)
db-openid ("hybrid" above, users can use DB or OpenID but not both)
openid ("only" above, openID alone supported)
cma (= authentication.cma.enabled=true).
If "db" seems too terse/vague, we can use "rollerdb" instead to
clarify the DB it's using. If we have additional auth methods in the
future, we'll add other constants, using hyphens such as "db-openid"
above instead of additional properties if we're allowing multiple
auth methods simultaneously. [Incidentally, I'm not sure if
authentication.cma.enabled (i.e., tomcat-users.xml file) even works
in Roller today--the web.xml probably won't support it--but we have
some coding for it within the application. We may wish to pull this
option out.]
Another advantage of this switch is that by leaving the ambiguous
"users.sso.enabled" ("sso" can mean multiple things--OpenID, LDAP,
CMA) and replacing it with an explicit "ldap" flag, we can possibly
start moving towards LDAP security without the users needing to
modify their security.xml, they would just need to configure their
roller-custom.properties instead.
WDYT?
Regards,
Glen
Re: Consolidate the security properties in roller.properties?
Actually, this could wait for a future patch release, 5.1.1 or whatever,
if desired. Requiring a major release whenever we need to have users
make a minor change to their roller-custom.properties file as a part of
a Roller upgrade, as I suggested below, is major overkill for a small
project such as ours.
Glen
On 07/29/2014 04:35 PM, Glen Mazza wrote:
Hi Team, it may be a good time for us to consolidate our security
settings in roller.properties from our current three properties to
just one. It would be best to get such a change into Roller 5.1
because for backward compatibility reasons we're not going to be able
to put it into a subsequent minor patch release.
Presently we have three different security flags:
authentication.cma.enabled = true/false (i.e., tomcat-users.xml file)
users.sso.enabled = true/false (i.e., LDAP)
authentication.openid = disabled/hybrid/only (Roller DB only, either
Roller DB or OpenID, OpenID only)
The problem with coding three properties where one will do is that
security holes start to develop as we code with just one or two of the
properties where we actually need all three. Also, users may
inadvertently set unsupported combinations of the three and as a
result not get the security they're expecting. Finally, it's not
obvious as it could be from the above settings the type of security
offered by each setting.
I propose we switch to one flag in 5.1 called "authentication.method"
and it will have only one of five possible values:
db (use roller database, this will be the default value defined in
roller.properties)
ldap (equivalent to old users.sso.enabled=true)
db-openid ("hybrid" above, users can use DB or OpenID but not both)
openid ("only" above, openID alone supported)
cma (= authentication.cma.enabled=true).
If "db" seems too terse/vague, we can use "rollerdb" instead to
clarify the DB it's using. If we have additional auth methods in the
future, we'll add other constants, using hyphens such as "db-openid"
above instead of additional properties if we're allowing multiple auth
methods simultaneously. [Incidentally, I'm not sure if
authentication.cma.enabled (i.e., tomcat-users.xml file) even works in
Roller today--the web.xml probably won't support it--but we have some
coding for it within the application. We may wish to pull this option
out.]
Another advantage of this switch is that by leaving the ambiguous
"users.sso.enabled" ("sso" can mean multiple things--OpenID, LDAP,
CMA) and replacing it with an explicit "ldap" flag, we can possibly
start moving towards LDAP security without the users needing to modify
their security.xml, they would just need to configure their
roller-custom.properties instead.
WDYT?
Regards,
Glen
Consolidate the security properties in roller.properties?
Hi Team, it may be a good time for us to consolidate our security
settings in roller.properties from our current three properties to just
one. It would be best to get such a change into Roller 5.1 because for
backward compatibility reasons we're not going to be able to put it into
a subsequent minor patch release.
Presently we have three different security flags:
authentication.cma.enabled = true/false (i.e., tomcat-users.xml file)
users.sso.enabled = true/false (i.e., LDAP)
authentication.openid = disabled/hybrid/only (Roller DB only, either
Roller DB or OpenID, OpenID only)
The problem with coding three properties where one will do is that
security holes start to develop as we code with just one or two of the
properties where we actually need all three. Also, users may
inadvertently set unsupported combinations of the three and as a result
not get the security they're expecting. Finally, it's not obvious as it
could be from the above settings the type of security offered by each
setting.
I propose we switch to one flag in 5.1 called "authentication.method"
and it will have only one of five possible values:
db (use roller database, this will be the default value defined in
roller.properties)
ldap (equivalent to old users.sso.enabled=true)
db-openid ("hybrid" above, users can use DB or OpenID but not both)
openid ("only" above, openID alone supported)
cma (= authentication.cma.enabled=true).
If "db" seems too terse/vague, we can use "rollerdb" instead to clarify
the DB it's using. If we have additional auth methods in the future,
we'll add other constants, using hyphens such as "db-openid" above
instead of additional properties if we're allowing multiple auth methods
simultaneously. [Incidentally, I'm not sure if
authentication.cma.enabled (i.e., tomcat-users.xml file) even works in
Roller today--the web.xml probably won't support it--but we have some
coding for it within the application. We may wish to pull this option out.]
Another advantage of this switch is that by leaving the ambiguous
"users.sso.enabled" ("sso" can mean multiple things--OpenID, LDAP, CMA)
and replacing it with an explicit "ldap" flag, we can possibly start
moving towards LDAP security without the users needing to modify their
security.xml, they would just need to configure their
roller-custom.properties instead.
WDYT?
Regards,
Glen
