基于声明的标识模型，简单来讲，就是将用户信息作为声明条件，向应用程序来提供用户标识。一个声明以是用户名，也可能是电子邮件地址。现在的想法是配置外部标识系统，为应用程序提供了解用户及其所做各个请求所需的所有信息，以及从可靠源接收的标识数据的加密保证。
基于声明的标识模型，更容易实现单点登录，并且应用程序可以彻底摆脱以下操作：
1) 对用户进行身份验证。
2) 存储用户账户和密码。
3) 调用企业目录以查看用户标识的详细信息。
4) 从其他平台或公司与标识系统集成。
在基于声明的标识模型中，应用程序将根据用户所提供的声明来做出与标识相关的决策。这可以是任何内容，从包含用户名字的简单应用程序个性化设置，到授予用户访问应用程序中高级功能和资源权限。
基本概念
下面简单介绍基于声明的标识模型的基本术语。
（1） 标识
“标识”一词通常是一个不明确的术语。但为了描述WIF中的编程模型，这里使用术语“标识”来描述一组说明要保护的系统中用户或其他一些实体的特性。比如一个常见的互联网站点，对于一个普通用户，其标识可能是用户名，可能是性别，也可能是爱好，总之是一个完整实体的特性。
（2） 声明
将声明视为一条标识信息，如销售角色中的姓名、电子邮件地址、年龄、成员身份。应用程序接收的声明越多，对用户了解得就越多。你可能想知道为何将这些称为“声明”而不是通常描述企业目录时用到的“特性”。原因就在于送达的方式。在此模型中，应用程序并不在目录中查询用户特性。相反，用户向应用程序传达声明，由应用程序对其进行检查。各声明均由颁发者发出，你对这些声明的信任度与对颁发者的信任度一样。例如，你对公司域控制器发出的声明的信任度高于对用户自己发出的声明。WIF代表Claim类型的声明，此类型声明具有找出声明颁发者的Issuer属性。
（3） 安全令牌
用户向应用程序传递一组声明和一个请求。 在Web服务中，这些声明将在 SOAP封装的安全标头中传递。在基于浏览器的Web应用程序中，这些声明将通过HTTP POST从用户的浏览器中到达，并可能随后缓存在 Cookie中（如果需要会话）。不论这些声明如何到达，都必须对其进行序列化，这也是安全令牌所在之处。安全令牌是一组经过颁发机构数字签名的序列化声明。此签名非常重要：它向你保证用户并不只是生成大量声明然后发送给你。在没必要或不希望加密的安全性较低的情况下，可使用未签名的令牌。
WIF的一个核心功能是，可以创建和读取安全令牌。WIF和.NET Framework可以处理所有的加密工作，并为应用程序提供一组可以读取的声明。
（4） 颁发机构
不同类型的颁发机构有很多，从颁发 Kerberos票证的域控制器到颁发X.509证书的证书颁发机构。这里讨论的颁发机构是可颁发包含声明的安全令牌的机构。此颁发机构是了解如何颁发安全令牌的 Web应用程序或 Web服务。它必须发出正确的声明，提供给目标信赖方和提出请求的用户，并且负责查看声明并对用户本身进行身份验证。
不论选择哪个颁发机构，它在标识解决方案中的作用都十分重要。在通过信任声明将身份验证的因素从应用程序中排除时，你会将责任转交给该机构并要求其以你的名义对用户进行身份验证。
（5） 标准
为使所有这些操作能够交互，使用了多个WS-*标准。使用WS-MetadataExchange检索策略，并根据WS-Policy规范对策略本身进行结构化。STS（安全令牌服务）公开了实施WS-Trust规范的终结点，此规范描述了如何请求和接收安全令牌。如今，大多数 STS可颁发安全声明标记语言(SAML)格式的令牌。SAML是行业认可的XML词汇，可用于以交互方式表示声明。或者，在多平台情况下，这使你可以与完全不同的平台上的 STS进行通信，并在所有应用程序中实现单点登录。
（6） 基于浏览器的应用程序
基于浏览器的应用程序也可以使用标识模型。
首先，用户将浏览器指向Web应用程序（信赖方应用程序）。Web应用程序将此浏览器重定向到STS以便可以对用户进行身份验证。在可以读取传入请求的简单 Web应用程序中托管 STS，使用标准HTTP机制对用户进行身份验证，然后创建SAML令牌并通过一段JavaScript代码给予回复，此代码将使浏览器发起可将SAML令牌发送回RP的HTTP POST。 此POST的正文包含RP请求的声明。此时，RP通常会将声明打包到Cookie以便不必为各个请求重定向用户。
（7） CardSpace和标识选择器
WIF为CardSpace序列化提供API，此API可用于构建托管的信息卡颁发以及在应用程序中启用信息卡登录。
标识选择器提供以下功能：
q 帮助用户管理 Web的多个标识。
q 帮助用户为指定信赖方选择适当标识。
q 帮助保护用户隐私。
基本实现
在具体了解基于声明的标识模型的实现机制之前，先来了解或者说回顾传统的验证模式。当然，本书高级扩展的部分会推荐基于声明的标识模型，不代表传统的方式做得不好，事实上，实践验证它们足够优秀。讨论基于声明的标识模型，给你一个全新的选择，或者在适合的场景下使用它。
（1） Iprincipal接口
管理标识和访问控制，需要得到当前应用环境的用户信息，从而根据用户信息识别其标识，并根据标识来判断权限。
在.NET应用程序中，当前上下文中的用户信息由IIdentity接口来表示。该接口的定义如代码清单15-1所示。
代码清单15-1 IIdentity接口定义
public interface IIdentity
{
// Properties
string AuthenticationType { get; }
bool IsAuthenticated { get; }
string Name { get; }
}
IIdentity接口的主要作用是用来验证，这一点从它的属性中也能看出来。提到验证肯定会想到授权。
以上是小编为您精心准备的的内容，在的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索sts
， 应用程序
， 声明
， 模型
， 令牌
， 用户
， 标识符声明
， pascalc++声明
， 基于
， 标识
声明的
未声明的标识符、必须声明标识符、c2065 未声明的标识符、c 未声明的标识符、cout未声明的标识符，以便于您获取更多的相关知识。