情報処理技術者試験で学ぶ SAML

情報処理技術者試験で学ぶ SAML
Version 0.9.1
Copyright (c) 2020 明日はもっと高いと思う All Rights Reserved.

1
目次
1 SAML とは...............................................................................................................................2
2 ID フェデレーションのコンセプト...................................................................................................3
2.1 【重要】コンセプト ..............................................................................................................3
2.2 《補足》ハッシュ.................................................................................................................5
2.3 《補足》ディジタル署名.......................................................................................................6
2.4 《補足》ディジタル証明書....................................................................................................7
3 【演習 1】 ID フェデレーション .....................................................................................................8
3.1 問題 H31 春 FE 午後........................................................................................................8
3.2 解答・解説 ...................................................................................................................... 13
4 【演習 2】 SAML ..................................................................................................................... 15
4.1 問題 H29 春 SC 午後 I.................................................................................................... 15
4.2 解答・解説 ...................................................................................................................... 19
4.3 《発展》 SAML を深掘る..................................................................................................... 27
全体像.................................................................................................................................. 27
認証シーケンス ...................................................................................................................... 28
信頼関係の構築..................................................................................................................... 28
バインディング........................................................................................................................ 29
アカウント連携........................................................................................................................ 30
SAML Request の生成 ............................................................................................................ 31
SAML Response の生成 .......................................................................................................... 33
SAML Response の検証 .......................................................................................................... 38
セッションの確立..................................................................................................................... 39
まとめ ................................................................................................................................... 40
5 今回参考にした文献 ............................................................................................................... 42
5.1 書籍 .............................................................................................................................. 42
5.2 Web サイト....................................................................................................................... 42

2
1 SAML とは
まず、「SAML（サムル、サムエルなどと呼びます）」とは何者なのか、知っておきましょう。
《ソフトウェア開発技術者1
平成 20 年度秋期 / 平成 18 年度秋期 / 平成 17 年度春期》
問 SAML (Security Assertion Markup Language) の説明はどれか。
ア Web サービスに関する情報を広く公開し、それらが提供する機能などを検索可能にするための仕組み
を定めたもの
イ権限のない利用者による傍受、読取り、改ざんから電子メールを保護して送信するためのプロトコルを
定めたもの
ウディジタル署名に使われる鍵情報を効率よく管理するための Web サービスプロトコルを定めたもの
エ認証情報に加え、属性情報とアクセス制御情報を異なるドメインに伝達するための Web サービスプロト
コルを定めたもの
《情報処理安全確保支援士平成 28 年度春期午前Ⅱ》
問標準化団体 OASIS が、Web サイト間で認証2
、属性及び認可3
の情報を安全に交換するために策定した
フレームワークはどれか。
ア SAML
イ SOAP
ウ XKMS
エ XML Signature4
つまり、
SAML とは、「認証、属性、認可」の情報を、異なるドメインに、安全に連携する規格のこと
→ SAML を使うと、異なるドメイン間で、SSO5
を実現できる
1
現在の、応用情報技術者に相当する。
2
認証（Authentication）とは、対象の正当性を確かめること。
3
認可（Authorization）とは、アクセス制御の（ポリシーを定義する）こと。
4
XML 署名。《発展》 SAML を深掘るで、再度登場します。
5
SSO（シングルサインオン）とは、一度の認証で、複数のサービスを利用できる仕組みのこと。一度認証して得た認証情報を、複数
のサービスに連携することで実現する。
なお、同一ドメイン内限定ではあるが、Cookie を用いる（エージェント型）、または、認証サーバをリバースプロキシに集約させる
（リバースプロキシ型）ことで、認証情報を伝えることもできる。

3
2 ID フェデレーションのコンセプト
2.1 【重要】コンセプト
SAML などの規格では、次のような流れで「認証、属性、認可」の情報を連携します。これを、ID フェデレー
ション（ID 連携）と呼びます。これにより、異なるドメイン間で、SSO を実現することができます。
図 1. ID 連携のシーケンス

4
ここで、Azure AD（Active Directory）など、認証情報を提供するサービスを IdP（アイデンティティプロバイ
ダ）、Office 365 など、ユーザが利用するサービスのことを、SP（サービスプロバイダ）や RP（リライングパーティー）
と呼びます。
以下、SAML を前提に説明します（SAML においては、ユーザが利用するサービスを、SP と呼びます。RP さ
ん、さようなら）。
IdP と SP は、事前に、信頼関係を構築しておく必要があります。具体的には、通信の方式や連携する属性情
報などが記述されたメタデータ、IdP のディジタル証明書などを渡しておきます。
その上で、前頁の図 1、図 2 のフローをながめてみましょう（以下の①～⑤は、図中の番号と対応しています）。
① ユーザが、SP にアクセスする6
② ユーザが認証されていない場合には、IdP へリダイレクトする
③ 認証を行う
ID とパスワードによる認証であれば、IdP が入力画面を応答し、ユーザが ID とパスワードを入力、送信
し、IdP で突合する
④ 認証に成功したならば、IdP でトークンを生成し、SP に送信する（トークンとは、「認証、属性、認可」の
情報に、これら情報のディジタル署名7
を加えた情報のことである）
SP では、ディジタル証明書（公開鍵）を用いて、トークンの内容を検証し、改ざんがないことを確認する
⑤ Web ブラウザと SP で、セッションを確立する
「ハッシュ」、「ディジタル署名」、「ディジタル証明書」がよくわからないよって方は、ここから 3 ページにわたっ
て解説しているので、復習しておいてください。
6
SAML には、はじめに IdP にアクセスするフローもある。詳しくは、4 章の《発展》にて解説している。
7
「認証、属性、認可」の情報のハッシュ値を、秘密鍵を使って暗号化（イメージ）したデータ。次ページからの
《補足》を参照のこと。

5
2.2 《補足》ハッシュ
《基本情報技術者試験 H25 秋問 38, 応用情報技術者試験 H24 春問 38》
問ディジタル署名などに用いるハッシュ関数の特徴はどれか。
ア. 同じメッセージダイジェストを出力する異なる二つのメッセージは容易に求められる。
イ. メッセージが異なっていても、メッセージダイジェストは全て同じである。
ウ. メッセージダイジェストからメッセージを復元することは困難である。
エ. メッセージダイジェストの長さはメッセージの長さによって異なる。
ア → ぶつかるので ×、イ → 同じハッシュ値にならないので ×、ウ → もどせないので ○、エ → 固
定長なので × と、瞬殺できると最高です。
（詳細）下の絵の、左側を見てください。メッセージ（入力）があって、その次に、ハッシュと書いてある楕円（ここでは、ハッシュ
関数による処理という意味だと思ってください）があって、最後にハッシュ値（出力）があります。
この「ハッシュ関数」とは、あるメッセージから、メッセージごとの固定長のデータを出力するための関数です。ハッシュ関数によ
って得られた値を、「ハッシュ値」と呼びます。ハッシュ値は、「メッセージダイジェスト」と呼ぶこともあります。
ハッシュ関数については、ざっくり、上の絵の右半分のイメージをもっておけばよいです。
・戻せない（ハッシュ値から、元のメッセージが見つからない）
・ぶつからない（同じハッシュ値となる、異なるメッセージが見つからない）
・同じハッシュ値（元のメッセージが同じであれば、ハッシュ値も同じ）
・固定長（ハッシュ値は、ハッシュ関数によって固定長である）

