<a id="principal-propagation-mtls"></a>

# Principal Propagation at REST Proxy for Mutual TLS (mTLS) in Confluent Platform

When Confluent REST Proxy forwards the identity, or principal, of a client authenticated
using mutual TLS (mTLS) to Confluent Server or Kafka brokers, the identity is propagated from
the REST Proxy to the Confluent Platform cluster. This process, called *principal propagation*,
enables the Confluent Platform cluster to make authorization decisions based on the identity
of the client and ensures that the identity is available to the applications
that produce and consume messages to and from the Confluent Platform cluster.

REST Proxy needs to propagate the principal received from the mTLS certificate of its
client or user to the Confluent Server brokers or a Confluent Platform cluster. For details on REST Proxy
security and principal propagation, see [Deploy Secure Standalone REST Proxy in Confluent Platform](../../../kafka-rest/production-deployment/rest-proxy/security.md#kafkarest-security).

## Security challenge

For REST Proxy to propagate the principal using mTLS, it needs to have access to
the client certificate on its keystore, which is a security challenge. This
principal propagation problem at REST Proxy when using mTLS for authentication
exists irrespective of whether the authorization used in the Confluent Platform cluster is
access control lists (ACLs) or role-based access control (RBAC).

## Impersonation solution

In mTLS RBAC, impersonation at REST Proxy solves this problem by giving REST Proxy
an elevated access (super user) in Confluent Platform, allowing it to impersonate its clients
without having access to certificates of all its clients.

To further avoid misuse of the new impersonation service, there is also a list of
protected users for which impersonation can never be done by REST Proxy.

This new enhanced secure principal propagation at REST Proxy is not available when
mTLS is used with ACL authorization when RBAC is not enabled. Also, MDS must
be configured in order for impersonation to work.

<a id="principal-propagation-mtls-flow"></a>

## Understand how principal propagation works with secure impersonation

To understand how principal propagation works with secure impersonation,
consider the following flow (see the image below):

1. When REST Proxy receives a resource request to forward to Confluent Server brokers or a Confluent Platform
   cluster, it first authenticates the incoming request using the certificate.
2. After successful authentication, the LoginService extracts the incoming
   user or client principal.
3. Using the extracted principal, the LoginService requests an authorization
   token from the MDS service. This authorization token is built from the
   client or user principal at the MDS service and needs to be refreshed at
   regular intervals.
4. Using the impersonated token, REST Proxy forwards the resource request to the
   Confluent Server brokers or Confluent Platform cluster.
5. The Confluent Server brokers or Confluent Platform cluster authenticates and authorizes the resource
   request using the impersonated token and responds appropriately to the user
   or client.