AzureAD以及其的驗證機制是怎樣的

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Azure AD以及其的驗證機制是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

10年積累的網(wǎng)站建設(shè)、成都網(wǎng)站制作經(jīng)驗，可以快速應(yīng)對客戶對網(wǎng)站的新想法和需求。提供各種問題對應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認識你，你也不認識我。但先網(wǎng)站設(shè)計后付款的網(wǎng)站建設(shè)流程，更有莊河免費網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

什么是Azure AD？ 

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

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

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

Azure AD的驗證機制

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

1. Identity

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

2. Claim(聲明)

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

3. Security Token (安全令牌)

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

Security Token就是指序列化過的經(jīng)過頒發(fā)機構(gòu)數(shù)字簽名過的一系列Claim。這個數(shù)字簽名很重要，這保證了Security Token不會被偽裝。

4. Security Token Service(STS)

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

5. Relying Party(RP)

當(dāng)你創(chuàng)建一個依賴于Claim方式進行驗證的應(yīng)用程序，這個應(yīng)用程序就稱作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網(wǎng)站（RP）的場景下，它從STS拿回來的Security Token則會Cache到本地的Cookie中，這樣就能實現(xiàn)SSO，多個Web的RP都可以收到Cache在Cookie中的Token。

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

聯(lián)合身份驗證

Claim Based 驗證的另一大優(yōu)勢就是可以實現(xiàn)聯(lián)合身份認證。

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

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

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

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

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

Azure AD 的驗證

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

Fabrikam首先在Azure上創(chuàng)建了Azure AD，F(xiàn)abrikam設(shè)定好了單點登錄模式，在自己企業(yè)環(huán)境內(nèi)有STS服務(wù)，F(xiàn)abrikam也將Bob的域加入到Azure AD中，但啟用的是目錄同步模式，Bob自己企業(yè)內(nèi)無STS服務(wù)。

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

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

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

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

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

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

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

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

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

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

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

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

上述就是小編為大家分享的Azure AD以及其的驗證機制是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

當(dāng)前名稱：AzureAD以及其的驗證機制是怎樣的
本文URL：http://www.muchs.cn/article0/pdhjio.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站設(shè)計公司、虛擬主機、響應(yīng)式網(wǎng)站、網(wǎng)站營銷、定制開發(fā)、App設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)