WCF introduces a claims-based approach to security at service boundaries, improving on role-based and permission-based security models. Claims can represent many different types of information including identity, roles, permissions or rights and even general information about the caller that may be useful to the application. A set of claims is also vouched for by an issuer such as a security token service, adding credibility to the information described by each claim – something not present in role-based or permission-based models. An additional benefit of using a claims-based security model is that it supports federated and single sign-on scenarios. This two-part article will explain how claims-based security is supported by WCF, and show you how to implement a claims-based security model for your services. In this first article I’ll start by providing a quick review of the traditional role-based model most .NET applications rely on, and then I’ll compare this model to the claims-based model supported by WCF. In the process, I’ll explain how different security tokens are converted into claims, how the security context for each request is initialized with those claims, and how you can interact with claims to authorize calls. I’ll also explain how to define custom claims for an application, how to normalize different credentials into that set of claims using a custom authorization policy, and how to handle authorization centrally or at each service operation. In the second article I’ll show you how to refine this claims-based authorization model working with custom security principals and claims-based permission demands. I’ll then explain how you can decouple authentication using security token services or CardSpace, and how to work with SAML tokens that carry normalized claims.

Visual Studio is fine for most debugging purposes. Just occasionally, it isn't practicable, or there are other quicker ways of doing it with a user-mode debugger. Edward argues that debugging in MSIL or assembly language is a strangely liberating experience and can be a lightweight route to discovering the cause of elusive bugs. He starts off with a simple introduction to SOS debugging.

WatiN is an easy to use, feature rich framework for Web Application Testing in .Net. This article provides some practical insight into creating automation based on the WatiN framework. It presents a well thought out and proven foundation for general web testing.

Provides a very thorough explanation of what happens during an HTTP request to an ASP.NET page being served up through IIS. A thorough knowledge of this process is invaluable when debugging strange problems, developing ASP.NET custom web controls or developing any sort of web framework.

Do you have an ASP.NET page that performs a long-running (>100ms) I/O request, like making an HTTP request or executing a costly SQL command? Has your ASP.NET web application unexpectedly hit its maximum throughput? Do ASP.NET web requests start queuing when your web server is under significant load? If so this article may help you address these issues.

F# has clean syntax, powerful multi-threading capabilities, and fluid interoperability with other Microsoft .NET Framework languages. We’ll give you an introduction to functional programming concepts and how they're implemented in F#.