[keycloak-dev] Multi tenant review

[Stian Thorgersen]

----- Original Message -----
> From: "Marek Posolda" <mposolda at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>, jpkroehling at redhat.com
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>
> 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
>