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
支付宝扫一扫
微信扫一扫
