突然「シングルサインオン（ＳＳＯ）を検討して」と言われたら－第５回
2021-03-12 - 星野 康
1. はじめに
=== この記事は、以前Qiitaに挙げていたものの再掲です ===
1.1 前回までのあらすじ
本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、 SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。 もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。
- 第１回
- 本シングルサインオン解説シリーズの位置づけ
- なぜシングルサインオン化すべきか
- 第２回
- シングルサインオン化のための大まかな要件定義
- 第３回
- シングルサインオンの仕組みの代表的な例
- 第４回
- 認証方法の種類や選択検討
1.2 今回のお題
今回は、「アプリとの認証連携方法の種類や選択検討」について記していきます。
2. アプリとの認証連携方法の種類
2.1 認証連携方法とは
本記事シリーズの第２回にて大まかな要件定義について書いてましたが、この3点目がアプリとの認証連携方法でした。 以下は、第２回の図の再掲です。
アプリとの認証連携方法とは、「アプリをシングルサインオンの対象とするために行う、SSOサーバとの連携接続の方法」ということです。
以下、代表的な認証連携方法として「標準仕様に基づく認証連携」「エージェントによる認証連携」「代理認証による認証連携」に分けて記していきます。
2.2 標準仕様による認証連携
アプリとSSOサーバ間の認証連携方法には、SAMLやOpenID Connectといった標準仕様が定められたものがあります。
動作としては、本記事シリーズの第３回のフロー図で記したものが代表例です。
標準仕様の認証連携を行うにあたっては、アプリ側が標準仕様に応じた動作をする必要があります。 現在は各種言語のライブラリやApacheモジュールなどが利用できるため、敷居は高くありません。
2.3 エージェントによる認証連携
標準仕様による方法以外にも、SSOサーバベンダから提供されるエージェントをアプリ側に組み込むことで、認証連携を実現できることがあります。 （アプリに成り代わってSSOサーバと連携するので、エージェントによる連携方法と呼ばれます。）
大枠の動作としては、標準仕様に基づく認証連携の場合と変わりありません。
なお、エージェントをアプリサーバに組み込む場合を「エージェント方式」と呼び、別のサーバにエージェントを入れてアプリサーバの前段に置く構成にする場合は「リバースプロキシ方式」と別の呼び方にすることがあります。 （呼び方が違っていても、内容的な違いはそれくらいです。）
2.4 代理認証による認証連携
上記２つ以外にも、代理認証という認証連携を実現できることがあります。 これは、従来のForm認証のように、アプリがID/PasswordのPOSTによる認証の口を持っていた場合に適用できるものです。
動作としては、上記２つとは大きく異なる部分があります。 SSOサーバ側が行う動作イメージとしては、「SSOサーバでのログイン時に入力されたID/Password情報などを使って、アプリの認証の口に自動POSTする」というような形になります。 （ユーザに代わってSSOサーバがID/PasswordなどをアプリにPOSTするので、代理認証と呼ばれます。）
3. 認証連携方法の選択検討
多くのSSOサーバ製品では、上記で見てきたような認証連携方法をアプリ毎に選択できます。 一例としてご参考になればと思い、ここで認証連携方法の選択の検討例について記します。
3.1 アプリ毎の認証連携方法選択の方針付け
アプリをSSOの対象として追加する毎に選択検討するのはコストが掛かるので、各認証連携方法の特徴を踏まえた上で選択検討の方針を立てておき、その方針に従って選択する運用にするのが良いかもしれません。
認証連携方式には、それぞれ以下の特徴があります。
| # | 認証連携方式 | 利点 | 要注意点 |
|---|---|---|---|
| 1 | 標準仕様による認証連携 | ・多くの場合、各言語のライブラリやApacheモジュールなどを適用すれば実現できる。 ・アプリが外部のWebサービスである場合、多くのものは標準仕様に対応済み。 ・標準仕様のため、ベンダロックインを回避できる。 | - |
| 2 | エージェントによる認証連携 | ・SSOサーバのベンダから提供されるエージェントを組み込めばよく、自社アプリへの導入時は楽。 | ・アプリが外部のWebサービスである場合、特定SSOサーバのエージェントの組み込みは、サービス提供者にとってメリット低い。 |
| 3 | 代理認証による認証連携 | ・既存アプリの改修が厳しい場合でも適用できることがある。 | ・既存アプリの認証の口が単純なPOSTでない場合、適用できない可能性もある。 ・アプリにPOSTするためにパスワード情報をメモリなどに保持する、という点についてリスク評価が必要。 |
一昔前とは異なり現在では、標準仕様による認証連携を実現する際のハードルは低くなっていると思います。 これを踏まえ、認証連携方法の選択方針として、一例ではありますが以下のような形が考えられると思います。
- 原則として、SAMLなどの標準仕様による認証連携を適用する。
- どうしても改修が厳しい既存アプリがあった場合は、代理認証による認証連携を適用する。
3.2 SSOサーバ製品とのFit＆Gap
上記のように方針付けを実施したら、概ねその方針を実現できそうなSSOベンダに問い合わせてFit＆Gap分析をし、最終的な認証連携方式の選択方針を定めていくのが良いと思います。
特に、「対応している標準仕様」や「代理認証の仕組みの有無」というような部分は、SSOサーバ製品によって異なります。第４回の内容と合わせて検討し、SSOサーバ製品の選定や要件・方針の確定を行うことをお勧めします。
4. おわりに
今回は、以下のことを記しました。
- アプリとの認証連携方法の種類や選択検討
今回の第５回にて、本記事シリーズは終了にします。 本記事シリーズでは、シングルサインオンの導入意義から始め、大まかな要件をどう纏めるのか、どういう仕組みで動くものか、そして認証方法や認証連携方法として何があってどう選択していくか、ということを記してきました。
皆様がシングルサインオン（SSO）の導入を検討される際、全体像の理解や要件定義の一助として本記事シリーズをお使いいただけましたら幸いでございます。