2

I've been doing some research on multi-tenant systems and micro-services and I'm a bit confused by this.

If each micro-service has it's own database, and implements the support of multi-tenancy in it's api - what service is responsible for telling the micro-service what account Ids map to which customers?

Is there a single source of truth for the account Ids? How is this information propagated out to all the various micro-services if a new customer is added?

Initially I thought that perhaps the micro-services don't need to be aware of this at all, they just accept an account Id and store the data without caring what customer it came from. But how do you avoid the issue of duplicate/wrong/updated account Ids being sent to these services? Doesn't this seem like a big security and regulatory risk?

This isn't a problem in a single database design, because Account Id is constrained in all tables that reference it and is easier to manage.

Improve this question
2
  • 1
    Wouldn't your accounts be managed by the Accounts microservice? Wouldn't that microservice be your single source of truth? You don't have to propagate this information; it's already there for the taking. If you see an account id that you don't recognize in the foreign key of a customer record, just look it up from the Accounts microservice.
    – Robert Harvey
    Commented Feb 12, 2019 at 22:32
  • 1
    You either propagate events (AccountCreated, AccountUpdated, etc) through the whole system or do requests to the AccountService. Or, if your services are secured, you can rely on the authorization (token, identifier, API key, whatever identifies the tuple customer-account or the tenant)
    – Laiv
    Commented Feb 12, 2019 at 22:53

1 Answer 1

Reset to default
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 solutions:

  1. Authenticate the ID. In other words, validate the ID against the client's authentication context. You would need to do this with each transaction.

  2. Don't expose the ID to the internet. Instead, retrieve the ID when the user authenticates and store it either in session or in an encrypted cookie (e.g. as part of an encrypted or signed authentication token). If the token is encrypted or signed then the client should not be able to change it.

Improve this answer
3
  • 1
    Even more (necessary) complexity in an already (necessarily) complex system.
    – Robert Harvey
    Commented Feb 13, 2019 at 0:17
  • I think number 1 would be most applicable in my case, as these would be back end services calling other back end services (ie. After customer created, go to this external endpoint and sync up changes). Another teams service may end up sending me a bad Id, or their test service is trying to talk to our prod service, etc. If I were to validate each transaction by going to the account service, would there be any risk in caching those results?
    – Igneous01
    Commented Feb 13, 2019 at 6:06
  • 2
    All clients that use your system have to be assessed and categorized: are they trusted or untrusted? If they are not trusted, they must authenticate with your system and you must validate all of their inputs. If they are trusted, then a code flaw may still end up sending you a wrong ID, but that is no different than if your own code had a flaw, and should be caught during integration testing.
    – John Wu
    Commented Feb 13, 2019 at 7:08

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.