Web分散構成における Shibboleth SP の設定

2019/03/06 fukuoka

更新 2019/9/19

ここでは Web サーバを分散させている場合の Shibboleth SP の設定を説明します。Web サーバ１台の場合は、Shibboleth SP の設定を参考にしてください。

確認事項

振り分け方式として、IPパーシステンスが設定されているか

IPパーシステンスありのケース

Shibboleth SP の shibd デーモンはアクセスしてくるブラウザの Shibboleth Session の情報を管理しています。Web サーバが分散している場合、それぞれのサーバで独立して shibd デーモンが動いていると、セッション管理が分かれてしまいます。

IP パーシステンスありの振り分けが行われていれば、利用者がブラウザで操作していてリクエスト先 Web サーバがコロコロ変わることはありませんので、特に問題ありません。各 Web サーバに同一の設定で Shibboleth SP をインストールします。設定方法は１台の時と同じで、設定コピーで大丈夫です。

多くのケースでは、パーシステンスの設定がなされていると思います。

IP パーシステンスなしのケース

IP パーシステンスなしの振り分けが行われていると、同じ利用者が操作していて、アクセスするWebサーバがコロコロと切り替わる可能性があります。Shibboleth セッションが各Webサーバで共有されていないと、リクエスト先サーバが切り替わった時にに認証処理のやり直しになったり、サーバURLは共通のはずですのでクッキーの値の整合が取れなくなったりします。

リバースプロキシ型のゲートウェイホストを立ててシボレス認証を集約させる手段もあると思いますが、そのような構成が取れるくらいなら、IPパーシステンスありのLBが設置できると思います。わざわざシボレスのために構成を追加するまでもないことが多いと思います。

このような場合には、Web サーバのどれか１台で shibd デーモンを動かし、他の Web サーバからの Shibboleth SP の処理も引き受ける方法をとります。

前提

公開サービスの URL を https://some.service/ とします。

２台の Web サーバでサービスを構築しているとします。

Web1 Global IP : 123.123.123.1 , Local IP: 192.168.1.10
Web2 Global IP : 123.123.123.2 , Local IP: 192.168.1.11

ここでは単純化のため、Web1 と Web2 にはそれぞれ SSL 証明書がインストールされており、振り分けは IP やセッションを無視しするとします。

Web1 と Web2 は、 Shibboleth SP のインストールまで終わっているとします。

Web1 で shibd デーモンを動かし、Web2 の処理も引き受ける設定を目指します。

Shibbleth SP と IDP の連携設定

まずは Web 1 で Shibboleth 認証ができるよう、Shibboleth SP の設定に従って設定します。

証明書の交換や属性の受け渡しチェックが主な注意事項になります。

Web 1 の Listener 設定

Web1 で動いている shibd デーモンが TCP ポートを介して処理を受け付けることができるようにします。

shibboleth2.xml の <SPConfig> タグの直下の階層、<OutOfProcess> の後に以下を追記します。

<TCPListener address="192.168.1.10" port="56000" acl="192.168.1.10 192.168.1.11 "/>

wiki.shibboleth.net : SP3/TCPListener

address には Web1 が待ち受けに使う IP アドレス、ポートは未使用ポートを shibd 用にあてがいます。acl には、Web1 の shibd デーモンが受付を許可する相手のIPアドレスをスペースで区切って列挙します。

Web1 の shidb デーモンと apache2 をリスタートします。

うまくいけば Web1 でシボレス認証を使える状態になります。もしshibdとmod_shibとの通信がうまく行かないときは、syslog にエラーが出力されます。

Web 2 の設定

Web2 にはWeb1 と同じ shibboleth2.xml を使います。Web1 の設定を一通りコピーで問題ありません。ただし、このサーバでは shibd デーモンは使用しません。shibboleth2.xml は Apache の shibboleth モジュールがロードします。

そこで、shibd の停止と Apache のリロードを行います。

# systemctl stop shibd
# systemctl disable shibd
# systemctl restart apache2

うまくいけば、これでWeb2でも共通の Shibboleth セッションで利用できます。

もしshibdとmod_shibとの通信がうまく行かないときは、syslog に以下のようなエラーが出力されます。

Sep 18 16:46:35 webclass shibboleth: ERROR Shibboleth.Listener [1670] shib_check_user [default]: failed socket call (connect), result (111): Connection refused
Sep 18 16:46:35 webclass shibboleth: WARN Shibboleth.Listener [1670] shib_check_user [default]: cannot connect socket (18)...retrying
Sep 18 16:46:36 webclass shibboleth: ERROR Shibboleth.Listener [1687] shib_check_user [default]: failed socket call (connect), result (111): Connection refused
Sep 18 16:46:36 webclass shibboleth: WARN Shibboleth.Listener [1687] shib_check_user [default]: cannot connect socket (18)...
Sep 18 16:46:36 webclass shibboleth: CRIT Shibboleth.Listener [1687] shib_check_user [default]: socket server unavailable, failing
Sep 18 16:46:36 webclass shibboleth: ERROR Shibboleth.Apache [1687] shib_check_user: Cannot connect to shibd process, a site administrator should be notified that this web server has malfunctioned.

パフォーマンスの調整

分散する Web サーバが多いと、シボレスの処理を１台に集約することがボトルネックになるかもしれません。なお、処理が重いシボレスのセッション処理は、利用者が最初に SP にアクセスしてきて、SPが IDP と認証確認する部分になります。この処理は、一旦行われればセッションが切れるまでは必要なくなります。利用者が web サービスに多数のリクエストの送ってくるうちのごく一部のリクエストになりますので、１サーバに集約したからといって、急に遅くなったりするものではありません。

もし Shibboleth の処理部分で応答時間の問題が認められ、かつ SingleLogout 機能を使用しないのであれば、maintainReverseIndex 機能を止めることでパフォーマンスが良くなります。なお WebClass では SingleLogout は使用しません。

この場合は shibboleth2.xml の<SPConfig>タグの直下の階層に以下を追記します。

     <StorageService type="Memory" id="mem" cleanupInterval="5"/>
     <SessionCache type="StorageService" StorageService="mem" cacheAssertions="false"
                 cacheAllowance="0" inprocTimeout="0" cleanupInterval="5" maintainReverseIndex="false"/>

wiki.shibboleth.net : SP3/StorageService

wiki.shibboleth.net : SP3/SessionCache