Gluegent Blog

Gluegent Blog

SSOの裏側を覗いてみよう

  • Gluegent Gate
SSOの裏側を覗いてみよう
こんにちは、Gluegent Gate 中の人です。

Gluegent Gateに関する情報を発信します。タイトルが気になったらぜひ、ご一読、宜しくお願いします!

さて今回は、Gluegent Gateと Webサービス をSAMLでSSO(シングルサインオン)を実現している環境で、実際にどのような情報のやり取りが行われているのかを、Google Chromeのプラグイン「SAML-tracer」を使って覗いてみたいと思います。 SSOの裏側でどのような情報が取り交わされているかを知ると、新たにWebサービスをSAMLで認証連携設定したい時や、日々の運用におけるトラブルシュートに役立てる事ができるようになります。

はじめに(記事中の表記、留意点)

この記事は弊社製品Gluegent Gateを利用されている企業様のIT部門管理者向けの内容となっています。用語・表現は、正確さよりも解りやすさを重視した内容となっています。
  • 認証基盤をGluegent Gateまたは IdP と表記します。
  • 認証連携の対象サービスを SP と表記します。
  • 本記事ではSPのサンプルとしてSalesforceを使用します。
  • SAMLの認証連携手順を示すものではありません。SAMLの認証連携手順についてはWebマニュアル「SAML(汎用SAML for SP)」を参照してください。

SAML-tracerのインストールと起動

Google Chromeで以下のURLにアクセスしSAML-tracerをインストールしてください。

https://chrome.google.com/webstore/detail/saml-tracer/mpdajninpobndbfcldcmbpnnbhibjmch

プラグインのメニューからSAML-tracerを起動します。
起動すると以下のウィンドウが立ち上がります。

SAMLリクエスト(認証要求)の中身を見てみよう

多くのSPの場合、ログインURLにアクセスするとIdPの認証画面にリダイレクトされますが、このリダイレクトの中でSPはIdPに対してSAMLリクエスト(認証要求)を送信しています。IdPは送られてきたSAMLリクエストの内容を検査し、問題なければ認証画面を表示させます。
では実際に、SAML-tracerが起動した状態でSPへのログインを試みてGluegent Gateの認証画面が表示されるまでの情報を見てみましょう。
下の例では、Gluegent Gateの認証画面が表示されるまでに何回かのリダイレクトを経た様子が記録されています。この内、右に「SAML」のマークがついたエントリはSAMLの情報が含まれている事を示しています。「SAML」のマークがついたエントリを選択して、下の「SAML」タブをクリックするとSAMLリクエスト(認証要求)の内容が確認できます。
続いてSAMLリクエストの内容で重要なパラメータを解説します。
  • 要素saml:Issuer
SP側のエンティティIDに該当します。
この要素の値は Gluegent Gateに登録したSPのエンティティIDと一致している必要があるため、重要な情報になります。
  • 要素samlp:AuthnRequestの属性AssertionConsumerServiceURL
後に続くSAMLレスポンス(認証応答)を受け付けるURLが記載されています。
Gluegent GateではSP登録画面の「Assertion Consumer Service」にこのURLを設定することになります。SAMLレスポンス(認証応答)の送信先になるのでこちらも重要な情報になります。

SAMLレスポンス(認証応答)の中身を見てみよう

IdPの認証画面で認証に成功すると、SP側の画面にリダイレクトされます。(ログイン成功!)
このリダイレクトの中で、IdPはSPに対してSAMLレスポンス(認証応答)を送っています。SPは送られてきたSAMLレスポンスの内容を検査し、問題なければログインとします。
では実際に、SAML-tracerが起動した状態でIdPの認証画面で認証を試みて、SP側の画面が表示されるまでの動作を見てみましょう。SAMLリクエストの時と同様に、右に「SAML」のマークがついたエントリはSAMLの情報が含まれている事を示しています。「SAML」のマークがついたエントリを選択して、下の「SAML」タブをクリックするとSAMLレスポンス(認証応答)の内容を確認することができます。続いてSAMLレスポンスの内容で重要なパラメータを解説します。
  • 要素saml:Issuer
IdP側のエンティティIDに該当します。
今回SPのサンプルとして使用したSalesforceでは、この要素の値と予め設定してあるIdPのエンティティIDが一致している必要があります。※この辺りの動作仕様はSP側のSAML実装によって異なる場合があります。
  • 要素<ds:signature>
SPはSAMLレスポンスに含まれる要素<ds:signature> (XML署名)を検証し、信頼したIdPからの情報であること、そしてそのメッセージが改ざんされていない事を確認します。 (Gluegent GateからダウンロードしてSPに設定したIdP証明書はこのXML署名検証で使用されています)
  • 要素<saml:nameid>
多くのSPでは要素<saml:nameid>の値でログイン先のユーザーを識別します。
前述のXML検証によってSAMLレスポンスの完全性や真正性が確認できたとしても、SPにログイン先のユーザーが存在していなければ結果としてログインすることができません。こちらも重要な情報となります。
以上となります。
今回はSAMLによるSSOの裏側について簡単に解説しました。
冒頭で書いた通り、SSOの裏側でどのような情報が取り交わされているかを知ると、新たにWebサービスをSAMLで認証連携設定したい時や、日々の運用におけるトラブルシュートに役立てる事ができるようになります。
SSOの設定と聞いて「なんだか難しそう」と思っていても、実はSAMLリクエストとSAMLレスポンス、この2ステップで成り立っていて、それぞれのステップで取り交わされている重要な情報もフタを開けてみれば2,3個程度です。
既にGluegent GateでSSOを実現している企業様でも是非、本記事を参考に実際のパラメータを覗いてみてはいかがでしょうか。
これからも、Gluegent Gateを便利に活用して頂ければ幸いです。
(C)