<div dir="ltr">Hi Bill,<div><br></div><div>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. </div>
<div><br></div><div>Here's the use case:</div><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div><div><br></div><div>Cheers!</div><div>Nils</div><div><br></div>
<div><br></div><div> </div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>My question is whether to extend the wildfly adapter (KeycloakLoginModule) or to </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Jun 1, 2014 at 5:57 PM, Nils Preusker <span dir="ltr"><<a href="mailto:n.preusker@gmail.com" target="_blank">n.preusker@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Bill,<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thanks for the discussion!<br>
<span class="HOEnZb"><font color="#888888">Nils<br>
</font></span><div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>