From cmoulliard at redhat.com  Mon Nov  2 07:27:07 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Mon, 2 Nov 2015 13:27:07 +0100
Subject: [Apiman-user] Enhance Keycloak with Certificate Authority
Message-ID: <5637569B.5050407@redhat.com>

Hi,

During this summer a Google project has been designed to Enhance 
Keycloak with Certificate Authority. Does somebody knows if the code has 
been integrated within a Keycloak release/snapshot ?

https://www.google-melange.com/gsoc/project/details/google/gsoc2015/girirajsharma/5693417237512192

Regards,

Charles

From eric.wittmann at redhat.com  Mon Nov  2 09:41:44 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 2 Nov 2015 09:41:44 -0500
Subject: [Apiman-user] Enhance Keycloak with Certificate Authority
In-Reply-To: <5637569B.5050407@redhat.com>
References: <5637569B.5050407@redhat.com>
Message-ID: <56377628.3030702@redhat.com>

Hi Charles.

This is probably a question to send to the KeyCloak dev mailing list.

Regards,

Eric

On 11/2/2015 7:27 AM, Charles Moulliard wrote:
> Hi,
>
> During this summer a Google project has been designed to Enhance
> Keycloak with Certificate Authority. Does somebody knows if the code has
> been integrated within a Keycloak release/snapshot ?
>
> https://www.google-melange.com/gsoc/project/details/google/gsoc2015/girirajsharma/5693417237512192
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From cmoulliard at redhat.com  Thu Nov 12 05:21:21 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 12 Nov 2015 11:21:21 +0100
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
Message-ID: <56446821.3080401@redhat.com>

Hi,

According to the ApimanMan code 
(https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53), 
HTTPS is supported and the trustore, keystore password ... can be 
defined using this file 
(https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22). 


How can we configure this file when apiman is deployed as a WAR in 
wildfly or in any other Java Container ?

Regards,

Charles

From jcechace at gmail.com  Thu Nov 12 05:26:24 2015
From: jcechace at gmail.com (=?UTF-8?B?SmFrdWIgxIxlY2jDocSNZWs=?=)
Date: Thu, 12 Nov 2015 11:26:24 +0100
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
In-Reply-To: <56446821.3080401@redhat.com>
References: <56446821.3080401@redhat.com>
Message-ID: <CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>

Hello Charles,

The example you used is specific for the VertX implementation of Apiman's
gateway.

I am not actually sure about the microservice implementation and the use of
Jetty for example. However in case of WildFly you can configure the
truststore in ${APIMAN_HOME}/standalone/configuration/standalone-apiman.xml
 (or any other WF config you decide to use for running apiman)

Jakub

On Thu, Nov 12, 2015 at 11:21 AM, Charles Moulliard <cmoulliard at redhat.com>
wrote:

> Hi,
>
> According to the ApimanMan code
> (
> https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53
> ),
> HTTPS is supported and the trustore, keystore password ... can be
> defined using this file
> (
> https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22
> ).
>
>
> How can we configure this file when apiman is deployed as a WAR in
> wildfly or in any other Java Container ?
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151112/6cb83b64/attachment.html 

From cmoulliard at redhat.com  Thu Nov 12 05:51:19 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 12 Nov 2015 11:51:19 +0100
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
In-Reply-To: <CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>
References: <56446821.3080401@redhat.com>
	<CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>
Message-ID: <56446F27.9030701@redhat.com>

We don't have to use the wildfly config file but the apiman.properties 
file located under also standalone/configuration folder of wildfly

# ---------------------------------------------------------------------
# SSL/TLS settings for the gateway connector(s).
# ---------------------------------------------------------------------

# Enable devMode for HTTPS connections (gateway trusts any certificate).
# This should *NOT* be used in production mode. *Use with great care.*
apiman-gateway.connector-factory.tls.devMode=true

The connector-factory property will be next retrieved by the gateway as 
such : 
https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/war/src/main/java/io/apiman/gateway/platforms/war/WarEngineConfig.java#L134

...

On 12/11/15 11:26, Jakub ?ech??ek wrote:
> Hello Charles,
>
> The example you used is specific for the VertX implementation of 
> Apiman's gateway.
>
> I am not actually sure about the microservice implementation and the 
> use of Jetty for example. However in case of WildFly you can configure 
> the truststore in 
> ${APIMAN_HOME}/standalone/configuration/standalone-apiman.xml  (or any 
> other WF config you decide to use for running apiman)
>
> Jakub
>
> On Thu, Nov 12, 2015 at 11:21 AM, Charles Moulliard 
> <cmoulliard at redhat.com <mailto:cmoulliard at redhat.com>> wrote:
>
>     Hi,
>
>     According to the ApimanMan code
>     (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53),
>     HTTPS is supported and the trustore, keystore password ... can be
>     defined using this file
>     (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22).
>
>
>     How can we configure this file when apiman is deployed as a WAR in
>     wildfly or in any other Java Container ?
>
>     Regards,
>
>     Charles
>     _______________________________________________
>     Apiman-user mailing list
>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/apiman-user
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151112/50db4aac/attachment-0001.html 

From cmoulliard at redhat.com  Thu Nov 12 06:38:34 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 12 Nov 2015 12:38:34 +0100
Subject: [Apiman-user] Launch Vertx 3, Jetty with Apiman UI
Message-ID: <56447A3A.7070400@redhat.com>

Hi,

Is it possible to start/launch vertx3 gateway 
(target/apiman-gateway-platforms-vertx3-1.2.0-SNAPSHOT-fat.jar -conf 
src/conf/conf.json) or Jetty locally and deploy also the web front end 
of apiman ui ?

Regards,

Charles

From marc.savy at redhat.com  Thu Nov 12 07:03:20 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 12 Nov 2015 12:03:20 +0000
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
In-Reply-To: <56446F27.9030701@redhat.com>
References: <56446821.3080401@redhat.com>
	<CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>
	<56446F27.9030701@redhat.com>
Message-ID: <56448008.2080206@redhat.com>

What are you trying to achieve? Do you want mutual TLS between the
gateway and the services you're offering through apiman? Or are you
talking about TLS between a client and the gateway?

i.e.
                A            B
Client (App) <---> apiman <---> Service (API)

On 12/11/2015 10:51, Charles Moulliard wrote:
> We don't have to use the wildfly config file but the apiman.properties
> file located under also standalone/configuration folder of wildfly
>
> # ---------------------------------------------------------------------
> # SSL/TLS settings for the gateway connector(s).
> # ---------------------------------------------------------------------
>
> # Enable devMode for HTTPS connections (gateway trusts any certificate).
> # This should *NOT* be used in production mode. *Use with great care.*
> apiman-gateway.connector-factory.tls.devMode=true
>
> The connector-factory property will be next retrieved by the gateway as
> such :
> https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/war/src/main/java/io/apiman/gateway/platforms/war/WarEngineConfig.java#L134
>
> ...
>
> On 12/11/15 11:26, Jakub ?ech??ek wrote:
>> Hello Charles,
>>
>> The example you used is specific for the VertX implementation of
>> Apiman's gateway.
>>
>> I am not actually sure about the microservice implementation and the
>> use of Jetty for example. However in case of WildFly you can configure
>> the truststore in
>> ${APIMAN_HOME}/standalone/configuration/standalone-apiman.xml  (or any
>> other WF config you decide to use for running apiman)
>>
>> Jakub
>>
>> On Thu, Nov 12, 2015 at 11:21 AM, Charles Moulliard
>> <<mailto:cmoulliard at redhat.com>cmoulliard at redhat.com> wrote:
>>
>>     Hi,
>>
>>     According to the ApimanMan code
>>     (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53),
>>     HTTPS is supported and the trustore, keystore password ... can be
>>     defined using this file
>>     (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22).
>>
>>
>>     How can we configure this file when apiman is deployed as a WAR in
>>     wildfly or in any other Java Container ?
>>
>>     Regards,
>>
>>     Charles
>>     _______________________________________________
>>     Apiman-user mailing list
>>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From marc.savy at redhat.com  Thu Nov 12 07:07:43 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 12 Nov 2015 12:07:43 +0000
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
In-Reply-To: <56448008.2080206@redhat.com>
References: <56446821.3080401@redhat.com>
	<CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>
	<56446F27.9030701@redhat.com> <56448008.2080206@redhat.com>
Message-ID: <5644810F.2010107@redhat.com>

The illustration may be misaligned due to fonts... See:

https://gist.github.com/msavy/ff66017daa1660e0d4a0

