On 13 September 2016 at 16:36, Niels Bertram <nielsbne(a)gmail.com> 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 ?
10.1 yes, we don't support encryption at the moment and this work will not
include it.
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(a)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(a)lists.jboss.org [mailto:
> keycloak-dev-bounces(a)lists.jboss.org] *On Behalf Of *Stian Thorgersen
> *Sent:* Tuesday, September 13, 2016 9:29 AM
> *To:* keycloak-dev <keycloak-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>