# Request Forwarding from Follower to Leader in Confluent Platform On this page you’ll find an explanation of request forwarding from follower to leader in role-based access control (RBAC) without and with mTLS authentication. ## Token-based authentication with RBAC authorization This section describes RBAC with token-based authentication alone. In this scenario, RBAC relies on token-based authorization. In this flow, the following happens: 1. The client makes a request. 2. A follower node receives the request with a token in the `Authorization` header and extracts the principal from the token. 3. The follower node authorizes the principal against the Metadata Service (MDS). 4. The follower node forwards the request containing the token to the leader. 5. The leader extracts the principal from the token and performs its own authorization. ## mutual TLS (mTLS) authentication authentication with RBAC authorization In contrast, when RBAC relies on mTLS-based authentication, the initial request lacks an `Authorization` header, instead the system does the following sequence:  1. The client makes a request. 2. The follower node extracts the principal from the client’s Transport Layer Security (TLS) certificate. 3. The follower node impersonates the client by requesting an `ImpersonationToken` from MDS. 4. MDS generates an `ImpersonationToken`, which the follower then includes in the `Authorization` header for the next step. 5. The follower node forwards the request to the leader node using the follower’s own certificate for the connection. 6. The leader node validates the principal from the follower’s TLS certificate, not the client’s certificate. 7. The leader authorizes the user principal based on the `ImpersonationToken`, correctly reflecting the client’s identity and permissions in the resource access request. ## Impersonation controls You must set mandatory properties on the MDS server that prevent others from impersonating specific principals. You can also list the principals that can impersonate others. To enable request forwarding with mTLS, you must provide both the list of protected users and the list of users allowed to impersonate others. ### Mandatory impersonation protection List the protected, privileged identities that others can’t impersonate for security reasons, for example: ```properties confluent.metadata.server.impersonation.protected.users=User:;User: ``` You should always include super users in the list of protected users. ### Who can impersonate List the users that can impersonate a targeted user, for example: ```properties confluent.metadata.server.impersonation.super.users=User:;User:;User:;User: ``` You can allow impersonation for specific service identities to enable request forwarding from followers to leaders. For example, multi-node Schema Registry or Connect clusters. Add the following configuration to MDS, specifying the service identities permitted to impersonate other users, replacing `` and `` with the actual service identities: ```properties confluent.metadata.server.impersonation.super.users=User:;User: ``` ## Related content * [Configure mTLS Authentication and RBAC for Kafka Brokers](../../../kafka/configure-mds/mutual-tls-auth-rbac.md#mutual-tls-auth-rbac) * [Configure Metadata Service (MDS) in Confluent Platform](../../../kafka/configure-mds/index.md#rbac-mds-config)