JP2012103931A - Method for establishing trust relationship between cloud services, and system - Google Patents

Method for establishing trust relationship between cloud services, and system Download PDF

Info

Publication number
JP2012103931A
JP2012103931A JP2010252448A JP2010252448A JP2012103931A JP 2012103931 A JP2012103931 A JP 2012103931A JP 2010252448 A JP2010252448 A JP 2010252448A JP 2010252448 A JP2010252448 A JP 2010252448A JP 2012103931 A JP2012103931 A JP 2012103931A
Authority
JP
Japan
Prior art keywords
service
ticket
cloud
information
instance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2010252448A
Other languages
Japanese (ja)
Other versions
JP5613532B2 (en
Inventor
Atsuhiro Watanabe
淳弘 渡邉
Kazuya Kikuchi
一也 菊池
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Systems Ltd
Original Assignee
Hitachi Systems Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Systems Ltd filed Critical Hitachi Systems Ltd
Priority to JP2010252448A priority Critical patent/JP5613532B2/en
Publication of JP2012103931A publication Critical patent/JP2012103931A/en
Application granted granted Critical
Publication of JP5613532B2 publication Critical patent/JP5613532B2/en
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Abstract

PROBLEM TO BE SOLVED: To provide a technique enabling a trust relationship between cloud services to be established, such as enabling a reliable authentication service to be provided while maintaining the characteristics of cloud computing.SOLUTION: The method comprises a procedure by which one of two cloud services (such as S1 and S2) checks and verifies the other by using a ticket (such as T1) for proving an individual reliability. On an IaaS service (IS), an instance (E) of a server implementing a service (such as S1) and a cloud cooperation server (CS) for exchanging information with a service, with which a partnership is formed, and managing it are provided. The instance (E) comprises a ticket attachment module and a ticket checking module. The cloud cooperation server (CS) comprises a ticket verification module, a ticket verification cooperation module, and a repository of each piece of information.

Description

本発明は、インターネット、クラウドコンピューティングなどの技術に関する。特に、クラウドコンピューティングのようにインターネット上にあるアプリケーションなどのクラウドサービス(クラウドクラウドコンピューティングによるサービス)に対し、ユーザが必要なときに必要なものを選択して利用することができる環境・状況において、ユーザが任意にそれを選択できるという特性を残したまま、認証における信頼性を保証するための方法などに関する。   The present invention relates to technologies such as the Internet and cloud computing. Especially in environments and situations where users can select and use necessary services for cloud services such as cloud computing (services using cloud cloud computing) such as applications on the Internet. The present invention relates to a method for assuring reliability in authentication while retaining a characteristic that a user can arbitrarily select it.

また特に、IaaS(Infrastructure as a Service)サービスを利用して実現されるアプリケーションサービス及びその事業者と認証サービス及びその事業者との間で、それぞれの信頼性を保証する方法などに関する。   In particular, the present invention relates to an application service realized by using an IaaS (Infrastructure as a Service) service and a method for guaranteeing the reliability between the service provider and the authentication service and the service provider.

また特に、エンドユーザがシングルサインオン等の方式を適用する環境におけるサービス間の信頼関係を構築する方法などに関する。   In particular, the present invention relates to a method of building a trust relationship between services in an environment where an end user applies a method such as single sign-on.

ユーザがインターネット上にあるアプリケーション(サービス)を任意に選択し利用するクラウドコンピューティング環境では、認証に関して、OpenIDやSAMLなど、一つのIDで複数のサービスが利用できるシングルサインオンの仕組み(ないしその類似の方式)が利用されている。このような認証方式では、アプリケーションがユーザを認証する際、ユーザが指定した認証サービスに処理を委託して、認証結果や認証したユーザの情報を得る。これによりアプリケーションの負荷軽減やユーザの利便性向上が期待できる。   In a cloud computing environment where a user arbitrarily selects and uses an application (service) on the Internet, a single sign-on mechanism (or similar) that allows multiple services to be used with one ID, such as OpenID and SAML, for authentication Method). In such an authentication method, when an application authenticates a user, the processing is entrusted to an authentication service designated by the user, and an authentication result and authenticated user information are obtained. As a result, application load reduction and user convenience can be expected.

しかし、ユーザが自由に認証サービスを指定できるという点から、アプリケーションと認証サービスが互いに信頼できるサービスであるのかを確認する仕組みが必要となる。   However, since the user can freely specify the authentication service, a mechanism for confirming whether the application and the authentication service are reliable services is required.

IaaSサービスとしては、公知のAmazon Elastic Compute Cloud(Amazon EC2)などに代表されるようなサービスがある。   As an IaaS service, there is a service represented by the well-known Amazon Elastic Compute Cloud (Amazon EC2).

シングルサインオンや認証などに関する先行技術例として、特表2005−516533号公報(特許文献1)(「パブリックキー暗号法を用いたインターネット上でのシングルサインオン」)などがある。   As a prior art example related to single sign-on and authentication, there is JP 2005-516533 A (Patent Document 1) (“Single Sign On on the Internet Using Public Key Cryptography”).

特表2005−516533号公報JP 2005-516533 A

前記OpenIDやSAMLなどのクラウドコンピューティングにおける認証方式(シングルサインオンなど)は、インターネット上にあるアプリケーション(サービス)が認証処理を外部委託し負荷の軽減が可能であると共に、一つのIDでユーザが任意に選択した複数のアプリケーションにログインでき、ユーザの利便性が向上するといった特徴を持つ。   Authentication methods (single sign-on, etc.) in cloud computing such as OpenID and SAML allow applications (services) on the Internet to outsource authentication processing and reduce the load. It is possible to log in to a plurality of arbitrarily selected applications, improving the user convenience.

しかし、認証サービスをユーザが自由に指定できることから、認証サービスの信頼性(認証サービスからアプリケーションが取得する認証情報及びユーザ情報がどれほど信頼できるのか等)、あるいは、アプリケーションの信頼性(アプリケーションに対して認証サービスはユーザ情報をどの程度開示できるのか等)、といった課題がある。   However, since the user can freely specify the authentication service, the reliability of the authentication service (how much the authentication information and user information acquired by the application from the authentication service can be trusted) or the reliability of the application (for the application) The authentication service has a problem such as how much user information can be disclosed.

以上を鑑み、本発明の主な目的は、ユーザがサービスを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる技術を提供することである。   In view of the above, the main object of the present invention is to provide a trust relationship between cloud services, such as enabling the provision of a reliable authentication service while retaining the characteristics of cloud computing such that a user can freely select a service. It is to provide technology that can be constructed.

さらに、本発明の処理機能をモジュールとして組み込んだIaaSサービスとして提供可能とすることで、例えばアプリケーション事業者が簡単な設定だけで信頼性の高い認証(認証サービス)を利用することができる技術を提供することである。   Furthermore, by making it possible to provide an IaaS service that incorporates the processing functions of the present invention as a module, for example, a technology is provided that enables an application provider to use highly reliable authentication (authentication service) with simple settings. It is to be.

上記目的を達成するため、本発明の代表的な形態は、ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス(クラウドコンピューティングによるサービス)間の信頼性を構築及び確保する、クラウドサービス間の信頼関係構築方法及びシステムなどであって、以下に示す構成を有することを特徴とする。   In order to achieve the above object, a typical embodiment of the present invention is a reliability between a plurality of cloud services (services by cloud computing) on the Internet including a cloud computing environment in which a user can select a service to be used. A method and system for constructing a trust relationship between cloud services for constructing and securing the network, and having the following configuration.

本方法及びシステムは、クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理手順及び対応する処理部(モジュール等)を含む方法及びシステムであり、インターネット上に、クラウドサービスを実現するサーバのインスタンスと、クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられる。サービスのサーバのインスタンスは、チケット添付モジュールと、チケット確認モジュールと、を有する。クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、チケットの情報と、チケットに関する暗号化・復号化のための鍵の情報と、パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有する。チケット情報は、一意の文字列を鍵により暗号化した文字列を含む。   This method and system uses a ticket including unique information for proving the reliability of each cloud service between the cloud services, and one process confirms and verifies the reliability of the other and the corresponding process. A server and an instance of a server that realizes a cloud service, and a cloud cooperation server that exchanges and manages information on the cloud service between the cloud services. It is done. The service server instance has a ticket attachment module and a ticket confirmation module. The cloud linkage server is a ticket validation module, a ticket validation linkage module, and cloud service information that has been contracted with a partner, as ticket information, key information for encryption / decryption related to the ticket, and a cloud service that has a partner contract. And a repository for managing each piece of information including the identifier information. The ticket information includes a character string obtained by encrypting a unique character string with a key.

一方が他方の信頼性を確認・検証する処理手順において、第1のクラウドサービスの第1のインスタンスは、第2のクラウドサービスの第2のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第1のチケットを添付して送信する。第2のクラウドサービスの第2のインスタンスは、第1のチケットをチケット確認モジュールにより第2のクラウド連携サーバへ送信して検証を依頼する。第2のクラウド連携サーバは、第1のチケットを、チケット検証モジュールによりリポジトリの情報を参照して検証する。上記検証できた場合は、結果を第2のインスタンスへ送信することにより第2のサービスが第1のサービスの信頼性を確認できる。上記検証できなかった場合は、他のクラウドサービスのクラウド連携サーバへ、チケット検証連携モジュールにより第1のチケットの検証の依頼を送信する。他のクラウドサービスのクラウド連携サーバは、上記第2のクラウド連携サーバと同様に、第1のチケットを、チケット検証モジュールによりリポジトリの情報を参照して検証し、結果を第2のクラウド連携サーバへ送信する。   In the processing procedure in which one side checks and verifies the reliability of the other side, when the first instance of the first cloud service proves itself to the second instance of the second cloud service, the ticket attachment module The first ticket is attached and transmitted. The second instance of the second cloud service requests the verification by transmitting the first ticket to the second cloud cooperation server by the ticket confirmation module. The second cloud cooperation server verifies the first ticket with reference to the repository information by the ticket verification module. If the verification is successful, the second service can confirm the reliability of the first service by transmitting the result to the second instance. If the verification fails, the first ticket verification request is transmitted to the cloud cooperation server of another cloud service by the ticket verification cooperation module. Similarly to the second cloud cooperation server, the cloud cooperation server of the other cloud service verifies the first ticket by referring to the repository information by the ticket verification module, and sends the result to the second cloud cooperation server. Send.

本発明の代表的な形態によれば、ユーザがサービスを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービスの提供を可能とする等、クラウドサービス間の信頼関係を構築できる。   According to a typical embodiment of the present invention, a trust relationship between cloud services is established, such as enabling the provision of a reliable authentication service while retaining the characteristics of cloud computing such that a user can freely select a service. it can.

