(57)【要約】      （修正有）【課題】リダイレクトＵＲＬをリソースのアクセス範囲ごとに設定するシステム、方法及びプログラムを提供する。【解決手段】システムは、ブラウザを備えた端末、クライアントアプリケーションを備えたクライアントサーバ、リソースサービスを提供するリソースサーバ及び認可サービスモジュールを備えた認可サーバを有する。連携を開始する要求をブラウザから受信したクライアントアプリケーションは、ブラウザが送信する情報から特定した顧客テナントのリダイレクトＵＲＬをクライアント作成予約と共にリソースサーバに送信するＳ１００３。クライアント作成予約を受信したリソースサーバは、リダイレクトＵＲＬをクライアント作成要求と共に認可サーバに送信し、クライアント作成要求を受信した認可サーバは、作成したクライアント情報とリダイレクトＵＲＬとを関連付けて記憶するＳ１０２５。【選択図】図１０
2018205840.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂブラウザを備えた端末と、前記Ｗｅｂブラウザから利用されるクライアントアプリケーションを備えたクライアントサーバと、前記クライアントアプリケーションからのサービスリクエストに応じてリソースを提供するリソースサーバと、ユーザを認証しかつ認証されたユーザが認可したことに応じて前記リソースサーバにおけるユーザの権限が委譲されたことを示すアクセストークンを発行する認可サーバとから構成されるシステムであって、
前記クライアントアプリケーションは、アクセストークンの取得に必要な認可コードの送信先を示すリダイレクトＵＲＬをテナント毎に作成する作成手段を有し、
連携を開始する要求を前記Ｗｅｂブラウザから受信した前記クライアントアプリケーションは、前記Ｗｅｂブラウザが送信する情報から特定した顧客テナントの前記リダイレクトＵＲＬをクライアント作成予約とともに前記リソースサーバに送信する第１の送信手段を有し、
前記クライアント作成予約を受信した前記リソースサーバは、前記リダイレクトＵＲＬをクライアント作成要求とともに前記認可サーバに送信する第２の送信手段を有し、
前記クライアント作成要求を受信した前記認可サーバは、作成したクライアント情報と前記リダイレクトＵＲＬとを関連付けて記憶する第１の記憶手段を有し、
前記認可サーバは、前記リソースサーバにおける権限を前記クライアントアプリケーションに委譲することを前記ユーザが前記Ｗｅｂブラウザを介して認可したこと応じて前記認可コードを作成した場合、前記Ｗｅｂブラウザが送信する情報から特定した前記顧客テナントの前記リダイレクトＵＲＬに対してリダイレクトするよう前記Ｗｅｂブラウザに要求するリダイレクト要求手段を有し、
前記リダイレクトの指示に従いアクセスする前記Ｗｅｂブラウザから前記認可コードを受信した前記クライアントアプリケーションは、前記認可コードと前記クライアント情報とを基に前記アクセストークンを前記認可サーバから受信し、前記リダイレクトＵＲＬに対応する前記顧客テナントのテナントＩＤと前記アクセストークンとを関連付けて記憶する第２の記憶手段を有することを特徴とするシステム。
【請求項２】
前記Ｗｅｂブラウザからサービスリクエストを受信した前記クライアントアプリケーションは、前記Ｗｅｂブラウザが送信する情報から特定した顧客テナントのテナントＩＤに関連づく前記アクセストークンを前記第２の記憶手段から取得し、前記リソースサーバにリソースを要求し、前記リソースサーバから取得したリソースに処理を施した結果を前記Ｗｅｂブラウザに応答する応答手段をさらに有することを特徴とする請求項１に記載のシステム。
【請求項３】
前記作成手段は、前記リダイレクトＵＲＬの他に前記クライアント情報が作成されたことを通知する通知先を示すリターンＵＲＬもテナント毎に作成し、
前記第１の送信手段は、前記リダイレクトＵＲＬの他に前記リターンＵＲＬも前記クライアント作成予約とともに前記リソースサーバに送信し、
前記第２の送信手段は、前記リダイレクトＵＲＬの他に前記リターンＵＲＬも前記クライアント作成要求とともに前記リソースサーバに送信し、
前記クライアント作成要求を受信した前記認可サーバの前記リダイレクト要求手段は、クライアント情報が作成されたことに応じて前記リターンＵＲＬに対してリダイレクトするよう前記Ｗｅｂブラウザに要求し、
前記クライアントアプリケーションは、前記リターンＵＲＬに前記Ｗｅｂブラウザがアクセスしたことに応じて、前記リソースサーバを介して前記認可サーバから前記クライアント情報を取得することを特徴とする請求項１または２に記載のシステム。
【請求項４】
連携を解除する要求を前記Ｗｅｂブラウザから受信した前記クライアントアプリケーションの第１の送信手段は、クライアント削除予約を前記リソースサーバに送信し、
前記リソースサーバは、前記クライアント削除予約を受信した場合に前記顧客テナントの前記クライアント情報が既に作成されているか否かを確認する確認手段を有し、
前記クライアント情報が作成されていないと前記確認手段により確認された場合は、前記リソースサーバは記憶している前記リダイレクトＵＲＬを削除し、削除された旨を前記クライアントアプリケーションへ送信することを特徴とする請求項１乃至３の何れか１項に記載のシステム。
【請求項５】
前記クライアント情報が作成されていると前記確認手段により確認された場合は、記憶している前記リダイレクトＵＲＬと前記クライアント情報とを削除し、前記リソースサーバは前記クライアント情報の削除予約を前記認可サーバへ送信し、
前記削除予約を受信した前記認可サーバの前記第１の記憶手段は、前記クライアント情報を削除することを特徴とする請求項４に記載のシステム。
【請求項６】
前記削除予約を受信した前記リソースサーバは、前記顧客テナントに対してサービスを開始する同意を得られていない場合、前記ユーザから同意を得てから前記クライアント情報の削除予約を前記認可サーバへ送信することを特徴とする請求項５に記載のシステム。
【請求項７】
Ｗｅｂブラウザを備えた端末と、前記Ｗｅｂブラウザから利用されるクライアントアプリケーションを備えたクライアントサーバと、前記クライアントアプリケーションからのサービスリクエストに応じてリソースを提供するリソースサーバと、ユーザを認証しかつ認証されたユーザが認可したことに応じて前記リソースサーバにおけるユーザの権限が委譲されたことを示すアクセストークンを発行する認可サーバとから構成されるシステムで実行される方法であって、
前記クライアントアプリケーションの作成手段は、アクセストークンの取得に必要な認可コードの送信先を示すリダイレクトＵＲＬをテナント毎に作成し、
連携を開始する要求を前記Ｗｅｂブラウザから受信した前記クライアントアプリケーションの第１の送信手段は、前記Ｗｅｂブラウザが送信する情報から特定した顧客テナントの前記リダイレクトＵＲＬをクライアント作成予約とともに前記リソースサーバに送信し、
前記クライアント作成予約を受信した前記リソースサーバの第２の送信手段は、前記リダイレクトＵＲＬをクライアント作成要求とともに前記認可サーバに送信し、
前記クライアント作成要求を受信した前記認可サーバの第１の記憶手段は、作成したクライアント情報と前記リダイレクトＵＲＬとを関連付けて記憶し、
前記認可サーバのリダイレクト要求手段は、前記リソースサーバにおける権限を前記クライアントアプリケーションに委譲することを前記ユーザが前記Ｗｅｂブラウザを介して認可したこと応じて前記認可コードを作成した場合、前記Ｗｅｂブラウザが送信する情報から特定した前記顧客テナントの前記リダイレクトＵＲＬに対してリダイレクトするよう前記Ｗｅｂブラウザに要求し、
前記リダイレクトの指示に従いアクセスする前記Ｗｅｂブラウザから前記認可コードを受信した前記クライアントアプリケーションの第２の記憶手段は、前記認可コードと前記クライアント情報とを基に前記アクセストークンを前記認可サーバから受信し、前記リダイレクトＵＲＬに対応する前記顧客テナントのテナントＩＤと前記アクセストークンとを関連付けて記憶することを特徴とする方法。
【請求項８】
前記Ｗｅｂブラウザからサービスリクエストを受信した前記クライアントアプリケーションの応答手段は、前記Ｗｅｂブラウザが送信する情報から特定した顧客テナントのテナントＩＤに関連づく前記アクセストークンを取得し、前記リソースサーバにリソースを要求し、前記リソースサーバから取得したリソースに処理を施した結果を前記Ｗｅｂブラウザに応答することを特徴とする請求項７に記載の方法。
【請求項９】
前記作成手段は、前記リダイレクトＵＲＬの他に前記クライアント情報が作成されたことを通知する通知先を示すリターンＵＲＬもテナント毎に作成し、
前記第１の送信手段は、前記リダイレクトＵＲＬの他に前記リターンＵＲＬも前記クライアント作成予約とともに前記リソースサーバに送信し、
前記第２の送信手段は、前記リダイレクトＵＲＬの他に前記リターンＵＲＬも前記クライアント作成要求とともに前記リソースサーバに送信し、
前記クライアント作成要求を受信した前記認可サーバの前記リダイレクト要求手段は、クライアント情報が作成されたことに応じて前記リターンＵＲＬに対してリダイレクトするよう前記Ｗｅｂブラウザに要求し、
前記クライアントアプリケーションは、前記リターンＵＲＬに前記Ｗｅｂブラウザがアクセスしたことに応じて、前記リソースサーバを介して前記認可サーバから前記クライアント情報を取得することを特徴とする請求項７または８に記載の方法。
【請求項１０】
連携を解除する要求を前記Ｗｅｂブラウザから受信した前記クライアントアプリケーションの第１の送信手段は、クライアント削除予約を前記リソースサーバに送信し、
前記リソースサーバの確認手段は、前記クライアント削除予約を受信した場合に前記顧客テナントの前記クライアント情報が既に作成されているか否かを確認し、
前記クライアント情報が作成されていないと前記確認手段により確認された場合は、前記リソースサーバは記憶している前記リダイレクトＵＲＬを削除し、削除された旨を前記クライアントアプリケーションへ送信することを特徴とする請求項７乃至９の何れか１項に記載の方法。
【請求項１１】
前記クライアント情報が作成されていると前記確認手段により確認された場合は、記憶している前記リダイレクトＵＲＬと前記クライアント情報とを削除し、前記リソースサーバは前記クライアント情報の削除予約を前記認可サーバへ送信し、
前記削除予約を受信した前記認可サーバの前記第１の記憶手段は、前記クライアント情報を削除することを特徴とする請求項１０に記載の方法。
【請求項１２】
前記削除予約を受信した前記リソースサーバは、前記顧客テナントに対してサービスを開始する同意を得られていない場合、前記ユーザから同意を得てから前記クライアント情報の削除予約を前記認可サーバへ送信することを特徴とする請求項１１に記載の方法。
【請求項１３】
請求項７乃至１２の何れか１項に記載の方法をシステムに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数サービスが連携するシステム、その方法およびそのプログラムに関する。
【背景技術】
【０００２】
マネージドプリントサービス（ＭＰＳ）は、顧客の印刷環境を可視化し、分析したうえで最適な環境を企業側に提示し、合意形成を図ったうえで実際の環境構築から運用・サポートまでワンストップで提供するアウトソーシングサービスである。
【０００３】
ＭＰＳの一つに、サービス提供ベンダである販売会社が企業内の印刷環境を可視化して分析するために、顧客の印刷環境にかかわる個人情報を含むデータを収集・集計・閲覧するためのデバイス管理サービスがある。デバイス管理サービスは、販売会社のユーザが顧客のデータを管理・閲覧することにユーザから同意してもらうことでサービスが提供される。
【０００４】
サービス運用のコスト面から近年ではインターネット上でサービス提供する他、複数のサービスが連携することで付加価値のあるサービスを提供するようになってきた。その一方で、複数のサービスが連携することによりいくつかの課題が生じている。たとえば、ユーザが望んだ以上の情報がサービス間で交換されることにより、ユーザデータや個人情報の漏えいリスクがある。一方、サービスの提供者からするとサービス連携の仕組みは容易に実装できるものが好ましい。このような状況において、ＯＡｕｔｈと呼ばれる認可に関する標準プロトコルが策定された。
【０００５】
ＯＡｕｔｈは、各ユーザに対して利用するサービスごとにアクセストークンを発行し、アクセストークンを用いてアクセスさせることで、ユーザの認証情報なしに認可を行ったユーザの権限でのアクセスを実現することができる。そのため、アクセストークンは厳重かつ適正な管理が必要であり、各連携サービスのアクセス範囲を正しく紐づけておくことが重要である。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２０１６−８５６４１号
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ＯＡｕｔｈでは、アクセストークンを発行する際に必要となるものの一つにＯＡｕｔｈクライアントがある。ＯＡｕｔｈクライアントはアクセストークンを取得したいサービスを証明するためのＩＤとシークレットの情報である。ＯＡｕｔｈクライアント発行には、アクセストークンを取得したいサービスが決めたリダイレクトＵＲＬ（アクセストークン取得に必要な認可コードの送信先）が必要となる。また、認可サービスが発行したＯＡｕｔｈクライアントのＩＤおよびシークレットと、リダイレクトＵＲＬの組み合わせでチェックを行うことでセキュリティを担保している。ＯＡｕｔｈクライアントはサービスを証明するための情報であり、連携元となるサービスごとに１つずつ発行されるのが従来技術であった。よって、リダイレクトＵＲＬはＯＡｕｔｈクライアントごとに設定されるため、リダイレクトＵＲＬを１サービスに対して１つしか設定ができない。そのため、ＭＰＳのように顧客単位でサービスを提供するような形態の場合、リソースのアクセス範囲である顧客単位でリダイレクトＵＲＬを設定するようなことはできず、正しい顧客からのサービスリクエストであることを担保できない虞がある。
【０００８】
本発明は、上述した課題を解決するため、リダイレクトＵＲＬをリソースのアクセス範囲ごとに設定する仕組みを提供し、セキュリティを向上させることを目的とする。
【課題を解決するための手段】
【０００９】
本願発明のシステムは、Ｗｅｂブラウザを備えた端末と、前記Ｗｅｂブラウザから利用されるクライアントアプリケーションを備えたクライアントサーバと、前記クライアントアプリケーションからのサービスリクエストに応じてリソースを提供するリソースサーバと、ユーザを認証しかつ認証されたユーザが認可したことに応じて前記リソースサーバにおけるユーザの権限が委譲されたことを示すアクセストークンを発行する認可サーバとから構成されるシステムであって、前記クライアントアプリケーションは、アクセストークンの取得に必要な認可コードの送信先を示すリダイレクトＵＲＬをテナント毎に作成する作成手段を有し、連携を開始する要求を前記Ｗｅｂブラウザから受信した前記クライアントアプリケーションは、前記Ｗｅｂブラウザが送信する情報から特定した顧客テナントの前記リダイレクトＵＲＬをクライアント作成予約とともに前記リソースサーバに送信する第１の送信手段を有し、前記クライアント作成予約を受信した前記リソースサーバは、前記リダイレクトＵＲＬをクライアント作成要求とともに前記認可サーバに送信する第２の送信手段を有し、前記クライアント作成要求を受信した前記認可サーバは、作成したクライアント情報と前記リダイレクトＵＲＬとを関連付けて記憶する第１の記憶手段を有し、前記認可サーバは、前記リソースサーバにおける権限を前記クライアントアプリケーションに委譲することを前記ユーザが前記Ｗｅｂブラウザを介して認可したこと応じて前記認可コードを作成した場合、前記Ｗｅｂブラウザが送信する情報から特定した前記顧客テナントの前記リダイレクトＵＲＬに対してリダイレクトするよう前記Ｗｅｂブラウザに要求するリダイレクト要求手段を有し、前記リダイレクトの指示に従いアクセスする前記Ｗｅｂブラウザから前記認可コードを受信した前記クライアントアプリケーションは、前記認可コードと前記クライアント情報とを基に前記アクセストークンを前記認可サーバから受信し、前記リダイレクトＵＲＬに対応する前記顧客テナントのテナントＩＤと前記アクセストークンとを関連付けて記憶する第２の記憶手段を有することを特徴とする。
【発明の効果】
【００１０】
リダイレクトＵＲＬをリソースのアクセス範囲ごとに設定する仕組みを提供することで、セキュリティを向上させることが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本願発明におけるシステム全体構成の一例を示す図
【図２】本願発明におけるクライアントサーバ１０６およびリソースサーバ１０２、認可サーバ１０４のＨ／Ｗ構成を示す図
【図３】本願発明におけるクライアントアプリケーション１０７のソフトウェア構成を示す図
【図４】本願発明におけるリソースサービス１０３のソフトウェア構成を示す図
【図５】本願発明における認可サービスモジュール１０５のソフトウェア構成を示す図
【図６】本願発明における管理端末１０１のＨ／Ｗ構成を示す図
【図７】本願発明における管理端末１０１のソフトウェア構成を示す図
【図８】本願発明におけるクライアントアプリケーション１０７の連携設定処理の動作を示すフロー
【図９】本願発明におけるクライアントアプリケーション１０７の連携設定画面の一例を示す図
【図１０】本願発明におけるクライアント作成のシーケンスの一例を示す図
【図１１】本願発明におけるリソースサービス１０２のログイン画面の一例を示す図
【図１２】本願発明におけるトークン取得のシーケンス
【図１３】本願発明における認可サービスモジュール１０５の認可確認画面の一例を示す図
【図１４】本願発明におけるクライアントアプリケーション１０７のトークン取得の動作を示すフロー
【図１５】本願発明におけるＡＰＩ呼び出しシーケンスの一例を示す図
【図１６】本願発明におけるクライアント削除シーケンスの一例を示す図
【発明を実施するための形態】
【００１２】
以下、本発明を実施するための最良の形態について図面を用いて説明する。
【実施例１】
【００１３】
本実施例では、顧客の周辺機器を管理し、周辺機器のカウンタやジョブやアラート情報などを収集し集計し、レポート作成やダッシュボード表示を行うデバイス管理サービスがインターネット上のサーバに設置されていることを前提とする。以降、デバイス管理サービスのように、インターネット上で機能を提供しているサービスを「リソースサービス」と呼ぶ。
【００１４】
また、複数のサービスの機能やコンテンツを一つのポータルに集約し、顧客向けに機能を提供する統合システムがリソースサービスを利用することを前提として説明する。以降、統合システムのように、リソースサービスを利用するアプリケーションを「クライアントアプリケーション」と呼ぶ。無論、リソースサービスはデバイス管理サービスに限られず、クライアントアプリケーションは統合システムに限定されるものではない。
【００１５】
さらに、本実施形態における権限委譲ではＯＡｕｔｈの仕組みを利用する。ＯＡｕｔｈのような権限委譲プロトコルでは、ユーザから委譲された権限の照明をするための情報としてアクセストークンが利用される。
【００１６】
＜システム構成図の説明＞
図１は、本実施例におけるシステムの全体構成を示すブロック図である。本実施形態のシステムは、管理端末１０１と、リソースサーバ１０２と、認可サーバ１０４と、クライアントサーバ１０６と、を備える。ネットワーク１０８はインターネット等の既知の技術によるネットワークである。クライアントサーバ１０６は、ＯＡｕｔｈにおけるクライアントを実現する。本実施形態では、クライアントサーバ１０６はリソースサービス１０３と連携するクライアントアプリケーション１０７が設置される。クライアントアプリケーション１０７は、統合システムを実現するソフトウェアである。クライアントアプリケーション１０７は、リソースサーバ１０２における顧客のリソースを顧客単位で区別して管理し、リソースにアクセス可能な顧客ユーザのみがリソースへのアクセスを可能とするよう構成される。顧客ユーザはクライアントアプリケーション１０７を用いてリソースサービス１０３を利用する。顧客ユーザは管理端末１０１のＷｅｂブラウザ７０１を介してクライアントサーバ１０６のクライアントアプリケーション１０７にアクセスする。そして、顧客ユーザはリソースサービス１０３が提供するリソースを用いてサービスを利用する。
【００１７】
クライアントサーバ１０６は、リソースサーバ１０２と認可サーバ１０４と異なるＬＡＮに接続されている。リソースサーバ１０２は、ＯＡｕｔｈにおけるリソースサーバ１０２を実現する。本実施形態では、リソースサーバ１０２にはリソースサービス１０３が設置される。リソースサービス１０３はデバイス管理サービスを提供するアプリケーションが設置される。なお、１台のリソースサーバ１０２に設置されるリソースサービス１０３は１つでも複数でもよい。顧客ユーザは、管理端末１０１が備えるＷｅｂブラウザ７０１を用いてリソースサービス１０３に直接アクセスしてリソースサービス１０３が提供するリソースを用いてサービスを利用することができる。
【００１８】
デバイス管理システムは、顧客や販売会社のリソースをテナントと呼ばれる単位（たとえば、顧客テナント、販社テナント）ごとに管理し、テナントにアクセス可能なユーザ（たとえば、顧客テナントの顧客ユーザ、販社テナントの販社ユーザ）を紐づける。これにより、テナントにアクセス可能なユーザのみが、テナントに関連づくリソースへアクセスすることが可能となる。さらに、本実施形態のデバイス管理システムは、顧客ユーザが周辺機器の利用状況を把握するために使用されるだけでなく、販売ユーザが担当顧客の周辺機器の利用状況の把握をするために使用する。そのため、顧客ユーザは、販売ユーザによる顧客リソース（顧客テナントに関連づくリソース）へのアクセス行為に同意することでサービスを開始できることを前提とする。
【００１９】
認可サーバ１０４は、ＯＡｕｔｈに対応し、認可サービスモジュール１０５が設置される。認可サービスモジュール１０５はリソースサービス１０３の認証・認可の機能を提供する。リソースサーバ１０２及び認可サーバ１０４は同一認証ドメインに存在するものとする。
【００２０】
＜クライアントサーバ１０６、リソースサーバ１０２、認可サーバ１０４のＨ／Ｗ構成を示す図＞
図２は、クライアントサーバ１０６、リソースサーバ１０２、認可サーバ１０４のＨ／Ｗ構成の一例を説明するブロック図である。ハードディスク（ＨＤＤ）２０７には、後述するすべての動作主体となる本実施形態にかかわるソフトウェアプログラムが格納される。クライアントサーバ１０６、リソースサーバ１０２、認可サーバ１０４は、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＤＫＣ２０５、ＮＩＣ２０６、ＨＤＤ２０７を備える。
【００２１】
ＣＰＵ２０１は、ＲＯＭ２０２または大規模記憶装置であるハードディスク（ＨＤＤ）２０７に記憶されたソフトウェアを実行することにより各実施例で説明する各処理を実現する。ＣＰＵ２０１は、システムバス２０４に接続される各デバイスを統括的に制御する。ＲＡＭ２０３は、ＣＰＵ２０１の主メモリ、ワークエリア等として機能する。ディスクコントローラ（ＤＫＣ）２０５は、ＨＤＤ２０７を制御する。ネットワークインターフェースカード（ＮＩＣ）２０６は、ネットワークを介してほかのノードと双方向にデータをやり取りする。ＮＩＣ２０６とネットワークの間に図示しないファイアウォールを設置してもよい。
【００２２】
＜クライアントアプリケーション１０７のソフトウェア構成を示す図＞
図３は、クライアントアプリケーション１０７のソフトウェア構成の一例を示すブロック図である。図３のソフトウェア機能は、ＣＰＵ２０１がＲＯＭ２０２またはＨＤＤ２０７に記憶されたソフトウェアを実行することにより実現される。クライアントアプリケーション１０７は、Ｗｅｂサーバ部３０１、顧客ユーザ管理部３０２、システム連携管理部３０３、データベース３０４を備える。
【００２３】
Ｗｅｂサーバ部３０１は、管理端末１０１からＮＩＣ２０６およびネットワークを経由して、ＨＴＴＰまたはＨＴＴＰＳリクエストを受信し、応答を返すことによってサービスを提供する。Ｗｅｂサーバ部３０１は、ＷｅｂＵＩ部３０５を備える。ＷｅｂＵＩ部３０５は、管理端末１０１のＷｅｂブラウザ７０１からＨＴＴＰリクエストを受信する。ＷｅｂＵＩ部３０５はユーザ管理部３０６と連携し、ユーザ管理部３０６がユーザ認証を行い、成功した場合にＷｅｂブラウザ７０１にＨＴＭＬデータを送信する。
【００２４】
顧客ユーザ管理部３０２は、ユーザ管理部３０６、顧客管理部３０７を備える。顧客管理部３０７は、クライアントアプリケーション１０７に登録されている顧客情報を管理する。顧客を一意に特定するＩＤに基づき、顧客に関する情報は顧客管理テーブル３１１で管理される。また、クライアントアプリケーション１０７に登録された顧客と、リソースサービス１０３の顧客の紐付けを管理する。顧客の紐付け情報は、顧客マッピングテーブル３１３で管理される。クライアントアプリケーション１０７に登録する顧客は、顧客テナントを作成可能な権限を持つ販売ユーザが管理端末１０１のＷｅｂブラウザ７０１からＷｅｂＵＩ部３０５にアクセスして作成する。そして、事前に作成済みのリソースサービス１０３の顧客をＷｅｂＵＩ部３０５から紐づける。
【００２５】
ユーザ管理部３０６は、ユーザに関する情報を管理し、顧客管理部３０７で管理される顧客に紐付けて管理する。クライアントアプリケーション１０７のユーザ情報は、顧客テナントを作成しユーザを作成することで作成される。ユーザ作成の権限を持つ販売会社のユーザおよび顧客の管理者ユーザが作成してもよい。ユーザ作成は管理端末１０１のＷｅｂブラウザ７０１からＷｅｂＵＩ部３０５にアクセスして作成することができる。顧客とユーザの紐付け情報は、ユーザ管理テーブル３１２で管理される。
【００２６】
ユーザ管理部３０６は、Ｗｅｂブラウザ７０１からのＨＴＴＰリクエストを受け取ると、ログイン画面のＨＴＭＬを返却する。Ｗｅｂブラウザ７０１はログイン画面を表示し、ユーザ操作によりユーザＩＤ、パスワードなどの認証情報が入力されると、これら認証情報をリクエストに追加し、クライアントアプリケーション１０７に送信する。ユーザ管理部３０６は、認証情報を受信しユーザＩＤ、パスワードの組み合わせが正しければ認証成功とし、リクエストされた画面へリダイレクトするようＷｅｂブラウザ７０１に指示する。リダイレクトされたＷｅｂ  ＵＩ部３０５は、ＷｅｂＵＩ部３０５はリクエストされた画面のＨＴＭＬを生成してＷｅｂブラウザ７０１へ返信する。
【００２７】
システム連携管理部３０３は、クライアント管理部３０８、トークン管理部３０９、ＡＰＩ呼び出し部３１０を備える。クライアント管理部３０８は、リソースサービス１０３と連携するためのトークン取得に使用するＯＡｕｔｈクライアントを管理する。クライアント管理部３０８はＯＡｕｔｈクライアントの作成・取得・削除の処理を行う。ＯＡｕｔｈはリソースサービス１０３の顧客ごとに管理し、クライアント管理テーブル３１４で管理される。
【００２８】
トークン管理部３０９は、リソースサービス１０３と連携する際に使用するトークンを管理する。トークン管理部３０９は、トークン取得の処理を行う。トークンはリソースサービス１０３の顧客ごとに管理され、トークン管理テーブル３１５で管理される。ＡＰＩ呼び出し部３１０は、リソースサービス１０３のリソースにアクセスするＡＰＩを呼び出す。
【００２９】
システム連携管理部３０３は、リソースサービス１０３と連携する際に使用するトークンを意識的に区別して使用する。たとえば、顧客ユーザが管理端末１０１のＷｅｂブラウザ７０１を使ってクライアントアプリケーション１０７にアクセスし、リソースサービス１０３のリソースを使ったサービスを利用する場合は、顧客ユーザ（リソースオーナ）を認証して得たトークンを使用する。つまり、Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅグラント方式で得たアクセストークンを使ってＡＰＩを呼び出す必要がある。また、顧客ユーザを介さず、リソースサービス１０３のリソースにアクセスする場合は、リソースオーナの認証なしに取得したトークンを使用する。つまりＣｌｉｅｎｔ  Ｃｒｅｄｅｎｔｉａｌｓグラント方式で得たアクセストークンを使ってＡＰＩを呼び出す。具体的にはリソースサービス１０３の顧客作成をクライアントアプリケーション１０７からＡＰＩ経由で受け付ける場合などである。システム連携管理部３０３で管理されるＯＡｕｔｈクライアントやトークン情報は認可サービスモジュール１０５で同様の情報が管理されることで認証が正しく行われる。Ａｕｔｈｏｒｉｚａｔｉｏｎ  Ｃｏｄｅグラント方式で使用するＯＡｕｔｈクライアントやトークンは、認可サービスモジュール１０５で顧客のリソースとして管理される。Ｃｌｉｅｎｔ  Ｃｒｅｄｅｎｔｉａｌｓグラント方式で使用するＯＡｕｔｈクライアントやトークンは、販売会社のリソースとして管理される。
【００３０】
データベース３０４は、顧客管理テーブル３１１、ユーザ管理テーブル３１２、顧客マッピングテーブル３１３、クライアント管理テーブル３１４、トークン管理テーブル３１５クレデンシャル管理テーブル３１６を備える。表１〜６で説明する。
【００３１】
【表１】
2018205840.tif 000003
【００３２】
表１では顧客管理テーブル３１１でクライアントアプリケーション１０７に登録された顧客の情報を格納する。顧客ＩＤは、顧客を識別するためのＩＤが格納される。顧客名は、顧客の表示名が格納される。住所は、顧客の住所が格納される。地域は、顧客が所属する地域情報が格納される。その他、顧客に関する情報は顧客管理テーブル３１１にて管理される。本実施例ではクライアントアプリケーション１０７に顧客を登録する権限を持つ販売会社のユーザが管理端末１０１のＷｅｂブラウザ７０１からＷｅｂＵＩ部３０５にアクセスして顧客を登録することで、本テーブルに顧客情報が登録される。
【００３３】
【表２】
2018205840.tif 000004
【００３４】
表２はユーザ管理テーブル３１２でクライアントアプリケーション１０７に登録されたユーザの情報を管理する。ユーザＩＤは、ユーザを識別するためのＩＤが格納される。パスワードはユーザ認証する際に使用するパスワードが格納される。顧客ＩＤは、顧客を一意に識別するための一意のＩＤであり、顧客管理テーブル３１１で管理される顧客ＩＤと関連付けられている。このテーブルにおいて、ユーザがどの顧客に属するかを管理することを示す。種別は、ユーザの権限の種類を表す。たとえば、管理者や一般が格納される。本実施例ではクライアントアプリケーション１０７にユーザを登録する権限を持つ販売会社のユーザもしくは顧客ユーザが、管理端末１０１のＷｅｂブラウザ７０１からＷｅｂＵＩ部３０５にアクセスしてユーザを作成するか、顧客を新規作成することで、本テーブルにユーザ情報が登録される。
【００３５】
【表３】
2018205840.tif 000005
【００３６】
表３は顧客マッピングテーブル３１３でクライアントアプリケーション１０７とリソースサービス１０３の顧客のマッピング情報を管理する。顧客ＩＤは、クライアントアプリケーション１０７に登録された顧客を一意に識別するためのＩＤが格納される。顧客管理テーブル３１１の顧客ＩＤと関連付けられている。
【００３７】
顧客テナントＩＤは、リソースサービス１０３に登録された顧客テナントを一意に識別するためのＩＤが格納される。顧客テナントＩＤは、顧客テナント情報テーブル４０９と後述するテナント管理テーブル５１３の顧客テナントＩＤと同じＩＤが格納される。本実施例ではクライアントアプリケーション１０７の顧客（顧客ＩＤ）とリソースサービス１０３の顧客（顧客テナントＩＤ）を紐づける権限がある販売会社のユーザが管理端末１０１のＷｅｂブラウザ７０１からＷｅｂＵＩ部３０５にアクセスして紐づけることで、本テーブルに紐付け情報が登録される。なお、顧客ＩＤと顧客テナントＩＤは同一の情報であってもよく、その場合は顧客マッピング管理テーブルは不要になる。
【００３８】
【表４】
2018205840.tif 000006
【００３９】
表４はクライアント管理テーブル３１４でリソースサービス１０３とシステム連携する際に必要なトークンを取得するために必要なＯＡｕｔｈクライアントをテナントＩＤに紐付けて管理する。ＯＡｕｔｈクライアントは顧客テナント毎に作成され、顧客テナント毎にクライアント管理テーブルにて管理される。
【００４０】
顧客テナントＩＤは、リソースサービス１０３に登録された顧客を一意に識別するためのＩＤが格納される。顧客テナントＩＤは、顧客マッピングテーブル３１３の顧客テナントＩＤと紐付けられる。クライアントＩＤおよびクライアントシークレットは、ＯＡｕｔｈクライアントを一意に識別するためのＩＤとシークレットである。クライアントシークレットは暗号化して格納される。クライアントＩＤおよびクライアントシークレットは認可サービスモジュール１０５で発行されたＩＤとシークレットが格納される。リダイレクトＵＲＬは、トークン取得に必要な認可コードを返却する送信先、すなわち、エンドポイントが格納される。リダイレクトＵＲＬは、クライアント管理部３０８がクライアント作成予約を行う際に、顧客テナントＩＤをＵＲＬに含めて作成する。
【００４１】
リターンＵＲＬは、クライアント作成フロー完了後に遷移するＵＲＬが格納される。リターンＵＲＬは、クライアント管理部３０８がクライアント作成予約を行う際に、顧客テナントＩＤをＵＲＬに含めて作成する。トークン取得フローおよびクライアント作成フローについて、詳細は後述する。クライアント管理テーブル３１４で管理する情報は、リソースサービス１０３のクライアント管理テーブル４１１および認可サービスモジュール１０５のクライアント管理テーブル５１１と同様の内容が管理される。
【００４２】
【表５】
2018205840.tif 000007
【００４３】
表５はトークン管理テーブル３１５でクライアントアプリケーション１０７がリソースサービス１０３にアクセスする際に使用するトークンを管理する。顧客テナントＩＤは、リソースサービス１０３に登録された顧客を一意に識別するためのＩＤが格納される。顧客テナントＩＤは、顧客マッピングテーブル３１３の顧客テナントＩＤと紐付けられる。アクセストークンは、クライアントアプリケーション１０７がトークン取得フローによって認可サービスモジュール１０５から取得したアクセストークンが格納される。アクセストークン有効時間は、アクセストークンの有効時間が格納される。リフレッシュトークンは、クライアントアプリケーション１０７がトークン取得フローによって認可サービスモジュール１０５から取得したリフレッシュトークンが格納される。リフレッシュトークン有効日時は、リフレッシュトークンの有効日時が格納される。認可コードは、クライアントアプリケーション１０７がトークン取得フローによって認可サービスモジュール１０５から取得した認可コードが格納される。
【００４４】
顧客ユーザは、管理端末１０１のＷｅｂブラウザ７０１を用いてクライアントアプリケーション１０７にアクセスし、リソースサービス１０３のリソースを使ったクライアントアプリケーション１０７のサービスを利用する。クライアントアプリケーション１０７はＷｅｂブラウザ７０１からＣｏｏｋｉｅ情報として送信された認証情報とユーザＩＤを検証する。そして、ユーザ管理テーブル３１２および顧客マッピングテーブル３１３より、ユーザＩＤと紐づく顧客テナントＩＤを取得する。
【００４５】
そして、クライアントアプリケーション１０７は、トークン管理テーブル３１５よりテナントＩＤに紐づくアクセストークンがあるか否かを検証し、存在すればアクセストークンをつかってリソースサービス１０３のリソースを取得し、サービスを提供する。本実施形態では、リソースサービス１０３の顧客ＩＤごとにアクセストークンを管理し、顧客管理テーブル３１１でリソースサービス１０３の顧客テナントＩＤと紐づけられたクライアントアプリケーション１０７の顧客ＩＤのテナントに属するユーザはアクセストークンを共有するようにしているが、顧客ユーザごとにアクセストークンを発行して管理してもよい。
【００４６】
【表６】
2018205840.tif 000008
【００４７】
表６はクレデンシャル管理テーブル３１６でクライアントアプリケーション１０７がリソースサービス１０３にアクセスする際に使用するアクセストークンを管理する。クライアントＩＤとクライアントシークレットはＯＡｕｔｈクライアントを一意に識別するためのＩＤとシークレットである。クライアントシークレットは暗号化して格納される。クライアントＩＤおよびクライアントシークレットは認可サービスモジュール１０５で発行されたＩＤとシークレットを入手し格納する。アクセストークンおよびリフレッシュトークンはクライアントアプリケーション１０７がＯＡｕｔｈクライアントよりＣｌｉｅｎｔ  Ｃｒｅｄｅｎｔｉａｌｓグラント方式で取得したトークンが格納される。アクセストークン有効時間およびリフレッシュトークン有効日時はそれぞれのトークンの有効時間が格納される。認可コードは、クライアントアプリケーション１０７がトークン取得フローによって認可サービスモジュール１０５から取得した認可コードが格納される。クレデンシャル管理テーブル３１６で管理される情報は、顧客ユーザを介さずリソースサービス１０３にアクセスする場合に使用される。
【００４８】
＜リソースサービス１０３のソフトウェア構成を示す図＞
図４は、リソースサービス１０３のソフトウェア構成の一例を示すブロック図である。図４のソフトウェア機能は、ＣＰＵ２０１がＲＯＭ２０２またはＨＤＤ２０７に記憶されたソフトウェアを実行することにより実現される。リソースサービス１０３は、Ｗｅｂサーバ部４０１、テナント管理部４０２、認証部４０３、ＡＰＩ管理部４０４、データベース４１２を備える。Ｗｅｂサーバ部４０１は、Ｗｅｂサーバ部３０１と同様なため説明を省略する。
【００４９】
ＷｅｂＵＩ部４０５は、管理端末１０１のＷｅｂブラウザ７０１からＨＴＴＰリクエストを受信する。ＷｅｂＵＩ部４０５は認証部４０３と連携し、認証部４０３が認可サービスモジュール１０５に認証を依頼し、ユーザ認証が成功した場合にＷｅｂブラウザ７０１にＨＴＭＬデータを送信する。Ｗｅｂサービス部４０６は、ＲＥＳＴなどのＷｅｂサービスリクエストを受信し、ＸＭＬデータなどの応答を返信する。
【００５０】
認証部４０３は、認可サービスモジュール１０５と連携しユーザやシステムの認証を行う。ユーザがＷｅｂブラウザ７０１からリソースサービス１０３にアクセスした場合、認証部４０３はＷｅｂブラウザ７０１からのＨＴＴＰリクエストを受け取るとログイン画面のＨＴＭＬを返却する。Ｗｅｂブラウザ７０１はログイン画面を表示し、ユーザ操作によりユーザＩＤ、パスワードなどの認証情報が入力されると、これら認証情報をリクエストに追加しリソースサービス１０３に送信する。認証部４０３は認証情報を受信し、認可サービスモジュール１０５に認証情報とユーザＩＤおよびパスワードの組み合わせが正しいか問い合わせる。認証部４０３は認可サービスモジュール１０５から認証成功が返却されると、リクエストされた画面へリダイレクトするようにＷｅｂブラウザ７０１に指示する。リダイレクトされたＷｅｂＵＩ部４０５はリクエストされた画面のＨＴＭＬを生成してＷｅｂブラウザ７０１へ返信する。また、Ｗｅｂサービス部４０６がクライアントアプリケーション１０７からリクエストを受信した場合、認証部４０３は認証ヘッダに埋め込まれたアクセストークンの検証を認可サービスモジュール１０５に依頼し、認証成功が返却されるとアクセストークンでアクセスできるリソースの範囲内でのリクエストをクライアントアプリケーション１０７から受け付ける。
【００５１】
テナント管理部４０２は、顧客管理部４０７、クライアント管理部４０８を備える。顧客管理部４０７は、リソースサービス１０３に登録されている顧客テナントを管理する。顧客管理部４０７は、顧客テナントを一意に特定するＩＤで管理し、顧客テナントに関する情報は顧客テナント情報テーブル４０９で管理される。まず、顧客テナントを作成可能な権限を持つ販売会社のユーザが、Ｗｅｂブラウザ７０１から認可サービスモジュール１０５のＷｅｂＵＩ部４０５にアクセスし、顧客テナントを登録する。そして、リソースサービス１０３のＷｅｂＵＩ部４０５にアクセスし、リソースサービス１０３に顧客テナントを登録する。リソースサービス１０３は、顧客テナントの登録操作をした販売会社のユーザを認可サービスモジュール１０５に問い合わせることでテナントＩＤを特定し、販売会社のテナントＩＤと登録した顧客のテナントＩＤの紐付け行う。販売会社のテナントＩＤと顧客のテナントＩＤの紐付けは販社顧客リレーション管理テーブル４１０で管理され、販売会社のリソースとして管理される。
【００５２】
クライアント管理部４０８は、クライアントアプリケーション１０７がリソースサービス１０３とシステム連携する際に使用するＯＡｕｔｈクライアントを管理する。ＯＡｕｔｈクライアントはクライアント管理テーブル４１１で管理され、顧客テナント情報テーブル４０９のテナントＩＤに紐づけて顧客のリソースとしてクライアントアプリケーション１０７ごとに一つ登録される。ＡＰＩ管理部４０４は、リソースサービス１０３が管理するリソースにアクセスするためのＡＰＩを管理する。本実施形態ではＲＥＳＴによるリクエストを受信するが、ＳＯＡＰなどの別のリクエスト形態でもよい。データベース４１２は、顧客テナント情報テーブル４０９、販社顧客リレーション管理テーブル４１０、クライアント管理テーブル４１１を備える。表７〜９で説明する。
【００５３】
【表７】
2018205840.tif 000009
【００５４】
表７は顧客テナント情報テーブル４０９でリソースサービス１０３登録された顧客の情報を格納する。顧客テナントＩＤは、顧客を識別するためのＩＤが格納される。顧客マッピングテーブル３１３のテナントＩＤと同様のデータが格納される。顧客名は、顧客の表示名が格納される。住所は、顧客の住所が格納される。地域は顧客が所属する地域情報が格納される。その他、顧客に関する情報は顧客テナント情報テーブル４０９にて管理される。
【００５５】
【表８】
2018205840.tif 000010
【００５６】
表８は販社顧客リレーション管理テーブル４１０でリソースサービス１０３に登録された販社と顧客のリレーション情報を格納する。販社テナントＩＤは、販社を識別するためのＩＤが格納される。顧客テナントＩＤは、顧客を識別するためのＩＤが格納される。顧客テナント情報テーブル４０９の顧客テナントＩＤと関連付けられる。同意ステータスは、顧客ユーザが、販売会社のユーザが自身のリソースにアクセスすることに同意したかのステータス情報が格納される。なお、本実施例では顧客ユーザがリソースサービス１０３を利用する際には販売会社のユーザが顧客リソースにアクセスすることに同意しなければサービスが開始できない。
【００５７】
【表９】
2018205840.tif 000011
【００５８】
表９はクライアント管理テーブル４１１で、クライアントアプリケーション１０７がリソースサービス１０３とシステム連携するためのトークン取得に使用するＯＡｕｔｈクライアント情報を格納する。顧客テナントＩＤは、顧客を識別するためのＩＤが格納される。顧客テナント情報テーブル４０９の顧客テナントＩＤと関連付けられる。アプリケーションＩＤは、クライアント作成要求元であるクライアントアプリケーション１０７を特定するＩＤが格納される。顧客テナントクライアントＩＤと顧客テナントクライアントシークレットは、ＯＡｕｔｈクライアントを一意に識別するためのＩＤとシークレットである。顧客テナントクライアントシークレットは暗号化して格納される。
【００５９】
リダイレクトＵＲＬは、トークン取得に必要な認可コードを渡すエンドポイントが格納される。リターンＵＲＬは、クライアント作成フロー完了後に遷移するＵＲＬが格納される。リターンＵＲＬはクライアント作成が完了したことを通知するための通知先となる。ステータスは、ＯＡｕｔｈクライアントの作成状況のステータスが格納される。具体的には、作成待ち、作成済み、提供済み、削除待ちなどがあげられる。
【００６０】
リソースサービス１０３は、クライアントアプリケーション１０７からクライアント作成予約リクエストを取得すると、クライアント管理テーブル４１１のステータスを作成待ちにして予約フラグを立てる。そして、クライアントセットアップのエンドポイントにＷｅｂブラウザ７０１をリダイレクトさせ、リソースオーナに認可をもらうことで認可サービスモジュール１０５にＯＡｕｔｈクライアントの作成を依頼する。ＯＡｕｔｈクライアントを作成するとステータスを作成済みにし、クライアントアプリケーション１０７に指定されたリターンＵＲＬにリダイレクトさせる。そして、クライアントアプリケーション１０７からクライアント取得リクエストを取得すると、ステータスを提供済みにしてＯＡｕｔｈクライアントを返却する。
【００６１】
なお、リソースサービス１０３は、ステータスが作成待ちの場合にはクライアント作成予約リクエストは何度でも受け付ける。その場合、後からリクエストされた内容でクライアント作成予約リクエストを受け付ける。また、クライアント作成と同様にクライアント削除のリクエストも受け付ける。ステータスが作成済み、もしくは提供済みの場合にクライアント削除予約リクエストを受け付けた場合は、リソースサービス１０３は顧客ユーザ（リソースオーナ）に許可をもらうことで認可サービスモジュール１０５にＯＡｕｔｈクライアント削除を依頼し、リソースサービス１０３に保存されたＯＡｕｔｈクライアント情報を削除する。ステータスが作成待ちの場合にクライアント削除予約リクエストを受け付けた場合は、顧客ユーザ（リソースオーナ）の許可なしにクライアント管理テーブル４１１からレコードを削除する。なぜなら、この場合は認可サービスモジュール１０５にＯＡｕｔｈクライアントは存在しないため、ＯＡｕｔｈクライアント削除依頼を出す必要がないためである。
【００６２】
＜認可サービスモジュール１０５のソフトウェア構成を示す図＞
図５は、認可サービスモジュール１０５のソフトウェア構成の一例を示すブロック図である。図５のソフトウェア機能は、ＣＰＵ２０１がＲＯＭ２０２またはＨＤＤ２０７に記憶されたソフトウェアを実行することにより実現される。認可サービスモジュール１０５は、Ｗｅｂサーバ部５０１、認証部５０２、トークン管理部５０３、クライアント管理部５０４、ユーザ管理部５０５、テナント管理部５０６、データベース５０７を備える。Ｗｅｂサーバ部５０１は、Ｗｅｂサーバ部４０１と同様のため説明を省略する。
【００６３】
ＷｅｂＵＩ部５０８は、管理端末１０１のＷｅｂブラウザ７０１からＨＴＴＰリクエストを受信する。ＷｅｂＵＩ部５０８は認証部５０２と連携し、認証部５０２が認可サービスモジュール１０５に認証を依頼し、ユーザ認証が成功した場合に、Ｗｅｂブラウザ７０１にＨＴＭＬデータを送信する。Ｗｅｂサービス部５０９は、ＲＥＳＴなどのＷｅｂサービスリクエストを受信し、ＸＭＬデータなどの応答を返信する。認証部５０２は、ユーザやシステムの認証を行う。
【００６４】
顧客ユーザや販社ユーザがＷｅｂブラウザ７０１から認可サービスモジュール１０５にアクセスした場合、認証部５０２はＷｅｂブラウザ７０１からのＨＴＴＰリクエストを受け取るとＷｅｂＵＩ部５０８がログイン画面のＨＴＭＬを返却する。Ｗｅｂブラウザ７０１はログイン画面を表示し、ユーザ操作によりユーザＩＤ、パスワードなどの認証情報が入力されると、認証部５０２はユーザ管理テーブル５１０に登録済みのユーザかどうかを検証する。そして、登録済みであればこれら認証情報をＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報に追加する。そしてＷｅｂＵＩ部５０８にてメニュー画面のＨＴＭＬを生成してＷｅｂブラウザ７０１へ返信する。また、Ｗｅｂサービス部５０９がリソースサービス１０３からトークンの検証をリクエストされた場合、トークン管理テーブル５１２よりトークンの検証を行う。
【００６５】
テナント管理部５０６は、認可サービスモジュール１０５に登録されているテナントを管理する。テナントを一意に特定するＩＤで管理され、テナント管理テーブル５１３で管理される。種別として顧客テナントと販社テナントが存在する。まず、顧客テナントを作成可能な権限を持つ販売会社のユーザが、Ｗｅｂブラウザ７０１からＷｅｂＵＩ部５０８にアクセスし、顧客テナントを作成する。顧客テナントを作成すると、テナント管理テーブル５１３にテナントＩＤが発行され、保存される。
【００６６】
ユーザ管理部５０５は、認可サービスモジュール１０５に登録されているユーザを管理する。ユーザを一意に特定するＩＤでユーザを管理し、ユーザ管理テーブル５１０で管理される。ユーザは、顧客テナントを作成すると、管理者権限をもつ顧客ユーザが作成され、ユーザ管理テーブル５１０に保存される。また、ユーザ作成権限を持つユーザが作成してもよい。
【００６７】
クライアント管理部５０４は、クライアントアプリケーション１０７がリソースサービス１０３とシステム連携する際に使用するＯＡｕｔｈクライアントを管理する。ＯＡｕｔｈクライアントはクライアント管理テーブル５１１で管理され、テナント管理テーブル５１３のテナントＩＤに紐づけて、紐づけられたテナントＩＤのリソースとして登録される。
【００６８】
トークン管理部５０３は、トークンの作成・削除などの管理を行う。トークンはユーザ管理テーブル５１０のユーザＩＤと紐づけて管理されトークン管理テーブル５１２で管理される。データベース５０７は、ユーザ管理テーブル５１０、クライアント管理テーブル５１１、トークン管理テーブル５１２、テナント管理テーブル５１３を備える。表１０〜１３で説明する。
【００６９】
【表１０】
2018205840.tif 000012
【００７０】
表１０はユーザ管理テーブル５１０で認可サービスモジュール１０５のユーザを管理する。ユーザＩＤおよびパスワードは、ユーザを一意に識別するためのＩＤとパスワードが格納される。ユーザ識別は、ユーザが販売会社のユーザかまたは顧客ユーザか、そして管理者かまたは一般者かを表す情報が格納される。認可サービスモジュール１０５は、ユーザＩＤおよびパスワードの組を検証し、その組み合わせが正しければ認証情報を生成することで、各ユーザを認証する機能を有する。
【００７１】
【表１１】
2018205840.tif 000013
【００７２】
表１１はクライアント管理テーブル５１１で、ＯＡｕｔｈクライアントを管理する。クライアントＩＤ及びクライアントシークレットは、ＯＡｕｔｈクライアントを一意に識別するためのＩＤとシークレットである。
【００７３】
リダイレクトＵＲＬは、トークン取得に必要な認可コードを返却するエンドポイントが格納される。クライアント名は、クライアントの表示名が格納される。グラントタイプはＯＡｕｔｈのグラントタイプが格納される。たとえば、クライアントアプリケーション１０７がリソースサービス１０３にクライアント作成要求およびクライアント取得要求を送信する際に使用するトークンは、グラントタイプがＣｌｉｅｎｔ  ＣｒｅｄｅｎｔｉａｌグラントのクライアントＩＤとシークレットを使って取得したアクセストークンを使用する。また、顧客ユーザがクライアントアプリケーション１０７からリソースサービス１０３のリソースにアクセスする際に使用するトークンは、グラントタイプがＡｕｔｈｏｒｉｚａｔｉｏｎ  ＣｏｄｅグラントのクライアントＩＤとシークレットを使って取得したアクセストークンを使用する。
【００７４】
【表１２】
2018205840.tif 000014
【００７５】
表１２はテナント管理テーブル５１３で、トークン情報を管理する。トークンＩＤは、トークンを一意に特定するためのＩＤが格納される。トークン種別は、トークンの種別を表す情報が格納される。具体的には、認証トークン、アクセストークン、認可コードなどが格納される。有効期限は、トークンの有効期限の情報が格納される。リフレッシュトークンＩＤは、リフレッシュトークンを一意に特定するためのＩＤが格納される。リフレッシュ期限は、リフレッシュトークンの有効期限の情報が格納される。クライアントＩＤは、ＯＡｕｔｈクライアントを一意に識別するためのＩＤで、クライアント管理テーブル５１１のクライアントＩＤと紐付けられる。ユーザＩＤは、ユーザを一意に識別するためのＩＤが格納される。ユーザＩＤはユーザ管理テーブル５１０のユーザＩＤと紐付けられる。
【００７６】
＜管理端末１０１のＨ／Ｗ構成を示す図＞
図６は管理端末１０１のＨ／Ｗ構成の一例を示すブロック図である。ＣＰＵ６０１は、ＲＯＭ６０２または大規模記憶装置であるＨＤＤ６０７に記憶されたソフトウェアを実行することにより各実施例で説明する各処理を実現する。ＣＰＵ６０１は、システムバス６０４に接続される各デバイスを総括的に制御する。ＲＡＭ６０３は、ＣＰＵ６０１の主メモリ、ワークエリア等として機能する。入力装置（ＩＮＰＵＴ）６０５は、キーボード、マウス、タッチパネルもしくはボタンなどであり、ユーザ操作の入力手段を提供する。表示モジュール（ＤＩＳＰＬＡＹ）６０６は、液晶ディスプレイ等で構成される表示モジュールである。ネットワークインターフェースカード（ＮＩＣ）６０８は、ネットワーク１０８を介してほかのノードと双方向にデータをやり取りする。
【００７７】
＜管理端末１０１のソフトウェア構成を示す図＞
図７は、管理端末１０１のソフトウェア構成の一例を示すブロック図である。図７のソフトウェア機能は、ＣＰＵ６０１がＲＯＭ６０２またはＨＤＤ６０７に記憶されたソフトウェアを実行することにより実現される。
【００７８】
管理端末１０１は、Ｗｅｂブラウザ７０１と、ＨＴＴＰ通信部７０２を備える。Ｗｅｂブラウザ７０１は、ＨＴＴＰ通信部７０２へＵＲＬを指定し情報取得要求を送信し、ＨＴＭＬデータを取得する。Ｗｅｂブラウザ７０１は、ＨＴＴＰ通信部７０２を使用して取得したＨＴＭＬデータを解釈し、表示モジュール６０６へ画面描画を行う。また、Ｗｅｂブラウザ７０１は表示した画面内のコントロールに対するユーザ操作を入力装置６０５から受け付け、操作内容に応じてＨＴＴＰ通信部７０２へ要求を送信する。
【００７９】
ＨＴＴＰ通信部７０２は、Ｗｅｂブラウザ７０１からの通信要求を受けてＨＴＴＰまたはＨＴＴＰＳプロトコルを用いてＷｅｂサーバと通信し、Ｗｅｂページの要求、Ｗｅｂページデータの受信等を行う。販売会社のユーザや顧客ユーザは、管理端末１０１のＷｅｂブラウザ７０１において、リソースサービス１０３やクライアントアプリケーション１０７のＵＲＬを指定し、Ｗｅｂサーバ部３０１およびＷｅｂサーバ部４０１にアクセスすることで、リソースサービス１０３やクライアントアプリケーション１０７の機能を使用することができる。
【００８０】
＜システム連携開始フロー＞
図８は、本実施形態におけるクライアントアプリケーション１０７とリソースサービス１０３がシステム連携を開始するフローチャートである。なお、フローチャートの各ステップ処理はクライアントサーバ１０６、リソースサーバ１０２、認可サーバ１０４に設けられたＣＰＵがＲＯＭ、ＨＤＤ等の不揮発性記憶手段に記憶された本発明の制御プログラムを読み込み実行することに応じて実現されたものとする。
【００８１】
ステップＳ８０１において、顧客ユーザがリソースサービス１０３のリソースを使ったサービスを利用するために、管理端末１０１のＷｅｂブラウザ７０１からクライアントアプリケーション１０７にアクセスし、リソースサービス１０３との連携開始ボタンを押す。具体的には図９のＯＫボタン９０１を押すことで処理が開始される。
【００８２】
ステップＳ８０２において、システム連携管理部３０３がＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれるユーザの認証情報とユーザＩＤの検証し、ユーザＩＤと紐づくＯＡｕｔｈクライアントが登録済みかどうか検証する。ユーザＩＤと紐づく顧客ＩＤをユーザ管理テーブル３１２から取得し、顧客ＩＤに紐づく顧客テナントＩＤを顧客マッピングテーブル３１３から取得し、顧客テナントＩＤに紐づくＯＡｕｔｈクライアントをクライアント管理テーブル３１４から取得することで検証する。登録済みであればステップＳ８０３に進む。未登録でなければステップＳ８０４に進む。
【００８３】
ステップＳ８０３において、トークン管理部３０９がトークン管理テーブル３１５からテナントＩＤに紐づくアクセストークンがあるか検証する。アクセストークンがあればステップＳ８０５に進む。なければステップＳ８０６に進む。ステップＳ８０５において、ＷｅｂＵＩ部３０５が連携開始ボタンをｄｉｓａｂｌｅにする。具体的には図９の設定メニュー９０２がｄｉｓａｂｌｅされる。ステップＳ８０４において、クライアント管理部３０８がクライアント作成処理を行う。詳細は図１０で説明する。ステップＳ８０５において、トークン管理部３０９がトークン取得処理を行う。詳細は図１２で説明する。
【００８４】
＜クライアント作成シーケンス＞
図１０は、本実施形態におけるクライアント作成のシーケンスである。なお、シーケンスの各ステップ処理は、クライアントサーバ１０６、リソースサーバ１０２、認可サーバ１０４に設けられたＣＰＵがＲＯＭ、ＨＤＤ等の不揮発性記憶手段に記憶された本発明の制御プログラムを読み込み実行することに応じて実現されたものとする。
【００８５】
ステップＳ１００１において、顧客ユーザ（リソースオーナー）がＷｅｂブラウザ７０１からリソースサービス１０３との連携開始のＨＴＴＰリクエストを送信する。具体的には、図９のＯＫボタン９０１が押されることでＨＴＴＰリクエストが送信され処理が開始される。ステップＳ１００２において、システム連携管理部３０３がユーザ管理テーブル３１２および顧客マッピングテーブル３１３からリソースサービス１０３の顧客テナントＩＤを特定し、リソースサービス１０３のテナントに紐づくＯＡｕｔｈクライアントが登録済みかどうかを確認する。登録済みであればステップＳ１００３にて、システム連携管理部３０３がＷｅｂブラウザ７０１にトークン取得ＵＲＬにリダイレクトするようにリダイレクト要求する。トークン取得ＵＲＬは、アクセストークンを取得するためのフローを処理するクライアントアプリケーション１０７のエンドポイントで、ステップＳ１０３３とステップＳ１２０１と同様の処理となる。登録済みでなければステップＳ１００４に進む。
【００８６】
ステップＳ１００４にて、クライアント管理部３０８がリソースサービス１０３にクライアント作成予約リクエストを送信する。クライアント作成予約リクエストには、顧客テナントＩＤ、リダイレクトＵＲＬ、リターンＵＲＬを含む。リダイレクトＵＲＬおよびリターンＵＲＬは、クライアント作成予約リクエストを送信する際に、ＵＲＬに顧客テナントＩＤを含めて作成される。また、認証ヘッダにあらかじめ認可サービスモジュール１０５から払い出したアクセストークンを含めてリクエストする。このアクセストークンは、クレデンシャル管理テーブル３１６で管理されたＣｌｉｅｎｔ  Ｃｒｅｄｅｎｔｉａｌグラントで作成されたクライアントＩＤとシークレットを使って取得したアクセストークンである。クライアントＩＤとシークレットは、クライアントアプリケーション１０７所有の販売会社リソースとして認可サービスモジュール１０５に登録されたものである。
【００８７】
ステップＳ１００５にて、クライアント管理部４０８は、ステップＳ１００４のクライアント作成予約リクエストを受け付けられるか検証する。まず、Ｗｅｂサービス部４０６がステップＳ１００４のリクエストを取得すると、認証部４０３が認証ヘッダに含まれるアクセストークンの検証を認可サービスモジュール１０５に依頼する。認証部４０３は認可サービスモジュール１０５から認証成功が返却されると、クライアント管理部４０８はアクセストークンがアクセス可能な販売テナントＩＤの販社顧客リレーション管理テーブル４１０にアクセスする。そして、ステップＳ１００４のリクエストに含まれる顧客テナントＩＤにアクセス可能か検証する。アクセス可能だった場合は、クライアント管理テーブル４１１に顧客テナントＩＤ、アプリケーションＩＤ、リダイレクトＵＲＬ、リターンＵＲＬとステータスを作成待ちにして登録する。なお、クライアント作成予約リクエストは、顧客テナントＩＤおよびアプリケーションＩＤをキーに、クライアント管理テーブル４１１に未登録の場合もしくはステータスが作成待ちの場合に受け付ける。クライアント管理テーブル４１１のステータスが作成済みもしくは提供済みの場合は、ステップＳ１００４の応答としてステップＳ１００６でクライアントアプリケーション１０７にエラーを返す。
【００８８】
クライアント管理部４０８はクライアント作成予約リクエストを受け付けると、クライアント管理テーブル４１１に顧客テナントＩＤ、リダイレクトＵＲＬ、リターンＵＲＬ、アプリケーションＩＤに格納し、ステータスを作成待ちに更新し、ステップＳ１００７に進む。
【００８９】
ステップＳ１００７において、クライアント管理部４０８は、ステップＳ１００４のクライアント作成予約リクエストの応答としてクライアントセットアップＵＲＬを返却する。クライアントセットアップＵＲＬは、認可サービスモジュール１０５にＯＡｕｔｈクライアント作成処理をするためのエンドポイントである。
【００９０】
ステップＳ１００８において、クライアント管理部３０８はステップＳ１００７で返却されたクライアントセットアップＵＲＬに対して、Ｗｅｂブラウザ７０１にリダイレクトするようにリダイレクト要求する。ここでのリダイレクト要求は、Ｗｅｂブラウザ７０１にＨＴＴＰ／１．１ステータスコード“３０２”を用いて行われる。ステップＳ１００９において、Ｗｅｂブラウザ７０１はステップＳ１００８のリダイレクト要求に従いクライアントセットアップＵＲＬにリダイレクトする。ステップＳ１０１０において、Ｗｅｂブラウザ７０１からクライアントセットアップＵＲＬにリダイレクトすると、認証部４０３はＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報からリソースサービス１０３にログイン済みかどうか認可サービスモジュール１０５に問い合わせ検証する。認可サービスモジュール１０５の認証部５０２は、ログイン済みかどうかを検証し、ログイン済みであればステップＳ１０１４に進む。ログインしていなければステップＳ１０１１に進む。
【００９１】
ステップＳ１０１１において、認証部５０２は認可サービスモジュール１０５のログインページにリダイレクトするようにＷｅｂブラウザ７０１にリダイレクト要求する。具体的には図１１に示すログイン画面のＷｅｂブラウザ７０１に表示させる。ステップＳ１０１２において、顧客ユーザ（リソースオーナ）はＷｅｂブラウザ７０１に表示されたログイン画面に対して、ユーザＩＤおよびパスワードを入力しログインを実行する。なお、ここで指定するユーザＩＤとパスワードは、ＯＡｕｔｈクライアントを作成したい顧客テナントにアクセス可能なユーザＩＤとパスワードである。
【００９２】
ステップＳ１０１３において、認証部５０２はステップＳ１０１１で受け付けたユーザＩＤとパスワードの組み合わせがユーザ管理テーブル５１０に登録されている情報と一致するかを検証し、一致する場合はステップＳ１０１４に進む。そして、認証情報をＷｅｂブラウザ７０１に対してＣｏｏｋｉｅ情報として格納する。一致しない場合はステップＳ１０１５でＷｅｂブラウザ７０１にエラーを返す。ステップＳ１０１５でＷｅｂブラウザ７０１にエラーが返った場合、ステップＳ１００５でクライアント管理テーブル４１１が作成待ちのステータスになっているため、再度ステップＳ１００１の連携開始のＨＴＴＰリクエストを送信するところから処理を始める必要がある。または、クライアントアプリケーション１０７はクライアント削除予約をリソースサービス１０３に送信してクライアント管理テーブル４１１からクライアント作成予約を削除する必要がある。
【００９３】
ステップＳ１０１４において、認証部５０２はステップＳ１０１２で検証したユーザＩＤに紐づく顧客テナントＩＤがサービス開始状態かどうかをリソースサービス１０３に問い合わせる。本実施形態では、リソースサービス１０３であるデバイス管理サービスは、販売会社が顧客リソースにアクセスすることを顧客が同意しなければサービスを開始できない。そのため、サービスが開始状態かどうかは販社顧客リレーション管理テーブル４１０の同意ステータスから判断する。ステップＳ１０１６において、テナント管理部４０２はステップＳ１０１３の応答として指定された顧客ＩＤに紐づく同意ステータスを返却する。ステップＳ１０１７において、認証部５０２はステップＳ１０１４で返却された同意ステータスが同意済みかどうかを検証する。同意済みであればステップＳ１０２４に進む。同意済みでなければステップＳ１０１８に進む。
【００９４】
ステップＳ１０１８において、ＷｅｂＵＩ部は同意をもらうためのＨＴＭＬを作成し、Ｗｅｂブラウザ７０１にリダイレクトするようにリダイレクト要求する。ステップＳ１０１９において、Ｗｅｂブラウザ７０１はステップＳ１０１６のリダイレクト要求に従い同意画面にリダイレクトする。具体的には図１２の同意画面にリダイレクトし、販売会社のユーザがリソースにアクセスしてサービスを提供することを同意する。ステップＳ１０２０において、テナント管理部４０２はステップＳ１０１７で同意されたかどうかを検証し、同意されなかった場合はステップＳ１０２１に進む。同意された場合は販社顧客リレーション管理テーブル４１０の同意ステータスを同意済みに更新し、ステップＳ１０２２に進む。
【００９５】
ステップＳ１０２２において、テナント管理部４０２はクライアントセットアップＵＲＬにリダイレクトするようにＷｅｂブラウザ７０１にリダイレクト要求する。ステップＳ１０２３において、Ｗｅｂブラウザ７０１はステップＳ１０１９のリダイレクト要求にしたがいクライアントセットアップＵＲＬにリダイレクトする。ステップＳ１０２４において、クライアント管理部４０８はＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれる認証情報から特定された顧客テナントＩＤに紐づくクライアント作成予約フラグがあるか検証する。Ｗｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれる認証情報は、ステップＳ１０１２で格納したＷｅｂブラウザ７０１を操作した顧客ユーザの認証情報である。クライアント作成予約フラグは、クライアント管理テーブル４１１のステータスが作成待ちのレコードを指し、ステップＳ１００５で受け付けたクライアント作成予約によって作成される。クライアント作成予約フラグがある場合はステップＳ１０２５に進む。なければステップＳ１０２６でエラーをＷｅｂブラウザ７０１に返す。
【００９６】
ステップＳ１０２５において、クライアント管理部４０８は認可サービスモジュール１０５にクライアント作成リクエストを送信する。クライアント作成リクエストには、クライアント名、リダイレクトＵＲＬなどが含まれる。ステップＳ１０２７において、クライアント管理部５０４はステップＳ１０２５のクライアント作成リクエストを受信すると、ＯＡｕｔｈクライアントを作成しクライアント管理テーブル５１１に格納する。そして、ステップＳ１０２５のクライアント作成リクエストの応答として、発行したＯＡｕｔｈクライアントのＩＤとシークレットを返す。
【００９７】
ステップＳ１０２８において、クライアント管理部４０８はステップＳ１０２７で返却されたＯＡｕｔｈクライアントのＩＤとシークレットをクライアント管理テーブル４１１に格納する。そして、クライアント管理テーブル４１１のステータスを作成済みに更新する。
【００９８】
ステップＳ１０２９において、クライアント管理部４０８は、クライアント管理テーブル４１１のリターンＵＲＬを取得する。ステップＳ１０３０において、クライアント管理部４０８はＷｅｂブラウザ７０１にリターンＵＲＬにリダイレクトするようにリダイレクト要求する。ステップＳ１０３１において、Ｗｅｂブラウザ７０１はステップＳ１０２６のリダイレクト要求に従いリターンＵＲＬにリダイレクトする。Ｗｅｂブラウザ７０１がリターンＵＲＬにアクセスすることで、クライアントアプリケーション１０７に対してＯＡｕｔｈクライアントが作成されたことを通知することが可能になっている。
【００９９】
ステップＳ１０３２において、クライアント管理部３０８は、Ｗｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれるクライアントアプリケーション１０７の認証情報を取得し、ユーザＩＤの検証及びユーザＩＤに紐づく顧客テナントＩＤを取得する。ステップＳ１０３３において、クライアント管理部３０８はステップＳ１０３２で取得した顧客テナントＩＤに対するクライアント取得リクエストをリソースサービス１０３に送信する。ここでクライアント取得リクエストは、認証ヘッダにステップＳ１００４と同様のアクセストークンを含めてリクエストする。
【０１００】
ステップＳ１０３４において、クライアント管理部４０８はステップＳ１００５と同様にクライアント取得リクエストのヘッダに含まれるアクセストークンから販社テナントＩＤを特定し、クライアント取得リクエストに含まれる顧客テナントＩＤにアクセス可能かを検証する。そして、アクセス可能であればクライアント管理テーブル４１１からＯＡｕｔｈクライアントが作成済みかどうか検証する。作成済みかどうかはステータスが作成済みかどうかで判断する。クライアントが未作成の場合は、ステップＳ１０３５にてステップＳ１０３３の応答としてクライアントアプリケーション１０７にエラーを返す。クライアントが作成済みの場合はステップＳ１０３６に進む。
【０１０１】
ステップＳ１０３６において、クライアント管理部４０８はクライアントアプリケーション１０７にステップＳ１０３３の応答としてＯＡｕｔｈクライアントのＩＤとシークレットを返却する。ステップＳ１０３７において、クライアント管理部３０８はステップＳ１０３６で返却されたＯＡｕｔｈクライアントのＩＤとシークレットをクライアント管理テーブル３１４に顧客テナントＩＤに紐づけて保存する。ステップＳ１０３８において、システム連携管理部３０３はＷｅｂブラウザ７０１にトークン取得ＵＲＬにリダイレクトするようにリダイレクト要求する。
【０１０２】
＜アクセストークン作成シーケンス＞
図１２は、本実施形態におけるクライアントアプリケーション１０７がトークンを取得する動作を示すシーケンスである。なお、シーケンスに各ステップはクライアントサーバ１０６、認可サーバ１０４に設けられたＣＰＵがＲＯＭ、ＨＤＤ等の不揮発性記憶手段に記憶された本発明の制御プログラムを読み込み実行することに応じて実現されてものとする。本シーケンスでは、発明にかかわる処理のみを説明し、その他処理については本発明の本質とは異なるため説明を省略する。
【０１０３】
ステップＳ１２０１において、Ｗｅｂブラウザ７０１はステップＳ１０３３のリダイレクト要求に応じて、トークン取得ＵＲＬにリダイレクトする。ステップＳ１２０２において、トークン管理部３０９は、トークン取得のフローを追跡するためのワンタイムセッションＩＤを生成する。ステップＳ１２０３において、トークン管理部３０９はブラウザのＣｏｏｋｉｅ情報に含まれる認証情報とユーザＩＤを検証し、ユーザＩＤに紐づく顧客テナントＩＤを取得する。そして、Ｗｅｂブラウザ７０１にＡｕｔｈｏｒｉｚａｔｉｏｎリクエストサイトへリダイレクトするようにリダイレクト要求する。Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストにはクライアント管理テーブル３１４に保存された顧客テナントＩＤに紐づくＯＡｕｔｈクライアントのＩＤとシークレット、リダイレクトＵＲＬと、生成したワンタイムセッションＩＤをＳｔａｔｅ情報として付与し、リダイレクト要求する。
【０１０４】
ステップＳ１２０３において、Ｗｅｂブラウザ７０１はステップＳ１２０２のリダイレクト要求に応じてＡｕｔｈｏｒｉｚａｔｉｏｎリクエストサイトにリダイレクトする。ステップＳ１２０４において、トークン管理部３０９は、Ａｕｔｈｏｒｉｚａｔｉｏｎリクエストの応答として認可サービスモジュール１０５のログイン画面のＨＴＭＬ（図１１）を返す。ステップＳ１２０５において、Ｗｅｂブラウザ７０１はステップＳ１２０４のログイン画面を表示する。
【０１０５】
ステップＳ１２０６において、リソースオーナである顧客ユーザがＷｅｂブラウザ７０１からログインＩＤとパスワードを入力しログインボタンを押すことで、ＨＴＴＰリクエストが送信される。ステップＳ１２０７において、認証部５０２がステップＳ１２０５でリクエストされたユーザＩＤとパスワード検証する。検証はユーザ管理テーブル５１０に登録された情報で検証を行う。認証失敗であればステップＳ１２０８でＷｅｂブラウザ７０１にステップＳ１２０６の応答としてエラーを返す。認証成功であればステップＳ１２０９に進む。ステップＳ１２０９において、認証部５０２はＡｕｈｏｒｉｚａｔｉｏｎ確認ページへリダイレクトするようにＷｅｂブラウザ７０１にリダイレクト要求する。
【０１０６】
ステップＳ１２０１０において、Ｗｅｂブラウザ７０１はＡｕｔｈｏｒｉｚａｔｉｏｎ確認ページ（図１３）にリダイレクトする。そして、クライアントアプリケーション１０７がリソースサービス１０３の保護リソースにアクセスすることを許可する旨を顧客ユーザの入力によって得る。この行為を認可と呼ぶ。認可の具体例としては、リソースオーナである顧客ユーザは、図１３の許可ボタン１３０１を押すことで、許可を示すＨＴＴＰリクエストが送信される。
【０１０７】
ステップＳ１２１１において、トークン管理部５０３がステップＳ１２１０のリクエストからクライアントアプリケーション１０７がリソースサービス１０３の保護リソースにアクセスすることが許可されたかを検証する。許可されない場合はステップＳ１２１２でステップＳ１２１０の応答としてエラーをＷｅｂブラウザ７０１に返す。許可された場合はステップＳ１２１３に進む。ステップＳ１２１３にて、トークン管理部５０３はステップＳ１２０３のＡｕｔｈｏｒｉｚａｔｉｏｎリクエストに含まれていたリダイレクトＵＲＬにリダイレクトするようにＷｅｂブラウザ７０１にリダイレクト要求する。リダイレクト要求には認可コードとＳｔａｔｅ情報が付与される。
【０１０８】
ステップＳ１２１４において、Ｗｅｂブラウザ７０１はステップＳ１２１０のリダイレクト要求に従いリダイレクトＵＲＬにリダイレクトする。ステップＳ１２１５において、トークン管理部３０９はリダイレクトＵＲＬを検証し、リクエストに付与された認可コードとＳｔａｔｅ情報を取得する。そして認可コードはトークン管理テーブル３１５に保存する。ステップＳ１２１６において、トークン管理部３０９はアクセストークン取得リクエストを送信する。アクセストークン取得リクエストには、ＯＡｕｔｈクライアントのＩＤとシークレット、ステップＳ１２１５で保存した認可コード、リダイレクトＵＲＬが付与される。
【０１０９】
ステップＳ１２１７において、トークン管理部５０３はステップＳ１２１６のリクエストに含まれるＯＡｕｔｈクライアントのＩＤとシークレットおよび、リダイレクトＵＲＬ、認可コードの検証を行う。検証はトークン管理テーブル５１２およびクライアント管理テーブル５１１の情報で行う。検証失敗した場合はステップＳ１２１８において、ステップＳ１２１６の応答としてＷｅｂブラウザ７０１にエラーを返す。検証ＯＫであればアクセストークンとリフレッシュトークンを作成しステップＳ１２１９に進む。作成したアクセストークンとリフレッシュトークンをトークン管理テーブル５１２に保存する。
【０１１０】
ステップＳ１２１９において、トークン管理部５０３はステップＳ１２０１６のアクセストークン取得リクエストの応答として、アクセストークンとリクエストトークンを返す。ステップＳ１２１７において、トークン管理部３０９は、ステップＳ１２１９で返却されたアクセストークンとリフレッシュトークンを顧客テナントＩＤに紐づけてトークン管理テーブル３１５に保存する。ステップＳ１２２０において、トークン管理部３０９はＷｅｂブラウザ７０１にトークン取得完了のＨＴＭＬを送信する。そして、ステップ８０５に遷移し、図９の設定メニュー９０２がｄｉｓａｂｌｅされる。
【０１１１】
＜ＡＰＩ呼び出しフロー＞
図１４は、本実施形態におけるクライアントアプリケーション１０７がリソースサービス１０３のＡＰＩを呼び出すフローチャートである。なお、フローチャートの各ステップ処理はクライアントアプリケーション１０７に設けられたＣＰＵがＲＯＭ、ＨＤＤ等の不揮発性記憶手段に記憶された本発明の制御プログラムを読み込み実行することに応じて実現されたものとする。本フローでは、発明にかかわる処理のみを説明し、その他処理については本発明の本質と異なるため説明を省略する。
【０１１２】
ステップＳ１４０１において、トークン管理部３０９がトークン管理テーブル３１５からテナントＩＤに紐づくアクセストークンが期限切れかどうかを検証する。テナントＩＤはユーザがクライアントアプリケーション１０７にログイン後、Ｗｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれる認証情報とユーザＩＤの検証し、ユーザＩＤに紐づく顧客テナントＩＤを取得して得る。また、アクセストークンが期限切れかどうかはアクセストークン有効期限より判断する。期限切れの場合はステップＳ１４０２に進む。期限内であればステップＳ１４０３に進む。
【０１１３】
ステップＳ１４０２において、トークン管理部３０９はトークン管理テーブル３１５からテナントＩＤに紐づくリフレッシュトークンが期限切れかどうかを検証する。リフレッシュトークンが期限切れかどうかはリフレッシュトークン有効期限より判断する。期限切れの場合はステップＳ１４０４に進む。期限内であればステップＳ１４０５に進む。
【０１１４】
ステップＳ１４０４において、トークン管理部３０９は図８のシステム連携開始フローに遷移するようにＷｅｂブラウザ７０１にＨＴＭＬを返す。そして、図９の設定メニュー９０２をｅｎａｂｌｅにする。ステップＳ１４０３において、トークン管理部３０９はアクセストークンをリクエストヘッダに付与してリソースサービス１０３のＡＰＩを呼び出す。ステップＳ１４０５において、トークン管理部３０９はリフレッシュトークンを使ってアクセストークンの再取得を行う。
【０１１５】
＜ＡＰＩ呼び出しシーケンス＞
図１５は、本実施形態におけるクライアントアプリケーション１０７がリソースサービス１０３のＡＰＩを呼び出すシーケンスである。なお、シーケンスの各ステップ処理はクライアントアプリケーション１０７に設けられたＣＰＵがＲＯＭ、ＨＤＤ等の不揮発性記憶手段に記憶された本発明の制御プログラムを読み込み実行することに応じて実現されたものとする。本フローでは、発明にかかわる処理のみを説明し、その他処理については本発明の本質と異なるため説明を省略する。
【０１１６】
ステップＳ１５０１において、Ｗｅｂブラウザ７０１はクライアントアプリケーション１０７にＨＴＭＬおよびＪａｖａＳｃｒｉｐｔ（登録商標）の取得要求を行う。ステップＳ１５０２において、クライアントアプリケーション１０７は、ステップＳ１５０１の応答としてリクエストされたＨＴＭＬおよびＪａｖａＳｃｒｉｐｔを返却する。ステップＳ１５０３において、Ｗｅｂブラウザ７０１はステップＳ１５０２で返却されたＪａｖａＳｃｒｉｐｔにからＲＥＳＴ  ＡＰＩを取得する。ステップＳ１５０４において、Ｗｅｂブラウザ７０１はクライアントアプリケーション１０７にＲＥＳＴ  ＡＰＩリクエストを要求する。Ｗｅｂブラウザ７０１は、Ｃｏｏｋｉｅ情報に認証情報を含めて送信する。クライアントアプリケーション１０７のＦＱＤＮに対して、ＲＥＳＴ  ＡＰＩのリクエストを送信する。
【０１１７】
ステップＳ１５０５において、ユーザ管理部３０６はＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれる認証情報とユーザ管理テーブル３１２のユーザＩＤの検証し、ユーザＩＤと紐づく顧客テナントＩＤを顧客マッピングテーブル３１３より取得する。ステップＳ１５０６において、トークン管理部３０９がステップＳ１５０５で取得したテナントＩＤに紐づくアクセストークンがあるかトークン管理テーブル３１５より検証する。トークンが期限切れの場合はステップＳ１５０７に進む。トークンが期限切れでなければステップＳ１５１１に進む。
【０１１８】
ステップＳ１５０７において、トークン管理部３０９が認可サービスモジュール１０５にアクセストークンのリフレッシュ要求を行う。リフレッシュ要求には、クライアント管理テーブル３１４でテナントＩＤに紐づくＯＡｕｔｈクライアントＩＤとシークレットおよび、リフレッシュトークンを使う。ステップＳ１５０８において、トークン管理部５０３がトークン管理テーブル５１２およびクライアント管理テーブル５１１よりステップＳ１５０７で取得したＯＡｕｔｈクライアントＩＤとシークレットおよびリフレッシュトークンの検証を行う。検証の結果、正しければ新しいアクセストークンとリフレッシュトークンを発行し、アクセストークンの期限とリフレッシュトークンの期限も更新して、トークン管理テーブル５１２を更新する。そして、ステップＳ１５０７の応答として、新しいアクセストークンとリフレッシュトークンおよび各トークンの期限を返却する。
【０１１９】
ステップＳ１５０９において、トークン管理部３０９は、ステップＳ１５０８で取得した各トークンおよび期限をトークン管理テーブル３１５に顧客テナントＩＤに紐づけて保存する。ステップＳ１５１０において、ＡＰＩ呼び出し部３１０がステップＳ１５０３のＲＥＳＴ  ＡＰＩのＦＱＤＮを、クライアントアプリケーションのＦＱＤＮからリソースサービスのＦＱＤＮにコンバートする。ステップＳ１５１１において、ＡＰＩ呼び出し部３１０はリソースサービス１０３にＲＥＳＴ  ＡＰＩのリクエストを行う。ＲＥＳＴ  ＡＰＩの認証ヘッダにはアクセストークンを付与してリクエストを行う。ステップＳ１５１２において、認証部４０３はステップＳ１５１１のＲＥＳＴ  ＡＰＩリクエストの認証ヘッダに含まれるアクセストークンの検証を行う。認証部４０３はトークン管理部５０３にアクセストークンの検証を依頼し、トークン管理テーブル５１２との検証が行われる。
【０１２０】
ステップＳ１５１３において、ＡＰＩ管理部４０４はステップＳ１５１２でアクセストークンの検証に成功すると、ステップＳ１５１１でリクエストされたＲＥＳＴ  ＡＰＩを処理し、リソースを返却する。ステップＳ１５１４において、ＡＰＩ呼び出し部３１０はステップＳ１５１３で返却されたリソースをＷｅｂブラウザ７０１にステップＳ１５０４の応答として返却する。なお、クライアントアプリケーション１０７は、返却されたリソースに処理を施し、その結果生成されたリソースを応答として返却しても良い。ステップＳ１５１５において、Ｗｅｂブラウザ７０１はステップＳ１５１４で返却されたリソースを使ってＷｅｂページを表示する。
【０１２１】
＜クライアント削除シーケンス＞
図１６、本実施形態におけるクライアント削除シーケンスである。なお、シーケンスの各ステップ処理は、クライアントサーバ１０６、リソースサーバ１０２、認可サーバ１０４に設けられたＣＰＵがＲＯＭ、ＨＤＤ等の不揮発性記憶手段に記憶された本発明の制御プログラムを読み込み実行することに応じて実現されたものとする。
【０１２２】
ステップＳ１６０１において、顧客ユーザ（リソースオーナー）がＷｅｂブラウザ７０１からリソースサービス１０３との連携解除のＨＴＴＰリクエストを送信する。ステップＳ１６０２において、システム連携管理部３０３がユーザ管理テーブル３１２および顧客マッピングテーブル３１３からリソースサービス１０３の顧客テナントＩＤを特定し、リソースサービス１０３のテナントに紐づくＯＡｕｔｈクライアントが登録済みかどうかを確認する。未登録であればステップＳ１６０３にて、ステップＳ１６０１の応答として連携解除成功が返る。登録済みであればステップＳ１６０４に進む。連携開始のボタンを押下するとＯＡｕｔｈクライアントの作成予約がリソースサービス１０３に送信されるが、その後ユーザが権限委譲を認可しなかった場合は、ＯＡｕｔｈクライアントが登録されていない状況があり得るためステップＳ１６０２で確認を行っている。
【０１２３】
ステップＳ１６０４にて、クライアント管理部３０８がリソースサービス１０３にクライアント削除予約リクエストを送信する。クライアント削除予約リクエストには、顧客テナントＩＤを含む。また、認証ヘッダにあらかじめ認可サービスモジュール１０５から払い出したアクセストークンを含めてリクエストする。このアクセストークンは、クレデンシャル管理テーブル３１６で管理されたＣｌｉｅｎｔ  Ｃｒｅｄｅｎｔｉａｌグラントで作成されたクライアントＩＤとシークレットを使って取得したアクセストークンである。クライアントＩＤとシークレットは、クライアントアプリケーション１０７所有の販売会社リソースとして認可サービスモジュール１０５に登録されたものである。
【０１２４】
ステップＳ１６０５にて、クライアント管理部４０８は、ステップＳ１６０４のクライアント削除予約リクエストを受け付けられるか検証する。まず、Ｗｅｂサービス部４０６がステップＳ１６０４のリクエストを取得すると、認証部４０３が認証ヘッダに含まれるアクセストークンの検証を認可サービスモジュール１０５に依頼する。認証部４０３は認可サービスモジュール１０５から認証成功が返却されると、クライアント管理部４０８はアクセストークンがアクセス可能な販売テナントＩＤの販社顧客リレーション管理テーブル４１０にアクセスする。そして、ステップＳ１６０４のリクエストに含まれる顧客テナントＩＤにアクセス可能か検証する。アクセス可能だった場合は、クライアント管理テーブル４１１に顧客テナントＩＤに紐づくステータスを確認する。ステータスが提供済みと作成済みであった場合はステップＳ１６０７に進む。それ以外のステータス、例えば作成待ちの場合はステップＳ１６０６に進む。
【０１２５】
ステップＳ１６０６において、クライアント管理部４０８はクライアント管理テーブル４１１の顧客テナントＩＤに紐づく情報を削除し、ステップＳ１６０４の応答として削除成功を返却する。ステップＳ１６０６は、認可サービスモジュール１０５にＯＡｕｔｈクライアントが未作成で、かつ、リソースサービス１０３のクライアント管理テーブル４１１にクライアント作成予約がされている状態である。そのため、ステップＳ１６０４のクライアント削除予約リクエストに対して、削除が必要なクライアント管理テーブル４１１の情報のみ削除すればよい。
【０１２６】
ステップＳ１６０７において、クライアント管理部４０８は、ステップＳ１００４のクライアント削除予約リクエストの応答としてクライアントセットアップＵＲＬのエンドポイントを返却する。ステップＳ１６０７は、認可サービスモジュール１０５にＯＡｕｔｈクライアントが登録済みで、かつ、リソースサービス１０３のクライアント管理テーブル４１１にクライアント情報が登録されている状態である。そのため、ステップＳ１６０４のクライアント削除予約リクエストに対して、リソースサービス１０３の情報と、認可サービスモジュール１０５のＯＡｕｔｈクライアント情報を削除する必要がある。認可サービスモジュール１０５のＯＡｕｔｈクライアントは、Ｗｅｂブラウザ７０１より顧客ユーザの同意のもと削除されなければならない。よって、クライアント管理テーブル４１１のステータスを削除待ちに更新する。そして、Ｗｅｂブラウザ７０１に認可サービスモジュール１０５のＯＡｕｔｈクライアント削除処理するためのエンドポイントであるクライアントセットアップＵＲＬにリダイレクトするように、クライアントセットアップＵＲＬをステップＳ１６０４の応答として返却する。
【０１２７】
ステップＳ１６０８において、クライアント管理部３０８はステップＳ１６０７で返却されたクライアントセットアップＵＲＬに対して、Ｗｅｂブラウザ７０１にリダイレクトするようにリダイレクト要求する。ここでのリダイレクト要求は、Ｗｅｂブラウザ７０１にＨＴＴＰ／１．１ステータスコード“３０２”を用いて行われる。ステップＳ１６０９において、Ｗｅｂブラウザ７０１はステップＳ１６０８のリダイレクト要求に従いクライアントセットアップＵＲＬにリダイレクトする。
【０１２８】
ステップＳ１６１０において、Ｗｅｂブラウザ７０１からクライアントセットアップＵＲＬにリダイレクトすると、認証部４０３はＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報からリソースサービス１０３にログイン済みかどうか認可サービスモジュール１０５に問い合わせる。認可サービスモジュール１０５の認証部５０２は、ログイン済みかどうかを検証し、ログイン済みであればステップＳ１６１４に進む。ログインしていなければステップＳ１６１１に進む。ステップＳ１６１１において、認証部５０２は認可サービスモジュール１０５のログインページにリダイレクトするようにＷｅｂブラウザ７０１にリダイレクト要求する。具体的には図１１に示すログイン画面のＷｅｂブラウザ７０１に表示させる。
【０１２９】
ステップＳ１６１２において、顧客ユーザ（リソースオーナ）はＷｅｂブラウザ７０１に表示されたログイン画面に対して、ユーザＩＤおよびパスワードを入力しログインを実行する。なお、ここで指定するユーザＩＤとパスワードは、ＯＡｕｔｈクライアントを削除したい顧客テナントにアクセス可能なユーザＩＤとパスワードである。
【０１３０】
ステップＳ１６１３において、認証部５０２はステップＳ１０１１で受け付けたユーザＩＤとパスワードの組み合わせがユーザ管理テーブル５１０に登録されている情報と一致するかを検証し、一致する場合はステップＳ１６１４に進む。そして、認証情報をＷｅｂブラウザ７０１に対してＣｏｏｋｉｅ情報として格納する。一致しない場合はステップＳ１６１５でＷｅｂブラウザ７０１にエラーを返す。ステップＳ１６１５でＷｅｂブラウザ７０１にエラーが返った場合、ステップＳ１６１５でクライアント管理テーブル４１１が作成待ちのステータスになっているため、再度ステップＳ１６０１の連携解除のＨＴＴＰリクエストを送信するところから処理を始める必要がある。
【０１３１】
ステップＳ１６１４において、認証部５０２はステップＳ１６１２で検証したユーザＩＤに紐づく顧客テナントＩＤがサービス開始状態かどうかをリソースサービス１０３に問い合わせる。本実施形態では、リソースサービス１０３であるデバイス管理サービスは、販売会社が顧客リソースにアクセスすることを顧客ユーザが同意しなければサービスを開始できない。そのため、サービスが開始状態かどうかは販社顧客リレーション管理テーブル４１０の同意ステータスから判断する。
【０１３２】
ステップＳ１６１６において、テナント管理部４０２はステップＳ１６１３の応答として指定された顧客テナントＩＤに紐づく同意ステータスを返却する。ステップＳ１６１７において、認証部５０２はステップＳ１６１４で返却された同意ステータスが同意済みかどうかを検証する。同意済みであればステップＳ１６２４に進む。同意済みでなければステップＳ１６１８に進む。ステップＳ１６１８において、ＷｅｂＵＩ部は同意をもらうためのＨＴＭＬを作成し、Ｗｅｂブラウザ７０１にリダイレクトするようにリダイレクト要求する。ステップＳ１６１９において、Ｗｅｂブラウザ７０１はステップＳ１６１６のリダイレクト要求に従い同意画面にリダイレクトする。具体的には図１２の同意画面にリダイレクトし、販売会社のユーザがリソースにアクセスしてサービスを提供することを同意する。
【０１３３】
ステップＳ１６２０において、テナント管理部４０２はステップＳ１６１７で同意されたかどうかを検証し、同意されなかった場合はステップＳ１６２１に進む。同意された場合は販社顧客リレーション管理テーブル４１０の同意ステータスを同意済みに更新し、ステップＳ１６２２に進む。
【０１３４】
ステップＳ１６２２において、テナント管理部４０２はクライアントセットアップＵＲＬにリダイレクトするようにＷｅｂブラウザ７０１にリダイレクト要求する。ステップＳ１６２３において、Ｗｅｂブラウザ７０１はステップＳ１６１９のリダイレクト要求にしたがいクライアントセットアップＵＲＬにリダイレクトする。ステップＳ１６２４において、クライアント管理部４０８はＷｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれる認証情報から特定された顧客テナントＩＤに紐づくクライアント削除予約フラグがあるか検証する。Ｗｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれる認証情報は、ステップＳ１６１２で格納したＷｅｂブラウザ７０１を操作した顧客ユーザの認証情報である。クライアント削除予約フラグは、クライアント管理テーブル４１１のステータスが削除待ちのレコードをさし、ステップＳ１６０７で受け付けたクライアント削除予約によって作成される。クライアント削除予約フラグがある場合はステップＳ１６２５に進む。なければステップ  Ｓ１６２６でステップＳ１６２３の応答としてエラーをＷｅｂブラウザ７０１に返す。
【０１３５】
ステップＳ１６２５において、クライアント管理部４０８は認可サービスモジュール１０５にクライアント削除リクエストを送信する。クライアント削除リクエストには、クライアント名などが含まれる。ステップＳ１６２７において、クライアント管理部５０４はステップＳ１６２５のクライアント削除リクエストを受信すると、クライアント管理テーブル５１１に格納されたＯＡｕｔｈクライアントを削除する。そして、ステップＳ１６２５のクライアント削除リクエストの応答として、削除成功を返す。ステップＳ１６２８において、クライアント管理テーブル４１１に格納されたリターンＵＲＬを取得し、ＲＯＭ２０２に格納する。そして、ステップＳ１６２９において、クライアント管理部４０８はクライアント管理テーブル４１１からＯＡｕｔｈクライアントの情報を削除する。
【０１３６】
ステップＳ１６３０において、クライアント管理部４０８はＷｅｂブラウザ７０１にステップＳ１６２８でＲＯＭ２０２に保持したリターンＵＲＬにリダイレクトするようにリダイレクト要求する。ステップＳ１６３１において、Ｗｅｂブラウザ７０１はステップＳ１６３０のリダイレクト要求に従いリターンＵＲＬにリダイレクトする。ステップＳ１６３２において、クライアント管理部３０８は、Ｗｅｂブラウザ７０１のＣｏｏｋｉｅ情報に含まれるクライアントアプリケーション１０７の認証情報を取得し、ユーザＩＤの検証及びユーザＩＤに紐づく顧客テナントＩＤを取得する。ステップＳ１６３３において、クライアント管理部３０８はステップＳ１６３２で取得した顧客テナントＩＤに対するＯＡｕｔｈクライアントをクライアント管理テーブル３１４から削除する。ステップＳ１６３４において、クライアント管理部３０８はステップＳ１６３１の応答として削除成功を返却する。
【０１３７】
本実施例により、ＯＡｕｔｈクライアントをリソースのアクセス範囲ごとに作成することで、ＯＡｕｔｈクライアント作成およびアクセストークン取得・管理の際に、意識的にアクセス範囲との紐づけチェックを行うため、よりセキュリティが強化される。さらに、ＯＡｕｔｈクライアントおよびアクセストークンを発行する際に、リソースのアクセス範囲のチェックを、リダイレクトＵＲＬを使って疑似チェックできるようになるため、認可サービス側でのチェックも強化される。
【０１３８】
［その他の実施例］
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施例の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【０１３９】
１０１  管理端末
１０２  リソースサーバ
１０４  認可サーバ
１０６  クライアントサーバ
【図１】
2018205840.tif 000015
【図２】
2018205840.tif 000016
【図３】
2018205840.tif 000017
【図４】
2018205840.tif 000018
【図５】
2018205840.tif 000019
【図６】
2018205840.tif 000020
【図７】
2018205840.tif 000021
【図８】
2018205840.tif 000022
【図９】
2018205840.tif 000023
【図１０】
2018205840.tif 000024
【図１１】
2018205840.tif 000025
【図１２】
2018205840.tif 000026
【図１３】
2018205840.tif 000027
【図１４】
2018205840.tif 000028
【図１５】
2018205840.tif 000029
【図１６】
2018205840.tif 000030