On 12/11/2015 12:03, Marc Savy wrote:
> What are you trying to achieve? Do you want mutual TLS between the
> gateway and the services you're offering through apiman? Or are you
> talking about TLS between a client and the gateway?
>
> i.e.
>                         A                    B
> Client (App) <---> apiman <---> Service (API)
>
> On 12/11/2015 10:51, Charles Moulliard wrote:
> > We don't have to use the wildfly config file but the apiman.properties
> > file located under also standalone/configuration folder of wildfly
> >
> > # ---------------------------------------------------------------------
> > # SSL/TLS settings for the gateway connector(s).
> > # ---------------------------------------------------------------------
> >
> > # Enable devMode for HTTPS connections (gateway trusts any certificate).
> > # This should *NOT* be used in production mode. *Use with great care.*
> > apiman-gateway.connector-factory.tls.devMode=true
> >
> > The connector-factory property will be next retrieved by the gateway as
> > such :
> >
> https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/war/src/main/java/io/apiman/gateway/platforms/war/WarEngineConfig.java#L134
>
> >
> >
> > ...
> >
> > On 12/11/15 11:26, Jakub ?ech??ek wrote:
> >> Hello Charles,
> >>
> >> The example you used is specific for the VertX implementation of
> >> Apiman's gateway.
> >>
> >> I am not actually sure about the microservice implementation and the
> >> use of Jetty for example. However in case of WildFly you can configure
> >> the truststore in
> >> ${APIMAN_HOME}/standalone/configuration/standalone-apiman.xml  (or any
> >> other WF config you decide to use for running apiman)
> >>
> >> Jakub
> >>
> >> On Thu, Nov 12, 2015 at 11:21 AM, Charles Moulliard
> >> <<mailto:cmoulliard at redhat.com>cmoulliard at redhat.com> wrote:
> >>
> >>     Hi,
> >>
> >>     According to the ApimanMan code
> >>
> >>
> (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53),
>
> >>
> >>     HTTPS is supported and the trustore, keystore password ... can be
> >>     defined using this file
> >>
> >>
> (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22).
>
> >>
> >>
> >>
> >>     How can we configure this file when apiman is deployed as a WAR in
> >>     wildfly or in any other Java Container ?
> >>
> >>     Regards,
> >>
> >>     Charles
> >>     _______________________________________________
> >>     Apiman-user mailing list
> >>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
> >>     https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >>
> >
> >
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >
>


From cmoulliard at redhat.com  Thu Nov 12 07:27:11 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 12 Nov 2015 13:27:11 +0100
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
In-Reply-To: <56448008.2080206@redhat.com>
References: <56446821.3080401@redhat.com>
	<CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>
	<56446F27.9030701@redhat.com> <56448008.2080206@redhat.com>
Message-ID: <5644859F.9090203@redhat.com>

I was talking about https between the client (A) and apiman (B)

I suppose that different combinations are possible ...

1) No HTTPS

Client (App) <-- HTTP -> apiman <-- HTTP --> Service (API)

2) HTTPS / HTTP

Client (App) <-- HTTPS -> apiman <-- HTTP--> Service (API)

3) HTTPS / HTTPS

Client (App) <-- HTTPS --> apiman <-- HTTPS --> Service (API)

What is not currently supportly is mutual SSL between client (A) & 
Apiman (B) (= client will send its certificate for validation & auth) ?


On 12/11/15 13:03, Marc Savy wrote:
> What are you trying to achieve? Do you want mutual TLS between the
> gateway and the services you're offering through apiman? Or are you
> talking about TLS between a client and the gateway?
>
> i.e.
>                A            B
> Client (App) <---> apiman <---> Service (API)
>
> On 12/11/2015 10:51, Charles Moulliard wrote:
>> We don't have to use the wildfly config file but the apiman.properties
>> file located under also standalone/configuration folder of wildfly
>>
>> # ---------------------------------------------------------------------
>> # SSL/TLS settings for the gateway connector(s).
>> # ---------------------------------------------------------------------
>>
>> # Enable devMode for HTTPS connections (gateway trusts any certificate).
>> # This should *NOT* be used in production mode. *Use with great care.*
>> apiman-gateway.connector-factory.tls.devMode=true
>>
>> The connector-factory property will be next retrieved by the gateway as
>> such :
>> https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/war/src/main/java/io/apiman/gateway/platforms/war/WarEngineConfig.java#L134 
>>
>>
>> ...
>>
>> On 12/11/15 11:26, Jakub ?ech??ek wrote:
>>> Hello Charles,
>>>
>>> The example you used is specific for the VertX implementation of
>>> Apiman's gateway.
>>>
>>> I am not actually sure about the microservice implementation and the
>>> use of Jetty for example. However in case of WildFly you can configure
>>> the truststore in
>>> ${APIMAN_HOME}/standalone/configuration/standalone-apiman.xml (or any
>>> other WF config you decide to use for running apiman)
>>>
>>> Jakub
>>>
>>> On Thu, Nov 12, 2015 at 11:21 AM, Charles Moulliard
>>> <<mailto:cmoulliard at redhat.com>cmoulliard at redhat.com> wrote:
>>>
>>>     Hi,
>>>
>>>     According to the ApimanMan code
>>> (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53),
>>>     HTTPS is supported and the trustore, keystore password ... can be
>>>     defined using this file
>>> (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22).
>>>
>>>
>>>     How can we configure this file when apiman is deployed as a WAR in
>>>     wildfly or in any other Java Container ?
>>>
>>>     Regards,
>>>
>>>     Charles
>>>     _______________________________________________
>>>     Apiman-user mailing list
>>>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/apiman-user
>>>
>>>
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>


From marc.savy at redhat.com  Thu Nov 12 07:31:30 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 12 Nov 2015 12:31:30 +0000
Subject: [Apiman-user] Configure keystore, truststore, password for Vertx
In-Reply-To: <5644859F.9090203@redhat.com>
References: <56446821.3080401@redhat.com>
	<CALvAxYs9wmo1LSDOJzV+tyFcNajn+au3Q181bOF3wZeG-2BmBw@mail.gmail.com>
	<56446F27.9030701@redhat.com> <56448008.2080206@redhat.com>
	<5644859F.9090203@redhat.com>
Message-ID: <564486A2.4060500@redhat.com>

Correct. There are multiple possible combinations.

 > What is not currently supportly is mutual SSL between client (A) & Apiman (B) (= client will send its certificate for validation & auth) ?

You can set this up yourself if you want. For WF: https://girirajsharma.wordpress.com/2015/10/04/authentication-via-wildfly-mutual-ssl-two-way-configuration/

