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

[Giriraj Sharma]

HI Marek,

I am basically looking after following high level use cases:
* Create root CA and configure KC server
 * Create chained realm CA
* Create cert for clients - and configure a WAR that uses it to auth the
client
 * Create cert for user

*We may have an abstract Keycloak CA which will simply act as the root CA.
Certs of realms, users and clients will be signed via this root CA private
key. Keycloak ssl will be configured with Keycloak abstract CA keys and
certificates in standalone.xml . **Users will import their pkcs#12 or .pfx
format of certificate and key into their browsers to enable mutual ssl
auth. *

*Admins will have ability to upload the root CA certificate/keys. In such a
case, certs of realms, users and clients will be signed via the uploaded
root CA's keys.*

Configure Keycloak/WildFly SSL
<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>
  ...

*So,In general,  standalone.xml  can be configured via Keycloak abstract
CA's cert and key and users can import their pkcs#12 format into their
browsers. I still need to dig around how to configure client war for client
mutual SSL authentication with KC server.*


On Tue, Jul 14, 2015 at 11:47 PM, Marek Posolda <mposolda at redhat.com> 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 .
>
> 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
>



-- 

Giriraj Sharma
about.me/girirajsharma
<http://about.me/girirajsharma?promo=email_sig>
 Giriraj Sharma,
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150715/2fda03fd/attachment-0001.html