Windows Authorization Manager

Windows Authorization Manager

    AzMan概述

    主要優點

    特色與改進(AzMan由2003至2008改進與新增的功能)

    AzMan Stores

    名詞定義

    AzMan操作

    範例程式碼

    參考網址


 

中英對照表


原文中譯

access control

存取控制

authorization manager

授權管理員

authorization policy

授權策略

Lightweight Directory Access Protocol

輕量級目錄存取協定

business rule

企業規則

application

應用程式

client context

使用者授權背景

 

AzMan概述


授權管理員 (AzMan) 是一個在Windows平台上,基於Role-based access control (RBAC)授權策略所發展的管理工具,可以依據分配的角色 (Role-based)來管理授權以及處理執行時的訪問檢查。 Role-based 的授權策略可以依據使用者的工作性質或職位來分配到不同的角色 (roles),而對應的角色會有不同的訪問權限,讓使用者依工作需求來執行任務 (tasks)。系統管理員用AzMan去管理哪些角色可以去執行那些任務,然後依循業務發展以及角色需求來修改授權內容;以Role-based發展的授權策略,使得授權的考量是以使用者或群體在企業或組織中所扮演的角色為單位,當管理員更改角色所授予的權限,就會套用到全部被分配到此角色的使用者 或群組,而不需要一個一個去改使用者權限。

 

主要優點


  • 降低軟體開發時程以及維護成本

         開發人員不需要花心力去做Access control功能,因為AzMan已經有完整的功能,包括RBAC模型,授權存放區(e.g. Active Directory, SQL database),MMC使用者介面, 支援內建應用程式群組、角色設定及查詢功能,審核性系統整合和系統性能優化

  • 安全性增強

        平台技術經過嚴格的測試和廣泛的使用,並且不斷改善以減少安全性的失誤

  • 平台的整合與調整

          AzMan支援Active Directory (AD) groups, Windows security auditing和MMC,可以正確的整合存取控制系統的對象

  • 常見的RBAC管理

        AzMan提供了易於使用的Role-based的管理,管理員可以不需要受太多訓練就可以使用

  • Role-based發展框架

        AzMan提供了一個易於結合本地或是托管的程序框架,和廣泛的RBAC管理和執行功能

  • 靈活的授權原則

        AzMan可以透過動態輕量級目錄存取協定 (LDAP)查詢或自定義業務規則(BizRules)來定義成員

  • 集中管理

        不同的操作、角色或是任務都可以分組,方便管理

  • 靈活的儲存選項

        提供XML file, AD DS, AD LDS,在Windows Server 2008新增MS SQL Server資料庫來儲存

 

特色與改進 (AzMan由2003至2008改進與新增的功能)


  • 改善授權應用的API

          可以用更簡單的方法來執行任務,如訪問檢查 (access check)和角色檢查 (role check)等

  • SQL資料庫授權存放

         新增以MS SQL Server資料庫來存放授權資訊

  • 支援企業規則群組

        在運作時透過腳本確定成員的群組

  • 支援自製的Azman使用者介面

        允許擴充AzMan MMC管理單元支援使用AD LDS或SQL使用者帳戶

  • LDAP查詢不僅限於用戶對象
  • 額外在log檔紀錄使用中的事件
  • 業務規則默認狀態是禁用的(以前是默認啟用)

 

AzMan Stores


AzMan可以使用以下的授權存放區。

  • XML files
  • AD DS
  • AD LDS
  • Microsoft SQL Server (new for Windows Vista and Windows Server 2008)

 

名詞定義


  • Authorization Store

          一個儲存體,儲存使用者對系統資源存取的授權策略

  • Application

        建立一組應用程式,並針對每個角色(roles)、工作(tasks)和操作(operations)定義一組名稱空間

  • Scope

        在應用程式下,定義出一個範圍來避免意外的資源共享並支援稽核和委派;在此範圍之內,以相同的授權策略來存取隸屬於此範圍底下的資源。一個範圍可以是AD DS或AD LDS底下的一個資料夾,一個URL等。

  • Role

        根據工作職責的分配而定義出角色,每個角色是負責並擁有權力來執行多項工作(tasks)的單元。使用者或群組通常會被分配到一個角色。例如,人事部經理或採購等。

  • Task

        工作是由多個操作 (Operations)或其他工作的組合,一個好的工作名稱的定義可立即反映出工作內容

  • Operation

        是一種受到授權管理員控管的行為,被定義在應用 (Application)的範疇中。通常一個工作 (task)是由多個操作 (Operations)所組成

  • Business Rule

         企業規則(Business Rule)又稱業務規則,是一種與工作相關的腳本,可用來測試某個業務規則,在任何條件的執行下是否允許訪問

 

AzMan操作


 

Step 1: 命令列中輸入AzMan.msc

 

Step 2: 選擇開發模式來開發新的應用程式

 

Step 3: 選擇授權存放區類型,範例中選擇XML file,並指定存取位置

 

Step 4: 開啟新的應用程式

 

Step 5: 命名新的應用程式,範例名稱為Trey Ordering,版本編號為1.0

Step 6: 展開新增的應用程式,在Operation Definitions資料夾裡,按右鍵新增Operation [Operation Definitions->New Operation Definition...],Operation名稱為Submit Order,識別編號為57

 

Step 7: 檢視新增的兩個Operations: Submit Order和Query Order Status

 

Step 8: 選擇Task Definitions資料夾裡,按右鍵新增Task [Task Definitions->New Task Definition...],Task名稱為Order Parts

 

Step 9: 在新增的Task: Order Parts指定具有那些Operations,在範例中選定Order Parts具有Query Order Status和Submit Order兩個操作的權限

 

 

 

 

Step 10: 選擇Role Definitions資料夾裡,按右鍵新增Role [Role Definitions->New Role Definition...],Role名稱為Purchaser

 

 

