クラウドサービス間の信頼関係構築方法及びシステム
【課題】クラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる技術を提供する。
【解決手段】本方法は、クラウドサービス間（Ｓ１，Ｓ２等）で、各自の信頼性を証明するためのチケット（Ｔ１等）を用いて、一方が他方の信頼性を確認・検証する処理手順を含む。ＩａａＳサービス（ＩＳ）上、サービス（Ｓ１等）を実現するサーバのインスタンス（Ｅ）と、パートナー契約したサービスの情報を互いに交換して管理するクラウド連携サーバ（ＣＳ）とが設けられる。インスタンス（Ｅ）は、チケット添付モジュール、チケット確認モジュールを有する。クラウド連携サーバ（ＣＳ）は、チケット検証モジュール、チケット検証連携モジュール、及び各情報のリポジトリを有する。
【解決手段】本方法は、クラウドサービス間（Ｓ１，Ｓ２等）で、各自の信頼性を証明するためのチケット（Ｔ１等）を用いて、一方が他方の信頼性を確認・検証する処理手順を含む。ＩａａＳサービス（ＩＳ）上、サービス（Ｓ１等）を実現するサーバのインスタンス（Ｅ）と、パートナー契約したサービスの情報を互いに交換して管理するクラウド連携サーバ（ＣＳ）とが設けられる。インスタンス（Ｅ）は、チケット添付モジュール、チケット確認モジュールを有する。クラウド連携サーバ（ＣＳ）は、チケット検証モジュール、チケット検証連携モジュール、及び各情報のリポジトリを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット、クラウドコンピューティングなどの技術に関する。特に、クラウドコンピューティングのようにインターネット上にあるアプリケーションなどのクラウドサービス（クラウドクラウドコンピューティングによるサービス）に対し、ユーザが必要なときに必要なものを選択して利用することができる環境・状況において、ユーザが任意にそれを選択できるという特性を残したまま、認証における信頼性を保証するための方法などに関する。
【０００２】
また特に、ＩａａＳ（Infrastructure as a Service）サービスを利用して実現されるアプリケーションサービス及びその事業者と認証サービス及びその事業者との間で、それぞれの信頼性を保証する方法などに関する。
【０００３】
また特に、エンドユーザがシングルサインオン等の方式を適用する環境におけるサービス間の信頼関係を構築する方法などに関する。
【背景技術】
【０００４】
ユーザがインターネット上にあるアプリケーション（サービス）を任意に選択し利用するクラウドコンピューティング環境では、認証に関して、ＯｐｅｎＩＤやＳＡＭＬなど、一つのＩＤで複数のサービスが利用できるシングルサインオンの仕組み（ないしその類似の方式）が利用されている。このような認証方式では、アプリケーションがユーザを認証する際、ユーザが指定した認証サービスに処理を委託して、認証結果や認証したユーザの情報を得る。これによりアプリケーションの負荷軽減やユーザの利便性向上が期待できる。
【０００５】
しかし、ユーザが自由に認証サービスを指定できるという点から、アプリケーションと認証サービスが互いに信頼できるサービスであるのかを確認する仕組みが必要となる。
【０００６】
ＩａａＳサービスとしては、公知のAmazon Elastic Compute Cloud（Amazon EC2）などに代表されるようなサービスがある。
【０００７】
シングルサインオンや認証などに関する先行技術例として、特表２００５−５１６５３３号公報（特許文献１）（「パブリックキー暗号法を用いたインターネット上でのシングルサインオン」）などがある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特表２００５−５１６５３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
前記ＯｐｅｎＩＤやＳＡＭＬなどのクラウドコンピューティングにおける認証方式（シングルサインオンなど）は、インターネット上にあるアプリケーション（サービス）が認証処理を外部委託し負荷の軽減が可能であると共に、一つのＩＤでユーザが任意に選択した複数のアプリケーションにログインでき、ユーザの利便性が向上するといった特徴を持つ。
【００１０】
しかし、認証サービスをユーザが自由に指定できることから、認証サービスの信頼性（認証サービスからアプリケーションが取得する認証情報及びユーザ情報がどれほど信頼できるのか等）、あるいは、アプリケーションの信頼性（アプリケーションに対して認証サービスはユーザ情報をどの程度開示できるのか等）、といった課題がある。
【００１１】
以上を鑑み、本発明の主な目的は、ユーザがサービスを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる技術を提供することである。
【００１２】
さらに、本発明の処理機能をモジュールとして組み込んだＩａａＳサービスとして提供可能とすることで、例えばアプリケーション事業者が簡単な設定だけで信頼性の高い認証（認証サービス）を利用することができる技術を提供することである。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明の代表的な形態は、ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス（クラウドコンピューティングによるサービス）間の信頼性を構築及び確保する、クラウドサービス間の信頼関係構築方法及びシステムなどであって、以下に示す構成を有することを特徴とする。
【００１４】
本方法及びシステムは、クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理手順及び対応する処理部（モジュール等）を含む方法及びシステムであり、インターネット上に、クラウドサービスを実現するサーバのインスタンスと、クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられる。サービスのサーバのインスタンスは、チケット添付モジュールと、チケット確認モジュールと、を有する。クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、チケットの情報と、チケットに関する暗号化・復号化のための鍵の情報と、パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有する。チケット情報は、一意の文字列を鍵により暗号化した文字列を含む。
【００１５】
一方が他方の信頼性を確認・検証する処理手順において、第１のクラウドサービスの第１のインスタンスは、第２のクラウドサービスの第２のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第１のチケットを添付して送信する。第２のクラウドサービスの第２のインスタンスは、第１のチケットをチケット確認モジュールにより第２のクラウド連携サーバへ送信して検証を依頼する。第２のクラウド連携サーバは、第１のチケットを、チケット検証モジュールによりリポジトリの情報を参照して検証する。上記検証できた場合は、結果を第２のインスタンスへ送信することにより第２のサービスが第１のサービスの信頼性を確認できる。上記検証できなかった場合は、他のクラウドサービスのクラウド連携サーバへ、チケット検証連携モジュールにより第１のチケットの検証の依頼を送信する。他のクラウドサービスのクラウド連携サーバは、上記第２のクラウド連携サーバと同様に、第１のチケットを、チケット検証モジュールによりリポジトリの情報を参照して検証し、結果を第２のクラウド連携サーバへ送信する。
【発明の効果】
【００１６】
本発明の代表的な形態によれば、ユーザがサービスを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる。
【００１７】
さらに、本発明の処理機能をモジュールとして組み込んだＩａａＳサービスとして提供可能とすることで、例えばアプリケーション事業者が簡単な設定だけで信頼性の高い認証（認証サービス）を利用することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態の方法及びシステム（クラウドサービス間の信頼関係構築方法及びシステム）の全体の概要構成を示す図である。
【図２】本実施の形態におけるサーバ（ＩａａＳサービス）の構成を示す図である。
【図３】本実施の形態におけるクラウドリポジトリの情報の一例を示す図である。
【図４】本実施の形態におけるキーリポジトリの情報の一例を示す図である。
【図５】本実施の形態におけるチケットリポジトリの情報の一例を示す図である。
【図６】本実施の形態における各リポジトリの情報の関係を示すＥＲ図である。
【図７】本実施の形態におけるチケットの構成を示す図である。
【図８】本実施の形態における各サーバ・モジュール等の関連の動作（処理例）を示す図である。
【図９】本実施の形態でチケット添付モジュールの処理を示すフローチャートである。
【図１０】本実施の形態でチケット確認モジュールの処理を示すフローチャートである。
【図１１】本実施の形態でチケット検証モジュールの処理を示すフローチャートである。
【図１２】本実施の形態でチケット検証連携モジュールの処理を示すフローチャートである。
【図１３】本実施の形態の基本的な構成などを補足するための説明図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態（クラウドサービス間の信頼関係構築方法及びシステム）を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００２０】
本実施の形態では、概要として、図１，図２，図１３等の構成に基づき、図３〜図７のようなデータ情報を用いて、図８の例に示すように各部（サーバ、モジュール等）間で動作する。図９〜図１２は各部の個別の処理を示す。特徴的な要素として各モジュール（図２、２１，２２，３１，３２等）やチケット（図２、４１）等を有する。複数のクラウドサービス間、例えば図８のＩＳ１，Ｅ１のアプリケーション（８０３）のサービス（Ｓ１）と、ＩＳ２，Ｅ２の認証モジュール（８０８）のサービス（Ｓ２）との間において、各自の信頼性を証明するためのチケット４１（例えばＥ１側の信頼性を証明するためのチケットＴ１（８０５）や、Ｅ２側の信頼性を証明するためのチケットＴ２）を用いて、互いに信頼性の確認・検証を行う仕組みを有する。
【００２１】
［基本］
図１，図２，図１３等に基づき、本実施の形態の方法及びシステムにおける基本的な前提や方式などについて以下である。インターネット上、パートナー契約などによる互いに信頼できるＩａａＳサービス１００間で、それぞれに、一意な識別子、一意な文字列、及び共通の暗号化・復号化の鍵情報を持たせる。次にこれらの情報を管理するサーバ（クラウド連携サーバ３００）をそれぞれのＩａａＳサービス１００環境上に構築する（図１）。これを前提として、ＩａａＳサービス事業者（Ｐ）は、ＩａａＳサービス１００のインスタンス２００（サーバ）を提供し、アプリケーション事業者や認証サービス事業者などのサービス利用者（Ｑ）は、上記インスタンス２００（サーバ）を利用して各自のサービス（アプリケーションや認証サービスなど）をエンドユーザに対し提供する（図１３）。
【００２２】
上記サービスの利用・提供の際は、例えば、サービス利用者（Ｑ）がＩａａＳサービス事業者（Ｐ）に対して利用申請を行い、ＩａａＳサービス事業者（Ｐ）は当該サービス利用者（Ｑ）が十分に信頼できる事業者であるかどうか審査し、審査の結果、信頼できる事業者である場合、当該ＩａａＳサービス１００で持つ一意な文字列や、それを利用するためのモジュール（図２）が組み込まれたサーバ（インスタンス２００）を用意（割り振り、提供）する（図１）。上記サーバ（インスタンス２００）上に、各サービス利用者（Ｑ）は、自身のアプリケーション（サービスＳ１）や認証サービス（サービスＳ２）などを構築して当該サービスをエンドユーザに提供する（図１３）。あるＩａａＳサービス事業者（Ｐ）を利用してアプリケーション（Ｓ１）を提供する事業者（Ｑ１）の場合も、別のＩａａＳサービス事業者（Ｐ２）を利用して認証サービス（Ｓ２）を提供する事業者（Ｑ）の場合も、同様の手順である。
【００２３】
上記サービスの提供・構築の際、当該サーバ（インスタンス２００）には、予め、本発明で特徴的なモジュール（図２）が組み込まれる。エンドユーザから当該サーバ（サービス）へのアクセス（リクエスト、レスポンス等）の際には、当該サーバ（インスタンス２００）に組み込まれているモジュールが自動的に呼び出され特徴的な処理を行うという構成である。
【００２４】
エンドユーザ（対応する端末等）は、ＯｐｅｎＩＤやＳＡＭＬなどの所定のシングルサインオン等の方式に基づき、上記サービスを開始したアプリケーション（Ｓ１）や認証サービス（Ｓ２）を自由に選択して利用する（図１３）。エンドユーザが例えばアプリケーションのサービスＳ１にアクセスした際、当該エンドユーザの認証が済んでいない場合は、当該アプリケーション（Ｓ１）から認証サービス（Ｓ２）に遷移して認証処理を行う。認証が済んでいる場合は、当該アプリケーション（Ｓ１）から、ユーザ情報を利用してエンドユーザにサービス処理が提供される。
【００２５】
上記認証の際、アプリケーション（Ｓ１）側は、当該インスタンス２００（Ｅ１）で持つチケット４１（Ｔ１）を用いて、自身の信頼性を認証サービス（Ｓ２）側に対して証明する（言い換えればＳ２側はＴ１を参照してＳ１側を確認・検証する）。同様に、認証サービス（Ｓ２）側は、当該インスタンス２００（Ｅ１）で持つチケット４１（Ｔ２）を用いて、自身の信頼性をアプリケーション（Ｓ１）側に対して証明する（言い換えればＳ１側はＴ２を参照してＳ２側を確認・検証する）。
【００２６】
例えば、アプリケーション（Ｓ１）側は、エンドユーザに関する認証処理を認証サービス（Ｓ２）へ要求する際、Ｅ１のチケットＴ１を添付して送信し、認証サービス（Ｓ２）側は当該チケットＴ１を用いた確認・検証を行う（図１３のａ１）。例えば、認証サービス（Ｓ２）側は、エンドユーザに関する認証処理の後、認証結果を含む認証情報に、Ｅ２のチケットＴ２を添付して、アプリケーション（Ｓ１）側に送信し、アプリケーション（Ｓ１）側は、当該チケットＴ２を用いた確認・検証を行う（図１３のａ２）。
【００２７】
上記チケット４１を用いた信頼性の確認・検証の際は、ＩａａＳサービス１００上のインスタンス２００のチケット確認モジュール（図２の２１）、同ＩａａＳサービス１００上のクラウド連携サーバ３００上のチケット検証モジュール（図２の３１）及びチケット検証連携モジュール（図２の３２）を用いて行う（詳しくは図８）。依頼元からチケット確認モジュール２１に確認を依頼し、チケット確認モジュール２１からチケット検証モジュール３１に検証を依頼する。
【００２８】
チケット検証モジュール３１は、自ＩａａＳサービス１００内のリポジトリの情報（ＩａａＳサービス情報）を参照して検証を試みる。検証ができた場合は、結果を依頼元などへ送信する。自ＩａａＳサービス１００内のチケット検証モジュール３１で当該チケットの検証ができない場合（該当ＩａａＳサービス情報などが登録されていない場合など）は、チケット検証連携モジュール３２を用いて、信頼できる他（パートナー）のＩａａＳサービス１００上のチケット検証モジュール３１に検証を依頼（問い合わせ）する。同様に複数のＩａａＳサービス１００間で繰り返し検証の連携が可能となっている。
【００２９】
図１３は、説明の補足として、ＩａａＳサービス事業者（Ｐ）、アプリケーション事業者や認証サービス事業者（サービス利用者（Ｑ））、及びエンドユーザ間の関係などを示している。図１３の例では、ＩＳ１を提供するＰ１と、ＩＳ２を提供するＰ２とがパートナー契約しており、Ｐ１（ＩＳ１）は、Ｑ１のサービスＳ１（アプリケーション）のためにインスタンスＥ１を提供しており、Ｐ２（ＩＳ２）は、Ｑ２のサービスＳ２（認証サービス）のためにインスタンスＥ２を提供している。
【００３０】
［システム構成］
図１は、本発明の一実施の形態の方法及びシステム（クラウドサービス間の信頼関係構築方法及びシステム）の全体の概要構成を示している。クラウドコンピューティング環境を含むインターネット上に、複数のＩａａＳサービス１００が存在する。なおＩａａＳサービスを記号ＩＳで表す。図１の例では３つのＩａａＳサービス１００（１０１〜１０３）としてＩＳ１〜ＩＳ３を有する。ＩａａＳサービス１００は、クラウドコンピューティングによるサービスである。各ＩａａＳサービス１００は、対応するＩａａＳサービス事業者（記号Ｐで表す（Ｐ１〜Ｐ３等））や情報処理システム等（サービス処理を実現するハードウェア・ソフトウェア等の技術的な構成、例えばサーバ）が存在する。なおＩａａＳサービス１００等を実現する前提的なサーバ等の詳細については公知技術であるため説明は省略する。
【００３１】
各ＩａａＳサービス１００の事業者（Ｐ）は、それぞれが一意な識別子、一意な文字列、及び当該文字列を暗号化及び復号化するための鍵情報（記号Ｋで表す）を持つ。複数のＩａａＳサービス１００の事業者Ｐは、互いにパートナー契約を結び、これらの情報（識別子、文字列、鍵）を互いに交換している。図１の例では、ＩＳ１（１０１）の事業者Ｐ１とＩＳ２（１０２）の事業者Ｐ２がパートナー契約を結んでおり、ＩＳ２（１０２）の事業者Ｐ２とＩＳ３（１０３）の事業者Ｐ３がパートナー契約を結んでいる。
【００３２】
各ＩａａＳサービス１００上には、ＩａａＳサービス情報を管理するクラウド連携サーバ３００（記号ＣＳで表す）が存在し、上記契約時に交換した情報（識別子、文字列、鍵）（ＩａａＳサービス情報）を管理している。クラウド連携サーバ（ＣＳ）３００は、ＩＳ事業者（Ｐ）が１台ずつ持つ。図１の例では３つのクラウド連携サーバ３００（３０１〜３０３）としてＣＳ１〜ＣＳ３を有する。
【００３３】
上記のような環境（図１）を持つＩａａＳサービス事業者（Ｐ）に対して、アプリケーション事業者などのサービス利用者（記号Ｑで表す）がサービス（記号Ｓで表す）の利用申請を行い、当該サービス（Ｓ）に対応するインスタンス２００が割り振られる。図１の例では、各ＩＳ１００上にインスタンス２００（２０１〜２０３）を有する。
【００３４】
また、上記申請があった際、ＩａａＳサービス事業者（Ｐ）は、申請しているアプリケーション事業者（サービス利用者（Ｑ））が十分に信頼できることを確認（審査などによる）してインスタンス２００を提供する。このインスタンス２００には、ＩａａＳサービス事業者（Ｐ）が持つ一意の文字列とそれを操作するためのモジュールが含まれている。
【００３５】
［ＩａａＳサービス］
図２において、ＩａａＳサービス（ＩＳ）１００の構成、ＩＳ１００上にあるクラウド連携サーバ（ＣＳ）３００とインスタンス(Ｅ）２００の構成について説明する。本発明の構成要素として、２１，２２，４１，４２，３１，３２，５０，５１，５２等がある。インスタンス(Ｅ）２００は、ＩＳ１００上の標準インスタンスを示す。各インスタンス(Ｅ）２００及びＣＳ３００は主にサーバ（ハードウェア及びソフトウェア）により構成され、各モジュールは当該サーバでのソフトウェアプログラム処理などにより構成される。尚これらサーバ（サービス、インスタンス）等の基本的な構成は公知技術（クラウドコンピューティング等）であるため詳細な説明は省略する。
【００３６】
［クラウド連携サーバ］
クラウド連携サーバ（ＣＳ）３００は、チケット検証モジュール３１、チケット検証連携モジュール３２、キーリポジトリ５０、チケットリポジトリ５１、及びクラウドリポジトリ５２、等を有する。
【００３７】
チケット検証モジュール３１は、ＩａａＳサービス１００の持つチケット（記号Ｔで表す）（４１と対応）を確認するためのモジュール（処理部）である。
【００３８】
チケット検証連携モジュール３２は、他のＩａａＳサービス１００にチケット検証を依頼するためのモジュールである。
【００３９】
キーリポジトリ５０は、契約したＩａａＳサービス１００間で交換した鍵情報（Ｋ）を保管するためのリポジトリである。
【００４０】
チケットリポジトリ５１は、契約したＩａａＳサービス１００間で交換したチケット（Ｔ）の情報を保管するためのリポジトリである。
【００４１】
クラウドリポジトリ５２は、契約したＩａａＳサービス１００の識別子などの情報を保管するためのリポジトリである。
【００４２】
［リポジトリ］
図３は、クラウドリポジトリ５２が持つ情報の一例を示す。本テーブル例では、ＩＤ、ＩａａＳ事業者名称、事業者識別子、チケット検証サーバ、等の項目を有するレコードから成る。「ＩａａＳ事業者名称」、「事業者識別子」は、前記Ｐの名称や識別子である。「チケット検証サーバ」は、チケット検証モジュール３１に対応したアドレス（ＵＲＬ）情報である。
【００４３】
図４は、キーリポジトリ５０が持つ情報の一例を示す。本テーブル例では、ＩＤ、ＩａａＳ事業者、キー（鍵）、等の項目を有するレコードから成る。「ＩａａＳ事業者」は、当該鍵（Ｋ）に対応する前記ＰのＩＤである。「キー（鍵）」（Ｋ）は、数値・文字列などである。
【００４４】
図５は、チケットリポジトリ５１が持つ情報の一例を示す。本テーブル例では、ＩＤ、ＩａａＳ事業者、チケット（Ｔ）、等の項目を有するレコードから成る。「ＩａａＳ事業者」は、当該チケット（Ｔ）に対応する前記ＰのＩＤである。チケット（Ｔ）は、数値・文字列などである。
【００４５】
図６は、上記リポジトリ（５０，５１，５２）のそれぞれの情報（６０１〜６０３）の関係を示すＥＲ図である。各テーブルのＩＤは主キーとなる。図３のクラウドリポジトリ５２の情報（６０１）の「ＩａａＳ事業者名称」（ＩａａＳプロバイダ）、及び「事業者識別子」（クラウド識別子）、図４のキーリポジトリ５０の情報（６０２）の「ＩａａＳ事業者」（ＩａａＳプロバイダ）、図５のチケットリポジトリ５１の情報（６０３）の「ＩａａＳ事業者」（ＩａａＳプロバイダ）は、ユニークキーである。
【００４６】
［インスタンス］
前記図２で、一方、アプリケーション事業者（サービス利用者（Ｑ））が利用するインスタンス（Ｅ）２００は、チケット添付モジュール２１、チケット確認モジュール２２、チケット４１、プロパティ４２、等を有する。
【００４７】
チケット添付モジュール２１は、アプリケーションサービス（サービスＳ）にチケット（Ｔ）（４１と対応）を添付するためのモジュールである。
【００４８】
チケット確認モジュール２２は、上記添付されたチケット（Ｔ）を確認するためのモジュールである。
【００４９】
チケット４１は、上記添付するチケット（Ｔ）のデータ情報であり、当該ＩＳのインスタンス（Ｅ）であることを証明する情報である。チケット（Ｔ）や鍵（Ｋ）の情報は、基本的に、各サービスで秘密情報であり、契約サービス間では共通情報となる。
【００５０】
図７は、チケット４１（Ｔ）の構成を示す。チケット４１（Ｔ）は、事業者識別子７０１と、暗号化文字列７０２（一意な文字列を鍵により暗号化した文字列）とを有する。事業者識別子７０１は、ＩＳ事業者（Ｐ）が持つ固有の識別子の文字列である（この識別子はクラウドリポジトリ５２で管理されている）。暗号化文字列７０２の元となる一意な文字列は、チケットリポジトリ５１（図５）の「チケット」文字列を用い、この「チケット」文字列を、自ＩＳの鍵Ｋ（キーリポジトリ５０（図４）の「キー」文字列）で暗号化することにより得られる。
【００５１】
プロパティ２０６は、チケット確認モジュール２２によるチケット検証の依頼先などの情報（ＣＳ３００（またはそのチケット検証モジュール３１）のアドレス情報など）が記載されたプロパティファイル情報である。
【００５２】
インスタンス２００は、上述の状態をテンプレートとして、各アプリケーション事業者（Ｑ）に、コピーにて展開（割り振り、提供）され、それぞれのアプリケーション（サービス）を組み込み利用する。また、インスタンス２００が持つチケット４１（Ｔ）は、図７の通り、事業者識別子７０１と暗号化文字列７０２とを結合した文字列となる。
【００５３】
［動作］
次に、図８を用いて、本実施の形態における各モジュール等の関連の動作（処理例）について説明する。ＯｐｅｎＩＤやＳＡＭＬなどのシングルサインオンあるいはそれに類する方式を適用するものとする。図８では、インターネット上の複数のＩＳ１００（ＩＳ１〜ＩＳ３）の例として、まず、第１のＩＳ事業者Ｐ１による第１のＩａａＳサービス（ＩＳ１）８０１上にある第１のインスタンス８０２（Ｅ１）を利用して、アプリケーション事業者（第１のサービス利用者Ｑ１）が当該アプリケーションのサービスＳ１を提供している。また、第２のＩＳ事業者Ｐ２による第２のＩａａＳサービス（ＩＳ２）８０６上にある第２のインスタンス（Ｅ２）８０７を利用して、認証サービス事業者（第２のサービス利用者Ｑ２）が認証サービス（サービスＳ２）を提供している。他にも、第３のＩＳ事業者Ｐ３による第３のＩａａＳサービス（ＩＳ３）８１９等が存在する。パートナー契約の状態として例えば、Ｐ１−Ｐ２間は無しまたは有り、Ｐ２−Ｐ３間は有り、Ｐ３−Ｐ１間は有り、とする。
【００５４】
第１のインスタンス８０２（Ｅ１）上には、アプリケーション事業者（Ｑ１）が提供するアプリケーションプログラム８０３（サービスＳ１の処理を実現するプログラム、例えばＷｅｂアプリケーションプログラム）がある。第２のインスタンス（Ｅ２）８０７上には、認証サービス事業者（Ｑ２）が提供する認証モジュール８０８（サービスＳ２のプログラム）がある。
【００５５】
適用するシングルサインオン等の方式に応じて、アプリケーションプログラム８０３は、ユーザ（８０３にアクセスし利用するエンドユーザ）が指定した認証サービス（本例ではインスタンス（Ｅ２）８０７上の認証モジュール８０８によるサービスＳ２）に認証処理を依頼（要求）する。そのために、アプリケーションプログラム８０３は、同一インスタンス（Ｅ１）内にあるチケット添付モジュール８０４（図２の２１）を呼び出す。チケット添付モジュール８０４は、チケット８０５（図２の４１）（ＩＳ１のインスタンス（Ｅ１）であることを証明するチケット：Ｔ１とする）を読み込み、当該チケット（Ｔ１）を、認証要求に関するレスポンスヘッダ情報に付加する。
【００５６】
図９に上記チケット添付モジュール８０４の処理の詳細を示す（後述）。
【００５７】
上記チケット添付モジュール８０４の処理（チケット（Ｔ１）添付）の終了後、アプリケーションプログラム８０３は、適用するシングルサインオン等の方式に則り、認証サービス事業者（Ｑ２）が提供する認証モジュール８０８（サービスＳ２）に対して認証処理を依頼（認証要求）する。この認証要求には、上記チケット（Ｔ１）情報が伴う。
【００５８】
第２のＩａａＳサービス（ＩＳ２）８０６上のインスタンス（Ｅ２）８０７上には、認証サービス事業者（Ｑ２）が開発した認証モジュール８０８が動作している。認証モジュール８０８は、認証サービス（第２のサービスＳ２）を提供するモジュール（プログラム）である。アプリケーションプログラム８０３（チケット添付モジュール８０４）から上記認証要求（チケット（Ｔ１）付き）を受けた認証モジュール８０８は、認証結果などを提供する対象となるアプリケーション（８０３）が信頼できるのかを判断するために、同一インスタンス（Ｅ２）内にあるチケット確認モジュール８０９（図２の２２）に、当該チケット（上記認証要求に伴うチケット（Ｔ１））の確認を依頼する。
【００５９】
チケット確認モジュール８０９は、プロパティ８１０（図２の４２）（ＩＳ２のＣＳ２のアドレス情報を含むプロパティファイル情報）を参照し、チケット検証処理を行うチケット検証サーバとなるチケット検証モジュール８１２（図２の３１）のアドレス情報を取得する。そして、チケット確認モジュール８０９は、当該チケット（Ｔ１）情報を、ＩＳ２で稼動するクラウド連携サーバ８１１（ＣＳ２）上にある当該チケット検証モジュール８１２へ送信する。
【００６０】
上記チケット（Ｔ１）情報を受け取ったチケット検証モジュール８１２は、当該チケット（Ｔ１）から、図７（７０１，７０２）に示したような、識別子８１３と暗号化文字列８１４の情報（文字列）を取得する。また、チケット検証モジュール８１２は、同ＣＳ２内のクラウドリポジトリ８１８（図２の５２）とキーリポジトリ８１６（図２の５０）を参照して、当該チケット（Ｔ１）（そのうちの暗号化文字列７０２）の復号化のための鍵（Ｋ）を取得する。
【００６１】
ここで、初回の状況では、ＩＳ１（Ｐ１）とＩＳ２（Ｐ２）との間で、まだパートナー契約が無く、そのため、当該リポジトリに、ＩＳ１に対応する識別子と鍵（Ｋ）等の情報が存在しない（即ち上記Ｔ１に対応する鍵Ｋ１を取得できない）状態とする。そのため、チケット検証モジュール８１２は、チケット検証連携モジュール８１５（図２の３２）に、他のＩＳ１００に対するチケット検証処理を依頼する。
【００６２】
なおＩＳ２（ＣＳ２）のリポジトリに上記ＩＳ１に対応する情報が登録済みの場合は、ＩＳ２にて当該チケット（Ｔ１）の検証処理が行われることになる。
【００６３】
上記依頼を受けたチケット検証連携モジュール８１５は、他のＩＳ１００に対するチケット検証処理依頼のために、同ＣＳ２内のクラウドリポジトリ８１８（図２の５２）を参照し、ＩＳ２と契約しているＩａａＳサービス１００、本例ではＩＳ３（８１９）、の情報を取得する。詳しくは、ＩＳ３上で稼働するＣＳ３（８２１）上のチケット検証サーバ（チケット検証モジュール８２１）のアドレス情報を取得する。そして、チケット検証連携モジュール８１５は、当該取得したＩＳ３（ＣＳ３）のアドレスに対してチケット検証処理依頼を転送（送信）する。この際、検証依頼には、検証対象のチケット（Ｔ１）情報を伴う。
【００６４】
上記検証依頼を受け取ったＩＳ３（８１９）上のＣＳ３（８２０）上にあるチケット検証モジュール８２１は、上記検証対象のチケット（Ｔ１）から取得した識別子８２２（７０１）をもとに、ＣＳ３上のクラウドリポジトリ８２６とキーリポジトリ８２４を参照して、当該チケット（Ｔ１）（その暗号化文字列８２３（７０２））の復号化のための鍵（本例ではＩＳ１のＫ１）を取得する。ここではＰ１−Ｐ３間の契約有りによりＣＳ３内に当該ＩＳ１に関する情報（Ｋ１を含む）が登録済みの状態であるため当該情報を取得できる場合である。
【００６５】
チケット検証モジュール８２１は、取得した鍵（Ｋ１）を用いて当該チケット（Ｔ１）の暗号化文字列８２３（７０２）を復号化した後、クラウドリポジトリ８２６とキーリポジトリ８２５を参照し、当該識別子（８２２）と文字列（上記８２３を復号化した文字列）の組み合わせが正しいかを確認する。即ち当該チケットの有効性・無効性を判断するチケット検証処理を行う。当該組み合わせが正しいという結果（ＯＫ）の場合、当該チケットは有効となり、正しくないという結果（ＮＧ）の場合、無効となる。ＯＫの場合、当該チケット（Ｔ１）がＩＳ１のインスタンス（Ｅ１）であることを証明する情報であることが確認できる。
【００６６】
ＩＳ３のＣＳ３のチケット検証モジュール８２１は、上記確認（チケット検証処理）の結果を、ＩＳ２のＣＳ２のチケット検証連携モジュール８１５へ返す。更に、当該結果は、チケット検証連携モジュール８１５からチケット検証モジュール８１２へ、チケット検証モジュール８１２からＥ２（８０７）のチケット確認モジュール８０９へ、チケット確認モジュール８０９から認証モジュール８０８へと、順に返される（図８に示す流れの逆）。
【００６７】
上記チケット検証処理の結果でＯＫ（Ｔ１有効）の場合、対象アプリケーション（８０３）の信頼性を確認できたことになる。そのため、認証モジュール８０８は、前記依頼されている認証処理（認証サービス（Ｓ２）の処理）を行い、認証結果及びユーザの属性情報を認証情報として、適用するシングルサインオン等の方式に則り、Ｅ１（８０２）上のアプリケーションプログラム８０３へ伝える（送信する）。
【００６８】
また、上記結果でＮＧ（Ｔ１無効）の場合、対象アプリケーション（８０３）の信頼性を確認できなかったため、認証モジュール８０８は、適用するシングルサインオン等の方式に則り、前記依頼されている認証処理ができないことを、Ｅ１のアプリケーションプログラム８０３に伝える。
【００６９】
図１０に、上記チケット確認モジュール８０９の処理の詳細を示す（後述）。
【００７０】
図１１に、上記ＩＳ２上のチケット検証モジュール８１２とＩＳ３上のチケット検証モジュール８２１の処理の詳細を示す（後述）。
【００７１】
図１２に、上記ＩＳ２上のチケット検証連携モジュール８１５の処理の詳細を示す（後述）。
【００７２】
なお、上記（図８）では、ＩＳ１のチケットＴ１を用いてアプリケーション（８０３）側の信頼性を認証モジュール８０８側が確認・検証する流れを説明しているが、ＩＳ２のチケットＴ２を用いて認証モジュール８０８側の信頼性をアプリケーション（８０３）側が確認・検証する場合なども同様となる。即ち例えば、上記（図８）で認証モジュール８０８が認証情報（認証結果とユーザの属性情報）をアプリケーション（８０３）へ返す際に、アプリケーション（８０３）側が当該認証モジュール８０８側の認証情報が信頼できるのかを判断させる（判断できるようにする）ために、当該認証情報に、Ｅ２上にあるチケットＴ２（ＩＳ２のインスタンス（Ｅ２）であることを証明するチケット）の情報を添付する。この際、アプリケーション（８０３）側が当該チケットＴ２を確認・検証する手順については、上記認証モジュール８０８側がチケットＴ１を確認・検証した手順と同様となる。
【００７３】
以上（図８）の流れにより、アプリケーションサービス（Ｓ１）側と認証サービス（Ｓ２）側とで相互に信頼性を確認した通信ができる。
【００７４】
［チケット添付モジュール処理］
図９において、チケット添付モジュール２１（例えば８０４）は、まず、呼び出し元（プログラム（８０３））から処理要求を受け付る（９０１）。即ち、同一インスタンス２００（例えばＥ１）上で動作するプログラム（８０３）から、レスポンス情報を受け取る。次に、同一インスタンス２００（Ｅ１）内にあるチケット情報（４１）を読み込む（９０２）。このチケット（例えばＴ１）は、図７の通り、暗号化文字列７０２は、自ＩＳ（例えばＩＳ１）に対応する一意の文字列（例えばＵＳ１）が、自ＩＳの鍵（例えばＫ１）により暗号化されている。次に、上記読み込んだチケット情報（４１）をＢＡＳＥ６４変換する（９０３）。次に、上記変換したチケット情報（４１）を、レスポンス情報のLocationヘッダのＵＲＬにＵＲＬパラメータとして付加する（９０４）。次に、上記編集したリクエスト情報（チケット付き）を呼び出し元（プログラム（８０３））に戻す（９０５）。
【００７５】
［チケット確認モジュール処理］
図１０において、チケット確認モジュール２２（例えば８０９）は、まず、呼び出し元から処理要求を受け取る（１００１）。即ち、同一インスタンス２００（Ｅ２）上で動作するプログラム（認証モジュール８０８）から、リクエスト情報を受け取る。次に、受け取ったリクエスト情報のヘッダ情報から、リクエストＵＲＬ（ＵＲＬパラメータ）に付加されているチケット情報を取得する（１００２）。次に、プロパティ４２（８１０）の参照から、同一ＩＳ上のクラウド連携サーバ（ＣＳ）３００のアドレス情報を取得する（１００３）。次に、当該アドレスのＣＳ（チケット検証サーバ）へ当該チケット情報をＳＯＡＰで転送（送信）する（１００４）。次に、当該ＣＳ（チケット検証サーバ）から、当該チケットの有効性・無効性の判定結果（チケット検証処理結果）を受け取る（１００５）。次に、上記取得した判定結果を、呼び出し元のプログラム（８０８）に返す（１００６）。
【００７６】
［チケット検証モジュール処理］
図１１において、チケット検証モジュール３１（例えば８１２，８２１）は、まず、インスタンス２００（例えばＥ２）のチケット確認モジュール２２（例えば８０９）から対象のチケット情報（変換状態）を受け取る（１１０１）。次に、受け取ったチケット情報に対してＢＡＳＥ６４デコーディングを行い、チケットデータ（例えばＴ１）を取得する（１１０２）。次に、取得したチケットデータ（Ｔ１）から、事業者識別子（７０１，８１８）（クラウド識別子）を取得し、この識別子を検索キーとしてクラウドリポジトリ５２の参照に基づき対応するＩＳ（例えばＩＳ１）の情報を取得し、取得した情報を用いてキーリポジトリ５０から対象（ＩＳ１）の鍵情報（例えばＫ１）を取得する。
【００７７】
上記対象の鍵（Ｋ１）を取得できた場合（１１０３−Ｙ）、チケットデータ（Ｔ１）から暗号化文字列（７０２，８１４）を取得し（１１０４）、取得した暗号化文字列を上記鍵（Ｋ１）により復号化する（１１０５）。そして、チケットリポジトリ５１を参照し、上記クラウド識別子（事業者識別子）とチケットが合致するデータを取得する（１１０６）。
【００７８】
上記合致するデータがある場合（１１０８−Ｙ）、該当インスタンス２００（例えばＥ２）のチケット確認モジュール２２（８０９）に、当該チケット（Ｔ１）が有効であることを伝え、合致するデータが無い場合（１１０８−Ｎ）、無効であることを伝える。
【００７９】
前記対象の鍵（Ｋ１）を取得できなかった場合（１１０３−Ｎ）、チケット検証モジュール３１は、同ＣＳ３００（例えばＣＳ２）内のチケット検証連携モジュール３２（例えば８１５）に、当該チケットデータ（Ｔ１）を引き渡し、当該チケット（Ｔ１）の確認（検証）処理を依頼する（１１１１）。そして、チケット検証連携モジュール３２から返ってきたチケット確認（検証）結果を、該当インスタンス２００（Ｅ２）のチケット確認モジュール２２（８０９）に伝える。
【００８０】
［チケット検証連携モジュール処理］
図１２において、チケット検証連携モジュール３２（例えば８１５）は、まず、チケット検証モジュール３１（例えば８１２）から事業者識別子（７０１）を含むチケットデータ（前記１１１１の依頼）を受け取る（１２０１）。次に、クラウドリポジトリ５２から、上記事業者識別子（クラウド識別子）を検索キーとして連携可能なクラウド連携サーバ（ＣＳ）３００の情報を取得する（１２０２）。次に、連携可能なＣＳ（例えばＣＳ３（８２０））に、当該チケットデータをＳＯＡＰで送信する。
【００８１】
チケット検証連携モジュール３２は、連携可能なＣＳ（ＣＳ３）のチケット検証モジュール３１（８２１）によるチケット検証結果を待ち受けて取得する（１２０３）。そして、当該検証結果を、依頼元のチケット検証モジュール３１（８１２）に渡す（１２０４）。
【００８２】
［効果等］
以上のように、本実施の形態によれば、クラウドサービス（ＩＳ事業者（Ｐ）から提供されるインスタンス２００によるサービスＳ）間のシングルサインオン等の方式の通信における信頼関係を構築・確保することができ、ユーザがサービスＳを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービス（図１３ではＳ２）の提供・利用が可能となる。さらに、本発明の特徴的な処理機能をモジュール（２１，２２，３１，３２）として組み込んだＩａａＳサービス１００（サーバ）をサービス利用者（Ｑ）に提供することにより、例えばアプリケーション事業者（図１３ではＱ１）が簡単な設定だけで信頼性の高い認証を利用できる。
【００８３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【００８４】
本発明は、クラウドコンピューティング環境における、ＩａａＳサービス、アプリケーションサービス、認証サービスなどの各種サービスに利用可能である。
【符号の説明】
【００８５】
２１，８０４…チケット添付モジュール、２２，８０９…チケット確認モジュール、３１，８１２，８２１…チケット検証モジュール、３２，８１５…チケット検証連携モジュール、４１，８０５…チケット、４２，８１０…プロパティ、５０，８１６，８２４…キーリポジトリ、５１，８１７，８２５…チケットリポジトリ、５２，８１８，８２６…クラウドリポジトリ、１００（１０１〜１０３），８０１，８０６，８１９…ＩａａＳサービス（ＩＳ）、２００（２０１〜２０３），８０２，８０７…インスタンス（Ｅ）、３００（３０１〜３０３），８１１，８２０…クラウド連携サーバ（ＣＳ）、８０３…アプリケーションプログラム、８０８…認証モジュール。
【技術分野】
【０００１】
本発明は、インターネット、クラウドコンピューティングなどの技術に関する。特に、クラウドコンピューティングのようにインターネット上にあるアプリケーションなどのクラウドサービス（クラウドクラウドコンピューティングによるサービス）に対し、ユーザが必要なときに必要なものを選択して利用することができる環境・状況において、ユーザが任意にそれを選択できるという特性を残したまま、認証における信頼性を保証するための方法などに関する。
【０００２】
また特に、ＩａａＳ（Infrastructure as a Service）サービスを利用して実現されるアプリケーションサービス及びその事業者と認証サービス及びその事業者との間で、それぞれの信頼性を保証する方法などに関する。
【０００３】
また特に、エンドユーザがシングルサインオン等の方式を適用する環境におけるサービス間の信頼関係を構築する方法などに関する。
【背景技術】
【０００４】
ユーザがインターネット上にあるアプリケーション（サービス）を任意に選択し利用するクラウドコンピューティング環境では、認証に関して、ＯｐｅｎＩＤやＳＡＭＬなど、一つのＩＤで複数のサービスが利用できるシングルサインオンの仕組み（ないしその類似の方式）が利用されている。このような認証方式では、アプリケーションがユーザを認証する際、ユーザが指定した認証サービスに処理を委託して、認証結果や認証したユーザの情報を得る。これによりアプリケーションの負荷軽減やユーザの利便性向上が期待できる。
【０００５】
しかし、ユーザが自由に認証サービスを指定できるという点から、アプリケーションと認証サービスが互いに信頼できるサービスであるのかを確認する仕組みが必要となる。
【０００６】
ＩａａＳサービスとしては、公知のAmazon Elastic Compute Cloud（Amazon EC2）などに代表されるようなサービスがある。
【０００７】
シングルサインオンや認証などに関する先行技術例として、特表２００５−５１６５３３号公報（特許文献１）（「パブリックキー暗号法を用いたインターネット上でのシングルサインオン」）などがある。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特表２００５−５１６５３３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
前記ＯｐｅｎＩＤやＳＡＭＬなどのクラウドコンピューティングにおける認証方式（シングルサインオンなど）は、インターネット上にあるアプリケーション（サービス）が認証処理を外部委託し負荷の軽減が可能であると共に、一つのＩＤでユーザが任意に選択した複数のアプリケーションにログインでき、ユーザの利便性が向上するといった特徴を持つ。
【００１０】
しかし、認証サービスをユーザが自由に指定できることから、認証サービスの信頼性（認証サービスからアプリケーションが取得する認証情報及びユーザ情報がどれほど信頼できるのか等）、あるいは、アプリケーションの信頼性（アプリケーションに対して認証サービスはユーザ情報をどの程度開示できるのか等）、といった課題がある。
【００１１】
以上を鑑み、本発明の主な目的は、ユーザがサービスを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる技術を提供することである。
【００１２】
さらに、本発明の処理機能をモジュールとして組み込んだＩａａＳサービスとして提供可能とすることで、例えばアプリケーション事業者が簡単な設定だけで信頼性の高い認証（認証サービス）を利用することができる技術を提供することである。
【課題を解決するための手段】
【００１３】
上記目的を達成するため、本発明の代表的な形態は、ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス（クラウドコンピューティングによるサービス）間の信頼性を構築及び確保する、クラウドサービス間の信頼関係構築方法及びシステムなどであって、以下に示す構成を有することを特徴とする。
【００１４】
本方法及びシステムは、クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理手順及び対応する処理部（モジュール等）を含む方法及びシステムであり、インターネット上に、クラウドサービスを実現するサーバのインスタンスと、クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられる。サービスのサーバのインスタンスは、チケット添付モジュールと、チケット確認モジュールと、を有する。クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、チケットの情報と、チケットに関する暗号化・復号化のための鍵の情報と、パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有する。チケット情報は、一意の文字列を鍵により暗号化した文字列を含む。
【００１５】
一方が他方の信頼性を確認・検証する処理手順において、第１のクラウドサービスの第１のインスタンスは、第２のクラウドサービスの第２のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第１のチケットを添付して送信する。第２のクラウドサービスの第２のインスタンスは、第１のチケットをチケット確認モジュールにより第２のクラウド連携サーバへ送信して検証を依頼する。第２のクラウド連携サーバは、第１のチケットを、チケット検証モジュールによりリポジトリの情報を参照して検証する。上記検証できた場合は、結果を第２のインスタンスへ送信することにより第２のサービスが第１のサービスの信頼性を確認できる。上記検証できなかった場合は、他のクラウドサービスのクラウド連携サーバへ、チケット検証連携モジュールにより第１のチケットの検証の依頼を送信する。他のクラウドサービスのクラウド連携サーバは、上記第２のクラウド連携サーバと同様に、第１のチケットを、チケット検証モジュールによりリポジトリの情報を参照して検証し、結果を第２のクラウド連携サーバへ送信する。
【発明の効果】
【００１６】
本発明の代表的な形態によれば、ユーザがサービスを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる。
【００１７】
さらに、本発明の処理機能をモジュールとして組み込んだＩａａＳサービスとして提供可能とすることで、例えばアプリケーション事業者が簡単な設定だけで信頼性の高い認証（認証サービス）を利用することができる。
【図面の簡単な説明】
【００１８】
【図１】本発明の一実施の形態の方法及びシステム（クラウドサービス間の信頼関係構築方法及びシステム）の全体の概要構成を示す図である。
【図２】本実施の形態におけるサーバ（ＩａａＳサービス）の構成を示す図である。
【図３】本実施の形態におけるクラウドリポジトリの情報の一例を示す図である。
【図４】本実施の形態におけるキーリポジトリの情報の一例を示す図である。
【図５】本実施の形態におけるチケットリポジトリの情報の一例を示す図である。
【図６】本実施の形態における各リポジトリの情報の関係を示すＥＲ図である。
【図７】本実施の形態におけるチケットの構成を示す図である。
【図８】本実施の形態における各サーバ・モジュール等の関連の動作（処理例）を示す図である。
【図９】本実施の形態でチケット添付モジュールの処理を示すフローチャートである。
【図１０】本実施の形態でチケット確認モジュールの処理を示すフローチャートである。
【図１１】本実施の形態でチケット検証モジュールの処理を示すフローチャートである。
【図１２】本実施の形態でチケット検証連携モジュールの処理を示すフローチャートである。
【図１３】本実施の形態の基本的な構成などを補足するための説明図である。
【発明を実施するための形態】
【００１９】
以下、本発明の実施の形態（クラウドサービス間の信頼関係構築方法及びシステム）を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。
【００２０】
本実施の形態では、概要として、図１，図２，図１３等の構成に基づき、図３〜図７のようなデータ情報を用いて、図８の例に示すように各部（サーバ、モジュール等）間で動作する。図９〜図１２は各部の個別の処理を示す。特徴的な要素として各モジュール（図２、２１，２２，３１，３２等）やチケット（図２、４１）等を有する。複数のクラウドサービス間、例えば図８のＩＳ１，Ｅ１のアプリケーション（８０３）のサービス（Ｓ１）と、ＩＳ２，Ｅ２の認証モジュール（８０８）のサービス（Ｓ２）との間において、各自の信頼性を証明するためのチケット４１（例えばＥ１側の信頼性を証明するためのチケットＴ１（８０５）や、Ｅ２側の信頼性を証明するためのチケットＴ２）を用いて、互いに信頼性の確認・検証を行う仕組みを有する。
【００２１】
［基本］
図１，図２，図１３等に基づき、本実施の形態の方法及びシステムにおける基本的な前提や方式などについて以下である。インターネット上、パートナー契約などによる互いに信頼できるＩａａＳサービス１００間で、それぞれに、一意な識別子、一意な文字列、及び共通の暗号化・復号化の鍵情報を持たせる。次にこれらの情報を管理するサーバ（クラウド連携サーバ３００）をそれぞれのＩａａＳサービス１００環境上に構築する（図１）。これを前提として、ＩａａＳサービス事業者（Ｐ）は、ＩａａＳサービス１００のインスタンス２００（サーバ）を提供し、アプリケーション事業者や認証サービス事業者などのサービス利用者（Ｑ）は、上記インスタンス２００（サーバ）を利用して各自のサービス（アプリケーションや認証サービスなど）をエンドユーザに対し提供する（図１３）。
【００２２】
上記サービスの利用・提供の際は、例えば、サービス利用者（Ｑ）がＩａａＳサービス事業者（Ｐ）に対して利用申請を行い、ＩａａＳサービス事業者（Ｐ）は当該サービス利用者（Ｑ）が十分に信頼できる事業者であるかどうか審査し、審査の結果、信頼できる事業者である場合、当該ＩａａＳサービス１００で持つ一意な文字列や、それを利用するためのモジュール（図２）が組み込まれたサーバ（インスタンス２００）を用意（割り振り、提供）する（図１）。上記サーバ（インスタンス２００）上に、各サービス利用者（Ｑ）は、自身のアプリケーション（サービスＳ１）や認証サービス（サービスＳ２）などを構築して当該サービスをエンドユーザに提供する（図１３）。あるＩａａＳサービス事業者（Ｐ）を利用してアプリケーション（Ｓ１）を提供する事業者（Ｑ１）の場合も、別のＩａａＳサービス事業者（Ｐ２）を利用して認証サービス（Ｓ２）を提供する事業者（Ｑ）の場合も、同様の手順である。
【００２３】
上記サービスの提供・構築の際、当該サーバ（インスタンス２００）には、予め、本発明で特徴的なモジュール（図２）が組み込まれる。エンドユーザから当該サーバ（サービス）へのアクセス（リクエスト、レスポンス等）の際には、当該サーバ（インスタンス２００）に組み込まれているモジュールが自動的に呼び出され特徴的な処理を行うという構成である。
【００２４】
エンドユーザ（対応する端末等）は、ＯｐｅｎＩＤやＳＡＭＬなどの所定のシングルサインオン等の方式に基づき、上記サービスを開始したアプリケーション（Ｓ１）や認証サービス（Ｓ２）を自由に選択して利用する（図１３）。エンドユーザが例えばアプリケーションのサービスＳ１にアクセスした際、当該エンドユーザの認証が済んでいない場合は、当該アプリケーション（Ｓ１）から認証サービス（Ｓ２）に遷移して認証処理を行う。認証が済んでいる場合は、当該アプリケーション（Ｓ１）から、ユーザ情報を利用してエンドユーザにサービス処理が提供される。
【００２５】
上記認証の際、アプリケーション（Ｓ１）側は、当該インスタンス２００（Ｅ１）で持つチケット４１（Ｔ１）を用いて、自身の信頼性を認証サービス（Ｓ２）側に対して証明する（言い換えればＳ２側はＴ１を参照してＳ１側を確認・検証する）。同様に、認証サービス（Ｓ２）側は、当該インスタンス２００（Ｅ１）で持つチケット４１（Ｔ２）を用いて、自身の信頼性をアプリケーション（Ｓ１）側に対して証明する（言い換えればＳ１側はＴ２を参照してＳ２側を確認・検証する）。
【００２６】
例えば、アプリケーション（Ｓ１）側は、エンドユーザに関する認証処理を認証サービス（Ｓ２）へ要求する際、Ｅ１のチケットＴ１を添付して送信し、認証サービス（Ｓ２）側は当該チケットＴ１を用いた確認・検証を行う（図１３のａ１）。例えば、認証サービス（Ｓ２）側は、エンドユーザに関する認証処理の後、認証結果を含む認証情報に、Ｅ２のチケットＴ２を添付して、アプリケーション（Ｓ１）側に送信し、アプリケーション（Ｓ１）側は、当該チケットＴ２を用いた確認・検証を行う（図１３のａ２）。
【００２７】
上記チケット４１を用いた信頼性の確認・検証の際は、ＩａａＳサービス１００上のインスタンス２００のチケット確認モジュール（図２の２１）、同ＩａａＳサービス１００上のクラウド連携サーバ３００上のチケット検証モジュール（図２の３１）及びチケット検証連携モジュール（図２の３２）を用いて行う（詳しくは図８）。依頼元からチケット確認モジュール２１に確認を依頼し、チケット確認モジュール２１からチケット検証モジュール３１に検証を依頼する。
【００２８】
チケット検証モジュール３１は、自ＩａａＳサービス１００内のリポジトリの情報（ＩａａＳサービス情報）を参照して検証を試みる。検証ができた場合は、結果を依頼元などへ送信する。自ＩａａＳサービス１００内のチケット検証モジュール３１で当該チケットの検証ができない場合（該当ＩａａＳサービス情報などが登録されていない場合など）は、チケット検証連携モジュール３２を用いて、信頼できる他（パートナー）のＩａａＳサービス１００上のチケット検証モジュール３１に検証を依頼（問い合わせ）する。同様に複数のＩａａＳサービス１００間で繰り返し検証の連携が可能となっている。
【００２９】
図１３は、説明の補足として、ＩａａＳサービス事業者（Ｐ）、アプリケーション事業者や認証サービス事業者（サービス利用者（Ｑ））、及びエンドユーザ間の関係などを示している。図１３の例では、ＩＳ１を提供するＰ１と、ＩＳ２を提供するＰ２とがパートナー契約しており、Ｐ１（ＩＳ１）は、Ｑ１のサービスＳ１（アプリケーション）のためにインスタンスＥ１を提供しており、Ｐ２（ＩＳ２）は、Ｑ２のサービスＳ２（認証サービス）のためにインスタンスＥ２を提供している。
【００３０】
［システム構成］
図１は、本発明の一実施の形態の方法及びシステム（クラウドサービス間の信頼関係構築方法及びシステム）の全体の概要構成を示している。クラウドコンピューティング環境を含むインターネット上に、複数のＩａａＳサービス１００が存在する。なおＩａａＳサービスを記号ＩＳで表す。図１の例では３つのＩａａＳサービス１００（１０１〜１０３）としてＩＳ１〜ＩＳ３を有する。ＩａａＳサービス１００は、クラウドコンピューティングによるサービスである。各ＩａａＳサービス１００は、対応するＩａａＳサービス事業者（記号Ｐで表す（Ｐ１〜Ｐ３等））や情報処理システム等（サービス処理を実現するハードウェア・ソフトウェア等の技術的な構成、例えばサーバ）が存在する。なおＩａａＳサービス１００等を実現する前提的なサーバ等の詳細については公知技術であるため説明は省略する。
【００３１】
各ＩａａＳサービス１００の事業者（Ｐ）は、それぞれが一意な識別子、一意な文字列、及び当該文字列を暗号化及び復号化するための鍵情報（記号Ｋで表す）を持つ。複数のＩａａＳサービス１００の事業者Ｐは、互いにパートナー契約を結び、これらの情報（識別子、文字列、鍵）を互いに交換している。図１の例では、ＩＳ１（１０１）の事業者Ｐ１とＩＳ２（１０２）の事業者Ｐ２がパートナー契約を結んでおり、ＩＳ２（１０２）の事業者Ｐ２とＩＳ３（１０３）の事業者Ｐ３がパートナー契約を結んでいる。
【００３２】
各ＩａａＳサービス１００上には、ＩａａＳサービス情報を管理するクラウド連携サーバ３００（記号ＣＳで表す）が存在し、上記契約時に交換した情報（識別子、文字列、鍵）（ＩａａＳサービス情報）を管理している。クラウド連携サーバ（ＣＳ）３００は、ＩＳ事業者（Ｐ）が１台ずつ持つ。図１の例では３つのクラウド連携サーバ３００（３０１〜３０３）としてＣＳ１〜ＣＳ３を有する。
【００３３】
上記のような環境（図１）を持つＩａａＳサービス事業者（Ｐ）に対して、アプリケーション事業者などのサービス利用者（記号Ｑで表す）がサービス（記号Ｓで表す）の利用申請を行い、当該サービス（Ｓ）に対応するインスタンス２００が割り振られる。図１の例では、各ＩＳ１００上にインスタンス２００（２０１〜２０３）を有する。
【００３４】
また、上記申請があった際、ＩａａＳサービス事業者（Ｐ）は、申請しているアプリケーション事業者（サービス利用者（Ｑ））が十分に信頼できることを確認（審査などによる）してインスタンス２００を提供する。このインスタンス２００には、ＩａａＳサービス事業者（Ｐ）が持つ一意の文字列とそれを操作するためのモジュールが含まれている。
【００３５】
［ＩａａＳサービス］
図２において、ＩａａＳサービス（ＩＳ）１００の構成、ＩＳ１００上にあるクラウド連携サーバ（ＣＳ）３００とインスタンス(Ｅ）２００の構成について説明する。本発明の構成要素として、２１，２２，４１，４２，３１，３２，５０，５１，５２等がある。インスタンス(Ｅ）２００は、ＩＳ１００上の標準インスタンスを示す。各インスタンス(Ｅ）２００及びＣＳ３００は主にサーバ（ハードウェア及びソフトウェア）により構成され、各モジュールは当該サーバでのソフトウェアプログラム処理などにより構成される。尚これらサーバ（サービス、インスタンス）等の基本的な構成は公知技術（クラウドコンピューティング等）であるため詳細な説明は省略する。
【００３６】
［クラウド連携サーバ］
クラウド連携サーバ（ＣＳ）３００は、チケット検証モジュール３１、チケット検証連携モジュール３２、キーリポジトリ５０、チケットリポジトリ５１、及びクラウドリポジトリ５２、等を有する。
【００３７】
チケット検証モジュール３１は、ＩａａＳサービス１００の持つチケット（記号Ｔで表す）（４１と対応）を確認するためのモジュール（処理部）である。
【００３８】
チケット検証連携モジュール３２は、他のＩａａＳサービス１００にチケット検証を依頼するためのモジュールである。
【００３９】
キーリポジトリ５０は、契約したＩａａＳサービス１００間で交換した鍵情報（Ｋ）を保管するためのリポジトリである。
【００４０】
チケットリポジトリ５１は、契約したＩａａＳサービス１００間で交換したチケット（Ｔ）の情報を保管するためのリポジトリである。
【００４１】
クラウドリポジトリ５２は、契約したＩａａＳサービス１００の識別子などの情報を保管するためのリポジトリである。
【００４２】
［リポジトリ］
図３は、クラウドリポジトリ５２が持つ情報の一例を示す。本テーブル例では、ＩＤ、ＩａａＳ事業者名称、事業者識別子、チケット検証サーバ、等の項目を有するレコードから成る。「ＩａａＳ事業者名称」、「事業者識別子」は、前記Ｐの名称や識別子である。「チケット検証サーバ」は、チケット検証モジュール３１に対応したアドレス（ＵＲＬ）情報である。
【００４３】
図４は、キーリポジトリ５０が持つ情報の一例を示す。本テーブル例では、ＩＤ、ＩａａＳ事業者、キー（鍵）、等の項目を有するレコードから成る。「ＩａａＳ事業者」は、当該鍵（Ｋ）に対応する前記ＰのＩＤである。「キー（鍵）」（Ｋ）は、数値・文字列などである。
【００４４】
図５は、チケットリポジトリ５１が持つ情報の一例を示す。本テーブル例では、ＩＤ、ＩａａＳ事業者、チケット（Ｔ）、等の項目を有するレコードから成る。「ＩａａＳ事業者」は、当該チケット（Ｔ）に対応する前記ＰのＩＤである。チケット（Ｔ）は、数値・文字列などである。
【００４５】
図６は、上記リポジトリ（５０，５１，５２）のそれぞれの情報（６０１〜６０３）の関係を示すＥＲ図である。各テーブルのＩＤは主キーとなる。図３のクラウドリポジトリ５２の情報（６０１）の「ＩａａＳ事業者名称」（ＩａａＳプロバイダ）、及び「事業者識別子」（クラウド識別子）、図４のキーリポジトリ５０の情報（６０２）の「ＩａａＳ事業者」（ＩａａＳプロバイダ）、図５のチケットリポジトリ５１の情報（６０３）の「ＩａａＳ事業者」（ＩａａＳプロバイダ）は、ユニークキーである。
【００４６】
［インスタンス］
前記図２で、一方、アプリケーション事業者（サービス利用者（Ｑ））が利用するインスタンス（Ｅ）２００は、チケット添付モジュール２１、チケット確認モジュール２２、チケット４１、プロパティ４２、等を有する。
【００４７】
チケット添付モジュール２１は、アプリケーションサービス（サービスＳ）にチケット（Ｔ）（４１と対応）を添付するためのモジュールである。
【００４８】
チケット確認モジュール２２は、上記添付されたチケット（Ｔ）を確認するためのモジュールである。
【００４９】
チケット４１は、上記添付するチケット（Ｔ）のデータ情報であり、当該ＩＳのインスタンス（Ｅ）であることを証明する情報である。チケット（Ｔ）や鍵（Ｋ）の情報は、基本的に、各サービスで秘密情報であり、契約サービス間では共通情報となる。
【００５０】
図７は、チケット４１（Ｔ）の構成を示す。チケット４１（Ｔ）は、事業者識別子７０１と、暗号化文字列７０２（一意な文字列を鍵により暗号化した文字列）とを有する。事業者識別子７０１は、ＩＳ事業者（Ｐ）が持つ固有の識別子の文字列である（この識別子はクラウドリポジトリ５２で管理されている）。暗号化文字列７０２の元となる一意な文字列は、チケットリポジトリ５１（図５）の「チケット」文字列を用い、この「チケット」文字列を、自ＩＳの鍵Ｋ（キーリポジトリ５０（図４）の「キー」文字列）で暗号化することにより得られる。
【００５１】
プロパティ２０６は、チケット確認モジュール２２によるチケット検証の依頼先などの情報（ＣＳ３００（またはそのチケット検証モジュール３１）のアドレス情報など）が記載されたプロパティファイル情報である。
【００５２】
インスタンス２００は、上述の状態をテンプレートとして、各アプリケーション事業者（Ｑ）に、コピーにて展開（割り振り、提供）され、それぞれのアプリケーション（サービス）を組み込み利用する。また、インスタンス２００が持つチケット４１（Ｔ）は、図７の通り、事業者識別子７０１と暗号化文字列７０２とを結合した文字列となる。
【００５３】
［動作］
次に、図８を用いて、本実施の形態における各モジュール等の関連の動作（処理例）について説明する。ＯｐｅｎＩＤやＳＡＭＬなどのシングルサインオンあるいはそれに類する方式を適用するものとする。図８では、インターネット上の複数のＩＳ１００（ＩＳ１〜ＩＳ３）の例として、まず、第１のＩＳ事業者Ｐ１による第１のＩａａＳサービス（ＩＳ１）８０１上にある第１のインスタンス８０２（Ｅ１）を利用して、アプリケーション事業者（第１のサービス利用者Ｑ１）が当該アプリケーションのサービスＳ１を提供している。また、第２のＩＳ事業者Ｐ２による第２のＩａａＳサービス（ＩＳ２）８０６上にある第２のインスタンス（Ｅ２）８０７を利用して、認証サービス事業者（第２のサービス利用者Ｑ２）が認証サービス（サービスＳ２）を提供している。他にも、第３のＩＳ事業者Ｐ３による第３のＩａａＳサービス（ＩＳ３）８１９等が存在する。パートナー契約の状態として例えば、Ｐ１−Ｐ２間は無しまたは有り、Ｐ２−Ｐ３間は有り、Ｐ３−Ｐ１間は有り、とする。
【００５４】
第１のインスタンス８０２（Ｅ１）上には、アプリケーション事業者（Ｑ１）が提供するアプリケーションプログラム８０３（サービスＳ１の処理を実現するプログラム、例えばＷｅｂアプリケーションプログラム）がある。第２のインスタンス（Ｅ２）８０７上には、認証サービス事業者（Ｑ２）が提供する認証モジュール８０８（サービスＳ２のプログラム）がある。
【００５５】
適用するシングルサインオン等の方式に応じて、アプリケーションプログラム８０３は、ユーザ（８０３にアクセスし利用するエンドユーザ）が指定した認証サービス（本例ではインスタンス（Ｅ２）８０７上の認証モジュール８０８によるサービスＳ２）に認証処理を依頼（要求）する。そのために、アプリケーションプログラム８０３は、同一インスタンス（Ｅ１）内にあるチケット添付モジュール８０４（図２の２１）を呼び出す。チケット添付モジュール８０４は、チケット８０５（図２の４１）（ＩＳ１のインスタンス（Ｅ１）であることを証明するチケット：Ｔ１とする）を読み込み、当該チケット（Ｔ１）を、認証要求に関するレスポンスヘッダ情報に付加する。
【００５６】
図９に上記チケット添付モジュール８０４の処理の詳細を示す（後述）。
【００５７】
上記チケット添付モジュール８０４の処理（チケット（Ｔ１）添付）の終了後、アプリケーションプログラム８０３は、適用するシングルサインオン等の方式に則り、認証サービス事業者（Ｑ２）が提供する認証モジュール８０８（サービスＳ２）に対して認証処理を依頼（認証要求）する。この認証要求には、上記チケット（Ｔ１）情報が伴う。
【００５８】
第２のＩａａＳサービス（ＩＳ２）８０６上のインスタンス（Ｅ２）８０７上には、認証サービス事業者（Ｑ２）が開発した認証モジュール８０８が動作している。認証モジュール８０８は、認証サービス（第２のサービスＳ２）を提供するモジュール（プログラム）である。アプリケーションプログラム８０３（チケット添付モジュール８０４）から上記認証要求（チケット（Ｔ１）付き）を受けた認証モジュール８０８は、認証結果などを提供する対象となるアプリケーション（８０３）が信頼できるのかを判断するために、同一インスタンス（Ｅ２）内にあるチケット確認モジュール８０９（図２の２２）に、当該チケット（上記認証要求に伴うチケット（Ｔ１））の確認を依頼する。
【００５９】
チケット確認モジュール８０９は、プロパティ８１０（図２の４２）（ＩＳ２のＣＳ２のアドレス情報を含むプロパティファイル情報）を参照し、チケット検証処理を行うチケット検証サーバとなるチケット検証モジュール８１２（図２の３１）のアドレス情報を取得する。そして、チケット確認モジュール８０９は、当該チケット（Ｔ１）情報を、ＩＳ２で稼動するクラウド連携サーバ８１１（ＣＳ２）上にある当該チケット検証モジュール８１２へ送信する。
【００６０】
上記チケット（Ｔ１）情報を受け取ったチケット検証モジュール８１２は、当該チケット（Ｔ１）から、図７（７０１，７０２）に示したような、識別子８１３と暗号化文字列８１４の情報（文字列）を取得する。また、チケット検証モジュール８１２は、同ＣＳ２内のクラウドリポジトリ８１８（図２の５２）とキーリポジトリ８１６（図２の５０）を参照して、当該チケット（Ｔ１）（そのうちの暗号化文字列７０２）の復号化のための鍵（Ｋ）を取得する。
【００６１】
ここで、初回の状況では、ＩＳ１（Ｐ１）とＩＳ２（Ｐ２）との間で、まだパートナー契約が無く、そのため、当該リポジトリに、ＩＳ１に対応する識別子と鍵（Ｋ）等の情報が存在しない（即ち上記Ｔ１に対応する鍵Ｋ１を取得できない）状態とする。そのため、チケット検証モジュール８１２は、チケット検証連携モジュール８１５（図２の３２）に、他のＩＳ１００に対するチケット検証処理を依頼する。
【００６２】
なおＩＳ２（ＣＳ２）のリポジトリに上記ＩＳ１に対応する情報が登録済みの場合は、ＩＳ２にて当該チケット（Ｔ１）の検証処理が行われることになる。
【００６３】
上記依頼を受けたチケット検証連携モジュール８１５は、他のＩＳ１００に対するチケット検証処理依頼のために、同ＣＳ２内のクラウドリポジトリ８１８（図２の５２）を参照し、ＩＳ２と契約しているＩａａＳサービス１００、本例ではＩＳ３（８１９）、の情報を取得する。詳しくは、ＩＳ３上で稼働するＣＳ３（８２１）上のチケット検証サーバ（チケット検証モジュール８２１）のアドレス情報を取得する。そして、チケット検証連携モジュール８１５は、当該取得したＩＳ３（ＣＳ３）のアドレスに対してチケット検証処理依頼を転送（送信）する。この際、検証依頼には、検証対象のチケット（Ｔ１）情報を伴う。
【００６４】
上記検証依頼を受け取ったＩＳ３（８１９）上のＣＳ３（８２０）上にあるチケット検証モジュール８２１は、上記検証対象のチケット（Ｔ１）から取得した識別子８２２（７０１）をもとに、ＣＳ３上のクラウドリポジトリ８２６とキーリポジトリ８２４を参照して、当該チケット（Ｔ１）（その暗号化文字列８２３（７０２））の復号化のための鍵（本例ではＩＳ１のＫ１）を取得する。ここではＰ１−Ｐ３間の契約有りによりＣＳ３内に当該ＩＳ１に関する情報（Ｋ１を含む）が登録済みの状態であるため当該情報を取得できる場合である。
【００６５】
チケット検証モジュール８２１は、取得した鍵（Ｋ１）を用いて当該チケット（Ｔ１）の暗号化文字列８２３（７０２）を復号化した後、クラウドリポジトリ８２６とキーリポジトリ８２５を参照し、当該識別子（８２２）と文字列（上記８２３を復号化した文字列）の組み合わせが正しいかを確認する。即ち当該チケットの有効性・無効性を判断するチケット検証処理を行う。当該組み合わせが正しいという結果（ＯＫ）の場合、当該チケットは有効となり、正しくないという結果（ＮＧ）の場合、無効となる。ＯＫの場合、当該チケット（Ｔ１）がＩＳ１のインスタンス（Ｅ１）であることを証明する情報であることが確認できる。
【００６６】
ＩＳ３のＣＳ３のチケット検証モジュール８２１は、上記確認（チケット検証処理）の結果を、ＩＳ２のＣＳ２のチケット検証連携モジュール８１５へ返す。更に、当該結果は、チケット検証連携モジュール８１５からチケット検証モジュール８１２へ、チケット検証モジュール８１２からＥ２（８０７）のチケット確認モジュール８０９へ、チケット確認モジュール８０９から認証モジュール８０８へと、順に返される（図８に示す流れの逆）。
【００６７】
上記チケット検証処理の結果でＯＫ（Ｔ１有効）の場合、対象アプリケーション（８０３）の信頼性を確認できたことになる。そのため、認証モジュール８０８は、前記依頼されている認証処理（認証サービス（Ｓ２）の処理）を行い、認証結果及びユーザの属性情報を認証情報として、適用するシングルサインオン等の方式に則り、Ｅ１（８０２）上のアプリケーションプログラム８０３へ伝える（送信する）。
【００６８】
また、上記結果でＮＧ（Ｔ１無効）の場合、対象アプリケーション（８０３）の信頼性を確認できなかったため、認証モジュール８０８は、適用するシングルサインオン等の方式に則り、前記依頼されている認証処理ができないことを、Ｅ１のアプリケーションプログラム８０３に伝える。
【００６９】
図１０に、上記チケット確認モジュール８０９の処理の詳細を示す（後述）。
【００７０】
図１１に、上記ＩＳ２上のチケット検証モジュール８１２とＩＳ３上のチケット検証モジュール８２１の処理の詳細を示す（後述）。
【００７１】
図１２に、上記ＩＳ２上のチケット検証連携モジュール８１５の処理の詳細を示す（後述）。
【００７２】
なお、上記（図８）では、ＩＳ１のチケットＴ１を用いてアプリケーション（８０３）側の信頼性を認証モジュール８０８側が確認・検証する流れを説明しているが、ＩＳ２のチケットＴ２を用いて認証モジュール８０８側の信頼性をアプリケーション（８０３）側が確認・検証する場合なども同様となる。即ち例えば、上記（図８）で認証モジュール８０８が認証情報（認証結果とユーザの属性情報）をアプリケーション（８０３）へ返す際に、アプリケーション（８０３）側が当該認証モジュール８０８側の認証情報が信頼できるのかを判断させる（判断できるようにする）ために、当該認証情報に、Ｅ２上にあるチケットＴ２（ＩＳ２のインスタンス（Ｅ２）であることを証明するチケット）の情報を添付する。この際、アプリケーション（８０３）側が当該チケットＴ２を確認・検証する手順については、上記認証モジュール８０８側がチケットＴ１を確認・検証した手順と同様となる。
【００７３】
以上（図８）の流れにより、アプリケーションサービス（Ｓ１）側と認証サービス（Ｓ２）側とで相互に信頼性を確認した通信ができる。
【００７４】
［チケット添付モジュール処理］
図９において、チケット添付モジュール２１（例えば８０４）は、まず、呼び出し元（プログラム（８０３））から処理要求を受け付る（９０１）。即ち、同一インスタンス２００（例えばＥ１）上で動作するプログラム（８０３）から、レスポンス情報を受け取る。次に、同一インスタンス２００（Ｅ１）内にあるチケット情報（４１）を読み込む（９０２）。このチケット（例えばＴ１）は、図７の通り、暗号化文字列７０２は、自ＩＳ（例えばＩＳ１）に対応する一意の文字列（例えばＵＳ１）が、自ＩＳの鍵（例えばＫ１）により暗号化されている。次に、上記読み込んだチケット情報（４１）をＢＡＳＥ６４変換する（９０３）。次に、上記変換したチケット情報（４１）を、レスポンス情報のLocationヘッダのＵＲＬにＵＲＬパラメータとして付加する（９０４）。次に、上記編集したリクエスト情報（チケット付き）を呼び出し元（プログラム（８０３））に戻す（９０５）。
【００７５】
［チケット確認モジュール処理］
図１０において、チケット確認モジュール２２（例えば８０９）は、まず、呼び出し元から処理要求を受け取る（１００１）。即ち、同一インスタンス２００（Ｅ２）上で動作するプログラム（認証モジュール８０８）から、リクエスト情報を受け取る。次に、受け取ったリクエスト情報のヘッダ情報から、リクエストＵＲＬ（ＵＲＬパラメータ）に付加されているチケット情報を取得する（１００２）。次に、プロパティ４２（８１０）の参照から、同一ＩＳ上のクラウド連携サーバ（ＣＳ）３００のアドレス情報を取得する（１００３）。次に、当該アドレスのＣＳ（チケット検証サーバ）へ当該チケット情報をＳＯＡＰで転送（送信）する（１００４）。次に、当該ＣＳ（チケット検証サーバ）から、当該チケットの有効性・無効性の判定結果（チケット検証処理結果）を受け取る（１００５）。次に、上記取得した判定結果を、呼び出し元のプログラム（８０８）に返す（１００６）。
【００７６】
［チケット検証モジュール処理］
図１１において、チケット検証モジュール３１（例えば８１２，８２１）は、まず、インスタンス２００（例えばＥ２）のチケット確認モジュール２２（例えば８０９）から対象のチケット情報（変換状態）を受け取る（１１０１）。次に、受け取ったチケット情報に対してＢＡＳＥ６４デコーディングを行い、チケットデータ（例えばＴ１）を取得する（１１０２）。次に、取得したチケットデータ（Ｔ１）から、事業者識別子（７０１，８１８）（クラウド識別子）を取得し、この識別子を検索キーとしてクラウドリポジトリ５２の参照に基づき対応するＩＳ（例えばＩＳ１）の情報を取得し、取得した情報を用いてキーリポジトリ５０から対象（ＩＳ１）の鍵情報（例えばＫ１）を取得する。
【００７７】
上記対象の鍵（Ｋ１）を取得できた場合（１１０３−Ｙ）、チケットデータ（Ｔ１）から暗号化文字列（７０２，８１４）を取得し（１１０４）、取得した暗号化文字列を上記鍵（Ｋ１）により復号化する（１１０５）。そして、チケットリポジトリ５１を参照し、上記クラウド識別子（事業者識別子）とチケットが合致するデータを取得する（１１０６）。
【００７８】
上記合致するデータがある場合（１１０８−Ｙ）、該当インスタンス２００（例えばＥ２）のチケット確認モジュール２２（８０９）に、当該チケット（Ｔ１）が有効であることを伝え、合致するデータが無い場合（１１０８−Ｎ）、無効であることを伝える。
【００７９】
前記対象の鍵（Ｋ１）を取得できなかった場合（１１０３−Ｎ）、チケット検証モジュール３１は、同ＣＳ３００（例えばＣＳ２）内のチケット検証連携モジュール３２（例えば８１５）に、当該チケットデータ（Ｔ１）を引き渡し、当該チケット（Ｔ１）の確認（検証）処理を依頼する（１１１１）。そして、チケット検証連携モジュール３２から返ってきたチケット確認（検証）結果を、該当インスタンス２００（Ｅ２）のチケット確認モジュール２２（８０９）に伝える。
【００８０】
［チケット検証連携モジュール処理］
図１２において、チケット検証連携モジュール３２（例えば８１５）は、まず、チケット検証モジュール３１（例えば８１２）から事業者識別子（７０１）を含むチケットデータ（前記１１１１の依頼）を受け取る（１２０１）。次に、クラウドリポジトリ５２から、上記事業者識別子（クラウド識別子）を検索キーとして連携可能なクラウド連携サーバ（ＣＳ）３００の情報を取得する（１２０２）。次に、連携可能なＣＳ（例えばＣＳ３（８２０））に、当該チケットデータをＳＯＡＰで送信する。
【００８１】
チケット検証連携モジュール３２は、連携可能なＣＳ（ＣＳ３）のチケット検証モジュール３１（８２１）によるチケット検証結果を待ち受けて取得する（１２０３）。そして、当該検証結果を、依頼元のチケット検証モジュール３１（８１２）に渡す（１２０４）。
【００８２】
［効果等］
以上のように、本実施の形態によれば、クラウドサービス（ＩＳ事業者（Ｐ）から提供されるインスタンス２００によるサービスＳ）間のシングルサインオン等の方式の通信における信頼関係を構築・確保することができ、ユーザがサービスＳを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービス（図１３ではＳ２）の提供・利用が可能となる。さらに、本発明の特徴的な処理機能をモジュール（２１，２２，３１，３２）として組み込んだＩａａＳサービス１００（サーバ）をサービス利用者（Ｑ）に提供することにより、例えばアプリケーション事業者（図１３ではＱ１）が簡単な設定だけで信頼性の高い認証を利用できる。
【００８３】
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。
【産業上の利用可能性】
【００８４】
本発明は、クラウドコンピューティング環境における、ＩａａＳサービス、アプリケーションサービス、認証サービスなどの各種サービスに利用可能である。
【符号の説明】
【００８５】
２１，８０４…チケット添付モジュール、２２，８０９…チケット確認モジュール、３１，８１２，８２１…チケット検証モジュール、３２，８１５…チケット検証連携モジュール、４１，８０５…チケット、４２，８１０…プロパティ、５０，８１６，８２４…キーリポジトリ、５１，８１７，８２５…チケットリポジトリ、５２，８１８，８２６…クラウドリポジトリ、１００（１０１〜１０３），８０１，８０６，８１９…ＩａａＳサービス（ＩＳ）、２００（２０１〜２０３），８０２，８０７…インスタンス（Ｅ）、３００（３０１〜３０３），８１１，８２０…クラウド連携サーバ（ＣＳ）、８０３…アプリケーションプログラム、８０８…認証モジュール。
【特許請求の範囲】
【請求項１】
ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス間の信頼関係を構築及び確保する、クラウドサービス間の信頼関係構築方法であって、
前記クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理手順を含む方法であり、
前記インターネット上に、前記クラウドサービスを実現するサーバのインスタンスと、前記クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられ、
前記インスタンスは、チケット添付モジュールと、チケット確認モジュールとを有し、
前記クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、前記チケットの情報と、前記チケットに関する暗号化・復号化のための鍵の情報と、前記パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有し、
前記チケットは、一意の文字列を前記鍵により暗号化した文字列を含み、
前記一方が他方の信頼性を確認・検証する処理手順において、
第１のクラウドサービスの第１のインスタンスが、第２のクラウドサービスの第２のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第１のチケットを添付して送信する処理手順と、
前記第２のクラウドサービスの第２のインスタンスが、前記第１のチケットを前記チケット確認モジュールにより第２のクラウド連携サーバへ送信して検証を依頼する処理手順と、
前記第２のクラウド連携サーバが、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証する処理手順と、
上記検証できた場合は、結果を前記第２のインスタンスへ送信することにより前記第２のクラウドサービスが前記第１のクラウドサービスの信頼性を確認できる処理手順と、
上記検証できなかった場合は、他の第３のクラウドサービスのクラウド連携サーバへ、前記チケット検証連携モジュールにより前記第１のチケットの検証の依頼を送信する処理手順と、
前記他の第３のクラウドサービスのクラウド連携サーバが、上記第２のクラウド連携サーバと同様に、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証し、結果を前記第２のクラウド連携サーバへ送信する処理手順と、を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
【請求項２】
請求項１記載のクラウドサービス間の信頼関係構築方法において、
前記クラウドサービスは、ＩａａＳサービス事業者によるＩａａＳサービスを利用して実現されるサービス利用者によるサービスであり、
前記ＩａａＳサービス上に、前記サービスを実現するサーバの前記インスタンスと、前記ＩａａＳサービス間でパートナー契約したＩａａＳサービスの情報を互いに交換して管理する前記クラウド連携サーバと、が設けられ、
前記インスタンスの各々は、各自のインスタンスであることを証明するチケットと、対応する前記クラウド連携サーバの情報を含むプロパティファイルと、を保持し、
前記クラウド連携サーバのリポジトリは、前記パートナー契約したＩａａＳサービスの事業者の識別子の情報を含み、
前記チケットは、前記ＩａａＳサービスの事業者の識別子と、前記一意の文字列を前記鍵により暗号化した文字列とを含み、
第１のＩａａＳサービス上に、アプリケーション事業者によるアプリケーションである第１のサービスを実現するサーバの第１のインスタンスと、対応する第１のクラウド連携サーバとを有し、第２のＩａａＳサービス上に、認証サービス事業者による認証サービスである第２のサービスを実現するサーバの第２のインスタンスと、対応する第２のクラウド連携サーバとを有し、他の第３のＩａａＳサービス上に、他の第３の事業者によるサービスを実現するサーバの第３のインスタンスと、対応する第３のクラウド連携サーバとを有し、
エンドユーザが利用する認証サービスを指定できる性質を持つシングルサインオンの方式を適用し、
前記第１のインスタンスの第１のチケットは、第１の文字列を第１の鍵により暗号化した文字列を含み、前記第２のインスタンスの第２のチケットは、第２の文字列を第２の鍵により暗号化した文字列を含み、
前記第１と第２のサービス間で認証情報を通信する際に、前記第１、第２のチケットを用いて互いに信頼性を確認・検証する処理手順を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
【請求項３】
請求項２記載のクラウドサービス間の信頼関係構築方法において、
前記第１と第２のサービス間で認証情報を通信する際の処理手順において、
前記第１のサービスから前記第２のサービスへ認証要求する際、前記第１のチケットを用いて前記第１のチケットの有効性を確認・検証することにより前記第１のサービスの信頼性を確認・検証する処理手順と、
前記第２のサービスから前記第１のサービスへ認証処理結果を応答する際、前記第２のチケットを用いて前記第２のチケットの有効性を確認・検証することにより前記第２のサービスの信頼性を確認・検証する処理手順と、を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
【請求項４】
ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス間の信頼関係を構築及び確保する、クラウドサービス間の信頼関係構築システムであって、
前記クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理を含むシステムであり、
前記インターネット上に、前記クラウドサービスを実現するサーバのインスタンスと、前記クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられ、
前記インスタンスは、チケット添付モジュールと、チケット確認モジュールとを有し、
前記クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、前記チケットの情報と、前記チケットに関する暗号化・復号化のための鍵の情報と、前記パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有し、
前記チケット情報は、一意の文字列を前記鍵により暗号化した文字列を含み、
前記一方が他方の信頼性を確認・検証する処理において、
第１のクラウドサービスの第１のインスタンスは、第２のクラウドサービスの第２のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第１のチケットを添付して送信する処理を行い、
前記第２のクラウドサービスの第２のインスタンスは、前記第１のチケットを前記チケット確認モジュールにより第２のクラウド連携サーバへ送信して検証を依頼する処理を行い、
前記第２のクラウド連携サーバは、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証する処理を行い、
上記検証できた場合は、結果を前記第２のインスタンスへ送信することにより前記第２のクラウドサービスが前記第１のクラウドサービスの信頼性を確認でき、
上記検証できなかった場合は、他の第３のクラウドサービスのクラウド連携サーバへ、前記チケット検証連携モジュールにより前記第１のチケットの検証の依頼を送信する処理を行い、
前記他の第３のクラウドサービスのクラウド連携サーバは、上記第２のクラウド連携サーバと同様に、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証し、結果を前記第２のクラウド連携サーバへ送信する処理を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
【請求項５】
請求項４記載のクラウドサービス間の信頼関係構築システムにおいて、
前記クラウドサービスは、ＩａａＳサービス事業者によるＩａａＳサービスを利用して実現されるサービス利用者によるサービスであり、
前記ＩａａＳサービス上に、前記サービスを実現するサーバの前記インスタンスと、前記ＩａａＳサービス間でパートナー契約したＩａａＳサービスの情報を互いに交換して管理する前記クラウド連携サーバと、が設けられ、
前記インスタンスの各々は、各自のインスタンスであることを証明するチケットと、対応する前記クラウド連携サーバの情報を含むプロパティファイルと、を保持し、
前記クラウド連携サーバのリポジトリは、前記パートナー契約したＩａａＳサービスの事業者の識別子の情報を含み、
前記チケット情報は、前記ＩａａＳサービスの事業者の識別子と、前記一意の文字列を前記鍵により暗号化した文字列とを含み、
第１のＩａａＳサービス上に、アプリケーション事業者によるアプリケーションである第１のサービスを実現するサーバの第１のインスタンスと、対応する第１のクラウド連携サーバとを有し、第２のＩａａＳサービス上に、認証サービス事業者による認証サービスである第２のサービスを実現するサーバの第２のインスタンスと、対応する第２のクラウド連携サーバとを有し、他の第３のＩａａＳサービス上に、他の第３の事業者によるサービスを実現するサーバの第３のインスタンスと、対応する第３のクラウド連携サーバとを有し、
エンドユーザが利用する認証サービスを指定できる性質を持つシングルサインオンの方式を適用し、
前記第１のインスタンスの第１のチケットは、第１の文字列を第１の鍵により暗号化した文字列を含み、前記第２のインスタンスの第２のチケットは、第２の文字列を第２の鍵により暗号化した文字列を含み、
前記第１と第２のサービス間で認証情報を通信する際に、前記第１、第２のチケットを用いて互いに信頼性を確認・検証する処理を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
【請求項６】
請求項５記載のクラウドサービス間の信頼関係構築システムにおいて、
前記第１と第２のサービス間で認証情報を通信する際の処理において、
前記第１のサービスから前記第２のサービスへ認証要求する際、前記第１のチケットを用いて前記第１のチケットの有効性を確認・検証することにより前記第１のサービスの信頼性を確認・検証する処理と、
前記第２のサービスから前記第１のサービスへ認証処理結果を応答する際、前記第２のチケットを用いて前記第２のチケットの有効性を確認・検証することにより前記第２のサービスの信頼性を確認・検証する処理と、を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
【請求項１】
ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス間の信頼関係を構築及び確保する、クラウドサービス間の信頼関係構築方法であって、
前記クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理手順を含む方法であり、
前記インターネット上に、前記クラウドサービスを実現するサーバのインスタンスと、前記クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられ、
前記インスタンスは、チケット添付モジュールと、チケット確認モジュールとを有し、
前記クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、前記チケットの情報と、前記チケットに関する暗号化・復号化のための鍵の情報と、前記パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有し、
前記チケットは、一意の文字列を前記鍵により暗号化した文字列を含み、
前記一方が他方の信頼性を確認・検証する処理手順において、
第１のクラウドサービスの第１のインスタンスが、第２のクラウドサービスの第２のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第１のチケットを添付して送信する処理手順と、
前記第２のクラウドサービスの第２のインスタンスが、前記第１のチケットを前記チケット確認モジュールにより第２のクラウド連携サーバへ送信して検証を依頼する処理手順と、
前記第２のクラウド連携サーバが、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証する処理手順と、
上記検証できた場合は、結果を前記第２のインスタンスへ送信することにより前記第２のクラウドサービスが前記第１のクラウドサービスの信頼性を確認できる処理手順と、
上記検証できなかった場合は、他の第３のクラウドサービスのクラウド連携サーバへ、前記チケット検証連携モジュールにより前記第１のチケットの検証の依頼を送信する処理手順と、
前記他の第３のクラウドサービスのクラウド連携サーバが、上記第２のクラウド連携サーバと同様に、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証し、結果を前記第２のクラウド連携サーバへ送信する処理手順と、を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
【請求項２】
請求項１記載のクラウドサービス間の信頼関係構築方法において、
前記クラウドサービスは、ＩａａＳサービス事業者によるＩａａＳサービスを利用して実現されるサービス利用者によるサービスであり、
前記ＩａａＳサービス上に、前記サービスを実現するサーバの前記インスタンスと、前記ＩａａＳサービス間でパートナー契約したＩａａＳサービスの情報を互いに交換して管理する前記クラウド連携サーバと、が設けられ、
前記インスタンスの各々は、各自のインスタンスであることを証明するチケットと、対応する前記クラウド連携サーバの情報を含むプロパティファイルと、を保持し、
前記クラウド連携サーバのリポジトリは、前記パートナー契約したＩａａＳサービスの事業者の識別子の情報を含み、
前記チケットは、前記ＩａａＳサービスの事業者の識別子と、前記一意の文字列を前記鍵により暗号化した文字列とを含み、
第１のＩａａＳサービス上に、アプリケーション事業者によるアプリケーションである第１のサービスを実現するサーバの第１のインスタンスと、対応する第１のクラウド連携サーバとを有し、第２のＩａａＳサービス上に、認証サービス事業者による認証サービスである第２のサービスを実現するサーバの第２のインスタンスと、対応する第２のクラウド連携サーバとを有し、他の第３のＩａａＳサービス上に、他の第３の事業者によるサービスを実現するサーバの第３のインスタンスと、対応する第３のクラウド連携サーバとを有し、
エンドユーザが利用する認証サービスを指定できる性質を持つシングルサインオンの方式を適用し、
前記第１のインスタンスの第１のチケットは、第１の文字列を第１の鍵により暗号化した文字列を含み、前記第２のインスタンスの第２のチケットは、第２の文字列を第２の鍵により暗号化した文字列を含み、
前記第１と第２のサービス間で認証情報を通信する際に、前記第１、第２のチケットを用いて互いに信頼性を確認・検証する処理手順を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
【請求項３】
請求項２記載のクラウドサービス間の信頼関係構築方法において、
前記第１と第２のサービス間で認証情報を通信する際の処理手順において、
前記第１のサービスから前記第２のサービスへ認証要求する際、前記第１のチケットを用いて前記第１のチケットの有効性を確認・検証することにより前記第１のサービスの信頼性を確認・検証する処理手順と、
前記第２のサービスから前記第１のサービスへ認証処理結果を応答する際、前記第２のチケットを用いて前記第２のチケットの有効性を確認・検証することにより前記第２のサービスの信頼性を確認・検証する処理手順と、を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
【請求項４】
ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス間の信頼関係を構築及び確保する、クラウドサービス間の信頼関係構築システムであって、
前記クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理を含むシステムであり、
前記インターネット上に、前記クラウドサービスを実現するサーバのインスタンスと、前記クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられ、
前記インスタンスは、チケット添付モジュールと、チケット確認モジュールとを有し、
前記クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、前記チケットの情報と、前記チケットに関する暗号化・復号化のための鍵の情報と、前記パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有し、
前記チケット情報は、一意の文字列を前記鍵により暗号化した文字列を含み、
前記一方が他方の信頼性を確認・検証する処理において、
第１のクラウドサービスの第１のインスタンスは、第２のクラウドサービスの第２のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第１のチケットを添付して送信する処理を行い、
前記第２のクラウドサービスの第２のインスタンスは、前記第１のチケットを前記チケット確認モジュールにより第２のクラウド連携サーバへ送信して検証を依頼する処理を行い、
前記第２のクラウド連携サーバは、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証する処理を行い、
上記検証できた場合は、結果を前記第２のインスタンスへ送信することにより前記第２のクラウドサービスが前記第１のクラウドサービスの信頼性を確認でき、
上記検証できなかった場合は、他の第３のクラウドサービスのクラウド連携サーバへ、前記チケット検証連携モジュールにより前記第１のチケットの検証の依頼を送信する処理を行い、
前記他の第３のクラウドサービスのクラウド連携サーバは、上記第２のクラウド連携サーバと同様に、前記第１のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証し、結果を前記第２のクラウド連携サーバへ送信する処理を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
【請求項５】
請求項４記載のクラウドサービス間の信頼関係構築システムにおいて、
前記クラウドサービスは、ＩａａＳサービス事業者によるＩａａＳサービスを利用して実現されるサービス利用者によるサービスであり、
前記ＩａａＳサービス上に、前記サービスを実現するサーバの前記インスタンスと、前記ＩａａＳサービス間でパートナー契約したＩａａＳサービスの情報を互いに交換して管理する前記クラウド連携サーバと、が設けられ、
前記インスタンスの各々は、各自のインスタンスであることを証明するチケットと、対応する前記クラウド連携サーバの情報を含むプロパティファイルと、を保持し、
前記クラウド連携サーバのリポジトリは、前記パートナー契約したＩａａＳサービスの事業者の識別子の情報を含み、
前記チケット情報は、前記ＩａａＳサービスの事業者の識別子と、前記一意の文字列を前記鍵により暗号化した文字列とを含み、
第１のＩａａＳサービス上に、アプリケーション事業者によるアプリケーションである第１のサービスを実現するサーバの第１のインスタンスと、対応する第１のクラウド連携サーバとを有し、第２のＩａａＳサービス上に、認証サービス事業者による認証サービスである第２のサービスを実現するサーバの第２のインスタンスと、対応する第２のクラウド連携サーバとを有し、他の第３のＩａａＳサービス上に、他の第３の事業者によるサービスを実現するサーバの第３のインスタンスと、対応する第３のクラウド連携サーバとを有し、
エンドユーザが利用する認証サービスを指定できる性質を持つシングルサインオンの方式を適用し、
前記第１のインスタンスの第１のチケットは、第１の文字列を第１の鍵により暗号化した文字列を含み、前記第２のインスタンスの第２のチケットは、第２の文字列を第２の鍵により暗号化した文字列を含み、
前記第１と第２のサービス間で認証情報を通信する際に、前記第１、第２のチケットを用いて互いに信頼性を確認・検証する処理を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
【請求項６】
請求項５記載のクラウドサービス間の信頼関係構築システムにおいて、
前記第１と第２のサービス間で認証情報を通信する際の処理において、
前記第１のサービスから前記第２のサービスへ認証要求する際、前記第１のチケットを用いて前記第１のチケットの有効性を確認・検証することにより前記第１のサービスの信頼性を確認・検証する処理と、
前記第２のサービスから前記第１のサービスへ認証処理結果を応答する際、前記第２のチケットを用いて前記第２のチケットの有効性を確認・検証することにより前記第２のサービスの信頼性を確認・検証する処理と、を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２０１２−１０３９３１（Ｐ２０１２−１０３９３１Ａ）
【公開日】平成２４年５月３１日（２０１２．５．３１）
【国際特許分類】
【出願番号】特願２０１０−２５２４４８（Ｐ２０１０−２５２４４８）
【出願日】平成２２年１１月１１日（２０１０．１１．１１）
【出願人】（０００２３３４９１）株式会社日立システムズ (394)
【Ｆターム（参考）】
【公開日】平成２４年５月３１日（２０１２．５．３１）
【国際特許分類】
【出願日】平成２２年１１月１１日（２０１０．１１．１１）
【出願人】（０００２３３４９１）株式会社日立システムズ (394)
【Ｆターム（参考）】
[ Back to top ]