IBM、MS、Verisignは、4月に共同でWeb Services Security (WS-Security) の仕様を公開しました。これは、Webサービスの開発者がセキュアにSOAPメッセージ交換するための一連のメカニズムを提供するものです。この仕様はOASISの承認を受けており、WS-Securityをオープン規格に移行させるために新しいWeb Services Technical Committee (WSS TC)が形成されました。WS-Security仕様は、以前のホワイト ペーパー、Webサービスのセキュリティー: アーキテクチャーとロードマップの提案 (参考文献を参照) に詳しく説明されています。

これに加えて、4月にIBMとMicrosoftでは、ロードマップ文書を提供しています。そこには、Webサービスにセキュリティーを組み込むのに重要な追加要素を明らかにした概念スタックが含まれています。

この発表の焦点となるのは、ロードマップのさらに3つの部分の提示です。つまりポリシー・レイヤーの2つの要素とフェデレーション・レイヤーの1つの要素です (図1 を参照)。

ポリシー

WS-Policyラベルの付いたロードマップのポリシー要素は、さらに以下の4つの文書に細分化されています。

• Webサービス・ポリシーを表現するための文法を定義したPolicy Framework(WS-Policy)
• これらのポリシーをWebサービスに付与する方法を定義したPolicy Attachment(WS-Policy-Attachment) 文書
• 1組の汎用ポリシー表明 (WS-Policy-Assertions)
• 1組のセキュリティー・ポリシー表明 (WS-Security Policy)

Policy Frameworkは拡張性を備えた設計になっています。ポリシーとは幅広い用語で、セキュリティー、信頼性、トランザクション、プライバシーなどの広範囲にわたります。同様に、ポリシーを表現する能力は、汎用ポリシーやセキュリティー・ポリシーの表現だけに限られません。基本ポリシー・フレームワークの意図は、一貫したWeb Services Framework内における異なるドメインの知識を活用できる方法で、ドメイン固有のポリシー言語の表現に適応できるようにすることです。

WS-PolicyAttachmentは、Webサービスに関するポリシー表明を公表するためのいくつかの方法を用意しています。これは、既存のWSDLおよびUDDI仕様の上に構築されたものですが、拡張性もサポートしています。

その上、Webサービス共通のポリシーに加えて、ドメイン固有のポリシー (たとえばセキュリティー・ポリシー) も考えられます。共通なポリシーの例として、特定の自然言語 (たとえばドイツ語) を処理するサービス・プロバイダーを探す要求サービスが挙げられます。要求サービスは、これを受けてポリシー表明、つまりドイツ語のサポートの必要性を付け加えます。プロバイダーは、ドイツ語のサービスを提供できることを公表することによってこの表明を行うこともできます。WS-Policy Assertions Languageは、この種の共通ポリシー表現を提供します。これは、Webサービス用のポリシー表明の汎用セットを定義するものです。

セキュリティーは1つのドメインであり、セキュリティー・ポリシーを表現するためには、別の文書 WS-Security-Policy で、WS-Security仕様のサポートに関連したポリシーをやり取りするのに必要なポリシーを表現する言語が提案されています。

上に戻る

信頼

Webサービスのパラダイムでは、サービス・リクエスターとサービス・プロバイダーとの信頼は、これら2者間によるあらかじめ決められた理解可能な方法での情報交換を通じて確立されます。WS-Security仕様では、すでにセキュリティー・トークンを使用してセキュアにメッセージを交換するための基本メカニズムが定義されています。WS-Trust仕様は、このようなセキュリティー・トークンの発行および交換方法を定義することによって、このモデルの上に構築されています。

WS-Trust は、信頼関係の定義という作業を、セキュア・トークン・サービスがセキュリティー・トークンの発行、交換、検査のために提供できる1組のインターフェースを定義することから始めます。これは、さまざまな認証および許可メカニズムに対応できるように、複数のセキュリティー・トークン形式の作成をサポートできる設計になっています。発行セキュリティー・トークン・サービスは、入力要求と通常はIDの証明とを要し、指定のIDが要求したトークン (つまり特定のビジネス証明) で応答します。

セキュリティー空間内におけるこのような予想動作の記述は、信頼ポリシーとして表現することができ、WS-Policy Frameworkでは、信頼パートナーがそれぞれの信頼ステートメントを表現したり交換したりすることをサポートしています。

上に戻る

セキュアな会話

WS-Secure Conversation は、信頼ベースのセキュリティー・トークンの概念を基に構築されています。これは、セキュリティー・トークンをどのように使用して、ポリシーで定義された信頼関係というコンテキスト内で、複数のサービス・リクエスターやサービス・プロバイダーが会話の継続を通じて情報をセキュアに交換できるかを説明したものです。WS-Trustが全体的な信頼関係の動作を定義しているのに対し、WS-SecureConversationではセキュアな会話のためのセキュリティー・コンテキスト (セキュリティー・トークン) の定義に重点を置いています。

