キャンセル
次の結果を表示 
次の代わりに検索 
もしかして: 
cancel
4824
閲覧回数
6
いいね!
0
コメント
tkitahar
Cisco Employee
Cisco Employee

 

※ 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 回行われる理由について説明します。以下の図は、この時の実際の通信の流れになります。

 

pic1.png

 

ユーザーからの 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 認証自体が行われなくなります。

Getting Started

検索バーにキーワード、フレーズ、または質問を入力し、お探しのものを見つけましょう

シスコ コミュニティをいち早く使いこなしていただけるよう役立つリンクをまとめました。みなさんのジャーニーがより良いものとなるようお手伝いします