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.
Related
I have searched all over for an answer to this, and not found anything that seems to answer my question. Which feels like it should be an easy one (but clearly isn't).
I have an API which authenticates using a token. This token I generate from my application - more specifically, I have a new Token Generation web call that will return a token. Currently, I pass in a cookie with the user and password information, and it uses this to identify who I am and what I should be allowed to do. This is all working absolutely fine and hunky-dory.
I am achieving this process by making the Token Generation use OWIN Cookie Authentication, which means that the cookie is read and the Identity is set. I am then able to use this identity to confirm whether the user is allowed to access the system.
What I now want to do is replace this Cookie Authentication process by authenticating against a Windows User (everything is windows based, and this will be an option so non-windows users can still use the cookie authentication route). But I cannot discover how to straightforwardly do this.
Note that I don't actually need to validate that the user is genuine or refer back to the AD at all. If you provide a windows user that matches a user in the system, you can log in.
So how can I - easily - get the requesting user into the Identity Name? Or is this not possible?
If you are looking for information on the current user accessing your program, assuming the program is running on the user's machine and is windows based, you can simply query windows for the user's username or any other publicly available information about the user.
Refer to https://learn.microsoft.com/en-us/dotnet/api/system.environment?view=netframework-4.8 for information on the Enviroment class and what it's features are.
If you could provide some code or further clarity I could help you further.
Scenario: I am creating an application which uses OAuth for authentication and I want to try and limit a user sharing their credentials with colleagues (we charge per seat). The only way I could think of this was to store the IP with the token (although I'm aware multiple users from a single client could be on the same IP).
Is there a standard way of doing this in OAuth?
Not via any feature specific to OAuth. A valid user that logs on from the office or from home will have a different IP address. How would you distinguish that from another user that has someone else their credentials?
The only way I see to make this work is require two-factor authentication. It's much less likely your users will be prepared to share for example their phone to use your application.
Just make sure your application adds enough value that your users will want their own account and not share credentials.
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.
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.
Just going to start making a web application and was wondering which was better, or at least what are the main differences between them (as it probably matters what I am using them for)?
Windows Authentication
Passport Authentication
Form Authentication
I would say it greatly depends on what your web app will be doing, as each one has its place. Here is some brief details about each one.
Windows authentication enables you to identify users without creating a custom page.
Credentials are stored in the Web server s local user database or an Active Directory domain. Once identified you can use the user s credentials to gain access to resources that are protected by Windows authorization.
Forms authentication enables you to identify users with a custom database such as an ASP.NET membership database. Alternatively you can implement your own custom database. Once authenticated
you can reference the roles the user is in to restrict access to portions of your Web site.
Passport authentication relies on a centralized service provided by Microsoft. Passport authentication identifies a user with using his or her e-mail address and a password and a single Passport account can be used with many different Web sites.
Passport authentication is primarily used for public Web sites with thousands of users.
Anonymous authentication does not require the user to provide credentials.
http://msdn.microsoft.com/en-us/library/eeyk640h.aspx - ASP.NET Authentication further details on forms and window authentication
Edit
Rushyo link is better: http://msdn.microsoft.com/en-us/library/ee817643.aspx
Situation as when you can use what :
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.
This should cover everything you're looking for (and more):
http://msdn.microsoft.com/en-us/library/ee817643.aspx
[Snap - I was totally going to use that exact same quote as well ;)]
Windows Authentication : As you will be using the login & password used in a domain... If you use windows authentication, your webapp will (generally) have to be deployed in a network server and all your users should (generally) have a login created for them in the domain. Though cross domain operations are possible, primarily you wont be able to use it in non-domain based environment like public websites. It will be tough if you want to include some users who are outside your domain.
Forms Authentication : Here you are deciding to act independently. You will assign each user a separate userId and password and will manage them yourself. The overhead here is you should provide and restrict the ways users are created and removed. Here you are not restricted to any domain. For any user to gain access to your webapp should get registered with your webapp. This is similar to any mail sites you see on internet.
Passport Authentication : You are depending on MS to validate your users. This will give you a global status to your application, but if you are going to deploy it only to a small group of users, you will be forcing them to create a passport account (if they don't have) so that they can access your application.
To make it more clear.. Whichever method you follow You can still restrict who can access your webapp, and can also define your own roles for each users.