ACS 中的 MyOpenID：添加所需的声明类型

发布于 2024-11-28 04:13:16 字数 3583 浏览 1 评论 0 原文

这个问题是如何使用 Azure ACS 将所需的声明传递给 OpenID 身份提供商？

不过，它对这个问题的看法略有不同，因此我将其作为一个新问题发布。注意：我还将其交叉发布到 Azure 安全论坛，但到目前为止尚未获得任何有用的意见。

Azure ACS 示例显示可以添加任意ACS 的 OpenID 身份提供商。但为了让 ACS 作为各种流行提供商的 STS 在我们的项目中真正发挥作用，我们开始让 ACS 与 MyOpenID.com 一起使用（同样，也在示例中使用）。这个问题，也是Vittorio 所展示的优点是，MyOpenID 不会向我们提供姓名和电子邮件地址等声明除非要求。 Vittorio 和其他人指出这是因为 MyOpenID 不支持属性交换。

不过我对此不太确定。深入研究 ACS 生成的请求 URL，我可以看到诸如 openid.ns.ax=http://openid.net/srv/ax/1.0 和 openid.ax 之类的参数.required=电子邮件、全名、名字、姓氏。此外，openid.ax.type.email 输入为 axschema.org/contact/email 类型。这就是 MyOpenID 出现问题的地方。 MyOpenID 不理解 axschema.org 类型，因此不会返回电子邮件值。

我所知道的是 MyOpenID 理解 schema.openid.net/contact/email 类型。因此，在此基础上，我手动更改了 ACS 请求 url 以使用 openid.net 架构而不是 axschema。你瞧，MyOpenID 做出反应并显示我的电子邮件地址实际上将被返回。

以下是我尝试传递到 myopenid.com/server 端点的参数列表：

openid.ns=http://specs.openid.net/auth/2.0
openid.mode=checkid_setup
openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
openid.identity=< a href="http://specs.openid.net/auth/2.0/identifier_select" rel="nofollow noreferrer">http://specs.openid.net/auth/2.0/identifier_select
openid.realm=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid
openid.return_to=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid。 ..
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.required=email,全名
openid.ax.type.email=http://schema.openid.net/contact/email
openid.ax.type.fullname=http://schema.openid.net/namePerson

不幸的是，当响应返回到 ACS，它不够好，并且 ACS 失败并显示以下错误代码：

HTTP 错误代码：400 消息：ACS30000：处理 OpenID 登录响应时出错。内部消息：ACS90014：缺少必填字段“openid.ax.value.email”。跟踪 ID：f8e09e6f-0765-4370-9f03-f744cce6fa2a 时间戳：2011-08-02 17:12:57Z

我尝试添加其他字段而不更改原始电子邮件类型，但只得到相同的错误。我开始怀疑实际上 ACS 并未完全支持 AX，并且它经过某种硬编码以仅接受某些类型的声明。

问题是：我的请求参数对您来说是否正确，还是我在这里遗漏了一些明显的东西？

注意：我的初始设置正在运行，如果我保持 ACS 请求不变，并且在 ACS 中仅为身份提供商配置单个直通规则，我可以使用 MyOpenID 身份提供商通过 ACS 成功验证我的网站。如果来自 ACS 的请求未明确要求声明类型 http://schema.openid.net/namePerson 或 http://schema.openid.net/contact/email

原文

This question is a continuation from How to pass required claims to OpenID identity provider with Azure ACS?

Its a slightly different take on the problem though, thus I'm posting this as a new question. Note: I'm also cross-posting this to the Azure Security forum but so far haven't gotten any useful input.

The Azure ACS samples shows that it is possible to add arbitrary OpenID identity providers to ACS. But for ACS to actually be helpful in our project as an STS for various popular providers we set out to get ACS working with MyOpenID.com (again, also used in the samples). The problem, as also the good Vittorio shows, is that MyOpenID will not give us claims like name and email address unless asked for. Vittorio and others states that this is because MyOpenID doesn't support Attribute Exchange.

I'm not so sure about that, though. Digging a bit deeper into the request url that ACS generates I can see that parameters like openid.ns.ax=http://openid.net/srv/ax/1.0 and openid.ax.required=email,fullname,firstname,lastname. Also, openid.ax.type.email is typed to the axschema.org/contact/email type. This is where things go wrong with MyOpenID. MyOpenID does not understand the axschema.org types and will thus not return an email value.

What I do know is that MyOpenID understands the schema.openid.net/contact/email type. So building on this I manually changed the ACS request url to use the openid.net schema instead of axschema. Lo and behold, MyOpenID reacts and shows that my email address in fact will be returned.

Here is a list of the parameters I'm trying to pass in to myopenid.com/server endpoint:

openid.ns=http://specs.openid.net/auth/2.0
openid.mode=checkid_setup
openid.claimed_id=http://specs.openid.net/auth/2.0/identifier_select
openid.identity=http://specs.openid.net/auth/2.0/identifier_select
openid.realm=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid
openid.return_to=https://myazurenamespace.accesscontrol.windows.net:443/v2/openid...
openid.ns.ax=http://openid.net/srv/ax/1.0
openid.ax.mode=fetch_request
openid.ax.required=email,fullname
openid.ax.type.email=http://schema.openid.net/contact/email
openid.ax.type.fullname=http://schema.openid.net/namePerson

Unfortunately, when the response is returned back to ACS it isn't good enough, and ACS fails with the following error codes:

HTTP Error Code: 400 Message: ACS30000: There was an error processing an OpenID sign-in response.
Inner Message: ACS90014: Missing required field 'openid.ax.value.email'.
Trace ID: f8e09e6f-0765-4370-9f03-f744cce6fa2a
Timestamp: 2011-08-02 17:12:57Z

I've tried adding additional fields without changing the original email type, but only get the same errors. I'm starting to suspect that it is in fact ACS that is not supporting AX to its full extent and that it is somewhat hardcoded to only accept claims of certain types.

The question is: does my request parameters look right to you or am I missing something obvious here?

NOTE: my initial setup is working, if I leave the ACS request unchanged and in ACS only configures a single Passthrough rule for the identity provider, I can successfully authenticate my website through ACS using the MyOpenID identity provider. The problem remains though that MyOpenID will not hand over e.g. FullName or Email to ACS if the request from ACS does not explicitly ask for the claim types http://schema.openid.net/namePerson or http://schema.openid.net/contact/email

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

昇り龍 2024-12-05 04:13:16

出于安全原因，ACS 不允许呼叫者重新输入电子邮件地址声明。实际上，您在不知不觉中所做的尝试是来自本文。出于安全原因，ACS 必须确保电子邮件地址和它支持的其他 AX 声明与其所知道的类型完全匹配，否则恶意调用者可能会欺骗 ACS 并用一种声明替换另一种声明。这并不是说 ACS 不支持 AX，而是 ACS 仅支持单一声明类型（如电子邮件声明），并且与 MyOpenID 使用的声明类型不同。简而言之，这是行不通的。