<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 14.7.2015 22:48, Bill Burke wrote:<br>
</div>
<blockquote cite="mid:55A5759C.4090609@redhat.com" type="cite">
<pre wrap="">
On 7/14/2015 2:17 PM, Marek Posolda wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
+1 for possibility of both upload and generate certificates.<br>
<blockquote cite="mid:55A5759C.4090609@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">- There is REST endpoint, which allows to authenticate with client
certificate. For example
<a class="moz-txt-link-rfc2396E" href="https://localhost:8443/auth/realms/demo/clients/certificate">"https://localhost:8443/auth/realms/demo/clients/certificate"</a> . 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.
</pre>
</blockquote>
<pre wrap="">
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.</pre>
</blockquote>
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.<br>
<br>
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. <br>
<br>
For example: Admin may want to authenticate users with password+TOTP
, but authenticate clients with client credentials grant or client
certificate<br>
<br>
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.<br>
<blockquote cite="mid:55A5759C.4090609@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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...</pre>
</blockquote>
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 <code class="hljs xml"><span
class="hljs-tag"><span class="hljs-attribute">verify-client</span>=<span
class="hljs-value">"want" of HTTPS connector), so looks<br>
it is supported for Wildfly10 as well. I will try to
doublecheck for sure...<br>
</span></span></code>
<blockquote cite="mid:55A5759C.4090609@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">This means that I will be able to access admin console
<a class="moz-txt-link-rfc2396E" href="https://localhost:8443/auth/admin">"https://localhost:8443/auth/admin"</a> with my browser without client
certificate, but I will be able to provide client certificate on the
endpoint <a class="moz-txt-link-rfc2396E" href="https://localhost:8443/auth/realms/demo/clients/certificate">"https://localhost:8443/auth/realms/demo/clients/certificate"</a> ,
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 .
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
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.<br>
<br>
Marek<br>
</body>
</html>