我有一個C＃.net應用程序，它既服務於公司的內部用戶，也服務於外部客戶。我需要進行細粒度的授權，比如誰訪問什麼資源。所以我需要基於資源或基於屬性的內容，而不是基於角色的授權。Web應用程序的細粒度授權
什麼在我腦海中是要麼：
第一種方法的問題是它不是集中式的，也不是標準的，因此其他系統不能將其用於授權。
第二種方法的問題是它可能較慢（由於每個資源需要額外的調用）。此外，我不確定市場上的應用程序是否支持XACML等標準授權以使未來的集成更容易。
因此，一般來說對於應該爲內部用戶和外部客戶提供服務的Web應用程序，細粒度授權有什麼好的做法？
我肯定會去外部授權。這並不意味着它會變慢。這意味着您已將業務邏輯完全分離了訪問控制。
概述 XACML是一個很好的方法。 TC非常活躍，諸如波音，EMC，退伍軍人管理局，Oracle和Axiomatics等公司都是活躍成員。
XACML架構可確保您獲得所需的性能。由於執法（PEP）和決策引擎（PDP）是鬆散耦合的，您可以選擇他們如何通信，他們使用什麼協議，是否使用多個決策等等。這意味着您可以選擇進行集成滿足您的性能需求。
在SAML配置文件中爲XACML定義了一個標準的PDP接口。這可以確保您在未被鎖定到任何特定供應商解決方案的情況下實現「面向未來」的訪問控制。對於web應用
訪問控制，您可以對.NET的Web程序的PEP在ISAPI和ASP.NET使用HTTP過濾器簡單地丟棄。 Axiomatics已經爲此提供了一個現成的產品。
當前實施方案 如果您檢查Axiomatics的客戶頁面，您會看到他們有Paypal，Bell直升機等等。所以XACML確實是一個現實，它可以解決非常大的部署（數以億計的用戶）。
此外，領先的金融服務提供商Datev eG正在爲其服務/應用程序使用Axiomatics的.Net PDP實現。由於.Net PDP是嵌入式的，因此性能是最佳的。否則，您可以隨時從現成的PEP中選擇與.Net集成的任何PDP - 例如基於SOAP的XACML授權服務。
與XACML 去年7月在Gartner的「催化劑」發佈會性能高的水平，希爾伯特宣佈了他們的最新產品的發佈，公理化反向查詢，可幫助您解決「十億記錄挑戰」。它針對數據源和RIA的訪問控制。它使用純粹的XACML解決方案，以保持與其他解決方案的互操作性。
由於事實上，Kuppinger科爾很快就會舉辦關於這一主題的研討會：http://www.kuppingercole.com/events/n10058
肯定找一個下拉授權模塊爲您的ASP.NET應用程序。我不只是這麼說，因爲我在BiTKOO上實現了嵌入式認證系統，但是因爲我過去不得不使用本地認證實現。爲一個應用程序構建自己的授權系統實際上並不能很好地利用您的時間或資源，除非您打算從事實施安全系統的職業。
從架構的角度來看，將應用程序的授權決策外化是一個好主意。對authz決策進行外部化可爲您提供巨大的靈活性，以便即時更改訪問條件，而無需關閉Web服務或重新配置Web服務器本身。將web前端與authz引擎分離可讓您根據應用程序的負載和流量模式獨立擴展，並允許您跨多個應用程序共享authz引擎。
是的，將網絡調用添加到您的Web應用程序中會相對於根本沒有授權或使用Web服務器上的本地數據庫而在Web響應中增加一些開銷。這不應該成爲不考慮外部授權的理由。您考慮的任何嚴重授權產品都會提供某種緩存功能，以最大限度地減少每個Web請求所需的網絡呼叫數量，甚至跨多個Web請求的每個用戶會話。
在BiTKOO的梯形校正系統，例如，用戶屬性可以被每個用戶會話的Web服務器上高速緩存，因此沒有真正參與的第一個頁面請求爲建立用戶登錄的一部分只有一個後端網絡請求。隨後的頁面請求（在高速緩存的憑證的生命週期內，通常5分鐘左右）可以由Web服務器處理，而無需再次訪問authz服務。這在雲網絡農場中可以很好地擴展，並且基於XACML標準。
訪問權限是否可以表述爲策略（覆蓋很多情況的一般規則）還是用戶彼此之間共享決策，基本上是任意的？ – kgilpin
@kgilpin：訪問權限既可以是通用的，也可以是特定的。如「僅A組可以讀取發票」，並且具體如「用戶X對賬戶Alpha有讀取權限」一樣。 – kaptan
我認爲目前關於基於角色的訪問控制（RBAC）實際上存在一些混淆。在其正式的構想中，RBAC非常有能力做你想做的事。您描述了兩個角色：「帳單讀者」和「帳戶Alpha的讀者」。下面有兩個來自基於屬性的訪問控制供應商的答案，但上面描述的規則對我來說聽起來並不屬於基於屬性的。有人認爲「RBAC無法做到這一點」，因爲人們將RBAC的形式與RBAC的一些相當薄弱的實現相混淆。 – kgilpin