5 Enterprise JavaBeans (EJB)の保護
-
ノート:
EJBの保護には、メタデータ・アノテーション、デプロイメント記述子ファイル、WebLogic Server管理コンソールおよびJACCを使用できます。WebLogic Server管理コンソールを使用したEJBの保護の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のWebアプリケーションおよびEJBリソースの保護のオプションを参照してください。JACCの詳細は、「Java Authorization Contract for Containersの使用」を参照してください。
Java EEアーキテクチャ・セキュリティ・モデル
エンタープライズ層とWeb層のアプリケーションは、様々なコンテナにデプロイされたコンポーネントから構成されています。これらのコンポーネントは組み合されて、多層構造のエンタープライズ・アプリケーションを構築します。コンポーネントのセキュリティは、コンテナが提供します。コンテナは、宣言によるものとプログラムによるものの2種類のセキュリティを提供します。
Java EEセキュリティ・アーキテクチャの詳細は、Java EEチュートリアル(リリース7)のJava EEセキュリティの概要に関する項を参照してください。
宣言によるセキュリティ
Java EEチュートリアル(リリース7)では、宣言によるセキュリティがデプロイメント記述子またはアノテーションのいずれかを使用して、アプリケーション・コンポーネントのセキュリティ要件を表現すると記述されています。
デプロイメント記述子は、アプリケーションの外部にあり、セキュリティ・ロール、アクセス制御、認証要件などの、アプリケーションのセキュリティ構造を表すXMLファイルです。
アノテーションは、メタデータとも呼ばれ、クラス・ファイルの範囲内でセキュリティに関する情報を指定するために使用されます。アプリケーションがデプロイされると、アプリケーション・デプロイメント記述子がこの情報を使用またはオーバーライドできます。アノテーションは、XML記述子に宣言情報を書き込む手間を省いてくれます。かわりに、コードにアノテーションを入れるだけで、要求された情報が生成されます。このチュートリアルでは、アノテーションは、可能なすべての場面でアプリケーションを保護するために使用されます。
アノテーションを使用した宣言による認可
EJB 3.xでは、デプロイヤのタスクをより簡単にするために、アプリケーション開発者がセキュリティ・ロールを定義できます。開発者は、セキュリティ・メタデータ・アノテーションをEJB Beanクラスに直接指定して、EJBのすべてのメソッドまたはそのサブセットを呼び出すことができるロールを特定できます。
Java EEチュートリアル(リリース7)の宣言によるセキュリティを使用したエンタープライズBeanの保護で説明されているように、宣言によるセキュリティを使用すると、アプリケーション開発者はどのユーザーがエンタープライズBeanのどのメソッドにアクセスできるかを指定できます。また、これらのユーザーをBASIC認証またはユーザー名とパスワードの認証によって認証することもできます。多くの場合、エンタープライズ・アプリケーションの開発者は、そのアプリケーションのデプロイヤとは異なります。宣言によるセキュリティを使用してメソッドのパーミッションと認証メカニズムを定義するアプリケーション開発者は、EJB JARに含まれるエンタープライズBeanのセキュリティに関する見解をデプロイヤに伝えます。セキュリティに関する見解がデプロイヤに伝えられると、デプロイヤはこの情報に基づいてセキュリティ・ロールのメソッドのパーミッションを定義します。セキュリティに関する見解が定義されていない場合、デプロイヤは、どのユーザーに各ビジネス・メソッドの呼び出しを認可するかを決定するために、そのメソッドでどのような処理が実行されるかを確認する必要があります。
デプロイメントの実行時、デプロイヤはこれらのセキュリティ・ロールが存在しない場合は作成し、それらのロールにユーザーをマップします。このマッピングは、WebLogic Server管理コンソールでセキュリティ・レルムを更新することによって行います。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理を参照してください。デプロイヤは、weblogic-ejb-jar.xmlデプロイメント記述子を使用して、任意のセキュリティ・ロールをユーザーにマップすることもできます。
ノート:
デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。
プログラムによるセキュリティ
Java EEチュートリアル(リリース7)では、エンタープライズBeanの場合、発信者のIDにプログラムでアクセスする際に使用され、この情報を使用してセキュリティの意思決定を行うビジネス・メソッドにコードが組み込まれていると記述されています。プログラムによるセキュリティは、宣言によるセキュリティだけではアプリケーションのセキュリティ・モデルを十分表せない場合に役に立ちます。プログラムによるセキュリティのAPIは、EJBContextインタフェースとHttpServletRequestインタフェースのメソッドから構成されます。これらのメソッドを使用すると、発信者またはリモート・ユーザーのセキュリティ・ロールに基づいて、コンポーネントがビジネス・ロジックの決定を下せます。
Java EEチュートリアル(リリース7)のエンタープライズBean発信者のセキュリティ・コンテキストへのアクセスでは、一般的に、エンタープライズBeanのビジネス・メソッドに透過的な方法で、コンテナがセキュリティ管理を強制的に適用する必要があると記述されています。この項で説明するセキュリティAPIは、アクセスを1日のうち特定の時間に制限する場合など、エンタープライズBeanビジネス・メソッドがセキュリティ・コンテキスト情報にアクセスする必要がある、頻度の少ない状況でのみ使用してください。
javax.ejb.EJBContextインタフェースには、BeanプロバイダがエンタープライズBeanの呼出し側に関するセキュリティ情報にアクセスするのを可能にする2つのメソッドが用意されています。
-
getCallerPrincipalを使用すると、エンタープライズBeanメソッドで現在の呼出し側プリンシパル名を取得できるようになります。このメソッドは、たとえば、名前をデータベース内で情報のキーとして使用する可能性があります。 -
isCallerInRoleを使用すると、開発者はメソッド・パーミッションで簡単に定義できないセキュリティ・チェックをコーディングできるようになります。そのようなチェックはリクエストにロール・ベースの制限を課す可能性がありますが、それがデータベースに格納される情報に依存する可能性もあります。エンタープライズBeanコードは、
isCallerInRoleメソッドを使用して、現在の呼出し側が指定のセキュリティ・ロールに割り当てられているかどうかをテストできます。セキュリティ・ロールはBeanプロバイダまたはアプリケーション・アセンブラで定義され、デプロイヤにより、操作環境の中に存在するプリンシパルまたはプリンシパル・グループに割り当てられます。
宣言による認可とプログラムによる認可
プログラムによるセキュリティは、宣言によるセキュリティだけではアプリケーションのセキュリティ・モデルを十分表せない場合に、セキュリティ対応のアプリケーションにより使用されます。最もよく機能する機密保護モデルを選択する場合、組織でセキュリティ管理の担当者を検討してください。開発者は作成するアプリケーション・コンポーネントを熟知していますが、必ずしも、それらのコンポーネントが実行されるデプロイメント環境に精通しているわけではありません。また、プログラムによってセキュリティ・アップデートをする場合、セキュリティ・ポリシーの変更に伴ってアプリケーションをリビルド、再テスト、再デプロイすることが必要になることがありますが、それより宣言によってセキュリティを再構成する方が、より無駄がありません。
「アノテーションを使用した宣言による認可」で説明しているように、アプリケーション開発者は、デプロイヤのタスクをより簡単にするために、セキュリティ・メタデータ・アノテーションをEJB Beanクラスに直接指定して、EJBのすべてのメソッドまたはそのサブセットを呼び出すことができるロールを特定できます。ただし、デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドするため、デプロイヤが最終的な制御を行います。
EJBでの宣言によるセキュリティの使用
管理コンソールからセキュリティ・プロバイダを使用して、またはJava Authorization Contract for Containers (JACC)を使用して、宣言によるセキュリティを実装できます。また、宣言によるセキュリティを実装するために、デプロイメント記述子およびメタデータ・アノテーションを使用します。
宣言によるセキュリティは、以下の3つの方法で実装できます。
-
WebLogic Server管理コンソールを介したセキュリティ・プロバイダ: 『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』で説明されています。
-
JACC (Java Authorization Contract for Containers): 「Java Authorization Contract for Containersの使用」で説明されています。
-
デプロイメント記述子およびメタデータ・アノテーション: ここで説明します。
これら3つのうちどの方法を使用するかは、JACCフラグとセキュリティ・モデルによって定義されます。(セキュリティ・モデルについては、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のEJBおよびWebアプリケーション・リソースの保護のオプションを参照してください)
メタデータ・アノテーションを使用した宣言によるセキュリティの実装
EJB 3.0では(『Oracle WebLogic Server Enterprise JavaBeansの開発』のEJB 3.0の新機能と変更された機能に関する項を参照してください)、デプロイメント記述子ファイル(ejb-jar.xmlなど)を作成する必要がなくなります。Beanファイル自体の中で、メタデータ・アノテーションを使用してメタデータを構成できます。
必要に応じて、引き続きXMLデプロイメント記述子をメタデータ・アノテーションに加えて、またはそのかわりに使用することもできます。
ノート:
デプロイメント記述子要素は、対応するアノテーションを常にオーバーライドします。競合がある場合、デプロイメント記述子の値がアノテーションの値をオーバーライドします。
メタデータ・アノテーションを使用するには:
-
メタデータ・アノテーション機能を使用して、アノテーション付きのEJB Beanファイルを作成します。
-
デプロイメントの実行時、デプロイヤはこれらのセキュリティ・ロールが存在しない場合は作成し、それらのロールにユーザーをマップする必要があります。このマッピングは、WebLogic Server管理コンソールでセキュリティ・レルムを更新することによって行います。Oracle WebLogic Server管理コンソール・オンライン・ヘルプのセキュリティ・ロールの管理に関する項を参照してください。
アノテーションはjavax.security.annotationパッケージに含まれています。次のセキュリティ関連アノテーションを使用できます。
-
javax.annotation.security.DeclareRoles — EJBの保護に使用するセキュリティ・ロールのリストを明示的に宣言します。
-
javax.annotation.security.RolesAllowed — EJBのメソッドを呼び出すことができるセキュリティ・ロールを指定します。すべてのメソッドを呼び出すことができるロールはクラス・レベルで指定し、特定のメソッドのみを呼び出すことができるロールはメソッド・レベルで指定します。
-
javax.annotation.security.DenyAll — どのロールでも呼び出すことができないメソッドを指定します。
-
javax.annotation.security.PermitAll — どのロールでも呼び出すことができるメソッドを指定します。
-
javax.annotation.security.RunAs — EJBを実行するロールを指定します。デフォルトでは、EJBはそれを実際に呼び出したユーザーとして実行されます。
セキュリティ関連アノテーションのコード例
Oracle WebLogic Server Enterprise JavaBeansの開発のEJBへのアクセスの保護では、すべてのセキュリティ関連アノテーションを使用する単純なステートレス・セッションEJBの例が示されています。
Java EE 7 TutorialのSpecifying Authorized Users by Declaring Security Rolesでは、アノテーションを使用してBeanクラスのメソッドに関するメソッド・パーミッションを指定する方法の説明、およびそれに付随するコード例も提供されます。
デプロイメント記述子を使用した宣言によるセキュリティの実装
EJBに宣言によってセキュリティを実装するには、デプロイメント記述子(ejb-jar.xmlおよびweblogic-ejb-jar.xml)を使用してセキュリティ要件を定義します。例5-1は、ejb-jar.xmlおよびweblogic-ejb-jar.xmlデプロイメント記述子を使用してセキュリティ・ロール名をセキュリティ・レルムにマップする例を示しています。デプロイメント記述子は、アプリケーションの論理的なセキュリティ要件を実行時の定義にマップします。また、実行時には、EJBコンテナがセキュリティ定義を使って要件を実施します。
EJBデプロイメント記述子でセキュリティを構成するには、次のステップを実行します(例5-1を参照):
例5-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のセキュリティ関連のデプロイメント記述子
WebLogic Serverでは、EJBのセキュリティ要件を定義するためにejb-jar.xml およびweblogic-ejb-jar.xmlファイルで使用されるいくつかのデプロイメント記述子の要素をサポートします。
ejb-jar.xmlデプロイメント記述子
以下のejb-jar.xmlデプロイメント記述子の要素が、WebLogic Serverでセキュリティ要件を定義するために使用されます。
method
method要素は、エンタープライズBeanのホームまたはコンポーネント・インタフェースのメソッド、あるいはメッセージドリブンBeanの場合にBeanのonMessageメソッド(またはメソッドのセット)を示すために使用されます。
次の表では、method要素内で定義できる要素について説明します。
表5-1 method要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
メソッドの説明文。 |
<ejb-name> |
必須 |
|
<method-intf> |
省略可能 |
エンタープライズBeanのホーム・インタフェースとコンポーネント・インタフェースの両方で定義されて同じ署名を持つメソッドを識別できるようにします。 |
<method-name> |
必須 |
エンタープライズBeanのメソッド名またはアスタリスク(*)を指定します。アスタリスクは、要素がエンタープライズBeanのコンポーネントおよびホーム・インタフェースのすべてのメソッドを表す場合に使用します。 |
<method-params> |
省略可能 |
Javaタイプのメソッド・パラメータの完全修飾名のリストが含まれます。 |
method-permission
method-permission要素では、1つまたは複数のエンタープライズBeanメソッドの呼出しを許可されている1つまたは複数のセキュリティ・ロールを指定します。method-permission要素は、説明(オプション)、セキュリティ・ロール名のリストまたはメソッドが認可に関してチェックされない状態を示すインジケータ、およびメソッドの要素のリストから成ります。
method-permission要素内のセキュリティ・ロールは、デプロイメント記述子のsecurity-role要素で定義されており、メソッドは、エンタープライズBeanのコンポーネントまたはホーム・インタフェースで定義されているメソッドでなければなりません。
次の表では、method-permission要素内で定義できる要素について説明します。
表5-2 method-permission要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
このセキュリティ制約の説明文。 |
<role-name>または<unchecked> |
必須 |
|
<method> |
必須 |
エンタープライズBeanのホームまたはコンポーネント・インタフェースのメソッド、あるいはメッセージドリブンBeanの場合にBeanの |
security-identity
security-identity要素には、エンタープライズBeanのメソッドを実行するために呼出し側のセキュリティIDを使用するか、または特定のrun-as IDを使用するかを指定します。この要素には、省略可能な説明と使用するセキュリティIDの指定が含まれます。
次の表では、security-identity要素内で定義できる要素について説明します。
表5-3 security-identity要素
| 要素 | 必須/省略可能 | 説明 |
|---|---|---|
<description> |
省略可能 |
セキュリティIDの説明文。 |
<use-caller-identity>または<run-as> |
必須 |
run-as要素には、エンタープライズBeanを実行するためのrun-as IDを指定します。この要素には、省略可能な説明とセキュリティ・ロールの名前が含まれます。 |
security-role-ref
security-role-ref要素には、エンタープライズBeanのコード内のセキュリティ・ロール参照の宣言が含まれます。この宣言は、省略可能な説明、コードで使用されているセキュリティ・ロール名、およびセキュリティ・ロールへのリンク(オプション)から成ります。セキュリティ・ロールが指定されていない場合、デプロイヤが適切なセキュリティ・ロールを選択する必要があります。
role-name要素の値は、EJBContext.isCallerInRole(String roleName)メソッドまたはHttpServletRequest.isUserInRole(String role)メソッドに対するパラメータとして使用されるStringでなければなりません。
例
security-role-ref要素の使用例については、例5-2を参照してください。
例5-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
use-caller-identity要素には、エンタープライズBeanのメソッドを実行するためのセキュリティIDとして、呼出し側のセキュリティIDを使用することを指定します。
例
use-caller-identity要素の使用例については、例5-3を参照してください。
例5-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-ejb-jar.xmlデプロイメント記述子の要素が、WebLogic Serverでセキュリティ要件を定義するために使用されます。
client-authentication
client-authentication要素は、EJBがクライアント認証をサポートするか、または、必要とするかを指定します。
次の表では、指定可能な設定を定義しています。
表5-4 client-authentication要素
| 設定 | 定義 |
|---|---|
none |
クライアント認証はサポートされません。 |
supported |
クライアント認証はサポートされますが、必須ではありません。 |
required |
クライアント認証は必須となります。 |
client-cert-authentication
client-cert-authentication要素は、EJBがトランスポート・レベルでのクライアント証明書認証をサポートするか、または、必要とするかを指定します。
次の表では、指定可能な設定を定義しています。
表5-5 client-cert-authentication要素
| 設定 | 定義 |
|---|---|
none |
クライアント証明書認証はサポートされません。 |
supported |
クライアント証明書認証はサポートされますが、必須ではありません。 |
required |
クライアント証明書認証は必須となります。 |
confidentiality
confidentiality要素は、そのEJBにおけるトランスポートの機密性の要件を指定します。confidentiality 要素を使用すると、他のエンティティに内容を見られることなく、クライアントとサーバー間でデータが送信されるようになります。
次の表では、指定可能な設定を定義しています。
表5-6 confidentiality要素
| 設定 | 定義 |
|---|---|
none |
機密性はサポートされません。 |
supported |
機密性はサポートされますが、必須ではありません。 |
required |
機密性は必須となります。 |
externally-defined
externally-defined要素を使用すると、weblogic-ejb-jar.xmlデプロイメント記述子のrole-name要素によって定義されたセキュリティ・ロールがWebLogic Server管理コンソールで指定したマッピングを使用するよう指定できます。この要素を使用することで、特定のWebアプリケーションのデプロイメント記述子に定義されたセキュリティ・ロールごとに特定のセキュリティ・ロール・マッピングを指定する必要がなくなります。このため、同じセキュリティ・レルムの中で、デプロイメント記述子を使用して一部のアプリケーションのセキュリティを指定および変更する一方、WebLogic Server管理コンソールを使用して他のアプリケーションのセキュリティを指定および変更できます。
ノート:
バージョン9.0からは、何も指定されていない場合は空のロール・マッピングが作成されるのが、ロール・マッピングのデフォルト動作になりました。バージョン8.1のEJBでは、ロール・マッピングをweblogic-ejb-jar.xml記述子に定義しないと、デプロイメントに失敗していました。9.0では、空のロール・マッピングを作成する際のEJBとWebAppの動作の矛盾がなくなりました。
ロール・マッピングの動作および後方互換性の設定の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護の「ロール・マッピングの組合せを有効化」設定の理解を参照してください。サーバーのロール・マッピングの動作は、WebLogic Server管理コンソールでどのセキュリティ・デプロイメント・モデルを選択したかによって異なります。セキュリティ・デプロイメント・モデルの詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のEJBおよびWebアプリケーション・リソースの保護のオプションを参照してください。
セキュリティ・ロール名を指定する場合には、以下の規約と制限に従ってください。
-
セキュリティ・ロール名の正しい構文は、XML (Extensible Markup Language)推奨仕様で
Nmtokenに関して定義されているとおりです(http://www.w3.org/TR/REC-xml#NT-Nmtoken)。 -
スペース、カンマ、ハイフン、\t、< >、#、|、&、~、?、( )、{ }を使用しないでください。
-
セキュリティ・ロール名では大文字と小文字が区別されます。
-
推奨されるネーミング・ルールでは、セキュリティ・ロール名は単数形です。
例5-4と例5-5は、weblogic-ejb-jar.xmlファイルでexternally-defined要素を使用する方法を比較して示しています。例5-5で、weblogic-ejb-jar.xml内の「manager」のexternally-defined要素は、セキュリティがgetReceiptsメソッドにおいて正しく構成されるにはWebLogic Server管理コンソールでmanagerに対応するプリンシパルが作成される必要がある、ということを意味します。
例5-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>
... 例5-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>
...
WebLogic Server管理コンソールを使用したEJBの保護の構成の詳細は、Oracle WebLogic Serverロールおよびポリシーによるリソースの保護のWebアプリケーションおよびEJBリソースの保護のオプションを参照してください。
identity-assertion
identity-assertion要素は、EJBがIDアサーションをサポートするかどうかを指定します。
次の表では、指定可能な設定を定義しています。
表5-7 identity-assertion要素
| 設定 | 定義 |
|---|---|
none |
IDアサーションはサポートされません。 |
supported |
IDアサーションはサポートされますが、必須ではありません。 |
required |
IDアサーションは必須となります。 |
iiop-security-descriptor
iiop-security-descriptor要素は、Beanレベルのセキュリティ構成パラメータを指定します。これらのパラメータにより、インターオペラブル・オブジェクト参照(IOR)に含まれるIIOPセキュリティ情報が決定します。
例
iiop-security-descriptor要素の使用例については、例5-6を参照してください。
例5-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
integrity要素は、そのEJBのトランスポートの整合性の要件を指定します。integrity要素を使用すると、クライアントとサーバー間で、データが途中で変更することなく転送されるようになります。
次の表では、指定可能な設定を定義しています。
表5-8 integrity要素
| 設定 | 定義 |
|---|---|
none
|
整合性はサポートされません。 |
supported
|
整合性はサポートされますが、必須ではありません。 |
required
|
整合性は必須となります。 |
principal-name
Principal-name要素には、security-role-assignment要素で指定したロール名に適用する、WebLogic Serverセキュリティ・レルム内のプリンシパルの名前を指定します。security-role-assignment要素には、最低1つのprincipalが必要です。各ロール名に対しては、複数のprincipal-nameを定義できます。
ノート:
大量のプリンシパルをリストする必要がある場合は、ユーザーのかわりにグループを指定することを検討してください。指定したユーザーが多すぎると、パフォーマンスが低下するおそれがあります。
role-name
role-name要素は、EJBプロバイダが対応するejb-jar.xmlファイルで指定されたアプリケーション・ロール名を示します。スタンザの次のprincipal-name要素で、WebLogic Serverプリンシパルを、指定したrole-nameにマップします。
run-as-identity-principal
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要素の使用例については、例5-7を参照してください。
例5-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
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
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要素の使用例については、例5-8を参照してください。
例5-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>
例5-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
security-permission-spec要素は、セキュリティ・ポリシー・ファイル構文に基づいて単一のセキュリティ許可を指定します。
セキュリティ・パーミッション仕様の実装を参照してください。
http://docs.oracle.com/javase/8/docs/technotes/guides/security/PolicyFiles.html#FileSyntax
ノート:
オプションのcodebaseおよびsignedBy句は無視してください。
例
security-permission-spec要素の使用例については、例5-9を参照してください。
例5-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://xmlns.jcp.org/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>
例5-9では、permission java.net.SocketPermissionは許可クラス名を、"*"はターゲット名を、resolve (host/IP名サービスのルックアップを解決する)はアクションを示します。
security-role-assignment
security-role-assignment要素は、ejb-jar.xmlファイル内のアプリケーション・ロールを、WebLogic Serverで使用可能なセキュリティ・プリンシパル名にマップします。
ノート:
エンタープライズ・アプリケーションのweblogic-application.xmlデプロイメント記述子でsecurity-role-assignment要素を使用する方法の詳細は、Oracle WebLogic Serverアプリケーションの開発のエンタープライズ・アプリケーションのデプロイメント記述子の要素を参照してください。
transport-requirements
transport-requirements要素は、EJBのトランスポートの要件を定義します。
例
transport-requirements要素の使用例については、例5-10を参照してください。
例5-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でのプログラムによるセキュリティの使用
WebLogic Serverは、EJBでプログラムによるセキュリティを実装するために、javax.ejb.EJBContext.getCallerPrincipal()メソッドおよびjavax.ejb.EJBContext.isCallerInRole()メソッドの使用をサポートします。
getCallerPrincipal
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を参照してください。
isCallerInRole
呼出し側(現在のユーザー)に割り当てられているセキュリティ・ロールにおいて、その実行スレッドでのWebLogicリソースに対するアクションの実行が許可されているかどうかを判定するには、isCallerInRole()メソッドを使用します。たとえば、現在のユーザーがadmin権限を持っている場合、javax.ejb.EJBContext.isCallerInRole("admin")メソッドはtrueを返します。
isCallerInRole()メソッドの使用方法の詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.htmlを参照してください。