JP2020017235A - 情報処理装置、認証方法、プログラム - Google Patents

Abstract

【課題】ユーザがログインしていない場合にアプリケーションソフトが動作することができる情報処理装置を提供する。【解決手段】情報処理装置１００（画像形成装置）は、ユーザが入力した第１の認証情報に基づいてユーザの認証を行う認証手段４３と、第１のアプリケーションソフトが生成する認証要求を受信する認証要求受信手段４４と、認証要求受信手段が受信した認証要求に第２の認証情報が含まれている場合、第２の認証情報に基づいて第１のアプリケーションソフトを認証し、認証要求に第２の認証情報が含まれていない場合、認証手段からユーザの認証結果を取得する認証制御手段４５と、第２の認証情報に基づく認証結果又はユーザの認証結果に基づいて処理を行う処理手段４２と、を有する。【選択図】図４

Description

本発明は、情報処理装置、認証方法、及び、プログラムに関する。

ユーザが情報処理装置を使用する際にログインを求められる場合がある。例えば、画像形成装置の場合、認証情報に基づいてログインしたユーザの権限（一般ユーザ権限又は管理者権限など）で画像形成装置の情報の取得又は設定が可能であり、印刷ジョブなどを実行できる。

また、例えば画像形成装置が他の機器と連携して一連の処理を行うことができるようになったが、この場合、ユーザは一の機器と他の機器との両方にログインしなければならなかった。このような不都合に対し、ユーザが利用できる機能を制限しつつ一の機器を他の機器と連携させて一連の処理を行う技術が知られている（例えば、特許文献１参照。）。特許文献１には、チケットの署名情報及び他の機器の証明書情報に基づくチケットの検証が成功すると、チケットに含まれるユーザ識別子情報及びアクセス制御情報を登録し、他の機器からのリクエストの処理を実行するか否かをユーザ識別子情報及びアクセス制御情報に基づいて判断する画像形成装置が開示されている。

しかしながら、従来の認証方法では、ユーザが誰もログインしていない場合にアプリケーションソフトが動作することができないという問題があった。まず、ユーザが操作しなくても動作するアプリケーションソフトを画像形成装置等にインストールしたいという要請がある。例えば、深夜など人のいない時間帯に画像形成装置の本体装置が受信したファクスを、外部サーバへ転送するような処理を行うアプリケーションソフトが想定されている。アプリケーションソフトが動作する操作部が本体装置から文書を引き取る必要があるため、一般ユーザ権限（又は文書管理者権限）が必要になるが、誰もログインしていないため文書を引き取ることができない。このように、従来は、ユーザがログインしていない場合、アプリケーションソフトに所望の動作を行わせることが困難であった。

本発明は、上記課題に鑑み、ユーザがログインしていない場合にアプリケーションソフトが動作することができる情報処理装置を提供することを目的とする。

上記課題に鑑み、本発明は、ユーザが入力した第１の認証情報に基づいて前記ユーザの認証を行う認証手段と、第１のアプリケーションソフトが生成する認証要求を受信する認証要求受信手段と、前記認証要求受信手段が受信した前記認証要求に第２の認証情報が含まれている場合、前記第２の認証情報に基づいて前記第１のアプリケーションソフトを認証し、前記認証要求に前記第２の認証情報が含まれていない場合、前記認証手段から前記ユーザの認証結果を取得する認証制御手段と、前記第２の認証情報に基づく認証結果又は前記ユーザの認証結果に基づいて処理を行う処理手段と、を有することを特徴とする情報処理装置を提供する。

本発明は、ユーザがログインしていない場合にアプリケーションソフトが動作することができる情報処理装置を提供することができる。

画像形成装置における認証と認証によりどのような権限で動作するかの関係を説明する図の一例である。 画像形成装置のハードウェア構成例を示す図である。 画像形成装置のソフトウェア構成の一例を示す模式図である。 画像形成装置が有する機能をブロック状に示す機能ブロック図の一例である。 リクエスト送信部が送信するリクエストの一例を示す図である。 認証成功時のレスポンスの一例を示す図である。 認証失敗時のレスポンスの一例を示す図である。 権限なしを示すレスポンスの一例を示す図である。 主に本体装置の処理手順を示す一例のフローチャート図である。 画像形成装置と外部装置を有するシステムの概略構成図の一例である。 外部装置からのリクエストを処理する手順を示すフローチャート図の一例である。

＜課題の補足＞
まず、課題について補足する。上記のように、ユーザが誰もログインしていない場合にアプリケーションソフトが動作することができないという課題があった。

また、一方、画像形成装置では、ユーザが一般ユーザでログインしている場合、管理者権限が必要な情報を取得できず、ユーザが管理者権限でログインしている場合、ジョブを実行できないという制限がある。しかし、ユーザが一般ユーザでログインしている場合に、バックグラウンドで動作するアプリケーションソフトが必要とする管理者権限の情報を取得したい場合がある（ユーザは特に管理者権限の情報を使用しない）。あるいは、ユーザが管理者権限でログインしている場合に、バックグラウンドで動作するアプリケーションソフトがジョブを実行する必要がある場合もある。これらの不都合を解決するために、従来は、アプリケーションソフトが必要に応じて管理者権限でのログイン又は一般ユーザでのログインに切り替える必要があるという課題がある。

なお、バックグラウンドで動作するアプリケーションソフトとは、ユーザがジョブの実行に使用するアプリケーションソフトとは別に動作するアプリケーションソフトである。ユーザはバックグラウンドで動作するアプリケーションソフトが動作していることを意識しない場合が多い。

＜本実施形態の画像形成装置の動作の概略＞
まず、図１を用いて、本実施形態の画像形成装置の概略的な動作を説明する。図１は、本実施形態の画像形成装置１００における認証と認証によりどのような権限で動作するかの関係を説明する図の一例である。図１に示すように、本実施形態の画像形成装置１００は操作部８０と本体装置９０が別々の装置に分かれており、操作部８０と本体装置９０は互いに通信する。また、操作部８０ではユーザログインアプリ４０と操作部アプリ５０が動作する。ユーザログインアプリ４０はユーザのログインを受け付けるアプリケーションソフトであり、操作部アプリ５０はバックグラウンドで動作する。

画像形成装置１００は、操作部アプリ５０が本体装置９０に送信するリクエスト（ＨＴＴＰリクエスト）に認証用ヘッダがあるか否かによって、認証用ヘッダの認証で許可された権限で動作するか、操作部８０からログインしたユーザの権限で動作するかを判断する。

まず、図１（ａ）はリクエストに認証用ヘッダがある場合を示す。ユーザログインアプリ４０はユーザのログイン操作を受け付け、本体装置９０に認証要求を送信する。ただし、本実施形態ではユーザのログイン操作はあってもなくてもよい（ユーザが操作部８０を操作しているか否かは関係がない。）。また、操作部アプリ５０が認証用ヘッダを含むリクエストを本体装置９０に送信する。この場合、本体装置９０は認証用ヘッダで操作部アプリ５０を認証するので、操作部アプリ５０の権限で動作する。

次に、図１（ｂ）はリクエストに認証用ヘッダがない場合を示す。同様に、ユーザログインアプリ４０はユーザのログイン操作を受け付け、本体装置９０に認証要求を送信する。ユーザのログイン操作はあってもなくてもよい。また、操作部アプリ５０が認証用ヘッダのないリクエストを本体装置９０に送信する。この場合、画像形成装置１００は、ユーザがログインしていればユーザの権限で動作し、ユーザがログインしていなければ何ら権限がないので原則的にエラーを返す（権限が必要ない処理要求に対してはリクエストが認められる場合があってよい）。

以上のような構成によれば、操作部アプリ５０は、ユーザがログインしていなくても本体装置９０に処理を要求でき、操作部アプリ５０はユーザの操作に関係なく所望の処理を行うことができる。

また、一般ユーザがユーザログインアプリ４０でログインしており、操作部アプリ５０が認証用ヘッダのあるリクエストを本体装置９０に送信した場合、操作部アプリ５０の権限で動作するので、操作部アプリ５０が管理者権限でログインすれば、操作部アプリ５０が動作するために必要な例えば管理者権限の情報を取得できる。管理者がユーザログインアプリ４０でログインしており、操作部アプリ５０が認証用ヘッダのあるリクエストを送信した場合、操作部アプリ５０の権限で動作するので、操作部アプリ５０の権限が一般ユーザであれば操作部アプリ５０がジョブを実行できる。

このように、本実施形態の画像形成装置１００の操作部アプリ５０は、ユーザが一般ユーザでログインしている場合でも管理者権限が必要な情報を取得でき、ユーザが管理者権限でログインしている場合でもジョブを実行できる。また、画像形成装置１００のリソースに対するアクセスポリシーを維持した状態で（アクセスポリシーを変更せずに）、異なる権限の情報を取得できる。

＜用語について＞
認証とは、画像形成装置のユーザが本人かどうかを確認することをいう。また、認証に使用される情報を認証情報という。認証情報は、ユーザを識別する情報と、識別する情報を確認する情報の組み合わせである。識別する情報を確認する情報は、例えばパスワード、ＩＣカード番号、又は生体認証情報などが使用される。認証情報はアカウント情報、証明書、トークンなどと呼ばれてもよい。認証が成功するとユーザがログインできる。ログインとは、コンピュータの利用開始時にユーザの身元や妥当性を識別してさまざまなリソースへのアクセスに必要な資格情報を取得するための操作のことをいう。ユーザの権限に応じてアクセスできるリソースが制限される場合がある。なお、ログインをログオン、サインイン、又は、サインオンという場合がある。

認証結果とはユーザが本人であると確認できたこと（認証が成功したこと）、又は、ユーザが本人であると確認できないこと（認証が失敗したこと）をいう。また、認証結果にはユーザがどのような権限を有するかを含んでよい。権限とは正式に行為し得る権利の範囲であり、画像形成装置では操作できる範囲をいう。

ユーザには権限が異なる一般ユーザと管理者がある。一般ユーザは画像形成装置１００を使用する一般的なユーザであり、管理者は画像形成装置１００の設定を変更する権限を有するなど、画像形成装置１００を管理するユーザである。

＜構成例＞
続いて、図２を用いて画像形成装置１００のハードウェア構成例を説明する。図２（ａ）は、画像形成装置１００の構成を模式的に示す図の一例である。本体装置９０は、操作部８０と通信可能に接続される。本体装置９０と操作部８０との通信は、例えば、ＵＳＢ（Universal Serial Bus）、近距離無線通信（Ｂｌｕｅｔｏｏｔｈ（登録商標）又は赤外線等）、又は、ＬＡＮ（有線又は無線の別は問わない）等のネットワークを介して行われる。

本体装置９０は、画像形成機能、スキャナ機能、ファクス機能、及び、コピー機能などの機能のうち少なくとも１つ以上を有する。これらのうち複数の機能を有する画像形成装置１００は、複合機又はＭＦＰ(Multifunction Peripheral/Printer/Product)と呼ばれる場合がある。また、画像形成装置１００は、印刷装置又はプリンタと呼ばれていてもよい。

本体装置９０は画像形成装置１００の主な機能を提供するのに対し、操作部８０ではアプリケーションソフトが動作して種々の画面を表示して画面に対する入力を受け付け、また、処理結果を出力（表示）する。つまり、操作部８０は画像形成装置１００におけるユーザインタフェースとなる。

操作部８０は、例えば、スマートフォンやタブレット型端末等、単独で完結した情報処理を実行可能な情報処理装置である。操作部８０は、従来、画像形成装置１００の専用の操作部８０として設置されていた操作パネルの代わりに、本体装置９０に接続される。操作部８０と本体装置９０とは、一台の装置として把握されてもよい。また、操作部８０は画像形成装置１００から取り外しができなくてもよいし、取り外しができてもよい。

