シングル ログアウトの概要(SAML 2.0)

目次
casso127jpjp
目次
2
シングル ログアウト(SLO)により、ログアウトを開始したブラウザのすべてのユーザ セッションが同時に終了します。すべてのユーザ セッションを閉じることにより、権限のないユーザが SP のリソースにアクセスできないようにします。
シングル ログアウトにより、特定ユーザに関するすべてのセッションが必ずしも終了するとは限りません。たとえば、ブラウザを 2 つ開いているユーザは、独立した 2 つのセッションを持つことができますが、ログアウトを開始したブラウザのセッションだけが、そのセッションのすべてのフェデレーション サイトで終了します。もう一方のブラウザのセッションは、引き続きアクティブです。
シングル ログアウト バインディングによって、シングル ログアウト メッセージと共に送信されるもの、および受信した各メッセージを処理する方法が決まります。
重要:
シングル ログアウトを設定するには、ポリシー サーバ管理コンソールを使用してセッション ストアを有効にします。
以下の 2 つのバインディングをシングル ログアウト操作で使用できます。
  • HTTP リダイレクト
    HTTP リダイレクト バインディングでは、ブラウザを使用して各ログアウト トランザクションを実行します。シングル ログアウト メッセージは常に GET リクエストです。ブラウザはすべてのリクエストおよびレスポンスに関与します。ブラウザの関与は、HTTP リダイレクト バインディングによってブラウザ セッション データが提供されることを意味します(SOAP バインディングでは提供されません)。
    HTTP リダイレクト バインディングのデメリットは、メッセージ内のデータがクエリ文字列で送信できるものに制限されることです。また、HTTP リダイレクト バインディングは非同期処理なので、タイムアウトはほとんど発生しません。ただし、リダイレクトが失敗すると、全シングル ログアウトが停止します。
  • SOAP
    SOAP バインディングでは、POST リクエストを使用してシングル ログアウト トランザクションを実行します。POST リクエストによって HTTP リダイレクト バインディングより多くのデータを送信できます。SOAP によって、暗号化の方法および他の機能でより多くのことを実行することもできます。
    SOAP は同期処理です。IdP はより制御性があり、1 つの SP での問題がプロセス全体に干渉することを防ぐことができます。SOAP 通信はバック チャネルで行われます。1 つのログアウト失敗によって、IdP が残りの SP からログアウトすることを中断されることはありません。
    SOAP はバック チャネル接続を使用しますので、最初のシングル ログアウト コールおよびレスポンスの後、ブラウザは関与しません。SOAP バインディングでは、ログアウト プロセスの一部としてリモート エンティティの Cookie をクリーンアップしません。Cookie はローカル エンティティでのみクリーンアップされます。Cookie の削除が必要な場合は、HTTP リダイレクト バインディングを使用します。
HTTP リダイレクトおよび SOAP を使用してネットワーク全体のシングル ログアウトを管理する
ネットワークには、HTTP リダイレクト バインディングをサポートするサイトおよび SOAP バインディングをサポートするサイトがある場合があります。IdP は複数のバインディングを管理する必要がありますが、SP は 1 つのログアウト リクエストのみを送信または受信します。
以下のセクションでは、バインディングが混在する環境に対応するための設定ガイドラインについて説明します。
  • Single Sign-On
    が IdP にある場合の SLO 設定
    Single Sign-On
    が IdP にある場合、HTTP リダイレクト ベースの SLO サービス URL および SOAP ベースの SLO サービス URL を含めるようにパートナーシップを設定します。
    IdP の
    Single Sign-On
    は、セッションの各 SP の設定を確認して、SOAP が有効なすべてのログアウトを最初に処理します。その後 SOAP をサポートしない SP の HTTP リダイレクト ログアウトが続きます。
  • Single Sign-On
    が SP にある場合の SLO 設定
    Single Sign-On
    が SP にあり、SP がシングル ログアウトを開始する場合は、HTTP リダイレクト バインディングでログアウトを開始することをお勧めします。ユーザ セッションの他の SP は SOAP をサポートしない可能性があります。
    HTTP リダイレクトは、ブラウザ セッションを使用してすべてのリダイレクトを処理します。このため、HTTP リダイレクトは、IdP が HTTP リダイレクトのみをサポートする SP をログアウトするために必要なデータを送信します。SP が HTTP リダイレクトでプロセスを開始する場合、IdP はそれをサポートするすべての SP と共に SOAP を使用できます。残りの SP については HTTP リダイレクト バインディングに切り替えます。SOAP バインディングでシングル ログアウトを開始する場合、ブラウザ セッション データは存在しません。
    SP によって開始されるログアウトで確実に HTTP リダイレクトが使用されるように、SP のローカル サーブレットを指す HTTP リダイレクト リンクをページまたはアプリケーションに埋め込みます。
    Single Sign-On
    用のリンクは次のとおりです: http://
    sp_host:port
    /affwebservices/public/saml2slo
    この埋め込みリンクによって、
    Single Sign-On
    は IdP の SLO サービスに送る SAML <LogoutRequest> メッセージを生成します。ユーザがログアウトするときは、まず SP のログアウトが実行され、次にログアウト リクエストが IdP に送信されます。その後、IdP は、ユーザ セッションに関連する他のすべての SP と共にログアウト プロセスを完了します。
