情報処理装置、情報処理方法及びプログラム
【課題】複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることを目的とする。
【解決手段】第一のセキュリティドメイン及び第二のセキュリティドメインに属さず、第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、リソース管理手段は、第二のアプリケーションから第一のアプリケーションのリソースへのアクセス要求を受け取ると、アクセス要求に含まれる第一のアプリケーションに対する認証結果を第一のアプリケーションに引き渡し、第一のアプリケーションから第二のアプリケーションによるリソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を第二のアプリケーションに返却する。
【解決手段】第一のセキュリティドメイン及び第二のセキュリティドメインに属さず、第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、リソース管理手段は、第二のアプリケーションから第一のアプリケーションのリソースへのアクセス要求を受け取ると、アクセス要求に含まれる第一のアプリケーションに対する認証結果を第一のアプリケーションに引き渡し、第一のアプリケーションから第二のアプリケーションによるリソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を第二のアプリケーションに返却する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、アプリケーションのリソースは、各アプリケーションが管理していた。例えば、第一のアプリケーションが、第二のアプリケーションから、前記第一のアプリケーションが管理するリソースに対するアクセス要求を受け取った場合を考える。この様な場合、従来、第一のアプリケーション自身が、前記第二のアプリケーションは前記リソースに対するアクセスを許されたアプリケーションであるか否かを判断していた。
例えば、特許文献１では、サービスＡがセキュリティドメインＸ内のサービスＢが所有するリソースに対するアクセス制御を目的としている。特許文献１の技術では、リソースの管理元であるサービスＢ自身が、サービスＡからの利用可否を判断している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−１４８４６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、複数のアプリケーションのリソースを一元的に管理するサービスを考えた場合、前記サービスは、アプリケーションと独立してリソースを管理する。そのため、前記サービスは、どのセキュリティドメインにも属さず、第一のアプリケーションのリソースに対して、第二のアプリケーションがアクセスを要求してきてもその可否等を判断できない問題があった。
【０００５】
本発明はこのような問題点に鑑みなされたもので、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明は、第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置であって、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、前記判断結果に応じて、前記第二のアプリケーションに対して前記リソースへのアクセスを許可するか否かの判断結果を返却する。
【発明の効果】
【０００７】
本発明によれば、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることができる。
【図面の簡単な説明】
【０００８】
【図１】情報処理装置の一例であるデジタル複合機のハードウェア構成の一例を示す図である。
【図２】ソフトウェアの実行環境等の一例を示す図である。
【図３】旧来のソフトウェアの実行環境等の一例を示す図である。
【図４】ログ領域の構成を示す図である。
【図５】アプリケーションのインストールからアプリケーションのログ領域を確保するまでの処理の一例を示すフローチャートである。
【図６】ログ（又はログ領域）に対するアクセス制御の処理を、ソフトウェア構成を用いて説明するための図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
図１は、情報処理装置の一例であるデジタル複合機のハードウェア構成の一例を示す図である。図１において、ＣＰＵ１０３と、ＲＡＭ１０５、Ｎｅｔｗｏｒｋインターフェース１０４、プリンタ部１０２、操作部１０８、Ｉ／Ｏ制御部１０６が接続され、ＨＤＤ（ハードディスクの意）１０７がＩ／Ｏ制御部１０６を介して接続されている。ＨＤＤ１０７には、プログラムが記憶されており、ＨＤＤ１０７からＣＰＵ１０３に読み込まれ実行される。ＣＰＵ１０３がプログラムを実行することによって、後述するソフトウェアモジュール、及びフローチャートの処理が実現される。ソフトウェアモジュールは、操作部１０８からユーザの操作入力を受け取ることができると共に、プリンタ部１０２、ＲＡＭ１０５、Ｎｅｔｗｏｒｋインターフェース１０４及びＨＤＤ１０７を利用・制御する事が可能である。
【００１１】
図２は、ソフトウェアの実行環境等の一例を示す図である。図２において、２０１は、ソフトウェア実行環境全体を表している。ソフトウェア実行環境における基礎となる部分はＯＳ２０２である。ＯＳとは一般にコンピュータ技術においてオペレーティングシステム（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）と呼ばれるソフトウェアモジュールであり、以下で述べる全てのソフトウェアモジュールはＯＳ２０２上で動作する。また、以下で述べる全てのソフトウェアモジュールは、直接的或いは、後に述べるＪａｖａ（登録商標）実行環境２０４を介して間接的にＯＳ２０２が提供するＡＰＩを介して、図１のハードウェアモジュールの利用・制御を行う。ＡＰＩは、アプリケーション・プログラミング・インターフェースの略である。なお、ＡＰＩの実体はＯＳ２０２に含まれて提供されることになるため、図２では特に示していない。Ｊａｖａ実行環境２０４は、ＯＳ２０２及びその提供するＡＰＩの種類やハードウェア構成に依らず、その上で動作するソフトウェアに均一化されたＡＰＩを提供する。このことによって、ソフトウェアモジュールの開発効率と再利用可能性とを向上させる仮想実行環境（バーチャルマシン）を提供する。
アプリケーション実行フレームワーク２０５は、主にアプリケーションのインストールやアンインストールの管理や、アプリケーションの実行順序の制御、同フレームワーク上のアプリケーションやソフトウェアモジュール間のＡＰＩを介した通信機能等、ソフトウェア実行環境２０１全体を統括して制御する仕組みを提供する。なお、アプリケーション実行フレームワーク２０５は、上述した機能を提供するソフトウェアモジュール群の総称である。
Ｊａｖａ実行環境２０４及び／又はアプリケーション実行フレームワーク２０５は、アプリケーション実行環境の一例である。
【００１２】
ログサービス２０６は、はじめからソフトウェア実行環境２０１に存在するソフトウェアモジュールである。ログサービス２０６は、後にインストールされるアプリケーションのログをＨＤＤ１０７上にログとして記録し管理する機能を提供するが、詳細は後述する図４で示す。ここで、ログとは、一般にアプリケーションの様々な振る舞い、処理の履歴を、ファイルとしてハードディスクやフラッシュメモリ等の記録媒体上に記録されるものの総称である。本実施形態においては、記録媒体としてハードディスク上にファイルとして記録されることとしているが、その他の記録媒体に記録されてもよい。ログサービス２０６は、リソース管理手段の一例である。
ここで、図３において典型的な旧来の構成等の一例を示す。図３は、旧来の構成等の一例を示す図である。図３において、アプリケーション５０７は、アプリケーション５０７のみがアクセス可能なファイルにアプリケーションログ５０９が記録されている。アプリケーション５０８がアプリケーションログ５０９にアクセスする場合、アプリケーション５０８は、予めアクセス可能なパーミッション及びアプリケーション５０７のログ読み出しに対するユーザ権限の取得が必要となる。即ち、アプリケーション５０８は、アプリケーション５０７に対するログ取得を行うパーミッション、及びアプリケーション５０７が提供するＡＰＩによってアプリケーション５０７の管理下にあるユーザの権限を取得する。そして、これらを取得した上で、アプリケーション５０８は、アプリケーションログ５０９を取得することができる。
ここで、アプリケーション５０７は、アプリケーション５０７に対する認証機能とアプリケーションログ５０９のアクセス制御機能とを保有するだけでなく、他のアプリケーションからアクセスされる可能性のあるアプリケーションログ５０９を所有している。言い換えればアプリケーション５０７自身が管理する領域にアプリケーションログ５０９が配置されている。
【００１３】
一方、図２では、任意のアプリケーションは、ログサービス２０６が、アプリケーション実行フレームワーク２０５に対して登録しているＡＰＩを介して、ログサービス２０６の機能を利用することができる。即ち、図３の例においては、アプリケーション５０７は、アプリケーションログ５０９を保有しているが、図２の例においては、図４で示すように、ログサービス２０６が複数のアプリケーションログを保有している。言い換えればログサービス２０６は、アプリケーション２０７等、複数のアプリケーションに対して、ログ領域を提供していることとなる。図２及び図４のような構成を取る最大の動機は、ログ領域の集約化である。ログ領域を一箇所（本実施形態の場合はログサービス２０６）に集約化させておく。このことによって、アプリケーションごとにログの形式、ログの取得方法及びそれらを記録・取得するＡＰＩを統一することができ、システム全体としてどのアプリケーションも統一されたログ形式に則ることができる。また、ログサービス２０６のみから集約されたログ領域のログを採取できれば、システムに存在するアプリケーション全てのログを統一された作法で一度に採取できることとなる。その結果、ユーザのログ採取に関する負荷軽減並びにアプリケーション作者のログ記録・取得処理の作成負荷軽減というメリットが生じる。
【００１４】
ここでまた図２において、ログサービス２０６はそのＡＰＩによって任意のアプリケーションに対して次の機能を提供する。まず、第一の機能は、アプリケーションのみが記録する専用ログ領域を、ログサービス２０６のみが直接的にアクセス可能なＨＤＤ１０７上のファイル（ログファイル）として作成し確保することである。第二の機能は、アプリケーションに対して、ＡＰＩを介してログの記録を行う機能である。第三の機能は、アプリケーションに対して、ＡＰＩを介してログの読み取りを行う機能である。それぞれの機能の詳細は図５以降において説明する。ここで、ログサービス２０６は、複数のログ領域を作成可能であるが、説明を簡易にするため、図４においては、ログサービス２０６が管理するログ領域全体を３０１として示しある。また、ログ領域全体３０１内に、アプリケーション２０７がログ領域３０２を作成・確保しており、その他のアプリケーションのログ領域は、他のアプリケーションのログ領域３０３として表記している。
【００１５】
図５は、アプリケーションのインストールからアプリケーションのログ領域を確保するまでの処理の一例を示すフローチャートである。なお、ログサービス２０６は、既にアプリケーション実行フレームワーク２０５によって既に実行されているものとする。
まず、ステップ４０１で、アプリケーション２０７は、アプリケーション実行フレームワーク２０５によってインストールされ、実行される。
実行されたアプリケーション２０７は、先述のＡＰＩを介して、ログサービス２０６に対してアプリケーション２０７専用のログ領域３０２の確保を要求する。また、アプリケーション２０７は、ユーザ権限確認用ＡＰＩとアプリケーションパーミッション（ここではアプリケーションパーミッションＡとした）とをログ領域３０２に登録する（ステップ４０２）。
アプリケーションパーミッションとは、Ｊａｖａにおいて導入されているアプリケーションの実行体に施されるコードレベルのセキュリティ機構であり、その定義や振舞いはＡＰＩ内部の処理で規定される。一方、パーミッションを保有しているか否かはアプリケーションごとにある定義をその実行体内部のファイル等に宣言する形で実装される。また、パーミッションは、あるＡＰＩを通じて機能や処理を実行要求する場合、そのＡＰＩを呼び出す側のアプリケーションが保有しておくべきものであり、一般にはＡＰＩの機能や処理による異なるパーミッションが定義でき得る。そして、もしアプリケーションがその利用に必要となるパーミッションを保有せずにそのＡＰＩを利用しようとすれば、パーミッションが不足しているものとみなされ、ＡＰＩの利用は中断され失敗することとなる。以下で示すアプリケーションパーミッションＡは、アプリケーションパーミッションＡを、アプリケーションが保有していれば、アプリケーションパーミッションＡが規定する行為、即ちＡＰＩを介してログ領域３０２へアクセスする権限があるとみなされる。
【００１６】
ここで、ユーザ権限確認用ＡＰＩは、後の説明でログサービス２０６が、アプリケーション２０７に対してユーザ権限の確認を行うために利用するものであるが、詳細は後述する。なお、このユーザ権限確認用ＡＰＩの登録は必須ではない。また、アプリケーションパーミッションＡを登録することは、アプリケーションが保有可能なパーミッションのうち、ステップ４０２で確保されたログ領域３０２へアクセスする任意のアプリケーションが保有することを義務付けられることを意味している。即ち、任意のアプリケーションのうち、アプリケーションパーミッションＡを保有しているアプリケーションのみが、ここで確保したログ領域３０２へアクセスする権限を持つ。
なお、このアプリケーションパーミッションの登録は、ログ領域３０２の保有者となるアプリケーション２０７の定めによって決まるものであり、必ずしも設定されなければならないものではない。ここで注意すべきは、ユーザ権限とアプリケーションパーミッションとは、アプリケーション２０７の定めによって独立して定義され、ログサービス２０６によって独立に制御されるものである点であるが、この詳細も後述する。なお、アプリケーションパーミッションとは、アプリケーションがインストールされる際に、任意のアプリケーションの実体（インストールパッケージ）の中に記述されるものである。またアプリケーションパーミッションとは、アプリケーション実行フレームワーク２０５によってインストール時に解釈され、そのアプリケーションが実行中は、Ｊａｖａ実行環境２０４によってそのパーミッションを保有しているかどうかを検証されるものである。本実施形態では、ログサービス２０６は、ＡＰＩを介して任意アプリケーションが同サービスを利用したとき、Ｊａｖａ実行環境２０４のパーミッションチェック機構を介して、アプリケーションパーミッションＡを保有しているかどうかを検証することができる。
次に、ログサービス２０６は、ログ領域３０２と共に、アプリケーションパーミッションＡとユーザ権限確認用のＡＰＩとをＨＤＤ１０７上にファイルとして記録する（ステップ４０３）。
【００１７】
次に、ステップ４０４以降において、ログ領域３０２の保有者であるアプリケーション２０７とは異なるアプリケーション２０８が、ログ領域３０２へアクセスする際の処理について詳述する。ステップ４０４において、アプリケーション２０８は、ログ領域３０２に記録されたログを読み取るようログサービス２０６に対してＡＰＩを介して要求する。このＡＰＩは、先述のＡＰＩとはその実体は異なるが、同様の機構によってログサービス２０６がログ領域へのアクセス用にアプリケーションに対して提供するものである。
この要求に応じて、ログサービス２０６は、ログ領域３０２に対してアプリケーションパーミッションが設定されているかどうかを検証する（ステップ４０５）。ログサービス２０６は、この検証を、先述した通り、ログ領域３０２と共にファイルに保存された情報を基に行うことができる。
次に、ログ領域３０２がアプリケーションパーミッションＡを保持していると検証できた場合、ログサービス２０６は、前記情報を基にアプリケーション２０８がアプリケーションパーミッションＡを保有しているかどうかを検証する（ステップ４０６）。ステップ４０５において、ログ領域３０２にアプリケーションパーミッションが設定されていない場合はステップ４０６の検証は行われずステップ４０７に処理は移る。ログ領域３０２にアプリケーションパーミッションＡが設定され、かつ、アプリケーション２０８がアプリケーションパーミッションＡを保有している場合もステップ４０７に処理は移る。
【００１８】
アプリケーション２０８がアプリケーションパーミッションＡを保有していない場合、ログサービス２０６は、アプリケーション２０８の読み取り要求を拒絶し、アプリケーション２０８にその結果を返却する（ステップ４１２）。
続いて、ステップ４０７において、ログサービス２０６は、ログ領域３０２に対してアプリケーション２０７からユーザ権限確認用ＡＰＩが登録されているかどうかを確認する。ユーザ権限確認用ＡＰＩがログ領域３０２に登録されていない場合、ログサービス２０６は、この時点でアプリケーション２０８のログ領域３０２へのアクセスが許可でき、その結果をアプリケーション２０８に返却する（ステップ４１１）。
一方、ステップ４０７において、ユーザ権限確認用ＡＰＩが登録されている場合には、同ＡＰＩを用いて、ログサービス２０６は、アプリケーション２０７に対してログ領域３０２に対するユーザ権限が妥当かどうかを問い合わせる。なお、ここで、アプリケーション２０８は、事前にアプリケーション２０７に対して、ログサービス２０６を介さずに、ユーザ認証を完了している事とする。ここでいうユーザ認証とは、例えばアプリケーション２０８を操作し、同アプリケーションを介してアプリケーション２０７のログ領域にアクセスする操作を行うユーザが、アプリケーション２０７に対して、所定のＡＰＩを介して行う認証である。言うなれば、アプリケーション２０７は別のアプリケーションに対して独自にユーザ認証するＡＰＩを備える。このＡＰＩによって、アプリケーション２０８は、アプリケーション２０７の管理下にあるユーザ認証を行うことができ、更にその認証結果をアプリケーション２０７から得ることができる。即ち、アプリケーション２０８は、ログサービス２０６に対してユーザ認証を要求するはない。このユーザ認証は、アプリケーション２０７が属するドメイン名を含むユーザ名、又は含まないユーザ名と、パスワードとの組み合わせによって実行されるものとしてもよい。また、ユーザ認証は、機器に装着された外部認証装置を介したＩＣカードや指紋・虹彩認証等のバイオメトリクスによる認証によって行われてもよい。なお、アプリケーション２０８がログサービス２０６に対してアクセス要求したＡＰＩには、この認証結果を引き渡すことができる事としてもよいし、別のＡＰＩで引き渡す事としてもよい。何れの場合も、ログサービス２０６は、この認証結果を、ユーザ権限確認用ＡＰＩを介してアプリケーション２０７に対して引渡す（ステップ４０８）。そして、アプリケーション２０７は、ログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在するかどうかを判断してその結果をログサービス２０６へ返却する（ステップ４０９）。
【００１９】
その結果を以って、ログサービス２０６は、アプリケーション２０８を操作しているユーザの認証結果が、ログ領域３０２にアクセスする権限を有するかどうか判定する（ステップ４１０）。ログサービス２０６は、ログ領域３０２へのアクセスが認められない場合はアクセスを拒絶する結果をアプリケーション２０８に対して返却する（ステップ４１２）。ログサービス２０６は、ログ領域３０２へのアクセスが認められる場合はアクセス許可される結果をアプリケーション２０８に対して返却する（ステップ４１１）。ここで示される結果とは、アプリケーション２０８を介して、認証されたユーザによってログ領域３０２へのアクセスが許可されるかどうかを決し、次のような行為に帰結する。即ち、アプリケーション２０７に対して認証されたユーザが、アプリケーション２０７内の管理者と判定されれば、そのユーザは管理者権限を有するとみなされる。またアプリケーション２０７が管理者とみなすユーザは、アプリケーション２０７が保有するログ領域３０２へのアクセスを認められる。しかし、認証されたユーザがアプリケーション２０７に対する一般ユーザであれば、認められない。こうして返却された結果は、引き続いてＡＰＩを介してログサービス２０６に対するログ領域３０２を介する場合にもパラメータとして指定されることが求められる。即ちＡＰＩの引数に認証結果情報が含まれる場合のみ、そのＡＰＩはログ領域３０２へのアクセスを許容して処理を行う。
【００２０】
以上、ステップ４０１からステップ４１２までの処理によって、ログサービス２０６は、以下のことができる。つまり、アプリケーション２０７がログサービス２０６の管理下で保持するログ領域３０２へのアプリケーション２０８からのアクセス要求に対して、予めログ領域３０２に設定したアプリケーションのパーミッションによるアクセス制御を行うことができる。つまり、ログサービス２０６は、アプリケーション２０７の管理するユーザ権限に基づくログ領域３０２へのアクセスの判断を、アプリケーション２０７にすべて委任することができる。言い換えればログサービス２０６はアプリケーション２０７のログ領域３０２を管理しているにも関わらず、ログ領域３０２へのアクセス制御は、アプリケーション２０７の定めるアクセス制御方法に則ることができる。
【００２１】
図６は、ログ（又はログ領域）に対するアクセス制御の処理を、ソフトウェア構成を用いて説明するための図である。
ＳＱ１において、ログサービス２０６は、例えば、セキュリティドメインＡに属するアプリケーション２０７より、ＡＰＩを介してログ領域３０２の確保要求を受信する。また、ログサービス２０６は、セキュリティドメインＡに属するアプリケーション２０７より、ログ領域のユーザ権限確認用のＡＰＩとアプリケーションパーミッションＡとを含む登録要求も受信する。セキュリティドメインＡは、第一のセキュリティドメインの一例である。セキュリティドメインＢは、第二のセキュリティドメインの一例である。
すると、ＳＱ２において、ログサービス２０６は、管理するログ領域全体３０１内にログ領域３０２を確保すると共に、ログ領域３０２と関連付けて、アプリケーションパーミッションＡとユーザ権限確認用のＡＰＩとをＨＤＤ１０７上にファイルとして記録する。
ＳＱ３において、ログサービス２０６は、例えば、セキュリティドメインＡ及びセキュリティドメインＢに属するアプリケーション２０８より、ログ領域３０２に記録されたログ（又はログ領域）に対するアクセス要求を受信する。
ＳＱ４において、ログサービス２０６は、前記ファイルに記録された情報に基づいて、ログ領域３０２に対してアプリケーションパーミッションが設定されているかどうかを検証する。
【００２２】
アプリケーションパーミッションが設定されていた場合、ＳＱ５において、ログサービス２０６は、アクセス要求を送信してきたアプリケーション２０８がログ領域３０２に設定されていたアプリケーションパーミッションＡを保有しているかどうかを検証する。なお、ログサービス２０６は、上述したように、Ｊａｖａ実行環境２０４のパーミッションチェック機構を介して、前記検証を行う。
アプリケーションパーミッションＡを保有していた場合、ＳＱ６において、ログサービス２０６は、ログ領域３０２に関連付けてユーザ権限確認用ＡＰＩがファイル等に登録されているかどうかを確認する。
ログ領域３０２に関連付けてユーザ権限確認用ＡＰＩがファイル等に登録されていた場合、ＳＱ７において、ログサービス２０６は、上述した認証結果を、ユーザ権限確認用ＡＰＩを介してアプリケーション２０７に対して引渡す。
ＳＱ８において、ログサービス２０６は、アプリケーション２０７より、ログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在するかどうかの判断結果を受け取る。
【００２３】
ＳＱ９において、ログサービス２０６は、アプリケーション２０７から受け取った判断結果を検証し、ログ領域３０２へのアクセスを認めるかどうかを確認する。例えば、ログサービス２０６は、アプリケーション２０７から受け取った判断結果がログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在することを示していた場合、ログ領域３０２へのアクセスを認める。一方、ログサービス２０６は、アプリケーション２０７から受け取った判断結果がログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在しないことを示していた場合、ログ領域３０２へのアクセスを認めない。
ＳＱ１０において、ログサービス２０６は、アプリケーション２０８に対して、ログ領域３０２へのアクセスを許可するか否かを示す結果を返却する。なお、本実施形態では、アクセスを許可するか否かを示す結果を返却したが、アクセスを認めることを確認したことに応じて、ログサービス２０６がログ領域３０２のログをＳＱ１０の返答時点でアプリケーション２０８に対して送信してもよい。
上述したように、ログサービス２０６は、アプリケーション２０７やアプリケーション２０８が属するセキュリティドメインに属していないため、アプリケーション２０８からのアプリケーション２０７のログ領域３０２へのアクセスを許可するか否かの判断を行うことができない。しかしながら、ログサービス２０６が、図６等に示したような処理を行うことによって、アプリケーション２０８からのアプリケーション２０７のログ領域３０２へのアクセス制御を可能としている。
【００２４】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００２５】
以上、上述した各実施形態によれば、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることができる。
なお、上述した実施形態では、リソースの一例として、ログ、又はログ領域を例に説明を行ったがこのことは実施形態を限定するものではない。
【００２６】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【技術分野】
【０００１】
本発明は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来、アプリケーションのリソースは、各アプリケーションが管理していた。例えば、第一のアプリケーションが、第二のアプリケーションから、前記第一のアプリケーションが管理するリソースに対するアクセス要求を受け取った場合を考える。この様な場合、従来、第一のアプリケーション自身が、前記第二のアプリケーションは前記リソースに対するアクセスを許されたアプリケーションであるか否かを判断していた。
例えば、特許文献１では、サービスＡがセキュリティドメインＸ内のサービスＢが所有するリソースに対するアクセス制御を目的としている。特許文献１の技術では、リソースの管理元であるサービスＢ自身が、サービスＡからの利用可否を判断している。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２０００−１４８４６９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、複数のアプリケーションのリソースを一元的に管理するサービスを考えた場合、前記サービスは、アプリケーションと独立してリソースを管理する。そのため、前記サービスは、どのセキュリティドメインにも属さず、第一のアプリケーションのリソースに対して、第二のアプリケーションがアクセスを要求してきてもその可否等を判断できない問題があった。
【０００５】
本発明はこのような問題点に鑑みなされたもので、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることを目的とする。
【課題を解決するための手段】
【０００６】
そこで、本発明は、第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置であって、前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、前記判断結果に応じて、前記第二のアプリケーションに対して前記リソースへのアクセスを許可するか否かの判断結果を返却する。
【発明の効果】
【０００７】
本発明によれば、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることができる。
【図面の簡単な説明】
【０００８】
【図１】情報処理装置の一例であるデジタル複合機のハードウェア構成の一例を示す図である。
【図２】ソフトウェアの実行環境等の一例を示す図である。
【図３】旧来のソフトウェアの実行環境等の一例を示す図である。
【図４】ログ領域の構成を示す図である。
【図５】アプリケーションのインストールからアプリケーションのログ領域を確保するまでの処理の一例を示すフローチャートである。
【図６】ログ（又はログ領域）に対するアクセス制御の処理を、ソフトウェア構成を用いて説明するための図である。
【発明を実施するための形態】
【０００９】
以下、本発明の実施形態について図面に基づいて説明する。
【００１０】
＜実施形態１＞
図１は、情報処理装置の一例であるデジタル複合機のハードウェア構成の一例を示す図である。図１において、ＣＰＵ１０３と、ＲＡＭ１０５、Ｎｅｔｗｏｒｋインターフェース１０４、プリンタ部１０２、操作部１０８、Ｉ／Ｏ制御部１０６が接続され、ＨＤＤ（ハードディスクの意）１０７がＩ／Ｏ制御部１０６を介して接続されている。ＨＤＤ１０７には、プログラムが記憶されており、ＨＤＤ１０７からＣＰＵ１０３に読み込まれ実行される。ＣＰＵ１０３がプログラムを実行することによって、後述するソフトウェアモジュール、及びフローチャートの処理が実現される。ソフトウェアモジュールは、操作部１０８からユーザの操作入力を受け取ることができると共に、プリンタ部１０２、ＲＡＭ１０５、Ｎｅｔｗｏｒｋインターフェース１０４及びＨＤＤ１０７を利用・制御する事が可能である。
【００１１】
図２は、ソフトウェアの実行環境等の一例を示す図である。図２において、２０１は、ソフトウェア実行環境全体を表している。ソフトウェア実行環境における基礎となる部分はＯＳ２０２である。ＯＳとは一般にコンピュータ技術においてオペレーティングシステム（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）と呼ばれるソフトウェアモジュールであり、以下で述べる全てのソフトウェアモジュールはＯＳ２０２上で動作する。また、以下で述べる全てのソフトウェアモジュールは、直接的或いは、後に述べるＪａｖａ（登録商標）実行環境２０４を介して間接的にＯＳ２０２が提供するＡＰＩを介して、図１のハードウェアモジュールの利用・制御を行う。ＡＰＩは、アプリケーション・プログラミング・インターフェースの略である。なお、ＡＰＩの実体はＯＳ２０２に含まれて提供されることになるため、図２では特に示していない。Ｊａｖａ実行環境２０４は、ＯＳ２０２及びその提供するＡＰＩの種類やハードウェア構成に依らず、その上で動作するソフトウェアに均一化されたＡＰＩを提供する。このことによって、ソフトウェアモジュールの開発効率と再利用可能性とを向上させる仮想実行環境（バーチャルマシン）を提供する。
アプリケーション実行フレームワーク２０５は、主にアプリケーションのインストールやアンインストールの管理や、アプリケーションの実行順序の制御、同フレームワーク上のアプリケーションやソフトウェアモジュール間のＡＰＩを介した通信機能等、ソフトウェア実行環境２０１全体を統括して制御する仕組みを提供する。なお、アプリケーション実行フレームワーク２０５は、上述した機能を提供するソフトウェアモジュール群の総称である。
Ｊａｖａ実行環境２０４及び／又はアプリケーション実行フレームワーク２０５は、アプリケーション実行環境の一例である。
【００１２】
ログサービス２０６は、はじめからソフトウェア実行環境２０１に存在するソフトウェアモジュールである。ログサービス２０６は、後にインストールされるアプリケーションのログをＨＤＤ１０７上にログとして記録し管理する機能を提供するが、詳細は後述する図４で示す。ここで、ログとは、一般にアプリケーションの様々な振る舞い、処理の履歴を、ファイルとしてハードディスクやフラッシュメモリ等の記録媒体上に記録されるものの総称である。本実施形態においては、記録媒体としてハードディスク上にファイルとして記録されることとしているが、その他の記録媒体に記録されてもよい。ログサービス２０６は、リソース管理手段の一例である。
ここで、図３において典型的な旧来の構成等の一例を示す。図３は、旧来の構成等の一例を示す図である。図３において、アプリケーション５０７は、アプリケーション５０７のみがアクセス可能なファイルにアプリケーションログ５０９が記録されている。アプリケーション５０８がアプリケーションログ５０９にアクセスする場合、アプリケーション５０８は、予めアクセス可能なパーミッション及びアプリケーション５０７のログ読み出しに対するユーザ権限の取得が必要となる。即ち、アプリケーション５０８は、アプリケーション５０７に対するログ取得を行うパーミッション、及びアプリケーション５０７が提供するＡＰＩによってアプリケーション５０７の管理下にあるユーザの権限を取得する。そして、これらを取得した上で、アプリケーション５０８は、アプリケーションログ５０９を取得することができる。
ここで、アプリケーション５０７は、アプリケーション５０７に対する認証機能とアプリケーションログ５０９のアクセス制御機能とを保有するだけでなく、他のアプリケーションからアクセスされる可能性のあるアプリケーションログ５０９を所有している。言い換えればアプリケーション５０７自身が管理する領域にアプリケーションログ５０９が配置されている。
【００１３】
一方、図２では、任意のアプリケーションは、ログサービス２０６が、アプリケーション実行フレームワーク２０５に対して登録しているＡＰＩを介して、ログサービス２０６の機能を利用することができる。即ち、図３の例においては、アプリケーション５０７は、アプリケーションログ５０９を保有しているが、図２の例においては、図４で示すように、ログサービス２０６が複数のアプリケーションログを保有している。言い換えればログサービス２０６は、アプリケーション２０７等、複数のアプリケーションに対して、ログ領域を提供していることとなる。図２及び図４のような構成を取る最大の動機は、ログ領域の集約化である。ログ領域を一箇所（本実施形態の場合はログサービス２０６）に集約化させておく。このことによって、アプリケーションごとにログの形式、ログの取得方法及びそれらを記録・取得するＡＰＩを統一することができ、システム全体としてどのアプリケーションも統一されたログ形式に則ることができる。また、ログサービス２０６のみから集約されたログ領域のログを採取できれば、システムに存在するアプリケーション全てのログを統一された作法で一度に採取できることとなる。その結果、ユーザのログ採取に関する負荷軽減並びにアプリケーション作者のログ記録・取得処理の作成負荷軽減というメリットが生じる。
【００１４】
ここでまた図２において、ログサービス２０６はそのＡＰＩによって任意のアプリケーションに対して次の機能を提供する。まず、第一の機能は、アプリケーションのみが記録する専用ログ領域を、ログサービス２０６のみが直接的にアクセス可能なＨＤＤ１０７上のファイル（ログファイル）として作成し確保することである。第二の機能は、アプリケーションに対して、ＡＰＩを介してログの記録を行う機能である。第三の機能は、アプリケーションに対して、ＡＰＩを介してログの読み取りを行う機能である。それぞれの機能の詳細は図５以降において説明する。ここで、ログサービス２０６は、複数のログ領域を作成可能であるが、説明を簡易にするため、図４においては、ログサービス２０６が管理するログ領域全体を３０１として示しある。また、ログ領域全体３０１内に、アプリケーション２０７がログ領域３０２を作成・確保しており、その他のアプリケーションのログ領域は、他のアプリケーションのログ領域３０３として表記している。
【００１５】
図５は、アプリケーションのインストールからアプリケーションのログ領域を確保するまでの処理の一例を示すフローチャートである。なお、ログサービス２０６は、既にアプリケーション実行フレームワーク２０５によって既に実行されているものとする。
まず、ステップ４０１で、アプリケーション２０７は、アプリケーション実行フレームワーク２０５によってインストールされ、実行される。
実行されたアプリケーション２０７は、先述のＡＰＩを介して、ログサービス２０６に対してアプリケーション２０７専用のログ領域３０２の確保を要求する。また、アプリケーション２０７は、ユーザ権限確認用ＡＰＩとアプリケーションパーミッション（ここではアプリケーションパーミッションＡとした）とをログ領域３０２に登録する（ステップ４０２）。
アプリケーションパーミッションとは、Ｊａｖａにおいて導入されているアプリケーションの実行体に施されるコードレベルのセキュリティ機構であり、その定義や振舞いはＡＰＩ内部の処理で規定される。一方、パーミッションを保有しているか否かはアプリケーションごとにある定義をその実行体内部のファイル等に宣言する形で実装される。また、パーミッションは、あるＡＰＩを通じて機能や処理を実行要求する場合、そのＡＰＩを呼び出す側のアプリケーションが保有しておくべきものであり、一般にはＡＰＩの機能や処理による異なるパーミッションが定義でき得る。そして、もしアプリケーションがその利用に必要となるパーミッションを保有せずにそのＡＰＩを利用しようとすれば、パーミッションが不足しているものとみなされ、ＡＰＩの利用は中断され失敗することとなる。以下で示すアプリケーションパーミッションＡは、アプリケーションパーミッションＡを、アプリケーションが保有していれば、アプリケーションパーミッションＡが規定する行為、即ちＡＰＩを介してログ領域３０２へアクセスする権限があるとみなされる。
【００１６】
ここで、ユーザ権限確認用ＡＰＩは、後の説明でログサービス２０６が、アプリケーション２０７に対してユーザ権限の確認を行うために利用するものであるが、詳細は後述する。なお、このユーザ権限確認用ＡＰＩの登録は必須ではない。また、アプリケーションパーミッションＡを登録することは、アプリケーションが保有可能なパーミッションのうち、ステップ４０２で確保されたログ領域３０２へアクセスする任意のアプリケーションが保有することを義務付けられることを意味している。即ち、任意のアプリケーションのうち、アプリケーションパーミッションＡを保有しているアプリケーションのみが、ここで確保したログ領域３０２へアクセスする権限を持つ。
なお、このアプリケーションパーミッションの登録は、ログ領域３０２の保有者となるアプリケーション２０７の定めによって決まるものであり、必ずしも設定されなければならないものではない。ここで注意すべきは、ユーザ権限とアプリケーションパーミッションとは、アプリケーション２０７の定めによって独立して定義され、ログサービス２０６によって独立に制御されるものである点であるが、この詳細も後述する。なお、アプリケーションパーミッションとは、アプリケーションがインストールされる際に、任意のアプリケーションの実体（インストールパッケージ）の中に記述されるものである。またアプリケーションパーミッションとは、アプリケーション実行フレームワーク２０５によってインストール時に解釈され、そのアプリケーションが実行中は、Ｊａｖａ実行環境２０４によってそのパーミッションを保有しているかどうかを検証されるものである。本実施形態では、ログサービス２０６は、ＡＰＩを介して任意アプリケーションが同サービスを利用したとき、Ｊａｖａ実行環境２０４のパーミッションチェック機構を介して、アプリケーションパーミッションＡを保有しているかどうかを検証することができる。
次に、ログサービス２０６は、ログ領域３０２と共に、アプリケーションパーミッションＡとユーザ権限確認用のＡＰＩとをＨＤＤ１０７上にファイルとして記録する（ステップ４０３）。
【００１７】
次に、ステップ４０４以降において、ログ領域３０２の保有者であるアプリケーション２０７とは異なるアプリケーション２０８が、ログ領域３０２へアクセスする際の処理について詳述する。ステップ４０４において、アプリケーション２０８は、ログ領域３０２に記録されたログを読み取るようログサービス２０６に対してＡＰＩを介して要求する。このＡＰＩは、先述のＡＰＩとはその実体は異なるが、同様の機構によってログサービス２０６がログ領域へのアクセス用にアプリケーションに対して提供するものである。
この要求に応じて、ログサービス２０６は、ログ領域３０２に対してアプリケーションパーミッションが設定されているかどうかを検証する（ステップ４０５）。ログサービス２０６は、この検証を、先述した通り、ログ領域３０２と共にファイルに保存された情報を基に行うことができる。
次に、ログ領域３０２がアプリケーションパーミッションＡを保持していると検証できた場合、ログサービス２０６は、前記情報を基にアプリケーション２０８がアプリケーションパーミッションＡを保有しているかどうかを検証する（ステップ４０６）。ステップ４０５において、ログ領域３０２にアプリケーションパーミッションが設定されていない場合はステップ４０６の検証は行われずステップ４０７に処理は移る。ログ領域３０２にアプリケーションパーミッションＡが設定され、かつ、アプリケーション２０８がアプリケーションパーミッションＡを保有している場合もステップ４０７に処理は移る。
【００１８】
アプリケーション２０８がアプリケーションパーミッションＡを保有していない場合、ログサービス２０６は、アプリケーション２０８の読み取り要求を拒絶し、アプリケーション２０８にその結果を返却する（ステップ４１２）。
続いて、ステップ４０７において、ログサービス２０６は、ログ領域３０２に対してアプリケーション２０７からユーザ権限確認用ＡＰＩが登録されているかどうかを確認する。ユーザ権限確認用ＡＰＩがログ領域３０２に登録されていない場合、ログサービス２０６は、この時点でアプリケーション２０８のログ領域３０２へのアクセスが許可でき、その結果をアプリケーション２０８に返却する（ステップ４１１）。
一方、ステップ４０７において、ユーザ権限確認用ＡＰＩが登録されている場合には、同ＡＰＩを用いて、ログサービス２０６は、アプリケーション２０７に対してログ領域３０２に対するユーザ権限が妥当かどうかを問い合わせる。なお、ここで、アプリケーション２０８は、事前にアプリケーション２０７に対して、ログサービス２０６を介さずに、ユーザ認証を完了している事とする。ここでいうユーザ認証とは、例えばアプリケーション２０８を操作し、同アプリケーションを介してアプリケーション２０７のログ領域にアクセスする操作を行うユーザが、アプリケーション２０７に対して、所定のＡＰＩを介して行う認証である。言うなれば、アプリケーション２０７は別のアプリケーションに対して独自にユーザ認証するＡＰＩを備える。このＡＰＩによって、アプリケーション２０８は、アプリケーション２０７の管理下にあるユーザ認証を行うことができ、更にその認証結果をアプリケーション２０７から得ることができる。即ち、アプリケーション２０８は、ログサービス２０６に対してユーザ認証を要求するはない。このユーザ認証は、アプリケーション２０７が属するドメイン名を含むユーザ名、又は含まないユーザ名と、パスワードとの組み合わせによって実行されるものとしてもよい。また、ユーザ認証は、機器に装着された外部認証装置を介したＩＣカードや指紋・虹彩認証等のバイオメトリクスによる認証によって行われてもよい。なお、アプリケーション２０８がログサービス２０６に対してアクセス要求したＡＰＩには、この認証結果を引き渡すことができる事としてもよいし、別のＡＰＩで引き渡す事としてもよい。何れの場合も、ログサービス２０６は、この認証結果を、ユーザ権限確認用ＡＰＩを介してアプリケーション２０７に対して引渡す（ステップ４０８）。そして、アプリケーション２０７は、ログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在するかどうかを判断してその結果をログサービス２０６へ返却する（ステップ４０９）。
【００１９】
その結果を以って、ログサービス２０６は、アプリケーション２０８を操作しているユーザの認証結果が、ログ領域３０２にアクセスする権限を有するかどうか判定する（ステップ４１０）。ログサービス２０６は、ログ領域３０２へのアクセスが認められない場合はアクセスを拒絶する結果をアプリケーション２０８に対して返却する（ステップ４１２）。ログサービス２０６は、ログ領域３０２へのアクセスが認められる場合はアクセス許可される結果をアプリケーション２０８に対して返却する（ステップ４１１）。ここで示される結果とは、アプリケーション２０８を介して、認証されたユーザによってログ領域３０２へのアクセスが許可されるかどうかを決し、次のような行為に帰結する。即ち、アプリケーション２０７に対して認証されたユーザが、アプリケーション２０７内の管理者と判定されれば、そのユーザは管理者権限を有するとみなされる。またアプリケーション２０７が管理者とみなすユーザは、アプリケーション２０７が保有するログ領域３０２へのアクセスを認められる。しかし、認証されたユーザがアプリケーション２０７に対する一般ユーザであれば、認められない。こうして返却された結果は、引き続いてＡＰＩを介してログサービス２０６に対するログ領域３０２を介する場合にもパラメータとして指定されることが求められる。即ちＡＰＩの引数に認証結果情報が含まれる場合のみ、そのＡＰＩはログ領域３０２へのアクセスを許容して処理を行う。
【００２０】
以上、ステップ４０１からステップ４１２までの処理によって、ログサービス２０６は、以下のことができる。つまり、アプリケーション２０７がログサービス２０６の管理下で保持するログ領域３０２へのアプリケーション２０８からのアクセス要求に対して、予めログ領域３０２に設定したアプリケーションのパーミッションによるアクセス制御を行うことができる。つまり、ログサービス２０６は、アプリケーション２０７の管理するユーザ権限に基づくログ領域３０２へのアクセスの判断を、アプリケーション２０７にすべて委任することができる。言い換えればログサービス２０６はアプリケーション２０７のログ領域３０２を管理しているにも関わらず、ログ領域３０２へのアクセス制御は、アプリケーション２０７の定めるアクセス制御方法に則ることができる。
【００２１】
図６は、ログ（又はログ領域）に対するアクセス制御の処理を、ソフトウェア構成を用いて説明するための図である。
ＳＱ１において、ログサービス２０６は、例えば、セキュリティドメインＡに属するアプリケーション２０７より、ＡＰＩを介してログ領域３０２の確保要求を受信する。また、ログサービス２０６は、セキュリティドメインＡに属するアプリケーション２０７より、ログ領域のユーザ権限確認用のＡＰＩとアプリケーションパーミッションＡとを含む登録要求も受信する。セキュリティドメインＡは、第一のセキュリティドメインの一例である。セキュリティドメインＢは、第二のセキュリティドメインの一例である。
すると、ＳＱ２において、ログサービス２０６は、管理するログ領域全体３０１内にログ領域３０２を確保すると共に、ログ領域３０２と関連付けて、アプリケーションパーミッションＡとユーザ権限確認用のＡＰＩとをＨＤＤ１０７上にファイルとして記録する。
ＳＱ３において、ログサービス２０６は、例えば、セキュリティドメインＡ及びセキュリティドメインＢに属するアプリケーション２０８より、ログ領域３０２に記録されたログ（又はログ領域）に対するアクセス要求を受信する。
ＳＱ４において、ログサービス２０６は、前記ファイルに記録された情報に基づいて、ログ領域３０２に対してアプリケーションパーミッションが設定されているかどうかを検証する。
【００２２】
アプリケーションパーミッションが設定されていた場合、ＳＱ５において、ログサービス２０６は、アクセス要求を送信してきたアプリケーション２０８がログ領域３０２に設定されていたアプリケーションパーミッションＡを保有しているかどうかを検証する。なお、ログサービス２０６は、上述したように、Ｊａｖａ実行環境２０４のパーミッションチェック機構を介して、前記検証を行う。
アプリケーションパーミッションＡを保有していた場合、ＳＱ６において、ログサービス２０６は、ログ領域３０２に関連付けてユーザ権限確認用ＡＰＩがファイル等に登録されているかどうかを確認する。
ログ領域３０２に関連付けてユーザ権限確認用ＡＰＩがファイル等に登録されていた場合、ＳＱ７において、ログサービス２０６は、上述した認証結果を、ユーザ権限確認用ＡＰＩを介してアプリケーション２０７に対して引渡す。
ＳＱ８において、ログサービス２０６は、アプリケーション２０７より、ログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在するかどうかの判断結果を受け取る。
【００２３】
ＳＱ９において、ログサービス２０６は、アプリケーション２０７から受け取った判断結果を検証し、ログ領域３０２へのアクセスを認めるかどうかを確認する。例えば、ログサービス２０６は、アプリケーション２０７から受け取った判断結果がログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在することを示していた場合、ログ領域３０２へのアクセスを認める。一方、ログサービス２０６は、アプリケーション２０７から受け取った判断結果がログ領域３０２へのアクセス権限が、認証結果に示されるユーザに存在しないことを示していた場合、ログ領域３０２へのアクセスを認めない。
ＳＱ１０において、ログサービス２０６は、アプリケーション２０８に対して、ログ領域３０２へのアクセスを許可するか否かを示す結果を返却する。なお、本実施形態では、アクセスを許可するか否かを示す結果を返却したが、アクセスを認めることを確認したことに応じて、ログサービス２０６がログ領域３０２のログをＳＱ１０の返答時点でアプリケーション２０８に対して送信してもよい。
上述したように、ログサービス２０６は、アプリケーション２０７やアプリケーション２０８が属するセキュリティドメインに属していないため、アプリケーション２０８からのアプリケーション２０７のログ領域３０２へのアクセスを許可するか否かの判断を行うことができない。しかしながら、ログサービス２０６が、図６等に示したような処理を行うことによって、アプリケーション２０８からのアプリケーション２０７のログ領域３０２へのアクセス制御を可能としている。
【００２４】
＜その他の実施形態＞
また、本発明は、以下の処理を実行することによっても実現される。即ち、上述した実施形態の機能を実現するソフトウェア（プログラム）を、ネットワーク又は各種記憶媒体を介してシステム或いは装置に供給し、そのシステム或いは装置のコンピュータ（又はＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【００２５】
以上、上述した各実施形態によれば、複数のアプリケーションのリソースを一元的に管理するサービスによる、第一のアプリケーションのリソースに対する第二のアプリケーションからのアクセス制御を可能とすることができる。
なお、上述した実施形態では、リソースの一例として、ログ、又はログ領域を例に説明を行ったがこのことは実施形態を限定するものではない。
【００２６】
以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
【特許請求の範囲】
【請求項１】
第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置であって、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、
前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を前記第二のアプリケーションに返却する情報処理装置。
【請求項２】
前記第一のセキュリティドメインに属する第二のアプリケーションは、前記第一のセキュリティドメインに属する第一のアプリケーションに対し認証を行うことが可能であり、前記アクセス要求に含まれる認証結果は、前記第二のアプリケーションが前記認証を事前に行った認証の結果であって、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さない前記リソース管理手段は、前記リソースへのアクセスを許可するか否かの判断を行うことができない請求項１記載の情報処理装置。
【請求項３】
前記リソース管理手段は、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可することを示す判断結果を受け取ると、前記第二のアプリケーションに対して前記リソースへのアクセスを許可することを示す判断結果を返却し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可しないことを示す判断結果を受け取ると、前記第二のアプリケーションに対して前記リソースへのアクセスを許可しないことを示す判断結果を返却する請求項１又は２記載の情報処理装置。
【請求項４】
前記リソースは、アプリケーションのログであり、
前記リソース管理手段は、前記第一のアプリケーションを含む複数のアプリケーションのログを管理する請求項１乃至３何れか１項記載の情報処理装置。
【請求項５】
前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記リソースに前記第一のアプリケーションへの問い合わせ用のインターフェースが関連付けられているか否かを判断し、前記リソースに前記第一のアプリケーションへの問い合わせ用のインターフェースが関連付けられている場合、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を、前記インターフェースを介して前記第一のアプリケーションに引き渡す請求項１乃至４何れか１項記載の情報処理装置。
【請求項６】
前記リソース管理手段は、前記第一のアプリケーションのリソースと、前記第一のアプリケーションへの問い合わせ用のインターフェースと、を関連付けて登録する請求項５記載の情報処理装置。
【請求項７】
第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置における情報処理方法であって、
前記情報処理装置は、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、
前記リソース管理手段が、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取るステップと、
前記リソース管理手段が、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡すステップと、
前記リソース管理手段が、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取るステップと、
前記リソース管理手段が、判断結果を前記第二のアプリケーションに返却するステップと、
を含む情報処理方法。
【請求項８】
第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有するコンピュータを、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段として機能させ、
前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を前記第二のアプリケーションに返却するプログラム。
【請求項１】
第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置であって、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、
前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を前記第二のアプリケーションに返却する情報処理装置。
【請求項２】
前記第一のセキュリティドメインに属する第二のアプリケーションは、前記第一のセキュリティドメインに属する第一のアプリケーションに対し認証を行うことが可能であり、前記アクセス要求に含まれる認証結果は、前記第二のアプリケーションが前記認証を事前に行った認証の結果であって、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さない前記リソース管理手段は、前記リソースへのアクセスを許可するか否かの判断を行うことができない請求項１記載の情報処理装置。
【請求項３】
前記リソース管理手段は、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可することを示す判断結果を受け取ると、前記第二のアプリケーションに対して前記リソースへのアクセスを許可することを示す判断結果を返却し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可しないことを示す判断結果を受け取ると、前記第二のアプリケーションに対して前記リソースへのアクセスを許可しないことを示す判断結果を返却する請求項１又は２記載の情報処理装置。
【請求項４】
前記リソースは、アプリケーションのログであり、
前記リソース管理手段は、前記第一のアプリケーションを含む複数のアプリケーションのログを管理する請求項１乃至３何れか１項記載の情報処理装置。
【請求項５】
前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記リソースに前記第一のアプリケーションへの問い合わせ用のインターフェースが関連付けられているか否かを判断し、前記リソースに前記第一のアプリケーションへの問い合わせ用のインターフェースが関連付けられている場合、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を、前記インターフェースを介して前記第一のアプリケーションに引き渡す請求項１乃至４何れか１項記載の情報処理装置。
【請求項６】
前記リソース管理手段は、前記第一のアプリケーションのリソースと、前記第一のアプリケーションへの問い合わせ用のインターフェースと、を関連付けて登録する請求項５記載の情報処理装置。
【請求項７】
第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有する情報処理装置における情報処理方法であって、
前記情報処理装置は、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段を有し、
前記リソース管理手段が、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取るステップと、
前記リソース管理手段が、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡すステップと、
前記リソース管理手段が、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取るステップと、
前記リソース管理手段が、判断結果を前記第二のアプリケーションに返却するステップと、
を含む情報処理方法。
【請求項８】
第一のセキュリティドメインに属する第一のアプリケーションと、前記第一のセキュリティドメイン及び第二のセキュリティドメインに属する第二のアプリケーションと、が動作するアプリケーション実行環境を有するコンピュータを、
前記第一のセキュリティドメイン及び前記第二のセキュリティドメインに属さず、前記第一のアプリケーションを含む複数のアプリケーションのリソースを管理するリソース管理手段として機能させ、
前記リソース管理手段は、前記第二のアプリケーションから前記第一のアプリケーションのリソースへのアクセス要求を受け取ると、前記アクセス要求に含まれる前記第一のアプリケーションに対する認証結果を前記第一のアプリケーションに引き渡し、前記第一のアプリケーションから前記第二のアプリケーションによる前記リソースへのアクセスを許可するか否かの判断結果を受け取ると、判断結果を前記第二のアプリケーションに返却するプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１２−１９０３９４（Ｐ２０１２−１９０３９４Ａ）
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願番号】特願２０１１−５５２９９（Ｐ２０１１−５５２９９）
【出願日】平成２３年３月１４日（２０１１．３．１４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
【公開日】平成２４年１０月４日（２０１２．１０．４）
【国際特許分類】
【出願日】平成２３年３月１４日（２０１１．３．１４）
【出願人】（０００００１００７）キヤノン株式会社 (59,756)
【Ｆターム（参考）】
[ Back to top ]