Oracle® Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング 11g リリース1(10.3.4) B61619-02 |
|
前 |
次 |
WebLogic Serverは、Enterprise JavaBeans (EJB)を保護するJava EEアーキテクチャ・セキュリティ・モデルをサポートしています。これには、宣言による認可(このドキュメントでは宣言によるセキュリティとも呼びます)とプログラムによる認可(このドキュメントではプログラムによるセキュリティとも呼びます)のサポートが含まれます。
この節では、以下の内容について説明します。
注意: EJBの保護には、デプロイメント記述子ファイル、管理コンソールおよびJACCを使用できます。管理コンソールを使用したEJBの保護の詳細は、『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つの方法で実装できます。
管理コンソールを介したセキュリティ・プロバイダ: 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明されています。
Java Authorization Contract for Containers (JACC): 「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ファイルでセキュリティを構成する方法の詳細は、Sun Microsystemsの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要素で指定したロール名に適用する、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要素の例
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://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> <! 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://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
を参照してください。