[keycloak-user] Multitenancy for WAR

Tue Aug 26 03:45:55 EDT 2014

Hi Stian,

thanks for your reply. We've actually come up with a totally different
approach in the meantime. We now ask our back-end for a domain specific
token every time an object that requires a custom role mapping is selected
in the UI. We then replace the token in keycloak.js. The back-end uses
keycloak-core in order to create tokens (inspired by
https://github.com/liveoak-io/liveoak/blob/master/modules/keycloak/src/test/java/io/liveoak/keycloak/TokenUtil.java
).

Cheers,
Nils

On Tue, Aug 26, 2014 at 9:32 AM, Stian Thorgersen <stian at redhat.com> wrote:

> This sounds like a feature that our adapter should provide so I would say
> if you can come up with a decent way to add it, then we'd probably be more
> than happy to pull it in.
>
> We could enable multi-tenancy support in keycloak.json by allowing
> multiple sets of configs with one or more url-patterns to match what config
> to use. For example:
>
> [
>   {
>     "realm" : "example",
>     "resource" : "app1",
>     ...
>     "url-pattern" : [ "/app1/*", "/myapp/*" ]
>   },
>   {
>     "realm" : "example2",
>     "resource" : "app2",
>     ...
>     "url-pattern" : [ "http://app2.org/*" ]
>   }
> ]
>
> ----- Original Message -----
> > From: "Nils Preusker" <n.preusker at gmail.com>
> > To: keycloak-user at lists.jboss.org
> > Sent: Tuesday, 12 August, 2014 7:01:33 PM
> > Subject: Re: [keycloak-user] Multitenancy for WAR
> >
> > 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
> >
> >
> > _______________________________________________
> > 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/20140826/d0889078/attachment-0001.html 