Re: Kerberos/GSSAPI credentials delegation/ticket fowarding

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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,

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

[Index of Archives]     [Info Cyrus]     [Squirrel Mail]     [Linux Media]     [Yosemite News]     [gtk]     [KDE]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux