フェデレーションとは？SSOとの違いや認証の仕組みを初心者向けにわかりやすく解説

はじめに

クラウドサービスや情報セキュリティについて学んでいると、フェデレーションという言葉が登場します。

フェデレーションは、もともと「連合」や「連邦」を意味する言葉です。

IT分野では、独立して管理されている複数の組織やシステムが、一定の信頼関係を結び、認証情報などを連携する仕組みを指します。

例えば、会社のアカウントで次のような外部サービスへログインできる場合があります。

• Microsoft 365
• Google Workspace
• Salesforce
• AWS
• 社内の業務システム
• 外部のクラウドサービス

利用するサービスごとに新しいIDとパスワードを作るのではなく、会社の認証システムで本人確認を行い、その結果を外部サービスが信頼してアクセスを許可します。

ただし、初めてフェデレーションについて学ぶ方にとっては、

• フェデレーションとは何を連携する仕組みなのか
• シングルサインオンと何が違うのか
• ユーザーのパスワードを外部サービスへ渡すのか
• IdPとSPにはどのような役割があるのか
• SAMLとOpenID Connectは何が違うのか
• OAuthはフェデレーション認証なのか
• LDAPやActive Directoryとは何が違うのか
• AWSではどのようにフェデレーションを使うのか
• 一つの認証システムが停止すると、すべてのサービスを利用できなくなるのか

といった点が分かりにくいのではないでしょうか。

フェデレーションを一言で表すと、

「別々に管理されている組織やサービスが信頼関係を結び、一方の認証結果をもう一方が利用する仕組み」

です。

米国国立標準技術研究所のNISTは、フェデレーションを、利用先のサービスが利用者の認証器を直接確認するのではなく、Identity Providerが発行する情報を利用して本人を確認する仕組みとして説明しています。

この記事では、IT分野におけるフェデレーションの意味、IdP・SPの役割、認証の流れ、SSOとの違い、SAML・OpenID Connect・OAuthとの関係について、会話を中心に初心者向けにわかりやすく解説します。

フェデレーションとは？

フェデレーションは別々の組織やサービスが信頼関係を作り、利用者の認証情報を連携する仕組みだよ。

同じユーザー情報を、複数のサービスへコピーするの？

必ずしもコピーするわけではないよ。ある認証システムが本人確認を行い、外部サービスがその認証結果を信頼するんだ。

フェデレーションは、英語でFederationと書きます。

一般的な英語では、次のような意味があります。

• 連合
• 連邦
• 複数の組織による連携
• 独立性を維持した集まり

IT分野でも、この「独立したもの同士が連携する」という考え方が基本です。

特に認証分野では、IDフェデレーションやID連携と呼ばれます。

それぞれの組織やサービスは独立したままですが、あらかじめ信頼関係を設定し、利用者の認証結果や属性情報をやり取りします。

会社の認証システム
       ↓
「この利用者は本人確認済みです」
       ↓
外部クラウドサービス
       ↓
利用を許可

NISTでは、Identity Providerが認証結果や利用者属性をアサーションとして、別に管理されたRelying Partyへ提供する仕組みとしてフェデレーションを説明しています。

フェデレーションを施設の会員証で例えてみよう

複数の施設が共通の会員証を認める場合で考えてみよう。

ある地域に、次の施設があるとします。

• 図書館
• 体育館
• 美術館
• 市民会館

それぞれの施設が独自に本人確認を行い、別々の会員証を発行すると、利用者は何枚もの会員証を管理しなければなりません。

そこで、市役所が市民の本人確認を行い、共通の会員証を発行します。

各施設は、

「市役所が本人確認して発行した会員証なら信用する」

という取り決めを結びます。

利用者が体育館へ行ったとき、体育館は改めて住所や本人確認書類を確認するのではなく、市役所が発行した会員証を確認します。

体育館は自分で本人確認する代わりに、市役所の確認結果を信用するんだね。

そう。それがフェデレーションの基本的な考え方だよ。

ただし、実際のシステムでは紙の会員証ではなく、電子署名されたトークンやアサーションなどを使います。

IDフェデレーションとは？

