Aspnet Core - web.config Authorization - asp.net-core

Question

I am trying to add "authorization" elements to web.config, like it used to work in classic asp.net:
global configuration - should limit access "globally":
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<allow roles="AD\some.user" />
<deny users="*" />
</authorization>
...
"location" based configuration:
<configuration>
<location path="RelativePath" >
<system.web>
<authorization>
<allow roles="AD\some.user" />
<deny users="*" />
</authorization>
</system.web>
</location>
both versions appear to be not working at all for aspnet.core hosted in IIS
What does work is this:
"global":
<configuration>
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" roles="AD\johannes.colmsee" />
</authorization>
</configuration>
"location" based:
<configuration>
<location path="RelativePath" >
<system.webServer>
<security>
<authorization>
<remove users="*" roles="" verbs="" />
<add accessType="Allow" roles="AD\denis.kopic" />
</authorization>
</security>
</system.webServer>
</location>
This works fine.
Now to my question:
does aspnet core not support the "first version" at all? Or is it something I do wrong?

Answer 1

ASP.NET Core does not support nor use web.config. The published web.config is there only for IIS hosting, since IIS requires this. If you happened to publish to a different web server, you could discard web.config entirely.
It should be apparent from looking at the contents of the published web.config, that it is extremely bare. Pretty much the only thing that exists is the AspNetCoreHosting module config, which of course is necessary for hosting ASP.NET Core inside IIS.
Now, as for why the second version actually did work, that's because it was placed inside system.webServer, which is directly for configuration of IIS, so IIS is doing the authorization at a very high-level before anything is handed off to your ASP.NET Core app. That may work for your needs, but it's an extremely rough-shod approach, as you'll have to likely end up defining many such sections for different paths, users, and authorization levels, and then keep that in sync with anything you end up changing in the ASP.NET Core app. Because IIS is looking at this as just static paths, if you move or rename anything, you can end up accidentally opening a hole in your security, since IIS will not yet have been configured to authorize that new location.
Long and short, you should remove all this and handle authorization via your ASP.NET Core app. Windows Auth is still supported.