[keycloak-dev] Realm key rotation support

Stian Thorgersen sthorger at redhat.com
Wed Sep 14 03:21:16 EDT 2016


On 13 September 2016 at 16:36, Niels Bertram <nielsbne at 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 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] *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/9a1cd62c/attachment.html 


More information about the keycloak-dev mailing list