| Oracle® Fusion Middleware Oracle JDeveloperによるアプリケーションの開発 12c (12.1.2) E48018-02 |
|
 前 |
 次 |
この章では、Oracle JDeveloperでセキュアなJava EEアプリケーションを開発、デプロイおよび管理する方法について説明します。
この章には次の項が含まれます:
Fusion Middleware Suiteでは、セキュアなアプリケーションを開発、デプロイおよび管理できます。Java EEアプリケーションは、コンテナ管理セキュリティのみを使用して保護できます。Fusion Webアプリケーションの場合は、Oracle ADF Securityを使用できます。Fusion Webアプリケーションは、Oracle Application Development Framework (Oracle ADF)を使用して開発するJava EEアプリケーションです。
Java EEアプリケーションは、OPSSを使用するよう拡張できます。このシナリオでは、JDeveloperの宣言エディタを使用してユーザーおよびロールを構成します。アプリケーション・リソースは、Java EEコンテナ管理のセキュリティを使用して保護します。
このシナリオは、ADFセキュリティを追加してOracle ADFリソースに対するきめ細かなセキュリティ・ポリシーを有効にする、完全な宣言実装です。JDeveloperの宣言エディタを使用してファイルベースのアイデンティティ・ストア、ポリシー・ストアおよび資格証明ストアを構成します。アプリケーションでOracle ADFが使用されるため、ウィザードを実行してADFタスク・フローやADFページ定義などのADFリソースに関連付けられているWebページのセキュリティを構成し、jazn-data.xmlポリシー・エディタを使用してセキュリティ・ポリシーも定義します。
Java EEセキュリティ・モデルは、コンテナ管理のセキュリティに基づくロールベースの宣言型モデルであり、ユーザーに割り当てられたロールによりリソースが保護されます。このモデルを使用すると、アプリケーション・デプロイメント・ディスクリプタのアプリケーション・ロジックとは別個にセキュリティを指定できるため、基礎となるセキュリティ・インフラストラクチャからアプリケーションを切り離すことができます。アプリケーションが実行されるコンテナは、デプロイメント・ディスクリプタの仕様に応じてアプリケーションのセキュリティを提供します。このモデルでは、デプロイメント・ディスクリプタ内で参照できるアプリケーション・コードにセキュリティ・データ(注釈)を埋め込むこともできます。
コンテナ管理セキュリティの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
Oracle ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。主な理由は、Oracle ADF Securityが、Oracle Platform Security Services (OPSS)アーキテクチャの上部で構築され、このアーキテクチャにより重要なセキュリティ・フレームワークが実現され、Oracle WebLogic Serverと緊密に統合されていることです。
Oracle ADF Securityの詳細は、Oracle Fusion Middleware ADF開発者ガイドのFusion WebアプリケーションでのADFセキュリティの有効化に関する項を参照してください。
OPSSの詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
JDeveloperでセキュアなアプリケーションを開発する場合、一般に、開発とデプロイメント(本番環境への)をそれぞれ異なるニーズを持つ別個のフェーズと考えることが有用です。これは、開発時およびテスト時、JDeveloperはOracle Platform Security Services (OPSS)との統合を通じて、管理が容易なファイルベースのセキュリティをサポートしているためです。
JDeveloperは、セキュリティに関するアプリケーション開発ライフサイクルを簡易化し、データのフラット・ファイルへの格納を可能にすることで開発を容易にします。jazn-data.xmlファイルは、OPSSと統合するための、JDeveloperのデフォルトのファイルベース・セキュリティ・プロバイダです。jazn-data.xmlファイルには、Oracle Application Development Framework (Oracle ADF)およびOracle ADF Securityを使用して構築されたFusion Webアプリケーションに定義するユーザー、グループ、ロールおよびポリシーが格納されます。JDeveloperには、セキュリティ・データ・ストアの作成を容易にするこのファイル専用のエディタが用意されています。
OPSSの機能は、本番環境のエンタープライズ・ロールで定義されたユーザーをアプリケーションの機能に固有のアプリケーション・ロールに抽出することです。開発時、アプリケーション開発者はアプリケーション・ロールおよびアプリケーション・ロールを使用するセキュリティ・ポリシーをjazn-data.xmlファイルのポリシー・ストアに追加します。その後、テストを簡易化するために、開発者は少数のユーザーをアイデンティティ・ストアに追加し、これらのテスト・ユーザーをアプリケーション・ロールに割り当てることができます。このため、アプリケーションをテストするために、jazn-data.xmlをアイデンティティ・ストアとしても使用できます。
開発時、アプリケーションは本番環境で定義されているエンタープライズ・ロールを認識する必要はありません。開発後、管理者はOracle Enterprise Manager Fusion Middleware Controlを使用して本番レベルのエンタープライズ・ロールをアプリケーションのポリシー・ストアのアプリケーション・ロールにマップします。このマッピングにより、任意のエンタープライズ・ロールのメンバーであるユーザーは、関連するアプリケーション・ロールからアクセス可能なリソースにアクセスできます。
アプリケーションを完了した後、ポリシー・ストアをOracle WebLogic Server上の本番環境プロバイダに移行します。この時点で、テスト・ユーザー・アイデンティティ・ストアを、Oracle WebLogic Server組込みLDAPサーバーで構成済のエンタープライズ・ユーザーに置き換えます。LDAPサーバーは、jazn-data.xmlファイルとは異なり、本番環境で使用可能な分散アプリケーション・サーバー構成をサポートしています。LDAPサーバーの詳細は、Oracle WebLogic Serverのセキュリティの管理を参照してください。
このため、JDeveloperでファイルベース・プロバイダおよびOPSSを使用すると、次のようにして本番環境での要求を分離できます。
テスト・ユーザーおよびアプリケーション・ロールを宣言によって定義する
Oracle ADFリソースのセキュリティ・ポリシーを宣言によって定義する
デプロイ時にアプリケーション・レベルのセキュリティ・プロバイダからsystem-jazn-data.xmlセキュリティ・プロバイダに容易に移行する
デプロイまでエンタープライズ・ロールのマッピングを見送る
Oracle WebLogic Serverでは、Java EE宣言セキュリティはOracle Platform Security Services (OPSS) (OracleのJAAS標準の実装)とともに実装されます。OPSSは、Java EEセキュリティを拡張することにより、アプリケーション開発者、システム・インテグレータ、セキュリティ管理者および独立系ソフトウェア・ベンダーに、Java SEおよびJava EEアプリケーション用の移植可能で統合された包括的なセキュリティ・プラットフォーム・フレームワークを提供します。
OPSSおよびその機能の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
JDeveloperには、Webアプリケーション用のJava EEセキュリティの構成、およびセキュアなWebアプリケーションのアプリケーション・サーバー・インスタンスへのデプロイをサポートするツールが用意されています。開発者は、アプリケーション開発時にウィザードおよびエディタを介して、JDeveloperからOPSSサービスを構成できます。
JDeveloperには、Oracle Platform Security構成(jps-config.xml)、JAAS構成(jazn-data.xml)およびWebアプリケーション・デプロイメント・ディスクリプタ(web.xml)を作成および編集する固有のエディタがあります。JDeveloperでは、Webアプリケーションのアプリケーション・サーバーへの直接デプロイメントもサポートされています。詳細は、第21.2項「フェーズでのアプリケーションの保護」を参照してください。
Webアプリケーションを開発する場合、Oracle Application Development Framework (Oracle ADF)を使用してユーザー・インタフェース内のデータ対応のコンポーネントを操作することを選択できます。ユーザー・インタフェースにADFタスク・フローやADFページ定義などのADFリソースが含まれる場合、ADFセキュリティ・フレームワークを介してこれらのリソースに依存するWebページを保護するオプションも用意されています。JDeveloperツールはセキュリティの繰返し型開発をサポートしているため、ADFリソース用として作成するセキュリティ・ポリシーを簡単に作成、テストおよび編集できます。JDeveloperでテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行し、エンドユーザーがセキュアなリソースにアクセスする方法をシミュレートできます。詳細は次の項目を参照してください。第21.5.2項「Fusion WebアプリケーションのADFセキュリティを使用したADFリソースの保護方法」。
Webアプリケーション・セキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』を参照してください。
ユーザーが保護されたWebアプリケーション領域を要求すると、宣言セキュリティでの認証が強制されます。
ユーザーが保護されたWebアプリケーション領域を要求すると、宣言セキュリティでの認証が強制されます。ユーザーがこれまで認証されていない場合、コンテナはユーザーから資格証明を取得します。ユーザーはサーバー・セッション中、認証されたままです。
サポートされている認証タイプは、FORMベース認証、BASIC認証およびCLIENT-CERT認証です。認証タイプは、<login-config>要素を使用してweb.xmlデプロイメント・ディスクリプタで指定されます。
BASIC認証では、ユーザーがユーザー名とパスワードを入力できるようにブラウザのログイン・ダイアログが使用されます。このダイアログ・フォームはカスタマイズできないため、使用するブラウザに応じてルック・アンド・フィールが異なります。ユーザー資格証明は認証済レルムのブラウザ・セッションに格納されます。レルムは、認証されたユーザーの一連の権限が含まれるリポジトリです。Oracle Platform Security Servicesのデフォルトのレルムは、jazn.comです。
例21-1のコードSnippetは、BASIC認証をweb.xmlファイルに指定する方法を示しています。
FORMベース認証では、アプリケーション開発者はカスタム・ログイン・ダイアログを指定できます。usernameパラメータの名前はj_usernameで、パスワード・フィールドの名前はj_passwordである必要があります。要求を認証するJava EEコンテナのログイン・フォーム・アクションの値はj_security_checkである必要があります。
例21-2のコードSnippetは、FORM認証をweb.xmlファイルに指定する方法を示しています。
パスワード暗号化はWebLogic Serverドメインに固有であるため、weblogic-jdbc.xmlファイルに手動でパスワード処理を追加する必要があります。パスワードを暗号化するには、デプロイ先ドメインの暗号化ユーティリティ(weblogic.security.Encrypt)を使用します。
|
注意: パスワードはドメイン固有であるため、異なるドメインにデプロイするたびにターゲット・ドメインのパスワードを再暗号化する必要があります。 |
weblogic-jdbc.xmlに追加する必要があるXMLコードは、次のようなコードです。
<password-encrypted>toystore</password-encrypted>
タグ間にはクリアテキストのパスワードまたは暗号化されたパスワード文字列を入力できます。この要素は、<jdbc-driver-params>要素(概要エディタを使用して編集済の場合はweblogic-jdbc.xmlにすでに存在)の内部に配置されます。
weblogic.security.Encryptユーティリティは、WebLogic Serverで使用されるクリアテキスト文字列を暗号化します。このユーティリティは、現在のディレクトリの暗号化サービスまたは指定されたWebLogic Serverドメイン・ルート・ディレクトリの暗号化サービスを使用します。
|
注意: 暗号化文字列は、使用するWebLogic Serverドメインの暗号化サービスで暗号化する必要があります。そうでない場合、サーバーで文字列を復号化できません。 |
weblogic.security.Encryptユーティリティは、WebLogic Serverドメイン内の少なくとも1つのサーバー・インスタンスを持つマシンでのみ実行できます。クライアントからは実行できません。表21-1は、weblogic.security.Encryptユーティリティの引数を定義しています。
|
注意: ユーティリティは、管理サーバー・ドメイン・ディレクトリから、または管理サーバーをホストしてドメイン・ルート・ディレクトリを指定するマシンで実行することをお薦めします。 |
構文
java [ -Dweblogic.RootDirectory= dirname ] [ -Dweblogic.management.allowPasswordEcho=true ] weblogic.security.Encrypt [ password ]
表21-1 weblogic.security.Encryptユーティリティの引数
| 引数 | 定義 |
|---|---|
|
|
オプション。暗号化文字列を使用するWebLogic Serverドメイン・ディレクトリ。指定されていない場合、デフォルトのドメイン・ルート・ディレクトリが現在のディレクトリになります(ユーティリティが実行されているディレクトリ)。 |
|
|
オプション。コマンドラインに入力された文字のエコーを可能にします。weblogic.security.Encryptは非表示が有効であることを想定しています。非表示が有効でない場合は、このプロパティをtrueに設定します。 |
|
|
オプション。暗号化するクリアテキスト文字列。コマンドラインにない場合、パスワードの入力を求められます。 |
例
ユーティリティは、現在のディレクトリにあるドメインの暗号化サービスを使用して、暗号化文字列を返します。
java weblogic.security.Encrypt xxxxxx {3DES}Rd39isn4LLuF884Ns
ユーティリティは、指定されたドメインの場所の暗号化サービスを使用して、暗号化文字列を返します。
java -Dweblogic.RootDirectory=./mydomain weblogic.security.Encrypt xxxxxx {3DES}hsikci118SKFnnw
ユーティリティはパスワードをエコーせずに、現在のディレクトリで暗号化文字列を返します。
java weblogic.security.Encrypt Password: {3DES}12hsIIn56KKKs3
アイデンティティ・ストアは、ユーザー、エンタープライズ・ロール(ユーザー・グループ)およびログイン資格証明のデータ・ストアです。資格証明は、認証時に検証され、ユーザーのアプリケーション機能へのアクセスを認証するために使用されます。
ユーザー、ロール、およびレルムの理解
ユーザーとはサービスにアクセスするエンド・ユーザーのことで、個人の場合やソフトウェア・コンポーネントの場合もあります。エンタープライズ・ロールは、同じ権限セットを付与することを目的としてグループ化するユーザーのコレクションです。レルムとは、認証ユーザーおよび認証エンタープライズ・ロールのコレクションです。
ユーザー、エンタープライズ・ロールおよびレルムの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
JDeveloperのアイデンティティ・ストアの理解
JDeveloperでセキュアなアプリケーションを開発する際、ファイルベース・データ・ストアを使用してログオンを許可するユーザーを定義します。jazn-data.xmlファイルを介してファイルベースのアイデンティティ・ストアを定義する利点は、system-jazn-data.xmlファイルへの移行を介して本番環境へのデプロイメントとの互換性を維持しながら、簡易なテストをサポートする点です。さらに、LDAPベース・アイデンティティ・ストア用のOracle Internet Directoryサービスを設定および保守する複雑さを排除できます。
Oracle ADFを使用してFusion Webアプリケーションを作成すると、「ADFセキュリティの構成」ウィザードの実行時にアイデンティティ・ストアが自動的に作成されます。
|
注意: LDAPベースのアイデンティティ・ストアはJDeveloperの設計時機能であり、実行時には使用できません。LDAPアイデンティティ・ストアの構成はすべて、JDeveloperの統合WebLogic Serverによりオーバーライドされます。 |
アイデンティティ・ストアの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
アイデンティティ・ストアを作成する手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」フォルダ内のjps-config.xmlファイルをダブルクリックします。
jps-config.xml概要エディタで「アイデンティティ・ストア」タブを選択します。
ページの上部にある「新規アイデンティティ・ストアの追加」アイコンをクリックします。「アイデンティティ・ストアの作成」ダイアログが表示されます。
必要なタイプのアイデンティティ・ストア・オプションを選択します。
ファイル・ベースのアイデンティティ・ストアを作成する場合は、「XMLベースのアイデンティティ・ストア」を選択し、ストアの名前を入力します。デフォルトで、ファイル名はidstore.xmlです。
LDAPベースのアイデンティティ・ストアを作成する場合は、「LDAPベースのアイデンティティ・ストア」を選択し、ストアの名前を入力します。デフォルトで、ファイル名はidstore.oidです。
注意: LDAPベースのアイデンティティ・ストアはJDeveloperの設計時機能であり、実行時には使用できません。LDAPアイデンティティ・ストアの構成はすべて、JDeveloperの統合WebLogic Serverによりオーバーライドされます。
作業が完了した後、「OK」をクリックしてダイアログを閉じます。
アイデンティティ・ストアは、ユーザーとエンタープライズ・ロールを格納するXMLファイルであり、ユーザーの認証時に使用されます。アイデンティティ・ストアはドメイン・レベルまたはアプリケーション・レベルで使用できます。
ユーザーをアイデンティティ・ストアに追加する手順は、次のとおりです。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「ユーザー」を選択し、jazn-data.xmlファイルの概要エディタを開きます。
「ユーザー」ページで、「新規ユーザー」アイコンをクリックします。
新規ユーザー名およびパスワードを入力します。
「ユーザー」リストからユーザーを選択し、表示名や説明などの詳細を入力します。
jazn-data.xmlファイルへの変更内容を保存します。
エンタープライズ・ロールは、同じ権限を付与することを目的としてグループ化するユーザー・セットです。エンタープライズ・ロールはアイデンティティ・ストアに追加します。アプリケーション・ロールはポリシー・ストアに追加します。
|
注意: エンタープライズ・ロールにユーザーを追加する前に、アイデンティティ・ストアにユーザーが作成されていることを確認してください。 |
jazn-data.xmlファイルの概要エディタを使用して、アイデンティティ・ストアにロールを追加できます。
ロールをアイデンティティ・ストアに追加する手順は、次のとおりです。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「グループ」を選択し、jazn-data.xmlファイルの概要エディタの「エンタープライズ・ロール」ページを開きます。
「エンタープライズ・ロール」で、「新規ロール」アイコンをクリックします。「エンタープライズ・ロール」リストに新規ロールが表示されます。
「エンタープライズ・ロール」リストからロールを選択し、表示名や説明などの詳細を入力します。
jazn-data.xmlファイルの概要エディタを使用して、アイデンティティ・ストアにあるロールを管理できます。
エンタープライズ・ロールに割り当てられたユーザーを管理するには、次のようにします。
jazn-data.xmlファイルの概要エディタの「エンタープライズ・ロール」ページを開きます。
「エンタープライズ・ロール」リストからロールを選択し、「メンバー」タブをクリックします。
「メンバー」セクションで、他のメンバーまたはロールを追加または削除します。
資格証明ストアは、データベースなどの外部システムとの接続時にOracle Platform Security Services (OPSS)で必要とされるシステム資格証明を格納するウォレットベース・ファイルです。JDeveloperでは、資格証明ストアはcwallet.ssoファイルです。このファイルにはOPSSベースのすべての資格証明が含まれ、Oracle ADF Securityに定義する資格証明を格納するために使用されます。このファイルは通常、直接は編集されません。
JDeveloperは、ユーザーが「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで最初に接続(データベース接続など)を作成する際に、資格証明ストア・サービス・インスタンスの存在をチェックしてストアを作成します。
資格証明ストアの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
資格証明ストアを作成する手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」フォルダ内のjps-config.xmlファイルをダブルクリックします。
jps-config.xml概要エディタで「資格証明ストア」タブを選択します。
ページの上部にある「資格証明ストアを追加します。」アイコンをクリックします。「資格証明ストアの作成」ダイアログが表示されます。
資格証明ストア・ファイルの名前を入力し、「OK」をクリックします。
|
注意: 1つのアプリケーションに対して1つの資格証明のみ作成できます。 |
ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。ログイン・モジュールはプラグイン可能で、アプリケーション・コードを変更せずに使用できます。1つのアプリケーションに複数のログイン・モジュールを使用できます。
ログイン認証プロセスは、次の2つのフェーズで発生します。
ログイン・モジュールは、ユーザー・リクエスト、必要に応じて名前およびパスワード、またはその他の資格証明データを認証しようとします。このフェーズが成功した場合のみ、2つ目のフェーズが開始します。
ログイン・モジュールは、関連するプリンシパルをサブジェクトに割り当て、最終的にそれを使用して権限があるアクションが実行されます。
ドメイン内のすべてのログイン・モジュールは、次の要素を使用してファイルjps-config.xml内で構成されます。
serviceProvider - ログイン・モジュールのサービス・プロバイダの定義
serviceInstance - サービス・プロバイダの1つ以上のインスタンスの定義
jpsContext - 使用するインスタンスの指定
JDeveloperでは、アプリケーションの事前定義済ログイン・モジュールを選択するか、または新規のカスタム・ログイン・モジュールを作成できます。表21-2には、JDeveloperで使用可能な事前定義済ログイン・モジュールが含まれます。
表21-2 事前定義済ログイン・モジュール
| モジュール | 説明 |
|---|---|
|
|
SAMLトークン・アサーションに使用され、 |
|
|
Kerberosトークン・アサーションに使用され、 |
|
wss.digest.loginmodule |
WSS Digest仕様に基づくダイジェスト・ベースのユーザー名トークンの認証に使用され、 |
|
certificate.authenticator. |
X509証明書の割当てに使用され、 |
|
|
有効なユーザー名およびパスワードに基づくユーザー認証に使用され、 |
|
user.assertion.loginmodule |
有効なユーザー名およびパスワードに基づくユーザー認証に使用され、 |
|
|
JSEベースのユースケースの認証に使用され、 |
ログイン・モジュールの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
ログイン・モジュールを追加する手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」フォルダ内のjps-config.xmlファイルをダブルクリックします。
jps-config.xmlの概要エディタで「ログイン・モジュール」タブを選択します。
ページの上部にある「事前定義済ログイン・モジュールのリストから選択」アイコンをクリックします。「ログイン・モジュールの追加」ダイアログが表示されます。
追加するログイン・モジュールのチェックボックスを選択します。1つのアプリケーションで複数のログイン・モジュールを選択できます。
終了したら「OK」をクリックします。
ログイン・サービスは、Oracle Platform Securityのキー・コンポーネントです。概念的には、ログイン・サービスはJAASログイン・モジュールSPI (javax.security.auth.spi.LoginModule)をOracle Platform Security for Javaフレームワーク(OPSS)に結合するアダプタです。
ログイン・サービスの主な役割は、OPSSでのJAASログイン・モジュール実装の構成および使用を可能にすることです。
カスタム・ログイン・モジュールを追加する手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」フォルダ内のjps-config.xmlファイルをダブルクリックします。
jps-config.xmlの概要エディタで「ログイン・モジュール」タブを選択します。
ページ上部で「新規ログイン・モジュールの作成」をクリックします。
「ログイン・モジュール名」を入力して「OK」をクリックします。
ログイン・モジュールのクラス名を入力します。プロジェクトで使用可能な既存のクラス名を検索するには、「検索」ボタンをクリックします。
「ログイン制御フラグ」を選択します。REQUISITE、REQUIRED、SUFFICIENTまたはOPTIONALを選択できます。
「ログ・レベル」を選択します。FINE、FINER、FINEST、CONFIG、INFO、WARNING、SEVEREを選択できます。
「デバッグ」をクリックして、ログイン・モジュールでデバッグ・メッセージを出力するかどうかを定義します。
「すべてのロールの追加」を選択して、ログイン・モジュールを使用して認証後にユーザーのすべての直接または間接付与ロールをサブジェクトに追加するかどうかを定義します。
ログイン・モジュールで必要なその他のプロパティすべての、名前と値を入力します。
キーストアは、秘密鍵およびデジタル証明書のリポジトリです。
キーおよび証明書を持ち、アプリケーションのセキュア・サービスにそれらを使用する場合、JDeveloperでは、Java Key Store、Oracle Wallet (*.ssoファイルまたは*.p12ファイル)、またはPCKS12ファイル(*.p12ファイル)をインポートできます。JDeveloperでキーストアを作成することはできません。
キーストアおよびキーストア・プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの理解』を参照してください。
キー・ストアを追加する手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」フォルダ内のjps-config.xmlファイルをダブルクリックします。
jps-config.xmlの概要エディタで「キーストア」タブを選択します。
ページの上部にある「キー・ストアを追加します。」アイコンをクリックします。「キー・ストアの追加」ダイアログが表示されます。
キー・ストア・ファイルをインポートし、必須フィールドに入力します。キーストアとしてJava Key Store (*.jksファイル)、Oracle Wallet (from a *.ssoまたは*.p12ファイル)、またはPCKS12 (*.p12ファイル)ファイルをインポートできます。
終了したら「OK」をクリックします。
無名プロバイダとは、パブリック・ページの代替です。ここでは、未認証ユーザーにパブリック・ページ全体に対するアクセス権を許可するのではなく、よりきめの細かい権限を割り当てることができます。
無名プロバイダを有効にすることで、無名サービス・インスタンスと無名ログイン・モジュールを含む無名JpsContextを作成できます。アプリケーション・ユーザーが未認証の場合は、実行時に無名資格証明が使用され、認証なしで一部のリソースへのアクセスが許可されます。
無名プロバイダの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
Webアプリケーションに対して無名プロバイダを有効にする手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「META-INF」フォルダ内のjps-config.xmlファイルをダブルクリックします。
jps-config.xmlの概要エディタで「無名プロバイダ」タブを選択します。
「無名プロバイダの有効化」を選択します。
「セキュリティ・コンテキスト」タブを選択し、無名が無名プロバイダとして自動的に選択されていることを確認します。
資格証明にはユーザーの認証パスワードが含まれます。資格証明は、デフォルトで不明瞭化されたフォームで表示されます。アイデンティティ・ストアに資格証明を追加する前に、最初にアイデンティティ・ストアのメンバー・ユーザーを定義する必要があります。
アイデンティティ・ストアで資格証明をユーザーに追加する手順は、次のとおりです。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「ユーザー」を選択し、jazn-data.xmlの概要エディタの「ユーザー」ページを開きます。
「ユーザー」リストでユーザーを選択し、資格証明を「パスワード」フィールドに追加します。
ユーザーが保護されたWebアプリケーション領域を要求すると、宣言セキュリティでの認証が強制されます。ユーザーがこれまで認証されていない場合、コンテナはユーザーから資格証明を取得します。ユーザーはサーバー・セッション中、認証されたままです。
サポートされている認証タイプは、FORMベース認証、BASIC認証およびCLIENT-CERT認証です。認証タイプは、<login-config>要素を使用してweb.xmlデプロイメント・ディスクリプタで指定されます。
認証タイプの詳細は、第21.4.1項「認証タイプの選択肢について」を参照してください。
Webアプリケーションの認証タイプを選択する手順は、次のとおりです。
「アプリケーション」ウィンドウでアプリケーションのweb.xmlファイルをダブルクリックします。
web.xml概要エディタの「セキュリティ」タブをクリックします。
「ログイン認証」セクションを展開し、必要な認証タイプを選択します。
WebアプリケーションのWebページおよび他のリソースは、保護する必要があります。アプリケーションのタイプに応じて、次の2つのいずれかの方法でアプリケーションを保護できます。
Java EE Webアプリケーションの場合、Oracle Platform Security Services (OPSS)を使用してWebアプリケーションを保護します。
Oracle Application Development Framework (ADF)を使用して開発されたアプリケーションの場合、Oracle ADF Securityを使用してアプリケーションを保護します。
OPSSセキュリティの使用
次のタスクは、Java EEセキュリティを使用したアプリケーションの保護プロセスの概要を示しています。
ユーザーに対する認証メカニズムを指定します。
レルム内のユーザーおよびグループを管理します。
アプリケーションのセキュリティ・ロールを作成します。
ユーザーおよびグループにロールをマップします。
Oracle ADF Securityの使用
Oracle ADF Securityフレームワークを使用して、Fusion Webアプリケーションに認証と認可のサービスを提供できます。
Oracle ADF Securityの詳細は、Oracle Fusion ADF開発者ガイドのFusion WebアプリケーションでのADFセキュリティの有効化に関する項を参照してください。
JDeveloperを使用すると、アプリケーションのリソース・タイプを保護できます。リソース・タイプは把握(つまり、JDeveloperによる認識)が可能です。また、独自のリソース・タイプを作成することもできます。
リソース・タイプは、フロー、ジョブ、Webサービスなどのセキュア・アーティファクトのタイプを表し、基本的には特定のタイプのリソースを作成するためのテンプレートです。すべてのリソースは、タイプが関連付けられており、タイプに応じてフィルタまたはグループ化されます。
アプリケーションのリソースを保護するには、次のようにします。
「アプリケーション」ウィンドウでアプリケーションを開きます。
メイン・メニューで、「アプリケーション」→「保護」→「リソース権限」を選択し、jazn-data.xmlファイルの概要エディタの「リソース権限」ページを開きます。
「リソース・タイプ」ドロップダウン・リストで、保護するリソース・タイプ(「タスク・フロー」など)を選択します。リストには、選択したプロジェクトで使用可能なすべてのリソース・タイプが表示されます。また、新規リソース・タイプを作成することもできます。
「ソース・プロジェクトの選択」アイコンを選択し、ソース・プロジェクトを選択します。選択したソース・プロジェクトから選択したリソース・タイプのインスタンスが「リソース」リストに表示されます。
リソース権限を付与する権限受領者(アプリケーション・ロール、エンタープライズ・ロールまたはコード・ソース)を追加します。リソース権限は、ユーザー、アプリケーション・ロール、エンタープライズ・ロールまたはコード・ソースに付与できます。「付与先」リストの「権限受領者の追加」アイコンをクリックし、権限受領者を追加します。
「アクション」リストで、リソースに対して許可するアクションを選択します。
jazn-data.xmlファイルへの変更内容を保存します。
Fusion Webアプリケーションで定義するセキュリティ・ポリシーは、ADFタスク・フローおよびADFページ定義などのADFセキュリティ対応リソースに対するきめ細かなアクセス制御をサポートします。ADFセキュリティ・ポリシーを有効にするには、まずユーザー・インタフェース・プロジェクトで「ADFセキュリティの設定」ウィザードを実行します。
ADF Securityを有効にしたら、ユーザーにアクセス権を付与する必要があります。これによってユーザーは、Fusion WebアプリケーションのWebページを表示できるようになります。ユーザーに付与するアクセス権は、ページのADFセキュリティ対応リソース用に指定するセキュリティ・ポリシーとして知られています。タスク・フローの入力やWebページの表示を行うユーザー権限を制御するのは、最終的にはADFリソースにおけるセキュリティ・ポリシーになります。
バインドされたタスク・フローの個々のWebページに対してはセキュリティ・ポリシーを定義しないでください。ユーザーがバインド・タスク・フローにアクセスする場合、すべてのページのセキュリティはタスク・フローに付与する権限により管理されます。また、デフォルトで、(ページ定義が関連付けられている)個々のWebページにはアクセスできないため、ADFセキュリティによりユーザーはタスク・フローの各ページに直接アクセスすることはできません。これにより、タスク・フローの明確なセキュリティ・モデルがサポートされ、すべてのユーザーに単一エントリ・ポイントを強制します。
Webページがバインドされたタスク・フローの構成要素ではない場合のみ、個々のページに対してセキュリティ・ポリシーを定義してください。ページが直接アクセスされる場合、またはページがバインドされていないタスク・フローでアクセスされる場合のみ、ページ定義バインド・ファイルが関連付けられたページに対してページ・レベルのセキュリティがチェックされます。
ADFセキュリティ・ポリシーは、ファイルベースのjazn-data.xmlポリシー・ストアで保守されます。JDeveloperでのADFセキュリティ・ポリシーの定義および更新は、このファイルの概要エディタによってサポートされます。作成された宣言ADFセキュリティ・ポリシーは容易に読み取ることができます。
Oracle ADFリソースを保護するための詳細ステップは、Oracle Fusion ADF開発者ガイドのFusion WebアプリケーションでのADFセキュリティの有効化に関する項を参照してください。
ADFリソースのセキュリティ・ポリシーを定義する手順は、次のとおりです。
「ADFセキュリティの構成」ウィザードを実行して、アプリケーションに対してADFセキュリティを強制します。
ポリシー・ストアにアプリケーション・ロール名を追加します。
ADFバインド・タスク・フローに含まれる一連のWebページ全体に対する権限を付与します。
ADFページ定義ファイルに関連付けられていてバインド・タスク・フローには関連付けられていない最上位Webページに対する権限を付与します。
データ対応コンポーネントが含まれていないためにADFリソースに関連付けられていない最上位レベルのWebページがアプリケーションに含まれる場合、必要に応じて、これらのページを保護することもできます。
必要に応じて、ADFエンティティ・オブジェクトにより定義されているデータの行に対する権限を付与します。
セキュリティをテストするためにログインするユーザーを追加して、アイデンティティ・ストアをプロビジョニングします。
作成したテスト・ユーザーを1つ以上のアプリケーション・ロールに関連付けます。
ポリシー・ストアとは、アプリケーションおよびエンタープライズ・ポリシーのリポジトリです。ポリシーは、特定の場所から実行されるコードに付与される権限を指定します。
アプリケーション・ポリシー・ストアは、アプリケーション・ポリシーのリポジトリであるとともに、アプリケーション・ロール、アプリケーション・ポリシー、プリンシパル、および権限のリポジトリです。アプリケーション・ロールには、アプリケーション・ユーザーとアプリケーション・ロール、およびアプリケーション固有のロール(管理ロールなど)を含むことができます。ポリシーでは、これらのロールまたはユーザーをプリンシパルとして使用できます。同様に、システム・ポリシー・ストアは、システム・ポリシー、プリンシパル、および権限のリポジトリです。システム・ポリシー・ストアにロールは含まれません。
Oracle ADFを使用してFusion Webアプリケーションを作成すると、「ADFセキュリティの構成」ウィザードの実行時にポリシー・ストアが自動的に作成されます。
アプリケーション・ポリシー・ストアとシステム・ポリシー・ストアの違いは、その範囲にあります。アプリケーション・ポリシー・ストアは1つのアプリケーション内に制約されてそのアクセシビリティが制限されますが、システム・ポリシー・ストアにはオープンにアクセスできます。
ポリシー・ストアの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
プリンシパルとは、エンティティ(ユーザーまたはロール)に割り当てられたアイデンティティです。権限とは、エンティティのグループに対して許可された一連の操作で、エンティティはプリンシパルである場合もあります。付与またはカスタム・ポリシーには、権限およびプリンシパルが含まれます。JDeveloperでは、付与を作成せずにプリンシパルおよび権限を作成できません。
アプリケーション・ロールはアプリケーションに固有で、アプリケーション・ポリシー・ストアで定義されます。アプリケーション・ロールはアプリケーションで直接使用され(Java SEまたはJava EEアプリケーションで)、Java EEコンテナに認識される必要はありません。jazn-data.xmlファイルのファイルベース・ポリシー・ストアでは、これらのアプリケーション・ロールは<policy-store>の<app-role>要素で定義され、デプロイ時にドメイン・レベルでsystem-jazn-data.xmlに書き込まれます。
アプリケーション・ポリシー・ストアにアプリケーション・ロールを追加する手順は、次のとおりです。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「アプリケーション・ロール」を選択し、jazn-data.xmlファイルの概要エディタの「アプリケーション・ロール」ページを開きます。
「追加」アイコンをクリックし、現在選択されているロールのピアまたは子として新規アプリケーション・ロールを作成するか、新規ロール・カテゴリを作成します。「ロール」リストに新規アプリケーション・ロールまたはカテゴリが表示されます。
「名前」、「表示名」および「説明」フィールドにロールまたはロール・カテゴリの詳細を入力します。
jazn-data.xmlファイルへの変更内容を保存します。
詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』ガイドを参照してください。
デプロイメント・ユーザーおよびロールは、使用するセキュリティ・プロバイダで定義されます。ファイルベース・プロバイダの場合、デプロイメント・ユーザーおよびロールはjazn-data.xmlファイルで定義されます。
|
注意: メンバー・ユーザーまたはメンバー・ロールをアプリケーション・ロールに追加する前に、まずアイデンティティ・ストアのメンバー・ユーザーおよびメンバー・ロールを定義する必要があります。 |
アプリケーション・ロールにユーザーまたはエンタープライズ・ロールを追加するには、次のようにします。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「アプリケーション・ロール」を選択し、jazn-data.xmlファイルの概要エディタの「アプリケーション・ロール」ページを開きます。
「アプリケーション・ロール」リストからアプリケーション・ロールを選択し、「メンバー」タブをクリックします。
ユーザーを追加するには、「メンバー・ユーザーとロール」で、「ユーザーまたはロールの追加」アイコンをクリックし、「ユーザーの追加」を選択します。
エンタープライズ・ユーザーを追加するには、「メンバー・ユーザーとロール」で、「ユーザーまたはロールの追加」アイコンをクリックし、「エンタープライズ・ロールの追加」を選択します。
jazn-data.xmlファイルへの変更内容を保存します。
カスタム・リソース・タイプを作成し、これらをjazn-data.xmlファイルに指定できます。
リソース・タイプは、フロー、ジョブ、Webサービスなどのセキュア・アーティファクトのタイプを表し、基本的には特定のタイプのリソースを作成するためのテンプレートです。すべてのリソースは、タイプが関連付けられており、タイプに応じてフィルタまたはグループ化されます。
カスタム・リソース・タイプを作成するには、次のようにします。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「リソース権限」を選択し、jazn-data.xmlファイルの概要エディタの「リソース権限」ページを開きます。
「リソース権限」ページで、「リソース・タイプ」フィールドの横にある「新規リソース・タイプ」アイコンをクリックします。
「リソース・タイプの作成」ダイアログで、名前、表示名および関連付けられたアクションなどのリソースのプロパティを指定します。「リソース・タイプの作成」ダイアログの「アクション」リストを使用して、このタイプのリソースの「リソース権限」ページでチェック可能な項目リストを移入します。
jazn-data.xmlファイルを保存します。
jazn-data.xmlの概要エディタの「リソース権限」ページを更新することにより、アプリケーション・リソース権限をアプリケーション・ポリシー・ストアに追加できます。
リソースは、具体的なリソースを表すリソース・タイプのインスタンスであり、ポリシーで保護できるアプリケーション・リソースを定義します。このリソースには、URL、EJB、JSPのようにコンテナで管理するソフトウェア・コンポーネントや、レポート、トランザクション、収益チャートなどのアプリケーション・ビジネスがあります。
アプリケーション・ポリシー・ストアにリソース権限を追加するには、次のようにします。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」→「保護」→「リソース権限」を選択し、jazn-data.xmlファイルの概要エディタの「リソース権限」ページを開きます。
セキュリティ・ポリシーを定義するには、「セキュリティ・ポリシー」フィールドで項目を選択します。デフォルトでは、アプリケーション・セキュリティ・ポリシーが選択されています。グローバル・リソース権限を定義するには、「グローバル」を選択します。
「リソース・タイプ」ドロップダウン・メニューからリソース・タイプを選択するか、「新規リソース・タイプ」アイコンをクリックしてリソース・タイプを作成します。
プロジェクトによってフィルタされるリソース・タイプの場合、「ソース・プロジェクト」セレクタが有効です。目的のリソースを検索するためにソース・プロジェクト選択を変更する必要がある場合があります。
選択したリソース・タイプに属するリソースは「リソース」リストに表示されます。
「付与先」リストの「権限受領者の追加」アイコンをクリックし、リソース権限が付与されているエンティティを管理します。アプリケーション・ロール、ユーザー、エンタープライズ・ロールまたはコード・ソースに対して付与できます。
「アクション」リストでリソースに許可されているアクションを表示および選択します。
jazn-data.xmlの概要エディタの「資格付与」ページを使用すると、一連のリソース権限を定義し、各権限を各アプリケーション・ロールに個別に付与する必要なく、これらの権限を複数のアプリケーション・ロールに付与できます。
資格は、権限のコレクションです。通常、これによって、特定のビジネス機能またはタスクを実行するために必要な権限のリストがカプセル化されます。
アプリケーション・ポリシー・ストアに資格付与を追加するには、次のようにします。
「アプリケーション」ウィンドウでアプリケーションを開きます。
メイン・メニューで、「アプリケーション」→「保護」→「資格付与」を選択し、jazn-data.xmlファイルの概要エディタの「資格付与」ページを開きます。
資格付与を追加するには、「資格」リストの「資格の追加」アイコンをクリックします。
メンバー・リソースを追加するには、「リソース」をクリックし、「メンバー・リソース」リストで「メンバー・リソースの追加」アイコンをクリックします。
資格を付与するアプリケーション・ロールを選択するには、「付与」を選択し、「ロール付与の追加」アイコンをクリックします。「アプリケーション・ロールの選択」ダイアログで、アプリケーション・ロールを選択するか、新規アプリケーション・ロールを作成できます。
jazn-data.xmlファイルを保存します。
|
ヒント:
|
新規権限クラスは、保護対象の論理アーティファクト・タイプに対して独自のJAAS権限を作成する場合に便利です。たとえば、Oracle ADFではすでに、セキュリティを強制するアーティファクト用のビルトイン権限クラス(タスク・フロー、ページ定義、エンティティ・オブジェクトおよびエンティティ属性など)が提供されていますが、ユーザー・インタフェースで保護する一連のUIコンポーネント用にカスタム権限クラスを作成できます。このクラスを作成すると、Java、式言語(EL)、またはGroovy式を使用した強制チェックを追加でき、その後jazn-data.xmlファイルを直接編集してアプリケーション・ロールに新しいカスタム権限クラスを付与できます。たとえば、セキュリティ・ポリシーを定義してアプリケーションに表示されるメニューへのアクセスを制限し、その後、コンポーネントのrenderedプロパティ上のEL値userGrantedPermissionを使用して、メニュー表示と付与されたユーザーのカスタム権限を関連付けることができます。
カスタムJAAS対応権限クラスを作成するには、次のようにします。
「アプリケーション」ウィンドウでアプリケーションを開きます。
メイン・メニューから「ファイル」→「新規」を選択して「新規ギャラリ」を開きます。
「新規ギャラリ」の「カテゴリ」で、「ビジネス層」→「セキュリティ」を選択します。
「項目」で、「JAAS権限」を選択します。
JAAS権限の作成ダイアログで、カスタム権限クラスの詳細を入力します。ダイアログ内でヘルプを参照するには、「ヘルプ」をクリックするか[F1]を押します。
現在、このリリースには、システム権限付与をシステム・ポリシー・ストアに追加するためのエディタがありません。jazn-data.xmlのソース・コードで付与を手動で追加する必要があります。
システム・ポリシーへの付与を追加する手順は、次のとおりです。
「アプリケーション」ウィンドウでアプリケーションを開きます。
「アプリケーション」ウィンドウで、jazn-data.xmlをダブルクリックして概要エディタを開きます。
「ソース」をクリックし、ソース・エディタを開きます。
ソース・コードで、<jazn-data>要素内に<jazn-policy>要素を作成します。
<jazn-policy>要素内で、目的のアプリケーション・ロールを持つ<grantee>、権限クラスの完全修飾クラス名を持つ<permission>、付与のターゲットとして使用する名前、およびアプリケーション・ロール・プリンシパルに付与するアクションを定義する<grant>要素を作成します。
jazn-data.xmlファイルへの変更内容を保存します。
JDeveloperはデフォルトで、アプリケーションを実行するたびにアプリケーション・リポジトリから統合WebLogic Serverにセキュリティ・オブジェクトをデプロイするよう構成されています。この動作は、「アプリケーション・プロパティ」ダイアログでのセキュリティ・デプロイメント・オプションの選択により、次のように変更できます。
ドメイン・レベル・ポリシーをアプリケーションのjazn-data.xmlファイル内のポリシーにより上書きするかどうかを決定します。
システム資格証明をアプリケーションのcwallet.ssoファイルにより上書きするかどうかを決定します。
jazn-data.xmlファイルのアイデンティティ・ストアの一部をドメイン・レベル・アイデンティティ・ストアに移行するかどうかを決定します。
デプロイ設定を変更しない場合、アプリケーションを実行するたびに、JDeveloperはドメイン・レベルのセキュリティ・ポリシーおよびシステム資格証明を上書きします。また、テスト目的で作成した新しいユーザー・アイデンティティを移行し、統合WebLogic Serverがそのアイデンティティ・ストアで使用する埋込みLDAPサーバー内の既存のユーザー・パスワードを更新します。ただし、統合WebLogic Server内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。
スタンドアロンOracle WebLogic Serverにアプリケーションをデプロイする準備ができている場合、同じ構成設定を使用して、JDeveloperでセキュリティ・オブジェクトの移行を処理する方法を制御できます。
セキュリティ・オブジェクトのデプロイを構成する手順は、次のとおりです。
「アプリケーション」→「保護」→「セキュリティ・デプロイメントの構成」を選択し、「アプリケーション・プロパティ」ダイアログを開きます。
「アプリケーション・プロパティ」ダイアログの「セキュリティ・デプロイメント・オプション」の下で、アプリケーションでデプロイするセキュリティ・オブジェクトを選択します。
デフォルトで、アプリケーションを実行するたびに、JDeveloperではドメイン・レベルのアプリケーション・ポリシーおよび資格証明がアプリケーションのアプリケーション・ポリシーおよび資格証明により上書きされます。これらのリポジトリを上書きしない場合、「アプリケーション・ポリシー」または「資格証明」の選択を解除します。選択を解除すると、新規ポリシーまたは資格証明のみがドメイン・レベルのストアにマージされます。詳細は、後述のセクションを参照してください。
デフォルトでは、アプリケーションを実行するたびに、テスト目的で作成する新規ユーザーのアイデンティティがJDeveloperによって移行され、統合WebLogic Serverでアイデンティティ・ストア用に使用される埋込みLDAPサーバーにある既存のユーザー・パスワードが更新されます。「ユーザーとグループ」の選択を解除して、アプリケーションのアイデンティティ・ストアの移行を無効にできます。詳細は、後述のセクションを参照してください。
「OK」をクリックします。
Oracle WebLogic Server環境のサーバーにアプリケーションをデプロイする際、jazn-data.xmlで指定したアプリケーション・ポリシーをドメイン・ポリシー・ストアに移行できます。必要に応じて、アプリケーションがアンデプロイされる際、またはアプリケーションが再デプロイ時に更新される際に、ドメイン・ポリシー・ストアからポリシーを削除することもできます。
「アプリケーション・プロパティ」ダイアログで「アプリケーション・ポリシー」が選択されている場合、JDeveloperによるアプリケーションのデプロイ時、パッケージ化されたweblogic-application.xmlでjps.policystore.migrationプロパティはOVERWRITEに設定されます。「アプリケーション・ポリシー」が選択されていない場合、jps.policystore.migrationの設定はパッケージ化されたweblogic-application.xmlに追加されず、すでに存在する場合には削除されます。これによりOracle WebLogic Serverではデフォルトの操作MERGEが使用されます。ポリシーが存在しない場合、アプリケーションが初めてデプロイされるときのみマージによりポリシーが移行されます。アプリケーションのポリシーがすでに存在する場合、再移行は行われません。
アプリケーション・ポリシーの自動および手動による移行の詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
アプリケーション・ポリシーを移行する際、資格証明も移行する必要がある場合があります。WebLogic環境で管理されたサーバーにアプリケーションをデプロイまたは再デプロイする際に、cwallet.ssoで指定されたアプリケーションの資格証明をドメイン資格証明ストアに移行できます。したがって、資格証明の移行には、JDeveloper内で作成されたすべての接続(Webサービス用に作成された接続を含む)のパスワードが含まれます。(これは、jazn-data.xmlファイルのアイデンティティ・ストアで指定したユーザー資格証明には関連しません。アイデンティティ・ストアの移行の詳細は、次の第21.7.4項「ユーザーおよびグループの移行」を参照してください)。
「アプリケーション・プロパティ」ダイアログで「資格証明」が選択されている場合、JDeveloperによるアプリケーションのデプロイ時、パッケージ化されたweblogic-application.xmlでjps.policystore.migrationプロパティはOVERWRITEに設定されます。「資格証明」が選択されていない場合、jps.policystore.migrationの設定はパッケージ化されたweblogic-application.xmlに追加されず、すでに存在する場合には削除されます。これによりOracle WebLogic Serverではデフォルトの操作MERGEが使用されます。資格証明が存在しない場合、アプリケーションが初めてデプロイされるときのみマージにより資格証明が移行されます。アプリケーションの資格証明がすでに存在する場合、再移行は行われません。
資格証明を移行できるのは、サーバーが「開発」モードで実行中の場合のみです。本番モードでは、資格証明を上書きできません。アプリケーション資格証明の移行は、JDeveloperの外部のツールを使用したデプロイ時に手動で行う必要があります。
WebLogic環境のサーバーにアプリケーションをデプロイする際、jazn-data.xmlで指定したユーザーおよびロールをドメイン・アイデンティティ・ストアに移行できます。
「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」が選択されている場合、アプリケーションをデプロイしてアプリケーションのjazn-data.xmlユーザーおよびロールに関連するOracle WebLogic Serverのユーザーおよびグループを作成すると、JDeveloperではコールが作成されます。ドメイン・ストアにユーザーがすでに存在する場合は、説明およびパスワードのみがデプロイ時に再移行されます。jazn-data.xmlファイル内のロールと同じ名前でグループがドメイン・ストア内に存在する場合、それは完全に置き換えられます。「ユーザーとグループ」が選択されていない場合、アイデンティティ・ストアのjazn-data.xmlアプリケーションからの移行は試行されません。
|
注意: ドメイン・アイデンティティ・ストアが上書きされないよう、ユーザーとグループを移行する前には、管理ロール( |
JDeveloperでJDBCデータベース接続を作成すると、マシンにインストールされているデータベース・クライアントから暗号化プロパティが導出されます。JDBCを使用してセキュアな接続を作成するには、次のようにします。
クライアント・マシンのsqlnet.oraファイルでパラメータを設定し、OCIドライバによる暗号化サポートを構成します。
JDBCシン・ドライバを使用し、JDeveloperにセキュアなJDBC接続を作成します。「データベース接続の作成」ウィザードのステップ3 (「接続」ページ)で、「カスタムJDBC URLの入力」を選択し、例21-3に示すように、暗号化パラメータをカスタムJDBC URLの一部として入力します。
