Kerberos/GSSAPI credentials delegation/ticket fowarding
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- To: cyrus-sasl@xxxxxxxxxxxxxxxxxxxx
- Subject: Kerberos/GSSAPI credentials delegation/ticket fowarding
- From: AiO <aio.sasl@xxxxxx>
- Date: Tue, 16 Oct 2018 11:00:45 +0200 (CEST)
- User-agent: Alpine 2.11 (DEB 23 2013-08-11)
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]