【问题标题】:In OpenID, is there a concept like SAMLSSO RelayState?在OpenID中,有没有SAMLSSO RelayState这样的概念?
【发布时间】:2014-04-15 04:32:45
【问题描述】:

我想通过 OpenID 请求发送一个状态,并通过 OpenID 提供者 (OP) 响应将其原封不动地返回。 SAMLSSO 为此使用“RelayState”参数。 OpenID中有这样的方式吗?

我检查了specification,似乎如果我将 RelayState 之类的参数附加到“openid.return_to”并发送请求,OP 应该在响应的“openid.return_to”参数中将其发送回。

但规范也提到:

return_to URL 可以用作依赖方将有关身份验证请求的上下文附加到身份验证响应的机制。 本文档没有定义 RP 可以确保查询参数不被外界修改的机制;这种机制可以由 RP 自己定义。

在 SAMLSSO 中,保证在 RelayState 中发送的相同值将由 IdP 发回。但是根据 OpenID 规范中的上述声明,我不确定使用 'openid.return_to' 是实现这一目标的正确方法。还有其他(更好的)方法吗?还是我以任何方式误解了该声明?

【问题讨论】:

    标签: openid


    【解决方案1】:

    就我所见,openid.return_to 是将 RelayState 传递给 OpenID 请求的唯一方法。正如您巧妙引用的规范所述:

    • “return_to URL 可以用作依赖方将有关身份验证请求的上下文附加到身份验证响应的机制。” 也就是说,此 URL 可以通过 GET 参数考虑中继状态,就像SAMLSSO 使用,如?RelayState=%2Fpost-login-page。
    • “本文档没有定义 RP 可以确保查询参数不被外界修改的机制;这种机制可以由 RP 自己定义。” 也就是说,这个端点也应该验证请求本身,就像 SAML 通过 SHA 指纹等一样。
    • 所以最后你可以有一个 return_to URL 来评估 OpenID 验证的结果,不管有没有 RelayState,比如/base?RelayState= 或只是/base。

    您之前曾问过这个问题,所以如果您找到了更好的选择,请告诉我们。但是现在我只是确认您原始帖子中的假设 openid.return_to 是考虑诸如 RelayState 之类的唯一方法。如果我错了,请有人纠正我!

    【讨论】:

      猜你喜欢
      • 2014-04-06
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2017-12-24
      • 2011-04-25
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多