Acknowledged. Certificate/Key Configuration Authority will facilitate
setting configuration for almost all config parameters( eg. key/cert
signature algorithm, encryption algorithm, signature/secure random
algorithm provider, bit length, validity etc.).
On Tue, May 26, 2015 at 6:13 PM, Bill Burke <bburke(a)redhat.com> wrote:
I want a facility in the admin console that can create and name one
more keypairs/certificates. Then, we can assign these keypair/certs to
various aspects. i.e., Most protocols recommend different keypairs for
encryption and signatures. Some clients may want to use HMAC over RSA,
On 5/26/2015 3:23 AM, Giriraj Sharma wrote:
> We're looking to provide a API to easily enable Key and Certificate
> Management to
> Keycloak-based applications. We may have a comprehensive PKI/Certificate
> for KC so as to fulfill all key/certificate/JOSE requirements in future
> roadmap. This is a future
> consideration/idea and is not meant as a feature to be merged soon. It
> will be likely to hit KC master
> as and when the roadmap will require.
> The idea is turn a realm into a Certification Authority,
> responsible for issue, validate, revoke and renew certificates for the
> identity types
> (eg.: realms, users, applications etc) associated with it. Thus, realm
> will act
> as the root CA or realm's certificate(X509 v1) will be self signed and
> certificates(X509 v3) of
> identity types will be signed with realm's certificate.
> So, there will be a pki module with key and certificate authority which
> will be able to
> perform all key and certificate related functions and hence will be used
> as per requirements
> by identity types(eg.: realms, users, applications etc).
> In the future, we also want to provide:
> - RESTful Endpoints to perform not only certificate operations, but also
> manage keys.
> Specially public keys. Probably using JSON Web Keys (JWK).
> - Better support for HTML5 and mobile applications that require some
> kind of support for certificates,
> asymmetric keys, signature and encryption. Specially when using JWT and
> - Support Java KeyStores to load and store keys.
> -Implementation of lets encrypt ACME Specification.
> -Support for JWS and JWE, if required.
> After some initial work, I think we have an initial design. Still have
> to think about,
> specially regarding the configuration and storage.
> Basically, what we have so far are two main components:
> CertificateAuthority and KeyAuthority.
> The first is about managing keys (eg.: RSA keys) for realm and identity
> The second one is about managing certificates using the keys for a
> particular type.
> We have Key and Certificate Authority which can be injected anywhere and
> be used accordingly.
> If CDI doesn't appears to be a good choice, then, we can probably
> directly use these services via method
> invocations :
> private KeyAuthority keyAuthority;
> private CertificateAuthority certificateAuthority;
> More information here :
> First cut on my local keycloak pki branch :
> Giriraj Sharma
> Giriraj Sharma,
> Department of Computer Science
> National Institute of Technology Hamirpur
> Himachal Pradesh, India 177005
> keycloak-dev mailing list
JBoss, a division of Red Hat
keycloak-dev mailing list
Department of Computer Science
National Institute of Technology Hamirpur
Himachal Pradesh, India 177005