IIS Windows Authentication - Unable to Deny Specific Users - api

Recently I have developed a very simple .net core API and then deployed the same on IIS and want to enable Windows Authentication for some users. To be able to implement it, my web.config looks like
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<authentication mode="Windows" />
<authorization>
<allow users="Tow\USER1"/>
<deny users="*"/>
</authorization>
</system.web>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\Oculus.WebApi.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
</system.webServer>
</location>
</configuration>
As it can be seen only User1 should be allowed access but everyone is able to access. My IIS authentication looks like this:
Can some one help please?

From this thread, ASP.NET Core does not support nor use web.config. The published web.config is there only for IIS hosting, since IIS requires this.
A wrokaround is that you could try to place inside system.webServer, which is directly for configuration of IIS.
<configuration>
<system.webServer>
<security>
<authorization>
<remove users = "*" roles="" verbs="" />
<add accessType = "Allow" users="Tow\USER1"/>
</authorization>
</security>
</system.webServer>
</configuration>
But the recommend way is that you'd better write you own custom authorization policy in asp.net core
https://learn.microsoft.com/en-us/aspnet/web-api/overview/security/authentication-and-authorization-in-aspnet-web-api
https://learn.microsoft.com/en-us/aspnet/core/security/authorization/policies?view=aspnetcore-2.2

Related

Net Core 5 project refuses to run

I have gone through many sites figuring out how to prepare Net Core 5 project to run in IIS. I did publishing, I have downloaded all the needed pieces (or so I think) from here:
Link
My web.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\RoundTheCode.ReactSignalR.dll" stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
But when I run website like this:
http://localhost:8090/methodname I get:
Feels like I am still missing some parts of the framework. Can someone please explain what needs to be checked for that?
Thanks

HTTP Error 500.19 - Internal Server Error-0x8007000d

I encountered this error when I tried to host my asp .net core project on local iis.
I have installed the asp .net hosting bundle, checked the permissions to my web.config file but still of no use.
My web.config file is as follows:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath=".\SampleApp1.exe" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</location>
</configuration>
<!--ProjectGuid: e4b7dcc7-c9c3-48c5-9a12-0a9ee0c9ac2c-->
My asp .net version is 3.1.201.
Also, usually at the error page you should see the physical path as well but in my case that's empty though I set the physical path to my web files.

IIS Dynamic Compression and ASP.NET Core

I have an ASP.NET Core v2.2 application deployed to IIS. I'm following the recommendation of using IIS dynamic compression rather than the response compression middleware as stated in Response compression in ASP.NET Core. I used the IIS Management Tool to configure the dynamic compression in IIS and it's working as expected. However, this updates the application's web.config to include a urlCompression element.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\xyz.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess" />
</system.webServer>
</location>
<system.webServer>
<urlCompression doDynamicCompression="true" />
</system.webServer>
</configuration>
My issue is that the next time I publish the application the dynamic compression setting is lost and I have to go back into the IIS Management Tool to configure it again.
How do I ensure this setting is preserved after re-publishing my application and without having to go into the IIS Management Tool every time?
Is there a way to include this dynamic compression setting in the Visual Studio project so it's included in the generated web.config file?
You can create a "web.config" file in the root of your project, and the contents will be merged with the other generated content in the resulting "web.config" file after publishing.
Example project file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<urlCompression doDynamicCompression="true" />
</system.webServer>
</configuration>
Contents of "web.config" file at the published location:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.webServer>
<urlCompression doDynamicCompression="true" />
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\xxx.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="inprocess" />
</system.webServer>
</configuration>

.Net Core AspNetCoreHostingModel what does it mean?

By this link, you can read about ASP.NET Core Module
To configure an app for in-process hosting, add the property to the app's project file with a value of InProcess (out-of-process hosting is set with OutOfProcess)
I've read several times but I don't understand what it's mean?
When I must use OutOfProcess and when InProcess?
Pros and cons these models?
What to rely on when making a decision?
Is referring to how IIS is hosting your app (web.config).
InProcess : IIS host the app (w3wp.exe or iisexpress.exe)
OutOfProcess: Kestrel host the app, IIS is a proxy to kestrel.
More details on how to configure and what to keep in mind for each one when using.
'InProcess' has significant better performance according to Microsoft.
To configure InProcess add web config with:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="InProcess">
<environmentVariables />
</aspNetCore>
</system.webServer>
</location>
</configuration>
For OutOfProcess:
<?xml version="1.0" encoding="utf-8"?>
configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="OutOfProcess">
<environmentVariables />
</aspNetCore>
</system.webServer>
</location>
</configuration>
when you will generate the build in my-api folder or plain publish to your server with:
dotnet publish -o my-api -c release
will take care if your %LAUNCHER_PATH% and %LAUNCHER_ARGS%.
What you are referring in initial question possibly is about .csproj config that dictate how app runs locally, default is InProcess

Aspnet Core - web.config Authorization

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?
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.