目次

 

SAML 概要

• ソリューションのコンポーネント SAML SSO 。

• ユース ケース。

• SAML 論理フロー。

• TOOLS.

• SAML メッセージ。

• • SAML 認証要求。

  • SAML 認証応答。

  • SAML ログアウト要求。

  • SAML ログアウト応答。

• IdP メタデータ XML :

• SP メタデータ XML :

 

 

 

SAML 概要

 

セキュリティ アサーション マークアップ言語 2.0 (SAML 2.0) は、 XML- セキュリティ ドメイン間で認証および認可データを交換するためのベースの標準です。 SAML 企業では、主に、複数のエンティティ間での Web ベースのシングル サインオンとフェデレーション ID という 2 つの要件を解決します。 シングル サインオンの複数の組織やアプリケーション間でアイデンティティ情報を共有することによって実現されます。 フェデレーション id により、あの手この手でプロバイダーにそのユーザーがわかっている場合でも、単一のユーザーを参照する方法に同意するサービス プロバイダーの設定です。

 

ソリューションのコンポーネント SAML SSO

 

通常、3 つのエンティティが SAML トランザクションに参加します。

• プリンシパル (ユーザー)
• サービス プロバイダ ( SP )
• ID プロバイダー (IdP)

 

サービス プロバイダーは、通常、アプリケーションまたはプリンシパルへのアクセスを要求するいると、Id プロバイダーが id に差し込まれているエンティティを保存するサービスは、ユーザーの資格情報を運ぶ。 SAML は、IdP がユーザーの認証に使用できる手法を定義しません。 SP これにより、IdP は、ユーザーを認証するために追加の認証テクニック (2FA/ MFA 、証明書ベースの認証..) を使用する自由を与えます。 SAML メッセージ XML はデータ交換形式として使用され、 HTTP これらのメッセージをセキュリティで保護するための強力な要件を満たして転送されます SSL ( TLS HTTPS )

 

SAML アサーション には、認証とユーザに関する情報が含まれます。 アサーションには、受信側は、アクセス制御決定をする使用できる情報が含まれています。 アサート ステートメントの 3 種類あります。

 

• 認証ステートメント には、ユーザーの ID を確保するために使用される時間や方法などの情報が含まれます。

 

• Attribute ステートメント には、ユーザー名、電話番号、住所などのユーザーに関する情報が含まれています。など。

 

• 許可決定ステートメント は、ユーザーが指定されたリソースへのアクセスを許可されているかどうかを確認します。

 

SAML アサーションを含むセキュリティ トークンを使用して、プリンシパル (通常はエンド ユーザー) に関する情報を SAML 、認証プロバイダとコンシューマ (サービス プロバイダ) の間 SAML で渡します。 たとえば、Id プロバイダーは、このユーザーが認証されている、関連付けられている属性を与えていることをアサートします。 SAMLでは、ID プロバイダは SAML 、権限およびアサーティング パーティとも呼ばれます。 サービス プロバイダは、アイデンティティ プロバイダ (アサー ティング パーティ ) によって提供される情報に "依存" するため、証明書利用者とも呼ばれます。 ID プロバイダはアサーションをアサーション コンシューマ サービス ( ACS ) に転送 URL し、このサービスはアサーションを検証して、エンド ユーザがアプリケーションやその他のリソースへのアクセス権を持っているかどうかを確認します。 ACS URL URLサービス プロバイダーがアサーションを受け取って使用する場所であるため、重要です。

 

メッセージを転送できる下位レベルの通信プロトコルまたはメッセージング プロトコル ( HTTP または SOAP ) は SAML 、Bindings によって定義されます。 SAML バインディング は、& IdP の通信方法を決定するエンドポイント SP 上のフックです。 HTTP輸送として、典型的な結合は REDIRECT HTTP (302)および POST HTTP POST ()を含む。 HTTP リダイレクト・バインディング: SAML リダイレクト・メッセージ HTTP (302 状況コード応答) を使用してプロトコル・メッセージを転送する方法を定義します。  SAML リダイレクトを介して送信される要求または応答 HTTP には、それぞれ SAMLRequest または SAMLResponse クエリ文字列パラメーターがあります。 送信前に、メッセージは (ヘッダーとチェックサムなし)、base64 エンコードされ、 URL- エンコードされた順序で縮小されます。 受領後、元のメッセージを回復する処理が逆に。 SP と IDP の両方が、リダイレクトまたはバインディングを使用してメッセージを送受信できます POST 。 URL特定のシナリオでは長さの制限があるため、 HTTP 通常は短いメッセージを渡すときに Redirect HTTP POST が使用され、長いメッセージを渡すときに使用されます。

 

HTTP POST バインディング: フォーム SAML コントロールの base64 でエンコードされたコンテンツ内でプロトコル メッセージを転送する方法を定義 HTML します。

