Authentication

Authentication is the process by which we validate a user's credentials in an attempt to verify who the user purports to be. That is, we are securely identifying our users using some sort of shared secret. For the scenarios we cover in this chapter, this shared secret is the user's password, although it really could be a number of things (once again, see The .NET Developer's Guide to Windows Security, referenced in Chapter 8, for a thorough discussion of authentication in general). As such, authentication really does not tell us much, other than "who" the user is choosing to represent.

In Chapters 3 and 8, we set the groundwork for connecting to the directory and understanding the binding process in detail. In this chapter, we take what we have already learned and apply it to the task of programmatic authentication.

When the user is a Windows or ADAM security principal, we have a number of options available to us for authentication. Since we will specifically be dealing with validating username/password combinations in this chapter, we will discuss the four primary means of password authentication we have available for us to use.

In each scenario, we will take input from the user in the form of a username, a password, and possibly, a domain name. A word of warning: The username can come to us in a few valid formats, so we should always be ready to contend with each one. Typically, we would filter the input or derive our own username format based on the input given to us by the client. For instance, the client might use any of the following formats for their username with Active Directory, as we discussed in Chapter 3:

• NT Login (DOMAINUsername)
• NT Username (Username)
• UPN ([e-mail])
• DN (CN=User,DC=domain,DC=com)

When using ADAM security principals (as opposed to using passthrough authentication with ADAM), we will typically see the username in only one of two formats[1]:

[1] 1. In actuality, if we do not bind using the DN, ADAM will attempt to resolve the account using DsCrackNames (of which UPN is one format). This means it can accept any format supported by this API (and there are eight), but collisions are possible that prevent UPN from being used effectively. Only the DN format is guaranteed to get what we want.

• DN (CN=ADAM User,OU=Foo,O=Domain,C=US)
• UPN (format varies)

It is our job as developers to anticipate that our clients will use any or all of the formats, and we need to be ready to either filter the format to our liking at input time, or deal with the format on the back end. Building the filtering through the UI is a good idea, but we should also be prepared to accept the different username formats on the back end.