概要
この記事では、SSOの仕組みをここにまとめる。
細かい設定値などはシステムごとで異なるので、システムごとで連携手順等を確認して実装すること。
SSO（Single-Sign-On）とは？
【定義】
一つの認証情報（ID、PW、ユーザー名、メールアドレス等を組み合わせる）を使用して複数のクラウドサービスへログインできるようになること。
通常のログイン時とシングルサインオンを採用した場合の違いについてイメージ図があったので添付する。
引用元：シングルサインオン
SAML認証とは？
【定義】
SSO認証を行う際に使用するプロトコルのこと
SSO認証する際に使用する情報をXML形式でSPとIdP間で連携してやり取りをすることでSPへアクセスできる。
IdPとSP間でやりとりする情報に関しては主に以下がある。
-
認証
- （定義）ログインしようとしているユーザーが正規のユーザーか否かを確認すること
-
ユーザー識別子：個人を特定する情報をもとに認証を行うために必要になる
- 例：メールアドレス、ユーザーID
-
認証方法：正規のユーザーが正しい認証方法で認証したのか？を確認するために必要になる
- 例：パスワード認証、多要素認証（例：AuthnContext）
-
認証のタイムスタンプ：ユーザーを認証した日時のこと（以下のパターンで必要）
- SP側のセキュリティポリシーで、最後の認証から大幅に時間経過している場合は再認証を求める
- 認証ログを取得することで、第三者が認証してきていないか？の確認ができる（時刻ベースで）
-
認可
- （定義）ログイン使用しているユーザーに正しい権限を付与すること
- 具体的には、**アクセス権限、操作権限（閲覧、編集・変更、削除）**を指す
-
属性
- ユーザーの特定を補助する追加情報のこと（認証する際の情報だけでは個人を特定するのに足りない場合に参照する情報のこと）
- 例：社員番号、電話番号（これ滅多にみない）、所属部署、役職
SSOのメリット
-
ユーザー観点
- ID、PW管理が楽になる
- ID、PWの使いまわしを減らせる
- 複数のクラウドサービスへのログインに手間がかからない（一つのID、PWで良いので）
- 入力間違いによるロックアウトも減るので、業務効率が上がる（実感ないけど...）
- ID、PW管理が楽になる
-
情シス管理者観点
- SSOを実装しない場合に生じる以下の業務工数を削減できる
- 各SaaSサービスでのアカウント発行、削除
- 各ユーザーのログイン情報の管理の徹底・統一化
- セキュリティの向上につながる
- IdPの情報と紐づけるので外部からのアクセスされる可能性を抑えられる （情報漏洩のリスクを減らせる）
- SSOを実装しない場合に生じる以下の業務工数を削減できる
SSOのデメリット
-
ユーザー観点
- 一つのID、PW情報を紛失、失念しないように管理に十分注意を払う必要がある（紙での管理など、紛失リスクが高い管理はNG）
- PW情報を紛失した際に連携しているサービスにすべてアクセスされる危険性がある
-
情シス管理者観点
- ユーザー目線でのPW紛失もそうだが、全社員のPW情報紛失した際の第三者のアクセスの危険性もある
- 使用しているIdPと連携できるサービスではなかった場合の工数増加
- 別の方法でのアクセスを考える必要がある
- IdPのシステムダウンによる業務停止の可能性がある
- ユーザーへのアナウンスや原因調査等が必要になることも？（基本的な調査はIdP提供側で行うが、情報提供を求められた際は工数がかかる）
SSO認証の流れ
SSO認証は主に2種類存在している。それぞれの認証方式の説明は以下の通り。
-
IdP Initiated SSO
- ユーザーを一括管理しているサービスから認証を行う方式
-
SP Initiated SSO
- 紐づけたクラウドサービスから認証を初めて、IdP（AureADやGWS等）にリダイレクトして認証を行う方式
究極いうと両者の違いは、
紐づけたクラウドサービスから認証を始める？ or IdP側から認証を始める？ である。
※認証を始める順番がどちらになるか？なので、そこまで深く考える必要は無いかも？それよりもそれぞれ、どういう認証の順番だったかイメージを付けられるとなお良い。。
一応、以下にイメージ図と文字ベースで簡潔に載せる。
IdP Initiated
IdP Initiatedの認証の流れは以下のイメージ。
※文字ベースでの説明と添付の画像の順番はリンクしていないです....
①IdPのログイン画面を開く
②IdPのログイン情報を入れて（ID、PW等）認証を行う ※IdP側での認証
③②での認証が通ると、連携しているSPが一覧で表示される ※ユーザー or グループごとでアクセスさせるSPを制限できる
④アクセスしたSPを選択する
⑤SPのログイン画面へ遷移する（リダイレクトする）
⑥⑤にてSP側での認証を行ったのちにログインできるようになる ※連携するSPによってはID、PWを入力するケースも？
SP Initiated
SP Initiatedの認証の流れは以下のイメージ。
※これも文字ベースでの説明と添付の画像の順番はリンクしていないです....
①IdPとSSO連携したSPのログイン画面を表示する
②ログイン情報（ID、PW等）を入れる
③IdPの画面へリダイレクトする（ここで認証情報を精査している）※ID、PW情報の入力は求められないです...多分
④IdP側での認証が通ると、SPへログインできる
いかがだったでしょうか？上記の通りどちらから認証を始めるか？の違いしかないので、使用しているIdP画面やSPの画面をイメージしながら連携業務にあたってもらえれば良いかと。。。。
引用元：SSO認証のイメージ
SSOする前に
最後にSSOを実装する際にいきなり実装、導入ではなくその前に考えておくべき事項等について整理していくことにします。不足している情報があるかもしれないですが、ご参考までに。
- 連携したいSPがSSO連携に対応しているのか？
- 連携可能な場合、利用しているIdPとの連携が可能なのか？
- アカウントプロビジョニングは可能か？（例：ログイン時に作成？、連携した際にIdPの情報が一括で反映？）
- SSO連携する際に必要な情報の確認、取得可否の確認（例：認証情報、属性情報）※IdPとSP両方を確認する
- 連携手順の作成
- 検証環境を使用して、手順に問題ないか？の確認
- 実装（本番の設定値を使用する）
- 実装後の動作確認（経過観察）
- 検証環境の削除
参考：HENNGEの例
まとめ
こんな感じで1回目の説明を終えたいと思います。
そういえば、SSOってなんだっけ？SSOするメリットって？目的は？等が分からなくなったときは見返す程度で。。。
次は具体的なSSO認証の種類の説明に入っていきますね。