シングルサインオン(SSO)

基礎

アクセするサーバごとに異なるユーザ名やパスワードで行われているユーザ認証を、一元的な方法で行なうための仕組み
認証を必要とする複数のシステムが存在する場合に、最初に 1 回認証が成功すれば、以降は利用するシステムが変わっても、利用が許可されているシステムであれば、認証プロセスを経ることなくそのまま利用できるようにする認証システム
導入する場合は、次のように検討・実施するのが望ましい
1. 利用者のユーザ ID とパスワードの各々の統一
2. 複数アプリケーションの認証インタフェースの統合
3. 各アプリケーションに対するアクセス制御の実施

実装方法

プロビジョニング
- 人事・組織に関するイベントにより統合 ID 管理システムが管理するアカウントや各種情報の更新を行い、クライアントシステムへ自動反映を行なうこと
ID 管理) プロビジョニング
- 認証/認可の大前提となる ID の登録
  - 認証の 8 大プロセス
    - 存在確認
    - 身分証明書発行
    - システム用の ID コードと認証手段のデータベース登録
    - ユーザ認証
    - 認証結果表明発行
    - 認証結果表明送付
    - 認証結果表明確認
    - リリース使用の認可
  - 認証/認可を"正しく"行なうために信頼できる ID 情報を登録する必要がある
- プロビジョニングの重要性
  - ID 管理システムが"正しく、信頼できる"プロビジョニングを行なうことにより識別、認証、認可が正しく実行できる
  - ID 管理システム
    - 役割
      - 他のシステムに信頼に足る ID 情報を提供する
    - 統合認証システムに対して、認証用属性の提供(クレデンシャル)
    - アプリに対して、認可用属性の提供
  - 統合認証システム
    - 役割
      - ユーザの正当性を検証す
    - アプリに対して、認証結果の提供
  - アプリ
    - 役割
      - 認可コントロールを行なう

B2E シナリオにおける ID 基盤
- 理想
  - アプリケーション
    - 全てのアプリケーションが統合認証システムへ認証機能を委譲
      - 標準プロトコルへの対応し、パスワードは持たない
    - ID 管理システムから同期される共通属性に基づく認可コントロールだけを行なう
  - 統合認証システム
    - 標準プロトコルのサポート
    - アプリケーションのコンテキストに応じた認証コントロール(MFA など)
  - ID 管理システム
    - 統合された源泉(人事等)から ID を取り込み、精度・鮮度の保証された ID 情報を管理・配布
- 現実
  - アプリケーション
    - 一部のアプリケーションが統合認証システムへ認証機能を委譲
    - ID 管理システムからパスワードを同期
    - ID 管理システムから同期される属性だけでは認可コントロールできないので独自管理
  - 統合認証システム
    - 標準プロトコルのサポート
    - アプリケーションのコンテキストに応じた認証コントロール(MFA など)
  - ID 管理システム
    - 複数の源泉(人事やグループウェア)から ID を取り込み、複雑なルールを実装
    - 精度は微妙

SSO リクエストはサービスプロバイダーの WEB サイトかまたは SSO ベンダーの WEB サイトから開始できる
- SAML はどちらの方法もサポートする
- OpenID はサービスプロバイダーの WEB サイトにアクセスする必要がある

実装方式

Cookie を使う SSO
- エージェント型 SSO
- 最初のログインの際には、Web サーバにインストールされたエージェントが認証サーバにアクセスで認証を行う
- その認証・識別情報を Cookie に含めクライアントに返す
- 別の Web サーバにアクセスがあった場合には、エージェントが認証サーバにアクセスし Cookie 情報をもとに認証を行う
- 制限
  - Cookie 共有可能な範囲内(同一ドメイン内) でしか、SSO システムを構築できない
  - クライアントが Cookie 使用を制限している場合には使用できない
リバースプロキシ型 SSO
- すべての Web サーバへのアクセスをリバースプロキシに集約
- リバースプロキシはアクセスしてきたユーザを認証
- ログインに成功すると、リバースプロキシは Web サーバに代理アクセスし結果をユーザに返す
- 制限
  - ネットワーク構成による制約
SAML(Security Assertion Markup Language)

エージェント方式
- Web アプリケーションサーバに、認証を代行する「エージェント」モジュールを組み込む方式
- リクエストは Web が受け取り、Web サーバ内の「エージェント」がシングルサインオンサーバに問い合わせを実施
- メリット
  - ネットワーク構成を変更せず導入できる
  - 拡張性に優れている
- デメリット
  - 「エージェント」のインストール/アップデート対応等が必要
  - 「エージェント」未対応の可能性
リバースプロキシ方式
- ブラウザと Web アプリケーションサーバ間に「リバースプロキシ」サーバを設置し、「リバースプロキシ」サーバにエージェントソフトを導入することで、シングルサインオンを実現
- 利用者の認証情報としてディジタル証明書を利用することができる
- メリット
  - リバースプロキシを経由することで Web アプリケーションサーバが隠蔽され、安全性・安定性を一層高めることができる
  - 個々の Web アプリケーションサーバへのエージェント導入が不要
  - プラットフォームに依存しない
- デメリット
  - ネットワーク構成の変更が必要
  - リバースプロキシ自体の冗長化
代理認証方式
- 対象の Web アプリケーションやクラウドサービスのログインページに対して、ユーザの代わりに ID/パスワードを送信し、自動的に代理入力することによってログインを完了
- メリット
  - IDaaS と組み合わせることで簡単にシングルサインオン対象にできる
  - Web アプリケーションやクラウドサービスのサービス事業者側で特別な改修がいらない
  - Web アプリケーションではない、サーバ/クライアントアプリケーションにも対応
- デメリット
  - クライアント側にエージェントをインストールする必要がある
  - Web アプリケーションやクラウドサービスによっては代理認証に対応できないこともある
フェデレーション方式
- クラウドサービス間を、パスワードの代わりにチケットと呼ばれる情報を受け渡しすることで、シングルサインオンを実現
- プロトコル
  - SAML
  - OpenID Connect
- メリット
  - 標準プロトコル(SAML 等) に対応するだけで、シングルサインオンが実現
- デメリット
  - 標準プロトコル(SAML 等)への対応が必要
  - 国産クラウドサービスが標準プロトコル(SAML 等)に対応していないことも
透過型方式
- ユーザが Web アプリケーションへアクセスする際の送信を監視し、ユーザ認証が必要なときのみ、認証情報を Web サーバへ送付する仕組み
- メリット
  - クライアントのブラウザやネットワーク経路に影響されない
  - 代理認証方式やエージェント方式が選択できる
  - 既存のネットワークに簡単に挿入できる
- デメリット
  - 透過モードに設定したサーバあるいはエージェントが必要

Life is ...

シングルサインオン(SSO)

基礎

実装方法

実装方式

OSS