さらに、本発明の処理機能をモジュールとして組み込んだIaaSサービスとして提供可能とすることで、例えばアプリケーション事業者が簡単な設定だけで信頼性の高い認証(認証サービス)を利用することができる。   Furthermore, by making it possible to provide an IaaS service incorporating the processing function of the present invention as a module, for example, application providers can use highly reliable authentication (authentication service) with simple settings.

本発明の一実施の形態の方法及びシステム(クラウドサービス間の信頼関係構築方法及びシステム)の全体の概要構成を示す図である。It is a figure which shows the general | schematic structure of the whole method and system (The trust relationship construction method and system between cloud services) of one Embodiment of this invention. 本実施の形態におけるサーバ(IaaSサービス)の構成を示す図である。It is a figure which shows the structure of the server (IaaS service) in this Embodiment. 本実施の形態におけるクラウドリポジトリの情報の一例を示す図である。It is a figure which shows an example of the information of the cloud repository in this Embodiment. 本実施の形態におけるキーリポジトリの情報の一例を示す図である。It is a figure which shows an example of the information of the key repository in this Embodiment. 本実施の形態におけるチケットリポジトリの情報の一例を示す図である。It is a figure which shows an example of the information of the ticket repository in this Embodiment. 本実施の形態における各リポジトリの情報の関係を示すER図である。It is an ER figure which shows the relationship of the information of each repository in this Embodiment. 本実施の形態におけるチケットの構成を示す図である。It is a figure which shows the structure of the ticket in this Embodiment. 本実施の形態における各サーバ・モジュール等の関連の動作(処理例)を示す図である。It is a figure which shows the related operation | movement (processing example) of each server module in this Embodiment. 本実施の形態でチケット添付モジュールの処理を示すフローチャートである。It is a flowchart which shows the process of a ticket attachment module in this Embodiment. 本実施の形態でチケット確認モジュールの処理を示すフローチャートである。It is a flowchart which shows the process of a ticket confirmation module in this Embodiment. 本実施の形態でチケット検証モジュールの処理を示すフローチャートである。It is a flowchart which shows the process of a ticket verification module in this Embodiment. 本実施の形態でチケット検証連携モジュールの処理を示すフローチャートである。It is a flowchart which shows the process of a ticket verification cooperation module in this Embodiment. 本実施の形態の基本的な構成などを補足するための説明図である。It is explanatory drawing for supplementing the basic composition etc. of this Embodiment.

以下、本発明の実施の形態(クラウドサービス間の信頼関係構築方法及びシステム)を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一符号を付し、その繰り返しの説明は省略する。   Hereinafter, embodiments of the present invention (a method and system for building a trust relationship between cloud services) will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted.

本実施の形態では、概要として、図1,図2,図13等の構成に基づき、図3〜図7のようなデータ情報を用いて、図8の例に示すように各部(サーバ、モジュール等)間で動作する。図9〜図12は各部の個別の処理を示す。特徴的な要素として各モジュール(図2、21,22,31,32等)やチケット(図2、41)等を有する。複数のクラウドサービス間、例えば図8のIS1,E1のアプリケーション(803)のサービス(S1)と、IS2,E2の認証モジュール(808)のサービス(S2)との間において、各自の信頼性を証明するためのチケット41(例えばE1側の信頼性を証明するためのチケットT1(805)や、E2側の信頼性を証明するためのチケットT2)を用いて、互いに信頼性の確認・検証を行う仕組みを有する。   In the present embodiment, as an overview, each unit (server, module, as shown in the example of FIG. 8 using data information as shown in FIGS. 3 to 7 based on the configuration of FIGS. Etc.). 9 to 12 show individual processing of each unit. As characteristic elements, each module (FIGS. 2, 21, 22, 31, 32, etc.), a ticket (FIGS. 2, 41), and the like are included. Prove the reliability of each cloud service, for example, between the service (S1) of the IS1, E1 application (803) in FIG. 8 and the service (S2) of the authentication module (808) of IS2, E2 Are mutually confirmed and verified using a ticket 41 (for example, a ticket T1 (805) for proving reliability on the E1 side or a ticket T2 for proving reliability on the E2 side). Has a mechanism.

[基本]
図1,図2,図13等に基づき、本実施の形態の方法及びシステムにおける基本的な前提や方式などについて以下である。インターネット上、パートナー契約などによる互いに信頼できるIaaSサービス100間で、それぞれに、一意な識別子、一意な文字列、及び共通の暗号化・復号化の鍵情報を持たせる。次にこれらの情報を管理するサーバ(クラウド連携サーバ300)をそれぞれのIaaSサービス100環境上に構築する(図1)。これを前提として、IaaSサービス事業者(P)は、IaaSサービス100のインスタンス200(サーバ)を提供し、アプリケーション事業者や認証サービス事業者などのサービス利用者(Q)は、上記インスタンス200(サーバ)を利用して各自のサービス(アプリケーションや認証サービスなど)をエンドユーザに対し提供する(図13)。
[Basic]
Based on FIG. 1, FIG. 2, FIG. 13, etc., the basic premise and method in the method and system of the present embodiment are as follows. A unique identifier, a unique character string, and common encryption / decryption key information are provided between the IaaS services 100 that can be mutually trusted by the partner contract on the Internet. Next, the server (cloud cooperation server 300) which manages these information is constructed | assembled on each IaaS service 100 environment (FIG. 1). On this assumption, the IaaS service provider (P) provides an instance 200 (server) of the IaaS service 100, and the service user (Q) such as an application provider or an authentication service provider receives the instance 200 (server). ) To provide end users with their own services (applications, authentication services, etc.) (FIG. 13).

上記サービスの利用・提供の際は、例えば、サービス利用者(Q)がIaaSサービス事業者(P)に対して利用申請を行い、IaaSサービス事業者(P)は当該サービス利用者(Q)が十分に信頼できる事業者であるかどうか審査し、審査の結果、信頼できる事業者である場合、当該IaaSサービス100で持つ一意な文字列や、それを利用するためのモジュール(図2)が組み込まれたサーバ(インスタンス200)を用意(割り振り、提供)する(図1)。上記サーバ(インスタンス200)上に、各サービス利用者(Q)は、自身のアプリケーション(サービスS1)や認証サービス(サービスS2)などを構築して当該サービスをエンドユーザに提供する(図13)。あるIaaSサービス事業者(P)を利用してアプリケーション(S1)を提供する事業者(Q1)の場合も、別のIaaSサービス事業者(P2)を利用して認証サービス(S2)を提供する事業者(Q)の場合も、同様の手順である。   When using or providing the above service, for example, a service user (Q) makes an application for use to an IaaS service provider (P), and the IaaS service provider (P) If it is a reliable business operator as a result of the examination, the unique character string possessed by the IaaS service 100 and a module (FIG. 2) for using it are incorporated. The prepared server (instance 200) is prepared (allocated and provided) (FIG. 1). On the server (instance 200), each service user (Q) builds his application (service S1), authentication service (service S2), etc., and provides the service to the end user (FIG. 13). In the case of a provider (Q1) that provides an application (S1) using a certain IaaS service provider (P), a business that provides an authentication service (S2) using another IaaS service provider (P2) The procedure is the same for the person (Q).

上記サービスの提供・構築の際、当該サーバ(インスタンス200)には、予め、本発明で特徴的なモジュール(図2)が組み込まれる。エンドユーザから当該サーバ(サービス)へのアクセス(リクエスト、レスポンス等)の際には、当該サーバ(インスタンス200)に組み込まれているモジュールが自動的に呼び出され特徴的な処理を行うという構成である。   When the service is provided / constructed, a module (FIG. 2) characteristic of the present invention is incorporated in the server (instance 200) in advance. When an end user accesses the server (service) (request, response, etc.), a module built in the server (instance 200) is automatically called to perform characteristic processing. .

エンドユーザ(対応する端末等)は、OpenIDやSAMLなどの所定のシングルサインオン等の方式に基づき、上記サービスを開始したアプリケーション(S1)や認証サービス(S2)を自由に選択して利用する(図13)。エンドユーザが例えばアプリケーションのサービスS1にアクセスした際、当該エンドユーザの認証が済んでいない場合は、当該アプリケーション(S1)から認証サービス(S2)に遷移して認証処理を行う。認証が済んでいる場合は、当該アプリケーション(S1)から、ユーザ情報を利用してエンドユーザにサービス処理が提供される。   The end user (corresponding terminal or the like) freely selects and uses the application (S1) or authentication service (S2) that started the service based on a predetermined single sign-on method such as OpenID or SAML ( FIG. 13). For example, when the end user accesses the application service S1, if the end user has not been authenticated, the application (S1) transitions to the authentication service (S2) to perform authentication processing. If the authentication has been completed, the application (S1) provides service processing to the end user using the user information.

上記認証の際、アプリケーション(S1)側は、当該インスタンス200(E1)で持つチケット41(T1)を用いて、自身の信頼性を認証サービス(S2)側に対して証明する(言い換えればS2側はT1を参照してS1側を確認・検証する)。同様に、認証サービス(S2)側は、当該インスタンス200(E1)で持つチケット41(T2)を用いて、自身の信頼性をアプリケーション(S1)側に対して証明する(言い換えればS1側はT2を参照してS2側を確認・検証する)。   At the time of the authentication, the application (S1) side uses the ticket 41 (T1) possessed by the instance 200 (E1) to prove its reliability to the authentication service (S2) side (in other words, the S2 side) Confirm and verify the S1 side with reference to T1). Similarly, the authentication service (S2) side uses the ticket 41 (T2) possessed by the instance 200 (E1) to prove its reliability to the application (S1) side (in other words, the S1 side is T2 To confirm and verify the S2 side).

例えば、アプリケーション(S1)側は、エンドユーザに関する認証処理を認証サービス(S2)へ要求する際、E1のチケットT1を添付して送信し、認証サービス(S2)側は当該チケットT1を用いた確認・検証を行う(図13のa1)。例えば、認証サービス(S2)側は、エンドユーザに関する認証処理の後、認証結果を含む認証情報に、E2のチケットT2を添付して、アプリケーション(S1)側に送信し、アプリケーション(S1)側は、当該チケットT2を用いた確認・検証を行う(図13のa2)。   For example, the application (S1) side sends an E1 ticket T1 attached to the authentication service (S2) when requesting authentication processing related to the end user, and the authentication service (S2) side confirms using the ticket T1. Verification is performed (a1 in FIG. 13). For example, the authentication service (S2) side attaches the E2 ticket T2 to the authentication information including the authentication result after the end user authentication process, and transmits it to the application (S1) side. The application (S1) side Then, confirmation / verification using the ticket T2 is performed (a2 in FIG. 13).

