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
Related
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?
Here's the situation: I have an account in the azure active directory of my company with several subscriptions. I am building an ASP.NET Framework application for a client. This application is going to be hosted in their own azure environment, so to set this up, they added my email address to their azure active directory. Now in the azure portal I can use the button "change active directory" to either view my company's resources or my client's.
I set up a keyvault in my client's azure environment and I added keyvault as connected service to my application using these instructions. My application is running locally in local IIS, so I set up the application pool to use my user account so it has access to my azure subscriptions.
The issue here is that I still get an error when I try to run the application. The ysod says that azure gives a 401 response when trying to access the keyvault. I see that it's trying to use the guid that is associated with my company's azure active directory (I don't know what the name of this guid is). Obviously, I can't access resources from my client's azure environment with my company's azure active directory.
As an attempt to get more information, I built a small console application and used the same procedure to add keyvault as a connected service, since the internet says that the console application gives more details than the ASP.NET application. However, when I run my console application, I don't get any errors at all and I can access my client's keyvault just fine.
This makes me believe that there is some setting in my user account or IIS that I need to change to make this work, but I can't find what it is.
How can I make my ASP.NET Framework application, running locally in IIS, access a keyvault as connected service in my client's azure environment?
This should work, try to follow this to re-login your user account in VS and make sure you have modified your ASP.NET Framework project.
If it still not work, you could ask your client to create a work account for you in their Azure AD tenant and add it to the keyvault access policy, then use the account to login VS and test.
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.
I'm built a forms authentication (actually I'm using the new single page application) website using Asp.net MVC 4.0 with LocalDB. I want to create a separated class lib project for service layer which accesses database. And I need to integrate the default Account/authentication tables with my own tables.
Question:
Should I put the Sql server LocalDB files under the service project folder?
If the answer is not for (1), how can the service project access the LocalDB files under the MVC project?
Do I need to modify the system generated code for Account login if I put the LocalDB file under service project. How about let the authentication code access the database via the service layer instead of the default DBContext?
This pattern is very common and the main control and point of understanding is IIS and security there.
It really is worth taking a look at MSDN IIS site to feel confident about this topic.
http://msdn.microsoft.com/en-us/library/aa292471%28v=vs.71%29.aspx
1) It doesnt matter where SQL server DB is located. Where the SQL server instance is , does play a role. If it is in the same domain/AD , then using Windows integrated security to log in to the DB works well.
2) If the userid that connects to SQL is a valid user on the DB instance and has the necessary permissions for the underlying DB, then you can access the data.
3) What is this code ?
There are a number of questions that need to be answered/considered.
a) are you using FORMS logon or Windows Integrated logon in IIS.
b) Do you want to use a service user to access the DB, or have each user allocated the in the Db.
c) What is is your security model for your application.
See also http://leastprivilege.com/category/net-security/ Dominick Baier security blog.
As a sample solution, (not the only one).
you can set the website in IIS to use FORMS authentication
Set the application pool used by the website in in IIS to use a specific Service user. You type the userid and password into IIS app pool. You must first create this user on the domain. Allocate it as little rights as possible.
Add this service user to SQL server and give it sufficient permissions in the DB that should be accessed. (2 steps) So the service user can access the DB but do little else.
So this leaves you with System.Environment.UserName as the System user you set in your app pool behind the website.
Your application security is then managed as you see fit.
Claims principal once you get to .net 4.5 is a "new way".
But you keep as simple as required here.
Thread.CurrentPrincipal.Identity.Name would contain the name of your forms based user.
good luck...
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.