SAML / 签名注销请求是否需要 RelayState?
SAML / is RelayState required for signed logout request?
我想确认有效的签名 SAML 注销请求需要 RelayState。
我们已将 Microsoft 的 ADFS 2012 R2 与 Oracle 的身份联合进行联合,其中 ADFS 是 SP,OIF 是 IdP。作为基础,我们遵循了Integrating ADFS 2.0/3.0 SP with OIF IdP.
一切正常,除了注销。我们有另一个 SP 正在注销并使用 OIF。我们发现的一个区别是 ADFS 没有发送带有其签名注销请求的 RelayState 参数,但另一个 SP 是。我一直在使用 SAMLTool's Validate Logout Req,我在其中输入以下内容:
- SAML 注销请求
- 来源的 EntityId
- 目标 URL,注销请求的目的地
- 信号算法
- SAML 注销请求的签名
- 源的 X.509 证书(检查签名)
- 忽略计时问题:选中
然后给我错误:
In order to check Signature you must provide the RelayState parameter and the X.509 cert
如果我在 SAMLTool's Validate Logout Req 中输入 RelayState 以及我的其他值,那么它会报告我的签名注销请求有效。
在 ADFS 的情况下,因为它没有 RelayState 参数,所以我无法 SAMLTool's Validate Logout Req 说从 ADFS 注销是有效的。
综上所述,我在 SAML 规范中找不到任何地方说签名注销请求需要 RelayState。任何人都可以确认它是必需的并使用文档进行备份吗?[=15=]
正在阅读 SAMLv2 核心规范 "Single Logout Protocol" XML SAML LogoutRequestType 架构
<element name="LogoutRequest" type="samlp:LogoutRequestType" />
<complexType name="LogoutRequestType">
<complexContent>
<extension base="samlp:RequestAbstractType">
<sequence>
<choice>
<element ref="saml:BaseID" />
<element ref="saml:NameID" />
<element ref="saml:EncryptedID" />
</choice>
<element ref="samlp:SessionIndex" minOccurs="0" maxOccurs="unbounded" />
</sequence>
<attribute name="Reason" type="string" use="optional" />
<attribute name="NotOnOrAfter" type="dateTime" use="optional" />
</extension>
</complexContent>
</complexType>
<element name="SessionIndex" type="string" />
没有提到 RelayState 元素。 SAMLv2 配置文件规范中的 "Single Logout Profile" 也没有提及 RelayState。
我会说这表明 RelayState(这是一个请求参数,因此只能用于前端通道绑定)不是强制性的。
LogoutRequest
消息不会引用 RelayState
参数(正如另一个 post 所建议的那样),但它是所谓绑定的一部分,用于在 SAML 各方之间传递消息。假设注销使用 HTTP-Redirect
、HTTP-POST
或 Artifact
绑定,规范 允许 发送方包含一个 RelayState
参数然后接收方必须 return 相同的 RelayState
参数作为响应的一部分(作为发送方保持状态的一种方式)。
参见 SAML 绑定文档的第 3.4.3 节 RelayState:https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf HTTP 重定向绑定:
3.4.3 RelayState
RelayState data MAY be included with a SAML protocol message transmitted with
this binding. The value MUST NOT exceed 80
bytes in length and SHOULD be integrity protected by the entity
creating the message independent of any other protections that may or
may not exist during message transmission. Signing is not realistic
given the space limitation, but because the value is exposed to
third-party tampering, the entity SHOULD ensure that the value has not
been tampered with by using a checksum, a pseudo-random value, or
similar means. If a SAML request message is accompanied by RelayState
data, then the SAML responder MUST return its SAML protocol response
using a binding that also supports a RelayState mechanism, and it MUST
place the exact data it received with the request into the
corresponding RelayState parameter in the response. If no such value
is included with a SAML request message, or if the SAML response
message is being generated without a corresponding request, then the
SAML responder MAY include RelayState data to be interpreted by the
recipient based on the use of a profile or prior agreement between the
parties
对于其他绑定,存在类似的部分。正如@nzpcmad 所说:在请求中包含它不是强制性的。
我想确认有效的签名 SAML 注销请求需要 RelayState。
我们已将 Microsoft 的 ADFS 2012 R2 与 Oracle 的身份联合进行联合,其中 ADFS 是 SP,OIF 是 IdP。作为基础,我们遵循了Integrating ADFS 2.0/3.0 SP with OIF IdP.
一切正常,除了注销。我们有另一个 SP 正在注销并使用 OIF。我们发现的一个区别是 ADFS 没有发送带有其签名注销请求的 RelayState 参数,但另一个 SP 是。我一直在使用 SAMLTool's Validate Logout Req,我在其中输入以下内容:
- SAML 注销请求
- 来源的 EntityId
- 目标 URL,注销请求的目的地
- 信号算法
- SAML 注销请求的签名
- 源的 X.509 证书(检查签名)
- 忽略计时问题:选中
然后给我错误:
In order to check Signature you must provide the RelayState parameter and the X.509 cert
如果我在 SAMLTool's Validate Logout Req 中输入 RelayState 以及我的其他值,那么它会报告我的签名注销请求有效。
在 ADFS 的情况下,因为它没有 RelayState 参数,所以我无法 SAMLTool's Validate Logout Req 说从 ADFS 注销是有效的。
综上所述,我在 SAML 规范中找不到任何地方说签名注销请求需要 RelayState。任何人都可以确认它是必需的并使用文档进行备份吗?[=15=]
正在阅读 SAMLv2 核心规范 "Single Logout Protocol" XML SAML LogoutRequestType 架构
<element name="LogoutRequest" type="samlp:LogoutRequestType" />
<complexType name="LogoutRequestType">
<complexContent>
<extension base="samlp:RequestAbstractType">
<sequence>
<choice>
<element ref="saml:BaseID" />
<element ref="saml:NameID" />
<element ref="saml:EncryptedID" />
</choice>
<element ref="samlp:SessionIndex" minOccurs="0" maxOccurs="unbounded" />
</sequence>
<attribute name="Reason" type="string" use="optional" />
<attribute name="NotOnOrAfter" type="dateTime" use="optional" />
</extension>
</complexContent>
</complexType>
<element name="SessionIndex" type="string" />
没有提到 RelayState 元素。 SAMLv2 配置文件规范中的 "Single Logout Profile" 也没有提及 RelayState。
我会说这表明 RelayState(这是一个请求参数,因此只能用于前端通道绑定)不是强制性的。
LogoutRequest
消息不会引用 RelayState
参数(正如另一个 post 所建议的那样),但它是所谓绑定的一部分,用于在 SAML 各方之间传递消息。假设注销使用 HTTP-Redirect
、HTTP-POST
或 Artifact
绑定,规范 允许 发送方包含一个 RelayState
参数然后接收方必须 return 相同的 RelayState
参数作为响应的一部分(作为发送方保持状态的一种方式)。
参见 SAML 绑定文档的第 3.4.3 节 RelayState:https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf HTTP 重定向绑定:
3.4.3 RelayState
RelayState data MAY be included with a SAML protocol message transmitted with this binding. The value MUST NOT exceed 80 bytes in length and SHOULD be integrity protected by the entity creating the message independent of any other protections that may or may not exist during message transmission. Signing is not realistic given the space limitation, but because the value is exposed to third-party tampering, the entity SHOULD ensure that the value has not been tampered with by using a checksum, a pseudo-random value, or similar means. If a SAML request message is accompanied by RelayState data, then the SAML responder MUST return its SAML protocol response using a binding that also supports a RelayState mechanism, and it MUST place the exact data it received with the request into the corresponding RelayState parameter in the response. If no such value is included with a SAML request message, or if the SAML response message is being generated without a corresponding request, then the SAML responder MAY include RelayState data to be interpreted by the recipient based on the use of a profile or prior agreement between the parties
对于其他绑定,存在类似的部分。正如@nzpcmad 所说:在请求中包含它不是强制性的。