SLO リクエスト有効期間に関するスキュー時間の概要
ログアウト リクエストの有効な期間の計算には、2 つの値が関連します。これらの値は IssueInstant 値および NotOnOrAfter 値です。SLO レスポンスでは、NotOnOrAfter 値になるまでシングル ログアウト リクエストが有効です。シングル ログアウト リクエストの生成時に、
Single Sign-On
はシステム時間を取得します。この時間がリクエスト メッセージの IssueInstant 設定になります。ログアウト リクエストが期限切れになるときを特定するために、
Single Sign-On
は現在のシステム時間を取得し、[スキュー時間]および[SLO 有効期間]を加えます。その結果の時間が NotOnOrAfter 値になります。
注:
時刻は GMT を基準にしています。
たとえば、ログアウト リクエストが 1:00 (GMT)にアサーティング パーティで生成されます。スキュー時間は 30 秒、SLO 有効期間は 60 秒です。したがって、そのリクエストは 1:00 GMT から 1:01:30 GMT までの間が有効です。IssueInstant 値は 1:00 GMT です。シングル ログアウト リクエスト メッセージはその後 90 秒で無効になります。
シングル ログアウトの設定
シングル ログアウトを設定するには、ポリシー サーバ管理コンソールを使用して、セッション ストアを有効にする必要があります。セッション ストアが有効にされていない場合、管理 UI でシングル ログアウト設定を確認できません。
シングル ログアウトの設定時には、以下の情報に注意してください。
  • パートナーが HTTP リダイレクトを使用して SAML <LogoutRequest> メッセージを受信する場合、送信元に返すレスポンスでは HTTP リダイレクト バインディングを使用する必要があります。
  • パートナーが SOAP を使用して SAML <LogoutRequest> メッセージを受信する場合、送信元に返すレスポンスは SOAP を経由する必要があります。
  • パートナーがサポートしていないバインディングによって SLO リクエストを受信すると、シングル ログアウトは失敗します。
  • シングル ログアウト ユーザ セッションに HTTP リダイレクト バインディングおよび SOAP バインディングを使用するパートナーが含まれる場合は、両方のバインディングをサポートするように
    Single Sign-On
    を設定します。IdP がログアウトを続行すると、SOAP を使用するすべてのSP からログアウトしてから、HTTP リダイレクト バインディングを使用するすべての SP からログアウトします。
  • Single Sign-On
    SP がシングル ログアウトを開始する場合は、SP が SOAP をサポートしていても、HTTP リダイレクト バインディングを使用して開始します。
    SOAP および HTTP リダイレクトがサポートされている混在環境でのシングル ログアウトの管理に関するガイドラインを確認してください。
以下の手順に従います。
注:
SLO 環境設定は IdP と SP で同じです。
  1. パートナーシップ ウィザードの[SSO と SLO]手順から始めます。
  2. [SLO]セクションで、1 つまたは両方の SLO バインディングを選択します。
    SLO バインディングによってシングル ログアウトが有効になり、ローカル エンティティで使用しているバインディングが示されます。さらに SLO バインディングによって、ローカル エンティティがシングル ログアウト リクエストを受信するときに使用するバインディングが示されます。
    SOAP を選択する場合、SOAP メッセージ内の名前 ID を暗号化できます。暗号化オプションはパートナーシップ ウィザードの[署名および暗号化]手順で設定されます。
    バインディングとして[SOAP]を選択する場合、[バック チャネル]の[受信および送信設定]はアクティブになります。SLO リクエストおよびレスポンスはバック チャネルを介して送信されます。各ローカル パートナーは、リモート パートナーによる認証を要求することによってバック チャネルを保護できます。
    SLO のバック チャネル設定に関する詳細を確認できます。
  3. 他の SLO 設定のいずれかを設定します。
    • SLO 確認 URL
    • SLO 有効期間(秒)
    • リレー状態を使用して SLO 確認 URL をオーバーライドする
       
  4. [SLO サービス URL]のテーブルに入力します。1 つ以上のエンティティを入力する必要があります。選択されたリモート エンティティに定義された値は、すでにテーブルに入力されています。
    SLO サービス URL はシングル ログアウトを開始し、その後、ポリシー サーバをトリガして SAML <LogoutRequest> メッセージを生成します。さらに、SLO サービス URL は、ログアウト リクエスト メッセージの送信先をポリシー サーバに指示します。
    以下のように、サポートされている各 SLO バインディングに SLO サービス URL を指定します。
    • HTTP リダイレクト対応 - HTTP リダイレクトをバインディングとして 1 つの URL を選択します。
      このオプションを選択すると、
      [属性および名前 ID サービスに関するユーザの検索]
      セクションが表示されます。 [カスタム]フィールドには、ユーザ ディレクトリ検索条件を指定します。 入力した値によって、ユーザ ディレクトリでのユーザ レコードの検索方法がポリシー サーバに指示されます。以下のように、ディレクトリ タイプに適切な検索文字列を入力します。
      LDAP: uid=%s
      ODBC: name=%s
       
    • SOAP 対応 - SOAP をバインディングとして 1 つの URL を選択します。
    • リダイレクトおよび SOAP 対応 - 1 つは HTTP リダイレクト、もう 1 つは SOAP に設定して 2 つの URL を選択します。
    注:
    [レスポンス ロケーション URL]フィールドはオプションです。
