[Apiman-user] Securing apiman admin resources and ports

[Eric Wittmann]

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 at 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
>