在shibboleth SP中签名身份验证请求

时间:2019-01-11 14:19:38

标签: saml saml-2.0 shibboleth shibboleth-sp

我正在使用Shibboleth SP进行SAML授权。

最近,IdP更改了配置,现在需要签署AuthRequest。

IdP的元数据具有以下参数

<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol"
WantAuthnRequestsSigned="true"><md:KeyDescriptor use="signing">

SP的shibboleth2.xml文件具有以下标记

<ApplicationDefaults entityID="...."
   REMOTE_USER="eppn persistent-id targeted-id email Email FirstName LastName NameID">

IdP强制执行A​​uthRequest签名后,我们如下更改了shibboleth2.xml文件

<ApplicationDefaults entityID="..."
                         REMOTE_USER="eppn persistent-id targeted-id email 

Email FirstName LastName NameID" 
signing="true" encryption="true">

基本上,我添加了signing="true"encryption="true"

之后,生成的新元数据在标记中具有以下属性

<md:SPSSODescriptor AuthnRequestsSigned="1" 
protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol 
urn:oasis:names:tc:SAML:1.1:protocol urn:oasis:names:tc:SAML:1.0:protocol">

更早的AuthnRequestsSigned="1"属性不存在。

在此之后,当我尝试进行身份验证时,它给了我们以下错误,

<samlp:Status><samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder"/>
        <samlp:StatusMessage>Unable to verify the signature</samlp:StatusMessage>
    </samlp:Status>

问题1:是否需要向IdP提供这个新的元数据? 问题2:知道为什么会这样吗? 问题3:是否需要更改配置中的其他内容?

P.S。在强制执行A​​uthRequest签名之前,它已经起作用了,因此我认为配置中没有其他问题。

这是示例AuthRequest

<samlp:AuthnRequest
    AssertionConsumerServiceURL="https://...SP-host.../Shibboleth.sso/SAML2/POST"
    Destination="https://...idp-host.../marrsso/idp/SSO.saml2"
    ID="...some-id..." IssueInstant="2019-01-11T14:13:25Z"
    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Version="2.0"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://...entity-id.../shibboleth</saml:Issuer><samlp:NameIDPolicy AllowCreate="1"/></samlp:AuthnRequest>

我认为签名信息应作为请求的一部分放在此处。作为http请求,它与GET请求一样,对吗? 当我在网络中看到请求时,我可以看到签名正在作为查询参数 enter image description here 请求的状态码为“ 200”

1 个答案:

答案 0 :(得分:1)

发送签名作为查询字符串的一部分并不罕见。就像一个预签名的URL。

  1. 仅在SP上启用“ signing = true”不应更改 最初是生成的。因此,重新发送元数据不是 需求。与IdP一起检查SP的元数据是否最初是 全部导入还是只是添加了依赖方和其他基本目的 要集成的点,如果请求签名是 不需要。

  2. 如果IdP无法验证签名,则它们必须丢失 SP的证书。确保比较两个元数据文件 在启用签名和加密之前和之后,他们应该 匹配(特别是在证书周围),但要附加属性 您已经确定的。否则,重新发送元数据。

  3. 在这种情况下,不需要其他配置更改。