JP2016091117A - 情報処理システム、情報処理装置、アクセス制御方法及びプログラム - Google Patents

Abstract

【課題】正当な認証チケットが存在するリクエストに含ませて情報をアクセス制御装置からサービス提供装置に送信できる情報処理システムを提供することを課題とする。【解決手段】１以上の情報処理装置を含む情報処理システムであって、サービス利用装置からサービス提供装置に対するリクエストを受け付け、リクエストに認証済みであることを示す情報が含まれている場合に、リクエストに付与する付与情報の種類が設定されている設定情報に基づき、設定情報に設定されている種類の付与情報をリクエストに付与してリクエストをサービス提供装置に送信するアクセス制御手段と、認証済みであることを示す情報と対応付けて付与情報を管理し、アクセス制御手段から受信した認証済みであることを示す情報と対応する付与情報をアクセス制御手段に提供する情報提供手段と、を有することにより上記課題を解決する。【選択図】 図１

Description

本発明は、情報処理システム、情報処理装置、アクセス制御方法及びプログラムに関する。

クラウドコンピューティングにより提供されるサービスをはじめ、ユーザが操作するクライアントに提供されるサービスにおいては、従来から、認証チケットによりアクセス制御を行うことが知られている。

例えばインターネットを含むさまざまなネットワークを介して、ユーザフレンドリな形で保護されたリソースへのセキュア・アクセスを、許可されたユーザに提供する内容が従来から知られている（例えば特許文献１参照）。

例えばユーザが操作するクライアントとサービスを提供するサービス提供装置との間で認証チケットによりアクセス制御を行うアクセス制御装置がある。アクセス制御装置はクライアントからサービス提供装置へのリクエストに正当な認証チケットが存在するか否かによりアクセス制御を行い、正当な認証チケットが存在するリクエストをサービス提供装置に提供する。

ところで、認証チケットの正当性の判断や認証に必要な情報を含む各種情報の保持はアクセス制御装置以外で行われる場合がある。また、サービス提供装置はアクセス制御装置以外で保持される各種情報を、サービスの提供に利用したい場合がある。

しかしながら、サービス提供装置がアクセス制御装置以外で保持される各種情報を直接取得できる仕組みを設けることはセキュリティの観点から望ましくない。

本発明の実施の形態は、上記の点に鑑みなされたものであり、正当な認証チケットが存在するリクエストに含ませて情報をアクセス制御装置からサービス提供装置に送信できる情報処理システムを提供することを目的とする。

上記目的を達成するため本願請求項１は、１以上の情報処理装置を含む情報処理システムであって、サービス利用装置からサービス提供装置に対するリクエストを受け付け、前記リクエストに認証済みであることを示す情報が含まれている場合に、前記リクエストに付与する付与情報の種類が設定されている設定情報に基づき、前記設定情報に設定されている種類の前記付与情報を前記リクエストに付与して、該リクエストを前記サービス提供装置に送信するアクセス制御手段と、前記認証済みであることを示す情報と対応付けて前記付与情報を管理し、前記アクセス制御手段から受信した前記認証済みであることを示す情報と対応する前記付与情報を前記アクセス制御手段に提供する情報提供手段と、を有することを特徴とする。

本発明の実施の形態によれば、正当な認証チケットが存在するリクエストに含ませて情報をアクセス制御装置からサービス提供装置に送信できる。

第１の実施形態に係る情報処理システムの一例の構成図である。 本実施形態に係るコンピュータの一例のハードウェア構成図である。 本実施形態に係る画像形成装置の一例のハードウェア構成図である。 第１の実施形態に係るサービス提供システムの一例の構成図である。 第１の実施形態に係るサービスプラットフォーム提供システムの一例の処理ブロック図である。 ＵＩ及びロジック（ＡＰＩ）の配置の一例を示す構成図である。 認証チケットでのアクセス制御の一例について説明する図である。 認証エージェントＡＰＩの一例について説明する図である。 テナント情報の一例の構成図である。 ユーザ情報の一例の構成図である。 ライセンス情報の一例の構成図である。 有効化された機器一覧情報の一例の構成図である。 機器情報の一例の構成図である。 設定項目の一例を表した構成図である。 署名した設定ファイルの一例の構成図である。 ユーザ認証チケットでのアクセス制御の一例のフローチャートである。 本人情報ヘッダの一例の構成図である。 エラー処理の一例のフローチャートである。 ユーザ認証チケットでのアクセス制御の一例のシーケンス図である。 ＨＴＴＰヘッダ名「Ｘ−Ｎｏ−Ｐｅｒｍｉｓｓｉｏｎ−Ｒｅａｓｏｎ」の値の付与について説明する図である。 機器認証チケットでのアクセス制御の一例のフローチャートである。 認証エージェントＡＰＩの一例のフローチャートである。 認証エージェントＡＰＩの一例について説明する図である。 認証エージェントＡＰＩのレスポンス例を示す図である。 認証エージェントＡＰＩの一例のシーケンス図である。

以下、本発明の実施形態について図面を参照しながら説明する。
［第１の実施形態］
＜システム構成＞
図１は第１の実施形態に係る情報処理システムの一例の構成図である。図１の情報処理システム１は、ユーザシステム１０、アプリマーケット提供システム２０、サービス提供システム３０、サービスプラットフォーム提供システム４０及び業務プラットフォーム提供システム５０を有する。

ユーザシステム１０、アプリマーケット提供システム２０、サービス提供システム３０及びサービスプラットフォーム提供システム４０は、インターネットなどのネットワークＮ１を介して接続されている。また、サービスプラットフォーム提供システム４０及び業務プラットフォーム提供システム５０は専用回線などで接続されている。

ユーザシステム１０のネットワークＮ２は、ファイアウォールＦＷの内側にあるプライベートなネットワークである。ファイアウォールＦＷは、不正なアクセスを検出及び遮断する。ネットワークＮ２にはユーザ端末１１、複合機などの画像形成装置１２が接続されている。なお、画像形成装置１２はユーザがサービスを利用する電子機器の一例である。

ユーザ端末１１は一般的なＯＳ（オペレーティングシステム）などが搭載された情報処理装置によって実現できる。ユーザ端末１１は無線による通信の手段または有線による通信の手段を有する。ユーザ端末１１はスマートフォンや携帯電話、タブレット端末、ＰＣなどのユーザが操作可能な端末である。

画像形成装置１２は複合機などの画像形成機能を有する装置である。画像形成装置１２は無線による通信の手段または有線による通信の手段を有する。画像形成装置１２は例えばブラウザが搭載された複合機、コピー機、スキャナ、プリンタ、レーザプリンタ、プロジェクタ、電子黒板など、画像形成に係る処理を行う装置である。図１では、一例としてユーザ端末１１、画像形成装置１２がそれぞれ一台である例を示しているが複数台であってもよい。

また、アプリマーケット提供システム２０のアプリマーケット提供サーバ２１はファイアウォールＦＷを介してネットワークＮ１に接続される。アプリマーケット提供サーバ２１は一般的なＯＳなどが搭載された一台以上の情報処理装置によって実現できる。

アプリマーケット提供システム２０は販売地域や販売会社等ごとに設けてもよい。アプリマーケット提供サーバ２１はサービス一覧画面や申し込み画面などのアプリマーケット画面をユーザ端末１１や画像形成装置１２に提供する。

サービス提供システム３０はファイアウォールＦＷを介してネットワークＮ１に接続されている。サービス提供システム３０はユーザ端末１１や画像形成装置１２に各種サービスを提供する。サービス提供システム３０は一般的なＯＳなどが搭載された一台以上の情報処理装置によって実現できる。サービス提供システム３０が提供するサービスはサービスプラットフォーム提供システム４０の運営者が提供するサービスの他、外部のサービスプロバイダ等が提供するサービスであってもよい。

サービスプラットフォーム提供システム４０は、ファイアウォールＦＷを介してネットワークＮ１に接続されている。サービスプラットフォーム提供システム４０は一般的なＯＳなどが搭載された一台以上の情報処理装置によって実現できる。

サービスプラットフォーム提供システム４０は、例えば認証・認可、テナント・ユーザ管理、ライセンス管理、アカウント登録などの機能を有している。サービスプラットフォーム提供システム４０は、ユーザ端末１１、画像形成装置１２からのアカウント登録やログインの要求を受け付ける。また、サービスプラットフォーム提供システム４０はサービス提供システム３０からの認証チケットの確認要求やユーザ情報の取得要求を受け付ける。

業務プラットフォーム提供システム５０のネットワークＮ３はファイアウォールＦＷの内側にあるプライベートなネットワークである。ネットワークＮ３には業務端末５１、ライセンス管理サーバ５２が接続されている。業務端末５１、ライセンス管理サーバ５２は一般的なＯＳなどが搭載された一台以上の情報処理装置によって実現できる。

業務端末５１は無線による通信の手段または有線による通信の手段を有する。業務端末５１はスマートフォンや携帯電話、タブレット端末、ＰＣなどの業務担当が操作可能な端末である。業務担当は業務端末５１からライセンス発行をライセンス管理サーバ５２に要求できる。

ライセンス管理サーバ５２はライセンス管理などの機能を有している。ライセンス管理サーバ５２はサービスプラットフォーム提供システム４０や業務端末５１からライセンス発行などの要求を受け付ける。図１の情報処理システム１の構成は一例であって、他の構成であってもよい。

