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?

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?

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?

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&gt; 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