上記チケット41を用いた信頼性の確認・検証の際は、IaaSサービス100上のインスタンス200のチケット確認モジュール(図2の21)、同IaaSサービス100上のクラウド連携サーバ300上のチケット検証モジュール(図2の31)及びチケット検証連携モジュール(図2の32)を用いて行う(詳しくは図8)。依頼元からチケット確認モジュール21に確認を依頼し、チケット確認モジュール21からチケット検証モジュール31に検証を依頼する。   When the reliability is confirmed and verified using the ticket 41, the ticket confirmation module (21 in FIG. 2) of the instance 200 on the IaaS service 100, and the ticket verification module on the cloud cooperation server 300 on the IaaS service 100 ( This is performed using 31) in FIG. 2 and the ticket verification cooperation module (32 in FIG. 2) (see FIG. 8 for details). The request source requests the ticket confirmation module 21 for confirmation, and the ticket confirmation module 21 requests the ticket verification module 31 for verification.

チケット検証モジュール31は、自IaaSサービス100内のリポジトリの情報(IaaSサービス情報)を参照して検証を試みる。検証ができた場合は、結果を依頼元などへ送信する。自IaaSサービス100内のチケット検証モジュール31で当該チケットの検証ができない場合(該当IaaSサービス情報などが登録されていない場合など)は、チケット検証連携モジュール32を用いて、信頼できる他(パートナー)のIaaSサービス100上のチケット検証モジュール31に検証を依頼(問い合わせ)する。同様に複数のIaaSサービス100間で繰り返し検証の連携が可能となっている。   The ticket verification module 31 attempts verification by referring to the repository information (IaaS service information) in the local IaaS service 100. If verification is successful, send the result to the requester. If the ticket verification module 31 in the local IaaS service 100 cannot verify the ticket (such as when the corresponding IaaS service information is not registered), the ticket verification cooperation module 32 can be used to trust other (partner) Request (inquire) the ticket verification module 31 on the IaaS service 100 for verification. Similarly, verification verification can be repeatedly performed among a plurality of IaaS services 100.

図13は、説明の補足として、IaaSサービス事業者(P)、アプリケーション事業者や認証サービス事業者(サービス利用者(Q))、及びエンドユーザ間の関係などを示している。図13の例では、IS1を提供するP1と、IS2を提供するP2とがパートナー契約しており、P1(IS1)は、Q1のサービスS1(アプリケーション)のためにインスタンスE1を提供しており、P2(IS2)は、Q2のサービスS2(認証サービス)のためにインスタンスE2を提供している。   FIG. 13 shows the relationship between an IaaS service provider (P), an application provider, an authentication service provider (service user (Q)), and end users as supplementary explanations. In the example of FIG. 13, P1 providing IS1 and P2 providing IS2 have a partner contract, and P1 (IS1) provides an instance E1 for the service S1 (application) of Q1. P2 (IS2) provides an instance E2 for the service S2 (authentication service) of Q2.

[システム構成]
図1は、本発明の一実施の形態の方法及びシステム(クラウドサービス間の信頼関係構築方法及びシステム)の全体の概要構成を示している。クラウドコンピューティング環境を含むインターネット上に、複数のIaaSサービス100が存在する。なおIaaSサービスを記号ISで表す。図1の例では3つのIaaSサービス100(101〜103)としてIS1〜IS3を有する。IaaSサービス100は、クラウドコンピューティングによるサービスである。各IaaSサービス100は、対応するIaaSサービス事業者(記号Pで表す(P1〜P3等))や情報処理システム等(サービス処理を実現するハードウェア・ソフトウェア等の技術的な構成、例えばサーバ)が存在する。なおIaaSサービス100等を実現する前提的なサーバ等の詳細については公知技術であるため説明は省略する。
[System configuration]
FIG. 1 shows an overall schematic configuration of a method and system (a trust relationship building method and system between cloud services) according to an embodiment of the present invention. There are a plurality of IaaS services 100 on the Internet including a cloud computing environment. The IaaS service is represented by the symbol IS. In the example of FIG. 1, IS1 to IS3 are provided as three IaaS services 100 (101 to 103). The IaaS service 100 is a service by cloud computing. Each IaaS service 100 includes a corresponding IaaS service provider (represented by the symbol P (P1 to P3, etc.)), an information processing system, etc. (technical configuration such as hardware / software that implements service processing, such as a server). Exists. Note that details of a premise server and the like for realizing the IaaS service 100 and the like are well-known techniques, and thus description thereof is omitted.

各IaaSサービス100の事業者(P)は、それぞれが一意な識別子、一意な文字列、及び当該文字列を暗号化及び復号化するための鍵情報(記号Kで表す)を持つ。複数のIaaSサービス100の事業者Pは、互いにパートナー契約を結び、これらの情報(識別子、文字列、鍵)を互いに交換している。図1の例では、IS1(101)の事業者P1とIS2(102)の事業者P2がパートナー契約を結んでおり、IS2(102)の事業者P2とIS3(103)の事業者P3がパートナー契約を結んでいる。   Each provider (P) of each IaaS service 100 has a unique identifier, a unique character string, and key information (denoted by symbol K) for encrypting and decrypting the character string. The business operators P of the plurality of IaaS services 100 have partner agreements with each other and exchange such information (identifier, character string, key) with each other. In the example of FIG. 1, the provider P1 of IS1 (101) and the provider P2 of IS2 (102) have a partner contract, and the provider P2 of IS2 (102) and the provider P3 of IS3 (103) are partners. I have a contract.

各IaaSサービス100上には、IaaSサービス情報を管理するクラウド連携サーバ300(記号CSで表す)が存在し、上記契約時に交換した情報(識別子、文字列、鍵)(IaaSサービス情報)を管理している。クラウド連携サーバ(CS)300は、IS事業者(P)が1台ずつ持つ。図1の例では3つのクラウド連携サーバ300(301〜303)としてCS1〜CS3を有する。   On each IaaS service 100, there is a cloud cooperation server 300 (denoted by the symbol CS) that manages IaaS service information, and manages the information (identifier, character string, key) (IaaS service information) exchanged at the time of the contract. ing. Each cloud service server (CS) 300 is owned by one IS provider (P). In the example of FIG. 1, the three cloud cooperation servers 300 (301 to 303) include CS1 to CS3.

上記のような環境(図1)を持つIaaSサービス事業者(P)に対して、アプリケーション事業者などのサービス利用者(記号Qで表す)がサービス(記号Sで表す)の利用申請を行い、当該サービス(S)に対応するインスタンス200が割り振られる。図1の例では、各IS100上にインスタンス200(201〜203)を有する。   For the IaaS service provider (P) having the above environment (FIG. 1), a service user (represented by the symbol Q) such as an application provider applies for use of the service (represented by the symbol S), An instance 200 corresponding to the service (S) is allocated. In the example of FIG. 1, there are instances 200 (201 to 203) on each IS 100.

また、上記申請があった際、IaaSサービス事業者(P)は、申請しているアプリケーション事業者(サービス利用者(Q))が十分に信頼できることを確認(審査などによる)してインスタンス200を提供する。このインスタンス200には、IaaSサービス事業者(P)が持つ一意の文字列とそれを操作するためのモジュールが含まれている。   In addition, when the above application is made, the IaaS service provider (P) confirms that the application provider (service user (Q)) that is applying is sufficiently reliable (by examination etc.) and sets the instance 200 provide. This instance 200 includes a unique character string possessed by the IaaS service provider (P) and a module for operating it.

[IaaSサービス]
図2において、IaaSサービス(IS)100の構成、IS100上にあるクラウド連携サーバ(CS)300とインスタンス(E)200の構成について説明する。本発明の構成要素として、21,22,41,42,31,32,50,51,52等がある。インスタンス(E)200は、IS100上の標準インスタンスを示す。各インスタンス(E)200及びCS300は主にサーバ(ハードウェア及びソフトウェア)により構成され、各モジュールは当該サーバでのソフトウェアプログラム処理などにより構成される。尚これらサーバ(サービス、インスタンス)等の基本的な構成は公知技術(クラウドコンピューティング等)であるため詳細な説明は省略する。
[IaaS service]
2, the configuration of the IaaS service (IS) 100 and the configuration of the cloud cooperation server (CS) 300 and the instance (E) 200 on the IS 100 will be described. The constituent elements of the present invention include 21, 22, 41, 42, 31, 32, 50, 51, 52 and the like. An instance (E) 200 indicates a standard instance on the IS 100. Each instance (E) 200 and CS 300 is mainly configured by a server (hardware and software), and each module is configured by software program processing or the like in the server. The basic configuration of these servers (services, instances) and the like is a known technique (cloud computing or the like), and thus detailed description thereof is omitted.

[クラウド連携サーバ]
クラウド連携サーバ(CS)300は、チケット検証モジュール31、チケット検証連携モジュール32、キーリポジトリ50、チケットリポジトリ51、及びクラウドリポジトリ52、等を有する。
[Cloud integration server]
The cloud cooperation server (CS) 300 includes a ticket verification module 31, a ticket verification cooperation module 32, a key repository 50, a ticket repository 51, a cloud repository 52, and the like.

チケット検証モジュール31は、IaaSサービス100の持つチケット(記号Tで表す)(41と対応)を確認するためのモジュール(処理部)である。   The ticket verification module 31 is a module (processing unit) for confirming the ticket (represented by the symbol T) (corresponding to 41) of the IaaS service 100.

チケット検証連携モジュール32は、他のIaaSサービス100にチケット検証を依頼するためのモジュールである。   The ticket verification cooperation module 32 is a module for requesting ticket verification from another IaaS service 100.

キーリポジトリ50は、契約したIaaSサービス100間で交換した鍵情報(K)を保管するためのリポジトリである。   The key repository 50 is a repository for storing key information (K) exchanged between contracted IaaS services 100.

チケットリポジトリ51は、契約したIaaSサービス100間で交換したチケット(T)の情報を保管するためのリポジトリである。   The ticket repository 51 is a repository for storing information on tickets (T) exchanged between contracted IaaS services 100.

クラウドリポジトリ52は、契約したIaaSサービス100の識別子などの情報を保管するためのリポジトリである。   The cloud repository 52 is a repository for storing information such as an identifier of the contracted IaaS service 100.

[リポジトリ]
図3は、クラウドリポジトリ52が持つ情報の一例を示す。本テーブル例では、ID、IaaS事業者名称、事業者識別子、チケット検証サーバ、等の項目を有するレコードから成る。「IaaS事業者名称」、「事業者識別子」は、前記Pの名称や識別子である。「チケット検証サーバ」は、チケット検証モジュール31に対応したアドレス(URL)情報である。
[Repository]
FIG. 3 shows an example of information that the cloud repository 52 has. In this example table, the table includes records having items such as ID, IaaS provider name, provider identifier, and ticket verification server. “IaaS company name” and “company identifier” are the name and identifier of P. The “ticket verification server” is address (URL) information corresponding to the ticket verification module 31.

