[keycloak-user] Internal and External Keycloak IDP's
Stian Thorgersen
sthorger at redhat.com
Thu Apr 14 02:55:25 EDT 2016
On 13 April 2016 at 20:51, Travis De Silva <traviskds at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20160414/a49c6a52/attachment.html
More information about the keycloak-user
mailing list