hey If I remove the tenant chooser component from ...
# ask-a-descoper
g
hey If I remove the tenant chooser component from the flow, the dct is not sent anymore, although I have the "Set active tenant claim automatically" on any idea why?
a
Hello, Removing the Tenant Chooser means no tenant is resolved in the flow, so the DCT is not issued. To restore the DCT, you need to ensure the flow selects or assigns an active tenant, either via the chooser or via a scripted assignment.
g
How do I do the script assignment
@Akash Jivane can I use the custom claims for that?
a
If “select tenant automatically” option is enabled in your JWT template. This setting works only when the user is assigned to a single tenant. Could you please confirm whether the user you’re testing with is assigned to only one tenant? If the user belongs to multiple tenants, this option will not work as expected, and you may need to disable it or adjust the configuration accordingly.
g
nope, no a single tenant but I have scenario where some users have 1 and some users have mutiple
so I want to rely on the dct at any scenario
a
Got it, thanks for the clarification — that helps. Since you have a mixed scenario and you want to always rely on the DCT, you’ll need to explicitly assign the active tenant in the flow when there isn’t a chooser.
You should add a Flow Script (or Action) step that: Determines which tenant should be active for the user. • Assigns that tenant as the active tenant in the flow This ensures a DCT is always issued, even without the tenant chooser.
Something like this - 1. Add a Flow Script step after user identification (login/signup step) 2. In the script, determine the tenant: • If user has only one tenant → select that • If user has multiple tenants → based on email domain user attribute query param / app context or your backend decision 3. Set that tenant as the active tenant
g
how do I do it? is there an exmaple somwhere
a
Sure, Let me create a sample flow for you.
I have created a sample flow. Where I have added a condition which might solve this issue. You can use this flow and simply add the required blocks into your flow. Let us know if this resolve your issue ?
g
thanks Akash, I'm just wondering why not allowing dct also in the scenario of tenant? why not support that natively?
t
Hi Gal, what would be your expected behavior? The
Set active tenant claim automatically
sets a DCT if the user has only one tenant. If the user has more than one tenant, based on what would you like the tenant to be determined?
g
@Tal Kapitolnik today when a user switch tenants, the dct changes so in the scenario of multiple tenants, I use the dct to determined the current session, which is good.
the tenant determined by the current/last active session this is how it works today
but some of my users have 1 tenant, some multiple, so I'd like to rely just on 1 param to determine the current active tenant
t
The DCT is determined in the login flow, or after it if you do switch tenant. You can rely on it if there is a tenant involved in the flow. If the user has more than one tenant, we don't know to which one you want the active one to be without the user to select one...
g
Yes, but there's always a login so the user decides otherwise it should take the last known session tenant
And the user can switch later on
t
You want the DCT to be set based on the last session of the user? And if it's his first time, or a new device?
Check out this flow. It's based on check if SSO is enabled flow, but I added stuff to fit your usecase. After authentication action, if the user: • Has no tenants (Don't know if you have this situation) - Goes to end. • Has one tenant - Goes to end (With DCT). • Has more than one tenant and have last session tenant - Goes to scriptlet that sets the tenant to the last tenant. • Has more that one tenant and doesn't have last session tenant - Gets tenant selector.
✅ 1
g
Thanks will give it a try