libre.sh/keycloak-scim
4
0
Fork 0
Code Issues 15 Pull requests Releases 1 Activity Actions

KEYCLOAK-15484 Document that client certificate trust should be validated by reverse proxy

Browse source
This commit is contained in:
mposolda 2021-01-04 10:31:52 +01:00 committed by Marek Posolda
parent 68dcd06748
commit 0f4affd1e9
1 changed files with 7 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
server_admin/topics/authentication/x509.adoc
View file

@ -8,7 +8,7 @@ A typical workflow is as follows:
- A client sends an authentication request over SSL/TLS channel - A client sends an authentication request over SSL/TLS channel
- During SSL/TLS handshake, the server and the client exchange their x.509/v3 certificates - During SSL/TLS handshake, the server and the client exchange their x.509/v3 certificates
- The container ({appserver_name}) validates the certificate PKIX path and the certificate expiration - The web container (either the reverse proxy or {appserver_name} where {project_name} is deployed) validates the certificate PKIX path and the certificate expiration
- The x.509 client certificate authenticator validates the client certificate as follows: - The x.509 client certificate authenticator validates the client certificate as follows:
* Optionally checks the certificate revocation status using CRL and/or CRL Distribution Points * Optionally checks the certificate revocation status using CRL and/or CRL Distribution Points
* Optionally checks the Certificate revocation status using OCSP (Online Certificate Status Protocol) * Optionally checks the Certificate revocation status using OCSP (Online Certificate Status Protocol)
@ -20,6 +20,12 @@ A typical workflow is as follows:
* In the Browser Flow, the server prompts the user to confirm identity or to ignore it and instead sign in with username/password * In the Browser Flow, the server prompts the user to confirm identity or to ignore it and instead sign in with username/password
* In the case of the Direct Grant Flow, the server signs in the user * In the case of the Direct Grant Flow, the server signs in the user
IMPORTANT: Note that it is the responsibility of the web container to validate certificate PKIX path. X.509 authenticator on the
{project_name} side provides just the additional support for check the certificate expiration, certificate revocation status and key usage. If you are
using {project_name} deployed behind reverse proxy, make sure that your reverse proxy is configured to validate PKIX path. If you
do not use reverse proxy and users directly access the {appserver_name}, you should be fine as {appserver_name} makes sure that PKIX path is validated as long
as it is configured as described below.
==== Features ==== Features
Supported Certificate Identity Sources:: Supported Certificate Identity Sources::