IDフェデレーションとは、異なる組織やセキュリティ領域の間で、利用者のデジタルIDに関する情報を連携する仕組みです。

例えば、会社Aの従業員が、会社Bの提供するクラウドサービスを利用するとします。

会社B側で従業員ごとのパスワードを管理するのではなく、会社Aの認証システムに本人確認を任せます。

利用者
  ↓
会社Aの認証システムでログイン
  ↓
認証済みであることを示す情報を発行
  ↓
会社Bのクラウドサービスが確認
  ↓
利用者へアクセスを許可

会社Aと会社Bは独立した組織ですが、認証結果を信頼する関係を作っています。

このような関係がIDフェデレーションです。

フェデレーションを構成する主な登場人物

フェデレーションでは、主に次の登場人物が関係します。

• 利用者
• Identity Provider
• Service ProviderまたはRelying Party
• 認証情報を伝えるトークンやアサーション

利用者とは？

利用者は、サービスへログインしようとする人です。

例えば、次のような人が該当します。

• 会社の従業員
• 学校の学生
• クラウドサービスの利用者
• Webサイトの会員
• 取引先の担当者

利用者は、通常、Identity ProviderへID・パスワードや多要素認証などを提示して本人確認を受けます。

Identity Providerとは？

Identity Providerは、利用者を認証し、その結果を外部サービスへ提供するシステムです。

略してIdPと呼ばれます。

日本語では、次のように表現されることがあります。

• IDプロバイダー
• アイデンティティプロバイダー
• 認証情報提供者
• 認証基盤

IdPの主な役割は次のとおりです。

• 利用者のIDを管理する
• パスワードや多要素認証で本人確認する
• 認証結果を示す情報を発行する
• 氏名や所属などの属性情報を提供する
• どのサービスへ情報を渡すか管理する
• アカウント停止やアクセス制御を行う

NISTでは、フェデレーションにおいて利用者の存在や属性の有効性を表明できる主体をIdPとして説明しています。

IdPが、利用者のパスワードを外部サービスへ教えるの？

通常は教えないよ。IdPは「本人確認が成功した」という結果を外部サービスへ伝えるんだ。

Service Providerとは？

Service Providerは、利用者へ実際のサービスを提供するシステムです。

略してSPと呼ばれます。

例えば、次のようなものがあります。

• 勤怠管理システム
• 経費精算サービス
• Web会議サービス
• ファイル共有サービス
• 顧客管理システム
• AWSの管理画面

SPは、IdPから送られた認証情報を確認し、問題がなければ利用者へアクセスを許可します。

SAMLでは、サービスを提供する側をService Providerと呼ぶのが一般的です。OASISのSAML標準は、オンライン上の組織間でセキュリティ情報を交換する仕組みを定めています。

Relying Partyとは？

OpenID ConnectやNISTの文書では、認証結果を信頼してサービスを提供する側をRelying Partyと呼びます。

略してRPです。

Relying Partyには、

「IdPが発行した認証情報に依存して、アクセスを許可する側」

という意味があります。

厳密な用語や役割は規格によって異なりますが、初心者向けには「利用者へサービスを提供し、IdPの認証結果を信頼する側」と考えると分かりやすいでしょう。

フェデレーション認証の基本的な流れ

フェデレーション認証は、一般的に次のような流れで行われます。

1. 利用者がサービスへアクセスする
2. サービスが利用者をIdPへ案内する
3. IdPが利用者を認証する
4. IdPが認証結果を発行する
5. サービスが認証結果を検証する
6. サービスが利用者へアクセスを許可する

1．利用者がサービスへアクセスする

利用者が、外部のクラウドサービスや業務システムを開きます。

この時点では、サービス側は利用者が誰なのか確認できていません。

2．サービスが利用者をIdPへ案内する

サービスは、

「この利用者の本人確認は、登録されたIdPに行ってもらう」

と判断します。

利用者のブラウザを、会社の認証画面などへ移動させます。

この移動をリダイレクトと呼びます。

3．IdPが利用者を認証する

IdPは、次のような方法で利用者を確認します。

