Auth0 counterpart for KeyCloak realms

[msugakov-sh]

Hi,

We have multiple different client organizations using my web application. We would like to assign global administrators from my organization to be able to manage all users, and administrators from each client organization to manage users of that organization.
Web application has actually a separate deployment per client organization and separate database, but I think this isn’t important.

KeyCloak has concept of Realms https://www.keycloak.org/docs/latest/getting_started/#realms-and-users to group different users. However, I’m failing to identify how the same concept is called in Auth0. There’s a page https://auth0.com/docs/best-practices/multi-tenant-apps-best-practices that seems related but I’m not sure which option is more relevant for my use-case.
Could you please suggest?

Thanks,
Mikhail

[James.Morrison]

Hi there @msugakov-sh and welcome to the Auth0 Community!

You can have multiple applications under a single tenant which sounds like what you are doing, is this correct? Can you direct message me associated tenant(s) when you get a chance?

When it comes to dashboard admins and delegating them down we have this helpful write-up on it? Please let me know if this helps provide some insights!

[msugakov-sh]

Hi @James.Morrison ,

Thanks for reply. We’re at this point evaluating Auth0 so I don’t have a setup yet to share.

Could you please tell if the following is possible with Auth0?
My organization has a global administrator and “areas” (similar to KeyCloak realms), one “area” per client company. My org’s global administrator will create “area administrator” for each “area” and hand this account to the corresponding client company. Company’s “area administrator” will be able to create and self-manage accounts of company users in their “area”. “Area administrator” will not be able to manage and even see “areas” of other companies except of their own.
At this point we know there will be one application per “area”, our application. There might be more applications in each “area” in the future. We will need some of our organization users to login to all “areas”, ideally with SSO.

I’m lost in concepts and terminology and don’t know how my made-up “area” maps to Auth0 concepts. Is it tenant? connection? application? That’s why I reached out for help here!

Thanks,
Mikhail

[msugakov-sh]

Okay, looks like these are tenants that we need.
According to https://auth0.com/docs/glossary#T:

• Tenant

At Auth0, a logically-isolated group of users who share common access with specific privileges to a single software instance. No tenant can access the data of another tenant, even though multiple tenants might be running on the same machine. Tenant, in general, is a term borrowed from software multitenant architecture.

See https://auth0.com/docs/get-started/learn-the-basics

[James.Morrison]

@msugakov-sh

Could you please tell if the following is possible with Auth0?
My organization has a global administrator and “areas” (similar to KeyCloak realms), one “area” per client company. My org’s global administrator will create “area administrator” for each “area” and hand this account to the corresponding client company. Company’s “area administrator” will be able to create and self-manage accounts of company users in their “area”. “Area administrator” will not be able to manage and even see “areas” of other companies except of their own.
At this point we know there will be one application per “area”, our application. There might be more applications in each “area” in the future. We will need some of our organization users to login to all “areas”, ideally with SSO.

This should be possible as shared in the previous dashboard admin doc:

Dashboard administrators

Administrators can be application-specific, so areas to which the admin doesn’t have access rights (e.g., APIs, Rules, Hooks, Universal Login Pages, and so on) will appear as blank pages. Administrators will also not be allowed to manage users, create rules, and perform other functions for applications to which they don’t have access.

Application-specific access includes the following:

• Read and write access to the specific application configuration
• Read access to enabled connections for the application
• Ability to configure add-ons for the specific application
• Read (not write) access to all user records

@msugakov-sh

Okay, looks like these are tenants that we need.

Awesome, I’m glad to see it all came together! please let me know if you have any additional questions and I’d be happy to help!

[patricetucker55]

Thanks for the information

[James.Morrison]

No worries at all @patricetucker55!

[nancyhawkins181]

I am also having this issue, does someone have any solution for this? kindly share your views, thanks in advance.!

[James.Morrison]

Hey Nancy Do you mind sharing a little bit more about the issue you are particularly facing? I’d be happy to assist.