The ASP.net Web API has a secure ASP.net Web API for Windows Azure AD and Ms Owin components

With the growing importance of Web API roles, the need to ensure that you can confidently use the Web API in High-value scenarios that can expose sensitive data and operations is becoming more urgent.

We can see clearly that the entire industry is looking for a solution to protect the REST API that relies on the OAuth 2.0 standard. In practice, however, there is no detailed guidance on what should be done at the project level. In addition, existing classes and tools in the Microsoft. NET Framework for protecting communications are designed for specific application types (Web UX applications based on postbacks). They do not apply to the Web APIs and their supported multiple client scenarios. As a result, the work of protecting the Web API has become, to a considerable extent, a manual activity. These protections are not necessarily unsafe, but the differences between the solutions are large and require too much custom code.

With the release of Visual Studio 2013, you can put all these annoyances behind you. This release introduces innovative asp.net tools and security middleware from the Microsoft Open Web Interface for. NET (Owin) component, which provides direct protection for your WEB APIs. With a new ASP.net tool and template, you can configure your Web API project to outsource authentication directly to Windows Azure Active Directory (AD) to emit the local project and the Windows Azure AD corresponding entry in the Necessary code.

In this article, I'll show you how to use these new features of Visual Studio 2013 to create a simple Web API that is protected by Windows Azure AD. I'll also show you how to create a test client to demonstrate the actual usage of the API. I'll also take a quick look at the background, and if you want to delve more deeply into the more advanced aspects of this scenario, you can start with it.

Please provide credentials

In the final analysis, the function of authentication is to require the caller to provide a credential that validates its identity or retrieves its properties when the calling direction server sends a message. The server then uses this information to authorize: Determine whether access should be granted, and in which areas the access rights are granted.

Resources typically transfer most of the authentication functionality to an external service provider, often referred to as an authority or identity provider. These providers are responsible for heavy tasks such as letting users log on, assigning credentials, handling lifecycle processes (such as password recovery), providing UI for user authentication, validating credentials on multiple protocols, multiple authentication factor management, fraud detection, and more.

Put these features aside, and the only remaining authentication task is to confirm that authentication succeeded through the selected authority. This work usually involves checking the security token, which is the data fragment that the issuing authority issued to the caller after the success of the authentication.

A security token is typically created according to a specific format, digitally signed by a key that explicitly identifies the authority, and contains some data that uniquely binds the token to the target resource. The resource will look for the accompanying token when it receives the request. If a token is found that conforms to the required validation attributes, the caller is authenticated.

At this level of detail, this pattern is so versatile that it can describe many different authentication methods. I will apply it to this scenario by assigning an advanced role to a specific entity.

Resource Resources will be the ASP.net Web API 2 Project I need to protect. You can apply the authentication requirements on a finer level of granularity. For example, you can define a subset of operations to protect and have other operations accept anonymous callers.

Authority I will configure the Web APIs to transfer the authentication requirements to Windows Azure AD, which is a platform, a service (PaaS) product, for each Windows Azure Subscriber. Windows Azure AD is specifically designed to support cloud-based application workloads. This service holds information about users (attributes and credentials) and the organization structure. You can synchronize its data with Windows Server Active Directory (if you choose to do so), or put all your data in the cloud without having to deploy the infrastructure internally.

Almost every online Microsoft service (Office 365, Intune, and Windows Azure) leverages Windows Azure AD to meet its authentication and directory requirements. With open standards and support for common protocols, you can connect to Windows Azure AD from virtually any application (Web UX, Web APIs, native clients, servers to servers, and so on) and platforms. I'll show you how to register the application in Windows Azure AD and take advantage of its OAuth 2.0 endpoint.

token format and validation The OAuth 2.0 specification does not enforce any specific token formats, but the JSON Web token (JWT) format for the REST scheme (BIT.LY/14EHLE8) has become a fact standard. Windows Azure AD and Microsoft Owin components support the JWT format in the OAuth 2.0 stream. The reason I mentioned this is mainly to provide some background information. The JWT acquisition and authentication mechanisms are all handled by the middleware, and the token format is transparent to the application code.

When a resource relies on an authority to handle authentication, the client is actually decoupled from the client. How the user (and the client application) obtains the token becomes a matter between the user and the authority. This is good for the maintainability of the code, but if you want to see the actual effect of the API, you still need to set up a client. You will learn how to register native clients that support the Web APIs in Windows Azure AD and how to use Windows Azure ad authentication Library (Adal) to enable. NET Rich client applications to pass the W indows Azure AD authenticates users and obtains tokens to protect calls to the Web API.

Figure 1 shows the elements of the solution that I will build. If you don't understand some of these tags at this point, don't worry: when I demonstrate the development of the solution, I'll explain it all.

Figure 1 Architecture for End-to-end Solutions

Creating a Web API project

To create a Web API project, you need to use the new ASP.net tools and templates in Visual Studio 2013. Open Visual Studio and create a new ASP.net Web application project. In the New Project dialog box, select the Web API template. Click the Change Authentication button.

The Out-of-the-box authentication methods that you can select for the Web API are displayed, as shown in Figure 2 . Select an organization account where you can use Windows Azure AD as an authority. (For more information on all options, see Bit.ly/1bhwngl.) The goal here is to collect Web API feature information that is important from an identity management perspective, and decide which Windows Azure AD instance (often called "tenant") is configured to handle authentication.

Figure 2 Organization Account Authentication dialog box