< subsystem xmlns = "urn:jboss:domain:web:1.1" default-virtual-server = "default-host" native = "true" > < connector name = "http" protocol = "HTTP/1.1" scheme = "http" socket-binding = "http" redirect-port = "443" /> < connector name = "https" scheme = "https" protocol = "HTTP/1.1" socket-binding = "https" enable-lookups = "false" secure = "true" > < ssl name = "foo-ssl" password = "secret" Keycloak-abstract-CA-certificate-key-file = "../standalone/configuration/foo.pem" Keycloak-abstract-CA-certificate-file = "../standalone/configuration/foo-cert.pem" /> </ connector > ... |
I want to doublecheck if we are on the same page regarding how client
certificate authentication should work, so we know what are the
requirements for Elytron
to support it. This will allow us to improve things before the Elytron
code freeze (end of August AFAIK) if needed.
Right now, I am covering just Service accounts and authenticating of
clients with the certificate. But I believe that for authenticate of
users, the requirements will be similar.
My view is:
- Admin will upload certificate of some client via Keycloak admin
console. (I guess many companies want to use their own certificate
issued by their trusted CA. IMO later Keycloak should provide the
ability to easily generate trusted certificates and act as CA - not sure
if it's something Giriraj is looking at. But for now, I assume that
trusted certificate is always provided by admin and uploaded to Keycloak
admin console)
- There is REST endpoint, which allows to authenticate with client
certificate. For example
"https://localhost:8443/auth/realms/demo/clients/certificate" . Client
will be able to start SSL handshake with it's certificate when sending
request to this endpoint. Server will then verify the underlying
SSLSession from the SSL socket and check that valid client certificate
was provided during handshake. It will authenticate client based on that.
To cover this usecase, the Wildfly/Elytron should be able to:
1) Support "variable" 2-way SSL . In other words, there is possibility
to set flag "setWantClientAuth(true)" in underlying SSLServerSocket.
This means that I will be able to access admin console
"https://localhost:8443/auth/admin" with my browser without client
certificate, but I will be able to provide client certificate on the
endpoint "https://localhost:8443/auth/realms/demo/clients/certificate" ,
which is deployed under same context
2) Dynamically upload it's truststore at runtime or provide SPI to
add/remove/update certificates in truststore. This is needed, so that
when admin uploads the certificate of client in KC admin console, I want
my client to be able to authenticate with the certificate immediatelly
without need to restart server and edit any JKS files .
3) Possibility to access underlying SSL Socket and SSL Session from the
REST endpoint, so I am able to verify the certificate in REST endpoint
(but maybe this one could be handled with our server subsystem if it's
not available for normal apps?)
WDYT? Am I missing something?
Marek
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev