Aspnetcore: Using AADIntegration AccountController

[JohnGoldsmith]

I'm not clear on intended usage of the AccountController in

https://github.com/aspnet/AspNetCore/blob/master/src/AADIntegration/src/Microsoft.AspNetCore.Authentication.AzureADB2C.UI/Areas/AzureADB2C/Controllers/AccountController.cs

As it stands the sample code suggests using the 'AzureADBC' area controller, but the SgnOut action just seems to default to https://localhost:44383/AzureADB2C/Account/SignedOut, which I imagine is not want anyone want in production.

So is it the intention that you should just use the AccountController code as a template for your own or have I misunderstood how the callbackUrl should be overridden?

[I've [migrated this issue](https://github.com/aspnet/AADIntegration/issues/53) across from the pre-merged repo as the issues don't appear to have been migrated automatically.]

[mkArtakMSFT]

Thanks for contacting us, @JohnGoldsmith.
@javiercn, can you please answer this question? Thanks!

[javiercn]

@JohnGoldsmith Thanks for reaching us.

What happens is a bit more complex than that. The action triggers the oidc signout process and then comes back to the signout oidc callback, which upon a successful logout, redirects the user back to the signed out page.

The logout redirect url is for the middleware to receive the callback from the IdP (B2C in this case). The other url is to redirect the user to a final destination after logout has happened.

I hope that helps to clarify things.

Closing this issue as there's no further action to be taken here.

[JohnGoldsmith]

@javiercn thanks very much for your help. I'm just not clear on what I need to do to get the callback to point to https://localhost:44383/ (or any other location) rather than the current https://localhost:44383/AzureADB2C/Account/SignedOut that it ends up at. Are you able to point me in the right direction?

Thanks, John

[javiercn]

@JohnGoldsmith The default callback path should be just fine. The callback path needs to be the same on your AAD application settings and on your configuration, but you can just use the default when configuring the app settings.

[JohnGoldsmith]

@javiercn I have /signin-oidc set as the reply url in the app properties in B2C and also in appsettings.json. ConfigureServices looks the same as the sample code, as far as .AddAuthentication is concerned so I believe I'm doing the same thing as the sample code but being left at https://localhost:44383/AzureADB2C/Account/SignedOut Is there a good approach to track this down? If I can work this out I'll happily add to the docs. Thanks again, John

[javiercn]

@JohnGoldsmith You are being left at Account/SignedOut because that's where the oidc middleware redirects you after successfully signing out. I'm not sure I'm understanding your expectations, but essentially the middleware needs to redirect you somewhere after receiving a callback on the /signout-oidc-callback endpoint.

[JohnGoldsmith]

@javiercn thank you for bearing with me - so what do i need to add/change to get the middleware to redirect to the homepage instead? This is what i’m not clear on.

[javiercn]

@JohnGoldsmith No problem. I understand now. There are a couple of things you can do:

1. Skip using this package and just configure oidc and cookie yourself (that way you have full control).
2. Create your own controller and use that one instead of ours.
   2.1 You can write a controllerfeatureprovider to remove our controller from the list of controllers and
   implement similar logic to that one but that redirects to where you want.

These packages are meant as a starting point, and while they offer some extensibility, (customizing the UI, changing protocol properties, behaviors) if you need full control of the flows you need to essentially configure the underlying primitives yourself and create the flows manually.

[JohnGoldsmith]

@javiercn Ok that's helpful, thank you.

I think I will go for option 1 as at least all of the code will be in a single place. I think it would be nice to split the OIDC logic (which I'd prefer the package to maintain) from the UI, (which I'd prefer to maintain myself).

I guess I was hoping to set something like the SignedOutCallbackPath, on AzureADB2COptions, to my custom path.

Anyway, thank you very much for persuing this with me.

[JohnGoldsmith]

...well having said that and just in case anyone else stumbles across this - I seem to be able to remove the feature provider (as per @javiercn recommendation item 2.1 above) like this:

public static class B2CExtensions
{
        public static IMvcBuilder RemoveADB2CAccountController(this IMvcBuilder builder)
        {
            const string appFeatureProviderName =
                "Microsoft.AspNetCore.Authentication.AzureADB2C.UI.AzureADB2CAccountControllerFeatureProvider";

            for (int i = builder.PartManager.FeatureProviders.Count - 1; i >= 0; i--)
            {
                var f = builder.PartManager.FeatureProviders[i];
                if(f.ToString().Equals(appFeatureProviderName))
                    builder.PartManager.FeatureProviders.RemoveAt(i);
            }
            return builder;
        }
    }

and that get's called from Startup.cs like this:

services.AddMvc()
                .SetCompatibilityVersion(CompatibilityVersion.Version_2_1)
                .RemoveADB2CAccountController();

Not sure if that's the best approach, but it seems to work and allows me to just implement the AccountController and UI without maintaining the rest.

[javiercn]

@JohnGoldsmith That would work. For extra points you can follow the same approach to remove the compiled views that would still be present. That said, I believe those views won't be accessible without a controller, so nothing to worry about.

[JohnGoldsmith]

@javiercn thanks! At least I now understand Application Parts a little better now. Hat tip also to @andrewlock whose post here helped me figure things out: https://andrewlock.net/controller-activation-and-dependency-injection-in-asp-net-core-mvc/