6
2.3 《補足》ディジタル署名
《基本情報技術者試験 H25 春問 37》
問手順に示す処理を実施することによって、メッセージの改ざんの検知の他に、受信者 B ができる
ことはどれか。
[手順]
送信者 A の処理
(1) メッセージから、ハッシュ関数を使ってダイジェストを生成する。
(2) 秘密に保持している自分の署名生成鍵を用いて、(1) で生成したダイジェストからメッセージの署
名を生成する。
(3) メッセージと、(2) で生成した署名を受信者 B に送信する。
受信者 B の処理
(4) 受信したメッセージから、ハッシュ関数を使ってダイジェストを生成する。
(5) (4) で生成したダイジェスト及び送信者 A の署名検証鍵を用いて、受信した署名を検証する。
ア. メッセージが送信者 A からのものであることの確認
イ. メッセージの改ざん部位の特定
ウ. メッセージの盗聴の検知
エ. メッセージの漏えいの防止
「ディジタル署名（デジタル署名、電子署名）」とは、電子的な署名のことです。送信者が、ディジタル署名を
作成し、それをメッセージに付加して送ることで、受信者は、「メッセージの改ざんの検知（完全性の確認）」
および「送信者の確認」をすることができます。
ディジタル署名は、上記の問題にある通り、次の手順で行います。

7
2.4 《補足》ディジタル証明書
ディジタル証明書（デジタル証明書、電子証明書）とは、公開鍵と、その所有者の情報などを、結びつけた
データのことです。
次の図を見てください。仮に、鍵ペアが P 社のものだったとしましょう。P 社のディジタル証明書とは、「P 社
の公開鍵」に、お役所である「認証局（CA）」が、「この公開鍵は、確かに P 社のものです」と、ハンコを押して
くれた（ディジタル署名をしてくれた）データのことです。
少々雑ですが、慣れるまでは、“証明書”＝“公開鍵”＋“認証局の署名” とイメージしておけばよいと思いま
す。

8
3 【演習 1】 ID フェデレーション
前章のコンセプトが理解できたかどうか、まずは、「基本情報技術者平成 31 年度（2019 年度）春期午後問
1」を解いてみましょう。『図 2. B 社クラウドサービスが利用可能になるまでの処理の流れ』がすっと入ってくれば、
OK です。
なお、『』は、問題文中からの引用を表します。
3.1 問題 H31 春 FE 午後
クラウドサービスの利用者認証に関する次の記述を読んで、設問 1、2 に答えよ。
A 社では現在、Web ベースの業務システムが複数稼働しており、それぞれが稼働するサーバ (以下、業務シス
テムサーバという) を社内 LAN に設置している。A 社のネットワーク構成を、図 1 に示す。
図 1. A 社のネットワーク構成
利用者は、業務システムを、社内 LAN に設置されたクライアント PC の Web ブラウザから利用する。社外から社
内 LAN へのリモートアクセスは禁止されている。業務システムの利用者認証は、A 社認証サーバでの利用者 ID
とパスワード (以下、この二つを併せて利用者認証情報という) の検証によって行っており、シングルサインオンを
実現している。
社内 LAN からインターネットを介した社外への通信は、クライアント PC からプロキシサーバを経由した、HTTP
over TLS (以下、HTTPS という) による通信だけが、ファイアウォールによって許可されている。社外からインター
ネットを介した社内 LAN への通信は、全てファイアウォールによって禁止されている。ファイアウォールの設定
は、A 社のセキュリティポリシに基づき変更しないものとする。

9
[クラウドサービスの利用者認証]
このたび A 社は、業務システムの一つである販売管理システムを、B 社がインターネットを介して提供する販売
管理サービス (以下、B 社クラウドサービスという) に移行することにした。利用者認証に関しては、A 社認証サー
バと B 社クラウドサービスを連携し、次の (1)～(3) を実現することにした。
(1) B 社クラウドサービスをシングルサインオンの対象とする。
(2) A 社の利用者認証は、B 社クラウドサービスについても、A 社認証サーバで行う。
(3) 利用者が本人であることを確認するために A 社認証サーバで用いる a は、B 社クラウドサービス
には送信しない。
(1)～(3) を実現するために、A 社は、利用者認証を仲介する ID プロバイダ (以下、IdP という) を社内 LAN に
設置することにした。IdP は、認証結果、認証有効期限及び利用者 ID (以下、これら三つを併せて認証済情報と
いう) にディジタル署名を付加してから、Web ブラウザを介して、B 社クラウドサービスに送信する。B 社クラウドサ
ービスは、付加されているディジタル署名を使って、受信した認証済情報に b がないことを検証する。
このために、IdP の c を B 社クラウドサービスに登録しておく。
Web ブラウザと B 社クラウドサービスとの間、及び Web ブラウザと IdP との間の通信には、HTTPS を用いる。
IdP と A 社認証サーバとの間の通信には LDAP を用いる。

10
[B 社クラウドサービスが利用可能になるまでの処理の手順]
A 社の利用者が、利用者認証されていない状態で、B 社クラウドサービスを利用しようとした場合に、利用可能
になるまでの処理の手順を次の ①～⑩ に示す。
① 利用者は、Web ブラウザから B 社クラウドサービスにアクセスの要求を送信する。
② B 社クラウドサービスは、アクセスの要求を IdP に転送する指示 (以下、転送指示という) を、Web ブラウザ
に返信する。
③ Web ブラウザは、② の転送指示に従い、IdP にアクセスの要求を送信する。
④ IdP は、利用者認証情報の入力画面を Web ブラウザに返信する。
⑤ 利用者は、Web ブラウザで利用者認証情報を入力する。Web ブラウザは、入力された利用者認証情報を
IdP に送信する。
⑥ IdP は、利用者認証情報を A 社認証サーバに送信する。
⑦ A 社認証サーバは、利用者認証情報を検証し、認証結果を IdP に返信する。
⑧ IdP は、認証結果が成功の場合に、認証済情報を発行し、当該情報の B 社クラウドサービスへの転送指示
とともに、Web ブラウザに返信する。
⑨ Web ブラウザは、⑧ の転送指示に従い、認証済情報を B 社クラウドサービスに送信する。
⑩ B 社クラウドサービスは、認証済情報に基づいて、B 社クラウドサービスの利用を許可し、操作画面を Web
ブラウザに返信する。
B 社クラウドサービスが利用可能になるまでの処理の流れを、図 2 に示す。図 2 中の ①～⑩ は、処理の手順の
①～⑩ と対応している。
図 2. B 社クラウドサービスが利用可能になるまでの処理の流れ

11
設問 1. 本文中のに入れる適切な答えを、解答群の中から選べ。
a ～ c に関する解答群
ア. PKI イ. 改ざんウ. 公開鍵
エ. サービス妨害オ. 生体情報カ. パスワード
キ. 秘密鍵ク. 利用者 ID ケ. 漏洩
設問 2. 次の記述中のに入れる適切な答えを、解答群の中から選べ。
B 社クラウドサービスでは、接続元の IP アドレスを A 社のものに限定する機能は提供されていない。しかし、他
の業務システムと同様に、B 社クラウドサービスを、社内 LAN からの利用に限定できる。
この理由は、 d ことが必要であるが、IdP を社内 LAN に設置するので、社外から B 社クラウドサービス
を利用しようとしても、図 2 中の e の送信で失敗し、利用者認証されないからである。
d に関する解答群
ア B 社クラウドサービスが、IdP と直接通信する
イ B 社クラウドサービスが、利用者認証情報を検証し、Web ブラウザに返信する
ウ IdP が、利用者に代わって、利用者認証情報を B 社クラウドサービスに送信する
エ Web ブラウザが、IdP と通信する
e に関する解答群
ア. ① イ. ③ ウ. ⑤ エ. ⑥ オ. ⑨

12
《補足》 LDAP
LDAP サーバとは、ざっくり、認証サーバのことです。
LDAP サーバでは、ユーザの情報（社員番号、氏名、所属部署、アクセス権など）を、階層構造で管理しま
す。
LDAP とは、クライアントと LDAP サーバとのやりとりを規定したプロトコルです。クライアントは、LDAP サーバ
に対しクエリを投げ（データベースに、SQL を投げるイメージです）、ユーザの情報を、検索したり、参照した
りすることができます（一応、追加・削除、変更することもできます）。
LDAP サーバが提供するようなサービスを、一般的には、「ディレクトリサービス」と呼びます。Microsoft 社
の Active Directory も、ディレクトリサービスの一つです。

