How to: Host a Secure Service in ASP.NET for Silverlight Applications

Caution:

Note that this approach will not work if you are using the client HTTP stack specified by the ClientHttp property instead of the default browser stack specified by the BrowserHttp property. You could be using this stack to get better support for SOAP faults, for example. The approach outlined in this topic relies on the fact that the default browser shares cookies between .aspx pages and Silverlight controls, which is something that the client HTTP stack does not support. For an alternative approach to using Forms authentication with the client HTTP stack, see How to: Use the ASP.NET Authentication Service to Log In Through Silverlight Applications.

Normally, the site contains some login functionality, such as the ASP.NET Login Control. You should confirm that this is the case. For more information about these controls, see ASP.NET Login Controls Overview.

Note:
If you want users to log in through a Silverlight user interface instead, see How to: Use the ASP.NET Authentication Service to Log In Through Silverlight Applications for information about how to do this.

The service can be a Silverlight-enabled WCF service (.svc), a regular WCF service (.svc), an ASP.NET Web service (.asmx), a regular ASP.NET page acting as a service (.aspx), or even a custom HTTP handler (.ashx).

Note:
If the service is a WCF service but has not used the “Silverlight-enabled WCF service template,” see the note in the “Special WCF Services” section below.

You can use any of the standard ASP.NET techniques for authorization. For more information, see ASP.NET Authorization. For example, to disallow anonymous access, put the service into its own folder (for example, “secure/MyService.svc”) and in the configuration file for this folder (for example, “secure/Web.config”) include the following elements.

<system.web>
     <authorization>
         <deny users="?"/>
     </authorization>
</system.web>

Note that you can also use role-based authorization. For more information, see Managing Authorization Using Roles.

In your service implementation, you can use System.Web.HttpContext.Current.User to discover the current user’s identity. For example:

  [OperationContract]
        public int GetAccountBalance()
        {
// Block unauthorized users. SecurityException will return the correct SOAP Fault for this situation.
            if (!HttpContext.Current.User.Identity.IsAuthenticated) throw new SecurityException();

// Retrieve the data for the current user.
            return Database.GetBalanceForUser(HttpContext.Current.User.Identity.Name);

        }

To use the service from a Silverlight application, no special steps are required. Invoke the service in the same way as you would invoke a non-secure service. When calling the service, if the user is not logged in to the ASP.NET site that hosts your Silverlight application, or if the user is not authorized to call the service, an error will occur. Thus, it is especially important to gracefully handle error conditions when using secure services.

Security Note:
When using this approach with Forms authentication in a production environment, ensure that you are using SSL (HTTPS) to prevent authentication cookies from being stolen during transit.

Windows authentication is useful when you are developing an intranet application where users should not even have to log on because their Windows credentials will be used automatically.

Note:
Before using this technique, consider the impact it could have on non-Windows platforms if they are important to your scenario.

Go to the Tools menu in the browser, select Internet Options, click the Security tab, and select the Local Intranet zone.

To configure settings for this zone, click the Custom Level button near the bottom, find the Logon settings in the User Authentication section, and select Automatic logon only in Intranet zone.

Click OK to return to the Internet Options window.

Click the Advanced tab in the Internet Options window, and scroll down to the Security section at the bottom. Ensure that Enable Integrated Windows Authentication* is selected, and click OK to save the new settings.

Caution:
Using Windows credentials outside of your local intranet has serious security implications.

Other than the browser configuration, no special steps are required to enable Windows authentication when you are using it in conjunction with ASP.NET-based services and Silverlight 4 applications. Follow the same steps as when using Forms authentication.

Because browser-based authentication techniques are used, you must not publish a “full access” cross-domain policy file (<domain uri=”*”/>) for the domain where the service is hosted. Doing so would introduce a security vulnerability.

If you cannot host your XAP file on the same domain as the service, you can publish a limited cross-domain policy file (<domain uri=”your.web.site.domain” />).

If you are using Forms authentication, you must publish the service on the same domain as the rest of your site (that is, the site with which the authentication cookie is associated).

For HttpContext and ASP.NET authorization to work with WCF services, the services must be configured to be in ASP.NET Compatibility Mode. Normally, this is automatically enabled for you when you use the “Silverlight-enabled WCF service template.”

However, if you have not used the template, you need to enable this manually. This could be the case, for example, when you are building WCF REST services. Make sure that the AspNetCompatibilityRequirements attribute appears on your service class in addition to the ServiceContract attribute to enable compatibility.

[AspNetCompatibilityRequirements(RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

Add the <serviceHostingEnvironment> element to the service configuration in the <system.serviceModel> section to enable ASP.NET compatibility.

<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />

For more information, see WCF Services and ASP.NET.