Securing Modern API and Microservices Based Applications by Design

Synopsis:
Many applications are modernized by leveraging APIs and decomposed into smaller units typically living inside containers. These changes involve many new tools and technologies that are not always well understood, leading to a poor application security posture. Many application architects and developers who take advantage of these architectures lack the knowledge to apply the required security controls. The ideas, principles and concepts such as API gateways, end-to-end trust, authentication and authorization discussed in this presentation have existed for some time; however, this presentation brings them all together to provide a blueprint for modern API and microservices-based application security.

The material on this topic is available as a presentation, as well as a two part series published on IBM’s Developer that provides detailed information on the subject. See below for links and other information.

Date & Locations presented:
Thursday Nov. 22, 2018 @ UBC Computer Science Alumni/Industry lecture series (Vancouver, BC)
Thursday May 23, 2019 @ OWASP Vancouver
Friday Oct. 25, 2019 @ LASCON 2019 (Austin, TX)
Tuesday Oct. 30, 2019 @ (ISC)2 Congress 2019 (Orlando, FL)

Link to presentation:
http://www.zyxgroup.com/farshad/presentations/SecuringModernAPIandMicroserviceBasedApplicationsByDesign-v0.2.pdf

Link to article published on IBM’s Developer:
https://developer.ibm.com/series/securing-modern-apps-api-microservices


Comments are closed.

3 Responses

  1. Joe Lee says:

    lol I was searching for advices on how to pass authorization check results in a chain of API calls and I came to your post…how are you Farshad?

  2. Joe Lee says:

    Specifically, to your statement ” information can be added to the E2E trust token’s payload”….that requires every API endpoint to be able to “add” and “sign” the token. That would mean every API endpoint has access to the key material to do so. And that is either very expensive (HSM clients etc) or compromising the security (if every little piece of code deployment can access the key).

    • ffa says:

      Hi Joe,

      Hope all is well :) Just to clarify, what I meant by “information can be added to the E2E trust token’s payload” is that the API gateway would perform the micro authZ, and then add information related to what is allowed for that user in the token. This would only require each API end-point to verify the token using the gateway’s public key, which can be served via a directory service (read-only). This is of course in the scenario where no direct API to API calls are allowed, and the token is only generated by the gateway and not modified downstream.