13
3.2 解答・解説
TODO: 解答、解説を書く
これまでのことがわかっていれば、全問正答できるはず。

14
出題趣旨
近年様々なクラウドサービスが普及してきており、クラウドサービスを利用する場合、利用者側で利用者認証
について検討する必要があり、この点を理解しておくことは重要である。
本問は、クラウドサービスでの利用者認証の標準的な規格である SAML （Security Assertion Markup
Language）を参考にした、利用者認証に関する情報の受渡しを主題としている。
本問では、ディジタル署名を使った改ざん防止の方法や、クラウドサービス側で制御しなくても接続元のネッ
トワークを限定できる場合があることについての理解を評価する。
問番号正解備考
問 1 設問 1 a カ
b イ
c ウ
設問 2 d エ
e イ
採点講評
問 1 では、クラウドサービスでの利用者認証の標準的な規格である SAML （Security Assertion Markup
Language）を参考にした、利用者認証に関する情報の受渡しについて出題した。
設問 1 では、a の正答率は平均的で、おおむね理解されていた。b の正答率は高く、よく理解されていた。c
の正答率は平均的で、おおむね理解されていたが、キと誤って解答した受験者が見受けられた。ディジタル署
名は、公開鍵暗号方式を利用しているが、受信側と送信側で利用する鍵について、よく理解しておいてほし
い。
設問 2 では、d の正答率は低く、あまり理解されていなかった。イやウと誤って解答した受験者が見受けられ
た。図 2 に示す通り、利用者認証を行うために、Web ブラウザは、ID プロバイダ（IdP）にアクセス要求を送信す
る。また、B 社クラウドサービスでは、利用者 ID とパスワードを併せた利用者認証情報は取得しないことを理解
していれば、正答できた。e の正答率は平均的で、おおむね理解されていたが、エと誤って解答した受験者が
見受けられた。[B 社クラウドサービスが利用可能になるまでの処理の手順] において、Web ブラウザが社外に
あると、社内 LAN に設置した IdP へのアクセス要求の送信（③）がファイアウォールの設定によって失敗し、以
降の処理ができないことを理解できれば、正答できた。
近年クラウドサービス側での対応が拡大している利用者認証の連携方式と、その仕組みを利用したアクセス
制御ができることについて、理解しておいてほしい。

15
4 【演習 2】 SAML
今度は、SAML に特化した問題「情報処理安全確保支援士平成 29 年度（2018 年度）春期午後 I 問 3」
を解いてみましょう。コンセプトがわかっていれば、かなり楽に戦えるはずです。
なお、『』は、問題文中からの引用を表します。
4.1 問題 H29 春 SC 午後 I
クラウドサービスの認証連携に関する次の記述を読んで、設問 1～3 に答えよ。
F 社は、従業員数 300 名のソフトウェア開発会社である。F 社では、社外のクラウドサービスを試行的に導入し
始めており、交通費精算サービス、グループウェアサービス、オンラインストレージサービスの三つを現在利用し
ている。これらのクラウドサービスには、各クラウドサービスの利用者 ID とパスワードを用いてログインする。これら
のクラウドサービスは、社内からの利用に限定するという社内ルールを定めている。
従業員が利用する端末は、社内ネットワークに設置されており、ウイルス対策ソフトが導入され、最新のウイルス
定義ファイルが毎日適用されている。社外から社内ネットワークへの通信はファイアウォールによって禁止されて
いる。端末からクラウドサービスを利用する際には、プロキシサーバを経由する必要がある。
[クラウドサービスへの不正アクセス]
ある日、交通費精算サービスで従業員の振込先口座が勝手に変更されたとの相談が、経理部から情報システ
ム部の C 主任にあった。R さんの振込先口座が F 社指定の銀行以外の口座に変更されていたので、R さんに確
認したところ、本人による変更ではないことが分かったとのことであった。
C 主任は、社外の攻撃者による不正アクセスの可能性を考え、交通費精算サービスに記録されているログイン
記録を調査した。F 社で利用しているクラウドサービスではログイン記録として、アクセス日時、利用者 ID、接続元
IP アドレス、接続先 URL が記録されている。調査の結果、R さんの利用者 ID によるログイン記録には接続元 IP
アドレスとして、F 社の IP アドレス以外に、海外の IP アドレスが一つあった。R さんに話を聞いたところ、このログ
インには心当たりがないということであった。R さんに更に詳しく話を聞いたところ、4 月 9 日に交通費精算サービ
スから登録情報の確認を促す電子メール（以下、メールという）が 1 通、R さんの私用メールアドレスに届いてお
り、R さんが 4 月 10 日にそのメールを自宅で読み、記載内容に従って自宅からログイン操作を行ったことが分か
った。そのメールを R さんから転送してもらい、C 主任がメールに記載されていた URL を確認したところ、交通費
精算サービスを模したフィッシングサイトであった。C 主任はこのフィッシングサイトから利用者 ID とパスワードが
盗まれた可能性が高いと判断した。そこで、R さんがパスワードを使い回している可能性も考慮して、他のクラウド
サービスに対する R さんのログイン記録も調査した。その結果、他のクラウドサービスに対する R さんの利用者 ID
を用いたログインは、F 社からのものだけであることを確認した。
今回は金銭的な損害に至らなかったが、情報システム部の B 部長は早急な対策が必要と考え、C 主任に暫定
対策の実施と根本的な対策の検討を指示した。

16
[暫定対策の実施と根本的な対策の検討]
C 主任はまず、暫定対策として三つの対策を行うことにした。第一に、フィッシングメールに注意するよう従業員
に周知した。第二に、F 社で利用している各クラウドサービスに対するログイン記録を C 主任が調査して、① F 社
以外からのログインがあった利用者 ID を特定し、その利用者 ID を利用する者にはパスワードを変更させることに
した。第三に、F 社以外からのログインを検知できるよう、ログイン記録の監視を行うことにした。C 主任は暫定対
策が完了したことを確認し、根本的な対策の検討を開始した。
C 主任は、今回の不正アクセスの原因の一つが、F 社の IP アドレス以外からクラウドサービスへのログインが可
能になっていたことにあると考え、F 社の IP アドレス以外からのログインを制限することが可能か調査した。F 社で
利用しているクラウドサービスのうち、グループウェアサービスだけは、接続元 IP アドレスを制限する機能を備え
ていたので、その機能を有効化し、社内からだけログインできるように設定した。しかし、残りのクラウドサービスは
接続元 IP アドレスの制限機能を備えていなかった。
C 主任は、接続元を制限する他の方法を検討した。その結果、クラウドサービスへログインする際、F 社に既に
設置してある LDAP サーバでの認証を必要とすることにすれば、接続元を制限できるようになると考えた。そこ
で、F 社で利用しているクラウドサービスを調べたところ、全て SAML（Security Assertion Markup Language）を用
いた認証連携に対応していることが分かった。C 主任は、クラウドサービスと LDAP サーバとの間で、SAML を用
いた認証連携による接続元の制限を検討することにした。
[SAML を用いた認証連携と接続元制限方式の概要]
SAML は、認証、認可などの情報を安全に交換するためのフレームワークである。SAML を用いることによって、
利用者にサービスを提供するサービスプロバイダ（以下、SP という）と、ID プロバイダ（以下、IdP という）との間で
利用者の認証結果などの情報を安全に連携することができる。SAML には複数の処理方式が存在する。今回 F
社で導入を検討している方式のシーケンスを図 1 に示す。図 1 中の各通信のプロトコルは、IdP と LDAP サーバ
間は LDAP であり、それ以外は HTTP over TLS である。
図 1 導入を検討している方式のシーケンス

