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
