はじめに
最近は、Prisma AccessやPA-SeriesでGlobalProtectによるリモートアクセスを実現したり、Captive Portal[1]やGlobalProtect PortalでクラアントレスVPNを実現する際に、認証[2]方法にオンプレミスのLDAPやRADIUSを使わず、SAMLを使う、というお客さまが増えてきました。いまのところオンプレミスのサービスを使っているけれど、今後はSAMLでの認証を検討したい、とお考えの皆さんのなかにも、以下の疑問をお持ちの方がいらっしゃるのではないでしょうか。
- そもそもSAMLってどんなもの?
- まだSAMLを使ったことがないけど全体的な認証フローはどうなる?
- Palo Alto Networks 製品でSAML認証を設定するときに注意する点は?
- 一番簡単に設定できるお勧めの方法は?
そこで本稿は、GlobalProtectを例として、SAMLの概要、SAMLの認証フロー、設定時の注意点、便利な設定方法について解説していきます。
目次
Cloud Identity Engineを使ったSAML認証設定の簡素化
SAMLとは
SAMLはSecurity Assertion Markup Languageの略で、「サムル」または「サムエル」と発音します。SAMLは、異なるインターネットドメイン間でユーザーの認証情報をXMLによってやりとりするための標準規格です。この規格は、1度認証を行うだけで、複数のインターネットドメインにまたがってサイトを利用できるようにする「シングルサインオン(SSO)」の実現によく利用されています。
SAMLが解決する従来の認証方式の問題点
従来の認証では、個々のサイトが認証のしくみを持ち、それぞれにユーザー情報を管理していました。これに対し、認証・認可の処理を切り出して外部の認証サイト(SAML IdP、詳しくは後述) に任せると、以下のようなメリットがあります。
- サイトを移動するつどログオンする必要がなくなるのでユーザーエクスペリエンスが向上する
- パスワード更新やリセットなどのユーザー資格情報管理を一元化できる
- パスワード フィッシングの成功率を下げてユーザーを保護しやすくなる
SAMLの動作環境
SAMLはSOAPベース (後述) で情報を交換して認証を行うので、一般的なWebブラウザーがサポートする機能が正しく動作する必要があります。たとえば、リダイレクトやJavaScriptによるHTTP POST、Cookieなどが正しく動作することが求められます。ですので、Lynxのようなテキストベースのブラウザーや、curlコマンドのように機能を限定されたプログラムでは、SAMLをうまく動作させることは難しいでしょう。
SAMLが交換する情報
SOAPとは、XMLベースの構造化された情報を、ネットワーク経由でやりとりするための通信規格です。SAMLの場合、XMLには下記のような情報が含まれています。
| Issuer | 要求メッセージの発行者を指定する。IdP / SP のURI 。 |
| Signature | 要求メッセージの真正性を守り、発行者を認証するXML 署名を指定する。 |
| Subject | 要求されたサブジェクトに関する結果の要素を指定する。 |
| Conditions | リクエスタが結果のアサーションに関する妥当性や使用制限などのSAML の制約条件を指定する。 |
| AutdnStatement | IdPでの認証アクションに関する情報。 |
| AttributeStatement | 認証元でのさまざまな紐付け属性に関する情報。 |
SAML認証で利用される2種類のサービス
SAML認証には以下の2種類のサービス (サイト) を利用します。
- Identity Provider (IdP)
ユーザーの資格情報を認証してセキュリティアサーションを生成するサービス。いわゆるSSO認証サイト。代表的な例はOkta、Google Workspace、HENNGE Oneなど。
- Service Provider (SP)
セキュリティアサーションを受け取ってその有効性を確認し、リソースへのアクセスを提供するサービス。IdPで認証された場合にアクセスを許可する、一連のWebサイトを指す。
SAML IdPとSAML SPは、互いにPKIのしくみで信頼し合うことで、SAML SPが生成した認証要求をSAML IdPが引き受けられるようにしています。
Prisma AccessやPAN-OSとの連携で推奨されるSAML IdPの条件は以下の2点です。
- 複数のSAML SPのURLを登録できること。
- シングルログアウト(SLO)[3]に対応していること。
また、Prisma AccessとPAN-OSの場合、GlobalProtect Portal、GlobalProtect Gateway、Captive Portal、Explicit ProxyがSAML SPとして機能します。
昨今は「ゼロトラスト」という概念が広く知られるようになりましたが、この概念はもともと特定のソリューションではなく、より高次なセキュリティモデル自体を指しています。しかしながら、多要素認証の導入でゼロトラストが達成できる、と理解されているケースもなかにはあるようです。もちろん、認証強化という文脈で多要素認証は有効ですが、それだけでゼロトラストを達成できるわけではありません。ゼロトラストの原則である「何も信頼せず、すべてを疑い、検証する」という文脈では、「どのようなSAML IdPを選ぶか」も同様に重要です。
たとえば、SAML IdPの認証・認可に重大なリスクがあり、どのSAML SPにでもログインできてしまうとすればその影響は甚大でしょう。SAML IdPの提供元が信頼に足るセキュリティ企業なのかどうかは確認が必要です。
GlobalProtectでのSAML認証
ここまでざっとSAML認証の概要をおさらいしてきました。ここからは、GlobalProtectを例にとり、SAML認証のフローを見ていきます。
通常のGlobalProtectの認証は、GlobalProtect Portalに接続して認証した後、GlobalProtect Gatewayへ接続するフローになります。GlobalProtect PortalもGlobalProtect GatewayもHTTPSでサービスを提供していますが、GlobalProtect GatewayはHTTPSでの認証後、IPSec VPN接続の確立時にUDPも利用します。
SAMLを使用する場合、GlobalProtect PortalとGlobalProtect GatewayがSAML SPとして機能します。
GlobalProtectのSAML認証フロー
実際の認証フローは以下のようになります。
- GlobalProtect Portalに接続
- SAML IdPへリダイレクトし認証
- 設定やGlobalProtect Gatewayのリストを取得
- 最寄りのGlobalProtect Gatewayへ接続 (認証オーバーライドが無効な場合)
- SAML IdPへ再度リダイレクトし認証
- GlobalProtect Gatewayへ接続しIPSec VPN接続 (IPSec接続確立できない場合SSLVPN)
ステップ1と4には、クライアント証明書認証を追加することもできます。「GlobalProtect Portalで認証されていればGlobalProtect Gatewayでは認証済み」とみなす認証オーバーライド機能が有効な場合、ステップ5は不要で、SAML IdP側にもGlobalProtect GatewayのURLを登録する必要はありません。
Prisma Accessの場合は、認証オーバーライドがデフォルトで有効に設定されています。これは、Prisma Accessの「GlobalProtect Gatewayがオートスケールで自動的に増加する」 (SAML SPのFQDNが動的に増える) という性質と、「認証オーバーライドの無効化」の相性が悪いことが理由です。
注意点1: SAML認証を行うWebブラウザーの選択
GlobalProtectがSAML認証を行うさいは、そのWebブラウザーとして、OSのデフォルトブラウザーを使うか、APIで呼び出すビルトインブラウザーを使うかを選択できます。
GlobalProtectの挙動は選択したブラウザーによって異なります。デフォルトブラウザーを選んだ場合、既にSAML IdPにログインしていれば認証画面は表示されません。ビルトインブラウザーを選んだ場合、認証画面が表示されます。この挙動の違いは、ビルトインブラウザーを選んだ場合、SAML認証が別のブラウザインスタンスとして行われ、デフォルトブラウザーと認証セッションが共有されないことに由来します。
ビルトインブラウザーで保持されるCookieは明示的に削除するのが困難です。このため、2度目の認証時にSAML IdPに有効なセッションが残っていると、認証画面を経由せず、そのまま接続できてしまいます。認証画面を明示的に再表示させたいのであれば、セッションが切れるまで待つか、クライアントを再起動するか、SAML IdP側でセッションを削除する操作が必要です。
注意点2: iOSのVPN常時接続はSAMLと相性が悪い
iOSのVPN常時接続は、VPN接続が確立するまではネットワークへの接続を許可しません。このため、VPN接続時に外部SAML IdPへのアクセスを必要とする設定はうまく動作しません。
iOSデバイスでは、クライアント証明書認証を使用し、オンデマンド接続で (すべての接続先へ接続しようとしたときに) VPN接続を確立するように設定するのがベストプラクティスです[4][5][6]。
Cloud Identity Engineを使ったSAML認証設定の簡素化
テナントごとに複数のSAML IdPで認証させたい場合、Cloud Identity Engineを使うと便利です。Cloud Identity Engineは、GlobalProtect Portalから見るとSAML IdPとして動作し、他のSAML IdPから見ると複数の認証基盤を接続するSAML SPとして動作します。これをSAML Chainingといいます。これにより、SAML IdP側はCloud Identity EngineをSAML SPとして設定するだけでよく、配下のGlobalProtect Portal (やGlobalProtect Gateway) と認証連携の設定をする必要がありません
この場合、認証フローは下記のようになります。
- GlobalProtect Portalに接続
- CIE: SAML IdPへリダイレクトし認証
- CIE: SAML SPとして認証基盤へリダイレクト
- 認証基盤で認証
- 設定やGlobalProtect Gatewayリストを取得
- 最寄りのGlobalProtect Gatewayへ接続 (認証オーバーライドが無効な場合)
- SAML IdPへ再度リダイレクトし認証
- GlobalProtect Gatewayへ接続しVPN接続
ステップ3で組織に応じ別のSAML IdPへリダイレクトさせることも可能なため、グループ会社で異なるSAML認証基盤を使用している場合に便利です。
おわりに
このブログでは、SAMLの基本的な構成要素と動作のしくみ、GlobalProtectで利用する場合の認証フローや考慮すべき注意点について紹介してきました。背後にある動作のしくみを理解しておくこと、認証がうまくいかない場合でも、問題の所在を把握しやすくなり、トラブルの解決を早めることができます。
よくあるトラブルとその解決方法については別のブログで後日紹介しようと考えていますが、今すでにお持ちの疑問点について相談なさりたい場合は、私たちSEバーチャルチームまでご連絡ください。
参考情報
- インターネット接続時にブラウザーによる認証や規約の画面が表示され、認証や同意を行わないとアクセスできないようにするしくみ。 ↑
- 資格情報を入力して本人確認を行うこと。 ↑
- ユーザーによる1度の操作で、対象のIdPセッションとWebブラウザー上のすべてのユーザーセッションから同時にログアウトできるようにする機能。 ↑
- https://support.apple.com/ja-jp/guide/deployment/depae3d361d0/1/Web/1.0 ↑
- https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PMfYCAW ↑
- https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000wln6CAA&lang=ja ↑