Re: [keycloak-dev] Multi tenant review

----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt;, jpkroehling(a)redhat.com > Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org&gt; > Sent: Thursday, 30 October, 2014 8:05:52 PM > Subject: Re: [keycloak-dev] Multi tenant review > > On 30.10.2014 15:25, Stian Thorgersen wrote: >>> On 10/28/2014 04:54 PM, Stian Thorgersen wrote: >>>>>> 3. CatalinaSessionTokenStore.checkCurrentToken - can you figure out >>>>>> the >>>>>> realm if the session was serialized? when adapter is clustered we >>>>>> support >>>>>> serializing the session >>>> I'm then changing one of the SecurityContext's to include the realm, so >>>> that it gets de-serialized with this information. Now, the question is >>>> whether it is more appropriate to add it to KeycloakSecurityContext or >>>> RefreshableKeycloakSecurityContext. On the superclass >>>> (KeycloakSecurityContext), I have access only to IdToken and >>>> AccessToken. I believe both have ways to retrieve the realm (issuer, I >>>> believe), but I don't know how reliable this is. I remember seeing a >>>> post from Bill on keycloak-user that it should be changed to an URL, not >>>> the realm name. On the subclass, however, I have access to the >>>> KeycloakDeployment, which provides the realm on the exact way that it >>>> was originally configured. >> TBH I have no idea - Marek can hopefully elaborate on this >> > I am not sure too TBH:-) > > Right now we have realm name available on AccessToken in "iss", so atm > the realm property on KeycloakSecurityContext is redundant. However it's > unclear if we still have it as it's possible that it's not compatible > with some 3rd party OIDC providers like Google, so in the future, we > would need to change this to URL. Quite related to parallel thread "1.1 > adapters no longer backward compatible" . > > My vote is to remove realm property from KeycloakSecurityContext for now > and implement getRealm method like: > > public String getRealm() { > return token.getIssuer(); > } > > I think that if we need in the future issuer to contain URL, we will > probably anyway add another "custom" property to AccessToken containing > realm name. > > Thoughts? Sounds sensible to me

> Marek >