1:50 p.m.
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(a)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(a)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