1

We are trying to implement an authorization and authentication service for our product.

Now, we would have to cater to different kinds of IAM systems like SSO, LDAP and Basic Username+Password in Database for accessing our product since we have different kinds of client applications that use either one of these security mechanisms. Each of such IAM systems would also hold the necessary authorisation roles as well in their respective formats as expected.

We are thinking of building an API Gateway between our clients and backend microservices, that has a pluggable security module that can cater to requests from either SSO, LDAP, Username+Password in Database based clients to authenticate and authorise the incoming requests accordingly and issue a JWT for system-wide use within the downstream internal microservices in our backend. Does this design approach seem reasonable for my usecase?

2
  • If the sole purpose of the API Gateway is "to plug a security module", you can get rid of the API Gateway and set up the Federated Identity Provider alone
    – Laiv
    Commented Mar 16, 2023 at 9:10
  • 1
    @Laiv as of now the API Gateway is to authenticate and authorize but it will be expanded to accommodate cross cutting concern for all requests to the backend like rate limit, circuit breaking, logging, caching read only data, CDN front, simplified service discovery for clients
    – Anirban Das
    Commented Mar 16, 2023 at 13:41

1 Answer 1

Reset to default
1

Your proposed design approach seems reasonable for your specific use case as it provides a centralized and scalable solution for authentication and authorization, which can simplify the implementation and maintenance of your security infrastructure.

However, while an API Gateway can simplify security management, it can also introduce additional complexity and potential single points of failure. You should also consider the performance and scalability implications of your security design, especially if you expect high traffic or user volume.

In addition, you may want to opt instead for an industry-standard security protocol or library such as OAuth 2.0, OpenID Connect, or SAML to implement your authentication and authorization mechanisms. These standards have been widely adopted and provide robust security features that can help you meet your security requirements.

A last point I would like to mention is that you should ensure that your security design complies with any regulatory requirements that apply to your specific use case, such as GDPR, HIPAA, or PCI-DSS.

2
  • We do have a SAML based SSO as an IAM provider in place place for authenticating and authorizing internal users, that we plan to adapt via our security module of the API Gateway into JWTs for accessing the backend microservices. This security module would also be extended for adapting the username+password+roles in Database based authentication and authorization of our external users into the concerned JWTs as well for access downstream. Does this sound okay?
    – Anirban Das
    Commented Mar 17, 2023 at 11:16
  • 1
    Sounds good, but I would emphasize the need to ensure that your security module handles the different authorization roles correctly, and that the issued JWTs are properly validated. Also, you should consider implementing proper security measures such as rate limiting and IP whitelisting to prevent brute force attacks and unauthorized access.
    – Sebastian Sotto M.
    Commented Mar 18, 2023 at 17:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.