On 12/11/2015 12:27, Charles Moulliard wrote:
> I was talking about https between the client (A) and apiman (B)
>
> I suppose that different combinations are possible ...
>
> 1) No HTTPS
>
> Client (App) <-- HTTP -> apiman <-- HTTP --> Service (API)
>
> 2) HTTPS / HTTP
>
> Client (App) <-- HTTPS -> apiman <-- HTTP--> Service (API)
>
> 3) HTTPS / HTTPS
>
> Client (App) <-- HTTPS --> apiman <-- HTTPS --> Service (API)
>
> What is not currently supportly is mutual SSL between client (A) &
> Apiman (B) (= client will send its certificate for validation & auth) ?
>
>
> On 12/11/15 13:03, Marc Savy wrote:
> > What are you trying to achieve? Do you want mutual TLS between the
> > gateway and the services you're offering through apiman? Or are you
> > talking about TLS between a client and the gateway?
> >
> > i.e.
> >                A            B
> > Client (App) <---> apiman <---> Service (API)
> >
> > On 12/11/2015 10:51, Charles Moulliard wrote:
> >> We don't have to use the wildfly config file but the apiman.properties
> >> file located under also standalone/configuration folder of wildfly
> >>
> >> # ---------------------------------------------------------------------
> >> # SSL/TLS settings for the gateway connector(s).
> >> # ---------------------------------------------------------------------
> >>
> >> # Enable devMode for HTTPS connections (gateway trusts any certificate).
> >> # This should *NOT* be used in production mode. *Use with great care.*
> >> apiman-gateway.connector-factory.tls.devMode=true
> >>
> >> The connector-factory property will be next retrieved by the gateway as
> >> such :
> >> https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/war/src/main/java/io/apiman/gateway/platforms/war/WarEngineConfig.java#L134
> >>
> >>
> >> ...
> >>
> >> On 12/11/15 11:26, Jakub ?ech??ek wrote:
> >>> Hello Charles,
> >>>
> >>> The example you used is specific for the VertX implementation of
> >>> Apiman's gateway.
> >>>
> >>> I am not actually sure about the microservice implementation and the
> >>> use of Jetty for example. However in case of WildFly you can configure
> >>> the truststore in
> >>> ${APIMAN_HOME}/standalone/configuration/standalone-apiman.xml (or any
> >>> other WF config you decide to use for running apiman)
> >>>
> >>> Jakub
> >>>
> >>> On Thu, Nov 12, 2015 at 11:21 AM, Charles Moulliard
> >>> <<mailto:cmoulliard at redhat.com>cmoulliard at redhat.com> wrote:
> >>>
> >>>     Hi,
> >>>
> >>>     According to the ApimanMan code
> >>> (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/main/java/io/apiman/gateway/platforms/vertx3/verticles/HttpsGatewayVerticle.java#L36-L53),
> >>>
> >>>     HTTPS is supported and the trustore, keystore password ... can be
> >>>     defined using this file
> >>> (https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/vertx3/vertx3/src/conf/conf.json#L22).
> >>>
> >>>
> >>>
> >>>     How can we configure this file when apiman is deployed as a WAR in
> >>>     wildfly or in any other Java Container ?
> >>>
> >>>     Regards,
> >>>
> >>>     Charles
> >>>     _______________________________________________
> >>>     Apiman-user mailing list
> >>>     Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
> >>>     https://lists.jboss.org/mailman/listinfo/apiman-user
> >>>
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >
>


From marc.savy at redhat.com  Thu Nov 12 07:57:30 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 12 Nov 2015 12:57:30 +0000
Subject: [Apiman-user] Launch Vertx 3, Jetty with Apiman UI
In-Reply-To: <56447A3A.7070400@redhat.com>
References: <56447A3A.7070400@redhat.com>
Message-ID: <56448CBA.8000706@redhat.com>

Hi,

I'm not sure I really understand your question.

The manager's backend component(s) can't be run on Vert.x 3. It's a
WAR-type implementation, so you can run it on Jetty, WF, EAP, etc - but
not Vert.x 3.

The gateway is a *separate* component, and there's a Vert.x 3
implementation.

So, for instance, you could have the manager running on Jetty and the
gateway running on Vert.x.

Regards,
Marc

On 12/11/2015 11:38, Charles Moulliard wrote:
> Hi,
>
> Is it possible to start/launch vertx3 gateway
> (target/apiman-gateway-platforms-vertx3-1.2.0-SNAPSHOT-fat.jar -conf
> src/conf/conf.json) or Jetty locally and deploy also the web front end
> of apiman ui ?
>
> Regards,
>
> Charles
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From cmoulliard at redhat.com  Thu Nov 12 08:04:32 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 12 Nov 2015 14:04:32 +0100
Subject: [Apiman-user] Launch Vertx 3, Jetty with Apiman UI
In-Reply-To: <56448CBA.8000706@redhat.com>
References: <56447A3A.7070400@redhat.com> <56448CBA.8000706@redhat.com>
Message-ID: <56448E60.1070809@redhat.com>

So I rephrase my question.

How can I start jetty to expose the apiman UI with the appropriate WAR 
files and use Vertx 3 as gateway engine ?


On 12/11/15 13:57, Marc Savy wrote:
> Hi,
>
> I'm not sure I really understand your question.
>
> The manager's backend component(s) can't be run on Vert.x 3. It's a
> WAR-type implementation, so you can run it on Jetty, WF, EAP, etc - but
> not Vert.x 3.
>
> The gateway is a *separate* component, and there's a Vert.x 3
> implementation.
>
> So, for instance, you could have the manager running on Jetty and the
> gateway running on Vert.x.
>
> Regards,
> Marc
>
> On 12/11/2015 11:38, Charles Moulliard wrote:
>> Hi,
>>
>> Is it possible to start/launch vertx3 gateway
>> (target/apiman-gateway-platforms-vertx3-1.2.0-SNAPSHOT-fat.jar -conf
>> src/conf/conf.json) or Jetty locally and deploy also the web front end
>> of apiman ui ?
>>
>> Regards,
>>
>> Charles
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user


From marc.savy at redhat.com  Thu Nov 12 08:24:23 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Thu, 12 Nov 2015 13:24:23 +0000
Subject: [Apiman-user] Launch Vertx 3, Jetty with Apiman UI
In-Reply-To: <56448E60.1070809@redhat.com>
References: <56447A3A.7070400@redhat.com> <56448CBA.8000706@redhat.com>
	<56448E60.1070809@redhat.com>
Message-ID: <56449307.30403@redhat.com>

1. Start up the api manager (for some simple setups, see apiman-servers @ https://github.com/apiman/apiman-servers - e.g. h2, postgresql, ...)
2. Configure & start up the gateway (e.g. Vert.x 3 impl)
3. Add the gateway from 2 to the manager (admin section of UI -> add gateway).

That's about it!

On 12/11/2015 13:04, Charles Moulliard wrote:
> So I rephrase my question.
>
> How can I start jetty to expose the apiman UI with the appropriate WAR
> files and use Vertx 3 as gateway engine ?
>
>
> On 12/11/15 13:57, Marc Savy wrote:
> > Hi,
> >
> > I'm not sure I really understand your question.
> >
> > The manager's backend component(s) can't be run on Vert.x 3. It's a
> > WAR-type implementation, so you can run it on Jetty, WF, EAP, etc - but
> > not Vert.x 3.
> >
> > The gateway is a *separate* component, and there's a Vert.x 3
> > implementation.
> >
> > So, for instance, you could have the manager running on Jetty and the
> > gateway running on Vert.x.
> >
> > Regards,
> > Marc
> >
> > On 12/11/2015 11:38, Charles Moulliard wrote:
> >> Hi,
> >>
> >> Is it possible to start/launch vertx3 gateway
> >> (target/apiman-gateway-platforms-vertx3-1.2.0-SNAPSHOT-fat.jar -conf
> >> src/conf/conf.json) or Jetty locally and deploy also the web front end
> >> of apiman ui ?
> >>
> >> Regards,
> >>
> >> Charles
> >> _______________________________________________
> >> Apiman-user mailing list
> >> Apiman-user at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From cmoulliard at redhat.com  Thu Nov 12 09:12:19 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Thu, 12 Nov 2015 15:12:19 +0100
Subject: [Apiman-user] Launch Vertx 3, Jetty with Apiman UI
In-Reply-To: <56449307.30403@redhat.com>
References: <56447A3A.7070400@redhat.com> <56448CBA.8000706@redhat.com>
	<56448E60.1070809@redhat.com> <56449307.30403@redhat.com>
Message-ID: <56449E43.5080200@redhat.com>


On 12/11/15 14:24, Marc Savy wrote:
> 1. Start up the api manager (for some simple setups, see 
> apiman-servers @ https://github.com/apiman/apiman-servers - e.g. h2, 
> postgresql, ...)
 >> I have review this part of the code which allow to start a 
MicroService --> 
https://github.com/cmoulliard/apiman/blob/master/gateway/platforms/war/micro/src/main/java/io/apiman/gateway/platforms/war/micro/GatewayMicroService.java
> 2. Configure & start up the gateway (e.g. Vert.x 3 impl)
 >> Do you mean that I have to start Vertx3 impl server from the project 
where the code has ben compiled (--> java -jar 
target/apiman-gateway-platforms-vertx3-1.2.0-SNAPSHOT-fat.jar -conf 
<path-to-your-config.json>) ?
 >> That should be great to have an option that we could use within 
apiman-servers config file to specify which gateway we would like to use 
(Vertx3, Jetty Servlet, Undertow, ...)
> 3. Add the gateway from 2 to the manager (admin section of UI -> add 
> gateway).
 >> Do I have to copy/paste the jar + config files ? Can you clarify 
this point please ?
>
> That's about it!
>
> On 12/11/2015 13:04, Charles Moulliard wrote:
>> So I rephrase my question.
>>
>> How can I start jetty to expose the apiman UI with the appropriate WAR
>> files and use Vertx 3 as gateway engine ?
>>
>>
>> On 12/11/15 13:57, Marc Savy wrote:
>> > Hi,
>> >
>> > I'm not sure I really understand your question.
>> >
>> > The manager's backend component(s) can't be run on Vert.x 3. It's a
>> > WAR-type implementation, so you can run it on Jetty, WF, EAP, etc - 
>> but
>> > not Vert.x 3.
>> >
>> > The gateway is a *separate* component, and there's a Vert.x 3
>> > implementation.
>> >
>> > So, for instance, you could have the manager running on Jetty and the
>> > gateway running on Vert.x.
>> >
>> > Regards,
>> > Marc
>> >
>> > On 12/11/2015 11:38, Charles Moulliard wrote:
>> >> Hi,
>> >>
>> >> Is it possible to start/launch vertx3 gateway
>> >> (target/apiman-gateway-platforms-vertx3-1.2.0-SNAPSHOT-fat.jar -conf
>> >> src/conf/conf.json) or Jetty locally and deploy also the web front 
>> end
>> >> of apiman ui ?
>> >>
>> >> Regards,
>> >>
>> >> Charles
>> >> _______________________________________________
>> >> Apiman-user mailing list
>> >> Apiman-user at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>
>> > _______________________________________________
>> > Apiman-user mailing list
>> > Apiman-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151112/41b53f9b/attachment.html 

From ton.swieb at finalist.nl  Tue Nov 17 07:26:40 2015
From: ton.swieb at finalist.nl (Ton Swieb)
Date: Tue, 17 Nov 2015 13:26:40 +0100
Subject: [Apiman-user] Docker image for Apiman 1.1.9.Final
Message-ID: <CAJJ5CnQ2SmeU93YtNUwH2OE1OBo6b0m7w+Bv_SM3W1SdxFSpAA@mail.gmail.com>

Hi,

Is there a docker image available for the 1.1.9.Final release?
I would expect it to find it here:
https://hub.docker.com/r/jboss/apiman-wildfly/
But 1.1.8.Final is the latest I can find there.

regards,

Ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151117/530f3272/attachment.html 

From eric.wittmann at redhat.com  Tue Nov 17 10:53:07 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 17 Nov 2015 10:53:07 -0500
Subject: [Apiman-user] Docker image for Apiman 1.1.9.Final
In-Reply-To: <CAJJ5CnQ2SmeU93YtNUwH2OE1OBo6b0m7w+Bv_SM3W1SdxFSpAA@mail.gmail.com>
References: <CAJJ5CnQ2SmeU93YtNUwH2OE1OBo6b0m7w+Bv_SM3W1SdxFSpAA@mail.gmail.com>
Message-ID: <564B4D63.3070509@redhat.com>

Alas we do not control the tagging of that docker image and sometimes 
forget to check to see if it was done.  This time it was overlooked by 
the /r/jboss guys.  :)

I should be building now.  Keep an eye on it and if you don't see a 
1.1.9.Final docker image sometime soon let me know.

Looks like there might be some docker hub issues ATM that may delay things.

-Eric

On 11/17/2015 7:26 AM, Ton Swieb wrote:
> Hi,
>
> Is there a docker image available for the 1.1.9.Final release?
> I would expect it to find it here:
> https://hub.docker.com/r/jboss/apiman-wildfly/
> But 1.1.8.Final is the latest I can find there.
>
> regards,
>
> Ton
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From ton at finalist.nl  Wed Nov 18 09:34:17 2015
From: ton at finalist.nl (Ton Swieb)
Date: Wed, 18 Nov 2015 15:34:17 +0100
Subject: [Apiman-user] Forwarding HTTP requests to service implementations
	secured by OAuth
Message-ID: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>

Hi,

I am using Apiman 1.1.8.Final and I want to use a backend service in Apiman
which is secured by OAuth.
So instead of securing the Apiman side of the service, using the Keycloak
OAuth plugin, Apiman needs forward calls to a service implementation that
is secured by OAuth. I have got an OAuth token with a very long time to
live (days/weeks/months) which I can use.

Currently I only see the option to configure BASIC Authentication or
MTLS/Two-Way-SSL on the service implementation.
Would it be possible to add the HTTP Simple Header policy to the service
and set the Authorization header with "Bearer........." or will that be
stripped off by Apiman when forwarding the call to the backend service?

Kind regards,

Ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151118/eacbc48a/attachment.html 

From marc.savy at redhat.com  Wed Nov 18 10:02:52 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Wed, 18 Nov 2015 15:02:52 +0000
Subject: [Apiman-user] Forwarding HTTP requests to service
 implementations secured by OAuth
In-Reply-To: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
References: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
Message-ID: <564C931C.3060302@redhat.com>

Hi Ton,

Just to clarify. From what I understand, you're trying to secure communications between the apiman gateway and back-end service using OAuth2/OpenID Connect?

I.e. You are *not* OAuth2 simply between the client to the apiman gateway.

Regards,
Marc

On 18/11/2015 14:34, Ton Swieb wrote:
> Hi,
>
> I am using Apiman 1.1.8.Final and I want to use a backend service in
> Apiman which is secured by OAuth.
> So instead of securing the Apiman side of the service, using the
> Keycloak OAuth plugin, Apiman needs forward calls to a service
> implementation that is secured by OAuth. I have got an OAuth token with
> a very long time to live (days/weeks/months) which I can use.
>
> Currently I only see the option to configure BASIC Authentication or
> MTLS/Two-Way-SSL on the service implementation.
> Would it be possible to add the HTTP Simple Header policy to the service
> and set the Authorization header with "Bearer........." or will that be
> stripped off by Apiman when forwarding the call to the backend service?
>
> Kind regards,
>
> Ton
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>


From ton at finalist.nl  Wed Nov 18 10:11:45 2015
From: ton at finalist.nl (Ton Swieb)
Date: Wed, 18 Nov 2015 16:11:45 +0100
Subject: [Apiman-user] Forwarding HTTP requests to service
 implementations secured by OAuth
In-Reply-To: <564C931C.3060302@redhat.com>
References: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
	<564C931C.3060302@redhat.com>
Message-ID: <CAJJ5CnTihasxwwUcE07kKtiuvLw+LVZinSmsDFo8QPQGP+_VGw@mail.gmail.com>

Hi Marc,

That is correct.

Regards,

Ton

2015-11-18 16:02 GMT+01:00 Marc Savy <marc.savy at redhat.com>:

> Hi Ton,
>
> Just to clarify. From what I understand, you're trying to secure
> communications between the apiman gateway and back-end service using
> OAuth2/OpenID Connect?
>
> I.e. You are *not* OAuth2 simply between the client to the apiman gateway.
>
> Regards,
> Marc
>
> On 18/11/2015 14:34, Ton Swieb wrote:
>
>> Hi,
>>
>> I am using Apiman 1.1.8.Final and I want to use a backend service in
>> Apiman which is secured by OAuth.
>> So instead of securing the Apiman side of the service, using the
>> Keycloak OAuth plugin, Apiman needs forward calls to a service
>> implementation that is secured by OAuth. I have got an OAuth token with
>> a very long time to live (days/weeks/months) which I can use.
>>
>> Currently I only see the option to configure BASIC Authentication or
>> MTLS/Two-Way-SSL on the service implementation.
>> Would it be possible to add the HTTP Simple Header policy to the service
>> and set the Authorization header with "Bearer........." or will that be
>> stripped off by Apiman when forwarding the call to the backend service?
>>
>> Kind regards,
>>
>> Ton
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151118/6f493563/attachment-0001.html 

From pblair at clearme.com  Tue Nov 24 11:53:17 2015
From: pblair at clearme.com (Paul Blair)
Date: Tue, 24 Nov 2015 16:53:17 +0000
Subject: [Apiman-user] Securing apiman admin resources and ports
Message-ID: <D27A002B.101E8%pblair@clearme.com>

One thing we're noticing working with apiman is that besides the apiman management console, running apiman on Wildfly exposes a Wildfly admin console as well. In addition, the Wildfly configuration exposes ports for ajp and several other things. We're looking to make sure all this is locked down and secure. I have a few questions relative to that:

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151124/4fc537e5/attachment.html 

From eric.wittmann at redhat.com  Tue Nov 24 15:12:42 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Tue, 24 Nov 2015 15:12:42 -0500
Subject: [Apiman-user] Securing apiman admin resources and ports
In-Reply-To: <D27A002B.101E8%pblair@clearme.com>
References: <D27A002B.101E8%pblair@clearme.com>
Message-ID: <5654C4BA.6050303@redhat.com>

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#jetty9-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

From pblair at clearme.com  Tue Nov 24 15:38:49 2015
From: pblair at clearme.com (Paul Blair)
Date: Tue, 24 Nov 2015 20:38:49 +0000
Subject: [Apiman-user] Securing apiman admin resources and ports
In-Reply-To: <5654C4BA.6050303@redhat.com>
Message-ID: <D27A34BF.101F9%pblair@clearme.com>

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



From eric.wittmann at redhat.com  Wed Nov 25 07:28:50 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Wed, 25 Nov 2015 07:28:50 -0500
Subject: [Apiman-user] Securing apiman admin resources and ports
In-Reply-To: <D27A34BF.101F9%pblair@clearme.com>
References: <D27A34BF.101F9%pblair@clearme.com>
Message-ID: <5655A982.5090802@redhat.com>

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
>

From ton at finalist.nl  Fri Nov 27 08:41:14 2015
From: ton at finalist.nl (Ton Swieb)
Date: Fri, 27 Nov 2015 14:41:14 +0100
Subject: [Apiman-user] Swagger documentation not rendered for service
Message-ID: <CAJJ5CnQdaxAQ-feNa1Hgu1MT+YNBQN82ud0Jo=3tSvL2pH+Usw@mail.gmail.com>

Hi,

I added a Swagger definition to my service definition, but for some reason
it will not render it. I am using Apiman 1.1.8.Final

I have a service endpoint like:
https://192.168.99.100:8443/apiman-gateway/Organization/Service/1.0

I am able to directly download the Swagger JSON definition using the URL:
http://192.168.99.100:8080/apiman/organizations/Organization/services/Service/versions/1.0/definition/

But on the page:
http://192.168.99.100:8080/apimanui/api-manager/browse/orgs/Organization/Service/1.0/def
the Swagger definition is not rendered.

It shows the following message:

[image: Inline afbeelding 1]


The server logging does not show any errors, but the browser log does show
some errors.

Is this a known bug or am I doing something wrong? It looks like it cannot
load some required Javascript libraries.

apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Loading page.
apiman-manager.js:1172:21
apiman [2:34:56 PM]>>  |{0}| >> Using cached current user from $rootScope.
apiman-manager.js:1172:21
apiman [2:34:56 PM]>>  Current user is admin. apiman-manager.js:1172:21
apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Binding currentUser to
$scope. apiman-manager.js:1175:21
apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Binding version to $scope.
apiman-manager.js:1175:21
"apiman [2:34:56 PM]>>  !!!!! Using definition URL:
http://192.168.99.100:8080/apiman/organizations/Organization/services/Service/versions/1.0/definition"
apiman-manager.js:1175:21
window.ApiKeyAuthorization is deprecated. Please use
SwaggerClient.ApiKeyAuthorization. swagger-ui.js:251:7
Using window.authorizations is deprecated. Please use
SwaggerUi.api.clientAuthorizations.add(). swagger-ui.js:251:7
Error: window.swaggerUi is not defined
window.authorizations.add@
http://192.168.99.100:8080/apimanui/libs/swagger-ui/dist/swagger-ui.js?cid=2015-09-10_15:24:230:1
Apiman.ConsumerSvcDefController</<@
http://192.168.99.100:8080/apimanui/dist/apiman-manager.js?cid=2015-09-10_15:24:2252:1
ApimanPageLifecycle.PageLifecycle</<.loadPage/<@
http://192.168.99.100:8080/apimanui/dist/apiman-manager.js?cid=2015-09-10_15:24:1123:29
processQueue@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:13300:27
scheduleProcessQueue/<@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:13316:27
$RootScopeProvider/this.$get</Scope.prototype.$eval@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14552:16
$RootScopeProvider/this.$get</Scope.prototype.$digest@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14368:15
$RootScopeProvider/this.$get</Scope.prototype.$apply@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14657:13
done@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9734:36
completeRequest@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9924:7
requestLoaded@
http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9865:1
 angular.js:11707:18

Regards,

Ton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151127/16ace99d/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 48017 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20151127/16ace99d/attachment-0001.png 

From ton at finalist.nl  Fri Nov 27 09:11:02 2015
From: ton at finalist.nl (Ton Swieb)
Date: Fri, 27 Nov 2015 15:11:02 +0100
Subject: [Apiman-user] Swagger documentation not rendered for service
In-Reply-To: <CAJJ5CnQdaxAQ-feNa1Hgu1MT+YNBQN82ud0Jo=3tSvL2pH+Usw@mail.gmail.com>
References: <CAJJ5CnQdaxAQ-feNa1Hgu1MT+YNBQN82ud0Jo=3tSvL2pH+Usw@mail.gmail.com>
Message-ID: <CAJJ5CnSq5wFkBT349pGYsJWeNtHRqPPQCtDABwyM0F8Y4fcRWw@mail.gmail.com>

Hi,

I totally missed https://issues.jboss.org/browse/APIMAN-691when looking at
the release notes of 1.1.9.Final.
Upgrading to 1.1.9.Final fixed my problem.

Regards,

Ton


2015-11-27 14:41 GMT+01:00 Ton Swieb <ton at finalist.nl>:

> Hi,
>
> I added a Swagger definition to my service definition, but for some reason
> it will not render it. I am using Apiman 1.1.8.Final
>
> I have a service endpoint like:
> https://192.168.99.100:8443/apiman-gateway/Organization/Service/1.0
>
> I am able to directly download the Swagger JSON definition using the URL:
> http://192.168.99.100:8080/apiman/organizations/Organization/services/Service/versions/1.0/definition/
>
> But on the page:
> http://192.168.99.100:8080/apimanui/api-manager/browse/orgs/Organization/Service/1.0/def
> the Swagger definition is not rendered.
>
> It shows the following message:
>
> [image: Inline afbeelding 1]
>
>
> The server logging does not show any errors, but the browser log does show
> some errors.
>
> Is this a known bug or am I doing something wrong? It looks like it cannot
> load some required Javascript libraries.
>
> apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Loading page.
> apiman-manager.js:1172:21
> apiman [2:34:56 PM]>>  |{0}| >> Using cached current user from $rootScope.
> apiman-manager.js:1172:21
> apiman [2:34:56 PM]>>  Current user is admin. apiman-manager.js:1172:21
> apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Binding currentUser to
> $scope. apiman-manager.js:1175:21
> apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Binding version to $scope.
> apiman-manager.js:1175:21
> "apiman [2:34:56 PM]>>  !!!!! Using definition URL:
> http://192.168.99.100:8080/apiman/organizations/Organization/services/Service/versions/1.0/definition"
> apiman-manager.js:1175:21
> window.ApiKeyAuthorization is deprecated. Please use
> SwaggerClient.ApiKeyAuthorization. swagger-ui.js:251:7
> Using window.authorizations is deprecated. Please use
> SwaggerUi.api.clientAuthorizations.add(). swagger-ui.js:251:7
> Error: window.swaggerUi is not defined
> window.authorizations.add@
> http://192.168.99.100:8080/apimanui/libs/swagger-ui/dist/swagger-ui.js?cid=2015-09-10_15:24:230:1
> Apiman.ConsumerSvcDefController</<@
> http://192.168.99.100:8080/apimanui/dist/apiman-manager.js?cid=2015-09-10_15:24:2252:1
> ApimanPageLifecycle.PageLifecycle</<.loadPage/<@
> http://192.168.99.100:8080/apimanui/dist/apiman-manager.js?cid=2015-09-10_15:24:1123:29
> processQueue@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:13300:27
> scheduleProcessQueue/<@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:13316:27
> $RootScopeProvider/this.$get</Scope.prototype.$eval@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14552:16
> $RootScopeProvider/this.$get</Scope.prototype.$digest@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14368:15
> $RootScopeProvider/this.$get</Scope.prototype.$apply@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14657:13
> done@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9734:36
> completeRequest@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9924:7
> requestLoaded@
> http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9865:1
>  angular.js:11707:18
>
> Regards,
>
> Ton
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151127/695f20d0/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 48017 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/apiman-user/attachments/20151127/695f20d0/attachment-0001.png 

From ton at finalist.nl  Fri Nov 27 09:16:45 2015
From: ton at finalist.nl (Ton Swieb)
Date: Fri, 27 Nov 2015 15:16:45 +0100
Subject: [Apiman-user] Docker image for Apiman 1.1.9.Final
Message-ID: <CAJJ5CnR3GM67wWtg-TxAip54HFXFObBtH1GDtSBf4S5prUAzQA@mail.gmail.com>

Hi Eric,

Thanks for kicking of the docker build.
I did find the 1.1.9.Final Docker image, but it looks like "latest" is
still pointing at 1.1.8.Final.
When doing a "docker pull jboss/apiman-wildfly" I end up with the
1.1.8.Final version instead of the 1.1.9.Final.

Regards,

Ton

2015-11-17 16:53 GMT+01:00 Eric Wittmann <eric.wittmann at redhat.com>:

> Alas we do not control the tagging of that docker image and sometimes
> forget to check to see if it was done.  This time it was overlooked by the
> /r/jboss guys.  :)
>
> I should be building now.  Keep an eye on it and if you don't see a
> 1.1.9.Final docker image sometime soon let me know.
>
> Looks like there might be some docker hub issues ATM that may delay things.
>
> -Eric
>
> On 11/17/2015 7:26 AM, Ton Swieb wrote:
>
>> Hi,
>>
>> Is there a docker image available for the 1.1.9.Final release?
>> I would expect it to find it here:
>> https://hub.docker.com/r/jboss/apiman-wildfly/
>> But 1.1.8.Final is the latest I can find there.
>>
>> regards,
>>
>> Ton
>>
>>
>>
>> _______________________________________________
>> Apiman-user mailing list
>> Apiman-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151127/d625be9a/attachment.html 

From eric.wittmann at redhat.com  Sat Nov 28 18:43:35 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Sat, 28 Nov 2015 18:43:35 -0500
Subject: [Apiman-user] Swagger documentation not rendered for service
In-Reply-To: <CAJJ5CnSq5wFkBT349pGYsJWeNtHRqPPQCtDABwyM0F8Y4fcRWw@mail.gmail.com>
References: <CAJJ5CnQdaxAQ-feNa1Hgu1MT+YNBQN82ud0Jo=3tSvL2pH+Usw@mail.gmail.com>
	<CAJJ5CnSq5wFkBT349pGYsJWeNtHRqPPQCtDABwyM0F8Y4fcRWw@mail.gmail.com>
Message-ID: <565A3C27.7080101@redhat.com>

Awesome!  :)

