gssapi/krbV need to be defined when missing

https://github.com/mikem23/koji-playground/commits/gssapi

If I try to auth to Brew with python-gssapi installed, I get an 'Invalid message type' error.

  File "/usr/share/koji-hub/kojixmlrpc.py", line 277, in handle_rpc
    return self._dispatch(method, params)
  File "/usr/share/koji-hub/kojixmlrpc.py", line 314, in _dispatch
    ret = koji.util.call_with_argcheck(func, params, opts)
  File "/usr/lib/python2.6/site-packages/koji/util.py", line 154, in call_with_argcheck
    return func(*args, **kwargs)
  File "/usr/lib/python2.6/site-packages/koji/auth.py", line 697, in krbLogin
    return context.session.krbLogin(*args, **opts)
  File "/usr/lib/python2.6/site-packages/koji/auth.py", line 313, in krbLogin
    options=krbV.AP_OPTS_MUTUAL_REQUIRED)
Krb5Error: (-1765328344, 'Invalid message type')

It's unclear to me whether the gssapi client code is expected to be compatible with the older server code. Using the same rpc call suggests that it should be, but the changes you've made in auth.py suggest maybe not.

Clients and servers don't always match up, and it's common for folks to use their client against multiple hubs. We're going to need be more graceful when a gssapi enabled client tries to authenticate to a non-gssapi hub.

The old code did indeed not work where the server is old and the client is new.
This should now work with this latest change.

Confirmed that old server new client works. Code needed a few tweaks, particularly for the gssapi-but-no-krbV case. Also fixed/extended the unit test. Changes here:

https://github.com/mikem23/koji-playground/commits/gssapi

That being said, I'm not sure I'm keen on the way we're overloading the existing rpc call. The way we detect a mismatch seems awkward. It might be saner to just make a new rpc call.

What's story with the magic number? (-1765328344)

Thanks for those!

Regarding overloading the RPC call, I'm fine with making a new gssapiLogin call instead if that's preferred. I just wanted to make sure we reuse as much of the current code as we can, but I'm guessing I can just factor those parts out.
Would you prefer a gssapiLogin call for the gssapi code paths on the server?

That "magic number" is the error code from krbV for "unknown message". I'm using it as an indicator that this is not a krbV message rather than any other error like "replay detected" or other such stuff, so that in those cases we don't fall back to gssapi if it's another error.

http://web.mit.edu/krb5/arch/i386_linux24/include/krb5.h code KRB5KRB_AP_ERR_MSG_TYPE

The code is now reworked, and it has a new gssapiLogin call.
The client determines via listMethods whether this method exists, and if it does AND gssapi is available on the client side, goes to use that codepath, and otherwise uses krbV.

It looks like you're hard-coding "host@" into the principal name. You should be using the krbservice option.

I'd very much like to deprecate our home-grown Kerberos auth. However, rather than just porting that logic to python-gssapi, I think we should modify the python client to generate a standard GSSAPI Negotiate header, and then configure the hub to support mod_auth_kerb. This would very similar to the way we support SSL, and would make it easier (possible) to support GSSAPI from other languages, like Java. Could we investigate this approach instead?

mikeb - agree, but this seems like this approach might be quicker way to help get rid of the dep in fedora. I guess it depends on how much work the latter approach is.
I've assumed this approach would depend upon moving to python-requests.

When the code is moved to python-requests, moving to gssapi is as simple as an additional import and saying auth=HTTPKerberosAuth() on the request.
So if the goal is to move to requests eventually, I would prefer to go with this patch for the time being and then move to use mod_auth_gssapi once koji moves to python-requests.

For now, I've modified the client patch to use krbservice@hostname.

What's the urgency to get rid of the dep?

For Fedora, the urgency is in moving our koji to kerberos without being a major pain for RHEL engineers (and other people that also use kerberos internally).
The reasoning here is that gssapi automatically selects the correct ccache (correct principal) if you have multiple sets of tickets (aka, you are logged in to fedoraproject.org and another one).

With krbV, we would need to tell people to run "kswitch" everytime they want to switch between RHEL and Fedora packaging work, whereas with gssapi that's all done automatically.

Was that explanation enough, or do you want more info or changes?

