[keycloak-user] Multitenancy for WAR

[Stian Thorgersen]

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