Step 11: 檢視新增的Role: Purchaser

 

 

Step 12: 定義Role之後,指定這個角色具有執行那些Tasks或Operations的權限,在範例中定義角色Purchaser有執行Order Parts這個Task的權限

 

Step 13: 在定義完operations, tasks, 和roles之後,可以為這些roles建立一個群組,範例中新增了Group: A Datum

 

 

Step 14: 在定義所有的roles之後,需要為應用程式分配一組合適的roles

Step 15: 分配的role可以指派為某個群組,範例將角色Purchaser指派為"A Datum"這個群組底下

 

 

範例程式碼


在操作完以上的流程之後,AzMan授權存放區存有使用者對系統資源的授權機制。下列程式碼將示範如何在Web應用程式中連接到AzMan store,並針對特定的使用者進行授權認證,在經過授權後,使用者可依其操作權限對系統資源進行存取。

在Web應用程式開發上,主要是透過Microsoft.Interop.Security.AzRoles primary interop assembly (AzMan PIA)來提供存取系統授權所需的API。以下範例程式碼採用Windows Server 2008所新增的AzMan PIA 2.0版本,授權機制主要包含三個流程:

  1. 連接AzMan Store並取得IAzApplication2物件之特定的應用程式。
  2. 取得使用者的授權背景。
  3. 判定並取得授權內容,以進行工作指定的操作項目。

 

Step 1: Connect to the AzMan Store and Obtain IAzApplication2

步驟一,在於建立與AzMan store之間的連結,並取得IAzApplication2物件,透過IAzApplication2物件可以取得儲存於AzMan store中,針對特定應用程式的授權機制。

StoreSample connection string

XML file

msxml://c:\AuthPolicy\AzStore.xml

AD DS

msldap://cn=AzStore,cn=AuthPolicy,dc=MyOrg,dc=com

AD LDS

msldap://AzServer:port/cn=AzStore,cn=AuthPolicy,dc=MyOrg,dc=com

SQL

mssql://Driver={SQL Server};Server={AzServer};/AzDB/AzStore

                                      表   AzMan Store儲存類型

 

在Windows Server 2008新增 IAzClientContext3介面類別,下列程式碼示範: 透過Windows logon token作為InitializeClientContextFromToken的參數來初始clientContext。

 

Step 2: Create the Client Context

步驟二,在取得IAzApplication2的物件後,透過此物件的函數可取得並初始特定使用者的clientContext,即 InitializeClientContext2的物件,初始的方法可依據security token, security ID (SID)或使用者名稱 (須避免相同名稱的衝突問題)。在這些方法之中,最快速也最直接的方法是透過security token來取得資訊。

MethodDescription

InitializeClientContextFromToken

Uses the Windows logon token of the userAll 

security IDs are in the tokenthereforethis 

method is the fastest and preferred way to 

initialize the client context because population 

of group SIDs from the domain controller is 

not required.

InitializeClientContextFromStringSid

Use when only the client SID of the user is 

availableAzMan queries the domain controller

 for the group SIDs associated with the client 

SIDSince these lookups arerequiredthis mechanism 

is slower than InitializeClientContextFromToken.

InitializeClientContextFromName

Use when only the name of the user is available

AzMan queries the domain controller for the SIDs

associated with the nameNames can be in the form

of username,domain\usernameor UPN

Using username alone (without a domain specified) 

can result in an incorrect client context if the same 

username is used in a trusteddomainSince these 

lookups are requiredthis mechanism is slower than

 InitializeClientContextFromToken.

InitializeClientContextFromToken2

Use for manual population scenarios such as AD FS 

and AD LDSAfter initializing the empty context

the application adds the SIDsrolesor groups to the 

contextADFS applications typically populate 

roles from group claims associated with the user

AD LDS applications typically populate SIDs.

                                          表   IAzApplication2類別與初始使用者授權相關的函數

 

Step 3: Make Authorization Decisions

步驟三,在取得特定使用者的授權背景後,即可開始判定該使用者的存取權限。判定步驟依序介紹如下:

  • Role Checks: 判別使用者是否屬於AzMan指定的角色。
  • Access Checks: 在確認角色之後,使用AccessCheck函數來判定該使用者對於特定的操作集(Operations)的存取權限,並回傳一個整數陣列,若對應的欄位為0,代表允許此操作(Operation)的存取。

 

 

Role Checks

取得在授權背景中,所有定義的角色。下列程式碼判定使用者是否為Purchaser的角色。

在Windows Server 2008中,新增了函數IAzClientContext3.IsInRoleAssignment,來直接判定是否為特定角色。

Access Checks

 

透過IAzClientContext.AccessCheck函數可判別使用者被授予那些操作(Operations)的權限,參數設定可參見下表說明。

 

 

 

ParameterDescription

bstrObjectName

A string used for run-time auditing.

varScopeNames

An object array where each element contains the string name of a scope 

as defined in the AzMan storeTo use the default application-level scope

set the first element in the array to an empty stringIn previous versions 

the array could contain only one element.

varOperations

The operations that are checked for access permissionThis object array 

contains integers that represents the OperationIDs as defined in the AzMan

store and available through the OperationID property of the IAzOperation 

object contained in the IazApplication2 object.

                                                                   表   AccessCheck參數

下列程式碼透過AccessCheck函數來判別是否有權限來操作operation #57 (Submit Order)和operation #58 (Query Order Status)此兩個操作(Operations)。其中,operation #57和operatoin #58是定義在Task: Order Parts下的操作集,詳細定義可參見AzMan Store

在Windows Server 2008中,新增了函數IAzClientContext3.AccessCheck2,來直接判定針對指定的Operation ID是否有權限來執行操作。

 

 

 

參考網址