[keycloak-user] Multitenancy for WAR

[Nils Preusker]

Hi Bill,

it's been a while since we discussed this but I thought I'd add my question
to this thread since it is related. I'm now looking into authorizing
requests based on domain specific permissions.

Here's the use case:
We have one war that serves as a REST-back-end for a JavaScript
application. We've successfully secured the application (AngularJS with
keycloak.js in the front-end, WAR on Wildfly 8 with JAX-RS/ RestEasy in the
back-end) with keycloak (beta-2). Now, instead of using the role mapping in
the OAuth token, we'd like to be able to determine the users' role mappings
based on a path parameter in the HTTP request to the REST-back-end.

For example, if the URL is '/my-app/1/some-resource', we need to check
whether the user has an account in 'my-app 1' (which is an entry in the
applications database) and add the respective roles (also from the
applications database), if the URL is /my-app/2/... the same needs to
happen for 'my-app 2' etc.

The idea would be to add some kind of security interceptor which extracts
the keycloak user id, matches the id to the domain user (user from e.g.
my-app 1), and adds the role mapping of the domain user. Since we'd like to
continue using the EJB annotations (RolesAllowed etc.), we'd need to make
sure those domain users' roles are propagated to the security context.

So the question is, would you recommend extending the keycloak login
module? Or can you think of an easier way like e.g. a web filter?

Cheers!
Nils













My question is whether to extend the wildfly adapter (KeycloakLoginModule)
or to


On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker <n.preusker at gmail.com> wrote:

> Hi Bill,
>
> 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!
> Nils
>
> > On 01 Jun 2014, at 13:28, Bill Burke <bburke at redhat.com> wrote:
> >
> > 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?
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-user mailing list
> > keycloak-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20140812/14255e0a/attachment.html