※ 2022 年 7 月 22 日現在の情報をもとに作成しています
1. はじめに
SWG (Secure Web Gateway) では、IdP (アイデンティティ プロバイダ) と連携して、ユーザーの Web アクセスの際に SAML を使ったユーザー認証を行うことが可能です。本記事では、このユーザー認証を行う際の Web ポリシーの設定例と注意点について説明します。
なお、SAML の設定自体については本記事で扱いません。必要に応じて、以下の公開文書を参照してください。
Configure SAML Integrations
https://docs.umbrella.com/umbrella-user-guide/docs/configure-saml-integrations
2. Umbrella と SAML について
Umbrella には、SAML の技術を使った機能が現在 2 つがあり、今回の話は以下のうちの後者となります。
- SAML による Umbrella Dashboard の SSO (シングルサインオン)
- SAML による SWG のユーザー認証
前者について書かれた記事の中にも SAML の説明がありますので、そちらも併せて参照してください。
3. 処理の流れ
SWG で SAML によるユーザー認証をする場合、Web ポリシーの選択は 2 回行われます。これは、ポリシーの選択を 1 回しか行わない他の実装方法と比べると、非常に特殊な動作といえます。
それでは、SAML 認証が設定された SWG 環境で、PAC ファイル を使用しているユーザーが Web アクセスをする場合を例に、Web ポリシーの選択が 2 回行われる理由について説明します。以下の図は、この時の実際の通信の流れになります。
ユーザーからの Web リクエストが SWG に送られると (1)、SWG (この役割のことを一般的にサービス プロバイダと呼ぶ) はまずアイデンティティの識別を行います。PAC ファイルを使用している場合、アイデンティティはグローバル IP アドレスになりますので、Web ポリシーの一番上から順にグローバル IP アドレスが選択されているポリシーを探し、一回目に適用する Web ポリシーを決定します。
1 回目の Web ポリシーでは、まず SAML が有効かどうかを確認します。もし、SAML が有効になっていない場合は、そのまま Web ポリシーの内容に従って、ブロックするか否かの判断を行います。一方で、SAML が有効になっている場合は、信頼関係を持つ IdP へリダイレクトする旨のレスポンスをユーザーに返します (2)。
SWG からのレスポンスを受け取ったユーザーは、リダイレクト先である IdP にアクセスし、そこで IdP 側が用意した認証が行われます (3)。このユーザー認証に問題がなければ、IdP は SWG へリダイレクトする旨のレスポンスをユーザーに返します (4)。そのレスポンスには、アサーションと呼ばれる認証結果が含まれています。
IdP からレスポンスを受け取ったユーザーは、アサーションとともにリダイレクト先である SWG にアクセスします (5)。SWG はアサーションの内容に問題がなければ、ここで 2 回目の Web ポリシーの選択を行います。今回のアイデンティティには、先ほど認証を行ったユーザー名が使用され、Web ポリシーの一番上から順にユーザー名が選択されているポリシーを探し、2 回目に適用する Web ポリシーを決定します。
2 回目の Web ポリシーでは、通常どおりブロックするか否かの判断を行い、ブロック対象でなければ、最終的にユーザーに Web ページが返されます (6)。
以上のように、「SAML の有効性確認」と「実際のブロック判断」のために Web ポリシーの選択が 2 回行われることになりますが、その理由としては、ユーザーごと (またはユーザーをまとめたグループごと) にポリシーを分けることができるようにするためです。次項で具体的な設定例を通して、この点についてさらに説明します。
4. Web ポリシーの設定例と注意点
前項で、Web ポリシーの選択を 2 回行うのはユーザーごとにポリシーを分けるためと説明しましたが、以下のような Web ポリシーの設定を行った場合が顕著な例です。
Web ポリシー 1
アイデンティティ => ユーザー A
SAML => 無効
コンテンツ カテゴリなどのブロック設定 => あり
Web ポリシー 2
アイデンティティ => ユーザー B
SAML => 無効
コンテンツ カテゴリなどのブロック設定 => あり
Web ポリシー 3
アイデンティティ => グローバル IP アドレス
SAML => 有効
コンテンツ カテゴリなどのブロック設定 => なし
※ さらに多くのユーザーまたはグループ用のポリシーを用意しても問題ありません
※ 慣例的に、ユーザー用のポリシーでは SAML を無効にします
このような設定をした場合、1 回目の Web ポリシーの選択では、アイデンティティがグローバル IP アドレスである Web ポリシー 3 が選ばれ、まず SAML の有効性の確認が行われます。そして、2 回目の Web ポリシーの選択では、アイデンティティがユーザー名である Web ポリシー 1 または Web ポリシー 2 が選ばれます。これにより、実際のブロック判定をユーザーごとに分けることが可能になります。
なお、Web ポリシー 3 を Web ポリシー 1 および Web ポリシー 2 よりも前に配置してしまった場合、1 回目の選択は問題なく行われますが、2 回目の選択でも Web ポリシー 3 が選ばれてしまい、ユーザーごとにポリシーを分けることができません。これは、2 回目の選択の際に対象となるアイデンティティは、厳密には「グローバル IP アドレス」と「ユーザー名」の両方であるためです。以下のサポート記事にも関連した記載があります。
SAML Identity not applied for Secure Web Gateway Traffic
https://support.umbrella.com/hc/en-us/articles/360041508731-SAML-Identity-not-applied-for-Secure-Web-Gateway-Traffic
また、Web ポリシー 1 と Web ポリシー 2 のアイデンティティにグローバル IP アドレスを付け加えてしまわないように注意する必要もあります。このような設定をした場合、1 回目の選択で SAML が無効になっているポリシーが選択されてしまい、SAML 認証自体が行われなくなります。