On 11/27/2015 9:11 AM, Ton Swieb wrote:
> Hi,
>
> I totally missed https://issues.jboss.org/browse/APIMAN-691when looking
> at the release notes of 1.1.9.Final.
> Upgrading to 1.1.9.Final fixed my problem.
>
> Regards,
>
> Ton
>
>
> 2015-11-27 14:41 GMT+01:00 Ton Swieb <ton at finalist.nl
> <mailto:ton at finalist.nl>>:
>
>     Hi,
>
>     I added a Swagger definition to my service definition, but for some
>     reason it will not render it. I am using Apiman 1.1.8.Final
>
>     I have a service endpoint like:
>     https://192.168.99.100:8443/apiman-gateway/Organization/Service/1.0
>
>     I am able to directly download the Swagger JSON definition using the
>     URL:
>     http://192.168.99.100:8080/apiman/organizations/Organization/services/Service/versions/1.0/definition/
>
>     But on the page:
>     http://192.168.99.100:8080/apimanui/api-manager/browse/orgs/Organization/Service/1.0/def
>     the Swagger definition is not rendered.
>
>     It shows the following message:
>
>     Inline afbeelding 1
>
>
>     The server logging does not show any errors, but the browser log
>     does show some errors.
>
>     Is this a known bug or am I doing something wrong? It looks like it
>     cannot load some required Javascript libraries.
>
>     apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Loading page.
>     apiman-manager.js:1172:21
>     apiman [2:34:56 PM]>>  |{0}| >> Using cached current user from
>     $rootScope. apiman-manager.js:1172:21
>     apiman [2:34:56 PM]>>  Current user is admin. apiman-manager.js:1172:21
>     apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Binding currentUser
>     to $scope. apiman-manager.js:1175:21
>     apiman [2:34:56 PM]>>  |ConsumerServiceDef| >> Binding version to
>     $scope. apiman-manager.js:1175:21
>     "apiman [2:34:56 PM]>>  !!!!! Using definition URL:
>     http://192.168.99.100:8080/apiman/organizations/Organization/services/Service/versions/1.0/definition"
>     apiman-manager.js:1175:21
>     window.ApiKeyAuthorization is deprecated. Please use
>     SwaggerClient.ApiKeyAuthorization. swagger-ui.js:251:7
>     Using window.authorizations is deprecated. Please use
>     SwaggerUi.api.clientAuthorizations.add(). swagger-ui.js:251:7
>     Error: window.swaggerUi is not defined
>     window.authorizations.add at http://192.168.99.100:8080/apimanui/libs/swagger-ui/dist/swagger-ui.js?cid=2015-09-10_15:24:230:1
>     Apiman.ConsumerSvcDefController</<@http://192.168.99.100:8080/apimanui/dist/apiman-manager.js?cid=2015-09-10_15:24:2252:1
>     ApimanPageLifecycle.PageLifecycle</<.loadPage/<@http://192.168.99.100:8080/apimanui/dist/apiman-manager.js?cid=2015-09-10_15:24:1123:29
>     processQueue at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:13300:27
>     scheduleProcessQueue/<@http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:13316:27
>     $RootScopeProvider/this.$get</Scope.prototype.$eval at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14552:16
>     $RootScopeProvider/this.$get</Scope.prototype.$digest at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14368:15
>     $RootScopeProvider/this.$get</Scope.prototype.$apply at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:14657:13
>     done at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9734:36
>     completeRequest at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9924:7
>     requestLoaded at http://192.168.99.100:8080/apimanui/libs/angular/angular.js?cid=2015-09-10_15:24:9865:1
>       angular.js:11707:18
>
>     Regards,
>
>     Ton
>
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Sat Nov 28 18:44:41 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Sat, 28 Nov 2015 18:44:41 -0500
Subject: [Apiman-user] Docker image for Apiman 1.1.9.Final
In-Reply-To: <CAJJ5CnR3GM67wWtg-TxAip54HFXFObBtH1GDtSBf4S5prUAzQA@mail.gmail.com>
References: <CAJJ5CnR3GM67wWtg-TxAip54HFXFObBtH1GDtSBf4S5prUAzQA@mail.gmail.com>
Message-ID: <565A3C69.10406@redhat.com>

