JP2020119147A

JP2020119147A - システム、テナントの移動方法、情報処理装置およびその制御方法、認可サーバーおよびその制御方法、並びにプログラム

Info

Publication number: JP2020119147A
Application number: JP2019008600A
Authority: JP
Inventors: 康矢岡部; Koya Okabe
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-01-22
Filing date: 2019-01-22
Publication date: 2020-08-06
Anticipated expiration: 2039-01-22
Also published as: JP7208807B2

Abstract

【課題】クラウドにおいて、特定のテナントにクライアントとして登録されたデバイスが、別のテナントへ移動する場合に、登録中のテナントの権限で別のテナントへ移動することができない。新規にテナント登録し直す必要があるが、手動で行うと手間となる。【解決手段】認可サーバーは、テナントに対応づけて登録されている情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持し、情報処理装置は、認可サーバーから発行された認証情報を用いて、認可サーバーに対して認可情報を要求し、前記要求の応答として情報処理装置の移動先のテナントの情報が返された場合、認可サーバーに対して、情報処理装置を前記移動先のテナントへ登録するための登録キーの発行を要求し、当該登録キーを取得し、前記登録キーを用いて、認可サーバーに対して、情報処理装置の前記移動先のテナントへの登録要求を行う。【選択図】図４

Description

本発明は、システム、テナントの移動方法、情報処理装置およびその制御方法、認可サーバーおよびその制御方法、並びにプログラムに関する。

所謂クラウドと呼ばれる、インターネット上における様々なＩＴリソースをオンデマンドで提供するサービスがある。クラウドは一般的にＷｅｂサービスのＡＰＩ（ＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅ）を公開しており、複写機等のネットワークデバイス（以後、デバイス）はＡＰＩを介してクラウドが提供する機能を利用することができる。このＡＰＩ利用における認証、認可のプロトコルとして、ＯＡｕｔｈ２．０と呼ばれる標準プロトコルが策定されている。ＯＡｕｔｈ２．０において、認証、認可を受ける側であるデバイスはクライアントと呼ばれる。デバイスがＡＰＩを利用するためには、事前に認可サーバーに対して当該デバイスをクライアントとして登録する。そして、認可サーバーが発行したクライアントを識別するためのクライアントＩＤと認証するためのシークレット（認証情報）を、クライアントであるデバイスが保持しておく必要がある。

一方、クラウドでは、同じシステムやサービスを複数の組織（例えば、企業等）が共有して使用することが一般的であり、各組織は、各テナントに論理的に分離され、セキュリティや秘匿性が担保される（マルチテナント方式）。組織に設置されたデバイスもまた、クラウドとやり取りするデータに機密情報等が含まれる場合に、その組織に対応するテナントに所属する形で認可サーバーに登録される必要がある。これにより、デバイスはデータを所属するテナント外に情報漏えいすることなく、クラウドが提供する各種機能を利用できる。

デバイスが特定のテナントに属する形で認可サーバーに登録される権限委譲システムとして、例えば、特許文献１が挙げられる。特許文献１の技術では、デバイスのシリアルＩＤとテナントＩＤを紐づけて管理し、クラウドにおけるユーザーの権限をテナント専用のクライアント作成として委譲することで、デバイスのテナント登録を実現している。その実現方法の一つとして、特定のテナントにデバイスを登録するためのキー（以後、デバイス登録キー）を使用している。ユーザーは、対象テナントからデバイス登録キーを入手し、それをデバイスに入力することで、デバイスを対象テナントへ登録することができる。

特開２０１７−１０７３９６号公報

マルチテナント方式において、テナントにはいくつか種類が存在する。例えば、クラウドを利用する企業のテナント（以下、顧客テナント）のほかに、クラウドを提供する提供者側のテナント（以下、販売テナント）が存在する。利用者（顧客）が提供者と契約を交わし、提供者が顧客テナントを作成する。販売テナントは顧客テナントの管理などを行うために利用される。デバイスは顧客テナントに登録されるべきであるが、次のような理由で販売テナントに一時的に登録する場合がある。例えば、デバイスを企業に物理的に設置する設置者が、設置作業の一環としてデバイスを顧客テナントに登録したいが、その段階ではまだ顧客テナントが存在しない場合が考えられる。また、設置者が顧客テナントのユーザーでない場合は、顧客テナントへデバイスを登録するためのキーを入手していない場合も考えられる。一方で、販売テナントに登録されているデバイスを顧客が使用するためには、そのデバイスを販売テナントから顧客テナントへ移動させる必要がある。

このように、あるテナントから別のテナントへデバイスを移動させる場合、デバイスの所属テナントを認可サーバーが単に書き換えることはテナント分離の原則に反する。すなわち、テナントＡのものであるデバイスがクラウド側の処理だけでテナントＢへ所属が変更になるということは、テナントＡの権限でテナントＢへクライアントを作成していることになる。つまり、分離されてなければならないテナント間で処理が発生してしまっている。これを避けるためには、デバイスはテナントＢに新規登録し直す必要があるが、テナントＢの作成後に手動でデバイスを登録し直すことはユーザーの手間となる。

上記課題を解決するために本願発明は以下の構成を有する。すなわち、情報処理装置と、サービスを提供するサービス提供サーバーと、前記サービスを利用するための認可情報を発行する認可サーバーとを含むシステムであって、前記認可サーバーは、情報処理装置と、当該情報処理装置が登録されたテナントとを対応づけて管理する管理手段と、要求に応じて、前記情報処理装置をテナントに登録するための登録キーを発行する発行手段と、前記登録キーを用いて前記情報処理装置の登録要求を受け付けた場合に、当該情報処理装置を前記テナントに対応づけて前記管理手段に登録し、当該情報処理装置を識別するための認証情報を発行する登録する登録手段と、前記認証情報を用いて前記サービスを利用するための認可情報の要求を受け付けた場合に、当該認証情報の検証結果に応じて、前記認可情報を発行する認可手段と、前記テナントに対応づけて登録されている前記情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持する受け付け手段とを有し、前記情報処理装置は、前記認可サーバーに対し、前記登録キーを用いて当該情報処理装置のテナントへの登録要求を行い、当該登録要求の応答として前記認証情報を取得する登録要求手段と、前記認可サーバーに対し、前記認証情報を用いて前記認可情報の取得要求を行い、当該取得要求の応答として前記認可情報を取得する取得手段とを有し、前記認可サーバーの前記認可手段は、前記情報処理装置から前記認可情報の取得要求を受け付けた際に、前記情報処理装置の移動先のテナントの情報を保持していた場合、当該移動先のテナントの情報を前記情報処理装置に通知し、前記情報処理装置の前記登録要求手段は、前記認可サーバーに対して、前記情報処理装置を前記移動先のテナントに登録するための登録キーの要求を行い、当該要求により得られた登録キーを用いて、当該情報処理装置の前記移動先のテナントへの登録要求を行う。

本発明によれば、デバイスが所属するテナントを、テナント分離の原則に反することなく自動で登録し直すことが可能となる。

本発明に係るシステムの構成例を示す図。本発明に係るハードウェア構成の例を示す図。第一の実施形態に係るデバイスと認可サーバーの機能ブロック図。第一の実施形態に係るデバイスのテナント移動処理の流れを示すシーケンス図。第一の実施形態に係る認可サーバーのトークン取得要求の受信時の処理を示すフローチャート。第二の実施形態に係るデバイスのテナント移動処理を示すシーケンス図第三の実施形態に係る移動先テナント情報登録処理を示すフローチャート。第四の実施形態に係るデバイスの機能ブロック図。第四の実施形態に係るデバイスの移動処理を示すシーケンス図。第一の実施形態に係る移動先テナントを指定する画面例を示す図。第四の実施形態に係るテナントの移動を指示する画面例を示す図。

以下、添付図面を参照して実施形態を詳しく説明する。尚、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。さらに、添付図面においては、同一若しくは同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜第１の実施形態＞
［システム構成］
図１は、本実施形態に係るシステム構成の例を示す図である。ＷＡＮ（ＷｉｄｅＡｒｅａＮｅｔｗｏｒｋ）１００は、インターネット等により構成される。すなわち、本実施形態では、ＷＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）システムが構築されている。ＬＡＮ（ＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋ）１１０は各構成要素を接続する。なお、ＷＡＮ１００やＬＡＮ１１０から構成される各種ネットワークの接続方式や有線／無線などは限定するものではなく、各種通信方法が組み合わせて実現されてよい。

デバイス１０１、端末１０２、認可サーバー１０３、およびリソースサーバー１０４は、それぞれＬＡＮ１１０、ＷＡＮ１００を介して通信可能に接続されている。本実施形態におけるシステムでは、認可サーバー１０３、およびリソースサーバー１０４がＷＡＮ１００側に位置し、ＬＡＮ１１０側に位置するデバイス１０１および端末１０２がＷＡＮ１００を介して各種サーバーに接続可能であるものとする。

認可サーバー１０３は、ＯＡｕｔｈ２．０を実現するための認可処理を行う。リソースサーバー１０４は、ネットワーク（ＬＡＮ１１０、ＷＡＮ１００）を介して各種サービスを提供するサービス提供サーバーとして機能する。

端末１０２は、ＰＣ（ＰｅｒｓｏｎａｌＣｏｍｐｕｔｅｒ）や携帯端末などであり、ユーザーが操作する装置である。端末１０２は、不図示であるが、例えば、Ｗｅｂブラウザーや、クラウド（認可サーバー１０３やリソースサーバー１０４）にアクセスするための専用のアプリケーションを備える。

デバイス１０１は、複写機や、スマートフォンなどの携帯端末が挙げられるが、特に限定するものではない。デバイス１０１は、ネットワーク（ＬＡＮ１１０、ＷＡＮ１００）を介して認可サーバー１０３に登録され、その登録に基づいてリソースサーバー１０４が提供するサービスを利用する。サービスの利用例として、デバイス１０１は、データをリソースサーバー１０４にアップロードするなどが挙げられる。デバイス１０１もまたＷｅｂブラウザー等の各種モジュールを備える。

また、認可サーバー１０３、およびリソースサーバー１０４は、データベースサーバー（不図示）とネットワークを介して接続し、各サーバーモジュールが利用するデータをデータベースサーバーに格納するよう構成してもよい。さらに、認可サーバー１０３、およびリソースサーバー１０４は、同一のサーバー（コンピューター）上に構成されていてもよい。また、各サーバーは、単体のコンピューターに限らず、複数台のコンピューターで構成されたシステムであっても構わない。

（ハードウェア構成）
図２は、本実施形態に係るデバイス１０１、端末１０２、認可サーバー１０３、およびリソースサーバー１０４のハードウェア構成の例を示す図である。本実施形態の各サーバー、デバイス１０１、および端末１０２には、一般的な情報処理装置のハードウェア構成を適用できる。さらに各サーバーについては、ＩａａＳ（ＩｎｆｒａｓｔｒｕｃｔｕｒｅａｓａＳｅｒｖｉｃｅ）として提供される情報処理装置の仮想的なハードウェア構成を適用することもできる。

図２において、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）２０１は、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）２０３が有するプログラム用ＲＯＭに記憶されたＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）やアプリケーション等のプログラムを実行し、システムバス２０４に接続される各ブロックを制御する。また、ＣＰＵ２０１は、ハードディスク（ＨＤ）等の外部メモリ２１１からＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）２０２にロードされたプログラムを実行し、各ブロックを制御する。後述する各シーケンスの処理は、ＣＰＵ２０１によるプログラムの実行により実現できる。

ＲＡＭ２０２は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。キーボードコントローラー２０５は、キーボード２０９やポインティングデバイス（不図示）からの入力を制御する。ディスプレイコントローラー２０６は、ディスプレイ２１０の表示を制御する。外部メモリコントローラー２０７は、各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２１１におけるデータアクセスを制御する。ネットワークコントローラー２００８は、ＷＡＮ１００、ＬＡＮ１１０を介して接続された他の機器との通信制御処理を実行する。

本実施形態において、デバイス１０１、端末１０２、認可サーバー１０３、およびリソースサーバー１０４はいずれも、図２にて示した情報処理装置２００の構成を有するものとする。ただし、図２の構成に限定するものではなく、ディスプレイ２１０を備えていなかったり、他の機能を備えていていたりしても構わない。特にＩａａＳとして提供される仮想的な情報処理を想定する場合においては、キーボードコントローラー２０５、ディスプレイコントローラー２０６等は設けられず、ネットワークコントローラー２０８を介して接続される端末に備えるキーボード２０９や、ディスプレイ２１０から操作されるよう構成される。後述の全ての説明において、特に断りのない限り、各サーバーや端末、およびデバイスにおける実行のハード上の主体は、ＣＰＵ２０１であり、ソフトウェア上の主体は、外部メモリ２１１にインストールされたアプリケーションプログラムである。

（機能構成）
図３は、デバイス１０１、および認可サーバー１０３において、特に本実施形態に係る部分の機能ブロックの構成例を示す図である。図３に示す各機能部は、各装置が有するＣＰＵ２０１が制御プログラムを実行することにより実現される。したがって、各装置は、図３に示す機能以外を提供可能であってよい。

図３（Ａ）は、本実施形態に係るデバイス１０１の機能構成の例を示す。登録キー入力受信部３０１は、デバイス１０１を認可サーバー１０３へ登録するためのデバイス登録キーの入力を受け付ける。デバイス登録キーの入力は、デバイス１０１におけるハードキーやタッチパネル操作による入力のほか、入力Ｉ／Ｆを用いたＯＣＲ（ＯｐｔｉｃａｌＣｈａｒａｃｔｅｒＲｅｃｏｇｎｉｔｉｏｎ）や二次元バーコードなどの読み取りによって行ってもよい。また、端末１０２が備えるＷｅｂブラウザー（不図示）などからデバイス１０１が提供する入力画面へアクセスし、デバイス登録キーを入力する構成であってもよい。

テナント登録部３０２は、認可サーバー１０３に対してデバイス１０１の登録を要求する。このとき、テナント登録部３０２は、デバイス登録キー、デバイスシリアルＩＤ、およびデバイス１０１が持つ証明書を認可サーバー１０３へ送信する。ここで保持されている証明書は、例えば、Ｘ．５０９形式のクライアント証明書およびその秘密鍵であり、この証明書によりデバイス１０１は自身をどのベンダーのデバイスであるか証明することができる。証明書は、デバイス１０１における証明書ストア（不図示）に保存されている。情報の送信にはＪＷＴ（ＪＳＯＮＷｅｂＴｏｋｅｎ）を使用してもよく、その場合はＪＷＴにデバイス登録キー、デバイスシリアルＩＤなどを記述し、証明書で署名する。以降省略するが、デバイス１０１と認可サーバー１０３とのやり取りではいずれもＪＷＴを使用することができる。

シークレット保持部３０３は、デバイス１０１を認可サーバー１０３に登録後に返却される、クライアントＩＤとシークレットを保持する。クライアントＩＤは、デバイス１０１を一意に識別するために発行される識別情報である。また、シークレットは、クライアントＩＤ（識別情報）に対応付けられた、クライアント（ここでは、デバイス１０１）を認証するために用いられる認証情報である。

トークン要求部３０４は、クライアントＩＤとシークレットを送信して、認可トークンを認可サーバー１０３へ要求する。認可トークンは、リソースサーバー１０１が提供するサービスを利用するための認可情報であり、デバイス１０１がリソースサーバー１０４のＡＰＩを利用する際に必要となる。

登録キー要求部３０５は、デバイス登録キーを認可サーバー１０３へ要求する。デバイス１０１がデバイス登録キーを要求する場合としては、既にテナントに登録され、そこから別のテナントに移動しようとしている場合である。本実施形態では、デバイス登録キーの要求時には、クライアントＩＤとシークレットが指定される。

図３（Ｂ）は、本実施形態に係る認可サーバー１０３の機能構成の例を示す。トークン発行部３１１は、デバイス１０１から認可トークンの取得要求を受け付けると、クライアント認証を行う。具体的には、受信したクライアントＩＤとシークレットの組が認可サーバー１０３に登録されているか否かを検証し、その検証結果から要求に対する可否を決定する。クライアントＩＤとシークレットの組が、認可サーバー１０３が管理するクライアント管理テーブルに登録されている場合、その要求元に対するクライアント認証が成功する。クライアント認証に成功した場合、トークン発行部３１１は、要求元に対する認可トークンを発行する。具体的には、トークン発行部３１１は、認可トークンＩＤを発行し、認可トークンを利用するための情報と紐づけて、トークン管理テーブルで管理する。なお、以下に示す各テーブルは、ＣＰＵ２０１が管理部として機能し、ＨＤ２１１等にて保持、管理される。

表１は、本実施形態に係るトークン管理テーブルの例を示す。トークン管理テーブルでは、認可トークンＩＤに紐づけてトークン種別やクライアントＩＤなどが管理される。ユーザーＵＵＩＤは、デバイス１０１に権限を委譲するユーザーを指す。なお、ＵＵＩＤ（ＵｎｉｖｅｒｓａｌＵｎｉｑｕｅＩｄｅｎｔｉｆｉｅｒ）は、重複しないユニークなＩＤ（識別情報）である。スコープは、ユーザーから権限委譲されるリソースの範囲を定義している。表１に示す例の場合、スコープが「テナント専用クライアント」となっており、ユーザーＩＤ「１００００００１」のユーザーの権限が、デバイス１０１（特定のテナントに紐づけられたクライアント）に委譲されることを意味する。

また、トークン発行部３１１は、クライアントＩＤに紐づいて、テナントの移動先情報が設定されていないか否かを判定する。本処理の詳細については後述する。

クライアント生成部３１２は、テナントＩＤの情報を含むデバイス登録キー、デバイスシリアルＩＤ、およびデバイス１０１が持つ証明書とともに、テナント登録要求をデバイス１０１から受け付けると、証明書を用いてクライアント認証を行う。そして、クライアント生成部３１２は、クライアント認証が成功した場合に、クライアントを生成する。具体的には、クライアント生成部３１２は、クライアントＩＤ、およびシークレットを発行し、これらをデバイスシリアルＩＤとテナントＩＤに紐づけて管理する。

移動先テナント情報登録部３１３は、デバイス１０１の移動先テナントＩＤを受信し、クライアントＩＤに紐づけて管理する。

上記の各処理部が扱うデータはクライアント管理テーブルに保存される。表２は、本実施形態に係るクライアント管理テーブルの例を示す。クライアントＩＤは、クライアント生成部３１２が生成するＩＤ（識別情報）であり、本実施形態に係るシステムにて一意となる。シークレットは、クライアント生成部３１２にて生成され、クライアントＩＤとの組でクライアントの認証の際に用いられる。テナントＩＤは、クライアント（すなわち、デバイス１０１）が所属しているテナントのＩＤ（識別情報）である。デバイスシリアルＩＤは、デバイス１０１を一意に識別するためのＩＤ（識別情報）である。移動先テナントＩＤは、指定されるまでは空となる。

トークン管理テーブル（表１）とクライアント管理テーブル（表２）を用いて、認可サーバー１０３は、デバイス１０１とテナントを紐づけて、認可トークンを管理する。

登録キー生成部３１４は、テナントＩＤを受信すると、このテナントＩＤにて示されるテナントへデバイスを登録するためのデバイス登録キーを生成する。デバイス登録キーの生成を依頼するアクター（要求主体）は２つ存在し、１つはリソースサーバー１０４を介したユーザーである。この場合は、登録キー生成部３１４は、テナントにログインしたユーザーの権限でデバイス登録キーを生成する。もう１つはデバイス１０１であり、この場合は、登録キー生成部３１４は、デバイス１０１が持つ証明書を受信し、証明書によるクライアント認証に成功した場合にデバイス登録キーを生成する。

表３は、本実施形態に係るデバイス登録キー管理テーブルの例を示す。デバイス登録キーは、例えば、１６桁の整数であり、テナントＩＤに紐づけられる。有効期限は、デバイス登録キーが使用可能な期限である。

［画面例］
図１０は、本実施形態に係る認可サーバー１０３の移動先テナント情報登録部３１３に移動先テナントを指示する場合に、端末１０２のＷｅｂブラウザー（不図示）等に表示される画面の一例である。図１０（Ａ）は、デバイス一覧画面１０００の構成例を示し、デバイス一覧画面１０００では、特定のテナント（この例では「ＡＡＡテナント」）をユーザーが指定し、そのテナントに登録されているデバイスの一覧が表示される。また、「ＡＡＡテナント」のテナントＩＤとして「１０１ＡＡ」が割り当てられているものとする。ユーザーは、テナントを移動させたいデバイスの登録先テナント変更ボタン１００１を押下する。この例では、シリアル番号が「Ｄ０００００００１」のデバイスが選択されたとする。

登録先テナント変更ボタン１００１が押下されると、図１０（Ｂ）に示す登録先テナントの変更画面１０１０が表示される。シリアル番号１０１１は、デバイス一覧画面１０００にて選択されたデバイスのシリアル番号を示す。移動先テナントＩＤ１０１２は、テキストボックスで入力可能となっており、ユーザーは移動先のテナントのテナントＩＤを指定する。このとき、移動先テナント情報登録部３１３は入力されたテナントＩＤからテナント名を検索し表示してもよい。ユーザーが変更ボタン１０１３を押下することで、移動先テナント情報登録部３１３へ登録指示が発行される。

［テナント移動処理］
図４は、本実施形態に係るデバイス１０１のテナント移動の処理の流れを示すシーケンス図である。図４に示す処理は、各装置のＣＰＵ２０１がＲＯＭ２０３等の記憶部に格納されたプログラムを読み出して実行することで実現される。

図４においてリソースサーバー１０４では、例えばデバイス１０１の設定情報や稼働情報を管理するデバイス管理サービスが稼働しているとする。テナント移動の処理は大きく３つの工程に分かれる。まず、デバイス１０１がテナントＡ（移動前のテナント）に登録される。次に、テナントＡに登録されたデバイスの移動先のテナントとして、テナントＢが設定される。最後に、テナントＡにアクセスしたデバイス１０１がテナントＢに新規登録（移動）される。

まず、デバイス１０１をテナントＡに登録する流れについて説明する。図４のＳ４０１〜Ｓ４０９がこの工程に相当する。

Ｓ４０１にて、端末１０２は、テナントＡのユーザーの指示に基づき、デバイス１０１をテナントＡに登録するため、リソースサーバー１０４へデバイス登録キーを要求する。

Ｓ４０２にて、リソースサーバー１０４は、端末１０２からの要求に基づき、認可サーバー１０２へデバイス登録キーを要求する。このとき、リソースサーバー１０４は、リソースサーバー１０４にログインしているユーザーの権限でデバイス登録キーを要求する。

Ｓ４０３にて、認可サーバー１０２の登録キー生成部３１４は、リソースサーバー１０４からの要求に基づいて権限検証を行い、その権限検証が成功した場合にテナントＡに登録するためのデバイス登録キーを生成し、デバイス登録キー管理テーブル（表３）に登録する。なお、権限検証に失敗した場合には、その旨をリソースサーバー１０４に返してもよい。この場合、リソースサーバー１０４は更に、端末１０２に権限検証が失敗した旨を通知することとなる。

Ｓ４０４にて、認可サーバー１０３は、要求に応答して、リソースサーバー１０４に対して生成したデバイス登録キーを返す。

Ｓ４０５にて、リソースサーバー１０４は、認可サーバー１０３から受信したデバイス登録キーを端末１００へ返す。このとき、例えば、端末１０２が有するＷｅｂブラウザー（不図示）等にて、受信したデバイス登録キーが表示されてよい。

Ｓ４０６にて、端末１０２は、テナントＡのユーザーの指示に基づいて、デバイス１０１へデバイス登録キーを入力する。例えば、端末１０２は、デバイス１０１にアクセスし、デバイス１０１が提供する画面を介してデバイス登録キーを入力してよい。または、ユーザーがデバイス１０１の入力装置を使用してデバイス１０１に直接入力するような構成であってもよい。

Ｓ４０７にて、デバイス１０１のテナント登録部３０２は、入力されたデバイス登録キー、自身のデバイスシリアル番号、及び、自身が保持する証明書の情報を認可サーバー１０３へ送信し、デバイス登録要求を行う。

Ｓ４０８にて、認可サーバー１０３のクライアント生成部３１２は、デバイス１０１から受信した証明書を用いてデバイス１０１を認証する。また、認証が成功すると、クライアント生成部３１２は、受信したデバイス登録キーからテナントＩＤ（すなわち、テナントＡのテナントＩＤ）を抽出し、クライアントＩＤとシークレットを生成して保存する。なお、認証に失敗した場合には、その旨をデバイス１０１に返してよい。

Ｓ４０９にて、認可サーバー１０３は、生成したクライアントＩＤとシークレットをデバイス１０１に返す。デバイス１０１のシークレット保持部３０３は、認可サーバー１０３から受信したクライアントＩＤおよびシークレットを保存する。この時点で、デバイス１０１はテナントＡに登録されたことになる。なお不図示であるが、リソースサーバー１０４は認可サーバー１０３へ問い合わせることにより、各デバイスに対応するクライアントＩＤのリストを取得可能であるとする。

続いて、テナントＡに登録済みのデバイスをテナントＢへ移動させるための設定を行う流れについて説明する。図４のＳ４１１〜Ｓ４１３がこの工程に相当する。

Ｓ４１１にて、端末１０２は、テナントＡのユーザーの指示に基づいて、デバイス１０１が所属するテナントをテナントＢへ移動することをリソースサーバー１０４に対して指示する。ここでの指示の方法は、図１０に示した画面を用いて行われることとする。

Ｓ４１２にて、リソースサーバー１０４は、認可サーバー１０３に対して、デバイス１０１のクライアントＩＤを指定し、テナント移動を指示する。上述したように、リソースサーバー１０４は、デバイスに対応するクライアントＩＤのリストを取得可能であり、ここで指定されるクライアントＩＤは、デバイス１０１のシリアル番号に対応するクライアントＩＤを示すことで行われる。

Ｓ４１３にて、認可サーバー１０３の移動先テナント情報登録部３１３は、クライアントＩＤに紐づけて移動先のテナントＩＤ（すなわち、テナントＢのテナントＩＤ）をクライアント管理テーブル（表２）の移動先テナントＩＤに登録する。この時点で、テナント移動の準備ができたことになる。

最後に、デバイス１０１がテナントＢへ新規登録を行う流れについて説明する。図４のＳ４２１〜Ｓ４３３がこの工程に相当する。

Ｓ４２１にて、デバイス１０１のトークン要求部３０４は、デバイス１０１がリソースサーバー１０３のＡＰＩを使用するために、認可サーバー１０３へクライアントＩＤとシークレットを送信し、認可トークンを要求する。

Ｓ４２２にて、認可サーバー１０３のトークン発行部３１１は、デバイス１０１から受信したクライアントＩＤとシークレットの組が認可サーバー１０３に登録されているか否かを、クライアント管理テーブル（表２）を参照して検証する。さらに、トークン発行部３１１は、クライアントＩＤに紐づく移動先テナント情報の有無を確認する。このとき、現在所属しているテナントの種類に応じて、確認処理の有無を判断してもよい。この処理については、図５を用いて後述する。

クライアント認証に成功し、かつ移動先テナント情報が存在する場合、Ｓ４２３にて、トークン発行部３１１は、デバイス１０１へ移動先となるテナントＩＤ（すなわち、テナントＢのＩＤ）を返す。このとき、レスポンスとして、例えば、ＨＴＴＰステータスコード“４０３”を返すことが考えられるが、これに限定するものではない。なお、クライアント認証に失敗した場合は、その旨をデバイス１０１に返してよい。

Ｓ４２４にて、デバイス１０１のトークン要求部３０４は、移動先のテナントＩＤが認可サーバー１０３から返されると、登録キー要求部３０５を呼び出す。登録キー要求部３０５は、移動先テナントＩＤとデバイス１０１が持つ証明書を付与して認可サーバー１０３へデバイス登録キーを要求する。

Ｓ４２５にて、認可サーバー１０３の登録キー生成部３１４は、デバイス１０１から受信した証明書に基づいてクライアント認証を行い、デバイス１０１が想定したベンダーの製品でありデバイス登録キーを発行して良いか否かを判定する。発行して良いと判定した場合、登録キー生成部３１４は、デバイス１０１をテナントＢに登録するためのデバイス登録キーを生成し、デバイス登録キー管理テーブル（表３）に登録する。

Ｓ４２６にて、登録キー生成部３１４は、生成したデバイス登録キーを、要求に対する応答としてデバイス１０１へ返す。

Ｓ４２７にて、デバイス１０１のテナント登録部３０２は、Ｓ４２６にて取得したデバイス登録キー、デバイスシリアル番号、及び証明書の情報を認可サーバー１０３へ送信し、デバイス登録要求を行う。

Ｓ４２８にて、認可サーバー１０３のクライアント生成部３１２は、Ｓ４２７にてデバイス１０１から受信した証明書を用いてデバイス１０１を認証する。また、認証が成功すると、クライアント生成部３１２は、Ｓ４２７にて受信したデバイス登録キーからテナントＩＤ（すなわち、テナントＢのＩＤ）を抽出し、クライアントＩＤとシークレットを生成して保存する。なお、認証に失敗した場合には、その旨をデバイス１０１に返してよい。

Ｓ４２９にて、認可サーバー１０３は、Ｓ４２８にて生成したクライアントＩＤとシークレットをデバイス１０１に返す。

Ｓ４３０にて、デバイス１０１のシークレット保持部３０３は、Ｓ４２９にて認可サーバー１０３から受信したクライアントＩＤとシークレットを保存する。

Ｓ４３１にて、デバイス１０１のトークン要求部３０４は、Ｓ４３０にて取得した新しいクライアントＩＤとシークレットを認可サーバー１０３へ送信し、認可トークンを要求する。

Ｓ４３２にて、認可サーバー１０３のトークン発行部３１１は、受信したクライアントＩＤとシークレットの組が認可サーバー１０３に登録されているか否かを、クライアント管理テーブル（表２）を参照して検証する。さらに、トークン発行部３１１は、クライアントＩＤに紐づく移動先テナント情報の有無を確認する。

クライアント認証に成功し、かつ移動先テナント情報が存在しない場合、Ｓ４３３にて、トークン発行部３１１は、デバイス１０１へ認可トークンを返す。以後、図４では不図示となるが、デバイス１０１は、Ｓ４３３にて受信した認可トークンをリソースサーバー１０４へ送る。更に、リソースサーバー１０４は、認可トークンを認可サーバー１０３へ送る。そして、認可サーバー１０３は、認可トークンを検証し、正当性が確認されることにより、デバイス１０１がリソースサーバー１０４のＡＰＩを使用することが可能となる。トークンのやり取りを前述したＪＷＴで行う場合、リソースサーバー１０４は、認可サーバー１０３へ認可トークンは送らず自身で認可トークンの検証を行う。

なお、Ｓ４２２の時点で、クライアント認証に成功し、かつ移動先テナント情報が存在しない場合、テナントＡにおける認可トークンがデバイス１０１に返される。その後、この認可トークンを用いて、デバイス１０１は、テナントＡにおけるリソースにてＡＰＩを利用することが可能となる。この場合、テナントの移動は行われないこととなる。

以上説明したフローを実行することにより、テナントＡに登録されたデバイス１０１はテナントＢへ新規登録（移動）することが可能となる。

（移動先テナント情報の確認処理）
図５は、認可サーバー１０３において、デバイス１０１からトークン取得要求を受信した際の処理の流れを示したフローチャートである。本処理フローは、図４のＳ４２２の工程にて行われる。

Ｓ５０１にて、認可サーバー１０３のトークン発行部３１１は、デバイス１０１からトークン取得要求を受け、クライアントＩＤとシークレットを受信する。これは、図４のＳ４２１に対応する。

Ｓ５０２にて、トークン発行部３１１は、受信したクライアントＩＤをキーとしてクライアント管理テーブル（表２）を参照し、クライアント認証を行う。ここでクライアント認証に失敗した場合は、本処理フローを終了してもよい。この場合、クライアント認証に失敗したことがデバイス１０１に通知される。

Ｓ５０３にて、トークン発行部３１１は、クライアントＩＤをキーとしてクライアント管理テーブル（表２）を参照し、デバイス１０１が所属するテナントＩＤを取得する。

Ｓ５０４にて、トークン発行部３１１は、テナント１０１が所属するテナントの種別が特定の種別か否かを判定する。特定の種別の例として、販売テナントと顧客テナントが挙げられる。例えば、デバイス１０１が販売テナントに登録されている場合にのみテナント移動の可能性があるとすれば、特定の種別を販売テナントとして判定を行うことで、その他の種別のテナントに対する移動情報の不要な確認を省略することができる。テナントの種別に関しては後述する。特定の種別であると判定された場合（Ｓ５０４にてＹＥＳ）Ｓ５０５へ進み、特定の種別でないと判定された場合（Ｓ５０４にてＮＯ）Ｓ５０７へ進む。

Ｓ５０５にて、トークン発行部３１１は、クライアント管理テーブル（表２）を参照して、テナント移動情報の有無を確認する。テナント移動情報が存在する場合（Ｓ５０５にてＹＥＳ）Ｓ５０６へ進み、テナント移動情報が存在しない場合（Ｓ５０５にてＮＯ）Ｓ５０７へ進む。

Ｓ５０６にて、トークン発行部３１１は、トークン取得要求に対する応答として、デバイス１０１に移動先のテナントＩＤを返す。これは、図４のＳ４２３に対応する。そして、本処理フローを終了する。

Ｓ５０７にて、トークン発行部３１１は、認可トークンを発行し、トークン取得要求に対する応答として、デバイス１０１に認可トークンを返す。これは、テナントの移動を行うことなく、認可トークンの発行処理を行う場合に相当する。そして、本処理フローを終了する。

上述したテナント種別は、認可サーバー１０３においてテナント管理テーブルで管理されている。表４は、本実施形態に係るテナント管理テーブルの例を示す。テナントＩＤ、テナント名、テナント種別、および作成日時が対応付けて管理されている。ここでは、テナント種別の例として、「販売テナント」と「顧客テナント」が示されているが、他の種別が用いられてもよい。また、テナントの種別ごとに別のテーブルで管理する構成をとってもよい。

以上、本実施形態のように、認可サーバー１０３からテナント移動指示を受信したデバイス１０１が移動先のテナントへの新規登録を要求することで、テナント分離の原則に反することなく、かつ、ユーザーの手間が生じずにテナントの移動が可能となる。

＜第二の実施形態＞
本発明に係る第二の実施形態について、図６を用いて説明する。第一の実施形態ではデバイス１０１がテナント移動後、移動元のテナント（上記の例では、テナントＡ）にクライアントが存在したままとなっている。本実施形態では、移動元のテナントにおいてクライアントを削除、或いは無効化する方法について説明する。なお、第一の実施形態と重複する構成については、説明を省略する。

［テナント移動処理］
図６は、本実施形態に係る、デバイス１０１がテナントＡからテナントＢに移動する流れを示したシーケンス図である。第一の実施形態にて述べた図４のシーケンスと同様の処理については説明を省略する。図４との差分は、Ｓ６０１〜Ｓ６０３の工程が追加となっている部分である。認可サーバー１０３にてテナントＢにクライアントが新規作成され（Ｓ４２８）、デバイス１０１がクライアントＩＤとシークレットを受信して保存した後（Ｓ４２９〜Ｓ４０３）、Ｓ６０１〜Ｓ６０３の処理が行われる。

Ｓ６０１にて、デバイス１０１のテナント登録部３０２は、テナントＡを指定してデバイス削除要求を行う。このとき、デバイス削除要求として、削除対象となるテナントＡのクライアントＩＤとこれに対応するシークレットが送信される。

Ｓ６０２にて、認可サーバー１０３のクライアント生成部３１２は、Ｓ６０１にてデバイス１０１から受信したテナントＡのクライアントＩＤとシークレットを用いてクライアント認証を行う。認証が成功すると、クライアント生成部３１２は、指定されたクライアントＩＤのクライアント情報をクライアント管理テーブル（表２）から削除する。なお、クライアントの削除ではなく無効化するようにクライアント管理テーブルにフラグを設定し、再利用可能な状態にするような構成であってもよい。

Ｓ６０３にて、クライアント生成部３１２は、要求に対する応答として、削除完了をデバイス１０１へ返却する。更に、デバイス１０１のシークレット保持部３０３は、保持しているテナントＡのクライアントＩＤとシークレットを削除する。その後、Ｓ４３１の処理へ進む。

以上、本実施形態により、第一の実施形態の効果に加え、移動元のテナントにおけるクライアント情報の削除もしくは無効化が可能となる。

なお、本実施形態において、認証エラー等により、移動先のテナント（上記の例では、テナントＢ）への移動に失敗した場合には移動元のテナントにおけるクライアント情報の削除または無効化は行われない。

＜第三の実施形態＞
本発明に係る第三の実施形態について、図７を用いて説明する。なお、第一の実施形態と重複する構成については、説明を省略する。本実施形態では、認可サーバー１０３へ移動先のテナント情報を設定する際に、指定されたテナントへの移動が可能か否かを判定する。販売テナントと顧客テナントの例を挙げると、販売テナントが顧客テナントと契約を結びサービスを提供する場合、これらのテナント間には販売関係が結ばれる。この販売関係が結ばれている場合のみ、テナントの移動を可能とする。

テナント間の販売関係は販売関係管理テーブルにて管理される。表５は、本実施形態に係る販売関係管理テーブルの例を示す。表５の例では、テナントＩＤ「１０１ＡＡ」の販売テナントは、テナントＩＤ「１００１ＡＡ」と「１００２ＡＡ」の顧客テナントと販売関係がある。サービスは、販売テナントが顧客テナントに対し使用を許可している（提供している）サービス（ライセンス）である。

また、販売テナントが複数存在し、販売テナント間の関係でもテナントの移動可否を判断できる場合がある。例えば、販売会社が顧客のテナントを直接管理する販売形態を「直接販売」と呼ぶ。なお、直接販売の場合でも販売会社が複数階層を持つこともできる。一方、販売会社が販売代理店を介してクラウドサービスを提供し、販売代理店が顧客のテナントを管理する販売形態を「間接販売」と呼ぶ。このとき、直接販売の販売形態を持つテナント間にだけ、デバイスのテナント移動を許可することが考えられる。

表６は、本実施形態に係る、顧客テナントも含めた販売テナント間の販売形態管理テーブルの例を示す。表６の例ではテナントＩＤ「１０１ＡＡ」の販売テナントが管理するテナントとしてテナントＩＤ「１０２ＡＡ」と「１１１ＡＡ」の販売テナントが存在する。テナント種別は、テナント管理テーブル（表４）にて管理されており、テナントＩＤをキーにして紐づける。例えば、テナントＩＤ「１０１ＡＡ」と「１０２ＡＡ」のテナント間の販売形態は「直接販売」であり、テナントＩＤ「１０１ＡＡ」と「１１１ＡＡ」のテナント間の販売形態は「間接販売」である。また、テナントＩＤ「１０２ＡＡ」の販売テナントが管理するテナントとしてテナントＩＤ「１０３ＡＡ」の販売テナントとテナントＩＤ「１００１ＡＡ」の顧客テナントが存在する。これらは両者とも販売形態は「直接販売」である。また、テナントＩＤ「１１１ＡＡ」の販売テナントが管理するテナントとしてテナントＩＤ「１１０１ＡＡ」の顧客テナントが存在する。このテナント間の販売形態も「直接販売」である。

テナントＩＤ「１０１ＡＡ」の販売テナントにデバイスが登録されているとして、「直接販売」の関係があるテナントにのみデバイスを移動可能であるとする。この場合、テナントＩＤ「１０１ＡＡ」の販売テナントから移動可能なテナントは、テナントＩＤ「１０２ＡＡ」、「１０２ＡＡ」、「１０３ＡＡ」、「１００１ＡＡ」のテナントとなる。この場合は、階層構造により、更に下位のテナントに移動可能であるとする。なお、テナントＩＤ「１１１ＡＡ」と「１１０１ＡＡ」のテナントには移動できない。

（移動先登録処理）
図７は、本実施形態に係る、移動先登録処理の流れを示したフローチャートである。本処理フローは、認可サーバー１０３において、移動先テナント情報の登録要求を受信した際に実行され、例えば、図４のＳ４１３の工程にて行われる。

Ｓ７０１にて、認可サーバー１０３の移動先テナント情報登録部３１３は、リソースサーバー１０４などから移動対象のクライアントと移動先テナント情報を受信する。

Ｓ７０２にて、移動先テナント情報登録３１３は、受信した移動先のテナントが、移動対象のクライアントのテナント（デバイス１０１が現在登録されているテナント）から移動可能か否かを判定する。移動可能か否かの判定は、上述したように、表５や表６などを用いて行われる。移動可能であると判定された場合（Ｓ７０２にてＹＥＳ）Ｓ７０３へ進み、移動可能でないと判定された場合（Ｓ７０２にてＮＯ）Ｓ７０４へ進む。

Ｓ７０３にて、移動先テナント情報登録部３１３は、移動先のテナントＩＤをクライアント管理テーブルに登録する。そして、本処理フローを終了する。

Ｓ７０４にて、移動先テナント情報登録部３１３は、要求されたテナントＩＤは登録できないとして、デバイス１０１へエラーを返す。この場合、再度移動先のテナントの指定を受け付けるような構成でもよい。そして、本処理フローを終了する。

以上、本実施形態により、第一の実施形態の効果に加え、移動先として要求されたテナントへの移動の可否を販売関係に基づいて判定し、その可否をデバイス１０１に通知することが可能となる。

なお、上記の例では、販売関係に基づいて移動可能か否かを判定したが、これに限定するものではない。そのほかのテナント間の関係に基づいて移動の可否を判定してもよい。

＜第四の実施形態＞
本発明に係る第四の実施形態について、図８、図９、及び図１１を用いて説明する。上記の実施形態ではデバイスの利用者が意識することなく、移動先テナントが登録された後に、使用するデバイスのテナントが自動的に変更されていた。しかし、この場合、顧客が意図しないタイミングでテナントの移動が実行され、クラウドの利用が開始されてしまう可能性がある。そこで本実施形態では販売テナントで移動先テナントの登録が完了しただけではテナント移動は開始されず、デバイスの利用者（管理者）が能動的にテナントの移動を指示する形態について説明する。なお、第一の実施形態と重複する構成については、説明を省略する。

なお、デバイスの管理者が移動先テナントのテナントＩＤも含めて指示可能にすれば、認可サーバー１０３に移動先テナント情報の登録は技術的に必須ではなくなるが、本実施形態ではデバイスの管理者の指示のみでテナントを移動しないように、移動先テナント情報の事前登録も必須とした構成について説明する。

（画面構成）
図１１は、本実施形態に係るデバイス１０１のタッチパネル等のディスプレイ２１０に表示されるＵＩ（ＵｓｅｒＩｎｔｅｒｆａｃｅ）画面の例である。ＵＩ画面１１００は、例えば、デバイス１０１の管理者がデバイス１０１のテナント登録状況を確認したい場合などに表示される。ＵＩ画面１１００において、テナントＩＤが表示されている横にテナント移動ボタン１１０１が配置されている。デバイス１０１の管理者は、テナント移動ボタン１１０１を押すことにより、テナント移動の実行を指示する。なお、テナント移動ボタン１１０１が押下される際には、すでに移動先のテナント情報が登録されているものとする。したがって、移動先のテナント情報が登録されていない場合には、テナント移動ボタン１１０１は表示されないようにしてもよいし、押下できないような制御がなされてもよい。また、移動先および移動元のテナント情報をＵＩ画面１１００上に表示してもよい。

［機能構成］
図８は、本実施形態に係るデバイス１０１の機能構成の例を示すブロック図である。第一の実施形態の図３（Ａ）に示した構成に加え、テナント移動指示部８０１が設けられている。テナント移動指示部８０１は、図１１のＵＩ画面１１００に示すテナント移動ボタン１１０１がユーザーに押されたことに応じて、認可サーバー１０３へテナントの移動を指示する。具体的には、テナント移動指示部８０１は、認可サーバー１０３へデバイス１０１のクライアントＩＤとシークレットを送信し、テナントの移動を指示する。

［テナント移動処理］
図９は、本実施形態に係る、デバイス１０１がテナントＡからテナントＢに移動する流れを示したシーケンス図である。第一の実施形態にて述べた図４のシーケンスと同様の処理については説明を省略する。図４との差分は、Ｓ４２１の代わりにＳ９０１の処理が行われる点である。上述したように、本実施形態では、Ｓ４１１〜Ｓ４１３にて、移動先テナント情報の事前登録が行われているものとする。

デバイス１０１のテナント移動指示部８０１は、ユーザーによりデバイス１０１上にてＵＩ画面１１００のテナント移動ボタン１１０１を押下されたことを起因として、Ｓ９０１にて、認可サーバー１０３へテナントの移動を指示する。この処理は内部的には、図４のＳ４２１と同様に、認可サーバー１０３へ認可トークンを要求する処理と同じで良い。認可サーバー１０３側で移動先テナント情報の設定がなければ、認可サーバー１０３から認可トークンが返却される。この場合、この認可トークンを用いて、デバイス１０１は、テナントＡにおけるリソースにてＡＰＩを利用することが可能となり、テナントの移動は行われない。

以上、本実施形態により、デバイス１０１の管理者が意図したタイミングにてテナントの移動が可能となる。

＜その他の実施形態＞
本発明は上述の実施形態の１以上の機能を実現するプログラムをネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１０１…デバイス、１０２…端末、１０３…認可サーバー、１０４…リソースサーバー

Claims

情報処理装置と、サービスを提供するサービス提供サーバーと、前記サービスを利用するための認可情報を発行する認可サーバーとを含むシステムであって、
前記認可サーバーは、
情報処理装置と、当該情報処理装置が登録されたテナントとを対応づけて管理する管理手段と、
要求に応じて、前記情報処理装置をテナントに登録するための登録キーを発行する発行手段と、
前記登録キーを用いて前記情報処理装置の登録要求を受け付けた場合に、当該情報処理装置を前記テナントに対応づけて前記管理手段に登録し、当該情報処理装置を識別するための認証情報を発行する登録する登録手段と、
前記認証情報を用いて前記サービスを利用するための認可情報の要求を受け付けた場合に、当該認証情報の検証結果に応じて、前記認可情報を発行する認可手段と、
前記テナントに対応づけて登録されている前記情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持する受け付け手段と
を有し、
前記情報処理装置は、
前記認可サーバーに対し、前記登録キーを用いて当該情報処理装置のテナントへの登録要求を行い、当該登録要求の応答として前記認証情報を取得する登録要求手段と、
前記認可サーバーに対し、前記認証情報を用いて前記認可情報の取得要求を行い、当該取得要求の応答として前記認可情報を取得する取得手段と
を有し、
前記認可サーバーの前記認可手段は、前記情報処理装置から前記認可情報の取得要求を受け付けた際に、前記情報処理装置の移動先のテナントの情報を保持していた場合、当該移動先のテナントの情報を前記情報処理装置に通知し、
前記情報処理装置の前記登録要求手段は、前記認可サーバーに対して、前記情報処理装置を前記移動先のテナントに登録するための登録キーの要求を行い、当該要求により得られた登録キーを用いて、当該情報処理装置の前記移動先のテナントへの登録要求を行う、
ことを特徴とするシステム。
前記管理手段は、テナントそれぞれの種別を管理し、
前記認可サーバーの前記認可手段は、前記情報処理装置から前記認可情報の取得要求を受け付けた際に、当該情報処理装置が対応づけて登録されているテナントが特定の種別のテナントか否かを判定し、前記特定の種別のテナントに対応づけて登録されていると判定された場合に、当該移動先のテナントの情報の確認処理を行うことを特徴とする請求項１に記載のシステム。
前記認可サーバーの前記認可手段は、前記情報処理装置が前記特定の種別のテナントに対応づけて登録されていないと判定された場合、前記確認処理を行わずに前記認可情報の発行処理を行うことを特徴とする請求項２に記載のシステム。
前記情報処理装置の前記取得手段は、前記サービスを利用する際に、前記認可サーバーに対し、前記認証情報を用いて前記認可情報の取得要求を行うことを特徴とする請求項１乃至３のいずれか一項に記載のシステム。
前記情報処理装置の前記取得手段は、ユーザーによる指示を受け付けたことに起因して、前記認可サーバーに対し、前記認証情報を用いて前記認可情報の取得要求を行うことを特徴とする請求項１乃至３のいずれか一項に記載のシステム。
前記情報処理装置は、前記移動先のテナントへの移動が完了したことに応じて、前記認可サーバーに対して、移動元のテナントに対応づけて登録された情報の削除を要求する手段を更に有することを特徴とする請求項１乃至５のいずれか一項に記載のシステム。
前記認可サーバーの前記管理手段は更に、移動可能なテナントの情報を管理し、
前記認可サーバーの前記受け付け手段は、指定された前記異なるテナントに移動可能か否かを前記移動可能なテナントの情報に基づいて判定し、移動可能であると判定した場合に、前記異なるテナントの情報を移動先のテナントの情報として保持することを特徴とする請求項１乃至６のいずれか一項に記載のシステム。
前記認可サーバーの前記受け付け手段は、指定された前記異なるテナントに移動可能でないと判定した場合、エラーを通知することを特徴とする請求項７に記載のシステム。
情報処理装置と、サービスを提供するサービス提供サーバーと、前記サービスを利用するための認可情報を発行する認可サーバーとを含むシステムにおけるテナントの移動方法であって、
前記認可サーバーは、情報処理装置と、当該情報処理装置が登録されたテナントとを対応づけて管理する管理手段を有し、
前記認可サーバーにおいて、前記テナントに対応づけて登録されている前記情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持し、
前記情報処理装置において、前記認可サーバーに対し、前記認可サーバーにて発行された認証情報を用いて前記認可情報の取得要求を行い、
前記認可サーバーにおいて、前記認証情報を用いて前記サービスを利用するための認可情報の要求を受け付けた場合に、前記情報処理装置の移動先のテナントの情報を保持していた場合、当該移動先のテナントの情報を前記情報処理装置に通知し、
前記情報処理装置において、前記認可サーバーに対して、前記情報処理装置を前記移動先のテナントに登録するための登録キーの要求を行い、
前記認可サーバーにおいて、前記情報処理装置を前記移動先のテナントに登録するための登録キーの要求に応じて、当該登録キーを発行し、
前記情報処理装置において、前記認可サーバーに対し、前記登録キーを用いて当該情報処理装置の前記移動先のテナントへの登録要求し、
前記認可サーバーにおいて、前記情報処理装置を前記移動先のテナントに対応付けて前記管理手段に登録する
ことを特徴とするテナントの移動方法。
サービスを提供するサービス提供サーバーと、前記サービスを利用するための認可情報を発行する認可サーバーと、ネットワークを介して通信可能な情報処理装置であって、
前記情報処理装置とテナントが対応付けて前記認可サーバーにて登録されており、
前記情報処理装置は、
前記認可サーバーから発行された認証情報を用いて、前記認可サーバーに対して前記認可情報を要求する要求手段と、
前記要求手段による要求の応答として前記情報処理装置の移動先のテナントの情報が返された場合、前記認可サーバーに対して、前記情報処理装置を前記移動先のテナントへ登録するための登録キーの発行を要求し、当該登録キーを取得する取得手段と、
前記登録キーを用いて、前記認可サーバーに対して、当該情報処理装置の前記移動先のテナントへの登録要求を行う登録要求手段と
を有することを特徴とする情報処理装置。
サービスを提供するサービス提供サーバーと、前記サービスを利用するための認可情報を発行する認可サーバーと、ネットワークを介して通信可能な情報処理装置の制御方法であって、
前記情報処理装置とテナントが対応付けて前記認可サーバーにて登録されており、
前記情報処理装置において、
前記認可サーバーから発行された認証情報を用いて、前記認可サーバーに対して前記認可情報を要求する要求工程と、
前記要求工程による要求の応答として前記情報処理装置の移動先のテナントの情報が返された場合、前記認可サーバーに対して、前記情報処理装置を前記移動先のテナントへ登録するための登録キーの発行を要求し、当該登録キーを取得する取得工程と、
前記登録キーを用いて、前記認可サーバーに対して、当該情報処理装置の前記移動先のテナントへの登録要求を行う登録要求工程と
を有することを特徴とする情報処理装置の制御方法。
サービスを提供するサービス提供サーバーと、前記サービスを利用するための認可情報を発行する認可サーバーと、ネットワークを介して通信可能なコンピューターを、
前記認可サーバーから発行された認証情報を用いて、前記認可サーバーに対して前記認可情報を要求する要求手段、
前記要求手段による要求の応答として前記コンピューターの移動先のテナントの情報が返された場合、前記認可サーバーに対して、前記コンピューターを前記移動先のテナントへ登録するための登録キーの発行を要求し、当該登録キーを取得する取得手段、
前記登録キーを用いて、前記認可サーバーに対して、当該コンピューターの前記移動先のテナントへの登録要求を行う登録要求手段
として機能させるためのプログラム。
情報処理装置と、サービスを提供するサービス提供サーバーと、ネットワークを介して通信可能な、前記サービスを利用するための認可情報を発行する認可サーバーであって、
情報処理装置と、当該情報処理装置が登録されたテナントとを対応づけて管理する管理手段と、
前記テナントに対応づけて登録されている前記情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持する受け付け手段と、
前記情報処理装置から前記認可情報の取得要求を受け付けた際に、前記情報処理装置の移動先のテナントの情報を保持していた場合、当該移動先のテナントの情報を前記情報処理装置に通知する通知手段と、
前記情報処理装置を前記移動先のテナントへ登録するための登録キーの発行の要求に応じて、当該登録キーを発行する発行手段と、
前記登録キーを用いて前記情報処理装置の登録要求を受け付けた場合に、当該情報処理装置を前記移動先のテナントに対応づけて前記管理手段に登録し、当該情報処理装置を識別するための認証情報を発行する登録する登録手段と、
前記認証情報を用いて前記サービスを利用するための認可情報の要求を受け付けた場合に、当該認証情報の検証結果に応じて、前記認可情報を発行する認可手段と
を有することを特徴とする認可サーバー。
情報処理装置と、サービスを提供するサービス提供サーバーと、ネットワークを介して通信可能な、前記サービスを利用するための認可情報を発行する認可サーバーの制御方法であって、
情報処理装置と、当該情報処理装置が登録されたテナントとを対応づけて管理部にて管理する管理工程と、
前記テナントに対応づけて登録されている前記情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持する受け付け工程と、
前記情報処理装置から前記認可情報の取得要求を受け付けた際に、前記情報処理装置の移動先のテナントの情報を保持していた場合、当該移動先のテナントの情報を前記情報処理装置に通知する通知工程と、
前記情報処理装置を前記移動先のテナントへ登録するための登録キーの発行の要求に応じて、当該登録キーを発行する発行工程と、
前記登録キーを用いて前記情報処理装置の登録要求を受け付けた場合に、当該情報処理装置を前記移動先のテナントに対応づけて前記管理部に登録し、当該情報処理装置を識別するための認証情報を発行する登録する登録工程と、
前記認証情報を用いて前記サービスを利用するための認可情報の要求を受け付けた場合に、当該認証情報の検証結果に応じて、前記認可情報を発行する認可工程と
を有することを特徴とする認可サーバーの制御方法。
情報処理装置と、サービスを提供するサービス提供サーバーと、ネットワークを介して通信可能な、前記サービスを利用するための認可情報を発行する認可サーバーとして機能するコンピューターを、
情報処理装置と、当該情報処理装置が登録されたテナントとを対応づけて管理する管理手段、
前記テナントに対応づけて登録されている前記情報処理装置を異なるテナントに移動させる要求を受け付け、当該異なるテナントの情報を移動先のテナントの情報として保持する受け付け手段、
前記情報処理装置から前記認可情報の取得要求を受け付けた際に、前記情報処理装置の移動先のテナントの情報を保持していた場合、当該移動先のテナントの情報を前記情報処理装置に通知する通知手段、
前記情報処理装置を前記移動先のテナントへ登録するための登録キーの発行の要求に応じて、当該登録キーを発行する発行手段、
前記登録キーを用いて前記情報処理装置の登録要求を受け付けた場合に、当該情報処理装置を前記移動先のテナントに対応づけて前記管理手段に登録し、当該情報処理装置を識別するための認証情報を発行する登録する登録手段、
前記認証情報を用いて前記サービスを利用するための認可情報の要求を受け付けた場合に、当該認証情報の検証結果に応じて、前記認可情報を発行する認可手段
として機能させるためのプログラム。