How to authenticate and authorize different profiles in a microservices and API Gateway architecture

2
votes

I want to build a microservices architecture. It's supposed to have 13 microservices and 3 clients (2 web and 1 mobile).

In our scenario we have:

  • Employees: Access to specific and shared services and their credentials are stored in Active Directory;
  • Administrators: They are employees with full access. They have specific and shared services and their credentials are stored in Active Directory;
  • Customers: Access to specific and shared services and their credentials are stored in the Identity microservice.

We're going to have an API Gateway.

Every request is handled by API Gateway which should (or invoke the responsible for) check if the token of the request is valid, identify if it is a customer, employee or admin and check if this user has permission to access request API/microservice.

I have some misconceptions about this solution, so I'd appreciate some help for:

  • What are API Gateway responsibilities?
  • What are Identity microservice responsibilities?
  • How to manage to define which APIs/microservices can an employee, a customer and an admin can access or not?
  • How to identify if given user is a customer, an employee or an admin?
1
architectureoauth-2.0asp.net-identitymicroservicesapi-gateway

1 Answers

2
votes

What are API Gateway responsibilities?

API gateway could be understood as one service that sits in front of all other services and let you expose these services to the client. In doing so it allowing all the traffic to pass through itself and it can, therefore, do lot many things like

  • Security
  • Logging
  • Routing
  • Versioning
  • Transforming

You have an incoming request with headers and you need to pass it along to downstream service that will actually be processing the request. API gateway can do pretty much everything in between like those mentioned above.

What are Identity microservice responsibilities?

Identity is the set of data that help you identify the user uniquely. In your case, you have Active Directory which has identity information of all your employees. Similarly, you can keep information about the customer is one such service. Identity should be solely responsible for the basic demographic info of the user that helps you identify him. Alongside this, such a service may need to provide for the security around using the identity.

Identity can have roles and the services when communicating with each other need to pass along the information that tells the downstream service about the identity and some means by which this service can verify the identity information being passed.

This is where OAuth comes into play, and if you add identity, identity provider and authorization you get something called OIDC or OpenID Connect

With this, you should be able to define roles for each of your identities and then let the individual service decide what a particular identity with a particular role can do or cannot do.

How to identify if given user is a customer, an employee or an admin?

Well, you can use the role to identify (if you can add roles to your identities) or just let your identity service answer this for you. Pass the userId and let the service tell you what kind of user it is based on where this user data was sourced. It is little difficult to answer this unless I have more insight.