次に、図２（ｂ）を用いて、画像形成装置１００のハードウェア構成について説明する。図２（ｂ）は、画像形成装置１００のハードウェアブロック図の一例を示す。画像形成装置１００の本体装置９０と操作部８０は、通信路３００を介して相互に通信可能に接続されている。

本体装置９０は、操作部８０が受け付けた操作に応じた動作を行うことができる。また、本体装置９０は、クライアントＰＣ（パーソナルコンピュータ）やサーバ等の外部装置とも通信可能であり、外部装置から受信した指示に応じた動作を行うこともできる。

まず、本体装置９０のハードウェア構成について説明する。本体装置９０は、ＣＰＵ１１と、ＲＯＭ１２と、ＲＡＭ１３と、ＨＤＤ（ハードディスクドライブ）１４と、通信Ｉ／Ｆ（インタフェース）１５と、接続Ｉ／Ｆ１６と、エンジン部１７とを備え、これらがシステムバス１８を介して相互に接続されている。

ＣＰＵ１１は、本体装置９０の動作を統括的に制御する。ＣＰＵ１１は、ＲＡＭ１３をワークエリア（作業領域）としてＲＯＭ１２又はＨＤＤ１４等に格納されたプログラム９０ｐを実行しエンジン部１７を制御することで、本体装置９０全体の動作を制御する。また、コピー機能、スキャナ機能、ファクス機能、プリンタ機能などの各種機能を実現する。

通信Ｉ／Ｆ１５は、ネットワーク５０１と接続するためのインタフェースである。接続Ｉ／Ｆ１６は、通信路３００を介して操作部８０と通信するためのインタフェースである。

エンジン部１７は、コピー機能、スキャナ機能、ファクス機能、及び、プリンタ機能を実現させるための、汎用的な情報処理及び通信以外の処理を行うハードウェアである。例えば、原稿の画像をスキャンして読み取るスキャナ（スキャナ機能）、用紙等のシート材への印刷を行うプロッタ（印刷機能）、ファクス通信を行うファクス部などを備えている。更に、印刷済みシート材を仕分けるフィニッシャや、原稿を自動給送するＡＤＦ（自動原稿搬送装置）のような特定のオプションを備えることもできる。

次に、操作部８０のハードウェア構成について説明する。操作部８０は、ＣＰＵ２１と、ＲＯＭ２２と、ＲＡＭ２３と、フラッシュメモリ２４と、通信Ｉ／Ｆ２５と、接続Ｉ／Ｆ２６と、ディスプレイ２７と、外部接続Ｉ／Ｆ２８と、ホームキー２９とを備える。これらがシステムバス３０を介して相互に接続されている。

ＣＰＵ２１は、操作部８０の動作を統括的に制御する。ＣＰＵ２１は、ＲＡＭ２３をワークエリア（作業領域）としてＲＯＭ２２又はフラッシュメモリ２４等に格納されたプログラム８０ｐを実行することで、操作部８０全体の動作を制御し、ユーザから受け付けた入力に応じた情報（画像）の表示などの後述する各種機能を実現する。

通信Ｉ／Ｆ２５は、ネットワーク５０１と接続するためのインタフェースである。接続Ｉ／Ｆ２６は、通信路３００を介して本体装置９０と通信するためのインタフェースである。

ディスプレイ２７は、ユーザの操作に応じた各種の入力を受け付けると共に、各種の情報（例えば受け付けた操作に応じた情報、画像形成装置１００の動作状況を示す情報、設定状態などを示す情報など）を画面として表示する。ディスプレイ２７は、タッチパネル機能を搭載した液晶表示装置（ＬＣＤ）で構成されるが、これに限られるものではない。例えばタッチパネル機能が搭載された有機ＥＬ表示装置で構成されてもよい。また、操作部８０はディスプレイ２７に加えて、ハードウェアキーやランプ表示などを有していてもよい。例えば、ホームキーと呼ばれるハードウェアキーとして装備していることで、ユーザはホームキーを押下することで利用可能なアプリの一覧を表示できる。

外部接続Ｉ／Ｆ２８は、外部の装置と通信するためのインタフェースであり、例えばＩＣカードリーダー／ライターと接続することができる。

＜ソフトウェア構成例＞
次に、図３を用いて画像形成装置１００のソフトウェア構成について説明する。図３は、画像形成装置１００のソフトウェア構成の一例を示す模式図である。図３に示すように、本体装置９０は、アプリ層１０１と、サービス層１０２と、ＯＳ層１０３とを有する。アプリ層１０１、サービス層１０２、及び、ＯＳ層１０３の実体は、ＲＯＭ１２やＨＤＤ１４等に格納されている各種ソフトウェアである。ＣＰＵ１１が、これらのソフトウェアを実行することにより、各種の機能が提供される。

アプリ層１０１のソフトウェアは、ハードウェア資源を動作させて所定の機能を提供するためのアプリケーションソフトである。例えばアプリケーションソフトとしては、コピー機能を提供するためのコピーアプリ、スキャナ機能を提供するためのスキャナアプリ、ファクス機能を提供するためのファクスアプリ、プリンタ機能を提供するためのプリンタアプリ、画像形成装置１００の情報を通知する機器情報通知アプリなどが挙げられる。

サービス層１０２のソフトウェアは、アプリ層１０１とＯＳ層１０３との間に介在し、アプリに対し、本体装置９０が備えるハードウェア資源を利用するためのインタフェースを提供するためのソフトウェアである。より具体的には、ハードウェア資源に対する動作要求の受付、動作要求の調停を行う機能を提供するためのソフトウェアである。サービス層１０２が受け付ける動作要求としては、スキャナによる読み取りやプロッタによる印刷等の要求が考えられる。

