发行说明

  • 项目

更新时间：2015 年 6 月 19 日

适用于：Azure

本主题介绍每个版本的Microsoft Azure Active Directory 访问控制 (（也称为访问控制服务或 ACS) ）中的新功能，介绍了产品的每个版本与其前置版本有何不同，并重点介绍可能影响为早期版本编写的代码的任何重大更改。

  • 2015 年 3 月 – 将 ACS 命名空间迁移到 Google OpenID Connect

  • 2014 年 6 月 – Google 标识提供程序支持

  • 2013 年 7 月更新发行说明

  • 2012 年 12 月更新发行说明

  • 2012 年 9 月更新发行说明

  • 2012 年 6 月更新发行说明

  • 2012 年 5 月更新发行说明

  • 2012 年 1 月更新发行说明

  • 2011 年 7 月更新发行说明

2015 年 3 月 – 将 ACS 命名空间迁移到 Google OpenID Connect

ACS 实施了一项功能，可帮助 ACS 命名空间所有者将他们的 Google 标识提供程序配置从 OpenID 2.0 迁移到 OpenID Connect。 若要使用 OpenID Connect 标识符，客户必须在 2015 年 6 月 1 日之前将他们的 ACS 命名空间迁移到 OpenID Connect，并在 2017 年 1 月 1 日之前迁移他们的后端代码。 如果未在每个期限之前执行相应的操作，将会导致你的应用程序发生中断。 有关详细指导，请参阅将 ACS 命名空间迁移到 Google OpenID 连接。

2014 年 6 月 – Google 标识提供程序支持

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

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

New ACS namespace and Google error

2013 年 7 月更新发行说明

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

2012 年 12 月更新发行说明

新增功能

ACS 2012 年 12 月更新包含以下新功能：

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

使用 ACS 通过标识提供者使用 WS-Federation 协议启用单一登录 (SSO) 的 Web 应用程序现在可以利用单一注销功能。 当用户注销 Web 应用程序时，ACS 可以自动将用户从标识提供者注销，并从使用同一标识提供者的其他信赖方应用程序注销。

此功能为WS-Federation标识提供者启用，包括 Active Directory 联合身份验证服务 2.0 和 Windows Live ID (Microsoft 帐户) 。 若要启用单一注销，ACS 为WS-Federation协议终结点执行以下任务：

  • ACS 从标识提供者识别 wsignoutcleanup1.0 消息，并通过向信赖方应用程序发送 wsignoutcleanup1.0 消息做出响应。

  • ACS 通过向标识提供者发送 wsignout1.0 消息并将 wsignout1.0 消息发送到信赖方应用程序来识别 wsignout1.0 和 wrsignout1.0 消息并做出响应。

有关详细信息，请参阅代码示例：在 WIF 中使用联合注销和被动 ASP.NET 身份验证的 MVC 4 ASP.NET MVC 4。

不再支持 ACS 1.0

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

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

新的 Azure 管理门户 (https://manage.WindowsAzure.com) 包括创建和管理访问控制命名空间的熟悉 ACS 管理门户的路由。

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

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

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

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

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

导航到服务总线的访问控制命名空间

在门户中创建服务总线命名空间时，门户会自动为服务总线创建访问控制命名空间。

若要配置和管理服务总线的访问控制命名空间，

  1. 登录到 Azure 管理门户。

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

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

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

有关详细信息，请参阅如何：管理服务总线的访问控制命名空间。

用于查看 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 协议实现的细节仍有可能更改。 有关详细信息，请参阅开发人员预览版：SAMLProtocol。

已知问题

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

Azure Co-Administrators现在可以管理访问控制命名空间。 但是，需要执行操作才能将预先存在的共同管理员传播到预先存在的访问控制命名空间。

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

  • ACS50000：颁发令牌时出错。

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

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

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

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

  2. 使用 “如何为 Azure 订阅https://msdn.microsoft.com/library/windowsazure/gg456328.aspx 添加和删除Co-Administrators”中的指南删除并重新添加共同管理员 ()

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

2012 年 9 月更新发行说明

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

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

访问控制命名空间发布的WS-Federation元数据中的“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 月更新发行说明

2012 年 6 月，ACS 收到了包含以下新功能的更新：

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

此更新引入了对 ACS 中 JSON Web 令牌 (JWT) BETA 格式的支持。 JWT 是一种轻型 JSON 编码的令牌格式，可以使用 X.509 证书或对称密钥进行签名，并且可以由 ACS 颁发给信赖方应用程序，以便通过以下任一协议进行签名：

  • OAuth 2.0

  • WS-Federation

  • WS-Trust

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

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

重要

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

2012 年 5 月更新发行说明

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 月更新发行说明

2012 年 1 月 25 日，ACS 2.0 收到包含以下更改的更新：

  • 针对失败的身份验证请求的 ACS 错误响应更改

  • 针对失败的身份验证请求的 OAuth 2.0 错误代码更改

针对失败的身份验证请求的 ACS 错误响应更改

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

ACS 将返回错误代码 ACS50008、ACS50009 或 ACS50012，以便在 SWT、SAML 和用户名/密码的情况下分别失败。 有关详细信息，请参阅下表：

身份验证响应 之前 之后

不存在的颁发者

ACS50026 IssuerNotFound

ACS50008 InvalidSwt、

ACS50009 InvalidSaml， OR

ACS50012 AuthenticationFailed

不正确的凭据

ACS50006 InvalidSignature

针对失败的身份验证请求的 OAuth 2.0 错误代码更改

在上一版本中，当客户端使用不存在的颁发者进行身份验证时，ACS 使用不同的 OAuth 2.0 错误代码做出响应， (invalid_client) 或凭据 (invalid_grant) 不正确。 此行为也已更新，当 OAuth 2.0 请求格式不正确时，ACS 将返回invalid_request，invalid_client如果客户端身份验证失败或为身份验证提供的断言格式不正确或无效，并且如果授权代码格式不正确或无效，invalid_grant。 有关详细信息，请参阅下表：

身份验证响应 示例 之前 之后

不存在的颁发者

invalid_client

invalid_client

不正确的凭据

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

invalid_grant

身份验证失败

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

invalid_grant

断言格式不正确

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

invalid_request

授权代码格式不正确

invalid_grant

invalid_grant

授权代码无效

invalid_grant

OAuth2 请求格式不正确

invalid_request

invalid_request

2011 年 7 月更新发行说明

ACS 2.0 7 月更新的发行说明包含以下项：

  • 先决条件

  • 新功能

  • 更改

  • 已知问题

  • 已知问题

先决条件

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

新功能

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

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

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

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

有关具有两个输入声明的规则的详细信息，请参阅 规则组和规则。

2. 十一种语言的本地化

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

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

  • URL – ACS 管理门户中显示的语言可以通过将“lang”参数添加到请求 URL 的末尾来更改。 此参数的合法值是与支持的语言对应的 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 委派方案中，使用 ACS 管理服务在访问控制命名空间中创建颁发者记录，并且此颁发者没有关联的标识提供者。

  • 当创建颁发者是为了在令牌请求中通过 OAuth WRAP 协议断言声明时，同时使用同名的服务标识通过 ACS 进行身份验证。

配额

在此版本中，ACS 不会对标识提供者的数量、信赖方应用程序、规则组、规则、服务标识、声明类型、委派记录、颁发者、密钥和地址施加限制，这些地址可以为给定的访问控制命名空间创建。

服务限制

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