Kerberos/GSSAPI credentials delegation/ticket fowarding

[AiO]

Hello again,

I'm replying my own thread - Still hoping to get insights from smarter 
people than me.

I ended up writing a patch for gssapi.c which reads a path-variale from 
the .conf-file for my server and it use gss_acquire_cred_from() rather 
than the older gss_acquire_cred(). The patch is creating a temporary file, 
and relying on the krb5 parts of the API to write the contents. The file 
is also is named using the Posix UID as suffix in its filename, so they 
can be separated per user, if one would like that.

The patch is really not up-stream level in quality. I'd need some feedback 
on a few points. Some stuff is quite hardcoded still.

Would it be nice to be able to specify the cached credential store-path 
like this (anyhow this is how i currently implemented it from a user 
perspective)?

   mech_list: GSSAPI
   keytab: /etc/my_service.keytab
   realm: MYREALM.COM
   use_authid: true
   ccpath: /var/lib/gssproxy/clients/

For example...

My hope is that this will be a rather nice way to tell a SASL enabled 
server to store the clients credentials in a known location. Hence 
avoiding eventual collisions with permissions of files and paths - Even 
supporting previlege separation using GSSProxy, best case...

Then a SASL enabled server application can set the KRB5CCNAME and access 
other Kerberized services in its turn, authenticating users correctly.

So... Four questions:

1. Is there SOME way to do this in 2.1.27 already - Something i've missed?
    In that case - I'll just happily toss my code and go on with using
    existing features. :)

2. Should the existance of ccpath if/else encapsulate all code changes
    related to the credentials cache, using all code as usual?

3. Is there an interest in the community for such a feature?

4. How do I contribute it best, if so? I would not promise i did the
    code 100% correct or in the smartest way possible, it might even be
    a bit hackish.

Kind regards,
AiO

On Tue, 16 Oct 2018, AiO wrote:

> Hello all,
>
> I'm trying to figure out how to make Cyrus SASL handle Kerberos ticket 
> delegation. I have read the mailing lists and the information is a bit thin 
> on this topic. I saw that Morten and Rob had discussions about it back int 
> 2003. And also S4U2 was discussed at some point between Howard and Alexey 
> back in 2010.
>
> I am looking to be able to pass user identity to services behind a 
> front-service - Much like Apache is able to do with mod_auth_kerb or 
> mod_auth_gssapi. To maintain the user identity for accessing for example 
> databases and such in a larger ecosystem of services. Or OpenSSH is able to 
> do delegation. In both Apache and OpenSSHD there are additional configuration 
> parameters to GSSAPI...  Can the Cyrus SASL library be used in the same 
> manner? (Given that the KDC and service policies are configured correctly, 
> either unconstrained delegation or S4U2 delegation)
>
> Play with the idea that I want to write an IMAP server that stores its data 
> in a PostgreSQL database, and I want to restrict users access to various 
> parts of the database using the built-in ACL's to secure the stored data. In 
> this example; authentication on to IMAP using GSSAPI and a previously 
> received ticket and then delegation of credentials achieve full 
> single-sign-on authentication and authorization to the data.
>
> In my case I have a Qpid Proton AMQP serice. I have managed to get GSSAPI 
> single-sign-on working to it using Cyrus SASL (libsasl) that is linked with 
> Qpid Proton. This is all good and totally AWESOME! However. How on earth do I 
> convince the libsasl-process instance to impersonate the user when accessing 
> other kerberized services. Yes as users. Not service-service.
>
> Is there something additional that can be added to the 
> /etc/sasl2/<service>.conf file that might convince the GSSAPI-parts of SASL 
> to do this automagically? I'm a bit lost, currently.  I hope to find someone 
> here that know how to do this wizardry. :)  Thanks in advance!
>
> Kind regards, AiO
>