<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 13 April 2016 at 20:51, Travis De Silva <span dir="ltr">&lt;<a href="mailto:traviskds@gmail.com" target="_blank">traviskds@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have a client that as per their corporate security policy, require a seperate KeyCloak instance for external users and a seperate one for internal users.</div><div><br></div><div>The external one is located in a different DMZ zone and the internal one is located inside the firewall.</div><div><br></div><div>The internal and external client applications are also different. Each of these client applications connect to a common java services layer (JAX-RS based REST API&#39;s)</div><div><br></div><div>The Java Restful services are located in the same zone as the internal KeyCloak IDP.  External users can access these services via proxy and firewall controls.</div><div><br></div><div>My issue is how do I secure the common services war against two IDP&#39;s?</div><div><br></div><div>Option 1</div><div>Had a look at the multi-tenant example (<a href="https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant" target="_blank">https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant</a>) which is the closet to my use case but it seems to work off a single or clustered Keycloak instance and not seperate keycloak instances.</div></div></blockquote><div><br></div><div>This! Your use-case is exactly why this was implemented in the first place ;)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Option 2</div><div>My next idea is to maybe on the services.war store the keys from the two different keycloak instances and then have a filter than will read the token and validate it against they keys. But this means I will not be able to use the standard Java security annotations in my services classes to project the classes/methods via annotations.</div><div><br></div><div>Option 3</div><div>Can I use the internal Keycloak instance to somehow use the external keycloak instance as a federated user provider? Then I am hoping to secure the common war against the internal keycloak? Is this a viable option to explore?</div></div></blockquote><div><br></div><div>That&#39;s not going to work as the service needs to be able to verify the token which is dependent on what Keycloak instance and realm issued it. So sharing users is not going help here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Has anyone encountered a similar use case? I suspect this is a common practice in corporate environments?</div><div><br></div><div>Cheers</div><span class="HOEnZb"><font color="#888888"><div>Travis</div><div><br></div><div><br></div></font></span></div>
<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" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-user</a><br></blockquote></div><br></div></div>