(57)【要約】【課題】認証と、サービスの発見、アクセス・ポリシーの評価、および符号付きセキュリティ・トークンでのこのプロセスの結果を入手することを組み合わせて取り入れることによって、各サービス要求を安全な方法で効率よく処理することができるようにするスケーラブル・ポリシーベースＷｅｂ  Ｓｅｒｖｉｃｅセキュリティ・アーキテクチャを提供すること。【解決手段】Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にする方法は、サービス要求に応えてＷｅｂ  Ｓｅｒｖｉｃｅを発見し、サービス要求に基づく実際のサービスとは別にＷｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーを決定することを含む。【選択図】図１
2005354679.tif 000002
【特許請求の範囲】
【請求項１】
サービス要求に応えてＷｅｂ  Ｓｅｒｖｉｃｅを発見すること、および
前記Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーを前記サービス要求に基づく実際のサービスとは別に決定することを含む、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にする方法。
【請求項２】
前記Ｗｅｂ  Ｓｅｒｖｉｃｅを発見した後に１つまたは複数の呼出しを前記Ｗｅｂ  Ｓｅｒｖｉｃｅに送信することを含む、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にする方法。
【請求項３】
前記Ｗｅｂ  Ｓｅｒｖｉｃｅのための前記アクセス・ポリシーを前記サービス要求に基づく実際のサービスとは別に決定することが、
事前計算されたポリシーを使用することをさらに含む、請求項１に記載の方法。
【請求項４】
事前計算されたポリシーを使用することが、
Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーを評価して、ＩＤおよびアクセス・ポリシー情報を決定すること、および
前記ＩＤおよびアクセス・ポリシー情報を前記事前計算したポリシーに基づいてセキュリティ・トークンに符号化することをさらに含む、請求項３に記載の方法。
【請求項５】
ネットワークに結合されてサービス要求に対応するウェブ・サーバのためのプログラミング命令を含むコンピュータ可読媒体であって、前記ウェブ・サーバが複数のクライアントにリンクされており、前記プログラミング命令が、
サービス要求に応えてＷｅｂ  Ｓｅｒｖｉｃｅを発見すること、および
前記Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーを前記サービス要求に基づく実際のサービスとは別に決定することを含む、コンピュータ可読媒体。
【請求項６】
ネットワークを介してウェブ・サーバにリンクされた複数のクライアントにＷｅｂ  Ｓｅｒｖｉｃｅを提供するためのウェブ・サーバであって、
ＩＤおよびアクセス・ポリシー情報を格納するキャッシュに結合されるインターフェースと、
アクセス・ポリシーを評価し、その決定をセキュリティ・トークンに符号化するポリシー・エンジンを備えたアクセス制御装置と、
サービス要求に基づく実際のサービスとは別にＷｅｂ  Ｓｅｒｖｉｃｅのために決定されたアクセス・ポリシーに基づいてＷｅｂ  Ｓｅｒｖｉｃｅを安全にするモジュールとを含む、ウェブ・サーバ。
【請求項７】
前記モジュールが前記サービス要求に応えて前記Ｗｅｂ  Ｓｅｒｖｉｃｅを発見する、請求項６に記載のウェブ・サーバ
【請求項８】
前記モジュールが前記Ｗｅｂ  Ｓｅｒｖｉｃｅを発見した後に１つまたは複数の呼出しを前記Ｗｅｂ  Ｓｅｒｖｉｃｅに送信する、請求項６に記載のウェブ・サーバ
【請求項９】
Ｗｅｂ  Ｓｅｒｖｉｃｅを求めるサービス要求をネットワークを介して送信するクライアントと、
前記ネットワークに結合され、事前計算されたポリシーに基づいて様々な管理可能ドメインにわたって前記Ｗｅｂ  Ｓｅｒｖｉｃｅを提供するウェブ・サーバとを含む、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にするシステム。
【請求項１０】
複数のクライアントのネットワークにリンクされたサーバに関する方法であって、
クライアントからサービス要求を受信すること、
前記サービス要求に応えて、第１のアクセス制御装置要素を使用してサービスを発見すること、および
アクセス制御の実施を前記サービス要求に基づく実際のサービスから分離させる第２のアクセス制御要素を使用することを含む方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は一般に、電気通信に関し、より詳細には無線通信に関する。
【背景技術】
【０００２】
Ｗｅｂ  Ｓｅｒｖｉｃｅなどのサービスを提供する場合、こうしたサービスの提供におけるセキュリティは主要な懸念の１つである。たとえばセキュリティは、様々な法律に従って、収益を保証かつ保護するためにきわめて重要である。換言すれば、セキュリティは、サービスに基づいてビジネスを行う会社全てに不可欠である。リクエスタ、膨大な量の文献、標準化、解、アーキテクチャなどへの安全なサービスの提供が、多くの会社によって開発され提案されている。
【０００３】
しかし、安全な環境を提供して、複数の企業およびインターネットにわたって組織内にサービスをもたらすことは、認証、許可、プライバシ、信用、完全性、秘密性、アプリケーションおよびビジネス・トポロジの広範なスペクトルにわたる安全な通信チャネルに関わることである。したがって、安全なサービスを可能にする機構には、技術（安全なメッセージング）とビジネス・プロセス（政策、リスク、信用）の問題の両方に対する解決策が必要であるが、それには、プラットフォーム・ベンダ、アプリケーション開発者、ネットワーク並びにインフラストラクチャの提供者、および顧客による努力の調和が必要とされる。ゆえに、課題の１つは、発展するネットワークおよび次世代アプリケーションにわたるＳｅｒｖｉｃｅ  Ｄｅｌｉｖｅｒｙ  ＰｌａｔｆｏｒｍｓおよびＩｎｔｅｌｌｉｇｅｎｔ  Ｎｅｔｗｏｒｋｓ配信の安全なサービスである。さらに、安全付加価値サービスを発展させて優位な利点を生み出し、新しい収益の流れを確保することが別の課題である。
【０００４】
一般にＷｅｂ  Ｓｅｒｖｉｃｅｓは、データを交換する目的で他のウェブ・アプリケーションと対話するウェブ・アプリケーションに基づくオープンスタンダード（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）、Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）など）である。Ｗｅｂ  Ｓｅｒｖｉｃｅは、最初は大規模民間企業ネットワーク上でデータを交換するために使用されていたが、公開インターネットを介したトランザクションを含むものに発展した。たとえば、Ｌｕｃｅｎｔ  ＴｅｃｈｎｏｌｏｇｉｅｓのＭｉＬｉｆｅ（商標）ＶｏｉｃｅＸＭＬ  Ｇａｔｅｗａｙは、音声可能なＷｅｂ  Ｓｅｒｖｉｃｅｓへの電話アクセスを提供している。それは、ウェブ・サーバからのＶｏｉｃｅＸＭＬ定様式内容を検索し、それを固定または移動電話を介してエンド・ユーザとの対話式音声会話に変換するものである。
【０００５】
サービス提供者、電気通信オペレータ、およびＩＴ部門は全て、サービス・インターフェースを指定し提供するための標準化された基本技術としてＷｅｂ  Ｓｅｒｖｉｃｅを使用し始めている。こうしたインターフェースの開発者は全て、重要な問題に対処しなければならない。すなわち、誰（どの当事者）がどのような条件下でこうしたインターフェースにアクセスするかという問題である。関連問題は、リクエスタ（発信者）の改ざん防止ＩＤ、アクセス権および規制の機械可読かつ実装可能な仕様、およびクロスドメイン操作を可能にすることである。
【０００６】
Ｃｏｒｅ  Ｗｅｂ  Ｓｅｒｖｉｃｅ仕様には、ＳＯＡＰおよびＷｅｂ  Ｓｅｒｖｉｃｅｓ  Ｄｅｆｉｎｉｔｉｏｎ  Ｌａｎｇｕａｇｅ（ＷＤＳＬ）が含まれているが、どちらも２０世紀の終り頃に標準化されたものである。この標準は両方共、ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＭＬ）に基づく構文を使用して、それぞれＷｅｂ  Ｓｅｒｖｉｃｅを呼び出す方法を指定する。その後、Ｗｅｂ  Ｓｅｒｖｉｃｅに関連するセキュリティ問題の様々な側面に対処する幾つかの標準が作られてきた。これには、ＷＳ−Ｓｅｃｕｒｉｔｙ、ＸＭＬシグニチャなどが含まれる。たとえば、Ｘ．５０９ｖ３証明書は、リクエスタと対象のサービス提供者の両方の相互ＩＤに使用することができる。ＨＴＴＰＳは、このコンテキストに適した移送プロトコルである。Ｋｅｒｂｅｒｏｓは、リソースへの認証済みアクセスに符号付きトークンを使用するアーキテクチャであり、ｅＸｔｅｎｓｉｂｌｅ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＸＡＣＭＬ）は、ポリシーおよびポリシー決定要求／返答を表すために使用されるＸＭＬ形式である。最後に、Ｓｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＳＡＭＬ）は、リクエスタのＩＤを含む（光学的に符号が付けられた）ＸＭＬトークンのための形式を指定する他の仕様である。
【０００７】
ＳＯＡＰメッセージのルーティング、確実なデータ転送、ファイアウォール走査などが問題になっているが、ＳＯＡＰは、ＳＯＡＰで伝送する任意のアプリケーション固有のデータのセマンティクスについて沈黙している。ＳＡＭＬはＩＤと認証情報を含む符号付きトークンの概念を導入する。しかし、ＳＯＡＰはこのトークンをより大きいコンテキストで使用する方法、または効率およびステーラビリティの利便性を高めるためにトークンとサービスの発見とを組み合わせる方法を指定していない。さらに、ＳＡＭＬは、サービスにアクセスするたびに要求への応答に基づくプロトコルを使用することを提案している。要約すれば、ＳＡＭＬはプロトコル仕様であってアーキテクチャまたは解決策ではない。したがって、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのスケーラブルなアクセス制御フレームワークを実装する明瞭かつ説得力のある解決策を提供するアーキテクチャは、多くの標準仕様で欠けた部分である。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
本発明は、上記で述べた１つまたは複数の問題の影響を克服し、または少なくとも低減することを目的とする。
【課題を解決するための手段】
【０００９】
本発明の一実装形態では、アクセス制御ポリシーを実際のサービスから分離するＷｅｂ  Ｓｅｒｖｉｃｅを安全にする方法を提供する。この方法は、サービス要求に応えてＷｅｂ  Ｓｅｒｖｉｃｅを発見し、サービス要求に基づく実際のサービスとは別に、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーを決定することを含む。
【００１０】
他の実装形態では、ネットワークに結合されてサービス要求に対応するウェブ・サーバのためのプログラミング命令を含むコンピュータ可読媒体を提供する。ウェブ・サーバは、複数のクライアントにリンクされる。プログラミング命令は、サービス要求に応えてＷｅｂ  Ｓｅｒｖｉｃｅを発見し、サービス要求に基づく実際のサービスとは別に、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーを決定することを含む。
【００１１】
他の実装形態では、ネットワークを介してリンクされた複数のクライアントにＷｅｂ  Ｓｅｒｖｉｃｅを提供するウェブ・サーバは、ＩＤおよびアクセス・ポリシー情報を格納するためのキャッシュに結合されたインターフェース、アクセス・ポリシーを評価しその決定をセキュリティ・トークンに符号化するためのポリシー・エンジンを備えたアクセス制御装置、およびサービス要求に基づく実際のサービスとは別に決定されたＷｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーに基づいてＷｅｂ  Ｓｅｒｖｉｃｅを安全にするモジュールを備える。
【００１２】
他の実装形態では、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にするシステムは、Ｗｅｂ  Ｓｅｒｖｉｃｅを求めるサービス要求をネットワークを介して送信するクライアント、およびネットワークに結合されて事前計算されたポリシーに基づいて様々な管理可能ドメインにわたってＷｅｂ  Ｓｅｒｖｉｃｅに対応するウェブ・サーバを含む。
【００１３】
他の実装形態では、複数のクライアントのネットワークにリンクされたサーバに関する方法は、クライアントからサービス要求を受信し、サービス要求に応えて第１のアクセス制御装置要素を使用してサービスを発見し、サービス要求に基づく実際のサービスとアクセス制御強制を分ける第２のアクセス制御装置要素を使用することを含む。
本発明は、添付の図面と併せて、以下の説明を参照すれば理解されるであろう。図面では、同様の参照番号は、同様の要素を示す。
【発明を実施するための最良の形態】
【００１４】
本発明の例示の実装形態を以下で説明する。明瞭にするために、実際の実装形態の特徴全てはこの明細書に記載しない。当然理解されるように、任意のこうした実際の実装形態を開発する際は、開発者の特定の目的を達成するには、システム関連およびビジネス関連の制約などに従って、多数の実装固有の決定をしなければならず、それは実装形態によって変わるものである。さらに、理解されるように、こうした開発努力は複雑で時間を要することもあるが、それでもなお本開示の恩典を有する当業者には日常的業務であろう。
【００１５】
一般に、既存のネットワーク要素、プロトコル、および概念の組合せを取り入れたスケーラブル・ポリシーベース・ウェブサービス・セキュリティ・アーキテクチャが提供されている。ウェブサービス・セキュリティ・アーキテクチャでは、認証と、サービスの発見、アクセス・ポリシーの評価、および各サービス要求を効率よく処理できるようにする符号付きセキュリティ・トークンでこのプロセスの結果を入手することを組み合わせて使用することが有利である。本発明の一実装形態によれば、スマートＵｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ、Ｄｉｓｃｏｖｅｒｙ  ａｎｄ  Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）要素に接続されたポリシー・エンジンは、アクセス・ポリシーを評価し、その決定をセキュリティ・トークンに符号化する。決定を行うために必要とされる情報全てをセキュリティ・トークン自体に符号化することによって、Ｗｅｂ  Ｓｅｒｖｉｃｅにスケーラブル・アクセス制御フレームワークが提供される。その結果、事前計算されたポリシーが得られる。アクセス制御装置は、この事前計算されたポリシーを使用して、実際の要求のコンテキストにおけるアクセス状態を評価する。こうすると、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのスケーラブル・アクセス制御フレームワークを実装することができる。
【００１６】
本発明の一実装形態によれば、サービス要求に応えてＷｅｂ  Ｓｅｒｖｉｃｅが発見される。たとえば、ウェブ・サーバに存在するディスカバリ文書にＵｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）が与えられると、クライアント・アプリケーション開発者は、Ｗｅｂ  Ｓｅｒｖｉｃｅが存在すること、その能力、および適切な対話方法を学ぶことができる。このプロセスは、Ｗｅｂ  Ｓｅｒｖｉｃｅの発見として周知であり、Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｄｉｓｃｏｖｅｒｙ  Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）照会Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）に基づいてサービスを捜し出すことができる。しかし、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーは、サービス要求に基づく実際のサービスとは別に決定される。認証およびアクセス・ポリシー評価のコストは、Ｗｅｂ  Ｓｅｒｖｉｃｅシステムでの多くのサービス要求によって償却することができる。Ｓｉｍｐｌｅ  Ｏｂｊｅｃｔ  Ａｃｃｅｓｓ  Ｐｒｏｔｏｃｏｌ（ＳＯＡＰ）およびＳｅｃｕｒｉｔｙ  Ａｓｓｅｒｔｉｏｎ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ（ＳＡＭＬ）に基づくＷｅｂ  Ｓｅｒｖｉｃｅシステムを、様々な管理可能ドメインにわたるＷｅｂ  Ｓｅｒｖｉｃｅに対する安全な細粒度のアクセス制御のコンテキストで本明細書に記載する。しかし当業者には理解されるように、本発明の原理は他のＷｅｂ  Ｓｅｒｖｉｃｅシステムにも適用することができる。
【００１７】
次に図面に移り、具体的に図１を参照すると、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にするために使用することができるシステム１００の様式的表示が示されている。システム１００は、ネットワーク１１０を介してウェブ・サーバ１１５にリンクされた複数のリクエスタ・クライアント１０５を含む。本発明の一実装形態によれば、ウェブ・サーバ１１５は、サービス要求に基づく実際のサービスとは別に決定された、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシー１２５に基づいてＷｅｂ  Ｓｅｒｖｉｃｅを安全にするためのＷｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０を含む。アクセス・ポリシー１２５は、１組のドメイン固有のポリシー・ステートメントでもよく、その場合、ポリシー・ステートメントは、ポリシー表明が個々のプリファランス、要求、能力などを示すことができる１グループのポリシー表明でもよい。たとえば一実装形態で、音声可能なＷｅｂ  Ｓｅｒｖｉｃｅへのポリシーベースの電話アクセスを提供することができる。
【００１８】
図２を参照すると、本発明の一実装形態によるＷｅｂ  Ｓｅｒｖｉｃｅを安全にするための方法が様式的に示されている。ブロック２００で、サービス要求に基づいてＷｅｂ  Ｓｅｒｖｉｃｅが、Ｗｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０によって発見される。Ｗｅｂ  Ｓｅｒｖｉｃｅが発見されると、ブロック２０５で、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシー１２５がサービス要求とは別に決定される。ブロック２１０で、サービス要求を効率よく処理するために、本発明の一実装形態に従って、Ｗｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０は、認証およびアクセス・ポリシー評価のコストを多くのサービス要求によって償却することができる。
【００１９】
一実装形態では、Ｗｅｂ  Ｓｅｒｖｉｃｅの発見および選択のためのＷｅｂ  Ｓｅｒｖｉｃｅの登録は、動的サービス・ロード情報を定期的に更新する通常のＵＤＤＩの場合と同様に進められる。Ｗｅｂ  Ｓｅｒｖｉｃｅリクエスタ、すなわちリクエスタ・クライアント１０５は、ＵＤＤＩレジストリに接続される。ＵＤＤＩレジストリは（図３および４で示したように）ＵＤＤＩモジュールの一部でもよく、認証するものである。Ｗｅｂ  Ｓｅｒｖｉｃｅリクエスタは、レジストリ・サービス発見基準を送信する。ＵＤＤＩレジストリは、認証されたＩＤと共に探索基準を一要因として含め、ポリシー（たとえばアクセス・ポリシー１２５）をＷｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０に適用する。
【００２０】
一実装形態に従って、ＵＤＤＩレジストリは、Ｕｎｉｖｅｒｓａｌ  Ｄｅｓｃｒｉｐｔｉｏｎ  Ｄｉｓｃｏｖｅｒｙ  Ｉｎｔｅｇｒａｔｉｏｎ（ＵＤＤＩ）標準によって開発された仕様に基づいて実装することができる。ＵＤＤＩレジストリは、Ｗｅｂ  Ｓｅｒｖｉｃｅをサポートするインフラストラクチャのコア要素である。ＵＤＤＩレジストリは、会社に提供されるビジネスおよびサービスを登録するための場所を提供する。Ｗｅｂ  Ｓｅｒｖｉｃｅなどサービスを必要とする人またはビジネスは、このレジストリを使用して、そのサービスを提供するビジネスを見つけることができる。
【００２１】
次に、ＵＤＤＩレジストリは、サービス・チケットを生成し、発見したサービスのリストと共にそれをＷｅｂ  Ｓｅｒｖｉｃｅリクエスタ（たとえばリクエスタ・クライアント１０５）に戻す。Ｗｅｂ  Ｓｅｒｖｉｃｅリクエスタは、（サービスによって）認証または非認証接続を介してＷｅｂ  Ｓｅｒｖｉｃｅに接続され、チケットを提示する。その後、サービス要求応答の対話が進行する。Ｗｅｂ  Ｓｅｒｖｉｃｅは、要求が処理されると、チケットの符号付き情報を使用する（すなわち、チケットが「事前計算された」ポリシーを含む）。
【００２２】
Ｗｅｂ  Ｓｅｒｖｉｃｅの発見および選択を完了するには、一実装形態では、所有権を主張できる追加のＨＴＴＰヘッダを使用して、この新しい情報を符号化することができる。あるいは、Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｒｃｅ  Ｌｏｃａｔｏｒ（ＵＲＬ）を追加のパラメータ（たとえばＦＡＴ  ＵＲＬ）と共に符号化することができる。いずれの場合も、使用される特定のパラメータは暗号化され、または他の方法では、ウェブ・サーバ１１５およびＷｅｂ  Ｓｅｒｖｉｃｅに選択的にアクセス可能になされる。
【００２３】
他の実装形態では、バックオフィス・チャネルをＷｅｂ  Ｓｅｒｖｉｃｅ発見および選択プロセスに使用することができる。バックオフィス・チャネル通信は、チケットと同じ情報を含むことができる。しかし、ＵＤＤＩレジストリが認証されたＩＤと共に探索基準を要因として含め、ポリシーを適用した後、ＵＤＤＩレジストリは発見したサービスのリストをＷｅｂ  Ｓｅｒｖｉｃｅリクエスタに戻す。Ｗｅｂ  Ｓｅｒｖｉｃｅリクエスタは、Ｗｅｂ  Ｓｅｒｖｉｃｅに接続され、要求を生成する。Ｗｅｂ  Ｓｅｒｖｉｃｅは、ローカル・ポリシーを適用し、またはＵＤＤＩレジストリにバックオフィス・チャネルを介して接続され、処理情報を要求する。こうすると、要求が処理され、応答が戻される。
【００２４】
本発明の一実装形態では、Ｗｅｂ  Ｓｅｒｖｉｃｅが発見された後、Ｗｅｂ  Ｓｅｒｖｉｃｅに対する１つまたは複数の呼出しを送信することができる。事前計算されたポリシーは、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシー１２５を決定するために、ウェブ・サーバ・セキュリティ・モジュール１２０によって使用される。こうすると、Ｗｅｂ  Ｓｅｒｖｉｃｅのためのアクセス・ポリシーが評価されて、Ｗｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０によってＩＤおよびアクセス・ポリシー情報が決定される。ＩＤおよびアクセス・ポリシー情報を事前計算したポリシーに基づいてセキュリティ・トークンに符号化することができる。本発明の一部の実装形態では、Ｗｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０は、符号付きセキュリティ・トークンでセキュリティ・トークンを捕獲して、それぞれ後続のサービス要求に使用することができる。
【００２５】
図３を参照すると、本発明の一実装形態による、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にするためのＷｅｂ  Ｓｅｒｖｉｃｅシステム３００が示されている。本発明の一実装形態によれば、リクエスタ・クライアント１０５は、クライアントＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇ  Ｉｎｔｅｒｆａｃｅ（ＡＰＩ）３２０を使用してアプリケーション・サーバ上でクライアント・アプリケーション３１０を稼動することができるリクエスタ３０５を含むことができる。ネットワーク１１０は、メッセージをリクエスタ・クライアント１０５からウェブ・サーバ１１５に送るネットワーク・リソースを含むことができる。ネットワーク・リソースは、通信ネットワーク３５０のプロトコル３３０およびネットワーク要素３３５を含むことができる。
【００２６】
Ｗｅｂ  Ｓｅｒｖｉｃｅシステム３００で展開することができるプロトコル３３０の１つはＳＯＡＰである。ＳＯＡＰプロトコル（たとえばバージョン１．２）は、ＸＭＬベースの情報の定義を提供し、この定義は、構造化かつ型付けされた情報を非集中分散環境のピア間で交換するのに使用することができる。ＳＯＡＰプロトコルは基本的にはステートレスで一方通行のメッセージ交換パラダイムであるが、こうした一方通行の交換を基礎となるプロトコルおよび／またはアプリケーション固有の情報によって提供されるフィーチャと組み合わせることによって、アプリケーションが（たとえば要求／応答、要求／複数の応答など）より複雑な対話パターンを生成することができるようになる。ＳＯＡＰプロトコルは、アプリケーション固有情報を拡張可能な方法で送ることができるフレームワークを提供する。また、ＳＯＡＰプロトコルは、ＳＯＡＰメッセージを受信したときに、ＳＯＡＰノードが取る要求された動作の記述を提供する。
【００２７】
ＳＯＡＰプロトコルは、その全てまたは一部に誰が対処すべきであるか、またこうした部分の処理が任意選択であるかまたは必須であるかを確認するＳＯＡＰメッセージ（たとえばメッセージ３２５）の内容を表すためのフレームワーク全体を定義付ける構成体であるＳＯＡＰエンベロープを定義する。ＳＯＡＰプロトコルは、他の基礎となるプロトコルへのＳＯＡＰのバインディングのための仕様を書き込む方法を記述するプロトコル・バインディング・フレームワークも定義する。ＳＯＡＰプロトコルはさらに、データ・モデル、リモート・プロシージャー・コール（ＲＰＣ）の移送に使用することができるデータ・タイプの特定の符号化方式、並びに基礎となるプロトコル・バインディング・フレームワークの具体的実現を定義付ける。このバインディングによって、ＨＴＴＰ  ＰＯＳＴ要求および応答のペイロードとして、またはＨＴＴＰ  ＧＥＴに応えるＳＯＡＰメッセージとして、ＳＯＡＰメッセージの交換が可能になる。
【００２８】
本発明の一実装形態によれば、アプリケーション・サービス提供者３６０のためのウェブ・サーバ１１５は、インテリジェント・サービス・ゲートウェイ３７０に結合されたサービス機能サーバ３６５を含むことができる。このサービス機能サーバ３６５は、ポリシー・エンジン３８０、スマートＵＤＤＩ３８５、およびデプロイド・サービス３９０を含むアクセス制御装置３７５を備えることができる。アクセス制御装置３７５は、アクセス・ポリシー１２５を認証し実装することができ、ポリシー・エンジン３８０はアクセス・ポリシーを評価し、その決定をセキュリティ・トークンに符号化することができる。より具体的には、スマートＵＤＤＩ３８５は、ポリシーを認証し、許可し、適用し、各サービス・インスタンスの動的情報を追跡し応答を戻すことによってロードのバランスをとる。Ｗｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０は、認証し、サービスを提供し、クライアント・アプリケーション３１０は認証し、要求する。
【００２９】
ＵＤＤＩ仕様に基づくスマートＵＤＤＩ３８５は、ビジネスが迅速に容易に動的に互いを見つけて取引することができるようにする。スマートＵＤＤＩ３８５は、ビジネスが、（ｉ）そのビジネスおよびそのサービスを記述し、（ｉｉ）所望のサービスを提供する他のビジネスを発見し、（ｉｉｉ）こうした他のビジネスを統合することができるようにする。たとえば、ＵＤＤＩレジストリ専用の実装は、ＵＤＤＩ仕様に従い、イントラネット、エクストラネット、またはインターネット上の専用ネットワーク内に存在するものである。それによって、許可されたユーザの特定のセット向きの、またはそれに適合された機能およびサービスを提供することができる。
【００３０】
Ｗｅｂ  Ｓｅｒｖｉｃｅセキュリティ・モジュール１２０は、アクセス・ポリシー１２５に基づき、ポリシー・エンジン３８０によって指示されたアクセス・ポリシーに従って、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にすることができる。インテリジェント・サービス・ゲートウェイ３７０は、キャッシュ３９７に結合されたサーバＡｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍｍｉｎｇインターフェース（ＡＰＩ）３９５を含むことができる。サーバＡＰＩ３９５は、クライアント・アプリケーション３１０との通信を可能にし、キャッシュ３９７はＩＤおよびアクセス・ポリシー情報を格納することができる。
【００３１】
操作では、アプリケーション・サーバ３１５に存在するクライアント・アプリケーション３１０は、サーバＡＰＩ３９５を通る通信ネットワーク３５０を介してクライアントＡＰＩ３２０を使用してサービス機能サーバ３６５にアクセスすることができる。ＡＰＩ３２０と３９５の両方は、クライアント・アプリケーション３１０とサービス機能サーバ３６５の間の通信手段を提供し、ネットワーク要素３３５上でプロトコル３３０を使用して１つまたは複数のメッセージ３２５が通信ネットワーク３５０を介して伝送されるようにする。こうすると、クライアント・アプリケーション３１０は、プロトコル３３０およびネットワーク要素３３５が含まれるが、それだけに限定されない、基礎となるネットワーク・リソースから独立することができる。本発明の一実装形態によれば、サービス機能サーバ３６５は、クライアント・アプリケーション３１０にサービス機能のフィーチャを提供することができる。
【００３２】
インテリジェント・サービス・ゲートウェイ３７０は、搬送波によって、アプリケーション・サービス提供者３６０またはサード・パーティ・クライアント・アプリケーション開発者にネットワーク・リソース（プロトコル３３０およびネットワーク要素３３５）を開放する標準の方法を提供することができる。こうすると、インテリジェント・サービス・ゲートウェイ３７０は、通信ネットワーク３５０の複雑性から、基礎となるネットワーク・リソースの詳細を隠し、アプリケーション開発者を防護することができる。
【００３３】
本発明の一実装形態によれば、インテリジェント・サービス・ゲートウェイ３７０は、サーバＡＰＩ３９５が基礎となるネットワーク・リソースに安全なアクセスを提供するための１組のＯｐｅｎ  Ｓｅｒｖｉｃｅｓ  Ａｒｃｈｉｔｅｃｔｕｒｅ（ＯＳＡ）方法を提供することができる。一実装形態では、サーバＡＰＩ３９５をＯＳＡ標準によって定義することができる。クライアント・アプリケーション３１０は、リクエスタ３０５からのサービス要求をインテリジェント・サービス・ゲートウェイ３７０に通信ネットワーク３５０上でクライアントＡＰＩ３２０を介して送信することができる。サービス機能サーバ３６５は、ネットワーク要素３３５と対話するためのインターフェースおよび機能を提供することができる。
【００３４】
クライアント・アプリケーション３１０の例には、ユーザＩＤの位置および呼のルーティングが含まれる。クライアント・アプリケーション３１０は、インテリジェント・サービス・ゲートウェイ３７０およびサービス機能サーバ３６５を使用して、ユーザの位置へのアクセスを有することができる。クライアント・アプリケーション３１０は、次いで、そのユーザが指定領域の外または中に移動したときに、クライアント・アプリケーションに知らせるためにサード・パーティに通知することができる。同様に、クライアント・アプリケーション３１０は、インターネット・ベースＷｅｂ  Ｓｅｒｖｉｃｅと呼のルーティングなどのインテリジェント・ネットワーク機能を組み合わせることができる。
【００３５】
有利には、本発明の一部の実装形態では、Ｗｅｂ  Ｓｅｒｖｉｃｅシステム３００は、電気通信サービス提供者に新しい付加価値サービスの機会を与えて、ウェブベースの開発を行い、内容をクライアント・アプリケーション３１０に配信する利点をもたらす。たとえば、音声ポータルおよびネットワークホスト・サービスは、プレミアム率表で使用される追加の数分間からの収益、エンド・ユーザ定期購読料金、および内容のパートナーとの合意を共有する収益を生み出すことができる。エンド・ユーザは、単純なユーザ・インターフェースを介してサービスへの汎用かつ容易なアクセス権を得る。専用かつ動的に更新されたインターネット内容を加入者に配信することによって、電話使用の秒数を増加し、より多くの顧客を保有できるようになる。インテリジェント・サービス・ゲートウェイ３７０アーキテクチャは、内容開発をサービス配信機構と分離させ、アプリケーション・サービス提供者３６０（たとえば電話機のオペレータ）および内容提供者（サービスの所有者）がその中核の専門知識に集中できるようにする。
【００３６】
図４を参照すると、本発明の一実装形態による、ウェブサービス・セキュリティ・アーキテクチャが示されている。このアーキテクチャでは、リクエスタ３０５は、サービスを発見してから、１つまたは複数のサービス呼出しをそのサービスに送る。すなわち、特定のサービス・アクセス・パターンが効率の利得を実現するために想定される。こうすると、発見が一回行われ、それに潜在的に多くのサービス呼出しが続いて行われる。その結果、比較的コストの高い認証およびアクセス・ポリシーの評価のコストを、多くのサービス要求によって償却することができる。したがって、コスト高の計算が発見プロセスの一部として１回行われる。こうした計算の結果を符号付きアクセス・トークンにキャッシュし、サービス呼出しごとに再使用することができる。
【００３７】
一実装形態では、ブロック４０５で示したように、ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  ｏｖｅｒ  ＳＳＬ  Ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＨＴＴＰＳ）に基づくＸ．５０９ｖ３などクライアント・サーバ証明書を使用して、リクエスタ３０５によるアクセス制御装置３７５に対するサービス要求に応えて、接続特性が形成される。一実装形態では、ＨＴＴＰプロトコルは、一方の端末部でＨＴＴＰクライアント・プログラムを使用し、他方の端末部でＨＴＴＰサーバ・プログラムを使用して、Ｗｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂまたはインターネット中でのハイパーテキスト・ファイルの移送を可能にする。
【００３８】
ブロック４１０で示したように、スマートＵＤＤＩ３８５はトークンを生成する。ブロック４１５で、スマートＵＤＤＩ３８５は、トークンに符号を付け、ＩＤを符号化する。ブロック４２０で示したように、リクエスタ３０５はそのトークンをサービス呼出しでデプロイド・サービス３９０に渡す。ブロック４２５で、アクセス制御装置３７５は、トークンを調べ、デプロイド・サービス３９０のためのアクセス・ポリシーを実装する。その結果、たとえば外部のデータベースに行き、または他のサーバに問い合わせる必要なく、各サービス要求のアクセス検査が効率的なローカル操作になる。すなわち、本発明の一実装形態によれば、サービス呼出し操作は、本質的にステートレスになる。これは、アクセス制御装置３７５およびデプロイド・サービス３９０が容易に複製されて、スケーラビリティが向上することを指す。
【００３９】
ブロック４３０で、リクエスタ３０５は、サービスを発見してから、１つまたは複数のサービス呼出しをそのサービスに送信する。ブロック４３５でトークンが戻され、ブロック４４０で、アクセス制御装置３７５はリクエスタ３０５のためにスマートＵＤＤＩ３８５に代理要求を送出する。ブロック４４５で、アクセス制御装置３７５は、リクエスタ３０５のためのスマートＵＤＤＩ４４５からのトークン情報をキャッシュする。
【００４０】
こうすると、アクセス・ポリシー１２５が実際のサービスとは別に決定されるため、Ｗｅｂ  Ｓｅｒｖｉｃｅを様々な管理可能ドメインに配置することができ、それによって、サービスのサード・パーティ・ホスティングが可能になり、アプリケーション・サービス提供者３６０が制御を維持できるようになる。Ｗｅｂ  Ｓｅｒｖｉｃｅは、アクセス制御装置３７５を通過することを要求するため、セキュリティ検査を受ける。しかし、様々な管理可能ドメインにわたる操作のため、本発明の一部の実装形態では、発見に使用されるアクセス制御装置要素は、サービス呼出しに使用されるものと異なるものにすることが可能である。
【００４１】
一実装形態では、管理可能ドメインは、同じ管理制御下で共にグループ化されたネットワーク要素でもよい。ネットワークドメインとは、サービス実行目的の品質について、共通のＱｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ（ＱｏＳ）ポリシーを共用する任意のドメインを指す。管理可能ドメインは、他のドメイン（すなわちＮＴまたはＩＰ）にオーバーラップすることができる。たとえば１つの管理者または権限の制御下にあるインターネットまたはローカル・ネットワークの１つのセクションは、主管庁管理ドメインを形成することができる。単一の管理可能ドメインは、複数のサーバ（ホストとして働き、またはＮｅｔ上で他のリソースを提供するコンピュータまたはシステム）を含むことができ、１つまたは複数のドメイン名（Ｎｅｔｗｏｒｋアドレス）によってアドレス指定することができる。この管理可能ドメインは、複数の管理者も有する。
【００４２】
図５を参照すると、本発明の一実装形態による、ブロック５００でウェブ・サーバ１１５によってサービス要求を受け取ることを含む、Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にするための方法が様式的に示されている。ブロック５０５で、リクエスタ３０５は、第１のアクセス制御装置要素３７５およびスマートＵＤＤＩ３８５を使用して、サービスを発見し、符号付きアクセス・トークンを得る。次いで、リクエスタ３０５は第２のアクセス制御装置要素３７５を介してデプロイド・サービス３９０を使用し、それによってこのポリシーをデプロイド・サービス３９０とは別に実装する。ブロック５１０で、ウェブ・サーバ１１５は、認証およびアクセス・ポリシーの評価をキャッシュ３９７にキャッシュすることができる。ブロック５１５で、スマートＵＤＤＩ３８５は、ＩＤおよびアクセス・ポリシー情報を符号付きアクセス・トークンに符号化することができる。
【００４３】
ダイヤモンド５２０で、サービス呼出しを生成するか否かについて判断が行われる。ダイヤモンド５２０でサービス呼出しが指示された場合、ブロック５２５で、リクエスタ３０５は符号付きアクセス・トークンをアクセス制御装置３７５に渡して、認証およびアクセス・ポリシー計算を再使用する。ブロック５３０で、アクセス制御装置３７５は、第２のアクセス制御装置要素を使用して、アクセス制御の実装をサービス要求に基づく実際のサービスと分離することができる。ブロック５３５で、様々な管理可能ドメインにわたって標準サービスの使用を可能にすることができる。ダイヤモンド５２０で、任意の保留中のサービス呼出しによって、後続のサービス呼出しを行うか否かの判定を試みることができる。
【００４４】
当業者には理解されるように、本明細書の様々な実装形態で示した多様なシステム層、ルーチン、またはモジュールは、制御ユニットで実装可能である。制御ユニットには、マイクロプロセッサ、マイクロコントローラ、ディジタル信号プロセッサ、（１つまたは複数のマイクロプロセッサあるいは制御装置を含む）プロセッサカード、または他の制御もしくはコンピューティング・デバイス、並びに１つまたは複数の記憶装置に含まれた実行可能な命令が含まれる。記憶装置には、データおよび命令を記憶するための１つまたは複数の機械可読記憶媒体が含まれる。記憶媒体には、ダイナミックまたはスタティック・ランダム・アクセス・メモリ（ＤＲＡＭまたはＳＲＡＭ）、消去書込み可能かつプログラム可能な読出し専用メモリ（ＥＰＲＯＭ）、電気的消去書込み可能かつプログラム可能な読出し専用メモリ（ＥＥＰＲＯＭ）並びにフラッシュメモリ、固定、フロッピー（登録商標）、リムーバブル・ディスクなど磁気ディスク、テープを含む他の磁気媒体、およびコンパクト・ディスク（ＣＤ）またはディジタル・ビデオ・ディスク（ＤＶＤ）など光媒体などの半導体メモリ・デバイスを含む多様な形態のメモリが含まれる。多様なシステムの多様なソフトウェア層、ルーチン、またはモジュールを作成する命令は、それぞれ記憶装置に記憶することができる。命令がそれぞれ制御ユニットによって実行されると、命令により、対応するシステムがプログラミングされた動作を行うようになる。
【００４５】
上記に開示した特定の実装形態は単に例示であり、本発明は、本明細書の教示の恩典を有する当業者には明らかな、相違しても等価な方法で修正または実装することができる。さらに、頭記の特許請求の範囲で記載したもの以外は、本明細書で示した構成および設計の詳細は制限を受けないものとする。したがって、上記で開示した特定の実装形態には、変更または修正を加えることができることは明らかであり、こうした変形形態は全て本発明の精神および範囲内にあるものと考えられる。したがって、本明細書で求める保護は頭記の特許請求の範囲で述べたものである。
【図面の簡単な説明】
【００４６】
【図１】Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にするシステムを様式的に示す図である。
【図２】Ｗｅｂ  Ｓｅｒｖｉｃｅを安全にする方法を様式的に示す図である。
【図３】スケーラブル・ポリシーベースＷｅｂ  Ｓｅｒｖｉｃｅセキュリティ・アーキテクチャによるＷｅｂ  Ｓｅｒｖｉｃｅを安全にするＷｅｂ  Ｓｅｒｖｉｃｅシステムを様式的に示す図である。
【図４】Ｗｅｂ  Ｓｅｒｖｉｃｅアクセス制御および許可アーキテクチャを様式的に示す図である。
【図５】サービス要求の基づく実際のサービスとは別にＷｅｂ  Ｓｅｒｖｉｃｅのために決定されたアクセス・ポリシーに基づいてＷｅｂ  Ｓｅｒｖｉｃｅを安全にする方法を様式的に示す図である。
【図１】
2005354679.tif 000003
【図２】
2005354679.tif 000004
【図３】
2005354679.tif 000005
【図４】
2005354679.tif 000006
【図５】
2005354679.tif 000007