Claims Based Identity Model

Claims based security is based on the concept that the identity of a person can be represented by a set of claims about that person. A claim is a bit of information that describes the person in a way that is digitally useful. Claims typically contain the usual user name, or email, but they can include much more. Information such as roles, phone numbers, zip codes, addresses, anything that is typically used by applications to customize the user experience.

Claims-based identity provides a standard way of acquiring identity information by heterogeneous applications to validate service requests within and outside an organization and also over the Web.

Abstracting Identity with Claims:

Authentication and authorization are two of the most common aspects of the application security. In Windows, security is generally handled using the Kerberos or the NTLM security tokens.

This works well within the boundaries of the Windows ecosystem; however, it gets difficult if the application has to support the users that do not have Windows Active Directory credentials. In the real world, the applications spanning multiple platforms interact with each other and require the security context to be shared. Using a claims-based identity model provides a robust way of handling authentication and authorization across the discrete systems.

Claims Base Authentication:

Claims-Based architecture allows you to delegate authentication logic into another entity. This entity is a “some” layer which abstracts all authentication related coding and gives your application what it needs: is the user authenticated or not, and some information about the user (called claims or assertions) that lets your application take authorization decisions.

How to do it…

Following example demonstrate how you can create a collection of claims from a WindowsIdentity object,

1.    Create a new Visual C# Console Application project in Visual Studio

2.       Add a reference to System.IdentityModel assembly

3.       Open the Program.cs file, and include the System.IdentityModel.Claims and the System.Security.Principal namespaces.

4.       In the Main method, create a new instance of the WindowsClaimSet class, and pass the current context identity as a parameter to the constructor. And then Loop through the ClaimSet object and print the claim information into the console output

5.       Compile and run the project. The result is displayed in the console window:

How it works…

The WindowsClaimSet class inherits from the System.IdentityModel.Claims.ClaimSet. ClaimSet represents a collection of claims (System.IdentityModel.Claims.Claim) associated with an entity. The WindowsClaimSet constructor accepts the current Windows user identity as a parameter and returns a ClaimSet object containing the collection of claims that represent the Windows Active Directory groups of the user. The current Windows user identity is fetched using the WindowsIdentity.GetCurrent method. Generated ClaimSet can be used to create a signed security token that can be passed on to a service to create a security context and implement role-based access control.

A claim is used to identify a user or provide access to a particular resource requested by the user. There are three properties exposed by the Claim class:

ClaimType: It identifies the type of claim. In our example, Sid (security identifier) and Name are the two claim types displayed in the console window.

               Resource: It identifies the resource associated with the claim.

Right: It is a URI representing the Identity or PossessProperty right associated with the claim. PossessProperty determines whether the user has the access to Resource.

Both the Claim and the ClaimSet classes are serialization-friendly, which allows them to be transmitted over service boundaries.

A Brief Introduction to the Web API

Web API provides a simple yet powerful framework for building

REST-based services that can be consume by a broad range of clients including browsers, mobiles, iphone and tablets.

With WebAPI content negotiation, we can return data based on the client requests. What I mean is, if the client is requesting the data to be returned as JSON or XML, the WebAPI framework deals with the request type and returns the data appropriately based on the media type. By default WebAPI provides JSON and XML based responses.

Let’s look at just a few of these new features:

• Convention-based CRUD Actions:
  HTTP  actions (e.g., GET and POST) are automatically mapped to controller methods(also known as controller actions) by their names. For example,on a controller called Products, a GET request such as/api/products will automatically invoke a method named “Get”on the controller. Further, the Web API automatically matches the number of arguments given in the URL to an appropriate controller method. Therefore, the URL /api/products/32 would automatically invoke the Get(long id) method. The same magic also applies to POST, PUT, and DELETE calls.
  
• Built-in Content Negotiation: In MVC,  controller methods that return JSON or XML have to be hard-coded to specifically return one of those content types. But with the Web API, the controller method need only return the raw data value, and this value will be automatically converted to JSON or XML, per the caller’s request.The caller simply uses an Accept or Content-Type HTTP header to specify the desired content type of the returned data, and theWeb API ensures your return value gets formatted appropriately.Rather than returning an object of type JsonResult, you simplyreturn your data object (e.g., Product or IEnumerable<Product>).
  
• Automatic support for OData: By simply placing the new[Queryable] attribute on a controller method that returns IQueryable, clients can use the method for OData query composition.
  
• Self-hosting: With the Web API,  you no longer need to use IIS to host HTTP services. Now your REST services can be hosted in a custom Windows service, console application, or any other type of host you need.