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

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at lists.jboss.org
> Sent: Thursday, 16 July, 2015 10:20:01 AM
> Subject: Re: [keycloak-dev] Requirements to Elytron for Client 2-way SSL	authentication
> 
> On 14.7.2015 22:48, Bill Burke wrote:
> 
> 
> 
> On 7/14/2015 2:17 PM, 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)
> Bouncycastle has all the utilities to create our own certificates.  I
> was thinking that admin could upload one, or we could generate one for
> the user.
> +1 for possibility of both upload and generate certificates.
> 
> 
> 
> 
> 
> 
> - 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.
> I'm not sure why you think a specifc URL is needed to do the SSL
> handshake.  The 2-way SSL handshake happens *before* HTTP request is
> even processed
> 
> Client app would redirect to the same SAML or OIDC endpoint it does now.
>   The keycloak authentication flow would grab the certificate chain from
> HttpServletRequest, and validate the client certificate.
> Sure, we need some code on server, which will retrieve the certificate from
> the request and authenticate client based on that. I don't care if it's
> specific URL endpoint or configured authentication flow.
> 
> But note that ATM I am looking at authenticating clients (Service accounts)
> not users. Do we want also authentication of clients to be that dynamic and
> use Authentication SPI? I am not against that, but we would need a way to
> separate configured authentication flows to be different for users and for
> clients authentication.
> 
> For example: Admin may want to authenticate users with password+TOTP , but
> authenticate clients with client credentials grant or client certificate
> 
> ATM it seems that for authentication of clients, we need to support quite
> many different mechanisms (Client credentials grant, signed JWT token,
> client certificate, kerberos keytab), maybe more will come and will be
> requested by people. So having possibility to add another mechanism
> dynamically would be cool. There is difference though that for client
> authentication we don't want to display any forms, so the supported
> mechanisms might be limited as well in comparison to user authentication.

Would be good to have some SPI for client authentication. It can be much simpler than for users though. A client will have a set of "credentials" associated with it and there will be a set of authentication mechanisms available. There's no flows really is there for authenticating a client?

> 
> 
> 
> 
> 
> 
> 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.
> IIRC, you can't do this at runtime with NIO or BIO.  You must set up the
> SSLContext at boot time.  What can be a little more dynamic is the
> TrustManager, but I'm not sure we need this...read more below...
> Here I meant that we need a way to ensure that client certificates are
> "wanted" (not mandatory). Now I am seeing that in EAP6 you have this
> possibility (Set the attribute verify-client = "want" of HTTPS connector),
> so looks
> it is supported for Wildfly10 as well. I will try to doublecheck for sure...
> 
> 
> 
> 
> 
> 
> 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 .
> I'm not sure we really need to have any special integration with
> Elytron.  We just need to make sure that it can support certificate
> chains the way we want to support it.  I'm pretty sure EAP 6.x can
> support what we want, read on...
> 
> The certficate chain is available from the HttpServletRequest as per the
> spec.  I'm not exactly sure on the specifics, but all you need is one
> "root" certificate in the web server's trust store.  Then you could
> conceivably create a trusted certificate chain as follows:
> 
> 1) Organization root certificate.
> 
> 2) Root cert signs Realm cert.
> 
> 3) Realm cert signs client cert.
> 
> Following me?  My guess is that it would be really easy to issue our own
> client certs and that we could have a Required Action that helped set
> this up.
> Yeah, so if we can just put root certificate in truststore at startup, it's
> easy. The issue might be if we want root CA to be added to truststore at
> "runtime" as Stian mentioned in other mail. Will try to doublecheck if it's
> possible.
> 
> Marek
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev