Python, Kerberos and ticket forwarding ..... please help
dpal at redhat.com
Mon Jul 22 09:00:39 EDT 2013
On 07/22/2013 04:49 AM, message adams wrote:
> Hi all;
> Over a number of weeks now I've been trying to set up a demonstration, to
> show MIT Kerberos working between a number of machines. Unfortunately this
> Friday (26th) I'm scheduled to give a presentation, but I'm missing one
> last vital component - ticket forwarding.
> My basic set up is:
> Redhat 6
> MIT 5
> Python 2.7.x
> client's ticket is already configured as F 'forwardable'
> Using the Python MIT wrapper (https://pypi.python.org/pypi/kerberos) I've
> successfully created clients and a Tornado server - and can happily
> demonstrate authentication between the two end points. My goal, however, is
> to use ticket forwarding, I.e.
> client -> web server -> service
> .. where the "web server" authenticates the client, and then forwards the
> client's credentials onto the 'service'. The service then authenticates
> against the original client's credentials and returns data if user
> is appropriately authorised.
> Maybe I've looked in all the wrong places, but after weeks of searching, I
> just cannot find any examples or discussions, describing how to forward the
> client's credentials?
> As time was running out, as a last resort I thought I'd throw the question
> out to the experts (you guys:-). I know you are all busy, but I would
> really appreciate any guidance, or ideally some example code, to
> demonstrate how the Python Kerberos wrapper can be used to forward a
> client's ticket. (Note - the client's ticket is already configured as F
> Any help would be gratefully received. All the very best,
> krbdev mailing list krbdev at mit.edu
I would count myself a semi expert here.
You have two options:
The old one (which is less preferable) is to get forward-able tickets.
In this case the client first authenticates against KDC gets a TGT using
user original credentials (user original credentials by default never
leave the client). Then using TGT it acquires service ticket for the
specific service. Then client uses this service ticket to authenticate
to the service. In the past the only way for this service to act on
behalf of the user was to request and get user TGT. AFAIU if the service
asks via flags to forward user TGT it will be store in the credential
cache and can be used to acquire tickets for other services.
But nowadays it is better to user s4u2proxy. You can see an example how
it is used in FreeIPA which uses it to acquire service tickets for LDAP
using service tickets for user UI/CLI interface. TGT in this case is not
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
Looking to carve out IT costs?
More information about the krbdev