• Choose a category
• All
• Classic-Fiction

By Root 5607 0

to the next level. If set, the domain attribute indicates the domain the cookie is valid for. Cookies can be assigned to an entire Internet domain, a subdomain, or even multiple subdomains.

In ASP.NET, the domain attribute in the section determines the value of the domain attribute on the authentication cookie being created.

Add the preceding script to the web.config file of the Web sites named www.contoso.com and blogs.contoso.com and you’ll have them share the authentication cookies (if the client browser recognizes the domain attribute of the cookie, which most modern browsers do).

The effect of the setting is that the primary domain (www) and any other subdomains will be able to handle each other’s authentication cookies, always with the proviso that their web.config files are synchronized on the machine key values.

Note

Setting the domain attribute doesn’t cause anything to be emitted into the authentication ticket; it simply forces all Forms authentication methods to properly set the domain property on each issued or renewed ticket. The attribute is ignored if cookieless authentication is used. The domain attribute of the section takes precedence over the domain field used in the section and is valid for all cookies created in the ASP.NET application.

External Applications to Authenticate Users

Forms authentication also supports having the login page specified in another application in the same Web site:

The two applications must have identical machine keys configured for this to work. If the application is using cookied authentication tickets, no additional work is necessary. The authentication ticket will be stored in a cookie and sent back to the original application.

If cookieless authentication is used, some extra work is required to enable the external application to authenticate for us. You need to set the enableCrossAppRedirects attribute in in the web.config file of both applications.

Upon successful authentication, the ticket is generated and attached to a query string parameter to be marshaled back to the original application.

If the enableCrossAppRedirects attribute is missing and cookieless authentication is used, the external application will throw an exception.

Note

To test this feature in practice, ensure that the section in the web.config file of both applications contains the same values. They need to be explicit keys, not just the AutoGenerate command.

Forms Authentication and Secured Sockets

A hacker who manages to steal a valid authentication ticket is in a position to perpetrate a replay attack for the lifetime of the ticket. To mitigate the risk of replay attacks, you can perform authentication over a secured socket. Using secured sockets also removes the threat represented by applications such as Firesheep (http://en.wikipedia.org/wiki/Firesheep) that can sniff unencrypted cookies.

This means that first you must deploy your login page on an HTTPS-capable server, and second you need to set the requireSSL attribute to true in the section. This setting causes the ASP.NET application to enable the Secure attribute on the HTTP cookie being created. When the Secure attribute is set, compliant browsers send back only the cookie containing the ticket over a resource that is protected with SSL. In this way, you can still use a broad cookie scope, such as the whole application (‘/’) while providing a reasonable security level for the ticket in transit.

If you don’t want to use SSL to protect the ticket, the best you can do to alleviate the risk of replay attacks is set the shortest lifetime for the authentication ticket to a value that is reasonable for the application. Even if the ticket is intercepted, there won’t be much time remaining for the attacker to do his or her (bad) things.

As a final note regarding SSL, consider the following. If requireSSL is set and the user attempts to log