(57)【要約】【課題】アプリケーション上でRBACを実装する上で省力化する。【解決手段】本RBAC方法では、データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されているデータ項目毎に生成されたデータクラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は権限データにおいて規定されている機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出し、メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトからユーザ識別情報を取得し、検出されたメソッド呼出の対象オブジェクトから、クラスタイプ及びクラス識別名を取得し、メソッド呼出に応じて実行されるメソッドによる処理が、権限データにおいてユーザ識別情報に含まれるロールとクラスタイプ及びクラス識別名とから特定される権限において正当であるか判断する。【選択図】図９
2010108170.tif 000002
【特許請求の範囲】
【請求項１】
データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されている前記データ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は前記権限データにおいて規定されている前記機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出するステップと、
ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、前記ユーザのユーザ識別子及び前記ユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、前記メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、前記ユーザ識別情報を取得するステップと、
検出された前記メソッド呼出の対象オブジェクトから、前記データ項目又は前記機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得ステップと、
前記メソッド呼出に応じて実行されるメソッドによる処理が、前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及び前記クラス識別名とから特定される権限において正当であるか判断する正当性判断ステップと、
正当であると判断された場合に、前記メソッド呼出を前記対象オブジェクトに出力するステップと、
を、コンピュータに実行させるためのプログラム。
【請求項２】
前記オブジェクトデータ取得ステップが、
検出された前記メソッド呼出の対象オブジェクトが前記データ・クラスのオブジェクトであって、前記対象オブジェクトが当該対象オブジェクトの所有者データを含む場合には、当該所有者データを取得するステップ
を含み、
前記正当性判断ステップが、
前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及びクラス識別名とから特定される権限において所有者のみ可能な権限が含まれる場合、取得された前記所有者データが、前記ユーザ識別情報に含まれるユーザ識別子に一致するか判断するステップ
を含む
請求項１記載のプログラム。
【請求項３】
前記正当性判断ステップが、
前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及びクラス識別名とから特定される権限について追加の制限ルールが規定されている場合、当該追加の制限ルールのデータを取得するステップと、
前記追加の制限ルールのデータにおいて確認が必要であり且つ前記対象オブジェクトに規定されている追加規定データを取得するステップと、
前記追加規定データが前記追加の制限ルールを満たしているか判断するステップと、
を含む請求項１又は２記載のプログラム。
【請求項４】
データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されている前記データ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は前記権限データにおいて規定されている前記機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出するステップと、
ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、前記ユーザのユーザ識別子及び前記ユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、前記メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、前記ユーザ識別情報を取得するステップと、
検出された前記メソッド呼出の対象オブジェクトから、前記データ項目又は前記機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得ステップと、
前記メソッド呼出に応じて実行されるメソッドによる処理が、前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及び前記クラス識別名とから特定される権限において正当であるか判断する正当性判断ステップと、
正当であると判断された場合に、前記メソッド呼出を前記対象オブジェクトに出力するステップと、
を含み、コンピュータに実行されるロールベースアクセス制御方法。
【請求項５】
データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されている前記データ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は前記権限データにおいて規定されている前記機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を取得する手段と、
ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、前記ユーザのユーザ識別子及び前記ユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、前記メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、前記ユーザ識別情報を取得する手段と、
取得された前記メソッド呼出の対象オブジェクトから、前記データ項目又は前記機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得手段と、
前記メソッド呼出に応じて実行されるメソッドによる処理が、前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及び前記クラス識別名とから特定される権限において正当であるか判断する正当性判断手段と、
正当であると判断された場合に、前記メソッド呼出を前記対象オブジェクトに出力する手段と、
を有するコンピュータ。
【発明の詳細な説明】
【技術分野】
【０００１】
本技術は、オペレーティングシステム（Operating System：ＯＳ）上で生成されるプロセス内におけるロールベースアクセス制御（Role Based Access Control）技術に関する。
【背景技術】
【０００２】
役割毎にアクセスを制御するＲＢＡＣという考え方は、セキュリティの分野では一般的な考え方である。しかし、ＯＳにＲＢＡＣが実装されている場合、ＯＳは通常１人のユーザによって実行される１つのアプリケーションを１つのプロセスとして認識し、プロセス毎に異なる権限を付与することはできるが、１つのプロセス内の各セッションについて異なる権限を付与することはできない。すなわち、アプリケーション側からはＯＳのＲＢＡＣ基盤を利用することができない場合が多い。
【特許文献１】特開２００７−４１８８１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ＯＳのＲＢＡＣ基盤を利用できないとなると、個別アプリケーション上でＲＢＡＣを実装することになるが、当然ながら手間がかかり、その上完全性を確保することが難しいという問題がある。
【０００４】
従って、本技術の目的は、アプリケーション上でＲＢＡＣを実装する上で省力化すると共に問題の発生を抑制できるようにすることである。
【課題を解決するための手段】
【０００５】
本ロールベースアクセス制御方法は、データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されているデータ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は権限データにおいて規定されている機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出するステップと、ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、ユーザのユーザ識別子及びユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、ユーザ識別情報を取得するステップと、検出されたメソッド呼出の対象オブジェクトから、データ項目又は機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得ステップと、メソッド呼出に応じて実行されるメソッドによる処理が、権限データにおいてユーザ識別情報に含まれるロールとクラスタイプ及びクラス識別名とから特定される権限において正当であるか判断する正当性判断ステップと、正当であると判断された場合に、メソッド呼出を対象オブジェクトに出力するステップとを含む。
【発明の効果】
【０００６】
アプリケーション上でＲＢＡＣを実装する上で省力化すると共に問題の発生を抑制できるようになる。
【発明を実施するための最良の形態】
【０００７】
［実施の形態１］
１．アプリケーションプログラム作成時
図１に、本技術の実施の形態におけるプログラム生成システムの機能ブロック図を示す。本実施の形態におけるプログラム生成システムは、権限テーブル１１と、権限テーブル１１を用いて必要なクラスを自動生成するクラス自動生成器１２と、クラス自動生成器１２によって生成された複数の機能クラス１３１のデータを格納する機能クラス格納部１３と、クラス自動生成器１２によって生成された複数のデータクラス１４１のデータを格納するデータクラス格納部１４とを有する。
【０００８】
図２に権限テーブル１１の一例を示す。図２の例では、「顧客」、「監査役」、「マネージャ」、「ブローカ」といったロールに対して、「申請＋個人情報」、「口座情報」、「申請」、「結果」、「注文」、「資金」、「取引情報」といったデータ項目と、「口座開設」、「口座解約」、「取引の注文」、「取引の実行」、「取引情報のチェック」といった機能とを含む資産の各々について、付与すべき場合には参照権ｒ、更新権ｗ又は実行権ｘが登録されている。このようなテーブルについては、これから開発するシステムの開発者が用意する。
【０００９】
次に、図３乃至図７を用いて、クラス自動生成器１２の処理について説明する。まず、クラス自動生成器１２は、機能クラス生成処理を実施する（図３：ステップＳ１）。この機能クラス生成処理については、図４及び図５を用いて説明する。
【００１０】
まず、クラス自動生成器１２は、権限テーブル１１における未処理の機能を１つ特定する（ステップＳ１１）。機能については、実行権ｘが規定されるので、実行権ｘが規定されている機能のうち未処理の機能を１つ特定する。
【００１１】
そして、対応機能クラスを生成する（ステップＳ１３）。この処理は、雛形の機能クラスのデータをクラス自動生成器１２が有する例えば雛形格納部から読み出すものである。そして、この機能クラスにおいて、クラスタイプとクラス識別子を設定できるようにした自動生成部分を生成する（ステップＳ１５）。その後、自動生成部分のタイプの値に「機能」を設定する（ステップＳ１７）。さらに、自動生成部分のクラス識別名の値に、ステップＳ１１で特定した機能の機能名を設定する（ステップＳ１９）。そして、このようにして生成した機能クラスのデータを、機能クラス格納部１３に格納する（ステップＳ２１）。
【００１２】
その後、全ての機能について処理したか判断し（ステップＳ２３）、未処理の機能が存在する場合には、ステップＳ１１に戻る。一方、全ての機能について処理した場合には処理を終了する。
【００１３】
このような処理によって生成された機能クラスの構造の一例を図５に示す。機能クラス１３１は、自動生成部分とカスタマイズ部分とを含む。自動生成部分では、クラスタイプの値に「機能」が設定されており、クラス識別子の値には各機能の名前（例えば「口座開設」）が設定されている。カスタマイズ部分は、プログラマが自由にデータフィールドやメソッドの追加、実装を行う部分である。
【００１４】
機能クラス格納部１３に格納されている全ての機能クラス１３１のカスタマイズ部分を、以下で述べるような方針にて実装すれば、権限テーブル１１で規定されている機能に関してＲＢＡＣに必要なクラスが漏れなく作成されることとなる。
【００１５】
図３の処理の説明に戻って、クラス自動生成器１２は、データクラス生成処理を実施する（ステップＳ３）。このデータクラス生成処理については、図６及び図７を用いて説明する。
【００１６】
まず、クラス自動生成器１２は、権限テーブル１１における未処理のデータ項目を１つ特定する（ステップＳ３１）。データ項目については、参照権ｒや更新権ｗが規定されるので、参照権ｒや更新権ｗが規定されているデータ項目のうち未処理のデータ項目を１つ特定する。
【００１７】
そして、対応データクラスを生成する（ステップＳ３３）。この処理は、雛形のデータクラスのデータをクラス自動生成器１２が有する例えば雛形格納部から読み出すものである。そして、このデータクラスにおいて、処理に係るデータ項目のデータについての参照用メソッド及び更新用メソッドの宣言部分を含み、タイプとクラス識別子を設定できるようにした自動生成部分を生成する（ステップＳ３５）。その後、自動生成部分のタイプの値に「データ」を設定する（ステップＳ３７）。さらに、自動生成部分のクラス識別名の値に、ステップＳ３１で特定したデータ項目のデータ項目名を設定する（ステップＳ３９）。そして、このようにして生成したデータクラス１４１のデータを、データクラス格納部１４に格納する（ステップＳ４１）。
【００１８】
その後、全てのデータ項目について処理したか判断し（ステップＳ４３）、未処理のデータ項目が存在する場合には、ステップＳ３１に戻る。一方、全てのデータ項目について処理した場合には処理を終了する。
【００１９】
このような処理によって生成されたデータクラス１４１の構造の一例を図７に示す。データクラス１４１は、自動生成部分を含む。自動生成部分では、クラスタイプの値に「データ」が設定されており、クラス識別子の値には各データ項目の名前（例えば「口座情報」）が設定されている。さらに、データクラス１４１の場合には、自動生成部分に、参照用メソッドの宣言部分と、更新用メソッドの宣言部分とを含む。この参照用メソッドの参照処理の具体的な内容と、更新用メソッドの更新処理の具体的な内容とが、カスタマイズ部分であって、プログラマが必要な処理内容の実装を行う部分である。
【００２０】
このように、データクラス格納部１４に格納されている全てのデータクラス１４１のカスタマイズ部分を、以下で述べるような方針にて実装すれば、権限テーブル１１で規定されているデータ項目に関してＲＢＡＣに必要なクラスが漏れなく作成されることとなる。
【００２１】
以上のように機能クラス１３１及びデータクラス１４１を、権限テーブル１１から自動的に生成し、開発者は、これら機能クラス１３１及びデータクラス１４１についてプログラミングを行って、アプリケーションの開発を行う。この際、機能クラス１３１及びデータクラス１４１において自動生成部分については変更を行わないようにする。上でも述べたように、機能クラス１３１のカスタマイズ部分については、データフィールドやメソッドを自由に規定することができる。さらに、データクラス１４１の参照用メソッドの具体的処理部分や更新用メソッドの具体的処理部分については、必要な処理内容を規定することができる。
【００２２】
機能クラス１３１のメソッドやアプリケーション中の他のクラスのメソッドについては、データクラス１４１に係るデータ項目に対するアクセスについて、データクラス１４１の参照用メソッド及び更新用メソッドのみを用いて行うように、プログラミングするものとする。
【００２３】
すなわち、構築されるアプリケーションプログラム全体としては図８のような構造を有するものとする。機能クラス１３１及びデータクラス１４１以外のサーバアプリケーション１００は、ＲＢＡＣの対象となる機能を実行する場合には機能クラス１３１ａ乃至１３１ｃのカスタマイズ部分におけるメソッドを呼び出す。機能クラス１３１ａ乃至１３１ｃのカスタマイズ部分におけるメソッドは、ＲＢＡＣの対象となるデータ項目を参照したり更新したりする場合には、データクラス１４１ａ乃至１４１ｃの該当するデータクラスにおける参照用メソッド又は更新用メソッドを呼び出すようにする。なお、図８には示していないが、サーバアプリケーション１００において、ＲＢＡＣの対象となるデータ項目を参照したり更新する場合には、データクラス１４１ａ乃至１４１ｃの参照用メソッド又は更新用メソッドを呼び出すようにする。
【００２４】
以上のように、クラス自動生成器１２を用いてＲＢＡＣの対象機能及びデータ項目について必要な機能クラス１３１及びデータクラス１４１を生成してから、上で述べた方針に従ってアプリケーションプログラムの開発を行うようにすれば、開発者側で特別にＲＢＡＣについて判断したり追加で実装したりする必要がないため、開発者の手間が削減され、実装漏れも避けることができるようになる。
【００２５】
２．プログラム実行時
上で述べたように実装したアプリケーションプログラムを実行する際には、以下で詳細に述べる権限検査部を導入して、実際の実行時に権限検査を行うようにする。権限検査部は、上で述べたようなメソッド呼出を前提として権限テーブル１１に従ったアクセスが行われているかを検査する共通のライブラリである。すなわち、権限検査部は個別のアプリケーションプログラムにカスタマイズするのではなく、どのアプリケーションプログラムにでも適用できるような形で実装されており、アプリケーションプログラムの開発者が個別に作成せずに済むようにする。このような権限検査部によって、開発者の負担を下げることができ、上で述べたようなメソッド呼出が保証されていれば、漏れなく実行時に権限検査が行われるようになる。
【００２６】
実行時におけるシステム構成を図９に示す。インターネットやイントラネットなどのネットワークに、複数のユーザ端末１ａ及び１ｂと、本実施の形態における主要な処理を実施するサーバ３とが接続されている。サーバ３は、例えば通常のコンピュータであり、図２１で述べるようなハードウエア構成を有する。そして、サーバ３は、ＯＳ３１を実行しており、また、ＯＳ３１上の１つのプロセス内で本実施の形態に係るオブジェクトなども実行している。すなわち、ＯＳ３１にＲＢＡＣ基盤が実装されていたとしても、それを用いることはできず、アプリケーション毎にＲＢＡＣを用意する必要がある状態であるものとする。
【００２７】
また、本実施の形態に関係する構成要素としては、様々な処理を行うサーバアプリケーション１００と、上で述べたように権限テーブル１１から生成された機能クラス１３１のオブジェクト１３５と、同じように権限テーブル１１から生成されたデータクラス１４１のオブジェクト１４５と、権限テーブル１１を参照して本実施の形態における主要な処理を実施する権限検査部３１５と、権限検査部３１５からの指示に従って特定のメソッド呼出（具体的には、機能クラス１３１のメソッド呼出、データクラス１４１の参照用メソッド又は更新用メソッドのメソッド呼出）を捕捉して権限検査部３１５に出力するメソッド呼出捕捉部３１１とを含む。
【００２８】
サーバアプリケーション１００は、例えばユーザ端末１ａからのアクセスに応じて認証処理を実施して当該ユーザのユーザ識別子及びロールを特定してユーザ識別子及びロールを含むユーザ識別情報を保持する、当該ユーザについてのセッションオブジェクトを生成するセッションオブジェクト生成部１１０を有している。セッションオブジェクト生成部１１０自体は従来から存在しているものである。セッションオブジェクト生成部１１０によって生成されたセッションオブジェクト３１３は、セッションＩＤで識別され、上で述べたようにユーザ識別情報を保持している。権限検査部３１５は、セッションＩＤで該当するセッションオブジェクト３１３を特定し、ユーザ識別情報を取得する。
【００２９】
また、メソッド呼出捕捉部３１１は、上で述べたように、機能クラス１３１のメソッド呼出、データクラス１４１の参照用メソッド又は更新用メソッドのメソッド呼出を捕捉対象として指定され、指定に従って該当メソッド呼出を捕捉して、捕捉したメソッド呼出を権限検査部３１５に出力する。具体的には、メソッドの属するクラスのクラスタイプが「機能」について全てのメソッドが指定され、メソッドの属するクラスのクラスタイプが「データ」について参照用メソッド及び更新用メソッドが指定される。このような機能自体は周知であるので、これ以上述べない。
【００３０】
なお、図９では、権限検査部３１５が、カスタマイズルール３１７を参照するようになっているが、本実施の形態ではカスタマイズルール３１７については用いられない。第３の実施の形態で詳しく述べる。
【００３１】
次に、図９に示したシステムの動作を、図１０及び図１１を用いて説明する。まず、例えば認証処理時などのユーザ識別時にセッションオブジェクト生成部１１０は、ユーザ識別子（すなわちユーザＩＤ）及びロールを特定し、当該ユーザＩＤ及びロールを含むユーザ識別情報を含むセッションオブジェクト３１３を生成する（ステップＳ５１）。
【００３２】
また、権限検査部３１５は、機能クラス１３１のメソッド呼出及びデータクラス１４１の参照用及び更新用メソッドのメソッド呼出の捕捉を、メソッド呼出捕捉部３１１に要求する（ステップＳ５３）。メソッド呼出捕捉部３１１は、権限検査部３１５からの上記メソッド呼出捕捉要求を受信し、指定されたメソッド呼出を捕捉するように設定する（ステップＳ５５）。設定はメインメモリなどの記憶装置に保持される。
【００３３】
その後、アプリケーションプログラム１００などによって、メソッド呼出が行われると（ステップＳ５７）、メソッド呼出捕捉部３１１は、当該メソッド呼出がステップＳ５５における設定に従ったものであるか確認し、設定に従ったものである場合には捕捉して、権限検査部３１５に出力する（ステップＳ５９）。一方、メソッド呼出がステップＳ５５における設定に従ったものではない場合、そのままメソッド呼出の宛先オブジェクトに出力される。
【００３４】
権限検査部３１５は、メソッド呼出捕捉部３１１から、捕捉を要求したメソッド呼出を受信すると（ステップＳ６１）、呼出対象メソッドのオブジェクトから、クラス自動生成器１２によって自動的に設定された自動生成項目（すなわちクラスタイプ及びクラス識別名。クラスタイプは既に分かっているので除外しても良い。また、他にも自動的に設定される項目が存在する場合にはその項目をも含む。）のデータを取得する（ステップＳ６３）。自動生成項目データについては、メインメモリなどの記憶装置に保持される。
【００３５】
さらに、権限検査部３１５は、捕捉されたメソッド呼出に含まれるセッションＩＤから該当するセッションオブジェクト３１３を特定し、当該セッションオブジェクト３１３からユーザ識別情報（ユーザ識別子及びロール）を取得する（ステップＳ６５）。ユーザ識別情報については、メインメモリなどの記憶装置に保持される。そして、処理は端子Ａを介して図１１の処理に移行する。
【００３６】
図１１の処理の説明に移行して、権限検査部３１５は、ステップＳ６５の処理結果としてユーザ識別情報を取得できたか、すなわちユーザ識別が完了しているか確認する（ステップＳ６７）。何らかの理由でユーザ識別情報が取得できない場合、すなわちユーザ識別が完了していない場合には、例外を発生させる（ステップＳ７３）。
【００３７】
一方、ユーザ識別情報を取得できた場合には、権限検査部３１５は、ユーザ識別情報に含まれているロールと、自動生成項目データに含まれるクラスタイプ及びクラス識別名とで、権限テーブル１１を検索して、該当する権限を取得する（ステップＳ６９）。
【００３８】
そして、権限検査部３１５は、該当する権限から、メソッド呼出から特定される要求処理が許可されているか、すなわち正当なアクセスであるか判断する（ステップＳ７１）。例えば、機能クラス１３１のメソッドが呼び出された場合には、当該機能クラス１３１についてのメソッド実行が、権限テーブル１１において許可されているか（図２の例では「ｘ」マークが付されているか）判断する。
【００３９】
例えば、クラスタイプが「機能」でクラス識別名が「口座開設」であってロールが「顧客」であれば、権限テーブル１１（図２）では、実行を許可されているので、ロールが「顧客」であるユーザ識別情報が取得され、クラスタイプが「機能」でクラス識別名が「口座開設」である機能クラス１３１のメソッドが呼び出された場合には、正当なアクセスと判断される。一方、ロールが「ブローカ」であれば、許可されていないので正当なアクセスではないと判断される。
【００４０】
また、データクラス１４１の参照用メソッド又は更新用メソッドが呼び出された場合には、当該データクラス１４１についての参照ｒ又は更新ｗが許可されているか判断する。例えば、クラスタイプが「データ」でクラス識別名が「注文」であってロールが「顧客」であれば、権限テーブル１１（図２）では、参照も更新も許可されているので、ロールが「顧客」であるユーザ識別情報が取得され、クラスタイプが「データ」でクラス識別名が「注文」であるデータクラス１４１の更新用メソッドが呼び出された場合には、正当なアクセスであると判断される。一方、ロールが「ブローカ」であれば、許可されていないので正当なアクセスではないと判断される。
【００４１】
正当なアクセスではないと判断された場合には、権限検査部３１５は、例外を発生させる（ステップＳ７３）。一方、正当なアクセスであると判断された場合には、メソッド呼出を呼出先オブジェクトに出力する（ステップＳ７５）。呼出先オブジェクトである機能クラス１３１のオブジェクト１３５又はデータクラス１４１のオブジェクト１４５は、メソッド呼出を受信し、要求された処理を実施する（ステップＳ７７）。すなわち、通常どおりの処理を実施する。
【００４２】
以上のように、権限検査を行うべきメソッド呼出を、機能クラス１３１のいずれかのメソッドのメソッド呼出とデータクラス１４１の参照用又は更新用メソッドのメソッド呼出に限定するようなアプリケーション構成を採用しているため、予め用意した権限検査部３１５によって集中的に必要十分な権限検査を実施することができるようになっている。すなわち、開発者の手間を省き、漏れを無くすようにして、検証もシンプルに実施されるようになっている。
【００４３】
［実施の形態２］
１．アプリケーションプログラム作成時
一般に、口座情報などの個人情報は、顧客というロールのユーザであれば誰の情報でも参照や更新しても良いわけではなく、本人、すなわち所有者のみが参照／更新できるようにすべきである。従って、本実施の形態では、図１２に示すように、権限テーブル１１において（Ｏ）マークの付されたデータ項目については、所有者のみが権限を有するように、第１の実施の形態を変形する。
【００４４】
具体的には、データクラス生成処理（図６）のステップＳ３５で、自動生成部分に、所有者フィールドを含むように生成する。すなわち、図１３Ａに示すように、データクラスの自動生成部分に、データにアクセス可能なロールについての所有者フィールドを設ける。これによって、このデータクラスのオブジェクトには、具体的に特定の所有者ユーザのユーザ識別子が登録される。
【００４５】
２．プログラム実行時
実行時において基本的なシステム構成は、第１の実施の形態についての図９に示したとおりである。
【００４６】
そして、処理フローについても第１の実施の形態についての図１０におけるステップＳ６３において取得される自動生成項目データには、所有者フィールドのデータ、即ち所有者のユーザ識別子が含まれる。
【００４７】
また、図１０の端子Ａ以降の処理は、図１３Ｂに示すような処理となる。権限検査部３１５は、ステップＳ６５の処理結果としてユーザ識別情報を取得できたか、すなわちユーザ識別が完了しているか確認する（ステップＳ８１）。何らかの理由でユーザ識別情報が取得できない場合、すなわちユーザ識別が完了していない場合には、例外を発生させる（ステップＳ８９）。
【００４８】
一方、ユーザ識別情報を取得できた場合には、権限検査部３１５は、ユーザ識別情報に含まれているロールと、自動生成項目データに含まれるクラスタイプ及びクラス識別名とで、権限テーブル１１を検索して、該当する権限を取得する（ステップＳ８３）。
【００４９】
さらに、権限検査部３１５は、該当権限において所有者限定が含まれている場合には、ユーザ識別情報に含まれるユーザＩＤと自動生成項目データに含まれる所有者のユーザ識別子とが一致するか確認する（ステップＳ８５）。
【００５０】
そして、権限検査部３１５は、該当する権限から、メソッド呼出から特定される要求処理が許可されているか、すなわち正当なアクセスであるか判断する（ステップＳ８７）。具体的には、ステップＳ７１と同様の判断を行って、機能クラス１３１のメソッドが呼び出された場合には、当該機能クラス１３１についてのメソッド実行が、権限テーブル１１において許可されているかを判断し、さらに、データクラス１４１の参照用メソッド又は更新用メソッドが呼び出された場合には、当該データクラス１４１についての参照ｒ又は更新ｗが許可されているか判断する。さらに加えて、ステップＳ８７でユーザ識別情報に含まれるユーザＩＤと所有者のユーザ識別子とが一致するかを確認する。
【００５１】
これらの一部でも問題があれば、権限検査部３１５は、例外を発生させる（ステップＳ８９）。一方、全て問題なく、正当なアクセスである場合には、権限検査部３１５は、メソッド呼出を呼出先オブジェクトに出力する（ステップＳ９１）。呼出先オブジェクトである機能クラス１３１のオブジェクト１３５又はデータクラス１４１のオブジェクト１４５は、メソッド呼出を受信し、要求された処理を実施する（ステップＳ９３）。すなわち、通常どおりの処理を実施する。
【００５２】
以上のような変形を加えることによって、所有者のみが可能となるアクセスなどについても権限検査部３１５において確認することができる。
【００５３】
［実施の形態３］
本実施の形態では、図２や図１２で示したような権限テーブル１１だけでは規定できないような細かいアクセス制御を行うものとする。この場合、権限テーブルだけでは対処できないので、図９に示したカスタマイズルール３１７を導入する。権限検査部３１５は、権限テーブル１１を参照して、図１４に示すような（Ｒ０）や（Ｒ１）といったカスタマイズルールが規定されているか確認する。
【００５４】
カスタマイズルールには、例えば、Ｒ０の場合、マネージャというロールは、口座開設や口座解約を行う際には顧客と同一人物であってはならないというルールであり、Ｒ１の場合には、ブローカというロールは、取引の注文や取引の実行について、事前に顧客に承認を受けた者でなければならないというルールである。
【００５５】
権限検査部３１５は、データクラス１４１のオブジェクト１４５及び機能クラス１３１のオブジェクト１３５から、自動生成項目データだけではなく他のデータフィールドの値をも取得可能であるものとする。
【００５６】
口座開設という機能に設定されたＲ０のようなルールの場合には、図１５に示すように、顧客ＩＤフィールドというデータフィールドを、カスタマイズ部分に規定する。
【００５７】
そして実行時には、この口座開設に係る機能クラス１３１のオブジェクトにおける顧客ＩＤフィールドに、開設口座の顧客のユーザＩＤが設定される。これによって、権限検査部３１５は、ユーザ識別情報に含まれるユーザＩＤ（マネージャのユーザＩＤ）と、顧客ＩＤフィールドのユーザＩＤとが一致するか判断できる。
【００５８】
なお、口座開設に係る機能クラス１３１のオブジェクトにおける顧客ＩＤフィールドには、事前にそのオブジェクト自身のメソッドや他の機能クラス１３１のオブジェクトのメソッドにより、開設口座の顧客のユーザＩＤを設定しておくものとする。
【００５９】
すなわち、本実施の形態では、機能クラス１３１のメソッドによる、自分自身を含む機能クラス１３１のメソッドのメソッド呼出については、権限検査部３１５の検査対象から外しておくものとする。具体的には、メソッド呼出捕捉部３１１で捕捉すべきメソッド呼出は、機能クラス１３１のメソッドのメソッド呼出とデータクラス１４１の参照用メソッド及び更新用メソッドのメソッド呼出であるが、ここでは、機能クラス１３１のメソッドのメソッド呼出の呼出元を、サーバアプリケーション１００に限定する。
【００６０】
また、取引の注文という機能に設定されたＲ１のようなルールの場合には、図１６に示すように、承認ブローカというデータフィールドを、カスタマイズ部分に規定する。
【００６１】
そして実行時には、この取引の注文という機能クラス１３１のオブジェクトにおける承認ブローカに、承認済みのブローカのユーザＩＤが設定される。これによって、権限検査部３１５は、ユーザ識別情報に含まれるユーザＩＤ（ブローカのユーザＩＤ）と、承認ブローカフィールドのユーザＩＤとが一致するか判断できる。
【００６２】
次に、プログラム実行時の処理内容について説明する。なお、図１０の処理フローについてはほぼ同じである。但し、上で述べたように、権限検査部３１５からメソッド呼出捕捉部３１１に設定される、捕捉すべきメソッド呼出は、機能クラス１３１のメソッドからのメソッド呼出を除外して、サーバアプリケーション１００からのメソッド呼出に、当該メソッド呼出に含まれる呼出元データ等によって限定する。これによって、メソッド呼出捕捉部３１１は、設定に従ってメソッド呼出を捕捉する。
【００６３】
そして端子Ａ以降の処理は、図１７に示すような処理に置き換える。まず、権限検査部３１５は、ステップＳ６５の処理結果としてユーザ識別情報を取得できたか、すなわちユーザ識別が完了しているか確認する（ステップＳ１０１）。何らかの理由でユーザ識別情報が取得できない場合、すなわちユーザ識別が完了していない場合には、例外を発生させる（ステップＳ１１３）。
【００６４】
一方、ユーザ識別情報を取得できた場合には、権限検査部３１５は、ユーザ識別情報に含まれているロールと、自動生成項目データに含まれるクラスタイプ及びクラス識別名とで、権限テーブル１１を検索して、該当する権限を取得する（ステップＳ１０３）。
【００６５】
そして、権限検査部３１５は、取得した権限に、カスタマイズルールが設定されていることを示すデータが含まれるか判断する（ステップＳ１０５）。カスタマイズルールが設定されていることを示すデータが含まれない場合には、ステップＳ１１１に移行する。なお、ステップＳ１１１に移行する場合には、第１の実施の形態と同様の判断を行う。
【００６６】
一方、カスタマイズルールが設定されていることを示すデータが含まれる場合には、権限検査部３１５は、カスタマイズルール３１７から、該当するカスタマイズルールを抽出すると共に、呼出先のオブジェクトから、カスタマイズルールについて判断する上で必要なデータを取得する（ステップＳ１０７）。例えば、上で述べたＲ０であれば、顧客ＩＤフィールドから顧客のユーザＩＤを読み出す。また、Ｒ１であれば、承認ブローカフィールドから承認済みのブローカのユーザＩＤを読み出す。
【００６７】
そして、権限検査部３１５は、ユーザ識別情報、自動生成項目のデータ及びオブジェクトから取得したデータから、今回のメソッド呼出が、該当するカスタマイズルールに従っているか判断する（ステップＳ１０９）。上でも述べたように、Ｒ０であれば、ユーザ識別情報に含まれるユーザＩＤと、オブジェクトから取得したユーザＩＤとが一致している場合には、カスタマイズルールに反することになる。また、Ｒ１であれば、ユーザ識別情報に含まれるユーザＩＤと、オブジェクトから取得したユーザＩＤとが一致している場合には、カスタマイズルールに従っていることとなる。
【００６８】
このようにして得られたデータから、今回のメソッド呼出が正当なアクセスであるかを判断し（ステップＳ１１１）、正当と判断されない場合には、権限検査部３１５は、例外を発生させる（ステップＳ１１３）。一方、正当なアクセスである場合には、権限検査部３１５は、メソッド呼出を呼出先オブジェクトに出力する（ステップＳ１１５）。呼出先オブジェクトである機能クラス１３１のオブジェクト１３５又はデータクラス１４１のオブジェクト１４５は、メソッド呼出を受信し、要求された処理を実施する（ステップＳ１１７）。すなわち、通常どおりの処理を実施する。
【００６９】
このように、カスタマイズルール３１７を権限検査部３１５の外に規定して、以上のような処理を権限検査部３１５が実施することによって、さまざまな権限確認を行うことができるようになる。なお、カスタマイズルール３１７ではなく、カスタマイズルールについて権限検査を行うような処理部を権限検査部３１５外に設けるようにしても良い。その際には、この場合、カスタマイズルールが規定されていることを検出すると、権限検査部３１５が、その処理部を起動して、その処理部が権限検査部３１５に対して必要なデータを取得するように要求する。そして、その処理部は、権限検査部３１５から得られたデータから、カスタマイズルールに従っているのかを判断する。
【００７０】
［その他の実施の形態］
これまでは権限テーブル１１については、予め開発者が用意することを前提にした説明であったが、現在開発においてよく用いられているＵＭＬ（Unified Modeling Language）におけるユースケース図を利用して、当該ユースケース図から自動的に権限テーブル１１を生成するようにしても良い。これによって開発に必要な書類から自動的に生成できるようにすることによって、余分な作業を削減でき、権限設定の見逃しを少なくすることができる。さらに、ユースケース図は、直感的に描くことができるので、権限テーブルという形式よりは、用意しやすい。
【００７１】
例えば、開発者は、図１８に示すような拡張ユースケース図を用意する。通常であれば、中央のシステム内に、必要な機能が楕円で列挙され、当該機能に関連するアクタが線で結ばれる。本例では、口座開設（Open Account）、口座解約（Close Account）、取引の注文（Receive Trade Order）、取引の実行（Perform Trade）、取引情報のチェック（Check Trade Info）が機能として定義されている。なお、＜＜Ａ＞＞は、必ず提供すべき機能であることを表している。また、顧客（Customer）、監査役（Auditor）、マネージャ（Manager）、ブローカ（Broker）がアクタとして規定されている。顧客は、口座開設、口座解約、取引の注文、取引の実行といった機能に関連しており、監査役は、取引情報のチェックという機能に関連しており、マネージャは口座開設及び口座解約という機能に関連し、ブローカは取引の注文及び取引の実行という機能に関連している。
【００７２】
このような通常の記述に加えて、各関連に関係するデータ及びそのデータの参照・更新を表す矢印が追加で記述する必要がある。
【００７３】
具体的には、申請＋個人情報（Request+Personal Info）というデータ１００１ａが、顧客と口座開設との間に規定されており、参照更新権限を表す、アクタから機能への矢印１００１ｂも規定されている。同様に、口座情報（Account Info）というデータ１００２ａが、顧客と口座開設との間に規定されており、参照権限を表す、機能からアクタへの矢印１００２ｂも規定されている。
【００７４】
さらに、結果（Result）というデータ１００３ａが、顧客と口座解約との間に規定されており、参照権限を表す、機能からアクタへの矢印１００３ｂも規定されている。同様に、申請（Rquest）というデータ１００４ａが、顧客と口座解約との間に規定されており、参照更新権限を表す、アクタから機能への矢印１００４ｂも規定されている。
【００７５】
また、注文（Order）というデータ１００５ａが、顧客と取引の注文との間に規定されており、参照更新権限を表す、アクタから機能への矢印１００５ｂも規定されている。
【００７６】
さらに、資金（Money）というデータ１００６ａが、顧客と取引の実行との間に規定されており、参照更新権限を表す、アクタから機能への矢印１００６ｂも規定されている。
【００７７】
また、取引情報（Trade Info）というデータ１００７ａが、監査役と取引情報のチェックとの間に規定されており、参照権限を表す、機能からアクタへの矢印１００７ｂも規定されている。
【００７８】
さらに、申請＋個人情報（Request+Personal Info）というデータ１００８ａが、マネージャと口座開設との間に規定されており、参照権限を表す、機能からアクタへの矢印１００８ｂも規定されている。また、口座情報（Account Info）というデータ１００９ａが、マネージャと口座開設との間に規定されており、参照更新権限を表す、アクタから機能への矢印１００９ｂも規定されている。さらに、申請（Request）というデータ１０１０ａが、マネージャと口座解約との間に規定されており、参照権限を表す、機能からアクタへの矢印１０１０ｂも規定されている。さらに、結果（Result）というデータ１０１１ａは、マネージャと口座解約との間に規定されており、参照更新権限を表す、アクタから機能への矢印１０１１ｂも規定されている。
【００７９】
また、注文（Order）というデータ１０１２ａが、ブローカと取引の注文との間に規定されており、参照権限を表す、機能からアクタへの矢印１０１２ｂも規定されている。また、資金（Money）というデータ１０１３ａが、ブローカと取引の実行との間に規定されており、参照更新権限を表す、アクタから機能への矢印１０１３ｂも規定されている。
【００８０】
なお、データに含まれる＜＜Ｃ２＞＞は、漏れてはいけないデータであることを表し、＜＜Ｉ＞＞は、改ざん不可を表す。
【００８１】
このようなデータを電子データとして用意した上で、以下のような処理を、権限テーブル生成プログラムに実行させる。
【００８２】
具体的には、アクタと機能との接続を検出して、アクタに、接続されている機能に対する実行権限を付与するように設定する（図１９：ステップＳ２０１）。これによって、図１８の例では、顧客は４つの機能の実行権限を得て、監査役は１つの機能の実行権限を得て、マネージャは２つの機能の実行権限を得て、ブローカは２つの機能の実行権限を得ることになる。
【００８３】
また、アクタと機能間にデータが存在している場合には、アクタから機能へのフロー（矢印）を検出して、アクタに、対象データに対する参照更新権限を付与するように設定する（ステップＳ２０３）。データ１００１ａ、データ１００４ａ、データ１００５ａ、データ１００６ａ、データ１００９ａ、データ１０１１ａ、データ１０１３ａについては、アクタから機能への矢印が設定されているので、参照更新権限がアクタに与えられるようになる。
【００８４】
さらに、アクタと機能間にデータが存在している場合には、機能からアクタへのフロー（矢印）を検出して、アクタに、対象データに対する参照権限を付与するように設定する（ステップＳ２０５）。データ１００２ａ、データ１００３ａ、データ１００７ａ、データ１００８ａ、データ１０１０ａ、データ１０１２ａについては、機能からアクタへの矢印が設定されているので、参照権限がアクタに与えられるようになる。
【００８５】
さらに、データに＜＜Ｃ２＞＞プロパティが付与されている部分を検出し、対象アクタに、対象データに対する所有者のみの権限を付与するように設定する（ステップＳ２０７）。図１８では全てのデータに＜＜Ｃ２＞＞プロパティが付与されているので、全てのデータが所有者のみの権限となる。
【００８６】
このような処理を実施することによって、図２０のような権限テーブルが生成される。これは、ほぼ図１２と同様であるから、これ以上の説明は省略する。
【００８７】
以上の処理を実施すれば、自動的に権限テーブル１１を生成できるようになる。
【００８８】
以上本技術の実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、処理フローについては、処理結果が変わらない限りにおいて、ステップの順番を入れ替えたり、並列に実行するようにしても良い。
【００８９】
さらに、１台のサーバで必要な機能を実現する例を示したが、複数台のサーバで、権限検査部３１５が動作できるような環境を整えれば、複数台のサーバが並列に又は連携して動作するような構成も採用可能である。
【００９０】
なお、サーバやユーザ端末は、コンピュータ装置であって、図２１に示すように、メモリ２５０１とＣＰＵ２５０３とハードディスク・ドライブ（ＨＤＤ）２５０５と表示装置２５０９に接続される表示制御部２５０７とリムーバブル・ディスク２５１１用のドライブ装置２５１３と入力装置２５１５とネットワークに接続するための通信制御部２５１７とがバス２５１９で接続されている。オペレーティング・システム（ＯＳ：Operating System）及び本実施例における処理を実施するためのアプリケーション・プログラムは、ＨＤＤ２５０５に格納されており、ＣＰＵ２５０３により実行される際にはＨＤＤ２５０５からメモリ２５０１に読み出される。必要に応じてＣＰＵ２５０３は、表示制御部２５０７、通信制御部２５１７、ドライブ装置２５１３を制御して、必要な動作を行わせる。また、処理途中のデータについては、メモリ２５０１に格納され、必要があればＨＤＤ２５０５に格納される。本発明の実施例では、上で述べた処理を実施するためのアプリケーション・プログラムはコンピュータ読み取り可能なリムーバブル・ディスク２５１１に格納されて頒布され、ドライブ装置２５１３からＨＤＤ２５０５にインストールされる。インターネットなどのネットワーク及び通信制御部２５１７を経由して、ＨＤＤ２５０５にインストールされる場合もある。このようなコンピュータ装置は、上で述べたＣＰＵ２５０３、メモリ２５０１などのハードウエアとＯＳ及び必要なアプリケーション・プログラムとが有機的に協働することにより、上で述べたような各種機能を実現する。
【００９１】
本実施の形態をまとめると以下のようになる。
【００９２】
本ロールベースアクセス制御方法は、データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されているデータ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は権限データにおいて規定されている機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出するステップと、ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、ユーザのユーザ識別子及びユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、ユーザ識別情報を取得するステップと、検出されたメソッド呼出の対象オブジェクトから、データ項目又は機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得ステップと、メソッド呼出に応じて実行されるメソッドによる処理が、権限データにおいてユーザ識別情報に含まれるロールとクラスタイプ及びクラス識別名とから特定される権限において正当であるか判断する正当性判断ステップと、正当であると判断された場合に、メソッド呼出を対象オブジェクトに出力するステップとを含む。
【００９３】
このような処理を行うことによって、ＯＳでは１つのユーザとして判断されてしまうようなプロセス上の各セッションについて、ＲＢＡＣを実現できる。また、権限データ（実施の形態における権限テーブル）に規定されているデータ項目及び機能について生成されている機能クラス及びデータクラスについてのメソッド呼出を捕捉して、権限データに従っているか判断するだけなので、当該捕捉したメソッド呼出から権限を確認する処理を共通化することができ、開発者が個々のアプリケーションについて実装する手間が省ける。
【００９４】
また、上で述べたオブジェクトデータ取得ステップが、検出されたメソッド呼出の対象オブジェクトがデータ・クラスのオブジェクトであって、対象オブジェクトが当該対象オブジェクトの所有者データを含む場合には、当該所有者データを取得するステップを含むようにしてもよい。そして、上で述べた正当性判断ステップが、権限データにおいてユーザ識別情報に含まれるロールとクラスタイプ及びクラス識別名とから特定される権限において所有者のみ可能な権限が含まれる場合、取得された所有者データが、ユーザ識別情報に含まれるユーザ識別子に一致するか判断するステップを含むようにしてもよい。
【００９５】
これによって、所有者のみ参照できる又は更新できるようなデータ項目について、所有者であるか判断することができるようになる。
【００９６】
さらに、上で述べた正当性判断ステップが、権限データにおいてユーザ識別情報に含まれるロールとクラスタイプ及びクラス識別名とから特定される権限について追加の制限ルールが規定されている場合、当該追加の制限ルールのデータを取得するステップと、追加の制限ルールのデータにおいて確認が必要であり且つ対象オブジェクトに規定されている追加規定データを取得するステップと、追加規定データが追加の制限ルールを満たしているか判断するステップとを含むようにしてもよい。このようにすれば、様々な権限データにカスタマイズルールを規定して、当該カスタマイズルールに従った処理のみが実行されるようになる。
【００９７】
なお、本発明に係る方法をコンピュータに実行させるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブル・ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。なお、処理途中のデータについては、コンピュータのメモリ等の記憶装置に一時保管される。
【００９８】
（付記１）
データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されている前記データ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は前記権限データにおいて規定されている前記機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出するステップと、
ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、前記ユーザのユーザ識別子及び前記ユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、前記メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、前記ユーザ識別情報を取得するステップと、
検出された前記メソッド呼出の対象オブジェクトから、前記データ項目又は前記機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得ステップと、
前記メソッド呼出に応じて実行されるメソッドによる処理が、前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及び前記クラス識別名とから特定される権限において正当であるか判断する正当性判断ステップと、
正当であると判断された場合に、前記メソッド呼出を前記対象オブジェクトに出力するステップと、
を、コンピュータに実行させるためのプログラム。
【００９９】
（付記２）
前記オブジェクトデータ取得ステップが、
検出された前記メソッド呼出の対象オブジェクトが前記データ・クラスのオブジェクトであって、前記対象オブジェクトが当該対象オブジェクトの所有者データを含む場合には、当該所有者データを取得するステップ
を含み、
前記正当性判断ステップが、
前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及びクラス識別名とから特定される権限において所有者のみ可能な権限が含まれる場合、取得された前記所有者データが、前記ユーザ識別情報に含まれるユーザ識別子に一致するか判断するステップ
を含む
付記１記載のプログラム。
【０１００】
（付記３）
前記正当性判断ステップが、
前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及びクラス識別名とから特定される権限について追加の制限ルールが規定されている場合、当該追加の制限ルールのデータを取得するステップと、
前記追加の制限ルールのデータにおいて確認が必要であり且つ前記対象オブジェクトに規定されている追加規定データを取得するステップと、
前記追加規定データが前記追加の制限ルールを満たしているか判断するステップと、
を含む付記１又は２記載のプログラム。
【０１０１】
（付記４）
データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されている前記データ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は前記権限データにおいて規定されている前記機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を検出するステップと、
ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、前記ユーザのユーザ識別子及び前記ユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、前記メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、前記ユーザ識別情報を取得するステップと、
検出された前記メソッド呼出の対象オブジェクトから、前記データ項目又は前記機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得ステップと、
前記メソッド呼出に応じて実行されるメソッドによる処理が、前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及び前記クラス識別名とから特定される権限において正当であるか判断する正当性判断ステップと、
正当であると判断された場合に、前記メソッド呼出を前記対象オブジェクトに出力するステップと、
を含み、コンピュータに実行されるロールベースアクセス制御方法。
【０１０２】
（付記５）
データ項目及び機能の各々についてロール毎に許可された権限を規定した権限データにおいて規定されている前記データ項目毎に生成されたデータ・クラスのオブジェクトの参照メソッド又は更新メソッドに対するメソッド呼出、又は前記権限データにおいて規定されている前記機能毎に生成された機能クラスのオブジェクトのメソッドに対するメソッド呼出を取得する手段と、
ユーザからの要求に応じた、プロセス上の各セッション開始時に生成され且つセッション識別子と、前記ユーザのユーザ識別子及び前記ユーザのロールとを含むユーザ識別情報を含むセッションオブジェクトのうち、前記メソッド呼出に含まれるセッション識別子に対応するセッションオブジェクトから、前記ユーザ識別情報を取得する手段と、
取得された前記メソッド呼出の対象オブジェクトから、前記データ項目又は前記機能のいずれかを表すクラスタイプ及びデータ項目名又は機能名を表すクラス識別名を取得するオブジェクトデータ取得手段と、
前記メソッド呼出に応じて実行されるメソッドによる処理が、前記権限データにおいて前記ユーザ識別情報に含まれる前記ロールと前記クラスタイプ及び前記クラス識別名とから特定される権限において正当であるか判断する正当性判断手段と、
正当であると判断された場合に、前記メソッド呼出を前記対象オブジェクトに出力する手段と、
を有するコンピュータ。
【図面の簡単な説明】
【０１０３】
【図１】本技術の実施の形態における、プログラム作成時の機能ブロック図である。
【図２】第１の実施の形態における権限テーブルの一例を示す図である。
【図３】プログラム作成時の処理フローを示す図である。
【図４】機能クラス生成処理の処理フローを示す図である。
【図５】機能クラスの構造を模式的に示す図である。
【図６】データクラス生成処理の処理フローを示す図である。
【図７】データクラスの構造を模式的に示す図である。
【図８】プログラム構築後のアプリケーションの構造を模式的に示す図である。
【図９】プログラム実行時のシステム構成を示す図である。
【図１０】プログラム実行時の処理フローを示す図である。
【図１１】第１の実施の形態におけるプログラム実行時の処理フローを示す図である。
【図１２】第２の実施の形態における権限テーブルの一例を示す図である。
【図１３Ａ】第２の実施の形態におけるデータクラスの構造の一例を示す図である。
【図１３Ｂ】第２の実施の形態におけるプログラム実行時の処理フローを示す図である。
【図１４】第３の実施の形態における権限テーブルの一例を示す図である。
【図１５】第３の実施の形態における機能クラスの構成について説明するための図である。
【図１６】第３の実施の形態における機能クラスの構成について説明するための図である。
【図１７】第３の実施の形態におけるプログラム実行時の処理フローを示す図である。
【図１８】その他の実施の形態において用いられるユースケース図である。
【図１９】ユースケース図から権限テーブルを生成するための処理の処理フローを示す図である。
【図２０】その他の実施の形態において生成される権限テーブルの一例を示す図である。
【図２１】コンピュータの機能ブロック図である。
【符号の説明】
【０１０４】
１１  権限テーブル    １２  クラス自動生成器    １３  機能クラス格納部
１４  データクラス格納部
１ａ，１ｂ  ユーザ端末    ３  サーバ
３１  ＯＳ
１００  サーバアプリケーション    １１０  セッションオブジェクト生成部
３１１  メソッド呼出捕捉部
３１３  セッションオブジェクト
３１５  権限検査部
３１７  カスタマイズルール
１３５  機能クラスのオブジェクト    １４５  データクラスのオブジェクト
【図１】
2010108170.tif 000003
【図２】
2010108170.tif 000004
【図３】
2010108170.tif 000005
【図４】
2010108170.tif 000006
【図５】
2010108170.tif 000007
【図６】
2010108170.tif 000008
【図７】
2010108170.tif 000009
【図８】
2010108170.tif 000010
【図９】
2010108170.tif 000011
【図１０】
2010108170.tif 000012
【図１１】
2010108170.tif 000013
【図１２】
2010108170.tif 000014
【図１３Ａ】
2010108170.tif 000015
【図１３Ｂ】
2010108170.tif 000016
【図１４】
2010108170.tif 000017
【図１５】
2010108170.tif 000018
【図１６】
2010108170.tif 000019
【図１７】
2010108170.tif 000020
【図１８】
2010108170.tif 000021
【図１９】
2010108170.tif 000022
【図２０】
2010108170.tif 000023
【図２１】
2010108170.tif 000024