ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法、システム、およびプログラム記憶装置
【課題】 ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法、システム、およびプログラム記憶装置を提供することにある。
【解決手段】 この方法は、データ・プロセッサ上で実行されたＸＭＬフォーマットを有するアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、認可ポリシーを変更するステップと、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップと、グループ化パラメータを使用してアプリケーション・オブジェクト・グループを指定するステップとをさらに有する。
【解決手段】 この方法は、データ・プロセッサ上で実行されたＸＭＬフォーマットを有するアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、認可ポリシーを変更するステップと、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップと、グループ化パラメータを使用してアプリケーション・オブジェクト・グループを指定するステップとをさらに有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の諸実施形態は、一般に、ソフトウェア・アプリケーション開発に関し、詳細には、Ｊａｖａ（Ｒ）ベースのセキュリティおよび認可ソフトウェア・アプリケーション開発システムおよび方法に関する。
【背景技術】
【０００２】
セキュリティおよび認可は、ソフトウェア・システムの開発、配置、および機能において非常に重要な役割を果たしている。米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能なＪａｖａ（Ｒ）は、コンポーネントベースのソフトウェアおよびシステムのための最も普及しているプラットフォームである。その上、Ｊａｖａ（Ｒ）セキュリティは、ｅコマース・エンタープライズ・システムにおいて重要な役割を果たしている。セキュリティ機能は、典型的には、臨時にアプリケーション内に組み込まれるか、または米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能であり、コンテナ管理の認証および認可を使用するアプリケーションであるエンタープライズＪ２ＥＥ（Ｒ）（Ｊａｖａ（Ｒ）２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）と統合される。このような状況には、いくつかの理由がある。第一に、セキュリティはアプリケーションのほぼすべてのコンポーネントによって処理されなければならないが、ソフトウェア開発におけるその統合は集中化されていない。第二に、きめの粗い（granular）セキュリティを開発するための標準的で使いやすいプロセスが欠如している。Ｊ２ＥＥ（Ｒ）システムでは、コンテナは、多くの状況には十分ではない可能性のあるメソッドレベルのセキュリティと役割ベースのアクセス制御を提供する。全体的に、低レベルのセキュリティ開発により、セキュリティ実装が厳正で、アプリケーションに緊密に結合されたものになる。
【０００３】
Ｊａｖａ（Ｒ）認証・承認サービス（ＪＡＡＳ：JavaAuthentication and Authorization Service）は、ユーザに関するアクセス制御を認証し執行するためのサービスを使用可能にするＪａｖａ（Ｒ）パッケージである。換言すれば、ＪＡＡＳは、（１）Ｊａｖａ（Ｒ）コードがアプリケーション、アプレット、Ｂｅａｎ、またはサーブレットとして実行されているかどうかにかかわらず、現在、誰がそのコードを実行しているかを確実かつ安全に判断するためのユーザの認証のため、ならびに（２）Ｊａｖａ（Ｒ）コードがアプリケーション、アプレット、Ｂｅａｎ、またはサーブレットとして実行されているかどうかにかかわらず、認証済みユーザがリソース（Ｊａｖａ（Ｒ）コードまたはＪａｖａ（Ｒ）コードによってアクセスされる何らかのオブジェクト／エンティティにすることができる）にアクセスできるかどうかを判断するためのユーザの認可のためという２つの目的に使用できる１組のＪａｖａ（Ｒ）アプリケーション・プログラム・インターフェース（ＡＰＩ：Application Program Interface）である。典型的には、ＪＡＡＳ認証は、プラグ可能なやり方で実行される。これにより、Ｊａｖａ（Ｒ）アプリケーションは、基礎となる認証技術から独立した状態で存続することができる。その上、アプリケーション自体の変更を必要とせずに、新しい技術または更新された技術をプラグ接続することができる。
【０００４】
Ｊａｖａ（Ｒ）では、バイトコード・ベリファイヤ（byte-code verifier）、クラス・ローダ（class loader）、およびセキュリティ・マネージャ（security manager）という３タイプの防衛メカニズムを使用する。Ｊａｖａ（Ｒ）バージョン１．０では、アプレットが「サンドボックス（sandbox）」内で動作し、それにより、アプレットが実行されるマシンに影響を及ぼすか、またはそこから任意の機密情報を入手するために、アプレットの能力を制限する。このため、ローカルにアクセスできるものは非常に少ない。Ｊａｖａ（Ｒ）のその後のバージョンでは、それを実行しているマシンが署名情報に基づいてそのように実行することを許可する場合、アプレットはサンドボックスを脱出することができる。柔軟できめ細かいアクセス制御をサポートするために、Ｊａｖａ（Ｒ）バージョン１．２は、ポリシー・ベースのセキュリティ・アーキテクチャを提供する。ポリシーは、様々な位置の様々な署名者によるコードに関する１組のパーミッション（permission）によって定義される。パーミッションにより、特定のリソースに関する特定のアクションへのアクセスが可能になる。通常、リソース名およびその関連アクションは、ポリシー・ファイルに列挙される。図１は、Ｊａｖａ（Ｒ）の典型的なポリシー・ファイルを例示している。
【０００５】
Ｊａｖａ（Ｒ）バージョン２では、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒによって以前提供された２つの機能、すなわち、セキュリティ・ポリシーの確立とセキュリティ・ポリシーの実施が分離されている。ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｏｌｉｃｙ抽象クラスはセキュリティ・ポリシーを確立するために使用され、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒはセキュリティ執行者（security enforcer）として使用される。後方互換性のために、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスは依然として存在するが、これはその決定のためにＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを参照する。ｊａｖａ．ｐｏｌｉｃｙでは、パーミッションはコードソースに関連付けられる。このため、それは、ユーザまたは役割ベースのパーミッションを備えていない。図２は、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを使用するＪａｖａ（Ｒ）メソッドを保護するための典型的なコードを例示している。図２に例示されている例は、リソースにアクセスする前にＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを呼び出すことにより、どのようにリソースが保護されるかを示している。ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、アプリケーションの現行認可ポリシーによって要求された許可をチェックする。ポリシー・ファイルに定義されたパーミッションが要求されたパーミッションを暗示する場合、メソッドの「ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ」コマンドが単純に戻り、さもなければ、ＡｃｃｅｓｓＣｏｎｔｒｏｌＥｘｃｅｐｔｉｏｎが開始される。
【０００６】
前述の通り、ＪＡＡＳは、ユーザに関するアクセス制御を認証し執行するためのサービスを使用可能にする１組のＡＰＩである。ＪＡＡＳは、現在、誰がＪａｖａ（Ｒ）コードを実行しているか、ならびにそのように実行することを許可されているかどうかを確実かつ安全に判断する。その上、ＪＡＡＳは、標準的なプラグ可能認証モジュール（ＰＡＭ：Pluggable Authentication Module）フレームワークのＪａｖａ（Ｒ）技術バージョンを実装するものである。これにより、Ｊａｖａ（Ｒ）アプリケーションは、基礎となる認証メカニズムから独立した状態で存続することができる。
【０００７】
ＪＡＡＳは、２つの主要コンポーネント、すなわち、認証（authentication）および認可（authorization）を含む。ＪＡＡＳは、Ｊａｖａ（Ｒ）バージョン２のセキュリティ・モデルにサブジェクト・ベースのポリシーを追加する。パーミッションは、ＣｏｄｅＳｏｕｒｃｅに基づくだけでなく、コードを実行しているユーザにも基づいて付与される。この場合、ユーザは先に認証される。ＪＡＡＳ配布は、ユーザからユーザＩＤおよびパスワードを取得するための様々なＬｏｇｉｎＭｏｄｕｌｅ実装を含む。ＬｏｇｉｎＣｏｎｔｅｘｔは、認証のためにどのＬｏｇｉｎＭｏｄｕｌｅを使用すべきかを判断するためにログイン構成ファイルを使用する。Ｓｕｂｊｅｃｔクラスは、認証済みユーザの資格情報をカプセル化するために使用される。サブジェクトは、プリンシパル（principal）と呼ばれる複数のＩＤを有することができる。ＪＡＡＳポリシー・ファイル内の各ｇｒａｎｔ文はプリンシパルに関連付けられている。サブジェクトに関連する各プリンシパルごとに、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、ＰｏｌｉｃｙＦｉｌｅからパーミッションを入手し、任意のパーミッションが要求されたパーミッションを暗示するかどうかをチェックする。さもなければ、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、ＡｃｃｅｓｓＣｏｎｔｒｏｌＥｘｃｅｐｔｉｏｎを開始する。図３は、ＪＡＡＳ内のプリンシパル・ベースの認可に関する典型的なポリシーを例示している。
【０００８】
Ｊ２ＥＥ（Ｒ）アーキテクチャでは、コンテナは、それがホストとして処理するコンポーネントとその呼び出し側との間の認可境界として機能する。コンテナは、呼び出し側コードのユーザのＩＤを確立する。呼び出されたコンポーネント、ＥＪＢ（米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能なＥｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ（Ｒ））、またはＷｅｂコンポーネントへのアクセスは、呼び出し側のセキュリティ属性を、呼び出されたコンポーネントにアクセスするために必要なものと比較することによって決定される。宣言認可（declarative authorization）では、デプロイヤ（deployer）は、Ｊ２ＥＥ（Ｒ）アプリケーションに関するコンテナ執行のアクセス制御ルールを確立する。デプロイヤは、典型的にはアプリケーション・アセンブラによって供給されたアプリケーション・パーミッション・モデルをランタイム環境に特有のメカニズムにマッピングする。配置記述子（deployment descriptor）は、様々なコンポーネントに関するセキュリティ役割とそれに関連するアクセス権を定義する。デプロイヤは、ランタイム環境内のユーザのアクセス権を確立するために、特定の呼び出し側にセキュリティ役割を割り当てる。たとえば、デプロイヤは、セキュリティ役割を動作環境内のプリンシパルＩＤのリストにマッピングすることができる。その場合、これらのＩＤの１つで認証された呼び出し側には、役割によって表される特権が割り当てられる。Ｊ２ＥＥ（Ｒ）コンテナは、コンポーネントへのディスパッチング・メソッド呼び出しの前にアクセス制御決定を行う。したがって、宣言アクセス制御は、メソッドの細分性によって割り当てることができる。
【０００９】
Ｊ２ＥＥ（Ｒ）コンテナは、これらのアクセス決定におけるコンポーネントのロジックまたは状態を考慮に入れない。これを実行するために、コード開発者がプログラムによる認可（programmatic authorization）を実行する必要がある。コンポーネントは、きめ細かいアクセス制御を実行するために、ＥＪＢＣｏｎｔｅｘｔ．ｉｓＣａｌｌｅｒＩｎＲｏｌｅ（ＥＪＢコンポーネントの場合）およびＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔ．ｉｓＵｓｅｒＩｎＲｏｌｅ（Ｗｅｂコンポーネントの場合）という２つのメソッドを使用することができる。コンポーネントは、これらのメソッドを使用して、呼び出しのパラメータ、コンポーネントの内部状態、またはランタイム・パラメータなどのその他の要因に基づいて、コンポーネントによって選択された特権が呼び出し側に付与されているかどうかを判断する。しかし、宣言認可とプログラマチック認可との間にはトレードオフが存在する。宣言認可はデプロイヤによって構成された外部アクセス制御ポリシーであり、プログラマチック認可はコンポーネント開発者によってアプリケーションに埋め込まれた内部ポリシーによるものである。内部ポリシーはよりきめ細かいものであり、外部ポリシーはより柔軟なものである。その上、外部ポリシーは透過性であり、内部ポリシーはアプリケーションに埋め込まれる。たとえば、「従業員は自分自身の給与情報のみにアクセスできる」という認可ポリシーを提供するためには、必要であれば、将来変更できないプログラムによる認可が必要である。
【００１０】
その上、ＪＡＡＳは、Ｊａｖａ（Ｒ）の既存のセキュリティ・モデルの上に構築され、それはＣｏｄｅＳｏｕｒｃｅベースのものであり、プレーンテキスト・フォーマットのポリシー・ファイル実装である。ＪＡＡＳは、特定のコンポーネントによってアクセスされるクラスに基づく認可を実装する。しかし、これは、エンタープライズ・アプリケーションには十分ではない可能性があり、それにより、ＪＡＡＳとともに、ＬＤＡＰ（軽量ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol））などのカスタム・セキュリティ・リポジトリを使用する必要がある場合もある。さらに、企業間（business-to-business）の電子商取引における価格設定契約は、他の契約とは異なるアクセス制御ポリシーを有する場合もある。セルフサービス・オークション・アプリケーションに関する指定は、「登録済みユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件を有する可能性もある。したがって、多くのＪａｖａ（Ｒ）アプリケーションは、その認可要件を満足するためにＪＡＡＳを拡張する必要がある。ＪＡＡＳの諸機能はプラグ可能であるので、ＪＡＡＳのデフォルト動作を変更するために様々な認証および認可サブモジュールについて自分専用の実装例を作成することができる。上記の例に例示されている認可要件の場合、以下の１つまたは複数のデフォルト実装を変更する必要がある場合もある。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｅｒｍｉｓｓｉｏｎ： 呼び出されたＣｏｄｅＳｏｕｒｃｅについてアクションを実行するための権限を呼び出し側が有するかどうかを判断するために、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒ．ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ（Ｐｅｒｍｉｓｓｉｏｎ ｐｅｒｍ）が呼び出される。パーミッション・オブジェクトｐｅｒｍは、リソースへの必要なアクセスを表している。パーミッション・オブジェクトは、パーミッションの名前（アクセスが必要なリソースを示す可能性がある）、リソースがアクセスされるアクションなどの項目を指定することができる。パーミッション・クラスは、付与されたパーミッションが要求されたパーミッションを暗示するかどうかを判断するために、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒによって呼び出される暗黙のメソッドを実装する。クラス・インスタンス・レベル認可を実装するために、そのフィールドの１つとしてオブジェクト・インスタンスを有するパーミッションの新しい実装を有する必要がある。そのオブジェクトは、認可を決定するために暗黙のメソッドで使用することができる。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ： この抽象クラスは、パーミッション・オブジェクトの集合を表すために使用される。このクラスは、付与されたパーミッションを保管し、それを要求されたパーミッションと比較して、付与されたパーミッションのいずれかが要求されたパーミッションを暗示するかどうかを判断する所望のやり方を備えるために実装することができる。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｏｌｉｃｙ： これは、Ｊａｖａ（Ｒ）アプリケーション環境においてセキュリティ・ポリシーを保管するための抽象クラスである。ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、ＣｏｄｅＳｏｕｒｃｅ上の認証済みサブジェクトに関するパーミッションを入手するためにポリシー実装に連絡する。ポリシー・オブジェクトは、そのポリシー指定を調べ、許可されるパーミッションを列挙する適切なＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎオブジェクトを返す。デフォルトでは、ｓｕｎ．ｓｅｃｕｒｉｔｙ．ｐｒｏｖｉｄｅｒ．ＰｏｌｉｃｙＦｉｌｅ実装がポリシー実装に使用される。異なる実装を有することにより、ポリシーが作成される方法（たとえば、ＬＤＡＰまたはソフトウェア・アプリケーション）または認可が依存する追加のパラメータを変更することができる。
・ｊａｖａｘ．ｓｅｃｕｒｉｔｙ．ａｕｔｈ．ｓｐｉ．ＬｏｇｉｎＭｏｄｕｌｅ： ＬｏｇｉｎＭｏｄｕｌｅは、認証プロバイダによって実装されたインターフェースを記述する。これは、デフォルトでは何らかのユーザ対話を実行するコールバックからユーザ名およびパスワード（複数も可）を検索する。ＬｏｇｉｎＭｏｄｕｌｅは、認証を何らかの外部アダプタに委任するよう、拡張することができる。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｒｉｎｃｉｐａｌ： Ｐｒｉｎｃｉｐａｌインターフェースは、個人、組織、グループ、またはログインＩＤなどのエンティティを表すために使用される抽象概念を表す。Ｇｒｏｕｐ、ＫｅｒｂｅｒｏｓＰｒｉｎｃｉｐａｌなどは、Ｐｒｉｎｃｉｐａｌの周知の実装例である。Ｐｒｉｎｃｉｐａｌを拡張することにより、認可に使用すべきカスタム・プロパティを追加することができる。
【００１１】
しかし、ＪＡＡＳの制限の１つは、それがクラス・インスタンス・レベル認可をサポートしないことであり、すなわち、ＪＡＡＳ内の認可は、クラスの特定のインスタンスを基礎として実行されるのではなく、クラス名を基礎として実行される。たとえば、Ｗｅｂベースのセルフサービス・オークション・アプリケーションに関する指定は、「登録済み（認証済み）ユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件を有する可能性がある。これは、どのユーザもオークション・クラス・インスタンスを作成するために作成されたコードを実行することができるが、そのインスタンスを所有するユーザのみが、それを変更するために設計されたコードを実行できることを意味する。通常、オークション・インスタンスを作成したユーザは所有者になる。これにより、同じ役割の人は、その属性または過去に実行したアクションに基づいて異なるアクセス権を有する可能性があることが暗示される。残念ながら、このタイプの認可は、ＪＡＡＳを使用してサポートすることができない。
【００１２】
ＪＡＡＳ認可は、どのアクセス権が実行中のコードに付与されるかを指定するためにセキュリティ・ポリシーを使用する既存のＪａｖａ（Ｒ）セキュリティ・アーキテクチャを拡張する。Ｊａｖａ（Ｒ）バージョン２のプラットフォームで提供される、このセキュリティ・アーキテクチャはコード中心である。すなわち、パーミッションはコード特性、すなわち、コードがどこから来るか、それがデジタル署名されるかどうか、そうである場合に、誰によって署名されるかに基づいて付与される。ＪＡＡＳをＪａｖａ（Ｒ）２のＳＤＫ（ソフトウェア開発キット（Software Development Kit））に統合することにより、ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｏｌｉｃｙ ＡＰＩはプリンシパルベースの照会を処理し、デフォルトのポリシー実装はプリンシパルベースの付与項目をサポートする。したがって、アクセス制御は、どのコードが実行されているか、ならびに誰がコードを実行しているかに基づくものになる可能性がある。
【００１３】
ＪＡＡＳは、インスタンス・レベルＪＡＡＳをサポートするためのメカニズムを提供する。これは、ＪＡＡＳによって使用されるクラスのいくつかを拡張することによって実施される。しかし、この手法の主な欠点は、それが拡張可能ではなく、異なるドメインで異なる種類の認可を提供する場合に新しい認可クラスの作成と相当な量の手直しを必要とすることである。インスタンス・レベル認可をサポートするためのもう１つのオプションは、アプリケーションの一部としてコーディングされるカスタム認可コードを使用することである。一般に、これは、認可技法をサポートするために最も広く使用される方法であり、その主要な欠点は、それが標準に基づくものではなく、異なるアプリケーションで適用することをより難しくしていることである。さらに、このコードはアプリケーションの一部であるので保守が難しく、それが非汎用であるので一般に異なるドメインで再利用することができない。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
したがって、従来の手法の欠点および制限のために、新しいコードを必要とせずに異なるドメインに適用できる、より普遍的に適用可能なＪＡＡＳベースの認可ソリューションの必要性が残っている。新しい認可要件に関する新しいコードを作成すると、配置時に認可設定を変更することが難しくなる。したがって、プログラマチック認可の高細分性とともに宣言認可の柔軟性が必要である。
【課題を解決するための手段】
【００１５】
上記を考慮すると、本発明の一実施形態は、ソフトウェア・オブジェクトおよびアプリケーションのいずれかによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を提供し、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクトをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクトにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。生成ステップにおいて、アプリケーション・オブジェクト記述ドキュメントは、拡張可能マークアップ言語（ＸＭＬ：eXtensible Markup Language）フォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、認可ポリシーを変更するステップとをさらに有する。さらに、この方法は、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか（およびこれらのメソッドおよびフィールド・パラメータに関する定義制約）、すべてのアプリケーション・オブジェクト・グループ間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクト・グループを指定するステップをさらに有する。その上、この方法は、同じ認可ポリシー分類器（classifier）を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００１６】
本発明の他の実施形態は、ソフトウェア・アプリケーションへのアクセスを制御する方法を提供し、この方法は、グループ化パラメータによりソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップと、アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップと、グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップと、ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関するユーザ・プロファイルと認可ポリシーとを突き合わせるステップとを有し、グループ化ステップにおいて、ソフトウェア・アプリケーションがアプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、アプリケーション・オブジェクト記述ドキュメントがＸＭＬフォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定およびグループ化制約を変更することにより、認可ポリシーを変更するステップとをさらに有する。グループ化ステップにおいて、このグループ化パラメータは、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係、またはソフトウェア・アプリケーション／オブジェクトによって表されるリソース、データ、またはコードを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクトを指定するステップを有する。この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００１７】
本発明の他の態様は、ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立するためのシステムを提供し、このシステムは、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するための手段と、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するための手段と、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するための手段と、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するための手段とを有する。
【００１８】
本発明の他の実施形態は、ソフトウェア・オブジェクトへのアクセスを制御するためのシステムを提供し、このシステムは、少なくとも１つのアプリケーション・オブジェクト・グループを有するアプリケーション・オブジェクト記述ドキュメントと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するように適合された認可ポリシー分類器（classifier）と、ソフトウェア・オブジェクトの配置時に認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてアクセス制御パラメータを確立するように適合されたアクセス・コントローラとを有し、アプリケーション・オブジェクト記述ドキュメントがＸＭＬフォーマットを有し、認可ポリシーが環境変数を有する。このシステムは、環境変数の宣言指定およびグループ化ルールを変更することにより、認可ポリシーを変更するように適合されたジェネレータ・ルーチンをさらに有する。このシステムによれば、アプリケーション・オブジェクト・グループは、ユーザ選択のアプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して指定される。その上、認可ポリシー分類器は、多様なクラスの認可ポリシーを実装するように適合される。
【００１９】
さらに、本発明の他の態様は、ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を実行するためにコンピュータによって実行可能な複数命令からなるプログラムを具体的に実施する、コンピュータによって読み取り可能なプログラム記憶装置を提供し、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。
【００２０】
本発明の諸実施形態により提供される認可技法は、新しいコードを作成せずに認可要件を満たす方法を提供し、新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。さらに、本発明の諸実施形態は、多様な認可要件をＸＭＬフォーマットで表し、オブジェクト制約ロジックを使用して認可のためのオブジェクト・グループを構文解析して生成し、認可パラメータとして環境変数を追加し、認証済みプリンシパル間の関係を定義し、同じ認可ポリシー・プロバイダを使用して、多様なクラスの認可ポリシーを実装し、配置時にアクションをグループ化するための技法を提供する。
【００２１】
本発明の諸実施形態の上記その他の諸態様は、以下の説明および添付図面に併せて考慮したときに、より十分に認識され理解されるであろう。しかし、以下の説明は、本発明の好ましい諸実施形態およびその数多くの特定の詳細を示しており、制限としてではなく、例示として示されていることを理解されたい。
【００２２】
本発明の諸実施形態は、図面に関して以下の詳細な説明からより十分に理解されるであろう。
【発明を実施するための最良の形態】
【００２３】
添付図面に例示され、以下の説明に詳述されている非制限的諸実施形態に関して、本発明の諸実施形態ならびにその様々な特徴および有利な詳細をより完全に説明する。図面に例示されている特徴は必ずしも一定の縮尺で描かれていないことに留意されたい。本発明の諸実施形態を不必要に不明確にしないために、周知のコンポーネントおよび処理技法の説明は省略されている。本明細書で使用される例は、単に本発明の諸実施形態を実施できる方法の理解を容易にするためのものであり、さらに当業者が本発明の諸実施形態を実施できるようにするためのものである。したがって、この例は、本発明の諸実施形態の範囲を制限するものと解釈してはならない。
【００２４】
前述の通り、認可セットアップに対する大幅な変更を必要とせずに異なるドメインに適用できる、より普遍的に適用可能なＪａｖａ（Ｒ）ベースのソフトウェア・アプリケーション開発技法の必要性が残っている。本発明の諸実施形態は、ＪＡＡＳ標準に基づいてＪａｖａ（Ｒ）アプリケーションに対し汎用性で低レベルで拡張可能なセキュリティを提供することにより、この必要性に対処する。次に図面を参照し、詳細には図４〜図１０を参照すると、本発明の好ましい諸実施形態が図示されている。
【００２５】
上述の通り、ＪＡＡＳは、様々な認証および認可目標を達成するために様々な方法で拡張することができる。しかし、様々な拡張について、様々なＪＡＡＳインターフェースおよびクラスをそれぞれ実装または拡張するためのコードを作成する必要がある場合がある。このため、アプリケーションの配置時にセキュリティ設定を変更することが難しくなる。したがって、本発明の諸実施形態によって提供される汎用認可技法は、プログラマチック認可の高細分性を保持しながら宣言認可を使用することにより、この柔軟性を達成する。
【００２６】
したがって、本発明の諸実施形態によって提供される認可技法は、宣言指定を使用するプログラマチック認可の諸機能を提供する。具体的には、本発明の諸実施形態は、プログラマチックではなく宣言的に認可要件を満たすことができるようにＪＡＡＳを拡張する。認証および認可を使用して保護する必要がある各メソッドは、そのメソッドが属すクラス、そのメソッドが実行する必要があるアクション、およびそのメソッドが呼び出されるオブジェクトという少なくとも３つのパラメータを有するＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎオブジェクトのコンストラクタへの呼び出しから始まる。図４は、上述の通り、本発明の一態様によりＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎを使用する保護メソッドのための疑似コードを例示している。
【００２７】
図５に例示されている通り、認可ポリシーはＸＭＬフォーマットで表現することができる。たとえば、図５に図示されている通り、「登録済みユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件に関する認可ポリシーが作成される。同様に、異なる価格設定契約について異なる認可ポリシーを備えて、パーミッションは、｛ｉｄｎａｍｅ＝“ｇｅｔＣｏｎｔｒａｃｔＩＤ”， ｉｄｔｙｐｅ＝“ｍｅｔｈｏｄ”， ｉｄｖａｌｕｅ＝“ｉｂｍ−ｓｕｎ”｝パラメータに基づくものである。
【００２８】
汎用認可の場合、ＪＤＫは、適正な認可ポリシー・プロバイダのために構成される。これは、Ｊａｖａ＿ｈｏｍｅ／ｊｒｅ／ｌｉｂ／ｓｅｃｕｒｉｔｙディレクトリのＪａｖａ．ｓｅｃｕｒｉｔｙファイル内のａｕｔｈ．ｐｏｌｉｃｙ．ｐｒｏｖｉｄｅｒを変更／追加することによって実施され、Ｊａｖａ＿ｈｏｍｅはＪａｖａ（Ｒ）がシステム内にインストールされるパスである。汎用認可は多種多様な認可ポリシーを包含するので、それぞれがそれ専用の認可要件を有するいくつかのアプリケーションについて１つの認可ポリシー・プロバイダしか存在できないという制限がある場合でも、各アプリケーションごとに別々のコードを作成する必要なしに同じマシン上で実行することができる。
【００２９】
図６は、ソフトウェア・オブジェクト／アプリケーションによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を例示しており、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップ（１０１）と、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップ（１０３）と、ユーザ選択のアプリケーション・オブジェクトをシステム２００のアクセス・コントローラ２０８（図９に図示されている）に送信するステップ（１０５）と、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップ（１０７）とを有する。生成ステップ（１０１）において、アプリケーション・オブジェクト記述ドキュメントは、ＸＭＬフォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更することにより、認可ポリシーを変更するステップとをさらに有する。さらに、この方法は、選択されたアプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト・グループ間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクト・グループを指定するステップをさらに有する。その上、この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００３０】
本発明の他の実施形態は図７に例示されており、同図は、ソフトウェア・オブジェクト／アプリケーションによって表されるリソース、データ、またはコードへのアクセスを制御する方法を例示し、この方法は、オブジェクト・メソッド呼び出し結果、オブジェクト・フィールド値、および環境変数のうちの１つまたは複数を有するグループ化パラメータによりソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップ（１１１）と、アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップ（１１３）と、グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップ（１１５）と、ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関するユーザ・プロファイルと認可ポリシーとを突き合わせるステップ（１１７）とを有し、グループ化ステップ（１１１）において、ソフトウェア・アプリケーションはアプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、アプリケーション・オブジェクト記述ドキュメントはＸＭＬフォーマットを有する。
【００３１】
さらに、グループ化ステップ（１１１）において、このグループ化パラメータは、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係、またはユーザ選択のソフトウェア・オブジェクトを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクトを指定するステップを有する。図８に図示されている通り、この方法は、認可ポリシーに関する環境変数を指定するステップ（１１９）と、環境変数の宣言指定を変更することにより、認可ポリシーを変更するステップ（１２１）とをさらに有する。この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００３２】
認可ポリシーを作成する方法によれば、本発明の諸実施形態により、ポリシーがこれらの変数に依存することができるように、何らかのセキュリティ関連変数および環境変数へのアクセスが可能になる。これにより、「平日にはソフトウェア・アプリケーションへのアクセスを許可し、週末には禁止する」などのポリシーを有することが可能になる。
【００３３】
図９は、ソフトウェア・アプリケーションへのアクセスを制御するためのシステム２００を例示し、このシステム２００は、少なくとも１つのアプリケーション・オブジェクト・グループ２０４を有するアプリケーション・オブジェクト記述ドキュメント２０２と、各アプリケーション・オブジェクト・グループ２０４ごとに認可ポリシーを指定するように適合された認可ポリシー分類器２０６と、ソフトウェア・アプリケーションの配置時に認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループ２０４にアクセスしようと試みるユーザ２１０についてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するように適合されたアクセス・コントローラ２０８とを有し、アプリケーション・オブジェクト記述ドキュメント２０２がＸＭＬフォーマットを有し、認可ポリシーが環境変数を有する。
【００３４】
このシステムは、環境変数の宣言指定を変更することにより、認可ポリシーを変更するように適合されたジェネレータ・ルーチン２１２をさらに有する。このシステム２００によれば、アプリケーション・オブジェクト・グループ２０４は、アプリケーション・オブジェクト・グループ２０４に関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト・グループ２０４間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメント２０２を少なくとも１つのアプリケーション・オブジェクト・グループ２０４に構文解析するための所定のグループ化アクションを使用して指定される。その上、認可ポリシー分類器２０６は、多様なクラスの認可ポリシーを実装するように適合される。
【００３５】
本発明の諸実施形態は、オブジェクト制約ロジック（ＸＭＬファイルに作成される）を構文解析し、認可のためのオブジェクト・グループを生成するための技法を提供する。従来、ＪＡＡＳでは、認可ポリシーはクラス（コード）レベルで作成される。逆に、本発明の諸実施形態によれば、認可ポリシーはオブジェクト・グループの細分性で作成される。オブジェクト・グループは、当該オブジェクトのメソッド／フィールドを使用して表される。たとえば、「契約」というクラスが存在すると想定すると、ＪＡＡＳでは、すべての契約が同じ認可プロパティを有することになり、本発明の諸実施形態によって提供される汎用認可では、ユーザは「サン（Ｒ）」（サン（Ｒ）は米国カリフォルニア州サンタクララのサン・マイクロシステムズ社の登録商標である）との契約を更新できる可能性があるが、「マイクロソフト（Ｒ）」（マイクロソフト（Ｒ）は米国ワシントン州レドモンドのマイクロソフト社の登録商標である）に関する契約を更新できない可能性がある。ＪＡＡＳでは、アプリケーション・オブジェクトに関する認可は、そのアプリケーション・オブジェクトの特性に依存しない。このため、すべてのアプリケーション・オブジェクトは同じ認可ルールを有する。これを回避するために、従来の手法では、典型的にはカスタム認可が実行される。逆に、本発明の諸実施形態は、個人がＪＡＡＳを使用してインスタンスレベルの認可（すなわち、データ・オブジェクトの特性に依存する認可）を実行できるようにする技法を提供する。
【００３６】
本発明によって提供される方法は、認証済みプリンシパル間の関係を定義する。従来、ＪＡＡＳでは、ユーザが認証されると、そのユーザは「サブジェクト」という型のオブジェクトによって表される。各サブジェクトは、それに関連する複数のプリンシパルを有することができる。これらのプリンシパルは、その個人が有することができる種々のＩＤを表す。このため、ある個人は、自分の名前（１つのプリンシパルである）または自分の社会保障番号（もう１つのプリンシパルである）によって明確に識別することができる。しかし、本発明の諸実施形態によって提供されるＸＭＬベースの表現を使用して、「ユーザ（認証済みプリンシパル）がオブジェクト（このオブジェクトはリーブ・アプリケーション（leave application）に関するものである可能性がある）の所有者のマネージャである場合、ユーザは承認メソッドを呼び出すことができる」などのポリシーを定義することができる。この場合も、本発明の諸実施形態は個人がＪＡＡＳを使用してインスタンスレベルの認可（すなわち、データ・オブジェクトの特性に依存する認可）を実行できるようにする技法を提供するので、これは有利である。さらに、これは宣言方式で実行され、プログラマチック認可より柔軟なものである。その上、このセットアップを使用して、認可のためにサブジェクト間の動的関係を使用することができる。この例では、ポリシーは認証済みプリンシパル間の関係（マネージャ）に関して定義される。
【００３７】
次に、本発明の諸実施形態は、同じ認可ポリシー・プロバイダを使用して多様なクラスの認可ポリシーを実装できる方法を提供する。認可プロバイダは、ｊａｖａ＿ｈｏｍｅ／ｊｒｅ／ｌｉｂ／ｓｅｃｕｒｉｔｙのｊａｖａ．ｓｅｃｕｒｉｔｙファイルに構成される。Ｊａｖａ（Ｒ）仮想マシン（ＪＶＭ：Java Virtual Machine）の場合、これは、ｊａｖａ．ｓｅｃｕｒｉｔｙファイルのａｕｔｈ．ｐｏｌｉｃｙ．ｐｒｏｖｉｄｅｒというプロパティを変更することによって構成される。汎用認可は多種多様な認可ポリシーを包含するので、１つの認可ポリシー・プロバイダしか存在できないという制限がある場合でも、それぞれがそれ専用の認可要件を有するいくつかのアプリケーションが同じＪＶＭ上で実行することができる。本発明の諸実施形態は単一のＸＭＬ認可ファイルを有するので、このファイルは、異なるアプリケーションについて異なる認可ルールを有することができる。各認可ルールは、そのアプリケーションに特有のアプリケーション・オブジェクトに関して定義されることになる。その上、認可インフラストラクチャは、単一の認可ファイルを使用することになる。このため、同じ認可ポリシー・プロバイダを使用して、多様なクラスの認可ポリシーを実装することができる。
【００３８】
本発明の諸実施形態は、配置時にアクションをグループ化するための方法をさらに提供する。異なるアクション・グループについて異なる認可要件を提供するように、アクションをグループ化することができる。配置時に、たとえば、「読み取り」アクションおよび「検索」アクションに同じ認可が使用されることを決定することができる。これは、認可ポリシーが認可ＸＭＬファイルに保管されたときに実施される。配置時に、単にＸＭＬを変更することにより、上述のアクションのグループ化を実施することができる。
【００３９】
次に、本発明の諸実施形態は、新しいコードを作成する必要なしに認可要件を満たすための方法を提供する。新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。これは、単にＸＭＬを変更することにより、上記の通り、実施される。このため、本発明の諸実施形態は新しいポリシーを提供し、これはコードに対する変更を必要としない。認可要件は、それをアプリケーションと統合するのではなくＸＭＬで表現されるので、（コード変更ではなく）単にＸＭＬを変更することにより、認可設定を変更することができる。本発明の諸実施形態によって提供されるＸＭＬベースのポリシー・ファイルでは、ｇｅｔＯｗｎｅｒ、ｇｅｔＭａｎａｇｅｒなどの特定の「Ｊａｖａ（Ｒ）Ｂｅａｎ様」メソッドの戻り値を使用して表された特定の特性を有する場合、ユーザ・プリンシパルは、特定のＪａｖａ（Ｒ）オブジェクトへのアクセスを許可される。
【００４０】
本発明の諸実施形態は、多様な認可要件をＸＭＬフォーマットで表すための方法をさらに含む。このフォーマットは、Ｊａｖａ（Ｒ）オブジェクト上の何らかのフィールドおよびメソッド呼び出しを使用してオブジェクトを指定すること、関係を使用してプリンシパルを指定すること、およびグループ化アクションを含む。また、本発明の諸実施形態は、時間、日などの環境変数をＸＭＬフォーマットで表し、これらの変数について認可ポリシーを定義する。ＸＭＬフォーマットでオブジェクトを識別するためのいくつかの方法を含むことにより、本発明の諸実施形態は認可設定に関する多種多様なオプションを作成するので、これは特に有利である。これらのオプションとしては、とりわけ、Ｊａｖａ（Ｒ）オブジェクトに関するフィールド値およびメソッド戻り値、プリンシパルおよびそれらの関係、環境変数を含む。したがって、本発明の諸実施形態は、配置時に認可ポリシーを変更することができ、それにより、ＪＡＡＳ標準を利用することができる。換言すれば、プログラマチック認可を利用せずに、インスタンスレベルの認可によってＪＡＡＳの利点が入手される。
【００４１】
その上、本発明の諸実施形態は、それに関する認可がチェックされるオブジェクトまたはアクセス要求を行っているオブジェクトあるいはその両方の引き渡しを可能にするコンストラクタを有する汎用パーミッション・クラスを提供する。従来、ＪＡＡＳでは、アクセス・コントローラを使用してパーミッションをチェックするためにパーミッション・オブジェクトが必要である。逆に、本発明の一実施形態によって提供される方法によれば、それに関するパーミッションが要求されるオブジェクトがアクセス・コントローラ２０８に渡されるＰｅｒｍｉｓｓｉｏｎオブジェクトのパラメータになるように、ＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎを使用してＰｅｒｍｉｓｓｉｏｎクラスが拡張される。したがって、アクセス・コントローラ２０８は、それに渡されるオブジェクトに基づいて、認可を決定することができる。この態様は、それに関する認可決定が行われるアプリケーション・オブジェクトの特定のインスタンスの特性に基づいて認可ルールを提供するために使用される。前述の通り、ＪＡＡＳでは、認可ポリシーはアプリケーション・オブジェクトのインスタンスから独立しており、ポリシーは同じカテゴリのアプリケーション・オブジェクトのすべてのインスタンスについて同じものである。オブジェクト・インスタンスをパラメータとして取る汎用パーミッション・クラスを使用するという上記の技法を使用して、本発明の諸実施形態は、インスタンスレベルの認可を提供することができる。
【００４２】
次に、本発明の諸実施形態は、環境変数の使用を可能にし、リフレクションを使用して動的メソッド呼び出しの表現を可能にし、式、述語論理などの表現を可能にする汎用ポリシー・ファイルを提供する。たとえば、本発明の諸実施形態は、認可要件を作成するためのフォーマットを提供する。このフォーマットは、Ｊａｖａ（Ｒ）オブジェクト上の何らかのフィールドおよびメソッド呼び出しを使用してオブジェクトを指定すること、関係を使用してプリンシパルを指定すること、およびグループ化アクションを含む。また、本発明の諸実施形態は、時間、日などの環境変数をＸＭＬフォーマットで表し、これらの変数について認可ポリシーを定義する。
【００４３】
さらに、本発明の諸実施形態は、汎用ポリシー・ファイルを構文解析し、Ｇｅｎｅｒｉｃ Ｐｏｌｉｃｙ Ｆｉｌｅの構文を理解し、過去のユーザＯｂｊｅｃｔ、ユーザＰｒｉｎｃｉｐａｌ／ユーザＳｕｂｊｅｃｔ、およびユーザ・コードに基づいてＧｅｎｅｒｉｃ Ｐｏｌｉｃｙ ＦｉｌｅからＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎを作成する、Ｐｏｌｉｃｙ Ｆｉｌｅ実装を提供する。これは、新しいタイプのＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスを使用することによって実施され、それにより、異なるタイプのポリシー・ファイル実装が使用される。したがって、本発明の諸実施形態は、Ｇｅｎｅｒｉｃ Ｐｏｌｉｃｙ Ｆｉｌｅの一般フォーマットを理解するが、必ずしもポリシー・ファイルに指定されたオブジェクト制約ロジックを理解するわけではない。しかし、この実装は、ポリシー・ファイルを使用してＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスを作成する。このため、前述のＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスは、ポリシー・ファイルに指定されたオブジェクト制約ロジックを理解する。
【００４４】
したがって、本発明の諸実施形態は、ＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスを利用するが、これは、ポリシー・ファイルを使用し、ポリシー言語の宣言指定を理解し、環境変数の値を取得することができ、式および述語論理を評価し、Ｊａｖａ（Ｒ）リフレクションを使用してランタイム・パラメータ値を入手する。換言すれば、本発明の諸実施形態は、汎用ＸＭＬベースのポリシー・ファイルに作成されたロジックを理解する。
【００４５】
さらに、本発明の諸実施形態は、ＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎの集合を保管し、Ｇｅｎｅｒｉｃ Ｐｏｌｉｃｙ Ｆｉｌｅを理解できるＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎの暗黙のメソッドを呼び出すＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎクラスを提供する。一般に、本発明の諸実施形態は、そのオブジェクトをパラメータの１つとして取るパーミッションの汎用集合を定義し、これはＪＡＡＳ規格に従ってＪＡＡＳ環境で機能する。具体的には、本発明の諸実施形態は、ＸＭＬフォーマットで定義されるアクセス制御または認可を提供するＪａｖａ（Ｒ）ベースのポリシーを提供する。Ｊａｖａ（Ｒ）に関する認可ポリシーの認可パラメータを定義するために、環境変数はＸＭＬフォーマットで宣言的に指定される。ＸＭＬはアプリケーションから独立しており、宣言変数の使用は、クラス、メソッド、およびオブジェクトというＪａｖａ（Ｒ）パラメータをＸＭＬで定義することによって汎用認可を可能にする。いくつかの異なるポリシーはＸＭＬで記述され、ポリシーは環境変数として宣言される。認可ポリシーを変更するために、環境変数の宣言が変更される。その上、各アプリケーションは、異なるポリシーを有することができ、ユーザが特定のユーザ名およびパスワードでログインするときにＸＭＬフォーマットで宣言的に指定することができる。
【００４６】
本発明の諸実施形態を実施するための代表的なハードウェア環境は図１０に描写されている。この概略図は、本発明の諸実施形態による情報処理／コンピュータ・システムのハードウェア構成を例示している。このシステムは、少なくとも１つのプロセッサまたは中央演算処理装置（ＣＰＵ：central processing unit）１０を有する。ＣＰＵ１０は、システム・バス１２を介して、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）１４、読み取り専用メモリ（ＲＯＭ：read-only memory）１６、および入出力（Ｉ／Ｏ：input/output）アダプタ１８に相互接続されている。入出力アダプタ１８は、ディスク装置１１および磁気テープ・ドライブ１３などの周辺装置またはシステムによって読み取り可能なその他のプログラム記憶装置に接続することができる。このシステムは、プログラム記憶装置上の発明に関する命令を読み取り、これらの命令に従って本発明の諸実施形態の方法を実行することができる。このシステムは、ユーザ入力を収集するために、キーボード１５、マウス１７、スピーカ２４、マイクロホン２２、またはタッチスクリーン装置（図示せず）などのその他のユーザ・インターフェース装置をバス１２に接続するユーザ・インターフェース・アダプタ１９をさらに含む。さらに、通信アダプタ２０はバス１２をデータ処理ネットワーク２５に接続し、ディスプレイ・アダプタ２１は、たとえば、モニタ、プリンタ、または送信機などの出力装置として実施可能なディスプレイ装置２３にバス１２を接続する。
【００４７】
本発明の諸実施形態によって提供される認可技法は、新しいコードを作成せずに認可要件を満たすための方法を提供し、新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。さらに、本発明の諸実施形態は、多様な認可要件をＸＭＬフォーマットで表し、オブジェクト制約ロジックを使用して認可のためにオブジェクト・グループを構文解析して生成し、環境変数を認可パラメータとして追加し、認証済みプリンシパル間の関係を定義し、同じ認可ポリシー・プロバイダを使用して多様なクラスの認可ポリシーを実装し、配置時にアクションをグループ化するための技法を提供する。本発明の諸実施形態は、Ｊ２ＥＥ（Ｒ）／非Ｊ２ＥＥ（Ｒ）環境のすべてのＪａｖａ（Ｒ）アプリケーションに有用である。その上、本明細書に記載した環境は、すべてのＪ２ＥＥ（Ｒ）／非Ｊ２ＥＥ（Ｒ）アプリケーションに適用される。
【図面の簡単な説明】
【００４８】
【図１】Ｊａｖａ（Ｒ）用の典型的なポリシー・ファイルを示す図である。
【図２】ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを使用してＪａｖａ（Ｒ）メソッドを保護するための典型的なコードを示す図である。
【図３】ＪＡＡＳにおけるプリンシパル・ベースの認可のための典型的なポリシーを示す図である。
【図４】本発明の一実施形態によりＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎを使用する保護メソッドのための疑似コードを示す図である。
【図５】本発明の一実施形態による汎用認可における認可ポリシーを示す図である。
【図６】本発明の一実施形態の好ましい方法を例示する流れ図である。
【図７】本発明の他の一実施形態の好ましい方法を例示する流れ図である。
【図８】本発明の他の態様の好ましい方法を例示する流れ図である。
【図９】本発明の一実施形態によるシステム・ブロック図である。
【図１０】本発明の一実施形態によるコンピュータ・システム図である。
【技術分野】
【０００１】
本発明の諸実施形態は、一般に、ソフトウェア・アプリケーション開発に関し、詳細には、Ｊａｖａ（Ｒ）ベースのセキュリティおよび認可ソフトウェア・アプリケーション開発システムおよび方法に関する。
【背景技術】
【０００２】
セキュリティおよび認可は、ソフトウェア・システムの開発、配置、および機能において非常に重要な役割を果たしている。米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能なＪａｖａ（Ｒ）は、コンポーネントベースのソフトウェアおよびシステムのための最も普及しているプラットフォームである。その上、Ｊａｖａ（Ｒ）セキュリティは、ｅコマース・エンタープライズ・システムにおいて重要な役割を果たしている。セキュリティ機能は、典型的には、臨時にアプリケーション内に組み込まれるか、または米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能であり、コンテナ管理の認証および認可を使用するアプリケーションであるエンタープライズＪ２ＥＥ（Ｒ）（Ｊａｖａ（Ｒ）２ Ｐｌａｔｆｏｒｍ Ｅｎｔｅｒｐｒｉｓｅ Ｅｄｉｔｉｏｎ）と統合される。このような状況には、いくつかの理由がある。第一に、セキュリティはアプリケーションのほぼすべてのコンポーネントによって処理されなければならないが、ソフトウェア開発におけるその統合は集中化されていない。第二に、きめの粗い（granular）セキュリティを開発するための標準的で使いやすいプロセスが欠如している。Ｊ２ＥＥ（Ｒ）システムでは、コンテナは、多くの状況には十分ではない可能性のあるメソッドレベルのセキュリティと役割ベースのアクセス制御を提供する。全体的に、低レベルのセキュリティ開発により、セキュリティ実装が厳正で、アプリケーションに緊密に結合されたものになる。
【０００３】
Ｊａｖａ（Ｒ）認証・承認サービス（ＪＡＡＳ：JavaAuthentication and Authorization Service）は、ユーザに関するアクセス制御を認証し執行するためのサービスを使用可能にするＪａｖａ（Ｒ）パッケージである。換言すれば、ＪＡＡＳは、（１）Ｊａｖａ（Ｒ）コードがアプリケーション、アプレット、Ｂｅａｎ、またはサーブレットとして実行されているかどうかにかかわらず、現在、誰がそのコードを実行しているかを確実かつ安全に判断するためのユーザの認証のため、ならびに（２）Ｊａｖａ（Ｒ）コードがアプリケーション、アプレット、Ｂｅａｎ、またはサーブレットとして実行されているかどうかにかかわらず、認証済みユーザがリソース（Ｊａｖａ（Ｒ）コードまたはＪａｖａ（Ｒ）コードによってアクセスされる何らかのオブジェクト／エンティティにすることができる）にアクセスできるかどうかを判断するためのユーザの認可のためという２つの目的に使用できる１組のＪａｖａ（Ｒ）アプリケーション・プログラム・インターフェース（ＡＰＩ：Application Program Interface）である。典型的には、ＪＡＡＳ認証は、プラグ可能なやり方で実行される。これにより、Ｊａｖａ（Ｒ）アプリケーションは、基礎となる認証技術から独立した状態で存続することができる。その上、アプリケーション自体の変更を必要とせずに、新しい技術または更新された技術をプラグ接続することができる。
【０００４】
Ｊａｖａ（Ｒ）では、バイトコード・ベリファイヤ（byte-code verifier）、クラス・ローダ（class loader）、およびセキュリティ・マネージャ（security manager）という３タイプの防衛メカニズムを使用する。Ｊａｖａ（Ｒ）バージョン１．０では、アプレットが「サンドボックス（sandbox）」内で動作し、それにより、アプレットが実行されるマシンに影響を及ぼすか、またはそこから任意の機密情報を入手するために、アプレットの能力を制限する。このため、ローカルにアクセスできるものは非常に少ない。Ｊａｖａ（Ｒ）のその後のバージョンでは、それを実行しているマシンが署名情報に基づいてそのように実行することを許可する場合、アプレットはサンドボックスを脱出することができる。柔軟できめ細かいアクセス制御をサポートするために、Ｊａｖａ（Ｒ）バージョン１．２は、ポリシー・ベースのセキュリティ・アーキテクチャを提供する。ポリシーは、様々な位置の様々な署名者によるコードに関する１組のパーミッション（permission）によって定義される。パーミッションにより、特定のリソースに関する特定のアクションへのアクセスが可能になる。通常、リソース名およびその関連アクションは、ポリシー・ファイルに列挙される。図１は、Ｊａｖａ（Ｒ）の典型的なポリシー・ファイルを例示している。
【０００５】
Ｊａｖａ（Ｒ）バージョン２では、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒによって以前提供された２つの機能、すなわち、セキュリティ・ポリシーの確立とセキュリティ・ポリシーの実施が分離されている。ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｏｌｉｃｙ抽象クラスはセキュリティ・ポリシーを確立するために使用され、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒはセキュリティ執行者（security enforcer）として使用される。後方互換性のために、ＳｅｃｕｒｉｔｙＭａｎａｇｅｒクラスは依然として存在するが、これはその決定のためにＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを参照する。ｊａｖａ．ｐｏｌｉｃｙでは、パーミッションはコードソースに関連付けられる。このため、それは、ユーザまたは役割ベースのパーミッションを備えていない。図２は、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを使用するＪａｖａ（Ｒ）メソッドを保護するための典型的なコードを例示している。図２に例示されている例は、リソースにアクセスする前にＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを呼び出すことにより、どのようにリソースが保護されるかを示している。ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、アプリケーションの現行認可ポリシーによって要求された許可をチェックする。ポリシー・ファイルに定義されたパーミッションが要求されたパーミッションを暗示する場合、メソッドの「ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ」コマンドが単純に戻り、さもなければ、ＡｃｃｅｓｓＣｏｎｔｒｏｌＥｘｃｅｐｔｉｏｎが開始される。
【０００６】
前述の通り、ＪＡＡＳは、ユーザに関するアクセス制御を認証し執行するためのサービスを使用可能にする１組のＡＰＩである。ＪＡＡＳは、現在、誰がＪａｖａ（Ｒ）コードを実行しているか、ならびにそのように実行することを許可されているかどうかを確実かつ安全に判断する。その上、ＪＡＡＳは、標準的なプラグ可能認証モジュール（ＰＡＭ：Pluggable Authentication Module）フレームワークのＪａｖａ（Ｒ）技術バージョンを実装するものである。これにより、Ｊａｖａ（Ｒ）アプリケーションは、基礎となる認証メカニズムから独立した状態で存続することができる。
【０００７】
ＪＡＡＳは、２つの主要コンポーネント、すなわち、認証（authentication）および認可（authorization）を含む。ＪＡＡＳは、Ｊａｖａ（Ｒ）バージョン２のセキュリティ・モデルにサブジェクト・ベースのポリシーを追加する。パーミッションは、ＣｏｄｅＳｏｕｒｃｅに基づくだけでなく、コードを実行しているユーザにも基づいて付与される。この場合、ユーザは先に認証される。ＪＡＡＳ配布は、ユーザからユーザＩＤおよびパスワードを取得するための様々なＬｏｇｉｎＭｏｄｕｌｅ実装を含む。ＬｏｇｉｎＣｏｎｔｅｘｔは、認証のためにどのＬｏｇｉｎＭｏｄｕｌｅを使用すべきかを判断するためにログイン構成ファイルを使用する。Ｓｕｂｊｅｃｔクラスは、認証済みユーザの資格情報をカプセル化するために使用される。サブジェクトは、プリンシパル（principal）と呼ばれる複数のＩＤを有することができる。ＪＡＡＳポリシー・ファイル内の各ｇｒａｎｔ文はプリンシパルに関連付けられている。サブジェクトに関連する各プリンシパルごとに、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、ＰｏｌｉｃｙＦｉｌｅからパーミッションを入手し、任意のパーミッションが要求されたパーミッションを暗示するかどうかをチェックする。さもなければ、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、ＡｃｃｅｓｓＣｏｎｔｒｏｌＥｘｃｅｐｔｉｏｎを開始する。図３は、ＪＡＡＳ内のプリンシパル・ベースの認可に関する典型的なポリシーを例示している。
【０００８】
Ｊ２ＥＥ（Ｒ）アーキテクチャでは、コンテナは、それがホストとして処理するコンポーネントとその呼び出し側との間の認可境界として機能する。コンテナは、呼び出し側コードのユーザのＩＤを確立する。呼び出されたコンポーネント、ＥＪＢ（米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能なＥｎｔｅｒｐｒｉｓｅ ＪａｖａＢｅａｎｓ（Ｒ））、またはＷｅｂコンポーネントへのアクセスは、呼び出し側のセキュリティ属性を、呼び出されたコンポーネントにアクセスするために必要なものと比較することによって決定される。宣言認可（declarative authorization）では、デプロイヤ（deployer）は、Ｊ２ＥＥ（Ｒ）アプリケーションに関するコンテナ執行のアクセス制御ルールを確立する。デプロイヤは、典型的にはアプリケーション・アセンブラによって供給されたアプリケーション・パーミッション・モデルをランタイム環境に特有のメカニズムにマッピングする。配置記述子（deployment descriptor）は、様々なコンポーネントに関するセキュリティ役割とそれに関連するアクセス権を定義する。デプロイヤは、ランタイム環境内のユーザのアクセス権を確立するために、特定の呼び出し側にセキュリティ役割を割り当てる。たとえば、デプロイヤは、セキュリティ役割を動作環境内のプリンシパルＩＤのリストにマッピングすることができる。その場合、これらのＩＤの１つで認証された呼び出し側には、役割によって表される特権が割り当てられる。Ｊ２ＥＥ（Ｒ）コンテナは、コンポーネントへのディスパッチング・メソッド呼び出しの前にアクセス制御決定を行う。したがって、宣言アクセス制御は、メソッドの細分性によって割り当てることができる。
【０００９】
Ｊ２ＥＥ（Ｒ）コンテナは、これらのアクセス決定におけるコンポーネントのロジックまたは状態を考慮に入れない。これを実行するために、コード開発者がプログラムによる認可（programmatic authorization）を実行する必要がある。コンポーネントは、きめ細かいアクセス制御を実行するために、ＥＪＢＣｏｎｔｅｘｔ．ｉｓＣａｌｌｅｒＩｎＲｏｌｅ（ＥＪＢコンポーネントの場合）およびＨｔｔｐＳｅｒｖｌｅｔＲｅｑｕｅｓｔ．ｉｓＵｓｅｒＩｎＲｏｌｅ（Ｗｅｂコンポーネントの場合）という２つのメソッドを使用することができる。コンポーネントは、これらのメソッドを使用して、呼び出しのパラメータ、コンポーネントの内部状態、またはランタイム・パラメータなどのその他の要因に基づいて、コンポーネントによって選択された特権が呼び出し側に付与されているかどうかを判断する。しかし、宣言認可とプログラマチック認可との間にはトレードオフが存在する。宣言認可はデプロイヤによって構成された外部アクセス制御ポリシーであり、プログラマチック認可はコンポーネント開発者によってアプリケーションに埋め込まれた内部ポリシーによるものである。内部ポリシーはよりきめ細かいものであり、外部ポリシーはより柔軟なものである。その上、外部ポリシーは透過性であり、内部ポリシーはアプリケーションに埋め込まれる。たとえば、「従業員は自分自身の給与情報のみにアクセスできる」という認可ポリシーを提供するためには、必要であれば、将来変更できないプログラムによる認可が必要である。
【００１０】
その上、ＪＡＡＳは、Ｊａｖａ（Ｒ）の既存のセキュリティ・モデルの上に構築され、それはＣｏｄｅＳｏｕｒｃｅベースのものであり、プレーンテキスト・フォーマットのポリシー・ファイル実装である。ＪＡＡＳは、特定のコンポーネントによってアクセスされるクラスに基づく認可を実装する。しかし、これは、エンタープライズ・アプリケーションには十分ではない可能性があり、それにより、ＪＡＡＳとともに、ＬＤＡＰ（軽量ディレクトリ・アクセス・プロトコル（Lightweight Directory Access Protocol））などのカスタム・セキュリティ・リポジトリを使用する必要がある場合もある。さらに、企業間（business-to-business）の電子商取引における価格設定契約は、他の契約とは異なるアクセス制御ポリシーを有する場合もある。セルフサービス・オークション・アプリケーションに関する指定は、「登録済みユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件を有する可能性もある。したがって、多くのＪａｖａ（Ｒ）アプリケーションは、その認可要件を満足するためにＪＡＡＳを拡張する必要がある。ＪＡＡＳの諸機能はプラグ可能であるので、ＪＡＡＳのデフォルト動作を変更するために様々な認証および認可サブモジュールについて自分専用の実装例を作成することができる。上記の例に例示されている認可要件の場合、以下の１つまたは複数のデフォルト実装を変更する必要がある場合もある。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｅｒｍｉｓｓｉｏｎ： 呼び出されたＣｏｄｅＳｏｕｒｃｅについてアクションを実行するための権限を呼び出し側が有するかどうかを判断するために、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒ．ｃｈｅｃｋＰｅｒｍｉｓｓｉｏｎ（Ｐｅｒｍｉｓｓｉｏｎ ｐｅｒｍ）が呼び出される。パーミッション・オブジェクトｐｅｒｍは、リソースへの必要なアクセスを表している。パーミッション・オブジェクトは、パーミッションの名前（アクセスが必要なリソースを示す可能性がある）、リソースがアクセスされるアクションなどの項目を指定することができる。パーミッション・クラスは、付与されたパーミッションが要求されたパーミッションを暗示するかどうかを判断するために、ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒによって呼び出される暗黙のメソッドを実装する。クラス・インスタンス・レベル認可を実装するために、そのフィールドの１つとしてオブジェクト・インスタンスを有するパーミッションの新しい実装を有する必要がある。そのオブジェクトは、認可を決定するために暗黙のメソッドで使用することができる。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．ＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎ： この抽象クラスは、パーミッション・オブジェクトの集合を表すために使用される。このクラスは、付与されたパーミッションを保管し、それを要求されたパーミッションと比較して、付与されたパーミッションのいずれかが要求されたパーミッションを暗示するかどうかを判断する所望のやり方を備えるために実装することができる。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｏｌｉｃｙ： これは、Ｊａｖａ（Ｒ）アプリケーション環境においてセキュリティ・ポリシーを保管するための抽象クラスである。ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒは、ＣｏｄｅＳｏｕｒｃｅ上の認証済みサブジェクトに関するパーミッションを入手するためにポリシー実装に連絡する。ポリシー・オブジェクトは、そのポリシー指定を調べ、許可されるパーミッションを列挙する適切なＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎオブジェクトを返す。デフォルトでは、ｓｕｎ．ｓｅｃｕｒｉｔｙ．ｐｒｏｖｉｄｅｒ．ＰｏｌｉｃｙＦｉｌｅ実装がポリシー実装に使用される。異なる実装を有することにより、ポリシーが作成される方法（たとえば、ＬＤＡＰまたはソフトウェア・アプリケーション）または認可が依存する追加のパラメータを変更することができる。
・ｊａｖａｘ．ｓｅｃｕｒｉｔｙ．ａｕｔｈ．ｓｐｉ．ＬｏｇｉｎＭｏｄｕｌｅ： ＬｏｇｉｎＭｏｄｕｌｅは、認証プロバイダによって実装されたインターフェースを記述する。これは、デフォルトでは何らかのユーザ対話を実行するコールバックからユーザ名およびパスワード（複数も可）を検索する。ＬｏｇｉｎＭｏｄｕｌｅは、認証を何らかの外部アダプタに委任するよう、拡張することができる。
・ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｒｉｎｃｉｐａｌ： Ｐｒｉｎｃｉｐａｌインターフェースは、個人、組織、グループ、またはログインＩＤなどのエンティティを表すために使用される抽象概念を表す。Ｇｒｏｕｐ、ＫｅｒｂｅｒｏｓＰｒｉｎｃｉｐａｌなどは、Ｐｒｉｎｃｉｐａｌの周知の実装例である。Ｐｒｉｎｃｉｐａｌを拡張することにより、認可に使用すべきカスタム・プロパティを追加することができる。
【００１１】
しかし、ＪＡＡＳの制限の１つは、それがクラス・インスタンス・レベル認可をサポートしないことであり、すなわち、ＪＡＡＳ内の認可は、クラスの特定のインスタンスを基礎として実行されるのではなく、クラス名を基礎として実行される。たとえば、Ｗｅｂベースのセルフサービス・オークション・アプリケーションに関する指定は、「登録済み（認証済み）ユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件を有する可能性がある。これは、どのユーザもオークション・クラス・インスタンスを作成するために作成されたコードを実行することができるが、そのインスタンスを所有するユーザのみが、それを変更するために設計されたコードを実行できることを意味する。通常、オークション・インスタンスを作成したユーザは所有者になる。これにより、同じ役割の人は、その属性または過去に実行したアクションに基づいて異なるアクセス権を有する可能性があることが暗示される。残念ながら、このタイプの認可は、ＪＡＡＳを使用してサポートすることができない。
【００１２】
ＪＡＡＳ認可は、どのアクセス権が実行中のコードに付与されるかを指定するためにセキュリティ・ポリシーを使用する既存のＪａｖａ（Ｒ）セキュリティ・アーキテクチャを拡張する。Ｊａｖａ（Ｒ）バージョン２のプラットフォームで提供される、このセキュリティ・アーキテクチャはコード中心である。すなわち、パーミッションはコード特性、すなわち、コードがどこから来るか、それがデジタル署名されるかどうか、そうである場合に、誰によって署名されるかに基づいて付与される。ＪＡＡＳをＪａｖａ（Ｒ）２のＳＤＫ（ソフトウェア開発キット（Software Development Kit））に統合することにより、ｊａｖａ．ｓｅｃｕｒｉｔｙ．Ｐｏｌｉｃｙ ＡＰＩはプリンシパルベースの照会を処理し、デフォルトのポリシー実装はプリンシパルベースの付与項目をサポートする。したがって、アクセス制御は、どのコードが実行されているか、ならびに誰がコードを実行しているかに基づくものになる可能性がある。
【００１３】
ＪＡＡＳは、インスタンス・レベルＪＡＡＳをサポートするためのメカニズムを提供する。これは、ＪＡＡＳによって使用されるクラスのいくつかを拡張することによって実施される。しかし、この手法の主な欠点は、それが拡張可能ではなく、異なるドメインで異なる種類の認可を提供する場合に新しい認可クラスの作成と相当な量の手直しを必要とすることである。インスタンス・レベル認可をサポートするためのもう１つのオプションは、アプリケーションの一部としてコーディングされるカスタム認可コードを使用することである。一般に、これは、認可技法をサポートするために最も広く使用される方法であり、その主要な欠点は、それが標準に基づくものではなく、異なるアプリケーションで適用することをより難しくしていることである。さらに、このコードはアプリケーションの一部であるので保守が難しく、それが非汎用であるので一般に異なるドメインで再利用することができない。
【発明の開示】
【発明が解決しようとする課題】
【００１４】
したがって、従来の手法の欠点および制限のために、新しいコードを必要とせずに異なるドメインに適用できる、より普遍的に適用可能なＪＡＡＳベースの認可ソリューションの必要性が残っている。新しい認可要件に関する新しいコードを作成すると、配置時に認可設定を変更することが難しくなる。したがって、プログラマチック認可の高細分性とともに宣言認可の柔軟性が必要である。
【課題を解決するための手段】
【００１５】
上記を考慮すると、本発明の一実施形態は、ソフトウェア・オブジェクトおよびアプリケーションのいずれかによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を提供し、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクトをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクトにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。生成ステップにおいて、アプリケーション・オブジェクト記述ドキュメントは、拡張可能マークアップ言語（ＸＭＬ：eXtensible Markup Language）フォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、認可ポリシーを変更するステップとをさらに有する。さらに、この方法は、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか（およびこれらのメソッドおよびフィールド・パラメータに関する定義制約）、すべてのアプリケーション・オブジェクト・グループ間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクト・グループを指定するステップをさらに有する。その上、この方法は、同じ認可ポリシー分類器（classifier）を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００１６】
本発明の他の実施形態は、ソフトウェア・アプリケーションへのアクセスを制御する方法を提供し、この方法は、グループ化パラメータによりソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップと、アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップと、グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップと、ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関するユーザ・プロファイルと認可ポリシーとを突き合わせるステップとを有し、グループ化ステップにおいて、ソフトウェア・アプリケーションがアプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、アプリケーション・オブジェクト記述ドキュメントがＸＭＬフォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定およびグループ化制約を変更することにより、認可ポリシーを変更するステップとをさらに有する。グループ化ステップにおいて、このグループ化パラメータは、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係、またはソフトウェア・アプリケーション／オブジェクトによって表されるリソース、データ、またはコードを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクトを指定するステップを有する。この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００１７】
本発明の他の態様は、ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立するためのシステムを提供し、このシステムは、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するための手段と、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するための手段と、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するための手段と、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するための手段とを有する。
【００１８】
本発明の他の実施形態は、ソフトウェア・オブジェクトへのアクセスを制御するためのシステムを提供し、このシステムは、少なくとも１つのアプリケーション・オブジェクト・グループを有するアプリケーション・オブジェクト記述ドキュメントと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するように適合された認可ポリシー分類器（classifier）と、ソフトウェア・オブジェクトの配置時に認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてアクセス制御パラメータを確立するように適合されたアクセス・コントローラとを有し、アプリケーション・オブジェクト記述ドキュメントがＸＭＬフォーマットを有し、認可ポリシーが環境変数を有する。このシステムは、環境変数の宣言指定およびグループ化ルールを変更することにより、認可ポリシーを変更するように適合されたジェネレータ・ルーチンをさらに有する。このシステムによれば、アプリケーション・オブジェクト・グループは、ユーザ選択のアプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して指定される。その上、認可ポリシー分類器は、多様なクラスの認可ポリシーを実装するように適合される。
【００１９】
さらに、本発明の他の態様は、ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を実行するためにコンピュータによって実行可能な複数命令からなるプログラムを具体的に実施する、コンピュータによって読み取り可能なプログラム記憶装置を提供し、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。
【００２０】
本発明の諸実施形態により提供される認可技法は、新しいコードを作成せずに認可要件を満たす方法を提供し、新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。さらに、本発明の諸実施形態は、多様な認可要件をＸＭＬフォーマットで表し、オブジェクト制約ロジックを使用して認可のためのオブジェクト・グループを構文解析して生成し、認可パラメータとして環境変数を追加し、認証済みプリンシパル間の関係を定義し、同じ認可ポリシー・プロバイダを使用して、多様なクラスの認可ポリシーを実装し、配置時にアクションをグループ化するための技法を提供する。
【００２１】
本発明の諸実施形態の上記その他の諸態様は、以下の説明および添付図面に併せて考慮したときに、より十分に認識され理解されるであろう。しかし、以下の説明は、本発明の好ましい諸実施形態およびその数多くの特定の詳細を示しており、制限としてではなく、例示として示されていることを理解されたい。
【００２２】
本発明の諸実施形態は、図面に関して以下の詳細な説明からより十分に理解されるであろう。
【発明を実施するための最良の形態】
【００２３】
添付図面に例示され、以下の説明に詳述されている非制限的諸実施形態に関して、本発明の諸実施形態ならびにその様々な特徴および有利な詳細をより完全に説明する。図面に例示されている特徴は必ずしも一定の縮尺で描かれていないことに留意されたい。本発明の諸実施形態を不必要に不明確にしないために、周知のコンポーネントおよび処理技法の説明は省略されている。本明細書で使用される例は、単に本発明の諸実施形態を実施できる方法の理解を容易にするためのものであり、さらに当業者が本発明の諸実施形態を実施できるようにするためのものである。したがって、この例は、本発明の諸実施形態の範囲を制限するものと解釈してはならない。
【００２４】
前述の通り、認可セットアップに対する大幅な変更を必要とせずに異なるドメインに適用できる、より普遍的に適用可能なＪａｖａ（Ｒ）ベースのソフトウェア・アプリケーション開発技法の必要性が残っている。本発明の諸実施形態は、ＪＡＡＳ標準に基づいてＪａｖａ（Ｒ）アプリケーションに対し汎用性で低レベルで拡張可能なセキュリティを提供することにより、この必要性に対処する。次に図面を参照し、詳細には図４〜図１０を参照すると、本発明の好ましい諸実施形態が図示されている。
【００２５】
上述の通り、ＪＡＡＳは、様々な認証および認可目標を達成するために様々な方法で拡張することができる。しかし、様々な拡張について、様々なＪＡＡＳインターフェースおよびクラスをそれぞれ実装または拡張するためのコードを作成する必要がある場合がある。このため、アプリケーションの配置時にセキュリティ設定を変更することが難しくなる。したがって、本発明の諸実施形態によって提供される汎用認可技法は、プログラマチック認可の高細分性を保持しながら宣言認可を使用することにより、この柔軟性を達成する。
【００２６】
したがって、本発明の諸実施形態によって提供される認可技法は、宣言指定を使用するプログラマチック認可の諸機能を提供する。具体的には、本発明の諸実施形態は、プログラマチックではなく宣言的に認可要件を満たすことができるようにＪＡＡＳを拡張する。認証および認可を使用して保護する必要がある各メソッドは、そのメソッドが属すクラス、そのメソッドが実行する必要があるアクション、およびそのメソッドが呼び出されるオブジェクトという少なくとも３つのパラメータを有するＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎオブジェクトのコンストラクタへの呼び出しから始まる。図４は、上述の通り、本発明の一態様によりＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎを使用する保護メソッドのための疑似コードを例示している。
【００２７】
図５に例示されている通り、認可ポリシーはＸＭＬフォーマットで表現することができる。たとえば、図５に図示されている通り、「登録済みユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件に関する認可ポリシーが作成される。同様に、異なる価格設定契約について異なる認可ポリシーを備えて、パーミッションは、｛ｉｄｎａｍｅ＝“ｇｅｔＣｏｎｔｒａｃｔＩＤ”， ｉｄｔｙｐｅ＝“ｍｅｔｈｏｄ”， ｉｄｖａｌｕｅ＝“ｉｂｍ−ｓｕｎ”｝パラメータに基づくものである。
【００２８】
汎用認可の場合、ＪＤＫは、適正な認可ポリシー・プロバイダのために構成される。これは、Ｊａｖａ＿ｈｏｍｅ／ｊｒｅ／ｌｉｂ／ｓｅｃｕｒｉｔｙディレクトリのＪａｖａ．ｓｅｃｕｒｉｔｙファイル内のａｕｔｈ．ｐｏｌｉｃｙ．ｐｒｏｖｉｄｅｒを変更／追加することによって実施され、Ｊａｖａ＿ｈｏｍｅはＪａｖａ（Ｒ）がシステム内にインストールされるパスである。汎用認可は多種多様な認可ポリシーを包含するので、それぞれがそれ専用の認可要件を有するいくつかのアプリケーションについて１つの認可ポリシー・プロバイダしか存在できないという制限がある場合でも、各アプリケーションごとに別々のコードを作成する必要なしに同じマシン上で実行することができる。
【００２９】
図６は、ソフトウェア・オブジェクト／アプリケーションによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を例示しており、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップ（１０１）と、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップ（１０３）と、ユーザ選択のアプリケーション・オブジェクトをシステム２００のアクセス・コントローラ２０８（図９に図示されている）に送信するステップ（１０５）と、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップ（１０７）とを有する。生成ステップ（１０１）において、アプリケーション・オブジェクト記述ドキュメントは、ＸＭＬフォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更することにより、認可ポリシーを変更するステップとをさらに有する。さらに、この方法は、選択されたアプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト・グループ間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクト・グループを指定するステップをさらに有する。その上、この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００３０】
本発明の他の実施形態は図７に例示されており、同図は、ソフトウェア・オブジェクト／アプリケーションによって表されるリソース、データ、またはコードへのアクセスを制御する方法を例示し、この方法は、オブジェクト・メソッド呼び出し結果、オブジェクト・フィールド値、および環境変数のうちの１つまたは複数を有するグループ化パラメータによりソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップ（１１１）と、アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップ（１１３）と、グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップ（１１５）と、ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関するユーザ・プロファイルと認可ポリシーとを突き合わせるステップ（１１７）とを有し、グループ化ステップ（１１１）において、ソフトウェア・アプリケーションはアプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、アプリケーション・オブジェクト記述ドキュメントはＸＭＬフォーマットを有する。
【００３１】
さらに、グループ化ステップ（１１１）において、このグループ化パラメータは、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係、またはユーザ選択のソフトウェア・オブジェクトを少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクトを指定するステップを有する。図８に図示されている通り、この方法は、認可ポリシーに関する環境変数を指定するステップ（１１９）と、環境変数の宣言指定を変更することにより、認可ポリシーを変更するステップ（１２１）とをさらに有する。この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【００３２】
認可ポリシーを作成する方法によれば、本発明の諸実施形態により、ポリシーがこれらの変数に依存することができるように、何らかのセキュリティ関連変数および環境変数へのアクセスが可能になる。これにより、「平日にはソフトウェア・アプリケーションへのアクセスを許可し、週末には禁止する」などのポリシーを有することが可能になる。
【００３３】
図９は、ソフトウェア・アプリケーションへのアクセスを制御するためのシステム２００を例示し、このシステム２００は、少なくとも１つのアプリケーション・オブジェクト・グループ２０４を有するアプリケーション・オブジェクト記述ドキュメント２０２と、各アプリケーション・オブジェクト・グループ２０４ごとに認可ポリシーを指定するように適合された認可ポリシー分類器２０６と、ソフトウェア・アプリケーションの配置時に認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループ２０４にアクセスしようと試みるユーザ２１０についてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するように適合されたアクセス・コントローラ２０８とを有し、アプリケーション・オブジェクト記述ドキュメント２０２がＸＭＬフォーマットを有し、認可ポリシーが環境変数を有する。
【００３４】
このシステムは、環境変数の宣言指定を変更することにより、認可ポリシーを変更するように適合されたジェネレータ・ルーチン２１２をさらに有する。このシステム２００によれば、アプリケーション・オブジェクト・グループ２０４は、アプリケーション・オブジェクト・グループ２０４に関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト・グループ２０４間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメント２０２を少なくとも１つのアプリケーション・オブジェクト・グループ２０４に構文解析するための所定のグループ化アクションを使用して指定される。その上、認可ポリシー分類器２０６は、多様なクラスの認可ポリシーを実装するように適合される。
【００３５】
本発明の諸実施形態は、オブジェクト制約ロジック（ＸＭＬファイルに作成される）を構文解析し、認可のためのオブジェクト・グループを生成するための技法を提供する。従来、ＪＡＡＳでは、認可ポリシーはクラス（コード）レベルで作成される。逆に、本発明の諸実施形態によれば、認可ポリシーはオブジェクト・グループの細分性で作成される。オブジェクト・グループは、当該オブジェクトのメソッド／フィールドを使用して表される。たとえば、「契約」というクラスが存在すると想定すると、ＪＡＡＳでは、すべての契約が同じ認可プロパティを有することになり、本発明の諸実施形態によって提供される汎用認可では、ユーザは「サン（Ｒ）」（サン（Ｒ）は米国カリフォルニア州サンタクララのサン・マイクロシステムズ社の登録商標である）との契約を更新できる可能性があるが、「マイクロソフト（Ｒ）」（マイクロソフト（Ｒ）は米国ワシントン州レドモンドのマイクロソフト社の登録商標である）に関する契約を更新できない可能性がある。ＪＡＡＳでは、アプリケーション・オブジェクトに関する認可は、そのアプリケーション・オブジェクトの特性に依存しない。このため、すべてのアプリケーション・オブジェクトは同じ認可ルールを有する。これを回避するために、従来の手法では、典型的にはカスタム認可が実行される。逆に、本発明の諸実施形態は、個人がＪＡＡＳを使用してインスタンスレベルの認可（すなわち、データ・オブジェクトの特性に依存する認可）を実行できるようにする技法を提供する。
【００３６】
本発明によって提供される方法は、認証済みプリンシパル間の関係を定義する。従来、ＪＡＡＳでは、ユーザが認証されると、そのユーザは「サブジェクト」という型のオブジェクトによって表される。各サブジェクトは、それに関連する複数のプリンシパルを有することができる。これらのプリンシパルは、その個人が有することができる種々のＩＤを表す。このため、ある個人は、自分の名前（１つのプリンシパルである）または自分の社会保障番号（もう１つのプリンシパルである）によって明確に識別することができる。しかし、本発明の諸実施形態によって提供されるＸＭＬベースの表現を使用して、「ユーザ（認証済みプリンシパル）がオブジェクト（このオブジェクトはリーブ・アプリケーション（leave application）に関するものである可能性がある）の所有者のマネージャである場合、ユーザは承認メソッドを呼び出すことができる」などのポリシーを定義することができる。この場合も、本発明の諸実施形態は個人がＪＡＡＳを使用してインスタンスレベルの認可（すなわち、データ・オブジェクトの特性に依存する認可）を実行できるようにする技法を提供するので、これは有利である。さらに、これは宣言方式で実行され、プログラマチック認可より柔軟なものである。その上、このセットアップを使用して、認可のためにサブジェクト間の動的関係を使用することができる。この例では、ポリシーは認証済みプリンシパル間の関係（マネージャ）に関して定義される。
【００３７】
次に、本発明の諸実施形態は、同じ認可ポリシー・プロバイダを使用して多様なクラスの認可ポリシーを実装できる方法を提供する。認可プロバイダは、ｊａｖａ＿ｈｏｍｅ／ｊｒｅ／ｌｉｂ／ｓｅｃｕｒｉｔｙのｊａｖａ．ｓｅｃｕｒｉｔｙファイルに構成される。Ｊａｖａ（Ｒ）仮想マシン（ＪＶＭ：Java Virtual Machine）の場合、これは、ｊａｖａ．ｓｅｃｕｒｉｔｙファイルのａｕｔｈ．ｐｏｌｉｃｙ．ｐｒｏｖｉｄｅｒというプロパティを変更することによって構成される。汎用認可は多種多様な認可ポリシーを包含するので、１つの認可ポリシー・プロバイダしか存在できないという制限がある場合でも、それぞれがそれ専用の認可要件を有するいくつかのアプリケーションが同じＪＶＭ上で実行することができる。本発明の諸実施形態は単一のＸＭＬ認可ファイルを有するので、このファイルは、異なるアプリケーションについて異なる認可ルールを有することができる。各認可ルールは、そのアプリケーションに特有のアプリケーション・オブジェクトに関して定義されることになる。その上、認可インフラストラクチャは、単一の認可ファイルを使用することになる。このため、同じ認可ポリシー・プロバイダを使用して、多様なクラスの認可ポリシーを実装することができる。
【００３８】
本発明の諸実施形態は、配置時にアクションをグループ化するための方法をさらに提供する。異なるアクション・グループについて異なる認可要件を提供するように、アクションをグループ化することができる。配置時に、たとえば、「読み取り」アクションおよび「検索」アクションに同じ認可が使用されることを決定することができる。これは、認可ポリシーが認可ＸＭＬファイルに保管されたときに実施される。配置時に、単にＸＭＬを変更することにより、上述のアクションのグループ化を実施することができる。
【００３９】
次に、本発明の諸実施形態は、新しいコードを作成する必要なしに認可要件を満たすための方法を提供する。新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。これは、単にＸＭＬを変更することにより、上記の通り、実施される。このため、本発明の諸実施形態は新しいポリシーを提供し、これはコードに対する変更を必要としない。認可要件は、それをアプリケーションと統合するのではなくＸＭＬで表現されるので、（コード変更ではなく）単にＸＭＬを変更することにより、認可設定を変更することができる。本発明の諸実施形態によって提供されるＸＭＬベースのポリシー・ファイルでは、ｇｅｔＯｗｎｅｒ、ｇｅｔＭａｎａｇｅｒなどの特定の「Ｊａｖａ（Ｒ）Ｂｅａｎ様」メソッドの戻り値を使用して表された特定の特性を有する場合、ユーザ・プリンシパルは、特定のＪａｖａ（Ｒ）オブジェクトへのアクセスを許可される。
【００４０】
本発明の諸実施形態は、多様な認可要件をＸＭＬフォーマットで表すための方法をさらに含む。このフォーマットは、Ｊａｖａ（Ｒ）オブジェクト上の何らかのフィールドおよびメソッド呼び出しを使用してオブジェクトを指定すること、関係を使用してプリンシパルを指定すること、およびグループ化アクションを含む。また、本発明の諸実施形態は、時間、日などの環境変数をＸＭＬフォーマットで表し、これらの変数について認可ポリシーを定義する。ＸＭＬフォーマットでオブジェクトを識別するためのいくつかの方法を含むことにより、本発明の諸実施形態は認可設定に関する多種多様なオプションを作成するので、これは特に有利である。これらのオプションとしては、とりわけ、Ｊａｖａ（Ｒ）オブジェクトに関するフィールド値およびメソッド戻り値、プリンシパルおよびそれらの関係、環境変数を含む。したがって、本発明の諸実施形態は、配置時に認可ポリシーを変更することができ、それにより、ＪＡＡＳ標準を利用することができる。換言すれば、プログラマチック認可を利用せずに、インスタンスレベルの認可によってＪＡＡＳの利点が入手される。
【００４１】
その上、本発明の諸実施形態は、それに関する認可がチェックされるオブジェクトまたはアクセス要求を行っているオブジェクトあるいはその両方の引き渡しを可能にするコンストラクタを有する汎用パーミッション・クラスを提供する。従来、ＪＡＡＳでは、アクセス・コントローラを使用してパーミッションをチェックするためにパーミッション・オブジェクトが必要である。逆に、本発明の一実施形態によって提供される方法によれば、それに関するパーミッションが要求されるオブジェクトがアクセス・コントローラ２０８に渡されるＰｅｒｍｉｓｓｉｏｎオブジェクトのパラメータになるように、ＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎを使用してＰｅｒｍｉｓｓｉｏｎクラスが拡張される。したがって、アクセス・コントローラ２０８は、それに渡されるオブジェクトに基づいて、認可を決定することができる。この態様は、それに関する認可決定が行われるアプリケーション・オブジェクトの特定のインスタンスの特性に基づいて認可ルールを提供するために使用される。前述の通り、ＪＡＡＳでは、認可ポリシーはアプリケーション・オブジェクトのインスタンスから独立しており、ポリシーは同じカテゴリのアプリケーション・オブジェクトのすべてのインスタンスについて同じものである。オブジェクト・インスタンスをパラメータとして取る汎用パーミッション・クラスを使用するという上記の技法を使用して、本発明の諸実施形態は、インスタンスレベルの認可を提供することができる。
【００４２】
次に、本発明の諸実施形態は、環境変数の使用を可能にし、リフレクションを使用して動的メソッド呼び出しの表現を可能にし、式、述語論理などの表現を可能にする汎用ポリシー・ファイルを提供する。たとえば、本発明の諸実施形態は、認可要件を作成するためのフォーマットを提供する。このフォーマットは、Ｊａｖａ（Ｒ）オブジェクト上の何らかのフィールドおよびメソッド呼び出しを使用してオブジェクトを指定すること、関係を使用してプリンシパルを指定すること、およびグループ化アクションを含む。また、本発明の諸実施形態は、時間、日などの環境変数をＸＭＬフォーマットで表し、これらの変数について認可ポリシーを定義する。
【００４３】
さらに、本発明の諸実施形態は、汎用ポリシー・ファイルを構文解析し、Ｇｅｎｅｒｉｃ Ｐｏｌｉｃｙ Ｆｉｌｅの構文を理解し、過去のユーザＯｂｊｅｃｔ、ユーザＰｒｉｎｃｉｐａｌ／ユーザＳｕｂｊｅｃｔ、およびユーザ・コードに基づいてＧｅｎｅｒｉｃ Ｐｏｌｉｃｙ ＦｉｌｅからＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎを作成する、Ｐｏｌｉｃｙ Ｆｉｌｅ実装を提供する。これは、新しいタイプのＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスを使用することによって実施され、それにより、異なるタイプのポリシー・ファイル実装が使用される。したがって、本発明の諸実施形態は、Ｇｅｎｅｒｉｃ Ｐｏｌｉｃｙ Ｆｉｌｅの一般フォーマットを理解するが、必ずしもポリシー・ファイルに指定されたオブジェクト制約ロジックを理解するわけではない。しかし、この実装は、ポリシー・ファイルを使用してＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスを作成する。このため、前述のＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスは、ポリシー・ファイルに指定されたオブジェクト制約ロジックを理解する。
【００４４】
したがって、本発明の諸実施形態は、ＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎクラスを利用するが、これは、ポリシー・ファイルを使用し、ポリシー言語の宣言指定を理解し、環境変数の値を取得することができ、式および述語論理を評価し、Ｊａｖａ（Ｒ）リフレクションを使用してランタイム・パラメータ値を入手する。換言すれば、本発明の諸実施形態は、汎用ＸＭＬベースのポリシー・ファイルに作成されたロジックを理解する。
【００４５】
さらに、本発明の諸実施形態は、ＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎの集合を保管し、Ｇｅｎｅｒｉｃ Ｐｏｌｉｃｙ Ｆｉｌｅを理解できるＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎの暗黙のメソッドを呼び出すＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎＣｏｌｌｅｃｔｉｏｎクラスを提供する。一般に、本発明の諸実施形態は、そのオブジェクトをパラメータの１つとして取るパーミッションの汎用集合を定義し、これはＪＡＡＳ規格に従ってＪＡＡＳ環境で機能する。具体的には、本発明の諸実施形態は、ＸＭＬフォーマットで定義されるアクセス制御または認可を提供するＪａｖａ（Ｒ）ベースのポリシーを提供する。Ｊａｖａ（Ｒ）に関する認可ポリシーの認可パラメータを定義するために、環境変数はＸＭＬフォーマットで宣言的に指定される。ＸＭＬはアプリケーションから独立しており、宣言変数の使用は、クラス、メソッド、およびオブジェクトというＪａｖａ（Ｒ）パラメータをＸＭＬで定義することによって汎用認可を可能にする。いくつかの異なるポリシーはＸＭＬで記述され、ポリシーは環境変数として宣言される。認可ポリシーを変更するために、環境変数の宣言が変更される。その上、各アプリケーションは、異なるポリシーを有することができ、ユーザが特定のユーザ名およびパスワードでログインするときにＸＭＬフォーマットで宣言的に指定することができる。
【００４６】
本発明の諸実施形態を実施するための代表的なハードウェア環境は図１０に描写されている。この概略図は、本発明の諸実施形態による情報処理／コンピュータ・システムのハードウェア構成を例示している。このシステムは、少なくとも１つのプロセッサまたは中央演算処理装置（ＣＰＵ：central processing unit）１０を有する。ＣＰＵ１０は、システム・バス１２を介して、ランダム・アクセス・メモリ（ＲＡＭ：random access memory）１４、読み取り専用メモリ（ＲＯＭ：read-only memory）１６、および入出力（Ｉ／Ｏ：input/output）アダプタ１８に相互接続されている。入出力アダプタ１８は、ディスク装置１１および磁気テープ・ドライブ１３などの周辺装置またはシステムによって読み取り可能なその他のプログラム記憶装置に接続することができる。このシステムは、プログラム記憶装置上の発明に関する命令を読み取り、これらの命令に従って本発明の諸実施形態の方法を実行することができる。このシステムは、ユーザ入力を収集するために、キーボード１５、マウス１７、スピーカ２４、マイクロホン２２、またはタッチスクリーン装置（図示せず）などのその他のユーザ・インターフェース装置をバス１２に接続するユーザ・インターフェース・アダプタ１９をさらに含む。さらに、通信アダプタ２０はバス１２をデータ処理ネットワーク２５に接続し、ディスプレイ・アダプタ２１は、たとえば、モニタ、プリンタ、または送信機などの出力装置として実施可能なディスプレイ装置２３にバス１２を接続する。
【００４７】
本発明の諸実施形態によって提供される認可技法は、新しいコードを作成せずに認可要件を満たすための方法を提供し、新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。さらに、本発明の諸実施形態は、多様な認可要件をＸＭＬフォーマットで表し、オブジェクト制約ロジックを使用して認可のためにオブジェクト・グループを構文解析して生成し、環境変数を認可パラメータとして追加し、認証済みプリンシパル間の関係を定義し、同じ認可ポリシー・プロバイダを使用して多様なクラスの認可ポリシーを実装し、配置時にアクションをグループ化するための技法を提供する。本発明の諸実施形態は、Ｊ２ＥＥ（Ｒ）／非Ｊ２ＥＥ（Ｒ）環境のすべてのＪａｖａ（Ｒ）アプリケーションに有用である。その上、本明細書に記載した環境は、すべてのＪ２ＥＥ（Ｒ）／非Ｊ２ＥＥ（Ｒ）アプリケーションに適用される。
【図面の簡単な説明】
【００４８】
【図１】Ｊａｖａ（Ｒ）用の典型的なポリシー・ファイルを示す図である。
【図２】ＡｃｃｅｓｓＣｏｎｔｒｏｌｌｅｒを使用してＪａｖａ（Ｒ）メソッドを保護するための典型的なコードを示す図である。
【図３】ＪＡＡＳにおけるプリンシパル・ベースの認可のための典型的なポリシーを示す図である。
【図４】本発明の一実施形態によりＧｅｎｅｒｉｃＰｅｒｍｉｓｓｉｏｎを使用する保護メソッドのための疑似コードを示す図である。
【図５】本発明の一実施形態による汎用認可における認可ポリシーを示す図である。
【図６】本発明の一実施形態の好ましい方法を例示する流れ図である。
【図７】本発明の他の一実施形態の好ましい方法を例示する流れ図である。
【図８】本発明の他の態様の好ましい方法を例示する流れ図である。
【図９】本発明の一実施形態によるシステム・ブロック図である。
【図１０】本発明の一実施形態によるコンピュータ・システム図である。
【特許請求の範囲】
【請求項１】
ソフトウェア・オブジェクトおよびアプリケーションのいずれかによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法において、前記方法が、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクトにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する方法。
【請求項２】
前記生成ステップにおいて、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項１に記載の方法。
【請求項３】
前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項１に記載の方法。
【請求項４】
前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項３に記載の方法。
【請求項５】
前記アプリケーション・オブジェクト・グループに関連するメソッドおよびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項１に記載の方法。
【請求項６】
すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項１に記載の方法。
【請求項７】
前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項１に記載の方法。
【請求項８】
同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項１に記載の方法。
【請求項９】
ソフトウェア・アプリケーションへのアクセスを制御する方法において、前記方法が、グループ化パラメータにより前記ソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップと、前記アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップと、前記グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップと、前記ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関する前記ユーザ・プロファイルと前記認可ポリシーとを突き合わせるステップとを有する方法。
【請求項１０】
前記グループ化ステップにおいて、前記ソフトウェア・アプリケーションが前記アプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項９に記載の方法。
【請求項１１】
前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項９に記載の方法。
【請求項１２】
前記環境変数の宣言指定を変更し、前記アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項１１に記載の方法。
【請求項１３】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項９に記載の方法。
【請求項１４】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係を使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項９に記載の方法。
【請求項１５】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記ソフトウェア・アプリケーションを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項９に記載の方法。
【請求項１６】
同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項９に記載の方法。
【請求項１７】
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立するためのシステムにおいて、前記システムが、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するための手段と、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するための手段と、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するための手段と、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについて前記ソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するための手段とを有するシステム。
【請求項１８】
ソフトウェア・オブジェクトへのアクセスを制御するためのシステムにおいて、前記システムが、少なくとも１つのアプリケーション・オブジェクト・グループを有するアプリケーション・オブジェクト記述ドキュメントと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するように適合された認可ポリシー分類器と、前記ソフトウェア・オブジェクトの配置時に前記認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてアクセス制御パラメータを確立するように適合されたアクセス・コントローラとを有するシステム。
【請求項１９】
前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項１８に記載のシステム。
【請求項２０】
前記認可ポリシーが環境変数を有する、請求項１８に記載のシステム。
【請求項２１】
前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するように適合されたジェネレータ・ルーチンをさらに有する、請求項２０に記載のシステム。
【請求項２２】
前記アプリケーション・オブジェクト・グループが、前記アプリケーション・オブジェクト・グループに関連するメソッドおよびフィールド・パラメータのいずれかを使用して指定される、請求項１８に記載のシステム。
【請求項２３】
前記アプリケーション・オブジェクト・グループが、すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して指定される、請求項１８に記載のシステム。
【請求項２４】
前記アプリケーション・オブジェクト・グループが、前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して指定される、請求項１８に記載のシステム。
【請求項２５】
前記認可ポリシー分類器が、多様なクラスの認可ポリシーを実装するように適合される、請求項１８に記載のシステム。
【請求項２６】
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を実行するためにコンピュータによって実行可能な複数命令からなるプログラムを具体的に実施する、コンピュータによって読み取り可能なプログラム記憶装置において、前記方法が、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについて前記ソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する、プログラム記憶装置。
【請求項２７】
前記生成ステップにおいて、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項２６に記載のプログラム記憶装置。
【請求項２８】
前記方法が、前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項２９】
前記方法が、前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項２８に記載のプログラム記憶装置。
【請求項３０】
前記方法が、前記アプリケーション・オブジェクト・グループに関連するプログラム記憶装置およびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項３１】
前記方法が、すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項３２】
前記方法が、前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項３３】
前記方法が、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項１】
ソフトウェア・オブジェクトおよびアプリケーションのいずれかによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法において、前記方法が、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクトにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する方法。
【請求項２】
前記生成ステップにおいて、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項１に記載の方法。
【請求項３】
前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項１に記載の方法。
【請求項４】
前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項３に記載の方法。
【請求項５】
前記アプリケーション・オブジェクト・グループに関連するメソッドおよびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項１に記載の方法。
【請求項６】
すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項１に記載の方法。
【請求項７】
前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項１に記載の方法。
【請求項８】
同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項１に記載の方法。
【請求項９】
ソフトウェア・アプリケーションへのアクセスを制御する方法において、前記方法が、グループ化パラメータにより前記ソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップと、前記アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップと、前記グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップと、前記ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関する前記ユーザ・プロファイルと前記認可ポリシーとを突き合わせるステップとを有する方法。
【請求項１０】
前記グループ化ステップにおいて、前記ソフトウェア・アプリケーションが前記アプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項９に記載の方法。
【請求項１１】
前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項９に記載の方法。
【請求項１２】
前記環境変数の宣言指定を変更し、前記アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項１１に記載の方法。
【請求項１３】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項９に記載の方法。
【請求項１４】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係を使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項９に記載の方法。
【請求項１５】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記ソフトウェア・アプリケーションを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項９に記載の方法。
【請求項１６】
同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項９に記載の方法。
【請求項１７】
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立するためのシステムにおいて、前記システムが、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するための手段と、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するための手段と、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するための手段と、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについて前記ソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するための手段とを有するシステム。
【請求項１８】
ソフトウェア・オブジェクトへのアクセスを制御するためのシステムにおいて、前記システムが、少なくとも１つのアプリケーション・オブジェクト・グループを有するアプリケーション・オブジェクト記述ドキュメントと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するように適合された認可ポリシー分類器と、前記ソフトウェア・オブジェクトの配置時に前記認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてアクセス制御パラメータを確立するように適合されたアクセス・コントローラとを有するシステム。
【請求項１９】
前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項１８に記載のシステム。
【請求項２０】
前記認可ポリシーが環境変数を有する、請求項１８に記載のシステム。
【請求項２１】
前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するように適合されたジェネレータ・ルーチンをさらに有する、請求項２０に記載のシステム。
【請求項２２】
前記アプリケーション・オブジェクト・グループが、前記アプリケーション・オブジェクト・グループに関連するメソッドおよびフィールド・パラメータのいずれかを使用して指定される、請求項１８に記載のシステム。
【請求項２３】
前記アプリケーション・オブジェクト・グループが、すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して指定される、請求項１８に記載のシステム。
【請求項２４】
前記アプリケーション・オブジェクト・グループが、前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して指定される、請求項１８に記載のシステム。
【請求項２５】
前記認可ポリシー分類器が、多様なクラスの認可ポリシーを実装するように適合される、請求項１８に記載のシステム。
【請求項２６】
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を実行するためにコンピュータによって実行可能な複数命令からなるプログラムを具体的に実施する、コンピュータによって読み取り可能なプログラム記憶装置において、前記方法が、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも１つのアプリケーション・オブジェクト・グループを生成するステップと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについて前記ソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する、プログラム記憶装置。
【請求項２７】
前記生成ステップにおいて、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語（ＸＭＬ）フォーマットを有する、請求項２６に記載のプログラム記憶装置。
【請求項２８】
前記方法が、前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項２９】
前記方法が、前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項２８に記載のプログラム記憶装置。
【請求項３０】
前記方法が、前記アプリケーション・オブジェクト・グループに関連するプログラム記憶装置およびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項３１】
前記方法が、すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項３２】
前記方法が、前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも１つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【請求項３３】
前記方法が、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項２６に記載のプログラム記憶装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【公表番号】特表２００８−５０８５８３（Ｐ２００８−５０８５８３Ａ）
【公表日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願番号】特願２００７−５２３０５７（Ｐ２００７−５２３０５７）
【出願日】平成１７年７月１３日（２００５．７．１３）
【国際出願番号】ＰＣＴ／ＥＰ２００５／０５３３４７
【国際公開番号】ＷＯ２００６／０１０７０７
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
【公表日】平成２０年３月２１日（２００８．３．２１）
【国際特許分類】
【出願日】平成１７年７月１３日（２００５．７．１３）
【国際出願番号】ＰＣＴ／ＥＰ２００５／０５３３４７
【国際公開番号】ＷＯ２００６／０１０７０７
【国際公開日】平成１８年２月２日（２００６．２．２）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ ＢＵＳＩＮＥＳＳ ＭＡＳＣＨＩＮＥＳ ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】
[ Back to top ]