Re: [keycloak-user] Multitenancy for WAR

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(a)gmail.com&gt; > To: keycloak-user(a)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(a)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(a)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(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user