＜ハードウェア構成＞
図１のユーザ端末１１、アプリマーケット提供サーバ２１、業務端末５１及びライセンス管理サーバ５２は例えば図２に示すようなハードウェア構成のコンピュータにより実現される。また、図１のサービス提供システム３０及びサービスプラットフォーム提供システム４０を実現する情報処理装置は例えば図２に示すハードウェア構成のコンピュータにより実現される。図２は、本実施形態に係るコンピュータの一例のハードウェア構成図である。

図２に示したコンピュータ５００は、入力装置５０１、表示装置５０２、外部Ｉ／Ｆ５０３、ＲＡＭ５０４、ＲＯＭ５０５、ＣＰＵ５０６、通信Ｉ／Ｆ５０７、及びＨＤＤ５０８などを備え、それぞれがバスＢで相互に接続されている。なお、入力装置５０１及び表示装置５０２は必要なときに接続して利用する形態であってもよい。

入力装置５０１はキーボードやマウスなどを含み、ユーザが各操作信号を入力するのに用いられる。表示装置５０２はディスプレイなどを含み、コンピュータ５００による処理結果を表示する。

通信Ｉ／Ｆ５０７は、コンピュータ５００をネットワークＮ１、Ｎ２及びＮ３に接続するインタフェースである。これにより、コンピュータ５００は通信Ｉ／Ｆ５０７を介してデータ通信を行うことができる。

ＨＤＤ５０８はプログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータは、例えばコンピュータ５００全体を制御する基本ソフトウェアであるＯＳや、ＯＳ上において各種機能を提供するアプリケーションソフトウェアなどである。

外部Ｉ／Ｆ５０３は、外部装置とのインタフェースである。外部装置には、記録媒体５０３ａなどがある。これにより、コンピュータ５００は外部Ｉ／Ｆ５０３を介して記録媒体５０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体５０３ａにはフレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリなどがある。

ＲＯＭ５０５は、電源を切ってもプログラムやデータを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ５０５には、コンピュータ５００の起動時に実行されるＢＩＯＳ、ＯＳ設定、及びネットワーク設定などのプログラムやデータが格納されている。ＲＡＭ５０４は、プログラムやデータを一時保持する揮発性の半導体メモリである。

ＣＰＵ５０６は、ＲＯＭ５０５やＨＤＤ５０８などの記憶装置からプログラムやデータをＲＡＭ５０４上に読み出し、処理を実行することで、コンピュータ５００全体の制御や機能を実現する演算装置である。

本実施形態に係るユーザ端末１１、アプリマーケット提供サーバ２１、業務端末５１及びライセンス管理サーバ５２は、上記したコンピュータ５００のハードウェア構成により後述する各種処理を実現できる。また、本実施形態に係るサービス提供システム３０及びサービスプラットフォーム提供システム４０を実現する情報処理装置は、上記したようなコンピュータ５００のハードウェア構成により後述する各種処理を実現できる。

図１の画像形成装置１２は、例えば図３に示すようなハードウェア構成のコンピュータにより実現される。図３は本実施形態に係る画像形成装置の一例のハードウェア構成図である。図３に示した画像形成装置１２は、コントローラ６０１、操作パネル６０２、外部Ｉ／Ｆ６０３、通信Ｉ／Ｆ６０４、プリンタ６０５及びスキャナ６０６などを備える。

コントローラ６０１はＣＰＵ６１１、ＲＡＭ６１２、ＲＯＭ６１３、ＮＶＲＡＭ６１４及びＨＤＤ６１５などを備える。ＲＯＭ６１３は、各種プログラムやデータが格納されている。ＲＡＭ６１２はプログラムやデータを一時保持する。ＮＶＲＡＭ６１４は、例えば設定情報等が格納されている。また、ＨＤＤ６１５は各種プログラムやデータが格納されている。

ＣＰＵ６１１は、ＲＯＭ６１３やＮＶＲＡＭ６１４、ＨＤＤ６１５などからプログラムやデータ、設定情報等をＲＡＭ６１２上に読み出し、処理を実行することで、画像形成装置１２全体の制御や機能を実現する。

操作パネル６０２はユーザからの入力を受け付ける入力部と、表示を行う表示部とを備えている。外部Ｉ／Ｆ６０３は外部装置とのインタフェースである。外部装置には、記録媒体６０３ａなどがある。これにより、出力装置１４は外部Ｉ／Ｆ６０３を介して記録媒体６０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体６０３ａにはＩＣカード、フレキシブルディスク、ＣＤ、ＤＶＤ、ＳＤメモリカード、ＵＳＢメモリ等がある。

通信Ｉ／Ｆ６０４は画像形成装置１２をネットワークＮ２に接続させるインタフェースである。これにより画像形成装置１２は通信Ｉ／Ｆ６０４を介してデータ通信を行うことができる。プリンタ６０５は印刷データを用紙に印刷する印刷装置である。スキャナ６０６は原稿から画像データ（電子データ）を読み取る読取装置である。なお、図１に示したファイアウォールＦＷのハードウェア構成については説明を省略する。

＜ソフトウェア構成＞
《サービス提供システム》
第１の実施形態に係るサービス提供システム３０は例えば図４に示す構成により実現できる。図４は第１の実施形態に係るサービス提供システムの一例の構成図である。図４のサービス提供システム３０は、認証エージェント装置３１及びサービス提供装置３２を有する構成である。

認証エージェント装置３１はユーザ端末１１や画像形成装置１２からサービス提供装置３２に対する各種要求（リクエスト）を受け付ける。認証エージェント装置３１はサービスプラットフォーム提供システム４０が発行した正当な認証チケットが含まれるユーザ端末１１や画像形成装置１２からの要求をサービス提供装置３２に送信するようにアクセス制御を行う。

また、認証エージェント装置３１は、正当な認証チケットが含まれていないユーザ端末１１や画像形成装置１２からの要求を後述の設定によりサービスプラットフォーム提供システム４０にリダイレクトできる。このように、認証エージェント装置３１は正当な認証チケットをユーザ端末１１や画像形成装置１２に取得させたあと、ユーザ端末１１や画像形成装置１２からの要求をサービス提供装置３２に送信できる。

サービス提供装置３２はユーザ端末１１や画像形成装置１２からの要求に応じたサービスを提供する。また、サービス提供装置３２は後述するように認証エージェント装置３１に対して認証チケットの正当性を問い合わせたり、サービスの提供に必要な情報の取得を要求したりする。

例えばサービス提供装置３２が提供するサービスの一例として翻訳サービスがある。画像形成装置１２は原稿からスキャンした画像データをＯＣＲ（光学的文字認識）した後でサービス提供装置３２に送信し、サービス提供装置３２が提供する翻訳サービスを利用できる。

サービス提供装置３２は翻訳サービスの提供に必要な情報の一例としてユーザ情報を取得し、翻訳結果に含ませてもよい。ユーザは例えばユーザ端末１１からサービス提供装置３２にアクセスして翻訳結果を閲覧してもよいし、電子メールで翻訳結果を受け取ってもよい。

《サービスプラットフォーム提供システム》
第１の実施形態に係るサービスプラットフォーム提供システム４０は例えば図５に示す処理ブロックにより実現される。図５は第１の実施形態に係るサービスプラットフォーム提供システムの一例の処理ブロック図である。サービスプラットフォーム提供システム４０はプログラムを実行することで、図５に示すような処理ブロックを実現する。

図５のサービスプラットフォーム提供システム４０は、アプリケーション１０１、共通サービス１０２、データベース（ＤＢ）１０３及びプラットフォームＡＰＩ１０４を実現している。

アプリケーション１０１は、ポータルサービスアプリ１１１、スキャンサービスアプリ１１２、プリントサービスアプリ１１３、アカウント登録アプリ１１４を一例として有している。

ポータルサービスアプリ１１１は、ポータルサービスを提供するアプリケーションである。ポータルサービスは情報処理システム１を利用するための入り口となるサービスを提供する。スキャンサービスアプリ１１２はスキャンサービスを提供するアプリケーションのＵＩ（ユーザインタフェース）である。

また、プリントサービスアプリ１１３はプリントサービスを提供するアプリケーションのＵＩである。アカウント登録アプリ１１４はアカウント登録サービスを提供するアプリケーションのＵＩである。なお、アプリケーション１０１には、その他のサービスアプリが含まれていてもよい。

スキャンサービスアプリ１１２、プリントサービスアプリ１１３及びアカウント登録アプリ１１４のＵＩには、ユーザ端末１１又は画像形成装置１２で表示又は実行されるＮａｔｉｖｅアプリ、ＨＴＭＬ／ＪａｖａＳｃｒｉｐｔ（登録商標）データが含まれていてもよい。ＮａｔｉｖｅアプリはＷｅｂアプリと対比するものであり、主な処理をユーザ端末１１や画像形成装置１２で行うタイプのアプリケーションである。Ｗｅｂアプリは主な処理をサービスプラットフォーム提供システム４０で行うタイプのアプリケーションである。

プラットフォームＡＰＩ（Application Programming Interface）１０４は、ポータルサービスアプリ１１１などのアプリケーション１０１が共通サービス１０２を利用するためのインタフェースである。

プラットフォームＡＰＩ１０４はアプリケーション１０１からの要求を共通サービス１０２が受信するために設けられた予め定義されたインタフェースであり、例えば関数やクラス等により構成される。プラットフォームＡＰＩ１０４は、サービスプラットフォーム提供システム４０が複数の情報処理装置で構成される場合、ネットワーク経由で利用可能な例えばＷｅｂ ＡＰＩにより実現できる。

共通サービス１０２はスキャンサービス部１２１、プリントサービス部１２２、アカウント登録部１２３、認証・認可部１３１、テナント管理部１３２、ユーザ管理部１３３、ライセンス管理部１３４、機器管理部１３５、一時画像保存部１３６、データ保管部１３７、画像処理ワークフロー制御部１３８、ログ収集部１３９を有する。また、画像処理ワークフロー制御部１３８は、メッセージキュー１４１、１つ以上のワーカー（Ｗｏｒｋｅｒ）１４２を有する。ワーカー１４２は画像変換や画像送信などの機能を実現する。

スキャンサービス部１２１はスキャンサービスアプリ１１２のロジック（ＡＰＩ）として機能する。プリントサービス部１２２はプリントサービスアプリ１１３のロジック（ＡＰＩ）として機能する。また、アカウント登録部１２３はアカウント登録アプリ１１４のロジック（ＡＰＩ）として機能する。

認証・認可部１３１は、ユーザ端末１１や画像形成装置１２などのオフィス機器からのログイン要求に基づいて認証・認可を実行する。オフィス機器はユーザ端末１１、画像形成装置１２などの総称である。

認証・認可部１３１は、例えば後述するユーザ情報記憶部１５３、ライセンス情報記憶部１５４などにアクセスしてユーザを認証・認可する。また、認証・認可部１３１は例えば後述するテナント情報記憶部１５２、ライセンス情報記憶部１５４、機器情報記憶部１５５などにアクセスして画像形成装置１２などをクライアント認証する。

テナント管理部１３２は後述するテナント情報記憶部１５２に記憶されているテナント情報を管理する。ユーザ管理部１３３は、後述するユーザ情報記憶部１５３に記憶されているユーザ情報を管理する。

ライセンス管理部１３４は後述するライセンス情報記憶部１５４に記憶されているライセンス情報を管理する。機器管理部１３５は後述する機器情報記憶部１５５に記憶されている機器情報を管理する。一時画像保存部１３６は後述する一時画像記憶部１５６への一時画像の保存、一時画像記憶部１５６からの一時画像の取得を行う。データ保管部１３７は後述するジョブ情報記憶部１５７などにデータを保管する。

画像処理ワークフロー制御部１３８はアプリケーション１０１からの要求に基づいて画像処理に関するワークフローを制御する。メッセージキュー１４１は処理の種類に対応するキューを有する。画像処理ワークフロー制御部１３８は処理（ジョブ）に係るリクエストのメッセージを、そのジョブの種類に対応するキューに投入する。

ワーカー１４２は対応するキューを監視している。そして、キューにメッセージが投入されるとワーカー１４２は、対応するジョブの種類に応じた画像変換や画像送信などの処理を行う。キューに投入されたメッセージは、ワーカー１４２が主体的に読み出す（Ｐｕｌｌ）ようにしてもよいし、キューからワーカー１４２に提供する（Ｐｕｓｈ）ようにしてもよい。ログ収集部１３９は、収集したログ情報を例えば後述するようなログ情報記憶部１５１に記憶させる。

データベース１０３は、ログ情報記憶部１５１、テナント情報記憶部１５２、ユーザ情報記憶部１５３、ライセンス情報記憶部１５４、機器情報記憶部１５５、一時画像記憶部１５６、ジョブ情報記憶部１５７、及び、アプリケーション固有の設定情報記憶部１５８を有する。

ログ情報記憶部１５１は、ログ情報を記憶する。テナント情報記憶部１５２は後述のテナント情報を記憶する。ユーザ情報記憶部１５３は後述のユーザ情報を記憶する。ライセンス情報記憶部１５４は、ライセンス情報を記憶する。機器情報記憶部１５５は後述の機器情報を記憶する。また、一時画像記憶部１５６は一時画像を記憶する。一時画像は例えばワーカー１４２が処理するスキャン画像などのファイルやデータである。

ジョブ情報記憶部１５７は処理（ジョブ）に係るリクエストの情報（ジョブ情報）を記憶する。アプリケーション固有の設定情報記憶部１５８はアプリケーション１０１に固有の設定情報を記憶する。

サービスプラットフォーム提供システム４０は認証・認可や画像処理に関するワークフロー等の共通サービスを提供する統合基盤と、統合基盤の機能を利用してスキャンサービスやプリントサービス等のアプリサービスを提供するサービス群として機能する。

統合基盤は例えば共通サービス１０２、データベース１０３及びプラットフォームＡＰＩ１０４によって構成される。サービス群は例えばアプリケーション１０１によって構成される。このように、図４に示したサービスプラットフォーム提供システム４０はサービス群と統合基盤とが分離された構成である。

図５に示したサービスプラットフォーム提供システム４０はサービス群と統合基盤とを分離した構成により、プラットフォームＡＰＩ１０４を利用するアプリケーション１０１を容易に開発できる。また、図５に示したサービスプラットフォーム提供システム４０はプラットフォームＡＰＩ１０４を利用するサービス提供装置３２を容易に開発できる。

なお、図５に示したサービスプラットフォーム提供システム４０の処理ブロックの分類形態は一例であり、アプリケーション１０１、共通サービス１０２、データベース１０３が図５に示される階層で分類されていることが必須ではない。例えば第１の実施形態に係るサービスプラットフォーム提供システム４０の処理を実施できるのであれば、図５に示される階層関係などは特定のものに限定されない。

《ＵＩ及びロジックの配置》
図５のサービスプラットフォーム提供システム４０ではスキャンサービスアプリ１１２などのアプリケーション１０１のＵＩ又はロジック（ＡＰＩ）が、ユーザ端末１１や画像形成装置１２などのクライアント２００から図６のようにアクセスを受ける。図６はＵＩ及びロジック（ＡＰＩ）の配置の一例を示す構成図である。

図６のサービスプラットフォーム提供システム４０のＵＩ２１１は、クライアント２００で行われたユーザ操作を解釈し、プラットフォームＡＰＩ１０４からロジック２１２を呼び出してＨＴＭＬデータ２０２を生成する。サービスプラットフォーム提供システム４０側で生成されたＨＴＭＬデータ２０２によりクライアント２００のブラウザ２０１は画面の変更を行う。

また、ブラウザ２０１はシングルページＷｅｂアプリケーション（ＳＰＡ）を利用してもよい。クライアント２００のブラウザ２０１はＨＴＭＬ／ＪａｖａＳｃｒｉｐｔ／ＣＳＳデータをサービスプラットフォーム提供システム４０からダウンロードする。ブラウザ２０１はＪａｖａＳｃｒｉｐｔデータ２０３によりサービスプラットフォーム提供システム４０のロジック２１２を例えばＡｊａｘにより呼び出し、ＤＯＭ操作により画面の変更を行うことができる。

ここで、Ａｊａｘ（Asynchronous JavaScript + XML）とはブラウザ２０１に実装されているＪａｖａＳｃｒｉｐｔのＨＴＴＰ通信機能を使い、Ｗｅｂページのリロードを伴わずに処理を進めるＷｅｂアプリケーションの実装形態の一例である。ＤＯＭ操作はＨＴＭＬデータの各要素の値にアクセスし、動的に書き換える操作の一例である。

また、クライアント２００はＮａｔｉｖｅＯＳにインストールされたＮａｔｉｖｅアプリ２０４を利用してもよい。Ｎａｔｉｖｅアプリ２０４はクライアント２００側でユーザ操作を解釈し、ロジック２１２を呼び出し、結果に応じて画面の変更を行う。

図６ではサービスプラットフォーム提供システム４０のＵＩ２１１がプラットフォームＡＰＩ１０４からロジック２１２を呼び出しているが、サービス提供システム３０のＵＩがプラットフォームＡＰＩ１０４からロジック２１２を呼び出す場合も同様である。

《認証チケットでのアクセス制御》
認証エージェント装置３１は図７に示すようにサービスプラットフォーム提供システム４０と連携して、クライアント２００からサービス提供装置３２に対する認証チケットでのアクセス制御を行う。図７は認証チケットでのアクセス制御の一例について説明する図である。

図７に示すように、クライアント２００からサービス提供装置３２へのアクセスは認証エージェント装置３１を経由して行う。認証エージェント装置３１は例えばＷｅｂサーバ部３１ａとプラグインなどの拡張機能部３１ｂなどで構成される。クライアント２００からサービス提供装置３２が提供するサービスを利用する場合、ユーザはクライアント２００からサービス提供システム３０にリクエストを行う。

サービス提供システム３０の認証エージェント装置３１は前述したように、正当な認証チケットが含まれていないリクエストをサービス提供装置３２に送信しないことで、認証チケットでのサービス提供装置３２の保護を行っている。例えば認証エージェント装置３１はＷｅｂサーバ部３１ａにおいて認証チケットで守りたいパスが指定されている。

認証チケットには例えばユーザ認証チケットと機器認証チケットとが含まれる。ユーザ認証チケットで守りたいパスへのリクエストであれば認証エージェント装置３１はユーザ認証チケットでのサービス提供装置３２の保護を行う拡張機能部３１ｂを指定する。機器認証チケットで守りたいパスへのリクエストであれば認証エージェント装置３１は機器認証チケットでのサービス提供装置３２の保護を行う拡張機能部３１ｂを指定する。

このように、認証エージェント装置３１は認証チケットでのサービス提供装置３２の保護を行う。なお、認証エージェント装置３１では、認証チケットで守りたいパス（ユーザごとに表示を切り替えるパスなど）以外に、守る必要がないパス（画像ファイル、ログインページ、利用規約ページなど）を、別途、保護除外パスとしてＷｅｂサーバ部３１ａに指定できる。

例えばクライアント２００を操作するユーザはサービスプラットフォーム提供システム４０に対するログイン処理を行い、正当な認証チケットを取得する。クライアント２００は取得した正当な認証チケットを含ませてサービス提供システム３０に対してリクエストを行う。サービス提供システム３０の認証エージェント装置３１はクライアント２００からのリクエストに含まれている認証チケットの正当性をサービスプラットフォーム提供システム４０に問い合わせる、
また、認証エージェント装置３１は、クライアント２００からのリクエストに情報を追加する必要がある場合、その情報をサービスプラットフォーム提供システム４０に問い合わせて、ＨＴＴＰヘッダなどに追加する。

サービス提供装置３２はクライアント２００からの要求に応じたサービス（××サービス）を提供する。サービス提供装置３２はＨＴＴＰヘッダなどに追加された情報を利用してクライアント２００からのリクエストに応じたサービスを提供する。

《認証エージェントＡＰＩ》
認証エージェント装置３１はサービスプラットフォーム提供システム４０から情報を取得する認証エージェントＡＰＩを設け、サービス提供装置３２に公開している。図８は認証エージェントＡＰＩの一例について説明する図である。サービス提供装置３２は、認証エージェントＡＰＩを利用することで、認証エージェント装置３１を経由してサービスプラットフォーム提供システム４０から情報を取得する。

したがって、サービス提供装置３２はサービスプラットフォーム提供システム４０から情報を直接取得する必要がなくなる。このため、サービスプラットフォーム提供システム４０はサービス提供装置３２から直接、情報の問い合わせを受けることが無くなり、情報を取得するためのＡＰＩをパブリックにする必要がなくなり、また、クロスドメイン対応も不要となる。

《情報》
図９はテナント情報の一例の構成図である。図９のテナント情報はデータ項目としてテナントＩＤ、テナント名、表示言語、タイムゾーン、状態、国などを有している。

テナントＩＤは企業、部署などのグループ（組織）を特定する情報である。テナントＩＤはテナントという言語に限定されるものではなく、例えば契約を識別する情報であってもよい。なお、テナントＩＤは一意である。

テナント名は企業、部署などのグループの名称を表している。表示言語は企業、部署などのグループの名称を表示する言語を表している。また、表示言語はブラウザからのアクセスに対する表示や、メールの本文の言語を表している。タイムゾーンは企業、部署などのグループが利用する標準時を表している。状態は企業、部署などのグループの状態を表している。国は企業、部署などのグループの属する国名を表している。

図１０はユーザ情報の一例の構成図である。図１０に示すユーザ情報は、データ項目としてテナントＩＤ、ユーザＩＤ、メールアドレス、パスワード、ユーザ名、表示言語、タイムゾーン、状態などを有する。

メールアドレス及びパスワードは、ユーザを特定する情報（ユーザ特定情報）の一例である。ユーザ特定情報は、メールアドレスに変えて、ユーザＩＤやユーザ名等であってもよい。また、パスワードは必須でない。

なお、メールアドレスは一意である必要がある。また、同じテナントＩＤで管理されるユーザＩＤも一意である。異なるテナントＩＤで管理されるユーザＩＤは重複していてもよい。

さらに、ユーザ特定情報はユーザが所持する電子媒体（例えばＩＣカード）を識別する情報を用いてもよい。ユーザが所持する電子媒体としてはＩＣカード、携帯電話、タブレット端末、電子書籍端末等を利用できる。電子媒体を識別する情報としては、カードＩＤ、シリアルＩＤ、携帯電話の電話番号、端末のプロフィール情報などを利用できる。電子媒体を識別する情報は組み合わせて利用してもよい。

メールアドレスはユーザのメールアドレスである。表示言語はユーザ名を表示する言語を表している。また、表示言語はブラウザからのアクセスに対する表示やメールの本文の言語を表している。タイムゾーンはユーザが利用する標準時を表している。状態はユーザの状態を表している。

図１１はライセンス情報の一例の構成図である。ライセンス情報はデータ項目としてサービス種別、ライセンスＩＤ、販売地域、国、タイムゾーン、商品コード、数量（台数）、利用開始日、課金開始日、利用終了日、解約予定日、状態、親サービス種別、親ライセンスＩＤ、登録用コード、機種機番、次ライセンス種別、次ライセンスＩＤ、ライセンス種別、ライセンス形態、数量（ユーザ数）、使用中の台数、使用中のユーザ数、契約形態などを有する。

サービス種別はポータル、スキャン、プリントなどのサービスの種別を特定する情報である。ライセンスＩＤは、本契約のライセンスや試用のためのライセンス（トライアルライセンス）を識別する識別情報である。なお、ライセンスＩＤは例えばテナントライセンスの場合にテナントＩＤとなり、サービスライセンスの場合にサービスＩＤとなる。

販売地域は、ライセンスを販売する地域等を表す情報である。国はライセンスを使用する国名を表している。タイムゾーンはライセンスを使用する国の標準時を表している。商品コードは、ライセンスに対応する商品を識別する識別情報である。数量（台数）はライセンスによりサービスを利用可能とすることができる機器の数量（台数）を表す情報である。

利用開始日はライセンスが有効になった日を表す情報である。課金開始日は課金の開始される日を表す情報であり、利用開始日と同日か後日（例えば翌月１日など）である。利用終了日は表示上のライセンス期限を表す情報であり、例えば課金開始日の一年後などである。解約予定日はライセンスが無効化される日を表す情報である。状態はライセンスの状態を表す情報である。ライセンスの状態には、例えば利用開始前を表す仮登録、利用中を表す登録、利用終了を表す解約などがある。

親サービス種別は、サービスライセンスの場合にテナントが設定される。親ライセンスＩＤはサービスライセンスの場合にテナントＩＤが設定される。登録用コードは、テナントライセンスの場合に設定される。登録用コードはテナントの開設時に入力するコードである。

機種機番はサービスライセンスの場合に設定される。機種機番はライセンスの対象となる機器を特定する情報である。ライセンスの対象となる機器が複数存在するボリュームライセンスの場合は、最も早く有効化された機器の機種機番が設定される。

次ライセンス種別は更新済みのサービスライセンスの場合に設定される。次ライセンス種別はサービス種別と同じ値となる。次ライセンスＩＤは更新済みのサービスライセンスの場合に設定される。次ライセンスＩＤは更新済みのサービスライセンスの利用が終了した後に有効になるライセンスのサービスＩＤとなる。

ライセンス種別は機器ライセンスやユーザライセンスなどのサービスライセンスの種別を特定する情報である。ライセンス種別はサービスライセンスにより利用の制限の対象である機器やユーザなどを設定する情報である。ライセンス形態は、他の種別のサービスライセンスと組み合わせて利用を許可するか、自身のサービスライセンスのみで利用を許可するか、を表す情報である。

例えばライセンス形態には「機器ライセンスのみ」や「機器ライセンス＋ユーザライセンス」のような情報が設定される。ライセンス形態が「機器ライセンスのみ」である場合はライセンス種別が「機器ライセンス」であるサービスライセンスが登録されることによりサービスの利用が許可される。また、ライセンス形態が「機器ライセンス＋ユーザライセンス」である場合はライセンス種別が「機器ライセンス」であるサービスライセンスとライセンス種別が「ユーザライセンス」であるサービスライセンスが登録されることによりサービスの利用が許可される。

数量（ユーザ数）はライセンスによりサービスを利用可能とすることができるユーザ数を表す情報である。使用中の台数はライセンスによりサービスが利用可能となっている機器の台数を表す情報である。使用中のユーザ数はライセンスによりサービスが利用可能となっているユーザ数を表す情報である。契約形態は本契約のライセンスか、トライアル契約のライセンス（トライアルライセンス）か、を表す情報である。

なお、図１１のライセンス情報は数量（台数）と数量（ユーザ数）とをデータ項目として別々に設けたが、同一のデータ項目として扱うようにしてもよい。

図１１のライセンス情報に示すように、テナントライセンスとサービスライセンスとは親子関係がある。図１１のライセンス情報はテナントライセンスを親ライセンス、サービスライセンスを子ライセンスとしている。親ライセンスとなるテナントライセンスは親ライセンスＩＤに設定される。なお、図１１のライセンス情報では、テナントライセンスとサービスライセンスとの親子関係を示したが、親子孫関係など３階層以上の関係があってもよい。

テナントライセンスはサービスプラットフォーム提供システム４０を利用するために必要なライセンスである。テナントライセンスが無ければ、サービスプラットフォーム提供システム４０ではテナント開設を実行できない。テナントライセンスはサービスライセンスと同じデータ形式で扱うことによりテナント自体に課金したり、課金によりサービスレベル（速度や容量）に差を設けたり、というようなことが可能となる。サービスプラットフォーム提供システム４０は複数のテナントへのサービス提供を行い、テナントごとに独立したユーザ管理を提供する。

また、サービスプラットフォーム提供システム４０はテナント間でデータ参照できないようにアクセス制限を行う。このため、サービスプラットフォーム提供システム４０では全てのサービス利用に先立ち、テナント開設が必要となる。なお、ライセンスの親子関係は非常に柔軟なデータ構造であるため、ボリュームライセンスなどにおけるライセンスのグルーピングを表現することもできる。

なお、ボリュームライセンスの場合、有効化された機器は例えば図１２に示すような有効化された機器一覧情報により管理される。図１２は有効化された機器一覧情報の一例の構成図である。有効化された機器一覧情報は例えばライセンス情報記憶部１５４に記憶される。

図１２の有効化された機器一覧情報はデータ項目として、サービスＩＤ、テナントＩＤ、機種機番及び有効化された日にちなどを有する。サービスＩＤはサービスライセンスを識別する識別情報である。

テナントＩＤ、機種機番はサービスＩＤを利用して有効化された機器の機種機番とテナントＩＤの情報である。有効化された日にちはサービスＩＤを利用して機器が有効化された日にちが設定される。

図１３は機器情報の一例の構成図である。図１３に示す機器情報はデータ項目としてテナントＩＤ、デバイス認証情報、事業所情報、ケーパビリティなどを有する。デバイス認証情報は、オフィス機器が特定の条件を備えていることを判別するデバイス認証（機器認証）のための情報である。

デバイス認証情報はオフィス機器に特定のアプリケーションが搭載されていることを示すＩＤや特定のオフィス機器であることを示す機種番号などであってもよい。事業所情報は例えばオフィス機器が設置されている事業所を表している。ケーパビリティは例えばオフィス機器の能力を表している。

＜処理の詳細＞
第１の実施形態に係る情報処理システム１では、前述したように認証エージェント装置３１が認証チケットでのアクセス制御、及び、認証エージェントＡＰＩの公開、を行っている。また、認証チケットでのアクセス制御はユーザ認証チケットでのアクセス制御と機器認証チケットでのアクセス制御とが含まれる。

認証エージェント装置３１にはユーザ認証チケットで守りたいパスと機器認証チケットで守りたいパスとが指定されている。認証エージェント装置３１はユーザ認証チケットで守りたいパスへのリクエストであればユーザ認証チケットでのアクセス制御を行い、機器認証チケットで守りたいパスであれば機器認証チケットでのアクセス制御を行う。

以下、ユーザ認証チケットでのアクセス制御、機器認証チケットでのアクセス制御及び認証エージェントＡＰＩについて説明する。

《ユーザ認証チケットでのアクセス制御》
ユーザ認証チケットでのアクセス制御を行うため、認証エージェント装置３１は図１４に示すような設定項目を有する設定ファイルを利用する。図１４は設定項目の一例を表した構成図である。

設定ファイルに設定される設定項目には、例えばリダイレクト先ＵＲＬ、複合機（ＭＦＰ）であることを示すＨＴＴＰヘッダ、付与するヘッダ、認証チケット名、認証基盤のアドレス、ＨＴＴＰＳの設定、キャッシュ時間、保護除外ＵＲＬが含まれる。

リダイレクト先ＵＲＬは、認証チケットが正しくないとき、認証エージェント装置３１で想定外のエラーが発生したとき、のリダイレクトＵＲＬを指定する。ＭＦＰであることを示すＨＴＴＰヘッダは、Ｕｓｅｒ−Ａｇｅｎｔなど、どのＨＴＴＰヘッダを見てＭＦＰからのアクセスであるかを指定できる。なお、ＭＦＰであることを示すＨＴＴＰヘッダは一例であって、画像形成装置１２からのアクセスであるかを指定できればよい。

付与するヘッダは認証チケットが正しい（正当である）とき、どの情報をどんなヘッダ名でＨＴＴＰヘッダに付与するかを指定する。認証チケット名はクッキーにある、どの名前を認証チケットとするかを指定する。認証基盤のアドレスは認証チケットの正当性を問い合わせる認証チケット問い合わせ先のＵＲＬを指定する。ＨＴＴＰＳの設定は自己署名でもｏｋにするか、全く見ないようにするかを指定する。

キャッシュ時間は認証チケットをキャッシュする時間を指定する。保護除外ＵＲＬは認証チケットの正当性を判断せず、そのままサービス提供装置３２へのアクセスを許可するＵＲＬを指定する。

なお、図１４の設定項目では設定項目ごとにサービス提供装置３２を提供する外部ベンダが変更できるか否かを指定できる。図１４の設定項目は外部ベンダが保護除外ＵＲＬを変更できる例を示している。

なお、図１４の設定項目を有する設定ファイルはサービス提供システム３０ごとに保持させることができる。したがって、第１の実施形態に係る情報処理システム１ではサービス提供装置３２ごとに設定項目による指定を替えることができる。また、図１４の設定項目を有する設定ファイルは外部ベンダが設定項目を変更できないように、設定ファイル内に署名を行うようにしてもよい。

図１５は署名した設定ファイルの一例の構成図である。図１５の設定ファイルは署名を行うことで外部ベンダなどによる設定項目の変更を防止する。認証エージェント装置３１は設定項目による指定を読み出す前に署名の検証を行い、その署名が正しくなければ後述のアクセス制御の処理を開始しない。

なお、設定ファイル内の署名の復号に必要なパスワードはブロック暗号化で暗号化して認証エージェント装置３１内の別ファイルとして保持しておいてもよい。設定ファイル内の署名の復号はサービスプラットフォーム提供システム４０で行ってもよい。設定ファイルを署名付きで暗号化しておくことで、認証エージェント装置３１は設定項目による指定を読み出す前に署名の検証を行い、外部ベンダなどによる設定項目の変更を防ぐようにしてもよい。

図１６はユーザ認証チケットでのアクセス制御の一例のフローチャートである。図１６に示すように、認証エージェント装置３１はステップＳ１１においてクライアント２００からのアクセスがＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダが無いかを判定する。なお、ＭＦＰであることを示すＨＴＴＰヘッダは図１４の設定項目により指定されている。

クライアント２００からのアクセスがＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダが無ければ、認証エージェント装置３１はステップＳ１２に進み、４０４ページにリダイレクトさせる。４０４ページはユーザがアクセスしたページが存在しない場合に表示されるエラーページの一例である。

クライアント２００からのアクセスがＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダが無い、場合以外であれば、認証エージェント装置３１はステップＳ１３に進む。ステップＳ１３において認証エージェント装置３１はリクエストから既存の本人情報ヘッダの削除を行う。ステップＳ１３の処理はクライアント２００側で勝手に付けられた本人情報ヘッダを削除するものである。

ステップＳ１４において、認証エージェント装置３１はリクエスト先のＵＲＬが保護除外ＵＲＬにマッチ（合致）しているかを判定する。リクエスト先のＵＲＬが保護除外ＵＲＬにマッチしていれば、認証エージェント装置３１はステップＳ２２に進み、サービス提供装置３２へのアクセスを許可する。

リクエスト先のＵＲＬが保護除外ＵＲＬにマッチしていなければ、認証エージェント装置３１はステップＳ１５に進み、リクエストにユーザ認証チケットが存在しないか否かを判定する。ユーザ認証チケットがリクエストに存在しなければ、認証エージェント装置３１はステップＳ１９に進み、後述するエラー処理を行う。

ユーザ認証チケットがリクエストに存在すれば、認証エージェント装置３１はステップＳ１６に進む。ステップＳ１６において認証エージェント装置３１は有効なユーザ認証チケットがキャッシュに存在するか否かを判定する。

有効なユーザ認証チケットがキャッシュに存在すれば、認証エージェント装置３１はステップＳ２１に進み、リクエストのＨＴＴＰヘッダに例えば図１７に示すような本人情報ヘッダを付与する。

図１７は本人情報ヘッダの一例の構成図である。本人情報ヘッダはユーザ情報ヘッダとライセンス情報ヘッダとを含む。本人情報ヘッダはＨＴＴＰヘッダ名と内容とを含む構成である。図１７の本人情報ヘッダは設定ファイルの設定項目「付与するヘッダ」により指定された内容で構成される。

例えば図１７のユーザ情報ヘッダ例では、テナントＩＤをＨＴＴＰヘッダ名「Ｘ−Ｔｅｎａｎｔ−Ｉｄ」で付与し、ユーザＩＤをＨＴＴＰヘッダ名「Ｘ−Ｕｓｅｒ−Ｉｄ」で付与し、姓をＨＴＴＰヘッダ名「Ｘ−Ｌａｓｔ−Ｎａｍｅ」で付与している。また、ライセンス情報ヘッダ例では例えばサービス種別をＨＴＴＰヘッダ名「Ｘ−Ｓｅｒｖｉｃｅ−Ｃｌａｓｓ」で付与し、課金区分をＨＴＴＰヘッダ名「Ｘ−Ｃｈａｒｇｅ−Ｋｉｎｄ」で付与している。

ステップＳ２１において本人情報ヘッダをリクエストのＨＴＴＰヘッダに付与したあと認証エージェント装置３１はステップＳ２２に進み、サービス提供装置３２へのアクセスを許可する。

一方、ステップＳ１６において有効なユーザ認証チケットがキャッシュに存在しなければ認証エージェント装置３１はステップＳ１７に進み、リクエストに存在したユーザ認証チケットの正当性をサービスプラットフォーム提供システム４０に問い合わせる。

ステップＳ１８に進み、認証エージェント装置３１はサービスプラットフォーム提供システム４０にユーザ認証チケットの正当性を問い合わせた結果に基づき、リクエストに存在したユーザ認証チケットが不正であるかを判定する。リクエストに存在したユーザ認証チケットが不正であれば、認証エージェント装置３１はステップＳ１９に進み、後述するエラー処理を行う。

リクエストに存在したユーザ認証チケットが不正なユーザ認証チケットでなければ、認証エージェント装置３１はステップＳ２０に進み、リクエストに存在した正当なユーザ認証チケットをキャッシュに保存する。その後、認証エージェント装置３１はステップＳ２１において本人情報ヘッダをリクエストのＨＴＴＰヘッダに付与し、ステップＳ２２においてクライアント２００からサービス提供装置３２へのアクセスを許可する。

ステップＳ１９のエラー処理は例えば図１８に示すように行う。図１８はエラー処理の一例のフローチャートである。ステップＳ３１において認証エージェント装置３１はクライアント２００からのアクセスがＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダがあるかを判定する。

クライアント２００からのアクセスがＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダがあれば、認証エージェント装置３１はステップＳ３３において例えばＪＳＯＮ形式のエラーレスポンスをクライアント２００に返す。

もしくは、ステップＳ３１において認証エージェント装置３１は認証チケットが不正である場合のレスポンスとしてエラーレスポンスが指定されているか否かを判定する。例えば認証チケットが不正である場合のレスポンスの指定はクライアント２００がリクエストのＨＴＴＰヘッダ名「Ｘ−Ｅｒｒｏｒ−Ｒｅｓｐｏｎｓｅ−Ｆｏｒｍ」に付与することで行うことができる。

ＨＴＴＰヘッダ名「Ｘ−Ｅｒｒｏｒ−Ｒｅｓｐｏｎｓｅ−Ｆｏｒｍ」によるレスポンスの指定では、例えば認証チケットが不正である場合に、レスポンスをリダイレクトにするかＪＳＯＮ形式によるエラーレスポンスにするか、を以下のように指定できる。

ｊｓｏｎ形式 → X-Error-Response-Form：json
リダイレクト形式 →X-Error-Response-Form：redirect
認証チケットが不正である場合のレスポンスとしてエラーレスポンスが指定されていなければ認証エージェント装置３１はステップＳ３２に進む。ステップＳ３２において認証エージェント装置３１はクライアント２００からのリクエストをＰＣ用のログイン画面にリダイレクトさせる。

なお、リダイレクトのＵＲＬにはクライアント２００からのリクエストのアクセス先のＵＲＬをクエリ情報として追記しておき、ログイン後にリクエストのアクセス先のＵＲＬにアクセスできるようにする。

一方、認証チケットが不正である場合のレスポンスとしてエラーレスポンスが指定されていれば、認証エージェント装置３１はステップＳ３３において例えばＪＳＯＮ形式のエラーレスポンスをクライアント２００に返す。

図１８のエラー処理により、認証エージェント装置３１はリクエストに正当なユーザ認証チケットが存在しない場合に、リクエスト元のクライアント２００の種類（ユーザ端末１１、画像形成装置１２など）に応じてレスポンスを変化させることができる。図１８のフローチャートはクライアント２００が画像形成装置１２の場合にレスポンスをＪＳＯＮ形式で返し、クライアント２００がユーザ端末１１である場合にレスポンスをリダイレクトにしている。

図１９はユーザ認証チケットでのアクセス制御の一例のシーケンス図である。ステップＳ５１において、ユーザが操作するクライアント２００はテナントＩＤ、ユーザＩＤ及びパスワードを指定してポータルサービスアプリ１１１にログインを要求する。

ステップＳ５２において、ポータルサービスアプリ１１１は認証・認可部１３１にテナントＩＤ、ユーザＩＤ及びパスワードを指定してログインを要求する。認証・認可部１３１は指定されたテナントＩＤ、ユーザＩＤ及びパスワードで認証を行い、認証に成功するとユーザ認証チケットを発行する。認証・認可部１３１は、テナントＩＤ及びユーザＩＤとユーザ認証チケットとを紐付けてセッションＤＢ１８１に記憶させる。セッションＤＢ１８１はセッション情報を記憶する記憶部である。

また、認証・認可部１３１は発行したユーザ認証チケットをポータルサービスアプリ１１１経由でクライアント２００に通知する。ステップＳ５４に進み、クライアント２００はユーザ認証チケットを含めてサービス提供システム３０にリクエストを行う。ステップＳ５４のリクエストにはＡＰＩを利用できる。

ステップＳ５５に進み、サービス提供システム３０の認証エージェント装置３１はクライアント２００からのリクエストに含まれていたユーザ認証チケットのチェックをサービスプラットフォーム提供システム４０の認証・認可部１３１に要求する。認証・認可部１３１はステップＳ５６に進み、チェックを要求されたユーザ認証チケットでセッションＤＢ１８１のレコードを検索し、チェックを要求されたユーザ認証チケットと紐付くテナントＩＤ及びユーザＩＤを取得する。

なお、認証・認可部１３１はチェックを要求されたユーザ認証チケットと紐付くテナントＩＤ及びユーザＩＤを検索できなければ、不正なユーザ認証チケットであることを表すチェック結果を認証エージェント装置３１に返す。例えば認証エージェント装置３１はエラーレスポンスやリダイレクトをクライアント２００に返す。

チェックを要求されたユーザ認証チケットと紐付くテナントＩＤ及びユーザＩＤを取得した認証・認可部１３１はステップＳ５７において、ユーザ・テナントＤＢ１８２を検索してユーザ認証チケットに対応するユーザ関連情報を取得する。なお、ユーザ・テナントＤＢ１８２は図５のテナント情報記憶部１５２及びユーザ情報記憶部１５３に対応するものである。

また、ステップＳ５８において、認証・認可部１３１はライセンスＤＢ１８３を検索してユーザ認証チケットに対応するライセンス関連情報を取得する。なお、ライセンスＤＢ１８３は図５のライセンス情報記憶部１５４に対応するものである。

ステップＳ５９において、認証・認可部１３１は取得したユーザ関連情報及びライセンス関連情報を含むチケット関連情報を認証エージェント装置３１に通知する。ステップＳ６０において、認証エージェント装置３１は通知されたチケット関連情報に基づき、図１７に示した本人情報ヘッダをリクエストのＨＴＴＰヘッダに付与する。

本人情報ヘッダに含まれるライセンス情報ヘッダのＨＴＴＰヘッダ名「Ｘ−Ｎｏ−Ｐｅｒｍｉｓｓｉｏｎ−Ｒｅａｓｏｎ」は認証エージェント装置３１がライセンス関連情報からサービス権限が無いと判定した場合に、以下のように付与する。

図２０はＨＴＴＰヘッダ名「Ｘ−Ｎｏ−Ｐｅｒｍｉｓｓｉｏｎ−Ｒｅａｓｏｎ」の値の付与について説明する図である。図２０に示すようにＨＴＴＰヘッダ名「Ｘ−Ｎｏ−Ｐｅｒｍｉｓｓｉｏｎ−Ｒｅａｓｏｎ」の値は、図１７のライセンス情報ヘッダ例に含まれている契約終了日、課金区分、実行可能なアクションの組み合わせにより、サービス権限無しの理由が対応付けられている。図２０にはサービス権限無しの理由として、トライアル期限切れ、本契約期限切れ、未契約及び期限無しを示している。

ライセンス情報ヘッダ例に含まれている契約終了日は実際に契約が終了になった日を表しているため、契約が実際に終了しないと値が入らない。したがって、契約終了日に値が入っている場合は契約が終了していると判断できる。また、契約終了日に値が入っていない場合は契約が終了していないと判断できる。

認証エージェント装置３１は図２０に示すように、図１７のライセンス情報ヘッダ例に含まれている契約終了日、課金区分、実行可能なアクションの組み合わせによりサービス権限無しであること、及び、サービス権限無しの理由を判定できる。したがって、認証エージェント装置３１はサービス権限無しであると判定した場合に、そのサービス権限無しの理由をＨＴＴＰヘッダ名「Ｘ−Ｎｏ−Ｐｅｒｍｉｓｓｉｏｎ−Ｒｅａｓｏｎ」の値として付与することができる。

図１９に戻り、認証エージェント装置３１はステップＳ６１に進み、図１７の本人情報ヘッダをＨＴＴＰヘッダに付与したリクエストにより、サービス提供装置３２にサービスの提供をリクエストする。ステップＳ６１のリクエストにはＡＰＩを利用できる。サービス提供装置３２はリクエストに応じたサービスをクライアント２００に提供する。

サービス提供装置３２は図１７の本人情報ヘッダをＨＴＴＰヘッダに付与したリクエストからユーザ情報ヘッダやライセンス情報ヘッダの内容を取得できる。ユーザ情報ヘッダやライセンス情報ヘッダの内容はサービスプラットフォーム提供システム４０が保持する情報を含ませることができる。

したがって、サービス提供装置３２はサービスプラットフォーム提供システム４０に直接アクセスしなくても、サービスプラットフォーム提供システム４０が保持する情報を取得し、クライアント２００へのサービスの提供に利用できる。

