I am making an intranet mvc app for in-house use. Only other guy in the shop is the server tech. I am told we have a domain controller and we use AD, every user is in groups. I'm pretty sure we use windows authentication (based on we have to log in to our workstation.
I'm not sure if I should be using the UserPrincipal in Directory Services, or the Current.User stuff in HTTPContext, or something else, for authenticating users. Only people in certain AD groups should be able to open the app.
Obviously I know nothing about app security stuff. I plan to hit the books, as soon as I figure out which "technology" I should be using. I also need to check users against specific groups. I almost had that figured out, but I am getting false when I know it should be true.
if (HttpContext.Current.User.IsInRole("MyADGroup"))
{
IsAdmin = true; //keeps returning false.
}
So what should I be looking into?
You can use this example to help you get started with Active Directory Roles.
Since the application is in-house, you don't want to stray far from Windows Authentication, but I do recommend looking into LDAP.
Connecting to an LDAP Server
Good luck!
You can hook up the internal application to use users and groups from AD by using the ActiveDirectoryMembershipProvider. Then simply authenticate against the provider instances (Membership.ValidateUser). This allows you to use AD as a backing store but isolates your application from an explicit dependence on it. This will also populate the UserPrincipal on the HttpContext.
I would recommend using this with a standard login form, though IIS will allow you to configure Windows authentication for the entire site. Using a standard login form along with AD-backed authentication allows you to maintain the decoupling and also expose some parts of the site as public pages by allowing anonymous access. This can be useful for things like application help and FAQs which might be useful to someone trying to log on but either disallowed by permission or using the incorrect credentials. Provides a better user experience as well.
Related
I am working for the DOD. The application they have requested is web based, and will be on their internal network. The request is for CAC authentication, which is easy enough... The remaining problem is authenticating a user. The CAC authentication is happening at the IIS level, so by the time the user gets to the application, all I am doing (or had planned on doing) is checking the ID on the CAC, and comparing it to a user table in the database. If the user exists (and has been approved), then they are off and running in the system. If they do not exist, then they are pushed to the registration screen.
Given my lack of experience with web development, I am unsure if I need to actually authenticate the user in some way beyond the CAC authentication, or if I can just manually assign roles to the user and let the roles dictate what can or cannot be done in the application. Windows authentication is not an option; while this application is internal for the military, it is accessible from different mil networks.
If I do indeed need to authenticate a user... this is where I run into trouble. I have not found anything that says there is a way to manually authenticate a user. I could use the standard ASP tables in the database, but it seems... messy... to include things that won't be used (meaning the password field would always be an empty string - why include it in the db if it isn't being used?).
Thanks in advance for any help... If there's links to where I can read more about the authentication process, those would be very much appreciated as will.
I'm working on several DOE projects that use the same idea. What we normally do for web applications is to enable Windows authentication on the app. This will allow pass-through of user credentials and keep out anyone without credentials.
I also like to add role based authorization into the mix and then use AD groups to allow/deny users on specific apps.
I have four systems running on the same server. I want to let the users to log in once for all the systems. I made one user-management system to create users and edit them.
I tried to save in the session but it didn't help.
Any suggestions? I am working on asp.net.
There are two approaches.
Most resolve around the login happening at a central site, which then returns with an identity information field (login token) that the target site uses to retreive the user.
When you go to another site, the site redirects you shortly to the central site and if you are logged in (persistent cookie) you get back the identity of you.
Alternatively you can do a lot with referrers and playing around.
YOu want to do some research on the internet - what you loo kfo is "Single Sign On".
http://www.codeproject.com/Articles/27576/Single-Sign-on-in-ASP-NET-and-Other-Platforms
has some technical discussions.
Across complete separate websites (domains) you can read up on
http://aspalliance.com/1513_Cross_Site_Authentication_and_Data_Transfer
howw to do it - obviously shared cookies will not work there.
The best way to do this is with Federated Security. If you were using Windows Authentication then you could use Active Directory Federation Services (ADFS). In this model, users reference a Web application and the principal on the current thread is checked. If the value is null then information stored in the web.config will redirect the request to a login page automatically. This is assuming there is no a Windows security context, otherwise the user can be automatically logged in.
After the user is successfully logged into the environment, the principal on the thread is populated and a set of claims are issued that are specific for that user. Since the claims are associated with the principal and not with a specific application, they can be used across the board by any claims aware application.
If you aren't using Windows Authentication, you can still accomplish the same thing, the only problem is that you cannot use ADFS. Instead, you'll have to implement your own Identity Provider to replace ADFS. The .NET Framework does provide base classes and interfaces to help you accomplish that.
I would suggest looking into ActiveDirectory or any LDAP server for single signon to access all applications. If you cannot (or do not wish to) use LDAP, you could implement similar functionality (but with more development work/time spent) with any memory/disk store. If this is not possible, please share why as it might be useful to others.
Hope this helps.
My company develops an asp.net 4.0 website as part of our product. It is meant to be run within an organization (intranet).
I've been given some requirements, but I'm new to this stuff and am not exactly sure what I should be looking into. In general this is what I need to do (assuming the website is running within a Windows domain network)
Allow automatic login to our application for any user currently logged into a domain computer. (Don't show a login screen).
Somehow map our predefined ASP.NET Roles to user groups defined in the domain (I guess manually mapping this in some sort of XML file is fine).
Get the authenticated user's groups so I can figure out the proper role from the above mapping
Get the authenticated user's contact information if available in active directory
I've done some hunting on google, and so far I've seen info on using forms authentication with active directory, windows authentication, something called AD authentication, impersonation, etc.
I'm not really looking for info on how to do this (although any help would be appreciated) I'm more looking for someone to point me in the right direction based on these requirements.
Thanks.
To skip a login, you'll have to use integrated authentication. (Turn off annonymous access in IIS, and enable Windows authentication in your application: http://msdn.microsoft.com/en-us/library/532aee0e.aspx) Of course, this will only work in Internet Explorer, and there are security concerns even if you keep it all inside your intranet.
You can probably use an Active Directory membership provider to get the username into Page.User.Identity.
And you can use the System.DirectoryServices namespace to query AD. This is a good way to get the groups out and into a form you can use for a Role Provider, as well as your route to look up their information.
I have the following scenario where I’m planning in using windows authentication.
1.1) I have a web server which will run within a domain.
1.2) The web site will run under the credentials of a domain user with a set of configured permissions (One which will be allowed access to the file system, SQL server database etc).
1.3) Users visiting the web site will belong to the same domain, so I’m planning in using windows authentication.
So at this point, an authenticated user, would access the site, but I guess that from code, “CurrentUser” would be the one under which the site is running.
I’d like the following.
2.1) To authenticate the user accessing the site with windows authentication. (Domain controller would be responsible for this).
2.2) For the site to run under the configured user from step 1.2. So it would have all of its permissions.
2.3) But I’d like to know the initial user used to authenticate from (step 2.1).
This way I could do the following:
3.1) User “A” decides to access the site, as he belongs to the same domain as the web server, he authenticates successfully.
3.2) From code I detect that “A” authenticated, so I’ll go and fetch his roles. “Role1, Role2, Role3”.
3.3) I then want the code to run under the user configured in step 1.2, but I’ll assign the Principal all of the roles retrieved from 3.2.
I’ve thought that maybe I could use Impersonation for this.
4.1) So user “A” decides to access the site and authenticates.
4.2) The site would initially run with “A” credentials, so the “CurrentUser” would be “A”.
4.3) Switch the user (somehow) back to the one from 1.2
4.4) I could retrieve all of 4.1 configured Roles.
4.5) Assign the Current Principal the roles retrieved from 4.4.
So in the end the web site will use Windows Authentication with Impersonation, but from code I’d switch back to user 1.2.
If you’ve reached this point thanks for reading! I’d like to know if this is possible and if it seems achievable or if I’m overcomplicating things.
Also suggestions in how can I plug into and where to do all the role retrieving and user switching.
Many thanks!
UPDATE 1
# Code Jammr , you're right, no need to do any crazy stuff. But I think I still need to look into HttpModules,..
After doing a few tests, searching etc...
I've started to understand the difference between these IIdentity objects:
HttpContext.Current.User.Identity
Thread.CurrentPrincipal.Identity
WindowsIdentity i2 = WindowsIdentity.GetCurrent();
I posted another question to help me understand them:
Help understanding impersonation
I think this answers my question.
There are several code samples out there for doing Impersonation. Most involve dealing with tokens and Win API calls. But if you really must do it this way, I say this not knowing what your webserver type is. IIS 6 or IIS7, then there are many code samples out there to guide you along.
Here is one link for ya that pretty much gives you a starting point.
http://msdn.microsoft.com/en-us/library/aa331755(v=vs.71).aspx
Here is a link on AD authentication and you may not have to do anything crazy.
http://support.microsoft.com/kb/326340
You may want to look into asp.net impersonation, app pool settings, etc... to see if there is a better way.
I've looked to many sources, and found many examples, but none really fit the situation that I hope to take a project to. I am writing a bunch of WCF services, some publicly accessible, others not (server to server), that will allow a fully flexible cloud app that ensures the ability to scale out the service as needed through Azure. I am unsure which way to go with message authentication, as I want to make sure a particular user logged in, can perform different tasks, and prevent others from running those tasks.
Most of what I have seen uses roles or ASP.NET membership. I have my own custom membership users will use to login with, and I don't rely on standard membership providers, or active directory. What is your recommendation? I thought about just creating a token that is created on successful login, that is stored within a cookie, added as a parameter passed into each method, but with some research, I think this might be able to be handled without modifying all my methods.
What are your thoughts?
You can easily implement authentication without needing to manually pass a token into all your functions by using UserNameAuthentication and writing a custom validator - there is a fairly straightforward tutorial here
If you use UserNameAuthentication, you will need to use SSL/HTTPS, which means you'll need to get a server certificate - this is a good idea anyway for most business applications.
At the server side you can get the identity of the current user:
IIdentity wic = OperationContext.Current.ServiceSecurityContext.PrimaryIdentity as IIdentity;
use basic authentication and have the webservice authenticate against your membership store.