4.9.1. SSO（シングルサインオン）¶
intra-mart Accel Platform における シングルサインオン（以下、SSO と記述します）の仕様について説明します。
4.9.1.1. SSO の概要¶
SSO とは、特定のシステムにログインすることで、連携する複数のシステムを利用可能とするための仕組みです。SSO を実現するためには、連携するシステムがそれぞれ共通の SSO の方式に対応している必要があります。SSO の方式としては、汎用的な方式を利用する場合もあれば、そのシステム固有の方式を利用する場合もあります。汎用的な方式として、以下のような規格があります。
- SAML
- OAuth
- OpenID
SSO を構成する要素としては、「認証を行うシステム」と「サービスを提供するシステム」があります。これらの名称は規格ごとに異なりますが、 intra-mart Accel Platform では以下のように定義します。
SSO認証プロバイダ
認証を行うシステム。SSOサービスプロバイダ
サービスを提供するシステム。認証が必要な場合、SSO認証プロバイダに認証要求を行います。SSO の構成図は以下の通りです。
図 SSOの構成
SSOサービスプロバイダでは、アクセスがあった場合にSSO認証プロバイダと連携して、 自動的にログイン済みの状態にします。これを「SSO自動ログイン処理」と呼びます。認証機能では、SSOサービスプロバイダでSSO自動ログイン処理を実装するためのインタフェースを提供しています。ここでは、認証機能を利用してSSO自動ログイン処理を実装するための説明をします。
4.9.1.2. SSOサービスプロバイダの認証フロー¶
SSO自動ログイン処理は、アクセスコンテキストの生成処理時に実行されます。注意
バーチャルテナントによる複数テナントを利用する場合、SSO自動ログイン処理を行うには SSO 対象のテナントを解決する必要があります。具体的には、リクエスト情報を利用したテナント自動解決機能の実装が必要です。リクエスト情報を利用したテナント自動解決機能の詳細は「intra-mart Accel Platform セットアップガイド」 - 「テナント解決機能」 - 「リクエスト情報を利用したテナント自動解決機能について」 を参照してください。なお、リクエスト情報を利用したテナント自動解決機能の実装は、バーチャルテナントによる複数テナントが利用可能となった intra-mart Accel Platform 2014 Spring(Granada) 以降にて必要になりました。これより前のバージョンで、SSOユーザコードプロバイダを実装し、 2014 Spring(Granada) 以降へアップデートする場合は、リクエスト情報を利用したテナント自動解決機能の実装を行ってください。SSOサービスプロバイダの認証フローの概要は、以下の通りです。
図 SSOサービスプロバイダの認証フロー概要
アクセスコンテキスト生成
アクセスコンテキストを生成します。次の「コンテキストキャッシュチェック」を実行した結果キャッシュが有効である場合、コンテキストキャッシュを利用します。そうでない場合、新しいアクセスコンテキストを生成します。コンテキストキャッシュチェック
HTTPセッションに保存したアクセスコンテキストが有効かどうかを確認します。この処理は、全てのリクエストで実行されます。コンテキストキャッシュはブラウザからの初回アクセス時は存在しません。コンテキストキャッシュが存在し、以下のチェックが全て有効と判定された場合は、有効と判断されます。以下のチェックを順に実行し、いずれかのチェックで無効と判定された場合は以降のチェックは実行されません。
- アクセスコンテキストごとの有効期間の検証
- 「テナントチェック」
- 「ユーザチェック」
テナントチェック
コンテキストキャッシュのテナントID と リクエスト情報を利用したテナント自動解決機能 により、解決されたテナントID が一致しているかどうかを確認します。ユーザチェック
コンテキストキャッシュのユーザコードと次の「ユーザコード取得１」処理により、取得したユーザコードが一致しているかどうかを確認します。ユーザコード取得１
「 SSOユーザコードプロバイダ 」を呼び出して、SSO のためのユーザコードを取得します。SSO自動ログイン
SSO のために自動的にログイン状態とします。この処理は、基本的に初回アクセス時に実行されます。ログイン中でコンテキストキャッシュが有効である間は、実行されません。SSO認証プロバイダに別のユーザでログインした場合は再度実行されます。以下のいずれかの条件を満たす場合に実行されます。
- アクセスコンテキストキャッシュが存在しなかった場合
- 「テナントチェック」「ユーザチェック」のいずれかで、アクセスコンテキストキャッシュ無効と判断された場合
以下の「ユーザコード取得２」でユーザコードが取得できた場合、「ログイン処理」を実行します。ユーザコード取得２
SSO のためのユーザコードを取得します。「ユーザコード取得１」が実行済みの場合、そのユーザコードを利用します。「ユーザコード取得１」が実行されなかった場合、「 SSOユーザコードプロバイダ 」を呼び出して、ユーザコードを取得します。ログイン処理
ユーザコードが取得できた場合に、以下の処理を実行します。
- ユーザの有効チェック
- ログイン
4.9.1.3. SSOユーザコードプロバイダとは¶
SSOユーザコードプロバイダとは、SSO認証プロバイダへのログイン時に保存されたユーザに関する情報から、ユーザコードを解析するためのプラグインです。SSO の方式によって、ユーザに関する情報が保存される場所や形式が異なります。例えば IM-SecureSignOn for Accel Platform では、ユーザに関する情報は Cookie に保存されています。SSOユーザコードプロバイダでは、利用する SSO の方式に従って実装する必要があります。注意
SSOユーザコードプロバイダは、SSO認証プロバイダの情報を取得するためのプラグインです。必要な情報は HTTPリクエストから取得するようにしてください。SSOサービスプロバイダの情報を参照することは想定していません。アクセスコンテキストの生成処理では、テナントの解決が実行されます。SSOユーザコードプロバイダはアクセスコンテキスト生成中に実行されるため、まだ、テナントの情報にはアクセスできません。そのため、データベースやパブリックストレージなどのテナントに紐づく情報は参照できませんので、注意してください。
4.9.1.4. SSOユーザコードプロバイダの実装¶
SSOユーザコードプロバイダは、以下のインタフェースを実装します。jp.co.intra_mart.foundation.security.certification.sso.SSOUserProvider作成した SSOユーザコードプロバイダは、以下の拡張ポイントのプラグインとして登録します。jp.co.intra_mart.foundation.security.certification.sso.user.providersSSOユーザコードプロバイダでは、SSO認証プロバイダから取得したユーザコードを返却してください。取得できない場合は、 null を返却します。作成した SSOユーザコードプロバイダは、プラグインとして複数設定することが可能です。その場合、プラグインの優先度に従って順番に実行され、最初に null でない値が取得できた場合に、解決されたユーザコードが返却されます。全てのSSOユーザコードプロバイダが null を返却した場合、認証処理を行いません。SSOユーザコードプロバイダが存在しないユーザコードを返却した場合、SSO自動ログインできないため、HTTPステータスコード 500 の「エラー」画面が表示されます。SSOユーザコードプロバイダの具体的な実装方法は、「 認証プログラミングガイド 」 - 「 SSO対応 」を参照してください。