ネーミング・ロール

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 のロール・パッケージとインターフェース・メソッド. 以下の表は、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 のロール・パッケージとインターフェース・メソッド. 以下の表は、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 のロールパッケージとインターフェース・メソッド. 以下の表に、CosNamingCreate のロール・パッケージとインターフェース・メソッドをリストしています。
    パッケージ インターフェース・メソッド
    javax.naming Context.createSubcontext
    org.omg.CosNaming NamingContext.bind_new_context
  • CosNamingDelete。CosNamingDelete ロールを割り当てられたユーザーは、 例えば、JNDI の destroySubcontext メソッドおよび CosNamingCreate 操作を使用して、 名前空間内のオブジェクトを破棄することができます。 デフォルト・ポリシーとして、対象にはこのロールが割り当てられていません。
    表 4. CosNamingDelete のロール・パッケージとインターフェース・メソッド. 以下の表に、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 アプリケーション・プロバイダーが予期されたネーミング・ロールを明確に伝達しない場合は、 デフォルトのネーミング許可ポリシーの変更を検討してください。


トピックのタイプを示すアイコン 参照トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rsec_nameroles
ファイル名:rsec_nameroles.html