[MERGE] GSSAPI Authentication support for HTTP

[Jelmer Vernooij]

Hi Vincent,

Thanks for the review.

On Tue, 2009-02-17 at 11:29 +0100, Vincent Ladeuil wrote:
> >>>>> "Jelmer" == Jelmer Vernooij <jelmer at samba.org> writes:

>     Jelmer> I've tested it here locally against a couple of
>     Jelmer> servers, but it's hard to do automated tests, as
>     Jelmer> setting up a KDC + mod_auth_kerberos is nontrivial.
> 
> You should try it via the lp:~vila/bzr/local_test_server plugin
> anyway. That will document the steps you went through to get a
> working Kerberos installation (and what means KDC ?).
The KDC is the main Kerberos credentials server, which provides tickets
that users can then use to authenticate against various services. 

>     Jelmer> Since this code is only executed for
>     Jelmer> "WWW-Authenticate: Negotiate", it can potentially
>     Jelmer> only break in situations that didn't work previously
>     Jelmer> anyway.
> Which is a bit short of a reason to not test it :-)
> 
> Look at bzrlib.test.test_http.TestActivity for a way to test an
> unmodified client against a server for which all responses are
> pre-canned and bzrlib.test.test_http.TestAuth for tests currently
> done for the supported authentication schemes.
pre-canned responses won't work, since the Apache server won't be able
to validate the tickets unless you have a proper Keytab and KDC running
for it. The client won't be able to obtain tickets to send to the server
without a connection to a KDC. 

> Recording the session against a working http server with Kerberos
> (with some random user/pass combo, but note that the tests use
> joe/foo) should get most of the needed responses (AFAICT from the
> client side you propose below).
Unfortunately it's not as simple as that (see my explanation above for
why canned responses won't work). Setting up the server environment is
nontrivial:

 * The Apache server with mod_auth_kerb will need to have a keytab file
that it can use to obtain credentials from the KDC. 
 * A KDC needs to be set up (/etc/krb5.conf and a kdc-specific conf
file) with reverse DNS set up properly or some custom host -> realm
mapping in /etc/krb5.conf
 * An account has to be set up for the apache server in the KDC, named
something like HTTP@<hostname>
 * An account has to be created for the user
 * whatever test we run has to have access to the krb5.conf file in the
test environment, and has to run "kinit" to obtain the initial Kerberos
credentials

>     Jelmer> At the moment, it's necessary to specify a username
>     Jelmer> in the URL as bzr requires it for authentication,
>     Jelmer> even though this is not required by
>     Jelmer> Kerberos/GSSAPI. The specified username is ignored.
> Patches welcome even if it implements only the part necessary to
> make Negotiate remove that constraint while leaving it for the
> other schemes.
I'll hopefully have a look at providing a fix for this in the next
couple of days.

> Does it work for https too ? If so, it's worth mentioning (and
> testing :-).
Yeah, it works for HTTPS as well. The service name is still HTTP in
those situations though. I've updated NEWS.

>     Jelmer> +    def _auth_match_kerberos(self, auth):
>     Jelmer> +        """Try to create a GSSAPI response for authenticating against a host."""
>     Jelmer> +        try:
>     Jelmer> +            import kerberos
>     Jelmer> +        except ImportError:
>     Jelmer> +            return None
> That would be better done at the module level (setting some flag
> on import errors) so that the import is attempted only once
> instead of once by *connection*.
Thanks, fixed in the attached patch.

>     Jelmer> +        ret, vc = kerberos.authGSSClientInit("HTTP@%(host)s" % auth)
> Is it valid for https too ?
Yep, but the service name is always HTTP.

>     Jelmer> +        if ret < 1:
>     Jelmer> +            trace.warning('Unable to create GSSAPI context for %(host)s', auth)
>     Jelmer> +            return None
> 
> What kind of error is that ? Shouldn't we give more feedback about
> some bad credentials is it just some internal check that should
> cover possible bugs in the implementation or server setup ?
Generally, this should never happen - only in the case of an
  incorrectly setup server. I've now added the error code to the
 message as well, but I'm not sure how much use it is.

>     Jelmer> +        ret = kerberos.authGSSClientStep(vc, "")
>     Jelmer> +        if ret < 0:
>     Jelmer> +            trace.mutter('authGSSClientStep failed: %d', ret)
>     Jelmer> +            return None
>     Jelmer> +        return kerberos.authGSSClientResponse(vc)
>     Jelmer> +
>     Jelmer> +    def build_auth_header(self, auth, request):
>     Jelmer> +        return "Negotiate %s" % auth['negotiate_response']
>     Jelmer> +
>     Jelmer> +    def auth_params_reusable(self, auth):
>     Jelmer> +        # If the auth scheme is known, it means a previous
>     Jelmer> +        # authentication was successful, all information is
>     Jelmer> +        # available, no further checks are needed.
>     Jelmer> +        return auth.get('scheme', None) == 'negotiate'
> 
> Shouldn't you test the 'negotiate_response' here to ensure you
> really authenticate before ?
Thanks, fixed.

Cheers,

Jelmer
-- 
Jelmer Vernooij <jelmer at samba.org> - http://samba.org/~jelmer/
Jabber: jelmer at jabber.fsfe.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http-gssapi.diff
Type: text/x-patch
Size: 8656 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090217/4aff5129/attachment-0001.bin