図面 (/)
課題
複数アプリケーションを実行可能な端末上において各アプリケーションを操作して通信テストを行うことは操作者の負担が大きい。
解決手段
本発明は、通信部を有しており、一以上のクライアントアプリケーションに対して前記リソースサーバとの間の通信テストの開始を通知し、前記一以上のクライアントアプリケーションからの要求に応じてリソースサーバと通信を行うためのトークン情報を取得し、取得した前記トークン情報を、前記一以上のクライアントアプリケーションの要求に応じて提供し、前記一以上のクライアントアプリケーションからの前記通信テストの結果を受け取る。
概要
背景
クラウドサービスは、一般的にWebサービスのAPI(Application Programming Interface)を公開しており、端末や他のクラウドサービスからAPIを介してサービスが提供する機能を利用する事ができる。このAPI利用における認証、認可のプロトコルとして、OAuth2.0と呼ばれる標準プロトコルが策定されている。OAuth2.0では、クライアントとなる端末や他のリソースサーバと認可サーバとが連携することで認証および認可を行う。認証および認可を受けたクライアントは、認可サーバから認可トークンを取得し、その認可トークンを送信することでAPIを利用する。
OAuth2.0では、認可プロトコルのフローをGrant Typeと呼んでいる。代表的なGrant Typeとして、ユーザがクライアントに権限を委譲するAuthorization Code Grantと、クライアントが自身のリソースにアクセスするためのClient Credentials Grantが定義されている。端末は、ユースケースによってGrant Typeを使い分ける事が考えられる。例えば、端末のオーナーであるユーザが、端末を操作した事を契機にクラウドサービスと連携する場合は、Authorization Code Grantが選択される。一方、端末が備えるセンサーや機器における変化を検知し、クラウドサービスと連携する場合は、Client Credentials Grantが選択される。このように、OAuth2.0を利用する事で、様々なユースケースに対応する事が可能である。
一つの端末上で各々がリソースサーバと連携する複数のクライアントアプリケーションが動作するシステムの場合、各アプリケーションが各々に認証・認可処理を行うのは非効率であるため、認証・認可処理を肩代わりするトークンプロバイダアプリケーションが配置される構成が提案されている(特許文献1)。その際、各クライアントアプリケーションはOAuth2.0による認証後にトークンプロバイダアプリケーションからアクセストークンを取得し、リソースサーバと連携する。
このとき、複数のクライアントアプリケーションと連携するリソースサーバはアプリケーションごとに異なり、そのドメインも異なることがある。そして各ドメインへのアクセス可否はファイヤウォール設定など端末設置先のネットワーク構成やセキュリティ設定などに依存する。したがって、端末上の各クライアントアプリケーションがリソースサーバと適切に連携するためには、クライアントアプリケーションとリソースサーバとの間の通信が可能であるかを確認する必要がある。通信相手のリソースサーバはクライアントアプリケーションごとに決まっているので、この確認はクライアントアプリケーションごとに実施しなければならない。
概要
複数アプリケーションを実行可能な端末上において各アプリケーションを操作して通信テストを行うことは操作者の負担が大きい。本発明は、通信部を有しており、一以上のクライアントアプリケーションに対して前記リソースサーバとの間の通信テストの開始を通知し、前記一以上のクライアントアプリケーションからの要求に応じてリソースサーバと通信を行うためのトークン情報を取得し、取得した前記トークン情報を、前記一以上のクライアントアプリケーションの要求に応じて提供し、前記一以上のクライアントアプリケーションからの前記通信テストの結果を受け取る。
目的
クラウドサービスは、一般的にWebサービスのAPI(Application Programming Interface)を公開しており、端末や他のクラウドサービスからAPIを介してサービスが提供する
効果
実績
- 技術文献被引用数
- 0件
- 牽制数
- 0件
この技術が所属する分野
(分野番号表示ON)※整理標準化データをもとに当社作成
請求項1
一以上のクライアントアプリケーションを有する情報処理装置であって、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションを有することによって以下の機能を備えることを特徴とし、前記機能とは、前記一以上のクライアントアプリケーションに対して前記リソースサーバとの間の通信テストの開始を通知するテスト開始通知機能と、前記一以上のクライアントアプリケーションからの要求に応じて前記リソースサーバと通信を行うためのトークン情報を取得する取得機能と、前記一以上のクライアントアプリケーションからの前記通信テストの結果を受け取るテスト結果受信機能と、であることを特徴とする情報処理装置。
請求項2
請求項1に記載の情報処理装置であって、前記一以上のクライアントアプリケーションからの要求に応じてイベント通知先として登録する登録機能を更に有し、前記テスト開始通知機能は、前記イベント通知先として登録した前記一以上のクライアントアプリケーションに対して、前記リソースサーバとの間の前記通信テストの開始を通知することを特徴とする情報処理装置。
請求項3
請求項1または2に記載の情報処理装置であって、テスト対象の前記一以上のクライアントアプリケーションを登録したリストを保持する保持機能を更に有し、前記テスト開始通知手段は、前記リストに登録されている前記一以上のクライアントアプリケーションに対して、前記リソースサーバとの間の前記通信テストの開始を通知することを特徴とする情報処理装置。
請求項4
請求項1乃至3のいずれか一項に記載の情報処理装置であって、前記テスト開始通知機能は、認可サーバへの前記情報処理装置の登録指示、または前記認可サーバから受信した前記情報処理装置の登録完了後の通信テスト指示をトリガーとして、前記通信テストの開始を通知することを特徴とする情報処理装置。
請求項5
請求項1乃至4のいずれか一項に記載の情報処理装置であって、前記通信テストの結果を出力する出力手段を更に有することを特徴とする情報処理装置。
請求項6
請求項1乃至5のいずれか一項に記載の情報処理装置であって、前記一以上のクライアントアプリケーションを実行することを特徴とする情報処理装置。
請求項7
一以上のクライアントアプリケーションを有する情報処理装置であって、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションを更に有する情報処理装置を、前記一以上のクライアントアプリケーションに対して前記リソースサーバとの間の通信テストの開始を通知するテスト開始通知手段と、前記一以上のクライアントアプリケーションからの要求に応じて前記リソースサーバと通信を行うためのトークン情報を取得する取得手段と、前記一以上のクライアントアプリケーションからの前記通信テストの結果を受け取るテスト結果受信手段として機能させるためのプログラム。
請求項8
一以上のクライアントアプリケーションを有する情報処理装置であって、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションを更に有する情報処理装置により実行されるクライアントアプリケーションのテスト方法であって、前記一以上のクライアントアプリケーションに対して前記リソースサーバとの間の通信テストの開始を通知し、前記一以上のクライアントアプリケーションからの要求に応じて前記リソースサーバと通信を行うためのトークン情報を取得し、前記一以上のクライアントアプリケーションからの前記通信テストの結果を受け取ることを特徴とするクライアントアプリケーションのテスト方法。
技術分野
0001
本発明は、一以上のクライアントアプリケーションの通信テストを行う情報処理装置およびクライアントアプリケーションのテスト方法、プログラムに関する。
背景技術
0002
クラウドサービスは、一般的にWebサービスのAPI(Application Programming Interface)を公開しており、端末や他のクラウドサービスからAPIを介してサービスが提供する機能を利用する事ができる。このAPI利用における認証、認可のプロトコルとして、OAuth2.0と呼ばれる標準プロトコルが策定されている。OAuth2.0では、クライアントとなる端末や他のリソースサーバと認可サーバとが連携することで認証および認可を行う。認証および認可を受けたクライアントは、認可サーバから認可トークンを取得し、その認可トークンを送信することでAPIを利用する。
OAuth2.0では、認可プロトコルのフローをGrant Typeと呼んでいる。代表的なGrant Typeとして、ユーザがクライアントに権限を委譲するAuthorization Code Grantと、クライアントが自身のリソースにアクセスするためのClient Credentials Grantが定義されている。端末は、ユースケースによってGrant Typeを使い分ける事が考えられる。例えば、端末のオーナーであるユーザが、端末を操作した事を契機にクラウドサービスと連携する場合は、Authorization Code Grantが選択される。一方、端末が備えるセンサーや機器における変化を検知し、クラウドサービスと連携する場合は、Client Credentials Grantが選択される。このように、OAuth2.0を利用する事で、様々なユースケースに対応する事が可能である。
0003
一つの端末上で各々がリソースサーバと連携する複数のクライアントアプリケーションが動作するシステムの場合、各アプリケーションが各々に認証・認可処理を行うのは非効率であるため、認証・認可処理を肩代わりするトークンプロバイダアプリケーションが配置される構成が提案されている(特許文献1)。その際、各クライアントアプリケーションはOAuth2.0による認証後にトークンプロバイダアプリケーションからアクセストークンを取得し、リソースサーバと連携する。
0004
このとき、複数のクライアントアプリケーションと連携するリソースサーバはアプリケーションごとに異なり、そのドメインも異なることがある。そして各ドメインへのアクセス可否はファイヤウォール設定など端末設置先のネットワーク構成やセキュリティ設定などに依存する。したがって、端末上の各クライアントアプリケーションがリソースサーバと適切に連携するためには、クライアントアプリケーションとリソースサーバとの間の通信が可能であるかを確認する必要がある。通信相手のリソースサーバはクライアントアプリケーションごとに決まっているので、この確認はクライアントアプリケーションごとに実施しなければならない。
先行技術
0005
特許第6066647号
発明が解決しようとする課題
0006
そこで各アプリケーションがクラウドサービスと連携できることを保証するには、まず端末使用者がトークンプロバイダアプリケーションにおいて認可サーバへの端末の登録を行う。そののち、使用者がクライアントアプリケーションを一つずつ起動して通信テストを行い、結果を確認する必要がある。この作業は煩雑な作業であり、クライアントアプリケーションが増えるに連れて作業量が増大し、使用者の負担となる。
課題を解決するための手段
0008
上記目的を達成するために本発明は以下の構成を有する。すなわち本発明の一側面によれば、一以上のクライアントアプリケーションを有する情報処理装置であって、前記一以上のクライアントアプリケーションがリソースサーバと通信するために必要なトークン情報を提供するトークンプロバイダアプリケーションを有することによって以下の機能を備えることを特徴とし、前記機能とは、
前記一以上のクライアントアプリケーションに対して前記リソースサーバとの間の通信テストの開始を通知するテスト開始通知機能と、
前記一以上のクライアントアプリケーションからの要求に応じて前記リソースサーバと通信を行うためのトークン情報を取得する取得機能と、
前記一以上のクライアントアプリケーションからの前記通信テストの結果を受け取るテスト結果受信機能と、
であることを特徴とする情報処理装置が提供される。
発明の効果
0009
本発明により、クライアントアプリケーションの通信テストを自動化して作業者による作業負担を低減することができる。
図面の簡単な説明
0010
システム構成例を示す図である。
端末のハードウェア構成例を示す図である。
第一の実施形態に係るトークンプロバイダアプリケーション310のモジュール構成を示す図である。
第一の実施形態に係る通信テストのシーケンスを示す図である。
第一の実施形態に係る通信テストのシーケンスを示す図である。
通信テスト開始の表示画面例を示す図である。
通信テスト結果の表示画面例を示す図である。
通信テスト結果詳細の表示画面例を示す図である。
第二の実施形態に係るトークンプロバイダアプリケーション310のモジュール構成を示す図である。
第二の実施形態に係る通信テストのシーケンスを示す図である。
実施例
0011
以下、本発明の実施形態について図面を用いて説明する。
[システム構成]
本実施形態にかかるシステムは、図1に示すような構成を示す図である。
認可サーバ100は、端末の認証・アクセストークンの発行を実現するためのAPIを備えるサーバである。
リソースサーバ200はWebサービスとして公開されるAPIを備える。端末300は、例えばPC(Personal Computer)やスマートフォンと呼ばれる携帯端末、複合機などが該当する。
トークンプロバイダアプリケーション310は、認可サーバ100が公開するAPIを利用することで、端末の認証を行い、クライアントアプリケーション320にリソースサーバ200のAPI利用に必要なアクセストークンを提供する。クライアントアプリケーション320は一つとは限らず、一以上であってもよい。
クライアントアプリケーション320は、リソースサーバ200が公開するAPIを利用することで、自身の提供する機能と合わせたサービスをユーザに提供する。
0012
本実施形態に係るシステムの構成要素は、例えば、図2に示すような構成の情報処理装置にて実現される。
図2は、認可サーバ100、リソースサーバ200、および端末300のハードウェア構成の例を示す。なお認可サーバ100とリソースサーバ200については同じハードウェア構成を有するのでサーバとして示した。また端末300としては、汎用のパーソナルコンピュータなどの情報処理装置のほか、MFPあるいは単にデバイスなどと呼ばれる多機能周辺機器などを利用することもできる。パーソナルコンピュータはサーバと同様のハードウェア構成でよいのでその図は省略し、多機能周辺機器の構成を図2に示した。なおサーバについては、ユーザインターフェースを持たなくとも端末との間の相互作用は可能なのでユーザインターフェースを示していない。しかし、コンピュータを端末として利用するのであれば、キーボードやポインティングデバイス、タッチパネルといったユーザインターフェースが端末には必要である。
0013
図2は端末装置300とサーバ100,200とを接続した構成例を示す。なお図2では端末装置300とサーバ100,200とはネットワーク220を介して接続されているが、ネットワーク220は、LANやWAN、インターネットなど様々な種類のネットワークやそれらの複合を含んでいてよい。
0014
●端末(MFP)のハードウェア
図2において、端末装置300は、のの一例であるMFPのハードウェア構成を示す。操作部210は、タッチパネル機能を有する表示部や各種ハードキー等を有し、制御部301からのデータに従ってユーザに対して情報を表示したり、ユーザの操作に応じた情報を制御部301に入力したりする。スキャナ部212は、原稿上の画像を読み取って、その画像の画像データを作成して制御部301に供給する。プリンタ部213は、制御部301から受け取った画像データに基づいて用紙上に画像を印刷する。
0015
制御部301は、操作部210、スキャナ部212、プリンタ部213と電気的に接続されており、またネットワーク220にもネットワークインターフェース(I/F)206を介して接続されている。これによりネットワーク220を介した、TCP/IP等の通信プロトコルによる通信が可能となっている。制御部301において、CPU201、ROM202、RAM203、HDD204、操作部I/F205、ネットワークI/F206、スキャナI/F207、画像処理部208及びプリンタI/F209がシステムバス211を介して接続されている。CPU201は、ROM202のブートプログラムを実行してHDD204に記憶されたOSや制御プログラムをRAM203に展開し、そのプログラムに基づいてこの端末(MFP)300を統括的に制御する。この制御には、後述のフローチャートを実現するためのプログラムの実行も含む。ROM202には、このMFP110のブートプログラムや各種データが格納されている。RAM203は、CPU201が動作するためのワークメモリを提供し、また画像データを一時記憶するための画像メモリも提供している。HDD204はハードディスクドライブであり、OSや各種プログラムや画像データを格納している。
0016
操作部I/F205は、システムバス211と操作部210とを接続するためのインターフェース部である。ネットワークI/F206は、ネットワーク220及びシステムバス211に接続し、ネットワークを介して情報の入出力を行う。スキャナI/F207は、スキャナ部212と制御部301との間のインターフェースを制御する。画像処理部208は、スキャナ部212から入力した画像データ、及びプリンタ部213に出力する画像データに対して、回転、色変換、画像圧縮/伸張処理などの画像処理を行う。プリンタI/F209は、画像処理部208で処理された画像データを受け取り、この画像データに付随している属性データに従ってプリンタ部213による印刷を制御する。
0017
操作部210には、たとえば立ち上げ後の初期画面において、クライアントアプリケーション320の登録済みのショートカット(あるいはGUIボタン)が表示される。クライアントアプリケーション320は、アクセス先のリソースサーバ200ごとに用意される。ショートカットが操作される(押下される)と、対応するクライアントアプリケーション320が起動されて、設定されたアクセス先(リソースサーバ)へとアクセスする。
0018
●サーバのハードウェア
図2には、認可サーバ100とリソースサーバ200(ここでは、これらをまとめてサーバ100と称する)のハードウェア構成も示されている。サーバ100は、CPU251、RAM252、ROM253、ハードディスクドライブ(HDD)254、ネットワークI/F255を有し、これらはシステムバス256を介して互いに通信可能に接続されている。ROM253はブートプログラムを格納しており、CPU251は電源オン時に、このブートプログラムを読み出してHDD254にインストールされているOSや制御プログラム等をRAM252に展開する。そしてCPU251が、RAM252に展開したプログラムを実行することにより、このサーバ100の機能が実現される。またCPU251は、ネットワークI/F255を介して接続されているネットワーク上の他の装置、例えば端末300との通信を行う。尚、端末300がコンピュータであるばあいには、キーボードなどのユーザインターフェースを有している。
0019
<第一の実施形態>
以下に、第一の実施形態にかかる説明を記載する。
[モジュール構成]
図3は、第一の実施形態に係るトークンプロバイダアプリケーション310のモジュール構成の例を示す図である。各モジュールを実行されることでサービスを提供する。トークンプロバイダアプリケーション310は端末300にインストールされて実行される。なお、ここでは、本実施形態に係るモジュールのみを示し、他のモジュールについては省略する。
トークンプロバイダアプリケーション310は、アクセストークン供給部311、通知テスト開始通知部312,通信テスト結果受信部313、および通信テスト結果表示部314を備える。
アクセストークン供給部311は、クライアントアプリケーション320からの要求を受けて、認可サーバ100からアクセストークンを取得するためのモジュールである。また取得したアクセストークンをクライアントに提供するトークン提供部としても機能する。なおアクセストークンは情報であるので、アクセストークン情報あるいは認可トークン情報あるいは単にトークン情報とも呼ぶ。
通信テスト開始通知部312は、クライアントアプリケーション320が登録を行うイベントを用意し、通信テスト開始指示に応じて前記イベントを発行して登録したクライアントアプリケーション320への通知を行うためのモジュールである。通信テスト開始指示は、それ自体が独立した指示として操作者により入力されてもよいし、或いは、操作者などにより入力される端末300の認可サーバ100への登録指示や、または認可サーバ100から受信した端末300の登録完了の応答、または登録完了後の通信テスト指示そのものであってもよいし、それらをトリガーとして発行されてもよい。
0020
通信テスト結果受信部313は、各クライアントアプリケーション320からの通信テスト完了結果を受け付けるモジュールである。また、通信テスト結果受信部313は通信テスト開始通知部312による通信テスト開始指示から一定時間までに通知を受け取れなかった場合、タイムアウトして通信テスト結果を失敗として処理する機能も備える。
通信テスト結果表示部314は、通信テスト結果受信部313が受信した各クライアントアプリケーション320からの通信テスト結果を取りまとめ、操作部210のLCDなどの表示デバイスに表示するモジュールである。
0021
[処理シーケンス]
図4A〜7を用いて、本実施形態にかかるシステムが通信テストを完了するまでに必要なステップを説明する。
図4Aでは、クライアントアプリケーション320を端末300にインストールした際の処理を示している。ここでは、クライアントアプリケーション320のインストール以前にトークンプロバイダアプリケーション310がすでにインストールされていることを前提とする。
0022
ステップS401では、まず、クライアントアプリケーション302が端末300にインストールされる。このときにクライアントアプリケーション320はトークンプロバイダアプリケーション310が提供するイベントに、イベントリスナとして自身を登録する(ステップS402)。これにより、トークンプロバイダアプリケーション310は、クライアントアプリケーション320への通知が可能となる。すなわち、ステップS402では、クライアントアプリケーション320は、トークンプロバイダアプリケーション310に自身をイベント通知先として登録しておく。
0023
本実施形態において、実際にトークンプロバイダアプリケーション310が端末登録の一連の処理において通信テストを実施する際のシーケンスを図4BのステップS403〜S408を用いて説明する。この手順は端末300が認可サーバ100からクライアントクレデンシャルを取得する必要がある場合に実行される。たとえば端末300が新たにインストールされた場合や、新たな認可サーバ100を利用する場合、クライアントクレデンシャルの有効期限が切れた場合などである。
0024
ステップS403では、まず、トークンプロバイダアプリケーション310が認可サーバ100へ端末300の登録を要求する。処理が成功すると、認可サーバ100は端末300が認証されたデバイスであることを示すためのクライアントクレデンシャルを返す。これにより、以降の処理でアクセストークンの取得が可能となる。
0025
ステップS404では、トークンプロバイダアプリケーション310が通信テスト開始イベントを発行し、ステップS402でイベントリスナ登録しているクライアントアプリケーションに対して通信テスト開始を通知する。本実施例では、クライアントアプリケーション320に通信テスト開始を通知する。
通信テストの内容はそれぞれのクライアントアプリケーション320固有である。またクライアントアプリケーション320は、アクセス先となるリソースサーバ200のURL、およびリソースへのアクセスに権限が必要な場合はその権限情報を保持できる。権限情報はたとえばアクセストークンでよく、いったん取得したなら有効である限り保持して利用できる。そこでアクセス権限が必要な通信テストを実施する場合、ステップS405において、クライアントアプリケーション320はトークンプロバイダアプリケーション310にアクセストークンを要求する。
0026
トークンプロバイダアプリケーション310は要求を受けると、ステップS403で取得したクライアントクレデンシャルを用いて認可サーバ100へアクセストークンの要求を行い、要求に応じてアクセストークンを取得する(S406)。
0027
ステップS407では、クライアントアプリケーション320がリソースサーバ200への通信テストを行い、通信テスト結果を取得する。通信テストはリソースサーバ200とクライアントアプリケーション320との間であらかじめ定めた手順で実施すればよい。そのための手順はリソースサーバ200とクライアントアプリケーション320それぞれに予めプログラムされていてよい。クライアントアプリケーション320は、通信テストに対するレスポンスが一定時間までに返ってこない場合には、タイムアウトして通信テスト失敗と判定する。
0028
通信テストが完了すると、ステップS408において、クライアントアプリケーション320はトークンプロバイダアプリケーション310に通信テスト結果を通知する。
0029
最後に、ステップS409では、トークンプロバイダアプリケーション310が、通信テスト開始を通知したすべてのクライアントアプリケーション320からのテスト結果を受け取り、表示デバイスへ結果を表示する。
0030
以上の構成及び手順により、クライアントアプリケーション320によるリソースサーバ100との間の通信テストを、個別のクライアントアプリケーション320に対する指示を行うことなく実施できる。より効率的に通信テストを行うには、たとえば端末300をネットワーク220に接続する前に、トークンプロバイダアプリケーション310をインストールし、その後に利用予定のクライアントアプリケーション320をインストールしておけばよい。その後端末300をネットワークに接続して、例えば操作者の明示的な指示などにより端末300を認可サーバ100に登録させれば、上記手順に従ってインストール済みのクライアントアプリケーション320すべてについて通信テストを実施できる。
0031
なお本実施形態においては、ステップS403からS404までの処理を一連のシーケンスで表現しているが、これに限るものではなく、ステップS404の処理はステップS403以後であれば、別の操作をトリガーに開始されても良い。
また、ステップS405においてクライアントアプリケーション320がトークンプロバイダアプリケーション310にアクセストークンを要求しているが、必ずしもこの方式である必要はなく、トークンプロバイダアプリケーション310があらかじめアクセストークンを取得しておき、ステップS404の通信テスト開始を通知する際にアクセストークンを渡す方式でも良い。
0032
●表示例
図5では、本実施形態において、通信テストを開始する際に表示されるトークンプロバイダアプリケーション310の画面の例を示している。
図5(A)は、操作者による端末の登録指示をトリガーにして通信テストを行う場合の画面の一例である。登録ボタン501が押下されると、トークンプロバイダアプリケーション310が端末300の認可サーバ100への登録を行ったのち、連続してクライアントアプリケーション320への通信テスト開始通知を行う図4(b)のシーケンスに沿った動作を行うものとなっている。
0033
一方で、図5(B)では、操作者が端末の登録指示とは別に通信テスト開始指示を行う場合の画面の一例である。この例は、ステップS403までの処理が完了している状態で表示される画面であり、通信テスト実施ボタン502を押下することでステップS404の処理が開始される。図5(B)の画面は、図5(A)の画面で端末の登録が完了した後に表示されてもよい。図5(B)の画面例では通信テストの実施は任意であり、ボタン503(OKボタンまたはキャンセルボタン)を押下することで通信テストを実施しないまま機器登録を終えることもできる。その場合には図5(B)の画面をその後に表示させて通信テストを実施することもできる。
0034
図6および図7は、通信テスト完了後のトークンプロバイダアプリケーション310の表示画面の一例を示している。図6は、結果の概要を示した画面の一例であり、端末の登録処理結果とともに通信テスト結果が表示されている。通信テストに失敗した端末がある場合には、そのことを示すメッセージが表示される。図6の表示に加えて、失敗した端末のIDなどを表示してもよい。さらにテスト結果詳細ボタン601を押下することで図7の例に示すような通信テスト結果詳細を閲覧することができる。
0035
図7の通信テスト結果詳細画面の例では、各クライアントアプリケーション320の通信テスト結果を閲覧することができ、通信テストに失敗したテストにおいては、そのエラーの詳細を確認できる。詳細画面にはテスト再試行ボタン701が配置されており、失敗した通信テストが存在する場合、その押下に応じて再度テストを実行しても良い。すなわち、図4のステップS407−S409を繰り返し行ってもよい。この場合には、たとえば図7の詳細画面にリストされたクライアントアプリケーションごとに選択用チェックボックスを設けるなどして、テスト対象のクライアントアプリケーションを選択できるようにしてもよい。そして再テストが指示されたなら、選択されたアプリケーションについて再テストを行ってもよい。あるいは、テストに失敗したクライアントアプリケーションのみを選択するためのチェックボックス等を設け、それがチェックされているなら、通信テストに失敗したクライアントアプリケーションを対象として再テストを実行してもよい。
0036
以上、本実施形態により、操作者はトークンプロバイダアプリケーション310上の端末300の登録操作からの一連の流れで、各クライアントアプリケーション320の通信テスト結果を確認することが可能となる。
0037
<第二の実施形態>
第一の実施形態では、図4Aに示すとおり、クライアントアプリケーション320がトークンプロバイダアプリケーション310インストール後にインストールされるクライアントアプリケーション(以下、アドオンアプリケーションと呼称する)であることを前提としていた。しかしながら、端末300にトークンプロバイダアプリケーション310がインストールされる以前からインストールされているクライアントアプリケーション(以下、プリインストールアプリケーションと呼称する)の場合、ステップS402で記載したイベントの登録を行うことができず、第一の実施形態では通信テストを実施できない。第二の実施形態では本課題を解決する。
0038
[モジュール構成]
図8は第二の実施形態に係るトークンプロバイダアプリケーション310のモジュール構成の例を示す図である。
ここでの説明は前述の実施例の図3とほぼ同様なため、異なる部分のみを以下、説明する。通信テスト指示部801は、通信テスト開始通知部312ではイベント登録されていないクライアントアプリケーション320に通信テストを指示するモジュールである。通信テスト指示部801は予めテスト対象のクライアントアプリケーション320のリストを保持し、通信テスト開始指示を受けると、リストに従ってクライアントアプリケーション320の通信テストを行い、結果を通信テスト結果表示部314へと渡す。通信テスト指示部801が保持するテスト対象のクライアントアプリケーション320のリストは、たとえばトークンプロバイダアプリケーション310が作成してもよい。その場合例えばトークンプロバイダアプリケーション310は、それがインストールされたときに、レジストリ等を参照してインストール済みのクライアントアプリケーション320の情報を取得し、取得した情報に基づいて作成してよい。あるいは操作者がユーザインターフェース上で対象のクライアントアプリケーションのIDなどを入力することで作成してもよい。
0039
[処理シーケンス]
本実施形態において、実際にトークンプロバイダアプリケーション310が端末登録の一連の処理において通信テストを実施する際のシーケンスを図9のステップS901〜S907を用いて説明する。本処理シーケンスは図4の処理シーケンスと並行して実施される。これにより、トークンプロバイダアプリケーション310とクライアントアプリケーション320のインストール順序に関わりなく、インストール済みのクライアントアプリケーション320について通信テストの自動化を実現できる。ただし、クライアントクレデンシャルの取得は、いずれか先に行った一度だけであってもよい。
ここで図9の処理の説明は前述の実施例の図4Bとほぼ同様なため、異なる部分のみを以下、説明する。
0040
ステップS902において、トークンプロバイダアプリケーション310は保持している指定テスト対象のクライアントアプリケーション一覧を取得する。
そして、ステップS903において、前記クライアントアプリケーション一覧にあるすべてのクライアントアプリケーション320に通信テスト開始処理を指示する。
0041
ステップS907において、すべてのクライアントアプリケーション320に対する通信テストの完了を受けて、図4Bの処理シーケンスによる通信テスト結果と合わせてイベント通知通信テスト結果を表示する。
このとき、前記クライアントアプリケーション一覧に記載されたクライアントアプリケーション320のうち、インストールされていない、あるいは、無効化されたクライアントアプリケーション320については、その結果を表示しない。
0042
本実施形態により、トークンプロバイダアプリケーション310よりも後にインストールされるアドオンアプリケーションのみならず、プリインストールアプリケーションも含め、一連の操作で、複数のインストール済みクライアントアプリケーションを対象として通信テストを行うことが可能となる。このため捜査が簡略化されて操作者の操作負担が軽減される。
0043
なお、端末300にインストールされたクライアントアプリケーション320すべてについて、通信テスト指示部801に登録してもよい。この場合には、例えば、トークンプロバイダアプリケーション310は、通信テスト実施の指示に応じてまずレジストリ等を参照してインストール済みのクライアントアプリケーションのリストを作成する。そしてその後に、図9に示したステップS903以降の処理を実行する。こうすることで、第2実施形態に示した構成及び手順により、インストールされたクライアントアプリケーション320すべてを対象として通信テストを実施できる。
0044
[その他の実施例]
本発明は、上述の実施形態の1以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける1つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、1以上の機能を実現する回路(例えば、ASIC)によっても実現可能である。
0045
100認可サーバ、200リソースサーバ、300端末、310トークンプロバイダアプリケーション、320クライアントアプリケーション、300 端末、311アクセストークン供給部、312通信テスト開始通知部、313 通信テスト結果受信部、314 通信テスト結果表示部、801 通信テスト指示部