How can I control access to a 2nd website from an ASP.net core website, both running on the same IIS 10 server?
My team is implementing a "gateway" or "wrapper" ASP.net core C# app which requires MFA. We want to require authentication to this app prior to allowing the user access to a third party app which has weaker security (its security will remain in place, though. We aren't touching the third party app.)
We don't have source code for the third party app (which we are licensed to use)-- it is compiled asp.net VB, however. We are using IIS and can install the third party app as a sub-application ("Add an application") to the gateway application:
Default Web Site/gateway/third party app
Or it could be a parallel app:
Default Web Site/third party app
But I believe it does have to be in a web site to run.
I've googled a lot for ways to control access to sub-applications from a root applications, and it looks like Forms can do this but Forms is deprecated, so I would use asp.net.identity for security. Can they be combined? Or is there documentation I can't find that allows web.config authorization along with Identity, like there is with Forms?
Another option I am considering is impersonation along with setting the NTFS folder permissions for the third party app.
In all cases I'm hoping to be able to access the 2nd third party website conditionally, through the first app. (That is, once the user authenticates to the first asp.net core Identity website, it sets the conditions necessary for that user to access the 2nd.) In all tests described below, the result is either no one can access the 2nd website, or everyone can directly access it, regardless of authentication status at the first asp.net core application.
I've tried Windows Authentication but the problem is we have several external users who don't have credentials for our Windows domain-- again, I'm looking at impersonation for this.
I've looked at How to restrict a website to get access to a specific path through IIS? and this would work to control access to folders and files through the app running on IIS accessed through your browser. However, the third party app has to run on IIS and be accessed through the asp.net.identity app also running through IIS accessed through your browser, so it doesn't seem to fit.
I've utilized location (have to do that to link when application is installed as a sub application)
<configuration>
<location path="." inheritInChildApplications="false">
...
</location>
</configuration>Suggestions like login to third party website using the credentials in c# look like they are automating login to a third-party site using the 2nd site's existing security, but that's not enought, we need to improve the third-party security.
We've also looked at URLrewrite, but it looks like anyone could simulate the same conditions used by the asp.net core app to avoid redirection away from the third party app. (For instance, edit the HTML of the sign in page to put in a link directly to the third party app.)
I've looked at https://learn.microsoft.com/en-us/iis/configuration/system.webserver/security/authorization/ but couldn't figure out how to use that together with asp.net.identity. I've googled a lot and may just be missing the correct search terms!
I resolved this issue by using a reverse proxy (in my case, YARP which is easily added via NuGet and documented at https://microsoft.github.io/reverse-proxy/index.html). I added a new IIS website and bound it with http to a port that is blocked by the firewall. My app is at the Default Web Site and bound to the default http and https ports, so users can access my app, authenticate properly, and then YARP routes the packets to and from the weaker website. (Since the server itself is behind its own firewall, the authenticating app can see the newly-added-but-blocked website.) YARP has a sample project at https://github.com/microsoft/reverse-proxy/tree/release/1.1/samples/ReverseProxy.Auth.Sample demonstrating requiring authentication for routes.
In retrospect I should have posted my question on Server Fault or maybe somewhere else, since this turned out to be less of a coding question than a structural one.