はじめに

前回までのあらすじ

本記事シリーズでは、SE様のようにシングルサインオン(SSO)を導入なさる側の皆様を意識し、
SSOのベース知識を得るための情報源となるべく執筆していきたいと思います。
もし記事をお読みくださったら、ベンダ候補として弊社も加えていただけますと嬉しいです。

第１回
- 本シングルサインオン解説シリーズの位置づけ
- なぜシングルサインオン化すべきか
第２回
- シングルサインオン化のための大まかな要件定義
第３回
- シングルサインオンの仕組みの代表的な例

今回のお題

今回は、認証方法の種類や選択検討について記していきます。

認証方法の種類

認証方法とは

本記事シリーズの第２回にて大まかな要件定義について書いてましたが、この2点目が認証方式でした。
以下は、第２回の図の再掲です。

認証方法とは、「アクセスしてきたユーザが確かにそのユーザであることを認定するための方法」ということです。
認証方法には様々なものがあり、以下に「個別の認証方法」「SSOサーバ間連携による認証」「認証方法の組み合わせ利用」に大別して記していきます。

個別の認証方法

認証方法は、旧来からのID/Passwordによる認証から、最新のFIDO2/WebAuthnまで、様々なものがあります。
以下、代表的な認証方法を記します。

#	認証方法	説明	備考
1-1	ID/Password	ID/Passwordの入力による認証を実施。	-
1-2	ワンタイムパスワード：送付型	別ルートでユーザにワンタイムパスワードを送付し、その入力による認証を実施。通常、ID/Passwordの認証と組み合わせて利用される。	別ルートとしては、email、SMS、LINE等がある。
1-3	ワンタイムパスワード：生成器連動型	ユーザが保持しているワンタイムパスワード生成器と連動し、生成されたワンタイムパスワードの入力により認証を実施。通常、ID/Passwordの認証と組み合わせて利用される。	生成器としては、Google Authenticator等のスマホアプリや専用小型デバイスがある。
1-4	Windows統合認証（DesktopSSO）	Active DirectoryやSambaによって組織内のWindows PCが管理されている場合に、WindowsにログインされていればSSOサーバとしても認証済みとする。	実現事例1 実現事例2
1-5	クライアント証明書認証	ICカード（学生証, マイナンバーカード, etc...）に格納されるクライアント証明書を利用して認証を実施。	実現事例
1-6	FIDO2/WebAuthn認証（HOT!!）	標準仕様が定められた認証方式。認証機器とのインタフェースやSSOサーバとの通信が定められ、公開鍵暗号方式に基づいた堅牢な仕組みとなっている。	認証機器として、USB鍵のような専用機器以外にも、PCやスマホ上の生体認証機能にも既に対応済みのものが多く、パスワードレス社会の促進が期待されている。 FIDOアライアンスによる概要説明 OpenAMによる設定・動作例
1-7	独自認証の開発	独自認証方法を開発して利用する。組織内で既に使われている独自認証実装をSSOサーバに組み込む場合や、既存の部品では実現できない機能を実現したい場合に用いる。	一例としてOpenAMでは、スクリプトやJavaで独自認証を開発できるフレームワークがあり、比較的低コスト＆安全に組み込める。

SSOサーバ間連携による認証

上記の「個別の認証方法」以外の例として、「SSOサーバ間連携による認証」という認証方法があります。

ざっくり説明すると「他のSSOサーバにて認証済みであれば、本SSOサーバとしても認証ＯＫとする」ということです。
ややこしいよう思えるかもしれませんが、アプリケーションとSSOサーバ間で実施するような認証連携接続を、SSOサーバと他のSSOサーバ間でも実施する、というだけのことです。

事例としては、「facebookでログイン」や「Googleでログイン」というようなクラウドサービスのSSOサーバとの連携もありますが、他にも「学認（学術認証フェデレーション）」でよく使われるShibbolethというSSOサーバとの連携という事例も多いです。

認証方法の組み合わせ利用

上記までで見てきた「個別の認証方法」や「SSOサーバ間連携による認証」は、単独で利用されるだけではなく、複数組み合わせて利用されることも多いです。
代表例は二段階認証／二要素認証ですが、他にも様々に組み合わせて利用されます。組み合わせ利用の例は以下のようなものです。

#	組み合わせ利用の例	説明	備考
2-1	二段階認証／二要素認証	１回のログインに対して複数の認証方法を適用することで、不正な認証突破のリスクを下げる。	例えば、「ID/Password認証＋ワンタイムパスワード」や「ID/Password認証＋クライアント証明書認証」といったもの。
2-2	リスクに応じた使い分け	アクセス時のリスク状況に応じて認証方法の使い分けを行う。	例えば、「アクセス時のIPが社外、であったり、前回ログイン時から1か月以上経過していた、といった場合にはワンタイムパスワードの追加認証を行う」といったもの。
2-3	アプリケーションによる使い分け	アプリケーションの特性に応じて認証方法の使い分けを行う。	例えば、「発注アプリは高いセキュリティが求められるのでワンタイムパスワードの追加認証を行う」といったもの。実現事例
2-4	ユーザによる使い分け	ユーザの属性やユーザによる選択に応じて、どの認証方式を行うかの使い分けを行う。	例えば、「FIDO2/WebAuthn対応機器を持っている人はそちらを使うが、持っていない人は二段階認証にする」といったもの。

認証方法の選択検討

ここまでで見てきたように認証方法は多様であり、SSO導入にあたってどの認証方法を実現するかの検討は悩ましいかもしれません。
一例としてご参考になればと思い、以下に認証方法の検討例について記します。

要件検討

要件検討のポイントとして、ざっと以下のようなものがあげられます。
それらを纏めた上で、直近及び将来的にどのような認証方法を実現したいかを検討すると良いかと思います。

#	要件検討のポイント	説明	備考
3-1	現状の整理	SSO化対象のアプリでは、現状どのような認証方式をとっているか。	-
3-2	昨今の状況の調査	昨今のセキュリティ事例や最新の認証方法としてどのようなものがあるか。	現状、パスワードのリスト型攻撃が一般化し、ワンタイムパスワードをフィッシング搾取する標的型攻撃も発生しており、FIDO2／WebAuthnの適用が推奨される状況だと考えられます。
3-3	使い分けの有無	上記「認証方式の組み合わせ利用」で記したような使い分けがあるか否か。	-
3-4	運用	認証方法に付帯して運用面で必要になるような点は何か。	例えば、「ICカードによるクライアント証明書認証を行う場合、ICカード紛失時の無効化・再発行に関する運用を検討する」といったこと。

SSOサーバ製品とのFit＆Gap

上記で要件を検討したら、概ね要件を実現できそうなSSOベンダに問い合わせてFit＆Gap分析をし、最終的にどのような認証方式を実現するのか定めるのが良いと思います。

特に、「独自認証方法の開発」や「使い分け」というような柔軟性の部分は、一般的なSSOサーバ製品のwebサイト等では見えづらい部分です。このため、直接SSOベンダに聞いてみることをお勧めします。

（「弊社以外のSSO製品を選定してしまい、後から要件に合致しない部分が見えてきてしまい困っている…」、という事例を実際に聞いています。。）

おわりに

今回は、以下のことを記しました。
・認証方法の種類や選択検討

SSOサーバによって対応している認証方法に差があったり、「使い分け」や「独自認証方法の開発」といった柔軟性の部分に差があったりしますので、将来の変更の可能性も含めて十分な検討を実施されることをお勧めします。

次回は、認証連携方法に関する種類や選択検討を記していこうかなと思います。
（変更の可能性もあります。）