図4は、キーリポジトリ50が持つ情報の一例を示す。本テーブル例では、ID、IaaS事業者、キー(鍵)、等の項目を有するレコードから成る。「IaaS事業者」は、当該鍵(K)に対応する前記PのIDである。「キー(鍵)」(K)は、数値・文字列などである。   FIG. 4 shows an example of information held by the key repository 50. In this example table, the table includes records having items such as an ID, an IaaS provider, and a key. “IaaS provider” is the ID of the P corresponding to the key (K). The “key” (K) is a numerical value / character string or the like.

図5は、チケットリポジトリ51が持つ情報の一例を示す。本テーブル例では、ID、IaaS事業者、チケット(T)、等の項目を有するレコードから成る。「IaaS事業者」は、当該チケット(T)に対応する前記PのIDである。チケット(T)は、数値・文字列などである。   FIG. 5 shows an example of information that the ticket repository 51 has. In this table example, the table includes records having items such as ID, IaaS provider, and ticket (T). “IaaS provider” is the ID of the P corresponding to the ticket (T). The ticket (T) is a numerical value / character string.

図6は、上記リポジトリ(50,51,52)のそれぞれの情報(601〜603)の関係を示すER図である。各テーブルのIDは主キーとなる。図3のクラウドリポジトリ52の情報(601)の「IaaS事業者名称」(IaaSプロバイダ)、及び「事業者識別子」(クラウド識別子)、図4のキーリポジトリ50の情報(602)の「IaaS事業者」(IaaSプロバイダ)、図5のチケットリポジトリ51の情報(603)の「IaaS事業者」(IaaSプロバイダ)は、ユニークキーである。   FIG. 6 is an ER diagram showing the relationship between the information (601 to 603) of the repository (50, 51, 52). The ID of each table is the primary key. “IaaS provider name” (IaaS provider) and “provider identifier” (cloud identifier) in the information (601) of the cloud repository 52 in FIG. 3, and “IaaS provider” in the information (602) in the key repository 50 in FIG. "(IaaS provider)", "IaaS provider" (IaaS provider) in the information (603) of the ticket repository 51 in FIG. 5 is a unique key.

[インスタンス]
前記図2で、一方、アプリケーション事業者(サービス利用者(Q))が利用するインスタンス(E)200は、チケット添付モジュール21、チケット確認モジュール22、チケット41、プロパティ42、等を有する。
[instance]
On the other hand, in FIG. 2, the instance (E) 200 used by the application provider (service user (Q)) has a ticket attachment module 21, a ticket confirmation module 22, a ticket 41, a property 42, and the like.

チケット添付モジュール21は、アプリケーションサービス(サービスS)にチケット(T)(41と対応)を添付するためのモジュールである。   The ticket attachment module 21 is a module for attaching a ticket (T) (corresponding to 41) to the application service (service S).

チケット確認モジュール22は、上記添付されたチケット(T)を確認するためのモジュールである。   The ticket confirmation module 22 is a module for confirming the attached ticket (T).

チケット41は、上記添付するチケット(T)のデータ情報であり、当該ISのインスタンス(E)であることを証明する情報である。チケット(T)や鍵(K)の情報は、基本的に、各サービスで秘密情報であり、契約サービス間では共通情報となる。   The ticket 41 is data information of the attached ticket (T), and is information that proves that it is an instance (E) of the IS. The information on the ticket (T) and the key (K) is basically secret information for each service, and is common information between contract services.

図7は、チケット41(T)の構成を示す。チケット41(T)は、事業者識別子701と、暗号化文字列702(一意な文字列を鍵により暗号化した文字列)とを有する。事業者識別子701は、IS事業者(P)が持つ固有の識別子の文字列である(この識別子はクラウドリポジトリ52で管理されている)。暗号化文字列702の元となる一意な文字列は、チケットリポジトリ51(図5)の「チケット」文字列を用い、この「チケット」文字列を、自ISの鍵K(キーリポジトリ50(図4)の「キー」文字列)で暗号化することにより得られる。   FIG. 7 shows the configuration of the ticket 41 (T). The ticket 41 (T) has an operator identifier 701 and an encrypted character string 702 (a character string obtained by encrypting a unique character string with a key). The provider identifier 701 is a character string of a unique identifier possessed by the IS provider (P) (this identifier is managed by the cloud repository 52). The unique character string that is the basis of the encrypted character string 702 uses the “ticket” character string of the ticket repository 51 (FIG. 5), and this “ticket” character string is used as the key K (key repository 50 (FIG. It is obtained by encrypting with the “key” character string of 4).

プロパティ206は、チケット確認モジュール22によるチケット検証の依頼先などの情報(CS300(またはそのチケット検証モジュール31)のアドレス情報など)が記載されたプロパティファイル情報である。   The property 206 is property file information in which information such as a ticket verification request destination by the ticket confirmation module 22 (address information of the CS 300 (or the ticket verification module 31), etc.) is described.

インスタンス200は、上述の状態をテンプレートとして、各アプリケーション事業者(Q)に、コピーにて展開(割り振り、提供)され、それぞれのアプリケーション(サービス)を組み込み利用する。また、インスタンス200が持つチケット41(T)は、図7の通り、事業者識別子701と暗号化文字列702とを結合した文字列となる。   The instance 200 is developed (allocated and provided) by copying to each application provider (Q) using the above-described state as a template, and each application (service) is incorporated and used. Also, the ticket 41 (T) possessed by the instance 200 is a character string obtained by combining the business entity identifier 701 and the encrypted character string 702 as shown in FIG.

[動作]
次に、図8を用いて、本実施の形態における各モジュール等の関連の動作(処理例)について説明する。OpenIDやSAMLなどのシングルサインオンあるいはそれに類する方式を適用するものとする。図8では、インターネット上の複数のIS100(IS1〜IS3)の例として、まず、第1のIS事業者P1による第1のIaaSサービス(IS1)801上にある第1のインスタンス802(E1)を利用して、アプリケーション事業者(第1のサービス利用者Q1)が当該アプリケーションのサービスS1を提供している。また、第2のIS事業者P2による第2のIaaSサービス(IS2)806上にある第2のインスタンス(E2)807を利用して、認証サービス事業者(第2のサービス利用者Q2)が認証サービス(サービスS2)を提供している。他にも、第3のIS事業者P3による第3のIaaSサービス(IS3)819等が存在する。パートナー契約の状態として例えば、P1−P2間は無しまたは有り、P2−P3間は有り、P3−P1間は有り、とする。
[Operation]
Next, a related operation (processing example) of each module and the like in the present embodiment will be described with reference to FIG. A single sign-on such as OpenID or SAML or a similar method is applied. In FIG. 8, as an example of a plurality of IS100 (IS1 to IS3) on the Internet, first, a first instance 802 (E1) on a first IaaS service (IS1) 801 by a first IS operator P1 is selected. The application provider (first service user Q1) uses the service S1 of the application. Also, the authentication service provider (second service user Q2) authenticates using the second instance (E2) 807 on the second IaaS service (IS2) 806 by the second IS provider P2. A service (service S2) is provided. In addition, there is a third IaaS service (IS3) 819 by the third IS provider P3. As the partner contract state, for example, it is assumed that there is no or present between P1 and P2, there is between P2 and P3, and there is between P3 and P1.

第1のインスタンス802(E1)上には、アプリケーション事業者(Q1)が提供するアプリケーションプログラム803(サービスS1の処理を実現するプログラム、例えばWebアプリケーションプログラム)がある。第2のインスタンス(E2)807上には、認証サービス事業者(Q2)が提供する認証モジュール808(サービスS2のプログラム)がある。   On the first instance 802 (E1), there is an application program 803 (a program for realizing the processing of the service S1, for example, a Web application program) provided by the application provider (Q1). On the second instance (E2) 807, there is an authentication module 808 (service S2 program) provided by the authentication service provider (Q2).

適用するシングルサインオン等の方式に応じて、アプリケーションプログラム803は、ユーザ(803にアクセスし利用するエンドユーザ)が指定した認証サービス(本例ではインスタンス(E2)807上の認証モジュール808によるサービスS2)に認証処理を依頼(要求)する。そのために、アプリケーションプログラム803は、同一インスタンス(E1)内にあるチケット添付モジュール804(図2の21)を呼び出す。チケット添付モジュール804は、チケット805(図2の41)(IS1のインスタンス(E1)であることを証明するチケット:T1とする)を読み込み、当該チケット(T1)を、認証要求に関するレスポンスヘッダ情報に付加する。   Depending on the applied method such as single sign-on, the application program 803 uses the authentication service (in this example, the authentication module 808 on the instance (E2) 807) service S2 designated by the user (the end user who accesses and uses 803). ) Is requested (requested) for authentication processing. For this purpose, the application program 803 calls the ticket attachment module 804 (21 in FIG. 2) in the same instance (E1). The ticket attachment module 804 reads the ticket 805 (41 in FIG. 2) (the ticket certifying that it is an instance (E1) of IS1: T1), and uses the ticket (T1) as response header information related to the authentication request. Append.

図9に上記チケット添付モジュール804の処理の詳細を示す(後述)。   FIG. 9 shows details of processing of the ticket attachment module 804 (described later).

上記チケット添付モジュール804の処理(チケット(T1)添付)の終了後、アプリケーションプログラム803は、適用するシングルサインオン等の方式に則り、認証サービス事業者(Q2)が提供する認証モジュール808(サービスS2)に対して認証処理を依頼(認証要求)する。この認証要求には、上記チケット(T1)情報が伴う。   After the processing of the ticket attachment module 804 (attachment of the ticket (T1)) is completed, the application program 803 executes the authentication module 808 (service S2) provided by the authentication service provider (Q2) in accordance with the applied single sign-on method or the like. ) Is requested (authentication request). The authentication request is accompanied by the ticket (T1) information.

第2のIaaSサービス(IS2)806上のインスタンス(E2)807上には、認証サービス事業者(Q2)が開発した認証モジュール808が動作している。認証モジュール808は、認証サービス(第2のサービスS2)を提供するモジュール(プログラム)である。アプリケーションプログラム803(チケット添付モジュール804)から上記認証要求(チケット(T1)付き)を受けた認証モジュール808は、認証結果などを提供する対象となるアプリケーション(803)が信頼できるのかを判断するために、同一インスタンス(E2)内にあるチケット確認モジュール809(図2の22)に、当該チケット(上記認証要求に伴うチケット(T1))の確認を依頼する。   An authentication module 808 developed by the authentication service provider (Q2) is operating on the instance (E2) 807 on the second IaaS service (IS2) 806. The authentication module 808 is a module (program) that provides an authentication service (second service S2). Upon receiving the authentication request (with ticket (T1)) from the application program 803 (ticket attachment module 804), the authentication module 808 determines whether or not the application (803) targeted for providing the authentication result can be trusted. The ticket confirmation module 809 (22 in FIG. 2) in the same instance (E2) is requested to confirm the ticket (ticket (T1) accompanying the authentication request).

