From kiwi.mec at gmail.com Sun Mar 15 03:20:36 2015 From: kiwi.mec at gmail.com (Michael Chester) Date: Sun, 15 Mar 2015 20:20:36 +1300 Subject: [Apiman-user] Using a header for versioning Message-ID: Hi, Currently APIman inserts the version into the URL. We would like to use a header instead. Is it possible to support this? Regards, Michael Chester -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150315/c59b49ba/attachment.html From eric.wittmann at redhat.com Mon Mar 16 06:37:05 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Mon, 16 Mar 2015 06:37:05 -0400 Subject: [Apiman-user] Using a header for versioning In-Reply-To: References: Message-ID: <5506B251.3030505@redhat.com> Hi Michael. Thanks for your interest. :) It would be a relatively easy change to allow this (although currently it's not supported out of the box). You have a couple of options including: 1) Create a feature request in JIRA for us to add this feature (https://issues.jboss.org/browse/APIMAN) 2) Create your own custom version of the API Gateway (not as hard as it sounds!) 3) Contribute a patch that adds support for this (Starting point here: https://github.com/apiman/apiman/blob/master/gateway/platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/GatewayServlet.java#L264) -Eric On 3/15/2015 3:20 AM, Michael Chester wrote: > Hi, > > Currently APIman inserts the version into the URL. We would like to use > a header instead. Is it possible to support this? > > Regards, > Michael Chester > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From kiwi.mec at gmail.com Mon Mar 16 15:17:04 2015 From: kiwi.mec at gmail.com (Michael Chester) Date: Tue, 17 Mar 2015 08:17:04 +1300 Subject: [Apiman-user] Using a header for versioning In-Reply-To: <5506B251.3030505@redhat.com> References: <5506B251.3030505@redhat.com> Message-ID: Hi Eric, Thank you. I will do 1 and have a look at doing 3. Regards, Michael Chester On Monday, March 16, 2015, Eric Wittmann wrote: > Hi Michael. > > Thanks for your interest. :) It would be a relatively easy change to > allow this (although currently it's not supported out of the box). You > have a couple of options including: > > 1) Create a feature request in JIRA for us to add this feature ( > https://issues.jboss.org/browse/APIMAN) > > 2) Create your own custom version of the API Gateway (not as hard as it > sounds!) > > 3) Contribute a patch that adds support for this (Starting point here: > https://github.com/apiman/apiman/blob/master/gateway/ > platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/ > GatewayServlet.java#L264) > > -Eric > > On 3/15/2015 3:20 AM, Michael Chester wrote: > >> Hi, >> >> Currently APIman inserts the version into the URL. We would like to use >> a header instead. Is it possible to support this? >> >> Regards, >> Michael Chester >> >> >> _______________________________________________ >> 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/20150317/f4983b7d/attachment.html From marc.savy at redhat.com Tue Mar 17 09:57:12 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 17 Mar 2015 13:57:12 +0000 Subject: [Apiman-user] Using a header for versioning In-Reply-To: References: <5506B251.3030505@redhat.com> Message-ID: <550832B8.8090304@redhat.com> Hi Michael, It just happens that I've been working on a very simple plug-in which may do what you want. Please check out: https://issues.jboss.org/browse/APIMAN-339 and look at the last line in particular. For the initial version it'd just be a simple list of fields you can access implemented very basically, but in the future we could make it a bit more sophisticated. Regards, Marc On 16/03/2015 19:17, Michael Chester wrote: > Hi Eric, > > Thank you. I will do 1 and have a look at doing 3. > > Regards, > Michael Chester > > > On Monday, March 16, 2015, Eric Wittmann > wrote: > > Hi Michael. > > Thanks for your interest. :) It would be a relatively easy change > to allow this (although currently it's not supported out of the > box). You have a couple of options including: > > 1) Create a feature request in JIRA for us to add this feature > (https://issues.jboss.org/__browse/APIMAN > ) > > 2) Create your own custom version of the API Gateway (not as hard as > it sounds!) > > 3) Contribute a patch that adds support for this (Starting point > here: > https://github.com/apiman/__apiman/blob/master/gateway/__platforms/servlet/src/main/__java/io/apiman/gateway/__platforms/servlet/__GatewayServlet.java#L264 > ) > > -Eric > > On 3/15/2015 3:20 AM, Michael Chester wrote: > > Hi, > > Currently APIman inserts the version into the URL. We would like > to use > a header instead. Is it possible to support this? > > Regards, > Michael Chester > > > _________________________________________________ > 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 Mar 17 11:01:38 2015 From: marc.savy at redhat.com (Marc Savy) Date: Tue, 17 Mar 2015 15:01:38 +0000 Subject: [Apiman-user] Using a header for versioning In-Reply-To: <550832B8.8090304@redhat.com> References: <5506B251.3030505@redhat.com> <550832B8.8090304@redhat.com> Message-ID: <550841D2.2020207@redhat.com> Hmm, I may have misinterpreted what you wanted. Are you talking about the routing of a request/response as a header, or just putting the value into the header. The use case I was talking about is simply putting values into headers, it doesn't change the URI format or anything like that. On 17/03/2015 13:57, Marc Savy wrote: > Hi Michael, > > It just happens that I've been working on a very simple plug-in which > may do what you want. > > Please check out: https://issues.jboss.org/browse/APIMAN-339 and look at > the last line in particular. > > For the initial version it'd just be a simple list of fields you can > access implemented very basically, but in the future we could make it a > bit more sophisticated. > > Regards, > Marc > On 16/03/2015 19:17, Michael Chester wrote: > > Hi Eric, > > > > Thank you. I will do 1 and have a look at doing 3. > > > > Regards, > > Michael Chester > > > > > > On Monday, March 16, 2015, Eric Wittmann > > wrote: > > > > Hi Michael. > > > > Thanks for your interest. :) It would be a relatively easy change > > to allow this (although currently it's not supported out of the > > box). You have a couple of options including: > > > > 1) Create a feature request in JIRA for us to add this feature > > (https://issues.jboss.org/__browse/APIMAN > > ) > > > > 2) Create your own custom version of the API Gateway (not as hard as > > it sounds!) > > > > 3) Contribute a patch that adds support for this (Starting point > > here: > > https://github.com/apiman/__apiman/blob/master/gateway/__platforms/servlet/src/main/__java/io/apiman/gateway/__platforms/servlet/__GatewayServlet.java#L264 > > ) > > > > -Eric > > > > On 3/15/2015 3:20 AM, Michael Chester wrote: > > > > Hi, > > > > Currently APIman inserts the version into the URL. We would like > > to use > > a header instead. Is it possible to support this? > > > > Regards, > > Michael Chester > > > > > > _________________________________________________ > > 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 kiwi.mec at gmail.com Wed Mar 18 00:08:38 2015 From: kiwi.mec at gmail.com (Michael Chester) Date: Wed, 18 Mar 2015 17:08:38 +1300 Subject: [Apiman-user] Using a header for versioning In-Reply-To: <550841D2.2020207@redhat.com> References: <5506B251.3030505@redhat.com> <550832B8.8090304@redhat.com> <550841D2.2020207@redhat.com> Message-ID: Hi Marc, Header based routing. Putting the value in the header is straight forward. Regards, Michael Chester On Wednesday, March 18, 2015, Marc Savy wrote: > Hmm, I may have misinterpreted what you wanted. Are you talking about the > routing of a request/response as a header, or just putting the value into > the header. > > The use case I was talking about is simply putting values into headers, it > doesn't change the URI format or anything like that. > > On 17/03/2015 13:57, Marc Savy wrote: > > Hi Michael, > > > > It just happens that I've been working on a very simple plug-in which > > may do what you want. > > > > Please check out: https://issues.jboss.org/browse/APIMAN-339 and look at > > the last line in particular. > > > > For the initial version it'd just be a simple list of fields you can > > access implemented very basically, but in the future we could make it a > > bit more sophisticated. > > > > Regards, > > Marc > > On 16/03/2015 19:17, Michael Chester wrote: > > > Hi Eric, > > > > > > Thank you. I will do 1 and have a look at doing 3. > > > > > > Regards, > > > Michael Chester > > > > > > > > > On Monday, March 16, 2015, Eric Wittmann > > > >> wrote: > > > > > > Hi Michael. > > > > > > Thanks for your interest. :) It would be a relatively easy > change > > > to allow this (although currently it's not supported out of the > > > box). You have a couple of options including: > > > > > > 1) Create a feature request in JIRA for us to add this feature > > > (https://issues.jboss.org/__browse/APIMAN > > > ) > > > > > > 2) Create your own custom version of the API Gateway (not as hard > as > > > it sounds!) > > > > > > 3) Contribute a patch that adds support for this (Starting point > > > here: > > > > https://github.com/apiman/__apiman/blob/master/gateway/__platforms/servlet/src/main/__java/io/apiman/gateway/__platforms/servlet/__GatewayServlet.java#L264 > > > < > https://github.com/apiman/apiman/blob/master/gateway/platforms/servlet/src/main/java/io/apiman/gateway/platforms/servlet/GatewayServlet.java#L264 > >) > > > > > > -Eric > > > > > > On 3/15/2015 3:20 AM, Michael Chester wrote: > > > > > > Hi, > > > > > > Currently APIman inserts the version into the URL. We would > like > > > to use > > > a header instead. Is it possible to support this? > > > > > > Regards, > > > Michael Chester > > > > > > > > > _________________________________________________ > > > 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/20150318/c3e146d4/attachment.html From kiwi.mec at gmail.com Wed Mar 18 17:40:02 2015 From: kiwi.mec at gmail.com (Michael Chester) Date: Thu, 19 Mar 2015 10:40:02 +1300 Subject: [Apiman-user] APIMAN-339 Policy: Simple header policy Message-ID: Does overwrite existing mean: - if it exists then over write it, or - add this header if it is there or not? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/apiman-user/attachments/20150319/35bc27e3/attachment.html From marc.savy at redhat.com Thu Mar 19 06:04:37 2015 From: marc.savy at redhat.com (Marc Savy) Date: Thu, 19 Mar 2015 10:04:37 +0000 Subject: [Apiman-user] APIMAN-339 Policy: Simple header policy In-Reply-To: References: Message-ID: <550A9F35.1090603@redhat.com> Yes. If exists overwrite. If not exists set. See: https://github.com/apiman/apiman-plugins/commit/c132348a86bfb3ffb2c5f1df7a87c96a755b6b4b On 18/03/2015 21:40, Michael Chester wrote: > Does overwrite existing mean: > > - if it exists then over write it, or > - add this header if it is there or not? > > > _______________________________________________ > Apiman-user mailing list > Apiman-user at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/apiman-user > From marc.savy at redhat.com Fri Mar 20 14:51:26 2015 From: marc.savy at redhat.com (Marc Savy) Date: Fri, 20 Mar 2015 18:51:26 +0000 Subject: [Apiman-user] APIMAN-339 Policy: Simple header policy In-Reply-To: <550A9F35.1090603@redhat.com> References: <550A9F35.1090603@redhat.com> Message-ID: <550C6C2E.3060606@redhat.com> I've just checked a couple of small new features into master which may be interesting. You can now stipulate that you want the value to be resolved from the environment or system.properties (using the provided value as a key into the corresponding map). On 19/03/2015 10:04, Marc Savy wrote: > Yes. If exists overwrite. If not exists set. > > See: https://github.com/apiman/apiman-plugins/commit/c132348a86bfb3ffb2c5f1df7a87c96a755b6b4b > > On 18/03/2015 21:40, Michael Chester wrote: > > Does overwrite existing mean: > > > > - if it exists then over write it, or > > - add this header if it is there or not? > > > > > > _______________________________________________ > > 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 Mar 24 12:42:33 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 24 Mar 2015 12:42:33 -0400 Subject: [Apiman-user] Swagger + oauth2 In-Reply-To: References: <550AE1FD.9020607@redhat.com> <550AE31C.5030308@redhat.com> <550AFB2D.1070200@redhat.com> <550B0CBF.5000808@redhat.com> Message-ID: <551193F9.3050806@redhat.com> Hi Christina. Marc and I had a discussion today about OAuth security and I think we agree on a few points. First of all, I think the typical approach to using apiman for authentication is to enable Keycloak OAuth at the apiman layer, and then to *NOT* enable Keycloak anywhere on your back-end service. Typically users would ensure that only apiman could invoke the back-end service, either by doing something at the network layer (network security) or some other mechanism. Marc is looking into the options for securing the connection between apiman and the back-end service (options include certificate authentication and separate server->server oauth). But the idea is that the back-end service wouldn't know anything about Keycloak - only apiman would. Here is a picture of how that might look: https://docs.google.com/drawings/d/1ggNcUuoMIU0zJDFBXVwPMGLovRpXWHoqlmXi2qa5vHo/pub?w=1440&h=1080 The client is responsible for getting the bearer token and including it in the request to the managed service. apiman would then consume the bearer token and validate it, then strip it from the request. apiman would then proxy the request to the back-end service, using eithet network trickery or something like certificate authentication to ensure that only apiman can invoke it. The missing piece is then authorization. So we are planning on creating an Authorization policy (or perhaps we will augment the current keycloak oauth policy impl) that will allow you to map resource regular expressions to required role(s). This would allow you to configure all of your security (authentication + authorization) in apiman. The only thing you would use keycloak for is managing the users and the roles that those users have. So it would look like this: https://docs.google.com/drawings/d/1b9ceXyOA3wzxtrav4UHERnaXE9o40D2lCUW6wFQHxBA/pub?w=960&h=720 What do you think about this approach? I think it's the right way to go, but we're obviously open to suggestions. If you agree, then I think our to-do list is: 1) Add authorization capabilities either via a new policy or as part of the existing OAuth policy 2) Figure out the best way to secure the connection between apiman and the back-end service (perhaps certificate auth) For some users #2 will be optional, with the assumption that they will configure their network to ensure that external clients cannot directly access back-end services. -Eric From eric.wittmann at redhat.com Tue Mar 24 13:50:25 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 24 Mar 2015 13:50:25 -0400 Subject: [Apiman-user] Swagger + oauth2 In-Reply-To: References: <550AE1FD.9020607@redhat.com> <550AE31C.5030308@redhat.com> <550AFB2D.1070200@redhat.com> <550B0CBF.5000808@redhat.com> <551193F9.3050806@redhat.com> Message-ID: <5511A3E1.7060704@redhat.com> I think this is correct, Christina. One of the advantages of apiman is to push some of the common API functionality like authentication into the apiman layer so that your API implementation don't have to worry about that. So yes - you will be able to simply deploy a REST API into a vanilla wildfly application server, and then you can protect it by managing the authentication *only* in apiman. -Eric On 3/24/2015 12:55 PM, Christina Lau wrote: > Hi Eric, if I understand you correctly, it is good. Let me validate what > you say so far, with this new change, I can simply deploy my REST APIs > into say a vanilla wildfly application server. > > Then I can either use my own APIKey policy, or use your newest OAuthKC > policy, and then I have the support for an api that is either secured by > APIKey or OAuth2 with roles. > > Is that correct? If yes, it is great because I have very complex topology > as I have to have a version of the APIs that is vanilla (if I want to just > secure by API key) and a version that has the keycloak metadata (json, > web.xml etc) deployed into a keycloak server. > > Christina Lau > mobile: 1-647-527-1145 > > > > > > On 2015-03-24, 12:42 PM, "Eric Wittmann" wrote: > >> Hi Christina. >> >> Marc and I had a discussion today about OAuth security and I think we >> agree on a few points. >> >> First of all, I think the typical approach to using apiman for >> authentication is to enable Keycloak OAuth at the apiman layer, and then >> to *NOT* enable Keycloak anywhere on your back-end service. Typically >> users would ensure that only apiman could invoke the back-end service, >> either by doing something at the network layer (network security) or >> some other mechanism. Marc is looking into the options for securing the >> connection between apiman and the back-end service (options include >> certificate authentication and separate server->server oauth). But the >> idea is that the back-end service wouldn't know anything about Keycloak >> - only apiman would. >> >> Here is a picture of how that might look: >> >> https://docs.google.com/drawings/d/1ggNcUuoMIU0zJDFBXVwPMGLovRpXWHoqlmXi2q >> a5vHo/pub?w=1440&h=1080 >> >> The client is responsible for getting the bearer token and including it >> in the request to the managed service. apiman would then consume the >> bearer token and validate it, then strip it from the request. apiman >> would then proxy the request to the back-end service, using eithet >> network trickery or something like certificate authentication to ensure >> that only apiman can invoke it. >> >> The missing piece is then authorization. So we are planning on creating >> an Authorization policy (or perhaps we will augment the current keycloak >> oauth policy impl) that will allow you to map resource regular >> expressions to required role(s). This would allow you to configure all >> of your security (authentication + authorization) in apiman. The only >> thing you would use keycloak for is managing the users and the roles >> that those users have. >> >> So it would look like this: >> >> https://docs.google.com/drawings/d/1b9ceXyOA3wzxtrav4UHERnaXE9o40D2lCUW6wF >> QHxBA/pub?w=960&h=720 >> >> What do you think about this approach? I think it's the right way to >> go, but we're obviously open to suggestions. If you agree, then I think >> our to-do list is: >> >> 1) Add authorization capabilities either via a new policy or as part of >> the existing OAuth policy >> >> 2) Figure out the best way to secure the connection between apiman and >> the back-end service (perhaps certificate auth) >> >> For some users #2 will be optional, with the assumption that they will >> configure their network to ensure that external clients cannot directly >> access back-end services. >> >> -Eric >> > From eric.wittmann at redhat.com Tue Mar 24 14:04:06 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Tue, 24 Mar 2015 14:04:06 -0400 Subject: [Apiman-user] Swagger + oauth2 In-Reply-To: References: <550AE1FD.9020607@redhat.com> <550AE31C.5030308@redhat.com> <550AFB2D.1070200@redhat.com> <550B0CBF.5000808@redhat.com> <551193F9.3050806@redhat.com> <5511A3E1.7060704@redhat.com> Message-ID: <5511A716.4020604@redhat.com> Will do. We're currently closing in on finishing up the conversion of the UI from GWT to angular. Target release for 1.1.0.Final is end of next week. After that we'll quickly get to work on all this non-UI related stuff for a 1.1.1.Final, perhaps a week or so later. -Eric On 3/24/2015 1:55 PM, Christina Lau wrote: > Ok great, let me know when you have something that I can try. > > Christina Lau > mobile: 1-647-527-1145 > > > > > > On 2015-03-24, 1:50 PM, "Eric Wittmann" wrote: > >> I think this is correct, Christina. One of the advantages of apiman is >> to push some of the common API functionality like authentication into >> the apiman layer so that your API implementation don't have to worry >> about that. >> >> So yes - you will be able to simply deploy a REST API into a vanilla >> wildfly application server, and then you can protect it by managing the >> authentication *only* in apiman. >> >> -Eric >> >> On 3/24/2015 12:55 PM, Christina Lau wrote: >>> Hi Eric, if I understand you correctly, it is good. Let me validate what >>> you say so far, with this new change, I can simply deploy my REST APIs >>> into say a vanilla wildfly application server. >>> >>> Then I can either use my own APIKey policy, or use your newest OAuthKC >>> policy, and then I have the support for an api that is either secured by >>> APIKey or OAuth2 with roles. >>> >>> Is that correct? If yes, it is great because I have very complex >>> topology >>> as I have to have a version of the APIs that is vanilla (if I want to >>> just >>> secure by API key) and a version that has the keycloak metadata (json, >>> web.xml etc) deployed into a keycloak server. >>> >>> Christina Lau >>> mobile: 1-647-527-1145 >>> >>> >>> >>> >>> >>> On 2015-03-24, 12:42 PM, "Eric Wittmann" >>> wrote: >>> >>>> Hi Christina. >>>> >>>> Marc and I had a discussion today about OAuth security and I think we >>>> agree on a few points. >>>> >>>> First of all, I think the typical approach to using apiman for >>>> authentication is to enable Keycloak OAuth at the apiman layer, and >>>> then >>>> to *NOT* enable Keycloak anywhere on your back-end service. Typically >>>> users would ensure that only apiman could invoke the back-end service, >>>> either by doing something at the network layer (network security) or >>>> some other mechanism. Marc is looking into the options for securing >>>> the >>>> connection between apiman and the back-end service (options include >>>> certificate authentication and separate server->server oauth). But the >>>> idea is that the back-end service wouldn't know anything about Keycloak >>>> - only apiman would. >>>> >>>> Here is a picture of how that might look: >>>> >>>> >>>> https://docs.google.com/drawings/d/1ggNcUuoMIU0zJDFBXVwPMGLovRpXWHoqlmXi >>>> 2q >>>> a5vHo/pub?w=1440&h=1080 >>>> >>>> The client is responsible for getting the bearer token and including it >>>> in the request to the managed service. apiman would then consume the >>>> bearer token and validate it, then strip it from the request. apiman >>>> would then proxy the request to the back-end service, using eithet >>>> network trickery or something like certificate authentication to ensure >>>> that only apiman can invoke it. >>>> >>>> The missing piece is then authorization. So we are planning on >>>> creating >>>> an Authorization policy (or perhaps we will augment the current >>>> keycloak >>>> oauth policy impl) that will allow you to map resource regular >>>> expressions to required role(s). This would allow you to configure all >>>> of your security (authentication + authorization) in apiman. The only >>>> thing you would use keycloak for is managing the users and the roles >>>> that those users have. >>>> >>>> So it would look like this: >>>> >>>> >>>> https://docs.google.com/drawings/d/1b9ceXyOA3wzxtrav4UHERnaXE9o40D2lCUW6 >>>> wF >>>> QHxBA/pub?w=960&h=720 >>>> >>>> What do you think about this approach? I think it's the right way to >>>> go, but we're obviously open to suggestions. If you agree, then I >>>> think >>>> our to-do list is: >>>> >>>> 1) Add authorization capabilities either via a new policy or as part of >>>> the existing OAuth policy >>>> >>>> 2) Figure out the best way to secure the connection between apiman and >>>> the back-end service (perhaps certificate auth) >>>> >>>> For some users #2 will be optional, with the assumption that they will >>>> configure their network to ensure that external clients cannot directly >>>> access back-end services. >>>> >>>> -Eric >>>> >>> > From eric.wittmann at redhat.com Thu Mar 26 06:56:47 2015 From: eric.wittmann at redhat.com (Eric Wittmann) Date: Thu, 26 Mar 2015 06:56:47 -0400 Subject: [Apiman-user] versioning and service definition In-Reply-To: References: Message-ID: <5513E5EF.5000208@redhat.com> Hi Christina. This is a bug. If you choose to "clone" the service version, then the definition should also be copied over to the new version. It looks like that's not happening right now. I have added a JIRA for this issue: https://issues.jboss.org/browse/APIMAN-346 Thanks! -Eric On 3/25/2015 5:18 PM, Christina Lau wrote: > Hi Eric, when I make a version of a service, it seems the service > definition file is not automatically copied over. I get 404 when I > access this for example: > > http://localhost:8080/apiman/organizations/unauth/services/blueprints/versions/v2/definition > > > Is this a bug or do I need to do something else? Thx. > > > Christina Lau > mobile: 1-647-527-1145