![閉じる [x]](http://dw1.s81c.com/i/c.gif){kind=small}
IT 業界はほぼ 2 年間をかけて Web サービスについて話し合ってきました。パイロット プログラムや大規模な実稼働環境で Web サービスが使用されるようになると、組織内、企業間、およびインターネット経由でアプリケーションをリンクする疎結合で、言語中立の、プラットフォームに依存しない方法を持つことの利点が、ますます明白になってきます。ユーザ、業界アナリスト、および報道機関は、この先 Web サービスが主流になってくるときに取り組む必要のある重要な分野はセキュリティであると認識しています。このドキュメントはこのセキュリティについての技術方策とロードマップを提案します。業界はこの提案を使って、標準ベースのアーキテクチャを作成し、実装できます。標準ベースのアーキテクチャは包括的で、かつ Web サービスのセキュリティに対する実際のビジネスのニーズを十分満たす柔軟性を備えたものです。
新たな Web サービス アーキテクチャの主な利点は、統合された、相互運用可能なソリューションを提供する能力です。包括的なセキュリティ モデルを備えたアプリケーションを使って Web サービスの完全性、秘匿性、およびセキュリティを確実することが、組織にとっても、組織のユーザにとっても重要になります。
IBM と Microsoft はユーザと業界の両方から表明された懸念に応えて、ここで提案する Web サービス セキュリティ プランとロードマップに共同で取り組みました。IBM と Microsoft はここで提案する Web サービス セキュリティ プランとロードマップに従って、Web サービス環境でのメッセージ交換の保護を提供する方法に対処する Web サービス セキュリティ仕様のセットを開発します。
まず初めに、公開鍵インフラストラクチャ (PKI) や Kerberos など、以前は互換性がなかったセキュリティ テクノロジを 1 つにまとめたセキュリティ モデルを作成しました。簡単に言えば、これは理想的なフレームワークではありませんが、現在ユーザが利用しているさまざまな種類の IT 分野でセキュアな Web サービスを構築できる実用的なフレームワークです。
このドキュメントでは、広範なアプリケーション トポロジやビジネス トポロジにまたがった認証、認可、プライバシー、信頼、完全性、秘匿性、セキュアな通信チャネル、連合、委任、監査などのセキュリティ テクノロジをカバーする幅広い仕様のセットを提示しています。これらの仕様は、拡張性があり、柔軟で、セキュリティ インフラストラクチャへのこれまでの投資を最大限に活かすフレームワークを提供します。これらの仕様は、IBM と Microsoft が以前に提案した同様の仕様 (つまり、SOAP-Security、WS-Security や WS-License 仕様) で表明した考えを包含し、拡張したものです。
仕様は、Web サービス モデルの中核となる自然な拡張性を応用することにより、SOAP、WSDL、XML デジタル署名、XML 暗号化、SSL/TLS などの基本的なテクノロジを基礎として構築されます。この結果、Web サービス プロバイダや要求者は、アプリケーションの個別のセキュリティの必要条件を満たすソリューションを開発できます。
IBM と Microsoft は、このセキュリティ モデルを段階的アプローチで進化、改善するために、ユーザ、パートナー、および標準化団体と共同で作業するつもりです。この作業はWS-Security 仕様にまとめられています。WS-Security は、メッセージの整合性や機密性を保護する中核となる機能や、メッセージにセキュリティ関係の確認を関連付けるメカニズムを定義します。WS-Security がこの作業の基礎になりますが、この作業は始まったばかりで、今後業界と共同で、ポリシー、信頼、プライバシーの問題を扱う新たな仕様を作成していく予定です。
このドキュメントで説明している問題点やソリューションをできる限り具体的にするために、Web サービスの現在のアプリケーションおよび予想されるアプリケーションを反映するいくつかのシナリオを説明します。これらのシナリオには、ファイアウォール処理、プライバシー、ブラウザやモバイル クライアントの使用、アクセス制御、委任、および監査などがあります。
さまざまな提案仕様の相互運用性や一貫性のある実装を保証するために、何が行えるのかという懸念を予測しています。IBM と Microsoft はこの懸念を解消するために、標準化組織、開発者コミュニティ、WS-I.org などの業界組織と密接に連係して、ツール ベンダにガイダンスを提供する相互運用性のプロファイルやテストを開発するつもりです。
このドキュメントは、包括的なモジュール構造のソリューションを概説しています。このソリューションを実装すると、ユーザはセキュリティ インフラストラクチャへのこれまでの投資を利用、拡張する、相互運用可能な、セキュアな Web サービスを構築でき、同時に Web サービス テクノロジが提供する必要のある統合と相互運用性の利点を完全に利用できます。
Web サービスのセキュリティ機能やコンポーネントの包括的なモデルを提供することにより、今後のアプリケーションで進化するセキュリティの必要条件と、現在利用できるプロセスやテクノロジの統合が必要になります。これは統一した概念を要求します。また、テクノロジ (セキュアなメッセージ処理) の問題点とビジネス プロセス (ポリシー、リスク、信頼) の問題点の両方に対するソリューションを必要とします。最後に、プラットフォーム ベンダ、アプリケーション開発者、ネットワーク プロバイダやインフラストラクチャ プロバイダ、およびユーザの連合した作業が必要になります。
利用できるさまざまなセキュリティ テクノロジを統一することは、採用する特定のメカニズムからアプリケーション セキュリティの機能的な必要条件を取り出す必要があることを意味します。たとえば、オンラインで商品を購入するユーザは、各デバイスが適切な ID を安全に表明している限り、携帯電話を使用しているか、ラップトップ コンピュータを使用しているかによって、影響を受けるべきではありません。
目標は、ユーザが異種システムを使った相互運用可能なソリューションを容易に構築できるようにすることです。たとえば、このドキュメントの後半で提案するセキュアなメッセージング モデルは、より一般的な機能の特定の具体的表現として、PKI メカニズムと Kerberos ID メカニズムの両方をサポートします。さらに、このメッセージング モデルを別のセキュリティ メカニズムをサポートするように拡張できます。単一のセキュリティ モデルの抽象概念を通じた統合により、異なるテクノロジを使用している複数の組織と通信しているときに、複数の組織がそれぞれセキュリティ テクノロジへの既存の投資を使用することを可能にします。
さらに、異なる ID メカニズムを使用している複数の組織が Web サービスを使用して共同作業するときに、セキュリティ信頼モデルが柔軟なフレームワークを提供し、複数の組織は適切な認可が構成されているときはそのフレームワーク内で相互接続できます。
同時に、すべてのユーザやすべての Web サービスは特定のビジネス ニーズや運用環境に基づいて、独自の一意なセキュリティの必要条件を持ちます。たとえば、ワークグループ設定内では単純さと操作の容易さが一番の関心事項ですが、パブリック インターネット アプリケーションでは、組織的なサービス拒否攻撃に耐えうる能力の優先順位が高くなります。これらの必要条件が多くの方法で組み合わせられる可能性があり、異なるレベルの特定性で表される可能性があるので、Web サービス セキュリティへのアプローチが成功するには、ポリシーや構成を使ってさまざまなセキュアなソリューションを可能にする柔軟で、相互運用可能なセキュリティ プリミティブのセットが必要になります。
このドキュメントでは、これらの課題に取り組むために、以前の異なるテクノロジを統一するセキュリティの抽象概念のセットに基づく、セキュアで、相互運用可能な Web サービスを作成する進化していくアプローチを提案しています。これは、フレームワーク全体から特定の顧客の必要条件を限定することを可能にする一方で、時間の経過と共にテクノロジが進化し、導入が増加していくことを同時に可能にします。
この進化していくアプローチの一例として、セキュアなメッセージング モデルを既存のトランスポート レベルのセキュリティ ソリューションに追加できます。ユーザは、たとえば Secure Sockets Layer (SSL/TLS) 経由で送信されるメッセージを持つ既存の Web サービスに、メッセージ レベルの完全性または永続的な秘匿性 (メッセージ要素の暗号化) を追加できます。そのメッセージは、トランスポート層を超えて保持される完全性 (または秘匿性) を持つことになります。
新たに提案するモデルや仕様は、複数のベンダから広範に利用でき、適切な標準化組織によって検討されるであろうと予測しています。モデル、仕様、および標準化プロセスが一体となることにより、ビジネスは既存のアプリケーションのセキュリティをすばやく、費用効率よく向上でき、新しい相互運用可能でセキュアな Web サービスを確信を持って開発できます。
このようなモデルのビジネス上の利点は明白です。ますますビジネス プロセスが Web サービスに作り直されていくようになるにつれ、組織やユーザは Web サービスの包括的なセキュリティ アーキテクチャを組み立てることによって、これまでの投資や資産が保護されることをより確実にできます。
テクノロジによって専門用語が変化するので、このドキュメントでは異なるセキュリティ形式やメカニズムに一貫性を持って適用されるいくつかの用語を定義します。その結果、ここで使用される専門用語は他の仕様書とは異なる可能性があります。また、読者が好みの用語に置き換えることができるように定義されています。
- Web サービス-- 用語 "Web サービス" は、さまざまなネットワーク ベースのアプリケーション トポロジに幅広く適用できます。このドキュメントでは用語 "Web サービス" を使用して、XML、SOAP、WSDL、HTTP などの既存および新規の Web テクノロジ標準のアプリケーションを使用する可能性のあるユーザに公開される機能やインターフェイスを持つアプリケーション コンポーネントを説明しています。Web サイト、ブラウザ ベースの対話、またはプラットフォームに依存するテクノロジとは対照的に、Web サービスは定義済みのフォーマットやプロトコルを使用して、プラットフォームに依存しない、言語中立の手法で、コンピュータ対コンピュータに提供されるサービスです。
-
セキュリティ トークン-- セキュリティ関連の情報 (例、X.509 証明書、Kerberos チケットや認証システム、SIM カードからのモバイル デバイス セキュリティ トークン、ユーザ名など) の表現としてセキュリティ トークンを定義します。
次の図にいくつかの異なる種類のセキュリティ トークンを示します。
- 署名付きセキュリティ トークン-- 発行者が暗号的に保証し、関連する申告 (アサーション) のセットを保持するセキュリティ トークンとして、"署名付きセキュリティ トークン" を定義します。署名付きセキュリティ トークンの例には、X.509 証明書や Kerberos チケットなどがあります。
- 申告 (Claims)-- 申告は、主体、または、主体を申告に関連付ける信頼される機関の、いずれかによる主体に関する記述です。ここで重要な点は、この仕様では行える申告の種類を制限しないだけでなく、これらの申告を表現する方法も制限しないことです。申告を、メッセージの署名や暗号化に使用する可能性のある鍵に関係するものにできます。申告を、セキュリティ トークンが搬送するステートメントにできます。たとえば、送信者の ID や認可された役割をアサートするために申告を使用することもできます。
- 主体-- セキュリティ トークンの主体は、セキュリティ トークンで表現される申告が適用される実体 (例、人、アプリケーション、またはビジネス エンティティ) です。特に、主体はセキュリティ トークンの所有者として、セキュリティ トークンの所有権を証明するために必要な情報を所有します。
- 所有の証明( Proof-of-Possession )-- セキュリティ トークンまたは申告のセットの所有権を証明するプロセスで使用する情報を "所有の証明" と定義します。たとえば、所有の証明が、公開鍵を含むセキュリティ トークンに関連付けられる秘密鍵になることもあります。
- Web サービス エンドポイント ポリシー-- Web サービスは、メッセージを処理するために必要な申告の指定に完全な柔軟性を持ちます。このような必要な申告や関連情報を総称して "Web サービス エンドポイント ポリシー" と呼びます。エンドポイントは XML で表記されることがあり、エンドポイントを使って、認証 (例、ユーザ ID またはグループ ID の証明)、認可 (例、特定の実行権限の証明)、またはその他のカスタム要件に関連する必要条件を示すことができます。
- 申告要件-- 申告要件を、メッセージ全体やメッセージの要素、指定した種類のすべての操作、または特定の状況下だけの操作に結び付けることができます。たとえば、サービスはサービスの要求者に、規定した制限を超える量を購入する権限を証明することを要求する場合があります。
- 中間ノード-- SOAP メッセージが最初の送信者からサービスに送信されるとき、メッセージのルーティングやメッセージの変更などの操作を実行する中間ノードによってそのメッセージが操作される可能性があります。たとえば、中間ノードがヘッダの追加、メッセージの一部の暗号化や復号化、または別のセキュリティ トークンの追加を行う可能性があります。このような状況では、完全性を無効にしたり、信頼モデルに違反したり、アカウンタビリティを破壊したりすることのないように注意が必要です。
- アクタ-- "アクタ" とは、URI もしくは、SOAP メッセージのプロセスにより識別される中間ノードもしくは終端 (SOAP 仕様書で定義されている) です。ユーザもクライアント ソフトウェア (例、ブラウザ) もアクタではないことに注意してください。
SOAP メッセージを URI で識別されるサービスのエンドポイントに送信し、特定の操作を要求し、SOAP メッセージ応答 (失敗応答も含む) を受信することによって、Web サービスにアクセスできます。このコンテキスト内で、Web サービスをセキュリティで保護するという幅広い目標は、メッセージの完全性と秘匿性を保護するための機能を提供するという目標と、ポリシーによって要求される申告を表すメッセージの要求だけをサービスが操作することを保証する機能を提供するという目標に分けられます。
今日では、Web サービス アプリケーションにトランスポート レベルのセキュリティを提供するために、業界標準の Transport Layer Security (TLS) と共に Secure Socket Layer (SSL) が使用されています。SSL/TLS は、認証、データ完全性、データ秘匿性など、いくつかのセキュリティ機能を提供します。SSL/TLS はセキュアなポイント ツー ポイント セッションを可能にします。
IPSec は、Web サービスで重要になる可能性があるトランスポート セキュリティの別のネットワーク層標準です。SSL/TLS と同様に、IPSec もホスト認証、データの完全性、およびデータ秘匿性を使ってセキュアなセッションを提供します。
今日の Web サービス アプリケーション トポロジには、モバイル デバイス、ゲートウェイ、プロキシ、負荷分散、非武装地帯 (DMZ)、アウトソースされたデータ センター、グローバルに分散され動的に構成されるシステムなどが含まれます。これらすべてのシステムは、メッセージを転送するメッセージ処理をする中間ノードの能力に依存します。特に、SOAP メッセージ モデルは物理ネットワークやアプリケーション インフラストラクチャを抽象化する論理エンドポイントで動作します。そのため、中間 アクタ を備えたマルチホップ トポロジを組み込むことがよくあります。
トランスポート層を超えてデータが中間ノードによって受信、転送されるとき、データの完全性とすべてのセキュリティ情報の両方が失われる可能性があります。これは、以前の中間ノードによって行われたセキュリティの評価に依存し、かつその中間ノードのメッセージのコンテンツの処理を完全に信頼することを、すべての上流のメッセージ プロセッサに強制します。包括的な Web サービス セキュリティ アーキテクチャに必要なものは、エンド ツー エンド セキュリティを提供するメカニズムです。成功する Web サービス セキュリティ ソリューションは、セキュリティ権限の包括的なセットを提供するために、トランスポート層セキュリティ メカニズムとアプリケーション層セキュリティ メカニズムの両方を利用できるでしょう。
ポイント ツー ポイント構成
エンド ツー エンド構成
ここで説明する Web サービス セキュリティ モデルは、以下のプロセスによってこれらの目標を実現できます。
- Web サービスは、着信するメッセージが "申告" のセット (例、名前、鍵、許可、権限など) を証明することを要求できます。必要な申告を持たずにメッセージが着信した場合は、サービスはこのメッセージを無視するか、破棄できます。必要な申告のセットとその関連情報を "ポリシー" と呼びます。
- 要求者は、"セキュリティ トークン" をメッセージに関連付けることにより、必要な申告の証明と共にメッセージを送信できます。そのため、メッセージは特定の操作を要求することと、メッセージの送信者がその操作を要求するための申告を持っているのを証明することの両方を行います。
- 要求者が必要な申告を持っていない場合、その要求者または代わりの誰かが他の Web サービスにコンタクトすることによって、必要な申告の取得を試みることができます。このような他の Web サービスを "セキュリティ トークン サービス" と呼び、これは申告の独自のセットを順次要求する可能性があります。セキュリティ トークン サービス 仲介者は、セキュリティ トークンを発行することにより、異なる信頼ドメイン間を信頼します。
このモデルを以下の図で説明します。任意の要求者がサービスの場合もあり、セキュリティ トークン サービスが、ポリシーの表明やセキュリティ トークンの要求を含む完全な Web サービスの場合もあります。
申告、ポリシー、およびセキュリティ トークンを使用するこの一般的なメッセージング モデルは、ID ベースのセキュリティ、アクセス制御リスト、権限ベースのセキュリティなど、より特定のモデルをいくつか包含し、サポートします。このモデルは、X.509 公開鍵証明書、Kerberos 共有秘密チケット、パスワード ダイジェストなどの既存のテクノロジの使用を許します。後半で説明するように、システムが異なるセキュリティ テクノロジ間にブリッジを構築できるようにする統合抽象概念も提供します。一般的なモデルは、高度な鍵交換、認証、認可、監査、および信頼メカニズムを構築するには、十分です。
ここで示しているセキュリティの方策と、以下で紹介するWS-Security 仕様は、提案する Web サービス セキュリティ モデルの戦略的目標と根本理念を提供します。
これから先も、Web サービス セキュリティ仕様の初期セットを開発するために、ユーザ、パートナー、および標準化組織と共同で行う作業プロセスを続けていきます。
この初期セットには、他のセキュリティ仕様の基礎を提供するメッセージ セキュリティ モデル (WS-Security) を含むことになるでしょう。このモデルは層を形成しており、Web サービス エンドポイント ポリシーを含むポリシー層 (WS-Policy)、信頼モデル (WS-Trust)、およびプライバシー モデル (WS-Privacy) を持っています。これらの初期仕様がまとまって、信頼関係のあるドメイン間にまたがったセキュアな、相互運用可能な Web サービスを実現するために作業できる基礎を提供します。
引き続きユーザ、パートナー、および標準化団体と共同で作業を行い、これらの初期仕様を基礎に構築していくことにより、セキュアな対話 (WS-SecureConversation)、信頼の連合 (WS-Federation) および、認可 (WS-Authorization) などを、セキュリティの連合ための追加仕様として提供します。
これらのセキュリティ仕様の組み合わせは、今日のより基本的なセキュリティ メカニズムでは実装が困難な多くのシナリオ (シナリオの一部はこのドキュメントの後半で説明します) を可能にします。
この作業と並行して、監査、管理、およびプライバシーに関連する仕様と共に、Web サービス セキュリティ フレームワークを強化する関連活動を提案し、推し進めていくでしょう。
さらに、IBM と Microsoft は相互運用性プロファイルでの WS-I のような組織と共同で作業することに全力を傾けます。
ユーザはセキュリティ仕様の組み合わせ、関連活動、および相互運用性プロファイルを使って、相互運用可能なセキュアな Web サービスを容易に構築できます。
提案する各仕様を以下にまとめます。
- WS-Security: SOAP メッセージに署名ヘッダおよび暗号化ヘッダを添付する方法を記述します。それに加え、X.509 証明書や Kerberos チケットなどのバイナリ セキュリティ トークンを含むセキュリティ トークンをメッセージに添付する方法を記述します。
- WS-Policy: 中間ノードやエンドポイントでのセキュリティ ポリシー (およびその他のビジネス ポリシー) の権限や制約を記述する予定です (例、必要なセキュリティ トークン、サポートする暗号化アルゴリズム、プライバシーの規則)。
- WS-Trust: Web サービスが安全に相互運用できるようにする信頼モデルのフレームワークを記述する予定です。
- WS-Privacy: Web サービスや要求者が、主体のプライバシーの設定や組織的なプライバシー実践ステートメントを提示する方法のモデルを記述する予定です。
- WS-SecureConversation: セキュリティ コンテキストの交換、セッション 鍵確立と派生などを含めて、団体間のメッセージ交換を管理、認証する方法を記述する予定です。
- WS-Federation: アイデンティティの連合のサポートを含めた、異種での連合された環境における信頼関係の管理と仲介の方法について、記述する予定です。
- WS-Authorization: 認可データや認可ポリシーを管理する方法を記述する予定です。
WS-Security にセキュリティを提供することは、多くの機能分野での記述、仕様、およびプロファイルの作成に不断の努力が必要になります。ユーザのニーズと Web 開発コミュニティのニーズを比較検討するプロセスや、仕様を決定するプロセスを行っているときの独自の教育プロセスを通じて、これらのドキュメントは変化し、進化していくことになるでしょう。
WS-Security は、メッセージの完全性やメッセージの秘匿性を使って "保護品質（quality of protection）" を提供するための SOAP メッセージ処理の強化を記述します。さらに、この仕様は SOAP メッセージ内にセキュリティ トークンを添付および含める方法を定義します。最後に、バイナリ エンコードされたセキュリティ トークン (例、X.509 証明書) を指定するためのメカニズムを提供します。さまざまなセキュリティ モデルや暗号化テクノロジを調整するために、これらのメカニズムを単独または組み合わせて使用できます。
WS-Security は、セキュリティ トークンをメッセージに関連付ける汎用のメカニズムを提供します。WS-Security が特定の種類のセキュリティ トークンを必要とすることはありません。これは拡張可能 (例、複数のセキュリティ トークン形式のサポート) になるようにデザインされています。たとえば、要求者は ID の証明や特定のビジネス証明書を持っていることの証明を提供するかもしれません。
メッセージが変更されずに送信されることを保証するために、XML 署名をセキュリティ トークン (鍵 データを含むか暗示するかもしれません) とともに使用することによりメッセージの完全性を提供します。完全性メカニズムは、複数のアクタによる複数の署名をサポートするように、さらに他の署名形式のサポートを拡張できるようにデザインされています。署名はセキュリティ トークンを参照する (すなわち、示す) ことができます。
同様に、SOAP メッセージのある部分や複数の部分の機密を保持するために、XML 暗号化をセキュリティ トークンとともに使用することによりメッセージの秘匿性を提供します。暗号化メカニズムは、複数のアクタによる別の暗号化テクノロジ、プロセス、および操作をサポートするようにデザインされています。暗号化もまたセキュリティトークンを参照することができます。
最後に、WS-Security はバイナリ セキュリティ トークンを符号化するためのメカニズムを記述します。特に、仕様では X.509 証明書や Kerberos チケットをエンコードする方法だけでなく、構造の不明な暗号化された鍵を含める方法も記述しています。また、メッセージに含まれるセキュリティ トークンの特性を詳しく記述するために使用できる拡張性メカニズムを含んでいます。
WS-Policy は、送信者や受信者が必要条件や権限を指定できる方法を記述する予定です。
WS-Policy は完全な拡張性を持ち、記述される可能性のある必要条件や権限の種類に制限を設けないでしょう。ただし、仕様は、おそらく、プライバシー属性、符号化形式、セキュリティ トークンの必要条件、サポートされるアルゴリズムなどを含む、いくつかの基本的なサービスの属性を識別することになるでしょう。
この仕様では汎用の SOAP ポリシー形式を定義するでしょう。このポリシー形式は単なるセキュリティ ポリシー以上のものをサポートできます。また、この仕様ではサービス ポリシーを SOAP メッセージに添付または関連付けるメカニズムも定義するでしょう。
WS-Trust は、直接信頼関係および仲介された信頼関係 (サード パーティや中間ノードを含む) の両方を確立するためのモデルを記述する予定です。
この仕様では、セキュリティ トークン発行サービスの作成を通じて仲介される信頼の基礎として、既存の直接信頼関係がどのように使用されるかを記述するでしょう。これらのセキュリティ トークン発行サービスは、必須のセキュリティ トークンの完全性と秘匿性を保証する方法でこれらのセキュリティ トークンを転送するために、WS-Security を基礎にします。
さらに、この信頼モデルと共にいくつかの既存の信頼メカニズムがどのように使用できるかも記述するでしょう。
最後に、信頼モデルはプリンシパルによる委任や偽装を明示的に許可するでしょう。ただし、これは必須ではありません。委任と偽装には一貫性がありますが、追跡可能性の新たなレベルを提供することに注意してください。
Web サービスを作成、管理、使用する組織は、組織のプライバシー ポリシーを提示し、送信者がこれらのポリシーに準拠していることの申告を行うことを着信要求に求める必要がある場合がよくあります。
WS-Policy、WS-Security、および WS-Trust を組み合わせて使用することにより、提示したプライバシー ポリシーに準拠していることを、組織が表明および示唆できます。この仕様では、プライバシー言語を WS-Policy 記述に埋め込む方法、およびプライバシーの申告をメッセージに関連付けるためにWS-Security を使用する方法についてのモデルを記述する予定です。最後に、この仕様では、ユーザからの設定および組織的な実施申告の両方に対してこれらのプライバシー申告を評価するために、WS-Trust メカニズムを使用する方法を記述するでしょう。
WS-SecureConversation は、Web サービスが要求者のメッセージを認証する方法、要求者がサービスを認証する方法、および相互に認証されたセキュリティ コンテキストを確立する方法を記述する予定です。
この仕様では、セッション 鍵、派生鍵、およびメッセージ単位の鍵を確立する方法を記述するでしょう。
最後に、この仕様ではサービスが安全にコンテキスト (セキュリティ属性や関連データについての申告のコレクション) を交換する方法を記述することになるでしょう。仕様ではこれを実現するために、セキュリティ トークン発行の概念やWS-Security と WS-Trust で定義された交換メカニズムを記述し、構築することになるでしょう。たとえば、サービスはこれらのメカニズムを使用することにより、弱い対称鍵 テクノロジを使用してセキュリティ トークンをサポートするだけでなく、非共有 (非対称) 鍵を使用してより強いセキュリティ トークンを発行できます。
WS-SecureConversation は、メッセージがさまざまなトランスポートや中間ノードを経由して転送されるように、SOAP メッセージ層で操作するようにデザインされます。これはメッセージング フレームワーク内での使用を除外しません。システムのセキュリティをさらに上げるために、トランスポート レベル セキュリティを、選択したリンクにまたがってWS-Security と WS-SecureConversation の両方とともに使用してもよいでしょう。
この仕様では、WS-Security、WS-Policy、WS-Trust、および WS-SecureConversation の各仕様を使って、信頼の連合シナリオを構築する方法を定義する予定です。たとえば、Kerberos インフラストラクチャと PKI インフラストラクチャを連合させる方法を記述するでしょう (以下のシナリオで説明します)。
さらに、仲介されている信頼の種類を示唆、制約、識別するために信頼ポリシーを導入します。
また、この仕様では信頼関係を管理するメカニズムも定義するでしょう。
この仕様では、Web サービスのアクセス ポリシーを指定および管理する方法を定義する予定です。特に、セキ ュリティ トークン内で申告を指定する方法、およびこれらの申告をエンドポイントで解釈する方法を記述するでしょう。
この仕様は、認証形式と認証言語の両方に関して柔軟性と拡張性を持つようにデザインされるでしょう。これは広範なシナリオを可能にし、セキュリティ フレームワークの長期間の存続を保証します。
Web サービス セキュリティと現在のセキュリティ モデルの関係
この Web サービス セキュリティ モデルは、現在一般的に使用されている認証、データ完全性、およびデータ秘匿性に関して、既存のセキュリティ モデルと互換性があります。その結果、Web サービス ベースのソリューションを、以下のような既存のセキュリティ モデルに統合できます。
- "トランスポート セキュリティ"—セキュア ソケット (SSL/TLS) などの既存のテクノロジは、メッセージに簡単なポイント ツー ポイントの完全性や秘匿性を提供できます。Web サービス セキュリティ モデルは、特に複数のトランスポート、中間ノード、および伝送プロトコルを経由するエンド ツー エンドの完全性や秘匿性を提供するために、既存のセキュアなトランスポート メカニズムをWS-Security (およびその他の仕様) と組み合わせて使用することをサポートします。
- "PKI"—PKI モデルは、公開非対称鍵と鍵の所有権以外のプロパティをアサートする機関 (たとえば、属性の機関) を持つ認証機関に高いレベルで関係しています。このような証明書の所有者は、ID などのさまざまな申告を表すために、関連付けられた鍵を使用する可能性があります。Web サービス セキュリティ モデルは、公開非対称鍵を使ってセキュリティ トークンを発行するセキュリティ トークン サービスをサポートします。ここでは PKI を広い意味で使用しており、特定の階層やモデルを想定していません。
- "Kerberos"—Kerberos モデルは、両者に暗号化された対称鍵を発行し、その対称鍵を他方に "導入する" ことによって両者間で信頼を仲介するために、鍵配布センター ( KDC ) との通信に依存します。Web サービス モデルは、暗号化された対称鍵と暗号化された信用書を持つセキュリティ トークンを発行することにより、信頼を仲介するセキュリティ トークンを備えた中核となるモデルを基礎にします。
このモデルは互換性を持ちながら、相互運用性を保証するために、署名や暗号のアダプタや共通のアルゴリズムが一致するか、開発される必要があることに注意してください。
連合、認証 (委任を含む)、プライバシー、および信頼に関する既存のモデルは、共通性が少なく、よりアドホックなものです。これらのセキュリティ プロパティに取り組む仕様は、この方策の後半の段階で示されます。
多くの場合、既存の信頼モデルはビジネス契約に基づいています。この一例が UDDI Web サービスです。UDDI では、API のセットをサポートするための合意を通じてユニバーサル ビジネス レジストリ (Universal Business Registry) を提供する参加者がいくつか存在します。UDDI の "信頼モデル" は、特定の認証メカニズムの必要条件を使って "信頼" の単一モデルを定義するのではなく、情報の管理人であるノードに認証の役割を与えます。つまり、UDDI Web サービスの各実装は独自の認証メカニズムを持ち、独自のアクセス制御ポリシーを設定します。"信頼" は、オペレータ間および要求者と情報の管理人であるオペレータ間のものです。
以下に、提案する Web サービス セキュリティ仕様がどのように使用されるかを例示する多くのシナリオを示します。これらのシナリオは、セキュリティ 方策全体の能力を示すために、意図的に技術的な詳細に注目しています。詳細なビジネス使用例を提供する関連ドキュメントも存在するでしょう。
ここで使用している会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、イベントなどの名称は架空のものです。実在する会社、組織、製品、ドメイン名、電子メール アドレス、ロゴ、人物、場所、イベントなどとは一切関係ありません。
以下のリストは、提案する初期仕様や関連提供物がサポートできるいくつかのシナリオを簡単に紹介しています。
- ユーザー名/パスワードを使った直接信頼とトランスポート レベル セキュリティ-- このシナリオは、トランスポート セキュリティでユーザ名とパスワードを使った認証を説明します。
- セキュリティ トークンを使った直接信頼-- このシナリオは、X.509 証明書と Kerberos サービス チケット (ST) を使った直接信頼を説明します。
- セキュリティ トークンの取得-- このシナリオは、メッセージとは独立して格納されるセキュリティ トークンを使用する認証を説明します。
- ファイアウォール処理-- このシナリオは、ファイアウォールが高度な制御にこのセキュリティ モデルを利用する方法を説明します。
- 発行済みセキュリティ トークン-- このシナリオは基本的な認証を説明します。
- ビジネス ポリシーの執行-- このシナリオは、ビジネス プロセスを体系化するためにセキュリティ トークンの発行を使用する方法を説明します。
- プライバシー-- このシナリオは、クライアントやサービスがプライバシー ポリシーを通信する方法を説明します。
- Web クライアント-- このシナリオは、クライアントとしての Web ブラウザの使用を説明します。
- モバイル クライアント-- このシナリオは、モバイル クライアントが安全に Web サービスと相互作用する方法を説明します。
シナリオの 2 番目のセットは、より洗練されたものです。これらのシナリオは現在の提供物でも構築できますが、シームレスに相互運用するには後続の仕様 (WS-SecureConversation など) が必要になります。
- 連合の有効化-- このセクションでは、連合される信頼に関係するいくつかの異なるシナリオを説明します。
- 検証サービス-- メッセージのセキュリティ (例、署名) を検証するサービスの使用法を説明します。
- 委任のサポート-- これは委任に対するセキュリティ トークンの使用法を説明します。
- アクセス制御-- これは、Web サービスが従来のアクセス制御リスト ベースのセキュリティをサポートする方法を説明します。
- 監査-- これはセキュリティ関連の動作やイベントを監視するための監査の使用を説明します。
以下の説明で、要求者という用語は Web サービスのさまざまな可能性のあるユーザを説明するために使用しており、要求者の特性を制限する意図はないことに注意してください。要求者は、B2B 環境内でサービスと相互作用するビジネス エンティティや、ブラウザやモバイル デバイスからサービスにアクセスする個人を含む可能性があります。
ユーザ名/パスワードを使った直接信頼とトランスポート レベル セキュリティ
ここでは、Web サービス セキュリティを既存のトランスポート セキュリティ メカニズムと共に使用する方法の非常に基本的な例を示します。
要求者はセキュアなトランスポート (例、SSL/TLS) を使用して Web サービスへの接続を開きます。要求者は要求を送信し、ユーザ名とパスワードを保持するセキュリティ トークンを含めます。サービスがその情報を認証し、要求を処理し、結果を返します。
このシナリオでは、メッセージの秘匿性と完全性は既存のトランスポート セキュリティ メカニズムを使用して処理されます。
このシナリオは、2者が機密情報、つまり要求者のパスワードを共有するために、あるメカニズムを既に使用していることを想定しています。これらの両者間の組織上の関係については何も想定していません。
このシナリオでは、Web サービスが直接信頼するセキュリティ トークンの使用を説明します。ここで直接信頼とは、要求者のセキュリティ トークン (または署名機関) が既知で、Web サービスにより信頼されていることを意味します。このシナリオは、その２者がセキュリティ トークンを使用するための信頼関係を確立するあるメカニズムを使用していることを想定しています。この信頼は、アプリケーションを構成することによって、または交換鍵に対してセキュアなトランスポートを使用することによって手作業で確立できます。鍵のセキュアなトランスポートにより、信頼される機関が、受信者に対して鍵またはセキュリティ トークンの検証をアサートする方法として、SSL (またはその他のメカニズムやプロセス) などのトランスポートを使用することを意味します。これらの両者間の組織上の関係については何も想定していません。
要求者はサービスにメッセージを送信し、署名付きのセキュリティ トークンを含め、たとえば、署名を使用してセキュリティ トークンの所有の証明を提供します。サービスがこの証明を検証し、セキュリティ トークンを評価します。セキュリティ トークンの署名が有効であれば、サービスにより直接信頼されます。サービスが要求を処理し、結果を返します。
直接信頼は、プライバシーのポリシーが参加者によって十分理解されることを想定します。
場合によっては、使用されるセキュリティ トークンがメッセージの一部として渡されないことがあります。代わりに、トークンの所在を示し、取得するために使用できるセキュリティ トークン参照が提供されます。
要求者はサービスに要求を発行し、セキュリティ トークンへの参照を含め、所有の証明（proof-of-possession）を提供します。Web サービスは提供された情報を使用して、トークン ストア サービスからセキュリティ トークンを取得し、証明を検証します。Web サービスがそのセキュリティ トークンを信頼する (信頼はメッセージ セマンティクスの外部で確立されることに注意してください) と、要求が処理され、応答が返されます。
ファイアウォールは、依然として Web サービス セキュリティ アーキテクチャでも重要なコンポーネントです。ファイアウォールは引き続き境界処理のための規則を設定できる必要があります。
以下に示すように、ファイアウォールは着信する SOAP メッセージを調べ、"認可された" 要求者からのメッセージだけがファイアウォールを通過することを許可します。
このシナリオでは、ファイアウォールの内側の Web サービスにメッセージを送信する 2 つの要求者がいます。ファイアウォールはメッセージを調べて、要求者がファイアウォールの内側の指定した Web サービスにメッセージを送信することを "認可されている" かどうかを判断します。
このシナリオでは、ファイアウォールはメッセージの署名に使用したセキュリティ トークンを調べることによってこの判断を行います。もし、署名が有効で、ファイアウォール内にメッセージを送り込むことを認可するためにセキュリティ トークンの署名機関が信頼され、トークンがファイアウォール内にメッセージを送り込むことを認可することを示しているならば、メッセージが許可されます。それ以外の場合は拒否されます。場合によっては、署名がファイアウォールを SOAP アクタとして特別に参照することもあります。
その他のシナリオでは、ファイアウォールがセキュリティ トークン発行機関として動作し、そのファイアウォールが発行したセキュリティ トークンの所有の証明を含むメッセージだけを許可します。
ここでの例は、Web サービス セキュリティが信頼された機関による簡単な認証をサポートする方法を示します。
最初の 2 つのステップで、要求者は認証機関と通信し、セキュリティ トークン、特に要求者の ID を証明するアサーションの署名付きステートメントを取得します。
Web サービスが適切な種類のセキュリティ トークンが必要であること (この場合は ID の証明) を要求するポリシーを持っているので、要求者はセキュリティ トークンを取得します。
次に要求者はメッセージに添付されるセキュリティ トークンと所有の証明 (認証子または署名付きチャレンジ) と共にメッセージを Web サービスに送信し、応答を受信します。
上記の説明では、ID 証明サービスの動作について詳しく説明されていないことに注意してください。要求者は ID セキュリティ トークンを取得するために、既存のセキュリティ プロトコルまたは Web サービス セキュリティ仕様を利用できます。
要求者が Web サービス セキュリティ仕様を使用していると仮定すると、システムは次のように動作するでしょう。ID サービスがポリシーに必要条件を記述します。その後、要求者はその ID の証明と共にセキュリティ トークンを要求できます。
ID サービスは単なるセキュリティ トークン サービスであることに注意してください。その上、Web サービスの対称性により、任意の Web サービスがセキュリティ トークン サービスをカプセル化することもできます。
最後に、Web サービスが要求者の代わりに (セキュリティ トークン サービスから) セキュリティ トークンを取得でき、その後のメッセージで使用するためにそのセキュリティ トークンを要求者に返すことができることに注意してください。
多くのビジネス プロセスでは、設定する必要のある特定のポリシーが存在します。たとえば、顧客が特定の監査企業での一定の評価または身分を持つことをサービスが要求する場合があります。Web サービスではプロセス全体を単純化して、これら多くのポリシーを自動的に体系化および検証できます。
次の例を考えてみましょう。
Nicholas' Dealership は、部品供給業者との対話に使用する Web サービスを持っています。ただし、Nicholas' Dealership は製造業者が保証する部品を持つ供給業者だけと付き合いたいと思っています。
部品会社である Joshua's Parts は製造業者に出向き、(たとえば、上記で説明したセキュリティ トークン サービスからの) ID セキュリティ トークンを提示 (および証明) し、Joshua's Parts が証明済みの部品ディーラーであることを示す製造業者からのセキュリティ トークンを要求します (Joshua's Parts が証明され、健全な状態であると仮定しています)。その後、Joshua's Parts は Nicholas' Dealership にコンタクトし、両方のセキュリティ トークンを提示 (および証明) します。
Nicholas' Dealership がビジネス ポリシーをサービス ポリシーに体系化している場合は、ポリシー準拠の負荷を部品会社 (すなわち、Joshua's Parts) に負わせることができます。
また、サービス ポリシーは、プライバシー ポリシーに準拠していることを保証するために、製造業者がどのような情報を格納できるかについての制約を指定できます。
プライバシーは関連事項の広範なセットを含み、この方策から明らかになる各仕様で考慮される必要があるでしょう。
基本的なプライバシーの問題は、サービス ポリシー内でプライバシーの声明を提供することで解決されるでしょう。委任や認証に関連する、より洗練されたシナリオは、これらのシナリオ固有の仕様でカバーする予定です。
一例として、個人は "プライバシー設定" のセットを表明します。プライバシー設定は、アプリケーションが個人の情報を使って行い、個人のために作用することのうち、何を許可し、何を許可しないかを記述します。個人のために作用するカレンダー設定アプリケーションは、個人的な情報を使用および開示することについての声明と決定を行うために、"プライバシー設定規則" のセットを使用するカレンダー設定サービスにアクセスできるようになります。カレンダー サービスは、提案する使用または開示が許可可能かどうかを判断するために、プライバシー設定規則とプライバシー設定を組み合わせることにより、その判断を行います。
中間層の Web アプリケーションと通信する Web クライアントを持ち、次にその中間層 Web アプリケーションが別のドメインの Web サービスと (安全に) 対話する例を考えてみましょう。中間層の Web アプリケーションは Web サービス対応で、Web クライアントのセキュリティ トークンの取得を必要とするとします。
さらにこのシナリオでは、セキュリティ トークンにより、中間層アプリケーションがサービスと対話するときに、クライアントの代理として振舞うことができると仮定します。
このシナリオを可能にするために、Web クライアントのブラウザが中間層アプリケーションにアクセスし、関連付けられた ID サービスにリダイレクトされます。要求が (たとえば、HTML フォームと https を使って) 認証された後、その要求が中間層アプリケーションにリダイレクトして戻されます。ID サービスが、(ID や委任をアサートする) セキュリティ トークンを、(たとえば、HTTPS 経由で送信されるクエリ文字列を使って) 元の中間層アプリケーション Web サーバに提供します。その結果、Web サーバがこれらのセキュリティ トークンを使用できるようになり、Web サーバ独自の ID から Web サービスに要求を発行できるようになります。Web サービスがその要求を処理し、結果を Web サーバに返します。Web サーバが結果の体裁を整え、ブラウザに返します。
このドキュメントでここまで説明してきた仕様は、モバイル セキュリティ固有のデザイン課題の取り組みに大きな柔軟性を提供します。Web サービス アプローチの柔軟性により、コンピュータ処理能力やストレージ能力が制限されているデバイスで、堅牢かつパフォーマンスの高い暗号的な保護を提供する複数の暗号テクノロジをサポートできます。同様に、この柔軟性はモバイル クライアントのために作用するために、ネットワーク オペレータがネットワーク ゲートウェイなどのセキュリティ プロキシを提供することを可能にします。
以下はこれらの考え方を組み合わせる例です。ネットワーク オペレータが (Web サービス セキュリティ仕様を使って) モバイル クライアントをサポートするとき、要求をネットワーク オペレータのゲートウェイを経由して送信するようにクライアントを構成できます。このシナリオでは、ゲートウェイはメッセージの流れ全体に積極的に参加する SOAP の中間ノードです。特に、ネットワーク オペレータがモバイル デバイス用にデザインされた付加価値のある暗号化アルゴリズムを提供しています。ゲートウェイはセキュリティ トークンとメッセージの保護レベルを補強または変更できます。この Web サービス セキュリティ モデルに本来備わっている柔軟性は、デバイスが外部ネットワークでローミングされるときでさえ、このソリューションを可能にします。
このことを以下の例で示します。
Web サービス セキュリティ モデルは連合をサポートするようにデザインされています。以下は、アイデンティティの連合の簡単な例です。
Adventure456 に所属する Alice は、Business456 にある 通貨 Web サービスを使用したいと考えています。この 通貨サービスは Business456 が発行したセキュリティ トークンを持つ要求だけを処理します。Alice は Adventure456 が発行した ID 申告を持つセキュリティ トークン (つまり、ID セキュリティ トークン) だけを所持しています。
このシナリオでは、Business456 が Adventure456 とのセキュリティ の連合を自発的に受け入れるつもりがある場合のみ、Alice は 通貨サービスにアクセスできるでしょう。
以下のセクションでは、セキュリティ の連合に対するいくつかのアプローチを説明します。
このシナリオでは、通貨サービスのポリシーは Business456 が発行したセキュリティ トークンだけを受け入れることを表明しています。ポリシーが必要なセキュリティ トークンを入手する場所を示しているので、Alice は Adventure456 セキュリティ トークンを Business456 セキュリティ トークン サービスに提示 (および証明) し、Business456 セキュリティ トークンを受け取ります。その後、要求内で受け取ったセキュリティ トークンを 通貨サービスに提示 (および証明) します。これを以下の図に示します。
このアプローチでは、Business456 セキュリティ トークン サービスは、Adventure456 が発行した ID 申告を持つセキュリティ トークンを受け入れるように構成されます。
この例は、ビジネス ポリシーの設定シナリオの例と非常によく似ていることに注意してください。このことは、Web サービス セキュリティ モデルの柔軟性を例示しています。
このアプローチでは、通貨サービスは任意のセキュリティ トークンを持つ要求を受け入れますが、指定したセキュリティ トークン (および証明) に基づく Business456 セキュリティ トークンを取得できない場合は、その要求は処理されません。
これを行うために、通貨サービスは元の要求を Business456 セキュリティ トークン サービスに転送し、Business456 セキュリティ トークン サービスが初期セキュリティ トークンを評価します。このセキュリティ トークンが有効な場合は、その要求は保証され、Alice がその後の要求で使用するために Business456 セキュリティ トークンを含めることができます。これを以下の図に示します。
このアプローチでは、Business456 セキュリティ トークン サービスは、Adventure456 が発行した ID 申告を持つセキュリティ トークンを受け入れるように構成されます。
セキュリティ トークン交換を使った連合 (PKI → Kerberos)
このアプローチでは、Adventure456 は Alice に公開鍵 セキュリティ トークンを発行し、通貨サービスのポリシーは KDC からの Kerberos セキュリティ トークンだけを受け入れることを示します。
通貨サービス ポリシーの指示で、Alice は自分の公開鍵 セキュリティ トークンを、Business456 のセキュリティ トークン サービスに提示 (および証明) します。セキュリティ トークン サービスが Business456 の KDC をカプセル化します。その結果、Alice の公開鍵 セキュリティ トークンを評価できるので、通貨サービスに対して Kerberos セキュリティ トークンを発行します。これを以下の図に示します。
このアプローチでは、Business456 セキュリティ トークン サービスが、Adventure456 が発行した ID 申告を持つ公開鍵 セキュリティ トークンを受け入れるように構成されます。
セキュリティ トークンを使った連合 (Kerberos → Security トークン サービス)
このアプローチでは、Adventure456 が Alice に Kerberos セキュリティ トークンを発行するので、通貨サービスのポリシーは独自のセキュリティ トークン サービスが発行したセキュリティ トークンだけを受け入れることを示します。
ここでは、Adventure456 および Business456 の管理者がセキュリティの連合をさせるために、公開鍵証明書を交換することを想定します。さらに、Alice が対称鍵 テクノロジだけをサポートすることを想定します。
Alice は 通貨 Web サービス ポリシーに基づいて、Business456 のセキュリティ トークン サービスにアクセスするために使用できるセキュリティ トークンを獲得する必要があります。Alice は対称鍵 セキュリティ トークンを使用しているので、まず、Business456 セキュリティ トークン サービスで使用することを目的とするセキュリティ トークンを獲得するために、自分のセキュリティ トークン サービスにコンタクトします。このセキュリティ トークンは、Business456 セキュリティ トークン サービスの公開鍵でエンコードされる対称鍵 Sab を保持することになるでしょう。
Alice は、Business456 セキュリティ トークン サービスで使用することを目的とするセキュリティ トークンを使って、通貨サービスのセキュリティ トークンを要求します。Business456 セキュリティ トークン サービスは Alice に、対称鍵 Sac と共に 通貨サービスのセキュリティ トークンを提供します。
Alice は、通貨サービスで使用することを目的とするセキュリティ トークンと関連付けられた対称鍵を使って、通貨サービスに要求を行います。
クレデンシャル交換を使った連合 (Kerberos → Kerberos)
このアプローチでは、Adventure456 が Alice に Kerberos セキュリティ トークンと 通貨サービスのポリシーを発行します。通貨サービスのポリシーは、KDC をカプセル化するそれ自身のセキュリティ トークン サービスが発行した Kerberos セキュリティ トークンだけを受け入れることを示します。
ここでは、Adventure456 と Business456 の管理者は領域（realm）をまたがって信頼が遷移することは希望しませんが、セキュリティの連合をさせるために公開鍵証明書を交換するのを希望することを想定します。さらに、Alice と 通貨サービスの両方が対称鍵 テクノロジだけをサポートすることを想定します。
以前の例と同様に、セキュリティ トークン サービスは信頼ドメイン内のサービスに対称鍵 セキュリティ トークンを提供する能力を持ちます。結果的に、上記で説明したアプローチがこのシナリオで機能します。
この Web サービス セキュリティ モデルは、メッセージの処理とセキュリティ トークンの検証を要求者が "アウトソース" するシナリオもサポートします。このようなサービスは使い方を間違えるとスケーラビリティの問題が生じる可能性があることに注意する必要があります。つまり、実装によっては、検証サービスを実行するサービスの負荷が高くなったり、低くなったりします。Web サービス セキュリティ モデルはいずれかのアプローチをサポートし、その結果このシナリオを可能にします。
このシナリオでは、検証サービスをセキュリティ トークン サービスから切り離します。検証サービスとセキュリティ トークン サービスを組み合わせたり、両者が直接信頼関係を持つ (そのため WS-Federation を必要としない) ような他のシナリオもあります。
このシナリオでは、要求者はセキュリティ トークン サービスからセキュリティ トークンを取得します。その後、Web サービスにメッセージを送信し、所有の証明 (すなわち、署名) を含めます。Web サービスは検証サービスに、署名ブロック、セキュリティトークン、および署名されたダイジェストの評価を送信します。その後、Web サービスが信頼する検証サービスが有効か無効かの決定を発行します。
検証サービスが、適切な申告をアサートする要求者に代わってセキュリティ トークンを発行することにより、その決定を示すことに注意する必要があります。
Web サービス セキュリティは委任をサポートします。以下は、このアプローチの柔軟性を示すためにデザインされた洗練された委任のシナリオです。Alice は calendar456 を使用してスケジュールを管理します。Alice は Bob が Alice との会議を火曜日に設定することを許可したいと思っています。ただし、Bob はこのスケジュール設定を直接行いません。その代わりに、Bob はサービス schedule456 を利用して、Alice の予定表に会議を設定する必要があります。
Alice は Bob が会議の予定を設定する方法を知りませんが、Alice の予定表を参照できるサービスのセットを制限したいと思っています。
Alice は、Bob が Alice の予定表に会議のスケジュールを設定できるようにするセキュリティ トークンを Bob に提供します。このセキュリティ トークンは、Bob の能力を火曜日に会議のスケジュールを設定することに制限する申告を保持します。さらに、このセキュリティ トークンは、主体がサード パーティのサービス TrustUs456 からのプライバシー証明書を持っていることを証明できる限り、Bob がその後のセキュリティ トークンを発行することを可能にします。
サービス Schedule456 は TrustUs456 によって監査されるので、これらはプライバシー証明書をアサートするセキュリティ トークンを持つことになります。
スケジュール サービスが Calendar456 の Alice の予定表にアクセスするとき、Alice から Bob を経由して スケジュール サービスに渡されるセキュリティ トークンに基づいて会議にアクセスし、スケジュールを設定するために、プライバシーの証明書と申告に関する所有の証明を証明できます。
Alice と Bob が共同で作業を行っている間は、互いに頻繁に会議の予定を設定することがわかるので、あるレベルの信頼を開発することになります。その結果、Alice は Bob が毎回委任を行わないで会議の予定を設定できるようにしたいと考えます。Alice は委任セキュリティ トークンの有効期限を延長できますが、Alice が会議予定を設定する Bob の能力を無効にしたいと考える場合、セキュリティ トークンを再発行する必要があり、これが問題になることがあるでしょう。
Alice は (自分を認証して) カレンダー サービスと通信し、認可リストを取得します。Alice はこの認可リストを更新し、Bob が Alice の空き時間情報データを参照し、会議の予定を設定し、それをサービスに送信することを許可します。この結果、Bob がこれらの操作のために Alice のカレンダー サービスにアクセスするときに、Alice からの委任セキュリティ トークンが必要ではなくなります。
上記の委任のシナリオでは、悪意を持つ人が委任セキュリティ トークンを使わずに会議の予定を設定したり、有効期限の切れたセキュリティ トークンを使って会議の予定を設定することが可能になります。このような場合、悪意を持つ人は必要な申告を証明できないので、要求は失敗するでしょう。
この種の利用状況を監視するために、サービスは監査機能を提供できます。つまり、認証などのセキュリティ関連のイベント、証明されていない申告、または不適切な署名が発生すると、ログに記録されます。管理者はこのログに安全にアクセスし、セキュリティ関連のイベントの調査や、ログの管理を行えます。
たとえば、悪意を持つ人が Bob になりすまそうとしています。セキュリティ管理者である Carol は、監視/管理ツールを使って、監査ログを調査し、Alice の予定表に多くのセキュリティの障害があることを申告します。Carol はそのデータの調査で、Bob の署名がメッセージと一致しないか、メッセージが古い (再送されている) ので Bob の要求がときどき失敗していることを申告します。その結果、Carol は悪意のある人を突き止めるために使用する監査レコードを収集します。
Web サービスがより広範に適用されるようになるにつれ、アプリケーション トポロジがファイアウォール、負荷分散、メッセージング ハブなどの中間ノードをサポートするために進化し続けるにつれ、さらに組織が直面する脅威に対する認識がより適切に理解されるようになるにつれ、Web サービスの新たなセキュリティ仕様の必要性がますます明白になります。このドキュメントでは、統合 Web サービス セキュリティ モデルと、そのモデルを実現するための仕様のセットを提案しています。これらの新しい仕様は、既存のセキュリティ テクノロジや資産を (置き換えるのではなく) 拡張および応用することにより、ユーザや組織がセキュアで、相互運用可能な Web サービスをより迅速に開発することを可能にするでしょう。
IBM と Microsoft は、これが包括的 Web サービス セキュリティの方策を定義する最初の手順になると確信しています。このドキュメントはこれまでに認識された課題やソリューションを反映しています。IBM と Microsoft は、セキュアな Web サービスにするためにユーザ、パートナー、および標準化組織との共同作業を続けていくと同時に、この方策を完全なものにするために必要な新たな考え方や仕様が出てくることを期待しています。
このドキュメントは IBM と Microsoft の共同で執筆されました。
主な寄稿者は次のとおりです (アルファベット順)Giovanni Della-Libera (Microsoft)、Brendan Dixon (Microsoft)、Joel Farrell (IBM)、Praerit Garg (Microsoft)、Maryann Hondo (IBM)、Chris Kaler (Microsoft)、Butler Lampson (Microsoft)、Kelvin Lawrence (IBM)、Andrew Layman (Microsoft)、Paul Leach (Microsoft)、John Manferdelli (Microsoft)、Hiroshi Maruyama (IBM)、Anthony Nadalin (IBM)、Nataraj Nagaratnam (IBM)、Rick Rashid (Microsoft)、John Shewchuk (Microsoft)、Dan Simon (Microsoft)、Ajamu Wesley (IBM)
- [Kerberos]
- J. Kohl and C. Neuman, "The Kerberos Network Authentication Service (V5),"RFC 1510, September 1993,http://www.ietf.org/rfc/rfc1510.txt.
- [SOAP]
- W3C Note, "SOAP: Simple Object Access Protocol 1.1," 08 May 2000.
- [URI]
- T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax,"RFC 2396, MIT/LCS, U.C. Irvine, Xerox Corporation, August 1998.
- [XML-C14N]
- W3C Recommendation, "Canonical XML Version 1.0," 15 March 2001.
- [XML-Encrypt]
- W3C Working Draft, "XML Encryption Syntax and Processing," 04 March 2002.
- [XML-ns]
- W3C Recommendation, "Namespaces in XML," 14 January 1999.
- [XML-Schema1]
- W3C Recommendation, "XML Schema Part 1: Structures," 2 May 2001.
- [XML-Schema2]
- W3C Recommendation, "XML Schema Part 2: Datatypes," 2 May 2001.
- [XML Signature]
- W3C Proposed Recommendation, "XML Signature Syntax and Processing," 20 August 2001.
- [WS-Routing]
- H. Nielsen, S. Thatte, "Web Services Routing Protocol ," Microsoft Corporation, October 2001.
- [X509]
- S. Santesson, et al, "Internet X.509 Public Key Infrastructure Qualified Certificates Profile,"http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=T-REC-X.509-200003-I.
タグ
スライダーバーを使用することで、より多く（少なく）タグを表示します。
人気のタグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するトップのタグを表示します。
マイ・タグは、この特定のコンテンツ・ゾーン（例えば、Java テクノロジー、Linux や WebSphere など）に対するお客様ご自身のタグを表示します。
記事の人気タグ |
記事のマイ・タグタグ・リストへスキップ
記事の人気タグ |
記事のマイ・タグ