なお、サービス層１０２によるインタフェースの機能は、本体装置９０のアプリ層１０１だけではなく、操作部８０のアプリ層２０１に対しても提供される。すなわち、操作部８０のアプリ層２０１のアプリケーションソフトも、サービス層１０２のインタフェース機能を介して、本体装置９０のハードウェア資源（例えばエンジン部１７）を利用した機能を実現することができる。例えばサービス層１０２のインタフェース機能は、ＷｅｂＡＰＩで提供される。操作部８０と本体装置９０は、通信路３００をネットワークとして通信することができる。

ＯＳ層１０３のソフトウェアは、本体装置９０が備えるハードウェアを制御する基本機能を提供するための基本ソフトウェア（オペレーティングシステム（ＯＳ））である。サービス層１０２のソフトウェアは、各種アプリからのハードウェア資源の利用要求を、ＯＳ層１０３が解釈可能なコマンドに変換してＯＳ層１０３に渡す。そして、ＯＳ層１０３のソフトウェアによりコマンドが実行されることで、ハードウェア資源は、アプリの要求に従った動作を行う。

同様に、操作部８０は、アプリ層２０１と、サービス層２０２と、ＯＳ層２０３とを有する。操作部８０が備えるアプリ層２０１、サービス層２０２及びＯＳ層２０３も、階層構造については本体装置９０側と同様である。ただし、アプリ層２０１のアプリケーションソフトにより提供される機能や、サービス層２０２が受け付け可能な動作要求の種類は、本体装置９０側とは異なる。アプリ層２０１のアプリケーションソフトは、操作部８０が備えるハードウェア資源を動作させて所定の機能を提供するためのソフトウェアであってもよいが、主として本体装置９０が備える機能（コピー機能、スキャナ機能、ファクス機能、プリンタ機能、初期設定機能）に関する操作や表示を行うためのＵＩ（ユーザインタフェース）の機能（コピーのＵＩ機能、スキャナのＵＩ機能、ファクスのＵＩ機能、プリンタのＵＩ機能、初期設定のＵＩ機能等）やブラウザ機能を提供するためのソフトウェアである。

なお、本実施形態では、機能の独立性を保つために、本体装置９０側のＯＳ層１０３のソフトウェアと操作部８０側のＯＳ層２０３のソフトウェアが互いに異なる。つまり、本体装置９０と操作部８０は、別々のオペレーティングシステムで互いに独立して動作する。例えば本体装置９０側のＯＳ層１０３のソフトウェアとしてＮｅｔＢＳＤ（登録商標）を用い、操作部８０側のＯＳ層２０３のソフトウェアとしてＡｎｄｒｏｉｄ（登録商標）を用いることも可能である。

以上のように、本実施形態の画像形成装置１００において、本体装置９０と操作部８０は別々のオペレーティングシステムで動作するため、本体装置９０と操作部８０との間の通信は、共通の装置内のプロセス間通信ではなく、異なる装置間の通信として行われる。操作部８０が受け付けた情報（ユーザからの指示内容）を本体装置９０へ伝達する動作（コマンド通信）や、本体装置９０が操作部８０へイベントを通知する動作などがこれに該当する。ここでは、操作部８０が本体装置９０へコマンド通信を行うことにより、本体装置９０の機能を使用することができる。また、本体装置９０から操作部８０に通知するイベントには、本体装置９０における動作の実行状況、本体装置９０側で設定された内容などが挙げられる。

また、本実施形態では、操作部８０に対する電力供給は、本体装置９０から通信路３００を経由して行われているので、操作部８０の電源制御を、本体装置９０の電源制御とは別に（独立して）行うことができる。

＜機能について＞
次に、図４を用いて画像形成装置１００の機能について説明する。図４は、画像形成装置１００が有する機能をブロック状に示す機能ブロック図の一例である。

＜＜操作部＞＞
操作部８０では操作部アプリ５０とユーザログインアプリ４０が動作している。図４では本実施形態の主要なアプリケーションソフトのみを示している。操作部アプリ５０は、操作部８０においてバックグラウンドで動作するアプリケーションソフトの総称である。したがって、複数あってもよい。例えば、深夜など人のいない時間帯に本体装置９０がファクスで文書を受信し、操作部８０で動作する操作部アプリ５０が本体装置９０から引き取って外部サーバへ転送するような処理を行う。このように操作部アプリ５０はユーザが操作しなくても動作するアプリケーションソフトである。ただし、ユーザが操作することで動作してもよい。このようなアプリケーションソフトを常駐アプリという場合がある。

ユーザログインアプリ４０は、ユーザのログインを受け付けるアプリケーションソフトである。ユーザログインアプリ４０はログインを受け付けるためのロック画面を表示して、ロック画面に対する認証情報の入力を受け付ける。ユーザログインアプリ４０はユーザがログインする前から使用可能である。認証情報は、例えばユーザＩＤとパスワード、ＩＣカードのカード番号、又は、生体認証情報などでよい。

操作部アプリ５０はリクエスト送信部３１を有し、ユーザログインアプリ４０は操作受付部３２とログイン要求部３３を有している。操作部８０が有するこれらの機能は、図２に示された各構成要素のいずれかが、フラッシュメモリ２４からＲＡＭ２３に展開されたプログラム（操作部アプリ５０とユーザログインアプリ４０）に従ったＣＰＵ２１からの命令により動作することで実現される機能又は手段である。このプログラムは、プログラム配信用のサーバから配信されるか又は記憶媒体に記憶された状態で配布される。

リクエスト送信部３１は、本体装置９０のサービス層１０２が有するＷｅｂＡＰＩを呼び出すＨＴＴＰ（HyperText Transfer Protocol）通信によって本体装置９０と通信する。ただし、操作部８０と本体装置９０との間において利用される通信プロトコルは、ＨＴＴＰに限定されなくてもよい。例えば、ＨＴＴＰｓ、ＷｅｖＤＡＶ等でもよい。何らかの処理を本体装置９０に要求する場合、リクエスト送信部３１はＨＴＴＰリクエスト（以下、単にリクエストという）を生成して送信する。リクエスト送信の契機は操作部アプリ５０によって様々であるが、例えば、ファクスによる文書の受信、所定の時刻になったこと、外部からデータを受信したこと、又は、ユーザが操作したことなどである。

