We Keep Coding

ASP.NET Manual user authentication

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.

SQL login technique for authentication

I have a very basic question and want to know how other experts do this
I have an application with some 100s of users. I have been using SQL LOGINS to authenticate these users. These users have password policy enforced. and I face difficulty when any user's password is expired i.e. i have to reset it from SSMS myself. It sometimes becomes a difficult job along with other tasks that i do.
I was told by some experts that it is a good practice to create my own user table and have all the user details in that table. I have created a user table with following columns.
User Id
User Name
Password
PasswordCreationDate
PasswordExpiryDate
PasswordActive
One simple question. How do my users connect to the database . Offcourse i would need a connection string from the application. That connection string would require a user name and a password isn't it? and I can not get the information from the user table until and unless i am connected to the database.
Another problem, how do i keep track of last 5 password. The policy says that the user can not use any of the last 5 already used passwords.
All this can be avoid if I can get a solution of notifying my users that their Password is due to expire in 'n' days and they must change it before it expires.
What do the other developers do when authenticating their users. Please Guide Me

If you keep your user's login credentials in the database, then for access to sql server itself you may only need one login for the entire app. This login would have full access to your database, because it would be up to your application to enforce access rights.
If you go this route, you need to be aware of two things:
There is still a security concern for larger applications that need to give ad hoc reporting capabilities to users through tools such as Reporting Services, Crystal Reports, Infomaker, etc. In this case, users can use these reporting tools to gain read access to areas of the database they should not be able to see.
If you store your own credential information for your users, you need to make sure you do it properly. That means no plain text passwords. You need a cryptographically secure password hash (not md5!) and a per-user salt. If that's greek to you, best to leave this alone.
Another option open to you is to use Active Directory/Windows Authentication for your database. The trick here is that you still have to set up access rights for all your users. However, you can use Active Directory groups for this to reduce the number of logins you need to create, and it will at least prevent you from needing to reset Sql Server logins by hand, because users will log in with their Active Directory account.

A pretty common scenario amongst web applications is to use one username/password (so only one sql login, typically some kind of dedicated login with minimal rights for the application). This way, connection pooling can be used. This is of course a backend account, configured in the web.config and not visible to the end-users.
The users are maintained as a type of data within the application. Asp.net comes with a solution that is called Membership. User authentication is done against the Membership provider and several classes give you programmataic support for authentication, roles, etc. You can use AD as a provider for example, or forms authentication. Or you can write your own.
Since you are now using a dedicated sql login for each user, you need to be aware that this approach moves data access security to the application level. So this might not always suit your needs.

Ideally you'd use existing Active Directory infrastructure to handle your authentication/authorisation of individual users, and you could then have end-users' credentials passed via the web server to your SQL server (You'd probably need to look into handling the Kerberos "double-hop issue" to effect this).
But failing this, it's easy to set up so that the application it self has a SQL login to access the database in order to retrieve user level authentication information. One-way hashes on user passwords would ensure that even if the app's password is read from connection string, user passwords can't be obtained.
Or somewhere in between those two solutions, where the application has a service account within AD, which has access to the SQL database, in order to retrieve the user account info from within the DB.
Either way, if AD is available you can secure further with Kerberos Service Point Names to ensure database access from only your expected end-point (ie the ASP.NET server).

How to get one login page for multiple systems?

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.

WCF, active directory authentication|authorization and user profiles in sql combination

I'm developing a WCF service that will host business logic of the application. The application is mostly for intranet, but can be accessed from internet. We have an active directory domain up and running, so I plan to authenticate and authorize users according to their username and groups they are in. This service will be used mostly be an ASP.NET MVC site
So, first question is how to authenticate and authorize users based on their AD profile?
Secondly, I need to store additional info about each user. The problem is that I can't modify AD scheme. The number of added fields is about 10 or so.
Can I somehow use SQL server for profile storage? Of course I can, but how to tie this with AD auth?

You can use WIF for this.
You would configure your WCF service for WIF in the normal way and then use a custom ClaimsAuthenticationManager class deriving from the base ClaimsAuthenticationManager and overriding its Authenticate method. This is a normal extensibility point of WIF. WIF will
get hold of the security token from the incoming request and add claims for each of the relevant AD properties. In your override of the Authenticate method, you will add new claims to represent your extra properties.
The basic use of WIF for WCF services is described here:
http://msdn.microsoft.com/en-us/library/ee748476.aspx
To see how to use ClaimsAuthenticationManager, start here:
http://msdn.microsoft.com/en-us/library/ee748211.aspx

Well, I think you have a couple of choices here, but you will have to carefully consider the implementation.
The primary issue with using active directory authentication is that by default a user's credentials can only be passed successfully between two machines. In the case of a web application, this means that the user's credentials can travel between the end user's machine and the web server, but no further.
However, this behavior can be changed through the use of Kerberos authentication, which essentially allows an authentication ticket to be passed among all of the trusted machines in the chain (i.e. from the web server to the application server to the database, for example). Successfully configuring Kerberos can be extremely challenging, especially if you have had no prior experience with it.
I think your best bet is to configure your web site to accept only Windows Authentication. This means that IIS will perform the validation of the user against active directory. In your ASP.Net application you can pickup the domain name of the authorized user from Request.ServerVariables("logon_user").
At this point, you can log the user on with FormsAuthentication, for example, without requiring them to login again.
You could then either implement the SQL Server Membership Provider or create your own interface to your database for further user validation and extra information storage. We have used both mechanisms, but I prefer the self-built one due to the additional control it provides and, in this case, you won't need a lot of the functionality (password reset, recovery, etc) that the membership provider offers.

What's the difference: Windows Authentication, Passport Authentication and Form Authentication?

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.