mrochon / b2csamples

MIT License
132 stars 41 forks source link

Multitenant sample and path-based tenant identifiers #23

Closed jimitndiaye closed 2 years ago

jimitndiaye commented 2 years ago

I've been trying to figure out how to set this up to use a URL path identifier for the tenant name rather than a query string as it does currently but not having much luck. Is this just not possible as a rule? Is updating the app registration in B2C with reply URLs for each tenant the only way to get this to work?

Basically i'm aiming for urls that look like https://b2cmultitenant.azurewebsites.com/tenant-a/ rather than https://b2cmultitenant.azurewebsites.net?tenant=tenant-a&domain=google.com

Is this possible without modifying the app registration?

mrochon commented 2 years ago

Yes, it's possible. B2CMultitenant is a custom app. You can modify it any way you want, including using url segmants instead of query parameters. However, when you then make a token request to B2C, that url (https://yourtenant.b2clogin.com...) has to use the query parameter format. Hope this helps. Sorry I did not respond earlier. Also note that I have repalced the MVC web app with a React sample: which can be found here.

jimitndiaye commented 2 years ago

(https://yourtenant.b2clogin.com/...) has to use the query parameter format. Not sure I understand that. Do you mean providing the tenant parameter as a protocol message parameter when using the sign-in flows? I'm currently using the graph api to update the web app's reply Urls when a new tenant is created. Or at least attempting to - the full process is not quite done yet.

My current setup is a bit involved. It's a 3-tier site hierarchy with a main site (domain.com), a tenant-specific sub-domain (tenant.domain.com) and task specific environments under each tenant (tenant.domain.com/environment).

Thus I've created SUSI user flows at all three levels of the site hierarchy. The one for the main site is just a basic SUSI with little interaction with the REST service. The one for the tenant-specific domain is almost identical to your original SUSI-TENANT flow with the tenant name supplied in the protocol message before sending to B2C. The one for the individual tenant environments is modified from the tenant one requiring both the tenant name and the environment name. I duplicated and modified the Tenant controller accordingly to handle the tenant environments.

Does this setup make sense? Is there a way you think it could be improved/simplified? I can't seem to avoid having to use the graph api to update reply Urls in order to accommodate all this. I'm hoping you'll have a simpler solution.

jimitndiaye commented 2 years ago

@mrochon What is the main goal with the new solution you've linked above? Is it just using new front end or did you want to accomplish something specific with the new userflows? I've noticed you've streamlined the userflows somewhat.

mrochon commented 2 years ago

Hi jimintdiaye, yes, the new app is laregly functionally equivalent to the previous one. Main difference is it is using a browser-based React app rather than a server-side ASP.NET MVC app. There are some minor modifications to the policies as well.

jimitndiaye commented 2 years ago

@mrochon Thanks for the response. I'm trying to follow the changes in the policies so I can understand the improvements. Your sample was my first introduction to custom user journeys so I've been using it as a reference as we implement our own similar use case. I notice that you're now using sub-journeys for password reset and profile edit rather than having them separate. Could you explain the motivation for this? What major advantages do the v2 policies have over the previous MVC sample policies? I'd also like to suggest using the Microsoft.Identity.Web Nuget package in the sample since that is Microsoft's recommended way to set up such authentication flows in web apps and web APIs these days. Also useful is the Microsoft.Graph package which might save you alot of JSON serialization logic which can obscure the actual functionality in the code.

Is there a more appropriate way to have this discussion by the way? via direct email perhaps?