Using WIF for single-point logon Part II-Basic Principles of Windows identity Foundation

In the previous article, we have used WIF to build a simple authentication program based on mvc4. In this article, we will discuss what WIF is, and how it works. Then, starting from the next article, we will implement the Single Sign-On function.

Challenges of identity

As mentioned in the previous article, most developers are not security experts. Many people feel very uncomfortable with identity verification, authorization, and user experience personalization. Traditional Computer Technology courses usually do not teach these topics, so these things are often highlighted in the second half of the software development cycle. Today, hundreds of web applications and services in a company are nothing new. Many companies have their own set of user identities, in addition, most companies do not use specific authentication methods. Developers know how boring it is to support identity for every program, and IT experts know how expensive it is to manage the result sets of these programs. A useful step to solve this problem is to centralize user accounts in the enterprise directory. Usually only IT experts know the most effective way to query directories, but now this work is usually handed over to developers. In addition, in the face of mergers, acquisitions, and partnerships, developers may need to access multiple directories and use multiple APIs. At Microsoft
. In the. NET Framework, many different methods of identity identification are supported in the program, and each communication framework processes identity differently. They adopt different object models, different storage models. Even in ASP. NET, developers may be confused about where to find the identity: should the httpcontext. User attribute be used? Or thread. currentprincipal? Improper use of passwords leads to rampant phishing. So many programs do their own thing, it is difficult for the company to upgrade to powerful authentication technology.

Better solutions