17
SAML を用いた認証連携を行うためには、事前に IdP と SP との間で様々な情報を共有することによって、信頼
関係を構築しておく必要がある。事前に共有する情報としては、通信の方式や連携する属性情報などが記述され
たメタデータ、 e で生成して送出する URL、 f において必要な IdP のディジタル証明書など
がある。
図 1 中の処理 1～4 の処理内容を表 1 に示す。
表 1 処理内容
処理番号処理内容
処理 1 ・ IdP に認証を要求する SAML Request を生成する。
・ SAML Request をエンコードする。
・エンコード結果を IdP のログイン画面の URL と組み合わせて、リダイレクト先 URL を
生成する。
処理 2 ・ URL 内の g から SAML Request を取得する。
・信頼関係が構築された SP からの認証要求であることを検証する。
処理 3 ・利用者の認証が成功した場合、検証結果や SP との間で連携する属性情報、有効期
間、それらの情報に対するディジタル署名を含めた SAML Response を生成する。
処理 4 ・ SAML Response に含まれるディジタル署名を検証することによって、ディジタル署名
が h によって署名されたものであること、及びデータの i がない
ことを確認する。
・ SAML Response 内の属性情報も検証することによって、サービスを提供すべきか決
定する。
C 主任は図 1 のシーケンスから、② IdP を社内ネットワークに設置しても認証情報の連携が成立することを確認
した。そこで、IdP は社内ネットワークに設置し、IdP のログイン画面の URL の FQDN には、社内の FQDN を割り
当てることにした。
[SAML を用いた認証連携と接続元制限の動作検証]
最後に C 主任は、F 社で利用しているクラウドサービスを用いて、SAML による認証連携の動作を検証すること
にした。C 主任は IdP を社内ネットワークに設置して必要な設定を行い、各クラウドサービス上に、既に利用して
いるものとは別の検証用アカウントを作成し、社内からのクラウドサービスへのログインが可能であることを確認し
た。また、③ 社外からクラウドサービスへのログインを試みると、失敗することも確認した。
C 主任は検証結果を B 部長に説明し、承認を得て、SAML を用いた認証連携と接続元制限を開始した。また、
シングルサインオンも併せて実現したことによって、クラウドサービスを利用する従業員の利便性も向上させること
ができた。

18
設問 1 本文中の下線①について、条件を満たす利用者 ID を特定するためには、どのような条件を満たすログ
イン記録を抽出すればよいか。満たすべき条件を 35 字以内で述べよ。
設問 2 [SAML を用いた認証連携と接続元制限方式の概要] について、（1）〜（5）に答えよ。
（1）図 1 中の a 〜 d に入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア. IdP イ. LDAP
ウ. SP エ. 利用者端末の Web ブラウザ
（2）本文中の e 、 f に入れる適切な処理番号を、表 1 中の処理 1〜4 の中から選び、答え
よ。
（3）表 1 中の g に入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア. Cookie イ. HTML ウ. クエリ文字列
エ. スキームオ. リファラ
（4）表 1 中の h 、 i に入れる適切な字句を、それぞれ 5 字以内で答えよ。
（5）本文中の下線②について、SP と IdP が直接通信できないにもかかわらず認証情報の連携が成立するのは
なぜか。その理由を、35 字以内で述べよ。
設問 3 本文中の下線③について、社外から交通費精算サービスとグループウェアサービスにアクセスしたとき、
それぞれのサービスは、異なる理由でログインに失敗する。それらは、図 1 中のどの通信ができないことに
よるものか。図 1 中の（1）〜（10）から選び、答えよ。また、その理由を、それぞれ 35 字以内で述べよ。

19
4.2 解答・解説
3 章の、基本情報技術者試験と同じだと思いませんか？記述は、情報処理技術者試験「特有の」書きにくさ
がありますが、それだけです。あえて言います。合格ラインを超えるのは簡単です。
それでは、解説していきます。
設問 1
問題文中の『条件を満たす利用者 ID』および『ログイン記録』とは、次の意味であると読み取れます。
条件を満たす利用者 ID F 社以外からのログインがあった利用者 ID のこと
ログイン記録 F 社で利用している各クラウドサービスに対するログイン記録のこと
つまり、設問 1 では、「各クラウドサービスにおける、どのようなログイン記録を抽出すれば、F 社以外からのログ
インがあった利用者 ID が特定できるか」について問われています。
各クラウドサービスのログイン記録のうち、『接続元 IP アドレス』が F 社の「グローバル IP アドレス」以外にな
っている記録を抽出すればよいとわかります。
ということで、
《解答》
接続元 I P アドレスが、 F 社のグロ ― バル I
P アドレス以外であるという条件
となります。
「接続元」と「グローバル IP アドレス」という用語が含まれていれば、満点だと思います。

20
続けていきます。
設問 2 (1)
解答から示すと、次の図のようになります。
2 章の、ID フェデレーションのコンセプトがわかっていれば、瞬殺できます。そうなっているはずです。
もっとも、ID フェデレーションについて知らなくても、国語力で正解は導けます。これが、ザ・情報処理技術者試
験・マジック。
まず、 b からです。最初にサービスを要求して、 a からサービスの提供を受けています。従
って、利用者端末の Web ブラウザであるとわかります。 a は、利用者にサービスを提供しているため、
SP であるとわかります。
次に、 d です。認証要求を受け、認証結果を応答しています。従って、LDAP であるとわかります。
最後に、残った c が、IdP であるとわかります。

21
バンバンいきます。
設問 2 (2)
IdP と SP の間で『事前に共有する情報』の中身が、どの処理で用いられるものであるか、問われています。
これも、ID フェデレーションについて知らなくても、正解は導けます。
まずは、 e についてです。
IdP がどこにあるのか、SP に、教えてあげなければならないです。そうしないと、SP にアクセスしてきた利用者
を、正しい IdP にリダイレクトしてあげられないからです。
SP に、利用者からリクエスト (1) があった時には、利用者を IdP にリダイレクトしてあげなければなりません。そ
こで SP は、「処理 1」で、リダイレクト先の URL を含めてレスポンス (2) を返す必要があります。
次に、 f についてです。
『IdP の』『ディジタル証明書』が必要とのことなので、該当するのは、「SP が、IdP によってされたディジタル
署名を検証」する処理であるとわかります。この時点で、処理 1 か処理 4 しか選択肢がありません。
IdP から認証結果が送られてくるのは、もちろんレスポンス (9) であるため、正解は「処理 4」となります。
《解答》
e 処理 1 で生成して送出する URL
f 処理 4 において必要な IdP のディジタル証明書
もりもり進みます。
設問 2 (3)
『URL 内の g から』とあるため、ウ. クエリ文字列またはエ. スキームしかありません。
● クエリ文字列とは、URL の後ろにつく文字列のことです。太字の箇所です
https://example.jp/?param1=value1&param2=value2
● スキームとは、URL の先頭につく http:、https:、ftp:、file:、javascript:、about: などのことです
正解は、ウとなります。
なお、ア. Cookie およびオ. リファラは、HTTP ヘッダのレコードです。

22
ゴリゴリ解きます。
設問 2 (4)
この h と i に入れる字句を、それぞれ 5 字以内で記述すると。前章の、基本情報技術者
試験レベルの問題ですね。
定する。
この処理 4 は、SP が行う処理です。IdP から連携された認証情報を検証し、サービスを提供すべきかどうか決
定します。
SP では、受け取った認証情報が、「確かに、登録されている IdP によって生成されたもの（他のホストでは生成
できない）であり、改ざんされていない」ことを検証する必要があります。
つまり、ディジタル署名が h. IdP によって署名されたものであることを確認しています。そして、ディジタル署
名は、データの i. 改ざんがないことを確認する技術でした。
あと少しです。
設問 2 (5)
『SP と IdP が直接通信できないにもかかわらず認証情報の連携が成立するのはなぜか』と聞かれても。いや、
当然、Web ブラウザ経由で通信しているからでしょ。以上。でも、これで、合格ライン突破できると思います。
もう少し字数があるので、① リダイレクトなどの技術を利用している旨を入れようか、② ちゃんと認証情報を検
証できるから、Web ブラウザ経由で成立する旨を入れようか、迷いました。
で、結局、こうしました。
《解答》
ディジタル署名付きの認証情報を、 W e b ブ
ラウザ経由で送受信しているから

