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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Tuesday, 14 July, 2015 10:48:28 PM Subject: Re: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication 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. > - 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. > > 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... > 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. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)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.

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Marek Posolda" <mposolda(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Thursday, 16 July, 2015 2:40:11 PM Subject: Re: [keycloak-dev] Requirements to Elytron for Client 2-way SSL authentication On 7/16/2015 4:20 AM, Marek Posolda wrote: >> 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. > I don't know how well cert chains are supported. I guess you'll find out :) For client auth, shouldn't we just support the best practices and whatever the spec requires? 2-way SSL is a pain in the ass, wouldn't you be better off with PIN+OTP? Much easier to set up and manage.

-- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev