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
On Tue, Aug 26, 2014 at 9:32 AM, Stian Thorgersen <stian(a)redhat.com> wrote:
This sounds like a feature that our adapter should provide so I would
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>
> 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
> 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'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)
> 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
> 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
> for 'my-app 2' etc.
> The idea would be to add some kind of security interceptor which
> keycloak user id, matches the id to the domain user (user from e.g.
> 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
> Or can you think of an easier way like e.g. a web filter?
> My question is whether to extend the wildfly adapter
> On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker < n.preusker(a)gmail.com >
> Hi Bill,
> The more I think about it the more it makes sense to me that the tenant
> application instance is indeed part of the applications data model and
> 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
> 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 > 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
> > 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
> > 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
> >> 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