About proxy_impersonator

Weijun Wang weijun.wang at oracle.com
Thu Feb 14 21:47:30 EST 2019


Sorry about so many questions. I know something about Kerberos but still have difficulties reading the krb5 codes.

So, this is how I understand S4U2Proxy:

1. Intermediate server starts, receives a TGT using its keytab, store it in its own ccache.

2. A client comes in, sends a ticket (A) to this server.

3. The server uses its own TGT and ticket A to get a S4U2Proxy ticket B to a backend.

4. This new ticket B is stored in the ccache.

5. Intermediate server talks to backend on behalf of client, using ticket B.

#3 and #5 can be in different processes since ticket B is already in ccache. Is the ticket A stored somewhere? Or the same process always does #3 right after #2 and throw about ticket A? What does the "delegated proxy credentials" means in your commit message?

Which step writes the proxy_impersonator entry?

Thanks,
Max

> On Feb 15, 2019, at 9:56 AM, Greg Hudson <ghudson at mit.edu> wrote:
> 
> On 2/14/19 8:24 PM, Weijun Wang wrote:
>>   proxy_impersonator
> 
>> I wonder what we (Java, as another krb5 vendor) should do when this entry appears in a ccache file. Should this ccache always belong to an intermediate server that works as both an initiator and an acceptor? If the entry is there, does it mean the it should always use S4U2Proxy to request for a ticket to a backend server on behalf of a client and should never request for itself?
> 
> Basically yes.  (MIT krb5 handles this at the GSSAPI layer, not the
> libkrb5 layer, so kvno would try to make regular requests with such a
> ccache, probably without success.  But that's probably a limitation, not
> a feature.)
> 
>> A ccache file is meant for sharing between processes. Who wrote this flag and who should use it?
> 
> This variable was introduced by commit
> 38de4804776a1a1a255b89b104b983fa1f10a664.  I was requested to make
> gss_store_cred_into() and similar operations work with creds resulting
> from gss_acquire_cred_impersonate_name() as well as synthetic delegated
> creds obtained from gss_accept_sec_context().




More information about the krbdev mailing list