この章の内容は次のとおりです。
セキュアなアプリケーションの開発について説明します。
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 Platform Security Servicesの概要」を参照してください。
Oracle ADFセキュリティ・フレームワークは、認証および認可サービスをFusion Webアプリケーションに提供するための推奨テクノロジです。主な理由は、Oracle ADF Securityが、Oracle Platform Security Services(OPSS)アーキテクチャの上部で構築され、このアーキテクチャにより重要なセキュリティ・フレームワークが実現され、Oracle WebLogic Serverと緊密に統合されているためです。
「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。
「Oracle Platform Security Servicesの概要」を参照してください。
JDeveloperは、開発時および本番環境へのデプロイ時のセキュリティをサポートしています。
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サーバーの詳細は、「LDAP認証プロバイダの構成」を参照してください。
このため、JDeveloperでファイルベース・プロバイダおよびOPSSを使用すると、次のようにして本番環境での要求を分離できます。
テスト・ユーザーおよびアプリケーション・ロールを宣言によって定義する
Oracle ADFリソースのセキュリティ・ポリシーを宣言によって定義する
デプロイ時にアプリケーション・レベルのセキュリティ・プロバイダからsystem-jazn-data.xml
セキュリティ・プロバイダに容易に移行する
デプロイまでエンタープライズ・ロールのマッピングを見送る
Webアプリケーションのセキュリティについて説明します。
Oracle WebLogic Serverでは、Java EE宣言セキュリティはOracle Platform Security Services (OPSS) (OracleのJAAS標準の実装)とともに実装されます。OPSSは、Java EEセキュリティを拡張することにより、アプリケーション開発者、システム・インテグレータ、セキュリティ管理者および独立系ソフトウェア・ベンダーに、Java SEおよびJava EEアプリケーション用の移植可能で統合された包括的なセキュリティ・プラットフォーム・フレームワークを提供します。
OPSSおよびその機能の詳細は、「Oracle Platform Security Servicesの概要」を参照してください。
JDeveloperには、Webアプリケーション用のJava EEセキュリティの構成、およびセキュアなWebアプリケーションのアプリケーション・サーバー・インスタンスへのデプロイをサポートするツールが用意されています。開発者は、アプリケーション開発時にウィザードおよびエディタを介して、JDeveloperからOPSSサービスを構成できます。
JDeveloperには、Oracle Platform Security構成(jps-config.xml
)、JAAS構成(jazn-data.xml
)およびWebアプリケーション・デプロイメント・ディスクリプタ(web.xml
)を作成および編集する固有のエディタがあります。JDeveloperでは、Webアプリケーションのアプリケーション・サーバーへの直接デプロイメントもサポートされています。「フェーズでのアプリケーションの保護」を参照してください。
Webアプリケーションを開発する場合、Oracle Application Development Framework (Oracle ADF)を使用してユーザー・インタフェース内のデータ対応のコンポーネントを操作することを選択できます。ユーザー・インタフェースにADFタスク・フローやADFページ定義などのADFリソースが含まれる場合、ADFセキュリティ・フレームワークを介してこれらのリソースに依存するWebページを保護するオプションも用意されています。JDeveloperツールはセキュリティの繰返し型開発をサポートしているため、ADFリソース用として作成するセキュリティ・ポリシーを簡単に作成、テストおよび編集できます。JDeveloperでテスト・ユーザーの作成に進み、統合WebLogic Serverでアプリケーションを実行し、エンド・ユーザーがセキュアなリソースにアクセスする方法をシミュレートできます。次を参照してください。Fusion WebアプリケーションのADFセキュリティを使用したADFリソースの保護方法。
Webアプリケーション・セキュリティの詳細は、「WebLogicセキュリティ・プログラミングの概要」を参照してください。
ユーザーが保護されたWebアプリケーション領域を要求すると、宣言セキュリティでの認証が強制されます。
ユーザーが保護されたWebアプリケーション領域を要求すると、宣言セキュリティでの認証が強制されます。ユーザーがこれまで認証されていない場合、コンテナはユーザーから資格証明を取得します。ユーザーはサーバー・セッション中、認証されたままです。
サポートされている認証タイプは、FORMベース認証、BASIC認証およびCLIENT-CERT認証です。認証タイプは、<login-config>
要素を使用してweb.xml
デプロイメント・ディスクリプタで指定されます。
BASIC認証では、ユーザーがユーザー名とパスワードを入力できるようにブラウザのログイン・ダイアログが使用されます。このダイアログ・フォームはカスタマイズできないため、使用するブラウザに応じてルック・アンド・フィールが異なります。ユーザー資格証明は認証済レルムのブラウザ・セッションに格納されます。レルムは、認証されたユーザーの一連の権限が含まれるリポジトリです。Oracle Platform Security Servicesのデフォルトのレルムは、jazn.com
です。
次のコード・スニペットは、BASIC認証をweb.xml
ファイルに指定する方法を示しています。
<login-config> <auth-method>BASIC</auth-method> <realm-name>jazn.com</realm-name> </login-config>
FORMベース認証では、アプリケーション開発者はカスタム・ログイン・ダイアログを指定できます。usernameパラメータの名前はj_username
で、パスワード・フィールドの名前はj_password
である必要があります。要求を認証するJava EEコンテナのログイン・フォーム・アクションの値はj_security_check
である必要があります。
次のコード・スニペットは、FORM認証をweb.xml
ファイルに指定する方法を示しています。
<login-config> <auth-method>FORM</auth-method> <form-login-config> <form-login-page>loginform.jsp</form-login-page> <form-error-page>error.jsp</form-error-page> </form-login-config> </login-config>
パスワード暗号化は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つのサーバー・インスタンスを持つマシンでのみ実行できます。クライアントからは実行できません。表19-1は、weblogic.security.Encrypt
ユーティリティの引数を定義しています。
注意:
ユーティリティは、管理サーバー・ドメイン・ディレクトリから、または管理サーバーをホストしてドメイン・ルート・ディレクトリを指定するマシンで実行することをお薦めします。
構文
java [ -Dweblogic.RootDirectory= dirname ] [ -Dweblogic.management.allowPasswordEcho=true ] weblogic.security.Encrypt [ password ]
表19-1 weblogic.security.Encryptユーティリティの引数
引数 | 定義 |
---|---|
|
オプション。暗号化文字列を使用するWebLogic Serverドメイン・ディレクトリです。指定しない場合、デフォルトのドメイン・ルート・ディレクトリは現在のディレクトリ(ユーティリティを実行するディレクトリ)になります。 |
|
オプション。コマンド行weblogic.securityに入力したエコー文字が許可されます。暗号化では、エコーが利用できないことが期待されています。エコーを利用できない場合は、このプロパティを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
アイデンティティ・ストアは、ユーザー、エンタープライズ・ロール(ユーザー・グループ)およびログイン資格証明のデータ・ストアです。資格証明は、認証時に検証され、ユーザーのアプリケーション機能へのアクセスを認証するために使用されます。
この項で使用されている用語の詳細は、用語に関する項を参照してください。
ユーザー、ロール、およびレルムの理解
ユーザーとはサービスにアクセスするエンド・ユーザーのことで、個人の場合やソフトウェア・コンポーネントの場合もあります。エンタープライズ・ロールは、同じ権限セットを付与することを目的としてグループ化するユーザーのコレクションです。レルムとは、認証ユーザーおよび認証エンタープライズ・ロールのコレクションです。
JDeveloperのアイデンティティ・ストアの理解
JDeveloperでセキュアなアプリケーションを開発する際、ファイルベース・データ・ストアを使用してログオンを許可するユーザーを定義します。jazn-data.xml
ファイルを介してファイルベースのアイデンティティ・ストアを定義する利点は、system-jazn-data.xml
ファイルへの移行を介して本番環境へのデプロイメントとの互換性を維持しながら、簡易なテストをサポートする点です。さらに、LDAPベース・アイデンティティ・ストア用のOracle Internet Directoryサービスを設定および保守する複雑さを排除できます。
Oracle ADFを使用してFusion Webアプリケーションを作成すると、「ADFセキュリティの構成」ウィザードの実行時にアイデンティティ・ストアが自動的に作成されます。
注意:
LDAPベースのアイデンティティ・ストアはJDeveloperの設計時機能であり、実行時には使用できません。LDAPアイデンティティ・ストアの構成はすべて、JDeveloperの統合WebLogic Serverによりオーバーライドされます。
アイデンティティ・ストアを作成する手順は、次のとおりです。
アイデンティティ・ストアは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で使用されます。このファイルは通常、直接は編集されません。
JDeveloperは、ユーザーが「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで最初に接続(データベース接続など)を作成する際に、資格証明ストア・サービス・インスタンスの存在をチェックしてストアを作成します。
資格証明ストアを作成する手順は、次のとおりです。
jps-config.xml
ファイルをダブルクリックします。jps-config.xml
概要エディタで「資格証明ストア」タブを選択します。注意:
1つのアプリケーションに対して1つの資格証明のみ作成できます。
ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。ログイン・モジュールはプラグイン可能で、アプリケーション・コードを変更せずに使用できます。1つのアプリケーションに複数のログイン・モジュールを使用できます。
ログイン認証プロセスは、次の2つのフェーズで発生します。
ログイン・モジュールは、ユーザー・リクエスト、必要に応じて名前およびパスワード、またはその他の資格証明データを認証しようとします。このフェーズが成功した場合のみ、2つ目のフェーズが開始します。
ログイン・モジュールは、関連するプリンシパルをサブジェクトに割り当て、最終的にそれを使用して権限があるアクションが実行されます。
ドメイン内のすべてのログイン・モジュールは、次の要素を使用してファイルjps-config.xml
内で構成されます。
serviceProvider
- ログイン・モジュールのサービス・プロバイダの定義
serviceInstance
- サービス・プロバイダの1つ以上のインスタンスの定義
jpsContext
- 使用するインスタンスの指定
JDeveloperでは、アプリケーションの事前定義済ログイン・モジュールを選択するか、または新規のカスタム・ログイン・モジュールを作成できます。表19-2には、JDeveloperで使用可能な事前定義済ログイン・モジュールが含まれます。
表19-2 事前定義済ログイン・モジュール
モジュール | 説明 |
---|---|
|
SAMLトークン・アサーションに使用され、 |
|
Kerberosトークン・アサーションに使用され、 |
wss.digest.loginmodule |
WSS Digest仕様に基づくダイジェスト・ベースのユーザー名トークンの認証に使用され、 |
certificate.authenticator. loginmodule |
X509証明書の割当てに使用され、 |
|
有効なユーザー名およびパスワードに基づくユーザー認証に使用され、 |
user.assertion.loginmodule |
有効なユーザー名およびパスワードに基づくユーザー認証に使用され、 |
|
JSEベースのユースケースの認証に使用され、 |
Javaアプリケーションでのログイン・モジュールの使用に関する項を参照してください。
ログイン・モジュールを追加する手順は、次のとおりです。
「アプリケーション」ウィンドウの「アプリケーション・リソース」パネルで、「ディスクリプタ」→「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ログイン・モジュール実装の構成および使用を可能にすることです。
カスタム・ログイン・モジュールを追加する手順は、次のとおりです。
jps-config.xml
ファイルをダブルクリックします。「ログイン・モジュール」
タブを選択します。キーストアは、秘密鍵およびデジタル証明書のリポジトリです。
キーおよび証明書を持ち、アプリケーションのセキュア・サービスにそれらを使用する場合、JDeveloperでは、Java Key Store、Oracle Wallet (*.sso
または*.p12
ファイル)、またはPCKS12ファイル(*.p12
ファイル)をインポートできます。JDeveloperでは、キーストアを作成できません。
キー・ストアを追加する手順は、次のとおりです。
無名プロバイダとは、パブリック・ページの代替のことです。ここでは、未認証ユーザーにパブリック・ページ全体に対するアクセス権を許可するのではなく、よりきめの細かい権限を割り当てることができます。
無名プロバイダを有効にすることで、無名サービス・インスタンスと無名ログイン・モジュールを含む無名JpsContext
を作成できます。アプリケーション・ユーザーが未認証の場合は、実行時に無名資格証明が使用され、認証なしで一部のリソースへのアクセスが許可されます。
Webアプリケーションに対して無名プロバイダを有効にする手順は、次のとおりです。
jps-config.xml
ファイルをダブルクリックします。jps-config.xml
の概要エディタで「無名プロバイダ」タブを選択します。資格証明にはユーザーの認証パスワードが含まれます。資格証明は、デフォルトで不明瞭化されたフォームで表示されます。アイデンティティ・ストアに資格証明を追加する前に、最初にアイデンティティ・ストアのメンバー・ユーザーを定義する必要があります。
アイデンティティ・ストアで資格証明をユーザーに追加する手順は、次のとおりです。
jazn-data.xml
の概要エディタの「ユーザー」ページを開きます。ユーザーが保護されたWebアプリケーション領域を要求すると、宣言セキュリティでの認証が強制されます。ユーザーがこれまで認証されていない場合、コンテナはユーザーから資格証明を取得します。ユーザーはサーバー・セッション中、認証されたままです。
サポートされている認証タイプは、FORMベース認証、BASIC認証およびCLIENT-CERT認証です。認証タイプは、<login-config>
要素を使用してweb.xml
デプロイメント・ディスクリプタで指定されます。「認証タイプの選択肢について」を参照してください。
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セキュリティを有効にしたら、ユーザーにアクセス権を付与する必要があります。これによってユーザーは、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つのアプリケーション内に制約されてそのアクセシビリティが制限されますが、システム・ポリシー・ストアにはオープンにアクセスできます。
「ポリシーの管理」を参照してください。
プリンシパルとは、エンティティ(ユーザーまたはロール)に割り当てられたアイデンティティのことです。権限とは、エンティティのグループに対して許可された一連の操作で、エンティティはプリンシパルである場合もあります。付与またはカスタム・ポリシーには、権限およびプリンシパルが含まれます。JDeveloperでは、付与を作成せずにプリンシパルおよび権限を作成できません。
アプリケーション・ロールはアプリケーションに固有で、アプリケーション・ポリシー・ストアで定義されます。アプリケーション・ロールはアプリケーションで直接使用され(Java SEまたはJava EEアプリケーションで)、Java EEコンテナに認識される必要はありません。jazn-data.xml
ファイルのファイルベース・ポリシー・ストアでは、これらのアプリケーション・ロールは<policy-store>
の<app-role>
要素で定義され、デプロイ時にドメイン・レベルでsystem-jazn-data.xml
に書き込まれます。
アプリケーション・ポリシー・ストアにアプリケーション・ロールを追加する手順は、次のとおりです。
jazn-data.xml
ファイルの概要エディタの「アプリケーション・ロール」ページを開きます。jazn-data.xml
ファイルへの変更内容を保存します。デプロイメント・ユーザーおよびロールは、使用するセキュリティ・プロバイダで定義されます。ファイルベース・プロバイダの場合、デプロイメント・ユーザーおよびロールは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対応権限クラスを作成するには、次のようにします。
現在、このリリースには、システム権限付与をシステム・ポリシー・ストアに追加するためのエディタがありません。jazn-data.xml
のソース・コードで付与を手動で追加する必要があります。
システム・ポリシーへの付与を追加する手順は、次のとおりです。
jazn-data.xml
をダブルクリックして概要エディタを開きます。<jazn-data>
要素内に<jazn-policy>
要素を作成します。 <jazn-policy>
要素内で、目的のアプリケーション・ロールを持つ<grantee>
、権限クラスの完全修飾クラス名を持つ<permission>
、付与のターゲットとして使用する名前、およびアプリケーション・ロール・プリンシパルに付与するアクションを定義する<grant>
要素を作成します。jazn-data.xml
ファイルへの変更内容を保存します。JDeveloperのデフォルトの動作では、セキュリティ・オブジェクトは統合WebLogic Serverにデプロイされます。この動作を変更する方法について説明します。
JDeveloperはデフォルトで、アプリケーションを実行するたびにアプリケーション・リポジトリから統合WebLogic Serverにセキュリティ・オブジェクトをデプロイするよう構成されています。この動作は、「アプリケーション・プロパティ」ダイアログでのセキュリティ・デプロイメント・オプションの選択により、次のように変更できます。
ドメイン・レベル・ポリシーをアプリケーションのjazn-data.xml
ファイル内のポリシーにより上書きするかどうかを決定します。
システム資格証明をアプリケーションのcwallet.ssoファイルにより上書きするかどうかを決定します。
jazn-data.xml
ファイルのアイデンティティ・ストアの一部をドメイン・レベル・アイデンティティ・ストアに移行するかどうかを決定する。
デプロイ設定を変更しない場合、アプリケーションを実行するたびに、JDeveloperはドメイン・レベルのセキュリティ・ポリシーおよびシステム資格証明を上書きします。また、JDeveloperはテスト目的で作成した新しいユーザー・アイデンティティを移行し、統合WebLogic Serverがそのアイデンティティ・ストアで使用する埋込みLDAPサーバー内の既存のユーザー・パスワードを更新します。ただし、統合WebLogic Server内の既存のセキュリティ・オブジェクトを更新せずにアプリケーションを実行する場合には、このオプションを選択できます。
スタンドアロンOracle WebLogic Serverにアプリケーションをデプロイする準備ができている場合、同じ構成設定を使用して、JDeveloperでセキュリティ・オブジェクトの移行を処理する方法を制御できます。
セキュリティ・オブジェクトのデプロイを構成する手順は、次のとおりです。
Oracle WebLogic Server環境のサーバーにアプリケーションをデプロイする際、jazn-data.xml
で指定したアプリケーション・ポリシーをドメイン・ポリシー・ストアに移行できます。必要に応じて、アプリケーションがアンデプロイされる際、またはアプリケーションが再デプロイ時に更新される際に、ドメイン・ポリシー・ストアからポリシーを削除することもできます。
「アプリケーション・プロパティ」ダイアログで「アプリケーション・ポリシー」が選択されている場合、JDeveloperによるアプリケーションのデプロイ時、パッケージ化されたweblogic-application.xmlでjps.policystore.migration
プロパティはOVERWRITE
に設定されます。「アプリケーション・ポリシー」が選択されていない場合、jps.policystore.migration
の設定はパッケージ化されたweblogic-application.xml
に追加されず、すでに存在する場合には削除されます。これによりOracle WebLogic Serverではデフォルトの操作MERGE
が使用されます。ポリシーが存在しない場合、アプリケーションが初めてデプロイされるときのみマージによりポリシーが移行されます。アプリケーションのポリシーがすでに存在する場合、再移行は行われません。
アプリケーション・ポリシーの自動および手動による移行の詳細は、migrateSecurityStoreを使用したセキュリティ・ストアの移行に関する項を参照してください。
アプリケーション・ポリシーを移行する際、資格証明も移行する必要がある場合があります。WebLogic環境で管理されたサーバーにアプリケーションをデプロイまたは再デプロイする際に、cwallet.sso
で指定されたアプリケーションの資格証明をドメイン資格証明ストアに移行できます。したがって、資格証明の移行には、JDeveloper内で作成されたすべての接続(Webサービス用に作成された接続を含む)のパスワードが含まれます。(これは、 jazn-data.xml
ファイルのアイデンティティ・ストアで指定したユーザー資格証明には関連しません。アイデンティティ・ストアの移行の詳細は、次の「ユーザーおよびグループの移行」を参照してください)。
「アプリケーション・プロパティ」ダイアログで「資格証明」が選択されている場合、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
ファイル内のロールと同じ名前でグループがドメイン・ストア内に存在する場合、それは完全に置き換えられます。「ユーザーとグループ」が選択されていない場合、JDeveloperではアイデンティティ・ストアのjazn-data.xml
アプリケーションからの移行は試行されません。
注意:
ドメイン・アイデンティティ・ストアが上書きされないよう、ユーザーとグループを移行する前には、管理ロール(admin
)およびユーザー(weblogic
)がアプリケーションのjazn-data.xml
ファイル内で使用されていないことを確認してください。アプリケーションを本番環境にデプロイする準備ができたら、jazn-data.xm
l
ファイルからアイデンティティを削除するか、「アプリケーション・プロパティ」ダイアログで「ユーザーとグループ」の選択を解除して、アイデンティティの移行を無効にしてください。
JDBCを使用して、データベース接続を保護します。
JDeveloperでJDBCデータベース接続を作成すると、マシンにインストールされているデータベース・クライアントから暗号化プロパティが導出されます。JDBCを使用してセキュアな接続を作成するには、次のようにします。
クライアント・マシンのsqlnet.oraファイルでパラメータを設定し、OCIドライバによる暗号化サポートを構成します。
JDBCシン・ドライバを使用し、JDeveloperにセキュアなJDBC接続を作成します。「データベース接続の作成」ウィザードのステップ3 (「接続」ページ)で、「カスタムJDBC URLの入力」を選択し、次に示すように、暗号化パラメータをカスタムJDBC URLの一部として入力します。
jdbc:oracle:thin:@(description =(address=(protocol=tcp)(host=myhost)(port=1521))(connect_data= (sid=ORCL)(SQLNET.ENCRYPTION_CLIENT=REQUIRED)(SQLNET.ENCRYPTION_TYPES_ CLIENT=DES40)(SQLNET.CRYPTO_CHECKSUM_CLIENT=REQUESTED) (SQLNET.CRYPTO_CHECKSUM_TYPES_CLIENTMD5=MD5) ))