JP2012181601A - 情報処理システム、情報処理装置、及び情報処理装置の制御方法 - Google Patents
情報処理システム、情報処理装置、及び情報処理装置の制御方法 Download PDFInfo
- Publication number
- JP2012181601A JP2012181601A JP2011042659A JP2011042659A JP2012181601A JP 2012181601 A JP2012181601 A JP 2012181601A JP 2011042659 A JP2011042659 A JP 2011042659A JP 2011042659 A JP2011042659 A JP 2011042659A JP 2012181601 A JP2012181601 A JP 2012181601A
- Authority
- JP
- Japan
- Prior art keywords
- authentication
- web
- user
- web browser
- screen
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Withdrawn
Links
Images
Abstract
【課題】Webサーバで認証処理を実行させつつ、その認証が成功した場合に情報処理装置が備える機能を使用可能な仕組みを提供する。
【解決手段】本発明の情報処理装置は、ネットワークに接続されたWebサーバから認証のための操作画面を取得し、取得した操作画面を表示することによりユーザからの認証データの入力操作を受け付け、受け付けた認証データを用いた認証処理を前記Webサーバに要求し、認証が成功した旨の通知を前記Webサーバから受けた場合に前記情報処理装置が備える機能のユーザによる使用を許可する。
【選択図】図4
【解決手段】本発明の情報処理装置は、ネットワークに接続されたWebサーバから認証のための操作画面を取得し、取得した操作画面を表示することによりユーザからの認証データの入力操作を受け付け、受け付けた認証データを用いた認証処理を前記Webサーバに要求し、認証が成功した旨の通知を前記Webサーバから受けた場合に前記情報処理装置が備える機能のユーザによる使用を許可する。
【選択図】図4
Description
本発明は、Webサーバと、当該Webサーバによって提供される操作画面を表示するためのWebブラウザを有する情報処理装置とを含む情報処理システム、当該情報処理システムを構成する情報処理装置、及び情報処理装置の制御方法に関する。
従来より、情報処理装置が備える認証アプリケーションにより、認証画面の出力を行うと共に、ユーザから受け付けた認証情報によって認証処理を行って、認証が成功した場合に、情報処理装置が備える機能をユーザに提供する技術がある。当該認証処理は、ユーザの認証情報を情報処理装置に予め登録された認証情報と照合することで行う。または、ネットワークで接続されたLDAP(Lightweight Directory Access Protocol)サーバによって管理される認証情報を照合する方法等がある。LDAPサーバを使用する場合、認証処理のために照合する認証情報を一元管理することが可能になる。
また、情報処理装置がネットワーク上のWebサーバと接続されるシステムにおいて、Webサーバにより提供される認証画面を情報処理装置のWebブラウザ上に表示することで、ユーザに認証のための操作を促し、入力された情報を用いてWebサーバで認証処理を行った後、Webサーバが有する機能の使用を可能とする技術がある。
この場合、情報処理装置がネットワーク上のWebサーバに対して認証画面を要求し、Webサーバ上のWebアプリケーションが情報処理装置からの要求に応えて、Webブラウザに認証画面を表示させるためのHTMLファイルを情報処理装置に送信する。情報処理装置のWebブラウザは受信したHTMLファイルを解析し、受信したHTMLファイルの記述に基づいた操作画面を表示する。
更に、Webブラウザに表示された認証画面に従ってユーザが認証情報を入力すると、入力された情報をWebブラウザがWebサーバに対して通知する。そして、この通知を受けたWebサーバ上のWebアプリケーションが入力された情報を基に、Webサーバ上に持つ認証情報を照会し、認証処理を行う。認証された場合にはサーバの機能がユーザに提供される。これにより、ユーザが操作する操作画面をWebサーバで一括管理することが可能になる。
最近では、プリンタやスキャナの機能を備えたMFP(Multi Function Pripheral)の中にも上述のようなWebブラウザを備えるものがある。MFPは上述した手順によってWebサーバから提供される認証画面をMFPのWebブラウザ上に表示し、ユーザからの認証情報の入力を受け付ける。これにより、MFPにおいても上記と同様の認証が可能となる。
また、ユーザの使用する操作画面の管理のために、特許文献1のような技術も考えられている。特許文献1の記述によれば、ユーザがMFPの操作を行う際に操作画面に表示される画面を制御するため、あらかじめ各ユーザに応じて画面遷移情報をWebサーバに登録しておく。MFPとネットワークによって接続するWebサーバにおいて、使用しているユーザと画面遷移情報に基づいて次に表示する画面を判断し、MFPが備えるWebブラウザに表示することで、ユーザに応じて適切な操作画面を提供する。
従来の技術では、MFPが備えるログインアプリケーションによって認証を行った後にMFPのアプリケーションの機能を使用すること、又は特許文献1のように、MFPが備えるWebブラウザを使用してWebサーバに認証要求を行い、Webサーバによって認証を行った後にWebサーバが備える機能を使用することしかできなかった。
一方、Webサーバで一元管理された、認証情報と認証画面とによってユーザの認証を行いたいが、使用するアプリケーションはMFPが備えるアプリケーションであるような場合には対応できなかった。
また、MFPとWebサーバとの間をネットワークで接続するシステムの場合、一般的にWebサーバからデータの受信を行うエンドポイントのURIは常に固定されているため、例えば、ユーザが不正にエンドポイントのURIにアクセスすることでMFPを不正使用できてしまう可能性がある。
特許文献2には、クライアントPCから印刷データを受信するMFPのポートに対して、不正に印刷ジョブを送り、印刷されてしまうことを防止する技術が開示されている。この技術は、動的にポートのURIを変更し、さらにポートが開いているかどうかを管理することで不正な印刷や印刷妨害などの行為を防ぐものである。
しかし、この場合においても、クライアントPCから通常の手続きを踏んでアクセスされた場合、クライアントPCに対して印刷ジョブ受信用のポートを割り当て、通信を受け付けてしまう。そのため、不正に印刷が行われてしまう可能性がある。
上記課題を解決するため、本発明に係るシステムは、
情報処理装置と、前記情報処理装置に出力するための画面データ及びユーザを認証するための認証データを管理する管理データベースを有するWebサーバとを含むシステムであって、
前記情報処理装置のWebブラウザが、前記Webサーバに対して認証用画面データのリクエストを行い、
前記WebサーバのWebアプリケーションが、前記Webブラウザからの認証用画面データのリクエストに応じて認証用画面データを前記Webブラウザに送信し、
前記情報処理装置のWebブラウザが、前記Webアプリケーションから取得した認証用画面データに従った画面を表示し、表示した画面によりユーザから認証データの入力を受け付け、受け付けた認証データを用いて前記Webアプリケーションに認証処理リクエストを行い、
前記WebサーバのWebアプリケーションが、前記Webブラウザから受信した認証データと前記管理データベースで管理されている認証データとを照合することにより認証処理を行い、前記Webブラウザに認証結果の通知を行い、
前記情報処理装置のログインアプリケーションロジックが、前記認証結果の通知が認証成功である旨を示す場合に、前記情報処理装置が備える機能のユーザによる使用を許可することを特徴とする。
情報処理装置と、前記情報処理装置に出力するための画面データ及びユーザを認証するための認証データを管理する管理データベースを有するWebサーバとを含むシステムであって、
前記情報処理装置のWebブラウザが、前記Webサーバに対して認証用画面データのリクエストを行い、
前記WebサーバのWebアプリケーションが、前記Webブラウザからの認証用画面データのリクエストに応じて認証用画面データを前記Webブラウザに送信し、
前記情報処理装置のWebブラウザが、前記Webアプリケーションから取得した認証用画面データに従った画面を表示し、表示した画面によりユーザから認証データの入力を受け付け、受け付けた認証データを用いて前記Webアプリケーションに認証処理リクエストを行い、
前記WebサーバのWebアプリケーションが、前記Webブラウザから受信した認証データと前記管理データベースで管理されている認証データとを照合することにより認証処理を行い、前記Webブラウザに認証結果の通知を行い、
前記情報処理装置のログインアプリケーションロジックが、前記認証結果の通知が認証成功である旨を示す場合に、前記情報処理装置が備える機能のユーザによる使用を許可することを特徴とする。
本発明によれば、Webサーバで認証処理を実行させつつ、その認証が成功した場合にユーザが情報処理装置が備える機能を使用可能な仕組みを提供することができる。
また、Webサーバに認証処理を依頼したユーザと異なるユーザが情報処理装置にアクセスした場合に、権限のないユーザが情報処理装置が備える機能を不正に使用することを防止可能な仕組みを提供することができる。
以下、図面を参照して本発明の実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に関わる発明を限定するものでなく、また、実施形態で説明されている特徴の組み合わせのすべてが発明の解決手段に必須のものとは限らない。
(第1の実施形態)
図1は、本発明の第1の実施形態における情報処理システムの全体構成を示す図である。LAN110のネットワーク上にMFP101およびWebサーバ102が互いに通信可能に接続されている。なお、LAN110は、説明の便宜上、LAN(ローカル・エリア・ネットワーク)と記載しているが、インターネットなどの他のネットワークでも構わない。
図1は、本発明の第1の実施形態における情報処理システムの全体構成を示す図である。LAN110のネットワーク上にMFP101およびWebサーバ102が互いに通信可能に接続されている。なお、LAN110は、説明の便宜上、LAN(ローカル・エリア・ネットワーク)と記載しているが、インターネットなどの他のネットワークでも構わない。
図2は、MFP101の構成を示すブロック図である。CPU211を含む制御部210は、MFP101全体の動作を制御する。CPU211は、ROM212に記憶された制御プログラムを読み出して読み取り制御や送信制御などの各種制御を行う。RAM213は、CPU211の主メモリ、ワークエリア等の一時記憶領域として用いられる。HDD214は、画像データや各種プログラム、或いは各種情報テーブルを記憶する。
操作部I/F217は、操作部221と制御部210とを接続する。操作部221には、タッチパネル機能を有する液晶表示部やキーボードなどを含む。操作部221にはMFP101の操作画面が表示され、ユーザからの入力操作を受け付ける。また、MFP101は、Webブラウザ410を有する。MFP101のWebブラウザ410は、Webサーバ102から受信したHTMLファイルを解析し、受信したHTMLファイルの記述に基づく操作画面を操作部221の液晶表示部に表示する。ここで、MFP101のWebブラウザ410が受信するHTMLファイルは必ずしもWebサーバ102から受信したものでなくても構わない。例えば、MFP101内部のサーブレットアプリケーションから受信したHTMLファイルでも構わない。
プリンタI/F215は、プリンタ219と制御部210とを接続する。プリンタ219で印刷すべき画像データはプリンタI/F215を介して制御部210からプリンタ219に転送され、プリンタ219において記録媒体上に印刷される。
スキャナI/F216は、スキャナ220と制御部210とを接続する。スキャナ220は、原稿上の画像を読み取って画像データを生成し、スキャナI/F216を介して制御部210に入力する。
ネットワークI/F218は、制御部210(MFP101)をLAN110に接続する。ネットワークI/F218は、LAN110上の外部装置(例えば、Webサーバ102)に画像データや情報を送信したり、LAN110上の外部装置から各種情報を受信したりする。
図3は、Webサーバ102の構成を示すブロック図である。
CPU311を含む制御部310は、Webサーバ102全体の動作を制御する。CPU311は、ROM312に記憶された制御プログラムを読み出して、各種制御処理を実行する。RAM313は、CPU311の主メモリ、ワークエリア等の一時記憶領域として用いられる。HDD314は、画像データや各種プログラム、或いは各種情報テーブルを記憶する。
ネットワークI/F315は、制御部310(Webサーバ102)をLAN110に接続する。ネットワークI/F315は、LAN110上の他の装置との間で各種情報を送受信する。
図4は、情報処理システム全体のソフトウェア構成を説明するための図である。図4に示す各機能部は、MFP101やWebサーバ102が備えるCPU311が制御プログラムを実行することによって実現される。
MFP101は、Webブラウザ410、ログインアプリケーションロジック420、アクセス制御情報記憶部430、プリファレンス情報記憶部440、及びログインフレームワーク470を備える。アクセス制御情報記憶部430、プリファレンス情報記憶部440は、MFP101に出力するための画面データ及びユーザを認証するための認証データを管理する管理データベースとして機能する。
Webブラウザ410は、通信部411、解析部412、及び画面表示部413を含む。通信部411は、HTTPプロトコルにしたがってWebアプリケーション450のプレゼンテーション部451と通信する。具体的には、通信部411はURIによって特定されるWebアプリケーション450のリソースに対してGETまたはPOSTのHTTPリクエストを送信する。つまり、指定されたURIをアクセス先としてWebブラウザ410がアクセスを行う。そして、HTTPリクエストに対するHTTPレスポンスとして、Webブラウザで表示するためのHTML形式等で記述された操作画面をWebアプリケーション450から取得する。また、Webブラウザ410に表示したHTMLフォームに入力されたユーザからの操作を、HTTPリクエストによってWebアプリケーション450に通知する。解析部412は、Webアプリケーション450から受信するHTMLファイルを解析する。このHTMLファイルにはWebブラウザ410に表示するべき操作画面の内容を示す記述が含まれる。画面表示部413は、解析部412による解析の結果に基づいて、操作部221に操作画面を表示する。このように、Webサーバ102から受信した情報に基づいて表示される画面をWebブラウザ画面と呼ぶこととする。
ログインアプリケーションロジック420は、リクエスト生成部421、ログインコンテキスト生成部422を含む。リクエスト生成部421は、Webブラウザ410がWebアプリケーション450と通信を行うために必要なHTTPリクエストを生成する。生成したリクエストはWebブラウザ410の通信部411からWebアプリケーション450のプレゼンテーション部451にPOSTさせる。ログインコンテキスト生成部422は、Webアプリケーション450のログイン通知部452から通知された、ログインユーザに関するログインコンテキストを生成する。ログインコンテキストは、認証されたユーザを示す情報であり、ユーザが入力した認証情報(認証データ)を含む。ユーザはログインコンテキストが生成されることによりMFP101の各機能へのアクセスが可能となり、プリファレンス情報記憶部440に登録された情報にしたがって、ユーザに応じた機能が提供される。なお、ログインアプリケーションロジック420の機能は、Webブラウザ410の機能をプラグインソフトウェアにより拡張すること(ADD−ON)によって実現しても構わない。
アクセス制御情報記憶部430は、MFP101を使用する各ユーザについて、MFP101が提供する各種機能や資源に対する、実行や読み出し、書き込み等のアクセスを制御するためのアクセス制御情報を記憶する。アクセス制御情報とは、カラー印刷処理を禁止し白黒印刷処理を許可する、片面印字を禁止し図面プリントを許可する、文書の送信を禁止しコピーを許可する、管理者用設定パラメータの変更を禁止し一般ユーザ用設定パラメータの変更を許可する、等の情報である。アクセス制御情報はシステム管理者がアクセス制御情報記憶部430に予め設定できる。また、外部サーバに記憶され管理されているアクセス・コントロール・リスト(ACL)等をネットワーク経由で利用するように構成することもできる。
プリファレンス情報記憶部440は、MFP101を使用する複数のユーザのそれぞれについて、MFP101の動作に関した各種の好みを表現するためのプリファレンス情報を記憶する。プリファレンス情報とは、カラーよりもモノクロの処理を好む、用紙サイズはA4サイズよりもB5サイズを好む、読み取り画像のプレビュー画面を確認してから送信することを好む等の情報のことを指す。プリファレンス情報は、ユーザや管理者がプリファレンス情報記憶部440に予め設定できる。また、当該ユーザによる過去の操作履歴から好みを自動で判定し、プリファレンス情報として自動設定することもできる。
ログインフレームワーク470は、ログインアプリケーションロジック420を管理し、ログイン要求をログインアプリケーションロジック420に対して行う。
Webサーバ102は、Webアプリケーション450及び認証情報記憶部460を含む。さらに、Webアプリケーション450は、プレゼンテーション部451、ログイン通知部452、及び認証処理部453を含む。プレゼンテーション部451は、通信部411と通信し、MFP101からの画面要求に応えてMFP101のWebブラウザ410で表示すべき操作画面をMFP101に送信する。また、MFP101のWebブラウザ410に表示された操作画面を介して入力された、ユーザからの指示をMFP101からHTTPリクエストとして受け取る。この際、プレゼンテーション部451は通信部411からのHTTPリクエストを解析し、その結果に応じた認証画面(認証用画面データ)を、通信部411を介してWebブラウザ410に送信する。ユーザの認証情報が通信部411から送信された場合、認証処理部453に認証情報を送信して認証処理を行わせる。認証処理部453はプレゼンテーション部451から受け取った認証情報と、認証情報記憶部460に登録されている認証情報とを照らし合わせることによって認証を行う。照らし合わせた結果、プレゼンテーション部451から受け取った認証情報が正しいものであると判断された場合、ログイン通知部452にログインが成功したことを通知する。認証情報が間違ったものであると判断された場合にはプレゼンテーション部451にログインエラーの表示を行わせる。ログイン通知部452は、認証処理部453の照合の結果、認証情報記憶部460にユーザがWebブラウザ410で入力した認証情報が存在した場合、ログインアプリケーションロジック420にログインが成功した旨を通知する。この認証結果の通知によりログインコンテキスト生成部422がログインコンテキストを生成し、ユーザがMFP101の機能を使用可能になる。ログイン認証処理後はMFP101のメイン画面が出力される。なお、このメイン画面はWebサーバによって提供されるものではなく、MFP101内で情報を保持し、表示されるものである。このようにMFP101自身にあらかじめ保存されている情報に基づいて表示される画面をネイティブ画面と呼ぶこととする。
認証情報記憶部460は、予め登録されたユーザ名と対応するパスワードを記憶する。認証処理部453が認証を行う際に登録された情報を参照し照合する。
ここまでで本実施形態におけるシステム構成の概要を説明した。引き続き、本実施形態におけるシステムの処理の流れの概要を説明する。
図5は本実施形態における、ログインフレームワーク470が認証処理をログインアプリケーションロジック420に要求してから、認証成功の応答が返ってくるまでのシーケンス図である。
ステップS501では、ログインフレームワーク470がログインアプリケーションロジック420に認証処理要求(認証処理リクエスト)を行う。
ステップS502では、Webブラウザ410がWebアプリケーション450と接続を行うためのHTTPリクエストをログインアプリケーションロジック420が生成する。
ステップS503では、ログインアプリケーションロジック420がWebブラウザ410に対して、ステップS502で生成したHTTPリクエストを送信する。
ステップS504では、Webブラウザ410がステップS503で送信されたHTTPリクエストをもとにWebアプリケーション450に対して、ログイン画面を描画するためのHTMLファイル取得要求を行う。
この際、Webアプリケーション450が行うHTMLファイル生成処理(S505)を詳細に説明する。図6に本例の画面取得処理におけるWebアプリケーション450のフローチャートを示す。
ステップS601では、ステップS504でWebブラウザ410が送信したHTTPリクエストを取得する。
ステップS602では、Webブラウザ410に表示させる図7に示す認証画面701のHTMLファイルを生成する。
ステップS603では、ステップS601で受信したHTTPリクエストのヘッダを解析する。
ステップS604では、ステップS603で解析した結果、リクエストヘッダ内にキー認証情報が含まれているか否かを判定する。
ステップS604でリクエストヘッダ内にキー認証情報が含まれていないと判定された場合には、ステップS605において、ステップS602で生成したHTMLファイルを認証エラー用のHTMLファイルに作り変える。リクエストヘッダ内にキー認証情報が入っていないということは、ユーザがログイン後にWebブラウザを介して、アクセスを行ったことを意味する。よって、複数回ログインしてしまうことを防止するため、エラーページへ飛ばす処理をここで行っている。一方、ステップS604でリクエストヘッダ内にキー認証情報が含まれていると判定された場合には、ステップS605の処理を行わずに、ステップS606に進む。
ステップS606では、生成されたキー認証画面用のHTMLファイルをWebブラウザ410に送信する。
以上が、本例の画面取得処理におけるWebアプリケーション450の処理である。この後、ステップS506においてWebブラウザ410はHTMLファイルを取得し、ステップS507で認証画面701を表示する。ユーザは認証画面701に従ってキー入力することで認証情報を入力する。なお、入力方法はキー入力に限らない。MFP101に接続されたUSB認証機器等によりユーザIDやパスワードを取得する方法でも構わない。
続いて、ステップS508では、Webブラウザ410はユーザから入力された認証情報を取得する。具体的には、Webブラウザ410は認証画面701のOKボタン710が押下されたか否かを判定する。OKボタン710が押下されたと判定した場合には、ステップS510に進む。
ステップS509では、ステップS508で取得した認証情報をリクエストヘッダに記載し、Webアプリケーション450に送信する。
ステップS510では、ステップS509でWebブラウザ410から送信された認証情報の認証処理を行う。図8に本例の認証処理におけるWebアプリケーション450のフローチャートを示す。
ステップS801では、ステップS509でWebブラウザ410から送信された認証情報を取得する。
ステップS802では、ステップS801で取得した認証情報と認証情報記憶部460に格納されているデータとの照合を行う。
ステップS803では、ステップS802で照合を行った結果、認証情報が一致するデータが見つかったか否かを判定する。
ステップS804は、ステップS803で認証情報が一致するデータが見つかった場合の処理であり、ログイン成功通知をログインアプリケーションロジック420に対して送信する。
ステップS805は、ステップS803で認証情報が一致するデータが見つからなかった場合の処理であり、ログインエラーを通知するHTMLファイルを生成し、Webブラウザ410に送信する。Webブラウザ410はそれを受けて、ログインエラー画面を表示する。
以上が、本例の認証処理におけるWebアプリケーション450のフローチャートである。この認証処理を経て、ステップS511においてログインアプリケーションロジック420に対してログイン通知が送信される。そして、ステップS512では、Webブラウザ410は、Webアプリケーション450から受信したログイン通知をログインアプリケーションロジック420に通知する。
ステップS513では、ログインアプリケーションロジック420がログインコンテキストを生成する。ログインコンテキストが生成されることにより、ユーザはMFP101の各機能へのアクセスが可能となる。
ステップS514では、ログインアプリケーションロジック420がログインフレームワーク470に認証成功通知を行う。
ステップS515では、ログインアプリケーションロジック420は、Webブラウザに対して、認証画面を非表示にするよう要求する。これにより、操作部221には図9で説明するMFPのネイティブ画面が表示され、ユーザはMFP101の持つ機能を使用することができるようになる。
なお、MFP101の機能を使用後、ログオフを行う場合は、ログインアプリケーションロジック420からWebサーバ102に対してログオフの通知を送ることにより、認証を行う前の状態に戻すことができる。
以上が本例におけるログインフレームワーク470が認証処理をログインアプリケーションロジックに要求してから、認証成功の応答が返ってくるまでのシーケンスである。これにより、ユーザはWebサーバ102で一元管理される認証情報と、一括管理される認証画面によって認証処理が行える。そして、認証処理後はMFP101の持つ機能を使用することができる。
(第2の実施形態)
次に、本発明の第2の実施形態について説明する。第2の実施形態では、ログインアプリケーションロジック420の中にプロキシの役割を果たす機能を備え、Webブラウザ410とWebアプリケーション450との通信内容を管理することで、ICカードリーダ等の認証機器を使用するための制御を行う。
次に、本発明の第2の実施形態について説明する。第2の実施形態では、ログインアプリケーションロジック420の中にプロキシの役割を果たす機能を備え、Webブラウザ410とWebアプリケーション450との通信内容を管理することで、ICカードリーダ等の認証機器を使用するための制御を行う。
図10は、本実施形態におけるソフトウェア構成を説明する図である。
ただし、Webブラウザ410、Webアプリケーション450の構成は、第1の実施形態で説明した構成と同じであるため、説明を省略する。
ログインアプリケーションロジック420は、プロキシ部1001、ICカードリーダ制御部1002、リクエスト生成部1003、及びログイン管理部1004を含む。
プロキシ部1001は、Webブラウザ410とWebアプリケーション450との間の通信を仲介・監視する。例えば、プロキシ部1001は、Webブラウザ410の画面要求に対してWebアプリケーション450から送信される認証画面の画面情報から、ICカードリーダが使用できる画面であるかどうかを判断する。ICカードリーダが使用できる場合には、プロキシ部1001は、ICカードリーダを読み込み待機状態にするようICカードリーダ制御部1002に通知する。ICカードリーダから得られた認証情報または、ユーザの手入力によって得られた認証情報をWebアプリケーション450に通知する。
ICカードリーダ制御部1002は、ICカードリーダの制御を行い、ユーザがICカードリーダを使用して入力した認証情報をプロキシ部1001に通知する。
リクエスト生成部1003は、Webブラウザ410がプロキシ部1001を通してWebアプリケーション450と通信を行うために必要なHTTPリクエストを生成する。生成したリクエストはWebブラウザ410の通信部411からプロキシ部1001に送られ、Webアプリケーション450にPOSTさせる。
ログイン管理部1004は、Webアプリケーション450から送信されたログインコンテキストを使い、MFP101へのログインを行う。ログイン後は、MFP101のネイティブ画面901が表示される。これにより、ユーザはMFP101の有する機能を使用することができる。
ここまでで、本実施形態におけるシステム構成の概要を説明した。引き続き、本実施形態におけるシステムの処理の流れを説明する。
まず、図11、図12は本実施形態における認証画面を表す。図11はICカードリーダを使用した場合の認証画面を表し、本画面を表示中にICカードリーダに対してICカードを近づけることで認証が行われる。なお、ICカード認証ボタン1101、キーボード認証ボタン1102を押下することにより、認証画面を切り替えることができる。図12はキーボード入力による認証画面である。ユーザID入力領域1201にユーザIDを、パスワード入力領域1202にパスワードを入力したのち、OKボタン1203を押下することで認証処理を行うことができる。
図13は、本実施形態における起動時から入力受付状態になるまでのシーケンス図である。
ステップS1301では、MFP101の起動時にログインフレームワーク470が、認証処理を開始すること(認証処理要求)をログインアプリケーションロジック420のリクエスト生成部1003に通知する。リクエスト生成部1003はステップS1302においてWebアプリケーション450に送る画面要求のためのHTTPリクエストを生成する。
ステップS1303、ステップS1304では、Webブラウザ410を画面の前面に表示するように要求する。
ステップS1305では、リクエスト生成部1003がWebブラウザ410に対し、ステップS1302において生成したHTTPリクエストを送信する。また、この時、Webブラウザ410に対して、プロキシ部1001にアクセスするためのURLを通知する。
ステップS1306において、Webブラウザ410はステップS1305で得られるプロキシ部1001のアドレスに対してHTTPリクエストを送信する。
ステップS1307では、プロキシ部1001にあらかじめ設定されているWebアプリケーション450のアドレスに対してHTMLを要求するためのHTTPリクエストを送信する。
ステップS1308では、ステップS1307で送信されたHTTPリクエストに基づき、Webブラウザ410に表示するための画面を生成する。生成されたHTMLは、ステップS1309において、プロキシ部1001に対するレスポンスとして送信される。ステップS1310では、プロキシ部1001がWebアプリケーション450から送られてくるHTMLを確認し、ICカードによる認証を行うことができる画面である場合には、ICカードリーダ制御部1002に読み込み待機を行うよう通知する。ステップS1310において、ICカードリーダが接続されていないことがわかった場合には、キーボード認証画面を再度、Webアプリケーション450に要求する。
ステップS1311では、Webブラウザ410に対してプロキシ部1001からHTMLを送信し、ステップS1312で認証画面を出力する。これにより、MFP101は認証画面を出力し、ユーザに対して認証操作を促すことができる。
次に、ICカードを使用した認証操作について説明する。図14はICカードリーダを使用した場合の認証シーケンスを示す。
ステップS1401では、ICカードリーダ制御部1002がICカードによってユーザが認証操作を行ったことを検知し、そのカードIDをプロキシ部1001に送信する。
ステップS1402では、プロキシ部1001がICカードリーダ制御部1002に対して、読み込み待機状態を解除するように通知する。
ステップS1403では、ステップS1401で得られたICカードの情報をWebアプリケーション450に送信する。
ステップS1404では、ステップS1403で送られた認証情報を基に、ログイン認証処理を行う。ログインが成功した場合に、ステップS1405において、ステップS1403に対するレスポンスとしてログインコンテキストをプロキシ部1001に送信する。
ステップS1406では、プロキシ部1001がログイン管理部1004にログインコンテキストを送信し、ステップS1407にてログインコンテキストを使用してMFP101へのログインを行う。
ステップS1408では、ログインが成功したことを受けて、Webブラウザ410を非表示にする。
ステップS1409では、認証が成功したことをログインフレームワーク470に通知する。
ログインが失敗した場合には、ステップS1405においてログイン失敗であることを表す画面を返し、Webブラウザ410に表示する。そして、再度、認証処理を行うようユーザに促す。
次に、キーボード入力による認証操作について説明する。図15は、キーボード入力によってユーザが認証操作を行う場合の認証シーケンスを示す。
まず、ステップS1501、ステップS1502では、Webブラウザ410の図11に示すキーボード認証ボタン1102が押下されたことを受けて、画面の要求をWebアプリケーション450に対して行う。
ステップS1503、ステップS1504では、画面要求に従って、キーボード認証用の画面をWebブラウザ410に送信する。これによって、画面表示がキーボード認証用の画面に切り替えられる。
ステップS1505では、認証情報を受信したことを受けて、プロキシ部1001がICカードリーダ制御部1002に対して読み込み待機解除の通知を行う。
ステップS1506では、ユーザが認証画面に対して入力した認証情報をプロキシ部1001に対して送信する。
ステップS1507では、プロキシ部1001がWebアプリケーション450に対して認証情報を送信する。
ステップS1508以降はICカードリーダを使用した認証操作と同様であるため、説明は省略する。
次に、ログアウト時の動作について説明する。図16は、ログアウトを行い、再度認証画面を表示するまでのシーケンスを示す。
ステップS1601では、デバイスに設けられたログアウトボタンやIDキーをユーザが押下することによってログインフレームワーク470がログインアプリケーションロジック420のリクエスト生成部1003に対してログアウトの通知を行う。
以下、起動時のシーケンスのステップS1302以降と同様に認証画面を出力し、ユーザに認証操作を促すためにリクエスト生成部1003は画面取得要求をWebアプリケーション450に対して行う。
以上が、プロキシを介してWebアプリケーションとの通信をすることにより認証機器の使用の可否を制御する処理の説明である。これにより、認証機器を使用した認証操作において、適切な画面表示が可能になる。
(第3の実施形態)
次に、本発明の第3の実施形態について説明する。第3の実施形態では、第1の実施形態で説明した各構成に対して、Webアプリケーション450のログイン通知部452から、MFP101のログインアプリケーションロジック420がログイン成功通知を受け取るまでの処理について説明する。ログイン成功通知を受け取る際、認証情報を受信するエンドポイントのURIを動的に変更する構成を追加することで、エンドポイントへの不正なアクセスを防ぐ。
次に、本発明の第3の実施形態について説明する。第3の実施形態では、第1の実施形態で説明した各構成に対して、Webアプリケーション450のログイン通知部452から、MFP101のログインアプリケーションロジック420がログイン成功通知を受け取るまでの処理について説明する。ログイン成功通知を受け取る際、認証情報を受信するエンドポイントのURIを動的に変更する構成を追加することで、エンドポイントへの不正なアクセスを防ぐ。
図17は本実施形態における、ログインフレームワーク470が認証処理をログインアプリケーションロジック420に要求してから、認証成功の応答が返ってくるまでのシーケンス図である。
ステップS901では、ログインフレームワーク470がログインアプリケーションロジック420に認証処理要求を行う。
ステップS902では、Webブラウザ410がWebアプリケーション450と接続を行うためのHTTPリクエストを、ログインアプリケーションロジック420のリクエスト生成部421が生成する。
ステップS903では、ログインアプリケーションロジック420がWebブラウザ410に対して、ステップS902で生成したHTTPリクエストを送信する。
ステップS904では、Webブラウザ410がステップS903で送信されたHTTPリクエストをもとに、Webアプリケーション450に対してキー認証画面を描画するためのHTMLファイルを取得するための要求を行う。
ステップS905では、ステップS904でWebブラウザ410から送られた要求をもとに画面表示のためのHTMLファイルを生成する。この際の処理は、図6と同様である。
この後、ステップS906では、Webブラウザ410はHTMLファイルをWebサーバ102から取得する。続いて、ステップS907では、Webブラウザ410は取得したHTMLファイルに従って認証画面701を表示する。
続いて、ステップS908では、Webブラウザ410はユーザから入力された認証情報を取得する。ユーザがOKボタン710を押下することで、ユーザが入力したユーザIDやパスワードを取得する。
ステップS909では、Webブラウザ410がWebサーバ102からログイン成功通知を受け取る際の受信端点であるエンドポイントのURIをランダムに生成する。例えば、“http://192.168.0.100:80/abcd”のようなURIを生成(オープン)する。「192.168.0.100」がMFP101のIPアドレスを示し、「80」がエンドポイントであるMFP101のポート番号を示し、「abcd」がディレクトリ名やファイル名を示す。この場合には、例えば、ポート番号の割り当てを変更することにより、エンドポイントのURIをランダムに生成する。
ステップS910では、Webブラウザ410は、ステップS908で取得した認証情報とステップS909で生成したエンドポイントのURIとをWebアプリケーション450に送信する。
ステップS911では、Webアプリケーション450は、ステップS910でWebブラウザ410から送信された認証情報を用いて認証処理を行う。認証処理に関しては図15と同様である。
この処理を経て、ステップS912では、Webアプリケーション450は、ステップS910で通知されたエンドポイントのURIに対してログイン成功通知を送信する。そして、ステップS913では、Webブラウザ410は、Webアプリケーション450から受信したログイン成功通知をログインアプリケーションロジック420に通知する。
ステップS914では、ログインアプリケーションロジック420は、ログイン通知がMFP101のログインアプリケーションロジック420に通知されたことを受けて、その後の不正なアクセスを防ぐため、エンドポイントのURIを削除(クローズ)する。削除してしまったエンドポイントのURIに他のエンドポイントがアクセスすることはできない。このように、エンドポイントでアクセスを受け付ける時間をWebサーバ102において認証処理を行っている間だけに局所化し、アクセスされる可能性のある時間帯を最小限にする。
なお、エンドポイントの削除処理は、あらかじめユーザによって設定されたタイムアウト時間を経過した時点で行ってもよい。例えば、ステップS910で、Webブラウザ410が、認証情報と共にエンドポイントのURIをWebアプリケーション450に送信した直後に、エンドポイントのURIを削除してしまっても構わない。この場合には、ログインが失敗した場合には、再びエンドポイントのURIを生成する必要があるが、不正アクセスされる可能性のある時間を更に短縮することができる。また、アプリケーション毎に前記タイムアウト時間を任意の時間に設定し、アプリケーション毎にエンドポイントの削除時間を切り替えても構わない。
ステップS915では、ログインアプリケーションロジック420がログインコンテキストを生成する。ログインコンテキストが生成されることにより、ユーザはMFP101の各機能へのアクセスが可能となる。
ステップS916では、ログインアプリケーションロジック420がログインフレームワーク470に認証成功通知を行う。
ステップS917では、ログインアプリケーションロジック420は、Webブラウザに対して、認証画面を非表示にするよう要求する。これにより、操作部221には図9に示すようなMFP101の機能を利用するためのネイティブ画面が表示され、ユーザはメニュー画面から使用する機能を選択することでMFP101の持つ機能の使用が可能となる。
以上が本例におけるログインフレームワーク470が認証処理をログインアプリケーションロジックに要求してから、認証成功の応答が返ってくるまでのシーケンスである。このように、ログインフレームワーク470の動作から処理が始まり、エンドポイントのURIが生成される。
これにより、不正なユーザがMFP101の外部からアクセスしようとしても、エンドポイントのURIが削除された後であれば、不正にアクセスすることはできない。また、Webブラウザ410に直接URLを入力しログイン操作を行おうとしても、ログインアプリケーションロジック420を通じた動作ではないため、エンドポイントのURIが生成されない。そのため、MFP101が二重にログインすることはない。
(他の実施形態)
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(又はCPUやMPU等)がプログラムコードを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア(プログラム)をネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ(又はCPUやMPU等)がプログラムコードを読み出して実行する処理である。この場合、そのプログラム、及び該プログラムを記憶した記憶媒体は本発明を構成することになる。
Claims (13)
- 情報処理装置と、前記情報処理装置に出力するための画面データ及びユーザを認証するための認証データを管理する管理データベースを有するWebサーバとを含むシステムであって、
前記情報処理装置のWebブラウザが、前記Webサーバに対して認証用画面データのリクエストを行い、
前記WebサーバのWebアプリケーションが、前記Webブラウザからの認証用画面データのリクエストに応じて認証用画面データを前記Webブラウザに送信し、
前記情報処理装置のWebブラウザが、前記Webアプリケーションから取得した認証用画面データに従った画面を表示し、表示した画面によりユーザから認証データの入力を受け付け、受け付けた認証データを用いて前記Webアプリケーションに認証処理リクエストを行い、
前記WebサーバのWebアプリケーションが、前記Webブラウザから受信した認証データと前記管理データベースで管理されている認証データとを照合することにより認証処理を行い、前記Webブラウザに認証結果の通知を行い、
前記情報処理装置のログインアプリケーションロジックが、前記認証結果の通知が認証成功である旨を示す場合に、前記情報処理装置が備える機能のユーザによる使用を許可することを特徴とするシステム。 - 前記情報処理装置のログインアプリケーションロジックが、前記Webアプリケーションから受信したデータが認証用画面データであるか否かを判定し、前記認証用画面データである場合に、認証機器を読み込み待機状態とし、前記認証機器を介してユーザから受け付けた認証データを前記Webアプリケーションに送信することを特徴とする請求項1に記載のシステム。
- 前記Webブラウザがユーザから受け付けた認証データは、前記認証処理リクエストのヘッダに埋め込まれることを特徴とする請求項1に記載のシステム。
- 前記ログインアプリケーションロジックは、前記Webブラウザの機能に含まれることを特徴とする請求項1に記載のシステム。
- 前記ログインアプリケーションロジックは、前記情報処理装置が備える機能のログオフをユーザから指示された場合に、前記Webサーバに対してログオフの通知を行うことを特徴とする請求項1に記載のシステム。
- 前記Webブラウザがユーザから受け付けた認証データを用いて認証処理リクエストを前記Webアプリケーションに行う際に、前記情報処理装置のエンドポイントのURIをランダムに生成して前記Webアプリケーションに通知し、
前記情報処理装置のログインアプリケーションロジックが、前記認証結果の通知が認証成功である旨を示す場合に、前記エンドポイントのURIを削除することを特徴とする請求項1に記載のシステム。 - 前記Webブラウザは、生成したエンドポイントのURIを前記認証処理リクエストのヘッダに埋め込むことを特徴とする請求項6に記載のシステム。
- 前記Webアプリケーションは、前記エンドポイントのURIが前記認証処理リクエストのヘッダに埋め込まれていない場合に、前記認証処理を行わないことを特徴とする請求項7に記載のシステム。
- 前記Webブラウザが前記認証結果の通知を受け取る時間帯は、前記エンドポイントのURIが生成されてから削除されるまでの間の時間帯に限られることを特徴とする請求項6に記載のシステム。
- 前記Webブラウザが前記認証処理リクエストを行ってから前記認証結果の通知を受信するまでのタイムアウト時間が予め設定されており、
前記ログインアプリケーションロジックは、前記タイムアウト時間を経過してもなお、前記認証結果の通知を受信していない場合に、前記タイムアウト時間を経過した時点で前記エンドポイントのURIを削除することを特徴とする請求項6に記載のシステム。 - 前記Webブラウザが前記認証処理リクエストを行ってから前記認証結果の通知を受信するまでのタイムアウト時間が、前記情報処理装置が備えるアプリケーションごとに予め設定されており、
アプリケーションに応じたタイムアウト時間を経過してもなお、前記認証結果の通知を受信していない場合に、前記タイムアウト時間を経過した時点で前記エンドポイントのURIを削除することを特徴とする請求項6に記載のシステム。 - 情報処理装置であって、
ネットワークに接続されたWebサーバから認証のための操作画面を取得し、取得した操作画面を表示することによりユーザからの認証データの入力操作を受け付け、受け付けた認証データを用いた認証処理を前記Webサーバに要求し、認証が成功した旨の通知を前記Webサーバから受けた場合に前記情報処理装置が備える機能のユーザによる使用を許可することを特徴とする情報処理装置。 - 情報処理装置の制御方法であって、
ネットワークに接続されたWebサーバから認証のための操作画面を取得し、取得した操作画面を表示することによりユーザからの認証データの入力操作を受け付け、受け付けた認証データを用いた認証処理を前記Webサーバに要求し、認証が成功した旨の通知を前記Webサーバから受けた場合に前記情報処理装置が備える機能のユーザによる使用を許可することを特徴とする制御方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011042659A JP2012181601A (ja) | 2011-02-08 | 2011-02-28 | 情報処理システム、情報処理装置、及び情報処理装置の制御方法 |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2011025341 | 2011-02-08 | ||
JP2011025341 | 2011-02-08 | ||
JP2011042659A JP2012181601A (ja) | 2011-02-08 | 2011-02-28 | 情報処理システム、情報処理装置、及び情報処理装置の制御方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2012181601A true JP2012181601A (ja) | 2012-09-20 |
Family
ID=47012763
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2011042659A Withdrawn JP2012181601A (ja) | 2011-02-08 | 2011-02-28 | 情報処理システム、情報処理装置、及び情報処理装置の制御方法 |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2012181601A (ja) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2018192740A (ja) * | 2017-05-19 | 2018-12-06 | キヤノン株式会社 | 画像形成装置、情報処理方法及びプログラム |
JP2019525350A (ja) * | 2016-08-12 | 2019-09-05 | アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited | 認証方法、装置及び認証クライアント |
JP2021056982A (ja) * | 2019-09-30 | 2021-04-08 | 株式会社リコー | 認証システム、共有端末および認証方法 |
-
2011
- 2011-02-28 JP JP2011042659A patent/JP2012181601A/ja not_active Withdrawn
Cited By (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2019525350A (ja) * | 2016-08-12 | 2019-09-05 | アリババ・グループ・ホールディング・リミテッドAlibaba Group Holding Limited | 認証方法、装置及び認証クライアント |
US10686786B2 (en) | 2016-08-12 | 2020-06-16 | Alibaba Group Holding Limited | Authentication method, device and authentication client |
JP2018192740A (ja) * | 2017-05-19 | 2018-12-06 | キヤノン株式会社 | 画像形成装置、情報処理方法及びプログラム |
JP2021056982A (ja) * | 2019-09-30 | 2021-04-08 | 株式会社リコー | 認証システム、共有端末および認証方法 |
JP7388139B2 (ja) | 2019-09-30 | 2023-11-29 | 株式会社リコー | 認証システム、共有端末、認証方法およびプログラム |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200319830A1 (en) | Image forming apparatus, printing system, control method, and storage medium | |
JP5424614B2 (ja) | 情報処理システム、情報処理装置、Webサーバ、制御方法、及びプログラム | |
JP5888880B2 (ja) | 印刷システム、サーバ装置、画像形成装置および印刷処理方法 | |
JP6502637B2 (ja) | 情報処理システム、情報処理装置、及びその制御方法とプログラム | |
JP6184194B2 (ja) | 画像処理装置及びその認証方法、並びにプログラム | |
JP5643493B2 (ja) | 情報処理装置、その制御方法、及びプログラム | |
JP2013191008A (ja) | 情報処理システム及びプログラム | |
JP5759243B2 (ja) | 情報処理システム、画像処理装置、情報処理装置、それらの制御方法及びプログラム | |
JP6327881B2 (ja) | 情報処理装置、その制御方法、及びプログラム | |
JP2015170117A (ja) | 情報処理装置、制御方法およびプログラム | |
JP2017027522A (ja) | 印刷装置及びその制御方法とプログラム | |
JP2014219832A (ja) | 画像処理装置及びその認証方法、並びにプログラム | |
JP2017154343A (ja) | 画像形成装置、印刷システム、画像形成装置の制御方法、印刷システムの制御方法、及びプログラム | |
JP5729503B2 (ja) | 情報処理装置及びプログラム | |
JP6762823B2 (ja) | 画像形成装置、画像形成装置の制御方法、及びプログラム | |
JP2017139013A (ja) | 印刷システム、情報処理装置、及びプログラム | |
KR20180000527A (ko) | 화상 형성 장치, 모바일 단말 및 그 장치들의 로컬 로그인 처리 방법 | |
JP6025797B2 (ja) | 画像形成装置、該装置の制御方法、及びプログラム | |
JP2012181601A (ja) | 情報処理システム、情報処理装置、及び情報処理装置の制御方法 | |
JP2015108951A (ja) | 印刷システム、情報処理装置、画像形成装置及びプログラム | |
JP7490405B2 (ja) | 画像形成装置、印刷システム、制御方法、およびプログラム | |
JP5286232B2 (ja) | 画像形成システムおよびユーザマネージャサーバ装置 | |
JP2006318098A (ja) | サーバ装置、システム、及びその制御方法 | |
JP2018195268A (ja) | 情報処理装置とその制御方法、及びプログラム | |
JP2013228788A (ja) | 画像形成装置、画像形成システム、画像形成方法、プログラムおよび記憶媒体 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A300 | Application deemed to be withdrawn because no request for examination was validly filed |
Free format text: JAPANESE INTERMEDIATE CODE: A300 Effective date: 20140513 |