A message from our CEO about the future of Stack Overflow and Stack Exchange. Read now.
4

After further research I am satisfied with an answer so I will answer my own post. I see that Microsoft recommends using a prepended-tenant (client ID in this case) in this particular article: https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/token-cache Furthermore, I see that the framework I'm using has specific options & code ...


2

But how do you avoid the issue of duplicate/wrong/updated account Ids being sent to these services? I think the concern you are raising is regarding what is known as an insecure direct object reference. You'd be exposed to this vulnerability if the client is capable of sending any Account ID it wants and the service does not authenticate it. There are two ...


2

I agree with Robert H. that there is an overarching problem here with terminology. Your customer is not using the terminology consistently or correctly, so any requirements discussions using that terminology will be problematic. Steer away from it. Instead, talk about use cases. The requirement could potentially be restated in plain terms as follows: As ...


2

In short Yes this can make sense, for example in combination with SSO, but it weakens the independence of the tenants. More infos In principle, in a multi-tenant architecture, you want each tenant to be independent of the others, as-if it would be separate system. This means that each tenant should have its own user management. However, some users ...


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 ...


1

First choice is better for security and independence between tenants, like the choice about database.But you have to build tools to handle it. Failure of one queue, don't expose failure to other tenants. First is not simple technically, but have functionals advantages : limited failure independence between tenants/confidentiality, eg: data cannot be ...


1

There is no silver bullet in this scenario, but you have to evaluate a solution for each customization aspect that you have to face in time, trying to keep separate the core api from customized services If customers just need to extend the information associated to some resource (company, user, asset) the most flexible solution is the introduction of ...


1

What I would like to know is how would you handle having a master admin account (for me) with which I could observe number of tenants, subscriptions and their types, permissions and so on? You can have a separate domain admin.example.com. Also have a list of reserved subdomains which won't be allowed for tenants. Now what bothers me with routes and ...


1

If I understood correctly, you need to propagate tenant_id(*) to most (all?) of your services, which will then convert that tenant_id into database access information (not quite sure from your question, whether it's the same db all services uses or different ones). This case seems to be very similar to authentication (even though I got an impression your ...


1

Bottom Line Up Front: You will likely have to start with a compromise. Micro-services, and multi-tenancy are hard. You have to consider the trade-offs on cost to run, maintain, and build your solutions. The answers are going to conflict with what makes the system more robust and secure. The challenge is to figure out where your project needs to start, ...


Only top voted, non community-wiki answers of a minimum length are eligible