Interplay of Kerberos authentication and reverse proxies

Question

I need to gain some high-level understanding about the interplay of reverse proxies and the Kerberos protocol.

Assume I have a web service and a client, which are already implemented and working. Now we put the web service into a network behind a reverse proxy. The internal authentication in the network behind the reverse proxy is based on Kerberos.

Now I would like to know whether this new infrastructure would make some programmatical changes on the web service side and on the client side necessary? This depends on

1. whether the reverse proxy will act as a client in this intranet using its own tickets
2. or whether the outside client has to be aware of this additional authentication layer and has to be able to request tickets by itself

What is the state of the art in such situations?

Thanks in advance!

Answer 1

I think I found the answer. Constrained delegation is the feature of the Kerberos protocol I expected to exist.

If we use SSL/TLS with mutual certificate based authentication, then the client will be authenticated by the proxy, who validates client's certificate by a local CA (within the hidden intranet). Afterwards, the proxy will generate Kerberos tickets on behalf of the already authenticated client.

At the server side, the ticket validation should happen at the runtime level (e.g., by IIS).

Hence, if the client is able to consume the service through SSL/TLS, then the Kerberos authentication remains fully transparent for client and the server.