<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;"><div class="">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.</div></div></blockquote></div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;"><div class=""><br class=""></div><div class="">Yes, that’s right.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Marc</div></div></div><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Mar 2016, at 15:23, Cabardo, Jeanette <<a href="mailto:jeanette_cabardo@merck.com" class="">jeanette_cabardo@merck.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class=""><div style="" class="">Just to clarify your statement: </div><div style="" class=""><span style="font-family: Calibri; font-size: 12px;" class=""><br class=""></span></div><div class=""><span style="font-family: Calibri; font-size: 12px;" class=""><font color="#1f497d" class=""><i class=""><b class="">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.</b></i></font></span></div></div></div><div style="" class=""><br class=""></div><div style="" class="">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.</div><div style="" class=""><br class=""></div><div style="" class="">Jeanette</div><div style="" class=""><br class=""></div><span id="OLK_SRC_BODY_SECTION" style="" class=""><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class=""><span style="font-weight:bold" class="">From: </span> Marc Savy <<a href="mailto:marc@rhymewithgravy.com" class="">marc@rhymewithgravy.com</a>><br class=""><span style="font-weight:bold" class="">Date: </span> Monday, March 21, 2016 at 11:15 AM<br class=""><span style="font-weight:bold" class="">To: </span> "Cabardo, Jeanette" <<a href="mailto:jeanette_cabardo@merck.com" class="">jeanette_cabardo@merck.com</a>><br class=""><span style="font-weight:bold" class="">Subject: </span> Re: keycloak question<br class=""></div><div class=""><br class=""></div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;"><div class=""> (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).</div></div></blockquote><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><a href="http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/2016/01/22/mtls-mutual-auth-redux.html" class="">http://www.apiman.io/blog/gateway/security/mutual-auth/ssl/mtls/1.2.x/2016/01/22/mtls-mutual-auth-redux.html</a></div><div class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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 :).</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 21 Mar 2016, at 14:53, Cabardo, Jeanette <<a href="mailto:jeanette_cabardo@merck.com" class="">jeanette_cabardo@merck.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class=""><div class=""><div class="">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.</div></div></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jeanette</div><div class=""><br class=""></div><span id="OLK_SRC_BODY_SECTION" class=""><div style="font-family: Calibri; font-size: 11pt; text-align: left; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);" class=""><span style="font-weight:bold" class="">From: </span>Marc Savy <<a href="mailto:marc@rhymewithgravy.com" class="">marc@rhymewithgravy.com</a>><br class=""><span style="font-weight:bold" class="">Date: </span>Monday, March 21, 2016 at 10:41 AM<br class=""><span style="font-weight:bold" class="">To: </span>"Cabardo, Jeanette" <<a href="mailto:jeanette_cabardo@merck.com" class="">jeanette_cabardo@merck.com</a>><br class=""><span style="font-weight:bold" class="">Subject: </span>Re: keycloak question<br class=""></div><div class=""><br class=""></div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi Jeanette,</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">i.e</div><div class=""><br class=""></div><div class=""><font face="Andale Mono" class=""><br class=""></font></div><div class=""><font face="Andale Mono" class=""> /---> Keycloak</font></div><div class=""><font face="Andale Mono" class=""> | </font></div><div class=""><font face="Andale Mono" class=""> v [Validate]</font></div><div class=""><font face="Andale Mono" class="">client <—> apiman <—> API</font></div><div class=""><font face="Andale Mono" class=""><br class=""></font></div><div class="">Notice, the API itself is not protected directly by Keycloak. apiman does it on the API’s behalf.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">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: <a href="http://localhost:8080/apiman-echo?" class="">http://localhost:8080/apiman-echo?</a><br class=""></blockquote><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Would you object if I copy this over to the apiman-user mailing list so that more people can participate?</div><div class=""><br class=""></div><div class="">Regards,</div><div class="">Marc</div><div class=""><br class=""></div><div class="">[1] OpenID Connect JWT</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 18 Mar 2016, at 19:59, Cabardo, Jeanette <<a href="mailto:jeanette_cabardo@merck.com" class="">jeanette_cabardo@merck.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; font-size: 14px; font-family: Calibri, sans-serif;" class=""><div class="">Hi, Marc. I just have a quick question regarding your blog post (<a href="http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/1.2.x/2016/01/22/keycloak-oauth2-redux.html" class="">http://www.apiman.io/blog/gateway/security/oauth2/keycloak/authentication/authorization/1.2.x/2016/01/22/keycloak-oauth2-redux.html</a>)</div><div class=""><br class=""></div><div class="">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…</div><div class=""><br class=""></div><div class=""> “<span style="color: rgb(51, 51, 51); font-family: 'Open Sans', Helvetica, Arial, sans-serif; line-height: 20px; widows: 1; background-color: rgb(255, 255, 255);" class="">Let’s assume we’re going to protect a very simple </span><span style="box-sizing: border-box; font-weight: 700; color: rgb(51, 51, 51); font-family: 'Open Sans', Helvetica, Arial, sans-serif; line-height: 20px; widows: 1; background-color: rgb(255, 255, 255);" class="">echo
service</span><span style="color: rgb(51, 51, 51); font-family: 'Open Sans', Helvetica, Arial, sans-serif; line-height: 20px; widows: 1; background-color: rgb(255, 255, 255);" class="">, which echoes back to the requestor the details of any request made to
it. It is located at</span><code style="box-sizing: border-box; font-family: Menlo, Monaco, Consolas, 'Courier New', monospace; font-size: 12.6px; padding: 2px 4px; color: rgb(199, 37, 78); border-top-left-radius: 1px; border-top-right-radius: 1px; border-bottom-right-radius: 1px; border-bottom-left-radius: 1px; white-space: nowrap; line-height: 20px; widows: 1; background-color: rgb(249, 242, 244);" class=""><a href="http://localhost:8080/apiman-echo" class="bare" style="box-sizing: border-box; color: rgb(0, 153, 211); text-decoration: none; background: 0px 0px;">http://localhost:8080/apiman-echo</a></code><span style="color: rgb(51, 51, 51); font-family: 'Open Sans', Helvetica, Arial, sans-serif; line-height: 20px; widows: 1; background-color: rgb(255, 255, 255);" class="">.</span>” </div><div class=""><br class=""></div><div class="">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:
<b class=""><a href="http://localhost:8080/apiman-echo" class="">http://localhost:8080/apiman-echo</a></b>? 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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jeanette</div><div class=""><br class=""></div><div class=""><div class=""><b style="font-size: 11pt;" class=""><span style="font-size: 12pt; font-family: Arial, sans-serif; color: rgb(1, 156, 150);" class="">Jeanette U. Cabardo</span></b></div><div class=""><div style="margin: 0in 0in 0.0001pt; font-size: 11pt;" class=""><font color="#8b8b8d" face="Arial,sans-serif" class=""><span style="font-size: 8pt;" class="">IT Planning & Innovation </span></font><font color="#8b8b8d" face="Arial,sans-serif" size="2" class="">–</font><font color="#8b8b8d" face="Arial,sans-serif" class=""><span style="font-size: 8pt;" class=""> Applied
Technology</span></font></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt;" class=""><span style="font-size: 9pt; color: rgb(55, 66, 74);" class="">Mail Room: 1131, Mail Code: BRN-1161A</span><span style="font-size: 12pt;" class=""><o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt;" class=""><span style="font-size: 9pt; color: rgb(35, 31, 32);" class="">Merck Sharp & Dohme Corp.</span><span style="font-size: 9pt;" class=""> <br class=""></span><span lang="FR" style="font-size: 9pt; color: rgb(35, 31, 32);" class="">3070 Route 22</span><span style="font-size: 9pt;" class=""> <br class=""></span><span lang="FR" style="font-size: 9pt; color: rgb(35, 31, 32);" class="">Branchburg, NJ 08876 USA</span><span style="font-size: 9pt;" class=""> <br class=""></span><span style="font-size: 8pt; font-family: Arial, sans-serif; color: rgb(139, 139, 141);" class="">908-243-8818<o:p class=""></o:p></span></div><div style="margin: 0in 0in 0.0001pt; font-size: 11pt;" class=""><span style="font-size: 8pt; font-family: Arial, sans-serif; color: rgb(139, 139, 141);" class="">Email: </span><a href="mailto:jeanette.cabardo@spcorp.com" style="color: purple;" class=""><span style="font-size: 8pt; font-family: Arial, sans-serif; color: blue;" class="">jeanette_cabardo@merck.com</span></a></div></div></div><div class="">Notice: This e-mail message, together with any attachments, contains<br class="">
information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth, <br class="">
New Jersey, USA 07033), and/or its affiliates Direct contact information<br class="">
for affiliates is available at <br class=""><a href="http://www.merck.com/contact/contacts.html" class="">http://www.merck.com/contact/contacts.html</a>) that may be confidential,<br class="">
proprietary copyrighted and/or legally privileged. It is intended solely<br class="">
for the use of the individual or entity named on this message. If you are<br class="">
not the intended recipient, and have received this message in error,<br class="">
please notify us immediately by reply e-mail and then delete it from <br class="">
your system.</div></div></div></blockquote></div><br class=""></div></div></span><div class="">Notice: This e-mail message, together with any attachments, contains<br class="">
information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth, <br class="">
New Jersey, USA 07033), and/or its affiliates Direct contact information<br class="">
for affiliates is available at <br class=""><a href="http://www.merck.com/contact/contacts.html" class="">http://www.merck.com/contact/contacts.html</a>) that may be confidential,<br class="">
proprietary copyrighted and/or legally privileged. It is intended solely<br class="">
for the use of the individual or entity named on this message. If you are<br class="">
not the intended recipient, and have received this message in error,<br class="">
please notify us immediately by reply e-mail and then delete it from <br class="">
your system.</div></div></div></blockquote></div><br class=""></div></div></span><div class="">Notice: This e-mail message, together with any attachments, contains<br class="">information of Merck & Co., Inc. (2000 Galloping Hill Road, Kenilworth, <br class="">New Jersey, USA 07033), and/or its affiliates Direct contact information<br class="">for affiliates is available at <br class=""><a href="http://www.merck.com/contact/contacts.html" class="">http://www.merck.com/contact/contacts.html</a>) that may be confidential,<br class="">proprietary copyrighted and/or legally privileged. It is intended solely<br class="">for the use of the individual or entity named on this message. If you are<br class="">not the intended recipient, and have received this message in error,<br class="">please notify us immediately by reply e-mail and then delete it from <br class="">your system.</div></div>
</div></blockquote></div><br class=""></body></html>