Oracle® Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド 11g リリース 1 (10.3.1) B55520-01 |
|
戻る |
次へ |
WebLogic Server は、エンタープライズ JavaBean (EJB) を保護する Java EE アーキテクチャ セキュリティ モデルをサポートしています。これには、宣言による認可 (このマニュアルでは宣言によるセキュリティとも呼ぶ) とプログラムによる認可 (このマニュアルではプログラムによるセキュリティとも呼ぶ) のサポートが含まれます。
この節では、以下の内容について説明します。
注意 : EJB の保護には、デプロイメント記述子ファイル、Administration Console、および JACC を使用できます。Administration Console を使用しての EJB の保護については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』を参照してください。JACC については、「Java Authorization Contract for Containers の使用」を参照してください。 |
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3 Authorization」に以下のような記述があります。
「J2EE アーキテクチャにおいて、コンテナはホストするコンポーネントとその呼び出し側との間の認可境界として機能します。認可境界はコンテナの認証境界内に存在するので、正常に認証が実行される中で認可が考慮されます。着信呼び出しの場合、コンテナは呼び出し側の資格のセキュリティ属性と、対象コンポーネントのアクセス制御ルールを比較します。ルール要件が満たされていれば、呼び出しは許可されます。それ以外の場合、この呼び出しは拒否されます。」
「アクセス制御ルールの定義には、能力とパーミッションという 2 つの基本的アプローチが存在します。能力は呼び出し側が実行できる操作、パーミッションは操作を実行できるユーザを焦点とします。J2EE アプリケーション プログラミング モデルは、パーミッションを焦点とします。J2EE アーキテクチャにおいて、デプロイヤの役割はアプリケーションのパーミッション モデルをその操作環境におけるユーザの能力にマップすることです。」
上記のマニュアルでは、Java EE アーキテクチャを使用してアプリケーション リソースへのアクセスを制御する 2 つの方法、宣言による認可とプログラムによる認可について説明しています。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html
からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.1 Authorization」に以下のような記述があります。
「デプロイヤは、J2EE アプリケーションと関連のコンテナによって実施されるアクセス制御ルールを設定します。デプロイヤは、デプロイメント ツールを使用して、通常はアプリケーション アセンブラによって供給されるアプリケーション パーミッション モデルを、操作環境に固有のポリシーおよびメカニズムにマップします。アプリケーション パーミッション モデルは、デプロイメント記述子で定義されます。」
WebLogic Server は EJB において宣言による認可を実装するためのデプロイメント記述子の使用をサポートしています。
注意 : 宣言による認可は、このマニュアルでは宣言によるセキュリティとも呼ばれます。 |
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html
からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.2 Programmatic Authorization」に以下のような記述があります。
「J2EE コンテナは、コンポーネントにメソッド呼び出しをディスパッチする前に、アクセス制御の決定を行います。コンポーネントの論理または状態は、これらのアクセス決定を考慮に入れません。しかし、コンポーネントは EJBContext.isCallerInRole
(エンタープライズ Bean コード用) および HttpServletRequest.isUserInRole
(Web コンポーネント用) の 2 つのメソッドを使用して、きめ細かいアクセス制御を行うことが可能です。コンポーネントはこれらのメソッドを使用して、呼び出しのパラメータ、コンポーネントの初期状態、または呼び出しの時間などその他の要因に基づき、コンポーネントによって選択された特権が呼び出し側に付与されているかどうかを判断します。」
「これらの機能の 1 つを呼び出すコンポーネントのアプリケーション コンポーネント プロバイダは、すべての呼び出しで使用されるあらゆる個別の roleName 値を宣言する必要があります。これらの宣言は、デプロイメント記述子では security-role-ref
要素として登場します。各 security-role-ref
要素は、アプリケーションに roleName として組み込まれた特権名をセキュリティ ロールにリンクします。最終的には、デプロイヤはアプリケーションに組み込まれた特権名と、デプロイメント記述子で定義されたセキュリティ ロールとの間のリンクを確立します。特権名とセキュリティ ロールの間のリンクは、同じアプリケーション内でもコンポーネントごとに異なる場合があります。」
「特定の特権をテストするだけでなく、アプリケーション コンポーネントでは EJBContext.getCallerPrincipal
または HttpServletRequest.getUserPrincipal
を使用して取得した呼び出し側 ID と、作成時の状態のコンポーネントに組み込まれている識別された呼び出し側 ID を比較できます。呼び出し側 ID が、識別された呼び出し側 ID に等しければ、コンポーネントは呼び出し側に処理の続行を許可できます。等しくなければ、コンポーネントは呼び出し側がそれ以上の対話を行わないようにできます。コンテナによって返される呼び出し側のプリンシパルは、呼び出し側が使用した認証メカニズムによって決まります。また、同じメカニズムによる同じユーザ認証に対してでも、異なったベンダからのコンテナは異なったプリンシパルを返す場合があります。プリンシパルの形式の変動性を考慮に入れるため、コンポーネントのアクセス決定に識別された呼び出し側の状態を適用することを選択した開発者は、同一ユーザを表す複数の識別された呼び出し側 ID がコンポーネントと関連付けられることを許容する必要があります。これは特に、アプリケーションの柔軟性や移植性が優先される場合に、推奨されます。」
WebLogic Server は、EJB におけるプログラムによる認可を実装するために、EJBContext.isCallerInRole
メソッドと EJBContext.getCallerPrincipal
メソッドの使用、およびデプロイメント記述子での security-role-ref
要素の使用をサポートしています。
注意 : プログラムによる認可は、このマニュアルではプログラムによるセキュリティとも呼ばれます。 |
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html
からオンラインで入手できます。
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.3 Declarative Versus Programmatic Authorization」に以下のような記述があります。
「デプロイヤによってコンフィグレーションされる外部アクセス制御ポリシーと、コンポーネント プロバイダによってアプリケーションに組み込まれた内部ポリシーとの間にはトレードオフが存在します。アプリケーションが作成された後では、外部ポリシーのほうが高い融通性を持ちます。アプリケーションが記述されている過程では、内部ポリシーのほうが融通性の高い機能を提供します。また、外部ポリシーはデプロイヤにとって透過的で完全に理解可能であるのに対し、内部ポリシーはアプリケーションに埋め込まれており、これを完全に理解できるのはアプリケーション開発者のみである可能性があります。ある特定のコンポーネントとメソッドについて認可モデルを選択する際には、これらのトレードオフを検討する必要があります。」
Sun Microsystems, Inc. のマニュアル『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.html
からオンラインで入手できます。
宣言によるセキュリティは、以下の 3 つの方法で実装できます。
Administration Console でセキュリティ プロバイダを使用する。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』 を参照してください。
JACC (Java Authorization Contract for Containers) を使用する。詳細については、「Java Authorization Contract for Containers の使用」を参照してください。
デプロイメント記述子を使用する。この節では、この方法について説明します。
これら 3 つのうちどの方法を使用するかは、JACC フラグとセキュリティ モデルによって定義されます。(セキュリティ モデルについては、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照)。
EJB に宣言によってセキュリティを実装するには、デプロイメント記述子 (ejb-jar.xml
および weblogic-ejb-jar.xml
) を使用してセキュリティ要件を定義します。コード リスト 6-1 は、ejb-jar.xml
および weblogic-ejb-jar.xml
デプロイメント記述子を使用してセキュリティ ロール名をセキュリティ レルムにマップする例を示しています。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、EJB コンテナがセキュリティ定義を使って要件を実施します。
EJB デプロイメント記述子でセキュリティをコンフィグレーションするには、次の手順を実行します (コード リスト 6-1 を参照)。
テキスト エディタを使用して、ejb-jar.xml
および weblogic-ejb-jar.xml
デプロイメント記述子ファイルを作成します。
ejb-jar.xml
ファイルに、ロール名、EJB 名、およびメソッド名を定義します (太字テキストを参照)。
注意 : セキュリティ ロール名の正しい構文は、XML (Extensible Markup Language) 推奨仕様で Nmtoken に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken )。
セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。
ejb-jar.xml ファイルでセキュリティをコンフィグレーションする方法の詳細については、Sun Microsystems のエンタープライズ JavaBeans 仕様 2.0 ( |
WebLogic 固有の EJB デプロイメント記述子ファイル weblogic-ejb-jar.xml
にセキュリティ ロール名を定義し、それをセキュリティ レルム内の 1 つまたは複数のプリンシパル (ユーザまたはグループ) にリンクします。
weblogic-ejb-jar.xml
ファイルでセキュリティをコンフィグレーションする方法の詳細については 『Oracle Fusion Middleware Oracle WebLogic Server Enterprise JavaBeans プログラマーズ ガイド』の「weblogic-ejb-jar.xml デプロイメント記述子のリファレンス」を参照してください。
コード リスト 6-1 ejb-jar.xml および weblogic-ejb-jar.xml ファイルを使用したセキュリティ ロール名とセキュリティ レルムのマッピング
ejb-jar.xml entries: ... <assembly-descriptor> <security-role> <role-name>manger</role-name> </security-role> <security-role> <role-name>east</role-name> </security-role> <method-permission> <role-name>manager</role-name> <role-name>east</role-name> <method> <ejb-name>accountsPayable</ejb-name> <method-name>getReceipts</method-name> </method> </method-permission> ... </assembly-descriptor> ... weblogic-ejb-jar.xml entries: <security-role-assignment> <role-name>manager</role-name> <principal-name>al</principal-name> <principal-name>george</principal-name> <principal-name>ralph</principal-name> </security-role-assignment> ...
以下のトピックでは、EJB のセキュリティ要件を定義するために ejb-jar.xml
および weblogic-ejb-jar.xml
ファイルで使用されるデプロイメント記述子の要素について説明します。
以下の ejb-jar.xml
デプロイメント記述子の要素が、WebLogic Server でセキュリティ要件を定義するために使用されます。
method
要素は、エンタープライズ Bean のホームまたはコンポーネント インタフェースのメソッド、あるいはメッセージ駆動型 Bean の場合に Bean の onMessage
メソッド (またはメソッドのセット) を示すために使用されます。
次の表では、method
要素内で定義できる要素について説明します。
表 6-1 method 要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<description> |
省略可能 |
メソッドの説明文。 |
<ejb-name> |
必須 |
|
<method-intf> |
省略可能 |
エンタープライズ Bean のホーム インタフェースとコンポーネント インタフェースの両方で定義されて同じ署名を持つメソッドを識別できるようにする。 |
<method-name> |
必須 |
エンタープライズ Bean のメソッド名またはアスタリスク (*) を指定する。アスタリスクは、要素がエンタープライズ Bean のコンポーネントおよびホーム インタフェースのすべてのメソッドを表す場合に使用する。 |
<method-params> |
省略可能 |
Java タイプのメソッド パラメータの完全修飾名のリストが含まれる。 |
method-permission
要素では、1 つまたは複数のエンタープライズ Bean メソッドの呼び出しを許可されている 1 つまたは複数のセキュリティ ロールを指定します。method-permission
要素は、説明 (省略可能)、セキュリティ ロール名のリストまたはメソッドが認可に関してチェックされないことを示すインジケータ、およびメソッドの要素のリストから成ります。
method-permission
要素内のセキュリティ ロールは、デプロイメント記述子の security-role
要素で定義されており、メソッドは、エンタープライズ Bean のコンポーネントまたはホーム インタフェースで定義されているメソッドでなければなりません。
次の表では、method-permission
要素内で定義できる要素について説明します。
表 6-2 method-permission 要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
|
省略可能 |
このセキュリティ制約の説明文。 |
<role-name> または <unchecked> |
必須 |
|
<method> |
必須 |
エンタープライズ Bean のホームまたはコンポーネント インタフェースのメソッド、あるいはメッセージ駆動型 Bean の場合に Bean の |
security-identity
要素には、エンタープライズ Bean のメソッドを実行するために呼び出し側のセキュリティ ID を使用するか、または特定の run-as ID を使用するかを指定します。この要素には、省略可能な説明と使用するセキュリティ ID の指定が含まれます。
次の表では、security-identity
要素内で定義できる要素について説明します。
表 6-3 security-identity 要素
要素 | 必須/省略可能 | 説明 |
---|---|---|
<description> |
省略可能 |
セキュリティ ID の説明文。 |
<use-caller-identity> または <run-as> |
必須 |
run-as 要素には、エンタープライズ Bean を実行するための run-as ID を指定する。この要素には、省略可能な説明とセキュリティ ロールの名前が含まれる。 |
security-role-ref
要素には、エンタープライズ Bean のコード内のセキュリティ ロール参照の宣言が含まれます。この宣言は、省略可能な説明、コードで使用されているセキュリティ ロール名、およびセキュリティ ロールへのリンク (省略可能) から成ります。セキュリティ ロールが指定されていない場合、デプロイヤが適切なセキュリティ ロールを選択する必要があります。
role-name
要素の値は、EJBContext.isCallerInRole(String roleName)
メソッドまたは HttpServletRequest.isUserInRole(String role)
メソッドに対するパラメータとして使用される String でなければなりません。
security-role-ref 要素の使用例については、コード リスト 6-2 を参照してください。
コード リスト 6-2 security-role-ref 要素の例
<!DOC<weblogic-ejb-jar xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-ejb-jar.xsd"> <ejb-jar> <enterprise-beans> ... <session> <ejb-name>SecuritySLEJB</ejb-name> <home>weblogic.ejb20.security.SecuritySLHome</home> <remote>weblogic.ejb20.security.SecuritySL</remote> <ejb-class>weblogic.ejb20.security.SecuritySLBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> <security-role-ref> <role-name>rolenamedifffromlink</role-name> <role-link>role121SL</role-link> </security-role-ref> <security-role-ref> <role-name>roleForRemotes</role-name> <role-link>roleForRemotes</role-link> </security-role-ref> <security-role-ref> <role-name>roleForLocalAndRemote</role-name> <role-link>roleForLocalAndRemote</role-link> </security-role-ref> </session> ... </enterprise-beans> </ejb-jar>
use-caller-identity
要素には、エンタープライズ Bean のメソッドを実行するためのセキュリティ ID として、呼び出し側のセキュリティ ID を使用することを指定します。
use-caller-identity
要素の使用例については、コード リスト 6-3 を参照してください。
コード リスト 6-3 use-caller-identity 要素の例
<ejb-jar> <enterprise-beans> <session> <ejb-name>SecurityEJB</ejb-name> <home>weblogic.ejb20.SecuritySLHome</home> <remote>weblogic.ejb20.SecuritySL</remote> <local-home> weblogic.ejb20.SecurityLocalSLHome </local-home> <local>weblogic.ejb20.SecurityLocalSL</local> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <message-driven> <ejb-name>SecurityEJB</ejb-name> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <transaction-type>Container</transaction-type> <security-identity> <use-caller-identity/> </security-identity> </message-driven> </enterprise-beans> </ejb-jar>
以下の weblogic-ejb-jar.xml
デプロイメント記述子の要素が、WebLogic Server でセキュリティ要件を定義するために使用されます。
client-authentication
要素は、EJB がクライアント認証をサポートするか、または、必要とするかを指定します。
次の表に、指定可能な設定を定義してあります。
表 6-4 client-authentication 要素
設定 | 定義 |
---|---|
なし |
クライアント認証はサポートされない。 |
supported |
クライアント認証はサポートされるが、必須ではない。 |
required |
クライアント認証は必須となる。 |
client-cert-authentication
要素は、EJB が転送レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。
次の表に、指定可能な設定を定義してあります。
表 6-5 client-cert-authentication 要素
設定 | 定義 |
---|---|
なし |
クライアント証明書認証はサポートされない。 |
supported |
クライアント証明書認証はサポートされるが、必須ではない。 |
required |
クライアント証明書認証は必須となる。 |
confidentiality
要素は、その EJB における転送の機密性の要件を指定します。confidentiality
要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバ間でデータが送信されるようになります。
次の表に、指定可能な設定を定義してあります。
externally-defined
要素を使用すると、weblogic-ejb-jar.xml
デプロイメント記述子の role-name
要素によって定義されたセキュリティ ロールが Administration Console で指定したマッピングを使用するよう指定できます。この要素を使用することで、特定の Web アプリケーションのデプロイメント記述子に定義されたセキュリティ ロールごとに特定のセキュリティ ロール マッピングを指定する必要がなくなります。このため、同じセキュリティ レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、Administration Console を使用して他のアプリケーションのセキュリティを指定および変更できます。
注意 : バージョン 9.0 からは、何も指定されていない場合は空のロール マッピングが作成されるのが、ロール マッピングのデフォルト動作になりました。バージョン 8.1 の EJB では、ロール マッピングを weblogic-ejb-jar.xml 記述子に定義しないと、デプロイメントに失敗していました。9.0 では、空のロール マッピングを作成する際の EJB と WebApp の動作の矛盾がなくなりました。ロール マッピングの動作および下位互換性の設定については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「ロール マッピングの組み合わせを有効化」を参照してください。サーバのロール マッピングの動作は、Administration Console でどのセキュリティ デプロイメント モデルを選択したかによって異なります。セキュリティ デプロイメント モデルの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の「Web アプリケーションおよび EJB リソースの保護のオプション」を参照してください。 |
セキュリティ ロール名を指定する場合には、以下の規約と制限に従ってください。
セキュリティ ロール名の正しい構文は、XML (Extensible Markup Language) 推奨仕様で Nmtoken
に関して定義されているとおりです (http://www.w3.org/TR/REC-xml#NT-Nmtoken
)。
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ } を使用しないでください。
セキュリティ ロール名では大文字と小文字が区別されます。
推奨される命名規約では、セキュリティ ロール名は単数形です。
コード リスト 6-4 とコード リスト 6-5 は、weblogic-ejb-jar.xml
ファイルで externally-defined
要素を使用する方法を比較して示しています。コード リスト 6-5 で、weblogic-ejb-jar.xml
内の「manager」の externally-defined
要素は、セキュリティが getReceipts
メソッドにおいて正しくコンフィグレーションされるには Administration Console で manager
に対応するプリンシパルが作成される必要がある、ということを意味します。
コード リスト 6-4 ejb-jar.xml および weblogic-ejb-jar.xml デプロイメント記述子を使用しての EJB におけるセキュリティ ロールのマッピング
ejb-jar.xml entries: ... <assembly-descriptor> <security-role> <role-name>manger</role-name> </security-role> <security-role> <role-name>east</role-name> </security-role> <method-permission> <role-name>manager</role-name> <role-name>east</role-name> <method> <ejb-name>accountsPayable</ejb-name> <method-name>getReceipts</method-name> </method> </method-permission> ... </assembly-descriptor> ... weblogic-ejb-jar.xml entries: <security-role-assignment> <role-name>manager</role-name> <principal-name>joe</principal-name> <principal-name>Bill</principal-name> <principal-name>Mary</principal-name> ... </security-role-assignment> ...
コード リスト 6-5 EJB デプロイメント記述子におけるロール マッピング用の externally-defined 要素の使用
ejb-jar.xml entries: ... <assembly-descriptor> <security-role> <role-name>manger</role-name> </security-role> <security-role> <role-name>east</role-name> </security-role> <method-permission> <role-name>manager</role-name> <role-name>east</role-name> <method> <ejb-name>accountsPayable</ejb-name> <method-name>getReceipts</method-name> </method> </method-permission> ... </assembly-descriptor> ... weblogic-ejb-jar.xml entries: <security-role-assignment> <role-name>manager</role-name> <externally-defined/> ... </security-role-assignment> ...
Administration Console を使用しての EJB の保護については、「Oracle Fusion Middleware Oracle WebLogic Server ロールおよびポリシーによるリソースの保護」を参照してください。
identity-assertion
要素は、EJB が ID アサーションをサポートするかどうかを指定します。
次の表に、指定可能な設定を定義してあります。
表 6-7 identity-assertion 要素
設定 | 定義 |
---|---|
なし |
ID アサーションはサポートされない。 |
supported |
ID アサーションはサポートされるが、必須ではない。 |
required |
ID アサーションは必須となる。 |
iiop-security-descriptor
要素は、Bean レベルのセキュリティ コンフィグレーション パラメータを指定します。これらのパラメータにより、インターオペラブル オブジェクト参照 (IOR) に含まれる IIOP セキュリティ情報が決定します。
iiop-security-descriptor
要素の使用例については、コード リスト 6-6 を参照してください。
コード リスト 6-6 iiop-security-descriptor 要素の例
<weblogic-enterprise-bean> <iiop-security-descriptor> <transport-requirements> <confidentiality>supported</confidentiality> <integrity>supported</integrity> <client-cert-authorization> supported </client-cert-authentication> </transport-requirements> <client-authentication>supported<client-authentication> <identity-assertion>supported</identity-assertion> </iiop-security-descriptor> </weblogic-enterprise-bean>
integrity
要素は、その EJB の転送の整合性の要件を指定します。integrity 要素を使用すると、クライアントとサーバ間で、データが途中で変更することなく転送されるようになります。
次の表に、指定可能な設定を定義してあります。
Principal-name
要素は、security-role-assignment 要素で指定したロール名に適用する、WebLogic Server セキュリティ レルム内のプリンシパルの名前を指定します。security-role-assignment
要素には、最低 1 つの principal
が必要です。各ロール名に対しては、複数の principal-name
を定義できます。
注意 : 大量のプリンシパルをリストする必要がある場合は、ユーザの代わりにグループを指定することを検討してください。指定したユーザが多すぎると、パフォーマンスが低下するおそれがあります。 |
role-name
要素は、EJB プロバイダが対応する ejb-jar.xml
ファイルで指定されたアプリケーション ロール名を示します。スタンザの次の principal-name 要素で、ProductName プリンシパルを、指定したrole-name
にマップします。
run-as-identity-principal
要素は、ejb-jar デプロイメント記述子で、security-identity run-as role-name を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名を指定します。run-as role-name と run-as-identity-principal または run-as-principal-name のマッピング方法については、「run-as-role-assignment」を参照してください。
注意 : 非推奨 : run-as-identity-principal 要素は WebLogic Server 8.1 で非推奨となりました。代わりに run-as-principal-name 要素を使用してください。 |
run-as-identity-principal
要素を使用する例については、コード リスト 6-7 を参照してください。
コード リスト 6-7 run-as-identity-principal 要素の例
ebj-jar.xml: <ejb-jar> <enterprise-beans> <session> <ejb-name>Caller2EJB</ejb-name> <home>weblogic.ejb11.security.CallerBeanHome</home> <remote>weblogic.ejb11.security.CallerBeanRemote</remote> <ejb-class>weblogic.ejb11.security.CallerBean</ejb-class> <session-type>Stateful</session-type> <transaction-type>Container</transaction-type> <ejb-ref><ejb-ref-name>Callee2Bean</ejb-ref-name> <ejb-ref-type>Session</ejb-ref-type> <home>weblogic.ejb11.security.CalleeBeanHome</home> <remote>weblogic.ejb11.security.CalleeBeanRemote</remote> </ejb-ref> <security-role-ref> <role-name>users1</role-name> <role-link>users1</role-link> </security-role-ref> <security-identity> <run-as> <role-name>users2</role-name> </run-as> </security-identity> </session> </enterprise-beans> </ejb-jar> woblogic-ejb-jar.xml: <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>Caller2EJB</ejb-name> <reference-descriptor> <ejb-reference-description> <ejb-ref-name>Callee2Bean</ejb-ref-name> <jndi-name>security.Callee2Bean</jndi-name> </ejb-reference-description> </reference-descriptor> <run-as-identity-principal>wsUser3</run-as-identity-principal> </weblogic-enterprise-bean> <security-role-assignment> <role-name>user</role-name> <principal-name>wsUser2</principal-name> <principal-name>wsUser3</principal-name> <principal-name>wsUser4</principal-name> </security-role-assignment> </weblogic-ejb-jar>
run-as-principal-name
要素は、ejb-jar デプロイメント記述子で、security-identity run-as role-name を指定した Bean の run-as プリンシパルとして使用されるセキュリティ プリンシパル名を指定します。run-as role-name と run-as-principal-name のマッピング方法については、「run-as-role-assignment」を参照してください。
run-as-role-assignment
要素は、ejb-jar.xml
ファイルで指定される特定の security-identity run-as role-name を weblogic-ejb-jar.xml
ファイルで指定される run-as-principal-name
にマップするために使用します。特定の role-name に対する run-as-principal-name
要素の値は、security-identity として指定された role-name を使用する ejb-jar.xml
ファイル内のすべての Bean が対象となります。weblogic-ejb-jar.xml
ファイルで指定した run-as-principal-name
要素の値は、その Bean の weblogic-enterprise-bean
要素の下で run-as-principal-name
を指定することによって、個々の Bean レベルでオーバーライドできます。
注意 : 特定の Bean に対して、run-as-principal-name 要素が run-as-role-assignment 要素内または Bean 固有の run-as-principal-name 要素内で指定されていない場合、EJB コンテナは、weblogic-enterprise-bean security-role-assignment 要素内のセキュリティ ユーザの最初の principal-name を role-name に対して選択し、その principal-name を run-as-principal-name として使用します。 |
run-as-role-assignment 要素の使用例については、コード リスト 6-8 を参照してください。
コード リスト 6-8 run-as-role-assignment 要素の例
ejb-jar.xml ファイル // Beans 「A_EJB_with_runAs_role_X」 および「B_EJB_with_runAs_role_X」では、 //security-identity run-as role-name「runAs_role_X」を指定する。 // Bean 「C_EJB_with_runAs_role_Y」では security-identity // run-as role-name 「runAs_role_Y」を指定する。 <ejb-jar> <enterprise-beans> <session> <ejb-name>SecurityEJB</ejb-name> <home>weblogic.ejb20.SecuritySLHome</home> <remote>weblogic.ejb20.SecuritySL</remote> <local-home> weblogic.ejb20.SecurityLocalSLHome </local-home> <local>weblogic.ejb20.SecurityLocalSL</local> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <session-type>Stateless</session-type> <transaction-type>Container</transaction-type> </session> <message-driven> <ejb-name>SecurityEJB</ejb-name> <ejb-class>weblogic.ejb20.SecuritySLBean</ejb-class> <transaction-type>Container</transaction-type> <security-identity> <run-as> <role-name>runAs_role_X</role-name> </run-as> </security-identity> <security-identity> <run-as> <role-name>runAs_role_Y</role-name> </run-as> </security-identity> </message-driven> </enterprise-beans> </ejb-jar> weblogic-ejb-jar file: <weblogic-ejb-jar> <weblogic-enterprise-bean> <ejb-name>A_EJB_with_runAs_role_X</ejb-name> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>B_EJB_with_runAs_role_X</ejb-name> <run-as-principal-name>Joe</run-as-principal-name> </weblogic-enterprise-bean> <weblogic-enterprise-bean> <ejb-name>C_EJB_with_runAs_role_Y</ejb-name> </weblogic-enterprise-bean> <security-role-assignment> <role-name>runAs_role_Y</role-name> <principal-name>Harry</principal-name> <principal-name>John</principal-name> </security-role-assignment> <run-as-role-assignment> <role-name>runAs_role_X</role-name> <run-as-principal-name>Fred</run-as-principal-name> </run-as-role-assignment> </weblogic-ejb-jar>
コード リスト 6-8 の 3 つの Bean はそれぞれ、run as として別々のプリンシパル名を選択します。
A_EJB_with_runAs_role_X
この Bean の run-as-role-name は runAs_role_X
です。使用するプリンシパルの名前のルックアップには、jar スコープの <run-as-role-assignment>
マッピングが使用されます。<run-as-role-assignment>
マッピングにより、<role-name> runAs_role_X
に対して、<run-as-principal-name>
Fred
を使用すべきであることが指定されます。したがって、使用されるプリンシパル名は Fred
です。
B_EJB_with_runAs_role_X
この Bean の run-as-role-name も runAs_role_X
です。この Bean は使用するプリンシパルの名前のルックアップに jar スコープの <run-as-role-assignment>
を使用することはありません。なぜなら、この値はこの Bean の <weblogic-enterprise-bean> <run-as-principal-name>
値である Joe
でオーバーライドされているからです。したがって、使用されるプリンシパル名は Joe
です。
C_EJB_with_runAs_role_Y
この Bean の run-as-role-name は runAs_role_Y
です。runAs_role_Y
の run-as プリンシパル名としての明示的なマッピングはありません。つまり、runAs_role_Y
に対する jar スコープの <run-as-role-assignment>
も、Bean スコープの <run-as-principal-name>
も、この Bean の <weblogic-enterprise-bean>
では指定されていません。使用するプリンシパル名を決定するには、<role-name>
runAs_role_Y
の <security-role-assignment>
を検証します。ユーザ (つまり、グループではない) に対応する最初の <principal-name>
が選択されます。したがって、使用されるプリンシパル名は Harry
です。
security-permission-spec
要素は、セキュリティ ポリシー ファイル構文に基づいて単一のセキュリティ パーミッションを指定します。
詳細については、Sun によるセキュリティ パーミッション仕様の実装を参照してください。
http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#FileSyntax
注意 : オプションの codebase および signedBy 句は無視してください。 |
security-permission-spec
要素の使用例については、コード リスト 6-9 を参照してください。
コード リスト 6-9 security-permission-spec 要素の例
<weblogic-ejb-jar> <security-permission> <description>Optional explanation goes here</description> <security-permission-spec> <! http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax の構文にしたがって、単一の grant 文をここで記述する。このとき、「codebase」および「signedBy」句は使用しない。次に例を示す --> grant { permission java.net.SocketPermission *, resolve; }; </security-permission-spec> </security-permission> </weblogic-ejb-jar>
コード リスト 6-9 では、permission java.net.SocketPermission
はパーミッション クラス名を、"*" は対象名を、resolve
(host/IP 名サービスのルックアップを解決する) はアクションを示します。
security-role-assignment
要素は、ejb-jar.xml
ファイル内のアプリケーション ロールを、ProductName で使用可能なセキュリティ プリンシパル名にマップします。
注意 : エンタープライズ アプリケーションで weblogic-application.xml デプロイメント記述子の security-role-assignment 要素を使用する方法については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。 |
transport-requirements
要素は、EJB の転送の要件を定義します。
transport-requirements
要素の使用例については、コード リスト 6-10 を参照してください。
コード リスト 6-10 transport-requirements 要素の例
<weblogic-enterprise-bean> <iiop-security-descriptor> <transport-requirements> <confidentiality>supported</confidentiality> <integrity>supported</integrity> <client-cert-authorization> supported </client-cert-authentication> </transport-requirements> </iiop-security-descriptor> <weblogic-enterprise-bean>
プログラムによるセキュリティを EJB に実装するには、javax.ejb.EJBContext
.getCallerPrincipal()
メソッドと javax.ejb.EJBContext.isCallerInRole()
メソッドを使用します。
getCallerPrincipal()
メソッドは、EJB の呼び出し側を特定するために使用します。javax.ejb.EJBContext
.getCallerPrincipal()
メソッドは、呼び出し元のユーザの Subject
に存在している場合に WLSUser
Principal
を返します。WLSUser
Principal
が複数の場合、このメソッドは、Subject.getPrincipals().iterator()
メソッドで指定された順序の 1 番目を返します。WLSUser
Principal
が存在しない場合、getCallerPrincipal()
メソッドは WLSGroup
Principal
以外の 1 番目を返します。Principals
が存在しない場合、またはすべての Principals
が WLSGroup
型の場合、このメソッドは weblogic.security.WLSPrincipals.getAnonymousUserPrincipal()
を返します。この動作は、weblogic.security.SubjectUtils.getUserPrincipal()
のセマンティクスとほぼ同じですが、EJBContext
.getCallerPrincipal()
は WLSPrincipals.getAnonmyousUserPrincipal()
を返すのに対し、SubjectUtils.getUserPrincipal()
は null
を返す点が異なります。
getCallerPrincipal()
メソッドの使用方法の詳細については、http://java.sun.com/javaee/technologies/javaee5.jsp
を参照してください。
呼び出し側 (現在のユーザ) に割り当てられているセキュリティ ロールにおいて、その実行スレッドでの WebLogic リソースに対するアクションの実行が許可されているかどうかを判定するには、isCallerInRole()
メソッドを使用します。たとえば、現在のユーザが admin
特権を持っている場合、javax.ejb.EJBContext.isCallerInRole("admin")
メソッドは true
を返します。
isCallerInRole()
メソッドの使用方法の詳細については、http://java.sun.com/javaee/technologies/javaee5.jsp
を参照してください。