在当今的软件开发中，授权和认证是任何软件解决方案中极为重要的一环。然而，许多应用程序在设计时并没有充分考虑到如何保护私有或重要数据免受攻击者侵害。许多应用程序都有自己的用户身份存储在业务层中，这需要开发者维护和支持。虽然并非所有解决方案都是如此，但随着进入一个新的时代，将解决方案迁移到Windows Azure，很明显安全解决方案并不能提供所需的可扩展性和可扩展性。
幸运的是，有了Windows Identity Foundation (WIF)，可以选择停止为每个使用.NET Framework的应用程序编写自定义的身份验证管道和用户身份数据库。那么，什么是基于声明的身份验证呢？将尝试简要解释一下；下面的图表显示了一个简单且经典的认证实现：
客户端输入用户名和密码（1）以获取对安全区域的访问权限。数据被传递到安全层（2），在那里凭证会与用户身份存储（3）进行验证。然后，结果很可能以用户声明的形式返回（4）并传递给应用程序（5）。在这里使用“声明”这个词是为了表达从身份存储返回的数据不仅仅是用户属性。一个声明可以是用户的电子邮件地址、部门等。但声明不仅仅是用户属性；声明还包括了提供者的信任信息。最后，客户端可能会获得对安全数据的访问权限（6）。
在想要实现不同的安全、增强安全或向系统中添加另一个应用程序之前，这幅图并没有问题。问题是必须根据身份和安全修改代码。基于声明的身份验证允许将这个逻辑从应用程序的核心解耦，并将责任交给另一个实体。那个实体就是身份提供者，如下所示：
客户端首先从应用程序请求令牌要求（1），接收它们（2），并将它们与用户名和密码一起传递给身份提供者的安全性令牌服务（STS）（3）。STS根据应用程序定义的要求（4）验证用户信息，并以声明的形式接收令牌响应（5）。然后它将令牌连同声明和公钥一起传回客户端（6）。客户端将令牌转发给应用程序。应用程序使用（8）WIF来解析（9）令牌（规范化、签名检查、解密、检查过期、检查重复等），并且可能从令牌中接收到它需要的声明（10），如果令牌有效的话。最后，客户端可能会获得对安全数据的访问权限（10）。
乍一看，似乎引入了很多步骤（从6到11），但当考虑到必须编写的代码的简单性时，使用WIF来认证用户可以节省很多麻烦。例如，必须编写的唯一代码来获取一个声明看起来像这样：
protected void Page_Load(object sender, EventArgs e)
{
IClaimsIdentity claimsIdentity =
((IClaimsPrincipal)(Thread.CurrentPrincipal)).Identities[0];
String userEmail =
(
from c in claimsIdentity.Claims
where c.ClaimType == System.IdentityModel.Claims.ClaimTypes.Email
select c.Value).FirstOrDefault();
}
在这段代码中，访问声明身份实例，并查询电子邮件地址的声明，这是由STS生成的令牌中的一个声明。其余的只是应用程序配置。例如，在非常简单的实现中，可能只设置一些页面，让某个角色看到，并进行以下配置：
<location path="SecretPage.aspx">
<system.web>
<authorization>
<allow roles="Manager" />
<deny users="*" />
</authorization>
</system.web>
</location>
请查看下面的SDK和Toolkit链接，一定会喜欢这个框架的实用性。实用性不是唯一的优势；当想要实现不同的认证技术时，它也非常强大。例如，切换到使用活动目录将不需要在应用程序上或与应用程序的通信上进行任何代码更改，如下所示：
在介绍微软身份和访问平台软件家族的其他部分之前：Active Directory Federation Services (ADFS) 2.0和Windows CardSpace 2.0。可以在这里获取更多关于这些技术的信息。不会详细介绍ADFS和CardSpace，因为这超出了当前的范围，但这些是一些不错的技术，可能会在自定义解决方案中使用它们。
也可以在Windows Identity Foundation SDK的帮助下开发自己的自定义STS。创建自定义STS就像右键点击项目，选择“添加STS引用…”然后按照向导创建一个新的STS项目一样简单。可以从这些链接下载WIF和WIF SDK：
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=eb9c345f-e830-40b8-a5fe-ae7a864c4d76&displaylang=en
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c148b2df-c7af-46bb-9162-2c9422208504&displaylang=en
。还有，请不要忘记从这里下载Toolkit，它提供了可能需要的所有代码示例。只是一个注意事项：请首先按照Toolkit的Assets文件夹中Setup.docx中描述的设置环境。是那些最后阅读手册的人之一，可以在那之前节省时间。
那么，所有这些如何在Windows Azure平台上帮助呢？可以开始使用Windows Azure平台作为解决方案的一部分有很多场景。其中之一是将应用程序放在云中，并将STS放在本地。这样，仍然可以利用本地身份验证用户，并利用Windows Azure的功能，如负载均衡、可扩展性等。下面的图表显示了这个例子：
逻辑与之前的非常相似；客户端只有在向应用程序（在这种情况下，是一个ASP.NET Web应用程序在ASP.NET Web角色上）发送了一个令牌（5）之后才能连接到应用程序（6），该令牌是基于应用程序定义的要求（2）从身份提供者（4）收集的。没有画出身份提供者和应用程序的细节，因为它可以像在基于声明的身份验证场景中描述的那样变化。请注意，WIF仍然在Windows Azure上的应用程序中使用。但是，WIF不在Windows Azure GAC中，这是对Windows Azure应用程序可见的。因此，想指出它是手动引用的。
一个重要的细节是要知道，托管在Windows Azure中的应用程序可能因为开发、测试和生产环境的不同而有不同的URI。因此，应用程序的URI应该动态地嵌入到令牌中以进行回复。因此，STS也必须修改以验证回复URI。
另一个细节是建立ASP.NET Web角色和STS之间的信任关系。这可以通过向导简单地完成，当右键点击应用程序项目并选择“添加STS引用…”时，向导就会出现。
另一个关键场景是也将身份提供部分委托给Windows Azure。这是通过使用Windows Azure AppFabric Access Control技术而不是STS。
使用AppFabric Access Control的使用情况如下所示：
正如所看到的，基于声明的工作流程并没有太大变化；只是简化了通信（1）只是为了清晰的目的。SWT代表简单Web令牌。