リクエスト送信部３１はリクエストを送信する際、ヘッダ情報の１つに操作部アプリ５０の認証情報を生成して含めることができる。ヘッダ情報とはＨＴＴＰメッセージのパケットのヘッダ部分の情報のことをいう。ヘッダ情報の一例を図５に示す。例えば、１行目（リクエスト行）にはＧＥＴなどのメソッド、リクエスト先のＵＲＬ、及びＨＴＴＰバージョンが設定される。２行目以降（ヘッダ行）には種々の情報が存在する。本実施形態ではヘッダ情報の１つに設定される認証情報を「認証用ヘッダ」という。認証情報は一例として、操作部アプリ５０のＩＤとパスワードであるが、認証情報はこれらには限られない。例えば、トークンや証明書などでもよい。

リクエスト送信部３１は、リクエストに認証用ヘッダを設定するか否かを切り替える。例えば、管理者権限に基づく情報取得が必要な場合、又は、一般ユーザ権限に基づくジョブの実行が必要な場合、リクエストに認証用ヘッダを設定する。例えば、ユーザがログインしている場合、又は、所定の権限以上のユーザがログインしている場合、ユーザの操作を優先するため、リクエストに認証用ヘッダを設定しない。また、あるいは、操作部アプリ５０の種類によって、リクエストに認証用ヘッダを設定するか否かを切り替える場合がある。一般ユーザ又は管理者権限が必要な操作部アプリ５０はリクエストに認証用ヘッダを設定し、そうでない操作部アプリ５０はリクエストに認証用ヘッダを設定しない。

なお、リクエスト送信部３１は本体装置９０からリクエストに対するＨＴＴＰレスポンスを受信する（以下、単にレスポンスという）。

操作受付部３２は、ユーザから操作部８０に対する各種の操作を受け付ける。本実施形態では認証情報の入力を受け付ける。ログイン要求部３３は認証情報を含む認証要求を本体装置９０に送信する。ログイン要求部３３が認証成功を受信すると、ユーザログインアプリ４０はロック画面を消去して、ディスプレイにはユーザが利用できるアプリケーションソフトの一覧が表示される。なお、ログイン要求部３３もＨＴＴＰ等のリクエストによって本体装置９０と通信するが、本体装置９０との通信に適切なリクエストが使用されるものとする。

＜＜本体装置＞＞
本体装置９０は、ＳＤＫ（Software Development Kit）制御部４１、認証制御部４３、及び、サービス部４２を有している。本体装置９０が有するこれらの機能は、図２に示された各構成要素のいずれかが、ＨＤＤ１４からＲＡＭ１３に展開されたプログラムに従ったＣＰＵ１１からの命令により動作することで実現される機能又は手段である。このプログラムは、プログラム配信用のサーバから配信されるか又は記憶媒体に記憶された状態で配布される。

サービス部４２は、各種のハードウェアリソース等を制御するための機能を有し、その機能を上位アプリケーション（ＳＤＫ制御部４１）等に利用させるためのインタフェースを提供するソフトウェアモジュール群である。サービス部４２は、例えば、コピーを制御する機能、スキャナを制御する機能、プリンタを制御する機能、ファクスの送受信を制御する機能、アドレス帳を管理する機能、及び、ログを記録する機能等を有する。

認証制御部４３はユーザログインアプリ４０から認証情報を含む認証要求を受信して、認証情報保存領域４７に該当ユーザがいるか否か（同じ認証情報があるか否か）を確認して認証結果をユーザログインアプリ４０に送信する。また、認証制御部４３は認証結果を、ＳＤＫ制御部４１内のリソース制御部４５に通知する。認証結果には認証の成功又は失敗だけでなく、ユーザの権限（例えば、一般ユーザ権限又は管理者権限など）が含まれる。ユーザの権限とリクエストがどの権限を必要とするかに応じて、リクエストが許可されたり制限されたりする。

ＳＤＫ制御部４１は、ＳＤＫに対応したアプリケーションソフト（以下、ＳＤＫアプリという）を開発するためのＡＰＩ（Application Program Interface）を備えると共に、ＳＤＫアプリの実行環境を提供する。更に、ＳＤＫアプリがサービス部４２を利用することを可能にする。ＡＰＩの形態は、例えば、関数であってもよいし、オブジェクト指向のクラス及びクラスのメソッド等であってもよい。例えば、ＳＤＫ制御部４１は、コピー機能に関するＳＤＫＡＰＩ、スキャナ機能に関するＳＤＫＡＰＩ、プリンタ機能に関するＳＤＫＡＰＩ等をＳＤＫアプリに提供する。ＳＤＫ制御部４１は、Ｊａｖａ（登録商標）ＶＭ（Virtual Machine）を含んでいてもよい。この場合、ＳＤＫアプリは、Ｊａｖａ（登録商標）言語によって実装される。ただし、本体装置９０にインストール可能なプログラムはＳＤＫアプリに限定されない。

ＳＤＫアプリは、画像形成装置１００の出荷後において、画像形成装置１００の機能拡張を図るために追加的にインストールされるプログラム（又はプラグインともいう。）である。図４では、ＳＤＫアプリとして、リクエスト管理部４４、リソース制御部４５、及び、結果応答部４６が例示されている。ただし、ＳＤＫを用いずに開発されたネイティブアプリでもよい。

リクエスト管理部４４は、操作部アプリ５０からのリクエストを受信し、リクエストに含まれるヘッダ情報をリソース制御部４５に送出する（図５参照）。ヘッダ情報には認証用ヘッダが含まれる場合と含まれない場合がある。

リソース制御部４５はヘッダ情報に認証用ヘッダがあるか否かを判断して、認証用ヘッダがある場合は、認証制御部４３に認証用ヘッダの認証情報を送出して認証してもらう。リソース制御部４５は認証結果を認証制御部４３から取得する。認証結果には操作部アプリ５０の権限が含まれる。

