MSDN的文章對這個兩個概念進行了一個舉例加漸進式的解釋, 能很好的幫助我們理解.
文字和相關概念的定義摘抄在這里, 有空翻譯出來, 以饗讀者.
===============================
想象下面的場景. Alice是一個想要通過Windows 域帳號訪問購物服務的一個用戶. 她的域控制器認證了她, 放置了一系列的security identifiers (SIDs)到ticket后, 創造了這個Kerberos ticket. 這些SID代表了Alice的用戶帳戶還有她加入了的眾多域用戶組. SID被嵌在ticket中還帶有一個域控的簽名. 在identity的術語中, "issure"(發行者, 即域控)給了Alice一個安全令牌(security token ), Alice可以使用這個令牌來證明她是誰. 這些方法在Alice使用證書完成認證的時候是一樣的. 證書只不過是另一種類型的安全令牌(security token )而已. 在這里, issure(發行者)是證書頒發機構(certificate authority (CA) ), 證書發布的目標就是Alice. Kerberos ticket也好, 證書也好, 本質上說, 都是發布者針對某個目標給出的一個聲明(statement). 這是被信任的機構擔保它的成員的兩種不同的方法. 每個被簽署了的生命都可以被認為是某些claim的集合. 換種說法: 當域控制器在發給Alice的ticket中放入SID的時候, 也就是域控制器對Alice這個個體發表了一些claims. 每個SID都成為了一個claim. 當證書機構對Alice這個個體簽署她的名字和公有密鑰的時候, 證書機構就在對Alice個體發布了claims. 證書中的名字和公有密鑰就是claim.
這個新的identity模型的目標是對identity進行抽象, 從而減少對某種特定類型的credential的依賴, 同時還不對你應用程序的安全做任何妥協. 通過對SharePoint 2010中的identity model編碼, 你可以處理對用戶身份認證的代理, 而且不需要Kerberos ticket, 還能處理Security Assertion Markup Language (SAML)令牌. 這就開啟了有趣的identity 架構(包括federated identity)的大門.
下面的部分介紹了能幫助你理解Claim-based的identity架構的術語和概念.
==============================
Identity
在某個你想要使之安全的系統中, Identity是描述一個用戶或其他實體的一系列屬性.
Claim
可以認為claim是一條身份信息(比如說, 名字, 郵件地址, 年齡, 或者是否銷售角色的一員). 你的應用程序收到的claim越多, 你知道的關於這個用戶的東西就越多. 這些信息被叫做claim而不是attribute(它們通常被用來描述企業級的目錄), 是因為傳遞的方式不同. 在這個模型里, 你的應用程序不會查詢目錄中的用戶屬性. 相反, 用戶給你的應用程序提供claims, 你的應用程序檢查它們是否匹配. 每個claim都是由issuer發布的, 你對這些claim的信任跟你對issuer的信任一樣. 比如說, 你信任一個你公司的域控制器發布的一條claim肯定比你信任由一個用戶發布的claim要多.
Security Token
隨着一個請求, 用戶傳遞給了你的應用程序幾個claim的集合. 在一個web service中, 這些claim通過SOAP信封的security header傳遞過去. 在一個基於瀏覽器的應用程序中, claim通過HTTP POST方法從用戶的瀏覽器到達服務器端, 稍后如果需要session的話, 那么這些claims會被緩存到cookie中. 不管這些claim是如何到達的, 它們都必須被序列化, 而這就是security token加入的地方. Security Token是序列化了的claim的集合, 由發布機構進行數字簽名. 簽名很重要: 它給了你用戶不能瞎編claim並且發送給你的一個保證. 在不那么安全的情形下, 加密不是必須的, 但是這並不在我們討論的范圍之內.
Windows Identify Foundation的核心特性之一, 是創建和閱讀security token的能力. WIF和Microsoft .NET Framework處理所有的加密工作, 給你的應用程序提供可以供它讀取的claim的集合.
Security Token Service (STS)
security token service (STS)是"構造, 簽署, 和根據互操作協議發布security token"的管道. 實現這些協議需要很多工作, 但是WIF把這些工作都為你做好了, 使得它對於非協議專家也是可以使用的, 可以用來花很小的代價來構造並上線Security Token Service .
WIF使得構造你自己的STS更容易了. 如何實現邏輯, 規則完全取決於你, 還要靠你來強制執行這些邏輯和規則(通常被叫做security policy, 安全策略).
Issuing Authority
Issuing authorities的種類很多, 從創建kerberos ticket的域控制器, 到發布x509證書的認證機構. 這里討論的具體的機構類型會發布帶有claim的security token. 這個發布機構是一個發布security token的web application或web service. 它必須能夠根據目標的relying party(依賴方)和發送請求的用戶來發布恰當的claim, 而且還可能需要負責與用戶目錄進行交互, 以便查找claim和認證用戶.
不管你選擇什么issuing authority, 它都在你的認證解決方案中扮演重要的角色. 當你通過依靠claim而把認證從你的應用程序中排除之后, 你就把責任推給了那個機構, 並且讓這個機構來替你認證用戶.
Relying Party
當你構建一個依靠claim的應用程序的時候, 你就在構造一個relying party application了. Relying party的同義詞包括"claims-aware application"和"claims-based application". Web applications和web service都是relying parties.
一個relying party application使用有STS發布的token, 從token中抽取claim, 用這些claim作為相關任務的個體鑒別之用. STS支持兩種rely party應用程序: ASP.NET Web applications和Windows Communication Foundation (WCF) Web services.
Standards
為了讓所有的這些概念和動作都是可互操作的, 許多WS-開頭的標准被應用了起來, 前面的場景也是一樣. 通過使用WS-MetadataExchange獲得安全策略(policy), 而且安全策略本身是根據 WS-Policy 標准的結構構造的. STS暴露實現了WS-Trust 標准的端點(endpoint), 該標准描述了如何請求和接受security token. 今天, 大多數的STS通過Security Assertion Markup Language (SAML)格式發布tokens. SAML是一種工業識別的XML字典, 可以被用於在可互操作的方式展現claim. 或者, 在一個多平台的情形下, 這使得你能夠在一個完全不同的平台上跟STS溝通, 並達到在所有應用程序上實現單點登錄的效果, 不管在什么平台上.
Browser-Based Applications
Smart客戶端不是可以使用基於claim的identity model的全部. Browser-based應用程序(也被叫做被動客戶端)也可以使用它. 下面的場景描述了這是如何工作的:
首先, 用戶讓瀏覽器訪問一個基於claim的web應用程序(即relying party application). Web應用程序重定向瀏覽器到STS, 以便於用戶可以被認證. STS被寄存於一個簡單的web 應用程序中, 它讀取到來的請求, 通過標准的HTTP機制認證用戶, 然后創建SAML token, 然后使用一些ECMAScript (JavaScript, JScript)代碼來回復客戶端, 這些代碼可以引發瀏覽器發送一個帶有SAML token的HTTP POST請求回到relying party application上. POST請求的正文部分包含relying party需要的claims. 這個時間點上, relying party把claim打包到一個cookie中是很常見的, 以便於這個用戶稍后的每個請求中不必再被重定向去認證了.
資料來源
===================
Why Use Claims-Based Identity
http://msdn.microsoft.com/en-us/library/ee535229
Claims-Based Identity Overview and Concepts