パロアルトネットワークス SP エンドポイントは、 SAML を使用して転送された場合のみメッセージを受け入れることができます HTTP POST 。

注意が必要なもう 1 つの SAML 用語は 、メタデータです。 IdP と . SP 各 IdP と各 IdP SP には、独自のメタデータが必要です。 国内避難民と Sp は通常互いにメタデータを使用して登録されます。 通常、メタデータには SSO URL 、発行者名、および "公開" キーを含む証明書などの情報が含まれます PKI 。 たとえば、 a SP はこの情報を使用して IdP から取得したアサーションを信頼し、その逆も同様です。 SAML 2.0 は、エンティティが信頼プロセスをブートストラップするために利用できる、明確に定義された相互運用可能なメタデータ形式を提供します。 IdP によって提供されるメタデータ SP には、IdP に関する情報 (エンティティ ID SSO 、/など) が含まれています SLO URL 。など)、その逆も同様です。

 

 

ユースケース

 

SSO キャプティブ ポータルの場合:

ユーザーが特定のベースのリソースにアクセスしようとしたときに、キャプティブ ポータルを起動するために、当社の機能を使用したいと考 HTTP- えています。 ユーザーが複数回サインオンする必要性を軽減するために、顧客 SAML- SSO は、ユーザーが IdP で 1 回サインインし、ユーザーが必要な承認チェックに合格する限り、同じ IdP で登録されているサービス プロバイダーへのアクセスを許可するベース に依存します。 さらに、これらの顧客はキャプティブ ポータルを使用して、ユーザの ID /ユーザ IP マッピングの期限が切れている場合に、ユーザを透過的に識別します(User- )。 非脱落型ポータルは、保護されたリソースにアクセスしようとして、知られているユーザーの認証にも使用できます。 この機能は、管理者に必要なレベルのセキュリティを保証を提供、エンドユーザーに、手間のかからない簡単なインターフェイスを提供します。 組織では、複数のアプリケーションを同じ IdP を使用してユーザーを認証する作ることができます。 アプリケーションが SAML ユーザーを認証するために同じ IdP を使用している場合、ユーザーはそれらのアプリケーションにアクセスして認証を行うと、一貫したエクスペリエンスを得ることができます。

 

SSO の場合 GlobalProtect :

お客様は、 SAML SSO GlobalProtect SAML これらの企業が SSO すべてのアプリケーションに対して、およびすべてのデバイス プラットフォーム上のすべてのユーザーに対して単一のアーキテクチャを使用できるようにする. GlobalProtect複数のプラットフォームで動作し、 SAML プラットフォームに依存しないため、 SAML シングルサインオンには最適です。 GP ゲートウェイとポータルはサービス プロバイダーとして機能 SAML し、ID アサーションのプロセスをサード パーティの ID SAML プロバイダーに延期します。

 

SSO / 用 Firewall Panorama GUI :

Firewall Panorama管理者は手動 GUI で管理者にサインオンすることなく、管理者にアクセスしようとします。 認定管理者 GUI が、標準として展開された企業内で直接アクセスできるようにすることで SAML SSO 、ログオンに必要なユーザーの労力が減少し firewall Panorama 、ID アサーションの目的で集中認証エンジンに頼ることができます。

 

 

 

SAML 論理フロー

 

次の例では、非脱落型ポータルを使用してユーザーの認証フローを当てます。 ユーザー、リソース( firewall サービス プロバイダー)と IdP 間の対話が強調表示されます。 認証フローは他のエンドポイントでも同様です SP (管理 UI 、 GlobalProtect ポータル/ゲートウェイ、 GlobalProtect クライアントレス SSL VPN )

 

 認証フロー

 

