Windows Azure Pack 的验证遵循基于声明的原则，自带通过基于 ASP.NET 成员提供程序的自定义租户验证网站进行租户验证的功能，以及通过 Windows 验证网站进行管理员验证的功能。也可以使用 Active Directory 联合服务（AD FS）将这个堆栈与 Active Directory 集成。这已经在之前的博文系列中详细讨论过。如果需要使用其他身份提供程序向 WAP 提供身份，则强烈建议将它们与 AD FS建立联合，使用户能够登录 WAP。这样做有一些优势，例如能够将验证机制保留在企业内部，对于 AD FS 场拥有完全控制等等。
除了这些选项之外，还可以集成其他能够通过 WS 联合协议通信的安全令牌服务（STS）向 WAP 提供身份。例如 Windows Azure 访问控制服务(ACS)。可以利用 Azure 访问控制服务和 Azure Active Directory/ Office 365/ 组织 ID 帐户直接向 Windows Azure Pack 提供基于云的身份。如果已经是 Azure Active Directory 客户，已经将企业内部基于 Active Directory 的身份同步到 Windows Azure，则根据这篇文章，可以将 ACS 直接作为身份提供程序，中间不需要 AD FS。
这篇博文还会介绍如何将其他类似的身份提供程序与 WAP 建立联合。在这个练习末尾，您的环境看起来应该与下图类似：
用例
- 企业具备内部 Active Directory，已经将 Active Directory 与 Azure AD 同步，或者拥有基于 Office 365 的用户帐户，已经将他们的合作伙伴全部与 ACS 建立联合。
- 企业不愿意承担部署和维护 AD FS 的负担。
- 组织没有基础结构，全部服务都托管在公有云上，不考虑安装本地 AD 或 AD FS 实例。
这篇博文介绍以下步骤：
- 在 Windows Azure 上创建访问控制命名空间
- 将 WAP 租户门户添加为 ACS 的依赖方
- 配置 Live (Microsoft) 和 Google 服务，充当身份提供程序
- 配置 Azure Active Directory 通过命名空间公开，并提供身份
前提条件
- Windows Azure Pack 安装(快捷安装或发行版)
- Windows Azure 订阅
- Windows Azure Active Directory
在 Windows Azure上创建访问控制命名空间
第一步是创建 ACS 命名空间。这是您的 STS，它负责生成 WAP 使用的签名身份令牌。这也是 WAP 信任的唯一 STS。
- 要在 Windows Azure 中创建访问控制命名空间，请打开底部选项，选择 App Services à Active Directory à Access Control
- 单击 Quick Create，输入要创建的命名空间的名称。我为这个示例起的名称是'WindowsAzurePackSTS'，并添加到美国中北部地区（添加到哪个地区没有影响）
- 命名空间创建完成之后，单击 Manage。
- 用适当的凭据登录
- 这应该将您带回基于 Silverlight 的命名空间管理门户。
将 WAP 租户门户添加为 ACS 的依赖方
命名空间创建之后，必须告诉它，WAP 门户要从它这里得到令牌。根据联合的原则，期望从 STS 获得令牌的应用称为依赖方。所以在这个阶段，我们要让 ACS 知道 WAP 租户门户。
- 单击 Relying Party Applications 并单击 Add，将 Windows Azure Pack 租户门户作为依赖方加入这个命名空间。这实际上就是告诉 ACS 命名空间：租户门户期望它提供用户身份。
- 您现在要进入 Add Relying Party Application 页面，在这里可以输入 WAP 租户门户的细节。可以手动完成所有这些步骤，也可以提供来自租户门户的联合元数据文件。联合元数据文件包含的信息包括：依赖方的地址、用来标识依赖方身份的标识符，等等。
- 更容易的做法是提供来自租户门户的故障元数据。联合元数据可以从https://www.contoso.com/federationmetadata/2007-06/federationmetadata.xml (请用租户门户的地址替换www.contoso.com)下载。请将 XML 文件保存到计算机本地。
- 现在回到 ACS 管理门户，上传联合元数据文件，为依赖方提供一个显示名称。我的名称是"Windows Azure Pack Tenant Portal"
- 向下滚动到 Token Format 区，在令牌格式中选择 'JWT'。默认选择的是 Windows Live 身份提供程序。如果不希望用户用他们的 Live id 登录，请取消这个选择。在 Token Signing Settings 区，选择 X.509 证书作为 Type。单击 Save。
配置外部服务充当身份提供程序
设置了 ACS 和 WAP 门户之后，现在必须找到能够通过 ACS 进入 WAP 门户的身份来源。在这一节，我们将介绍 Google 这样的外部服务，下一节将介绍 Azure Active Directory。如果不考虑外部身份，可以跳过这节，进入配置 Azure Active Directory 和 ACS 小节。
- 接下来增加另外一个身份提供程序。使用 ACS，Windows Live 默认启用，但必须在幕后稍做调整，才能加入更多身份提供程序。请进入 Identity Providers 区，选择 Add 来增加新的身份提供程序。
- 对于第一个场景，我们选择 Google。如果希望与 Azure Active Directory 或 Office 365 帐户建立联合，可以跳过这节，直接进入下一节。请选择 Google 并单击 Next。
- 幸运的是，ACS 从一开始就与 Google 建立起很好的联合，所以您需要做的几乎很少。只要输入登录链接文本，并选择刚刚添加的依赖方，单击 Save。
提示：在使用 Google 时，我目前不确定是否有具体方法可以限定只有特定用户访问系统，因为 Google 只是对任何有效用户进行验证。但是，授权在 WAP 内进行，所以要想限制用户登录之后访问的资源，可以创建专用的计划，限制用户的使用。我认为一个可行的做法是使用 Google Apps 帐户管理一个用户集合，将它单独与 ACS 实例建立联合。（这个想法我自己还没有验证过，因此不能保证，但肯定是一条值得探索的道路。）我会继续探索寻找更好方法来进行这类验证，一旦找到更好的方法就会在这里更新
连接Azure Active Directory和ACS
我们更进一步，将 Azure Active Directory 加入 ACS。关于这个操作，请参阅以下详细教程：
关于将 O365 与 ACS 连接的操作指南，请参阅：
我不会重复以上博客的全部内容，而是假定您已经学习过它们，而且已经有了工作正常的 Azure Active Directory 或 Office 365 目录，已经准备就绪，已经有了一批用户。
下面两节摘录自以下博文：
首先，需要让 Active Directory 租户知道 ACS 命名空间的存在。Web SSO （在这个示例中，是 WS联合）端点不会为任何接收者发放令牌，只有服务主体对象代表的接收方才被视为合法。
到目前为止，Windows Azure Active Directory 门户尚未提供创建服务主体的命令，所以创建它的最直接方式就是使用 Office365 命令。这些命令可以从这里下载（请仔细阅读操作说明，尤其是与前提条件以及 x86 vs x64 平台有关的说明）。
- 安装了这些命令之后，单击桌面上新的 PowerShell 快捷方式("Microsoft Online Services Module for Windows PowerShell")并输入以下命令(用自己的 ACS 命名空间代替其中的'windowsazurepacksts')
1: Connect-MsolService
2: Import-Module MSOnlineExtended –Force
3: 4: $replyUrl = New-MsolServicePrincipalAddresses `
5: –Address https://windowsazurepacksts.accesscontrol.windows.net/
6: 7: New-MsolServicePrincipal –ServicePrincipalNames @("https://windowsazurepacksts.accesscontrol.windows.net/") `
8: -DisplayName "mywap ACS Namespace" ` 9: -Addresses $replyUrl 在 ACS 命名空间中将Azure Active Directory作为一个ID 提供程序对外服务
- 回到 ACS 管理平台的 'Identity providers' 区，单击 Add，选择 "WS-Federation identity provider" 并单击 Next 按钮。
- 输入显示名称和登录链接文本，在 WS 联合元数据区的 URL 字段中粘贴进目录租户的元数据文档 URL。Azure 目录的联合元数据信息可以在这里找到：https://accounts.accesscontrol.windows.net/mywap.onmicrosoft.com/FederationMetadata/2007-06/FederationMetadata.xml
请用您自己的 Active Directory 命名空间替换其中的 'mywap' 。滚动到页面底部，选择"Windows Azure Pack Tenant Portal" 依赖方。
单击 Save，完成操作。
声明转换规则
现在已经设置了依赖方和身份提供程序。接下来应该说明如何为这些身份提供程序转换进入的声明，以便依赖方能够理解它。我们使用 Rule Groups 做这件事，规则组是一个管理声明转换的规则集合。由于我们有两个身份提供程序，所以必须为每个提供程序创建一个规则。
- 单击 Rule Groups ，选择 'Default Rule Group for Windows Azure Pack Tenant Portal'。这个规则组是在前面创建依赖方的时候自动生成的。单击 Add 增加新规则。
- 首先，选择 Windows Live ID 作为身份提供程序，选择传入声明为http://schemas.xmlsoap.org/ws/2005/05/claims/nameidentifier。WAP 门户需要 UPN 声明。所以，在 Output Claim types 区，在 Enter Type 文本框中输入 'upn' 并单击 Save。
提示：输入 'upn' 后，会得到带有完整规范名称的 UPN 建议。忽略这个建议，确保文本框中只有 'upn' 三个字母。
向下滚动，给这个规则一个说明，并单击 Save。
3. 重复以上过程，这次选择 Google 作为身份提供程序，选择http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress作为传入声明类型，'upn' 作为传出类型。
4. 针对 Azure Active Directory 身份提供程序再执行一次。选择http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name作为传入声明类型， 'upn' 作为传出类型。
好了！ACS 设好了，可以在 WAP 中使用了！
提示：可以使用这个过程将任何基于 WS 联合的身份提供程序与 ACS 建立联合，用它向 WAP 安装提供身份!
配置 WAP 门户使用 ACS
现在，ACS 方面的工作设置完成！余下的就是让 WAP 安装知道您要通过 ACS 提供身份，它应该从 ACS 查找签名的令牌，还提供签名证书。做法是，提供 WAP 门户、ACS 实例的联合元数据，就像通过 WAP 门户的元数据文件将 WAP 告知 ACS 一样。
- 从导航栏上选择 Application Integration，在 Endpoint Reference 区找到 WS-Federation Metadata。联合元数据文件通常位于at .com.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml">.com.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml">https://.com.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml
- 您是否对用户界面工作感到厌倦了？是时候做些 PowerShell 操作了。要将 ACS 联合元数据文件交给 WAP，需要执行以下脚本。使用从 ACS 管理控制台得到的元数据文件的链接。
执行以下 PowerShell 命令，将 ConnectionString 指向 WAP 配置数据库。
1: $dbServer = 'azurepack\sqlexpress'
2: $dbPassword = 'pass@word'
3: $portalConfigStoreConnectionString = [string]::Format('Data Source={0};Initial Catalog=Microsoft.MgmtSvc.PortalConfigStore;User ID=sa;Password={1}', $dbServer, $dbPassword)
4: 5: Set-MgmtSvcRelyingPartySettings -Target @("Tenant") `
6: -MetadataEndpoint https://windowsazurepacksts.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml `
7: -ConnectionString $portalConfigStoreConnectionString -DisableCertificateValidation 3. 打开浏览器，访问 WAP 租户门户
4. 请注意，现在被重定向到 ACS 登录页面，上面列出了刚刚配置的 Windows Live、 Google 和 Azure Active Directory 这几个选项。
5. 我选择 Google，输入我的 Google 凭据登录。
6. 由于这是我第一次通过 WAP 门户访问我的 Google 凭据，所以 Google 会询问是否应该信任这个应用程序，并与这个应用程序共享电子邮件地址和基本信息，请选择 Accept。
7. 现在会发生一系列的重定向，在这个过程中，身份令牌从Google 传递给 ACS，再传递给 WAP 门户，然后就用 Google 帐户登录 WAP。太棒了！！现在客户就能使用他们的Google 帐户登录 WAP 了！
真的就是这么容易！！
现在回到 WAP 租户门户，选择 Azure Active Directory 选项，将会进入对应的登录页面。
输入 AAD 凭据，可以看到重定向神奇地将您带回 WAP 门户。
好了！现在已经成功地使用 Azure Active Directory 和 ACS, Google 和 Windows Live 向 WAP 提供身份!
本文开头提到过，还可以使用这个指南与基于 WS 联合的其他 STS 建立联合，向 WAP 提供身份。要做到这点，必须像处理 ACS 一样在 STS 上执行类似步骤，并执行"配置 WAP 门户使用 ACS"，用 STS 的数据替换联合元数据端点，就可以成功。