23
いよいよ最後です。
設問 3
交通費精算サービスと、グループウェアサービスで、『ログインに失敗する』理由が問われています。
基本、どちらもいっしょです。どちらも、社外から IdP にアクセスできません。『社外から社内ネットワークへの通
信はファイアウォールによって禁止されている』からです。つまり、通信 (3) が阻まれます。
異なるのは、グループウェアサービスでは、『接続元 IP アドレスを制限する機能』があり、それを有効にしてい
るということです。
ですので、グループウェアサービスは、最初から SP に接続できません。
グループウェアサービスの『接続元 IP アドレスを制限する機能』については、[暫定対策の実施と根本的な
対策の検討] の箇所に書かれています。これを見つけられたかどうかで、設問 3 が満点になるか、半分しかとれ
ないか、決まります。うーん。
《補足》
IdP にアクセスできないということは、本物の SAML Response が作成できないということです。仮に、社外から
交通費精算サービスに対し、ニセの情報を『(9) SAML Response を送信』で送りつけたとしましょう。それで
あっても、処理 4 において、ディジタル署名の検証に失敗します。やはり、社外からサービスを利用することは
できません。
以上。あとは、まとめるだけです。

24
● 交通費精算サービス
交通費精算サービスは、『接続元 IP アドレスの制限機能』が備わっていないため（クラウドサービスでは、普通
にあることです）、社外からもアクセスできてしまいます。
社外の端末であったとしても、社内の端末同様、まずは SP に『(1) サービス要求』をします。SP は、利用者
を IdP へリダイレクトさせるため、端末に対し、『(2) リダイレクト指示』を応答します。
しかし、『社外から社内ネットワークへの通信はファイアウォールによって禁止されている』ため、IdP にアクセス
することはできません。
従って、通信 (3) によりログインに失敗します。
理由は、問題文の文言そのまま、『社外から社内ネットワークへの通信はファイアウォールによって禁止されて
いる』からです。
《解答》
社外から社内への通信は、ファイアウォ ― ル
によりブロックされるから

25
● グループウェアサービス
[暫定対策の実施と根本的な対策の検討] の箇所に、『グループウェアサービスは、接続元 IP アドレスを制限
する機能を備えていたので、その機能を有効化し、社内からだけログインできるように設定した』とあります。です
ので、外部の端末は、そもそもグループウェアサービスにアクセスできません。
従って、通信 (1) が、グループウェアサービスによって拒否されます。
これも、理由が本文中に解答が書かれています。一応、交通費精算サービスの解答と、平仄をとっておきます。
《解答》
社外からの通信は、接続元 I P アドレスの制
限により、ブロックされるから

26
出題趣旨
近年、企業においても外部のクラウドサービスの利用が増加しており、企業が保有する情報資産もクラウドサ
ービスへの移行が進んでいる。クラウドサービス上の情報資産を保護する上では、クラウドサービスでの認証と
アクセス制限が重要である。
本問では、クラウドサービス側での対応が拡大しつつある SAML を用いた認証連携を題材とし、認証とアク
セス制限を設計する能力について問う。
IPA 解答
設問 1 接続元 IP アドレスが F 社のグローバル IP アドレスではないこと
設問 2 (1) a ウ
b エ
c ア
d イ
(2) e 処理 1
f 処理 4
(3) g ウ
(4) h IdP
i 改ざん
(5) 認証に関する情報を利用者端末の Web ブラウザが中継するから
設問 3 交通費精算
サービス
番号 (3)
理由社外から IdP への通信がファイアウォールによって遮断されるから
グループウェア
サービス
番号 (1)
理由クラウドサービス側で接続元 IP の制限が行われているから
採点講評
クラウドサービスに対する認証連携を題材に、SAML を用いた認証連携と、その仕組みを利用したアクセス
制御の方法について出題した。全体として正答率は高かった。
設問 1 は正答率が高かった。クラウドサービス側に記録されるログイン記録について、よく理解されている
ようであった。
設問 2 は全体的に正答率が高かった。ただし、設問 2(5)については、IdP と SP が直接通信できない点を
考慮していない解答が散見された。SAML では IdP と SP 間での認証情報の連携方式が複数存在し、本文
中に記載した通信内容は一例である。今回の方式だけでなく、SAML の認証連携の仕組みを広く理解してお
いてほしい。
設問 3 は正答率が低かった。特に交通費精算サービスへのログインに失敗する理由については、IdP と
LDAP サーバの役割を混同した解答が一部に見られた。SAML における各主体の役割を理解しておいてほ
しい。

27
4.3 《発展》 SAML を深掘る
ここからは、これまで見てきた「情報処理安全確保支援士平成 29 年度（2018 年度）春期午後 I 問 3」を、
ごりごり深掘っていきます。この問題が解けるようになっていることを前提に、説明していきます。
・全体像
・認証シーケンス
・信頼関係の構築
・バインディング
・アカウント連携
・ SAML Request の生成
・ SAML Response の生成
・ SAML Response の検証
・セッションの確立
・まとめ
全体像
まずは、全体をざっと俯瞰しましょう。以降の説明であまり必要がない「LDAP サーバ」は、省略しました。IdP
の中に入っていると思ってください。水色の文字が、SP や IdP による処理の内容です。
図 1. SAML の全体像
よくわからない用語が、たくさん出てきました。これから、順に解説していきます。

28
認証シーケンス
SAML のシーケンスは、IdP が起点となるか、SP が起点となるかで、大きく 2 通りに分けられます。
表 1 SAML の認証シーケンス
認証シーケンス説明
IdP-initiated IdP が起点となる連携方式です。利用者は、最初に IdP に接続し、認証を行います。IdP に
より認証された後で、利用者は、リンクをクリックするなどして SP にアクセスします。このとき
に、IdP 経由で（IdP に認証情報をもらってから） SP にアクセスすることになります
SP-initiated SP が起点となる連携方式です。利用者は、最初に SP に接続し、IdP にリダイレクトされ、認
証を行います
SP 側で、どの IdP で利用者を認証するのか、予め定義しておきます
本問では、初めに Web ブラウザから SP へのリクエストを送信しているため、SP-initiated 方式となります。
信頼関係の構築
問題文中には、IdP と SP との「信頼関係の構築」について、次のような記述があります。
SAML を用いた認証連携を行うためには、事前に IdP と SP との間で様々な情報を共有することによって、
信頼関係を構築しておく必要がある。事前に共有する情報としては、通信の方式や連携する属性情報などが
記述されたメタデータ、 e で生成して送出する URL、 f において必要な IdP のディジタル
証明書などがある。
これを見る限り、おそらくですが、次の表のような情報の共有を想定しているのだと思われます。
表 2. IdP と SP との間で共有する情報
共有する情報登録場所情報の内容、用途
『メタデータ※1
』 IdP に登録する
SP の情報※2
『通信の方式（バインディングの箇所で解説）』
『連携する属性情報（アカウント連携の箇所で解説）』
『処理 1 で生成して送出
する URL』
SP に登録する
IdP の情報
IdP の URL※3
『IdP のディジタル証明書』『処理 4 において必要』
※1. メタデータは、XML 形式です
※2. SP に IdP の情報を登録する際に、メタデータ（SP メタデータ）を用いる場合もあります
※3. IdP のサービスを使う（e.g. 認証要求する）ための URL です。SSO エンドポイントと呼ばれることもあります

