• Choose a category
• All
• Classic-Fiction

By Root 5438 0

still try to access the services via the public URL. In this case, though, because the service IIS endpoint is also placed behind an authorization section, they will receive an HTTP 401 error code (unauthorized access). The outsider call will pass only if the outsider can show a valid authentication cookie. But this can happen only if a cookie theft has occurred previously. However, this is all another problem that relates to the security of the Web site rather than to the security of the services in the HTTP façade.

The only viable alternative to using cookies and ASP.NET Forms authentication is to install client certificates on all client machines.

Trusting the HTTP Façade

Should WCF and Web services do something on their own to keep outsiders off the site? If you place service endpoints behind a protected area of the site, you’re as safe as with any other ASP.NET pages based on Forms authentication. To give you an idea, if you combine Forms authentication with HTTPS you have the same security level currently used by online banking applications and payment sites.

It’s therefore safe for the middle tier to trust the upper HTTP façade and accept any calls coming down the way. However, nothing prevents you from implementing an extra check for authorization within the body of service methods. In this case, though, you need to access credentials information from within the service.

AJAX-enabled services can carry this information only via the authentication cookie or client certificates. Programmatically, a service gets user credentials via intrinsic objects of the run-time platform. ASP.NET XML Web services live within the ASP.NET runtime and have full access to the ASP.NET intrinsics, including the User object.

By default, instead, WCF service calls are processed by the WCF runtime, which lives side by side with ASP.NET, but it’s not a part of it. As a result, a WCF service method can’t access the HTTP request context and put its hands on the User object. The only possible workaround is running all the WCF services hosted by the site in ASP.NET compatibility mode.

You turn compatibility mode on in the configuration file, as shown here:

...

In addition, each service is required to express its explicit approval of the model. A service does this by decorating the service class—not the service contract—with the AspNetCompatibilityRequirements attribute, as shown here:

[AspNetCompatibilityRequirements(

RequirementsMode = AspNetCompatibilityRequirementsMode.Allowed)]

public class TimeService : ITimeService

{

...

}

Note that, by default, a WCF service has the RequirementsMode property set to NotAllowed. If this value is not changed to either Allowed or Required, you get a run-time exception as you attempt to make a call to the service.

Note

WCF services have been designed to be independent from binding and transportation. By turning on ASP.NET compatibility mode, you break this rule because you make the service dependent on IIS as the host and HTTP as the transportation protocol. On the other hand, services in the HTTP façade are just Ajax-specific services so, in this regard, enabling ASP.NET compatibility is actually a natural choice.

JSON Payloads

When you call server-based code you likely need to pass input data and wait to receive some other data back. Clearly, a serialization format is required to transform platform-specific data (for example, a .NET object) into an HTTP network packet. For years, this field has been the reign of XML. To a large extent, this is still the reign of XML, but not when a Web browser is used as the client.

Shorthand for JavaScript Object Notation, JSON is the de facto standard format for browsers and Web servers to exchange data over HTTP when a script-led request is made. The main reasons for preferring JSON over XML can be summarized by saying that, overall, JSON is simpler than full-blown XML and gets a free deserialization engine in virtually any