Forms Authentication Provider in ASP.NET
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
Forms authentication generally refers to a system in which unauthenticated requests are redirected to an HTML form, using HTTP client-side redirection. Forms authentication is a good choice if your application needs to collect its own user credentials at logon time through HTML forms. 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. The requests are authenticated and authorized by an ASP.NET event handler using whatever validation method the application specifies.
Note that forms authentication is often used for personalization, where content is customized for a known user. In some of these cases, identification is the issue rather than authentication, so it is enough merely to store the user name in a durable cookie and use that cookie to access the user's personalization information.
For detailed information about how to develop ASP.NET applications that use forms authentication, see documentation on the forms authentication provider in the MSDN Library.
Forms Authentication Across Applications
ASP.NET supports forms authentication in a distributed environment, either across applications on a single server or in a Web farm. Several configuration attributes in the <forms> element configuration section must match for all applications participating in shared forms authentication. The directives name, protection, path, validationKey, descriptionKey, and validation in the following example must be identical (unless otherwise noted) across the applications.
<configuration>
<system.web>
<authentication>
<forms name=".ASPXAUTH"
loginUrl="logon.aspx"
protection="all" <!-- Protection must be identical.-->
timeout="30"
path="/" > <!-- Path must have a compatible scope.-->
</authentication>
<!-- Validation and decryption keys must exactly match and cannot
be set to "AutoGenerate". The validation algorithm must also
be the same. -->
<machineKey>
validationKey= "C50B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE"
decryptionKey= "8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F"
validation="SHA1"
isolateApplications="false"
</machineKey>
</system.web>
</configuration>
The encryption and validation keys and the encryption scheme used for cookie data must be exactly the same. If the settings do not match, cookies cannot be shared.
After a cookie has been issued, expiration of the cookie is tracked based on the Expires property value in the cookie itself. This means that if two applications have different timeout attributes, the expiration date and time that was set when each cookie was originally issued is retained throughout the lifetime of the cookie. When a cookie is updated, the cookie's original expiration is used to compute the new expiration. The only time the configuration timeout value is used is when the cookie is initially created.