Oracle® Fusion Middleware

Oracle Platform Security Servicesによるアプリケーションの保護

12c (12.2.1)

E72537-01(原本部品番号:E61646-01)

2015年10月

Oracle Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護, 12c (12.2.1)

E72537-01

Copyright © 2003, 2015, Oracle and/or its affiliates.All rights reserved.

原本著者: Carlos Subi

原本協力著者:  Vinaye Misra

原本協力者: Amit Agarwal、Soumya Aithal、Moushmi Banerjee、William Cai、Deepika Damojipurapu、Pratik Datta、Jordan Douglas、Guru Dutt、Todd Elwood、Vineet Garg、Vikas Ghorpade、Sandeep Guggilam、Shiang-Jia Huang、Dan Hynes、Anant Kadam、Supriya Kalyanasundaram、Lakshmi Kethana、Rohit Koul、Chun Ma、Srivatsa Manjunath、Nithya Muralidharan、Frank Nimphius、Sudip Regmi、Bhupindra Singh、Kk Sriramadhesikan、Mamta Suri、Kavita Tippana、Ramana Turlapati、Yi Wang、Jane Xu、Sam Zhou

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、このソフトウェアまたはハードウェアを安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

このガイドで説明する新機能

- リリース12.2.1.0.0の新機能

- 2015年1月度12.1.3.0.0向けドキュメントの更新内容

- 2014年10月度12.1.3.0.0向けドキュメントの更新内容

- リリース12.1.3.0.0の新機能

- リリース12.1.2.0.0の新機能

第I部 セキュリティの概念の理解

1 Oracle Platform Security Servicesの概要

- 1.1 OPSSとは

- 1.1.1 OPSSの主な機能

- 1.1.2 サポートされているサーバー・プラットフォーム

- 1.2 OPSSのアーキテクチャの概要

- 1.2.1 OPSSの利点

- 1.3 開発者向けのOPSS

- 1.3.1 Java EEアプリケーションのセキュリティについて

- 1.3.2 Java SEアプリケーションのセキュリティについて

- 1.4 ADFのセキュリティの概要

- 1.4.1 Oracle ADFアプリケーション・セキュリティ

2 ユーザーおよびロールの理解

- 2.1 用語

- 2.2 ロール・マッピング

- 2.2.1 パーミッションの継承とロールの階層

- 2.2.1.1 ロール階層の例

- 2.3 ロール・カテゴリについて

- 2.4 認証ロールについて

- 2.5 匿名ユーザーとロールについて

- 2.6 管理ユーザーおよび管理ロールについて

- 2.7 ユーザー・アカウントの管理

3 アイデンティティ、ポリシー、資格証明、鍵、証明書および監査の理解

- 3.1 バージョン11gおよび12cの互換性の表

- 3.2 認証の基本

- 3.2.1 WebLogic認証プロバイダ

- 3.2.1.1 複数の認証プロバイダのサポート

- 3.2.1.2 その他の認証方式

- 3.2.2 アイデンティティ・ストア・タイプとWebLogic認証プロバイダ

- 3.3 ポリシーの基本

- 3.4 資格証明の基本

- 3.5 鍵および証明書の基本

- 3.6 監査の基本

4 セキュリティ・ストアについて

- 4.1 サポートされているファイル、LDAPおよびDBのストア

- 4.2 パッケージ要件

- 4.3 OPSSでのFIPSサポート

第II部 OPSSの基本的な管理

5 セキュリティ管理

- 5.1 OPSS管理: 主な手順

- 5.2 セキュリティ管理ツール

- 5.3 Fusion Middleware Controlを使用したセキュリティ・プラクティス

- 5.4 WebLogic Server管理コンソールを使用したセキュリティ・プラクティス

- 5.4.1 WLSTを使用したセキュリティ・プラクティス

- 5.5 OESを使用したセキュリティ・プラクティス

6 セキュア・アプリケーションのデプロイ

- 6.1 Oracle ADFアプリケーションの開発

- 6.2 デプロイのためのツールの選択

- 6.2.1 Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ

- 6.3 新しい環境へのOracle ADFアプリケーションのデプロイ

- 6.3.1 テスト環境へのデプロイ

- 6.3.1.1 デプロイ後の一般的な管理タスク

- 6.4 標準Java EEアプリケーションのデプロイ

- 6.5 監査対応アプリケーションのデプロイ

- 6.6 テスト環境から本番環境への移行

- 6.6.1 アイデンティティの移行

- 6.6.1.1 migrateSecurityStoreを使用したアイデンティティの移行

- 6.6.2 ポリシーおよび資格証明の移行

- 6.6.2.1 migrateSecurityStoreを使用したポリシーの移行

- 6.6.2.2 migrateSecurityStoreを使用した資格証明の移行

- 6.6.3 監査データの移行

- 6.6.4 migrateSecurityStoreを使用した鍵および証明書の移行

- 6.6.4.1 同じドメイン内での鍵および証明書の移行

- 6.6.4.2 異なるドメイン間での鍵および証明書の移行

第III部 OPSSサービス

7 セキュリティ・アーティファクトのライフ・サイクル

- 7.1 セキュリティ・アーティファクトのシード方法

- 7.2 Fusion Middlewareドメインについて

- 7.3 FMWドメインの作成

- 7.3.1 新しいデータベース・インスタンスの使用

- 7.3.2 データベース・インスタンスの共有

- 7.4 階層型コンポーネントのセキュリティ・アーティファクト

- 7.5 セキュリティの12.2.1へのアップグレード

- 7.5.1 セキュリティ・ストアをアップグレードする前に

- 7.5.2 Oracle Fusion Middlewareアップグレード・アシスタントを使用した準備状況のチェック

- 7.5.3 セキュリティのアップグレード: 主な手順

- 7.5.4 リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成

- 7.5.5 アップグレード・アシスタントを使用したスキーマのアップグレード

- 7.5.6 アップグレード・アシスタントを使用したスキーマのアップグレード

- 7.5.7 Fusion Middleware再構成ウィザードを使用したドメインの再構成

- 7.5.8 DBベースのセキュリティ・ストアのアップグレード

- 7.5.8.1 共有している12.1.2または12.1.3セキュリティ・ストアのアップグレード

- 7.5.8.2 共有している11gセキュリティ・ストアのアップグレード

- 7.6 セキュリティ・ストアのバックアップとリカバリ

- 7.6.1 DBセキュリティ・ストアのバックアップとリカバリ

- 7.6.2 LDAPセキュリティ・ストアのバックアップとリカバリ

- 7.6.3 推奨事項

- 7.7 コンポーネントの監査定義の12cへのアップグレード

8 アイデンティティ・ストアの構成

- 8.1 アイデンティティ・ストアについて

- 8.2 アイデンティティ・ストア・プロバイダの構成

- 8.3 アイデンティティ・ストアの構成

- 8.3.1 アイデンティティ・ストアのパラメータ

- 8.3.1.1 問合せパラメータ

- 8.3.1.2 グローバル接続パラメータ

- 8.3.1.3 バックエンド接続パラメータ

- 8.3.2 サービス構成の理解

- 8.3.2.1 単一のLDAP用のサービスの構成

- 8.3.2.2 仮想化を指定しない複数のLDAP用のサービスの構成

- 8.3.2.3 Fusion Middleware Controlを使用した複数のLDAP用のサービスの構成

- 8.3.2.4 WLSTを使用したサービスの構成

- 8.3.2.5 WLSTを使用したタイムアウト設定の構成

- 8.3.2.6 その他のパラメータの構成

- 8.3.2.7 サーバーの再起動

- 8.3.2.8 単一および複数のLDAPの構成

- 8.3.3 分割プロファイルの構成

- 8.3.4 カスタム認証プロバイダの構成

- 8.3.5 Java SEアプリケーションでの仮想化の構成

- 8.4 プログラムによるアイデンティティ・ストアの問合せ

- 8.5 アイデンティティ・ストア用のSSLの構成

9 セキュリティ・ストアの構成

- 9.1 セキュリティ・ストアについて

- 9.1.1 複数のサーバーがある環境

- 9.2 LDAPセキュリティ・ストアの使用

- 9.2.1 LDAPセキュリティ・ストアを使用する場合の前提条件

- 9.2.2 LDAPセキュリティ・ストアへの一方向SSLの設定

- 9.2.3 LDAPユーザー・パスワードのリセット

- 9.3 DBセキュリティ・ストアの使用

- 9.3.1 DBセキュリティ・ストアを使用する場合の前提条件

- 9.3.2 DBセキュリティ・ストアのメンテナンス

- 9.3.3 OPSSスキーマ・パスワードのリセット

- 9.3.4 DBセキュリティ・ストアへのSSL接続の設定

- 9.4 セキュリティ・ストアの再関連付け

- 9.4.1 Fusion Middleware Controlを使用したセキュリティ・ストアの再関連付け

- 9.4.1.1 LDAPノードへのアクセスの保護

- 9.4.2 reassociateSecurityStoreを使用したセキュリティ・ストアの再関連付け

- 9.5 セキュリティ・ストアの移行

- 9.5.1 Fusion Middleware Controlを使用したセキュリティ・ストアの移行

- 9.5.2 migrateSecurityStoreを使用したセキュリティ・ストアの移行

- 9.5.2.1 migrateSecurityStoreを使用したすべてのポリシーの移行

- 9.5.2.2 migrateSecurityStoreを使用したシステム・ポリシーの移行

- 9.5.2.3 migrateSecurityStoreを使用したアプリケーション・ポリシーの移行

- 9.5.2.4 migrateSecurityStoreを使用したすべての資格証明の移行

- 9.5.2.5 migrateSecurityStoreを使用した1つの資格証明マップの移行

- 9.5.2.6 migrateSecurityStoreを使用した監査データの移行

- 9.5.2.7 migrateSecurityStoreの使用例

- 9.6 Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成

10 ポリシーの管理

- 10.1 セキュリティ・ストアの特性の確認

- 10.2 ポリシー・ストアの管理

- 10.3 Fusion Middleware Controlを使用したポリシーの管理

- 10.3.1 アプリケーション・ポリシーの管理

- 10.3.2 アプリケーション・ロールの管理

- 10.3.3 システム・ポリシーの管理

- 10.4 WLSTを使用したポリシーの管理

- 10.4.1 reassociateSecurityStore

- 10.5 ポリシー・キャッシュのリフレッシュ

- 10.5.1 ポリシー・リフレッシュを使用した認可のシナリオ

- 10.6 WLSTコマンドにおけるプリンシパルとロール

- 10.7 WLSTコマンドにおけるアプリケーション・ストライプ

- 10.8 OESを使用したアプリケーション・ポリシーの管理

11 資格証明の管理

- 11.1 資格証明のタイプ

- 11.2 資格証明の暗号化

- 11.3 Fusion Middleware Controlを使用した資格証明の管理

- 11.4 WLSTを使用した資格証明の管理

12 鍵と証明書の管理

- 12.1 キーストア・サービスについて

- 12.1.1 キーストア・サービスの構造

- 12.1.2 キーストアのタイプ

- 12.1.3 トラストストア

- 12.2 Fusion Middleware Controlを使用したキーストアの管理

- 12.3 WLSTを使用したキーストアの管理

- 12.4 証明書について

- 12.5 Fusion Middleware Controlを使用した証明書の管理

- 12.6 WLSTを使用した証明書の管理

- 12.7 サードパーティのCA署名証明書の使用

- 12.8 Fusion Middlewareコンポーネントでのキーストア・サービスの使用方法

- 12.8.1 syncKeyStoresコマンドの使用

- 12.8.1.1 syncKeyStoresの使用方法

- 12.8.1.2 syncKeyStoresコマンドを使用するタイミング

- 12.9 キーストア・サービス・コマンドについて

- 12.9.1 キーストア・サービス・コマンドのヘルプの表示

- 12.9.2 キーストア・サービス・コマンド・リファレンス

- 12.10 キーストア・サービスでのSSLの構成

- 12.10.1 複数のLDAPとキーストアへの一方向SSLの設定

- 12.10.2 複数のLDAPとキーストアへの双方向SSLの設定

- 12.10.3 JKSからKSSへの切替え

- 12.11 LDAPとJKS間のSSLの設定

- 12.11.1 LDAPとJKS間の一方向SSLの設定

- 12.11.2 LDAPとJKS間の双方向SSLの設定

13 Oracle Fusion Middleware監査フレームワークの概要

- 13.1 監査の目的

- 13.2 監査の用語

- 13.3 OFM監査フレームワークを使用した監査について

- 13.3.1 OFM監査フレームワークの概要

- 13.3.2 コンポーネントとアプリケーションについて

- 13.4 監査の理解

- 13.4.1 監査モデル

- 13.4.2 監査ストアについて

- 13.4.3 監査データの格納方法

- 13.4.4 OFM監査フレームワークについて

- 13.4.5 監査の設定: 主な手順

- 13.4.6 実行時監査イベント・フローの理解

- 13.5 監査の属性、イベントおよびイベント・カテゴリについて

- 13.5.1 監査属性グループ

- 13.5.1.1 汎用属性グループについて

- 13.5.1.2 カスタム属性グループについて

- 13.5.1.3 監査属性のデータ型について

- 13.5.2 監査イベントとイベント・カテゴリ

- 13.5.2.1 システム・カテゴリとイベントについて

- 13.5.2.2 コンポーネントとアプリケーション・カテゴリについて

- 13.5.3 監査アーティファクトのネーミング要件

- 13.6 監査定義ファイルについて

- 13.6.1 component_events.xmlファイルについて

- 13.7 マッピングとバージョン・ルールについて

- 13.7.1 バージョン番号とは

- 13.7.2 カスタム属性からデータベース列へのマッピングについて

14 監査の管理

- 14.1 監査管理タスク

- 14.2 監査ストアの管理

- 14.2.1 監査データ・ソースについて

- 14.2.2 バスストップ・ファイルの管理

- 14.2.3 スタンドアロン監査ローダーの構成

- 14.2.3.1 環境の構成

- 14.2.3.2 スタンドアロン監査ローダーの実行

- 14.3 監査ポリシーの管理

- 14.3.1 Fusion Middleware Controlを使用した監査ポリシーの管理

- 14.3.2 WLSTを使用した監査ポリシーの管理

- 14.3.2.1 WLSTコマンドを使用した監査ポリシーの表示

- 14.3.2.2 WLSTコマンドを使用した監査ポリシーの更新

- 14.3.2.3 監査ポリシーの構成例

- 14.3.2.4 監査イベントの構成例

- 14.3.2.5 監査レベルを変更するとカスタム構成はどうなるか

- 14.3.3 プログラムによる監査ポリシーの管理

- 14.4 監査のタイムスタンプの理解

- 14.5 監査ログとバスストップ・ファイルについて

- 14.6 監査データベースの管理

- 14.6.1 監査スキーマの概要

- 14.6.2 実表およびコンポーネント表の属性

- 14.6.3 パフォーマンスのチューニング

- 14.6.4 バックアップとリカバリのプランニング

- 14.6.5 データのインポートとエクスポート

- 14.6.6 データのパージ

- 14.6.7 パーティション化

- 14.6.8 階層アーカイブの実行

- 14.6.9 マテリアライズド・ビューを使用したカスタム表属性に対する索引の作成

- 14.7 監査イベント定義のベスト・プラクティス

- 14.7.1 イベントのネーミングのガイドライン

- 14.7.2 イベントの区別

- 14.7.3 イベントの分類

- 14.7.4 汎用属性の使用

- 14.7.5 コンポーネント属性の使用

- 14.7.6 コンポーネント間のリンクのガイドライン

- 14.7.7 イベント定義の更新

15 監査分析と監査レポートの使用

- 15.1 監査レポートについて

- 15.2 動的メタデータ・モデルを使用した監査レポート

- 15.2.1 登録時に作成される監査ビュー

- 15.2.2 手動で作成される監査ビュー

第IV部 OPSS APIを使用した開発

16 アプリケーション・セキュリティのOPSSとの統合

- 16.1 セキュリティの課題について

- 16.2 セキュリティ統合ユースケース

- 16.2.1 認証

- 16.2.1.1 認証されたユーザーが必要なJava EEアプリケーション

- 16.2.1.2 プログラム認証が必要なJava EEアプリケーション

- 16.2.1.3 認証が必要なJava SEアプリケーション

- 16.2.2 アイデンティティ

- 16.2.2.1 2つの環境で実行されるアプリケーション

- 16.2.2.2 複数のストア内のユーザー・プロファイルにアクセスするアプリケーション

- 16.2.3 認可

- 16.2.3.1 特定のロールのみアクセス可能なJava EEアプリケーション

- 16.2.3.2 ファイングレイン認可が必要なOracle ADFアプリケーション

- 16.2.3.3 Webサービスを保護するアプリケーション

- 16.2.3.4 コードソース・パーミッションが必要なJava EEアプリケーション

- 16.2.3.5 ファイングレイン認可が必要な非Oracle ADFアプリケーション

- 16.2.4 資格証明

- 16.2.4.1 システムへのアクセスに資格証明が必要なアプリケーション

- 16.2.5 監査

- 16.2.5.1 セキュリティ関連アクティビティの監査

- 16.2.5.2 ビジネス関連アクティビティの監査

- 16.2.6 アイデンティティ伝播

- 16.2.6.1 実行ユーザー・アイデンティティの伝播

- 16.2.6.2 ユーザー・アイデンティティの伝播

- 16.2.6.3 別のドメインへのアイデンティティの伝播

- 16.2.6.4 HTTPを介したアイデンティティの伝播

- 16.2.7 管理

- 16.2.7.1 集中管理されたストアが必要なアプリケーション

- 16.2.7.2 カスタム管理ツールが必要なアプリケーション

- 16.2.7.3 複数のサーバー環境で実行されるアプリケーション

- 16.2.8 統合

- 16.3 OPSSトラスト・サービス

- 16.4 HTTPを介したアイデンティティの伝播

- 16.5 OPSSトラスト・サービスを使用したアイデンティティの伝播

- 16.5.1 複数のWebLogic Serverドメイン間でのアイデンティティの伝播

- 16.5.1.1 クライアント側ドメインでのトークン生成

- 16.5.1.2 サーバー側つまりトークン検証ドメイン

- 16.5.2 単一のWebLogic Serverドメイン内のコンテナ間でのアイデンティティの伝播

- 16.5.3 トラスト・プロバイダのプロパティ

- 16.6 カスタム・グラフィカル・ユーザー・インタフェースの実装

- 16.6.1 前提とするインポート

- 16.6.2 アイデンティティ・ストアの問合せの例

- 16.6.3 ロールの作成の例

- 16.6.4 ロールの問合せの例

- 16.6.5 ロールのマッピングの例

- 16.6.6 ユーザーが含まれるロールの取得の例

- 16.6.7 ロール・マッピングの削除の例

- 16.7 Oracle ADFアプリケーションの保護

- 16.7.1 開発フェーズ

- 16.7.2 デプロイメント・フェーズ

- 16.7.3 管理フェーズ

- 16.7.4 各フェーズの担当者別タスクの概要

- 16.8 コードおよび構成例

- 16.8.1 プログラミング例

- 16.8.2 構成例

- 16.9 JKSを使用したアイデンティティの伝播

- 16.9.1 単一ドメイン・シナリオ

- 16.9.1.1 クライアント・アプリケーションの作成

- 16.9.1.2 キーストアの構成

- 16.9.1.3 マップおよびキーの構成

- 16.9.1.4 権限付与の構成

- 16.9.1.5 Javaサーブレットの作成

- 16.9.1.6 web.xmlの構成

- 16.9.1.7 アサータの構成

- 16.9.1.8 トラスト・パラメータの更新

- 16.9.2 複数ドメイン・シナリオ

- 16.9.3 両方のプロトコルを使用するドメイン

- 16.9.3.1 単一ドメイン・シナリオ

- 16.9.3.2 複数ドメイン・シナリオ

17 セキュリティ・モデル

- 17.1 OPSSの認可モデルおよびポリシー・モデルについて

- 17.2 認可モデル

- 17.2.1 Java EE認可モデル

- 17.2.1.1 宣言による認可

- 17.2.1.2 プログラムによる認可

- 17.2.1.3 Java EEアプリケーションの例

- 17.2.2 JAAS認可モデル

- 17.3 JAAS/OPSS認可モデル

- 17.3.1 リソース・カタログ

- 17.3.2 ポリシーの管理

- 17.3.3 プログラムによるポリシーのチェック

- 17.3.3.1 checkPermissionの使用

- 17.3.3.2 doAsおよびdoAsPrivilegedの使用

- 17.3.3.3 checkBulkAuthorizationの使用

- 17.3.3.4 getGrantedResourcesの使用

- 17.3.4 クラスResourcePermission

18 資格証明ストア・フレームワークを使用した開発

- 18.1 資格証明ストア・フレームワークAPIについて

- 18.2 資格証明ストア・フレームワークAPIの使用のガイドライン

- 18.3 マップとキー名について

- 18.4 アクセス・パーミッションのプロビジョニング

- 18.4.1 1つのキーにアクセスするためのパーミッションの例

- 18.4.2 マップにアクセスするためのパーミッションの例

- 18.5 資格証明ストア・フレームワークAPIの使用

- 18.5.1 Java SEアプリケーションでの資格証明ストア・フレームワークAPIの使用

- 18.5.2 Java EEアプリケーションでの資格証明ストア・フレームワークAPIの使用

- 18.6 資格証明ストア・フレームワークAPIの例

- 18.6.1 資格証明ストア・フレームワーク操作の例

- 18.6.2 ファイル資格証明を使用するJava SEアプリケーションの例

- 18.6.3 ファイル資格証明を使用するJava EEアプリケーションの例

- 18.6.4LDAPストアを使用するJava EEアプリケーションの例

- 18.6.5 DBストアを使用するJava EEアプリケーションの例

19 ユーザーおよびロールAPIを使用した開発

- 19.1 ユーザーおよびロールAPIについて

- 19.1.1 認証プロバイダとユーザーおよびロールAPI

- 19.2 サービス・プロバイダの操作

- 19.2.1 環境の設定

- 19.2.2 プロバイダ・リポジトリの選択

- 19.2.3 プロバイダ・インスタンスの作成

- 19.2.4 プロバイダの起動時および実行時のプロパティの構成

- 19.2.4.1 起動時と実行時の構成

- 19.2.4.2 実行コンテキストIDの有効化

- 19.2.5 ファクトリ・インスタンス作成時のプロバイダの構成

- 19.2.5.1 共通プロパティの構成

- 19.2.5.2 定数、接続数およびプール接続の構成

- 19.2.6 ストア・インスタンス作成時のプロバイダの構成

- 19.2.7 実行時のプロバイダの構成

- 19.2.8 プログラミングのガイドライン

- 19.2.8.1 プロバイダの切替え

- 19.2.8.2 アイデンティティ・ストア・オブジェクトの使用

- 19.2.9 プロバイダの存続期間

- 19.3 アイデンティティ・ストアの検索

- 19.3.1 特定のアイデンティティの検索

- 19.3.2 複数のアイデンティティの検索

- 19.3.3 検索フィルタの使用

- 19.3.3.1 フィルタ演算子

- 19.3.3.2 ログイン・ユーザーおよびロール用のフィルタ

- 19.3.3.3 フィルタの例

- 19.4 アイデンティティ・ストアのエントリの作成と変更

- 19.4.1 アイデンティティとロールの作成

- 19.4.2 アイデンティティの変更

- 19.4.3 アイデンティティの削除

- 19.5 ユーザーおよびロールAPIの例

- 19.5.1 ユーザーの検索の例

- 19.5.2 ユーザーの管理の例

- 19.6 LDAPプロバイダ用のSSLの構成

- 19.6.1 プロバイダに対するSSLの設定

- 19.6.2 プロバイダに対するSSLのカスタマイズ

20 Identity Governance Frameworkを使用した開発

- 20.1 Identity Governance Frameworkについて

- 20.1.1 アイデンティティ・ディレクトリAPIの概要

- 20.2 アイデンティティ・ディレクトリAPIの構成について

- 20.3 アイデンティティ・ディレクトリAPIの使用

- 20.3.1 アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- 20.3.2 ユーザーの作成と削除

- 20.3.3 ユーザーの取得と変更

- 20.3.4 ユーザーの簡易検索と複合検索

- 20.3.5 グループの作成と削除

- 20.3.6 グループの取得

- 20.3.7 グループ検索フィルタ

- 20.3.8 グループに対するメンバーの追加と削除

- 20.4 アイデンティティ・ディレクトリAPIを使用したSSLの構成

21 キーストア・サービスを使用した開発

- 21.1 キーストア・サービスAPIについて

- 21.2 ポリシー・パーミッションの設定

- 21.2.1 キーストアのパーミッションの例

- 21.2.2 マップのパーミッションの例

- 21.2.3 鍵の別名のパーミッションの例

- 21.3 Java EEアプリケーションでのキーストア・サービスAPIの使用

- 21.4 Java SEアプリケーションでのキーストア・サービスAPIの使用

- 21.5 キーストア・サービスAPIの例

- 21.5.1 キーストア・サービス管理の例

- 21.5.2 実行時のキーの読取りの例

- 21.5.2.1 キーストアへのハンドルの取得

- 21.5.2.2 キーストア・アーティファクトのアクセス - メソッド1

- 21.5.2.3 キーストア・アーティファクトのアクセス - メソッド2

22 Oracle Fusion Middleware監査フレームワークを使用した開発

- 22.1 アプリケーションとOFM監査フレームワークの統合

- 22.2 監査定義ファイルの作成

- 22.2.1 component-events.xmlファイル

- 22.2.2 翻訳ファイル

- 22.3 サービスへのアプリケーションの登録

- 22.3.1 宣言による監査登録の実行

- 22.3.1.1 アプリケーション監査登録

- 22.3.1.2 カスタム監査登録

- 22.3.2 プログラム登録

- 22.3.3 WLSTコマンドを使用した登録

- 22.3.4 監査アーティファクト用ドメイン拡張テンプレートの使用

- 22.4 プログラムによるポリシーの管理

- 22.4.1 監査データの問合せ

- 22.4.2 監査ポリシーの表示と設定

- 22.5 プログラムによる監査イベントのロギング

- 22.5.1 OFM監査フレームワークのインタフェース

- 22.5.2 システム権限の設定

- 22.5.3 監査インスタンスの取得

- 22.6 監査定義の更新と保守

23 OPSSを使用するためのJava EEアプリケーションの構成

- 23.1 Java EEアプリケーションでの認証について

- 23.2 Java EEアプリケーションでの認証の開発

- 23.3 フィルタおよびインターセプタの構成

- 23.3.1 アプリケーション・ストライプの設定

- 23.3.2 アプリケーション・ロールのサポートの設定

- 23.3.3 匿名ユーザーとロールの設定

- 23.3.4 認証ロールのサポートの設定

- 23.3.5 JAASモードの設定

- 23.3.6 インターセプタ構成要件

- 23.3.7 フィルタおよびインターセプタ・パラメータの概要

- 23.4 エンタープライズ・グループとエンタープライズ・ユーザーに適したクラスの選択

- 23.5 Java EEアプリケーションの手動によるパッケージ化

- 23.5.1 アプリケーションとのポリシーのパッケージ化

- 23.5.2 アプリケーションとの資格証明のパッケージ化

- 23.6 OPSSを使用するためのJava EEアプリケーションの構成

- 23.6.1 ポリシーの移行の制御

- 23.6.1.1 jps.policystore.migration

- 23.6.1.2 jps.policystore.applicationid

- 23.6.1.3 jps.apppolicy.idstoreartifact.migration

- 23.6.1.4 jps.policystore.removal

- 23.6.1.5 jps.policystore.migration.validate.principal

- 23.6.1.6 JpsApplicationLifecycleListener

- 23.6.2 動作に応じたポリシーの移行の構成

- 23.6.2.1 推奨事項

- 23.6.2.2 ポリシーの移行のスキップ

- 23.6.2.3 マージによるポリシーの移行

- 23.6.2.4 上書きによるポリシーの移行

- 23.6.2.5 ポリシーを削除または削除しない

- 23.6.2.6 静的デプロイメントでのポリシーの移行

- 23.6.3 ファイル資格証明ストアの使用

- 23.6.4 資格証明の移行の制御

- 23.6.4.1 jps.credstore.migration

- 23.6.5 動作に応じた資格証明の移行の構成

- 23.6.5.1 資格証明の移行のスキップ

- 23.6.5.2 マージによる資格証明の移行

- 23.6.5.3 上書きによる資格証明の移行

- 23.6.6 サポートされているパーミッション・クラスの使用

- 23.6.6.1 セキュリティ・ストアのパーミッション・クラス

- 23.6.6.2 資格証明ストアのパーミッション・クラス

- 23.6.6.3 汎用パーミッション・クラス

- 23.6.7 ブートストラップ資格証明の手動による指定

24 OPSSを使用するためのJava SEアプリケーションの構成

- 24.1 Java SEアプリケーションでのOPSSの使用

- 24.1.1 JpsStartupクラス

- 24.1.1.1 JpsStartup.start状態

- 24.1.1.2 JpsStartupのコンストラクタ

- 24.1.1.3 JpsStartupのランタイム・オプション

- 24.1.1.4 OPSS起動例

- 24.2 Java SEアプリケーションでのセキュリティ・サービスの実装

- 24.3 Java SEアプリケーションでの認証

- 24.3.1 Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成

- 24.3.2 Javaアプリケーションでのログイン・モジュールの使用

- 24.3.2.1 ユーザー認証のログイン・モジュール

- 24.3.2.2 ユーザー・アサーションのログイン・モジュール

- 24.3.2.3 アイデンティティ・ストアのログイン・モジュール

- 24.3.2.4 アサートされたユーザー

- 24.3.3 Java SEアプリケーションでのログイン・モジュールの使用

- 24.4 Java SEアプリケーションでの認可

- 24.4.1 ポリシーおよび資格証明のファイル・ストアの構成

- 24.4.2 ポリシーおよび資格証明のLDAPストアの構成

- 24.4.3 DBセキュリティ・ストアの構成

- 24.4.4 ファイル・ストアでサポートされていないメソッド

- 24.5 Java SEアプリケーションでの監査

- 24.5.1 Java SEアプリケーションでの監査について

- 24.5.2 監査のバスストップ・ディレクトリの構成

- 24.5.3 監査ローダーの構成

- 24.5.4 Java SEアプリケーションでの一般的な監査シナリオ

- 24.5.4.1 WebLogic Serverが一緒に配置されている場合の監査

- 24.5.4.2 WebLogic Serverが一緒に配置されていない場合の監査

第V部 付録

A OPSS構成ファイル・リファレンス

- A.1 第1および第2階層レベル

- A.2 第3階層以下のレベル

- <description>

- <extendedProperty>

- <extendedPropertySet>

- <extendedPropertySetRef>

- <extendedPropertySets>

- <jpsConfig>

- <jpsContext>

- <jpsContexts>

- <name>

- <property>

- <propertySet>

- <propertySetRef>

- <propertySets>

- <serviceInstance>

- <serviceInstanceRef>

- <serviceInstances>

- <serviceProvider>

- <serviceProviders>

- <value>

- <values>

B ファイル・ストアのリファレンス

- B.1 ファイル・ストアの階層

- B.2 ファイル・ストアの要素と属性

- <actions>

- <actions-delimiter>

- <app-role>

- <app-roles>

- <application>

- <applications>

- <attribute>

- <class>

- <codesource>

- <credentials>

- <description>

- <display-name>

- <extended-attributes>

- <grant>

- <grantee>

- <guid>

- <jazn-data>

- <jazn-policy>

- <jazn-realm>

- <matcher-class>

- <member>

- <member-resource>

- <member-resources>

- <members>

- <name>

- <owner>

- <owners>

- <permission>

- <permissions>

- <permission-set>

- <permission-sets>

- <policy-store>

- <principal>

- <principals>

- <provider-name>

- <realm>

- <resource>

- <resources>

- <resource-name>

- <resource-type>

- <resource-types>

- <role>

- <role-categories>

- <role-category>

- <role-name-ref>

- <roles>

- <type>

- <type-name-ref>

- <uniquename>

- <url>

- <user>

- <users>

- <value>

- <values>

C Oracle Fusion Middleware監査フレームワーク・リファレンス

- C.1 監査イベント

- C.1.1 監査可能なコンポーネント

- C.1.2 システム・カテゴリとイベント

- C.1.3 OPSSイベントの属性

- C.2 監査スキーマ

- C.3 監査フィルタ式の構文

- C.4 監査ファイルのネーミングおよびロギング

D ユーザー/ロールAPIリファレンス

- D.1 LDAPディレクトリへのユーザー属性のマッピング

- D.2 LDAPディレクトリへのロール属性のマッピング

- D.3 デフォルトの構成パラメータ

E スクリプトおよびMBeanを使用した管理

- E.1 スクリプトを使用したサービスの構成

- E.2 MBeanを使用したサービスの構成

- E.2.1 サポートされるOPSS MBean

- E.2.2 OPSS MBeanの使用

- E.2.3 OPSS MBeansを使用したプログラミング

- E.3 MBeanへのアクセスの制限

- E.3.1 注釈の例

- E.3.2 エンタープライズ・グループへの論理ロールのマッピング

- E.3.3 特定のアクセス制限

F OPSSのシステムおよび構成プロパティ

- F.1 OPSSシステム・プロパティ

- F.2 OPSS構成プロパティ

- F.2.1 OPSSサービスに共通するプロパティ

- F.2.2 ポリシー・サービスのプロパティ

- F.2.2.1 ポリシー・サービスの構成

- F.2.2.2 実行時ポリシーの構成

- F.2.3 資格証明サービスのプロパティ

- F.2.4 LDAPアイデンティティのプロパティ

- F.2.5 すべてのLDAPサーバーに共通するプロパティ

- F.2.6 トラスト・サービスのプロパティ

- F.2.7 監査サービスのプロパティ

- F.2.8 キーストア・サービスのプロパティ

- F.2.9 匿名ロールと認証ロールのプロパティ

G OPSS APIリファレンス

- G.1 OPSS APIリファレンス

H OpenLDAPアイデンティティ・ストアの使用

- H.1 OpenLDAPアイデンティティ・ストアの使用

I ID仮想化のためのアダプタ構成

- I.1 分割プロファイルについて

- I.2 分割プロファイルの構成

- I.3 分割プロファイルの実装

- I.4 Identity Virtualization Libraryのロギング

J OPSSのトラブルシューティング

- J.1 OPSS診断フレームワーク

- J.2 セキュリティ・エラーの診断

- J.2.1 OPSSロガーについて

- J.2.1.1 診断ログ・ファイル

- J.2.1.2 オフラインWLSTロガー

- J.2.2 サービス別のロガー

- J.2.2.1 認可のロギング

- J.2.2.2 監査のロギング

- J.2.2.3 ユーザーおよびロールAPIのロギング

- J.2.2.4 その他のコンポーネントのロギング

- J.2.3 システム・プロパティ

- J.2.4 ログ・エントリの理解

- J.3 再関連付けおよび移行のトラブルシューティング

- J.3.1 再関連付けの失敗

- J.3.2 サポートされていないスキーマ

- J.3.3 再関連付けしたセキュリティ・ストアのポリシーの欠落

- J.3.4 移行の失敗

- J.4 サーバーの起動のトラブルシューティング

- J.4.1 必須のLDAP認証プロバイダの欠落

- J.4.2 管理者アカウントの欠落

- J.4.3 パーミッションの欠落

- J.4.4 サーバーの起動の失敗

- J.4.5 サーバーの起動に関するその他の問題

- J.4.6 サーバーの起動前のパーミッション・チェックの失敗

- J.5 パーミッションのトラブルシューティング

- J.5.1 システム・ポリシー障害のトラブルシューティング

- J.5.2 パーミッションの取得の失敗 - 大文字と小文字の不一致

- J.5.3 認可チェックの失敗

- J.5.4 ユーザーによる予期しないパーミッションの取得

- J.5.5 Java SEアプリケーションにおけるパーミッションの付与

- J.5.6 12c HAドメインで認識されないアプリケーション・ポリシー

- J.6 接続およびアクセスのトラブルシューティング

- J.6.1 JNDI接続例外

- J.6.2 組込みLDAPサーバーへの接続の失敗

- J.6.3 LDAPサーバーへの接続の失敗

- J.6.4 資格証明ストアのデータへのアクセスの失敗

- J.6.5 セキュリティ・アクセス制御の例外

- J.6.6 匿名SSL接続の確立の失敗

- J.7 Oracle Business Intelligence Publisherのタイムゾーン

- J.8 検索のトラブルシューティング

- J.8.1 セキュリティ・ストアでの属性照合時の検索の失敗

- J.8.2 不明なホスト例外による検索の失敗

- J.9 バージョンのトラブルシューティング

- J.9.1 バイナリとセキュリティ・ストアのバージョンの非互換性

- J.9.2 セキュリティ・ストアのバージョンの非互換性

- J.10 その他のエラーのトラブルシューティング

- J.10.1 実行時のパーミッション・チェックの失敗

- J.10.2 サイズ変更の必要な表領域

- J.10.3 Oracle Internet Directoryの例外

- J.10.4 ユーザーおよびロールAPIの失敗

- J.10.5 ポリシーに使用する文字

- J.10.5.1 Oracle Internet Directory 10.1.4.3に使用する特殊文字

- J.10.5.2 ファイル・セキュリティ・ストアに使用する文字

- J.10.5.3 アプリケーション・ロール名に使用する文字

- J.10.5.4 ファイル・ストアでの改行文字の欠落

- J.10.6 無効な鍵サイズ

- J.11 追加のヘルプ

図一覧

- 1-1 OPSSアーキテクチャ

- 16-1 アプリケーション、セキュリティ・ストアおよび管理ツール

- 16-2 HTTPを介したアイデンティティ伝播

- 16-3 アプリケーション・ロールからユーザーとグループへのマッピング

- 16-4 アプリケーション・ライフ・サイクルのフェーズ

表一覧

- 2-1 付与されるパーミッションと継承されるパーミッション

- 3-1 アイデンティティ・ストア・タイプと認証プロバイダ

- 6-1 Java EEアプリケーションをデプロイするためのツール

- 7-1 OPSSによって使用される、コンポーネント・テンプレートのファイル

- 7-2 12.1.2または12.1.3から12.2.1へのアップグレード

- 7-3 11.1.1.6、11.1.1.7または11.1.1.9から12.2.1からのアップグレード

- 8-1 LDAPアイデンティティ・ストアのグローバル・パラメータ

- 12-1 JKSによるSSL

- 13-1 監査属性のデータ型

- 16-1 アプリケーション設計者のセキュリティ・タスク

- 16-2 アプリケーション開発者のセキュリティ・タスク

- 16-3 アプリケーション・セキュリティ管理者のセキュリティ・タスク

- 17-1 Java EEモデルの認可の比較

- 17-2 JAASモードに応じたcheckPermissionの動作

- 19-1 リポジトリとプロバイダ・クラス

- 19-2 起動時のアイデンティティ・プロバイダ・プロパティ

- 19-3 実行時のアイデンティティ・プロバイダ・プロパティ

- 22-1 監査登録のパラメータ

- 23-1 JpsFilterおよびJpsInterceptorのパラメータ

- 23-2 ポリシーの移行をスキップするための設定

- 23-3 ポリシーをマージして移行するための設定

- 23-4 上書きによりポリシーを移行するための設定

- 23-5 ポリシーを削除するための設定

- 23-6 ポリシーの削除を無効にするための設定

- 23-7 静的デプロイメントでポリシーを移行するための設定

- 23-8 静的デプロイメントでポリシーを移行しないための設定

- 23-9 資格証明の移行をスキップするための設定

- 23-10 マージにより資格証明を移行するための設定

- 23-11 上書きにより資格証明を移行するための設定

- 24-1 JpsStartupのランタイム・オプション

- A-1 jps-config.xmlのトップレベルと第2レベルの要素

- A-2 <property>のシナリオ

- B-1 system-jazn-data.xmlおよびjanz-data.xmlの要素の階層

- C-1 システム・カテゴリとイベント

- C-2 コアOPSSのイベント

- C-3 アイデンティティ・ガバナンス・サービスのイベント

- C-4 Identity Virtualization Libraryのイベント

- C-5 監査イベントの属性

- C-6 監査スキーマ

- C-7 追加の監査スキーマ表

- D-1 ディレクトリ・サーバーのユーザー属性

- D-2 ディレクトリ・サーバーのロール属性

- D-3 Oracle Internet DirectoryおよびMicrosoft Active Directoryのパラメータ

- D-4 Directory Server Enterprise EditionおよびNovell eDirectoryのパラメータ

- D-5 OpenLDAPおよびOracle Virtual Directoryのパラメータ

- D-6 組込みLDAPのパラメータ

- E-1 OPSS MBeansのリスト

- E-2 WebLogicグループへの論理ロールのマッピング

- E-3 操作別に必要なロール

- F-1 OPSSシステム・プロパティ

- F-2 共通プロパティ

- F-3 ポリシーのプロパティ

- F-4 実行時ポリシーのプロパティ

- F-5 資格証明ストアのプロパティ

- F-6 LDAPアイデンティティ・ストアのプロパティ

- F-7 LDAPの汎用的なプロパティ

- F-8 トラストストアのプロパティ

- F-9 監査のプロパティ

- F-10 キーストア・サービスのプロパティ

- F-11 匿名ロールと認証ロールのプロパティ

- J-1 監査診断のログ・ファイル

はじめに

このマニュアルでは、Oracle Platform Security Services (OPSS)の機能と管理について説明します。

対象読者

このガイドは、OPSSを理解して使用したいと考えている熟練したJava開発者、ドメイン管理者、デプロイ担当者およびアプリケーション・マネージャを対象としています。

このガイドは複数の部で構成されており、それぞれに関連する主要なトピックがまとめられています。第I部から第III部まではセキュリティ管理者向けの内容です。第IV部には開発者を対象としたポリシー・モデルに関する情報、第V部にはリファレンス情報がそれぞれ記載されています。

ドキュメントのアクセシビリティについて

オラクル社のアクセシビリティへの取組みの詳細は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細は、http://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoまたはhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs (聴覚障害者向け)を参照してください。

関連ドキュメント

追加情報は、次のドキュメントを参照してください。

- Oracle Fusion Middlewareの管理

- Oracle Fusion Middleware 2日で管理者ガイド

- Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理

- Oracle Fusion Middleware Oracle Internet Directory管理者ガイド

- Oracle Fusion Middleware Oracle Directory Integration Platform管理者ガイド

- Oracle Fusion Middleware Oracle Identity Federation管理者ガイド

- Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

- Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド

- WebLogic Scripting Toolの理解

- Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス

- Repository Creation Utilityを使用したスキーマの作成

- APIドキュメントへのリンクについては、第G.1項「OPSS APIリファレンス」を参照してください。

Oracleドキュメントの包括的なリストを参照する場合や、Oracleドキュメント・ライブラリ内で特定のトピックを検索する場合は、http://www.oracle.com/technetwork/indexes/documentation/index.htmlを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するグラフィカル・ユーザー・インタフェース要素を示します。

イタリック

イタリックは、特定の値を指定するプレースホルダ変数を示します。

モノスペース

パラグラフ内の固定幅フォントは、コマンド、URL、Javaクラス名とメソッド名、ファイル名とディレクトリ名、画面に表示されるテキスト、または入力するテキストを示します

このガイドで説明する新機能

この章では、このリリースと前の12cリリースで導入された主要な変更についてまとめます。

リリース12.2.1.0.0の新機能

リリース12.1.3.0.0で導入された新機能および主な変更は次のとおりです。

- IBM DB2データベースおよびMicrosoft SQLサーバー・データベースのサポート。OPSSでは、2つの新しいデータベースがセキュリティ・ストアのリポジトリとしてサポートされます。第4.1項「サポートされているファイル、LDAPおよびDBのストア」を参照してください。

- 動的メタデータ・モデルを使用して登録時に監査レコードのデータベース・ビューを作成する機能。第15.2.1項「登録時に作成される監査ビュー」を参照してください。

- 新しい監査コマンドcreateIAUViewおよびgetIAUViewInfo。使用すると、監査データベース・ビューに関する情報を作成および取得できます。『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の監査構成コマンドに関する項を参照してください。

- 新しいmerge.jdkcacerts.with.trustプロパティ。kss://system/trustへのキーストア問合せでkss://system/publicacertsキーストアの公開認証局証明書を戻すかどうかを指定します。第12.4項「証明書について」を参照してください。

- OPSS REST API。

2015年1月度12.1.3.0.0向けドキュメントの更新内容

このドキュメントで更新された内容は次のとおりです。

- ドキュメントのバージョン番号が修正されました。

2014年10月度12.1.3.0.0向けドキュメントの更新内容

このドキュメントで更新された内容は次のとおりです。

- 12cの規格に従ってトピック・タイトルが改訂されました。

- Identity Governance Framework。Oracle Fusion Middleware Identity Governance Framework Identity Directory用のJava APIリファレンスを参照してください。

リリース12.1.3.0.0の新機能

リリース12.1.3.0.0で導入された新機能および大規模な変更は次のとおりです。

- OPSSおよび監査スキーマでは、エディションベースの再定義(EBR)がサポートされます。EBRサポートに関するリファレンスについては、第9.3項「DBセキュリティ・ストアの使用」を参照してください。

- Java Required Files (JRF)テンプレートにより、データ・ソースが自動的に作成されます。JRFテンプレートを使用してドメインを作成すると、データ・ソースが3つ(OPSSスキーマ、OPSS監査ビューア・スキーマ、OPSS監査追加スキーマそれぞれに1つずつ)作成されます。第7.3.1項「新しいデータベース・インスタンスの使用」を参照してください。

- 動的メタデータ・モデルへのコンポーネント監査定義のアップグレード。静的モデルを使用しているコンポーネントでは、AuditSchemaUpgradeToolコマンドで監査定義を12c動的モデルにアップグレードできます。第7.7項「コンポーネントの監査定義の12cへのアップグレード」を参照してください。

- 監査イベント名および監査名について推奨されるネーミング規則とガイドライン。第14.7項「監査イベント定義のベスト・プラクティス」を参照してください。

- 新しい監査イベント。表C-2「コアOPSSのイベント」で次のイベント・カテゴリを参照してください。

- RolePolicyManagement

- ResourceManagement

- KeyStoreManagement

- PermissionSetManagement

- OPSS診断フレームワーク。このフレームワークは、レポートされた問題の解決時間を短縮できるようサポート担当者を支援します。このフレームワークを使用して、ドメインの内部状態をダンプに抽出し、特定の問題の原因を明らかにすることができます。第J.1項「OPSS診断フレームワーク」を参照してください。

- reassociateSecurityStoreコマンドの2つの新しい引数。新しいmigrate引数を使用すると、ソース・データをターゲット・ストアに追加するかどうかを指定できます。新しいskip引数を使用すると、互換性のないアーティファクトの移行をスキップできます。第10.4.1項「reassociateSecurityStore」を参照してください。

- migrateSecurityStoreコマンドの新しい引数。新しいskip引数では、互換性のないアーティファクトの移行をスキップするか、ソース・リポジトリで互換性のないアーティファクトが検出されたときに実行を終了するかを指定します。第9.5.2項「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。

- JpsStartupクラスの機能強化。このクラスには、次のものが含まれるようになりました。

- JpsStartup.startメソッドのOPSS状態セット

- JpsStartup.startメソッドのランタイム・オプションの一部

- JpsStartupクラスの新しいコンストラクタ

- JpsStartup.getStateメソッド

第24.1.1項「JpsStartupクラス」を参照してください。

- ウォレットに対するキーストアのエクスポートおよびインポートのサポート。第12.3項「WLSTを使用したキーストアの管理」のタスク・リストを参照してください。

- 米国連邦情報処理標準(FIPS)のサポート。FIPS-140は、Oracle Fusion Middlewareスタック全体で有効になっています。第4.3項「OPSSでのFIPSサポート」を参照してください。

リリース12.1.2.0.0の新機能

リリース12.1.2.0.0で導入された新機能および大規模な変更は次のとおりです。

- ドメインの作成または拡張でセキュリティ・アーティファクトをシードするためのテンプレートの使用、および12.1.2にアップグレードするための新しい手順。第7章「セキュリティ・アーティファクトのライフ・サイクル」を参照してください。

- WLSTコマンドの参照情報は、このガイドから削除されました。この内容は現在、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』に記載されています。

- 監査レポートの2つの手法(動的メタデータ・モデルおよびレポート・テンプレート・モデル)。第15.1項「監査レポートについて」を参照してください。

- 監査システムの属性およびイベントの詳細を参照できます。C.1.1項「監査可能なコンポーネント」を参照してください。

第I部

セキュリティの概念の理解

この部は、次の章で構成されています。

- 第1章「Oracle Platform Security Servicesの概要」

- 第2章「ユーザーおよびロールの理解」

- 第3章「アイデンティティ、ポリシー、資格証明、鍵、証明書および監査の理解」

- 第4章「セキュリティ・ストアについて」

1 Oracle Platform Security Servicesの概要

Oracle Platform Security Services (OPSS)は、Java Platform Standard Edition (Java SE)およびJava Platform Enterprise Edition (Java EE)のアプリケーションを保護する移植可能な統合フレームワークを開発チームに提供します。

この章は次の項で構成されています。

- OPSSとは

- OPSSのアーキテクチャの概要

- 開発者向けのOPSS

- ADFのセキュリティの概要

このドキュメントではOracle Web Servicesのセキュリティについて説明しません。Oracle Web Servicesの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

1.1 OPSSとは

OPSSは、Oracle WebLogic Server、サービス指向アーキテクチャ(SOA)アプリケーション、Oracle WebCenter、Oracle Application Development Framework (Oracle ADF)アプリケーション、Oracle Entitlements Server (OES)などのOracle Fusion Middleware製品を保護する、基盤となるセキュリティ・プラットフォームです。

OPSSでは、アプリケーション・プログラミング・インタフェース(API)として抽象レイヤーを提供しています。これにより、開発者は、セキュリティおよびアイデンティティ管理の実装の詳細に関与する必要がなくなります。開発者は、暗号鍵の管理、リポジトリ・インタフェース、他のアイデンティティ管理インフラストラクチャなどについて詳しく理解する必要がありません。社内開発アプリケーション、サードパーティ・アプリケーションおよび統合アプリケーションでは、OPSSを使用することで、企業全体で統一された同一のセキュリティ・サービスを利用できます。

OPSSは、Oracle Fusion Middlewareのインストールの一部としてインストールされます。

1.1.1 OPSSの主な機能

OPSSは、ロールベースのアクセス制御(RBAC)、Java EE、Java Authorization and Authentication Services (JAAS)およびJava Authorization Contract for Containers (JACC)の各標準に準拠しています。

これらの標準に基づいているOPSSは、次の機能をサポートする統合セキュリティ・プラットフォームを提供します。

- 認証

- IDアサーション

- 認可

- ロールおよびロール・マッピングの管理

- アプリケーション・ポリシーおよび資格証明の管理

- 鍵と証明書の管理

- 監査

- ID仮想化

- セキュリティAPI

1.1.2 サポートされているサーバー・プラットフォーム

OPSSは、WebLogic Serverでサポートされています。

1.2 OPSSのアーキテクチャの概要

OPSSは、WebLogic Serverのセキュリティ・プロバイダとOracle Fusion Middlewareセキュリティ・フレームワークで構成されています。図1-1に、OPSSアーキテクチャを示します。

図1-1 OPSSアーキテクチャ

OPSSアーキテクチャには次のレイヤーがあります。

- 認可、認証、資格証明、アイデンティティと信頼、Secure Sockets Layer (SSL)および暗号化サービスなどのセキュリティ・サービス。認証には、WebLogic Server認証プロバイダが使用されます。

- WebLogicセキュリティ・プロバイダ。セキュリティ・サービス・プロバイダ・インタフェース(SSPI)により、Javaコンテナ・セキュリティ、環境に応じたリソースベースの認可、セキュリティ・プロバイダを実装するためAPIが提供されます。これらのインタフェースを実装するモジュールをフレームワークにプラグインすることで、カスタム認証や特定のロール・マッピングなどの特殊なタイプのセキュリティ・サービスを提供できます。

- ファイル、Lightweight Directory Access Protocol (LDAP)、データベースという3タイプのリポジトリのいずれかを使用したセキュリティ・ストア。

関連項目:

『Oracle WebLogic Serverセキュリティの理解』のセキュリティ・サービス・プロバイダ・インタフェース(SSPI)に関する項を参照してください。

1.2.1 OPSSの利点

OPSSには、次のような様々な利点があります。

- アプリケーションとドメインの問題に対する開発リソースの集中が可能

- エンタープライズ・デプロイメントのサポート

- LDAPサーバーおよびSSOシステムのサポート

- WebLogic Serverで動作保証済であること

- Oracleの製品およびテクノロジとの統合

- 開発者およびセキュリティ管理者の一貫したセキュリティ・エクスペリエンス

- あらゆるタイプのアプリケーションを対象にしたAPIの統一セット

- 抽象レイヤーによる開発時間の最適化

- アプリケーションのセキュリティ・メンテナンスの簡素化

- アプリケーション・コードの変更を必要としない、セキュリティ・ルールの変更

- 管理の容易化

- アイデンティティ管理システムとの統合

OPSSでは、Java EEアプリケーション、Oracle Fusion MiddlewareアプリケーションおよびJava SEアプリケーションを保護します。また、企業内の全セキュリティを管理するためのツールを提供し、アプリケーション・コードを変更せずにセキュリティ構成を変更することも可能です。

OPSS APIを使用することで、開発者はあらゆるタイプのアプリケーションを保護し、他のセキュリティ・システム(LDAP、DBMS、カスタムのセキュリティ・コンポーネントなど)と統合します。

すぐに使用できる状態では、デフォルトのセキュリティ・プロバイダ(組込みLDAPサーバー)が使用可能ですが、ドメインでは他のLDAPリポジトリにあるアイデンティティ・データを使用することもできます。

1.3 開発者向けのOPSS

次の各項では、Javaアプリケーションで使用する主要なセキュリティ機能の概要を示します。

- Java EEアプリケーションのセキュリティについて

- Java SEアプリケーションのセキュリティについて

1.3.1 Java EEアプリケーションのセキュリティについて

Java EEアプリケーションでは、資格証明ストア・フレームワークAPI、ユーザーおよびロールAPI、Identity Governance Framework APIおよびキーストア・サービスAPIに付属するものを含め、いくつかのインタフェースを使用してセキュリティ・データへのアクセスおよび管理を行うことができます。これらのインタフェースを使用して、Java EEアプリケーションでは、ユーザー属性の設定および取得、ポリシー、鍵および証明書の管理を行います。

Java EEアプリケーションでは、認証と認可をweb.xmlファイルで指定することで宣言的に使用することも、isUserInRoleメソッドおよびisCallerInRoleメソッドをコールすることでプログラム的に使用することもできます。

Java EEアプリケーションでは、カスタム認証プロバイダを使用できますが、ロールおよびエンタープライズ・グループを使用してJavaサーブレットとEnterprise JavaBeans (EJB)間の認証を制御することもできます。

関連項目:

第16.2項「セキュリティ統合ユースケース」

第19.1項「ユーザーおよびロールAPIについて」

第23章「OPSSを使用するためのJava EEアプリケーションの構成」

1.3.2 Java SEアプリケーションのセキュリティについて

Java EEアプリケーションで使用可能なOPSS機能のほとんどはJava SEアプリケーションでも使用可能ですが、Java SEアプリケーションにのみ当てはまる次のような相違点があります。

- アプリケーションでは、セキュリティ操作をコールする前に、AppSecurityContext.JpsStartup.startメソッドを使用する必要があります。

- アプリケーションのセキュリティ構成は、次の場所にデフォルトでインストールされるjps-config-jse.xmlファイルで定義します。

$DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml

別の場所を指定するには、oracle.security.jps.configプロパティを使用します。

-Doracle.security.jps.config=pathToConfigFile

- アプリケーションでは、ログイン・モジュールをコールするカスタム認証プロバイダを実装することで標準のJAASログイン・モジュールを使用します。

- 次のJavaアーカイブ(JAR)ファイルをクラス・パスに追加する必要があります。

$ORACLE_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar

関連項目:

『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「認証プロバイダ」

第24.1項「Java SEアプリケーションでのOPSSの使用」

1.4 ADFのセキュリティの概要

Oracle ADFは、インフラストラクチャ・サービスおよび視覚的な開発エクスペリエンスを提供することで開発を簡略化するエンドツーエンドJava EEフレームワークです。Oracle ADFは、Oracle JDeveloper (JDeveloper)と統合されます。

ADFセキュリティは、JAASセキュリティ・モデルに基づいており、OPSSおよびパーミッション・ベースの認可を使用し、ビジュアル・エディタおよびADFセキュリティ・ウィザードによってアプリケーション・セキュリティの構成を簡単にします。

Oracle ADFアプリケーションの開発段階で、Oracle WebLogic Server管理コンソールを使用して認証プロバイダを構成し、ポリシーをファイルに格納します。

要約すると、ADFのセキュリティによって次のことが可能になります。

- 宣言的セキュリティの粒度の制御

- ロール階層によるパーミッションの簡略化

- Oracle ADFリソースへのアクセス

- 短期間での開発とテスト・サイクルのためのJDeveloperとの統合

関連項目:

Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

第16.7項「Oracle ADFアプリケーションの保護」

1.4.1 Oracle ADFアプリケーション・セキュリティ

Oracle ADFにより、アプリケーション・インフラストラクチャを実装するコードが最小限に抑えられ、JDeveloperを使用したJava EEアプリケーションの開発が簡略化されます。これにより、開発者はアプリケーションの機能に集中できます。

Oracle ADFでは、コンテナ認証を利用してから、JAASベースの認可を使用してOracle ADFリソースへのアクセスを制御します。ポリシーには、特定のアプリケーション・ロールおよびJAAS認可パーミッションを指定できます。Oracle ADFの接続資格証明は、セキュリティ・ストアに格納されます。

Oracle ADFおよびWebCenterのアプリケーションには、WebLogic認証プロバイダが組み込まれていますが、Oracle Single Sign-Onなどのシングル・サインオン・ソリューションを組み込むこともできます。

関連項目:

『Oracle WebLogic Serverセキュリティの管理 12c』のMicrosoftクライアントに対するシングル・サインオンの概要に関する項を参照してください。

第16.7項「Oracle ADFアプリケーションの保護」

2 ユーザーおよびロールの理解

この章では、このドキュメント全体を通して使用されている用語を定義し、ロール・カテゴリおよびロール・マッピングについて説明します。特別なロールには、認証ロールと匿名ロールがあります。

この章の内容は次のとおりです。

- 用語

- ロール・マッピング

- ロール・カテゴリについて

- 認証ロールについて

- 匿名ユーザーとロールについて

- 管理ユーザーおよび管理ロールについて

- ユーザー・アカウントの管理

2.1 用語

この項では、このドキュメント全体で使用されているOPSS用語を定義します。

ユーザーおよびグループ

ユーザーとは、サービスにアクセスしているエンドユーザーです。グループとは、ユーザーおよびその他のグループのサブセットであるため、グループには階層構造があります。

認証されたユーザーとは、資格証明が検証されているユーザーです。ユーザーを認証するために、OPSSではWebLogic認証プロバイダを使用します。

匿名ユーザーとは、保護されていないリソースにのみアクセスを許可された、認証されたユーザーのことです。

ロール

エンタープライズ・ロールまたはエンタープライズ・グループとは、ユーザーおよびグループの集合です。

アプリケーション・ロールとは、ユーザーおよびその他のアプリケーション・ロールの集合です。アプリケーション・ロールはアプリケーション・ポリシーで定義されますが、Javaコンテナに認識されるとはかぎりません。アプリケーション・ロールは、エンタープライズ・ロールに多対多でマップできます。たとえば、(アイデンティティ・ストア内の)employeeエンタープライズ・ロールを、(あるストライプ内の)helpdesk service requestアプリケーション・ロールにマッピングし、さらに(他のストライプ内の)self service HRアプリケーション・ロールにマップできます。

プリンシパル

プリンシパルとは、ポリシーによってパーミッションが付与されるアイデンティティです。プリンシパルには、ユーザー、外部ロールまたはアプリケーション・ロールを指定できます。

ポリシー

アプリケーション・ポリシーとは、プリンシパルに対してパーミッション・セット(アプリケーションWebページの閲覧やアプリケーション・レポートの変更など)を指定するポリシーです。アプリケーション・ポリシーにはプリンシパルが少なくとも1つ必要であり、個別のパーミッションまたはパーミッション・セットのいずれかを指定できますが、両方は指定できません。

システム・ポリシーとは、プリンシパルまたはコードソースに対してパーミッション・セットを指定するポリシーです。システム・ポリシーの有効範囲はドメイン全体です。システム・ポリシーではコードソースとプリンシパルにパーミッションが付与されますが、アプリケーション・ポリシーではプリンシパルにのみパーミッションが付与されます。アプリケーション・ポリシーとシステム・ポリシーは、jazn-data.xmlファイルに指定します。

サブジェクト

サブジェクトとは、プリンシパルおよびユーザーの資格証明(パスワード、暗号鍵など)の集合です。認証サービスにより、サブジェクトにユーザー、グループ、アプリケーション・ロールおよび資格証明が移入されます。OPSSサブジェクトは、アイデンティティがドメイン間で伝播される場合にきわめて重要です。

OPSS構成ファイル

ドメインに対するすべてのセキュリティ・サービスが指定されているファイル。OPSS構成ファイルでの指定内容は、ドメイン全体、すなわちドメイン内で実行されているサーバーおよびアプリケーションすべてに適用されます。

デフォルトでは、OPSS構成ファイルはjps-config.xmlファイル(Java EEアプリケーションの場合)およびjps-config-jse.xmlファイル(Java SEアプリケーションの場合)であり、$DOMAIN_HOME/config/fmwconfigディレクトリにあります。

OPSSコンテキスト

コンテキストは、ドメインに共通するサービス・インスタンスの集合を定義します。コンテキストは、OPSS構成ファイルに指定します。

セキュリティ・ストア

アイデンティティ・ストアは、エンタープライズ・ユーザーおよびグループのリポジトリで、LDAPである必要があります。すぐに使用できる状態では、ユーザーおよびグループはデフォルト・プロバイダ(組込みLDAPサーバー)に格納できます。

セキュリティ・ストアは、ドメイン内で実行されているアプリケーションすべてで使用されるシステム・ポリシー、アプリケーション・ポリシー、資格証明、監査データ、鍵および証明書のリポジトリです。

ポリシー・ストアは、アプリケーション・ポリシーおよびシステム・ポリシーが格納される部分、すなわちセキュリティ・ストアのことです。資格証明ストアは、資格証明が格納されるセキュリティ・ストアの部分のことです。キーストアは、キーおよび証明書が格納されるセキュリティ・ストアの部分のことです。トラストストアは、サードパーティの認証局の信頼できる証明書が格納されるキーストアのことです。

アプリケーション・ストライプ

アプリケーション・ストライプまたはストライプとは、(アプリケーションが認識されている場合)ポリシー・ストア内のポリシーのサブセットです。アプリケーションでは、ストライプ名を指定することで使用するポリシーが選択されます。複数のアプリケーションで同じストライプを使用できます。

監査の用語の詳細は、13.2項「監査の用語」を参照してください。

関連項目:

ロール・マッピング

認証ロールについて

匿名ユーザーとロールについて

第23.3.1項「アプリケーション・ストライプの設定」

2.2 ロール・マッピング

OPSSでは、アプリケーション・ロールとエンタープライズ・グループの多対多のマッピングがサポートされています。これにより、アプリケーション・ロールでの指定に従って、エンタープライズ・グループのユーザーがアプリケーション・リソースにアクセスできます。

エンタープライズ・グループにアプリケーション・ロールをマップすると、そのエンタープライズ・グループのパーミッションは、自身のパーミッションとマップされたロールのパーミッションの和集合に書き換えられます。したがって、マッピングによってエンタープライズ・グループのパーミッションが増えることはあっても減ることはありません。

アプリケーションのデプロイ後に、WebLogic Scripting Tool (WLST)、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはOracle Entitlements Server (OES)を使用してアプリケーション・ロールをエンタープライズ・グループにマップします。

関連項目:

Fusion Middleware Controlを使用したロールの管理の詳細は、第10.3.2項「アプリケーション・ロールの管理」を参照してください。

2.2.1 パーミッションの継承とロールの階層

OPSSロールは、"所属メンバー"という関係を使用して階層構造とすることができるため、ロールはメンバーとしてユーザーまたはロールを持つことができます。

ロール階層では、ロールのメンバーは親ロールからパーミッションを継承します。つまり、roleAロールがroleBロールのメンバーである場合、roleBロールに付与されているパーミッション全部がroleAロールにも付与されます。また、roleAロールは独自のパーミッションを持つこともできます。

関連項目:

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のgrantAppRoleに関する項およびrevokeAppRoleに関する項

Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド

2.2.1.1 ロール階層の例

次の例は、ネストしたアプリケーション・ユーザーおよびロールのロール階層を示しています。この例では、developerAppRoleロールは次のメンバーを持っています。

developer
developer_group
managerAppRole
directorAppRole

また、directorAppRoleロールは次のメンバーを持っています。

developer
developer_group

jazn-data.xmlファイルでこの階層を指定している部分は次のとおりです。

<policy-store>
<applications>
<application>
<name>MyApp</name>
<app-roles>
<app-role>
<name>developerAppRole</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>Application developer role</display-name>
<description>Application developer role</description>
<guid>61FD29C0D47E11DABF9BA765378CF9F5</guid>
<members>
<member>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>developer</name>
</member>
<member>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>directorAppRole</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developer_group</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>managerAppRole</name>
</member>
</members>
</app-role>
<app-role>
<name>directorAppRole</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<display-name>Application director role </display-name>
<description>Application director role</description>
<guid>61FD29C0D47E11DABF9BA765378CF9F8</guid>
<members>
<member>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>developer</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developer_group</name>
</member>
</members>
</app-role> ...
</app-roles>

<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>developerAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.io.FilePermission</class>
<name>/tmp/oracle.txt</name>
<actions>write</actions>
</permission>
</permissions>
</grant>

<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>managerAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.util.PropertyPermission</class>
<name>myProperty</name>
<actions>read</actions>
</permission>
</permissions>

</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>directorAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>foo.CustomPermission</class>
<name>myProperty</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</policy-store>

表2-1は、この例での5つのユーザーおよびロールのパーミッションをまとめたものです。

表2-1 付与されるパーミッションと継承されるパーミッション

ロール

付与されるパーミッション

実際のパーミッション

developerAppRole

P1=java.io.FilePermission

P1

managerAppRole

P2= java.util.PropertyPermission

P2および(継承される)P1

directorAppRole

P3=foo.CustomPermission

P3および(継承される)P1

developer

P1およびP3(どちらも継承される)

developer_group

P1およびP3(どちらも継承される)

2.3 ロール・カテゴリについて

ロール・カテゴリは、アプリケーション・ロールの集まりです。ロール・カテゴリには階層構造がありません。

次の例は、ロール・カテゴリの構成を示しています。

<app-roles>
<app-role>
<name>AppRole_READONLY</name>
<display-name>display name</display-name>
<description>description</description>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<extended-attributes>
<attribute>
<name>ROLE_CATEGORY</name>
<values>
<value>RC_READONLY</value>
</values>
</attribute>
</extended-attributes>
</app-role>
</app-roles>
<role-categories>
<role-category>
<name>RC_READONLY</name>
<display-name>RC_READONLY display name</display-name>
<description>RC_READONLY description</description>
</role-category>
</role-categories>

ロール・カテゴリのメンバーは<role-category>内で構成されませんが、対応するアプリケーション・ロールの<extended-attributes>内で構成されます。ロール・カテゴリ名では、大文字と小文字は区別されません。ロール・カテゴリは、RoleCategoryManagerインタフェースを使用して管理できます。

関連項目:

Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド

『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』

2.4 認証ロールについて

OPSSでは、認証ロールがサポートされています。このロールは、あらゆるアプリケーションで使用でき、OPSS構成ファイルで宣言する必要がありません。認証ロールに付与されるパーミッションは、所属先のエンタープライズ・グループおよびアプリケーション・ロールから取得されます(つまり、継承されるパーミッションのみが付与されます)。認証ロールの一般的な用途は、認証されたユーザーに共通アプリケーション・リソースへのアクセスを許可することです。これはJavaサーブレット・フィルタおよびEnterprise JavaBeans (EJB)インターセプタで構成します。

関連項目:

第23.3項「フィルタおよびインターセプタの構成」

2.5 匿名ユーザーとロールについて

OPSSでは、匿名ユーザーおよび匿名ロールがサポートされています。これらに付与されるパーミッションは、所属先のエンタープライズ・グループおよびアプリケーション・ロールから取得されます(つまり、継承されるパーミッションのみが付与されます)。匿名ユーザーおよびロールの一般的な用途は、認証されていないユーザーにパブリックな非保護リソースへのアクセスを許可することです。これはJavaサーブレット・フィルタおよび(EJB)インターセプタで構成します。

関連項目:

第23.3項「フィルタおよびインターセプタの構成」

2.6 管理ユーザーおよび管理ロールについて

WebLogic管理者は、Administratorsグループのユーザー・メンバーであり、このグループにはWebLogicセキュリティ・レルム内のユーザーを追加できます。通常、管理者にデフォルト名はありません。

ドメインを構成すると、AdministratorsグループのメンバーはAdministratorsグループのユーザーを管理できます。これらのアカウントを管理するためのツールは、Oracle WebLogic Server管理コンソール、WLSTおよびFusion Middleware Controlです。

関連項目:

『Oracle WebLogic Server本番環境の保護』のWebLogic Serverのセキュアなインストールに関する項

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループ、セキュリティ・ロール」

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグループへのユーザーの追加に関する項

『WebLogic Scripting Toolの理解』の「WebLogic Scripting Toolの使用」

2.7 ユーザー・アカウントの管理

ユーザー・アカウントおよびパスワードの詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーおよびグループの管理に関する項

- 『Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護に関する項

- 『Oracle WebLogic Serverセキュリティの管理 12c』の「組込みLDAPサーバーの管理」

- 『Oracle WebLogic Serverセキュリティの管理 12c』の「パスワード検証プロバイダの構成」

3 アイデンティティ、ポリシー、資格証明、鍵、証明書および監査の理解

アイデンティティ、ポリシー、資格証明、鍵および監査は、アプリケーションの保護の基盤となります。この章では、これらの基本概念について説明し、セキュリティの互換バージョン11gおよび12cの表を示します。

この章の内容は次のとおりです。

- バージョン11gおよび12cの互換性の表

- 認証の基本

- ポリシーの基本

- 資格証明の基本

- 鍵および証明書の基本

- 監査の基本

3.1 バージョン11gおよび12cの互換性の表

この項では、リリース11.1.1.5.0、11.1.1.6.0、11.1.1.7.0、11.1.1.9.0、12.1.2.0.0、12.1.3.0.0および12.2.1.0.0について、バイナリ、構成、スキーマおよびストアの互換バージョンを示します。これらのアーティファクトの互換バージョンは、DBとLDAPの両方のセキュリティ・ストアに適用されます。DBストアでは、データベース・スキーマごとにセキュリティ・ストアは1つのみと見なされます。

次の表は、互換バージョンを示しており、DBとLDAPの両方のセキュリティ・ストアに適用されます。次の記号に注意してください。

- バージョン番号の前に付いている記号=>は、示されているバージョン番号以降のバージョンを意味します。

- バージョン番号の前に付いている記号>は、示されているバージョン番号より新しいバージョンを意味します。

- バージョン番号の前に付いている記号<は、示されているバージョン番号より前のバージョンを意味します。

バイナリ

構成

スキーマ

ストア

ステータス

11.1.1.5.0

11.1.1.5.0

=>11.1.1.5.0

11.1.1.5.0

認証済

11.1.1.5.0

11.1.1.5.0

>11.1.1.5.0

>11.1.1.5.0

サポート対象外

11.1.1.6.0

11.1.1.5.0

=>11.1.1.5.0

11.1.1.5.0

認証済

11.1.1.6.0

11.1.1.5.0

>11.1.1.5.0

>11.1.1.5.0

サポート対象外

11.1.1.6.0

11.1.1.6.0

=>11.1.1.6.0

11.1.1.6.0

認証済

11.1.1.6.0

11.1.1.6.0

>11.1.1.6.0

>11.1.1.6.0

サポート対象外

11.1.1.7.0

11.1.1.7.0

=>11.1.1.6.0

<11.1.1.7.0

サポート対象外

11.1.1.7.0

11.1.1.6.0

=>11.1.1.6.0

11.1.1.6.0

認証済

11.1.1.7.0

11.1.1.6.0

>11.1.1.6.0

>11.1.1.6.0

サポート対象外

11.1.1.7.0

11.1.1.7.0

=>11.1.1.7.0

11.1.1.7.0

認証済

11.1.1.9.0

11.1.1.7.0
11.1.1.6.0

11.1.1.5.0

11.1.1.9.0

=>11.1.1.7.0
=>11.1.1.6.0

=>11.1.1.5.0

=>11.1.1.9.0

11.1.1.7.0
11.1.1.6.0

11.1.1.5.0

11.1.1.9.0

認証済

12.1.2.0.0

12.1.2.0.0

=>12.1.2.0.0

12.1.2.0.0

認証済(スキーマのみのアップグレード)

12.1.2.0.0

<12.1.2.0.0

<12.1.2.0.0

<12.1.2.0.0

サポート対象外

12.1.3.0.0

12.1.3.0.0

=>12.1.3.0.0

12.1.3.0.0

認証済(スキーマのみのアップグレード)

12.1.3.0.0

<12.1.3.0.0

<12.1.3.0.0

<12.1.3.0.0

サポート対象外

12.2.1.0.0

<12.2.1.0.0

<12.2.1.0.0

<12.2.1.0.0

サポート対象外

3.2 認証の基本

OPSSでは、ユーザー名とパスワードの組合せまたは証明書に基づいてユーザーを検証するコンポーネントであるWebLogic認証プロバイダを使用します。認証プロバイダにより、ドメイン内の他のコンポーネントで(サブジェクト内の)ユーザー・アイデンティティ情報を使用できるようになります。

Java EEアプリケーションでは、LDAPまたはDBの認証プロバイダを使用できます。すぐに使用できる状態のJava SEアプリケーションでは、ファイル・アイデンティティ・ストアを使用しますが、LDAPサーバーまたはデータベースを使用するようにストアを構成することもできます。

Oracle WebLogic Serverのセキュリティの詳細は、『Oracle WebLogic Serverセキュリティの理解』の認証に関する項を参照してください。

次の各項では、WebLogic認証プロバイダについて説明します。

- WebLogic認証プロバイダ

- アイデンティティ・ストア・タイプとWebLogic認証プロバイダ

3.2.1 WebLogic認証プロバイダ

デフォルトでは、ユーザーおよびグループはWebLogic Default Authenticatorに格納されます。この認証プロバイダでは、デフォルト属性としてcnを使用します。

LDAP認証プロバイダに格納されたデータには、ユーザーおよびロールAPIでアクセスしてユーザー・プロファイル属性を問い合せることができますが、LDAPではないアイデンティティ・リポジトリの問合せにはカスタム・コードが必要な場合があります。認証プロバイダ内では、グループ名は一意である必要があります。

次の各項では、複数の認証プロバイダを設定する方法について説明します。

- 複数の認証プロバイダのサポート

- その他の認証方式

関連項目:

『Oracle WebLogic Serverセキュリティの管理 12c』のLDAP X509アイデンティティ・アサーション・プロバイダの仕組みに関する項

『Oracle WebLogic Serverセキュリティの管理 12c』の「SAML認証プロバイダの構成」

3.2.1.1 複数の認証プロバイダのサポート

WebLogic Serverでは、特定のコンテキストで複数の認証プロバイダを構成できます。そのうちの1つは、LDAP認証プロバイダとする必要があります。

デフォルト・オーセンティケータでは、制御フラグが(デフォルトで)REQUIREDに設定されています。デフォルト・オーセンティケータ以外のLDAP認証プロバイダでアイデンティティ・ストアを初期化するには、デフォルト・オーセンティケータの制御フラグを変更するか、認証プロバイダの順序を入れ替えます。

OPSSでは、次のアルゴリズムに従ってLDAP認証プロバイダを使用し、アイデンティティ・ストアを初期化します。

1. コンテキストで構成されているLDAP認証プロバイダのセットを検討します。コンテキストには、LDAP認証プロバイダが少なくとも1つ含まれている必要があります。

2. そのセットの中で、最大のフラグが設定されている認証プロバイダを検討します。このサブセットでの計算に使用するフラグの順序は次のとおりです。

REQUIRED > REQUISITE > SUFFICIENT > OPTIONAL

3. そのサブセットの中から、該当のコンテキストで最初のプロバイダを検討します。

手順3で選択したLDAP認証プロバイダを、アイデンティティ・ストアの初期化に使用します。

サービス・インスタンスの初期設定値がサービス・インスタンスの構成で明示的に指定されている場合は、その構成された値がデフォルト値よりも優先されます。

関連項目:

Oracle WebLogic Server本番環境の保護

第G.1項「OPSS APIリファレンス」

3.2.1.2 その他の認証方式

WebLogic Serverアイデンティティ・アサーション・プロバイダでは、X.509証明書、SPNEGOトークン、セキュリティ・アサーション・マークアップ・ランゲージ(SAML)アサーション・トークンおよびCORBA Common Secure Interoperability version 2 (CSIv2)を使用した証明書認証がサポートされています。

ネゴシエート・アイデンティティ・プロバイダは、SPNEGOプロトコルをサポートするMicrosoftクライアントでSSOに使用します。このプロバイダは、SPNEGOトークンをデコードしてKerberosトークンを取得し、このKerberosトークンを検証してWebLogicユーザーにマップします。

関連項目:

『Oracle WebLogic Serverセキュリティの理解』のアイデンティティ・アサーション・プロバイダに関する項

『Oracle WebLogic Serverセキュリティの管理 12c』のMicrosoftクライアントに対するシングル・サインオンの概要に関する項を参照してください。

『Oracle WebLogic Serverセキュリティの管理 12c』のWebLogic Server用のKerberos識別情報の作成に関する項

3.2.2 アイデンティティ・ストア・タイプとWebLogic認証プロバイダ

この項の情報は、Java EEアプリケーションにのみ適用されます。

アイデンティティ・ストア・タイプのサポートされているバージョンについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlで「Oracle Fusion Middleware 12c Certifications」を参照してください。

次の表に、各アイデンティティ・ストア・タイプとともに使用するWebLogic認証プロバイダを示します。

表3-1 アイデンティティ・ストア・タイプと認証プロバイダ

ストア・タイプ

WebLogic認証プロバイダ

Oracle Internet Directory

OracleInternetDirectoryAuthenticator

Oracle Virtual Directory

OracleVirtualDirectoryAuthenticator

Open LDAP

OpenLDAPAuthenticator

Oracle Unified Directory

iPlanetAuthenticator

Oracle Directory Server Enterprise Edition

iPlanetAuthenticator

Sun Java System Directory Server。

iPlanetAuthenticator

Novell eDirectory

NovellAuthenticator

Tivoli Access Manager

OpenLDAPAuthenticator

Active Directory

ActiveDirectoryAuthenticator

Active Directory AM

ActiveDirectoryAuthenticator

Active Directory 2008

ActiveDirectoryAuthenticator

Oracle DB

CustomDBMSAuthenticator

ReadOnlySQLAuthenticator

SQLAuthenticator

デフォルト・オーセンティケータ以外のLDAP認証プロバイダでは、UseRetrievedUserNameAsPrincipalフラグの設定が必要です。すぐに使用できる状態では、デフォルト・オーセンティケータのこのフラグは設定されています。

関連項目:

第24.3.1項 「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」

付録H「OpenLDAPアイデンティティ・ストアの使用」

『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「認証プロバイダ」

『Oracle WebLogic Serverセキュリティの管理 12c』の「認証プロバイダの構成」

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証およびアイデンティティ・アサーション・プロバイダの構成に関する項

3.3 ポリシーの基本

ポリシーは、特定の場所からロードされたコードに付与されるパーミッションを指定します。

Java Authorization and Authentication Services (JAAS)ポリシーは、オプションのプリンシパル・リストを指定できるようにすることでポリシーを拡張するため、それらのプリンシパルで表されるユーザーによって実行されるコードにパーミッションが付与されます。

アプリケーション・ポリシーは、(ドメイン内のすべてのアプリケーションに適用されるポリシーとは対照的に)該当のアプリケーションにのみ適用されるJAASポリシーの集合です。

システム・ポリシーにより、ユーザーおよびグループに、またはURLやJARファイルなどのコードにパーミッションが付与されます。

OPSS認証サービスでは、システムの中央リポジトリ、アプリケーション・ポリシーおよびロールを提供します。アプリケーション・ロール(管理ロールなど)には、アプリケーション固有のエンタープライズ・ユーザーおよびグループを指定できます。ポリシーでは、これらのグループまたはユーザーをプリンシパルとして使用できます。

ロールを自己管理するアプリケーションの場合は、Java EEアプリケーション・ロール(web.xmlファイルまたはejb-jar.xmlファイルで構成)がエンタープライズ・ユーザーおよびグループにマップされ、アプリケーション・ポリシーで使用されます。

ポリシー・ストアは、アプリケーション・ポリシーおよびシステム・ポリシーが格納されるセキュリティ・ストアの部分のことです。ポリシー・ストアのタイプは、ファイル、LDAPまたはDBのいずれかです。ファイル・ストアはXMLファイルです。唯一サポートされているLDAPポリシー・ストア・タイプは、Oracle Internet Directoryです。

開発段階およびデフォルトでは、アプリケーション・ポリシーはjazn-data.xmlファイルで指定します。

Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用してアプリケーションをデプロイすると、ポリシーをセキュリティ・ストアに自動的に移行することができます。

パーミッション・クラスはすべて、システム・クラスパスで指定する必要があります。

関連項目:

第9.5.1項「Fusion Middleware Controlを使用したセキュリティ・ストアの移行」

第9.4項「セキュリティ・ストアの再関連付け」

第17.3.1項「リソース・カタログ」

3.4 資格証明の基本

OPSS資格証明サービスでは、ユーザー、Javaコンポーネントおよびシステム・コンポーネントの権限を証明するアーティファクトの中央リポジトリを提供します。資格証明には、ユーザー名とパスワードの組合せ、チケットまたは公開鍵証明書を格納できます。このデータは、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。

資格証明ストアは、資格証明が格納されるセキュリティ・ストアの部分のことです。資格証明ストアのタイプは、ファイル、LDAPまたはDBのいずれかです。ファイル資格証明ストアはcwallet.ssoファイルです。唯一サポートされているLDAP資格証明ストア・タイプは、Oracle Internet Directoryです。

アプリケーションでは、資格証明ストアまたは独自の資格証明ストアを使用できます。資格証明ストアは、ファイル、LDAPまたはDBのいずれかです。

Fusion Middleware Controlを使用してアプリケーションをデプロイすると、資格証明をセキュリティ・ストアに自動的に移行することができます。

OPSSには、アプリケーションで資格証明をプログラムで作成、読取り、更新および管理する際に使用できるAPIが組み込まれた資格証明ストア・フレームワークが用意されています。

関連項目:

第9.5.1項「Fusion Middleware Controlを使用したセキュリティ・ストアの移行」

第9.4項「セキュリティ・ストアの再関連付け」

3.5 鍵および証明書の基本

キーストア・サービス(KSS)キーストアは、ドメインのコンポーネントおよびアプリケーションによって使用される鍵および証明書に対する中央リポジトリとなります。これにより、キーストアを個々のアプリケーションに関連付ける必要がなくなり、また、ドメイン内のキーストア・データを一様に管理できる単一のユーザー・インタフェースとなります。

キーストア・リポジトリは、ファイル、DBまたはLDAPのいずれかです。あるタイプから別のタイプに、キーストアを再関連付けすることもできます。

関連項目:

第9.4項「セキュリティ・ストアの再関連付け」

第12章「鍵と証明書の管理」

3.6 監査の基本

Oracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)は、ドメインの監査レコードの中央リポジトリである監査ストアとなります。このフレームワークを使用して構成の変更をはじめ、コンポーネントおよびデプロイ済アプリケーションに対する操作アクティビティによってトリガーされるイベントを監査します。監査ストアは、ファイルまたはデータベースのいずれかです。

関連項目:

第13章「Oracle Fusion Middleware監査フレームワークの概要」

4 セキュリティ・ストアについて

この章では、サポートされているセキュリティ・ストア・タイプ、アプリケーション・セキュリティのパッケージ要件、米国連邦情報処理標準(FIPS)のOPSSサポートについて説明します。

この章の内容は次のとおりです。

- サポートされているファイル、LDAPおよびDBのストア

- パッケージ要件

- OPSSでのFIPSサポート

4.1 サポートされているファイル、LDAPおよびDBのストア

OPSSでは、次のリポジトリがサポートされています。

- セキュリティ・ストアおよびキーストアの場合:

- ファイルベース - XMLファイル

- LDAPベース - Oracle Internet Directory

- DBベース - Oracle DBMS、IBM DB2およびMicrosoft SQL Server

- アイデンティティ・ストアの場合: Oracle WebLogic ServerでサポートされているLDAP認証プロバイダ。ファイル・アイデンティティ・ストアは、Java SEアプリケーションでのみサポートされます。

- 監査ストアの場合:

- ファイルベース - XMLファイル

- DBベース - Oracle DBMS、IBM DB2およびMicrosoft SQL Server

サポートされているバージョンについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlで「Oracle Fusion Middleware 12c Certifications」を参照してください。

Oracle Internet Directoryリリース10.1.4.3をOPSSとともに使用している場合は、Oracle Bug#8351672を修正するパッチが必要です。各種バージョンのOracle Internet Directoryに対するパッチのリストについては、第9章「LDAPセキュリティ・ストアの使用」を参照してください。

関連項目:

第10章「ポリシーの管理」

第11章「資格証明の管理」

第12章「鍵と証明書の管理」

第14章「監査の管理」

4.2 パッケージ要件

アプリケーション・ポリシーはjazn-data.xmlファイルで指定し、アプリケーション資格証明はcwallet.ssoファイルで指定します。アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルのMETA-INFディレクトリでこれらのファイルをパッケージ化します。通常はアプリケーションのデプロイ時に、ポリシーおよび資格証明をセキュリティ・ストアに移行します。

関連項目:

第23.5項「Java EEアプリケーションの手動によるパッケージ化」

第6章「セキュア・アプリケーションのデプロイ」

4.3 OPSSでのFIPSサポート

FIPS-140は、Oracle Fusion Middlewareスタック全体で有効です。FIPSの詳細は、『Oracle Fusion Middlewareの管理』の「Oracle Fusion MiddlewareでのFIPS-140サポート」を参照してください。

第II部

OPSSの基本的な管理

この部は、次の章で構成されています。

- 第5章「セキュリティ管理」

- 第6章「セキュア・アプリケーションのデプロイ」

5 セキュリティ管理

この章では、アプリケーション・セキュリティを管理するために実行する主要なタスクと、それらのタスクを完了するために使用するツールについて説明します。

内容は次のとおりです。

- OPSS管理: 主な手順

- セキュリティ管理ツール

- Fusion Middleware Controlを使用したセキュリティ・プラクティス

- WebLogic Server管理コンソールを使用したセキュリティ・プラクティス

- OESを使用したセキュリティ・プラクティス

5.1 OPSS管理: 主な手順

アプリケーション・セキュリティ管理は、次の主要なタスクで構成される反復プロセスです。

- アプリケーションのパッキングおよびデプロイ

- アプリケーション・ロールおよびユーザーの管理

- アプリケーション・ポリシーおよびシステム・ポリシーの管理

- アプリケーション資格証明の管理

- アプリケーションの鍵および証明書の管理

- 監査の管理

関連項目:

アプリケーションとのセキュリティのパッキングの詳細は、第6章「セキュア・アプリケーションのデプロイ」を参照してください。

第10章の項「アプリケーション・ポリシーの管理」

第10章の項「アプリケーション・ロールの管理」

第11章「資格証明の管理」

第12章「鍵と証明書の管理」

第14章「監査の管理」

付録E「スクリプトおよびMBeanを使用した管理」

5.2 セキュリティ管理ツール

セキュリティを管理するには、次のツールのいずれかを使用します。

- Oracle WebLogic Server管理コンソール

- Fusion Middleware Control

- WebLogic Scripting Tool(WLST)

- Oracle Entitlements Server(OES)

使用するツールは、データのタイプおよびストアの種類によって決まります。

OPSSでは、サーバー・ファイルの自動バックアップおよび自動リカバリはサポートされません。すべてのサーバー構成ファイルを定期的にバックアップすることをお薦めします。バックアップの詳細は、『Oracle Fusion Middlewareの管理』の「バックアップとリカバリの概要」を参照してください。

ユーザーおよびグループ

ドメインでWebLogic Default Authenticatorを使用してアイデンティティを格納する場合は、WebLogic Server管理コンソールを使用して、格納したデータを管理します。このデータには、ユーザーおよびロールAPIでアクセスし、ユーザー・プロファイル属性を問い合せたり、ユーザーまたはグループに追加属性を挿入したりできます。

ドメインでデフォルト・オーセンティケータを使用する場合、アプリケーションでユーザーおよびロールAPIを使用してアイデンティティ・データにアクセスするためには管理サーバーが稼働している必要があります。そうではなく、デフォルト・オーセンティケータとは異なるLDAPサーバーを使用する場合は、そのLDAPサーバーのユーティリティを使用してユーザーとグループを管理します。

ポリシー、資格証明、キーおよび証明書

ポリシー、鍵、資格証明および証明書は、同じ種類の記憶域(ファイル、LDAPまたはDB)に格納されます。これらのアーティファクトを管理するためのツールは次のとおりです。

- WebLogic Server管理コンソール(アイデンティティの場合)

- Fusion Middleware Control、WLSTまたはOES (ポリシーおよび資格証明の場合)

- WLST (鍵および証明書の場合)

ポリシー、資格証明または鍵を変更した場合は、サーバーの再起動が不要です。jps-config.xmlファイルを変更した場合は、サーバーの再起動が必要です。

関連項目:

『Oracle Fusion Middlewareの管理』の「Oracle Fusion Middlewareの管理のスタート・ガイド」を参照してください。

5.3 Fusion Middleware Controlを使用したセキュリティ・プラクティス

この項では、セキュリティ関連の操作についてのみ説明します。その他の管理操作については、『Oracle Fusion Middleware Fusion Middleware ControlによるOracle WebLogic Serverの管理』を参照してください。

Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用して、次のようにします。

- インストール後、アプリケーションをデプロイする前に、セキュリティ・ストアを再関連付けします。

- インストール後、アプリケーションをデプロイする前に、OPSSのプロパティを定義します。

- アプリケーションのデプロイ時に、アプリケーション・ポリシーおよび資格証明からセキュリティ・ストアへの自動的な移行を構成します。

- アプリケーションのデプロイ後、次を実行します。

- アプリケーション・ポリシーの管理。

- 資格証明の管理。

- ユーザーとグループの管理。

- アプリケーション・ロールからユーザー、グループおよびアプリケーション・ロールへのマッピングの指定。

- ドメインのシステム・ポリシーを管理します。

- ドメインのOPSSプロパティを管理します。

関連項目:

第6.3項「新しい環境へのOracle ADFアプリケーションのデプロイ」

第9.4.1項「Fusion Middleware Controlを使用したセキュリティ・ストアの再関連付け」

第9.6項「Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成」

第9.5項「セキュリティ・ストアの移行」

第10.2項「ポリシー・ストアの管理」

第10.3.2項「アプリケーション・ロールの管理」

第10.3.3項「システム・ポリシーの管理」

第11章「資格証明の管理」

5.4 WebLogic Server管理コンソールを使用したセキュリティ・プラクティス

WebLogic Server管理コンソールを使用して、次を実行します。

- WebLogicサーバーの起動および停止。

- WebLogicサーバーおよびドメインの構成。

- アプリケーションのデプロイ。

- フェイルオーバー・サポートの構成。

- WebLogic ServerドメインおよびWebLogic Serverレルムの構成。

- WebLogic認証プロバイダの管理。

- Microsoftクライアント、WebブラウザおよびHTTPクライアントでのシングル・サインオンの有効化。

- 管理ユーザーおよび管理ポリシーの管理。

関連項目:

『WebLogic Scripting Toolの理解』の「既存のWebLogicドメインの構成」

Oracle WebLogic Serverへのアプリケーションのデプロイ

『Oracle WebLogic Serverクラスタの管理』の「クラスタのフェイルオーバーとレプリケーション」

『Oracle WebLogic Serverサーバーの起動と停止の管理』の「サーバーの起動および停止」

Oracle WebLogic Server管理コンソール・オンライン・ヘルプ

5.4.1 WLSTを使用したセキュリティ・プラクティス

WebLogic Server管理コンソールを使用して実行するセキュリティ構成タスクはすべて、ドメイン構成およびアプリケーション・デプロイメントを含め、WLSTを使用しても実行できます。

Java仮想マシン(JVM)インスタンスは、最大でも1つのjps-config.xmlファイルを指します。インスタンス内でコールされるあらゆるWLSTコマンドでは、次のコマンドに渡された構成場所に関係なく、最初に取得された構成ファイルを使用します。

関連項目:

Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス

5.5 OESを使用したセキュリティ・プラクティス

OESには、次の機能を含め、認証を構成および管理するための機能が多数用意されています。

- アプリケーション・ロールおよびロール階層の検索。

- アプリケーション・ポリシーおよびロール階層の管理。

- ロール履歴の表示。

- アプリケーション・ロール・マッピングの管理。

OESの詳細は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』を参照してください。

6 セキュア・アプリケーションのデプロイ

通常、Oracle WebLogic Server管理コンソールまたはOracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用して、アプリケーションをOracle WebLogic Serverにデプロイします。WebLogic Serverに認識されている場所にビットを設定することによって、サーバーを再起動せずにアプリケーションを起動することもできます。このようなアプリケーション起動は、ホット・デプロイとして知られています。

この章での推奨事項は、OPSSを使用するJava EEアプリケーションに当てはまります。

この章の内容は次のとおりです。

- Oracle ADFアプリケーションの開発

- デプロイのためのツールの選択

- 新しい環境へのOracle ADFアプリケーションのデプロイ

- 標準Java EEアプリケーションのデプロイ

- 監査対応アプリケーションのデプロイ

- テスト環境から本番環境への移行

関連項目:

『Oracle Fusion Middlewareの管理』の第8章「アプリケーションのデプロイ」

Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

第16.7項「Oracle ADFアプリケーションの保護」

第23章「OPSSを使用するためのJava EEアプリケーションの構成」

6.1 Oracle ADFアプリケーションの開発

Oracle Application Development Framework (Oracle ADF)アプリケーションをデプロイする場合、次のようにします。

- JDeveloperを使用してアプリケーションを開発し、Oracle ADFウィザードを使用してアプリケーションのセキュリティを構成します。

- JDeveloperを使用し、テスト・サイクルでアプリケーションのデプロイ先となる統合WebLogic Serverに、アプリケーションのユーザー、ロール、ポリシーおよび資格証明をコピーします。

- アプリケーションのポリシーおよび資格証明をパックしたアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルを作成します。

- Fusion Middleware Controlを使用して、EARファイルをWebLogic Serverにデプロイします。

このフローを図示すると次のようになります。

開発段階では、Oracle JDeveloper (JDeveloper)を使用してアプリケーションを組込みWebLogic Serverにデプロイします。テスト環境または本番環境に移行したアプリケーションは、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはWebLogic Server管理コンソールあるいはホット・デプロイを使用してデプロイします。

アプリケーションをデプロイするための推奨方法は、プラットフォーム、アプリケーション・タイプ、そのアプリケーションが開発中フェーズと開発後フェーズのどちらにあるかによって異なります。

関連項目:

「Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ」

6.2 デプロイのためのツールの選択

表6-1に、Java EEアプリケーションのデプロイに使用するツールを示します。

表6-1 Java EEアプリケーションをデプロイするためのツール

Java EEアプリケーション

使用ツール

Oracle ADF以外

WebLogic Server管理コンソール、Fusion Middleware Control。推奨ツールはWebLogic Server管理コンソールです。

Oracle ADF

Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)。推奨ツールはFusion Middleware Controlです。

関連項目:

「Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ」

6.2.1 Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ

この項では、OPSSを使用するJava EEアプリケーションをFusion Middleware Controlを使用してデプロイする際に使用可能なセキュリティ構成について説明します。

「アプリケーション・セキュリティの構成」ページの外観は、EARファイルのパッケージ内容に応じて次のように異なります。

- アプリケーション・ポリシーを設定したjazn-data.xmlをEARファイルにパッケージ化している場合、ページにはポリシーの移行セクションが表示されます。

- cwallet.ssoファイルに収めた資格証明をEARファイルにパッケージ化している場合、ページには資格証明の移行セクションが表示されます。

- これらのファイルのいずれもEARファイルに含まれていない場合、ページにはデフォルトのJava EEセキュリティ・オプションが表示されます。

このページの設定は、セキュリティ・ストアへの(アプリケーションEARファイルにパックされた)アプリケーションのポリシーおよび資格証明の移行を制御します。

デプロイ時にアプリケーション・ポリシーを移行する場合

デプロイ時にパックしたアプリケーション・ポリシーを移行するには、アプリケーションを1つのWebLogic Serverにのみデプロイします。パックしたポリシーとともにアプリケーションを複数の管理対象サーバーにデプロイする場合は、デプロイメントに管理サーバーを含める必要があるため、パックしたポリシーでsystem-jazn-data.xmlドメイン・ファイルが更新されます。

- アプリケーションを初めてデプロイする場合、セキュリティ・ストアにアプリケーション・ポリシーを移行するため、「アプリケーション・ポリシー移行」領域で「追加」を選択します。
なんらかの理由で移行しない場合は、「無視」を選択します。オプションの「上書き」も使用できます。

- 以前のデプロイでアプリケーション・ポリシーが移行済であることを前提としてアプリケーションを再デプロイしている場合、パックしたポリシーをドメイン内のポリシーにマージするには「追加」を選択し、ポリシーを移行しないようにするには「無視」を選択します。
「無視」オプションは、アプリケーションを再デプロイする場合、または以前のデプロイの際に変更したセキュリティ・ストアの内容を保持する場合に選択します。

- 「追加」を選択した場合は、移行する権限付与およびロールを指定します。基本的な相違点は、Oracle ADFアプリケーションのロールおよび権限付与と、開発時のみのロールおよび権限付与との差です。
Oracle ADFアプリケーションのロールおよび権限付与を移行して、開発時のみのセキュリティ・ロールおよび権限付与を移行しないようにするには、次を選択します: アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。これは、本番環境へのデプロイ時に選択します。アプリケーションをデプロイした後でアプリケーション・ロールをエンタープライズ・グループにマップする必要があります。

- 「追加」を選択した場合は、「アプリケーション・ストライプID」テキスト・フィールドにそのストライプの名前を入力して、アプリケーション・ポリシーの移行先とする特定のストライプ(アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ)を指定します。

- 何も指定しない場合、デフォルト設定は「追加」(デプロイの場合)と「無視」(再デプロイの場合)です。

デプロイ時にアプリケーション資格証明を移行する場合

- アプリケーションを初めてデプロイする場合、資格証明ストアにアプリケーション資格証明を移行します。そのためには、「アプリケーション資格証明移行」領域で「追加」を選択します。

- 資格証明を移行しないようにするには「無視」(デフォルト値)を選択します。

注意:
資格証明の移行を無視すると、資格証明を使用するアプリケーション・コードが動作しない場合があります。マップとキーが同じで値が異なる資格証明を作成した場合は「無視」を選択します。

- 「上書き」がサポートされるのは、WebLogic Serverが開発モードで稼働している場合のみです。

6.3 新しい環境へのOracle ADFアプリケーションのデプロイ

テスト環境または本番環境にOracle ADFアプリケーションを移行するとき通常は、Fusion Middleware Controlを使用してデプロイし、フレームワークで提供されるADFのセキュリティ機能すべてを活用します。

次の各項では、アプリケーションを新しい環境に移行する場合に含まれるタスクについて説明します。

- テスト環境へのデプロイ

- テスト環境から本番環境への移行

6.3.1 テスト環境へのデプロイ

ファイル・セキュリティ・ストアを使用するアプリケーションをデプロイする前に、権限付与に重複したパーミッションが含まれていないことを確認します。権限付与でパーミッションが重複している(パーミッションの名前とクラスが同じ)場合は、移行でエラーがレポートされ、停止します。解決するには、jazn-data.xmlファイルを編集して、重複しているパーミッションを削除します。

Fusion Middleware Controlを使用してOracle ADFアプリケーションをデプロイするときには次のプロセスが発生します。

- アプリケーションとともにパックされたアプリケーション・ポリシーは、セキュリティ・ストアに自動的に移行されます。

- アプリケーションとともにパックされたアプリケーション資格証明は、資格証明ストアに自動的に移行されます。

- 移行中に、LDAPリポジトリへのアクセスに必要なブートストラップ資格証明が作成されます。

アプリケーションとともにパックされたアイデンティティは移行されません。認証プロバイダを(WebLogic Server管理コンソールを使用して)構成し、必要に応じて、アイデンティティを更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールを(Fusion Middleware Controlを使用して)マップする必要があります。

LDAPセキュリティ・ストアがあるドメインにデプロイし、アプリケーション・データの整合性を保持する場合は、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。

アプリケーションを複数の管理対象サーバーにデプロイするときは、データが予期したとおりに移行されるよう管理サーバーを含めます。

関連項目:

「デプロイ後の一般的な管理タスク」

6.3.1.1 デプロイ後の一般的な管理タスク

アプリケーションのデプロイ後に、Fusion Middleware ControlまたはWebLogic Server管理コンソールを使用して、次を実行します。

- セキュリティ・プロバイダの管理

- アプリケーション・ポリシーの作成およびカスタマイズ

- アプリケーション・ロールの作成およびカスタマイズ

- システム・ポリシーの管理

- 資格証明の管理

- キーストアの管理

- 監査データの管理

Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、アプリケーション・ポリシーがセキュリティ・ストアから削除されます。他のツールを使用してアプリケーションをアンデプロイする場合は、そのポリシーを手動で削除する必要があります。

資格証明は、アプリケーションをアンデプロイしても削除されません。

関連項目:

第9.6項「Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成」

第10.3.1項「アプリケーション・ポリシーの管理」

第10.3.2項「アプリケーション・ロールの管理」

第10.3.3項「システム・ポリシーの管理」

第11.3項「Fusion Middleware Controlを使用した資格証明の管理」

第12.2項「Fusion Middleware Controlを使用したキーストアの管理」

第14.2項「監査ストアの管理」

6.4 標準Java EEアプリケーションのデプロイ

OPSSを使用せずにJavaの標準認可を使用するJava EEアプリケーションを保護するには、WebLogic Server管理コンソールまたはWLSTコマンドを使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。

WebLogic ServerにデプロイしたJava EEアプリケーションはWebLogicリソースとなるため、他のWebLogicリソースの場合と同じ方法で、アプリケーションにセキュリティを設定します。

関連項目:

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の次の各項

- アプリケーション・リソース

- WebアプリケーションおよびEJBリソースの保護のオプション

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次の項

- ロールとポリシーを使用したリソースの保護

『Oracle WebLogic Server WebLogic Webサービスの保護』の次の項

- Webサービス・セキュリティの概要

『WebLogicセキュリティ・サービスによるアプリケーションの開発』の次の各項

- Webアプリケーションの保護。特に、Webアプリケーションでの宣言セキュリティの使用に関する項

- Enterprise JavaBeans (EJB)の保護

- Javaセキュリティを使用したWebLogicリソースの保護

6.5 監査対応アプリケーションのデプロイ

監査対応コンポーネントとは、Oracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)と統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントのことです。

このフレームワークを使用するには、デプロイ時にアプリケーションを登録する必要があります。

登録

アプリケーションEARファイルにパッケージ化されたOPSSデプロイメント・ディスクリプタ・ファイルで監査登録パラメータを構成します。ファイルは、アプリケーションのデプロイ時に監査登録によって自動的に処理されます。

パッケージ要件

次の構成ファイルは、アプリケーションEARファイルにパッケージ化します。

- アプリケーションの監査可能イベントを記述するイベント定義ファイル

- ローカライズ可能な要素が含まれる翻訳ファイル

関連項目:

「監査データの移行」

第22.2項「監査定義ファイルの作成」

第22.3項「サービスへのアプリケーションの登録」

第13章「Oracle Fusion Middleware監査フレームワークの概要」

6.6 テスト環境から本番環境への移行

次の推奨事項は、Oracle ADFアプリケーション、サービス指向アーキテクチャ(SOA)アプリケーション、Oracle WebCenterアプリケーションなどのJava Authorization and Authentication Services (JAAS)認可を使用するJava EEアプリケーションに当てはまりますが、標準認可を使用するJava EEアプリケーションには当てはまりません。

アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlであるため、ユーザーは、LDAPリポジトリでスキーマをシードするパーミッションなど、適切なパーミッションを持っている必要があります。

本番環境ではファイル・セキュリティ・ストアは推奨されません。

本番環境への移行では、次を実行します。

- アイデンティティの移行

- ポリシーおよび資格証明の移行

- 監査データの移行

- migrateSecurityStoreを使用した鍵および証明書の移行

6.6.1 アイデンティティの移行

テスト環境での認証プロバイダの構成は、本番環境で複製する必要があります。この場合のタスクとして、次のものが考えられます。

- WebLogic Server管理コンソールを使用した認証プロバイダの構成とユーザーおよびグループのプロビジョニング。

- テスト環境で使用される特定のプロバイダ構成の本番環境での設定。

6.6.1.1 migrateSecurityStoreを使用したアイデンティティの移行

たとえば、ファイル・アイデンティティ・ストアを使用するテスト環境からLDAPアイデンティティ・ストアを使用する本番環境に移行する場合、migrateSecurityStore WLSTコマンドを使用してソース・リポジトリからターゲット・リポジトリにアイデンティティ・データを移行します。

このコマンドは実行中のサーバーに接続しなくても動作します。configFile引数に渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するだけです。

アイデンティティを移行するには、次のいずれかを使用します。

migrateSecurityStore -type idStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-dstLdifFile LdifFileLocation]
[-overwrite trueOrfalse]

migrateSecurityStore(type="idStore",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext",
[dstLdifFile="LdifFileLocation"]
[,overwrite="trueOrfalse"])

説明:

- configFileでは、jps-config.xml構成ファイルの相対パスまたは絶対パスを指定します。

- srcでは、configFile引数に渡す構成ファイルで、ソース・ストアを指定しているコンテキストの名前を指定します。組込みLDAPサーバーをソース・ストアにすることはできません。

- dstでは、configFile引数に渡す構成ファイルで、ターゲット・ストアを指定している別のコンテキストの名前を指定します。ターゲット・ストアはLDAPである必要があります。サポートされているタイプのリストは、第3.2.2項「アイデンティティ・ストア・タイプとWebLogic認証プロバイダ」を参照してください。

- dstLdifFileでは、作成したLDAPデータ交換形式(LDIF)ファイルの相対パスまたは絶対パスを指定します。ターゲット・ストアがLDAPである場合にのみ適用されます。LDIFファイルはLDAPサーバーにはインポートされず、手動による編集が必要であることに注意してください。

- overwriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。ターゲット・データを上書きする場合はtrueに設定します。ターゲット・データを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

srcおよびdstに渡すコンテキストは、構成ファイルで定義し、名前が一意である必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

生成されたLDIFファイルでのパスワードはすべて文字列weblogicに設定され、ターゲットがLDAPの場合は文字列changeに設定されます。LDIFファイルをターゲットLDAPストアにインポートする前に、これらのパスワードを実際のパスワードに変更します。

6.6.2 ポリシーおよび資格証明の移行

本番環境では、セキュリティ・ストアをLDAPストアまたはDBストアに再関連付けすることをお薦めします。

この項では、アプリケーションのデプロイ時にポリシーおよび資格証明を移行する方法について説明します。デプロイ後のセキュリティ・データの移行の詳細は、「migrateSecurityStoreを使用したポリシーの移行」および「migrateSecurityStoreを使用した資格証明の移行」を参照してください。

アプリケーションのホット・デプロイを行う場合、セキュリティ・ストアにそのアプリケーションと同じ名前のストライプが含まれていない場合にかぎり、jazn-data.xmlファイルのデータのセキュリティ・ストアへの移行が実行されます。特に、アプリケーションのホット・デプロイを再実行する場合、jazn-data.xmlファイルに加えられた変更はセキュリティ・ストアに移行されません。

WebLogic Serverにデプロイしたすべてのアプリケーションについて、(アプリケーション移行に関する特定の設定に関係なく)ポリシーおよび資格証明の移行を無効にするには、システム・プロパティjps.deployment.handler.disabledをtrueに設定します。

移行時にGUIDを保持するには、jps.approle.preserveguidパラメータを設定します。

アプリケーションをテスト環境から本番環境に移行する際、次の点を把握していることがきわめて重要です。

アプリケーションEARファイルにパックしたポリシーまたは資格証明がテスト環境で変更されているかどうか

これを踏まえて、アプリケーションを本番環境にデプロイするには、次の手順を実行します。

1. Fusion Middleware Controlで次のオプションを使用して、アプリケーションEARファイルを本番環境にデプロイします。

- ポリシー(アプリケーションまたはシステム)がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション・ポリシー移行」領域で「無視」を選択して、デプロイ時にポリシーを移行するオプションを無効にします。それ以外の場合は、「追加」を選択します。
テスト環境でアプリケーション・ロールのマッピングが変更されている場合でも、「追加」を選択し、同時に「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」を選択できます。この組合せを選択した場合、アプリケーション・ポリシーは移行されますが、テスト用のエンタープライズ・グループへのマッピングは無視されます。後で、アプリケーション・ロールを本番用のエンタープライズ・グループに再マップする必要があります。

- 資格証明がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション資格証明移行」領域で「無視」オプションを選択して、デプロイ時に資格証明を移行するオプションを無効にします。それ以外の場合は、「追加」を選択します。

2. migrateSecurityStoreコマンドを使用して、変更済のデータを移行します。

- アプリケーション・ポリシーの移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPにアプリケーション・ポリシーおよびシステム・ポリシーを移行します。手順の詳細は、「migrateSecurityStoreを使用したポリシーの移行」の例を参照してください。

- アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。手順の詳細は、「migrateSecurityStoreを使用した資格証明の移行」の例を参照してください。

3. 必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。

4. Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であること、特にテスト用のパスワードと本番用のパスワードを確認します。必要な場合は、本番用のデータを適宜変更します。

6.6.2.1 migrateSecurityStoreを使用したポリシーの移行

デフォルトでは、migrateSecurityStoreコマンドによってGUIDが再作成されるため、大量のポリシーを移行するのに長時間を要することがあります。したがって、テスト環境から本番環境への移行時には、一括操作を使用する代替手順によるポリシーおよび資格証明の移行を検討してください。セキュリティ・ストアのバックアップの詳細は、第7.6.2項「LDAPセキュリティ・ストアのバックアップとリカバリ」を参照してください。

migrateSecurityStoreを使用してポリシーを移行するには、ソースおよびターゲットが指定された構成ファイルをアセンブルします。

次に示すt2p-policies.xmlという構成ファイルの完全な例は、LDAP、データベースおよびファイルの各リポジトリ内のポリシー・ソースの指定と、LDAPおよびDBのリポジトリ内のポリシー・ターゲットの指定を示しています。

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">

<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE">
<description>XML-based policy store provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="ldap.policystore.provider" type="POLICY_STORE">
<property value="OID" name="policystore.type"/>
<description>LDAP policy store provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="db.policystore.provider" type="POLICY_STORE">
<property value="DB_ORACLE" name="policystore.type"/>
<description>DB policy store provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<!-- Source XML-based policy store instance -->
<serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml.source">
<description>Replace location with the full path of the folder where the system-jazn-data.xml is located in the source file system </description>
</serviceInstance>

<!-- Source LDAP policy store instance -->
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source LDAP directory structure; B. OID with OVD,
if your source LDAP is OVD; C. ldap://mySourceHost.com:3060 with the URL
and port number of your source LDAP</description>
<property value="OID" name="policystore.type"/>
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
</serviceInstance>

<!-- Source DB policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.source">
<description>Replace: mySourceDomain and mySourceRootName to appropriate
values according to your source DB policy store structure
</description>
<property value="DB_ORACLE" name="policystore.type"/>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@mySourceHost.com:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the source
datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="mySourceKeyName" />
<property name="bootstrap.security.principal.map" value="mySourceMapName" />
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- target LDAP policy store instance -->
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. OID with OVD, if your target LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your target LDAP</description>
<property value="OID" name="policystore.type"/>
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://myDestHost.com:3060" name="ldap.url"/>
</serviceInstance>

<!-- target DB policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values
according to your target DB policy store structure</description>
<property value="DB_ORACLE" name="policystore.type"/>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@myDestHostcom:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the target datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="myDestKeyName" />
<property name="bootstrap.security.principal.map" value="myDestMapName" />
<!-- the value of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the value entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- Bootstrap credentials to access source and target LDAPs or DBs-->
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
<description>Replace location with the full path of the directory where the cwallet.sso file is located; typically found in targetDomain/config/fmwconfig/</description>
</serviceInstance>
</serviceInstances>

<jpsContexts>
<jpsContext name="XMLsourceContext">
<serviceInstanceRef ref="policystore.xml.source"/>
</jpsContext>

<jpsContext name="LDAPsourceContext">
<serviceInstanceRef ref="policystore.ldap.source"/>
</jpsContext>

<jpsContext name="DBsourceContext">
<serviceInstanceRef ref="policystore.db.source"/>
</jpsContext>

<jpsContext name="LDAPtargetContext">
<serviceInstanceRef ref="policystore.ldap.target"/>
</jpsContext>

<jpsContext name="DBtargetContext">
<serviceInstanceRef ref="policystore.db.target"/>
</jpsContext>

<!-- Do not change the name of the next context -->
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.credstore"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

LDAPおよびDBのストアが移行対象となっているため、cwallet.ssoブートストラップ資格証明ファイルが格納されているディレクトリを指定するbootstrap_credstore_contextというコンテキストがファイルに含まれていることに注意してください。さらに、例のマップ名とキー名の各ペアに対して、次のようにaddBootStrapCredential WLSTコマンドを使用して対応するブートストラップ資格証明を指定する必要があります。

wls:/offline> addBootStrapCredential(jpsConfigFile='jps-config.xml',
map='myMapName', key='myKeyName', username='myUserName',
password='myPassword')

myUserNameおよびmyPassawordには、ターゲット・データベースにアクセスするユーザー・アカウントの名前とパスワードを指定します。

使用例

migrateSecurityStoreの使用方法を示す後述の例は、次の点を前提としています。

- コマンドが実行されるターゲット・システムのディレクトリにt2p-policies.xmlファイルが格納されています。

- テスト環境と本番環境で、LDAPまたはDBシステム・ポリシーのディレクトリ構造が同じです。異なる場合は、本番環境のシステム・ポリシー・ディレクトリを、テスト環境の対応する構造に合せて手動で再構築してからコマンドを使用します。

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="policyStore",
configFile="t2p-policies.xml",
src="LDAPsourceContext",
dst="LDAPtargetContext")

テスト用(ソース)のファイル・ストアから本番用(ターゲット)のLDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="policyStore",
configFile="t2p-policies.xml",
src="XMLsourceContext",
dst="LDAPtargetContext")

テスト用(ソース)のDBストアから本番用(ターゲット)のDBストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="policyStore",
configFile="t2p-policies.xml",
src="DBsourceContext",
dst="DBtargetContext")

6.6.2.2 migrateSecurityStoreを使用した資格証明の移行

migrateSecurityStoreコマンドによってGUIDが再作成されるため、大量の資格証明を移行するのに長時間を要することがあります。したがって、テスト環境から本番環境への移行時には、一括操作を使用する代替手順によるポリシーおよび資格証明の移行を検討してください。ストアのバックアップの詳細は、第7.6.2項「LDAPセキュリティ・ストアのバックアップとリカバリ」を参照してください。

migrateSecurityStoreを使用して資格証明を移行するには、ソースおよびターゲットが指定された構成ファイルをアセンブルします。

次に示すt2p-credentials.xmlという構成ファイルの完全な例は、LDAP、DBおよびファイルの各リポジトリ内の資格証明ソースの指定と、LDAPおよびDBのリポジトリ内の資格証明ターゲットの指定を示しています。

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">

<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE">
<description>File credential provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE">
<description>LDAP credential provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider" name="db.credentialstore.provider" type="CREDENTIAL_STORE">
<description>DB credential provider</description>
</serviceProvider>

</serviceProviders>

<serviceInstances>
<!-- Source file credential store instance -->
<serviceInstance location="myFileBasedCredStoreLocation" provider="credstoressp" name="credential.file.source">
<description>Replace location with the full path of the folder where the file source credential store cwallet.sso is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
</serviceInstance>

<!-- Source LDAP credential store instance -->
<serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source LDAP directory structure; B. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description>
<property value="bootstrap" name="bootstrap.security.credential.key"/>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
</serviceInstance>

<!-- Source DB credential store instance -->
<serviceInstance provider="db.credentialstore.provider" name="credential.db.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source DB credential store</description>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@mySourceHost:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the source datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="mySourceKeyName" />
<property name="bootstrap.security.principal.map" value="mySourceMapName" />
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- target LDAP credential store instance -->
<serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your target LDAP</description>
<property value="bootstrap" name="bootstrap.security.credential.key"/>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://myDestHost.com:3060" name="ldap.url"/>
</serviceInstance>

<!-- target DB credential store instance -->
<serviceInstance provider="db.credentialstore.provider" name="credential.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your target DB credential store</description>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@myDestHost.com:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the target datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="myDestKeyName" />
<property name="bootstrap.security.principal.map" value="myDestMapName" />
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- Bootstrap credentials to access source and target LDAPs and DBs -->
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
<description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in targetDomain/config/fmwconfig/</description>
</serviceInstance>
</serviceInstances>

<jpsContexts>
<jpsContext name="FileSourceContext">
<serviceInstanceRef ref="credential.file.source"/>
</jpsContext>

<jpsContext name="LDAPsourceContext">
<serviceInstanceRef ref="credential.ldap.source"/>
</jpsContext>

<jpsContext name="DBsourceContext">
<serviceInstanceRef ref="credential.db.source"/>
</jpsContext>

<jpsContext name="LDAPtargetContext">
<serviceInstanceRef ref="credential.ldap.target"/>
</jpsContext>

<jpsContext name="DBtargetContext">
<serviceInstanceRef ref="credential.db.target"/>
</jpsContext>

<!-- Do not change the name of the next context -->
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.credstore"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

LDAPまたはDBのストアが移行対象となっているため、cwallet.ssoブートストラップ資格証明ファイルが格納されているディレクトリを指定するbootstrap_credstore_contextというコンテキストがファイルに含まれていることに注意してください。

使用例

次に示すmigrateSecurityStoreの使用例では、コマンドが実行されるターゲット・システムのディレクトリにt2p-credentials.xmlファイルが格納されていることを前提とします。

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="credStore",
configFile="t2p-credentials.xml",
src="LDAPsourceContext",
dst="LDAPtargetContext")

テスト用(ソース)のファイル・ストアから本番用(ターゲット)のLDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="credStore",
configFile="t2p-credentials.xml",
src="FileSourceContext",
dst="LDAPtargetContext")

テスト用(ソース)のDBストアから本番用(ターゲット)のDBストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="credStore",
configFile="t2p-credentials.xml",
src="DBSourceContext",
dst="DBtargetContext")

6.6.3 監査データの移行

監査データは、コンポーネント・イベント定義、属性表マッピングおよび監査ポリシーで構成されており、この情報は監査ストアにあります。

次の構文でmigrateSecurityStore WLSTコマンドを使用し、ソース・リポジトリとターゲット・リポジトリ間で監査データを移行します。

migrateSecurityStore(type="auditStore",
configFile="jps_config_file_location",
src="sourceContext",
dst="targetContext"
[,overWrite="{true|false}"])

説明:

- configFileでは、構成ファイルの絶対パスまたは相対パスによる場所を指定します。この構成ファイルは移行用にのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのコンテキストが含まれます。

- srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。これはソース・データ・ストアです。

- dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。これはターゲット・データ・ストアです。

- overWriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。常にデータを上書きする場合はtrueに設定します。特定の条件を満す場合を除いてデータを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。次のことに留意してください:

- システム定義はフラグの値にかかわらず上書きされません。

- overwriteがtrueの場合、ターゲット・ストアのコンポーネント定義はソース・ストアの定義で置き換えられます。

- overwriteがfalseの場合、ソース・ストアおよびターゲット・ストアのコンポーネント定義のバージョンが比較されます。メジャー・バージョンが同じで、ソース・コンポーネント定義のマイナー・バージョンの方が高い場合、ターゲット・ストアのコンポーネント定義はソース・ストアの定義で置き換えられます。そうでない場合、上書きはスキップされます。

6.6.4 migrateSecurityStoreを使用した鍵および証明書の移行

鍵および証明書は、次の2つの異なるシナリオで移行します。

- ソースおよびターゲットのキーストアが同じドメインにある場合(ソースおよびターゲットのキーストアで同じ暗号化鍵が使用される場合)。

- ソースおよびターゲットのキーストアが異なるドメインにある場合(ソースおよびターゲットのキーストアで異なる暗号化鍵が使用される場合)。

次の各項では、これらのシナリオでの鍵の移行について説明します。

- 同じドメイン内での鍵および証明書の移行

- 異なるドメイン間での鍵および証明書の移行

6.6.4.1 同じドメイン内での鍵および証明書の移行

両方のストアが同じドメイン内にある場合に、鍵および証明書をmigrateSecurityStoreを使用して移行するには、構成ファイルを作成してソースおよびターゲットのサービス・インスタンスを指定し、migrateSecurityStoreを使用します。キーストアが同じドメイン内にある場合、ソースおよびターゲットのコンテキストを指定するのに1つの構成ファイルで十分です。

次の例では、LDAP、DBおよびファイルのストア内のキーストア・ソースと、LDAPおよびDBのストア内のキーストア・ターゲットを指定する方法を示します。

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">

<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE">
<description>File credential provider</description>
</serviceProvider>

<!-- provider for file, LDAP, and DB keystores -->
<serviceProvider type="KEY_STORE" name="keystore.provider" class="oracle.security.jps.internal.keystore.KeyStoreProvider">
<description>PKI Based Keystore Provider</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>

<!-- Source XML-based keystore instance -->
<serviceInstance location="./" provider="keystore.provider" name="keystore.file.source">
<property name="keystore.provider.type" value="file"/>
<property name="keystore.file.path" value="./"/>
<description>Replace keystore.file.path with the full path of the folder where the file source keystore keystores.xml is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
</serviceInstance>

<!-- Source LDAP keystore instance -->
<serviceInstance provider="keystore.provider" name="keystore.ldap.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source LDAP directory structure; B. ldap://mySourceHost.com:3060 with the URL and port number of your source LDAP</description>
<property value="bootstrap" name="bootstrap.security.credential.key"/>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://mySourceHost.com:3060" name="ldap.url"/>
<property name="keystore.provider.type" value="ldap"/>
</serviceInstance>

<!-- Source DB keystore instance -->
<serviceInstance provider="keystore.provider" name="keystore.db.source">
<description>Replace: A. mySourceDomain and mySourceRootName to appropriate
values according to your source DB </description>
<property value="cn=mySourceDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=mySourceRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@mySourceHost:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the source datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="mySourceKeyName" />
<property name="bootstrap.security.principal.map" value="mySourceMapName" />
<property name="keystore.provider.type" value="db"/>
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- target LDAP keystore instance -->
<serviceInstance provider="keystore.provider" name="keystore.ldap.target">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your target LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your target LDAP</description>
<property value="bootstrap" name="bootstrap.security.credential.key"/>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://myDestHost.com:3060" name="ldap.url"/>
<property name="keystore.provider.type" value="ldap"/>
</serviceInstance>

<!-- target DB keystore instance -->
<serviceInstance provider="keystore.provider" name="keystore.db.target">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your target DB </description>
<property value="cn=myDestDomain" name="oracle.security.jps.farm.name"/>
<property value="cn=myDestRootName" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc:oracle:thin:@myDestHost.com:1722:orcl" name="jdbc.url"/>
<!-- the value of jdbc.url should be the value entered when the target datasource was set up -->
<property value="oracle.jdbc.driver.OracleDriver" name="jdbc.driver"/>
<property name="bootstrap.security.principal.key" value="myDestKeyName" />
<property name="bootstrap.security.principal.map" value="myDestMapName" />
<property name="keystore.provider.type" value="db"/>
<!-- the values of bootstrap.security.principal.key and
bootstratp.security.principal.map
should be the values entered when the bootstrap credential was set up -->
</serviceInstance>

<!-- Bootstrap credentials to access source and target LDAPs and DBs -->
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.credstore">
<description>Replace location with the full path of the directory where the bootstrap file cwallet.sso is located; typically found in targetDomain/config/fmwconfig/bootstrap</description>
</serviceInstance>
</serviceInstances>

<jpsContexts>
<jpsContext name="FileSourceContext">
<serviceInstanceRef ref="keystore.file.source"/>
</jpsContext>

<jpsContext name="LDAPsourceContext">
<serviceInstanceRef ref="keystore.ldap.source"/>
</jpsContext>

<jpsContext name="DBsourceContext">
<serviceInstanceRef ref="keystore.db.source"/>
</jpsContext>

<jpsContext name="LDAPtargetContext">
<serviceInstanceRef ref="keystore.ldap.target"/>
</jpsContext>

<jpsContext name="DBtargetContext">
<serviceInstanceRef ref="keystore.db.target"/>
</jpsContext>

<!-- Do not change the name of the next context -->
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.credstore"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

LDAPまたはDBのストアが移行対象となっているため、cwallet.ssoブートストラップ資格証明ファイルの場所を指定するbootstrap_credstore_contextコンテキストがファイルに含まれていることに注意してください。

使用例

次に示す例では、コマンドが実行されるターゲット・システムのディレクトリにt2p-keys.xmlファイルが格納されていることを前提とします。

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアに鍵および証明書をすべて移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="keyStore",
configFile="t2p-keys.xml",
src="LDAPsourceContext",
dst="LDAPtargetContext")

テスト用(ソース)のファイル・ストアから本番用(ターゲット)のLDAPストアに鍵および証明書をすべて移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="keyStore",
configFile="t2p-keys.xml",
src="FileSourceContext",
dst="LDAPtargetContext")

テスト用(ソース)のデータベース・ストアから本番用(ターゲット)のデータベース・ストアに、特定のアプリケーション・ストライプに対する鍵および証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="stripeKeyStore",
configFile="t2p-keys.xml",
src="DBSourceContext",
dst="DBtargetContext",
srcStripe="application1",
dstStripe="application2")

6.6.4.2 異なるドメイン間での鍵および証明書の移行

ソースおよびターゲットのキーストアが異なるドメインにある場合にキーストア・データを移行するには、キーストアの暗号化に使用する暗号化鍵が異なるため、2つの異なる構成ファイルが必要です。したがって、ブートストラップ資格証明ストアは異なる必要があります。

migrateSecurityStore WLSTコマンドを使用する場合は、次に留意してください。

- 構成ファイル内のソース・キーストアのコンテキストをsrcConfigFileパラメータに指定します。

- 構成ファイル内のターゲット・キーストアのコンテキストをconfigFileパラメータに指定します。

使用例

テスト用(ソース)のLDAPストアから本番用(ターゲット)のLDAPストアに鍵および証明書をすべて移行するには、ターゲット・システムで次のようにmigrateSecurityStoreをコールします。

>migrateSecurityStore(type="keyStore",
srcConfigFile="/source_domain/config/fmwconfig/jps-config.xml",
configFile="/target_domain/config/fmwconfig/jps-config.xml",
src="ksSrc",
dst="ksDst")

第III部

OPSSサービス

この部は、次の章で構成されています。

- 第8章「アイデンティティ・ストアの構成」

- 第9章「セキュリティ・ストアの構成」

- 第10章「ポリシーの管理」

- 第11章「資格証明の管理」

- 第12章「鍵と証明書の管理」

- 第13章「Oracle Fusion Middleware監査フレームワークの概要」

- 第14章「監査の管理」

- 第15章「監査分析と監査レポートの使用」

7 セキュリティ・アーティファクトのライフ・サイクル

この章では、WebLogic Serverドメインの作成または拡張時に、アプリケーションでセキュリティ・ストアにシードすることを指定できるセキュリティ・アーティファクトについて説明します。また、セキュリティ・ストアをリリース12.2.1にアップグレードする手順についても説明します。

この章の内容は次のとおりです。

- セキュリティ・アーティファクトのシード方法

- Fusion Middlewareドメインについて

- FMWドメインの作成

- 階層型コンポーネントのセキュリティ・アーティファクト

- セキュリティの12.2.1へのアップグレード

- セキュリティ・ストアのバックアップとリカバリ

- コンポーネントの監査定義の12cへのアップグレード

7.1 セキュリティ・アーティファクトのシード方法

11gドメインでは、デプロイメント・ディスクリプタが適切に設定されている場合、製品固有のセキュリティ・アーティファクトの指定はアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにバンドルされ、それらのアーティファクトはアプリケーションのデプロイ時にセキュリティ・ストアに移行されます。

12cドメインでは、製品固有のセキュリティ・アーティファクトの指定は、それらのアーティファクトをドメインの作成時にセキュリティ・ストアにシードする手段となる製品テンプレートで構成されます。

関連項目:

階層型コンポーネントのセキュリティ・アーティファクト

7.2 Fusion Middlewareドメインについて

FMWドメインは、Java Required Files (JRF)テンプレートを使用して作成または拡張されたドメインです。テンプレートにより、セキュリティ・ストアのアーティファクトのプロビジョニングが指定されます。具体的には、次のものが作成されます。

- OPSSセキュリティ・アーティファクト。

- 暗号化鍵でシードされるcwallet.ssoブートストラップ・ファイル。

- キーストア(トラストストア、デモ・キーストア、Oracle WebLogic Serverで使用されるドメイン・アイデンティティ・キーストアを含む)。

- トラストストアに接続されたトラスト・サービス。

- 3つのデータ・ソース: OPSSスキーマ、OPSS監査ビューア・スキーマ、OPSS監査追加スキーマそれぞれに1つずつ。

- データベース・セキュリティ・ストアおよび監査ストアの構成。

JRFテンプレートでは、管理対象サーバーは作成されません。FMWドメインでは、すべてのリソースが管理サーバーにのみターゲット設定されます。後で管理対象サーバーをドメインに追加する場合は、リソースがその管理対象サーバーにもターゲット設定されるようにapplyJRFをコールする必要があります。

ドメイン再構成後にOPSSおよび監査データ・ソースを管理対象サーバーにターゲット設定するには、applyJRF WebLogic Scripting Tool (WLST)コマンドを使用します。

関連項目:

階層型コンポーネントのセキュリティ・アーティファクト

『Oracle Fusion Middlewareインフラストラクチャ・コンポーネントWLSTコマンド・リファレンス』のapplyJFRに関する項

7.3 FMWドメインの作成

本番用のFMWドメインにはDBセキュリティ・ストアが必要です。データベースは、新しいデータベースでも、他のFMWドメインに関連付けられたデータベースでもかまいません。

次の各項では、FMWドメインの作成方法について説明します。

- 新しいデータベース・インスタンスの使用

- データベース・インスタンスの共有

7.3.1 新しいデータベース・インスタンスの使用

新しいデータベースに関連付けられたFMWドメインを作成または拡張するには、次の手順を実行します。

1. 新しいデータベース・スキーマを作成します。DBセキュリティ・ストアの詳細は、第9.3.1項「DBセキュリティ・ストアを使用する場合の前提条件」を参照してください。

2. 『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』の第5章「構成ウィザード画面」で説明されているように、Fusion Middleware構成ウィザードを使用してドメインを作成または拡張します。
このタスクでは、手順1で作成したデータベース・スキーマなど、使用するデータベース・スキーマに関する情報を指定したり、JFRテンプレートの使用を選択します。作成したドメインに関連付けるデータベース・スキーマは新しいスキーマである必要があります。

JRFテンプレートを使用すると、3つのデータ・ソース(OPSSスキーマ、OPSS監査ビューア・スキーマ、OPSS監査追加スキーマそれぞれに1つずつ)が自動的に作成されます。

関連項目:

『Oracle Fusion Middlewareドメイン・テンプレート・リファレンス』のテンプレート・ツールに関連する項

「Fusion Middlewareドメインについて」

7.3.2 データベース・インスタンスの共有

次の手順では、WLSTコマンドのみを使用します。ドメイン・データベースに関連付けられたFMWドメインを作成または拡張するには、次の手順を実行します。

1. domain1ドメインで(他のドメインを結合する)db1データベースを使用しているとした場合、exportEncryptionKeyコマンドを使用して、domain1ドメインから指定された場所に暗号化鍵をエクスポートします。

exportEncryptionKey(location, password)

2. 次のようなスクリプトを使用して、db1データベースを共有するドメインを作成します。

## arg1 - wls.jar loc
## arg2 - jrf.jar loc
## arg3 - domain home
## arg4 - adminserver port
## arg5 - Db host
## arg6 - db port
## arg 7 - DB service name (pdb)
## arg8 - STB schema user,

readTemplate(sys.argv[1],"Expanded")
cd('/Security/base_domain/User/weblogic')
cmo.setName('weblogic')
cmo.setPassword('welcome1')
writeDomain(sys.argv[3])
closeTemplate()

#Set AdminServer Port
readDomain(sys.argv[3])
cd('/Servers/AdminServer')
set('ListenAddress','')
set('ListenPort', int(sys.argv[4]))
updateDomain()
closeDomain()

readDomain(sys.argv[3])
addTemplate(sys.argv[2])

cd('/JDBCSystemResource/LocalSvcTblDataSource/JdbcResource/LocalSvcTblDataSource')
cd('JDBCDriverParams/NO_NAME_0')
set('DriverName','oracle.jdbc.OracleDriver')
set('PasswordEncrypted', 'myPassw')
set('URL','jdbc:oracle:thin:@'+sys.argv[5]+':'+sys.argv[6]+'/'+sys.argv[7])
set('UsePasswordIndirection', 'false')
set('UseXADataSourceInterface', 'false')
create('myProps','Properties')
cd('Properties/NO_NAME_0/Property/user')
cmo.setValue(sys.argv[8])

getDatabaseDefaults()

setSharedSecretStoreWithPassword(location, password)
updateDomain()

locationおよびpasswordの値は、exportEncryptionKeyコマンドへのコールで使用した値と同じです。

3. スクリプトを実行して、domain1および新しいドメイン内のサーバーをすべて起動します。どちらのドメインも同じセキュリティ・ストアを共有しています。

注意:
スクリプトからsetSharedSecretStoreWithPasswordで始まる行を削除すると、domain1などのFMWドメインの作成に使用できることがあります。

関連項目:

『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyに関する項

7.4 階層型コンポーネントのセキュリティ・アーティファクト

セキュリティ・アーティファクトのシードおよび処理を簡略化するには、ドメインの作成または拡張時に、OPSSを使用するコンポーネントによってテンプレートが指定される必要があります。このテンプレートは、コンポーネントの実行に必要な、コンポーネントのみに固有のアーティファクトを定義およびバンドルし、表7-1に示すファイルを含みます。

表7-1 OPSSで使用されるコンポーネント・テンプレートのファイル

ファイル名

説明

テンプレートのルート・フォルダからの場所

component-security-info.xml

必須。セキュリティ・アーティファクトのライフ・サイクルを指定します。

./security/component-security-info.xml

jazn-data.xml

オプション。ポリシーを指定します。

./security/authorization/jazn-data.xml

keystore.xml

オプション。キーストアのメタデータを指定します。

./security/keystore/keystore.xml

credentials.xml

オプション。コンポーネントで使用される資格証明メタデータを指定します。

./security/credential/credentials.xml

component_events.xml

オプション。監査データを指定します。

./security/audit/component_events.xml

component_events_xlf.jar

オプション。ローカライズされた監査データを指定します。

./security/audit/component_events_xlf.jar

製品テンプレートにバンドルされたOPSSセキュリティ・アーティファクトには、アーティファクトの処理方法を指定するcomponent-security-info.xmlファイルが必要です。

7.5 セキュリティの12.2.1へのアップグレード

次の各項では、セキュリティ・アーティファクトをリリース11.1.1.6、11.1.1.7、11.1.1.9、12.1.2または12.1.3からリリース12.2.1にアップグレードする方法について説明します。

- セキュリティ・ストアをアップグレードする前に

- Oracle Fusion Middlewareアップグレード・アシスタントを使用した準備状況のチェック

- セキュリティのアップグレード: 主な手順

- リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成

- アップグレード・アシスタントを使用したスキーマのアップグレード

- アップグレード・アシスタントを使用したスキーマのアップグレード

- Fusion Middleware再構成ウィザードを使用したドメインの再構成

- 共有セキュリティ・ストアのアップグレード

アップグレード後のシステムでは、古いデータ・ソースを使用せず、新しく作成されたデータ・ソースのみを使用します。11gからアップグレードすると、重複するOPSSデータ・ソースが表示されることがありますが、一方はアップグレード前から存在し、もう一方はアップグレードによって作成されたものです。この重複は機能的に影響することはなく、古いデータ・ソースはアップグレード後のシステムで使用されません。

アップグレード後に、キーストアをJavaキーストア(JKS)からキーストア・サービス(KSS)キーストアに移行することを検討してください。12.2.1にアップグレードしたドメインでは、systemストライプのKSSキーストアは以前のリリースのものとは異なります。証明書の詳細は、第12.4項「証明書について」を参照してください。

7.5.1 セキュリティ・ストアをアップグレードする前に

セキュリティ・ストアをアップグレードする前に、アップグレードに失敗した場合にリカバリできるようバックアップを作成します。バックアップの詳細は、「セキュリティ・ストアのバックアップとリカバリ」を参照してください。

7.5.2 Oracle Fusion Middlewareアップグレード・アシスタントを使用した準備状況のチェック

この項に記載されている手順を実行して、FMWの古いバージョンがリリース12.2.1.0.0へのアップグレードに適しているかどうかを判断します。次の手順ではアップグレードは実行されません。

1. アップグレード・アシスタントを起動します。

> cd oracle_common/upgrade/bin
> ./ua-readiness

2. 左側のペインで「選択したスキーマ」をクリックします。

3. 「選択したスキーマ」ページで、「個別に選択されたスキーマ」を選択して「次」をクリックします。

4. 「使用可能なコンポーネント」ページで、「Oracle Platform Security Services」を選択して「次」をクリックします。

5. 「ドメイン・ディレクトリ」で、ドメインのディレクトリを入力します。

6. 必要に応じて、IAUスキーマおよびOPSSスキーマの情報を入力します。

7. 左側のペインで「準備状況サマリー」をクリックします。「準備状況サマリー」ページに、チェック対象のスキーマの詳細が表示されます。

8. 「次」をクリックします。「準備状況チェック」ページに、チェックの進行状況および最終ステータスが表示されます。
エラーがレポートされた場合は、ログ出力を確認します。問題が12.2.1へのアップグレードで修正されることがログに示されている場合は、そのエラーを無視します。

9. 「準備状況成功」ページに、チェック結果が表示されます。

7.5.3 セキュリティのアップグレード: 主な手順

次の各表は、セキュリティ・ストアおよび監査ストアのタイプに応じて、システムをアップグレードするために実行する手順をまとめたものです。いずれの手順でも、バイナリが12.2.1 Oracle Fusion Middlewareバイナリにアップグレードされていることを前提としています。

表7-2 12.1.2または12.1.3から12.2.1へのアップグレード

セキュリティ・ストア・タイプ

監査ストア・タイプ

12.2.1へのアップグレード手順

Oracle Internet Directory

DB

1. 12.2.1 Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用してOPSSスキーマを作成します(IAUスキーマも作成されます)。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. ドメインを再構成し、OPSSデータ・ソースを新規作成したOPSSスキーマにバインドします。Fusion Middleware再構成ウィザードで監査スキーマの詳細を入力します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。
この場合、OPSS 12.2.1スキーマと12.2.1 IAUスキーマはいずれも冗長であることに注意してください。

DB

DB

1. 12.2.1リポジトリ作成ユーティリティを使用してOPSSスキーマを作成します(IAUスキーマも作成されます)。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. ドメインを再構成します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。

注意:
12cファイル・セキュリティ・ストアからのアップグレードはサポートされていません。

表7-3 11.1.1.6、11.1.1.7または11.1.1.9から12.2.1からのアップグレード

セキュリティ・ストア・タイプ

監査ストア・タイプ

12.2.1へのアップグレード手順

ファイル

ファイル

1. 12.2.1リポジトリ作成ユーティリティを使用してOPSSスキーマを作成します(IAUスキーマも作成されます)。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. ドメインを再構成し、新しいスキーマの詳細を指定します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。

ファイル

DB

1. 12.2.1リポジトリ作成ユーティリティを使用してOPSSスキーマを作成します(IAUスキーマも作成されます)。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. 11g監査スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. ドメインを再構成して新しいOPSSスキーマの詳細を指定し、Fusion Middleware再構成ウィザードで11g監査スキーマの詳細を入力します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。
この場合、IAU 12.2.1スキーマは冗長であることに注意してください。

Oracle Internet Directory

ファイル

1. 12.2.1リポジトリ作成ユーティリティを使用してOPSSスキーマを作成します。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. OPSSスキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. ドメインを再構成し、OPSSデータ・ソースを新規作成したOPSSスキーマにバインドするために、新しいスキーマの詳細を指定します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。
この場合、12.2.1 OPSSスキーマは冗長であることに注意してください。

Oracle Internet Directory

DB

1. 12.2.1リポジトリ作成ユーティリティを使用してOPSSスキーマを作成します(IAUスキーマも作成されます)。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. 監査スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. ドメインを再構成し、OPSSデータ・ソースを新規作成したOPSSスキーマにバインドします。Fusion Middleware再構成ウィザードで11g監査スキーマの詳細を入力します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。
この場合、OPSS 12.2.1スキーマと12.2.1 IAUスキーマはいずれも冗長であることに注意してください。

DB

ファイル

1. 12.2.1リポジトリ作成ユーティリティを使用してIAUスキーマを作成します。「リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成」を参照してください。

2. 11g OPSSスキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. ドメインを再構成して新しい監査スキーマの詳細を指定し、11g OPSSスキーマの詳細を入力します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。

DB

DB

1. スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

2. ドメインを再構成して、11g OPSSスキーマの詳細を指定します。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。

注意:
11gファイル・セキュリティ・ストアは、DBセキュリティ・ストアに自動的にアップグレードされます。

7.5.4 リポジトリ作成ユーティリティを使用したOPSSスキーマとIAUスキーマの作成

12.2.1リポジトリ作成ユーティリティを実行して、スキーマを作成します。手順の詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』を参照してください。

7.5.5 アップグレード・アシスタントを使用したスキーマのアップグレード

この項に記載されている手順を実行してスキーマをアップグレードします。代替手順の「アップグレード・アシスタントを使用したスキーマのアップグレード」では、少ないユーザー入力で同じ結果になりますが、既存のスキーマが必要となることに注意してください。

1. アップグレード・アシスタントを起動します。

> cd oracle_common/upgrade/bin
> ./ua

2. 左側のペインで「スキーマ」をクリックします。

3. 「スキーマ」ページで、「スキーマ」を選択して「次」をクリックします。

4. 「使用可能なコンポーネント」ページで、「Oracle Platform Security Services」を選択して「次」をクリックします。

5. 「前提条件」ページで、示された前提条件がすべて満たされていることを確認して「次」をクリックします。

6. 必要に応じて、IAUスキーマおよびOPSSスキーマの情報を入力してから、入力内容を確認します。

7. 左側のペインで「アップグレード・サマリー」をクリックします。「アップグレード・サマリー」ページに、アップグレードされるスキーマが表示されます。

8. 「アップグレード」をクリックします。「アップグレードの進行状況」ページに、アップグレードの進行状況および最終ステータスが表示されます。

9. 「アップグレード成功」ページに、アップグレード結果が表示されます。

関連項目:

Oracle Fusion Middleware Upgrade Assistantによるアップグレード

7.5.6 アップグレード・アシスタントを使用したスキーマのアップグレード

ドメイン支援スキーマ・アップグレード(DASU)を使用すると、ドメイン・ディレクトリからスキーマの詳細を自動的にロードできるため、そのようなスキーマの詳細を入力する必要がありません。

この項に記載されている手順を実行して、DASUモードでスキーマをアップグレードします。

1. アップグレード・アシスタントを起動します。

> cd oracle_common/upgrade/bin
> ./ua

2. 左側のペインで「スキーマ」をクリックします。

3. 「スキーマ」ページで、「ドメインで使用されるすべてのスキーマ」を選択してスキーマの詳細のロード元となるドメイン・ディレクトリを入力し、「次」をクリックします。

4. 「コンポーネント・リスト」ページで、コンポーネント・スキーマを表示して「次」をクリックします。

5. 「アップグレードの進行状況」ページに、アップグレードの進行状況および最終ステータスが表示されます。

6. 「アップグレード成功」ページに、アップグレード結果が表示されます。

7.5.7 Fusion Middleware再構成ウィザードを使用したドメインの再構成

この項に記載されている手順を実行し、Fusion Middleware再構成ウィザードを使用してドメインを再構成します。

1. Fusion Middleware再構成ウィザードを起動します。

> cd oracle_common/common/bin
> ./reconfig.sh

2. 「ドメインの選択」ページで、再構成するドメインのディレクトリを指定して「次」をクリックします。

3. 「データベース構成タイプ」ページで「RCUデータ」ラジオ・ボタンを選択し、データベース接続の詳細を入力して「RCU構成の取得」をクリックします。取得結果が表示されます。

4. 「次」をクリックします。

5. 「JDBCコンポーネント・スキーマ」ページに、影響を受けるスキーマの表が表示されます。必要に応じて行を選択し、「次」をクリックします。

6. 「JDBCコンポーネント・スキーマ・テスト」ページで「選択された接続のテスト」をクリックします。テスト結果が表示されます。「次」をクリックします。

7. 「拡張構成」ページで、必要に応じてボックスを選択して「次」をクリックします。

8. 「構成サマリー」に、選択したオプションが表示されます。「再構成」をクリックします。

7.5.8 共有セキュリティ・ストアのアップグレード

複数のドメインが共有(結合)しているセキュリティ・ストアをアップグレードするには、次のタスクのいずれかを実行します。

- 共有している12.1.2または12.1.3セキュリティ・ストアのアップグレード

- 共有している11gセキュリティ・ストアのアップグレード

7.5.8.1 共有している12.1.2または12.1.3セキュリティ・ストアのアップグレード

この項に記載されている手順を実行し、12.1.2または12.1.3の共有しているセキュリティ・ストアを12.2.1にアップグレードします。

1. アップグレードするストアを共有しているドメインをすべて停止します。

2. アップグレード・アシスタントを実行し、共有しているセキュリティ・ストアのOPSSスキーマと、ソース監査データがデータベース・ストアの場合は監査スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. セキュリティ・ストアを共有しているドメインそれぞれで、Fusion Middleware再構成ウィザードを実行してドメインを再構成し、OPSSデータ、ディレクトリ情報ツリーおよび製品のセキュリティ・アーティファクトをアップグレードします。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。

4. セキュリティ・ストアを共有しているドメインをすべて再起動します。

7.5.8.2 共有している11gセキュリティ・ストアのアップグレード

この項に記載されている手順を実行し、11.1.1.6、11.1.1.7または11.1.1.9の共有しているセキュリティ・ストアを12.2.1にアップグレードします。

1. アップグレードするストアを共有しているドメインをすべて停止します。

2. アップグレード・アシスタントを実行し、共有しているセキュリティ・ストアのOPSSスキーマと、ソース監査がデータベース・ストアの場合は監査スキーマをアップグレードします。「アップグレード・アシスタントを使用したスキーマのアップグレード」を参照してください。

3. セキュリティ・ストアを共有しているドメインのそれぞれで、Fusion Middleware再構成ウィザードを実行します。初めて実行すると、セキュリティ・ストアのデータおよびドメインの構成がアップグレードされます。他のドメインから実行すると、そのドメインの構成のみアップグレードされます。「Fusion Middleware再構成ウィザードを使用したドメインの再構成」を参照してください。

4. アップグレードされたドメインをすべて再起動します。

7.6 セキュリティ・ストアのバックアップとリカバリ

この項では、セキュリティ・ストアをバックアップおよびリカバリする方法について説明します。セキュリティ・ストアのバックアップに加えて、次の構成ファイルおよびデータ・ファイルも保存する必要があることに注意してください。

{domain}/Config/config.xml
{domain}/Config/Fmwconfig/jps-config.xml
{domain}/Config/Fmwconfig/jps-config-jse.xml
{domain}/Config/Fmwconfig/cwallet.sso
{domain}/Config/Fmwconfig/keystores.cml
{domain}/Config/Fmwconfig/audit-store.xml
{domain}/Config/Fmwconfig/system-jazn-data.xml
{domain}/Config/Fmwconfig/ids-config.xml
{domain}/Config/Fmwconfig/mbeans/jps_mbeans.xml
{domain}/Config/Fmwconfig/bootstrap/cwallet.sso

この項には次のトピックが含まれます:

- DBセキュリティ・ストアのバックアップとリカバリ

- LDAPセキュリティ・ストアのバックアップとリカバリ

- 推奨事項

注意:
migrateSecurityStore WLSTコマンドを使用して、セキュリティ・データをバックアップおよびリカバリできます。セキュリティ・データをバックアップするには、セキュリティ・データをファイル・ストアに移行します。リカバリするには、ファイル・ストアをターゲット・セキュリティ・ストアに移行します。

関連項目:

『Oracle Fusion Middlewareの管理』のバックアップの実行に関する項

『Oracle Fusion Middlewareの管理』のOracle WebLogic Serverドメインのリカバリに関する項

「アイデンティティの移行」

ポリシーおよび資格証明の移行

「監査データの移行」

「migrateSecurityStoreを使用した鍵および証明書の移行」

7.6.1 DBセキュリティ・ストアのバックアップとリカバリ

この項に記載されている手順では、バックアップ計画およびリカバリの自動化とデータベースの複製に使用するツールであるOracle Database Utility Recovery Manager (RMAN)を使用します。

次の手順を使用してホストAのDBセキュリティ・ストアをホストBのDBセキュリティ・ストアにバックアップします。ホストAのセキュリティ・ストアではjdbc URLがproddbに設定されており、ホストBのセキュリティ・ストアではjdbc URLがtestdbに設定されています。この手順では、ホストBのクローニングされたDBセキュリティ・ストアと連動するようにドメインを設定します。

DBセキュリティ・ストアをバックアップするには、次の手順を実行します。

1. ホストBでtestdbデータベースを設定します。

1. inittestdb.oraファイルを作成して次の行を含めます。

#
db_name=testdb
#

2. testdbをlistener.oraファイルに追加します。
SID_LIST_LISTENER = (SID_LIST=(SID_DESC=(SID_NAME=testdb)(GLOBAL_DBNAME=testdb)(ORACLE_HOME=/ade/b/3882746433/oracle))

3. testdb/proddbをtnsnames.oraファイルに追加します。
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))

testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))

4. リスナーを再起動します。
lsnrctl stop, lsnrctl start

5. nomountモードでpfileを使用して新しいインスタンスを起動します。
$ export ORACLE_SID=testdb

$ sqlplus / as sysdba

SYS@testdb SQL>startup nomount pfile=/scratch/rdbms/dbs/inittestdb.ora

2. RMANを使用してproddbデータベースをtestdbデータベースにクローニングします。

1. testdb/proddbをtnsnames.oraファイルに追加します。
proddb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostA.com)(PORT=XXXX))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME= proddb)))

testdb=(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=myhostB.com)(PORT=YYYY))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=testdb)))

2. proddbデータベースでspfileが使用されていることを確認します。使用されていない場合は、sysdbaユーザーとしてログインしてcreate spfile from pfileを実行し、initファイルからバイナリspfileを生成します。次にサーバーを再起動します。

3. リスナーを再起動します。
lsnrctl stop, lsnrctl start

4. 複製データベース・ファイルの名前を生成する方法を決定します。具体的には、制御ファイル、データ・ファイル、オンラインREDOログ・ファイルおよび一時ファイルに名前を付ける方法を決定します。
たとえば、proddbデータベースでは、ホストAのディレクトリ/oradata/proddbにあるファイルを、ホストBの/oradata/testdbディレクトリに保存する場合は、次の手順で示すように、DB_FILE_NAME_CONVERT /proddb, /testdbを指定します。

RMANを実行してproddbデータベースをtestdbデータベースにクローニングします。

$rman
RMAN> CONNECT TARGET SYS@proddb
RMAN> CONNECT AUXILIARY SYS@testdb
RMAN> DUPLICATE TARGET DATABASE TO testdb
FROM ACTIVE DATABASE
DB_FILE_NAME_CONVERT '/proddb','/testdb'
SPFILE
PARAMETER_VALUE_CONVERT '/proddb','/testdb'
SET LOG_FILE_NAME_CONVERT '/proddb','/testdb';

RMANがエラーなしで完了したことを確認します。

3. ドメインを切り替えて、バックアップしたデータベースをセキュリティ・ストアとして使用することで、testdbデータベースが予期したとおりに機能することを確認します。

1. WebLogic Serverを停止します。

2. {domain}/config/fmwconfig/jps-config.xmlファイルおよび{domain}/config/jdbc/*xmlファイルで、jdbc URLをproddbからtestdbに変更します。

3. WebLogic Serverを再起動します。

4. ドメイン・セキュリティが正しく機能することを確認します。

7.6.2 LDAPセキュリティ・ストアのバックアップとリカバリ

この項に記載されている手順を使用し、ソースLDAPストアをターゲットLDAPストアにバックアップします。

1. ソースLDAPシステムで、ldifwriteを実行してLDAPデータ交換形式(LDIF)ファイルを作成します。

>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode" ldiffile="srcOid.ldif"

このコマンドでは、cn=jpsnode, c=usノード下のすべてのエントリがsrcOid.ldifファイルに書き込まれます。

このファイルをターゲットLDAPシステムに移動します。

2. ターゲットLDAPシステムで、スキーマがシードされていることを確認します。

3. ターゲットLDAPシステムで、bulkloadを実行してスキーマ・エラーや不適切なエントリがないことを確認します。

>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"

重複する識別名(ソース・ディレクトリとターゲット・ディレクトリとの間で共通するエントリ)が検出された場合は、予期しない結果が生じないようにその識別名を確認します。

4. bulkloadを実行して、ターゲットLDAPにデータをロードします。

>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"

関連項目:

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項

- ldifwriteを使用したOracle Internet Directoryからファイルへのデータのダンプ

- 「LDIFファイルとbulkloadを使用したLDAPデータの移行」

7.6.3 推奨事項

企業に適したスケジュールに従って、定期的にセキュリティ・ストアをバックアップすることをお薦めします。また、ドメインに対して新しい暗号化鍵が(自動的に)生成されたり、ポリシーや資格証明など新しいセキュリティ・データを作成した後には、すぐにスケジュール外のバックアップをお薦めします。

7.7 コンポーネントの監査定義の12cへのアップグレード

監査静的モデルを使用しているコンポーネントでは、AuditSchemaUpgradeToolを使用して、リリース12cで使用されている監査動的モデルに監査定義をアップグレードできます。このツールは、コンポーネント定義を1つしか含まない監査静的定義ファイルをサポートします。

コンポーネントをアップグレードする前に、displayNameコンポーネントをcomponent_events.xmlファイルのAuditConfigプロパティに追加します。

<AuditConfig componentType="SOA-HCFP"
xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd"
displayName="Oracle SOA Suite Integration">

構文

java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool
-s source_file
-t target_file_or_directory
[, -v component_def_version]

説明:

- source_fileは、component_events.xmlなどの監査定義ファイルです。

- target_file_or_directoryは、a) 12g定義ファイルの格納先ファイル、またはb) ターゲット・ディレクトリで、このディレクトリにモデル定義ファイルがデフォルト・ファイル名source_file_dynamic.xmlで格納されます。

- component_def_versionは生成された12c定義のバージョン番号です。指定しない場合は、デフォルトの1.0に設定されます。

例

次の例では、デフォルトのバージョン番号とターゲット・ファイルcomponent_events_OPSS.xmlを使用して、OPSSコンポーネント定義をリリース12c動的モデルにアップグレードする方法を示します。

java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool
-s component_events.xml
-t component_events_OPSS.xml

次の例では、特定のバージョン番号とターゲット・ディレクトリを指定して、OPSSコンポーネント定義をリリース12c動的モデルにアップグレードする方法を示します。コマンドでは、デフォルトのターゲット・ファイル名component_events_dynamic.xmlを使用しています。

java -classpath $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-manifest.jar oracle.security.audit.tools.AuditSchemaUpgradeTool
-s component_events.xml
-t /scratch/example -v 2.0

8 アイデンティティ・ストアの構成

この章では、アイデンティティ・ストアを構成および使用する方法と、プログラムで問い合せる方法について説明します。

この章の内容は次のとおりです。

- アイデンティティ・ストアについて

- アイデンティティ・ストア・プロバイダの構成

- アイデンティティ・ストアの構成

- プログラムによるアイデンティティ・ストアの問合せ

- アイデンティティ・ストア用のSSLの構成

関連項目:

『Identity Governance Framework開発者ガイド』のIdentity Directory Serviceについてに関する項

8.1 アイデンティティ・ストアについて

アイデンティティ・ストアには、ユーザーとグループの他、そのデータを問い合せることができるサービスが格納されます。デフォルトでは、単一のLDAPアイデンティティ・ストアへの問合せがサポートされます。1つのみではなく、複数のLDAPアイデンティティ・リポジトリに問い合せることが可能になる仮想アイデンティティ・ストアを使用するようにサービスを構成できます。アイデンティティ仮想化の詳細は、第8.3項「アイデンティティ・ストアの構成」を参照してください。

構成に応じて、サービスではファイルまたは(1つ以上の) LDAPサーバーをアイデンティティのリポジトリとして使用します。LDAP用にサービスを構成すると、デフォルトでは単一のLDAPに問い合せますが、複数のLDAPに問い合せるようにサービスを構成することもできます。

サービスは、Java SE環境で使用できます。Java SEアプリケーションでの仮想化の詳細は、第8.3.5項「Java SEアプリケーションでの仮想化の構成」を参照してください。

8.2 アイデンティティ・ストア・プロバイダの構成

アイデンティティ・ストアを使用する前に、アイデンティティ・ストア・プロバイダを構成する必要があります。OPSSでは、次の構成の例で示すように、ファイルとLDAPの両方のアイデンティティ・ストア・プロバイダがサポートされています。

<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider"
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>LDAP IdentityStore Provider</description>
</serviceProvider>

<serviceProvider type="IDENTITY_STORE" name="idstore.xml.provider"
class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider">
<description>XML-based IdentityStore Provider</description>
</serviceProvider>

Active Directoryをアイデンティティ・ストア・プロバイダとして設定した場合、デフォルト値(cn)をオーバーライドするには、jps-config.xml (またはjps-config-jse.xml)でUSERNAME_ATTRプロパティとUSER_LOGIN_ATTRプロパティをsAMAccountNameに設定します。例:

<property value="sAMAccountName" name="username.attr"/>
<property value="sAMAccountName" name="user.login.attr"/>

注意:
virtualizeをtrueに設定する場合は、user.login.attrプロパティとusername.attrプロパティは設定しないでください。

関連項目:

「タスク3: アイデンティティ・ストア・プロバイダの構成」

8.3 アイデンティティ・ストアの構成

次の各項では、アイデンティティ・ストアの構成方法について説明します。

- アイデンティティ・ストアのパラメータ

- サービス構成の理解

- 分割プロファイルの構成

- カスタム認証プロバイダの構成

- Java SEアプリケーションでの仮想化の構成

関連項目:

付録F「OPSSのシステムおよび構成プロパティ」

8.3.1 アイデンティティ・ストアのパラメータ

次の各項では、アイデンティティ・ストアの構成パラメータの使用方法について説明します。

- 問合せパラメータ

- グローバル接続パラメータ

- バックエンド接続パラメータ

8.3.1.1 問合せパラメータ

次のパラメータを使用して、複数のLDAPへの問合せを構成します。

- virtualizeプロパティ - このプロパティには、true (複数のLDAP検索)またはfalse (単一のLDAP検索)を設定できます。指定しない場合は、デフォルトのfalseに設定されます。

- グローバル接続パラメータ(virtualizeプロパティが有効の場合) - コール元のアプリケーションではこれらのパラメータを使用して、グローバルLDAP構成(検索ベース、作成ベースなど)を指定します。これらのパラメータのいずれかを指定しない場合は、デフォルト値が使用されます。

- バックエンド接続パラメータ - このパラメータは各LDAPストアに固有のものです。各LDAPに対して1セットのバックエンド・パラメータが指定されます。デフォルト値を上書きしない場合は、これらのパラメータを設定する必要がありません。

8.3.1.2 グローバル接続パラメータ

表8-1に、グローバル・パラメータを示します。接続プール・パラメータのリストは、『Identity Governance Framework開発者ガイド』の構成パラメータの理解に関する項を参照してください。

表8-1 LDAPアイデンティティ・ストアのグローバル・パラメータ

パラメータ

デフォルト値

group.create.bases

user.create.basesと同じ

group.filter.object.classes

groupofuniquenames

group.mandatory.attrs

デフォルト値なし

group.member.attrs

uniquemember

group.object.classes

groupofuniquenames

group.search.bases

デフォルト値なし

group.selected.create.base

デフォルト値なし

group.selected.search.base

デフォルト値なし

groupname.attr

cn

max.search.filter.length

デフォルト値なし

search.type

デフォルト値なし

user.create.bases

認証プロバイダが1つしかない場合は、作成ベース値が使用されます。複数ある場合は、デフォルト値が設定されません。

user.filter.object.classes

inetorgperson

user.login.attr

uid

user.mandatory.attrs

デフォルト値なし

user.object.classes

inetorgperson

user.search.bases

group.search.basesと同じ

username.attr

cn

関連項目:

第F.2.5項「LDAPの汎用的なプロパティ」

8.3.1.3 バックエンド接続パラメータ

これらのパラメータは特定のLDAPストアに固有のものです。

関連項目:

第F.2.4項「LDAPアイデンティティのプロパティ」

第F.2.2項「ポリシー・サービスのプロパティ」

8.3.2 サービス構成の理解

LDAP認証プロバイダは、Oracle WebLogic Server管理コンソールまたはWebLogic Scripting Tool (WLST)を使用して構成します。実行時に、サーバーから構成の詳細がOPSSに渡されます。

WebLogic Serverドメインでは、指定したコンテキストで複数の認証プロバイダを構成できます。デフォルトでは、リストで最初の認証プロバイダを使用してアイデンティティ・ストアが初期化されます。認証プロバイダの詳細は、第3.2.1.1項「複数の認証プロバイダのサポート」を参照してください。

複数のLDAPに問い合せるには、virtualizeプロパティの設定が必要です。

次の各項では、いくつかの構成について説明します。

- 単一のLDAP用のサービスの構成

- 仮想化を指定しない複数のLDAP用のサービスの構成

- Fusion Middleware Controlを使用した複数のLDAP用のサービスの構成

- WLSTを使用したサービスの構成

- 単一および複数のLDAPの構成

8.3.2.1 単一のLDAP用のサービスの構成

次の例では、単一のLDAPサービス・インスタンスの構成を示します。

<!-- JPS WLS LDAP Identity Store Service Instance -->
<serviceInstance name=idstore.ldap provider=idstore.ldap.provider>
<property name=idstore.config.provider                       value=oracle.security.jps.wls.internal.idstore.
WlsLdapIdStoreConfigProvider/>
<property name=CONNECTION_POOL_CLASS
value=oracle.security.idm.providers.stdldap.JNDIPool/>
</serviceInstance>

8.3.2.2 仮想化を指定しない複数のLDAP用のサービスの構成

virtualizeプロパティを設定できない場合は、複数のLDAPに問い合せて、WebLogic Serverの構成をオーバーライドするようにサービスを構成できます。複数のLDAPを指定するには、LDAP URLのカンマ区切りリストを使用します。

<property name="ldap.url", value="ldap://host1:port1,ldap://host2:port2"/>

8.3.2.3 Fusion Middleware Controlを使用した複数のLDAP用のサービスの構成

Fusion Middleware Controlを使用して複数のLDAPに対するサービスを構成するには、次の手順を実行します。

1. 左側のナビゲーション・ペインでドメインを選択します。

2. 「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

3. ページの「アイデンティティ・ストア・プロバイダ」セクションを開きます。

4. 「構成」をクリックします。

5. 「アイデンティティ・ストア構成」ページが表示されます。

6. 「カスタム・プロパティ」で「追加」をクリックします。

7. 新しいプロパティを追加します。

Property Name=virtualize
Value=true

このプロパティは、OPSS構成ファイルのデフォルト・コンテキストのサービス・インスタンスにも必ず追加します。

8. 「OK」をクリックします。

8.3.2.4 WLSTを使用したサービスの構成

WLSTを使用して仮想化を構成および使用するには、次の手順を実行します。

1. 対象ドメインの管理サーバーに接続するためのスクリプト・ファイルを作成します。この操作についてuserName、userPass、localHostおよびportNumberを指定する必要があります。スクリプトを使用したサービスの構成の詳細は、付録Eの項「スクリプトを使用したサービスの構成」を参照してください。

2. $ORACLE_HOME/common/binに移動します。

3. wlst.shを実行します。
たとえば、ドメイン構成ファイルにidstore.ldap認証プロバイダが含まれている場合、次のコマンドで複数のLDAP検索用にプロバイダを構成します。

wlst.sh /tmp/updateServiceInsta, nceProperty.py -si idstore.ldap
-key "virtualize" -value "true"

8.3.2.5 WLSTを使用したタイムアウト設定の構成

WLSTを使用してアダプタ・タイムアウトを設定するには、次の手順を実行します。

1. listAdaptersコマンドを実行して、アダプタのリストを取得します。

2. modifyLDAPAdapterコマンドを実行して、アダプタごとにタイムアウト(たとえば120秒)を設定します。
modifyLDAPAdapter('<ADAPTER NAME>', 'OperationTimeout', 120000)

3. WebLogic Serverを再起動します。

関連項目:

『Identity Governance Framework開発者ガイド』のmodifyLDAPAdapterに関する項

8.3.2.6 その他のパラメータの構成

必要に応じて、jps-config.xmlファイルの構成を更新して、第8.3.1項「アイデンティティ・ストアのパラメータ」に記載されている問合せパラメータを設定します。これらのパラメータはオプションであり、デフォルト値があります。

8.3.2.7 サーバーの再起動

複数のLDAPへの問合せを構成したら、Weblogic管理サーバーおよび管理対象サーバーを再起動します。

8.3.2.8 単一および複数のLDAPの構成

次の例では、単一のLDAPの構成を示します。

<serviceInstance name=idstore.ldap provider=idstore.ldap.provider>
<property name=idstore.config.provider                       value=oracle.security.jps.wls.internal.idstore.
WlsLdapIdStoreConfigProvider/>
<property name=CONNECTION_POOL_CLASS
value=oracle.security.idm.providers.stdldap.JNDIPool/>
</serviceInstance>

次の例では、複数のLDAPの構成を示します。

<serviceProviders>
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider"
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>LDAP IdentityStore Provider</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>
<!-- IDstore instance connecting to multiple ldap  -->
<serviceInstance name="idstore.virtualize" provider="idstore.ldap.provider">
<!-- indicates using WLS ldap authentication providers -->
<property name="idstore.config.provider"
value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>
<!-- enable virtualization -->
<property name="virtualize" value="true"/>
<!-- ldap properties (if not supplied, then it uses default values) -->
<extendedProperty>
<name>user.create.bases</name>
<values>
<value>cn=users_front,dc=us,dc=example,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.create.bases</name>
<values>
<value>cn=groups_front,dc=us,dc=example,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>
</serviceInstances>
<jpsContexts default="default">
<!-- the identity store uses multiple ldaps -->
<jpsContext name="default">
<!-- use multiple ldap -->
<serviceInstanceRef ref="idstore.virtualize"/>
<!-- .....other services -->
</jpsContext>
</jpsContexts>
</jpsConfig>

次のことに留意してください:

- サービス・インスタンスのvirtualizeプロパティはtrueであり、この値により、複数のLDAPディレクトリに問い合せることができます。

- extendedProperty要素を使用すると、デフォルト値をオーバーライドするようにフロントエンド・パラメータを設定できます。

関連項目:

第8.3.1項「アイデンティティ・ストアのパラメータ」のフロントエンド・パラメータ

8.3.3 分割プロファイルの構成

アイデンティティ仮想化では分割プロファイルがサポートされており、アイデンティティ属性が複数のLDAPリポジトリに格納されている場合、その属性にアプリケーションでアクセスできます。

この機能には、付録I「ID仮想化のためのアダプタ構成」に記載されている追加構成が必要です。

8.3.4 カスタム認証プロバイダの構成

OPSSでは、アイデンティティへのアクセスにWebLogic認証プロバイダがサポートされています。使用可能なプロバイダが特定のLDAPサーバーに適合していない場合は通常、カスタマイズします。この項では、カスタム認証プロバイダを構成して使用する方法について説明します。

カスタムLDAP認証プロバイダを使用する場合に、次の構成では、jps-config.xmlのidstore.typeをオーバーライドすることで、プロバイダが適切なLDAPプラグインを検出できるようにLDAPタイプを使用する方法を示します。

<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<property name="idstore.config.provider"
value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"
/>
<property name="CONNECTION_POOL_CLASS"
value="oracle.security.idm.providers.stdldap.JNDIPool" />
<property value="true" name="virtualize" />
<serviceInstanceRef ref="myGenericLDAPName"/>
</serviceInstance>
<serviceInstance name="myGenericLDAPName" provider="idstore.ldap.provider">
<!-- overrides the 'idstore.type' property -->
<property name="idstore.type" value="ACTIVE_DIRECTORY" />
</serviceInstance>

追加のLDAPプロバイダ・インスタンスをオーバーライドするには、同様のエントリを挿入します。プロバイダ構成の詳細は、第9.6項「Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成」を参照してください。

8.3.5 Java SEアプリケーションでの仮想化の構成

Java SEアプリケーションの場合、構成はすべてjps-config-jse.xmlファイルに設定します。必要に応じて、このファイルを次のように編集します。

1. 新しいサービス・インスタンスを定義します。

2. 新しいサービス・インスタンスをコンテキストに追加して、事前に定義されているインスタンスを置き換えます。

3. virtualizeを有効にします。

関連項目:

第24.3.1項 「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」

8.4 プログラムによるアイデンティティ・ストアの問合せ

アイデンティティ・ストアにプログラムで問い合せるには、OPSS APIを使用してコンテキストを取得します。このコンテキストは、ストア・インスタンスを取得するブリッジのように機能します。続いて、ユーザーおよびロールAPIを使用して、ストア・インスタンスに問い合せます。

try {
//find the JPS context
JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();

//find the JPS IdentityStore service instance
//(assuming the back-end is ldap type)
LdapIdentityStore idstoreService = (LdapIdentityStore)ctx.getServiceInstance(IdentityStoreService.class)

//get the User/Role API's Idmstore instance
oracle.security.idm.IdentityStore idmIdentityStore = idstoreService.getIdmStore();

//use the User/Role API to query ID store
//

//alternatively, instead of using IdentityStore, use the
//IdentityDirectory to access LDAP
oracle.igf.ids.IdentityDirectory ids = idstoreService.getIdentityStore();
} catch (Exception e) {
e.printStackTrace()
}

関連項目:

第E.2項「MBeanを使用したサービスの構成」

8.5 アイデンティティ・ストア用のSSLの構成

アイデンティティ・ストアとLDAPサーバーの間ではSecure Sockets Layer (SSL)接続を使用できます。アイデンティティ・ディレクトリAPIとユーザーおよびロールAPIのいずれも、複数のLDAPで動作できます。

アイデンティティ・ストアへの接続がWebLogic Serverのクライアントから始まる場合、SSL構成はサーバーで処理されます。

関連項目:

第9.2.2項「LDAPセキュリティ・ストアへの一方向SSLの設定」

第12.11.1項「LDAPとJKS間の一方向SSLの設定」

9 セキュリティ・ストアの構成

セキュリティ・ストアは、WebLogic Serverドメイン内で実行されているアプリケーションすべてで使用されるシステムおよびアプリケーション固有のポリシー、資格証明、鍵、監査データの中央リポジトリです。

この章の内容は次のとおりです。

- セキュリティ・ストアについて

- LDAPセキュリティ・ストアの使用

- DBセキュリティ・ストアの使用

- セキュリティ・ストアの再関連付け

- セキュリティ・ストアの移行

- Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成

9.1 セキュリティ・ストアについて

セキュリティ・ストアは、システムおよびアプリケーション固有のポリシー、資格証明および鍵の中央リポジトリです。この集中化により、ポリシー、資格証明および鍵の管理とメンテナンスが容易になります。

セキュリティ・ストアのタイプは、ファイル、LDAPまたはDBのいずれかです。ファイルからLDAPまたはDB、DBからLDAPまたはDB、LDAPからLDAPまたはDBに再関連付けすることができます。すぐに使用できる状態では、セキュリティ・ストアはデータベース・ストアです。

Java EEアプリケーションでは、セキュリティ・データはアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにパッケージ化されるため、アプリケーションのデプロイ時にセキュリティ・ストアに移行できます。

WebLogic Serverドメインでセキュリティ・ストアのポリシーを使用すると、そのドメイン内のすべての管理対象サーバーでJava Authorization Contract for Containers (JACC)ポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。

ポリシーで使用するパーミッション・クラスをすべてクラス・パスに含めておく必要があるため、サービス・インスタンスの初期化時にポリシー・プロバイダでそれらパーミッション・クラスをロードできます。

関連項目:

「Fusion Middleware Controlを使用したセキュリティ・ストアの再関連付け」

「reassociateSecurityStoreを使用したセキュリティ・ストアの再関連付け」

「Fusion Middleware Controlを使用したセキュリティ・ストアの移行」

「migrateSecurityStoreを使用したセキュリティ・ストアの移行」

『Oracle WebLogic Serverセキュリティの理解』のJava EEおよびWebLogicセキュリティに関する項

9.1.1 複数のサーバーがある環境

複数のサーバー・インスタンス(管理サーバーおよび管理対象サーバー)が同じホスト上にある、または複数のマシンに分散されている本番のWebLogic Serverドメインでは、LDAPまたはデータベースのセキュリティ・ストアを使用する必要があります。本番環境ではファイルベースのプロバイダは推奨されません。

関連項目:

付録Fの項「ポリシー・サービスのプロパティ」

付録Fの項「資格証明サービスのプロパティ」

9.2 LDAPセキュリティ・ストアの使用

本番環境では通常、LDAPセキュリティ・ストアを使用します。唯一サポートされているLDAPは、Oracle Internet Directoryです。

OPSSでは、LDAPサーバーでの参照整合性の有効化がサポートされていません。参照整合性を有効化した場合、サーバーは想定したとおりには機能しません。サーバーの参照整合性を無効にするには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、次の手順を実行します。

1. 「管理」→「共有プロパティ」→「一般」の順に選択します。

2. 参照整合性の有効化リストで、「無効」を選択します。

注意:
バージョンに応じて、次のOracle Internet Directoryパッチが必要です。

- パッチ10.1.4: Oracle Bug#9093298の修正

- パッチ11.1.x: Oracle Bug#8736355の修正

- パッチ11.1.xおよび10.1.4.3: Oracle Bug#8426457の修正

- パッチ10.1.4.3: Oracle Bug#8351672の修正

- パッチ10.1.4.3: Oracle Bug#8417224の修正

- パッチ11.1.1.6.0: Oracle Bug#13782459の修正

サポートされているOracle Internet Directoryのバージョンの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlで「Oracle Fusion Middleware 12c Certifications」を参照してください。

次の各項では、LDAPセキュリティ・ストアを設定する方法について説明します。

- LDAPセキュリティ・ストアを使用する場合の前提条件

- LDAPセキュリティ・ストアへの一方向SSLの設定

- LDAPユーザー・パスワードのリセット

関連項目:

付録Fの項「すべてのLDAPサーバーに共通するプロパティ」

9.2.1 LDAPセキュリティ・ストアを使用する場合の前提条件

LDAPに正しくアクセスできるようにするには、この項の説明に従ってサーバー・ディレクトリにノードを設定します。

Fusion Middleware Controlを使用してLDAPストアに再関連付けすると、ブートストラップ資格証明がcwallet.ssoファイルに自動的に指定されます。

LDAPサーバーにノードを設定するには、次の手順を実行します。

1. 次のエントリ指定してLDAPデータ交換形式(LDIF)ファイル(jpstestnode.ldif)を作成します。

dn: cn=jpsroot
cn: jpsroot
objectclass: top
objectclass: OrclContainer

ルート・ノードの識別名jpsrootは、他のどの識別名とも異なる必要があります。一部のLDAPサーバーでは、デフォルトで大文字小文字が区別されます。複数のWebLogic Serverドメインで1つのルート・ノードを共有できます。このノードは最上位レベルに作成する必要はありませんが、LDAP管理者にはその下のノードすべてに対する読取りおよび書込みの権限が必要です。

2. このデータをldapaddユーティリティを使用してLDAPサーバーにインポートします。

>ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -v -f  jpstestnode.ldif

3. ldapsearchユーティリティを使用してノードが正常に挿入されたことを確認します。

>ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -s base
-b "cn=jpsroot" objectclass="orclContainer"

4. oidstats.sqlを実行して、最適なデータベースのパフォーマンスのためにデータベース統計を生成します。

>$ORACLE_HOME/ldap/admin/oidstats.sql

このユーティリティは、最初のプロビジョニング後に1回のみ実行する必要があります。

関連項目:

第23.6.7項「ブートストラップ資格証明の手動による指定」

『Oracle Fusion Middleware Oracle Identity Managementリファレンス』

9.2.2 LDAPセキュリティ・ストアへの一方向SSLの設定

この項では、Oracle WebLogic ServerまたはJava SEアプリケーションとLDAPセキュリティ・ストア間で一方向Secure Sockets Layer (SSL)チャネルを設定する方法について説明します。このような接続は、たとえばLDAPターゲット・ストアへの再関連付けの際に必要になります。

LDAPの構成

一方向SSLでLDAPを構成する方法の詳細は、『Oracle Fusion Middlewareの管理』のOracle Internet DirectoryリスナーでのSSLの有効化に関する項を参照してください。

LDAP認証局の作成

WebLogic ServerでLDAP認証局を認識できない場合、orapkiを使用して証明書を作成します。

>orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert

serverTrust.cert証明書が作成され、キーストア・パスワードの入力を求められます。

SSLを構成する前に、次のことに注意してください。

- 次の手順は、SSLのタイプがserver-authである場合に必要で、それ以外(no-authまたはclient-auth)の場合には不要です。

- 次の手順で指定するフラグを複数のアプリケーションが実行される環境で使用する場合は、それらのアプリケーションで同じトラストストアを使用する必要があります。

Java EEアプリケーション用の設定

次の手順のいずれかを使用して、サーバーとアイデンティティ・ストアの間に一方向SSL接続を設定します。アイデンティティ・ストア・サービスとセキュリティ・ストア・サービスでは、異なるソケット・ファクトリを使用するため、次の手順が異なります。

サーバーとアイデンティティ・ストア間で一方向SSL接続を確立するには、次の手順を実行します(信頼できる認証局(CA)がある場合は、エクスポートされていることを前提とします)。

1. WebLogic ServerでCAを認識できる場合、この手順をスキップします。
認識できない場合は、次の例(ここではmyKeys.jksファイルを生成してserverTrust.certファイルをインポート)に示すように、keytoolを使用してLDAP CAをトラストストアにインポートします。

>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword

2. サーバーを起動するstartWebLogic.shスクリプトを変更して次のような行を挿入した後、スクリプトを実行します。

-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>

サーバーとセキュリティ・ストア間で一方向SSL接続を確立するには、次の手順を実行します(信頼できるCAがある場合は、エクスポートされていることを前提とします)。

1. keytoolを使用して、信頼できるCAをトラストストアにインポートします。

>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword

2. サーバーを起動するstartWebLogic.shスクリプトを変更して次のような行を挿入した後、スクリプトを実行します。

-Dweblogic.security.SSL.trustedCAKeyStore=<absolute path name to file myKeys.jks>

3. LDAPサーバーのSSL証明書でワイルド・カードを使用する場合は、WebLogic Serverを起動するスクリプトに次の行を追加します。

-Dweblogic.security.SSL.ignoreHostnameVerification=true

4. サーバーを再起動します。

Java SEアプリケーション用の設定

1. WebLogic ServerでCAを認識できる場合、この手順をスキップします。
認識できない場合は、次の例(ここではmyKeys.jksファイルを生成してserverTrust.certファイルをインポート)に示すように、keytoolを使用してLDAP CAをトラストストアにインポートします。

>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword

2. Java仮想マシン(JMV)を起動するスクリプトを変更して次のような行を挿入します。

-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>

3. サーバーを再起動します。

9.2.3 LDAPユーザー・パスワードのリセット

この項に記載されている手順を使用して、LDAPユーザー・パスワードをリセットします。

1. 新しいパスワードを指定する内容でLDIFファイルを作成します。

dn: <UserDN>
changetype: modify
replace: userPassword
userPassword: new_password

userDNは、管理者の識別名を表します。

2. 次の例(ここではupdatePassword.ldifファイルの指定を使用)に示すように、ldapmodifyを使用して作成したファイルの指定を適用します。

ldapmodify -h oid_hostName -p oid_port -D ”cn=orcladmin” -w orcladmin_password -f updatePassword.ldif

3. modifyBootStrapCredentialを実行してブートストラップ・ウォレットに格納されたパスワードを更新します。

関連項目:

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』

Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス

9.3 DBセキュリティ・ストアの使用

本番環境では、DBセキュリティ・ストアをお薦めします。セキュリティ・ストアを構成するには、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)を使用します。DBセキュリティ・ストアおよびドメインは同じデータ・センターに存在する必要があります。

開発環境でのみ、セキュリティ・ストアとしてOracle DBMS Express、Oracle DBMS Standard EditionまたはOracle DBMS Standard Edition Oneを使用できます。

サポートされているバージョンの詳細は、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlで「Oracle Fusion Middleware 12c Certifications」を参照してください。

OPSSスキーマおよび監査スキーマによるエディション・ベースの再定義(EBR)のサポートの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』の第2.7.5項を参照してください。

次の各項では、DBセキュリティ・ストアを設定する方法について説明します。

- DBセキュリティ・ストアを使用する場合の前提条件

- DBセキュリティ・ストアのメンテナンス

- OPSSスキーマ・パスワードのリセット

- DBセキュリティ・ストアへのSSL接続の設定

9.3.1 DBセキュリティ・ストアを使用する場合の前提条件

セキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middlewareリポジトリ作成ユーティリティを使用して必要なOPSSスキーマを作成し、一部の初期データをシードします。リポジトリ作成ユーティリティの詳細は、『リポジトリ作成ユーティリティによるスキーマの作成』の「リポジトリ作成ユーティリティの各画面の理解」を参照してください。

リポジトリ作成ユーティリティを実行してOPSSスキーマを作成する場合、名前に次の接尾辞が含まれるスキーマをすべて選択します。

- _OPSS

- _IAU

- _IAU_APPEND

- _IAU_VIEWER

- _STB

9.3.2 DBセキュリティ・ストアのメンテナンス

この項では、OPSSスキーマ・パスワードの変更を含め、DBセキュリティ・ストアをメンテナンスする場合に実行するタスクをいくつか説明します。

DBセキュリティ・ストアには、定期的にパージする必要がある変更ログが保持されます。パージするには、提供されているSQLスクリプトopss_purge_changelog.sqlを使用して24時間以上前の変更ログをパージするか、データベースに接続してdeleteユーティリティを(適切な引数を指定して)実行します。

SQL>delete from jps_changelog where createdate < (select(max(createdate) - 1) from jps_changelog);
SQL>Commit;

DBセキュリティ・ストアにアクセスする際のパフォーマンスを向上させるには、DBMS_STATSパッケージを実行して、データベース表および索引の物理記憶域に関する統計情報を収集します。この情報はデータ・ディクショナリに格納され、分析対象のオブジェクトにアクセスするSQL文の実行計画を最適化する場合に使用します。

数千の新しいアプリケーション・ロールを作成する場合など、大量のデータをDBセキュリティ・ストアにロードする場合は、短期間内にロード・アクティビティと同時にDBMS_STATSを実行することをお薦めします。そうではなく、ロード・アクティビティが小規模な場合は、DBMS_STATSを1回のみまたは必要に応じて実行します。

次の例では、DBMS_STATSの使用方法を示します。

EXEC DBMS_STATS.GATHER_SCHEMA_STATS('DEV_OPSS', DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);

DEV_OPSSは、リポジトリ作成ユーティリティを使用して作成されたデータベース・スキーマの名前を示しています。

スクリプトの例

次の例では、DBMS_STATSコマンドを10分ごとに実行します。

#!/bin/sh
i=1
while [ $i -le 1000 ]
do
echo $i
sqlplus dev_opss/welcome1@inst1 @opssstats.sql
sleep 600
i=`expr $i + 1`
done

opssstats.sqlには、次のテキストが含まれます。

EXEC DBMS_STATS.gather_schema_stats('DEV_OPSS',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);
QUIT;

次の例でも、DBMS_STATSを10分ごとに実行します。

variable jobno number;
BEGIN
DBMS_JOB.submit
(job => :jobno,
what => 'DBMS_STATS.gather_schema_stats(''DEV_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE,no_invalidate=>FALSE);',
interval => 'SYSDATE+(10/24/60)');
COMMIT;
END;
/

このSQLスクリプトによって起動されたDBMS_STATSを停止するには、まず次のコマンドを発行してそのジョブ番号を見つけます。

sqlplus '/as sysdba'
SELECT job FROM dba_jobs WHERE schema_user = 'DEV_OPSS' AND what = 'DBMS_STATS.gather_schema_stats(''DEV_OPSS'',DBMS_STATS.AUTO_SAMPLE_SIZE, no_invalidate=>FALSE);';

続いて、次のようなコマンドを実行します(問合せでジョブ番号31が返されたと仮定しています)。

EXEC DBMS_JOB.remove(31);

9.3.3 OPSSスキーマ・パスワードのリセット

OPSSスキーマ・パスワードをリセットするには、次の手順を実行します。

1. ALTER USERデータベース・コマンドを使用してデータベースのパスワードをリセットします。次の2つの手順で使用しますので、入力した新しいパスワードを忘れないでください。

2. Oracle WebLogic Server管理コンソールを使用して、データ・ソースがOPSSスキーマへの接続に使用しているパスワードを新しいパスワードで更新します。

3. modifyBootStrapCredential WLSTコマンドを使用して、新しいパスワードでcwallet.ssoブートストラップ・ファイルを更新します。

関連項目:

『Oracle WebLogic Server JDBCデータ・ソースの管理』Oracle WebLogic ServerのJDBCデータ・ソースの作成に関する項

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のmodifyBootStapCredentialに関する項

9.3.4 DBセキュリティ・ストアへのSSL接続の設定

DBセキュリティ・ストアへの一方向または双方向SSL接続の確立は必要に応じて実行するものであり、詳細は『Oracle Fusion Middlewareの管理』のデータベースでのSSLの構成に関する項を参照してください。

9.4 セキュリティ・ストアの再関連付け

セキュリティ・ストアの再関連付けとは、セキュリティ・データをリポジトリ間で再配置するプロセスです。ソース・タイプは、ファイル、LDAPまたはDBのいずれかです。ターゲット・タイプは、LDAPまたはDBのいずれかです。

再関連付けでは、格納データの整合性を保持しながらリポジトリが変更されます。この操作は、ドメインの作成後であればいつでも実行でき、次の各項の説明に従って、Fusion Middleware ControlまたはreassociateSecurityStore WLSTコマンドのいずれかを使用して実行します。

- Fusion Middleware Controlを使用したセキュリティ・ストアの再関連付け

- reassociateSecurityStoreを使用したセキュリティ・ストアの再関連付け

9.4.1 Fusion Middleware Controlを使用したセキュリティ・ストアの再関連付け

再関連付けでは、セキュリティ・ストア(ポリシー、資格証明、鍵および監査データ)をリポジトリ間で移行し、セキュリティ・プロバイダを再構成します。手順の詳細は、「タスク2: セキュリティ・ストアの移行」を参照してください。

次の点に注意してください:

- ターゲットLDAPストアに再関連付けを行う前に、「LDAPセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。

- ターゲットDBストアに再関連付けを行う前に、「DBセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。

- 再関連付けを行う前でターゲットLDAPへの一方向SSLが必要な場合は、「LDAPセキュリティ・ストアへの一方向SSLの設定」に記載されている手順を実行してください。

- LDAPストアへの再関連付けの後、LDAPストアのルート・ノードへのアクセスを保護するために、「LDAPノードへのアクセスの保護」に記載されている手順を実行してください。

- 再関連付けによって、jps-config.xmlファイルとjps-config-jse.xmlファイルが新しい構成で更新されます(古いプロバイダ構成が削除され、新しいプロバイダ構成が挿入され、データがソース・ストアからターゲット・ストアに移動します)。

- ターゲット・ストアがLDAPの場合、情報は、次の形式に従ってドメイン識別名の下に格納されます。

cn=<domain_name>,cn=JpsContext,<JPS ROOT DN>

構成がドメイン識別名に基づいている場合、このノードをLDAPサーバーから削除しないでください。

9.4.1.1 LDAPノードへのアクセスの保護

この項で説明する手順は必要に応じて実行するものであり、LDAPサーバーにアクセスする際のセキュリティを強化することのみを目的として実行します。

アクセス制御リスト(ACL)とは、情報にアクセスできるユーザーとLDAPオブジェクトに対して許可される操作を指定したリストです。制御リストはノードで指定し、そのノード下のすべてのエントリにその制限が適用されます。

ACLを使用してLDAPリポジトリに格納されているデータへのアクセスを制御します。通常、このリストはストアのルート・ノードで指定します。

LDAPリポジトリのノードでACLを指定するには、次の手順を実行します。

1. ACLを指定する内容を記述したLDIFファイルを作成します。

dn: <storeRootDN>
changetype: modify
add: orclACI
access to entry by dn="<userDN>" (browse,add,delete) by * (none)
access to attr=(*) by dn="<userDN>" (search,read,write,compare) by * (none)

storeRootDNはストアのルート・ノードを表し、userDNは管理者の識別名(再関連付けを実行する際に入力したのと同じ識別名)を表します。

2. ldapmodifyを使用して、これらの指定をOIDに適用します。

dn: cn=jpsRootNode
changetype: modify
add: orclACI
access to entry by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (browse,add,delete) by * (none)
access to attr=(*) by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (search,read,write,compare) by * (none)

関連項目:

『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のldapmodifyに関する項

9.4.2 reassociateSecurityStoreを使用したセキュリティ・ストアの再関連付け

セキュリティ・ストアの再関連付けは、reassociateSecurityStore WLSTコマンドを使用して行うことができます。このコマンドの詳細は、第10.4.1項「reassociateSecurityStore」を参照してください。

9.5 セキュリティ・ストアの移行

アプリケーションでは独自のポリシーを指定することができ、アプリケーションをWebLogic Serverにデプロイすると、これらのポリシーは(セキュリティ・ストアの)アプリケーション・ストライプに格納されます。ドメインで実行されているアプリケーションはそれぞれストライプを1つ使用し、複数のアプリケーションが同じストライプを使用することができます。ファイル・セキュリティ・ストアでは、$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlファイルの<applications>要素でストライプを指定します。

セキュリティ・ストアの移行とは、ポリシー、資格証明、監査データおよび鍵をリポジトリ間で再配置するプロセスです。ソース・タイプは、ファイル、LDAPまたはDBのいずれかです。ターゲット・タイプは、LDAPまたはDBのいずれかです。OPSSのバイナリとターゲット・セキュリティ・ストアには、バージョンの互換性が必要です。バージョンの問題の詳細は、第J.9.1項「バイナリとセキュリティ・ストアのバージョンの非互換性」を参照してください。

次の各項では、アプリケーション・セキュリティをセキュリティ・ストアに移行する方法について説明します。

- Fusion Middleware Controlを使用したセキュリティ・ストアの移行

- migrateSecurityStoreを使用したセキュリティ・ストアの移行

9.5.1 Fusion Middleware Controlを使用したセキュリティ・ストアの移行

アプリケーションでは、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用してアプリケーションをWebLogic Serverにデプロイすると、jazn-data.xmlアプリケーション・ファイルで指定されたセキュリティ・データをセキュリティ・ストアに移行できます。アプリケーションがアンデプロイされる際およびアプリケーションが再デプロイ時に更新される際に、セキュリティ・ストアからポリシーを削除することもできます。

システム・プロパティjps.deployment.handler.disabledをtrueに設定し、weblogic-application.xmlファイルでの個別の設定に関係なく、すべてのアプリケーションに対してデプロイ時のポリシーおよび資格証明の移行を無効にします。

関連項目:

第9.6項「タスク2: セキュリティ・ストアの移行」

9.5.2 migrateSecurityStoreを使用したセキュリティ・ストアの移行

アイデンティティ、ポリシー、システム・ポリシーおよび資格証明は、migrateSecurityStore WLSTコマンドを使用してソース・リポジトリからターゲット・リポジトリに移行できます。

このコマンドは実行中のサーバーに接続しなくても動作します。したがって、configFile引数に渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけです。

注意:
migrateSecurityStoreコマンドによってGUIDが再作成されるため、大量のデータを移行するのに長時間を要します。かわりに、OIDの一括操作を使用して大量のストアを移行することを検討してください。手順の詳細は、第7.6.2項「LDAPセキュリティ・ストアのバックアップとリカバリ」を参照してください。

次の各項では、このコマンドの使用方法について説明します。

- migrateSecurityStoreを使用したすべてのポリシーの移行

- migrateSecurityStoreを使用したシステム・ポリシーの移行

- migrateSecurityStoreを使用したアプリケーション・ポリシーの移行

- migrateSecurityStoreを使用したすべての資格証明の移行

- migrateSecurityStoreを使用した1つの資格証明マップの移行

関連項目:

第10.4項「WLSTを使用したポリシーの管理」の注意

「migrateSecurityStoreの使用例」

9.5.2.1 migrateSecurityStoreを使用したすべてのポリシーの移行

すべてのポリシー(すべてのアプリケーションのシステム・ポリシーおよびアプリケーション・ポリシー)を移行するには、次の構文のいずれかを使用します。

migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-skip trueOrfalse]
[-overwrite trueOrfalse]

migrateSecurityStore(type="policyStore",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext"
[,skip="trueOrfalse"]
[,overwrite="trueOrfalse"])

説明:

- configFileでは、構成ファイルの場所を、コマンドが実行されるディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の情報を指定するコンテキストを含める必要があります。

- ソース・ストア

- ターゲット・ストア

- ブートストラップ資格証明

ブートストラップ・コンテキストでは、ソースおよびターゲットのストアへのアクセスと、セキュリティ・データの復号化および暗号化に必要な鍵が含まれているcwallet.ssoファイルの場所を指定します。

ドメインで使用される鍵の抽出の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyコマンドに関する項を参照してください。

ウォレットへの鍵の格納の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportEncryptionKeyコマンドに関する項を参照してください。

ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』の一般的なウォレットの操作に関する項を参照してください。

- srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- skipでは、互換性のないアーティファクトの移行をスキップするか、ソース・リポジトリで互換性のないアーティファクトを検出したときに終了するかを指定します。互換性のないアーティファクトの移行をスキップして終了しない場合はtrueに設定します。互換性のないアーティファクトが検出されたときに終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- overwriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。ターゲット・データを上書きする場合はtrueに設定します。ターゲット・データを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

srcおよびdstで指定するコンテキストは、渡す構成ファイルで定義する必要があり、重複しない名前にし、渡すコンテキストと構成ファイルのコンテキストは大文字小文字の区別まで一致する必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

9.5.2.2 migrateSecurityStoreを使用したシステム・ポリシーの移行

システム・ポリシーのみ移行するには、次の構文のいずれかを使用します。

migrateSecurityStore.py -type globalPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-overwrite trueOrfalse]

migrateSecurityStore(type="globalPolicies",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext"
[,overwrite="trueOrfalse"])

説明:

- configFileでは、構成ファイルの場所を、コマンドが実行されるディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の情報を指定するコンテキストを含める必要があります。

- ソース・ストア

- ターゲット・ストア

- ブートストラップ資格証明

ブートストラップ・コンテキストでは、ソースおよびターゲットのストアへのアクセスと、セキュリティ・データの復号化および暗号化に必要な鍵が含まれているcwallet.ssoファイルの場所を指定します。

ドメインで使用される鍵の抽出の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyに関する項を参照してください。

ウォレットへの鍵の格納の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportEncryptionKeyに関する項を参照してください。

ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』の一般的なウォレットの操作に関する項を参照してください。

- srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- skipでは、互換性のないアーティファクトの移行をスキップするか、ソース・リポジトリで互換性のないアーティファクトを検出したときに終了するかを指定します。互換性のないアーティファクトの移行をスキップして終了しない場合はtrueに設定します。互換性のないアーティファクトが検出されたときに終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- overwriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。ターゲット・データを上書きする場合はtrueに設定します。ターゲット・データを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

srcおよびdstで指定するコンテキストは、構成ファイルで定義する必要があり、重複しない名前にし、渡すコンテキストと構成ファイルのコンテキストは大文字小文字の区別まで一致する必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

9.5.2.3 migrateSecurityStoreを使用したアプリケーション・ポリシーの移行

1つのアプリケーションのアプリケーション固有のポリシーのみ移行するには、次の構文のいずれかを使用します。

migrateSecurityStore.py -type appPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
-srcApp srcAppName
[-dstApp dstAppName]
[-overWrite trueOrfalse]
[-migrateIdStoreMapping trueOrfalse]
[-mode laxOrstrict]
[-skip trueOrfalse]

migrateSecurityStore(type="appPolicies",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext",
srcApp="srcAppName",
[dstApp="dstAppName"],
[overWrite="trueOrfalse"],
[migrateIdStoreMapping="trueOrfalse"],
[mode="strict"],
skip="trueOrfalse")

説明:

- configFileでは、構成ファイルの場所を、コマンドが実行されるディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の情報を指定するコンテキストを含める必要があります。

- ソース・ストア

- ターゲット・ストア

- ブートストラップ資格証明

ブートストラップ・コンテキストでは、ソースおよびターゲットのストアへのアクセスと、セキュリティ・データの復号化および暗号化に必要な鍵が含まれているcwallet.ssoファイルの場所を指定します。

ドメインで使用される鍵の抽出の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyに関する項を参照してください。

ウォレットへの鍵の格納の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportEncryptionKeyに関する項を参照してください。

ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』の一般的なウォレットの操作に関する項を参照してください。

- srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- skipでは、互換性のないアーティファクトの移行をスキップするか、ソース・リポジトリで互換性のないアーティファクトを検出したときに終了するかを指定します。互換性のないアーティファクトの移行をスキップして終了しない場合はtrueに設定します。互換性のないアーティファクトが検出されたときに終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- srcAppでは、ポリシーを移行するアプリケーションの名前を指定します。

- dstAppでは、ポリシーを書き込むアプリケーションの名前を指定します。指定しない場合は、ソース・アプリケーションの名前にデフォルト設定されます。オプション。

- migrateIdStoreMappingでは、エンタープライズ・ポリシーを移行するかどうかを指定します。デフォルト値はtrueです。アプリケーション・ポリシーのみ移行する場合はfalseに設定します。オプション。

- overWriteでは、ソース・ポリシーと一致するターゲット・ポリシーをソース・ポリシーで上書きするか、ソース・ポリシーとマージするかを指定します。ターゲット・ポリシーを上書きする場合はtrueに設定します。一致するポリシーをマージする場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- modeでは、ポリシーで重複するプリンシパルまたはパーミッションを検出したときに、移行を停止してエラーを送信するかどうかを指定します。重複する項目を検出した場合に移行を続行し、重複する項目のいずれかのみを移行してこの結果に対する警告をログに記録させる場合は、指定しないか、laxに設定します。オプション。

srcおよびdstで指定するコンテキストは、構成ファイルで定義する必要があり、重複しない名前にし、渡すコンテキストと構成ファイルのコンテキストは大文字小文字の区別まで一致する必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

入力がこれらの構文要件に従っていない場合は、コマンドの実行に失敗します。特に、入力は次の要件を満たす必要があります: (a) 渡された場所でjps-config.xmlファイルが検出されること、(b) 渡されたコンテキストがjps-config.xmlファイルに含まれていること、(c) ソースおよびターゲットのコンテキスト名が異なっていること。

9.5.2.4 migrateSecurityStoreを使用したすべての資格証明の移行

すべての資格証明を移行するには、次の構文のいずれかを使用します。

migrateSecurityStore.py -type credStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-skip trueOrfalse]
[-overwrite trueOrfalse]

migrateSecurityStore(type="credStore",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext",
[skip="trueOrfalse"],
[overwrite="trueOrfalse"])

説明:

- configFileでは、構成ファイルの場所を、コマンドが実行されるディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の情報を指定するコンテキストを含める必要があります。

- ソース・ストア

- ターゲット・ストア

- ブートストラップ資格証明

ブートストラップ・コンテキストでは、ソースおよびターゲットのストアへのアクセスと、セキュリティ・データの復号化および暗号化に必要な鍵が含まれているcwallet.ssoファイルの場所を指定します。

ドメインで使用される鍵の抽出の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyに関する項を参照してください。

ウォレットへの鍵の格納の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportEncryptionKeyに関する項を参照してください。

ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』の一般的なウォレットの操作に関する項を参照してください。

- srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- skipでは、互換性のないアーティファクトの移行をスキップするか、ソース・リポジトリで互換性のないアーティファクトを検出したときに終了するかを指定します。互換性のないアーティファクトの移行をスキップして終了しない場合はtrueに設定します。互換性のないアーティファクトが検出されたときに終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- overwriteでは、ターゲット・ストア内のデータを上書きするかどうかを指定します。ターゲット・データを上書きする場合はtrueに設定します。ターゲット・データを上書きしない場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

srcおよびdstで指定するコンテキストは、構成ファイルで定義する必要があり、重複しない名前にし、渡すコンテキストと構成ファイルのコンテキストは大文字小文字の区別まで一致する必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

9.5.2.5 migrateSecurityStoreを使用した1つの資格証明マップの移行

資格証明マップを1つのみ移行するには、次の構文のいずれかを使用します。

migrateSecurityStore.py -type folderCred
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-srcFolder map1]
[-dstFolder map2]
[-srcConfigFile alternConfigFileLocation]
[-overWrite trueOrFalse]
[-skip trueOrFalse]

migrateSecurityStore(type="folderCred",
configFile="jpsConfigFileLocation",
src="srcJpsContext",
dst="dstJpsContext",
[srcFolder="map1"],
[dstFolder="map2"],
[srcConfigFile="alternConfigFileLocation"],
[overWrite="trueOrFalse"],
[skip="trueOrFalse"])

説明:

- configFileでは、構成ファイルの場所を、コマンドが実行されるディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の情報を指定するコンテキストを含める必要があります。

- ソース・ストア

- ターゲット・ストア

- ブートストラップ資格証明

ブートストラップ・コンテキストでは、ソースおよびターゲットのストアへのアクセスと、セキュリティ・データの復号化および暗号化に必要な鍵が含まれているcwallet.ssoファイルの場所を指定します。

ドメインで使用される鍵の抽出の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncryptionKeyに関する項を参照してください。

ウォレットへの鍵の格納の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のimportEncryptionKeyに関する項を参照してください。

ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』のウォレットの一般的な操作に関する説明を参照してください。

- srcでは、configFile引数に渡す構成ファイル内のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- dstでは、configFile引数に渡す構成ファイル内の別のコンテキストの名前を指定します。渡す文字列と構成ファイルのコンテキストは、大文字小文字の区別まで一致している必要があります。

- skipでは、互換性のないアーティファクトの移行をスキップするか、ソース・リポジトリで互換性のないアーティファクトを検出したときに終了するかを指定します。互換性のないアーティファクトの移行をスキップして終了しない場合はtrueに設定します。互換性のないアーティファクトが検出されたときに終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- srcFolderでは、移行する資格証明が含まれるマップの名前を指定します。オプション。指定しない場合は、資格証明ストアにはマップが1つのみであると想定され、この引数の値はそのマップの名前にデフォルト設定されます。

- dstFolderでは、ソース資格証明の移行先のマップを指定します。オプション。指定しない場合は、srcFolderに渡されるマップにデフォルト設定されます。

- srcConfigFileでは、代替構成ファイルの場所を指定します。これは、configFileに渡されるファイルで資格証明が構成されていないという特別な場合に使用されます。オプション。指定しない場合は、configFileに渡される値にデフォルト設定されます。指定した場合は、configFileに渡された値は無視されます。

- overWriteでは、ソース資格証明と一致するターゲット資格証明をソース資格証明で上書きするか、ソース資格証明とマージするかを指定します。ターゲット資格証明を上書きする場合はtrueに設定します。一致する資格証明をマージする場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。falseに設定した場合、一致する資格証明が検出されると、ソース資格証明は無視され、警告がログに記録されます。

srcおよびdstで指定するコンテキストは、構成ファイルで定義する必要があり、重複しない名前にし、渡すコンテキストと構成ファイルのコンテキストは大文字小文字の区別まで一致する必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

9.5.2.6 migrateSecurityStoreを使用した監査データの移行

migrateSecurityStore WLSTコマンドを使用して、監査データを別のセキュリティ・ストアに移行します。手順の詳細は、第6.6.3項「監査データの移行」を参照してください。

9.5.2.7 migrateSecurityStoreの使用例

migrateSecurityStoreの使用方法を示す例は、次の各項を参照してください。

- 第6.6.2.1項「migrateSecurityStoreを使用したポリシーの移行」

- 第6.6.2.2項「migrateSecurityStoreを使用した資格証明の移行」

- 第6.6.3項「監査データの移行」

- 第6.6.4項「migrateSecurityStoreを使用した鍵および証明書の移行」

9.6 Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成

この項に記載されている手順に従い、Fusion Middleware Controlを使用して、セキュリティ・ストアの移行、アイデンティティ・ストア・プロバイダおよびセキュリティ・サービスの構成、ログイン・モジュールおよびプロパティの管理を行います。

1. タスク1: 「セキュリティ・プロバイダ構成」ページのオープンく

2. タスク2: セキュリティ・ストアの移行

3. タスク3: アイデンティティ・ストア・プロバイダの構成

4. タスク4: セキュリティ・サービスの構成

5. タスク5: ログイン・モジュールの管理

6. タスク6: プロパティおよびプロパティ・セットの管理

タスク1: 「セキュリティ・プロバイダ構成」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」の順に移動します。「セキュリティ・プロバイダ構成」ページが表示されます。

タスク2: セキュリティ・ストアの移行

1. 「セキュリティ・ストア・プロバイダ」→「セキュリティ・ストア」の順に開きます。

2. 「ストア・タイプの変更」をクリックします。「セキュリティ・ストアの構成」ページが表示されます。このページで、ターゲット・リポジトリのパラメータを入力します。

3. 「OK」をクリックします。

タスク3: アイデンティティ・ストア・プロバイダの構成

1. 「セキュリティ・ストア・プロバイダ」→「アイデンティティ・ストア・プロバイダ」の順に開きます。

2. 「構成」ボタンをクリックします。「アイデンティティ・ストア構成」ページが表示されます。このページで、必要に応じてプロパティを追加または編集します。

3. 「OK」をクリックします。

タスク4: セキュリティ・サービスの構成

1. 「セキュリティ・ストア・プロバイダ」→「セキュリティ・サービス(Security Services)」の順に開きます。

2. 鉛筆アイコンをクリックして、プロバイダを構成します。プロバイダのページが表示されます。

3. このページで、必要なフィールドに入力します。

4. 「OK」をクリックします。

タスク5: ログイン・モジュールの管理

1. 「セキュリティ・ストア・プロバイダ」→「ログイン・モジュール」の順に開きます。構成済のログイン・モジュールの表が表示されます。

2. 新規ログイン・モジュールを作成するには、「作成」をクリックします。「ログイン・モジュールの作成」ページが表示されます。ログイン・モジュール・パラメータを入力して「OK」をクリックします。

3. 「編集」をクリックして、ログイン・モジュールを変更します。「ログイン・モジュールの編集」ページが表示されます。パラメータを変更して「OK」をクリックします。

4. 「削除」をクリックして、ログイン・モジュールを削除します。削除を確認します。

タスク6: プロパティおよびプロパティ・セットの管理

1. 「セキュリティ・ストア・プロバイダ」→「拡張プロパティ」の順に開きます。

2. 「構成」ボタンをクリックします。「拡張プロパティ」ページが表示されます。

3. このページで、次のいずれかを実行します。

- 「追加」をクリックして、新しいプロパティを追加します。

- 「編集」をクリックして、プロパティを変更します。

- 「削除」をクリックして、プロパティを削除します。

- 「プロパティ・セットの追加」をクリックして、新しいプロパティ・セットを追加します。

- 「プロパティの追加」をクリックして、新しいプロパティをセットに追加します。

- 「プロパティの編集」をクリックして、プロパティ・セット内のプロパティを変更します。

- 「削除」をクリックして、プロパティ・セットまたはプロパティ・セット内のプロパティを削除します。

10 ポリシーの管理

この章では、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)、WebLogic Scripting Tool (WLST)およびOracle Entitlements Server (OES)を使用してポリシーを管理する方法について説明します。

この章の内容は次のとおりです。

- セキュリティ・ストアの特性の確認

- ポリシー・ストアの管理

- Fusion Middleware Controlを使用したポリシーの管理

- WLSTを使用したポリシーの管理

- ポリシー・キャッシュのリフレッシュ

- WLSTコマンドにおけるプリンシパルとロール

- WLSTコマンドにおけるアプリケーション・ストライプ

- OESを使用したアプリケーション・ポリシーの管理

10.1 セキュリティ・ストアの特性の確認

listSecurityStore WLSTコマンドを使用して、セキュリティ・ストアの属性をいくつか確認します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のlistSecurityStoreに関する項を参照してください。

10.2 ポリシー・ストアの管理

予期しない認可の失敗を防ぎ、効果的にポリシーを管理するには、次の点に注意してください。

- ユーザーを削除する前に、ユーザーに付与されているすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除したユーザーを参照するセキュリティ・データの一部を削除できなかった場合、そのようなアーティファクトは中途半端な状態のままになり、同じ名前の別のユーザーが後で作成された場合に誤って継承される可能性があります。
ユーザー名を変更する場合にも、同様の考え方が当てはまります。認可が変更後のデータでも予期したとおりに機能するように、古いデータを参照するポリシー(権限付与、パーミッション、グループ)をすべて更新する必要があります。

- ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。次のことをお薦めします。

- ポリシーのプロビジョニング時に、ポリシーで使用するユーザーおよびグループの名前の文字構成をアイデンティティ・ストアでの文字構成とまったく同じにします。

- 実行時にユーザー名を入力する際には、アイデンティティ・ストアでの大文字/小文字の組合せと完全に一致する名前を入力します。

- リソース・タイプ、リソースまたは権限の名前には印刷可能文字のみを使用でき、先頭または末尾に空白を使用することはできません。

- デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗(JpsAuth.checkPermissionの失敗など)がコンソールに表示されるようにするには、システム変数jps.auth.debugをtrueに設定します。

次の各項では、Fusion Middleware Control、WLSTおよびOESを使用してポリシーを管理する方法について説明します。代表的な操作は次のとおりです。

- Fusion Middleware Controlを使用したポリシーの管理

- WLSTを使用したポリシーの管理

- OESを使用したアプリケーション・ポリシーの管理

関連項目:

第J.5.2項「パーミッションの取得の失敗 - 大文字と小文字の不一致」

第J.5.4項「ユーザーによる予期しないパーミッションの取得」

第J.10.5項「ポリシーに使用する文字」

10.3 Fusion Middleware Controlを使用したポリシーの管理

Fusion Middleware Controlでは、次の各項で説明しているように、WebLogic Serverドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理することができます。

- アプリケーション・ポリシーの管理

- アプリケーション・ロールの管理

- システム・ポリシーの管理

10.3.1 アプリケーション・ポリシーの管理

この項に記載されている手順に従って、Fusion Middleware Controlを使用してアプリケーション・ポリシーを管理します。

1. タスク1: 「アプリケーション・ポリシー」ページのオープン

2. タスク2: アプリケーション・ポリシーの検索

3. タスク3: アプリケーション・ポリシーの作成

4. タスク4: 別のアプリケーション・ポリシーに似たアプリケーション・ポリシーの作成

タスク1: 「アプリケーション・ポリシー」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ポリシー」の順に移動します。「アプリケーション・ポリシー」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: アプリケーション・ポリシーの検索

「検索」領域で、アプリケーション・ストライプを選択し、(プリンシパル名、プリンシパル・グループまたはアプリケーション・ロールと)照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。

タスク3: アプリケーション・ポリシーの作成

アプリケーション・ストライプを選択して、「作成」をクリックします。「アプリケーション権限の作成」ページが表示されます。このページで、必要に応じてプリンシパルおよびパーミッションを権限付与に追加します。

1. パーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログを表示します。
このダイアログの「検索」領域で、「権限」または「リソース・タイプ」を選択します。「権限」を選択した場合は、クラスまたはリソースの名前に一致するパーミッションを特定し、「権限クラス」および「リソース名」を決定します。「リソース・タイプ」を選択した場合は、タイプ名に一致するリソース・タイプを特定し、タイプを決定します。次に、「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したパーミッションが、「権限」領域の表に表示されます。

2. プリンシパルを追加するには、「権限受領者」領域の「追加」をクリックして、「プリンシパルの追加」ダイアログを表示します。
このダイアログの「検索」領域で、タイプを選択し、プリンシパル名および表示名と照合する文字列を入力して検索ボタンをクリックします。問合せの結果は、「検索済プリンシパル」表に表示されます。次に、この表から1行以上選択し、「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したプリンシパルが、「権限受領者」領域の表に表示されます。

3. 「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。新しいポリシーがページの下部の表に表示されます。

タスク4: 別のアプリケーション・ポリシーに似たアプリケーション・ポリシーの作成

1. ポリシーを選択します。

2. 「類似作成」をクリックします。アプリケーション権限の類似作成ページが表示され、選択したポリシーから抽出されたデータがパーミッションの表に入力されます。

3. 必要に応じて値を変更して「OK」をクリックします。

10.3.2 アプリケーション・ロールの管理

この項に記載されている手順に従って、Fusion Middleware Controlを使用してアプリケーション・ロールを管理します。

1. タスク1: 「アプリケーション・ロール」ページのオープン

2. タスク2: アプリケーション・ロールの検索

3. タスク3: アプリケーション・ロールの作成

4. タスク4: ロールへのアプリケーション・ロールの追加

5. タスク5: 別のアプリケーション・ロールに似たアプリケーション・ロールの作成

タスク1: 「アプリケーション・ロール」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ロール」の順に移動します。「アプリケーション・ロール」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: アプリケーション・ロールの検索

「検索」領域で、アプリケーション・ストライプを選択し、照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。

タスク3: アプリケーション・ロールの作成

「作成」をクリックして「アプリケーション・ロールの作成」ページを表示します。

このページでは、データを一度に全部入力する必要はありません。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後で指定できます。同様に、後でロール・マッピングを指定することもできます。

「一般」領域で、次の情報を入力します。

- 「ロール名」テキスト・フィールドに、ロールの名前を入力します。

- 「表示名」テキスト・フィールドに、ロールに表示する名前を入力します(オプション)。

- 「説明」テキスト・フィールドに、ロールの説明を入力します(オプション)。

- 「メンバー」領域で、ロールのマップ先とするユーザー、グループまたは他のアプリケーション・ロールを指定します。

タスク4: ロールへのアプリケーション・ロールの追加

1. ロールを選択し、「追加」をクリックします。「プリンシパルの追加」ダイアログが表示されます。

2. 「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名と照合する文字列を入力して検索ボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。この表からプリンシパルを1つ以上選択します。

3. ロールを追加するプリンシパルを1つ以上選択します。

4. 「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。新しいアプリケーション・ロールが「メンバー」表に表示されます。

タスク5: 別のアプリケーション・ロールに似たアプリケーション・ロールの作成

1. ロールを選択します。

2. 「類似作成」をクリックします。アプリケーション・ロールの類似作成ページが表示され、選択したロールから抽出されたデータが一部のエントリに入力されます。

3. ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。

ロールの階層でパーミッションがどのように継承されるかを理解するには、第2.2.1項「パーミッションの継承とロールの階層」を参照してください。

10.3.3 システム・ポリシーの管理

この項に記載されている手順に従って、Fusion Middleware Controlを使用してシステム・ポリシーを管理します。

- タスク1: 「システム・ポリシー」ページのオープン

- タスク2: システム・ポリシーの検索

- タスク3: システム・ポリシーの作成

タスク1: 「システム・ポリシー」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「システム・ポリシー」の順に移動します。「システム・ポリシー」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: システム・ポリシーの検索

「検索」領域で、タイプを選択し、照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。

タスク3: システム・ポリシーの作成

1. 「作成」をクリックします。「システム権限の作成」ページが表示されます。

2. 作成するポリシーのタイプとして、「プリンシパル」または「コードベース」を選択します。次の手順は、「プリンシパル」を選択した場合のものです。

3. パーミッションを追加するには、「追加」ボタンをクリックします。「権限の追加」ダイアログが表示されます。作成しているポリシーに追加するパーミッションを選択します。

- 「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。検索結果が「検索」領域の表に表示されます。

- 追加するパーミッションを選択します。詳細が読取り専用の「カスタマイズ」領域に表示されます。

- 「OK」をクリックして、「システム権限の作成」ページに戻ります。パーミッションが「権限」表に表示されます。

4. 「OK」をクリックして、「システム・ポリシー」ページに戻ります。

5. 「コードベースに関する権限」領域の表は読取り専用であり、新しいシステム・ポリシーに関連付けられているリソース名、アクションおよびパーミッション・クラスが表示されます。

10.4 WLSTを使用したポリシーの管理

WLSTオンライン・コマンドとは、実行中のサーバーとの接続が必要なコマンドです。特に指定がないかぎり、この項に記載されているコマンドはオンライン・コマンドで、タイプに関係なくセキュリティ・ストアに対して動作します。動作に実行中のサーバーを必要としないオフラインのコマンドもいくつか存在します。

読取り専用コマンドは、WebLogicグループMonitor、Operator、ConfiguratorまたはAdminに属するユーザーのみが実行できます。読取り/書込みコマンドは、WebLogicグループAdminまたはConfiguratorに属するユーザーのみが実行できます。すべてのコマンドは、Oracle WebLogic Serverをインストールすると使用できます。

WLSTコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力します。スクリプト・モードでは、シェル・スクリプトのディレクティブのように、コマンドをテキスト・ファイルに記述してスクリプトを実行します。

コマンドで指定するクラス名はすべて、完全修飾パス名にする必要があります。

OPSSでは、アプリケーション・ポリシーを管理するために次のコマンドが用意されています。

- listAppStripes

- listCodeSourcePermissions

- createAppRole

- deleteAppRole

- grantAppRole

- revokeAppRole

- listAppRoles

- listAppRolesMembers

- grantPermission

- revokePermission

- listPermissions

- deleteAppPolicies

- createResourceType

- getResourceType

- deleteResourceType

- createResource

- deleteResource

- listResources

- listResourceActions

- createEntitlement

- getEntitlement

- deleteEntitlement

- addResourceToEntitlement

- revokeResourceFromEntitlement

- listEntitlements

- grantEntitlement

- revokeEntitlement

- listResourceTypes

- reassociateSecurityStore

- migrateSecurityStore。第9.5.2項「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。

関連項目:

第5.4.1項「WLSTを使用したセキュリティ・プラクティス」

第10.6項「WLSTコマンドにおけるプリンシパルとロール」

第10.7項「WLSTコマンドにおけるアプリケーション・ストライプ」

10.4.1 reassociateSecurityStore

reassociateSecurityStore WLSTコマンドは、セキュリティ・ストアをソース・ストアからターゲット・ストアに移行し、jps-config.xmlファイルとjps-config-jse.xmlファイルでサービス構成をターゲット・リポジトリに再設定します。このコマンドは、インタラクティブ・モードでのみサポートされます。

ソース・ストアは、ファイル、LDAPまたはDBのいずれかのセキュリティ・ストアです。ターゲット・ストアは、新しいストアでも他のドメインにある既存のストア(後述のオプションのjoin引数を参照)でもかまいません。ターゲット・ストアが他のドメインにあるストアの場合、ソース・データをターゲット・ストアに追加するかどうかを指定します(後述のオプションのmigrate引数を参照)。

ソース・ストアのバージョンは、ターゲット・ストアのバージョン以上である必要があります。ソースのバージョンがターゲットのバージョンよりも新しい場合、コマンドではソースとターゲットのセキュリティ・データ間の互換性チェックを実行します。skip引数をtrueに設定することで、アーティファクトのいずれかでチェックがエラーとなった場合、コマンドは互換性のないアーティファクトの移行をスキップできます。この引数がtrueでない場合、互換性のないアーティファクトが検出されると、コマンドは終了します。

このコマンドはブートストラップ資格証明をリセットします(後述のadmin引数とpassword引数を参照)。ブートストラップ資格証明をリセットする別の方法については、modifyBootStrapCredentialコマンドとaddBootStrapCredentialコマンドを参照してください。

コマンド構文

コマンド構文は、ターゲット・ストアのタイプに応じて異なります。ターゲットがLDAPストアの場合は、次の構文を使用します(見やすくするために引数をそれぞれ別の行に記述しています)。

reassociateSecurityStore(domain="domainName",
servertype="OID",
ldapurl="hostAndPort",
jpsroot="cnSpecification",
admin="cnSpecification",
password="passWord",
[join="trueOrfalse"] [,keyFilePath="dirLoc", keyFilePassword="password"]]
[migrate="trueOrfalse"]
[skip="trueOrfalse"])

ターゲットがDBセキュリティ・ストアの場合は、次の構文を使用します(見やすくするために引数をそれぞれ別の行に記述しています)。

reassociateSecurityStore(domain="domainName",
servertype="DB_ORACLE",
datasourcename="datasourceName",
jpsroot="jpsRoot",
jdbcurl="jdbcURL",
jdbcdriver="jdbcDriverClass",
dbUser="dbUserName",
dbPassword="dbPassword",
[admin="adminAccnt", password="passWord",]
[,join="trueOrfalse"
[,keyFilePath="dirLoc", keyFilePassword="password"]                         [,migrate="trueOrfalse" [,skip="trueOrfalse"]]])
[odbcdsn="odbcDsnSting"]
[migrate="trueOrfalse"]
[skip="trueOrfalse"])

join、migrateおよびskipの各引数の使用に関する要点を次にまとめます。

- migrate引数が意味を持つのはjoinがtrueである場合のみです。それ以外の場合は、無視されます。したがって、移行が必要である場合は、joinとmigrateの両方をtrueに設定する必要があります。

- joinとmigrateが両方ともtrueである場合、引数keyFilePathおよびkeyFilePasswordは必須です。

- join引数とmigrate引数がいずれもtrueであるときに、skipがtrueの場合、ターゲット・ストアと互換性のないアーティファクトの移行はスキップされます。skipがfalseの場合、互換性のないアーティファクトが検出されるとコマンドは終了します。スキップがサポートされているのは、汎用の資格証明に対してのみです。

引数の説明は、次のとおりです。

- domain: ターゲット・ストアが配置されているドメイン名を指定します。

- adminでは、LDAPターゲットの場合、ターゲット・サーバーでの管理者のユーザー名を指定します。形式はcn=usrNameです。
DBセキュリティ・ストアの場合は、ユーザーおよびパスワードで保護されているデータ・ソースがデータベースにあるときのみ必要です。その場合、この引数ではデータ・ソースの作成時にデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。指定した場合は、passwordも指定する必要があります。

- passwordでは、adminで指定したユーザーに関連付けられているパスワードを指定します。LDAPターゲットの場合にのみ必要です。
DBセキュリティ・ストアの場合は、保護されているデータ・ソースがデータベースにあるときのみ必要です。その場合、adminで指定したユーザーに関連付けられているパスワードを指定します。指定した場合は、adminも指定する必要があります。

- ldapurlでは、LDAPサーバーのURIを指定します。形式は、デフォルトのポートを使用している場合はldap//host:port、匿名Secure Sockets Layer (SSL)または一方向SSLを使用している場合はldaps://host:portを使用します。セキュア・ポートは、目的のSSL接続モードを処理するように構成し、デフォルトの(セキュアではない)ポートとは別のポートにする必要があります。

- servertypeでは、ターゲット・ストアの種類を指定します。有効なタイプは、OIDまたはDB_ORACLEです。

- jpsrootでは、ターゲットLDAPリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。

- joinでは、ターゲット・ストアが他のドメインにあるストアであるかどうかを指定します。オプション。他のドメインにあるターゲット・ストアを共有する場合は、trueに設定します。それ以外の場合は、falseに設定します。指定しない場合は、デフォルトのfalseに設定されます。この引数を使用すると、複数のWebLogic Serverドメインで同じセキュリティ・ストアを指すことができるようになりますが、次の点に注意してください。

- セキュリティ・ストアへの結合がサポートされるのは、新しいドメインを作成する場合のみです。

- 2つのドメインにある異なる2つのセキュリティ・ストアのマージはサポートされていません。

- joinがtrueの場合、OPSS暗号化鍵を一方のドメインからエクスポートして他方のドメインにインポートする必要があります。

注意:
暗号化鍵をエクスポートしてインポートするには、次の手順を実行します。代替手順については、keyFilePath引数を参照してください。
Domain1にセキュリティ・ストアがあり、joinをtrueに設定してDomain2がDomain1のセキュリティ・ストアに再関連付けされたとします。その場合は、次の手順を実行します。

1. exportEncryptionKey WLSTコマンドを使用して、Domain1からewallet.p12ファイルに鍵を抽出します。渡されたkeyFilePassword引数の値は、後でその鍵を2つ目のドメインにインポートするときに使用する必要があります。

2. importEncryptionKey WLSTコマンドを使用して、抽出したewallet.p12ファイルをDomain2にインポートします。keyFilePassword引数の値は、ewallet.p12ファイルの生成時に使用したものと同一である必要があります。

3. Domain2のサーバーを再起動します。

エクスポートおよびインポートのコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncrytionKeyに関する項およびimportEncryptionKeyに関する項を参照してください。

- migrateが意味を持つのはjoinがtrueである場合のみで、それ以外の場合は無視されます。結合したストアにソース・ストアのデータを追加するかどうかを指定します。ソース・データをターゲット・ストアに追加する場合はtrueに設定します。ソース・データを追加せずにターゲット・ストアに結合する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- skipが意味を持つのはjoinとmigrateの両方がtrueである場合のみで、それ以外の場合は無視されます。互換性のないアーティファクトの移行をスキップするかどうかを指定します。ターゲット・ストアへの互換性のないアーティファクトの追加をスキップしてコマンドを終了しない場合はtrueに設定します。ソース・ストアで互換性のないアーティファクトが検出されたときにコマンドを終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。

- datasourcenameでは、Java Database Connectivity (JDBC)データ・ソースのJava Naming and Directory Interface (JNDI)名を指定します。この値は、データ・ソースの作成時に入力したJNDI名データ・ソースの値と同一である必要があります。

- keyFilePathでは、ターゲット・ドメインのewallet.p12ファイルが配置されているディレクトリを指定します。このファイルの内容は、keyFilePasswordに渡される値により暗号化され、保護されます。joinがtrueである場合のみ必須です。
joinがtrueの場合、暗号化鍵を一方のドメインからエクスポートして他方にインポートする必要があります。これらのタスクは、keyFilePath引数とkeyFilePassword引数を使用すると、自動的に実行されます。

Domain1にセキュリティ・ストアがあり、joinをtrueに設定し、keyFileの引数を使用してDomain2がDomain1のセキュリティ・ストアに再関連付けされているとします。その場合、まず適切な引数値を指定してreassociateSecurityStore WLSTコマンドを実行し、次にDomain2のサーバーを再起動します。暗号化鍵をエクスポートしてインポートする代替手順については、join引数の説明の注意を参照してください。

- keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。joinがtrueである場合のみ必須です。

- jdbcurlでは、Java SEアプリケーションでデータベースへの接続に使用するJDBC URLを指定します。Java SEアプリケーションにのみ適用されます。必須。jdbcdriver、dbUserおよびdbPasswordの各引数とともに使用する必要があります。

- jdbcdriverでは、データベースへの接続に使用するJDBCドライバのクラスを指定します。必須。jdbcurl引数とともに使用する必要があります。

- dbUserでは、ブートストラップ資格証明に追加する(資格証明ストア内の)データベース・ユーザーを指定します。必須。jdbcurl引数とともに使用する必要があります。

- dbPasswordでは、dbUserを使用して指定したユーザーのパスワードを指定します。必須。jdbcurl引数とともに使用する必要があります。

- odbcdsnでは、C資格証明ストア・フレームワークAPIで使用するOpen Database Connectivity (ODBC)データ・ソース名を指定します。Cプログラムにのみ適用されます。

再関連付けの例

次の例では、DBセキュリティ・ストアに再関連付けする方法を示します。

reassociateSecurityStore(domain="targetDomain", servertype="DB_ORACLE",
jpsroot="cn=jpsroot", datasourcename="jdbc/opssds",
jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",
dbUser="test_opss", dbPassword="mypass",
jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource")

ソース・セキュリティ・ストアの内容を移行せずにotherDomain内のセキュリティ・ストアを共有するには、次のようにします。

reassociateSecurityStore(domain="otherDomain", servertype="DB_ORACLE",
jpsroot="cn=jpsroot", datasourcename="jdbc/opssds",
jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",dbUser="test_opss",
dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource",
join="true", keyFilePath="/tmp/myFileDirectory", keyFilePassword="password")

otherDomain内のセキュリティ・ストアを共有し、互換性のないアーティファクトをスキップしながら、ソース・セキュリティ・ストアの内容をターゲットDBセキュリティ・ストアに移行するには、次のようにします。

reassociateSecurityStore(domain="otherDomain", servertype="DB_ORACLE",
jpsroot="cn=jpsroot", datasourcename="jdbc/opssds",
jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",dbUser="test_opss",
dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource",
join="true", migrate="true", skip="true",
keyFilePath="/tmp/myFileDirectory", keyFilePassword="password")

10.5 ポリシー・キャッシュのリフレッシュ

このトピックは、LDAPセキュリティ・ストアとDBセキュリティ・ストアにのみ適用されます。ファイル・ストアの場合、キャッシュは数秒後に更新されます。

OPSSは、キャッシュ・セキュリティ・アーティファクトによって認可プロセスを最適化します。セキュリティ・アーティファクトを変更した場合、アーティファクトおよびアプリケーションの変更に使用したツールが実行されている場所によって変更が有効になるタイミングが異なります。

- アプリケーションとツールの両方が同じホスト上および同じドメイン内で実行されている場合、変更は即座に有効になります。

- そうではなく、アプリケーションとツールが異なるホストまたは異なるドメイン内で実行されている場合、変更はストア・キャッシュのリフレッシュ後に有効になります。キャッシュのリフレッシュの頻度は、oracle.security.jps.ldap.policystore.refresh.intervalプロパティの値によって決まります。デフォルト値は10分です。
ドメイン内で、WLSTまたはFusion Middleware Controlを使用して加えられた変更はいずれも、最初は管理サーバーでのみ考慮されます。サーバーの再起動時にのみ、その変更はドメイン内のすべての管理対象サーバーにプッシュされます。

10.5.1 ポリシー・リフレッシュを使用した認可のシナリオ

次の使用例では、セキュリティ・データの変更に(別のドメインまたはホストの)OESを使用し、oracle.security.jps.ldap.policystore.refresh.intervalプロパティを10分に設定した場合のシナリオにおける認可の動作を示します。

このケースの前提は次のとおりです。

- ユーザーはエンタープライズ・ロールのメンバー

- このエンタープライズ・ロールは、アプリケーション・ロールのメンバーに含まれている

- このアプリケーション・ロールにはアプリケーション機能の一部を制御するパーミッションが付与されている

次のシナリオを考えてみます。

1. ユーザーがアプリケーションにログインします。

2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

3. 別のホスト(またはドメイン)から、エンタープライズ・ロールをアプリケーション・ロールから削除します。

続いて、次のアクションと結果を考えてみます。

- ユーザーはアプリケーションからログアウトして、ただちにログインしなおします。手順3で加えた変更でポリシー・キャッシュがまだリフレッシュされていないため、ユーザーは依然としてアプリケーション・ロールによって保護された機能にアクセスできます。

- ユーザーはアプリケーションからログアウトして、10分後にログインしなおします。手順3で加えた変更でポリシー・キャッシュがリフレッシュされているため、ユーザーはアプリケーション・ロールによって保護された機能にアクセスできません。

- ユーザーはログアウトしないと、手順3で加えた変更でポリシー・キャッシュがまだリフレッシュされていないため、10分間はアプリケーション・ロールによって保護された機能へのアクセスが可能な状態のままです。

- ユーザーはログアウトせず、10分より長く待機してから、アプリケーション・ロールによって保護された機能へのアクセスを試行すると、手順3で加えた変更でポリシー・キャッシュがリフレッシュされているため、アクセスは拒否されます。

10.6 WLSTコマンドにおけるプリンシパルとロール

一部のコマンドでは、myAppアプリケーション・ストライプのmyAppRoleロールにプリンシパルが追加される次のコマンドのように、操作にかかわるロールのプリンシパル名とプリンシパル・クラスを指定する必要があります。

grantAppRole.py -appStripe myApp
-appRoleName myAppRole
-principalClass myPrincipalClass
-principalName myPrincipal

プリンシパルが認証ロールまたは匿名ロールを参照する場合、プリンシパル名とプリンシパル・クラスは決まっており、次の名前/クラス・ペアのいずれかである必要があります。

- 認証ロール

- authenticated-role

- oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl

- 匿名ロール

- anonymous-role

- oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl

次のWLSTコマンドでは、プリンシパル名とプリンシパル・クラスの指定が必要です。

- grantAppRole

- revokeAppRole

- grantPermission

- revokePermission

- listPermissions

10.7 WLSTコマンドにおけるアプリケーション・ストライプ

一部のコマンドでは、アプリケーション・ストライプの指定が必要です。アプリケーションにバージョンがない場合は、アプリケーション・ストライプがアプリケーション名にデフォルト設定されます。そうではなく、アプリケーションにバージョンがある場合は、アプリケーション名とアプリケーション・ストライプが同じではありません。

たとえば、バージョン1のmyAppアプリケーションの名前はmyApp(v1.0)ですが、アプリケーション・ストライプの名前はmyApp#v1.0です。より一般的には、名前がappName(vers)のアプリケーションは、アプリケーション・ストライプappName#versに割り当てられます。このパターンの文字列をアプリケーション・ストライプ名として渡します。

>listAppRoles myApp#v1.0

次のWLSTコマンドでは、ストライプの指定が必要です。

- createAppRole

- deleteAppRole

- grantAppRole

- revokeAppRole

- listAppRoles

- listAppRoleMembers

- grantPermission

- revokePermission

- listPermissions

- deleteAppPolicies

10.8 OESを使用したアプリケーション・ポリシーの管理

OESを使用すると、WebLogic Serverドメインのアプリケーション・ポリシーおよびその他のセキュリティ・データを管理および検索できます。

OESを使用したポリシーの管理の詳細は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』の次の項を参照してください。

- セキュリティ・アーティファクトの問合せ

- ポリシーおよびロールの管理

11 資格証明の管理

OPSSには、アプリケーションで資格証明を作成、読取り、更新および管理する際に使用するインタフェースの集合である資格証明ストア・フレームワークが組み込まれています。資格証明は資格証明ストアに格納されるため、このフレームワークでは資格証明の暗号化がサポートされています。

この章の内容は次のとおりです。

- 資格証明のタイプ

- 資格証明の暗号化

- Fusion Middleware Controlを使用した資格証明の管理

- WLSTを使用した資格証明の管理

11.1 資格証明のタイプ

資格証明には、ユーザー名、パスワードおよびチケットを格納でき、資格証明の暗号化も可能です。資格証明は、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。

OPSSでは、そこに置かれたデータに応じて次のタイプの資格証明がサポートされています。

- パスワード資格証明は、ユーザー名とパスワードをカプセル化します。

- 汎用資格証明は、対称キーなどの任意のカスタマイズされたデータまたは任意のトークンをカプセル化します。

資格証明は、マップ名およびキー名によって一意に識別されます。マップには複数のキーを保持でき、マップ名はアプリケーションの名前に対応しています。同じマップ名を持つ資格証明すべてにより、資格証明のグループ(アプリケーションで使用される資格証明など)が定義されます。マップ名とキー名のペアは、資格証明ストアにあるすべてのエントリで一意である必要があります。

パスワードに使用できる文字数に制限はありませんが、空やnullにはできません。

デフォルトでは、資格証明ストアはOracleウォレットで、X.509証明書を格納できます。

11.2 資格証明の暗号化

OPSSでは、ファイルおよびLDAPの資格証明ストアへの暗号化データの格納がサポートされています。OPSSでは、暗号化鍵を使用して、資格証明ストアでの読み書き時にデータの暗号化と復号化を行います。この鍵は一意で、ドメイン・スコープがあります。ファイルまたはLDAPのストアでの資格証明の暗号化を有効にするには、jps-config.xmlファイルの資格証明ストア・インスタンスで次のプロパティを設定します。

<property name="encrypt" value="true" />

DB資格証明ストアの場合、データは常にクライアント側の鍵を使用して暗号化されます。

ドメイン暗号化鍵

encryptプロパティをtrueに設定した場合、OPSSでは暗号化鍵を使用して、資格証明ストアに入力された新しい資格証明が暗号化されます。この暗号化鍵は、ドメインが初めて起動されたときにランダムに生成される128ビットの高度暗号化標準(AES)鍵で、ドメイン全体で有効です。最終的には、このドメイン暗号化鍵の定期的なロールオーバーが必要になります。鍵をロールオーバーすると、新しい鍵が生成され、前の鍵はアーカイブされます。アーカイブされた鍵は古いデータの復号化に使用され、新しい鍵は新しいデータの暗号化および復号化に使用されます。

新しいドメイン暗号化鍵が生成されても、資格証明ストア・データはこの新しい鍵でただちに暗号化されるわけではありません。データは書き込まれたときにのみ(新しいキーで)暗号化されます。つまり、すべてのデータが同じ暗号化鍵を使用するようにするには、すべての資格証明を読み取って書き込む必要があります。

資格証明ストアを共有するドメイン

2つ以上のドメインが資格証明ストアを共有し、そのストアで暗号化が有効になっている場合、各ドメインは同じ暗号化鍵を使用する必要があります。これを容易にするために、OPSSにはcwallet.ssoブートストラップ・ファイルに鍵をエクスポート、インポートおよびリストアするためのオフライン・スクリプトが用意されているため、1つのドメインで生成された暗号化鍵を、資格証明ストアを共有する他のすべてのドメインに引き継ぐことができます。

次のシナリオでは、Domain1とDomain2という2つのドメインから構成されるクラスタで暗号化鍵を設定する方法を示します。(ドメインが3つ以上がある場合は、各追加ドメインをDomain2として扱ってください。)

注意:
次の各シナリオではLDAP資格証明ストアを前提としていますが、(データが常に暗号化されている)DB資格証明ストアでも、importEncryptionKeyコマンドとexportEncryptionKeyコマンドを使用してドメイン間で鍵をインポートしてエクスポートすることができます。

シナリオ1

Domain1はLDAP資格証明ストアに再関連付けされており、Domain2はそのストアにまだ結合していないものとします。そのストアで資格証明の暗号化を有効にするには、次の手順を実行します。

1. Domain1のjps-config.xmlファイルでencryptプロパティをtrueに設定し、ドメインを再起動します。

2. exportEncryptionKey WebLogic Scripting Tool (WLST)コマンドを使用して、Domain1からewallet.p12ファイルに鍵を抽出します。コマンドに渡したkeyFilePasswordの値は、後でその鍵をもう1つのドメインにインポートするときに使用する必要があります。

3. Domain2のjps-config.xmlファイルでencryptプロパティをtrueに設定します。

この時点で、この手順は次の2つのいずれかの方法で完了します。いずれの方法でも、reassociateSecurityStore WLSTコマンドを使用しますが、構文が異なります。

1つ目の方法は次のとおりです。

1. reassociateSecurityStore WLSTコマンドを使用して、Domain2の資格証明ストアをDomain1で使用されている資格証明ストアに再関連付けします。join引数を使用し、keyFilePassword引数とkeyFilePath引数は使用しないでください。

2. importEncryptionKey WLSTコマンドを使用して、抽出したewallet.p12ファイルをDomain2にインポートします。keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同一である必要があります。

3. Domain2のサーバーを再起動します。

2つ目の方法は次のとおりです。

1. reassociateSecurityStore WLSTコマンドを使用して、Domain2の資格証明ストアをDomain1で使用されている資格証明ストアに再関連付けします。join、keyFilePasswordおよびkeyFilePathの各引数を使用します。

2. Domain2のサーバーを再起動します。

シナリオ2

Domain1はLDAP資格証明ストアに再関連付けされており、Domain2はそのストアにすでに結合しているものとします。そのストアで資格証明の暗号化を有効にするには、次の手順を実行します。

1. Domain1のjps-config.xmlファイルでencryptプロパティをtrueに設定し、ドメインを再起動します。

2. exportEncryptionKey WLSTコマンドを使用して、Domain1からewallet.p12ファイルに鍵を抽出します。コマンドに渡したkeyFilePasswordの値は、後でその鍵をもう1つのドメインにインポートするときに使用する必要があります。

3. Domain2のjps-config.xmlファイルでencryptプロパティをtrueに設定します。

4. importEncryptionKey WLSTコマンドを使用して、抽出したewallet.p12ファイルをDomain2に書き込みます。keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同一である必要があります。

5. Domain2のサーバーを再起動します。

注意:
暗号化が有効になっている資格証明ストアを複数のドメインで共有している場合、これらのドメインのいずれかでロールオーバー鍵が生成されるたびに、exportEncryptionKeyコマンドとimportEncryptionKeyコマンドを使用して、他の各ドメインにそのキーをインポートする必要があります。

関連項目:

「WLSTを使用した資格証明の管理」

第10.4.1項「reassociateSecurityStore」

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncrytionKeyに関する項およびimportEncryptionKeyに関する項

11.3 Fusion Middleware Controlを使用した資格証明の管理

この項に記載されている手順に従って、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用して資格証明を管理します。

- タスク1: 「資格証明」ページのオープン

- タスク2: 資格証明の検索

- タスク3: 資格証明マップの作成

- タスク4: 資格証明マップへのキーの追加

- タスク5: キーの編集

タスク1: 「資格証明」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「資格証明」の順に移動します。「資格証明」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: 資格証明の検索

指定したキー名と一致する資格証明を表示するには、「資格証明キー名」テキスト・フィールドに照合する文字列を入力して検索ボタンをクリックします。検索結果がページの下部の表に表示されます。

タスク3: 資格証明マップの作成

1. 「マップの作成」をクリックします。「マップの作成」ダイアログが表示されます。

2. 新しい資格証明のマップの名前を入力します。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しい資格証明マップ名が表に表示されます。

タスク4: 資格証明マップへのキーの追加

1. 「キーの作成」をクリックします。「キーの作成」ダイアログが表示されます。

2. 「マップの選択」メニューでマップを選択し、キーを「キー」テキスト・フィールドに入力して「タイプ」プルダウン・メニューからタイプ(「パスワード」または「汎用」)を選択します。

- パスワード・キーの場合、「キー」、「ユーザー名」、「パスワード」、「パスワードの確認」の各フィールドに入力します。

- 汎用キーの場合、必須フィールドの「キー」と、資格証明の情報をテキスト(「テキストとして入力」ラジオ・ボタンを選択)またはキー/値ペアのリスト(「プロパティ名と値のペアのマップを入力」ラジオ・ボタンを選択)として入力します。キー/値ペアを追加するには、「行の追加」をクリックし、追加した行の「プロパティ名」、「値」および「値の確認」に入力します。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しいキーが選択したマップの下に表示されます。

タスク5: キーの編集

1. キーを選択します。

2. 「編集」をクリックします。「キーの編集」ダイアログが表示されます。

3. 必要に応じてデータを変更します。汎用キーを編集する場合は、行の横の赤のXを使用すると、対応するプロパティと値のペアが削除されます。

4. 「OK」をクリックして変更内容を保存して、「資格証明」ページに戻ります。

11.4 WLSTを使用した資格証明の管理

オンライン・コマンドの実行には、実行中のサーバーとの接続が必要です。特に指定がないかぎり、この項に記載されているコマンドはオンライン・コマンドで、セキュリティ・ストアに対して動作します。

読取り専用スクリプトは、WebLogicグループMonitor、Operator、ConfiguratorまたはAdminに属するユーザーのみが実行できます。読取り/書込みスクリプトは、WebLogicグループAdminまたはConfiguratorに属するユーザーのみが実行できます。すべてのWLSTコマンドは、Oracle WebLogic Serverをインストールすると使用できます。

WLSTコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力します。スクリプト・モードでは、シェル・スクリプトのディレクティブのように、コマンドをテキスト・ファイルに記述してスクリプトを実行します。

OPSSでは、アプリケーション資格証明を管理するために次のコマンドが用意されています。

- updateCred

- createCred

- deleteCred

- modifyBootStrapCredential

- addBootStrapCredential

- exportEncryptionKey

- importEncryptionKey

- restoreEncryptionKey

- rollOverEncryptionKey

関連項目:

第5.4.1項「WLSTを使用したセキュリティ・プラクティス」の注意

第10.4項「WLSTを使用したポリシーの管理」の注意

12 鍵と証明書の管理

キーストア・サービスでは、Secure Sockets Layer (SSL)、メッセージ・セキュリティ、暗号化、特別な証明書を必要とするその他のタスク用の鍵および証明書を管理できます。

この章の内容は次のとおりです。

- キーストア・サービスについて

- Fusion Middleware Controlを使用したキーストアの管理

- WLSTを使用したキーストアの管理

- 証明書について

- Fusion Middleware Controlを使用した証明書の管理

- WLSTを使用した証明書の管理

- サードパーティのCA署名証明書の使用

- Fusion Middlewareコンポーネントでのキーストア・サービスの使用方法

- キーストア・サービス・コマンドについて

- キーストア・サービスでのSSLの構成

- LDAPとJKS間のSSLの設定

12.1 キーストア・サービスについて

キーストア・サービスでは、SSL、メッセージ・セキュリティ、暗号化、鍵および証明書を必要とするその他のタスク用の鍵および証明書を管理できます。一般的なキーストア管理タスクには、次のものがあります。

- アプリケーション・ストライプのコンテキストでキーストアを直接作成、またはファイル・システムからキーストア・ファイルをインポートして作成。

- キーストアのリストの表示と、更新のためのその一部の選択。

- キーストアの更新および削除。

- キーストア・パスワードの変更。

- キーストアのエクスポートおよびインポート。

次の各項目で、キーストア・サービスの概要を説明します。

- キーストア・サービスの構造

- キーストアのタイプ

- トラストストア

12.1.1 キーストア・サービスの構造

キーストアは、アプリケーション・ストライプおよびそのストライプ内のキーストアによって一意に識別されます。キーおよび証明書はストライプ内のキーストアに作成されます。セキュリティ・ストア内のストライプ名はセキュリティ・ストアで一意であり、ストライプ内のキーストア名はストライプで一意です。たとえば、(stripe1,keystoreA)、(stripe1,keystoreB),および(stripe2,keystoreA)は、3つの異なるキーストアを指します。

アプリケーションは、アプリケーション・ストライプ内に複数のキーストアを作成できます。

キーストアには、キーストア内で一意の別名によって参照される次のエントリを含めることができます。

- 非対称鍵: SSLで使用される公開鍵および秘密鍵が含まれます。公開鍵は証明書内にラップされます。

- 対称鍵: 通常、暗号化に使用されます。

- 信頼できる証明書: SSLピアとの信頼を構築するために使用されます。

12.1.2 キーストアのタイプ

キーストア・サービスでは、次の2つのタイプのキーストアを作成できます。

- ポリシーによって保護されるキーストア
このキーストアはポリシーによって保護されるため、ランタイム・コードによるアクセスはコードソース・ポリシーによって保護されます。鍵データは、ドメイン暗号化鍵を使用して暗号化されます。

- パスワードによって保護されるキーストア
このキーストアは、キーストア・パスワードまたはキー・パスワード(あるいはその両方)によって保護されます。ランタイム・コードがこれらにアクセスするには、キーストア・パスワードとキー・パスワード(キーストア・パスワードと異なる場合)へのアクセスが必要になります。鍵データは、パスワードベースの暗号化によりキーストア/鍵パスワードを使用して暗号化されます。

パスワードによって保護されるキーストアの使用をお薦めします。ただし、アプリケーションに高レベルのセキュリティが必要な場合は、コードソース・ポリシーによって保護されたキーストアを検討してください。鍵はウォレットに対してエクスポート、インポートおよびリストアできます。

複数のサーバーがあるドメインでは、サポートされているストア・タイプはLDAPまたはDBのみです。キーストア・サービスを使用して、パスワードまたは鍵を管理しないでください。かわりに、資格証明ストアをアプリケーションに使用します。

12.1.3 トラストストア

トラストストアは、最もよく知られたサードパーティ認証局の信頼できる証明書と、キーストア・サービスで構成されているデモ認証局(CA)からの信頼できる証明書が格納されるキーストアです。アプリケーションでSSLを使用する場合、たとえば、証明書に対してトラストストアを指定でき、証明書を格納するための専用のキーストアは必要ありません。

注意:
デモCAには、ハードコードされた秘密鍵が含まれています。本番環境でこのデモCAの証明書を使用も信頼もしないことをお薦めします。サードパーティ証明書の詳細は、「サードパーティのCA署名証明書の使用」を参照してください。

トラストストアは、ドメイン内のすべての製品およびアプリケーションによって共有されます。製品に対する信頼の追加または削除に関する決定は、ドメイン内の他の製品に影響する可能性があります。カスタム・トラストストアの作成は、トラストストアでは製品の信頼管理要件を満たせない場合にのみ検討してください。

トラストストアはすべての製品およびアプリケーションで使用されるように事前に構成されているため、アプリケーションではニーズに応じて複数のキーストアを構成できます。

一方向SSL

一方向SSLの場合、アプリケーションではトラストストアを使用できるため、特別なキーストアを作成する必要はありません。

双方向SSL

双方向SSLの場合、アプリケーションではキーストアを作成して独自のアイデンティティ証明書のみを格納し、他の証明書にはトラストストアを使用します。

12.2 Fusion Middleware Controlを使用したキーストアの管理

次のタスクに従って、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用してキーストアを管理します。

1. タスク1: 「キーストア」ページのオープン

2. タスク2: キーストアの作成

3. タスク3: キーストアの削除

4. タスク4: キーストア・パスワードの変更

タスク1: 「キーストア」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

タスク2: キーストアの作成

1. キーストアの作成先となるストライプを選択します。必要に応じて、ストライプを作成します。

2. 「キーストアの作成」をクリックします。「キーストアの作成」ダイアログが表示されます。

3. このダイアログで、次のデータを入力します。

- キーストア名: 一意の名前。

- 「保護」タイプ: キーストアの保護メカニズム。「ポリシー」または「パスワード」を選択します。パスワードで保護されたキーストアの場合は、有効なパスワードを指定します。

- 権限の付与: コードURLにパーミッションを付与するにはこのチェック・ボックスを選択します。

4. 「OK」をクリックします。新しいキーストアが選択したストライプの下に表示されます。

タスク3: キーストアの削除

キーストアを削除すると、そのキーストア内の証明書もすべて削除されることに注意してください。

1. キーストアが存在するストライプを開いて、行を選択します。

2. 「削除」をクリックします。「キーストアの削除」ダイアログが表示されます。

3. これがパスワードで保護されたキーストアの場合は、パスワードを入力します。

4. 「OK」をクリックします。

タスク4: キーストア・パスワードの変更

このタスクは、パスワードで保護されたキーストアにのみ適用されます。

1. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

2. 「パスワードの変更」をクリックします。「キーストア・パスワードの変更」ダイアログが表示されます。

3. 古いパスワードと新しいパスワードを入力します。

4. 「OK」をクリックします。

12.3 WLSTを使用したキーストアの管理

次のタスクに従って、WebLogic Scripting Tool (WLST)を使用してキーストアを管理します。

1. タスク1: キーストアの作成

2. タスク2: キーストアの削除

3. タスク3: キーストア・パスワードの変更

4. タスク4: キーストアのエクスポート

5. タスク5: キーストアのインポート

タスク1: キーストアの作成

createKeyStore WLSTコマンドを使用します。たとえば、ストライプ名をteststripe1として、パーミッションベースのキーストアを作成します。

svc.createKeyStore(appStripe='teststripe1', name='keystore1', password='mypassword',permission=true)

mypasswordは、keystore1のパスワードです。新しいストライプ名では任意の文字の組合せが可能ですが、フォワード・スラッシュ(/)を使用しないことをお薦めします。キーストア名は、一意である必要があります。

タスク2: キーストアの削除

deleteKeyStore WLSTコマンドを使用します。たとえば、ストライプをappstripe1として、keystore1を削除します。

svc.deleteKeyStore(appStripe='appstripe1', name='keystore1', password='mypassword')

mypasswordは、keystore1のパスワードです。

タスク3: キーストア・パスワードの変更

changeKeyStorePassword WLSTコマンドを使用します。たとえば、ストライプ名をsystemとして、keystore2のパスワードを変更します。

svc.changeKeyStorePassword(appStripe='system', name='keystore2', currentpassword='currentpassword', newpassword='newpassword')

currentpasswordとnewpasswordはそれぞれ、古いパスワードと新しいパスワードです。

タスク4: キーストアのエクスポート

exportKeyStore WLSTコマンドを使用します。

単一の鍵をファイルにエクスポートするには、次のようにします。

svc.exportKeyStore(appStripe='mystripe', name='keystore2', password='mypassword',aliases='myorakey', keypasswords='keypassword1', type='JKS',filepath='/tmp/file.jks')

複数の鍵をファイルにエクスポートするには、aliasesとkeypasswordsのカンマ区切りリストを指定します。

対称鍵をエクスポートするには、次のようにします。

svc.exportKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myorakey', keypasswords='keypassword1', type='JCEKS',filepath='/tmp/file.jks')

ウォレットにエクスポートするには、OracleWalletタイプを使用します。

svc.exportKeyStore(appStripe='mystripe', name='keystore3', password='mypassword',aliases='myorakey1,myorakey2', keypasswords='', type='OracleWallet',filepath='/tmp')

タスク5: キーストアのインポート

importKeyStore WLSTコマンドを使用します。

単一の鍵(myOrakeyなど)をインポートするには、次のようにします。

svc.importKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myOrakey', keypasswords='keypassword1', type='JKS', permission=true, filepath='/tmp/file.jks')

複数の鍵をファイルにインポートするには、aliasesとkeypasswordsのカンマ区切りリストを指定します。

鍵をウォレットからインポートするには、OracleWalletタイプを使用します。

svc.importKeyStore(appStripe='mystripe', name='keystore4', password='owPwd1234',aliases='myorakey1,myorakey2', keypasswords='', type='OracleWallet', permission=true, filepath='/tmp')

12.4 証明書について

キーストア・サービス(KSS)キーストアでは、Javaキーストア(JKS)、Java暗号化拡張機能キーストア(JCEKS)およびOracleウォレットの証明書フォーマットがサポートされています。一般的な証明書管理タスクは、次のとおりです。

- 鍵ペアに対する証明書の作成。

- 証明書に対する証明書署名リクエスト(CSR)の生成とファイルへの保存。

- 送信者を検証し、署名して証明書を返信する認証局へのCSRの送信。

- テキスト・フィールドへの貼付けまたはファイル・システムからのインポートによる、キーストアへのユーザーおよび信頼できる証明書のインポート。

注意:
キーストア・サービスでは、PEM/BASE64でエンコードされた証明書のインポートのみサポートされます。DERでエンコードされた証明書または信頼できる証明書をキーストアにインポートすることはできません。

- キーストアからファイルへの証明書または信頼できる証明書のエクスポート。

- キーストアからの証明書または信頼できる証明書の削除。

公開CA証明書に関する次の点は、12.2.1にアップグレードされたドメインおよび新しい12.2.1 Java Required Files (JRF)ドメインに当てはまります。

- よく知られた公開CA証明書は、systemストライプ内のtrustキーストアでは使用できなくなりました。

- かわりに、よく知られた公開CA証明書を使用してJava SE Development Kit (JDK) cacertsファイルからすでにシードされている、systemストライプ内のpubliccacertsキーストアを使用します。あるいは、必要に応じて独自の証明書をインポートします。

- merge.jdkcacerts.with.trustプロパティでは、kss://system/trustキーストアへの問合せ時に、kss://system/ubliccacertsキーストアの公開CA証明書を戻すかどうかを指定します。問合せですべてのpublicacerts証明書を戻す場合はtrueに設定します。問合せでpublicacerts証明書を戻さない場合は設定しないか、falseに設定します。

関連項目:

第F.2.6項「トラスト・サービスのプロパティ」

12.5 Fusion Middleware Controlを使用した証明書の管理

次のタスクに従って、Fusion Middleware Controlを使用してキーストアを管理します。

1. タスク1: 鍵ペアの生成

2. タスク2: 鍵ペアに対するCSRの生成

3. タスク3: 証明書のインポート

4. タスク4: 証明書のエクスポート

5. タスク5: 証明書のパスワードの変更

6. タスク6: 証明書の削除

タスク1: 鍵ペアの生成

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

2. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択し、「管理」をクリックします。

3. キーストアがパスワードで保護されている場合は、キーストア・パスワードを入力して「OK」をクリックします。「証明書の管理」ページが表示されます。

4. 「鍵ペアの生成」ボタンをクリックします。「鍵ペアの生成」ダイアログが表示されます。

5. このダイアログで、次のデータを入力します。

- 別名(必須)

- 共通名(必須)

- 組織単位

- 組織

- 市区町村

- 都道府県

- 国: ドロップダウン・リストから1つ選択します。

- キー・タイプ: ドロップダウン・リストからアルゴリズムを選択します。選択肢は、「ECC」(楕円曲線暗号システム)または「RSA」です。

- キー・サイズ: キー・サイズを選択します。

6. 「OK」をクリックします。証明書リスト内に新規証明書が表示されます。

7. 証明書の別名をクリックして、証明書の詳細を表示します。

鍵ペアは、デモCA署名証明書内にラップされ、トラストストアに格納されます。この証明書をSSLに使用するには、アプリケーションでトラストストアを使用するか、デモCA証明書をカスタム・キーストアにインポートする必要があります。

タスク2: 証明書に対するCSRの生成

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

2. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択し、「管理」をクリックします。

3. キーストアがパスワードで保護されている場合は、キーストア・パスワードを入力して「OK」をクリックします。「証明書の管理」ページが表示されます。

4. 証明書に対応する行を選択して、「CSRの生成」をクリックします。「CSRの生成」ダイアログ・ボックスが表示されます。

5. 次のいずれかの操作を行います。

- CSR全体をコピーしてテキスト・ファイルに貼り付け、「閉じる」をクリックします。

- 「CSRのエクスポート」をクリックすると、CSRがファイルに保存されます。

署名証明書を返信する認証局に生成された証明書を送信します。

タスク3: 証明書のインポート

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

2. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択し、「管理」をクリックします。

3. キーストアがパスワードで保護されている場合は、パスワードを入力して「OK」をクリックします。「証明書の管理」ページが表示されます。

4. 「インポート」をクリックします。「証明書のインポート」ダイアログが表示されます。

5. ドロップダウンから「証明書」または「信頼できる証明書」を選択します。

6. ドロップダウンから別名を選択します。

7. 証明書ソースを指定します。貼付けオプションを使用する場合は、証明書をコピーして直接テキスト・フィールドに貼り付けます。ファイルの選択オプションを使用する場合は、「参照」をクリックしてオペレーティング・システムからファイルを選択します。

8. 「OK」をクリックします。インポートされた証明書または信頼できる証明書が、証明書の一覧に表示されます。

タスク4: 証明書のエクスポート

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

2. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択し、「管理」をクリックします。

3. キーストアがパスワードで保護されている場合は、パスワードを入力して「OK」をクリックします。「証明書の管理」ページが表示されます。

4. 証明書に対応する行を選択して、「エクスポート」をクリックします。証明書のエクスポート・ダイアログが表示されます。

5. 次のいずれかの操作を行います。

- 証明書全体をテキスト・ファイルにコピーして貼り付けて、「閉じる」をクリックします。

- 「証明書のエクスポート」をクリックして証明書をファイルに保存します。

タスク5: 証明書のパスワードの変更

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

2. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択し、「管理」をクリックします。

3. キーストアがパスワードで保護されている場合は、パスワードを入力して「OK」をクリックします。「証明書の管理」ページが表示されます。

4. 証明書に対応する行を選択して、「パスワードの変更」をクリックします。「キー・パスワードの変更」ダイアログが表示されます。

5. 古いパスワードと新しいパスワードを入力し、「OK」をクリックします。

タスク6: 証明書の削除

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「キーストア」の順に移動します。「キーストア」ページが表示されます。

2. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択し、「管理」をクリックします。

3. キーストアがパスワードで保護されている場合は、パスワードを入力して「OK」をクリックします。「証明書の管理」ページが表示されます。

4. 証明書に対応する行を選択して、「削除」をクリックします。「証明書の削除」ダイアログが表示されます。「OK」をクリックします。

12.6 WLSTを使用した証明書の管理

次のタスクに従って、WLSTを使用して証明書を管理します。

1. タスク1: 鍵ペアの生成

2. タスク2: 鍵ペアに対するCSRの生成

3. タスク3: 証明書のインポート

4. タスク4: 証明書のエクスポート

5. タスク5: 証明書のパスワードの変更

6. タスク6: 証明書の削除

タスク1: 鍵ペアの生成

generateKeyPair WLSTコマンドを使用します。たとえば、アプリケーション・ストライプがappstripe2という名前とすると、次のコマンドではECCアルゴリズムを使用して別名がmyaliasの鍵ペアが作成されます。

svc.generateKeyPair(appStripe='appstripe2', name='keystore2', password='mypassword', dn='cn=www.example.com', keysize='1024', alias='myalias', keypassword='keypassword', algorithm='EC')

mypasswordはキーストア・パスワードで、keypasswordは別名のパスワードです。

鍵ペアは、デモCA証明書内にラップされ、トラストストアに格納されます。アプリケーションでトラスト・ストアを使用していない場合は、デモ用のCA証明書をカスタム・キーストアにインポートする必要があります。

タスク2: 鍵ペアに対するCSRの生成

exportKeyStoreCertificateRequest WLSTコマンドを使用します。たとえば、アプリケーション・ストライプをstripe1とすると、次のコマンドではtestalias鍵ペアからCSRが生成されます。

svc.exportKeyStoreCertificateRequest(appStripe='stripe1', name='keystore1', password='mypassword', alias='testalias', keypassword='keypassword', filepath='/tmp/csr-file')

mypasswordはキーストア・パスワードで、keypasswordは別名のパスワードです。CSRはオペレーティング・システム・ファイルにエクスポートされます。

タスク3: 証明書のインポート

importKeyStoreCertificate WLSTコマンドを使用します。たとえば、アプリケーション・ストライプをappstripe1とすると、次のコマンドでは別名がmykeyの証明書がオペレーティング・システム・ファイルからインポートされます。

svc.importKeyStoreCertificate(appStripe='appstripe1', name='keystore2', password='mypassword', alias='mykey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

mypasswordはキーストア・パスワードで、keypasswordは別名のパスワードです。

タスク4: 証明書のエクスポート

exportKeyStoreCertificate WLSTコマンドを使用します。たとえば、アプリケーション・ストライプをappstripe1とすると、次のコマンドでは別名がmykeyの証明書がオペレーティング・システム・ファイルにエクスポートされます。

svc.exportKeyStoreCertificate(appStripe='appstripe1', name='keystore2', password='mypassword', alias='mykey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

mypasswordはキーストア・パスワードで、keypasswordは別名のパスワードです。

タスク5: 証明書のパスワードの変更

changeKeyPassword WLSTコマンドを使用します。たとえば、システム・ストライプをsystem1とすると、次のコマンドでは別名がtestkeyの証明書が削除されます。

svc.changeKeyPassword(appStripe='system1', name='keystore', password='password', alias='testkey', currentkeypassword='currentkeypassword', newkeypassword='newkeypassword')

ここで、passwordはキーストア・パスワードで、keypasswordは証明書の別名のパスワードです。

タスク6: 証明書の削除

deleteKeyStoreEntry WLSTコマンドを使用します。たとえば、アプリケーション・ストライプをappstripeとすると、次のコマンドでは別名がorakeyの証明書が削除されます。

ssvc.deleteKeyStoreEntry(appStripe='appstripe', name='keystore2', password='password', alias='orakey', keypassword='keypassword')

ここで、passwordはキーストア・パスワードで、keypasswordは別名のパスワードです。

12.7 サードパーティのCA署名証明書の使用

アプリケーションを本番環境にデプロイする際は、サードパーティのCA署名証明書を使用することをお薦めします。次の手順を使用して、サードパーティのCA署名証明書を設定します。

1. 指定された別名を使用して、KSSで鍵ペアを生成します。

2. CSRと鍵ペアを生成します。

3. 新しいCSRをサードパーティのCAに送信します。CAはCSRの公開鍵に署名して、CA署名証明書および独自の証明書を返します。
一部のCAは、2つの別個の証明書ではなく、CA署名証明書と独自の証明書の両方を含む証明書チェーンを返します。

4. 鍵ペアの生成に指定された別名を使用して、CA署名証明書(または証明書チェーン)をインポートします。

5. 新しい別名を使用して、CA署名証明書(または証明書チェーン)を信頼できる証明書としてインポートします。

関連項目:

「Fusion Middleware Controlを使用した証明書の管理」

「WLSTを使用した証明書の管理」

12.8 Fusion Middlewareコンポーネントでのキーストア・サービスの使用方法

Oracle WebLogic Serverでキーストアを構成した後、それらを使用してキーおよび証明書を生成します。キーストア・サービスを使用するようにノード・マネージャを構成することもできます。

関連項目:

『Oracle WebLogic Serverセキュリティの管理 12c』の「SSLの構成」

Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する項

『Oracle Fusion Middlewareの管理』のOPSSキーストア・サービスを使用するためのノード・マネージャの構成に関する項

Oracle WebLogic Serverノード・マネージャの管理

12.8.1 syncKeyStoresコマンドの使用

鍵および証明書はセキュリティ・ストアに格納されます。すべてのOracle Fusion Middlewareスタック・コンポーネントでこの中央ストアを使用することをお薦めします。ただし、特定のインフラストラクチャ・コンポーネントでは、セキュリティ・ストアが使用可能になるには起動が必要になるため、かわりにローカル・ファイル・インスタンスを使用します。

syncKeyStoresコマンドを使用して、中央セキュリティ・ストアからローカル・ファイル・インスタンスを作成します。同期化は、セキュリティ・ストアから鍵データを読み取ってローカル・ファイル・インスタンスのデータと同期させる一方向の工程です。

たとえば、中央ストアの更新時に、syncKeyStoresコマンドを使用して、Weblogic Serverで使用されるローカル・キーストアのコピーを中央ストアと同期させます。

- syncKeyStoresの使用方法

- syncKeyStoresコマンドを使用するタイミング

12.8.1.1 syncKeyStoresの使用方法

syncKeyStoresコマンドの構文は次のとおりです。

syncKeyStores

このコマンドは、中央リポジトリでsystemストライプを検索し、その内容をDOMAIN_HOME/config/fmwconfigのkeystores.xmlというファイルにダウンロードします。同じファイルにトラストストアの内容もダウンロードします。

12.8.1.2 syncKeyStoresコマンドを使用するタイミング

syncKeyStoresコマンドを使用する場合を判断するには、次のガイドラインを検討します。

- 更新中のキーストアがWebLogic Serverに属する場合、そのキーストアはsystemストライプの下にあります。

- トラストストアを変更(信頼できる証明書の追加または削除)する場合、WebLogic Serverの同期コマンドをコールします。

- Oracle Web Services ManagerやJava EEアプリケーションといった階層型コンポーネントのキーストアの更新では、同期コマンドを実行する必要がありません。このようなコンポーネントでは、中央セキュリティ・ストアから鍵のマテリアルに直接アクセスします。

12.9 キーストア・サービス・コマンドについて

KSSでは、キーストアの作成と管理、証明書のエクスポート、鍵ペアの生成などのキーストア操作に、専用のコマンド・セットを使用します。これらのコマンドの使用方法は似ていますが、他のOPSSコマンドとは異なります。

これらすべてのコマンドの起点は、次の操作を可能にするOPSSサービス・コマンド・オブジェクトを取得するgetOpssServiceコマンドです。

- サービスに対するコマンドの実行

- コマンド・ヘルプの取得

コマンドの構文は次のようになります。

getOpssService(name='service_name')

name引数では、取得するサービスを指定します。有効な値は、KeyStoreServiceのみです。

- variableはコマンド・オブジェクトを格納します。

- S

例:

svc = getOpssService(name='KeyStoreService')

12.9.1 キーストア・サービス・コマンドのヘルプの表示

KSSコマンドに関するヘルプを取得するには、サービス・コマンド・オブジェクトの取得から始めます。次に、このオブジェクトをヘルプ・コマンドおよび問題のコマンドとともに使用します。

すべてのキーストア・サービス・コマンドのリストを取得するには、次のように入力します。

svc.help()

特定のコマンドに対するヘルプを表示するには、次のように入力します。

svc.help('command-name')

たとえば次のように入力すると、exportKeyStoreコマンドに対するヘルプが表示されます。

svc.help('exportKeyStore')

12.9.2 キーストア・サービス・コマンド・リファレンス

KSSコマンドに関する構文およびリファレンスの情報は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のOPSSキーストア・サービス・コマンドに関する項を参照してください。

12.10 キーストア・サービスでのSSLの構成

次の手順を使用して、キーストアへのSSL接続を構成します。

- 複数のLDAPとキーストアへの一方向SSLの設定

- 複数のLDAPとキーストアへの双方向SSLの設定

- JKSからKSSへの切替え

関連項目:

第12.11項「LDAPとJKS間のSSLの設定」

12.10.1 複数のLDAPとキーストアへの一方向SSLの設定

複数のLDAPとキーストア間で一方向SSLを有効にするには、次の手順を実行します。

1. エクスポート・コマンドを使用して、LDAPディレクトリからストア証明書をエクスポートします。

2. importKeyStoreCertificateコマンドを使用して、外部LDAPサーバーから共有されているドメイン・トラストストアにストア証明書をインポートします。例:

svc.importKeyStoreCertificate(appStripe='system', name='trust', password='',
alias='alias', keypassword='', type='TrustedCertificate',filepath='absolute
_file_path')

appStripe='system'name='trust'はトラストストアです。

3. WebLogic Serverを再起動します。

12.10.2 複数のLDAPとキーストアへの双方向SSLの設定

複数のLDAPとキーストア間で双方向SSLを有効にするには、次の手順を実行します。

1. LDAPサーバー・エクスポート・ユーティリティを使用して、LDAPディレクトリからストア証明書をエクスポートします。

2. importKeyStoreCertificateを使用して、外部LDAPサーバーから共有されているドメイン・トラストストアに証明書をインポートします。

svc.importKeyStoreCertificate(appStripe='system', name='trust', password='',
alias='alias', keypassword='', type='TrustedCertificate',filepath='absolute
_file_path')

appStripe='system'name='trust'はトラストストアです。

3. appStripe='libovd'引数とname='adapters'引数を渡してcreateKeyStoreコマンドを使用し、キーストアを作成します。

svc.createKeyStore(appStripe='libovd',name='adapters',password='',permission=true)

4. generateKeyPairを実行して、新しい署名証明書を生成します。

svc.generateKeyPair(appStripe='libovd',name='adapters',password='',dn='cn=directory manager', keysize='1024',alias='alias',keypassword='', algorithm='RSA&rsquor;)

5. exportKeyStoreCertificateコマンドを使用して、この証明書をファイルにエクスポートします。

svc.exportKeyStoreCertificate(appStripe='libovd',name='adapters',password='',
alias='key1', type='Certificate',
filepath='/tmp/cert.txt')

6. 生成した証明書をLDAPサーバーにインポートします。

7. DOMAIN_HOME/config/fmwconfig/ovd/default下のprovider.os_xmlファイルで、"property name="enabled" value="true""をKSSKeyManagerに変更します。

8. WebLogic Serverを再起動します。

12.10.3 JKSからKSSへの切替え

次の手順を使用して、LibOVDアダプタを、JKSを使用する構成からKSSを使用する構成に切り替えます。

1. importKeyStore WLSTコマンドを使用して、LibOVDアダプタ(JKSを使用)からトラストストアにLDAP証明書をインポートします。

importKeyStore(appStripe='system', name='trust', password='welcome1',
aliases='alias_names_from_JKS', keypasswords='',type='JKS',
permission=true, filepath='DOMAIN_HOME/config/fmwconfig/ovd/<context_   name>/keystores/adapters.jks')

2. DOMAIN_HOME/config/fmwconfig/ovd/<context_name>/provider.os_xmlファイルを開き、次のように変更してKSSを有効にします。

- provider name=KSSTrustManagerを探し、enabledをtrueに変更します。

- provider name=FileKeyManagerを探し、enabledをfalseに変更します。

- provider name=FileTrustManagerを探し、enabledをfalseに変更します。

3. 双方向SSLを使用していた場合は、次のようにします。

1. createKeyStore WLSTコマンドを使用して、KSSにLibOVDキーストアを作成します。

createKeyStore(appStripe='libovd',name='adapters',password='myPass',permission=true)

2. importKeyStore WLSTコマンドを使用して、生成した鍵ペアをadapters.jksからLibOVDキーストアにインポートします。

importKeyStore(appStripe='libovd', name='adapters', password='myPassw',
aliases='alias_names_from_JKS', keypasswords='',type='JKS',
permission=true,
filepath='DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks')

3. DOMAIN_HOME/config/fmwconfig/ovd/<context_name>/provider.os_xmlファイルを開き、KSSKeyManagerを探してenabledをtrueに置換します。

4. WebLogic Serverを再起動します。

12.11 LDAPとJKS間のSSLの設定

複数のLDAPとJKS間でSSL接続を確立するには、WebLogic Serverトラストストアやadapters.jksファイルなど、複数の場所に格納されているキーストア証明書が必要です。

表12-1に、virtualizeフラグとAPIに応じて、JKSによるSSLの構成に使用する手順を示します。

表12-1 JKSによるSSL

仮想化フラグ

ユーザーおよびロールAPIの使用

アイデンティティ・ディレクトリAPIの使用

virtualize=false

第9.2.2項の説明に従って、トラストストアを指定します。

第12.11.1項および第12.11.2項で示しているように、adapters.jksファイルを使用します。

virtualize=true

第12.11.1項および第12.11.2項で示しているように、adapters.jksファイルを使用します。

第12.11.1項および第12.11.2項で示しているように、adapters.jksファイルを使用します。

12.11.1 LDAPとJKS間の一方向SSLの設定

複数のLDAPとJKS間で一方向SSLを設定にするには、次の手順を実行します。

1. サービスが使用するLDAPサーバー証明書を格納するためのキーストアを作成します。Oracle WebLogic Server管理コンソールとキーストアのそれぞれについてパスワードを指定する必要があります。libovdconfig.shを実行する前に、ORACLE_HOMEをoracle_commonに設定します。
createKeystoreオプションを指定してMW_HOME/oracle_common/bin/libovdconfig.shを実行し、キーストアを作成するには次のようにします。

libovdconfig.sh -host wls_host -port wls_adminserver_port -userName
wls_user_name -domainPath full_path_domain_home -createKeystore

説明:

- hostは、サーバー・ホストです。

- portは、WebLogic管理サーバーのポートです。

- usernameは管理者ユーザー名です。

- domainPathはドメイン・ホームへの完全パスです。

2. LDAPエクスポート・ユーティリティを使用して、LDAPディレクトリからストア証明書をエクスポートします。

3. keytoolコマンドを使用して、作成したキーストアに証明書をインポートします。

$JAVA_HOME/bin/keytool -importcert
-keystore $DOMAIN_HOME/config/fmwconfig/ovd/default/keystores/adapters.jks
-storepass keystore_password_used_in_libovdconfig.sh
-alias alias_name
-file full_path_to_LDAPCert_file
-noprompt

4. WebLogic Serverを再起動します。

12.11.2 LDAPとJKS間の双方向SSLの設定

複数のLDAPとJKS間で双方向SSLを設定にするには、次の手順を実行します。

1. 第12.11.1項の手順を実行します。

2. 作成したキーストアで、新しい署名証明書を生成します。

3. この証明書をファイルにエクスポートします。

4. 証明書をドメイン・キーストアにインポートします。

13 Oracle Fusion Middleware監査フレームワークの概要

Oracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)では、アプリケーション・イベントを監査できます。このフレームワークを使用して、アプリケーション固有のイベントの作成、デプロイ時のアプリケーションの登録、監査レポートの生成を行います。

この章の内容は次のとおりです。

- 監査の目的

- 監査の用語

- OFM監査フレームワークを使用した監査について

- 監査の理解

- 監査の属性、イベントおよびイベント・カテゴリについて

- 監査定義ファイルについて

- マッピングとバージョン・ルールについて

13.1 監査の目的

監査の目的は、法令の遵守、事業活動の監視およびリスク分析用のデータの取得にあります。

コンプライアンス

企業で求められる法令を遵守し、コンプライアンス・ポリシーを見直せるように、顧客は、アイデンティティ情報と次のようなユーザー・アクセス・イベントを企業全体のアプリケーションおよびデバイスで監査する必要があります。

- ユーザー・プロファイルの変更

- アクセス権の変更

- ユーザー・アクセス

- 操作アクティビティ(アプリケーションの起動と停止、アップグレード、バックアップなど)

監視

監査データを使用すると、アクティビティの監視、ダッシュボードの作成、企業内の様々なシステムの状態を監視するためのキー・パフォーマンス・インディケータの構築が可能です。

分析

監査データの分析を使用すると、管理の効果およびリスクを評価できます。履歴データに基づいてリスク・スコアが計算され、ユーザーに割り当てられます。したがって、システムに対するユーザー・アクセスのどの実行時評価にも、アクセス・パーミッションを判別するための追加の基準としてリスク・スコアを含めることができます。

監査サポートは企業間で一様ではありません。たとえば、監査レコードの生成やレコードのフォーマット、監査ポリシーの定義に標準はありません。その結果、監査ソリューションには、次のような多くの問題点があります。

- 集中管理される監査フレームワークがありません。

- アプリケーション間で監査サポートに一貫性がありません。

- 監査データ、監査ポリシーおよび構成が企業全体に散乱しています。

- コンポーネントにまたがった監査の分析は、複雑で多大な時間を要します。

- データが散乱し、一貫性もなく、集中管理もされていない状態のため、監査ソリューションは特異性がありながら脆弱になります。

13.2 監査の用語

この項では、このドキュメントで使用されている監査の用語をいくつか紹介します。

コンポーネント

コンポーネントとは、Oracle Fusion Middlewareコンポーネントのことです。

監査対応コンポーネント

監査対応コンポーネントとは、OFM監査フレームワークと統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントのことです。

監査ストア

監査ストアは、事前に定義された監査スキーマを持ち、監査イベントが格納されるデータベースです。監査ストアを構成すると、監査ローダーによって定期的にデータがこのデータベースにアップロードされます。監査データは累積的なもので、時間とともにサイズが増大します。監査ストアは監査専用のデータベースとし、他のアプリケーションでは使用しないのが理想です。監査ストアには、コンポーネントの他、OFM監査フレームワークに統合されたユーザー・アプリケーションによって生成された監査イベントが格納されます。

監査定義ファイル

監査定義ファイルとは、アプリケーションにより、監査を管理する固有の監査ルール(イベント、フィルタなど)が指定されるファイルのことです。

監査イベント

監査イベントとは、OFM監査フレームワークによって記録されるイベントのことです。このフレームワークには、アプリケーションの監査共通イベントにマップする一連の汎用イベント(認証、ポリシーの変更など)が用意されています。また、Fusion Middleware ControlまたはWebLogic Scripting Tool (WLST)コマンドを使用して、特殊なアプリケーション・イベントを定義したり、監査構成を更新することもできます。

監査ローダー

監査ローダーは、サーバーで監査アクティビティをサポートするOracle WebLogic Serverのモジュールです。監査ストアを構成すると、監査ローダーにより、実行されているすべてのコンポーネントの監査レコードが収集され、監査ストアにロードされます。Javaコンポーネントの場合、監査ローダーは、コンテナの起動時に起動されます。監査ローダーを使用してイベントをアップロードするには、システム・コンポーネントを監査に(registerAudit WLSTコマンドを使用して)登録するか、スタンドアロン監査ローダーを使用します。

監査ポリシー

監査ポリシーとは、特定のコンポーネントについてOFM監査フレームワークによって取得されるイベントを指定するものです。ポリシーは、コンポーネント・レベル(特定のコンポーネントに適用)またはドメイン・レベル(ドメイン内のコンポーネントすべてに適用)で定義します。

バスストップ・ファイル

バスストップ・ファイルとは、監査データ・レコードが格納されるローカル・ファイルのことです。バスストップ・ファイルは、特定の監査イベントを探すために簡単に問い合せることができる単純なテキスト・ファイルです。ドメインで監査を構成すると、このようなファイルのデータは、構成可能な時間間隔で定期的に監査ストアにアップロードされます。ドメインで監査を構成しないと、データはバスストップ・ファイルに格納されます。

すべてのミドルウェア・コンポーネントおよびインスタンスで認証の失敗を特定する場合などに、レポートで複数のコンポーネントからの監査データを相互的に関連付けたり、組み合せます。

デフォルトでは、バスストップ・ファイルは次のディレクトリにあります。

Weblogic Domain Home/servers/server_name/logs/auditlogs

コンポーネントのバスストップ・ファイルごとにサブディレクトリがあります。たとえば、OPSSのバスストップ・ファイルは、次のディレクトリに格納されています。

Weblogic Domain Home/servers/server_name/logs/auditlogs/JPS

イベント・フィルタ

イベント・フィルタとは、イベントをログに記録するかどうかを制御するフィルタのことです。たとえば、特定のユーザーについてのみコンポーネントへの成功したログインのイベントがログに記録されます。

監査構成Mbean

監査構成MBeanとは、監査構成を管理するMBeanのことです。Javaコンポーネントおよびアプリケーションの場合、このようなMbeanはWebLogic管理サーバー内に存在し、監査構成が集中管理されます。システム・コンポーネントの場合、コンポーネントごとに異なるMBeanがあります。

関連項目:

「監査ストアについて」

「監査データの格納方法」

監査定義ファイルについて

第14.6.1項「監査スキーマの概要」

第14.2.3.2項「スタンドアロン監査ローダーの実行」

第14.3項「監査ポリシーの管理」

第C.1項「監査イベント」

13.3 OFM監査フレームワークを使用した監査について

次の各項では、コンポーネントを監査するためのOFM監査フレームワークのサポートについて説明します。

- OFM監査フレームワークの概要

- コンポーネントとアプリケーションについて

13.3.1 OFM監査フレームワークの概要

OFM監査フレームワークには次の機能があります。

- Javaコンポーネント、システム・コンポーネントおよびアプリケーションにわたって監査を管理するための統一された方法。

- Javaコンポーネント監査。

- 非監査対応アプリケーションの監査のサポート。

- 任意のアプリケーション・レベルでの監査データ検索機能。

- 認証履歴、認証失敗、認可履歴、ユーザー管理およびその他の共通トランザクション・データの取得。

- 柔軟なポリシー。

- 構成を容易にするために使用可能で、最もよく使用される監査イベントを取得する以前にシードされた監査ポリシー。

- ツリー状のポリシー構造。

- 公開された監査スキーマに基づいて独自のレポートを作成する機能。監査分析の詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

- レコードのメンテナンスを簡略化する、共通の場所(監査ストア)への監査のデータおよびファイルの格納。

- 共通の監査レコード・フォーマット。

- 結果(ステータス)、イベントの日時、ユーザーなどのベースライン属性。

- 認証方式、ソースIPアドレス、ターゲット・ユーザー、リソースなどのイベント固有の属性。

- 実行コンテキストID (ECID)、セッションIDなどのコンテキスト属性。

- ドメイン全体に対して監査ポリシーを構成するための共通の統一された方法。

- 監査で次のことを実現するOracle Fusion Middlewareのサポート。

- Oracle Fusion Middlewareコンポーネントおよびサービス間での使用が可能。

- Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)との統合。

- WLSTとの統合。

- OFM監査フレームワークと統合され、アプリケーションで次のことを可能にする動的メタデータ・モデル。

- 任意の時点での登録。

- 特定の監査イベントの定義およびログへの記録。

- イベント定義のバージョンの指定による、リリース・サイクルに依存しない定義のアップグレード。

13.3.2 コンポーネントとアプリケーションについて

OFM監査フレームワークは、Oracle Fusion Middlewareの全製品向けの集中管理フレームワークです。特に、次のアプリケーションおよびコンポーネントに監査を提供しています。

- ミドルウェア・プラットフォーム - これには、OPSSやOracle Web Services ManagerなどのJavaコンポーネントが含まれます。Javaコンポーネントを利用しているデプロイ済アプリケーションはすべて、プラットフォーム・レベルで発生する監査の恩恵を受けます。

- Java EEアプリケーション - フレームワークにより、Java EEアプリケーション(Oracle Java EEベースのコンポーネントを含む)に監査が提供され、アプリケーションおよびコンポーネントでは固有の監査イベントを指定できます。

- システム・コンポーネント - フレームワークにより、Oracle HTTP Serverなどのシステム・コンポーネントについても、Javaコンポーネント(CおよびC++アプリケーション用のAPIを含む)の場合と同様のエンドツーエンドのソリューションが提供されます。

関連項目:

『Oracle Fusion Middlewareの管理』のOracle Fusion Middlewareの主要概念の理解に関する項

13.4 監査の理解

次の各項では、基本的な監査の概念について説明します。

- 監査モデル

- 監査の設定: 主な手順

- 監査ストアについて

- 監査データの格納方法

13.4.1 監査モデル

監査モデルは、Oracle Fusion Middleware全体のJava EEおよびJava SEのアプリケーションとコンポーネントに対する標準ベースの統合フレームワークとなります。

動的モデル

OFM監査フレームワークは、アプリケーションで監査イベント定義を管理し、リリース・サイクルに関係なくバージョン変更を行うことが可能になる動的監査モデルを特徴としています。監査イベント定義は、再デプロイメント時に動的に更新できます。

アプリケーション・ライフ・サイクルのサポート

このモデルは、設計から開発、デプロイメントに至るまでのアプリケーション・ライフ・サイクルのすべての側面をサポートします。

アプリケーションの登録

汎用性の高い登録により、様々な方法でアプリケーションを監査に登録できます。

- 宣言して、META-INFディレクトリのアプリケーションのエンタープライズ・アーカイブ(EAR)ファイルに構成をパッケージ化することによって登録します。

- プログラムを使用して、監査登録メソッドをコールすることによって登録します。

- コマンドラインで、WLST監査コマンドをコールすることによって登録します。

- ドメイン作成時に、製品テンプレートでセキュリティ・アーティファクトを指定することによって登録します。

分散環境

OFM監査フレームワークでは、複数のサーバーがある分散環境をサポートします。監査ストアを監視するため、あるサーバーで加えられた監査ポリシーへの変更はドメイン内の他のサーバーすべてと同期されます。

たとえば、管理サーバー1台と管理対象サーバー3台で構成される分散環境を考えてみます。単一のセキュリティ・ストア(監査データを格納)がドメイン内のサーバーすべてをサポートします。Fusion Middleware Controlを使用して管理サーバーで監査ポリシーを変更すると、その変更はドメイン内の他のサーバーすべてに自動的に伝播され、同期されます。

関連項目:

第22.3.1項「宣言による監査登録の実行」

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のregisterAuditに関する項

第7.1項「セキュリティ・アーティファクトのシード方法」

13.4.2 監査ストアについて

監査ストアには、コンポーネントのイベント定義、属性表マッピングおよび監査ポリシーが格納されます。

監査ストアには次のものが組み込まれています。

- 次のことが可能になる監査登録。

- イベント定義エントリの作成、変更および削除。

- 監査データを格納するための属性データベース・マッピングの作成。

- イベント定義および実行時ポリシーを取得するサービス。

- コンポーネントの監査定義および実行時ポリシーの検索および変更を可能にする監査MBeanコマンド。

OFM監査フレームワークには、監査データを格納するためのデータベースが必要ですが、このデータベースはサポートされているものであれば何でもかまいません。サポートされているタイプの詳細は、第4.1項「サポートされているファイル、LDAPおよびDBのストア」を参照してください。

新しいアプリケーションが監査に登録されると、次のアーティファクトが監査ストアに格納されます。

- カスタム属性グループ、カテゴリ、イベントおよび事前設定済フィルタ定義を含む、監査イベント定義

- ローカライズされた翻訳エントリ

- カスタム属性/データベース列マッピング表

- 実行時監査ポリシー

13.4.3 監査データの格納方法

監査データは、中間的な記憶域または永続的な記憶域にあります。

- 中間的な記憶域: バスストップ・ファイル内。コンポーネント・インスタンスはそれぞれ別個のバスストップ・ファイルに書き込みます。バスストップ・ファイルはテキストベースで問合せが容易です。

- 永続的な記憶域: 監査ストア内(環境で構成されている場合)。ドメイン内のあらゆるコンポーネントで生成された監査レコードは同じストアに書き込まれます。

データベース・ストアを使用する利点

バスストップ・ファイルに監査レコードを格納する場合、次のような制限があります。

- ドメイン・レベルの監査データを表示できません。

- レポートの取得が困難です。

一方、監査ストアの使用には次のような利点があります。

- 監査レポートを生成できます。

- データベース・ストアには、ドメイン内のあらゆるコンポーネントからのレコードが格納されるのに対して、バスストップには、1つのコンポーネントの監査レコードのみが格納されます。

- パフォーマンスが向上します。

13.4.4 OFM監査フレームワークについて

OFM監査フレームワークには、統合されている監査対応コンポーネント用に一連のインタフェースが用意されています。アプリケーションでは実行時、これらのAPIをコールして、監査ポリシーを管理したり、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査したりする場合もあります。これらのインタフェースにより、アプリケーションでは、監視対象イベントのコンテキストの提供に必要なイベントの詳細および属性を指定できます。

関連項目:

第22章「Oracle Fusion Middleware監査フレームワークを使用した開発」

13.4.5 監査の設定: 主な手順

環境で監査を設定およびメンテナンスする場合に実行する主要なタスクを次に示します。

- 監査アーキテクチャ、フレームワークの不可欠な要素、アクションのフロー、OFM監査フレームの理解。これらのタスクの詳細は、第14.1項「監査管理タスク」を参照してください。

- アプリケーションとフレームワークの統合。統合の詳細は、第22.1項「アプリケーションとOFM監査フレームワークの統合」を参照してください。

- アプリケーションの監査イベントと、それらを監査スキーマにマップする方法を指定する監査定義ファイルの作成。監査定義ファイルの詳細は、第22.2項「監査定義ファイルの作成」を参照してください。

- 監査へのアプリケーションの登録。監査登録の詳細は、第22.3項「サービスへのアプリケーションの登録」を参照してください。

- 監査情報の移行。監査データの移行の詳細は、第6.6.3項「監査データの移行」を参照してください。

- 監査レポートの生成。監査レポートの詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

13.4.6 実行時監査イベント・フローの理解

環境で監査ストアを構成しないと、監査レコードはバスストップ・ファイルに格納されます。監査イベントを記録できない場合、アプリケーションは実行を停止しません。

監査イベント・フローを最もよく理解するには、監査を構成した環境で実行されているアプリケーション内で監査イベントが発生した際に実行される次の手順を見ることです。

1. アプリケーションのデプロイ時またはサービスの起動時に、クライアントJava EEアプリケーションが監査に登録されます。

2. サービスはアプリケーションの監査定義ファイルを読み取り、監査ストアの定義を更新します。

3. ユーザーがそのコンポーネントまたはアプリケーションにアクセスすると、イベントを監査するために監査関数がコールされます。

4. OFM監査フレームワークが、このタイプ、ステータスおよび属性のイベントを監査するかどうかをチェックします。監査が必要な場合は監査関数がコールされてイベントが作成され、ステータス、イニシエータ、リソース、ECIDなどの情報が収集されます。

5. イベントはバスストップ・ファイルに格納されます。アプリケーションまたはコンポーネントにはそれぞれ個別のバスストップ・ファイルがあります。

6. 監査ローダーはバスストップ・ファイルからイベントをプルし、アプリケーションのメタデータを使用してデータを書式設定し、監査ストアに移動します。

関連項目:

第15章「監査分析と監査レポートの使用」

13.5 監査の属性、イベントおよびイベント・カテゴリについて

OFM監査フレームワークでは、アプリケーションの監査属性グループ、カテゴリおよびイベントの動的な指定および定義が可能になるモデルをサポートしています。

次の各項では、このサポートについて説明しています。

- 監査属性グループ

- 監査イベントとイベント・カテゴリ

- 監査アーティファクトのネーミング要件

13.5.1 監査属性グループ

属性グループは監査属性の広範な分類であり、共通、汎用、カスタムの3つのタイプから構成されます。

- 共通属性グループには、コンポーネント・タイプ、システムIPアドレス、ホスト名など、すべてのアプリケーションに共通のシステム属性が含まれます。IAU_COMMONデータベース表には、このグループ内の属性が含まれます。

- 汎用属性グループには、監査認証およびユーザー・プロビジョニングの属性が含まれます。

- カスタム属性グループは、特定のニーズに応じてアプリケーションで定義されるグループです。カスタム・グループの属性の有効範囲は、コンポーネントに限定されます。これらの属性グループおよび属性は、IAU_CUSTOMn表(nは1、2などの整数)に格納されます。

関連項目:

「汎用属性グループについて」

「カスタム属性グループについて」

「監査属性のデータ型について」

第C.1.3項「OPSSイベントの属性」

13.5.1.1 汎用属性グループについて

汎用属性グループは、ネームスペースおよびバージョン番号を表し、1つ以上の属性が含まれます。次の例は、authorizationネームスペースおよびバージョン1.0の属性グループを示しています。

<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit-2.0.xsd" >
<Attributes ns="authorization" version="1.0">
<Attribute displayName="CodeSource" maxLength="2048" name="CodeSource" type="string"/>
<Attribute displayName="Principals" maxLength="1024" name="Principals" type="string"/>
<Attribute displayName="InitiatorGUID" maxLength="1024" name="InitiatorGUID" type="string"/>
<Attribute displayName="Subject" maxLength="1024" name="Subject" type="string">
<HelpText>Used for subject in authorization</HelpText>
</Attribute>
</Attributes>
……

CodeSource属性は、次のように表します。

<Attribute name="CodeSource" ns="authorization" version="1.0" />

各汎用属性グループは、専用のデータベース表に格納されます。ネーミング規則は次のとおりです。

- 表名はIAU_GENERIC_ATTRIBUTE_GROUP_NAME

- 表の列はIAU_ATTRIBUTE_NAME

たとえば、authorization属性グループは、次の列を含むIAU_AUTHORIZATION表に格納されます。

- 文字列であるIAU_CODESOURCE

- 文字列であるIAU_PRINCIPALS

- 文字列であるIAU_INITIATORGUID

13.5.1.2 カスタム属性グループについて

カスタム属性グループは、ネームスペース、バージョン番号および1つ以上の属性を表します。各カスタム属性には次のプロパティがあります。

- 属性名

- データ型

- 属性/データベース列マッピング順序 - このプロパティは、属性が、カスタム属性表内の特定のデータ型のデータベース列にマップされる順序を指定します。

- ヘルプ・テキスト(オプション)

- 最大長

- 表示名

- サイズ - このプロパティは、属性に指定できる同じデータ型の値の数を示します。サイズのデフォルト値は1です。1より大きいサイズは、同じデータ型の値を複数指定できる属性を示します。このような属性では、binary型以外のすべてのデータ型がサポートされます。

次の例は、accountingネームスペースおよびバージョン1.0のAccounting属性グループの定義を示しています。

<Attributes ns="accounting" version="1.0">
<Attribute name="TransactionType" displayName="Transaction Type" type="string" order="1"/>
<Attribute name="AccountNumber" displayName="Account Number" type="int" order="2">
<HelpText>Account number.</HelpText>
</Attribute>
……
</Attributes>

次の例では、複数の値を持つAccountBalance属性を定義します。

<Attribute order="3" displayName="AccountBalance" type="double" name="Balance" size="2" sinceVersion="1.1">
<MultiValues>
<MultiValueName displayName="Previous Balance" index="0">
<HelpText>the previous account balance</HelpText>
</MultiValueName>
<MultiValueName displayName="Current Balance" index="1"/>
</MultiValues>
</Attribute>

13.5.1.3 監査属性のデータ型について

表13-1に、サポートされている属性のデータ型とそれに対応するJavaオブジェクト・タイプを示します。

表13-1 監査属性のデータ型

属性のデータ型

Javaオブジェクト・タイプ

注意

Integer

Integer

Long

Long

Float

Float

Double

Double

Boolean

Boolean

DateTime

java.util.Date

String

String

最大長2048バイト

LongString

String

無限長

Binary

byte[]

13.5.2 監査イベントとイベント・カテゴリ

イベント・カテゴリには、機能領域内の監査イベントが含まれます。たとえば、セッション・カテゴリには、ユーザー・セッションのライフ・サイクルで重要なログイン・イベントとログアウト・イベントが含まれます。イベント・カテゴリ自体は属性を定義しません。かわりに、コンポーネント内の属性およびシステム属性グループを参照します。

イベント・カテゴリには次の2つのタイプがあります。

- システム・カテゴリ

- コンポーネントとアプリケーション・カテゴリ

関連項目:

第C.1.2項「システム・カテゴリとイベント」

13.5.2.1 システム・カテゴリとイベントについて

システム・カテゴリは、共通属性グループと汎用属性グループを参照し、監査イベントが含まれます。システム・カテゴリは、コンポーネント・イベント・カテゴリおよびイベントのベース・セットです。アプリケーションではシステム・カテゴリを参照し、そのイベントを使用して監査イベントをログに記録し、事前設定済フィルタ定義を設定できます。

次の例は、属性およびイベントの定義と、AuthenticationMethod共通属性を参照する属性を持つUserSessionシステム・カテゴリの定義を示しています。

<SystemComponent major="1" minor="0">
<Attributes ns="common" version ="1.0"></Attributes>
<Attributes ns="identity" version ="1.0"></Attributes>
<Attributes ns="authorization" version ="1.0"></Attributes>
<Events>
<Category name="UserSession" displayName="User Sessions">
<Attributes>
<Attribute name="AuthenticationMethod" ns="common" version ="1.0" />
</Attributes>
<HelpText></HelpText>
<Event name="UserLogin" displayName="User Logins" shortName="uLogin"></Event>
<Event name="UserLogout" displayName="User Logouts" shortName="uLogout"
xdasName="terminateSession"></Event>
<Event name="Authentication" displayName="Authentication"></Event>
<Event name="InternalLogin" displayName="Internal Login" shortName="iLogin"
xdasName="CreateSession"></Event>
<Event name="InternalLogout" displayName="Internal Logout" shortName="iLogout"
xdasName="terminateSession"></Event>
<Event name="QuerySession" displayName="Query Session"     shortName="qSession"></Event>
<Event name="ModifySession" displayName="Modify Session"     shortName="mSession"></Event>
</Category>
<Category displayName="Authorization" name="Authorization"></Category>
<Category displayName="ServiceManagement" name="ServiceManagement"></Category>
</Events>
</SystemComponent>

13.5.2.2 コンポーネントとアプリケーション・カテゴリについて

コンポーネントまたはアプリケーションは、システム・カテゴリを拡張するか、新しいコンポーネント・イベント・カテゴリを定義できます。

次の例は、accounting属性グループのAccountNumber、DateおよびAmountの各属性を持ち、purchaseイベントとdepositイベントが含まれるカテゴリの定義を示しています。

<Category displayName="Transaction" name="Transaction">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0"/>
<Attribute name="Date" ns="accounting" version="1.0" />
<Attribute name="Amount" ns="accounting" version="1.0" />
</Attributes>
<Event displayName="purchase" name="purchase"/>
<Event displayName="deposit" name="deposit">
<HelpText>depositing funds.</HelpText>
</Event>
……
</Category>

アプリケーション監査定義でカテゴリ参照を作成し、カテゴリに含まれるシステム・イベントをリストし、属性参照およびイベントをカテゴリ参照に追加することで、システム・カテゴリを拡張します。

次の例は、ServiceTime属性およびrestartServiceイベントを持つServiceManagementシステム・カテゴリ参照の定義を示しています。

<CategoryRef name="ServiceManagement" componentType="SystemComponent">
<Attributes>
<Attribute name="ServiceTime" ns="accounting" version="1.0" />
</Attributes>
<EventRef name="startService"/>
<EventRef name="stopService"/>
<Event displayName="restartService" name="restartService">
<HelpText>restart service</HelpText>
</Event>
</CategoryRef>

13.5.3 監査アーティファクトのネーミング要件

カテゴリ、イベントまたは属性の名前には次の要件があります。

- 英単語であること

- 25文字以下であること

- 文字(a-z、A-Z)および数字(0-9)のみで構成すること

- 文字で始まること

13.6 監査定義ファイルについて

監査定義ファイルでは、アプリケーション固有の監査ルール(イベント、フィルタなど)を指定します。監査定義ファイルは、イベント定義を外国語に翻訳する手段になります。監査定義ファイルには、2つのタイプがあります。

- component_events.xmlファイル。このファイルの詳細は、「component_events.xmlファイルについて」を参照してください。

- 翻訳ファイル(様々な言語で監査定義を表示するために使用されます)。翻訳ファイルの詳細は、第22.2.2項「翻訳ファイル」を参照してください。

13.6.1 component_events.xmlファイルについて

component_events.xmlファイルでは、監査で監査イベントをログに記録する際に使用する次のようなプロパティを指定します。

- 基本プロパティ

- コンポーネント・タイプ(監査に登録し、実行時オーディタ・インスタンスを取得するためにアプリケーションで使用するプロパティ)

- アプリケーションのメジャーおよびマイナー・バージョン

- カスタム属性グループ

- 属性参照およびイベントを含むイベント・カテゴリ

- コンポーネント・レベル・フィルタ定義

- 実行時ポリシー

次の例は、このファイルの定義を示しています。

<?xml version="1.0"?>
<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit-2.0.xsd">
<AuditComponent componentType="ApplicationAudit" major="1" minor="0">
<Attributes ns="accounting" version="1.0">
<Attribute name="TransactionType" displayName="Transaction Type" type="string" order="1">
<HelpText>Transaction type.</HelpText>
</Attribute>
<Attribute name="AccountNumber" displayName="Account Number" type="int" order="2">
<HelpText>Account number.</HelpText>
</Attribute>
<Attribute name="Date" displayName="Date" type="dateTime" order="3"/>
<Attribute name="Amount" displayName="Amount" type="float" order="4">
<HelpText>Transaction amount.</HelpText>
</Attribute>
<Attribute name="Status" displayName="Account Status" type="string" order="5">
<HelpText>Account status.</HelpText>
</Attribute>
</Attributes>
<Events>
<Category displayName="Transaction" name="Transaction">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0" />
<Attribute name="Date" ns="accounting" version="1.0" />
<Attribute name="Amount" ns="accounting" version="1.0" />
</Attributes>
<Event displayName="purchase" name="purchase">
<HelpText>direct purchase.</HelpText>
</Event>
<Event displayName="deposit" name="deposit">
<HelpText>depositing funds.</HelpText>
</Event>
<Event displayName="withdrawing" name="withdrawing">
<HelpText>withdrawing funds.</HelpText>
</Event>
<Event displayName="payment" name="payment">
<HelpText>paying bills.</HelpText>
</Event>
</Category>
<Category displayName="Account" name="Account">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0" />
<Attribute name="Status" ns="accounting" version="1.0" />
</Attributes>
<Event displayName="open" name="open">
<HelpText>Open a new account.</HelpText>
</Event>
<Event displayName="close" name="close">
<HelpText>Close an account.</HelpText>
</Event>
<Event displayName="suspend" name="suspend">
<HelpText>Suspend an account.</HelpText>
</Event>
</Category>
</Events>
<FilterPresetDefinitions>
<FilterPresetDefinition displayName="Low" helpText="" name="Low">
<FilterCategory enabled="partial" name="Transaction"> deposit.SUCCESSESONLY(HostId -eq &quot;NorthEast&quot;),withdrawing </FilterCategory>
<FilterCategory enabled="partial" name="Account">open.SUCCESSESONLY,close.FAILURESONLY</FilterCategory>
</FilterPresetDefinition>
<FilterPresetDefinition displayName="Medium" helpText="" name="Medium">
<FilterCategory enabled="partial" name="Transaction">deposit,withdrawing</FilterCategory>
<FilterCategory enabled="partial" name="Account">open,close</FilterCategory>
</FilterPresetDefinition>
<FilterPresetDefinition displayName="High" helpText="" name="High">
<FilterCategory enabled="partial" name="Transaction">deposit,withdrawing,payment</FilterCategory>
<FilterCategory enabled="true" name="Account"/>
</FilterPresetDefinition>
</FilterPresetDefinitions>

<Policy filterPreset="Low">
<CustomFilters>
<FilterCategory enabled="partial" name="Transaction"> purchase </FilterCategory>
</CustomFilters>
</Policy>
</AuditComponent>
</AuditConfig>

実行時のプロパティについて

さらに、Fusion Middleware ControlまたはWLSTコマンドを使用して作成したり、登録時に作成する実行時プロパティがあります。これには、次のようなプロパティがあります。

- filterPreset: 監査フィルタ・レベルを指定します。

- specialUsers: 常に監査するユーザーを指定します。

- maxBusstopFileSize: バスストップ・ファイルのサイズを指定します。

関連項目:

第14.3項「監査ポリシーの管理」

13.7 マッピングとバージョン・ルールについて

監査登録では、特定のルールを適用してアプリケーションに対して監査データが作成されますが、このデータは監査定義の様々なバージョンを管理したり、レポートを生成するために使用されます。

次の各項では、登録のしくみについて説明します。

- バージョン番号とは

- カスタム属性からデータベース列へのマッピングについて

13.7.1 バージョン番号とは

監査定義ファイルには、メジャー・バージョン番号とマイナー・バージョン番号があります。監査イベント定義を変更する場合は、バージョン番号を更新する必要があります。この番号は、イベント定義の互換性およびバージョン間の属性マッピングを判別するために監査登録で使用されます。これらのバージョン番号はOracle Fusion Middlewareのバージョン番号とは関係ありません。

コンポーネント・バージョン

コンポーネントの登録時に、監査登録によってこれが初めての登録なのか、アップグレードなのかがチェックされます。

新規登録の場合、サービスは次のように動作します。

1. コンポーネントの監査および翻訳情報を取得します。

2. 定義を解析して検証し、監査ストアに格納します。

3. 属性/列マッピング表を生成し、監査ストアに保存します。

アップグレードの場合、監査ストア内のコンポーネントの現在のバージョン番号が新しいバージョン番号と比較され、アップグレードを続行するかどうかが決まります。

Java EEアプリケーション・バージョン

アプリケーション監査定義の変更後にバージョン番号を次のように再設定することをお薦めします。

- マイナー・バージョン番号は、以前の属性データベース・マッピング表で作成された監査データとでも動作する変更を監査定義に加える場合のみ増やします。
たとえば、現在の定義バージョンが2.1であるとします。属性データベース・マッピング表に影響しない新しいイベントを追加した場合は、バージョンを2.2に変更し、メジャー・バージョンはそのままにします(major=2)。同様に、新しい属性を追加した後は、マイナー・バージョンを増やします。

- 新しいマッピング表が以前の表と互換性がない変更を加える場合には、メジャー・バージョン番号を増やします。

変更はサーバーを再起動すると有効になります。

13.7.2 カスタム属性からデータベース列へのマッピングについて

新しいコンポーネントまたはアプリケーションを登録する際、監査登録では、カスタム属性から属性/データベース列マッピング表を作成し、この表を監査ストアに保存します。

カスタム属性の数が100を超える場合は、手動で表を追加作成する必要があります。OPSSに同梱されている表は、IAU_CUSTOMおよびIAU_CUSTOM_01のみです。

属性/データベース列マッピング表は、アプリケーションの属性定義とデータベース列間で一意なマッピングを行うために必要です。監査ローダーはマッピング表を使用してデータを監査ストアにロードします。これらの表は、カスタム・データベース表IAU_CUSTOMから監査レポートを生成する場合にも使用されます。

createAuditDBView WLSTコマンドを使用して、コンポーネントについて監査定義のデータベース・ビューを作成するSQLファイルを生成します。

コンポーネントのマッピング表の理解

カスタム属性/データベース列マッピングには、名、データベース列名およびデータ型の各プロパティがあります。

各カスタム属性定義には、マッピング順序番号が含まれている必要があります。同じデータ型の属性は、属性マッピング順序に従ってデータベース列にマップされます。

たとえば、次のような定義ファイルは、

<Attributes ns="accounting" version="1.1">
<Attribute name="TransactionType" type="string" maxLength="0"     displayName="Transaction Type" order="1"/>
<Attribute name="AccountNumber" type="int" displayName="Account Number"     order="2">
<Attribute name="Date" type="dateTime" displayName="Date" order="3"/>
<Attribute name="Amount" type="float" displayName="Amount" order="4"/>
<Attribute name="Status" type="string" maxLength="0" displayName="Account     Status" order="5"/>
<Attribute name="Balance" type="float" displayName="Account Balance"     order="6"/>
</Attributes>

次にマップします。

<AttributesMapping ns="accounting" tableName="IAU_CUSTOM" version="1.1">
<AttributeColumn attribute="TransactionType" column="IAU_STRING_001"     datatype="string"/>
<AttributeColumn attribute="AccountNumber" column="IAU_INT_001"     datatype="int"/>
<AttributeColumn attribute="Date" column="IAU_DATETIME_001"     datatype="dateTime"/>
<AttributeColumn attribute="Amount" column="IAU_FLOAT_001" datatype="float"/>
<AttributeColumn attribute="Status" column="IAU_STRING_002" datatype="string"/>
<AttributeColumn attribute="Balance" column="IAU_FLOAT_002" datatype="float"/>
</AttributesMapping>

属性/データベース列マッピング表のバージョン番号は、カスタム属性グループのバージョン番号に一致します。これにより、アプリケーションは監査定義バージョン間で、属性マッピングの下位互換性を維持できます。

関連項目:

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のcreateAuditDBViewに関する項

付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

「バージョン番号とは」

14 監査の管理

この章では、主要な管理タスクと、監査ストア、監査ポリシーおよびバスストップ・ファイルの管理に使用するツールについて説明します。

この章の内容は次のとおりです。

- 監査管理タスク

- 監査ストアの管理

- 監査ポリシーの管理

- 監査のタイムスタンプの理解

- 監査ログとバスストップ・ファイルについて

- 監査データベースの管理

- 監査イベント定義のベスト・プラクティス

14.1 監査管理タスク

環境での監査の設定では、次の主なタスクを実行します。

- 監査レコードに使用するストアのタイプやストア構成の詳細の計画。監査ストアの管理の詳細は、「監査ストアの管理」を参照してください。

- 監査イベントが生成されるようにするための監査ポリシーの構成およびメンテナンス。監査ポリシーの詳細は、「監査ポリシーの管理」を参照してください。

- 監査レポートおよび監査問合せの構成。レポートの詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

- アプリケーションの登録。アプリケーション登録の詳細は、第22.3項「サービスへのアプリケーションの登録」を参照してください。

- 監査情報の移行。監査データの移行の詳細は、第6.6.3項「監査データの移行」を参照してください。

- 監査データベースの管理(生成された監査データを格納するデータベースのサイズの増加やそのデータのバックアップおよびパージを含む)監査の管理の詳細は、「監査データベースの管理」を参照してください。

14.2 監査ストアの管理

監査ストアは、監査レコードの格納に必要なスケーラビリティと高可用性を備え、レポートの表示および生成を可能にするデータベースです。

次の各項では、監査ストアとその管理方法について説明します。

- 監査データ・ソースについて

- バスストップ・ファイルの管理

- スタンドアロン監査ローダーの構成

14.2.1 監査データ・ソースについて

ドメインを作成すると、データベースに監査レコードを格納するために必要なデータ構造である監査スキーマが生成されます。また、監査スキーマを使用するサーバーで監査データ・ソースが設定されます。レコードを格納するデータベースを使用して環境を設定しないと、監査レコードはバスストップ・ファイルに格納されます。

関連項目:

「バスストップ・ファイル」

14.2.2 バスストップ・ファイルの管理

バスストップ・ファイルが一定のサイズに到達し、すべてのデータがデータベースにアップロードされると、監査ローダーによってファイルはファイル・システムから削除されます。バスストップ・ファイルの場所および最大サイズを指定し、バスストップ・ファイルが自動的に削除されるようにします。監査ファイルを手動で削除することは、お薦めしません。

バスストップ・ファイルの場所

Javaコンポーネント用のバスストップ・ファイルは、次のディレクトリにあります。

$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type

システム・コンポーネント用のバスストップ・ファイルは、次のディレクトリにあります。

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

バスストップ・ファイルのサイズ

Javaコンポーネントでは、バスストップ・ファイルの最大サイズはaudit.maxFileSizeプロパティを使用して設定します。

システム・コンポーネントでは、バスストップ・ファイルの最大サイズはauditconfig.xmlファイルで設定します。

<serviceInstance name="audit" provider="audit.provider">
<property name="audit.maxFileSize" value="10240" />
<property name=" audit.loader.repositoryType " value="Db" />
</serviceInstance>

監査データ用のストアをファイルからデータベースに切り替えると、ファイルに収集されたイベントはすべてデータベース表に移動され、監査ファイルは削除されます。

14.2.3 スタンドアロン監査ローダーの構成

スタンドアロン監査ローダーは、レコードをバスストップ・ファイルから監査ストアに定期的に移動します。監査ローダーを駆動するメカニズムは、アプリケーション環境に応じて変わります。

- Java EEコンポーネントおよびアプリケーションでは、OPSSランタイムによって提供される監査ローダー機能を使用します。スタンドアロン監査ローダーはそのような環境では不要です。

- システム・コンポーネントおよび非Javaアプリケーションでは、StandAloneAuditLoaderコマンドによって提供される監査ローダー機能を使用します。

- Java SEアプリケーションでは、バスストップ・ファイルが書き込まれる場所に応じて、スタンドアロン監査ローダーを使用することもあります。Java SEアプリケーション用の監査の詳細は、第24.5.4項「Java SEアプリケーションでの一般的な監査シナリオ」を参照してください。

次の各項では、スタンドアロン監査ローダーの設定および実行方法について説明します。

- 環境の構成

- スタンドアロン監査ローダーの実行

14.2.3.1 環境の構成

次の設定は、非Javaアプリケーションおよびシステム・コンポーネントにのみ適用されます。

スタンドアロン監査ローダーを実行する前に、次の監査ローダーのパラメータを設定します。

- ORACLE_HOME: ホーム・ディレクトリへのフルパス

- COMMON_COMPONENTS_HOME: Java Required Files (JRF)ディレクトリへのフルパス

- ORACLE_INSTANCE: Oracleインスタンス・ディレクトリへのフルパス

- auditloader.jdbcString: 監査データが格納されるデータベースのJava Database Connectivity (JDBC)接続文字列

- auditloader.username: 監査ローダーを実行するユーザーの名前

さらに、データベース・スキーマ・ユーザーのパスワードが使用可能であり、格納されていることを確認します。このパスワードは1回指定します。

データベース・スキーマ・ユーザーのパスワードを指定するには、Java StandAloneAuditLoaderコマンドを-Dstore.password=trueプロパティを指定して使用します。

$JDK_HOME/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.2.1/jps-manifest.jar
-Doracle.home=$ORACLE_INSTANCE -Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
-Dstore.password=true
oracle.security.audit.ajl.loader.StandaloneAuditLoader

パスワードの入力を求められます。コマンドにより、入力したパスワードを含むcwallet.ssoファイルが生成されます。

14.2.3.2 スタンドアロン監査ローダーの実行

ローダーを実行するには、StandAloneAuditLoaderコマンドを使用します。

$JDK_HOME/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.2.1/jps-manifest.jar
-Doracle.home=$ORACLE_INSTANCE -Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
oracle.security.audit.ajl.loader.StandaloneAuditLoader

このコマンドは通常、監査レコードが監査ストアに定期的にアップロードされるように、自動的に実行されるようスケジュールされます。

14.3 監査ポリシーの管理

監査ポリシーとは、特定のコンポーネントについてOracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)によって記録されるイベントのタイプの宣言です。Javaコンポーネントでは、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントでは、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

コンポーネントやユーザーを追加したり、削除するなど、アプリケーション環境を変更した場合は、監査ポリシーを更新する必要があることに注意してください。ポリシーの変更にはサーバーまたはインスタンスの再起動は不要です。

OFM監査フレームワークを使用すると、監査ポリシーを構成でき、監視対象のイベントおよびデータのタイプはきめ細かく制御されます。監査ポリシーは、次の各項で説明しているように、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)、WebLogic Scripting Tool (WLST)またはプログラムを使用して構成します。

- Fusion Middleware Controlを使用した監査ポリシーの管理

- WLSTを使用した監査ポリシーの管理

- プログラムによる監査ポリシーの管理

関連項目:

第13.2項「監査の用語」

付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

14.3.1 Fusion Middleware Controlを使用した監査ポリシーの管理

この項に記載されている手順に従って、Fusion Middleware Controlを使用してJavaコンポーネントおよびシステム・コンポーネントの監査ポリシーを管理します。

1. タスク1: 「監査」ページのオープン

2. タスク2: Javaコンポーネント用の監査対象イベントの選択

3. タスク3: Javaコンポーネント用の監査ポリシーのカスタマイズ

4. タスク4: Javaコンポーネント用の監査フィルタの作成

5. タスク5: Javaコンポーネント用の監査ポリシーのインポートとエクスポート

6. タスク6: システム・コンポーネント用の監査対象イベントの選択

7. タスク7: システム・コンポーネント用の監査ポリシーのカスタマイズ

8. タスク8: システム・コンポーネント用の監査フィルタの作成

9. タスク9: システム・コンポーネント用の監査ポリシーのインポートとエクスポート

タスク1: 「監査」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「監査ポリシー」の順に移動します。「監査ポリシー」ページが表示されます。

タスク2: Javaコンポーネント用の監査対象イベントの選択

1. 「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

注意:
「監査ポリシー設定」領域で入力する値は、Oracle Access Manager監査には適用されません。

2. 「監査レベル」ドロップダウンで、ニーズに応じて監査レベルを選択します。

- なし - イベント・カテゴリを選択しません。

- 低、中、高 - 事前に定義された監査レベルを表すイベント・カテゴリのサブセットを選択します。

- カスタム - カスタム・フィルタを選択します。

チェック・フラグが「監査用に選択」列に表示され、選択したカテゴリのイベントが監査対象となります。フラグ付きカテゴリ内のイベントを表示するには、カテゴリ表でその行をクリックします。イベントの表はカスタム・レベルでのみ編集できます。

タスク3: Javaコンポーネント用の監査ポリシーのカスタマイズ

1. 「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. 「監査レベル」ドロップダウンで、「カスタム」を選択します。すべてのカテゴリが使用可能になります。

3. 「監査用に選択」列のボックスを選択して、監査ポリシーをカスタマイズするカテゴリおよびイベントを選択します。

4. 「適用」をクリックして変更を保存します。

タスク4: Javaコンポーネント用の監査フィルタの作成

1. 「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. 「フィルタの編集」列の鉛筆アイコンは、そのイベントでフィルタを使用できることを示します。イベントの鉛筆アイコンをクリックします。「フィルタの編集」ダイアログが表示されます。
各フィルタ属性には、正式名と表示名があります。いずれかの名前が「フィルタの編集」編集ダイアログに表示されます。

3. 「条件」ドロップダウンから項目を選択し、さらに演算子と値を選択してフィルタ条件を作成します。次に、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックします。

4. 必要に応じて、「常に監査するユーザー」で、ユーザーのカンマ区切りリストを指定し、そのユーザーによって起動されるイベントを監査します。監査は、指定された監査レベルやフィルタとは関係なく行われます。このフィールドに入力するユーザー名は検証されません。

5. Javaコンポーネントが実行されているOracle WebLogic Serverを再起動し、変更を反映します。

タスク5: Javaコンポーネント用の監査ポリシーのインポートとエクスポート

1. 「監査コンポーネント名」ドロップダウンで、Javaコンポーネントを選択します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. ポリシーを編集している間、いつでも次のいずれかを実行できます。

- 「エクスポート」をクリックして現在の設定をファイルに保存します。

- 「インポート」をクリックしてファイルから設定をロードします。

タスク6: システム・コンポーネント用の監査対象イベントの選択

1. システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. 「監査レベル」ドロップダウンで、監査レベルを選択します。

- なし - イベント・カテゴリを選択しません。

- 低、中、高 - 事前に定義された監査レベルを表すイベント・カテゴリのサブセットを選択します。

- カスタム - カスタム・フィルタを選択します。

チェック・フラグが「監査用に選択」列に表示され、選択したカテゴリのイベントが監査対象となります。フラグ付きカテゴリ内のイベントを表示するには、カテゴリ表でその行をクリックします。イベントの表はカスタム・レベルでのみ編集できます。

タスク7: システム・コンポーネント用の監査ポリシーのカスタマイズ

1. システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. 「監査レベル」ドロップダウンで、「カスタム」を選択します。すべてのカテゴリが使用可能になります。

3. 「監査用に選択」列のボックスを選択して、監査ポリシーをカスタマイズするカテゴリおよびイベントを選択します。

4. 「適用」をクリックして変更を保存します。

タスク8: システム・コンポーネント用の監査フィルタの作成

1. システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. 「フィルタの編集」列の鉛筆アイコンは、そのイベントでフィルタを使用できることを示します。イベントの鉛筆アイコンをクリックします。「フィルタの編集」ダイアログが表示されます。フィルタ属性には、正式名と表示名があります。いずれかの名前が「フィルタの編集」編集ダイアログに表示されます。

3. 「条件」ドロップダウンから項目を選択し、さらに演算子と値を選択してフィルタ条件を作成します。次に、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックします。

4. 必要に応じて、「常に監査するユーザー」で、ユーザーのカンマ区切りリストを指定し、そのユーザーによって起動されるイベントを監査します。監査は、指定された監査レベルやフィルタとは関係なく行われます。このフィールドに入力するユーザー名は検証されません。システム管理者などの特定のユーザーがコンポーネントの監査可能なイベントを実行するときはいつでも監査トラフィックが発生します。

5. システム・コンポーネントが実行されているWebLogic Serverを再起動します。

タスク9: システム・コンポーネント用の監査ポリシーのインポートとエクスポート

1. システム・コンポーネントのホーム・ページに移動します。コンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」領域に表示されます。

2. ポリシーを編集している間、いつでも次のいずれかを実行できます。

- 「エクスポート」をクリックして現在の設定をファイルに保存します。

- 「インポート」をクリックしてファイルから設定をロードします。

14.3.2 WLSTを使用した監査ポリシーの管理

この項に従って、WLSTを使用して監査ポリシーを管理します。

- WLSTコマンドを使用した監査ポリシーの表示

- WLSTコマンドを使用した監査ポリシーの更新

- 監査ポリシーの構成例

- 監査イベントの構成例

- 監査レベルを変更するとカスタム構成はどうなるか

14.3.2.1 WLSTコマンドを使用した監査ポリシーの表示

1. WebLogic Serverに接続します。

>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')

2. ドメインまたはJavaコンポーネントの監査ポリシーを表示するには、getAuditPolicyコマンドを使用します。

(view domain audit policies)
wls:/mydomain/serverConfig> getAuditPolicy()

(view component audit policies)
wls:/mydomain/serverConfig> getAuditPolicy(componentType="JPS")

3. システム・コンポーネントの監査ポリシーを表示するには、次のようにします。

1. getNonJava EEAuditMBeanNameコマンドを使用してシステム・コンポーネントMBean名を取得します。

2. getAuditPolicyコマンドを使用します。

wls:/mydomain/serverConfig> getAuditPolicy
(on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")

14.3.2.2 WLSTコマンドを使用した監査ポリシーの更新

1. 次のように、WebLogic Serverに接続します。

>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')

2. 階層を移動し、目的のドメインにアクセスします。

wls:/mydomain/serverConfig>

3. setAuditPolicyコマンドを使用して、監査ポリシーの構成を更新します。

4. システム・コンポーネントの場合は、setAuditPolicyコマンドを使用し、MBean名を含めると、監査ポリシーの構成が更新されます。監査MBeanの名前の書式は次のとおりです。

oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=INSTANCE,component=COMPONENT_NAME

例:

oracle.as.management.mbeans.register:type=component.auditconfig,name=auditconfig1,instance=instance1,component=oid1

5. Oracle HTTP ServerやLDAPなどのシステム・コンポーネントの場合は、setAuditPolicyコマンドまたはimportAuditConfigコマンドの発効後にsaveを明示的にコールします。
次の例では、この手順を示します。つまり、ツリーのルート・プロキシMBeanに移動し、invokeコマンドを使用してsetAuditPolicyをコールし、saveコマンドを使用しています。

ORACLE_COMMON_HOME/common/bin/wlst.sh
connect('username', 'password', 'protocol://localhost:7001', 'localhost:7001')
custom()
cd('oracle.as.management.mbeans.register')
cd('oracle.as.management.mbeans.register:type=component,name=oid1,instance=instance1')
invoke('load',jarray.array([],java.lang.Object),jarray.array([],
java.lang.String))
setAuditPolicy(filterPreset='None',
on='oracle.as.management.mbeans.register:type=component.auditconfig,
name=auditconfig1,instance=instance1,component=oid1')
invoke('save',jarray.array([],java.lang.Object),jarray.array([],
java.lang.String))

14.3.2.3 監査ポリシーの構成例

ドメインの現在のポリシーによってuser1というユーザーが監査されていますが、常に監査対象とするユーザーのリストに2つの名前(user2およびuser3)を追加し、監査対象ユーザーのリストからuser1を削除することにします。

このようなタスクを実行するには、次のコマンドを実行します。

setAuditPolicy
(filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")

14.3.2.4 監査イベントの構成例

ドメインの現在のポリシーによってユーザーのログアウト・イベントが監査されていますが、ログアウト・イベントを削除し、監査ログイン・イベントを追加することにします。

このようなタスクを実行するには、次のコマンドを実行します。

setAuditPolicy (on="OHS mbean name")
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")

イベントを追加および削除するために、Custom事前設定済フィルタがコールされたことに注意してください。

14.3.2.5 監査レベルを変更するとカスタム構成はどうなるか

カスタム監査レベルで監査を構成し、WLSTを使用して別の(カスタム以外の)監査レベルに切り替えても、明示的に削除しないかぎり、カスタム監査設定は保持されます。

次の手順では、監査レベルの変更が監査データ・コレクションにどのように影響するかを示します。

1. カスタム監査レベルはコンポーネントのポリシーで設定し、監査フィルタを構成の一部として指定します。

2. 実行時に、フィルタに従って監査データが収集されます。

3. setAuditPolicyコマンドを使用して、たとえばコンポーネントの監査ポリシーをカスタム監査レベルから低監査レベルに変更します。カスタム監査レベルの一部として設定されたフィルタは監査構成に残ります。

4. それ以降、監査データは低監査レベルに基づいて収集されます。

5. コンポーネントの監査ポリシーをカスタム・レベルに戻し、追加フィルタを追加します。この新しいフィルタは、元のフィルタに追加されます。元のフィルタを明示的に削除しないかぎり、このフィルタは構成の中で保持されます。

6. それ以降、監査データはカスタム・レベルの両方のフィルタに基づいて収集されます。

14.3.3 プログラムによる監査ポリシーの管理

OFM監査フレームワークには、アプリケーションで監査ポリシーの取得および更新に使用できる一連のインタフェースが用意されています。ポリシーの管理の詳細は、第22.4項「プログラムによるポリシーの管理」を参照してください。

14.4 監査のタイムスタンプの理解

リリース11.1.1.7.0より前の監査では、アプリケーション・サーバーのタイムゾーンを使用して監査レコードが書き出されていました。リリース11.1.1.7.0以降、監査およびサーバーでは別のタイムゾーンを使用することもできます。つまり、次のことを意味します。

- 新しいサイトは、監査イベントが協定世界時(UTC)で書かれているとみなします。

- リリース11.1.1.6.0からアップグレードされたサイトは、UTCの使用を明示的に指定しないかぎり、デフォルトでは、監査レコードに対してアプリケーション・サーバーのタイムゾーンを引き続き使用します。

バスストップ・ファイル内のレコードは、UTCを使用します。

新しいサイトでの監査タイムスタンプ

新しいインストールでは、監査レコードはUTCタイムスタンプを使用します。それは、監査構成でaudit.timezoneプロパティを使用して指定します。

<serviceInstance name="audit" provider="audit.provider"       location="./audit-store.xml">
<property name="audit.filterPreset" value="None"/>
<property name="audit.timezone" value="utc" />
<property name="audit.loader.repositoryType" value="File" />
<property name="auditstore.type" value="file"/>
</serviceInstance>

アップグレードされたサイトでの監査タイムスタンプ

リリース11.1.1.7より前の監査レコードは、アプリケーション・サーバーのタイムスタンプを使用していました。そのリリースからアップグレードした後も、サービスの構成に変更はなく、デフォルトでは、レコードはアプリケーション・サーバーのタイムスタンプを使用して書き込まれます。

12cへのアップグレード後にUTCを使用する場合は、不一致の可能性を回避するために現在のレコードを移動し、audit.timezoneサービス・プロパティを構成ファイルに挿入します。

関連項目:

第F.2.7項「監査サービスのプロパティ」

14.5 監査ログとバスストップ・ファイルについて

OFM監査フレームワークには、エラー・メッセージをログに記録する実行時コンポーネントがいくつかあります。このフレームワークには、OFM監査フレームワークで例外が発生した場合に、エラーのトレースや障害の診断に使用する一連のログ・ファイルが用意されています。

監査のバスストップ・ファイルのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。

関連項目:

第J.2.2.2項「監査のロギング」

第C.4項「監査ファイルのネーミングおよびロギング」

第14.4項「監査のタイムスタンプの理解」

14.6 監査データベースの管理

この項の次のトピックでは、監査スキーマの編成および管理について説明します。

- 監査スキーマの概要

- 実表およびコンポーネント表の属性

- パフォーマンスのチューニング

- バックアップとリカバリのプランニング

- データのインポートおよびエクスポート

- パーティション化

- 階層アーカイブの実行

- マテリアライズド・ビューを使用したカスタム表属性に対する索引の作成

14.6.1 監査スキーマの概要

OFM監査フレームワーク・スキーマの表は、次のものから構成されています。

- 実表の基本データ。この表には監査レコードの基本データが含まれており、IAU_ID属性を使用してコンポーネント固有の表に関連づけられています。

- IAU_COMMON表の共通属性。この表には監査レコードの基本データが含まれており、IAU_ID属性を使用してカスタム表に関連づけられています。

- 専用表の汎用属性。

- IAU_CUSTOM_nnn表のカスタム属性。

同時にこれらすべての表が使用されるわけではありません。動的モデルでは、共通表とカスタム表を使用しています。静的(従来の)モデルでは、実表とコンポーネント固有の表を使用しています。

関連項目:

第13.5項「監査の属性、イベントおよびイベント・カテゴリについて」

第13.4.1項「監査モデル」

14.6.2 実表およびコンポーネント表の属性

監査ローダーにより、2種類のデータ・レコードが表に格納されます。

- 一般的な情報(時間、イベント・タイプ、イベント・ステータスなど): 共通表(動的モデル)または実表の1行に格納されます。

- コンポーネント固有の情報: カスタム表(動的モデル)またはコンポーネント表の1行に格納されます。

平均的な監査レコード・サイズは約0.3KBです。この平均値は、データベース表のサイズ変更を計画する際の他、監査データベース・サイズがポリシーおよびアクティビティのレベルに応じて増加する様子を監視する際に使用します。

実表の属性は次のファイルから導出されます。

$ORACLE_HOME/modules/oracle.iau_12.2.1/components/generic/generic_events.xml

コンポーネント表の属性は次のファイルから導出されます。

$ORACLE_HOME/modules/oracle.iau_12.2.1/components/componentName/component_events.xml

表C-6に、IAU_BASE実表で定義されている属性を示します。表C-7に、IAU_COMMON共通表で定義されている属性を示します。

個々のコンポーネント表の属性名リストを取得するには、listAuditEvents WLSTコマンドを使用します。

関連項目:

第C.2項「監査スキーマ」

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のlistAuditEventsに関する項

14.6.3 パフォーマンスのチューニング

効率よく問い合せるために、実表IAU_TSTZORIGINATING列およびコンポーネント固有の各表に対して索引がデフォルトで作成されます。

デフォルトの索引は、IAU_BASEではEVENT_TIME_INDEX、コンポーネント表ではtableName_INDEX (OVDCOMPONENT_INDEX、OIDCOMPONENT_INDEX、JPS_INDEXなど)です。

共通表の追加の列および索引は次のとおりです。

- IAU_TSTZORIGINATING: 索引はDYN_EVENT_TIME_INDEX

- IAU_AuditUser: 索引はDYN_USER_INDEX

- IAU_ComponentType: 索引はDYN_COMPONENT_TYPE_INDEX

- IAU_EventCategory: 索引はDYN_EVENT_CATEGORY_INDEX

- IAU_EventType: 索引はDYN_EVENT_TYPE_INDEX

14.6.4 バックアップとリカバリのプランニング

監査データベースのバックアップを計画する際、次の点を考慮します。

- 監査イベントの増加率
フレームワークで生成される監査イベントの数は監査ポリシーによって決まり、ストアをバックアップする頻度は日々生成される監査イベントの数によって決まります。

- コンプライアンスの規制
バックアップの実行頻度および監査データの必須保存年数は、各組織のコンプライアンス規制を参照して決定してください。

Oracle DatabaseユーティリティのRecovery Manager (RMAN)を使用してOracle Databaseをバックアップおよびリカバリします。IAU_DISP_NAMES_TL変換表は通常、時間の経過とともに変化しないため、バックアップが必要なのは1回のみです。

関連項目:

第7.6.1項「DBセキュリティ・ストアのバックアップとリカバリ」

14.6.5 データのインポートとエクスポート

たとえば、複数の監査リポジトリを結合して単一の監査ストアとする場合やデータベースの規模を拡大する場合は、監査スキーマをインポートおよびエクスポートしてデータを移行します。Oracle Data Pumpを使用してOracle Databaseからデータをインポートおよびエクスポートします。

14.6.6 データのパージ

フレームワークには、監査ストアからレコードをパージするために、次のSQLスクリプトが$MW_HOME/oracle_common/common/sql/iau/scriptsディレクトリに用意されています。

- auditDataPurge.sql

- auditDeleteData.sql

- auditReclaimSpace.sql

他のアクションを実行せずにレコードを削除するには、auditDeleteData.sqlを使用します。このスクリプトの構文は次のとおりです。

auditDeleteData.sql audit_schema_user number_of_days_to_keep

たとえば、100日を超過したレコードを削除するには、次のようにします。

sqlplus> @auditDeleteData.sql DEV_IAU 100

領域を再要求するには、auditReclaimSpace.sqlを使用します。このスクリプトの構文は次のとおりです。

auditReclaimSpace.sql audit_schema_user

監査レコードを削除して領域を再要求するには、auditDataPurge.sqlを使用します。このスクリプトの構文は次のとおりです。

auditDataPurge.sql audit_schema_user number_of_days_to_keep

たとえば、100日を超過したレコードをすべて削除し、領域を小さくするために行の移動を有効にするには、次のようにします。

sqlplus> @auditDataPurge.sql DEV_IAU 100

14.6.7 パーティション化

すべてのデータベース・システムでパーティション化がサポートされているわけではなく、デフォルトでは、監査スキーマ内の表はすべてパーティション化されていません。

監査データは時間の経過とともに増えるため、大量のデータを格納する場合は、アーカイブが容易になるように監査スキーマのパーティション化を検討します。

パーティション化には、次のような利点があります。

- パフォーマンスの向上: たとえば、表がタイムスタンプによってレンジ・パーティション化されている場合、タイムスタンプによる問合せを処理できるのは、その時間枠内のパーティションのみとなります。

- 管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、古いデータは低速で大型のディスクに移動する一方、新しいデータは高速で小型のディスクに保持できます。
また、パーティション化により、アーカイブ処理もはるかに容易になります。

- 可用性の拡張: たとえば、単一のパーティションが使用不可の場合に、問合せでそのパーティションを対象から外せることが判明しているのであれば、使用不可のパーティションが使用可能になるのを待たずに、問合せを処理できます。

14.6.8 階層アーカイブの実行

表のパーティション化により、個々のパーティションを記憶域の様々な層に格納できます。通常、表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成します。

Oracle Information Lifecycle Management (ILM)はパーティション化および圧縮による合理化されたデータ管理を特徴としています。

14.6.9 マテリアライズド・ビューを使用したカスタム表属性に対する索引の作成

データベース・ビューを使用すると、監査レコードに対して問合せを実行できます。さらに、カスタム表で、索引付け可能ビューを使用して属性に索引を作成できます。アプリケーションでは、まず簡易ビューを作成し、後で必要なときに索引付け可能ビューに切り替えることをお薦めします。

索引付け可能ビューを作成するには、次の手順を実行します。

1. component_events.xmlファイルにイベント属性を指定します。リリース12c (12.2.1)では、新しいindexable属性がAttributeType要素に追加されています。

Component_events.xml
<?xml version="1.0"?>
<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit-2.0.xsd">
<AuditComponent componentType="ApplicationAudit" major="1" minor="1">
<Attributes ns="accounting" version="1.0">
<Attribute name="TransactionType" displayName="Transaction Type" type="string" order="1" indexable="true">
<HelpText>Transaction type.</HelpText>
</Attribute>
<Attribute name="AccountNumber" displayName="Account Number" type="int" order="2">
<HelpText>Account number.</HelpText>
</Attribute>
<Attribute name="Date" displayName="Date" type="dateTime" order="3"/>
<Attribute name="Amount" displayName="Amount" type="float" order="4">
<HelpText>Transaction amount.</HelpText>
</Attribute>
<Attribute name="Status" displayName="Account Status" type="string" order="5" indexable="true">
<HelpText>Account status.</HelpText>
</Attribute>
</Attributes>
...
</AuditComponent>
</AuditConfig>

2. 登録時または登録後のいずれかに索引付け可能ビューを作成します。
登録時の場合は、次のいずれかを実行します。

- weblogic-application.xmlでopss.audit.iauviewデプロイメント・パラメータをINDEXABLEと指定します。

- createView=INDEXABLEオプションをregisterAuditコマンドに渡します。

- AuditRegistrationExtインタフェースを実装し、getIAUViewSupportTypeメソッドからAuditRegistrationExt.TYPE.INDEXABLEを戻します。

登録後の場合は、次のいずれかを実行します。

- createIAUViewコマンドを実行してINDEXABLEビューに切り替えます。

- INDEXABLEビュー・タイプを指定してcreateAuditDBViewコマンドを使用するSQLスクリプトを生成します。次に、管理者としてそのスクリプトを実行します。

イベント定義を変更する場合は、再デプロイの前に関連するマテリアライズド・ビューを削除します。

14.7 監査イベント定義のベスト・プラクティス

この項の次のトピックでは、監査構成を管理し、収集された監査データの価値を最大限生かすためのガイドラインを示します。

- イベントのネーミングのガイドライン

- イベントの区別

- イベントの分類

- 汎用属性の使用

- コンポーネント属性の使用

- コンポーネント間のリンクのガイドライン

- イベント定義の更新

14.7.1 イベントのネーミングのガイドライン

監査名はすべて、次のネーミング規則に準拠する必要があります。

- componentType、Category、EventまたはAttributeの名前では、!、@、"、#、$、%、', (、)、*、+、カンマ、ピリオド、-、_、/、空白、:、;、<、=、>、?、{、}、~、^の各文字を使用できません。

- 表示名でのみ、空白文字を使用できます。

監査イベントに名前を付ける場合は、次のようにします。

- イベント名の接頭辞としてコンポーネント名を付けないでください。

- できるだけ具体的な名前を付けてください。たとえば、HTTPレスポンス・コードを定義する際には、ResponseではなくHTTPResponseを使用します。

- すべてのイベント名の接尾辞としてEventを付けないでください。たとえば、AuthenticationEventではなく、Authenticationを使用します。

14.7.2 イベントの区別

イベントの使用を最適にするには、次のようにします。

- 操作ごとに異なるイベントを定義します。たとえば、属性Deleteと属性Createを指定してイベントPolicyを定義するのではなく、イベントPolicyCreateとイベントPolicyDeleteを別々に定義します。

- イベントの成功および失敗について別々のイベントを定義しないでください。たとえば、イベントPolicyCreateSuccessとイベントPolicyCreateFailureを別々に定義しないでください。かわりに、属性EventStatusを使用して成否を記録します。

14.7.3 イベントの分類

イベントを分類するには、次のようにします。

- 必要に応じて、システム・カテゴリを参照します。たとえば、UserSessionやAuthorizationを参照します。

- 構成操作では、操作のグループを基準にカテゴリを作成します。たとえば、PolicyCreateやPolicyDeleteは、コンポーネント固有のカテゴリPolicyに入れます。

14.7.4 汎用属性の使用

汎用属性を定義する場合は、次のようにします。

- 次のイベント属性を含めます。

- Initiator - イベント・アクションを実行したユーザー

- MessageText - 何が起こったのかについての簡単な説明。

- EventStatus - イベントの結果

- FailureCode - 失敗に該当するエラー・コード。

- 属性Resource(アクセスされたURIや付与されたパーミッションなど、影響を受けたオブジェクト)を使用します。

14.7.5 コンポーネント属性の使用

OFM監査フレームワークでは、各イベントの共通属性すべての和集合と見なし、各属性についてデータベース列を定義します。したがって、できるだけ多くの共通属性を定義するようにしてください。

14.7.6 コンポーネント間のリンクのガイドライン

コンポーネントによって生成されたイベントが他のイベントとクロスリンクできるように、十分な情報を定義します。

14.7.7 イベント定義の更新

component_events.xmlファイルではバージョン・サポートがあります。イベント定義を変更することにした場合は、必ず関連付けられたマテリアライズド・ビューを削除します。

15 監査分析と監査レポートの使用

この章では、監査レポートの構成方法および表示方法について説明します。

この章の内容は次のとおりです。

- 監査レポートについて

- 動的メタデータ・モデルを使用した監査レポート

15.1 監査レポートについて

Oracle Fusion Middleware監査フレームワークでは、2つの方法で監査レポートを作成できます。採用する方法は、サイトでコンポーネントが使用している監査モデルによって決まります。

- 動的メタデータ・モデル
このモデルは、11g リリース1 (11.1.1.6.0)で導入されました。12c (12.1.2)以降のOracle Fusion Middlewareのインストールでは、このモデルが使用されます。このモデルの詳細は、「動的メタデータ・モデルを使用した監査レポート」を参照してください。

- レポート・テンプレート・モデル
この古いモデルは、システム・コンポーネントによって使用されます。アップグレードしても、OFM監査フレームワークでは引き続きこのモデルが使用されます。

15.2 動的メタデータ・モデルを使用した監査レポート

監査イベントは、iau_common共通属性表およびiau_custom_nnnカスタム属性表に保存されます。Oracle Platform Security Services共通監査フレームワークでは、SQLスクリプトを生成してOracle Databaseビューを作成します。コンポーネント・レポート・アプリケーションはこれらのビューを使用して、監査データベース表から監査イベント・データを問い合せることができます。

動的メタデータ・モデルを使用して監査レポートを設定するには、次の手順を実行します。

1. 監査にアプリケーションを登録します。監査登録によって監査ビューが作成され、監査データに対して問合せを実行できるようになります。手動による監査ビューの生成の詳細は、第22.3項「サービスへのアプリケーションの登録」を参照してください。

2. 監査データを生成するイベントが監査でログに記録されるように、監査ポリシーを構成します。監査ロギングの詳細は、第22.5項「プログラムによる監査イベントのロギング」を参照してください。

3. バスストップ・ファイルがデータベースに必ず移行されるように監査ローダーを構成します。バスストップ・ファイルの詳細は、第14.2.2項「バスストップ・ファイルの管理」を参照してください。

4. 登録時に監査ビューを作成しなかった場合は、次のようにします。

- createAuditDBViewを使用して、監査定義のSQLファイルを生成します。

- IAUスキーマ・ユーザーとしてデータベースにログインし、SQLスクリプトを使用してビューを作成します。

5. ビューに問い合せるレポート作成アプリケーションを構成します。

関連項目:

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のcreateAuditDBViewに関する項

「登録時に作成される監査ビュー」

「手動で作成される監査ビュー」

15.2.1 登録時に作成される監査ビュー

リリース12c (12.2.1)以降では、監査データのデータベース・ビューを登録時に作成できます。次のビューがサポートされています。

- 簡易ビュー - このビューは、IAU_COMMON表およびIAU_CUSTOM_*表の列に対するコンポーネント属性の実行時データベース・マッピングに基づいています。
簡易データベース・ビューは、コンポーネントを監査に登録する際にIAU VIEWERスキーマ内に作成されます。このビュー・タイプは、サポートされているすべてのデータベースで使用できます。Oracle Fusion Middlewareリポジトリ作成ユーティリティを使用してスキーマを作成すると、コンポーネントについて簡易ビューが自動的に作成されます。

- 索引付け可能ビュー - 索引付けが可能な簡易ビューです。このビューでは、レポート問合せのパフォーマンスを向上させるためにOracleマテリアライズド・ビューを利用しています。このビューは、すぐに使用できる状態では、Oracle Databaseでのみサポートされています。
索引付け可能ビューは監査ローダーのパフォーマンスに影響を及ぼす可能性があるため、注意して使用してください。コンポーネントでは、createIAUView WebLogic Scripting Tool (WLST)コマンドを使用して索引付け可能ビューに切り替えることができます。修飾されたイベント属性がコンポーネント監査定義に存在する必要があります。索引の詳細は、第14.6.9項「マテリアライズド・ビューを使用したカスタム表属性に対する索引の作成」を参照してください。

ファイル監査リポジトリでは、ビューはサポートされていません。

15.2.2 手動で作成される監査ビュー

監査ビューを手動で作成するには、createAuditDBViewコマンドを使用します。ApplicationAuditコンポーネントについてビューを作成するためにコールされたときに、このコマンドによって生成された出力を次に示します。

-- Audit View for Component
CREATE VIEW ApplicationAudit_AUDITVIEW AS
SELECT IAU_AUDITSERVICE.IAU_TRANSACTIONID AS AUDITSERVICE_TRANSACTIONID,
IAU_COMMON.IAU_COMPONENTTYPE AS ComponentType,
IAU_COMMON.IAU_MAJORVERSION AS MajorVersion,
IAU_COMMON.IAU_MINORVERSION AS MinorVersion,
IAU_COMMON.IAU_INSTANCEID AS InstanceId,
IAU_COMMON.IAU_HOSTID AS HostId,
IAU_COMMON.IAU_HOSTNWADDR AS HostNwaddr,
IAU_COMMON.IAU_MODULEID AS ModuleId,
IAU_COMMON.IAU_PROCESSID AS ProcessId,
IAU_COMMON.IAU_ORACLEHOME AS OracleHome,
IAU_COMMON.IAU_HOMEINSTANCE AS HomeInstance,
IAU_COMMON.IAU_ECID AS ECID,
IAU_COMMON.IAU_RID AS RID,
IAU_COMMON.IAU_CONTEXTFIELDS AS ContextFields,
IAU_COMMON.IAU_SESSIONID AS SessionId,
IAU_COMMON.IAU_TARGETCOMPONENTTYPE AS TargetComponentType,
IAU_COMMON.IAU_APPLICATIONNAME AS ApplicationName,
IAU_COMMON.IAU_EVENTTYPE AS EventType,
IAU_COMMON.IAU_EVENTCATEGORY AS EventCategory,
IAU_COMMON.IAU_EVENTSTATUS AS EventStatus,
IAU_COMMON.IAU_TSTZORIGINATING AS TstzOriginating,
IAU_COMMON.IAU_THREADID AS ThreadId,
IAU_COMMON.IAU_COMPONENTNAME AS ComponentName,
IAU_COMMON.IAU_INITIATOR AS Initiator,
IAU_COMMON.IAU_MESSAGETEXT AS MessageText,
IAU_COMMON.IAU_FAILURECODE AS FailureCode,
IAU_COMMON.IAU_REMOTEIP AS RemoteIP,
IAU_COMMON.IAU_TARGET AS Target,
IAU_COMMON.IAU_RESOURCE AS IAU_RESOURCE,
IAU_COMMON.IAU_ROLES AS Roles,
IAU_COMMON.IAU_DOMAINNAME AS DomainName,
IAU_COMMON.IAU_COMPONENTDATA AS ComponentData,
IAU_COMMON.IAU_AUDITUSER AS AuditUser,
IAU_COMMON.IAU_TENANTID AS TenantId,
IAU_COMMON.IAU_TRANSACTIONID AS TransactionId,
IAU_COMMON.IAU_USERTENANTID AS UserTenantId,
IAU_CUSTOM.IAU_INT_001 AS AccountNumber,
IAU_CUSTOM.IAU_DATETIME_001 AS Date,
IAU_CUSTOM.IAU_FLOAT_001 AS Amount,
IAU_CUSTOM.IAU_STRING_002 AS Status,
IAU_CUSTOM.IAU_FLOAT_002 AS Balance,
IAU_USERSESSION.IAU_AUTHENTICATIONMETHOD AS AuthenticationMethod
FROM IAU_AUDITSERVICE, IAU_COMMON, IAU_CUSTOM, IAU_USERSESSION WHERE IAU_COMMON.IAU_ID = IAU_AUDITSERVICE.IAU_ID AND IAU_COMMON.IAU_ID = IAU_CUSTOM.IAU_ID AND IAU_COMMON.IAU_ID = IAU_USERSESSION.IAU_ID AND IAU_COMMON.IAU_ComponentType = 'ApplicationAudit';

第IV部

OPSS APIを使用した開発

この部は、次の章で構成されています。

- 第16章「アプリケーション・セキュリティのOPSSとの統合」

- 第17章「セキュリティ・モデル」

- 第18章「資格証明ストア・フレームワークを使用した開発」

- 第19章「ユーザーおよびロールAPIを使用した開発」

- 第20章「Identity Governance Frameworkを使用した開発」

- 第21章「キーストア・サービスを使用した開発」

- 第22章「Oracle Fusion Middleware監査フレームワークを使用した開発」

- 第23章「OPSSを使用するためのJava EEアプリケーションの構成」

- 第24章「OPSSを使用するためのJava SEアプリケーションの構成」

16 アプリケーション・セキュリティのOPSSとの統合

この章では、ドメイン内およびドメイン間のアイデンティティの伝播を含め、様々なセキュリティのユースケースと、Oracle Application Development Framework (Oracle ADF)アプリケーション・セキュリティの一般的なライフ・サイクルについて説明します。

この章の内容は次のとおりです。

- セキュリティの課題について

- セキュリティ統合ユースケース

- OPSSトラスト・サービス

- HTTPを介したアイデンティティの伝播

- OPSSトラスト・サービスを使用したアイデンティティの伝播

- カスタム・グラフィカル・ユーザー・インタフェースの実装

- Oracle ADFアプリケーションの保護

- コードおよび構成例

- JKSを使用したアイデンティティの伝播

16.1 セキュリティの課題について

この章では、いくつかの一般的なセキュリティの課題を解決するユースケースを紹介します。これらのユースケースを、特定のアプリケーション・セキュリティ要件を解決するための出発点として使用します。対象読者は、開発者、セキュリティ設計者およびセキュリティ管理者であり、記載されている解決策では、宣言的アプローチとプログラム的アプローチの両方を提供します。

直面する上位のセキュリティの課題には、ユーザーの管理、ユーザー・パスワードの管理、リソースへのアクセスの制御などがあります。OPSSでは、次をサポートすることでこれらの課題に対する解決策を提供します。

- 外部セキュリティ・アーティファクトのアプリケーション・ロジックからの分離

- セキュリティに対する宣言的アプローチ

- 完全なユーザー・アイデンティティ・ライフ・サイクル

- ポリシー主導のアクセス制御

図16-1に、アプリケーションがセキュリティ・ストアにアクセスする方法と、それらの管理に使用するツールを示します。

図16-1 アプリケーション、セキュリティ・ストアおよび管理ツール

関連項目:

第1.2項「OPSSアーキテクチャの概要」

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

Oracle Application Development FrameworkによるFusion Webアプリケーションの開発

『Oracle Fusion Middleware Reference for Oracle Security Developer Tools』

付録G「OPSS APIリファレンス」

16.2 セキュリティ統合ユースケース

次の各項では、ユースケースをいくつか紹介します。

- 認証

- アイデンティティ

- 認可

- 資格証明

- 監査

- アイデンティティ伝播

- 管理

- 統合

各ユースケースには、解決を試みる問題の簡単な説明、関連するセキュリティおよび機能、詳細情報へのリンクが含まれています。

16.2.1 認証

次の各項では、認証のユースケースについて説明します。

- 認証されたユーザーが必要なJava EEアプリケーション - Java EEアプリケーションにアクセスするには、ユーザーは認証を受ける必要があります。

- プログラム認証が必要なJava EEアプリケーション - Java EEアプリケーションで、ユーザーをプログラムにより認証する必要があります。

- 認証が必要なJava SEアプリケーション - Java SEアプリケーションで、ドメイン・アイデンティティ・ストアに対して認証を行う必要があります。

16.2.1.1 認証されたユーザーが必要なJava EEアプリケーション

Java EEアプリケーションにアクセスするために、ユーザーはアイデンティティ・ストアに対して認証される必要があり、この場合、アイデンティティ・ストアは次のいずれかになります。

- 単一のLDAPストア。

- 同じ種類の複数のLDAPストア。

- 異なる種類の複数のLDAPストア(Microsoft Active DirectoryとOracle Internet Directoryなど)。

- 単一のDBストア。

- 複数のLDAPストアおよびDBストア。

このユースケースでは、次のことが求められます。

- アプリケーションへのアクセスを認証されたユーザーにのみ許可する

- 顧客が別のリポジトリでユーザー・アイデンティティを管理している場合でも、アプリケーション・コードは変更しない

このユースケースでは、次の機能を使用します。

- 特定のユーザー・リポジトリのセットに応じた適切な認証プロバイダの構成。

- LDAPタイプが混在するか、LDAPタイプとDBタイプが混在する場合の認証プロバイダの構成。

使用されているリポジトリに応じて、このユースケースの詳細は、次のシナリオに分かれます。

- 単一のユーザー・リポジトリ - 適切なWebLogic認証プロバイダを構成します。

- 複数のユーザー・リポジトリ - LDAPプロバイダを構成します。

- DBリポジトリ - データベース・プロバイダを構成します。

認証プロバイダの詳細は、第3.2.1項「WebLogic認証プロバイダ」を参照してください。

16.2.1.2 プログラム認証が必要なJava EEアプリケーション

デプロイメント・ディスクリプタを使用しないJava EEアプリケーションで、構成済のアイデンティティ・ストアに対してユーザーをプログラムにより認証する必要があります。

このユースケースでは、ユーザーを認証するためにOPSS APIを使用する必要があり、次の機能を使用します。

- Javaコンテナ用の認証プロバイダの構成

- ユーザーを認証するためのoracle.security.jps.service.login.LoginServiceインタフェースの使用

認証の詳細は、第23.1項「Java EEアプリケーションでの認証について」を参照してください。

16.2.1.3 認証が必要なJava SEアプリケーション

Java SEアプリケーションで、ドメイン内で使用されているLDAPアイデンティティ・ストアに対してユーザーを認証する必要があります。認証をリクエストするアプリケーション・コードは、ドメインのアイデンティティ・ストアの詳細に関係なく同じである必要があります。

このユースケースでは、認証先となるアイデンティティ・ストアを構成し、oracle.security.jps.service.login.LoginServiceインタフェースを使用する必要があります。Java SEアプリケーションで使用できるアイデンティティ・ログイン・モジュールは1つのみです。

プログラムによるログイン・モジュールの使用の詳細は、第24.3.3項「Java SEアプリケーションでのログイン・モジュールの使用」を参照してください。

16.2.2 アイデンティティ

次の各項では、アイデンティティのユースケースについて説明します。

- 2つの環境で実行されるアプリケーション - 2つの異なる環境で実行されるアプリケーションで、単一のLDAPストア内のユーザー・プロファイル情報にアクセスする必要があります。

- 複数のストア内のユーザー・プロファイルにアクセスするアプリケーション - アプリケーションで、複数のLDAPストアに格納されたユーザー・プロファイル情報にアクセスする必要があります。

16.2.2.1 2つの環境で実行されるアプリケーション

2つの異なる環境で実行可能なアプリケーションで、LDAPストアに格納されているユーザー・プロファイル情報にアクセスする必要があります。LDAPサーバーは環境によって異なる場合があります。

さらに具体的には、このユースケースでは次のことを前提としています。

- アプリケーションではUserProfile.getEmailメソッドを使用します。

- 一方の環境では、Microsoft Active Directoryサーバーでメールが構成されています。

mail.attr = msad_email

- 他方の環境では、Oracle Identity Directoryサーバーでメールが構成されています。

mail.attr = mail

コードを変更せず、実行される環境(1つ目または2つ目)に関係なく、アプリケーションが正しい情報を取得するには、それぞれの環境でアイデンティティ・ストア・プロバイダを適切なプロパティで構成する必要があります。

Microsoft Active Directoryでは、アイデンティティ・ストア・プロバイダのnameプロパティを次のように設定します。

<property name="mail.attr" value="msad_mail">

Oracle Identity Directoryでは、アイデンティティ・ストア・プロバイダのnameプロパティを次のように設定します。

<property name="mail.attr" value="mail"

アイデンティティ・ストア・プロバイダの構成の詳細は、第8.2項「アイデンティティ・ストア・プロバイダの構成」を参照してください。

16.2.2.2 複数のストア内のユーザー・プロファイルにアクセスするアプリケーション

アプリケーションで、複数のLDAPストア・サーバーにあるユーザー・プロファイル情報にアクセスする必要があります。このシナリオでは、複数のLDAPストア用に環境を構成する必要があります。手順の詳細は、第8.3.2.8項「単一および複数のLDAPの構成」を参照してください。

16.2.3 認可

次の各項では、認可のユースケースについて説明します。

- 特定のロールのみアクセス可能なJava EEアプリケーション - Webディスクリプタで構成されているユーザーのみがアクセスできるJava EEアプリケーションです。

- ファイングレイン認可が必要なOracle ADFアプリケーション - Oracle ADFアプリケーションにファイングレイン認可が必要です。

- Webサービスを保護するアプリケーション - アプリケーションで、Webサービスを保護する必要があります。

- コードソース・パーミッションが必要なJava EEアプリケーション - Java EEアプリケーションにコードソース・パーミッションが必要です。

- ファイングレイン認可が必要な非Oracle ADFアプリケーション - 非Oracle ADFアプリケーションにファイングレイン認可が必要です。

16.2.3.1 特定のロールのみアクセス可能なJava EEアプリケーション

Webディスクリプタで特定のロールが割り当てられたユーザーのみがアクセスできるJava EEアプリケーションの場合、グループ対ロールの割当ては、顧客の環境に基づいてデプロイ時に構成できる必要があります。

宣言によるセキュリティの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のWebアプリケーションでの宣言によるセキュリティの使用に関する項およびEJBでの宣言によるセキュリティの使用に関する項を参照してください。

16.2.3.2 ファイングレイン認可が必要なOracle ADFアプリケーション

アプリケーションのページ上の個々のコントロール・レベルでファイングレイン認可が必要なOracle ADFアプリケーションの場合、ポリシーを外部化し、アプリケーションのデプロイ後にカスタマイズする必要があります。

関連項目:

「Oracle ADFアプリケーションの保護」

『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の「Fusion WebアプリケーションでのADFセキュリティの有効化」

16.2.3.3 Webサービスを保護するアプリケーション

アプリケーションで、ファイングレイン認可を使用してWebサービスを保護する必要があります。Webサービスの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

16.2.3.4 コードソース・パーミッションが必要なJava EEアプリケーション

Java EEアプリケーションで、特定のアクションを実行するためにコードソース・パーミッションが必要です。典型的な例として、資格証明ストアからの資格証明の読取りやポリシーの検索があります。パーミッションの詳細は、「権限付与の構成」を参照してください。

16.2.3.5 ファイングレイン認可が必要な非Oracle ADFアプリケーション

非Oracle ADFアプリケーションで、ファイングレイン認可チェックが必要です。このシナリオでは、次のようにします。

- アプリケーション・コードにチェックを挿入します。

- 適切なポリシーを構成します。

プログラムによるポリシーの管理およびチェックの詳細は、第17.3項「JAAS/OPSS認可モデル」を参照してください。

16.2.4 資格証明

次の項では、資格証明のユースケースについて説明します。

- システムへのアクセスに資格証明が必要なアプリケーション - アプリケーションにバックエンド・システムにアクセスするための資格証明が必要です。

16.2.4.1 システムへのアクセスに資格証明が必要なアプリケーション

あるアプリケーションには、データベースまたはLDAPサーバーなどのバックエンド・システムに接続するために資格証明が必要です。アプリケーション・コードは、デプロイメント後にアプリケーション・コードを変更することなく顧客ごとに資格証明の詳細が変更可能になるよう、この資格証明を参照する必要があります。さらにこのユースケースでは、資格証明ストアにアクセスできるユーザー、および認可されたユーザーが資格証明ストアで実行できる操作を指定する必要もあります。

このユースケースでは、次の機能を使用します。

- 資格証明を永続化するための資格証明ストアの使用

- アプリケーション・コード内での資格証明ストア・フレームワークAPIによる実行時の資格証明のフェッチ

- コードソースでのシステム・ポリシーの定義と施行

関連項目:

第11章「資格証明の管理」

第18.4項「アクセス・パーミッションのプロビジョニング」

第18.6項「資格証明ストア・フレームワークAPIの例」

第23.5.2項「アプリケーションとの資格証明のパッケージ化」

16.2.5 監査

次の各項では、監査のユースケースについて説明します。

- セキュリティ関連アクティビティの監査 - アプリケーションは、セキュリティ関連のアクティビティを記録する必要があります。

- ビジネス関連アクティビティの監査 - アプリケーションは、フローのコンテキストでビジネス・アクティビティを記録する必要があります。

16.2.5.1 セキュリティ関連アクティビティの監査

このユースケースで説明する設定は、ドメイン内のすべてのアプリケーションおよびコンポーネントに当てはまります。ドメイン内で実行されているアプリケーションで、ポリシー、資格証明または鍵がいつ変更されたかと、特定の時間間隔内に評価されたポリシーを記録する必要があります。

このユースケースでは、次の機能を使用します。

- アプリケーションとOracle Platform Security Services共通監査フレームワークとの統合。

- セキュリティ領域内でのアプリケーションの監査カテゴリおよび監査イベントの定義と、アプリケーションの監査対応化。

- 各アプリケーションでの適切なフィルタ・レベルの設定。

関連項目:

第22.3項「サービスへのアプリケーションの登録」

第22.5項「プログラムによる監査イベントのロギング」

16.2.5.2 ビジネス関連アクティビティの監査

このユースケースで説明する設定は、ドメイン内のすべてのアプリケーションおよびコンポーネントに当てはまります。アプリケーションで、機能フローのコンテキストでビジネス関連アクティビティを記録する必要があります。具体的には、ユーザーおよびそのユーザーにより特定の間隔で実行されるビジネス・アクションのロギングを行う必要があります。

このシナリオを実現するには、ビジネス・ニーズに基づいて監査イベントを作成し、アプリケーションでイベント・アクティビティを監査ストアに記録します。さらに、監査イベントから監査レポートを生成し、実行時監査ポリシーを管理し、必要に応じて監査イベント定義を変更します。

このユースケースでは、次の機能を使用します。

- アプリケーションがビジネス機能領域(監査カテゴリとして)、ビジネス・アクティビティ(カテゴリ内の監査イベントとして)、および各カテゴリ内に属性を定義することを可能にする

- デプロイ時のアプリケーションの登録、監査定義の更新、デプロイ後のアプリケーションの登録解除。

- Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはWebLogic Scripting Tool (WLST)コマンドを使用した監査アーティファクトの管理。

関連項目:

第22.3項「サービスへのアプリケーションの登録」

第22.5項「プログラムによる監査イベントのロギング」

第22.2項「監査定義ファイルの作成」

第14.3項「監査ポリシーの管理」

16.2.6 アイデンティティ伝播

次の各項では、アイデンティティ伝播のユースケースについて説明します。

- 実行ユーザー・アイデンティティの伝播

- ユーザー・アイデンティティの伝播

- 別のドメインへのアイデンティティの伝播

- HTTPを介したアイデンティティの伝播

16.2.6.1 実行ユーザー・アイデンティティの伝播

コンテナ内のクライアント・アプリケーションで、シンプル・オブジェクト・アクセス・プロトコル(SOAP)を介してWebサービスに実行ユーザー・アイデンティティを伝播する必要があります。Webサービスは、同じドメイン内(同じまたは異なる管理対象サーバー)でも異なるドメイン内でも実行されています。

OWSMの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

16.2.6.2 ユーザー・アイデンティティの伝播

コンテナ内のクライアント・アプリケーションで、SOAPを介してWebサービスにユーザー・アイデンティティ(実行ユーザー・アイデンティティとは異なる)を伝播する必要があります。

このユースケースでは、アプリケーションで伝播する特定のアイデンティティを資格証明ストアから取得し、OWSM機能を使用してそのアイデンティティをリモート・サーバーに伝播します。

OWSMの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

16.2.6.3 別のドメインへのアイデンティティの伝播

コンテナ内のクライアント・アプリケーションで、ユーザー・アイデンティティ(セキュリティ・ストアに格納されている)を、別のWebLogic Serverドメインに伝播する必要があります。

ドメインの信頼の詳細は、『Oracle WebLogic Server WebLogic Webサービスの保護』のWebLogic Serverドメイン間の信頼の有効化に関する項を参照してください。

16.2.6.4 HTTPを介したアイデンティティの伝播

コンテナ内のクライアント・アプリケーションで、HTTPを介してアイデンティティを伝播する必要があります。OPSSトラスト・サービスを使用して実現することをお薦めします。

関連項目:

OPSSトラスト・サービスを使用したアイデンティティの伝播

「JKSを使用したアイデンティティの伝播」

16.2.7 管理

次の各項では、管理のユースケースについて説明します。

- 集中管理されたストアが必要なアプリケーション

- カスタム管理ツールが必要なアプリケーション

- 複数のサーバー環境で実行されるアプリケーション

16.2.7.1 集中管理されたストアが必要なアプリケーション

アプリケーションで、ポリシー、資格証明、監査構成、信頼および鍵の中央リポジトリと、それを管理する一連のツールが必要です。このユースケースを実現するには、OPSSサービスおよびツールを使用してセキュリティ・サービスを管理します。

関連項目:

第9.1項「セキュリティ・ストアについて」

第10.3項「Fusion Middleware Controlを使用したポリシーの管理」

第10.4項「WLSTを使用したポリシーの管理」

第11.3項「Fusion Middleware Controlを使用した資格証明の管理」

第11.4項「WLSTを使用した資格証明の管理」

第12章「鍵と証明書の管理」

16.2.7.2 カスタム管理ツールが必要なアプリケーション

アプリケーションで、外部化したセキュリティ・データを管理するためのカスタム・ツールが必要です。このユースケースを実現するには、アプリケーションに有意味なコンテキストでセキュリティ・データを表示および管理するためのOPSS APIをコールするカスタム・グラフィカル・ユーザー・インタフェースを作成する必要があります。

関連項目:

カスタム・グラフィカル・ユーザー・インタフェースの実装

付録G「OPSS APIリファレンス」

16.2.7.3 複数のサーバー環境で実行されるアプリケーション

管理サーバーで変更を開始し、管理対象サーバーのデータがキャッシュ・ポリシーに基づいてリフレッシュされる場合に、ドメイン(複数のサーバー・インスタンスが複数のマシンに分散されている)内で実行されているアプリケーションで、セキュリティ・データの変更を伝播する必要があります。どこで実行されているかにかかわらず、アプリケーションのすべてのコンポーネントで変更を反映する必要があります。このユースケースを実現するには、OPSS MBeanまたはOPSS APIを使用してセキュリティ・データを変更します。

関連項目:

第9.1.1項「複数のサーバーがある環境」

付録Eの項「MBeanを使用したサービスの構成」

16.2.8 統合

製品で、複数のWebLogic Serverドメインを実行する必要があり、これらのドメインは単一の中央セキュリティ・ストアを共有する必要があります。このユースケースを実現するには、他のドメイン内のストアに結合するためのreassociateSecurityStoreコマンドと、複数のドメインが1つの集中管理されたセキュリティ・ストアを共有するためのOPSSのサポートを使用します。

セキュリティ・ストアへの結合がサポートされるのは、新しいドメインを作成する場合のみです。

関連項目:

第10.4.1項「reassociateSecurityStore」

第11.2項「資格証明の暗号化」

16.3 OPSSトラスト・サービス

OPSSトラスト・サービスでは、アイデンティティ・アサータを使用してトークンの提供および検証が行われるため、アプリケーションではHTTP対応のアプリケーション間でアイデンティティを伝播できます。

関連項目:

第F.2.6項「トラスト・サービスのプロパティ」

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のupdateTrustServiceConfigに関する項

16.4 HTTPを介したアイデンティティの伝播

注意:
アイデンティティ伝播を実装するには、「OPSSトラスト・サービスを使用したアイデンティティの伝播」の説明に従って、OPSSトラスト・サービスを使用することをお薦めします。

図16-2に、HTTPを使用したアイデンティティ伝播の典型的なフローを示します。

1. Domain1のクライアント・アプリケーションが、認証されたユーザーについて、Domain1のOPSSトラスト・インスタンスからのトークンをリクエストします。

2. サービスがDomain1のキーストアにアクセスし、クライアント・アプリケーション用にトークンを生成します。

3. クライアント・アプリケーションがトークンをHTMLヘッダー内にエンコードし、HTTPリクエストをDomain2のJavaサーブレットにディスパッチします。Domain 2のアサーション・プロバイダがリクエストをインターセプトし、トークンを抽出します。

4. アサータがDomain2のOPSSトラスト・インスタンスからのそのトークンの検証をリクエストします。

5. サービスがトークンを検証するためにDomain2のキーストアにアクセスし、レスポンスを返します。

6. 検証が成功したとみなし、アサータはアサートされたアイデンティティを使用してリクエストをJavaサーブレットに送信します。

7. Javaサーブレットが、クライアント・アプリケーションのリクエストに対するHTTPレスポンスを送信します。

図16-2 HTTPを介したアイデンティティ伝播

すぐに使用できる構成では、鍵の別名はサーバー名に基づいて設定されています。

16.5 OPSSトラスト・サービスを使用したアイデンティティの伝播

複数のドメイン間または単一ドメイン内の複数のコンテナ間でアイデンティティを伝播するには、次の各項で説明しているように、OPSSトラスト・サービスを使用することをお薦めします。

- 複数のWebLogic Serverドメイン間でのアイデンティティの伝播

- 単一のWebLogic Serverドメイン内のコンテナ間でのアイデンティティの伝播

- トラスト・プロバイダのプロパティ

16.5.1 複数のWebLogic Serverドメイン間でのアイデンティティの伝播

このユースケースでは、2つの異なるWebLogic ServerドメインDomain1とDomain2があります。クライアント・アプリケーションはDomain1で、JavaサーブレットはDomain2で実行されています。クライアント・アプリケーションではトークンの生成にDomain1のサービスを使用し、Javaサーブレットではトークンの検証にDomain2のサービスを使用します。

次の各項では、このユースケースを実現するための例と構成を示します。

- クライアント側ドメインでのトークン生成

- サーバー側つまりトークン検証ドメイン

16.5.1.1 クライアント側ドメインでのトークン生成

トークンが生成されるクライアント側(Domain1)で、次の作業を実行します。

- クライアント・アプリケーションの開発

- トラストストアの構成

- TrustServiceAccessPermission権限の追加

- プロバイダの構成

16.5.1.1.1 クライアント・アプリケーションの開発

クライアント・アプリケーションは、Java SEアプリケーションまたはJava EEアプリケーションです。次の例は、クライアント・アプリケーションを示しています。

// Authentication type name
public static final String AUTH_TYPE_NAME = "OIT";
// The authenticated username
String user = "weblogic";
// URL of the target application
URL url = "http://<host>:<port>/<destinationApp>";
//-----------------------------------------
JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext jpsCtx = ctxFactory.getContext();
final TrustService trustService = jpsCtx.getServiceInstance(TrustService.class);
final TokenManager tokenMgr = trustService.getTokenManager();
final TokenContext ctx = tokenMgr.createTokenContext(
TokenConfiguration.PROTOCOL_EMBEDDED);
UsernameToken ut = WSSTokenUtils.createUsernameToken("wsuid", user);
GenericToken gtok = new GenericToken(ut);
ctx.setSecurityToken(gtok);
ctx.setTokenType(SAML2URI.ns_saml);
Map<String, Object> ctxProperties = ctx.getOtherProperties();
ctxProperties.put(TokenConstants.CONFIRMATION_METHOD,
SAML2URI.confirmation_method_bearer);

AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
try {
tokenMgr.issueToken(ctx);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
});

Token token = ctx.getSecurityToken();
String b64Tok = TokenUtil.encodeToken(token);

HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setDoOutput(true);
connection.setReadTimeout(10000);
connection.setRequestProperty("Authorization", AUTH_TYPE_NAME + " " + b64Tok);
connection.connect();
BufferedReader rd = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
StringBuilder sb = new StringBuilder();

String line = null;
while ((line = rd.readLine()) != null) {
sb.append(line);
}
connection.disconnect();
System.out.println(sb.toString());

16.5.1.1.2 トラストストアの構成

トラストストアは、クライアント証明書および秘密鍵を使用してプロビジョニングする必要があります。証明書は、キーストアからエクスポートされ、トラストストアにインポートされます。キーストアとトラストストアはいずれも、クライアント・ドメイン内でキーストア・サービス(KSS)キーストアによって管理されます。

注意:
trust.keystoreTypeプロパティをKSSに設定する際に、キーストアまたはトラストストアのパスワードを使用しないことをお薦めします。この場合、デフォルトでは、キーストアおよびトラストストアはコードソース・パーミッションで保護されるため、パスワード保護を必要としません。

次のスクリプトに、これらのタスクが示されています。

# Update following values with correct value
user = "<username>"
password = "<password>"
wlsurl = "t3(s)://<host>:<port>"
stripeName = "<stripeNmae>"

#-----------------------------------------------
ksName = "<trustservice_ks>"
tsName = "<trustservice_ts>"
aliasName = "<trustservice>"
issuerDN = "cn=" + aliasName

print "Stripe Name: " + stripeName

print "KeyStore Name: " + ksName
print "TrustStore Name: " + tsName
print "Alias Name: " + aliasName
print "Issuer DN: " + issuerDN

#-----------------------------------------------
connect(user, password, wlsurl)

svc = getOpssService(name='KeyStoreService')
svc.listKeyStores(appStripe=stripeName)

svc.createKeyStore(appStripe=stripeName, name=ksName, password="", permission=true)
svc.generateKeyPair(appStripe=stripeName, name=ksName, password="", dn=issuerDN, keysize="1024", alias=aliasName, keypassword="", algorithm="RSA")
svc.exportKeyStoreCertificate(appStripe=stripeName, name=ksName, password="", alias=aliasName, keypassword="", type="Certificate", filepath="./trustservice.cer")

svc.createKeyStore(appStripe=stripeName, name=tsName, password="", permission=true)
svc.importKeyStoreCertificate(appStripe=stripeName, name=tsName, password="", alias=aliasName, keypassword="", type="TrustedCertificate", filepath="./trustservice.cer")

svc.listKeyStores(appStripe=stripeName)
svc.listKeyStoreAliases(appStripe=stripeName, name=ksName, password="", type="Certificate")
exit()

16.5.1.1.3 TrustServiceAccessPermission権限の追加

次の権限(アプリケーションのjazn-data.xmlファイル)は、トラスト・メソッドの使用をクライアントに許可するコードソース・パーミッションを示しています。

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.trust.TrustServiceAccessPermission</class>
<name>appId=*</name>
<actions>issue</actions>
</permission>
</permissions>
</grant>

この権限は、grantPermission WLSTコマンドを使用してセキュリティ・ストアに追加するか、アプリケーションがJava EEアプリケーションであり、jazn-data.xmlファイルがアプリケーションとともにパックされる場合は、アプリケーションのデプロイ時にセキュリティ・ストアに移行されます。

関連項目:

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のgrantPermissionに関する項

第23.3項「フィルタおよびインターセプタの構成」

16.5.1.1.4 プロバイダの構成

次の例は、トラスト・プロバイダのプロパティを示しています。

<propertySet name="trust.provider.embedded">
<property name="trust.keystoreType" value="KSS"/>
<property name="trust.keyStoreName" value="kss://<stripeName>/<keystoreName>"/>
<property name="trust.trustStoreName" value="kss://<stripeName>/<truststoreName>"/>
<property name="trust.aliasName" value="<aliasName>"/>
<property name="trust.issuerName" value="<issuerName>"/>
<property name="trust.provider.className" value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.token.includeCertificate" value="false"/>
</propertySet>

16.5.1.2 サーバー側つまりトークン検証ドメイン

トークンが検証されるサーバー側(Domain2)で、次の作業を実行します。

- サーバー・アプリケーションの開発

- web.xmlの構成

- アサータの構成

- キーストアのプロビジョニング

- パーミッションの追加

- プロバイダの構成

16.5.1.2.1 サーバー・アプリケーションの開発

まず、Javaサーブレット・コードで、アサートされたユーザーを取得します。

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String username = request.getRemoteUser();
ServletOutputStream out = response.getOutputStream();
out.print("Asserted username: " + username);
out.close();
}

16.5.1.2.2 web.xmlの構成

web.xmlファイルで、ログイン構成メソッドをCLIENT-CERTに設定します。

<web-app id="WebApp_ID"
…
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Identity Assertion </realm-name>
</login-config>
…
</web-app>

16.5.1.2.3 アサータの構成

次のいずれかの方法でアサータを構成します。

- Oracle WebLogic Server管理コンソールにログインし、「セキュリティ・レルム」→「プロバイダ」タブ→「認証」の順に移動し、「TrustServiceIdentityAsserter」を選択します。
このアサータは、トラスト・メソッドをコールして着信リクエストからのトークンをデコードして検証し、ユーザー名をWebLogic Serverに渡してアサートされたサブジェクトを確立します。

- 次のようなスクリプトを使用します。

connect("<username>","<password>","t3://<host>:<port>")
edit()
startEdit()
realm = cmo.getSecurityConfiguration().getDefaultRealm()
tsia = realm.lookupAuthenticationProvider("TSIA")
if tsia != None:
realm.destroyAuthenticationProvider(tsia)
tsia = realm.createAuthenticationProvider("TSIA", "oracle.security.jps.wls.providers.trust.TrustServiceIdentityAsserter")
save()
activate()
disconnect()

16.5.1.2.4 キーストアのプロビジョニング

次の例に示すように、Domain1のキーストアでプロビジョニングしたクライアント証明書をエクスポートし、Domain2のトラストストアにインポートします。

注意:
キーストアの証明書は、クライアント名と一致する別名でインポートします。複数のドメインの場合は、クライアント側でトークンの生成時に設定されたissuerNameが、サーバー側で証明書の名前を検索するための別名として使用されます。

# Update following values with correct value
user = "<username>"
password = "<password>"
wlsurl = "t3(s)://<host>:<port>"
stripeName = "<stripeName>"
ksName = "<trustservice_ks>"
tsName = "<trustservice_ts>"
aliasName = "<trustservice>"
print "Importing certificate for : " + aliasName
print "Stripe Name: " + stripeName
print "TrustStore Name: " + tsName
print "Alias Name: " + aliasName
connect(user, password, wlsurl)
svc = getOpssService(name='KeyStoreService')
svc.listKeyStores(appStripe=stripeName)

# switch Trust service to using FKS
svc.createKeyStore(appStripe=stripeName, name=tsName, password="", permission=true)
svc.importKeyStoreCertificate(appStripe=stripeName, name=tsName, password="", alias=aliasName, keypassword="", type="TrustedCertificate", filepath="./trustservice.cer")
svc.listKeyStoreAliases(appStripe=stripeName, name=tsName, password="", type="TrustedCertificate")
exit()

16.5.1.2.5 パーミッションの追加

grantPermission WLSTコマンドを使用して、アプリケーションのjazn-data.xmlファイルにコードソースの権限付与を追加します。

たとえば、次のコードソースの権限付与は、MyAppアプリケーションでトラスト・メソッドを使用するのに必要です。

<grant>
<grantee
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.trust.TrustServiceAccessPermission</class>
<name>appId=*</name>
<actions>validate</actions>
</permission>
</permissions>
</grant>

関連項目:

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のgrantPermissionに関する項

16.5.1.2.6 プロバイダの構成

次の例は、トラスト・プロバイダのプロパティを示しています。

<propertySet name="trust.provider.embedded">
<property name="trust.keystoreType" value="KSS"/>
<property name="trust.keyStoreName" value="kss://<stripeName>/<keystoreName>"/>
<property name="trust.trustStoreName" value="kss://<stripeName>/<truststoreName>"/>
<property name="trust.aliasName" value="<aliasName>"/>
<property name="trust.issuerName" value="<issuerName>"/>
<property name="trust.provider.className" value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.token.includeCertificate" value="false"/>
</propertySet>

プロバイダがトークンの検証にのみ使用される場合、aliasName属性とissuerName属性は、トークンの検証には使用されないため、オプション属性です。この場合、トークンを検証するために、プロバイダではトークンに含まれている名前を使用して証明書を探します。

16.5.2 単一のWebLogic Serverドメイン内のコンテナ間でのアイデンティティの伝播

このユースケースでは、クライアント・アプリケーションとサーバー・アプリケーションは同じドメインで稼働し、どちらのアプリケーションも同じキーストアを使用できるため、(その他のキーストアに)クライアント証明書をインポートする必要はありません。その他の情報はすべて、複数ドメインのシナリオで説明された内容と同じです。

16.5.3 トラスト・プロバイダのプロパティ

トラスト・プロバイダを構成するには、次のプロパティを使用します。

- trust.keyStoreType

- trust.keyStoreName

- trust.trustStoreName

- trust.aliasName

- trust.issuerName

- trust.provider.className

- trust.clockSkew

- trust.token.validityPeriod

- trust.token.includeCertificate

次の例は、トラスト・プロバイダ構成の例を示しています。

<propertySet name="trust.provider.embedded">
<property name="trust.keystoreType" value="KSS"/>
<property name="trust.keyStoreName" value="kss://<stripeName>/<keystoreName>"/>
<property name="trust.trustStoreName" value="kss://<stripeName>/<truststoreName>"/>
<property name="trust.aliasName" value="<aliasName>"/>
<property name="trust.issuerName" value="<aliasName>"/>
<property name="trust.provider.className"       value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.token.includeCertificate" value="false"/>
</propertySet>

トラスト・プロバイダのプロパティを変更するには、updateTrustServiceConfig WLSTコマンドを使用します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のupdateTrustServiceConfifに関する項を参照してください。

16.6 カスタム・グラフィカル・ユーザー・インタフェースの実装

この項では、ポリシーを管理するためにカスタム・グラフィカルUIを実装する場合などに必要な操作の一部を示します。各例では、OPSS APIを使用し、次の方法に関するデモを示します。

- アイデンティティ・ストアへのユーザーのキューイング。

- セキュリティ・ストアへのアプリケーション・ロールのキューイング。

- ユーザーおよびグループからアプリケーション・ロールへのマッピングのキューイング。具体的には、ユーザーが自分にマップされているすべてのアプリケーション・ロールを特定する場合です(ユーザーおよびグループからアプリケーション・ロールへのマッピングは多対多の関係です)。

- ユーザーおよびグループからアプリケーション・ロールへのマッピングの作成、読取り、更新および削除。

このユースケースは次のことを前提としています:

- アイデンティティ・ストアは、LDAPストアです。

- セキュリティ・ストアは、LDAPストアです。

- アイデンティティ・ストアには、次のユーザーおよびグループの階層があります。

- ユーザー: Mary、John、TomおよびHelen。

- グループ: IT、TrainingおよびDevelopment。

- グループITのメンバー: グループTrainingおよびDevelopment。

- グループTrainingのメンバー: ユーザーMary。

- グループDevelopmentのメンバー: ユーザーTomおよびJohn。

- セキュリティ・ストアには、次のアプリケーション・ポリシーおよびアプリケーション・ロールの階層があります。

- アプリケーション・ポリシー: ApplicationPolicy1およびApplicationPolicy2。

- ポリシーApplicationPolicy1で参照されるアプリケーション・ロール: ロールSystem Manager、System DeveloperおよびSystem Analyst。ロールSystem Managerは、ロールSystem Developerのメンバーです。ロールSystem Developerは、ロールSystem Analystのメンバーです。

- ポリシーApplicationPolicy2で参照されるアプリケーション・ロール: ロールDirector、InstructorおよびLecturer。ロールDirectorは、ロールInstructorのメンバーです。ロールInstructorは、ロールLecturerのメンバーです。

- アプリケーション・ロールは、次のようにユーザーおよびグループにマップされています。

- ロールSystem ManagerはユーザーHelenにマップされています。

- ロールSystem DeveloperはグループDevelopmentにマップされています。

- ロールDirectorはユーザーTomにマップされています。

- ロールInstructorはグループTrainingおよびDevelopmentにマップされています。

図16-3に、アプリケーション・ロール、ユーザーおよびグループのこの階層と、アプリケーション・ロールからユーザーおよびグループへのマッピングを示します。

図16-3 アプリケーション・ロールからユーザーとグループへのマッピング

このロール階層は、ロールSystem ManagerのユーザーはロールSystem Developerにも含まれ、他のロールについても同様であることを意味します。4人のユーザーそれぞれのロール・メンバーシップをまとめると、次のとおりです。

- ユーザーTomは、アプリケーション・ロールSystem Developer、System Analyst、Director、InstructorおよびLecturerのメンバーです。

- ユーザーHelenは、アプリケーション・ロールSystem Manager、System DeveloperおよびSystem Analystのメンバーです。

- ユーザーMaryは、アプリケーション・ロールInstructorおよびLecturerのメンバーです。

- ユーザーJohnは、アプリケーション・ロールSystem Developer、System Analyst、InstructorおよびLecturerのメンバーです。

例の詳細は、次の各項を参照してください。

- 前提とするインポート

- アイデンティティ・ストアの問合せの例

- ロールの作成の例

- ロールの問合せの例

- ロールのマッピングの例

- ユーザーが含まれるロールの取得の例

- ロール・マッピングの削除の例

16.6.1 前提とするインポート

各例では、次のimport文を前提としています。

import java.security.AccessController;
import java.security.Policy;
import java.security.Principal;
import java.security.PrivilegedExceptionAction;
import java.security.Security;
import java.util.HashSet;
import java.util.List;
import java.util.Set;
import javax.security.auth.Subject;
import oracle.security.idm.Identity;
import oracle.security.idm.IdentityStore;
import oracle.security.idm.ObjectNotFoundException;
import oracle.security.idm.Role;
import oracle.security.idm.RoleManager;
import oracle.security.idm.SearchParameters;
import oracle.security.idm.SearchResponse;
import oracle.security.idm.SimpleSearchFilter;
import oracle.security.idm.User;
import oracle.security.idm.UserProfile;
import oracle.security.jps.ContextFactory;
import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.principals.JpsApplicationRole;
import oracle.security.jps.service.idstore.IdentityStoreService;
import oracle.security.jps.service.policystore.ApplicationPolicy;
import oracle.security.jps.service.policystore.PolicyObjectNotFoundException;
import oracle.security.jps.service.policystore.PolicyStore;
import oracle.security.jps.service.policystore.PolicyStoreException;
import oracle.security.jps.service.policystore.entitymanager.AppRoleManager;
import oracle.security.jps.service.policystore.info.AppRoleEntry;
import oracle.security.jps.service.policystore.search.AppRoleSearchQuery;
import oracle.security.jps.service.policystore.search.ComparatorType;
import oracle.security.jps.util.JpsAuth;
import weblogic.security.principal.PrincipalFactory;

16.6.2 アイデンティティ・ストアの問合せの例

次の例は、アイデンティティ・ストア内のユーザーに対する2つの問合せを示しています。

private void queryUsers() throws Exception {
// Using IDM U/R to query ID store
IdentityStore idmStore = idStore.getIdmStore();

// Query an individual user by name
User employee = idmStore.searchUser(USER_TOM);
log("----------------------------------------------------------");
log("### Query individual user (Tom) from ID store ###");
log(USER_TOM + ": " + employee.getName() + " GUID: " +
employee.getGUID());
log();

// Get all users whose name is not "Paul"
SimpleSearchFilter filter =
idmStore.getSimpleSearchFilter(UserProfile.NAME,
SimpleSearchFilter.TYPE_NOTEQUAL,
"Paul");
SearchParameters sps =
new SearchParameters(filter, SearchParameters.SEARCH_USERS_ONLY);
SearchResponse result = idmStore.searchUsers(sps);
log("----------------------------------------------------------");
log("### Query all users (whose name is not Paul) from ID store ###");
log("Found the following users:");
while (result.hasNext()) {
Identity user = result.next();
log("\t user: " + user.getName() + ", GUID: " + user.getGUID());
}
log();
}

16.6.3 ロールの作成の例

次の例は、アプリケーション・ロールを作成する方法と、ロールを別のロールのメンバーにする方法を示しています。

private void createAppRoles1() throws Exception {
AppRoleManager arm1 = ap1.getAppRoleManager();
log("----------------------------------------------------------");
log("### Creating app roles in app policy1 with hierachy ###");

AppRoleEntry sysAnalystRole =
arm1.createAppRole(APP_ROLE_SYS_ANALYST, APP_ROLE_SYS_ANALYST,
APP_ROLE_SYS_ANALYST);
AppRoleEntry sysDeveloperRole =
arm1.createAppRole(APP_ROLE_SYS_DEVELOPER, APP_ROLE_SYS_DEVELOPER,
APP_ROLE_SYS_DEVELOPER);
AppRoleEntry sysManagerRole =
arm1.createAppRole(APP_ROLE_SYS_MANAGER, APP_ROLE_SYS_MANAGER,
APP_ROLE_SYS_MANAGER);

ap1.addPrincipalToAppRole(sysManagerRole, APP_ROLE_SYS_DEVELOPER);
ap1.addPrincipalToAppRole(sysDeveloperRole, APP_ROLE_SYS_ANALYST);
log("### App roles in app policy #1 have been created ###");
log();
}

16.6.4 ロールの問合せの例

次の例は、アプリケーション・ロールを問い合せる方法をいくつか示しています。

private void queryAppRolesInApplicationPolicy1() throws Exception {
AppRoleManager arm1 = ap1.getAppRoleManager();

// Get role that matches a name
AppRoleEntry are = arm1.getAppRole(APP_ROLE_SYS_MANAGER);
log("----------------------------------------------------------");
log("### Query app roles in application policy #1, by name ###");
log("Found " + are.getName() + " by app role name.");
log();

// Get the role that matches a name exactly
AppRoleSearchQuery q =
new AppRoleSearchQuery(AppRoleSearchQuery.SEARCH_PROPERTY.NAME,
false, ComparatorType.EQUALITY,
APP_ROLE_SYS_ANALYST,
AppRoleSearchQuery.MATCHER.EXACT);
List<AppRoleEntry> arel = arm1.getAppRoles(q);
log("### Query app roles in application policy #1, by exact query ###");
log("Found " + arel.get(0).getName() + " by exact query.");
log();

// Get roles with names that begin with a given string
q =
new AppRoleSearchQuery(AppRoleSearchQuery.SEARCH_PROPERTY.NAME, false,
ComparatorType.EQUALITY,
APP_ROLE_SYS_DEVELOPER.subSequence(0, 7),
AppRoleSearchQuery.MATCHER.BEGINS_WITH);
arel = arm1.getAppRoles(q);
log("### Query app roles in app policy #1, by begins_with query ###");
log("Found " + arel.get(0).getName() + " by begins_with query.");
log();

// Get roles with names that contain a given substring
q =
new AppRoleSearchQuery(AppRoleSearchQuery.SEARCH_PROPERTY.NAME, false,
ComparatorType.EQUALITY, "dummy",
AppRoleSearchQuery.MATCHER.ANY);
arel = arm1.getAppRoles(q);
log("### Query app roles in app policy #1, by matcher any ###");
log("Found " + arel.size() + " app roles by matcher any.");
for (AppRoleEntry ar : arel) {
log("\t" + ar.getName());
}
log();
}

16.6.5 ロールのマッピングの例

次の例は、アプリケーション・ロールをユーザーおよびグループにマップする方法を示しています。

private void assignAppRoleToUsersAndGroups() throws Exception {
// Obtain the user/group principals
IdentityStore idmStore = idStore.getIdmStore();
User tom = idmStore.searchUser(USER_TOM);
User helen = idmStore.searchUser(USER_HELEN);

Role trainingRole =
idmStore.searchRole(IdentityStore.SEARCH_BY_NAME, GROUP_TRAINING);
Role devRole =
idmStore.searchRole(IdentityStore.SEARCH_BY_NAME, GROUP_DEV);

Principal tomPrincipal =
PrincipalFactory.getInstance().createWLSUser(tom.getName(),
tom.getGUID(),
tom.getUniqueName());
Principal helenPrincipal =
PrincipalFactory.getInstance().createWLSUser(helen.getName(),
helen.getGUID(),
helen.getUniqueName());
Principal trainingPrincipal =
PrincipalFactory.getInstance().createWLSGroup(trainingRole.getName(),
trainingRole.getGUID(),
trainingRole.getUniqueName());
Principal devPrincipal =
PrincipalFactory.getInstance().createWLSGroup(devRole.getName(),
devRole.getGUID(),
devRole.getUniqueName());

// Application policy #1
log("----------------------------------------------------------");
log("### Assigning appl roles to users and groups, app policy #1 ###");
ap1.addPrincipalToAppRole(helenPrincipal, APP_ROLE_SYS_MANAGER);
ap1.addPrincipalToAppRole(devPrincipal, APP_ROLE_SYS_DEVELOPER);

// Application policy #2
log("### Assigning app roles to users and groups, app policy #2 ###");
ap2.addPrincipalToAppRole(tomPrincipal, APP_ROLE_DIRECTOR);
ap2.addPrincipalToAppRole(devPrincipal, APP_ROLE_INSTRUCTOR);
ap2.addPrincipalToAppRole(trainingPrincipal, APP_ROLE_INSTRUCTOR);

log("### App roles have been assigned to users and groups ###");
log();
}

16.6.6 ユーザーが含まれるロールの取得の例

次の例は、特定のユーザーを含むロールをすべて取得する方法を示しています。

private void showAppRoles() throws Exception {
Subject tomSubject = getUserSubject(USER_TOM);
Subject helenSubject = getUserSubject(USER_HELEN);
Subject johnSubject = getUserSubject(USER_JOHN);
Subject marySubject = getUserSubject(USER_MARY);

Set<String> applications = new HashSet<String>();
applications.add(APPLICATION_NAME1);
applications.add(APPLICATION_NAME2);
log("----------------------------------------------------------");
log("### Query application roles for Tom ###");
showAppRoles(applications, USER_TOM, tomSubject);
log();
log("### Query application roles for Helen ###");
showAppRoles(applications, USER_HELEN, helenSubject);
log();
log("### Query application roles for John ###");
showAppRoles(applications, USER_JOHN, johnSubject);
log();
log("### Query application roles for Mary ###");
showAppRoles(applications, USER_MARY, marySubject);
log();
}
private Subject getUserSubject(String userName) throws Exception {
Subject subject = new Subject();

// Query users from ID store using user/role API,for user principal
IdentityStore idmStore = idStore.getIdmStore();
User user = idmStore.searchUser(userName);
Principal userPrincipal =
PrincipalFactory.getInstance().createWLSUser(user.getName(),
user.getGUID(),
user.getUniqueName());
subject.getPrincipals().add(userPrincipal);

// Query users from ID store using user/role API, for enterprise roles
RoleManager rm = idmStore.getRoleManager();
SearchResponse result = null;
try {
result = rm.getGrantedRoles(user.getPrincipal(), false);
} catch (ObjectNotFoundException onfe) {
// ignore
}

// Add group principals to the subject
while (result != null && result.hasNext()) {
Identity role = result.next();
Principal groupPrincipal =
PrincipalFactory.getInstance().createWLSGroup(role.getName(),
role.getGUID(),
role.getUniqueName());
subject.getPrincipals().add(groupPrincipal);
}

// The subject now contains both user and group principals.
return subject;
}

private void showAppRoles(Set<String> applications, String user, Subject subject) {
// Get all granted application roles for this subject
Set<JpsApplicationRole> result = null;
try {
result = JpsAuth.getAllGrantedAppRoles(subject, applications);
} catch (PolicyStoreException pse) {
log(pse.toString());
}
if (result.size() <= 1) {
log(user + " has " + result.size() + " application role.");
if (result.size() == 1) {
for (JpsApplicationRole ar : result) {
log("\tApplication role: " + ar.getName());
}
}
} else {
System.out.println(user + " has " + result.size() +
" application roles.");
for (JpsApplicationRole ar : result) {
log("\tApplication role: " + ar.getAppID() + "/" +
ar.getName());
}
}
}

16.6.7 ロール・マッピングの削除の例

次の例は、アプリケーション・ロールからグループへのマッピングを削除する方法を示しています。

private void removeAppRoleForUserDirector() throws Exception {
// Remove instructor role from Dev group
log("----------------------------------------------------------");
log("### Removing Instructor application role from Dev group ###");

IdentityStore idmStore = idStore.getIdmStore();
Role devRole =
idmStore.searchRole(IdentityStore.SEARCH_BY_NAME, GROUP_DEV);
Principal devPrincipal =
PrincipalFactory.getInstance().createWLSGroup(devRole.getName(),
devRole.getGUID(),
devRole.getUniqueName());
ap2.removePrincipalFromAppRole(devPrincipal, APP_ROLE_INSTRUCTOR);
log("### Instructor app role has been removed from Dev group ###");
log();

log("----------------------------------------------------------");
log("### Now query application roles for user John, again ###");
Set<String> applications = new HashSet<String>();
applications.add(APPLICATION_NAME1);
applications.add(APPLICATION_NAME2);
Subject johnSubject = getUserSubject(USER_JOHN);
showAppRoles(applications, USER_JOHN, johnSubject);
log();
}

16.7 Oracle ADFアプリケーションの保護

次の各項では、Oracle JDeveloper (JDeveloper)を使用して開発したOracle ADFアプリケーションで実行される一般的なタスクについて説明します。

- 開発フェーズ

- デプロイメント・フェーズ

- 管理フェーズ

関係する担当者は、アプリケーション製品マネージャ、開発者およびセキュリティ管理者です。

関連項目:

「各フェーズの担当者別タスクの概要」

16.7.1 開発フェーズ

開発フェーズでは、開発者によってOracle Fusion Middlewareで使用可能な広範なセキュリティ・オプション機能がアプリケーションと連携するように設計されます。開発者は、JDeveloper、組込みのOracle ADFフレームワークおよびOracle WebLogic Server(これらすべてにより、アプリケーションの存続期間全体にわたってセキュリティへの一貫したアプローチが保証されます)で公開される豊富な一連のセキュリティ・サービスを利用できます。

ADFセキュリティ・ウィザード(認可エディタ)および式言語エディタを使用しますが、いずれもJDeveloper内にあります。さらに、必要に応じて、OPSS APIを使用してより複雑なセキュリティ・タスクを実行することもできます。このように、アプリケーションのある部分では宣言によるセキュリティを使用し、別の部分ではプログラムによるセキュリティを使用しますが、いずれも開発環境および実行時環境で使用可能なセキュリティ機能に基づいています。

また、アプリケーションの保護に必要なアプリケーション権限およびロールを多数定義しますが、このデータはアプリケーションのソース・コードとともにソース制御システムに格納されます。

16.7.2 デプロイメント・フェーズ

アプリケーションを開発したら、本番環境にデプロイする前にステージング環境でテストします。本番環境では、アプリケーションとランタイム・サービスは、シングル・サインオン、ユーザー・プロビジョニング、監査などの他のセキュリティ・コンポーネントと統合されます。

通常、セキュリティ・サービスのタイプはフェーズとともに変化します。たとえば、開発時は資格証明をファイルまたはOracleウォレットに格納しますが、本番環境ではLDAPサーバーに格納します。

デプロイメント・フェーズでは、ポリシーを本番のセキュリティ・ストアに移行し、アプリケーション・ポリシーに応じてアプリケーション・ロールをエンタープライズ・グループにマップします。

16.7.3 管理フェーズ

管理フェーズは、アプリケーションを本番環境にデプロイした後に始まります。このフェーズでは、アプリケーション・リソースへのアクセス権のユーザーへの付与、監査ログの確認、セキュリティ・インシデントへの対応、セキュリティ・パッチの適用など、日常的なセキュリティ・タスクを管理します。

16.7.4 各フェーズの担当者別タスクの概要

次の各表はセキュリティ・ライフ・サイクルのフェーズごとに、担当者別に主要な担当任務をまとめたものです。図16-4は、基本的なフローを示します。

図16-4 アプリケーション・ライフ・サイクルのフェーズ

表16-1 アプリケーション設計者のセキュリティ・タスク

フェーズ

タスク

開発

機能のセキュリティ要件およびデータのセキュリティ要件に基づいてアプリケーション・ロールをおおまかに定義します。初期のセキュリティ・ストアにデータを移入します。

デプロイメント

QA (品質保証)チームのテストに使用する実際のカスタマ・シナリオを定義します。

管理

アプリケーション・ポリシーのカスタマイズ要件を理解し、特定します。垂直産業向けのテンプレートの定義を検討します。

表16-2 アプリケーション開発者のセキュリティ・タスク

フェーズ

タスク

開発

ツールおよびプロセス(特にJDeveloper)を使用して、アプリケーションを構築し、アプリケーション・ロールやパーミッションなどのセキュリティ・データを作成します。

権限付与を使用して、データレベルのセキュリティを指定します。

ローカル・セキュリティ・ストアをユーザーおよびロールとともに使用してアプリケーションをテストします。

デプロイメント

QAチームによる実行時の問題のトラブルシューティングおよび解決を支援します。

表16-3 アプリケーション・セキュリティ管理者のセキュリティ・タスク

フェーズ

タスク

デプロイメント

デプロイメント・サービスを使用して、jazn-data.xmlのデータを本番のセキュリティ・ストアに移行します。

セキュリティ・ポリシーを施行できるように、アプリケーション・ロールをエンタープライズ・グループにマップします。

管理

必要に応じて、ソフトウェアにパッチおよびアップグレードを適用します。

エンタープライズ・ユーザーおよびアプリケーション・ロールの階層は時間とともに変化するため、それに応じてユーザーとロールを管理します。

アプリケーションとともにパックされたポリシーを管理し、新しいポリシーを作成します。

アイデンティティ・インフラストラクチャとの統合および管理を行います。

16.8 コードおよび構成例

次の各項では、このガイドの他の章に記載されているコードおよび構成の例を示します。

- プログラミング例

- 構成例

16.8.1 プログラミング例

次の各項では、一般的なセキュリティ関連のプログラミング・タスクの例が記載されています。

- 第8.4項「プログラムによるアイデンティティ・ストアの問合せ」

- カスタム・グラフィカル・ユーザー・インタフェースの実装

- 第17.2.1.2項「プログラムによる認可」

- 17.3.2項「ポリシーの管理」

- 第17.3.3項「プログラムによるポリシーのチェック」

- 第17.3.4項「クラスResourcePermission」

- 第24.3.2.3.1項「認証のためのアイデンティティ・ストア・ログイン・モジュールの使用」

- 第24.3.2.3.2項「アサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用」

16.8.2 構成例

次の各項では、一般的なセキュリティ関連の構成タスクの例が記載されています。

- 第17.3.4項「クラスResourcePermission」

- 第23.3項「フィルタおよびインターセプタの構成」

- 第6.6.2.1項「migrateSecurityStoreを使用したポリシーの移行」

- 第6.6.2.2項「migrateSecurityStoreを使用した資格証明の移行」

- 第8.3.2.8項「単一および複数のLDAPの構成」

- 第24.3.1項 「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」

- 第24.4項「Java SEアプリケーションでの認可」

16.9 JKSを使用したアイデンティティの伝播

すぐに使用できる構成では、トークン名および鍵の別名はサーバー名に基づいて設定されています。これらのデフォルト値を変更するには、第16.9.1.8項「トラスト・パラメータの更新」で説明されている手順を使用します。

次の各項では、Javaキーストア(JKS)を使用してHTTPを介したアイデンティティの伝播について説明します。

- 単一ドメイン・シナリオ

- 複数ドメイン・シナリオ

- 両方のプロトコルを使用するドメイン

16.9.1 単一ドメイン・シナリオ

このシナリオでは、クライアントとJavaサーブレットはいずれも同じサービスを使用して、トークンを生成および検証します。次の各項では、クライアントおよびJavaサーブレットが同じドメイン内で実行されている場合のアイデンティティ伝播の実装に必要なタスクについて説明します。

- クライアント・アプリケーションの作成

- キーストアの構成

- マップおよびキーの構成

- 権限付与の構成

- Javaサーブレットの作成

- web.xmlの構成

- アサータの構成

- トラスト・パラメータの更新

16.9.1.1 クライアント・アプリケーションの作成

次の例は、クライアント・アプリケーションを示しています。jps-api.jarファイルおよびosdt_ws_sx.jar、osdt_core.jar、osdt_xmlsec.jar、osdt_saml2.jarの各ファイルは、クラスパスに含める必要があることに注意してください。

// Authentication type name
public static final String AUTH_TYPE_NAME = "OIT";
// The authenticated username
String user = "weblogic";
// URL of the target application
URL url = "http://<host>:<port>/<destinationApp>";
//-----------------------------------------
JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext jpsCtx = ctxFactory.getContext();
final TrustService trustService = jpsCtx.getServiceInstance(TrustService.class);
final TokenManager tokenMgr = trustService.getTokenManager();
final TokenContext ctx = tokenMgr.createTokenContext(
TokenConfiguration.PROTOCOL_EMBEDDED);
UsernameToken ut = WSSTokenUtils.createUsernameToken("wsuid", user);
GenericToken gtok = new GenericToken(ut);
ctx.setSecurityToken(gtok);
ctx.setTokenType(SAML2URI.ns_saml);
Map<String, Object> ctxProperties = ctx.getOtherProperties();
ctxProperties.put(TokenConstants.CONFIRMATION_METHOD,
SAML2URI.confirmation_method_bearer);

AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
try {
tokenMgr.issueToken(ctx);
} catch (Exception e) {
e.printStackTrace();
}
return null;
}
});

Token token = ctx.getSecurityToken();
String b64Tok = TokenUtil.encodeToken(token);

HttpURLConnection connection = (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setDoOutput(true);
connection.setReadTimeout(10000);
connection.setRequestProperty("Authorization", AUTH_TYPE_NAME + " " + b64Tok);
connection.connect();
BufferedReader rd = new BufferedReader(new InputStreamReader(
connection.getInputStream()));
StringBuilder sb = new StringBuilder();

String line = null;
while ((line = rd.readLine()) != null) {
sb.append(line);
}
connection.disconnect();
System.out.println(sb.toString());

16.9.1.2 キーストアの構成

サーバー名をjrfServer_adminとした場合、次のコマンドは、生成されたdefault-keystore.jksファイルによって表されるキーストアの作成を示しています。

JAVA_HOME/bin/keytool -genkeypair
-alias orakey
-keypass welcome
-keyalg RSA
-dname "CN=jrfServer_admin,O=Oracle,C=US"
-keystore default-keystore.jks
-storepass password

# the generated file must be placed on the domain configuration location
cp default-keystore.jks ${domain.home}/config/fmwconfig

jps-config.xmlファイル内で構成されているキーストア・サービスが、生成されたdefault-keystore.jksを指していることを確認します。

<!-- KeyStore Service Instance -->
<serviceInstance name="keystore"
provider="keystore.provider"  location="./default-keystore.jks">
<description>Default JPS Keystore Service</description>
<property name="keystore.provider.type" value="file"/>
<property name="keystore.file.path" value="./"/>
<property name="keystore.type" value="JKS"/>
<property name="keystore.csf.map" value="oracle.wsm.security"/>
<property name="keystore.pass.csf.key" value="keystore-csf-key"/>
<property name="keystore.sig.csf.key" value="sign-csf-key"/>
<property name="keystore.enc.csf.key" value="enc-csf-key"/>
</serviceInstance >

16.9.1.3 マップおよびキーの構成

キーストアを開くために使用するマップ/キー・ペアと、トークンを生成するために使用する別のマップ/キー・ペアを作成します。次のコマンドは、createCred WLSTコマンドを使用したこれらの操作を示しています。

// JKS keystore opening password
createCred(map="oracle.wsm.security", key="keystore-csf-key",
user="keystore", password="password")

// Private key password to issue tokens
createCred(map="oracle.wsm.security", key="sign-csf-key",
user="orakey", password="password")

createCredの詳細は、第11.4項「WLSTを使用した資格証明の管理」を参照してください。

16.9.1.4 権限付与の構成

トラスト・メソッドの使用をクライアント・アプリケーションに許可するコードソースの権限付与を含むシステム・ポリシーを追加します。

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.trust.TrustServiceAccessPermission</class>
<name>appId=*</name>
<actions>issue</actions>
</permission>
</permissions>
</grant>

権限付与を有効にするには、WebLogic Serverを停止して再起動する必要があります。

16.9.1.5 Javaサーブレットの作成

次の例は、Javaサーブレットがアサートされたユーザー名を取得する方法を示しています。

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
String username = request.getRemoteUser();
ServletOutputStream out = response.getOutputStream();
out.print("Asserted username: " + username);
out.close();
}

16.9.1.6 web.xmlの構成

web.xmlファイルで、適切なログイン・メソッドを設定します。

<web-app id="WebApp_ID"
…
<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>Identity Assertion</realm-name>
</login-config>
…
</web-app>

16.9.1.7 アサータの構成

アサータを構成するには、次の手順を実行します。

1. jps-wls-trustprovider.jarアイデンティティ・アサーション・ファイルを${domain.home}/lib/mbeantypesにコピーします。

cp ${common.components.home}/modules/oracle.jps_12.2.1/jps-wls-trustprovider.jar ${domain.home}/lib/mbeantypes

2. WebLogic Serverを再起動します。

3. WebLogic Server管理コンソールを使用してアサータを構成します。

1. 管理者としてログインし、「セキュリティ設定」→「セキュリティ・レルム」→「プロバイダ」→「認証」タブの順に移動し、「新規」をクリックします。「新規認証プロバイダの作成」ダイアログが表示されます。

2. このダイアログで、名前のテキスト・フィールドにTrustServiceIdentityAsserterと入力し、プルダウン・リストからTrustServiceIdentityAsserterを選択します。次に、「OK」をクリックします。

4. セキュリティ・ストアに次のような権限付与が存在することを確認します。この権限付与は、アサータでOPSSトラスト・メソッドを使用できるようにするために必要です。

<grant>
<grantee>
<codesource>
<url>file:${domain.home}/lib/mbeantypes/jps-wls-trustprovider.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.trust.TrustServiceAccessPermission</class>
<name>appId=*</name>
<actions>validate</actions>
</permission>
</permissions>
</grant>

jps-config.xmlファイルを変更した場合は、サーバーの再起動が必要です。

16.9.1.8 トラスト・パラメータの更新

この項では、スクリプトの実行によってjps-config.xmlファイルのトラスト・パラメータを変更する方法について説明します。

デフォルトでは、trust.aliasNameパラメータとtrust.issuerNameパラメータはサーバー名に設定されています。これらの値を変更するには、次のように変更したスクリプトを使用します。

import sys

wlsAdmin = 'weblogic'
wlsPwd ='password_value'
wlUrl='t3://localhost:7001'
issuer= 'issuer'
alias = 'alias'

print "OPSS Trust Service provider configuration management script.\n"

instance = 'trust.provider'
name = 'trust.provider.embedded'
cfgProps = HashMap()
cfgProps.put("trust.issuerName", issuer)
cfgProps.put("trust.aliasName", alias)
pm = PortableMap(cfgProps);

connect(wlsAdmin, wlsPwd, wlUrl)
domainRuntime()

params = [instance, name, pm.toCompositeData(None)]
sign = ["java.lang.String", "java.lang.String", "javax.management.openmbean.CompositeData"]
on = ObjectName("com.oracle.jps:type=JpsConfig")
mbs.invoke(on, "updateTrustServiceConfig", params, sign)
mbs.invoke(on, "persist", None, None)

print "Done.\n"

16.9.2 複数ドメイン・シナリオ

このシナリオでは、Domain1とDomain2という2つのドメインが存在します。クライアント・アプリケーションはDomain1で、JavaサーブレットはDomain2で実行されています。この2つのドメインそれぞれに、「単一ドメイン・シナリオ」の説明に従って適切に構成されたトラスト・サービスが1つあることを前提とします。クライアントではトークンの生成にDomain1のトラスト・サービスを使用し、Javaサーブレットではトークンの検証にDomain2のトラスト・サービスを使用します。

Domain1では、クライアントのコードと次の構成は、「単一ドメイン・シナリオ」で説明したものと同じです。

- クライアント・アプリケーションについては、「クライアント・アプリケーションの作成」を参照してください。

- キーストアの構成については、「キーストアの構成」を参照してください。

- 資格証明ストア・フレームワークの構成については、「マップおよびキーの構成」を参照してください。

- 権限付与の構成については、「権限付与の構成」を参照してください。

Domain2では、Javaサーブレットのコードとweb.xmlの構成は、「単一ドメイン・シナリオ」で説明したものと同じです。

- Javaサーブレットのコードについては、「Javaサーブレットの作成」を参照してください。

- web.xmlファイルの構成については、「web.xmlの構成」を参照してください。

- Domain1でトークンの署名に使用されたクライアント証明書はDomain2のキーストアに存在する必要があります。そのためには、次の手順を実行します。

1. 証明書をDomain 1のキーストアからエクスポートします。

JAVA_HOME/bin/keytool -export
-orakey orakey.cer
-keystore default-keystore.jks
-storepass password

2. その証明書をDomain 2のキーストアにインポートします。証明書のインポートに使用された別名はクライアント側の証明書の名前と一致する必要があります。

JAVA_HOME/bin/keytool -importcert
-alias orakey
-keypass welcome
-keyalg RSA
-keystore default-keystore.jks
-storepass password

3. createCred WLSTコマンドを使用して、Domain2のキーストア・パスワードを(Domain2の)資格証明ストアで設定します。

createCred(map="oracle.wsm.security", key="keystore-csf-key", user="keystore", password="password")

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のcreateCredに関する項を参照してください。

16.9.3 両方のプロトコルを使用するドメイン

このシナリオでは、アプリケーションではHTTPまたはSOAPのいずれかを使用し、ドメイン内のすべてのアプリケーションが同じプロトコルを使用するわけではありません。このようなシナリオでは、キーストアをHTTPサービスとSOAPサービスで共有できます。

次の各項では、この場合に必要となる特殊な構成について説明します。

- 単一ドメイン・シナリオ

- 複数ドメイン・シナリオ

16.9.3.1 単一ドメイン・シナリオ

このシナリオでは、キーストアは1つしかありません。次の例は、別名がorakeyの証明書に必要な構成を示しています。

<propertySet name="trust.provider.embedded">
<property name="trust.provider.className"
value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.token.includeCertificate" value="false"/>

<!-- The alias used to get the signing certificate from JKS -->
<property name="trust.aliasName" value="orakey"/>

<!-- The issuer name to add in the token used by the target
trust service instance as an alias to pick up the corresponding certificate
to validate the token signature -->
<property name="trust.issuerName" value="orakey"/>
</propertySet>

16.9.3.2 複数ドメイン・シナリオ

このシナリオでは、2つのドメインと2つのキーストアが存在します。次の例は、別名がorakeyの証明書に対するトークンを発行するドメインで必要な構成を示しています。

<!-- issuer domain truststore must have a signing certif. w. alias orakey -->
<propertySet name="trust.provider.embedded">
<property name="trust.provider.className"
value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.token.includeCertificate" value="false"/>

<!-- the signing certificate alias in local JKS -->
<property name="trust.aliasName" value="orakey"/>

<!-- the token issuer's name -->
<property name="trust.issuerName" value="domain1"/>
</propertySet>

クライアント側では、trust.issuerNameの値はtrust.aliasNameと同じ値にすることができます。ただし、名前の値は、(例で示しているように)trust.issuerNameに別の値を設定することで、オーバーライドできます。この名前は、クライアント側で生成されたトークンに設定されます。

サーバーがトークンの検証のみに使用される場合は、サーバー側でtrust.aliasNameおよびtrust.issuerNameの設定は必須ではありません。トークンの生成中に設定された名前が、サーバー側で証明書を検索する際に使用されます。このため、クライアントからインポートされた証明書は、クライアント側(例ではdomain1)の名前を別名としてサーバー側でエクスポートする必要があります。

次の例は、別名がorakeyの証明書に対するトークンを受け取るドメインで必要な構成を示しています。

<!- the recipient domain must have a token validation certificate
for domain1, which is the one was used to sign the token with alias "domain1" -->
<propertySet name="trust.provider.embedded">
<property name="trust.provider.className"
value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.token.includeCertificate" value="false"/>

<!-- the signing certificate alias in local JKS -->
<property name="trust.aliasName" value="orakey"/>

<!-- the token issuer's name -->
<property name="trust.issuerName" value="domain2"/>
</propertySet>

17 セキュリティ・モデル

この章では、OPSSの認可モデルおよびポリシー・モデルについて説明し、Java EEおよびJava Authorization and Authentication Services (JAAS)の認可モデルと比較します。

この章の内容は次のとおりです。

- OPSSの認可モデルおよびポリシー・モデルについて

- 認可モデル

- JAAS/OPSS認可モデル

17.1 OPSSの認可モデルおよびポリシー・モデルについて

OPSSの認可モデルおよびポリシー・モデルの詳細は、『Oracle Fusion Middleware Oracle Entitlements Server管理者ガイド』を参照してください。

17.2 認可モデル

ポリシーは、特定の場所からロードされたコードに付与されるパーミッションを指定します。JAASモデルは、オプションのプリンシパル・リストを指定できるようにすることで、ポリシーを拡張します。このようなポリシーにより、そのプリンシパルのいずれかによって実行される特定の場所からのコードにパーミッションが付与されます。

OPSSモデルはJAASモデルに基づいており、さらに、アプリケーションのポリシーおよびロールとシステム・ポリシーを使用できます。アプリケーション・ロールは、エンタープライズ・ユーザーおよびグループ(管理ロールなど)にマップできます。ポリシーでは、これらのロール、グループまたはユーザーにプリンシパルのいずれかにパーミッションを付与できます。

Java EEアプリケーションでは、そのアプリケーションが実行されているコンテナに認可を委任できる他、checkPermission、checkBulkAuthorization、getGrantedResourcesなどのメソッドへのコールによって独自の認可を実装できます。

次の各項では、Java EEおよびJAASの認可モデルの要点を説明します。

- Java EE認可モデル

- JAAS認可モデル

17.2.1 Java EE認可モデル

Java EE認可モデルではロール・メンバーシップを使用して、Enterprise JavaBeans (EJB)と、URLで参照されるWebリソースへのアクセスを制御します。ポリシーによってユーザーおよびロールにパーミッションが割り当てられ、コンテナによってポリシーが施行されます。

Java EEモデルでは、次のいずれかの方法で認可が実装されます。

- 宣言: ポリシーはデプロイメント・ディスクリプタに指定されます。コンテナは、デプロイメント・ディスクリプタからそれらのポリシーを読み取って施行します。認可を実施するための特別なアプリケーション・コードは必要ありません。

- プログラム: ポリシーはアプリケーション・コードで処理されます。コードにより、特定のコード・セクションの実行に適したパーミッションをサブジェクトが持っているかどうかチェックされます。サブジェクトに適切なパーミッションがない場合、コードは例外をスローします。

表17-1は、各方法の長所と短所を示しています。

表17-1 Java EEモデルの認可の比較

認可のタイプ

長所

短所

宣言

コーディングが不要です。デプロイメント・ディスクリプタのみを変更すればよいため、更新が簡単です。

認可はURLレベルまたはEJBメソッド・レベルで指定されます。

プログラム

アプリケーション・コードで指定されます。きめ細かい認可を提供します。

コード変更や再コンパイルを伴うため、更新が簡単ではありません。

コンテナでは、次の各項で説明しているように、その中で実行されているアプリケーションに対して、宣言とプログラムという2つの方法で認可を提供できます。

- 宣言による認可

- プログラムによる認可

- Java EEアプリケーションの例

17.2.1.1 宣言による認可

宣言による認可では、URLベースのリソース(Javaサーブレットやページなど)およびEJBのメソッドへのアクセスを制御できます。

宣言による認可を構成するには、次の手順を実行します。

1. 保護するリソースとそのリソースへのアクセス権を持つロールを(標準のデプロイメント・ディスクリプタで)指定します。あるいは、コード注釈を使用します。

2. ロールを(web.xmlファイルなどの固有のデプロイメント・ディスクリプタで)エンタープライズ・グループにマップします。

17.2.1.2 プログラムによる認可

プログラムによる認可では、宣言による方法ではできないきめ細かい認可を実現しますが、isUserInRoleメソッド(Javaサーブレットの場合)またはisCallerInRoleメソッド(EJBの場合)をアプリケーション・コードからコールする必要があります(どちらのメソッドも標準のJava APIから使用可能です)。

これらのメソッドは、認可の決定に関してロール・メンバーシップに引き続き依存していますが、アクセス制御がEJBにもURLにも限定されないため、よりきめ細かく認可の決定を制御できます。

17.2.1.3 Java EEアプリケーションの例

次の例は、isUserInRoleメソッドをコールするアプリケーションを示しています。この例では、アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにweb.xmlファイルとweblogic-application.xmlファイルが含まれており、これらのファイルには次のような指定が含まれていることを前提とします。

<!-- security roles in web.xml -->
<security-role>
<role-name>sr_developer</role-name>
</security-role>

<!-- maaping of user to role in weblogic.application.xml -->
<wls:security-role-assignment>
<wls:role-name>sr_developer</wls:role-name>
<wls:principal-name>weblogic</wls:principal-name>
</wls:security-role-assignment>

isUserInRoleをコールするコード

import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.util.Date;

public class PolicyServlet extends HttpServlet {
public PolicyServlet() {
super();
}
public void init(ServletConfig config)
throws ServletException {
super.init(config);
}
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
final ServletOutputStream out = response.getOutputStream();
response.setContentType("text/html");
out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
out.println("Time stamp: " + new Date().toString());
out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");
out.println("</BODY>");
out.println("</HTML>");
}
}

17.2.2 JAAS認可モデル

JAAS認可モデルではパーミッションを採用していますが、ロールも使用します。このモデルでは、ポリシーによって、パーミッションとサブジェクト(ロール、グループまたはユーザー)がバインドされ、さらに必要に応じてコードともバインドされます。addPrincipalsToAppRoleメソッドをコールして、ロールにパーミッションを付与します。パーミッションは静的メソッドAccessController.checkPermissionのコールによって評価されます。このモデルでは、リソースをきめ細かく制御できます。

ポリシーで、次のデータを指定します。

- パーミッションが許可されたアプリケーション・ロールおよびエンタープライズ・グループ。

- パーミッション(アプリケーション・ポリシー内)およびコードソース(システム・ポリシー内)。アプリケーション・ポリシーでは、アクセスを許可されるユーザーまたはグループのメンバーを定義します。システム・ポリシーでは、コードで実行できるアクションを定義します。

このモデルを使用してプログラミングする場合、アプリケーションの機密性の高い部分の前に、現在のユーザーまたはロールがコードに対して適切なパーミッションを持っているかどうかを判別するチェックを記述すると、ユーザーが適切なパーミッションを持っている場合にコードが実行されます。例については、第23.6.6項「サポートされているパーミッション・クラスの使用」を参照してください。

17.3 JAAS/OPSS認可モデル

JAASおよびOPSS認可では、クラスを環境にロードして実行するときに、そのクラスで実行できる操作を制御することが基本になっています。

次の各項では、OPSS認可モデルについて説明します。

- リソース・カタログ

- ポリシーの管理

- プログラムによるポリシーのチェック

- クラスResourcePermission

17.3.1 リソース・カタログ

OPSSでは、セキュリティ・ストアでのリソース・カタログの指定およびランタイム・サポートに対応しています。

リソース・カタログを使用すると、次の操作が可能になります。

- 判読可能な用語でのポリシーおよび保護アーティファクトの記述。

- アプリケーション・ソース・コードとは無関係なポリシーの定義および変更。

- ポリシー、ロールおよびロール階層の参照および検索。

- 権限でのパーミッションのグループ化。

17.3.2 ポリシーの管理

次のインタフェースはすべてoracle.security.jps.service.policystore.EntityManagerの下位インタフェースですが、これらを使用してリソース・カタログを管理します。

- GrantManager - このインタフェースは、検索基準を使用して権限付与を問い合せたり、リソース・カタログ・アーティファクトの様々な組合せに適合する権限付与のリストを取得したり、プリンシパルに対してパーミッションを付与または取り消す場合に使用します。

- PermissionSetManager - このインタフェースは、パーミッション権限の作成、変更および問合せを実行する場合に使用します。

- ResourceManager - このインタフェースは、リソース・インスタンスの作成、削除および変更を実行する場合に使用します。

- ResourceTypeManager - このインタフェースは、リソース・タイプの作成、削除、変更および問合せを実行する場合に使用します。

リソース・タイプ、リソース・インスタンス、アクションまたはパーミッション・セットを作成するには、次のようなコードを使用します。

import oracle.security.jps.service.policystore.entitymanager.*;
import oracle.security.jps.service.policystore.search.*;
import oracle.security.jps.service.policystore.info.resource.*;
import oracle.security.jps.service.policystore.info.*;
import oracle.security.jps.service.policystore.*;
import java.util.*;

public class example {
public static void main(String[] args) throws Exception {
ApplicationPolicy ap;

ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
query.setANDMatch();
query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
List<ResourceTypeEntry> allResourceTypes = rtm.getResourceTypes(query);

ResourceManager rm = ap.getEntityManager(ResourceManager.class);
ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
ResourceQuery.setANDMatch();
ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
List<ResourceEntry> allResources = rm.getResources("RT2", ResourceQuery);

PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
pssq.setANDMatch();
pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
List<PermissionSetEntry> allPermSets = psm.getPermissionSets(pssq);

RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
rcsq.setANDMatch();
rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false,      ComparatorType.EQUALITY, "roleCategoryCartoon",      BaseSearchQuery.MATCHER.EXACT);

List<RoleCategoryEntry> allRoleCategories = rcm.getRoleCategories(rcsq);
}
}

次の例は、リソース・カタログ要素を指定した複雑な問合せを示しています。

//ApplicationPolicy ap as in the preceeding example
ResourceTypeManager rtm = ap.getEntityManager(ResourceTypeManager.class);
ResourceTypeSearchQuery query = new ResourceTypeSearchQuery();
query.setANDMatch();
query.addQuery(ResourceTypeSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "resourceType", BaseSearchQuery.MATCHER.EXACT);
List<ResourceTypeEntry> enties = rtm.getResourceTypes(query);

ResourceManager rm = ap.getEntityManager(ResourceManager.class);
ResourceSearchQuery ResourceQuery = new ResourceSearchQuery();
ResourceQuery.setANDMatch();
ResourceQuery.addQuery(ResourceSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "R2", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> querries = ResourceQuery.getQueries();
List<ResourceEntry> resources = rm.getResources("RT2", ResourceQuery);

PermissionSetManager psm = ap.getEntityManager(PermissionSetManager.class);
PermissionSetSearchQuery pssq = new PermissionSetSearchQuery();
pssq.setANDMatch();
pssq.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "PS1", BaseSearchQuery.MATCHER.EXACT);
List<PermissionSetEntry> psets = psm.getPermissionSets(pssq);

RoleCategoryManager rcm = ap.getEntityManager(RoleCategoryManager.class);
RoleCategorySearchQuery rcsq = new RoleCategorySearchQuery();
rcsq.setANDMatch();
rcsq.addQuery(RoleCategorySearchQuery.SEARCH_PROPERTY.NAME, false, ComparatorType.EQUALITY, "roleCategoryCartoon", BaseSearchQuery.MATCHER.EXACT);
ArrayList<BaseSearchQuery> queries = rcsq.getQueries();
List<RoleCategoryEntry> rcs = rcm.getRoleCategories(rcsq);

次の例は、権限を作成する方法を示しています。

GrantManager gm = ap.getEntityManager(GrantManager.class);
Set<PrincipalEntry> pe = new HashSet<PrincipalEntry>();
List<AppRoleEntry> are = ap.searchAppRoles(appRoleName);
pe.addAll(are);
gm.grant(pe, null, permissionSetName);

17.3.3 プログラムによるポリシーのチェック

プログラムでポリシーをチェックする際には、次の点に留意してください。

- デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debugを-Djps.auth.debug=trueと設定します。
特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を設定する必要があります。

- ポリシー・プロバイダは、Java SEアプリケーションで明示的に設定する必要があります。

java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())

Java SEアプリケーションにポリシー・プロバイダを明示的に設定しておかないと、ランタイム・メソッド(JpsAuth.checkPermissionなど)が不正確な値を返す場合があります。

次の各項では、プログラムでポリシーをチェックするいくつかのメソッドの使用方法について説明します。

- checkPermissionの使用

- doAsおよびdoAsPrivilegedの使用

- checkBulkAuthorizationの使用

- getGrantedResourcesの使用

17.3.3.1 checkPermissionの使用

Oracle Fusion Middlewareでは、java.security.AccessControllerクラスとoracle.security.jps.util.JpsAuthクラスでcheckPermissionメソッドをサポートしています。

JpsAuthクラスのcheckPermissionはデバッグ・サポートとパフォーマンスにおいて優れており、監査もサポートされるため、このクラスの使用をお薦めします。

静的なAccessController.checkPermissionメソッドは、デフォルトのアクセス制御コンテキスト(スレッド作成時に継承されるコンテキスト)を使用します。その他のコンテキストでパーミッションを確認するには、特定のAccessControlContextインスタンスでcheckPermissionメソッドのインスタンスをコールします。

次の表では、JAASモードの値に応じたcheckPermissionの動作について説明します。

表17-2 JAASモードに応じたcheckPermissionの動作

JAASモード

checkPermissionの動作

offまたはundefined

有効なセキュリティ・ポリシーに基づいたコードソース・セキュリティを実施し、サブジェクトベースのセキュリティに対するプロビジョニングはありません。

doAs

doAsブロック内で作成されたアクセス制御コンテキストを使用して、コードソース・およびサブジェクトベースのセキュリティを組み合せて実施します。

doAsPrivileged

NULLアクセス制御コンテキストを使用してサブジェクトベースのセキュリティを適用します。

subjectOnly

パーミッションの評価時に、プリンシパルにかかわる権限付与のみが考慮されます(コードソースにかかわる権限付与は無視されます)。

注意:
checkPermissionをdoAsブロックの中でコールして、パーミッション・チェックのコールが失敗した場合、失敗した保護ドメインを表示するには、システム・プロパティjava.security.debug=access,failureを設定する必要があります。

次の例は、パーミッションをチェックするアプリケーションを示しています。アプリケーションEARファイルにjazn-data.xmlファイルとweb.xmlファイルが含まれていることを前提とします。

jazn-data.xml

<?xml version="1.0" ?>
<jazn-data>
<policy-store>
<applications>
<application>
<name>MyApp</name>

<app-roles>
<app-role>
<name>AppRole</name>
<display-name>AppRole display name</display-name>
<description>AppRole description</description>
<guid>F5494E409CFB11DEBFEBC11296284F58</guid>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
</app-role>
</app-roles>

<resource-types>
<resource-type>
<name>MyResourceType</name>
<display-name>MyResourceType display name</display-name>
<description>MyResourceType description</description>
<provider-name>MyResourceType provider</provider-name>
<matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>write,read</actions>
</resource-type>
</resource-types>

<resources>
<resource>
<name>MyResource</name>
<display-name>MyResource display name</display-name>
<description>MyResource description</description>
<type-name-ref>MyResourceType</type-name-ref>
</resource>
</resources>

<permission-sets>
<permission-set>
<name>MyEntitlement</name>
<display-name>MyEntitlement display name</display-name>
<description>MyEntitlement description</description>
<member-resources>
<member-resource>
<type-name-ref>MyResourceType</type-name-ref>
<resource-name>MyResource</resource-name>
<actions>write</actions>
</member-resource>
</member-resources>
</permission-set>
</permission-sets>

<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>AppRole</name>
<guid>F5494E409CFB11DEBFEBC11296284F58</guid>
</principal>
</principals>
</grantee>

<!-- entitlement -->
<permission-set-refs>
<permission-set-ref>
<name>MyEntitlement</name>
</permission-set-ref>
</permission-set-refs>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy></jazn-policy>
</jazn-data>

web.xml

次の例は、JpsFilterフィルタ構成を示しています。

<web-app>
<display-name>PolicyTest: PolicyServlet</display-name>
<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>application.name</param-name>
<param-value>PolicyServlet</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>PolicyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>...

例

次の例では、Subject.doAsPrivilegedがJpsSubject.doAsPrivilegedによって置換される場合があります。

import javax.security.auth.Subject;
import javax.servlet.ServletConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletOutputStream;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
import java.io.PrintWriter;
import java.io.StringWriter;
import java.security.*;
import java.util.Date;
import java.util.PropertyPermission;
import java.io.FilePermission;

public class PolicyServlet extends HttpServlet {

public PolicyServlet() {
super();
}

public void init(ServletConfig config)
throws ServletException {
super.init(config);
}

public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
final ServletOutputStream out = response.getOutputStream();

response.setContentType("text/html");
out.println("<HTML><BODY bgcolor=\"#FFFFFF\">");
out.println("Time stamp: " + new Date().toString());
out.println( "<br>request.getRemoteUser = " + request.getRemoteUser() + "<br>");
out.println("request.isUserInRole('sr_developer') = " + request.isUserInRole("sr_developer") + "<br>");
out.println("request.getUserPrincipal = " + request.getUserPrincipal() + "<br>");

Subject s = null;
s = Subject.getSubject(AccessController.getContext());

out.println("Subject in servlet " + s);
out.println("<br>");
final RuntimePermission rtPerm = new RuntimePermission("getClassLoader");
try {
Subject.doAsPrivileged(s, new PrivilegedAction() {
public Object run() {
try {
AccessController.checkPermission(rtPerm);
out.println("<br>");
out.println("CheckPermission passed for permission: " + rtPerm+ " seeded in application policy");
out.println("<br>");
} catch (IOException e) {
e.printStackTrace();
printException ("IOException", e, out);
} catch (AccessControlException ace) {
ace.printStackTrace();
printException ("Accesscontrol Exception", ace, out);
}
return null;
}
}, null);

} catch (Throwable e) {
e.printStackTrace();
printException("application policy check failed", e, out);
}
out.println("</BODY>");
out.println("</HTML>");
}

void printException(String msg, Throwable e, ServletOutputStream out) {
Throwable t;
try {
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw, true);
e.printStackTrace(pw);

out.println("<p>" + msg + "<p>");
out.println("<code>");
out.println(sw.getBuffer().toString());
t = e;
/* Print the root cause */
while ((t = t.getCause()) != null) {
sw = new StringWriter();
pw = new PrintWriter(sw, true);
t.printStackTrace(pw);

out.println("<hr>");
out.println("<p>  Caused By ... </p>");
out.println(sw.getBuffer().toString());
}
out.println("</code><p>");
} catch (IOException ioe) {
ioe.printStackTrace();
}
}
}

17.3.3.2 doAsおよびdoAsPrivilegedの使用

Oracle Fusion Middlewareでは、javax.security.auth.Subjectクラスとoracle.security.jps.util.JpsSubjectクラスでdoAsメソッドとdoAsPrivilegedメソッドをサポートしています。

oracle.security.jps.util.JpsSubjectクラスはパフォーマンスに優れており、監査も備えているため、このクラスの使用をお薦めします。

注意:
checkPermissionをdoAsブロックの中でコールして、パーミッション・チェックのコールが失敗した場合、失敗した保護ドメインを表示するには、システム・プロパティjava.security.debug=access,failureを設定する必要があります。

17.3.3.3 checkBulkAuthorizationの使用

checkBulkAuthorizationメソッドでは、サブジェクトが1つ以上のリソース・アクションにアクセスできるかどうかを判断します。このメソッドは、サブジェクトがリソースに対して認可されている一連のリソース・アクションを返します。リソースを使用する権限付与には、リソース・タイプを指定する必要があります。

このメソッドをコールする場合は、必ず次のようにします。

1. システム・プロパティjava.security.policyをOracle WebLogic Serverポリシー・ファイルの場所に設定しておきます。

2. アプリケーションでは、setPolicyの後にcheckBulkAuthorizationをコールします。

java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())

checkBulkAuthorizationでは、次のことを前提としています。

- コール元は、ユーザーおよびエンタープライズ・ロールのプリンシパルが指定されたサブジェクトと、各リソースが属するストライプが含まれるリソースのリストを提供できます。

- アプリケーションは、そのアプリケーションが実行されているドメインで構成されたアプリケーション・ストライプにアクセスできます。

17.3.3.4 getGrantedResourcesの使用

getGrantedResourcesメソッドは、指定のサブジェクトに付与されているリソース・アクションを返すことで、そのサブジェクトに付与されているリソースをすべてフェッチする実行時の認可問合せです。このメソッドは、リソース・タイプに関連付けられているパーミッションのみを返し、LDAPセキュリティ・ストアの場合のみ使用できます。

17.3.4 クラスResourcePermission

パーミッション・クラスでは、リソースに対して権限受領者が実行できるアクションを制御する手段が提供されます。カスタムのパーミッション・クラスを使用してアクション、ターゲット照合およびロジックを全面的に制御する場合でも、実行時に予期したとおりに機能するには、カスタムのパーミッション・クラスを使用可能にして必要に応じてロードできるようにサーバーのシステム・クラスパスに指定する必要があります。ただし、環境のシステム・クラス・パスの変更は困難で、環境によってはそのような変更ができないこともあります。

OPSSには、アプリケーションまたはシステム・リソースを保護するためにアプリケーション権限内でパーミッション・クラスとして使用するoracle.security.jps.ResourcePermissionクラスがあります。この方法では、カスタムのパーミッション・クラスを作成する必要がなくなるため、サポートされているポリシー・プロバイダに格納されているアプリケーション権限内のパーミッションでそのクラスをすぐに使用できます。このクラスはシステム・ポリシーで使用せず、アプリケーション・ポリシーでのみ使用してください。

リソース・パーミッションの構成

ResourcePermissionクラスを使用するパーミッションは、リソース・パーミッションと呼ばれ、リソース・タイプ、リソース名およびオプションのアクション・リストを指定します。

<permission>
<class>oracle.security.jps.ResourcePermission</class>
<name>resourceType=type,resourceName=name</name>
<actions>character-separated-list-of-actions</actions>
</permission>

リソース・タイプ情報が実行時に使用されない場合でも、リソース・タイプ定義は必要です。

次の例では、必要なリソース・タイプが含まれるリソース・パーミッションの指定を示しています。

<permission>
<class>oracle.security.jps.ResourcePermission</class>
<name>resourceType=epm.calcmgr.permission,resourceName=EPM_Calc_Manager</name>
</permission>

<resource-types>
<resource-type>
<name>epm.calcmgr.permission</name>
<display-name>CalcManager ResourceType</display-name>
<description>Resourcetype for managing CalcManager grants</description>
<provider-name></provider-name>
<matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions></actions>
</resource-type>
</resource-types>

<permission>
<class>oracle.security.jps.ResourcePermission</class>
<name>resourceType=oracle.bi.publisher.Reports,resourceName=GLReports</name>
<actions>develop;schedule</actions>
</permission>

<resource-types>
<resource-type>
<name>oracle.bi.publisher.Reports</name>
<display-name>BI Publisher Reports</display-name>
<provider-name></provider-name>
<matcher-class>oracle.security.jps.ResourcePermission</matcher-class>
<actions-delimiter>;</actions-delimiter>
<actions>view;develop;schedule</actions>
</resource-type>
</resource-types>

リソース・パーミッションに関連付けられるリソース・タイプには、空のアクション・リストを指定してもかまいません。リソース・パーミッションについて次の点に注意してください。

- 名前は、次の形式に従う必要があります。

resourceType=aType,resourceName=aName

リソース・パーミッションのリソース・タイプを定義する必要があります。リソース・タイプを取得するには、ResourcePermission.getTypeメソッドを使用します。

- アクションの文字区切りリストはオプションです。指定する場合は、関連するリソース・タイプで指定されているアクションのいずれかにする必要があります。ResourcePermission.getActionsメソッドにより、このリストは返されます。
このリストの項目の区切り文字には、関連するリソース・タイプの<actions-delimiter>で指定されている文字を使用する必要があります。

- ResourcePermission.getResourceNameメソッドは、パーミッションで使用されるリソースの表示名を返します。

- リソース・パーミッションでは、ワイルドカード文字がサポートされていません。

リソース・パーミッションの管理と確認

次の行は、リソース・パーミッションの作成方法とそのチェック方法を示しています。

ResourcePermission rp =
new ResourcePermission("oracle.bi.publisher.Reports","GLReps","develop");
JpsAuth.checkPermission(rp);

リソース・パーミッションによって次の条件が満たされると、パーミッション・チェックは成功です。

- パーミッションがResourcePermisionクラスのインスタンスです。

- リソース・タイプ名がリソース・タイプの名前に一致します(大文字小文字の区別はなし)。

- リソース名がリソース・インスタンスの名前に完全に一致します。

- アクション・リストが、リソース・タイプで指定されているアクションのカンマ区切りリストです。

リソース・タイプのクラスについて

リソース・タイプの作成時に、必要に応じてクラスを指定できます。指定しない場合は、oracle.security.jps.ResourcePermissionクラスにデフォルト設定されます。

2つ以上のリソース・タイプで1つのクラスを共有する場合は、そのクラスを次のいずれかにする必要があります。

- oracle.security.jps.ResourcePermissionクラス。

- oracle.security.jps.AbstractTypedPermission抽象クラスを拡張する具象クラス(次に示すMyAbstractTypedPermission)。

public class MyAbstractTypedPermission extends AbstractTypedPermission {
private static final long serialVersionUID = 8665318227676708586L;
public MyAbstractTypedPermission(String resourceType,
String resourceName,                                     String actions) {super(resourceType, resourceName, actions);
}
}

- oracle.security.jps.TypePermissionクラスを実装し、java.security.Permissionクラスを拡張するクラス。

18 資格証明ストア・フレームワークを使用した開発

この章では、アプリケーションでの資格証明ストア・フレームワークの使用方法と、資格証明ストア構成のガイドラインについて説明します。

この章の内容は次のとおりです。

- 資格証明ストア・フレームワークAPIについて

- 資格証明ストア・フレームワークAPIの使用のガイドライン

- マップとキー名について

- アクセス・パーミッションのプロビジョニング

- 資格証明ストア・フレームワークAPIの使用

- 資格証明ストア・フレームワークAPIの例

18.1 資格証明ストア・フレームワークAPIについて

CFS APIは、資格証明ストアに格納されている資格証明へのアクセス、取得および管理に使用します。このAPIを使用すると、次の操作が可能です。

- 資格証明マップまたはマップとキーのどちらが資格証明ストアに格納されているかのチェック。

- マップまたはマップとキーに関連付けられている資格証明の取得。

- マップまたはマップとキーへの資格証明の割当て。

- マップまたはマップとキーの資格証明の削除。

資格証明ストアに対する操作は、資格証明フレームワークで使用されるファイングレイン制御を実装するクラスであるCredentialAccessPermissionクラスによって保護されます。

関連項目:

第11章「資格証明の管理」

18.2 資格証明ストア・フレームワークAPIの使用のガイドライン

資格証明ストア・フレームワークAPIを使用するアプリケーションを開発する際には、必ず次のようにします。

- アプリケーションによる資格証明へのアクセスを可能にするセキュリティ・ポリシーをプロビジョニングします。

- 特に、複数のアプリケーションが同じ資格証明ストアを使用する環境では、使用する適切なマップとキー名を決定します。

- 必ずjps-config.xmlファイルで資格証明ストア・インスタンスを定義し、適切に構成します。

関連項目:

「アクセス・パーミッションのプロビジョニング」

「マップとキー名について」

「資格証明ストア・フレームワークAPIの使用」

「資格証明ストア・フレームワークAPIの例」

18.3 マップとキー名について

各アプリケーションには、資格証明ストア内で一意のマップ名が関連付けられている必要があります。これにより、ストア内のマップおよびキーの様々な名前の間で競合が発生せず、マップ名によってアプリケーションが一義的に特定されることが保証されます。アプリケーションは、特定のマップの中に、それぞれが同様に一意の名前を持っている複数のキーを格納できるため、マップ名/キー名のペアによって資格証明ストア内でただ1つのキーが特定されます。

18.4 アクセス・パーミッションのプロビジョニング

資格証明フレームワークにより、マップ、マップ内のすべてのキーおよびマップ内の特定のキーへのアクセスが保護されます。資格証明ストア・フレームワークAPIを使用するには、アプリケーションでAPIを使用できるようにするアクセス・パーミッションを指定する必要があります。さらに、このAPIをコールするコードにもコードソース・パーミッションが必要ですが、これらのパーミッションは通常、特定のJarのみに制限されます。すべてのマップおよびキーに対してアクセス・パーミッションを定義することはお薦めしません。

次の各項では、アクセス・パーミッションの定義について説明します。

- 1つのキーにアクセスするためのパーミッションの例

- マップにアクセスするためのパーミッションの例

18.4.1 1つのキーにアクセスするためのパーミッションの例

次の例では、マップ内の特定のキーに対してアクションを実行するソース・コードに対してのアクセス・パーミッションを示しています。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.
CredentialAccessPermission</class>
<name>context=SYSTEM,mapName=myMap,keyName=myKey</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

18.4.2 マップにアクセスするためのパーミッションの例

次の例では、マップとそのマップ内のすべてのキーに対して特定のアクションを実行するソース・コードに対してのアクセス・パーミッションを示しています。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.
CredentialAccessPermission</class>
<name>context=SYSTEM,mapName=myMap,keyName=*</name>
<actions>read,write,update,delete</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

18.5 資格証明ストア・フレームワークAPIの使用

次の各項では、Java SEアプリケーションおよびJava EEアプリケーションでこのフレームワークを使用する方法について説明します。

- Java SEアプリケーションでの資格証明ストア・フレームワークAPIの使用

- Java EEアプリケーションでの資格証明ストア・フレームワークAPIの使用

18.5.1 Java SEアプリケーションでの資格証明ストア・フレームワークAPIの使用

Java SEアプリケーションで資格証明ストア・フレームワークAPIを使用するには、次の手順を実行します。

1. jps-manifest.jarファイルがクラスパスに含まれていることを確認します。

2. 資格証明ストア・フレームワークAPIにアクセスするためのパーミッションを指定します。

3. Java仮想マシン(JVM)オプションを適宜設定します。次のようなオプションがあります。

- -Doracle.security.jps.config

デフォルトの場所($DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml)とは異なる場合に、jps-config-jse.xmlファイルへのフルパスを指定します。

- -Djava.security.policy

デフォルトの場所($WL_HOME/server/lib)とは異なる場合に、weblogic.policyファイルの場所を指定します。

- -Dcommon.components.home

ミドルウェア・ホームの下にあるoracle_commonディレクトリの場所を指定します。

- -Dopss.version

環境で使用されるバージョンを指定します。

関連項目:

「アクセス・パーミッションのプロビジョニング」

第24.1項「Java SEアプリケーションでのOPSSの使用」

18.5.2 Java EEアプリケーションでの資格証明ストア・フレームワークAPIの使用

資格証明ストア・フレームワークAPIをJava EEアプリケーションで使用するには、アプリケーションをOracle WebLogic Serverにデプロイする前に、動作に必要なアクセス・パーミッションを指定します。

関連項目:

「アクセス・パーミッションのプロビジョニング」

18.6 資格証明ストア・フレームワークAPIの例

次の各例では、資格証明ストア操作で必要なアクセス・パーミッションを使用する方法を示します。

- 資格証明ストア・フレームワーク操作の例

- ファイル資格証明を使用するJava SEアプリケーションの例

- ファイル資格証明を使用するJava EEアプリケーションの例

- LDAPストアを使用するJava EEアプリケーションの例

- DBストアを使用するJava EEアプリケーションの例

18.6.1 資格証明ストア・フレームワーク操作の例

次の例では、他の例で使用されている資格証明ストア・フレームワークAPI操作を示します。

package demo.util;
import java.security.AccessController;
import java.security.PrivilegedAction;
import oracle.security.jps.JpsException;
import oracle.security.jps.service.credstore.Credential;
import oracle.security.jps.service.credstore.CredentialAlreadyExistsException;
import oracle.security.jps.service.credstore.CredentialFactory;
import oracle.security.jps.service.credstore.CredentialStore;
import oracle.security.jps.service.credstore.PasswordCredential;

public class CsfUtil {
final CredentialStore store;
public CsfUtil(CredentialStore store) {
super();
this.store = store;
}

private void doOperation() {
try {
PasswordCredential pc = null;
try {
// this call requires read privilege
pc = (PasswordCredential)store.getCredential("pc_map", "pc_key");
if (pc == null) {
// key not found, create one
pc = CredentialFactory.newPasswordCredential("jdoe",
"password".toCharArray());
// this call requires write privilege
store.setCredential("pc_map", "pc_key", pc);
System.out.print("Created ");
}
else {
if (pc instanceof PasswordCredential){
System.out.print("Found ");
} else {
System.out.println("Unexpected credential type found");
}

System.out.println("password credential: Name=" + pc.getName() +
",Password=" +
new String(pc.getPassword()));

} catch (CredentialAlreadyExistsException e) {
// ignore because credential already exists.
System.out.println("Credential already exists for
<pc_map, pc_key>: " + pc.getName() + ":" +
new String(pc.getPassword()));
}

try {
// permission corresponding to
// "context=SYSTEM,mapName=gc_map,keyName=gc_key"
byte[] secret =
new byte[] { 0x7e, 0x7f, 0x3d, 0x4f, 0x10,
0x20, 0x30 };
Credential gc =
CredentialFactory.newGenericCredential(secret);
store.setCredential("gc_map", "gc_key", gc);
System.out.println("Created generic credential");
} catch (CredentialAlreadyExistsException e) {
// ignore because credential already exists.
System.out.println("Generic credential already exists
for <gc_map,gc_key>");
}

try {
//no permission for pc_map2 & pc_key2 to perform
//operation on store
Credential pc2 =
CredentialFactory.newPasswordCredential("pc_jode2",
"pc_password".toCharArray());
store.setCredential("pc_map2", "pc_key2", pc2);

} catch (Exception expected) {
//CredentialAccess Exception expected here. Not enough permission
System.out.println("This is expected :" +
expected.getLocalizedMessage());
}

} catch (JpsException e) {
e.printStackTrace();
}

}

/*
* This method performs a non-privileged operation. all code
* in the call stack must have CredentialAccessPermission
* OR
* the caller must have the CredentialAccessPermission only and
* invoke this operation in doPrivileged block
*/
public void doCredOperation() {
doOperation();
}

/*
* because the following performs a privileged operation, only
* jar containing this class needs CredentialAccessPermission
*/
public void doPrivilegedCredOperation() {
AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
doOperation();
return "done";
}
};
}
}

18.6.2 ファイル資格証明を使用するJava SEアプリケーションの例

この項の例では、$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlファイルで表されるファイル資格証明ストアを使用するJava SEアプリケーションを示します。

この例では、システム・プロパティprojectsrc.homeはJava SEアプリケーションを格納しているディレクトリを指し、clientApp.jarはdistディレクトリに存在するアプリケーションJARファイルです。

次の権限付与は、アクセス・パーミッションを示しています。

<grant>
<grantee>
<codesource>
<url>file:${projectsrc.home}/dist/clientApp.jar</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=pc_map,keyName=*</name>
<actions>read,write</actions>
</permission>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=gc_map,keyName=gc_key</name>
<actions>write</actions>
</permission>
</permissions>
</grant>

mapName=pc_map2,keyName=pc_key2にはパーミッションが付与されないため、そのマップおよびキーのsetCredentialへのコールは失敗します。

アプリケーションで使用される資格証明ストアは、jps-config-jse.xmlに指定します。

<serviceInstances>
<serviceInstance name="credstore_file_instance"
provider="credstore_file_provider">
<property name="location" value="store" />
</serviceInstance>
</serviceInstances>

次に、プログラムをコールするJava SEコードを示します。

package demo;
import java.io.ByteArrayInputStream;
import java.security.AccessController;
import java.security.PrivilegedAction;
import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsStartup;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.JpsException;
import oracle.security.jps.jaas.JavaPolicy;
import oracle.security.jps.service.credstore.Credential;
import oracle.security.jps.service.credstore.CredentialAlreadyExistsException;
import oracle.security.jps.service.credstore.CredentialFactory;
import oracle.security.jps.service.credstore.CredentialStore;
import oracle.security.jps.service.credstore.PasswordCredential;
import oracle.security.jps.service.policystore.PolicyStore;
import oracle.security.jps.service.policystore.PolicyStoreException;
import demo.util.CsfUtil;

public class CsfApp {
public CsfApp() {
super();
}
public static void main(String[] a) {
// perform operation as privileged code
JpsContextFactory ctxFactory;
try {
new JpsStartup().start();
ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();
CredentialStore store =
ctx.getServiceInstance(CredentialStore.class);
CsfUtil csf = new CsfUtil(store);
// next call is in a doPrivileged block and should succeed
csf.doPrivilegedCredOperation();

// because next call is not in a doPrivileged block,
// it fails if CredentialAccessPermission is not granted to this class
csf.doCredOperation();
} catch (JpsException e) {
e.printStackTrace();
}
}
}

18.6.3 ファイル資格証明を使用するJava EEアプリケーションの例

この例では、資格証明ストア・フレームワークAPIをコールするファイル資格証明を使用するJava EEアプリケーションを示します。jazn-data.xmlファイルでは、適切なアクセス・パーミッション、コードソース・パーミッション、マップとキーの様々な組合せで必要なパーミッションを定義します。

次の権限付与は、アクセス・パーミッションを示しています。

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=pc_map,keyName=*</name>
<actions>read,write</actions>
</permission>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=gc_map,keyName=gc_key</name>
<actions>write</actions>
</permission>
</permissions>
</grant>

アプリケーションで使用される資格証明ストアは、jps-config.xmlに指定します。

<serviceProviders>
<serviceProvider type="CREDENTIAL_STORE" name="credstoressp"
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider">
<description>SecretStore-based CSF provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name="credstore" provider="credstoressp">
<property name="location" value="./" />
</serviceInstance>
</serviceInstances>

<jpsContexts default="default">
<jpsContext name="default">
...
<serviceInstanceRef ref="credstore"/>
...
</jpsContext>
</jpsContexts>

locationプロパティでは、cwallet.ssoファイルの場所を指定します。

次に、このような構成を使用する例を示します。

package demo;
import demo.util.CsfUtil;
import java.io.IOException;
import java.io.PrintWriter;
import java.net.URL;
import java.util.Date;
import javax.servlet.*;
import javax.servlet.http.*;
import oracle.security.jps.JpsException;
import oracle.security.jps.service.JpsServiceLocator;
import oracle.security.jps.service.credstore.CredentialStore;
public class CsfDemoServlet extends HttpServlet {
private static final String CONTENT_TYPE = "text/html; charset=windows-1252";
public void init(ServletConfig config) throws ServletException {
super.init(config);
}
public void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException,
IOException {
response.setContentType(CONTENT_TYPE);
PrintWriter out = response.getWriter();
//ServletOutputStream out = response.getOutputStream();
try {
response.setContentType("text/html");
out.println("<html><body bgcolor=\"#FFFFFF\">");
out.println("<b>Current Time: </b>" + new Date().toString() +
"<br><br>");

//get hold of app-level CSF service store
//Outside app context, it returns the domain CSF store
final CredentialStore store =
JpsServiceLocator.getServiceLocator().lookup(CredentialStore.class);
CsfUtil csf = new CsfUtil(store);
csf.doPrivilegedCredOperation();
out.println("Credential operations completed using privileged code.");
} catch (JpsException e) {
e.printStackTrace(out);
}
}
}

作成操作は、権限が付与されたブロックの中に実装されます。Java SE環境では、次の2つのコールは同等です。

CredentialStore store = JpsServiceLocator.getServiceLocator().lookup(CredentialStore.class);

CredentialStore store = JpsContextFactory.getContextFactory().getContext().getServiceInstance(CredentialStore.class);

18.6.4LDAPストアを使用するJava EEアプリケーションの例

次の例では、「ファイル資格証明を使用するJava EEアプリケーションの例」で使用されている同じアプリケーションを使用していますが、資格証明ストアはここではファイルではなくLDAPです。

次に、LDAPストア構成の例を示します。

<serviceProviders>
<serviceProvider name="ldap.credentialstore.provider"
class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider">
<description>Prototype LDAP CSF provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance provider="ldap.credentialstore.provider"
name="credstore.ldap">
<property value="bootstrap"
name="bootstrap.security.principal.key"/>
<property value="cn=wls-jrfServer"
name="oracle.security.jps.farm.name"/>
<property value="cn=jpsTestNode"
name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://mynode.us.mycorp.com:1234"
name="ldap.url"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default="appdefault">
<jpsContext name="appdefault">
<serviceInstanceRef ref="credstore.ldap"/>
</jpsContext>
</jpsContexts>

18.6.5 DBストアを使用するJava EEアプリケーションの例

次の例では、「ファイル資格証明を使用するJava EEアプリケーションの例」で使用されている同じアプリケーションを使用していますが、資格証明ストアはここではファイルではなくデータベースです。

次に、DBストア構成の例を示します。

<serviceProviders>
<serviceProvider type="CREDENTIAL_STORE" name="db.credentialstore.provider" class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider"/>
<description>DB CSF provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance provider="db.credentialstore.provider"
name="credstore.db">
<property value="bootstrap"
name="bootstrap.security.principal.key"/>
<property value="cn=wls-jrfServer"
name="oracle.security.jps.farm.name"/>
<property value="cn=jpsTestNode"
name="oracle.security.jps.ldap.root.name"/>
<property name="jdbc.url" value="jdbc:oracle:thin:@localhost:5521:ldapoid"/>
<property name="jdbc.driver" value="oracle.jdbc.OracleDriver"/>
<property name="datasource.jndi.name" value="jdbc/OpssDS"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default="appdefault">
<jpsContext name="appdefault">
<serviceInstanceRef ref="credstore.db"/>
</jpsContext>
</jpsContexts>

19 ユーザーおよびロールAPIを使用した開発

この章では、ユーザーおよびロールAPIを使用してアイデンティティ・ストアのエントリにアクセス、検索および変更する方法と、LDAPプロバイダを使用してSecure Sockets Layer (SSL)を構成する方法について説明します。

次の項が含まれます:

- ユーザーおよびロールAPIについて

- サービス・プロバイダの操作

- アイデンティティ・ストアの検索

- アイデンティティ・ストアのエントリの作成と変更

- ユーザーおよびロールAPIの例

- LDAPプロバイダ用のSSLの構成

19.1 ユーザーおよびロールAPIについて

注意:
ユーザーおよびロールAPIは非推奨です。かわりにIdentity Governance Frameworkを使用し、このフレームワークの使用に移行することをお薦めします。この移行の詳細は、『Identity Governance Framework開発者ガイド』の「アイデンティティ・ディレクトリAPIへの移行」を参照してください。

ユーザーおよびロールAPIを使用すると、アプリケーションでは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報にアクセスできます。このリポジトリとして、LDAPサーバー、データベース、ファイル、一部のカスタム・リポジトリを使用できます。

ユーザーおよびロールAPIでは、プログラムによってリポジトリにアクセスでき、移植性を確保するため、アプリケーションの簡略化に役立ちます。たとえば、このAPIを使用すると、アプリケーションでは、アプリケーション・コードを変更する必要なしにいくつかのリポジトリにアクセスできます。

このAPIには、ユーザーおよびロールを作成、更新、削除したり、属性を検索するためのメソッドが組み込まれているため、たとえば、特定のロールの全ユーザーの電子メール・アドレスを取得することが可能です。

JavaコンテナからユーザーおよびロールAPIを使用するには、アイデンティティ・ストアはLDAPであり、管理サーバーは稼働している必要があります。さらに、アプリケーション・ロール・メンバーではweblogic.security.principal.WLSUserImplクラスを使用する必要があります。

ユーザーの認証には認証プロバイダを使用し、ユーザーおよびロールAPIをその目的で使用しないことと、ユーザーおよびロールAPIと同じLDAPサーバーのエントリにアクセスする他のAPIを同時に使用しないことをお薦めします。

関連項目:

「認証プロバイダとユーザーおよびロールAPI」

Oracle WebLogic Serverのセキュリティ・プロバイダの開発

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

19.1.1 認証プロバイダとユーザーおよびロールAPI

デフォルトでは、ユーザーおよびロールAPIはドメインで構成されている最初の認証プロバイダを使用します。アプリケーションで他の構成済認証プロバイダを使用する必要がある場合は、「サービス・プロバイダの操作」の説明に従ってこの特別な使用を構成します。

環境で複数のプロバイダが構成されている場合、プロバイダを順序リストに指定し、それぞれに制御フラグを設定します。この順序と制御フラグを使用して、サーバーでは使用するプロバイダが判別されます。プロバイダが1つ選択されると、残りのプロバイダは無視されます。

19.2 サービス・プロバイダの操作

プロバイダを実装するには、次の各項での説明に従って、基礎となるリポジトリに適したプロバイダ・クラスを選択し、そのプロバイダを構成してからプロバイダ・ランタイムを構成します。

- 環境の設定

- プロバイダ・リポジトリの選択

- プロバイダの起動時および実行時のプロパティの構成

- ファクトリ・インスタンス作成時のプロバイダの構成

- ストア・インスタンス作成時のプロバイダの構成

- 実行時のプロバイダの構成

- プログラミングのガイドライン

- プロバイダの存続期間

関連項目:

『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「アイデンティティ・アサーション・プロバイダ」

19.2.1 環境の設定

ユーザーおよびロールAPIでは、基礎となるリポジトリとの実際の通信を実行するアイデンティティ・プロバイダを介して、アイデンティティ・リポジトリとやり取りします。これにより、プロバイダの接続情報を変更することで様々なリポジトリで同じコードを使用できるため、柔軟性が得られます。

ユーザーおよびロールAPIを使用するように環境を構成するには、次のようにします。

- 基礎となる特定のアイデンティティ・リポジトリを実装するプロバイダJARファイルとプロバイダで必要なコンポーネントJARが環境で使用できることを確認します。

- 検索メソッドで使用されるオブジェクト・クラスを指定します。

<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<property name="idstore.config.provider"
value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/
>
<property name="CONNECTION_POOL_CLASS"
value="oracle.security.idm.providers.stdldap.JNDIPool"/>
<extendedProperty>
<name>user.object.classes</name>
<values>
<value>top</value>
<value>person</value>
<value>inetorgperson</value>
<value>organizationalperson</value>
<value>otherActiveDirectorySpecificClasses</value>
...
</values>
</extendedProperty>

- LDAPプロバイダの場合、cn=common,cn=products,cn=oraclecontextノードを読み取るためのパーミッションを保持するようにプロバイダ・ユーザーを構成します。

関連項目:

第9.6項「Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成」

19.2.2 プロバイダ・リポジトリの選択

OPSSでは、アイデンティティ・サービス・プロバイダに対して数多くのユーザー・リポジトリをサポートしています。システムおよびバージョンについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlで「Oracle Fusion Middleware 12c Certifications」を参照してください。

リポジトリを選択すると、次の表で説明しているように、プロバイダとともに使用するプロバイダ・クラスが決まります。

表19-1 リポジトリとプロバイダ・クラス

リポジトリ

プロバイダ・クラス

Microsoft Active Directory

oracle.security.idm.providers.ad.ADIdentityStoreFactory

Novell eDirectory

oracle.security.idm.providers.edir.EDIdentityStoreFactory

Oracle Directory Server Enterprise Edition

oracle.security.idm.providers.iplanet.IPIdentityStoreFactory

Oracle Internet Directory

oracle.security.idm.providers.oid.OIDIdentityStoreFactory

OpenLDAP

oracle.security.idm.providers.openldap.OLdapIdentityStoreFactory

組込みLDAPサーバー

oracle.security.idm.providers.wlsldap.WLSLDAPIdentityStoreFactory

Oracle Virtual Directory

oracle.security.idm.providers.ovd.OVDIdentityStoreFactory

Microsoft ADAM

oracle.security.idm.providers.ad.ADIdentityStoreFactory

IBM Tivoli

oracle.security.idm.providers.openldap.OLdapIdentityStoreFactory

プロバイダ・クラスには、ユーザーおよびロールAPIフレームワークで指定されているインタフェースを実装する必要があります。このAPIの詳細は、Oracle Fusion Middleware Oracle Platform Security Services用のJava APIリファレンスを参照してください。

19.2.3 プロバイダ・インスタンスの作成

プロバイダのクラスを特定した後にプロバイダ・インスタンスを作成するには、次の手順を実行します。

1. IdentityStoreFactoryBuilder.getIdentityStoreFactoryメソッドを使用して、ファクトリ・インスタンスを作成します。

IdentityStoreFactoryBuilder builder =new IdentityStoreFactoryBuilder ();

2. IdentityStoreFactory.getIdentityStoreInstanceメソッドを使用して、ストア・インスタンスを作成します。

IdentityStoreFactory oidFactory = builder.getIdentityStoreFactory(
”oracle.security.idm.providers.oid.OIDIdentityStoreFactory", factEnv);

3. アイデンティティ・ストアへのハンドルを取得します。

oidStore = oidFactory.getIdentityStoreInstance(storeEnv);

19.2.4 プロバイダの起動時および実行時のプロパティの構成

URL、リポジトリ・ポート番号、リポジトリにアクセスするためのユーザーおよびパスワードなど、ファクトリ・インスタンスおよびストア・インスタンスについて数多くのプロパティを設定できます。

次の各項では、これらのプロパティの設定方法について説明します。

- 起動時と実行時の構成

- 実行コンテキストIDの有効化

19.2.4.1 起動時と実行時の構成

起動時(プロバイダの作成時)または実行時にプロバイダ・プロパティを構成するには、次のようなプロパティを使用します。

- 起動時のプロパティ: 名前には接頭辞ST_が付いています。

- 実行時のプロパティ: 名前には接頭辞RT_が付いています。

起動時の構成プロパティ

通常、起動時のプロバイダ・プロパティの値はプロバイダの存続期間にわたって永続するため、このようなプロパティの構成は1回です。

ストア・インスタンスを作成する場合はST_SUBSCRIBER_NAMEプロパティを指定し、プロバイダ・ファクトリ・インスタンスを作成する場合は他の起動時のプロパティをすべて指定します。

次の表では、起動時のアイデンティティ・プロバイダ・プロパティについて説明します。

表19-2 起動時のアイデンティティ・プロバイダ・プロパティ

プロパティ名

説明

ST_BINARY_ATTRIBUTES

LDAPサーバーに格納されているバイナリ属性の名前。プロバイダでは、LDAPサーバーとのデータの送受信時に、このような属性をバイナリ・データとして処理します。

ST_CONNECTION_POOL

oracle.idm.connection.ConnectionPoolクラスのインスタンスである、外部接続プール。プロバイダでは、このプールを使用してLDAPサーバーへの接続を獲得し、ST_SECURITY_PRINCIPAL、ST_SECURITY_CREDENTIALS、ST_LDAP_URLの各プロパティは無視されます。

ST_USER_NAME_ATTR

アイデンティティ・ストアでのプロバイダ・ユーザーの名前。

ST_GROUP_NAME_ATTR

アイデンティティ・ストアでのプロバイダ・ユーザーのロール名。

ST_USER_LOGIN_ATTR

アイデンティティ・ストアでのプロバイダのユーザーのログインID。

ST_SECURITY_PRINCIPAL

ユーザー(プリンシパル)。

ST_SECURITY_CREDENTIALS

アイデンティティ・ストアにログインするための資格証明。

ST_LDAP_URL

アイデンティティ・ストアのURL。

ST_MAX_SEARCHFILTER_LENGTH

LDAPサーバーによって許可されている検索フィルタの最大長。

ST_LOGGER

APIで使用するロガー。

ST_SUBSCRIBER_NAME

LDAPサーバーでのベース識別名。このプロパティは、IdentityStoreインスタンスの作成時に指定され、残りのプロパティのデフォルト値を決定するために使用されます。

ST_CONNECTION_POOL_CLASS

接続プールの完全修飾クラス名。

ST_INITIAL_CONTEXT_FACTORY

初期コンテキストを作成するファクトリの完全修飾クラス名。

実行時の構成プロパティ

実行時のプロパティは、プロバイダのIdentityStoreインスタンスの動作を制御します。これらのプロパティは、IdentityStoreインスタンスから取得されるStoreConfigurationオブジェクトを指定して構成します。すべての実行時のプロパティには、デフォルト値があります。

次の表では、実行時のアイデンティティ・プロバイダ・プロパティについて説明します。

表19-3 実行時のアイデンティティ・プロバイダ・プロパティ

プロパティ名

説明

RT_USER_OBJECT_CLASSES

ユーザーの作成に必要なクラスの配列。

RT_USER_MANDATORY_ATTRS

新しいユーザーの必須属性。

RT_USER_CREATE_BASES

新しいユーザーの作成が可能なベースDN。

RT_USER_SEARCH_BASES

ユーザーの検索が可能なベースDN。

RT_USER_FILTER_OBJECT_CLASSES

ユーザーの検索に使用するクラスの配列。

RT_GROUP_OBJECT_CLASSES

ロールの作成に必要なクラスの配列。

RT_GROUP_MANDATORY_ATTRS

新しいロールの必須属性。

RT_GROUP_CREATE_BASES

新しいロールの作成が可能なベースDN。

RT_GROUP_SEARCH_BASES

ロールの検索が可能なベースDN。

RT_GROUP_MEMBER_ATTRS

ロールの属性の配列。ロールのメンバーはすべて、これらの属性それぞれについて値を持っています。

RT_GROUP_FILTER_OBJECT_CLASSES

ロールの検索に使用するクラスの配列。

RT_USER_SELECTED_CREATE_BASE

createUserを使用してユーザーが作成される識別名。nullで、ST_SUBSCRIBER_NAMEが指定されていない場合は、最初に指定されたRT_USER_CREATE_BASEの値が使用されます。nullで、ST_SUBSCRIBER_NAMEが指定されている場合は、アイデンティティ・ストアのサブスクライバ名が使用されます。

RT_GROUP_SELECTED_CREATE_BASE

createRoleを使用してロールが作成される識別名。nullで、ST_SUBSCRIBER_NAMEが指定されていない場合は、最初に指定されたRT_GROUP_CREATE_BASEの値が使用されます。nullで、ST_SUBSCRIBER_NAMEが指定されている場合は、アイデンティティ・ストアのサブスクライバ名が使用されます。

RT_GROUP_GENERIC_SEARCH_BASE

特定のアイデンティティでロールを検索する識別名。LDAPプロバイダでは、デフォルトでサブスクライバ名に設定されますが、それ以外の場合は最初のグループ検索ベースに設定されます。

RT_SEARCH_TYPE

検索のタイプ: SIMPLE、PAGEDまたはVIRTUAL_LIST_VIEW。

19.2.4.2 実行コンテキストIDの有効化

ECIDの有効化は、LDAPアイデンティティ・ストアでのみ必要です。ユーザーおよびロールAPIでは、デフォルトでECIDのサポートが無効になっています。有効にするには、APIを初期化する際にST_ECID_ENABLEDプロパティをtrueに設定します。

factEnv.put(OVDIdentityStoreFactory.ST_ECID_ENABLED, "true");

19.2.5 ファクトリ・インスタンス作成時のプロバイダの構成

この段階での構成は、ファクトリ・オブジェクト全体の他、特定のファクトリ・インスタンスを使用して作成されるオブジェクトにも影響を与えます。ST_LDAP_URL、ST_SECURITY_PRINCIPAL、ST_SECURITY_CREDENTIALなど、起動時のプロパティの多くはこの時点で設定されます。

次の各項では、ファクトリ・インスタンスの作成時にプロバイダ・プロパティを構成する方法について説明します。

- 共通プロパティの構成

- 定数、接続数およびプール接続の構成

19.2.5.1 共通プロパティの構成

次の例では、ログの場所の指定を含め、LDAPファクトリの作成時点でのプロバイダ構成を示します。

IdentityStoreFactoryBuilder builder = new IdentityStoreFactoryBuilder();
IdentityStoreFactory oidFactory = null;
Hashtable factEnv = new Hashtable();
Logger mylogr = Logger.getLogger("mylogger.abc.com");
FileHandler fh = new FileHandler("userroleapi.log");
mylogr.addHandler(fh);
factEnv.put(OIDIdentityStoreFactory.ST_SECURITY_PRINCIPAL,"User DN");
factEnv.put(OIDIdentityStoreFactory.ST_SECURITY_CREDENTIALS,"User password");
factEnv.put(OIDIdentityStoreFactory.ST_LDAP_URL,"ldap://ldaphost:port/");
factEnv.put(OIDIdentityStoreFactory.ST_LOGGER_NAME, "mylogger.abc.com");
oidFactory = builder.getIdentityStoreFactory(
"oracle.security.idm.providers.oid.OIDIdentityStoreFactory", factEnv);

19.2.5.2 定数、接続数およびプール接続の構成

定数およびデフォルトのプロパティ値を上書きするには、ファクトリの作成時にST_PROPERTY_ATTRIBUTE_MAPPINGにマップを指定します。

次の例では、接続の最大数と最小数、カスタム接続プール・クラス、RoleProfile.OWNERユーザーからmyowner属性へのマップを設定する方法を示します。

factEnv.put(LDIdentityStoreFactory.ST_CONNECTION_POOL_MIN_CONNECTIONS,  "3");
factEnv.put(LDIdentityStoreFactory.ST_CONNECTION_POOL_MAX_CONNECTIONS, "16");

factEnv.put(OIDIdentityStoreFactory.ST_CONNECTION_POOL_CLASS,
"oracle.security.idm.providers.stdldap.JNDIPool");

factEnv.put(IPIdentityStoreFactory.ST_SECURITY_PRINCIPAL, "<User DN>");
factEnv.put(IPIdentityStoreFactory.ST_SECURITY_CREDENTIALS, "<User password>");
factEnv.put(IPIdentityStoreFactory.ST_LDAP_URL,"ldap://ldaphost:port/");
Map m = new Hashtable();
m.put(RoleProfile.OWNER, "myowner");
factEnv.put(IPIdentityStoreFactory.ST_PROPERTY_ATTRIBUTE_MAPPING, m);
ipFactory = builder.getIdentityStoreFactory(
"oracle.security.idm.providers.iplanet.IPIdentityStoreFactory",
factEnv);

getOwnersやgetOwnedRolesなど、所有者に関連する操作はすべて、myowner属性を使用して実行されます。接続の最大値から最小値を差し引いた値は10を上回る必要があります。

19.2.6 ストア・インスタンス作成時のプロバイダの構成

アイデンティティ・ストアの構成は、ストアとストア・インスタンスで作成されたすべてのオブジェクトに適用されるため、アイデンティティ・ストア・インスタンスの作成時に、必要な実行時のプロパティを指定します。

次の例では、ストア・インスタンスを作成する方法と、そのハンドルを取得する方法を示します。

IdentityStore oidStore = null;
Hashtable storeEnv = new Hashtable();
storeEnv.put(OIDIdentityStoreFactory.ST_SUBSCRIBER_NAME,"dc=us,dc=oracle,dc=com");
oidStore = oidFactory.getIdentityStoreInstance(storeEnv);

19.2.7 実行時のプロバイダの構成

実行時のプロパティの追加および変更を容易にするために、ユーザーおよびロールAPIにはgetStoreConfigurationメソッドが用意されています。たとえば、実行時にRT_USER_SEARCH_BASESを設定するには、次のようにします。

StoreConfiguration conf = oidStore.getStoreConfiguration();
conf.setProperty(”RT_USER_SEARCH_BASES”, ”dc=us,dc=oracle,dc=com”);

19.2.8 プログラミングのガイドライン

次の各項では、プロバイダおよびプロバイダ・アーティファクトを操作する際に考慮する推奨事項を示します。

- プロバイダの切替え

- アイデンティティ・ストア・オブジェクトの使用

19.2.8.1 プロバイダの切替え

プロバイダを切り替えた後にアプリケーションが確実に機能するように、次のガイドラインを考慮してください。

1. ユーザー・プロパティを参照する場合にのみ、oracle.security.idm.UserProfileで指定した定数を使用します。移植不可能なネイティブの定数は使用しないでください。たとえば、ユーザーのログイン名を取得する必要がある場合は、UserProfile.USER_NAME定数を使用してフェッチします。

Property prop = usrprofile.getProperty(UserProfile.USER_NAME);

2. 次のようなコードを使用して、ユーザーのプロパティをすべて取得します。

UserProfile upf = null;
List proplst = store.getUserPropertyNames();
String[] proparr = (String[]) proplst.toArray(new String[proplst.size()]);
PropertySet pset = upf.getProperties(proparr);

3. 検索フィルタを作成する際、検索フィルタ文字列でネイティブのワイルド・カード文字を直接使用しないでください。かわりに、プロバイダに対して正しいワイルドカード文字をフェッチするSimpleSearchFilter.getWildCardCharメソッドを使用します。

SmpleSearchFilter sf = m_identityStore.getSimpleSearchFilter(
attrName, SimpleSearchFilter.TYPE_EQUAL, null);
sf.setValue(filterStringWithoutWildcard+sf.getWildCardChar());

たとえば、このメソッドは、データベース・プロバイダの場合は%を返し、LDAPプロバイダの場合は*を返します。

4. アプリケーションが事前定義済のワイルドカード文字を含むユーザー指定のフィルタ文字列を受け入れる場合は、ユーザーおよびロールAPIのフィルタを生成する間に、フィルタに次の変換を適用します。

//User supplied filter assumes ”%” as the wildcard character
String userDefinedFilter = .................
SmpleSearchFilter sf = m_identityStore.getSimpleSearchFilter(
attrName, SimpleSearchFilter.TYPE_EQUAL, null);
userDefinedFilter = userDefinedFilter.replaceall("%", sf.getWildCardChar());
sf.setValue(userDefinedFilter);

19.2.8.2 アイデンティティ・ストア・オブジェクトの使用

アプリケーションの実装時には、次の点を考慮します。

- アイデンティティ・ストアの実装は、スレッドセーフではありません。ユーザーおよびロールAPIでは、ストア・インスタンスはスレッド間で共有されないことを前提としています。ストア・インスタンスがスレッド間で共有される場合、アプリケーション・コードでは、避けられないスレッド・セーフティの問題に注意して対処する必要があります。

- 一部のアプリケーションでは、実行時のプロパティとして定義する作成ベース、検索ベース、その他の様々な実行時のプロパティをユーザー・セッションで変更できるため、このような設定に応じてアイデンティティ・ストアの実行時の動作が変ります。フレームワークでは、セッションごとに使用できるアイデンティティ・ストア・インスタンスは1つのみです。

19.2.9 プロバイダの存続期間

プロバイダは、ファクトリ・インスタンスを閉じるまで環境に存在し続けます。プロバイダ・インスタンスが終了すると、そのインスタンスで作成されたオブジェクトはすべて無効になり、そのようなオブジェクトに対するその後のコールは例外をスローします。ファクトリ・インスタンスを閉じる際は、サーバー接続を明示的に閉じて、有効でなくなったインスタンスを削除することをお薦めします。ファクトリ・インスタンスはスレッドセーフですが、アイデンティティ・ストア・インスタンスはスレッドセーフではありません。

アイデンティティ・ストア・インスタンスを閉じる場合にも、同様の考慮事項が当てはまります。

19.3 アイデンティティ・ストアの検索

アイデンティティ・ストアへの問合せでは、単一のアイデンティティを返すことも、複数のアイデンティティを返すこともできます。次の各項では、ユーザーおよびロールAPIを使用してアイデンティティ・ストアに問い合せる方法について説明します。

- 特定のアイデンティティの検索

- 複数のアイデンティティの検索

- 検索フィルタの使用

19.3.1 特定のアイデンティティの検索

特定のアイデンティティまたはロールを問い合せるには、次のメソッドのいずれかを使用します。

IdentityStore.searchUser(String name);
IdentityStore.searchUser(Principal principal);
IdentityStore.searchUser(int searchType, String name);
IdentityStore.searchRole(int searchType, String value);

これらのメソッドは、ストアに格納されていることがわかっているアイデンティティへのオブジェクト参照を取得する必要がある場合に使用します。ストアで同じ値を持つエンティティが複数見つかると例外が発生します。

19.3.2 複数のアイデンティティの検索

複数のアイデンティティまたはロールを問い合せるには、次のメソッドのいずれかを使用します。

IdentityStore.search(SearchParams params);
IdentityStore.searchUsers(SearchParams params);
IdentityStore.searchRoles(int searchType, SearchParams params);
IdentityStore.searchProfiles(SearchParams params);

19.3.3 検索フィルタの使用

ユーザーおよびロールAPIには、様々な検索操作を容易にする検索フィルタが多数含まれています。次の各項では、検索フィルタの使用方法について説明します。

- フィルタ演算子

- ログイン・ユーザーおよびロール用のフィルタ

- フィルタの例

19.3.3.1 フィルタ演算子

ユーザーおよびロールAPIでは、簡易検索フィルタの作成に使用する演算子"="、"<"、">"、"<="および">="と、2つ以上の検索文字列を組み合せた複合検索フィルタの作成に使用する演算子"&"および"|"がサポートされています。

NOT演算子は、簡易検索フィルタでも複合検索フィルタでも使用します。否定フィルタは、フィルタによって拒否されたエンティティを返します。

19.3.3.2 ログイン・ユーザーおよびロール用のフィルタ

アプリケーションでは一般に、ログイン・ユーザーのアイデンティティおよびユーザーのグループ名を取得する必要があります。user.login.attr属性とgroupname.attr属性はユーザーのログイン時に設定されるため、UserProfile.getUserNameメソッドとRoleProfile.getProperty(RoleProfile.NAME)メソッドを使用して、これらの値を取得します。

次の例では、ログイン・ユーザーを問い合せる方法を示します。

SimpleSearchFilter sf = oidStore.getSimpleSearchFilter(
UserProfile.USER_NAME,  SimpleSearchFilter.TYPE_EQUAL, "sampleUserName");
SearchParameters ssp = new SearchParameters(sf, SearchParameters.SEARCH_USERS_ONLY);

SearchResponse resp = oidStore.searchUsers(ssp);
System.out.println("Searched users are:");
while (resp.hasNext()) {
Identity idy = resp.next();
String foundUserName = ((User)idy).getUserProfile().getUserName();
System.out.println("Found user name: "+ foundUserName );
}

次の例では、ログイン・ユーザーのロールを問い合せる方法を示します。

Role aRole = idStore.searchRole(IdentityStore.SEARCH_BY_NAME, "sampleRoleName");
Property prop = aRole.getRoleProfile().getProperty(RoleProfile.NAME);

List roleList = prop.getValues();
Iterator itr = roleList.iterator();
System.out.println("Searched roles are:");
while (itr.hasNext()) {
String foundRoleName = (String)itr.next();
System.out.println("Found role name: "+ foundRoleName );
}

19.3.3.3 フィルタの例

簡易検索フィルタの実装は、基礎となるストアによって異なります。次の例では、NAMEフィールドの値がnull以外であるエントリがすべてフィルタを通ります。

SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(UserProfile.NAME,
SimpleSearchFilter.TYPE_EQUAL, null);
sf.setValue(sf.getWildCardChar());

次の例では、優先言語が英語以外のユーザーが取得されます。

SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(
UserProfile.PREFERRED_LANGUAGE,
SimpleSearchFilter.TYPE_EQUAL,
"english");
sf.negate();

次の例では、複数の検索フィルタを演算子の"&"または"|"で結合しています。これは、aからjまでの文字で始まる名前のユーザーが検索されます。

SimpleSearchFilter sf1 =
oidStore.getSimpleSearchFilter(
UserProfile.NAME,
SimpleSearchFilter.TYPE_GREATER,
null);

sf1.setValue("a"+sf1.getWildCardChar());
SimpleSearchFilter sf2 =
oidStore.getSimpleSearchFilter(UserProfile.NAME,
SimpleSearchFilter.TYPE_LESS, null);
sf2.setValue("j"+sf2.getWildCardChar());
SimpleSearchFilter sfArray[] = new SimpleSearchFilter[] {sf1, sf2};
ComplexSearchFilter cf1 =
store.getComplexSearchFilter(sfArray, ComplexSearchFilter.TYPE_AND);

否定フィルタを使用して、"a"から"j"までの文字で始まり、文字"i"で始まらない名前を持つユーザーを検索するには、次のようにします。

[continues from previous example]
SimpleSearchFilter sf3 =
oidStore.getSimpleSearchFilter(UserProfile.NAME,SimpleSearchFilter.TYPE_EQUAL,null);
sf3.setValue(”i”+sf3.getWildCardChar());
sf3.negate();

SearchFilter sfArray2[] = new SearchFilter[] {cf1, sf3};
ComplexSearchFilter cf2 =
store.getComplexSearchFilter(sfArray2, ComplexSearchFilter.TYPE_AND);

次の例では、文字のAで始まる名前がフィルタ処理され、戻り値が出力されます。

// search filter (cn=a*)
SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(UserProfile.NAME,SimpleSearchFilter.TYPE_EQUAL,null);
sf.setValue("a"+sf.getWildCardChar());

SearchParameters params = new SearchParameters();
params.setFilter(sf);

// Search users
SearchResponse resp = oidStore.searchUsers(params);
System.out.println("Searched users are:");
while (resp.hasNext()) {
Identity idy = resp.next();
System.out.println("Unique name: "+idy.getUniqueName());
}

19.4 アイデンティティ・ストアのエントリの作成と変更

ユーザーおよびロールAPIを使用すると、UserManagerクラスとRoleManagerクラスを使用してアイデンティティを追加および変更できます。UserManagerおよびRoleManagerのインスタンスをストア・インスタンスから取得するには、次のコールを使用します。

UserManager um = storeInst.getUserManager();
RoleManager rm = storeInst.getRoleManager();

次の各項では、それぞれの例を示します。

- アイデンティティとロールの作成

- アイデンティティの変更

- アイデンティティの削除

関連項目:

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

19.4.1 アイデンティティとロールの作成

新しいアイデンティティを作成するには、UserManagerクラスで次のメソッドのいずれかを使用します。

createUser(java.lang.String name, char[] password)
createUser(java.lang.String name, char[] password, PropertySet suppliedProps)

2つ目のメソッドにより、渡された値がユーザー・プロパティに設定されます。必須属性の値が入力されないと、デフォルト値が指定されます。

新しいロールを作成するには、RoleManagerクラスで次のメソッドのいずれかを使用します。

createRole(String roleName);
createRole(String roleName, int roleScope);

デフォルトでは、ロールはエンタープライズ・スコープで作成されます。

19.4.2 アイデンティティの変更

アイデンティティを変更するには、まずそのアイデンティティへの参照を取得します。次に、User、UserProfile、RoleまたはRoleProfileの各クラスでsetPropertyメソッドを使用してアイデンティティを変更します。

表示名を置換するには、次のようにします。

UserProfile usrprofile = usr.getUserProfile();
ModProperty mprop = new ModProperty(UserProfile.DISPLAY_NAME,
"modified display name",
ModProperty.REPLACE);
usrprofile.setProperty(mprop);

有効な演算子は、ADD、REMOVEおよびREPLACEです。

複数の値を持つ属性の値の1つを変更するには、まず変更する値を削除し、次に変更した値を追加します。

19.4.3 アイデンティティの削除

アイデンティティを削除するには、まずユーザーおよびロールの参照を取得し、次にdropUserメソッドとdropRoleメソッドを使用します。

User usr;
Role role;
usrmanager.dropUser(usr);
rolemanager.dropRole(role);

19.5 ユーザーおよびロールAPIの例

次の各例では、ユーザーおよびロールAPIを使用してユーザーを問い合せたり、管理する方法を示します。

- ユーザーの検索の例

- ユーザーの管理の例

19.5.1 ユーザーの検索の例

次の例では、ユーザーを問い合せるための検索フィルタの設定方法を示します。グループを問い合せるには、RoleProfileクラスを使用します。ユーザーを問い合せるには、UserProfileクラスを使用します。

import oracle.security.idm.*;
import oracle.security.idm.providers.oid.*;
import java.util.*;
import java.io.*;

public class SearchUsersOID
{
public static void main(String args[])
{
IdentityStoreFactoryBuilder builder = new
IdentityStoreFactoryBuilder();
IdentityStoreFactory oidFactory = null;
IdentityStore oidStore = null;

try
{
Hashtable factEnv = new Hashtable();
Hashtable storeEnv = new Hashtable();
// creating the factory instance
factEnv.put(OIDIdentityStoreFactory.ST_SECURITY_PRINCIPAL,"<User DN>");
factEnv.put(OIDIdentityStoreFactory.ST_SECURITY_CREDENTIALS,"<User password>");
factEnv.put(OIDIdentityStoreFactory.ST_LDAP_URL,"ldap://ldaphost:port/");
oidFactory =  builder.getIdentityStoreFactory(
"oracle.security.idm.providers.oid.OIDIdentityStoreFactory",
factEnv);

storeEnv.put(OIDIdentityStoreFactory.RT_SUBSCRIBER_NAME,
"<Subscriber name>");
oidStore = oidFactory.getIdentityStoreInstance(storeEnv);

// search filter (cn=a*)
SimpleSearchFilter sf = oidStore.getSimpleSearchFilter(
UserProfile.NAME, SimpleSearchFilter.TYPE_EQUAL, null);
sf.setValue("a"+sf.getWildCardChar());

// sf2 search filter (!(cn=*a))
SimpleSearchFilter sf2 = oidStore.getSimpleSearchFilter(
UserProfile.NAME, SimpleSearchFilter.TYPE_EQUAL, null);
sf2.setValue(sf2.getWildCardChar()+"a");
sf2.negate();

SimpleSearchFilter sfArray[] = new SimpleSearchFilter[] {sf,sf2};
ComplexSearchFilter cf1 = oidStore.getComplexSearchFilter(sfArray,
ComplexSearchFilter.TYPE_AND);
SearchParameters params = new SearchParameters();
params.setFilter(cf1);

// Searching for users
SearchResponse resp = oidStore.searchUsers(params);
System.out.println("Searched users are:");
while (resp.hasNext()) {
Identity idy = resp.next();
System.out.println("Unique name: "+idy.getUniqueName());
}
}catch (IMException e)
{
e.printStackTrace();
}
}
}

19.5.2 ユーザーの管理の例

Microsoft Active Directoryストアでアイデンティティを作成、変更および削除するには、次のようにします。

package oracle.security.idm.samples;
import oracle.security.idm.*;
import oracle.security.idm.providers.ad.*;
import java.util.*;
import java.io.*;

public class CreateModifyDeleteUserAD
{
public static void main(String args[])
{
IdentityStoreFactoryBuilder builder = new IdentityStoreFactoryBuilder();
IdentityStoreFactory adFactory = null;
IdentityStore adStore = null;
try
{
Hashtable factEnv = new Hashtable();
Hashtable storeEnv = new Hashtable();

String keystore = "/home/bhusingh/client_keystore.jks";
System.setProperty("javax.net.ssl.trustStore",keystore);
System.setProperty("javax.net.ssl.trustStorePassword","welcome1");

// create the factory
factEnv.put(ADIdentityStoreFactory.ST_SECURITY_PRINCIPAL,
"sramaset@xyzt.com");
factEnv.put(ADIdentityStoreFactory.ST_SECURITY_CREDENTIALS,"ntrtntrt");
factEnv.put(ADIdentityStoreFactory.ST_LDAP_URL,
"ldaps://mynode.us.mycorp.com:123/");
factEnv.put("java.naming.security.protocol","SSL");
adFactory =  builder.getIdentityStoreFactory(
"oracle.security.idm.providers.ad.ADIdentityStoreFactory",factEnv);

// create the store
storeEnv.put(ADIdentityStoreFactory.ST_SUBSCRIBER_NAME,
"dc=upad,dc=us,dc=oracle,dc=com");
adStore = adFactory.getIdentityStoreInstance(storeEnv);

//get UserManager and create user
UserManager usrmanager = adStore.getUserManager();
String usrname = "amyd";
try
{
User usr = adStore.searchUser(usrname);
usrmanager.dropUser(usr);
}catch(IMException ime){}

System.out.println("creating user "+usrname);
char[] password = {'w', 'e', 'l', 'c', 'o', 'm','e','3'};
User usr = usrmanager.createUser(usrname, password);
System.out.println("user (" +usr.getUniqueName() + ") created with guid="+usr.getGUID());
System.out.println("user name = "+usr.getName() );

// modify user
System.out.println("DISPLAY_NAME="+usr.getDisplayName());
System.out.println("modifying property UserProfile.DISPLAY_NAME");
UserProfile usrprofile = usr.getUserProfile();
ModProperty mprop = new ModProperty(UserProfile.DISPLAY_NAME,
"modified display name",
ModProperty.REPLACE);
usrprofile.setProperty(mprop);
System.out.println("get property values UserProfile.DISPLAY_NAME");
Property prop = usrprofile.getProperty(UserProfile.DISPLAY_NAME);
List values = prop.getValues();
Iterator itr = values.iterator();
while(itr.hasNext())
{
System.out.println(UserProfile.DISPLAY_NAME+": "+ itr.next());
}
System.out.println();

System.out.println("verifying the password");
boolean pass = false;
try
{
usrmanager.authenticateUser(usrname, password);
pass= true;
}catch (oracle.security.idm.AuthenticationException e)
{
System.out.println(e);
e.printStackTrace();
}
if (pass)
System.out.println("password verification succeded");
else
System.out.println("password verification failed");

SimpleSearchFilter sf = adStore.getSimpleSearchFilter(
UserProfile.NAME, SimpleSearchFilter.TYPE_EQUAL, usrname);

SearchParameters params = new SearchParameters();
params.setFilter(sf);

// Search users
SearchResponse resp = adStore.searchUsers(params);
System.out.println("Searched users are:");
while (resp.hasNext())
{
Identity idy = resp.next();
System.out.println("name: "+idy.getName()+"\tUnique name: "+idy.getUniqueName());
}

// delete user
System.out.println("deleting user "+usrname);
usrmanager.dropUser(usr);
System.out.println("user dropped");
}catch (Exception e)
{
e.printStackTrace();
}
}
}

19.6 LDAPプロバイダ用のSSLの構成

次の各項では、プロバイダへのSSL接続に関するUserおよびロールAPIのサポートについて説明します。

- プロバイダに対するSSLの設定

- プロバイダに対するSSLのカスタマイズ

19.6.1 プロバイダに対するSSLの設定

ユーザーおよびロールAPIのLDAPプロバイダでは、LDAPアイデンティティ・ストアとのSSLを実現するために、Java Secure Sockets Extension (JSSE)に依存しています。

すぐに使用できるSSLを設定するには、次の手順を実行します。

1. キーストアおよびキー・パスワードの値を指定し、システム・プロパティを設定します。

String keystore = "<keystore location>";
String keypasswd = "<keystore password>";
System.setProperty("javax.net.ssl.trustStore",keystore);
System.setProperty("javax.net.ssl.trustStorePassword", keypasswd);

2. LDAPサーバーのSSL URLを設定します。

factEnv.put(ADIdentityStoreFactory.ST_LDAP_URL,
"ldaps://ldaphost:sslport/");

3. 次のように、セキュリティ・プロトコルをSSLに設定します。

factEnv.put("java.naming.security.protocol","SSL");

関連項目:

第8.5項「アイデンティティ・ストア用のSSLの構成」

19.6.2 プロバイダに対するSSLのカスタマイズ

SSLをカスタマイズするには、次の手順を実行します。

1. 次のように、カスタムSSLソケット・ファクトリ名を指定します。

factEnv.put("java.naming.ldap.factory.socket",
"fully qualified custom socket factory name");

2. LDAPサーバーのSSL URLを設定します。

factEnv.put(ADIdentityStoreFactory.ST_LDAP_URL,
"ldaps://ldaphost:sslport/");

3. 次のように、セキュリティ・プロトコルをSSLに設定します。

factEnv.put("java.naming.security.protocol","SSL");

20 Identity Governance Frameworkを使用した開発

この章では、Identity Governance Frameworkに用意されているアイデンティティ・ディレクトリAPIを使用してアイデンティティにアクセスする方法およびメンテナンスする方法について説明します。

この章の内容は次のとおりです。

- Identity Governance Frameworkについて

- アイデンティティ・ディレクトリAPIの構成について

- アイデンティティ・ディレクトリAPIの使用

- アイデンティティ・ディレクトリAPIを使用したSSLの構成

20.1 Identity Governance Frameworkについて

Identity Governance Frameworkを使用すると、アプリケーションでは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的な方法でアイデンティティ・データにアクセスできます。このフレームワークには、アイデンティティ・ディレクトリAPIが組み込まれていますが、このAPIはアイデンティティ・ストアのアーティファクトにアクセスできるインタフェースの集合で、柔軟に全面的に構成できます。

アイデンティティ・ディレクトリAPIを使用するには、igf-manifest.jarファイルをアプリケーション・クラスパスに追加します。

関連項目:

Oracle Fusion Middleware Identity Governance Framework Identity Directory用のJava APIリファレンス

20.1.1 アイデンティティ・ディレクトリAPIの概要

アイデンティティ・ディレクトリAPIを使用すると、Java EEアプリケーションおよびJava SEアプリケーションでアイデンティティ・データへのアクセスおよび管理が可能になります。このAPIは、Identity Governance Frameworkに付属し、アイデンティティ制御に関するフレームワークの利点をすべて提供します。

アイデンティティ・ディレクトリAPIを使用すると、次のことが可能になります。

- ユーザーおよびグループの操作。

- パスワードの変更。

- パスワード変更の施行。

- 複数の値を持つ属性、静的グループおよび動的グループのメンテナンス。

20.2 アイデンティティ・ディレクトリAPIの構成について

アイデンティティ・ディレクトリAPIは、異なるアイデンティティ・ストアに格納されているユーザーおよびグループ情報にアクセスし、それらを変更するためのインタフェースを提供します。構成は、DOMAIN_HOME/config/fmwconfig/ids-config.xmlファイル、ovd/ids/adapters.os.xmlファイルおよびOPSS構成ファイルに指定します。

関連項目:

第9.6項「Fusion Middleware Controlを使用したセキュリティ・プロバイダの構成」

第F.2.4項「LDAPアイデンティティのプロパティ」

Oracle Fusion Middleware Identity Governance Framework Identity Directory用のJava APIリファレンスのアイデンティティ・ディレクトリAPIの構成に関する項

Oracle Fusion Middleware Identity Governance Framework Identity Directory用のJava APIリファレンス

20.3 アイデンティティ・ディレクトリAPIの使用

次の各項では、ユーザーおよびグループを管理するためのアイデンティティ・ディレクトリAPIの使用例を示します。

- アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- ユーザーの作成と削除

- ユーザーの取得と変更

- ユーザーの簡易検索と複合検索

- グループの作成と削除

- グループの取得

- グループ検索フィルタ

- グループに対するメンバーの追加と削除

20.3.1 アイデンティティ・ディレクトリ・ハンドルの初期化と取得

次の例では、アイデンティティ・ディレクトリ・ハンドルおよびディレクトリ・インスタンスを取得する方法を示します。

JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();

//find the service instance
IdentityStoreService idstoreService =   ctx.getServiceInstance(IdentityStoreService.class)
to
//get instance
oracle.igf.ids.IdentityDirectory ids = idstoreService.getIdentityStore();

次の例では、IDSの場所にある構成でサービスを初期化しています。すべてのユーザーおよびグループの操作は、このIDSインスタンスを使用して実行されます。

import java.util.ArrayList;
import java.util.List;
import java.util.Iterator;
import java.util.Map;
import java.security.Principal;
import oracle.igf.ids.Entity;
import oracle.igf.ids.User;
import oracle.igf.ids.UserManager;
import oracle.igf.ids.Group;
import oracle.igf.ids.GroupManager;
import oracle.igf.ids.config.OperationalConfig;
import oracle.igf.ids.IdentityDirectoryFactory;
import oracle.igf.ids.IdentityDirectoryInfo;
import oracle.igf.ids.IdentityDirectory;
import oracle.igf.ids.IDSException;
import oracle.igf.ids.ReadOptions;
import oracle.igf.ids.CreateOptions;
import oracle.igf.ids.ModifyOptions;
import oracle.igf.ids.DeleteOptions;
import oracle.igf.ids.SearchOptions;
import oracle.igf.ids.SearchFilter;
import oracle.igf.ids.ResultSet;
import oracle.igf.ids.Attribute;
import oracle.igf.ids.ModAttribute;
import oracle.dms.context.ExecutionContext;

public class Ids1Test {
private IdentityDirectory ids;
private UserManager uMgr;
private GroupManager gMgr;
public Ids1Test() throws IDSException {
// Set Operational Config
OperationalConfig opConfig = new OperationalConfig();

// Set search/crate base, name, objclass, etc. config.
// This overrides default operational configuration in IDS
opConfig.setEntityProperty("User", opConfig.SEARCH_BASE,          "l=amer,dc=example,dc=com");
opConfig.setEntityProperty("User", opConfig.CREATE_BASE,          "l=amer,dc=example,dc=com");
opConfig.setEntityProperty("User", opConfig.FILTER_OBJCLASSES, "person");
opConfig.setEntityProperty("User", opConfig.CREATE_OBJCLASSES,          "inetorgperson");
opConfig.setEntityProperty("Group", opConfig.SEARCH_BASE,          "cn=dlcontainerOCS,dc=example,dc=com");
opConfig.setEntityProperty("Group", opConfig.CREATE_BASE,          "cn=dlcontainerOCS,dc=example,dc=com");
opConfig.setEntityProperty("Group", opConfig.FILTER_OBJCLASSES,          "groupofuniquenames");
opConfig.setEntityProperty("Group", opConfig.CREATE_OBJCLASSES,          "groupofuniquenames,orclgroup");

// Get IdentityDirectoryService "userrole" configured in IDS config
IdentityDirectoryFactory factory = new IdentityDirectoryFactory();
ids = factory.getIdentityDirectory("userrole", opConfig);

// Get UserManager and GroupManager handles
uMgr = ids.getUserManager();
gMgr = ids.getGroupManager();
}

20.3.2 ユーザーの作成と削除

次の例では、ユーザーを作成および削除する方法を示します。

public Principal createUser() {
Principal principal = null;
List<Attribute> attrs = new ArrayList<Attribute>();
attrs.add(new Attribute("commonname", "test1_user1"));
attrs.add(new Attribute("password", "welcome123".toCharArray()));
attrs.add(new Attribute("firstname", "test1"));
attrs.add(new Attribute("lastname", "user1"));
attrs.add(new Attribute("mail", "test1.user1@example.com"));
attrs.add(new Attribute("telephone", "1 650 123 0001"));
attrs.add(new Attribute("title", "Senior Director"));
attrs.add(new Attribute("uid", "tuser1"));
attrs.add(new Attribute("description", "created test user 1",
new java.util.Locale("us", "en")));
try {
CreateOptions createOpts = new CreateOptions();
createOpts.setCreateBase("l=apac,dc=example,dc=com");
principal = uMgr.createUser(attrs, createOpts);
System.out.println("Created user " + principal.getName());
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
return principal;
}

public void deleteGroup(Principal principal) {
try {
DeleteOptions deleteOpts = new DeleteOptions();
gMgr.deleteGroup(principal, deleteOpts);
System.out.println("Deleted group " + principal.getName());
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

20.3.3 ユーザーの取得と変更

次の例では、ユーザーへのハンドルを取得し、変更する方法を示します。

public User getUser(Principal principal) {
User user = null;
try {
ReadOptions readOpts = new ReadOptions();
// Getting specific locale values
readOpts.setLocale("us-en");
user = uMgr.getUser(principal, readOpts);
printEntity(user);
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
return user;
}

public void modifyUser(User user) {
try {
ModifyOptions modifyOpts = new ModifyOptions();
List<ModAttribute> attrs = new ArrayList<ModAttribute>();
attrs.add(new ModAttribute("description", "modified test user 1"));
//attrs.add(new ModAttribute("uid", "testuser1"));
user.modify(attrs, modifyOpts);
System.out.println("Modified user " + user.getName());
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

20.3.4 ユーザーの簡易検索と複合検索

次の例では、簡易ユーザー検索と複合ユーザー検索を示します。

try {
ReadOptions readOpts = new ReadOptions();
readOpts.setSearchBase("l=apac");
User user = uMgr.searchUser("tuser1", readOpts);
printEntity(user);
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

public void searchUsers() {
try {
// Complex search filter with nested AND and OR conditiions
SearchFilter filter = new SearchFilter(
SearchFilter.LogicalOp.OR,
new SearchFilter(SearchFilter.LogicalOp.AND,
new SearchFilter("firstname", SearchFilter.Operator.BEGINS_WITH, "ve"),
new SearchFilter("telephone", SearchFilter.Operator.CONTAINS, "506")),
new SearchFilter(SearchFilter.LogicalOp.AND,
new SearchFilter("firstname", SearchFilter.Operator.BEGINS_WITH, "ra"),
new SearchFilter(SearchFilter.LogicalOp.OR,
new SearchFilter("orgunit", SearchFilter.Operator.BEGINS_WITH, "ldap"),
new SearchFilter("orgunit", SearchFilter.Operator.BEGINS_WITH, "sun"),
new SearchFilter("orgunit", SearchFilter.Operator.BEGINS_WITH,           "access")),
new SearchFilter("telephone", SearchFilter.Operator.CONTAINS, "506")));

// Request attributes
List<String> reqAttrs = new ArrayList<String>();
reqAttrs.add("jpegphoto");
SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(3);
searchOpts.setRequestedPage(1);
searchOpts.setRequestedAttrs(reqAttrs);
searchOpts.setSearchBase("l=amer");

ResultSet<User> sr = uMgr.searchUsers(filter, searchOpts);
while (sr.hasMore()) {
User user = sr.getNext();
System.out.println(user.getSubjectName());
System.out.println("    " + user.getAttributeValue("commonname"));
}
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

20.3.5 グループの作成と削除

次の例では、グループを作成および削除する方法を示します。

public Principal createGroup() {
Principal principal = null;
List<Attribute> attrs = new ArrayList<Attribute>();
attrs.add(new Attribute("name", "test1_group1"));
attrs.add(new Attribute("description", "created test group 1"));
attrs.add(new Attribute("displayname", "test1 group1"));
try {
CreateOptions createOpts = new CreateOptions();
principal = gMgr.createGroup(attrs, createOpts);
System.out.println("Created group " + principal.getName());
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
return principal;
}

20.3.6 グループの取得

次の例では、グループへのハンドルを取得する方法を示します。

public Group getGroup(Principal principal) {
Group group = null;
try {
ReadOptions readOpts = new ReadOptions();
group = gMgr.getGroup(principal, readOpts);
printEntity(group);
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
return group;
}

20.3.7 グループ検索フィルタ

次の例では、複数のグループを返す検索フィルタを示します。

public void searchGroups() {
try {
SearchFilter filter = new SearchFilter("name",
SearchFilter.Operator.BEGINS_WITH, "test");
SearchOptions searchOpts = new SearchOptions();
searchOpts.setPageSize(10);
ResultSet<Group> sr = gMgr.searchGroups(filter, searchOpts);
while (sr.hasMore()) {
Group group = sr.getNext();
System.out.println(group.getSubjectName());
}
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

20.3.8 グループに対するメンバーの追加と削除

次の例では、グループに対してユーザーを追加および削除する方法を示します。

public void addMember() {
try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("testuser1", readOpts);
Group group = gMgr.searchGroup("test1_group1", readOpts);
ModifyOptions modOpts = new ModifyOptions();
user.addMemberOf(group, modOpts);
System.out.println("added testuser1 as member of test1_group1");
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

public void deleteMember() {
try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("testuser1", readOpts);
Group group = gMgr.searchGroup("test1_group1", readOpts);
ModifyOptions modOpts = new ModifyOptions();
group.deleteMember(user, modOpts);
System.out.println("deleted testuser1 from the group test1_group1");
} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

20.4 アイデンティティ・ディレクトリAPIを使用したSSLの構成

アイデンティティ・ディレクトリAPI使用時のSecure Sockets Layer (SSL)構成の詳細は、第8.5項「アイデンティティ・ストア用のSSLの構成」を参照してください。

21 キーストア・サービスを使用した開発

この章では、アプリケーションでキーストア・サービスAPIを使用する方法について説明し、実行時に鍵にアクセスしたり、取得する一般的なキーストア操作の例を示します。

この章の内容は次のとおりです。

- キーストア・サービスAPIについて

- ポリシー・パーミッションの設定

- Java EEアプリケーションでのキーストア・サービスAPIの使用

- Java SEアプリケーションでのキーストア・サービスAPIの使用

- キーストア・サービスAPIの例

21.1 キーストア・サービスAPIについて

キーストアは鍵と証明書を安全に格納するために使用し、キーストア・サービスAPIはキーストア・リポジトリのデータへのアクセス、取得およびメンテナンスのために使用します。このリポジトリ・タイプは、ファイル、LDAPまたはDBのいずれかです。

操作には鍵の作成、読取り、更新、削除などがあり、キーストアの構成済プロパティであるキーストア・アーティファクトへのハンドルを取得します。このような操作は、サービスで使用されるファイングレイン・アクセス制御モデルを実装するKeyStoreAccessPermissionクラスによって保護されます。

アプリケーションでキーストア・サービスAPIを使用する前に、次のようにします。

- 使用するアプリケーション・ストライプとキーストアを特定します。

- アプリケーションによるキーストアへのアクセスおよび使用を可能にする必要なポリシーをプロビジョニングします。ポリシーのプロビジョニングの詳細は、「ポリシー・パーミッションの設定」を参照してください。

- 必ずキーストア・インスタンスをjps-config.xmlファイルに指定します。

関連項目:

第12.2項「Fusion Middleware Controlを使用したキーストアの管理」

第12.3項「WLSTを使用したキーストアの管理」

「キーストアのパーミッションの例」

21.2 ポリシー・パーミッションの設定

ドメインに構成されているキーストア・プロバイダは、サーバーの起動時にインスタンス化されます。ファイル・キーストア・プロバイダにより、その内容はsystem-jazn-data.xmlファイルに指定されます。

鍵はアプリケーション・ストライプ・レベル、キーストア・レベルまたは単一の鍵レベルで保護できます。キーストア・サービスAPIを使用してキーストアにアクセスするには、アプリケーションで実行できる操作を指定するコードソース・パーミッションがアプリケーションに必要です。

このようなパーミッションは特定のアプリケーションおよび鍵に限定することをお薦めします。

次の各項では、いくつかのパーミッションの例を示します。

- キーストアのパーミッションの例

- マップのパーミッションの例

- 鍵の別名のパーミッションの例

21.2.1 キーストアのパーミッションの例

次の例では、ストライプ内のキーストアに対するアクションをコードソースに付与するポリシーを示します。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<!-- This is the location of the JAR as loaded with the runtime -->
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.keystore.KeyStoreAccessPermission</class>
<name>stripeName=keystoreapp,keystoreName=ks1,alias=*</name>
<!-- All actions are granted -->
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

説明:

- stripeNameは、パーミッションを付与するアプリケーション・ストライプの名前です。

- keystoreNameは、キーストアの名前です。

- aliasはキーストア内のキー別名を示します。ワイルドカードは、すべての別名に対するパーミッションがアプリケーションに付与されることを意味します。

関連項目:

第12.1.1項「キーストア・サービスの構造」

21.2.2 マップのパーミッションの例

次の例では、ストライプ内のすべてのキーストアに対する読取り、書込みおよび削除のパーミッションをコードソースに付与するポリシーを示します。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.keystore.KeyStoreAccessPermission</class>
<name>stripeName=keystoreapp,keystoreName=*,alias=*</name>
<actions>read,write,update,delete</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

21.2.3 鍵の別名のパーミッションの例

次の例では、ストライプ内の特定のキーストアおよび別名に対する読取りパーミッションをコードソースに付与するポリシーを示します。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.keystore.KeyStoreAccessPermission</class>
<name>stripeName=keystoreapp,keystoreName=ks1,alias=orakey</name>
<actions>read</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

21.3 Java EEアプリケーションでのキーストア・サービスAPIの使用

Java EEアプリケーションでキーストア・サービスAPIを使用するには、次の手順を実行します。

1. アプリケーションでAPIを使用するのに必要なパーミッションを設定します。

2. Oracle WebLogic Serverを起動します。

3. アプリケーションをデプロイします。

関連項目:

「ポリシー・パーミッションの設定」

第23章「OPSSを使用するためのJava EEアプリケーションの構成」

21.4 Java SEアプリケーションでのキーストア・サービスAPIの使用

Java SEアプリケーションでキーストア・サービスAPIを使用するには、次の手順を実行します。

1. jps-manifest.jarファイルがそのクラスパスに入っていることを確認します。

2. アプリケーションでAPIを使用するのに必要なパーミッションを設定します。

3. Java仮想マシン(JVM)を適宜設定します。

-Doracle.security.jps.config

jps-config-jse.xml構成ファイルのフルパスを指定します。

-Djava.security.policy

weblogic.policyポリシー・ファイルの場所を指定します。

-Dcommon.components.home

ミドルウェア・ホームの下にあるoracle_commonディレクトリの場所を指定します。

-Dopss.version

環境で使用されるバージョンを指定します。

-Djava.security.debug=all

デバッグ・レベルを指定します。

4. アプリケーションを実行します。

関連項目:

「ポリシー・パーミッションの設定」

第1.3.2項「Java SEアプリケーションのセキュリティについて」

第24.1項「Java SEアプリケーションでのOPSSの使用」

21.5 キーストア・サービスAPIの例

次の各項では、APIの使用例を示します。

- キーストア・サービス管理の例

- 実行時のキーの読取りの例

21.5.1 キーストア・サービス管理の例

次の例では、一般的なキーストアの操作を示します。

import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.JpsException;
import oracle.security.jps.service.keystore.KeyStoreProperties;
import oracle.security.jps.service.keystore.KeyStoreService;
import oracle.security.jps.service.keystore.KeyStoreServiceException;
import java.security.AccessController;
import java.security.PrivilegedAction;

public class KeyStoreTest {
private static KeyStoreService ks = null;
public KeyStoreTest() {
super();
}
/*
* This method performs a non-privileged operation. Either all code
* in the call stack must have KeyStoreAccessPermission
* OR
* the caller must have the KeyStoreAccessPermission only and
* invoke this operation in doPrivileged block
*/
public static void doKeyStoreOperation() {
doOperation();
}
/*
* because this method performs a privileged operation, only current class or
* jar containing this class needs KeyStoreAccessPermission
*/
public static void doPrivilegedKeyStoreOperation() {
AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
doOperation();
return "done";
}
});
}
private static void doOperation() {
try {
ks.deleteKeyStore("keystoreapp", "ks1", null);
} catch(KeyStoreServiceException e) {
e.printStackTrace();
}
public static void main(String args[]) throws Exception {
try {
new JpsStartup().start();
JpsContext ctx = JpsContextFactory.getContextFactory().getContext();
ks = ctx.getServiceInstance(KeyStoreService.class);
// this call is in a doPrivileged block
doPrivilegedKeyStoreOperation();

} catch (JpsException je) {
je.printStackTrace();
}
}
}

関連項目:

『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』

21.5.2 実行時のキーの読取りの例

次の例では、実行時にキーストア・アーティファクトにアクセスする方法をいくつか示します。

- キーストアへのハンドルの取得

- キーストア・アーティファクトのアクセス - メソッド1

- キーストア・アーティファクトのアクセス - メソッド2

21.5.2.1 キーストアへのハンドルの取得

キーストアにアクセスするには、まずアプリケーションで、アプリケーション・ストライプおよびキーストア名を別々のパラメータとして指定するか、アプリケーション・ストライプおよびキーストア名を1つのパラメータとして指定して、キーストア・ハンドルを取得する必要があります。

いずれの方法も、鍵および証明書のフェッチとまったく同じ方法で動作をしますが、唯一の相違はキーストアのロード方法です。1つ目の方法1ではOPSS APIを使用します。2つ目の方法ではJava SE Development Kit (JDK) APIを使用します。

21.5.2.2 キーストア・アーティファクトのアクセス - メソッド1

次の例では、アプリケーション・ストライプおよびキーストアを別々のパラメータとして指定し、キーストアへのハンドルを取得する方法を示します。

// First get the KeyStoreService handle from JpsContext
JpsContext ctx = JpsContextFactory.getContextFactory().getContext();
KeyStoreService kss = ctx.getServiceInstance(KeyStoreService.class);

// Now get the keystore handle from KeyStoreService.
// Method 1: Explicitly specify application stripe and keystore name as
// separate parameters. In this example, the last parameter is null because
// we are demonstrating a password-protected keystore.
java.security.KeyStore keyStore = kss.getKeyStore("keystoreapp", "ks1", null);

// If this keystore is password-protected, provide the keystore password as the
// last parameter.
// java.security.KeyStore.ProtectionParameter pwd = new
java.security.KeyStore.PasswordProtection("password".toCharArray());
// java.security.KeyStore keyStore = kss.getKeyStore("keystoreapp", "ks1", pwd);

// Method 2: Specify application stripe and keystore name as one parameter
// using KSS URI. The last parameter is the keystore password, which is
// set to null in this example due to permission protected keystore.
// For password-protected keystore, set it to the keystore password.
Key key = keyStore.getKey("key-alias", null);

// Get the certificate associated with this alias
Certificate cert = keyStore.getCertificate("cert-alias");

注意:
メソッドload、getKey、getCertへのコールをdoPrivilegedブロック内に入れることをお薦めします。

21.5.2.3 キーストア・アーティファクトのアクセス - メソッド2

次の例では、JDKキーストアURIを使用してアプリケーション・ストライプおよびキーストアを1つのパラメータとして指定し、キーストアへのハンドルを取得する方法を示します。

// Create an object with parameters indicating the keystore to load
FarmKeyStoreLoadStoreParameter param = new FarmKeyStoreLoadStoreParameter();
param.setAppStripeName("keystoreapp");
param.setKeyStoreName("ks1");
// The password is set to null in this example because it assumes this is a
// permission protected keystore.
param.setProtectionParameter(null);
// If the keystore is password protected, use the following lines instead
// java.security.KeyStore.ProtectionParameter pwd = new java.security.KeyStore.PasswordProtection("password".toCharArray());
// param.setProtectionParameter(pwd);

// Initialize the keystore object by setting keystore type and provider
java.security.KeyStore keyStore = KeyStore.getInstance("KSS", new FarmKeyStoreProvider());

// Load the keystore. There are two ways to do this:
// Method 1: Explicitly specify application stripe and keystore name as
// separate parameters in param object
// keyStore.load(param);

// Method 2: Specify application stripe and keystore name as one parameter
// using KSS URI. because we demonstrate method 2, in this
// example, method 1 is commented out

FarmKeyStoreLoadStoreParameter param = new FarmKeyStoreLoadStoreParameter();
param.setKssUri("kss://keystoreapp/ks1");
param.setProtectionParameter(null);
keyStore.load(param);

// Now you have a handle to JDK KeyStore object. Use this handle to get
// key(s) and/or certificate(s)

// Get the private key associated with this alias
Key key = keyStore.getKey("key-alias", null);
// Get the certificate associated with this alias
Certificate cert = keyStore.getCertificate("cert-alias");

注意:
メソッドload、getKey、getCertへのコールをdoPrivilegedブロック内に入れることをお薦めします。

22 Oracle Fusion Middleware監査フレームワークを使用した開発

この章では、Oracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)を使用してアプリケーション・イベントを監査する方法について説明します。このフレームワークを使用して、イベント定義の作成、デプロイ時のサービスへのアプリケーションの登録、実行時の監査構成の変更およびレポートの生成を行います。

この章の内容は次のとおりです。

- アプリケーションとOFM監査フレームワークの統合

- 監査定義ファイルの作成

- サービスへのアプリケーションの登録

- プログラムによるポリシーの管理

- プログラムによる監査イベントのロギング

- 監査定義の更新と保守

22.1 アプリケーションとOFM監査フレームワークの統合

アプリケーションをOFM監査フレームワークと統合するには、次の各項で説明されるタスクを実行します。

- 監査定義ファイルの作成

- サービスへのアプリケーションの登録

- プログラムによる監査イベントのロギング

- 監査定義の更新と保守

22.2 監査定義ファイルの作成

次の各項では、component-event.xmlおよび翻訳ファイルの作成方法について説明します。

- component-events.xmlファイル

- 翻訳ファイル

関連項目:

第13.6.1項「component_events.xmlファイルについて」

22.2.1 component-events.xmlファイル

component-events.xml監査定義ファイルを作成する際には、次の点に留意してください。

- 監査イベント定義を変更する場合は、マイナー番号またはメジャー番号を変更してバージョンIDを変更する必要があります。

- アプリケーション属性定義の表とデータベース列は、1対1で対応する必要があります。各カスタム属性には、対応する順序番号が属性定義に含まれている必要があります。

関連項目:

第13.7.1項「バージョン番号とは」

第13.7.2項「カスタム属性からデータベース列へのマッピングについて」

22.2.2 翻訳ファイル

次の手順では、XLIFF (XML Localization Interchange File Format)翻訳ファイルを生成して、component_events_xlf.jarファイルにパックする方法について説明します。デプロイ時および登録中に、この情報はコンポーネント監査イベント定義とともに監査ストアに格納されます。

1. 次のようなコマンドを実行してXLIFFファイルを生成します。

java -cp $MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jpsaudit.jar:
$MW_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-api.jar oracle.security.audit.tools.NewXlfGenerator
-s /tmp/comp_events.xml
-t /tmp/comp_events.xlf

2. 生成されたxlfファイルをサポートされている言語に翻訳します。このxlfファイルには、すべてのカテゴリ、イベント、属性に関する翻訳ユニットおよびヘルプ・テキストが含まれます。これらの接頭辞は、Category_、Event_およびAttribute_です。

3. 翻訳済ファイルをJARファイルにパッケージ化します。

22.3 サービスへのアプリケーションの登録

次の各項では、監査へのアプリケーションの登録を可能にする様々なメカニズムについて説明します。

- 宣言による監査登録の実行

- プログラム登録

- WLSTコマンドを使用した登録

- 監査アーティファクト用ドメイン拡張テンプレートの使用

注意:
ドメイン拡張テンプレートを使用した登録が望ましい方法です。テンプレートの詳細は、「監査アーティファクト用ドメイン拡張テンプレートの使用」を参照してください。

22.3.1 宣言による監査登録の実行

この項では、2種類の宣言による監査定義の登録方法を説明します。

- デフォルトの監査登録

- カスタム監査登録

22.3.1.1 アプリケーション監査登録

アプリケーションをデプロイ、再デプロイまたはアンデプロイする際に、次の登録アクティビティがデフォルトで発生します。

- デプロイ - アプリケーションがまだ登録されていない場合に、監査イベント定義を監査ストアに登録します。

- 再デプロイ - コンポーネントがすでに登録されている場合に、コンポーネント・イベント定義をアップグレードします。

- アンデプロイ - アプリケーションの監査イベント定義を監査ストアから削除します。

監査レコードを問い合せるための簡易データベース・ビューは、登録時にIAUスキーマ内に作成されます。これは、Oracle Fusion Middlewareリポジトリ作成ユーティリティによってビューが作成されるコンポーネントを除いたすべてについて発生します。

22.3.1.2 カスタム監査登録

監査登録をカスタマイズするパラメータは、weblogic-application.xml WebLogicデプロイメント記述子で設定します。このファイルは、アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルのMETA-INFディレクトリでパッケージ化されます。パッケージ化の要件の詳細は、第23.5項を参照してください。

監査レコードを問い合せるための簡易データベース・ビューは、ビューの作成を明示的に無効にしないかぎり、監査登録時にIAUスキーマ内に作成されます。

表22-1に、パラメータとそのオプションを示します。

表22-1 監査登録のパラメータ

パラメータ

オプション

説明

opss.audit.registration

OVERWRITE

登録されているかどうかにかかわらず、コンポーネント監査定義を登録します。

UPGRADE (デフォルト・オプション)

バージョンのサポートに応じてコンポーネント監査定義を登録します。

DISABLE

コンポーネント監査定義を登録しません。

opss.audit.deregistration

DELETE(デフォルト・オプション)

アプリケーションのアンデプロイ時に、コンポーネント監査定義を監査ストアから削除します。

DISABLE

アプリケーションのアンデプロイ時に、コンポーネント監査定義を監査ストアに残します。

opss.audit.componentType

カスタム・コンポーネント・タイプを設定します。(オプション)

opss.audit.iauview

SIMPLE

INDEXABLE

DISABLE

- 簡易IAUビューを作成します(デフォルトの動作)。

- 索引がcomponent_events.xmlアプリケーション・ファイルで指定されている場合は、索引付け可能IAUビューを作成します。

- ビューの作成を無効にします。

次の例では、登録オプションと登録解除オプションの使用方法を示します。

<wls:application-param>
<wls:param-name>opss.audit.registration</wls:param-name>
<wls:param-value>DISABLE</wls:param-value>
</wls:application-param>

<wls:application-param>
<wls:param-name>opss.audit.registration</wls:param-name>
<wls:param-value>OVERWRITE</wls:param-value>
</wls:application-param>

<wls:application-param>
<wls:param-name>opss.audit.unregistration</wls:param-name>
<wls:param-value>DELETE</wls:param-value>
</wls:application-param>

<wls:application-param>
<wls:param-name>opss.audit.unregistration</wls:param-name>
<wls:param-value>DISABLE</wls:param-value>
</wls:application-param>

22.3.2 プログラム登録

次の例では、プログラムでアプリケーションを監査に登録する方法を示しています。

AuditService auditService = JpsServiceLocator.getServiceLocator().lookup(AuditService.class);
AuditRegistration auditReg = <instance of AuditRegistration implementation>;
AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {
public Object run() throws AuditException, IOException {
auditService.register(auditReg);
return null;
}
});

auditService.registerメソッドをコールするには、作成およびアップグレードのアクションに関してAuditStoreAccessPermissionパーミッションがアプリケーションに付与されている必要があります。権限の指定の詳細は、「システム権限の設定」を参照してください。

次に、プログラムによる登録例を示します。

JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();
//get audit service
final AuditService auditService = ctx.getServiceInstance(AuditService.class);

//create an audit registration instance
final AuditRegistration auditReg = new SampleRegistration();

//call API to register audit event definition
AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {
public Object run() throws AuditException, IOException {
auditService.register(auditReg);
return null;
}
});

登録により、データベースから監査レコードを問い合せるためのデータベース・ビューが作成されます。ビューの作成を管理するロジックまたはその機能を無効にするロジックを追加するには、AuditRegistrationを拡張するoracle.security.jps.service.audit.AuditRegistrationExtインタフェースを実装します。

SampleRegistration.java
class SampleRegistration implements AuditRegistrationExt {
/*
methods from Audit Registration go here
*/
public AuditRegistrationExt.TYPE getIAUViewSupportType() {
// add app specific logic here to determine the type
return AuditRegistrationExt.TYPE.<type>;  // where type is SIMPLE, INDEXABLE, DISABLE
}
}

22.3.3 WLSTコマンドを使用した登録

アプリケーションを監査に登録するには、registerAudit WebLogic Scripting Tool (WLST)コマンドを使用します。このコマンドでは、登録を使用して監査ビューを作成することもできます。

registerAudit(xmlFile, [xlfFile], componentType, [mode=OVERWRITE|UPGRADE], [createView=SIMPLE|INDEXABLE|DISABLE])

SIMPLEは、createViewに値が入力されなかった場合のデフォルトです。

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のregisterAuditに関する項を参照してください。

22.3.4 監査アーティファクト用ドメイン拡張テンプレートの使用

ドメインの作成時または拡張時、アプリケーションではセキュリティ・ストア内のアプリケーション固有のセキュリティ・データのシードを指定できます。アーティファクトのシードの詳細は、第7.1項「セキュリティ・アーティファクトのシード方法」を参照してください。

Java EEアプリケーションは、component_events.xmlファイルとcomponent_events_xlf.jarファイルを含むドメイン拡張テンプレートを使用して監査に登録できます。アプリケーションのデプロイ時に、監査登録によってファイルは自動的に処理されます。テンプレートに含まれるファイルの詳細は、第7.4項「階層型コンポーネントのセキュリティ・アーティファクト」を参照してください。

22.4 プログラムによるポリシーの管理

OFM監査フレームワークでは、監査データの問合せ、プログラムによる監査ポリシーの取得および設定が可能です。まず、次のメソッドを使用してAuditServiceインスタンスを取得します。

AuditService auditService = JpsContextFactory.getContextFactory().getContext().getServiceInstance(AuditService.class);
AuditAdminService auditAdminService = auditService.getAdminService();

次の各項では、このインスタンスを使用した監査データの問合せ方法と表示方法について説明します。

- 監査データの問合せ

- 監査ポリシーの表示と設定

22.4.1 監査データの問合せ

監査データを問い合せるには、次のメソッドのいずれかを使用します。

Set<String> getComponentNames() throws AuditException;
Map<String, ? extends AttributeGroup> getGenericAttributeGroups() throws AuditException;
Collection<? extends EventCategory> getSystemEvents() throws AuditException;
ComponentDefinition getComponentDef(String componentType) throws AuditException;
AttributesDatabaseMap getAttributesMap(String componentType) throws AuditException;
AttributesDatabaseMap getSystemAttributesMap() throws AuditException;

次の例では、監査データを問い合せる方法を示しています。

//search events and attributes for a component
Set<String> components = auditAdminService.getComponentNames();
for (String componentType : components) {
ComponentDefinition componentDef = auditAdminService.getComponentDef(componentType);
//get attributes of a component
AttributeGroup attrGroup = componentDef.getAttributes();
for (AuditAttribute attr : attrGroup.getAttributes()) {
AuditAttribute.DataType type = attr.getAttributeType();
String attrName = attr.getName();
}
//get events of a component
Collection<? extends EventCategory> events = componentDef.getEvents();
for (EventCategory category : events) {
if (category.isComponentSpecific()) { // isComponentSpecific() is true means the category is belong to a component, otherwise is system category
Collection<? extends Event> categoryEvents = category.getAllEvents();

}
}
}

22.4.2 監査ポリシーの表示と設定

監査ポリシーを取得して設定するには、次のメソッドを使用します。

AuditPolicy getAuditPolicy(String componentType) throws AuditException;
void setAuditPolicy(String componentType, AuditPolicy auditPolicy) throws AuditException;

次の例では、これらのメソッドを使用してコンポーネントの監査ポリシーを取得して設定する方法を示します。

//get runtime policy for component JPS
final String componentType = "JPS";
AuditPolicy policy = auditAdminService.getAuditPolicy(componentType);
String filterLevel = policy.getFilterLevel();

//set runtim policy for component JPS
final AuditPolicy newPolicy = new AuditPolicy("None", null, null);
//setAuditPolicy() requires AuditStoreAccessPermission(<componentType>, "modify");
AccessController.doPrivileged(new PrivilegedExceptionAction<Object>(){
public Object run() throws AuditException {
auditAdminService.setAuditPolicy(componentType, newPolicy);
return null;
}
});

22.5 プログラムによる監査イベントのロギング

次の各項では、アプリケーションでOFM監査フレームワークを使用してプログラムで監査にアクセスし、独自の監査イベントを生成できる方法を示します。

- OFM監査フレームワークのインタフェース

- システム権限の設定

- オーディタ・インスタンスの取得

22.5.1 OFM監査フレームワークのインタフェース

OFM監査フレームワークには次のクラスおよびインタフェースが用意されています。

Interface AuditService {
Auditor getAuditor(String componentType);
void register(AuditRegistration auditRegistration);
void unregister(AuditRegistration auditRegistration);
}
Interface Auditor {
boolean log(AuditEvent ev);
boolean isEnabled();
boolean isEnabled(String categoryName, String eventType, boolean eventStatus, Map<String, Object> properties);
}
public class oracle.security.jps.service.audit.AuditEvent {
public AuditEvent(AuditContext ctx, String eventType,
String eventCategory, boolean eventStatus, String messageText);
public void setApplicationName(String applicationName)   public void setAttribute(String attributeName, Object attributeValue)   public void setAttributeBoolean(String attributeName, boolean attributeValue)   public void setAttributeBoolean(String attributeName, Boolean attributeValue)   public void setAttributeBooleans(String attributeName, boolean[] values)   public void setAttributeByteArray(String attributeName, byte[] attributeValue)   public void setAttributeDate(String attributeName, Date attributeValue)   public void setAttributeDates(String attributeName, Date[] values)   public void setAttributeDouble(String attributeName, double attributeValue)   public void setAttributeDoubles(String attributeName, double[] values)   public void setAttributeFloat(String attributeName, float attributeValue)   public void setAttributeFloats(String attributeName, float[] values)   public void setAttributeInt(String attributeName, int attributeValue)   public void setAttributeInts(String attributeName, int[] values)   public void setAttributeLong(String attributeName, long attributeValue)   public void setAttributeLongs(String attributeName, long[] values)   public void setAttributeString(String attributeName, String attributeValue)   public void setAttributeStrings(String attributeName, String[] values)   public void setComponentName(String componentName)   public void setComponentType(String componentType)   public void setContextFields(String contextFields)   public void setECID(String ecid)   public void setEventCategory(String category)   public void setEventDefinition(Object eventDefinition)   public void setEventStatus(boolean status)   public void setEventTimestamp(long eventTimestamp)   public void setEventType(String eventType)   public void setFailureCode(String failureCode)   public void setHostId(String hostId)   public void setHostNetworkAddr(String hostNetworkAddr)   public void setInitiator(String initiator)   public void setInstanceId(String instanceId)   public void setMessageText(String messageText)   public void setModuleId(String moduleId)   public void setOracleHome(String oracleHome)   public void setOracleInstance(String oracleInstance)   public void setProcessId(String processId)   public void setRemoteIP(String value)              public void setResource(String value)             public void setRID(String rid)             public void setRoles(String value)            public void setTarget(String value)           public void setTargetComponentType(String targetComponentType)            public void setThreadId(String threadId)   public void setTransactionId(String transactionId)
}

パーミッションを設定し、オーディタ・インスタンスを取得するには、「システム権限の設定」および「オーディタ・インスタンスの取得」を参照してください。

22.5.2 システム権限の設定

アプリケーションには、OFM監査フレームワークに用意されているメソッドを使用するためのAuditStoreAccessPermissionパーミッションが必要です。この例では、権限付与によりMyAppアプリケーションのAccessController.doPrivilegedブロックでauditService.getAuditorメソッドをコールできます。

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/MyApp${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.audit.AuditStoreAccessPermission</class>
<name>comp1</name>
<actions>action1,action2,action3</actions>
</permission>
</permissions>
</grant>

<actions>は、アプリケーションで実行できるアクションのカンマ区切りリストです。次の表に、使用可能なアクションを示します。

アクション

クライアントへの認可

作成

新しい監査コンポーネントを登録するためのAuditService.registerのコール。

アップグレード

コンポーネント・イベント定義をアップグレードするためのAuditService.registerのコール。

削除

監査コンポーネントを登録解除するためのAuditService.unregisterのコール。

読取り

コンポーネント・オーディタのインスタンスを取得するためのAuditService.getAuditorのコール。

変更

監査ポリシーを変更するためのAuditAdminService.setAuditPolicyのコール。

22.5.3 監査インスタンスの取得

アプリケーションを監査に登録すると、プログラムでオーディタ・インスタンスを取得できます。

//Gets audit service instance
final AuditService auditService = JpsServiceLocator.getServiceLocator().lookup(AuditService.class);

//Gets Auditor instance for application 'MyApp'
Auditor auditor = AccessController.doPrivileged(
new PrivilegedExceptionAction<Auditor>() {
public Auditor run() throws AuditException {
return auditService.getAuditor("MyApp");
}
});

final String category = "Transaction";
final String eventName = "deposit";

//Check if event 'deposit' is enabled in filtering.
boolean enabled = auditor.isEnabled(category, eventName, "true", null);
if (enabled) {
AuditContext ctx = new AuditContext();
String message = "deposit transaction";
//Creates an audit event
AuditEvent ev = new AuditEvent(ctx, eventName, category, "true", message);

//Sets event attributes
ev.setInitiator("johnsmith");
ev.setAttributeInt("accounting:AccountNumber", 2134567);
ev.setAttributeDate("accounting:Date", new Date());
ev.setAttributeFloat("accounting:Amount", 100.00);

//Logs audit event
boolean ret = auditor.log(event);
}

22.6 監査定義の更新と保守

アプリケーションの監査要件の変化に応じて通常、その変化を反映するように監査定義を更新します。具体的には、次のようにします。

1. 監査ファイル定義を更新します。バージョンの詳細は、第13.7項「マッピングとバージョン・ルールについて」を参照してください。

2. 更新されたイベント定義ファイルとともにアプリケーションEARファイルを再デプロイします。あるいは、新しいバージョンについて監査登録に通知します。

3. 変更を検証します。

注意:
WebLogic Serverドメインを作成または拡張する際に、ドメイン・テンプレートに監査アーティファクトを指定して、監査定義アップグレードを簡単にすることができます。コンポーネント・テンプレートに含まれるファイルの詳細は、第7.4項「階層型コンポーネントのセキュリティ・アーティファクト」を参照してください。

23 OPSSを使用するためのJava EEアプリケーションの構成

この章では、OPSSを使用するがOracle Application Development Framework (Oracle ADF)セキュリティを使用しないJava EEアプリケーションにお薦めの構成およびパッケージ化について説明します。

この章では、次の各項についても説明します。

- Java EEアプリケーションでの認証について

- Java EEアプリケーションでの認証の開発

- フィルタおよびインターセプタの構成

- エンタープライズ・グループとエンタープライズ・ユーザーに適したクラスの選択

- Java EEアプリケーションの手動によるパッケージ化

- OPSSを使用するためのJava EEアプリケーションの構成

次のセキュリティ関連のファイルは、開発、デプロイおよび実行時にJava EEアプリケーションで関係します。

- DOMAIN_HOME/config/fmwconfig/jps-config.xml

- DOMAIN_HOME/config/fmwconfig/system-jazn-data.xml

- jazn-data.xml (アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルにパッケージ化)

- cwallet.sso (アプリケーションEARファイルにパッケージ化)

- web.xml (アプリケーションEARファイルにパッケージ化)

- weblogic-application.xml (アプリケーションEARファイルにパッケージ化)

関連項目:

第24章「OPSSを使用するためのJava SEアプリケーションの構成」

第6.1項「Oracle ADFアプリケーションの開発」

第16.7項「Oracle ADFアプリケーションの保護」

第G.1項「OPSS APIリファレンス」

23.1 Java EEアプリケーションでの認証について

次の各トピックには、Java EEアプリケーションでの認証の開発に関する情報が記載されています。

- 『Oracle WebLogic Serverセキュリティの理解』の認証に関する項

- 『WebLogicセキュリティ・サービスによるアプリケーションの開発』の次の各項

- 「Webアプリケーションの保護」

- JavaクライアントでのJAAS認証の使用

- JavaクライアントでのSSL認証の使用

- JAAS認証の開発環境

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』

- 「認証プロバイダ」

- 「アイデンティティ・アサーション・プロバイダ」

- 「サーブレット認証フィルタ」

- カスタム認証プロバイダの開発方法

- ログイン・モジュールに関する項

23.2 Java EEアプリケーションでの認証の開発

OPSSログイン・モジュールは、Java EEアプリケーションおよびJava SEアプリケーションでのプログラムによるユーザー認証とアサーションをサポートしており、このログイン・モジュールのコールに使用するAPIはJava EEアプリケーションとJava SEアプリケーションの両方に共通します。Oracle WebLogic Serverは、WebLogic Serverセキュリティ・プロバイダにユーザー認証とアサーションを委託します。

関連項目:

Oracle WebLogic Serverのセキュリティ・プロバイダの開発

第24.3.2項「Javaアプリケーションでのログイン・モジュールの使用」

23.3 フィルタおよびインターセプタの構成

この項で説明している構成は、Oracle JDeveloperの外で(OPSSと統合されている) Java EEアプリケーションをパッケージ化または構成する場合にのみ必要です。

OPSSでは、Javaサーブレット用にJpsFilterフィルタが、Enterprise JavaBeans (EJB)用にJpsInterceptorインターセプタが用意されています。フィルタは、Webアプリケーション・アーカイブ(WAR)ファイルにパックされるweb.xmlファイルで構成します。インターセプタは、JARファイルにパックされるejb-jar.xmlファイルで構成します。

OPSSには、web.xmlファイルで、アプリケーションMBeanがアクセスするストライプを構成する手段も用意されています。

すぐに使用できる状態では、フィルタはデフォルトのパラメータ値で設定されているため、デプロイメント記述子で構成する必要はありません。しかし、デフォルト値とは異なる値が必要な場合は、手動で構成する必要があります。インターセプタは手動で構成する必要があります。

フィルタおよびインターセプタの構成に使用するパラメータの説明は、次の各項を参照してください。

- アプリケーション・ストライプの設定

- アプリケーション・ロールのサポートの設定

- 匿名ユーザーとロールの設定

- 認証ロールのサポートの設定

- JAASモードの設定

関連項目:

第2.5項「匿名ユーザーとロールについて」

第2.4項「認証ロールについて」

「インターセプタ構成要件」

「フィルタおよびインターセプタのパラメータの概要」

23.3.1 アプリケーション・ストライプの設定

アプリケーション・ストライプは、必要に応じてアプリケーションのweb.xmlファイルで指定しますが、適用可能なポリシー・セットを決定するために実行時に使用されます。指定しない場合は、アプリケーションID(アプリケーション名が含まれる)にデフォルト設定されます。

アプリケーション・ストライプを設定するには、application.nameパラメータを使用します。この設定はオプションで、大文字と小文字が区別されます。指定しない場合は、アプリケーションの名前にデフォルト設定されます。

アプリケーション・ストライプを指定するには、web.xmlでfilter要素またはcontext-param要素を構成します。

<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>application.name</param-name>
<param-value>stripeid</param-value>
</init-param>
</filter>

<context-param>
<description>JPS custom stripe id</description>
<param-name>application.name</param-name>
<param-value>stripeid</param-value>
</context-param>

アプリケーションにセキュリティ・ストアにアクセスするアプリケーションMBeanが含まれ、アプリケーションの名前がそのMBeanがアクセスするストライプの名前と異なる場合は、前述と同様にcontext-param構成を使用してストライプ名を指定する必要があります。

その他の例

次の例では、web.xmlでのMyServlet1サーブレットとMyServlet2サーブレットの構成を示します。同じWARファイル内のサーブレットが同じポリシー・ストライプを使用している点に注意してください。

<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>application.name</param-name>
<param-value>MyAppName</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet1</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet2</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

次の例では、ejb-jar.xmlファイルでのMyAppNameアプリケーション・ストライプおよびJpsInterceptorインターセプタの構成と、MyEjbへのそのインターセプタのバインドを示します。

<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>application.name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>MyAppName</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>application_name</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>.

23.3.2 アプリケーション・ロールのサポートの設定

サブジェクトにアプリケーション・ロールを追加するは、add.application.rolesパラメータをtrueに設定します。追加しない場合は、falseに設定します。デフォルト値はtrueです。アプリケーション・ロールのプリンシパル・クラスは、oracle.security.jps.service.policystore.ApplicationRoleクラスです。

23.3.3 匿名ユーザーとロールの設定

匿名ユーザーの使用を有効にするには、enable.anonymousをtrueに設定します。無効にするには、falseに設定します。デフォルト値はtrueです。

サブジェクトから匿名ロールを削除するには、remove.anonymous.roleをtrueに設定します。保持するには、falseに設定します。デフォルト値はfalseです。

匿名ユーザーおよびロールの名前とプリンシパル・クラスは、次のとおりです。

anonymous
oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl
anonymous-role
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl

次の例では、web.xmlファイルでの匿名ユーザーおよびロールの設定と、MyServlet JavaサーブレットによるJpsFilterフィルタの使用方法を示します。

<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>enable.anonymous</param-name>
<param-value>true</param-value>
</init-param>
<init-param>
<param-name>remove.anonymous.role</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

次の例では、ejb-jar.xmlファイルでのremove.anonymous.roleの設定と、MyEjbによるインターセプタの使用方法を示します。

<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>remove.anonymous.role</env-entry-name>
<env-entry-type>java.lang.Boolean</env-entry-type>
<env-entry-value>false</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>remove_anonymous_role/injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>

23.3.4 認証ロールのサポートの設定

サブジェクトに認証ロールを追加するは、add.authenticated.roleプロパティをtrueに設定します。追加しない場合は、falseに設定します。デフォルト値はtrueです。

認証ロールの名前とプリンシパル・クラスは、次のとおりです。

authenticated-role
oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl

次の例では、web.xmlファイルでのadd.authenticated.roleプロパティの構成と、MyServlet JavaサーブレットによるJpsFilterフィルタの使用方法を示します。

<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>add.authenticated.role</param-name>
<param-value>false</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

23.3.5 JAASモードの設定

JAASモードを設定するには、次の値のいずれかを指定してoracle.security.jps.jaas.modeパラメータを使用します。

doAs
doAsPrivileged
off
undefined
subjectOnly

デフォルト値はdoAsPrivilegedです。

次の例では、MyServlet JavaサーブレットによるJpsFilterフィルタの使用方法を示します。

<filter>
<filter-name>JpsFilter</filter-name>
<filter-class>oracle.security.jps.ee.http.JpsFilter</filter-class>
<init-param>
<param-name>oracle.security.jps.jaas.mode</param-name>
<param-value>doAs</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>JpsFilter</filter-name>
<servlet-name>MyServlet</servlet-name>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>

次の例では、doAsの設定とJpsInterceptorインターセプタの使用方法を示します。

<interceptor>
<interceptor-class>oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
<env-entry>
<env-entry-name>oracle.security.jps.jaas.mode</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>doAs</env-entry-value>
<injection-target>
<injection-target-class>
oracle.security.jps.ee.ejb.JpsInterceptor</injection-target-class>
<injection-target-name>oracle_security_jps_jaas_mode
</injection-target-name>
</injection-target>
</env-entry>
</interceptor>
...
<interceptor-binding>
<ejb-name>MyEjb</ejb-name>
<interceptor-class>
oracle.security.jps.ee.ejb.JpsInterceptor</interceptor-class>
</interceptor-binding>

23.3.6 インターセプタ構成要件

次の要件は、JpsInterceptorパラメータの指定すべてに適用されます。

- env-entry-type要素にパラメータ・タイプを指定する必要があります。

- インターセプタのクラスと同じクラス(injection-target-class要素に指定)を特定するinjection-target要素を指定する必要があります。injection-target-name要素には、ドットをアンダースコアに置換した文字列として名前を再度書き込む必要があります。

- インターセプタのクラスを参照することで、EJBへのインターセプタのバインドを指定する必要があります。

23.3.7 フィルタおよびインターセプタのパラメータの概要

次の表に、フィルタおよびインターセプタのパラメータを示します。

表23-1 JpsFilterおよびJpsInterceptorのパラメータ

パラメータ名

値

デフォルト

機能

注意

application.name

任意の有効な文字列。この値では大文字と小文字が区別されます。

アプリケーションの名前。

JavaサーブレットまたはEJBによって使用されるポリシーのサブセットを指定します。

複数のJavaサーブレットまたはEJBで同じポリシーのサブセットにアクセスするかどうかを指定する必要があります。

add.application.roles

trueまたはfalse

true

アプリケーション・ロールをサブジェクトに追加します。

アプリケーション・ロールをサブジェクトに追加しない場合はfalseに設定します。

enable.anonymous

trueまたはfalse

true

サブジェクトで匿名ユーザーを有効にします。

trueの場合、匿名ユーザーおよびロールがサブジェクトに含まれます。

remove.anonymous.role

trueまたはfalse

false

認証後にサブジェクトから匿名ロールを削除します。

Javaサーブレットの場合にのみ使用可能です。EJBの場合、匿名ロールはサブジェクトから削除されます。falseの場合、認証後、匿名ロールがサブジェクトで保持されます。trueの場合、認証後、匿名ロールが削除されます。

add.authenticated.role

trueまたはfalse

true

サブジェクトへの認証ロールの追加を許可します。

認証ロールをサブジェクトに追加しない場合はfalseに設定します。

oracle.security.jps.jaas.mode

doAsPrivileged

doAs

Off

undefined

subjectOnly

doAsPrivileged

JAASモードを設定します。

23.4 エンタープライズ・グループとエンタープライズ・ユーザーに適したクラスの選択

アプリケーション・ロールのメンバーに指定するクラスは、アプリケーション・ロールのクラスまたは次のいずれかにする必要があります。

weblogic.security.principal.WLSUserImpl
weblogic.security.principal.WLSGroupImpl

次の例では、ロールの指定でのApplicationRoleクラスとWLSGroupImplクラスの使用方法を示します。

<app-role>
<name>app_monitor</name>
<display-name>application role monitor</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>app_operator</name>
</member>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>Developers</name>
</member>
</members>
</app-role>

アプリケーション・ロール名では、大文字と小文字は区別されません。エンタープライズ・ユーザーおよびグループの名前では、大文字と小文字が区別されます。

関連項目:

第J.5.2項「パーミッションの取得の失敗 - 大文字と小文字の不一致」

23.5 Java EEアプリケーションの手動によるパッケージ化

この項では、カスタムのポリシーおよび資格証明を使用するJavaサーブレットおよびEJBのパッケージ化要件について説明します。

アプリケーション・ポリシーは、jazn-data.xmlファイルで定義します。このファイルをアプリケーションに含めるためにサポートされている唯一の方法は、アプリケーションEARファイルのMETA-INFディレクトリにパッケージ化することです。

Javaサーブレットは、web.xml構成ファイルが含まれるWARファイルにパッケージ化されます。EJBは、ejb-jar.xml構成ファイルが含まれるWARファイルにパッケージ化されます。WARファイルでは、フィルタ(サーブレットの場合)またはインターセプタ(EJBの場合)の構成を対応する構成ファイルに含める必要があります。

次のパッケージ要件は、web.xmlファイルでのJavaサーブレットとフィルタの構成について述べていますが、ejb-jar.xmlファイルでのEJBとインターセプタの構成にも適用されます。

- アプリケーションは、1つのEARファイルにパッケージ化する必要があります。

- EARファイルには、アプリケーションのポリシーおよびロールを指定するMETA-INF/jazn-data.xmlファイルが1つのみ含まれている必要があります。

- EARファイルには、1つ以上のWARファイルを含めることができます。

- EARファイル内の各WARファイルまたはJARファイルには、JpsFilterフィルタを構成するweb.xmlファイルが1つのみ含まれ、このような構成はすべてのEARファイル内で同一である必要があります。

- cwallet.ssoファイル内のコンポーネント資格証明は、EARファイルにパッケージ化できます。

コンポーネントで、他のコンポーネントとは異なるフィルタ構成が必要な場合は、別個のEARファイルにパッケージ化して別々にデプロイする必要があります。

関連項目:

「フィルタおよびインターセプタの構成」

23.5.1 アプリケーションとのポリシーのパッケージ化

アプリケーション・ポリシーは、jazn-data.xmlファイルで定義します。このファイルをアプリケーションに含めるためにサポートされている唯一の方法は、アプリケーションEARファイルのMETA-INFディレクトリにパッケージ化することです。

WARファイルで1つのコンポーネントに対して特定のポリシーを指定するには、そのコンポーネントを独自のjazn-data.xmlファイルとともに別個のEARファイルにパッケージ化する必要があります。他のポリシー・パッケージの組合せはサポートされていないため、jazn-data.xml以外のポリシー・ファイルは無視されます。

23.5.2 アプリケーションとの資格証明のパッケージ化

アプリケーション資格証明は、cwallet.ssoファイルで定義します。このファイルをアプリケーションに含めるためにサポートされている唯一の方法は、アプリケーションEARファイルのMETA-INFディレクトリにパッケージ化することです。

WARファイルで1つのコンポーネントに対して特定の資格証明を指定するには、そのコンポーネントを独自のcwallet.ssoファイルとともに別個のEARファイルにパッケージ化する必要があります。他の資格証明パッケージの組合せはサポートされていないため、cwallet.ssoファイル以外の資格証明ファイルは無視されます。

23.6 OPSSを使用するためのJava EEアプリケーションの構成

次の各項では、アプリケーションのデプロイ時にJava EEアプリケーションとともにパッケージ化されるポリシーおよび資格証明の移行の制御方法について説明します。

- ポリシーの移行の制御

- 動作に応じたポリシーの移行の構成

- 資格情報の移行の制御

- 動作に応じた資格証明の移行の構成

- ファイル資格証明ストアの使用

- サポートされているパーミッション・クラスの使用

- ブートストラップ資格証明の手動による指定

関連項目:

第6.6.1.1項「migrateSecurityStoreを使用したアイデンティティの移行」

23.6.1 ポリシーの移行の制御

デプロイ時のアプリケーション・ポリシーの移行は、META-INF/weblogic-application.xmlファイルで指定するパラメータを使用して制御します。Fusion Middleware Controlを使用してアプリケーションを管理しない場合は、このような構成を手動で入力する必要があります。

システム・プロパティjps.deployment.handler.disabledをtrueに設定し、weblogic-application.xmlファイルでの個別の設定に関係なく、すべてのアプリケーションに対してデプロイ時のポリシーおよび資格証明の移行を無効にします。

管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ポリシーおよび資格証明が含まれているアプリケーションをデプロイする場合は、管理対象サーバーと管理サーバーによって管理されているデータが最終的に同期しないため、ライフ・サイクル・リスナーを使用してデプロイ時の移行を制御しないでください。かわりに、migrateSecurityStoreコマンドを使用して、ポリシーおよび資格証明をセキュリティ・ストアに移行します。

ポリシーの移行および削除を構成するパラメータは、次のとおりです。

- 移行

- jps.policystore.migration

- jps.apppolicy.idstoreartifact.migration

- jps.policystore.removal

- リスナー

- JpsApplicationLifecycleListener

- プリンシパルの検証

- jps.policystore.migration.validate.principal

- 移行のターゲット(アプリケーション・ストライプ)

- jps.policystore.applicationid

関連項目:

第6.2.1項「Fusion Middleware Controlを使用したセキュア・アプリケーションのデプロイ」

23.6.1.1 jps.policystore.migration

次の例で構成されているこのパラメータでは、セキュリティ・ストアにポリシーを移行してマージするのか、上書きするのかを指定します。

<wls:application-param>
<wls:param-name>jps.policystore.migration</wls:param-name>
<wls:param-value>Option</wls:param-value>
</wls:application-param>

Optionは、MERGE、OVERWRITEまたはOFFを表します。

移行しない場合は、OFFに設定します。ポリシーをマージして移行する場合は、MERGEに設定します。ターゲット・ストアでポリシーを上書きして移行する場合は、OVERWRITEに設定します。デフォルト値はMERGEです。

23.6.1.2 jps.policystore.applicationid

次の例で構成されているこのパラメータでは、ポリシーの移行先であるターゲット・ストライプを指定します。

<wls:application-param>
<wls:param-name>jps.policystore.applicationid</wls:param-name>
<wls:param-value>myApplicationStripe</wls:param-value>
</wls:application-param>

値には、有効な任意の文字列を指定できます。指定しない場合は、WebLogic Serverにより、application_name#version形式を使用してアプリケーション名およびバージョンに基づいてストライプ名が作成されます。

このパラメータの値は、JpsFilterフィルタ用に(web.xmlで)またはJpsInterceptorインスペクタ用に(ejb-jar.xmlで)指定されるapplication.nameパラメータの値に一致する必要があります。

weblogic-application.xmlファイルから読み取られた値はデプロイ時に使用されます。web.xmlファイルまたはejb-jar.xmlファイルから読み取られた値は実行時に使用されます。

23.6.1.3 jps.apppolicy.idstoreartifact.migration

次の例で構成されているこのパラメータでは、エンタープライズ・ユーザーまたはグループへのアプリケーション・ロールのマッピングなど、エンタープライズ・ユーザーまたはグループへの参照の移行を除外するかどうかを指定します。そのため、アプリケーション・ポリシーのみの移行が可能となり、エンタープライズ・ユーザーまたはグループへのアプリケーション・ロールのマッピングは無視されます。

<wls:application-param>
<wls:param-name>jps.apppolicy.idstoreartifact.migration</wls:param-name>
<wls:param-value>Option</wls:param-value>
</wls:application-param>

Optionは、trueまたはfalseを表します。エンタープライズ・ユーザーまたはグループを参照するアーティファクトの移行を除外する場合は、falseに設定します。それ以外の場合は、trueに設定します。指定しない場合は、デフォルトのtrueに設定されます。

注意:
このパラメータをfalseに設定してアプリケーションをデプロイした後、アプリケーションをドメイン内で使用する前に、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)またはOracle WebLogic Server管理コンソールを使用してアプリケーション・ロールをエンタープライズ・グループまたはユーザーにマップします。

次の例では、アプリケーションEARファイルにパッケージ化され、ポリシーが記述されているjazn-data.xmlファイルを示します。system-jazn-data.xmlファイルは、アプリケーション・ポリシーの移行先となるファイル・セキュリティ・ストアを表しています。jps.apppolicy.idstoreartifact.migrationパラメータがfalseであることを前提としています。

<!-- Example 1: app role applicationDeveloperRole in jazn-data.xml that references
the enterprise group developers -->
<app-role>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
</members>
</app-role>

<!-- app role applicationDeveloperRole in system-jazn-data.xml after migration: notice how the role developers has been excluded -->
<app-role>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<guid>CB3633A0D0E811DDBF08952E56E4544A</guid>
<class>weblogic.security.principal.WLSGroupImpl</class>
</app-role>

<!-- Example 2: app role viewerApplicationRole in jazn-data.xml makes reference
to the anonymous role -->
<app-role>
<name>viewerApplicationRole</name>
<display-name>viewerApplicationRole</display-name>
<class>weblogic.security.principal.WLSGroupImpl</class>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
</class>
<name>anonymous-role</name>
</member>
</members>
</app-role>

<!-- app role viewerApplicationRole in system-jazn-data.xml after migration:
notice that references to the anonymous role are never excluded -->
<app-role>
<name>viewerApplicationRole</name>
<display-name>viewerApplicationRole</display-name>
<guid>CB3D86A0D0E811DDBF08952E56E4544A</guid>
<class>weblogic.security.principal.WLSGroupImpl</class>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
</class>
<name>anonymous-role</name>
</member>
</members>
</app-role>

23.6.1.4 jps.policystore.removal

次の例で構成されているこのパラメータでは、アプリケーションのアンデプロイ時にポリシーを削除するかどうかを指定します。

<wls:application-param>
<wls:param-name>jps.policystore.removal</wls:param-name>
<wls:param-value>OFF</wls:param-value>
</wls:application-param>

ポリシーを削除しない場合は、OFFに設定します。設定しない場合、ポリシーは削除されます。デフォルトでは、アプリケーションのアンデプロイ時にポリシーは削除されません。

複数のアプリケーションで同じアプリケーション・ストライプを共有し、その中の1つをアンデプロイする場合には、この設定の使用を検討しますが、特定のアプリケーションについてjps.plicystore.ramovalをOFFに設定するには、アプリケーションのデプロイ時に、アプリケーション・ストライプを他のアプリケーションと共有して使用するかどうか把握しておく必要があります。

23.6.1.5 jps.policystore.migration.validate.principal

次の例で構成されているこのパラメータでは、デプロイ時または再デプロイ時にシステム・ポリシーおよびアプリケーション・ポリシーでプリンシパルをチェックするかどうかを指定します。

<wls:application-param>
<wls:param-name>jps.policystore.migration.validate.principal</wls:param-name>
<wls:param-value>option</wls:param-value>
</wls:application-param>

optionは、trueまたはfalseを表します。

エンタープライズ・ユーザーおよびグループを検証する場合は、trueに設定します。プリンシパルが(アプリケーション・ポリシーまたはシステム・ポリシーで)アイデンティティ・ストアにないエンタープライズ・ユーザーまたはグループを参照している場合、警告がログに記録され、続行されます。チェックをスキップする場合は、falseに設定します。指定しない場合は、デフォルトのfalseに設定されます。検証の警告は、サーバー・ログに記録されます。

23.6.1.6 JpsApplicationLifecycleListener

次の例で構成されているこのパラメータでは、リスナー・クラスを指定します。

<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>

23.6.2 動作に応じたポリシーの移行の構成

次の各項では、推奨事項と一般的なシナリオで必要な設定について説明します。

- 推奨事項

- ポリシーの移行のスキップ

- マージによるポリシーの移行

- 上書きによるポリシーの移行

- ポリシーを削除または削除しない

- 静的デプロイメントでのポリシーの移行

23.6.2.1 推奨事項

次の推奨事項は、ポリシーと資格証明の両方の移行に適用されます。

次の各項で説明されていない値の設定はお薦めしません。

アプリケーションを複数の管理対象サーバーにデプロイする場合は、それらのサーバーの1つにデプロイする際にのみ、移行することを選択します。残りのデプロイでは、ポリシーおよび資格証明を移行しないことを選択します。これにより、ポリシーおよび資格証明は確実にアプリケーション・ストアからストアに1回のみ移行されます。すべてのデプロイで、同じアプリケーションIDを使用する必要があります。

デプロイ時にセキュリティ・データを移行する代替方法として、migrateSecurityStore WLSTコマンドを使用してポリシーおよび資格証明を移行することもできます。このコマンドの詳細は、第9.5.2項「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。

アプリケーションでポリシーおよび資格証明がパッケージ化され、複数のサーバーにデプロイされる場合、$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlポリシー・ファイルが更新されるように管理サーバーを含める必要があります。

23.6.2.2 ポリシーの移行のスキップ

次の表に、移行をスキップするための設定を示します。

表23-2 ポリシーの移行をスキップするための設定

デプロイ時にまたは再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OFF

ドメイン・ポリシーをそのまま保持する場合はポリシーの移行をスキップしますが、初めてアプリケーションをデプロイする場合はポリシーを移行します。

23.6.2.3 マージによるポリシーの移行

次の表に、ターゲット・ストアにないポリシーのみを移行するための設定を示します。

表23-3 ポリシーをマージして移行するための設定

デプロイ時にまたは再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

MERGE

jps.policystore.applicationid

オプション。デフォルトはJavaサーブレット名またはEJB名です。

jps.apppolicy.idstoreartifact.migration

オプション。エンタープライズ・アーティファクトを参照するポリシーの移行を除外する場合はfalseに設定します。それ以外の場合は、trueに設定します。デフォルトはtrueです。

jps.policystore.migration.validate.principal

オプション。アプリケーションおよびシステム・ポリシーでエンタープライズ・ユーザーおよびロールを検証する場合は、trueに設定します。それ以外の場合は、falseに設定します。指定しない場合は、デフォルトのfalseに設定されます。

ポリシーが(前回のアンデプロイから)変更されるか、新しいポリシーを追加する場合は、再デプロイ時にマージによるポリシーの移行を選択します。

23.6.2.4 上書きによるポリシーの移行

次の表に、一致するターゲット・ポリシーを上書きしてポリシーをすべて移行するための設定を示します。

表23-4 上書きによりポリシーを移行するための設定

デプロイ時にまたは再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OVERWRITE

jps.policystore.migration.validate.principal

オプション。アプリケーションおよびシステム・ポリシーでエンタープライズ・ユーザーおよびロールを検証する場合は、trueに設定します。それ以外の場合は、falseに設定します。指定しない場合は、デフォルトのfalseに設定されます。

すべてのポリシーを新しいポリシーで置き換える場合は、再デプロイ時に上書きによるポリシーの移行を選択します。

23.6.2.5 ポリシーを削除または削除しない

アンデプロイ時にはアプリケーション・ポリシーのみを削除できます。システム・ポリシーは削除されません。次の表に、アンデプロイ時にアプリケーション・ポリシーを削除するための設定を示します。

表23-5 ポリシーを削除するための設定

アンデプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.removal

設定しない(デフォルト)

アンデプロイ時にポリシーが削除されるストライプは、デプロイ時または再デプロイ時に指定したストライプによって決まります。元のものとは異なるストライプを指定してアプリケーションを再デプロイすると、元のストライプのポリシーは削除されません。

次の表に、アプリケーションのアンデプロイ時にポリシーの削除を無効にするための設定を示します。

表23-6 ポリシーの削除を無効にするための設定

アンデプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.removal

OFF

削除されるデータと削除されないデータ

ポリシーを自動的に移行および削除するように構成されているmyAppアプリケーションを考えてみます。次の(アプリケーションのjazn-data.xmlファイルの)例では、アプリケーションのデプロイ時に移行されるポリシーとアプリケーションのアンデプロイ時に削除されないポリシーを示します。

<jazn-data>
<policy-store>
<applications>
<!-- The contents of the following element application is migrated
to the element policy-store in domain system-jazn-data.xml;
when myApp is undeployed with EM, it is removed from security store -->
<application>
<name>myApp</name>
<app-roles>
<app-role>
<class>oracle.security.jps.service.policystore.SomeRole</class>
<name>applicationDeveloperRole</name>
<display-name>application role applicationDeveloperRole</display-name>
<members>
<member>
<class>oracle.security.somePath.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>applicationDeveloperRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>loadPolicy</name>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>

<jazn-policy>
<!-- The following codesource grant is migrated to the element
jazn-policy in domain system-jazn-data.xml; when myApp is undeployed
with FMC, it is not removed from security store -->
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/Foo.ear/-</url>
</codesource>
</grantee>
<permissions>
<permission>               <class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<name>context=SYSTEM,mapName=*,keyName=*</name>
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</jazn-data>

23.6.2.6 静的デプロイメントでのポリシーの移行

次の表に、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーを移行するための設定を示します。MERGEまたはOVERWRITEの操作は、アプリケーション・ポリシーがセキュリティ・ストアにまだ存在していない場合にのみ実行されます。

表23-7 静的デプロイメントでポリシーを移行するための設定

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

MERGEまたはOVERWRITE

次の表に、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーの移行をスキップするための設定を示します。

表23-8 静的デプロイメントでポリシーを移行しないための設定

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OFF

23.6.3 ファイル資格証明ストアの使用

ファイル資格証明ストアはcwallet.ssoファイルです。このファイルの場所は、jps-config.xmlファイルで<serviceInstance>要素を使用して指定します。

<serviceInstance name="credstore" provider="credstoressp">
<property name="location"  value="myCredStorePath"/>
</serviceInstance>

関連項目:

『Oracle Fusion Middlewareの管理』の一般的なウォレットの操作に関する項

『Oracle Fusion Middlewareの管理』の「キーストア、ウォレットおよび証明書の管理」

23.6.4 資格証明の移行の制御

デプロイ時のアプリケーション資格証明の移行は、META-INF/weblogic-application.xmlファイルで指定するパラメータを使用して制御します。Fusion Middleware Controlを使用してアプリケーションを管理しない場合は、このような構成を手動で入力する必要があります。

システム・プロパティjps.deployment.handler.disabledをtrueに設定し、weblogic-application.xmlアプリケーション・ファイルの設定に関係なく、すべてのアプリケーションに対してデプロイ時のポリシーおよび資格証明の移行を無効にします。

管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ポリシーおよび資格証明がパッケージ化されているアプリケーションをデプロイする場合は、管理対象サーバーと管理サーバーによって管理されているデータが最終的に同期しないため、ライフ・サイクル・リスナーを使用してデプロイ時の移行を制御しないでください。かわりに、migrateSecurityStoreコマンドを使用して、ポリシーおよび資格証明をセキュリティ・ストアに移行します。このコマンドの詳細は、第9.5.2項「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。

資格証明の移行および削除を構成するパラメータは、次のとおりです。

- jps.credstore.migration

- JpsApplicationLifecycleListener

23.6.4.1 jps.credstore.migration

次の例で構成されているこのパラメータでは、セキュリティ・ストアで資格証明を移行してマージするのか、上書きするのかを指定します。

<wls:application-param>
<wls:param-name>jps.credstore.migration</wls:param-name>
<wls:param-value>Option</wls:param-value>
</wls:application-param>

Optionは、MERGE、OVERWRITEまたはOFFを表します。

移行しない場合は、OFFに設定します。資格証明をマージして移行する場合は、MERGEに設定します。資格証明を上書きして移行する場合は、OVERWRITEに設定します。デフォルト値はMERGEです。

23.6.5 動作に応じた資格証明の移行の構成

次の各項では、推奨事項と一般的なシナリオで必要な設定について説明します。

- 推奨事項

- 資格証明の移行のスキップ

- マージによる資格証明の移行

- 上書きによる資格証明の移行

アプリケーションのアンデプロイ時に、アプリケーション資格証明は削除されません。

23.6.5.1 資格証明の移行のスキップ

次の表に、移行しないための設定を示します。

表23-9 資格証明の移行をスキップするための設定

デプロイ時にまたは再デプロイ時に有効

jps.credstore.migration

OFF

23.6.5.2 マージによる資格証明の移行

次の表に、ターゲット・ストアにない資格証明のみの移行に必要な設定を示します。

表23-10 マージにより資格証明を移行するための設定

デプロイ時にまたは再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.credstore.migration

MERGE

23.6.5.3 上書きによる資格証明の移行

次の表に、ターゲットの資格証明を上書きして資格証明をすべて移行するための設定を示します。

表23-11 上書きにより資格証明を移行するための設定

デプロイ時にまたは再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.credstore.migration

OVERWRITE

jps.app.credential.overwrite.allowed

必ずtrueにします。

23.6.6 サポートされているパーミッション・クラスの使用

次の各項では、system-jazn-data.xmlファイルの<permission>要素内の<class>、<name>および<actions>の各要素で使用する値について説明します。

- セキュリティ・ストアのパーミッション・クラス

- 資格証明ストアのパーミッション・クラス

- 汎用パーミッション・クラス

ポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。

23.6.6.1 セキュリティ・ストアのパーミッション・クラス

セキュリティ・ストアのパーミッション・クラスは、次のとおりです。

oracle.security.jps.service.policystore.PolicyStoreAccessPermission

特定のアプリケーションにパーミッションが適用される場合は、対応するname要素に対して次のパターンを使用します。appStripeNameでは、特定のアプリケーションを指定します。

context=APPLICATION,name=appStripeName

パーミッションがすべてのアプリケーションに適用される場合、次の名前パターンを使用します。

context=APPLICATION,name=*

パーミッションがすべてのアプリケーションおよびシステム・ポリシーに適用される場合、次の名前パターンを使用します。

context=SYTEM

actions要素で使用できる値は、次のとおりです(*は任意のアクションを表します)。

*
createPolicy
getConfiguredApplications
getSystemPolicy
getApplicationPolicy
createApplicationPolicy
deleteApplicationPolicy
grant
revoke
createAppRole
alterAppRole
removeAppRole
addPrincipalToAppRole
removePrincipalFromAppRole
hasPermission
containsAppRole

次の例では、ポリシーを作成する権限付与と実行時チェックを実行する権限付与を示します。

grant {
permission oracle.security.jps.service.policystore.PolicyStoreAccessPermission
"context=APPLICATION,name=*", "*";
permission oracle.security.jps.service.policystore.PolicyStoreAccessPermission
"context=SYSTEM,adminresource=ApplicationPolicy,instancename=*", "*"; oracle.security.jps.JpsPermission "AppSecurityContext.setApplicationID.*";
};

grant codebase "file:${opss.lib.location}/-" { permission java.security.AllPermission;
};

23.6.6.2 資格証明ストアのパーミッション・クラス

資格証明ストアのパーミッション・クラスは、oracle.security.jps.service.credstore.CredentialAccessPermissionクラスです。

マップとそのマップ内の特定のキーにパーミッションが適用される場合は、対応するname要素に対して次のパターンを使用します。myMapおよびmyKeyでは、特定の資格証明を指定します。

context=SYSTEM,mapName=myMap,keyName=myKey

マップとそのマップ内のすべてのキーにパーミッションが適用される場合は、次のパターンを使用します。myMapでは、特定のマップを指定します。

context=SYSTEM,mapName=myMap,keyName=*

actions要素で使用できる値は、次のとおりです(*は任意のアクションを表します)。

*
read
write
update
delete

23.6.6.3 汎用パーミッション・クラス

汎用パーミッション・クラスは、oracle.security.jps.JpsPermissionクラスです。

oracle.security.jps.callback.IdentityCallbackコールバック・インスタンスによって実行されたアサーションにパーミッションが適用される場合は、対応する<name>要素に対して次のパターンを使用します。

IdentityAssertion

actions要素で使用できる唯一の値は、executeです。

23.6.7 ブートストラップ資格証明の手動による指定

ドメイン・リポジトリへの接続およびアクセスに必要な資格証明は、cwallet.ssoファイルに指定し、jps-config.xmlファイルで構成します。このような資格証明は、ブートストラップ資格証明と呼ばれ、常にファイルで保持されます。

ブートストラップ資格証明は、bootstrap_credstore_contextというコンテキストで構成されます。

<serviceInstances>
...
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>
...
</serviceInstances>

<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>

cwallet.ssoファイルは、bootstrapディレクトリにあることを前提としています。

bootstrap.security.principal.keyプロパティとbootstrap.security.principal.mapプロパティでは、ブートストラップのマップおよびキーを指定します。

<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
...
<property value="bootstrapKey" name="bootstrap.security.principal.key"/>
...
</serviceInstance>

bootstrap.security.principal.mapプロパティを指定しないと、デフォルトのBOOTSTRAP_JPSに設定されます。

ブートストラップ資格証明を変更または追加するには、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のmodifyBootStrapCredentialに関する項およびaddBootStrapCredentialに関する項を参照してください。

24 OPSSを使用するためのJava SEアプリケーションの構成

この章では、Java SEアプリケーションでOPSSを使用して認証、認可および監査を使用する方法について説明します。

この章の内容は次のとおりです。

- Java SEアプリケーションでのOPSSの使用

- Java SEアプリケーションでのセキュリティ・サービスの実装

- Java SEアプリケーションでの認証

- Java SEアプリケーションでの認可

- Java SEアプリケーションでの監査

関連項目:

第23章「OPSSを使用するためのJava EEアプリケーションの構成」

24.1 Java SEアプリケーションでのOPSSの使用

Java SEアプリケーションでOPSSを使用するには、次のようにします。

- jps-manifest.jarファイルをクラスパスに挿入します。

- 初期化の際に、JpsStartup.startをコールします。

- 次のプロパティを設定します。

- oracle.security.jps.config: jps-config-jse.xmlファイルへのファイル・パス。

- common.components.home: oracle_commonディレクトリへのパス。

- java.security.policy: java.policyファイルへのパス。

- opss.audit.logDirectory: 監査によってアプリケーションに関するレコードが書き込まれる、書込み可能なディレクトリへのパス。

- -Djava.security.policyを、(wl_home/server/libディレクトリにある)Oracle WebLogic Serverのweblogic.policyポリシー・ファイルの場所に設定します。

- OPSS AppSecurityContextクラスを使用し、必要な関連する権限付与を書き留めます。

String appID = AppSecurityContext.getApplicationID();
try {
setApplicationID(appName);
.....
} finally {
setApplicationID(appID );
}
}
private static void setApplicationID(final String applicationID) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run() {
AppSecurityContext.setApplicationID(applicationID);
return null;
}
});
}

AppSecurityContext.setApplicationIDコールでは、jps-config-jse.xmlに次のようなコードソース・パーミッションを挿入する必要があります。

<grant>
<grantee>
<codesource>
<url>myJavaSEapp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>AppSecurityContext.setApplicationID.myAppStripeID</name>
</permission>
</permissions>
</grant>

関連項目:

「JpsStartupクラス」

第9章「セキュリティ・ストアの構成」

第F.1項「OPSSシステム・プロパティ」

24.1.1 JpsStartupクラス

次の各項では、JpsStartupクラスの状態、ランタイム・オプションおよび使用例について説明します。

- JpsStartup.startの状態

- JpsStartupのコンストラクタ

- JpsStartupのランタイム・オプション

- OPSS起動例

関連項目:

『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』

24.1.1.1 JpsStartup.start状態

JpsStartup.startメソッドの遷移状態は、次の定数で定義されます。

- UNINITIALIZED - JpsStartup.startをコールする前の状態。

- INITIALIZING - JpsStartup.startがコールされた後、この状態に遷移します。

- FAILURE - INITIALIZING状態でエラーが発生した場合、この状態に遷移します。

- ACTIVE - INITIALIZING状態が正常に完了した場合、この状態に遷移します。

- INACTIVE - JpsStatup.stopメソッドがコールされた後、この状態に遷移します。

JpsStartup.getStateメソッドは、現在のOPSSの状態を返します。

24.1.1.2 JpsStartupのコンストラクタ

クラスには次のコンストラクタが含まれます。

JpsStatup(java.lang.String platformType,
java.util.Map<java.lang.String,ContextConfiguration>  ctxtCfgs,
java.util.Map<java.lang.String,?> options)

追加のコンテキストの詳細およびオプションを指定してOPSSを起動する場合に、このコンストラクタをコールします。

ctxCfgs引数は、jps-config-jse.xmlファイルに指定されたコンテキストの詳細を保持します。デフォルトのコンテキスト以外のコンテキストを複数起動するには、複数のコンテキスト情報を渡します。デフォルトのコンテキスト以外のコンテキストを1つ起動するには、コンテキスト名を渡します。指定しない場合は、デフォルトのコンテキストが使用されます。

options引数は、特定のOPSS起動値を1つにまとめます。ランタイム・オプションの詳細は、表24-1を参照してください。

関連項目:

OPSS起動例

24.1.1.3 JpsStartupのランタイム・オプション

次の表は、jpsStartupメソッドで使用するオプションの説明をまとめたものです。

表24-1 JpsStartupのランタイム・オプション

オプション

値

デフォルト

説明

ACTIVE_CONTEXT

アクティブなコンテキストの名前。

default

指定されたコンテキストを使用します。それ以外の場合は、デフォルトのコンテキストを使用します。

ENABLE_JAVA_POLICY_PROVIDER

trueまたはfalse

true

ポリシー・プロバイダを使用する場合はtrueに設定します。それ以外の場合は、falseに設定します。

ENABLE_AUDIT_SERVICE_EXT

trueまたはfalse

true

サービスの起動時に監査モニタリングおよび監査ローダーを起動する場合はtrueに設定します。それ以外の場合は、falseに設定します。

ENABLE_POLICY_STORE_SERVICE_EXT

trueまたはfalse

true

ポリシー変更とともにポリシー配布ポイント(PDP)を起動する場合はtrueに設定します。それ以外の場合は、falseに設定します。

ENABLE_DEPLOYMENT_HANDLING

trueまたはfalse

true

デプロイメント・ハンドラを作成する場合はtrueに設定します。それ以外の場合は、falseに設定します。

RUNTIME_MODE

DEFAULTまたは

SCRIPT

DEFAULT

次のオプションをfalseに設定した場合はSCRIPTに設定します。

- ENABLE_JAVA_POLICY_PROVIDER

- ENABLE_AUDIT_SERVICE_EXT

- ENABLE_POLICY_STORE_SERVICE_EXT

- ENABLE_DEPLOYMENT_HANDLING

それ以外の場合は、DEFAULTに設定します。

JPS_CONFIG

oracle.security.jps.configで指定されたjps.config-jse.xmlへのパス

指定されたパスを使用します。それ以外の場合は、デフォルトのパスを使用します。

24.1.1.4 OPSS起動例

この項では、一般的なシナリオでのJpsStartupクラスの使用例を示します。

例1

次の例では、明示的にパラメータを指定せずにOPSSを起動する方法を示します。

JpsStartup jpsStartUp = new JpsStartup();
jpsStartUp.start();
jpsStartUp.getState();
jpsStartUp.stop();

例2

次の例では、特定の構成値でOPSSを起動する方法を示します。次の点に注意してください。

- default1は、contextConfigマップの一部として渡されるデフォルト・コンテキストです。

- 監査を無効にするには、ENABLE_AUDIT_SERVICE_EXTをfalseに設定します。このオプションはデフォルトでは有効になっています。

- ランタイム・サービスを無効にするには、ENABLE_POLICY_STORE_SERVICE_EXTをfalseに設定します。このオプションはデフォルトでは有効になっています。

ConfigurationServiceProvider prov = ConfigurationServiceProvider.newInstance();
ConfigurationService configService = prov.getConfigurationService();
ContextConfiguration configuration = configService.getContextConfiguration("default1");
Map<String, ContextConfiguration> contextConfig = new HashMap<String, ContextConfiguration>();
contextConfig.put(JpsConstants.DEFAULT_CONTEXT_KEY, configuration);

Map<String, Object> option = new HashMap<String, Object>();
option.put(JpsConstants.ENABLE_AUDIT_SERVICE_EXT, "FALSE");
option.put(JpsConstants.ENABLE_POLICY_STORE_SERVICE_EXT, "FALSE");

JpsStartup  jpsStartUp = new JpsStartup("JSE", contextConfig, option);
jpsStartUp.start();
jpsStartUp.stop();

例3

次の例では、追加のコンテキストを使用してOPSSを起動する方法を示します。

Map<String, Object> startupOption = new HashMap<String, Object>();

ConfigurationServiceProvider prov = ConfigurationServiceProvider.newInstance();
ConfigurationService configService = prov.getConfigurationService();
ContextConfiguration configuration = configService.getContextConfiguration("default1");

Map<String, ContextConfiguration> contextConfig = new HashMap<String, ContextConfiguration>();
contextConfig.put(JpsConstants.DEFAULT_CONTEXT_KEY, configuration);

JpsStartup jpsStartUp = new JpsStartup("JSE", contextConfig, startupOption);
jpsStartUp.start();
jpsStartUp.stop();

例4

次のコードは、複数のコンテキストを使用したOPSSの起動方法の例です。jps.config-jse.xmlファイルに次のコンテキストが含まれていることを前提としています。

<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="credstore"/> ...
</jpsContext>

<jpsContext name="default1">
<serviceInstanceRef ref="idstore.loginmodule"/> ...
</jpsContext>

<jpsContext name="default2">
<serviceInstanceRef ref="keystore"/> ...
</jpsContext>

<jpsContext name="default3">
<serviceInstanceRef ref="policystore "/> ...
</jpsContext>

<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.credstore"/>
</jpsContext>
</jpsContexts>

ConfigurationServiceProvider prov = ConfigurationServiceProvider.newInstance();
ConfigurationService configService = prov.getConfigurationService();
ContextConfiguration configuration1 = configService.getContextConfiguration("default1");
ContextConfiguration configuration2 = configService.getContextConfiguration("default2");
ContextConfiguration configuration3 = configService.getContextConfiguration("default3");

Map<String, ContextConfiguration> contextConfig = new HashMap<String, ContextConfiguration>();

contextConfig.put(JpsConstants.DEFAULT_CONTEXT_KEY, configuration);
contextConfig.put(("default1", configuration1);
contextConfig.put(("default2", configuration2);
contextConfig.put(("default3", configuration3);

Map<String, Object> startupOption = new HashMap<String, Object>();
startupOption.put(JpsConstants.ACTIVE_CONTEXT, "default");

JpsStartup jpsStartUp = new JpsStartup("JSE", contextConfig, startupOption);
jpsStartUp.start();
jpsStartUp.stop();

ACTIVE_CONTEXTパラメータでは、デフォルトとして使用するコンテキストを指定します。マップの一部としてDEFAULT_CONTEXT_KEYを渡さなかった場合、startupOptionマップの一部として渡されたACTIVE_CONTEXTキーがなければ、デフォルトのコンテキストが起動されます。

例5

次の例では、SCRIPTモードでOPSSを起動する方法を示します。このモードは、ランタイム・サービスを起動しない場合に使用します。

Map<String, Object> startupOption = new HashMap<String, Object>();
startupOption.put(JpsConstants.RUNTIME_MODE, "SCRIPT");

JpsStartup jpsStartUp = new JpsStartup("JSE", startupOption);
jpsStartUp.start();
jpsStartUp.stop();

24.2 Java SEアプリケーションでのセキュリティ・サービスの実装

次の各項では、Java SEアプリケーションでのOPSSサポートについて説明します。

- Java SEアプリケーションでの認証

- 「Java SEアプリケーションでの認可」

- 第18.5.1項「Java SEアプリケーションでの資格証明ストア・フレームワークAPIの使用」

- 第21.4項「Java SEアプリケーションでのキーストア・サービスAPIの使用」

- 「Java SEアプリケーションでの監査」

24.3 Java SEアプリケーションでの認証

次の各項では、Java SEアプリケーションでのアイデンティティ・ストアのサポートについて説明します。

- Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成

- Javaアプリケーションでのログイン・モジュールの使用

- Java SEアプリケーションでのログイン・モジュールの使用

24.3.1 Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成

Java SEアプリケーションでは、jps-config-jse.xmlファイルでserviceProvider、serviceInstanceおよびjpsContextの各要素を使用して構成されたLDAPアイデンティティ・ストアを使用できます。

<serviceProviders>
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider" class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>Prototype LDAP ID store</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<property name="idstore.type" value="OID"/>
<property name="max.search.filter.length" value="500"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>
</serviceInstances>

<jpsContexts default="ldap_idstore">
<jpsContext name="ldap_idstore">
<serviceInstanceRef ref="idstore.ldap"/>
</jpsContext>

<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
</jpsContexts>

次の点に注意してください:

- serviceInstanceの名前(この例ではidstore.ldap)は、serviceInstanceRefで参照されるインスタンスと一致する必要があります。

- serviceProviderの名前(この例ではidstore.ldap.provider)は、serviceInstanceで指定されるプロバイダと一致する必要があります。

関連項目:

付録Eの項「スクリプトを使用したサービスの構成」

第F.2.4項「LDAPアイデンティティのプロパティ」

24.3.2 Javaアプリケーションでのログイン・モジュールの使用

特に指定のないかぎり、この項の情報は、Java EEアプリケーションとJava SEアプリケーションの両方に適用され、ログイン・モジュールのコールに使用するAPIは両種類のアプリケーションに共通します。

ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。ログイン・モジュールでは、名前とパスワードまたはその他のデータを要求した後にユーザーを認証します。認証が成功すると、モジュールによって関連するプリンシパルがサブジェクトに割り当てられます。

サポートされているログイン・モジュールで、次のプロパティを設定します。

enable.anonymous (default: false)
remove.anonymous.role (default: true)
add.application.roles (default: true)
add.authenticated.role (default: true)

サポートされているログイン・モジュールは次のとおりです。

- ユーザー認証のログイン・モジュール

- ユーザー・アサーションのログイン・モジュール

- アイデンティティ・ストアのログイン・モジュール

- アサートされたユーザー

Java SEアプリケーションでは、ユーザー認証のログイン・モジュールとユーザー・アサーションのログイン・モジュールがデフォルトのアイデンティティ・ストア・サービスでサポートされています。

24.3.2.1 ユーザー認証のログイン・モジュール

ユーザー認証のログイン・モジュールは、指定されたユーザー名およびパスワードによってユーザーを認証するために、Java EEアプリケーションとJava SEアプリケーションの両方で使用します。このログイン・モジュールの構成はすぐに使用でき、ドメイン・アイデンティティ・ストアに対して認証します。

次の例では、プログラムによる認証に対するこのモジュールの使用方法を示します。

import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
public class MyCallbackHandler  extends CallbackHandler {
private String name = null;
private char[] password = null;

public MyCallbackHandler(String name, char[] password) {
this.name = name;
this.password = password;
}

public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof NameCallback) {
NameCallback ncb  = (NameCallback) callback;
ncb.setName(name);
}
else if (callback instanceof PasswordCallback) {
PasswordCallback pcb  = (PasswordCallback) callback;
pcb.setPassword(password);
}
else {
throw UnsupportedCallbackException(callback);
}
}
}
}

JpsLoginModuleFactory factory = JpsLoginModuleFactory.getLoginModuleFactory();
CallbackHandler cbh = new  MyCallbackHandler("name", "password".toCharArray());
LoginContext ctx = factory.getLoginContext(JpsLoginModuleType.USER_AUTHENTICATION, null, cbh);
ctx.login();
Subject s = ctx.getSubject();

24.3.2.2 ユーザー・アサーションのログイン・モジュール

ユーザー認証のログイン・モジュールは、アイデンティティ・ストア内のユーザー・アイデンティティをアサートするために、Java EEアプリケーションとJava SEアプリケーションの両方で使用します。これには、次の各項で説明しているように、oracle.security.jps.JpsPermissionパーミッションのプロビジョニングと、oracle.security.jps.callback.IdentityCallbackコールバックの実装が必要です。

- jpsPermissionのプロビジョニング

- CallbackHandlerの実装

- プログラムのアサーションの実装

24.3.2.2.1 jpsPermissionのプロビジョニング

次の例では、ユーザー・アサーションのログイン・モジュールを実行するためのjdoeプリンシパル・パーミッションを許可する権限付与を示します。

<grant>
<grantee>
<principals>
<principal>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>jdoe</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<action>execute</action>
</permission>
</permissions>
</grant>

関連項目:

第23.6.6項「サポートされているパーミッション・クラスの使用」

24.3.2.2.2 CallbackHandlerの実装

次の例では、コールバック・ハンドラの実装を示します。

import oracle.security.jps.callback.IdentityCallback;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import java.io.IOException;
public class AssertCallbackHandler implements CallbackHandler {
private String name = null;
public AssertCallbackHandler(String name) {
this.name = name;
}
public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof IdentityCallback) {
IdentityCallback nc = (IdentityCallback) callback;
nc.setIdentity(name);
}
else {
throw new UnsupportedCallbackException(callback);
}
}
}
}

24.3.2.2.3 プログラムのアサーションの実装

次の例では、ユーザーのアサート方法を示します。

import oracle.security.jps.callback.IdentityCallback;
import oracle.security.jps.internal.api.jaas.module.JpsLoginModuleFactory;
import oracle.security.jps.internal.api.jaas.module.JpsLoginModuleType;
import javax.security.auth.Subject;
import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.UnsupportedCallbackException;
import javax.security.auth.login.LoginContext;
import java.io.IOException;
import java.security.AccessController;
import java.security.PrivilegedActionException;
import java.security.PrivilegedExceptionAction;
Subject subject = AccessController.doPrivileged(new PrivilegedExceptionAction<Subject>() {
public Subject run() throws Exception {
JpsLoginModuleFactory f = JpsLoginModuleFactory.getLoginModuleFactory();
CallbackHandler cbh = new AssertCallbackHandler(name);
LoginContext c = f.getLoginContext(JpsLoginModuleType.USER_ASSERTION, null, cbh);
c.login();
return c.getSubject();
}
});

24.3.2.3 アイデンティティ・ストアのログイン・モジュール

Java SEアプリケーションでは、ログイン・モジュールのスタックを使用してユーザーを認証できます。各モジュールではスタック内の他のモジュールとは無関係に独自の計算を実行でき、これらのモジュールはjps-config-jse.xmlファイルに指定されています。

認証アルゴリズムでは、コンテキストがスタック内のログイン・モジュールをリストする順序を考慮して計算を実行するため、この順序は重要です。すぐに使用できる状態では、アイデンティティ・ストア・サービスはsystem-jazn-data.xmlファイルに指定されています。サービスは、LDAPストアを使用するように再構成できます。

OPSS APIには、oracle.security.jps.service.login.LoginServiceインタフェースが組み込まれており、これを使用するとJava SEアプリケーションでは、スタック内のすべてのログイン・モジュールだけでなく、その一部も所定の順序でコールできます。このインタフェースのLoginContextに渡されるコンテキストにより、アプリケーションで使用するログイン・モジュールのスタックが決まります。

アイデンティティ・ストアのログイン・モジュールに関連付けられているクラスは、oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModuleクラスです。

このログイン・モジュールに固有のプロパティには、remove.anononymous.roleおよびadd.application.roleがあります。

このモジュールのインスタンスは、jps-config-jse.xmlファイルで構成します。

<serviceInstance name="idstore.loginmodule" provider="jaas.login.provider">
<description>Identity Store Login Module</description>
<property name="loginModuleClassName" value="oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule"/>
<property name="jaas.login.controlFlag" value="REQUIRED"/>
</serviceInstance>

次の各項では、Java SEアプリケーションでのこのモジュールの使用方法について説明します。

- 認証のためのアイデンティティ・ストア・ログイン・モジュールの使用

- アサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用

24.3.2.3.1 認証のためのアイデンティティ・ストア・ログイン・モジュールの使用

この項では、基本的なユーザー名とパスワードの認証のためのアイデンティティ・ストアのログイン・モジュールの使用方法について説明します。

次の例では、appNameコンテキストの構成方法を示します。

<jpsContext name="appName">
<serviceInstanceRef ref="jaaslm.idstore1"/>
</jpsContext>

<serviceProvider type="JAAS_LM" name="jaaslm.idstore"
class="oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule">
<description>Identity Store-based LoginModule
</description>
</serviceProvider>

<serviceInstance name="jaaslm.idstore1" provider="jaaslm.idstore">
<property name="jaas.login.controlFlag" value="REQUIRED"/>
<property name="debug" value="true"/>
<property name="addAllRoles" value="true"/>
</serviceInstance>

次の例では、名前およびパスワードを処理するコールバックを示します。

import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import javax.security.auth.callback.*;
import java.io.IOException;
Subject sub = new Subject();
CallbackHandler cbh = new YourCallbackHandler();
LoginContext context = new LoginContext(appName, subject,  cbh);
context.login();

public class SampleCallbackHandler implements CallbackHandler {
//For name/password callbacks
private String name = null;private char[] password = null;
public SampleCallbackHandler(String name, char[] pwd) {
if (name == null || name.length() == 0 )
throw new IllegalArgumentException("Invalid name ");
else
this.name = name;
if (pwd == null || pwd.length == 0)
throw new IllegalArgumentException("Invalid password ");
else
this.password = pwd;
}
public String getName() {
return name;
} public char[] getPassword()  {
return password;
}
public void handle(Callback[] callbacks)
throws IOException, UnsupportedCallbackException {
if (callbacks != null && callbacks.length > 0) {
for (Callback c : callbacks) {
if (c instanceof NameCallback) {
((NameCallback) c).setName(name);
}
else
if (c instanceof PasswordCallback) {
((PasswordCallback) c).setPassword(password);
}
else {
throw new UnsupportedCallbackException(c);
}
}
}
}
}

24.3.2.3.2 アサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用

アイデンティティ・ストアのログイン・モジュールをアサーションに使用するには、保護されたsetIdentityメソッドを実行するためのパーミッションを指定し、oracle.security.jps.callback.IdentityCallbackクラスを使用するコールバック・ハンドラを実装する必要があります。

次の例では、アサーションのログイン・モジュールで、保護されたメソッドを実行するためのMyAppアプリケーション・パーミッションを許可する構成を示します。

<grant>
<grantee>
<codesource>
<url>file:${soa.oracle.home}/application/myApp.ear</url>
<--! soa.oracle.home is a system property set when
the server JVM is started -->
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
</permission>t
</permissions>
</grant>

次の例では、アサーションのログイン・モジュールを実行するためのjdoeユーザー・パーミッションを許可する構成を示します。

<grant>
<grantee>
<principals>
<principal>
<class>weblogic.security.principal.WLSUserImpl</class>
<name>jdoe</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
</permission>
</permissions>
</grant>

次の例では、コールバック・ハンドラの実装を示します。

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;
import oracle.security.jps.callback.IdentityCallback;
public class CustomCallbackHandler implements CallbackHandler {
private String name = null;
private char[] password;
public CustomCallbackHandler(String name) {
this.name = name;
}
public CustomCallbackHandler(String name, char[] password) {
this.name  = name;
this.password = password;
}
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
for (Callback callback : callbacks) {
if (callback instanceof NameCallback) {
NameCallback nc = (NameCallback) callback;
nc.setName(name);
}
else if (callback instanceof PasswordCallback) {
PasswordCallback pc = (PasswordCallback) callback;
pc.setPassword(password);
}
else if (callback instanceof IdentityCallback) {
IdentityCallback idcb = (IdentityCallback)callback;
idcb.setIdentity(name);
idcb.setIdentityAsserted(true);
idcb.setAuthenticationType("CUSTOM");
} else {
//throw exception
throw new UnsupportedCallbackException(callback);
}
}
}
}

次の例では、ログイン・モジュールの実装を示します。

import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.login.LoginContext;

import oracle.security.jps.service.JpsServiceLocator;
import oracle.security.jps.service.login.LoginService;

public class LoginModuleExample {
private static final String CONTEXT_NAME = "JSE_UserAuthnAssertion";

public LoginModuleExample() {
super();
}

public Subject assertUser(final String username) throws Exception {
CallbackHandler cbh =
AccessController.doPrivileged(new PrivilegedExceptionAction<CallbackHandler>() {
public CallbackHandler run() throws Exception {
return new CustomCallbackHandler(username);
}
});
Subject sub = new Subject();
LoginService ls =
JpsServiceLocator.getServiceLocator().lookup(LoginService.class);
LoginContext context = ls.getLoginContext(sub, cbh);

context.login();
Subject s = context.getSubject();

return s;
}

public Subject authenticate(final String username, final char[] password) throws Exception {
CallbackHandler cbh = new CustomCallbackHandler(username, password);
Subject sub = new Subject();
LoginService ls =
JpsServiceLocator.getServiceLocator().lookup(LoginService.class);
LoginContext context = ls.getLoginContext(sub, cbh);

context.login();
Subject s = context.getSubject();

return s;
}

public static void main(String[] args) {
LoginModuleExample loginModuleExample = new LoginModuleExample();
try {
System.out.println("authenticated user subject = " +
loginModuleExample.authenticate("testUser",
"welcome1".toCharArray()));
System.out.println("asserted user subject = " +
loginModuleExample.assertUser("testUser"));
} catch (Exception e) {
e.printStackTrace();
}
}
}

24.3.2.4 アサートされたユーザー

アプリケーションでは、みなし実行操作としてアクションを実行することが必要になる場合がよくあります。OPSSでは、アサートされたユーザーのサブジェクトを使用して、そのユーザーが実行するかのようにアプリケーション・ロジックを実行できます。

次の各項では、OPSS SubjectSecurityクラスを使用してみなし実行操作を実装する方法について説明します。

- SubjectSecurityクラス

- プログラミングのガイドラインおよび推奨事項

- SubjectSecurityの使用

24.3.2.4.1 SubjectSecurityクラス

次に、このクラスを使用するシナリオをいくつか示します。

- UC1 - スケジューラにより、ジョブの送信および実行が可能になります。このようなジョブは一度に送信された後、ある時点で実行されるため、ユーザーのアイデンティティをアサートし、ユーザーのコンテキストでスケジュールされたジョブを実行する必要があります。

- UC2 - スケジュールされたジョブが、ジョブを完了するために他のエンティティBeanをコールするエンティティBeanによって実行され、ジョブを完了するためのコードはすべて、ユーザーのコンテキストで実行する必要があります。したがって、このコンテキストはコール・パスを介してエンティティBean間で伝播される必要があります。

- UC3 - スケジュールされたジョブを実行するためのパーミッションは、ユーザーのアプリケーション・ロールに基づいています。この場合は、エンティティBean間のコード・パスにかかわらず、ユーザーのコンテキストではユーザーに付与されたアプリケーション・ロールを認識する必要があります。

- UC4 - 認証されていないユーザーがジョブを送信する場合、ジョブ・メタデータは匿名ユーザーを保持する必要があります。最終的に、ジョブは匿名ユーザーによって実行される必要があります。

- UC5 - アプリケーションで実行されるMBeanは、MBeanサーバー経由でUIからコールされます。MBean操作により、特定のユーザーとして実行する必要のある一連の診断テストがコールされます。

- UC6 - アイデンティティがアサートされており、そのユーザーとして操作を実行するために使用できるユーザー・コンテキストがアサーションで作成されています。

24.3.2.4.2 プログラミングのガイドラインおよび推奨事項

SubjectSecurityクラスでは、事前に計算されたサブジェクトが使用可能な場合または最初にユーザーをアサートする必要がある場合、コードを実行できます。アプリケーション・コンテキストを設定していない場合は、SubjectSecurityクラスを使用する前に、そのIDを設定します。

AppSecurityContext.setApplicationID(applicationID)

アプリケーション・コンテキストを設定した場合は、setApplicationIDへのコールはオプションです。

SubjectSecurityクラスを使用したプログラミングでは、次のようにします。

- サブジェクトをすでに取得しており、サブジェクトを使用して操作を実行する場合は、SubjectSecurity.getActionExecutor(subject)を使用します。

- SubjectUtil.getCurrentSubjectメソッドを使用してサブジェクトを取得した場合、そのサブジェクトはコンテナ・セキュリティおよびOPSSと連動し、アプリケーション・ロールが考慮されます。

- JpsLoginModuleFactoryクラスを使用してプログラムでサブジェクトを取得した場合、そのサブジェクトはコンテナ・セキュリティおよびOPSSと連動します。

- ユーザー名のみが使用可能で、そのユーザーとして操作を実行する場合は、SubjectSecurity.getActionExecutor(userName)を使用します。このメソッドを使用するには、次のようにコードソース・パーミッションを指定します。

<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/myApp.ear/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>IdentityAssertion</name>
<actions>execute</actions>
</permission>
</permissions>
</grant>

urlでは、メソッドをコールするコードの場所を指定します。

- ActionExecutor.execute(PrivilegedAction)が、サブジェクトおよびアプリケーションのPrivilegedActionを使用してSubject.doAsをコールすることに注意します。

- SubjectSecurity.executeAs(Subject subject, PrivilegedAction<T> action)を使用して、アクションを即時に実行します。

- SubjectSecurity.executeAs(Subject subject, PrivilegedExceptionAction<T> action)を使用して、アクションを即時に実行します。このメソッドでは、getActionExecutorメソッドを使用してアクション・エグゼキュータを取得し、アクションを実行します。

oracle.security.jps.runtime.SubjectSecurityクラスおよびoracle.security.jps.runtime.ActionExecutorインタフェースの詳細は、Oracle Fusion Middleware Oracle Platform Security Services用のJava APIリファレンスを参照してください。

24.3.2.4.3 SubjectSecurityの使用

次の例では、SubjectSecurityクラスを使用して、アサートされたjdoeユーザーとして実行する方法を示します。

// get a SubjectSecurity instance
final SubjectSecurity subjectSecurity = SubjectSecurity.getInstance();
String username = "jdoe";
// create ActionExecutor with subjectSecurity getActionExecutor(String username)
ActionExecutor executor =
AccessController.doPrivileged(new PrivilegedExceptionAction<ActionExecutor>() {
public ActionExecutor run() throws AssertionException {
return subjectSecurity.getActionExecutor(username);
}
}, null);
// When OPSS subjects are available,
// create ActionExecutor with SubjectSecurity getActionExecutor(Subject subject)
Subject opssSubject = SubjectUtil.getCurrentSubject();
ActionExecutor ececutor = subjectSecurity.getActionExecutor(opssSubject);
//run privilegedAction
PrivilegedAction action = new MyPrivilegedAction();
executor.execute(action);
//run PrivilegedExceptionAction
PrivilegedExceptionAction exceptionAction = new MyPrivilegedExceptionAction();
try {
executor.execute(exceptionAction);
} catch (PrivilegedActionException e) {
// handle PrivilegedActionException
}

24.3.3 Java SEアプリケーションでのログイン・モジュールの使用

Java SEアプリケーションでログイン・モジュールをコールするには、oracle.security.jps.service.login.LoginServiceインタフェースのgetLoginContextメソッドを使用します。

標準のJava Authorization and Authentication Services (JAAS) APIのLoginContextメソッドと同様、getLoginContextメソッドはユーザーの認証に使用するLoginContextオブジェクト・インスタンスを返しますが、より一般的には、任意の数のログイン・モジュールを任意の順序で使用できます。認証は、これらのログイン・モジュールのみに対して、渡された順に実行されます。

次の例では、getLoginContextメソッドを使用したログイン・モジュールのサブセットに対するユーザー認証を示します。

import oracle.security.jps.service.ServiceLocator;
import oracle.security.jps.service.JpsServiceLocator;
import oracle.security.jps.service.login.LoginService;

//Obtain the login service
ServiceLocator locator = JpsServiceLocator.getServiceLocator();
LoginService loginService = locator.lookup(LoginService.class);

//Create the handler for given name and password
CallbackHandler cbh = new MyCallbackHandler("name", "password".toCharArray());

//Invoke login modules selectively in a given order
selectiveModules = new String[]{"lmName1", "lmName2", "lmName3"};
LoginContext ctx = loginService.getLoginContext(new Subject(), cbh, selectiveModules);
ctx.login();
Subject s = ctx.getSubject();

selectiveModulesは、ログイン・モジュール名の配列であり、認証では、これらのログイン・モジュールが配列にリストされた順で使用されます。配列内の各ログイン・モジュールは、jps-config-jse.xmlファイルのデフォルトのコンテキストにリストされています。

次の例では、2つのログイン・モジュールからなるスタックの構成を示します。

<serviceProvider type="LOGIN" name="jaas.login.provider" class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider">
<description>Common definition for any login module instances</description>
</serviceProvider>

<serviceInstance name="auth.loginmodule" provider="jaas.login.provider">
<description>User Authentication Login Module</description>
<property name="loginModuleClassName" value="oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule"/>
<property name="jaas.login.controlFlag" value="REQUIRED"/>
</serviceInstance>

<serviceInstance name="custom.loginmodule" provider="jaas.login.provider">
<description>My Custom Login Module</description>
<property name="loginModuleClassName" value="my.custom.MyLoginModuleClass"/>
<property name="jaas.login.controlFlag" value="REQUIRED"/>
</serviceInstance>

<jpsContexts default="aJpsContext">
<jpsContext name="aJpsContext">
<serviceInstanceRef ref="auth.loginmodule"/>
<serviceInstanceRef ref="custom.loginmodule"/>
</jpsContext>
</jpsContexts>

24.4 Java SEアプリケーションでの認可

ファイル・ストア、LDAPストアまたはDBストアをJava SEアプリケーションで使用して、すべてのサービスをjps-config-jse.xmlファイルで構成します。このファイルでは、アプリケーションに適したシステム・プロパティも設定します。

次の各項では、ポリシー・ストアおよび資格証明ストアの構成について説明します。

- ポリシーおよび資格証明のファイル・ストアの構成

- ポリシーおよび資格証明のLDAPストアの構成

- DBセキュリティ・ストアの構成

- ファイル・ストアでサポートされていないメソッド

関連項目:

第F.1項「OPSSシステム・プロパティ」

24.4.1 ポリシーおよび資格証明のファイル・ストアの構成

ファイル・ポリシー・ストアは、system-jazn-data.xmlファイルに指定されています。ファイル資格証明ストアは、cwallet.ssoファイルに指定されています。

次の例では、ポリシーおよび資格証明の構成を示します。

<serviceProviders>
<serviceProvider type="CREDENTIAL_STORE" name="credstoressp"
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider">
<description>SecretStore-based CSF Provider</description>
</serviceProvider>
<serviceProvider type="POLICY_STORE" name="policystore.xml.provider"
class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
<description>XML-based PolicyStore Provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name="credstore" provider="credstoressp" location="./">
<description>File Credential Store Instance</description>
</serviceInstance>

<serviceInstance name="policystore.xml" provider="policystore.xml.provider" location="./system-jazn-data.xml">
<description>File Policy Store Service Instance</description>
<property name="oracle.security.jps.policy.principal.cache.key" value="false"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default="TestJSE">
<jpsContext name="TestJSE">
<serviceInstanceRef ref="credstore"/>
<serviceInstanceRef ref="policystore.xml"/>
...
</jpsContext>
</jpsContexts>

ポリシー・ストアのインスタンスでoracle.security.jps.policy.principal.cache.keyプロパティをfalseに設定する必要があることに注意してください。

関連項目:

第23.6.3項「ファイル資格証明ストアの使用」

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のmodifyBootStrapCredentialに関する項およびaddBootStrapCredentialに関する項

24.4.2 ポリシーおよび資格証明のLDAPストアの構成

この項の例では、ドメインでLDAPストアを使用することを前提としています。

次の例では、Java SEアプリケーション用のプロバイダ、インスタンスおよびコンテキストの構成を示しています。

<serviceProviders
<serviceProvider type="POLICY_STORE" mame="ldap.policystore.provider"
class=oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider"/>
<serviceProvider type="CREDENTIAL_STORE" mame="ldap.credential.provider"
class=oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider"/>
</serviceProviders>

<serviceInstances>
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
<property value="OID" name="policystore.type"/>
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=PS1domainRC3" name="oracle.security.jps.farm.name"/>
<property value="cn=myTestNode" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://myComp.com:1234" name="ldap.url"/>
</serviceInstance>

<serviceInstance provider="ldap.credential.provider" name="credstore.ldap">
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=PS1domainRC3" name="oracle.security.jps.farm.name"/>
<property value="cn=myTestNode" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://myComp.com:1234" name="ldap.url"/>
</serviceInstance>
</serviceInstances>

<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>

<jpsContexts default="TestJSE">
<jpsContext name="TestJSE">
<serviceInstanceRef ref="policystore.ldap"/>
<serviceInstanceRef ref="credstore.ldap"/>
</jpsContext>
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
</jpsContexts>

次の例では、セキュリティ・ストアへの参照をプログラムで取得する方法を示しますが、システム・プロパティoracle.security.jps.configがjps-config-jse.xmlファイルの場所に設定されていることを前提としています。

String contextName="TestJSE";
public static PolicyStore getPolicyStore(String contextName) {
try-block
JpsContextFactory ctxFact;
ctxFact = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFact.getContext(contextName);
return ctx.getServiceInstance(PolicyStore.class);
catch-block ...

関連項目:

第9.2.1項「LDAPセキュリティ・ストアを使用する場合の前提条件」

24.4.3 DBセキュリティ・ストアの構成

この項では、jps-config-jse.xmlファイルでのDBポリシー、資格証明およびキーストアの構成例を示します。この例では、次の点に注意してください。

- jdbc.urlプロパティの値は、データ・ソース作成時に入力したJava Database Connectivity (JDBC)データ・ソースの名前と同じにする必要があります。

- ブートストラップ資格証明(マップとキー)の値は、ブートストラップ資格証明の作成時にaddBootStrapCredential WebLogic Scripting Tool (WLST)コマンドに渡した値と一致する必要があります。

<jpsConfig  …>
<propertySets>
<propertySet name="props.db.1">
<property value="cn=myDomain" name="oracle.security.jps.farm.name"/>
<property value="DB_ORACLE" name="server.type"/>
<property value="cn=myRoot" name="oracle.security.jps.ldap.root.name"/>
<property name="jdbc.url" value="jdbc:oracle:thin:@myhost.com:1521/srv_name"/>
<property name="jdbc.driver" value="oracle.jdbc.driver.OracleDriver"/>
<property name="bootstrap.security.principal.key" value="myKeyName" />
<property name="bootstrap.security.principal.map" value="myMapName" />
</propertySet>
</propertySets>

<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.policystore.OPSSPolicyStoreProvider"
type="POLICY_STORE" name="policy.rdbms">
<description>DBMS based PolicyStore</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider"
type="CREDENTIAL_STORE" name="db.credentialstore.provider" >
<serviceProvider class="oracle.security.jps.internal.keystore.KeyStoreProvider"
type="KEY_STORE" name="keystore.provider" >
<property name="provider.property.name" value="owsm"/>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name="policystore.rdbms" provider="db.policystore.provider">
<propertySetRef ref = "props.db.1"/>
<property name="policystore.type"  value="DB_ORACLE"/>
</serviceInstance>
<serviceInstance name="credstore.rdbms" provider="db.credstore.provider">
<propertySetRef ref = "props.db.1"/>
</serviceInstance>
<serviceInstance name="keystore.rdbms" provider="db.keystore.provider">
<propertySetRef ref = "props.db.1"/>
<property name="keystore.provider.type"  value="db"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="policystore.rdbms"/>
<serviceInstanceRef ref="credstore.rdbms"/>
<serviceInstanceRef ref="keystore.rdbms"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

関連項目:

第9.3.1項「DBセキュリティ・ストアを使用する場合の前提条件」

第F.2.1項「OPSSサービスに共通するプロパティ」

第F.2.8項「キーストア・サービスのプロパティ」

24.4.4 ファイル・ストアでサポートされていないメソッド

ファイル・ストアでは、カスケード削除が含まれるメソッドはサポートされていません。サポートされているのは、単純な問合せのみです。

次の例では、表示名がMyDisplayNameに一致するパーミッションをすべて返す単純な問合せを示します。

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.DISPLAY_NAME,
false,
ComparatorType.EQUALITY,
"MyDisplayName",
BaseSearchQuery.MATCHER.EXACT);
getPermissionSets(query);

カスケード削除は、シグネチャにブール型のcascadeDelete引数が含まれるメソッドと関連があります。ファイル・ストアの場合に指定できる唯一の値は、falseです。

24.5 Java SEアプリケーションでの監査

次の各項では、Oracle Platform Security Services共通監査フレームワークを使用してJava SEアプリケーションでイベントを監査する方法について説明し、一般的な監査使用シナリオをいくつか示します。

- Java SEアプリケーションでの監査について

- 監査のバスストップ・ディレクトリの構成

- 監査ローダーの構成

- Java SEアプリケーションでの一般的な監査シナリオ

関連項目:

Java SEアプリケーションでのOPSSの使用

24.5.1 Java SEアプリケーションでの監査について

Java SEアプリケーションでは、監査構成をjps-config-jse.xmlファイルに指定します。

<serviceInstance provider="audit.provider" name="audit">
<property value="Medium" name="audit.filterPreset"/>
<property value="0" name="audit.maxDirSize"/>
<property value="104857600" name="audit.maxFileSize"/>
<property value="" name="audit.specialUsers"/>
<property value="" name="audit.customEvents"/>
<property value="Db" name="audit.loader.repositoryType"/>
<property value="file" name="auditstore.type"/>
</serviceInstance>

監査により、アプリケーションではバスストップ・ファイルに記録される特定のランタイム・イベントを取得できます。監査ローダーは、データをバスストップ・ファイルから監査ストアに定期的に移動します。

関連項目:

監査のバスストップ・ディレクトリの構成

監査ローダーの構成

「Java SEアプリケーションでの一般的な監査シナリオ」

第14.2.2項「バスストップ・ファイルの管理」

第14.5項「監査ログとバスストップ・ファイルについて」

第F.2.7項「監査サービスのプロパティ」

24.5.2 監査のバスストップ・ディレクトリの構成

バスストップ・ファイル名は、sample.myhost.com_12345_audit_1_0.logのように、host_pid_audit_major_minor.log形式で指定します。ホスト名、プロセスIDおよびバージョン番号がファイル名に組み込まれていることに注意してください。

Java SEアプリケーションでは、サービスが監査バスストップ・ファイルを書き込む、書込み可能なディレクトリを使用する必要があります。この場所を指定するには、setAuditRepository WLSTコマンドを使用してaudit.logDirectoryプロパティを設定するか、システム・プロパティopss.audit.logDirectoryを設定します。実行時プロセスが書込み可能なディレクトリを特定できない場合、監査が機能しない可能性があります。

Java SEアプリケーションでは、audit.logDirectoryプロパティを使用して設定し、環境内のすべてのJava SEアプリケーションで同じjps-config-jse.xmlファイルを使用するか、同じ値をすべてのJava SEアプリケーションにシステム・プロパティとして渡すと、バスストップ・ファイルを共有できます。

関連項目:

『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のsetAuditRepositoryに関する項

24.5.3 監査ローダーの構成

監査ローダーは、バスストップ・ファイルからデータベースに監査データを移動するプロセスです。システム・プロパティaudit.loader.repositoryTypeは、Java EEアプリケーションおよびJava SEアプリケーションで設定する必要があります。デフォルトでは、databaseに設定されています。

Java SEアプリケーションでは、次の2種類のローダーを使用できます。

- 監査ローダー: ランタイム監査によって開始されるスレッドです。すぐに使用できる状態では、監査ローダーは無効になっており、有効にするにはaudit.loader.enable=trueと設定します。

- Java SEアプリケーション用のスタンドアロン監査ローダー: 特に共有ディレクトリを使用する場合にお薦めします。

関連項目:

第14.2.3項「スタンドアロン監査ローダーの構成」

24.5.4 Java SEアプリケーションでの一般的な監査シナリオ

次の各項では、Java SEアプリケーションで監査を実装する一般的なシナリオを説明します。WebLogic Serverが一緒に配置されている環境と一緒に配置されていない環境について考えます。一緒に配置されている環境とは、Java Required Files (JRF)がインストールされているWebLogic Serverドメインのことです。

24.5.4.1 WebLogic Serverが一緒に配置されている場合の監査

ドメインで監査を設定するには、次の手順を実行します。

1. Fusion Middleware ControlまたはsetAuditRepository WLSTコマンドを使用して、監査ローダー・リポジトリを設定します。

# logDirectory is the location of the audit log directory
# jdbcSring is the connect string
# user and pass refer to the IAU append schema user and password
# (These get stored in bootstrap credential store)

setAuditRepository(switchToDB = "true",dataSourceName = "jdbc/AuditDB",interval = "20", timezone="utc", logDirectory="/foo/bar", jdbcString="jdbc:oracle:thin:@host:1521:sid", dbUser="test_iau_append", dbPassword="password");

このコマンドによって、jps-config.xmlファイルとjps-config-jse.xmlファイルが更新されます。Java SEアプリケーションの書込み可能な監査ディレクトリがWebLogic Serverのログ・ディレクトリと同じディレクトリである場合、スタンドアロン監査ローダーは不要です。

2. Java SEアプリケーション用に異なる書込み可能な監査ディレクトリを選択した場合は、スタンドアロン監査ローダーを開始し、oracle.instanceなどのシステム・プロパティを使用してバスストップ・ディレクトリの値を設定します。

$JAVA_HOME/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.jps_12.2.1/jps-manifest.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_12.2.1/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_12.2.1./jps-manifest.jar
-Doracle.instance=$ORACLE_INST
-Doracle.security.jps.config=path_to_jps-config-jse.xml
oracle.security.audit.ajl.loader.StandaloneAuditLoader

24.5.4.2 WebLogic Serverが一緒に配置されていない場合の監査

次のタスクでは、ミドルウェア・ホームが使用できますが、WebLogic Serverが実行されていないため、Fusion Middleware ControlもsetAuditRepository WLSTコマンドも使用できないことを前提としています。

この場合、監査を設定するには、次の手順を実行します。

1. システム・プロパティopss.audit.logDirectoryまたはoracle.instanceを使用して、バスストップ・ディレクトリを指定します。すぐに使用できる状態では、書込み可能なディレクトリをJava仮想マシン(JVM)に指定すると、監査はJava SEアプリケーションで有効になります。

2. addBootStrapCredential WLSTコマンドを使用して、ブートストラップ資格証明をブートストラップ資格証明ストアに追加します。

addBootStrapCredential(jpsConfigFile='../../../user_projects/domains/base_domain/config/fmwconfig/jps-config-jse.xml', map='AuditDbPrincipalMap', key='AuditDbPrincipalMap', username='TEST_IAU_APPEND', password='password')

3. jps-config-jse.xmlファイルで、audit.loader.jdbcString=jdbc:oracle:thin:@host:1521:sidなどの値を指定して、audit.loader.jdbcStringプロパティを監査構成に追加します。

4. 複数のJava SEアプリケーションで監査ディレクトリを共有する場合、スタンドアロン監査ローダーを開始してレコードをデータベースに移動します。

5. Java SEアプリケーションがそれぞれ独自の監査ディレクトリに書き込む場合は、specifying audit.loader.enable=trueを指定してランタイム・サービスの監査ローダーを有効にします。
そうではなく、監査ディレクトリが共有されている場合は、スタンドアロン監査ローダーを開始します。

関連項目:

第14.2.3.2項「スタンドアロン監査ローダーの実行」

第V部

付録

この部は、次の付録で構成されています。

- 付録A「OPSS構成ファイル・リファレンス」

- 付録B「ファイル・ストアのリファレンス」

- 付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

- 付録E「スクリプトおよびMBeanを使用した管理」

- 付録F「OPSSのシステムおよび構成プロパティ」

- 付録G「OPSS APIリファレンス」

- 付録H「OpenLDAPアイデンティティ・ストアの使用」

- 付録I「ID仮想化のためのアダプタ構成」

- 付録J「OPSSのトラブルシューティング」

A OPSS構成ファイル・リファレンス

この付録では、通常$DOMAIN_HOME/config/fmwconfigディレクトリにある構成ファイルjps-config.xmlおよびjps-config-jse.xmlでの要素の階層と属性について説明します。

この付録の内容は次のとおりです。

- 第1および第2階層レベル

- 第3階層以下のレベル

関連項目:

第E.2項「MBeanを使用したサービスの構成」

A.1 第1および第2階層レベル

OPSS構成ファイルでの指定内容は、ドメイン全体、すなわちドメインにデプロイされた管理対象サーバーおよびアプリケーションすべてに適用されます。

jps-config.xmlファイルの最上位要素は、jpsConfig要素です。これには、次の第2レベルの要素が含まれています。

- <property>

- <propertySets>

- <extendedProperty>

- <serviceProviders>

- <serviceInstances>

- <jpsContexts>

表A-1は、これらの要素の機能を説明しています。中カッコ{}で囲まれた注釈は、その要素に許可されている繰返し回数を示します。たとえば、{0以上}は、その要素がゼロ回以上出現する可能性があることを示し、{1}はその要素が1回のみ出現することを示します。

表A-1 jps-config.xmlのトップレベルと第2レベルの要素

要素

説明

<jpsConfig> {1}

構成ファイルのトップレベルの要素を定義します。

<property> {0 or more}

プロパティの名前と値を定義します。この要素は、<propertySet>、<serviceProvider>、<serviceInstance>の下など、階層内の他の場所にも出現する可能性があります。

<propertySets> {0 or 1}
<propertySet> {1 or more}
<property> {1 or more}

1つまたは複数の<propertySet>要素をグループ化して、1つのグループとして参照できるようにします。

<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}

複数の値を持つプロパティを定義します。これは、extendedPropertyおよびserviceInstanceの各要素の下など、階層内の他の場所にも出現する可能性があります。

<extendedPropertySets> {0 or 1}
<extendedPropertySet> {1 or more}
<extendedProperty> {1 or more}
<name> {1}
<values> {1}
<value> {1 or more}

1つまたは複数の<extendedPropertySet>要素をグループ化して、1つのグループとして参照できるようにします。

<serviceProviders> {0 or 1}
<serviceProvider> {1 or more}
<description> {0 or 1}
<property> {0 or more}

1つ以上の<serviceProvider>要素をグループ化し、それぞれの要素では、プロバイダやログイン・モジュールなど、OPSSサービスの実装を定義します。

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

1つまたは複数の<serviceInstance>要素をグループ化します。それぞれの要素は、<serviceProvider>要素で定義されたサービス・プロバイダのプロパティ値を構成および指定します。

<jpsContexts> {1}
<jpsContext> {1 or more}
<serviceInstanceRef> {1 or more}

1つまたは複数の<jpsContext>要素をグループ化します。それぞれの要素は、アプリケーションが使用できるサービス・インスタンスのコレクションです。

A.2 第3階層以下のレベル

この項では、「第1および第2階層レベル」で説明した要素の下に出現する可能性がある全要素をアルファベット順に説明します。

- <description>

- <extendedProperty>

- <extendedPropertySet>

- <extendedPropertySetRef>

- <extendedPropertySets>

- <jpsConfig>

- <jpsContext>

- <jpsContexts>

- <name>

- <property>

- <propertySet>

- <propertySetRef>

- <propertySets>

- <serviceInstance>

- <serviceInstanceRef>

- <serviceInstances>

- <serviceProvider>

- <serviceProviders>

- <value>

- <values>

<description>

この要素は、対応するエンティティ(サービス・インスタンスまたはサービス・プロバイダ)の説明を示します。

親要素

<serviceInstance>または<serviceProvider>

子要素

なし

繰返し

<description>は、<serviceInstance>または<serviceProvider>の子として指定できます。

- <serviceInstance>の子の場合:

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

- <serviceProvider>の子の場合:

<serviceProviders> {0 or 1}
<serviceProvider> {1 or more}
<description> {0 or 1}
<property> {0 or more}

例

次の例は、説明を示しています。

<serviceProvider ... >
<description>file IdStore Provider</description>
...
</serviceProvider>

<extendedProperty>

この要素は、次の場所で拡張プロパティを定義します。

- <jpsConfig>の直下: 汎用的な拡張プロパティを定義します。たとえば、LDAP認証プロバイダのすべてのベースDNを指定できます。

- <extendedPropertySet>の直下: 拡張プロパティ・セットを定義します。

- <serviceInstance>の直下: 特定のサービス・インスタンスの拡張プロパティを定義します。

1つの拡張プロパティには複数の値が含まれています。それぞれの値を指定するには、<value>要素を使用します。このカテゴリには、次の値の指定など、LDAPアイデンティティ・ストアのプロパティがいくつか含まれます。

- ユーザー・オブジェクトの作成に使用されるオブジェクト・クラス

- ユーザーの作成時に指定する必要がある属性名

- ユーザー検索用のベースDN

親要素

<extendedPropertySet>、<jpsConfig>または<serviceInstance>

子要素

<name>または<values>

繰返し

<extendedProperty>は、<extendedPropertySet>、<jpsConfig>または<serviceInstance>の子として指定できます。

- <extendedPropertySet>の子の場合:

<extendedPropertySets> {0 or 1}
<extendedPropertySet> {1 or more}
<extendedProperty> {1 or more}
<name> {1}
<values> {1}
<value> {1 or more}

- <jpsConfig>の子の場合:

<jpsConfig>
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}

- <serviceInstance>の子の場合:

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

例

次の例では、1つの値を設定しています。

<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>

<extendedPropertySet>

この要素は、拡張プロパティのセットを定義します。定義後、拡張プロパティ・セットは、サービス・インスタンスの構成の一部として特定のプロパティを指定するために、<extendedPropertySetRef>要素によって参照されます。

属性

の属性" title="<extendedPropertySet>の属性" width="100%">

名前

説明

name

拡張プロパティ・セットの名前を指定します。1つの構成ファイル中に同じname属性の設定を持つ<extendedPropertySet>要素が複数存在することはできません。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<extendedPropertySets>

子要素

<extendedProperty>

繰返し

<extendedPropertySets>内に1つ以上必要です。

<extendedPropertySets> {0 or 1}
<extendedPropertySet> {1 or more}
<extendedProperty> {1 or more}
<name> {1}
<values> {1}
<value> {1 or more}

<extendedPropertySetRef>

この要素は、ファイル内の別の場所で定義された拡張プロパティ・セットを参照することにより、サービス・インスタンスを構成します。

属性

の属性" title="<extendedPropertySetRef>の属性" width="100%">

名前

説明

ref

<serviceInstance>親要素で定義されたサービス・インスタンスに使用される拡張プロパティが含まれる拡張プロパティ・セットを参照します。<extendedPropertySetRef>のref値は、<extendedPropertySet>要素のname値と一致している必要があります。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<serviceInstance>

子要素

なし

繰返し

オプション(ゼロ個以上)

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

<extendedPropertySets>

この要素は、プロパティのセットを指定します。

親要素

<jpsConfig>

子要素

<extendedPropertySet>

繰返し

オプション(0または1つ)

<jpsConfig>
<extendedPropertySets> {0 or 1}
<extendedPropertySet> {1 or more}
<extendedProperty> {1 or more}
<name> {1}
<values> {1}
<value> {1 or more}

<jpsConfig>

これは構成ファイルのルート要素です。

親要素

なし

子要素

<extendedProperty>、<extendedPropertySets>、<jpsContexts>、<property>、<propertySets>、<serviceInstances>または<serviceProviders>

繰返し

必須(1つのみ)

例

<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd"
schema-major-version="11" schema-minor-version="1">
...
</jpsConfig>

<jpsContext>

この要素は、コンテキストを構成するサービス・インスタンスのセットを参照することにより、ドメインに共通するサービス・インスタンスのコレクションであるOPSSコンテキストを宣言します。各<jspContext>には、一意の名前が必要です。

属性

の属性" title="<jpsContext>の属性" width="100%">

名前

説明

name

OPSSコンテキストの名前。コンテキストには、一意の名前が必要です。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<jpsContexts>

子要素

<serviceInstanceRef>

繰返し

<jpsContext>要素は、<jpsContexts>の下に少なくとも1つ必要です。<serviceInstanceRef>要素は、<jpsContext>要素に含まれます。

<jpsContexts> {1}
<jpsContext> {1 or more}
<serviceInstanceRef> {1 or more}

例

次の例では、2つのコンテキストの定義を示します。最初のdefaultというコンテキストは、デフォルトのコンテキスト(<jpsContexts>でdefault属性によって指定されたもの)であり、複数のサービス・インスタンスを名前によって参照します。

2番目のanonymousというコンテキストは、認証されていないユーザーを対象としており、anonymousおよびanonymous.loginmoduleサービス・インスタンスを参照します。

<serviceInstances>
...
<serviceInstance provider="credstoressp" name="credstore">
<description>File Based Default Credential Store Instance</description>
<property name="location" value="${oracle.instance}/config/JpsDataStore/JpsSystemStore"/>
</serviceInstance>
...
<serviceInstance provider="anonymous.provider" name="anonymous">
<property value="anonymous" name="anonymous.user.name"/>
<property value="anonymous-role" name="anonymous.role.name"/>
</serviceInstance>
...
<serviceInstance provider="jaas.login.provider" name="anonymous.loginmodule">
<description>Anonymous Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.anonymous.AnonymousLoginModule"
name="loginModuleClassName"/>
<property value="REQUIRED"
name="jaas.login.controlFlag"/>
</serviceInstance>
...
</serviceInstances>
...
<jpsContexts default="default">
...
<jpsContext name="default">
<!-- This is the default JPS context. All the mandatory services and Login Modules must be
configured in this default context -->
<serviceInstanceRef ref="credstore"/>
<serviceInstanceRef ref="idstore.xml"/>
<serviceInstanceRef ref="policystore.xml"/>
<serviceInstanceRef ref="idstore.loginmodule"/>
<serviceInstanceRef ref="idm"/>
</jpsContext>
<jpsContext name="anonymous">
<serviceInstanceRef ref="anonymous"/>
<serviceInstanceRef ref="anonymous.loginmodule"/>
</jpsContext>
...
</jpsContexts>

<jpsContexts>

この要素は、コンテキストのセットを指定します。

属性

の属性" title="<jpsContexts>の属性" width="100%">

名前

説明

デフォルト

指定がない場合にアプリケーションによって使用されるコンテキストを指定します。<jpsContexts>要素のdefault値は、<jpsContext>子要素のnameと一致している必要があります。
値: 文字列

デフォルト: 該当なし(必須)

デフォルトのコンテキストでは、サービスおよびログイン・モジュールをすべて構成する必要があります。

親要素

<jpsConfig>

子要素

<jpsContext>

繰返し

必須(1つのみ)

<jpsConfig>
<jpsContexts> {1}
<jpsContext> {1 or more}

例

<jpsContext>を参照してください。

<name>

この要素は、拡張プロパティの名前を指定します。

親要素

<extendedProperty>

子要素

なし

繰返し

必須(1つのみ)

<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}

例

<extendedProperty>を参照してください。

<property>

この要素は、次のシナリオでプロパティを定義します。

表A-2 <property>のシナリオ

要素のシナリオ" title="<property>のシナリオ" width="100%">

jps-config.xml内での位置

機能

<jpsConfig>の直下

汎用的な単一値プロパティを定義します。

<propertySet>の直下

複数の値を持つプロパティ・セットを定義します。

<serviceInstance>の直下

特定のサービス・インスタンスで使用されるプロパティを定義します。

<serviceProvider>の直下

特定のサービス・プロバイダのすべてのサービス・インスタンスで使用されるプロパティを定義します。

プロパティのリストについては、付録F「OPSSのシステムおよび構成プロパティ」を参照してください。

属性

の属性" title="<property>の属性" width="100%">

名前

説明

name

設定するプロパティの名前を指定します。
値: 文字列

デフォルト: 該当なし(必須)

value

設定するプロパティの値を指定します。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<jpsConfig>、<propertySet>、<serviceInstance>または<serviceProvider>

子要素

なし

繰返し

<propertySet>の下の場合は1つ以上必要です。それ以外の場合はオプションで、ゼロ個以上です。

- <jpsConfig>の子の場合:

<jpsConfig>
<property> {0 or more}

- <propertySet>の子の場合:

<propertySets> {0 or 1}
<propertySet> {1 or more}
<property> {1 or more}

- <serviceInstance>の子の場合:

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

- <serviceProvider>の子の場合:

<serviceProviders> {0 or 1}
<serviceProvider> {1 or more}
<description> {0 or 1}
<property> {0 or more}

例

次の例では、認可のJava Authorization and Authentication Services (JAAS)モードを無効にするプロパティを示します。

<jpsConfig ... >
...
<property name="oracle.security.jps.jaas.mode" value="off"/>
...
</jpsConfig>

その他の例については、<propertySet>および<serviceInstance>を参照してください。

<propertySet>

この要素は、プロパティのセットを定義します。各プロパティ・セットには名前があり、サービス・インスタンスの構成にプロパティを含めるために、<propertySetRef>要素から参照できるようになっています。

属性

の属性" title="<propertySet>の属性" width="100%">

名前

説明

name

プロパティ・セットの名前を指定します。1つのjps-config.xmlファイル中に同じ名前を持つ<propertySet>要素が複数存在することはできません。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<propertySets>

子要素

<property>

繰返し

<propertySets>内に1つ以上必要です。

<propertySets> {0 or 1}
<propertySet> {1 or more}
<property> {1 or more}

例

<propertySets>
...
<!-- For property that points to valid Access SDK installation directory -->
<propertySet name="access.sdk.properties">
<property name="access.sdk.install.path" value="$ACCESS_SDK_HOME"/>
</propertySet>
...
</propertySets>

<serviceInstances>
...
<serviceInstance provider="jaas.login.provider" name="oam.loginmodule">
<description>OAM Login Module</description>
<property
value="oracle.security.jps.internal.jaas.module.oam.OAMLoginModule"
name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
<propertySetRef ref="access.sdk.properties"/>
</serviceInstance>
...
</serviceInstances>

<propertySetRef>

この要素は、ファイル内の別の場所で定義されたプロパティ・セットを参照することにより、サービス・インスタンスを構成します。

属性

の属性" title="<propertySetRef>の属性" width="100%">

名前

説明

ref

<serviceInstance>親要素で定義されたサービス・インスタンスに使用されるプロパティが含まれるプロパティ・セットを参照します。<propertySetRef>要素のref値は、<propertySet>要素のnameと一致している必要があります。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<serviceInstance>

子要素

なし

繰返し

オプション(ゼロ個以上)

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

例

<propertySet>を参照してください。

<propertySets>

この要素は、プロパティ・セットのセットを指定します。

親要素

<jpsConfig>

子要素

<propertySet>

繰返し

オプション。存在する場合は、1つの<propertySets>要素のみが存在できます。

<jpsConfig>
<propertySets> {0 or 1}
<propertySet> {1 or more}
<property> {1 or more}

例

<propertySet>を参照してください。

<serviceInstance>

この要素は、アイデンティティ・ストア・インスタンスやログイン・モジュール・インスタンスなど、サービス・プロバイダのインスタンスを定義します。

各プロバイダ・インスタンスは、構成ファイル内でプロバイダの参照に使用されるインスタンス名と、場合によってはインスタンスのプロパティを指定します。プロパティは、インスタンスの場所を含んでおり、そのインスタンス要素自体内で直接指定したり、プロパティまたはプロパティ・セットを参照することによって間接的に指定することができます。サービス・インスタンスのプロパティを変更するには、第E.1項「スクリプトを使用したサービスの構成」で説明されている手順を使用します。

サービス・インスタンスのプロパティと拡張プロパティを、次の方法で設定します。

- <property>サブ要素を使用してプロパティを直接設定します。

- <extendedProperty>サブ要素を使用して拡張プロパティを直接設定します。

- <propertySetRef>サブ要素を使用して事前定義済のプロパティ・セットを参照します。

- <extendedPropertySetRef>サブ要素を使用して事前定義済の拡張プロパティ・セットを参照します。

属性

の属性" title="<serviceInstance>の属性" width="100%">

名前

説明

name

このサービス・インスタンスの名前を指定します。1つのjps-config.xmlファイル内に同じname属性の設定を持つ<serviceInstance>要素が2つ存在することはできません。
値: 文字列

デフォルト: 該当なし(必須)

プロバイダ

このインスタンスがどのサービス・プロバイダのものであるかを示します。
<serviceInstance>要素のprovider値は、<serviceProvider>要素のname値と一致している必要があります。

値: 文字列

デフォルト: 該当なし(必須)

親要素

<serviceInstances>

子要素

<description>、<extendedProperty>、<extendedPropertySetRef>、<property>または<propertySetRef>

繰返し

<serviceInstances>内に1つ以上必要です。

<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

例

例1

次の例では、locationプロパティを使用してファイルの場所を指定するファイル・アイデンティティ・ストアの構成を示します。

<serviceInstances>
<serviceInstance name="idstore.xml" provider="idstore.xml.provider">
<!-- Subscriber name must be defined for file Identity Store -->
<property name="subscriber.name" value="jazn.com"/>
<!-- This is the location of file Identity Store -->
<property name="location" value="./system-jazn-data.xml"/>
</serviceInstance>
...
</serviceInstances>

例2

次の例では、資格証明ストアの構成を示します。ここでは、locationプロパティを使用して資格証明ストアの場所を設定しています。

<serviceInstances>
<serviceInstance provider="credstoressp" name="credstore">
<description>File Based Default Credential Store Instance</description>
<property name="location"
value="${oracle.instance}/config/JpsDataStore/JpsSystemStore" />
</serviceInstance>
...
</serviceInstances>

例3

次の例では、LDAPアイデンティティ・ストアの構成を示します。

<serviceInstance name="idstore.oid" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=us,dc=oracle,dc=com"/>
<property name="idstore.type" value="OID"/>
<property name="security.principal.key" value="ldap.credentials"/>
<property name="security.principal.alias" value="JPS"/>
<property name="ldap.url" value="ldap://myServerName.com:389"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<property name="username.attr" value="uid"/>
<property name="groupname.attr" value="cn"/>
</serviceInstance>

例4

次の例では、監査プロバイダの構成を示します。

<serviceInstances>
<serviceInstance name="audit" provider="audit.provider">
<property name="audit.filterPreset" value="Low"/>
<property name="audit.specialUsers" value ="admin, fmwadmin" />
<property name="audit.customEvents" value ="JPS:CheckAuthorization,           CreateCredential, OIF:UserLogin"/>
<property name="audit.loader.jndi" value="jdbc/AuditDB"/>
<property name="audit.loader.interval" value="15" />
<property name="audit.maxFileSize" value="10240" />
<property name=" audit.loader.repositoryType " value="Db" />
</serviceInstance>
</serviceInstances>

例5

次の例では、ログイン・モジュールの構成を示します。

<serviceInstance name="user.authentication.loginmodule" provider="jaas.login.provider">
<description>User Authentication Login Module</description>
<property name="loginModuleClassName" value="oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule"/>
<property name="jaas.login.controlFlag" value="REQUIRED"/>
<property name="enable.anonymous" value="true"/>
<property name="remove.anonymous.role" value="false"/>
</serviceInstance>

関連項目:

- ここで参照されているサービス・プロバイダの定義の例については、<serviceProvider>を参照してください。

- <serviceInstanceRef>の対応する例については、<jpsContext>を参照してください。

<serviceInstanceRef>

この要素は、サービス・インスタンスを参照します。

属性

の属性" title="<serviceInstanceRef>の属性" width="100%">

名前

説明

ref

<jpsContext>親要素で定義されたコンテキストの一部であるサービス・インスタンスを参照します。<serviceInstanceRef>要素のref値は、<serviceInstance>要素のnameと一致している必要があります。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<jpsContext>

子要素

なし

繰返し

<jpsContext>内に1つ以上必要です。

<jpsContexts> {1}
<jpsContext> {1 or more}
<serviceInstanceRef> {1 or more}

例

<jpsContext>を参照してください。

<serviceInstances>

この要素は、<serviceInstance>要素の親です。

親要素

<jpsConfig>

子要素

<serviceInstance>

繰返し

オプション(0または1つ)

<jpsConfig>
<serviceInstances> {0 or 1}
<serviceInstance> {1 or more}
<description> {0 or 1}
<property> {0 or more}
<propertySetRef> {0 or more}
<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}
<extendedPropertySetRef> {0 or more}

例

<serviceInstance>を参照してください。

<serviceProvider>

この要素は、サービス・プロバイダを定義します。各プロバイダは、資格証明ストア、認証、ポリシー、ログイン・モジュールなどのプロバイダ・タイプと、プロバイダの作成時に使用するために実装するJavaクラスを指定します。さらに、要素propertyではプロバイダのインスタンス化に使用される設定を指定します。

次のデータを指定します。

- サービス・プロバイダのタイプ(type属性で指定)

- サービス・プロバイダに指定された名前(このサービス・プロバイダのインスタンスを定義する各<serviceInstance>要素内で参照)

- このサービス・プロバイダを実装し、このサービス・プロバイダのインスタンス作成時にインスタンス化されるクラス

- このサービス・プロバイダの任意のインスタンスに汎用的に使用される任意のオプションのプロパティ

属性

の属性" title="<serviceProvider>の属性" width="100%">

名前

説明

type

宣言されているサービス・プロバイダのタイプを指定します。有効なタイプは次のとおりです。
CREDENTIAL_STORE

IDENTITY_STORE

POLICY_STORE

AUDIT

LOGIN

ANONYMOUS

KEY_STORE

IDM(プラガブルなアイデンティティ管理用)

CUSTOM

実装クラスでは、より具体的にプロバイダのタイプが定義されます。

値: 任意の有効なタイプ。

デフォルト: 該当なし(必須)

name

このサービス・プロバイダの名前を指定します。この名前は、<serviceInstance>要素のprovider属性で、このプロバイダのインスタンスを作成するために参照されます。1つの構成ファイル中に同じname属性の設定を持つ<serviceProvider>要素が複数存在することはできません。
値: 文字列

デフォルト: 該当なし(必須)

class

サービス・プロバイダの作成時にインスタンス化されたこのサービス・プロバイダを実装するJavaクラスの完全修飾名を指定します。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<serviceProviders>

子要素

<description>または<property>

繰返し

<serviceProviders>要素内に1つ以上必要です。

<serviceProviders> {0 or 1}
<serviceProvider> {1 or more}
<description> {0 or 1}
<property> {0 or more}

例

次の例では、ログイン・モジュールの指定を示します。

<serviceProviders>
<serviceProvider type="LOGIN" name="jaas.login.provider"
class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider">
<description>This is Jaas Login Service Provider and is used to configure
login module service instances</description>
</serviceProvider>
</serviceProviders>

次の例では、プロバイダの定義を示します。

<serviceProviders>
<serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
</serviceProvider>
</serviceProviders>

その他の例については、<serviceInstance>を参照してください。

<serviceProviders>

この要素は、サービス・プロバイダのセットを指定します。

親要素

<jpsConfig>

子要素

<serviceProvider>

繰返し

オプションで、1つのみです。

<jpsConfig>
<serviceProviders> {0 or 1}
<serviceProvider> {1 or more}
<description> {0 or 1}
<property> {0 or more}

例

<serviceProvider>を参照してください。

<value>

この要素は拡張プロパティの値を指定します。拡張プロパティは複数の値を持つことができます。<value>要素ごとに1つの値を指定します。

親要素

<values>

子要素

なし

繰返し

<values>内に1つ以上必要です。

<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}

例

<extendedProperty>を参照してください。

<values>

<value>要素の親要素です。

親要素

<extendedProperty>

子要素

<value>

繰返し

<extendedProperty>内に1つのみ必要です。

<extendedProperty> {0 or more}
<name> {1}
<values> {1}
<value> {1 or more}

例

<extendedProperty>を参照してください。

B ファイル・ストアのリファレンス

この付録では、ファイル・アイデンティティ・ストアを指定するsystem-jazn-data.xmlファイルおよびjazn-data.xmlファイルでの要素の階層と属性について説明します。ファイル・アイデンティティ・ストアは、Java SEアプリケーションでのみサポートされます。

内容は次のとおりです。

- ファイル・ストアの階層

- ファイル・ストアの要素と属性

B.1 ファイル・ストアの階層

この項では、system-jazn-data.xmlファイルおよびjazn-data.xmlファイルの要素の階層について説明します。<jazn-data>要素はルート要素です。このルート要素の直下の要素は次のとおりです。

- <jazn-realm>

- <policy-store>

- <jazn-policy>

<jazn-principal-classes>要素および<jazn-permission-classes>要素とそのサブ要素は、<policy-store>要素のサブ要素としてsystem-jazn-data.xmlファイルに出現することがありますが、下位互換性のみを目的としたものです。

表B-1 system-jazn-data.xmlおよびjanz-data.xmlの要素の階層

要素

説明

<jazn-data>

system-jazn-data.xmlファイルの最上位レベルの要素です。

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

セキュリティ・レルムと、各レルムに含まれるユーザーおよびエンタープライズ・グループを指定します。

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
|   <app-role> {1 or more}
|       <name> {1}
|       <class> {1}
|       <display-name> {0 or 1}
|       <description> {0 or 1}
|       <guid> {0 or 1}
|       <uniquename> {0 or 1}
|       <extended-attributes> {0 or 1}
|       |   <attribute> {1 or more}
|       |       <name> {1}
|       |       <values> {1}
|       |           <value>  {1 or more}
|       <members> {0 or 1}
|           <member> {1 or more}
|               <name> {1}
|               <class> {1}
|               <uniquename> {0 or 1}
|               <guid> {0 or 1}
<role-categories> {0 or 1}
|   <role-category> {1 or more}
|      <name> {1}
|      <display-name> {0 or 1}
|      <description> {0 or 1}
|      <members> {0 or 1}
|         <role-name-ref> {1}
<resource-types> {0 or 1}
|   <resource-type> {1 or more}
|      <name> {1}
|      <display-name> {1}
|      <description> {0 or 1}
|      <provider-name> {1}
|      <matcher-class> {1}
|      <actions-delimiter> {1}
|      <actions> {0 or more}
<resources> {0 or 1}
|    <resource> {1 or more}
|       <name> {1}
|       <display-name> {1}
|       <description> {0 or 1}
|       <type-name-ref> {1}
<permission-sets> {0 or 1}
|   <permission-set> {1 or more}
|       <name> {1}
|       <member-resources> {1 or more}
|          <member-resource>     {1 or more}
|              <resource-name> {1}
|              <type-name-ref> {1}
|              <actions> {0 or 1}
<jazn-policy> {0 or 1}
|   <grant> {0 or more}
|       <description> {0 or 1}
|       <grantee> {0 or 1}
|       |   <principals> {0 or 1}
|       |       <principal> {0 or more}
|       |           <name> {1}
|       |           <class> {1}
|       |           <uniquename> {0 or 1}
|       |           <guid> {0 or 1}
|       |   <codesource> {0 or 1}
|       |       <url> {1}
|       <permissions> {0 or 1}
|           <permission> {1 or more}
|               <class> {1}
|               <name> {0 or 1}
|               <actions> {0 or 1}

アプリケーション・レベルのポリシーを構成します。アプリケーション・レベルでロールを定義してから、ロールのメンバーを定義します。ロールのメンバーは、ユーザーおよびその他のロールです。

<jazn-policy>が<application>要素の下に指定されている場合は、アプリケーション・レベルのポリシーを指定します。

<jazn-policy>は、<jazn-data>要素の下にも指定できます。この場合は、システム・レベルのポリシーを指定します。

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
|   <principals> {0 or 1}
|      <principal> {0 or more}
|         <name> {1}
|         <class> {1}
|         <uniquename> {0 or 1}
|         <guid> {0 or 1}
|   <codesource> {0 or 1}
|      <url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}
<permission-sets>
|   <permission-set>
|      <name>

<jazn-policy>要素が<jazn-data>要素の下にある場合は、システム・レベルのポリシーを指定します。

<jazn-policy>は、<application>要素の下にも指定できます。この場合は、アプリケーション・レベルのポリシーを指定します。

B.2 ファイル・ストアの要素と属性

次の各項では、system-jazn-data.xmlファイルおよびjazn-data.xmlファイルの要素と属性について説明します。

- <actions>

- <actions-delimiter>

- <app-role>

- <app-roles>

- <application>

- <applications>

- <attribute>

- <class>

- <codesource>

- <credentials>

- <description>

- <display-name>

- <extended-attributes>

- <grant>

- <grantee>

- <guid>

- <jazn-data>

- <jazn-policy>

- <jazn-realm>

- <matcher-class>

- <member>

- <member-resource>

- <member-resources>

- <members>

- <name>

- <owner>

- <owners>

- <permission>

- <permissions>

- <permission-set>

- <permission-sets>

- <policy-store>

- <principal>

- <principals>

- <provider-name>

- <realm>

- <resource>

- <resource-name>

- <resources>

- <resource-type>

- <resource-types>

- <role>

- <role-categories>

- <role-category>

- <role-name-ref>

- <roles>

- <type>

- <type-name-ref>

- <uniquename>

- <url>

- <user>

- <users>

- <value>

- <values>

<actions>

この要素は、関連するパーミッションのクラスに対して許可されている操作を指定します。値では大文字と小文字が区別され、値はパーミッションの実装ごとに異なります。

親要素

<permission>

子要素

なし

繰返し

オプション(0または1つ)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
...
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<actions-delimiter>

この要素は、関連付けられているリソース・タイプのアクションを区切るために使用する文字を指定します。

親要素

<resource-types>

子要素

<name>、<display-name>、<description>、<actions>、<roles>、<users>

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<resource-types> {0 or 1}
<resource-type> {1 or more}
<name> {1}
<display-name> {1}
<description> {0 or 1}
<provider-name> {1}
<matcher-class> {1}
<actions-delimiter> {1}
<actions> {0 or more}

例

例については、<resource-type>を参照してください。

<app-role>

この要素は、アプリケーション・ロールを指定します。

必須のサブ要素では、次を指定します。

- <name>は、アプリケーション・ロールの名前を指定します。

- <class>は、アプリケーション・ロールを実装するクラスの完全修飾名を指定します。

オプションのサブ要素では、次のものを指定できます。

- <description>は、アプリケーション・ロールに関する詳細情報を提供します。

- <display-name>は、GUIインタフェースで使用されるような、アプリケーション・ロールの表示名を指定します。

- <guid>は、アプリケーション・ロールを参照するためのグローバル一意識別子を指定します。これは内部使用専用です。

- <members>は、このアプリケーション・ロールのメンバーであるユーザー、ロールまたはその他のアプリケーション・ロールを指定します。

- <uniquename>は、アプリケーション・ロールを参照するための一意の名前を指定します。これは内部使用専用です。

親要素

<app-roles>

子要素

<class>、<description>、<display-name>、<guid>、<members>、<name>、<uniquename>

繰返し

必須(1つ以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

例

<policy-store>を参照してください。

<app-roles>

この要素は、アプリケーション・ロールのセットを指定します。

親要素

<application>

子要素

<app-role>

繰返し

オプション(0または1つ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
...

例

<policy-store>を参照してください。

<application>

この要素は、アプリケーションのロールとポリシーを指定します。

必須のサブ要素は、アプリケーションに関する次の情報を指定します。

- <name>は、アプリケーションの名前を指定します。

オプションのサブ要素では、次のものを指定できます。

- <description>は、アプリケーション、およびそのロールとポリシーに関する情報を提供します。

- <app-roles>は、任意のアプリケーション・レベルのロールを指定します。

- <jazn-policy>は、任意のアプリケーション・レベルのポリシーを指定します。

親要素

<applications>

子要素

<app-roles>、<description>、<jazn-policy>、<name>、<permission-sets>、<resource-types>、<resources>、<role-categories>

繰返し

必須(1つ以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
...

例

<policy-store>を参照してください。

<applications>

この要素は、アプリケーションのセットを指定します。

親要素

<policy-store>

子要素

<application>

繰返し

オプション(0または1つ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
...

例

例については、「<policy-store>」を参照してください。

<attribute>

この要素は、アプリケーション・ロールの属性を指定します。

親要素

<extended-attributes>

子要素

<name>、<values>

繰返し

必須(1つ以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<guid> {0 or 1}

<class>

この要素は、構成ファイル内のどの場所にあるかに応じて複数の値を指定します。

- <app-role>要素内では、<class>は、アプリケーション・ロールを実装するクラスの完全修飾名を指定します。

<app-role>
...
<class>oracle.security.jps.service.policystore.ApplicationRole</class>

- <member>要素内では、<class>は、ロール・メンバーを実装するクラスの完全修飾名を指定します。

<app-role>
...
<members>
<member>
...
<class>
weblogic.security.principal.WLSUserImpl
</class>

- <permission>要素(パーミッションをプリンシパルに付与する要素)内では、<class>は、パーミッションを実装するクラスの完全修飾名を指定します。値では、大文字と小文字は区別されません。

<jazn-policy>
<grant>
...
<permissions>
<permission>
<class>java.io.FilePermission</class>

- <principal>要素(パーミッションをプリンシパルに付与するための要素)内では、プリンシパル・クラス(一連のパーミッションを付与されるプリンシパルを表すためにインスタンス化されたクラス)の完全修飾名を指定します。

<jazn-policy>
<grant>
...
<grantee>
<principals>
<principal>
...
<class>oracle.security.jps.service.policystore.TestUser</class>

親要素

<app-role>、<member>、<principal>または<permission>

子要素

なし

繰返し

必須(1つのみ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
...
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
...
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

例については、「<jazn-policy>」および「<policy-store>」を参照してください。

<codesource>

この要素は、パーミッションの付与対象のコードのURLを指定します。

ポリシー構成には、<codesource>要素に加え、<principals>要素も使用できます。どちらの要素も、<grantee>要素の子で、該当のパーミッションが付与される対象を指定します。

<codesource> URLの指定で使用できる変数については、<url>を参照してください。

親要素

<grantee>

子要素

<url>

繰返し

オプション(0または1つ)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<credentials>

この要素は、ユーザーの認証パスワードを指定します。資格証明は、デフォルトでは、不明瞭化されたフォームになっています。

親要素

<user>

子要素

なし

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}

例

<jazn-realm>を参照してください。

<description>

この要素は、項目の文字情報を提供するテキスト文字列を指定します。

親要素

<app-role>、<application>、<grant>、<role>または<user>

子要素

なし

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
...
<description>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
...
<description>  {0 or 1}
...

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
...
<description> {0 or 1}

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}

例

fmwadminユーザーの説明は、次のようになります。

<description>User with administrative privileges</description>

他の例については<jazn-realm>を参照してください。

<display-name>

この要素は、項目の名前を指定します。項目は、親要素に応じて、アプリケーション・ロール、ユーザーまたはエンタープライズ・グループのいずれかです。

親要素

<app-role>、<role>または<user>

子要素

なし

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
...

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}

例

fmwadminユーザーの表示名は、次のようになります。

<display-name>Administrator</display-name>

他の例については<jazn-realm>を参照してください。

<extended-attributes>

この要素は、アプリケーション・ロールの複数の属性を指定します。

親要素

<app-role>

子要素

<attribute>

繰返し

オプション(0または1つ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

例

<app-roles>
<app-role>
<name>Knight</name>
<display-name>Fellowship For the Ring</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<extended-attributes>
<attribute>
<name>SCOPE</name>
<values>
<value>Part-I</value>
</values>
</attribute>
</extended-attributes>
</app-role>

<grant>

この要素は、権限の付与先(コードソース、プリンシパル・セットまたはその両方)と、割り当てるパーミッションを指定します。

親要素

<jazn-policy>

子要素

<description>、<grantee>、<permissions>、<permission-sets>

繰返し

オプション(ゼロ個以上)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<grantee>

この要素は、パラレルの<permissions>要素と組み合せて使用され、パーミッションの付与の対象(プリンシパル・セット、コードソースまたはその両方)を指定します。

親要素

<grant>

子要素

<codesource>、<principals>

繰返し

オプション(0または1つ)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<guid>

この要素は、内部使用専用です。これは、項目を参照するためのグローバル一意識別子(GUID)を指定します。

親要素に応じて、参照される項目は、アプリケーション・ロール、アプリケーション・ロール・メンバー、プリンシパル、エンタープライズ・グループまたはユーザーのいずれかになり、項目を一意に識別します。GUIDは、OPSSによって生成され、内部で使用されることがあります。

親要素

<app-role>、<member>、<principal>、<role>または<user>

子要素

なし

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
...

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
...

例

<jazn-realm>を参照してください。

<jazn-data>

この要素は、system-jazn-data.xmlファイルの最上位レベルの要素を指定します。

属性

の属性" title="<jazn-data>要素の属性" width="100%">

名前

説明

schema-major-version

system-jazn-data.xml XSDのメジャー・バージョン番号を指定します。この属性の値は、Oracle Fusion Middleware 11gで使用される場合は、11に固定されています。

schema-minor-version

system-jazn-data.xml XSDのマイナー・バージョン番号を指定します。この属性の値は、Oracle Fusion Middleware 12.2.1実装で使用される場合は、0に固定されています。

親要素

該当なし

子要素

<jazn-policy>、<jazn-realm>、<policy-store>

繰返し

必須(1つのみ)

<jazn-data ... >  {1}
<jazn-realm>  {0 or 1}
...

<policy-store> {0 or 1}
...

<jazn-policy> {0 or 1}
...

例

<jazn-data
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation=
"http://xmlns.oracle.com/oracleas/schema/jazn-data-11_0.xsd">
...
</jazn-data

<jazn-policy>

この要素は、権限受領者(プリンシパルまたはコードソース)をパーミッションに関連付けるポリシー付与を指定します。

この要素は、system-jazn-data.xmlファイルの次の2つの場所で使用できます。

- <jazn-data>要素の下では、グローバル・ポリシーを指定します。

- <application>要素の下では、アプリケーション・レベルのポリシーを指定します。

親要素

<application>または<jazn-data>

子要素

<grant>

繰返し

オプション(0または1つ)

<jazn-data> {1}
<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
...
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

jazn-policyの例

これは、jazn-policyの最初の例です。

<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.TestUser
</class>
<name>jack</name>
</principal>
<principal>
<class>
oracle.security.jps.service.policystore.TestUser
</class>
<name>jill</name>
</principal>
</principals>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getContext</name>
</permission>
<permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

これは、jazn-policyの2番目の例です。

<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.TestAdminRole
</class>
<name>Farm=farm1,name=FullAdministrator</name>
</principal>
</principals>
<codesource>
<url>file://some-path</url>
</codesource>
</grantee>
<permissions>
permission>
<class>javax.management.MBeanPermission</class>
<name>
oracle.as.management.topology.mbeans.InstanceOperations#getAttribute
</name>
<actions>invoke</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

<jazn-realm>

この要素は、セキュリティ・レルムと、各レルムのユーザーを指定します。これは、ユーザーおよびロール情報の最上位レベルの要素です。

属性

の属性" title="<jazn-realm>要素の属性" width="100%">

名前

説明

デフォルト

この要素の下に定義されているレルムのうちどれがデフォルトのレルムであるのかを指定します。この属性の値は、いずれかの<realm>サブ要素の下位にある<name>値に一致する必要があります。
値: 文字列

デフォルト: 該当なし(必須)

親要素

<jazn-data>

子要素

<realm>

繰返し

オプション(0または1つ)

<jazn-data>  {1}
<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
...

例

<jazn-data ... >
...
<jazn-realm default="jazn.com">
<realm>
<name>jazn.com</name>
<users>
<user deactivated="true">
<name>anonymous</name>
<guid>61FD29C0D47E11DABF9BA765378CF9F3</guid>
<description>The default guest/anonymous user</description>
</user>
<user>
<name>developer1</name>
<credentials>!password</credentials>
</user>
<user>
<name>developer2</name>
<credentials>!password</credentials>
</user>
<user>
<name>manager1</name>
<credentials>!password</credentials>
</user>
<user>
<name>manager2</name>
<credentials>!password</credentials>
</user>
<!-- these are for testing the admin role hierachy. -->
<user>
<name>farm-admin</name>
<credentials>!password</credentials>
</user>
<user>
<name>farm-monitor</name>
<credentials>!password</credentials>
</user>
<user>
<name>farm-operator</name>
<credentials>!password</credentials>
</user>
<user>
<name>farm-auditor</name>
<credentials>!password</credentials>
</user>
<user>
<name>farm-auditviewer</name>
<credentials>!password</credentials>
</user>
</users>
<roles>
<role>
<name>users</name>
<guid>31FD29C0D47E11DABF9BA765378CF9F7</guid>
<display-name>users</display-name>
<description>users role for rmi/ejb access</description>
</role>
<role>
<name>ascontrol_appadmin</name>
<guid>51FD29C0D47E11DABF9BA765378CF9F7</guid>
<display-name>ASControl App Admin Role</display-name>
<description>
Application Administrative role for ASControl
</description>
</role>
<role>
<name>ascontrol_monitor</name>
<guid>61FD29C0D47E11DABF9BA765378CF9F7</guid>
<display-name>ASControl Monitor Role</display-name>
<description>Monitor role for ASControl</description>
</role>
<role>
<name>developers</name>
<members>
<member>
<type>user</type>
<name>developer1</name>
</member>
<member>
<type>user</type>
<name>developer2</name>
</member>
</members>
</role>
<role>
<name>managers</name>
<members>
<member>
<type>user</type>
<name>manager1</name>
</member>
<member>
<type>user</type>
<name>manager2</name>
</member>
</members>
</role>
</roles>
</realm>
</jazn-realm>
...
</jazn-data>

<matcher-class>

この要素は、リソース・タイプのクラスの完全修飾名を指定します。このタイプのリソースに対する問合せは、このクラスに委任されます。値では、大文字と小文字が区別されます。

親要素

<resource-type>

子要素

なし

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<resource-types> {0 or 1}
<resource-type> {1 or more}
<name> {1}
<display-name> {1}
<description> {0 or 1}
<provider-name> {1}
<matcher-class> {1}
<actions-delimiter> {1}
<actions> {1 or more}

例

例については、<resource-type>を参照してください。

<member>

この要素は、<role>要素や<app-role>要素などのセットのメンバーを指定します。

- <role>要素の下では、エンタープライズ・グループのメンバーを指定します。メンバーには、ユーザーまたはその他のエンタープライズ・グループを指定できます。<name>サブ要素はメンバーの名前を指定し、<type>サブ要素はメンバー・タイプ(ユーザーまたはエンタープライズ・グループ)を指定します。

- <app-role>要素の下では、アプリケーション・ロールのメンバーを指定します。メンバーには、ユーザー、エンタープライズ・グループまたはアプリケーション・ロールを指定できます。<name>サブ要素はメンバーの名前を指定し、<class>サブ要素はメンバーを実装するクラスを指定します。メンバー・タイプは、<class>要素で決まります。

親要素

<members>

子要素

- <role>要素の下では、<member>要素には、<name>および<type>という子要素があります。

- <app-role>要素の下では、<member>要素には、<name>、<class>、<uniquename>および<guid>という子要素があります。

繰返し

オプション(ゼロ個以上)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
...
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

例

<jazn-realm>および<policy-store>を参照してください。

<member-resource>

この要素は、パーミッション・セットのリソースを指定します。

親要素

<member-resources>

子要素

<resource-name>、<type-name-ref>、<actions>

繰返し

<member-resources>内に1つ以上必要です。

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<permission-sets> {0 or 1}
<permission-set> {1 or more}
<name> {1}
<member-resources> {1 or more}
<member-resource>   {1 or more}
<resource-name> {1}
<type-name-ref> {1}
<actions> {0 or 1}

例

例については、<permission-set>を参照してください。

<member-resources>

この要素は、メンバー・リソースのセットを指定します。

親要素

<permission-set>

子要素

<member-resource>

繰返し

<permission-sets>内に1つ以上必要です。

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<permission-sets> {0 or 1}
<permission-set> {1 or more}
<name> {1}
<member-resources> {1 or more}
<member-resource>     {1 or more}
<resource-name> {1}
<type-name-ref> {1}
<actions> {0 or 1}

例

例については、<permission-set>を参照してください。

<members>

この要素は、メンバーのセットを指定します。

親要素

<role>、<app-role>

子要素

<member>

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
...
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

例

<jazn-realm>および<policy-store>を参照してください。

<name>

この要素には、ファイル内のこの要素の場所に応じたいくつかの使用方法があります。

- <app-role>要素内では、ポリシー構成のアプリケーション・レベルのロール名を指定します。例:

<name>Farm=farm1,name=FullAdministrator</name>

または、より簡単な例は次のとおりです。

<name>Myrolename</name>

- <application>要素内では、ポリシー・コンテキストIDを指定します。

- <attribute>要素内では、アプリケーション・レベルのロールの追加属性の名前を指定します。

- <member>要素内では、エンタープライズ・グループまたはアプリケーション・ロールのメンバー名を指定します(<member>要素の場所に応じて指定します)。たとえば、fmwadminユーザーがロールのメンバーである場合は、次のようになります。

<name>fmwadmin</name>

- <owner>要素内では、エンタープライズ・グループの所有者の名前を指定します。例:

<name>mygroupowner</name>

- <permission>要素内では、適宜、パーミッション・クラスに有意味なパーミッションの名前を指定します。値では、大文字と小文字が区別されます。例:

<name>
oracle.as.management.topology.mbeans.InstanceOperations#getAttribute
</name>

または

<name>getContext</name>

- <principal>要素(パーミッションをプリンシパルに付与する要素)内では、所定のレルム内のプリンシパルの名前を指定します。例:

<name>Administrators</name>

- <realm>要素内では、レルム名を指定します。例:

<name>jazn.com</name>

- <role>要素内では、レルム内のエンタープライズ・グループの名前を指定します。例:

<name>Administrators</name>

- <user>要素内では、レルム内のユーザーの名前を指定します。例:

<name>fmwadmin</name>

- <resource-type>要素に必須で、リソース・タイプの名前を指定します。例:

<name>restype1</name>

親要素

<app-role>、<application>、<attribute>、<member>、<owner>、<permission>、<principal>、<realm>、<role>または<user>

子要素

なし

繰返し

<permission>以外の親要素内では必須、1つのみ。<permission>内ではオプション、0または1つ。

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<application>
<name>peanuts</name>
<app-roles>
<app-role>
<name>snoopy</name>
<display-name>application role snoopy</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>

.......

例については、「<jazn-policy>」、「<jazn-realm>」および「<policy-store>」を参照してください。

<owner>

この要素は、エンタープライズ・グループの所有者を指定します。所有者は、ロールに対する管理権限を持っています。

所有者は、ユーザーや別のエンタープライズ・グループです。<type>サブ要素は、所有者のタイプを指定します。ロール(グループ)所有者の概念は、特に、BPELやOracle Internet Directoryの機能に関連しています。たとえば、BPELでは、ロール所有者はロールのワークフロー・ルールの作成や更新ができます。

親要素

<owners>

子要素

<name>、<type>

繰返し

オプション(ゼロ個以上)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

<owners>

この要素は、所有者のセットを指定します。

親要素

<role>

子要素

<owner>

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

<permission>

この要素は、権限受領者に付与するパーミッションを指定します。この場合の権限受領者は、ポリシー構成の一環として、プリンシパル・セット、コードソース、またはその両方になります。

親要素

<permissions>

子要素

<actions>、<class>、<name>

繰返し

親要素内で必須(1つ以上)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<permissions>

この要素は、パーミッションのセットを指定します。

<permissions>要素(パラレルの<grantee>要素と組み合せて使用)は、一連の<permission>サブ要素を使用して、付与するパーミッションを指定します。

system-jazn-data.xmlスキーマ定義では、この要素は必須要素として指定されませんが、OPSSランタイムでは、任意の<grant>要素内でこの要素を使用する必要があります。

親要素

<grant>

子要素

<permission>

繰返し

オプション(0または1つ)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<permission-set>

パーミッション・セット(または権限)は、パーミッションのセットを指定します。

親要素

<permission-sets>

子要素

<name>

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<permission-sets> {0 or 1}
<permission-set> {1 or more}
<name> {1}
<member-resources> {1 or more}
<member-resource>     {1 or more}
<resource-name> {1}
<type-name-ref> {1}
<actions> {0 or 1}

例

次の例は、パーミッション・セットの構成を示しています。

<permission-sets>
<permission-set>
<name>permsetName</name>
<member-resources>
<member-resource>
<type-name-ref>TaskFlowResourceType</type-name-ref>         <resource-name>resource1</resource-name>
<actions>customize,view</actions>
</member-resource>
</member-resources>
</permission-set>
</permission-sets>

パーミッション・セットに関して、次の点に注意してください。

- <member-resource>で指定するアクションは、<resource-name-ref>で参照しているリソース・タイプで指定されているアクションから選択する必要があります。

- <member-resources>には、複数の<member-resource>要素を指定できます。

- パーミッション・セットには1つ以上のリソースが必要です。

- プリンシパルで使用されていないパーミッション・セットが存在してもかまいません。

また、パーミッションの名前、説明および表示名では、大文字と小文字が区別されます。

<permission-sets>

この要素は、パーミッション・セットのコレクションを指定します。

親要素

<application>

子要素

<permission-set>

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<permission-sets> {0 or 1}
<permission-set> {1 or more}
<name> {1}
<member-resources> {1 or more}
<member-resource>     {1 or more}
<resource-name> {1}
<type-name-ref> {1}
<actions> {0 or 1}

例

例については、<permission-set>を参照してください。

<policy-store>

この要素は、アプリケーション・ポリシーを構成します。<applications>の下には、各アプリケーションの<application>があります。ポリシーは、各<application>の<jazn-policy>で指定されます。

<jazn-principal-classes>および<jazn-permission-classes>の要素とそれらのサブ要素は、<policy-store>のサブ要素としてsystem-jazn-data.xmlスキーマの定義の中に現れることがありますが、それは後方互換性の確保のみを目的としたものです。

親要素

<jazn-data>

子要素

<applications>

繰返し

オプション(0または1つ)

<jazn-data>  {1}
<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
...

例

<jazn-data ... >
...
<policy-store>
<!--  application policy -->
<applications>
<application>
<name>policyOnly</name>
<jazn-policy>
...
</jazn-policy>
</application>
<application>
<name>roleOnly</name>
<app-roles>
<app-role>
<name>Fellowship</name>
<display-name>Fellowship of the Ring</display-name>
<class>
oracle.security.jps.service.policystore.ApplicationRole
</class>
</app-role>
<app-role>
<name>King</name>
<display-name>Return of the King</display-name>
<class>
oracle.security.jps.service.policystore.ApplicationRole
</class>
</app-role>
</app-roles>
</application>
<application>
<app-roles>
<app-role>
<name>Farm=farm1,name=FullAdministrator</name>
<display-name>farm1.FullAdministrator</display-name>
<guid>61FD29C0D47E11DABF9BA765378CF9F2</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole
</class>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl
</class>
<name>admin</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
...
</jazn-policy>
</application>
...
</applications>
</policy-store
....
</jazn-data

<jazn-policy>の例については、この要素を参照してください。

<principal>

この要素は、ポリシー構成の一環として、<permissions>要素で指定されているパーミッションを付与されるプリンシパルを指定します。<principals>の下に必要です。

サブ要素は、プリンシパルの名前とそれを実装するクラスを指定します。また、オプションで、一意の名前とグローバル一意識別子を指定します(この2つは内部使用のみを目的としています)。

親要素

<principals>

子要素

<class>、<guid>、<name>、<uniquename>

繰返し

オプション(ゼロ個以上)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<principals>

この要素は、プリンシパルのセットを指定します。

ポリシー構成では、<principals>要素あるいは<codesource>要素は、<grantee>要素の下で使用され、該当のパーミッションが付与される対象を指定します。<principals>要素は、パーミッションを付与されるプリンシパル・セットを指定します。

サブジェクトがこれらのパーミッションを取得するには、サブジェクトにプリンシパルがすべて含まれている必要があります。

親要素

<grantee>

子要素

<principal>

繰返し

オプション(0または1つ)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

<jazn-policy>を参照してください。

<provider-name>

この要素は、リソース・タイプ・プロバイダの名前を指定します。リソースは、ドメイン・セキュリティ・ストアの外部の場所にあります。値では、大文字と小文字は区別されません。

親要素

<resource-type>

子要素

なし

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<resource-types> {0 or 1}
<resource-type> {1 or more}
<name> {1}
<display-name> {1}
<description> {0 or 1}
<provider-name> {1}
<matcher-class> {1}
<actions-delimiter> {1}
<actions> {0 or more}

例

例については、<resource-type>を参照してください。

<realm>

この要素は、セキュリティ・レルムと、レルム内のユーザーおよびロールを指定します。

親要素

<jazn-realm>

子要素

<name>、<roles>、<users>

繰返し

オプション(ゼロ個以上)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
...

例

<jazn-realm>を参照してください。

<resource>

この要素は、アプリケーション・リソースを指定し、そのリソースに関する情報を含みます。

親要素

<resources>

子要素

<name>、<description>、<display-name>、<type-name-ref>

繰返し

<resources>の下に1つ以上必要です。

<resources> (0 or more)
<resource> (1 or more)
<name> (1)
<display-name> (1)
<description> {0 or 1}
<type-name-ref> (1)

例

次の例は、リソース(インスタンス)の構成を示しています。

<resources>
<resource>
<name>resource1</name>
<display-name>Resource1DisplayName</display-name>
<description>Resource1 Description</description>
<type-name-ref>TaskFlowResourceType</type-name-ref>
</resource>
</resources>

名前、説明および表示名では、大文字と小文字が区別されることに注意してください。

<resources>

この要素は、アプリケーション・リソースの集合を指定します。

親要素

<application>

子要素

<resource>

繰返し

オプション(ゼロ個以上)

<resources> (0 or more)
<resource> (1 or more)
<name> (1)
<display-name> (1)
<description> {0 or 1}
<type-name-ref> (1)

例

例については、<resource>を参照してください。

<resource-name>

この要素は、パーミッション・セット内のメンバー・リソースを指定します。値では、大文字と小文字が区別されます。

親要素

<member-resource>

子要素

なし

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<permission-sets> {0 or 1}
<permission-set> {1 or more}
<name> {1}
<member-resources> {1 or more}
<member-resource>     {1 or more}
<resource-name> {1}
<type-name-ref> {1}
<actions> {0 or 1}

例

例については、<permission-set>を参照してください。

<resource-type>

この要素は、フロー、ジョブ、Webサービスなど、保護アーティファクトのタイプを指定します。値では、大文字と小文字は区別されません。

親要素

<resource-types>

子要素

<name>、<display-name>、<description>、<actions>、<actions-delimiter>、<matcher-class>、<provider-name>

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<resource-types> {0 or 1}
<resource-type> {1 or more}
<name> {1}
<display-name> {1}
<description> {0 or 1}
<provider-name> {1}
<matcher-class> {1}
<actions-delimiter> {1}
<actions> {0 or more}

例

次の例は、リソース・タイプの構成を示しています。

<resource-types>
<resource-type>
<name>TaskFlowResourceType</name>
<display-name>TaskFlowResourceType_disp</display-name>
<description>Resource Type for Task Flow</description>
<provider-name>resTypeProv</provider-name>
<matcher-class>
oracle.adf.controller.security.TaskFlowPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>customize,view</actions>
</resource-type>
</resource-types>

リソース・タイプの指定では次の点が適用されます。

- 名前は必須で、大文字と小文字は区別されません。

- プロバイダ名はオプションで、大文字と小文字は区別されません。セキュリティ・ストア以外のストアで管理しているリソースがある場合に、プロバイダを使用します。
指定すると、<provider-name>要素のクラスがリソース・ファインダとして使用されます。このタイプのリソースに対する問合せ(ResourceManagerメソッドを使用)は、組込みリソース・ファインダを使用するかわりに、このクラスに委任されます。

- クラスの指定は必須で、大文字と小文字が区別されます。

- 説明および表示名の指定はオプションで、大文字と小文字は区別されません。

- アクションの指定はオプションで、大文字と小文字が区別されます。リソース・タイプのアクションのリストは空でもかまいません。空のアクション・リストは、リソース・タイプのインスタンスに対するアクションは外部で決定されることを示します。

<resource-types>

この要素は、リソース・タイプのセットを指定します。

親要素

<application>

子要素

<resource-type>

繰返し

オプション(ゼロ個以上)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
...
<role-categories> {0 or 1}
...
<resource-types> {0 or 1}
<resource-type> {1 or more}
<name> {1}
<display-name> {1}
<description> {0 or 1}
<provider-name> {1}
<matcher-class> {1}
<actions-delimiter> {1}
<actions> {0 or more}

例

例については、<resource-type>を参照してください。

<role>

この要素は、アプリケーション・レベルのロールではなく、エンタープライズ・セキュリティ・ロールを指定します。また、そのロールのメンバー(およびオプションで所有者)も指定します。

親要素

<roles>

子要素

<description>、<display-name>、<guid>、<members>、<name>、<owners>

繰返し

オプション(ゼロ個以上)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

例

<jazn-realm>を参照してください。

<role-categories>

この要素は、<role-category>要素の親要素を指定します。

親要素

<application>

子要素

<role-category>

繰返し

オプション(0または1つ)

<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<role-categories> {0 or 1
<role-category> {1 or more}
<name> {1}
<description> {0 or 1}
<display-name> {0 or 1}

例

例については、第17.3.3.1項「checkPermissionの使用」を参照してください。

<role-category>

この要素は、アプリケーション・ロールのフラット・セットを指定します。

親要素

<role-categories>

子要素

<name>、<display-name>、<description>、<members>

繰返し

オプション(0または1つ)

<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<role-categories> {0 or 1}
<role-category> {1 or more}
<name> {1}
<description>{0 or 1}
<display-name>{0 or 1}
<members> {0 or 1}

例

例については、第17.3.3.1項「checkPermissionの使用」を参照してください。

<role-name-ref>

この要素は、ロール・カテゴリ内のアプリケーション・ロールを指定します。

親要素

<members>

子要素

なし

繰返し

オプション(0または1つ)

<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<role-categories> {0 or 1}
<role-category> {1 or more}
<name> {1}
<description> {0 or 1}
<members> {0 or 1}
<role-name-ref> {1}

<roles>

この要素は、セキュリティ・レルムに属するエンタープライズ・ロールのセットを指定します。

親要素

<realm>

子要素

<role>

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

例

<jazn-realm>を参照してください。

<type>

この要素は、エンタープライズ・グループ・メンバーまたはロール所有者のタイプを指定します。具体的には、メンバーや所有者がユーザーなのか別のロールなのかを指定します。

<type>user</type>

または

<type>role</type>

親要素

<member>または<owner>

子要素

なし

繰返し

必須(1つのみ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
...
<roles>  {0 or 1}
<role>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<members>  {0 or 1}
<member>  {0 or more}
<type>  {1}
<name>  {1}
<owners>  {0 or 1}
<owner>  {0 or more}
<type>  {1}
<name>  {1}

例

<jazn-realm>を参照してください。

<type-name-ref>

この要素は、リソースのリソース・タイプを指定します。

親要素

<member-resource>、<resource>

子要素

なし

繰返し

1つのみ。<resource>または<member-resource>に必要です。

<resources> (0 or more)
<resource> (1 or more)
<name> (1)
<display-name> (1)
<description> {0 or 1}
<type-name-ref> (1)

例

例については、<resource>を参照してください。

<uniquename>

内部使用向けのこの要素は、項目を参照するための一意の名前を指定する文字列値をとります。(JpsPrincipalクラスは、GUIDと一意の名前を使用してプリンシパルを一意に識別できます。GUIDと一意の名前は両方とも、基礎となるポリシー・プロビジョニングAPIによって算出されます。)親要素に応じて、項目はアプリケーション・ロール、アプリケーション・ロール・メンバー(エンタープライズ・グループ・メンバーではない)、またはプリンシパルになりえます。項目を一意に識別します。一意の名前は、Oracle Platform Securityによって生成され、内部で使用されることがあります。

アプリケーション・ロールの一意の名前は、appid=application_name, name=actual_rolenameの形式になります。例:

<principal>
<class>
oracle.security.jps.service.policystore.adminroles.AdminRolePrincipal
</class>
<uniquename>
APPID=App1,name="FARM=D.1.2.3,APPLICATION=PolicyServlet,TYPE=OPERATOR"
</uniquename>
</principal>

親要素

<app-role>、<member>または<principal>

子要素

なし

繰返し

オプション(0または1つ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
...
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

<url>

この要素は、パーミッションを付与されたコードのURLを指定します。

次の点に注意してください:

- URL値は単一クラスに制限できません。

- 接尾辞.jarが付いたURL値は、指定されたディレクトリにあるJARファイルに一致します。

- 接尾辞/が付いたURL値は、指定されたディレクトリにあるすべてのクラス・ファイルに一致します(JARファイルには一致しません)。

- 接尾辞/*が付いたURL値は、指定されたディレクトリにあるすべてのファイル(クラス・ファイルとJARファイルの両方)に一致します。

- 接尾辞/-が付いたURL値は、指定されたディレクトリにあるすべてのファイル(クラス・ファイルとJARファイルの両方)に一致し、サブディレクトリにあるすべてのファイルに再帰的に一致します。

- システム変数oracle.deployed.app.dirとoracle.deployed.app.extを使用することによって、プラットフォームとは無関係なURLを指定できます。

親要素

<codesource>

子要素

なし

繰返し

親要素内で必須(1つのみ)

<jazn-policy> {0 or 1}
<grant> {0 or more}
<description> {0 or 1}
<grantee> {0 or 1}
<principals> {0 or 1}
<principal> {0 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}
<codesource> {0 or 1}
<url> {1}
<permissions> {0 or 1}
<permission> {1 or more}
<class> {1}
<name> {0 or 1}
<actions> {0 or 1}

例

次の例は、システム変数oracle.deployed.app.dirとoracle.deployed.app.extを使用して、サーバー・プラットフォームとは無関係なURLを指定する方法を示しています。

アプリケーション権限でサーバー・プラットフォームとは異なるコードソースURLが必要だとします。

<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/myApp/-</url>
</codesource>
</grantee>
<permissions> ... </permissions>
</grant>

その後、次のシステム変数設定を使用します。

-Doracle.deployed.app.dir=${DOMAIN_HOME}/servers/${SERVER_NAME}/tmp/_WL_user
-Doracle.deployed.app.ext=/-

次のように指定できます。

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}</url>
</codesource>
</grantee>
<permissions> ... </permissions>
</grant>

<user>

この要素は、レルム内のユーザーを指定します。

属性

の属性" title="<user>要素の属性" width="100%">

名前

説明

deactivated

ユーザーが有効かどうかを指定します。
ユーザーを構成ファイル内に保持しても、現在有効なユーザーにしない場合は、trueに設定します。これは、たとえば、jazn.comレルムのanonymousユーザーの初期構成です。

値: trueまたはfalse

デフォルト値: false

親要素

<users>

子要素

<name>、<display-name>、<description>、<guid>、<credentials>

繰返し

オプション(ゼロ個以上)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
...

例

<jazn-realm>を参照してください。

<users>

この要素は、レルムに属するユーザーのセットを指定します。

親要素

<realm>

子要素

<user>

繰返し

オプション(0または1つ)

<jazn-realm>  {0 or 1}
<realm>  {0 or more}
<name>  {1}
<users>  {0 or 1}
<user>  {0 or more}
<name>  {1}
<display-name>  {0 or 1}
<description>  {0 or 1}
<guid>  {0 or 1}
<credentials>  {0 or 1}
<roles>  {0 or 1}
...

例

<jazn-realm>を参照してください。

<value>

この要素は、属性の値を指定します。<extended-attributes>要素を使用してアプリケーション・レベルのロールに追加属性を指定します。

親要素

<attribute>

子要素

なし

繰返し

親要素内で必須(1つのみ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

例

<app-roles>
<app-role>
<name>Knight</name>
<display-name>Fellowship of the Ring</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<extended-attributes>
<attribute>
<name>SCOPE</name>
<values>
<value>Part-I</value>
</values>
</attribute>
</extended-attributes>
</app-role>

<values>

この要素は、属性値をそれぞれ指定する値のセットを指定します。属性ごとに複数の値を指定できます。

親要素

<attribute>

子要素

<value>

繰返し

親要素内で必須(1つのみ)

<policy-store> {0 or 1}
<applications> {0 or 1}
<application> {1 or more}
<name> {1}
<description> {0 or 1}
<app-roles> {0 or 1}
<app-role> {1 or more}
<name> {1}
<class> {1}
<display-name> {0 or 1}
<description> {0 or 1}
<guid> {0 or 1}
<uniquename> {0 or 1}
<extended-attributes> {0 or 1}
<attribute> {1 or more}
<name> {1}
<values> {1}
<value>  {1 or more}
<members> {0 or 1}
<member> {1 or more}
<name> {1}
<class> {1}
<uniquename> {0 or 1}
<guid> {0 or 1}

例

<app-roles>
<app-role>
<name>Knight</name>
<display-name>Fellowship of the Ring</display-name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<extended-attributes>
<attribute>
<name>SCOPE</name>
<values>
<value>Part-I</value>
</values>
</attribute>
</extended-attributes>
</app-role>

C Oracle Fusion Middleware監査フレームワーク・リファレンス

この付録では、Oracle Fusion Middleware監査フレームワーク(OFM監査フレームワーク)を使用して監査データからレポートを作成および開発する方法について説明します。

この付録の内容は次のとおりです。

- 監査イベント

- 監査スキーマ

- 監査フィルタ式の構文

- 監査ファイルのネーミングおよびロギング

この付録では、Oracle Business Intelligence Publisher 10gのレポート・テンプレート・モデルに基づいたレポートについて説明します。監査動的モデルに基づいた別の方法の詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

C.1 監査イベント

次の各項では、監査で使用するコンポーネント、イベントおよび属性について説明します。

- 監査可能なコンポーネント

- システム・カテゴリとイベント

- OPSSイベントの属性

C.1.1 監査可能なコンポーネント

OFM監査フレームワークは、次のようなOracle Fusion Middlewareコンポーネントおよびアプリケーションを監査するための基礎となります。

- OPSS

- Oracle Web Services Manager

- Oracle Directory Integration Platform

- Oracle HTTP Server

- OID

この付録では、OPSSによって生成されたイベントについてのみ監査情報を示します。他のコンポーネントおよびアプリケーションでの監査の詳細は、それぞれの管理ガイドを参照してください。

C.1.2 システム・カテゴリとイベント

OFM監査フレームワークでは、次のような主要なプラットフォーム・セキュリティ・サービスのイベントを監査できます。

- OPSSサービスのシステム・イベント

- コアOPSS

- アイデンティティ・ガバナンス・サービス

- アイデンティティ仮想化

次の各表に具体的なイベントを示します。

- 表C-1「システム・カテゴリとイベント」

- 表C-2「コアOPSSのイベント」

- 表C-3「アイデンティティ・ガバナンス・サービスのイベント」

- 表C-4「Identity Virtualization Libraryのイベント」

表C-1 システム・カテゴリとイベント

カテゴリ

イベント

説明

UserSession

UserLogin

UserLogins

複数層アプリケーションでは、内部の層が次の層にログインするために、特別なユーザーIDを使用することがよくあります。このようなログインは、内部ログインという別のカテゴリに分けて考えます。ユーザー・ログイン/ログアウトのイベントでは、通常のユーザーによるアクションのみが記録されます。

UserLogout

UserLogouts

エンド・ユーザーまたは管理者がログアウトします。

認証

UserLogin/InternalLoginに似ていますが、セッションは作成されないため、対応するUserLogout/InternalLogoutは存在しません。通常、このイベントは下位レイヤーによって生成されますが、ログインは上位レイヤーによって生成されます。

InternalLogin

2つの層の間での内部ログイン。

InternalLogout

2つの層の間での内部ログアウト。

QuerySession

ログイン・ユーザー用のセッション・オブジェクト内の属性を問い合せます。

ModifySession

ログイン・ユーザー用のセッション・オブジェクト内の属性を変更します。

Authorization

CheckAuthorization

認可イベントのセット。

Data Access

CreateDataItem

データ項目の作成

DeleteDataItem

データ項目を削除します。

QueryDataItemAttributes

データ項目に関連付けられる属性を問い合せます。

ModifyDataItemAttributes

データ項目に関連付けられる属性(アクセスなど)を変更します。

AccountManagement

ChangePassword

CreateAccount

ユーザー、グループまたは任意のプリンシパルのアカウントを作成します。

DeleteAccount

ユーザー、グループまたは他のプリンシパルのアカウントを削除します。

EnableAccount

ユーザー、グループまたは他のプリンシパルのアカウントを有効にします。

DisableAccount

ユーザー、グループまたは他のプリンシパルのアカウントを無効にします。

QueryAccount

ユーザーのアカウントを問い合せます。

ModifyAccount

アカウント属性を変更します。

ServiceManagement

InstallService

サービスまたはアプリケーションをインストールまたはアップグレードします。

RemoveService

サービスまたはアプリケーションをアンインストールします。

QueryServiceConfig

サービスまたはアプリケーションの構成を問い合せます。

ModifyServiceConfig

サービスまたはアプリケーションの構成を変更します。

DisableService

サービスまたはアプリケーションを停止または無効化します。

EnableService

サービスまたはアプリケーションを開始または有効化します。

ServiceUtilize

InvokeService

サービスまたはアプリケーションをコールします。

TerminateService

アプリケーション自体からの要求、あるいはユーザー・アクションまたは管理アクションに対するドメインの介入によって、サービスまたはアプリケーションが停止します。

QueryProcessContext

現在進行中のコンテキストに関連付けられた属性を問い合せます。

ModifyProcessContext

現在進行中のコンテキストに関連付けられた属性を変更します。

PeerAssocManagement

CreatePeerAssoc

システム・コンポーネント間の通信チャネルを作成します。

TerminatePeerAssoc

システム・コンポーネント間の通信チャネルを停止します。

QueryAssocContext

システム・コンポーネント間の通信チャネルに関連する属性を問い合せます。

ModifyAssocContext

システム・コンポーネント間の通信チャネルに関連する属性を変更します。

システム・コンポーネント間の通信チャネル

ReceiveDataViaAssoc

関連するピアからデータを受信します。

SendDataViaAssoc

関連するピアにデータを送信します。

DataItemContentAccess

CreateDataItemAssoc

ファイルなどのデータ項目を開きます。

TerminateDataItemAssoc

ファイルなどのデータ項目を閉じます。

QueryDataItemAssocContext

データ項目の属性を問い合せます(アクセス・モード、サイズ制限、アクセス・パスなど)。

ModifyDataItemAssocContext

データ項目の属性を変更します。

QueryDataItemContents

データ項目の読取りを行います。

ModifyDataItemContent

データ項目に書込みまたは追加を行います。

Exceptional

StartSystem

システム・ホストをブートします。

ShutdownSystem

システムを停止します。

ResourceExhausted

データ記憶域や通信のエンドポイントなどのリソースが不足しています。

ResourceCorrupted

データ記憶域などのリソースの整合性が一致しません。

BackupDatastore

データ・ストアのバックアップ・コピーを作成します。

RecoverDatastore

バックアップ・コピーからデータ・ストアをリカバリします。

AuditService

ConfigureAuditPolicy

監査イベントのフィルタ処理など、監査を制御するパラメータを変更します。

ConfigureAuditRepository

監査記憶域タイプを構成します。

表C-2 コアOPSSのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

Authorization

CheckPermission

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、CodeSource、Principals、InitiatorGUID、Subject、PermissionAction、PermissionTarget、PermissionClass

CheckSubject

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、CodeSource、Principals、InitiatorGUID、Subject

IsAccessAllowed

CredentialManagement

CreateCredential

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、mapName、key、CodeSource、Principals、InitiatorGUID

DeleteCredential

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、mapName、key、CodeSource、Principals、InitiatorGUID

AccessCredential

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、mapName、key、CodeSource、Principals、InitiatorGUID

ModifyCredential

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、mapName、key、CodeSource、Principals、InitiatorGUID

PolicyManagement

PolicyGrant

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、CodeSource、Principals、InitiatorGUID、PermissionAction、PermissionTarget、PermissionClass、PermissionScope

PolicyRevoke

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、CodeSource、Principals、InitiatorGUID、PermissionAction、PermissionTarget、PermissionClass、PermissionScope

RoleManagement

RoleMembershipAdd

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、CodeSource、Principals、InitiatorGUID、ApplicationRole、EnterpriseRoles、PermissionScope

RoleMembershipRemove

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Roles、CodeSource、Principals、InitiatorGUID、ApplicationRole、EnterpriseRoles、PermissionScope

RolePolicyManagement

RolePolicyCreation

CodeSource, Principals, InitiatorGUID, InitiatorDN, ManagedApplication, PolicyName, PolicyApplicationRolePrincipals, RoleMembers, PolicyRules, ResourceNames, ResourceNameExpressions, PolicyApplicationRolePrincipalsOld, RoleMembersOld, PolicyRulesOld, ResourceNamesOld, ResourceNameExpressionsOld

,RolePolicyModification

CodeSource, Principals, InitiatorGUID, InitiatorDN, ManagedApplication, PolicyName, PolicyApplicationRolePrincipals, RoleMembers, PolicyRules, ResourceNames, ResourceNameExpressions, PolicyApplicationRolePrincipalsOld, RoleMembersOld, PolicyRulesOld, ResourceNamesOld, ResourceNameExpressionsOld

RolePolicyDeletion

CodeSource, Principals, InitiatorGUID, InitiatorDN, ManagedApplication, PolicyName, PolicyApplicationRolePrincipals, RoleMembers, PolicyRules, ResourceNames, ResourceNameExpressions, PolicyApplicationRolePrincipalsOld, RoleMembersOld, PolicyRulesOld, ResourceNamesOld, ResourceNameExpressionsOld

ResourceManagement

ResourceCreation

InitiatorDN, GUID, CodeSource, Principals, Permission, PermissionClass, ManagedApplication, ResName, ResTypeName, PolicyDomainName, ResourceAttributes, Cascade, ModifiedAttributeName, ModifiedAttributeValue, ModifiedAttributeValueOld, ResourceAttributesOld, SqlPredicate, SqlPredicateOld, XmlExpression, XmlExpressionOld,

ResourceDeletion

InitiatorDN, GUID, CodeSource, Principals, Permission, PermissionClass, ManagedApplication, ResName, ResTypeName, PolicyDomainName, ResourceAttributes, Cascade, ModifiedAttributeName, ModifiedAttributeValue, ModifiedAttributeValueOld ResourceAttributesOld, SqlPredicate, SqlPredicateOld, XmlExpression, XmlExpressionOld

ResourceModification

InitiatorDN, GUID, CodeSource, Principals, Permission, PermissionClass, ManagedApplication, ResName, ResTypeName, PolicyDomainName, ResourceAttributes, Cascade, ModifiedAttributeName, ModifiedAttributeValue, ModifiedAttributeValueOld, ResourceAttributesOld, SqlPredicate SqlPredicateOld, XmlExpression, XmlExpressionOld

KeyStoreManagement

CreateKeyStore

stripeName, keystoreName, alias, operation, CodeSource, Principals, InitiatorGUID

DeleteKeyStore

stripeName, keystoreName, alias, operation, CodeSource, Principals, InitiatorGUID

ModifyKeyStore

stripeName, keystoreName, alias, operation, CodeSource, Principals, InitiatorGUID

PermissionSet
Management

PermissionSetCreation

InitiatorDN, GUID, CodeSource, Principals, Permission, PermissionClass, ManagedApplication, PermissionSetName, PolicyDomainName, ResourceActions, Cascade, ModifiedAttributeName, ModifiedAttributeValue, ModifiedAttributeValueOld, ResourceActionsOld

PermissionSetDeletion

InitiatorDN, GUID, CodeSource, Principals, Permission, PermissionClass, ManagedApplication, PermissionSetName, PolicyDomainName, ResourceActions, Cascade, ModifiedAttributeName, ModifiedAttributeValue, ModifiedAttributeValueOld, ResourceActionsOld

PermissionSetModification

InitiatorDN, GUID, CodeSource, Principals, Permission, PermissionClass, ManagedApplication, PermissionSetName, PolicyDomainName, ResourceActions, Cascade, ModifiedAttributeName, ModifiedAttributeValue, ModifiedAttributeValueOld, ResourceActionsOld

表C-3 アイデンティティ・ガバナンス・サービスのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

認証

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

DataAccess

CreateDataItem

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

DeleteDataItem

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

ModifyDataItemAttributes

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

表C-4 Identity Virtualization Libraryのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

LDAPEntryAccess

Add

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

Delete

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

Modify

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

Rename

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

UserSession

UserLogin.FAILURESONLY

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

DataAccess

QueryDataItemAttributes

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

ModifyDataItemAttributes

Initiator、EventType、EventStatus、MessageText、ApplicationName、AuditService:TransactionId、ContextFields、ECID、EventCategory、FailureCode、MajorVersion、MinorVersion、RID、RemoteIP、Resource、Roles、SessionId、Target、ThreadId、AuthenticationMethod

関連項目:

第13.5.2項「監査イベントとイベント・カテゴリ」

C.1.3 OPSSイベントの属性

表C-5に、監査イベントの属性を示します。

表C-5 監査イベントの属性

ネームスペース

属性名

説明

共通

ApplicationName

Java EEアプリケーション名。

AuditUser

アプリケーションを実行しているユーザーのユーザー名を識別する属性。

ComponentData

スキーマにコンポーネント固有の表がない場合に、コンポーネント固有のデータが格納される場所。

ComponentName

このコンポーネントの名前。

ComponentType

コンポーネントのタイプ

ContextFields

dmsコンテキストから抽出されたコンテキスト・フィールドを含む属性。

DomainName

WebLogic Serverドメイン。

ECID

開始コンポーネントが参加している実行のスレッドを識別します。

EventCategory

監査イベントのカテゴリ

EventStatus

監査イベントの結果(失敗または成功)。

EventType

監査イベントのタイプすべてのイベントを表示するには、listAuditEventsコマンドを使用します。

FailureCode

EventStatusがfailureの場合のエラー・コード

HomeInstance

このコンポーネントのORACLE_INSTANCEディレクトリ。

HostId

開始ホストのDN。

HostNwaddr

開始ホストのIPアドレスまたは他のネットワーク・アドレス。

Initiator

操作を実行しているユーザーのUIDを識別する属性。

InstanceId

このコンポーネントが属しているインスタンスの名前。

MajorVersion

メジャー・バージョンのコンポーネント。

MessageText

監査イベントの説明。

MinorVersion

マイナー・バージョンのコンポーネント。

ModuleId

メッセージを生成したモジュールのID。解釈はコンポーネントID内で一意です。

OracleHome

コンポーネントのORACLE_HOMEディレクトリ。

ProcessId

メッセージの起点となったプロセスのID。

RemoteIP

このイベントを開始するクライアントのIPアドレス。

Resource

Webページ、ファイル、ディレクトリ、Webサービス、ドキュメントなど、アクセス対象のリソースを識別します。リソース名には、ホスト名とURIを組み合せます。

RID

これは、リレーションシップ識別子です。スレッドとプロセスの間に完全かつ適切なコールのリレーションシップを指定するために使用します。

Roles

ログイン時にユーザーに付与されたロール

ServerName

サーバーの名前。

SessionId

ログイン・セッションのID。

Target

実行中の操作の対象であるユーザーのUIDを識別する属性たとえば、AliceがBobのパスワードを変更する場合、Aliceはイニシエータ、Bobはターゲット。

TargetComponentType

ターゲット・コンポーネント・タイプ。

TstzOriginating

監査イベントが生成された日時。

ThreadId

このイベントを生成したスレッドのID。

TenantId

テナントID。

TransactionId

トランザクションID。

UserTenantId

ユーザーのテナントID。

AuditService

TransactionId

トランザクションID。

UserSession

AuthenticationMethod

認証方式(パスワード、SSL、Kerberosなど)。

関連項目:

第13.5.1項「監査属性グループ」

C.2 監査スキーマ

ビルトイン・レポートでイベント属性のサブセットを使用している場合でも、OFM監査フレームワークでは、イベント属性セット全体をカスタム・レポートで使用できます。

表C-6および表C-7では、監査スキーマについて説明します。問合せのパフォーマンスを強化するため、スキーマのIAU_ID列には索引が付けられています。

表C-6 監査スキーマ

表名

列名

データ型

NULL値可能

列ID

BASE TABLE

IAU_ID

NUMBER

はい

1

IAU_ORGID

VARCHAR2(255)

はい

2

IAU_COMPONENTID

VARCHAR2(255)

はい

3

IAU_COMPONENTTYPE

VARCHAR2(255)

はい

4

IAU_INSTANCEID

VARCHAR2(255)

はい

5

IAU_HOSTINGCLIENTID

VARCHAR2(255)

はい

6

IAU_HOSTID

VARCHAR2(255)

はい

7

IAU_HOSTNWADDR

VARCHAR2(255)

はい

8

IAU_MODULEID

VARCHAR2(255)

はい

9

IAU_PROCESSID

VARCHAR2(255)

はい

10

IAU_ORACLEHOME

VARCHAR2(255)

はい

11

IAU_HOMEINSTANCE

VARCHAR2(255)

はい

12

IAU_UPSTREAMCOMPONENTID

VARCHAR2(255)

はい

13

IAU_DOWNSTREAMCOMPONENTID

VARCHAR2(255)

はい

14

IAU_ECID

VARCHAR2(255)

はい

15

IAU_RID

VARCHAR2(255)

はい

16

IAU_CONTEXTFIELDS

VARCHAR2(2000)

はい

17

IAU_SESSIONID

VARCHAR2(255)

はい

18

IAU_SECONDARYSESSIONID

VARCHAR2(255)

はい

19

IAU_APPLICATIONNAME

VARCHAR2(255)

はい

20

IAU_TARGETCOMPONENTTYPE

VARCHAR2(255)

はい

21

IAU_EVENTTYPE

VARCHAR2(255)

はい

22

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

23

IAU_EVENTSTATUS

NUMBER

はい

24

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

25

IAU_THREADID

VARCHAR2(255)

はい

26

IAU_COMPONENTNAME

VARCHAR2(255)

はい

27

IAU_INITIATOR

VARCHAR2(255)

はい

28

IAU_MESSAGETEXT

VARCHAR2(255)

はい

29

IAU_FAILURECODE

VARCHAR2(255)

はい

30

IAU_REMOTEIP

VARCHAR2(255)

はい

31

IAU_TARGET

VARCHAR2(255)

はい

32

IAU_RESOURCE

VARCHAR2(255)

はい

33

IAU_ROLES

VARCHAR2(255)

はい

34

IAU_AUTHENTICATIONMETHOD

VARCHAR2(255)

はい

35

IAU_TRANSACTIONID

VARCHAR2(255)

はい

36

IAU_DOMAINNAME

VARCHAR2(255)

はい

37

IAU_COMPONENTDATA

clob

はい

38

DIP

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_ASSOCIATEPROFILENAME

VARCHAR2(512)

はい

5

IAU_PROFILENAME

VARCHAR2(512)

はい

6

IAU_ENTRYDN

VARCHAR2(1024)

はい

7

IAU_PROVEVENT

VARCHAR2(2048)

はい

8

IAU_JOBNAME

VARCHAR2(128)

はい

9

IAU_JOBTYPE

VARCHAR2(128)

はい

10

IAU_DISP_NAME_TL

IAU_LOCALE_STR

VARCHAR2(7)

1

IAU_DISP_NAME_KEY

VARCHAR2(255)

2

IAU_COMPONENT_TYPE

VARCHAR2(255)

3

IAU_DISP_NAME_KEY_TYPE

VARCHAR2(255)

4

IAU_DISP_NAME_TRANS

VARCHAR2(4000)

はい

5

IAU_LOCALE_MAP_TL

IAU_LOC_LANG

VARCHAR2(2)

はい

1

IAU_LOC_CNTRY

VARCHAR2(3)

はい

2

IAU_LOC_STR

VARCHAR2(7)

はい

3

表C-7は、動的メタデータ・モデルがサポートされている監査スキーマの表です。

表C-7 追加の監査スキーマ表

表名

列名

データ型

IAU_COMMON

IAU_ID

NUMBER

IAU_OrgId

VARCHAR(255)

IAU_ComponentId

VARCHAR(255)

IAU_ComponentType

VARCHAR(255)

IAU_MajorVersion

VARCHAR(255)

IAU_MinorVersion

VARCHAR(255)

IAU_InstanceId

VARCHAR(255)

IAU_HostingClientId

VARCHAR(255)

IAU_HostId

VARCHAR(255)

IAU_HostNwaddr

VARCHAR(255)

IAU_ModuleId

VARCHAR(255)

IAU_ProcessId

VARCHAR(255)

IAU_OracleHome

VARCHAR(255)

IAU_HomeInstance

VARCHAR(255)

IAU_UpstreamComponentId

VARCHAR(255)

IAU_DownstreamComponentId

VARCHAR(255)

IAU_ECID

VARCHAR(255)

IAU_RID

VARCHAR(255)

IAU_ContextFields

VARCHAR(2000)

IAU_SessionId

VARCHAR(255)

IAU_SecondarySessionId

VARCHAR(255)

IAU_ApplicationName

VARCHAR(255)

IAU_TargetComponentType

VARCHAR(255)

IAU_EventType

VARCHAR(255)

IAU_EventCategory

VARCHAR(255)

IAU_EventStatus

NUMBER

IAU_TstzOriginating

TIMESTAMP

IAU_ThreadId

VARCHAR(255)

IAU_ComponentName

VARCHAR(255)

IAU_Initiator

VARCHAR(255)

IAU_MessageText

VARCHAR(2000)

IAU_FailureCode

VARCHAR(255)

IAU_RemoteIP

VARCHAR(255)

IAU_Target

VARCHAR(255)

IAU_Resource

VARCHAR(255)

IAU_Roles

VARCHAR(255)

IAU_AuthenticationMethod

VARCHAR(255)

IAU_TransactionId

VARCHAR(255)

IAU_DomainName

VARCHAR(255)

IAU_ComponentVersion

VARCHAR(255)

IAU_ComponentData

CLOB

IAU_CUSTOM

IAU_ID

NUMBER

IAU_BOOLEAN_001 - IAU_BOOLEAN_050

NUMBER

IAU_INT_001 - IAU_INT_050

NUMBER

IAU_LONG_001 - IAU_LONG_050

NUMBER

IAU_FLOAT_001 - IAU_FLOAT_050

NUMBER

IAU_DOUBLE_001 - IAU_DOUBLE_050

NUMBER

IAU_STRING_001 - IAU_STRING_100

VARCHAR(2048)

IAU_DATETIME_001 - IAU_DATETIME_050

TIMESTAMP

IAU_LONGSTRING_001 - IAU_LONGSTRING_050

CLOB

IAU_BINARY_001 - IAU_BINARY_050

BLOB

IAU_AuditService

IAU_ID

NUMBER

IAU_TransactionId

VARCHAR(255)

IAU_USERSESSION

IAU_ID

NUMBER

IAU_AuthenticationMethod

VARCHAR(255)

C.3 監査フィルタ式の構文

カスタム監査ポリシーを選択する際、イベントとともにフィルタ式を指定することもできます。

たとえば、次の式を使用します。

Host Id -eq "myhost123"

この式を使用して、特定のホストのみに対して監査イベントを有効化することができます。この式はsetAuditPolicyコマンドを使用して入力します。

式は、ブール式でもリテラルでも構いません。

<Expr> ::= <BooleanExpression> | <BooleanLiteral>

ブール式では、RelationalExpressionを–and、-or、-notおよびカッコと組み合せて使用できます。(例: Host Id -eq "stadl17" -or ")。

<BooleanExpression> ::=  <RelationalExpression>
| ”(” <BooleanExpression> ”)”
| <BooleanExpression> ”-and” <BooleanExpression>
| <BooleanExpression> ”-or” <BooleanExpression>
| ”-not” <BooleanExpression>

リレーショナル式では(左側の)属性名と(右側の)リテラルが比較されます。リテラルと演算子は、属性に対して適切なデータ型である必要があります。

<RelationalExpression> ::= <AttributeName> <RelationalOperator> <Literal>

関係演算子とデータ型との関係は次のとおりです。

- -eq、-neは、すべてのデータ型で使用できます。

- -contains、-startswith、-endswithは、文字列でのみ使用できます。

- -contains_case、-startswith_caseおよび-endswith_caseは、前述の3つの関数の、大文字と小文字を区別するバージョンです。

- -lt、-le、-gt、-geは、数値と日時で使用できます。

<RelationalOperator> : = "-eq" | "-ne" | "-lt" | "-le" | "-gt" | "-ge"
| "-contains" | "-contains_case"
| "-startswith" | "-startswith_case"
| "-endswith" | "-endswith_case"

リテラルに関するルールは、次のとおりです。

- ブール型リテラルはtrueまたはfalseです。

- 日時のリテラルは二重引用符で囲む必要があり、様々な書式を使用できます。たとえば、"June 25, 2016 2:00 pm"と"06/25/2016 2:00 pm"はいずれも有効です。

- 文字列リテラルは引用符で囲み、埋込み二重引用符をエスケープするために、バックスラッシュを使用できます。

- 数値リテラルは、通常の形式で使用できます。

例:

<Literal> ::=  <NumericLiteral> | <BooleanLiteral> | <DateTimeLiteral> | <StringLiteral><BooleanLiteral> ::= "true” | "false”

C.4 監査ファイルのネーミングおよびロギング

Java EEアプリケーションでは、監査ファイル名のパターンはaudit*.logです。現行ファイル名は、audit.logです。

このファイルが一杯になると(構成されている最大監査ファイル・サイズの100MBに達した場合)、名前はaudit<n>.logに変更され、レコードは新しいaudit.logに書き込まれます。したがって、現在のログはaudit.logに書き込まれ、古いログはaudit1.log、audit2.logなどで見つかります。

Java SEアプリケーションおよびシステム・コンポーネントでは、監査ログ・ファイル名のパターンはhostname_pid_audit*.logで、これらのファイルもJava EEアプリケーションでのログ・ファイルのサイクルと同様のサイクルで回ります。現行ログ・ファイル名は、host_pid_audit.logです。host_12345_audit.logのように、プロセスIDがログ・ファイル名に組み込まれていることに注意してください。

監査ストアが構成されると、監査ローダーはこれらのファイルを読み取って、レコードをデータベースに転送します。転送後、ログ・ファイル(audit2.logやhost_11925_audit1.logなど)を削除しますが、現行ログ・ファイルのaudit.logまたはhost_pid_audit.logは削除しません。

監査定義が動的モデルのアプリケーションの場合、ファイル名の形式audit_major_minor.logです。audit_1_2.logのように、バージョン番号がファイル名に組み込まれていることに注意してください。

ログ・ファイルは、次のようなW3C拡張ロギング形式に従っています。

- #Fieldsでは、ファイルの他の箇所にあるフィールドをすべて指定します。

- #Remarkでは、共通属性を指定します。

- 属性は空白で区切り、欠落している属性はダッシュで示します。

D ユーザーおよびロールAPIリファレンス

この付録では、ユーザーおよびロールAPIを使用してLDAPリポジトリ用のアプリケーションを開発するために使用する属性とパラメータについて説明します。

注意:
ユーザーおよびロールAPIは非推奨です。かわりにIdentity Governance Frameworkを使用し、このフレームワークの使用に移行することをお薦めします。この移行の詳細は、『Identity Governance Framework開発者ガイド』の「アイデンティティ・ディレクトリAPIへの移行」を参照してください。

この付録の内容は次のとおりです。

- LDAPディレクトリへのユーザー属性のマッピング

- LDAPディレクトリへのロール属性のマッピング

- デフォルトの構成パラメータ

D.1 LDAPディレクトリへのユーザー属性のマッピング

表D-1に、UserProfile.propertyファイルのユーザー属性と、サポートされているディレクトリ・サーバーで対応する属性を示します。IBM TivoliとOpenLDAPでは、同じパラメータ・セットを使用します。Microsoft ADAMとMicrosoft Active Directoryでは、同じパラメータ・セットを使用します。

表D-1 ディレクトリ・サーバーのユーザー属性

ユーザー属性

Oracle Internet Directory

組込みLDAPサーバー

Microsoft Active Directory

ODS EE

Novell eDirectory

OpenLDAP

GUID

orclguid

uid

objectguid

nsuniqueid

guid

entryuuid

USER_ID

username(表の下の「注意」を参照)

uid

uid

uid

uid

uid

DISPLAY_NAME

displayname

displayname

displayname

displayname

displayname

displayname

BUSINESS_EMAIL

mail

mail

mail

mail

mail

mail

DESCRIPTION

description

description

description

description

description

description

EMPLOYEE_TYPE

employeeType

employeeType

employeeType

employeeType

employeeType

employeeType

DEPARTMENT

departmentnumber

departmentnumber

departmentnumber

departmentnumber

departmentnumber

departmentnumber

DATE_OF_BIRTH

orcldateofbirth

-

-

-

-

-

BUSINESS_FAX

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

facsimiletelephonenumber

BUSINESS_CITY

l

l

l

l

l

l

BUSINESS_COUNTRY

c

c

c

c

c

c

DATE_OF_HIRE

orclhiredate

-

-

-

-

-

NAME

cn

uid

cn

uid

cn

cn

PREFERRED_LANGUAGE

Preferredlanguage

preferredlanguage

preferredlanguage

preferredlanguage

preferredlanguage

preferredlanguage

BUSINESS_POSTAL_ADDR

postaladdress

postaladdress

postaladdress

postaladdress

postaladdress

postaladdress

MIDDLE_NAME

orclmiddlename

-

-

-

-

-

ORGANIZATIONAL_UNIT

ou

ou

ou

ou

ou

ou

WIRELESS_ACCT_NUMBER

orclwirelessaccountnumber

-

-

-

-

-

BUSINESS_PO_BOX

postofficebox

postofficebox

postofficebox

postofficebox

postofficebox

postofficebox

BUSINESS_STATE

St

st

st

st

st

st

HOME_ADDRESS

Homepostaladdress

homepostaladdress

homepostaladdress

homepostaladdress

homepostaladdress

homepostaladdress

NAME_SUFFIX

Generationqualifier

generationqualifier

generationqualifier

generationqualifier

generationqualifier

generationqualifier

BUSINESS_STREET

street

street

street

street

street

street

INITIALS

initials

initials

initials

initials

initials

initials

USER_NAME

username(表の下の「注意」を参照)

uid

samaccountname

uid

uid

uid

BUSINESS_POSTAL_CODE

postalcode

postalcode

postalcode

postalcode

postalcode

postalcode

BUSINESS_PAGER

pager

pager

pager

pager

pager

pager

LAST_NAME

sn

sn

sn

sn

sn

sn

BUSINESS_PHONE

telephonenumber

telephonenumber

telephonenumber

telephonenumber

telephonenumber

telephonenumber

FIRST_NAME

givenname

givenname

givenname

givenname

givenname

givenname

TIME_ZONE

orcltimezone

-

-

-

-

-

MAIDEN_NAME

orclmaidenname

-

-

-

-

-

PASSWORD

userpasssword

userpasssword

userpasssword

userpasssword

userpasssword

userpasssword

DEFAULT_GROUP

orcldefaultprofilegroup

-

-

-

-

-

ORGANIZATION

o

o

o

o

o

o

HOME_PHONE

homephone

homephone

homephone

homephone

homephone

homephone

BUSINESS_MOBILE

mobile

mobile

mobile

mobile

mobile

mobile

UI_ACCESS_MODE

orcluiaccessibilitymode

-

-

-

-

-

JPEG_PHOTO

jpegphoto

jpegphoto

jpegphoto

jpegphoto

jpegphoto

jpegphoto

MANAGER

manager

manager

manager

manager

manager

manager

TITLE

title

title

title

title

title

title

EMPLOYEE_NUMBER

employeenumber

employeenumber

employeenumber

employeenumber

employeenumber

employeenumber

LDUser.PASSWORD

userpassword

userpassword

userpassword

userpassword

userpassword

userpassword

D.2 LDAPディレクトリへのロール属性のマッピング

表D-2は、UserProfile.propertyの各ロール属性と、異なるディレクトリ・サーバーにおけるその対応する属性を示しています。IBM TivoliとOpenLDAPでは、同じパラメータ・セットを使用します。Microsoft ADAMとMicrosoft Active Directoryでは、同じパラメータ・セットを使用します。

表D-2 ディレクトリ・サーバーのロール属性

ロール属性

Oracle Internet Directory

組込みLDAPサーバー

Microsoft Active Directory

ODS EE

Novell eDirectory

OpenLDAP

DISPLAY_NAME

displayname

-

displayname

displayname

displayname

displayname

MANAGER

-

-

-

-

-

-

NAME

cn

cn

cn

cn

cn

cn

OWNER

owner

owner

-

Owner

-

owner

GUID

orclguid

cn

objectguid

NSuniqueid

guid

entryuuid

D.3 デフォルトの構成パラメータ

この項では、デフォルトの構成パラメータ値と、異なるディレクトリ・サーバーでの値のソースを示します。

表D-3に、Oracle Internet DirectoryおよびMicrosoft Active Directoryのパラメータ値を示します。Active Directoryでは、パスワードのような機密情報を設定する際に、SSLが必要です。

表D-3 Oracle Internet DirectoryおよびMicrosoft Active Directoryのパラメータ

パラメータ

Oracle Internet Directory

Microsoft Active Directory

RT_USER_OBJECT_CLASSES

#config

{"user"}

RT_USER_MANDATORY_ATTRS

#schema

#schema

RT_USER_CREATE_BASES

#config

cn=users,<subscriberDN>

RT_USER_SEARCH_BASES

#config

<subscriberDN>

RT_USER_FILTER_OBJECT_CLASSES

#config

{"user"}

RT_USER_SELECTED_CREATE_BASE

#config

cn=users,<subscriberDN>

RT_GROUP_OBJECT_CLASSES

#config

{"group"}

RT_GROUP_MANDATORY_ATTRS

#schema

#schema

RT_GROUP_CREATE_BASES

#config

<subscriberDN>

RT_GROUP_SEARCH_BASES

#config

<subscriberDN>

RT_GROUP_FILTER_OBJECT_CLASSES

#config

{"group"}

RT_GROUP_MEMBER_ATTRS

"uniquemember", "member"

"member"

RT_GROUP_SELECTED_CREATE_BASE

#config

<subscriberDN>

RT_GROUP_GENERIC_SEARCH_BASE

<subscriber-DN>

<subscriberDN>

RT_SEARCH_TYPE

#config

#config

ST_SUBSCRIBER_NAME

#config

NULL

ST_USER_NAME_ATTR

#config

cn

ST_USER_LOGIN_ATTR

#config

samaccountname

ST_GROUP_NAME_ATTR

#config

cn

ST_MAX_SEARCHFILTER_LENGTH

500

500

ST_BINARY_ATTRIBUTES

バイナリ属性

バイナリ
属性 + {objectguid, unicodepwd}

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole

注意:
バイナリ属性には、photo、personalsignature、audio、jpegphoto、javaSErializeddata、thumbnailphoto、thumbnaillogo、userpassword、usercertificate、cacertificate、authorityrevocationlist、certificaterevocationlist、crosscertificatepairおよびx500UniqueIdentifierがあります。
config属性は、ディレクトリに存在するメタ情報から抽出されます。schema属性は、ディレクトリのスキーマから抽出されます。

表D-4に、Oracle Directory Server Enterprise EditionおよびNovell eDirectoryのパラメータを示します。

表D-4 Directory Server Enterprise EditionおよびNovell eDirectoryのパラメータ

パラメータ

DS EE

Novell eDirectory

RT_USER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson" }

{ "person", "inetorgperson", "organizationalPerson", "ndsloginproperties" }

RT_USER_MANDATORY_ATTRS

#schema

#schema

RT_USER_CREATE_BASES

ou=people,<subscriberDN>

ou=users,<subscriberDN>

RT_USER_SEARCH_BASES

<subscriberDN>

<subscriberDN>

RT_USER_FILTER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson" }

{ "person", "inetorgperson", "organizationalPerson", "ndsloginproperties" }

RT_USER_SELECTED_CREATE_BASE

ou=people,<subscriberDN>

ou=users,<subscriberDN>

RT_GROUP_OBJECT_CLASSES

"groupofuniquenames"

{"group"}

RT_GROUP_MANDATORY_ATTRS

#schema

#schema

RT_GROUP_CREATE_BASES

ou=groups,<subscriberDN>

ou=groups,<subscriberDN>

RT_GROUP_SEARCH_BASES

<subscriberDN>

<subscriberDN>

RT_GROUP_FILTER_OBJECT_CLASSES

{"groupofuniquenames"}

{"group"}

RT_GROUP_MEMBER_ATTRS

"uniquemember"

"member"

RT_GROUP_SELECTED_CREATE_BASE

ou=groups,<subscriberDN>

ou=groups,<subscriberDN>

RT_GROUP_GENERIC_SEARCH_BASE

<subscriber-DN>

<subscriberDN>

RT_SEARCH_TYPE

#config

#config

ST_SUBSCRIBER_NAME

NULL

NULL

ST_USER_NAME_ATTR

uid

cn

ST_USER_LOGIN_ATTR

uid

cn

ST_GROUP_NAME_ATTR

cn

cn

ST_MAX_SEARCHFILTER_LENGTH

500

500

ST_BINARY_ATTRIBUTES

バイナリ属性

バイナリ
属性 + {objectguid, unicodepwd}

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole

注意:
バイナリ属性には、photo、personalsignature、audio、jpegphoto、javaSErializeddata、thumbnailphoto、thumbnaillogo、userpassword、usercertificate、cacertificate、authorityrevocationlist、certificaterevocationlist、crosscertificatepairおよびx500UniqueIdentifierがあります。
config属性は、ディレクトリに存在するメタ情報から抽出されます。schema属性は、ディレクトリのスキーマから抽出されます。

表D-5に、OpenLDAPおよびOracle Virtual Directoryのパラメータを示します。

表D-5 OpenLDAPおよびOracle Virtual Directoryのパラメータ

パラメータ

OpenLDAP

Oracle Virtual Directory

RT_USER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson" }

{"inetorgperson"}

RT_USER_MANDATORY_ATTRS

#schema

#schema

RT_USER_CREATE_BASES

ou=people,<subscriberDN>

<subscriberDN>

RT_USER_SEARCH_BASES

<subscriberDN>

<subscriberDN>

RT_USER_FILTER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson" }

{"inetorgperson"}

RT_USER_SELECTED_CREATE_BASE

ou=people,<subscriberDN>

<subscriberDN>

RT_GROUP_OBJECT_CLASSES

"groupofuniquenames"

{"groupofuniquenames"}

RT_GROUP_MANDATORY_ATTRS

#schema

#schema

RT_GROUP_CREATE_BASES

ou=groups,<subscriberDN>

<subscriberDN>

RT_GROUP_SEARCH_BASES

<subscriberDN>

<subscriberDN>

RT_GROUP_FILTER_OBJECT_CLASSES

"groupofuniquenames"

{"groupofuniquenames"}

RT_GROUP_MEMBER_ATTRS

"uniquemember"

"uniquemember"

RT_GROUP_SELECTED_CREATE_BASE

ou=groups,<subscriberDN>

<subscriberDN>

RT_GROUP_GENERIC_SEARCH_BASE

<subscriber-DN>

<subscriberDN>

RT_SEARCH_TYPE

#config

#config

ST_SUBSCRIBER_NAME

NULL

#config (namingcontexts)

ST_USER_NAME_ATTR

uid

cn

ST_USER_LOGIN_ATTR

uid

cn

ST_GROUP_NAME_ATTR

cn

cn

ST_MAX_SEARCHFILTER_LENGTH

500

500

ST_BINARY_ATTRIBUTES

バイナリ属性

バイナリ
属性 + {objectguid, unicodepwd}

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole

注意:
バイナリ属性には、photo、personalsignature、audio、jpegphoto、javaSErializeddata、thumbnailphoto、thumbnaillogo、userpassword、usercertificate、cacertificate、authorityrevocationlist、certificaterevocationlist、crosscertificatepairおよびx500UniqueIdentifierがあります。
config属性は、ディレクトリに存在するメタ情報から抽出されます。schema属性は、ディレクトリのスキーマから抽出されます。

表D-6に、組込みLDAPサーバーのパラメータを示します。

表D-6 組込みLDAPのパラメータ

パラメータ

デフォルト値

RT_USER_OBJECT_CLASSES

{"inetorgperson", "person", "organizationalperson", "wlsUser"}

RT_USER_MANDATORY_ATTRS

#schema

RT_USER_CREATE_BASES

{"ou=people,<subscriberDN>"}

RT_USER_SEARCH_BASES

{"ou=people,<subscriberDN>"}

RT_USER_FILTER_OBJECT_CLASSES

{"inetorgperson", "wlsUser"}

RT_USER_SELECTED_CREATE_BASE

ou=people,<subscriberDN>

RT_GROUP_OBJECT_CLASSES

{"top","groupofuniquenames","groupOfURLs"}

RT_GROUP_MANDATORY_ATTRS

#schema

RT_GROUP_CREATE_BASES

{"ou=groups,<subscriberDN>"}

RT_GROUP_SEARCH_BASES

{"ou=groups,<subscriberDN>"}

RT_GROUP_FILTER_OBJECT_CLASSES

{"top","groupofuniquenames","groupOfURLs"}

RT_GROUP_MEMBER_ATTRS

"uniquemember"

RT_GROUP_SELECTED_CREATE_BASE

ou=groups,<subscriberDN>

RT_GROUP_GENERIC_SEARCH_BASE

<subscriberDN>

RT_SEARCH_TYPE

#config

ST_SUBSCRIBER_NAME

#config (namingcontexts)

ST_USER_NAME_ATTR

uid

ST_USER_LOGIN_ATTR

uid

ST_GROUP_NAME_ATTR

cn

ST_MAX_SEARCHFILTER_LENGTH

500

ST_BINARY_ATTRIBUTES

*(BBA)

BBAの詳細は、表の下の「注意」を参照してください。

ST_LOGGER_NAME

oracle.idm.userrole

E スクリプトおよびMBeanを使用した管理

この付録では、WebLogic Scripting Tool (WLST)コマンドおよびOPSS MBean APIを使用して実行する管理タスクについて説明します。

次の項目について説明します。

- スクリプトを使用したサービスの構成

- MBeanを使用したサービスの構成

- MBeanへのアクセスの制限

E.1 スクリプトを使用したサービスの構成

アプリケーションでユーザーおよびロールAPIを使用しており、デフォルトのcn属性とは異なるプロバイダのユーザー属性にアクセスする必要がある場合は、必要なユーザー属性を使用するように認証プロバイダを構成し、プロバイダを適切に初期化する必要があります。

次の手順に従って、プロバイダの初期化を変更するスクリプトを作成し、ユーザーおよびロールAPIで指定のユーザー属性を使用して、構成されたプロバイダのデータにアクセスできるようにします。

1. 次の内容のスクリプト・ファイルを作成します。

import sys
connect('userName', 'userPassword', 'url', 'adminServerName')
domainRuntime()

val = None
key = None
si = None
for  i in range(len(sys.argv)):
if sys.argv[i] == "-si":
si = sys.argv[i+1]
if sys.argv[i] == "-key":
key  = sys.argv[i+1]
if sys.argv[i] == "-value":
val = sys.argv[i+1]

on = ObjectName("com.oracle.jps:type=JpsConfig")
sign = ["java.lang.String","java.lang.String","java.lang.String"]
params = [si,key,val]
mbs.invoke(on, "updateServiceInstanceProperty", params, sign)
mbs.invoke(on, "persist", None, None)

2. userName、userPass、localHostおよびportNumberを、目的のドメイン内の管理サーバーに接続するのに適した値で置換します。connectを使用するには、スクリプトがコールされたときに接続先のサーバーが稼働している必要があります。このスクリプトを/tmp/updateServiceInstanceProperty.pyとして保存するとします。

3. $ORACLE_HOME/common/binディレクトリに変更してwlst.shを実行します。

>cd $ORACLE_HOME/common/bin
>wlst.sh /tmp/updateServiceInstanceProperty.py -si servInstName -key propKey -value propValue

説明:

- servInstNameは、変更対象のプロパティがあるサービス・インスタンス・プロバイダの名前です。

- propKeyは、挿入または変更するプロパティの名前を識別します。

- propValueは、追加または更新する値の名前です。

コマンドでは、渡されたインスタンス・プロバイダに対してプロパティを追加または更新することによって、$DOMAIN_HOME/config/fmwconfig/jps-config.xmlドメイン構成ファイルが変更されます。プロパティの名前と一致するキーを渡すと、そのプロパティは渡された値で更新されます。

4. Oracle WebLogic Serverを再起動します。

使用例

ドメインでidstore.ldap認証プロバイダを使用していることを前提とします。次のコマンドを実行します。

wlst.sh /tmp/updateServiceInstanceProperty.py -si idstore.ldap -key "myPropName" -value "myValue"

このインスタンス・プロバイダの指定のプロパティが追加(または更新)されます。

<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
...
<property name="myPropName" value="myValue"/>
...
</serviceInstance>

E.2 MBeanを使用したサービスの構成

OPSSには、Fusion Middleware Controlおよびスクリプトによってサービスの管理、構成および監視に使用される、一連のJMXに準拠したJava EE Beanが用意されています。MBeanは、Java EEアプリケーションでのみ使用することをお薦めします。

次の各項では、OPSS MBeanの使用方法について説明します。

- サポートされるOPSS MBean

- OPSS MBeanの使用

- OPSS MBeansを使用したプログラミング

関連項目:

第G.1項「OPSS APIリファレンス」

E.2.1 サポートされるOPSS MBean

表E-1に、OPSSでサポートされるMBeanとその基本機能、およびタスクを実行するために(カスタム・スクリプトまたはJava SEプログラムで)使用するオブジェクト名を示します。

表E-1 OPSS MBeansのリスト

MBean

機能

MBeanServerオブジェクト名

Jps構成

jps-config.xmlのドメイン構成を管理します。このMBeanは、構成データを変更するための唯一の方法として機能します。

更新または書込み操作では、サーバーを再起動して変更を有効にする必要があります。

com.oracle.jps:type=JpsConfig

資格証明ストア

資格証明データを管理します。

更新または書込み操作の場合は、変更を有効にするためにサーバーを再起動する必要はありません。変更はすべて即座に反映されます。アクセスは、セキュリティ管理者のみに制限されます。

com.oracle.jps:type=JpsCredentialStore

グローバル・ポリシー・ストア

デフォルトのコンテキストで構成されたセキュリティ・ストアで、グローバル・ポリシーを管理します。

更新または書込み操作の場合は、変更を有効にするためにサーバーを再起動する必要はありません。変更はすべて即座に反映されます。

com.oracle.jps:type=JpsGlobalPolicyStore

アプリケーション・ポリシー・ストア

デフォルトのコンテキストで構成されたセキュリティ・ストアで、アプリケーション・ポリシーを管理します。

更新または書込み操作の場合は、変更を有効にするためにサーバーを再起動する必要はありません。変更はすべて即座に反映されます。

com.oracle.jps:type=JpsApplicationPolicyStore

管理ポリシー・ストア

現在のJMXコンテキストにログインしたユーザーが特定のロールに属しているかどうかを検証します。これによって構成の変更が容易になることはありません。

com.oracle.jps:type=JpsAdminPolicyStore

E.2.2 OPSS MBeanの使用

OPSS MBeanをコールするには、スクリプトを作成してWLSTを使用して実行するか、Javaプログラムを作成するか、Fusion Middleware ControlのMBeanブラウザを使用します。

Fusion Middleware Controlを使用してOPSS MBeanをコールするには、次の手順を実行します。

1. 適切なドメインで、「AdminServer」→「システムMBeanブラウザ」の順に選択します。「システムMBeanブラウザ」ページが表示されます。

2. このページで、「アプリケーション定義のMBean」→「com.oracle.jps」→「ドメイン」の順にノードを開きます。

3. MBeanを選択し、右側のペインの「属性」、「操作」および「通知」の各タブを使用し、MBean属性値およびメソッドを調べます。
たとえば、指定されたマップおよびキーを持つ資格証明を取得するには、スクリプトを使用してMBean操作JpsCredentialMXBean.getPortableCredential(map, key)をコールします。

関連項目:

第E.2.3項「OPSS MBeanを使用したプログラミング」

『WebLogic Scripting Toolの理解』の「MBeanのナビゲート」

E.2.3 OPSS MBeansを使用したプログラミング

次の例は、JpsConfiguration MBeanのコール方法を示しています。次の点に注意してください。

- 次のJARファイルがクラスパスに入っていることを前提とします。

- $ORACLE_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-api.jar

- $ORACLE_HOME/oracle_common/modules/oracle.jps_12.2.1/jps-mbeans.jar

- $ORACLE_HOME/oracle_common/modules/oracle.jmx_12.2.1/jmxframework.jar

- $ORACLE_HOME/oracle_common/modules/oracle.idm_12.2.1/identitystore.jar

- $WEBLOGIC_HOME/server/lib/wljmxclient.jar

- 接続は、initメソッドを使用して確立されています。

- 更新操作の後では必ず、維持のためのコールを行います。

import java.io.IOException;
import java.net.MalformedURLException;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.HashMap;
import java.util.List;

import javax.management.InstanceNotFoundException;
import javax.management.MBeanException;
import javax.management.MBeanServerConnection;
import javax.management.MalformedObjectNameException;
import javax.management.ObjectName;
import javax.management.ReflectionException;
import javax.management.openmbean.CompositeData;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;
import javax.naming.Context;

import oracle.security.jps.mas.mgmt.jmx.credstore.PortableCredential;
import oracle.security.jps.mas.mgmt.jmx.credstore.PortablePasswordCredential;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableApplicationRole;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableCodeSource;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableGrant;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableGrantee;
import oracle.security.jps.mas.mgmt.jmx.policy.PortablePermission;
import oracle.security.jps.mas.mgmt.jmx.policy.PortablePrincipal;
import oracle.security.jps.mas.mgmt.jmx.policy.PortableRoleMember;
import oracle.security.jps.mas.mgmt.jmx.util.JpsJmxConstants;

public class InvokeJpsMbeans {
private static JMXConnector connector;
private static MBeanServerConnection wlsMBeanConn;
private static ObjectName configName;
private static ObjectName credName;
private static ObjectName appPolName;
private static ObjectName gloPolName;
private static ObjectName adminPolName;

private final static String STR_NAME =String.class.getName();

public static void main(String args[]) {
// Intialize connection and retrieve connection object
init();

//Check registration
if (isRegistered(configName))
System.out.println("Jps Config MBean is registered");
if (isRegistered(credName))
System.out.println("Jps Credential Mbean is registered");
if (isRegistered(appPolName))
System.out.println("Jps Application policy Mbean is registered");
if (isRegistered(gloPolName))
System.out.println("Jps Global policy Mbean is registered");
if (isRegistered(adminPolName))
System.out.println("Jps Admin Policy Mbean is registered");

//invoke MBeans
invokeConfigMBeanMethods();
invokeCredentialMBeanMethods();
invokeApplicationPolicyMBeanMethods();
invokeGlobalPolicyMBeanMethods();
invokeAdminPolicyMBeanMethhods();
}

private static void invokeConfigMBeanMethods() {
String KEY = "myKey";
String VALUE = "myValue";
String strVal;
try {
strVal = (String) wlsMBeanConn.invoke(configName, "updateProperty",
new Object[] { KEY, VALUE },
new String[] { STR_NAME, STR_NAME });
wlsMBeanConn.invoke(configName,"persist",null,null);

strVal = (String) wlsMBeanConn.invoke(configName, "getProperty",
new Object[] { KEY }, new String[] { STR_NAME });
System.out.println("Updated the property: " + strVal.equals(strVal));

strVal = (String) wlsMBeanConn.invoke(configName, "removeProperty",
new Object[] { KEY }, new String[] { STR_NAME });
wlsMBeanConn.invoke(configName,"persist",null,null);
} catch (InstanceNotFoundException e) {
// auto-generated catch block
e.printStackTrace();
} catch (MBeanException e) {
// auto-generated catch block
e.printStackTrace();
} catch (ReflectionException e) {
// auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// auto-generated catch block
e.printStackTrace();
}
}

private static void  invokeCredentialMBeanMethods() {

String USER = "jdoe";
String PASSWORD = "welcome1";
String ALIAS = "mapName";
String KEY = "keyValue";

PortableCredential cred = new PortablePasswordCredential(USER, PASSWORD.toCharArray());

try {
//seed a password credential
wlsMBeanConn.invoke(credName, "setPortableCredential", new Object[] { ALIAS, KEY, cred.toCompositeData(null) }, new String[] { STR_NAME, STR_NAME, CompositeData.class.getName() });
boolean bContainsMap = (Boolean) wlsMBeanConn.invoke(credName, "containsMap", new Object[] { ALIAS }, new String[] { STR_NAME });
System.out.println("Credstore contains map: " + ALIAS + " - " +bContainsMap);

boolean bContainsCred = (Boolean) wlsMBeanConn.invoke(credName, "containsCredential", new Object[] { ALIAS, KEY }, new String[] { STR_NAME, STR_NAME });
System.out.println("Contains Credential; " + bContainsCred);

CompositeData cd = (CompositeData) wlsMBeanConn.invoke(credName, "getPortableCredential", new Object[] { ALIAS, KEY }, new String[] { STR_NAME, STR_NAME });
cred = PortableCredential.from(cd);

PortablePasswordCredential pc = (PortablePasswordCredential) cred;

System.out.println("User name should be " +  USER + " Retrieved - " + pc.getName());
System.out.println("Password should be " + PASSWORD + "retrieved - " +  new String(pc.getPassword()));

//delete entire map
wlsMBeanConn.invoke(credName, "deleteCredentialMap", new Object[] {ALIAS}, new String[] {STR_NAME} );

} catch (InstanceNotFoundException e) {
// auto-generated catch block
e.printStackTrace();
} catch (MBeanException e) {
// auto-generated catch block
e.printStackTrace();
} catch (ReflectionException e) {
// auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// auto-generated catch block
e.printStackTrace();
}

}

private static void invokeApplicationPolicyMBeanMethods() {
//add grants to approles

//first create application policy
String TESTGET_APP_ROLES_MEMBERS = "testgetAppRolesMembers";
try {
wlsMBeanConn.invoke(appPolName, "deleteApplicationPolicy", new Object[] { TESTGET_APP_ROLES_MEMBERS }, new String[] { STR_NAME });
} catch (Exception e ) {
System.out.println("IGNORE: App " + TESTGET_APP_ROLES_MEMBERS + " might not exist");
}
try {
wlsMBeanConn.invoke(appPolName, "createApplicationPolicy", new Object[] { TESTGET_APP_ROLES_MEMBERS }, new String[] { STR_NAME });
// add remove members to applicaiton roles
// Create App Role here
String APP_ROLE_NAME = "ravenclaw_house";
wlsMBeanConn.invoke(appPolName, "createApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, APP_ROLE_NAME, null, null, null }, new String[] { STR_NAME, STR_NAME, STR_NAME, STR_NAME, STR_NAME });

CompositeData cd = (CompositeData) wlsMBeanConn.invoke(appPolName, "getApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, APP_ROLE_NAME }, new String[] { STR_NAME, STR_NAME });
PortableApplicationRole appRole = PortableApplicationRole.from(cd);

//Add custom principal here
PortableRoleMember prm_custom = new PortableRoleMember("My.Custom.Principal","CustomPrincipal",null,null,null);

CompositeData[] arrCompData = { prm_custom.toCompositeData(null) };
cd = (CompositeData) wlsMBeanConn.invoke(appPolName, "addMembersToApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null), arrCompData }, new String[] { STR_NAME, CompositeData.class.getName(), CompositeData[].class.getName() });

// Chk if member got added
CompositeData[] arrCD = (CompositeData[]) wlsMBeanConn.invoke(appPolName, "getMembersForApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null) }, new String[] { STR_NAME, CompositeData.class.getName() });
PortableRoleMember[] actRM = getRMArrayFromCDArray(arrCD);
PortableRoleMember[] expRM = { prm_custom};
chkRoleMemberArrays(actRM, expRM);

cd = (CompositeData) wlsMBeanConn.invoke(appPolName, "removeMembersFromApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null), arrCompData }, new String[] { STR_NAME, CompositeData.class.getName(), CompositeData[].class.getName() });

// Chk if member got removed
arrCD = (CompositeData[]) wlsMBeanConn.invoke(appPolName, "getMembersForApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, appRole.toCompositeData(null) }, new String[] { STR_NAME, CompositeData.class.getName() });
System.out.println("length should be zero :" + arrCD.length);

// Remove the App Role
wlsMBeanConn.invoke(appPolName, "removeApplicationRole", new Object[] { TESTGET_APP_ROLES_MEMBERS, APP_ROLE_NAME }, new String[] { STR_NAME, STR_NAME });
wlsMBeanConn.invoke(appPolName, "deleteApplicationPolicy", new Object[] { TESTGET_APP_ROLES_MEMBERS }, new String[] { STR_NAME });

} catch (InstanceNotFoundException e) {
// auto-generated catch block
e.printStackTrace();
} catch (MBeanException e) {
// auto-generated catch block
e.printStackTrace();
} catch (ReflectionException e) {
// auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// auto-generated catch block
e.printStackTrace();
}
}

private static PortableRoleMember[] getRMArrayFromCDArray(CompositeData[] arrCD) {
PortableRoleMember[] actRM = new PortableRoleMember[arrCD.length];
int idx = 0;
for (CompositeData cdRM : arrCD) {
actRM[idx++] = PortableRoleMember.from(cdRM);
}
return actRM;
}

private static void chkRoleMemberArrays(PortableRoleMember[] arrExpectedRM, PortableRoleMember[] arrActRM) {

List < PortableRoleMember > lstExpRM = new ArrayList < PortableRoleMember >(Arrays.asList(arrExpectedRM));
List < PortableRoleMember > lstActRM = new ArrayList < PortableRoleMember >(Arrays.asList(arrActRM));

for (PortableRoleMember actRM : lstActRM) {
for (int idx = 0; idx < lstExpRM.size(); idx++) {
PortableRoleMember expRM = (PortableRoleMember) lstExpRM.get(idx);
if (expRM.equals(actRM)) {
lstExpRM.remove(idx);
break;
}
}
}
System.out.println("List should be empty - " + lstExpRM.size());
}

private static void  invokeAdminPolicyMBeanMethhods() {
//Connection is established as weblogic user, who by OOTB gets all permissions
Boolean bool;
try {
bool = (Boolean) wlsMBeanConn.invoke(adminPolName,"checkRole",new Object[]{"Admin"}, new String[]{STR_NAME});
System.out.println("Werblogic has Admin role: " + bool);
bool = (Boolean) wlsMBeanConn.invoke(adminPolName,"checkRole",new Object[] {"Configurator"}, new String[]{STR_NAME});
System.out.println("Werblogic has Configurator role: " + bool);
bool = (Boolean) wlsMBeanConn.invoke(adminPolName,"checkRole", new Object[]{new String[] {"Operator", "Admin", "Configurator"}},
new String[]{String[].class.getName()});
System.out.println("Werblogic has Admin,Operator,Configurator role: " + bool);
} catch (InstanceNotFoundException e) {
// auto-generated catch block
e.printStackTrace();
} catch (MBeanException e) {
// auto-generated catch block
e.printStackTrace();
} catch (ReflectionException e) {
// auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// auto-generated catch block
e.printStackTrace();
}
}

private static void invokeGlobalPolicyMBeanMethods() {
// lets create a grant in system policy
PortablePrincipal CUSTOM_JDOE = new PortablePrincipal("oracle.security.jps.internal.core.principals.CustomXmlUserImpl", "jdoe", PortablePrincipal.PrincipalType.CUSTOM);
PortablePrincipal CUSTOM_APP_ADMINS = new PortablePrincipal("oracle.security.jps.internal.core.principals.CustomXmlEnterpriseRoleImpl", "oc4j-app-administrators", PortablePrincipal.PrincipalType.CUSTOM);
PortablePrincipal[] arrPrincs = {CUSTOM_JDOE, CUSTOM_APP_ADMINS};
//codesource URL
String URL = "http://www.oracle.com/as/jps-api.jar";
PortableCodeSource pcs = new PortableCodeSource(URL);
PortableGrantee pge = new PortableGrantee(arrPrincs, pcs);
PortablePermission CSF_PERM = new PortablePermission("oracle.security.jps.service.credstore.CredentialAccessPermission", "context=SYSTEM,mapName=MY_MAP,keyName=MY_KEY", "read");
PortablePermission[] arrPerms = {CSF_PERM};
PortableGrant grnt = new PortableGrant(pge, arrPerms);
CompositeData[] arrCompData = { grnt.toCompositeData(null) };
try {
System.out.println("Creating System Policy grant");
wlsMBeanConn.invoke(gloPolName, "grantToSystemPolicy", new Object[] { arrCompData }, new String[] { CompositeData[].class.getName() });
System.out.println("Deleting the created grant");
wlsMBeanConn.invoke(gloPolName, "revokeFromSystemPolicy", new Object[] { arrCompData }, new String[] { CompositeData[].class.getName() });

} catch (InstanceNotFoundException e) {
// auto-generated catch block
e.printStackTrace();
} catch (MBeanException e) {
// auto-generated catch block
e.printStackTrace();
} catch (ReflectionException e) {
// auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// auto-generated catch block
e.printStackTrace();
}
}

private static boolean isRegistered(ObjectName name) {
try {
return wlsMBeanConn.isRegistered(name);
} catch (IOException e) {
// auto-generated catch block
e.printStackTrace();
}
return false;
}

private static void init() {
String protocol = "t3";
String jndi_root = "/jndi/";
String wlserver = "myWLServer";
String host =  "myHost.com";
int port =  7001;
String adminUsername = "myAdminName";
String adminPassword = "myAdminPassw";
JMXServiceURL url;
try {
url = new JMXServiceURL(protocol,host,port,jndi_root+wlserver);
HashMap<String, Object> env = new HashMap<String, Object>();
env.put(Context.SECURITY_PRINCIPAL, adminUsername);
env.put(Context.SECURITY_CREDENTIALS, adminPassword);
env.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,
"weblogic.management.remote");
connector = JMXConnectorFactory.connect(url, env);
wlsMBeanConn = connector.getMBeanServerConnection();
//create object names
// the next string is set to com.oracle.jps:type=JpsConfig
configName = new
ObjectName(JpsJmxConstants.MBEAN_JPS_CONFIG_FUNCTIONAL);
// the next string is set to com.oracle.jps:type=JpsApplicationPolicyStore
appPolName = new
ObjectName(JpsJmxConstants.MBEAN_JPS_APPLICATION_POLICY_STORE);
// the next string is set to com.oracle.jps:type=JpsGlobalPolicyStore
gloPolName = new
ObjectName(JpsJmxConstants.MBEAN_JPS_GLOBAL_POLICY_STORE);
// the next string is set to com.oracle.jps:type=JpsAdminPolicyStore
adminPolName = new
ObjectName(JpsJmxConstants.MBEAN_JPS_ADMIN_POLICY_STORE);
// the next string is set to com.oracle.jps:type=JpsCredentialStore
credName = new ObjectName(JpsJmxConstants.MBEAN_JPS_CREDENTIAL_STORE);
} catch (MalformedURLException e) {
// take proper action
e.printStackTrace();
} catch (IOException e) {
// take proper action
e.printStackTrace();
} catch (MalformedObjectNameException e) {
// auto-generated catch block
e.printStackTrace();
}
}
}

E.3 MBeanへのアクセスの制限

ここでの説明はOPPS MBeansにのみ限定されるものではなく、Oracle Fusion Middleware MBeans全般に当てはまります。

論理ロールとは、Java EEアプリケーションで宣言またはプログラムによって指定するロールです。アプリケーション・デプロイメント・ディスクリプタで定義し、アプリケーション・コード内で使用します。論理ロールは、エンタープライズ・グループまたはユーザーにマップできますが、アプリケーション・ロールにはマップできません。

MBeansへのセキュリティ・アクセスは、セキュリティ許可ではなく、論理ロールに基づいています。MBeanには、JMX Frameworkによって実行時に施行されるロールベースの制約を受けた注釈が付けられます。

次の各項では、注釈の使用方法と特定のアクセス制限を示し、エンタープライズ・グループへの論理ロールのマッピングについて説明します。

- 注釈の例

- エンタープライズ・グループへの論理ロールのマッピング

- 特定のアクセス制限

E.3.1 注釈の例

次の例は、MBeanインタフェースでのエンタープライズ・グループの注釈(太字テキストの部分)の使用方法を示しています。

@Description(resourceKey = "demo.ScreenCustomizerRuntimeMBean.description",
resourceBundleBaseName = "demo.runtime.Messages")
@ImmutableInfo("true")
@Since("1.1")
public interface ScreenCustomizerRuntimeMXBean {
@Description(resourceKey = "demo.ScreenCustomizerRuntimeMBean.Active",
resourceBundleBaseName = "demo.runtime.Messages")
@AttrributeGetterRequiredGlobalSecurityRole(GlobalSecurityRole.Operator)
public boolean isActive();
@AttrributeSetterRequiredGlobalSecurityRole(GlobalSecurityRole.Admin)
public void setActive(boolean val);

@Description(resourceKey =
"demo.ScreenCustomizerRuntimeMBean.ActiveVirtualScreenId",
resourceBundleBaseName = "demo.runtime.Messages")
@DefaultValue("0")
@LegalValues( {"0", "2", "4", "6", "8" })
@RequireRestart(ConfigUptakePolicy.ApplicationRestart)
@OperationRequiredGlobalSecurityRole(GlobalSecurityRole.Admin)
public void setActiveVirtualScreenId(int id) throws IllegalArgumentException;
…
}

説明:

- @AtrributeGetterRequiredGlobalSecurityRoleは、ユーザーがgetメソッドのisActiveにアクセスするには、Operatorロールに属している必要があることを指定します。

- @AtrributeSetterRequiredGlobalSecurityRoleは、ユーザーがsetActiveメソッドにアクセスするには、Adminロールに属している必要があることを指定します。

- @OperationRequiredGlobalSecurityRoleは、ユーザーがsetActiveVirtualScreenIdメソッドMBeanにアクセスするには、Adminロールに属している必要があることを指定します。

この3つの注釈はすべて、インタフェース内の特定のアイテムにのみ適用されることに注意してください。

次の例は、範囲の異なる注釈(太字テキスト)の使用方法を示しています。

@Description(resourceKey = "demo.ScreenCustomizerRuntimeMBean.description",
resourceBundleBaseName = "demo.runtime.Messages")
@ImmutableInfo("true")
@Since("1.1")
@MBeanRequiredGlobalSecurityRole(GlobalSecurityRole.Admin)
public interface ScreenCustomizerRuntimeMXBean { … }

@MbeanRequiredGlobalSecurityRoleは、ユーザーがMBeanの操作または属性にアクセスするには、Adminロールに属している必要があることを指定しているため、MBean全体が対象範囲になります。メソッドまたは属性の範囲を指定している注釈は、MBean全体に適用される注釈よりも優先されます。

GlobalSecurityRoleは、セキュリティ・チェックの実行前に、環境内で実際のロールにマップされるグローバルの論理ロール・セットを定義します。この列挙には、注釈付き操作または属性に対してすべてのユーザーが読取り/書込み権限を持っていることを示す値NONEが含まれています。

E.3.2 エンタープライズ・グループへの論理ロールのマッピング

表E-2は、エンタープライズ・グループへの論理ロールのマッピングを示しています。

表E-2 WebLogicグループへの論理ロールのマッピング

論理ロール

デフォルトのパーミッション

WebLogicグループ

Admin

すべてのMBeansへの読取り/書込み権限

Admin

Configurator

構成MBeansへの読取り/書込み権限

Admin

Operator

構成MBeanへの読取り権限。実行時MBeanへの読取り/書込み権限

Operator

Monitor

すべてのMBeansへの読取り権限

Monitor

ApplicationAdmin

すべてのアプリケーションMBeansへの読取り/書込み権限

Admin

ApplicationConfigurator

すべてのアプリケーションMBeansへの読取り/書込み権限

Admin

ApplicationOperator

アプリケーション構成MBeanへの読取り権限。アプリケーション実行時MBeanへの読取り/書込み権限

Operator

ApplicationMonitor

すべてのアプリケーション実行時MBeansおよび構成MBeansへの読取り権限

Monitor

関連項目:

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループ、セキュリティ・ロール」

E.3.3 特定のアクセス制限

デフォルトでは、すべてのMBeanの書込み操作および更新操作には、ユーザーがAdminロールまたはConfiguratorロールのメンバーである必要があります。また、@Impact(value=1)タグで注釈を付けられた操作には、ユーザーがAdminロールのメンバーである必要があり、@Impact(value=0)タグで注釈を付けられた操作には、ユーザーがAdminロールまたはOperatorロールのメンバーである必要があります。

表E-3は、MBeanの属性および操作へのアクセスに必要なロールの説明をまとめたものです。

表E-3 操作別に必要なロール

影響値を持つ操作

MBeanのタイプ

必要なロール

INFOまたは属性ゲッター

システム構成MBean

Monitor、Operator、Configurator、Admin

INFOまたは属性ゲッター

アプリケーション構成MBean

Monitor、Operator、Configurator、Admin、ApplicationMonitor、ApplicationOperator、ApplicationConfigurator、ApplicationAdmin

ACTION、ACTION_INFO、UNKNOWNまたは属性セッター

システム構成MBean

Admin、Configurator

ACTION、ACTION_INFO、UNKNOWNまたは属性セッター

アプリケーション構成MBean

Admin、Configurator、ApplicationAdmin、ApplicationConfigurator

INFOまたは属性ゲッター

システム実行時MBean

Monitor、Operator、Configurator、Admin

INFOまたは属性ゲッター

アプリケーション実行時MBean

Monitor、Operator、Configurator、Admin、ApplicationMonitor、ApplicationOperator、ApplicationAdmin

ACTION、ACTION_INFO、UNKNOWNまたは属性セッター

システム実行時MBean

Admin、Operator

ACTION、ACTION_INFO、UNKNOWNまたは属性セッター

アプリケーション実行時MBean

Admin、Operator、ApplicationAdmin、ApplicationOperator

F OPSSのシステムおよび構成プロパティ

この付録では、サーバー起動時に設定するOPSSのシステム・プロパティおよび構成プロパティについて説明します。

次の項目について説明します。

- OPSSシステム・プロパティ

- OPSS構成プロパティ

すべてのOPSSのシステム変更および構成変更を有効にするには、サーバーを再起動する必要があります。

関連項目:

第E.2.3項「OPSS MBeanを使用したプログラミング」

F.1 OPSSシステム・プロパティ

導入または変更したシステム・プロパティは、サーバーを再起動するまで有効になりません。システム・プロパティを設定するには、setDomainEnv.shを編集してEXTRA_JAVA_PROPERTIES変数にそのプロパティを追加します。

表F-1は、OPSSで使用可能なシステム・プロパティを示しています。

表F-1 OPSSシステム・プロパティ

システム・プロパティ名

指定内容

common.components.home

共通のコンポーネント・ホームの場所。

Java EEアプリケーションとJava SEアプリケーションの両方で必須です。

デフォルト値なし

java.security.debug

JpsAuth.checkPermissionがSubject.doAsブロック内でコールされ、パーミッション・チェックで不合格になると、パーミッションは失敗します。

jps.auth.debugまたはjps.auth.debug.verboseを設定するだけでは、この場合に失敗の通知を受け取ることはできません。

オプション。

java.security.policy

Javaセキュリティ・ポリシー・ファイルの場所。

jps.app.permissioncollectionmap.size

メモリーに保持されるパーミッション・コレクション・マップ・エントリの数。各エントリは、パーミッションのセットに相当します。jps.policystore.ref.useSoftHardMapForSelectedMapsをtrueに設定する必要があります。

オプション。

有効な値: 正の整数。

デフォルト値: 512。

jps.authz

実行時およびデバッグのオーバーヘッドを軽減するJava SE Development Kit (JDK)メソッドのAccessController.checkPermissionへのコールの委任。

オプション。

有効な値: NULL、SM、ACCおよびDEBUG_NULL

デフォルト値なし

jps.auth.debug

サーバーのロギング出力。デフォルト値: false。

オプション。

jps.auth.debug.verbose

サーバーのロギング出力。デフォルト値: false。

オプション。

jps.combiner.optimize

サブジェクトの保護ドメインのキャッシュ。

オプション。

有効な値: true、false

デフォルト値: false。

jps.combiner.optimize.lazyeval

パーミッション・チェックのトリガー時にサブジェクトの保護ドメインの評価。

オプション。

有効な値: true、false

デフォルト値: false。

jps.combinermap.size

メモリーに保持されるコンバイナ・マップ・エントリの数。各エントリは、プリンシパルのセットに相当します。jps.policystore.ref.useSoftHardMapForSelectedMapsをtrueに設定する必要があります。

オプション。

有効な値: 正の整数。

デフォルト値: 128。

jps.deployment.handler.disabled

WebLogic Serverにデプロイされているアプリケーションのポリシーおよび資格証明の移行。WebLogic Serverに対してのみ有効です。

weblogic-application.xmlファイルにあるアプリケーション設定に関係なく、サーバーにデプロイされているすべてのアプリケーションについてアプリケーションのポリシーおよび資格証明の移行を無効にする場合はtrueに設定します。

オプション。

有効な値: true、false

デフォルト値: false。

jps.policystore.hybrid.mode

混合モード。有効になっている場合、ポリシー・プロバイダではjava.policyファイルおよびweblogic.policyファイルから読取りが実行され、セキュリティ・ストアではjps-config.xmlファイルから読取りが実行されます。

オプション。

有効な値: true、false

デフォルト値: true。

jps.policystore.ref.useSoftHardMapForSelectedMaps

マップ・タイプの使用。

マップ・タイプは、一部の構造を特別なキャッシュに保持することで、それらの構造がJava仮想マシンによるガベージ・コレクションの対象となるのを防ぐために使用されます。

falseの場合、SoftKeyHashMapタイプが使用されます。

trueの場合、SoftHardKeyHashMapタイプが使用されます。この設定により、一部のマップをメモリーで保持できるようになります。すべてのget/put操作でロック操作のオーバーヘッドが発生することに注意してください。

関連するjps.subjectmap.size、jps.combinermap.sizeおよびjps.app.permissioncollectionmap.sizeの各プロパティを参照してください。

オプション。

有効な値: true、false

デフォルト値: false。

jps.subject.cache.ttl

グループ・メンバーシップの変更が有効になるまでの時間(ミリ秒)。

この値は、Group Hierarchy Cacheの値と同期している必要があります。Group Hierarchy Cacheの値を変更した場合は、新しい値に一致するようにjps.subject.cache.ttlをリセットする必要があります。

オプション。

有効な値: 任意の正の整数。

デフォルト値: 60000

jps.subjectmap.size

メモリーに保持されるサブジェクト・マップ・エントリの数。各エントリは、サブジェクトに関するTTL情報に相当します。この設定を有効にするには、jps.policystore.ref.useSoftHardMapForSelectedMapsプロパティをtrueにする必要があります。

オプション。

有効な値: 正の整数。

デフォルト値: 128。

oracle.security.jps.config

ドメイン構成ファイルjps-config.xmlまたはjps-config-jse.xmlへのパス。これらのファイルでパスを指定する場合は、絶対パスまたは構成ファイルの場所を基準とする相対パスで指定できます。

必須。

デフォルト値なし

oracle.deployed.app.dir

コードソースURLのディレクトリへのパス。

オプション。

デフォルト値なし

例については、<url>を参照してください。

oracle.deployed.app.ext

コードソースURLの拡張。

オプション。

デフォルト値なし

例については、<url>を参照してください。

oracle.security.jps.log.for.approle.substring

指定した部分文字列が含まれるアプリケーション・ロールの名前。照合する部分文字列を指定しないと、すべてのアプリケーション・ロール名がログに記録されます。

オプション。

デフォルト値なし

oracle.security.jps.log.for.permeffect

付与または拒否された権限。値を指定しないと、(付与または拒否にかかわらず)すべての権限がログに記録されます。

オプション。

デフォルト値なし

oracle.security.jps.log.for.permclassname

指定した名前に完全一致するパーミッション・クラスの名前。照合する名前を指定しないと、すべてのパーミッション・クラス名がログに記録されます。

オプション。

デフォルト値なし

oracle.security.jps.log.for.permtarget.substring

指定した部分文字列が含まれるパーミッション・ターゲットの名前。照合する部分文字列を指定しないと、すべてのパーミッション・ターゲットがログに記録されます。

オプション。

デフォルト値なし

oracle.security.jps.log.for.enterprise.principalname

指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)の名前。照合する名前を指定しないと、すべてのプリンシパル名がログに記録されます。

オプション。

デフォルト値なし

opss.audit.logDirectory

jps-config-jse.xml構成ファイルで設定されていない場合は、SEアプリケーション用の監査ログ・ファイルの場所。

オプション。

デフォルト値なし

有効値: 任意の書込みディレクトリ。

wlst.offline.log

オフラインのWLSTを実行する際のログ・ファイルの場所。

オプション。

デフォルト値なし

有効な値: <filename>、stdout、strerr、disable。

wlst.offline.log.priority

通知のレベル。

オプション。

デフォルト値なし

有効な値: OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL、デバッグ、情報、警告、エラー、致命的。

関連項目:

第J.2.3項「システム・プロパティ」

第E.1項「スクリプトを使用したサービスの構成」

F.2 OPSS構成プロパティ

次の各項では、サービス・プロパティについて説明します。

- OPSSサービスに共通するプロパティ

- ポリシー・サービスのプロパティ

- 資格証明サービスのプロパティ

- LDAPアイデンティティのプロパティ

- すべてのLDAPサーバーに共通するプロパティ

- トラスト・サービスのプロパティ

- 監査サービスのプロパティ

- キーストア・サービスのプロパティ

- 匿名ロールと認証ロールのプロパティ

F.2.1 OPSSサービスに共通するプロパティ

表F-2は、トラスト・ストア・サービスを除くすべてのサービスに共通するOPSSプロパティの説明をまとめたものです。トラスト・ストア・サービスのプロパティの詳細は、「トラスト・サービスのプロパティ」を参照してください。

表F-2 共通プロパティ

プロパティ名

指定内容

次のプロパティは、Java EEアプリケーションとJava SEアプリケーションの両方で有効です。

bootstrap.security.principal.key

LDAPストアにアクセスするためのパスワード資格証明のキーで、cwallet.ssoファイルに格納されています。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

必須。

デフォルト値なし

すぐに使用できる値はbootstrapです。

bootstrap.security.principal.map

LDAPストアにアクセスするためのパスワード資格証明のマップで、cwallet.ssoファイルに格納されています。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

必須。

デフォルト値: BOOTSTRAP_JPS

jdbc.url

JBDCのURL。

Java SEアプリケーションとJava EEアプリケーションで有効です。

DBセキュリティ・ストアにのみ適用されます。

必須。

デフォルト値なし

値の例: jdbc:oracle:thin:@xxx27.com:1345:asi102cn

ldap.url

LDAPセキュリティ・ストアのURLで、形式はldap://host:portです。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアにのみ適用されます。

必須。

デフォルト値なし

oracle.security.jps.farm.name

LDAPストア内のドメイン・ノードの相対識別名形式。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

必須。

デフォルト値なし

oracle.security.jps.ldap.root.name

LDAPストア内のルート・ノードの相対識別名形式。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

必須。

デフォルト値なし

oracle.security.jps.pdp.PolicyProvider.PermissionCollectionCache.MaxSize

保護ドメインおよびリクエスト・パーミッション・クラスごとにキャッシュで使用できるパーミッション・コレクションの最大数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 5000

server.type

セキュリティ・ストアのタイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

必須。

デフォルト値なし

値: OID、DB_ORACLE。

次のプロパティは、Java EEアプリケーションでのみ有効です。

datasource.jndi.name

Java Database Connectivity (JDBC)データ・ソース・インスタンスのJava Naming and Directory Interface (JNDI)名。

Java EEアプリケーションでのみ有効です。

DBセキュリティ・ストアにのみ適用されます。

必須。

デフォルト値なし

oracle.security.jps.failover.retry.times

再試行回数。

Java EEアプリケーションでのみ有効です。

DBセキュリティ・ストアにのみ適用されます。

オプション。

デフォルト値: 3

oracle.security.jps.failover.retry.interval

次に再試行するまでの秒数。

Java EEアプリケーションでのみ有効です。

DBセキュリティ・ストアにのみ適用されます。

オプション。

デフォルト値: 15

weblogic.dbuser.map

weblogic.dbuser.key

Weblogic DBユーザー/パスワードの資格証明のマップおよびキー。oracle.security.jps.db.useWeblogicDBUserMapKeyがtrueの場合にのみ適用されます。この場合、両方が構成されるか、またはどちらも構成されません。

Java EEアプリケーションでのみ有効です。

DBセキュリティ・ストアにのみ適用されます。

オプション。

デフォルト値なし。

oracle.security.jps.db.useWeblogicDBUserMapKey

Weblogic DBユーザー/パスワードのマップおよびキーの場所。このプロパティは、DBセキュリティ・ストアに再関連付けする際に自動的に設定されます。

Java EEアプリケーションでのみ有効です。

DBセキュリティ・ストアにのみ適用されます。

オプション。

有効な値: trueまたはfalse。

デフォルト値: false。

trueの場合は、weblogic.dbuser.mapプロパティおよびweblogic.dbuser.keyプロパティにより、Weblogic DBユーザー/パスワードの資格証明のマップおよびキーが指定されます。

そうではなく、falseの場合または指定されない場合は、bootstrap.security.principal.mapプロパティおよびbootstrap.security.principal.keyプロパティにより、Weblogic DBユーザー/パスワードの資格証明のマップおよびキーが指定されます。

次のプロパティは、Java SEアプリケーションでのみ有効です。

security.principal

bootstrapで指定されたユーザー名のかわりに使用する、クリアテキストによるプリンシパル名。開発環境でのみ使用できます。

Java SEアプリケーションでのみ有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値なし

security.credential

bootstrapで指定されたパスワードのかわりに使用する、クリアテキストによるセキュリティ・プリンシパルのパスワード。使用はお薦めしません。

Java SEアプリケーションでのみ有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値なし

jdbc.driver

JDBCドライバ。

Java SEアプリケーションでのみ有効です。

DBセキュリティ・ストアにのみ適用されます。

必須。

デフォルト値なし

値の例: oracle.jdbc.driver.OracleDriver

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.2 ポリシー・サービスのプロパティ

次の各項では、ポリシー・サービスのプロパティについて説明します。

- ポリシー・サービスの構成

- 実行時ポリシーの構成

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.2.1 ポリシー・サービスの構成

LDAPまたはDBのセキュリティ・ストアで使用するポリシー・ストア・プロバイダ・クラスは、oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProviderクラスです。

表F-3に、ポリシー・ストア固有のプロパティを示します。その他のプロパティについては、「OPSSサービスに共通するプロパティ」を参照してください。

表F-3 ポリシーのプロパティ

プロパティ名

指定内容

oracle.security.jps.policystore.resourcetypeenforcementmode

次のいずれかのチェックで不合格になった場合の例外のスロー。

- 2つのリソース・タイプが同じパーミッション・クラスを共有する場合、そのパーミッションはResourcePermissionまたは拡張AbstractTypedPermissionのいずれかである必要があり、そのリソース・タイプが作成できないことの確認。

- すべてのパーミッションにリソース・タイプが定義されており、リソース・マッチャ・パーミッション・クラスと付与するパーミッションが一致することの確認。

Strictに設定した場合、いずれかのチェックで不合格になると、例外がスローされ、操作は停止します。

Lenientに設定した場合、いずれかのチェックで不合格になっても例外はスローされず、操作は途切れることなく続行され、検出されたあらゆる矛盾がログ・ファイルに記録されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: Lenient

有効な値: Strict、Lenient

例1

次の例は、Java EEアプリケーション用のポリシー・ストア・インスタンスの構成を示しています。

<propertySet name="props.ldap.1">
<property name="java.naming.ldap.derefAliases" value="never"/>
<property name="bootstrap.security.principal.key" value="bootstrap_6aCNhgRM3zF04ToliwecdF6K3oo="/>
<property name="oracle.security.jps.farm.name" value="cn=compact1_oid26008"/>
<property name="server.type" value="OID"/>
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsTestNode"/>
<property name="ldap.url" value="ldap://myComp.com:2020"/>
</propertySet>

<serviceProvider type="POLICY_STORE" name="policystore.provider" class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider"/>

<serviceInstance name="policystore.ldap" provider="policystore.provider">
<propertySetRef ref="props.ldap.1"/>
</serviceInstance>

例2

次の例は、Java SEアプリケーション用のLDAPポリシー・ストア・インスタンスの構成を示しています。

<serviceInstance name="policystore.oid" provider="policy.oid">
<property value="OID" name="server.type"/>
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property name="ldap.url" value="ldap://myHost.com:1234"/>
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsNode"/>
<property name="oracle.security.jps.farm.name" value="cn=domain1"/>
</serviceInstance>

例3

次の例は、Java EEアプリケーション用のDBセキュリティ・ストアの構成を示しています。

<jpsConfig>
...
<propertySets>
<!-- property set props.db.1 common to all DB services -->
<propertySet name="props.db.1">
<property name="jdbc.url" value="jdbc:oracle:thin@xxx.com:1521:orcl"/>
<property name="datasource.jndi.name"  value="opssds"/>
<property value="cn=farm" name="oracle.security.jps.farm.name"/>
<property value="cn=jpsroot" name="oracle.security.jps.ldap.root.name"/>
<property value="dsrc_lookup_key"
name="bootstrap.security.principal.key"/>
<property value="credential_map" name="bootstrap.security.principal.map"/>
</propertySet>
</propertySets>

<serviceProviders>
<serviceProvider      class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider"
type="POLICY_STORE" name="rdbms.policystore.provider" >
<description>RDBMS based PolicyStore provider</description>
</serviceProvider>

<serviceProvider type="KEY_STORE" name="keystore.provider"        class="oracle.security.jps.internal.keystore.KeyStoreProvider">
<description>PKI Based Keystore Provider</description>
<property name="provider.property.name" value="owsm"/>
</serviceProvider>

<serviceProvider name="pdp.service.provider" type="PDP"       class="oracle.security.jps.az.internal.runtime.provider.PDPServiceProvider">
<description>OPSS Runtime Service provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name="policystore.rdbms"                      provider="rdbms.policystore.provider">
<property value="DB_ORACLE" name="server.type"/>
<propertySetRef ref = "props.db.1"/>
<property name="session_expiration_sec" value="60"/>
<property name="failover.retry.times"  value="5"/>
</serviceInstance>

<serviceInstance name="credstore.rdbms" provider="rdbms.credstore.provider">
<propertySetRef ref = "props.db.1"/>
</serviceInstance>

<serviceInstance name="keystore.rdbms" provider="rdbms.keystore.provider">
<propertySetRef ref = "props.db.1"/>
<property name="server.type"  value="DB_ORACLE"/>
</serviceInstance>

<serviceInstance name="pdp.service" provider="pdp.service.provider">
<property name="oracle.security.jps.runtime.pd.client.sm_name" value="permissionSm"/>
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled" value="true"/>
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity" value="500"/>
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage" value="10"/>
<property name="failover.retry.times"  value="5"/>
<property name="failover.retry.interval" value="20"/>
<property name="oracle.security.jps.policystore.refresh.purge.timeout",
value="30000"/>
<propertySetRef ref = "props.db.1"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="pdp.service"/>
<serviceInstanceRef ref="policystore.rdbms"/>
<serviceInstanceRef ref="credstore.rdbms"/>
<serviceInstanceRef ref="keystore.rdbms"/>
</jpsContext>
</jpsContexts>
...
</jpsConfig>

例4

次の例は、Java SEアプリケーション用のDBポリシー・ストアの構成を示しています。

<serviceInstance name="policystore.rdbms" provider="policy.rdbms">
<property name="server.type" value="DB_ORACLE"/>
<property name="jdbc.url" value="jdbc:oracle:thin:@xxx.com:1722:orcl"/>
<property name="jdbc.driver" value="oracle.jdbc.driver.OracleDriver"/>
<property name="bootstrap.security.principal.key" value="bootstrap_DWgpEJgXwhDIoLYVZ2OWd4R8wOA=" />
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsTestNode"/>
<property name="oracle.security.jps.farm.name" value="cn=view_steph.atz"/>
</serviceInstance>

F.2.2.2 実行時ポリシーの構成

LDAPまたはDBのセキュリティ・ストアで使用する実行時ポリシー・ストア・プロバイダ・クラスは、oracle.security.jps.az.internal.runtime.provider.PDPServiceProviderクラスです。

表F-4は、ポリシー・ストア・インスタンスの実行時のプロパティを示しています。

表F-4 実行時ポリシーのプロパティ

プロパティ名

指定内容

oracle.security.jps.policystore.rolemember.cache.type

ロール・メンバーのキャッシュ・タイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値:

- STATIC - キャッシュ・オブジェクトは静的にキャッシュされ、FIFOなど、適用されたキャッシュ戦略に応じてのみ明示的にクリーンアップされます。ガベージ・コレクタでは、このタイプのキャッシュはクリーンアップされません。

- SOFT - メモリーが不足している場合、このタイプのキャッシュのクリーンアップはガベージ・コレクタに依存します。

- WEAK - このタイプのキャッシュの動作は、タイプSOFTのキャッシュとよく似ていますが、ガベージ・コレクタによってより頻繁にクリーンアップされます。

デフォルト値: STATIC。

oracle.security.jps.policystore.rolemember.cache.strategy

ロール・メンバーのキャッシュで使用する方針のタイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値:

- FIFO - キャッシュでは、先入れ先出し方針が実装されます。

- NONE - リフレッシュまたは再起動が実行されるまで、キャッシュ内のエントリはすべて増大します。キャッシュのサイズは制御できません。お薦めできませんが、ポリシーのフットプリントがきわめて小さい場合には効率的です。

デフォルト値: FIFO。

oracle.security.jps.policystore.rolemember.cache.size

メンバー・キャッシュに維持するロール数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 1000。

oracle.security.jps.policystore.policy.lazy.load.enable

ポリシーの遅延ロード。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値: true、false

デフォルト値: true。

oracle.security.jps.policystore.policy.cache.strategy

パーミッションのキャッシュで使用する方針のタイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値:

- PERMISSION_FIFO - キャッシュでは、先入れ先出し方針が実装されます。

- NONE - リフレッシュまたは再起動が実行されるまで、キャッシュ内のエントリはすべて増大します。キャッシュのサイズは制御できません。お薦めできませんが、ポリシーのフットプリントがきわめて小さい場合には効率的です。

デフォルト値: PERMISSION_FIFO。

oracle.security.jps.policystore.policy.cache.size

パーミッション・キャッシュに維持するパーミッション付与数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 1000。

oracle.security.jps.policystore.refresh.enable

ポリシー・ストアのリフレッシュ。このプロパティを設定した場合、oracle.security.jps.ldap.cache.enableは設定できません。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値: true、false

デフォルト値: true。

oracle.security.jps.ldap.cache.enable

キャッシュのリフレッシュ。このプロパティを設定した場合、oracle.security.jps.policystore.refresh.enableは設定できません。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値: true、false

デフォルト値: true。

oracle.security.jps.policystore.refresh.purge.timeout

セキュリティ・ストア・キャッシュがパージされるまでの時間(ミリ秒)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値は43200000 (12時間)です。

oracle.security.jps.ldap.policystore.refresh.interval

セキュリティ・ストアで変更がポーリングされる間隔(ミリ秒)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 600000 (10分)。

oracle.security.jps.policystore.rolemember.cache.warmup.enable

ApplicationRoleメンバーシップ・キャッシュの作成方法。trueの場合、キャッシュはサーバーの起動時に作成されます。それ以外の場合は、必要に応じて作成されます(遅延ロード)。

ユーザーおよびグループの数がアプリケーション・ロールの数を大きく上回っている場合は、trueに設定します。アプリケーション・ロールの数が非常に多い場合は、falseに設定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

有効な値: true、false

デフォルト値: false。

security.jps.runtime.pd.client.localpolicy.work_folder

一時的な保存に使用するフォルダ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイル・セキュリティ・ストア、LDAPセキュリティ・ストアおよびDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: システムの一時フォルダ。

oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled

認可キャッシュは有効になっていること。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイル・セキュリティ・ストア、LDAPセキュリティ・ストアおよびDBセキュリティ・ストアに適用されます。

オプション。

有効な値: true、false

デフォルト値: false。

oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage

削除容量に達したときに削除するセッションの比率。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイル・セキュリティ・ストア、LDAPセキュリティ・ストアおよびDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 10

oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity

維持する認可とロールのマッピング・セッションの最大数。最大数に達すると、古いセッションが削除され、必要になったときに再確立されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイル・セキュリティ・ストア、LDAPセキュリティ・ストアおよびDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 500

oracle.security.jps.pdp.AuthorizationDecisionCacheTTL

セッション・データをキャッシュする秒数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイル・セキュリティ・ストア、LDAPセキュリティ・ストアおよびDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: 60

oracle.security.jps.policystore.resourcetypeenforcementmode

次のいずれかのチェックで不合格になった場合の例外のスロー。

- 2つのリソース・タイプが同じパーミッション・クラスの場合、そのパーミッションはResourcePermissionまたは拡張AbstractTypedPermissionでなければならず、この最後のリソース・タイプが作成不可能であることの確認。

- すべてのパーミッションにリソース・タイプが定義されており、リソース・マッチャ・パーミッション・クラスと付与するパーミッションが一致することの確認。

Strictに設定した場合、いずれかのチェックで不合格になると、例外がスローされ、操作は終了します。

Lenientに設定した場合、いずれかのチェックで不合格になっても例外はスローされず、操作は途切れることなく続行され、検出されたあらゆる矛盾がログ・ファイルに記録されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPセキュリティ・ストアとDBセキュリティ・ストアに適用されます。

オプション。

デフォルト値: Lenient

有効な値: Strict、Lenient

F.2.3 資格証明サービスのプロパティ

表F-5は、資格証明ストア・インスタンス固有のプロパティを示しています。その他のプロパティについては、「OPSSサービスに共通するプロパティ」を参照してください。

表F-5 資格証明ストアのプロパティ

プロパティ名

指定内容

encrypt

資格証明の暗号化。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイルおよびLDAPストアにのみ適用されます。

有効な値: true、false

オプション。

デフォルト値: false。

次の例は、Java EEアプリケーション用の資格証明ストアの構成を示しています。

<propertySet name="props.ldap.1">
<property name="java.naming.ldap.derefAliases" value="never"/>
<property name="bootstrap.security.principal.key" value="bootstrap_6aCNhgRM3zF04ToliwecdF6K3oo="/>
<property name="oracle.security.jps.farm.name" value="cn=compact1_oid26008"/>
<property name="server.type" value="OID"/>
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsTestNode"/>
<property name="ldap.url" value="ldap://myComp.com:2020"/>
</propertySet>

<serviceProvider type="CREDENTIAL_STORE" name="ldap.credentialstore.provider" class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider"/>
<serviceInstance name="credstore.ldap" provider="ldap.credentialstore.provider">
<propertySetRef ref="props.ldap.1"/>
</serviceInstance>

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.4 LDAPアイデンティティのプロパティ

表F-6は、LDAPアイデンティティ・ストアのプロパティと、拡張プロパティの場合はその旨、ユーザーおよびロールAPIのプロパティをまとめたものです。

表F-6 LDAPアイデンティティ・ストアのプロパティ

プロパティ名

指定内容

idstore.type

アイデンティティ・ストアのタイプ。

Java SEアプリケーションとJava EEアプリケーションで有効です。

必須

有効な値:

OID - Oracle Internet Directory

OVD - Oracle Virtual Directory

ACTIVE_DIRECTORY - Microsoft Active Directory

IPLANET - Oracle Directory Server Enterprise Edition

EDIRECTORY - Novell eDirectory

OPEN_LDAP - OpenLdap

LIBOVD - OracleライブラリOVD

CUSTOM - その他の任意のタイプ

カスタムの認証プロバイダを使用する場合、サービス・インスタンスの構成に次のいずれかのプロパティを含める必要があります。

<property name="idstore.type" value="<your-idstore-type>"
<property name="ADF_IM_FACTORY_CLASS" value="<your-IDM-FACTOY_CLASS_NAME>"

ユーザーおよびロールAPIの対応するプロパティ: ADF_IM_FACTORY_CLASS

ldap.url

LDAP URL値。

Java SEアプリケーションとJava EEアプリケーションで有効です。

必須。

デフォルト値なし

値の例: ldap://myServerName.com:1389。

ユーザーおよびロールAPIのタイプするプロパティ: ADF_IM_PROVIDER_URL

user.search.bases

LDAPサーバーに対するDN形式のユーザー検索ベース。拡張プロパティ。

Java SEアプリケーションとJava EEアプリケーションで有効です。

必須。

デフォルト値なし

値の例: cn=users,dc=us,dc=abc,dc=com

ユーザーおよびロールAPIの対応するプロパティ: USER_SEARCH_BASES

group.search.bases

LDAPサーバーに対するDN形式のグループまたはエンタープライズ検索ベース。拡張プロパティ。

Java SEアプリケーションとJava EEアプリケーションで有効です。

必須

デフォルト値なし

値の例: cn=groups,dc=us,dc=abc,dc=com

ユーザーおよびロールAPIの対応するプロパティ: ROLE_SEARCH_BASES

idstore.config.provider

idstoreプロバイダ・クラス。

Java EEアプリケーションでのみ有効です。

必須

次の値のみサポートされています。

oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider

group.create.bases

グループの作成に使用するベースDN。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ユーザーおよびロールAPIを使用した書込み操作を可能にする場合は必須それ以外の場合はオプション。

シングルDNの値の例:

<extendedProperty>
<name>group.create.bases</name>
<values>
<value>cn=groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>

ユーザーおよびロールAPIの対応するプロパティ: ROLE_CREATE_BASES

user.create.bases

ユーザーの作成に使用するベースDN。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ユーザーおよびロールAPIを使用した書込み操作を可能にする場合は必須それ以外の場合はオプション。

シングルDNの値の例:

<extendedProperty>
<name>user.create.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>

ユーザーおよびロールAPIの対応するプロパティ: USER_CREATE_BASES

group.filter.object.classes

グループの検索に使用するオブジェクト・クラスの完全修飾名。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: groupOfUniqueNames。

ユーザーおよびロールAPIの対応するプロパティ: ROLE_FILTER_OBJECT_CLASSES

group.mandatory.attrs

グループの作成時に指定する必要がある属性。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例:

<extendedProperty>
<name>group.mandatory.attrs</name>
<values>
<value>cn</value>
<value>objectClass</value>
</values>
</extendedProperty>

ユーザーおよびロールAPIの対応するプロパティ: ROLE_MANDATORY_ATTRS

group.member.attrs

グループのメンバーの識別名(DN)を指定する静的ロールの属性。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例:

<extendedProperty>
<name>group.member.attrs</name>
<values>
<value>uniqueMember</value>
</values>
</extendedProperty>

ユーザーおよびロールAPIの対応するプロパティ: ROLE_MEMBER_ATTRS

group.object.classes

グループを表すために使用する1つ以上のスキーマ・オブジェクト・クラスの完全修飾名。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例:

<extendedProperty>
<name>group.object.classes</name>
<values>
<value>top</value>
<value>groupOfUniqueNames</value>
</values>
</extendedProperty>

ユーザーおよびロールAPIの対応するプロパティ: ROLE_OBJECT_CLASSES

group.selected.create.base

グループ作成用のベースDN。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: cn=users,dc=us,dc=abc,dc=com (シングルDN)

ユーザーおよびロールAPIの対応するプロパティ: ROLE_SELECTED_CREATEBASE

groupname.attr

グループ名を一意に識別する属性。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: cn

ユーザーおよびロールAPIの対応するプロパティ: ROLE_NAME_ATTR

group.selected.search.base

グループ検索用のベースDN。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: cn=users,dc=us,dc=abc,dc=com (シングルDN)

max.search.filter.length

検索フィルタの最大文字数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値: 正の整数。

ユーザーおよびロールAPIの対応するプロパティ: MAX_SEARCHFILTER_LENGTH

search.type

リポジトリに対する問合せに使用する検索のタイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

有効な値: SIMPLE、PAGEDまたはVIRTUAL_LIST_VIEW。

ユーザーおよびロールAPIの対応するプロパティ: IDENTITY_SEARCH_TYPE

user.filter.object.classes

ユーザーの検索に使用するオブジェクト・クラスの完全修飾名。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: inetOrgPerson

ユーザーおよびロールAPIの対応するプロパティ: USER_FILTER_OBJECT_CLASSES

user.login.attr

ユーザーのログインID。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例:

<property name="user.login.attr" value="mail"/>

ユーザーおよびロールAPIの対応するプロパティ: USER_LOGIN_ATTR

user.mandatory.attrs

ユーザーの作成時に指定する必要がある属性。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例:

<extendedProperty>
<name>user.mandatory.attrs</name>
<values>
<value>cn</value>
<value>objectClass</value>
<value>sn</value>
</values>
</extendedProperty>

ユーザーおよびロールAPIの対応するプロパティ: USER_MANDATORY_ATTRS

user.object.classes

ユーザーを表現するために使用するスキーマ・クラスの完全修飾名。拡張プロパティ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

ユーザーおよびロールAPIの対応するプロパティ: USER_OBJECT_CLASSES

username.attr

ユーザー名を一意に識別するLDAP属性。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

ユーザーおよびロールAPIの対応するプロパティ: USER_NAME_ATTR

username属性をリセットした場合は、username.attrもリセットする必要があることに注意してください。

ldap.host

アイデンティティ・ストアをホストするシステムの名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

subscriber.name

アイデンティティ・ストアのデフォルトのレルム。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: dc=us,dc=oracle,dc=com。

ユーザーおよびロールAPIの対応するプロパティ: ADF_IM_SUBSCRIBER_NAME

virtualize

検索と変更を実行できる場所。trueの場合、構成されているすべての認証プロバイダで検索と変更が可能になります。falseの場合、構成されているスタックの最初の認証プロバイダでのみ検索と変更が可能になります。

すべてのプロバイダでユーザーおよびロールAPIを使用して情報の検索または書込みを実行する場合は、trueに設定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

有効な値: trueまたはfalse。

デフォルト値: false。

値の例:

<property name="virtualize" value="true"/>

次の例は、Java SEアプリケーション用のLDAPアイデンティティ・ストアの構成を示しています。

<serviceInstance name="idstore.ldap" provider="idstore.ldap.provider">
<property name="idstore.type" value="OID"/>
<property name="ldap.url" value="ldap://myHost.com:1234"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=oracle,dc=com</value>
</values>
</extendedProperty>
</serviceInstance>

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.5 すべてのLDAPサーバーに共通するプロパティ

表F-7に、LDAPサーバーに共通するプロパティを示します。

LDAPアイデンティティ・ストアの場合、ユーザーおよびロールAPIでJNDI接続ファクトリを使用するときに接続プールのプロパティが必ず選択されるように、アイデンティティ・ストア・インスタンスに次のプロパティを含める必要があります。

<property
name="INITIAL_CONTEXT_FACTORY" value="com.sun.jndi.ldap.LdapCtxFactory"/>

表F-7 LDAPの汎用的なプロパティ

プロパティ名

指定内容

connection.pool.authentication

JNDI接続プールが使用するLDAP接続のタイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値: none、simpleおよびDIGEST-MD5。

デフォルト値: simple。

connection.pool.max.size

LDAP接続プールの最大接続数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: 30

connection.pool.min.size

LDAP接続プールの最小接続数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: 5

connection.pool.protocol

LDAP接続に使用するプロトコル。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値: plain、ssl。

デフォルト値: plain。

connection.pool.provider.type

使用する接続プール。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値: JNDI、IDM。

デフォルト値: JNDI。

connection.pool.timeout

アイドル接続がプールにとどまっていられるミリ秒数。タイムアウト後に接続は閉じられ、プールから削除されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値: 300000 (5分)

oracle.security.jps.ldap.max.retry

LDAP接続に問題がある場合の、最大再試行回数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

値の例: 5

次の例は、いくつかのプロパティの構成を示しています。

<!-- common properties used by all LDAPs -->
<property name="oracle.security.jps.farm.name" value="cn=OracleFarmContainer"/>
<property name="oracle.security.jps.ldap.root.name"
value="cn=OracleJpsContainer"/>
<property name="oracle.security.jps.ldap.max.retry" value="5"/>

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.6 トラスト・サービスのプロパティ

表F-8に、トラスト・サービス固有のプロパティを示します。

表F-8 トラストストアのプロパティ

プロパティ名

指定内容

merge.jdkcacerts.with.trust

kss://system/trustへのキーストア問合せでkss://system/publiccacertsキーストアの公開CA証明書を戻すかどうか。キーストア問合せのリターンにpubliccacertsの証明書をすべて含める場合は、trueに設定します。問合せのリターンに含めない場合は、falseに設定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

値: trueまたはfalse

オプション。

デフォルト: false。

trust.keystoreType

トラスト・サービス・ストアのタイプ(Javaキーストア(JKS)またはキーストア・サービス(KSS)キーストア)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

有効な値: JKSまたはKSS。

デフォルトなし。

指定されておらず、KSSがプロビジョニングされている場合、値はKSSです。それ以外の場合は、JKSです。

trust.keyStoreName

次の形式のストア名。

kss://<stripeName>/<keyStoreName>

trust.keystoreTypeがKSSの場合にのみ適用されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: kss://opss/trustservice_ks。

trust.trustStoreName

次の形式のストアURL。

kss://<stripeName>/<keyStoreName>

trust.keystoreTypeがKSSの場合にのみ適用されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: kss://opss/trustservice_ts。

trust.aliasName

キーストアからX.509証明書と秘密鍵を取得するために使用する別名。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: Oracle WebLogic Serverドメインの名前。

trust.issuerName

ターゲット・トラスト・サービスでトークンを取得して検証するために使用される(トークンに含まれる)名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: WebLogic Serverドメインの名前。

trust.provider.className

トラスト・プロバイダ・クラスの完全修飾名。

Java EEアプリケーションとJava SEアプリケーションで有効です。

必須。

値: サポートされている値はoracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImplのみです。

trust.clockSkew

時間の条件を検証する際に許容される時間差(秒)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: 0。

trust.token.validityPeriod

トークンが発行された後の有効時間(秒)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

必須。

デフォルトなし。

trust.csf.map

キーストアにアクセスするための資格証明のマップ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.csf.mapの値。

trust.csf.keystorePass

trust.keystoreTypeがJKSである場合にのみ適用し、秘密鍵にアクセスするための資格証明のキーを指定します(マップはtrust.csf.mapによって設定されます)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.pass.csf.keyの値。

trust.csf.keyPass

キーストアにアクセスするための資格証明のキー(マップはtrst.csf.mapによって設定されます)。trust.keystoreTypeがJKSの場合にのみ適用されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.sig.csf.keyの値。

trust.token.includeCertificate

Security Assertion Markup Language (SAML)トークンに証明書が含まれていること。

Java EEアプリケーションとJava SEアプリケーションで有効です。

必須。

有効な値: trueまたはfalse。

デフォルト: false。

次の例は、トラスト・サービスの構成を示しています。

<propertySet name="trust.provider.embedded">
<property name="trust.provider.className" value="oracle.security.jps.internal.trust.provider.embedded.EmbeddedProviderImpl"/>
<property name="trust.clockSkew" value="60"/>
<property name="trust.token.validityPeriod" value="1800"/>
<property name="trust.aliasName" value="orakey"/>
<property name="trust.issuerName" value="orakey"/>
<property name="trust.csf.map " value="my-csf-map"/>
<property name="trust.csf.keystorePass" value="my-keystore-csf-key"/>
<property name="trust.csf.keypass" value="my-signing-csf-key"/>
</propertySet>

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.7 監査サービスのプロパティ

表F-9に、監査固有のプロパティを示します。その他のプロパティについては、「OPSSサービスに共通するプロパティ」を参照してください。

表F-9 監査のプロパティ

プロパティ名

指定内容

必須

値

デフォルト値

audit.filterPreset

監査レベル。

いいえ

None、Low、MediumまたはHigh

なし

audit.customEvents

監査対象のカスタム・イベント。イベントは、コンポーネント・タイプを使用して修飾する必要があります。イベントはカンマ、コンポーネント・タイプはセミコロンで区切ります。

例:

JPS:CheckAuthorization, CreateCredential; OIF:UserLogin

いいえ

audit.specialUsers

filterPresetプロパティがnoneの場合でも、アクティビティが常に監査対象となるユーザーのリスト。

いいえ

audit.maxFileSize

監査イベントが書き込まれるバスストップ・ファイルのサイズ。バイト単位

いいえ

104857600

audit.loader.interval

監査ローダーがデータベースにアップロードする間隔(秒)。

いいえ

15秒

audit.loader
.repositoryType

監査イベントのストア・タイプ。タイプがデータベース(DB)の場合は、audit.loader.jndiまたはJDBCプロパティも定義します。

はい

File、DB

File

audit.loader.jndi

データベースに監査イベントをアップロードするための、アプリケーション・サーバー内のデータ・ソースのJNDI名。

いいえ

jdbc/AuditAppendDataSource

audit.db.principal.map audit.db.principal.key

Java SEアプリケーションが実行されており、リポジトリ・タイプがDBの場合の、ブートストラップ資格証明ストア内のJDBCユーザー名とパスワード資格証明に対するマップとキー。

いいえ

audit.loader.jdbc.string

Java SEアプリケーションが実行されており、リポジトリ・タイプがDBの場合の、JDBC接続に対するJDBC文字列。

いいえ

audit.logDirectory

バスストップ・ファイルのベース・ディレクトリ。

JavaSEでは必須

jse

audit.timezone

特定のタイムゾーンを使用したイベントの記録。

いいえ

UTC、ローカル

UTC

audit.change.scanning.
interval

サービスが変更をチェックするまでの時間(ミリ秒)。

いいえ

0(ゼロ)より大きい数値

60000 (60秒)

次の例は、構成でのプロパティの使用方法を示しています。

<serviceInstance name="audit" provider="audit.provider" location="./audit-store.xml">
<property name="audit.filterPreset" value="Medium"/>
<property name="audit.loader.jndi" value="jdbc/AuditAppendDataSource"/>
<property name="audit.loader.repositoryType" value="DB" />
<property name="server.type" value="DB_ORACLE"/>
<property name="audit.timezone" value="local" />
</serviceInstance>

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.8 キーストア・サービスのプロパティ

表F-10に、キーストア固有のプロパティを示します。その他のプロパティについては、「OPSSサービスに共通するプロパティ」を参照してください。

表F-10 キーストア・サービスのプロパティ

プロパティ名

指定内容

必須

値

デフォルト

keystore.file.path

ファイル・プロバイダが構成されている場合のkeystores.xmlファイルの場所。

ファイル・キーストア・プロバイダが構成されている場合は、はい。

-

./

ca.key.alias

キーストア・サービス・インスタンスに使用されているサードパーティCAのキー別名。

いいえ

-

-

location

キーストアの場所の絶対パスまたは相対パス。

keystore.typeがJKSの場合は、はい。

keystore.typeがPKCS11またはHSM (LunaSA)の場合は、いいえ。

キーストアへのパス

./default-keystore.jks

keystore.type

キーストアのタイプ。

いいえ

KSS、JKS、PKCS11、Luna

JKS

keystore.csf.map

OWSMで使用される資格証明ストア・マップ名。OWSMでのみ使用します。

いいえ

資格証明ストアのマップ名

oracle.wsm.security

keystore.pass.csf.key

キーストア・パスワードを指す資格証明ストア・キー。OWSMでのみ使用します。

いいえ

資格証明ストアのcsfキー名

keystore-csf-key

keystore.sig.csf.key

キーストア内の署名鍵の別名およびパスワードを指す資格証明ストアのキー名。HSMの場合は、資格証明ストアのキー名ではなく、ダイレクト・キー別名です。OWSMでのみ使用します。

いいえ

資格証明ストアのcsfキー名、またはHSMの場合はダイレクト別名

sign-csf-key

keystore.enc.csf.key

キーストア内の暗号化鍵の別名およびパスワードを指す資格証明ストアのキー名。HSMの場合は、資格証明ストアのキー名ではなく、ダイレクト・キー別名です。OWSMでのみ使用します。

いいえ

資格証明ストアのcsfキー名、またはHSMの場合はダイレクト別名

enc-csf-key

次の例は、キーストアの構成を示しています。

<propertySet name="props.ldap.1">
<property name="java.naming.ldap.derefAliases" value="never"/>
<property name="bootstrap.security.principal.key" value="bootstrap_6aCNhgRM3zF04ToliwecdF6K3oo="/>
<property name="oracle.security.jps.farm.name" value="cn=compact1_oid26008"/>
<property name="server.type" value="OID"/>
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsTestNode"/>
<property name="ldap.url" value="ldap://myComp.com:2020"/>
</propertySet>

<serviceProvider type="KEY_STORE" name="keystore.provider" class="oracle.security.jps.internal.keystore.KeyStoreProvider">
</serviceProvider>
<serviceInstance name="keystore.ldap" provider="keystore.provider">
<propertySetRef ref="props.ldap.1"/>
</serviceInstance>

次の例は、LDAPプロバイダ用のキーストアの構成を示しています。

<serviceInstance name="keystore" provider="keystore.provider"       location="./default-keystore.jks">
<description>Default JPS Keystore Service</description>
<property name="server.type" value="OID"/>
<property name="keystore.type" value="JKS"/>
<property name="keystore.csf.map" value="oracle.wsm.security"/>
<property name="keystore.pass.csf.key" value="keystore-csf-key"/>
<property name="keystore.sig.csf.key" value="sign-csf-key"/>
<property name="keystore.enc.csf.key" value="enc-csf-key"/>
<property value="bootstrap" name="bootstrap.security.principal.key"/>
<property value="cn=wls-jrfServer" name="oracle.security.jps.farm.name"/>
<property value="cn=jpsTestNode" name="oracle.security.jps.ldap.root.name"/>
<property value="ldap://myHost.com:1234" name="ldap.url"/>
</serviceInstance>

次の例は、DBプロバイダ用のキーストアの構成を示しています。

<propertySet name="props.db.1">
<property name="jdbc.url" value="jdbc:oracle:thin:@host:port:sid"/>
<property name="oracle.security.jps.farm.name" value="cn=farm"/>
<property name="server.type" value="DB_ORACLE"/>
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsroot"/>
<property name="jdbc.driver" value="oracle.jdbc.OracleDriver"/>
<property name="bootstrap.security.principal.map" value="credendial_map"/>
<property name="bootstrap.security.principal.key" value="credential_key"/>
</propertySet>

<serviceInstance name="keystore.rdbms" provider="keystore.provider"            location="./default-keystore.jks">
<propertySetRef ref = "props.db.1"/>
<property name="server.type"  value="DB_ORACLE"/>
<property name="keystore.type" value="JKS"/>
<property name="keystore.csf.map" value="oracle.wsm.security"/>
<property name="keystore.pass.csf.key" value="keystore-csf-key"/>
<property name="keystore.sig.csf.key" value="sign-csf-key"/>
<property name="keystore.enc.csf.key" value="enc-csf-key"/>
</serviceInstance>

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

F.2.9 匿名ロールと認証ロールのプロパティ

表F-11に、匿名ユーザー、匿名ロールおよび認証ロールの構成に使用できるプロパティを示します。

表F-11 匿名ロールと認証ロールのプロパティ

プロパティ名

指定内容

anonymous.role.description

匿名ロールの説明。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値なし

anonymous.role.name

匿名ロールのプリンシパルの名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値: anonymous-role

anonymous.role.uniquename

匿名ロールの名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値: anonymous-role

anonymous.user.name

匿名ユーザーのプリンシパルの名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値: anonymous

authenticated.role.description

認証ロールの説明。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値なし

authenticated.role.name

認証ユーザー・ロールのプリンシパルの名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値: authenticated-role

authenticated.role.uniquename

認証ロールの名前。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト値: authenticated-role

remove.anonymous.role

ユーザーの認証後にサブジェクトから削除する匿名ロール。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

有効な値: true、false

デフォルト値: false。

関連項目:

第E.1項「スクリプトを使用したサービスの構成」

G OPSS APIリファレンス

この付録では、OPSSとともに使用されるAPIで使用可能なJavadocドキュメントを示します。

この付録の内容は次のとおりです。

- OPSS APIリファレンス

G.1 OPSS APIリファレンス

次のJavadocドキュメントには、OPSS APIの説明が記載されています。

OPSS API

Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services

MBean API

Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services Mbeans

ユーザーおよびロールAPI

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

アイデンティティ・ディレクトリAPI

Oracle Fusion Middleware Java API Reference for Identity Governance Framework Identity Directory

H OpenLDAPアイデンティティ・ストアの使用

この付録では、アイデンティティ・ストアに対してOpenLDAP 2.2をリポジトリとして使用する場合に必要な設定について説明します。

内容は次のとおりです。

- OpenLDAPアイデンティティ・ストアの使用

H.1 OpenLDAPアイデンティティ・ストアの使用

アイデンティティ・ストアにOpenLDAP 2.2を使用するには、次の手順を実行します。

1. Oracle WebLogic Server管理コンソールを使用して、新しい認証プロバイダを作成します。

- プロバイダ・リストからOpenLDAPAuthenticatorを選択します。

- OpenLDAPAuthenticatorの制御フラグをSUFFICIENTに設定します。

- WebLogic Default Authenticatorの制御フラグをSUFFICIENTに設定します。

- OpenLDAPAuthenticatorがリストの先頭になるように、順序を変更します。

- OpenLDAPAuthenticatorの「プロバイダ固有」ページで、「ユーザー・ベースDN」および「グループ・ベースDN」に入力し、「名前指定によるグループ・フィルタ」のオブジェクト・クラスの値を名前のグループ以外の値に設定します。

2. OpenLDAPをインストールするディレクトリから、次のようにします。

- 編集のためにslapd.confを開きます。

- 一番上にあるincludeセクションに次の行を挿入します。

include ./schema/inetorgperson.schema

- ファイルを保存し、OpenLDAPを再起動します。

この手順では、OpenLDAPで新しい外部ロールを作成するたびに、inetorgpersonオブジェクトがそのロールに追加されます。アプリケーション・ロールに外部ロールをマップするには、そのクラスが必要です。

I ID仮想化のためのアダプタ構成

この付録では、アイデンティティ仮想化で使用されるアダプタを構成および実装する方法と、メッセージをログに記録する方法について説明します。

この付録の内容は次のとおりです。

- 分割プロファイルについて

- 分割プロファイルの構成

- 分割プロファイルの実装

- Identity Virtualization Libraryのロギング

I.1 分割プロファイルについて

分割プロファイルとは、属性が2つ(以上)のソースに格納されるアイデンティティのことです。アイデンティティ仮想化では、分割プロファイルと、単一の問合せによる複数のLDAPディレクトリの問合せがサポートされています。したがって、アプリケーションで1つのアイデンティティについて複数のソース・ディレクトリから属性を取得する必要がある場合は、分割プロファイルとともにアイデンティティ仮想化を使用します。アダプタ構成はadapters.os_xmlファイルに格納されていますが、接続パラメータ(ホスト、ポート、資格証明など)はOPSSの構成から取得されます。

LDAP接続パラメータを構成する際、user.create.basesプロパティとgroup.create.basesプロパティがプライマリ・アダプタのネームスペースに対応している必要があります。

関連項目:

『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のOracle Virtual Directoryのアダプタの理解に関する項

『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』の結合ビュー・アダプタの理解に関する項

第8.3.1項「アイデンティティ・ストアのパラメータ」

I.2 分割プロファイルの構成

分割プロファイルを構成するには、次の手順を実行します。

1. virtualizeプロパティをtrueに設定して、複数のLDAPに対して問合せを有効にします。アイデンティティ・ストアの構成の詳細は、第8.3項「アイデンティティ・ストアの構成」を参照してください。

2. createJoinAdapter WLSTコマンドを使用して、プライマリ・アイデンティティ・ストアで結合アダプタを作成します。

createJoinAdapter(adapterName="Join Adapter Name",  root="Namespace", primaryAdapter="Primary adapter Name")

3. addJoinRule WLSTコマンドを使用して、各セカンダリ・ストアに結合ルールを追加します。

addJoinRule(adapterName="Join Adapter Name", secondary="Secondary Adapter Name", condition="Join Condition")

4. modifyLDAPAdapter WLSTコマンドを使用して、すべてのストアでアダプタを変更します。

modifyLDAPAdapter(adapterName="AuthenticatorName", attribute="Visible", value="Internal")

関連項目:

『WebLogic Server WLSTコマンド・リファレンス』のcreateJoinAdapterに関する項

『WebLogic Server WLSTコマンド・リファレンス』のaddJoinRuleに関する項

『WebLogic Server WLSTコマンド・リファレンス』のmodifyLDAPAdapterに関する項

I.3 分割プロファイルの実装

cn=users,dc=acme,dc=comユーザー・ベースを指定してMicrosoft Active Directoryがプライマリ認証プロバイダであり、cn=users,dc=oid,dc=comユーザー・ベースを指定してOracle Internet Directoryがセカンダリ・プロバイダであることを前提とします。

この2つのアダプタを使用して分割プロファイルを実装するには、次の手順を実行します。

1. プライマリ認証プロバイダで結合アダプタを作成します。

createJoinAdapter(adapterName="JoinAdapter1", root="dc=acme,dc=com", primaryAdapter="AD")

2. セカンダリ認証プロバイダに作成した結合アダプタを追加します。

addJoinRule(adapterName="JoinAdapter1", secondary="OID", condition="uid=cn")

uid=cnは、ユーザーのuidの値がMicrosoft Active Directoryのcnの値と一致した場合に、属性が組み合されることを示しています。

等号記号の左側の属性がセカンダリ・アダプタの属性で、右側の属性がプライマリ・アダプタの属性です。

3. すべてのアダプタの表示を変更するには、次のようにします。

modifyLDAPAdapter(adapterName="OID", attribute="Visible", value="Internal")
modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Internal")

4. Oracle WebLogic Serverを再起動します。

関連項目:

『WebLogic Server WLSTコマンド・リファレンス』のcreateJoinAdapterに関する項

『WebLogic Server WLSTコマンド・リファレンス』のaddJoinRuleに関する項

『WebLogic Server WLSTコマンド・リファレンス』のmodifyLDAPAdapterに関する項

I.4 Identity Virtualization Libraryのロギング

Identity Virtualization Libraryのロギングを有効にするには、次の手順を実行します。

1. すでに構成されたIdentity Virtualization Libraryロガーをすべて削除します。

2. NOTIFICATIONレベルでoracle.ods.virtualization.accesslogという名前の新しいロガーを作成します。

3. ハンドラを作成し、ロガーに関連付けられたファイル(すべてのメッセージが記録されます)を指定します。

4. auditLogPublisherをDOMAIN_HOME/config/fmwconfig/ovd/default/provider.os_xmlファイルに追加します。

<providers>
...
<auditLogPublisher>
<provider name="FMWAuditLogPublisher"></provider>
<provider name="AccessLogPublisher">
<configClass>oracle.ods.virtualization.config.AccessLogPublisherConfig</configClass>
<properties>
<property name="enabled" value="true"/>
</properties>
</provider>
</auditLogPublisher>
...
</providers>

5. WebLogic Serverを再起動します。

J OPSSのトラブルシューティング

この付録では、OPSSの構成および使用時に発生する可能性のある一般的な問題と、その解決方法について説明します。

次の項が含まれます:

- OPSS診断フレームワーク

- セキュリティ・エラーの診断

- 再関連付けおよび移行のトラブルシューティング

- サーバーの起動のトラブルシューティング

- パーミッションのトラブルシューティング

- 接続およびアクセスのトラブルシューティング

- Oracle Business Intelligence Publisherのタイムゾーン

- 検索のトラブルシューティング

- バージョンのトラブルシューティング

- その他のエラーのトラブルシューティング

- 追加のヘルプ

J.1 OPSS診断フレームワーク

OPSSには、問題の解決時間を短縮できるよう支援するフレームワークが組み込まれています。このフレームワークでは、ドメインの内部状態を抽出し、その情報をファイルにダンプできます。フレームワークには、そのドメイン内のドメイン・サーバーおよびドメイン・サービスの特性を記録するダンプを生成するためのテストが多数用意されています。

OPSS診断フレームワークに用意されているテストは次のとおりです。

- 構成テスト

- oracle.security.jps.diag.test.JpsConfigTest

- 接続テスト

- oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTest

- oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiLdapConnectivityTest

- 資格証明ストア・テスト

- oracle.security.jps.diag.test.JpsCredentialStoreConfigTest

- oracle.security.jps.diag.test.JpsCredentialStoreTest

- アイデンティティ・ストア・テスト

- oracle.security.jps.diag.test.JpsIdentityStoreIDSSearchTest

- oracle.security.jps.diag.test.JpsIdentityStoreLibOvdConfigTest

- oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiSearchTest

- キーストア・テスト

- oracle.security.jps.diag.test.JpsKeyStoreTest

- oracle.security.jps.diag.test.JpsKeyStoreConfigTest

テストの実行

テストをコールするには、次の構文でexecuteDumpコマンドを使用します。

executeDump(name='opss.diagTest', outputFile='dumpLocation', args={'testtname':'testName'})

説明:

- 最初の引数name='opss.diagTest'は変更できません。

- outputFileでは、ダンプの生成場所を、コマンドが実行される場所を基準とした相対パスで指定します。

- 3つ目の引数の文字列はすべて決まっていますが、testName文字列は例外で、テストの1つを設定します。ワイルドカード(*)を使用すると、すべてのテストが次の順序で実行されます。

oracle.security.jps.diag.test.JpsConfigTest
oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTest
oracle.security.jps.diag.test.JpsCredentialStoreConfigTest
oracle.security.jps.diag.test.JpsCredentialStoreTest
oracle.security.jps.diag.test.JpsIdentityStoreIDSSearchTest
oracle.security.jps.diag.test.JpsIdentityStoreLibOvdConfigTest
oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiLdapConnectivityTest
oracle.security.jps.diag.test.JpsIdentityStoreUserRoleApiSearchTest
oracle.security.jps.diag.test.JpsKeyStoreConfigTest
oracle.security.jps.diag.test.JpsKeyStoreTest

使用例

診断フレームワークを使用する状況の流れは、次のとおりです。

1. 顧客から問題を受け取ります。

2. ログに記録された障害から、問題が(たとえば)接続に関係していると判断します。

3. 問題になっているドメインで、oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTestなど、テストを1つ以上実行します。

1. Oracle WebLogic Serverに接続します。

wls:/offline> connect('adminuser', 'adminpass', 't3://localhost:7001')

2. 次のように、テストをコールします。

>executeDump(name='opss.diagTest', outputFile='myDumpTest',
args={'testname': 'oracle.security.jps.diag.test.JpsContainerAuthenticationLdapConnectivityTest'})

4. テストにより、指定の場所にダンプが生成されます。ダンプに、次の行が含まれています。

LDAP authenticator : OID
host : myHost.com
port : 7066
principal : cn=orcladmin
password : ********
Is SSL? false
Testing LDAP connection to ldap://myHost.com:7066 with principal cn=orcladmin.
JNDI settings:
java.naming.provider.url = ldap://myHost.com:7066
java.naming.factory.initial = com.sun.jndi.ldap.LdapCtxFactory
com.sun.jndi.ldap.connect.timeout = 5000
java.naming.security.principal = cn=orcladmin
java.naming.security.authentication = simple
java.naming.security.credentials = ********
Failed to establish LDAP connection to ldap://myHost.com:7066.
The stack trace:
javax.naming.CommunicationException: myHost.com:7066 [Root exception is java.net.ConnectException: Connection refused]
at com.sun.jndi.ldap.Connection.<init>(Connection.java:214) …

5. エラーおよび障害がないかダンプを調べます。この例では、太字のテキストはLDAPプロバイダへの接続を確立できなかったことを示しています。

J.2 セキュリティ・エラーの診断

OPSS診断フレームワークに加えて、次の各項で説明しているように、ロガーを使用して様々なセキュリティ問題を診断して解決します。

- OPSSロガーについて

- サービス別のロガー

- システム・プロパティ

- ログ・エントリの理解

関連項目:

OPSS診断フレームワーク

J.2.1 OPSSロガーについて

次の各項では、OPSSでサポートされているログ・ファイルとロガーを紹介し、Fusion Middleware ControlおよびWebLogic Scripting Tool (WLST)を使用して、ロガー・レベルを構成および設定する方法と、ログ・ファイルを表示する方法について説明します。

- 診断ログ・ファイル

- オフラインWLSTロガー

J.2.1.1 診断ログ・ファイル

ドメイン内の各サーバー・インスタンスは、アプリケーションで発生したOPSS例外をすべて、ローカル・ホスト・コンピュータのファイル・システムにあるサーバー・ログ・ファイルに書き込みます。

デフォルトでは、このログ・ファイルは、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName-diagnostic.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。

サーバーは、セキュリティ関連のエラーを診断ファイルに書き込みます。サーバー関連のセキュリティ・エラー(サブジェクトやプリンシパルの問題で発生した例外など)やドメイン・セキュリティ・データの移行または再関連付けのときに発生するエラーは、管理サーバー診断ログに書き込まれます。アプリケーション関連のセキュリティ・エラー(アプリケーション固有のポリシーまたは資格証明で発生した例外など)は、アプリケーションが実行されている管理対象サーバーの診断ログに書き込まれます。

デフォルトでは、サーバー・ログ・ファイルは、診断ログ・ファイルと同様に、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。ドメイン・ログ・ファイルは、管理サーバー・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName.logxxxxxおよびdomain.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。

ドメイン・ログは、サーバー・ログのメッセージと一部重複しており、多数のサーバーで構成されたドメインで障害が発生したサーバーを特定するのに役立ちます。

新しいログ・ファイルの生成は、ファイル・サイズによって決まります。ログ・ファイルが指定されたサイズを超えると、整数の接尾辞が1つ増えた名前を持つ、新しいログ・ファイルが生成されます。

関連項目:

『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタリング』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する項

Oracle WebLogic Server診断フレームワークの構成と使用

Oracle WebLogic ServerにデプロイされたアプリケーションへのWebLogicロギング・サービスの追加

『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」

J.2.1.2 オフラインWLSTロガー

オンラインWLSTコマンドの場合、ロギングは自動ですが、オフライン・コマンドの場合は自動ではありません。migrateSecurityStoreコマンドなどのオフライン・コマンドの使用時には、次のシステム・プロパティを指定してJava仮想マシン(JVM)を起動することにより、ロギングを有効にします。

- wlst.offiline.log: <filename>、stdout、sterrまたはdisableのいずれかの値を指定します。指定しない場合、ログ・ファイルは$MW_HOME/logsディレクトリに置かれます。

- wlst.offline.log.priority: OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL、debug、info、warn、error、fatalのいずれかの値を指定します。

J.2.2 サービス別のロガー

次の各項では、サービスごとに使用可能なロガーを示します。

- 認可のロギング

- 監査のロギング

- ユーザーおよびロールAPIのロギング

- その他のコンポーネントのロギング

J.2.2.1 認可のロギング

サーバーを停止して再起動しなくても、ロガーを有効および無効にできます。通常、ロガーのレベルはTRACE:32に設定します。

OPSSでは、実行時の認可の失敗をトラブルシューティングするのに役立つロガーがいくつか用意されています。

- oracle.security.jps.util.JpsAuth - checkPermissionの起動とリターンをログに記録します。

- oracle.security.jps.trace.logger - アプリケーション・ロール、パーミッション、ターゲット、プリンシパルおよび付与されたポリシーと拒否されたポリシーに関する情報をログに記録します。このロガーは、大規模な出力を生成します。単一のユースケースのデバッグにのみ使用します。

- oracle.jps.authorization - 実行時の認可中のメッセージをログに記録します。

- oracle.jps.common - サービス管理やユーザー管理など、OPSS共通機能領域でのメッセージをログに記録します。

- oracle.security.jps.dbg.logger - JpsFilterフィルタ・パーミッション・チェックのデバッグに使用されるメッセージをログに記録します。

- oracle.security.jps.az.internal.runtime.policy.AbstractPolicyImpl - oracle.security.jps.az.internal.runtime.policy.AbstractPolicyImplクラスのメッセージをログに記録します。

- oracle.security.jps.internal.policystore.JavaPolicyProvider - oracle.security.jps.internal.policystore.JavaPolicyProviderクラスのメッセージをログに記録します。

J.2.2.2 監査のロギング

この項では、監査ログ・メッセージを解釈する方法と、それらのメッセージを使用してコンポーネントの障害を診断する方法について説明します。ログ・ファイルの場所は次のとおりです。

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

表J-1に、使用可能な診断ログ・ファイルを示します。

表J-1 監査診断のログ・ファイル

コンポーネント

ログの保存場所

ロガーの構成

Java EEコンポーネント

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

OPMNコンポーネント

第J.2.2.2項を参照してください。

第J.2.2.2項を参照してください。

起動クラス監査ローダー

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

OPMN監査ローダー

$ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.out

java.util.logging.config.fileシステム・プロパティを、OPMN監査ローダーのログ・レベルを含むファイルに設定できます。

構成/プロキシMbeans

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

監査スキーマ・サポート

Oracle Fusion Middlewareリポジトリ作成ユーティリティのログの場所(デフォルトでは$ORACLE_HOME/rcu/log/)。RCU_LOG_LOCATIONを設定すると、この場所を変更できます。

リポジトリ作成ユーティリティのログ・レベル。デフォルトは、ERRORです。

監査ロガーの構成

Fusion Middleware Controlを使用して、oracle.security.audit.loggerロガーを構成し、ロガーを表示します。ログ・ファイルの詳細は、『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」を参照してください。

監査エラー・メッセージには、IAU-XXXという番号が付けられます。

OPMNで管理されるシステム・コンポーネントの監査ロギングを構成するには、auditconfig.xmlファイルを編集して、コンポーネントの監査ログが書き込まれるログ・ディレクトリの場所を指定します。

<LogsDirectory>
<MaxFileSize></MaxFileSize>
<Location>/tmp/audit/auditlogs</Location>
</LogsDirectory>

J.2.2.3 ユーザーおよびロールAPIのロギング

OPSSのユーザーおよびロールAPIコールを追跡するには、oracle.idm.userroleapiロガーをTRACE:32に設定します。

J.2.2.4 その他のコンポーネントのロギング

加えて、OPSSには次のロガーも用意されています。

oracle.jps.deploymentは、アプリケーションのデプロイ時に、アプリケーションとともにパックされたOPSSアーティファクトに関する問題をログに記録します。

oracle.jps.openazは、PEP APIコールに関する問題をログに記録します。oracle.jps.openaz.levelをFINESTに設定すると、送信されたリクエストに関する情報(アイデンティティ、リソース、アクション、コンテキスト)および認可結果が記録されます。

oracle.jps.attributeは、OPSS属性サービスに関する問題をログに記録します。

J.2.3 システム・プロパティ

次のプロパティを使用して、サーバー起動時のデバッグを構成します。

- jps.auth.debug: 失敗したパーミッション・チェックのみをログに記録します。パーミッション・チェックのメッセージを無効にするには、このプロパティをfalseに設定します。デフォルトは、trueです。

- jps.auth.debug.verbose: 失敗したパーミッション・チェックをログに記録します。jps.auth.debubよりも多くの情報をログに記録します。デフォルトは、falseです。

- DebugOPSSPolicyLoading: ポリシー・プロバイダの進行状況と設定を監視するフラグ。

- java.security.debug=policy: ファイル・システムでの場所、付与するパーミッション、使用する証明書など、解析したとおりにポリシー・ファイルに関する印刷情報を生成する、標準のJavaセキュリティ・デバッグ・フラグ。

setDomainEnv.shスクリプトを編集し、必要なプロパティをシステム・プロパティEXTRA_JAVA_PROPERTIESに追加します。この変更には、サーバーの再起動が必要です。

注意:
ロギング出力を高く設定すると、特にファイルのロード時に、スレッドがスタックする可能性があります。この状況を回避するには、WebLogic Serverでスレッドをスタックとマークするために使用するタイムアウト値を、さらに高い値に変更します。

その他のシステム・プロパティ

デバッグに役立つその他のシステム・プロパティは、次のとおりです。

- oracle.security.jps.log.for.approle.substring: 指定した部分文字列が含まれるアプリケーション・ロールの名前をログに記録します。照合する部分文字列を指定しないと、すべてのアプリケーション・ロール名がログに記録されます。

- oracle.security.jps.log.for.permeffect: 付与または拒否された権限をログに記録します。値を指定しないと、(付与または拒否にかかわらず)すべての権限がログに記録されます。

- oracle.security.jps.log.for.permclassname: 指定した名前に完全一致するパーミッション・クラスの名前をログに記録します。照合する名前を指定しないと、すべてのパーミッション・クラス名がログに記録されます。

- oracle.security.jps.log.for.permtarget.substring: 指定した部分文字列が含まれるパーミッション・ターゲットの名前をログに記録します。照合する部分文字列を指定しないと、すべてのパーミッション・ターゲットがログに記録されます。

- oracle.security.jps.log.for.enterprise.principalname: 指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)の名前をログに記録します。照合する名前を指定しないと、すべてのプリンシパル名がログに記録されます。

使用例

次の例では、システム・プロパティの一般的な設定を示します。

- 文字列myAppRoleが含まれるすべてのアプリケーション・ロール名をログに記録するには、次のようにします。

-Doracle.security.jps.log.for.approle.substring=myAppRole

- 拒否されたすべてのパーミッション・チェックをログに記録するには、次のようにします。

-Doracle.security.jps.log.for.permeffect=deny

- 付与されたすべてのパーミッション・チェックをログに記録するには、次のようにします。

-Doracle.security.jps.log.for.permeffect=grant

- 付与されたか、または拒否されたすべてのパーミッション・チェックをログに記録するには、oracle.security.jps.log.for.permeffectは設定しません。

- java.util.PropertyPermissionに完全一致するすべてのパーミッション・チェックをログに記録するには、次のようにします。

-Doracle.security.jps.log.for.permclassname=java.util.PropertyPermission

- 文字列p.monが含まれるすべてのターゲット名をログに記録するには、次のようにします。

-Doracle.security.jps.log.for.permtarget.substring=p.mon

- プリンシパル名managerに関連するすべての認可をログに記録するには、次のようにします。

-Doracle.security.jps.log.for.enterprise.principalname=manager

- 部分文字列に一致するアプリケーション・ロール名または文字列に一致するプリンシパル名をログに記録するには、oracle.security.jps.log.for.approle.substringとoracle.security.jps.log.for.enterprise.principalnameの両方を使用します。

J.2.4 ログ・エントリの理解

エラーを分離して解決するには、ログ・エラーを理解することが重要です。この項では、次のような診断ログ・ファイルの内容を解釈する方法について説明します。

[2009-01-07T09:15:02.393-08:00] [AdminServer] [ERROR] [JPS-00004] [oracle.jps.admin]
[tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'] [userId: weblogic] [ecid: 0000Hum5kxw7MAn54nU4Ui19PD8S000005,0]
Unable to add principal to the application role. Reason: Principal
"abc.xxx@myComp.com" is already a member of the application role
"BPMWorkflowAdmin"[[
java.security.PrivilegedActionException:
oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException:
Unable to add principal to the application role. Reason: Principal "abc.xxx@myComp.com" is already a member of the application role
"BPMWorkflowAdmin"
at java.security.AccessController.doPrivileged(Native Method)
at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl.
addRemoveMembersToRole(JpsApplicationPolicyStoreImpl.java:408)
at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl.
addMembersToApplicationRole(JpsApplicationPolicyStoreImpl.java:385)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

前述のメッセージの各フィールドの意味は、次のとおりです。

- [2009-01-07T09:15:02.393-08:00]
エラーがログに記録された日時を識別します。

- [AdminServer]
エラーが発生したサーバーの名前を識別します。

- [JPS-00004]
エラー・コードを識別し、発生したエラーの種類に関するヒントを示します。すべてのJPSエラー・コードのリストについては、エラー・メッセージの第41章を参照してください。

- [oracle.jps.admin]
ロガー・カテゴリを識別します。oracle.jpsのサブカテゴリ(adminなど)は、発生したエラーの種類を示します。これには次の機能が含まれます。

- common - 一般的なエラー

- upgrade - アップグレード・エラー

- config - 構成エラー

- deployment - デプロイ・エラー

- authentication - ログイン・モジュール・エラー(Java SEアプリケーションのみ)

- idmgmt - アイデンティティ・ストア・エラー。

- credstore - 資格証明ストア・エラー。

- authorization - 実行時のポリシー・ストア・エラー

- policymgmt - ポリシー・ストア管理エラー。

- admin - JMXエラーおよびWLSTエラー。

- [tid: [ACTIVE].ExecuteThread: '3' for queue: 'weblogic.kernel.Default (self-tuning)']
エラーが発生したスレッドを識別します。

- [userId: weblogic]
エラーを生成した操作を実行したユーザーを識別します。

- [ecid: 0000Hum5kxw7MAn54nU4Ui19PD8S000005,0]
実行コンテキストIDを識別します。イベントの順序を相互に関連付けて追跡します。実行コンテキストID (ECID)は、リクエストからWebLogic ServerやOIDサーバーへなど、プロセスをまたがるフローに関する情報を提供します。

- Unable to add principal to the application role. Reason: Principal abc.xxx@myComp.com is already a member of the application role BPMWorkflowAdmin
エラーがログに記録された理由を識別します。

- java.security.PrivilegedActionException: oracle.security.jps.service.policystore.PolicyObjectAlreadyExistsException: Unable to add principal to the application role. Reason: Principal abc.xxx@myComp.com is already a member of the application role BPMWorkflowAdmin
発生した例外とその理由を識別します。

J.3 再関連付けおよび移行のトラブルシューティング

次の各項では、データベース・セキュリティ操作の問題について説明します。

- 再関連付けの失敗

- 移行の失敗

- サポートされていないスキーマ

- 再関連付けしたセキュリティ・ストアのポリシーの欠落

J.3.1 再関連付けの失敗

この項では、ファイルからLDAPストアへの再関連付けに失敗する3つの理由について説明します。

現象1- エラー・コード32

再関連付けが失敗し、次のようなエラーがMyServerName.diagnostic.logファイルに記録されます。

[LDAP: error code 32 - No Such Object]
Authentication to LDAP server ldap://myServer.com:3060 is unsuccessful.

診断1

このエラーは、指定されたノードがLDAPサーバーに存在しないことを意味しています。

ストアの再関連付けを開始する前に、指定したルート・ノードがLDAPに存在する必要があります。

解決策1

「JPSルートDN」テキスト・フィールドに入力したデータが、ターゲットLDAPディレクトリのノードの名前に一致することを確認してから、再関連付けを再実行します。

現象2- エラー・コード68

再関連付けが失敗し、次のようなエラーがserverName.diagnostic.logファイルに記録されます。

Authentication to LDAP server ldap://myServer.com:3060 is successful.
Starting to migrate policy store...
Set up security provider reassociation successfully.
Checked and seeded security store schema successfully.
null
[LDAP: error code 68 - Object already exists]:cn=SystemPolicy,cn=domain1,cn=JPSContext,cn=nb_policy
Error occurred while migrating LDAP based policy store.

診断2

このエラーは、「WebLogicドメイン名」テキスト・フィールドに指定した名前がターゲットLDAPディレクトリの「JPSルートDN」ノードの孫であることを示しています。

cnはルート・ノードの子孫ではない必要があります。

解決策2

「WebLogicドメイン名」テキスト・フィールドに入力した名前が、指定した「JPSルートDN」ノードの子孫の名前に一致していないことを確認してから、再関連付けを再実行します。

現象3

Fusion Middleware Controlを使用して実行された再関連付けが失敗し、次のようなエラーがserverName.diagnostic.logファイルに記録されます。

[2009-01-21T10:09:24.326-08:00] [AdminServer] [ERROR] [] [oracle.jps.admin] [tid
: [ACTIVE].ExecuteThread: '15' for queue: 'weblogic.kernel.Default (self-tuning)
'] [userId: weblogic] [ecid: 0000HvuOTpe7q2T6uBADUH19Tpyb000006,0] Unable to rem
ove the principal from the application role. Reason: Principal "Managers" is not
a member of the application role "test-role"[[
java.security.PrivilegedActionException: oracle.security.jps.service.policystore
.PolicyObjectNotFoundException: Unable to remove the principal from the applicat
ion role. Reason: Principal "Managers" is not a member of the application role "
test-role"
at oracle.security.jps.mas.mgmt.jmx.policy.JpsApplicationPolicyStoreImpl
.addRemoveMembersToRole(JpsApplicationPolicyStoreImpl.java:408)...

診断3

このエラーは、test-roleアプリケーション・ロールに関連するなんらかの問題を示しています。

データを入力し、Fusion Middleware Controlを使用して再関連付けを実行する際、必ずターゲットLDAPサーバーに接続するために必要なすべての値の入力が完了した直後に、「LDAP認証のテスト」ボタンを使用します。このテストにより、再関連付けが開始される前に、これらの値を使用したときに発生する可能性のある問題を見つけることができます。

解決策3

この例では、system-jazn-data.xmlを迅速に検査した結果、test-roleロールがポリシーで使用されているのに、定義されていないことが明らかになりました。次の例では、必要なデータが欠落している場合を示します。

<application>
<name>myApp</name>
<app-roles>
<--! test-role should have been defined here -->
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>test-role</name>
<guid>66368900E7E511DD9F62F9ADA4233FE2</guid>
</principal>
</principals>...

このエラーを解決するには、(a) アプリケーションtest-roleの定義を挿入してsystem-jazn-data.xmlを修正し、(b) 修正したファイルを使用してファイル・ストアに戻り、(c) 再関連付けを再実行します。

現象4 - 監査ストアが再関連付けされていない

この注意が該当するのはリリース11.1.1.6.0です。Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)を使用した再関連付けが正常に完了しても、ターゲット・ストアに監査ストアは表示されません。これは、このリリースでは、reassociateSecurityStore WLSTコマンドを使用してのみ監査ストアの再関連付けができるためです。

解決策4

元の環境で、reassociateSecurityStoreコマンドを異なるjpsrootノードで実行します。これによって、LDAPディレクトリ間の再関連付けが行われ、データ(監査データを含む)が新しいノードに移行されます。

J.3.2 サポートされていないスキーマ

この項では、LDAPサーバーへの再関連付けに失敗する理由について説明します。

現象

LDAPリポジトリへのセキュリティ・ストアの再関連付けに失敗すると、管理サーバー・ログに次のようなエラーがレポートされます。

[2011-02-09T07:01:13.884-05:00] [AdminServer] [ERROR] [] [oracle.jps.admin] [tid: [ACTIVE].ExecuteThread: '6' for queue: 'weblogic.kernel.Default (self-tuning)'] [userId: weblogic] [ecid: 41050d66ef2ec40b:-4c1fb689:12e06cc7b6c:-8000-00000000000001e1,0] Schema seeding failed, check the server type of the given ldap url.[[
oracle.security.jps.JpsException: Error Modifying JPS Schema,  Record: dn: cn=schema
changetype: modify
delete: objectclasses
objectclasses: ( 2.16.840.1.113894.7.2.2 NAME 'orclContainer' SUP ( top ) MUS
T ( cn ) MAY ( orclVersion $ orclServiceType ) )
-
: [LDAP: error code 32 - No Such Object]:cn=schema

診断

このエラーは、ターゲットLDAPリポジトリのスキーマがサポートされていないことを示しています。

解決策

ターゲットLDAPリポジトリをサポートされているものに更新して、再関連付けを再試行します。Oracle Internet Directoryのバージョンは10.1.4.3以上である必要があります。サポートされているバージョンのリストは、第9.2項「LDAPセキュリティ・ストアの使用」を参照してください。

J.3.3 再関連付けしたセキュリティ・ストアのポリシーの欠落

現象

ファイル・ストアをLDAPストアに正常に再関連付けしたのに、コードソース・ポリシーがターゲット・ストアに存在しません。

診断

実行時に、サーバーは次のようなスタック・トレースをレポートします。

<BEA-000000> <JspServlet: initialization complete>
####<May 4, 2009 8:32:50 AM PDT> <Error> <HTTP> <ap626atg> <WLS_Spaces>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <> <> <1241451170341> <BEA-101020>
<[ServletContext@20193148[app:webcenter module:/webcenter path:/webcenter
spec-version:2.5]] Servlet failed with Exception
java.security.AccessControlException: access denied
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:348)
at
oracle.security.jps.util.JpsAuth$Diagnostic.checkPermission(JpsAuth.java:268)
at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$6.checkPermission(JpsAuth.java:372)
at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:408)
at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:431)
at
oracle.security.jps.internal.policystore.AbstractPolicyStore.checkPolicyStoreAccessPermission(AbstractPolicyStore.java:246)
at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.getApplicationPolicy(LdapPolicyStore.java:281)
at
oracle.security.jps.internal.policystore.PolicyUtil.getGrantedAppRoles(PolicyUtil.java:898)
at
oracle.security.jps.internal.policystore.PolicyUtil.getJpsAppRoles(PolicyUtil.java:1354)
at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:273)
at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:270)
at java.security.AccessController.doPrivileged(Native Method)

パーミッションは次のとおりです。

oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy

コードソースに付与され、falseと評価されたために認可できません。

解決策

管理サーバー・ログに、再関連付けの際にスキーマがシードされなかったことを示す、次のようなメッセージがないか確認します。

AdminServer-diagnostic.log:[2009-05-28T02:27:52.249-07:00] [AdminServer] [NOTIFICATION] [JPS-00072] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Policy schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0
AdminServer-diagnostic.log:[2009-05-28T02:28:58.012-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Credential store schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0

再関連付けの際にスキーマがシードされるようにするには、次のようにします。

1. LDAPのcn=OracleSchemaVersionコンテナの下にあるcn=OPSSコンテナを削除します。

2. ファイル・ポリシー・ストアの正常に動作しているインスタンスを起動します。

3. ファイル・ストアをターゲットLDAPストアに再関連付けします。

管理サーバー・ログで、次のようなメッセージを検索してOPSSスキーマがLDAPサーバーでシードされたことを確認します。

AdminServer-diagnostic.log:[2009-05-29T07:18:18.002-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-12] [ecid: 0000I61Z0MH0fplp4sm3Ui1A7_Ll00002s,1:5001] [arg: 11.1.1.0.0]  Policy schema version set to 11.1.1.0.0

リリース11g Oracle Internet Directoryサーバーに再関連付けした場合、スキーマのバージョンは11.1.1.1.0になります。

リリース10.1.4.3 Oracle Internet Directoryサーバーに再関連付けした場合、スキーマのバージョンは11.1.1.0.0になります。

ポリシー・ストアのバージョンは、LDAPの次のコンテナの下に設定されます。

cn=PolicyStore,cn=OPSS,cn=OracleSchemaVersion

資格証明ストアのバージョンは、LDAPの次のコンテナの下に設定されます。

cn=CredentialStore,cn=OPSS,cn=OracleSchemaVersion

J.3.4 移行の失敗

この項では、アプリケーションのデプロイ時にポリシーの移行が失敗する理由について説明します。アプリケーションのデプロイは、移行に失敗しても、成功する場合があることに注意してください。バージョンの問題の詳細は、「セキュリティ・ストアのバージョンの非互換性」も参照してください。

現象

デプロイ時にポリシーを移行するようにアプリケーションを構成しました。アプリケーションのデプロイには成功しますが、サーバーの診断ファイルに次のようなメッセージが出力されます。

[2009-01-21T13:34:48.144-08:00] [server_soa] [NOTIFICATION] []
[oracle.jps.deployment] [tid: [ACTIVE].ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic]
[ecid: 0000Hvv7U_H7q2T6uBADUH19Tq0B00002I,0] [APP: JpsJdev#V2.0]
Application [JpsJdev#V2.0] is being deployed, start policy migration.

[2009-01-21T13:34:48.770-08:00] [server_soa] [WARNING] []
[oracle.jps.deployment] [tid: [ACTIVE].ExecuteThread: '2' for queue:
'weblogic.kernel.Default (self-tuning)'] [userId: weblogic]
[ecid: 0000Hvv7U_H7q2T6uBADUH19Tq0B00002I,0] [APP: JpsJdev#V2.0]
Exception in application policy migration.[[
oracle.security.jps.JpsException: appplication Role:
test_role not found for the application in the destination policy store
at oracle.utility.destination.apibased.JpsDstPolicy.convertAppPolicyPrincipal
(JpsDstPolicy.java:815)
at oracle.utility.destination.apibased.JpsDstPolicy.clone
(JpsDstPolicy.java:691)...

この例では、JpsJdevアプリケーションがserver_soa管理対象サーバーにデプロイされました。このようなエラーを探すために検索するキー・フレーズが、出力例で強調表示されています。さらに、このエラーには、例外を引き起こしたアーティファクトであるtest_roleアプリケーション・ロールが記載されています。

診断

jazn-data.xmlを確認すると、granteeでtest_roleロールが参照されていることがわかります。

<grantee>
<display-name>myPolicy</display-name>
<principals>
<principal>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<name>test_role</name>
</principal>
</principals>
</grantee> ...

しかし、名前がtest_rolleとスペルミスされています。

<application>
<name>JpsJdev</name>
<app-roles>
<app-role>
<name>test_rolle</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members> ...

解決策

アプリケーション・ポリシーで参照されているアプリケーション・ロールがすべて定義されていることを確認します。参照されたロール名が一致しない場合、移行は失敗します。

J.4 サーバーの起動のトラブルシューティング

この項では、次の各項でOracle WebLogic Serverの起動に失敗する理由をいくつか説明します。

- 必須のLDAP認証プロバイダの欠落

- 管理者アカウントの欠落

- パーミッションの欠落

- サーバーの起動の失敗

- サーバーの起動に関するその他の問題

- サーバーの起動前のパーミッション・チェックの失敗

J.4.1 必須のLDAP認証プロバイダの欠落

この項では、ドメイン内の認証プロバイダのリストを変更した後に、WebLogic Serverの起動に失敗する理由について説明します。

現象

ドメイン内のプロバイダのリストを変更すると、WebLogic Serverの起動に失敗し、エラー・メッセージは次のような内容になります。

java.lang.IllegalArgumentException: null KeyStore name

診断

この問題の原因の1つは、ドメイン内のリストにLDAPプロバイダが含まれていないことです。OPSSを使用するすべてのドメインで、このリストにはLDAPプロバイダが必須です。

解決策

プロバイダを追加するには、次の手順を実行します。

1. DOMAIN_NAME/config/config.xmlを開きます。

2. <realm>要素内にLDAPプロバイダが含まれるように編集します。

<realm>
...
<sec:authentication-provider xsi:type="wls:default-authenticatorType">
</sec:authentication-provider>
...
</realm>

3. サーバーを再起動します。

サーバーが稼働したら、Oracle WebLogic Server管理コンソールを使用して、希望のプロバイダが含まれるようにプロバイダのリストを変更し、必ずそれらの少なくとも1つをLDAP認証プロバイダにします。

WebLogic Server管理コンソールを使用して、次の手順を実行します。

1. 「新しい認証プロバイダの作成」ページに移動します。

2. 名前を入力して、タイプを選択します。

- ActiveDirectoryAuthenticator

- WebLogic Default Authenticator (例では、これは手動で挿入したものです)

- LDAPAuthenticator

- LDAPX509IdentityAsserter

- OpenLDAPAuthenticator

- OracleInternetDirectoryAuthenticator

- OracleVirtualDirectoryAuthenticator

J.4.2 管理者アカウントの欠落

この項では、WebLogic Serverの起動に失敗する理由について説明します。

現象

構成済の認証プロバイダを削除してOID認証プロバイダを追加すると、サーバーの起動に失敗します。

診断

追加したプロバイダにAdministratorsグループのアカウント・メンバーを入力することを忘れた可能性が高いと考えられます。サーバーでは、1つの認証プロバイダにこのようなアカウントが存在する必要があります。このアカウントは、デフォルトの認証プロバイダに常に存在します。

解決策

削除したLDAPプロバイダを手動で追加します。

1. DOMAIN_NAME/config/config.xmlを開きます。

2. <realm>要素内にデフォルトのプロバイダが含まれるように編集します。

<realm>
...
<sec:authentication-provider xsi:type="wls:default-authenticatorType">
</sec:authentication-provider>
...
</realm>

3. サーバーを再起動します。

サーバーが稼働したら、次の手順を実行します。

1. Administratorsグループのメンバーにアカウントを作成します。

2. フラグをSUFFICIENTに設定します。

3. サーバーを再起動します(デフォルトのプロバイダに指定されたAdministratorsグループのアカウントを使用しているため、問題なく起動するはずです)。

4. フラグをREQUIREDにリセットして、デフォルトのプロバイダを削除します。これで、サーバーは作成したAdministratorsグループのアカウントを使用して起動します。

J.4.3 パーミッションの欠落

この項では、WebLogic Serverの起動に失敗する理由について説明します。

現象

システム・プロパティ-Djava.security.managerを使用して、セキュリティ・マネージャを有効にした状態でサーバーを起動しようとすると、起動に失敗します。

診断

サーバー起動時にセキュリティ・マネージャを有効にする際、oraclepki.jarの公開鍵メソッドへのアクセスを許可する権限付与が見つかりません。

解決策

weblogic.policyファイルに次のような権限付与が存在することを確認し、存在しない場合は追加します。

grant codeBase "file:${oracle.home}/modules/oracle.pki_${opss.version}/*" {
permission java.security.AllPermission;
};

デフォルトでは、この権限付与が指定されています。セキュリティ・マネージャを有効にする際、すべてのシステム・リソースへのアクセスに、コードソース・パーミッションの権限付与が必要であることに注意してください。

WebLogicリソースを保護するためのJava Security Managerの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。

J.4.4 サーバーの起動の失敗

この項では、WebLogic Serverの起動に失敗する2つの理由について説明します。

現象1

${domain.home}/config/fmwconfigドメイン・ディレクトリはNFSマウントされたパーティション上にあり、サーバーの起動時に次のようなエラー・メッセージがログに記録されます。

JPS-01050: Opening of wallet based credential store failed. Reason
java.io.IOException: PKI-02002: Unable to open the wallet. Check password.

さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、次のメッセージがログに記録されます。

java.io.IOException: No locks available.

診断1

OPSSではファイル・ストアでセキュリティ・データを管理するためにファイルのロックが必要であるため、エラー・メッセージNo locks availableはドメイン・ディレクトリがNFSマウントされているファイル・システムでファイルのロックがサポートされていないことを示しています。

解決策1

次の手順のいずれかを実行して、サーバーを再起動します。

- NFS v3からNFS v4にアップグレードします。

- nolockオプションを有効にしてリモート・ファイル・システムをマウントします。

- ${domain.home}/config/fmwconfig内のファイルをローカル記憶域に移動します。

現象2

資格証明操作に例外が発生したため、サーバーの起動は失敗します。さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、ファイル・パーミッション・エラーがログに記録されます。

診断2

資格証明操作では、/tmpディレクトリに一時ファイルを作成して使用します。パターン/tmp/*pki*と一致するファイルはすべて、サーバーを起動したユーザーが所有する必要があります。ファイル・パーミッション・エラー・メッセージは、そのパターンと一致するファイルの一部が適切なユーザーにより所有されていないことを示しています。

解決策2

サーバーを起動しているユーザーが所有していないパターン/tmp/*pki*と一致するファイルをすべて削除し、サーバーを再起動します。

現象3

この現象は現象2と同様ですが、解決策が異なります。資格証明操作に例外が発生したため、サーバーの起動は失敗します。さらに、orapkiデバッグをオンにしてサーバーを再度起動すると、ファイル・パーミッション・エラーがログに記録されます。

診断3

サーバーの起動は、ドメインをインストールしたユーザーと同じOSユーザーにより実行される必要があります。インストーラが属するOSグループのメンバーでも、別のメンバーによりサーバーが起動された場合は失敗します。

解決策3

ドメインをインストールしたOSユーザーを使用してサーバーを再起動します。

J.4.5 サーバーの起動に関するその他の問題

この項では、WebLogic Serverの起動に失敗する理由をいくつか説明します。

現象

ポリシー・プロバイダをロードして設定しようとすると、WebLogic Serverの起動に失敗し、次のような例外がログに記録されます。

<Mar 30, 2010 3:15:54 PM EDT> <Error> <Security> <BEA-090892> <The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider.
...
<Mar 30, 2010 3:15:54 PM EDT> <Critical> <WebLogicServer> <BEA-000386> <Server subsystem failed. Reason: weblogic.security.SecurityInitializationException: The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider.
...
weblogic.security.SecurityInitializationException: The dynamic loading of the OPSS java security policy provider class oracle.security.jps.internal.policystore.JavaPolicyProvider failed due to problem inside OPSS java security policy provider. Exception was thrown when loading or setting the JPSS policy provider.
...

診断

サーバーの起動では、jps-config.xml構成ファイルに定義されているように、ポリシー・プロバイダのロードおよび設定を行います。このタスクが正常に完了しないと、WebLogic Serverの起動に失敗します。このタイプの失敗は、サーバーのログで次の文字列によって識別されます。

Exception was thrown when loading or setting the JPSS policy provider.

サーバーの起動失敗の根本原因を突き止めるには、そのサーバーのログ・ファイルを確認し、記録されたスタック・トレースを調べます。エラーの特定の詳細は、「セキュリティ・エラーの診断」を参照してください。

サーバーが起動に失敗する理由を次にいくつか示します。

1. 構成ファイルのパスの指定に誤りがあります。

2. 構成ファイルにデフォルトのコンテンツが欠落しています。

3. XMLパーサーが利用不能です。

4. システム・ポリシーに指定されたコードソースURLに誤りがあります。この状況は、次の文字列を含む例外がログに記録されていることで識別されます。

java.net.MalformedURLException: unknown protocol.

解決策

次の手順では、前述の各理由に対する解決策について説明します。

1. システム・パラメータoracle.security.jps.configに正しいパスが指定されていることを確認します。

-Doracle.security.jps.config=<full-path-to-jps-config.xml>

フルパスの指定時には、特殊文字(バックスラッシュや空白文字など)は正しくエスケープ処理する必要がある点に注意してください。誤りがないことを確認する方法の1つとして、コマンドラインにそのフルパスを指定してテストしてみます。

2. 構成ファイルには、デフォルトのコンテキストが含まれている必要があります。デフォルトのコンテキストの例は、<jpsContext>を参照してください。

3. 使用システムでXMLパーサーが利用できることと、クラスパスにXMLパーサーのJARファイルが含まれていることを確認します。

4. 次の例では、誤ったコードソースURLと修正したコードソースURLを示します。

Example 1 - Incorrect URL
<grantee>
<codesource>
<url>${my.oracle.home}/jlib/webcacheua.jar</url>
</codesource>
</grantee>

Example 1 - Corrected URL (in bold)
<grantee>
<codesource>
<url>file:/${my.oracle.home}/jlib/webcacheua.jar</url>
</codesource>
</grantee>

Example 2 - Incorrect URL
<grantee>
<codesource>
<url>c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>

Example 2 - The corrected URL (in bold) is either one of the following three:
<grantee>
<codesource>
<url>file:///c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>

<grantee>
<codesource>
<url>file:c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>

<grantee>
<codesource>
<url>file:/c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>

コードソースでのURLの指定構文の詳細は、<url>を参照してください。

J.4.6 サーバーの起動前のパーミッション・チェックの失敗

この項では、サーバーが起動フェーズを完了する前にパーミッション・チェックが失敗する理由について説明します。

現象

サーバーの起動前に認可チェックが失敗します。サーバーは起動しましたが、サーバーの診断ファイルに次の行が出力されます。

<WebLogicServer> <BEA-000365> <Server state changed to STARTING>

診断

サーバーのステータスがSTARTINGに変わる前のパーミッション・チェック・エラーは通常、そのパーミッションのチェックに必要なサービスがリクエスト時に完全には初期化されていなかったことを示します。

解決策

この問題を回避するには:

1. weblogic.policyファイルを編集して、適切な権限付与を追加します。

2. 次のシステム・プロパティを設定してWebLogic Serverを起動します。

- java.security.policyをweblogic.policyファイルの場所に設定します。

- jps.policystore.hybrid.modeをtrueに設定します。

J.5 パーミッションのトラブルシューティング

この項では、次の問題について説明します。

- システム・ポリシー障害のトラブルシューティング

- パーミッションの取得の失敗 - 大文字と小文字の不一致

- 認可チェックの失敗

- ユーザーによる予期しないパーミッションの取得

- Java SEアプリケーションにおけるパーミッションの付与

- 12c HAドメインで認識されないアプリケーション・ポリシー

J.5.1 システム・ポリシー障害のトラブルシューティング

システム・ポリシーは、プリンシパルまたはコードソースが実行を許可される権限セットを指定するポリシーで、ドメイン全体に適用されます。たとえば、アプリケーション・コードでポリシー、資格証明、キーまたは監査に対して管理操作を実行する必要がある場合、コードソースの権限付与は必須です。このような操作のいずれかで実行時の認可に失敗すると、java.security.AccessControlException例外がスローされます。この項では、問題を診断するために実行する手順について説明します。

現象

実行時の認可で障害が発生します。

java.security.AccessControlException: access denied
(oracle.security.jps.service.credstore.CredentialAccessPermission
context=SYSTEM,mapName=oracle.patching,keyName=FUSION_APPS_PATCH_WLS_ADMIN-KEY read)

まず、障害に関する情報を得るために、次のロガーを有効にして障害を再現します。

setLogLevel(target="serverName", logger="oracle.security.jps.util.JpsAuth", level="TRACE:32", persist=1);

setLogLevel(target="serverName", logger="oracle.security.jps.trace.logger", level="TRACE:32", persist=1);

setLogLevel(target="serverName", logger="oracle.security.jps.dbg.logger", level="TRACE:32", persist=1);

setLogLevel(target="serverName", logger="oracle.security.jps.internal.policystore.JavaPolicyProvider", level="TRACE:32", persist=1);

setLogLevel(target="serverName", logger="oracle.jps.common", level="TRACE:32", persist=1);

JpsAuthロガーの出力で文字列"Failed ProtectionDomain"を探します。次の出力例は、この文字列に関連している行を示しています。

Failed ProtectionDomain:ClassLoader=sun.misc.Launcher$AppClassLoader@1823ab20                      CodeSource=file:/scratch/idmprov/idmtop/products/iam/patch_wls1036/patch_jars/BUG14331527_1036.jar
Principals=total 0 of principals<no principals>
Permissions=((java.io.FilePermission /scratch/idmprov/idmtop/products/iam/patch_wls1036/patch_jars/BUG14331527_1036.jar read)
…
Call Stack:    java.security.AccessControlException: access denied (oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM, mapName=OAM_STORE, keyName=jks write)
e] java.security.AccessControlContext.checkPermission(AccessControlContext.java:374)
e] java.security.AccessController.checkPermission(AccessController.java:546)
e] oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission (JpsAuth.java:463)

診断

この障害では、プロビジョニングされたコードソースの権限付与と、その権限付与に対するランタイムの拡張評価が一致しないことを示しています。

解決策

この問題を解決するには、ランタイムが評価するパーミッション、ターゲットおよびアクションと一致するように、プロビジョニングされたコードソースの権限付与を更新する必要があります。そのためには、次の手順を実行します。

1. 第10.3項「Fusion Middleware Controlを使用したポリシーの管理」の説明に従ってFusion Middleware Controlを使用するか、listCodeSourcePermissions WLSTコマンドを使用して、プロビジョニングされたコードソースの権限付与を調べます。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

2. プロビジョニングされたコードソースの権限付与がランタイム・エラーのデータと一致しない場合、Fusion Middleware ControlまたはgrantPermission WLSTコマンドを使用して、この権限付与を変更します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

3. ドメインおよびその他の変数が、指定された権限付与に正しく展開されることを確認します。ロガーでは、コードソースはJARファイルへの絶対パスを使用して書き込まれますが、URLは環境変数を使用して書き込まれることに注意してください。

4. system-jazn-data.xmlファイルで権限付与を指定している場合、アプリケーションを新しい環境でデプロイしたときに修正が有効になるように、このファイルの権限付与を確認します。

5. 権限が付与されたブロック内でコードを実行する必要がある場合は、そのブロック内で実行されていることを確認します。

J.5.2 パーミッションの取得の失敗 - 大文字と小文字の不一致

この項では、エンタープライズ・ユーザーまたはロール(グループ)のパーミッションの取得に失敗する理由をいくつか説明します。

現象

認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに権限付与で定義されたパーミッションが付与されません。

診断

この問題は、格納されている名前と指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致は、格納されているユーザー名がjDoeで、指定されたユーザー名がjdoeの場合に発生します。

解決策1

1つ目の解決策では、ドメイン内で使用されている認証プロバイダで適切なプロパティを設定します。両方の文字列(指定された文字列と格納されている文字列)にまったく同じ順序の文字が(大文字と小文字に関係なく)含まれているかぎり、この設定により、対応する文字の大文字と小文字が異なっている場合でも、サブジェクトに移入されたユーザー名が、認証プロバイダに存在するユーザー名に一致することが保証されます。

プロバイダのプロパティを設定するには、次の手順を実行します。

1. WebLogic Server管理コンソールを使用してプロバイダを構成するページに移動します。たとえば、デフォルトのプロバイダを使用している場合は、Realms.myrealm.Providers.Default Authenticatorでデフォルト・オーセンティケータのページに移動します。

2. 「プロバイダ固有」タブを選択します。

3. プロパティuserRetrievedUserNameAsPrincipalをtrueに設定します。

4. サーバーを再起動します。

解決策2

2つ目の解決策では、ユーザー名からプリンシパルを生成する必要がある場合を考えます。

ユーザーまたはロール・プリンシパルを作成する場合、次のコードを使用します。

Principal userPrincipal = new WLSUserImpl(user.getUserProfile()getName());
Principal rolePrincipal = new WLSGroupImpl(role.getRoleProfile().getName());

次のコードは使用しません。

Principal userPrincipal = new WLSUserImpl(user.getName());
Principal rolePrincipal = new WLSGroupImpl(role.getName());

正しいユーザーまたはグループ名を取得するには、認証プロバイダに格納されている名前を正確にそのまま渡すか、次のコール・シーケンスを使用します。

import weblogic.security.principal.WLSGroupImpl;
import weblogic.security.principal.WLSUserImpl;

// Set the context
JpsContextFactory ctxFact = JpsContextFactory.getContextFactory();
ServerContextFactory scf = (ServerContextFactory) ctxFact;
JpsContext ctx = scf.getContext(ServerContextFactory.Scope.SYSTEM);
ctx = ctxFact.getContext();

// Set the identity store
IdentityStore identityStore = ctx.getServiceInstance(IdentityStoreService.class).getIdmStore();

// In case of a user name, search the user that matches the supplied name
User user = idStore.searchUser(IdentityStore.SEARCH_BY_NAME, suppliedUserName);

// Use the obtained object (user) to obtain the stored user name and create
// the Principal
String storedUserName = user.getName();
Principal userPrincipal = new WLSUserImpl(storedUserName);

// Similarily, in case of a role name, search the role that matches
// the supplied role name
Role role = identityStore.searchRole(IdentityStore.SEARCH_BY_NAME, suppliedRoleName);

// Use the obtained object (role) to obtain the stored role name and create
// the Principal
String storedRoleName = role.getName();
Principal rolePrincipal = new WLSGroupImpl(storedRoleName);

J.5.3 認可チェックの失敗

この項では、認可チェックが失敗する理由について説明します。

現象

アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。

Servlet failed with Exception oracle.adf.controller.security.AuthorizationException:ADFC-0619:
Authorization check failed: '/StartHere.jspx' 'VIEW'.

診断

このような認可の失敗が発生する理由の1つは、コンテキストと、アプリケーションで使用しているストライプとの間の不一致です。

一方では、アプリケーションで使用するアプリケーション・ストライプが、JpsFilterフィルタまたはJpsInterceptorインターセプタの構成でapplication.nameパラメータを使用してweb.xmlファイルに指定されています。アプリケーション・ストライプが指定されていない場合、アプリケーション名に基づいて、アプリケーション・ストライプが取得されます。

他方では、アプリケーションで使用する実行時ポリシーが、<application.name>要素を使用してsystem-jazn-data.xmlファイルに指定されています。

この2つの名前が一致しない場合または使用するストライプを明示的に指定されていない場合、アプリケーションが間違ったポリシー・ストライプにアクセスし、予期したとおりにアプリケーションのユーザーを認可できない可能性が高くなります。

解決策

アプリケーション・ストライプを明示的に指定し、そのストライプが、アプリケーションで使用することになっているストライプであることを確認します。ほとんどの場合、この2つの異なるファイルに指定された2つの名前は一致します。ただし、複数のアプリケーションが同じポリシー・ストライプを共有する場合は、異なる可能性があります。

J.5.4 ユーザーによる予期しないパーミッションの取得

この項では、ユーザーが予期したもの以外のパーミッションを取得する、よくある理由について説明します。

現象

新しいユーザーまたは変更されたユーザーが、予期しないパーミッションを取得します。

診断

この問題は、すでに削除されたユーザーの名前を使用してユーザーを追加した場合、または古いユーザーがその名前またはuidを変更した場合に、よく起こります。ユーザーが予期したより多いまたは少ないパーミッションを取得する一般的な理由は、ユーザーの削除前またはユーザー・データの変更前にセキュリティ・ストアが適切に更新されていないことです。

解決策

ユーザーを削除する前に、そのユーザーに付与されていたパーミッション、アプリケーション・ロールおよびエンタープライズ・グループをすべて取り消します。このユーザーを参照するセキュリティ・データの一部を削除できなかった場合、そのようなデータは中途半端な状態のままになり、同じ名前の別のユーザーが後で作成された場合に継承される可能性があります。

ユーザー名を変更する場合にも、同様の考え方が当てはまります。新しいデータでも予期したとおりに機能するように、古いデータを参照するポリシー(権限付与、パーミッション、ロール)をすべて更新する必要があります。

J.5.5 Java SEアプリケーションにおけるパーミッションの付与

この項では、Java SEアプリケーションで権限付与を適切にコーディングする方法を説明します。ここ説明している問題はJava EEアプリケーションの問題ではありませんが、高い移植性を実現するために、この解決策をJava EEアプリケーションでも使用することをお薦めします。

現象

アプリケーション・コードに次のような行があります。

Permission p = new FilePermission(resourceName, "write");
PrincipalEntry myPrincipal2 = InfoFactory.newPrincipalEntry("weblogic.security.principal.WLSGroupImpl", enterpriseRoleName2);
ap.grant(new Principal[]{myPrincipal2.getPrincipal()}, null, new Permission[]{p});

ところが、実行時に権限が予期したとおりに適用されません。

診断

簡単な調査で、次の属性がセキュリティ・ストアにあることがわかります。

orcljaznjavaclass=oracle.security.jps.internal.policystore.UnresolvedPrincipal+cn=enterpriseRoleName2

解決策

このコードを次の行で置換する必要があります。

Permission p = new FilePermission (resourceName, "write");
PermissionEntry permEntry  = InfoFactory.newPermissionEntry(p.getClassName(), p.getName(),  p.getActions());
ap.grant (new PrincipalEntry[] {myPrincipal2}, null, new PermissionEntry[] {permEntry});

この解決策では、Principal配列ではなくPrincipalEntry配列と、Permission配列ではなくPermissionEntry配列を使用しています。

J.5.6 12c HAドメインで認識されないアプリケーション・ポリシー

この項では、12c HA (高可用性)ドメインでアプリケーション・ポリシーが有効にならなくなる順序と、その解決方法について説明します。

現象

次の順序によって、例外がスローされます。

1. 12c HAドメインで、管理サーバーまたは管理対象サーバーのいずれか(一方のみ)に(アプリケーション・ポリシーとともにパックされた)カスタム・アプリケーションをデプロイします。

2. アプリケーションをアンデプロイします。

3. 手順1のサーバーとは異なるサーバーにアプリケーションを再デプロイします。

手順3の結果、例外が発生し、アプリケーション・ポリシーは有効になりません。この問題は、12c HAドメインでのみ検出されます。

診断

この問題は、ドメイン・サーバーでキャッシュが同期されていないために発生します。様々なサーバーが個別のJVM (Java仮想マシン)で実行されていることに注意してください。

たとえば、HAドメインにサーバーA (管理サーバー)、サーバーB (管理対象サーバー)およびサーバーC (管理対象サーバー)の3つのサーバーがあるとします。さらに、アプリケーションが最初にサーバーA(管理サーバー)にデプロイされた後に、3つのサーバーすべてが再起動されたとします。サーバーA、BおよびCのキャッシュが(セキュリティ・ストアから読み込まれたポリシーで)初期化され、同期します。

アプリケーションが(サーバーAから)アンデプロイされると、サーバーAのキャッシュは消去されますが、サーバーBおよびCのキャッシュは消去されません。また、アプリケーションが(たとえばサーバーBに)再デプロイされた場合は、キャッシュが同期しなくなり、例外がスローされます(これは、ポリシー・オブジェクトがすでに存在するためです)。

解決策

アプリケーションをアンデプロイし、デプロイ前に、HAドメインのすべてのサーバーを再起動します。このように、修正した手順によってHAドメイン内のすべてのサーバーでキャッシュが同期するため、アプリケーション・ポリシーが予期したとおりに表示されます。

J.6 接続およびアクセスのトラブルシューティング

この項では、次の問題について説明します。

- JNDI接続例外

- 組込みLDAPサーバーへの接続の失敗

- LDAPサーバーへの接続の失敗

- 資格証明ストアのデータへのアクセスの失敗JNDI接続例外

- セキュリティ・アクセス制御の例外

- 匿名SSL接続の確立の失敗

J.6.1 JNDI接続例外

この項では、Java Naming and Directory Interface (JNDI)接続がタイムアウト例外をスローする理由について説明します。

現象

JNDIがjavax.naming.NamingException: LDAP response read timed out, timeout used:-1ms例外をスローします。

診断

このエラーは、ドメインでLDAPセキュリティ・ストアを使用し、Java SE Development Kit (JDK)バージョンJava SE 6u85、7u72または8u20のいずれかを実行している場合に発生します。

解決策

JDKをJava SE 6u95、7u80または8u45に更新します。認証済のJDKバージョンについては、http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.htmlにある『Oracle Fusion Middleware 12c Certifications』を参照してください。

J.6.2 組込みLDAPサーバーへの接続の失敗

この項では、組込みLDAPサーバーへの接続に失敗する理由について説明します。

現象

クライアント・アプリケーションでユーザーおよびロールAPIを使用して組込みLDAPサーバーに問合せをリクエストするために使用される接続は、接続プールに格納され、保持されます。デフォルトでは、このプールはjps-config.xmlファイルに指定されてるJNDIプールです。

このプールの同時接続数がLDAPサービスの最大許容数を超えると、クライアント・アプリケーションはサービスに接続できなくなり、すでに接続している場合でも、「ソケットがクローズされました」という例外を受信します。この場合、サーバーのログで、許容される同時接続数を超えたことが示されます。

診断

この制限を超えないようにするには、LDAPサービスで許容する最大同時接続数をアプリケーションのニーズに合わせて調整する必要があります。このしきい値は細かく調整する必要があります。最大値が小さすぎると十分でなく、例外が発生します。最大値が大きすぎると、サービス妨害(DOS)攻撃のリスクが生じます。適切な最大値は、アプリケーションと、そのアプリケーションで使用する特定のLDAPサービスに依存します。

解決策

この問題の解決方法として次の2つの選択肢があります。

- プロバイダで許容する最大同時接続数を増やします。

- アプリケーションで使用しているプロバイダが組込みLDAPサーバーである場合は、DomainName/servers/MyServerName/data/ldap/conf/vde.propファイルを編集してvde.quota.max.conpersubjectプロパティの値をデフォルトの100から200などの値に増やします。

- そうではなく、アプリケーションでその他のプロバイダを使用している場合は、プロバイダのドキュメントで最大値の変更方法を確認してください。

- DomainName/config/fmwconfig/jps-config.xmlファイルを編集して、CONNECTION_POOL_CLASSプロパティをプロバイダ・サーバー・インスタンスから削除します(デフォルトでは、このプロパティの値はoracle.security.idm.providers.stdldap.JNDIPoolです)。

これらの設定は相互排他的ではなく、いずれの場合も、変更を有効にするにはサーバーを再起動する必要があることに注意してください。

J.6.3 LDAPサーバーへの接続の失敗

この項では、LDAPサーバーへの接続が失敗する、よくある理由について説明します。この失敗は、再関連付け時にも発生する可能性があります。

現象

ソース・リポジトリからターゲットLDAPサーバーへのデータの移行が失敗します。

診断

この種の問題は、ターゲットLDAPサーバーのパラメータ値が間違っていることが原因です。

WebLogic Serverのログ・ファイルをさらに調査する場合は、DomainName/servers/AdminServerディレクトリまたはDomainName/servers/ManagedServersディレクトリのログ・ファイルで<Error>、<Critical>および<Warning>という文字列を検索します。

エラーを特定して解決する方法の詳細は、第J.2項「セキュリティ・エラーの診断」を参照してください。

解決策

移行用に指定したターゲット・サーバー・データが、すべて有効であることを確認します。Fusion Middleware Controlを使用して、LDAPサーバーへの再関連付けを行う場合、必ず操作を開始する前に「LDAP認証のテスト」ボタンを使用してください。このテストにより、間違ったパラメータが見つかります。

J.6.4 資格証明ストアのデータへのアクセスの失敗

この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。

現象

アプリケーションが、ドメインの資格証明ストアからの資格証明データの取得に失敗し、次のような行を含むエラー・メッセージがログに記録されます。

07/07/26 18:22:22 [JpsAuth] For permisson ( CredentialAccessPermission [target] [actions]), domain that failed: ProtectionDomain
cs(file:somePath/aWarFile.war/WEB-INF/classes/), []

診断

アプリケーションが資格証明ストアにアクセスして操作(ユーザー・パスワードの取得など)を実行する場合、保護された操作を実行するために、そのコードに適切なパーミッションを付与する必要があります。そうしないと、アプリケーションでエラーが発生します。

解決策

資格証明ストアへのアクセスにアプリケーションが必要とするパーミッションを付与するには、アプリケーションのjazn-data.xmlに適切なCredentialAccessPermissionパーミッションを含めます。この権限付与は、アプリケーションをデプロイまたは再デプロイすると有効になります。

Fusion Middleware Controlを使用してパーミッションを追加するには、第10.3項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。

WLSTコマンドを使用してパーミッションを追加するには、第10.4項「WLSTを使用したポリシーの管理」を参照してください。

次の例では、myAppアプリケーションの内のすべてのコードに、myAliasフォルダ内のすべての資格証明を読み取るパーミッションを付与する方法を示します。

<jazn-data>
<!--  codesource policy -->
<jazn-policy>
<grant>
<grantee>
<codesource>
<!-- This grants applies to all code in the following directory -->
<url>${domain.home}/tmp/_WL_user/myApp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.service.credstore.CredentialAccessPermission</class>
<!-- Allow read permission to all credentials under folder MY_MAP -->
<name>context=SYSTEM,mapName=MY_MAP,keyName=*</name>
<actions>read</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</jazn-data>

J.6.5 セキュリティ・アクセス制御の例外

この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。

現象

実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが示されています)。

<Jan 20, 2009 5:45:33 PM PST> <Error> <HTTP> <BEA-101020>
<[weblogic.servlet.internal.WebAppServletContext@140cf52
- appName: 'Application2',
name: 'Application2.war',
context-path: '/Application2',
spec-version: '2.5']
Servlet failed with Exceptionjava.lang.RuntimeException:java.security.AccessControlException:access denied
...

診断

このエラーは、コード内のコールに、保護された操作を実行するための十分なパーミッションがないことを意味しています。

解決策

保護された操作を実行するために、コードに十分なパーミッションを付与する必要があります。設定するパーミッションの範囲に応じて、2つの選択肢があります。

1つ目は、アプリケーションのエンタープライズ・アーカイブ(EAR)ファイルまたはWebアプリケーション・アーカイブ(WAR)ファイル内のすべてのアプリケーション・コードにパーミッションを付与します。この場合、操作へのコールはアプリケーション・コードの任意の場所に挿入できます。

2つ目は、JARファイルにのみパーミッションを付与します。この場合、操作へのコールは権限が付与されたブロック内にある必要があります。

これらの解決策をそれぞれ、資格証明ストアへのアクセスを試みるアプリケーションの例によって次に示します。

次の例では、資格証明ストアにあるマップMY_MAP内のあらゆるキーをBasicAuthディレクトリ内の任意のコードに読み取るためのパーミッションの設定方法を示します。

<jazn-policy>
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/_WL_user/BasicAuth/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>
oracle.security.jps.service.credstore.CredentialAccessPermission
</class>
<name>context=SYSTEM,mapName=MY_MAP,keyName=*</name>
<actions>read</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

特定のEARファイルまたはWARファイル内のコードにパーミッションを付与する場合は、url指定を次のように変更します。

<url>file:${domain.home}/servers/_WL_user/jpsBasicAuth/.../BasicAuth.ear</url>

特定のJARファイル内のコードにのみパーミッションを付与する場合は、url指定を次のように変更します。

<url>file:${domain.home}/servers/_WL_user/jpsBasicAuth/myJars/Foo.jar</url>

その場合は、資格証明ストアに対する読取り操作をコールするFoo.jarファイル内のコードを、AccessController.doPrivilegedブロック内に配置する必要があります。

import oracle.security.jps.*;
import oracle.security.jps.service.credstore.*;

JpsContextFactory factory = JpsContextFactory.getContextFactory();
JpsContext jpsContext = factory.getContext();
final CredentialStore store = jpsContext.getServiceInstance(CredentialStore.class);
Credential cred = AccessController.doPrivileged(new PrivilegedExceptionAction<PasswordCredential>() {
public PasswordCredential run() throws JpsException {
return store.getCredential("MY_MAP", "anyKey");
}
});

PasswordCredential pwdCred = (PasswordCredential)cred;
...

この例では、権限付与で読取りパーミッションのみを許可しているため、権限が付与されたブロック内であっても、設定操作またはリセット操作のいずれも機能しないことに注意してください。

J.6.6 匿名SSL接続の確立の失敗

この項では、ポリシーと資格証明の再関連付けを行う際に匿名Secure Sockets Layer (SSL)接続を確立できない、よくある理由について説明します。

現象

Fusion Middleware Controlを使用したLDAPサーバーへのファイル・セキュリティ・ストアの再関連付けでは、LDAPサーバーへの匿名SSL接続をテストします。「LDAPのテスト」をクリックすると、テストに失敗します。

診断

ターゲットLDAPサーバーがWebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。

解決策

LDAPサーバーへのSSL接続を確立するには、LDAPサーバーの追加構成が必要です。この構成の詳細は、第9.2.1項「LDAPセキュリティ・ストアを使用する場合の前提条件」を参照してください。

さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このようなポートを使用してLDAPサーバーを構成していない場合、接続は失敗します。

指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。

J.7 Oracle Business Intelligence Publisherのタイムゾーン

BI Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、監査レポートに問題が発生することがあります。必ずBI Publisherとデータベースを同じタイムゾーンにインストールします。

J.8 検索のトラブルシューティング

この項では、問合せの問題について説明します。

- セキュリティ・ストアでの属性照合時の検索の失敗

- 不明なホスト例外による検索の失敗

J.8.1 セキュリティ・ストアでの属性照合時の検索の失敗

この項では、属性のカタログ化が必要な理由について説明します。

現象

セキュリティ・ストアに問い合せると、次のような例外が発生します。

oracle.security.jps.service.policystore.PolicyStoreOperationNotAllowedException
javax.naming.OperationNotSupportedException:
[LDAP: error code 53 - Function Not Implemented, search filter attribute orcljpsresourcetypename is not indexed/cataloged];
remaining name 'cn=Permissions,cn=JAASPolicy,cn=IDCCS, cn=sprint6_policy_domain,cn=JPSContext,cn=FusionAppsPolicies'

診断

orcljpsresourcetypenameカタログは、フィルタで使用してセキュリティ・ストアを検索する前に、カタログ化する必要があります。

解決策

検索フィルタで使用するLDAP属性は、索引付けしてカタログ化する必要があります。索引作成やカタログ化は通常は必須ではありませんが、OPSS関連の属性の場合は必須です。属性の索引付けおよびカタログ化は、reassociateSecurityStore WLSTコマンドによって自動的に実行されます。

属性を手動でカタログ化するには、ldapmodifyコマンドを使用します。

>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>

たとえば、createtimestamp属性とmodifytimestamp属性をカタログ化するには、次のようなLDAPデータ交換形式(LDIF)ファイルを使用します。

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: modifytimestamp
orclindexedattribute: createtimestamp

索引付けが必要なLDAP属性のリストは次のとおりです。

OrclJpsAllResourcKeyword
OrclJpsAllResourceActionKeyword
OrclJpsEncodedAttributes
OrclJpsExtensionType
OrclJpsResourceConverter
OrclJpsResourceMatchingAlg
OrclJpsResourceMatchingAlgorithm
OrclJpsResourceNameExpression
OrclJpsRoleType
orcOesAppAttributes
orclASInstanceName
orclFarmName
orclJPSObjGUID
orclJavaApplicationEntityRef
orclJpsPolicyDomainName
orclJpsResourceActionsetMembers
orclJpsResourceExpression
orclJpsResourceLocalityRef
orclJpsResourceMatcherJavaclass
orclJpsResourceName
orclJpsResourceTypeActionAttrs
orclJpsResourceTypeActionNames
orclJpsResourceTypeName
orclJpsResourceTypeProviderName
orclJpsResourceTypeResourceAttrs
orclJpsRoleCategory
orclJpsRoleMemberExpression
orclJpsSuperResourceType
orclOESActCollectionName
orclOESActCollectionRfs
orclOESActionAttributes
orclOESActionConstraint
orclOESAlgorithmJavaClass
orclOESAllResourceType
orclOESAllowAdviceRef
orclOESAllowObligationRef
orclOESAttributeCategory
orclOESAttributeCollectionHandlerFunctionName
orclOESAttributeCollectionHandlerPackageName
orclOESAttributeCollectionHandlerSchemaName
orclOESAttributeCollectionName
orclOESAttributeDataType
orclOESAttributeIssuer
orclOESAttributeNamespace
orclOESAttributeType
orclOESCombinerParameter
orclOESConditionExpression
orclOESDSColumnAttrs
orclOESDSPrimKey
orclOESDataSourceCtrnt
orclOESDataSourceName
orclOESDataSourceType
orclOESDefaultPolSetRef
orclOESDenyAdviceRef
orclOESDenyObligationRef
orclOESDistributionEndTime
orclOESDistributionID
orclOESDistributionIssuer
orclOESDistributionMessage
orclOESDistributionPercentComplete
orclOESDistributionStartTime
orclOESEffect
orclOESEnvAttributes
orclOESEnvConstraint
orclOESExecutionFrequency
orclOESExpression
orclOESFunctionCategory
orclOESFunctionClass
orclOESFunctionParameters
orclOESFunctionReturnType
orclOESIsSensitive
orclOESIsSingleValued
orclOESMatchInfo
orclOESMaxDelegationDepth
orclOESObligationFulfillOn
orclOESPDPAddress
orclOESPDPConfigurationID
orclOESPDPInstanceName
orclOESPDPStatusSuccess
orclOESPIPType
orclOESPolicyCategory
orclOESPolicyCombinerParameter
orclOESPolicyCombiningAlgorithmRef
orclOESPolicyDefaults
orclOESPolicyExtension
orclOESPolicyIssuer
orclOESPolicyRef
orclOESPolicyRuleOrder
orclOESPolicyRuleRef
orclOESPolicySetCategory
orclOESPolicySetDefaults
orclOESPolicySetRef
orclOESPolicySetType
orclOESPolicyType
orclOESPolicyVersion
orclOESPresenceRequired
orclOESPrincConstraint
orclOESPrincipalAttributes
orclOESResConstraint
orclOESResTypeCategory
orclOESResourceAttributes
orclOESResourceHirchyType
orclOESResourceNameDelim
orclOESResourceParentName
orclOESRoleMapping
orclOESRuleCombinerParameter
orclOESRuleCombiningAlgorithmRef
orclOESSQLExpression
orclOESSetCombinerParameter
orclOESSetMemberOrder
orclOESTargetExpression
orclOESXMLExpression
orclassignedpermissions
orclassignedroles
orcldistributionversion
orcljazncodebase
orcljaznjavaclass
orcljaznpermissionactions
orcljaznpermissionresourceref
orcljaznpermissionsigner
orcljaznpermissiontarget
orcljaznpermissiontargetexpr
orcljaznprincipal
orcljaznsigner
orcljpsRuleCombiningAlgorithmRef
orcljpsactionsdelim
orcljpsassignee
orclrolescope

J.8.2 不明なホスト例外による検索の失敗

Microsoft Active Directory (LDAP参照用に構成)で検索する際、参照先のホストがActive Directoryサーバーと異なるドメインにある場合、参照は失敗します。

現象

ユーザーがリソースをリクエストしたときに、ディレクトリでのユーザーのアイデンティティの検証が不可能なためにユーザーのアイデンティティの検証に失敗することがあります。このエラーは、ブラウザがMicrosoft Windows以外のシステムで実行されている場合またはブラウザがMicrosoft Windowsで実行されていてもMicrosoft Active Directoryが稼働しているサーバーにない場合に、Microsoft Active Directoryで発生します。

診断

この問題はLDAP参照の追跡が原因で発生することがあります。LDAP参照は、リクエスト対象のオブジェクトが存在するディレクトリ・ツリー・セクションをドメイン・コントローラが保有していないときに発生します。ドメイン・コントローラは、クライアントが別のドメイン・コントローラのDNS検索を実施できるように、クライアントに別のターゲットを参照させます。クライアントが参照を追跡するよう構成されている場合は、検索を継続できます。

ユーザーがWindowsベースのコンピュータを使用しているシナリオでは、クライアントのドメイン・コントローラとActive Directoryドメイン・コントローラとの間に信頼が確立されていない場合に、LDAP参照で問題が発生することがあります。

解決策

Active Directoryホストのアドレスのエントリを次のリストに追加します。

WINDOWS_HOME_DIRECTORY\system32\drivers\etc\hosts

Windows XPの場合、リストは次の場所にあります。

C:\WINDOWS\system32\drivers\etc\host

Unixベースのシステムの場合は、このエントリを次の形式で/etc/hostsファイルに追加します。

ADhost_IPaddress ADhost_name

AD_host_nameは、参照で指定されるホスト名です(例: 123.123.123.123 my2003ad.com)。

J.9 バージョンのトラブルシューティング

次の各項では、バージョンの問題について説明します。

- バイナリとセキュリティ・ストアのバージョンの非互換性

- セキュリティ・ストアのバージョンの非互換性

J.9.1 バイナリとセキュリティ・ストアのバージョンの非互換性

この項では、サーバーがPolicyStoreIncompatibleVersionException例外をスローする理由について説明します。

現象

次のようなエラーが発生します。

Oracle.security.jps.service.policystore. PolicyStoreIncompatibleVersionException
JPS-06100: Policy Store version 11.1.1.5.0 and Oracle Platform Security Services
version 11.1.1.4.0 are not compatible.

診断

この例外は、ドメインのOPSSバイナリ・バージョン(11.1.1.4.0)と、そのドメインで使用しているセキュリティ・ストアのバージョン(11.1.1.5.0)に互換性がないことを示しています。セキュリティ・ストアのバージョンは再関連付け時に設定され、セキュリティ・ストアを新しいバージョンにアップグレードするまでそのバージョンが使用されます。

OPSSドメイン・バイナリ・バージョンは、セキュリティ・ストアのバージョンと下位互換性はありますが、上位互換性はありません。したがって、このエラーは、セキュリティ・ストアのバージョンがOPSSバイナリのバージョンよりも新しいことを示しています。

OPSSバイナリで非互換性が発生するシナリオには、次の3つがあります。

- シナリオ1

- Domain1とDomain2は同じセキュリティ・ストアを指しています。Domain1、Domain2およびそのセキュリティ・ストアのバージョンはいずれも11.1.1.3.0です。

- Domain1のバイナリを11.1.1.4.0にアップグレードします。

- セキュリティ・ストアを11.1.1.4.0に(upgradeOPSSコマンドを使用して)アップグレードします。

- Domain2を再起動すると、バイナリとセキュリティ・ストアのバージョンに互換性がありません。

- シナリオ2

- Domain1はセキュリティ・ストアを指しており、バイナリおよびセキュリティ・ストアのバージョンはどちらも11.1.1.3.0です。

- セキュリティ・ストアを11.1.1.4.0に移行しようとすると、移行によってバージョンの非互換性が発生するため、失敗します。
移行は、OPSSバイナリとセキュリティ・ストアのバージョンが同じ場合にのみサポートされます。

- シナリオ3

- 11.1.1.3.0のDomain1で、join引数を指定したreassociateSecurityStore WLSTコマンドを使用して、11.1.1.4.0のセキュリティ・ストア(他のドメインにあるもの)を結合しようとします。

- この操作は失敗します。この共有によってバージョンの非互換性が発生するためです。
再関連付けは、OPSSバイナリとセキュリティ・ストアのバージョンが同じ場合にのみサポートされます。

解決策

3つのシナリオすべてに対する解決策は、次のいずれかです。

- OPSSバイナリを更新して、ドメインが使用しているセキュリティ・ストアのバージョンと一致させます。

- そのセキュリティ・ストアを、バージョンがOPSSバイナリのバージョン以下のセキュリティ・ストアに再関連付けします。

J.9.2 セキュリティ・ストアのバージョンの非互換性

この項では、セキュリティ・ストアの移行中にPolicyStoreIncompatibleVersionException例外が発生する理由について説明します。

PolicyStoreIncompatibleVersionException例外は、ソース・ストアのバージョンがターゲット・ストアのバージョンよりも高いことを示しています。移行は、ソースのバージョンがターゲットのバージョン以下である場合にのみ実行されます。

回避策は、移行先のストアのバージョンを移行元のストアのバージョンと互換性のあるバージョンにアップグレードすることです。

J.10 その他のエラーのトラブルシューティング

次の各項では、様々な問題について説明します。

- 実行時のパーミッション・チェックの失敗

- サイズ変更の必要な表領域

- Oracle Internet Directoryの例外

- ユーザーおよびロールAPIの失敗

- ポリシーに使用する文字

- 無効な鍵サイズ

J.10.1 実行時のパーミッション・チェックの失敗

この項では、パーミッションで、パーミッション・チェックに合格できない理由について説明します。

現象

アプリケーションが次のようなエラーを出力します。

[JpsAuth] Check Permission
PolicyContext:        [null]
Resource/Target:      [test]
Action:               [null]
Permission Class:     [com.oracle.permission.SimplePermission]
Evaluator:            [ACC]
Result:               [FAILED]
Failed ProtectionDomain:ClassLoader=weblogic.utils.classloaders.ChangeAwareClassLoader@14061a8
finder: weblogic.utils.classloaders.CodeGenClassFinder@2dce7a8
annotation: Application2@Application2.war
CodeSource=file:/scratch/servers/AdminServer/tmp/permission/TestServlet$1.class
Principals=total 0 of principals<no principals>
Permissions=(
(oracle.security.jps.service.credstore.CredentialAccessPermission
context=SYSTEM,mapName=default,keyName=* read,write)
(java.net.SocketPermission localhost:1024- listen,resolve)
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=* getApplicationPolicy)
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=SYSTEM getConfiguredApplications)
(com.oracle.permission.SimplePermission *)
...
java.security.AccessControlException: access denied
(com.oracle.permission.SimplePermission test)...

診断

2つ以上のアプリケーションがパーミッション・クラスを共有している場合、そのパーミッション・クラスをシステム・クラス・パスに設定して、そのクラスを一度だけロードする必要があります。そうしないと、クラスをロードする最初のアプリケーションのみがパーミッション・チェックに合格します。その後、同じクラスをロードする他のアプリケーションは、パーミッション・チェックに合格せず、同様のエラーを出力します。

パーミッション・クラスがパーミッション・コレクション内にあっても、環境に同じ名前のパーミッション・クラスのインスタンスが複数存在するため、チェックに合格せず、アクセスが拒否されることに注意してください。

解決策

同じドメイン内で実行されている2つ以上のアプリケーションが1つのパーミッション・クラスを共有する場合、必ずシステム・クラス・パスにそのクラスを含めます。

J.10.2 サイズ変更の必要な表領域

この項では、DBセキュリティ・ストアで、SQL操作が失敗する場合の理由について説明します。

現象

ポリシー操作の実行中に、データベースが次のようなエラーを発行します。

"ORA-1652: unable to extend temp segment by 128 in tablespace"

診断

理由は、操作で使用される一時表に使用できる空きブロックがないことです。

解決策

この問題を解決するには:

1. 一時表のサイズを4096Mに拡張します。

ALTER TABLESPACE "<TEMP_TABLESPACE_NAME>" ADD TEMPFILE '<data_file_name>' size 4096M

2. 管理サーバーを再起動します。

J.10.3 Oracle Internet Directoryの例外

Oracle Internet Directory 11.1.1.6.0をセキュリティ・ストアとして使用しているドメインでは、次のような例外が発生します。

[LDAP: error code 53 - OID-5018: Cataloging for attr orcljpsextensiontype
is already in progress.]:cn=catalogs

Oracle Internet Directory 11.1.1.6.0では、Oracle Bug#13782459を修正するパッチを適用する必要があります。Oracle Internet Directoryのパッチ・リストは、第9.2項「LDAPセキュリティ・ストアの使用」を参照してください。

J.10.4 ユーザーおよびロールAPIの失敗

この項では、ユーザーおよびロールAPIによる認証プロバイダのデータへのアクセスに失敗する理由について説明します。

現象

ユーザーおよびロールAPIで、データへのアクセスに失敗します。

診断1

ユーザーおよびロールAPIでは、ドメイン内で最初に構成されたLDAPプロバイダのデータにのみアクセスできます。このようなプロバイダが少なくとも1つ、ドメイン内に存在する必要があります。その最初のLDAPプロバイダにターゲット・ユーザーが存在しない場合、そのユーザーが他の認証プロバイダに存在しても、APIはそのプロバイダへのアクセスに失敗します。

解決策1

この存在しないユーザーを最初のLDAP認証プロバイダに入力するか、ドメイン内のLDAPプロバイダのリストの順序を並べ替えます。

診断2

ドメイン内で最初に構成されたLDAPプロバイダに、失敗したAPIのターゲット・ユーザーが存在するとします。

デフォルトでは、ユーザーおよびロールAPIでは、uid属性を使用してLDAPプロバイダでユーザー検索を実行します。らかの理由で、LDAPで入力したユーザーにこの属性が欠落している場合、ユーザーおよびロールAPIは失敗します。

解決策2

最初のLDAP認証プロバイダのすべてのユーザーに、uid属性が設定されていることを確認します。

Java SEアプリケーションを開発していて、ユーザーおよびロールAPIでuid以外の属性(mailなど)を使用してユーザーを検索する場合は、username.attr属性とuser.login.attr属性をアイデンティティ・ストアのLDAPプロバイダ・インスタンス(jps-config-jse.xmlファイル)で構成する必要があります。

<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
...
<property name="username.attr" value="mail"/>
<property name="user.login.attr" value="mail"/>
...
</serviceInstance>

所定のスクリプトを使用してプロバイダ・インスタンスにプロパティを追加する方法の詳細は、第E.1項「スクリプトを使用したサービスの構成」を参照してください。

J.10.5 ポリシーに使用する文字

次の各項では、ポリシーでの文字に関連するいくつかの問題について説明します。

- Oracle Internet Directory 10.1.4.3に使用する特殊文字

- ファイル・セキュリティ・ストアに使用する文字

- アプリケーション・ロール名に使用する文字

- ファイル・ストアでの改行文字の欠落

J.10.5.1 Oracle Internet Directory 10.1.4.3に使用する特殊文字

セキュリティ・ストアがOracle Internet Directory 10.1.4.3の場合、RFC 2252/2253フィルタで'*'、'('、')'または'\'の各文字を使用するとエラー53 (DSAによる操作拒否)が発生します。このエラーを解決するには、バグ番号7711351用のパッチをOracle Internet Directory 10.1.4.3に適用します。

J.10.5.2 ファイル・セキュリティ・ストアに使用する文字

この項で説明する問題は、ファイル・ストアにのみ当てはまります。

ここで問題となる文字は次のとおりです。

< "  &  $ ? * , / \ ` :    ( ) ^ ' % +  { }

これらをファイル・ストア内でロール名に使用しないことをお薦めします。

ロールを作成するために、これらのいずれかの文字を使用する場合は、正しい結果が返されるように、ApplicationPolicy.searchAppRolesなどのメソッドへの引数で必ずその文字をエスケープ処理します。たとえば、アプリケーション・ロールにappRole^$という名前を付けた場合、セキュリティ・ストアで一致を検索するにはappRole\\^\\$のように引数を渡します。

あるいは、このようなエスケープ処理した特殊文字を含めるのではなく、appRole*のように、検索式にワイルド・カードを使用することもできます。

J.10.5.3 アプリケーション・ロール名に使用する文字

アプリケーション・ロール名は、空白を含まない、英数字(ASCIIまたはUnicode)とその他の印刷可能文字(アンダースコアや大カッコなど)の文字列です。このルールは、どの種類の記憶域のロール名にも適用されます。

J.10.5.4 ファイル・ストアでの改行文字の欠落

ファイル・ストアでは、<permission>または<principal>の終了タグと次の開始タグとの間に改行文字が必要です。

次に、正しくない形式と正しい形式の例を示します。

正しくない形式:

<permission>
<class>java.lang.RuntimePermission</class>
<name>getClassLoader</name>
</permission><permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>

修正した形式:

<permission>
<class>java.lang.RuntimePermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>

J.10.6 無効な鍵サイズ

この項では、無効な鍵サイズの例外が発生する理由について説明します。

現象

次の例外が発生します。

java.security.InvalidKeyException: Illegal key size

診断1

ドメインの作成時、OPSSではキーストア・サービスを使用して、セキュリティ・ストア・データの暗号化に使用される高度暗号化標準(AES)対称鍵を作成します。OPSSは、最初に256ビットの鍵を生成しようとします。これがサポートされていない場合は、192ビットの鍵の生成を試行しますが、それもサポートされていない場合は、128ビットの鍵を作成します。128ビットの鍵がサポートされていない場合は、invalidKeyException例外がスローされます。

診断2

OPSSの起動時、ランタイムJDKでAESアルゴリズムがサポートされていないためにOPSS暗号化鍵が読取り不可能な場合、またはドメインのプロビジョニングされた鍵サイズがJDKでサポートされているサイズと異なる場合、invalidKeyException例外がスローされます。

解決策

JDKにJava Cryptography Extension (JCE)無制限強度の管轄ポリシー・ファイルをインストールし、ドメインの作成またはOPSSの起動を再試行します。

J.11 追加のヘルプ

Oracleサポートの詳細は、http://myoraclesupport.oracle.comにアクセスしてください。問題に対する解決策が見つからない場合は、サービス・リクエストを登録してください。

オラクルの法律上の注意点について

コピーライトについて

Copyright © 1994-2016, Oracle and/or its affiliates.All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

アルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のアルファ版およびベータ版ドラフト・ドキュメントについて

このドキュメントが非公開の試作版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のベータ・トライアル契約のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle PartnerNetwork Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティについて

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。