The PKI realm currently relies on the TLS handshake with the client for authentication, which works in most cases. However, there are cases where end user requests may be proxied by another server such as Kibana. In these cases, the PKI realm would not have access to the TLS handshake with the client and the clients certificate directly. In order to enable end user PKI authentication for this use case we would need to add support for proxied PKI (PPKI MITM AAS as @jkakavas puts it). The requirements for this are:
- The proxied client certificate must be placed in an HTTP header
- The client connection proxying the certificate must be authenticated using PKI
- The client subject authenticated using PKI must be allowed to proxy pki (configured at the realm level)
- There needs to be some level of auditing for this; can we safely re-purpose run as?
cc @kobelb @clintongormley
The PKI realm currently relies on the TLS handshake with the client for authentication, which works in most cases. However, there are cases where end user requests may be proxied by another server such as Kibana. In these cases, the PKI realm would not have access to the TLS handshake with the client and the clients certificate directly. In order to enable end user PKI authentication for this use case we would need to add support for proxied PKI (PPKI MITM AAS as @jkakavas puts it). The requirements for this are:
cc @kobelb @clintongormley