-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mTLS authN mode #8
Comments
Implementation for this could involve having the CA certs stored in In the case of Authorino API keys, however, each Kubernetes Without storing SANs/CNs anywhere, mTLS authentication in Authorino will probably be limited to
This limitation is similar to the current support for the verification of OpenID Connect JWTs in Authorino. Some authorization policies can still be implemented based on SANs/CNs and/or other fields of the certificate. However considering X.509 certificates are usually not very complex structures (unlike JWTs), any additional user data will likely have to be fetched from external services in request-time, using Authorino HTTP GET/GET-by-POST metadata. Revocation is another issue to consider. Unless we're planning on supporting certificate revocation lists (see https://datatracker.ietf.org/doc/html/rfc2459#section-3.3 for more info), issued certificates shall be valid until they expire. While for OIDC |
A reference about the client cert revocation issue: kubernetes/kubernetes#18982 |
We should also make sure people interested in this feature in Authorino still have the option of using Keycloak's X.509 Client Certificate User Authentication and later Authorino only to verify the token via the OIDC token verification feature. |
I will try to follow up with Gui's ideas. Revocation:
Another way would be downloading the CRLs (from CA) during the reconciliation, but since the reconciliation is not periodic and some CRDs might be a long period of time without reconciliation it would not be suitable for this use case.
|
I think we could start with this option in the beginning, and then either evolve to CRLs or advise clients to use Keycloak for a 1st leg of authentication based on mTLS followed by requests to the protected service using the access token. |
To sum up a few options we have for supporting mTLS authn in Auhtorino:
|
There's already a placeholder for it at https://github.com/3scale-labs/authorino/blob/2b6a6f8016a5837650506cd125751f8d95ea4197/pkg/config/identity/mtls.go.
The text was updated successfully, but these errors were encountered: