导出 (0) 打印
全部展开

发行说明

发布时间: 2011年4月

更新时间: 2014年6月

应用到: Azure

本主题介绍 Microsoft Azure Active Directory 访问控制(也称为访问控制服务或 ACS) 的每个版本的新功能,说明该产品的每个版本与它前面的版本有何不同,并重点介绍任何可能会影响为前面版本编写的代码的重大更改。

从 2014 年 5 月 19 日开始,新的 ACS 命名空间无法使用 Google 作为标识提供程序。在 2014 年 5 月 19 日之前注册的使用 Google 的 ACS 命名空间不受影响。之所以实施此新限制,是因为 Google 正逐步取消对 ACS 所依赖的 OpenID 2.0 的支持,并已关闭新应用程序注册。使用 Google 的现有 ACS 命名空间将继续工作,直到 2015 年 4 月 20 日。如果你的应用程序需要支持 Google 帐户,建议你直接向这些帐户注册你的应用程序。有关详细信息,请参阅 Google 文档

如果用户尝试使用 Google 帐户登录到新的 ACS 命名空间,则会被重定向到 HTTP 400 错误页。

新的 ACS 命名空间和 Google 错误

为了提高所有用户的 ACS 可用性和性能,ACS 对每个命名空间实施了每秒 30 个令牌请求的限制。如果某个命名空间在较长的一个时间段内超出此限制,则 ACS 将在该时间段内拒绝来自该命名空间的令牌请求,并返回 HTTP 429/ACS90055“请求太多”错误。有关详细信息,请参阅 ACS 服务限制ACS 错误代码

新增功能

ACS 2012 年 12 月更新包括以下新功能:

支持使用 WS 联合身份验证协议进行联合单一注销

使用 ACS 和 WS 联合身份验证协议通过标识提供程序进行单一登录 (SSO) 的 Web 应用程序现在可以使用单一注销功能。当用户从某一 Web 应用程序中注销时,ACS 可以自动将该用户从标识提供程序及其他使用同一标识提供程序的信赖方应用程序中注销。

已为 WS 联合身份验证标识提供程序(包括 Active Directory 联合身份验证服务 2.0 和 Windows Live ID(Microsoft 帐户))启用此功能。为了启用单一注销,ACS 会执行以下 WS 联合身份验证协议终结点任务:

  • ACS 识别来自标识提供程序的 wsignoutcleanup1.0 消息,并通过向信赖方应用程序发送 wsignoutcleanup1.0 消息来进行响应。

  • ACS 识别来自信赖方应用程序的 wsignout1.0wreply 消息,并通过向标识提供程序发送 wsignout1.0 消息以及向信赖方应用程序发送 wsignoutcleanup1.0 消息来进行响应。

有关详细信息,请参阅代码示例:支持联合注销的 ASP.NET MVC 4使用 WIF 实现 ASP.NET 被动身份验证

不再支持 ACS 1.0

此版本不再支持 Access Control Service 1.0,包括不再支持从 Access Control Service 1.0 迁移到 Access Control Service 2.0。

导航到新的 Azure 管理门户中的 “访问控制”命名空间

