| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング 11g リリース1(10.3.6) B61619-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング 11g リリース1(10.3.6) B61619-04 |
|
前 |
次 |
WebLogic Serverは、Enterprise JavaBeans (EJB)を保護するJava EEアーキテクチャ・セキュリティ・モデルをサポートしています。これには、宣言による認可(このドキュメントでは宣言によるセキュリティとも呼びます)とプログラムによる認可(このドキュメントではプログラムによるセキュリティとも呼びます)のサポートが含まれます。
この節では、以下の内容について説明します。
|
注意: EJBの保護には、デプロイメント記述子ファイル、管理コンソールおよびJACCを使用できます。管理コンソールを使用したEJBの保護の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。JACCの詳細は、「Java Authorization Contract for Containersの使用」を参照してください。 |
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3 Authorization」に次のような記述があります。
「J2EEアーキテクチャにおいて、コンテナはホストするコンポーネントとその呼出し側との間の認可境界として機能します。認可境界はコンテナの認証境界内に存在するので、正常に認証が実行される中で認可が考慮されます。着信呼出しの場合、コンテナは呼出し側の資格証明のセキュリティ属性と、ターゲット・コンポーネントのアクセス制御ルールを比較します。ルール要件が満たされていれば、呼出しは許可されます。それ以外の場合、この呼出しは拒否されます。
「アクセス制御ルールの定義には、能力と許可という2つの基本的アプローチが存在します。能力は呼出し側が実行できる操作、許可は操作を実行できるユーザーを焦点とします。許可では、何かをできるのは誰かに重点が置かれます。J2EEアプリケーション・プログラミング・モデルは、許可に焦点を当てます。J2EEアーキテクチャにおいて、デプロイヤの役割は、アプリケーションの許可モデルをその操作環境におけるユーザーの能力にマップすることです。」
同じドキュメントでは続けて、Java EEアーキテクチャを使用してアプリケーション・リソースへのアクセスを制御する2つの方法 - 宣言による認可とプログラムによる認可 - について説明しています。
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.1 Authorization」に次のような記述があります。
「デプロイヤは、J2EEアプリケーションと関連のコンテナによって実施されるアクセス制御ルールを設定します。デプロイヤは、デプロイメント・ツールを使用して、通常はアプリケーション・アセンブラによって供給されるアプリケーション許可モデルを、操作環境に固有のポリシーおよびメカニズムにマップします。アプリケーション許可モデルは、デプロイメント記述子で定義されます。」
WebLogic ServerはEJBにおいて宣言による認可を実装するためのデプロイメント記述子の使用をサポートしています。
|
注意: 宣言による認可は、このドキュメントでは宣言によるセキュリティとも呼ばれます。 |
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。
ドキュメント『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要素の使用をサポートしています。
|
注意: プログラムによる認可は、このドキュメントではプログラムによるセキュリティとも呼ばれます。 |
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』の「Section 9.3.3 Declarative Versus Programmatic Authorization」に次のような記述があります。
「デプロイヤによって構成される外部アクセス制御ポリシーと、コンポーネント・プロバイダによってアプリケーションに組み込まれた内部ポリシーとの間にはトレードオフが存在します。アプリケーションが作成された後では、外部ポリシーのほうが高い融通性を持ちます。アプリケーションが記述されている過程では、内部ポリシーのほうが融通性の高い機能を提供します。また、外部ポリシーはデプロイヤにとって透過的で完全に理解可能であるのに対し、内部ポリシーはアプリケーションに埋め込まれており、これを完全に理解できるのはアプリケーション開発者のみである可能性があります。ある特定のコンポーネントとメソッドについて認可モデルを選択する際には、これらのトレードオフを検討する必要があります。
ドキュメント『Designing Enterprise Applications with the J2EE Platform, Second Edition』は、http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/security/security4.htmlからオンラインで入手できます。
宣言によるセキュリティは、以下の3つの方法で実装できます。
管理コンソールを介したセキュリティ・プロバイダ: 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明されています。
JACC (Java Authorization Contract for Containers): 「Java Authorization Contract for Containersの使用」で説明されています。
デプロイメント記述子 - この項で説明します。
これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。)
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ファイルでセキュリティを構成する方法の詳細は、Enterprise JavaBeans仕様2.0( |
WebLogic固有のEJBデプロイメント記述子ファイルweblogic-ejb-jar.xmlにセキュリティ・ロール名を定義し、それをセキュリティ・レルム内の1つまたは複数のプリンシパル(ユーザーまたはグループ)にリンクします。
weblogic-ejb-jar.xmlファイルでセキュリティを構成する方法の詳細は、『Oracle WebLogic Server WebLogic 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> or <unchecked> |
必須 |
|
<method> |
必須 |
エンタープライズBeanのホームまたはコンポーネント・インタフェースのメソッド、あるいはメッセージドリブンBeanの場合にBeanの |
security-identity要素には、エンタープライズBeanのメソッドを実行するために呼出し側のセキュリティIDを使用するか、または特定のrun-as IDを使用するかを指定します。この要素には、省略可能な説明と使用するセキュリティIDの指定が含まれます。
次の表では、security-identity要素内で定義できる要素について説明します。
表6-3 security-identity要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
セキュリティIDの説明文。 |
<use-caller-identity> or <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要素
| 設定 | 定義 |
|---|---|
none |
クライアント認証はサポートされません。 |
supported |
クライアント認証はサポートされますが、必須ではありません。 |
required |
クライアント認証は必須となります。 |
client-cert-authentication要素は、EJBがトランスポート・レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。
次の表では、指定可能な設定を定義しています。
表6-5 client-cert-authentication要素
| 設定 | 定義 |
|---|---|
none |
クライアント証明書認証はサポートされません。 |
supported |
クライアント証明書認証はサポートされますが、必須ではありません。 |
required |
クライアント証明書認証は必須となります。 |
confidentiality要素は、そのEJBにおけるトランスポートの機密性の要件を指定します。confidentiality 要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバー間でデータが送信されるようになります。
次の表では、指定可能な設定を定義しています。
表6-6 confidentiality要素
| 設定 | 定義 |
|---|---|
none |
機密性はサポートされません。 |
supported |
機密性はサポートされますが、必須ではありません。 |
required |
機密性は必須となります。 |
externally-defined要素を使用すると、weblogic-ejb-jar.xmlデプロイメント記述子のrole-name要素によって定義されたセキュリティ・ロールが管理コンソールで指定したマッピングを使用するよう指定できます。この要素を使用することで、特定のWebアプリケーションのデプロイメント記述子に定義されたセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。このため、同じセキュリティ・レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、管理コンソールを使用して他のアプリケーションのセキュリティを指定および変更できます。
|
注意: バージョン9.0からは、何も指定されていない場合は空のロール・マッピングが作成されるのが、ロール・マッピングのデフォルト動作になりました。バージョン8.1のEJBでは、ロール・マッピングをweblogic-ejb-jar.xml記述子に定義しないと、デプロイメントに失敗していました。9.0では、空のロール・マッピングを作成する際のEJBとWebAppの動作の矛盾がなくなりました。ロール・マッピングの動作および下位互換性の設定の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ロール・マッピングの組合せを有効化」設定の理解に関する項を参照してください。サーバーのロール・マッピングの動作は、管理コンソールでどのセキュリティ・デプロイメント・モデルを選択したかによって異なります。セキュリティ・デプロイメント・モデルの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のEJBおよびWebアプリケーション・リソースの保護のオプションに関する項を参照してください。 |
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
セキュリティ・ロール名の正しい構文は、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メソッドにおいて正しく構成されるには管理コンソールで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>
...
管理コンソールを使用したEJBのセキュリティ構成の詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』を参照してください。
identity-assertion要素は、EJBがIDアサーションをサポートするかどうかを指定します。
次の表では、指定可能な設定を定義しています。
表6-7 identity-assertion要素
| 設定 | 定義 |
|---|---|
none |
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要素で指定したロール名に適用する、ProductNameセキュリティ・レルム内のプリンシパルの名前を指定します。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要素の例
In the ejb-jar.xml file:
// Beans "A_EJB_with_runAs_role_X" and "B_EJB_with_runAs_role_X"
// specify a security-identity run-as role-name "runAs_role_X".
// Bean "C_EJB_with_runAs_role_Y" specifies a 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://download.oracle.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>
<!
A single grant statement following the syntax of
http://java.sun.com/j2se/1.5.0/docs/guide/security/PolicyFiles.html#FileSyntax,
without the codebase and signedBy clauses, goes here. For example:
-->
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 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://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。
呼出し側(現在のユーザー)に割り当てられているセキュリティ・ロールにおいて、その実行スレッドでのWebLogicリソースに対するアクションの実行が許可されているかどうかを判定するには、isCallerInRole()メソッドを使用します。たとえば、現在のユーザーがadmin権限を持っている場合、javax.ejb.EJBContext.isCallerInRole("admin")メソッドはtrueを返します。
isCallerInRole()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。