One way to solve these problems is to avoid creating custom identity management channels and user account databases in each new program. However, developers who rely on corporate directories still suffer from mergers, acquisitions, and partners, and may even be blamed for poor performance due to inefficient queries in other programs that drag down directories. The declared solution described in this article does not require developers to connect to any specific enterprise directory to query the details of user identity. On the contrary, the user requests to arrive together with the identification information required by the program. When a user request with these declarations arrives, the user has already passed the verification, and the application does not have to worry about managing or searching for the user account. You only need to focus on the business. Processing authentication outside the application can bring many benefits to developers, IT experts and users. Simply put, fewer user accounts need to be managed by everyone. the centralization of Identity Authentication makes it easier to upgrade as it develops to a strong authentication method, this is true even if it is associated with other platforms and organizations. This article will help you, as a developer, understand the declarative identity model and use the new Microsoft framework windows
Identity Foundation (WIF.

What is Windows identity foundation?

Windows identity Foundation (WIF) is a set of. NET Framework classes. It is used to implement the declaration-based identification framework in the program. By using it, we will feel the benefits of the declared identity model described in this article. Windows identity foundation can be used for any. Net-based
Web applications or services of Framework 3.5 SP1 or later versions. WIF is only part of the Microsoft Identity and access platform software family, which implements an interoperable identity metasystem sharing industry vision. Including the Active Directory Federation Service (ADFs) 2.0 (formerly known
"Geneva" server), Windows cardspace 2.0, and Windows identity Foundation (formerly known as "Geneva" framework) are derived from Microsoft's new core part of a declarative access policy. Refer to identity
Management in Active Directory to obtain more information about the ADFs and cardspace components.

Declarative identity Model

When you create an application with claim-aware, the user presents his identity to the application, which is represented by a set of declarations (see figure 1 ). One statement may be a user name, and the other statement may be an email address. The idea here is that an external identification system is configured to provide the program with the user information it needs to know for every request initiated by the user, and the received identity data are encrypted and protected by trusted sources.

Figure 1 Statement presented by the user

Based on this model, single-point logon is easier, and applications do not need to do the following:

• Verify user identity
• Store user accounts and passwords
• Call the enterprise directory to query user ID details
• Integrate the identification system from other platforms or other companies

Based on this model, the application processes all identifiers through user-provided declarations, from simple user names to authorizing users to access advanced features and resources. Introduction to declarative identity

As mentioned above, many strange terms may have emerged. Let's explain these terms with an example in our real life.

Suppose you want to watch a documentary at a cinema, consider the following factors:

1. This documentary contains a plot that is not suitable for minors to watch. Therefore, cinema employees need to show your ID card to verify whether you are suitable for watching. When you pull out your wallet, you find that your ID card is lost and your driver's license has expired.

2. If you decide not to watch the premiere, you can get a new driver's license from the nearby DOL (Department of licensing.

3. Check whether you are consistent with the photo in the record. You may also be asked to test the visual table. When he believes that you are indeed you, he will send you a new driver's license.

4. When you go back to the cinema and show your new driver's license, the staff confirms that you are really old enough to watch the film and will give you a ticket for the next movie.

The process of this example is demonstrated.

The above example is quite common. Next, let's abstract it into our authentication:

Assume that our system includes a user (subject, subject) and the program to be accessed. In the above example, this user is the person who wants to watch a movie. Generally, the subject can be anything, whether it is a real user or an unattended program identifier. An application can be a website, Web Service, or any software that requires authentication and authorization. The line in the identifier is called the relying party (RP ). In the above example, RP is the cinema and its staff. The system may include one or more identity providers (
Provider, ip ). IP is an entity that recognizes subject. It knows how to verify the subject, as in the above example, DOL knows how to compare the photos in the archives with the customer's face; it knows about the customer, just as Dol knows the birth date of every driver in its region. IP is an abstract role, but it requires specific components: directories, user system information library, and identity authentication system. These are some examples of IP addresses used to fulfill their responsibilities. We assume that subject has multiple standard ways to use IP addresses for authentication and receive the necessary user information returned (the birth date in the preceding example ). We call this user information a claim ).

The word Declaration has finally begun. A declaration is an entity's statement of subject. This statement can be anything associated with the subject, whether it is an attribute such as the birth date or the subject belongs to a specific security group. Declarations and simple attributes are different. Declarations are usually associated with the entities that issue them. This is an important difference: it provides a standard for you to decide whether to trust this subject. Looking back at the example above, the date printed on the driver's license is a very sloppy date, and the cinema staff trust the former rather than the latter.

The abstract process is described. The following describes the process in detail:

1. The subject wants to access the RP application through some means (browsers, rich clients, and so on. The subject first understands the RP policy. Determine the ID trusted by the RP, the declaration required, and the security protocol to use.

2. The subject selects an IP trusted by the RP, detects its policy, and learns what security protocol to use. Then, send the request to the IP address and issue a token that matches the RP requirement. This process is the same as sending a dol request for an archive containing the date of birth. The subject must provide some proofs for IP Address Identification. The details of the Protocol to be used are described in the IP policy.

3. The IP address processes the request. If the request meets the requirements, it obtains the required declared value and sends it back to the subject in the form of a security token.

4. The subject receives the Security token from the IP address and sends it together with the initial request to the RP program.

5. RP
The program checks the passed-in token and verifies that it meets all requirements (whether it comes from a trusted IP address, whether the format is correct, whether it has been tampered with, and whether it contains the correct declaration set, and so on ). If everything meets the requirements, the RP permits access by the subject.

Well, after learning about the basic process of declarative identity, let's take a look at how WIF works.

This section describes how WIF processes authentication for ASP. NET programs.

1. The front-end of the WIF application is located in the ASP. NET pipeline. When the user request page fails to be verified, WIF redirects the browser to the ID provision (IP) page.

2. Here, the IP address authenticates the user, No matter what method is used (a user and password page may be displayed, or Kerberos or other methods may be used ). Then generate a token and send it back together with the required declaration.

3. the browser posts the token obtained from the IP address to the application, and WIF intercepts the request again.

4. If the token meets the application's requirements (that is, from the correct IP address, including the correct declaration, etc.), the user is deemed to have passed the verification. WIF then places a cookie and creates a session.

5. the Declaration in the passed-in token can be used by code in the program. At this time, the control will be handed over to the application.

As long as the session cookie is valid, subsequent requests do not need to go through this process again, because the user has been considered to have passed authentication.

The WS-Federation protocol used by WIF mainly has two HTTP modules to handle these tasks: wsfederationauthenticationmodule (wsfam) and sessionauthenticationmodule.

Using WIF in applications comes down to the following three points:

1. Configure the application so that the HTTP module of WIF can sit at the front end of the ASP. NET pipeline.

2. Configure the WIF module so that they reference the target IP address, use the correct protocol, protect the scheduled resources of the application, and execute the required application policies.

3. When the application logic is required, access the declared value from the application and process it when the user identity attribute is required.

Iclaimsidentity and iclaimsprincipal

WIF provides two iidentity and ipricipal extensions: iclaimsidentity and iclaimsprincipal, which are used to process declarations in the WIF pipeline. Their instances exist in the httpcontext. Current. User attribute in the ASP. NET program. You can use them like the common iidentity and iprincipal programming models, or convert them into correct instances and use their new features.

Iclaimsidentity is defined as follows:

public interface IClaimsPrincipal : IPrincipal  {     // ...      // Properties     ClaimsIdentityCollection Identities { get; }  }

Because iclaimsprincipal is an extension of iprincipal, all common functions (such as isinrole) are supported.

The only thing worth noting is the identities set, which is actually the value of an iclaimsidentity group. Let's take a look at the definition of iclaimsidentity:

public interface IClaimsIdentity : IIdentity {     // ...       ClaimCollection Claims { get; }  }

Most of the members of this interface are saved here, leaving only the most important one, that is, a group of declarations related to the current user. So what is the statement:

public class Claim  {     // ...     // Properties     public virtual string ClaimType { get; }     public virtual string Issuer { get; }      public virtual IClaimsIdentity Subject { get; }      public virtual string Value { get; } }

I am saving other members again. The attributes listed are basically used by name:

■ Claimtype indicates the declared type: Date of birth, role, and group membership. These are good examples. WIF has many constants that represent declared type names. However, you can easily define your own types if needed. A typical declaration type is represented by Uri.
■ Value is obvious, that is, the declared value. Although it can be expressed by other CLR types, it is usually a string. (For example, the date of birth)

■ Issuer indicates the name of the IP address currently declared for release.

■ Subject indicates the iclaimsidentity of the current claim and the identifier of the referenced subject.

Let's take a simple example. Assume that your program has configured WIF to use a declarative identity. Authentication occurs at the beginning of the session, so during the execution process, you can assume that the user has passed authentication. At a specific point in your code, you need to send an e-mail to your users. Therefore, you need to obtain her email address. This can be written in WIF:

IClaimsIdentity identity = Thread.CurrentPrincipal.Identity as IClaimsIdentity; string Email = (from c in identity.Claims               where c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Email               select c.Value).SingleOrDefault();

The first line of code obtains the current iclaimsidentity from the current thread, and the second line of code obtains the e-mail address from the current declared set using LINQ. The query conditions are intuitive: Query all declarations to see which type is the email declaration type and return the first found result. The Code demonstrated above does not indicate the Protocol or certificate type used by the user. This means that you can make any changes in the authentication code, and the code here does not need to be changed.

Summary

This time we talked about the declared identity and the basic working principles of WIF. In the next article, we will use these wonderful features of WIF to build our single sign-on implementation.