0

I am currently trying my hand at a microservices architecture for the first time, and I am looking to put together a multi-tenant application built on a this architecture. Tenants are created with their own subdomain, and the tenant owner can create further user accounts linked to that tenant

I currently have the identity api set up, and was thinking of composing the rest a bit like the following:

enter image description here

The Gateways are intended to be implemented as Backend-For-Frontend and would aggregate data as necessary to satisfy the client request to that gateway.

In the identity API, I use the SaasKit middleware to check the subdomain and get tenant details. I was wondering what would be the best approach to apply this tenant discovery across the rest of the services? I am wary of creating a coupling that would undermine the autonomy of microservices. Would I do my tenant discovery in the gateways and pass the tenant ID to the microservices when requests are made to the services, should I be holding local copies of tenant information in each service, or should I use SaasKit in each service and call out to the identity API in each service to get tenant information if its not already cached?

EDIT: To add some context on to how tenants are created; The tenants are created via an API call from a separate system which provides a JWT created by a central authentication service separate to this. Users are also created this way, but the users created here are authenticated here rather than the 'other' authentication service

  • The Gateways are intended to be implemented as Backend-For-Frontend and would aggregate data as necessary to satisfy the client request to that gateway. No, Gateways are intended to provide a single entry point for several and different APIS. The APIs don't even need to be related. It's an infrastructure element unrelated to the domain or functionality of the application. API Gateways might seem a good place for aggregates but they are not. The same way we don't make aggregates in our HTTP Server or balancers. – Laiv Jul 23 at 9:52
  • I'm not sure I understand your point there? I am trying to implement a gateway per user interface, similar to what is described at: samnewman.io/patterns/architectural/bff which talks explicitly about aggregation of calls. – Steven Brookes Jul 23 at 10:25
2

Since you are using micro-services I am guessing that you are using token based authentication/authorization which means that you have a signed token in which you can securely pass data from a client to a service and from service to service to authorize requests. If not I would suggest to do so because this will enable you to:

  • Capture/Recognize the tenant information in the API Gateway through the identity service. The identity service would return the auth token which will include the tenant id.

  • There is no need to keep local copies of tenant ids or make extra calls to the identity server since the tenant id is already in the token

  • In order to acquire specific tenant configurations/access rights, caching may be required to cache data per tenant for quick retrieval.

  • That's a good suggestion, and something that did come to mind. The question I have on that though is, would that make the subdomain redundant after login? If I login on tenant1.mydomain.com, and the token contains the tenant ID, I wouldn't envisage I should be allowed to goto tenant2.mydomain.com and do something, even if the checks are done at token level post-login – Steven Brookes Jul 23 at 10:21
  • Also, I have edited my initial post to add some info on tenant/user creation. There would already be tokens provided by an external service in those contexts, and those tokens would also be used for some of the API gateway calls – Steven Brookes Jul 23 at 10:31
  • @StevenBrookes, this is a good point. If you need to enforce domain accessibility this is a check that can be done by the API Gateway to ensure that the tenant-id matches the domain name. However, if this is a SaaS environment, wouldn't domain access be used just for tenant identification purposes? If this is the case then even if users access a different domain, they would be treated for the tenant they have been authenticated with since their tenant-id will not change. – pan Jul 26 at 14:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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