Shulou(Shulou.com)06/01 Report--

In this issue, the editor will bring you about Azure AD and its verification mechanism. The article is rich in content and analyzes and narrates it from a professional point of view. I hope you can get something after reading this article.

What is Azure AD?

Azure AD (AAD for short) is a service that provides authentication and authorization in the cloud. With the increasing improvement of functions, the functions provided are becoming more and more abundant. By using AAD,IT and application developers, authentication and authorization can be fully managed by AAD, while cross-platform authentication and single sign-on scenarios can be easily implemented.

But it must be clarified that Azure AD is completely different from the AD of enterprises we are familiar with. The former is a cloud service. Despite authentication and authorization, AAD is more like a cloud extension of traditional AD to meet more usage scenarios and verification requirements.

Windows Azure AD (standalone mode or federated mode) supports different authentication and authorization scenarios:

1.Web applications, device applications, background processes / services access a set of Web services

2.Web applications, Web services, device applications, background processes / services need to authenticate and authorize users

Verification Mechanism of Azure AD

Azure AD is the authentication and authorization of Claim Based, so it is necessary to understand several important concepts of Claim Based Identity before we understand the authentication mechanism of Azure AD.

1. Identity

Identity is a word we often mention, which is mainly related to authorization and authentication. But simply from the developer's point of view, Identity is actually from a security point of view, can describe a user or object a series of properties, such as name, email address, phone, department and so on.

2. Claim (declaration)

Intuitively, Claim is a subset of Identity. The more attributes the Claim contains, the more the application will know about the user when it gets the Claim. Why is it called Claim? this is mainly from the point of view that the application handles it. When an application receives a Claim, it will not go to the active directory to verify whether the content of the Claim is true, he will only find an attribute in the Claim called the issuer, as long as the issuer is trusted by the application, then the application will automatically trust the Claim.

3. Security Token (security token)

When passing a series of Claim, in Web Service, Claim is placed in the header of SOAP, in the browser's Web application, Claim is placed in HTTP POST, and then cache in cookie. But either way, these Claim must be passed in serialization and stored.

A Security Token is a serialized series of Claim digitally signed by an authority. This digital signature is important, which ensures that Security Token will not be camouflaged.

4. Security Token Service (STS)

STS is a service that creates, signs, and issues Security Token for payment. Microsoft's ADFS is more common, and the latest version is ADFS3.0 in Server 2012 R2.

5. Relying Party (RP)

When you create an application that relies on Claim for authentication, the application is called RP. The more popular name can be Claims aware app or claim-based app.

Basic verification process

A client, to access a Web Service (RP), it will first 1. Access to get the basic Policy, such as which Claim you need, which STS you need to get, 2. The client then goes to STS to get its Claim,STS and asks the client to provide basic information (such as username and password) to validate itself, and after authentication, STS returns to the client's Security Token containing all the Claim it needs. 3. The client then submits its Security Token to Web Service (RP) in all its subsequent SOAP requests. As long as RP sees a Token signed by a trusted STS in the request, it will release it. If not, it will simply Deny it.

If the client is a Browser and the request is for a Web website (RP), the Security Token it retrieves from STS will be Cache to the local Cookie, so that SSO can be implemented, and the RP of multiple Web can receive the Token of Cache in Cookie.

Note: all the acquired Token have a validity period, which is set in the STS. After the expiration of the validity period, you must go to STS to obtain the Token.

Federated authentication

Another advantage of Claim Based authentication is that federated authentication can be implemented.

For example, Fabrikam, a large bicycle manufacturer, has its own purchase, sale and storage system website, which can be accessed by all franchisees. Bob is the owner of a franchise store. In order to enable Bob to access the system, Fabrikam traditionally creates their account for Bob and gives him the corresponding permission according to the role of Bob's franchise store manager. If Bob's business is getting bigger and bigger, there are more and more employees, and every employee has to use Fabrikam's system, then Bob must let Fabrikam create a different account for him to access the system.

