The more I think about it the more it makes sense to me that the tenant or application
instance is indeed part of the applications data model and not part of keycloak.
Especially since we want to add tenants at runtime, it wouldn't be possible to have a
check without hitting the db.
About cross realm users, I totally agree! I also don't like the idea and I'm
hoping and guessing that we won't really need it in the end.
Thanks for the discussion!
On 01 Jun 2014, at 13:28, Bill Burke <bburke(a)redhat.com>
We already support some form of multi-tenancy. One keycloak server can
serve up multiple realms.
For multitenant-apps was thinking of a app or service that needs to
support multiple isolated realms.
For bearer-only services, there would just be a list of realms that are
supported and the keycloak adapter would just look into the bearer token
to know which realm to validate the token with. For browser apps, they
need to be able to know which realm you are authenticating against, so I
thought the desired realm would be extracted from the URL.
I balk at your use-case because I don't like the idea of cross-realm users.
> On 6/1/2014 4:02 AM, Nils Preusker wrote:
> The only issue is that we might need to be able to assign different
> roles to the same user in different application instances.
What you could do, is not use the keycloak adapter and just hand code
your interactions via our oauth client api. Then your application
service could figure out which realm and application instance the user
was logging however it wanted and and pass that information along when
you start the oauth protocol flow. Following me?
JBoss, a division of Red Hat
keycloak-user mailing list