WebLogic JMSのセキュリティの理解

WebLogic JMSリソースの保護

WebLogic JMSでは、JMS宛先へのアクセスを制限することでJMSリソースを保護できます。

デフォルトでは、すべてのユーザーがWebLogicサーバーまたはWebLogicクラスタ内のJMSリソースにアクセスできます。これには、リモート・アクセス権を持つユーザー、WebLogicサーバーまたはWebLogicクラスタ自体で直接実行しているユーザーが含まれます。WebLogic JMS宛先へのアクセスを制限するには、ユーザーのシステム・リソースに対するセキュリティ・ポリシーを作成し、ユーザーに必要なロールを付与する必要があります。セキュリティ・ロールとポリシーの詳細は、「WebLogicリソースの保護の概要」を、JMSで使用できるポリシーについては「Java Messaging Service (JMS)リソース」を参照してください。

JMSセキュリティに関する用語

WebLogic JMSでは、オブジェクトベース・セキュリティ(OBS)またはスレッド・ベースのセキュリティを使用して、保護されたWebLogic JMS宛先へのアクセス時にチェックされるユーザーを決定します。

2つのセキュリティ・アプローチの違いを調査する前に、JMSセキュリティのコンテキストで使用する一般的な用語をいくつか理解します。

サブジェクト: WebLogicアプリケーション内のユーザーを表すセキュリティ・オブジェクト。
プリンシパルおよび資格証明: それぞれユーザーのユーザー名およびパスワード。
資格証明: ユーザーのユーザー名とパスワードの組合せを表すために使用されることがよくあります。

スレッド・ベースのセキュリティでは、保護されたWebLogic JMS宛先がチェックするサブジェクトは、現在の呼出し側のスレッドから暗黙的に派生します。オブジェクトベースのセキュリティでは、サブジェクトは、呼出し側がJMS呼出しに使用しているオブジェクトに格納されたサブジェクトから暗黙的に派生します。一般に、WebLogicのセキュリティはスレッド・ベースです。次の各項では、これら両方の方法について説明します。

クライアントおよびサーバーでのスレッド・ベースのセキュリティの理解

デフォルトでは、保護されているWebLogic JMSリソースへのアクセスには、スレッド・ベースのセキュリティが利用されます。これにより、EJB、WebアプリケーションおよびRMIに対するJava EEの一般的なセキュリティ・モデルと同等のWebLogic JMSセキュリティの動作が提供されます。

これは、WebLogic JMSの送信操作および消費操作が次のようになることを意味します。

チェック済では、現在のスレッド内に暗黙的に格納されたセキュリティ・サブジェクト/ロールを使用します。
チェックなしでは、JMS javax.jms createConnection()またはcreateJMSContext()コールに渡すことができるユーザー名とパスワードを使用します。つまり、(1)からのスレッドのサブジェクトは、アプリケーションがオプションでcreateConnection()またはcreateJMSContext()に渡すことができるユーザー名およびパスワードより優先されます。

サーバー・アプリケーションに対するスレッド・ベースのセキュリティ

サーバー側アプリケーションでは、EJBおよびWebアプリケーション・スレッドのサブジェクトまたはロールを設定する方法は複数あります。『Oracle Fusion Middleware WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。サーバー側のWebLogic JMS送信および消費コールのスレッド・ベースのJMSセキュリティ・チェック動作をオーバーライドするには、「サーバー・アプリケーションにおけるオブジェクトベースのセキュリティの理解」を参照してください。

クライアント・アプリケーションに対するスレッド・ベースのセキュリティ

クライアント・アプリケーションの場合は、クライアント・アプリケーションでJNDIコンテキストが作成されると、現在のスレッドのサブジェクトが生成され、スレッドに暗黙的に配置されます。JNDIコンテキストは、SECURITY_PRINCIPALおよびContext.SECURITY_CREDENTIALSプロパティを使用して、資格証明をオプションで指定できます。

次のコード・サンプルでは、ユーザーmyusernameおよびパスワードuser_passwordの現在のスレッドにサブジェクトを配置しています。

