Udostępnij za pośrednictwem


Authentication Options for Mobile Devices 

This topic discusses the authentication options for ASP.NET mobile pages and controls. It addresses some complexities of authentication on mobile devices, and discusses these authentication methods:

  • Windows authentication

  • Passport authentication

  • Forms authentication

  • Authentication on devices that do not support cookies

Windows Authentication

Internet Information Services (IIS), in conjunction with ASP.NET, can negotiate Microsoft Windows-based authentication with the client. In an unsecured application (one in which authentication is set to Anonymous), the identity of the requesting user is never considered. Instead, the request is executed using a default account set up during IIS installation.

Using Internet Services Manager, you can choose from the following Windows authentication models: Basic, Digest, and Integrated Windows. You can configure these using the Internet Services Manager snap-in for Microsoft Management Console. IIS negotiates the credentials based on which authentication methods the browser supports, and which authentication methods are enabled for the application.

Basic Authentication

Many mobile devices on the market today support only Basic authentication. Basic authentication is the most widely supported credential exchange mechanism but, by itself, is not secure because there is no encryption.

Caution noteCaution

Basic authentication transmits the user name and passwords in clear text by default. It is therefore recommended that you use HTTPS for this and other sensitive information.

Passport Authentication

ASP.NET does not support using Passport authentication with mobile devices.

Forms Authentication

Forms authentication is a part of the .NET Framework architecture that enables you to authenticate users without IIS authentication. The general sequence of events is.

  1. The client requests a page.

  2. If the user is not already authenticated, the browser is redirected to a login form.

  3. The client provides credentials in a form posted back to the server.

  4. Your application validates the credentials. If the user is validated, your application writes a forms authentication ticket (cookie) to the client and redirects to the originally requested page.

  5. In subsequent requests, the authentication cookie is checked, and if it is valid, the requested page is served directly.

Step 4 creates a problem for some devices that do not support cookies. The RedirectFromLoginPage method writes the authentication information into the query string. To keep the user from being redirected to the logon page for every request, the authentication information can be presented in each request as part of the query string. ASP.NET provides a method for carrying data such as this in the query string for relative URLs.

For an example of how to perform forms authentication, refer to the MobileFormsAuthentication class overview.

Caution noteCaution

Form authentication sends the user name and password in clear text by default. It is therefore recommended that you use HTTPS for this and other sensitive information, and specify set the requiresSSL attribute of the <forms> element in the Web.config file. If a device does not support SSL directly or through the gateway, and it tries to access a page that requires SSL, an error message will be displayed to the user.

Authentication on Devices that Do Not Support Cookies

Browser authentication models typically use cookies for tracking the user authentication. Many mobile devices do not support cookies and are therefore unable to authenticate by this means.

Providing Basic authentication for the widest array of devices possible adds value for the developer targeting mobile devices.

Cookieless authentication requires that an authentication ticket be accessed in another location. In forms authentication, if the cookie is not present, the ASP.NET authentication module checks for it in the query string. You implement this by including the session ID in the query string. This requires rewriting all links on a page to include the authentication ticket conditionally based on these factors:

  • Is the application configured to persist cookieless data? This is determined by the setting of the CookielessDataDictionary property of the IPageAdapter interface.

  • Does this device require cookieless authentication?

    NoteNote

    You cannot configure an individual device for cookieless authentication.

The CookielessDataDictionaryType attribute in the <mobileControls> element must be set in order for authentication to work properly on cookieless devices, as well as in devices that have the SupportsCookieWithRedirect attribute set to false. By default, the CookielessDataDictionaryType attribute is set to CookielessData in the Machine.config file. To override this behavior for a single application, you must set the CookielessDataDictionaryType attribute to an empty string ("").

Be aware that some devices and browsers currently require fully qualified URLs in response to an HTTP redirect. Set the UseFullyQualifiedRedirectUrl attribute to true in the <system.web> element of either the Machine.config file or Web.config file (at the application level). For more details, see Redirecting to an ASP.NET Mobile Web Page.

For more security recommendations, see Securing Applications and ASP.NET Web Application Security.

See Also

Reference

CookielessDataDictionaryType

Concepts

Designing Secure Mobile Web Form Pages
Securing Applications

Other Resources

ASP.NET Web Application Security