rud
rudβ€’2w ago

Bigger picture - SCIM between Entra ID and Zitadel

Hi - thank you for working on Zitadel, it's awesome to see all the things being added all the time. We have some customers that would love to use Entra ID to let their end users sign in to our products. The idea is to create: 1. a Zitadel organization per customer we have a relationship with (managed by humans). 2. customer sets up creation of users in their Zitadel organisation using SCIM updates from Entra ID - we manually give them an API token with sufficient permissions. 3. we are currently planning to add a bit of custom code that ensures each user in the organization gets the intended roles they have paid for, but it is a cumbersome process. 4. end-user SSO experience: * click SSO login in our product * forward the user browser to Zitadel * There the user clicks the Microsoft button to use Entra ID for login - perform login in Entra ID * once they return to Zitadel, their paid roles are automatically assigned and they return to the product, their paid roles included in their access token. On the surface this seems like feasible and maintainable flow to me. Are there simpler alternatives we're missing? Especially the adding of roles to the SCIM created users is cumbersome. What is the best practice method to add roles to users created via SCIM?
10 Replies
Ask Inkeep
Ask Inkeepβ€’2w ago
Hi @rud, I'm an AI assistant for ZITADEL. While a team member reviews this question, I'll see if I can find relevant sources for your question. Answer I wasn't able to find a direct answer, here are some relevant sources: 1. Onboard B2B customers using organizations : This guide explains creating organizations per customer and setting up SSO flows, which aligns with your planned architecture. 2. SCIM Provisioning from Okta : While focused on Okta, this provides guidance on SCIM setup that would apply to Entra ID integration. Feel free to tag @Ask Inkeep with additional questions. Got it. Tagging @Rajat for additional help.
rud
rudOPβ€’2w ago
hi @Rajat , hope you are not completely snowed under today. I was wondering if you have time to give a bit of feedback on my SCIM question above? Thank you so much for your time!
Rajat
Rajatβ€’2w ago
hey @rud thanks for the detailed POC, I will look into it today and will try to get back possibly tomorrow πŸ™‚
rud
rudOPβ€’2w ago
awesome to hear, thank you. Looking forward to any extra insights you can provide πŸ™‚ If I have two customers (A using user77@customer-a.com accounts and B using user56@customer-b.com), each with their own Zitadel Organization, would the SCIM method outlined above still work? I'd love for all users to share the same login screen, enter their work email address and be forwarded to Microsoft Entra ID, and have their Zitadel user accounts in their appropriate Zitadel organization.
Rajat
Rajatβ€’2w ago
hey @rud I will go one by one and lmk if it makes sense. Short answer: Yes, it works. Long Answer How to make one shared login route users correctly?(from what I understood, this is what you want) Turn on Domain Discovery so the user types user@customer-a.com on your single login page and ZITADEL routes them to the right Org automatically (and then to that Org’s Entra ID).- > allow email as username so users can enter their work email directly and finally in each customer’s Org, configure Entra ID as the IdP (OIDC or SAML).
rud
rudOPβ€’7d ago
@Rajat sounds super promising! I've just experimented in an instance using Zitadel v1 UI, and it seems to work as expected there! Very exciting! I tried the same setup where Zitadel v2 UI was active, and the "Domain Discovery" does not seem to work when logging in a user. In the UI I see "User not found in the system", no IDP option. Specifically a POST request to /ui/v2/login/loginname?requestId=oidc_V2_335907689802498051, with a body of:
[{"loginName":"bob@customer.com","organization":"$undefined","requestId":"oidc_V2_335907689802498051","suffix":"$undefined"}]
[{"loginName":"bob@customer.com","organization":"$undefined","requestId":"oidc_V2_335907689802498051","suffix":"$undefined"}]
got a response of:
0:{"a":"$@1","f":"","b":"afyplmr3k5vDUT97-jcAQ"}
1:{"error":"User not found in the system"}
0:{"a":"$@1","f":"","b":"afyplmr3k5vDUT97-jcAQ"}
1:{"error":"User not found in the system"}
Is this simply not supported yet in the v2 UI, or am I doing something wrong. Only change I made between the two tests was enabling/disabling Login V2 UI. Might just be a bug
Rajat
Rajatβ€’7d ago
hey @rud the V2 Login UI in ZITADEL is still in beta and does not have full feature parity with the V1 login UI. So, it is likely that domain discovery is not yet fully supported or not working as intended in the V2 login UI at this time. If the same configuration works with the V1 login but fails with V2, this matches the current known limitations of the V2 beta. lmk if this helped πŸ™‚
ZITADEL Docs
ZITADEL provides a hosted single-sign-on page to securely sign-in users to your applications.
rud
rudOPβ€’7d ago
Ah, I missed the beta-status of Login V2 as it is the default for new Zitadel v4 installs. I'll stay with V1 for now and keep track of the updates. Thank you so much for your help, I was floundering in a sea of self-created "almost works" spikes πŸŽ‰ I'd love to mark this as solved, but don't think I have the rights to do so.
Rajat
Rajatβ€’7d ago
you can mark my answer my answer with βœ… and it will auto close this thread @rud πŸ™‚ or else I will check if the bot is not working as intended πŸ˜„
Gigi the Giraffe (Zitadel)
πŸŽ‰ Looks like you just helped out another community member! Thanks for being so helpful <@1179168518801981572>! You're now one step closer to leveling upβ€”keep up the amazing peer support! πŸš€

Did you find this page helpful?