You meant the diagram in the link you provided for using the Mutual TLS, correct? I just want to make sure that you were referring to that solution. And thanks so much for providing these information—really, really helpful.

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@merck.com> 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.

You meant the diagram in the link you provided for using the Mutual TLS, correct? I just want to make sure that you were referring to that solution. And thanks so much for providing these information—really, really helpful.

Jeanette

From: Marc Savy <marc@rhymewithgravy.com>
Date: Monday, March 21, 2016 at 11:15 AM
To: "Cabardo, Jeanette" <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:



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@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@rhymewithgravy.com>
Date: Monday, March 21, 2016 at 10:41 AM
To: "Cabardo, Jeanette" <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?

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@merck.com> wrote:


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.” 

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? 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
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.

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.

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.