So, if there are Bob employees who want to change roles or leave their jobs, Bob should tell Fabrikam, and then reclaim the account or change the account permissions. This is obviously very troublesome, and users need to have multiple accounts, an account of BOB and an account of Fabrikam system. If Bob also buys products from other companies, there may be more accounts. If the employee's role has changed or left, it will be a headache just to recover the account and modify the information.

So, we need to automate the work of Bob. There is a trust relationship between Bob and Fabrikam, that is, Fabrikam trusts what Bob tells him. Bob said that this is his employee, which attributes, Fabrikam will believe the information he provides, and there is no need to assign him an additional Fabrikam account, which is the basis of joint authentication.

The application of Fabrikam is that a RP,Fabrikam has its own STS,RP based on this STS. At this time, BoB's company also provides its own STS services, and there is a trust relationship between the two companies. Alice, a new employee of Bob, wants to use Fabrikam's application system, she will 1. First, verify and get the Token,2 on the STS of Bob. Then the STS that sends the Token to Fabrikam's STS,Fabrikam sees the Token issued by the Bob it trusts, takes the Claims inside, and reissues it to Alice's second Token signed by Fabrikam. 3. At this time, Alice takes the second Token and sends it to the system website (RP). RP only needs to see the Token with Fabrikam signature and can release it.

So as an application here, you don't need to change any permissions, and you don't need to care about authenticating users, you just need to see the Token issued by Fabrikam. This application and users are very efficient.

Verification of Azure AD

With all that said above, let's take a look at how Azure AD works. The authentication of Azure AD is divided into two scenarios, one is single sign-on mode enabled, the other is directory-only synchronization mode. In the figure below, Fabrikam uses Azure AD to enable single sign-on mode, while Bob's company uses Azure AD to enable only directory synchronization, but they all use the same Azure AD for authentication and authorization, and they all access the corresponding application (RP).

Fabrikam first created Azure AD,Fabrikam on Azure and set the single sign-on mode. STS services are available in its own enterprise environment. Fabrikam also joins the domain of Bob to Azure AD, but directory synchronization mode is enabled, and Bob does not have STS services in its own enterprise.

The process for users of Fabrikam to access RP using the client:

1. The client first accesses RP to get the Policy, including the Claim information needed by the STS server.

two。 The client is redirected to Azure AD for authentication. After a user name is provided by a single user, the Azure AD automatic detection domain is in single sign-on mode, which requires joint authentication.

3. After the client is redirected to the enterprise's STS,STS for authentication, the Token is issued to the client

4. The client is automatically redirected back to the Token issued by the Azure AD,Azure AD inspection enterprise STS, and then issues the second TTL Token issued by Azure AD.

Note: Azure AD can also enable multi-factor authentication here, that is, authenticate the user again via mobile phone or SMS, and then issue a certificate. This allows Azure AD to protect more important applications.

5. The client can access the RP normally during the validity period of the Token with the Token. So what RP really trusts is only the Token issued by Azure AD.

The process for users of Bob to access RP using the client:

1. The client first accesses RP to get the Policy, including the Claim information needed by the STS server.

two。 The client is redirected to Azure AD for verification. After a user name is provided by a single user, Azure AD automatically detects that the domain is in directory synchronization mode. Since the user name, password hash and various user attributes have been synchronized to Azure AD, Azure AD will issue Token after direct verification.

3. The client accesses the RP with Token.

Because RP only trusts Token issued by Azure AD, RP is approved for both Fabrikam and Bob users. Therefore, as long as different directories are integrated into Azure AD, you can achieve cross-domain, cross-organizational authentication and synchronization, from the user's point of view, only need a user name and password, from the developer's point of view, only need to use Azure AD for authentication and authorization, and will not modify the code because of organizational or user changes. From the perspective of IT, identity and permission management will become intuitive and simple, such as permission recovery. In the figure above, if you want to remove a user's permissions, you only need to operate in Azure AD, then you can recover the user's access to all Azure AD-based RP.

The above is the Azure AD and its verification mechanism shared by the editor. If you happen to have similar doubts, you might as well refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.