From tdudgeon.ml at gmail.com Sat Oct 3 07:00:07 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sat, 3 Oct 2015 12:00:07 +0100 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> <55B11A40.6090201@redhat.com> Message-ID: <560FB537.5060808@gmail.com> Arun, did you get anywhere creating a full dockerised apiman environment with all relevant parts (db, elasticsearch, keycloak, manager, gateway) as separate containers and a corresponding docker compose file? I'm trying to set this up, but suspecting that its already been done. Tim On 23/07/2015 17:57, Arun Gupta wrote: > Start/stop yes, but not if the container is removed. > > And because the "cost" associated with restarting a container is low, > restarting is more common that start/stop. > > Arun > > On Thu, Jul 23, 2015 at 10:45 AM, Eric Wittmann > wrote: >> Is that true? The state of the container is lost each time you stop it? I >> thought the EAP data directory was preserved across container start/stop, so >> that the state was preserved. But I guess I'm wrong? >> >> If it's true that state is *not* preserved, then the script can just blindly >> run I guess. >> >> -Eric >> >> On 7/23/2015 12:26 PM, Arun Gupta wrote: >>> That could work too! I was just trying to be comprehensive but YAGNI! >>> >>> Either way, as the state of the container is not preserved and a new >>> container is started every time, what is the likelihood that the >>> entity to be created will exist? >>> >>> Arun >>> >>> On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann >>> wrote: >>>> I'm not sure what you mean by this. I'm only suggesting that the >>>> "bootstrap" script could first do a GET on *one* of the entities that the >>>> script is planning on creating. If the entity already exists then the >>>> script can bail at that point. I don't see how a loop is possible. And >>>> I >>>> don't think you would need to check for *each* entity you plan on >>>> creating. >>>> Just use the first entity as a marker - if *that* one exists then assume >>>> the >>>> rest do as well. >>>> >>>> On 7/23/2015 11:15 AM, Arun Gupta wrote: >>>>> >>>>> If the container is started a fresh then it would not have any >>>>> existing resources, isn't it? >>>>> >>>>> Otherwise the script will get into a nested loop to first check for >>>>> organization, then service, then version, etc. >>>>> >>>>> Arun >>>>> >>>>> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >>>>> >>>>> wrote: >>>>>> >>>>>> I think it would be possible to have a run-once shell script. Either >>>>>> by >>>>>> writing/checking some sort of "already run" file. Or else by querying >>>>>> apiman to see if a particular entity exists. For example, query to see >>>>>> if >>>>>> "My-Custom-Organization" exists ... if it does then skip the script. >>>>>> If >>>>>> not, then run the multitude of curl commands to do what you want. >>>>>> >>>>>> -Eric >>>>>> >>>>>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>>>>> >>>>>>> >>>>>>> I've been thinking something on those lines. >>>>>>> >>>>>>> - Invoke shell script from Dockerfile >>>>>>> - Start API Man >>>>>>> - Run shell scripts >>>>>>> - Shut it down >>>>>>> - Go back to Dockerfile which will then start it >>>>>>> >>>>>>> Will share something, stay tuned. >>>>>>> >>>>>>> Arun >>>>>>> >>>>>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> You are probably more deft with docker than I am, but perhaps a shell >>>>>>>> script >>>>>>>> could be used to send a bunch of curl commands? >>>>>>>> >>>>>>>> -Eric >>>>>>>> >>>>>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> What is the recommended design pattern to extend the Dockerfile in >>>>>>>>> the >>>>>>>>> meanwhile? >>>>>>>>> >>>>>>>>> Arun >>>>>>>>> >>>>>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>>>>>> since it seems like a nice idea (especially for extending the >>>>>>>>>> docker >>>>>>>>>> container). >>>>>>>>>> >>>>>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>>>>> >>>>>>>>>> -Eric >>>>>>>>>> >>>>>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This indeed would be very useful. >>>>>>>>>>> Tim >>>>>>>>>>> >>>>>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I've created a Dockerfile [1] that will attempt to create >>>>>>>>>>>> different >>>>>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>>>>> .yml in a pre-defined directory and API Man will >>>>>>>>>>>> read >>>>>>>>>>>> the resources defined there and create them? >>>>>>>>>>>> >>>>>>>>>>>> This will simplify how the resources are created using Docker. >>>>>>>>>>>> The >>>>>>>>>>>> samples at [2] do not show that. >>>>>>>>>>>> >>>>>>>>>>>> [1] >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>>>>> >>>>>>>>>>>> Arun >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 tdudgeon.ml at gmail.com Thu Oct 8 07:00:29 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Thu, 8 Oct 2015 12:00:29 +0100 Subject: [Apiman-user] failure with postgres as db Message-ID: <56164CCD.2080006@gmail.com> I'm trying to deploy using postgres as the database, using instructions found here: http://www.apiman.io/latest/production-guide.html#_connecting_to_the_database I think I did things correctly, but I'm getting a failure to deploy the datasource as it can't find the postgres driver, even though it seems to have deployed OK. Here is the apiman-ds.xml: jdbc:postgresql://192.168.59.103:5432/apiman postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 30 apiman secret and this is what is deployed: [jboss at 5b39dce15d98 deployments]$ ls -l total 102664 -rw-r--r-- 1 jboss jboss 8869 Nov 21 2014 README.txt -rw-r--r-- 1 root root 542 Oct 8 10:09 apiman-ds.xml -rw-r--r-- 1 jboss jboss 219 Oct 8 10:17 apiman-ds.xml.failed -rwxr-xr-x 1 jboss jboss 19511221 Sep 10 11:28 apiman-es.war -rw-r--r-- 1 jboss jboss 13 Sep 10 11:28 apiman-es.war.deployed -rwxr-xr-x 1 jboss jboss 23949175 Sep 10 11:28 apiman-gateway-api.war -rw-r--r-- 1 jboss jboss 22 Sep 10 11:28 apiman-gateway-api.war.deployed -rwxr-xr-x 1 jboss jboss 22778008 Sep 10 11:28 apiman-gateway.war -rw-r--r-- 1 jboss jboss 18 Sep 10 11:28 apiman-gateway.war.deployed -rwxr-xr-x 1 jboss jboss 27389167 Sep 10 11:27 apiman.war -rw-r--r-- 1 jboss jboss 10 Sep 10 11:27 apiman.war.deployed -rwxr-xr-x 1 jboss jboss 10850509 Sep 10 11:27 apimanui.war -rw-r--r-- 1 jboss jboss 12 Sep 10 11:27 apimanui.war.deployed -rw-r--r-- 1 root root 592322 Oct 8 09:38 postgresql-9.3-1102-jdbc41.jar -rw-r--r-- 1 jboss jboss 30 Oct 8 09:38 postgresql-9.3-1102-jdbc41.jar.deployed [jboss at 5b39dce15d98 deployments]$ head apiman-ds.xml.failed "{\"JBAS014771: Services with missing/unavailable dependencies\" => [\"jboss.data-source.java:jboss/datasources/apiman-manager is missing [jboss.jdbc-driver.postgresql-9_3-1102_jdbc41_jar_org_postgresql_Driver_9_3]\"]}"[jboss at 5b39dce15d98 deployments]$ In the example found here: https://github.com/apiman/apiman/blob/master/distro/wildfly8/src/main/resources/overlay/apiman/sample-configs/apiman-ds_postgresql.xml the syntax is like this: postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 I think the . before jdbc41 should be a dash, like this: postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver_9_3 but that doesn't work. And there is no class named Driver_9_3 in the org.postgresql package, so I thought it could need to be: postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver but that doesn't work either. Any suggestions for what is needed here? Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151008/12073d6c/attachment.html From eric.wittmann at redhat.com Thu Oct 8 07:35:09 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 8 Oct 2015 07:35:09 -0400 Subject: [Apiman-user] failure with postgres as db In-Reply-To: <56164CCD.2080006@gmail.com> References: <56164CCD.2080006@gmail.com> Message-ID: <561654ED.6040000@redhat.com> I'll give this a try today with the latest released apiman and let you know what I discover. I mostly test using mysql, so it's easily possible that the documentation for postgresql is a bit out of date. -Eric On 10/8/2015 7:00 AM, Tim Dudgeon wrote: > I'm trying to deploy using postgres as the database, using instructions > found here: > http://www.apiman.io/latest/production-guide.html#_connecting_to_the_database > > I think I did things correctly, but I'm getting a failure to deploy the > datasource as it can't find the postgres driver, even though it seems to > have deployed OK. > Here is the apiman-ds.xml: > > > > pool-name="apiman-manager-api" enabled="true" use-java-context="true"> > jdbc:postgresql://192.168.59.103:5432/apiman > postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 > > 30 > > > apiman > secret > > > > > and this is what is deployed: > > [jboss at 5b39dce15d98 deployments]$ ls -l > total 102664 > -rw-r--r-- 1 jboss jboss 8869 Nov 21 2014 README.txt > -rw-r--r-- 1 root root 542 Oct 8 10:09 apiman-ds.xml > -rw-r--r-- 1 jboss jboss 219 Oct 8 10:17 apiman-ds.xml.failed > -rwxr-xr-x 1 jboss jboss 19511221 Sep 10 11:28 apiman-es.war > -rw-r--r-- 1 jboss jboss 13 Sep 10 11:28 apiman-es.war.deployed > -rwxr-xr-x 1 jboss jboss 23949175 Sep 10 11:28 apiman-gateway-api.war > -rw-r--r-- 1 jboss jboss 22 Sep 10 11:28 > apiman-gateway-api.war.deployed > -rwxr-xr-x 1 jboss jboss 22778008 Sep 10 11:28 apiman-gateway.war > -rw-r--r-- 1 jboss jboss 18 Sep 10 11:28 apiman-gateway.war.deployed > -rwxr-xr-x 1 jboss jboss 27389167 Sep 10 11:27 apiman.war > -rw-r--r-- 1 jboss jboss 10 Sep 10 11:27 apiman.war.deployed > -rwxr-xr-x 1 jboss jboss 10850509 Sep 10 11:27 apimanui.war > -rw-r--r-- 1 jboss jboss 12 Sep 10 11:27 apimanui.war.deployed > -rw-r--r-- 1 root root 592322 Oct 8 09:38 > postgresql-9.3-1102-jdbc41.jar > -rw-r--r-- 1 jboss jboss 30 Oct 8 09:38 > postgresql-9.3-1102-jdbc41.jar.deployed > [jboss at 5b39dce15d98 deployments]$ head apiman-ds.xml.failed > "{\"JBAS014771: Services with missing/unavailable dependencies\" => > [\"jboss.data-source.java:jboss/datasources/apiman-manager is missing > [jboss.jdbc-driver.postgresql-9_3-1102_jdbc41_jar_org_postgresql_Driver_9_3]\"]}"[jboss at 5b39dce15d98 > deployments]$ > > > In the example found here: > https://github.com/apiman/apiman/blob/master/distro/wildfly8/src/main/resources/overlay/apiman/sample-configs/apiman-ds_postgresql.xml > the syntax is like this: > > postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 > I think the . before jdbc41 should be a dash, like this: > postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver_9_3 > but that doesn't work. And there is no class named Driver_9_3 in the > org.postgresql package, so I thought it could need to be: > postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver > but that doesn't work either. > > Any suggestions for what is needed here? > > > Tim > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Thu Oct 8 08:17:42 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 8 Oct 2015 08:17:42 -0400 Subject: [Apiman-user] failure with postgres as db In-Reply-To: <56164CCD.2080006@gmail.com> References: <56164CCD.2080006@gmail.com> Message-ID: <56165EE6.2080903@redhat.com> Apparently you don't need the full driver name and version in the element. I was able to reproduce your result (the sample postgresql datasource file didn't work). I got it working by making the look like this: postgresql-9.3-1102-jdbc41.jar Could you give that a try and let me know how it goes? I can update the documentation and the sample config file if the above works OK for you. Thanks, Eric On 10/8/2015 7:00 AM, Tim Dudgeon wrote: > I'm trying to deploy using postgres as the database, using instructions > found here: > http://www.apiman.io/latest/production-guide.html#_connecting_to_the_database > > I think I did things correctly, but I'm getting a failure to deploy the > datasource as it can't find the postgres driver, even though it seems to > have deployed OK. > Here is the apiman-ds.xml: > > > > pool-name="apiman-manager-api" enabled="true" use-java-context="true"> > jdbc:postgresql://192.168.59.103:5432/apiman > postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 > > 30 > > > apiman > secret > > > > > and this is what is deployed: > > [jboss at 5b39dce15d98 deployments]$ ls -l > total 102664 > -rw-r--r-- 1 jboss jboss 8869 Nov 21 2014 README.txt > -rw-r--r-- 1 root root 542 Oct 8 10:09 apiman-ds.xml > -rw-r--r-- 1 jboss jboss 219 Oct 8 10:17 apiman-ds.xml.failed > -rwxr-xr-x 1 jboss jboss 19511221 Sep 10 11:28 apiman-es.war > -rw-r--r-- 1 jboss jboss 13 Sep 10 11:28 apiman-es.war.deployed > -rwxr-xr-x 1 jboss jboss 23949175 Sep 10 11:28 apiman-gateway-api.war > -rw-r--r-- 1 jboss jboss 22 Sep 10 11:28 > apiman-gateway-api.war.deployed > -rwxr-xr-x 1 jboss jboss 22778008 Sep 10 11:28 apiman-gateway.war > -rw-r--r-- 1 jboss jboss 18 Sep 10 11:28 apiman-gateway.war.deployed > -rwxr-xr-x 1 jboss jboss 27389167 Sep 10 11:27 apiman.war > -rw-r--r-- 1 jboss jboss 10 Sep 10 11:27 apiman.war.deployed > -rwxr-xr-x 1 jboss jboss 10850509 Sep 10 11:27 apimanui.war > -rw-r--r-- 1 jboss jboss 12 Sep 10 11:27 apimanui.war.deployed > -rw-r--r-- 1 root root 592322 Oct 8 09:38 > postgresql-9.3-1102-jdbc41.jar > -rw-r--r-- 1 jboss jboss 30 Oct 8 09:38 > postgresql-9.3-1102-jdbc41.jar.deployed > [jboss at 5b39dce15d98 deployments]$ head apiman-ds.xml.failed > "{\"JBAS014771: Services with missing/unavailable dependencies\" => > [\"jboss.data-source.java:jboss/datasources/apiman-manager is missing > [jboss.jdbc-driver.postgresql-9_3-1102_jdbc41_jar_org_postgresql_Driver_9_3]\"]}"[jboss at 5b39dce15d98 > deployments]$ > > > In the example found here: > https://github.com/apiman/apiman/blob/master/distro/wildfly8/src/main/resources/overlay/apiman/sample-configs/apiman-ds_postgresql.xml > the syntax is like this: > > postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 > I think the . before jdbc41 should be a dash, like this: > postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver_9_3 > but that doesn't work. And there is no class named Driver_9_3 in the > org.postgresql package, so I thought it could need to be: > postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver > but that doesn't work either. > > Any suggestions for what is needed here? > > > Tim > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Thu Oct 8 08:21:35 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 8 Oct 2015 08:21:35 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <560FB537.5060808@gmail.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> <55B11A40.6090201@redhat.com> <560FB537.5060808@gmail.com> Message-ID: <56165FCF.2010701@redhat.com> Hi Tim - I'm sorry to say that Arun has moved on from Red Hat, so I'm assuming he is no longer poking at apiman + docker: http://blog.arungupta.me/au-revoir-redhat/ If you continue with this effort, we'd love to have a look at your results. We currently have a production guide (which might help with your efforts): http://www.apiman.io/latest/production-guide.html But we'd love to have full dockerized versions of each component! -Eric On 10/3/2015 7:00 AM, Tim Dudgeon wrote: > Arun, > did you get anywhere creating a full dockerised apiman environment with > all relevant parts (db, elasticsearch, keycloak, manager, gateway) as > separate containers and a corresponding docker compose file? > I'm trying to set this up, but suspecting that its already been done. > > Tim > > > > On 23/07/2015 17:57, Arun Gupta wrote: >> Start/stop yes, but not if the container is removed. >> >> And because the "cost" associated with restarting a container is low, >> restarting is more common that start/stop. >> >> Arun >> >> On Thu, Jul 23, 2015 at 10:45 AM, Eric Wittmann >> wrote: >>> Is that true? The state of the container is lost each time you stop it? I >>> thought the EAP data directory was preserved across container start/stop, so >>> that the state was preserved. But I guess I'm wrong? >>> >>> If it's true that state is *not* preserved, then the script can just blindly >>> run I guess. >>> >>> -Eric >>> >>> On 7/23/2015 12:26 PM, Arun Gupta wrote: >>>> That could work too! I was just trying to be comprehensive but YAGNI! >>>> >>>> Either way, as the state of the container is not preserved and a new >>>> container is started every time, what is the likelihood that the >>>> entity to be created will exist? >>>> >>>> Arun >>>> >>>> On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann >>>> wrote: >>>>> I'm not sure what you mean by this. I'm only suggesting that the >>>>> "bootstrap" script could first do a GET on *one* of the entities that the >>>>> script is planning on creating. If the entity already exists then the >>>>> script can bail at that point. I don't see how a loop is possible. And >>>>> I >>>>> don't think you would need to check for *each* entity you plan on >>>>> creating. >>>>> Just use the first entity as a marker - if *that* one exists then assume >>>>> the >>>>> rest do as well. >>>>> >>>>> On 7/23/2015 11:15 AM, Arun Gupta wrote: >>>>>> >>>>>> If the container is started a fresh then it would not have any >>>>>> existing resources, isn't it? >>>>>> >>>>>> Otherwise the script will get into a nested loop to first check for >>>>>> organization, then service, then version, etc. >>>>>> >>>>>> Arun >>>>>> >>>>>> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >>>>>> >>>>>> wrote: >>>>>>> >>>>>>> I think it would be possible to have a run-once shell script. Either >>>>>>> by >>>>>>> writing/checking some sort of "already run" file. Or else by querying >>>>>>> apiman to see if a particular entity exists. For example, query to see >>>>>>> if >>>>>>> "My-Custom-Organization" exists ... if it does then skip the script. >>>>>>> If >>>>>>> not, then run the multitude of curl commands to do what you want. >>>>>>> >>>>>>> -Eric >>>>>>> >>>>>>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>>>>>> >>>>>>>> >>>>>>>> I've been thinking something on those lines. >>>>>>>> >>>>>>>> - Invoke shell script from Dockerfile >>>>>>>> - Start API Man >>>>>>>> - Run shell scripts >>>>>>>> - Shut it down >>>>>>>> - Go back to Dockerfile which will then start it >>>>>>>> >>>>>>>> Will share something, stay tuned. >>>>>>>> >>>>>>>> Arun >>>>>>>> >>>>>>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> You are probably more deft with docker than I am, but perhaps a shell >>>>>>>>> script >>>>>>>>> could be used to send a bunch of curl commands? >>>>>>>>> >>>>>>>>> -Eric >>>>>>>>> >>>>>>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> What is the recommended design pattern to extend the Dockerfile in >>>>>>>>>> the >>>>>>>>>> meanwhile? >>>>>>>>>> >>>>>>>>>> Arun >>>>>>>>>> >>>>>>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> That is not currently a feature. But I've now added a JIRA for it, >>>>>>>>>>> since it seems like a nice idea (especially for extending the >>>>>>>>>>> docker >>>>>>>>>>> container). >>>>>>>>>>> >>>>>>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>>>>>> >>>>>>>>>>> -Eric >>>>>>>>>>> >>>>>>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This indeed would be very useful. >>>>>>>>>>>> Tim >>>>>>>>>>>> >>>>>>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I've created a Dockerfile [1] that will attempt to create >>>>>>>>>>>>> different >>>>>>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>>>>>> .yml in a pre-defined directory and API Man will >>>>>>>>>>>>> read >>>>>>>>>>>>> the resources defined there and create them? >>>>>>>>>>>>> >>>>>>>>>>>>> This will simplify how the resources are created using Docker. >>>>>>>>>>>>> The >>>>>>>>>>>>> samples at [2] do not show that. >>>>>>>>>>>>> >>>>>>>>>>>>> [1] >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>>>>>> >>>>>>>>>>>>> Arun >>>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> 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 tdudgeon.ml at gmail.com Thu Oct 8 08:29:14 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Thu, 8 Oct 2015 13:29:14 +0100 Subject: [Apiman-user] failure with postgres as db In-Reply-To: <56165EE6.2080903@redhat.com> References: <56164CCD.2080006@gmail.com> <56165EE6.2080903@redhat.com> Message-ID: <5616619A.5040600@gmail.com> Thanks. That seem to have worked. Tim On 08/10/2015 13:17, Eric Wittmann wrote: > Apparently you don't need the full driver name and version in the > element. I was able to reproduce your result (the sample > postgresql datasource file didn't work). I got it working by making > the look like this: > > postgresql-9.3-1102-jdbc41.jar > > Could you give that a try and let me know how it goes? I can update > the documentation and the sample config file if the above works OK for > you. > > Thanks, > > Eric > > On 10/8/2015 7:00 AM, Tim Dudgeon wrote: >> I'm trying to deploy using postgres as the database, using instructions >> found here: >> http://www.apiman.io/latest/production-guide.html#_connecting_to_the_database >> >> >> I think I did things correctly, but I'm getting a failure to deploy the >> datasource as it can't find the postgres driver, even though it seems to >> have deployed OK. >> Here is the apiman-ds.xml: >> >> >> >> > pool-name="apiman-manager-api" enabled="true" use-java-context="true"> >> jdbc:postgresql://192.168.59.103:5432/apiman >> >> postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 >> >> >> 30 >> >> >> apiman >> secret >> >> >> >> >> and this is what is deployed: >> >> [jboss at 5b39dce15d98 deployments]$ ls -l >> total 102664 >> -rw-r--r-- 1 jboss jboss 8869 Nov 21 2014 README.txt >> -rw-r--r-- 1 root root 542 Oct 8 10:09 apiman-ds.xml >> -rw-r--r-- 1 jboss jboss 219 Oct 8 10:17 apiman-ds.xml.failed >> -rwxr-xr-x 1 jboss jboss 19511221 Sep 10 11:28 apiman-es.war >> -rw-r--r-- 1 jboss jboss 13 Sep 10 11:28 apiman-es.war.deployed >> -rwxr-xr-x 1 jboss jboss 23949175 Sep 10 11:28 apiman-gateway-api.war >> -rw-r--r-- 1 jboss jboss 22 Sep 10 11:28 >> apiman-gateway-api.war.deployed >> -rwxr-xr-x 1 jboss jboss 22778008 Sep 10 11:28 apiman-gateway.war >> -rw-r--r-- 1 jboss jboss 18 Sep 10 11:28 >> apiman-gateway.war.deployed >> -rwxr-xr-x 1 jboss jboss 27389167 Sep 10 11:27 apiman.war >> -rw-r--r-- 1 jboss jboss 10 Sep 10 11:27 apiman.war.deployed >> -rwxr-xr-x 1 jboss jboss 10850509 Sep 10 11:27 apimanui.war >> -rw-r--r-- 1 jboss jboss 12 Sep 10 11:27 apimanui.war.deployed >> -rw-r--r-- 1 root root 592322 Oct 8 09:38 >> postgresql-9.3-1102-jdbc41.jar >> -rw-r--r-- 1 jboss jboss 30 Oct 8 09:38 >> postgresql-9.3-1102-jdbc41.jar.deployed >> [jboss at 5b39dce15d98 deployments]$ head apiman-ds.xml.failed >> "{\"JBAS014771: Services with missing/unavailable dependencies\" => >> [\"jboss.data-source.java:jboss/datasources/apiman-manager is missing >> [jboss.jdbc-driver.postgresql-9_3-1102_jdbc41_jar_org_postgresql_Driver_9_3]\"]}"[jboss at 5b39dce15d98 >> >> deployments]$ >> >> >> In the example found here: >> https://github.com/apiman/apiman/blob/master/distro/wildfly8/src/main/resources/overlay/apiman/sample-configs/apiman-ds_postgresql.xml >> >> the syntax is like this: >> >> postgresql-9.3-1102.jdbc41.jar_org.postgresql.Driver_9_3 >> I think the . before jdbc41 should be a dash, like this: >> postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver_9_3 >> but that doesn't work. And there is no class named Driver_9_3 in the >> org.postgresql package, so I thought it could need to be: >> postgresql-9.3-1102-jdbc41.jar_org.postgresql.Driver >> but that doesn't work either. >> >> Any suggestions for what is needed here? >> >> >> Tim >> >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> From tdudgeon.ml at gmail.com Thu Oct 8 08:31:59 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Thu, 8 Oct 2015 13:31:59 +0100 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <56165FCF.2010701@redhat.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> <55B11A40.6090201@redhat.com> <560FB537.5060808@gmail.com> <56165FCF.2010701@redhat.com> Message-ID: <5616623F.2070202@gmail.com> Sad to hear Arun has left. yes, I've been making some progress on this. Hope to get a basic project into github soon. Still a lot more to do, and lots of bits I don't fully understand, so I'm sure I'll be back here soon for more help! Tim On 08/10/2015 13:21, Eric Wittmann wrote: > Hi Tim - I'm sorry to say that Arun has moved on from Red Hat, so I'm > assuming he is no longer poking at apiman + docker: > > http://blog.arungupta.me/au-revoir-redhat/ > > If you continue with this effort, we'd love to have a look at your > results. We currently have a production guide (which might help with > your efforts): > > http://www.apiman.io/latest/production-guide.html > > But we'd love to have full dockerized versions of each component! > > -Eric > > On 10/3/2015 7:00 AM, Tim Dudgeon wrote: >> Arun, >> did you get anywhere creating a full dockerised apiman environment with >> all relevant parts (db, elasticsearch, keycloak, manager, gateway) as >> separate containers and a corresponding docker compose file? >> I'm trying to set this up, but suspecting that its already been done. >> >> Tim >> >> >> >> On 23/07/2015 17:57, Arun Gupta wrote: >>> Start/stop yes, but not if the container is removed. >>> >>> And because the "cost" associated with restarting a container is low, >>> restarting is more common that start/stop. >>> >>> Arun >>> >>> On Thu, Jul 23, 2015 at 10:45 AM, Eric Wittmann >>> wrote: >>>> Is that true? The state of the container is lost each time you >>>> stop it? I >>>> thought the EAP data directory was preserved across container >>>> start/stop, so >>>> that the state was preserved. But I guess I'm wrong? >>>> >>>> If it's true that state is *not* preserved, then the script can >>>> just blindly >>>> run I guess. >>>> >>>> -Eric >>>> >>>> On 7/23/2015 12:26 PM, Arun Gupta wrote: >>>>> That could work too! I was just trying to be comprehensive but YAGNI! >>>>> >>>>> Either way, as the state of the container is not preserved and a new >>>>> container is started every time, what is the likelihood that the >>>>> entity to be created will exist? >>>>> >>>>> Arun >>>>> >>>>> On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann >>>>> >>>>> wrote: >>>>>> I'm not sure what you mean by this. I'm only suggesting that the >>>>>> "bootstrap" script could first do a GET on *one* of the entities >>>>>> that the >>>>>> script is planning on creating. If the entity already exists >>>>>> then the >>>>>> script can bail at that point. I don't see how a loop is >>>>>> possible. And >>>>>> I >>>>>> don't think you would need to check for *each* entity you plan on >>>>>> creating. >>>>>> Just use the first entity as a marker - if *that* one exists then >>>>>> assume >>>>>> the >>>>>> rest do as well. >>>>>> >>>>>> On 7/23/2015 11:15 AM, Arun Gupta wrote: >>>>>>> >>>>>>> If the container is started a fresh then it would not have any >>>>>>> existing resources, isn't it? >>>>>>> >>>>>>> Otherwise the script will get into a nested loop to first check for >>>>>>> organization, then service, then version, etc. >>>>>>> >>>>>>> Arun >>>>>>> >>>>>>> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >>>>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> I think it would be possible to have a run-once shell script. >>>>>>>> Either >>>>>>>> by >>>>>>>> writing/checking some sort of "already run" file. Or else by >>>>>>>> querying >>>>>>>> apiman to see if a particular entity exists. For example, >>>>>>>> query to see >>>>>>>> if >>>>>>>> "My-Custom-Organization" exists ... if it does then skip the >>>>>>>> script. >>>>>>>> If >>>>>>>> not, then run the multitude of curl commands to do what you want. >>>>>>>> >>>>>>>> -Eric >>>>>>>> >>>>>>>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> I've been thinking something on those lines. >>>>>>>>> >>>>>>>>> - Invoke shell script from Dockerfile >>>>>>>>> - Start API Man >>>>>>>>> - Run shell scripts >>>>>>>>> - Shut it down >>>>>>>>> - Go back to Dockerfile which will then start it >>>>>>>>> >>>>>>>>> Will share something, stay tuned. >>>>>>>>> >>>>>>>>> Arun >>>>>>>>> >>>>>>>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>>>>>>> >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> You are probably more deft with docker than I am, but perhaps >>>>>>>>>> a shell >>>>>>>>>> script >>>>>>>>>> could be used to send a bunch of curl commands? >>>>>>>>>> >>>>>>>>>> -Eric >>>>>>>>>> >>>>>>>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> What is the recommended design pattern to extend the >>>>>>>>>>> Dockerfile in >>>>>>>>>>> the >>>>>>>>>>> meanwhile? >>>>>>>>>>> >>>>>>>>>>> Arun >>>>>>>>>>> >>>>>>>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>>>>>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> That is not currently a feature. But I've now added a JIRA >>>>>>>>>>>> for it, >>>>>>>>>>>> since it seems like a nice idea (especially for extending the >>>>>>>>>>>> docker >>>>>>>>>>>> container). >>>>>>>>>>>> >>>>>>>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>>>>>>> >>>>>>>>>>>> -Eric >>>>>>>>>>>> >>>>>>>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This indeed would be very useful. >>>>>>>>>>>>> Tim >>>>>>>>>>>>> >>>>>>>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I've created a Dockerfile [1] that will attempt to create >>>>>>>>>>>>>> different >>>>>>>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>>>>>>> .yml in a pre-defined directory and API Man >>>>>>>>>>>>>> will >>>>>>>>>>>>>> read >>>>>>>>>>>>>> the resources defined there and create them? >>>>>>>>>>>>>> >>>>>>>>>>>>>> This will simplify how the resources are created using >>>>>>>>>>>>>> Docker. >>>>>>>>>>>>>> The >>>>>>>>>>>>>> samples at [2] do not show that. >>>>>>>>>>>>>> >>>>>>>>>>>>>> [1] >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>>>>>>> >>>>>>>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Arun >>>>>>>>>>>>>> >>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> 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 eric.wittmann at redhat.com Thu Oct 8 08:46:34 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 8 Oct 2015 08:46:34 -0400 Subject: [Apiman-user] Creating resources using Docker image In-Reply-To: <5616623F.2070202@gmail.com> References: <55B09C1F.4090300@gmail.com> <55B0D0C3.9060603@redhat.com> <55B0D3C9.3030400@redhat.com> <55B0ED51.2050804@redhat.com> <55B10F5C.8050204@redhat.com> <55B11A40.6090201@redhat.com> <560FB537.5060808@gmail.com> <56165FCF.2010701@redhat.com> <5616623F.2070202@gmail.com> Message-ID: <561665AA.30503@redhat.com> Always happy to help. Good luck. -Eric On 10/8/2015 8:31 AM, Tim Dudgeon wrote: > Sad to hear Arun has left. > > yes, I've been making some progress on this. Hope to get a basic project > into github soon. > Still a lot more to do, and lots of bits I don't fully understand, so > I'm sure I'll be back here soon for more help! > > Tim > > On 08/10/2015 13:21, Eric Wittmann wrote: >> Hi Tim - I'm sorry to say that Arun has moved on from Red Hat, so I'm >> assuming he is no longer poking at apiman + docker: >> >> http://blog.arungupta.me/au-revoir-redhat/ >> >> If you continue with this effort, we'd love to have a look at your >> results. We currently have a production guide (which might help with >> your efforts): >> >> http://www.apiman.io/latest/production-guide.html >> >> But we'd love to have full dockerized versions of each component! >> >> -Eric >> >> On 10/3/2015 7:00 AM, Tim Dudgeon wrote: >>> Arun, >>> did you get anywhere creating a full dockerised apiman environment with >>> all relevant parts (db, elasticsearch, keycloak, manager, gateway) as >>> separate containers and a corresponding docker compose file? >>> I'm trying to set this up, but suspecting that its already been done. >>> >>> Tim >>> >>> >>> >>> On 23/07/2015 17:57, Arun Gupta wrote: >>>> Start/stop yes, but not if the container is removed. >>>> >>>> And because the "cost" associated with restarting a container is low, >>>> restarting is more common that start/stop. >>>> >>>> Arun >>>> >>>> On Thu, Jul 23, 2015 at 10:45 AM, Eric Wittmann >>>> wrote: >>>>> Is that true? The state of the container is lost each time you >>>>> stop it? I >>>>> thought the EAP data directory was preserved across container >>>>> start/stop, so >>>>> that the state was preserved. But I guess I'm wrong? >>>>> >>>>> If it's true that state is *not* preserved, then the script can >>>>> just blindly >>>>> run I guess. >>>>> >>>>> -Eric >>>>> >>>>> On 7/23/2015 12:26 PM, Arun Gupta wrote: >>>>>> That could work too! I was just trying to be comprehensive but YAGNI! >>>>>> >>>>>> Either way, as the state of the container is not preserved and a new >>>>>> container is started every time, what is the likelihood that the >>>>>> entity to be created will exist? >>>>>> >>>>>> Arun >>>>>> >>>>>> On Thu, Jul 23, 2015 at 9:59 AM, Eric Wittmann >>>>>> >>>>>> wrote: >>>>>>> I'm not sure what you mean by this. I'm only suggesting that the >>>>>>> "bootstrap" script could first do a GET on *one* of the entities >>>>>>> that the >>>>>>> script is planning on creating. If the entity already exists >>>>>>> then the >>>>>>> script can bail at that point. I don't see how a loop is >>>>>>> possible. And >>>>>>> I >>>>>>> don't think you would need to check for *each* entity you plan on >>>>>>> creating. >>>>>>> Just use the first entity as a marker - if *that* one exists then >>>>>>> assume >>>>>>> the >>>>>>> rest do as well. >>>>>>> >>>>>>> On 7/23/2015 11:15 AM, Arun Gupta wrote: >>>>>>>> >>>>>>>> If the container is started a fresh then it would not have any >>>>>>>> existing resources, isn't it? >>>>>>>> >>>>>>>> Otherwise the script will get into a nested loop to first check for >>>>>>>> organization, then service, then version, etc. >>>>>>>> >>>>>>>> Arun >>>>>>>> >>>>>>>> On Thu, Jul 23, 2015 at 7:34 AM, Eric Wittmann >>>>>>>> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I think it would be possible to have a run-once shell script. >>>>>>>>> Either >>>>>>>>> by >>>>>>>>> writing/checking some sort of "already run" file. Or else by >>>>>>>>> querying >>>>>>>>> apiman to see if a particular entity exists. For example, >>>>>>>>> query to see >>>>>>>>> if >>>>>>>>> "My-Custom-Organization" exists ... if it does then skip the >>>>>>>>> script. >>>>>>>>> If >>>>>>>>> not, then run the multitude of curl commands to do what you want. >>>>>>>>> >>>>>>>>> -Eric >>>>>>>>> >>>>>>>>> On 7/23/2015 7:48 AM, Arun Gupta wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I've been thinking something on those lines. >>>>>>>>>> >>>>>>>>>> - Invoke shell script from Dockerfile >>>>>>>>>> - Start API Man >>>>>>>>>> - Run shell scripts >>>>>>>>>> - Shut it down >>>>>>>>>> - Go back to Dockerfile which will then start it >>>>>>>>>> >>>>>>>>>> Will share something, stay tuned. >>>>>>>>>> >>>>>>>>>> Arun >>>>>>>>>> >>>>>>>>>> On Thu, Jul 23, 2015 at 5:45 AM, Eric Wittmann >>>>>>>>>> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> You are probably more deft with docker than I am, but perhaps >>>>>>>>>>> a shell >>>>>>>>>>> script >>>>>>>>>>> could be used to send a bunch of curl commands? >>>>>>>>>>> >>>>>>>>>>> -Eric >>>>>>>>>>> >>>>>>>>>>> On 7/23/2015 7:35 AM, Arun Gupta wrote: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> What is the recommended design pattern to extend the >>>>>>>>>>>> Dockerfile in >>>>>>>>>>>> the >>>>>>>>>>>> meanwhile? >>>>>>>>>>>> >>>>>>>>>>>> Arun >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jul 23, 2015 at 5:32 AM, Eric Wittmann >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> That is not currently a feature. But I've now added a JIRA >>>>>>>>>>>>> for it, >>>>>>>>>>>>> since it seems like a nice idea (especially for extending the >>>>>>>>>>>>> docker >>>>>>>>>>>>> container). >>>>>>>>>>>>> >>>>>>>>>>>>> https://issues.jboss.org/browse/APIMAN-566 >>>>>>>>>>>>> >>>>>>>>>>>>> -Eric >>>>>>>>>>>>> >>>>>>>>>>>>> On 7/23/2015 3:47 AM, Tim Dudgeon wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> This indeed would be very useful. >>>>>>>>>>>>>> Tim >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 23/07/2015 04:44, Arun Gupta wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I've created a Dockerfile [1] that will attempt to create >>>>>>>>>>>>>>> different >>>>>>>>>>>>>>> resources. Is there any standard format where I can drop >>>>>>>>>>>>>>> .yml in a pre-defined directory and API Man >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> read >>>>>>>>>>>>>>> the resources defined there and create them? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This will simplify how the resources are created using >>>>>>>>>>>>>>> Docker. >>>>>>>>>>>>>>> The >>>>>>>>>>>>>>> samples at [2] do not show that. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [1] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/arun-gupta/microservices/blob/master/microservice/docker/Dockerfile >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [2] https://registry.hub.docker.com/u/jboss/apiman-wildfly/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Arun >>>>>>>>>>>>>>> >>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>> 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 >>> > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Fri Oct 9 10:03:04 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Fri, 9 Oct 2015 15:03:04 +0100 Subject: [Apiman-user] production guide error Message-ID: <5617C918.2010608@gmail.com> Hi All I think I found an error in the production guide section for Setting the API Gateway Public Endpoint http://www.apiman.io/latest/production-guide.html#_setting_the_api_gateway_public_endpoint where it states: apiman-gateway.public-endpoint=https://api-gateway-host.org:8443/api-gateway/ it should be: apiman-gateway.public-endpoint=https://api-gateway-host.org:8443/apiman-gateway/ And on a related topic, is it possible to define the configuration endpoint for the gateway in the apiman.properties file rather than through the UI (the property that has the default value of https://localhost:8443/apiman-gateway-api). Thanks Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151009/ed58e8da/attachment.html From eric.wittmann at redhat.com Fri Oct 9 11:15:20 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 9 Oct 2015 11:15:20 -0400 Subject: [Apiman-user] production guide error In-Reply-To: <5617C918.2010608@gmail.com> References: <5617C918.2010608@gmail.com> Message-ID: <5617DA08.90507@redhat.com> Thanks for the correction to the production guide. I'll get that updated. As for the configuration endpoint. The UI lets you *connect* the manager to one or more Gateway via the gateway's configuration endpoint. The UI (or the Manager REST services) must be used to manage the gateway connections. If you wanted to change the *actual* endpoints the gateway is using, you would need to make changes to the gateway WARs themselves. But if you're asking how to automate the configuration of the link between the manager and the gateway, you would need to use the manager's REST API to modify the value during some sort of bootstrapping phase. -Eric On 10/9/2015 10:03 AM, Tim Dudgeon wrote: > Hi All > > I think I found an error in the production guide section for Setting the > API Gateway Public Endpoint > http://www.apiman.io/latest/production-guide.html#_setting_the_api_gateway_public_endpoint > where it states: > apiman-gateway.public-endpoint=https://api-gateway-host.org:8443/api-gateway/ > it should be: > apiman-gateway.public-endpoint=https://api-gateway-host.org:8443/apiman-gateway/ > > > And on a related topic, is it possible to define the configuration > endpoint for the gateway in the apiman.properties file rather than > through the UI (the property that has the default value of > https://localhost:8443/apiman-gateway-api). > > Thanks > Tim > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Fri Oct 9 11:35:49 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Fri, 9 Oct 2015 16:35:49 +0100 Subject: [Apiman-user] production guide error In-Reply-To: <5617DA08.90507@redhat.com> References: <5617C918.2010608@gmail.com> <5617DA08.90507@redhat.com> Message-ID: <5617DED5.4010101@gmail.com> Yes, I'm wanting to set up a automated build/deploy environment and wanting to avoid needing to manually change this setting in the UI. Using the REST API should be feasible. On 09/10/2015 16:15, Eric Wittmann wrote: > Thanks for the correction to the production guide. I'll get that > updated. > > As for the configuration endpoint. The UI lets you *connect* the > manager to one or more Gateway via the gateway's configuration > endpoint. The UI (or the Manager REST services) must be used to > manage the gateway connections. > > If you wanted to change the *actual* endpoints the gateway is using, > you would need to make changes to the gateway WARs themselves. > > But if you're asking how to automate the configuration of the link > between the manager and the gateway, you would need to use the > manager's REST API to modify the value during some sort of > bootstrapping phase. > > -Eric > > On 10/9/2015 10:03 AM, Tim Dudgeon wrote: >> Hi All >> >> I think I found an error in the production guide section for Setting the >> API Gateway Public Endpoint >> http://www.apiman.io/latest/production-guide.html#_setting_the_api_gateway_public_endpoint >> >> where it states: >> apiman-gateway.public-endpoint=https://api-gateway-host.org:8443/api-gateway/ >> >> it should be: >> apiman-gateway.public-endpoint=https://api-gateway-host.org:8443/apiman-gateway/ >> >> >> >> And on a related topic, is it possible to define the configuration >> endpoint for the gateway in the apiman.properties file rather than >> through the UI (the property that has the default value of >> https://localhost:8443/apiman-gateway-api). >> >> Thanks >> Tim >> >> >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> From tdudgeon.ml at gmail.com Fri Oct 9 13:10:17 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Fri, 9 Oct 2015 18:10:17 +0100 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <55B0ED64.2020505@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> Message-ID: <5617F4F9.6080800@gmail.com> Picking up on this again, you mentioned OAuth2 authentication. By this I'm assuming you mean what's listed as "Authorization policy" in the available policies, and this authenticates against the apiman realm in keycloak. Is it possible/desirable to allow a different realm to be configured here? The idea being that an organisation could create a policy that authenticates against a realm configured for that organisation (maybe using its own LDAP server etc.). This way an organisation can configure usage for all its users without them needing to be apiman users? Tim On 23/07/2015 14:34, Eric Wittmann wrote: > +1 thanks. > > On 7/23/2015 9:13 AM, Tim Dudgeon wrote: >> No further comments so I created an issue for this: >> https://issues.jboss.org/browse/APIMAN-569 >> >> On 20/07/2015 10:09, Eric Wittmann wrote: >>> Hi Tim. >>> >>> Interesting scenario. The typical scenario is that the apiman UI is >>> only used by service providers and application developers. End users >>> will typically not use the apiman UI. However, that doesn't mean >>> apiman can't track end users. If authentication is enabled (either >>> BASIC or OAuth2), then rate limiting can be configured on a per-user >>> basis. When you configure the rate limit policy, you can choose >>> "user" as an option and then provide the HTTP header containing the >>> user. When configuring the authentication policy (which must come >>> first in the policy chain) you would need to enable forwarding of the >>> username. >>> >>> In addition, the next version of apiman will also include the >>> authenticated user in the metrics data. This would allow you to query >>> the elasticsearch metrics information by username. We won't have any >>> specific support in the UI for breaking down metrics by user, at least >>> not right away, but it will be in the data at least. >>> >>> Of course, you *can* use apiman the way you are suggesting. But as >>> you observed there are some challenges. We don't currently have a way >>> to assign roles to users automatically when they register. It would >>> need to be a feature request I think: >>> >>> https://issues.jboss.org/browse/APIMAN >>> >>> I think if we added a very generic "user registration" extension point >>> to apiman, then you could write your own custom handler to do whatever >>> you want. Such a handler would be invoked the first time a new user >>> logged into apiman. You could drive off their email address, roles, >>> whatever. You could also provide a handler via a plugin. >>> >>> Thoughts? :) >>> >>> -Eric >>> >>> >>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>>> Hi >>>> >>>> I've been looking into apiman and like what I see, but have a >>>> conceptual >>>> question about its usage. >>>> I need something to manage the end users of my applications, not just >>>> the people who are developing and managing those applications. Is >>>> apiman >>>> suitable for this? e.g. each actual user of the applications would >>>> register to apiman and use their own access keys. I need this as I >>>> will >>>> want to handle metrics and usage on the level of the individual user. >>>> >>>> Also, if this was to be a sensible approach how does one configure the >>>> registration process. I understand apiman is using keycloak for this, >>>> but I see no link in the UI to configure keycloak. And I would need a >>>> way that new users could automatically be assigned to an organisation >>>> (e.g. a default organisation, or a specific one based on their email >>>> address). >>>> >>>> Tim >>>> _______________________________________________ >>>> 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 eric.wittmann at redhat.com Fri Oct 9 13:56:15 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 9 Oct 2015 13:56:15 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <5617F4F9.6080800@gmail.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> Message-ID: <5617FFBF.2090006@redhat.com> I would argue that using some *other* realm (NOT the apiman realm) is the more sensible thing to do. In fact, I might go so far as to suggest a second keycloak server would make more logical sense than using the apiman one. Of course, practically speaking it makes sense to just have one KC server. But definitely I think you want to create other realms - and one realm per organization is a very sensible approach. -Eric On 10/9/2015 1:10 PM, Tim Dudgeon wrote: > Picking up on this again, you mentioned OAuth2 authentication. > By this I'm assuming you mean what's listed as "Authorization policy" in > the available policies, and this authenticates against the apiman realm > in keycloak. > > Is it possible/desirable to allow a different realm to be configured > here? The idea being that an organisation could create a policy that > authenticates against a realm configured for that organisation (maybe > using its own LDAP server etc.). This way an organisation can configure > usage for all its users without them needing to be apiman users? > > Tim > > On 23/07/2015 14:34, Eric Wittmann wrote: >> +1 thanks. >> >> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: >>> No further comments so I created an issue for this: >>> https://issues.jboss.org/browse/APIMAN-569 >>> >>> On 20/07/2015 10:09, Eric Wittmann wrote: >>>> Hi Tim. >>>> >>>> Interesting scenario. The typical scenario is that the apiman UI is >>>> only used by service providers and application developers. End users >>>> will typically not use the apiman UI. However, that doesn't mean >>>> apiman can't track end users. If authentication is enabled (either >>>> BASIC or OAuth2), then rate limiting can be configured on a per-user >>>> basis. When you configure the rate limit policy, you can choose >>>> "user" as an option and then provide the HTTP header containing the >>>> user. When configuring the authentication policy (which must come >>>> first in the policy chain) you would need to enable forwarding of the >>>> username. >>>> >>>> In addition, the next version of apiman will also include the >>>> authenticated user in the metrics data. This would allow you to query >>>> the elasticsearch metrics information by username. We won't have any >>>> specific support in the UI for breaking down metrics by user, at least >>>> not right away, but it will be in the data at least. >>>> >>>> Of course, you *can* use apiman the way you are suggesting. But as >>>> you observed there are some challenges. We don't currently have a way >>>> to assign roles to users automatically when they register. It would >>>> need to be a feature request I think: >>>> >>>> https://issues.jboss.org/browse/APIMAN >>>> >>>> I think if we added a very generic "user registration" extension point >>>> to apiman, then you could write your own custom handler to do whatever >>>> you want. Such a handler would be invoked the first time a new user >>>> logged into apiman. You could drive off their email address, roles, >>>> whatever. You could also provide a handler via a plugin. >>>> >>>> Thoughts? :) >>>> >>>> -Eric >>>> >>>> >>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>>>> Hi >>>>> >>>>> I've been looking into apiman and like what I see, but have a >>>>> conceptual >>>>> question about its usage. >>>>> I need something to manage the end users of my applications, not just >>>>> the people who are developing and managing those applications. Is >>>>> apiman >>>>> suitable for this? e.g. each actual user of the applications would >>>>> register to apiman and use their own access keys. I need this as I >>>>> will >>>>> want to handle metrics and usage on the level of the individual user. >>>>> >>>>> Also, if this was to be a sensible approach how does one configure the >>>>> registration process. I understand apiman is using keycloak for this, >>>>> but I see no link in the UI to configure keycloak. And I would need a >>>>> way that new users could automatically be assigned to an organisation >>>>> (e.g. a default organisation, or a specific one based on their email >>>>> address). >>>>> >>>>> Tim >>>>> _______________________________________________ >>>>> 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 tdudgeon.ml at gmail.com Fri Oct 9 14:01:00 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Fri, 9 Oct 2015 19:01:00 +0100 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <5617FFBF.2090006@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> Message-ID: <561800DC.6070206@gmail.com> Yes, but I don't see how a different realm/server this can be configured with the current Authorization policy. Is this possible? Tim On 09/10/2015 18:56, Eric Wittmann wrote: > I would argue that using some *other* realm (NOT the apiman realm) is > the more sensible thing to do. > > In fact, I might go so far as to suggest a second keycloak server > would make more logical sense than using the apiman one. Of course, > practically speaking it makes sense to just have one KC server. But > definitely I think you want to create other realms - and one realm per > organization is a very sensible approach. > > -Eric > > On 10/9/2015 1:10 PM, Tim Dudgeon wrote: >> Picking up on this again, you mentioned OAuth2 authentication. >> By this I'm assuming you mean what's listed as "Authorization policy" in >> the available policies, and this authenticates against the apiman realm >> in keycloak. >> >> Is it possible/desirable to allow a different realm to be configured >> here? The idea being that an organisation could create a policy that >> authenticates against a realm configured for that organisation (maybe >> using its own LDAP server etc.). This way an organisation can configure >> usage for all its users without them needing to be apiman users? >> >> Tim >> >> On 23/07/2015 14:34, Eric Wittmann wrote: >>> +1 thanks. >>> >>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: >>>> No further comments so I created an issue for this: >>>> https://issues.jboss.org/browse/APIMAN-569 >>>> >>>> On 20/07/2015 10:09, Eric Wittmann wrote: >>>>> Hi Tim. >>>>> >>>>> Interesting scenario. The typical scenario is that the apiman UI is >>>>> only used by service providers and application developers. End users >>>>> will typically not use the apiman UI. However, that doesn't mean >>>>> apiman can't track end users. If authentication is enabled (either >>>>> BASIC or OAuth2), then rate limiting can be configured on a per-user >>>>> basis. When you configure the rate limit policy, you can choose >>>>> "user" as an option and then provide the HTTP header containing the >>>>> user. When configuring the authentication policy (which must come >>>>> first in the policy chain) you would need to enable forwarding of the >>>>> username. >>>>> >>>>> In addition, the next version of apiman will also include the >>>>> authenticated user in the metrics data. This would allow you to >>>>> query >>>>> the elasticsearch metrics information by username. We won't have any >>>>> specific support in the UI for breaking down metrics by user, at >>>>> least >>>>> not right away, but it will be in the data at least. >>>>> >>>>> Of course, you *can* use apiman the way you are suggesting. But as >>>>> you observed there are some challenges. We don't currently have a >>>>> way >>>>> to assign roles to users automatically when they register. It would >>>>> need to be a feature request I think: >>>>> >>>>> https://issues.jboss.org/browse/APIMAN >>>>> >>>>> I think if we added a very generic "user registration" extension >>>>> point >>>>> to apiman, then you could write your own custom handler to do >>>>> whatever >>>>> you want. Such a handler would be invoked the first time a new user >>>>> logged into apiman. You could drive off their email address, roles, >>>>> whatever. You could also provide a handler via a plugin. >>>>> >>>>> Thoughts? :) >>>>> >>>>> -Eric >>>>> >>>>> >>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>>>>> Hi >>>>>> >>>>>> I've been looking into apiman and like what I see, but have a >>>>>> conceptual >>>>>> question about its usage. >>>>>> I need something to manage the end users of my applications, not >>>>>> just >>>>>> the people who are developing and managing those applications. Is >>>>>> apiman >>>>>> suitable for this? e.g. each actual user of the applications would >>>>>> register to apiman and use their own access keys. I need this as I >>>>>> will >>>>>> want to handle metrics and usage on the level of the individual >>>>>> user. >>>>>> >>>>>> Also, if this was to be a sensible approach how does one >>>>>> configure the >>>>>> registration process. I understand apiman is using keycloak for >>>>>> this, >>>>>> but I see no link in the UI to configure keycloak. And I would >>>>>> need a >>>>>> way that new users could automatically be assigned to an >>>>>> organisation >>>>>> (e.g. a default organisation, or a specific one based on their email >>>>>> address). >>>>>> >>>>>> Tim >>>>>> _______________________________________________ >>>>>> 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 eric.wittmann at redhat.com Fri Oct 9 14:11:31 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 9 Oct 2015 14:11:31 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <561800DC.6070206@gmail.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> <561800DC.6070206@gmail.com> Message-ID: <56180353.6090801@redhat.com> Perhaps you are looking at the wrong policy. The one you want to use is the Keycloak OAuth Policy, which is available if you install the appropriate keycloak plugin. A blog post about it can be found here: http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html The Authorization policy only does role-based access control, not OAuth authentication. The Keycloak OAuth policy should be configured first, and then the roles found in the bearer token will get passed to the Authorization policy, which should be configured 2nd. -Eric On 10/9/2015 2:01 PM, Tim Dudgeon wrote: > Yes, but I don't see how a different realm/server this can be configured > with the current Authorization policy. > Is this possible? > > Tim > > On 09/10/2015 18:56, Eric Wittmann wrote: >> I would argue that using some *other* realm (NOT the apiman realm) is >> the more sensible thing to do. >> >> In fact, I might go so far as to suggest a second keycloak server >> would make more logical sense than using the apiman one. Of course, >> practically speaking it makes sense to just have one KC server. But >> definitely I think you want to create other realms - and one realm per >> organization is a very sensible approach. >> >> -Eric >> >> On 10/9/2015 1:10 PM, Tim Dudgeon wrote: >>> Picking up on this again, you mentioned OAuth2 authentication. >>> By this I'm assuming you mean what's listed as "Authorization policy" in >>> the available policies, and this authenticates against the apiman realm >>> in keycloak. >>> >>> Is it possible/desirable to allow a different realm to be configured >>> here? The idea being that an organisation could create a policy that >>> authenticates against a realm configured for that organisation (maybe >>> using its own LDAP server etc.). This way an organisation can configure >>> usage for all its users without them needing to be apiman users? >>> >>> Tim >>> >>> On 23/07/2015 14:34, Eric Wittmann wrote: >>>> +1 thanks. >>>> >>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: >>>>> No further comments so I created an issue for this: >>>>> https://issues.jboss.org/browse/APIMAN-569 >>>>> >>>>> On 20/07/2015 10:09, Eric Wittmann wrote: >>>>>> Hi Tim. >>>>>> >>>>>> Interesting scenario. The typical scenario is that the apiman UI is >>>>>> only used by service providers and application developers. End users >>>>>> will typically not use the apiman UI. However, that doesn't mean >>>>>> apiman can't track end users. If authentication is enabled (either >>>>>> BASIC or OAuth2), then rate limiting can be configured on a per-user >>>>>> basis. When you configure the rate limit policy, you can choose >>>>>> "user" as an option and then provide the HTTP header containing the >>>>>> user. When configuring the authentication policy (which must come >>>>>> first in the policy chain) you would need to enable forwarding of the >>>>>> username. >>>>>> >>>>>> In addition, the next version of apiman will also include the >>>>>> authenticated user in the metrics data. This would allow you to >>>>>> query >>>>>> the elasticsearch metrics information by username. We won't have any >>>>>> specific support in the UI for breaking down metrics by user, at >>>>>> least >>>>>> not right away, but it will be in the data at least. >>>>>> >>>>>> Of course, you *can* use apiman the way you are suggesting. But as >>>>>> you observed there are some challenges. We don't currently have a >>>>>> way >>>>>> to assign roles to users automatically when they register. It would >>>>>> need to be a feature request I think: >>>>>> >>>>>> https://issues.jboss.org/browse/APIMAN >>>>>> >>>>>> I think if we added a very generic "user registration" extension >>>>>> point >>>>>> to apiman, then you could write your own custom handler to do >>>>>> whatever >>>>>> you want. Such a handler would be invoked the first time a new user >>>>>> logged into apiman. You could drive off their email address, roles, >>>>>> whatever. You could also provide a handler via a plugin. >>>>>> >>>>>> Thoughts? :) >>>>>> >>>>>> -Eric >>>>>> >>>>>> >>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>>>>>> Hi >>>>>>> >>>>>>> I've been looking into apiman and like what I see, but have a >>>>>>> conceptual >>>>>>> question about its usage. >>>>>>> I need something to manage the end users of my applications, not >>>>>>> just >>>>>>> the people who are developing and managing those applications. Is >>>>>>> apiman >>>>>>> suitable for this? e.g. each actual user of the applications would >>>>>>> register to apiman and use their own access keys. I need this as I >>>>>>> will >>>>>>> want to handle metrics and usage on the level of the individual >>>>>>> user. >>>>>>> >>>>>>> Also, if this was to be a sensible approach how does one >>>>>>> configure the >>>>>>> registration process. I understand apiman is using keycloak for >>>>>>> this, >>>>>>> but I see no link in the UI to configure keycloak. And I would >>>>>>> need a >>>>>>> way that new users could automatically be assigned to an >>>>>>> organisation >>>>>>> (e.g. a default organisation, or a specific one based on their email >>>>>>> address). >>>>>>> >>>>>>> Tim >>>>>>> _______________________________________________ >>>>>>> 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 >>> > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Sat Oct 10 05:39:19 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sat, 10 Oct 2015 10:39:19 +0100 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <56180353.6090801@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> <561800DC.6070206@gmail.com> <56180353.6090801@redhat.com> Message-ID: <5618DCC7.2090501@gmail.com> Yes, indeed I was looking at the wrong policy. The Keycloak OAuth Policy looks exactly what I need and the blog post describes it well. You should make those non-bundled policies more visible! Tim On 09/10/2015 19:11, Eric Wittmann wrote: > Perhaps you are looking at the wrong policy. The one you want to use > is the Keycloak OAuth Policy, which is available if you install the > appropriate keycloak plugin. A blog post about it can be found here: > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > > The Authorization policy only does role-based access control, not > OAuth authentication. The Keycloak OAuth policy should be configured > first, and then the roles found in the bearer token will get passed to > the Authorization policy, which should be configured 2nd. > > -Eric > > On 10/9/2015 2:01 PM, Tim Dudgeon wrote: >> Yes, but I don't see how a different realm/server this can be configured >> with the current Authorization policy. >> Is this possible? >> >> Tim >> >> On 09/10/2015 18:56, Eric Wittmann wrote: >>> I would argue that using some *other* realm (NOT the apiman realm) is >>> the more sensible thing to do. >>> >>> In fact, I might go so far as to suggest a second keycloak server >>> would make more logical sense than using the apiman one. Of course, >>> practically speaking it makes sense to just have one KC server. But >>> definitely I think you want to create other realms - and one realm per >>> organization is a very sensible approach. >>> >>> -Eric >>> >>> On 10/9/2015 1:10 PM, Tim Dudgeon wrote: >>>> Picking up on this again, you mentioned OAuth2 authentication. >>>> By this I'm assuming you mean what's listed as "Authorization >>>> policy" in >>>> the available policies, and this authenticates against the apiman >>>> realm >>>> in keycloak. >>>> >>>> Is it possible/desirable to allow a different realm to be configured >>>> here? The idea being that an organisation could create a policy that >>>> authenticates against a realm configured for that organisation (maybe >>>> using its own LDAP server etc.). This way an organisation can >>>> configure >>>> usage for all its users without them needing to be apiman users? >>>> >>>> Tim >>>> >>>> On 23/07/2015 14:34, Eric Wittmann wrote: >>>>> +1 thanks. >>>>> >>>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: >>>>>> No further comments so I created an issue for this: >>>>>> https://issues.jboss.org/browse/APIMAN-569 >>>>>> >>>>>> On 20/07/2015 10:09, Eric Wittmann wrote: >>>>>>> Hi Tim. >>>>>>> >>>>>>> Interesting scenario. The typical scenario is that the apiman >>>>>>> UI is >>>>>>> only used by service providers and application developers. End >>>>>>> users >>>>>>> will typically not use the apiman UI. However, that doesn't mean >>>>>>> apiman can't track end users. If authentication is enabled (either >>>>>>> BASIC or OAuth2), then rate limiting can be configured on a >>>>>>> per-user >>>>>>> basis. When you configure the rate limit policy, you can choose >>>>>>> "user" as an option and then provide the HTTP header containing the >>>>>>> user. When configuring the authentication policy (which must come >>>>>>> first in the policy chain) you would need to enable forwarding >>>>>>> of the >>>>>>> username. >>>>>>> >>>>>>> In addition, the next version of apiman will also include the >>>>>>> authenticated user in the metrics data. This would allow you to >>>>>>> query >>>>>>> the elasticsearch metrics information by username. We won't >>>>>>> have any >>>>>>> specific support in the UI for breaking down metrics by user, at >>>>>>> least >>>>>>> not right away, but it will be in the data at least. >>>>>>> >>>>>>> Of course, you *can* use apiman the way you are suggesting. But as >>>>>>> you observed there are some challenges. We don't currently have a >>>>>>> way >>>>>>> to assign roles to users automatically when they register. It >>>>>>> would >>>>>>> need to be a feature request I think: >>>>>>> >>>>>>> https://issues.jboss.org/browse/APIMAN >>>>>>> >>>>>>> I think if we added a very generic "user registration" extension >>>>>>> point >>>>>>> to apiman, then you could write your own custom handler to do >>>>>>> whatever >>>>>>> you want. Such a handler would be invoked the first time a new >>>>>>> user >>>>>>> logged into apiman. You could drive off their email address, >>>>>>> roles, >>>>>>> whatever. You could also provide a handler via a plugin. >>>>>>> >>>>>>> Thoughts? :) >>>>>>> >>>>>>> -Eric >>>>>>> >>>>>>> >>>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>>>>>>> Hi >>>>>>>> >>>>>>>> I've been looking into apiman and like what I see, but have a >>>>>>>> conceptual >>>>>>>> question about its usage. >>>>>>>> I need something to manage the end users of my applications, not >>>>>>>> just >>>>>>>> the people who are developing and managing those applications. Is >>>>>>>> apiman >>>>>>>> suitable for this? e.g. each actual user of the applications would >>>>>>>> register to apiman and use their own access keys. I need this as I >>>>>>>> will >>>>>>>> want to handle metrics and usage on the level of the individual >>>>>>>> user. >>>>>>>> >>>>>>>> Also, if this was to be a sensible approach how does one >>>>>>>> configure the >>>>>>>> registration process. I understand apiman is using keycloak for >>>>>>>> this, >>>>>>>> but I see no link in the UI to configure keycloak. And I would >>>>>>>> need a >>>>>>>> way that new users could automatically be assigned to an >>>>>>>> organisation >>>>>>>> (e.g. a default organisation, or a specific one based on their >>>>>>>> email >>>>>>>> address). >>>>>>>> >>>>>>>> Tim >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >> >> _______________________________________________ >> 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 Oct 10 10:13:26 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Sat, 10 Oct 2015 10:13:26 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <5618DCC7.2090501@gmail.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> <561800DC.6070206@gmail.com> <56180353.6090801@redhat.com> <5618DCC7.2090501@gmail.com> Message-ID: <56191D06.5050700@redhat.com> Funny you should suggest that - the plugins will be *much* easier to install in version 1.2.x because there is a UI which lists all the available "official" apiman plugins. Of course you can also still install your own plugin via the UI. I'm also toying around with the idea of pre-installing some of the plugins so they are automatically included in the apiman quickstart. -Eric On 10/10/2015 5:39 AM, Tim Dudgeon wrote: > Yes, indeed I was looking at the wrong policy. > The Keycloak OAuth Policy looks exactly what I need and the blog post > describes it well. > You should make those non-bundled policies more visible! > > Tim > > On 09/10/2015 19:11, Eric Wittmann wrote: >> Perhaps you are looking at the wrong policy. The one you want to use >> is the Keycloak OAuth Policy, which is available if you install the >> appropriate keycloak plugin. A blog post about it can be found here: >> >> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html >> >> >> The Authorization policy only does role-based access control, not >> OAuth authentication. The Keycloak OAuth policy should be configured >> first, and then the roles found in the bearer token will get passed to >> the Authorization policy, which should be configured 2nd. >> >> -Eric >> >> On 10/9/2015 2:01 PM, Tim Dudgeon wrote: >>> Yes, but I don't see how a different realm/server this can be configured >>> with the current Authorization policy. >>> Is this possible? >>> >>> Tim >>> >>> On 09/10/2015 18:56, Eric Wittmann wrote: >>>> I would argue that using some *other* realm (NOT the apiman realm) is >>>> the more sensible thing to do. >>>> >>>> In fact, I might go so far as to suggest a second keycloak server >>>> would make more logical sense than using the apiman one. Of course, >>>> practically speaking it makes sense to just have one KC server. But >>>> definitely I think you want to create other realms - and one realm per >>>> organization is a very sensible approach. >>>> >>>> -Eric >>>> >>>> On 10/9/2015 1:10 PM, Tim Dudgeon wrote: >>>>> Picking up on this again, you mentioned OAuth2 authentication. >>>>> By this I'm assuming you mean what's listed as "Authorization >>>>> policy" in >>>>> the available policies, and this authenticates against the apiman >>>>> realm >>>>> in keycloak. >>>>> >>>>> Is it possible/desirable to allow a different realm to be configured >>>>> here? The idea being that an organisation could create a policy that >>>>> authenticates against a realm configured for that organisation (maybe >>>>> using its own LDAP server etc.). This way an organisation can >>>>> configure >>>>> usage for all its users without them needing to be apiman users? >>>>> >>>>> Tim >>>>> >>>>> On 23/07/2015 14:34, Eric Wittmann wrote: >>>>>> +1 thanks. >>>>>> >>>>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: >>>>>>> No further comments so I created an issue for this: >>>>>>> https://issues.jboss.org/browse/APIMAN-569 >>>>>>> >>>>>>> On 20/07/2015 10:09, Eric Wittmann wrote: >>>>>>>> Hi Tim. >>>>>>>> >>>>>>>> Interesting scenario. The typical scenario is that the apiman >>>>>>>> UI is >>>>>>>> only used by service providers and application developers. End >>>>>>>> users >>>>>>>> will typically not use the apiman UI. However, that doesn't mean >>>>>>>> apiman can't track end users. If authentication is enabled (either >>>>>>>> BASIC or OAuth2), then rate limiting can be configured on a >>>>>>>> per-user >>>>>>>> basis. When you configure the rate limit policy, you can choose >>>>>>>> "user" as an option and then provide the HTTP header containing the >>>>>>>> user. When configuring the authentication policy (which must come >>>>>>>> first in the policy chain) you would need to enable forwarding >>>>>>>> of the >>>>>>>> username. >>>>>>>> >>>>>>>> In addition, the next version of apiman will also include the >>>>>>>> authenticated user in the metrics data. This would allow you to >>>>>>>> query >>>>>>>> the elasticsearch metrics information by username. We won't >>>>>>>> have any >>>>>>>> specific support in the UI for breaking down metrics by user, at >>>>>>>> least >>>>>>>> not right away, but it will be in the data at least. >>>>>>>> >>>>>>>> Of course, you *can* use apiman the way you are suggesting. But as >>>>>>>> you observed there are some challenges. We don't currently have a >>>>>>>> way >>>>>>>> to assign roles to users automatically when they register. It >>>>>>>> would >>>>>>>> need to be a feature request I think: >>>>>>>> >>>>>>>> https://issues.jboss.org/browse/APIMAN >>>>>>>> >>>>>>>> I think if we added a very generic "user registration" extension >>>>>>>> point >>>>>>>> to apiman, then you could write your own custom handler to do >>>>>>>> whatever >>>>>>>> you want. Such a handler would be invoked the first time a new >>>>>>>> user >>>>>>>> logged into apiman. You could drive off their email address, >>>>>>>> roles, >>>>>>>> whatever. You could also provide a handler via a plugin. >>>>>>>> >>>>>>>> Thoughts? :) >>>>>>>> >>>>>>>> -Eric >>>>>>>> >>>>>>>> >>>>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: >>>>>>>>> Hi >>>>>>>>> >>>>>>>>> I've been looking into apiman and like what I see, but have a >>>>>>>>> conceptual >>>>>>>>> question about its usage. >>>>>>>>> I need something to manage the end users of my applications, not >>>>>>>>> just >>>>>>>>> the people who are developing and managing those applications. Is >>>>>>>>> apiman >>>>>>>>> suitable for this? e.g. each actual user of the applications would >>>>>>>>> register to apiman and use their own access keys. I need this as I >>>>>>>>> will >>>>>>>>> want to handle metrics and usage on the level of the individual >>>>>>>>> user. >>>>>>>>> >>>>>>>>> Also, if this was to be a sensible approach how does one >>>>>>>>> configure the >>>>>>>>> registration process. I understand apiman is using keycloak for >>>>>>>>> this, >>>>>>>>> but I see no link in the UI to configure keycloak. And I would >>>>>>>>> need a >>>>>>>>> way that new users could automatically be assigned to an >>>>>>>>> organisation >>>>>>>>> (e.g. a default organisation, or a specific one based on their >>>>>>>>> email >>>>>>>>> address). >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> _______________________________________________ >>>>>>>>> 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 >>>>> >>> >>> _______________________________________________ >>> 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 jcechace at gmail.com Sat Oct 10 10:20:15 2015 From: jcechace at gmail.com (=?UTF-8?B?SmFrdWIgxIxlY2jDocSNZWs=?=) Date: Sat, 10 Oct 2015 16:20:15 +0200 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <56191D06.5050700@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> <561800DC.6070206@gmail.com> <56180353.6090801@redhat.com> <5618DCC7.2090501@gmail.com> <56191D06.5050700@redhat.com> Message-ID: Hi, > I'm also toying around with the idea of pre-installing some of the > plugins so they are automatically included in the apiman quickstart. A nice approach to this would be a post-install "setup wizard" when the UI is first entered. This would enable user to add the seed data and possibly enable additional plugins. Jakub. On Sat, Oct 10, 2015 at 4:13 PM, Eric Wittmann wrote: > Funny you should suggest that - the plugins will be *much* easier to > install in version 1.2.x because there is a UI which lists all the > available "official" apiman plugins. Of course you can also still > install your own plugin via the UI. > > I'm also toying around with the idea of pre-installing some of the > plugins so they are automatically included in the apiman quickstart. > > -Eric > > On 10/10/2015 5:39 AM, Tim Dudgeon wrote: > > Yes, indeed I was looking at the wrong policy. > > The Keycloak OAuth Policy looks exactly what I need and the blog post > > describes it well. > > You should make those non-bundled policies more visible! > > > > Tim > > > > On 09/10/2015 19:11, Eric Wittmann wrote: > >> Perhaps you are looking at the wrong policy. The one you want to use > >> is the Keycloak OAuth Policy, which is available if you install the > >> appropriate keycloak plugin. A blog post about it can be found here: > >> > >> > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > >> > >> > >> The Authorization policy only does role-based access control, not > >> OAuth authentication. The Keycloak OAuth policy should be configured > >> first, and then the roles found in the bearer token will get passed to > >> the Authorization policy, which should be configured 2nd. > >> > >> -Eric > >> > >> On 10/9/2015 2:01 PM, Tim Dudgeon wrote: > >>> Yes, but I don't see how a different realm/server this can be > configured > >>> with the current Authorization policy. > >>> Is this possible? > >>> > >>> Tim > >>> > >>> On 09/10/2015 18:56, Eric Wittmann wrote: > >>>> I would argue that using some *other* realm (NOT the apiman realm) is > >>>> the more sensible thing to do. > >>>> > >>>> In fact, I might go so far as to suggest a second keycloak server > >>>> would make more logical sense than using the apiman one. Of course, > >>>> practically speaking it makes sense to just have one KC server. But > >>>> definitely I think you want to create other realms - and one realm per > >>>> organization is a very sensible approach. > >>>> > >>>> -Eric > >>>> > >>>> On 10/9/2015 1:10 PM, Tim Dudgeon wrote: > >>>>> Picking up on this again, you mentioned OAuth2 authentication. > >>>>> By this I'm assuming you mean what's listed as "Authorization > >>>>> policy" in > >>>>> the available policies, and this authenticates against the apiman > >>>>> realm > >>>>> in keycloak. > >>>>> > >>>>> Is it possible/desirable to allow a different realm to be configured > >>>>> here? The idea being that an organisation could create a policy that > >>>>> authenticates against a realm configured for that organisation (maybe > >>>>> using its own LDAP server etc.). This way an organisation can > >>>>> configure > >>>>> usage for all its users without them needing to be apiman users? > >>>>> > >>>>> Tim > >>>>> > >>>>> On 23/07/2015 14:34, Eric Wittmann wrote: > >>>>>> +1 thanks. > >>>>>> > >>>>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: > >>>>>>> No further comments so I created an issue for this: > >>>>>>> https://issues.jboss.org/browse/APIMAN-569 > >>>>>>> > >>>>>>> On 20/07/2015 10:09, Eric Wittmann wrote: > >>>>>>>> Hi Tim. > >>>>>>>> > >>>>>>>> Interesting scenario. The typical scenario is that the apiman > >>>>>>>> UI is > >>>>>>>> only used by service providers and application developers. End > >>>>>>>> users > >>>>>>>> will typically not use the apiman UI. However, that doesn't mean > >>>>>>>> apiman can't track end users. If authentication is enabled > (either > >>>>>>>> BASIC or OAuth2), then rate limiting can be configured on a > >>>>>>>> per-user > >>>>>>>> basis. When you configure the rate limit policy, you can choose > >>>>>>>> "user" as an option and then provide the HTTP header containing > the > >>>>>>>> user. When configuring the authentication policy (which must come > >>>>>>>> first in the policy chain) you would need to enable forwarding > >>>>>>>> of the > >>>>>>>> username. > >>>>>>>> > >>>>>>>> In addition, the next version of apiman will also include the > >>>>>>>> authenticated user in the metrics data. This would allow you to > >>>>>>>> query > >>>>>>>> the elasticsearch metrics information by username. We won't > >>>>>>>> have any > >>>>>>>> specific support in the UI for breaking down metrics by user, at > >>>>>>>> least > >>>>>>>> not right away, but it will be in the data at least. > >>>>>>>> > >>>>>>>> Of course, you *can* use apiman the way you are suggesting. But as > >>>>>>>> you observed there are some challenges. We don't currently have a > >>>>>>>> way > >>>>>>>> to assign roles to users automatically when they register. It > >>>>>>>> would > >>>>>>>> need to be a feature request I think: > >>>>>>>> > >>>>>>>> https://issues.jboss.org/browse/APIMAN > >>>>>>>> > >>>>>>>> I think if we added a very generic "user registration" extension > >>>>>>>> point > >>>>>>>> to apiman, then you could write your own custom handler to do > >>>>>>>> whatever > >>>>>>>> you want. Such a handler would be invoked the first time a new > >>>>>>>> user > >>>>>>>> logged into apiman. You could drive off their email address, > >>>>>>>> roles, > >>>>>>>> whatever. You could also provide a handler via a plugin. > >>>>>>>> > >>>>>>>> Thoughts? :) > >>>>>>>> > >>>>>>>> -Eric > >>>>>>>> > >>>>>>>> > >>>>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> I've been looking into apiman and like what I see, but have a > >>>>>>>>> conceptual > >>>>>>>>> question about its usage. > >>>>>>>>> I need something to manage the end users of my applications, not > >>>>>>>>> just > >>>>>>>>> the people who are developing and managing those applications. Is > >>>>>>>>> apiman > >>>>>>>>> suitable for this? e.g. each actual user of the applications > would > >>>>>>>>> register to apiman and use their own access keys. I need this as > I > >>>>>>>>> will > >>>>>>>>> want to handle metrics and usage on the level of the individual > >>>>>>>>> user. > >>>>>>>>> > >>>>>>>>> Also, if this was to be a sensible approach how does one > >>>>>>>>> configure the > >>>>>>>>> registration process. I understand apiman is using keycloak for > >>>>>>>>> this, > >>>>>>>>> but I see no link in the UI to configure keycloak. And I would > >>>>>>>>> need a > >>>>>>>>> way that new users could automatically be assigned to an > >>>>>>>>> organisation > >>>>>>>>> (e.g. a default organisation, or a specific one based on their > >>>>>>>>> email > >>>>>>>>> address). > >>>>>>>>> > >>>>>>>>> Tim > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>> > >>> > >>> _______________________________________________ > >>> 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/20151010/66737f2b/attachment-0001.html From tdudgeon.ml at gmail.com Sun Oct 11 07:16:25 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 11 Oct 2015 12:16:25 +0100 Subject: [Apiman-user] apiman-user@lists.jboss.org Message-ID: <561A4509.4090004@gmail.com> I've noticed that requests to the apiman gateway for an invalid organisation or service etc. hang forever. e.g. a request to https://localhost:8443/apiman-gateway/OrganisationThatDoesntExist/serviceThatDoesntExist/1.0 Shouldn't this return a 404 error (or some other error) immediately? Tim From tdudgeon.ml at gmail.com Sun Oct 11 07:30:45 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 11 Oct 2015 12:30:45 +0100 Subject: [Apiman-user] service not being published to gateway after restart? Message-ID: <561A4865.8090009@gmail.com> I'm hitting a problem where I'm running apiman in a docker container. When I first set up a public service it runs fine. But when I restart the container the service definition is still there, but the gateway does not respond to requests for the service. If I create a new version of the service and publish it then it works fine. Seems like the service definition is not being published to the gateway after a restart? I've tried it with the basic Docker container similar to jboss/apiman-wildfly on Dockerhub and it seems OK with that, so it looks like its something I've done to cause this, but I don't see any errors and don't know where to look to try to fix it. Any ideas what's wrong? This is with version 1.1.8.Final. Tim From tdudgeon.ml at gmail.com Sun Oct 11 11:40:07 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Sun, 11 Oct 2015 16:40:07 +0100 Subject: [Apiman-user] base64 encoding of tokens Message-ID: <561A82D7.1050305@gmail.com> According to this: http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html the tokens returned by keycloak are base64 encoded, but when I try to decode I get an error. $ curl -X POST http://192.168.59.103:8080/auth/realms/myrealm/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d "username=user1" -d 'password=secret' -d 'grant_type=password' -d 'client_id=echo' -s | jq -r '.access_token' | base64 -D Invalid character in input stream. How are the tokens supposed to be decoded? Tim From eric.wittmann at redhat.com Sun Oct 11 16:33:22 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Sun, 11 Oct 2015 16:33:22 -0400 Subject: [Apiman-user] apiman-user@lists.jboss.org In-Reply-To: <561A4509.4090004@gmail.com> References: <561A4509.4090004@gmail.com> Message-ID: <561AC792.7040306@redhat.com> This is a bug in version 1.1.8.Final - it has been fixed and should be working OK in the next release (due out shortly - likely this week). -Eric On 10/11/2015 7:16 AM, Tim Dudgeon wrote: > I've noticed that requests to the apiman gateway for an invalid > organisation or service etc. hang forever. > e.g. a request to > https://localhost:8443/apiman-gateway/OrganisationThatDoesntExist/serviceThatDoesntExist/1.0 > > > Shouldn't this return a 404 error (or some other error) immediately? > > Tim > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Sun Oct 11 17:51:09 2015 From: marc.savy at redhat.com (Marc Savy) Date: Sun, 11 Oct 2015 22:51:09 +0100 Subject: [Apiman-user] base64 encoding of tokens In-Reply-To: <561A82D7.1050305@gmail.com> References: <561A82D7.1050305@gmail.com> Message-ID: <561AD9CD.5090101@redhat.com> Tim, You're right. I'll have to update the blog. What Keycloak returns in the access_token field is a JWT (see http://www.jtw.io), which is a string split into 3 base64 parts, separated by full stops (header, payload and signature info) as is highlighted on jwt.io when you paste your token :-). Alternatively, if you use something like Ruby's Base64 decoder (which is a bit more tolerant), you'll see useful info coming out. Regards, Marc On 11/10/2015 16:40, Tim Dudgeon wrote: > According to this: > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > the tokens returned by keycloak are base64 encoded, but when I try to > decode I get an error. > > $ curl -X POST > http://192.168.59.103:8080/auth/realms/myrealm/protocol/openid-connect/token > -H "Content-Type: application/x-www-form-urlencoded" -d "username=user1" > -d 'password=secret' -d 'grant_type=password' -d 'client_id=echo' -s | > jq -r '.access_token' | base64 -D > Invalid character in input stream. > > How are the tokens supposed to be decoded? > > Tim > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Mon Oct 12 07:43:58 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Mon, 12 Oct 2015 12:43:58 +0100 Subject: [Apiman-user] Token audience doesn't match domain when run inside Docker container Message-ID: <561B9CFE.4000501@gmail.com> Hi, I've been following this blog on using the OAuth policy: http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html When I do this with Apiman running in a Docker container (jboss/apiman-wildfly from Dockerhub) I'm getting an error when I try to access the echo service: $ curl -k -H "Authorization: Bearer eyJhbGciO..." -s https://192.168.59.103:8443/apiman-gateway/Newcastle/EchoService/1.0 | jq { "type": "Authentication", "failureCode": 11004, "responseCode": 401, "message": "Token audience doesn't match domain. Token issuer is http://192.168.59.103:8080/auth/realms/stottie, but URL from configuration is http://127.0.0.1:8080/auth/realms/stottie", "headers": {} } $ (192.168.59.103 is the IP address of the Docker host running in Boot2Docker). Any ideas where the wrong "URL from configuration" part is coming from? Tim From fadiabdeen at gmail.com Mon Oct 12 07:52:13 2015 From: fadiabdeen at gmail.com (Fadi Abdin) Date: Mon, 12 Oct 2015 07:52:13 -0400 Subject: [Apiman-user] Token audience doesn't match domain when run inside Docker container In-Reply-To: <561B9CFE.4000501@gmail.com> References: <561B9CFE.4000501@gmail.com> Message-ID: Hi Tim, Check the Realm in Keycloak OAuth Policy Configuration page it should match the one in the token. i hope this help. On Mon, Oct 12, 2015 at 7:43 AM, Tim Dudgeon wrote: > Hi, > > I've been following this blog on using the OAuth policy: > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > When I do this with Apiman running in a Docker container > (jboss/apiman-wildfly from Dockerhub) I'm getting an error when I try to > access the echo service: > > $ curl -k -H "Authorization: Bearer eyJhbGciO..." -s > https://192.168.59.103:8443/apiman-gateway/Newcastle/EchoService/1.0 | jq > { > "type": "Authentication", > "failureCode": 11004, > "responseCode": 401, > "message": "Token audience doesn't match domain. Token issuer is > http://192.168.59.103:8080/auth/realms/stottie, but URL from > configuration is http://127.0.0.1:8080/auth/realms/stottie", > "headers": {} > } > $ > > (192.168.59.103 is the IP address of the Docker host running in > Boot2Docker). > Any ideas where the wrong "URL from configuration" part is coming from? > > Tim > _______________________________________________ > 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/20151012/5796cba9/attachment.html From tdudgeon.ml at gmail.com Mon Oct 12 08:18:43 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Mon, 12 Oct 2015 13:18:43 +0100 Subject: [Apiman-user] Token audience doesn't match domain when run inside Docker container In-Reply-To: References: <561B9CFE.4000501@gmail.com> Message-ID: <561BA523.5010802@gmail.com> Thanks. That's the trick! On 12/10/2015 12:52, Fadi Abdin wrote: > Hi Tim, > > Check the Realm in Keycloak OAuth Policy Configuration page it should > match the one in the token. > > i hope this help. > > On Mon, Oct 12, 2015 at 7:43 AM, Tim Dudgeon > wrote: > > Hi, > > I've been following this blog on using the OAuth policy: > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > When I do this with Apiman running in a Docker container > (jboss/apiman-wildfly from Dockerhub) I'm getting an error when I > try to > access the echo service: > > $ curl -k -H "Authorization: Bearer eyJhbGciO..." -s > https://192.168.59.103:8443/apiman-gateway/Newcastle/EchoService/1.0 > | jq > { > "type": "Authentication", > "failureCode": 11004, > "responseCode": 401, > "message": "Token audience doesn't match domain. Token issuer is > http://192.168.59.103:8080/auth/realms/stottie, but URL from > configuration is http://127.0.0.1:8080/auth/realms/stottie", > "headers": {} > } > $ > > (192.168.59.103 is the IP address of the Docker host running in > Boot2Docker). > Any ideas where the wrong "URL from configuration" part is coming > from? > > Tim > _______________________________________________ > 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/20151012/f092cc44/attachment-0001.html From tdudgeon.ml at gmail.com Tue Oct 13 06:04:59 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Tue, 13 Oct 2015 11:04:59 +0100 Subject: [Apiman-user] Invalid token signature Message-ID: <561CD74B.60408@gmail.com> Hi, I'm trying to access a service though an application and plan, using OAuth authentication at the application level and authorization at the service level (requiring a role assigned to the user during authentication). I thought I had it all set up correctly, but am getting an Invalid token signature error. I generate access token like this: $ curl -X POST http://192.168.59.103:8080/auth/realms/Organization1/protocol/openid-connect/token -H "Content-Type: application/x-www-form-urlencoded" -d 'username=user1' -d 'password=user1' -d 'grant_type=password' -d 'client_id=app1' -s | jq -r '.access_token' and get an access token like this: eyJhb Then try to access the service like this: $ curl -k -H "Authorization: Bearer eyJhb" -H "X-API-Key: bb9eb966-" -s https://192.168.59.103:8443/apiman-gateway/Organization2/echo/1.5/ And I get this error: {"type":"Authentication","failureCode":11004,"responseCode":401,"message":"Invalid token signature.","headers":{}} Any ideas what the Invalid token signature error relates to? Thanks Tim From tdudgeon.ml at gmail.com Tue Oct 13 06:20:31 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Tue, 13 Oct 2015 11:20:31 +0100 Subject: [Apiman-user] Invalid token signature In-Reply-To: <561CD74B.60408@gmail.com> References: <561CD74B.60408@gmail.com> Message-ID: <561CDAEF.1000409@gmail.com> I tracked it down eventually - I had OAuth authentication at 2 places in the chain which seems to be the cause or the error. Tim On 13/10/2015 11:04, Tim Dudgeon wrote: > Hi, I'm trying to access a service though an application and plan, > using OAuth authentication at the application level and authorization > at the service level (requiring a role assigned to the user during > authentication). > I thought I had it all set up correctly, but am getting an Invalid > token signature error. > > I generate access token like this: > > $ curl -X POST > http://192.168.59.103:8080/auth/realms/Organization1/protocol/openid-connect/token > -H "Content-Type: application/x-www-form-urlencoded" -d > 'username=user1' -d 'password=user1' -d 'grant_type=password' -d > 'client_id=app1' -s | jq -r '.access_token' > > and get an access token like this: > > eyJhb > > Then try to access the service like this: > > $ curl -k -H "Authorization: Bearer eyJhb" -H "X-API-Key: > bb9eb966-" -s > https://192.168.59.103:8443/apiman-gateway/Organization2/echo/1.5/ > > And I get this error: > > {"type":"Authentication","failureCode":11004,"responseCode":401,"message":"Invalid > token signature.","headers":{}} > > > Any ideas what the Invalid token signature error relates to? > > Thanks > Tim > From eric.wittmann at redhat.com Tue Oct 13 07:23:58 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 13 Oct 2015 07:23:58 -0400 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561A4865.8090009@gmail.com> References: <561A4865.8090009@gmail.com> Message-ID: <561CE9CE.8090109@redhat.com> When a service is published to the gateway, that configuration is saved in the gateway's persistent registry. By default (in the latest version of apiman) the gateway uses elasticsearch to store its registry information. So ideally you should run elasticsearch as a separate docker container, making sure that you have an appropriate persistent volume attached so that any data added to ES survives a docker restart. Then you can configure apiman to use that external ES. There is documentation in the Installation Guide that explains how to use an external elasticsearch cluster. -Eric On 10/11/2015 7:30 AM, Tim Dudgeon wrote: > I'm hitting a problem where I'm running apiman in a docker container. > When I first set up a public service it runs fine. > But when I restart the container the service definition is still there, > but the gateway does not respond to requests for the service. If I > create a new version of the service and publish it then it works fine. > > Seems like the service definition is not being published to the gateway > after a restart? > I've tried it with the basic Docker container similar to > jboss/apiman-wildfly on Dockerhub and it seems OK with that, so it looks > like its something I've done to cause this, but I don't see any errors > and don't know where to look to try to fix it. > Any ideas what's wrong? > This is with version 1.1.8.Final. > > Tim > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Tue Oct 13 07:37:53 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Tue, 13 Oct 2015 12:37:53 +0100 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561CE9CE.8090109@redhat.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> Message-ID: <561CED11.2060305@gmail.com> Right now I'm using the ES that's bundled with Apiman (though do intend to switch to a separate container). The baffling thing is that with the Docker image on Dockerhub (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised version (with Keycloak and Postgres currently as separate containers) it fails. The APIMan and ES parts are still pretty well the same as the jboss/apiman-wildfly image. So I seem to have messed something up, but don't have much of an idea as to what. Tim On 13/10/2015 12:23, Eric Wittmann wrote: > When a service is published to the gateway, that configuration is > saved in the gateway's persistent registry. By default (in the latest > version of apiman) the gateway uses elasticsearch to store its > registry information. So ideally you should run elasticsearch as a > separate docker container, making sure that you have an appropriate > persistent volume attached so that any data added to ES survives a > docker restart. Then you can configure apiman to use that external ES. > > There is documentation in the Installation Guide that explains how to > use an external elasticsearch cluster. > > -Eric > > On 10/11/2015 7:30 AM, Tim Dudgeon wrote: >> I'm hitting a problem where I'm running apiman in a docker container. >> When I first set up a public service it runs fine. >> But when I restart the container the service definition is still there, >> but the gateway does not respond to requests for the service. If I >> create a new version of the service and publish it then it works fine. >> >> Seems like the service definition is not being published to the gateway >> after a restart? >> I've tried it with the basic Docker container similar to >> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so it looks >> like its something I've done to cause this, but I don't see any errors >> and don't know where to look to try to fix it. >> Any ideas what's wrong? >> This is with version 1.1.8.Final. >> >> Tim >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> From eric.wittmann at redhat.com Tue Oct 13 07:57:45 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 13 Oct 2015 07:57:45 -0400 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561CED11.2060305@gmail.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> Message-ID: <561CF1B9.2020008@redhat.com> Hm. Without digging into it, I'm not sure what to suggest. I'm also not a docker expert by any stretch, so that complicates things. :) I can tell you that the default elasticsearch instance that comes with the apiman quickstart stores data in the standalone/data/es directory. You could perhaps poke around that area. See if data is getting written there, and whether it's still there when you restart the container? -Eric On 10/13/2015 7:37 AM, Tim Dudgeon wrote: > Right now I'm using the ES that's bundled with Apiman (though do intend > to switch to a separate container). > The baffling thing is that with the Docker image on Dockerhub > (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised > version (with Keycloak and Postgres currently as separate containers) it > fails. The APIMan and ES parts are still pretty well the same as the > jboss/apiman-wildfly image. > > So I seem to have messed something up, but don't have much of an idea as > to what. > > Tim > > On 13/10/2015 12:23, Eric Wittmann wrote: >> When a service is published to the gateway, that configuration is >> saved in the gateway's persistent registry. By default (in the latest >> version of apiman) the gateway uses elasticsearch to store its >> registry information. So ideally you should run elasticsearch as a >> separate docker container, making sure that you have an appropriate >> persistent volume attached so that any data added to ES survives a >> docker restart. Then you can configure apiman to use that external ES. >> >> There is documentation in the Installation Guide that explains how to >> use an external elasticsearch cluster. >> >> -Eric >> >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: >>> I'm hitting a problem where I'm running apiman in a docker container. >>> When I first set up a public service it runs fine. >>> But when I restart the container the service definition is still there, >>> but the gateway does not respond to requests for the service. If I >>> create a new version of the service and publish it then it works fine. >>> >>> Seems like the service definition is not being published to the gateway >>> after a restart? >>> I've tried it with the basic Docker container similar to >>> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so it looks >>> like its something I've done to cause this, but I don't see any errors >>> and don't know where to look to try to fix it. >>> Any ideas what's wrong? >>> This is with version 1.1.8.Final. >>> >>> Tim >>> >>> _______________________________________________ >>> 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 eric.wittmann at redhat.com Tue Oct 13 07:58:33 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 13 Oct 2015 07:58:33 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> <561800DC.6070206@gmail.com> <56180353.6090801@redhat.com> <5618DCC7.2090501@gmail.com> <56191D06.5050700@redhat.com> Message-ID: <561CF1E9.9080503@redhat.com> +1 to this idea. @Jakub - can you add a jira feature request for this? On 10/10/2015 10:20 AM, Jakub ?ech??ek wrote: > Hi, > > > I'm also toying around with the idea of pre-installing some of the >> plugins so they are automatically included in the apiman quickstart. > > A nice approach to this would be a post-install "setup wizard" when the > UI is first entered. This would enable user to add the seed data and > possibly enable additional plugins. > > Jakub. > > On Sat, Oct 10, 2015 at 4:13 PM, Eric Wittmann > wrote: > > Funny you should suggest that - the plugins will be *much* easier to > install in version 1.2.x because there is a UI which lists all the > available "official" apiman plugins. Of course you can also still > install your own plugin via the UI. > > I'm also toying around with the idea of pre-installing some of the > plugins so they are automatically included in the apiman quickstart. > > -Eric > > On 10/10/2015 5:39 AM, Tim Dudgeon wrote: > > Yes, indeed I was looking at the wrong policy. > > The Keycloak OAuth Policy looks exactly what I need and the blog post > > describes it well. > > You should make those non-bundled policies more visible! > > > > Tim > > > > On 09/10/2015 19:11, Eric Wittmann wrote: > >> Perhaps you are looking at the wrong policy. The one you want > to use > >> is the Keycloak OAuth Policy, which is available if you install the > >> appropriate keycloak plugin. A blog post about it can be found > here: > >> > >> > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > >> > >> > >> The Authorization policy only does role-based access control, not > >> OAuth authentication. The Keycloak OAuth policy should be > configured > >> first, and then the roles found in the bearer token will get > passed to > >> the Authorization policy, which should be configured 2nd. > >> > >> -Eric > >> > >> On 10/9/2015 2:01 PM, Tim Dudgeon wrote: > >>> Yes, but I don't see how a different realm/server this can be > configured > >>> with the current Authorization policy. > >>> Is this possible? > >>> > >>> Tim > >>> > >>> On 09/10/2015 18:56, Eric Wittmann wrote: > >>>> I would argue that using some *other* realm (NOT the apiman > realm) is > >>>> the more sensible thing to do. > >>>> > >>>> In fact, I might go so far as to suggest a second keycloak server > >>>> would make more logical sense than using the apiman one. Of > course, > >>>> practically speaking it makes sense to just have one KC > server. But > >>>> definitely I think you want to create other realms - and one > realm per > >>>> organization is a very sensible approach. > >>>> > >>>> -Eric > >>>> > >>>> On 10/9/2015 1:10 PM, Tim Dudgeon wrote: > >>>>> Picking up on this again, you mentioned OAuth2 authentication. > >>>>> By this I'm assuming you mean what's listed as "Authorization > >>>>> policy" in > >>>>> the available policies, and this authenticates against the apiman > >>>>> realm > >>>>> in keycloak. > >>>>> > >>>>> Is it possible/desirable to allow a different realm to be > configured > >>>>> here? The idea being that an organisation could create a > policy that > >>>>> authenticates against a realm configured for that > organisation (maybe > >>>>> using its own LDAP server etc.). This way an organisation can > >>>>> configure > >>>>> usage for all its users without them needing to be apiman users? > >>>>> > >>>>> Tim > >>>>> > >>>>> On 23/07/2015 14:34, Eric Wittmann wrote: > >>>>>> +1 thanks. > >>>>>> > >>>>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: > >>>>>>> No further comments so I created an issue for this: > >>>>>>> https://issues.jboss.org/browse/APIMAN-569 > >>>>>>> > >>>>>>> On 20/07/2015 10:09, Eric Wittmann wrote: > >>>>>>>> Hi Tim. > >>>>>>>> > >>>>>>>> Interesting scenario. The typical scenario is that the apiman > >>>>>>>> UI is > >>>>>>>> only used by service providers and application developers. End > >>>>>>>> users > >>>>>>>> will typically not use the apiman UI. However, that > doesn't mean > >>>>>>>> apiman can't track end users. If authentication is > enabled (either > >>>>>>>> BASIC or OAuth2), then rate limiting can be configured on a > >>>>>>>> per-user > >>>>>>>> basis. When you configure the rate limit policy, you can > choose > >>>>>>>> "user" as an option and then provide the HTTP header > containing the > >>>>>>>> user. When configuring the authentication policy (which > must come > >>>>>>>> first in the policy chain) you would need to enable forwarding > >>>>>>>> of the > >>>>>>>> username. > >>>>>>>> > >>>>>>>> In addition, the next version of apiman will also include the > >>>>>>>> authenticated user in the metrics data. This would allow > you to > >>>>>>>> query > >>>>>>>> the elasticsearch metrics information by username. We won't > >>>>>>>> have any > >>>>>>>> specific support in the UI for breaking down metrics by > user, at > >>>>>>>> least > >>>>>>>> not right away, but it will be in the data at least. > >>>>>>>> > >>>>>>>> Of course, you *can* use apiman the way you are > suggesting. But as > >>>>>>>> you observed there are some challenges. We don't > currently have a > >>>>>>>> way > >>>>>>>> to assign roles to users automatically when they register. It > >>>>>>>> would > >>>>>>>> need to be a feature request I think: > >>>>>>>> > >>>>>>>> https://issues.jboss.org/browse/APIMAN > >>>>>>>> > >>>>>>>> I think if we added a very generic "user registration" > extension > >>>>>>>> point > >>>>>>>> to apiman, then you could write your own custom handler to do > >>>>>>>> whatever > >>>>>>>> you want. Such a handler would be invoked the first time > a new > >>>>>>>> user > >>>>>>>> logged into apiman. You could drive off their email address, > >>>>>>>> roles, > >>>>>>>> whatever. You could also provide a handler via a plugin. > >>>>>>>> > >>>>>>>> Thoughts? :) > >>>>>>>> > >>>>>>>> -Eric > >>>>>>>> > >>>>>>>> > >>>>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> I've been looking into apiman and like what I see, but have a > >>>>>>>>> conceptual > >>>>>>>>> question about its usage. > >>>>>>>>> I need something to manage the end users of my > applications, not > >>>>>>>>> just > >>>>>>>>> the people who are developing and managing those > applications. Is > >>>>>>>>> apiman > >>>>>>>>> suitable for this? e.g. each actual user of the > applications would > >>>>>>>>> register to apiman and use their own access keys. I need > this as I > >>>>>>>>> will > >>>>>>>>> want to handle metrics and usage on the level of the > individual > >>>>>>>>> user. > >>>>>>>>> > >>>>>>>>> Also, if this was to be a sensible approach how does one > >>>>>>>>> configure the > >>>>>>>>> registration process. I understand apiman is using > keycloak for > >>>>>>>>> this, > >>>>>>>>> but I see no link in the UI to configure keycloak. And I > would > >>>>>>>>> need a > >>>>>>>>> way that new users could automatically be assigned to an > >>>>>>>>> organisation > >>>>>>>>> (e.g. a default organisation, or a specific one based on > their > >>>>>>>>> email > >>>>>>>>> address). > >>>>>>>>> > >>>>>>>>> Tim > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>> > >>> > >>> _______________________________________________ > >>> 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 marc.savy at redhat.com Tue Oct 13 08:40:58 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 13 Oct 2015 13:40:58 +0100 Subject: [Apiman-user] Invalid token signature In-Reply-To: <561CDAEF.1000409@gmail.com> References: <561CD74B.60408@gmail.com> <561CDAEF.1000409@gmail.com> Message-ID: <561CFBDA.3010008@redhat.com> Interesting situation - was it intentional? On 13/10/2015 11:20, Tim Dudgeon wrote: > I tracked it down eventually - I had OAuth authentication at 2 places in > the chain which seems to be the cause or the error. > > Tim > > On 13/10/2015 11:04, Tim Dudgeon wrote: > > Hi, I'm trying to access a service though an application and plan, > > using OAuth authentication at the application level and authorization > > at the service level (requiring a role assigned to the user during > > authentication). > > I thought I had it all set up correctly, but am getting an Invalid > > token signature error. > > > > I generate access token like this: > > > > $ curl -X POST > > http://192.168.59.103:8080/auth/realms/Organization1/protocol/openid-connect/token > > -H "Content-Type: application/x-www-form-urlencoded" -d > > 'username=user1' -d 'password=user1' -d 'grant_type=password' -d > > 'client_id=app1' -s | jq -r '.access_token' > > > > and get an access token like this: > > > > eyJhb > > > > Then try to access the service like this: > > > > $ curl -k -H "Authorization: Bearer eyJhb" -H "X-API-Key: > > bb9eb966-" -s > > https://192.168.59.103:8443/apiman-gateway/Organization2/echo/1.5/ > > > > And I get this error: > > > > {"type":"Authentication","failureCode":11004,"responseCode":401,"message":"Invalid > > token signature.","headers":{}} > > > > > > Any ideas what the Invalid token signature error relates to? > > > > Thanks > > Tim > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Tue Oct 13 08:44:13 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 13 Oct 2015 13:44:13 +0100 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561CF1B9.2020008@redhat.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> <561CF1B9.2020008@redhat.com> Message-ID: <561CFC9D.3020107@redhat.com> Not a container expert either, but: I think it's standard practice for containers to be non-persistent (i.e. no persistent state), so you'd need an external ES instance. or set the ES data-store to be on a data volume (which is persistent). Regards, Marc On 13/10/2015 12:57, Eric Wittmann wrote: > Hm. Without digging into it, I'm not sure what to suggest. I'm also > not a docker expert by any stretch, so that complicates things. :) > > I can tell you that the default elasticsearch instance that comes with > the apiman quickstart stores data in the standalone/data/es directory. > You could perhaps poke around that area. See if data is getting written > there, and whether it's still there when you restart the container? > > -Eric > > > On 10/13/2015 7:37 AM, Tim Dudgeon wrote: > > Right now I'm using the ES that's bundled with Apiman (though do intend > > to switch to a separate container). > > The baffling thing is that with the Docker image on Dockerhub > > (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised > > version (with Keycloak and Postgres currently as separate containers) it > > fails. The APIMan and ES parts are still pretty well the same as the > > jboss/apiman-wildfly image. > > > > So I seem to have messed something up, but don't have much of an idea as > > to what. > > > > Tim > > > > On 13/10/2015 12:23, Eric Wittmann wrote: > >> When a service is published to the gateway, that configuration is > >> saved in the gateway's persistent registry. By default (in the latest > >> version of apiman) the gateway uses elasticsearch to store its > >> registry information. So ideally you should run elasticsearch as a > >> separate docker container, making sure that you have an appropriate > >> persistent volume attached so that any data added to ES survives a > >> docker restart. Then you can configure apiman to use that external ES. > >> > >> There is documentation in the Installation Guide that explains how to > >> use an external elasticsearch cluster. > >> > >> -Eric > >> > >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: > >>> I'm hitting a problem where I'm running apiman in a docker container. > >>> When I first set up a public service it runs fine. > >>> But when I restart the container the service definition is still there, > >>> but the gateway does not respond to requests for the service. If I > >>> create a new version of the service and publish it then it works fine. > >>> > >>> Seems like the service definition is not being published to the gateway > >>> after a restart? > >>> I've tried it with the basic Docker container similar to > >>> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so it looks > >>> like its something I've done to cause this, but I don't see any errors > >>> and don't know where to look to try to fix it. > >>> Any ideas what's wrong? > >>> This is with version 1.1.8.Final. > >>> > >>> Tim > >>> > >>> _______________________________________________ > >>> 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 tdudgeon.ml at gmail.com Tue Oct 13 08:45:34 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Tue, 13 Oct 2015 13:45:34 +0100 Subject: [Apiman-user] Invalid token signature In-Reply-To: <561CFBDA.3010008@redhat.com> References: <561CD74B.60408@gmail.com> <561CDAEF.1000409@gmail.com> <561CFBDA.3010008@redhat.com> Message-ID: <561CFCEE.9000801@gmail.com> It was unintentional. I had failed to remove the authentication from one place when I added it to another. On 13/10/2015 13:40, Marc Savy wrote: > Interesting situation - was it intentional? > > On 13/10/2015 11:20, Tim Dudgeon wrote: >> I tracked it down eventually - I had OAuth authentication at 2 places in >> the chain which seems to be the cause or the error. >> >> Tim >> >> On 13/10/2015 11:04, Tim Dudgeon wrote: >> > Hi, I'm trying to access a service though an application and plan, >> > using OAuth authentication at the application level and authorization >> > at the service level (requiring a role assigned to the user during >> > authentication). >> > I thought I had it all set up correctly, but am getting an Invalid >> > token signature error. >> > >> > I generate access token like this: >> > >> > $ curl -X POST >> > >> http://192.168.59.103:8080/auth/realms/Organization1/protocol/openid-connect/token >> > -H "Content-Type: application/x-www-form-urlencoded" -d >> > 'username=user1' -d 'password=user1' -d 'grant_type=password' -d >> > 'client_id=app1' -s | jq -r '.access_token' >> > >> > and get an access token like this: >> > >> > eyJhb >> > >> > Then try to access the service like this: >> > >> > $ curl -k -H "Authorization: Bearer eyJhb" -H "X-API-Key: >> > bb9eb966-" -s >> > https://192.168.59.103:8443/apiman-gateway/Organization2/echo/1.5/ >> > >> > And I get this error: >> > >> > >> {"type":"Authentication","failureCode":11004,"responseCode":401,"message":"Invalid >> > token signature.","headers":{}} >> > >> > >> > Any ideas what the Invalid token signature error relates to? >> > >> > Thanks >> > Tim >> > >> >> _______________________________________________ >> Apiman-user mailing list >> Apiman-user at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/apiman-user >> > From tdudgeon.ml at gmail.com Tue Oct 13 09:48:13 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Tue, 13 Oct 2015 14:48:13 +0100 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561CFC9D.3020107@redhat.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> <561CF1B9.2020008@redhat.com> <561CFC9D.3020107@redhat.com> Message-ID: <561D0B9D.90006@gmail.com> If you restart a container it will contain the same state as when it was stopped. If you were to create a new container from the image it would of course not contain the state of other containers created from that image (unless you were re-using volumes). And with the jboss/apiman-wildfly image its working OK. I stop the container and restart it and the gateway is configured. But in my image, adapted from that image the gateway looses it configuration, so its clearly something I've done. I just don't know what. What I've discovered so far is that when restarted ES contains information in the apiman_manger index but has lost all info in the apiman_gateway index. Tim On 13/10/2015 13:44, Marc Savy wrote: > Not a container expert either, but: > > I think it's standard practice for containers to be non-persistent > (i.e. no persistent state), so you'd need an external ES instance. or > set the ES data-store to be on a data volume (which is persistent). > > Regards, > Marc > > On 13/10/2015 12:57, Eric Wittmann wrote: >> Hm. Without digging into it, I'm not sure what to suggest. I'm also >> not a docker expert by any stretch, so that complicates things. :) >> >> I can tell you that the default elasticsearch instance that comes with >> the apiman quickstart stores data in the standalone/data/es directory. >> You could perhaps poke around that area. See if data is getting written >> there, and whether it's still there when you restart the container? >> >> -Eric >> >> >> On 10/13/2015 7:37 AM, Tim Dudgeon wrote: >> > Right now I'm using the ES that's bundled with Apiman (though do >> intend >> > to switch to a separate container). >> > The baffling thing is that with the Docker image on Dockerhub >> > (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised >> > version (with Keycloak and Postgres currently as separate >> containers) it >> > fails. The APIMan and ES parts are still pretty well the same as the >> > jboss/apiman-wildfly image. >> > >> > So I seem to have messed something up, but don't have much of an >> idea as >> > to what. >> > >> > Tim >> > >> > On 13/10/2015 12:23, Eric Wittmann wrote: >> >> When a service is published to the gateway, that configuration is >> >> saved in the gateway's persistent registry. By default (in the >> latest >> >> version of apiman) the gateway uses elasticsearch to store its >> >> registry information. So ideally you should run elasticsearch as a >> >> separate docker container, making sure that you have an appropriate >> >> persistent volume attached so that any data added to ES survives a >> >> docker restart. Then you can configure apiman to use that >> external ES. >> >> >> >> There is documentation in the Installation Guide that explains how to >> >> use an external elasticsearch cluster. >> >> >> >> -Eric >> >> >> >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: >> >>> I'm hitting a problem where I'm running apiman in a docker >> container. >> >>> When I first set up a public service it runs fine. >> >>> But when I restart the container the service definition is still >> there, >> >>> but the gateway does not respond to requests for the service. If I >> >>> create a new version of the service and publish it then it works >> fine. >> >>> >> >>> Seems like the service definition is not being published to the >> gateway >> >>> after a restart? >> >>> I've tried it with the basic Docker container similar to >> >>> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so >> it looks >> >>> like its something I've done to cause this, but I don't see any >> errors >> >>> and don't know where to look to try to fix it. >> >>> Any ideas what's wrong? >> >>> This is with version 1.1.8.Final. >> >>> >> >>> Tim >> >>> >> >>> _______________________________________________ >> >>> 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 eric.wittmann at redhat.com Tue Oct 13 09:50:18 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 13 Oct 2015 09:50:18 -0400 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561D0B9D.90006@gmail.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> <561CF1B9.2020008@redhat.com> <561CFC9D.3020107@redhat.com> <561D0B9D.90006@gmail.com> Message-ID: <561D0C1A.9050305@redhat.com> Since you have to do it anyway, I'd suggest going with an external elasticsearch instance. It's easy to hook apiman up to it. It's just a couple properties in apiman.properties. -eric On 10/13/2015 9:48 AM, Tim Dudgeon wrote: > If you restart a container it will contain the same state as when it was > stopped. > If you were to create a new container from the image it would of course > not contain the state of other containers created from that image > (unless you were re-using volumes). > > And with the jboss/apiman-wildfly image its working OK. I stop the > container and restart it and the gateway is configured. > But in my image, adapted from that image the gateway looses it > configuration, so its clearly something I've done. I just don't know what. > > What I've discovered so far is that when restarted ES contains > information in the apiman_manger index but has lost all info in the > apiman_gateway index. > > Tim > > > On 13/10/2015 13:44, Marc Savy wrote: >> Not a container expert either, but: >> >> I think it's standard practice for containers to be non-persistent >> (i.e. no persistent state), so you'd need an external ES instance. or >> set the ES data-store to be on a data volume (which is persistent). >> >> Regards, >> Marc >> >> On 13/10/2015 12:57, Eric Wittmann wrote: >>> Hm. Without digging into it, I'm not sure what to suggest. I'm also >>> not a docker expert by any stretch, so that complicates things. :) >>> >>> I can tell you that the default elasticsearch instance that comes with >>> the apiman quickstart stores data in the standalone/data/es directory. >>> You could perhaps poke around that area. See if data is getting written >>> there, and whether it's still there when you restart the container? >>> >>> -Eric >>> >>> >>> On 10/13/2015 7:37 AM, Tim Dudgeon wrote: >>> > Right now I'm using the ES that's bundled with Apiman (though do >>> intend >>> > to switch to a separate container). >>> > The baffling thing is that with the Docker image on Dockerhub >>> > (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised >>> > version (with Keycloak and Postgres currently as separate >>> containers) it >>> > fails. The APIMan and ES parts are still pretty well the same as the >>> > jboss/apiman-wildfly image. >>> > >>> > So I seem to have messed something up, but don't have much of an >>> idea as >>> > to what. >>> > >>> > Tim >>> > >>> > On 13/10/2015 12:23, Eric Wittmann wrote: >>> >> When a service is published to the gateway, that configuration is >>> >> saved in the gateway's persistent registry. By default (in the >>> latest >>> >> version of apiman) the gateway uses elasticsearch to store its >>> >> registry information. So ideally you should run elasticsearch as a >>> >> separate docker container, making sure that you have an appropriate >>> >> persistent volume attached so that any data added to ES survives a >>> >> docker restart. Then you can configure apiman to use that >>> external ES. >>> >> >>> >> There is documentation in the Installation Guide that explains how to >>> >> use an external elasticsearch cluster. >>> >> >>> >> -Eric >>> >> >>> >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: >>> >>> I'm hitting a problem where I'm running apiman in a docker >>> container. >>> >>> When I first set up a public service it runs fine. >>> >>> But when I restart the container the service definition is still >>> there, >>> >>> but the gateway does not respond to requests for the service. If I >>> >>> create a new version of the service and publish it then it works >>> fine. >>> >>> >>> >>> Seems like the service definition is not being published to the >>> gateway >>> >>> after a restart? >>> >>> I've tried it with the basic Docker container similar to >>> >>> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so >>> it looks >>> >>> like its something I've done to cause this, but I don't see any >>> errors >>> >>> and don't know where to look to try to fix it. >>> >>> Any ideas what's wrong? >>> >>> This is with version 1.1.8.Final. >>> >>> >>> >>> Tim >>> >>> >>> >>> _______________________________________________ >>> >>> 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 tdudgeon.ml at gmail.com Wed Oct 14 05:54:58 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Wed, 14 Oct 2015 10:54:58 +0100 Subject: [Apiman-user] problems adding users Message-ID: <561E2672.8050408@gmail.com> I'm having difficulty adding users to an organisation. I add the user to the apiman realm in keycloak, but that new user is not recognised in the list that apiman presents when adding a member to an organisation. I think the new user has had the same roles added (including realm-management) as the admin user. In one case I did get one new user recognised after a server restart, but even that doesn't seem to work consistently. Also noticed that if I change the email of the admin user in keycloak that change is not reflected in apiman. I've tried turning off the user cache in keycloak for the realm (using the UI), but that makes no difference. I'm using a standalone keycloak server, but suspect that makes no difference. Is there some additional caching going on here? Tim From tdudgeon.ml at gmail.com Wed Oct 14 05:57:48 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Wed, 14 Oct 2015 10:57:48 +0100 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561D0C1A.9050305@redhat.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> <561CF1B9.2020008@redhat.com> <561CFC9D.3020107@redhat.com> <561D0B9D.90006@gmail.com> <561D0C1A.9050305@redhat.com> Message-ID: <561E271C.1040300@gmail.com> OK, I tried that and now the gateway is working after a restart. I have no idea why is didn't work when running with the built in ES. Now one more question - how to disable the ES within apiman (I mean stop it running, not reconfigure the connection)? Tim On 13/10/2015 14:50, Eric Wittmann wrote: > Since you have to do it anyway, I'd suggest going with an external > elasticsearch instance. It's easy to hook apiman up to it. It's just > a couple properties in apiman.properties. > > -eric > > On 10/13/2015 9:48 AM, Tim Dudgeon wrote: >> If you restart a container it will contain the same state as when it was >> stopped. >> If you were to create a new container from the image it would of course >> not contain the state of other containers created from that image >> (unless you were re-using volumes). >> >> And with the jboss/apiman-wildfly image its working OK. I stop the >> container and restart it and the gateway is configured. >> But in my image, adapted from that image the gateway looses it >> configuration, so its clearly something I've done. I just don't know >> what. >> >> What I've discovered so far is that when restarted ES contains >> information in the apiman_manger index but has lost all info in the >> apiman_gateway index. >> >> Tim >> >> >> On 13/10/2015 13:44, Marc Savy wrote: >>> Not a container expert either, but: >>> >>> I think it's standard practice for containers to be non-persistent >>> (i.e. no persistent state), so you'd need an external ES instance. or >>> set the ES data-store to be on a data volume (which is persistent). >>> >>> Regards, >>> Marc >>> >>> On 13/10/2015 12:57, Eric Wittmann wrote: >>>> Hm. Without digging into it, I'm not sure what to suggest. I'm also >>>> not a docker expert by any stretch, so that complicates things. :) >>>> >>>> I can tell you that the default elasticsearch instance that comes with >>>> the apiman quickstart stores data in the standalone/data/es directory. >>>> You could perhaps poke around that area. See if data is getting >>>> written >>>> there, and whether it's still there when you restart the container? >>>> >>>> -Eric >>>> >>>> >>>> On 10/13/2015 7:37 AM, Tim Dudgeon wrote: >>>> > Right now I'm using the ES that's bundled with Apiman (though do >>>> intend >>>> > to switch to a separate container). >>>> > The baffling thing is that with the Docker image on Dockerhub >>>> > (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised >>>> > version (with Keycloak and Postgres currently as separate >>>> containers) it >>>> > fails. The APIMan and ES parts are still pretty well the same as the >>>> > jboss/apiman-wildfly image. >>>> > >>>> > So I seem to have messed something up, but don't have much of an >>>> idea as >>>> > to what. >>>> > >>>> > Tim >>>> > >>>> > On 13/10/2015 12:23, Eric Wittmann wrote: >>>> >> When a service is published to the gateway, that configuration is >>>> >> saved in the gateway's persistent registry. By default (in the >>>> latest >>>> >> version of apiman) the gateway uses elasticsearch to store its >>>> >> registry information. So ideally you should run elasticsearch as a >>>> >> separate docker container, making sure that you have an appropriate >>>> >> persistent volume attached so that any data added to ES survives a >>>> >> docker restart. Then you can configure apiman to use that >>>> external ES. >>>> >> >>>> >> There is documentation in the Installation Guide that explains >>>> how to >>>> >> use an external elasticsearch cluster. >>>> >> >>>> >> -Eric >>>> >> >>>> >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: >>>> >>> I'm hitting a problem where I'm running apiman in a docker >>>> container. >>>> >>> When I first set up a public service it runs fine. >>>> >>> But when I restart the container the service definition is still >>>> there, >>>> >>> but the gateway does not respond to requests for the service. If I >>>> >>> create a new version of the service and publish it then it works >>>> fine. >>>> >>> >>>> >>> Seems like the service definition is not being published to the >>>> gateway >>>> >>> after a restart? >>>> >>> I've tried it with the basic Docker container similar to >>>> >>> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so >>>> it looks >>>> >>> like its something I've done to cause this, but I don't see any >>>> errors >>>> >>> and don't know where to look to try to fix it. >>>> >>> Any ideas what's wrong? >>>> >>> This is with version 1.1.8.Final. >>>> >>> >>>> >>> Tim >>>> >>> >>>> >>> _______________________________________________ >>>> >>> 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 tdudgeon.ml at gmail.com Wed Oct 14 06:24:10 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Wed, 14 Oct 2015 11:24:10 +0100 Subject: [Apiman-user] Dockerised environment github project Message-ID: <561E2D4A.400@gmail.com> Hi all, I've been working on a fully Dockerised implementation for apiman, with all key parts running as separate Docker containers, with the view to generating a setup that is suitable for production use. Its very much work in progress at present and a long way off being suitable for production use, but if anyone is interested in taking a look and providing feedback then that would be great. You can find it on github here: https://github.com/tdudgeon/apiman-site Thanks to all on this list and the keycloak list in helping me get this far. Tim From jcechace at gmail.com Wed Oct 14 06:35:06 2015 From: jcechace at gmail.com (=?UTF-8?B?SmFrdWIgxIxlY2jDocSNZWs=?=) Date: Wed, 14 Oct 2015 12:35:06 +0200 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: <561E271C.1040300@gmail.com> References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> <561CF1B9.2020008@redhat.com> <561CFC9D.3020107@redhat.com> <561D0B9D.90006@gmail.com> <561D0C1A.9050305@redhat.com> <561E271C.1040300@gmail.com> Message-ID: Hello, rm ${APIMAN_HOME}/standalone/deployments/apiman-es.war Removing the deployment is all you need to do. Jakub. On Wed, Oct 14, 2015 at 11:57 AM, Tim Dudgeon wrote: > OK, I tried that and now the gateway is working after a restart. > I have no idea why is didn't work when running with the built in ES. > > Now one more question - how to disable the ES within apiman (I mean stop > it running, not reconfigure the connection)? > > Tim > > On 13/10/2015 14:50, Eric Wittmann wrote: > > Since you have to do it anyway, I'd suggest going with an external > > elasticsearch instance. It's easy to hook apiman up to it. It's just > > a couple properties in apiman.properties. > > > > -eric > > > > On 10/13/2015 9:48 AM, Tim Dudgeon wrote: > >> If you restart a container it will contain the same state as when it was > >> stopped. > >> If you were to create a new container from the image it would of course > >> not contain the state of other containers created from that image > >> (unless you were re-using volumes). > >> > >> And with the jboss/apiman-wildfly image its working OK. I stop the > >> container and restart it and the gateway is configured. > >> But in my image, adapted from that image the gateway looses it > >> configuration, so its clearly something I've done. I just don't know > >> what. > >> > >> What I've discovered so far is that when restarted ES contains > >> information in the apiman_manger index but has lost all info in the > >> apiman_gateway index. > >> > >> Tim > >> > >> > >> On 13/10/2015 13:44, Marc Savy wrote: > >>> Not a container expert either, but: > >>> > >>> I think it's standard practice for containers to be non-persistent > >>> (i.e. no persistent state), so you'd need an external ES instance. or > >>> set the ES data-store to be on a data volume (which is persistent). > >>> > >>> Regards, > >>> Marc > >>> > >>> On 13/10/2015 12:57, Eric Wittmann wrote: > >>>> Hm. Without digging into it, I'm not sure what to suggest. I'm also > >>>> not a docker expert by any stretch, so that complicates things. :) > >>>> > >>>> I can tell you that the default elasticsearch instance that comes with > >>>> the apiman quickstart stores data in the standalone/data/es directory. > >>>> You could perhaps poke around that area. See if data is getting > >>>> written > >>>> there, and whether it's still there when you restart the container? > >>>> > >>>> -Eric > >>>> > >>>> > >>>> On 10/13/2015 7:37 AM, Tim Dudgeon wrote: > >>>> > Right now I'm using the ES that's bundled with Apiman (though do > >>>> intend > >>>> > to switch to a separate container). > >>>> > The baffling thing is that with the Docker image on Dockerhub > >>>> > (jboss/apiman-wildfly) it restarts OK, but with my partly Dockerised > >>>> > version (with Keycloak and Postgres currently as separate > >>>> containers) it > >>>> > fails. The APIMan and ES parts are still pretty well the same as the > >>>> > jboss/apiman-wildfly image. > >>>> > > >>>> > So I seem to have messed something up, but don't have much of an > >>>> idea as > >>>> > to what. > >>>> > > >>>> > Tim > >>>> > > >>>> > On 13/10/2015 12:23, Eric Wittmann wrote: > >>>> >> When a service is published to the gateway, that configuration is > >>>> >> saved in the gateway's persistent registry. By default (in the > >>>> latest > >>>> >> version of apiman) the gateway uses elasticsearch to store its > >>>> >> registry information. So ideally you should run elasticsearch as a > >>>> >> separate docker container, making sure that you have an appropriate > >>>> >> persistent volume attached so that any data added to ES survives a > >>>> >> docker restart. Then you can configure apiman to use that > >>>> external ES. > >>>> >> > >>>> >> There is documentation in the Installation Guide that explains > >>>> how to > >>>> >> use an external elasticsearch cluster. > >>>> >> > >>>> >> -Eric > >>>> >> > >>>> >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: > >>>> >>> I'm hitting a problem where I'm running apiman in a docker > >>>> container. > >>>> >>> When I first set up a public service it runs fine. > >>>> >>> But when I restart the container the service definition is still > >>>> there, > >>>> >>> but the gateway does not respond to requests for the service. If I > >>>> >>> create a new version of the service and publish it then it works > >>>> fine. > >>>> >>> > >>>> >>> Seems like the service definition is not being published to the > >>>> gateway > >>>> >>> after a restart? > >>>> >>> I've tried it with the basic Docker container similar to > >>>> >>> jboss/apiman-wildfly on Dockerhub and it seems OK with that, so > >>>> it looks > >>>> >>> like its something I've done to cause this, but I don't see any > >>>> errors > >>>> >>> and don't know where to look to try to fix it. > >>>> >>> Any ideas what's wrong? > >>>> >>> This is with version 1.1.8.Final. > >>>> >>> > >>>> >>> Tim > >>>> >>> > >>>> >>> _______________________________________________ > >>>> >>> 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 > >>>> > >>> > >> > > _______________________________________________ > 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/20151014/c409a7b0/attachment.html From jcechace at gmail.com Wed Oct 14 07:27:24 2015 From: jcechace at gmail.com (=?UTF-8?B?SmFrdWIgxIxlY2jDocSNZWs=?=) Date: Wed, 14 Oct 2015 13:27:24 +0200 Subject: [Apiman-user] Dockerised environment github project In-Reply-To: <561E2D4A.400@gmail.com> References: <561E2D4A.400@gmail.com> Message-ID: Hi, this is great -- very useful. Thanks for sharing! What I would change is maybe swapping your postgress image for one based on the official postgress dockerfile. Alternatively I would suggest using centos in order to keep al the parts based on the same system (jboss images are using centos). Jakub. On Wed, Oct 14, 2015 at 12:24 PM, Tim Dudgeon wrote: > Hi all, > > I've been working on a fully Dockerised implementation for apiman, with > all key parts running as separate Docker containers, with the view to > generating a setup that is suitable for production use. > > Its very much work in progress at present and a long way off being > suitable for production use, but if anyone is interested in taking a > look and providing feedback then that would be great. You can find it on > github here: > https://github.com/tdudgeon/apiman-site > > Thanks to all on this list and the keycloak list in helping me get this > far. > > Tim > _______________________________________________ > 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/20151014/336d1643/attachment.html From eric.wittmann at redhat.com Wed Oct 14 07:42:09 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 14 Oct 2015 07:42:09 -0400 Subject: [Apiman-user] problems adding users In-Reply-To: <561E2672.8050408@gmail.com> References: <561E2672.8050408@gmail.com> Message-ID: <561E3F91.7050804@redhat.com> Unfortunately the user would need to log into apiman at least once before she can be added as a member of an organization. We have some improvements to make in this area going forward. On 10/14/2015 5:54 AM, Tim Dudgeon wrote: > I'm having difficulty adding users to an organisation. > I add the user to the apiman realm in keycloak, but that new user is not > recognised in the list that apiman presents when adding a member to an > organisation. > I think the new user has had the same roles added (including > realm-management) as the admin user. > In one case I did get one new user recognised after a server restart, > but even that doesn't seem to work consistently. > Also noticed that if I change the email of the admin user in keycloak > that change is not reflected in apiman. > I've tried turning off the user cache in keycloak for the realm (using > the UI), but that makes no difference. > I'm using a standalone keycloak server, but suspect that makes no > difference. > > Is there some additional caching going on here? > > Tim > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From eric.wittmann at redhat.com Wed Oct 14 07:42:30 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 14 Oct 2015 07:42:30 -0400 Subject: [Apiman-user] service not being published to gateway after restart? In-Reply-To: References: <561A4865.8090009@gmail.com> <561CE9CE.8090109@redhat.com> <561CED11.2060305@gmail.com> <561CF1B9.2020008@redhat.com> <561CFC9D.3020107@redhat.com> <561D0B9D.90006@gmail.com> <561D0C1A.9050305@redhat.com> <561E271C.1040300@gmail.com> Message-ID: <561E3FA6.802@redhat.com> +1 On 10/14/2015 6:35 AM, Jakub ?ech??ek wrote: > Hello, > > rm ${APIMAN_HOME}/standalone/deployments/apiman-es.war > > Removing the deployment is all you need to do. > > Jakub. > > On Wed, Oct 14, 2015 at 11:57 AM, Tim Dudgeon > wrote: > > OK, I tried that and now the gateway is working after a restart. > I have no idea why is didn't work when running with the built in ES. > > Now one more question - how to disable the ES within apiman (I mean stop > it running, not reconfigure the connection)? > > Tim > > On 13/10/2015 14:50, Eric Wittmann wrote: > > Since you have to do it anyway, I'd suggest going with an external > > elasticsearch instance. It's easy to hook apiman up to it. It's > just > > a couple properties in apiman.properties. > > > > -eric > > > > On 10/13/2015 9:48 AM, Tim Dudgeon wrote: > >> If you restart a container it will contain the same state as > when it was > >> stopped. > >> If you were to create a new container from the image it would of > course > >> not contain the state of other containers created from that image > >> (unless you were re-using volumes). > >> > >> And with the jboss/apiman-wildfly image its working OK. I stop the > >> container and restart it and the gateway is configured. > >> But in my image, adapted from that image the gateway looses it > >> configuration, so its clearly something I've done. I just don't know > >> what. > >> > >> What I've discovered so far is that when restarted ES contains > >> information in the apiman_manger index but has lost all info in the > >> apiman_gateway index. > >> > >> Tim > >> > >> > >> On 13/10/2015 13:44, Marc Savy wrote: > >>> Not a container expert either, but: > >>> > >>> I think it's standard practice for containers to be non-persistent > >>> (i.e. no persistent state), so you'd need an external ES > instance. or > >>> set the ES data-store to be on a data volume (which is persistent). > >>> > >>> Regards, > >>> Marc > >>> > >>> On 13/10/2015 12:57, Eric Wittmann wrote: > >>>> Hm. Without digging into it, I'm not sure what to suggest. > I'm also > >>>> not a docker expert by any stretch, so that complicates things. :) > >>>> > >>>> I can tell you that the default elasticsearch instance that > comes with > >>>> the apiman quickstart stores data in the standalone/data/es > directory. > >>>> You could perhaps poke around that area. See if data is getting > >>>> written > >>>> there, and whether it's still there when you restart the > container? > >>>> > >>>> -Eric > >>>> > >>>> > >>>> On 10/13/2015 7:37 AM, Tim Dudgeon wrote: > >>>> > Right now I'm using the ES that's bundled with Apiman (though do > >>>> intend > >>>> > to switch to a separate container). > >>>> > The baffling thing is that with the Docker image on Dockerhub > >>>> > (jboss/apiman-wildfly) it restarts OK, but with my partly > Dockerised > >>>> > version (with Keycloak and Postgres currently as separate > >>>> containers) it > >>>> > fails. The APIMan and ES parts are still pretty well the > same as the > >>>> > jboss/apiman-wildfly image. > >>>> > > >>>> > So I seem to have messed something up, but don't have much of an > >>>> idea as > >>>> > to what. > >>>> > > >>>> > Tim > >>>> > > >>>> > On 13/10/2015 12:23, Eric Wittmann wrote: > >>>> >> When a service is published to the gateway, that > configuration is > >>>> >> saved in the gateway's persistent registry. By default (in the > >>>> latest > >>>> >> version of apiman) the gateway uses elasticsearch to store its > >>>> >> registry information. So ideally you should run > elasticsearch as a > >>>> >> separate docker container, making sure that you have an > appropriate > >>>> >> persistent volume attached so that any data added to ES > survives a > >>>> >> docker restart. Then you can configure apiman to use that > >>>> external ES. > >>>> >> > >>>> >> There is documentation in the Installation Guide that explains > >>>> how to > >>>> >> use an external elasticsearch cluster. > >>>> >> > >>>> >> -Eric > >>>> >> > >>>> >> On 10/11/2015 7:30 AM, Tim Dudgeon wrote: > >>>> >>> I'm hitting a problem where I'm running apiman in a docker > >>>> container. > >>>> >>> When I first set up a public service it runs fine. > >>>> >>> But when I restart the container the service definition is > still > >>>> there, > >>>> >>> but the gateway does not respond to requests for the > service. If I > >>>> >>> create a new version of the service and publish it then it > works > >>>> fine. > >>>> >>> > >>>> >>> Seems like the service definition is not being published > to the > >>>> gateway > >>>> >>> after a restart? > >>>> >>> I've tried it with the basic Docker container similar to > >>>> >>> jboss/apiman-wildfly on Dockerhub and it seems OK with > that, so > >>>> it looks > >>>> >>> like its something I've done to cause this, but I don't > see any > >>>> errors > >>>> >>> and don't know where to look to try to fix it. > >>>> >>> Any ideas what's wrong? > >>>> >>> This is with version 1.1.8.Final. > >>>> >>> > >>>> >>> Tim > >>>> >>> > >>>> >>> _______________________________________________ > >>>> >>> 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 > >>>> > >>> > >> > > _______________________________________________ > 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 ryordan at redhat.com Wed Oct 14 08:54:13 2015 From: ryordan at redhat.com (Rachel Yordan) Date: Wed, 14 Oct 2015 08:54:13 -0400 Subject: [Apiman-user] apiman suitable for managing end users? In-Reply-To: <561CF1E9.9080503@redhat.com> References: <55AB8DC8.7070901@gmail.com> <55ACBADB.3040102@redhat.com> <55B0E867.1050602@gmail.com> <55B0ED64.2020505@redhat.com> <5617F4F9.6080800@gmail.com> <5617FFBF.2090006@redhat.com> <561800DC.6070206@gmail.com> <56180353.6090801@redhat.com> <5618DCC7.2090501@gmail.com> <56191D06.5050700@redhat.com> <561CF1E9.9080503@redhat.com> Message-ID: +1 Late here, but I second this. Great idea Jakub! On Tue, Oct 13, 2015 at 7:58 AM, Eric Wittmann wrote: > +1 to this idea. > > @Jakub - can you add a jira feature request for this? > > On 10/10/2015 10:20 AM, Jakub ?ech??ek wrote: > > Hi, > > > > > I'm also toying around with the idea of pre-installing some of the > >> plugins so they are automatically included in the apiman quickstart. > > > > A nice approach to this would be a post-install "setup wizard" when the > > UI is first entered. This would enable user to add the seed data and > > possibly enable additional plugins. > > > > Jakub. > > > > On Sat, Oct 10, 2015 at 4:13 PM, Eric Wittmann > > wrote: > > > > Funny you should suggest that - the plugins will be *much* easier to > > install in version 1.2.x because there is a UI which lists all the > > available "official" apiman plugins. Of course you can also still > > install your own plugin via the UI. > > > > I'm also toying around with the idea of pre-installing some of the > > plugins so they are automatically included in the apiman quickstart. > > > > -Eric > > > > On 10/10/2015 5:39 AM, Tim Dudgeon wrote: > > > Yes, indeed I was looking at the wrong policy. > > > The Keycloak OAuth Policy looks exactly what I need and the blog > post > > > describes it well. > > > You should make those non-bundled policies more visible! > > > > > > Tim > > > > > > On 09/10/2015 19:11, Eric Wittmann wrote: > > >> Perhaps you are looking at the wrong policy. The one you want > > to use > > >> is the Keycloak OAuth Policy, which is available if you install > the > > >> appropriate keycloak plugin. A blog post about it can be found > > here: > > >> > > >> > > > http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html > > >> > > >> > > >> The Authorization policy only does role-based access control, not > > >> OAuth authentication. The Keycloak OAuth policy should be > > configured > > >> first, and then the roles found in the bearer token will get > > passed to > > >> the Authorization policy, which should be configured 2nd. > > >> > > >> -Eric > > >> > > >> On 10/9/2015 2:01 PM, Tim Dudgeon wrote: > > >>> Yes, but I don't see how a different realm/server this can be > > configured > > >>> with the current Authorization policy. > > >>> Is this possible? > > >>> > > >>> Tim > > >>> > > >>> On 09/10/2015 18:56, Eric Wittmann wrote: > > >>>> I would argue that using some *other* realm (NOT the apiman > > realm) is > > >>>> the more sensible thing to do. > > >>>> > > >>>> In fact, I might go so far as to suggest a second keycloak > server > > >>>> would make more logical sense than using the apiman one. Of > > course, > > >>>> practically speaking it makes sense to just have one KC > > server. But > > >>>> definitely I think you want to create other realms - and one > > realm per > > >>>> organization is a very sensible approach. > > >>>> > > >>>> -Eric > > >>>> > > >>>> On 10/9/2015 1:10 PM, Tim Dudgeon wrote: > > >>>>> Picking up on this again, you mentioned OAuth2 authentication. > > >>>>> By this I'm assuming you mean what's listed as "Authorization > > >>>>> policy" in > > >>>>> the available policies, and this authenticates against the > apiman > > >>>>> realm > > >>>>> in keycloak. > > >>>>> > > >>>>> Is it possible/desirable to allow a different realm to be > > configured > > >>>>> here? The idea being that an organisation could create a > > policy that > > >>>>> authenticates against a realm configured for that > > organisation (maybe > > >>>>> using its own LDAP server etc.). This way an organisation can > > >>>>> configure > > >>>>> usage for all its users without them needing to be apiman > users? > > >>>>> > > >>>>> Tim > > >>>>> > > >>>>> On 23/07/2015 14:34, Eric Wittmann wrote: > > >>>>>> +1 thanks. > > >>>>>> > > >>>>>> On 7/23/2015 9:13 AM, Tim Dudgeon wrote: > > >>>>>>> No further comments so I created an issue for this: > > >>>>>>> https://issues.jboss.org/browse/APIMAN-569 > > >>>>>>> > > >>>>>>> On 20/07/2015 10:09, Eric Wittmann wrote: > > >>>>>>>> Hi Tim. > > >>>>>>>> > > >>>>>>>> Interesting scenario. The typical scenario is that the > apiman > > >>>>>>>> UI is > > >>>>>>>> only used by service providers and application developers. > End > > >>>>>>>> users > > >>>>>>>> will typically not use the apiman UI. However, that > > doesn't mean > > >>>>>>>> apiman can't track end users. If authentication is > > enabled (either > > >>>>>>>> BASIC or OAuth2), then rate limiting can be configured on a > > >>>>>>>> per-user > > >>>>>>>> basis. When you configure the rate limit policy, you can > > choose > > >>>>>>>> "user" as an option and then provide the HTTP header > > containing the > > >>>>>>>> user. When configuring the authentication policy (which > > must come > > >>>>>>>> first in the policy chain) you would need to enable > forwarding > > >>>>>>>> of the > > >>>>>>>> username. > > >>>>>>>> > > >>>>>>>> In addition, the next version of apiman will also include > the > > >>>>>>>> authenticated user in the metrics data. This would allow > > you to > > >>>>>>>> query > > >>>>>>>> the elasticsearch metrics information by username. We > won't > > >>>>>>>> have any > > >>>>>>>> specific support in the UI for breaking down metrics by > > user, at > > >>>>>>>> least > > >>>>>>>> not right away, but it will be in the data at least. > > >>>>>>>> > > >>>>>>>> Of course, you *can* use apiman the way you are > > suggesting. But as > > >>>>>>>> you observed there are some challenges. We don't > > currently have a > > >>>>>>>> way > > >>>>>>>> to assign roles to users automatically when they > register. It > > >>>>>>>> would > > >>>>>>>> need to be a feature request I think: > > >>>>>>>> > > >>>>>>>> https://issues.jboss.org/browse/APIMAN > > >>>>>>>> > > >>>>>>>> I think if we added a very generic "user registration" > > extension > > >>>>>>>> point > > >>>>>>>> to apiman, then you could write your own custom handler to > do > > >>>>>>>> whatever > > >>>>>>>> you want. Such a handler would be invoked the first time > > a new > > >>>>>>>> user > > >>>>>>>> logged into apiman. You could drive off their email > address, > > >>>>>>>> roles, > > >>>>>>>> whatever. You could also provide a handler via a plugin. > > >>>>>>>> > > >>>>>>>> Thoughts? :) > > >>>>>>>> > > >>>>>>>> -Eric > > >>>>>>>> > > >>>>>>>> > > >>>>>>>> On 7/19/2015 7:45 AM, Tim Dudgeon wrote: > > >>>>>>>>> Hi > > >>>>>>>>> > > >>>>>>>>> I've been looking into apiman and like what I see, but > have a > > >>>>>>>>> conceptual > > >>>>>>>>> question about its usage. > > >>>>>>>>> I need something to manage the end users of my > > applications, not > > >>>>>>>>> just > > >>>>>>>>> the people who are developing and managing those > > applications. Is > > >>>>>>>>> apiman > > >>>>>>>>> suitable for this? e.g. each actual user of the > > applications would > > >>>>>>>>> register to apiman and use their own access keys. I need > > this as I > > >>>>>>>>> will > > >>>>>>>>> want to handle metrics and usage on the level of the > > individual > > >>>>>>>>> user. > > >>>>>>>>> > > >>>>>>>>> Also, if this was to be a sensible approach how does one > > >>>>>>>>> configure the > > >>>>>>>>> registration process. I understand apiman is using > > keycloak for > > >>>>>>>>> this, > > >>>>>>>>> but I see no link in the UI to configure keycloak. And I > > would > > >>>>>>>>> need a > > >>>>>>>>> way that new users could automatically be assigned to an > > >>>>>>>>> organisation > > >>>>>>>>> (e.g. a default organisation, or a specific one based on > > their > > >>>>>>>>> email > > >>>>>>>>> address). > > >>>>>>>>> > > >>>>>>>>> Tim > > >>>>>>>>> _______________________________________________ > > >>>>>>>>> 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 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 > > > > > _______________________________________________ > > 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/20151014/80a9bba3/attachment-0001.html From tdudgeon.ml at gmail.com Wed Oct 14 09:46:55 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Wed, 14 Oct 2015 14:46:55 +0100 Subject: [Apiman-user] applications without plans? Message-ID: <561E5CCF.7080105@gmail.com> I'm wanting to do something that may not be possible :-) I have a service that I want to offer to multiple organisations. I want the users of each organisation to authenticate according to the needs or that organisation (e.g. against their own LDAP server). I do not want to have to handle API keys as I have lots of organisations and lots of services and lots of versions of those services, so think managing those keys will fast become a nightmare. I am happy to use the service as a public service, as long as the user is authenticated and authorized. e.g. I think what I want to do is create an application in each organisation with a policy that does the authentication, and use a public service that does the authorization based on expected role granted to the user. But the only way I can see to do this is to use plans, which involve the need for API keys. Any ways to do this? Tim From eric.wittmann at redhat.com Wed Oct 14 09:57:37 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 14 Oct 2015 09:57:37 -0400 Subject: [Apiman-user] applications without plans? In-Reply-To: <561E5CCF.7080105@gmail.com> References: <561E5CCF.7080105@gmail.com> Message-ID: <561E5F51.3080504@redhat.com> That's an imaginative use of apiman and it should work precisely as you have described it. You are right that if you use applications, then you must also have at least one plan. The API key is necessary in this situation because the gateway will need to know which application is calling the service (so that it can pick the right set of policies to apply). Your only other solution would be a custom authentication policy, which would obviously allow you to do whatever you wanted. In that scenario, you will presumably still need to identify the application/organization in some way. For example, each application would need to identify itself via a custom http header, or a query param, etc. -Eric On 10/14/2015 9:46 AM, Tim Dudgeon wrote: > I'm wanting to do something that may not be possible :-) > > I have a service that I want to offer to multiple organisations. > I want the users of each organisation to authenticate according to the > needs or that organisation (e.g. against their own LDAP server). > I do not want to have to handle API keys as I have lots of organisations > and lots of services and lots of versions of those services, so think > managing those keys will fast become a nightmare. I am happy to use the > service as a public service, as long as the user is authenticated and > authorized. > > e.g. I think what I want to do is create an application in each > organisation with a policy that does the authentication, and use a > public service that does the authorization based on expected role > granted to the user. > But the only way I can see to do this is to use plans, which involve the > need for API keys. > > Any ways to do this? > > Tim > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From tdudgeon.ml at gmail.com Wed Oct 14 11:17:46 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Wed, 14 Oct 2015 16:17:46 +0100 Subject: [Apiman-user] applications without plans? In-Reply-To: <561E5F51.3080504@redhat.com> References: <561E5CCF.7080105@gmail.com> <561E5F51.3080504@redhat.com> Message-ID: <561E721A.3000706@gmail.com> On 14/10/2015 14:57, Eric Wittmann wrote: > That's an imaginative use of apiman and it should work precisely as > you have described it. You are right that if you use applications, > then you must also have at least one plan. The API key is necessary > in this situation because the gateway will need to know which > application is calling the service (so that it can pick the right set > of policies to apply). Yes, I understand why that is necessary. This is because the service is being called directly through the service owner's "path". e.g. /apiman-gateway/ServiceOwnerOrg/service/1.0 Might it (in principle) be possible to access the service through the the application owners "path" e.g /apiman-gateway/AppOwnerOrg/AppName/ServiceOwnerOrg/service/1.0 > > Your only other solution would be a custom authentication policy, > which would obviously allow you to do whatever you wanted. In that > scenario, you will presumably still need to identify the > application/organization in some way. For example, each application > would need to identify itself via a custom http header, or a query > param, etc. Yes, that might work. A sort of delegating authenticator that delegates to the appropriate realm based on a header param. But it would not allow each organisation to provide custom policies. e.g. I have in mind that an individual organisation might want to add user based rate limiting to prevent one of its users using all the organisation's quota. Tim > > -Eric > > On 10/14/2015 9:46 AM, Tim Dudgeon wrote: >> I'm wanting to do something that may not be possible :-) >> >> I have a service that I want to offer to multiple organisations. >> I want the users of each organisation to authenticate according to the >> needs or that organisation (e.g. against their own LDAP server). >> I do not want to have to handle API keys as I have lots of organisations >> and lots of services and lots of versions of those services, so think >> managing those keys will fast become a nightmare. I am happy to use the >> service as a public service, as long as the user is authenticated and >> authorized. >> >> e.g. I think what I want to do is create an application in each >> organisation with a policy that does the authentication, and use a >> public service that does the authorization based on expected role >> granted to the user. >> But the only way I can see to do this is to use plans, which involve the >> need for API keys. >> >> Any ways to do this? >> >> Tim >> >> _______________________________________________ >> 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/20151014/e31fc04b/attachment.html From eric.wittmann at redhat.com Wed Oct 14 13:44:58 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Wed, 14 Oct 2015 13:44:58 -0400 Subject: [Apiman-user] applications without plans? In-Reply-To: <561E721A.3000706@gmail.com> References: <561E5CCF.7080105@gmail.com> <561E5F51.3080504@redhat.com> <561E721A.3000706@gmail.com> Message-ID: <561E949A.1070009@redhat.com> > Yes, I understand why that is necessary. > This is because the service is being called directly through the service > owner's "path". e.g. > /apiman-gateway/ServiceOwnerOrg/service/1.0 > Might it (in principle) be possible to access the service through the > the application owners "path" e.g > /apiman-gateway/AppOwnerOrg/AppName/ServiceOwnerOrg/service/1.0 Not at present. It's technically possible, but would require some core changes to how the gateway processes the inbound request. > Yes, that might work. A sort of delegating authenticator that delegates > to the appropriate realm based on a header param. > But it would not allow each organisation to provide custom policies. > e.g. I have in mind that an individual organisation might want to add > user based rate limiting to prevent one of its users using all the > organisation's quota. One possibility is that each Organization that wants to 'consume' the service could create their own version of it. This would allow each Org to configure the service with whatever policies are necessary. Each org's service would simply point to managed endpoint of the canonical service in apiman. For example: * Organization "Foo" publishes a public service named "bar" -> the Implementation endpoint is set to http://real-api.com/bar -> service is configured with some policies, optionally * Organization "A" publishes a public service named "bar" -> the Implementation endpoint is set to http://apiman:8080/apiman-gateway/Foo/bar/1.0 -> org-specific policies can be configured here * Organization "B" does the *same* thing that A did, but with different policies * Organization "C" does the *same* thing that A did, but with different policies * Etc Note: apiman 1.1.8.Final has a bug in the CachingESRegistry which will actually cause the above to fail, but it will work fine in 1.1.9.Final -Eric From tdudgeon.ml at gmail.com Thu Oct 15 06:20:34 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Thu, 15 Oct 2015 11:20:34 +0100 Subject: [Apiman-user] Dockerised environment github project In-Reply-To: References: <561E2D4A.400@gmail.com> Message-ID: <561F7DF2.9030800@gmail.com> Yes, one or other of those would be sensible. I had a quick look and neither is trivial, so will have to remain on the TODO list for now. Tim On 14/10/2015 12:27, Jakub ?ech??ek wrote: > Hi, > > this is great -- very useful. Thanks for sharing! > > What I would change is maybe swapping your postgress image for one > based on the official postgress dockerfile. Alternatively I would > suggest using centos in order to keep al the parts based on the same > system (jboss images are using centos). > Jakub. > > On Wed, Oct 14, 2015 at 12:24 PM, Tim Dudgeon > wrote: > > Hi all, > > I've been working on a fully Dockerised implementation for apiman, > with > all key parts running as separate Docker containers, with the view to > generating a setup that is suitable for production use. > > Its very much work in progress at present and a long way off being > suitable for production use, but if anyone is interested in taking a > look and providing feedback then that would be great. You can find > it on > github here: > https://github.com/tdudgeon/apiman-site > > Thanks to all on this list and the keycloak list in helping me get > this far. > > Tim > _______________________________________________ > 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/20151015/833dabdf/attachment.html From marc.savy at redhat.com Fri Oct 16 06:02:40 2015 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 16 Oct 2015 11:02:40 +0100 Subject: [Apiman-user] base64 encoding of tokens In-Reply-To: <561AD9CD.5090101@redhat.com> References: <561A82D7.1050305@gmail.com> <561AD9CD.5090101@redhat.com> Message-ID: <5620CB40.1070909@redhat.com> Tim, Sorry, I managed to make a typo of the URL in this post. It was meant to be http://www.jwt.io :-) On 11/10/2015 22:51, Marc Savy wrote: > Tim, > > You're right. I'll have to update the blog. > > What Keycloak returns in the access_token field is a JWT (see > http://www.jtw.io), which is a string split into 3 base64 parts, > separated by full stops (header, payload and signature info) as is > highlighted on jwt.io when you paste your token :-). > > Alternatively, if you use something like Ruby's Base64 decoder (which is > a bit more tolerant), you'll see useful info coming out. > > Regards, > Marc > > On 11/10/2015 16:40, Tim Dudgeon wrote: >> According to this: >> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html >> the tokens returned by keycloak are base64 encoded, but when I try to >> decode I get an error. >> >> $ curl -X POST >> http://192.168.59.103:8080/auth/realms/myrealm/protocol/openid-connect/token >> -H "Content-Type: application/x-www-form-urlencoded" -d "username=user1" >> -d 'password=secret' -d 'grant_type=password' -d 'client_id=echo' -s | >> jq -r '.access_token' | base64 -D >> Invalid character in input stream. >> >> How are the tokens supposed to be decoded? >> >> Tim >> _______________________________________________ >> 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 tdudgeon.ml at gmail.com Fri Oct 16 06:14:42 2015 From: tdudgeon.ml at gmail.com (Tim Dudgeon) Date: Fri, 16 Oct 2015 11:14:42 +0100 Subject: [Apiman-user] base64 encoding of tokens In-Reply-To: <5620CB40.1070909@redhat.com> References: <561A82D7.1050305@gmail.com> <561AD9CD.5090101@redhat.com> <5620CB40.1070909@redhat.com> Message-ID: <5620CE12.6030403@gmail.com> Mark, Thanks - I had worked that out. The information you gave was very useful. Tim On 16/10/2015 11:02, Marc Savy wrote: > Tim, > > Sorry, I managed to make a typo of the URL in this post. > > It was meant to be http://www.jwt.io :-) > > On 11/10/2015 22:51, Marc Savy wrote: >> Tim, >> >> You're right. I'll have to update the blog. >> >> What Keycloak returns in the access_token field is a JWT (see >> http://www.jtw.io), which is a string split into 3 base64 parts, >> separated by full stops (header, payload and signature info) as is >> highlighted on jwt.io when you paste your token :-). >> >> Alternatively, if you use something like Ruby's Base64 decoder (which is >> a bit more tolerant), you'll see useful info coming out. >> >> Regards, >> Marc >> >> On 11/10/2015 16:40, Tim Dudgeon wrote: >>> According to this: >>> http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/2015/06/09/keycloak-oauth2.html >>> the tokens returned by keycloak are base64 encoded, but when I try to >>> decode I get an error. >>> >>> $ curl -X POST >>> http://192.168.59.103:8080/auth/realms/myrealm/protocol/openid-connect/token >>> -H "Content-Type: application/x-www-form-urlencoded" -d "username=user1" >>> -d 'password=secret' -d 'grant_type=password' -d 'client_id=echo' -s | >>> jq -r '.access_token' | base64 -D >>> Invalid character in input stream. >>> >>> How are the tokens supposed to be decoded? >>> >>> Tim >>> _______________________________________________ >>> 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 eric.wittmann at redhat.com Fri Oct 23 14:06:24 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Fri, 23 Oct 2015 14:06:24 -0400 Subject: [Apiman-user] Announcement: apiman 1.1.9.Final released! Message-ID: <562A7720.4020007@redhat.com> Hey everyone - just wanted to let you know that a new bug-fix-only release of apiman 1.1.x has been pushed out: http://www.apiman.io/latest/ The new version is 1.1.9.Final. You can see the list of issues that were fixed here: http://red.ht/1MJbBsx Enjoy! -Eric From gy.cai at foxmail.com Mon Oct 26 21:38:40 2015 From: gy.cai at foxmail.com (=?gb18030?B?Q0FJ?=) Date: Tue, 27 Oct 2015 09:38:40 +0800 Subject: [Apiman-user] =?gb18030?q?How_to_Define_a_Service_with_Path_Param?= =?gb18030?q?eters_=A8C_like_/porfolio/=7Bid=7D_=3F?= Message-ID: My backend system provide REST APIs like /porfolio/{id}, how can I define a service proxying request to such APIs with path parameter? After I filled in Service Name with ?/porfolio/{id}? and configured application, I can only access through ?/backend/porfolioid/?. I tried searching documents of APIMan but couldn?t find a solution. Thanks for your help. Best regards, Kelvin Cai -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20151027/ac674931/attachment.html From eric.wittmann at redhat.com Tue Oct 27 07:05:37 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 27 Oct 2015 07:05:37 -0400 Subject: [Apiman-user] =?utf-8?q?How_to_Define_a_Service_with_Path_Paramet?= =?utf-8?b?ZXJzIOKAkyBsaWtlIC9wb3Jmb2xpby97aWR9ID8=?= In-Reply-To: References: Message-ID: <562F5A81.4080500@redhat.com> OK - let's assume that the endpoint for your backend system is this (for example): http://example.org:8080/backend/portfolio/{id} Typically what you want to do is configure the Implementation Endpoint in apiman to be: http://example.org:8080/backend/ Assuming you named your apiman service "Bar" and created it inside organization "Foo", then your managed endpoint would be something like this: http://apiman-host:8080/apiman-gateway/Foo/Bar/1.0 Now, any additional path information is simply passed through as-is to your backend. So for example, you could do this: http://apiman-host:8080/apiman-gateway/Foo/Bar/1.0/portfolio/12345 This will result in apiman proxying the request here: http://example.org:8080/backend/portfolio/12345 It does this because the extra path information beyond the base managed endpoint is: /portfolio/12345 So that bit is simply appended to the implementation endpoint of: http://example.org:8080/backend/ which results in: http://example.org:8080/backend/portfolio/12345 -Eric On 10/26/2015 9:38 PM, CAI wrote: > My backend system provide REST APIs like /porfolio/{id}, how can I > define a service proxying request to such APIs with path parameter? > After I filled in /Service Name/ with ?/porfolio/{id}? and configured > application, I can only access through ?/backend/porfolioid/?. > > I tried searching documents of APIMan but couldn?t find a solution. > Thanks for your help. > > Best regards, > > Kelvin Cai > > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user >