For detail please visit following link :
http://msdn.microsoft.com/en-us/library/ms998310.aspx
Forms Authentication is one of three authentication providers. Windows Authentication and Passport Authentication make up the other two providers. In this article, we will focus on Forms Authentication
|
ASP.NET authentication provider
|
Description
|
|
Forms authentication
|
A system by which unauthenticated requests are redirected to an HTML form using HTTP client-side redirection. The user provides credentials and submits the form. If the application authenticates the request, the system issues a cookie that contains the credentials or a key for reacquiring the identity. Subsequent requests are issued with the cookie in the request headers; they are authenticated and authorized by an ASP.NET event handler using whatever validation method the application developer specifies.
|
|
Passport authentication
|
Centralized authentication service provided by Microsoft that offers a single logon and core profile services for member sites.
|
|
Windows authentication
|
ASP.NET uses Windows authentication in conjunction with Microsoft Internet Information Services (IIS) authentication. Authentication is performed by IIS in one of three ways: basic, digest, or Integrated Windows Authentication. When IIS authentication is complete, ASP.NET uses the authenticated identity to authorize access.
|
Forms Authentication Flow
1. A client generates a request for a protected resource (e.g. a secured page from your site).
2. IIS (Internet Information Server) receives the request. If the requesting client is authenticated by IIS, the user/client is passed on to the ASP.NET application. Note that if Anonymous Access is enabled, the client will be passed onto the ASP.NET application by default. Otherwise, Windows will prompt the user for credentials to access the server's resources. Also note that because the authentication mode in the ASP.NET application is set to Forms, IIS authentication cannot be used.
3. If the client doesn't contain a valid authentication ticket/cookie, ASP.NET will redirect the user to the URL specified in the loginURL attribute of the Authentication tag in your web.config file. This URL should contain the login page for your application. At this URL, the user is prompted to enter their credentials to gain access to the secure resource.
4. The client must provide credentials, which are then authenticated/processed by your ASP.NET application. Your ASP.NET application also determines the authorization level of the request, and, if the client is authorized to access the secure resource, an authentication ticket is finally distributed to the client. If authentication fails, the client is usually returned an Access Denied message.
5. The client can then be redirected back to the originally-requested resource, which is now accessible, provided that the client has met the authentication and authorization prerequisites discussed above. Once the authorization ticket/cookie is set, all subsequent requests will be authenticated automatically until the client closes the browser or the session terminates. You can have the user's credentials persist over time by setting the authorization ticket/cookie expiration value to the date you desire to have the credentials persist through. After that date, the user will have to log in again.
Setting Up Forms Authentication
Let's take a look at the applicable settings to execute Forms Authentication. In general, setting up Forms Authentication involves just a few simple steps.
1. Enable anonymous access in IIS. By default, anonymous users should be allowed to access your Web application. In rare cases, however, you may opt to layer an Integrated Windows OS security layer level with Forms authentication. We will discuss how to integrate this layer with anonymous access enabled in the article succeeding this one ("Part 2 (Integration w/ Active Directory)").
2. Configure your Web application's web.config file to use Forms Authentication. Start by setting the authentication mode attribute to Forms, and denying access to anonymous users. The following example shows how this can be done in the web.config file for your Web application:
3.
4. <configuration>
5. <system.web>
6. <authentication mode="Forms">
7. <forms name=".COOKIEDEMO"
8. loginUrl="login.aspx"
9. protection="All"
10. timeout="30"
11. path="/"/>
12. </authentication>
13. <authorization>
14. <deny users="?" />
15. </authorization>
16. </system.web>
17.</configuration>
Upon setting the authentication mode to Forms, you'll notice that we appended another child element. The Forms element has five attributes that implement your forms authentication configuration. The attributes and their descriptions are as follows :
|
Attribute
|
Description
|
|
name
|
This is the name of the HTTP cookie from which we will store our authentication ticket and information, respectively.
|
|
loginURL
|
This is the URL from which your unauthenticated client will be redirected. In most scenarios, this would be your login page, where the client is required to provide their credentials for authentication.
|
|
protection
|
This is used to set the method from which to protect your cookie data. The following valid values can be supplied:
All: Specifies to use both data validation and encryption to protect the cookie. Triple DES is used for encryption, if it is available and if the key is long enough (48 bytes). The All value is the default (and suggested) value.
None: Used for sites that are only using cookies for personalization and have weaker requirements for security. Both encryption and validation can be disabled. This is the most efficient performance wise, but must be used with caution.
Encryption: Specifies that the cookie is encrypted using Triple DES or DES, but data validation is not done on the cookie. It's important to note that this type of cookie is subject to chosen plaintext attacks.
Validation: Specifies to avoid encrypting the contents of the cookie, but validate that the cookie data has not been altered in transit. To create the cookie, the validation key is concatenated in a buffer with the cookie data and a MAC is computed/appended to the outgoing cookie.
|
|
timeout
|
This is the amount of time (in integer minutes) that the cookie has until it expires. The default value for this attribute is 30 (thus expiring the cookie in 30 minutes).
The value specified is a sliding value, meaning that the cookie will expire n minutes from the time the last request was received.
|
|
path
|
This is the path to use for the issued cookie. The default value is set to "/" to avoid issues with mismatched case in paths. This is because browsers are case-sensitive when returning cookies.
|
In our web.config file, it's also important to note the value we have for the deny child element of the authorization section (as highlighted below). Essentially, we set that value of the users attribute to "?" to deny all anonymous users, thus redirecting unauthenticated clients to the loginURL.
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".COOKIEDEMO"
loginUrl="login.aspx"
protection="All"
timeout="30"
path="/"/>
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
1. Create your login page (as referenced in the loginURL attribute discussed above). In this case, we should save our login page as login.aspx. This is the page to where clients without valid authentication cookie will be redirected. The client will complete the HTML form and submit the values to the server. You can use the example below as a prototype.
19.
20. <%@ Import Namespace="System.Web.Security " %>
21.<html>
22. <script language="C#" runat=server>
23. void Login_Click(Object sender, EventArgs E)
24. {
25.
26. // authenticate user: this sample accepts only one user with
27. // a name of [email protected] and a password of 'password'
28. if ((UserEmail.Value == "[email protected]") &&
29. (UserPass.Value == "password"))
30. {
31. FormsAuthentication.RedirectFromLoginPage(UserEmail.Value,
32. PersistCookie.Checked);
33. }
34. else
35. {
36. lblResults.Text = "Invalid Credentials: Please try again";
37. }
38. }
39. </script>
40. <body>
41. <form runat="server">
42. <h3>Login Page</h3>
43. <hr>
44. Email:<input id="UserEmail" type="text" runat="server"/>
45. <asp:RequiredFieldValidator ControlToValidate="UserEmail"
46. Display="Static"
47. ErrorMessage="*"
48. runat="server"/>
49. <p>Password:<input id="UserPass"
50. type="password"
51. runat="server"/>
52. <asp:RequiredFieldValidator ControlToValidate="UserPass"
53. Display="Static"
54. ErrorMessage="*"
55. runat="server"/>
56. <p>Persistent Cookie:<ASP:CheckBox id="PersistCookie"
57. runat="server" />
58. <p><asp:button id="cmdLogin"
59. text="Login"
60. OnClick="Login_Click"
61. runat="server"/>
62. <p><asp:Label id="lblResults"
63. ForeColor="red"
64. Font-Size="10"
65. runat="server" />
66. </form>
67. </body>
68.</html>
It's important to note that the above page authenticates the client on the click event of the cmdLogin button. Upon clicking, the logic determines if the username and password provided match those hard-coded in the logic. If so, the client is redirected to the requested resource. If not, the client is not authorized, and thus receives a message depicting this.
You can adjust the logic to fit your needs, as it is very likely that you will not have your usernames and passwords hard-coded into the logic. It is here at the Login_Click function that you can substitute the logic with that of your own. It is common practice to substitute database logic to verify the credentials against a data table with a stored procedure.
You can also provide authorized credentials in the web.config file. Inside the forms section, you would append a user element(s), as follows :
<configuration>
<system.web>
<authentication mode="Forms">
<forms name=".COOKIEDEMO"
loginUrl="login.aspx"
protection="All"
timeout="30"
path="/">
<credentials passwordFormat="Clear">
<user name="user1" password="password1"/>
<user name="user2" password="password2"/>
<user name="user3" password="password3"/>
</credentials>
</forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Doing so allows you to authenticate against a list of users in your web.config file, easily. You can append as many users as necessary. To authenticate against that list of users, you would append the applicable logic in the click event of the cmdLogin button discussed above. Here is the code :
void Login_Click(Object sender, EventArgs E)
{
// authenticate user: this sample authenticates
// against users in your app domain's web.config file
if (FormsAuthentication.Authenticate(UserEmail.Value,
UserPass.Value))
{
FormsAuthentication.RedirectFromLoginPage(UserEmail.Value,
PersistCookie.Checked);
}
else
{
lblResults.Text = "Invalid Credentials: Please try again";
}
}
Client Requirements
To enable forms authentication, cookies must be enabled on the client browser. If the client disables cookies, the cookie generated by Forms Authentication is lost and the client will not be able to authenticate.
Windows Based Authentication
When you use ASP.NET Windows authentication, ASP.NET attaches a WindowsPrincipal object to the current request. This object is used by URL authorization. The application can also use it programatically to determine whether a requesting identity is in a given role.
If User.IsInRole("Administrators") Then
DisplayPrivilegedContent()
End If
The WindowsPrincipal class determines roles by NT group membership. Applications that want to determine their own roles can do so by handling the WindowsAuthentication_OnAuthenticate event in their Global.asax file and attaching their own class that implements System.Security.Principal.IPrincipal to the request, as shown in the following example:
' Create a class that implements IPrincipal
Public Class MyPrincipal : Inherits IPrincipal
' Implement application-defined role mappings
End Class
' In a Global.asax file
Public Sub WindowsAuthentication_OnAuthenticate(
Source As Object, e As WindowsAuthenticationEventArgs)
' Attach a new application-defined class that implements IPrincipal to
' the request.
' Note that since IIS has already performed authentication, the provided
' identity is used.
e.User = New MyPrincipal(e.Identity)
End Sub
Passport Authentication
This first installment of a two-part series on Microsoft Passport in ASP.NET applications discusses Passport's basic authentication mechanism and demonstrates the use of related .NET classes. It describes the design and implementation of Passport-enabled Web applications and how such applications communicate with client browsers and Passport servers.
Beginning with a general description of how Microsoft Passport acts as an authentication service, it then describes the sequence of events that occurs when a user (normally a browser client) tries to access a Passport-enabled application. The following section demonstrates the necessary setup steps, and the final section explains how to use ASP.NET classes that wrap the authentication-related functionality that the Passport server provides.
Microsoft Passport as an Authentication Service
E-commerce applications on the Internet use electronic means to identify people trying to reach their enterprise resources. For example, when you create a new Yahoo e-mail account, you enter some personal information along with a user name and a password. The name/password pair becomes your identification when you later check your e-mail messages on the site. This simple authentication mechanism is also applicable to e-commerce applications. The login and password pairs are used to identify site users.
The user-authentication mechanisms that e-commerce applications normally have to implement require the following features:
- A graphical user interface (GUI) for sign-up and login
- A database of user information (at least user names and passwords)
- Authentication logic at the Web server
- Log-out functionality, such as deleting (or destroying) server-side session objects
Microsoft .NET Passport, in its most basic form, provides all four of these features wrapped inside an easy-to-use programmatic interface. Passport provides a simple architecture, in which a single .NET Passport class named System.Web.Security.PassportIdentity wraps all authentication functionality. A Passport-enabled Web application developer need only instantiate the PassportIdentity class and use its methods to perform the complete authentication process.
This means Passport-enabled e-commerce application developers can rely on Passport to manage all the authentication features required by their e-commerce sites. In effect, Passport is a reusable authentication component, pluggable directly into an ASP.NET-based e-commerce application, which makes it very suitable for rapid application development.
Single Sign-on
Single sign-on (SSO) is another important benefit of Passport. Microsoft hosts its Passport service on its own servers and allows the use of all Passport-enabled accounts (e.g., all Hotmail and MSN.com accounts) to be authenticated on all Passport-enabled Web applications. This means users with Passport-enabled accounts need to remember only one login password pair to access all partner sites. So Passport not only allows rapid e-commerce application development, but it provides ease for users as well.
On the other hand, if you host your SSO on your own server, you can offer it only to your own user base—not all Hotmail and MSN users. You'll normally find this type of SSO in enterprise integration applications, where the application is meant only for users who belong to a particular trusted domain (e.g., employees of a company).
Microsoft currently sells Passport as a hosted service, like an application service provider (ASP). Passport is not available as a software product or a component you can host on your Web servers. The disadvantage of this strategy is if you want to authenticate your own user base on a Passport-enabled site, you have to implement your own authentication mechanism in addition to Passport.
This disadvantage makes Passport a generally unsuitable authentication solution for enterprise application integration (EAI) projects. In most EAI projects, customers don't want their users authenticated on a third-party server, because third-party authentication unnecessarily exposes their business information. For such applications, SSO solutions from other vendors like Oracle or IBM are better, as they are available as software components that customers can host on their Web servers.
However, B2C e-commerce applications can take advantage of the Hotmail and MSN user base with Passport.