應(yīng)用程序在任何身份和訪問管理策略中都起著非常重要的作用。應(yīng)用程序使用數(shù)字身份數(shù)據(jù)進(jìn)行授權(quán)，并判斷是否有執(zhí)行資源訪問的權(quán)利。選擇或開發(fā)應(yīng)用程序時(shí)，應(yīng)確保應(yīng)用程序適合身份和訪問管理框架，這一點(diǎn)非常重要。

應(yīng)用程序通常分為兩類：

無論是開發(fā)的應(yīng)用程序還是購買的應(yīng)用程序，都需要將其有效地集成到組織的身份和訪問管理框架中。但是集成涉及的標(biāo)準(zhǔn)不盡相同，這取決于要集成的應(yīng)用程序的種類。

應(yīng)用程序與身份和訪問管理平臺集成的難易程度取決于應(yīng)用程序的體系結(jié)構(gòu)及其用來標(biāo)識用戶的機(jī)制。微軟建議將應(yīng)用程序進(jìn)行標(biāo)識和分類，并著眼于應(yīng)用程序的功能和體系結(jié)構(gòu)的依賴性。如果應(yīng)用程序與組織的身份和訪問管理平臺不兼容，則需要修改應(yīng)用程序或基礎(chǔ)結(jié)構(gòu)。

注意 從應(yīng)用程序開發(fā)的角度出發(fā)，應(yīng)用程序不應(yīng)創(chuàng)建和實(shí)施自己的身份存儲、安全性協(xié)議（用于身份驗(yàn)證、授權(quán)和審核）或數(shù)據(jù)保護(hù)機(jī)制。

本章中的以下部分將探討應(yīng)用程序與微軟身份和訪問管理平臺集成的建議方法。同時(shí)文中還詳細(xì)討論了開發(fā)、測試和部署能識別身份的應(yīng)用程序的技術(shù)。本系列文章中的“開發(fā)能識別身份的應(yīng)用程序”一文詳細(xì)描述了應(yīng)用程序架構(gòu)師和開發(fā)人員需要采取哪些措施以將應(yīng)用程序集成到基礎(chǔ)結(jié)構(gòu)中。

本頁內(nèi)容

	選擇應(yīng)用程序
	開發(fā)應(yīng)用程序

選擇應(yīng)用程序

選擇應(yīng)用程序時(shí)，IT 經(jīng)理通常會盡最大努力確保應(yīng)用程序能夠提供所需功能。遺憾的是，他們往往不會考慮應(yīng)用程序應(yīng)如何與網(wǎng)絡(luò)集成，尤其是關(guān)于身份管理。

第三方應(yīng)用程序可通過以下方式識別用戶：

Exchange Server 2003 提供了與目錄服務(wù)完全集成的應(yīng)用程序示例。Exchange 擴(kuò)展了 Microsoft Active Directory® 目錄服務(wù)架構(gòu)，并向 Active Directory 中的用戶帳戶添加了郵箱屬性。與 Exchange 5.5 不同的是，Exchange 2000 Server 和 Exchange Server 2003 并不維護(hù)單獨(dú)的目錄數(shù)據(jù)庫。與目錄服務(wù)的完全集成為實(shí)施應(yīng)用程序身份管理提供了最為簡捷的方法。

雖然有些應(yīng)用程序未與目錄服務(wù)完全集成，但卻可以使用基于標(biāo)準(zhǔn)的連接對訪問目錄的用戶進(jìn)行身份驗(yàn)證。例如，使用 Kerberos 版本5 驗(yàn)證協(xié)議驗(yàn)證 Active Directory 的應(yīng)用程序，如 SAP R/3 示例，它是虛構(gòu) Contoso 環(huán)境的一部分，本系列文章的其他文章都提及了此環(huán)境。

應(yīng)用程序可能對非組織主目錄的其他目錄服務(wù)進(jìn)行驗(yàn)證。這并不理想，因?yàn)槿绻@樣，就必須對主目錄和應(yīng)用程序所使用的目錄進(jìn)行同步。元目錄產(chǎn)品（如 Microsoft Identity Integration Server 2003，Enterprise Edition (MIIS 2003 SP1)）通過連接到最常見身份存儲的管理代理實(shí)現(xiàn)這種同步。

適應(yīng)性最差的安排是應(yīng)用程序具有專用的私有身份存儲，但不具備可按 MIIS 2003 SP1 所支持的格式導(dǎo)入/導(dǎo)出身份數(shù)據(jù)的工具。在這種特殊情況下，不能使用 MIIS 2003 SP1 同步應(yīng)用程序身份存儲和主目錄服務(wù)，因此，應(yīng)用程序身份存儲中身份的維護(hù)即成為手動(dòng)過程，這不僅成本昂貴，還容易出錯(cuò)。

返回頁首

開發(fā)應(yīng)用程序