I don't love the idea of adding all this new code to a deprecated code path. Is there a way to use a Negotiate header without moving to python-requests? It seems like it could be added to the headers list in _prepCall(). Possibly by having krb_login() set the Negotiate header content as an attribute on the ClientSession, which _prepCall() could consume?

I'd just like to comment that mod_auth_kerb SHOULD NOT be used. Please use mod_auth_gssapi instead.

What is the timeline for Fedora to move to kerberos? We might actually want to move to requests before then anyway.

What is the timeline for Fedora to move to kerberos? We might actually want to move to requests before then anyway.

there is kerberos auth in staging infra now, as I understand it. with the idea of moving production as soon as is feasible

The kerberos auth provider is now ready and working in production. It works with koji and the lookaside cache.

As Ralph and Dennis have indicated, this is now live in Fedora Infrastructure, both staging and production, both the infrastructure and the koji configuration.
We are now patching all the user tools to silently transition.

If I may, I'd like to add a +1 to the idea that it'd be nice not to have to type "kswitch" ☺

unit test updates and one change here
https://github.com/mikem23/koji-playground/commits/gssapi

As Ralph and Dennis have indicated, this is now live in Fedora Infrastructure, both staging and production, both the infrastructure and the koji configuration.
We are now patching all the user tools to silently transition.

What exactly is live? Just this patch, or can I actually use krb auth on koji.fp.o now? If so, is there a doc on that? I'm having no luck finding any sort of page or announcement.

You can actually use krb auth for koji.fp.o now.
I am still working on the documentation et al, which is why I haven't announced it yet.
But if you just kinit $username@FEDORAPROJECT.ORG, you'll get a ticket you can immediately use at production koji and with an update to pyrpkg that's now in testing also for distgit.

This patch is not live in production because it hasn't been approved yet. It was in staging, until I just updated that with my reworked patch.

If you decide you want to wait for python-requests, I have a reworked patch submitted as https://github.com/mikem23/koji-playground/pull/1 against the use-requests2 branch.

Rebased, and added a small fix (setting KRB5_CLIENT_KTNAME) for clients, so that builders are fixed.

So our flag day (when we are planning on changing other tools as well) is 2016-12-12.
https://fedoraproject.org/wiki/ReleaseEngineering/FlagDay2016

So, just about 3 weeks from today (with thanksgiving holiday later this week).

It would be very nice to land this and have a release before then. :fingers_crossed:

Note there is now a PR for the use-requests-2 branch
https://pagure.io/koji/pull-request/213

The alternate implementation that Patrick linked above applies just fine on top of this.

successfully connected to hub
ciao, mikem!
You are using the hub at https://koji.fedoraproject.org/kojihub
Authenticated via Kerberos principal mikem@FEDORAPROJECT.ORG

Is there a doc on how to kinit with fp.o without blowing away my existing krb ticket with rh.c?

Moving to requests would be fine with me too as long as it's ready to go. ;)

Your other tickets are still there, use 'klist -A' to see them and 'kswitch user@domain' to switch which one is primary. My understanding is that this patch made it so you wouldn't need to switch, but perhaps I am mixing up patches, I'll defer to @puiterwijk here.

What @kevin said is correct, with a sidenote: multi-principal will work if you use a credential cache that supports multiple principals, like KEYRING or DIR (it's the top row in "klist").
If you have one of those, klist -A will show you all tickets you currently have that are not expired.

With plain Kerberos, Koji will only use the current primary principal, so you will need to run "kswitch -p $username@FEDORAPROJECT.ORG" or "kswitch -p username@EXAMPLE.COM" to make one or the other active, and selected by koji.

With GSSAPI. the selection of the correct principal is handled automatically.

@mikem If you want, I can apply either of my patches to our staging environment so we can try things out.

Ok, I guess it isn't working for me because my credential cache is "FILE:...". I guess I just need to set KRB5CCNAME to something else? What's the recommendation here?

Hmm, trying to use a KEYRING cache. Seems to work for koji, but other apps seem to be having trouble. Seems to break auth for thunderbird and firefox.

DIR seems to not share the problem, using this in krb5.conf:

default_ccache_name = DIR:/tmp/krb5ccdir_%{uid}

@mikem, I'm using KEYRING on rawhide without any problems (firefox and epiphany). I think upstream fixed a bug in the latest release. So I would file a bug if you still have problems on rawhide.

Commit 1d93396b fixes this pull-request