Identity: Securely disable asp.net core 2.1 identity user registration

[pwen090]

In asp.net core 2.1 identity projects with authentication for users the default UI contains user registration functionality. In the past to avoid a potential security risk (particularly for enterprise apps without open user registration) you could simply delete the relevant controller and view code for registration.

What is the proper process for disabling user registration with this new razor library?
Scaffold the Account\Register section and then comment out the code within Register.cshtml and Register.cshtml.cs? I assume you cannot simply comment out the files entirely but instead essentially comment out the specific functions like OnGet, OnPost and so on?
Can you just delete these file[s] completely or will that then revert to the built-in razor library code?

Secondarily how does one disable the default identity razor class library all together so that there is no potential for attack surface creep in future updates or changes to said library? E.g. My authentication UI/Controllers are only what I have explicitly coded them to be. thank you!

[blowdart]

@javiercn did we consider this? Enhancement to make it easier later on?

[HaoK]

Disabling the default UI entirely is fairly easy, you would just replace AddDefaultIdentity with the old AddIdentity/AddIdentityCore with whatever additional stores/additional servicesbut not call AddDefaultUI.

i.e. something like:

 services.AddIdentity<ApplicationUser, ApplicationRole>()
        .AddEntityFrameworkStores<ApplicationDbContext>()
        .AddDefaultTokenProviders();

[javiercn]

Hi @pwen090, thanks for contacting us.
Here is the answer to your questions:

What is the proper process for disabling user registration with this new razor library?

The simplest way to accomplish this is the one you mentioned. Simply override the register view, remove the code and have it for example, redirect to the login page.

public IActionResult OnGet() => RedirectToPage("/Account/Login");

Can you just delete these file[s] completely or will that then revert to the built-in razor library code?

If you remove the pages, it will revert to using the ones in the library. As a more involved option, you can remove the page actions using a pageapplicationmodelconvention.

Secondarily how does one disable the default identity razor class library all together so that there is no potential for attack surface creep in future updates or changes to said library? E.g. My authentication UI/Controllers are only what I have explicitly coded them to be. thank you!

@HaoK answer is the best way to do this.

Hope this helps!

Closing this issue as there's no further action to do here. Feel free to reopen if your problem hasn't been solved.

[pwen090]

If I go with the method @HaoK mentioned, to simply not have any default UI, would the best way to bring in a base template UI be to create a second project with UI, scaffold it all, then copy over those files to my original project?

I am still wondering on the point of attack surface creep for this Identity UI library. It looks like it is included as Microsoft.AspNetCore.Identity.UI as a dependency of Microsoft.AspNetCore.App. If I wanted to use the default UI but have more control over the versioning of when I want to update it or not is there a way to do that or is it bound to the overall asp.net core version? thank you much

[sbsw]

I have a similar requirement: The only part of the library code I want to use (because it incorporates a lot of security best practices) is the login stuff. But I have my own pages for registration and user settings. So I'm looking for a way to disable everything except for the Login pages. Please tell me I don't need to template ALL of the pages I don't want, just to hack up the code behind the page to return a 404 status if someone tries to access that page.

[macux]

Appreciate this is closed but I'm struggling to see the best option for getting around this, seems there are three choices:

1. Override all the views we don't want - seems hacky (there are 28 of them) and prone to potentially serious issues if new views are added in future Identity upgrades that would need to be overridden to exclude them
2. Do something with a PageApplicationModelConvention (would this option protect us from new views being added as mentioned above?)
3. Use the alternative proposed by @HaoK - having just been through the code for AddDefaultIdentity (including AddIdentityCookies and AddIdentityCore) and the "old" AddIdentity there seem to be subtle differences between the two other than just the AddDefaultUI call. Could this approach not also lead to nasty bugs in the future when things get added/fixed in AddDefaultUI?

Would be nice if we could just have some kind of options builder to throw at AddDefaultUI to say explicitly what we do want....