|
SSLUserName is an evil kludge in our global configuration that interferes with mod_auth_optional, complicates debugging of authentication problems, and cannot be disabled on a per-user basis once enabled globally. We need to get rid of it.
To quote from the scripts-commits@ thread on this issue:
andersk (r409 commit):
Remove SSLUserName, because mod_auth_sslcert is better and having the wrong REMOTE_USER set is confusing.
presbrey:
Its fine if you want to change that behavior from now on but you should certainly leave the old setting for everyone else who quite possibly depend on the old format of the value in the code of their scripts. This is a common issue with global configs.
andersk:
I had done a quick survey of the way REMOTE_USER was used on our vhosts, and didn't notice any obvious problems. We have always been telling users to use SSL_CLIENT_S_DN_Email, anyway, and the fact that REMOTE_USER happened to contain the same value was undocumented. Obviously I can't check every use and there could be new problems, but they will be reported and quickly solved, just like when various PHP extensions were disabled.
(This highlights the need for a good way to inform our users of configuration changes. Is scripts-announce still a useful list to send them to?)
Now that we have more powerful Apache modules for SSL authentication, the SSLUserName hack only gets in the way. For example, with mod_auth_sslcert's AuthSSLCertStripSuffix enabled along with AuthOptional?, I believe that a user with a valid certificate that doesn't match the suffix will still get the REMOTE_USER left over from SSLUserName even though they shouldn't. It's also a pain for debugging that the only side effects of authentication not being properly set up are a @MIT.EDU appended to REMOTE_USER, and mysterious failures when you try to use Apache-level authorization.
I see that you went and reverted my change on the two servers, without making an svn commit. It's fine to let changes lie around uncommited for a little while, but please send email when you do so. Unless you can point to something specific that broke, I'm going to redisable SSLUserName some time tomorrow.
presbrey:
Removing the SSLUserName directive results in a blank REMOTE_USER variable for anyone who hasn't set "AuthType? SSLCert" even when "SSLVerifyClient require" is set.
Surveying the vhosts doesn't quit do it. This change affects everyone on the scripts and scripts-cert hosts as well.
quentin:
I know I'm using REMOTE_USER on one of my sites; rather, I'm using Trac's default handling of REMOTE_USER.
andersk:
But that's part of my point--the scripts server shouldn't be authenticating visitors to scripts that didn't explicitly ask for it. If Trac honors REMOTE_USER by default, then it should be up to the owner to say what a user is, not our global configuration.
Note that, although you can specify SSLUserName in .htaccess if you know you want it, there is no way to _unset_ it if you don't!
quentin:
I don't think it's a good idea to make a non-backwards-compatible change to the way we handle it.
andersk:
I was not aware that people were depending on this broken behavior, so I agree that the change should probably be handled a bit more carefully. Do you think it would be sufficient for this to be part of a mail to scripts-announce, or do you have other suggestions for alerting users?
Regardless of how users are notified, temporarily breaking some scripts that were written with bad assumptions is inevitable. But I think the impact here will be minimal and I'm willing to deal with a few extra support requests.
quentin:
Can I still achieve the same results by configuring mod_auth_sslcert? I don't want authz, just authn.
andersk:
There are plenty of options:
- Alternatively, you can use SSL_CLIENT_S_DN_Email directly instead of assuming that REMOTE_USER will be the same thing.
|