29
バインディング
バインディングとは、SAML のメッセージ（SAML Request の内容や、SAML Response の内容）を、実際の通信
プロトコル（HTTP など）にマッピングする方式です。ここでは、代表的なバインディングを、3 つ紹介します。
表 3. 代表的なバインディング
バインディング方式
HTTP リダイレクト
HTTP のリダイレクトにより、Web ブラウザを介して、メッセージを連携する方式です。
IdP または SP は、HTTP リクエストに対し、① ステータスコードに 300 番台を、② Location
ヘッダにリダイレクト先の URL を指定し、レスポンスを返します。
この URL のクエリ文字列には、SAML メッセージをエンコード（Base64 エンコードし、それを
URL エンコード）したデータを指定しておきます。要は、次のような HTTP レスポンス（一部）
を返します。
HTTP/1.1 301 Moved Permanently
Location: https://リクエストの送信先 ? samlRequest=エンコードされた SAML メッセージ
.
HTTP POST
HTML 中の JavaScript により、Web ブラウザを介して、メッセージを連携する方式です。
IdP または SP は、HTTP リクエストに対し、HTML 中に（form 要素をサブミットするような）
JavaScript を記述しておきます。Web ブラウザ上で、この JavaScript が実行されることで、自動
的に HTTP POST リクエストが送信されます。もちろん、POST データ中（input 要素の属性
値）には、エンコードされた SAML メッセージを格納しておきます。要は、次のような HTML
（一部）を返します。
<form id="samlform" action="リクエストの送信先">
<input type="hidden"
name="samlResponse"
value="エンコードされた SAML メッセージ" />
</form>
<script> samlform.submit(); </script>
.
HTTP Artifact
まずは、Artifact（アサーションそのものではなく、アサーションへのリファレンスのみが格納さ
れた小さなデータ）を、Web ブラウザを介して IdP と SP で送受信します。
その後、Artifact を用いて、IdP と SP が直接通信し、メッセージを連携する方式です。

30
本問の SAML Request は、「HTTP リダイレクトバインディング」により IdP に連携されています。(2) の通信に『リダ
イレクト指示』とあるからです。
また、SAML Response は、「HTTP POST バインディング」により SP に連携されています。(8) の通信に、『SAML
Response の送信フォームを応答』とあるからです。
アカウント連携
IdP と SP が連携するにあたっては、IdP のアカウントと、SP のアカウントが紐づけられている必要があります。そ
の方法には、大きく分けて、「ユーザの属性情報による連携」と「仮名による連携」があります。
表 4. アカウントの連携方式
連携方式説明
ユーザの
属性情報
IdP の属性と SP の属性（例えば、ユーザ ID）を、直接連携する方式です。
必然的に、自システムの情報の一部を、他システムに教えることになります。
仮名
（Pseudonym）
IdP のアカウントと SP のアカウントを紐づける「仮名（サービスごとにユニークな値）」を発行
する方式です。仮名には、次の 2 種類があります。
永続的な仮名
（Persistent）
IdP が、SP ごとに異なる値を発行します。同一 SP では、継続してサービスを
利用できます。ある SP の情報が知られてしまっても、別の SP で名寄せする
ことが難しくなります。
一時的な仮名
（Transient）
IdP が、認証ごと（アサーションごと）に異なる値を発行します。SP 間はもちろ
ん、同一 SP 内でも、過去のふるまいなどを紐づけられることがありません。
本問では、メタデータ中に、『連携する属性情報』とあるので、「ユーザの属性情報による連携」を想定してい
ます。
上記のうち、どの方式を用いるのかについては、メタデータに NameID フォーマットとして記述します（NameID
とは、認証された利用者の識別子のことです）。ここに指定できる値を 3 つ紹介します（他にもあります）。
・ urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified ・・・ NameID の解釈は、個々の実装にまかせる
・ urn:oasis:names:tc:SAML:2.0:nameid-format:persistent ・・・永続的な仮名による連携
・ urn:oasis:names:tc:SAML:2.0:nameid-format:transient ・・・一時的な仮名による連携
もちろん、本問では、unspecified が指定されているはずです。
「メールアドレス」、「氏名」、「性別」、「年齢」、「所属」などの属性情報についても、IdP と SP でマッピングして
おきます。どの属性をどのように連携するか（できるか）については、個々の IdP の実装にまかせられています。

31
SAML Request の生成
問題文中の『処理 1』では、SP は、次のようにして SAML Request （AuthnRequest と呼ばれることもあります）
を生成して、IdP に送信しています。ちなみに、SAML Request は XML 形式です。
問題文中「表 1.処理内容」の抜粋
処理 1 ・ IdP に認証を要求する SAML Request を生成する。
・ SAML Request をエンコードする。
・エンコード結果を IdP のログイン画面の URL と組み合わせて、リダイレクト先 URL を
生成する。
処理 2 ・ URL 内の g から SAML Request を取得する。
・信頼関係が構築された SP からの認証要求であることを検証する。
・・・
まさに、HTTP リダイレクトバインディング方式ですね。SAML Request を生成し、エンコードします。IdP のログ
イン画面の URL のクエリ文字列（空欄 g）に、エンコードした SAML Request を指定して、Location ヘッダに
指定する『リダイレクト先 URL』を生成します。
SAML Request には、例えば、次のような内容が含まれます。
表 5. SAML Request に含まれる情報の一部
要素属性内容
AuthnRequest ID SAML Request ごとにユニークな文字列。再利用を防ぐ
Version SAML のバージョン（e.g. 2.0）
IssueInstant SP が SAML Request を発行した日時
ProtocolBinding SP が SAML Response を受け取る際に利用する SAML
AssertionConsumerServiceURL SAML Response を受け取る SP※
の URL
Issure 発行者（e.g. SP ごとのユニークな文字列や URL）
NameIDPolicy Format NameID フォーマットの値（前述）
RequestedAuthnContext SP が IdP に要求する認証方式
Signature SP のディジタル署名
※ アサーション（後述）を生産するのが IdP に対し、消費するのが SP だという意味だと思います

32
参考までに、SAML Request の例を挙げておきます。
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
ID="ONELOGIN_809707f0030a5d00620c9d9df97f627afe9dcc24"
Version="2.0"
ProviderName="SP test"
IssueInstant="2014-07-16T23:52:45Z"
Destination="http://idp.example.com/SSOService.php"
ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
AssertionConsumerServiceURL="http://sp.example.com/demo1/index.php?acs">
<saml:Issuer>
http://sp.example.com/demo1/metadata.php
</saml:Issuer>
<samlp:NameIDPolicy
Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress" AllowCreate="true"/>
<samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</samlp:RequestedAuthnContext>
</samlp:AuthnRequest>
onelogin - SAML DEVELOPER TOOLS - SAML AuthNRequest (SP -> IdP)
https://www.samltool.com/generic_sso_req.php
本問の『処理 2』には、『信頼関係が構築された SP からの認証要求であることを検証』とあります。ですの
で、ここで生成した SAML Request には、ディジタル署名が付いている8
かもしれません。信頼関係を構築した際
に、IdP に、SP のディジタル証明書を渡していれば実現できます9
。
8
ディジタル署名は、バインディングによって、格納される場所が異なります。HTTP POST バインディングの場合
には、XML 中 signature 要素に格納されます。しかし、HTTP リダイレクトバインディングの場合には、URL クエリ
文字列 Signature に格納されます。
https://idp.example.com/Redirect?SAMLRequest=request&SigAlg=value&Signature=value&RelayState=token
9
これ言い出したら切りがないのですが、Azure AD のように、署名付き認証要求をサポートしていない IdP もあり
ます。

