Azure AD以及其的驗證機制是怎樣的

這期內容當中小編將會給大家帶來有關Azure AD以及其的驗證機制是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

什么是Azure AD？ 

Azure AD（簡稱AAD）是在云端提供驗證與授權的服務，隨著功能日趨完善，提供的功能也越來越豐富。通過使用AAD，IT以及應用程序開發人員可以把驗證和授權全權交給AAD來管理，同時也可以輕而易舉得實現跨平臺的認證，以及實現單點登錄的場景。

但是有一點必須澄清，Azure AD與我們熟悉的企業的AD是完全不同的，前者是云服務，只管驗證與授權, AAD更像是傳統AD像云端的擴展，用以滿足更多的是用場景與驗證需求。

Windows Azure AD (獨立模式或聯邦模式)支持不同的驗證和授權場景：
1.Web 應用程序、設備應用、后臺進程/服務訪問一組 Web 服務
2.Web 應用程序、Web 服務、設備應用、后臺進程/服務需要對用戶進行驗證 和授權用戶

Azure AD的驗證機制

Azure AD是Claim Based的驗證與授權，所以在理解Azure AD的驗證機制前，我們有必要理解幾個Claim Based Identity的重要概念。

1. Identity

Identity是我們經常會提到的一個詞，主要涉及于授權與驗證相關的內容。但是簡單從開發人員的角度來看，Identity其實就是從安全角度出發，能夠描述一個用戶或者對象一系列屬性，如名字，郵件地址，電話，部門等。

2. Claim(聲明)

直觀的看，Claim就是Identity的一個子集。Claim包含的屬性越多，應用程序拿到這個Claim的時候也就越了解這個用戶。為什么要叫Claim，這個主要是從應用程序處理它角度來看的。當一個應用程序收到一個Claim，他是不會去活動目錄去驗證這個Claim的內容是否屬實，他只會從Claim里找一個叫做頒發者的屬性，只要頒發者是應用程序信任的，那么應用程序就自動信任這個Claim。

3. Security Token (安全令牌)

在傳遞一系列Claim的時候，在Web Service里，Claim是放在SOAP的包頭里的，在瀏覽器的Web應用里，Claim是放在HTTP POST里的，然后再cache在cookie中。但是不管哪一種方式，這些Claim必須以序列化的方式傳遞過來并存放。

Security Token就是指序列化過的經過頒發機構數字簽名過的一系列Claim。這個數字簽名很重要，這保證了Security Token不會被偽裝。

4. Security Token Service(STS)

STS是付則創建、簽名和頒發Security Token的服務。比較常見就是微軟的ADFS，目前最新版本是Server 2012 R2里的ADFS3.0。

5. Relying Party(RP)

當你創建一個依賴于Claim方式進行驗證的應用程序，這個應用程序就稱作RP。比較通俗的叫法可以是Claims aware app或者claim-based app。

基本的驗證流程

一個客戶端,要訪問一個Web Service（RP），它會首先1. 訪問時獲取基本的Policy，如需要哪些Claim，需要到哪一個STS獲取， 2. 然后客戶端會到STS獲取它的Claim，STS會讓客戶端提供驗證自己的基本信息（如用戶名密碼），驗證后，STS會返回給客戶端包含它所需要的所有Claim的Security Token。 3. 然后客戶端就會把它的Security Token放在他之后所有的SOAP請求里一起提交給Web Service（RP）。 RP只要看到請求里有信任的STS簽名過的Token，就放行，如果沒有，就直接Deny掉。

如果客戶端是一個Browser，請求的是一個Web網站（RP）的場景下，它從STS拿回來的Security Token則會Cache到本地的Cookie中，這樣就能實現SSO，多個Web的RP都可以收到Cache在Cookie中的Token。

注：獲取的Token都是有有效期的，這個有效期都是在STS里設置的，有效期過期后必須重新去STS獲取Token。

聯合身份驗證

Claim Based 驗證的另一大優勢就是可以實現聯合身份認證。

舉一個例子，Fabrikam是一家很大的生產自行車的公司，它有自己的進銷存系統網站，可以給所有的加盟店訪問。Bob是一個加盟店的老板，為了能讓Bob能訪問系統，傳統情況下，Fabrikam會給Bob創建一個他們的賬號，然后按照Bob的加盟店店長角色，給他對應的權限。如果Bob生意越走越大，員工越來越多，每一個員工都要使用Fabrikam的系統，那么Bob就必須讓Fabrikam給他創建不同的賬號來訪問系統。

