<div dir="ltr">Hi Stian,<div><br></div><div>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 <a href="https://github.com/liveoak-io/liveoak/blob/master/modules/keycloak/src/test/java/io/liveoak/keycloak/TokenUtil.java">https://github.com/liveoak-io/liveoak/blob/master/modules/keycloak/src/test/java/io/liveoak/keycloak/TokenUtil.java</a>).</div>
<div><br></div><div>Cheers,</div><div>Nils</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 9:32 AM, Stian Thorgersen <span dir="ltr"><<a href="mailto:stian@redhat.com" target="_blank">stian@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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:<br>
<br>
[<br>
{<br>
"realm" : "example",<br>
"resource" : "app1",<br>
...<br>
"url-pattern" : [ "/app1/*", "/myapp/*" ]<br>
},<br>
{<br>
"realm" : "example2",<br>
"resource" : "app2",<br>
...<br>
"url-pattern" : [ "<a href="http://app2.org/*" target="_blank">http://app2.org/*</a>" ]<br>
}<br>
]<br>
<div class="HOEnZb"><div class="h5"><br>
----- Original Message -----<br>
> From: "Nils Preusker" <<a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a>><br>
> To: <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> Sent: Tuesday, 12 August, 2014 7:01:33 PM<br>
> Subject: Re: [keycloak-user] Multitenancy for WAR<br>
><br>
> Hi Bill,<br>
><br>
> it's been a while since we discussed this but I thought I'd add my question<br>
> to this thread since it is related. I'm now looking into authorizing<br>
> requests based on domain specific permissions.<br>
><br>
> Here's the use case:<br>
> We have one war that serves as a REST-back-end for a JavaScript application.<br>
> We've successfully secured the application (AngularJS with keycloak.js in<br>
> the front-end, WAR on Wildfly 8 with JAX-RS/ RestEasy in the back-end) with<br>
> keycloak (beta-2). Now, instead of using the role mapping in the OAuth<br>
> token, we'd like to be able to determine the users' role mappings based on a<br>
> path parameter in the HTTP request to the REST-back-end.<br>
><br>
> For example, if the URL is '/my-app/1/some-resource', we need to check<br>
> whether the user has an account in 'my-app 1' (which is an entry in the<br>
> applications database) and add the respective roles (also from the<br>
> applications database), if the URL is /my-app/2/... the same needs to happen<br>
> for 'my-app 2' etc.<br>
><br>
> The idea would be to add some kind of security interceptor which extracts the<br>
> keycloak user id, matches the id to the domain user (user from e.g. my-app<br>
> 1), and adds the role mapping of the domain user. Since we'd like to<br>
> continue using the EJB annotations (RolesAllowed etc.), we'd need to make<br>
> sure those domain users' roles are propagated to the security context.<br>
><br>
> So the question is, would you recommend extending the keycloak login module?<br>
> Or can you think of an easier way like e.g. a web filter?<br>
><br>
> Cheers!<br>
> Nils<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> My question is whether to extend the wildfly adapter (KeycloakLoginModule) or<br>
> to<br>
><br>
><br>
> On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker < <a href="mailto:n.preusker@gmail.com">n.preusker@gmail.com</a> > wrote:<br>
><br>
><br>
> Hi Bill,<br>
><br>
> The more I think about it the more it makes sense to me that the tenant or<br>
> application instance is indeed part of the applications data model and not<br>
> part of keycloak. Especially since we want to add tenants at runtime, it<br>
> wouldn't be possible to have a check without hitting the db.<br>
><br>
> About cross realm users, I totally agree! I also don't like the idea and I'm<br>
> hoping and guessing that we won't really need it in the end.<br>
><br>
> Thanks for the discussion!<br>
> Nils<br>
><br>
> > On 01 Jun 2014, at 13:28, Bill Burke < <a href="mailto:bburke@redhat.com">bburke@redhat.com</a> > wrote:<br>
> ><br>
> > We already support some form of multi-tenancy. One keycloak server can<br>
> > serve up multiple realms.<br>
> ><br>
> ><br>
> > For multitenant-apps was thinking of a app or service that needs to<br>
> > support multiple isolated realms.<br>
> ><br>
> > For bearer-only services, there would just be a list of realms that are<br>
> > supported and the keycloak adapter would just look into the bearer token<br>
> > to know which realm to validate the token with. For browser apps, they<br>
> > need to be able to know which realm you are authenticating against, so I<br>
> > thought the desired realm would be extracted from the URL.<br>
> ><br>
> > I balk at your use-case because I don't like the idea of cross-realm users.<br>
> ><br>
> ><br>
> >> On 6/1/2014 4:02 AM, Nils Preusker wrote:<br>
> >> The only issue is that we might need to be able to assign different<br>
> >> roles to the same user in different application instances.<br>
> ><br>
> > What you could do, is not use the keycloak adapter and just hand code<br>
> > your interactions via our oauth client api. Then your application<br>
> > service could figure out which realm and application instance the user<br>
> > was logging however it wanted and and pass that information along when<br>
> > you start the oauth protocol flow. Following me?<br>
> ><br>
> > --<br>
> > Bill Burke<br>
> > JBoss, a division of Red Hat<br>
> > <a href="http://bill.burkecentral.com" target="_blank">http://bill.burkecentral.com</a><br>
> > _______________________________________________<br>
> > keycloak-user mailing list<br>
> > <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
><br>
><br>
> _______________________________________________<br>
> keycloak-user mailing list<br>
> <a href="mailto:keycloak-user@lists.jboss.org">keycloak-user@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/keycloak-user" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br>
</div></div></blockquote></div><br></div>