☰

将 SSL 证书移至边缘会破坏 Shibboleth

tag-icon • tag-icon nginx ssl shibboleth
将 SSL 证书移至边缘会破坏 Shibboleth

我们正在转换我们继承的系统：两个运行 IIS 和 Shibboleth 的 Web 服务器，位于运行 HAPROXY 的负载平衡服务器后面。每个 Web 服务器上都安装了 SSL 证书，并且 HAPROXY 配置为直通。

我们希望用运行 nginx 的服务器替换 HAPROXY 服务器，并且希望将 SSL 证书从 Web 服务器移到边缘，即 nginx 服务器。

因此，我们希望从以下角度出发：

前

更改为：

在此处输入图片描述

我们快要成功了。但有一个障碍：Shibboleth。

我们构建了一台新服务器，安装并配置了 nginx。我们使用 HOSTS 文件来回指向以进行测试。完成后，我们将使用 DNS 重新指向。

第一步，我们将 nginx 配置为 SSL 的直通：

在此处输入图片描述

这非常有效。

但是当我们将证书移至 nginx 服务器时，Shibboleth 会抱怨：
Unable to locate satisfiable bearer SubjectConfirmation in assertion

尝试访问不受 Shibboleth 保护的内容时（https://example.com/open)，它工作正常-所以证书设置正确。

如果我们将 HOSTS 指向 HAPROXY，进行身份验证，然后将 HOSTS 指向 nginx，它就会工作（通过跟踪 nginx 的 access.log 时通过浏览器测试确认）换句话说，一旦设置了 SAML cookie，一切就都好了。因此，问题似乎发生在 IdP 尝试将断言发送到 .../Shibboleth.sso/SAML2/POST 时（Fiddler 确认）

我已经在 Shibboleth 上打开了 DEBUG 日志记录，也许我会在那里找到一些东西，但现在还没有。

这里是nginx.conf：

worker_processes  1;

events {
    worker_connections  1024;
}

http {
  include             mime.types;
  default_type        application/octet-stream;
  sendfile            on;
  keepalive_timeout   65;

  upstream farm {
    server 192.168.1.42:80; # WEB1
    server 192.168.1.43:80; # WEB2
  }

  server {
    listen              80;
    listen              443 default ssl;
    server_name         example.com;

    ssl_certificate         example.com.crt;
    ssl_certificate_key     example.com.key;
    ssl_trusted_certificate example.com.pem;

    location / {
      proxy_pass              http://farm;
      proxy_next_upstream     error timeout invalid_header http_500 http_502 http_503 http_504;
      proxy_set_header        Host            $host;
      proxy_set_header        X-Real-IP       $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    }
  }

}

这是shibboleth2.xml

<SPConfig xmlns="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:conf="urn:mace:shibboleth:2.0:native:sp:config"
    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
    xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"    
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"
    clockSkew="180">

    <InProcess logger="native.logger">
        <ISAPI normalizeRequest="true" safeHeaderNames="true">
            <Site id="3" name="example.com"/>
        </ISAPI>
    </InProcess>

    <TCPListener address="192.168.1.42" port="1600" acl="192.168.1.42 192.168.1.43"/> 

    <RequestMapper type="Native">
        <RequestMap>
            <Host name="example.com">
              <Path name="closed" authType="shibboleth" requireSession="true">
              <Path name="open" authType="shibboleth" requireSession="false"/>
            </Host>
        </RequestMap>
    </RequestMapper>

    <ApplicationDefaults entityID="--spEntityId--"
                         REMOTE_USER="eppn persistent-id targeted-id uid"
                         cipherSuites="ECDHE+AESGCM:ECDHE:!aNULL:!eNULL:!LOW:!EXPORT:!RC4:!SHA:!SSLv2"
                         homeURL="https://example.com/closed">

        <Sessions lifetime="28800" timeout="86400" relayState="ss:mem" checkAddress="false" handlerSSL="false" cookieProps="https">
            <SSO entityID="--IdpEntityId--">SAML2 SAML1</SSO>

            <Logout>SAML2 Local</Logout>
            <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/>
            <Handler type="Status" Location="/Status" acl="127.0.0.1 ::1"/>
            <Handler type="Session" Location="/Session" showAttributeValues="true"/>
            <Handler type="DiscoveryFeed" Location="/DiscoFeed"/>
        </Sessions>

        <Errors supportContact="root@localhost"
            helpLocation="/about.html"
            styleSheet="/shibboleth-sp/main.css"
            redirectErrors="/errors/shiberror.html" />

        <MetadataProvider type="XML" path="idp_metadata.xml" />

        <AttributeExtractor type="XML" validate="true" reloadChanges="false" path="attribute-map.xml"/>
        <CredentialResolver type="File" key="file.key" certificate="file.crt"/>
    </ApplicationDefaults>

    <SecurityPolicyProvider type="XML" validate="true" path="security-policy.xml"/>
    <ProtocolProvider type="XML" validate="true" reloadChanges="false" path="protocols.xml"/>
</SPConfig>

我被难住了。你能帮忙吗？

答案1

通过修改解决了该问题shibboleth2.xml，更改如下：

<InProcess logger="native.logger">
    <ISAPI normalizeRequest="true" safeHeaderNames="true">
        <Site id="3" name="example.com"/>
    </ISAPI>
</InProcess>

更改为：

<InProcess logger="native.logger">
    <ISAPI normalizeRequest="true" safeHeaderNames="true">
        <Site id="3" name="example.com" scheme="https" port="443"/>
    </ISAPI>
</InProcess>

这就是添加scheme并port归因于InProcess\ISAPI\Site

我从 Scott Cantor 的理解中密码邮件列表这是由于 IIS 无法虚拟化服务器造成的。此功能已添加到 shibboleth 中作为解决方法。

答案2

参见此页面；

https://support.aaf.edu.au/support/solutions/articles/19000031196-unable-to-locate-satisfiable-bearer-subjectconfirmation-in-assertion

本质上，IdP 发送的是带有 https:// 前缀的 entityID（请注意“s”），但是因为 IIS Web 服务器已（直接或间接）配置了带有 http:// 前缀的 entityID（请注意没有“s”）。

上面的链接指的是在 Apache 服务器上使用 SP 时的解决方案（将 ServerName 指令更改为以“https://...”开头）。对于您使用 IIS 的情况，我不知道 IIS 本身中的等效项是什么，但您可以尝试将 shibboleth2.xml 中的 entityID="" 条目更改为以 https:// 开头

一种解决方法是在 nginx 代理和 Web 服务器之间使用 SSL 进行通信，并再次为 HTTPS 配置 IIS 绑定。

相关内容