Tom Jones <t...@oxix.org> writes:
> We use fully qualified principal names in our Webauth service
> ("WebKdcLocalRealms none").
> When we recently added HTTP Negotiate support to the login page, we
> found that in Webauth's REMOTE_USER support, the set of permitted realms
> and the set of realms for which Webauth strips off the realm name were
> both controlled by a single setting: @REMUSER_REALMS. This left us
> unable to enable our local realm, whilst leaving the full principal name
> intact. It also left us unable to configure this part of Webauth not to
> care which realms it was able to deal with, and just leave it to the
> cross-realm relationships. In mod_webkdc, this is done by leaving
> WebKdcPermittedRealms unset.
> The attached patch introduces separate @REMUSER_PERMITTED_REALMS and
> @REMUSER_LOCAL_REALMS settings. Both of these can be set to the same
> value via @REMUSER_REALMS, thus providing backwards compatibility.
> Using this patch has allowed us to meet our site's requirements.
This looks great to me. Thanks! I'll apply this for the next release.
> This does change the semantics of leaving @REMUSER_REALMS unset from
> "all denied" to "all permitted", so it's not completely backwards
> compatible. For this to be an issue, someone would have to be currently
> running with $REMUSER_ENABLED on, but relying on @REMUSER_REALMS being
> empty to disallow all authentications via this mechanism. If this is
> judged to be realistic, the patch may need a bit of redesign.
I think that's fine. I agree that this configuration is not particularly
likely.
--
Russ Allbery <ea...@windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
