有效地設計角色

在許多案例中，角色型安全性是一種非常有效的機制，但在某些情況下，其效率較低。 在決定將角色型安全性套用至特定應用程式的位置和方式時，您應該考慮一些因素。

用戶和數據特性和角色的適用性

角色很適合用來描述使用者群組的特性，並在此基礎上篩選那些使用者可以執行的動作。 通常，做法是建立可反映使用者在組織內位置的角色，例如「經理」和「告訴者」、「管理員 管理員」和「讀者」、「專案一員工」和「專案二員工」角色。在這種情況下，存取的數據與用戶相當一般，角色可以有效率地用來強制執行商務規則，例如：

• “經理可以轉移任何金額。 告訴者只能轉讓高達10,000美元。

• “管理員 主義者可以改變任何事情。 其他人只能讀取。

• 「Project One 員工可以存取特定資料庫。 沒有人可以。

使用者可能會自然而然地落入多個角色，視角色如何建立企業組織結構的模型而定。

不過，當安全性存取決策取決於特定數據特性時，角色無法正常運作。 例如，很難使用角色來反映複雜的用戶數據關聯性，如下所示：

• 「特定經理只能存取其報告的人員數據。

• 喬消費者可以查閱他的賬戶餘額。

在這種情況下，安全性檢查通常必須在資料庫本身進行，因為要考慮到所存取數據的內在特性會比較容易。 這表示您必須使用 模擬 將用戶端身分識別傳遞至資料庫，並讓資料庫驗證要求。 這可能會影響效能，而且可能會影響應用程式的設計，例如，在特定使用者身分識別下開啟連線時，連線共用可能無法運作。 如需相關問題的討論，請參閱多層式應用程式安全性和用戶端模擬和委派。

角色型授權原則的複雜性和延展性

您設定的任何安全策略，都只會像部署應用程式的系統管理員一樣有效。 如果系統管理員根據安全策略將使用者指派給正確的角色時犯了錯誤，您的原則將無法如預期般運作。 問題最有可能在下列情況下發生：

• 您已建立一個非常複雜的角色型原則，其中有許多角色和用戶對應至許多角色。
• 您可以使用模棱兩可的準則來建立角色，以供應屬於這些角色的人員使用。
• 安裝應用程式的網站有許多使用者，而且用戶經常在組織內移動，並隨著您所建立的角色而變更。
• 安裝應用程式的站臺上有許多系統管理員負責，因此熟悉應用程式安全性需求的系統管理員可能不熟悉必須使用該應用程式的大量使用者群組。 當使用者在組織內移動時，這是特別關心的問題，這類信息必須妥善溝通。

此外，隨著指派給應用程式的角色數目增加，COM+ 必須花費在查閱這些角色的呼叫端成員資格的時間量，效能可能會降低。

若要管理複雜度並減輕這些疑慮，您可以使用下列指導方針：

• 選擇自我描述性的角色名稱。 盡可能清楚哪些用戶應該屬於哪些角色。
• 讓您的角色型原則盡可能簡單（且沒有更簡單）。 選擇盡可能少的角色，同時維護有效的原則。
• 請清楚記載您為系統管理員建構的角色型原則，不論角色成員資格是否明顯（對您而言）。 特別是，使用每個角色可用的描述字段來描述角色的意圖。 如果您通常無法描述誰應該屬於幾個句子的角色，它可能太複雜。
• 強烈建議您應用程式的系統管理員使用使用者群組填入角色，而不是個別使用者。 這是更可調整的解決方案。 這可讓您更輕鬆地在組織內移動時重新指派或移除使用者，並讓系統管理員與通訊中的一定數量監督和問題隔離。

相關主題

安全性界限

安全性呼叫內容資訊

安全性內容屬性

使用客戶端授權的角色