10g（10.1.3.4.0）
B50832-01
 目次 |
 索引 |
| Oracle Containers for J2EE
セキュリティ・ガイド
10g（10.1.3.4.0） B50832-01 |
|
この章では、OC4Jで使用可能な各種セキュリティ・プロバイダ全体に該当する一般的なタスクと関連するガイドラインについて説明します。
OC4Jコンポーネントの多くは、認証にパスワードを必要とします。これらのパスワードをデプロイメント・ファイルと構成ファイルに埋め込む方法は、特にファイルのパーミッションによりどのユーザーでも読取り可能な場合には、セキュリティ上のリスクを伴います。この問題を回避するために、OC4Jには次の2つの解決策が用意されています。
system-jazn-data.xml）で検索するために必要な情報で置換します。
この項の以降の部分で、次の項目について説明します。
次に示す構成ファイルと各構成ファイル内の1つ以上の要素で、パスワードの間接化がサポートされています。
data-sources.xml: <native-data-source>および<managed-data-source>要素のpassword属性
ra.xml: <res-password>要素
rmi.xml: <ssl-config>要素のkeystore-password属性
jms.xml: <password>要素
*-web-site.xml: <ssl-config>要素のkeystore-password属性
これらのパスワードのいずれかを間接化するには、リテラルのパスワード文字列を、「->」に続けてユーザー名、またはスラッシュ（/）で区切ったレルムとユーザー名を含む文字列で置換します。
次に、間接パスワードと直接パスワードの例をいくつか示します。
<data-source password="->Scott">デフォルト・レルムでScottを検索し、パスワード・マネージャに格納されているパスワードを使用します。
<res-password="->customers/Scott">customersレルムでScottを検索し、そこに格納されているパスワードを使用します。
<cluster password="mypass">リテラル文字列mypassがパスワードですが、間接パスワードではありません。
OC4J固有のsystem-application.xmlファイル（OC4J systemアプリケーションと関連）の<password-manager>要素では、間接パスワードの検索に使用するセキュリティ・プロバイダを指定します（前項の「パスワードの間接化の使用方法」を参照してください）。この要素を省略すると、間接パスワードの認証と認可にはグローバル・アプリケーションのセキュリティ・プロバイダが使用されます。system-application.xmlの<password-manager>要素内にある<jazn>要素は、このファイルの最上位にある<jazn>要素と異なっていてもかまいません。
セキュリティ上の理由で、Oracle Internet Directoryに格納されている資格証明は、通常、復号化された（クリアテキスト）形式で取得できません。つまり、Oracle Internet Directoryはアプリケーションのパスワード・マネージャとして使用できません。これを解決するために、アプリケーションでOracle Identity Managementがセキュリティ・プロバイダとして使用される場合でも、ファイルベースのプロバイダをアプリケーションのパスワード・マネージャとして指定できます。
それには、次のようなエントリをOC4J固有のsystem-application.xmlファイルに追加します。
<password-manager> <jazn provider="XML" location=ORACLE_HOME/j2ee/instance_name/config/system-jazn-data.xml /> </password-manager>
JAAS構成ファイルjazn.xmlおよびsystem-jazn-data.xml（またはオプションでアプリケーション固有のjazn-data.xmlファイル）には、JAAS認可用のユーザー名とパスワードが含まれています。これらのファイルを保護するために、OC4Jではパスワードの不明瞭化が使用されます。
通常、jazn.xmlまたはsystem-jazn-data.xmlを更新するたびに、OC4Jによりファイルが読み取られ、すべてのパスワードの不明瞭化（暗号化）バージョンで書き換えられます。
また（Oracle Identity Managementに関連して）、orion-application.xmlなどの<jazn>要素内のldap.passwordプロパティは不明瞭化されます。次に例を示します。
<jazn ... > <property name="ldap.password" value="welcome123"/> ... </jazn>
他のOC4J構成では、「パスワードの間接化の使用方法」で説明するように、パスワードの間接化を使用してパスワードのクリアテキストの公開を回避できます。
OC4Jでは、ファイルベースのプロバイダとLDAPベースのOracle Identity Managementの両方でセキュリティ・レルムの概念が使用されます（「OracleAS JAAS Providerのセキュリティ・レルム」を参照してください）。レルムは単一でも複数でも構成できますが、デフォルトのレルムはOC4J構成を介して指定します。Active DirectoryやSun Java System Directory Serverなどの外部LDAPプロバイダを使用する場合は、レルムの概念はサポートされていませんので、注意してください。
この項では、OC4Jの認証と認可を制御するセキュリティ・レルムを使用する場合の重要な事項について説明します。この項の内容は次のとおりです。
デフォルト・レルムは、<jazn>要素のdefault-realm属性で指定します。ファイルベースのプロバイダの場合、これはorion-application.xmlファイルのアプリケーション・レベルか、インスタンス・レベルのjazn.xmlファイルのOC4Jレベルにあります。Oracle Identity Managementの場合、これはOC4J homeインスタンスのjazn.xmlファイルにあります。
ファイルベースのプロバイダの場合、jazn.comは、インスタンス・レベルのデフォルト・レルムとしてデフォルトで構成されています。
<jazn provider="XML" location="./system-jazn-data.xml" default-realm="jazn.com" />
Oracle Identity Managementの場合、デフォルト・レルムはOracle Internet Directoryに基づいており、Oracle Internet Directoryのインストール時に決定されます。OC4JをOracle Internet Directoryインスタンスに関連付けると、デフォルト・レルムの反映先は、次の例のようにOC4Jインスタンス・レベルになります。
<jazn provider="LDAP" location="ldap://www.example.com:636" default-realm="us"/>
デフォルト・レルムの使用上のガイドラインについては、「デフォルト・レルムの使用方法」を参照してください。
前述の項で説明したように、デフォルト・レルムは必ず構成してください。ただし、この項では、ファイルベース・プロバイダまたはOracle Identity Managementの使用時にデフォルト・レルムを指定しなかった場合に、その特定のために行われる後続の処理を、参考目的でのみ説明します。
アプリケーションでファイルベース・プロバイダを使用する場合:
orion-appliation.xmlファイルで検索されます。そこでデフォルト・レルムが見つかると、アプリケーションのデフォルト・レルムとして使用されます。
jazn.xmlファイルでOC4Jインスタンス・レベルのデフォルト・レルム構成が検索されます。
アプリケーションでOracle Identity Managementを使用する場合:
jazn.xmlの）構成でLDAPベースのプロバイダがアプリケーションとOC4Jインスタンス・レベルで指定されている場合は、OracleAS JAAS Providerでは、jazn.xmlでデフォルト・レルム構成が検索されます。そこでデフォルト・レルムが見つかると、アプリケーションのデフォルト・レルムとして使用されます。
認証の場合は、デフォルト・レルムを使用するとき、ユーザー名の前にレルム名を接頭辞として付ける必要はありません。たとえば、ユーザーscottがデフォルト・レルムjazn.comにある場合、認証用には、ユーザー名をscottとのみ指定します。
これは該当するOC4Jコンポーネントや、JNDI、JMS、J2EE Connector Architectureなどのサービスにも当てはまります。
同様に、パスワードの間接化を行う場合にも、OC4Jデプロイメント・ディスクリプタでは、間接化対象として指定するユーザー名の前にレルム名を付ける必要はありません。つまり、->scottと指定します。
この説明でのacme.comのような非デフォルト・レルム（つまりカスタム・レルム）を使用している場合は、ユーザー名に接頭辞としてレルム名を付ける必要があります。たとえば、acme.comのユーザーscottを認証するには、ただscottとするのではなく、acme.com/scottと指定する必要があります。
これは該当するOC4Jコンポーネントや、JNDI、JMS、J2EE Connector Architectureなどのサービスにも当てはまります。
同様に、パスワードの間接化を行う場合にも、OC4Jデプロイメント・ディスクリプタでは、ユーザーが非デフォルト・レルムに定義されているときは、間接化のために指定するユーザー名にレルム名を接頭辞として付ける必要があります。すなわち、->acme.com/scottのように指定します。
また、カスタム・レルムを使用する場合に、そのカスタム・レルムでユーザーまたはロールにJAASポリシーが付与されているときは、次の作業を実行する必要があります。
orion-application.xmlファイルの<jazn>要素で、default-realm設定としてcustom_realm_nameを指定します。
<jazn>要素のlocation属性の設定は指定しないでください。
jazn.xmlで、<jazn>要素の<property>サブ要素を使用して、jaas.username.simpleプロパティをfalseに設定します（「認証済プリンシパル取得時のレルム名の省略」を参照してください）。
これらの手順によって、カスタム・レルムとそのユーザー、ロールおよびポリシーを永続化できます。
JAAS認可を使用する場合、特にカスタム・レルムでユーザーまたはロールにパーミッションを付与する場合は、カスタム・レルムとそのユーザーおよびグループを、アプリケーション固有のjazn-data.xmlファイルではなく、system-jazn-data.xmlで定義し、永続化する必要があります。
複数レルムを構成するときは、使用する非デフォルト・レルムに対してユーザー名にレルム名を接頭辞として付ける必要があります。この説明では、レルムjazn.com、acme.comおよびexample.orgが構成済で、jazn.comがデフォルト・レルムであるとします。さらに、ユーザーscottがjazn.com内に、ユーザーralphがexample.org内に定義されているものとします。
scottを認証対象として指定するには、このユーザーをscottとしてのみ指定します。このユーザーがデフォルト・レルムjazn.com内に定義されているためです。
ralphを認証対象として指定するには、example.org/ralphと指定する必要があります。
これは該当するOC4Jコンポーネントや、JNDI、JMS、J2EE Connector Architectureなどのサービスにも当てはまります。レルム名は、非デフォルト・レルムのユーザーに対して指定します。
同様に、パスワードの間接化を行う場合にも、OC4Jデプロイメント・ディスクリプタでは、ユーザーが非デフォルト・レルムに定義されているときは、間接化のために指定するユーザー名にレルム名を接頭辞として付ける必要があります。すなわち、->example.org/ralphのように指定します。ただし、デフォルト・レルムにあるユーザーには、レルム名を指定する必要がありません。すなわち、scottのようにします。
カスタム・レルムを構成する場合を除いて、通常は認証プリンシパルではレルム名を省略するようにしてください。認証プリンシパルは、サーブレット、EJBおよびWebサービスの主要なメソッドによって戻されます。OC4Jでは、この動作の制御にjaas.username.simpleプロパティを使用します。このプロパティにより、次のメソッドが影響を受けます。
HTTPServletRequestインスタンスのgetUserPrincipal()メソッド（サーブレット）
HTTPServletRequestインスタンスのgetRemoteUser()メソッド（サーブレット）
EJBContextインスタンスのgetCallerPrincipal()メソッド（EJB）
ServletEndpointContextインスタンスのgetUserPrincipal()メソッド（Webサービス）
プロパティ設定にtrue（デフォルト）を指定すると、これらのメソッドから戻されるプリンシパル名にレルム名が含まれなくなります。たとえば、scottのようになります。
プロパティをfalseに設定すると、これらのメソッドから戻されるプリンシパル名に、接頭辞としてレルム名が付けられます。たとえばjazn.com/scottのようになります。
false設定を指定するには、次のように<jazn>要素の<property>サブ要素（アプリケーション・レベルの場合はorion-application.xml内、OC4Jインスタンス・レベルの場合はインスタンス・レベルのjazn.xmlファイル内）を使用します。
<jazn ... > ... <property name="jaas.username.simple" value="false" /> ... </jazn>
この項では、アプリケーションのデプロイ時に考慮する必要があるセキュリティ上の事項について説明します。この項の内容は次のとおりです。
セキュリティ・プロバイダは、J2EEの宣言によるセキュリティ・モデルで動作するように設計されています。この宣言によるモデルでは、アプリケーションでJAASセキュリティを使用するためのプログラミングは不要であるか、必要であるとしてもごくわずかです。かわりに、セキュリティ上のほとんどの決定はデプロイ処理中に行われ、再びコーディングしなくても容易に変更できます。宣言によるモデルでは不十分な場合、セキュリティ・プロバイダではすべてのJ2SE環境でJAASが使用されるのと同じ方法でプログラムによるセキュリティもサポートされます。
宣言によるセキュリティ・モデルを使用する場合、デプロイヤはセキュリティに関連して次の事項を決定する必要があります。
hr_managerであると想定される場合、デプロイヤはそのロールを定義する必要があります。
hr_managerを、OracleAS JAAS Providerにより定義された指定のユーザー・セットにマップできます。
この項では、Application Server Controlコンソールの機能に沿って、アプリケーションのデプロイ方法について説明します。
デプロイ・プランの詳細やApplication Server Controlコンソールの使用方法などを含めた、OC4Jへのアプリケーションのデプロイに関する一般情報は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。ここでは、次の基本手順を確認しておきます。
セキュリティ上で特に重要なのは、セキュリティ・プロバイダの選択とセキュリティ・ロールのマップです。また、共有ライブラリに対するクラスのロードの構成が必要なことがあります。たとえば、共有ライブラリとしてロードするログイン・モジュールがある場合などです。
この項では、Application Server Controlコンソールを使用してセキュリティ・プロバイダを指定する方法について説明します。また、ファイルベース・プロバイダとLDAPベース・プロバイダの使用方法の差異に関する注意事項についても説明します。
一般に、ファイルベースのプロバイダは、開発中およびユーザー数の少ないデプロイ済アプリケーション（スタンドアロンOC4J環境など）で使用します。Oracle Identity Managementは、大規模な本番環境で使用します。
ファイルベースのプロバイダはより軽量な実装であり、一方のOracle Identity Managementはセキュリティとパフォーマンスの面で優れています。集中型Oracle Internet Directoryサーバーは、アプリケーションとユーザーの数の増大に適切に対応でき、キャッシュ・パラメータを構成して、認証と認可の全体的なパフォーマンスを向上させることができます。また、複数のOC4Jインスタンスからのユーザー・リポジトリへのアクセスが簡素化されます。ファイルベースのプロバイダでは、それらの各インスタンスが独自にリポジトリを保有している場合に、ユーザー・データの更新をインスタンス間で整合させる必要があります。
さらに、Oracle Internet Directoryでは、アカウントの集中的な作成と管理、シングル・パスワード、資格証明管理などの機能を提供します。
Application Server Controlコンソールでは、次のように、デプロイ時に「デプロイ: デプロイ設定」ページからセキュリティ・プロバイダを指定します（このページへのナビゲート方法については、「Application Server Controlを介したアプリケーションのデプロイ」を参照してください）。
Oracle Access Managerセキュリティ・プロバイダは、Application Server Controlではサポートされません（ただし、そのログイン・モジュールは他のログイン・モジュールと同様にApplication Server Controlを介して構成できます）。Oracle Access Managerの構成方法の詳細は、
注意
第11章「Oracle Access Manager」を参照してください。
この項では、次の項目について様々な側面から説明します。
次のような構成で説明します。
セキュリティ・ロールの定義および参照の手順は次のとおりです。
web.xmlまたはejb-jar.xml）で、<security-role>要素を使用して次の例のようなJ2EE論理ロールを定義します。
<security-role> <role-name>sr_developers</role-name> </security-role>
<security-role-ref>要素を使用して、アプリケーションで作成したロールを標準ディスクリプタで定義したJ2EEロールにリンクします（この例のar_developersはアプリケーション・ロールです）。
<security-role-ref> <role-name>ar_developers</role-name> <role-link>sr_developers</role-link> </security-role-ref>
これらの手順を実行すると、セキュリティ・プロバイダで定義された（たとえばファイルベースのプロバイダの場合はjazn-data.xmlファイルやsystem-jazn-data.xmlファイル、LDAPベースのプロバイダの場合はOracle Internet Directoryで定義）デプロイ・ロールへのマッピングは、OC4J固有のディスクリプタであるorion-web.xml、orion-ejb-jar.xmlまたはorion-application.xmlで定義されます。これらのファイルは、Application Server Controlを介したアプリケーションのデプロイ時に、必要に応じて定義したマッピングによって更新され、その更新内容は<security-role-mapping>要素に反映されます。これらのマッピングについては、後続の2つの項「Application Server Controlを介したセキュリティ・ロール・マッピングの指定」および「OC4J構成ファイルにおけるJ2EEロールのデプロイ・ロールへのマッピング」を参照してください。
Application Server Controlコンソールでは、次のように、デプロイ処理中に「デプロイ: デプロイ設定」ページからJ2EEロールをデプロイ・ロールにマップします（このページへのナビゲート方法については、「Application Server Controlを介したアプリケーションのデプロイ」を参照してください）。
これらのアクションにより、orion-application.xml、orion-web.xml、orion-ejb-jar.xmlなどの該当するOC4J構成ファイルに<security-role-mapping>要素が作成されます（次の「OC4J構成ファイルにおけるJ2EEロールのデプロイ・ロールへのマッピング」を参照）。
|
注意 デプロイ後にApplication Server Controlを介してセキュリティ・マッピングを変更することはできません。これを行うには、手動で構成を更新し（「OC4JによるJ2EEロールのデプロイ・ロールへのマッピング」および「J2EEロールからデプロイ・ユーザーおよびデプロイ・ロールへのマッピング」を参照）、アプリケーションを再起動または再デプロイします。 |
標準デプロイメント・ディスクリプタに定義された移植可能なJ2EE論理ロールは、orion-application.xmlファイル（J2EEアプリケーション全体に適用の場合）、orion-web.xmlファイル（特定のWebアプリケーションに適用の場合）、orion-ejb-jar.xmlファイル（特定のEJBアプリケーションに適用の場合）のいずれかの<security-role-mapping>設定を介して、デプロイ・ロールにマップされます。
この例では、J2EEロールsr_developersをデプロイ・ロールdevelopersにマップしています。<security-role-mapping>要素下の<group>サブ要素は、system-jazn-data.xmlやOracle Internet Directoryで定義されているデプロイ・ロールなどに対応していることに注意してください。<user>サブ要素を個々のユーザーにマップすることもできます。
<security-role-mapping name="sr_developers"> <group name="developers" /> </security-role-mapping>
この関連付けにより、developerロールは、標準デプロイメント・ディスクリプタで構成されたセキュリティ制約に従って、sr_developersロールがアクセスできるリソースにアクセスできるようになります。
たとえば、developerデプロイ・ロールのメンバーであるユーザーjohnについて考えてみます。このロールはJ2EEロールsr_developersにマップされているため、johnは、sr_developersロールからアクセス可能なアプリケーション・リソースにアクセスできます。
認可は不要で認証についてのみ考慮が必要な状況のために、OC4Jでは、認証済ユーザーが所定のアプリケーションまたはリソースにアクセスできるモードがサポートされています。このモードはPUBLICロールに対してサポートされ、必要に応じてURL単位またはメソッド単位で構成できます。手順は次のとおりです。
web.xml（Webアプリケーションの場合）またはejb-jar.xml（EJBの場合）にそのようなロールを定義できます。 たとえば、web.xmlでは次のようにします。
<web-app> ... <security-role> <role-name>public_role</role-name> </security-role> ... <auth-constraint> <role-name>public_role</role-name> </auth-constraint> ... </web-app>
また、ejb-jar.xmlでは次のようにします。
<assembly-descriptor> ... <security-role> <role-name>public_role</role-name> </security-role> ... <method-permission> <role-name>public_role</role-name> <method>method</method> </method-permission> ... </assembly-descriptor>
orion-application.xml（Webアプリケーションの場合）またはorion-ejb-jar.xml（EJBの場合）のPUBLICロールに、使用しているPUBLICロールをマップします。上のweb.xmlで定義したロールをマップするには、orion-application.xmlに次を挿入します。
<orion-application> ... <security-role-mapping name="public_role"> <group name="{{PUBLIC}}"/> </security-role-mapping> ... </orion-application>
また、EJBの場合は、かわりにorion-ejb-jar.xmlの<security-role-mapping>要素を使用します（この要素は、<assembly-descriptor>要素のサブ要素です）。
この項では、アプリケーションをデプロイした後の次の注意事項について説明します。
アプリケーションのデプロイ後に、Application Server Controlコンソールにあるアプリケーションの「セキュリティ・プロバイダ」ページに移動して、アプリケーション・レベルのセキュリティ設定を確認または更新できます。OC4JインスタンスのOC4Jホームページから次の手順を実行します。
これにより、「セキュリティ・プロバイダ」ページが表示され、アプリケーションのプロバイダに関する情報が表示されて、設定の更新や、別のセキュリティ・プロバイダへの変更ができます。
OracleAS JAAS Providerは、OC4Jのクラス・ロード・アーキテクチャと統合されています。ライブラリをOC4J共有ライブラリとしてロードすることで、それらのライブラリがアプリケーションで利用可能になります。たとえば、複数のアプリケーション間で次を共有する場合などは、この機能が役立ちます。
ライブラリの共有と使用は、主に次の2つの手順からなります（具体的にApplication Server Controlコンソールの機能を考えた場合）。
Application Server ControlからライブラリをOC4J共有ライブラリとしてロードするには、「共有ライブラリ」タスクを使用します。
ライブラリをロードすると、OC4J server.xmlファイルに次のような構成が生成されます。
<application-server ... > ... <shared-library name="mylib.lib" version="1.0" library-compatible="true"> <code-source path="../mypath" /> </shared-library> ... </application-server>
アプリケーションのデプロイ中に、Application Server Controlを介してアプリケーションにライブラリをインポートできます。
ライブラリをインポートすると、アプリケーションのorion-application.xmlファイルに次のような構成が生成されます。
<orion-application ... > ... <imported-shared-libraries> <import-shared-library name="mylib.lib" /> ... </imported-shared-libraries> ... </orion-application>
|
 Copyright © 2003, 2008 Oracle Corporation. All Rights Reserved. |
|