(57)【要約】  Ｗｅｂベースのサービス環境において、サードパーティプロバイダは、補完サービスを得るためにユーザデータに対するアクセス度が可変である必要がある。サードパーティプロバイダが必要以上に広範なアクセス権をもち、あるいは不適切なアクセスレベルをもつのを防止するために、サードパーティに相応のアクセスレベルを判断するために転送可能な制限付きセキュリティチケットが採用されている。有効期限と制限ロールをもつチケットは、サードパーティに対するアクセスの持続時間とレベルを定義している。これらの制限は、システムに定義されている許可ユーザのセキュリティロールと制限ロールの交差を通して判断されている。
2010538365.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂベースのサービス環境（１０４）においてユーザデータへのアクセスに対するサードパーティのリクエストを安全に処理するためにコンピューティングデバイスにおいて少なくとも部分的に実行される方法であって、前記方法は、
アクセスに対するリクエストをサードパーティプロバイダ（１０６）から受け取るステップ（９０２）であって、前記リクエストは、前記Ｗｅｂベースのサービスのプロセスを補完するサブシステムと関連付けられているステップと、
チケット（２１８）とクレームを前記リクエストから抽出するステップ（９０４）であって、前記チケット（２１８）は、有効期限パラメータと制限ロール（３２４、３２６）を含んでいるステップと、
前記チケット（２１８）が有効期限を満了していないことを検証するステップ（９０８）と、
前記チケット（２１８）と関連付けられた少なくとも１つのユーザロール（３２２）をロードするステップ（９１０）と、
前記リクエストに対するアクセス制限を前記制限ロール（３２４、３２６）と前記少なくとも１つのユーザロール（３２２）の交差に基づいて判断するステップ（９１２、９１４）と、
前記サードパーティが前記判断したアクセス制限に基づいてユーザデータにアクセスするのを可能にするステップ（９１６）とを備えることを特徴とする方法。
【請求項２】
前記チケット（２１８）は、サードパーティプロバイダ（１０６）のドメイン名と関連付けられていることを特徴とする請求項１に記載の方法。
【請求項３】
前記アクセス制限を判断する前に前記チケット（２１８）を認証するステップ（９０６）をさらに備えることを特徴とする請求項１に記載の方法。
【請求項４】
前記チケット（２１８）は、デジタルシグネーチャ（電子署名）を使用して認証されることを特徴とする請求項３に記載の方法。
【請求項５】
前期クレームは、前記デジタルシグネーチャを使用して検証されることを特徴とする請求項４に記載の方法。
【請求項６】
前記チケット（２１８）は、ハッシュメッセージ認証コード（ＨＭＡＣ）を使用して認証されることを特徴とする請求項３に記載の方法。
【請求項７】
前記チケット（２１８）は、キーインジケータと組織識別名のうち少なくとも１つをさらに含んでいることを特徴とする請求項６に記載の方法。
【請求項８】
前記チケット（２１８）のＨＭＡＣ部分にビットを付加することによって前記チケット（２１８）を特定のアックションに制限することをさらに備えることを特徴とする請求項６に記載の方法。
【請求項９】
前記チケット（２１８）は、前記ユーザデータにアクセスするために前記チケット（２１８）が何回使用されることがあるかを定義する反復パラメータをさらに含んでいることを特徴とする請求項１に記載の方法。
【請求項１０】
前記制限ロール（３２４、３２６）と少なくとも１つのユーザロール（３２２）と交差することは、前記ロールに定義された前記制限のうちより厳格なものを選択することを含むことを特徴とする請求項１に記載の方法。
【請求項１１】
前記ロールに定義された前記制限のうちより厳格なものを選択するステップに加えて、あらかじめ定められたルールを適用するステップをさらに備えることを特徴とする請求項１に記載の方法。
【請求項１２】
ＷｅｂベースのＣＲＭサービス環境においてユーザデータへのアクセスに対するサードパーティのリクエストを安全に処理するシステムであって、
少なくとも１つのＣＲＭ  Ｗｅｂサーバ（７７２）を含み、前記Ｗｅｂサーバ（７７２）は、
アクセスに対するリクエストをサードパーティプロバイダ（１０６）から受信するステップ（９０２）であって、前記リクエストは、前記ＷｅｂベースのＣＲＭサービスのプロセスを補完するサブプロセスと関連付けられているステップと、
チケット（２１８）を前記リクエストから抽出するステップ（９０４）であって、前記チケット（２１８）は、前記サードパーティプロバイダ（１０６）のドメイン名と関連付けられていて、有効期限パラメータと制限パラメータを含んでいるステップと、
前記チケット（２１８）が有効期限を満了していないことを検証するステップ（９０８）と、
前記リクエストに対するアクセス制限を前記制限パラメータに基づいて判断するステップ（９１０、９１２、９１４）であって、前記アクセス制限は、実行される前記サブプロセスの対象であるユーザ（１０２）のアクセス制限とは異なっているステップと、
前記サードパーティが判断されたアクセス制限に基づいて前記ユーザデータにアクセスするのを可能にするステップ（９１６）とを実行することを特徴とするシステム。
【請求項１３】
前記少なくとも１つのＣＲＭ  Ｗｅｂサーバ（７７２）は、さらに、
関連する制限ロール（３２４、３２６）をもつ制限されたユーザ／ドメインを前記制限パラメータに基づいて作成し、
前記関連する制限ロール（３２４、３２６）とユーザロールとの交差（９１４）に基づいてアクセス制限を判断することを特徴とする請求項１２に記載のシステム。
【請求項１４】
前記少なくとも１つのＣＲＭ  Ｗｅｂサーバ（７７２）は、さらに、
制限ロール（３２４、３２６）のリストを前記チケット（２１８）から取り出し、
前記サブプロセスと関連付けられたユーザロール（３２２）をロードし、
前記制限ロール（３２４、３２６）とロードした前記ユーザロール（３２２）との交差（９１４）に基づいて前記アクセス制限を判断することを特徴とする請求項１２に記載のシステム。
【請求項１５】
各制限ロール（３２４、３２６）および前記ユーザロール（３２２）は、前記ユーザデータに対するアクセス許可レベルを定義する権限の深さを含み、前記アクセス制限は、交差したロールの権限の深さのうちより厳格なものを選択することによって判断されることを特徴とする請求項１４に記載のシステム。
【請求項１６】
前記ＣＲＭ  Ｗｅｂサーバ（７７７）は、さらに、前記制限ロール（３２４、３２６）および前記ユーザロール（３２２）の権限の深さを設定するためのグラフィカルユーザインタフェース（ＧＵＩ）を提供することを特徴とする請求項１２に記載のシステム。
【請求項１７】
前記サブプロセスと関連付けられたユーザロール（３２２）に割り当てられた少なくとも１つの制限は、前記ＷｅｂベースのＣＲＭサービスのクライアント組織の階層構造に基づいて定義されていることを特徴とする請求項１２に記載のシステム。
【請求項１８】
Ｗｅｂベースのサービス環境（１０４）においてユーザデータへのアクセスに対するサードパーディのリクエストを安全に処理するための命令が格納されているコンピュータ可読記憶媒体であって、前記命令は、
アクセスに対するリクエストをサードパーティプロバイダ（１０６）から受信するステップ（９０２）であって、前記リクエストは、前記Ｗｅｂベースのサービスを補完するサブプロセスと関連付けられているステップと、
チケット（２１８）とクレームを前記リクエストから抽出するステップ（９０４）であって、前記チケット（２１８）は、前記サードパーティプロバイダ（１０６）のドメイン名と関連付けられて、有効期限パラメータ、制限ロール（３２４、３２６）および反復パラメータを含んでいるステップと、
前記アクセス制限を判断する前に前記チケット（２１８）を認証するステップ（９０６）と、
前記チケット（９０８）は、有効期限を満了していないことを検証するステップ（９０８）と、
前記制限ロール（３２４、３２６）と少なくとも１つの前記ユーザロール（３２２）との交差に基づいて前記リクエストに対するアクセス制限を判断するステップ（９１４）と、
判断した前記アクセス制限に基づいて前記サードパーティが前記ユーザデータにアクセスするのを可能にする（９１６）ステップとを含むことを特徴とするコンピュータ可読記憶媒体。
【請求項１９】
前記制限ロール（３２４、３２６）および少なくとも１つの前記ユーザロール（３２２）を判断（９１４）するステップは、前記ロールに定義された制約のうちより厳格なものを選択し、あらかじめ定められたルールを適用することを含むことを特徴とする請求項１８に記載のコンピュータ可読記憶媒体。
【請求項２０】
前記アクセスは、新レコードの作成、既存レコードの削除、既存レコードの修正、既存レコードの更新、前記サブプロセスの実行と関連付けられたオペレーション上のパラメータの取り出し、および前記ユーザデータと関連付けられたスキーマの修正のセットから少なくとも１つを含んでいることを特徴とする請求項１８に記載のコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
Ｗｅｂベースのサービスには、サービスプロバイダ、そのユーザ、およびサードパーティの間のやりとりが含まれており、サードパーティは統合コンテンツ形式(integrated content form)のように、特定のサービスを提供するための補完的サービス(complementary service)を提供することができる。
【背景技術】
【０００２】
このような統合コンテンツは、組み込まれたフレーム、フォームまたはスクリプトの形をとることができる。例えば、ビジネスレコードサービスは、そのユーザのための種々のプロセスを、ユーザのビジネス連絡先（例えば、履歴データの収集、統計的分析、イベントのスケジューリングなど）に基づいて実行することができる。他方、ユーザおよび／またはサードパーティと名付けられたサービスプロバイダは、レコード上のアドレスに基づいてビジネス連絡先(business contact)のマップの提供といった、提供サービスを補完するサブプロセスを実行することができる。
【０００３】
ＣＲＭ(Customer Relationship Management)ソリューションは、Ｗｅｂベースのビジネスサービスの一例であり、このサービスでは、代表例としてホストされたコンピュータアプリケーション環境において、購買とポストセールスを通した第１の連絡先から顧客の明確な像を生成し、維持するのに必要なツールと能力が提供されている。複雑な組織では、ＣＲＭシステムは、セールスおよびマーケッティング組織が新規の顧客をターゲットとし、マーケッティングキャンペーンを管理し、セールスアクティビティを駆動する際の仕方を改善するのに役立つ特徴と能力を提供することができる。ＣＲＭシステムは、組織の内部または外部のユーザだけでなく、サードパーティプロバイダによっても個別的にまたは共用の形で利用される多数のコンポーネント、ハードウェアおよびソフトウェアを含むことができる。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
サブプロセスを実行するために、サードパーティは、サービスプロバイダにおいてユーザのレコードへのアクセス権を有している必要があるのが一般的である。上記の例において、サードパーティは、マップを生成し、そのマップをサービスプロバイダのＷｅｂページに組み入れるためには、ビジネス連絡先のアドレスにアクセスできる必要がある。データを読み取り、修正し、作成し、および削除するためにユーザデータにアクセスできることは、特にサードパーティプロバイダが信頼できるエンティティ(trusted entity)でないときセキュリティ上の問題が起りえる。
【課題を解決するための手段】
【０００５】
この概要は、「詳細な説明」に詳しく記載されている概念のいくつかを選んで、簡単な形式で紹介したものである。この概要は、請求項に記載の主題のキーとなる特徴または基本的特徴を特定することを意図するものではなく、請求項に記載の主題の範囲を理解する上で一助となることを意図するものでもない。
【０００６】
実施形態は、サードパーティプロバイダが転送可能な制限付きセキュリティトークン(transferable restricted security token)を使用してユーザデータにアクセスするのを制御することによって、Ｗｅｂベースのサービスプロバイダにおいてユーザレコードの機能が強化されたセキュリティを提供することを目的としている。転送可能な制限付きセキュリティトークンは、ユーザに割り当てられたものに加えて、セキュリティ制限をもつチケットの形で生成される。
【０００７】
上記およびその他の特徴と利点は、下述する詳細な説明の記載及び、関連する図面の外観により明らかにされる。当然に理解されるように、上述の概要説明と下述する詳細な説明は共に、単なる例示であり、請求項に記載の事項を限定するものではない。
【図面の簡単な説明】
【０００８】
【図１】ユーザ、サービスプロバイダ、およびＷｅｂベースのサービスのサードパーティプロバイダの間の代表的なデータアクセスのやりとりを示す概略図である。
【図２】実施形態に係るユーザ、サービスプロバイダ、およびＷｅｂベースのサービスのサードパーティプロバイダの間のやりとりの例を示す概略図である。
【図３】Ｗｅｂベースのサードパーティプロバイダに割り当てられるセキュリティ制限を判断する際のユーザロールと制限ロールの使用を示す概念図である。
【図４】Ｗｅｂベースのサービスのユーザにアクセス制限を割り当てるためのソフトウェアプログラムを示すスクリーンショットである。
【図５】Ｗｅｂベースのサービスのサードパーティプロバイダにアクセス制限を割り当てるためのソフトウェアプログラムを示すスクリーンショットである。
【図６】実施形態に係る制限付きセキュリティチケットの３つの例を示す図である。
【図７】実施形態が実現可能であるネットワーク化環境の例を示す図である。
【図８】実施形態が実現可能であるコンピューティング動作環境の例を示すブロック図である。
【図９】Ｗｅｂベースのサービスにおいてサードパーティプロバイダによるユーザデータへのアクセスを許可するために制限付きセキュリティチケットを使用するプロセスのロジックフローを示す図である。
【発明を実施するための形態】
【０００９】
簡単に上述したように、Ｗｅｂベースのサービスにおけるユーザデータセキュリティは、サードパーティプロバイダによるデータへのアクセスを許可するため制限付きセキュリティチケット(restricted security ticket)の使用によって機能の強化がなされている。下述する詳細説明において、本明細書の一部を形成し、そこに特定の実施形態または例が例示されている添付図面が参照されている。これらの事項は結合されることもあれば、その他の事項が利用されることもあれば、本明細書の開示事項の精神または範囲から逸脱することなく、構成上の変更が行なわれることもある。従って、下述する詳細説明は限定的意味に解されるものではなく、本発明の範囲は請求項の記載およびそれと同等の記載によって明確化されている。
【００１０】
実施形態は、パーソナルコンピュータ上のオペレーティングシステム上で稼動するアプリケーションプログラムと併用して実行されるプログラムモジュールの一般的なコンテキストの中で説明されているが、この分野の当業者ならば認識されるように、本発明の特徴は、他のプログラムモジュールと組み合わせて実現されることもあり得る。
【００１１】
一般的に、プログラムモジュールの中には、ルーチン、プログラム、コンポーネント、データ構造、および特定のタスクを実行し、または特定の抽象データ型を実現するその他のタイプの構造が含まれている。さらに、この分野の当業者ならば認識されるように、実施形態は、他のコンピュータシステム構成と共に実施されることがあり、その中には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースのプログラマブルコンシューマエレクトロニクス、ミニコンピュータ、メインフレームコンピュータなどが含まれている。実施形態は、通信ネットワークを通してリンクされたリモート処理デバイスによってタスクが実行されるような分散コンピューティング環境で実施されてもよい。分散コンピューティング環境において、プログラムモジュールがローカルとリモートの両方のメモリストレージデバイスに置かれてもよい。
【００１２】
実施形態は、コンピュータプログラムプロダクトやコンピュータ可読媒体のように、コンピュータプロセス（方法）、コンピューティングシステム、または製造物品として実現されてもよい。コンピュータプログラムプロダクトは、コンピュータシステムによって読み取り可能で、コンピュータプロセスを実行するための命令からなるコンピュータプログラムを符号化しているコンピュータ記憶媒体でもよい。コンピュータプログラムプロダクトは、コンピューティングシステムによって読み取り可能で、コンピュータプロセスを実行するための命令からなるコンピュータプログラムを符号化した搬送波上の伝播信号でもよい。
【００１３】
図１を参照して説明すると、図１には、ユーザ、サービスプロバイダ、およびＷｅｂベースのサービスのサードパーティプロバイダの間の代表的なデータアクセスのやりとりが示されている。
【００１４】
前述したように、サードパーティプロバイダは、ユーザのためのサービスのプロセスを補完するＷｅｂサービス内のサブプロセスを実行することができる。１つの例は、前述したように、ユーザのための連絡先(contacts)を処理するＷｅｂベースのサービスに対する連絡先マップを提供するサードパーティである。別の例は、ＣＲＭシステム内のクレジットスコア(credit score)を計算するためのサードパーティサービスである。ＣＲＭ連絡先フォームは、コールでサードパーティに入り込んで連絡先ＩＤを渡すスクリプトを実行するようにカスタマイズされてもよい。そのあと、サードパーティは、コールバックしてＣＲＭサービスに入り込んで種々の連絡先および注文情報を取り出して、選択した連絡先に対するクレジットスコアを計算してもよい。サードパーティは、クレジットレーティングスコア(credit rating score)を返すことができ、これは、連絡先フォームのフィールドに表示されてもよい。サードパーティは、他の有用な統計により連絡先レコードを直接に更新することもできる。
【００１５】
以上のように、サードパーティプロバイダは、収集、修正、削除または作成オペレーションのためにＷｅｂベースのシステム内のユーザデータへのアクセス権をもつ必要があることがある。このようなサードパーティのオペレーションを受け入れる際の困難な点としては、これらのオペレーションのためにどのサードパーティを許可し、どのような許可レベルにし、どのような持続時間にするか、をどのように制御するかがある。
【００１６】
従来のＷｅｂベースのサービス環境では、図１の概略図１００に示されているように、各ユーザ１０２は、Ｗｅｂベースのサービス１０４内に割り当てられたセキュリティロール(security role)をもち、そのロールによって許可されたようにサービスにアクセスすることができる。ユーザ１０２は、例えば、そのセキュリティチケット(security ticket)をサードパーティに提供することによって、ある時点でサードパーティサービス１０６にオペレーションの実行を認可することができる。このようなケースでは、サードパーティサービス１０６は、そのユーザのセキュリティロールによって許可されたように、ユーザ１０２と関連付けられた全データへの完全アクセス権を有し、そのオペレーションを実行することになる。このようなセットアップの問題点は、ユーザ自身がもっているデータ全体への完全アクセス能力をサードパーティに持たせることを、ユーザが望んでいないことがあることである。
【００１７】
この問題をさらに複雑にしているのは、組織には、可変のセキュリティロールをもつ複数の内部ユーザがいることである。その一人がサードパーティに認可した場合、そのユーザのセキュリティロールは、必要なオペーションを実行するのに不適切になるおそれがあるか、さもなければ、必要以上に広くなるおそれがある。例えば、ある会社の受付係は、ビジネス連絡先情報を「読み取る」だけといったように、アクセスが制限されていることがある。その受付係がクレジットスコアを計算するためにサードパーティサービスをアクチベートしようとした場合、サードパーティは、受付係のセキュリティロールが制限されているために、Ｗｅｂサービスにおけるデータを更新できないことがある。
【００１８】
他方、広いアクセス権を持つハイレベルマネージャは、あるビジネス連絡先のためにマップサービスをアクチベートしたいことがあるが、サードパーティに必要なアクセス権は制限されているのが代表的である。しかし、マネージャは、広いアクセス権を持っているので、サードパーティは、それが必要であるか否かに関係なく、そのマネージャのセキュリティチケットを通して同じ権限を得ることになる。
【００１９】
サードパーティによるユーザデータへのアクセスを制御する別のアプローチとしては、Ｗｅｂサービスで制限付きセキュリティロールをサードパーティサービスに割り当てることがあるが、これは、ユーザが自分の選択したサードパーティサービスを使用するのを可能にするＷｅｂベースのサービスの柔軟性をひどく制限し、ユーザサービスのカスタマイズを非常に困難なタスクにするおそれがある。
【００２０】
図２は、ユーザ、サービスプロバイダ、および実施形態に係るＷｅｂベースのサービスのサードパーティプロバイダの間のやりとりの例を示す図である。
【００２１】
上述したように、Ｗｅｂベースのサービスプロバイダの困難な点は、どの許可レベルで、どれだけの正確な持続時間の間、どのサードパーティがコールバックしてサービスに入るのを許可するかをどのように制御するかである。例えば、サービスアドミニストレータがＣＲＭサービスで連絡先フォームを見ているとき、接続側ユーザのセキュリティコンテスト全体をセミトラステッド(semi-trusted)サードパーティに転送することは、サードパーティが実際に目的のサービスを実行することを必要とする以上に、レコードにアクセス可能になったことを意味することがある。アドミニストレータは、どのタイプのレコードも削除し、どのタイプのレコードも作成し、またはスキーマ変更を行なうこと（例えば、新エンティティ、アトリビュートの作成など）が認可されることができる。接続側ユーザのセキュリティコンテキスト全体を特定サービスの狭いセットを提供することだけが期待されるセミトラステッドサードパーティに転送することは、結果的に重大なリスクとなるおそれがある。
【００２２】
実施形態によれば、チケットは、サードパーティプロバイダのために生成されてもよい。このチケットは、追加のセキュリティ制限とチケット有効期限を指定することができる。追加のセキュリティ制限は、Ｗｅｂベースのサービスロールインフラストラクチャを使用して定義されてもよい。サードパーティプロバイダの特定ドメイン名は、そのあと制限ロールと関連付けられてもよい。例えば、制限ロールは、［activity read permission with a scope of local］+ [lead create and read permission, with a scope of current business unit]を許与するために、サードパーティドメイン‘‘http://accuratecreditinfo.com’’に対して定義されてもよい。しかし、接続側ユーザがリード(leads)を作成する許可を得ていない場合には、接続側ユーザ（およびそのロール）に対する許可を、エレベーション(elevation)がないことを確かめるための制限ロールによって定義された許可と交差することによって、セキュリティが評価されてもよい。制約ロールは、カレントビジネスユニットのスコープを指定してもよい。
【００２３】
概略図２００において、Ｗｅｂベースのサービスは、ユーザ固有プロセス２１０をユーザ２０２のために実行するサーバ２０４によって表されている。チケット検証プロセス(ticket verification process)（２０８）は、ユーザを認証し、そのアクセス権を判断するために採用されてもよい。認証情報は、チケットに含まれてもよい。実施形態に係るサービスにおいて、サードパーティサービス２０６は、ユーザ固有プロセス２１０を補完するためにサブプロセス２１２を実行することができる。Ｗｅｂベースのサービスでユーザデータとオーダにアクセスするために、サードパーティサービス２０６は、制限付きセキュリティチケット(restricted security ticket)２１８をＷｅｂベースのサービス２０４に提供することができる。サードパーティサービス２０６は、他のシステム２１４とやりとりすることもできる。
【００２４】
制限付きセキュリティチケット２１８は、Webベースのサービスによって認可されてもよい。この認可は、いくつかの方法を通して行なわれることができる。そのような方法の１つはハッシュメッセージ認可コード（ＨＭＡＣ）である。「ＭＡＣタグ」は、メッセージに含まれる秘密鍵に基づいて生成され、攻撃者が有効なペア（メッセージ、タグ）を生成するのを困難にしている。
【００２５】
ＨＭＡＣの代わりに、他の実施形態によればデジタルシグネーチャが使用されてもよい。デジタルシグネーチャによると、コンポーネントは、クレームを検証できるが、有効なチケットを生成する能力を持っていないことがある（検証鍵だけが利用可能なこともある）。ＨＭＡＣによると、コンポーネントは、クレームを検証できるが、その場合も、必要な対称鍵(symmetric key)にアクセスできるので有効なチケットを作成する能力を持っている。デジタルシグネーチャの使用は、別のデリゲーション(delegation)を許可するのに役立つことができる。例えば、サードパーティは、Ｗｅｂベースのサービスチケットを他のサードパーティに転送することがあるので、他のサードパーティは、なんらかのアクションをとる前にＷｅｂベースのサービスへのアクセスを検証することができる。本明細書に上述した方式を利用して、他の認証方法が採用されてもよい。
【００２６】
従って、例示のチケットは、{UserId + Expiration + RestrictionRoleIds + HMAC(UserId + Expiration + RestrictionRoleIds)}のような形式になっていてもよい。チケットは、（各々がある時間後に期限満了する回転鍵が使用される場合、どの鍵が使用されるかを知るために）鍵インジケータおよび（同じUserIdが再使用されることがある場合に組織間の攻撃を防止するために）組織ＩＤを含んでもよい。
【００２７】
別の実施形態によれば、Ｗｅｂベースのサービスアドミニストレータは、読み取りのみのアクションのように、チケットを特定のアクションに制限することを指定できることができる。これは、例えば、チケットのＨＭＡＣにビットを付加し、プラットフォームで書き込みアクションを阻止することによって行なわれることがある。
【００２８】
さらに別の実施形態によれば、制限付きユーザ／ドメインは、制限付きロールのリストをチケットに組み入れる代わりに、システムに作成されてもよい。制限付きユーザ／ドメインは、ロールが自分と関連付けられていることがあり、これらのロールが制限付きロールとして使用されてもよい。ユーザロールと制限付きロールの交差は上述したように判断されてもよい。このシナリオでは、チケットは、{UserId + Expiration + RestrictedUserId + HMAC(UserId + Expiration + RestrictedUserId)}のような形式になっていてもよい。
【００２９】
制限付きチケットがロールリストを含んでいるバージョンでは、ドメインに関連するロールは変更されてもよいが、セキュリティ制限は、ロールにおける権限が独立に変更される場合でも、チケット内のロールセットに基づいている。制限付きユーザ／ドメインのアプローチでは、サーバは制限付きロールの制御権を持っている。従って、制限付きドメイン／ユーザだけを持つバージョン内のロールは、すでに許与されているチケットとは独立に追加／変更することができる。
【００３０】
権限交差(privilege intersection)は、一実施形態に従ってチケットがＷｅｂサービス（例えば、ＣＲＭサービス）から戻されたとき行なわれてもよく、変更の可能性があるユーザ権限をダイナミックに再評価し、（システムリソース節約のために）サードパーティによって使用されることのないチケットを処理しないという利点があるが、チケットが本明細書に説明した方式を用いてチケットが最初に発行されるとき同じ交差が行なわれてもよい。
【００３１】
図３は、Ｗｅｂベースのサービスのサードパーティプロバイダに割り当てられるセキュリティ制限を判断する際のユーザロールと制限ロールの使用を示す概念図である。
【００３２】
ロールベースのアクセス権システムにおいて、権限の深さ(privilege depth)は、ユーザとレコードとの関係に基づいて種々のレベルで定義されてもよい。例えば、「基本的」な深さは、ユーザによって所有するレコードに関して定義されてもよく、「ローカル」な深さは、ユーザが所属するビジネスユニットのレコードに関して定義されてもよく、「ディープ」な深さは、ユーザのビジネスユニットまたはいずれかの子ビジネスユニットのレコードに関して定義されてもよく、「グローバル」な深さは、傘下組織のいずれかのビジネスユニットにおけるレコードに関して定義されてもよい。
【００３３】
これらの例示の権限の深さに基づいて、ユーザには、基本的な深さをもつ“Read Activity”、ディープな深さをもつ“Write Lead”、およびディープな深さをもつ“Create Contact”と定義された単一ロールが割り当てられてもよい。サードパーティプロバイダには、ローカルな深さをもつ“Write Lead”およびグローバルな深さをもつ“Create Contact”と定義された単一ロールが割り当てられてもよい。
【００３４】
実施形態に係るサービスにおいて、これらのロールの交差３２０（例えば、ユーザロール３２２と制限ロール３２４および制限ロール３２６との交差）は、結果としてローカル深さをもつ“Write Lead”およびディープ深さをもつ“Create Contact”が得られる（各ケースにおいて、これらの深さの小さい方が選択される）。
【００３５】
制限ロール、権限の深さ、および上記の交差シナリオは例示の目的のみに示されたもので、実施形態を限定するものではない。実施形態は、いずれかの定義した権限の深さ、組織構造、および制限ロールを使用して実現されてもよい。さらに、ユーザのロールと制限ロールの交差を、これらの２交差のうち小さい方を超えて判断するための追加のロールが定義されてもよい。さらに、ＣＲＭサービスは、本明細書では、Ｗｅｂベースのサービス例として使用されている。実施形態は、本明細書に説明した方式を用いて、いずれかのアプリケーションセキュリティ制限と共に実現されてもよい。
【００３６】
図４は、アクセス制限をＷｅｂベースのサービスに割り当てるためのソフトウェアプログラムのスクリーンショット（４００）を示す図である。
【００３７】
上述したように、セキュリティロールは、可変のアクセス許可レベルをもつ組織の各ユーザに割り当てられてもよい。例えば、Ｗｅｂサービスプログラムのアクセス管理モジュールを使用すると、アドミニストレータは、スクリーンショットに示すように各ユーザのセキュリティロールを定義することができる。例では、受付係（４３２）のためにロールが作成されるところである。アカウント、連絡先、ｅメールテンプレートなどの異なるタイプのレコードがカラム（列）（４３４）にリストされている。作成、読み取り、書き込み、削除などのアクセスオペレーション（４３８）が対応するカラムにリストされ、アドミニストレータがマトリックス（４３０）内の各タイプのレコードについて各オペレーションの許可レベルをセットすることを可能にしている。
【００３８】
ユーザインタフェースは、タブ（４３６）で示すようにレコードが組織のサブディビジョン別に分類されるようにセットアップされてもよい。セキュリティロールは、ユーザによって割り当てられ、Ｗｅｂベースのサービスに送られても、Ｗｅｂベースのサービスによって生成されたデフォルトロールのテンプレートに基づいてユーザによって修正されても、Ｗｅｂベースのサービスの管理プログラムの設定モードにあるユーザによって割り当てられてもよい。
【００３９】
図５は、アクセス制限をＷｅｂベースのサービスのサードパーティプロバイダに割り当てるためのソフトウェアプログラムのスクリーンショットを示す図である。サードパーティプロバイダは、Ｗｅｂベースのサービスを補完する種々のタスクを実行することができる。スクリーンショット（５００）に示す例示プロセスは、連絡先分析である。
【００４０】
スクリーンショット５００における設定用ユーザインタフェースは、図４のものと同じであり、レコードタイプ（５４４）がマトリックス内の第１のカラムとしてリストされ、アクセスタイプが第１の行(row)（５４８）としてリストされている。各レコードタイプとアクセスタイプのアクセス制限は、ユーザインタフェースマトリックス５４０のエレメントとして示されている。実施形態に係るユーザインタフェースは、パートナのアクセス制限を可能にするコントロールを含み、パートナがサードパーティプロバイダと関連付けられたＵＲＬによって定義されている点が重要である。
【００４１】
さらに、制限は組織の階層構造に基づいて判断されてもよい。例えば、制限ロールは、サードパーティサービスが個人ユーザ、ビジネスユニット、ビジネスサブユニット、または組織全体のために実行されるかどうかに基づいて定義されてもよい。
【００４２】
図６は、実施形態に係る制限付きチケットの３つの例を示す図である。実施形態に係る制限付きチケットは、図示のもの以外のエレメントを含んでもよい。有効期限と制限も図示の例に限定されない。
【００４３】
前述したように、サードパーティのためのロール制限は、Ｗｅｂベースのサービスにおける特定ドメイン名と関連付けられてもよい。第１の例のチケット６５２は、ドメイン名http://accuratecreditinfo.com（架空ドメイン名）と関連付けられている。チケットは、有効期限が６０秒で、制限は、連絡先分析ロールのみである。従って、チケット６５２で割り当てられたサードパーティは、チケットが受け取られたあとそのプロセスを実行するのに６０秒であり、Ｗｅｂベースのサービスにおけるユーザデータにアクセスして連絡先分析を実行するだけである。
【００４４】
第２のチケット６５４は、ドメイン名http://productimages.comと関連付けられており、これは特定ビジネスのプロダクトイメージを処理するためのサードパーティプロバイダサービスでもよい。このチケットは、有効期限が１０秒であり、その制限は、制限付きプロダクトアクセスロールである。このロールは、Ｗｅｂベースのサービスのアクセス管理部分に定義されてもよい。有効期限と制限のほかに、チケット６５４は、オプションとして反復(repetition)パラメータを含んでもよい。この反復パラメータを使用すると、サードパーティプロバイダは、反復パラメータの値に基づいて自分のセキュリティチケットを繰り返し使用することができる。図６の例では、反復パラメータは、チケットが一度だけ使用のチケット(single use ticket)であることを意味する“Ｎｏ”にセットされている。
【００４５】
例示のチケット６５６は、ドメイン名http://analyzeleads.comと関係付けられており、これからは、ＣＲＭサービスに対するビジネスリードの分析が得られる。このチケットの有効期限は、６０分にセットされ、制限は“read all leads”になっている。従って、このチケットを持つサードパーティはＣＲＴサービスにおけるすべてのビジネスリードデータを読むことができるが、どの追加アクセスオペレーションも実行しなくてもよい。オプションの反復パラメータは、このケースでは１０回にセットされているが、これはサードパーティプロバイダが１０回まで同じチケットを使用してユーザデータにアクセスすることができることを意味している。
【００４６】
いくつかの実施形態によれば、タイムスタンプの有効期限は、有効な時間期間の範囲（日付と時刻）を定義する有効期限の期間ではなく、他の方法で実現されてもよい。さらに、もっと複雑な式がチケットに組み入れられて、比較的フレキシブルな制限を表すことができる。例えば、時刻の有効期限、ユーザｉｄ（または名前）カテゴリ、およびユーザロールを与えるために、&(time.hour<8)(user.startswith(“s*”)(user.role.includes(CEO))のような式が使用されてもよい。
【００４７】
一実施形態によれば、サードパーティは、チケットを別のサードパーティに手渡す前にそのチケットをさらに制限する能力を有することができる。従って、あるサードパーティが別のサードパーティからのいくつかのサービスを使用する必要がある場合には、さらに制限されたトークンを作成することを選んで（またはサービスがそうすることもある）、チケットが複数の制限付きユーザＩＤ、または２以上のドメインから得られる制限付きロールＩＤを含むようにすることもできる。
【００４８】
図２、４、５および６に記載の例示のシステム、サービス、チケットおよびオペレーションは例示を目的とした例である。Ｗｅｂベースのサービス環境において転送可能な制限付きセキュリティチケットを提供するシステムは、本明細書に説明した方式を使用した追加またはもっと少数のコンポーネントおよびエレメントを使用して実現されてもよい。
【００４９】
図７は、実施形態が実現可能であるネットワーク構築環境の例を示す図である。サードパーティプロバイダのために制限付きセキュリティトークンを提供するＷｅｂベースのサービスは、複数の物理的および仮想的（バーチャル）クライアントとサーバを利用して分散方式で実現されてもよい。サービスは、１または２以上のネットワーク（例えば、ネットワーク（群）７７０）を利用して通信する複数のノードを採用した非クラスタシステムまたはクラスタシステムで実現されてもよい。
【００５０】
このようなシステムは、サーバ、クライアント、インターネットサービスプロバイダ、および通信媒体のいずれかのトポロジを含んでもよい。また、システムは、スタティックまたはダイナミックのトポロジを有してもよい。ここで「クライアント」という用語は、クライアントアプリケーションまたはクライアントデバイスを指すことがある。転送可能な制限付きセキュリティチケットを実現するネットワーク構築システムは、より多くの多数のコンポーネントが介入していることがあるが、関係するコンポーネントは図７を参照して説明されている。
【００５１】
ユーザは、個々のクライアントデバイス７６１−７６３を使用してＷｅｂベースのサービスにアクセスすることができる。Ｗｅｂベースのサービスは、Ｗｅｂサーバ７７２のような１または２以上のサーバによって管理されてもよい。Ｗｅｂベースのサーバと関連付けられた種々の目的のためのデータはデータストア７７６に格納されてもよく、このデータストアは、データベースサーバ７７４によって直接にアクセスまたは管理されてもよい。Ｗｅｂサーバ７７２（および関連サーバ）によって提供されるサービスを補完するサードパーティサービスは、転送可能な制限付きセキュリティチケットを前述したように使用してＷｅｂベースのサービスにアクセスし、Ｗｅｂベースのサービスに組み込まれているサブプロセスを実行することができる。
【００５２】
ネットワーク（群）７７０は、企業内ネットワークのようなセキュアネットワーク、ワイヤレスオープンネットワークのようなアンセキュアネットワーク、またはインターネットを含んでもよい。ネットワーク（群）７７０は、本明細書に説明されているノード間のコミュニケーションを提供している。例を挙げると、この例には限定されないが、ネットワーク（群）７７０は、ワイヤードネットワークまたは直接ワイヤードコネクションのようなワイヤード媒体および音響、ＲＦ、赤外線およびその他のワイヤレス媒体のようなワイヤレス媒体を含んでもよい。
【００５３】
コンピューティングデバイス、アプリケーション、データソース、データ記述システムの多くの他の構成を、Ｗｅｂベースのサービス環境において転送可能な制限付きセキュリティチケットを実現するために採用してもよい。さらに、図７に説明されているネットワーク化環境は、単に例示を目的としたものである。実施形態は、例示のアプリケーション、モジュールまたはプロセスに限定されない。
【００５４】
図８および関連する説明は、実施形態の実現が可能である適当なコンピューティング環境を簡単に概要説明したものである。図８を参照して説明すると、図８はコンピューティングデバイス８００などのコンピューティング動作環境例を示したブロック図である。基本構成では、コンピューティングデバイス８００は、サードパーティプロバイダが制限付きセキュリティチケットを通してデータにアクセスするのを可能にするＷｅｂベースのサービスと関連付けられたサービスを提供するサーバであって、代表例として少なくとも１つの処理ユニット８０２とシステムメモリ８０４を有することができる。コンピューティングデバイス８００は、プログラムを実行する際に協働する複数の処理ユニットを有することもできる。コンピューティングデバイスの正確な構成とタイプに応じて、システムメモリ８０４は、揮発性（ＲＡＭなど）、非揮発性（ＲＯＭ、フラッシュメモリなど）、または上記２つのなんらかの組み合わせであってもよい。システムメモリ８０４は、Microsoft Corporation(Redmond, Washington)提供のＷＩＮＤＯＷＳ（登録商標）オペレーティングシステムのように、ネットワーク化パーソナルコンピュータのオペレーションを制御するのに適したオペレーティングシステム８０５を収めているのが普通である。システムメモリ８９４は、プログラムモジュール８０８、Ｗｅｂサービス８２２、およびセキュリティモジュール８２４のような、１または２以上のソフトウェアアプリケーションを収めることができる。
【００５５】
Ｗｅｂサービスは、別個のアプリケーションであることも、コンピューティングデバイス８００と関連付けられたクライアントアプリケーションにデータと処理サービスを提供するホストされたＷｅｂベースのサービスアプリケーションの不可欠なモジュール(integral module)であってもよい。セキュリティモジュール８２４は、前述したように、ユーザおよび／または制限付きセキュリティチケットを実現するサードパーティプロバイダによるデータへの安全なアクセスを保証することに関連するサービスを提供することができる。この基本構成は、これらのコンポーネントが破線８０６で囲まれていることで図８に示されている。
【００５６】
コンピューティングデバイス８００は、追加の特徴または機能を有することができる。例えば、コンピューティングデバイス８００は、磁気ディスク、光ディスクまたはテープのような追加データストレージデバイス（取り外し可能および／または取り出し不能）を有することができる。このような追加ストレージは、取り外し可能ストレージ８０９および固定ストレージ８１０で図８に示されている。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、またはその他のデータのような、情報を記憶するためのいずれかの方法またはテクノロジで実現された揮発性と不揮発性で取り外し可能および固定媒体が含まれてもよい。システムメモリ８０４、取り外し可能ストレージ８０９および固定ストレージ８１０は、いずれもコンピュータ記憶媒体の例である。コンピュータ記憶媒体には、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリや他のメモリテクノロジ、ＣＤ−ＲＯＭ、ＤＶＤまたは他の光ストレージ、磁気カセット、磁気テープ、磁気ディスクストレージまたは他の磁気ストレージデバイス、または必要な情報を格納するために使用可能で、コンピューティングデバイス８００によってアクセス可能である他の媒体が含まれているが、これらに限定されない。このようなコンピュータ記憶媒体は、いずれもデバイス８００の一部であってもよい。コンピューティングデバイス８００は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイスなどの入力デバイス（群）８１２を有することができる。ディスプレイ、スピーカ、プリンタなどの出力デバイス（群）８１４を含んでもよい。これらのデバイスは、この分野で周知であるので、ここで詳しく説明することは省略する。
【００５７】
コンピューティングデバイス８００は、例えば、イントラネットやインターネット、つまり、分散コンピューティング環境においてワイヤレスネットワークを利用するといったように、デバイスが他のコンピューティングデバイス８１８と通信するのを可能にする通信コネクション８１６を収めてもよい。他のコンピューティングデバイス８１８には、Ｗｅｂベースのサービスと関連付けられたアプリケーションを実行するサーバが含まれてもよい。通信コネクション８１６は、通信媒体の一例である。通信媒体は、代表例として、コンピュータ可読命令、データ構造、プログラムモジュール、または搬送波や他のトランスポートメカニズムのような変調データ信号における他のデータによって具現化され、任意の情報配信媒体を含んでもよい。「変調データ信号(modulated data signal)」という用語は、信号の中の情報を符号化するような形でその特性の１つまたは２つ以上が設定または変更されている信号を意味している。例を挙げると、その例に限定されないが、通信媒体には、ワイヤードネットワークや直接ワイヤードコネクションのようなワイヤード媒体、および音響、ＲＦ、赤外線およびその他のワイヤレス媒体のようなワイヤレス媒体が含まれている。本明細書で用いられている「コンピュータ可読媒体(computer readable media)」の用語は記憶媒体と通信媒体の両方を含んでいる。
【００５８】
請求項に記載の主題には、方法も含まれている。これらの方法は、いくつかの任意の方法で実現することが可能であり、その中には、本明細書に記載した構造が含まれている。そのような方法の１つは、本明細書に記載したタイプのデバイスのマシンオペレーションによる方法である。
【００５９】
もう１つのオプショナルな方法は、その方法の個々のオペレーションの１つまたは２以上が、オペレーションの一部を実行する１または２以上のヒューマンオペレータと関連して実行される場合である。これらのヒューマンオペレータは相互に関連している必要はなく、各オペレータはプログラムの一部を実行するマシンと一緒にいるだけである。
【００６０】
図９は、Ｗｅｂベースのサービスにおいてサードパーティプロバイダによるユーザデータへのアクセスを可能にするために制限付きセキュリティチケットを使用するプロセス（９００）を示すロジックフロー図である。プロセス９００は、ＣＲＭサービスの一部として実現されてもよい。
【００６１】
プロセス９００は、オペレーション９０２から開始し、アクセスに対するリクエストがサードパーティプロバイダから受信される。前述したように、サードパーティプロバイダは、Ｗｅｂベースのサービスによって提供されるサービスを補完するサブプロセスを実行することができる。処理は、オペレーション９０２からオペレーション９０４に進む。
【００６２】
オペレーション９０４において、セキュリティチケットとクレームがリクエストから抽出される。クレームは、要求されたアクセスの範囲を定義している。チケットは、有効期限と制限を含んでいる。チケットは、同じチケットが何回使用されることがあるかを定義するオプションの反復パラメータを含んでもよい。処理は、オペレーション９０４からオプションのオペレーション９０６に移動する。
【００６３】
オプションのオペレーション９０６において、チケットが認証される。チケットは、トラステッド(trusted)サードパーティ認証、公開／私用鍵暗号化、ハッシュメッセージ認証コード（ＨＭＡＣ）暗号化などの種々のメカニズムを通して認証されてもよい。オペレーション９０６のあと、処理はオペレーション９０８に移る。
【００６４】
オペレーション９０８において、チケットのタイムスタンプが検証される。タイムスタンプが無効であれば、プロセスは停止され、アクセスがサードパーティリクエスタに対し拒否されてもよい。処理は、オペレーション９０８からオペレーション９１０に移る。
【００６５】
オペレーション９１０において、ユーザロールがセキュリティモジュールによってロードされる。処理は、オペレーション９１０からオペレーション９１２に進み、制限ロールもセキュリティモジュールによってロードされる。
【００６６】
オペレーション９１２に続くオペレーション９１４において、ユーザロールと制限ロールが要求側サードパーティプロバイダに適用可能である制限を判断するために交差される。処理はオペレーション９１４からオペレーション９１６に移る。
【００６７】
オペレーション９１６において、制限ロールとユーザロールの交差から判断された制限（およびチケットに定義された有効期限）に基づいてアクセスが要求側サードパーティプロバイダに許与される。オペレーション９１６のあと、処理は呼び出し側プロセスに移り、さらに別のアクションがとられる。
【００６８】
プロセス９００に含まれるオペレーションは例示を目的としたものである。Ｗｅｂサービスにおいてサードパーティにアクセスを許可するための転送可能な制限付きセキュリティチケットを使用することは、本明細書に記載の方式を使用して、ステップ数が追加またはより少ない類似のプロセスによって実現されてもよいし、異なるオペレーションの順序で実現されてもよい。
【００６９】
上述した明細書、例およびデータは、実施形態の構成の製造および使用を詳しく説明したものである。主題は構成上の特徴および／または方法上の動作に特有の表現で説明されているが、当然に理解されるように、請求項に定義されている主題は必ずしも上述した特定の特徴または動作に限定されない。むしろ、上述した特定の特徴および動作は、請求項および実施形態を実現する例として開示されたものである。
【図１】
2010538365.tif 000003
【図２】
2010538365.tif 000004
【図３】
2010538365.tif 000005
【図４】
2010538365.tif 000006
【図５】
2010538365.tif 000007
【図６】
2010538365.tif 000008
【図７】
2010538365.tif 000009
【図８】
2010538365.tif 000010
【図９】
2010538365.tif 000011
【国際調査報告】
2010538365.tif 000012
2010538365.tif 000013