Notice: Undefined variable: fterm_desc_sub in /mnt/www/biblio_conv.php on line 353
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法、システム、およびプログラム記憶装置
説明

ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法、システム、およびプログラム記憶装置

【課題】 ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法、システム、およびプログラム記憶装置を提供することにある。
【解決手段】 この方法は、データ・プロセッサ上で実行されたXMLフォーマットを有するアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、認可ポリシーを変更するステップと、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップと、グループ化パラメータを使用してアプリケーション・オブジェクト・グループを指定するステップとをさらに有する。

【発明の詳細な説明】
【技術分野】
【0001】
本発明の諸実施形態は、一般に、ソフトウェア・アプリケーション開発に関し、詳細には、Java(R)ベースのセキュリティおよび認可ソフトウェア・アプリケーション開発システムおよび方法に関する。
【背景技術】
【0002】
セキュリティおよび認可は、ソフトウェア・システムの開発、配置、および機能において非常に重要な役割を果たしている。米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能なJava(R)は、コンポーネントベースのソフトウェアおよびシステムのための最も普及しているプラットフォームである。その上、Java(R)セキュリティは、eコマース・エンタープライズ・システムにおいて重要な役割を果たしている。セキュリティ機能は、典型的には、臨時にアプリケーション内に組み込まれるか、または米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能であり、コンテナ管理の認証および認可を使用するアプリケーションであるエンタープライズJ2EE(R)(Java(R)2 Platform Enterprise Edition)と統合される。このような状況には、いくつかの理由がある。第一に、セキュリティはアプリケーションのほぼすべてのコンポーネントによって処理されなければならないが、ソフトウェア開発におけるその統合は集中化されていない。第二に、きめの粗い(granular)セキュリティを開発するための標準的で使いやすいプロセスが欠如している。J2EE(R)システムでは、コンテナは、多くの状況には十分ではない可能性のあるメソッドレベルのセキュリティと役割ベースのアクセス制御を提供する。全体的に、低レベルのセキュリティ開発により、セキュリティ実装が厳正で、アプリケーションに緊密に結合されたものになる。
【0003】
Java(R)認証・承認サービス(JAAS:JavaAuthentication and Authorization Service)は、ユーザに関するアクセス制御を認証し執行するためのサービスを使用可能にするJava(R)パッケージである。換言すれば、JAASは、(1)Java(R)コードがアプリケーション、アプレット、Bean、またはサーブレットとして実行されているかどうかにかかわらず、現在、誰がそのコードを実行しているかを確実かつ安全に判断するためのユーザの認証のため、ならびに(2)Java(R)コードがアプリケーション、アプレット、Bean、またはサーブレットとして実行されているかどうかにかかわらず、認証済みユーザがリソース(Java(R)コードまたはJava(R)コードによってアクセスされる何らかのオブジェクト/エンティティにすることができる)にアクセスできるかどうかを判断するためのユーザの認可のためという2つの目的に使用できる1組のJava(R)アプリケーション・プログラム・インターフェース(API:Application Program Interface)である。典型的には、JAAS認証は、プラグ可能なやり方で実行される。これにより、Java(R)アプリケーションは、基礎となる認証技術から独立した状態で存続することができる。その上、アプリケーション自体の変更を必要とせずに、新しい技術または更新された技術をプラグ接続することができる。
【0004】
Java(R)では、バイトコード・ベリファイヤ(byte-code verifier)、クラス・ローダ(class loader)、およびセキュリティ・マネージャ(security manager)という3タイプの防衛メカニズムを使用する。Java(R)バージョン1.0では、アプレットが「サンドボックス(sandbox)」内で動作し、それにより、アプレットが実行されるマシンに影響を及ぼすか、またはそこから任意の機密情報を入手するために、アプレットの能力を制限する。このため、ローカルにアクセスできるものは非常に少ない。Java(R)のその後のバージョンでは、それを実行しているマシンが署名情報に基づいてそのように実行することを許可する場合、アプレットはサンドボックスを脱出することができる。柔軟できめ細かいアクセス制御をサポートするために、Java(R)バージョン1.2は、ポリシー・ベースのセキュリティ・アーキテクチャを提供する。ポリシーは、様々な位置の様々な署名者によるコードに関する1組のパーミッション(permission)によって定義される。パーミッションにより、特定のリソースに関する特定のアクションへのアクセスが可能になる。通常、リソース名およびその関連アクションは、ポリシー・ファイルに列挙される。図1は、Java(R)の典型的なポリシー・ファイルを例示している。
【0005】
Java(R)バージョン2では、SecurityManagerによって以前提供された2つの機能、すなわち、セキュリティ・ポリシーの確立とセキュリティ・ポリシーの実施が分離されている。java.security.Policy抽象クラスはセキュリティ・ポリシーを確立するために使用され、AccessControllerはセキュリティ執行者(security enforcer)として使用される。後方互換性のために、SecurityManagerクラスは依然として存在するが、これはその決定のためにAccessControllerを参照する。java.policyでは、パーミッションはコードソースに関連付けられる。このため、それは、ユーザまたは役割ベースのパーミッションを備えていない。図2は、AccessControllerを使用するJava(R)メソッドを保護するための典型的なコードを例示している。図2に例示されている例は、リソースにアクセスする前にAccessControllerを呼び出すことにより、どのようにリソースが保護されるかを示している。AccessControllerは、アプリケーションの現行認可ポリシーによって要求された許可をチェックする。ポリシー・ファイルに定義されたパーミッションが要求されたパーミッションを暗示する場合、メソッドの「checkPermission」コマンドが単純に戻り、さもなければ、AccessControlExceptionが開始される。
【0006】
前述の通り、JAASは、ユーザに関するアクセス制御を認証し執行するためのサービスを使用可能にする1組のAPIである。JAASは、現在、誰がJava(R)コードを実行しているか、ならびにそのように実行することを許可されているかどうかを確実かつ安全に判断する。その上、JAASは、標準的なプラグ可能認証モジュール(PAM:Pluggable Authentication Module)フレームワークのJava(R)技術バージョンを実装するものである。これにより、Java(R)アプリケーションは、基礎となる認証メカニズムから独立した状態で存続することができる。
【0007】
JAASは、2つの主要コンポーネント、すなわち、認証(authentication)および認可(authorization)を含む。JAASは、Java(R)バージョン2のセキュリティ・モデルにサブジェクト・ベースのポリシーを追加する。パーミッションは、CodeSourceに基づくだけでなく、コードを実行しているユーザにも基づいて付与される。この場合、ユーザは先に認証される。JAAS配布は、ユーザからユーザIDおよびパスワードを取得するための様々なLoginModule実装を含む。LoginContextは、認証のためにどのLoginModuleを使用すべきかを判断するためにログイン構成ファイルを使用する。Subjectクラスは、認証済みユーザの資格情報をカプセル化するために使用される。サブジェクトは、プリンシパル(principal)と呼ばれる複数のIDを有することができる。JAASポリシー・ファイル内の各grant文はプリンシパルに関連付けられている。サブジェクトに関連する各プリンシパルごとに、AccessControllerは、PolicyFileからパーミッションを入手し、任意のパーミッションが要求されたパーミッションを暗示するかどうかをチェックする。さもなければ、AccessControllerは、AccessControlExceptionを開始する。図3は、JAAS内のプリンシパル・ベースの認可に関する典型的なポリシーを例示している。
【0008】
J2EE(R)アーキテクチャでは、コンテナは、それがホストとして処理するコンポーネントとその呼び出し側との間の認可境界として機能する。コンテナは、呼び出し側コードのユーザのIDを確立する。呼び出されたコンポーネント、EJB(米国カリフォルニア州サンタクララのサン・マイクロシステムズ社から入手可能なEnterprise JavaBeans(R))、またはWebコンポーネントへのアクセスは、呼び出し側のセキュリティ属性を、呼び出されたコンポーネントにアクセスするために必要なものと比較することによって決定される。宣言認可(declarative authorization)では、デプロイヤ(deployer)は、J2EE(R)アプリケーションに関するコンテナ執行のアクセス制御ルールを確立する。デプロイヤは、典型的にはアプリケーション・アセンブラによって供給されたアプリケーション・パーミッション・モデルをランタイム環境に特有のメカニズムにマッピングする。配置記述子(deployment descriptor)は、様々なコンポーネントに関するセキュリティ役割とそれに関連するアクセス権を定義する。デプロイヤは、ランタイム環境内のユーザのアクセス権を確立するために、特定の呼び出し側にセキュリティ役割を割り当てる。たとえば、デプロイヤは、セキュリティ役割を動作環境内のプリンシパルIDのリストにマッピングすることができる。その場合、これらのIDの1つで認証された呼び出し側には、役割によって表される特権が割り当てられる。J2EE(R)コンテナは、コンポーネントへのディスパッチング・メソッド呼び出しの前にアクセス制御決定を行う。したがって、宣言アクセス制御は、メソッドの細分性によって割り当てることができる。
【0009】
J2EE(R)コンテナは、これらのアクセス決定におけるコンポーネントのロジックまたは状態を考慮に入れない。これを実行するために、コード開発者がプログラムによる認可(programmatic authorization)を実行する必要がある。コンポーネントは、きめ細かいアクセス制御を実行するために、EJBContext.isCallerInRole(EJBコンポーネントの場合)およびHttpServletRequest.isUserInRole(Webコンポーネントの場合)という2つのメソッドを使用することができる。コンポーネントは、これらのメソッドを使用して、呼び出しのパラメータ、コンポーネントの内部状態、またはランタイム・パラメータなどのその他の要因に基づいて、コンポーネントによって選択された特権が呼び出し側に付与されているかどうかを判断する。しかし、宣言認可とプログラマチック認可との間にはトレードオフが存在する。宣言認可はデプロイヤによって構成された外部アクセス制御ポリシーであり、プログラマチック認可はコンポーネント開発者によってアプリケーションに埋め込まれた内部ポリシーによるものである。内部ポリシーはよりきめ細かいものであり、外部ポリシーはより柔軟なものである。その上、外部ポリシーは透過性であり、内部ポリシーはアプリケーションに埋め込まれる。たとえば、「従業員は自分自身の給与情報のみにアクセスできる」という認可ポリシーを提供するためには、必要であれば、将来変更できないプログラムによる認可が必要である。
【0010】
その上、JAASは、Java(R)の既存のセキュリティ・モデルの上に構築され、それはCodeSourceベースのものであり、プレーンテキスト・フォーマットのポリシー・ファイル実装である。JAASは、特定のコンポーネントによってアクセスされるクラスに基づく認可を実装する。しかし、これは、エンタープライズ・アプリケーションには十分ではない可能性があり、それにより、JAASとともに、LDAP(軽量ディレクトリ・アクセス・プロトコル(Lightweight Directory Access Protocol))などのカスタム・セキュリティ・リポジトリを使用する必要がある場合もある。さらに、企業間(business-to-business)の電子商取引における価格設定契約は、他の契約とは異なるアクセス制御ポリシーを有する場合もある。セルフサービス・オークション・アプリケーションに関する指定は、「登録済みユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件を有する可能性もある。したがって、多くのJava(R)アプリケーションは、その認可要件を満足するためにJAASを拡張する必要がある。JAASの諸機能はプラグ可能であるので、JAASのデフォルト動作を変更するために様々な認証および認可サブモジュールについて自分専用の実装例を作成することができる。上記の例に例示されている認可要件の場合、以下の1つまたは複数のデフォルト実装を変更する必要がある場合もある。
・java.security.Permission: 呼び出されたCodeSourceについてアクションを実行するための権限を呼び出し側が有するかどうかを判断するために、AccessController.checkPermission(Permission perm)が呼び出される。パーミッション・オブジェクトpermは、リソースへの必要なアクセスを表している。パーミッション・オブジェクトは、パーミッションの名前(アクセスが必要なリソースを示す可能性がある)、リソースがアクセスされるアクションなどの項目を指定することができる。パーミッション・クラスは、付与されたパーミッションが要求されたパーミッションを暗示するかどうかを判断するために、AccessControllerによって呼び出される暗黙のメソッドを実装する。クラス・インスタンス・レベル認可を実装するために、そのフィールドの1つとしてオブジェクト・インスタンスを有するパーミッションの新しい実装を有する必要がある。そのオブジェクトは、認可を決定するために暗黙のメソッドで使用することができる。
・java.security.PermissionCollection: この抽象クラスは、パーミッション・オブジェクトの集合を表すために使用される。このクラスは、付与されたパーミッションを保管し、それを要求されたパーミッションと比較して、付与されたパーミッションのいずれかが要求されたパーミッションを暗示するかどうかを判断する所望のやり方を備えるために実装することができる。
・java.security.Policy: これは、Java(R)アプリケーション環境においてセキュリティ・ポリシーを保管するための抽象クラスである。AccessControllerは、CodeSource上の認証済みサブジェクトに関するパーミッションを入手するためにポリシー実装に連絡する。ポリシー・オブジェクトは、そのポリシー指定を調べ、許可されるパーミッションを列挙する適切なPermissionCollectionオブジェクトを返す。デフォルトでは、sun.security.provider.PolicyFile実装がポリシー実装に使用される。異なる実装を有することにより、ポリシーが作成される方法(たとえば、LDAPまたはソフトウェア・アプリケーション)または認可が依存する追加のパラメータを変更することができる。
・javax.security.auth.spi.LoginModule: LoginModuleは、認証プロバイダによって実装されたインターフェースを記述する。これは、デフォルトでは何らかのユーザ対話を実行するコールバックからユーザ名およびパスワード(複数も可)を検索する。LoginModuleは、認証を何らかの外部アダプタに委任するよう、拡張することができる。
・java.security.Principal: Principalインターフェースは、個人、組織、グループ、またはログインIDなどのエンティティを表すために使用される抽象概念を表す。Group、KerberosPrincipalなどは、Principalの周知の実装例である。Principalを拡張することにより、認可に使用すべきカスタム・プロパティを追加することができる。
【0011】
しかし、JAASの制限の1つは、それがクラス・インスタンス・レベル認可をサポートしないことであり、すなわち、JAAS内の認可は、クラスの特定のインスタンスを基礎として実行されるのではなく、クラス名を基礎として実行される。たとえば、Webベースのセルフサービス・オークション・アプリケーションに関する指定は、「登録済み(認証済み)ユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件を有する可能性がある。これは、どのユーザもオークション・クラス・インスタンスを作成するために作成されたコードを実行することができるが、そのインスタンスを所有するユーザのみが、それを変更するために設計されたコードを実行できることを意味する。通常、オークション・インスタンスを作成したユーザは所有者になる。これにより、同じ役割の人は、その属性または過去に実行したアクションに基づいて異なるアクセス権を有する可能性があることが暗示される。残念ながら、このタイプの認可は、JAASを使用してサポートすることができない。
【0012】
JAAS認可は、どのアクセス権が実行中のコードに付与されるかを指定するためにセキュリティ・ポリシーを使用する既存のJava(R)セキュリティ・アーキテクチャを拡張する。Java(R)バージョン2のプラットフォームで提供される、このセキュリティ・アーキテクチャはコード中心である。すなわち、パーミッションはコード特性、すなわち、コードがどこから来るか、それがデジタル署名されるかどうか、そうである場合に、誰によって署名されるかに基づいて付与される。JAASをJava(R)2のSDK(ソフトウェア開発キット(Software Development Kit))に統合することにより、java.security.Policy APIはプリンシパルベースの照会を処理し、デフォルトのポリシー実装はプリンシパルベースの付与項目をサポートする。したがって、アクセス制御は、どのコードが実行されているか、ならびに誰がコードを実行しているかに基づくものになる可能性がある。
【0013】
JAASは、インスタンス・レベルJAASをサポートするためのメカニズムを提供する。これは、JAASによって使用されるクラスのいくつかを拡張することによって実施される。しかし、この手法の主な欠点は、それが拡張可能ではなく、異なるドメインで異なる種類の認可を提供する場合に新しい認可クラスの作成と相当な量の手直しを必要とすることである。インスタンス・レベル認可をサポートするためのもう1つのオプションは、アプリケーションの一部としてコーディングされるカスタム認可コードを使用することである。一般に、これは、認可技法をサポートするために最も広く使用される方法であり、その主要な欠点は、それが標準に基づくものではなく、異なるアプリケーションで適用することをより難しくしていることである。さらに、このコードはアプリケーションの一部であるので保守が難しく、それが非汎用であるので一般に異なるドメインで再利用することができない。
【発明の開示】
【発明が解決しようとする課題】
【0014】
したがって、従来の手法の欠点および制限のために、新しいコードを必要とせずに異なるドメインに適用できる、より普遍的に適用可能なJAASベースの認可ソリューションの必要性が残っている。新しい認可要件に関する新しいコードを作成すると、配置時に認可設定を変更することが難しくなる。したがって、プログラマチック認可の高細分性とともに宣言認可の柔軟性が必要である。
【課題を解決するための手段】
【0015】
上記を考慮すると、本発明の一実施形態は、ソフトウェア・オブジェクトおよびアプリケーションのいずれかによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を提供し、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクトをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクトにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。生成ステップにおいて、アプリケーション・オブジェクト記述ドキュメントは、拡張可能マークアップ言語(XML:eXtensible Markup Language)フォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、認可ポリシーを変更するステップとをさらに有する。さらに、この方法は、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか(およびこれらのメソッドおよびフィールド・パラメータに関する定義制約)、すべてのアプリケーション・オブジェクト・グループ間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクト・グループを指定するステップをさらに有する。その上、この方法は、同じ認可ポリシー分類器(classifier)を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【0016】
本発明の他の実施形態は、ソフトウェア・アプリケーションへのアクセスを制御する方法を提供し、この方法は、グループ化パラメータによりソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップと、アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップと、グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップと、ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関するユーザ・プロファイルと認可ポリシーとを突き合わせるステップとを有し、グループ化ステップにおいて、ソフトウェア・アプリケーションがアプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、アプリケーション・オブジェクト記述ドキュメントがXMLフォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定およびグループ化制約を変更することにより、認可ポリシーを変更するステップとをさらに有する。グループ化ステップにおいて、このグループ化パラメータは、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係、またはソフトウェア・アプリケーション/オブジェクトによって表されるリソース、データ、またはコードを少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクトを指定するステップを有する。この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【0017】
本発明の他の態様は、ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立するためのシステムを提供し、このシステムは、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するための手段と、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するための手段と、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するための手段と、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するための手段とを有する。
【0018】
本発明の他の実施形態は、ソフトウェア・オブジェクトへのアクセスを制御するためのシステムを提供し、このシステムは、少なくとも1つのアプリケーション・オブジェクト・グループを有するアプリケーション・オブジェクト記述ドキュメントと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するように適合された認可ポリシー分類器(classifier)と、ソフトウェア・オブジェクトの配置時に認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてアクセス制御パラメータを確立するように適合されたアクセス・コントローラとを有し、アプリケーション・オブジェクト記述ドキュメントがXMLフォーマットを有し、認可ポリシーが環境変数を有する。このシステムは、環境変数の宣言指定およびグループ化ルールを変更することにより、認可ポリシーを変更するように適合されたジェネレータ・ルーチンをさらに有する。このシステムによれば、アプリケーション・オブジェクト・グループは、ユーザ選択のアプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して指定される。その上、認可ポリシー分類器は、多様なクラスの認可ポリシーを実装するように適合される。
【0019】
さらに、本発明の他の態様は、ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を実行するためにコンピュータによって実行可能な複数命令からなるプログラムを具体的に実施する、コンピュータによって読み取り可能なプログラム記憶装置を提供し、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するステップと、各アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する。
【0020】
本発明の諸実施形態により提供される認可技法は、新しいコードを作成せずに認可要件を満たす方法を提供し、新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。さらに、本発明の諸実施形態は、多様な認可要件をXMLフォーマットで表し、オブジェクト制約ロジックを使用して認可のためのオブジェクト・グループを構文解析して生成し、認可パラメータとして環境変数を追加し、認証済みプリンシパル間の関係を定義し、同じ認可ポリシー・プロバイダを使用して、多様なクラスの認可ポリシーを実装し、配置時にアクションをグループ化するための技法を提供する。
【0021】
本発明の諸実施形態の上記その他の諸態様は、以下の説明および添付図面に併せて考慮したときに、より十分に認識され理解されるであろう。しかし、以下の説明は、本発明の好ましい諸実施形態およびその数多くの特定の詳細を示しており、制限としてではなく、例示として示されていることを理解されたい。
【0022】
本発明の諸実施形態は、図面に関して以下の詳細な説明からより十分に理解されるであろう。
【発明を実施するための最良の形態】
【0023】
添付図面に例示され、以下の説明に詳述されている非制限的諸実施形態に関して、本発明の諸実施形態ならびにその様々な特徴および有利な詳細をより完全に説明する。図面に例示されている特徴は必ずしも一定の縮尺で描かれていないことに留意されたい。本発明の諸実施形態を不必要に不明確にしないために、周知のコンポーネントおよび処理技法の説明は省略されている。本明細書で使用される例は、単に本発明の諸実施形態を実施できる方法の理解を容易にするためのものであり、さらに当業者が本発明の諸実施形態を実施できるようにするためのものである。したがって、この例は、本発明の諸実施形態の範囲を制限するものと解釈してはならない。
【0024】
前述の通り、認可セットアップに対する大幅な変更を必要とせずに異なるドメインに適用できる、より普遍的に適用可能なJava(R)ベースのソフトウェア・アプリケーション開発技法の必要性が残っている。本発明の諸実施形態は、JAAS標準に基づいてJava(R)アプリケーションに対し汎用性で低レベルで拡張可能なセキュリティを提供することにより、この必要性に対処する。次に図面を参照し、詳細には図4〜図10を参照すると、本発明の好ましい諸実施形態が図示されている。
【0025】
上述の通り、JAASは、様々な認証および認可目標を達成するために様々な方法で拡張することができる。しかし、様々な拡張について、様々なJAASインターフェースおよびクラスをそれぞれ実装または拡張するためのコードを作成する必要がある場合がある。このため、アプリケーションの配置時にセキュリティ設定を変更することが難しくなる。したがって、本発明の諸実施形態によって提供される汎用認可技法は、プログラマチック認可の高細分性を保持しながら宣言認可を使用することにより、この柔軟性を達成する。
【0026】
したがって、本発明の諸実施形態によって提供される認可技法は、宣言指定を使用するプログラマチック認可の諸機能を提供する。具体的には、本発明の諸実施形態は、プログラマチックではなく宣言的に認可要件を満たすことができるようにJAASを拡張する。認証および認可を使用して保護する必要がある各メソッドは、そのメソッドが属すクラス、そのメソッドが実行する必要があるアクション、およびそのメソッドが呼び出されるオブジェクトという少なくとも3つのパラメータを有するGenericPermissionオブジェクトのコンストラクタへの呼び出しから始まる。図4は、上述の通り、本発明の一態様によりGenericPermissionを使用する保護メソッドのための疑似コードを例示している。
【0027】
図5に例示されている通り、認可ポリシーはXMLフォーマットで表現することができる。たとえば、図5に図示されている通り、「登録済みユーザはオークションを作成することができるが、そのオークションを作成したユーザのみがそれを変更することができる」という要件に関する認可ポリシーが作成される。同様に、異なる価格設定契約について異なる認可ポリシーを備えて、パーミッションは、{idname=“getContractID”, idtype=“method”, idvalue=“ibm−sun”}パラメータに基づくものである。
【0028】
汎用認可の場合、JDKは、適正な認可ポリシー・プロバイダのために構成される。これは、Java_home/jre/lib/securityディレクトリのJava.securityファイル内のauth.policy.providerを変更/追加することによって実施され、Java_homeはJava(R)がシステム内にインストールされるパスである。汎用認可は多種多様な認可ポリシーを包含するので、それぞれがそれ専用の認可要件を有するいくつかのアプリケーションについて1つの認可ポリシー・プロバイダしか存在できないという制限がある場合でも、各アプリケーションごとに別々のコードを作成する必要なしに同じマシン上で実行することができる。
【0029】
図6は、ソフトウェア・オブジェクト/アプリケーションによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を例示しており、この方法は、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するステップ(101)と、各アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップ(103)と、ユーザ選択のアプリケーション・オブジェクトをシステム200のアクセス・コントローラ208(図9に図示されている)に送信するステップ(105)と、認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップ(107)とを有する。生成ステップ(101)において、アプリケーション・オブジェクト記述ドキュメントは、XMLフォーマットを有する。この方法は、認可ポリシーに関する環境変数を指定するステップと、環境変数の宣言指定を変更することにより、認可ポリシーを変更するステップとをさらに有する。さらに、この方法は、選択されたアプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト・グループ間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメントを少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクト・グループを指定するステップをさらに有する。その上、この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【0030】
本発明の他の実施形態は図7に例示されており、同図は、ソフトウェア・オブジェクト/アプリケーションによって表されるリソース、データ、またはコードへのアクセスを制御する方法を例示し、この方法は、オブジェクト・メソッド呼び出し結果、オブジェクト・フィールド値、および環境変数のうちの1つまたは複数を有するグループ化パラメータによりソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップ(111)と、アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップ(113)と、グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップ(115)と、ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関するユーザ・プロファイルと認可ポリシーとを突き合わせるステップ(117)とを有し、グループ化ステップ(111)において、ソフトウェア・アプリケーションはアプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、アプリケーション・オブジェクト記述ドキュメントはXMLフォーマットを有する。
【0031】
さらに、グループ化ステップ(111)において、このグループ化パラメータは、アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれか、ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係、またはユーザ選択のソフトウェア・オブジェクトを少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、アプリケーション・オブジェクトを指定するステップを有する。図8に図示されている通り、この方法は、認可ポリシーに関する環境変数を指定するステップ(119)と、環境変数の宣言指定を変更することにより、認可ポリシーを変更するステップ(121)とをさらに有する。この方法は、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する。
【0032】
認可ポリシーを作成する方法によれば、本発明の諸実施形態により、ポリシーがこれらの変数に依存することができるように、何らかのセキュリティ関連変数および環境変数へのアクセスが可能になる。これにより、「平日にはソフトウェア・アプリケーションへのアクセスを許可し、週末には禁止する」などのポリシーを有することが可能になる。
【0033】
図9は、ソフトウェア・アプリケーションへのアクセスを制御するためのシステム200を例示し、このシステム200は、少なくとも1つのアプリケーション・オブジェクト・グループ204を有するアプリケーション・オブジェクト記述ドキュメント202と、各アプリケーション・オブジェクト・グループ204ごとに認可ポリシーを指定するように適合された認可ポリシー分類器206と、ソフトウェア・アプリケーションの配置時に認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループ204にアクセスしようと試みるユーザ210についてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するように適合されたアクセス・コントローラ208とを有し、アプリケーション・オブジェクト記述ドキュメント202がXMLフォーマットを有し、認可ポリシーが環境変数を有する。
【0034】
このシステムは、環境変数の宣言指定を変更することにより、認可ポリシーを変更するように適合されたジェネレータ・ルーチン212をさらに有する。このシステム200によれば、アプリケーション・オブジェクト・グループ204は、アプリケーション・オブジェクト・グループ204に関連するメソッドおよびフィールド・パラメータのいずれか、すべてのアプリケーション・オブジェクト・グループ204間の所定の関係、またはアプリケーション・オブジェクト記述ドキュメント202を少なくとも1つのアプリケーション・オブジェクト・グループ204に構文解析するための所定のグループ化アクションを使用して指定される。その上、認可ポリシー分類器206は、多様なクラスの認可ポリシーを実装するように適合される。
【0035】
本発明の諸実施形態は、オブジェクト制約ロジック(XMLファイルに作成される)を構文解析し、認可のためのオブジェクト・グループを生成するための技法を提供する。従来、JAASでは、認可ポリシーはクラス(コード)レベルで作成される。逆に、本発明の諸実施形態によれば、認可ポリシーはオブジェクト・グループの細分性で作成される。オブジェクト・グループは、当該オブジェクトのメソッド/フィールドを使用して表される。たとえば、「契約」というクラスが存在すると想定すると、JAASでは、すべての契約が同じ認可プロパティを有することになり、本発明の諸実施形態によって提供される汎用認可では、ユーザは「サン(R)」(サン(R)は米国カリフォルニア州サンタクララのサン・マイクロシステムズ社の登録商標である)との契約を更新できる可能性があるが、「マイクロソフト(R)」(マイクロソフト(R)は米国ワシントン州レドモンドのマイクロソフト社の登録商標である)に関する契約を更新できない可能性がある。JAASでは、アプリケーション・オブジェクトに関する認可は、そのアプリケーション・オブジェクトの特性に依存しない。このため、すべてのアプリケーション・オブジェクトは同じ認可ルールを有する。これを回避するために、従来の手法では、典型的にはカスタム認可が実行される。逆に、本発明の諸実施形態は、個人がJAASを使用してインスタンスレベルの認可(すなわち、データ・オブジェクトの特性に依存する認可)を実行できるようにする技法を提供する。
【0036】
本発明によって提供される方法は、認証済みプリンシパル間の関係を定義する。従来、JAASでは、ユーザが認証されると、そのユーザは「サブジェクト」という型のオブジェクトによって表される。各サブジェクトは、それに関連する複数のプリンシパルを有することができる。これらのプリンシパルは、その個人が有することができる種々のIDを表す。このため、ある個人は、自分の名前(1つのプリンシパルである)または自分の社会保障番号(もう1つのプリンシパルである)によって明確に識別することができる。しかし、本発明の諸実施形態によって提供されるXMLベースの表現を使用して、「ユーザ(認証済みプリンシパル)がオブジェクト(このオブジェクトはリーブ・アプリケーション(leave application)に関するものである可能性がある)の所有者のマネージャである場合、ユーザは承認メソッドを呼び出すことができる」などのポリシーを定義することができる。この場合も、本発明の諸実施形態は個人がJAASを使用してインスタンスレベルの認可(すなわち、データ・オブジェクトの特性に依存する認可)を実行できるようにする技法を提供するので、これは有利である。さらに、これは宣言方式で実行され、プログラマチック認可より柔軟なものである。その上、このセットアップを使用して、認可のためにサブジェクト間の動的関係を使用することができる。この例では、ポリシーは認証済みプリンシパル間の関係(マネージャ)に関して定義される。
【0037】
次に、本発明の諸実施形態は、同じ認可ポリシー・プロバイダを使用して多様なクラスの認可ポリシーを実装できる方法を提供する。認可プロバイダは、java_home/jre/lib/securityのjava.securityファイルに構成される。Java(R)仮想マシン(JVM:Java Virtual Machine)の場合、これは、java.securityファイルのauth.policy.providerというプロパティを変更することによって構成される。汎用認可は多種多様な認可ポリシーを包含するので、1つの認可ポリシー・プロバイダしか存在できないという制限がある場合でも、それぞれがそれ専用の認可要件を有するいくつかのアプリケーションが同じJVM上で実行することができる。本発明の諸実施形態は単一のXML認可ファイルを有するので、このファイルは、異なるアプリケーションについて異なる認可ルールを有することができる。各認可ルールは、そのアプリケーションに特有のアプリケーション・オブジェクトに関して定義されることになる。その上、認可インフラストラクチャは、単一の認可ファイルを使用することになる。このため、同じ認可ポリシー・プロバイダを使用して、多様なクラスの認可ポリシーを実装することができる。
【0038】
本発明の諸実施形態は、配置時にアクションをグループ化するための方法をさらに提供する。異なるアクション・グループについて異なる認可要件を提供するように、アクションをグループ化することができる。配置時に、たとえば、「読み取り」アクションおよび「検索」アクションに同じ認可が使用されることを決定することができる。これは、認可ポリシーが認可XMLファイルに保管されたときに実施される。配置時に、単にXMLを変更することにより、上述のアクションのグループ化を実施することができる。
【0039】
次に、本発明の諸実施形態は、新しいコードを作成する必要なしに認可要件を満たすための方法を提供する。新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。これは、単にXMLを変更することにより、上記の通り、実施される。このため、本発明の諸実施形態は新しいポリシーを提供し、これはコードに対する変更を必要としない。認可要件は、それをアプリケーションと統合するのではなくXMLで表現されるので、(コード変更ではなく)単にXMLを変更することにより、認可設定を変更することができる。本発明の諸実施形態によって提供されるXMLベースのポリシー・ファイルでは、getOwner、getManagerなどの特定の「Java(R)Bean様」メソッドの戻り値を使用して表された特定の特性を有する場合、ユーザ・プリンシパルは、特定のJava(R)オブジェクトへのアクセスを許可される。
【0040】
本発明の諸実施形態は、多様な認可要件をXMLフォーマットで表すための方法をさらに含む。このフォーマットは、Java(R)オブジェクト上の何らかのフィールドおよびメソッド呼び出しを使用してオブジェクトを指定すること、関係を使用してプリンシパルを指定すること、およびグループ化アクションを含む。また、本発明の諸実施形態は、時間、日などの環境変数をXMLフォーマットで表し、これらの変数について認可ポリシーを定義する。XMLフォーマットでオブジェクトを識別するためのいくつかの方法を含むことにより、本発明の諸実施形態は認可設定に関する多種多様なオプションを作成するので、これは特に有利である。これらのオプションとしては、とりわけ、Java(R)オブジェクトに関するフィールド値およびメソッド戻り値、プリンシパルおよびそれらの関係、環境変数を含む。したがって、本発明の諸実施形態は、配置時に認可ポリシーを変更することができ、それにより、JAAS標準を利用することができる。換言すれば、プログラマチック認可を利用せずに、インスタンスレベルの認可によってJAASの利点が入手される。
【0041】
その上、本発明の諸実施形態は、それに関する認可がチェックされるオブジェクトまたはアクセス要求を行っているオブジェクトあるいはその両方の引き渡しを可能にするコンストラクタを有する汎用パーミッション・クラスを提供する。従来、JAASでは、アクセス・コントローラを使用してパーミッションをチェックするためにパーミッション・オブジェクトが必要である。逆に、本発明の一実施形態によって提供される方法によれば、それに関するパーミッションが要求されるオブジェクトがアクセス・コントローラ208に渡されるPermissionオブジェクトのパラメータになるように、GenericPermissionを使用してPermissionクラスが拡張される。したがって、アクセス・コントローラ208は、それに渡されるオブジェクトに基づいて、認可を決定することができる。この態様は、それに関する認可決定が行われるアプリケーション・オブジェクトの特定のインスタンスの特性に基づいて認可ルールを提供するために使用される。前述の通り、JAASでは、認可ポリシーはアプリケーション・オブジェクトのインスタンスから独立しており、ポリシーは同じカテゴリのアプリケーション・オブジェクトのすべてのインスタンスについて同じものである。オブジェクト・インスタンスをパラメータとして取る汎用パーミッション・クラスを使用するという上記の技法を使用して、本発明の諸実施形態は、インスタンスレベルの認可を提供することができる。
【0042】
次に、本発明の諸実施形態は、環境変数の使用を可能にし、リフレクションを使用して動的メソッド呼び出しの表現を可能にし、式、述語論理などの表現を可能にする汎用ポリシー・ファイルを提供する。たとえば、本発明の諸実施形態は、認可要件を作成するためのフォーマットを提供する。このフォーマットは、Java(R)オブジェクト上の何らかのフィールドおよびメソッド呼び出しを使用してオブジェクトを指定すること、関係を使用してプリンシパルを指定すること、およびグループ化アクションを含む。また、本発明の諸実施形態は、時間、日などの環境変数をXMLフォーマットで表し、これらの変数について認可ポリシーを定義する。
【0043】
さらに、本発明の諸実施形態は、汎用ポリシー・ファイルを構文解析し、Generic Policy Fileの構文を理解し、過去のユーザObject、ユーザPrincipal/ユーザSubject、およびユーザ・コードに基づいてGeneric Policy FileからGenericPermissionCollectionを作成する、Policy File実装を提供する。これは、新しいタイプのGenericPermissionクラスを使用することによって実施され、それにより、異なるタイプのポリシー・ファイル実装が使用される。したがって、本発明の諸実施形態は、Generic Policy Fileの一般フォーマットを理解するが、必ずしもポリシー・ファイルに指定されたオブジェクト制約ロジックを理解するわけではない。しかし、この実装は、ポリシー・ファイルを使用してGenericPermissionクラスを作成する。このため、前述のGenericPermissionクラスは、ポリシー・ファイルに指定されたオブジェクト制約ロジックを理解する。
【0044】
したがって、本発明の諸実施形態は、GenericPermissionクラスを利用するが、これは、ポリシー・ファイルを使用し、ポリシー言語の宣言指定を理解し、環境変数の値を取得することができ、式および述語論理を評価し、Java(R)リフレクションを使用してランタイム・パラメータ値を入手する。換言すれば、本発明の諸実施形態は、汎用XMLベースのポリシー・ファイルに作成されたロジックを理解する。
【0045】
さらに、本発明の諸実施形態は、GenericPermissionの集合を保管し、Generic Policy Fileを理解できるGenericPermissionの暗黙のメソッドを呼び出すGenericPermissionCollectionクラスを提供する。一般に、本発明の諸実施形態は、そのオブジェクトをパラメータの1つとして取るパーミッションの汎用集合を定義し、これはJAAS規格に従ってJAAS環境で機能する。具体的には、本発明の諸実施形態は、XMLフォーマットで定義されるアクセス制御または認可を提供するJava(R)ベースのポリシーを提供する。Java(R)に関する認可ポリシーの認可パラメータを定義するために、環境変数はXMLフォーマットで宣言的に指定される。XMLはアプリケーションから独立しており、宣言変数の使用は、クラス、メソッド、およびオブジェクトというJava(R)パラメータをXMLで定義することによって汎用認可を可能にする。いくつかの異なるポリシーはXMLで記述され、ポリシーは環境変数として宣言される。認可ポリシーを変更するために、環境変数の宣言が変更される。その上、各アプリケーションは、異なるポリシーを有することができ、ユーザが特定のユーザ名およびパスワードでログインするときにXMLフォーマットで宣言的に指定することができる。
【0046】
本発明の諸実施形態を実施するための代表的なハードウェア環境は図10に描写されている。この概略図は、本発明の諸実施形態による情報処理/コンピュータ・システムのハードウェア構成を例示している。このシステムは、少なくとも1つのプロセッサまたは中央演算処理装置(CPU:central processing unit)10を有する。CPU10は、システム・バス12を介して、ランダム・アクセス・メモリ(RAM:random access memory)14、読み取り専用メモリ(ROM:read-only memory)16、および入出力(I/O:input/output)アダプタ18に相互接続されている。入出力アダプタ18は、ディスク装置11および磁気テープ・ドライブ13などの周辺装置またはシステムによって読み取り可能なその他のプログラム記憶装置に接続することができる。このシステムは、プログラム記憶装置上の発明に関する命令を読み取り、これらの命令に従って本発明の諸実施形態の方法を実行することができる。このシステムは、ユーザ入力を収集するために、キーボード15、マウス17、スピーカ24、マイクロホン22、またはタッチスクリーン装置(図示せず)などのその他のユーザ・インターフェース装置をバス12に接続するユーザ・インターフェース・アダプタ19をさらに含む。さらに、通信アダプタ20はバス12をデータ処理ネットワーク25に接続し、ディスプレイ・アダプタ21は、たとえば、モニタ、プリンタ、または送信機などの出力装置として実施可能なディスプレイ装置23にバス12を接続する。
【0047】
本発明の諸実施形態によって提供される認可技法は、新しいコードを作成せずに認可要件を満たすための方法を提供し、新しい認可シナリオは、宣言設定を変更することにより、配置時に入手することができる。さらに、本発明の諸実施形態は、多様な認可要件をXMLフォーマットで表し、オブジェクト制約ロジックを使用して認可のためにオブジェクト・グループを構文解析して生成し、環境変数を認可パラメータとして追加し、認証済みプリンシパル間の関係を定義し、同じ認可ポリシー・プロバイダを使用して多様なクラスの認可ポリシーを実装し、配置時にアクションをグループ化するための技法を提供する。本発明の諸実施形態は、J2EE(R)/非J2EE(R)環境のすべてのJava(R)アプリケーションに有用である。その上、本明細書に記載した環境は、すべてのJ2EE(R)/非J2EE(R)アプリケーションに適用される。
【図面の簡単な説明】
【0048】
【図1】Java(R)用の典型的なポリシー・ファイルを示す図である。
【図2】AccessControllerを使用してJava(R)メソッドを保護するための典型的なコードを示す図である。
【図3】JAASにおけるプリンシパル・ベースの認可のための典型的なポリシーを示す図である。
【図4】本発明の一実施形態によりGenericPermissionを使用する保護メソッドのための疑似コードを示す図である。
【図5】本発明の一実施形態による汎用認可における認可ポリシーを示す図である。
【図6】本発明の一実施形態の好ましい方法を例示する流れ図である。
【図7】本発明の他の一実施形態の好ましい方法を例示する流れ図である。
【図8】本発明の他の態様の好ましい方法を例示する流れ図である。
【図9】本発明の一実施形態によるシステム・ブロック図である。
【図10】本発明の一実施形態によるコンピュータ・システム図である。

