Retrieve Creds from a user cache about python-gssapi

[frozencemetery]

First of all, thanks for working on this API. By far the most usable solution i've found on the web so far. And the docs are pretty good too! This is not a bug, I'm just looking for help implementing something using your wrapper.

Hi! Thanks, hopefully we can provide some assistance as well.

I'm having some trouble with the acquire_cred_from() method. Which I see is an extension, but i'm wondering if you can help me. I've done a kinit as a user, and i'm hoping to use this method to acquire the cred and forward it to a remote host. Am I understanding this function correctly?

I think you probably want init_sec_context(), if I understand what you're trying to do correctly. The normal workflow is that one end of a connection will call init_sec_context() and send the resulting payload to the other end, while the other end calls accept_sec_context() on the payload.

In your documentation it says that the cred store needs to be a dict. Do you know what information needs to be in the dict?

We do a conversion of the Python dict to the format that the underlying GSSAPI layer expects without checking presence/absence of fields, since there are different ways to call this function. Unfortunately this extension didn't get an RFC, so the best documentation available on what it can take seems to be our test, or if you're more familiar with C, krb5's test and the thing that calls it. Digging through the krb5 source, it appears that the possible ways to call here are None (which translates to GSS_C_NO_CRED_STORE) or as a dict possibly containing entries for any of: "ccache", "client_keytab", "keytab", or "rcache". @DirectXMan12 since you wrote the code that interfaces with the cred store extension, do you have anything to add here?

I have one other question, which is about the acquire_cred_with_password() function. It seems that when I use that function to acquire credentials, my password is stored in plain text in the credentials object. Is this expected behaviour?

We don't do any fancy handling on credentials objects, so I expect that it is. However, this is probably not an issue since credentials are generally treated as secret: that is, one does not pass credentials around the network, to untrusted parties, etc. (see above for more information on how the handshake usually works). If, on the other hand, you're concerned about processes having direct access to credentials, the GSS-Proxy might be able to help.

Hope that helps!

[DirectXMan12]

I'm having some trouble with the acquire_cred_from() method. Which I see is an extension, but i'm wondering if you can help me. I've done a kinit as a user, and i'm hoping to use this method to acquire the cred and forward it to a remote host. Am I understanding this function correctly?

I think you probably want init_sec_context(), if I understand what you're trying to do correctly. The normal workflow is that one end of a connection will call init_sec_context() and send the resulting payload to the other end, while the other end calls accept_sec_context() on the payload.

To provide further detail, by default, acquiring credentials is done from "default" locations -- the main ccache and keytab. If the user has already kinited, these credentials will become the "default" credentials in GSSAPI; if you acquire credentials (using acquire_cred or the Credentials constructor) with no name, or if you pass no credentials to init_sec_context/the SecurityContext constructor, these are the credentials that will be used.

acquire_cred_from is used if you need to acquire from an alternate ccache or keytab that is not the main one.

Digging through the krb5 source, it appears that the possible ways to call here are None (which translates to GSS_C_NO_CRED_STORE) or as a dict possibly containing entries for any of: "ccache", "client_keytab", "keytab", or "rcache". @DirectXMan12 since you wrote the code that interfaces with the cred store extension, do you have anything to add here?

That's correct, AFAIK.

However, this is probably not an issue since credentials are generally treated as secret: that is, one does not pass credentials around the network, to untrusted parties, etc. (see above for more information on how the handshake usually works).

It's important to note that export_cred is designed to be used to pass credentials between threads and processes, not over the network. If all you want to do is establish a session with a remote host (for auth, encryption, or both), you simply want to establish a security context. If you're trying to delegate credentials (so that the remote host can establish a new context on behalf of the user), you'll need to have used kinit -f to get a forwardable ticket (see, for instance, https://github.com/pythongssapi/python-gssapi/blob/master/gssapi/tests/test_raw.py#L435, which shows an S4U delegation).

[mogthesprog]

Hi guys,

Sorry for the slow reply.

Thanks for all the information, this has cleared up so many things about the API. After posting the question I realised I should have been using Credentials.aquire(). I'm just writing some point to point communication using twisted so that I can try the init_sec_context with another host. This info will make the gssapi part of that process much easier.

Out of curiosity, if I wanted to use a different credentials store, what could I use to store the creds? Would I have to store in a file or could I store in a database of some sort?

Again, cheers for the helps guys. If you want a hand writing docs, let me know. Understanding Kerberos and GSSAPI has been a pretty steep learning curve!

Cheers,

Morgan

[DirectXMan12]

Out of curiosity, if I wanted to use a different credentials store, what could I use to store the creds? Would I have to store in a file or could I store in a database of some sort?

The "store" part is controlled by the underlying mechanism's library (for instance MIT krb5). Each mechanism has different "stores" that it accepts -- krb5 has "ccache", "client_keytab", "keytab", or "rcache", which are all file-based, IIRC.

If you want a hand writing docs, let me know.

We'd be happy to have PRs with any documentation fixes that you think would make things clearer.

[simo5]

On Thu, 2016-01-07 at 10:15 -0800, Solly Ross wrote:

Out of curiosity, if I wanted to use a different credentials store,
what could I use to store the creds? Would I have to store in a file
or could I store in a database of some sort?

The "store" part is controlled by the underlying mechanism's library
(for instance MIT krb5). Each mechanism has different "stores" that
it accepts -- krb5 has "ccache", "client_keytab", "keytab", or
"rcache", which are all file-based, IIRC.

All these stores can be fully qualified with a type, so they are not
necessary file based (though a missing identifier defaults to FILE:)

If you want a hand writing docs, let me know.

We'd be happy to have PRs with any documentation fixes that you think
would make things clearer.

+1

Simo.

Simo Sorce * Red Hat, Inc * New York

[frozencemetery]

(Closing this for triage reasons. If you have more questions, please do ask them on irc or here; we are happy to help.)

[mogthesprog]

Thanks for all the help guys. Really appreciate it.

I've been busy with other things lately, but i'll be coming back to this in a month or so and will have some PRs for docs, specifically with some working example that we can pull (and probably change) from my code.

Again, thanks a lot!