About proxy_impersonator

[Weijun Wang]

> On Feb 16, 2019, at 7:03 AM, Greg Hudson <ghudson at mit.edu> wrote:
> 
> 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.

Suppose there is only one process, is the intermediate server also forbidden to get a ticket to a backend server on its own? Is this true for any GSS_C_BOTH credential?

Thanks,
Max