MSDN Magazine - September 2008 - (Page 56)

The key is to isolate in a protected user interface element—an ASP.NET page in this case—any function that needs to invoke a sensitive service method. By requiring that any user who wants to invoke that functionality pass through a login page first, you guarantee that any subsequent requests originated by that user carry the authentication cookie issued by the application’s membership system. The login page gets credentials from the user and verifies whether the user is authorized to visit the page. If all is fine, the request is authorized and an authentication cookie is generated and attached to the response. From then on, any requests the user makes to the application, including service requests, will carry the cookie. As a result, any invoked services in the AJAX service layer should check for the authentication cookie to ensure that a legitimate user is making the request. Any page that carries security-sensitive operations in ASP.NET AJAX or Silverlight 2 applications should be placed in a protected area of the Web site. To filter access to a specific area, add the following configuration fragment to the web.config file: You can’t avoid public endpoints, but you need a way to recognize authorized users and keep others off your site. Here, the contents of the MembersOnly folder are restricted to authenticated users. Finally, you need to turn on authentication. In this example, I’m enabling ASP.NET forms authentication: Admittedly, this is not rocket science. Once a user has successfully visited the login page, a valid authentication cookie is attached to the response. This cookie will be used for any subsequent request until it expires. It is interesting that this approach works for both ASP.NET AJAX and Silverlight 2. The Silverlight plug-in, in fact, relies on the browser’s underlying infrastructure (which is only visible to plug-ins) to execute remote calls. This ensures that authentication cookies (and any other cookies) are appended to the request. WebService, you can still access the same ASP.NET intrinsic objects using the HttpContext.Current property. In any case, the ASP.NET request context is always available to an ASMX Web service. For a WCF service, things are different. A WCF service can be hosted in IIS either side-by-side with ASP.NET or in compatibility mode. The default configuration is side-by-side with ASP.NET. Requests for a WCF service are received by the ASP.NET run time, but it doesn’t participate in the processing of these requests. Within the worker process, the WCF run time detects incoming requests and processes them through the WCF stack. When ASP.NET and WCF work side-by-side, there are a few side effects to note. For example, you can’t define an access control list to the SVC resource and, more important in this context, the HttpContext.Current property always returns null when accessed from within a WCF service. As a result, there’s no way for the WCF service to grab any information about the ASP.NET logged-in user. In general, the WCF model is designed to work regardless of the hosting environment or transport mechanism. However, security over the AJAX service layer requires a stricter collaboration between WCF and the host ASP.NET environment. This is just what the ASP.NET compatibility mode for WCF addresses. When running in compatibility mode, a WCF service fully participates in the lifecycle of the ASP.NET request. The net effect is that the WCF service has access to the same information as an ASMX Web service. In particular, file-based authorization is supported and, more important, HttpContext.Current is correctly set. Compatibility mode is a global setting enabled at the application level. Individual services, though, are allowed to refuse or accept the mode. To turn on compatibility mode, you need to enter the following fragment in the configuration file: Retrieving User Information from the Service The authentication cookie issued by the application is passed to the Web service or WCF service. But how can the service access this information? Let’s tackle ASMX Web services first. An ASMX Web service is always hosted by the ASP.NET worker process; thus it has access to the HTTP context of the ASP.NET request being processed. If you derive the Web service class from the WebService class defined in the System.Web.Services namespace, then your class will inherit the Context property and will then have access to all of its properties, including Session, Request, Response, and, especially, User. If you choose not to derive your class from 56 msdn magazine Individual services declare their support for compatibility mode through the RequirementsMode property of the AspNetCompatibilityRequirements attribute, which is to be set on the service class, not the contract. Values for the property are Required, Allowed, and NotAllowed. The default is NotAllowed, which means that each WCF service in the AJAX service layer must have the RequirementsMode property changed to either Allowed or Required: [AspNetCompatibilityRequirements( RequirementsMode = AspNetCompatibilityRequirementsMode.Required)] public class TimeService : ITimeService { : } Based on this information, each critical method in a service within the AJAX service layer should incorporate a piece of code that checks the identity of the logged-in user. Here’s an example: public class TimeService : ITimeService { Cutting Edge

Table of Contents Feed for the Digital Edition of MSDN Magazine - September 2008

MSDN Magazine - September 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Cutting Edge Hierarchy ID New Features for Microsoft SQL Server 2008 Prism Data Services Advanced WPF Test Run Security Briefs Foundations { End Bracket }

MSDN Magazine - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.