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

確認事項

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

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

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

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

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

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

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

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

前提

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

2台の 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> タグの直下の階層に以下を追記します。

<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 をリスタートします。

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 セッションで利用できます。

パフォーマンスの調整

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

もし 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