No334 シングルサインオンとディレクトリサービス

前回の記事の最後で、シングルサインオンとディレクトリサービスという言葉を登場させました。

以前も書いたかな？と思いつつバックナンバーを見直したところ、一度も書いていないことがわかりましたので、今回はこの二つの用語についてお話をします。


1. たくさんのログインはもうたくさん

会社が大きくなってくると、いろんな業務システムを導入して効率化を図ろうとします。
結果、たくさんのバラバラなシステムへのログインが必要になってきます。

例えば、営業さんの一日はこんな感じではないでしょうか。
　・社内のスケジュール管理システムで予定を確認
　・旅費精算システムで昨日の旅費を精算
　・メールを確認
　・社内のサーバで新製品の価格表を確認
　・見積り管理システムで見積りを作成
　・お客様から納期確認の電話があったので、受発注管理システムで確認
　・社内チャットで競合他社の新製品情報を共有

さて、上記の作業をするにはこれだけのログイン作業が必要になります。
　1. スケジュール管理システム
　2. 旅費精算システム
　3. 電子メール
　4. 社内サーバ
　5. 見積り管理システム
　6. 受発注管理システム
　7. 社内チャット

実に7回！これを毎日やるのはかなり面倒な話ですよね。

しかも、ログインIDがシステム毎にバラバラ（社員番号や、メールアドレスや、システム側で付与されたID）だったりします。
パスワードも同様で、最大文字数が違う、ルール（大文字必須、記号必須など）が違う、などの同一パスワードにできない事情も出てきます。

このイラッとする不便さを解消してくれるのがシングルサインオンという仕組みです。


2. シングルサインオン（SSO）

シングルサインオン（Single Sign On、以降SSOと書きます）というのは、その名の通り、一度だけサインオン（ログイン）すれば、後は再ログインを求められないという仕組みのことです。

SSOでは、（上述の例では）最初のスケジュール管理システムでID/パスワードを入力すれば、後は裏側で勝手にシステム側でその情報を連携してくれて、その日はIDもパスワードも入力不要となります。

ただし、SSOのメリットを享受できるのは、社内システムがたくさんあり、ID/パスワードがバラバラとなっているケースです。

中小企業では、システムは発注元との連携用システムくらいで、後はメールと共有サーバでこと足りる、というところも多いでしょう。

そういった場合では、それほどSSOのメリットは活かせないかもしれません。（もちろん、今後を考えてSSOを早期導入するという決断はアリです）

さて、利用者にとってのSSOのメリットは何といってもIDとパスワードを１セット覚えるだけで済む点でしょう。
今までのように、利用するシステム別のID/パスワードの備忘録は要りませんし、パスワードを忘れて事務局にリセットをお願いする必要もなくなります。

また、副次的な効果として、パスワードを堅牢にしやすい（一つだけなら多少複雑なものでも覚えられる）という点もあります。

これを実現する手法の代表的なものに、ディレクトリサービスというものがあります。


3. ディレクトリサービス

ごくシンプルにSSOを実現する方式としてディレクトリサービスを利用する方法というのがあります。

というわけで、ディレクトリサービスというものについてお話をしておきます。

Windowsをお使いの方にはディレクトリはおなじみの用語で、ファイルを保管する場所を意味します。（Macintosh派はフォルダですかね）

ですが、英語の辞書を見ますと、directory は住所録や人名簿となっています。
ファイル保管場所としてのフォルダの意味は元来の意味ではないようです。

ディレクトリサービスの「ディレクトリ」はこの人名簿の意味になります。

つまり、その組織内のサービスを利用できる人を管理するサービスということです。

ディレクトリサービスで管理する情報は自由に決められるのですが、氏名、メールアドレス、ログインID、パスワードなどは定番の情報です。
他にも所属部署、役職、職種、勤務地といった情報を持たせる場合もあります。

これらの情報はディレクトリサービスが管理するデータベースに入っています。

さて、いざログインの場面となると、各システムは利用者にIDとパスワードを入力してもらいます。

ディレクトリサービスがない場合は、各システムが持つIDとパスワードのデータベースを見て、ログイン成攻／失敗の判断をします。
ディレクトリサービスが使える場合は、各システムはIDとパスワードの入力画面すら出さず、ディレクトリサービスに丸投げします。
ディレクトリサービス側は入力画面を表示して、IDとパスワードが正しいかどうかを判断します。
その結果を受けてシステム側は次の画面（エラーの場合はエラー画面）を表示します。

つまり、各システムはIDもパスワードも知らずにログイン処理が行えるわけです。
（利用者のIDはディレクトリサービスが結果通知時に伝えます）

ディレクトリサービスを使うと便利なのは、別システムでのログイン時です。

既にログインに成功していればIDとパスワードの入力画面の代わりに「あなたは○○さんですね？正しければ続行ボタンを押してください」などと表示し、IDもパスワードも入力せずにログインができます。

ログイン依頼をしたシステム側には「ちゃんとログインできたよ」という事実だけが通知されますから、各システムは何も気にする必要がありません。

利用者からすれば、一日に一度だけIDとパスワードを入力すれば良いわけです。


4. ディレクトリサービスの問題

こんなに便利なものなら、どこでもSSOが当然になってもよさそうなものです。

ですが、SSOにはいくつかの課題があります。

まず、最大の問題はディレクトリサービスを実行してくれるサーバが必要な点です。
（厳密にはSSOの方式によりますが、何らかの専用サービスが必要となるのは同様です）

ログインする時にはこのディレクトリサーバを必ず使いますから、これがトラブルで落ちると大変です。全ての業務が進められなくなるからです。
そのため、ディレクトリサーバは二台を同時運用し、どちらかが止まっても大丈夫なようにする（二重化）ことが多いです。

次の問題は、各システム側がSSOに対応している必要がある点です。
導入しようとしているシステムがSSOに対応していなければ、どうにもなりません。

また、先ほどから何度か書いているようにSSOにはいくつかの方式（流派）があり、それぞれの流派に応じた機構が必要になります。ですので、お目当てのSSOの流派に合ったシステムを導入しないとSSOは実現できません。


5. まとめ

シングルサインオン（SSO）というログイン方式があります。
これは、特定のサーバ（ディレクトリサービス）にログインの全てを委ねて、各システムにはログインに必要な情報（IDやパスワード）を持たせないという方式です。

そのディレクトリサービスでは、毎日の最初だけはIDとパスワードを聞いてきますが、二回目以降はログイン済とみなして、入力をせずに済むというものです。

ディレクトリサービスでは、利用者はIDとパスワードを１セットで済ませるというメリットがあります。
管理者にとっても、パスワード忘れ対応が減る上、より強いパスワードにしてもらいやすい（１つだけなら覚えられる）、というメリットがあります。

一方で、SSOを使うためにはディレクトリサービスが必要になる、同じ方式（流派）を採用しないとSSOが実現できないといった課題もあります。

そもそも導入済のシステムが少ないのであれば、コストをかけてまでSSOを実現する価値は小さいのも事実ですが。

今回はシングルサインオンとディレクトリサービスという用語についてお話をしました。

次回もお楽しみに。

（本稿は 2023年11月に作成しました）