Thanks Stian.

Yes I went with option1 and that is working like a charm. Had to make some changes where I check a header value rather than the path value and also loaded the keycloak.json files externally to the war file so if the keys are regenerated the support guys can update the file without having to build and deploy the war file.



On Thu, 14 Apr 2016 at 16:55 Stian Thorgersen <sthorger@redhat.com> wrote:
On 13 April 2016 at 20:51, Travis De Silva <traviskds@gmail.com> wrote:
Hi,

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.

The external one is located in a different DMZ zone and the internal one is located inside the firewall.

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's)

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.

My issue is how do I secure the common services war against two IDP's?

Option 1
Had a look at the multi-tenant example (https://github.com/keycloak/keycloak/tree/master/examples/multi-tenant) 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.

This! Your use-case is exactly why this was implemented in the first place ;)
 

Option 2
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.

Option 3
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?

That'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.
 

Has anyone encountered a similar use case? I suspect this is a common practice in corporate environments?

Cheers
Travis



_______________________________________________
keycloak-user mailing list
keycloak-user@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user