はじめに
OpenStandiaではOSSに関する各種サービスを提供しており、そのサービスの中に認証・認可やID管理に関するシステム化構想・計画などの上流コンサル、OSSを活用したシステム構築があります。
今日は認証・認可の要件を整理する活動の中でどのようなポイントに注意をしているのか、ユースケースを元にご紹介しようと思います。
本稿でご紹介するのはSingle Sign On（以降はSSOと記載します）をユースケース例とします。SSOとは一度認証行為を行うと、次回からのアクセス時に認証が求められなくなる機能となります（詳細は説明は「「認証システムの仕組み」で記載しています）。SSOは利用者にとっては操作の手数を減らしてサイト利用が可能になるメリットがありますが、認証基盤提供者は利用方法に応じて機能提供するか否かの検討が必要となります。
前提とするシステム構成
今回前提とするシステム構成は以下となります。
システム構成図に登場するシステム・アクタは以下の通りです。
| # | システム・アクタ | 説明 |
|---|---|---|
| 1 | User A, User B | Site A, Bを利用時にSSO Serverで認証を行う利用者 |
| 2 | SSO Server | Site A, Site Bの利用ユーザを認証するための認証システム |
| 3 | Directory System | SSO Serverで認証するユーザ情報を管理するディレクトリシステム |
| 4 | Site A, Site B | 利用ユーザが実際に利用したいサイト（本ケースではSSO Serverで統合認証されている） |
| 5 | Identity Management Server | 利用ユーザ情報を管理し、認証用・各サイトへデータを配布するシステム |
| 6 | HR System | Identity Management Serverで管理する社員情報の源泉システムとなる人事システム |
今回のケースにおけるシステム構成のポイントは以下3点です。
- サービス提供サイトが複数ある（Site A/Site B）
- サービス提供サイトの認証の仕組みを認証システム（SSO Server）が統合管理している
- 認証システム（SSO Server）はユーザを一意に特定するID情報を保持している
※本稿は上記システム構成の青点線内の説明が中心となります。認証システムおよび連携サービスでユーザを一意に特定するID情報を保持するためにID管理システムを導入するケース（システム構成図のIDM System）がありますが、IDM Systemについては別記事で説明予定です。
認証システムの仕組み
今回想定しているシステム構成図において認証・認可は以下のように振る舞います。
まずはSSO Serverが未認証状態、かつSite Aを利用する場合のシーケンスを示します。
ポイントは以下３点になります。
- SSO Serverは「SSO Serverセッションクッキー」が無い場合はログイン画面を通じて認証を行います。
- Site A(認可制御)は「Site A(認可制御)セッションクッキー」が無いと未認証と判断しSSO Serverへリダイレクトします。SSO Serverが認証済みと判断するとSite A(認可制御)は最終的に「Site A(認可制御)セッションクッキー」を発行します。
- Site A(認可制御)が認証状態と判断するとSite A(コンテンツ)はコンテンツを返却する際に「サイトA(コンテンツ)セッションクッキー」を発行します。
次にSSO Serverが認証済状態でSite Bを利用する場合のシーケンスを示します。
基本的なシーケンスは前述のSSO Serverが未認証状態でSite Aを利用する場合と同じです。
異なるのはSite B(認可制御)で未認証と判断した後にSSO Serverへリダイレクトしますが、SSO Serverが認証済状態のためログイン画面の表示を無しにSite B(認可制御)へ認証済であることを通知（=認可コードの送信）し、最終的に「Site B(認可制御)セッションクッキー」を発行します。
問題となる点
今回は以下３点について検討を行います。
| # | 検討ポイント（一部） |
|---|---|
| 1 | 複数ユーザで同一クライアント端末を利用するケース |
| 2 | ある利用者は複数組織に所属しており、認証後に利用サービスで組織毎に利用権限を分ける必要があるケース |
| 3 | 認証システム・サービスで認可情報のステータスがずれるケース |
（※注意）本稿では認証・認可要件の整理する一例としてSSO要件で検討すべき一部項目を記載しております。認証・認可要件は他に検討すべき事項（認証要件・認可要件・利用ユーザ／端末要件・性能要件 等）があります。あくまで一例として閲覧ください。
検討ポイント１に対する考え方
SSO Serverやサイトは発行された各種クッキーを元に認証済みかどうかを判断します。発行されたクッキーは利用ブラウザ（=利用端末）に格納されるため、同じ端末を複数ユーザで共有するケースでは考慮が必要です。
本稿のシーケンスでは「セッションクッキー」という記載をしていますが、このクッキーはブラウザを閉じることでブラウザに格納されたクッキーが破棄されます。また「永続クッキー」と呼ばれるクッキーも存在しますが、利用ユーザが変更される前にログアウト操作を行い発行された各種クッキーを破棄する必要があります。
ログアウトする際にはSSOに関連する各種クッキーの破棄が必要です。具体的には上記シーケンスでSite Bが利用できる状態になった際には以下5種類のクッキーがブラウザに格納された状態となっています。
| # | ブラウザに格納されているクッキー | クッキー／セッション破棄 |
|---|---|---|
| 1 | SSO Serverセッションクッキー | 必須 |
| 2 | Site A(認可制御)セッションクッキー | 必須 |
| 3 | Site A(コンテンツ)セッションクッキー | 任意 |
| 4 | Site B(認可制御)セッションクッキー | 必須 |
| 5 | Site B(コンテンツ)セッションクッキー | 任意 |
つまりSSO Serverおよび認可制御のクッキーは破棄することが必須となります。例えばSSO Serverセッションクッキーのみ破棄し、Site A(認可制御)セッションクッキーを破棄しないと、SSO Serverは未認証状態と認識しているのにSite Aは利用継続できる状態となってしまい不整合状態となってしまいます。
また破棄が任意の項目もアプリケーションの作り方によってはクッキーが上書きされずSSO Serverが認証したユーザと各サイトで利用させるユーザが不整合となるケースがありますので、クッキーを破棄することが望ましいです。
検討ポイント２に対する考え方
企業に勤めていると、ある人が複数の組織（元々A社へ入社したが、B社へ出向する等）に所属するケースがあります。このようなケースにおいてはSSO Serverの先にある利用サービス（=今回のユースケースではSite A / Site Bのこと）の要件によって対応方法が異なります。その一例が利用サービスが所属組織毎に利用権限を分けるケースになります。ある人に1IDしか割り当てないと所属組織毎の利用権限を分けることができないため、複数IDを割り当てる必要があります。このケースのようにある人に対してどのようにIDを割り当てるかはID管理システムの役割となります。
このように認証・認可の要件を整理する上で、ID管理的検討ポイントが必要になるケースが出てきますので認証・認可システム単体で解決できる問題なのか、そうでないのか、という視点で検討する必要があります。
仮にある人に対して所属組織毎に複数IDを付与できたとすると、SSO Serverへ認証後、SSO Serverから利用サービスへの認可情報として各IDが保持する利用権限を連携すれば、所属組織毎に利用権限を分けることができます。
さらに言うと検討ポイント１の問題も気にする必要があります。検討ポイント１では複数ユーザ（=複数利用者）と言うニュアンスで説明しましたが、検討ポイント２では複数ユーザ（=1人の利用者で複数IDを所持）ということになりますので検討ポイント１の事項も検討が必要になります。
検討ポイント３に対する考え方
検討ポイント１の中でユーザ操作によるクッキー／セッション破棄について説明しましたが、一定時間ユーザ操作がない場合に発生するセッションタイムアウトについても検討が必要です。検討ポイント１で述べた通り、認証システムとサービスサイトのクッキー／セッションは同時に破棄することが望ましいのですが、以下の組合せが発生します。
| # | 認証システム | 利用サービス | 検討ポイント |
|---|---|---|---|
| 1 | 有 | 有 | 検討事項は特に無し（認証済み状態） |
| 2 | 有 | 無 | 利用サービスから認証システムへリダイレクトするが、認証済み情報を認証システムから利用サービスへ連携し、利用サービスを認証状態とする（ユーザ操作は発生しない） |
| 3 | 無 | 有 | 利用サービスの認証済み状態を破棄すべき状態。一般的には認可情報の有効期間は認証システム認可情報＞利用サービス認可情報とすべき |
| 4 | 無 | 無 | 検討事項は特に無し（未認証状態） |
問題となるのは#3だけなので、このパターンにならないよう認証システムと利用サービスを接続させる際に検討することが必要となります。
まとめ
認証システムを構築する際に検討すべきSSO機能にフォーカスを当てて検討事項の一部分をご紹介しました。
利用サービスによって認証システムの検討ポイントや構成も変わってくるのでどんなパターンでも利用できる知見というわけではないですが、検討の際にご参考頂ければと思います。