前置き
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を保持させておき、利用するサービスのログイン画面が表示された時、エージェントがログインのために必要な認証情報を代理で入力する。
エージェント方式では、サービス提供側にエージェントを導入したが、代理認証方式では、サービスの利用者側にエージェントを導入するという違いがポイント！
お疲れ様でした。
以上、ざっくりまとめでした！