[keycloak-dev] Migration of old offline tokens

[Marek Posolda]

Yeah, the legacy provider seems to be cleaner solution, but indeed more 
work :)

I will try to see if I have time to do it as I have some other JIRAs 
related to LDAP and I would like to look at least to KEYCLOAK-2333 .

Marek

On 13/01/17 15:09, Stian Thorgersen wrote:
> Option 1 is OK.
>
> Another option could be to add a special legacy provider. It would be 
> added during migration together with the rsa provider, but would have 
> a null value for the kid. It would not have an option to make it the 
> active key. This would mean new installations wouldn't be affected and 
> the provider could be removed once all old offline tokens are 
> migrated. We can also deprecate the provider later on.
>
> On 13 January 2017 at 11:45, Marek Posolda <mposolda at redhat.com 
> <mailto:mposolda at redhat.com>> wrote:
>
>     We have a bug that offline tokens issued in the old release (eg.
>     1.9.8)
>     don't work after migration into the new release and can't be
>     successfully refreshed. JIRA is
>     https://issues.jboss.org/browse/KEYCLOAK-4140
>     <https://issues.jboss.org/browse/KEYCLOAK-4140> .
>
>     Reason is, that old offline token don't have KID in the header, but
>     currently we require KID to be present, so we can lookup correct
>     key. I
>     wonder about possible solutions:
>
>     1) If KID is not present in offline token, then just look for the
>     realm
>     active RSA key and use that one for the verification. This is
>     easier and
>     I've sent PR for it now
>     https://github.com/keycloak/keycloak/pull/3752
>     <https://github.com/keycloak/keycloak/pull/3752> .
>     However there is one small limitation though, that if admin
>     changes the
>     active realm key, the old offline tokens won't work (even though
>     the old
>     publicKey is still valid, it is just not active). So seems that if
>     we go
>     with this one, we should add a note to the migration guide about this
>     limitation?
>
>     2) Iterate over all realm RSA keys and try to verify token with any of
>     them. This won't have the limitation above, but it's more complex
>     though.
>
>     IMO the limitation is acceptable, considering that it's just about
>     backwards compatibility. So I would rather go with simpler 1. WDYT?
>
>     Marek
>
>     _______________________________________________
>     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>
>
>