web-dev-qa-db-ja.com

SSL証明書をエッジに移動するとShibbolethが壊れます

継承したシステムを変換しています：HAPROXYを実行している負荷分散サーバーの背後にあるIISとShibbolethを実行している2つのWebサーバー。SSL証明書は各Webサーバーにインストールされ、HAPROXYはパススルーとして構成されています。

HAPROXYサーバーをnginxを実行しているサーバーに置き換え、SSL証明書をWebサーバーからEdge、つまりnginxサーバーに移動します。

だから私たちはこれから行きたいです：

Before

これに：

enter image description here

そして、私たちはほとんどそこにいます。 1つの障害があります：Shibboleth。

新しいサーバーを構築し、nginxをインストールして構成しました。 HOSTSファイルを使用して、テストのために前後にポイントします。完了したら、DNSを使用して再ポイントします。

ステップ1、SSLのパススルーとしてnginxを構成しました。

enter image description here

これは完璧に機能しました。

しかし、証明書をnginxサーバーに移動すると、Shibbolethは次のように文句を言います。
Unable to locate satisfiable bearer SubjectConfirmation in assertion

Shibboleth（ https://example.com/open ）で保護されていないコンテンツにアクセスしようとすると、正常に機能するため、証明書が正しく設定されます。

HOSTSをHAPROXYにポイントし、認証してから、HOSTSをnginxにポイントすると、機能します（nginxのaccess.logを調整する際のブラウザーテストで確認されます）。つまり、SAMLCookieが設定されるとすべて問題ありません。したがって、IdPがアサーションを.../Shibboleth.sso/SAML2/POSTに送信しようとすると問題が発生するようです（フィドラーが確認）

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>

私は困惑しています。手伝ってくれますか？

nginxsslshibboleth
1
biscuit314

この問題は、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に追加します。

shibbolethメーリングリスト のScott Cantorからの私の理解は、これはIISサーバーを仮想化できないためです。この機能は、回避策としてshibbolethに追加されました。

1
biscuit314

このページを参照してください。

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

基本的に、IdPはhttps：//プレフィックス（「s」に注意）を付けてentityIDを送信しますが、IIS Webサーバーは（直接的または間接的に）entityIDで構成されているためです。 http：//プレフィックス（「s」がないことに注意してください）。

上記のリンクは、ApacheサーバーでSPが使用されている場合の解決策を示しています（ServerNameディレクティブを変更して「https：// ...」を開始します）。この場合、IIS同等のものがIIS自体に含まれるかどうかはわかりませんが、shibboleth2.xmlのentityID = ""エントリを変更してhttps：/を開始してみてください。 //

回避策は、nginxプロキシとWebサーバー間のトラフィックにSSLを使用し、HTTPSのIISバインディングを再度構成することです。

0
Steve365