[keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication

Marek Posolda mposolda at redhat.com
Tue Jul 14 14:53:03 EDT 2015


On 14.7.2015 20:17, Marek Posolda wrote:
> 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 .
ah, actually thinking that we can likely relax a bit on this one. As 
long as truststore contains root CA, the uploaded client certificates 
signed by that CA will be trusted too. So just need to check if elytron 
allows to trust certificates from provided truststore, which I hope 
shouldn't be an issue.

Marek
>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev



More information about the keycloak-dev mailing list