OK thanks for letting me know.  I'm not sure how 'latest' gets aliased 
to some specific version.  I'll have to poke around. :)

I assume you resolved it by pulling the specific version?

On 11/27/2015 9:16 AM, Ton Swieb wrote:
> Hi Eric,
>
> Thanks for kicking of the docker build.
> I did find the 1.1.9.Final Docker image, but it looks like "latest" is
> still pointing at 1.1.8.Final.
> When doing a "docker pull jboss/apiman-wildfly" I end up with the
> 1.1.8.Final version instead of the 1.1.9.Final.
>
> Regards,
>
> Ton
>
> 2015-11-17 16:53 GMT+01:00 Eric Wittmann <eric.wittmann at redhat.com
> <mailto:eric.wittmann at redhat.com>>:
>
>     Alas we do not control the tagging of that docker image and
>     sometimes forget to check to see if it was done.  This time it was
>     overlooked by the /r/jboss guys.  :)
>
>     I should be building now.  Keep an eye on it and if you don't see a
>     1.1.9.Final docker image sometime soon let me know.
>
>     Looks like there might be some docker hub issues ATM that may delay
>     things.
>
>     -Eric
>
>     On 11/17/2015 7:26 AM, Ton Swieb wrote:
>
>         Hi,
>
>         Is there a docker image available for the 1.1.9.Final release?
>         I would expect it to find it here:
>         https://hub.docker.com/r/jboss/apiman-wildfly/
>         But 1.1.8.Final is the latest I can find there.
>
>         regards,
>
>         Ton
>
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>