那么，如果有Bob有員工要轉換角色，或者要離職，這些都是要Bob告訴Fabrikam，然后來回收賬號或者修改賬號權限。這明顯非常麻煩，而且用戶需要有多個賬號，BOB公司的一個賬號，Fabrikam系統的一個賬號，如果Bob還買其他公司的產品，賬號可能就更多了，如果員工角色有改動或者離職了，光回收賬號和修改信息，就有得頭疼的了。

所以，我們要讓Bob的工作自動化，Bob和Fabrikam之間有一個信任關系，也就是Fabrikam信任Bob告訴他的信息。Bob說這個是他的員工，有哪些屬性，Fabrikam就會相信他提供的信息，不需要額外再給他分配Fabrikam的賬號了，這就是聯合身份認證的基礎。

Fabrikam的應用就是一個RP，Fabrikam有自己的STS，RP是基于這個STS。此時BoB的公司也提供自己的STS服務，這兩個公司之間有信任關系。Bob新入職的一個員工Alice要使用Fabrikam的應用系統，她會1.首先在Bob的STS上驗證并拿到Token，2. 然后會把Token發送給Fabrikam的STS，Fabrikam的STS看到了由它信任的Bob頒發的Token，拿到里面的Claims，重新頒發給Alice第二個由Fabrikam簽名的Token。3.此時Alice拿著第二個Token發給系統網站（RP），RP只需要看到有Fabrikam簽名的Token，就可以放行了。

所以在這里作為應用程序，不需要有任何權限上的修改，也不需要關心驗證用戶，只需要看到是Fabrikam頒發的Token即可。這個應用程序和用戶來講，都是非常高效的。

Azure AD 的驗證

上面講了這么多，我們來看一下Azure AD具體是如何操作的。Azure AD的驗證分為兩種場景，一種是啟用了單點登錄模式的，另一種是僅目錄同步模式。下圖，Fabrikam利用Azure AD，啟用了單點登錄模式，而Bob的公司利用Azure AD僅啟用目錄同步，但是他們都使用同一個Azure AD進行驗證與授權，同時他們都要訪問對應的應用(RP)。

Fabrikam首先在Azure上創建了Azure AD，Fabrikam設定好了單點登錄模式，在自己企業環境內有STS服務，Fabrikam也將Bob的域加入到Azure AD中，但啟用的是目錄同步模式，Bob自己企業內無STS服務。

Fabrikam的用戶使用客戶端訪問RP的流程：

1.客戶端首先訪問RP，獲得Policy，包括STS服務器，需要的Claim信息

2.客戶端被重定向到Azure AD進行驗證，單用戶提供用戶名后，Azure AD自動檢測域為單點登錄模式，需要聯合認證

3.客戶端被重定向到企業的STS，STS驗證身份后，頒發Token給客戶端

4. 客戶端被自動重定向回到Azure AD，Azure AD檢驗企業STS頒發的Token通過后，再頒發第二個由Azure AD頒發的有時效（TTL）的Token

注： Azure AD在這里還可以啟用多因素驗證，也就是通過手機或短信再驗證一次用戶，然后再頒發證書。這可以讓Azure AD保護更重要的應用。

5. 客戶端拿著Token在Token有效期內可以正常訪問RP了。所以RP真正信任的僅僅是Azure AD頒發的Token。

Bob的用戶使用客戶端訪問RP的流程：

1. 客戶端首先訪問RP，獲得Policy，包括STS服務器，需要的Claim信息

2. 客戶端被重定向到Azure AD進行驗證，單用戶提供用戶名后，Azure AD自動檢測域為目錄同步模式，由于已經將用戶名以及密碼哈希，以及各種用戶屬性同步到Azure AD中，Azure AD直接驗證通過后，頒發Token。

3. 客戶端拿著Token訪問RP。

由于RP都是只信任Azure AD頒發的Token，所以不管是Fabrikam還是Bob的用戶，RP都是通過的。因此只要把不同的目錄集成到Azure AD中，就可以實現跨域、跨組織的身份驗證和同步，從用戶角度，只需要一個用戶名和密碼，從開發人員角度，只需要使用Azure AD進行驗證和授權即可，而不會因為組織或用戶更改而修改代碼。從IT角度，身份和權限管理，會變得直觀和簡單，如權限回收，在上圖中，如果要移除一個用戶的權限，只需要在Azure AD中操作，那么就能收回該用戶對所有的基于Azure AD的RP的訪問權限。

上述就是小編為大家分享的Azure AD以及其的驗證機制是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。