認証が成功し操作部アプリ５０の権限がリクエストを実行できる権限である場合、リソース制御部４５はリクエスト行のＵＲＬに基づいてリクエストをサービス部４２のサービスに振り分ける。サービス部４２はリクエストに応じた処理を行い、設定情報やジョブの実行結果などの処理結果をＳＤＫ制御部４１の結果応答部４６に送出する。結果応答部４６はレスポンスを作成して操作部アプリ５０にレスポンスを送信する（返却する）。

認証が失敗するか又は操作部アプリ５０の権限がリクエストを実行できる権限でない場合、リソース制御部４５は認証失敗又は権限なしを結果応答部４６に通知する。結果応答部４６はレスポンスを作成して操作部アプリ５０にレスポンスを送信する（返却する）。

＜リクエスト例とレスポンス例＞
図５〜図８を用いてリクエスト例とレスポンス例について説明する。まず、図５は、リクエスト送信部３１が送信するリクエストの一例である。まず、記述１〜記述３がヘッダ情報である。記述１はリクエスト行と呼ばれる。記述１はＧＥＴメソッドを使って、「192.168.1.100」というＵＲＬ（アドレス）に対してdevicelogというＡＰＩを呼び出している。このＡＰＩはあくまで一例であるが、ログ情報を返送するＡＰＩである。「HTTP/1.1」はＨＴＴＰのバージョンである。

記述２の「Host 192.168.1.30」はリクエストの送信先のサーバ名である。仮想サーバ等を指定する場合に設定されるが、HTTP/1.1では必須である。

記述3の「OneShotAuthorization」が認証用ヘッダである。「Basic」は認証方法を示している。「aaa」はユーザ名、「bbb」はパスワードである。図５ではユーザ名とパスワードが平文になっているが、符号化や暗号化して容易に解読できないようにすることも考えられる。

図６は、結果応答部４６が送信する認証成功時のレスポンスの一例である。記述４の「HTTP /1.1 200 OK」の「２００」はステータスコードであり２００番はリクエストが成功し、レスポンスと共に要求に応じた情報が返されることを意味している。記述４のその他は書誌的な情報である。記述５はdevicelogというＡＰＩが取得して結果応答部４６に返却したログ情報の一例である。図示するＪＳＯＮ形式の他、ＸＭＬ形式などで送信されてよい。

図６のようなレスポンスを返却する場合、本体装置９０は次のように動作する。まず、リソース制御部４５が認証用ヘッダに基づく認証が成功した旨の認証結果を認証制御部４３から取得するとサービス部４２が呼び出され、サービス部４２が処理結果を結果応答部４６に送出する。結果応答部４６は記述４のようにリクエストが受け付けられた旨と、記述５のログ情報を含むレスポンスを生成する。

図７は、結果応答部４６が送信する認証失敗時のレスポンスの一例である。記述６の「HTTP /1.1 401 Unauthorized」の「４０１」というステータスコードは、認証エラーを示す。つまり、リクエストの認証用ヘッダに追加されたユーザ名/パスワードの組み合わせが認証情報保存領域４７に記憶されていないこと（ユーザ名/パスワードの組み合わせが間違っていること）を意味する。ユーザが入力したユーザ名/パスワードの組み合わせが間違っていた場合も同様である。記述７は、認証失敗を表すエラーメッセージである。

図７のようなレスポンスを返却する場合、本体装置９０は次のように動作する。結果応答部４６はリソース制御部４５から認証失敗の通知を受けると、記述６のように認証失敗でリクエストが拒否された旨と、記述７のようにユーザ名/パスワードの組み合わせが間違っている旨を示すエラーメッセージを含むレスポンスを生成する。

図８は、結果応答部４６が送信する権限なしを示すレスポンスの一例である。記述８の「HTTP /1.1 403 Forbidden」の「４０３」というステータスコードは、リクエスト先のＵＲＬは存在するが、情報を表示する権限が付与されず、アクセスが拒否されたことを示す。つまり、認証用ヘッダのユーザ名/パスワードは正しいが情報へのアクセス権がない場合、権限なし表すステータスコード４０３が返却される。情報へのアクセス権がないとは、例えば、管理者権限が必要なＡＰＩに対して一般ユーザがリクエストした場合などである。記述９は、権限なしを表すエラーメッセージである。

図８のようなレスポンスを返却する場合、本体装置９０は次のように動作する。結果応答部４６は、リソース制御部４５から権限なしの通知を受けると、記述８のように権限なしでリクエストが拒否された旨と、記述９のように情報を表示する権限が付与されなかった旨を示すエラーメッセージを含むレスポンスを生成する。

＜動作手順＞
図９は、主に本体装置９０の処理手順を示す一例のフローチャート図である。図９の処理は例えば画像形成装置１００が起動中にスタートする。

まず、リクエスト管理部４４は操作部８０からリクエストを受信する（Ｓ１０１）。リクエスト管理部４４は、ヘッダ情報をリソース制御部４５に送出する。

リソース制御部４５は、ヘッダ情報に基づいてシステム権限に対するリクエストか否かを判断する（Ｓ１０２）。システム権限とは操作部８０が非同期でイベントを受け取る場合に必要になる特別な権限である。管理者権限や一般ユーザの権限とは異なる権限である。システム権限へのリクエストか否かは、例えばヘッダ情報のリクエスト行のＵＲＬに基づいて判断される。

ステップＳ１０２でＹｅｓと判断された場合、認証用ヘッダ又はユーザが入力した認証情報に基づく認証は行われないので、処理はステップＳ１０５に進み、ステップＳ１０２でＮｏと判断された場合、Ｓ１０３に進む。

ステップＳ１０３では、リソース制御部４５はリクエストに認証用ヘッダがあるか否かを判断する（Ｓ１０３）。つまり、ヘッダ情報にOneShotAuthorizationというヘッダ行があるか否かを判断する。

