シングルサインオンとは
エクステックでは、社内システムとしてオープンソースのCRMを使用しております。今回、この社内システムに対して「シングルサインオン」を導入した手順についてご紹介したいと思います。
まずは前提知識として、シングルサインオンとはどういうものか、について簡単にご紹介。シングルサインオン（SSO: Single Sign-On）とは、ユーザーが一度の認証で複数のシステムやサービスにアクセスできる仕組みです。
シングルサインオンのメリット、デメリットをまとめてみました。
シングルサインオンのメリット
- システム利用者の利便性が向上する
- 一度のログインで複数のサービスにアクセスが可能になる。
- パスワード忘れやリセットの手間、リスクが減る。
- セキュリティが向上する
- パスワードの使い回しが減る。
- セキュリティポリシーを集中管理しやすくなる。
シングルサインオンのデメリット
- リスクが集中する
- 認証サーバーが落ちると、すべてのサービスにログインできなくなる。
- SSOアカウントが乗っ取られると、全サービスが乗っ取られる。
- 導入・構築コストがかかる
- SSO基盤の設計・構築には一定の知識とコストがかかる。
- 古いシステムや独自認証があるサービスはSSO対応が難しい場合がある。
SSOには、このようにメリットデメリットがあります。デメリットに着目すると、SSOの導入はリスクが多いように見えますが、社内で複数のシステムを使用しており、外部からのアクセスを保護しているような企業にとっては、メリットの方がとても魅力的に映ります。
SSOの主な基盤要素
次に、SSOの構築のための、主要な基盤要素（構成技術）を挙げてみます。
- IdP（Identity Provider）：ユーザーの認証を行い、トークンを発行する中心的な存在
例）Azure AD、Okta、Keycloak 等 - SP（Service Provider）：認証を受けるアプリケーション側の仕組み
- プロトコル（認証・認可方式）：IdPとSP間で通信する共通のプロトコル
例）SAML 2.0、OpenID Connect (OIDC)、OAuth 2.0 等 - ディレクトリサービス（ユーザーストア）
例）Microsoft Active Directory、LDAPサーバー（OpenLDAP など） 等
他にもありますが、主要なものといえばこれぐらいでしょうか。全体の関係、流れはこんな感じです。
SSOの全体構成と流れ
ユーザー
↓
SSOポータル / SP
↓
（未認証時 / 認証済の場合はアプリ利用開始）
↓
IdP（Identity Provider）
↓
ユーザーストア
↓
トークン発行
↓
SPで認証成功
↓
アプリ利用開始
ここまで理解できれば、この構成要素をひとつづつつぶしていく（検討する）作業になります。
エクステックの社内システム
エクステックでは社内販売管理システムとして、オープンソースのCRMをカスタマイズして使用しています。ただ、元となったオープンソースのCRMはSSOに対応していないため、SSO用のカスタマイズが必要になってきます。
販売管理システムの構成はこんな感じです。
Webサーバー：nginx
言語：PHP
目標：Entra ID（Azure AD）との統合で、ユーザーがEntra IDで認証されるようにしたい。
先述のIdP、ディレクトリサービスとして、いくつかの候補があります。
エクステックではすでにMicrosoft365を利用しており、Entra ID（Azure AD）をそのまま利用する事で、「ディレクトリサービス」と「IdP」が両方賄えるため、今回は一番シンプルな構成としてEntra IDによるSSOの実現を目指す事にしました。（オンプレでADを構築していれば、Azure AD Connectというサービスを使用してAzure ADと同期する、もしくはIdPを他社製（Oktaなど）にするといった構成も考えられたかもしれません。）
さて、ここまでがSSO構築の事前知識になります。次回は実際に行った、具体的な構築手順について記載していきたいと思います。
