LoginSignup
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@zumax

シングルサインオンについて整理する

Posted at

背景・目的

シングルサインオンの仕組みを理解したい衝動に駆られたため、整理する。

内容

概要

シングルサインオンとは

Wikipediaのシングルサインオンの定義によると、以下のとおりである。

シングルサインオン（英語：Single Sign-On、略称：SSO）は、一度のユーザ認証処理によって、独立した複数のソフトウェアシステム上のリソースが利用可能になる機能または環境である[1]。シングルサインオンによって、ユーザはシステムごとにユーザIDとパスワードの組を入力する必要がなくなる。

  • 一回の認証処理（システムごとに、ユーザIDとパスワードを改めて入力する必要はない。）
  • 認証後は、独立した複数のシステムのサービスや機能が利用可能

また、アイデンティティ管理を連邦化（federate）することによって、ひとつの組織（管理ドメイン）を超えて他の管理ドメインのWebサーバにも同一のユーザIDとパスワードの組でログインできるようにする処理も、しばしば「シングルサインオン」と呼ばれている。ユーザ認証結果をクレデンシャル（SAMLアサーションやOpenID ConnectのIDトークン）によって伝えて実現させるが、通常、各Webサーバに同一のユーザIDとパスワードの組を入力する必要がある。
必ずしも一度（single）の処理にならない実装についても含めるために「Reduced sign-on」という用語が使われることがある [2]。

  • フェデレートとSSOは異なるようだ。

SSOの実装方式

Wikipediaの実装方式を元に、以下の実装方式について、特徴を整理する。

  • ケルベロス認証
  • リバースプロキシ型
  • エージェント型
  • SAMLに基づくアイデンティティプロバイダ（IdP）
  • OpenIDに基づくアイデンティティプロバイダ（IdP）

ケルベロス認証

ITトレンドの「ケルベロス（Kerberos）認証とシングルサインオンの違いを簡単解説！」を元に、仕組みや特徴を整理する。

  • サーバとクライアント間の身元確認のために使用されるプロトコル

  • クライアントとサーバ間で通信の暗号化が可能

  • 一度認証すると、あらためて認証の必要がない。

  • チケットをサーバに渡すことでアクセス権のあるユーザか否かを判断する。

  • チケットには、以下のものが含まれている。

    • 有効期限
    • クライアントID
    • タイムスタンプ

  • エージェント型（後述）の一種。

リバースプロキシ型

ITトレンドの「シングルサインオンのリバースプロキシ方式とは？詳しく解説！」を元に、仕組みや特徴を整理する。

  • クライアントとWebシステムの間にリバースプロキシサーバ（以降、プロキシと呼ぶ。）を設置し、専用のエージェントソフトを導入する。
  • 認証をプロキシが行うことでログインが可能になり、リバースプロキシを経由することでWebシステムにエージェントを導入する必要はない。
  • 複数のWebシステムがある場合でも、展開しやすいなどのメリットもある。
  • メリット
    • プラットフォームに依存しない。
  • デメリット
    • プロキシがSPOFになる可能性がある。
    • プロキシが対応できるようにNWを構築する必要がある。
    • Webシステムによってはプロキシ認証に対応していないこともある。

エージェント型

ITトレンドの「シングルサインオン（SSO）の1種！エージェント方式とは？」とアシスト社のシングルサインオン（SSO）の選び方と仕組みの解説を元に、仕組みや特徴を整理する。

  • Webサーバや、アプリケーションサーバにエージェントソフトを組み込む。

  • ログインしようとするとSSOサーバから、SSOトークンが発行される。

  • エージェントがSSOトークンを確認し、SSOサーバからユーザ情報が連携される。

  • エージェントからSSOの対象となっているサーバに情報を連携し、SSOサーバからログイン済み状態のレスポンスが利用者に変える。

  • ログイン情報をエージェントが管理することで、アプリケーションの個別管理が不要になる。

  • メリット

    • NW構成の変更は不要
    • 拡張性が高い
    • ユーザの利用記録の特定が容易
    • 既存の環境を変更しなくても良い
    • URLを替えなくても良い

  • デメリット

    • サーバにエージェントのソフトを導入する
    • エージェントのバージョンアップを都度行う
    • サーバのPFによっては、エージェントが対応してないことがある

  • エージェント方式＝ケルベロス認証？

SAMLに基づくアイデンティティプロバイダ（IdP）