33
SAML Response の生成
問題文中の『処理 3』を見てください。SP は、このようにして SAML Response を生成し、IdP に送信していま
す。ちなみに、SAML Request 同様、SAML Response も XML 形式です。
処理 3 ・利用者の認証が成功した場合、検証結果や SP との間で連携する属性情報、有効期
間、それらの情報に対するディジタル署名を含めた SAML Response を生成する。
・・・
利用者の認証が成功した場合、IdP は、アサーション（Assertion）を生成します。アサーションとは、『処理 3』
で言うところの『検証結果や SP との間で連携する属性情報、有効期間、それらの情報に対するディジタル署名』
のことです。アサーションに含まれる情報、および、SAML Response に含まれる情報は、次の表の通りです。
表 6. アサーションに含まれる情報の一部
情報意味
Signature アサーションに対する、IdP の XML ディジタル署名（Enveloped 署名）
Subject NameID （認証された利用者の識別子）
Condition 検証条件。アサーションの有効期限（有効期限内であれば検証する）など
Statement Authentication
（認証）
・認証に使用された手段（e.g. パスワード認証）
・認証が行われた日時
Attribute
（属性）
Subject に紐づいている属性
（ユーザ ID、メールアドレス、氏名、性別、年齢、所属など）
Authorization decision
（認可決定）
あるサブジェクトが、特定の行動をすることが許可されていると
いう情報（特定の操作、特定のリソースへのアクセス）
表 7. SAML Response に含まれる情報の例（一部）
要素具体例
Issue アサーションを発行した IdP の URL
Status 認証に成功、または失敗したことを表す値（ステータスコード、ステータスメッセージ）
Assertion 上記のアサーション
※ アサーションのディジタル署名とは別に、SAML Response のディジタル署名をつける場合もあります

34
アサーションの署名部分については、次のようになっています。左側が、署名前のアサーション。右側が、署名
後のアサーションを表しています。
図 2. アサーションのディジタル署名
ごちゃごちゃして見えますが、通常のディジタル署名とあまり変わりません。要は、アサーションのダイジェストを
とって署名し、それをアサーションの中に埋め込むだけです。もう少し細かく説明します。
なお、実際は、ダイジェスト値が一定になるよう、正規化（e.g. 余分な空白や改行を削除するなど）が必要です
が、話を単純にするため、無視します。
① まず、どの部分を署名するのか、署名対象を決めます。そして、署名対象のダイジェストを計算します。署名
対象を指し示す「リファレンス URI」と、求めた「ダイジェスト値」などをあわせて、「リファレンス
（Reference）」を作成します
② 次に、作成した「リファレンス」に、「署名アルゴリズム」などの情報を加えて、「署名情報（SignedInfo）」を
作成します。「署名アルゴリズム」を使って、「署名情報」から「署名値（SignatureValue）」を求めます
③ 「署名情報」と「署名値」をまとめて「署名（Signature）」を作成し、アサーションに埋め込みます
このように、署名対象に署名を埋め込む XML ディジタル署名の形式を、エンベロープ署名（Enveloped
Signature）と呼びます。

35
《補足》 XML ディジタル署名
《安全確保支援士・セキュリティスペシャリスト R1 秋 / H30 春 / H28 秋 / H25 秋 / H22 春 / H19 春》
問 XML ディジタル署名の特徴のうち、適切なものはどれか。
ア XML 文書中の、指定したエレメントに対してデタッチ署名（Detached Signature）することができる。
イエンベローピング署名（Enveloping Signature）では一つの署名対象に必ず複数の署名を付ける。
ウ署名形式として、CMS（Cryptographic Message Syntax) を用いる。
エ署名対象と署名アルゴリズムを ASN.1 によって記述する。
まず、うるさいウとエから片づけます。次のことを知っておけば、十分だと思います。
・ XML 署名フォーマット、XML 暗号フォーマット ← W3C と IETF が共同で策定
・ CMS 署名フォーマット、CMS 暗号フォーマット ← ASN.1 が策定
本題です。XML ディジタル署名とは、XML にディジタル署名を埋め込むための標準です。次の 3 つの
形式は、知っておいて損はないと思います。
表 8. XML ディジタル署名の形式
署名形式概要
デタッチ署名（Detached Signature）「署名対象」と「署名」が独立
エンベロープ署名（Enveloped Signature）「署名」が「署名対象（封筒）」の中にある
エンベローピング署名（Enveloping Signature）「署名対象」が「署名（封筒）」の中にある
@IT - XML デジタル署名と XML 暗号 - 鈴木優一, エントラストジャパン
https://www.atmarkit.co.jp/ait/articles/0207/24/news001.html

36
参考までに、SAML Response の例を挙げておきます。
<samlp:Response ID="_257f9d9e9fa14962c0803903a6ccad931245264310738"
IssueInstant="2009-06-17T18:45:10.738Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://www.salesforce.com
</saml:Issuer>
<samlp:Status>
<samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status>
<saml:Assertion ID="_3c39bc0fe7b13769cab2f6f45eba801b1245264310738"
IssueInstant="2009-06-17T18:45:10.738Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://www.salesforce.com
</saml:Issuer>
<saml:Signature>
<saml:SignedInfo>
<saml:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<saml:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<saml:Reference URI="#_3c39bc0fe7b13769cab2f6f45eba801b1245264310738">
<saml:Transforms>
<saml:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<saml:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="ds saml xs"/>
</saml:Transform>
</saml:Transforms>
<saml:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<saml:DigestValue>vzR9Hfp8d16576tEDeq/zhpmLoo=
</saml:DigestValue>
</saml:Reference>
</saml:SignedInfo>
<saml:SignatureValue>
AzID5hhJeJlG2llUDvZswNUrlrPtR7S37QYH2W+Un1n8c6kTC
Xr/lihEKPcA2PZt86eBntFBVDWTRlh/W3yUgGOqQBJMFOVbhK
M/CbLHbBUVT5TcxIqvsNvIFdjIGNkf1W0SBqRKZOJ6tzxCcLo
9dXqAyAUkqDpX5+AyltwrdCPNmncUM4dtRPjI05CL1rRaGeyX
3kkqOL8p0vjm0fazU5tCAJLbYuYgU1LivPSahWNcpvRSlCI4e
Pn2oiVDyrcc4et12inPMTc2lGIWWWWJyHOPSiXRSkEAIwQVjf
Qm5cpli44Pv8FCrdGWpEE0yXsPBvDkM9jIzwCYGG2fKaLBag==
</saml:SignatureValue>
<saml:KeyInfo>
<saml:X509Data>
<saml:X509Certificate>
MIIEATCCAumgAwIBAgIBBTANBgkqhkiG9w0BAQ0FADCBgzELM
[Certificate truncated for readability...]
</saml:X509Certificate>
</saml:X509Data>
</saml:KeyInfo>
</saml:Signature>
<saml:Subject>
<saml:NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified">
saml01@salesforce.com

37
</saml:NameID>
<saml:SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData NotOnOrAfter="2009-06-17T18:50:10.738Z"
Recipient="https://login.salesforce.com"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions NotBefore="2009-06-17T18:45:10.738Z"
NotOnOrAfter="2009-06-17T18:50:10.738Z">
<saml:AudienceRestriction>
<saml:Audience>https://saml.salesforce.com</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement AuthnInstant="2009-06-17T18:45:10.738Z">
<saml:AuthnContext>
<saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute Name="portal_id">
<saml:AttributeValue xsi:type="xs:anyType">060D00000000SHZ
</saml:AttributeValue>
</saml:Attribute>
<saml:Attribute Name="organization_id">
<saml:AttributeValue xsi:type="xs:anyType">00DD0000000F7L5
</saml:Attribute>
<saml:Attribute Name="ssostartpage"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:unspecified">
<saml:AttributeValue xsi:type="xs:anyType">
http://www.salesforce.com/security/saml/saml20-gen.jsp
</saml:Attribute>
<saml:Attribute Name="logouturl"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri">
<saml:AttributeValue xsi:type="xs:string">
http://www.salesforce.com/security/del_auth/SsoLogoutPage.html
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>
</samlp:Response>
Salesforce Developers シングルサインオン実装ガイドサンプル SAML アサーション
https://developer.salesforce.com/docs/atlas.ja-jp.sso.meta/sso/sso_saml_assertion_examples.htm

