Federated identity: Using WIF to implement ASP.net passive authentication

The goal of federated security is to provide a mechanism for establishing a trust relationship between domains, so that users who authenticate with their own domain will gain access to applications and services that are authorized to be available to other domains. This makes it possible to use an authentication method such as single sign-on, which eliminates the cost of extending applications to trusted parties without having to configure and manage duplicate accounts for users in multiple applications and domains.

In the Federated security Model, an identity provider (IdP) performs authentication and issues security tokens through the Security Token Service (STS). These tokens assert information about the authenticated user: the user identity and other possible information, including roles and finer-grained access rights. In the Federated technology field, this information is called a declaration, and declarative access control is the core of the joint security model. In this model, applications and services authorize access to attributes and functionality based on claims from trusted authorities (STS).

Platform tools such as Windows Identity Foundation (WIF) greatly reduce the difficulty of supporting this kind of federated authentication. WIF is an identity model framework for building claims-based applications and services that support SOAP based (active) and browser-based (passive) joint scenarios. In the November 2009 issue of MSDN Magazine, "Implementing claims-based Authorization through WIF," I focused on how to use WIF in Windows communication Foundation (WCF). In this article, I described how to implement a claims-based security model for a WCF service and how to migrate to federated authentication.

In this follow-up article, I will focus on passive syndication. I will describe the passive-federated communication process, introduce several ways to support syndication in asp.net applications, discuss claims-based asp.net authorization methods, and then introduce single sign-on and single logoff scenarios. At the same time, I will introduce the basic WIF features and components that support passive joint scenarios.

Passive Joint Foundation

The passive joint scheme is based on the Ws-federation specification. The specification sets out how to request security tokens, how to publish and obtain federated metadata documents, and thus simplifies the process of establishing trust relationships. Ws-federation also provides a single sign-on and logoff process, as well as other joint implementation concepts.

Ws-federation discusses a number of details about unions, some of which are devoted to browser-based unions, which rely on HTTP get and POST, browser redirection, and cookies to achieve the goal.

Some aspects of passive joint messaging are mainly based on ws-trust specifications. For example, when requesting a security token for STS, the passive union takes the form of a browser-compatible request security token (RST) and RST response (RSTR). In a passive joint scenario, I refer to RST as a login request message, which RSTR called a login response message. The Ws-trust specification focuses on SOAP (active) syndication, such as the Union of Windows clients and WCF services.

Figure 1 is a simple passive joint scheme.

Fig. 1 Simple passive joint scheme