如果要開發(fā)內(nèi)部應(yīng)用程序，應(yīng)用程序架構(gòu)師和開發(fā)人員需要考慮以下三種基本方法：

這三個(gè)方面的選擇會影響應(yīng)用程序開發(fā)人員為進(jìn)行身份驗(yàn)證、授權(quán)和審核而需要實(shí)施的內(nèi)容。在集成良好的應(yīng)用程序中，由于底層基礎(chǔ)結(jié)構(gòu)完成了所有工作，因此幾乎不需要實(shí)現(xiàn)識別身份的代碼。

應(yīng)用程序集成涵蓋了前文“選擇應(yīng)用程序”部分探討的相同要素。

啟用身份流

有三種不同模型可用于實(shí)現(xiàn)已驗(yàn)證用戶的身份在分布式環(huán)境中的流動(dòng)，也稱為身份流。這三種模型是：

使用模擬/委派模型

模擬允許使用客戶端的安全憑證來運(yùn)行服務(wù)器流程。服務(wù)器模擬客戶端時(shí)，該服務(wù)器執(zhí)行的任何操作都可使用客戶端的憑證來執(zhí)行。但是，模擬不允許服務(wù)器代表客戶端訪問遠(yuǎn)程資源，這種訪問需要委派。委派比模擬的功能更為強(qiáng)大，而且允許服務(wù)器流程在作為客戶端執(zhí)行操作期間調(diào)用其他計(jì)算機(jī)。

使用受信任的子系統(tǒng)模型

借助此模型，中間層服務(wù)可使用固定的身份訪問下游服務(wù)和資源。雖然應(yīng)用程序可能選擇在應(yīng)用程序級傳播原始呼叫方的身份，但是原始呼叫方的安全上下文并不流過操作系統(tǒng)級的服務(wù)。需要完成此操作的目的是為了支持后端的審核要求，或者支持每個(gè)用戶的數(shù)據(jù)訪問和授權(quán)。

此模型的名稱源于下游服務(wù)（可能是數(shù)據(jù)庫）信任上游服務(wù)以授權(quán)調(diào)用方這一事實(shí)。

使用憑證映射模型

憑證映射模型將一組憑證對應(yīng)于映射表中的另一組憑證。然后可以使用已映射的憑證創(chuàng)建到另一系統(tǒng)的新連接。憑證映射模型可分為兩類：一類使用直接憑證映射，另一類使用稍后可轉(zhuǎn)換為憑證的間接映射“票證”。如果目標(biāo)系統(tǒng)不支持 Kerberos 版本5 身份驗(yàn)證協(xié)議或沒有將 Active Directory 作為其身份存儲使用，則可以使用憑證映射模型。

實(shí)施授權(quán)

一旦應(yīng)用程序識別用戶后，便需要建立一種可通過授權(quán)來控制用戶所訪問內(nèi)容的機(jī)制。應(yīng)用程序授權(quán)模型有兩種：

使用訪問控制列表模型

ACL 模型涉及使用 ACL 來保證資源（如文件、文件夾、打印機(jī)或目錄服務(wù)對象）的安全，ACL 是包含用戶和組以及每個(gè)用戶或組權(quán)限（允許和拒絕）的列表。在用戶請求訪問資源時(shí)，將對用戶的訪問權(quán)限連同該用戶所屬所有組的訪問權(quán)限一并進(jìn)行判斷。然后根據(jù)這些訪問權(quán)限允許或拒絕用戶訪問。

雖然 ACL 模型可與界定明確的永久對象協(xié)同正常工作，但在某些環(huán)境下（如行業(yè) (LOB) 應(yīng)用程序或 Web 應(yīng)用程序）卻無法正常行使其職能。處理這些類型的應(yīng)用程序、工作流應(yīng)用程序和暫時(shí)對象需要不同的模型。

使用基于角色的訪問控制

RBAC 使用角色概念。通常，角色是指組織的職務(wù)稱謂，如“經(jīng)理”、“出納”或“銷售代表”等。RBAC 將這些角色映射到應(yīng)用程序權(quán)限，從而可以根據(jù)用戶的角色完成訪問控制管理。

然后，RBAC 將用戶的角色成員身份轉(zhuǎn)化為應(yīng)用程序權(quán)限。由于權(quán)限是在角色級授予，因此無需檢查特定資源即可查詢和更改角色的權(quán)限。

一旦管理員創(chuàng)建了角色并為這些角色分配了權(quán)限，就很少需要更改角色或權(quán)限。所做的唯一更改是將用戶（或組）分配給角色。

本系列文章中的“開發(fā)可識別身份的 ASP.NET 應(yīng)用程序”一文中，詳細(xì)描述了應(yīng)用程序架構(gòu)師和開發(fā)人員需要采取哪些措施將應(yīng)用程序集成到基礎(chǔ)結(jié)構(gòu)中。

返回頁首	第 7 頁，共 9 頁