[keycloak-dev] Realm key rotation support

[Marek Posolda]

On 13/09/16 16:36, Niels Bertram wrote:
> Hi Stian,
>
> intersting email, we were recently given advise to rotate keys 
> periodically but at this point in time keycloak 1.9.8 does not 
> actually implement 
> http://openid.net/specs/openid-connect-core-1_0.html#RotateSigKeys nor 
> are any of the client adapters able to use the jks url to retrieve pub 
> keys rather requiring to hard code the target realm key in the 
> public-realm-key property of the keycloak.json client configuration file.
>
> Is this new feature going to implement the OpenID Connect spec 
> sections 10.1 and 10.2 ?
>
> Also I assume this would also require changes to adapters by removing 
> the public-realm-key property from the config file?
Yes, exactly. Adapter's side is already implemented in master (but not 
yet documented). See my other mail for details 
http://lists.jboss.org/pipermail/keycloak-dev/2016-September/008062.html

Marek
>
> Kind Regards,
> Niels
>
> On Tue, Sep 13, 2016 at 11:41 PM, Nalyvayko, Peter <pnalyvayko at agi.com 
> <mailto:pnalyvayko at agi.com>> wrote:
>
>     Is this going to be a breaking feature or is the plan to continue
>     supporting the current single key/realm model?
>
>     *From:*keycloak-dev-bounces at lists.jboss.org
>     <mailto:keycloak-dev-bounces at lists.jboss.org>
>     [mailto:keycloak-dev-bounces at lists.jboss.org
>     <mailto:keycloak-dev-bounces at lists.jboss.org>] *On Behalf Of
>     *Stian Thorgersen
>     *Sent:* Tuesday, September 13, 2016 9:29 AM
>     *To:* keycloak-dev <keycloak-dev at lists.jboss.org
>     <mailto:keycloak-dev at lists.jboss.org>>
>     *Subject:* [keycloak-dev] Realm key rotation support
>
>     To be able to gracefully rotate the realm keys periodically a
>     realm needs to have more than one keypair. One keypair that is
>     active and will be used to issue new cookies and tokens. Also, one
>     or more keypairs that are inactive that can be used to verify old
>     cookies and tokens.
>
>     I'm going to start work on this soon, but here's some initial
>     thoughts:
>
>     * Realm keys will have a list of keypairs rather than just one.
>     Only one can be active. There will also be an expiration time on
>     the inactive keypairs. Once expired and inactive keypair is no
>     longer usable.
>
>     * There will also be an option to automatically generate a new key
>     every N days.
>
>     * If a session cookie is signed with an inactive pair the cookie
>     will be refreshed so it's signed with the active keypair
>
>     * Token introspect endpoint will allow any token that is signed
>     with any keypair that is not expired
>
>     * If a refresh token is signed with an inactive pair the new
>     tokens (including refresh token) will be signed with the active
>     keypair
>
>     * Secret used to generate client code will be linked to the
>     keypair. I'll need a way to specify what secret it was signed with
>     so codes are still valid even if they where signed with an old.
>
>     This is only for login cookie and OIDC protocol. Is it even
>     necessary to have support for multiple certificates for SAML? SAML
>     doesn't have a token introspection or refresh of the assertions
>     right, so not sure it's needed.
>
>     With regards to the applications. Marek has already added support
>     for clients to fetch new keypairs for the realm. See his email on
>     keycloak-dev for details around that.
>
>
>     _______________________________________________
>     keycloak-dev mailing list
>     keycloak-dev at lists.jboss.org <mailto:keycloak-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/keycloak-dev
>     <https://lists.jboss.org/mailman/listinfo/keycloak-dev>
>
>
>
>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160913/d25a811b/attachment-0001.html