前置き

SSO(シングルサインオン)についてざっくりまとめた記事です。
備忘録として残しています。

SSO(シングルサインオン)ってなに？

シングルサインオン(Single Sign On)は１回の認証で複数のシステムやサービスを利用できるようにする認証の方式

→利用者は、１回認証が通れば、許可されている複数のサービスを利用できる

導入のメリットは？

・パスワード管理の煩雑さ(手間やコスト)を大幅に軽減できる！
・業務効率(利便性)が向上する！
・セキュリティ向上！

導入のデメリットは？

・認証システムへの依存度の高まり
→認証基盤が障害等によりダウンしていた場合、関連サービスへ接続できなくなり業務へ影響を及ぼすおそれがある！

・情報漏洩による不正アクセス時の被害拡大
→アカウント乗っ取りなどにより、権限を突破されてしまうと、関連するサービス等不正利用につながり、影響範囲が拡大するおそれがある！

・シングルサインオンを使用できないケースの存在
→システムに応じて、SSOが利用できないおそれがあり、その場合管理が煩雑になるおそれがある。

SSO実現方式

・フェデレーション方式
・エージェント方式
・リバースプロキシ方式
・代理認証方式

→最も採用されがちなのは フェデレーション方式

代表的プロトコル
・SAML
・OpenID Connect(OIDC)

フェデレーション方式

認証連携の意味
複数のサービスを利用する際に、ひとつのシステムで認証済みであれば、他のシステムを利用した際に、改めて認証要求せずに利用できるよう連携する仕組み

例：一連の流れ
利用者がAサービスにログインしBサービスを利用しようと考える
サービスBはサービスAに「チケット」とよぶ利用者認証情報を要求
利用者がサービスAにログインしてると、AがBに利用者の認証が完了していることを伝える
利用者はサービスAのID/PassでサービスBをログイン操作なしで利用できる

エージェント方式

SSOを利用したい全てのサービスにエージェントを導入し、その認証情報からSSOサーバで認証する方式

例：一連の流れ
SSOの対象となるサーバ(サービス提供側)すべてにエージェントと呼ぶモジュールをインストールする
利用者はSSOサーバから認証済資格情報が含まれたCokkie(クッキー)を受け取る。
SSOの対象サーバに導入されたエージェントが利用者の認証済みCokkieを確認し、サービス利用の許可、拒否を判定する
ただし、Cokkieの仕様上、Cokkieが有効となる同一ドメイン内でしか利用できない！

リバースプロキシ方式

利用者とサービスの間に、書くサービスの代わりとしてリバースプロキシサーバを配置し、そのリバースプロキシサーバで認証する方式

例：一連の流れ
リバースプロキシサーバにエージェント導入することで、SSOを実現する
サービスへ接続は、リバースプロキシサーバ経由でのアクセスとなる、および、エージェントなどのプログラムがリバースプロキシサーバ以外では不要となることが特徴
ただし、リバースプロキシ経由となると、すべての認証がこのサーバを経由して行うことになるため、アクセスが集中し、リバースプロキシサーバに障害が発生するとシステム全体に影響が波及する

代理認証方式

利用者の端末へエージェントを導入し、そのエージェントがユーザに変わって各サービスへのログインを行う。エージェントがユーザのものであることの認証はSSOサーバが行う

例：一連の流れ
利用者の端末に導入したエージェントには、あらかじめユーザID/Passを保持させておき、利用するサービスのログイン画面が表示された時、エージェントがログインのために必要な認証情報を代理で入力する。
エージェント方式では、サービス提供側にエージェントを導入したが、代理認証方式では、サービスの利用者側にエージェントを導入するという違いがポイント！

お疲れ様でした。
以上、ざっくりまとめでした！