1. ユーザーがリソースに対して要求を行う (サービス プロバイダ上、または bing.com などの Firewall Panorama GUI 別のWeb サーバー上のいずれか)
2. リソースへの要求が / にな Firewall らず Panorama GUI 、認証ルールが Policy 存在する場合、その要求が実行され、ユーザはキャプティブ ポータル にリダイレクトされます URL 。
3. ユーザのブラウザがキャプティブ ポータルにアクセス URL
4. サービス プロバイダは、ユーザーが認証する方法を示す AuthnRequest オブジェクト SP を作成します。 AuthnRequest はエンコードされ、ユーザーのブラウザーを介して ID プロバイダー HTTP POST または HTTP リダイレクトメソッドに送信されます。 SAML認証リクエスト、レスポンスなどに関する詳細文書の後半で説明します。
5. IdP がユーザーを認証して以前、IdP はユーザーを識別する cookie を送信します。 この cookie はブラウザーに保存されます。 前の手順 (手順 4) に続きは、ユーザーが以前、認証と共に、IdP で認証されている場合、ブラウザーに保存されている cookie はユーザーのブラウザーを介して IdP にも送信されます。 IdP は、有効な cookie は、それをチェックします。 有効な cookie が存在しない場合、または cookie が存在しない場合は、IdP は、ユーザーを認証します。 IdP のブラウザーにログイン要求と構成される認証メカニズムに基づいて、ユーザーを認証します。 たとえば、単純なフォームベースの認証を構成し、サーバーに LDAP 対してクエリを実行してユーザールックアップを実行できます。 ログイン要求とは、ブラウザーでユーザーに表示されます、ユーザー ログイン資格情報を入力し、IdP に戻ってそれらを投稿します。 IdP は、ログイン資格情報をサーバーに送信 LDAP します。 LDAP サーバーは資格情報をチェックし、検証ステータスを IdP に返します。
6. IdP はアサーションを作成 SAML し、秘密キーを使用してアサーションに署名し、アサーションを含むメソッドを介してユーザをサービス プロバイダ HTTP POST にリダイレクトします SAML 。 アサーションで提供された情報を使用して、 は SP 、保護されたリソースへのユーザー アクセスの提供など、適切な決定を行います。
7. サービス プロバイダは SAML XML 、IdP によって提供されるアサーションとシグネチャを検証します。 ユーザ名 SAML 属性を使用してアサーションからユーザ名を抽出し、ユーザおよびユーザ グループを許可リストに対して検証します。 アクセス チェックに合格する場合、は、ブラウザーにリソースが返されます。 ブラウザは、bing.comなどのリソースへの接続を完了します。

 

TOOLS

 

メッセージのデバッグに役立つ、ブラウザー (Chrome など) に読み込むことができるいくつかの DevTools があります SAML 。 人気のある chrome の拡張機能には、次のものがあります。

• SAML クロームパネル
• SAML 開発ツールの拡張機能

 SAML 開発ツールの拡張機能

 

 

 

SAML メッセージ

 

SAML 認証要求

 

認証要求 は、 SAML 認証を SP 開始するために IdP に送信するメッセージです。 このメッセージは、Base64 でエンコードされた、IdP に送信します。 Base64 でエンコードされた SAML 認証要求と共に、リレーステート トークンが IdP に送信されます。 Relaystate トークンは、サービス プロバイダーで保持されている状態情報を参照する不透明な識別子です。 このトークンは、応答メッセージの IdP によってエコーされます。

 

 

SAML オーテンリクエスト

上記の認証における重要な要素は次のとおりです。

• アサーション コンシューマー サービス URL
• 先 URL
• 要求 (インスタント号) の時間
• ID 要求の
• 発行者

 

アサーション コンシューマー サービス URL は、認証が完了した後に IdP によって応答メッセージが送信されるサービス プロバイダーのアドレスです。

 

送信先 URL は IdP によってチェックされ、認証要求が実際にそれに対して意図されていることを検証します。 これは意図しない受信者に悪意のある要求転送を防ぐために役立ちます。

 

要求の時間 は IdP によってチェックされ、要求が古すぎていないかどうかを確認します。

IDの乱数が生成され、リクエストの応答と一致することが重要です。

 

発行者は 、要求メッセージを生成したエンティティを識別します。 通常、すべての要求と応答には ID 、送信者のエンティティが含まれています。

 

留意する必要があるその他の要素は次のとおりです。

 

• プロトコル バインディング
• 署名
• ダイジェスト値
• X509 証明書

 

プロトコル バインド は、 URI SAML 応答メッセージを返すときに使用されるプロトコル バインドを識別する参照です。

 

署名 と ダイジェスト値 は、要求メッセージと応答メッセージのメッセージの整合性を確保するために使用されます。 この値は、メッセージの整合性を保証するために、同じ ダイジェストメソッド (SHA1 など) を使用して受信側で相互チェックおよび検証されます。

 

X509 証明書: SAML で SP 、 と IdP は公開証明書キーを相互に交換します。 証明書を得るインストールし、明示的に信頼されています。 キーの元の信頼を確立するには、証明機関を使用できます。 認証または応答メッセージに含まれている公開キーは、メッセージを対応する秘密キーを持つエンティティに署名パートナーに示すことです。 それはちょうどキーが他の党に属しているを判断します。

 

イチジク: SAML 認証リクエスト ( FW GUI およびクロム開発ツール)

 

SAML オーテンリクエスト

イチジク: リレーステート

 

RelayState

 

SAML 認証応答

 

IdP は、ユーザーを認証した後、Base64 エンコード SAML された応答を作成し、サービス プロバイダーに転送します。