From pavel.masloff at gmail.com  Sun Nov 29 01:40:44 2015
From: pavel.masloff at gmail.com (Pavel Maslov)
Date: Sun, 29 Nov 2015 07:40:44 +0100
Subject: [Apiman-user] Initial gateway config
Message-ID: <CAF9aV_pEEDK9V0cTy8ifrKcVmePXnDw4xc-rZoxgc6Y53fi4ZQ@mail.gmail.com>

Hi everyone,


What should be the initial gateway configuration?

I am trying with the following settings and I get the "Authentication to
the gateway failed" message:

Configuration Endpoint: http://localhost:8080/apiman-gateway-api/
username: apimanager
password: apimanager

Thanks!

Regards,
Pavel Maslov, MS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151129/a2c4b65c/attachment.html 

From marc.savy at redhat.com  Mon Nov 30 06:31:02 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 30 Nov 2015 11:31:02 +0000
Subject: [Apiman-user] Forwarding HTTP requests to service
 implementations secured by OAuth
In-Reply-To: <CAJJ5CnTihasxwwUcE07kKtiuvLw+LVZinSmsDFo8QPQGP+_VGw@mail.gmail.com>
References: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
	<564C931C.3060302@redhat.com>
	<CAJJ5CnTihasxwwUcE07kKtiuvLw+LVZinSmsDFo8QPQGP+_VGw@mail.gmail.com>
Message-ID: <565C3376.10407@redhat.com>

Hi Ton,

Sorry, I forgot to reply to this.

