10:31 a.m.
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(a)redhat.com
<mailto:mposolda@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(a)lists.jboss.org <mailto:keycloak-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
<https://lists.jboss.org/mailman/listinfo/keycloak-dev>