認証リクエストへの応答として、IdP は SP にステータスおよびセキュリティ アサーションを送信します。 応答には、ユーザーは IdP で正常に認証の場合成功ステータスとアサーションを含まれます。 その他の障害の場合応答はエラーの理由を示すステータスを含み、任意のアサーションは含まれません。 IdP はユーザーを認証し SP 、 はこのプロセスに関与しません。 SP 認証のステータスを受け取るだけです。

 

SAML 応答 

 

応答で見られる要素の大半 SAML は、AuthnRequest で説明されているものと類似しています。 認証の対象とならないものを以下に示します。

 

• ステータス
• Nアメ ID
• セッション インデックス
• ステートメント属性と属性値
• 認証文

 

ステータス 要素は、ユーザが正常に認証されたかどうかを示します

 

NameID は認証が成功した後のユーザー/プリンシパル セキュリティ セッションのライフ サイクルを管理する IdP によって作成されたユニークな識別子 (この例では、IdP はセッションの権限とみなされる)

 

セッションインデックスは、 SP ユーザー/プリンシパルが実行している ( SAML SSO この場合 SP はセッション参加者と見なされる) を追跡するために IdP によって作成された一意の識別子です。

 

属性ステートメント には、ユーザーに関連付けられた属性が含まれています。 上の例では、ユーザーの samAccountName が IdP から SP に送信されています。

 

認証ステートメント には、ユーザーの ID を確認するために使用される時間や方法などの情報が含まれています。

 

Fig: SAML レスポンス ( FW GUI およびクロム開発ツール)

 

SAML応答イチジク: 再レイステート

 

RelayState

 

SAML ログアウト要求

 

ユーザーが からログアウトすると Firewall GUI 、サービス プロバイダは SAML ユーザー セッションを終了するためのログアウト要求を作成します。 SLO要求は IdP に送信されます。 NameID とセッションインデックスは、IdP によって使用され、 SP ユーザー セッションを終了します。 IdP は、 SLO SP ユーザーがログオンした他のすべてのアプリケーションに対して要求を送信するのが理想的です。 だから、1 つのアプリケーションからユーザーがログオン、IdP は他のすべてのアプリケーションからユーザーをログオンしようとします。

 

SAML ログアウトリクエスト

 

[リダイレクト] が [バインド] として選択されている SAML HTTP SLO 場合は、要求で SAML 署名されたログアウト要求の署名が表示されます SP URL GET 。

 

図: SAML ログアウトリクエスト ( FW GUI およびクロム開発ツール)

 

SAML ログアウトリクエスト

SAML ログアウト応答

 

によって SLO IdP に送信された要求に対して SP 、IdP は成功または失敗を示すログアウト応答を送信します。 応答は、IdP によって署名されます。 SPは、ユーザーをログアウトする前に必要なクリーンアップを行います。 SPは、ユーザーに対して持っているセッション Cookie をクリアします。 次回、ユーザーがログインしようとすると、プロセス全体が SAML 再度再開されます。 SPセッション アイドル タイムアウトに基づいてユーザーのセッション Cookie をクリアし、 SAML ユーザーがアプリケーションに再度アクセスしようとしたときに認証プロセスを再開することもできます。

 

SAML 応答のログアウト

 

図: SAML ログアウトレスポンス ( FW GUI およびクロム開発ツール)

 

SAML 応答のログアウト

 

IdP メタデータ XML

 

IdP 間で信頼を共有 SP し、メタデータによって容易に容易にできます。

( SP Firewall または Panorama ) で、 IdP サーバ プロファイルは、提供された IdP メタデータ ファイルを使用して構築できます XML 。 メタデータで提供される情報は解析され、パナロマまたは構成に保存されます Firewall 。 IdP メタデータは、次の情報を含めることができます。

 

• IdP エンティティ ID
• Idp SSO URL
• SSO バインディング形式 ( SAML HTTP バインディング – POST /リダイレクト)
• Idp SLO URL
• SLO バインド形式 ( SAML HTTP バインディング – POST /リダイレクト)
• SAML 属性
  • ユーザー名属性名
  • グループ属性名
  • 管理者ロールの属性名
  • アクセス ドメイン属性名
• IdP 署名証明書
• IdP WantAuthnRequestsSigned フラグ

 エンティティ記述子

 

SP メタデータ XML

 

SP メタデータは、 / SAML から認証 プロファイル からエクスポートできます Panorama Firewall 。IdP が SP データに合致をアップロードするオプションを提供する場合、エクスポートされた SP メタデータを IdP にアップロードし、 SAML アプリケーションを簡単に作成できます。 前述のように、メタデータを利用して信頼プロセスをブートストラップできます。

 

SPメタデータには、次の情報が含まれます。

 

• ACS URL
• ACS バインディング形式
• SLO URL
• SLO バインディング形式
• エンティティ ID
• 証明書を署名

 

EntityDescriptor