About proxy_impersonator

[Greg Hudson]

On 2/14/19 9:47 PM, Weijun Wang wrote:
> 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.

That's one scenario.  The other variant is that in place of step 2, the
intermediate server uses its TGT to make an S4U2Self request to the KDC,
obtaining a ticket from a client of its choosing.  Steps 1, 3, 4, and 5
are the same.

> #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?

In either variant of step 2, the resulting GSS credential is a
composition of the intermediate service TGT and the ticket from the
client (often called an "evidence ticket").  Usually these two tickets
are stored in a memory ccache.  If the application uses one of the GSS
facilities for storing or copy this credential (gss_store_cred(),
gss_store_cred_into(), gss_krb5_copy_ccache()) then the
proxy_impersonator config entry helps identify the stored ccache to
another process.

So step 2 and step 3 can be in different processes, and that is what the
proxy_impersonator entry is about.