(57)【要約】【課題】Ｗｅｂアプリケーションに対するアクセス制御の認可ポリシの管理および切り替えを容易に行なう。【解決手段】アクセス検知部３５がＵＲＬを指定するアクセスもしくはタグライブラリにより画面表示項目に対するアクセスを検知した場合に、属性情報取得部３６はアクセスの属性情報を取得する。認可ポリシ評価部３７は、評価対象の認可ポリシの認可ポリシＩＤおよび認可種別を認可実行ポイント定義情報から取得し、この取得した認可ポリシＩＤの認可ポリシを認可ポリシ定義情報から取得した上で、この認可ポリシに定義されたルールと取得済みの属性情報とを照合することで認可ポリシの評価を行なう。アクセス制御実行部３８は、ポリシ評価結果をもとに、ユーザが要求したＵＲＬへのアクセスの可否や画面内の画面項目の表示の有無を制御する。【選択図】      図３
2011086172.tif 000002
【特許請求の範囲】
【請求項１】
Ｗｅｂアプリケーションの利用者の役割を示すロール情報を利用者ごとに定めた利用者情報を記憶する利用者情報記憶手段と、
前記Ｗｅｂアプリケーションの利用にかかる認可の実行ポイントの識別情報、当該実行ポイントに対応する認可ポリシを識別する認可ポリシ識別情報、および複数種類のうち何れかの認可種別を各種認可種別のそれぞれについて関連付けた認可実行ポイント定義情報を記憶する認可実行ポイント記憶手段と、
前記認可実行ポイント定義情報で定められる認可ポリシ識別情報に対応し、かつ前記複数種類の認可種別のそれぞれに対応する認可ポリシを定めた認可ポリシ定義情報を記憶する認可ポリシ記憶手段と、
利用者の端末装置からの前記Ｗｅｂアプリケーションへのアクセス要求をもとに前記利用にかかる認可の実行ポイントの識別情報を取得し、この識別情報に関連付けられる認可ポリシ識別情報および認可種別を前記認可実行ポイント定義情報から取得する取得手段と、
前記アクセス要求を行なった利用者のロール情報を前記利用者情報から取得し、このロール情報を含む、当該アクセス要求にかかる属性情報を取得する属性情報取得手段と、
前記取得手段により取得した認可ポリシ識別情報および認可種別に対応する認可ポリシを前記認可ポリシ定義情報から取得し、この取得結果と前記属性情報取得手段により取得した属性情報とを照合することで前記取得した認可ポリシの評価を行なう認可ポリシ評価部と、
前記認可ポリシ評価部により評価結果に基づいて前記Ｗｅｂアプリケーションへのアクセス制御を行なうアクセス制御部と
を備えたことを特徴とするサーバ装置。
【請求項２】
前記認可ポリシ記憶手段には、
前記認可実行ポイント定義情報で定められる認可ポリシ識別情報に対応し、かつ前記複数種類の認可種別のそれぞれに対応し、かつ複数のルールを有する認可ポリシを定めた認可ポリシ定義情報が記憶され、
前記認可ポリシ評価部は、
前記取得手段により取得した認可ポリシ識別情報および認可種別に対応する認可ポリシの各ルールを前記認可ポリシ定義情報から取得し、この取得結果と、前記属性情報取得手段により取得した属性情報とを照合し、前記取得したルールの何れかに前記取得した属性情報が一致するか否かを判別することで前記取得した認可ポリシの評価を行なう
ことを特徴とする請求項１に記載のサーバ装置。
【請求項３】
前記認可種別は、
前記Ｗｅｂアプリケーションにより前記端末装置へ表示する画面へのアクセス認可、または画面表示項目の表示有無の認可であり、
前記認可ポリシ記憶手段に記憶される認可ポリシは、前記アクセス認可のために前記属性情報取得手段により取得した属性情報と照合するための認可ポリシ、および前記画面表示項目の表示有無の認可のために前記属性情報取得手段により取得した属性情報と照合するための認可ポリシが組み合わされたものである
ことを特徴とする請求項１に記載のサーバ装置。
【請求項４】
Ｗｅｂアプリケーションの利用者が用いる端末装置と当該Ｗｅｂアプリケーションを提供するサーバ装置を有する通信システムであって、
前記サーバ装置は、
前記利用者の役割を示すロール情報を利用者ごとに定めた利用者情報を記憶する利用者情報記憶手段と、
前記Ｗｅｂアプリケーションの利用にかかる認可の実行ポイントの識別情報、当該実行ポイントに対応する認可ポリシを識別する認可ポリシ識別情報、および複数種類のうち何れかの認可種別を各種認可種別のそれぞれについて関連付けた認可実行ポイント定義情報を記憶する認可実行ポイント記憶手段と、
前記認可実行ポイント定義情報で定められる認可ポリシ識別情報に対応し、かつ前記複数種類の認可種別のそれぞれに対応する認可ポリシを定めた認可ポリシ定義情報を記憶する認可ポリシ記憶手段と、
前記端末装置からの前記Ｗｅｂアプリケーションへのアクセス要求をもとに前記利用にかかる認可の実行ポイントの識別情報を取得し、この識別情報に関連付けられる認可ポリシ識別情報および認可種別を前記認可実行ポイント定義情報から取得する取得手段と、
前記アクセス要求を行なった利用者のロール情報を前記利用者情報から取得し、このロール情報を含む、当該アクセス要求にかかる属性情報を取得する属性情報取得手段と、
前記取得手段により取得した認可ポリシ識別情報および認可種別に対応する認可ポリシを前記認可ポリシ定義情報から取得し、この取得結果と前記属性情報取得手段により取得した属性情報とを照合することで前記取得した認可ポリシの評価を行なう認可ポリシ評価部と、
前記認可ポリシ評価部により評価結果に基づいて前記Ｗｅｂアプリケーションへのアクセス制御を行なうアクセス制御部と
を有することを特徴とする通信システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、Ｗｅｂアプリケーションのアクセス制御機能を有するサーバ装置および通信システムに関する。
【背景技術】
【０００２】
従来、一般的に利用されているＷｅｂアプリケーションでは、利用者の権限に応じて、アクセスできる画面を制限したり、画面内のリンクなどの画面項目の表示を制限したりするといったことが行われている。その具体的な実現方法として、サーブレットフィルタの機能を利用したＵＲＬ（Uniform Resource Locater）の認可と、ＪＳＰ（JAVA（登録商標） Script）のタグライブラリを利用した画面表示項目の認可とが挙げられる。
【０００３】
図１０は、ＵＲＬ認可設定情報の記述例を示す図である。図１１は画面表示項目認可設定情報の記述例を示す図である。  
フィルタ機能を利用したＵＲＬの認可は、図１０に示すようにデプロイメントディスクリプタ、または専用の設定ファイルに認可ポリシを記述することで実現していた。  
また、ＪＳＰのカスタムタグを利用した画面表示項目の認可に関する技術は、例えば非特許文献１に開示されており、図１１に示すように各画面用のＪＳＰファイルの中にそれぞれ認可ポリシを記述することで実現していた。また、この画面表示項目の認可に関する技術として、例えば特許文献１に開示されるように、利用者の権限に応じて表示もしくは非表示するための内容を定義しておき、その内容に従って画面表示項目の認可を実現するものがある。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−１２３０６２号公報
【非特許文献】
【０００５】
【非特許文献１】Spring Security、［online］、［平成２１年９月１１日検索］、インターネット＜ＵＲＬ：http://static.springsource.org/spring-security/site/＞
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、Ｗｅｂアプリケーションに対するアクセス制御を行なうための認可ポリシが、ＵＲＬ認可の場合はデプロイメントディスクリプタやＵＲＬ認可用のポリシ記述ファイルで示され、また、画面表示項目の認可の場合は各ＪＳＰファイルや、画面表示項目認可用のポリシ記述ファイルで示されるため、ＵＲＬ認可の認可ポリシの記述箇所と画面表示項目の認可の認可ポリシの記述箇所が分散しているため、ロールの追加や削除、ロール名の変更など認可ポリシの変更を行なうためには、デプロイメントディスクリプタや、各ファイルそれぞれに対して変更を行なう必要があり、運用の負荷が高かった。
【０００７】
そこで、本発明の目的は、Ｗｅｂアプリケーションに対するアクセス制御の認可ポリシの管理および切り替えを容易に行なうことが可能になるサーバ装置および通信システムを提供することにある。
【課題を解決するための手段】
【０００８】
すなわち、本発明に係わるサーバ装置は、Ｗｅｂアプリケーションの利用者の役割を示すロール情報を利用者ごとに定めた利用者情報を記憶する利用者情報記憶手段と、前記Ｗｅｂアプリケーションの利用にかかる認可の実行ポイントの識別情報、当該実行ポイントに対応する認可ポリシを識別する認可ポリシ識別情報、および複数種類のうち何れかの認可種別を各種認可種別のそれぞれについて関連付けた認可実行ポイント定義情報を記憶する認可実行ポイント記憶手段と、前記認可実行ポイント定義情報で定められる認可ポリシ識別情報に対応し、かつ前記複数種類の認可種別のそれぞれに対応する認可ポリシを定めた認可ポリシ定義情報を記憶する認可ポリシ記憶手段と、利用者の端末装置からの前記Ｗｅｂアプリケーションへのアクセス要求をもとに前記利用にかかる認可の実行ポイントの識別情報を取得し、この識別情報に関連付けられる認可ポリシ識別情報および認可種別を前記認可実行ポイント定義情報から取得する取得手段と、前記アクセス要求を行なった利用者のロール情報を前記利用者情報から取得し、このロール情報を含む、当該アクセス要求にかかる属性情報を取得する属性情報取得手段と、前記取得手段により取得した認可ポリシ識別情報および認可種別に対応する認可ポリシを前記認可ポリシ定義情報から取得し、この取得結果と前記属性情報取得手段により取得した属性情報とを照合することで前記取得した認可ポリシの評価を行なう認可ポリシ評価部と、前記認可ポリシ評価部により評価結果に基づいて前記Ｗｅｂアプリケーションへのアクセス制御を行なうアクセス制御部とを備えたことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、Ｗｅｂアプリケーションに対するアクセス制御の認可ポリシの管理および切り替えを容易に行なうことができる。
【図面の簡単な説明】
【００１０】
【図１】本発明の実施形態における従業員情報管理システムの画面構成の一例を示す図。
【図２】本発明の実施形態における従業員情報管理システムが管理するアクセス制御情報の構成例を表形式で示す図。
【図３】本発明の実施形態における従業員情報管理システムの機能構成例を示すブロック図。
【図４】本発明の実施形態における従業員情報管理システムが管理する利用者情報の構成例を表形式で示す図。
【図５】本発明の実施形態における従業員情報管理システムにより表示するメニュー画面の記述例を示す図。
【図６】本発明の実施形態における従業員情報管理システムにより表示する検索結果画面の記述例を示す図。
【図７】本発明の実施形態における従業員情報管理システムが管理する認可実行ポイント定義情報の記述例を示す図。
【図８】本発明の実施形態における従業員情報管理システムが管理する認可ポリシ定義情報の記述例を示す図。
【図９】本発明の実施形態における従業員情報管理システムによる処理動作の手順の一例を示す図。
【図１０】ＵＲＬ認可設定情報の記述例を示す図。
【図１１】画面表示項目認可設定情報の記述例を示す図。
【発明を実施するための形態】
【００１１】
以下図面により本発明の実施形態について説明する。  
本実施形態では、従業員の情報を管理する従業員情報管理システムのアクセス制御について説明する。  
図１は、本発明の実施形態における従業員情報管理システムの画面構成の一例を示す図である。図２は、本発明の実施形態における従業員情報管理システムが管理するアクセス制御情報の構成例を表形式で示す図である。  
このアクセス制御情報では、従業員情報管理システムにおける各画面名、当該画面のリクエストパス、当該画面のアクセス可能ユーザおよび当該画面内の画面項目情報が関連付けられる情報である。この画面項目情報は、画面項目ごとに付与される画面項目ＩＤおよび当該画面項目の表示可能ユーザの情報に区分される。
【００１２】
この従業員情報管理システムでは、ユーザとして一般利用者と管理者の２種類を設定し、一般利用者にはロール「UserRole」を、管理者にはロール「AdminRole」をそれぞれ割り当て、アクセスするユーザのロールに基づいてアクセス制御を行なうものとする。
【００１３】
従業員情報管理システムのメイン画面は、図１に示したメニュー画面Ｇ１である。図２に示すようにメニュー画面Ｇ１のリクエストパスは「/empMenu」であり、このリクエストパスによるメニュー画面Ｇ１のＵＲＬへのアクセスは、図２のアクセス制御情報におけるアクセス可能ユーザの欄に示されるように、一般利用者および管理者の双方に対して許可とする。
【００１４】
また、図１に示すように、メニュー画面Ｇ１には、従業員情報検索画面Ｇ２へのリンクである「従業員情報検索」と、従業員情報登録画面Ｇ４へのリンクである「従業員情報登録」とを有し、これらのリンクはユーザが一般利用者であるか管理者であるかによって、表示の有無が切り替えられる。
【００１５】
図２に示すように、メニュー画面Ｇ１の１つ目のリンク「従業員情報検索」に付与される画面項目ＩＤは「link_search」であり、メニュー画面Ｇ１の２つ目のリンク「従業員情報登録」に付与される画面項目ＩＤは「link_regist」である。  
ここで、図２のアクセス制御情報における画面項目の欄に示すように、ロール「AdminRole」を持つ管理者からのメニュー画面Ｇ１へのアクセスに対しては、リンク「従業員情報検索」およびリンク「従業員情報登録」をともに当該メニュー画面Ｇ１への表示対象とする。一方、ロール「AdminRole」を持たない一般利用者からのメニュー画面Ｇ１へのアクセスに対してはリンク「従業員情報検索」は当該メニュー画面Ｇ１への表示対象とする一方で、リンク「従業員情報登録」は当該メニュー画面Ｇ１への表示対象としない。
【００１６】
また、図２のアクセス制御情報におけるアクセス可能ユーザの欄に示されるように、従業員情報検索画面Ｇ２および検索結果画面Ｇ３は一般利用者、管理者の双方ともアクセス可とし、従業員情報登録画面Ｇ４、従業員情報削除画面Ｇ５および従業員情報更新画面Ｇ６は管理者のみアクセス可とする。
【００１７】
また、検索結果画面Ｇ３において、管理者は検索結果一覧の中の従業員の情報を端末装置１の操作により選択した上で、従業員情報更新画面Ｇ６上で従業員情報の更新を行なったり、従業員情報削除画面Ｇ５上で従業員情報の削除を行なったりすることができる。このため、図２に示すように検索結果画面Ｇ３においては、管理者にのみに対して従業員情報更新画面Ｇ６へのリンク「更新」と従業員情報削除画面Ｇ５へのリンク「削除」とをあわせて表示し、管理者でない一般利用者に対しては何れのリンクも表示しない。  
また、図２のアクセス制御情報の画面項目ＩＤの欄に示すように、検索結果画面Ｇ３の１つ目のリンク「更新」および２つ目のリンク「削除」には、画面項目ＩＤ「link_update_delete」がまとめて付与される。
【００１８】
図３は、本発明の実施形態における従業員情報管理システムの機能構成例を示すブロック図である。  
本実施形態における従業員情報管理システムは、端末装置１およびＷｅｂアプリケーションサーバ２を有する。  
端末装置１は、例えばパーソナルコンピュータであり、Ｗｅｂアプリケーションサーバ２から提供されるサービスを利用するための任意のＷｅｂブラウザの実行機能を有する。
【００１９】
Ｗｅｂアプリケーションサーバ２は、アクセス制御実行装置３を有する。このアクセス制御実行装置３は、装置全体の処理動作を司る制御部３１、記憶装置３２、通信インタフェース３３、認証部３４、アクセス検知部３５、属性情報取得部３６、認可ポリシ評価部３７およびアクセス制御実行部３８を備え、それぞれがバス３９により相互に接続される。
【００２０】
記憶装置３２は、例えばハードディスクドライブや不揮発性メモリなどの記憶媒体であり、認証部３４、アクセス検知部３５、属性情報取得部３６、認可ポリシ評価部３７およびアクセス制御実行部３８による処理動作のためのプログラムを記憶する他、利用者情報記憶部４１、認可実行ポイント記憶部４２、認可ポリシ記憶部４３を有する。
【００２１】
図４は、本発明の実施形態における従業員情報管理システムが管理する利用者情報の構成例を表形式で示す図である。  
利用者情報記憶部４１は、図４に示した形式の利用者情報を記憶する。この利用者情報は、各ユーザのユーザＩＤ、パスワードおよびロールを関連付けた情報であり、管理者による端末装置１の所定の操作を経る事で変更が可能である。
【００２２】
図４に示した利用者情報では、ユーザＩＤが「taro」であるユーザのロールは「AdminRole」であり、ユーザＩＤが「jiro」もしくは「saburo」であるユーザのロールは「UserRole」である。つまり、ユーザＩＤが「taro」であるユーザは管理者の権限を有する。また、ユーザＩＤが「jiro」もしくは「saburo」であるユーザは管理者の権限を有しない一般利用者である。
【００２３】
通信インタフェース３３は端末装置１と通信可能に接続される。認証部３４は、システムを利用するユーザが認証済みか否かを確認し、当該ユーザが未認証の場合は、利用者情報で定義されたユーザＩＤおよびパスワードをもとに認証処理を行なう。  
認証部３４は、認証に成功した場合は、記憶装置３２内で管理されるHTTPセッションにロールを格納する。本実施形態では、Ｗｅｂアプリケーションサーバ２で認証を行なう構成を記述しているが、例えば認証サーバやアクセス管理サーバなど別のミドルウェアを利用して認証を行ってもよい。
【００２４】
アクセス検知部３５は、ユーザからのアクセスを検知する。具体的には、アクセス検知部３５は、ＵＲＬの認可と画面表示項目の認可とをそれぞれ行なうために、フィルタ機能とＪＳＰのタグライブラリとをそれぞれ利用してアクセス検知を行なう。また、アクセス検知部３５は、アクセス検知の際、どの実行ポイントでの認可であるかを示す認可実行ポイントＩＤを取得する。
【００２５】
本実施形態では、ＵＲＬ認可のために、所定のフィルタ名を認可実行ポイントＩＤとした上で、アクセス検知部３５は、フィルタ機能の初期化時にフィルタ名が定義された設定ファイルから認可実行ポイントＩＤを取得する。本実施形態では、フィルタ機能の認可実行ポイントＩＤを「filter」とする。
【００２６】
図５は、本発明の実施形態における従業員情報管理システムにより表示するメニュー画面の記述例を示す図である。図６は、本発明の実施形態における従業員情報管理システムにより表示する検索結果画面の記述例を示す図である。  
図５、図６に示した記述例は、各画面のＪＳＰファイルの記述例である。本実施形態では、画面表示項目認可のために、図５、図６に示すように、各画面のＪＳＰファイルにおける画面表示項目の記述部分のうち表示もしくは非表示を切り替える部分をauthorizeタグで囲み、このタグの属性として認可実行ポイントＩＤを指定する。本実施形態ではauthorizeタグのＩＤ属性（id）として指定された「taglib」を画面表示項目認可のための認可実行ポイントＩＤとする。タグライブラリは、各画面の表示の際に、当該画面のＪＳＰファイル内の認可実行ポイントＩＤを取得する。
【００２７】
また、属性情報取得部３６は、ユーザからのアクセス要求をもとに認可に利用するサブジェクト、リソース、アクションの属性情報を取得する。本実施形態では、属性情報取得部３６は、ＵＲＬ認可、画面表示項目の認可ともに、認証部３４によりHTTPセッションに格納したロールをサブジェクトとして取得する。
【００２８】
また、属性情報取得部３６は、ＵＲＬの認可の場合、HTTPリクエストからリソースとなるリクエスト先ＵＲＬを取得し、当該HTTPリクエストからアクションとなるHTTPメソッドを取得する。また、属性情報取得部３６は、画面表示項目の認可の場合、画面項目ＩＤをリソースとして取得する。
【００２９】
この画面項目ＩＤは、図５、図６に示すように、ＪＳＰファイルに示されるauthorizeタグの「resId」属性として指定され、ＪＳＰファイル表示の際にこの値を取得する。本実施形態では、画面表示項目の認可でのアクションは「表示する」に限定されるため、属性情報取得部３６は、デフォルト値「DISP」をアクションとして取得するものとする。
【００３０】
本実施形態では属性情報取得部３６により取得する属性情報をサブジェクト、リソースおよびアクションとしているが、時間や接続元ＩＰアドレスを利用した認可を行なう場合には、例えば、環境条件（コンディション）として新たにこれらの情報を取得してもよい。
【００３１】
図７は、本発明の実施形態における従業員情報管理システムが管理する認可実行ポイント定義情報の記述例を示す図である。  
認可実行ポイント記憶部４２には、図７に示した形式の認可実行ポイント定義情報が記憶される。この認可実行ポイント定義情報は、認可実行ポイントの識別情報である認可実行ポイントＩＤ（id）と、当該認可実行ポイントにおいて適用する認可ポリシ（policyId）と、認可種別（type）とを定義した情報である。この情報は、端末装置１からの所定の操作により書き換えることができる。
【００３２】
図７に示した例では、認可実行ポイント定義情報中の認可実行ポイントＩＤとして、ＵＲＬ認可を実行するための前述した「filter」と、画面表示項目の認可を実行するための前述した「taglib」の２種類が定義される。また、図７に示すように、それぞれの認可実行ポイントＩＤに対応する認可ポリシとして、共通の認可ポリシＩＤ「policy_001」が指定される。
【００３３】
また、認可実行ポイント定義情報中の認可種別は複数種類であって、認可実行ポイントＩＤが「filter」の場合は「url」が指定され、認可実行ポイントＩＤが「taglib」の場合は「gitem」が指定される。これらの認可種別は、認可ポリシの評価を行なう際に評価対象とするリソースやアクションを区別するために定義される。
【００３４】
図８は、本発明の実施形態における従業員情報管理システムが管理する認可ポリシ定義情報の記述例を示す図である。  
認可ポリシ記憶部４３には、図８に示した形式の認可ポリシ定義情報を記憶する。この認可ポリシ定義情報は、誰（サブジェクト）が、何（リソース）に対して、何（アクション）ができるかを示す情報である。
【００３５】
図８に示すように、認可ポリシ定義情報はXMLファイルで記述され、端末装置１からの所定の操作により書き換えることができる。本実施形態では認可ポリシ定義情報をXMLファイルで記述しているが、RDBを利用してもよい。この認可ポリシ定義情報中の認可ポリシは複数設定することが出来、これらの認可ポリシは、認可実行ポイント定義情報で示された認可ポリシＩＤにより識別される。図８に示した例では、認可ポリシ定義情報中の認可ポリシはPolicyタグで囲まれ、認可ポリシＩＤ「policy_001」が付される認可ポリシである１つ目の認可ポリシ、および認可ポリシＩＤ「policy_002」が付される認可ポリシである２つ目の認可ポリシと定義される。  
また、認可ポリシＩＤに対応する各認可ポリシは単一または複数のルールで構成され、当該ルールにはサブジェクト、リソース、アクションが指定される。認可ポリシ定義情報中の各認可ポリシ中の各ルールはruleタグで囲まれ、各ルールのサブジェクトはSubjectタグで囲まれ、各ルールのリソースはResourceタグで囲まれ、各ルールのアクションはActionタグで囲まれる。サブジェクト、リソース、アクションが、属性情報取得部３６で取得したサブジェクト、リソース、アクションに一致するかどうかの判定はeval属性で指定された方法で判定を行なう。本実施形態において、evalType属性に設定された「full」は全文一致の判定を行なうことを示し、「part」は部分一致の判定を行なうことを示している。
【００３６】
評価対象の認可ポリシの一つのルールの中のサブジェクト、リソースおよびアクションの全てが、属性情報取得部３６で取得したサブジェクト、リソースおよびアクションに一致すれば当該ルールの評価結果は「true」となる。つまり、評価対象の認可ポリシの中に含まれるルールのいずれか一つの評価結果が「true」になれば、認可ポリシ定義情報中の評価対象の認可ポリシのPolicy要素のeffect属性に指定された値である「permit」が認可ポリシの評価結果となる。  
一方、評価対象の認可ポリシの中に含まれるいずれのルールも「true」にならなかった場合は「deny」がポリシ評価結果となる。
【００３７】
図８に示した例では、認可ポリシ定義情報における認可ポリシＩＤ「policy_001」が付される認可ポリシでは２つのルールが定義される。１番目のルールは、サブジェクトが「UserRole」または「AdminRole」を持つユーザである条件、かつ、認可種別が「url」である場合にリソースがメニュー画面Ｇ１へのリクエストパス「/empMenu」、従業員情報検索画面Ｇ２へのリクエストパス「/empSearch」、または検索結果画面Ｇ３へのリクエストパス「/empSearchResult」を含む条件、かつ、認可種別が「url」であるアクションが「GET
」または「POST」である条件を含むルールを指定している。
【００３８】
また、２番目のルールは、サブジェクトが「AdminRole」を持つユーザである条件、かつ、認可種別が「url」である場合にリソースが従業員情報登録画面Ｇ４へのリクエストパス、「/empRegist」、従業員情報削除画面Ｇ５へのリクエストパス「/empDelate」、または従業員情報更新画面Ｇ６へのリクエストパス「/empUpdate」を含む条件、かつ、認可種別が「taglib」である条件、リソースが図２に示したリンク「従業員情報登録」の画面項目ＩＤは「link_regist」、またはリンク「更新」およびリンク「削除」に共通の画面項目ＩＤ「link_update_delete」を含む条件、かつ、認可種別が「url」である場合にアクションが「GET」または「POST」である条件、かつ、認可種別が「taglib」である場合にアクションが「DISP」である条件を含むルールを指定している。  
つまり、本実施形態では、Ｗｅｂアプリケーションにより表示する画面へのアクセス可否の認可のための認可ポリシ、および画面内の画面表示項目の表示有無の認可のための認可ポリシが単一のファイルに記述される。  
本実施形態では認可ポリシを図８のように定義したが、認可ポリシの定義方法は特にこれに限定されるものではなく、他の定義方法でも構わない。
【００３９】
また、認可ポリシ評価部３７は、アクセス検知部３５により取得済みの認可実行ポイントＩＤに対応する認可ポリシＩＤおよび認可種別を図７に示した認可実行ポイント定義情報から取得し、かつ、この取得した認可ポリシＩＤに対応する認可ポリシのサブジェクト、取得済みの認可種別のリソース、取得済みの認可種別のアクションを図８に示した認可ポリシ定義情報から取得し、さらに、この認可ポリシ定義情報から取得した情報と属性情報取得部３６により取得したサブジェクト、リソース、アクションの属性情報とを照合することで、認可ポリシの評価を行なう。
【００４０】
アクセス制御実行部３８は、認可ポリシ評価部３７による評価結果に基づいてアクセス制御を実行する。本実施形態では、アクセス制御実行部３８は、ＵＲＬの認可の場合、認可成功時にユーザの要求するＵＲＬへアクセスさせ、認可失敗時に認可エラー画面へ遷移させる。  
また、アクセス制御実行部３８は、画面表示項目の認可の場合、認可成功時にユーザの要求する画面項目を表示し、認可失敗時にユーザの要求する画面項目を非表示にする。  
また、サービスロジック実行装置４は、ユーザに提供するサービス機能を実行する装置である。
【００４１】
次に、ここまで示した構成のシステムによるアクセス制御の動作について説明する。図９は、本発明の実施形態における従業員情報管理システムによる処理動作の手順の一例を示す図である。  
まず、ＵＲＬ認可の際の作用を説明する。Ｗｅｂアプリケーションサーバ２のアクセス制御実行装置３の認証部３４は、端末装置１のＷｅｂブラウザによる、ユーザＩＤが「taro」であるユーザからのリクエストを受け、ユーザが認証済みか否かをチェックする。Ｗｅｂアプリケーションサーバ２は、未認証であれば、ログイン画面を端末装置１のＷｅｂブラウザの表示画面に表示し、ユーザＩＤおよびパスワードを端末装置１のＷｅｂブラウザからユーザに入力させる。
【００４２】
次に、認証部３４は、ユーザが入力したユーザＩＤおよびパスワードを通信インタフェース３３を介して取得し、この取得結果と図２に示す利用者情報に格納されたユーザＩＤおよびパスワードとを比較することで認証を行なう。認証部３４は、認証に成功すれば、HTTPセッションにロールを格納する。本実施形態では、認証後、図２に示す利用者情報で示される前述したユーザＩＤ「taro」に関連付けられるロール「AdminRole」がHTTPセッションに格納される（ステップＳ１）。
【００４３】
アクセス検知部３５は、端末装置１からのユーザのアクセス、ここではＵＲＬとしてメニュー画面Ｇ１のリクエストパス「/empMenu」をＷｅｂブラウザ上で指定するアクセスを検知する。この場合、アクセス検知部３５は、リクエストパスを指定するアクセスを検知した場合のフィルタ名として記憶装置３２に予め記憶された認可実行ポイントＩＤ「filter」を取得する（ステップＳ２）。
【００４４】
続いて、アクセス検知部３５は属性情報取得部３６に対して属性情報取得を要求する。属性情報取得要求を受けた属性情報取得部３６は、ＵＲＬ認可に利用するサブジェクト、リソースおよびアクションを属性情報として取得し、この取得した属性情報をアクセス検知部３５に返す。具体的には、属性情報取得部３６は、ステップＳ１の処理でHTTPセッションに格納済みのユーザのロール「AdminRole」をサブジェクトとして取得し、当該HTTPリクエストからはリソースとして「http://xxx.xxx.co.jp/empManage/empMenu」を取得し、アクションとしてHTTPメソッドの「GET」,「POST」を取得し、これらの取得結果を属性情報としてアクセス検知部３５に返す（ステップＳ３）。
【００４５】
続いて、アクセス検知部３５は、認可ポリシ評価部３７に対して認可ポリシ評価を要求する。この要求の際、アクセス検知部３５は、ステップＳ２の処理で取得した認可実行ポイントＩＤと、ステップＳ３の処理で属性情報取得部３６により取得した属性情報であるサブジェクト、リソースおよびアクションを認可ポリシ評価部３７に引き渡す。
【００４６】
認可ポリシ評価部３７は、図７に示す認可実行ポイント定義情報の内容を参照し、アクセス検知部３５から引き渡された認可実行ポイントＩＤ「filter」に対応する認可ポリシの認可ポリシＩＤ「policy_001」および認可種別「url」を取得する。
【００４７】
続いて、認可ポリシ評価部３７は、図８に示す認可ポリシ定義情報を参照し、前述のように取得済みの認可ポリシＩＤ「policy_001」の認可ポリシを取得する。そして、認可ポリシ評価部３７は、ステップＳ３の処理により属性情報取得部３６から属性情報として取得したサブジェクト「AdminRole」、リソース「http://xxx.xxx.co.jp/empManage/empMenu」、アクション「GET」,「POST」と、取得済みの認可ポリシに定義されたルールとを照合する。このとき、当該ルール内のリソース、アクションについては、認可ポリシ定義情報中のResource要素、Action要素の属性に認可種別「url」が定義されたものを照合対象とする。
【００４８】
本実施形態では、照合の結果、属性情報取得部３６から属性情報として取得したサブジェクト、リソース、アクションの組み合わせが認可ポリシ定義情報中の認可ポリシＩＤ「policy_001」に対応する認可ポリシの一つ目のルールと一致するため、ルールの評価結果が「true」となり、最終的なポリシ評価結果が「permit」となる（ステップＳ４）。
【００４９】
認可ポリシ評価部３７は、この評価結果をアクセス検知部３５に返す。アクセス検知部３５は、認可ポリシ評価部３７から取得したポリシ評価結果をアクセス制御実行部３８に引渡し、アクセス制御の実行を要求する。
【００５０】
アクセス制御実行部３８は、アクセス検知部３５からのポリシ評価結果「permit」を受け、ユーザが要求した「http://xxx.xxx.co.jp/empManage/empMenu」へのアクセスを許可する。アクセスが許可された後、Ｗｅｂアプリケーションサーバ２は、サービスロジック実行装置４を起動させる。
【００５１】
一方、アクセス制御実行部３８は、認可ポリシ評価の結果、前述のように取得済みの認可ポリシのいずれのルールにも合致せずポリシ評価の結果が「deny」となった場合は、端末装置１における表示画面を認可エラー画面に遷移させる（ステップＳ５）。
【００５２】
次に、画面表示項目の認可の作用として、一般利用者がメニュー画面Ｇ１にアクセスしたときの作用について説明する。  
Ｗｅｂアプリケーションサーバ２のアクセス制御実行装置３の認証部３４は、端末装置１のＷｅｂブラウザによる、ユーザＩＤが「jiro」であるユーザからのリクエストを受け、ユーザが認証済みか否かをチェックする。Ｗｅｂアプリケーションサーバ２は、未認証であれば、ログイン画面を端末装置１のＷｅｂブラウザの表示画面に表示し、ユーザＩＤ、パスワードを端末装置１のＷｅｂブラウザからユーザに入力させる。
【００５３】
次に、認証部３４は、ユーザが入力したユーザＩＤおよびパスワードを通信インタフェース３３を介して取得し、これら取得結果と図２に示す利用者情報に格納されたＩＤおよびパスワードとを比較することで認証を行なう。認証部３４は、認証に成功すれば、HTTPセッションにロールを格納する。本実施形態では認証後、図２に示す利用者情報で示される前述したユーザＩＤ「jiro」に関連付けられるロール「UserRole」がHTTPセッションに格納される（ステップＳ１）。
【００５４】
アクセス検知部３５は、メニュー画面Ｇ１内のＪＳＰのタグライブラリにより画面表示項目に対するアクセスを検知する。本実施形態では、図５に示すＪＳＰファイルのauthorizeタグによりアクセスを検知し、当該タグの属性に設定された認可実行ポイントＩＤ「taglib」を取得する（ステップＳ２）。
【００５５】
続いて、アクセス検知部３５は属性情報取得部３６に対して属性情報取得を要求する。属性情報取得要求を受けた属性情報取得部３６は、画面表示項目の認可に利用するサブジェクト、リソース、アクションを属性情報として取得し、この取得した属性情報をアクセス検知部３５に返す。具体的には、属性情報取得部３６は、ステップＳ１の処理でHTTPセッションに格納済みのロール「UserRole」をサブジェクトとして取得し、メニュー画面Ｇ１のＪＳＰファイルのauthorizeタグに設定されたリソースである画面表示項目ＩＤ「link_regist」を取得し、デフォルト値として記憶装置３２に予め記憶された「DISP」をアクションとして取得し、これらの取得結果を属性情報としてアクセス検知部３５に返す（ステップＳ３）。
【００５６】
続いて、アクセス検知部３５は、認可ポリシ評価部３７に対して認可ポリシ評価を要求する。この要求の際、アクセス検知部３５は、ステップＳ２の処理で取得した認可実行ポイントＩＤと、ステップＳ３の処理で属性情報取得部３６により取得した属性情報であるサブジェクト、リソース、アクション情報とを認可ポリシ評価部３７に引き渡す。
【００５７】
認可ポリシ評価部３７は、図７に示す認可実行ポイント定義情報の内容を参照し、アクセス検知部３５から引き渡された認可実行ポイントＩＤ「taglib」に対応する認可ポリシの認可ポリシＩＤ「policy_001」、認可種別「gitem」を取得する。
【００５８】
続いて、認可ポリシ評価部３７は、図８に示す認可ポリシ定義情報を参照し、前述のように取得済みの認可ポリシＩＤ「policy_001」に対応する認可ポリシを取得する。そして、認可ポリシ評価部３７は、ステップＳ３の処理により属性情報取得部３６から属性情報として取得したサブジェクト「UserRole」、リソース「link_regist」、アクション「DISP」と、取得済みの認可ポリシに定義されたルールとを照合する。このとき、当該ルール内のリソース、アクションについては、認可ポリシ定義情報中のResource要素、Action要素の属性に認可種別「gitem」が定義されたものを照合対象とする。
【００５９】
本実施形態では、照合の結果、属性情報取得部３６から属性情報として取得したサブジェクト、リソース、アクションの組み合わせが認可ポリシ定義情報中の認可ポリシＩＤ「policy_001」に対応する認可ポリシの２つのルールのいずれとも一致しないため、ルールの評価結果が「false」となり、最終的なポリシ評価結果が「deny」となる。（ステップＳ４）
認可ポリシ評価部３７はポリシの評価結果「deny」をアクセス検知部３５に返す。アクセス検知部３５は、認可ポリシ評価部３７から取得したポリシ評価結果をアクセス制御実行部３８に引渡し、アクセス制御の実行を要求する。アクセス制御実行部３８は、ポリシ評価結果「deny」を受け、ユーザが要求したメニュー画面Ｇ１のＪＳＰファイルのauthorizeタグで囲まれたエリアの表示項目を非表示にする（ステップＳ５）。
【００６０】
以上のように、本発明の実施形態では、ＷｅｂアプリケーションのＵＲＬ認可と画面表示項目認可といった複数種類の認可種別に関わる認可ポリシを同一の認可ポリシとして単一のファイルに格納して集中管理することにより、認可ポリシの変更など運用時の負荷を軽減することができる。例えば、ロールの名称を「AdminRole」から「AdRole」に変更したいといった場合には、一つの認可ポリシのみを修正すればよい。
【００６１】
また、認可ポリシ自体をある認可ポリシから別の認可ポリシへ一時的もしくは恒常的に切り換えたい場合には、切り換え前および切り換え後の認可ポリシをともに認可ポリシ定義情報に設定しておくことを前提として、認可実行ポイント定義情報に設定された認可ポリシＩＤを端末装置１への操作により必要時に書き換えるだけで、認可ポリシ定義情報において認可ポリシ評価に用いるための認可ポリシを容易かつ迅速に切り換えることができる。  
つまり、従来のように複数箇所に分散されていた認可ポリシを一箇所に纏めて管理することができ、認可ポリシの切り替えを容易に行なうことが可能になる。
【００６２】
なお、この発明は前記実施形態そのままに限定されるものではなく実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を省略してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。  
なお、上記実施形態に記載した手法は、コンピュータに実行させることのできるプログラムとして、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクなど）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤなど）、光磁気ディスク（ＭＯ）、半導体メモリなどの記憶媒体に格納して頒布することもできる。  
また、この記憶媒体としては、プログラムを記憶でき、かつコンピュータが読み取り可能な記憶媒体であれば、その記憶形式は何れの形態であっても良い。  
また、記憶媒体からコンピュータにインストールされたプログラムの指示に基づきコンピュータ上で稼働しているＯＳ（オペレーティングシステム）や、データベース管理ソフト、ネットワークソフト等のＭＷ（ミドルウェア）等が上記実施形態を実現するための各処理の一部を実行しても良い。  
さらに、本発明における記憶媒体は、コンピュータと独立した媒体に限らず、ＬＡＮやインターネット等により伝送されたプログラムをダウンロードして記憶または一時記憶した記憶媒体も含まれる。  
また、記憶媒体は１つに限らず、複数の媒体から上記実施形態における処理が実行される場合も本発明における記憶媒体に含まれ、媒体構成は何れの構成であっても良い。  
尚、本発明におけるコンピュータは、記憶媒体に記憶されたプログラムに基づき、上記実施形態における各処理を実行するものであって、パソコン等の１つからなる装置、複数の装置がネットワーク接続されたシステム等の何れの構成であっても良い。  
また、本発明におけるコンピュータとは、パーソナルコンピュータに限らず、情報処理機器に含まれる演算処理装置、マイコン等も含み、プログラムによって本発明の機能を実現することが可能な機器、装置を総称している。
【符号の説明】
【００６３】
１…端末装置、２…Ｗｅｂアプリケーションサーバ、３…アクセス制御実行装置、４…サービスロジック実行装置、３１…制御部、３２…記憶装置、３３…通信インタフェース、３４…認証部、３５…アクセス検知部、３６…属性情報取得部、３７…認可ポリシ評価部、３８…アクセス制御実行部、３９…バス、４１…利用者情報記憶部、４２…認可実行ポイント記憶部、４３…認可ポリシ記憶部。
【図１】
2011086172.tif 000003
【図２】
2011086172.tif 000004
【図３】
2011086172.tif 000005
【図４】
2011086172.tif 000006
【図５】
2011086172.tif 000007
【図６】
2011086172.tif 000008
【図７】
2011086172.tif 000009
【図８】
2011086172.tif 000010
【図９】
2011086172.tif 000011
【図１０】
2011086172.tif 000012
【図１１】
2011086172.tif 000013