WebSphere Application Server - Express, Version 6.0.x   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows

             目次と検索結果のパーソナライズ化

ネーミング役割

Java 2 Platform, Enterprise Edition (J2EE) 役割ベースの許可の概念は、 CosNaming サービスを保護するように拡張されました。

CosNaming セキュリティーでは、CosNaming 機能に対する セキュリティー管理の細分性が高まりました。CosNaming 機能は、WebSphere Application Server などの CosNaming サーバー上で使用可能です。これらの機能は、ネーム・スペースの内容に影響を与えます。 クライアント・プログラムが最終的に CosNaming 呼び出しを行うのに、 一般に 2 つの方法があります。 1 つは、Java Naming and Directory Interface (JNDI) メソッドを介する方法です。 2 つ目は、CORBA クライアントが直接 CosNaming メソッドを呼び出します。

以下の セキュリティー役割があります。ただし、役割には、次のリストに示すように、 低から高までの権限レベルがあります。このリストでは、各役割のセキュリティー関連の インターフェース・メソッドも示しています。リストされていないインターフェース・メソッドは、 サポートされていないか、セキュリティー関連でないかのどちらかです。
  • CosNamingRead CosNamingRead 役割を割り当てられたユーザーは、 JNDI のルックアップ・メソッドを使用するなどして、ネーム・スペースの照会を実行することができます。 特別な対象 Everyone が、この役割のデフォルト・ポリシーです。
    表 1. CosNamingRead の役割パッケージとインターフェース・メソッド
    パッケージ インターフェース・メソッド
    javax.naming
    • Context.list
    • Context.listBindings
    • Context.lookup
    • NamingEnumeration.hasMore
    • NamingEnumeration.next
    org.omg.CosNaming
    • NamingContext.list
    • NamingContext.resolve
    • BindingIterator.next_one
    • BindingIterator.next_n
    • BindingIterator.destroy
  • CosNamingWrite CosNamingWrite 役割を割り当てられたユーザーは、書き込み操作 (JNDI のバインド、再バインド、アンバインドなど)、および CosNamingRead 操作を実行することができます。 デフォルト・ポリシーとして、対象はこの役割に割り当てられません。
    表 2. CosNamingWrite の役割パッケージとインターフェース・メソッド
    パッケージ インターフェース・メソッド
    javax.naming
    • Context.bind
    • Context.rebind
    • Context.rename
    • Context.unbind
    org.omg.CosNaming
    • NamingContext.bind
    • NamingContext.bind_context
    • NamingContext.rebind
    • NamingContext.rebind_context
    • NamingContext.unbind
  • CosNamingCreate CosNamingCreate 役割を割り当てられたユーザーは、 JNDI の createSubcontext 操作を介してネーム・スペース内に新規オブジェクトを作成する操作、 および CosNamingWrite 操作を実行することができます。 デフォルト・ポリシーとして、対象はこの役割に割り当てられません。
    表 3. CosNamingCreate の役割パッケージとインターフェース・メソッド
    パッケージ インターフェース・メソッド
    javax.naming Context.createSubcontext
    org.omg.CosNaming NamingContext.bind_new_context
  • CosNamingDelete CosNamingDelete 役割を割り当てられたユーザーは、 例えば、JNDI の destroySubcontext メソッドおよび CosNamingCreate 操作を使用して、 ネーム・スペース内のオブジェクトを破棄することができます。 デフォルト・ポリシーとして、対象はこの役割に割り当てられません。
    表 4. CosNamingDelete の役割パッケージとインターフェース・メソッド
    パッケージ インターフェース・メソッド
    javax.naming Context.destroySubcontext
    org.omg.CosNaming NamingContext.destroy
重要: javax.naming パッケージは、 CosNaming JNDI サービス・プロバイダーにのみ適用されます。 JNDI インターフェース・メソッドの バリアントの役割マッピングは、すべて同じです。
呼び出し元が許可されていない場合、 上の表にリストしたパッケージは、次のような振る舞いを示します。
javax.naming
このパッケージは、javax.naming.NoPermissionException 例外を発生させます。 この例外は、NO_PERMISSION を、CosNaming メソッド呼び出しから NoPermissionException にマップします。
org.omg.CosNaming
このパッケージは、org.omg.CORBA.NO_PERMISSION 例外を発生させます。

ユーザー、グループ、または特別な対象の AllAuthenticated および Everyone は、 いつでも、WebSphere Application Server の管理コンソールから、ネーミング役割に追加したり、 ネーミング役割から除去したりすることができます。 ただし、変更内容を有効にするには、サーバーを再始動する必要があります。ベスト・プラクティスは、 特定のユーザーではなく、グループまたは特別な対象のうちの 1 つを、ネーミング役割にマップすることです。 その方が、結局は柔軟性があり、管理しやすいためです。 グループをネーミング役割にマップすることにより、 ユーザーのグループへの追加またはグループからの除去が WebSphere Application Server の外側で行われ、 変更を有効にするのにサーバーを再始動する必要がなくなります。

ユーザーが特定のネーミング役割に割り当てられており、 このユーザーが別のネーミング役割に割り当てられているグループのメンバーである場合、 このユーザーには、自身が割り当てられている役割とグループが割り当てられている役割のうち 最も権限の大きいアクセス権が与えられます。例えば、 ユーザー MyUser が CosNamingRead 役割に割り当てられていると仮定します。また、 グループ MyGroup は CosNamingCreate 役割に割り当てられているとします。ユーザー MyUser がグループ MyGroup のメンバーである場合、 MyUser は、グループ MyGroup のメンバーであるため、CosNamingCreate 役 割に割り当てられます。ユーザー MyUser が グループ MyGroup のメンバーではない場合は、CosNamingRead 役割に割り当てられます。

CosNaming 許可ポリシーは、管理セキュリティーが使用可能になっている場合にのみ有効です。 管理セキュリティーが使用可能であるときに、適切な役割の割り当てを使用しないで CosNaming 操作を試行すると、CosNaming サーバーから org.omg.CORBA.NO_PERMISSION 例外が出されます。

WebSphere Application Server では、CosNaming 関数ごとに 1 つの役割のみが割り当てられます。 したがって、CosNamingCreate 役割を割り当てられたユーザーは、 CosNamingRead 役割も割り当てられていない限り、ネーム・スペースを照会することはできません。ほとんどの場合、 作成者には 3 つの役割、CosNamingRead、CosNamingWrite、および CosNamingCreate を割り当てる必要があります。 この作成者の例の CosNamingRead 役割および CosNamingWrite 役割の割り当ては、 CosNamingCreate 役割に組み込まれています。ほとんどの場合、 WebSphere Application Server 管理者は、前のリリースからこのリリースに移行するときに、 各ユーザーまたはグループの役割の割り当てを変更する必要はありません。

デフォルト・ポリシーを変更することによって、 ネーム・スペースへのアクセスを大幅に制限することができますが、 それによって、予期しない org.omg.CORBA.NO_PERMISSION 例外が 実行時に生じる場合があります。 通常は、J2EE アプリケーションがネーム・スペースにアクセスし、 その ID は、J2EE アプリケーションにアクセスするときに WebSphere Application Server で認証されたユーザーの ID と同じものです。 J2EE アプリケーション・プロバイダーが予期されたネーミング役割を明確に伝達しない場合は、 デフォルトのネーミング許可ポリシーの変更を検討してください。




関連概念
許可テクノロジー
関連タスク
リソースへのアクセスの許可
関連情報
ネーミングの使用
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 11:31:28 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/rsec_nameroles.html