38
SAML Response の検証
SP は、IdP のディジタル証明書を用いて、アサーション中のディジタル署名を検証します。これにより、アサーシ
ョンが、確かに信頼する IdP によって署名されたものであり、改ざんされていないことが確認できます。
定する。
・・・
XML ディジタル署名の検証は、次のようになります。署名するとき同様に、正規化は無視しています。
リファレンスの検証：
「リファレンス（Reference）」から、署名対象（アサーションから署名を除いた部分）を取得します。リファレン
ス中のダイジェストアルゴリズムを用い、署名対象のダイジェスト値を求めます。これを、予めあったダイジェスト値
と比較し、異なっていれば、検証は失敗です。
署名の検証：
他方、ディジタル証明書の公開鍵を用いて、署名値（SignatureValue）を復号し、ダイジェスト値を取り出しま
す。予めあったダイジェスト値と比較し、異なっていれば、検証は失敗です。
いずれもダイジェスト値が一致すれば、信頼する IdP が署名したものであり、改ざんされていないことが確認で
きます。
属性情報（AttributeStatement）も検証しています。このあたりは、実装次第です。必要な属性情報がない場
合や、サポートしていない属性情報が含まれている場合などには、エラーとなり、サービスが提供されないこともあ
るでしょう。

39
セッションの確立
SP がサービスを提供すると判断したら、利用者の Web ブラウザと SP との間で、セッションを確立します。いよ
いよ最後です。
HTTP は状態を保持できないため、利用者（の Web ブラウザ）は、SP に対し、一意の値を毎回送信する必
要があります（これが、セッションの実体になります）。例えば、次のようなイメージです（SP の位置を右側にして
います）。
Cookie を使ってセッション管理をするのであれば（これが一般的です）、『通信 (10)』の HTTP レスポンス
に、Set-Cookie ヘッダ（例えば、Set-Cookie: sessionid = abcdefg secure httpOnly）を設定するか、あ
るいは、レスポンスボディの HTML 中に、JavaScript （例えば、document.cookie = "sessionid = abcdefg
secure httpOnly ";）を入れることで、Web ブラウザに Cookie を設定します。
Set-Cookie ヘッダを使う場合のイメージは、次のようになります。
SP からの HTTP レスポンス（オレンジ色）によって、Web ブラウザに a.example.com の Cookie のとして
id=abc123 がセットされます。以降、a.example.com にアクセスする場合には、HTTP リクエストの Cookie ヘッダ
によって、毎回 id=abc123 という値が送信されます。

40
まとめ
最後に、これまで説明してきたことを踏まえて、もう一度全体像を見ておきましょう。
図 3. SAML の全体像
・ Web ブラウザは、まず SP に対し、「サービスを使わせておくれ」とリクエストします。(1) の通信です。SP-
initiated 方式と呼びました。
・ SP では、『処理 1』で、IdP に送るための SAML Request を作成します。SAML Request には、SAML
Response を受け取る SP の URL、SAML Response を受け取る際に利用する SAML バインディング（本問で
は、HTTP POST バインディング）、NameIDFormat の値（本問では、ユーザの情報）などが含まれていまし
た。アカウントは、IdP と SP で、直接ユーザの属性情報を交換、マッピングすることで連携していました。
・できあがった SAML Request は、エンコード（Base64 → URL）して、IdP の URL のクエリ文字列にセットし
ます。それを、HTTP レスポンスの Location ヘッダに入れて、300 番台で応答します。HTTP リダイレクトバイ
ンディングです。HTTP のレスポンス（一部）は、こんな感じでした。(2) の通信です。
HTTP/1.1 301 Moved Permanently
Location: https://リクエストの送信先 ? samlRequest=エンコードされた SAML メッセージ

41
・ Web ブラウザは、HTTP レスポンスを、Location ヘッダに指定された URL （IdP の URL です）へ、リダイレク
トします。(3) の通信です。この URL のクエリ文字列には、SAML Request が入っています。IdP は、『処理
2』で、この SAML Request を取り出します（クエリ文字列を URL デコードして、Base64 デコードします。圧
縮されていたら、解凍します）。そして、利用者が認証されていないことを確認すると、クレデンシャルを要求
します（本問では、ログイン画面を応答していました）。(4) の通信です。
・利用者は、IdP にクレデンシャル（ユーザ ID とパスワードなど）を送信します。(5) の通信です。IdP で認証
が成功すると、『処理 3』で、SAML Response を作成します。
・まずは、アサーション（認証情報、属性情報、認可情報）を作成します。本問では、おそらく、認証情報と属性
情報が含まれています。そして、アサーションに署名します。Enveloped 署名です。
・アサーションができたら、SAML Response を作成し、HTML フォームに設定します。こんな感じです。
<form id="samlform" action="リクエストの送信先">
<input type="hidden"
name="samlResponse"
value="エンコードされた SAML メッセージ" />
</form>
<script> samlform.submit(); </script>
・この SAML Response を HTTP レスポンスにのせて応答します。(8) の通信です。
・ Web ブラウザがコンテンツをロードすると、form を submit する JavaScript が実行され、SAML Response が
SP にリクエストされます。(9) の通信です。
・ SAML Response を受け取った SP は、『処理 4』で、事前に登録していた IdP のディジタル証明書を用い
て、アサーションを検証します。
・アサーションが正当であれば、アサーションに従って、サービスを提供します。HTTP レスポンスで、Set-
Cookie ヘッダや JavaScript を応答して、ブラウザに Cookie を設定します。(10) の通信です。

42
5 今回参考にした文献
5.1 書籍
クラウド時代の認証基盤 Azure Active Directory 完全解説 – Vittorio Bertocci 著 - 日経 BP 社
5.2 Web サイト
（アルファベット、五十音順）
[1] @IT - 鈴木優一エントラストジャパン- XML デジタル署名と XML 暗号
https://www.atmarkit.co.jp/ait/articles/0207/24/news001.html
[2] Cyboze Inside Out - SAML 認証ができるまで
https://blog.cybozu.io/entry/4224
[3] IdM 実験室 - プライバシーに考慮した ID 連携設定
https://idmlab.eidentity.jp/2014/12/ad-fsid.html
[4] Microsoft Docs - Microsoft ID プラットフォームのドキュメント - シングルサインオンの SAML プロトコル
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/single-sign-on-saml-protocol
[5] Office365 の Identity 管理
https://www.slideshare.net/naohiro.fujie/office365identity
[6] Qiita - @ea54595 - SAML2.0 でのシングルサインオン実装と戦うあなたに(.NET 編)
https://qiita.com/ea54595/items/e932644477a45070690b
[7] Qiita - @ekojima - SAML2.0 シングルサインオンの流れと設定項目の意味をちゃんと理解する
https://qiita.com/ekojima/items/5a09fb3e7f8017c08aae
[8] オープンソース・ソリューション・テクノロジ - クラウド時代のシングルサインオン
https://www.osstech.co.jp/_media/techinfo/seminar/hbstudy-20110416-sso.pdf

■ 著者
あし
IT 嫌い・IT ど素人で SIer に飛び込んだ愚か
者。10 年ほど受託開発に従事した後、エンジニ
アをセミリタイア。ここ数年は、SIer の本社部門
にて、慣れない企画推進に凹む日々を送ってい
る。
著書：「情報セキュリティスペシャリスト完全合格
対策（2009, 2010, 2011 年版）」
資格：情報処理安全確保支援士、GREM、
CEH など多数
ミッション - IT 教育を通じ、エンジニアとして大
きな一歩を踏み出す後押しをします
バリュー - 「難しい」を「好き」に
2020 年 5 月 17 日
情報処理技術者試験で学ぶ SAML
Version 0.9.1 （たたき台）発行
著者あし
発行所明日はもっと高いと思う（https://tasuwa.net）
© 明日はもっと高いと思う 2020

情報処理技術者試験で学ぶ SAML

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 情報処理技術者試験で学ぶ SAML

Similar a 情報処理技術者試験で学ぶ SAML (20)

Más de higher_tomorrow

Más de higher_tomorrow (15)

Último

Último (9)

情報処理技術者試験で学ぶ SAML