【特許請求の範囲】
【請求項1】
ソフトウェア・オブジェクトおよびアプリケーションのいずれかによって表されるリソース、データ、またはコードにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法において、前記方法が、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するステップと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを作成するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクトにアクセスしようと試みるユーザについてソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する方法。
【請求項2】
前記生成ステップにおいて、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語(XML)フォーマットを有する、請求項1に記載の方法。
【請求項3】
前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項1に記載の方法。
【請求項4】
前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項3に記載の方法。
【請求項5】
前記アプリケーション・オブジェクト・グループに関連するメソッドおよびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項1に記載の方法。
【請求項6】
すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項1に記載の方法。
【請求項7】
前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項1に記載の方法。
【請求項8】
同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項1に記載の方法。
【請求項9】
ソフトウェア・アプリケーションへのアクセスを制御する方法において、前記方法が、グループ化パラメータにより前記ソフトウェア・アプリケーション内のアプリケーション・オブジェクトをグループ化するステップと、前記アプリケーション・オブジェクトにアクセスする各クラスのユーザごとにユーザ・プロファイルを確立するステップと、前記グループ化されたアプリケーション・オブジェクトのそれぞれに関するアクセス制御パラメータを有する認可ポリシーを指定するステップと、前記ソフトウェア・アプリケーションの配置時に、選択されグループ化されたアプリケーション・オブジェクトにアクセスしようと試みるユーザに関する前記ユーザ・プロファイルと前記認可ポリシーとを突き合わせるステップとを有する方法。
【請求項10】
前記グループ化ステップにおいて、前記ソフトウェア・アプリケーションが前記アプリケーション・オブジェクトを有するアプリケーション・オブジェクト記述ドキュメントを有し、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語(XML)フォーマットを有する、請求項9に記載の方法。
【請求項11】
前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項9に記載の方法。
【請求項12】
前記環境変数の宣言指定を変更し、前記アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項11に記載の方法。
【請求項13】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記アプリケーション・オブジェクトに関連するメソッドおよびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項9に記載の方法。
【請求項14】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記ソフトウェア・アプリケーション内のすべてのアプリケーション・オブジェクト間の所定の関係を使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項9に記載の方法。
【請求項15】
前記グループ化ステップにおいて、前記グループ化パラメータが、前記ソフトウェア・アプリケーションを前記少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクトを指定するステップを有する、請求項9に記載の方法。
【請求項16】
同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項9に記載の方法。
【請求項17】
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立するためのシステムにおいて、前記システムが、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するための手段と、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するための手段と、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するための手段と、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについて前記ソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するための手段とを有するシステム。
【請求項18】
ソフトウェア・オブジェクトへのアクセスを制御するためのシステムにおいて、前記システムが、少なくとも1つのアプリケーション・オブジェクト・グループを有するアプリケーション・オブジェクト記述ドキュメントと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するように適合された認可ポリシー分類器と、前記ソフトウェア・オブジェクトの配置時に前記認可ポリシーに基づいて、選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについてアクセス制御パラメータを確立するように適合されたアクセス・コントローラとを有するシステム。
【請求項19】
前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語(XML)フォーマットを有する、請求項18に記載のシステム。
【請求項20】
前記認可ポリシーが環境変数を有する、請求項18に記載のシステム。
【請求項21】
前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するように適合されたジェネレータ・ルーチンをさらに有する、請求項20に記載のシステム。
【請求項22】
前記アプリケーション・オブジェクト・グループが、前記アプリケーション・オブジェクト・グループに関連するメソッドおよびフィールド・パラメータのいずれかを使用して指定される、請求項18に記載のシステム。
【請求項23】
前記アプリケーション・オブジェクト・グループが、すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して指定される、請求項18に記載のシステム。
【請求項24】
前記アプリケーション・オブジェクト・グループが、前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して指定される、請求項18に記載のシステム。
【請求項25】
前記認可ポリシー分類器が、多様なクラスの認可ポリシーを実装するように適合される、請求項18に記載のシステム。
【請求項26】
ソフトウェア・アプリケーションにアクセスするユーザに関するセキュリティ・ポリシーおよび認可ポリシーを確立する方法を実行するためにコンピュータによって実行可能な複数命令からなるプログラムを具体的に実施する、コンピュータによって読み取り可能なプログラム記憶装置において、前記方法が、データ・プロセッサ上で実行されたアプリケーション・オブジェクト記述ドキュメントから少なくとも1つのアプリケーション・オブジェクト・グループを生成するステップと、それぞれの前記アプリケーション・オブジェクト・グループごとに認可ポリシーを指定するステップと、選択されたアプリケーション・オブジェクト・グループをアクセス・コントローラに送信するステップと、前記認可ポリシーに基づいて、前記選択されたアプリケーション・オブジェクト・グループにアクセスしようと試みるユーザについて前記ソフトウェア・アプリケーションの配置時にアクセス制御パラメータを確立するステップとを有する、プログラム記憶装置。
【請求項27】
前記生成ステップにおいて、前記アプリケーション・オブジェクト記述ドキュメントが拡張可能マークアップ言語(XML)フォーマットを有する、請求項26に記載のプログラム記憶装置。
【請求項28】
前記方法が、前記認可ポリシーに関する環境変数を指定するステップをさらに有する、請求項26に記載のプログラム記憶装置。
【請求項29】
前記方法が、前記環境変数の宣言指定を変更し、アプリケーション・オブジェクトの属性について定義された制約を変更することにより、前記認可ポリシーを変更するステップをさらに有する、請求項28に記載のプログラム記憶装置。
【請求項30】
前記方法が、前記アプリケーション・オブジェクト・グループに関連するプログラム記憶装置およびフィールド・パラメータのいずれかを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項26に記載のプログラム記憶装置。
【請求項31】
前記方法が、すべてのアプリケーション・オブジェクト・グループ間の所定の関係を使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項26に記載のプログラム記憶装置。
【請求項32】
前記方法が、前記アプリケーション・オブジェクト記述ドキュメントを前記少なくとも1つのアプリケーション・オブジェクト・グループに構文解析するための所定のグループ化アクションを使用して、前記アプリケーション・オブジェクト・グループを指定するステップをさらに有する、請求項26に記載のプログラム記憶装置。
【請求項33】
前記方法が、同じ認可ポリシー分類器を使用して、多様なクラスの認可ポリシーを実装するステップをさらに有する、請求項26に記載のプログラム記憶装置。

【図1】
image rotate

【図2】
image rotate

【図3】
image rotate

【図4】
image rotate

【図5】
image rotate

【図6】
image rotate

【図7】
image rotate

【図8】
image rotate

【図9】
image rotate

【図10】
image rotate


【公表番号】特表2008−508583(P2008−508583A)
【公表日】平成20年3月21日(2008.3.21)
【国際特許分類】
【出願番号】特願2007−523057(P2007−523057)
【出願日】平成17年7月13日(2005.7.13)
【国際出願番号】PCT/EP2005/053347
【国際公開番号】WO2006/010707
【国際公開日】平成18年2月2日(2006.2.2)
【出願人】(390009531)インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】INTERNATIONAL BUSINESS MASCHINES CORPORATION
【Fターム(参考)】