第4回 アイデンティティ管理における「レベル合わせ」
連携アイデンティティ管理を実現するには、「その認証は本当にきちんと行われているか」といった条件を満たし、信頼関係を結ぶことが必要になります(編集部)日本電信電話株式会社
NTT情報流通プラットフォーム研究所
伊藤 宏樹
2011/4/11
これまで、第1回「『アイデンティティ管理』の周辺事情を整理しよう」では主要なシングルサインオン方式について、第3回「OpenID/SAMLのつなぎ方とその課題」では、Kantara Initiative Concordia Discussion Group(Concordia DG)にて行われていたOpenIDとSAMLとの相互連携ユースケースについて解説しました。
今回から2回にわたり、「サーバ間での信頼構築」の材料の1つとなる「Identity Assurance」(アイデンティティの保証)の考え方について説明したいと思います。
認証の「レベル合わせ」の必要性
これまでに説明してきた「連携アイデンティティ管理」では、どのようにすれば、複数のサーバ間でユーザー・アイデンティティにかかわるメッセージを安心、安全に交換できるか、がポイントになります。ここでいう「安心、安全に交換できる」ことの対象は、単なるサーバ間のメッセージ送受信には留まりません。
|
| 図1 シングルサインオンの基本的な手順(第1回 図2) |
第1回で示した例をもう一度紹介しましょう。ここで「認証サーバ」は、「サービス提供サーバ」が発行した要求メッセージ(図1のA)の内容を、真に検証する手段を持ちません。同様に「サービス提供サーバ」は、「認証サーバ」が発行した応答メッセージ(同E)の内容(すなわち、メッセージに含まれるアカウント名などのユーザー・アイデンティティそのもの)を、真に検証する手段を持ちません。
次に、サービス提供サーバが、「認証サーバでユーザーIDとパスワードを照合してきちんと認証しました」という主張を受け入れるケースを考えてみましょう。この場合、認証サーバがユーザー・アイデンティティをどの程度厳密に管理しているか、例えば、
- 認証サーバ内のデータベースはどのように管理されているか
- 認証サーバはそのアカウントが不正利用されていないことを確認できているか
- 認証サーバにてユーザーにパスワードを定期的に変更させているか
などの体制が不明なままでは、その主張を受け入れることは困難です。サービス提供サーバで高度なサービスを提供するために必要な「ユーザーの正当性」が担保されていない可能性があります。
第2回で説明した「コンコーディア」における取り組みでも、同様のことがいえます。
|
| 図2 サーバ間の依存関係例(第2回 図2) |
これは第2回で示した例です。「サーバB」は、「方式A」で受けた要求メッセージを「方式B」に変換した上で「サーバC」に通知し、「方式B」で受けた応答メッセージを「方式A」に変換した上で「サーバC」に通知しています。さて、この「方式A」と「方式B」との間のメッセージの変換の正当性は、いったい誰が担保するのでしょうか?
これらの課題は「認証のレベル合わせ」「アイデンティティ管理のレベル合わせ」などと表現されます。プロトコルレベル、メッセージレベルで内容の完全性や機密性を図ること、あるいは相互認証や否認防止を図ること、とは異なる概念です。
相互信頼の構築に必要な手続き
それでは、連携アイデンティティ管理を実現するにあたって必要な「相互信頼」は、どのように構築されるべきなのでしょうか? 大まかに分けて、次の2つの方法があると考えられます。
●相互評価や契約を基にした信頼関係
先に示した「認証サーバ」と「サービス提供サーバ」のような単純な事例であれば、両者間での接続条件の調整に特に問題は生じないでしょう。これは、相互評価に基づいてサービスが実施される1つの形態だと考えられます。
また、SAMLやLiberty Alliance ID-WSFといった、サービス提供に際して「信頼の環(トラストサークル:Circle of Trust)」の構築を前提とする仕様もあります。
![]() |
| 図3 SAML、Liberty Alliance ID-WSFにおける信頼の環 |
この場合、「SAML 2.0に対応した認証サーバと接続する際には、認証サーバが指定した接続条件を満たすこと」といった類の契約に基づき、シングルサインオンなどのサービス実現に必要な環境を整備することになります。
信頼の環をサービス提供サーバが主導する場合も考えられます。Google AppsをSAML SP(サービス提供サーバ)として利用する場合などがその例です。サービス提供サーバが主導し、SAML IdP(認証サーバ)として機能する各接続元のサービスがサービス提供サーバに要求された接続条件を満たすケースもあります。
●第三者の評価による信頼関係
前述の「 相互評価や契約を基にした信頼関係」は、アイデンティティ管理にかかわる事業者や組織が、自発的、能動的に相互接続条件を評価することを前提としていました。これに対し第三者の評価では、認証サーバ、サービス提供サーバや、それらを運営する事業者、組織が第三者による評価を受け、その上で、ある条件を満たした事業者間でのみ接続を行う形態が考えられます。
| 図4 監査体制のイメージ |
例えばKantara Initiativeは第三者評価機関として、アイデンティティ管理技術を導入するサービス、事業者に対し、当該事業者、組織がユーザー・アイデンティティを管理、運用する事業者、組織としてふさわしいことを監査し、認定する枠組み作りを進めています。そして、この監査の礎となる仕様の1つが、次回紹介するIdentity Assurance Framework(IAF)です。この仕様は、Kantara Initiative Identity Assurance Work Group(IAWG)にて策定されています。
1/3 |
| Index | |
| アイデンティティ管理における「レベル合わせ」 | |
| Page1 認証の「レベル合わせ」の必要性 相互信頼の構築に必要な手続き |
|
| Page2 アイデンティティ保証レベルの規定 Identity Assuranceの運用事例も |
|
| Page3 コラム■アンカンファレンス方式の「Internet Identiry Workshop」 |
|
アイデンティティ管理の新しい教科書 バックナンバー
- 第1回 「アイデンティティ管理」の周辺事情を整理しよう
- 第2回 ID管理技術をつなぐ女神、コンコーディア
- 第3回 OpenID/SAMLのつなぎ方とその課題
- 第4回 アイデンティティ管理における「レベル合わせ」
| アイデンティティ管理の新しい教科書 連載インデックス |
TechTargetジャパン
- 実録、「Hardening Zero」の舞台裏 (2012/5/25)
コラムの更新頻度を落として何をやっていたかって? 「守る技術」に焦点を当てたこんなイベントを開催しました - 複雑化、巧妙化する脅威への対策は? (2012/5/23)
データ保護や標的型攻撃対策、クラウドセキュリティ……「第9回 情報セキュリティEXPO」の会場で見つけた製品を一挙に紹介 - 仮想化がはらむ新たなリスク (2012/5/17)
仮想化に伴って生じるセキュリティやパフォーマンスへの影響を慎重に考慮し、うまく制御していく方法を紹介します - 新入生も新入社員も勉強会に寄っといで! (2012/5/14)
週末ともなれば至るところでセキュリティ系勉強会やCTFなどのイベントがあり、ツイートも盛り上がりました
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -


