WIF basic principle (2) based on declarative identification model

Based on the declarative identification model, it simply means that the user information is used as a declarative condition to provide the user identity to the application. A declaration is a user name, or it may be an e-mail address. The idea now is to configure an external identity system to provide applications with all the information they need to understand the user and the individual requests they make, as well as encryption guarantees for identifying data received from a trusted source.

A declarative identity model makes it easier to implement single sign-on, and the application can completely get rid of the following actions:

1 authenticate the user.

2 Store user account and password.

3 Call the enterprise directory to view the details of the user's identity.

4 integration from other platforms or companies with identity systems.

In the claims-based identity model, the application will make the decision related to the identity based on the declaration provided by the user. This can be anything from a simple application personalization containing the user's name to giving users access to advanced features and resource permissions in the application.
Basic concepts

The following is a brief introduction to the basic terminology of the claims-based identity model.

(1) Logo

The term "identity" is often an ambiguous term. But in order to describe the programming model in wif, the term "identity" is used here to describe a set of features that describe the user or some other entity in the system to be protected. For example, a common Internet site, for an ordinary user, its identity may be the user name, may be gender, or may be a hobby, in short, is a complete entity characteristics.

(2) statement

Treat a declaration as an identifying information, such as a name, e-mail address, age, and membership in a sales role. The more declarations the application receives, the more you know about the user. You may wonder why these are referred to as "declarations" rather than "attributes" that are typically used to describe the enterprise directory. The reason is the way of delivery. In this model, the application does not query the user attribute in the directory. Instead, the user communicates the declaration to the application, which is checked by the application. Each declaration is issued by the issuer, and you have the same level of trust with the issuer as you do with the authority. For example, you trust a company domain controller to make a declaration that is higher than the user's own statement. WIF represents a claim type declaration that has a issuer property to find the issuer of the declaration.

(3) Security token

The user passes a set of declarations and a request to the application. In Web services, these declarations are passed in the security header in the SOAP wrapper. In browser-based Web applications, these declarations are reached from the user's browser via an HTTP post and may then be cached in a cookie if a session is required. Regardless of how these declarations arrive, they must be serialized, which is where the security token is located. A security token is a set of serialized declarations that have been digitally signed by the authority. This signature is important: it assures you that the user does not just generate a large number of statements and then send it to you. You can use unsigned tokens when you do not need or want encryption to be less secure.

One of the core features of WIF is that you can create and read security tokens. The wif and the. NET Framework can handle all cryptographic work and provide an application with a set of readable statements.

(4) Issuing authority

There are many different types of authorities, from the domain controller that issues the Kerberos ticket to the certification authority that issued the X.509 certificate. The authority discussed here is the authority that can issue security tokens that contain declarations. This authority is a Web application or Web service that understands how to issue security tokens. It must issue the correct declaration, provide it to the target relying party and the requesting user, and be responsible for viewing the declaration and authenticating the user itself.

Regardless of which authority is selected, its role in identifying the solution is important. When you exclude an element of authentication from your application through a trust statement, you transfer the responsibility to the organization and ask it to authenticate the user in your name.

(5) Standard

To enable all of these operations to interact, multiple ws-* standards have been used. Use Ws-metadataexchange to retrieve the policy and to structure the policy itself according to the Ws-policy specification. The STS (Security token Service) exposes endpoints that implement the Ws-trust specification, which describes how to request and receive security tokens. Today, most STS can issue tokens in the Security Declaration Markup Language (SAML) format. SAML is an industry-approved XML vocabulary that can be used to represent declarations interactively. Or, in a multiplatform scenario, this allows you to communicate with STS on a completely different platform and implement a single sign-on in all applications.

(6) Browser-based applications

The identity model can also be used for browser-based applications.

First, the user points the browser to the Web application (the relying party application). The Web application redirects this browser to the STS so that users can be authenticated. Managed STS in a simple Web application that can read an incoming request, authenticates the user with the standard HTTP mechanism, creates a SAML token, and responds with a section of JavaScript code that causes the browser to initiate an HTTP POST that sends the SAML token back to the RP. The body of this post contains the declaration of the RP request. At this point, the RP will typically package the declaration to a cookie so that users do not have to be redirected for each request.

(7) CardSpace and logo selector

WIF provides APIs for CardSpace serialization, which can be used to build managed information card issuance and enable information card logons in applications.

The identity selector provides the following features:

Q helps users manage multiple identities for the web.

Q Help the user select the appropriate identification for the specified trust party.

Q helps protect user privacy.

Basic implementation

Before you know the implementation mechanism of a declarative identification model, you should first understand or review the traditional validation patterns. Of course, the Advanced Extensions section of this book will recommend a declarative identity model that does not represent a traditional way of doing poorly, and in fact, practice verifies that they are good enough. Discuss a claims-based identity model, give you a new choice, or use it in a suitable scenario.

(1) IPrincipal interface

The management of identity and access control requires the user information of the current application environment to identify its identity according to the user's information, and to judge the authority according to the identity.

In a. NET application, the user information in the current context is represented by the IIdentity interface. The definition of this interface is shown in listing 15-1 of code.

Code Listing 15-1 IIdentity Interface definition

Public interface IIdentity
    
 {
    
     //Properties
    
     string AuthenticationType {get;}
    
     BOOL IsAuthenticated {get;}
    
     String Name {get;}
    
 }

The primary role of the IIdentity interface is to validate, as can be seen from its properties. The reference to validation would certainly be the thought of authorization.