Imported Google Group message.
Sender:Carl Partridge.
Date:Friday, 21 August 2015 15:35:12 UTC+1.
Hi Carl,
The gateway has no actual “knowledge” of organisations, in the gateway, Orgs are an abstract concept and only exist through a session token that sits in a slightly different namespace, and that object solely exists to manage quotas. There is no object structure or heirarchy.
The documentation for adding these quotas is here: https://tyk.io/v1.7/rest-api/organisation_quotas/
If you create an organisation object like this, and apply the same ID to an API definition, and also apply the same organisation ID to the user token object then you’ve created a link between those things and Tyk will behave accordingly if you configure it to (as in, manage org quotas). Though it won’t secure the API from being accessed by another key with a different ORG ID, because access rgihts are handled by an explicit access rights section in the token, there is no “ownership”.
This set up is very intentional, Tyk gateway nodes are designed to be spartan, they are meant to be “dumb” and resilient, and most of all, do what they are told without cruft. Out of the box a tyk node runs on it’s own with only a redis db, no mongo or anything else required. It’s meant to be a functional unit in a wider, more complex infrastructure setup, if you want to add heirarchies to it, then that needs to be done elsewhere, because the “unit” just routes traffic according to rules you give it.
having a spartan gateway means there’s less that can go wrong, and it can be more resillient to high traffic.
The dashboard actually imposes a lot of structure (as well a centralised data repository) on top of a Tyk cluster, and with that: workflows, ownership and granular access rights at an API owner / admin level. Since Tyk can be used in a myiriad of ways, the dashboard offers one way of structuring access for a large deployment.
For example, with tyk there are no granular acces rights that allow different admin users access to a specific subset of APIs, tokens and policies, nor can you enable/disable admin API keys because there is no such concept, there is only a single key - the node secret, and you would never expose that outside of your ops team because it is meant for orchestration… by things like the dashboard 
The advanced management API provides this additional security layer that allows programatic, granular, administrative automation & integration access with an organisation → user heirarchy, while the gateway has a very raw API that is mainly meant for deeper integration with wider infrastructure systems.
The point here is that Tyk is a versatile component, if you want to add heirarchies and segregation to it, you can use the dashboard, or write your own logic and impose it on your Tyk cluster. Many people do this simply because they don’t need all the features of the dashboard, or they have their own portals, and means they can adapt the business logic around their business instead of being forced by the gateway to do something a certain way.
Hope that clarifies the design philosophy a little.
Cheers,
Martin