• IDとパスワード
• ワンタイムパスワード
• 認証アプリ
• 生体認証
• セキュリティキー
• クライアント証明書
• 端末情報

すでにIdPへログイン済みであれば、パスワードの再入力を求められない場合もあります。

4．IdPが認証結果を発行する

本人確認に成功すると、IdPは認証済みであることを示す情報を発行します。

使用する規格によって、次のような名称が使われます。

• SAMLアサーション
• IDトークン
• セキュリティトークン

この情報には、次の内容が含まれる場合があります。

• 利用者を識別する情報
• 認証を行った時刻
• 認証方法
• 有効期限
• 所属部署
• メールアドレス
• グループ
• 役割

5．サービスが認証結果を検証する

サービス側は、IdPから受け取った情報について確認します。

主な確認内容は次のとおりです。

• 信頼しているIdPが発行したものか
• 電子署名が正しいか
• 内容が改ざんされていないか
• 有効期限内か
• 自分のサービス向けに発行されたものか
• 過去の情報を再利用されていないか

6．サービスがアクセスを許可する

認証情報に問題がなければ、サービスは利用者をログイン済みとして扱います。

さらに、部署や役割などの属性情報を使い、利用できる機能を決めることもあります。

利用者
  ↓ ①サービスへアクセス
SP・RP
  ↓ ②IdPへ移動
IdP
  ↓ ③本人確認
IdP
  ↓ ④認証情報を発行
SP・RP
  ↓ ⑤署名・期限などを確認
サービス利用開始

パスワードは外部サービスへ送られる？

会社のパスワードが、クラウドサービスへ送られるの？

一般的なフェデレーションでは、パスワードそのものを外部サービスへ渡さないよ。

利用者のパスワードはIdPへ入力します。

外部サービスへ渡るのは、原則として次のような情報です。

• 認証に成功したこと
• 利用者を識別する情報
• 利用者の属性
• 認証時刻
• トークンの有効期限

外部サービスは、会社のパスワードを保存したり確認したりする必要がありません。

ただし、システムの構成や古い認証方式によっては異なる仕組みもあるため、実際の仕様を確認する必要があります。

アサーションとは？

アサーションとは、IdPが発行する利用者の認証や属性に関する表明です。

簡単に表すと、

「この利用者について、IdPが確認した内容を記載した電子的な証明書のような情報」

です。

SAMLでは、XML形式のSAMLアサーションが使われます。

アサーションには、次のような情報が含まれる場合があります。

• この利用者は認証済みである
• 利用者の識別子
• 利用者の所属
• 利用者の権限
• 認証した日時
• 有効期限
• 発行したIdP
• 利用を許可する対象サービス

IdPはアサーションへ電子署名を付けます。

SPは、事前に登録した証明書などを使って署名を検証します。

トークンとは？

OpenID ConnectやOAuthでは、認証・認可に関する情報をトークンとしてやり取りします。

代表的なトークンには、次のものがあります。

IDトークンとアクセストークンは同じもの？

役割が違うよ。IDトークンは本人確認、アクセストークンはAPIなどを利用する権限を示すんだ。

フェデレーションとSSOの違い

フェデレーションと混同されやすい言葉が、SSOです。

SSOは、Single Sign-Onの略です。

一度のログインで、複数のシステムやサービスを利用できる仕組みを指します。

フェデレーションは、独立した組織やサービス間で認証情報を信頼し合う仕組みです。

フェデレーションを利用すると、SSOを実現できる場合があります。

フェデレーションとSSOは同じではないの？

同じではないよ。SSOは利用者から見たログイン体験で、フェデレーションはそれを支える信頼と連携の仕組みと考えると分かりやすいよ。

フェデレーションを使わないSSOもある

同じ組織内の複数システムが、一つの認証サーバーやセッションを共有してSSOを実現する場合があります。

この場合、異なる組織間で信頼関係を作るフェデレーションとは限りません。

例えば、同じ会社が管理する三つの社内システムが、同じ認証基盤を直接利用するケースです。

社内認証基盤
├─ 社内システムA
├─ 社内システムB
└─ 社内システムC