In essence, you are correct. There's no in-built mechanism to achieve
what you want (i.e. gateway acting as an OAuth2 *client*).

You could indeed use the simple header policy to store a long-lived
token, but this should not be considered a particularly secure approach
(particularly if there's a chance that the token could be exposed
somehow - e.g. by a user looking at the policy config in the UI).

The second issue, which you are undoubtedly aware of, is that there is
no mechanism to auto-refresh those token(s) once expired.

Another option which you could explore is to create a custom policy
which does the periodic refreshing of tokens for you.

Regards,
Marc

On 18/11/2015 15:11, Ton Swieb wrote:
> Hi Marc,
>
> That is correct.
>
> Regards,
>
> Ton
>
> 2015-11-18 16:02 GMT+01:00 Marc Savy <marc.savy at redhat.com
> <mailto:marc.savy at redhat.com>>:
>
>     Hi Ton,
>
>     Just to clarify. From what I understand, you're trying to secure
>     communications between the apiman gateway and back-end service using
>     OAuth2/OpenID Connect?
>
>     I.e. You are *not* OAuth2 simply between the client to the apiman
>     gateway.
>
>     Regards,
>     Marc
>
>     On 18/11/2015 14:34, Ton Swieb wrote:
>
>         Hi,
>
>         I am using Apiman 1.1.8.Final and I want to use a backend service in
>         Apiman which is secured by OAuth.
>         So instead of securing the Apiman side of the service, using the
>         Keycloak OAuth plugin, Apiman needs forward calls to a service
>         implementation that is secured by OAuth. I have got an OAuth
>         token with
>         a very long time to live (days/weeks/months) which I can use.
>
>         Currently I only see the option to configure BASIC Authentication or
>         MTLS/Two-Way-SSL on the service implementation.
>         Would it be possible to add the HTTP Simple Header policy to the
>         service
>         and set the Authorization header with "Bearer........." or will
>         that be
>         stripped off by Apiman when forwarding the call to the backend
>         service?
>
>         Kind regards,
>
>         Ton
>
>
>         _______________________________________________
>         Apiman-user mailing list
>         Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/apiman-user
>
>


From eric.wittmann at redhat.com  Mon Nov 30 08:33:47 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 30 Nov 2015 08:33:47 -0500
Subject: [Apiman-user] Forwarding HTTP requests to service
 implementations secured by OAuth
In-Reply-To: <565C3376.10407@redhat.com>
References: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
	<564C931C.3060302@redhat.com>
	<CAJJ5CnTihasxwwUcE07kKtiuvLw+LVZinSmsDFo8QPQGP+_VGw@mail.gmail.com>
	<565C3376.10407@redhat.com>
Message-ID: <565C503B.7020603@redhat.com>

Right - at this point a custom policy is probably the only reasonable 
approach.

I've added OAuth support between the Gateway and back-end API as a 
feature request here:

https://issues.jboss.org/browse/APIMAN-811

-Eric

On 11/30/2015 6:31 AM, Marc Savy wrote:
> Hi Ton,
>
> Sorry, I forgot to reply to this.
>
> In essence, you are correct. There's no in-built mechanism to achieve
> what you want (i.e. gateway acting as an OAuth2 *client*).
>
> You could indeed use the simple header policy to store a long-lived
> token, but this should not be considered a particularly secure approach
> (particularly if there's a chance that the token could be exposed
> somehow - e.g. by a user looking at the policy config in the UI).
>
> The second issue, which you are undoubtedly aware of, is that there is
> no mechanism to auto-refresh those token(s) once expired.
>
> Another option which you could explore is to create a custom policy
> which does the periodic refreshing of tokens for you.
>
> Regards,
> Marc
>
> On 18/11/2015 15:11, Ton Swieb wrote:
>> Hi Marc,
>>
>> That is correct.
>>
>> Regards,
>>
>> Ton
>>
>> 2015-11-18 16:02 GMT+01:00 Marc Savy <marc.savy at redhat.com
>> <mailto:marc.savy at redhat.com>>:
>>
>>      Hi Ton,
>>
>>      Just to clarify. From what I understand, you're trying to secure
>>      communications between the apiman gateway and back-end service using
>>      OAuth2/OpenID Connect?
>>
>>      I.e. You are *not* OAuth2 simply between the client to the apiman
>>      gateway.
>>
>>      Regards,
>>      Marc
>>
>>      On 18/11/2015 14:34, Ton Swieb wrote:
>>
>>          Hi,
>>
>>          I am using Apiman 1.1.8.Final and I want to use a backend service in
>>          Apiman which is secured by OAuth.
>>          So instead of securing the Apiman side of the service, using the
>>          Keycloak OAuth plugin, Apiman needs forward calls to a service
>>          implementation that is secured by OAuth. I have got an OAuth
>>          token with
>>          a very long time to live (days/weeks/months) which I can use.
>>
>>          Currently I only see the option to configure BASIC Authentication or
>>          MTLS/Two-Way-SSL on the service implementation.
>>          Would it be possible to add the HTTP Simple Header policy to the
>>          service
>>          and set the Authorization header with "Bearer........." or will
>>          that be
>>          stripped off by Apiman when forwarding the call to the backend
>>          service?
>>
>>          Kind regards,
>>
>>          Ton
>>
>>
>>          _______________________________________________
>>          Apiman-user mailing list
>>          Apiman-user at lists.jboss.org <mailto:Apiman-user at lists.jboss.org>
>>          https://lists.jboss.org/mailman/listinfo/apiman-user
>>
>>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From marc.savy at redhat.com  Mon Nov 30 08:37:50 2015
From: marc.savy at redhat.com (Marc Savy)
Date: Mon, 30 Nov 2015 13:37:50 +0000
Subject: [Apiman-user] Forwarding HTTP requests to service
 implementations secured by OAuth
In-Reply-To: <565C503B.7020603@redhat.com>
References: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
	<564C931C.3060302@redhat.com>
	<CAJJ5CnTihasxwwUcE07kKtiuvLw+LVZinSmsDFo8QPQGP+_VGw@mail.gmail.com>
	<565C3376.10407@redhat.com> <565C503B.7020603@redhat.com>
Message-ID: <565C512E.1010807@redhat.com>

I'll take any further stuff to the ticket - but, my understanding is that Server-To-Server OAuth2 isn't particularly recommended (Mutual TLS or similar is preferred).

That being said, I think you could argue we're just acting as a client by proxy, so perhaps it's okay.

On 30/11/2015 13:33, Eric Wittmann wrote:
> Right - at this point a custom policy is probably the only reasonable
> approach.
>
> I've added OAuth support between the Gateway and back-end API as a
> feature request here:
>
> https://issues.jboss.org/browse/APIMAN-811
>
> -Eric
>
> On 11/30/2015 6:31 AM, Marc Savy wrote:
> > Hi Ton,
> >
> > Sorry, I forgot to reply to this.
> >
> > In essence, you are correct. There's no in-built mechanism to achieve
> > what you want (i.e. gateway acting as an OAuth2 *client*).
> >
> > You could indeed use the simple header policy to store a long-lived
> > token, but this should not be considered a particularly secure approach
> > (particularly if there's a chance that the token could be exposed
> > somehow - e.g. by a user looking at the policy config in the UI).
> >
> > The second issue, which you are undoubtedly aware of, is that there is
> > no mechanism to auto-refresh those token(s) once expired.
> >
> > Another option which you could explore is to create a custom policy
> > which does the periodic refreshing of tokens for you.
> >
> > Regards,
> > Marc
> >
> > On 18/11/2015 15:11, Ton Swieb wrote:
> >> Hi Marc,
> >>
> >> That is correct.
> >>
> >> Regards,
> >>
> >> Ton
> >>
> >> 2015-11-18 16:02 GMT+01:00 Marc Savy <marc.savy at redhat.com
> >> <mailto:marc.savy at redhat.com>>:
> >>
> >>      Hi Ton,
> >>
> >>      Just to clarify. From what I understand, you're trying to secure
> >>      communications between the apiman gateway and back-end service
> >> using
> >>      OAuth2/OpenID Connect?
> >>
> >>      I.e. You are *not* OAuth2 simply between the client to the apiman
> >>      gateway.
> >>
> >>      Regards,
> >>      Marc
> >>
> >>      On 18/11/2015 14:34, Ton Swieb wrote:
> >>
> >>          Hi,
> >>
> >>          I am using Apiman 1.1.8.Final and I want to use a backend
> >> service in
> >>          Apiman which is secured by OAuth.
> >>          So instead of securing the Apiman side of the service, using
> >> the
> >>          Keycloak OAuth plugin, Apiman needs forward calls to a service
> >>          implementation that is secured by OAuth. I have got an OAuth
> >>          token with
> >>          a very long time to live (days/weeks/months) which I can use.
> >>
> >>          Currently I only see the option to configure BASIC
> >> Authentication or
> >>          MTLS/Two-Way-SSL on the service implementation.
> >>          Would it be possible to add the HTTP Simple Header policy to
> >> the
> >>          service
> >>          and set the Authorization header with "Bearer........." or will
> >>          that be
> >>          stripped off by Apiman when forwarding the call to the backend
> >>          service?
> >>
> >>          Kind regards,
> >>
> >>          Ton
> >>
> >>
> >>          _______________________________________________
> >>          Apiman-user mailing list
> >>          Apiman-user at lists.jboss.org
> >> <mailto:Apiman-user at lists.jboss.org>
> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
> >>
> >>
> >
> > _______________________________________________
> > Apiman-user mailing list
> > Apiman-user at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/apiman-user
> >