WS-Policy、WS-Trust、WS-SecureConversationの適用

これらの概念を説明するために、旅行代理店のシナリオを取り上げてみましょう。Acme Travel Serviceでは、さまざまなビジネス・ポータルを通じて、顧客に航空券、ホテル、レンタカーなどの旅行サービスを提供しています。Acmeは、これらのポータルを通じてパートナーとさまざまな 信頼 関係を確立する必要があります。

Acmeでは、ホテル、航空券、車を1回の要求でサブミットできるような統合サービス・セットを顧客に提供したいと考えています。また、Acmeは、さまざまな基準 (ゴールド・サービス、得意客など) に基づいて、パートナーごとにサービスを拡張できる柔軟性を持たせたいと考えています。パートナーの1つ、Cars-R-Us用の ポリシー には、Cars-R-Usユーザー名トークンに対するセキュリティー・ポリシー要求と、予約に対するキャンセル・ポリシーを記したビジネス・アプリケーション要求が含まれる予定です。別のパートナーであるUnitedCars用のポリシーには、UnitedCarsの得意客番号に対する要求が含まれる予定です。

Acmeはさまざまなビジネス関係をサポートしているので、どの顧客向けにどの旅行サービスを呼び出すかを判別できる必要があります。Acmeが、その顧客の信頼済みのポータル環境の一部として統合旅行サービスを迅速かつセキュアに提供できるように信頼関係を自動化する上で、規格がどのように役立つのでしょうか。

Acmeは、すべてのパートナーに対する登録作業を自ら行い、顧客にAcmeUsernameおよびIDを発行することができます。このケースでは、Acmeはパートナーに対しシステム機能の利用を許可しています。要求を処理する前に、AcmeはパートナーであるCars-R-Usのポリシーをチェックし、顧客に対しキャンセル・ポリシーの通知を行ってから、要求を処理すべきかどうかをたずねます。承認された後、このID、プライバシー、その他のビジネス・ポリシーに基づいて、その要求に追加のセキュリティー・トークンが (Acmeによって) 付加される可能性があります (Juserはxyz社の従業員で、クレジット制限が10,000米ドルのゴールド・サービスを付与されているなど)。Acmeは、旅行サービス会社との信頼関係を確立し、それぞれの予約要求にどの追加トークンを供給する必要があるか明らかにする必要があります。

あるいは、Acmeはちょうど手形交換所のように機能することもできます。つまり、各ユーザーからの要求を任意のパートナー渡すことによってすべての要求をリダイレクトして、そのパートナーにユーザーの認証およびその顧客へのポリシー通知を行わせるようにすることができます。Acmeは、クリアリングハウスとして広告収入を得ることができますが、旅行サービスとしても価値を提供する必要があります。この2番目のシナリオでは、Acmeは新規ビジネス・パートナーにセキュリティー・トークン・サービスを提供することができるでしょう。ユーザー情報の管理をアウトソースしたいと考えるCars-R-Usでは、独自のクレジット処理を行わずに済むことに利点を見出し、それぞれの認証要求を受け付け、セキュリティー・トークン・サービスを呼び出すことによってAcmeからクレジット承認を読み出すという、Acmeの追加サービスの利用を選択する可能性があります。

クレジット・サービスには、追加的なセキュリティー尺度が必要となる場合があり、WS-SecurityPolicy表明には、(WS-Security仕様に忠実な) AcmeとCars-R-Usとが、互いのメッセージで提供しなければならない追加セキュリティー・ポリシーを表現できる機能が用意されています。たとえば、Cars-R-Usでは、すべてのクレジット表明がディジタル署名付きで有効期限時刻が含まれていることを要するかもしれません。

参考文献

• Webサービスのセキュリティー: アーキテクチャーとロードマップの提案 では、Web Services Securityモデルについて詳しく説明されています。
  
  
• Web Services Security仕様 をダウンロードしてください。
  
  
• Web Services Policy Framework仕様 をダウンロードしてください。
  
  
• Web Services Policy Attachments仕様 をダウンロードしてください。
  
  
• Web Services Policy Assertions Language仕様 をダウンロードしてください。
  
  
• Web Services Trust Language仕様 をダウンロードしてください。
  
  
• Web Services Security Policy Language仕様 をダウンロードしてください。
  
  
• Web Services Secure Conversation Language仕様 をダウンロードしてください。
  
  
• IBMでは、 セキュア・ビジネス・インテグレーションのソリューション をご提案しています。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• ポリシー
• 信頼
• セキュアな会話
• 参考文献
• 著者について
• コメント