Yes, that’s right. Communications between a client (e.g. web app) and apiman are secured by Keycloak; communications between apiman and APIs are secured by mutual TLS (or whichever scheme you choose). Regards, Marc > On 21 Mar 2016, at 15:23, Cabardo, Jeanette <jeanette_cabardo(a)merck.com&gt; wrote: > > Just to clarify your statement: > > Instead of protecting your APIs directly, you could instead remove the auth from them and let apiman deal with it (see the diagram in the linked blog post) and simply stop unauthorised folk calling those services directly. That would likely be a good option to evaluate. > > > Jeanette > > From: Marc Savy <marc(a)rhymewithgravy.com <mailto:marc@rhymewithgravy.com>> > Date: Monday, March 21, 2016 at 11:15 AM > To: "Cabardo, Jeanette" <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>> > Subject: Re: keycloak question > >> (I have recommended doing it on the network level as you noted in the embedded link that I provided but our network engineer is adamant on protecting the endpoints explicitly). > > I suggest using Mutual TLS (good solution, high security) or BASIC (development or lower security). MTLS blog is below. It’s an excellent option for your requirements: > > http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/201... <http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/201... > > > The downside of both of these is that it requires some modification of your existing APIs, whereas the network solution is more transparent. Either way, the above is well supported :). > > Instead of protecting your APIs directly, you could instead remove the auth from them and let apiman deal with it (see the diagram in the linked blog post) and simply stop unauthorised folk calling those services directly. That would likely be a good option to evaluate. > > > >> On 21 Mar 2016, at 14:53, Cabardo, Jeanette <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>> wrote: >> >> Yes, Marc, please feel free to copy my posting. I am fairly new to Apiman and keycloak, and been struggling finding examples/documentation that can help. I think these blogs definitely helped a lot in the past few days. >> >> And yes, my requirement is to explicitly protect the endpoints (I have recommended doing it on the network level as you noted in the embedded link that I provided but our network engineer is adamant on protecting the endpoints explicitly). I was able to protect the endpoints by using the nodejs library (connect-keycloak) though I’m finding I have to make adjustments as it was developed on the older version of keycloak and I think it’s really primarily if you have a client app more than just a back-end api. I know that this issue that I have raised maybe a combination of apiman/keycloak but it would be good to know if what I’m doing is feasible or am I chasing something that’s not even possible at this time, is what I am trying to at least find out. As a back-up we can opt to do the protection on the network level. >> >> Jeanette >> >> From: Marc Savy <marc(a)rhymewithgravy.com <mailto:marc@rhymewithgravy.com>> >> Date: Monday, March 21, 2016 at 10:41 AM >> To: "Cabardo, Jeanette" <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>> >> Subject: Re: keycloak question >> >> Hi Jeanette, >> >> The blog-post refers to a use-case where you are applying your Keycloak authentication [1] against your API configured in apiman; not directly on the API itself. That is, apiman provides and performs the authentication *on behalf* of your API: >> >> i.e >> >> >> /---> Keycloak >> | >> v [Validate] >> client <—> apiman <—> API >> >> Notice, the API itself is not protected directly by Keycloak. apiman does it on the API’s behalf. >> >> >>> means that you are protecting this api explicitly, I.e., that without using any additional network level protection, one cannot just simply go into the browser or Postman and type in the url: http://localhost:8080/apiman-echo? <http://localhost:8080/apiman-echo?> >> >> If you want to stop people calling your API endpoint explicitly then you need to protect it . For instance, network level configuration or OOTB endpoint protection options: MTLS (Mutual TLS) or BASIC. The blog is simply for demonstrating the concepts, so it would indeed be useless in a production setup if developers could bypass the gateway. >> >> Would you object if I copy this over to the apiman-user mailing list so that more people can participate? >> >> Regards, >> Marc >> >> [1] OpenID Connect JWT >> >>> On 18 Mar 2016, at 19:59, Cabardo, Jeanette <jeanette_cabardo(a)merck.com <mailto:jeanette_cabardo@merck.com>> wrote: >>> >>> Hi, Marc. I just have a quick question regarding your blog post (http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication... <http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication...>) >>> >>> We currently have managed to set up our api to use Apiman to manage access to it and is also trying to use keycloak to potentially protect the back-end api endpoints. In you post, I just wasn’t clear whether your statement… >>> >>> “Let’s assume we’re going to protect a very simple echo service, which echoes back to the requestor the details of any request made to it. It is located athttp://localhost:8080/apiman-echo <http://localhost:8080/apiman-echo>.” >>> >>> means that you are protecting this api explicitly, I.e., that without using any additional network level protection, one cannot just simply go into the browser or Postman and type in the url: http://localhost:8080/apiman-echo <http://localhost:8080/apiman-echo>? I was using this middleware connect-keycloak to protect my endpoints but after doing so, my endpoint configuration in apiman also can’t get to the endpoint. So, when I saw your post, I thought maybe this will be the solution to my problem but just not sure if on the api side itself (in your example, apiman-echo), there is also some keycloak setup/config that needs to happen. >>> >>> I have been struggling to get this to work but maybe you can shed some light for me to understand whether what I’m doing even make sense. Appreciate any help you can provide. >>> >>> Jeanette >>> >>> Jeanette U. Cabardo >>> IT Planning & Innovation – Applied Technology >>> Mail Room: 1131, Mail Code: BRN-1161A >>> Merck Sharp & Dohme Corp. >>> 3070 Route 22 >>> Branchburg, NJ 08876 USA >>> 908-243-8818 >>> Email: jeanette_cabardo(a)merck.com <mailto:jeanette.cabardo@spcorp.com> >>> Notice: This e-mail message, together with any attachments, contains >>> information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth, >>> New Jersey, USA 07033), and/or its affiliates Direct contact information >>> for affiliates is available at >>> http://www.merck.com/contact/contacts.html <http://www.merck.com/contact/contacts.html>) that may be confidential, >>> proprietary copyrighted and/or legally privileged. It is intended solely >>> for the use of the individual or entity named on this message. If you are >>> not the intended recipient, and have received this message in error, >>> please notify us immediately by reply e-mail and then delete it from >>> your system. >> >> Notice: This e-mail message, together with any attachments, contains >> information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth, >> New Jersey, USA 07033), and/or its affiliates Direct contact information >> for affiliates is available at >> http://www.merck.com/contact/contacts.html <http://www.merck.com/contact/contacts.html>) that may be confidential, >> proprietary copyrighted and/or legally privileged. It is intended solely >> for the use of the individual or entity named on this message. If you are >> not the intended recipient, and have received this message in error, >> please notify us immediately by reply e-mail and then delete it from >> your system. > > Notice: This e-mail message, together with any attachments, contains > information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth, > New Jersey, USA 07033), and/or its affiliates Direct contact information > for affiliates is available at > http://www.merck.com/contact/contacts.html) that may be confidential, > proprietary copyrighted and/or legally privileged. It is intended solely > for the use of the individual or entity named on this message. If you are > not the intended recipient, and have received this message in error, > please notify us immediately by reply e-mail and then delete it from > your system.