認証用ヘッダがある場合（Ｓ１０３のＹｅｓ）、リソース制御部４５は認証用ヘッダのユーザ名とパスワードを利用して認証制御部４３に認証を依頼し、認証結果を取得する（Ｓ１０４）。これにより、操作部アプリ５０の権限を含む認証結果が取得される。

認証用ヘッダがない場合（Ｓ１０３のＮｏ）、リソース制御部４５は認証制御部４３からユーザログインアプリ４０が送信したユーザの認証結果を取得する（Ｓ１０８）。これにより、操作部８０のユーザログインアプリ４０からログインしているユーザの権限を含む認証結果が取得される。ユーザがログインしていなければその旨が通知される。

次に、リソース制御部４５は要求元（操作部アプリ５０又はユーザ）がリクエストに対する権限を有するか否かを判断する（Ｓ１０５）。認証結果には要求元の権限が入っており、この権限とリクエスト行のＵＲＬのＡＰＩに必要な権限を比較する。認証用ヘッダがある場合は、認証用ヘッダの認証結果を利用し、認証用ヘッダがない場合はユーザの認証結果を利用する。すなわち、操作部アプリ５０の権限とリクエスト行のＵＲＬのＡＰＩに必要な権限を比較するか、又は、ユーザの権限とリクエスト行のＵＲＬのＡＰＩに必要な権限を比較する。

なお、システム権限に対するリクエストの場合、要求元は一般ユーザでも管理者でもないが、同様にリクエストのヘッダ情報には要求元が操作部８０であることを意味する情報が含まれているものとする。これにより、リクエストに対し要求元がシステム権限を有するか否かが判断される。

リクエストに対して要求元が権限を有する場合（Ｓ１０５のＹｅｓ）、リソース制御部４５はサービス部４２に対し処理要求を行う（Ｓ１０６）。サービス部４２はリクエスト内容に応じて処理を実行する。処理が完了したらサービス部４２はＳＤＫ制御部４１の結果応答部４６に処理結果を渡す。結果応答部４６は処理内容を含むレスポンスを作成する。

リクエストに対して権限がない場合（Ｓ１０５のＮｏ）、リソース制御部４５は認証失敗又は権限なしを結果応答部４６に通知する。結果応答部４６は認証失敗又は権限なしのレスポンスを作成する（Ｓ１０９）。

以上により、ステップＳ１０７では、結果応答部４６が操作部８０から送信されたリクエストに対してレスポンスを送信する（Ｓ１０７）。

したがって、図９の処理によれば、リクエストに認証用ヘッダがある場合は、操作部アプリ５０の権限でサービス部４２を利用できる。この場合、ユーザがログインしていてもしていなくてもよい。したがって、操作部アプリ５０は、ユーザがログインしていなくても本体装置９０に処理を要求できる。

また、一般ユーザがログインしていても、操作部アプリ５０が管理者権限でログインすれば、操作部アプリ５０が動作するために必要な例えば管理者権限の情報を取得できる。管理者がログインしているが、操作部アプリ５０が認証用ヘッダのあるリクエストを送信した場合、操作部アプリ５０の権限で動作するので、操作部アプリ５０の権限が一般ユーザであれば操作部アプリ５０がジョブを実行できる。

＜外部装置からリクエスト＞
以上の実施形態では、画像形成装置という１台の装置の中で認証情報が送信され、処理結果が返却される実施例を説明したが、以下では、別々の装置間における認証について説明する。

図１０は、画像形成装置と外部装置を有するシステムの概略構成図の一例である。画像形成装置１００と外部装置７０はネットワークを介して通信することができる。画像形成装置１００は外部装置７０に対しＷｅｂ ＡＰＩを提供しており、外部装置７０はＷｅｂ ＡＰＩを介して画像形成装置１００と通信することができる。例えば、外部装置７０としてＰＣで動作するプリンタドライバやブラウザソフトウェアは画像形成装置１００に関する情報を取得して表示できる。また、外部装置７０として任意のサーバが画像形成装置１００の情報を取得して異常を監視するような使い方もある。

しかし、外部装置７０が送信するリクエストに認証用ヘッダが存在することで、外部装置７０が一般ユーザ権限又は管理者権限を変更できてしまうと、セキュリティ上、好ましくないおそれがある。このため、ネットワークを介して送信された外部装置７０からのリクエストに認証用ヘッダが含まれていても画像形成装置１００は無視することが好ましい。

図１０では、外部装置７０が送信したリクエストに認証用ヘッダ(OneShotAuthorization)が存在するが、画像形成装置１００は認証用ヘッダを無視する。このため、一般の外部装置７０からリクエストしたことになる。したがって、上記した図９の処理は実行されない。つまり、認証失敗か、又は、認証用ヘッダ以外に認証情報があり認証成功しても、devicelogのように管理者権限が必要なリクエストは権限なしと判断される。

なお、外部装置７０に対応するための機能ブロック図は図４と同じでよく、リクエスト管理部４４は外部装置７０が送信したリクエストを受信する。また、外部装置７０としては一般的なＰＣ、タブレット型端末、スマートフォン、及び、ウェアラブルＰＣなどでよい。

図１１は、外部装置７０からのリクエストを処理する手順を示すフローチャート図の一例である。

まず、リクエスト管理部４４がリクエストを受信する（Ｓ２０１）。リクエスト管理部４４はヘッダ情報をリソース制御部４５に送出する。

リソース制御部４５は外部装置７０から受信したか否かを判断する（Ｓ２０２）。判断方法としては、リクエストの送信元のＩＰアドレスを確認する方法がある。この場合、操作部８０のＩＰアドレスが予めリソース制御部４５により把握されており、このＩＰアドレスと送信元のＩＰアドレスを比較する。あるいは、リソース制御部４５がトークンのような識別情報を操作部８０に予め渡しておき、そのトークンがヘッダ情報に含まれているか否かにより判断してもよい。

ステップＳ２０２の判断がＹｅｓの場合、リソース制御部４５は認証用ヘッダを削除する（Ｓ２０３）。あるいは、認証用ヘッダを無視するか又は認証用ヘッダがないものとみなす。

ステップＳ２０２の判断がＮｏの場合、リソース制御部４５は認証用ヘッダを削除しなせず、図９の処理が実行される。

認証用ヘッダを削除した場合、リソース制御部４５は外部装置からの認証要求に対する従来と同様の認証処理を行う（Ｓ２０５）。

したがって、外部装置７０からのリクエストは認証用ヘッダが削除されるので、外部装置７０からの従来のリクエストと判断され、認証と権限に基づく処理を行うことができ、セキュリティが低下することはない。

＜その他の適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、本実施形態では画像形成装置１００を例にして説明したが、画像形成装置１００に限られず認証する機能を有する情報処理装置に適用できる。情報処理装置の例としては、例えば電子黒板、プロジェクタ、テレビ会議端末、などでもよい。

また、図４などの構成例は、画像形成装置１００による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本発明が制限されることはない。また、画像形成装置１００の処理は、処理内容に応じて更に多くの処理単位に分割することもできる。また、１つの処理単位が更に多くの処理を含むように分割することもできる。

なお、認証制御部４３は認証手段の一例であり、リクエスト管理部４４は認証要求受信手段の一例であり、リソース制御部４５は認証制御手段の一例であり、サービス部４２は処理手段の一例である。ユーザログインアプリ４０が入力を受け付ける認証情報は第１の認証情報の一例であり、認証用ヘッダは第２の認証情報の一例であり、操作部アプリ５０は第１のアプリケーションソフトの一例であり、ユーザログインアプリ４０は第２のアプリケーションソフトの一例である。

４０ ユーザログインアプリ
５０ 操作部アプリ
７０ 外部装置
８０ 操作部
９０ 本体装置
１００ 画像形成装置

特開2010−072760号公報

Claims (9)

1. ユーザが入力した第１の認証情報に基づいて前記ユーザの認証を行う認証手段と、
   第１のアプリケーションソフトが生成する認証要求を受信する認証要求受信手段と、
   前記認証要求受信手段が受信した前記認証要求に第２の認証情報が含まれている場合、前記第２の認証情報に基づいて前記第１のアプリケーションソフトを認証し、前記認証要求に前記第２の認証情報が含まれていない場合、前記認証手段から前記ユーザの認証結果を取得する認証制御手段と、
   前記第２の認証情報に基づく認証結果又は前記ユーザの認証結果に基づいて処理を行う処理手段と、
   を有することを特徴とする情報処理装置。
2. 前記ユーザが前記第１の認証情報を入力していないため前記認証手段が前記第１の認証情報に基づいて前記ユーザの認証を行っておらず、前記認証要求に第２の認証情報が含まれている場合、
   前記認証制御手段は、前記第２の認証情報に基づいて前記第１のアプリケーションソフトを認証し、
   前記処理手段は、前記第２の認証情報に基づく認証結果に基づいて処理を行うことを特徴とする請求項１に記載の情報処理装置。
3. 前記認証要求に第２の認証情報が含まれ、前記第２の認証情報に基づく認証結果に管理者権限が含まれており、
   前記認証手段による前記ユーザの認証結果に一般ユーザの権限が含まれている場合、
   前記処理手段は管理者権限に基づいて処理を行うことを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記認証要求に第２の認証情報が含まれ、前記第２の認証情報に基づく認証結果に一般ユーザの権限が含まれており、
   前記認証手段による前記ユーザの認証結果に管理者権限が含まれている場合、
   前記処理手段は一般ユーザの権限に基づいて処理を行うことを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
5. ユーザが操作を入力する操作部と、
   前記操作部と通信する本体装置とを有し、
   前記操作部では、ユーザからの認証情報を受け付け前記本体装置に送信する第２のアプリケーションソフトと、ユーザが操作しなくても動作する前記第１のアプリケーションソフトが動作しており、
   前記第１のアプリケーションソフトは、前記本体装置に送信するリクエストに前記第２の認証情報を含めるか含めないかを切り替え、前記リクエストを前記認証要求として前記本体装置に送信することを特徴とする請求項１〜３のいずれか１項に記載の情報処理装置。
6. 前記リクエストのヘッダ情報に前記第２の認証情報が含まれることを特徴とする請求項５に記載の情報処理装置。
7. 前記認証制御手段は、ネットワークを介して通信する外部装置から前記第２の認証情報が含まれている前記認証要求を前記認証要求受信手段が受信した場合、
   前記認証要求に前記第２の認証情報が含まれていないものとみなすことを特徴とする請求項６に記載の情報処理装置。
8. 認証手段が、ユーザが入力した第１の認証情報に基づいて前記ユーザの認証を行うステップと、
   認証要求受信手段が、第１のアプリケーションソフトが生成する認証要求を受信するステップと、
   認証制御手段が、前記認証要求受信手段が受信した前記認証要求に第２の認証情報が含まれている場合、前記第２の認証情報に基づいて前記第１のアプリケーションソフトを認証し、前記認証要求に前記第２の認証情報が含まれていない場合、前記認証手段から前記ユーザの認証結果を取得するステップと、
   処理手段が、前記第２の認証情報に基づく認証結果又は前記ユーザの認証結果に基づいて処理を行うステップと、
   を有することを特徴とする認証方法。
9. 情報処理装置を、
   ユーザが入力した第１の認証情報に基づいて前記ユーザの認証を行う認証手段と、
   第１のアプリケーションソフトが生成する認証要求を受信する認証要求受信手段と、
   前記認証要求受信手段が受信した前記認証要求に第２の認証情報が含まれている場合、前記第２の認証情報に基づいて前記第１のアプリケーションソフトを認証し、前記認証要求に前記第２の認証情報が含まれていない場合、前記認証手段から前記ユーザの認証結果を取得する認証制御手段と、
   前記第２の認証情報に基づく認証結果又は前記ユーザの認証結果に基づいて処理を行う処理手段、
   として機能させるためのプログラム。

Images