AlejandroF.14622 (Customer) asked a question.
Hello community. I'm new to Okta and I'm currently doing my own research regarding the Hub and Spoke architecture, but I thought as well of posting this question here to see whether you think this might be the right approach to our problem.
Right now we have around 100 customers and planning on growing that number even more. Each customer needs to be able to manage its own users as well as be able to create different groups for them. Both the users and groups need to be isolated from our other customers. Besides this, all of our customers' users will need to able to access the application that we will be providing them. So, the way I envision this is as the following:
- Each of our customers will be represented by a spoke (organization).
- Each spoke will have its own users and groups as well its own branding and registration settings which will be managed within the spoke.
- Each spoke's users data and configuration will be isolated from the other spokes.
- The company where I work at will be represented as the hub in this architecture and will be providing access to a cloud-based application, where all the users in the different spokes will be able to log in using the credentials created for them within their corresponding spokes.
Having said that, do you think that the spoke and hub architecture is the correct solution for our needs?
Also, if that's the case, will I need to create a separate Okta account for each of our customers (spokes) and then link them to our Okta account (hub) using the Org2Org connector?
Thank you very much in advance.
Hello @AlejandroF.14622 (Customer),
Thanks for posting.
Taking into account what are trying to accomplish in your company, definitely, the Hub and Spoke Architecture is ideal for you.
From this document:
https://developer.okta.com/docs/concepts/multi-tenancy/#from-logical-to-physical
The best option for your use case is Configuration 2 since it offers features applicable to your use case as Data residency requirements, Branding emails, Out-of-the-box duplicate name support, Unique DNSs.
And as you mentioned, Using the Org2Org connector, spokes can add users and give access to shared applications and services through the hub.
Additional useful information can be found here:
https://www.okta.com/resources/whitepaper/okta-for-global-distributed-organizations/
If this is a new implementation, it is possible to reach out to PS so they can help you with a personalized solution.
Have a great day!
Regards,
Natalia
Okta Inc.
Hi @User16254393570754125507 (Okta),
Thanks for replying back,
I have one more question. Let's consider the following scenario:
There's a user named John who belongs to OrganizationA. Then there's another user named Bob who belongs to OrganizationB.
If both their organizations (spokes) are connected to my central organization (Hub) and they are both able to log into the application I will be exposing through the Hub, will I, within the application, be able to read which are the groups that they belong to within their corresponding applications by calling the Get User's Groups endpoint?
Besides being able to read the groups that the current logged in user belongs to, could I permit the user to carry on different actions that will only affect the organization they belong to? E.g. create new users, assign them to groups, etc... Even though they would be executing them through the shared application. This of course assuming that the logged in user has the right roles for this.
Thanks