ITトレンドの「「SAML」とは？シングルサインオンの実現に必要な仕組みを解説！」とスプラッシュトップ社の「シングルサインオンでよく聞くSAML認証とは？仕組みの概要、導入のメリットを解説」を元に、仕組みや特徴を整理する。

  • SAML=Security Assertion Markup Language

  • SAMLとは、異なるドメイン間においてユーザー認証情報を繋げる、マークアップ言語。

  • OASISにより策定された標準規格

  • 現在のバージョンはSAML2.0

  • アイデンティティ連携プロトコルのスタンダード

  • Cookieに依存しないSSO

  • SP（Service Provider）とIdP（ID Provider）が存在する。

    • IdP:シングルサインオンのサービス提供者。ユーザとSPの橋渡しを行う。
      • ※オンプレミスのWindowsの認証基盤のActive Directoryとも連携可能。
    • SP:ログイン先のクラウドなどのサービス提供者

  • 認証フローには2パターンある（★が挙動の違い。）

    • SP起点
      1. ユーザがSPにアクセスする。
      2. SPがSAML認証要求を作成してユーザにレスポンスを返す。
      3. ユーザはSPから受け取ったSAML認証要求をIdPに送信する。（リダイレクト？）
      4. IdPは認証画面を表示する。
      5. ユーザは、ログインIDとパスワードを入力してIdPとの間で認証処理を行う。
      6. 認証が成功したら、IdPからSAML認証応答が発行される。
      7. ユーザはIdPから受け取ったSAML認証応答をSPに送信する。
      8. SPにSAML認証応答が届くとログインが成功する。
    • IdP起点
      1. ユーザがIdPにアクセスする。
      2. IdPは認証画面を表示する
      3. ユーザは、ログインIDとパスワードを入力してIdPとの間で認証処理を行う。
      4. 認証が成功したら、IdPの画面から対象のSPを表示する。★
      5. IdPからSAML認証応答が発行される。
      6. ユーザはIdPから受け取ったSAML認証応答をSPに送信する。
      7. SPにSAML認証応答が届くとログインが成功する。

  • メリット

    • 利便性向上
    • セキュリティ強化
    • 導入期間が短くコストが低い
    • 多くのクラウドサービスが対応している。

OpenIDに基づくアイデンティティプロバイダ（IdP）

「第一回 認証基盤のこれからを支えるOpenID Connect」の記事を元に、仕組みや特徴を整理する。

  • OAuth 2.0で実装した認可のフローをそのままに追加で認証結果と属性情報を流通させるプロトコル。

  • Webアプリ、ネイティブアプリ間でアイデンティティ情報を流通させる仕組みを、簡単に安全に実現できる。

  • 用語

    • OP：OpenID Provider
      • ユーザの認証を行う機能を有するサーバ。
      • RP（下記参照。）から要求されたアイデンティティ情報を供給することができるRESTエンドポイントを有するサーバ。
    • RP:Relying Party
      • OpenID ProviderにID Tokenとアイデンティティ情報をリクエストするサーバ。
      • SSO対象のアプリケーションを指す。
    • ID Token
      • 認証と認可の情報を含むJWT（JSON Web Token）形式のトークン
    • Access Token
      • UserInfoエンドポイントにアクセスするためのトークン
    • UserInfo
      • Access Tokenを提示するクライアントに対して、アイデンティティ情報を提供する。

  • 実現できること

    • 複数のRPの間でシングルサインオン。これは、SAMLも一緒。
    • RPにおける、IDと認証の実装負荷の軽減。
      • OpenID Providerへクレデンシャルを集約可能。
      • OPからクレデンシャルに紐づくユーザ属性情報の取得をできる。（★ここが他にはない？）
        • RP上のユーザの新規作成を容易に実装できる。
        • コンシューマー向けサービスなどでよく見るな。
      • ユーザの利便性向上
        • ユーザの認証とアイデンティティ情報にアクセスするための認可処理を一体化しているため、ユーザは認証処理と同時にアプリケーションへのアイデンティティ情報の連携の可否を制御できる。

  • アイデンティティ情報の提供

    • OpenID Connectの仕様では2通りの方法がある
      • ID TokenからID情報を取得
        • ID Tokenが含まれるレスポンスから取得する
      • UserInfoエンドポイントで提供する方法

その他

OAuth2.0

一番分かりやすい OAuth の説明記事がとても分かり易かった。後日、別途整理する。

考察

  • SSOには多くの方式がある。
  • クラウドシステム全盛の時代では、SAMLやOpenIDなどのドメイン間のSSO認証の仕組みが必要。
  • 今後、それぞれの認証フローを図で表す予定。

参考

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?