[keycloak-dev] Realm key rotation support

[Niels Bertram]

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?

Kind Regards,
Niels

On Tue, Sep 13, 2016 at 11:41 PM, Nalyvayko, Peter <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@
> 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>
> *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
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160914/cb226a61/attachment-0001.html