以上、第１の実施形態に係るユーザ認証チケットでのアクセス制御によれば、ユーザ認証チケットで守りたいパスへのリクエストに対してユーザ認証チケットでのアクセス制御を行うことができる。また、第１の実施形態に係るユーザ認証チケットでのアクセス制御によれば、図１４の設定項目を有する設定ファイルを利用することで、サービスプラットフォーム提供システム４０が保持する情報をリクエストに含ませてサービス提供装置３２に提供できる。リクエストには、例えば図１７のユーザ情報やライセンス情報を含ませることができる。また、リクエストにはレスポンスの形式を指定する情報を含ませることができる。

《機器認証チケットでのアクセス制御》
機器認証チケットでのアクセス制御は一部を除いてユーザ認証チケットでのアクセス制御と同様であるため、適宜説明を省略する。機器認証チケットでのアクセス制御を行うために認証エージェント装置３１は図１４に示したような設定項目を有する。

図２１は機器認証チケットでのアクセス制御の一例のフローチャートである。図２１に示すように、認証エージェント装置３１はステップＳ８１に進み、リクエストに機器認証チケットが存在しないか否かを判定する。機器認証チケットがリクエストに存在しなければ認証エージェント装置３１はステップＳ８７に進み、エラーレスポンスを返す。

機器認証チケットがリクエストに存在すれば、認証エージェント装置３１はステップＳ８２に進み、有効な機器認証チケットがキャッシュに存在するか否かを判定する。有効な機器認証チケットがキャッシュに存在すれば認証エージェント装置３１はステップＳ８６に進み、リクエストのＨＴＴＰヘッダに前述した本人情報ヘッダと同様な手順で機器情報ヘッダを付与する。機器情報ヘッダをリクエストのＨＴＴＰヘッダに付与したあと、認証エージェント装置３１はサービス提供装置３２へのアクセスを許可する。

一方、ステップＳ８２において有効な機器認証チケットがキャッシュに存在しなければ認証エージェント装置３１はステップＳ８３に進み、機器認証チケットの正当性をサービスプラットフォーム提供システム４０に問い合わせる。

ステップＳ８４に進み、認証エージェント装置３１はサービスプラットフォーム提供システム４０に機器認証チケットの正当性を問い合わせた結果に基づき、リクエストに存在した機器認証チケットが不正であるかを判定する。機器認証チケットが不正であれば認証エージェント装置３１はステップＳ８７に進み、エラーレスポンスを返す。

機器認証チケットが不正な機器認証チケットでなければ、認証エージェント装置３１はステップＳ８６に進み、リクエストに存在した正当な機器認証チケットをキャッシュに保存する。その後、認証エージェント装置３１はステップＳ８６において機器情報ヘッダをリクエストのＨＴＴＰヘッダに付与したあと、サービス提供装置３２へのアクセスを許可する。

認証エージェント装置３１は機器情報ヘッダをＨＴＴＰヘッダに付与したリクエストにより、サービス提供装置３２にサービスの提供をリクエストする。サービス提供装置３２はリクエストに応じたサービスをクライアント２００に提供する。

サービス提供装置３２は、機器情報ヘッダをＨＴＴＰヘッダに付与したリクエストから機器情報ヘッダの内容を取得できる。機器情報ヘッダの内容はサービスプラットフォーム提供システム４０が保持する情報を含ませることができる。

したがって、サービス提供装置３２はサービスプラットフォーム提供システム４０に直接アクセスしなくても、サービスプラットフォーム提供システム４０が保持する情報を取得し、クライアント２００へのサービスの提供に利用できる。

以上、第１の実施形態に係る機器認証チケットでのアクセス制御によれば、機器認証チケットで守りたいパスへのリクエストに対して機器認証チケットでのアクセス制御を行うことができる。また、第１の実施形態に係る機器認証チケットでのアクセス制御によれば設定ファイルを利用することで、サービスプラットフォーム提供システム４０が保持する情報をリクエストに含ませてサービス提供装置３２に提供できる。

《認証エージェントＡＰＩ》
認証エージェント装置３１は前述したように認証エージェントＡＰＩを実装し、サービス提供装置３２に公開している。認証エージェントＡＰＩを利用したリクエストをサービス提供装置３２から受け付けると、認証エージェント装置３１は図２２に示すような処理を行う。

図２２は認証エージェントＡＰＩの一例のフローチャートである。図２２に示すように認証エージェント装置３１はステップＳ１０１においてサービス提供装置３２からのアクセスがＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダが無いかを判定する。なお、ＭＦＰであることを示すＨＴＴＰヘッダは図１４の設定項目により指定されている。

ＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダが無ければ、認証エージェント装置３１はステップＳ１０２に進み、４０４ページにリダイレクトさせる。

ＭＦＰ用のＵＲＬへのアクセスであり、且つ、ＭＦＰであることを示すＨＴＴＰヘッダが無い、場合以外であれば、認証エージェント装置３１はステップＳ１０３に進み、リクエストに認証チケットが存在しないか否かを判定する。認証チケットがリクエストに存在しなければ、認証エージェント装置３１はステップＳ１０７に進み、エラーレスポンスを返す。

認証チケットがリクエストに存在すれば、認証エージェント装置３１はステップＳ１０４に進む。ステップＳ１０４において認証エージェント装置３１は有効な認証チケットがキャッシュに存在するか否かを判定する。有効な認証チケットがキャッシュに存在すれば認証エージェント装置３１はステップＳ１０９に進み、リクエストに応じたレスポンスを返す。

一方、ステップＳ１０４において有効な認証チケットがキャッシュに存在しなければ認証エージェント装置３１はステップＳ１０５に進み、リクエストに存在した認証チケットの正当性をサービスプラットフォーム提供システム４０に問い合わせる。

ステップＳ１０６に進み、認証エージェント装置３１はサービスプラットフォーム提供システム４０に認証チケットの正当性を問い合わせた結果に基づき、リクエストに存在した認証チケットが不正であるかを判定する。

リクエストに存在した認証チケットが不正であれば、認証エージェント装置３１はステップＳ１０７に進み、エラーレスポンスを返す。リクエストに存在した認証チケットが不正な認証チケットでなければステップＳ１０８において認証エージェント装置３１はリクエストに存在した正当な認証チケットをキャッシュに保存する。

なお、認証チケットを保存するキャッシュは認証チケットによるアクセス制御と共有するものとする。したがって、認証エージェントＡＰＩでキャッシュに認証チケットが保存されていれば、認証チケットによるアクセス制御時においてもキャッシュに認証チケットが存在すると判定される。その後、認証エージェント装置３１はステップＳ１０９においてリクエストに応じたレスポンスを返す。

図２３は認証エージェントＡＰＩの一例について説明する図である。図２３（Ａ）は認証エージェントＡＰＩが無い場合を表している。図２３（Ｂ）は認証エージェントＡＰＩがある場合を表している。また、図２３では認証エージェント装置３１とサービス提供装置３２とが同一のネットワークＡに存在し、サービスプラットフォーム提供システム４０が異なるネットワークＢに存在している例を示している。

図２３（Ａ）に示すように、認証エージェントＡＰＩが無い場合、サービス提供装置３２はサービスプラットフォーム提供システム４０から直接、必要な情報を取得する必要がある。サービスプラットフォーム提供システム４０はサービス提供装置３２からのアクセスを受け付けるため、サービス提供装置３２が情報を取得するためのＡＰＩをパブリックにしておく必要があった。また、認証エージェントＡＰＩが無い場合はクロスドメイン対応も必要となる。

一方、図２３（Ｂ）に示すように、認証エージェントＡＰＩがある場合、サービス提供装置３２は認証エージェント装置３１を経由して、サービスプラットフォーム提供システム４０から必要な情報を取得できる。

サービスプラットフォーム提供システム４０はサービス提供装置３２からのアクセスを直接受け付けることが無くなるため、サービス提供装置３２が情報を取得するためのＡＰＩをパブリックにしておく必要もない。また、認証エージェントＡＰＩがある場合はクロスドメイン対応も不要となる。

図２４は認証エージェントＡＰＩのレスポンス例を示す図である。認証エージェント装置３１がサービス提供装置３２に返す認証エージェントＡＰＩのレスポンスは例えば図２４に示すように、ヘッダに情報１０００が付与されている。したがって、サービス提供装置３２は認証エージェントＡＰＩを利用することで、認証エージェント装置３１を経由してサービスプラットフォーム提供システム４０から情報１０００を取得できる。

図２５は認証エージェントＡＰＩの一例のシーケンス図である。なお、図２５のシーケンス図では省略しているが、サービス提供装置３２は有効な認証チケットを取得しているものとする。

ステップＳ１５１に進み、サービス提供装置３２は認証エージェントＡＰＩを利用してサービスプラットフォーム提供システム４０からの情報の取得をリクエストする。このリクエストには認証チケットを含ませておく。

ステップＳ１５２に進み、認証エージェント装置３１はサービス提供装置３２からのリクエストに含まれていた認証チケットを指定してサービスプラットフォーム提供システム４０に情報の取得をリクエストする。

サービスプラットフォーム提供システム４０の認証・認可部１３１はステップＳ１５３に進み、認証チケットでセッションＤＢ１８１のレコードを検索し、認証チケットと紐付くテナントＩＤ及びユーザＩＤを取得する。

なお、認証・認可部１３１は認証チケットと紐付くテナントＩＤ及びユーザＩＤを検索できなければ、エラーレスポンスを認証エージェント装置３１に返す。認証チケットと紐付くテナントＩＤ及びユーザＩＤを取得した認証・認可部１３１はステップＳ１５４において、ユーザ・テナントＤＢ１８２を検索して認証チケットに対応するユーザ関連情報を取得する。また、ステップＳ１５５において、認証・認可部１３１はライセンスＤＢ１８３を検索して認証チケットに対応するライセンス関連情報を取得する。

ステップＳ１５６において、認証・認可部１３１は取得したユーザ関連情報及びライセンス関連情報を含むチケット関連情報を認証エージェント装置３１に通知する。ステップＳ１５７において、認証エージェント装置３１は通知されたチケット関連情報を利用してレスポンスを生成する。生成したレスポンスには通知されたチケット関連情報の少なくとも一部を含ませることができる。ステップＳ１５８において、認証エージェント装置３１は生成したレスポンスをサービス提供装置３２に返す。

したがって、サービス提供装置３２はサービスプラットフォーム提供システム４０に直接アクセスしなくても、サービスプラットフォーム提供システム４０が保持する情報を取得し、クライアント２００へのサービスの提供に利用できる。

以上、第１の実施形態に係る情報処理システム１によれば、サービスプラットフォーム提供システム４０から情報を取得する認証エージェントＡＰＩを設け、サービス提供装置３２に利用させることができる。

このため、サービスプラットフォーム提供システム４０は、サービス提供装置３２から直接、情報の問い合わせを受け付ける仕組みを設けることなく、サービス提供装置３２がサービスの提供の為に必要な情報を提供できる。

本発明は、具体的に開示された上記の実施形態に限定されるものではなく、特許請求の範囲から逸脱することなく、種々の変形や変更が可能である。ユーザ端末１１、画像形成装置１２はサービス利用装置の一例である。認証エージェント装置３１はアクセス制御手段、アクセス制御装置の一例である。サービスプラットフォーム提供システム４０は情報提供手段、情報提供装置の一例である。認証チケットは認証済みであることを示す情報の一例である。

１ 情報処理システム
１０ ユーザシステム
１１ ユーザ端末
１２ 画像形成装置
２０ アプリマーケット提供システム
２１ アプリマーケット提供サーバ
３０ サービス提供システム
３１ 認証エージェント装置
３２ サービス提供装置
４０ サービスプラットフォーム提供システム
５０ 業務プラットフォーム提供システム
５１ 業務端末
５２ ライセンス管理サーバ
１０１ アプリケーション
１０２ 共通サービス
１０３ データベース（ＤＢ）
１０４ プラットフォームＡＰＩ（Application Programming Interface）
１１１ ポータルサービスアプリ
１１２ スキャンサービスアプリ
１１３ プリントサービスアプリ
１１４ アカウント登録アプリ
１２１ スキャンサービス部
１２２ プリントサービス部
１２３ アカウント登録部
１３１ 認証・認可部
１３２ テナント管理部
１３３ ユーザ管理部
１３４ ライセンス管理部
１３５ 機器管理部
１３６ 一時画像保存部
１３７ データ保管部
１３８ 画像処理ワークフロー制御部
１３９ ログ収集部
１４１ メッセージキュー
１４２ ワーカー
１５１ ログ情報記憶部
１５２ テナント情報記憶部
１５３ ユーザ情報記憶部
１５４ ライセンス情報記憶部
１５５ 機器情報記憶部
１５６ 一時画像記憶部
１５７ ジョブ情報記憶部
１５８ アプリケーション固有の設定情報記憶部
２００ クライアント
５００ コンピュータ
５０１ 入力装置
５０２ 表示装置
５０３ 外部Ｉ／Ｆ
５０３ａ 記録媒体
５０４ ＲＡＭ
５０５ ＲＯＭ
５０６ ＣＰＵ
５０７ 通信Ｉ／Ｆ
５０８ ＨＤＤ
６０１ コントローラ
６０２ 操作パネル
６０３ 外部Ｉ／Ｆ
６０３ａ 記録媒体
６０４ 通信Ｉ／Ｆ
６０５ プリンタ
６０６ スキャナ
６１１ ＣＰＵ
６１２ ＲＡＭ
６１３ ＲＯＭ
６１４ ＮＶＲＡＭ
６１５ ＨＤＤ
Ｂ バス
ＦＷ ファイヤウォール
Ｎ１〜Ｎ３ ネットワーク

特開２００６−３１７１４号公報

Claims (11)

1. １以上の情報処理装置を含む情報処理システムであって、
   サービス利用装置からサービス提供装置に対するリクエストを受け付け、前記リクエストに認証済みであることを示す情報が含まれている場合に、前記リクエストに付与する付与情報の種類が設定されている設定情報に基づき、前記設定情報に設定されている種類の前記付与情報を前記リクエストに付与して、該リクエストを前記サービス提供装置に送信するアクセス制御手段と、
   前記認証済みであることを示す情報と対応付けて前記付与情報を管理し、前記アクセス制御手段から受信した前記認証済みであることを示す情報と対応する前記付与情報を前記アクセス制御手段に提供する情報提供手段と、
   を有する情報処理システム。
2. 前記アクセス制御手段は、前記サービス提供装置からのリクエストを受け付け、前記リクエストに認証済みであることを示す情報が含まれている場合に、前記設定情報に設定されている種類の前記付与情報を前記リクエストに対するレスポンスに付与すること
   を特徴とする請求項１記載の情報処理システム。
3. 前記アクセス制御手段は、ＡＰＩ（Application Programming Interface）により前記サービス提供装置からのリクエストを受け付けること
   を特徴とする請求項２記載の情報処理システム。
4. 前記アクセス制御手段は、前記設定情報に設定されている前記リクエストに含まれる前記サービス利用装置の種類を示す情報に基づき、前記サービス利用装置の種類を判断して前記認証済みであることを示す情報によるアクセス制御を異ならせること
   を特徴とする請求項１乃至３何れか一項記載の情報処理システム。
5. 前記アクセス制御手段は、前記リクエストに、前記認証済みであることを示す情報が正当でない場合のレスポンスの形式が指定されている場合に、指定された形式で前記リクエストに対するエラーレスポンスを返すこと
   を特徴とする請求項１乃至４何れか一項記載の情報処理システム。
6. 前記アクセス制御手段は、サービスを利用する権限が無い前記サービス利用装置からのリクエストである場合に、前記サービスを利用する権限が無い理由を前記リクエストに付与して、該リクエストを前記サービス提供装置に送信すること
   を特徴とする請求項１乃至５何れか一項記載の情報処理システム。
7. 前記アクセス制御手段は、前記サービス利用装置から前記サービス提供装置に対するリクエストに含まれていた正当な前記認証済みであることを示す情報、又は、前記サービス提供装置からのリクエストに含まれていた正当な前記認証済みであることを示す情報を同一の記憶手段に記憶しておき、前記記憶手段に前記認証済みであることを示す情報が記憶されていれば利用すること
   を特徴とする請求項２記載の情報処理システム。
8. 前記アクセス制御手段は、前記付与情報を前記リクエストのヘッダ部分に付与すること
   を特徴とする請求項１乃至７何れか一項記載の情報処理システム。
9. サービス利用装置からサービス提供装置に対するリクエストを受け付け、前記リクエストに認証済みであることを示す情報が含まれている場合に、前記リクエストに付与する付与情報の種類が設定されている設定情報に基づき、前記設定情報に設定されている種類の前記付与情報を前記リクエストに付与して、該リクエストを前記サービス提供装置に送信するアクセス制御手段と、
   前記認証済みであることを示す情報と対応付けて前記付与情報を管理する情報提供装置から、前記認証済みであることを示す情報と対応する前記付与情報を取得する情報取得手段と、
   を有することを特徴とする情報処理装置。
10. サービス利用装置からサービス提供装置に対するリクエストを受け付け、該リクエストを前記サービス提供装置に送信するアクセス制御装置と、認証済みであることを示す情報と対応付けて付与情報を管理し、前記認証済みであることを示す情報と対応する前記付与情報を前記アクセス制御装置に提供する情報提供装置と、を含む情報処理システムにおいて実行されるアクセス制御方法であって、
    前記リクエストに認証済みであることを示す情報が含まれている場合に、前記アクセス制御装置が前記情報提供装置から前記認証済みであることを示す情報と対応する前記付与情報を取得するステップと、
    前記リクエストに付与する付与情報の種類が設定されている設定情報に基づき、前記設定情報に設定されている種類の前記付与情報を前記リクエストに付与して、該リクエストを前記サービス提供装置に送信するステップと、
    を有するアクセス制御方法。
11. コンピュータを、
    サービス利用装置からサービス提供装置に対するリクエストを受け付け、前記リクエストに認証済みであることを示す情報が含まれている場合に、前記リクエストに付与する付与情報の種類が設定されている設定情報に基づき、前記設定情報に設定されている種類の前記付与情報を前記リクエストに付与して、該リクエストを前記サービス提供装置に送信するアクセス制御手段、
    前記認証済みであることを示す情報と対応付けて前記付与情報を管理する情報提供装置から、前記認証済みであることを示す情報と対応する前記付与情報を取得する情報取得手段、
    として機能させるためのプログラム。

Images