シングル ログアウト設定が完了しました。
シングル ログアウト用バック チャネル設定
SOAP バインディングを使用するシングル ログアウトでは、ログアウト リクエストおよびレスポンスがバック チャネルを介して送信されます。バック チャネルへのアクセスを認証するためにエンティティを要求できます。必須ではありませんが、SSL を使用してバック チャネルを保護することができます。
SSL を使用してバック チャネルを保護するには、以下を実行する必要があります。
  • SSL を有効にする。
    SSL は基本認証には必要ありませんが、SSL を介して基本認証を使用できます。SSL はクライアント証明書認証に必要です。
  • シングル ログアウト通信交換用に受信および送信バック チャネルを設定します。ローカル エンティティは、送信チャネルでメッセージを送信し、受信チャネルでメッセージを受信できる必要があります。
    注:
    1 つの受信および送信バック チャネルを設定できますが、チャネルに設定できるのは 1 つの設定のみです。2 つのサービスが同じチャネルを使用する場合、これらの 2 つのサービスは同じバック チャネル設定を使用します。たとえば、ローカルのアサーティング パーティの受信チャネルが HTTP-Artifact SSO と SLO over SOAP をサポートする場合、これらの 2 つのサービスは同じバック チャネル設定を使用する必要があります。
  • 保護されているバック チャネルを介してアクセスできるようにリモート エンティティ用の認証タイプを選択する。認証方法はチャネルごと(受信または送信)に適用されます。
    バック チャネル認証のオプションは以下のとおりです。
    • 基本
      基本認証方式がバック チャネルを保護していることを示します。
      注:
      SSL がバック チャネル接続に対して有効な場合も、基本認証を選択できます。
    • クライアント証明書
      X.509 クライアント証明書を含む SSL がアサーティング パーティ バック チャネルを保護することを示します。
      認証方法として[クライアント証明書]を選択する場合、すべてのエンドポイント URL が SSL 通信を使用する必要があります。これは、URL が
      https://
      で始まる必要があることを意味します。エンドポイント URL によって、サーバ上でシングル サインオン、シングル ログアウトおよびアサーション コンシューマ サービスなどさまざまな SAML サービスが特定されます。
    • 認証なし
      依存パーティが認証情報を提供する必要がないことを示します。バック チャネルは保護されません。このオプションでも SSL を有効にできます。バック チャネル トラフィックは暗号化されますが、認証情報は保証機関と依存パーティの間で交換されません。
      認証なし(NoAuth)オプションは、実稼働用ではなくテスト用にのみ使用します。
      Single Sign-On
      が SSL 対応のフェールオーバを実装するプロキシ サーバの背後にある場合は例外です。クライアント証明書認証がバック チャネルの保護に使用される場合、プロキシ サーバは認証を処理します。IdP から SP へのすべてのパートナーシップは認証タイプとして[NoAuth]を使用できます。
    重要:
    受信バック チャネル用の認証方法は、パートナーシップの反対側の送信バック チャネルに一致する必要があります。認証方法の選択の一致は帯域外通信で処理されます。
シングル ログアウト用バック チャネルを保護する方法
  1. パートナーシップ ウィザードの[SSO と SLO]手順の[バック チャネル]セクションから始めます。
  2. [SLO]セクションで[SOAP]を選択します。[認証方法]フィールドはアクティブになります。
  3. 受信および送信バック チャネルに対して認証方法のタイプを選択します。その他の設定するフィールドが、基本およびクライアント証明書方式用に表示されます。
    認証方法として[認証なし]を選択する場合、これ以上の手順は必要ありません。
  4. 選択する認証方法に応じて、設定するフィールドがさらに表示されます。
すべての必要なフィールドに値を入力したら、バック チャネル設定は完了です。