一方、会社の認証基盤と、別企業が運営するクラウドサービスを連携する場合は、フェデレーションの特徴が明確になります。

フェデレーションと認証の違い

認証とは、利用者が本人であることを確認する処理です。

例えば、ID・パスワードや多要素認証を使います。

フェデレーションは、あるシステムが行った認証の結果を、別のシステムが信頼して利用する仕組みです。

フェデレーションと認可の違い

認証と混同されやすいものに、認可があります。

• 認証：あなたは誰か
• 認可：あなたは何をしてよいか

例えば、会社のIdPが利用者を認証した後、クラウドサービス側が次のように認可します。

• 一般社員は閲覧のみ
• 管理者は設定変更可能
• 経理部は請求情報を閲覧可能
• 退職予定者はアクセス不可

フェデレーションでは、IdPが所属やグループなどの属性を伝え、サービス側がその情報をもとに権限を決める場合があります。

ただし、本人確認に成功したからといって、すべての機能を利用できるわけではありません。

SAMLとは？

SAMLは、Security Assertion Markup Languageの略です。

一般的には「サムル」と読みます。

異なるシステム間で、認証や属性に関する情報を交換するためのXMLベースの標準規格です。

企業向けのクラウドサービスやWebアプリケーションで、フェデレーションやSSOを実現するために広く使われています。

OASISはSAMLを、オンライン上の組織間でセキュリティ情報を交換するための標準的な枠組みとして定義しています。

SAML認証の基本的な流れ

1. 利用者がSPへアクセスする
2. SPが利用者をIdPへ案内する
3. IdPが利用者を認証する
4. IdPがSAMLアサーションを発行する
5. SPが電子署名などを確認する
6. SPが利用者へアクセスを許可する

利用者
 ↓
SAML対応クラウドサービス（SP）
 ↓
会社の認証システム（IdP）
 ↓
SAMLアサーションを発行
 ↓
クラウドサービスが確認
 ↓
ログイン成功

SAMLの主な特徴

• XML形式を利用する
• IdPとSPの間で認証情報を交換する
• ブラウザを使ったSSOで多く利用される
• 企業向けクラウドサービスで広く採用されている
• アサーションへ電子署名を付けられる
• 属性情報をSPへ渡せる

OpenID Connectとは？

OpenID Connectは、OAuth 2.0の仕組みを利用して、利用者の認証情報を伝えるための規格です。

略してOIDCと呼ばれます。

Webアプリケーション、スマートフォンアプリ、APIを利用するサービスなどで使われます。

OpenID Foundationは、OpenID ConnectをOAuth 2.0上のID層とし、アプリケーションが利用者の本人確認結果や基本的なプロフィール情報を取得できる規格として定義しています。

OpenID Connectの基本的な流れ

1. 利用者がアプリケーションへアクセスする
2. アプリケーションが利用者をOpenID Providerへ案内する
3. OpenID Providerが利用者を認証する
4. 認証コードなどがアプリケーションへ返される
5. アプリケーションがIDトークンを取得する
6. IDトークンを検証してログインさせる

OpenID Connectでは、IdPに相当するものをOpenID Providerと呼び、略してOPと表すことがあります。

サービス側はRelying PartyやClientと呼ばれます。

SAMLとOpenID Connectの違い

SAMLとOpenID Connectは、どちらもフェデレーション認証やSSOに利用されます。

新しいシステムなら、必ずOpenID Connectを使うの？

必ずではないよ。利用するサービスの対応状況、既存環境、セキュリティ要件などで選ぶんだ。

SAMLは現在も多くの企業向けサービスで利用されています。

OpenID Connectは、Webサービスだけでなく、スマートフォンアプリやAPI連携にも利用しやすい特徴があります。

OAuthとOpenID Connectの違い

OAuthは、第三者のアプリケーションへ、利用者のパスワードを渡さずに、特定の操作権限を与えるための認可の仕組みです。

例えば、写真印刷アプリへ、クラウドストレージ内の写真を読み取る権限だけを与える場合があります。

「Googleでログイン」ってよくみるけど、
これはOAuthなの？

