I have a bit of a hybrid situation on my hands. I'm writing an intranet asp.net web app. I don't want to use full blown Windows Authentication, because I don't have proper groups set up in Active Directory to be able to authenticate users simply based on what group they are in. Up until now, I had created a membership database, and was manually authenticating users based on their NT Login. The app is getting more complex, and I'm looking at using the Membership and Roles providers to authenticate users. Here's my issue: I want to be able to authenticate users just based on their NT, but I don't want to use Windows Authentication. I want to write my own provider to plug into the membership and roles providers, and use Forms authentication, but make it transparent. Based on a Users table, I want to be able to authenticate the user or redirect them based on their NT alone. Is this possible, or am I stuck writing my own small framework to accomplish this? I would like to take advantage of the provider framework if at all possible.
Set your web.config to use Forms Authentication.
Make sure Integrated Authentication is turned on in IIS (you may need to disable anonymous as well). This will allow you to get the user's NT name.
You can get the user's NT name with:
Request.ServerVariables["LOGON_USER"]
You can log the user in, no password needed, with:
FormsAuthentication.RedirectFromLoginPage( userName, false );
Related
I have an ASP.NET Core application using Identity. It is an intranet application and I am requiring all users be authenticated using Windows Authentication, which uses Kerberos.
I want to have the system be seamless for the user, so that when they access the page and they are not signed in but are authenticated, they are automatically signed in using their User.Identity.Name which corresponds to their Identiy Username which I first check to see if exists with UserManager.FindByIdAsync
If it does exist, I sign them in using the SignInManager. If it doesn't exist, I create a new user in the Identity store and then sign that user in.
Is this assuming too much? is this potentially going to come back and bite me, or is this perfectly acceptable? Most examples I see exist with user credentials being transmitted to sign the user in to Active Directory.
With integrated authentication IIS becomes the point at which users login, and you don't need, and shouldn't use Identity 3.0 - you don't need it, AD is the user database here, you don't need to add Identity.
When you create a new application you should click the change authentication button in the new project dialog and choose Windows authentication. That will configure everything correctly and won't add any of the Identity pieces.
Note that in RC1 authorization based on role/AD group membership is broken, so Authorize[Roles = "MYDOMAIN\mygroup"] won't work. This will be fixed in RC2.
I have a case that I need my application run on windows authentication mode but a specific folder I want to deny access for it and handle it like forms mode authentication
Do you have any suggestions how to handle this case and use something like multi authentication mode within one application !
It's possible - exact mechanism would depends upon where your user store is located at. For example, let's say you have your own users table in the database that you are using for doing Forms authentication. In such case, you can offer windows authentication by mapping your user to the windows user(s) - it can be as simple as maintaining a column in the users table.
Basic idea is to to configure ASP.NET to use forms authentication - the login page uses windows authentication and if user is authenticated then do not display login form. See this link for more info: http://mvolo.com/iis-70-twolevel-authentication-with-forms-authentication-and-windows-authentication/
On related note, see this SO question: Mixing Forms authentication with Windows authentication
I have only one user for my asp.net application and I have to create the authentication system for the website. What could be the best, secure and easiest way I can do that?
What I believe that createing a table in a database for a single user is not at all a good choice. At the same time, security is the major need for the authentication.
You can store the username and (hashed) password in the web.config.
http://msdn.microsoft.com/en-us/library/e01fc50a.aspx
Since you don't have to worry about user maintenance, just add the user to the local system and establish integrated windows authentication. This keeps the password secure, the login is done through NTLM, and you can use the built-in Identity class to keep track of the logged in user.
My question is about an approach, and I am looking for tips or links to help me develop a solution. I have an .NET 4.0 web forms application that works with Forms authentication using the aspnetdb SQL database of users and passwords. A new feature for the application is a new authentication mechanism using single sign on to allow access for thousands of new users. Essentially, when the user logs in through the new single-sign-on method, I will be able to identify them as legitimate users with a role.
So I will have something like HttpContext.Current.Session["email_of_authenticated_user"] (their identity) and HttpContext.Current.Session["role_of_authenticated_user"] (their role).
Importantly, I don't necessarily want to maintain these users and roles redundantly in the aspnetdb database which will be retired, but I do want to use the session objects above to allow the user to pass through the application as if they were in passing through with forms authentication. I don't think CustomRoleProviders or CustomMemberProviders are helpful since they do not allow for creating session-level users.
So my question is how to use the session level user and role that I do have to "mimic" all the forms authentication goodness like enforcing:
[System.Security.Permissions.PrincipalPermission(System.Security.Permissions.SecurityAction.Demand, Role = "Student")]
or
<authorization>
<allow users="wilma, barney" />
</authorization>
Thanks for any pointers.
I think you're confusing Forms Authentication with the SqlMembershipProvider.
Forms authentication is the means by which ASP.NET generically authorizes and authenticates users. It does not specify a specific implementation of how that is done. It only provides a way that, once authenticated, the application can use those credentials throughout the app via a "ticket" system that's saved as a cookie.
Essentially, there are only two kinds of authentication in windows, Forms Authentication and Windows Authentication. Since your new method is not Windows based, then you have to use Forms Authentication (unless you simply ignore the stuff that's built into asp.net and roll everything yourself, which is kind of stupid to do).
You might want to look into the Windows Identity Foundation as it provides a plugable architecture for identity, including various web based single sign-on methods.
Scenario: An intranet ASP.Net application using Integrated Windows Authentication and a SqlRoleProvider for authorization. The application is used by a small subset of users within the domain.
If there are only a few users within the domain that should be able to access the application, can IWA be narrowed to allow authentication for that subset of users only, say via a domain group? Is this possible or even logical? This would certainly be the case if you predefined user accounts and used forms authentication. I understand that you can manage authorization within the application but wonder if the above is possible to add some security in depth. Appreciate your thoughts.
With anonymous access disabled, you can set the NTFS permissions on the web application directory to let only specific users in.
IWA will authenticate all valid users. But you can do the following,
allocate the subset of users into a group, and use role rrovider for them. Then you can allow only this group to use the application.
Or use forms authentication instead and write your own membership provider to authenticate users. Then you have all the controls and can block unwanted users.
You can also try some of the more traditional authorization techniques I outlined here:
Is it possible to restrict windows authenticated users in an ASPNet app to specific domains?