java.util.Hashtable env = new Hashtable();
    env.put(Context.PROVIDER_URL, url);  // typical url: t3://example.com:7001  
    env.put(Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory");
    env.put(Context.SECURITY_PRINCIPAL, "myusername");
    env.put(Context.SECURITY_CREDENTIALS, "user_password");
    javax.naming.InitialContext ic = new InitialContext(env); // throws an exception if user name/password is incorrect 
    // thread now implicitly has subject for the ic user name/password
    ic.close();    
    // thread now has original subject from before the ic was created

クライアントが資格証明を指定せずにInitialContextオブジェクトを作成する場合、次のようになります。

現在のスレッドにすでにあるサブジェクトは変更されていません。
スレッドのサブジェクトがない場合は、匿名のサブジェクトであるとみなされます。

クライアント・プログラムが、InitialContextオブジェクトの作成に使用したスレッドとは異なるスレッドにスレッドのサブジェクトを転送する必要がある場合、クライアント・プログラムはセキュリティAPIを使用してスレッドの現在のサブジェクトを格納し、その後このキャッシュされたサブジェクトを別のスレッドで使用できます。

たとえば:

// retrieve the subject that is implicitly store in the current thread
javax.security.auth.Subject subject =   
weblogic.security.Security.getCurrentSubject();  
...  
// use the given subject to perform an action:
// if the action throws, return an exception 
// if the action succeeds, return "OK" 
static Object doSomethingAsSubject(javax.security.auth.Subject subject) {   
try {     
return weblogic.security.Security.runAs(subject,       
    new java.security.PrivilegedExceptionAction() {         
        public java.lang.Object run() throws Exception {           
            //  do something or throw  
                 return "OK"; 
    }});
   } catch (java.security.PrivilegedActionException e) { 
    return e;   
} catch (Throwable t) {    
 return t;
  } 
}

これは匿名サブジェクトの取得に役立つ場合があります。

 javax.security.auth.Subject anon = new javax.security.auth.Subject();

クライアント側のWebLogic JMS送信および消費コールのスレッド・ベースのJMSセキュリティ・チェック動作をオーバーライドするには、「クライアントにおけるオブジェクトベースのセキュリティの理解」を参照してください。

オブジェクトベースのセキュリティの理解

WebLogic JMSクライアントでは、スレッド・ベースのセキュリティではなく、オブジェクトベースのセキュリティ(OBS)と呼ばれるより単純なセキュリティ・モデルをオプションで使用できます。このオプションはWebLogic 12.2.1.3で導入されたもので、マルチスレッド・クライアントでは、これを使用しないとスレッド間でスレッド・ベースのセキュリティ・サブジェクトを転送するための追加コードが必要になるため便利です。

次の各項では、オブジェクトベースのセキュリティを有効にする方法について説明します。

クライアントでのオブジェクトベースのセキュリティの有効化

オブジェクトベースのセキュリティ(OBS)を有効にすると、メッセージが送信され、コール元のスレッドの件名ではなく、JMSクライアントの初期化時に指定した資格証明に基づいてセキュリティ・チェックが消費されます。

OBSを有効にするには、OBS JNDI初期コンテキストを使用する必要があります。OBS初期コンテキストから取得されるOBS接続ファクトリを使用して作成されるWebLogic JMS送信者またはコンシューマは、デフォルトで、現在の送信者またはコンシューマ・スレッドに関連付けられたサブジェクトではなく、OBS初期コンテキストに関連付けられた資格証明を暗黙的に使用します。また、ユーザー名とパスワード資格証明がOBS接続ファクトリの標準のJMS createConnection()またはcreateJMSContext()コールにパラメータとして渡される場合、この新しい資格証明は、OBS初期コンテキストに関連付けられた資格証明よりも優先します。新しい資格証明を使用して、その接続またはJMSコンテキストで送信または消費を行います。

JMSクライアントの送信者およびコンシューマでOBSを有効にするステップ:

javax.naming.InitialContextオブジェクトを作成します:
1. weblogic.jndi.WLInitialContextFactoryではなく、文字列値weblogic.jms.WLInitialContextFactoryを使用してContext.INITIAL_CONTEXT_FACTORYプロパティを指定します。これにより、OBS初期コンテキストが戻されます。これはJMSクライアントOBSを使用する多くのアプリケーションにとって必要な唯一のステップです。
2. (オプション)標準のJNDI Context.SECURITY_PRINCIPALおよびContext.SECURITY_CREDENTIALSプロパティを使用して、ユーザー名およびパスワード資格証明を指定します(OBS以外のコンテキストに対する場合と同じです)。これは、OBS初期コンテキストに関連付けられているデフォルトのOBS資格証明になります。これらのプロパティが指定されていない場合、OBS初期コンテキストに関連付けられている資格証明は、weblogic.jndi.securityPolicyの設定によって決定されます。
3. (オプション)文字列値ObjectBasedまたはObjectBasedHybridを使用して、weblogic.jndi.securityPolicyという名前の初期コンテキスト・プロパティを指定します。これにより、初期コンテキストのContext.SECURITY_PRINCIPALおよびContext.SECURITY_CREDENTIALSプロパティを使用してユーザー名およびパスワード資格証明が指定されない場合の動作を微調整できます。
  - ObjectBased(デフォルト):初期コンテキストの作成時に資格証明が提供されない場合、デフォルトでは、JNDIルックアップの匿名サブジェクトが使用されます。WebLogic JMSではファクトリに関連付けられた資格証明を送信または消費します。
  - ObjectBasedHybrid:初期コンテキストの作成時に資格証明が提供されない場合、デフォルトで、後続のJNDIルックアップ用に初期コンテキストが作成されたときに現在のスレッド上に存在した資格証明が使用されます。WebLogic JMSではファクトリに関連付けられている資格証明を送信または消費します。
ステップ(1)で作成されたOBS初期コンテキストを使用して、WebLogic JMS接続ファクトリをルックアップします(非OBSコンテキストの接続ファクトリをルックアップする場合と同じです)。暗黙的にOBS JMS接続ファクトリになります。OBS JMS接続ファクトリを使用して作成されるJMS送信者またはコンシューマは、OBSを使用することになります。
(オプション)ユーザー名とパスワードをJMS標準のcreateConnection()、またはJMS接続またはコンテキストを作成するために使用されるcreateJMSContext()コールに渡して、OBS JMS接続ファクトリに関連付けられたOBS資格証明をオーバーライドします。

クライアントでのオブジェクトベースのセキュリティの制限

次に、OBSの制限事項のいくつかを示します。

OBS初期コンテキストでは、lookup()コールのみをサポートし、それ以外の場合はNotSupported例外をスローします。他のコールをサポートするコンテキストが必要な場合は、OBSを有効にしない2番目のコンテキストを作成します。
OBS初期コンテキストは、WebLogicクライアントでのみサポートされ、WebLogicサーバーではサポートされません。ブリッジ、MDB、リソース参照などのWebLogic JMSサーバー機能と組み合せて、このようなコンテキストを使用しようとすると、例外がスローされます。これらのサーバー側JMS機能にはすでに、OBSに類似したセマンティクスを提供する独自のセキュリティ処理があるため、このような制限が存在します。
OBS初期コンテキストが作成されると、初期コンテキストのユーザーは現在のスレッドに配置されません。これはweblogic.jndi.WLInitialContextFactoryコンテキストとは異なります。

サーバー・アプリケーションでのオブジェクトベースのセキュリティの有効化

インバウンドおよびアウトバウンドJMSアプリケーションでオブジェクトベース・セキュリティ(OBS)を有効にする方法を学習します。

インバウンドJMSアプリケーションのオブジェクトベースのセキュリティ

インバウンドWebLogic JMSコールを実行するサーバー・アプリケーション(メッセージドリブンBeanなど)は、暗黙的にオブジェクトベースとなります。これらのアプリケーションが受信JMSメッセージにアクセスするための資格証明またはロールは、次のいずれかの方法で提供されます。

アプリケーション自体での指定。

ノート:
この方法の使用はお薦めしません。
サービス自体での定義(メッセージング・ブリッジを使用すると、ユーザー名またはパスワードを構成できます)。

ノート:
この方法の使用はお薦めしません。
アウトバウンドの場合と同様に、JMSリソースをJNDIにマップするJMSシステム・リソース・モジュールに外部JMSサーバーを使用して指定します。

次のように、メッセージドリブンBean、メッセージング・ブリッジおよびアウトバウンドJMSに外部JMSサーバー・メソッドを使用するのがベスト・プラクティスです。

資格証明が動的に構成可能であり、アプリケーション・ファイルまたは記述子ファイルにハードコードされていないことを確認します。
ほぼすべてのインバウンドおよびアウトバウンドのユースケースに適用されるため、JMS資格証明を集中管理する方法として役立ちます。

「FAQ: リモートJMSプロバイダの統合」および「WebLogic JMSをEJBやサーブレットと組み合せて使用するために拡張されたサポート」を参照してください。

アウトバウンドJMSアプリケーションのオブジェクトベースのセキュリティ

アウトバウンドWebLogic JMSコールを実行するサーバー・アプリケーションは、現在のスレッドで現在のセキュリティ・サブジェクトに優先するオブジェクトベースのセキュリティ・パターンを実現できます。これが機能するには、次のことを確認してください。

JMS接続ファクトリの現在のJNDIロケーションをローカルJNDIにマップするには、次のようにします。
- JMSシステム・リソース・モジュールに外部JMSサーバーを構成します。
- 必要な権限を持つユーザーに対し外部JMSサーバーの資格証明を構成します。
アプリケーション・コードで、JMSリソース参照を使用するか、JMS接続ファクトリのローカルJNDI名を参照するJMSコンテキストを挿入します。

ノート:

オブジェクトベースのセキュリティ・パターンやスレッドベースのセキュリティ・パターンが必要かどうかにかかわらず、サーバー・アプリケーションがリソース参照またはJMSコンテキスト・インジェクションを使用してJMS接続ファクトリを参照することは、一般的なベスト・プラクティスです。

前述の要件が満たされた後、WebLogicサーバーは、外部JMSサーバーに構成した資格証明を、特定のJMS接続ファクトリから発生したアウトバウンド送信コールまたは消費コールすべてにインジェクトします。