[keycloak-dev] Truststore SPI

Sebastian Laskawiec slaskawi at redhat.com
Mon Aug 20 04:25:19 EDT 2018


On Tue, Aug 14, 2018 at 11:30 PM Stian Thorgersen <sthorger at redhat.com>
wrote:

> Was thinking some more about how to share certificate functionality between
> user authentication and client authentication. Potentially also to SAML.
>
> We could add a Truststore SPI. The TruststoreProvider interface would have
> something like the following methods (quick mock stuff):
>

We already have a Truststore SPI [1]. If I remember correctly, it's being
used when Keycloak needs to create an TLS connection to another IDP.
Perhaps we could come up with another name, like CertificateSpi?

[1]
https://github.com/keycloak/keycloak/blob/08dbdeb57f678646a30a8ef44a76a8bf50f87e59/server-spi-private/src/main/java/org/keycloak/truststore/TruststoreSpi.java


>
> * boolean verifyCert(CertificateMatcher matcher)
> * Set<String> listExpiring()
>

This one should probably take a date as an argument (or maybe there should
be an overloaded method that takes it?).


> * void trustCert(Cert cert)
>

Probably addCert would be a better name since we have a removeTrustedCert
method.


> * void removeTrustedCert(String id)
> * Cert getSavedCert(String id)
> * void removeSavedCert(String id)
> * void saveCert(Cert cert)
>

Plus, methods that list trusted and saved certs.


>
> We'd have a default built-in TruststoreProvider. Potentially delegating
> some stuff to Elytron, but it would have to store certs in the db. It would
> deal with checking if cert is still valid, call cert validation like the
> user cert does, etc..
>

That's a very good idea. Some of the interesting stuff is, like
Certificates Revocation Lists are coming out of the box once we integrate
Elytron [2].

[2]
https://docs.jboss.org/author/display/WFLY/SSL+Configuration+using+Elytron+Subsystem#SSLConfigurationusingElytronSubsystem-UsingaCertificateRevocationList


>
> For user and client authentication we'd use verifyCert primarily. We'd have
> something like UserCertMatcher.create()... and
> ClientCertMatcher.create()... In the admin console we could add an option
> to add trusted certs (not sure how that'd work in a cluster).


It shouldn't be hard. We probably need a DB entity for that and let
Infinispan do the caching. Although, I'm not sure if we have any
constraints from the security perspective??


> For SAML
> clients we'd delegate storing certs to the Truststore SPI instead of
> storing the cert data alongside the client. The truststore would also add
> some metadata in the db about certs so we can easily query for expiring
> certs.
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>


More information about the keycloak-dev mailing list