Chapter 07

シングルサインオン

ほげさん
ほげさん
2021.08.14に更新

この章の目的

  • Single Sign-On を実現する方法がいくつかあることを知る
  • OpenID Connect と SAML の違いを把握する

概要

  • 先述の通り、1つのアカウントで複数のクライアントを利用する仕組み
  • メリット
    • ユーザの操作が楽になる
    • 各クライアントが ID/PW の管理と機能の実装をしなくてよくなる
    • 例えば退職するときなど、アカウントを漏れなく削除するのもとても楽

Single Sign-On のパターン

いくつかある

証明書認証による Single Sign-On

  • ID/PW ではなく端末に設定されたクライアント証明書を使う
    • ID/PW より強固だし、入力が楽
  • クライアント全てに証明書を配布しなければならない
    • セキュリティレベルは高いが導入が大変

エージェントによる Single Sign-On

  • クライアント側 Web サーバとかに認証用のエージェントを入れる
    • Web サーバはリクエストが来たときに Single Sign-On 管理サーバに認証をチェックし、認証していなければ認証画面を表示する
  • 全てのアプリやサービスでエージェントを導入する必要がある

リバースプロキシによる Single Sign-On

  • クライアント側 Web サーバとかにリバースプロキシを立てる
    • エージェントと同じ考え方
  • エージェントを入れなくて済むが、リバースプロキシがボトルネックや単一障害点になりやすい

代理認証による Single Sign-On

  • プロキシサーバを用意し、それがアプリに代わり ID/PW を送信して認証を代行する
    • アプリの変更が全く必要ない
  • プロキシサーバは開発・保守が必要、またリバースプロキシと同じ問題がある

SAML による Single Sign-On

  • SAML に対応したサービスしか対象にできないが、徐々に増えている
  • 認証だけでなくユーザの属性情報も共有できる
  • ドメイン間が直接信頼関係を結んでいるので、いちいち ユーザに確認を求めない
    • 会社の Windows PC にログインしたら、共有ディレクトリにアクセスするときやプリンタを使うときにまた認証ってならない
  • Single Sign-On 範囲を増やすには、IdP 管理者 が相手ドメインを SP として IdP に登録する

OpenID Connect による Single Sign-On

  • OpenID Connect に対応したサービスしか対象にできないが、徐々に増えている
  • 認証だけでなくユーザの属性情報も共有できる
  • クライアントが ID トークンを伝達するときに、ユーザに確認を求める
    • Slack に Zoom と連携して良いですかって聞かれたり
  • Single Sign-On 範囲を増やすには、ユーザ が連携先クライアントへの権限委譲に同意する

ケルベロス認証による Single Sign-On

  • Windows の Active Directory に採用されている方式、Linux でも利用できる
    • Windows ログオンや Linux ログインと組み合わせた Single Sign-On が可能になる

この章の参考資料

  1. シングルサインオン(SSO)とは | OSSでのシステム構築・デージーネット
  2. シングルサインオン(SSO)の選び方と仕組みの解説 | アシスト
  3. SAML認証を使用したシングルサインオンを設定する