10g（10.1.3.1.0）
B31852-03
 目次 |
 索引 |
| Oracle Containers for J2EE Enterprise JavaBeans開発者ガイド 10g（10.1.3.1.0） B31852-03 |
|
この章では、Java EEアプリケーションに特に適用される次のようなセキュリティ・サービス構成について説明します。
詳細は、次を参照してください。
Security ManagerがアクティブなクライアントでEJBアプリケーションをダウンロードする場合は、ダウンロードの前に次の権限を付与する必要があります。
permission java.net.SocketPermission "*:*", "connect,resolve"; permission java.lang.RuntimePermission "createClassLoader"; permission java.lang.RuntimePermission "getClassLoader"; permission java.util.PropertyPermission "*", "read"; permission java.util.PropertyPermission "LoadBalanceOnLookup", "read,write";
EJBの認証と認可については、EJBデプロイメント・ディスクリプタを構成して、各メソッドを実行する基礎となるプリンシパルを定義します。コンテナでは、メソッドを実行するユーザーが、デプロイメント・ディスクリプタで定義されたユーザーと同じであることが必要です。
EJBデプロイメント・ディスクリプタを使用すると、各メソッドを実行できるセキュリティ・ロールを定義できます。このメソッドは、OC4J固有のデプロイメント・ディスクリプタで、ユーザーまたはグループにマッピングされます。ユーザーとグループは、指定したセキュリティ・ユーザー・マネージャ（Oracle Application Server Java Authentication and Authorization Service（JAAS）Provider（OracleAS JAAS Provider）またはXMLユーザー・マネージャのいずれかを使用）内で定義されます。セキュリティ・ユーザー・マネージャの詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
この項では、認証と認可に関して、EJBデプロイメント・ディスクリプタ内のXML構成を説明します。EJBの認可は、EJBおよびOC4J固有のデプロイメント・ディスクリプタ内で指定されます。セキュリティの許可の部分は、次のように、デプロイメント・ディスクリプタ内で管理できます。
ユーザーおよびグループは、コンテナによって認識される認識情報です。ロールは、アプリケーションが、各オブジェクトへのアクセス権を示すために使用する論理識別情報です。ユーザー名およびパスワードには、デジタル証明が使用可能で、SSLの場合、秘密鍵も使用可能です。
ロールの定義およびマッピングを、図22-1に示します。
ユーザー、グループおよびロールの定義について、次の各項で説明します。
OC4Jでは、ユーザーおよびグループの定義をサポートしています。これには、すべてのデプロイ済アプリケーションで共有されているものと、特定のアプリケーション固有のものの両方が含まれます。共有またはアプリケーション固有のユーザーとグループは、OracleAS JAAS ProviderまたはXMLユーザー・マネージャのいずれかで定義します。詳細は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
図22-2に示すように、Bean実装内でロールの論理名を使用して、この論理名を適切なデータベース・ロールまたはユーザーにマッピングできます。論理名のデータベース・ロールへのマッピングは、OC4J固有のデプロイメント・ディスクリプタで指定されます。詳細は、
「ユーザーおよびグループへの論理ロールのマッピング」を参照してください。
isCallerInRoleなどのメソッドのBean実装内でデータベース・ロールの論理名を使用する場合は、次の手順を実行して、実際のデータベース・ロールに論理名をマッピングできます。
<enterprise-beans>セクションの<security-role-ref>要素内で論理名を宣言します。たとえば、発注の例で使用するロールを定義する場合は、Bean実装内で、コール元が発注にサインする認可を受けているかどうかをチェックしておくことができます。したがって、コール元は、適切なロールでサインオンする必要があります。Beanによるデータベース・ロールの認識を不要にするため、POMgrなどの論理名でisCallerInRoleをチェックできます。これは、注文を承認できるのは発注マネージャのみであるためです。したがって、論理セキュリティ・ロールのPOMgrを、次のように、<enterprise-beans>セクションの<security-role-ref><role-name>要素で定義します。
<enterprise-beans> ... <security-role-ref> <role-name>POMgr</role-name> <role-link>myMgr</role-link> </security-role-ref> </enterprise-beans>
<security-role-ref>要素内の<role-link>要素は、実際のデータベース・ロールの場合があり、<assembly-descriptor>セクション内で詳細に定義されます。また、この要素は別の論理名の場合があり、<assembly-descriptor>セクションで詳細に定義され、Oracle固有のデプロイメント・ディスクリプタ内で実際のデータベース・ロールにマッピングされます。
PurchaseOrder Beanで実行されるメソッドは、myMgrとして認可されている必要があります。PurchaseOrderは、<entity | session><ejb-name>要素で宣言された名前です。 次の例では、ロールをmyMgr、Enterprise BeanをPurchaseOrder、およびすべてのメソッドを*記号で示して定義しています。
<assembly-descriptor> <security-role> <description>Role needed purchase order authorization</description> <role-name>myMgr</role-name> </security-role> <method-permission> <role-name>myMgr</role-name> <method> <ejb-name>PurchaseOrder</ejb-name> <method-name>*</method-name> </method> </method-permission> ... </assembly-descriptor>
前述の2つの手順を実行した後は、Bean実装内でPOMgrを参照でき、コンテナはPOMgrをmyMgrに変換します。
Enterprise Beanメソッドの起動を許可されるセキュリティ・ロールを指定できます。
EJB 3.0アプリケーションでは、アノテーションを使用できます（「アノテーションの使用方法」を参照）。
EJB 3.0またはEJB 2.1アプリケーションでは、ejb-jar.xmlデプロイメント・ディスクリプタを使用できます（「デプロイXMLの使用方法」を参照）。
EJB 3.0アプリケーションでは、例22-1に示すように@RolesAllowedアノテーションを使用して、アプリケーションでのメソッドへのアクセスを許可されるセキュリティ・ロールを指定できます。
@RolesAllowed("Users")
public class Calculator {
@RolesAllowed("Administrator")
public void setNewRate(int rate) {
...
}
}
このアノテーションは、クラス、メソッドまたはその両方に適用できます。
メソッドに適用される場合、指定によってクラス指定がオーバーライドされます（存在する場合）。
セキュリティ・アノテーションの詳細は、「EJB 3.0セキュリティ・アノテーションの使用方法」を参照してください。
<method-permission><method>要素を使用して、インタフェースまたは実装内の1つ以上のメソッドについてセキュリティ・ロールを指定します。この定義は、EJB仕様に従って、次のいずれかの形式になります。
<method-permission> <role-name>myMgr</role-name> <method> <ejb-name>EJBNAME</ejb-name> <method-name>*</method-name> </method> </method-permission>
<method-permission> <role-name>myMgr</role-name> <method> <ejb-name>myBean</ejb-name> <method-name>myMethodInMyBean</method-name> </method> </method-permission>
<method-permission> <role-name>myMgr</role-name> <method> <ejb-name>myBean</ejb-name> <method-name>myMethod</method-name> <method-params> <method-param>javax.lang.String</method-param> <method-param>javax.lang.String</method-param> </method-params> </method> </method-permission>
パラメータは、完全に修飾されたJavaタイプのメソッドの入力パラメータです。メソッドに入力引数がない場合、<method-params>要素内に要素は含まれません。配列を指定するには、配列要素のタイプの後に1つ以上の角カッコ（int[ ] [ ]など）を指定します。
特定のメソッドでセキュリティ・ロールをチェックしないようにするには、そのメソッドをチェックなしとして定義します。
EJB 3.0アプリケーションでは、アノテーションを使用できます（「アノテーションの使用方法」を参照）。
EJB 3.0またはEJB 2.1アプリケーションでは、ejb-jar.xmlデプロイメント・ディスクリプタを使用できます（「デプロイXMLの使用方法」を参照）。
EJB 3.0アプリケーションでは、例22-2に示すように@PermitAllアノテーションを使用して、すべてのセキュリティ・ロールがアプリケーションでのメソッドへのアクセスを許可されるように指定できます。
@RolesAllowed("Users")
public class Calculator {
@RolesAllowed("Administrator")
public void setNewRate(int rate) {
...
}
@PermitAll
public long convertCurrency(long amount) {
...
}
}
このアノテーションは、クラスまたはメソッドに適用できます。
クラスに適用される場合、指定はすべてのメソッドに適用されます。
メソッドに適用される場合、指定はそのメソッドにのみ適用されます。
このアノテーションを使用する場合は、「EJB 3.0セキュリティ・アノテーションの使用方法」で説明する制限に注意してください。
次のように<method-permission><unchecked>要素を使用して、すべてのセキュリティ・ロールがメソッドへのアクセスを許可されるように指定します。
<method-permission> <unchecked/> <method> <ejb-name>EJBNAME</ejb-name> <method-name>*</method-name> </method> </method-permission>
<role-name>要素を定義するかわりに、<unchecked/>要素を定義します。これによって、EJBNAME Beanで任意のメソッドを実行すると、コンテナはセキュリティをチェックしません。チェックなしのメソッドは、常に、他のロール定義をオーバーライドします。
Enterprise Beanのすべてのメソッドが特定の識別情報を使用して実行されるように指定できます。つまり、コンテナは、特定のメソッドを実行する許可について別のロールをチェックせず、かわりに、指定されたセキュリティ識別情報を使用してすべてのEnterprise Beanメソッドを実行します。セキュリティ識別情報として、特定のロールまたはコール元の識別情報を指定できます。
EJB 3.0アプリケーションでは、アノテーションを使用できます（「アノテーションの使用方法」を参照）。
EJB 3.0またはEJB 2.1アプリケーションでは、ejb-jar.xmlデプロイメント・ディスクリプタを使用できます（「デプロイXMLの使用方法」を参照）。
EJB 3.0アプリケーションでは、例22-3に示すように@RunAsアノテーションを使用して、Java EEコンテナでの実行中にアプリケーションのロールを指定できます。
@RunAs("Admin")
public class Calculator {
...
}
このアノテーションは、クラスに適用できます。
セキュリティ・アノテーションの詳細は、「EJB 3.0セキュリティ・アノテーションの使用方法」を参照してください。
runAsセキュリティ識別情報は、<enterprise-beans>セクションの<security-identity>要素で指定します。次のXMLは、すべてのエンティティBeanメソッドがPOMgrというロールを使用して実行されることを示します。
<enterprise-beans> <entity> ... <security-identity> <run-as> <role-name>POMgr</role-name> </run-as> </security-identity> ... </entity> </enterprise-beans>
また、次のXMLの例は、コール元の識別情報を使用してBeanのすべてのメソッドを実行するように指定する方法を示します。
<enterprise-beans> <entity> ... <security-identity> <use-caller-identity/> </security-identity> ... </entity> </enterprise-beans>
論理ロールまたは実際のユーザーとグループは、EJBデプロイメント・ディスクリプタで使用できます。ただし、論理ロールを使用する場合は、OracleAS JAAS ProviderまたはXMLユーザー・マネージャのいずれかで定義した実際のユーザーとグループに、論理ロールをマッピングする必要があります。
アプリケーションのデプロイメント・ディスクリプタで定義した論理ロールをOracleAS JAAS ProviderまたはXMLユーザー・マネージャのユーザーまたはグループにマッピングするには、OC4J固有のデプロイメント・ディスクリプタで、次のように<security-role-mapping>要素を使用します。
name属性では、マッピングされる論理ロールを定義します。
groupまたはuser要素では、論理ロールをグループまたはユーザー名にマッピングします。このグループまたはユーザーは、OracleAS JAAS ProviderまたはXMLユーザー・マネージャ構成で定義する必要があります。OracleAS JAAS ProviderおよびXMLユーザー・マネージャの説明は、『Oracle Containers for J2EEサービス・ガイド』を参照してください。
この例では、論理ロールPOMGRを、orion-ejb-jar.xmlファイル内のmanagersグループにマッピングします。このグループの一部としてログイン可能なユーザーは、すべてPOMGRロールを所有しているとみなされます。したがって、PurchaseOrderBeanのメソッドを実行可能です。
<security-role-mapping name="POMGR"> <group name="managers" /> </security-role-mapping>
このロールを特定のユーザーにマッピングするには、次のようにします。
<security-role-mapping name="POMGR"> <user name="guest" /> </security-role-mapping>
最後に、次のように、ロールを特定のグループ内の特定のユーザーにマッピングすることも可能です。
<security-role-mapping name="POMGR"> <group name="managers" /> <user name="guest" /> </security-role-mapping>
図22-3に示すように、EJBデプロイメント・ディスクリプタで定義されているPOMGRの論理ロール名は、OC4J固有のデプロイメント・ディスクリプタ内の<security-role-mapping>要素でmanagersにマッピングされています。
EJBデプロイメント・ディスクリプタ内の<role-name>は、OC4J固有のデプロイメント・ディスクリプタ内の<security-role-mapping>要素内のname属性と同じです。これによりマッピングが識別されます。
メソッドがロール・マッピングに関連付けられていない場合、そのメソッドは、orion-ejb-jar.xmlファイルの<default-method-access>要素を介してデフォルト・セキュリティ・ロールにマッピングされます。次に、保護されていないメソッドの自動マッピングを示します。
<default-method-access> <security-role-mapping name="<default-ejb-caller-role>" impliesAll="true" > </security-role-mapping> </default-method-access>
デフォルト・ロールは<default-ejb-caller-role>で、name属性で定義されます。この文字列は、デフォルト・ロールの名前に置換できます。
impliesAll属性は、メソッドに対するセキュリティ・ロールのチェックが実行されるかどうかを示します。orion-ejb-jar.xmlファイルで、impliesAll属性には次のデフォルトが割り当てられます。
<security-role-mapping>がorion-ejb-jar.xmlファイルで指定されており、impliesAllが設定されていない場合、この属性のデフォルトはfalseに設定されます。コンテナにより、各メソッドでこのデフォルト・ロールがチェックされます。
<security-role-mapping>がorion-ejb-jar.xmlファイルで指定されていない場合、OC4J EJBレイヤーにより、この属性のデフォルトはtrueに設定されます。各メソッドでは、セキュリティ・ロールのチェックは実行されません。
impliesAll属性がfalseの場合は、<user>要素および<group>要素を使用して、name属性で定義したデフォルト・ロールをOracleAS JAAS ProviderまたはXMLのユーザーまたはグループにマッピングする必要があります。次の例では、メソッド許可に関連付けられていないすべてのメソッドをothersグループにマッピングする方法を示します。
<default-method-access> <security-role-mapping name="default-role" impliesAll="false" > <group name="others" /> </security-role-mapping> </default-method-access>
クライアントは、ユーザーとグループにより保護されたメソッドにアクセスするために、OracleAS JAAS ProviderまたはXMLユーザー・マネージャが認識できる正確なユーザー名またはグループ名とパスワードを提供する必要があります。また、ユーザーまたはグループは、対象となるメソッドのセキュリティ・ロールで指定されている内容と同じであることが必要です。詳細は、「EJBクライアントの資格証明の指定」を参照してください。
クライアントのタイプに応じて、クライアントがEnterprise Bean、またはJNDIでアクセス可能なその他のリソースにアクセスする前に、セキュリティ資格証明を指定することが必要な場合があります。
表22-1に、起動するターゲットのEnterprise Beanを基準としたデプロイの場所によりEJBクライアントを分類します。そのターゲットEnterprise Beanを基準としたクライアントのデプロイ場所により、セキュリティ資格証明を指定する必要があるかどうかが決定されます。
| クライアント・タイプ | ターゲットEJBとの関連 | 資格証明の設定 |
|---|---|---|
|
任意のクライアント |
クライアントとターゲットEnterprise Beanが同一JVM上に置かれます。 |
× |
|
任意のクライアント |
クライアントとターゲットEnterprise Beanは同じアプリケーションにデプロイされます。 |
× |
|
任意のクライアント |
クライアントの親として指定されるアプリケーションにデプロイされるターゲットEnterprise Bean。1 |
× |
|
任意のクライアント |
クライアントとターゲットEnterprise Beanは同一JVM上に置かれず、同じアプリケーションにデプロイされません。ターゲットEJBアプリケーションはクライアントの親ではありません。1 |
○ |
|
1
アプリケーションの親の設定方法は、『Oracle Containers for J2EE開発者ガイド』を参照してください。 |
リモート・コンテナのEnterprise Beanにアクセスする場合（つまり、クライアントおよびターゲットEnterprise Beanが同一JVM上に置かれておらず、同じアプリケーションにデプロイされず、ターゲットEnterprise Beanアプリケーションがクライアントの親でない場合）は、リモート・コンテナに有効な資格証明を渡す必要があります。クライアントが資格証明を渡す方法は、クライアントのタイプによって決まります。
InitialContext内で渡します（「初期コンテキストでの資格証明の指定」を参照）。
jndi.propertiesファイルで資格証明を定義します（「JNDIプロパティの資格証明の指定」を参照）。
InitialContext内で渡します（「初期コンテキストでの資格証明の指定」を参照）。
また、すべてのクライアントはejb_sec.propertiesファイルでセキュリティ・プロパティを指定できます（「ejb_sec.propertiesファイルでのEJBクライアント・セキュリティ・プロパティの指定」を参照）。
詳細は、次を参照してください。
jndi.propertiesファイルで資格証明を指定するには、次のようにします。
jndi.propertiesファイルを作成または変更します。
jndi.propertiesファイルに適切な資格証明を構成します。プロパティ名については、javax.naming.Contextのフィールド定義を参照してください。
java.naming.security.principal=POMGR java.naming.security.credentials=welcome java.naming.factory.initial= oracle.j2ee.server.ApplicationClientInitialContextFactory java.naming.provider.url=opmn:ormi://opmnhost:6004:oc4j_inst1/ejbsamples
jndi.propertiesファイルがクライアントのクラスパスにあることを確認します。
Context ic = new InitialContext(); CustomerHome = (CustomerHome)ic.lookup("java:comp/env/purchaseOrderBean");
実行時に、JNDIはClassLoaderのメソッドgetResourcesを使用して、クラスパス内のjndi.propertiesという名前のすべてのアプリケーション・リソース・ファイルを特定します。このときに、例22-6で設定したJNDIプロパティを使用して、purchaseOrderBeanにアクセスします。
詳細は、「JNDIプロパティ・ファイルでのJNDIプロパティの設定」を参照してください。
JNDIでアクセス可能なリソースをルックアップするために使用する資格証明を初期コンテキストで指定するには、次のようにします。
HashTableを作成し、javax.naming.Contextフィールドをキーとし、Stringオブジェクトを値として使用して必要なプロパティを移入します。Hashtable env = new Hashtable(); env.put(Context.SECURITY_PRINCIPAL, "POMGR"); env.put(Context.SECURITY_CREDENTIALS, "welcome"); env.put("java.naming.factory.initial", "oracle.j2ee.server.ApplicationClientInitialContextFactory"); env.put("java.naming.provider.url", "opmn:ormi://opmnhost:6004:oc4j_inst1/ejbsamples");
HashTableを初期コンテキスト・コンストラクタに渡します。Context ic = new InitialContext (env); CustomerHome = (CustomerHome) ic.lookup ("java:comp/env/purchaseOrderBean");
詳細は、次を参照してください。
サーバーの内部で実行しているかどうかにかかわらず、すべてのクライアントには、ejb_sec.propertiesファイルで制御されるEJBセキュリティ・プロパティがあります。このファイルを使用して、一般的なセキュリティ・オプションおよびCommon Secure Interoperability Version 2プロトコル（CSIv2）に固有のオプションを指定します。
詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』のCommon Secure Interoperabilityプロトコルに関する項を参照してください。
EJB 3.0アプリケーションでは、JSR250で定義されているjavax.annotation.securityアノテーションを使用して、EJB 3.0セッションBeanのセキュリティ・オプションを構成できます。
表22-2に、OC4Jでサポートされるセキュリティ・アノテーションをまとめます。これらのアノテーションの使用例は、「アノテーションの使用方法」を参照してください。
| アノテーション | 説明 | 適用対象 |
|---|---|---|
|
|
Java EEコンテナでの実行中にアプリケーションのロールを定義します。ロールは、コンテナのセキュリティ・レルムのユーザー/グループ情報にマッピングする必要があります。詳細は、 |
クラス |
|
|
アプリケーションでのメソッドへのアクセスを許可されるセキュリティ・ロールを指定します。詳細は、「EJBメソッドに対するロールの指定」を参照してください。 |
メソッド指定によりクラス指定がオーバーライドされます（存在する場合）。 |
|
|
すべてのセキュリティ・ロールが指定のメソッドの起動を許可されるように指定します。詳細は、「EJBメソッドに対するセキュリティ・チェックなしの指定」を参照してください。 |
メソッド指定はそのメソッドにのみ適用されます。 |
|
|
指定のメソッドの起動を許可されるセキュリティ・ロールがないことを指定します。 |
メソッド指定はそのメソッドにのみ適用されます。 |
|
|
アプリケーションで使用されるセキュリティ・ロールを指定します。 |
クラス |
@PermitAll、@DenyAllおよび@RolesAllowedを使用している場合は、次の制限に注意してください。
@PermitAll、@DenyAllおよび@RolesAllowedアノテーションは、同じメソッドまたはクラスに適用できません。
例22-9に、@RolesAllowedアノテーションの使用方法を示します。詳細および例は、JSR250の仕様を参照してください。
@RolesAllowed("Users")
public class Calculator {
@RolesAllowed("Administrator")
public void setNewRate(int rate) {
...
}
}
OC4Jでは、標準のJAAS APIを使用した、セッションBean（ステートレスおよびステートフル）およびエンティティBeanのビジネス・メソッドおよびライフ・サイクル・メソッドからのSubject、Principalおよび資格証明の取得をサポートしています。
例22-10に、JAAS APIを使用して、OC4JにデプロイされるEnterprise Beanのビジネス・メソッドで資格証明を取得する方法を示します。
public class Calculator {
// Buisness method
public void setNewRate(int rate) {
...
AccessControlContext actx = AccessController.getContext();
Subject subject = Subject.getSubject(actx);
Set principals = subject.getPrincipals();
...
}
}
JAAS Pluggable Authenticationフレームワーク内では、アプリケーション・サーバーおよび基礎となる認証サービスが相互に独立しています。アプリケーション・サービスは、アプリケーション・サーバーまたはアプリケーション・コードの変更を必要とせずに、JAASログイン・モジュールを通じてプラグインできます。ログイン・モジュールは、提供される資格証明（パスワードなど）の認証を行い、適切なプリンシパル（ロールなど）をサブジェクトに追加します。JAASログイン・モジュールの可能なタイプには、プリンシパル・マッピングJAASmモジュール、資格証明マッピングJAASモジュール、Kerberos JAASモジュールまたはカスタム・ログイン・モジュールがあります。
カスタムJAASログイン・モジュールをEnterprise Beanで使用するには、次の要素を構成する必要があります。
system-jazn-data.xmlの<jazn-loginconfig>
orion-application.xmlの<jazn>
orion-application.xmlの<namespace-access>
詳細は、『Oracle Containers for J2EEセキュリティ・ガイド』の「ログイン・モジュール」を参照してください。
|
 Copyright © 2002, 2008 Oracle Corporation. All Rights Reserved. |
|