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