新的 Azure 管理门户 (http://manage.WindowsAzure.com) 提供到熟悉的 ACS 管理门户的路由,你可以在后面的门户中创建和管理 “访问控制”命名空间。

若要导航到 ACS 管理门户,请执行以下操作:

  1. 转到 Microsoft Azure 管理门户 (https://manage.WindowsAzure.com) 并登录,然后单击“Active Directory”。(故障排除提示:“Active Directory”项缺失或不可用

  2. 单击 “访问控制”命名空间,然后单击“管理”。

若要创建访问控制命名空间,请依次单击“新建”、“应用程序服务”和“访问控制”,然后单击“快速创建”。(或者,先单击“访问控制命名空间”,然后单击“新建”。)

要获取有关 Microsoft Azure 管理门户中 ACS 管理任务的帮助,请单击“Active Directory”,然后单击“帮助(?)”。(或者,依次单击“Active Directory”、“访问控制命名空间”,然后单击“帮助”。)

导航到 Service Bus 的 “访问控制”命名空间

当你在 中创建 Service Bus 命名空间时,门户会自动为 Service Bus 创建 “访问控制”命名空间。

若要配置和管理 Service Bus 的 “访问控制”命名空间,请执行以下操作:

  1. 登录到 Azure 管理门户

  2. 单击“Service Bus”,然后选择某一 Service Bus。

  3. 单击“访问密钥”,然后单击“打开 ACS 管理门户”

若要验证 “访问控制”命名空间是否与 Service Bus 相关联,请查看“访问控制服务”页顶部的“服务命名空间”字段。命名空间名称由 Service Bus 名称加上“-sb”后缀组成。

有关详细信息,请参阅操作方法:管理 Service Bus 的访问控制命名空间

用于查看 WS 联合身份验证标识提供程序密钥、隐藏密码的 ACS 管理门户增强功能

此版本包含两个有关在 ACS 2.0 管理门户中查看和使用证书、密钥和密码的增强功能:

  • 现在可在“编辑 WS 联合身份验证标识提供程序”部分看到签名证书 - 以前,从 WS 联合身份验证元数据导入的用于验证标识提供程序颁发的令牌签名的证书在 ACS 管理门户中不可见。“编辑 WS 联合身份验证标识提供程序”部分现在显示有关导入的证书(包括其到期日期和状态)的信息。现在可以使用新的“保存时从 WS 联合身份验证元数据 URL 重新导入数据”复选框来刷新这些证书。

  • 现在,密码和对称签名密钥在默认情况下隐藏 - 为了防止无意中泄露密码和对称密钥,现在这些值在默认情况下在整个门户的编辑屏幕上隐藏。若要有意显示密码或对称密钥的值(例如,为了将该值复制到应用程序中),现在必须按“显示密码”或“显示密钥”按钮。

将目录租户与 “访问控制”命名空间联合的功能

Azure Active Directory 租户现在可以用作 “访问控制”命名空间中的标识提供程序。这可实现很多方案,如允许 Web 应用程序同时接受目录租户的组织标识和社交提供程序(例如 Facebook、Google、Yahoo!、Microsoft 帐户或任何其他 OpenID 提供程序)的使用者标识。你可以在这篇文章(在 ACS 命名空间中将 Azure Active Directory 租户设为标识提供程序)中找到有关如何实现该方案的详细说明。

用于信赖方应用程序的 SAML 2.0 协议支持(开发者预览版)

ACS 现在支持用于向信赖方应用程序颁发令牌的 SAML 2.0 协议。SAML 2.0 协议支持已作为开发者预览版发布,这意味着 SAML 2.0 协议实现的细节仍有可能更改。有关详细信息,请参阅开发者预览版:SAML 协议

已知问题

在 2012 年 12 月的 Microsoft Azure Active Directory 访问控制(也称为访问控制服务或 ACS) 更新中,已确定以下已知问题:

Azure 协同管理员现在可以管理 “访问控制”命名空间。但是,需要执行相应的操作,以便将现有协同管理员传播到现有 “访问控制”命名空间。

在 2012 年 11 月更新之前,我们解决了这样一个问题:在默认情况下,只有主要 Azure 服务管理员可以管理订阅中创建的 “访问控制”命名空间。如果 Azure 协同管理员尝试在 ACS 管理门户中访问 “访问控制”命名空间,他们将收到以下 ACS 错误代码之一:

  • ACS50000:颁发令牌时出错。

  • ACS60000:使用颁发者“uri:WindowsLiveID”处理信赖方规则时出错

  • ACS60001:在处理规则期间未生成任何输出声明。

对于新的由任何 Azure 服务管理员或协同管理员创建的 “访问控制”命名空间,现在已解决此问题。但是,在修复推出之前其命名空间已存在的客户需要执行以下解决方案,以便将协同管理员数据传播到那些命名空间:

  1. 使用服务管理员或帐户管理员凭据登录到 Azure 门户 (https://windows.azure.com/)。

  2. 使用如何为 Azure 订阅添加和删除协同管理员 (http://msdn.microsoft.com/zh-cn/library/windowsazure/gg456328.aspx) 中的指南,删除并重新添加协同管理员

  3. 使用协同管理员凭据注销并登录到 Azure 门户。然后,你将能够管理 “访问控制”命名空间。

在 2012 年 9 月,Microsoft Azure Active Directory 访问控制(也称为访问控制服务或 ACS) 收到包含以下更改的更新:

ACS 发出的 WS 联合身份验证元数据中发布的 entityID 现在统一为小写

“访问控制”命名空间发布的 WS 联合身份验证元数据中的“entityID”特性现在始终为小写。在以前的版本中,它使用在 Azure 门户中创建命名空间时输入的字母大小写。“entityID”特性为信赖方应用程序标识 “访问控制”命名空间,下面是该特性的一个示例:

<EntityDescriptor xmlns="urn:oasis:names:tc:SAML:2.0:metadata" entityID="https://lowercase-namespace.accesscontrol.windows.net/" ID="_e4a0006c-c23c-41c0-8f87-baa110afaf1d">

需要进行此更改是为了解决潜在的令牌验证问题,即在 ACS 颁发的令牌中 “访问控制”命名空间的字母大小写(始终为小写)与信赖方导入的 “访问控制”命名空间的字母大小写不匹配。使用 Windows Identity Foundation 的信赖方不受区分大小写问题的影响。

现在,上载到 ACS 的 X.509 证书具有 4096 位的公钥大小限制

通过 ACS 管理门户或管理服务上载到 “访问控制”命名空间的所有 X.509 证书的公钥大小现在都不能大于 4096 位。这包括用于令牌签名、令牌加密和令牌解密的证书。

在 Windows 中,你可以打开证书 (.CER) 文件,选择“详细信息”选项卡,然后检查“公钥”字段的值,这样即可查看证书的公钥大小。使用安全的 sha256RSA 签名算法的证书的公钥将为 2048 位。

密钥大于 4096 位的任何现有证书均可继续用于 ACS,但不能在 ACS 中重新保存,除非将它们替换为合乎规范的证书。

对 ACS 通过 X.509 证书为令牌签名时使用的“主密钥”选择算法进行的小更改

在 ACS 管理门户和管理服务中,令牌签名证书有一个“设为主证书或密钥”字段,选择了该字段时,将促使ACS 使用该证书为令牌签名。在此版本中,如果配置的令牌签名证书未选中“设为主证书或密钥”字段,则 “访问控制”命名空间将使用具有最早有效开始日期的现有非主令牌签名证书为令牌签名。如果主证书虽存在,但无效或已过期,ACS 仍然不会使用非主令牌签名证书为令牌签名。

JWT Beta 版:使用全局命名空间证书或密钥为 JWT 令牌签名时签名行为的更改

在 2012 年 6 月发布对 JSON Web 令牌 (JWT) 格式的 Beta 支持时,ACS 使用以下优先顺序来确定哪个密钥应该用于为颁发给每个信赖方应用程序的每个 JWT 令牌签名:

  • 分配给信赖方的对称签名密钥(如果可用)

  • 分配给信赖方的 X.509 签名证书(如果可用)

  • 分配给 “访问控制”命名空间的对称签名密钥

  • 分配给 “访问控制”命名空间的 X.509 签名证书

自此版本起,不再支持使用整个命名空间的对称密钥为 JWT 令牌签名。下面是用于为 JWT 令牌签名的新优先顺序:

  • 分配给信赖方的对称签名密钥(如果可用)

  • 分配给信赖方的 X.509 签名证书(如果可用)

  • 分配给 “访问控制”命名空间的 X.509 签名证书

在 2012 年 6 月,ACS 收到包含以下新功能的更新:

JWT 格式现在可用于信赖方应用程序 (Beta)

此更新在 ACS 中引入了对 JSON Web 令牌 (JWT) BETA 格式的支持。JWT 是一种 JSON 编码的轻量级令牌格式,可以使用 X.509 证书或对称密钥为其签名,并可以由 ACS 通过以下任一协议向信赖方应用程序颁发:

  • OAuth 2.0

  • WS 联合身份验证

  • WS 信任

JWT 令牌格式现在是 ACS 管理门户的“信赖方应用程序”部分中的可选项,也可通过 ACS 管理服务进行配置。

若要了解有关 JWT 令牌格式的详细信息,请参阅 JSON Web 令牌规范。包含 JWT 令牌的 ACS 代码示例会在将来某一天提供。

Important重要提示
JWT 支持在 ACS 中标记为“Beta”,这意味着 JWT 实现的所有细节都可能会更改。鼓励开发人员尝试使用此令牌格式。但是,不应将 JWT 用于生产服务,因为其行为可能会在不另行通知的情况下发生更改。

在 2012 年 5 月初,ACS 收到包含以下更改的更新:

通过管理服务公开的实体 ID 属性的更改

ACS 管理服务目前公开了它支持的每个实体类型的 ID 属性,如 ACS 管理服务 API 参考中所述。这些 ID 属性由 ACS 自动设置并管理。

在此服务更新中,ACS 将迁移到不同的数据库架构,因此,通过管理服务公开的所有实体类型的这些 ID 都将发生更改。

不常见且通常不建议的做法是:为通过管理服务查询特定实体而让应用程序存储这些 ID 或为这些 ID 创建硬编码的依赖关系。而建议的做法是:使用 Name 属性查询 RelyingParty、ServiceIdentity、RuleGroup 和 Issuer 实体类型,使用父实体 ID(例如,就规则而言为 RuleGroupId,就标识提供程序而言为 IssuerId)查询其他实体类型。

针对规则处理而对数据库排序规则进行的更改

为了扩大国际语言支持和提高安全性,此版本的 ACS 将用于比较输入声明的基础 SQL 数据库排序规则从 SQL_Latin1_General_CP1_CI_AS 更新为 Latin1_General_100_BIN2。此更改允许 ACS 支持附加的字符集和字符集组合。由于使用这个新的排序规则,依赖于包含多字符集字符串的输入声明(不受 SQL_Latin1_General_CP1_CI_AS 支持)的应用程序可能会看到不同的或附加的声明。建议希望利用此新功能的客户验证其应用程序是否与新的 SQL 排序规则兼容。

在 2012 年 1 月 25 日,ACS 2.0 收到包含以下更改的更新:

在前一版本中,当使用不存在的颁发者(错误代码:ACS50026)或不正确的凭据(错误代码:ACS50006)对客户端进行身份验证时,ACS 将使用不同的错误代码进行响应。这些错误代码是以前当客户端尝试使用无效的服务标识名称或无效的标识提供程序颁发的 SWT 或 SAML 令牌进行身份验证时发出的。

ACS 将为失败的身份验证返回错误代码 ACS50008、ACS50009 或 ACS50012,分别对应于使用 SWT、SAML 和用户名/密码的情况。有关详细信息,请参阅下表:

 

身份验证响应 以前 完成

不存在的颁发者

ACS50026 IssuerNotFound

ACS50008 InvalidSwt、

ACS50009 InvalidSaml 或

ACS50012 AuthenticationFailed

不正确的凭据

ACS50006 InvalidSignature

还是在前一版本中,当使用不存在的颁发者 (invalid_client) 或不正确的凭据 (invalid_grant) 对客户端进行身份验证时,ACS 使用不同的 OAuth 2.0 错误代码进行响应。此行为也已更新,当 OAuth 2.0 请求格式不正确时,ACS 将返回 invalid_request;如果客户端未通过身份验证,或者为身份验证提供的断言格式不正确或无效,则返回 invalid_client;如果授权代码格式不正确或无效,则返回 invalid_grant。有关详细信息,请参阅下表:

 

身份验证响应 示例 以前 完成

不存在的颁发者

invalid_client

invalid_client

不正确的凭据

使用不正确的密钥对 SWT 进行签名。客户端 ID 和凭据与 ACS 中配置的匹配。

invalid_grant

身份验证失败

受众 URI 验证失败。证书验证失败。服务标识的断言包含自行颁发的声明。

invalid_grant

断言格式不正确

SWT 缺少签名。SAML 断言不是有效的 XML。

invalid_request

授权代码格式不正确

invalid_grant

invalid_grant

授权代码无效

invalid_grant

OAuth2 请求格式不正确

invalid_request

invalid_request

ACS 2.0 的 2011 年 7 月更新的发行说明包含以下项目:

所有 “访问控制”命名空间都自动接收 2011 年 7 月更新。此更新不包含针对新客户或现有客户的 ACS 先决条件更改。有关当前 ACS 先决条件的详细信息,请参阅 ACS 先决条件

ACS 的 2011 年 7 月更新包含以下新功能:

1. 规则现在最多支持两个输入声明

ACS 规则引擎现在支持新类型的规则,该规则允许最多配置两个输入声明,而不是只能配置一个输入声明。包含两个输入声明的规则可用于减少执行复杂的用户授权功能所需的规则总数。

在 ACS 管理门户中,可以通过在规则编辑器中单击“添加第二个输入声明”在新规则中指定第二个输入声明。在管理服务中,可以使用 ConditionalRule 实体类型配置包含两个输入声明的规则。包含一个输入声明的规则仍使用 Rule 实体类型进行配置,以保持向后兼容性。

有关包含两个输入声明的规则的详细信息,请参阅规则组和规则

2. 十一种语言的本地化

ACS 管理门户和 ACS 托管的信赖方应用程序登录页现在支持十一种书面语言的本地化,这些语言包括英语、法语、德语、意大利语、日语、韩语、俄语、西班牙语、葡萄牙语(巴西)、简体中文和繁体中文。“英语(国际)”选项也可用,该选项使用替代日期格式,用于设置和显示密钥的有效/到期日期。为这些用户界面显示的书面语言可通过以下三种方式之一进行更改:

  • 语言选择器 - 在 ACS 管理门户中,显示的语言可以使用门户右上角显示的新的语言选择器菜单即时进行更改。

  • URL – ACS 管理门户中显示的语言可以通过向请求 URL 的末尾添加“lang”参数来进行更改。此参数的合法值是与支持的语言对应的 ISO 639-1/3166 语言代码。示例值包括 en、de、es、fr、it、ja、ko、ru、pt-br、zh-cn 和 zh-tw。下面是一个 ACS 管理门户 URL 示例,所带参数将显示的语言设置为法语:

    https://your-namespace.accesscontrol.windows.net/?lang=fr

  • Web 浏览器首选项 - 如果从未使用“lang”URL 参数或语言选择器设置语言首选项,则 ACS 管理门户和 ACS 托管的登录页将根据 Web 浏览器设置中设置的语言首选项确定要显示的默认语言。

此版本中明显的服务行为更改如下所示:

1. 所有 OAuth 2.0 响应的编码现在是 UTF-8

在 ACS 的初始版本中,来自 OAuth 2.0 终结点的所有 HTTP 响应的字符编码集是 US-ASCII。在 2011 年 7 月更新中,所有 HTTP 响应的字符编码现在设置为支持扩展字符集的 UTF-8。

以下是此版本中的已知问题:

规则编辑器无法显示未与标识提供程序关联的自定义颁发者

目前,ACS 管理门户中的规则编辑器只能显示与标识提供程序或 ACS 关联的声明颁发者。如果加载的规则引用了未对应于其中任一项的颁发者,则会显示以下错误:

  • ACS80001:此规则是为了使用管理门户并不支持的声明颁发者类型而配置的。请使用管理服务来查看并编辑此规则。

ACS 中支持以下两种方案,这两种方案允许颁发者在没有关联的标识提供程序的情况下存在:

  • 在 OAuth 2.0 委托方案(在Code Sample: OAuth 2.0 Delegation中提供)中,通过使用 ACS 管理服务在 “访问控制”命名空间中创建颁发者记录,此颁发者没有关联的标识提供程序。

  • 在另一种方案中,创建颁发者是为了通过 OAuth WRAP 协议验证令牌请求中的声明,同时会使用同名服务标识通过 ACS 进行身份验证。

到此版本为止,ACS 未对以下项的数量加以限制:标识提供程序、信赖方应用程序、规则组、规则、服务标识、声明类型、委托记录、颁发者、密钥以及可以为给定 “访问控制”命名空间创建的地址。

有关服务限制的详细信息,请参阅 ACS 服务限制

另请参阅

社区附加资源

添加
Microsoft 正在进行一项网上调查,以了解您对 MSDN 网站的意见。 如果您选择参加,我们将会在您离开 MSDN 网站时向您显示该网上调查。

是否要参加?
显示:
© 2014 Microsoft