Single Sign On with Identity Provider vs Integrated Windows Authentication with IIS - asp.net

I'm working on on-premise web application (front end hosted on IIS) that currently uses traditional form-based authentication. Our client wants the application to support "single sign on", which basically means he wants the users to automatically log in to the application. AFAIK there are two ways I can take to achieve the desired effect:
Most articles that I found suggest using some kind of Identity Provider system (like Active Directory Federated Services), which my application can communicate with over SAML/OIDC in order to obtain user's claims.
On the other hand, I could set up IIS to use Integrated Windows Authentication and get user claims directly from Active Directory through Kerberos/NTLM. This approach seems easier.
Given that my application will not be used outside of intranet, it is hosted in environments using Microsoft products (Active Directory, Windows Server, users using Windows machines), is there any reason I should consider the first approach?

Related

What is the best way to implement Single Sign On (SSO) against Active Directory in ASP.NET WebForms for intranet only application

We have intranet application, which is always installed on-premise in customer's environment.
Right now we are using forms authentication and we would like to use continue using it where active directory is not present. However this is a bit irritating to user's of our application because they need to always log in when they are on the machine where the application is installed, even thought it is withing their safe network (with no Internet access etc).
So we would like to have single sign on against active directory, so when they are logged in Windows they will not have to type any passwords when accessing this ASP.NET WebForms application - active directory shall be used (if present of course).

In ASP.NET, under which credentials does the code run?

1) I want to know suppose we are using an ASP.NET web application in debug mode in VS, then, the code runs under which user account?
2) I also want to know, suppose we publish this to the IIS and then, set it up to use WBA/FBA, then, the username/password of logged in user is used to authenticate user to the ASP.NET site, however, the code (SQL query, etc) runs under credentials of apppool account. Further, which credential is used to access resources on server like files? What is your view on this point?
1) I want to know suppose we are using an ASP.NET web application in
debug mode in VS, then, the code runs under which user account?
This is depending on the hosting. VS provides 4 ways to host & debug a web application : VS Dev Server (VS 2012), IIS Express, Local IIS and Custom Host (VS 2013). Devs servers generally runs under your -Administrator- account, and may not be suitable to test security. Working directly with IIS as your development web server lets you work in an environment closer to that of an IIS production web server.
This is configured in the Web Tab in your web project properties.
2) I also want to know, suppose we publish this to the IIS and then,
set it up to use WBA/FBA, then, the username/password of logged in
user is used to authenticate user to the ASP.NET site, however, the
code runs under credentials of apppool account. What is your view on
this point?
Not very clear, but I think your undestanding of IIS security may not be correct. There is only one application pool per web site which runs under a specific account (by default apppool account, but it could be Network Service or Local System). When a user logs in, absolutely nothing is changed in this process. The user is just connected using an authentication provider : Windows Authentatication or Forms Authentication are 2 common providers. User identity is kept in http context, which allow you to use authorization rules later. So every code block always run under the same account (unless you enable delegation but that's another story).
I higly suggest you to read this complete introduction on asp.net security.

Managing authentication for my Asp.net MVC web application

I am trying to accomplish the following:-
To build an Asp.net MVC 4 web application from scratch.
I want to use the current users and groups that are found on our company production active directory server.
In asp.net I know that we can have two types of authentication; Form Based & Windows based.
On my development machine I did the following tests:-
I set the authentication to be “windows based” and I was be able to access the asp.net MVC application without entering my username and password.
I set the authentication to be Form-based and I modify the query string to connect to the Active Directory instead of connecting to the sql databases tables. And I was able to access the application by typing username#domain and the password.
But my questions are:-
When deploying the web application on production, how will “windows authentication” works. Let say the user tries to access the application from external device, then can he still login to the system . Or “windows authentication” will not work for internet application.
Will form-base authentication connected to AD be the best approach to follow in my case?
If “windows authentication” will work when users access the application from external machine. Then what are the differences between having “windows authentication” & Form-based that is connected to an Active directory in this case?
Best Regards

IIS 7.5 ASP.Net and remote share

I have an issue with our ASP.net application not being able to read files from a remote directory. Our users log into our application using Forms Authentication, so no AD accounts are used in logging them in.
I have added the machine accounts the machines to the share, as I have a local service on the machine that can write to it and a SQL server able to read/write to the share with a machine account.
However, our asp.net app, running on the same server as the service above, is is not able to do this. I have tried impersonation set to true, but this does not work unless I provide an AD account. Once provided, the share works fine.
I can't move the share to the IIS server due to size constraints.
Is there anyway to allow easy access or do I need to take the interop approach?
The account the application pool runs under needs access on the remote folder. Add that account to the security tab(not only share tab) of the remote folder.
Or, try running the apppool as the AD account you used for impersonation.

Windows User Account that executes only IIS7 Provisions

I have a web application that executes IIS 7 provisions (using Microsoft.Web.Administration.dll) to create our web and ftp sites. When I run this using the administrator account, it works ok.
I want to create a Windows user account for impersonation that will only execute these web provisioning procedures without being identical to a server's administrator roles.
How can I achieve this?
You should split your application into three parts:
Windows Service
This would host a WCF or Remoting application. You want to put the code that requires privileged access to your system in here. For example creating and deleting websites. Run this service under an account that has enough rights to perform operations using Microsoft.Web.Administration.
Trusted Wrapper or Proxy Assembly
This is just a signed wrapper assembly that is installed in the GAC. Its role is to pass on calls from your low trust web application to perform privileged actions in the code running in the service above. Mark the assembly with the AllowPartiallyTrustedCallers attribute (if your server is configured for partial trust) and mark any classes that require access to the remoting service with [PermissionSet(SecurityAction.Assert, Unrestricted=true)].
Front End Application(or Web Service)
This is the interface to your application (whether it be a web application with a GUI or a web service). Run this in its own application pool with just enough rights to execute, for example IUSR or a similar account. Ideally you should also run this under partial trust.
Your web application/service references the Trusted Wrapper assembly in the GAC which in turn has a reference to the remoting or WCF application running in the windows service.
Using this layered approach means that you are locking down by gating access to specific privileged operations which only run in your windows service.
This approach is covered quite well in Appendix C of Dominick Baier's 'Developing More-Secure Microsoft ASP.NET 2.0 Applications'. I thoroughly recommend getting a copy.

Resources