From eric.wittmann at redhat.com  Mon Nov 30 08:45:27 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 30 Nov 2015 08:45:27 -0500
Subject: [Apiman-user] Initial gateway config
In-Reply-To: <CAF9aV_pEEDK9V0cTy8ifrKcVmePXnDw4xc-rZoxgc6Y53fi4ZQ@mail.gmail.com>
References: <CAF9aV_pEEDK9V0cTy8ifrKcVmePXnDw4xc-rZoxgc6Y53fi4ZQ@mail.gmail.com>
Message-ID: <565C52F7.1090605@redhat.com>

I think this may have already been answered somewhere else (github 
issues) but I'll respond here as well for the benefit of all. :)

The API Gateway configuration API is protected by KeyCloak using the 
same Realm as the API Manager UI/REST.  However, the KeyCloak role 
needed is "apipublisher" which is unique to the API Gateway configuration.

So in other words, in order to call the API Gateway configuration API 
you must authenticate as a user with the 'apipublisher' role.  The 
quickstart comes pre-configured with a user named "apimanager" that has 
this role.  By default that user's password is:

apiman123!

I believe our documentation must be updated to reflect this fact.  If 
anyone can point me to where we have the old information (where the 
password is listed as something else) then I'd appreciate it.

Please note that you should definitely change this password in the 
quickstart.  To do this, log into KeyCloak here:

http://localhost:8080/auth
admin
admin123!

Then find the user in via the KC UI and modify the credentials.  You 
really should do this for the 'admin' user in both the Apiman and Master 
realms!

The quickstart comes pre-configured with these users as a convenience only.

-Eric

On 11/29/2015 1:40 AM, Pavel Maslov wrote:
> Hi everyone,
>
>
> What should be the initial gateway configuration?
>
> I am trying with the following settings and I get the "Authentication to
> the gateway failed" message:
>
> Configuration Endpoint: http://localhost:8080/apiman-gateway-api/
> username: apimanager
> password: apimanager
>
> Thanks!
>
> Regards,
> Pavel Maslov, MS
>
>
>
> _______________________________________________
> Apiman-user mailing list
> Apiman-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/apiman-user
>

From eric.wittmann at redhat.com  Mon Nov 30 09:25:08 2015
From: eric.wittmann at redhat.com (Eric Wittmann)
Date: Mon, 30 Nov 2015 09:25:08 -0500
Subject: [Apiman-user] Forwarding HTTP requests to service
 implementations secured by OAuth
In-Reply-To: <565C512E.1010807@redhat.com>
References: <CAJJ5CnS-i3gcSMz5WFw1+oFakwidnvQ4V4te4AUU83OVkgXVpg@mail.gmail.com>
	<564C931C.3060302@redhat.com>
	<CAJJ5CnTihasxwwUcE07kKtiuvLw+LVZinSmsDFo8QPQGP+_VGw@mail.gmail.com>
	<565C3376.10407@redhat.com> <565C503B.7020603@redhat.com>
	<565C512E.1010807@redhat.com>
Message-ID: <565C5C44.9010607@redhat.com>

Fair point.  Although BASIC Auth probably isn't recommended either. :)

On 11/30/2015 8:37 AM, Marc Savy wrote:
> I'll take any further stuff to the ticket - but, my understanding is
> that Server-To-Server OAuth2 isn't particularly recommended (Mutual TLS
> or similar is preferred).
>
> That being said, I think you could argue we're just acting as a client
> by proxy, so perhaps it's okay.
>
> On 30/11/2015 13:33, Eric Wittmann wrote:
>> Right - at this point a custom policy is probably the only reasonable
>> approach.
>>
>> I've added OAuth support between the Gateway and back-end API as a
>> feature request here:
>>
>> https://issues.jboss.org/browse/APIMAN-811
>>
>> -Eric
>>
>> On 11/30/2015 6:31 AM, Marc Savy wrote:
>> > Hi Ton,
>> >
>> > Sorry, I forgot to reply to this.
>> >
>> > In essence, you are correct. There's no in-built mechanism to achieve
>> > what you want (i.e. gateway acting as an OAuth2 *client*).
>> >
>> > You could indeed use the simple header policy to store a long-lived
>> > token, but this should not be considered a particularly secure approach
>> > (particularly if there's a chance that the token could be exposed
>> > somehow - e.g. by a user looking at the policy config in the UI).
>> >
>> > The second issue, which you are undoubtedly aware of, is that there is
>> > no mechanism to auto-refresh those token(s) once expired.
>> >
>> > Another option which you could explore is to create a custom policy
>> > which does the periodic refreshing of tokens for you.
>> >
>> > Regards,
>> > Marc
>> >
>> > On 18/11/2015 15:11, Ton Swieb wrote:
>> >> Hi Marc,
>> >>
>> >> That is correct.
>> >>
>> >> Regards,
>> >>
>> >> Ton
>> >>
>> >> 2015-11-18 16:02 GMT+01:00 Marc Savy <marc.savy at redhat.com
>> >> <mailto:marc.savy at redhat.com>>:
>> >>
>> >>      Hi Ton,
>> >>
>> >>      Just to clarify. From what I understand, you're trying to secure
>> >>      communications between the apiman gateway and back-end service
>> >> using
>> >>      OAuth2/OpenID Connect?
>> >>
>> >>      I.e. You are *not* OAuth2 simply between the client to the apiman
>> >>      gateway.
>> >>
>> >>      Regards,
>> >>      Marc
>> >>
>> >>      On 18/11/2015 14:34, Ton Swieb wrote:
>> >>
>> >>          Hi,
>> >>
>> >>          I am using Apiman 1.1.8.Final and I want to use a backend
>> >> service in
>> >>          Apiman which is secured by OAuth.
>> >>          So instead of securing the Apiman side of the service, using
>> >> the
>> >>          Keycloak OAuth plugin, Apiman needs forward calls to a
>> service
>> >>          implementation that is secured by OAuth. I have got an OAuth
>> >>          token with
>> >>          a very long time to live (days/weeks/months) which I can use.
>> >>
>> >>          Currently I only see the option to configure BASIC
>> >> Authentication or
>> >>          MTLS/Two-Way-SSL on the service implementation.
>> >>          Would it be possible to add the HTTP Simple Header policy to
>> >> the
>> >>          service
>> >>          and set the Authorization header with "Bearer........." or
>> will
>> >>          that be
>> >>          stripped off by Apiman when forwarding the call to the
>> backend
>> >>          service?
>> >>
>> >>          Kind regards,
>> >>
>> >>          Ton
>> >>
>> >>
>> >>          _______________________________________________
>> >>          Apiman-user mailing list
>> >>          Apiman-user at lists.jboss.org
>> >> <mailto:Apiman-user at lists.jboss.org>
>> >>          https://lists.jboss.org/mailman/listinfo/apiman-user
>> >>
>> >>
>> >
>> > _______________________________________________
>> > Apiman-user mailing list
>> > Apiman-user at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/apiman-user
>> >
>

From pblair at clearme.com  Mon Nov 30 10:59:43 2015
From: pblair at clearme.com (Paul Blair)
Date: Mon, 30 Nov 2015 15:59:43 +0000
Subject: [Apiman-user] Securing apiman admin resources and ports
In-Reply-To: <5654C4BA.6050303@redhat.com>
Message-ID: <D281DC3F.102B3%pblair@clearme.com>

Just as a follow-up to one thing, for the benefit of the list: I had read
that it's possible to secure the WildFly admin console in WildFly 9. This
turns out not to be the case; that functionality is now on hold. See
http://lists.jboss.org/pipermail/keycloak-user/2015-November/003833.html
for more discussion.

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