(57)【要約】【課題】Ｗｅｂサービスを利用する異なるデバイス間のセキュアな連携を、デバイス間の認証を行うことなく可能にすることを目的とする。【解決手段】認証認可サーバーが情報処理装置からの登録要求に応じて、前記情報処理装置を前記認証認可サーバーの配下のリソースサーバーの一部として動的に登録し、認証認可サーバーから認可されたクライアント端末は、認証認可サーバーの配下のリソースサーバーへアクセスする方法と同様の方法で前記情報処理装置へアクセスする。【選択図】図７
2016009466.tif 000002
【特許請求の範囲】
【請求項１】
認証認可装置と、情報処理装置と、端末装置と、を含むＷｅｂサービスシステムであって、
前記認証認可装置は、
ネットワークを介して通信可能な前記情報処理装置からの登録要求に応じて、前記情報処理装置を配下の資源として登録する登録手段と、
前記情報処理装置に対して前記登録手段での登録の内容に対応するリソーストークンを送信する第１の送信手段と、
前記登録手段で登録された前記情報処理装置からのリソーストークンと認可トークンと処理情報とを含む検証要求に応じて、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否か検証する検証手段と、
を有し、
前記端末装置は、
ネットワークを介して通信可能な前記情報処理装置へ処理の依頼を行う際に、前記情報処理装置に対し前記認証認可装置から取得した認可トークンを送信する第２の送信手段を有し、
前記情報処理装置は、
前記情報処理装置を前記認証認可装置の配下の資源として登録するよう前記認証認可装置に対して要求する登録要求手段と、
前記端末装置からの処理要求に応じて、前記認証認可装置からのリソーストークンと前記端末装置からの認可トークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に対して送信し、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否かの検証を前記送信した情報に基づき行うよう前記認証認可装置に対して要求する検証要求手段と、
前記認証認可装置による前記検証の結果が肯定だった場合、前記端末装置から依頼された処理を実行する実行手段と、
を有するＷｅｂサービスシステム。
【請求項２】
前記登録手段は、前記登録要求を行ったユーザーのユーザー情報と前記情報処理装置の装置情報と前記認証認可装置の配下であることを示す権限情報とを含む識別情報に前記識別情報を一意に特定する特定情報を加えた登録情報を記憶手段に記憶することで、前記情報処理装置を配下の資源として登録し、
前記第１の送信手段は、前記特定情報をリソーストークンとして前記情報処理装置に送信し、
前記検証手段は、前記情報処理装置からのリソーストークンに対応する識別情報の権限情報が前記認証認可装置の配下の資源となっているか否か、前記情報処理装置からの認可トークンに対応する識別情報の権限情報に、前記端末装置により前記情報処理装置に対して依頼された処理情報に対応する処理が許可されているか否か、を検証し、前記検証の結果が共に肯定だった場合、前記リソーストークンに対応する識別情報のユーザー情報と前記認可トークンに対応する識別情報のユーザー情報とが同一であるか否かを検証する請求項１記載のＷｅｂサービスシステム。
【請求項３】
前記第２の送信手段は、前記処理の依頼を行うユーザー情報と、前記端末装置の装置情報と、前記ユーザー情報と装置情報とに対応する権限情報と、を一意に特定する前記認証認可装置から取得した特定情報を認可トークンとして前記情報処理装置に送信する請求項２記載のＷｅｂサービスシステム。
【請求項４】
前記登録要求手段は、登録要求を行うユーザーのユーザー情報と前記情報処理装置の装置情報とを送信し、前記送信した情報に基づき前記情報処理装置を前記認証認可装置の配下の資源として登録するよう要求し、
前記検証要求手段は、前記端末装置からの処理要求に応じて、前記認証認可装置から取得した認可トークンと前記端末装置から取得したリソーストークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に送信し、前記依頼に応じた前記情報処理装置での前記処理の実行が許可されているか否かを検証することを要求する請求項３記載のＷｅｂサービスシステム。
【請求項５】
前記認証認可装置は、
ユーザー情報とユーザーの所属情報とユーザーの権限情報とを対応付けたユーザー権限情報を保持するユーザー権限データを取得する取得手段を更に有し、
前記検証手段は、前記リソーストークンに対応する識別情報のユーザー情報と前記認可トークンに対応する識別情報のユーザー情報とが同一でなかった場合、前記取得手段で取得されたユーザー権限データの中の前記リソーストークンに対応するユーザー権限情報の所属情報と前記ユーザー権限データの中の前記認可トークンに対応するユーザー権限情報の所属情報とが同一か否か、前記リソーストークンに対応するユーザー権限情報のユーザー権限情報が管理者権限となっているか否か、を検証し、前記検証の結果が共に肯定だった場合、前記検証手段の結果を肯定であるとする請求項４記載のＷｅｂサービスシステム。
【請求項６】
前記情報処理装置は、
前記認証認可装置から送信された前記認可トークンに係るユーザー情報と前記リソーストークンに係るユーザー情報とが同一でなかった場合、処理を実行するユーザーを特定する特定手段と、
を更に有し、
前記実行手段は、前記特定手段で特定されたユーザーが前記端末装置から依頼された処理を実行する請求項１乃至５何れか１項記載のＷｅｂサービスシステム。
【請求項７】
前記特定手段は、ユーザーインターフェースに設定画面を表示し、操作者に前記設定画面を介した操作を促し、前記操作に基づいて、処理を実行するユーザーを特定する請求項６記載のＷｅｂサービスシステム。
【請求項８】
ネットワークを介して通信可能な情報処理装置からの登録要求に応じて、前記情報処理装置を配下の資源として登録する登録手段と、
前記情報処理装置に対して前記登録手段での登録の内容に対応するリソーストークンを送信する送信手段と、
前記登録手段で登録された前記情報処理装置からのリソーストークンと認可トークンと処理情報とを含む検証要求に応じて、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否か検証する検証手段と、
を有する認証認可装置。
【請求項９】
前記登録手段は、前記登録要求を行ったユーザーのユーザー情報と前記情報処理装置の装置情報と前記認証認可装置の配下であることを示す権限情報とを含む識別情報に前記識別情報を一意に特定する特定情報を加えた登録情報を記憶手段に記憶することで、前記情報処理装置を配下の資源として登録し、
前記送信手段は、前記特定情報をリソーストークンとして前記情報処理装置に送信し、
前記検証手段は、前記情報処理装置からのリソーストークンに対応する識別情報の権限情報が前記認証認可装置の配下の資源となっているか否か、前記情報処理装置からの認可トークンに対応する識別情報の権限情報に、端末装置により前記情報処理装置に対して依頼された処理情報に対応する処理が許可されているか否か、を検証し、前記検証の結果が共に肯定だった場合、前記リソーストークンに対応する識別情報のユーザー情報と前記認可トークンに対応する識別情報のユーザー情報とが同一であるか否かを検証する請求項８記載の認証認可装置。
【請求項１０】
ユーザー情報とユーザーの所属情報とユーザーの権限情報とを対応付けたユーザー権限情報を保持するユーザー権限データを取得する取得手段を更に有し、
前記検証手段は、前記リソーストークンに対応する識別情報のユーザー情報と前記認可トークンに対応する識別情報のユーザー情報とが同一でなかった場合、前記取得手段で取得されたユーザー権限データの中の前記リソーストークンに対応するユーザー権限情報の所属情報と前記ユーザー権限データの中の前記認可トークンに対応するユーザー権限情報の所属情報とが同一か否か、前記リソーストークンに対応するユーザー権限情報のユーザー権限情報が管理者権限となっているか否か、を検証し、前記検証の結果が共に肯定だった場合、前記検証手段の結果を肯定であるとする請求項９記載の認証認可装置。
【請求項１１】
ネットワークを介して通信可能な認証認可装置の配下の資源として情報処理装置を登録するよう前記認証認可装置に対して要求する登録要求手段と、
ネットワークを介して通信可能な端末装置からの処理要求に応じて、前記認証認可装置からのリソーストークンと前記端末装置からの認可トークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に対して送信し、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否かの検証を前記送信した情報に基づき行うよう前記認証認可装置に対して要求する検証要求手段と、
前記認証認可装置による前記検証の結果が肯定だった場合、前記端末装置から依頼された処理を実行する実行手段と、
を有する情報処理装置。
【請求項１２】
前記登録要求手段は、登録要求を行うユーザーのユーザー情報と前記情報処理装置の装置情報とを送信し、前記送信した情報に基づき前記情報処理装置を前記認証認可装置の配下の資源として登録するよう前記認証認可装置に対して要求し、
前記検証要求手段は、前記端末装置からの処理要求に応じて、前記認証認可装置からの認可トークンと前記端末装置からのリソーストークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に送信し、前記情報処理装置での前記処理の実行が許可されているか否かを検証することを要求する請求項１１記載の情報処理装置。
【請求項１３】
前記認証認可装置から送信された前記認可トークンに係るユーザー情報と前記リソーストークンに係るユーザー情報とが同一でなかった場合、処理を実行するユーザーを特定する特定手段と、
を更に有し、
前記実行手段は、前記特定手段で特定されたユーザーが前記端末装置から依頼された処理を実行する請求項１１又は１２記載の情報処理装置。
【請求項１４】
前記情報処理装置は、画像を形成する画像形成装置である請求項１１乃至１３何れか１項記載の情報処理装置。
【請求項１５】
認証認可装置と、情報処理装置と、端末装置と、を含むＷｅｂサービスシステムにおける情報処理方法であって、
前記情報処理装置が、前記情報処理装置を、ネットワークを介して通信可能な前記認証認可装置の配下の資源として登録するよう前記認証認可装置に対して要求する登録要求ステップと、
前記認証認可装置が、前記情報処理装置からの登録要求に応じて、前記情報処理装置を配下の資源として登録する登録ステップと、
前記情報処理装置に対して前記登録の内容に対応するリソーストークンを送信する第１の送信ステップと、
前記端末装置が、ネットワークを介して通信可能な前記情報処理装置へ処理の依頼を行う際に、前記情報処理装置に対し前記認証認可装置から取得した認可トークンを送信する第２の送信ステップと、
前記情報処理装置が、前記端末装置からの処理要求に応じて、前記認証認可装置からのリソーストークンと前記端末装置からの認可トークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に対して送信し、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否かの検証を前記送信した情報に基づき行うよう前記認証認可装置に対して要求する検証要求ステップと、
前記認証認可装置が、前記登録ステップで登録された前記情報処理装置からのリソーストークンと認可トークンと処理情報とを含む検証要求に応じて、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否か検証する検証ステップと、
前記情報処理装置が、前記認証認可装置による前記検証の結果が肯定だった場合、前記端末装置から依頼された処理を実行する実行ステップと、
を含む情報処理方法。
【請求項１６】
認証認可装置が実行する情報処理方法であって、
ネットワークを介して通信可能な情報処理装置からの登録要求に応じて、前記情報処理装置を配下の資源として登録する登録ステップと、
前記情報処理装置に対して前記登録の内容に対応するリソーストークンを送信する送信ステップと、
前記登録ステップで登録された前記情報処理装置からのリソーストークンと認可トークンと処理情報とを含む検証要求に応じて、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否か検証する検証ステップと、
を含む情報処理方法。
【請求項１７】
情報処理装置が実行する情報処理方法であって、
ネットワークを介して通信可能な認証認可装置の配下の資源として前記情報処理装置を登録するよう前記認証認可装置に対して要求する登録要求ステップと、
ネットワークを介して通信可能な端末装置からの処理要求に応じて、前記認証認可装置からのリソーストークンと前記端末装置からの認可トークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に対して送信し、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否かの検証を前記送信した情報に基づき行うよう前記認証認可装置に対して要求する検証要求ステップと、
前記認証認可装置による前記検証の結果が肯定だった場合、前記端末装置から依頼された処理を実行する実行ステップと、
を含む情報処理方法。
【請求項１８】
コンピューターに、
ネットワークを介して通信可能な情報処理装置からの登録要求に応じて、前記情報処理装置を配下の資源として登録する登録ステップと、
前記情報処理装置に対して前記登録の内容に対応するリソーストークンを送信する送信ステップと、
前記登録ステップで登録された前記情報処理装置からのリソーストークンと認可トークンと処理情報とを含む検証要求に応じて、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否か検証する検証ステップと、
を実行させるためのプログラム。
【請求項１９】
コンピューターに、
ネットワークを介して通信可能な認証認可装置の配下の資源として前記コンピューターを登録するよう前記認証認可装置に対して要求する登録要求ステップと、
ネットワークを介して通信可能な端末装置からの処理要求に応じて、前記認証認可装置からのリソーストークンと前記端末装置からの認可トークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に対して送信し、前記コンピューターでの前記処理情報に対応する処理の実行が許可されているか否かの検証を前記送信した情報に基づき行うよう前記認証認可装置に対して要求する検証要求ステップと、
前記認証認可装置による前記検証の結果が肯定だった場合、前記端末装置から依頼された処理を実行する実行ステップと、
を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂサービスシステム、認証認可装置、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
近年、インターネット上で提供されるクラウドサービスを携帯端末、デジタル家電、オフィス機器といった各種デバイスから利用するサービスの普及が進んでいる。また、一人のユーザーが複数のデバイスを保持し、様々なクラウドサービスを利用するユースケースも増えてきている。更には、携帯端末で提供されるアプリケーションでクラウドサービスを利用し何らかの処理を行い、前記処理の結果に基づいて携帯端末から別のデバイスのアプリケーションを利用するといった形態も普及している。前記形態において、クラウドサービスとデバイスの処理だけでなく、デバイスアプリケーション間での処理連携が必要となる。
一人のユーザーが複数のデバイスを利用し、更にはデバイス間でも機能の連携があるとき、ユーザーは、各デバイスからクラウドサービスを利用するためのＩＤとパスワードといった認証情報の入力を行う必要がある。更には、ユーザーは、デバイスアプリケーション間の連携のためにＩＤとパスワードといった認証情報の入力を行う必要がある。
特許文献１では、同一端末内での複数アプリケーション間でのシングルサインオン技術が述べられている。特許文献１の技術は、同一端末内のアプリケーションであるという条件と、それぞれのアプリケーションを事前に設定しておくという条件と、を必要とする。前記２つの条件を満たすことで、特許文献１の技術は、アプリケーション間での認証を省略し、クラウドサービスへアクセスするための情報の共有を行い、クラウド・アプリケーション間の認証を簡易にしている。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】国際公開第０９／１０７２１９号パンフレット
【発明の概要】
【発明が解決しようとする課題】
【０００４】
複数デバイスを利用したクラウドサービス連携では、各デバイスがクラウドサービスを利用するための各デバイスへの認証情報の入力だけでなく、各デバイスアプリケーション間の連携をするための認証情報の入力も必要となる。したがって、ユーザーは、連携機能を利用するため多数の設定を行う必要があり、不便である。特許文献１の方法では、アプリケーションが同じ端末上にあれば、事前に前記アプリケーションで連携可能設定をしておくことで、アプリケーション間連携が実現可能となる。しかし、アプリケーションが別々のデバイスで動作している場合では、先行技術の方法ではアプリケーション同士の通信をセキュアにすることができず、認証を省略できない。また、アプリケーション同士の事前設定も必要なため、前記事前設定の作業も面倒である。
そこで、本発明は、Ｗｅｂサービスを利用する異なるデバイス間のセキュアな連携を、デバイス間の認証を行うことなく可能にすることを目的とする。
【課題を解決するための手段】
【０００５】
そこで、本発明のＷｅｂサービスシステムは、認証認可装置と、情報処理装置と、端末装置と、を含むＷｅｂサービスシステムであって、前記認証認可装置は、ネットワークを介して通信可能な前記情報処理装置からの登録要求に応じて、前記情報処理装置を配下の資源として登録する登録手段と、前記情報処理装置に対して前記登録手段での登録の内容に対応するリソーストークンを送信する第１の送信手段と、前記登録手段で登録された前記情報処理装置からのリソーストークンと認可トークンと処理情報とを含む検証要求に応じて、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否か検証する検証手段と、を有し、前記端末装置は、ネットワークを介して通信可能な前記情報処理装置へ処理の依頼を行う際に、前記情報処理装置に対し前記認証認可装置から取得した認可トークンを送信する第２の送信手段を有し、前記情報処理装置は、前記情報処理装置を前記認証認可装置の配下の資源として登録するよう前記認証認可装置に対して要求する登録要求手段と、前記端末装置からの処理要求に応じて、前記認証認可装置からのリソーストークンと前記端末装置からの認可トークンと前記端末装置から依頼された処理の処理情報とを前記認証認可装置に対して送信し、前記情報処理装置での前記処理情報に対応する処理の実行が許可されているか否かの検証を前記送信した情報に基づき行うよう前記認証認可装置に対して要求する検証要求手段と、前記認証認可装置による前記検証の結果が肯定だった場合、前記端末装置から依頼された処理を実行する実行手段と、を有する。
【発明の効果】
【０００６】
本発明によれば、Ｗｅｂサービスを利用する異なるデバイス間のセキュアな連携を、デバイス間の認証を行うことなく可能にすることができる。
【図面の簡単な説明】
【０００７】
【図１】システム構成の一例を示す図である。
【図２】各装置のハードウェア構成の一例を示す図である。
【図３】各装置のソフトウェアモジュール構成の一例を示す図である。
【図４】画像形成装置を認証認可サーバーへ登録する処理の一例を示す図である。
【図５】画面の一例を示す図である。
【図６】クライアント端末によるリソースサーバーの利用処理の一例を示す図である。
【図７】クライアント端末による画像形成装置の利用処理の一例を示す図である。
【図８】認証認可サーバーでのユーザー情報特定処理の一例を示すフローチャートである。
【図９】認証認可サーバーでのトークン検証処理のフローチャートである。
【図１０】画像形成装置でのユーザー特定処理のフローチャートである。
【図１１】ユーザー特定処理における設定のための画面の一例を示す図である。
【発明を実施するための形態】
【０００８】
以下、本発明の実施形態について図面に基づいて説明する。
＜実施形態＞
【０００９】
本実施形態においては、インターネット上のサーバーに印刷サービスが設置されていることを想定している。また、印刷サービスは、携帯端末から印刷データを受け取り、変換・保存する機能、任意の携帯端末より印刷データと画像形成装置を指定して印刷する機能等を提供することを想定している。
以降、前記印刷サービス等のインターネット上で機能を提供しているサービスを、リソースサービスとする。
また、本実施形態においては、画像形成装置上にインストールされた印刷アプリケーションと携帯端末上にインストールされた印刷アプリケーションとリソースサービスとが連携することを想定している。前記印刷アプリケーション等のリソースサービスと連携するアプリケーションをリソースサービス連携アプリケーションとする。
本実施の形態における権限の移譲処理には、ＯＡｕｔｈの仕組みが利用される。ＯＡｕｔｈでは、ユーザーから移譲された権限の証明するための情報として、トークンと呼ばれる情報が利用される。ＯＡｕｔｈの仕組みにおいては、例えば、携帯端末がリソースサーバーのリソースを利用する際、携帯端末はリソースサーバーに対して認証認可サーバーから取得したトークンを含むリソース要求を行う。前記リソースサーバーと認証認可サーバーとは、前記要求に付随する情報に含まれるトークンに基づいて、前記要求の処理を許可するか否かを判定する。前記判定の結果が許可である場合、リソースサーバーは、前記要求の処理を実行する。
更に、本実施形態において、画像形成装置や携帯端末に対応したサーバー上の仮想的なユーザーをデバイスクライアントとする。
以下では、例えば「Ａであるか否かの検証」において検証結果が「Ａである」ことを「検証結果が正しい」、又は「検証結果が肯定である」と表現する。
【００１０】
図１は、本実施形態に係る情報処理システムのシステム構成の一例を示す図である。前記情報処理システムは、Ｗｅｂサービスシステムの一例である。
ＷＡＮ１００は、Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋであり、本実施形態ではＷｏｒｌｄ  Ｗｉｄｅ  Ｗｅｂ（ＷＷＷ）システムが構築されている。ＬＡＮ１０１は、各構成要素を接続するＬｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋである。認証認可サーバー１１０は、ユーザーの認証、ＯＡｕｔｈの仕組み等を実現するための認証認可サーバーである。リソースサーバー１２０には、印刷サービスが設置されている。また、本実施形態において各サーバーは、１台ずつ設置されているが複数台で構成されていてもよく、例えば複数のサーバーで構成される認証認可サーバーシステムとして提供されてもよい。クライアント端末１５０は、例えばスマートフォンといったモバイル端末である。スマートフォンには、Ｗｅｂブラウザやリソース連携アプリケーションがインストールされている。画像形成装置１４０には、１つ又は複数のリソースサービス連携アプリケーションがインストールされている。ユーザーは、クライアント端末１５０、画像形成装置１４０のリソースサービス連携アプリケーション等を介してリソースサービスを利用する。
認証認可サーバー１１０、リソースサーバー１２０、画像形成装置１４０、クライアント端末１５０は、それぞれＷＡＮ１００及びＬＡＮ１０１を介して接続されている。なお認証認可サーバー１１０、リソースサーバー１２０、画像形成装置１４０、クライアント端末１５０は、それぞれ個別のＬＡＮ上に構成されていてもよいし、同一のＬＡＮ上に構成されていてもよい。認証認可サーバー１１０、リソースサーバー１２０は、同一のサーバー上に構成されていてもよい。
【００１１】
図２は、認証認可サーバー１１０、リソースサーバー１２０、画像形成装置１４０、クライアント端末１５０等を抽象化した装置２００のハードウェア構成の一例を示す図である。なお、装置２００を認証認可サーバー１１０、リソースサーバー１２０、クライアント端末１５０に適用した場合、印刷部Ｉ／Ｆ２５０、スキャナ部Ｉ／Ｆ２５１、印刷部２５２、スキャナ部２５３はハードウェア構成として含まれない。
ＣＰＵ２３１は、ＲＯＭ２３３のプログラム用ＲＯＭに記憶された、或いはハードディスク（ＨＤ）等の外部メモリ２４１からＲＡＭ２３２にロードされたＯＳやアプリケーション等のプログラムを実行する。また、ＣＰＵ２３１は、システムバス２３４に接続される各ブロックを制御する。ＯＳは、コンピューター上で稼動するオペレーティングシステムの略語であり、以下オペレーティングシステムのことをＯＳとする。図４、図６及び図７で後述する各シーケンスの処理は、ＣＰＵ２３１がＲＡＭ２３２にロードされたプログラムを実行することにより実現できる。ＲＡＭ２３２は、ＣＰＵ２３１の主メモリ、ワークエリア等として機能する。ＣＰＵ２３１は、操作部Ｉ／Ｆ２３５を介して操作部２３９からの入力を制御する。ＣＰＵ２３１は、ＣＲＴコントローラ（ＣＲＴＣ）２３６を介して、ＣＲＴディスプレイ２４０の表示を制御する。ＣＰＵ２３１は、ディスクコントローラ（ＤＫＣ）２３７を介して各種データを記憶するハードディスク（ＨＤ）等の外部メモリ２４１におけるデータアクセスを制御する。ＣＰＵ２３１は、ネットワークコントローラ（ＮＣ）２３８を制御することにより、ＷＡＮ１００若しくはＬＡＮ１０１を介して接続されたサーバーコンピューターや他の機器との通信制御処理を実行する。
【００１２】
画像形成装置１４０は、印刷部２５２やスキャナ部２５３等のハードウェアを保持する。画像形成装置１４０のＣＰＵ２３１は、印刷データを、印刷部Ｉ／Ｆ２５０を通して、印刷部２５２に出力情報として出力する。画像形成装置１４０のＣＰＵ２３１は、スキャナ部２５３にて読み取ったスキャンデータをスキャナ部Ｉ／Ｆ２５１経由で取得する。
認証認可サーバー１１０のＣＰＵ２３１が、認証認可サーバー１１０のＲＯＭ２３３又は外部メモリ２４１に記憶されたプログラムに基づき処理を実行することで、後述する認証認可サーバー１１０の機能及びフローチャート、シーケンスの処理が実現される。
リソースサーバー１２０のＣＰＵ２３１が、リソースサーバー１２０のＲＯＭ２３３又は外部メモリ２４１に記憶されたプログラムに基づき処理を実行することで、後述するリソースサーバー１２０の機能及びシーケンスの処理が実現される。
画像形成装置１４０のＣＰＵ２３１が、画像形成装置１４０のＲＯＭ２３３又は外部メモリ２４１に記憶されたプログラムに基づき処理を実行することで、後述の画像形成装置１４０の機能及び後述のフローチャート、シーケンスの処理が実現される。
クライアント端末１５０のＣＰＵ２３１が、クライアント端末１５０のＲＯＭ２３３又は外部メモリ２４１に記憶されたプログラムに基づき処理を実行することで、後述のクライアント端末１５０の機能及び後述のシーケンスの処理が実現される。
【００１３】
図３は、各装置のソフトウェアモジュール構成の一例を示す図である。
認証認可サーバー１１０は、ログインＵＩモジュール３１０を持つ。リソースサーバー１２０は、リソースサーバーモジュール３２０を持つ。
クライアント端末１５０は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ３５０と、リソースサーバー１２０と連携するためのリソースサービス連携アプリケーションと、を持つ。
画像形成装置１４０は、ＣＰＵ２３１がＲＯＭ２３３、或いは外部メモリ２４１に記憶されたＯＳを実行することで各アプリケーションを制御する。ＯＳ３４２は、オペレーティングシステムである。ＯＳは、リアルタイムＯＳであってもよいし、Ｌｉｎｕｘ（登録商標）等の汎用ＯＳであってもよい。仮想マシン３４１は、例えばＪａｖａ（登録商標）ＶＭである。仮想マシン３４１は、ＣＰＵ２３１によりＯＳ３４２を介して制御されるアプリケーションとして動作する仮想的なアプリケーション実行環境である。アプリケーション管理フレームワーク３４０は、仮想マシン３４１が提供するアプリケーション実行環境上で動作する管理対象のアプリケーションのライフサイクルを管理する機能と、前記機能を制御するＩ／Ｆと、を備えている。更に、アプリケーション管理フレームワーク３４０は、各アプリケーション間で処理要求を仲介するためのＩ／Ｆ公開機能を備えている。ライフサイクルは、アプリケーションのインストール、起動、停止、アンインストール等のアプリケーションの状態を示すものである。本実施形態におけるアプリケーション管理フレームワーク３４０は、ＯＳＧｉ（Ｏｐｅｎ  Ｓｅｒｖｉｃｅｓ  Ｇａｔｅｗａｙ  ｉｎｉｔｉａｔｉｖｅ）アライアンスで規定されたＯＳＧｉ（登録商標）として説明する。
【００１４】
認証認可サーバー連携クライアント３４６、リソースサービス連携アプリケーション３４７、ローカルログインアプリケーション３４５は、仮想マシン３４１が提供するアプリケーション実行環境にて動作する各種アプリケーションである。また、前記アプリケーションは、アプリケーション管理フレームワーク３４０にてライフサイクルを管理されている。アプリケーション管理アプリケーション３４３は、アプリケーション管理フレームワーク３４０が公開するライフサイクル管理用の制御Ｉ／Ｆを介して、ユーザーからの各種アプリケーションのインストール操作、開始リクエスト操作等を受け付け実行する。画像形成装置１４０は、認証認可サーバー連携クライアント３４６、リソースサービス連携アプリケーション３４７、ローカルログインアプリケーション３４５を既定で持つことができる。また、画像形成装置１４０は、認証認可サーバー連携クライアント３４６、リソースサービス連携アプリケーション３４７、ローカルログインアプリケーション３４５を、後からインストールすることもできる。画像形成装置１４０は、前記インストールを、アプリケーション管理アプリケーション３４３及びアプリケーション管理フレームワーク３４０を介して行うことができる。更に、画像形成装置１４０は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ３４８を備える。
クライアント端末１５０は、ＷＷＷを利用するためのユーザーエージェントであるＷｅｂブラウザ３５０とリソースサービス連携アプリケーション３５１とを持つ。
【００１５】
認証認可サーバー１１０が外部メモリ２４１にて記憶するデータテーブルに関して説明する。前記データテーブルは、認証認可サーバー１１０の外部メモリ２４１ではなく、ＬＡＮ１０１を介して通信可能に構成された別のサーバーに記憶するようにすることもできる。
認証認可サーバー１１０のＣＰＵ２３１は、ユーザー管理テーブルに記憶することで、ユーザーの情報を管理する。ユーザー管理テーブルは、ユーザーを一意に識別する「ユーザーＩＤ」、ユーザーが所属するテナントを一意に識別する「テナントＩＤ」、ユーザーが通常のユーザーかデバイスとしての仮想ユーザーかを識別する「種別」を含む。前記テナントは、所属情報の一例である。ユーザー管理テーブルは、更に、ユーザーの「メールアドレス」、ユーザーのシステム上の役割を管理する「ロール」を含む。「ロール」にはテナントの管理者を示すロール、一般者を表すロール、印刷サービスを利用するためのロール等が設定される。「ロール」に管理者が設定されていることは、管理者権限が設定されていることの一例である。「ユーザーＩＤ」、「テナントＩＤ」、「ロール」の組みは、ユーザー権限情報の一例である。ユーザー管理テーブルは、ユーザー権限データの一例である。
【表１】
2016009466.tif 000003
【００１６】
認証認可サーバー１１０のＣＰＵ２３１は、テナント管理テーブルに記憶することで、テナントの情報を管理する。テナントは、サービスの利用契約を結んだ顧客ごとに割り当てられる管理単位である。ユーザーの管理やデータの管理は、テナント単位で行われる。テナント管理テーブルの「テナントＩＤ」は、ユーザー管理テーブルで示したものと同様であり、「テナント名」は、例えばテナントを契約している会社の名称が設定される。
【表２】
2016009466.tif 000004
【００１７】
認証認可サーバー１１０のＣＰＵ２３１は、クライアント管理テーブルに記憶することで、デバイスクライアントの情報を管理する。クライアント管理テーブルは、「クライアントＩＤ」、「クライアント名」「リダイレクトＵＲＬ」「シリアル番号」を含む。「クライアントＩＤ」は、ユーザー管理テーブルの「ユーザーＩＤ」と関連付いており、互いに参照可能となっている。「クライアント名」、「リダイレクトＵＲＬ」は、ＯＡｕｔｈのシーケンスで利用される値である。「シリアル番号」は、デバイスクライアントを一意に識別可能な値である。認証認可サーバー１１０は、前記クライアントＩＤを基に接続元の画像形成装置１４０やクライアント端末１５０を一意に識別することが可能となる。
【表３】
2016009466.tif 000005
【００１８】
認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに記憶することで、ＯＡｕｔｈのためのトークンを管理する。認可トークン管理テーブルは、「認可トークンＩＤ」、「種別」、「スコープ」、「有効期限」、「リフレッシュトークンＩＤ」、「リフレッシュ期限」、「クライアントＩＤ」、「ユーザーＩＤ」を含む。認可トークン管理テーブルの処理詳細については、図４、６、８、９で後述する。認証認可サーバー１１０のＣＰＵ２３１は、ユーザーによる操作部２３９への操作等に基づいて、認可トークン管理テーブルのそれぞれの値を設定してもよい。「クライアントＩＤ」は、装置情報の一例である。「ユーザーＩＤ」は、ユーザー情報の一例である。「スコープ」、「クライアントＩＤ」、「ユーザーＩＤ」の組みは、識別情報の一例である。「認可トークンＩＤ」は、識別情報を一意に特定する特定情報の一例である。前記識別情報に前記特定情報を加えたものは、登録情報の一例である。
【表４】
2016009466.tif 000006
【００１９】
認証認可サーバー１１０のＣＰＵ２３１は、スコープ管理テーブルに記憶することで、ＯＡｕｔｈのためのスコープを管理する。スコープ管理テーブルは、「スコープ」、「ロール」を含む。認証認可サーバー１１０のＣＰＵ２３１は、スコープ管理テーブルからスコープに対応する「ロール」の値を参照することで、前記スコープに対応する処理の内容を取得できる。
【表５】
2016009466.tif 000007
以上が、認証認可サーバー１１０が外部メモリ２４１にて記憶するデータテーブルに関する説明である。
【００２０】
次に、画像形成装置１４０やクライアント端末１５０が外部メモリ２４１に記憶するデータテーブルの説明を行う。
画像形成装置１４０、クライアント端末１５０のＣＰＵ２３１は、デバイスユーザー管理テーブルに記憶することで、画像形成装置１４０やクライアント端末１５０のユーザーを管理する。例えば、画像形成装置１４０へのアクセスの際には、画像形成装置１４０のＣＰＵ２３１は、画像形成装置１４０に入力された「ユーザーＩＤ」と「パスワード」との組みが、前記デバイスユーザー管理テーブル内に存在する場合、認証を行う。また、画像形成装置１４０、クライアント端末１５０のＣＰＵ２３１は、前記デバイスユーザー管理テーブルの「権限情報」に基づいて、アクセス制御を行う。なお、クライアント端末１５０では、画像形成装置１４０と同様に複数のユーザーを管理する場合、ユーザーを管理しない場合等が想定される。ユーザーを管理しない場合、デバイスユーザー管理テーブルの「ユーザーＩＤ」や「権限情報」は存在しない場合がある。また、本実施形態では、認証方法は、ユーザーＩＤとパスワードによる認証を想定しているが、ＩＣカード認証、指紋といった生体認証、パターンロック認証といった異なる認証方法であってもよい。認証方法がユーザーＩＤとパスワードとによる認証ではない場合、デバイスユーザー管理テーブルには「パスワード」の代わりに前記認証方法の情報が管理される。更に、クライアント端末１５０でユーザー管理をしない場合には、認証なしといった構成でもよく、デバイスユーザー管理テーブルは存在しない場合がある。本実施形態では画像形成装置１４０やクライアント端末１５０での認証方法は問わず、デバイスの利用者が前記デバイス内で一意に識別できさえすればよい。
【表６】
2016009466.tif 000008
【００２１】
画像形成装置１４０、クライアント端末１５０のＣＰＵ２３１は、デバイスクライアント管理テーブルに記憶することで、デバイスクライアントの情報を管理する。デバイスクライアント管理テーブルは、「クライアントＩＤ」、「シークレット」、「エンドポイントＵＲＬ」、「リダイレクトＵＲＬ」を含む。「クライアントＩＤ」、「シークレット」は、予め認証認可サーバー１１０によって発行され、ユーザー管理テーブルに記憶された「ユーザーＩＤ」、「パスワード」にそれぞれ対応している。更に、「リダイレクトＵＲＬ」は、認証認可サーバー１１０のクライアント管理テーブルに登録されている情報と同一のデータとなっている。デバイスクライアント管理テーブルへの情報の登録方法としては、例えば、画像形成装置１４０やクライアント端末１５０がＬＡＮ１０１、ＷＡＮ１００を介してオンラインで登録する方法でもよい。また、画像形成装置１４０、クライアント端末１５０のＣＰＵ２３１は、ユーザーによる操作部２３９への操作に基づいて、デバイスクライアント管理テーブルのそれぞれの値を設定してもよい。なお、「エンドポイントＵＲＬ」は、認証認可サーバー１１０が公開するＯＡｕｔｈのためのエンドポイントのＵＲＬである。
【表７】
2016009466.tif 000009
【００２２】
画像形成装置１４０、クライアント端末１５０のＣＰＵ２３１は、デバイストークン管理テーブルに記憶することで、認証認可サーバー１１０によって発行されたトークンを管理する。デバイストークン管理テーブルは、「ユーザーＩＤ」、「トークンＩＤ」、「種別」、「リフレッシュトークンＩＤ」、「認証認可サーバーユーザーＩＤ」を含む。デバイストークン管理テーブルの処理詳細については、図４、６、７で後述する。ユーザーを管理していないクライアント端末１５０では、「ユーザーＩＤ」の情報は存在しない。「ユーザーＩＤ」の情報が存在しない場合、一般的には、クライアント端末１５０のＣＰＵ２３１は、デバイストークン管理テーブルをリソースサービス連携アプリケーション３５１の固有の情報として管理する。
【表８】
2016009466.tif 000010
【００２３】
以上が、画像形成装置１４０やクライアント端末１５０が外部メモリ２４１に記憶するデータテーブルの説明である。
【００２４】
ここで、画像形成装置１４０をリソースサーバー１２０の一部として認証認可サーバー１１０に対して登録を行うリソース登録処理を説明する。前記処理により画像形成装置１４０は、仮想的にリソースサーバー１２０の一部となる。したがって、クライアント端末１５０は、リソースサーバー１２０にアクセスする方法と同様の方法で画像形成装置１４０のリソースサービス連携アプリケーション３４７にアクセス可能となる。
【００２５】
リソース登録処理に関する本実施形態のシーケンスを図４、図５を用いて説明する。
前記シーケンスは、ユーザーが画像形成装置１４０にて一度だけ行う操作であり、一般的なＯＡｕｔｈの認可トークンを取得するシーケンスと同様の処理を利用しリソース登録処理を実現している。
図４は、画像形成装置を認証認可サーバーへ登録する処理の一例を示す図である。
Ｓ４０１において、画像形成装置１４０のＣＰＵ２３１は、ユーザーによる画像形成装置１４０へのローカルログインアプリケーション３４５を介したログイン操作を検知し、前記操作に基づき前記ユーザーを画像形成装置１４０へログインさせる。本実施形態では、画像形成装置１４０のＣＰＵ２３１は、前記ユーザーにより入力されたユーザーＩＤとパスワードとを、デバイスユーザー管理テーブルにて検証し、ログイン処理を行う。
Ｓ４０２において、画像形成装置１４０のＣＰＵ２３１は、例えば「ユーザーＩＤ」が「Ｕｓｅｒ」のユーザーがログインした場合、ローカルログインアプリケーション３４５を介して、「Ｕｓｅｒ」を含むログインコンテキストを生成する。画像形成装置１４０のＣＰＵ２３１は、前記ログインコンテキストを、アプリケーション管理フレームワーク３４０を介して各アプリケーションから取得可能なよう、ＲＡＭ２３２に格納する。
Ｓ４０３において、画像形成装置１４０のＣＰＵ２３１は、ユーザーによるＷｅｂブラウザ３４８への操作に基づいて、認証認可サーバー連携クライアント３４６の認証認可サーバー１１０へのリソース登録の開始のためのＵＲＬへアクセスする。
画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、リソース登録の開始を検知したら、デバイスクライアント管理テーブルの「エンドポイントＵＲＬ」に記載のＵＲＬを取得する。
【００２６】
Ｓ４０４において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、前記ＵＲＬに対してＯＡｕｔｈの認可リクエストをするようＷｅｂブラウザ３４８にリダイレクト要求する。前記認可リクエストに付随する情報は、デバイスクライアント管理テーブルの「クライアントＩＤ」、「リダイレクトＵＲＬ」の情報を含む。また、前記認可リクエストに付随する情報は、認可を受けたい権限範囲を示す情報として「Ｒｅｓｏｕｒｃｅ」の値が設定された「スコープ」の情報を含む。前記認可リクエストは、登録要求の処理の一例である。
Ｓ４０５において、画像形成装置１４０のＣＰＵ２３１は、前記認可リクエストを受け付けた認証認可サーバー１１０から送信される図５ａに示すログイン画面５０１をＷｅｂブラウザ３４８に示す。
Ｓ４０６において、画像形成装置１４０のＣＰＵ２３１は、ユーザーによるＷｅｂブラウザ３４８に示されたログイン画面５０１へのユーザーＩＤとパスワードとの入力を受け付ける。画像形成装置１４０のＣＰＵ２３１は、Ｗｅｂブラウザ３４８を介して示された前記ユーザーＩＤと前記パスワードとを認証認可サーバーへと送信する。認証認可サーバー１１０のＣＰＵ２３１は、前記ユーザーＩＤ、前記パスワードの組みがユーザー管理テーブルに登録されている情報と合致するか否かを検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記ユーザーＩＤと前記パスワードとの組みがユーザー管理テーブルに登録されている情報と合致する場合、ユーザーＩＤと紐づいた認証情報を生成する。認証認可サーバー１１０のＣＰＵ２３１は、認可リクエストに含まれている「クライアントＩＤ」と「リダイレクトＵＲＬ」との組みが、クライアント管理テーブルに登録された情報と合致するか否か、「スコープ」が「Ｒｅｓｏｕｒｃｅ」であるか否かを検証する。
【００２７】
Ｓ４０７において、認証認可サーバー１１０のＣＰＵ２３１は、前記「クライアントＩＤ」と前記「リダイレクトＵＲＬ」との組みがクライアント管理テーブルに登録された情報と合致し、前記「スコープ」が「Ｒｅｓｏｕｒｃｅ」である場合、次の処理を実行する。即ち、認証認可サーバー１１０のＣＰＵ２３１は、クライアント管理テーブルの前記検証で合致した登録された情報から「クライアント名」を取得し、図５ｂに示すリソース登録確認画面５０２を生成し、Ｗｅｂブラウザ３４８に送信する。また、認証認可サーバー１１０のＣＰＵ２３１は、認証情報をＷｅｂブラウザ３４８に対してＣｏｏｋｉｅ情報として格納させる。なお、図５ｂでは、リソース登録確認画面５０２にクライアント名を表示されるとして示したが、リソース登録確認画面５０２にクライアントの詳細な説明を追加して表示させることや、ログインしているユーザーの情報を表示させるようにすることもできる。
Ｓ４０８において、画像形成装置１４０のＣＰＵ２３１は、Ｗｅｂブラウザ３４８に示されたリソース登録確認画面５０２へのユーザーによる操作に基づいて、認証認可サーバー１１０に対して許可であることを示す情報を送信する。より具体的には、画像形成装置１４０のＣＰＵ２３１は、ユーザーによりリソース登録確認画面５０２の許可ボタンが押されたことを検知した場合、認証認可サーバー１１０に対して画像形成装置１４０のリソース登録が許可であることを示す情報を送信する。
【００２８】
前記許可を受けた認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに認可コードを発行し、登録する処理を行う。前記登録する処理は、画像形成装置１４０を認証認可サーバー１１０の配下の資源として登録する処理の一例である。認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルの「認可トークンＩＤ」に前記発行した認可コードの「ＩＤ」を、「種別」に「認可コード」を、「スコープ」に「Ｒｅｓｏｕｒｃｅ」を、「有効期限」にトークンの有効期限を、登録する。更には、認証認可サーバー１１０のＣＰＵ２３１は、認可リクエスト時に受け付けたクライアントＩＤを「クライアントＩＤ」に、Ｗｅｂブラウザ３４８からＣｏｏｋｉｅとして送信された認証情報に紐づくユーザーＩＤを「ユーザーＩＤ」に登録する。例えば、認可トークン管理テーブルの１行目に記載したＡＴ＿００００が前記登録された情報の一例である。
Ｓ４０９において、認証認可サーバー１１０のＣＰＵ２３１は、認可コードの認可トークンＩＤを付与したリダイレクトＵＲＬに対してＷｅｂブラウザ３４８にリダイレクト要求する。画像形成装置１４０のＣＰＵ２３１は、前記リダイレクト要求に基づき、Ｗｅｂブラウザ３４８を介して、認証認可サーバー連携クライアント３４６へ前記認可トークンＩＤを送信する。
【００２９】
Ｓ４１０において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、認証認可サーバー１１０に対してトークン要求を行う。前記トークン要求に付随する情報は、前記認可トークンＩＤ、デバイスクライアント管理テーブルの「クライアントＩＤ」、「シークレット」、「リダイレクトＵＲＬ」を含む。
Ｓ４１１において、認証認可サーバー１１０のＣＰＵ２３１は、以下の検証処理を行い、前記検証処理の結果が全て正しい場合、リソーストークンを生成する。認証認可サーバー１１０のＣＰＵ２３１は、前記トークン要求で受けつけたクライアントＩＤとクライアントシークレットとの組みが、ユーザー管理テーブルに登録されている「ユーザーＩＤ」、「パスワード」の組みと合致するか否か検証する。認証認可サーバー１１０のＣＰＵ２３１は、トークン要求で受けつけた認可トークンＩＤが、認可トークン管理テーブルに登録されているか否か、有効期限内か否かを検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記トークン要求で受けつけたクライアントＩＤと、認可トークン管理テーブルの「認可トークンＩＤ」で特定される「クライアントＩＤ」と、が合致するか否かを検証する。更には、認証認可サーバー１１０のＣＰＵ２３１は、前記トークン要求で受け付けたリダイレクトＵＲＬと、クライアント管理テーブルの「リダイレクトＵＲＬ」と、が合致するか否かを検証する。前記「リダイレクトＵＲＬ」は、クライアント管理テーブルで管理されるのではなく、認可トークン管理テーブルに「リダイレクトＵＲＬ」のカラムを追加することにより認可トークン管理テーブルで管理されていてもよい。「リダイレクトＵＲＬ」が認可トークン管理テーブルで管理される場合、認可コードの発行のときに前記認可コードに対応するリダイレクトＵＲＬも前記追加された「リダイレクトＵＲＬ」のカラムに登録される。前記検証において、認証認可サーバー１１０のＣＰＵ２３１は、前記トークン要求で受け付けたリダイレクトＵＲＬと、認可トークン管理テーブルの「リダイレクトＵＲＬ」と、が合致するか否か検証するようにしてもよい。Ｓ４１１の全ての検証の結果が正しい場合、認証認可サーバー１１０のＣＰＵ２３１は、リソーストークンを生成する。
【００３０】
Ｓ４１２において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ４１１で生成されたリソーストークンの認可トークンＩＤを認証認可サーバー連携クライアント３４６に対して送信する。更に、認証認可サーバー１１０のＣＰＵ２３１は、前記リソーストークンと同時に発行したリフレッシュトークンＩＤ、認証認可サーバー１１０へログインしたユーザーＩＤも認証認可サーバー連携クライアント３４６へ送信する。認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに「認可トークンＩＤ」に発行したトークンのＩＤ、「トークン種別」にリソーストークン、「有効期限」、を登録する。更に、認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに対して、前記認可コードから引き継ぐ情報として、「クライアントＩＤ」、「ユーザーＩＤ」を登録する。また、認証認可サーバー１１０のＣＰＵ２３１は、リソーストークンをリフレッシュするためのリフレッシュトークンを発行し、認可トークン管理テーブルの「リフレッシュトークンＩＤ」、「リフレッシュ期限」に登録する。リフレッシュの処理については、図６のＳ６１４−Ｓ６１６等で、後述する。認可トークン管理テーブルの２行目に記載したＡＴ＿０００１は、前記登録された情報の一例である。
【００３１】
Ｓ４１３において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、アプリケーション管理フレームワーク３４０を介して画像形成装置１４０にログインしているユーザーのログインコンテキストを取得する。そして、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、前記ログインコンテキストからデバイスユーザーＩＤを取得する。
Ｓ４１４において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、デバイストークン管理テーブルに対して登録を行う。画像形成装置１４０のＣＰＵ２３１は、前記登録において、「ユーザーＩＤ」にデバイスユーザーＩＤを、「認可トークンＩＤ」にリソーストークンの認可トークンＩＤを、「リフレッシュトークンＩＤ」にリフレッシュトークンＩＤを、登録する。また、画像形成装置１４０のＣＰＵ２３１は、前記登録において、「認証認可サーバーユーザーＩＤ」に認証認可サーバー１１０へログインしたユーザーＩＤを、登録する。
Ｓ４１５において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、リソース登録完了の旨を示す画面をＷｅｂブラウザ３４８に応答し、リソース登録処理の処理を終了する。
【００３２】
次に、図５、６を用いて、クライアント端末１５０から、リソースサーバー１２０及び画像形成装置１４０のリソースサービス連携アプリケーション３４７にアクセスする処理を説明する。
図６は、クライアント端末によるリソースサーバーの利用処理の一例を示す図である。
図６のシーケンスは、クライアント端末１５０が、リソースサーバー１２０にアクセスするまでのシーケンスである。前記シーケンスは、２つのシーケンスに分かれる。１つ目のシーケンスは、クライアント端末１５０が、リソースサーバー１２０を利用するための認可トークンを取得するためのシーケンス（Ｓ６０１−Ｓ６１１）である。２つ目のシーケンスは、前記認可トークンを利用してリソースサーバー１２０へアクセスするためのシーケンス（Ｓ６１２−Ｓ６２５）である。なお、前記２つのシーケンスは一般的なＯＡｕｔｈの仕組みを利用した端末装置がリソースサーバーにアクセスするためのシーケンスと同様である。また、本実施形態では、クライアント端末１５０は、ユーザーを管理していない端末を想定している。クライアント端末１５０が画像形成装置１４０と同様の構成でユーザーやリソースサービス連携アプリケーション３４７を管理する場合、クライアント端末１５０は、図４で示したリソース登録処理と同様の処理で認可トークンを取得する。
【００３３】
Ｓ６０１において、クライアント端末１５０のＣＰＵ２３１は、ユーザーによる操作に基づいて、リソースサービス連携アプリケーション３５１を起動する。クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、デバイストークン管理テーブルにて認可トークンを保持しているか否かを確認し、保持していない場合、Ｓ６０２の処理へ進む。クライアント端末１５０のＣＰＵ２３１は、デバイストークン管理テーブルにて認可トークンを保持している場合、Ｓ６１２の処理に進む。
Ｓ６０２において、クライアント端末１５０のＣＰＵ２３１は、ＯＡｕｔｈの認可リクエストを行う。クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、Ｗｅｂブラウザ３５０を起動する。クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、Ｗｅｂブラウザ３５０に対してデバイスクライアント管理テーブルの「エンドポイントＵＲＬ」のＵＲＬへリダイレクトを要求する。クライアント端末１５０のＣＰＵ２３１は、前記認可リクエストに、デバイスクライアント管理テーブルの「クライアントＩＤ」、「リダイレクトＵＲＬ」の情報を含めることができる。また、クライアント端末１５０のＣＰＵ２３１は、前記認可リクエストに、認可を受けたい権限範囲を示すスコープを含めることができる。例えば、クライアント端末１５０のＣＰＵ２３１は、リソースサーバー１２０を利用するためのスコープとしてＰｒｉｎｔを指定することができる。
【００３４】
Ｓ６０３において、認証認可サーバー１１０のＣＰＵ２３１は、ユーザーを認証するために図５ａに示すログイン画面５０１をＷｅｂブラウザ３５０に送信する。
Ｓ６０４において、クライアント端末１５０のＣＰＵ２３１は、ユーザーによるＷｅｂブラウザ３５０に示されたＳ６０３で送信されたログイン画面５０１へのユーザーＩＤとパスワードとの入力を検知する。クライアント端末１５０のＣＰＵ２３１は、Ｗｅｂブラウザ３５０を介して、前記ユーザーＩＤとパスワードとを認証認可サーバー１１０へ送信する。認証認可サーバー１１０のＣＰＵ２３１は、前記ユーザーＩＤとパスワードとの組みがユーザー管理テーブルに登録されている情報と合致するか否かを検証し、合致する場合は前記ユーザーＩＤと紐づいた認証情報を生成し、次の処理を実行する。認証認可サーバー１１０のＣＰＵ２３１は、前記認可リクエストのクライアントＩＤとリダイレクトＵＲＬとの組みがクライアント管理テーブルに登録されている情報と合致するか否かを検証する。また、認証認可サーバー１１０のＣＰＵ２３１は、ログインしたユーザーに前記認可リクエストのスコープへの権限があるか否かを検証する。前記２つの検証の結果、前記認可リクエストのクライアントＩＤとリダイレクトＵＲＬとの組みがクライアント管理テーブルに登録されている情報と合致し、ログインしたユーザーに前記認可リクエストのスコープへの権限がある場合、次の処理が行われる。即ち、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ６０５の処理へ進む。
【００３５】
Ｓ６０５において、認証認可サーバー１１０のＣＰＵ２３１は、図５ｃに示す認可確認画面５０３を生成し、Ｗｅｂブラウザ３５０に送信する。認証認可サーバー１１０のＣＰＵ２３１は、前記認証情報をＷｅｂブラウザ３５０に対してＣｏｏｋｉｅ情報として格納する。なお、図５ｃでは、認可確認画面５０３にリソース名を表示するよう示したが、ここにクライアントの詳細な説明を追加して表示することや、ログインしているユーザーの情報を表示するようにすることもできる。
Ｓ６０６において、クライアント端末１５０のＣＰＵ２３１は、Ｗｅｂブラウザ３５０に示された認可確認画面へのユーザーによる操作に基づいて、認証認可サーバーへ認可の許可を示す情報を送信する。認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに認可コードを発行し、前記認可コードに対応する情報を登録する。認可トークン管理テーブルに登録される前記情報は、「認可トークンＩＤ」に発行した認可コードのＩＤ、「種別」に認可コード、「スコープ」にＰｒｉｎｔ、「有効期限」にトークンの有効期限を含む。更には、認可トークン管理テーブルに登録される前記情報は、「クライアントＩＤ」に認可リクエスト時に受け付けたクライアントＩＤを、「ユーザーＩＤ」にＷｅｂブラウザ３５０からＣｏｏｋｉｅとして送信された認証情報に紐づくユーザーＩＤを、含む。例えば、認可トークン管理テーブルの３行目に記載したＡＴ＿０００２は、認可トークン管理テーブルに登録される前記情報の一例である。
Ｓ６０７において、認証認可サーバー１１０のＣＰＵ２３１は、認可応答として、認可コードのＩＤを付与したリダイレクトＵＲＬに対してＷｅｂブラウザ３５０にリダイレクト要求する。
【００３６】
Ｓ６０８において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、認証認可サーバー１１０に対してトークン要求を行う。前記トークン要求に付随する情報は、認可応答で取得した認可コードの認可トークンＩＤ、デバイスクライアント管理テーブルの「クライアントＩＤ」、「シークレット」、「リダイレクトＵＲＬ」を含む。
前記トークン要求を受けた認証認可サーバー１１０のＣＰＵ２３１は、以下の検証を行い、全て正しい場合は認可トークンを生成する。認証認可サーバー１１０のＣＰＵ２３１は、トークン要求のクライアントＩＤとクライアントシークレットとの組みが、ユーザー管理テーブルに登録されている「ユーザーＩＤ」、「パスワード」の組みと合致するか否か検証する。認証認可サーバー１１０のＣＰＵ２３１は、トークン要求の認可コードの認可トークンＩＤが、認可トークン管理テーブルに登録されているか否か、前記認可トークンＩＤが有効期限内か否かを検証する。また、認証認可サーバー１１０のＣＰＵ２３１は、トークン要求で受けつけたクライアントＩＤと認可トークン管理テーブルの「認可トークンＩＤ」で特定される「クライアントＩＤ」とが合致するか否かを検証する。更には、認証認可サーバー１１０のＣＰＵ２３１は、前記トークン要求のリダイレクトＵＲＬがクライアント管理テーブルの「リダイレクトＵＲＬ」と合っているか否かを検証する。前記「リダイレクトＵＲＬ」は、クライアント管理テーブルで管理されるのではなく、認可トークン管理テーブルに「リダイレクトＵＲＬ」のカラムを追加することにより認可トークン管理テーブルで管理されていてもよい。「リダイレクトＵＲＬ」が認可トークン管理テーブルで管理される場合、認可コードの発行のときに前記認可コードに対応するリダイレクトＵＲＬも前記追加された「リダイレクトＵＲＬ」のカラムに登録される。前記検証において、認証認可サーバー１１０のＣＰＵ２３１は、前記トークン要求で受け付けたリダイレクトＵＲＬと、認可トークン管理テーブルの「リダイレクトＵＲＬ」と、が合致するか否か検証するようにしてもよい。前記すべての検証が正しい場合に、認証認可サーバー１１０のＣＰＵ２３１は、認可トークンを生成する。
【００３７】
Ｓ６０９において、認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンの認可トークンＩＤ、リフレッシュトークンＩＤ、認証認可サーバー１１０へログインしたユーザーＩＤをリソースサービス連携アプリケーション３５１に送信する。認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに、「認可トークンＩＤ」に前記認可トークンのＩＤ、「トークン種別」に「認可トークン」、「有効期限」を登録する。また、認証認可サーバー１１０のＣＰＵ２３１は、認可コードから引き継ぐ情報として、「クライアントＩＤ」、「ユーザーＩＤ」を登録する。更に、認証認可サーバー１１０のＣＰＵ２３１は、認可トークンをリフレッシュするためのリフレッシュトークンを発行し、「リフレッシュトークンＩＤ」、「リフレッシュ期限」に登録する。例えば、認可トークン管理テーブルの４行目に記載したＡＴ＿０００３は、前記登録された情報の一例である。なお、リフレッシュの処理については、図６のＳ６１４−Ｓ６１６等で、後述する。
Ｓ６１０において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、デバイストークン管理テーブルに前記認可トークンの情報を保存する。クライアント端末１５０のＣＰＵ２３１は、デバイストークン管理テーブルの「認可トークンＩＤ」に認可トークンＩＤを、「リフレッシュトークンＩＤ」にリフレッシュトークンＩＤを、保存する。更に、クライアント端末１５０のＣＰＵ２３１は、デバイストークン管理テーブルの「認証認可サーバーユーザーＩＤ」に認証認可サーバー１１０へログインしたユーザーＩＤを、保存する。
Ｓ６１１において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、認可完了の旨を示す画面をＷｅｂブラウザ３５０に示す。
【００３８】
続いて、取得した認可トークンを利用したクライアント端末１５０によるリソースサーバー１２０へのアクセスについてのシーケンスを説明する。
Ｓ６１２において、クライアント端末１５０のＣＰＵ２３１は、ユーザーによるクライアント端末１５０への操作に基づいて、リソースサービス連携アプリケーション３５１を利用する。クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、ユーザーから要求された処理を実現するため、リソースサーバー１２０へ前記処理の要求を行う。
【００３９】
Ｓ６１３−Ｓ６１７の処理は、認可トークンの有効期限が切れている場合に新たな認可トークンを認証認可サーバー１１０に対してクライアント端末１５０により要求される認可トークンのリフレッシュ処理である。認可トークンの有効期限が切れていない場合は、前記リフレッシュ処理を実施せず、Ｓ６１８へ進んでもよい。
Ｓ６１３において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、デバイストークン管理テーブルより、認可トークンの「リフレッシュトークンＩＤ」を取得する。
Ｓ６１４において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して認証認可サーバー１１０にトークンリフレッシュ要求を行う。前記トークンリフレッシュ要求に付随する情報は、前記「リフレッシュトークンＩＤ」とデバイスクライアント管理テーブルの「クライアントＩＤ」と「シークレット」とを含む。認証認可サーバー１１０のＣＰＵ２３１は、前記トークンリフレッシュ要求を受け付けると、以下の処理を実行する。まず、認証認可サーバー１１０のＣＰＵ２３１は、前記トークンリフレッシュ要求に付随する情報に含まれるクライアントＩＤとクライアントシークレットとの組みがユーザー管理テーブルの「ユーザーＩＤ」と「パスワード」との組みと合致するか否かを検証する。前記検証の結果、合致するとされた場合、認証認可サーバー１１０のＣＰＵ２３１は、前記トークンリフレッシュ要求のリフレッシュトークンＩＤが認可トークン管理テーブルに登録されているか否かを検証する。更に、認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルの前記リフレッシュトークンＩＤに対応する「リフレッシュ期限」が有効期限内か否かを検証する。更に、認証認可サーバー１１０のＣＰＵ２３１は、トークンリフレッシュ要求に付随する情報に含まれるクライアントＩＤが認可トークン管理テーブルの「クライアントＩＤ」と一致するか検証する。
【００４０】
Ｓ６１５において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ６１４における検証が全て正しい場合、認可トークンを再度発行する。認証認可サーバー１１０のＣＰＵ２３１は、新たに認可トークンＩＤ、リフレッシュトークンＩＤを発行して認可トークン管理テーブルに登録する。認証認可サーバー１１０のＣＰＵ２３１は、前記トークンリフレッシュ要求で受けつけたリフレッシュトークンＩＤに対応する「トークン種別」、「スコープ」、「クライアントＩＤ」の値を引き継いで認可トークン管理テーブルに登録する。また、認証認可サーバー１１０のＣＰＵ２３１は、元のリフレッシュトークンＩＤを、再度リフレッシュできないよう無効化、より具体的には有効期限を強制的に期限切れにしてもよい。認証認可サーバー１１０のＣＰＵ２３１は、リフレッシュトークンＩＤを新規発行せず、新たな認可トークンＩＤに対応する「リフレッシュトークンＩＤ」に引き継ぐようにしてもよい。
Ｓ６１６、前記認可トークンの認可トークンＩＤと、リフレッシュトークンＩＤをリソースサービス連携アプリケーション３５１に送信する。
Ｓ６１７において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、デバイストークン管理テーブルの「トークンＩＤ」を、Ｓ６１５で発行された認可トークンの認可トークンＩＤで上書きする。また、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、デバイストークン管理テーブルの「リフレッシュトークンＩＤ」を、Ｓ６１５で発行された認可トークンのリフレッシュトークンＩＤで上書きする。
【００４１】
Ｓ６１８において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、リソースサーバー１２０に認可トークンＩＤを含む情報を付随させたリソース要求を行う。
Ｓ６１９において、リソースサーバー１２０のＣＰＵ２３１は、前記リソース要求に付随する情報に含まれる認可トークンＩＤのトークン検証を、認証認可サーバー１１０に対して要求する。前記要求に付随する情報は、スコープを含めることができ、例えばＰｒｉｎｔのスコープを含めることができる。スコープは、処理情報の一例である。
Ｓ６２０において、認証認可サーバー１１０は、前記認可トークンＩＤが、認可トークン管理テーブルに登録されているか否か、有効期限内か否か及び受け付けたスコープが認可トークンのスコープの範囲内否か、を検証する。そして、認証認可サーバー１１０は、前記検証の結果をリソースサーバー１２０に送信する。
Ｓ６２１において、リソースサーバー１２０のＣＰＵ２３１は、認証認可サーバー１１０に対して、前記認可トークンＩＤを送信しトークン情報取得を要求する。
【００４２】
Ｓ６２２において、認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルから前記認可トークンＩＤに対応する情報を取得し、前記情報をリソースサーバー１２０に送信する。前記送信に付随する情報は、例えば、認可トークン管理テーブルの「スコープ」、「クライアントＩＤ」、「ユーザーＩＤ」等の情報を含む。更には、前記送信に付随する情報は、クライアントＩＤにて特定されるクライアント管理テーブルに登録されている「シリアル番号」を含む。
Ｓ６２３において、リソースサーバー１２０のＣＰＵ２３１は、Ｓ６２２で送信された情報に基づいて、要求されたリソースに対するアクセスを許可するか否かを判断し、許可する場合に処理を実行する。
Ｓ６２４において、リソースサーバー１２０のＣＰＵ２３１は、処理の結果をリソースサービス連携アプリケーション３５１に送信する。
Ｓ６２５において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、ユーザーに対して結果を表示する。
前記シーケンスに係る処理によって、クライアント端末１５０と画像形成装置１４０とは、クライアント端末１５０と画像形成装置１４０との間の新たな認証処理を要することなく連携処理が可能となる。
以上が、クライアント端末１５０がリソースサーバー１２０を利用するシーケンスである。
【００４３】
続いて、クライアント端末１５０が画像形成装置１４０のリソースサービス連携アプリケーション３４７を利用するシーケンスについて、図７、８、９、１０、１１を用いて説明する。
図７は、クライアント端末１５０が図６のＳ６０１−Ｓ６１１の処理で認可トークンを取得したことを前提とするシーケンスである。クライアント端末１５０のＣＰＵ２３１がリソースサーバー１２０へのアクセスに利用した認可トークンをそのまま画像形成装置１４０へのアクセスで利用可能なため、クライアント端末１５０と画像形成装置１４０との間の認証処理が不要となる。
【００４４】
Ｓ７０１において、クライアント端末１５０のＣＰＵ２３１は、ユーザーによるクライアント端末１５０への操作に基づいて、リソースサービス連携アプリケーション３５１を利用する。クライアント端末１５０のＣＰＵ２３１は、ユーザーによる操作に基づいてアクセスする画像形成装置１４０を特定し、リソースサービス連携アプリケーション３４７の機能を利用する。画像形成装置１４０の特定方法としては、事前にクライアント端末１５０に登録しておいた画像形成装置１４０の一覧から選択するといった方法等がある。また、クライアント端末１５０と画像形成装置１４０とにＮＦＣ（Ｎｅａｒ  Ｆｉｅｌｄ  Ｃｏｍｍｕｎｉｃａｔｉｏｎ）等が実装されていれば、クライアント端末１５０で対象の画像形成装置１４０のＮＦＣを読み取り画像形成装置１４０を特定する方法でもよい。更に、クライアント端末１５０にカメラ等のハードウェアが実装されていれば、画像形成装置１４０にて２次元バーコード等を表示し、前記カメラで前記２次元バーコード等を読み取って画像形成装置１４０を特定する方法でもよい。本実施形態では画像形成装置１４０の特定方法は限定しない。
Ｓ７０２において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、利用する画像形成装置１４０に対して、リソース要求を行う。前記リソース要求に付随する情報は、図６のＳ６１７で保存した認可トークンの認可トークンＩＤを含む。画像形成装置１４０の印刷性能（カラー／モノクロやフィニッシャーの性能）の取得、取得した印刷情報に基づいた印刷設定付きの印刷指示は、前記リソース要求の一例である。
【００４５】
Ｓ７０３において、画像形成装置１４０のＣＰＵ２３１は、リソースサービス連携アプリケーション３４７を介して、次の処理を行う。即ち、画像形成装置１４０のＣＰＵ２３１は、前記リソース要求に付随する情報に含まれる前記認可トークンについて認証認可サーバー連携クライアント３４６に検証するようトークン検証要求する。なお、前記トークン検証要求に付随する情報は、スコープの指定を含むことができる。本実施形態では、前記トークン検証要求に付随する情報は、Ｐｒｉｎｔスコープの指定を含むものとする。
Ｓ７０４において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、認証認可サーバー１１０に対して、前記認可トークンに対応するユーザーの情報を要求するトークンユーザー情報要求を行う。前記要求に付随する情報は、テナントクライアント管理テーブルの「クライアントＩＤ」、「シークレット」及びリソースサービス連携アプリケーション３４７からの認可トークンを含む。
Ｓ７０５において、認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンに対応するユーザーの情報を特定するユーザー情報特定処理を実施する。
Ｓ７０５の前記ユーザー情報特定処理の詳細に関して図８のフローチャートを用いて説明する。
【００４６】
図８は、認証認可サーバー１１０でのユーザー情報特定処理の一例を示すフローチャートである。
Ｓ８０１において、認証認可サーバー１１０のＣＰＵ２３１は、前記トークンユーザー情報要求のクライアントＩＤとシークレットとの組みが、ユーザー管理テーブルに登録されている「ユーザーＩＤ」と「パスワード」との組みと合致するか否かを検証する。
Ｓ８０２において、前記検証の結果、合致するとされた場合、認証認可サーバー１１０のＣＰＵ２３１は、クライアント管理テーブルの「クライアントＩＤ」を取得し、Ｓ７０２のリソース要求のアクセス元を特定する。
Ｓ８０３において、認証認可サーバー１１０のＣＰＵ２３１は、前記トークンユーザー情報要求の認可トークンＩＤの検証を行う。認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンＩＤが、認可トークン管理テーブルに登録されているか否か、有効期限内か否かを検証することで、前記認可トークンＩＤが有効か否かを検証する。
Ｓ８０４において、認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンＩＤが有効である場合、認可トークン管理テーブルの前記認可トークンＩＤに対応する「ユーザーＩＤ」からトークン発行ユーザーの情報を取得する。
Ｓ８０５において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ８０４で取得したユーザーＩＤの情報に基づいて、認可トークン管理テーブルよりリソーストークンの検索を行う。認証認可サーバー１１０のＣＰＵ２３１は、次の条件を全て満たすトークンを、認可トークン管理テーブルに登録されているトークンの中から検索する。前記条件は、「種別」がリソーストークン、「スコープ」がＲｅｓｏｕｒｃｅ、「クライアント」がＳ８０２で取得したクライアントＩＤ、「ユーザーＩＤ」がＳ８０４で取得したユーザーＩＤ、「リフレッシュ期限」が切れていないこと、である。認証認可サーバー１１０のＣＰＵ２３１は、前記条件を満たすトークンが検索できた場合、Ｓ８０６の処理に進み、前記条件を満たすトークンが検索できなかった場合、Ｓ８０７の処理に進む。
【００４７】
Ｓ８０６において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ８０４で取得した認可トークン発行者のユーザーＩＤを戻り値として、図８のユーザー情報特定処理を終了する。
Ｓ８０７において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ８０４で取得した認可トークン発行者のユーザーの管理者である管理者ユーザーの情報に基づいて、認可トークン管理テーブルよりリソーストークンの検索を行う。まず、認証認可サーバー１１０のＣＰＵ２３１は、ユーザー管理テーブルから、「テナントＩＤ」がＳ８０４で取得した認可トークンの発行者ユーザーと同一であり、「ロール」が管理者であるユーザーの「ユーザーＩＤ」を全て取得する。次に、認証認可サーバー１１０のＣＰＵ２３１は、次の条件を全て満たすトークンを、認可トークン管理テーブルに登録されているトークンから検索する。前記条件は、「種別」がリソーストークン、「スコープ」がＲｅｓｏｕｒｃｅ、「クライアント」がＳ８０２で取得したクライアントＩＤ、「ユーザーＩＤ」が取得した管理者のユーザーＩＤ、「リフレッシュ期限」が切れていないこと、である。認証認可サーバー１１０のＣＰＵ２３１は、前記条件を全て満たすトークンを検索できた場合、Ｓ８０８の処理に進み、前記条件を全て満たすトークンを検索できなかった場合、Ｓ８０９に進む。
Ｓ８０８において、認証認可サーバー１１０のＣＰＵ２３１は、前記管理者のユーザーＩＤを戻り値にして、図８のユーザー情報特定処理を終了する。もし、Ｓ８０７での検索の結果、複数のトークンが見つかった場合、認証認可サーバー１１０のＣＰＵ２３１は、前記複数のトークンの中から特定のルールに則ったものを１つ返せばよい。認証認可サーバー１１０のＣＰＵ２３１は、例えば最初に見つかったトークンのユーザーＩＤを返すようにしてよい。また認証認可サーバー１１０のＣＰＵ２３１は、リフレッシュ期限が一番未来、つまりもっとも新しいトークンのユーザーＩＤを返すようにしてよい。
Ｓ８０９において、認証認可サーバー１１０のＣＰＵ２３１は、エラー処理を行うことができる。
以上が、図８のユーザー情報特定処理（Ｓ７０５）の詳細である。
【００４８】
図７の説明に戻る。
Ｓ７０６において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ７０５で取得したユーザーＩＤを認証認可サーバー連携クライアント３４６に送信する。
画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、次の処理を実行する。即ち、画像形成装置１４０のＣＰＵ２３１は、デバイストークン管理テーブルから、「種別」がリソーストークンであり、「認証認可サーバーユーザーＩＤ」がＳ７０６で取得したユーザーＩＤと同一であるトークンを取得する。
Ｓ７０７において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、取得したトークンを認証認可サーバー１１０に対してリフレッシュ要求する。
Ｓ７０８において、認証認可サーバー１１０のＣＰＵ２３１は、リフレッシュしたリソーストークンを認証認可サーバー連携クライアント３４６へ送信する。
Ｓ７０７−Ｓ７０８の処理は、Ｓ６１４−Ｓ６１６の処理と同様の処理である。
Ｓ７０９において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、認証認可サーバー１１０に対して、前記認可トークンを検証するようトークン検証要求を行う。前記トークン検証要求に付随する情報は、前記リソーストークンと、Ｓ７０３でリソースサービス連携アプリケーション３４７から検証依頼された前記認可トークンと、スコープと、を含む。
Ｓ７１０において、認証認可サーバー１１０のＣＰＵ２３１は、トークン検証処理を実施する。
【００４９】
図９にて、認証認可サーバー１１０が実施するＳ７１０のトークン検証処理の詳細を説明する。
図９は、認証認可サーバーでのトークン検証処理のフローチャートである。
Ｓ９０１において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ７０９で受けつけたリソーストークンの検証を行う。前記リソーストークンの認可トークンＩＤが、認可トークン管理テーブルに登録されているか否か、有効期限内か否かを検証する。より具体的には、認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに登録されているトークンの中で前記認可トークンＩＤに対応するトークンを検索する。認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンＩＤに対応するトークンが検出できた場合、前記認可トークンの認可トークンＩＤが認可トークン管理テーブルに登録されていると検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記検索したトークンに対応する「有効期限」を参照して、有効期限内か否かを検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記検証の結果、前記リソーストークンの認可トークンＩＤが認可トークン管理テーブルに登録されており、有効期限内である場合、Ｓ９０２の処理へ進む。認証認可サーバー１１０のＣＰＵ２３１は、前記検証の結果、前記リソーストークンの認可トークンＩＤが、認可トークン管理テーブルに登録されていない、又は、有効期限内ではない場合、検証失敗とする。
【００５０】
Ｓ９０２において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ７０９で受けつけた認可トークンの検証を行う。認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンの認可トークンＩＤが、認可トークン管理テーブルに登録されているか否か、有効期限内か否か、前記トークン検証要求のスコープが合致するか否か、を検証する。より具体的には、認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルに登録されているトークンの中で前記認可トークンＩＤに対応するトークンを検索する。認証認可サーバー１１０のＣＰＵ２３１は、前記認可トークンＩＤに対応するトークンが検出できた場合、前記認可トークンの認可トークンＩＤが認可トークン管理テーブルに登録されていると検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記検索したトークンに対応する「有効期限」を参照して、有効期限内か否かを検証する。また、認証認可サーバー１１０のＣＰＵ２３１は、前記スコープと前記検索したトークンに対応する「スコープ」の値とに基づいて、前記スコープが合致するか否かを検証する。例えば、認証認可サーバー１１０のＣＰＵ２３１は、前記スコープと前記検索したトークンに対応する「スコープ」の値とが同一である場合、前記スコープが合致すると検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記検証の結果、受け付けたリソーストークンの認可トークンＩＤが認可トークン管理テーブルに登録されており、有効期限内であり、前記スコープが合致する場合、Ｓ９０３の処理へ進む。認証認可サーバー１１０のＣＰＵ２３１は、前記検証の結果、受け付けたリソーストークンの認可トークンＩＤが認可トークン管理テーブルに登録されていない、又は有効期限内でない、又は前記スコープが合致しない場合、検証失敗とする。
Ｓ９０３において、認証認可サーバー１１０のＣＰＵ２３１は、リソーストークンと認可トークンとの発行者ユーザーをチェックする。認証認可サーバー１１０のＣＰＵ２３１は、認可トークン管理テーブルからリソーストークンと認可トークンとの「ユーザーＩＤ」を取得し比較する。認証認可サーバー１１０のＣＰＵ２３１は、リソーストークンと認可トークンとのユーザーＩＤが同一である場合、Ｓ９０４の処理へ進む。認証認可サーバー１１０のＣＰＵ２３１は、リソーストークンと認可トークンとのユーザーＩＤが異なる場合、Ｓ９０５の処理へ進む。
【００５１】
Ｓ９０４において、認証認可サーバー１１０のＣＰＵ２３１は、トークン検証を成功として図９のトークン検証処理を終了する。
Ｓ９０５において、認証認可サーバー１１０のＣＰＵ２３１は、ユーザー管理テーブルのリソーストークンのユーザーの「テナントＩＤ」と認可トークンのユーザーの「テナントＩＤ」とが一致するか否かを検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記検証の結果、前記２つの「テナントＩＤ」が一致するとされた場合、さらに前記リソーストークンのユーザーの「ロール」が管理者を含むか否かを検証する。認証認可サーバー１１０のＣＰＵ２３１は、前記検証の結果、前記「ロール」に管理者を含む場合、Ｓ９０６の処理へ進み、前記「ロール」に管理者を含まない場合、Ｓ９０７の処理へ進む。
Ｓ９０６において、認証認可サーバー１１０のＣＰＵ２３１は、トークン検証を成功として図９のトークン検証処理を終了する。
Ｓ９０７において、認証認可サーバー１１０のＣＰＵ２３１は、トークン検証を失敗として図９のトークン検証処理を終了する。
以上が、トークン検証処理（Ｓ７１０）の処理の詳細である。
【００５２】
図７の説明に戻る。
Ｓ７１１において、認証認可サーバー１１０のＣＰＵ２３１は、Ｓ７１０の検証結果と、認可トークンのユーザーＩＤを、認証認可サーバー連携クライアント３４６にトークン検証結果として送信する。
Ｓ７１２において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６は、Ｓ７１１の検証結果が成功だった場合、ユーザー特定処理を実施する。
【００５３】
図１０にて、Ｓ７１２で画像形成装置１４０のＣＰＵ２３１が認証認可サーバー連携クライアント３４６を介して実施するユーザー特定処理の詳細を説明する。
図１０は、画像形成装置１４０でのユーザー特定処理のフローチャートである。
Ｓ１００１において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、Ｓ７１１で受信したユーザーＩＤとＳ７０６の処理で受信したユーザーＩＤとを比較するユーザーチェック処理を行う。画像形成装置１４０のＣＰＵ２３１は、前記ユーザーチェック処理の結果ユーザーＩＤが同一である場合、Ｓ１００２の処理へ進み、前記ユーザーチェック処理の結果ユーザーＩＤが同一でない場合、Ｓ１００３の処理へ進む。
Ｓ１００２において、画像形成装置１４０のＣＰＵ２３１は、デバイストークン管理テーブルから「認証認可サーバーユーザーＩＤ」がＳ７０６の処理で受信したユーザーＩＤであり、「種別」がリソーストークンであるトークンを取得する。画像形成装置１４０のＣＰＵ２３１は、前記取得したトークンに対応する「ユーザーＩＤ」を取得する。Ｓ１００２の処理により、認証認可サーバー１１０で管理されているユーザーから、画像形成装置１４０を管理しているユーザーを特定できる。
【００５４】
Ｓ１００３において、画像形成装置１４０のＣＰＵ２３１は、設定に応じたユーザーマッピング処理を実施する。前記ユーザーマッピング処理は、認可トークンを取得したユーザーが画像形成装置１４０にて、リソース登録していないが、認可トークンを取得したユーザーの管理者ユーザーが画像形成装置１４０にて、リソース登録していた場合の処理である。画像形成装置１４０のＣＰＵ２３１は、前記認可トークンを取得したユーザーに対応づけられたユーザーとして前記管理者を、クライアント端末１５０から要求された処理を画像形成装置１４０上で実行する主体として取得する。設定の方法や内容の詳細は、図１１で後述する。Ｓ１００３にて画像形成装置の何らかのユーザーが特定される。
Ｓ１００４において、画像形成装置１４０のＣＰＵ２３１は、画像形成装置１４０のユーザーを特定したらログインコンテキストの生成処理を実施する。Ｓ１００３で特定されたユーザーによって、クライアント端末１５０から要求された処理が画像形成装置１４０上で実行されることになる。
以上が、図１０で説明するＳ７１２で認証認可サーバー連携クライアント３４６が実施するユーザー特定処理の詳細である。
【００５５】
図７の説明に戻る。
Ｓ７１３において、画像形成装置１４０のＣＰＵ２３１は、認証認可サーバー連携クライアント３４６を介して、Ｓ７１１で取得した検証結果が成功であるという情報をリソースサービス連携アプリケーション３４７に送信する。更に、画像形成装置１４０のＣＰＵ２３１は、Ｓ７１２で取得したログインコンテキストをリソースサービス連携アプリケーション３４７に送信する。また、画像形成装置１４０のＣＰＵ２３１は、Ｓ７１１の検証結果が失敗である場合、即座にリソースサービス連携アプリケーション３４７にＳ７１１で取得した検証結果が失敗である情報を送信する。
Ｓ７１４において、画像形成装置１４０のＣＰＵ２３１は、リソースサービス連携アプリケーション３４７を介して、Ｓ７０２でクライアント端末１５０より要求されたリソースの処理を実施する。
Ｓ７１５において、画像形成装置１４０のＣＰＵ２３１は、Ｓ７１４のリソースの処理の結果をクライアント端末１５０のリソースサービス連携アプリケーション３５１に送信する。
Ｓ７１６において、クライアント端末１５０のＣＰＵ２３１は、リソースサービス連携アプリケーション３５１を介して、ユーザーに処理結果を示す。
【００５６】
前述した図１０のＳ１００３の処理に関して図１１を用いて補足する。
図１１は、ユーザー特定処理における設定のための画面の一例を示す図である。
ユーザーアンマッチ時の処理設定画面１１０１は、画像形成装置１４０の管理者が予め画像形成装置１４０にて設定を行うための画面である。ユーザーアンマッチ時の処理設定画面１１０１は、設定画面の一例である。
ユーザーアンマッチ時の処理１１０２は、Ｓ１００１にてユーザーＩＤが一致しなかった場合の処理、つまりＳ１００３での処理方法の設定を行うための項目である。ユーザーアンマッチ時の処理１１０２内の項目は、操作者による例えばユーザーインターフェース部等に表示された前記ユーザーアンマッチ時の処理設定画面１１０１への操作に基づいて、設定することができる。
リソース登録者として実行１１０３は、リソース登録したユーザーとしてクライアント端末１５０から依頼された処理を実行する設定を選択する項目である。より具体的には、検証に利用したリソーストークンのユーザーとして実行することを意味する。
自動生成して実行１１０４は、新規に画像形成装置１４０にユーザーを生成し実行する設定を選択する項目である。画像形成装置１４０のＣＰＵ２３１は、Ｓ７１１で取得した認証認可サーバーのユーザーＩＤに紐づけて画像形成装置１４０に自動的にユーザーを作成するようにできる。なお、前記自動的なユーザーの作成時に、すでに同じ認証認可サーバーのユーザーＩＤに紐づけて作成されていたユーザーがいれば前記ユーザーを利用するようにしてよい。したがって、画像形成装置１４０のＣＰＵ２３１は、前回実行した処理で画像形成装置に作成、保存されたデータ（個人アドレス帳といったユーザー毎の設定等）を再度利用できる。
【００５７】
［  ＸＸ  ］日後に削除１１０５の設定項目は、自動生成して実行１１０４の設定に則って自動生成されたユーザーをいつ削除するのかを設定するための項目である。［  ＸＸ  ］日後に削除１１０５が設定されていない場合、ユーザーは削除されず残り続け、設定した場合、最後にユーザーが利用したのち設定日数経過後に自動削除されるようにできる。
ユーザーマッピング１１０６は、画像形成装置１４０のユーザーと認証認可サーバーのユーザーの対応付け情報を管理している項目である。ユーザーマッピング１１０６には、自動生成して実行１１０４による自動生成で作成されたユーザーの対応付け情報が保持される。ユーザーマッピング１１０６は、画像形成装置１４０のユーザーに対応する認証認可サーバー１１０のユーザーが表示されるようにできる。また、画像形成装置１４０のＣＰＵ２３１は、ユーザーマッピング１１０６への操作者による操作によって、ユーザーマッピング１１０６に任意のユーザーを記述できるようにできる。画像形成装置１４０のＣＰＵ２３１は、ユーザーにより設定１１０７を押下されることを検知することで、前記記述されたユーザーを、画像形成装置１４０の既存のユーザーに対応した認証認可サーバーのユーザーとして登録するようにできる。また、画像形成装置１４０のＣＰＵ２３１は、ユーザーにより設定１１０７を押下されることを検知することで、マッピング情報の解除や、自動生成したユーザーの手動削除等を行うようにもすることができる。
画像形成装置１４０のＣＰＵ２３１は、ユーザーアンマッチ時の処理設定画面１１０１の設定を全て行わなかった場合、次の設定にすることもできる。即ち、画像形成装置１４０のＣＰＵ２３１は、クライアント端末１５０を利用しているユーザーと画像形成装置１４０でリソース登録したユーザーとが一致しなければ利用できないという設定にすることもできる。
以上、本実施形態によれば、次の効果が得られる。操作者、管理者等が予め画像形成装置１４０等をリソースサーバーの一部として認証認可サーバー１１０に登録することで、クライアント端末１５０は、画像形成装置１４０等との間の認証処理を行わずに、セキュアに画像形成装置１４０等へアクセス可能となる。したがって、クライアント端末１５０は、認証認可サーバーの配下のリソースサーバーと画像形成装置１４０等の異なるデバイスとの間の連携処理をシームレスに行うことができるようになる。
以上が本実施形態の説明である。
【００５８】
＜その他の実施形態＞
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピューターにおける１つ以上のプロセッサーがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５９】
１１０  認証認可サーバー、１２０  リソースサーバー、１４０  画像形成装置、１５０  クライアント端末、２３１  ＣＰＵ
【図１】
2016009466.tif 000011
【図２】
2016009466.tif 000012
【図３】
2016009466.tif 000013
【図４】
2016009466.tif 000014
【図５】
2016009466.tif 000015
【図６】
2016009466.tif 000016
【図７】
2016009466.tif 000017
【図８】
2016009466.tif 000018
【図９】
2016009466.tif 000019
【図１０】
2016009466.tif 000020
【図１１】
2016009466.tif 000021