突然「シングルサインオン（ＳＳＯ）を検討して」と言われたら－第３回
2021-03-10 - 星野 康
1. はじめに
=== この記事は、以前Qiitaに挙げていたものの再掲です ===
1.1 前回までのあらすじ
本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、 SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。
1.2 今回のお題
今回は、シングルサインオンの仕組みの代表的な例、について書いていきたいと思います。
2. シングルサインオンの仕組みの代表的な例
2.1 なぜ理解しておくべきか
本記事シリーズの第１回から、「シングルサインオン化のためには、SSOサーバを導入し、 各アプリがSSOサーバと認証連携することで実現する」という形の図を出していました。 以下は、第１回の図の再掲です。
ただ、一言で「認証連携」と書いてきましたが、どのような仕組みで実現されているのでしょうか。 この全体的な仕組みを知らないままですと、SSOサーバのベンダとの会話の効率や、 個別技術要素の理解の効率が悪くなってしまったりするかもしれません。
そこで今回は、シングルサインオン実現のための仕組みについて、代表的な例を記していきたいと思います。 （実際はいくつかの仕組みがありますが、１つ代表的な例を知っておくことで、他の仕組みも理解しやすくなると思います。）
2.2 シングルサインオンの仕組みの代表的な例
シングルサインオンの仕組みの代表的な例について、以下の簡易シーケンス図にて記していきます。
[1] ユーザがWebアプリＡを使うため、ブラウザを用いてアプリＡのURLでアクセスします。
[2] アプリＡは、ブラウザから送付されてきたCookieなどからアプリＡとしての認証状態をチェックし、まだ認証済みでなければSSOサーバへリダイレクトします。 （リダイレクトではなく、同等の「自動POSTするコンテンツ」を返すこともあります。）
[3] SSOサーバは、ブラウザから送付されてきたからCookieなどからSSOサーバとしての認証状態をチェックし、まだ認証済みでなければ認証画面を返します。 （ここではID/PWの入力画面の例を出しましたが、ここはワンタイムパスワードなどの多要素認証、FIDO2/WebAuthnによるパスワードレス認証など、様々な方法があります。）
[4] ユーザが認証情報（ID/PWなど）を入力し、その認証情報がSSOサーバにPOSTされます。
[5] SSOサーバは該当ユーザの認証処理を終え、認証済みであるという情報を載せた上でアプリＡへリダイレクトします。 （実際は、リダイレクトではなく、同等の「自動POSTするコンテンツ」を返すことが多いです。）
[6] アプリＡは「SSOサーバがそのユーザで認証済みというならウチとしてもＯＫ」ということで該当ユーザ認証処理を終え、アプリＡの画面を返します。
※※※ 大まかな流れとしてはこのようにシンプルです。これだけ見ると「凄く簡単だから全部1から自前で開発してしまおう！」と考えてしまうかもしれませんが、実際のところは不正を防ぐための様々な対応や細かな動作パターンへの対応といったことが必要であり、セキュリティ面やコスト面で相当大変です。このため、自前で1から開発することはお勧めしません。各種製品やライブラリを利用しましょう。 ※※※
2.3 ざっくり要点を纏めると
上記「シングルサインオンの仕組みの代表的な例」の内容のうち、さらにざっくり要点を纏めるとこんな感じです。
- アプリは、SSOサーバに認証処理を委託する。
- SSOサーバは、既に認証済みであったなら認証処理をすっとばす。（＝シングルサインオン）
- SSOサーバは、認証済み情報を添えてアプリに戻す。
- ユーザからすれば、最初のアプリ利用時に認証入力するだけで、あとは自動で動いてくれる。
3. おわりに
今回は、以下のことを記しました。
- シングルサインオンの仕組みの代表的な例
この代表的な例は、認証連携に関する標準仕様の１つである「SAML 2.0」において、 最もよく使われている基本的なフローです。 この基本的な形をまず理解しておくことで、他の形も理解しやすくなると思います。
次回以降は、認証方法や認証連携方法に関して、種類や選択方針など記していこうかなと思います。 （変更の可能性もあります。）