Exactly, you can have portal per organization. They will be completely separate and can be configured by having own URL with ORG id prefix, e.g portal.domain/org-id, or by having them on separate domains.
Regarding having admin user which have access to multiple organizations, there are 2 options right now. By design, at the moment Tyk user can’t be attached to multiple organizations, but there are some tricks to mitigate it:
- You can create a user without organization id, using admin API, and it will see analytics and data for ALL organizations. The pitfall here, that you won’t be able to edit or create objects in this mode, read-only.
- You can create multiple users with the same email for different orgs BUT with different passwords. In other words Tyk check user -> org uniqueness not only by user email, but email + password. Or for simplicity, for each user have same email with + trick, like "firstname.lastname@example.org", "email@example.com" and etc.
We are planning to improve this situation in next releases and allow user be attached to multiple orgs, so he can switch between them dynamically in UI.
Worth noticing that having the multi-org setup like this has own pitfalls. Since each Org has own set of APIs, will they have separate server infrastructure or will share the same servers?
If they share same servers, you need to force some naming strategy for APIs inside your orgs, to avoid conflicts (for example when 2 orgs both use same domain and decided to use the same slug). We have API URL uniqueness check within one org, but not multiple ones and here is related ticket https://github.com/TykTechnologies/tyk/issues/1457
If they are using different resources, you need to tell Gateway how to segregate APIs from different orgs to separate servers. Solution to this depends on the Tyk installation you will use.
For On-premise you need to use API tags as described here https://tyk.io/docs/manage-multiple-environments/with-on-premise/, and enforce tagging standard inside multiple orgs.
Hybrid, on another note, automatically segregate all API resources based on organization id, so no tagging needed in this case.
In Hybird mode, all your gateway servers live on your own servers, but their configuration (dashboard) on our side. If you want to achieve Hybrid similar functionality fully on-premise, you need our enterprise MDCB component (which in addition adds the option of multi-dc fallback). If you want to know more about it, feel free to contact sales via firstname.lastname@example.org.
Hope it make sense. Cheers!