チケット確認モジュール809は、プロパティ810(図2の42)(IS2のCS2のアドレス情報を含むプロパティファイル情報)を参照し、チケット検証処理を行うチケット検証サーバとなるチケット検証モジュール812(図2の31)のアドレス情報を取得する。そして、チケット確認モジュール809は、当該チケット(T1)情報を、IS2で稼動するクラウド連携サーバ811(CS2)上にある当該チケット検証モジュール812へ送信する。   The ticket confirmation module 809 refers to the property 810 (42 in FIG. 2) (property file information including the address information of CS2 of IS2), and a ticket verification module 812 (31 in FIG. 2) serving as a ticket verification server that performs ticket verification processing. ) Address information. Then, the ticket confirmation module 809 transmits the ticket (T1) information to the ticket verification module 812 on the cloud cooperation server 811 (CS2) operating in IS2.

上記チケット(T1)情報を受け取ったチケット検証モジュール812は、当該チケット(T1)から、図7(701,702)に示したような、識別子813と暗号化文字列814の情報(文字列)を取得する。また、チケット検証モジュール812は、同CS2内のクラウドリポジトリ818(図2の52)とキーリポジトリ816(図2の50)を参照して、当該チケット(T1)(そのうちの暗号化文字列702)の復号化のための鍵(K)を取得する。   Upon receipt of the ticket (T1) information, the ticket verification module 812 receives information (character string) of the identifier 813 and the encrypted character string 814 as shown in FIG. 7 (701, 702) from the ticket (T1). get. Further, the ticket verification module 812 refers to the cloud repository 818 (52 in FIG. 2) and the key repository 816 (50 in FIG. 2) in the CS2, and the ticket (T1) (of which the encrypted character string 702). The key (K) for decryption of is acquired.

ここで、初回の状況では、IS1(P1)とIS2(P2)との間で、まだパートナー契約が無く、そのため、当該リポジトリに、IS1に対応する識別子と鍵(K)等の情報が存在しない(即ち上記T1に対応する鍵K1を取得できない)状態とする。そのため、チケット検証モジュール812は、チケット検証連携モジュール815(図2の32)に、他のIS100に対するチケット検証処理を依頼する。   Here, in the initial situation, there is no partner contract between IS1 (P1) and IS2 (P2), and therefore there is no information such as an identifier and a key (K) corresponding to IS1 in the repository. (In other words, the key K1 corresponding to T1 cannot be acquired). Therefore, the ticket verification module 812 requests the ticket verification cooperation module 815 (32 in FIG. 2) to perform ticket verification processing for another IS100.

なおIS2(CS2)のリポジトリに上記IS1に対応する情報が登録済みの場合は、IS2にて当該チケット(T1)の検証処理が行われることになる。   If the information corresponding to the IS1 is already registered in the repository of IS2 (CS2), the verification process of the ticket (T1) is performed in IS2.

上記依頼を受けたチケット検証連携モジュール815は、他のIS100に対するチケット検証処理依頼のために、同CS2内のクラウドリポジトリ818(図2の52)を参照し、IS2と契約しているIaaSサービス100、本例ではIS3(819)、の情報を取得する。詳しくは、IS3上で稼働するCS3(821)上のチケット検証サーバ(チケット検証モジュール821)のアドレス情報を取得する。そして、チケット検証連携モジュール815は、当該取得したIS3(CS3)のアドレスに対してチケット検証処理依頼を転送(送信)する。この際、検証依頼には、検証対象のチケット(T1)情報を伴う。   Upon receiving the request, the ticket verification cooperation module 815 refers to the cloud repository 818 (52 in FIG. 2) in the CS2 for a ticket verification processing request to another IS100, and the IaaS service 100 that is contracted with the IS2 In this example, information of IS3 (819) is acquired. Specifically, the address information of the ticket verification server (ticket verification module 821) on the CS3 (821) operating on the IS3 is acquired. Then, the ticket verification cooperation module 815 transfers (transmits) the ticket verification processing request to the acquired IS3 (CS3) address. At this time, the verification request is accompanied by ticket (T1) information to be verified.

上記検証依頼を受け取ったIS3(819)上のCS3(820)上にあるチケット検証モジュール821は、上記検証対象のチケット(T1)から取得した識別子822(701)をもとに、CS3上のクラウドリポジトリ826とキーリポジトリ824を参照して、当該チケット(T1)(その暗号化文字列823(702))の復号化のための鍵(本例ではIS1のK1)を取得する。ここではP1−P3間の契約有りによりCS3内に当該IS1に関する情報(K1を含む)が登録済みの状態であるため当該情報を取得できる場合である。   Upon receipt of the verification request, the ticket verification module 821 on the CS3 (820) on the IS3 (819) receives the cloud on the CS3 based on the identifier 822 (701) acquired from the verification target ticket (T1). With reference to the repository 826 and the key repository 824, a key (K1 of IS1 in this example) for decrypting the ticket (T1) (its encrypted character string 823 (702)) is acquired. This is a case where information regarding IS1 (including K1) is already registered in CS3 due to a contract between P1 and P3, and thus the information can be acquired.

チケット検証モジュール821は、取得した鍵(K1)を用いて当該チケット(T1)の暗号化文字列823(702)を復号化した後、クラウドリポジトリ826とキーリポジトリ825を参照し、当該識別子(822)と文字列(上記823を復号化した文字列)の組み合わせが正しいかを確認する。即ち当該チケットの有効性・無効性を判断するチケット検証処理を行う。当該組み合わせが正しいという結果(OK)の場合、当該チケットは有効となり、正しくないという結果(NG)の場合、無効となる。OKの場合、当該チケット(T1)がIS1のインスタンス(E1)であることを証明する情報であることが確認できる。   After decrypting the encrypted character string 823 (702) of the ticket (T1) using the acquired key (K1), the ticket verification module 821 refers to the cloud repository 826 and the key repository 825, and refers to the identifier (822). ) And a character string (character string obtained by decrypting the above 823) is confirmed. That is, a ticket verification process for determining validity / invalidity of the ticket is performed. If the result indicates that the combination is correct (OK), the ticket is valid. If the result is incorrect (NG), the ticket is invalid. In the case of OK, it can be confirmed that the ticket (T1) is information that proves that the instance (E1) of IS1.

IS3のCS3のチケット検証モジュール821は、上記確認(チケット検証処理)の結果を、IS2のCS2のチケット検証連携モジュール815へ返す。更に、当該結果は、チケット検証連携モジュール815からチケット検証モジュール812へ、チケット検証モジュール812からE2(807)のチケット確認モジュール809へ、チケット確認モジュール809から認証モジュール808へと、順に返される(図8に示す流れの逆)。   The IS3 CS3 ticket verification module 821 returns the result of the above confirmation (ticket verification process) to the IS2 CS2 ticket verification cooperation module 815. Further, the result is returned in order from the ticket verification cooperation module 815 to the ticket verification module 812, from the ticket verification module 812 to the ticket verification module 809 of E2 (807), and from the ticket verification module 809 to the authentication module 808 (FIG. The reverse of the flow shown in FIG.

上記チケット検証処理の結果でOK(T1有効)の場合、対象アプリケーション(803)の信頼性を確認できたことになる。そのため、認証モジュール808は、前記依頼されている認証処理(認証サービス(S2)の処理)を行い、認証結果及びユーザの属性情報を認証情報として、適用するシングルサインオン等の方式に則り、E1(802)上のアプリケーションプログラム803へ伝える(送信する)。   If the result of the ticket verification process is OK (T1 valid), the reliability of the target application (803) has been confirmed. Therefore, the authentication module 808 performs the requested authentication processing (processing of the authentication service (S2)), and uses the authentication result and the user attribute information as authentication information in accordance with a method such as single sign-on to be applied. (802) The information is transmitted (transmitted) to the application program 803 above.

また、上記結果でNG(T1無効)の場合、対象アプリケーション(803)の信頼性を確認できなかったため、認証モジュール808は、適用するシングルサインオン等の方式に則り、前記依頼されている認証処理ができないことを、E1のアプリケーションプログラム803に伝える。   In the case of NG (T1 invalid) in the above result, the reliability of the target application (803) could not be confirmed, so that the authentication module 808 follows the requested authentication process in accordance with the applied method such as single sign-on. Is notified to the application program 803 of E1.

図10に、上記チケット確認モジュール809の処理の詳細を示す(後述)。   FIG. 10 shows details of processing of the ticket confirmation module 809 (described later).

図11に、上記IS2上のチケット検証モジュール812とIS3上のチケット検証モジュール821の処理の詳細を示す(後述)。   FIG. 11 shows details of processing of the ticket verification module 812 on IS2 and the ticket verification module 821 on IS3 (described later).

図12に、上記IS2上のチケット検証連携モジュール815の処理の詳細を示す(後述)。   FIG. 12 shows details of processing of the ticket verification cooperation module 815 on the IS2 (described later).

なお、上記(図8)では、IS1のチケットT1を用いてアプリケーション(803)側の信頼性を認証モジュール808側が確認・検証する流れを説明しているが、IS2のチケットT2を用いて認証モジュール808側の信頼性をアプリケーション(803)側が確認・検証する場合なども同様となる。即ち例えば、上記(図8)で認証モジュール808が認証情報(認証結果とユーザの属性情報)をアプリケーション(803)へ返す際に、アプリケーション(803)側が当該認証モジュール808側の認証情報が信頼できるのかを判断させる(判断できるようにする)ために、当該認証情報に、E2上にあるチケットT2(IS2のインスタンス(E2)であることを証明するチケット)の情報を添付する。この際、アプリケーション(803)側が当該チケットT2を確認・検証する手順については、上記認証モジュール808側がチケットT1を確認・検証した手順と同様となる。   In the above (FIG. 8), the flow in which the authentication module 808 confirms and verifies the reliability on the application (803) side using the IS1 ticket T1 is described. However, the authentication module uses the IS2 ticket T2. The same applies when the application (803) side confirms / verifies the reliability on the 808 side. That is, for example, when the authentication module 808 returns authentication information (authentication result and user attribute information) to the application (803) in the above (FIG. 8), the authentication information on the authentication module 808 side can be trusted by the application (803) side. Is attached to the authentication information, the information of the ticket T2 on the E2 (ticket that proves the instance (E2) of IS2) is attached. At this time, the procedure for confirming / verifying the ticket T2 on the application (803) side is the same as the procedure for confirming / verifying the ticket T1 on the authentication module 808 side.

以上(図8)の流れにより、アプリケーションサービス(S1)側と認証サービス(S2)側とで相互に信頼性を確認した通信ができる。   Through the flow of FIG. 8 (FIG. 8), communication can be performed with the application service (S1) side and the authentication service (S2) side confirming the reliability.

[チケット添付モジュール処理]
図9において、チケット添付モジュール21(例えば804)は、まず、呼び出し元(プログラム(803))から処理要求を受け付る(901)。即ち、同一インスタンス200(例えばE1)上で動作するプログラム(803)から、レスポンス情報を受け取る。次に、同一インスタンス200(E1)内にあるチケット情報(41)を読み込む(902)。このチケット(例えばT1)は、図7の通り、暗号化文字列702は、自IS(例えばIS1)に対応する一意の文字列(例えばUS1)が、自ISの鍵(例えばK1)により暗号化されている。次に、上記読み込んだチケット情報(41)をBASE64変換する(903)。次に、上記変換したチケット情報(41)を、レスポンス情報のLocationヘッダのURLにURLパラメータとして付加する(904)。次に、上記編集したリクエスト情報(チケット付き)を呼び出し元(プログラム(803))に戻す(905)。
[Ticket attachment module processing]
In FIG. 9, the ticket attachment module 21 (for example, 804) first receives a processing request from the caller (program (803)) (901). That is, response information is received from a program (803) operating on the same instance 200 (for example, E1). Next, the ticket information (41) in the same instance 200 (E1) is read (902). As shown in FIG. 7, this ticket (for example, T1) is encrypted with a unique character string (for example, US1) corresponding to its own IS (for example, IS1) and encrypted with its own IS key (for example, K1). Has been. Next, the read ticket information (41) is converted to BASE64 (903). Next, the converted ticket information (41) is added as a URL parameter to the URL of the Location header of the response information (904). Next, the edited request information (with ticket) is returned to the caller (program (803)) (905).

[チケット確認モジュール処理]
図10において、チケット確認モジュール22(例えば809)は、まず、呼び出し元から処理要求を受け取る(1001)。即ち、同一インスタンス200(E2)上で動作するプログラム(認証モジュール808)から、リクエスト情報を受け取る。次に、受け取ったリクエスト情報のヘッダ情報から、リクエストURL(URLパラメータ)に付加されているチケット情報を取得する(1002)。次に、プロパティ42(810)の参照から、同一IS上のクラウド連携サーバ(CS)300のアドレス情報を取得する(1003)。次に、当該アドレスのCS(チケット検証サーバ)へ当該チケット情報をSOAPで転送(送信)する(1004)。次に、当該CS(チケット検証サーバ)から、当該チケットの有効性・無効性の判定結果(チケット検証処理結果)を受け取る(1005)。次に、上記取得した判定結果を、呼び出し元のプログラム(808)に返す(1006)。
[Ticket confirmation module processing]
In FIG. 10, the ticket confirmation module 22 (for example, 809) first receives a processing request from the caller (1001). That is, request information is received from a program (authentication module 808) operating on the same instance 200 (E2). Next, ticket information added to the request URL (URL parameter) is acquired from the header information of the received request information (1002). Next, the address information of the cloud cooperation server (CS) 300 on the same IS is acquired from reference to the property 42 (810) (1003). Next, the ticket information is transferred (transmitted) to the CS (ticket verification server) at the address by SOAP (1004). Next, the validity / invalidity determination result (ticket verification processing result) of the ticket is received from the CS (ticket verification server) (1005). Next, the obtained determination result is returned to the calling program (808) (1006).

[チケット検証モジュール処理]
図11において、チケット検証モジュール31(例えば812,821)は、まず、インスタンス200(例えばE2)のチケット確認モジュール22(例えば809)から対象のチケット情報(変換状態)を受け取る(1101)。次に、受け取ったチケット情報に対してBASE64デコーディングを行い、チケットデータ(例えばT1)を取得する(1102)。次に、取得したチケットデータ(T1)から、事業者識別子(701,818)(クラウド識別子)を取得し、この識別子を検索キーとしてクラウドリポジトリ52の参照に基づき対応するIS(例えばIS1)の情報を取得し、取得した情報を用いてキーリポジトリ50から対象(IS1)の鍵情報(例えばK1)を取得する。
[Ticket validation module processing]
In FIG. 11, the ticket verification module 31 (for example, 812 and 821) first receives target ticket information (conversion state) from the ticket confirmation module 22 (for example, 809) of the instance 200 (for example, E2) (1101). Next, BASE64 decoding is performed on the received ticket information to obtain ticket data (for example, T1) (1102). Next, an operator identifier (701, 818) (cloud identifier) is acquired from the acquired ticket data (T1), and information on the corresponding IS (eg, IS1) based on the reference of the cloud repository 52 using this identifier as a search key. And the key information (for example, K1) of the target (IS1) is acquired from the key repository 50 using the acquired information.

上記対象の鍵(K1)を取得できた場合(1103−Y)、チケットデータ(T1)から暗号化文字列(702,814)を取得し(1104)、取得した暗号化文字列を上記鍵(K1)により復号化する(1105)。そして、チケットリポジトリ51を参照し、上記クラウド識別子(事業者識別子)とチケットが合致するデータを取得する(1106)。   If the target key (K1) can be acquired (1103-Y), the encrypted character string (702, 814) is acquired from the ticket data (T1) (1104), and the acquired encrypted character string is stored in the key ( Decryption is performed by K1) (1105). Then, the ticket repository 51 is referred to, and data in which the ticket matches the cloud identifier (operator identifier) is acquired (1106).

上記合致するデータがある場合(1108−Y)、該当インスタンス200(例えばE2)のチケット確認モジュール22(809)に、当該チケット(T1)が有効であることを伝え、合致するデータが無い場合(1108−N)、無効であることを伝える。   When there is matching data (1108-Y), the ticket confirmation module 22 (809) of the corresponding instance 200 (for example, E2) is notified that the ticket (T1) is valid, and there is no matching data ( 1108-N), telling it to be invalid.

前記対象の鍵(K1)を取得できなかった場合(1103−N)、チケット検証モジュール31は、同CS300(例えばCS2)内のチケット検証連携モジュール32(例えば815)に、当該チケットデータ(T1)を引き渡し、当該チケット(T1)の確認(検証)処理を依頼する(1111)。そして、チケット検証連携モジュール32から返ってきたチケット確認(検証)結果を、該当インスタンス200(E2)のチケット確認モジュール22(809)に伝える。   When the target key (K1) cannot be obtained (1103-N), the ticket verification module 31 sends the ticket data (T1) to the ticket verification cooperation module 32 (for example, 815) in the CS 300 (for example, CS2). And confirming (verifying) the ticket (T1) is requested (1111). Then, the ticket confirmation (verification) result returned from the ticket verification cooperation module 32 is transmitted to the ticket confirmation module 22 (809) of the corresponding instance 200 (E2).

[チケット検証連携モジュール処理]
図12において、チケット検証連携モジュール32(例えば815)は、まず、チケット検証モジュール31(例えば812)から事業者識別子(701)を含むチケットデータ(前記1111の依頼)を受け取る(1201)。次に、クラウドリポジトリ52から、上記事業者識別子(クラウド識別子)を検索キーとして連携可能なクラウド連携サーバ(CS)300の情報を取得する(1202)。次に、連携可能なCS(例えばCS3(820))に、当該チケットデータをSOAPで送信する。
[Ticket validation linkage module processing]
In FIG. 12, the ticket verification cooperation module 32 (for example, 815) first receives the ticket data (request of 1111) including the business entity identifier (701) from the ticket verification module 31 (for example, 812) (1201). Next, information of the cloud cooperation server (CS) 300 that can cooperate with the above provider identifier (cloud identifier) as a search key is acquired from the cloud repository 52 (1202). Next, the ticket data is transmitted by SOAP to a collaborative CS (for example, CS3 (820)).

チケット検証連携モジュール32は、連携可能なCS(CS3)のチケット検証モジュール31(821)によるチケット検証結果を待ち受けて取得する(1203)。そして、当該検証結果を、依頼元のチケット検証モジュール31(812)に渡す(1204)。   The ticket verification cooperation module 32 waits for and acquires the ticket verification result by the ticket verification module 31 (821) of the CS (CS3) that can be linked (1203). Then, the verification result is passed to the requesting ticket verification module 31 (812) (1204).

[効果等]
以上のように、本実施の形態によれば、クラウドサービス(IS事業者(P)から提供されるインスタンス200によるサービスS)間のシングルサインオン等の方式の通信における信頼関係を構築・確保することができ、ユーザがサービスSを自由に選択できるといったクラウドコンピューティングの特性を残したまま、信頼できる認証サービス(図13ではS2)の提供・利用が可能となる。さらに、本発明の特徴的な処理機能をモジュール(21,22,31,32)として組み込んだIaaSサービス100(サーバ)をサービス利用者(Q)に提供することにより、例えばアプリケーション事業者(図13ではQ1)が簡単な設定だけで信頼性の高い認証を利用できる。
[Effects]
As described above, according to the present embodiment, a trust relationship is established and secured in a communication such as single sign-on between cloud services (service S by the instance 200 provided by the IS provider (P)). It is possible to provide and use a reliable authentication service (S2 in FIG. 13) while retaining the characteristics of cloud computing such that the user can freely select the service S. Further, by providing the service user (Q) with the IaaS service 100 (server) incorporating the characteristic processing functions of the present invention as modules (21, 22, 31, 32), for example, an application provider (FIG. 13). Then, Q1) can use highly reliable authentication with only simple settings.

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることは言うまでもない。   As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

本発明は、クラウドコンピューティング環境における、IaaSサービス、アプリケーションサービス、認証サービスなどの各種サービスに利用可能である。   The present invention can be used for various services such as an IaaS service, an application service, and an authentication service in a cloud computing environment.

21,804…チケット添付モジュール、22,809…チケット確認モジュール、31,812,821…チケット検証モジュール、32,815…チケット検証連携モジュール、41,805…チケット、42,810…プロパティ、50,816,824…キーリポジトリ、51,817,825…チケットリポジトリ、52,818,826…クラウドリポジトリ、100(101〜103),801,806,819…IaaSサービス(IS)、200(201〜203),802,807…インスタンス(E)、300(301〜303),811,820…クラウド連携サーバ(CS)、803…アプリケーションプログラム、808…認証モジュール。   21, 804... Ticket attachment module, 22, 809... Ticket confirmation module, 31, 812, 821... Ticket validation module, 32, 815... Ticket validation cooperation module, 41, 805 ... Ticket, 42, 810 ... Properties, 50, 816 , 824 ... Key repository, 51, 817, 825 ... Ticket repository, 52, 818, 826 ... Cloud repository, 100 (101 to 103), 801, 806, 819 ... IaaS service (IS), 200 (201 to 203), 802, 807 ... Instance (E), 300 (301-303), 811, 820 ... Cloud cooperation server (CS), 803 ... Application program, 808 ... Authentication module.

Claims (6)

ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス間の信頼関係を構築及び確保する、クラウドサービス間の信頼関係構築方法であって、
前記クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理手順を含む方法であり、
前記インターネット上に、前記クラウドサービスを実現するサーバのインスタンスと、前記クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられ、
前記インスタンスは、チケット添付モジュールと、チケット確認モジュールとを有し、
前記クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、前記チケットの情報と、前記チケットに関する暗号化・復号化のための鍵の情報と、前記パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有し、
前記チケットは、一意の文字列を前記鍵により暗号化した文字列を含み、
前記一方が他方の信頼性を確認・検証する処理手順において、
第1のクラウドサービスの第1のインスタンスが、第2のクラウドサービスの第2のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第1のチケットを添付して送信する処理手順と、
前記第2のクラウドサービスの第2のインスタンスが、前記第1のチケットを前記チケット確認モジュールにより第2のクラウド連携サーバへ送信して検証を依頼する処理手順と、
前記第2のクラウド連携サーバが、前記第1のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証する処理手順と、
上記検証できた場合は、結果を前記第2のインスタンスへ送信することにより前記第2のクラウドサービスが前記第1のクラウドサービスの信頼性を確認できる処理手順と、
上記検証できなかった場合は、他の第3のクラウドサービスのクラウド連携サーバへ、前記チケット検証連携モジュールにより前記第1のチケットの検証の依頼を送信する処理手順と、
前記他の第3のクラウドサービスのクラウド連携サーバが、上記第2のクラウド連携サーバと同様に、前記第1のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証し、結果を前記第2のクラウド連携サーバへ送信する処理手順と、を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
A trust relationship building method between cloud services for building and securing a trust relationship between a plurality of cloud services on the Internet including a cloud computing environment in which a user can select a service to be used.
A method including a processing procedure in which one cloud confirms and verifies the reliability of the other using a ticket including unique information for proving the reliability of each cloud service between the cloud services,
On the Internet, an instance of a server that realizes the cloud service, and a cloud cooperation server that exchanges and manages information on the cloud service between the cloud services are provided,
The instance has a ticket attachment module and a ticket confirmation module;
The cloud cooperation server includes a ticket verification module, a ticket verification cooperation module, and information on a cloud service for which a partner contract has been made, information on the ticket, key information for encryption / decryption related to the ticket, and the partner A repository for managing each information including the identifier information of the contracted cloud service,
The ticket includes a character string obtained by encrypting a unique character string with the key,
In the processing procedure in which the one confirms and verifies the reliability of the other,
A processing procedure in which, when the first instance of the first cloud service proves itself to the second instance of the second cloud service, the first ticket is attached and transmitted by the ticket attachment module;
A processing procedure in which the second instance of the second cloud service transmits the first ticket to the second cloud cooperation server by the ticket confirmation module to request verification;
A processing procedure in which the second cloud cooperation server verifies the first ticket by referring to the repository information by the ticket verification module;
If the verification is successful, the second cloud service can confirm the reliability of the first cloud service by sending a result to the second instance; and
If the verification fails, a processing procedure for transmitting a request for verification of the first ticket by the ticket verification cooperation module to a cloud cooperation server of another third cloud service;
The cloud cooperation server of the other third cloud service verifies the first ticket by referring to the information of the repository by the ticket verification module, similarly to the second cloud cooperation server, and the result And a processing procedure for transmission to the second cloud cooperation server.
請求項1記載のクラウドサービス間の信頼関係構築方法において、
前記クラウドサービスは、IaaSサービス事業者によるIaaSサービスを利用して実現されるサービス利用者によるサービスであり、
前記IaaSサービス上に、前記サービスを実現するサーバの前記インスタンスと、前記IaaSサービス間でパートナー契約したIaaSサービスの情報を互いに交換して管理する前記クラウド連携サーバと、が設けられ、
前記インスタンスの各々は、各自のインスタンスであることを証明するチケットと、対応する前記クラウド連携サーバの情報を含むプロパティファイルと、を保持し、
前記クラウド連携サーバのリポジトリは、前記パートナー契約したIaaSサービスの事業者の識別子の情報を含み、
前記チケットは、前記IaaSサービスの事業者の識別子と、前記一意の文字列を前記鍵により暗号化した文字列とを含み、
第1のIaaSサービス上に、アプリケーション事業者によるアプリケーションである第1のサービスを実現するサーバの第1のインスタンスと、対応する第1のクラウド連携サーバとを有し、第2のIaaSサービス上に、認証サービス事業者による認証サービスである第2のサービスを実現するサーバの第2のインスタンスと、対応する第2のクラウド連携サーバとを有し、他の第3のIaaSサービス上に、他の第3の事業者によるサービスを実現するサーバの第3のインスタンスと、対応する第3のクラウド連携サーバとを有し、
エンドユーザが利用する認証サービスを指定できる性質を持つシングルサインオンの方式を適用し、
前記第1のインスタンスの第1のチケットは、第1の文字列を第1の鍵により暗号化した文字列を含み、前記第2のインスタンスの第2のチケットは、第2の文字列を第2の鍵により暗号化した文字列を含み、
前記第1と第2のサービス間で認証情報を通信する際に、前記第1、第2のチケットを用いて互いに信頼性を確認・検証する処理手順を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
In the trust relationship construction method between the cloud services according to claim 1,
The cloud service is a service by a service user realized by using an IaaS service by an IaaS service provider,
On the IaaS service, the instance of the server that realizes the service, and the cloud cooperation server that manages and exchanges information on the IaaS service that is a partner contract between the IaaS services, are provided.
Each of the instances holds a ticket that proves that it is its own instance, and a property file that includes information of the corresponding cloud cooperation server,
The repository of the cloud cooperation server includes information on the identifier of the provider of the IaaS service with which the partner contract is made,
The ticket includes an identifier of an operator of the IaaS service and a character string obtained by encrypting the unique character string with the key,
The first IaaS service has a first instance of a server that realizes a first service that is an application by an application provider, and a corresponding first cloud cooperation server, and the second IaaS service has The second instance of the server that realizes the second service that is the authentication service by the authentication service provider, and the corresponding second cloud cooperation server, and the other third IaaS service on the other A third instance of a server that implements a service provided by a third operator, and a corresponding third cloud linkage server;
Apply a single sign-on method with the property that the end user can specify the authentication service to be used,
The first ticket of the first instance includes a character string obtained by encrypting a first character string with a first key, and the second ticket of the second instance includes a second character string. Including the character string encrypted with the key of 2,
A cloud service characterized in that, when communicating authentication information between the first and second services, it has a processing procedure for confirming and verifying the reliability of each other using the first and second tickets. Trust relationship building method.
請求項2記載のクラウドサービス間の信頼関係構築方法において、
前記第1と第2のサービス間で認証情報を通信する際の処理手順において、
前記第1のサービスから前記第2のサービスへ認証要求する際、前記第1のチケットを用いて前記第1のチケットの有効性を確認・検証することにより前記第1のサービスの信頼性を確認・検証する処理手順と、
前記第2のサービスから前記第1のサービスへ認証処理結果を応答する際、前記第2のチケットを用いて前記第2のチケットの有効性を確認・検証することにより前記第2のサービスの信頼性を確認・検証する処理手順と、を有すること、を特徴とするクラウドサービス間の信頼関係構築方法。
In the trust relationship construction method between the cloud services according to claim 2,
In the processing procedure when communicating authentication information between the first and second services,
When making an authentication request from the first service to the second service, the reliability of the first service is confirmed by confirming / verifying the validity of the first ticket using the first ticket.・ Processing procedure to verify,
When the authentication processing result is returned from the second service to the first service, the validity of the second ticket is confirmed and verified by using the second ticket, whereby the trust of the second service is confirmed. And a processing procedure for confirming and verifying the authenticity of the cloud service.
ユーザが利用するサービスを選択可能なクラウドコンピューティング環境を含むインターネット上で、複数のクラウドサービス間の信頼関係を構築及び確保する、クラウドサービス間の信頼関係構築システムであって、
前記クラウドサービス間で、各自のクラウドサービスの信頼性を証明するための固有の情報を含むチケットを用いて、一方が他方の信頼性を確認・検証する処理を含むシステムであり、
前記インターネット上に、前記クラウドサービスを実現するサーバのインスタンスと、前記クラウドサービス間で当該クラウドサービスの情報を互いに交換して管理するクラウド連携サーバと、が設けられ、
前記インスタンスは、チケット添付モジュールと、チケット確認モジュールとを有し、
前記クラウド連携サーバは、チケット検証モジュールと、チケット検証連携モジュールと、パートナー契約したクラウドサービスの情報として、前記チケットの情報と、前記チケットに関する暗号化・復号化のための鍵の情報と、前記パートナー契約したクラウドサービスの識別子の情報とを含む各情報を管理するリポジトリと、を有し、
前記チケット情報は、一意の文字列を前記鍵により暗号化した文字列を含み、
前記一方が他方の信頼性を確認・検証する処理において、
第1のクラウドサービスの第1のインスタンスは、第2のクラウドサービスの第2のインスタンスへ、自身を証明する場合、前記チケット添付モジュールにより第1のチケットを添付して送信する処理を行い、
前記第2のクラウドサービスの第2のインスタンスは、前記第1のチケットを前記チケット確認モジュールにより第2のクラウド連携サーバへ送信して検証を依頼する処理を行い、
前記第2のクラウド連携サーバは、前記第1のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証する処理を行い、
上記検証できた場合は、結果を前記第2のインスタンスへ送信することにより前記第2のクラウドサービスが前記第1のクラウドサービスの信頼性を確認でき、
上記検証できなかった場合は、他の第3のクラウドサービスのクラウド連携サーバへ、前記チケット検証連携モジュールにより前記第1のチケットの検証の依頼を送信する処理を行い、
前記他の第3のクラウドサービスのクラウド連携サーバは、上記第2のクラウド連携サーバと同様に、前記第1のチケットを、前記チケット検証モジュールにより前記リポジトリの情報を参照して検証し、結果を前記第2のクラウド連携サーバへ送信する処理を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
A trust relationship building system between cloud services that builds and secures a trust relationship between a plurality of cloud services on the Internet including a cloud computing environment in which a user can select a service to be used.
A system including a process of checking and verifying the reliability of the other using a ticket including unique information for proving the reliability of each cloud service between the cloud services;
On the Internet, an instance of a server that realizes the cloud service, and a cloud cooperation server that exchanges and manages information on the cloud service between the cloud services are provided,
The instance has a ticket attachment module and a ticket confirmation module;
The cloud cooperation server includes a ticket verification module, a ticket verification cooperation module, and information on a cloud service for which a partner contract has been made, information on the ticket, key information for encryption / decryption related to the ticket, and the partner A repository for managing each information including the identifier information of the contracted cloud service,
The ticket information includes a character string obtained by encrypting a unique character string with the key,
In the process in which the one confirms and verifies the reliability of the other,
When the first instance of the first cloud service proves itself to the second instance of the second cloud service, the first attachment of the ticket is attached and transmitted by the ticket attachment module,
The second instance of the second cloud service performs processing to send the first ticket to the second cloud cooperation server by the ticket confirmation module and request verification.
The second cloud cooperation server performs processing for verifying the first ticket by referring to the repository information by the ticket verification module,
If the verification is successful, the second cloud service can confirm the reliability of the first cloud service by sending the result to the second instance,
If the verification cannot be performed, a process of transmitting a request for verifying the first ticket by the ticket verification cooperation module to a cloud cooperation server of another third cloud service is performed,
Similarly to the second cloud collaboration server, the cloud collaboration server of the other third cloud service verifies the first ticket by referring to the information in the repository by the ticket verification module. A system for building a trust relationship between cloud services, characterized by performing a process of transmitting to the second cloud cooperation server.
請求項4記載のクラウドサービス間の信頼関係構築システムにおいて、
前記クラウドサービスは、IaaSサービス事業者によるIaaSサービスを利用して実現されるサービス利用者によるサービスであり、
前記IaaSサービス上に、前記サービスを実現するサーバの前記インスタンスと、前記IaaSサービス間でパートナー契約したIaaSサービスの情報を互いに交換して管理する前記クラウド連携サーバと、が設けられ、
前記インスタンスの各々は、各自のインスタンスであることを証明するチケットと、対応する前記クラウド連携サーバの情報を含むプロパティファイルと、を保持し、
前記クラウド連携サーバのリポジトリは、前記パートナー契約したIaaSサービスの事業者の識別子の情報を含み、
前記チケット情報は、前記IaaSサービスの事業者の識別子と、前記一意の文字列を前記鍵により暗号化した文字列とを含み、
第1のIaaSサービス上に、アプリケーション事業者によるアプリケーションである第1のサービスを実現するサーバの第1のインスタンスと、対応する第1のクラウド連携サーバとを有し、第2のIaaSサービス上に、認証サービス事業者による認証サービスである第2のサービスを実現するサーバの第2のインスタンスと、対応する第2のクラウド連携サーバとを有し、他の第3のIaaSサービス上に、他の第3の事業者によるサービスを実現するサーバの第3のインスタンスと、対応する第3のクラウド連携サーバとを有し、
エンドユーザが利用する認証サービスを指定できる性質を持つシングルサインオンの方式を適用し、
前記第1のインスタンスの第1のチケットは、第1の文字列を第1の鍵により暗号化した文字列を含み、前記第2のインスタンスの第2のチケットは、第2の文字列を第2の鍵により暗号化した文字列を含み、
前記第1と第2のサービス間で認証情報を通信する際に、前記第1、第2のチケットを用いて互いに信頼性を確認・検証する処理を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
In the trust relationship building system between cloud services according to claim 4,
The cloud service is a service by a service user realized by using an IaaS service by an IaaS service provider,
On the IaaS service, the instance of the server that realizes the service, and the cloud cooperation server that manages and exchanges information on the IaaS service that is a partner contract between the IaaS services, are provided.
Each of the instances holds a ticket that proves that it is its own instance, and a property file that includes information of the corresponding cloud cooperation server,
The repository of the cloud cooperation server includes information on the identifier of the provider of the IaaS service with which the partner contract is made,
The ticket information includes an identifier of a provider of the IaaS service and a character string obtained by encrypting the unique character string with the key,
The first IaaS service has a first instance of a server that realizes a first service that is an application by an application provider, and a corresponding first cloud cooperation server, and the second IaaS service has The second instance of the server that realizes the second service that is the authentication service by the authentication service provider, and the corresponding second cloud cooperation server, and the other third IaaS service on the other A third instance of a server that implements a service provided by a third operator, and a corresponding third cloud linkage server;
Apply a single sign-on method with the property that the end user can specify the authentication service to be used,
The first ticket of the first instance includes a character string obtained by encrypting a first character string with a first key, and the second ticket of the second instance includes a second character string. Including the character string encrypted with the key of 2,
When authentication information is communicated between the first and second services, a process for confirming and verifying the reliability of each other using the first and second tickets is performed. Trust relationship building system.
請求項5記載のクラウドサービス間の信頼関係構築システムにおいて、
前記第1と第2のサービス間で認証情報を通信する際の処理において、
前記第1のサービスから前記第2のサービスへ認証要求する際、前記第1のチケットを用いて前記第1のチケットの有効性を確認・検証することにより前記第1のサービスの信頼性を確認・検証する処理と、
前記第2のサービスから前記第1のサービスへ認証処理結果を応答する際、前記第2のチケットを用いて前記第2のチケットの有効性を確認・検証することにより前記第2のサービスの信頼性を確認・検証する処理と、を行うこと、を特徴とするクラウドサービス間の信頼関係構築システム。
In the trust relationship building system between cloud services according to claim 5,
In processing when communicating authentication information between the first and second services,
When making an authentication request from the first service to the second service, the reliability of the first service is confirmed by confirming / verifying the validity of the first ticket using the first ticket.・ Process to verify,
When the authentication processing result is returned from the second service to the first service, the validity of the second ticket is confirmed and verified by using the second ticket, whereby the trust of the second service is confirmed. A system for building a trust relationship between cloud services, characterized by performing processing for confirming and verifying performance.
JP2010252448A 2010-11-11 2010-11-11 Method and system for building trust relationship between cloud services Expired - Fee Related JP5613532B2 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010252448A JP5613532B2 (en) 2010-11-11 2010-11-11 Method and system for building trust relationship between cloud services

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010252448A JP5613532B2 (en) 2010-11-11 2010-11-11 Method and system for building trust relationship between cloud services

Publications (2)

Publication Number Publication Date
JP2012103931A true JP2012103931A (en) 2012-05-31
JP5613532B2 JP5613532B2 (en) 2014-10-22

Family

ID=46394241

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010252448A Expired - Fee Related JP5613532B2 (en) 2010-11-11 2010-11-11 Method and system for building trust relationship between cloud services

Country Status (1)

Country Link
JP (1) JP5613532B2 (en)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014157480A (en) * 2013-02-15 2014-08-28 Canon Inc Information processor, program, and control method
US9160715B2 (en) 2013-03-28 2015-10-13 Fujitsu Limited System and method for controlling access to a device allocated to a logical information processing device
CN107018132A (en) * 2017-03-29 2017-08-04 宁夏煜隆科技有限公司 Cloud platform encrypting and decrypting method and system based on open network environment
CN109002965A (en) * 2018-06-22 2018-12-14 南京邮电大学 A kind of cloud manufacturing service cooperative level assessment system and application method

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06290152A (en) * 1993-03-31 1994-10-18 Toshiba Corp User authentication device
JP2001069138A (en) * 1999-08-27 2001-03-16 Inst Of Systems Information Technologies Kyushu User verifying system on internet for shared key enciphered ic card
JP2005327189A (en) * 2004-05-17 2005-11-24 Nec Soft Ltd Server, authentication exchange system, request relaying method
JP2007026294A (en) * 2005-07-20 2007-02-01 Ntt Resonant Inc Authentication method and authentication system
US20100070760A1 (en) * 2008-09-12 2010-03-18 Qualcomm Incorporated Ticket-based spectrum authorization and access control
JP2010205239A (en) * 2009-03-02 2010-09-16 Toyo Networks & System Integration Co Ltd Agent device and agent system using the same

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06290152A (en) * 1993-03-31 1994-10-18 Toshiba Corp User authentication device
JP2001069138A (en) * 1999-08-27 2001-03-16 Inst Of Systems Information Technologies Kyushu User verifying system on internet for shared key enciphered ic card
JP2005327189A (en) * 2004-05-17 2005-11-24 Nec Soft Ltd Server, authentication exchange system, request relaying method
JP2007026294A (en) * 2005-07-20 2007-02-01 Ntt Resonant Inc Authentication method and authentication system
US20100070760A1 (en) * 2008-09-12 2010-03-18 Qualcomm Incorporated Ticket-based spectrum authorization and access control
JP2010205239A (en) * 2009-03-02 2010-09-16 Toyo Networks & System Integration Co Ltd Agent device and agent system using the same

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014157480A (en) * 2013-02-15 2014-08-28 Canon Inc Information processor, program, and control method
US9160715B2 (en) 2013-03-28 2015-10-13 Fujitsu Limited System and method for controlling access to a device allocated to a logical information processing device
CN107018132A (en) * 2017-03-29 2017-08-04 宁夏煜隆科技有限公司 Cloud platform encrypting and decrypting method and system based on open network environment
CN109002965A (en) * 2018-06-22 2018-12-14 南京邮电大学 A kind of cloud manufacturing service cooperative level assessment system and application method

Also Published As

Publication number Publication date
JP5613532B2 (en) 2014-10-22

Similar Documents

Publication Publication Date Title
US10810515B2 (en) Digital rights management (DRM)-enabled policy management for an identity provider in a federated environment
US10027670B2 (en) Distributed authentication
Hughes et al. Security assertion markup language (saml) v2. 0 technical overview
EP2688265B1 (en) A method and apparatus for private token communication services
US8108920B2 (en) Passive client single sign-on for web applications
US7860883B2 (en) Method and system for distributed retrieval of data objects within multi-protocol profiles in federated environments
US7299493B1 (en) Techniques for dynamically establishing and managing authentication and trust relationships
US7346923B2 (en) Federated identity management within a distributed portal server
US7860882B2 (en) Method and system for distributed retrieval of data objects using tagged artifacts within federated protocol operations
US8386776B2 (en) Certificate generating/distributing system, certificate generating/distributing method and certificate generating/distributing program
US9225525B2 (en) Identity management certificate operations
JP5790653B2 (en) Service provision system
US20100100924A1 (en) Digital Rights Management (DRM)-Enabled Policy Management For A Service Provider In A Federated Environment
US8806195B2 (en) User interface generation in view of constraints of a certificate profile
JPH1125048A (en) Method for managing security of network system
CA2489127C (en) Techniques for dynamically establishing and managing authentication and trust relationships
JP5613532B2 (en) Method and system for building trust relationship between cloud services
Koshutanski et al. Distributed identity management model for digital ecosystems
Lockhart et al. Security assertion markup language (saml) v2. 0 technical overview
JP4932154B2 (en) Method and system for providing user authentication to a member site in an identity management network, method for authenticating a user at a home site belonging to the identity management network, computer readable medium, and system for hierarchical distributed identity management
Tehrani et al. The missing piece: On namespace management in NDN and how DNSSEC might help
JP2012181662A (en) Account information cooperation system
Pfitzmann et al. BBAE–a general protocol for browser-based attribute exchange
More et al. Offline-verifiable Data from Distributed Ledger-based Registries
Sharif et al. Cross-Domain Sharing of User Claims: A Design Proposal for OpenID Connect Attribute Authorities

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20130828

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20140515

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20140527

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20140725

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20140812

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20140908

R150 Certificate of patent or registration of utility model

Ref document number: 5613532

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees