6:28 a.m.
Nope - apiman doesn't currently communicate with KeyCloak at all. For
example, when using the KeyCloak OAuth policy to protect a back-end
service, the policy is configured with the realm key (along with some
other stuff). This configuration is sufficient to validate and consume
the auth token (which I believe is a signed JWT). So there's no need to
chat with KC in any way.
-Eric
On 11/24/2015 3:38 PM, Paul Blair wrote:
Thanks very much -- these were very useful answers for us.
One other related question: Does apiman do any back-channel communication
with Keycloak when it receives a token? Is there any communication between
apiman and Keycloak at all?
On 11/24/15, 3:12 PM, "Eric Wittmann" <eric.wittmann(a)redhat.com> wrote:
> Hi Paul. Thanks for the questions. I'll do my best to answer each one,
> inline below:
>
> On 11/24/2015 11:53 AM, Paul Blair wrote:
>> One alternative for us would be to run the gateway and management
>> console with embedded Jetty instead of Wildfly as described in the
>> recent post on micro-services. Since we want all authentication to go
>> through Keycloak it looks like we'd need to modify the authentication
>> handlers/filters in the gateway. Is there a good example of how to go
>> about writing an authentication handler for Keycloak?
>
> I think KeyCloak already has a Jetty adapter implementation. Of course,
> you would still need a standalone KeyCloak server running somewhere to
> take advantage of that.
>
> http://keycloak.github.io/docs/userguide/keycloak-server/html/ch08.html#je
> tty9-adapter
>
>> What would we be giving up if we were to go with the micro-service
>> approach rather than running on Wildfly? One thing I know we'd be giving
>> up is the HA clustering. Is apiman stateless? Could we just run multiple
>> Jetty instances and load balance across them?
>
> Once the authentication issue is resolved, I don't think you give up
> anything except for the ease of mind you get running on an application
> server like EAP or WildFly versus an embedded instance of Jetty.
> Certainly there is no loss in terms of feature set.
>
> As for HA clustering - apiman doesn't take advantage of that. The API
> Manager is basically a simple CRUD application - you can start up
> multiple nodes and point them all at the same database. Likewise, the
> Gateway shares state and configuration information by sharing a common
> data store (e.g. elasticsearch).
>
> You can definitely start up multiple instances of the apiman
> micro-service(s) and load balance across them!
>
>> If we stay on Wildfly we'd like to secure the Wildfly management console
>> using Keycloak, which I read is possible using Wildfly 9. Is there any
>> issue with deploying apiman to Wildfly 9?
>
> We don't currently have a WildFly 9 distribution. I admit I simply
> haven't had time to try it out. It may work flawlessly or it may
> require some tweaks. We won't know until we try. :) In the near
> future (early in the 1.2.x line) we will be upgrading our keycloak
> support, which will require us to upgrade to WildFly 9 - so that should
> be coming soon (i.e. in the next month or two).
>
> -Eric