※ 2024 年 12 月 27 日現在の情報をもとに作成しています
1. はじめに
SWG (Secure Web Gateway) では、IdP (アイデンティティ プロバイダ) と連携して、ユーザーの Web アクセスの際に SAML を使ったユーザー認証 (SAML 認証とも呼ぶ) を行うことが可能です。本記事では、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 では、PAC ファイル、Proxy Chaining、ネットワーク トンネルの構成で SAML 認証を利用することが可能です。本項では、PAC ファイル を使用しているユーザーを例に説明します。
ユーザーからの Web リクエストが SWG に送られると (1)、SWG はいつものようにアイデンティティの識別を行います。PAC ファイルを使用している場合、アイデンティティはネットワーク (グローバル IP アドレス) になりますので、Web ポリシーの一番上から順に、当該のネットワークが選択されているポリシーを探し、Web ポリシーを 1 つ決定します。
選ばれた Web ポリシーの中で SAML が有効かどうかを確認します。もし、SAML が有効になっていない場合、SWG はそのまま Web ポリシーの内容に従って、ブロックするか否かの判断を行います。一方で、SAML が有効になっている場合、SWG は信頼関係を持つ IdP (アイデンティティ プロバイダ) へ Web 通信をリダイレクトする旨のレスポンスをユーザーに返します (2)。
※ SWG のような IdP (アイデンティティ プロバイダ) に認証を依頼する側のことを「サービス プロバイダ」と呼びます
※ SAML が有効になっていても、宛先が HTTPS 検査の除外対象となっている場合、SAML 認証は行われません
ユーザーはリダイレクト先である IdP にアクセスし、IdP に対してユーザー認証を行います (3)。このユーザー認証に問題がなければ、IdP は SWG へ Web 通信をリダイレクトする旨のレスポンスをユーザーに返します (4)。そのレスポンスには、アサーションと呼ばれる認証結果が含まれています。
ユーザーはアサーションとともに、再度 SWG にアクセスします (5)。SWG はアサーションの内容に問題がなければ、このユーザーとアサーションに書かれているユーザー アカウント (Umbrella では AD ユーザーに該当) を紐づけます。
以上の工程を経て、このユーザーからの Web アクセスに対して、ネットワークの他に AD ユーザーのアイデンティティが割り当てられます。
その後、SWG は再度 Web ポリシーの一番上から順に、当該のネットワークまたは AD ユーザーが選択されているポリシーを探し、Web ポリシーを 1 つ決定します。
SWG は 2 回目に選ばれた Web ポリシーを使って、普段どおりブロックするか否かの判断を行い、ブロック対象でなければ、最終的にユーザーに Web ページが返されます (6)。
以上のように、「SAML によるユーザー認証」と「実際のブロック判断」のために Web ポリシーの選択が 2 回行われることになります。次項では、Web ポリシーの具体的な設定例を見ていきます。
4. Web ポリシーの設定例と注意点
では、実際の Web ポリシーの設定例を見ていきます。以下の例では、ユーザー A とユーザー B 用の Web ポリシーを用意しています。
ユーザー A 用 Web ポリシー (優先順位 1)
アイデンティティ => AD ユーザー内のユーザー A
SAML => 無効
コンテンツ カテゴリなどのブロック設定 => あり
ユーザー B 用 Web ポリシー (優先順位 2)
アイデンティティ => AD ユーザー内のユーザー B
SAML => 無効
コンテンツ カテゴリなどのブロック設定 => あり
SAML 認証用 Web ポリシー (優先順位 3)
アイデンティティ => ネットワーク
HTTPS 検査 => 有効 (強制)
SAML => 有効
コンテンツ カテゴリなどのブロック設定 => なし
※ さらに多くのユーザーまたはグループ用のポリシーを用意しても問題ありません
※ 一般的にユーザー用のポリシー側では SAML を有効にしません
このような設定をした場合、1 回目の Web ポリシーの選択では、アイデンティティがネットワークである SAML 認証用 Web ポリシーが選ばれ、まず SAML 認証が行われます。そして、2 回目の Web ポリシーの選択では、アイデンティティが AD ユーザーであるユーザー A 用 Web ポリシーまたはユーザー B 用 Web ポリシーが選ばれます。
なお、SAML 認証用 Web ポリシーをユーザー用 Web ポリシーよりも高い優先順位に配置してしまった場合、1 回目の選択は問題なく行われますが、2 回目の選択でも SAML 認証用ポリシーが選ばれてしまい、ユーザーごとにポリシーを分けることができません。以下のサポート記事にも関連した記載があります。
SAML Identity not applied for Secure Web Gateway Traffic
また、ユーザー用の Web ポリシーのアイデンティティにネットワークを付け加えてしまわないように注意する必要もあります。このような設定をした場合、1 回目の Web ポリシーの選択で SAML が無効になっているポリシーが選択されてしまい、SAML 認証自体が行われなくなります。
検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう
シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします
