JP2017120502A - クラウドサービスへのＩｏＴ機器の登録方法 - Google Patents

Abstract

【課題】機器が持つ情報をテナントの情報として管理することができる権限委譲システムを提供する。
【解決手段】端末からの連携アプリケーションの作成要求に応じて、アクセス管理サーバ１０２は、ユーザのテナントを識別するための第１の認証情報を発行し、これを含む連携アプリケーションを作成し、デバイス１０５に提供する。デバイス１０５は、連携アプリケーションが有する第１の認証情報を基に、アクセス管理サーバ１０２へクライアント登録を要求する。アクセス管理サーバ１０２は、クライアント登録の要求に含まれるテナントと紐付けて管理されるクライアントに対応する第２の認証情報を発行する。デバイス１０５は、第２の認証情報を基に、特定の権限が前記クライアントに委譲されたことを示す認可情報の取得を要求する。
【選択図】図６

Description

本発明は、Ｗｅｂサービス上で機器の情報を利用する場合に、機器利用者のＷｅｂサービス上でのグループと機器とを紐付ける方法に関する。

現在、Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ（ＩｏＴ）と呼ばれる、様々な機器をインターネットに接続し、それらの情報を利用する仕組みが広がってきている。このとき、機器が持つデータを利用者が利用するためには、機器とその利用者を紐付ける必要がある。
現在、Ｗｅｂサービス上で機器と利用者とを紐付ける手段として、システム間のアクセス制御をセキュア且つ容易に行う仕組みであるＯＡｕｔｈと呼ばれる技術がある。特許文献１はＯＡｕｔｈを利用し、Ｗｅｂサービスに機器を登録した際に、自動的に権限を付与し、機器と利用者との紐付けを行い、機器の情報を利用者が利用することが出来る技術を公開している。特許文献１が開示する権限委譲システムでは、アプリケーションが保持しているＸ．５０９形式のクライアント証明書を利用する事で、認可サーバに対して動的にクライアントが登録される。そして、自動的に取得されたクライアントＩＤおよびシークレットを利用する事で、ＯＡｕｔｈ ２．０の各種プロトコルを利用することが可能となる。

特開２０１５−５２０２号公報

各機器が持つデータについて、機器の利用者に関係なく機器を提供しているテナントが利用する形態があるが、従来の権限委譲システムでは、クラウドサービスに登録されたクライアントが、どのテナントのクライアントなのかが特定される仕組みがなかった。

本発明は、機器が持つ情報をテナントの情報として管理することができる権限委譲システムを提供することを目的とする。

本発明の一実施形態の権限委譲システムは、情報処理装置と、ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含む。前記情報処理装置は、連携アプリケーションの作成を要求する作成要求手段を有する。前記認可サーバは、前記情報処理装置からの前記連携アプリケーションの作成要求に応じて、ユーザのテナントを識別するための第１の認証情報を発行する第１の発行手段と、前記第１の認証情報を含む連携アプリケーションを作成し、情報処理装置に提供する作成手段と、を有する。前記認可サーバから提供された前記連携アプリケーションを備えた情報処理装置は、認可サーバから提供された前記連携アプリケーションが有する前記第１の認証情報を基に、認可サーバへクライアント登録を要求する登録要求手段を有する。さらに、認可サーバは、前記クライアント登録の登録要求に含まれる前記テナントと紐付けて管理されるクライアントに対応する第２の認証情報を発行する第２の発行手段を有する。さらに、前記連携アプリケーションを備えた情報処理装置は、前記第２の認証情報を基に、特定の権限が前記クライアントに委譲されたことを示す認可情報の取得を要求する認可情報要求手段を有する。

本発明によれば、機器が持つ情報をテナントの情報として管理することができる権限委譲システムを提供することを目的とする。

システム全体の構成を示す図である。 ハードウェアの構成を示す図である。 ソフトウェアの構成を示す図である。 連携用アプリケーション作成のフローチャートである。 連携用アプリケーション作成画面の一例を示す図である。 連携用アプリケーション利用のフローチャートである。 連携用アプリケーション無効化のフローチャートである。 連携用アプリケーション無効化画面の一例を示す図である。 デバイス変更のフローチャートである。 デバイス変更のフローチャートである。 デバイス変更設定画面の一例を示す図である。 連携用アプリケーション再インストールのフローチャートである。

（実施例１）
本実施の形態においては、端末利用者が端末からクラウドサービスを利用する際に、端末は端末利用者が所属するテナントに対してデータのやり取りを行う。そのために、端末をクラウドサービスに登録し、当該端末であることを証明するための情報を取得しておく必要がある。この情報は、ＯＡｕｔｈ ２．０で言うところのクライアントＩＤおよび、クライアントシークレットである。本実施例では、この端末登録の方法として、ＳＳＬ／ＴＬＳのＸ．５０９証明書を用いたクライアント認証を用いて、端末自身が能動的に登録処理を実施し、クライアントＩＤ、クライアントシークレットを取得するフローで説明する。しかしながら、手段を限定するわけではない。例えば、ＩＤ、パスワードや、何かしらのトークンを用いてクライアント認証を受け、動的に登録処理するよう構成する事もできる。

なお、ここで言うクラウドサービスとは、Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどが提供する機能群のことである。Ｗｅｂサイト、Ｗｅｂアプリケーション、Ｗｅｂサービスなどは、サーバコンピュータで実行されるソフトウェアである。
また、本実施の形態においては、クラウドサービス上のユーザグループであるテナント単位で、クライアント情報を発行して利用する。そのため、テナント単位で発行するクライアント情報を、テナント専用クライアントクレデンシャルと呼ぶものとする。また、端末登録のためのクライアント認証情報も、テナント単位で発行する。このテナント単位で発行するクライアント認証情報をテナント専用デフォルトクレデンシャルと呼ぶものとする。

図１は、各種オンラインサービスが存在する権限委譲システムのネットワーク構成を示している。
インターネット１００は、インターネットなどの外部から接続可能なパブリックなネットワークである。イントラネット１０１は、ＬＡＮなどの外部から接続不可能なプライベートなネットワークである。
アクセス管理サーバ１０２は、ユーザの認証情報および認可情報を管理する認可サーバである。

リソースサーバ１０３、印刷サービスや帳票サービスといったリソースサービスを提供しているサービス提供装置である。リソースサーバ１０３は、インターネット１００を介したデバイス１０５あるいは不図示の外部サービスシステムからのリクエストに応じて、リソースサービスを提供する。なおリソースサーバに設置されるリソースサービスは１つでもよく、複数でもよい。また、アクセス管理サーバ１０２とリソースサーバは、同一のサーバ上に構成されてもよいし、それぞれ個別のＬＡＮ上に構成されてもよい。実施例１において各サーバは１台ずつ設置されているが、複数台で構成されていてもよい。
端末１０４およびデバイス１０５は、ＰＣや、スマートフォンやタブレットと呼ばれる携帯端末や、画像形成装置などの情報処理装置である。

図２は、図１に示した各種サービスが配置されているサーバの論理構成である。
ユーザインターフェース２０１は、ディスプレイ、キーボード、マウスなどによる、情報の入出力を行うハードウェアである。これらのハードウェアを備えないコンピュータは、リモートデスクトップなどにより、他のコンピュータから接続・操作することも可能である。
ネットワークインターフェース２０２は、ＬＡＮなどのネットワークに接続して、他のコンピュータやネットワーク機器との通信を行うハードウェアである。

ＣＰＵ２０３は、ＲＯＭ２０４、ＲＡＭ２０５、二次記憶装置２０６などから読み込んだプログラムを実行し、各種サービスを実現する。ＲＯＭ２０４は、組込済みプログラムおよびデータが記録されている記憶装置である。ＲＡＭ２０５は、一時メモリ領域である。二次記憶装置２０６は、ＨＤＤに代表されるような外部記憶装置である。各部は入出力インターフェース２０７を介して接続されている。

図３は本実施の形態に係る、アクセス管理サーバ１０２、リソースサーバ１０３、端末１０４、デバイス１０５それぞれのモジュール構成を示す図である。
アクセス管理サーバ１０２は、リクエスト処理部３００、アクセス制御部３０１、データ管理部３０２からなるアクセス管理サービスを提供する。リクエスト処理部３００は、アクセス管理サーバ１０２がインターネット及びイントラネットを経由して受信したアクセス管理サーバへのリクエストを処理する処理部であり、アクセス制御部３０１から返される応答データを呼び出し元に返す。また、ＳＳＬ／ＴＬＳによる通信が可能に構成されており、不図示の証明書ストアを持つ。また本実施例では、後述するクライアント登録要求を受け付けるエンドポイントにて、要求元に対してＸ．５０９形式の証明書による認証を要求するように構成している。アクセス制御部３０１は、データ管理部３０２から取得するデータに基づき、認証および認可要求を処理する処理部である。また、データ管理部３０２に対して、アカウント追加やアカウント情報変更を行う。データ管理部３０２は、アカウントのデータや、認可情報を管理する。

リソースサーバ１０３は、リクエスト処理部３１０、機能制御部３１１からなるリソースサービスを提供する。リクエスト処理部３１０は、リソースサーバ１０３、１０４がインターネット及びイントラネットを経由して受信したリソースサービスへのリクエストを処理する処理部である。また、リクエスト処理部３１０は、機能制御部３１１から返される処理結果を呼び出し元に返す。機能制御部３１１は、リクエスト処理部３１０が受信したリクエストに応じて必要な処理を行い、応答データを呼び出し元に返す。

端末１０４は、Ｗｅｂブラウザ３２０からなる。Ｗｅｂブラウザ３２０は、ＷＷＷを利用するためのユーザエージェントであり、インターネット１００を経由してアクセス管理サーバ１０２へのアクセスを行う。
デバイス１０５は、Ｗｅｂブラウザ３２０およびアプリケーションモジュール３３１からなる。Ｗｅｂブラウザ３２０は、ＷＷＷを利用するためのユーザエージェントであり、インターネット１００を経由してアクセス管理サーバ１０２やリソースサーバ１０３へのアクセスを行う。アプリケーションモジュール３３１は、デバイス１０５にて動作するアプリケーションプログラムであり、アクセス管理サーバ１０２および、リソースサーバ１０３を利用する。また、アプリケーションモジュール３３１は、自身を証明するためのＸ．５０９形式の証明書および、その秘密鍵を所有している。なおデバイス１０５は、不図示の認証モジュールを備えていても良い。認証モジュールを備えている場合、デバイス１０５は認証モジュールを利用してデバイス利用者を認証する事ができる。

図４を用いて、端末利用者がアクセス管理サーバ１０２において、端末利用者が所属するテナント専用の連携用アプリケーションを作成する作成処理のフローを説明する。
ステップＳ４０１において、端末１０４上のＷｅｂブラウザ３２０を用いて、アクセス管理サーバ１０２の連携用アプリケーション作成画面へのアクセス要求を行う。
Ｓ４０２において、アクセス管理サーバ１０２は、認証処理を行う。認証処理では、まず、アクセス管理サーバ１０２が端末１０４に認証情報を要求する。認証情報の要求を受けた端末１０４はユーザ認証情報として、例えば、ユーザＩＤとパスワードをアクセス管理サーバ１０２に送信する。アクセス管理サーバ１０２は、端末１０４から受信したユーザＩＤとパスワードの組み合せがアカウントテーブルに登録されている情報の組と一致する場合に認証する。表１に、アクセス管理サーバ１０２が、アカウントテーブルとしてデータ管理部３０２で管理しているアカウント情報の例を示す。

なおユーザを認証する手段として他の手段、例えば、Ｘ．５０９の証明書や、パスワードを複数回入力する多段階認証等、別の手段を構成する事も可能であり、本手段に限定するものではない。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」で認証したものとする。
ステップＳ４０３において、アクセス管理サーバ１０２は、アカウントテーブルとロールテーブルから、認証したユーザの権限を確認し、サービステーブルから、認証したユーザが連携アプリケーション作成権限を持つか確認する。表２に、ロールテーブルの例を示す。また、表３に、サービステーブルの例を示す。表２及び表３は、アクセス管理サーバ１０２がデータ管理部３０２で管理している。

本実施例のロールテーブルには、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」に対してロールＩＤ「ロールＡ」が設定されている。そしてサービステーブルから、ロールＩＤ「ロールＡ」には「サービスＡ」の「管理者」としての権限があり、連携用のアプリケーション作成権限を持つと判断される。なお、ステップＳ４０３では、ユーザが連携アプリケーション作成権限を持つかを、ユーザに設定されたロールによって判定したが、ユーザのその他の属性情報や、ユーザが所属するグループの権限などで判断してもよい。
ユーザが連携アプリケーション作成権限を持たない場合はステップＳ４０４に進み、権限なしエラーとして処理を終了する。連携アプリケーション作成権限を持つ場合はステップＳ４０５に進み、処理を継続する。

ステップＳ４０５において、アクセス管理サーバ１０２は、図５に示される連携用アプリケーション作成画面５００を提供する。
図５は本実施形態において、連携用アプリケーション作成画面を示した図である。連携用アプリケーション作成画面５００は、作成ボタン５０１、キャンセルボタン５０２から構成される。作成ボタン５０１が押下された場合は、Ｓ４０６に進む。キャンセルボタン５０２が押下された場合は、処理を終了する。

ステップＳ４０６において、アクセス管理サーバ１０２は、テナント専用デフォルトクレデンシャルとしてＸ．５０９形式のクライアント証明書およびその秘密鍵を生成し、デフォルトクレデンシャルテーブルに情報を格納する。表４に、アクセス管理サーバ１０２がデータ管理部３０２で管理しているテナント専用デフォルトクレデンシャル情報の例を示す。

本実施例では、テナントを識別するためのテナントＩＤ「１００１ＡＡ」に対し、テナント専用デフォルトクレデンシャル「１００１ＡＡ．ｐ１２」を作成したものとする。作成時は、テナント専用デフォルトクレデンシャルは無効になっておらず有効であるため、状態欄は有効となっている。なお、Ｘ．５０９形式の証明書については、ファイルの参照先として格納する例を示しているが、バイナリデータとして直接データを格納しても良い。

ステップＳ４０７において、アクセス管理サーバ１０２は、ステップＳ４０６で作成したテナント専用デフォルトクレデンシャルと、対象のテナント情報を含む連携用アプリケーションを作成する。表５に、アクセス管理サーバ１０２がデータ管理部３０２で管理している連携用アプリケーション情報の例を示す。

本実施例では、テナント専用デフォルトクレデンシャル「１００１ＡＡ．ｐ１２」と、テナント情報「１００１ＡＡ」を含み、アプリケーションＩＤが「ＡＰ０００１」である連携用アプリケーションを作成する。

ステップＳ４０８において、アクセス管理サーバ１０２はステップＳ４０７で作成した連携用アプリケーションを提供可能状態とする。本実施例では、連携用アプリケーションが提供可能状態となると、連携用アプリケーション作成画面５００にアプリケーション取得用リンクを提供し、端末１０４から連携用アプリケーションを取得できるようにする。例えば、テナント作成ボタン押下時に、アクセス管理サーバ１０２から提供された連携用アプリケーション取得用リンクへアクセスし、連携用アプリケーションを取得する。なお、不図示の連携用アプリケーション取得用ボタンや、連携用アプリケーション取得用リンクを利用してもよい。なお本実施例では、画面から連携用アプリケーションを取得出来るようにしたが、これに限られるものではなく、不図示のアプリケーション配布サービスなどの外部サービスに連携用アプリケーションを登録してもよい。

図６を用いて、デバイス１０５が連携用アプリケーションを用いて、リソースサーバを利用する際のフローを説明する。デバイス１０５には、図４で説明したフローで作成された連携用アプリケーションがアプリケーションモジュール３３１としてインストールされている。
ステップＳ６０１において、デバイス１０５上のアプリケーションモジュール３３１を用いて、アクセス管理サーバ１０２にテナント専用クライアントクレデンシャルの登録要求を行う。この登録要求には、登録先のテナントＩＤとして連携アプリケーションに登録されているテナントＩＤと、デバイス１０５のデバイスシリアルＩＤを含む。本実施例では、アプリケーションモジュール３３１が、アクセス管理サーバ１０２に対し、登録先テナントＩＤ「１００１ＡＡ」、デバイスシリアルＩＤ「Ｓ０００１」を送り、テナント専用クライアントクレデンシャル登録要求を行う。

Ｓ６０２において、アクセス管理サーバ１０２は、テナント専用デフォルトクレデンシャルを用いた認証処理を行う。まず、登録要求を受けたアクセス管理サーバ１０２は、ＳＳＬ／ＴＬＳ通信のネゴシエーションを開始し、アプリケーションモジュール３３１に対してクライアント認証を要求する。要求を受けたアプリケーションモジュール３３１は、クライアント認証情報として、証明書を含むテナント専用デフォルトクレデンシャルの情報をアクセス管理サーバ１０２に送信する。アクセス管理サーバ１０２は、不図示の証明書ストアにて設定されている証明書を用いて、取得したクライアント認証情報を検証し、アプリケーションモジュール３３１をテナント専用クライアント登録要求元として認証する。

ステップＳ６０３において、アクセス管理サーバ１０２は、ステップＳ６０２で認証したテナント専用デフォルトクレデンシャルが、作成要求があったテナントに登録されているかを、デフォルトクレデンシャルテーブルを検証し確認する。本実施例では、表４のデフォルトクレデンシャルテーブルにて、テナント「１００１ＡＡ」に「１００１ＡＡ．ｐ１２」が登録されている事から、テナント専用デフォルトクレデンシャルは登録ありと判断される。
対象のテナントに認証したテナント専用デフォルトクレデンシャルが登録されていなかった場合は、ステップＳ６０４に進み、作成エラーとして処理を終了する。対象のテナントにテナント専用デフォルトクレデンシャルが登録されていた場合は、ステップＳ６０５に進み、処理を継続する。

ステップＳ６０５において、アクセス管理サーバ１０２はテナント専用クライアントクレデンシャルの作成を行う。アクセス管理サーバ１０２は、テナント専用クライアントクレデンシャルのクライアントＩＤ、及び、クライアントを認証するための秘匿情報であるクライアントシークレットを発行する。そして、クライアント登録要求で取得した情報と合わせてデータをテナント専用クライアントクレデンシャルテーブルに格納する。表６に、アクセス管理サーバ１０２が管理している、テナント専用クライアントクレデンシャル情報の例を示す。なお、表６においてはテナント専用デフォルトクレデンシャル情報を合わせて保存した例を示したが、実施例１においては、テナント専用クライアン発行時に、テナント専用デフォルトクレデンシャル情報を合わせて保存しなくてもよい。

本実施例では、クライアントＩＤ「ＩＤ０００１」のテナント専用クライアントクレデンシャルを発行したものとする。その後、テナント専用クライアントクレデンシャル作成要求元に、作成したテナント専用クライアントのクライアントＩＤおよびクライアントシークレットを返す。

以降、ステップＳ６０６からステップＳ６１３を用いて、デバイス１０５上のアプリケーションモジュール３３１が、リソースサーバ１０３を利用するためのフローを説明する。本実施例では、ＯＡｕｔｈ ２．０で言うところのＣｌｉｅｎｔ Ｃｒｅｄｅｎｔｉａｌｓ Ｇｒａｎｔを用いて、認可トークンを発行するフローとして説明する。
ステップＳ６０６において、デバイス１０５は受け取ったテナント専用クライアントクレデンシャルクライアントＩＤおよびシークレットを、アプリケーションモジュール３３１にテナント専用クライアントクレデンシャルとして保存する。本実施例では、クライアントＩＤ「ＩＤ０００１」、クライアントシークレット「＊＊＊＊＊」をテナント専用クライアントクレデンシャルとして保存する。

ステップＳ６０７において、デバイス１０５上のアプリケーションモジュール３３１を用いて、アクセス管理サーバ１０２にクライアント認証情報を送り、特定の権限が前記クライアントに委譲されたことを示す認可トークンの取得要求（認可情報要求）を行う。本実施例では、クライアント認証情報として、テナント専用クライアントクレデンシャルのクライアントＩＤ「ＩＤ０００１」、クライアントシークレット「＊＊＊＊＊」を送る。

ステップＳ６０８において、アクセス管理サーバ１０２は、取得要求によって受け取ったクライアントＩＤとクライアントシークレットによってクライアントを認証する。その上で認可トークンを発行し、テナント専用クライアントテーブルの情報と合わせて認可トークンテーブルに格納する。その後、認可トークン発行要求元に、発行した認可トークンを応答する。表７に、アクセス管理サーバ１０２がデータ管理部３０２で管理している認可トークン情報の例を示す。

本実施例では、トークンＩＤ「ＡＴ０００１」を発行したものとし、テナント専用クライアントテーブルから取得したクライアントＩＤ「ＩＤ０００１」、テナントＩＤ「１００１ＡＡ」、デバイスシリアル「Ｓ０００１」を合わせて保存したものとする。

ステップＳ６０９において、デバイス１０５上のアプリケーションモジュール３３１は発行された認可トークンを用いて、リソースサーバ１０３にリソース利用要求を行う。
ステップＳ６１０において、リソースサーバ１０３はアクセス管理サーバ１０２に対して、受け取った認可トークンの検証要求を行う。本実施例では、認可トークンとして「ＡＴ０００１」を利用する。

ステップＳ６１１において、アクセス管理サーバ１０２は、検証要求された認可トークンのトークンＩＤを検証し、検証結果としてトークンに紐付く情報を応答する。より具体的には、認可トークンテーブルに登録されているか、かつ有効期限内かを検証し、特定された認可トークンに紐付く情報を認可トークン情報として利用する。本実施例では、トークンＩＤ「ＡＴ０００１」に紐付くクライアントＩＤ「ＩＤ０００１」、テナントＩＤ「１００１ＡＡ」、デバイスシリアルＩＤ「Ｓ０００１」が認可トークン情報として利用される。

ステップＳ６１２において、リソースサーバ１０３は、認可トークン情報を元にリソースの提供を行う。リソースサーバ１０３は、認可トークン情報に含まれるテナントＩＤおよびデバイスシリアルＩＤを元に、リソース利用要求をしてきたデバイスとそのデバイスの所属テナントを特定する。リソースサーバ１０３は、そのデバイスのものとして処理を行い、処理内容などのデータを対象のテナントの持ち物として管理する。本実施例では、テナント「１００１ＡＡ」のデバイスシリアルＩＤ「Ｓ０００１」が利用しているものとして処理を行う。
ステップＳ６１３において、デバイス１０５上のアプリケーションモジュール３３１はリソースサーバ１０３のリソースを利用する。

実施例１により、連携アプリケーションを介してサービスを利用するので、デバイス１０５を利用している端末利用者が所属するテナントを特定できる。これにより、端末利用者の情報をテナントの情報として管理でき、より詳細な情報を利用する事ができる。また、連携用アプリケーションをデバイスからアンインストールすることで、これまでアクセスしていたテナントにアクセス出来なくなる。そのため、端末利用者が別テナントのユーザになった場合でも、以前の端末利用者が所属していたテナントの情報として処理されることがなくなり、情報漏洩などのリスクがなくなる。

（実施例２）
次に、作成済みの連携用アプリケーションを無効化する場合の第２の形態について説明する。連携用アプリケーションやテナント専用クライアントクレデンシャルが流出した場合や、利用している暗号技術の危殆化などで、セキュリティの観点から作成済みの連携用アプリケーションを無効化したい場合がある。本形態では、作成済みの連携用アプリケーションを一斉に無効化する方法について説明する。

図７を用いて、端末利用者がアクセス管理サーバ１０２において、端末利用者が作成済みの連携用アプリケーションを無効化する無効化処理のフローを説明する。
ステップＳ７０１において、端末１０４上のＷｅｂブラウザ３２０を用いて、アクセス管理サーバ１０２の連携用アプリケーション無効化画面に対してアクセスを行う。
アクセス管理サーバ１０２は、前述のステップＳ４０２と同じ認証処理を行う。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」で認証したものとする。

ステップＳ７０２において、アクセス管理サーバ１０２は、アカウントテーブル（表１）とロールテーブル（表２）から認証したユーザの権限を確認し、サービステーブル（表３）から、認証したユーザが連携用のアプリケーション無効化権限を持つか確認する。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」に対してロールＩＤ「ロールＡ」が設定されている。そしてサービステーブルから、ロールＩＤ「ロールＡ」には「サービスＡ」の「管理者」としての権限があり、連携用のアプリケーション無効化権限を持つと判断される。なお、ステップＳ４０２では、ユーザが連携用のアプリケーション無効化権限を持つかを、ユーザに設定されたロールによって判定したが、ユーザのその他の属性情報や、ユーザが所属するグループの権限などで判断してもよい。
ユーザが連携用のアプリケーション無効化権限を持たない場合はステップＳ７０３に進み、権限なしエラーとして処理を終了する。アプリケーション無効化権限を持つ場合はステップＳ７０４に進み、処理を継続する。

Ｓ７０４において、アクセス管理サーバ１０２は、連携用アプリケーション無効化画面８００を提供する。
図８は本実施形態において、連携用アプリケーション無効化画面を示した図である。連携用アプリケーション無効化画面８００は、無効化要求ボタン８０１、無効化キャンセルボタン８０２から構成される。また本画面は、複数の連携用アプリケーションが作成されていた場合などに備え、不図示のテナント専用アプリケーション一覧を表示し、無効化対象を選択できるように構成してもよい。無効化要求ボタン８０１が押下された場合は、Ｓ７０５に進む。一方、無効化キャンセルボタン８０２は処理を終了する。

ステップＳ７０５において、アクセス管理サーバ１０２は、アプリケーションの無効化実行を行う。
ステップＳ７０６において、アクセス管理サーバ１０２は、連携用アプリケーションテーブル（表５）を参照し、無効化実行されたアプリケーションに紐付いているテナント専用デフォルトクレデンシャルの無効化を行う。表８に、テナント専用デフォルトクレデンシャルの無効化を行った場合の、アクセス管理サーバ１０２がデータ管理部３０２で管理しているテナント専用デフォルトクレデンシャル情報の例を示す。

本実施例では、アプリケーションＩＤ「ＡＰ０００１」を無効化したものとし、該アプリケーションに紐付くテナント専用デフォルトクレデンシャル「１００１ＡＡ．ｐ１２」が無効化される。表４では「有効」だったテナント専用デフォルトクレデンシャルの状態欄が、無効化後の表８では「無効」に変更されている。

ステップＳ７０７において、アクセス管理サーバ１０２は、無効化されたテナント専用デフォルトクレデンシャルを利用しているテナント専用クライアントクレデンシャルを無効化する。実施例２においては、テナント専用クライアント発行時に、テナント専用デフォルトクレデンシャル情報を合わせて保存する必要がある。表９に、テナント専用クライアントクレデンシャルテーブル情報の無効化を行った場合のテナント専用クライアントクレデンシャルテーブル情報の例を示す。

本実施例では、テナント専用デフォルトクレデンシャル「１００１ＡＡ．ｐ１２」を利用しているテナント専用クライアントクレデンシャルである、クライアントＩＤ「ＩＤ０００１」が無効化される。

実施例２の方法により、テナントの全ての連携用アプリケーションからのサービス利用を停止できる。発行済みのテナント専用デフォルトクレデンシャルを無効化する事で、連携用アプリケーションの新規利用が出来なくなる。さらにそのテナント専用デフォルトクレデンシャルで登録されたテナント専用クライアントクレデンシャルを無効化する事で、既に利用されているアプリケーションからの認可トークン発行が行えなくなる。これにより、セキュリティが向上する。なお本実施例では、テナント専用クライアントクレデンシャルの無効化のみ行ったが、合わせて発行済みの認可トークンの無効化も行っても良い。

（実施例３）
次に、端末利用者が利用しているデバイスを更新するための形態について説明する。端末利用者が利用しているデバイスを物理的に更新する場合があるが、デバイスを変えて連携用アプリケーションを利用すると、新たなテナント専用クライアントクレデンシャルが発行されるため、これまでの利用データが引き継げないという問題がある。本形態では、デバイスを変更した場合に、以前のデータを引き継ぐ方法を説明する。

図９及び図１０を用いて、デバイスを変更する際のフローを説明する。なお図９は、デバイス変更前の設定フロー、図１０は、デバイス変更フローを示す図である。
ステップＳ９０１において、端末１０４上のＷｅｂブラウザ３２０を用いて、アクセス管理サーバ１０２のデバイス変更設定画面に対してアクセスを行う。アクセス管理サーバ１０２は、前述のステップＳ４０２と同じ認証処理を行う。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」で認証したものとする。

ステップＳ９０２において、アクセス管理サーバ１０２は、アカウントテーブル（表１）とロールテーブル（表２）から、認証したユーザの権限を確認し、サービステーブル（表３）から、認証したユーザがデバイス変更権限を持つか確認する。本実施例では、ユーザＩＤ「ａｄｍｉｎ＠１００１ＡＡ」に対してロールＩＤ「ロールＡ」が設定されている。そしてサービステーブルから、ロールＩＤ「ロールＡ」には「サービスＡ」の「管理者」としての権限があり、デバイス変更権限を持つと判断される。なお、ステップＳ４０２では、ユーザがデバイス変更権限を持つかを、ユーザに設定されたロールによって判定したが、ユーザのその他の属性情報や、ユーザが所属するグループの権限などで判断してもよい。ユーザがデバイス変更権限を持たない場合はステップＳ９０３に進み、権限なしエラーとして処理を終了する。デバイス変更権限を持つ場合はステップＳ９０４に進み、処理を継続する。

ステップＳ９０４において、アクセス管理サーバ１０２は、デバイス変更設定画面１１００の提供を行う。
図１１は本実施形態において、デバイス変更設定画面を示した図である。デバイス変更設定画面１１００は、変更前デバイスシリアルＩＤ入力欄１１０１、変更後デバイスシリアルＩＤ入力欄１１０２、設定ボタン１１０３、設定キャンセルボタン１１０４から構成される。設定ボタン１１０３が押下された場合は、Ｓ９０５に進む。一方。設定キャンセルボタン１１０４が押下された場合は、処理を終了する。本実施例では、変更前デバイスシリアルＩＤ入力欄１１０１に「Ｓ０００１」が、変更後デバイスシリアルＩＤ入力欄１１０２に「Ｓ０００２」が入力され、設定ボタン１１０３が押下されたとする。

ステップＳ９０５において、アクセス管理サーバ１０２は、変更前のデバイスシリアルＩＤと変更後のデバイスシリアルＩＤを紐付けて、変更用デバイスシリアルＩＤ管理テーブルに格納する。表１０に、デバイス変更設定を行った場合の、アクセス管理サーバ１０２がデータ管理部３０２で管理している変更用デバイスシリアルＩＤ管理テーブル情報の例を示す。

本実施例では、これまで利用していたデバイスシリアルＩＤ「Ｓ０００１」を、デバイスシリアルＩＤ「Ｓ０００２」に変更するものとする。

図１０は、変更したデバイスでのデバイス変更設定のフローチャートである。図１０のデバイス１０５は、デバイスの物理的な変更後の新しいデバイスであり、連携用アプリケーションがアプリケーションモジュール３３１としてインストールされている。
ステップＳ１００１において、デバイス１０５上のアプリケーションモジュール３３１を用いて、アクセス管理サーバ１０２にテナント専用クライアントクレデンシャルの変更要求を行う。本実施例では、アプリケーションモジュール３３１が、アクセス管理サーバ１０２に対し、登録先テナントＩＤ「１００１ＡＡ」、デバイスシリアルＩＤ「Ｓ０００２」を送り、テナント専用クライアントクレデンシャル変更要求を行う。
アクセス管理サーバ１０２は、前述のステップＳ６０２と同じ認証処理を行う。

ステップＳ１００２において、アクセス管理サーバ１０２は、変更要求されたデバイスシリアルＩＤが、変更用デバイスシリアルＩＤ管理テーブル（表１０）に登録されているか確認する。本実施例では、表１０の変更用デバイスシリアルＩＤ管理テーブルにて、変更後デバイスシリアル「Ｓ０００２」が登録されているため、変更実施可能と判断される。
変更要求されたデバイスシリアルＩＤが登録されていなかった場合は、ステップＳ１００３に進み、変更エラーとして処理を終了する。なおここで、図６で説明したテナント専用クライアントクレデンシャル作成を実施しても良い。一方、変更要求されたデバイスシリアルＩＤが登録されていた場合は、変更実施可能と判断し、ステップＳ１００４に進み、処理を継続する。

ステップＳ９１３において、アクセス管理サーバ１０２は、テナント専用クライアントクレデンシャルの変更を行う。アクセス管理サーバ１０２は、変更用デバイスシリアルＩＤ管理テーブルから、変更前デバイスシリアルＩＤを取得し、そのデバイスシリアルＩＤに対応するテナント専用クライアントクレデンシャルを特定する。その上でアクセス管理サーバ１０２は、対象のクライアントＩＤを引き継ぎ、新たにそのクライアントを認証するためのクライアントシークレットを発行し、データを格納する。したがって、デバイスの変更前と後で、クライアントＩＤは共通であり、シークレットのみが異なる。その後、テナント専用クライアントクレデンシャル変更要求元に、作成したテナント専用クライアントクレデンシャルのクライアントＩＤおよびクライアントシークレットを返す。表１１に、第３の形態でのテナント専用クライアントクレデンシャルテーブル情報の例を示す。

本実施例では、デバイスシリアルＩＤ「Ｓ０００１」に紐付いていたクライアントＩＤ「ＩＤ０００１」を引き継ぎ、新たに作成したクライアントシークレットと合わせて格納する。なおここで、変更前のテナント専用クライアントクレデンシャルはテナント専用クライアントテーブルから削除してもよく、無効状態にしてもよい。

ステップＳ９１４において、デバイス１０５は、受け取ったクライアントＩＤおよびシークレットを、アプリケーションモジュール３３１にテナント専用クライアントクレデンシャルとして保存する。本実施例では、クライアントＩＤ「ＩＤ０００１」及びクライアントシークレット「＊＊＊＊＊＊」をテナント専用クライアントクレデンシャルとして保存する。

実施例３の方法により、デバイスを更新する際に、発行済みのクライアントＩＤを引き継いてテナント専用クライアントクレデンシャルを発行することで、更新前のデバイスシリアルＩＤ「Ｓ０００１」で利用していたデータを引き継いで利用する事が出来る。

（実施例４）
次に、デバイス１０５上の連携用アプリケーションを再インストールする際の形態について説明する。連携用アプリケーションの更新やデバイス１０５の都合で、インストールされている連携用アプリケーションを再インストールする場合がある。ここで、連携用アプリケーションを再インストールして再度クライアントクレデンシャル作成を行うと、新たなテナント専用クライアントクレデンシャルが発行されるため、これまでの利用データが引き継げない。本実施例では、連携用アプリケーションを再インストールした場合に、以前のデータを引き継ぐ方法を説明する。

図１２を用いて、アプリケーション再インストール時のフローを説明する。
ステップＳ１２０１において、デバイス１０５上のアプリケーションモジュール３３１を用いて、アクセス管理サーバ１０２にテナント専用クライアントクレデンシャルの再登録要求を行う。本実施例では、アプリケーションモジュール３３１が、アクセス管理サーバ１０２に対し、登録先テナントＩＤ「１００１ＡＡ」、デバイスシリアルＩＤ「Ｓ０００１」を送り、テナント専用クライアントクレデンシャル再登録要求を行う。
アクセス管理サーバ１０２は、前述のステップＳ６０２と同じ認証処理を行う。

ステップＳ１２０２において、アクセス管理サーバ１０２は、再登録要求されたデバイスシリアルＩＤが、テナント専用クライアントクレデンシャルテーブルに登録されているか登録確認を行う。再登録要求されたデバイスシリアルＩＤがテナント専用クライアントクレデンシャルテーブルに登録されていなかった場合は、ステップＳ１２０３に進み、再登録エラーとして処理を終了する。再登録要求されたデバイスシリアルＩＤがテナント専用クライアントクレデンシャルテーブルに登録されていた場合は、ステップＳ１２０４に進み、処理を継続する。本実施例では、表６のテナント専用クライアントクレデンシャルテーブルにて、デバイスシリアル「Ｓ０００１」が登録されているため、再登録実施可能と判断される。

ステップＳ１２０４において、アクセス管理サーバ１０２は、テナント専用クライアントクレデンシャルを認証するための新しいクライアントシークレットを作成し、テナント専用クライアントの更新を行う。したがって、再インストール後の連携アプリケーションは、再インストール前のクライアントＩＤが共通で、シークレットのみが異なる。その後、テナント専用クライアントクレデンシャル再登録要求元に、テナント専用クライアントクレデンシャルのクライアントＩＤおよび再作成したクライアントシークレットを返す。
ステップＳ１２０５において、デバイス１０５は受け取ったクライアントＩＤおよびシークレットを、アプリケーションモジュール３３１にテナント専用クライアントクレデンシャルとして保存する。

実施例４の方法により、デバイス１０５上の連携用アプリケーションを再インストールした場合に、再インストール前のクライアントＩＤを継続して利用出来るため、以前のデータを引き継いで利用する事が出来る。

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

以上、本発明の好ましい実施形態について説明したが、本発明は、これらの実施形態に限定されず、その要旨の範囲内で種々の変形および変更が可能である。

Claims (13)

1. 情報処理装置と、ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含む権限委譲システムであって、
   前記情報処理装置は、
   連携アプリケーションの作成を要求する作成要求手段を有し、
   前記認可サーバは、
   前記情報処理装置からの前記連携アプリケーションの作成要求に応じて、ユーザのテナントを識別するための第１の認証情報を発行する第１の発行手段と、
   前記第１の認証情報を含む連携アプリケーションを作成し、情報処理装置に提供する作成手段と、を有し、
   前記認可サーバから提供された前記連携アプリケーションを備えた情報処理装置は、
   認可サーバから提供された前記連携アプリケーションが有する前記第１の認証情報を基に、認可サーバへクライアント登録を要求する登録要求手段を有し、
   さらに、認可サーバは、
   前記クライアント登録の登録要求に含まれる前記テナントと紐付けて管理されるクライアントに対応する第２の認証情報を発行する第２の発行手段を有し、
   さらに、前記連携アプリケーションを備えた情報処理装置は、
   前記第２の認証情報を基に、特定の権限が前記クライアントに委譲されたことを示す認可情報の取得を要求する認可情報要求手段を有する
   ことを特徴とする権限委譲システム。
2. 前記連携アプリケーションを備えた情報処理装置は、
   前記認可情報要求手段による前記認可情報の取得要求によって取得された前記認可情報を基に、前記サービス提供装置のサービスを利用する利用手段を有し、
   前記認可サーバは、
   前記認可情報要求手段からの前記認可情報の取得要求に応じて、前記認可情報を提供する提供手段と、
   前記利用手段による前記サービス提供装置のサービスの利用の際に送信される前記認可情報を基に、前記利用手段が前記特定の権限で前記サービス提供装置のサービスを利用することを認可するか否かを検証する認可手段と、を有する
   ことを特徴とする請求項１に記載の権限委譲システム。
3. 前記第１の発行手段は、前記情報処理装置からのユーザ認証情報を基に、前記ユーザがテナントに属するユーザであるか認証し、さらに、前記ユーザが連携アプリケーション作成権限を有するユーザであるか確認して、前記第１の認証情報を生成する
   ことを特徴とする請求項１または請求項２に記載の権限委譲システム。
4. 前記認可サーバは、前記連携アプリケーションを管理する管理手段を有し、
   前記連携アプリケーションは、アプリケーションＩＤと、前記第１の認証情報として前記テナントを示すテナントＩＤと前記テナントＩＤに紐付く証明書を含む
   ことを特徴とする請求項１乃至３のいずれか１項に記載の権限委譲システム。
5. 前記第２の認証情報の発行要求は、前記連携アプリケーションを備えた情報処理装置を示すシリアルＩＤと、前記テナントＩＤとを含み、
   前記第２の認証情報は、前記テナントＩＤと、前記シリアルＩＤと、前記クライアントを示すクライアントＩＤとシークレットとを含む
   ことを特徴とする請求項４に記載の権限委譲システム。
6. 前記認可情報の取得を要求する認可情報要求は、前記クライアントＩＤと前記シークレットを含む
   ことを特徴とする請求項５に記載の権限委譲システム。
7. 前記第２の認証情報は、さらに、前記第１の認証情報に紐付けられ、
   前記連携アプリケーションを備えた情報処理装置は、さらに、
   前記認可サーバに、前記連携アプリケーションの無効化を要求する無効化要求手段を有し、
   前記認可サーバは、さらに、
   前記連携アプリケーションの無効化要求に基づいて、前記第１の認証情報を無効化する第１の無効化手段と、
   前記第１の無効化手段により無効化された前記第１の認証情報に紐付く前記第２の認証情報を無効化する第２の無効化手段と、を有する
   ことを特徴とする請求項１乃至６のいずれか１項に記載の権限委譲システム。
8. 前記情報処理装置は、
   前記認可サーバに、前記クライアントとして第１の情報処理装置が有する前記特定の権限を、前記連携アプリケーションを備えた第２の情報処理装置に引き継ぐ変更要求を行う変更要求手段を有し、
   前記認可サーバは、
   前記変更要求に基づいて、前記第１の情報処理装置を示すシリアルＩＤと、前記第２の情報処理装置を示すシリアルＩＤとを紐付けて保存する保存手段と、
   前記第２の情報処理装置を示すシリアルＩＤが前記保存手段に保存されているか確認する確認手段と、を有し、
   前記第２の情報処理装置を示すシリアルＩＤが前記保存手段に保存されていると確認できた場合、前記第２の発行手段は、前記第２の情報処理装置に、前記第２の認証情報を発行する
   ことを特徴とする請求項１乃至７のいずれか１項に記載の権限委譲システム。
9. 前記第１の情報処理装置に発行される第２の認証情報と、前記第２の情報処理装置に発行される第２の認証情報とでは、クライアントＩＤは共通であり、クライアントシークレットが異なる
   ことを特徴とする請求項８に記載の権限委譲システム。
10. 前記連携アプリケーションを備えた情報処理装置は、
    前記第２の認証情報の再インストールを要求する再インストール手段を有し、
    前記認可サーバは、
    前記連携アプリケーションを備えた情報処理装置から前記第２の認証情報の発行を要求された場合、前記連携アプリケーションを備えた情報処理装置のシリアルＩＤが、前記第２の認証情報に紐付けられているか確認する登録確認手段を有し、
    前記再インストールの要求に含まれるシリアルＩＤが、前記第２の認証情報に紐付けられていると確認された場合、前記第２の発行手段により前記第２の認証情報を再インストールし、
    再インストール前と再インストール後の第２の認証情報では、クライアントＩＤは共通であり、クライアントシークレットが異なる
    ことを特徴とする請求項１乃至９のいずれか１項に記載の権限委譲システム。
11. 情報処理装置をクライアントとして登録し、前記情報処理装置がネットワークを介してサービス提供装置が提供するサービスを利用するための認可処理を行う認可サーバであって、
    前記情報処理装置からの連携アプリケーションの作成要求に応じて、ユーザのテナントを識別するための第１の認証情報を発行するする第１の発行手段と、
    前記第１の認証情報を含む連携アプリケーションを作成し、情報処理装置に提供する作成手段と、
    前記認可サーバから提供された前記連携アプリケーションを備えた情報処理装置からのクライアント登録の登録要求に含まれる前記テナントと紐付けて管理されるクライアントに対応する第２の認証情報を発行する第２の発行手段と、
    前記連携アプリケーションを備えた情報処理装置からの前記第２の認証情報を基にした、特定の権限が前記クライアントに委譲されたことを示す認可情報の取得要求に応じて、前記認可情報を提供する提供手段と、
    前記連携アプリケーションを備えた情報処理装置による前記サービス提供装置のサービスの利用の際に送信される前記認可情報を基に、前記連携アプリケーションを備えた情報処理装置が前記特定の権限で前記サービス提供装置のサービスを利用することを認可するか否かを検証する認可手段と、を有する
    ことを特徴とする認可サーバ。
12. 情報処理装置と、ネットワークを介してサービスを提供するサービス提供装置と、認可サーバとを含む権限委譲システムの制御方法であって、
    前記情報処理装置が、連携アプリケーションの作成を要求する工程と、
    前記認可サーバが、前記情報処理装置からの前記連携アプリケーションの作成要求に応じて、ユーザのテナントを識別するための第１の認証情報を発行するする工程と、
    前記認可サーバが、前記第１の認証情報を含む連携アプリケーションを作成し、情報処理装置に提供する工程と、
    前記認可サーバから提供された前記連携アプリケーションを備えた情報処理装置が、認可サーバから提供された前記連携アプリケーションが有する前記第１の認証情報を基に、認可サーバへクライアント登録を要求する工程と、
    認可サーバが、前記クライアント登録の登録要求に含まれる前記テナントと紐付けて管理されるクライアントに対応する第２の認証情報を発行する工程と、
    前記連携アプリケーションを備えた情報処理装置が、前記第２の認証情報を基に、特定の権限が前記クライアントに委譲されたことを示す認可情報の取得を要求する工程と、
    認可サーバが、前記認可情報の取得要求に応じて、前記認可情報を提供する工程と、
    前記連携アプリケーションを備えた情報処理装置が、取得した前記認可情報を基に、前記サービス提供装置のサービスを利用する工程と、
    前記認可サーバが、前記サービスの利用の際に送信される前記認可情報を基に、前記連携アプリケーションを備えた情報処理装置が、前記特定の権限で前記サービス提供装置のサービスを利用することを認可するか否かを検証する工程と、を有する
    ことを特徴とする権限委譲システムの制御方法。
13. 請求項１１に記載の認可サーバの各手段としてコンピュータを機能させることを特徴とするプログラム。

Images