ログイン、つまり本人確認が目的なら、一般的にはOpenID Connectが使われるよ。OAuthはAPIへのアクセス権限を与える仕組みなんだ。

OpenID ConnectはOAuth 2.0の仕組みを利用しますが、OAuthそのものは利用者の本人確認を目的とした規格ではありません。

SCIMとは？

SCIMは、System for Cross-domain Identity Managementの略です。

異なるシステム間でユーザーやグループの情報を自動的に連携するための規格です。

例えば、社員が入社したときにクラウドサービスのアカウントを作成し、退職時に自動削除するために使われます。

フェデレーションがあれば、外部サービスのアカウント管理も全部自動になるの？

必ずしもそうではないよ。アカウントの作成や削除には、SCIMなどの別の仕組みを使うことがあるんだ。

フェデレーションとプロキシ型SSOの違い

SSOには、フェデレーション以外の方式もあります。

プロキシ型SSOでは、利用者とWebサービスの間にプロキシを置き、ログイン処理を仲介します。

また、代行入力型SSOでは、ツールが保存したIDとパスワードをログイン画面へ自動入力します。

フェデレーション方式は、外部サービスへパスワードを渡さず、標準規格で認証情報を交換できる点が特徴です。

AWSにおけるフェデレーションとは？

AWSでも、外部の認証情報を使ってAWSへアクセスする仕組みを、フェデレーションと呼びます。

例えば、会社の従業員が、社内のIDを使ってAWSアカウントへアクセスします。

会社の認証基盤
       ↓
SAML・OIDCなど
       ↓
AWS
       ↓
IAMロールを引き受ける
       ↓
一時的な認証情報を取得

AWSは、社内のディレクトリや第三者のIdPなど、外部のIDを使ってAWSリソースへアクセスする利用者をフェデレーテッドアイデンティティとして説明しています。

AWSフェデレーションの特徴

AWSフェデレーションでは、利用者ごとに長期的なIAMユーザーを作成する代わりに、IAMロールと一時的な認証情報を利用できます。

主な流れは次のとおりです。

1. 利用者が会社のIdPで認証する
2. IdPがSAMLアサーションなどを発行する
3. AWSがアサーションを確認する
4. 利用者が許可されたIAMロールを引き受ける
5. AWS STSが一時的な認証情報を発行する
6. 利用者が許可されたAWSリソースへアクセスする

AWSでは、フェデレーションによって、IdPとAWSの間に認証や認可情報を共有する信頼関係を構築します。

一時的な認証情報とは？

一時的な認証情報には、次の情報が含まれます。

• アクセスキーID
• シークレットアクセスキー
• セッショントークン
• 有効期限

有効期限が切れると、その認証情報は利用できなくなります。

長期間有効なアクセスキーを利用者ごとに配布するより、認証情報が漏えいした場合の影響を限定しやすくなります。

AWS IAM Identity Centerとの関係

AWS IAM Identity Centerを使うと、複数のAWSアカウントや対応アプリケーションへの従業員アクセスを一元管理できます。

既存の外部IdPやディレクトリと接続し、ユーザーやグループにAWSアカウントへの権限を割り当てられます。

例えば、次のような割り当てができます。

ソーシャルログインもフェデレーション？

次のようなログイン方法を見たことがある方も多いでしょう。

• Googleでログイン
• Appleでサインイン
• Microsoftアカウントでログイン
• LINEでログイン

これらも、外部のIDプロバイダーが行った認証結果をサービス側が利用するという点では、IDフェデレーションの一種と考えられます。

利用者
 ↓
Webサービス
 ↓
GoogleなどのIdPで認証
 ↓
認証結果をWebサービスへ返す
 ↓
ログイン成功

ただし、企業の従業員向けフェデレーションとは、管理方法や利用目的が異なることがあります。

フェデレーションの信頼関係とは？

フェデレーションでは、IdPとSP・RPの間に信頼関係を設定します。

信頼関係には、次のような情報が関係します。

• IdPの識別情報
• SP・RPの識別情報
• 証明書や公開鍵
• 認証情報の送信先URL
• 利用するプロトコル
• 電子署名の検証方法
• 渡してよい属性
• アクセスを許可する条件
• トークンの有効期限

サービス側は、IdPが発行した情報なら何でも信用するの？

そうではないよ。事前に登録したIdPの署名や、送信先、有効期限などを確認するんだ。

電子署名が必要な理由

攻撃者が、

「私は管理者として認証済みです」

という偽の認証情報を作れたら、サービスへ不正アクセスできてしまいます。

そこで、IdPはアサーションやトークンへ電子署名を付けます。

SP・RPは、事前に信頼した公開鍵を使って署名を検証します。

これによって、次のことを確認できます。

• 信頼しているIdPが発行した
• 内容が途中で改ざんされていない
• 偽物ではない

ただし、秘密鍵が漏えいした場合は、正しい署名に見える偽の情報を作られる可能性があります。

鍵の安全な管理と定期的な更新が重要です。

属性情報とは？

属性情報とは、利用者に関する情報です。

例えば、次のような情報があります。

• 氏名
• メールアドレス
• 社員番号
• 所属部署
• 役職
• グループ
• 雇用区分
• 管理者かどうか

IdPは、必要に応じてこれらの情報をSPへ渡します。

SPは属性情報を使い、利用者のアカウントを識別したり、権限を割り当てたりします。

属性は必要な範囲だけ渡す

サービスを利用するために、すべての個人情報を渡す必要はありません。

例えば、勤怠管理サービスで必要なのが社員番号と氏名だけなら、住所や生年月日まで渡す必要はありません。

必要な情報だけを提供する考え方は、個人情報保護やセキュリティの観点から重要です。

フェデレーションのメリット

利用者が管理するパスワードを減らせる

複数のサービスで同じIdPを利用すれば、サービスごとに新しいパスワードを覚える必要を減らせます。

ログイン操作を簡単にできる

IdPへ一度ログインすると、対応する複数サービスを追加認証なしで利用できる場合があります。

認証を一元管理できる

会社は、IdP側で次の設定をまとめて管理できます。

• パスワードポリシー
• 多要素認証
• アカウント停止
• ログイン制限
• 端末制限
• アクセス元の制限

外部サービスへパスワードを保存させずに済む

外部サービスは、会社の利用者のパスワードを管理する必要がありません。

パスワードが保存される場所を減らせます。

退職者のアクセスを止めやすい

IdP側でアカウントを停止すれば、連携している複数サービスへのログインをまとめて停止できる場合があります。

ただし、サービス側に残っているセッションや個別アカウントの処理も必要になることがあります。

多要素認証を共通化できる

複数のサービスへ、それぞれ異なる多要素認証を設定する代わりに、IdPで強い認証を実施できます。

クラウドサービスの導入を管理しやすい

従業員が利用できるクラウドサービスをIdP側で管理し、アクセスログを集約できる場合があります。

フェデレーションのデメリット・注意点

IdPが停止すると複数サービスへログインできなくなる

認証を一つのIdPへ集約すると、そのIdPの障害が多くのサービスへ影響します。

IdPが停止している間、新しいログインができなくなる可能性があります。

IdPのアカウントが侵害されると影響が広がる

一つのアカウントで複数のサービスへアクセスできるため、IdPのアカウントを乗っ取られると被害が広がる可能性があります。

そのため、次の対策が重要です。

• 多要素認証
• フィッシングに強い認証方式
• 端末の確認
• 不審なログインの検知
• 最小権限
• セッション管理

設定ミスでログインできなくなる

証明書、URL、属性名、時刻などの設定が一致していないと、認証に失敗することがあります。

証明書の期限切れが発生する

SAMLなどでは、署名検証に使う証明書を設定します。

証明書の更新を忘れると、認証できなくなる可能性があります。

すべてのサービスが同じ規格へ対応しているとは限らない

SAMLのみ対応、OpenID Connectのみ対応、フェデレーション非対応など、サービスによって異なります。

属性情報の管理が複雑になる

IdPとSPで、部署名やグループ名などの形式が一致していないと、正しい権限を割り当てられない可能性があります。

ログアウトが完全に連動しない場合がある

一つのサービスからログアウトしても、IdPやほかのサービスのセッションが残っている場合があります。

SSOだけでなく、シングルログアウトの仕様も確認する必要があります。

フェデレーションのセキュリティ対策

IdPへ多要素認証を設定する

フェデレーションの中心となるIdPには、強い認証を設定します。

パスワードだけでなく、認証アプリやセキュリティキーなどを組み合わせます。

最小権限を守る

ログインできることと、管理者権限を持つことは別です。

利用者には業務に必要な最低限の権限だけを与えます。

トークンの有効期限を適切にする

トークンの有効期限が長すぎると、漏えい時の悪用期間も長くなります。

短すぎると、利用者が頻繁に認証を求められます。

リスクと利便性を考えて設定します。

証明書や秘密鍵を安全に管理する

秘密鍵の保管、アクセス制御、更新、失効手順を整備します。

証明書の有効期限も監視します。

ログを記録・監視する

次のようなログを確認します。

• 認証成功・失敗
• 多要素認証の結果
• トークン発行
• 管理者権限の利用
• 不審な国やIPアドレスからのアクセス
• 短時間での大量ログイン
• アカウント設定変更

不要な属性を渡さない

外部サービスへ提供する情報は、利用目的に必要な範囲へ限定します。

緊急時のログイン方法を準備する

IdPが停止した場合に備え、緊急用アカウントや復旧手順を用意する場合があります。

ただし、緊急用アカウントが攻撃者に悪用されないよう、厳格な管理が必要です。

フェデレーションを導入する基本的な流れ

1．利用するサービスを確認する

サービスが対応する方式を確認します。

• SAML
• OpenID Connect
• 独自方式
• SCIM
• シングルログアウト

2．IdPを決める

会社の利用者を認証するIdPを決めます。

既存のディレクトリやクラウド型の認証サービスと連携することもあります。

3．信頼関係を設定する

IdPとSP・RPへ、次のような情報を登録します。

• 識別子
• エンドポイントURL
• 証明書
• リダイレクトURI
• クライアントID
• 署名方式

4．利用者属性を決める

外部サービスへ渡す属性を決めます。

• 利用者ID
• メールアドレス
• 氏名
• 所属
• グループ
• 役割

5．権限の対応関係を決める

IdPのグループと、サービス側の権限を対応させます。

IdPの開発部グループ
       ↓
クラウドサービスの開発者権限

6．テストする

次のようなケースを確認します。

• 正常にログインできる
• 権限が正しく割り当てられる
• 未登録ユーザーが拒否される
• 退職者がログインできない
• 証明書エラーを検知できる
• トークン期限切れ後に拒否される
• IdP停止時の動作

7．監視・更新する

運用開始後も、証明書、鍵、属性、権限、連絡先を定期的に見直します。

ITパスポート・基本情報・応用情報の試験対策

フェデレーションは、認証、クラウド、アクセス管理に関連する用語として押さえておきたい内容です。

特に、SSO、SAML、OAuth、OpenID Connectとの違いを整理しましょう。

試験別に押さえたい内容

試験で覚えたい重要用語

試験問題で注目する表現

類似用語の試験対策比較

よくある誤解

フェデレーションとSSOは同じである

一度のログインで複数サービスを使えるなら、それがフェデレーションだよね？

それはSSOの特徴だよ。フェデレーションは、異なるシステムが認証結果を信頼し合う仕組みなんだ。

フェデレーションによってSSOを実現することはありますが、二つの言葉は同じ意味ではありません。

フェデレーションではパスワードを外部サービスへ渡す

一般的なフェデレーションでは、外部サービスへパスワードを渡しません。

IdPが本人確認を行い、認証結果を示すアサーションやトークンを渡します。

一つのIDとパスワードを複数サービスへ登録する仕組みである

同じIDとパスワードを複数サービスへ登録するだけでは、フェデレーションとはいえません。

フェデレーションでは、サービス側がIdPの認証結果を信頼します。

フェデレーションを導入すれば認証は不要になる

認証が不要になるのではありません。

認証を行う場所がIdPへ集約され、外部サービスはその結果を利用します。

IdPへログインできれば、すべての機能を利用できる

認証に成功しても、利用できる機能はサービス側の認可設定によって決まります。

一般社員と管理者では、同じサービスでも利用できる機能が異なります。

SAMLとフェデレーションは同じである

SAMLは、フェデレーションを実現するために利用できる規格の一つです。

OpenID Connectなど、ほかの方式もあります。

OAuthはログインの規格である

OAuthは、基本的には外部アプリへアクセス権限を与える認可の仕組みです。

利用者の本人確認にはOpenID Connectが利用されます。

フェデレーションがあればID同期は不要である

フェデレーションはログイン時の認証連携を行います。

外部サービス内のユーザー作成・変更・削除には、SCIMなどのID同期が必要になる場合があります。

IdPのアカウントを停止すれば、必ず即座にすべてのアクセスが止まる

新しいログインは止められても、外部サービス側に有効なセッションが残っている場合があります。

セッションの有効期限、強制ログアウト、アカウント削除なども確認する必要があります。

フェデレーションを使えば必ず安全になる

パスワード管理を集約し、多要素認証を共通化できる利点があります。

一方、IdPが攻撃されると複数サービスへ影響が広がる可能性があります。

IdPの保護、最小権限、監視、バックアップが重要です。

フェデレーションは大企業だけが使う

利用するクラウドサービスが増えている組織では、規模にかかわらず利用価値があります。

ただし、小規模組織では導入・運用負担とのバランスを考える必要があります。

フェデレーションは認証情報を一か所に統合することだけを指す

フェデレーションでは、各組織のID管理を完全に一つへ統合する必要はありません。

それぞれが独立した管理を維持しながら、信頼関係によって認証情報を連携する点が特徴です。

まとめ

フェデレーションとは、別々に管理されている組織やサービスが信頼関係を結び、一方の認証結果をもう一方が利用する仕組みです。

ITの認証分野では、IDフェデレーションとも呼ばれます。

フェデレーションでは、Identity Providerが利用者の本人確認を行います。

サービスを提供するSPやRPは、IdPが発行したアサーションやIDトークンを検証し、利用者へアクセスを許可します。

一般的なフェデレーションでは、利用者のパスワードを外部サービスへ渡しません。

外部サービスへ渡すのは、認証に成功したことや、利用者の識別子、所属などの必要な情報です。

フェデレーションと混同されやすい言葉に、SSOがあります。

SSOは、一度のログインで複数サービスを利用できる状態や仕組みです。

フェデレーションは、異なる組織やサービス間で認証結果を連携する仕組みであり、その結果としてSSOを実現できる場合があります。

フェデレーションを実現する代表的な規格として、SAMLとOpenID Connectがあります。

SAMLはXML形式のアサーションを利用し、企業向けのWebサービスで広く使われています。

OpenID ConnectはOAuth 2.0上に構築された認証規格で、Webアプリケーション、スマートフォンアプリ、APIを利用するサービスなどに使われます。

また、AWSでは、社内のIdPなどで認証した利用者がIAMロールを引き受け、一時的な認証情報を使ってAWSリソースへアクセスできます。

最後に要点を整理します。

フェデレーションは、複数のサービスへ同じパスワードを登録する仕組みではないんだね。

そう。IdPが本人確認を行い、外部サービスはその認証結果を信頼するんだ。

外部サービスには、パスワードではなく、認証済みという情報が渡されるんだね。

そう、SAMLならアサーション、OpenID ConnectならIDトークンなどが使われるよ。

SSOは一度のログインで複数サービスを使うこと、フェデレーションは別々のサービスが認証結果を信頼し合うことなんだね。

バッチリ。フェデレーションを使った結果として、SSOを実現できる場合があるんだ。

AWSでも、会社のアカウントで認証して、一時的な権限でAWSへ入れるんだね。

そう。「IdPが本人確認し、サービスがその結果を信じる」と覚えれば、フェデレーションの基本をつかめるよ。

クマノくらげ

X

難しいIT用語やビジネス用語を、できるだけ身近な例えで解説するブログです。 「専門用語を見ると眠くなる人」でも読めるように、画像や会話形式を多めにしています。 AWS12冠達成済み。