Oracle® Fusion Middleware

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

12c (12.1.2)

E47967-02(原本部品番号:E39179-02)

2014年1月

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

E47967-02

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

原本著者: Carlos Subi

原本協力著者:  Vinaye Misra

原本協力者:  Amit Agarwal、Soumya Aithal、Moushmi Banerjee、Pratik Datta、Jordan Douglas、Guru Dutt、Todd Elwood、Vineet Garg、Vikas Ghorpade、Sandeep Guggilam、Shiang-Jia Huang、Dan Hynes、Supriya Kalyanasundaram、Lakshmi Kethana、Ganesh Kirti、Ashish Kolli、Rohit Koul、Nithya Muralidharan、Frank Nimphius、Sudip Regmi、Bhupindra Singh、Kk Sriramadhesikan、Mamta Suri、Kavita Tippana、Srikant Tirumalai、Ramana Turlapati、Jane Xu、Sam Zhou

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

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

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

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

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

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

- リリース12.1.2.0.0の新機能

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

1 Oracle Platform Security Servicesの概要

- 1.1 Oracle Platform Security Servicesとは

- 1.1.1 OPSSの主な機能

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

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

- 1.2.1 OPSSの利点

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

- 1.4 管理者向けのOPSS

- 1.5 開発者向けのOPSS

- 1.5.1 シナリオ1: Java EEアプリケーションのセキュリティ強化

- 1.5.2 シナリオ2: Oracle ADFアプリケーションの保護

- 1.5.3 シナリオ3: Java SEアプリケーションの保護

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

- 2.1 用語

- 2.2 ロール・マッピング

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

- 2.3 認証ロール

- 2.4 匿名ユーザーとロール

- 2.4.1 匿名サポートとサブジェクト

- 2.5 管理ユーザーとロール

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

- 2.7 プリンシパル名の比較ロジック

- 2.7.1 プリンシパルの比較が認可に及ぼす影響

- 2.7.2 プリンシパル名の比較を制御するシステム・パラメータ

- 2.8 ロール・カテゴリ

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

- 3.1 認証の基本

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

- 3.1.2 WebLogic認証プロバイダ

- 3.1.2.1 複数の認証プロバイダ

- 3.1.2.2 その他の認証方式

- 3.2 ポリシー・ストアの基本

- 3.3 資格証明ストアの基本

- 3.4 キーストア・サービスの基本

- 3.4.1 キーストア・リポジトリのタイプ

- 3.4.2 キーストア・リポジトリのスコープと再関連付け

- 3.5 監査サービスの基本

4 Oracle Platform Security Servicesのシナリオについて

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

- 4.2 管理ツール

- 4.3 パッケージ要件

- 4.4 シナリオの例

- 4.5 その他のシナリオ

第II部 OPSSの基本的な管理

5 セキュリティ管理

- 5.1 テクノロジに応じた管理ツールの選択

- 5.2 基本的なセキュリティ管理タスク

- 5.2.1 新しい本番環境の設定

- 5.3 Fusion Middleware Controlを使用した一般的なセキュリティ操作

- 5.4 管理コンソールを使用した一般的なセキュリティ操作

- 5.5 Oracle Entitlements Serverを使用した一般的なセキュリティ操作

- 5.6 WLSTコマンドを使用した一般的なセキュリティ操作

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

- 6.1 概要

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

- 6.2.1 Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ

- 6.3 テスト環境へのOracle ADFアプリケーションのデプロイ

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

- 6.3.1.1 テスト環境へのデプロイ後の一般的な管理タスク

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

- 6.5 監査機能を伴ったアプリケーションのデプロイ

- 6.5.1 監査のパッケージ化要件

- 6.5.2 監査サービスへの登録

- 6.5.3 監査データの移行

- 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.2.3 大量のポリシー・ストアおよび資格証明ストアの移行

- 6.6.3 監査情報の移行

- 6.6.4 キーストア・サービス・アーティファクトの移行

- 6.6.4.1 キーストア移行の概要

- 6.6.4.2 ドメイン内でのキーストア・サービス・アーティファクトの移行

- 6.6.4.3 ドメイン間でのキーストア・サービス・アーティファクトの移行

第III部 OPSSサービス

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

- 7.1 概要

- 7.2 FMWドメイン

- 7.3 FMWドメインの作成

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

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

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

- 7.5 12.1.2へのアップグレード

- 7.5.1 アップグレード前に

- 7.5.2 アップグレード手順

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

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

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

- 7.6.3 推奨事項

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

- 8.1 アイデンティティ・ストア・サービスの概要

- 8.1.1 アイデンティティ・ストア・サービスについて

- 8.1.2 サービス・アーキテクチャ

- 8.1.3 アプリケーション・サーバーのサポート

- 8.1.4 Java SEのサポート

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

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

- 8.3.1 構成内容

- 8.3.1.1 複数のLDAP検索の構成

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

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

- 8.3.2 WebLogic Serverにおける構成

- 8.3.2.1 単一のLDAPを使用する場合のサービスの構成

- 8.3.2.2 virtualizeプロパティを指定せずに複数のLDAPを使用する場合のサービスの構成

- 8.3.2.3 Fusion Middleware Controlによる複数のLDAPを使用する場合のサービスの構成

- 8.3.2.4 WLSTによる複数のLDAPを使用する場合のサービスの構成

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

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

- 8.3.2.7 サーバーの再起動

- 8.3.2.8 構成ファイルの例

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

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

- 8.3.5 その他のアプリケーション・サーバーの構成

- 8.3.5.1 単一のLDAPを使用する場合のサービスの構成

- 8.3.5.2 複数のLDAPを使用する場合のサービスの構成

- 8.3.6 Java SE環境

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

- 8.5 アイデンティティ・ストア・サービスでのSSLの使用

- 8.5.1 Oracle WebLogic Serverからアイデンティティ・ストアへの接続

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

- 8.5.2.1 キーストア・サービスでの複数のLDAPシナリオでの一方向SSL

- 8.5.2.2 キーストア・サービスでの複数のLDAPシナリオでの双方向SSL

- 8.5.3 JKSベースのキーストアでのSSLの構成

- 8.5.3.1 JKSベースのキーストアを使用した複数のLDAPシナリオでの一方向SSL

- 8.5.3.2 JKSベースのキーストアを使用した複数のLDAPシナリオでの双方向SSL

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

- 9.1 OPSSセキュリティ・ストアの概要

- 9.1.1 マルチサーバー環境

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

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

- 9.2.2 LDAPへの一方向SSL接続の設定

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

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

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

- 9.3.3 DBへのSSL接続の設定

- 9.4 OPSSセキュリティ・ストアの構成

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

- 9.5.1 Fusion Middleware Controlを使用した再関連付け

- 9.5.1.1 Oracle Internet Directoryノードへのアクセスの保護

- 9.5.2 スクリプトreassociateSecurityStoreを使用した再関連付け

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

- 9.6.1 Fusion Middleware Controlを使用した移行

- 9.6.2 スクリプトmigrateSecurityStoreを使用した移行

- 9.6.2.1 監査メタデータの移行

- 9.6.2.2 使用例

- 9.7 Fusion Middleware Controlを使用したサービス・プロバイダの構成

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

- 9.7.2 シングル・サインオン・プロバイダの構成

- 9.7.3 トラスト・サービス・プロバイダの構成

- 9.7.4 プロパティとプロパティ・セットの構成

10 ポリシー・ストアの管理

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

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

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

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

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

- 10.3 WLSTコマンドを使用したアプリケーション・ポリシーの管理

- 10.3.1 reassociateSecurityStore

- 10.4 キャッシングとキャッシュのリフレッシュ

- 10.4.1 例

- 10.5 WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与

- 10.6 WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ

- 10.7 Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理

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.1.4 複数サーバーを持つドメイン用のキーストア

- 12.1.5 キーストア・サービスのトラブルシューティング

- 12.2 キーストア・サービスでのキーストアの管理

- 12.2.1 キーストア・ライフサイクルの概要

- 12.2.2 一般的なキーストアの操作

- 12.2.2.1 Fusion Middleware Controlでのキーストアの作成

- 12.2.2.2 コマンドラインでのキーストアの作成

- 12.2.2.3 Fusion Middleware Controlでのキーストアの削除

- 12.2.2.4 コマンドラインでのキーストアの削除

- 12.2.2.5 Fusion Middleware Controlでのキーストア・パスワードの変更

- 12.2.2.6 コマンドラインでのキーストア・パスワードの変更

- 12.2.2.7 コマンドラインでのキーストアのエクスポート

- 12.2.2.8 コマンドラインでのキーストアのインポート

- 12.3 キーストア・サービスでの証明書の管理

- 12.3.1 証明書のライフサイクルについて

- 12.3.2 一般的な証明書の操作

- 12.3.2.1 Fusion Middleware Controlでの鍵ペアの生成

- 12.3.2.2 コマンドラインでの鍵ペアの生成

- 12.3.2.3 Fusion Middleware Controlでの証明書に対するCSRの生成

- 12.3.2.4 コマンドラインでの鍵ペアに対するCSRの生成

- 12.3.2.5 Fusion Middleware Controlを使用した証明書または信頼できる証明書のインポート

- 12.3.2.6 コマンドラインでの証明書のインポート

- 12.3.2.7 Fusion Middleware Controlでの証明書または信頼できる証明書のエクスポート

- 12.3.2.8 コマンドラインでの証明書または信頼できる証明書のエクスポート

- 12.3.2.9 Fusion Middleware Controlでの証明書の削除

- 12.3.2.10 コマンドラインでの証明書の削除

- 12.3.2.11 Fusion Middleware Controlでの証明書のパスワードの変更

- 12.3.2.12 コマンドラインでの証明書のパスワードの変更

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

- 12.4.1 syncKeyStoresコマンドの使用

- 12.4.1.1 syncKeyStoresコマンドの使用方法

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

- 12.4.2 Oracle WebLogic Serverとの統合

- 12.4.3 ノード・マネージャとの統合

- 12.4.4 アイデンティティ・ストア・サービスとの統合

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

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

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

13 Oracle Fusion Middleware監査サービスの概要

- 13.1 Oracle Fusion Middleware監査フレームワークの利点と機能

- 13.1.1 監査の目的

- 13.1.2 現在の監査の課題

- 13.1.3 Oracle Fusion Middleware監査フレームワークについて

- 13.2 監査機能の概要

- 13.3 Oracle Fusion Middleware監査フレームワークの概念

- 13.3.1 監査アーキテクチャ

- 13.3.1.1 監査サービス・モデル

- 13.3.1.2 監査API

- 13.3.1.3 ランタイム・サポートおよび監査イベント・フロー

- 13.3.2 重要な技術的概念

- 13.3.3 監査メタデータ・ストア

- 13.3.4 監査データ記憶域

- 13.3.5 分析

- 13.3.6 監査ライフサイクルの理解

- 13.4 監査メタデータ・モデル

- 13.4.1 監査アーティファクトのネーミング規則

- 13.4.2 属性グループ

- 13.4.2.1 監査属性のデータ型

- 13.4.2.2 共通属性グループ

- 13.4.2.3 汎用属性グループ

- 13.4.2.4 カスタム属性グループ

- 13.4.3 イベント・カテゴリとイベント

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

- 13.4.3.2 コンポーネント/アプリケーション・カテゴリ

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

- 13.5.1 component_events.xmlファイル

- 13.5.2 翻訳ファイル

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

- 13.5.3.1 バージョン番号

- 13.5.3.2 カスタム属性からデータベース列へのマッピング

14 監査の構成と管理

- 14.1 監査管理タスク

- 14.2 監査データ・ストアの管理

- 14.2.1 RCUによる監査スキーマの作成

- 14.2.2 監査データソースの設定

- 14.2.2.1 複数のデータソース

- 14.2.3 Javaコンポーネント用のデータベース監査データ・ストアの構成

- 14.2.3.1 監査データ・ストアの構成の表示

- 14.2.3.2 監査データ・ストアとバスストップ・ストレージの構成

- 14.2.3.3 監査データ・ストアの構成解除

- 14.2.4 システム・コンポーネント用のデータベース監査データ・ストアの構成

- 14.2.4.1 監査データ・ストアの構成解除

- 14.2.5 バスストップ・ファイルのチューニング

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

- 14.2.6.1 環境の構成

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

- 14.3 監査ポリシーの管理

- 14.3.1 Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理

- 14.3.2 Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理

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

- 14.3.3.1 WLSTを使用した監査ポリシーの表示

- 14.3.3.2 WLSTを使用した監査ポリシーの更新

- 14.3.3.3 例1: WLSTを使用したユーザーに対する監査ポリシーの構成

- 14.3.3.4 例2: WLSTを使用したイベントに対する監査ポリシーの構成

- 14.3.3.5 監査レベルを変更する際に保持されるカスタム構成

- 14.3.4 監査ポリシーの手動による管理

- 14.3.4.1 Javaコンポーネントの構成ファイルの場所

- 14.3.4.2 Javaコンポーネントのjps-config.xml内の監査サービス構成プロパティ

- 14.3.4.3 Javaコンポーネントのデータベースからファイルへの切替え

- 14.3.4.4 システム・コンポーネントの監査構成ファイル

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

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

- 14.5.1 監査ログの場所

- 14.5.2 バスストップ・ファイルの監査タイムスタンプ

- 14.6 データベース・ストアの拡張管理

- 14.6.1 スキーマの概要

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

- 14.6.3 索引スキーム

- 14.6.4 バックアップおよびリカバリ

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

- 14.6.6 パーティション化

- 14.6.6.1 パーティション表

- 14.6.6.2 パーティション表のバックアップとリカバリ

- 14.6.6.3 インポートとエクスポート

- 14.6.6.4 データ削除

- 14.6.6.5 階層アーカイブ

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

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

- 15.2 監査データのレポート生成

- 15.2.1 監査レポートの構成

- 15.2.2 Oracle Business Intelligence Publisherの使用

第IV部 Oracle Platform Security Servicesの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 ファイングレイン認可が必要なADFアプリケーション

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

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

- 16.2.3.5 ファイングレイン認可が必要な非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.2.8.1 複数のドメインで実行されるアプリケーション

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

- 16.4 HTTPプロトコルを介したアイデンティティの伝播

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

- 16.5.1 複数のWebLogicドメイン間

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

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

- 16.5.2 単一のWebLogicドメイン内のコンテナ間

- 16.5.3 埋込みトラスト・サービス・プロバイダのプロパティ

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

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

- 16.6.2 コード・サンプル1

- 16.6.3 コード・サンプル2

- 16.6.4 コード・サンプル3

- 16.6.5 コード・サンプル4

- 16.6.6 コード・サンプル5

- 16.6.7 コード・サンプル6

- 16.7 付録 - ADFアプリケーションのセキュリティ・ライフサイクル

- 16.7.1 開発フェーズ

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

- 16.7.3 管理フェーズ

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

- 16.8 付録 - コードおよび構成例

- 16.8.1 コード例

- 16.8.2 構成例

- 16.8.3 セキュリティが統合されたJava EEアプリケーションの完全なコード例

- 16.9 付録 - JKSベースのキーストアを使用したアイデンティティの伝播

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

- 16.9.1.1 クライアント・アプリケーションのコード・サンプル

- 16.9.1.2 キーストア・サービスの構成

- 16.9.1.3 CSFの構成

- 16.9.1.4 権限付与の構成

- 16.9.1.5 サーブレット・コードのサンプル

- 16.9.1.6 web.xmlの構成

- 16.9.1.7 WebLogicアサーション・プロバイダおよびトラスト・サービスの構成

- 16.9.1.8 トラスト・サービス構成パラメータの更新

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

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

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

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

17 OPSSポリシー・モデル

- 17.1 セキュリティ・ポリシー・モデル

- 17.2 認可の概要

- 17.2.1 認可について

- 17.2.2 Java EE認可モデル

- 17.2.2.1 宣言による認可

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

- 17.2.2.3 Java EEコードの例

- 17.2.3 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 OPSSを使用するためのJava EEアプリケーションの構成

- 18.1 Java EEアプリケーションの認証トピックへのリンク

- 18.2 サーブレット・フィルタとEJBインターセプタの構成

- 18.2.1 インターセプタ構成構文

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

- 18.2.3 アプリケーションMBeansのアプリケーション・ストライプの構成

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

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

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

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

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

- 18.5.1 ポリシーの移行を制御するパラメータ

- 18.5.2 動作に従ったポリシー・パラメータの構成

- 18.5.2.1 ポリシーの移行をスキップするには

- 18.5.2.2 ポリシーをマージにより移行するには

- 18.5.2.3 ポリシーを上書きにより移行するには

- 18.5.2.4 ポリシーを削除する(またはポリシーを削除しない)には

- 18.5.2.5 静的デプロイメントでポリシーを移行するには

- 18.5.2.6 推奨事項

- 18.5.3 ウォレットベースの資格証明ストアの使用

- 18.5.4 資格証明の移行を制御するパラメータ

- 18.5.5 動作に従った資格証明パラメータの構成

- 18.5.5.1 資格証明の移行をスキップするには

- 18.5.5.2 資格証明をマージにより移行するには

- 18.5.5.3 資格証明を上書きにより移行するには

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

- 18.5.6.1 ポリシー・ストアのパーミッション

- 18.5.6.2 資格証明ストアのパーミッション

- 18.5.6.3 一般的なパーミッション

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

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

- 18.5.9 構成ファイルjps-config.xmlの例

- 18.6 アサートされたユーザーとしての実行

- 18.6.1 ユースケース

- 18.6.2 プログラミングのガイドラインおよび推奨事項

- 18.6.3 コード例

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

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

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

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

- 19.3.1 アイデンティティ・ストア

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

- 19.3.3 ログイン・モジュール

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

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

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

- 19.3.4 Java SEアプリケーションでのOPSS API LoginServiceの使用方法

- 19.4 構成例

20 認可サービスを使用した開発

- 20.1 Java SEアプリケーションでのポリシー・ストアと資格証明ストア

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

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

- 20.1.3 DBベースのOPSSセキュリティ・ストアの構成

- 20.2 ファイルベースのポリシー・ストアに対してサポートされていないメソッド

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

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

- 21.2 CSFを使用したアプリケーション開発の概要

- 21.3 Javaセキュリティ・ポリシーのパーミッションの設定

- 21.3.1 パーミッション付与のガイドライン

- 21.3.2 パーミッション付与例1

- 21.3.3 パーミッション付与例2

- 21.4 マップ名のガイドライン

- 21.5 資格証明ストアの構成

- 21.6 CSF APIの使用

- 21.6.1 Java SEアプリケーションでのCSF APIの使用

- 21.6.2 Java EEアプリケーションでのCSF APIの使用

- 21.7 例

- 21.7.1 CSF操作の共通コード

- 21.7.2 例1: ウォレット・ストアを使用するJava SEアプリケーション

- 21.7.3 例2: ウォレット・ストアを使用するJava EEアプリケーション

- 21.7.4 例3: OID LDAPストアを使用するJava EEアプリケーション

- 21.7.5 例4: Oracle DBストアを使用するJava EEアプリケーション

- 21.8 ベスト・プラクティス

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

- 22.1 ユーザーおよびロールAPIフレームワークの概要

- 22.1.1 ユーザーおよびロールAPIとOracle WebLogic Serverの認証プロバイダ

- 22.2 ロールとクラスの要約

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

- 22.3.1 サービス・プロバイダの理解

- 22.3.2 環境の設定

- 22.3.2.1 Jarの構成

- 22.3.2.2 jps-config.xml内のユーザー・クラス(Oracle Virtual Directoryのみ)

- 22.3.2.3 プロバイダ・ユーザーの読取り権限(Oracle Internet Directoryのみ)

- 22.3.3 プロバイダの選択

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

- 22.3.5 プロバイダの構成プロパティ

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

- 22.3.5.2 ECID伝播

- 22.3.5.3 構成の値を渡すタイミング

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

- 22.3.6.1 Oracle Internet Directoryプロバイダ

- 22.3.6.2 既存のロガー・オブジェクトの使用

- 22.3.6.3 定数値の指定

- 22.3.6.4 接続パラメータの構成

- 22.3.6.5 カスタム接続プール・クラスの構成

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

- 22.3.8 実行時の構成

- 22.3.9 プログラミングの考慮事項

- 22.3.9.1 プロバイダの移植性に関する考慮事項

- 22.3.9.2 IdentityStoreオブジェクト使用時の考慮事項

- 22.3.10 プロバイダのライフサイクル

- 22.4 リポジトリの検索

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

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

- 22.4.3 検索パラメータの指定

- 22.4.4 検索フィルタの使用

- 22.4.4.1 検索フィルタの演算子

- 22.4.4.2 検索フィルタ使用時の特殊文字の処理

- 22.4.4.3 ログイン・ユーザー用の検索フィルタ

- 22.4.4.4 検索フィルタの使用例

- 22.4.5 GUIDによる検索

- 22.5 ユーザー認証

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

- 22.6.1 アイデンティティ作成時の特殊文字の処理

- 22.6.2 アイデンティティの作成

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

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

- 22.7 ユーザーおよびロールAPIの使用例

- 22.7.1 例1: ユーザーの検索

- 22.7.2 例2: Oracle Internet Directoryストアにおけるユーザー管理

- 22.7.3 例3: Microsoft Active Directoryストアにおけるユーザー管理

- 22.8 LDAPベースのユーザーおよびロールAPIプロバイダのSSL構成

- 22.8.1 すぐに使用できるSSLのサポート

- 22.8.1.1 システム・プロパティ

- 22.8.1.2 SSL構成

- 22.8.2 ユーザーおよびロールAPIのSSLサポートのカスタマイズ

- 22.8.2.1 SSL構成

- 22.9 ユーザーおよびロールAPIリファレンス

- 22.10 カスタムのユーザーおよびロール・プロバイダの開発

- 22.10.1 SPIの概要

- 22.10.2 ユーザーおよびロール・プロバイダのタイプ

- 22.10.3 読取り専用プロバイダの開発

- 22.10.3.1 拡張が必要なSPIクラス

- 22.10.3.2 oracle.security.idm.spi.AbstractIdentityStoreFactory

- 22.10.3.3 oracle.security.idm.spi.AbstractIdentityStore

- 22.10.3.4 oracle.security.idm.spi.AbstractRoleManager

- 22.10.3.5 oracle.security.idm.spi.AbstractUserManager

- 22.10.3.6 oracle.security.idm.spi.AbstractRoleProfile

- 22.10.3.7 oracle.security.idm.spi.AbstractUserProfile

- 22.10.3.8 oracle.security.idm.spi.AbstractSimpleSearchFilter

- 22.10.3.9 oracle.security.idm.spi.AbstractComplexSearchFilter

- 22.10.3.10 oracle.security.idm.spi.AbstractSearchResponse

- 22.10.4 フル機能プロバイダの開発

- 22.10.5 開発のガイドライン

- 22.10.6 テストと検証

- 22.10.7 例: アイデンティティ・プロバイダの実装

- 22.10.7.1 サンプル・プロバイダについて

- 22.10.7.2 実装の概要

- 22.10.7.3 サンプル・アイデンティティ・プロバイダの使用に向けたjps-config.xmlの構成

- 22.10.7.4 Oracle WebLogic Serverの構成

- ユーザーおよびロールSPIリファレンス

- oracle.security.idm.spi.AbstractUserProfile

- oracle.security.idm.spi.AbstractUserManager

- oracle.security.idm.spi.AbstractUser

- oracle.security.idm.spi.AbstractSubjectParser

- oracle.security.idm.spi.AbstractStoreConfiguration

- oracle.security.idm.spi. AbstractSimpleSearchFilter

- oracle.security.idm.spi.AbstractSearchResponse

- oracle.security.idm.spi.AbstractRoleProfile

- oracle.security.idm.spi.AbstractRoleManager

- oracle.security.idm.spi.AbstractRole

- oracle.security.idm.spi.AbstractIdentityStoreFactory

- oracle.security.idm.spi.AbstractIdentityStore

- oracle.security.idm.spi.AbstractComplexSearchFilter

23 アイデンティティ・ディレクトリAPIを使用した開発

- 23.1 アイデンティティ・ディレクトリAPIについて

- 23.1.1 機能の概要

- 23.2 クラスの概要

- 23.3 アイデンティティ・ディレクトリの構成

- 23.4 アイデンティティ・ディレクトリAPIの操作

- 23.4.1 アイデンティティ・ディレクトリAPIインスタンスの取得

- 23.4.2 ユーザーとグループに対するCRUD操作の実行

- 23.4.2.1 ユーザー操作

- 23.4.2.2 グループ操作

- 23.5 アイデンティティ・ディレクトリAPIの例

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

- 23.5.2 ユーザーの作成

- 23.5.3 ユーザーの取得

- 23.5.4 ユーザーの変更

- 23.5.5 ユーザーの簡易検索

- 23.5.6 ユーザーの複合検索

- 23.5.7 グループの作成

- 23.5.8 グループの取得

- 23.5.9 検索フィルタを使用したグループの取得

- 23.5.10 グループの削除

- 23.5.11 グループへのメンバーの追加

- 23.5.12 グループからのメンバーの削除

- 23.6 SSL構成

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

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

- 24.2 キーストア・サービスを使用したアプリケーション開発の概要

- 24.3 Javaセキュリティ・ポリシーのパーミッションの設定

- 24.3.1 パーミッション付与のガイドライン

- 24.3.2 パーミッション付与例1

- 24.3.3 パーミッション付与例2

- 24.3.4 パーミッション付与例3

- 24.4 キーストア・サービスの構成

- 24.5 キーストア・サービスAPIの使用

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

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

- 24.6 キーストア・サービスAPIの使用例

- 24.6.1 キーストア・サービス管理操作用のJavaプログラム

- 24.6.2 実行時のキーの読取り

- 24.6.2.1 キーストア・ハンドルの取得

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

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

- 24.6.3 ポリシー・ストアのセットアップ

- 24.6.4 構成ファイル

- 24.6.5 Java SE環境でのキーストア・サービスの使用について

- 24.7 ベスト・プラクティス

25 監査サービスを使用した開発

- 25.1 監査フローへのアプリケーションの統合

- 25.2 監査フレームワークへのアプリケーションの統合

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

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

- 25.4.1 デフォルトのアプリケーション監査登録

- 25.4.2 カスタム・アプリケーション監査登録

- 25.4.3 プログラム登録

- 25.5 管理サービスAPIの使用

- 25.5.1 監査メタデータの問合せ

- 25.5.2 監査ランタイム・ポリシーの表示と設定

- 25.6 監査イベントを記録するためのアプリケーション・コードの追加

- 25.6.1 監査クライアントAPI

- 25.6.2 システム権限の設定

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

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

第V部 付録

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

- A.1 トップレベルおよび第2レベルの要素階層

- A.2 下位レベルの要素

- <description>

- <extendedProperty>

- <extendedPropertySet>

- <extendedPropertySetRef>

- <extendedPropertySets>

- <jpsConfig>

- <jpsContext>

- <jpsContexts>

- <name>

- <property>

- <propertySet>

- <propertySetRef>

- <propertySets>

- <serviceInstance>

- <serviceInstanceRef>

- <serviceInstances>

- <serviceProvider>

- <serviceProviders>

- <value>

- <values>

B ファイルベースのアイデンティティ・ストアとポリシー・ストアのリファレンス

- B.1 system-jazn-data.xmlの要素の階層

- B.2 system-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>

- <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.2.1 Oracle Platform Security Servicesのイベントとその属性

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

- C.2 ビルトイン監査レポート

- C.2.1 監査レポート用のOracle Business Intelligence Publisherの設定

- C.2.1.1 Oracle Business Intelligence Publisherについて

- C.2.1.2 Oracle Business Intelligence Publisherのインストール

- C.2.1.3 Oracle Business Intelligence PublisherでのOracle Reportsの設定

- C.2.1.4 監査レポート・テンプレートの設定

- C.2.1.5 監査レポート・フィルタの設定

- C.2.1.6 Oracle Business Intelligence Publisherのスケジューラの構成

- C.2.2 監査レポートの編成

- C.2.3 監査レポートの表示

- C.2.4 Oracle Business Intelligence Publisherレポートの例

- C.2.5 監査レポートの詳細

- C.2.5.1 Oracle Business Intelligence Publisherの監査レポートのリスト

- C.2.5.2 Oracle Business Intelligence Publisherの監査レポートの属性

- C.3 監査レポートのカスタマイズ

- C.3.1 ビルトイン・レポートに対する拡張フィルタの使用

- C.3.2 カスタム・レポートの作成

- C.4 監査スキーマ

- C.5 監査のためのWLSTコマンド

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

- C.7 監査ファイルの命名およびロギング形式

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

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

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

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

- D.4 Microsoft Active Directoryのためのセキュアな接続

E スクリプトおよびMBeanプログラミングを使用した管理

- E.1 スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成

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

- E.2.1 サポートされるOPSS MBeansのリスト

- E.2.2 OPSS MBeanの起動

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

- E.3 アクセス制限

- E.3.1 注釈の例

- E.3.2 WebLogicロールへの論理ロールのマッピング

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

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

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

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

- F.2.1 ポリシー・ストアのプロパティ

- F.2.1.1 ポリシー・ストアの構成

- F.2.1.2 実行時ポリシー・ストアの構成

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

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

- F.2.4 LDAPベースのすべてのインスタンスに共通するプロパティ

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

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

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

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

G OPSS APIリファレンス

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

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

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

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

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

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

- I.3 結合ルールの削除

- I.4 結合アダプタの削除

- I.5 アダプタの可視性の変更

- I.6 Identity Virtualization Libraryに対するアクセス・ログの有効化

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

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

- J.1.1 ログ・ファイルとOPSSロガー

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

- J.1.1.2 一般的なログ・ファイル

- J.1.1.3 認可ロガー

- J.1.1.4 オフラインWLSTコマンド・ロガー

- J.1.1.5 その他のOPSSロガー

- J.1.1.6 ユーザーおよびロールAPIロガー

- J.1.1.7 監査ロガー

- J.1.1.8 Fusion Middleware Controlを使用したロガーの管理

- J.1.1.9 スクリプトを使用したロガーの管理

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

- J.1.2.1 jps.auth.debug

- J.1.2.2 jps.auth.debug.verbose

- J.1.2.3 認可プロセスのデバッグ

- J.1.3 セキュリティ・エラーの解決

- J.1.3.1 サンプル・ログ・エントリの理解

- J.1.3.2 Fusion Middleware Controlを使用したログの検索

- J.1.3.3 Fusion Middleware Controlを使用したメッセージ・コンテキストの識別

- J.1.3.4 Fusion Middleware Controlを使用したエラー・リスト・ファイルの生成

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

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

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

- J.2.3 再関連付けしたポリシー・ストアのポリシーの欠落

- J.2.4 移行の失敗

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

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

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

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

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

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

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

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

- J.4.1 コードソースの付与のトラブルシューティング

- J.4.2 パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致

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

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

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

- J.4.6 12c HA環境で認識されないアプリケーション・ポリシー

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

- J.5.1 組込みのLDAP認証プロバイダへの接続の失敗

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

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

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

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

- J.6 Oracle Business Intelligenceレポート作成のトラブルシューティング

- J.6.1 Oracle Business Intelligence Publisherの監査テンプレート

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

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

- J.7.1 ポリシー・ストアでの属性照合時の検索の失敗

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

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

- J.8.1 バイナリとポリシー・ストアのバージョンの非互換性

- J.8.2 ポリシー・ストアのバージョンの非互換性

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

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

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

- J.9.3 Oracle Internet Directoryの例外

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

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

- J.9.5.1 Oracle Internet Directory 10.1.4.3での特殊文字の使用

- J.9.5.2 特定の文字が含まれるXMLポリシー・ストア

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

- J.9.5.4 XMLポリシー・ストアでの改行文字の欠落

- J.9.6 無効な鍵サイズ

- J.10 追加のヘルプ

例一覧

- 8-1 virtualizeプロパティを設定しない複数のLDAPの構成

- 8-2 Oracle WebLogic Serverにおける単一のLDAP構成

- 8-3 Oracle WebLogic Serverにおける複数のLDAP構成

- 8-4 サード・パーティのアプリケーション・サーバーにおける複数のLDAP構成

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

- 22-1 名前によってユーザーを取得するための簡易フィルタ

- 22-2 言語プリファレンスによってユーザーを検索するための簡易フィルタ

- 22-3 先頭の文字による名前の複合フィルタ

- 22-4 先頭の文字を制限する複合フィルタ

- 22-5 出力付きの完全な検索

- 22-6 ログイン・ユーザーのアイデンティティの取得

- 22-7 ロール/グループ名の取得

- B-1 <jazn-policy>

- B-2 <jazn-policy>

図一覧

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

- 2-1 アプリケーション・ポリシーの論理モデル

- 8-1 OPSSアイデンティティ・ストア・サービス

- 11-1「キーの作成」ダイアログ

- 11-2「キーの作成」ダイアログ

- 13-1 監査アーキテクチャ

- 14-1 共通監査表とカスタム監査表

- 14-2 監査実表とコンポーネント表

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

- 16-2 HTTPコールを使用したアイデンティティ伝播

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

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

- 25-1 監査フレームワークへのアプリケーションの統合

表一覧

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

- 3-1 アイデンティティ・ストアのリポジトリと認証プロバイダ

- 5-1 基本的な管理セキュリティ・タスクとツール

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

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

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

- 8-2 JKSベースのキーストアを使用したSSL

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

- 14-1 実表IAU_BASEの属性

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

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

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

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

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

- 18-1 JpsFilterとJpsInterceptorのパラメータの概要

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

- 18-3 マージによりポリシーを移行するための設定

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

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

- 18-6 ポリシーを削除しないための設定

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

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

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

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

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

- 19-1 Idstoreのタイプ

- 22-1 ユーザーおよびロールAPIのクラスとインタフェース

- 22-2 LDAPアイデンティティ・プロバイダ・クラス

- 22-3 起動時のアイデンティティ・プロバイダ構成プロパティ

- 22-4 実行時のアイデンティティ・プロバイダ構成プロパティ

- 22-5 カスタム・プロバイダ向けに拡張するSPIクラス

- 22-6 AbstractSimpleSearchFilterのメソッド

- 22-7 複雑な検索フィルタのメソッド

- 23-1 アイデンティティ・ディレクトリAPIのクラス

- 25-1 監査登録サービスのパラメータ

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

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

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

- B-1 system-jazn-data.xmlの要素の階層

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

- C-2 Oracle Platform Security Servicesの主要なイベント

- C-3 アイデンティティ・ディレクトリ・サービスのイベント

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

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

- C-6 監査レポートのリスト

- C-7 監査レポートの属性

- C-8 監査スキーマ

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

- D-1 UserProfile.Propertyのユーザー属性

- D-2 LDAPディレクトリのロール属性の値

- D-3 デフォルト値 - Oracle Internet DirectoryおよびMicrosoft Active Directory

- D-4 デフォルト値 - Oracle Directory Server Enterprise EditionおよびNovell eDirectory

- D-5 デフォルト値 - OpenLDAPおよびOracle Virtual Directory

- D-6 デフォルト値 - Oracle WebLogic Server LDAP

- E-1 OPSS MBeansのリスト

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

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

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

- F-2 ポリシー・ストアのプロパティ

- F-3 実行時のポリシー・ストアのプロパティ

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

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

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

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

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

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

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

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

はじめに

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

対象読者

このガイドの利用者と想定されるのは、Oracle Platform Security Servicesを理解し使用しようとしている、熟練したJava開発者、管理者、デプロイ担当者およびアプリケーション・マネージャです。

このガイドの全体的な構成は、複数の部分に分けられており、それぞれ関連する主なトピックごとにまとめられています。第I部から第III部までは管理者向けの内容、第IV部は開発者を対象としたOPSSポリシー・モデルに関する情報、第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/technology/documentation/index.htmlを参照してください。

表記規則

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

規則

意味

太字

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

イタリック

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

固定幅

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

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

ここでは、このリリースで導入された最も重要な変更について説明します。

リリース12.1.2.0.0の新機能

リリース12.1.2.0.0で導入された機能およびドキュメントの変更は次のとおりです。

機能

このリリースで導入された機能は次のとおりです。

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

ドキュメント

このリリースで導入されたドキュメントの変更は次のとおりです。

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

- 監査レポートに関する様々なオプションについて説明しています。第15.1項を参照してください。

- 監査システムの属性およびイベントの詳細を参照できます。表C-1および表C-5を参照してください。

第I部

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

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

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

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

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

- 第4章「Oracle Platform Security Servicesのシナリオについて」

1 Oracle Platform Security Servicesの概要

Oracle Platform Security Services (OPSS)は、サポート対象のプラットフォームまたはスタンドアロン・アプリケーションにデプロイされるアプリケーションを保護するセキュリティ・プラットフォームです。

この章では、次の各項でこのプラットフォームの主な機能を紹介します。

- 第1.1項「Oracle Platform Security Servicesの概要」

- 第1.2項「OPSSアーキテクチャの概要」

- 第1.3項「Oracle ADFのセキュリティの概要」

- 第1.4項「管理者向けのOPSS」

- 第1.5項「開発者向けのOPSS」

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

1.1 Oracle Platform Security Servicesとは

OPSSは、エンタープライズ製品開発チーム、システム・インテグレータおよび独立系ソフトウェア・ベンダー向けに、Java SEアプリケーションおよびJava EEアプリケーションで使用できる、標準に基づいた移植可能でエンタープライズ・レベルの統合セキュリティ・フレームワークを提供します。

また、基盤となるセキュリティ・プラットフォームとして、WebLogic Server、Server Oriented Architecture (SOA)アプリケーション、Oracle WebCenter、Oracle Application Development Framework (ADF)アプリケーション、Oracle Entitlement ServerなどのOracle Fusion Middlewareにセキュリティを提供します。

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

FAQ、ホワイトペーパー、サンプル・コード、フォーラム・ディスカッションなど、OPSS関連のニュースは、http://www.oracle.com/technology/products/id_mgmt/opss/index.htmlを参照してください。

1.1.1 OPSSの主な機能

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

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

- 認証

- IDアサーション

- ファイングレインJAASパーミッションに基づいた認可

- アプリケーション・ポリシーの指定と管理

- 資格証明ストア・フレームワークを使用したシステム資格証明のセキュアな格納とアクセス

- キーストア・サービスを使用したキーと証明書のセキュアな格納とアクセス

- 監査

- ロール管理とロール・マッピング

- ユーザーおよびロールAPI

- ID仮想化

- セキュリティの構成と管理

- SAMLとXACML

- Oracle Security Developer Tools(暗号化ツールなど)

- ポリシー管理API

- Java Authorization Contract for Containers (JACC)

特定のOPSS機能の詳細は、このガイドの該当する章を参照してください。

WebLogic監査プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』のWebLogic監査プロバイダの構成に関する説明を参照してください。

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

OPSSは、Oracle WebLogic Serverアプリケーション・プラットフォームでサポートされています。

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

OPSSは、アプリケーション・サーバーのセキュリティとOracle Fusion Middlewareのセキュリティで構成されます。図1-1は、この2つのセキュリティ・フレームワークを組み合せた階層型アーキテクチャを示しています。

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

一番上のレイヤーにはOPSSセキュリティ・サービス、次のレイヤーにはサービス・プロバイダ、一番下のレイヤーには3種類の内の1つのリポジトリを使用するOPSSセキュリティ・ストアがそれぞれ含まれます。

セキュリティ・サービス・プロバイダ

セキュリティ・サービス・プロバイダ・インタフェース(SSPI)によって、Java EEコンテナ・セキュリティおよび環境に応じたリソースベースの認可が提供されます。

SSPIは、プラガブルなセキュリティ・プロバイダを実装するための一連のAPIです。これらのインタフェースを実装するモジュールをSSPIにプラグインすることで、カスタム認証や特定のロール・マッピングなどの特別なタイプのセキュリティ・サービスを提供できます。

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

Oracle Platform Security Services

Java Authorization (JAZN)機能には、資格証明ストア・フレームワーク(CSF)、共通監査フレームワーク(CAF)、キーストア・サービスおよびその他のコンポーネントが含まれます。また、SSPIと結合してOracle Platform Security Services (OPSS)を構成します。

1.2.1 OPSSの利点

OPSSには、次の利点があります。

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

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

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

- Oracle WebLogic Serverで認定済である

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

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

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

- 抽象レイヤー(宣言的API)による開発時間の最適化

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

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

- 管理者の作業の負荷軽減

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

OPSSは、SSPIとJPSを結合することで、アプリケーション・サーバーとOracleアプリケーションを単一の環境でシームレスに実行可能なフレームワークを提供します。

OPSSでは、Java EEアプリケーションおよびOracle Fusion Middlewareアプリケーション(Oracle WebCenterやOracle SOA Suiteなど)のセキュリティをサポートしています。

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

管理者は、OPSSを使用することで、大規模なエンタープライズ・アプリケーションを小規模な一定のツール・セットでデプロイし、それらのアプリケーションのセキュリティ全体を管理できます。OPSSにより、アプリケーション・コードを変更することなくセキュリティ構成を変更できるため、アプリケーション・セキュリティのメンテナンスが簡単になります。

Oracle WebLogic Serverでは、デフォルトで追加設定なしに、ユーザーとグループがその埋込みLDAPリポジトリに格納されます。なお、他の種類のLDAPリポジトリにあるアイデンティティ・データを使用するようにドメインを構成することもできます。このようなLDAPリポジトリとして、Oracle Internet Directory、Active Directory、Novell eDirectory、OpenLDAPなどがあります。さらに、Oracle WebLogic Serverでは、ここにあげていない他のLDAPサーバーで使用できる汎用的なデフォルトのLDAP認証プロバイダを提供しています。

ポリシーおよび資格証明は、特別な設定をしなくてもファイルベースのストアに格納されます。これらのストアは、Oracle Internet Directoryの支援を受けるLDAPリポジトリに移動(再関連付け)できます。

出荷時にはキーおよび証明書はファイルベースのキーストアに格納されていますが、データベースまたはLDAPリポジトリに再関連付けすることができます。

1.3 Oracle ADFのセキュリティの概要

Oracle ADFは、エンドツーエンドJava EEフレームワークです。これによって、追加設定なしで使用できるインフラストラクチャ・サービスと、視覚的で宣言的な開発エクスペリエンスが提供され、開発が簡素化されます。

Oracle ADFのセキュリティはJAASセキュリティ・モデルに基づいており、このモデルはOPSSを使用しています。Oracle ADFのセキュリティでは、ファイルベース、LDAPベースまたはDBベースのセキュリティ・ストアがサポートされ、OPSSが提供するパーミッションベースのファイングレイン認可が使用され、視覚的宣言的エディタおよびOracle ADFセキュリティ・ウィザードを使用することによってアプリケーション・セキュリティの構成が簡単になります。これらはすべてOracle JDeveloper 11gに用意されています(このガイドではこのツールに関する参照はすべて11gリリース用のものです)。

Oracle ADFのセキュリティの認可は、コンポーネント(フローとページ)の保護を可能にし、設計時にはOracle JDeveloperと統合されます。通常、セキュリティ機能のテストを実行する統合サーバーにアプリケーションをデプロイした場合は、実行時にOracle ADFのセキュリティの認可が可能です。

Oracle ADFアプリケーションの開発段階で、Oracle WebLogic Server管理コンソールを使用し、アプリケーションのデプロイ先とする特定のドメインで認証プロバイダを構成します。また、ファイルベースとしたポリシー・ストアをファイルjazn-data.xmlに格納します。デプロイの詳細は、第6.3.1項「テスト環境へのデプロイ」を参照してください。

要約すると、Oracle ADFのセキュリティによって提供されるものは次のとおりです。

- 詳細な宣言的セキュリティの制御

- セキュリティ・アーティファクトの視覚的宣言的開発

- ロール階層での簡素化したパーミッションの割当て

- EL(式言語)を使用したOracle ADFリソースへのアクセス

- 迅速な開発とテスト・サイクルを可能にするOracle JDeveloperとの統合

- リッチなWebユーザー・インタフェースと簡素化されたデータベース・アクセス

関連情報については、「シナリオ2: Oracle ADFアプリケーションの保護」を参照してください。

1.4 管理者向けのOPSS

アプリケーション・タイプに応じて、Oracle WebLogic管理コンソール、WLSTコマンド、Fusion Middleware ControlまたはOracle Entitlements Serverを使用してアプリケーション・セキュリティを管理するガイドラインは次のようになります。

- Java EEアプリケーションの場合は、セキュリティをOracle WebLogic管理コンソール、Oracle Entitlements ServerまたはWLSTコマンドで管理します。

- Oracle SOA、Oracle WebCenter、MDSおよびOracle ADFの各アプリケーションでは、Oracle WebLogic管理コンソールで認証を管理し、Fusion Middleware ControlおよびOracle Entitlements Serverで認可を管理します。

- OPSSに統合するJava EEアプリケーションの場合、Oracle WebLogic管理コンソールで認証を管理し、Fusion Middleware ControlおよびOracle Entitlements Serverで認可を管理します。

セキュリティ管理の詳細は、第5章「セキュリティ管理」を参照してください。

1.5 開発者向けのOPSS

この項では、次の各シナリオで、アプリケーションを保護するために一般的に使用される主なOPSS機能をまとめています。

- シナリオ1: Java EEアプリケーションのセキュリティ強化

- シナリオ2: Oracle ADFアプリケーションの保護

- シナリオ3: Java SEアプリケーションの保護

その他のユースケースについては、第16.2項「セキュリティ統合のユースケース」を参照してください。

1.5.1 シナリオ1: Java EEアプリケーションのセキュリティ強化

CSF、ユーザー/ロール、ポリシー管理などのOPSS APIを使用するようにJava EEアプリケーションを拡張できます。ユーザーの電子メール、電話、住所などのユーザー属性を取得するには、Identity Governance Framework APIまたはユーザー/ロールAPIを使用します。外部システム資格証明(ウォレットまたはLDAPベース・ストアに格納)を取得するには、CSF APIを使用します。認可ポリシー・データの管理には、ポリシー管理APIを使用します。アプリケーションのキーおよび証明書の管理にはキーストア・サービスAPIを使用します。

Oracle WebLogic Server上にデプロイされるサーブレット、JSP、EJBなどのJava EEアプリケーションは、認証と認可をファイルweb.xmlで指定することで宣言的に使用するように構成することも、isUserInRoleおよびisCallerInRoleのコールによってプログラム的に使用するように構成することもできます。

カスタムの認証プロバイダには、標準のBasic認証、フォーム認証、クライアント証明書認証の各方法があります。サーブレットとEJBの間の認証は、ユーザー・ロールとエンタープライズ・グループを使用して制御します。これらのロールとグループは通常、LDAPリポジトリ、データベースまたはカスタムの認証プロバイダに格納します。

1.5.2 シナリオ2: Oracle ADFアプリケーションの保護

Oracle Application Development Framework (ADF)は、Oracle JDeveloperに用意されているJava EE開発フレームワークであり、Java EEアプリケーションのインフラストラクチャを実装するコードの作成を最小限に抑えることで、アプリケーションの開発を簡素化します。その結果、アプリケーション機能に開発リソースを集中できるようになります。Oracle ADFでは、これらのインフラストラクチャの実装をOracle JDeveloperフレームワークの中で実現し、Java EEの視覚的宣言的な開発アプローチによる開発エクスペリエンスの向上を図っています。

Oracle ADFではOPSSが暗黙的に使用されるので、開発者は通常、OPSS APIを直接操作するコードを作成する必要はありませんが、当然のことながら、OPSS APIへの直接コールを使用することもできます。

Oracle ADFでは、まずコンテナ認証を使用し、それに続いてJAASベースの認可を使用することで、Oracle ADFリソースへのアクセスを制御します。これらの認可ポリシーでは、アプリケーション固有のロールおよびJAAS認可パーミッションを指定できます。Oracle ADFの接続資格証明は、資格証明ストアに安全に格納されます。

Oracle WebLogic Server上にデプロイしたOracle ADFアプリケーションおよびOracle WebCenterアプリケーションには、デフォルトで指定されているようなWebLogic認証プロバイダが組み込まれますが、シングル・サインオン・ソリューション(Oracle Access ManagerまたはOracle Application Serverシングル・サインオン)を組み込むこともできます。

また、アプリケーションでは、OPSSの機能である匿名ロールと認証ロールのサポート、ポリシー管理APIおよび資格証明ストア・フレームワークを任意に使用することが普通です。

これらのトピックの詳細は、次の各項を参照してください。

- 第2.3項「認証ロール」

- 第2.4項「匿名ユーザーとロール」

- 第3.2項「ポリシー・ストアの基本」

- 第3.3項「資格証明ストアの基本」

Oracle ADFアプリケーションを開発および保護する方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の第29章を参照してください。

1.5.3 シナリオ3: Java SEアプリケーションの保護

Java EEアプリケーションで機能するOPSS機能のほとんどはJava SEアプリケーションでも機能しますが、その扱いにはいくつかの違いがあります。この項では、それらの違いについて説明します。

OPSSサービスの開始

Java SEアプリケーションでは、任意のOPSSセキュリティ操作を起動する前に、OPSSメソッドAppSecurityContext.JpsStartup.start()を使用する必要があります。

構成

OPSS関連の構成ファイルおよびデータ・ファイルはすべて、ドメイン・ホームの構成ディレクトリに格納されます。たとえば、Java SE環境の構成ファイルは、デフォルトで次の場所にインストールされるファイルjps-config-jse.xmlで定義されています。

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

別の場所を指定するには、次のスイッチを使用します。

-Doracle.security.jps.config=pathToConfigFile

このファイルの構文は、ファイルjps-config.xmlの構文と同じです。このファイルは、WebLogicコンテナで実行するコードで使用します。詳細は、付録A「OPSS構成ファイル・リファレンス」を参照してください。

Java SEアプリケーションのセキュリティ構成の詳細は、第19章「OPSSを使用するためのJava SEアプリケーションの構成」を参照してください。

クラスパスで指定する必要のあるJAR

Java SEアプリケーションでOPSSサービスを使用できるようにするには、次のJARファイルを必ずクラスパスに追加します。このJARファイルは、Oracleのインストール・ホームのモジュール領域にあります。

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

ログイン・モジュール

Java SEアプリケーションでは標準のJAASログイン・モジュールを使用できます。ただし、WLS上で同じログイン・モジュールを使用する場合は、このログイン・モジュールを呼び出すカスタム認証プロバイダを実装します。SSPIインタフェースを使用すると、複数のカスタム認証プロバイダをWLSで統合できます。

Java SEアプリケーションでの使用にお薦めするログイン・モジュールはIdentityStoreログイン・モジュールです。このログイン・モジュールおよび他のログイン・モジュールの詳細は、第19.3.3項「ログイン・モジュール」を参照してください。

詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の「認証プロバイダ」を参照してください。

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

この章では、匿名ロール、認証ロール、ロール・マッピング、ロール・カテゴリなどのユーザーとロールの様々な特性について説明します。ここには、このマニュアルで使用されている用語の定義も含まれます。

OPSSでは、WebLogic管理コンソールで管理するOracle WebLogic Server認証プロバイダに認証を委任します。

この章は次の項に分かれています:

- 第2.1項「用語」

- 第2.2項「ロール・マッピング」

- 第2.3項「認証ロール」

- 第2.4項「匿名ユーザーとロール」

- 第2.5項「管理ユーザーとロール」

- 第2.6項「ユーザー・アカウントの管理」

- 第2.7項「プリンシパル名の比較ロジック」

- 第2.8項「ロール・カテゴリ」

プログラムによるユーザーとロールの管理の詳細は、第23章「アイデンティティ・ディレクトリAPIを使用した開発」を参照してください。

2.1 用語

この項では、OPSSのセキュリティ用語を定義します。

ユーザー

ユーザーまたはエンタープライズ・ユーザーとは、サービスにアクセスするエンド・ユーザーです。ユーザー情報は、アイデンティティ・ストアに格納されます。認証されたユーザーとは、資格証明が検証されているユーザーです。

匿名ユーザーとは、資格証明が検証されていない(したがって認証されていない)ユーザーのことであり、保護されていないリソースにのみアクセスを許可されます。匿名ユーザーはOPSS固有のユーザーで、アプリケーション側でその使用を有効化または無効化できます。匿名ユーザーのサポートの詳細は、第2.4項「匿名ユーザーとロール」を参照してください。

ロール

エンタープライズ・ロールまたはエンタープライズ・グループとは、ユーザーとその他のグループの集合です。それは階層にすることが可能です。つまり、グループには任意にネストされたグループ(そのグループ自体を除く)を追加できます。

Java EE論理ロールとは、Java EEアプリケーションで宣言的またはプログラム的に指定するロールです。アプリケーション・デプロイメント・ディスクリプタで定義され、通常、アプリケーション・コード内で使用されます。エンタープライズ・グループまたはユーザーにのみマップでき、アプリケーション・ロールには直接マップできません。

アプリケーション・ロールは、ユーザー、グループおよびその他のアプリケーション・ロールの集まりであり、階層構造にできます。アプリケーション・ロールはアプリケーション・ポリシーによって定義されます。Java EEコンテナに認識されるとは限りません。アプリケーション・ロールは、外部ロールに多対多でマッピングできます。たとえば、(アイデンティティ・ストアに格納されている)外部グループemployeeを、(あるストライプ内の)アプリケーション・ロールhelpdesk service requestにマッピングして、さらに(別のストライプ内の)アプリケーション・ロールself service HRにマッピングできます。

匿名ロールの詳細は、第2.4項「匿名ユーザーとロール」を参照してください。認証ロールの詳細は、第2.3項「認証ロール」を参照してください。

プリンシパル

プリンシパルとは、ポリシー内の認可が付与されるアイデンティティです。プリンシパルには、ユーザー、外部ロールまたはアプリケーション・ロールを指定できます。ほとんどの場合、アプリケーション・ロールを指定します。

アプリケーション・ポリシーとシステム・ポリシー

アプリケーション・ポリシーは、アプリケーション内でプリンシパルが実行を許可される権限セット(Webページの閲覧やレポートの変更など)を指定する機能ポリシーです。

アプリケーション・ポリシーの特徴を次に示します。

- プリンシパルを権限受領者として使用します。少なくとも1つのプリンシパルを割り当てる必要があります。

- 1つ以上の権限または資格を使用できますが、その両方は使用できません。
資格を使用するポリシーは資格に基づくポリシーと呼ばれ、1つ以上の権限を使用するポリシーはリソースに基づくポリシーと呼ばれます。

システム・ポリシーは、プリンシパルまたはコード・ソースが実行を許可される権限セットを指定するポリシーで、ドメイン全体に適用されます。システム・ポリシーではコード・ソースとプリンシパルに権限が付与されますが、アプリケーション・ポリシーではプリンシパルのみに権限を付与できます。複数の権限を指定したソース・コード・システム・ポリシーの例は、第18.5.6項「サポートされているパーミッション・クラス」を参照してください。

アプリケーション・ポリシーおよびシステム・ポリシーは、アプリケーションのjazn-data.xmlファイルにパッケージ化されます。このファイルでは、システム・ポリシーは、アプリケーションの有効範囲外として定義する必要があります。

図2-1は、アプリケーション・ポリシー・モデルを示しています。

図2-1 アプリケーション・ポリシーの論理モデル

OPSSサブジェクト

OPSSサブジェクトとは、プリンシパルのコレクションで、多くの場合ユーザーの資格証明(パスワード、暗号キーなど)も含まれます。サーバー認証では、サブジェクトにユーザーおよびグループを移入した後、サブジェクトにアプリケーション・ロールを追加します。OPSSサブジェクトは、OAMなどの他のOracle Identity Management製品を使用したID伝播で重要になります。匿名データの処理方法の詳細は、第2.4.1項「匿名サポートとサブジェクト」を参照してください。

セキュリティ・ストア

アイデンティティ・ストアとは、エンタープライズ・ユーザーとグループのリポジトリで、LDAPベースにする必要があります。追加設定なしで使用できるアイデンティティ・ストアは、WebLogic LDAP DefaultAuthenticatorです。その他のタイプのアイデンティティ・ストアには、Oracle Internet Directory、Sun Directory Server、Oracle Virtual Directoryなどがあります。

ポリシー・ストアとは、アプリケーション・ポリシーおよびシステム・ポリシーのリポジトリです。このストアは、Oracle Enterprise Manager Fusion Middleware Controlで管理します。

資格証明ストアとは、資格証明のリポジトリです。このストアは、Oracle Enterprise Manager Fusion Middleware Controlで管理します。

OPSSセキュリティ・ストアとは、システムやアプリケーションに固有のポリシー、資格証明、監査メタデータ、およびキーが格納される論理リポジトリです。サポートされているタイプは、LDAPベースのOPSSセキュリティ・ストアではOracle Internet Directoryのみで、DBベースのOPSSセキュリティ・ストアではOracle Databaseのみです。

詳細は、第3章「アイデンティティ、ポリシー、資格証明、キー、証明書および監査の理解」を参照してください。

その他の用語

システム・コンポーネントとは、WebLogicコンポーネント以外の管理可能なプロセスです。たとえば、Oracle Internet Directory、WebCache、Java SEコンポーネントなどがあります。

Javaコンポーネントとは、システム・コンポーネントの一種ですが、その管理はアプリケーション・サーバー・コンテナで行います。通常は、ドメイン拡張テンプレートと1対1の関係にある、アプリケーションおよびリソースの集合を表します。たとえば、Oracle SOAアプリケーションやOracle WebCenter Spaceなどがあります。

2.2 ロール・マッピング

OPSSでは、OPSSセキュリティ・ストアにあるアプリケーション・ロールを、アイデンティティ・ストアにあるエンタープライズ・グループに多対多の関係でマッピングでき、このマッピングにより、アプリケーション・ロールでの指定に従って、エンタープライズ・グループのユーザーがアプリケーション・リソースにアクセスできます。このマッピングは多対多なので、ロール対グループ・マッピングまたはグループ対ロール・マッピングとも呼ばれています。

注意:

Oracle JDeveloperでは、その環境でアプリケーションを開発している段階でこのマッピングを指定できます。また、第10.2.2項「アプリケーション・ロールの管理」の説明に従って、アプリケーションのデプロイ後にWLSTコマンド、Fusion Middleware ControlまたはOracle Entitlements Serverを使用してマッピングを指定することもできます。

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

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

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

重要:

ロール階層を構築するときは、望ましくない動作を防止するために、循環依存を使用しないでください。たとえば、ロールAをロールBのメンバーに設定し、ロールBをロールAのメンバーに設定すると、このような循環依存が生成されます。

ロール階層では、ロールのメンバーは親ロールからパーミッションを継承します。つまり、ロールAがロールBのメンバーである場合、ロールBに付与されているすべてのパーミッションがロールAにも付与されます。当然のことながら、ロールAは、それ自体の特定のパーミッションを持っていますが、ロールBのメンバーとなることにより、ロールBに付与されているすべてのパーミッションを継承します。

WLSTコマンドによるアプリケーション・ロール階層の管理方法の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のgrantAppRoleに関する説明およびrevokeAppRoleに関する説明を参照してください。

Oracle Entitlements Serverによるアプリケーション・ロール階層の管理方法の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

次の例は、ネストしたアプリケーション・ユーザーとロールで構成したロール階層を示しています。

- ロール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 認証ロール

OPSSでは、特別なロールである認証ロールの使用がサポートされています。このロールには次の特性があります。

- 構成ファイルで宣言する必要がありません。

- 認証が成功した後、必ず、サブジェクトに関連付けられているプリンシパルとして表されます。つまり、認証されたすべてのユーザーにデフォルトで付与されます。

- サブジェクト内における認証ロールの存在は、匿名ロールと相互に排他的です。つまり、(a)サブジェクトが認証を受けていない場合は、「匿名サポートとサブジェクト」の説明のように、サブジェクトにはプリンシパルと匿名ロールが含まれます。(b)サブジェクトが正常に認証された場合は、認証ロールが含まれるほか、構成によっては匿名ロールも含まれます。

- アプリケーション・ロールです。したがって、あらゆるアプリケーションで使用でき、アプリケーションのロール階層に追加できます。

認証ロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。

認証ロールの一般的な用途は、共通のアプリケーション・リソース、つまり認証されたユーザーが利用できるリソースへのアクセスを、認証されたユーザーに許可することです。

認証されたロールの使用をアプリケーション側で手動で構成する方法の詳細は、第18.2項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

2.4 匿名ユーザーとロール

OPSSでは、匿名ユーザーと匿名ロールという、2つの特殊なエンティティを使用できます。認証ロールと同様に、これらのエンティティを宣言する必要はなく、アプリケーションによってJpsFilterまたはJpsInterceptorでその使用が構成されます。これらのどのエンティティも、アプリケーションのロール階層内でアプリケーションによって使用できます。

この匿名のエンティティを有効にしておくと、認証されていないユーザーが非保護リソースにアクセスするとき、そのユーザーは匿名ユーザーと匿名ロールのみが移入されたサブジェクトで表されます。そのサブジェクトが保護されたリソースにアクセスを試みた場合、認可過程でサブジェクトは「匿名サポートとサブジェクト」の説明のように処理されます。

匿名ユーザーおよびロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。

匿名ユーザーおよびロールの一般的な用途は、認証されていないユーザーにパブリックな非保護リソースへのアクセスを許可することです。

匿名ユーザーおよび匿名ロールの使用をアプリケーション側で手動で構成する方法の詳細は、第18.2項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

2.4.1 匿名サポートとサブジェクト

この項では、全体を通じて匿名ユーザーおよび匿名ロールの使用が有効になっていることを前提とします。

エンドユーザーが初めて非保護リソースにアクセスした場合、サブジェクトが作成され、そのサブジェクトに匿名ユーザーと匿名ロールに対応した2つのプリンシパルが移入されます。非保護リソースに関するかぎり、そのサブジェクトは変更されず認証は行われません。

保護されたリソースにそのサブジェクトがアクセスすると認証が始まり、この時点までは匿名ロールのみを持っていたサブジェクトが、認証プロセスの結果に応じて次のように変更されます。

認証に成功した場合は次のようになります。

1. 匿名ユーザーがサブジェクトから削除され、必要に応じて、認証されたユーザーに置換されます。

2. 匿名ロールは削除され、認証ロールが追加されます。

3. その他のロールが、必要に応じてサブジェクトに追加されます。

認証に成功すると、サブジェクトには、非匿名ユーザーに対応した1つのプリンシパル、認証ロールに対応した1つのプリンシパル、および場合によってはエンタープライズ・ロールまたはアプリケーション・ロールに対応した他のプリンシパルが含まれるようになります。

認証が成功しなかった場合は、匿名ユーザーが保持されます。匿名ロールは、アプリケーションによるJpsFilterまたはJpsInterceptorの構成に応じて削除または保持されます。他のプリンシパルは追加されません。デフォルトでは、匿名ロールはサブジェクトから削除されます。

2.5 管理ユーザーとロール

(WebLogic)管理者は、グループAdministratorsのユーザー・メンバーであり、このグループにはセキュリティ・レルムに存在している任意のユーザーを追加できます。

セキュリティ・レルムに存在するデフォルト・グループの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループ、セキュリティ・ロール」を参照してください。

通常、管理者にはデフォルト名はありません。唯一の例外は実行例をインストールした場合で、その際はサンプル・ドメインの管理者のデフォルト・ユーザー名とパスワードが提供されます。ただし、これらの例は本番環境では使用しないでください。

詳細は、『Oracle WebLogic Server本番環境の保護』のWebLogic Serverのセキュアなインストールに関する説明を参照してください。

ドメインを構成すると、Administratorsグループのメンバーは、セキュリティ・レルムに作成されたユーザーを、いつでもAdministratorsグループに追加したりグループから削除することができます。これらのアカウントを管理するための2つの基本ツールが、Oracle WebLogic管理コンソールとOracle WebLogic Scripting Tool (WLST)です。

詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのグループへのユーザーの追加に関する説明および『WebLogic Scripting Toolの理解』の「WebLogic Scripting Toolの使用」を参照してください。

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

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

- パスワード作成の一般的なガイドラインは、Oracle WebLogic Server管理コンソール・オンライン・ヘルプのユーザーおよびグループの管理に関する説明を参照してください。デフォルトの認証プロバイダでは、8文字以上の長さのパスワードが必要ですが、これは構成可能です。
パスワードの作成に関するいくつかの推奨事項は、『Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護に関する説明を参照してください。

- 一般的に、パスワードは、LDAPサーバーまたはRDBMSに格納されます。これらのパスワードが格納される特定の場所は、環境(正確にはドメインのセキュリティ・レルム)内で構成された固有の認証プロバイダによって決定されます。追加設定なしで使用できる認証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』の「組込みLDAPサーバーの管理」を参照してください。

- カスタマイズ可能なパスワード作成ルールを適用するパスワード検証プロバイダを、パスワードを作成したときに自動的にコールできるオプションがあります。このオプションの構成方法は、『Oracle WebLogic Serverセキュリティの管理』のパスワード検証プロバイダの構成に関する説明を参照してください。

- ユーザーの追加または削除の際は、第J.4.4項「ユーザーによる予期しないパーミッションの取得」の説明にある推奨事項を考慮してください。

2.7 プリンシパル名の比較ロジック

この項では、プリンシパルの比較がOPSS認可に及ぼす影響とプリンシパル名の比較ロジックを制御するシステム・パラメータについて説明します。この項の内容は次のとおりです。

- プリンシパルの比較が認可に及ぼす影響

- プリンシパル名の比較を制御するシステム・パラメータ

2.7.1 プリンシパルの比較が認可に及ぼす影響

ユーザーが適切に認証されると、そのユーザーについてアイデンティティ・ストアに格納されているユーザー名およびエンタープライズ・グループ名(ユーザーが所属するエンタープライズ・グループ名)と一致するプリンシパルを持つサブジェクトが移入されます。

これに対し、ユーザー(またはエンタープライズ・グループ)を認可する必要がある場合は、アプリケーション・ロールがエンタープライズ・グループにどのようにマップされているかがシステムで考慮され、OPSSセキュリティ・ストアに格納されているアプリケーション権限の名前から別のプリンシパルが構築されます。

プリンシパルを認可するために、サブジェクトに(アイデンティティ・ストアで検出された名前から)移入されたプリンシパル名とOPSSセキュリティ・ストアの名前から構築されたプリンシパル名が比較されます。これらのプリンシパル名が一致した場合にのみ、そのユーザー(またはグループ)が認可されます。

したがって、想定どおりにプリンシパル名が機能するには、認可プロバイダでプリンシパル名を適切に比較することが重要です。

たとえば、アイデンティティ・ストアに格納されているユーザー名が「jdoe」であるのに対し、権限付与のユーザー名は「Jdoe」であるとします。この場合は、大文字と小文字を区別せずにプリンシパル名を比較するように指定する必要があります。そうしないと、「jdoe」と「Jdoe」という名前から構築されたプリンシパルは一致せず(この2つの名前が異なると認識され)、「jdoe」が想定どおりには認可されなくなります。

2.7.2 プリンシパル名の比較を制御するシステム・パラメータ

次の2つのWebLogic Serverシステム・パラメータを使用すると、プリンシパル名をドメイン内で比較する方法を制御でき、さらにDNデータとGUIDデータを使用してプリンシパルを比較できます。

PrincipalEqualsCaseInsensitive (True or False; False by default)
PrincipalEqualsCompareDnAndGuid (True or False; False by default)

WebLogic Serverコンソールを使用してこれらのパラメータを設定する手順は、次のとおりです。

1. 「コンソール」の左側ペインにある「ドメイン構造」で、前述のパラメータを設定するドメインを選択します。

2. 「構成」→「セキュリティ」を選択し、「詳細」をクリックします。

3. 必要に応じて、次のエントリをtrueまたはfalseに設定します。

- Principal Equalsの大文字/小文字を区別しない

- Principal EqualsでDNとGUIDを比較

4. サーバーを再起動します。サーバーが再起動するまで、変更は有効になりません。

WLSTコマンドを使用してこれらのパラメータを設定することもできます。WebLogic Serverの構成の詳細は、『Oracle WebLogic Serverセキュリティの管理』のJAAS認可を使用するためのドメインの構成に関する説明を参照してください。

実行時に選択した名前の比較ロジックは、次の擬似コードで記述できます。

if PrincipalEqualsCompareDnAndGuid is true
//use GUID and DN to compare principals
{
when GUID is present in both principals {
use case insensitive to compare GUIDs
}
when DN is present in both principals {
use case insensitive to compare DNs
}
}

if PrincipalEqualsCaseInsensitive is true
//use just name to compare principals
{
use case insensitive to compare principal names
}
else
{
use case sensitive to compare principal names
}

デフォルトではPrincipalEqualsCompareDnAndGuidとPrincipalEqualsCaseInsensitiveがfalseに設定されているので、プリンシパル名の比較では大文字と小文字が区別されます。

2.8 ロール・カテゴリ

ロール・カテゴリを使用すると、セキュリティ管理者はアプリケーション・ロールを編成できます。管理者は、アプリケーション内のロールのフラット・リストを表示するかわりに、それらのロールを任意のフラット・セットやカテゴリに編成できます。ロール・カテゴリは、フラット・セットです。つまり、ロール・カテゴリには階層構造は含まれていません。

Oracle Entitlements Serverによるアプリケーション・ロール・カテゴリの管理方法の詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

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

<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を使用して管理できます。

RoleCategoryManagerインタフェースの詳細は、Javadocドキュメントの『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』を参照してください。

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

アプリケーションでは、それを実行しているドメインで構成されたアイデンティティ・ストア、ポリシー・ストア、資格証明ストア、キーストアおよび監査リポジトリを使用します。この章では、アイデンティティ、ポリシー、資格証明、キーストアおよび監査のデータに関する基本概念について説明します。また、セキュリティ・アーティファクトの互換バージョンを示したマトリクスも提示します。

この章は次の項に分かれています:

- 第3.1項「認証の基本」

- 第3.2項「ポリシー・ストアの基本」

- 第3.3項「資格証明ストアの基本」

- 第3.4項「キーストア・サービスの基本」

- 第3.5項「監査サービスの基本」

この章で使用する用語の定義は、第2.1項「用語」を参照してください。

ストアの利用法を示すシナリオは、第4章「Oracle Platform Security Servicesのシナリオについて」を参照してください。

3.1 認証の基本

OPSSではサーバー認証プロバイダを使用します。この認証プロバイダは、ユーザー名とパスワードの組合せまたはデジタル証明書に基づき、ユーザーの資格証明またはシステム・プロセスを検証するコンポーネントです。認証プロバイダには、必要に応じ、ドメイン内の他のコンポーネントでサブジェクトを介してユーザー・アイデンティティ情報を使用できるようにする機能もあります。

Java EEアプリケーションでは、LDAPベースまたはDBベースの認証プロバイダが使用されます。Java SEアプリケーションでは、追加設定なしで使用できるファイル・ベースのアイデンティティ・ストアが使用されますが、LDAPベースまたはDBベースの認証プロバイダも使用するよう構成できます。

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

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

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

- WebLogic認証プロバイダ

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

この項の情報は、Java EEアプリケーションにのみ適用されます。Java SEアプリケーションでの認証の使用の詳細は、第19.3.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」を参照してください。

次のリストでは、アイデンティティ・ストアでサポートされるリポジトリを列挙しています(最後のものを除き、すべてLDAPベースとなっています)。

- Oracle Internet Directory 11g

- Oracle Virtual Directory

- Open LDAP 2.2

- Oracle Unified Directory 11gR1

- Oracle Directory Server Enterprise Edition 11.1.1.3.0

- Sun DS 6.3、7.0

- Novell eDirectory 8.8

- Tivoli Access Manager

- Active Directory

- Active Directory AM

- Active Directory 2008

- Oracle DB 10g、11gR1、11gR2

Open LDAP 2.2には、特別な設定が必要です(詳細は、付録H「OpenLDAPアイデンティティ・ストアの使用」を参照してください)。

Oracle Internet Directoryサーバーにおける参照整合性のサポートについては、第9.2項「LDAPベースのOPSSセキュリティ・ストアの使用」の重要事項を参照してください。

次の表は、各リポジトリで使用するWebLogic認証プロバイダを示しています。

表3-1 アイデンティティ・ストアのリポジトリと認証プロバイダ

ストア・タイプ

WebLogic認証プロバイダ

Oracle Internet Directory 11g

OracleInternetDirectoryAuthenticator

Oracle Virtual Directory

OracleVirtualDirectoryAuthenticator

Open LDAP 2.2

OpenLDAPAuthenticator

Oracle Unified Directory 11gR1

iPlanetAuthenticator

Oracle Directory Server Enterprise Edition 11.1.1.3.0

iPlanetAuthenticator

Sun DS 6.3、7.0

iPlanetAuthenticator

Novell eDirectory 8.8

NovellAuthenticator

Tivoli Access Manager

OpenLDAPAuthenticator

Active Directory

ActiveDirectoryAuthenticator

Active Directory AM

ActiveDirectoryAuthenticator

Active Directory 2008

ActiveDirectoryAuthenticator

Oracle DB 10g、11gR1、11gR2

CustomDBMSAuthenticator

ReadOnlySQLAuthenticator

SQLAuthenticator

WebLogicコンソールを使用して新規認証プロバイダを作成および構成するには、次の手順を実行します。

1. 新しい認証者を作成します。詳細は、この手順の次に示しているトピックのリストを参照してください。
特定のアイデンティティ・ストア・リポジトリと表3-1に基づいて、適切なWebLogic認証プロバイダを選択します。入力するパラメータは、選択した認証プロバイダによって異なります。たとえば、次のサンプルに示しているように、OidAuthenticatorの場合は、ホスト情報を入力します。

host name: example.com
port: 5555
principal: cn=orcladmin
credential: myPassword
user base DN: cn=Users,dc=us,dc=oracle,dc=com
group base DN: cn=Groups,dc=us,dc=oracle,dc=com

2. 入力内容を保存して、新規認証プロバイダを作成します。

3. 作成した認証プロバイダに適切な制御フラグを設定します。

4. 必要に応じて、ドメイン内の認証プロバイダのリストを並べ替えます。

5. WebLogicサーバーを再起動します。

重要:

DefaultAuthenticatorを除き、ドメインで使用するすべてのLDAPベースの認証プロバイダでは、フラグUseRetrievedUserNameAsPrincipalを設定する必要があります。DefaultAuthenticatorでは、追加設定なしでこのフラグが設定されています。

WebLogic認証プロバイダの詳細は、次のトピックを参照してください。

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

- 『Oracle WebLogic Serverセキュリティの管理』の「認証プロバイダの構成」、およびOracle WebLogic Server管理コンソール・オンライン・ヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する説明

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する説明

3.1.2 WebLogic認証プロバイダ

追加設定がない状態のOracle WebLogic Serverでは、ユーザーとグループがデフォルトでDefaultAuthenticatorに格納されます。この認証プロバイダは、デフォルト属性としてcnを使用するように設定されています。

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

この項には次のトピックが含まれます:

- 複数の認証プロバイダ

- その他の認証方式

X.509 IDアサーションの詳細は、『Oracle WebLogic Serverセキュリティの管理』のLDAP X509 IDアサーション・プロバイダの仕組みに関する説明を参照してください。

SAML 1.1またはSAML 2.0 IDアサーション・プロバイダを使用した認証の詳細は、『Oracle WebLogic Serverセキュリティの管理』のSAML認証プロバイダの構成に関する説明を参照してください。

3.1.2.1 複数の認証プロバイダ

Oracle WebLogic Serverでは、特定のコンテキストで複数の認証プロバイダを構成できます。そのうちの1つは、LDAPベースの認証プロバイダとする必要があります。

OPSSでは、構成済の認証プロバイダのリストから次のアルゴリズムに従って選択したLDAP認証プロバイダを使用して、アイデンティティ・ストア・サービスを初期化します。

1. 構成されているLDAP認証プロバイダのサブセットを検討します。コンテキストではLDAP認証プロバイダが1つ以上指定されていることが前提なので、このサブセットは空ではありません。

2. そのサブセットの中で、最大のフラグが設定されている認証プロバイダを検討します。このサブセットでの計算に使用するフラグの順序は次のとおりです。

REQUIRED > REQUISITE > SUFFICIENT > OPTIONAL

このサブセット(最大のフラグを実現するLDAPのサブセット)も空ではありません。

3. そのサブセットの中から、該当のコンテキストで最初に構成された認証プロバイダを検討します。

ステップ3で選択したLDAP認証プロバイダを、アイデンティティ・ストア・サービスの初期化に使用します。LDAP認証プロバイダを使用してSSL接続を確立する際のホスト名検証の詳細は、『Oracle WebLogic Server本番環境の保護』を参照してください。

サポートされている様々なLDAP認証プロバイダの初期化にOPPSが使用するデフォルト値の詳細は、第G.1項「OPSS APIリファレンス」のユーザーおよびロールAPIに関する説明を参照してください。サービス・インスタンスの初期化値が、デフォルトでもサービス・インスタンスの構成でも(明示的に)提供されている場合は、構成された値がデフォルト値よりも優先されます。

3.1.2.2 その他の認証方式

WebLogic IDアサーション・プロバイダでは、X.509証明書、SPNEGOトークン、SAMLアサーション・トークンおよびCORBA Common Secure Interoperability version 2 (CSIv2) IDアサーションを使用した証明認証がサポートされています。

ネゴシエート・アイデンティティ・プロバイダは、SPNEGOプロトコルをサポートするMicrosoftクライアントでSSOに使用します。このプロバイダは、SPNEGOトークンをデコードしてKerberosトークンを取得し、このKerberosトークンを検証してWebLogicユーザーにマップします。

IDアサーション・プロバイダの一般情報は、『Oracle WebLogic Serverセキュリティの理解』のIDアサーション・プロバイダに関する説明を参照してください。

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

Kerberos IDの詳細は、『Oracle WebLogic Serverセキュリティの管理』のWebLogic Server用のKerberos IDの作成に関する説明を参照してください。

3.2 ポリシー・ストアの基本

Java 2ポリシーは、特定の場所からロードされた署名付きコードに付与されるパーミッションを指定します。

JAASポリシーは、オプションのプリンシパル・リストを指定できるようにすることで、Java 2の権限を拡張します。これにより、特定の場所からロードされた(場合によって署名付きの)コードが、指定のプリンシパルで表されるユーザーによって実行された場合にのみ、そのコードにパーミッションのセマンティックが付与されます。

JACCは、カスタム認可プロバイダ(実行中のJava EEアプリケーションに付与される認可の制御とカスタマイズを可能にするプラガブル・コンポーネント)とのインタフェースを定義することで、Java 2およびJAASのパーミッションベースのポリシーをEJBおよびサーブレットに拡張します。

アプリケーション・ポリシーは、Java 2ポリシーとJAASポリシーの集合です。Java 2ポリシーはJVM全体に適用されるのに対して、JAASポリシーは該当のアプリケーションにのみ適用されます。

ポリシー・ストアは、システムおよびアプリケーションに固有のポリシーとロールを格納するリポジトリです。アプリケーション・ロール(管理ロールなど)には、アプリケーション固有のエンタープライズ・ユーザーおよびグループを指定できます。ポリシーでは、これらのグループまたはユーザーをプリンシパルとして使用できます。

ロールを自己管理するアプリケーションの場合は、Java EEアプリケーション・ロール(ファイルweb.xmlまたはejb-jar.xmlで構成)がエンタープライズ・ユーザーおよびグループにマップされ、アプリケーション固有のポリシーで使用されます。

ポリシー・ストアのタイプ

ポリシー・ストアはファイルベース、LDAPベース、またはDBベースにすることができます。ファイルベースのポリシー・ストアはXMLファイルであり、このストアは即時利用できるポリシー・ストア・プロバイダで表されます。LDAPベースのポリシー・ストア・タイプは、Oracle Internet Directoryのみでサポートされています。DBベースのポリシー・ストア・タイプは、Oracle RDBMSのみでサポートされています。

ポリシー・ストアのスコープ、移行、および再関連付け

1つのドメインに1つのポリシー・ストアがあります。開発段階では、アプリケーション・ポリシーはファイルベースで、ファイルjazn-data.xmlで指定します。

Fusion Middleware Controlを使用してアプリケーションをWebLogicにデプロイすると、ポリシー・ストアに自動的に移行することができます。この機能の詳細は、第9.6.1項「Fusion Middleware Controlを使用した移行」を参照してください。デフォルトでは、ポリシー・ストアはファイル・ベースになります。

再関連付けの詳細は、第9.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

注意:

パーミッション・クラスはすべて、システム・クラスパスで指定する必要があります。

ポリシー・ストアでのリソース・カタログのサポートの詳細は、第17.3.1項「リソース・カタログ」を参照してください。

3.3 資格証明ストアの基本

資格証明ストアは、ユーザー、Javaコンポーネントおよびシステム・コンポーネントの認証レベルを認定するセキュリティ・データ(資格証明)のリポジトリです。資格証明には、ユーザー名とパスワードの組合せ、チケットまたは公開鍵証明書を格納できます。このデータは、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。

OPSSは資格証明ストア・フレームワークを備えています。これは、アプリケーションで資格証明を安全に作成、読取り、更新および管理する際に使用できる一連のAPIです。

資格証明ストアのタイプ

資格証明ストアは、ファイルベース、LDAPベース、またはDBベースにすることができます。ファイルベースの資格証明ストアはウォレットベースとも呼ばれ、ファイルcwallet.ssoで表される、追加設定なしで使用できる資格証明ストアです。LDAPベースの資格証明ストア・タイプは、Oracle Internet Directoryでのみサポートされています。DBベースの資格証明ストア・タイプはOracle RDBMS(リリース10.2.0.4以降、リリース11.1.0.7以降、およびリリース11.2.0.1以降)でのみサポートされています。

資格証明ストアのスコープ、移行、および再関連付け

アプリケーションでは、ドメイン資格証明ストアを使用できる他、ウォレットベースの独自の資格証明ストアを使用できます。ドメイン資格証明ストアは、ウォレットベース(デフォルト)、LDAPベース、またはDBベースにすることができます。LDAPベースの資格証明ストア・タイプは、Oracle Internet Directoryでのみサポートされています。

アプリケーションがデプロイされるときに、アプリケーションの資格証明が自動的に資格証明ストアに移行されるように構成することができます。詳細は、第9.6.1項「Fusion Middleware Controlを使用した移行」を参照してください。

あるタイプのストアから別のタイプのストアに、資格証明を再び関連付けることもできます。詳細は、第9.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

3.4 キーストア・サービスの基本

キーストア・サービスは、ドメインのコンポーネントおよびアプリケーションによって使用されるすべてのキーと証明書を含むキーストアおよびトラスト・ストアに対する中央リポジトリを提供します。これにより、キーストアを個々のアプリケーションに関連付ける必要がなくなります。

管理者は単一のユーザー・インタフェースを使用して、一貫した方法ですべてのキーストアを表示および管理できます。

3.4.1 キーストア・リポジトリのタイプ

中央リポジトリには次のものを使用できます。

- XMLファイルベース
これが出荷時のキーストア・リポジトリであり、名前はkeystores.xmlです。

注意:

このファイルはインストール直後には存在せず、管理サーバーを初めて起動したときに作成されます。

- Oracle Database

- Oracle Internet Directory(注意: これ以外のLDAPサーバーはサポートされていません。)

関連項目:

キーストア・サービスの詳細は、第12章を参照してください。

3.4.2 キーストア・リポジトリのスコープと再関連付け

ドメイン・キーストア・リポジトリ内のキーおよび証明書は、1つのタイプから別のタイプへと関連付けを変更できます。詳細は、第9.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

3.5 監査サービスの基本

監査サービスでは、ドメインの監査レコードの中央リポジトリがサポートされます。管理者は、監査サービスを有効に活用して、構成の変更をはじめ、コンポーネントおよびデプロイ済アプリケーションに対する操作アクティビティによってトリガーされるイベントを監査できます。

監査リポジトリのタイプ

監査レコードのリポジトリは次のいずれかになります。

- ファイルベース

- Oracle Database

関連項目:

監査サービスの詳細は、第13章を参照してください。

4 Oracle Platform Security Servicesのシナリオについて

この章では、Oracle Platform Security Servicesでサポートされているいくつかの一般的なセキュリティ・シナリオについて説明します。また、サポートされているLDAPサーバー、DBサーバー、XMLサーバーや、各シナリオで管理者がセキュリティ・データを管理するために使用する管理ツール、さらに、ポリシーおよび資格証明に対するパッケージ要件についても取り上げます。

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

- 第4.1項「サポートされているファイルベース、LDAPベースおよびDBベースのサービス」

- 第4.2項「管理ツール」

- 第4.3項「パッケージ要件」

- 第4.4項「シナリオの例」

- 第4.5項「その他のシナリオ」

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

Oracle Platform Security Servicesでは、次のリポジトリがサポートされています。

- OPSSセキュリティ・ストアでは、次のようになります。

- ファイルベース(OPSSセキュリティ・ストアの場合はXML、資格証明ストアの場合はcwallet)。

- LDAPベース。Oracle Internet Directory(バージョン10.1.4.3または11g)を使用できます。

- DBベース。Oracle RDBMS(リリース10.2.0.4以降、リリース11.1.0.7以降およびリリース11.2.0.1以降)を使用できます。

- アイデンティティ・ストアでは、Oracle WebLogic ServerでサポートしているあらゆるLDAP認証プロバイダを使用できます。XMLアイデンティティ・ストアは、Java SEアプリケーションでのみサポートされています。

- キーストアでは、次のようになります。

- ファイルベース。XMLファイルを使用できます。

- LDAPベース。Oracle Internet Directory(バージョン10.1.4.3または11g)を使用できます。

- DBベース。Oracle RDBMS(リリース10.2.0.4以降、リリース11.1.0.7以降およびリリース11.2.0.1以降)を使用できます。

重要:

Oracle Internet Directory 10.1.4.3をOPSSとともに使用する場合は、Oracle Bug#8351672に対する必須の個別パッチをOracle Internet Directory 10.1.4.3に適用する必要があります。様々なバージョンのOracle Internet Directoryについて、適用する必要のあるパッチのリストは、第9章「LDAPベースのOPSSセキュリティ・ストアの使用」を参照してください。

最適なパフォーマンスを確保するには、Oracle Internet Directoryを次のようにチューニングすることをお薦めします。

ldapmodify -D cn=orcladmin -w <password> -v <<EOF
dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory
changetype: modify
add: orclinmemfiltprocess
orclinmemfiltprocess: (objectclass=orcljaznpermission)
orclinmemfiltprocess: (objectclass=orcljazngrantee)
EOF

LDAP認証プロバイダの詳細は、『Oracle WebLogic Serverセキュリティの管理』のLDAP認証プロバイダの構成に関する説明を参照してください。特に、DefaultAuthenticatorは追加設定なしで使用できますが、その使用は、ユーザーが10,000以下およびグループが2,500以下の開発環境に限定することをお薦めします。

1つのLDAPベースのストアに格納されているポリシー、資格証明およびキーは、同一の物理永続リポジトリを使用する必要があります。詳細は、次の各章を参照してください。

- 第10章「ポリシー・ストアの管理」

- 第11章「資格証明ストアの管理」

- 第12章「キーストア・サービスでのキーと証明書の管理」

4.2 管理ツール

セキュリティ管理者が使用できるツールは、次のとおりです。

- WebLogic管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle Entitlements Server

- WLSTコマンド

- LDAPサーバー固有のユーティリティ

セキュリティ・データの管理に使用するツールは、格納するデータのタイプと、そのデータの保持に使用するストアの種類に応じて異なります。

ユーザーおよびグループ

DefaultAuthenticatorを使用してアイデンティティを格納するドメインでは、Oracle WebLogic Server管理コンソールを使用して、格納したデータを管理します。DefaultAuthenticatorに格納したデータにユーザー/ロールAPIを使用してアクセスし、ユーザー・プロファイル属性を問い合せたり、ユーザーまたはグループに追加属性を挿入したりできます。

重要:

ドメインでDefaultAuthenticatorを使用する場合は、アプリケーションでユーザー/ロールAPIを使用してアイデンティティ・データを操作できるように、ドメイン管理サーバーを実行している必要があります。

また、デフォルトの認証プロバイダとは異なる他のLDAPサーバー、またはDBを認証に使用する場合は、そのLDAPサーバーのサービスを使用してユーザーとグループを管理します。

ポリシー、資格証明、キーおよび証明書

ポリシー、キーおよび資格証明は、同じ種類の記憶域(ファイルベース、LDAPベース、またはDBベース)を使用する必要があり、LDAPベースの場合は、同じLDAPサーバー(Oracle Internet Directoryに限る)、DBベースの場合は、同じDB (Oracle DB)を使用する必要があります。

ポリシーおよび資格証明データを管理するには、第10.2項「Fusion Middleware Controlを使用したポリシーの管理」および第11.3項「Fusion Middleware Controlを使用した資格証明の管理」の説明に従ってFusion Middleware Controlを使用するか、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」および第11.4項「WLSTコマンドを使用した資格証明の管理」の説明に従ってWLSTコマンドを使用します。

また、ポリシー・データを管理するには、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの説明に従って、Oracle Entitlements Serverを使用します。

キーと証明書を管理するには、Fusion Middleware ControlおよびWLSTを使用します。詳細は、第12章「キーストア・サービスでのキーと証明書の管理」を参照してください。

セキュリティ・データの管理で使用する各種ツールを次にあげます。

- アイデンティティ・データ

- デフォルトの認証プロバイダ: 管理コンソールを使用

- その他のLDAPまたはDBストア: LDAPサーバーまたはDBに用意されているユーティリティを使用

- ポリシーおよび資格証明データ

- ファイルベース: Fusion Middleware ControlまたはWLSTコマンドを使用

- LDAPベース: Fusion Middleware Control、WLSTコマンドまたはOracle Entitlements Serverを使用

- キーと証明書

- WLSTコマンドの使用

ポリシー、資格証明またはキーを変更してもサーバーを再起動する必要はありません。ファイルjps-config.xmlを変更した場合はサーバーを再起動する必要があります。

注意:

一般に、ドメインの構成を変更した場合はサーバーを再起動する必要があります。ただし、ドメイン・データを変更してもサーバーを再起動する必要はありません。ドメインの構成の変更の一例として、ドメイン・ストアの再関連付けがあります。

アプリケーションのデプロイ時に、アプリケーションのポリシーと資格証明をドメイン・ストアに自動的に移行する方法の詳細は、第9.6項「OPSSセキュリティ・ストアの移行」を参照してください。

4.3 パッケージ要件

ファイルベースのアプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションとパッケージ化するためにサポートされている唯一の方法は、このファイルをEARファイルのディレクトリMETA-INFに置くことです。

ファイルベースのアプリケーション資格証明は、ファイルcwallet.ssoで定義します。このファイルをアプリケーションとパッケージ化するためにサポートされている唯一の方法は、このファイルをEARファイルのディレクトリMETA-INFに置くことです。詳細は、第18.4項「Java EEアプリケーションの手動によるパッケージ化」を参照してください。

WebLogicへのデプロイの詳細は、第6章「セキュア・アプリケーションのデプロイ」を参照してください。

注意:

Oracle JDeveloperでEARファイルを生成すると、必要なすべてのファイル(および適切なセキュリティ構成)とともに、セキュアなOracle ADFアプリケーションのEARファイルが自動的にパッケージ化されます。

4.4 シナリオの例

この項で解説するシナリオでは、ほとんどのOracle ADFアプリケーション、Oracle WebCenterおよびWeb Services Manager Controlで採用されているセキュリティ機能について説明します。

これらのシナリオでは、アプリケーションで次の特性を持つセキュリティ・スキームが採用されていると想定しています。

- 認証: WebLogicのデフォルトの認証プロバイダを使用してユーザーおよびグループを格納します。

- 認可: アプリケーションとパッケージ化されたファイルベースのポリシーおよび資格証明によってサポートされ、ポリシーおよび資格証明ストア(ファイルベースまたはLDAPベース)によってもサポートされているファイングレインJAAS認可を使用します。

ファイングレインJAAS認可を必要とするOracle ADFやOracle SOAなどのアプリケーションによって、これらのセキュリティ・スキームのいずれかが採用されていることが普通です。このような場合、個々のセキュリティ・コンポーネントは適切なツールで管理されます。

次のシナリオは、これらの想定に基づいた、基本的なテーマに対する一般的なバリエーションです。ただし、このリストですべてのバリエーションを取り上げているわけではありません。

関連ドキュメント

デフォルトの認証プロバイダの構成に関する詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する説明を参照してください。

OPSSセキュリティ・ストアの構成方法の詳細は、第9章「OPSSセキュリティ・ストアの構成」を参照してください。

ポリシー管理の詳細は、第10章「ポリシー・ストアの管理」を参照してください。

資格証明管理の詳細は、第11章「資格証明ストアの管理」を参照してください。

キーストア・サービスの管理の詳細は、第12章「キーストア・サービスでのキーと証明書の管理」を参照してください。

一般的なシナリオ1

このシナリオでは、開発中のJava EEアプリケーションを示します。

認証: このアプリケーションではデフォルトの認証プロバイダを使用します。これは、開発環境では一般的な扱いです。

認可: ポリシー・ストアと資格証明ストアはファイルベースです。

バリエーション: このアプリケーションでは、SSOおよびJava EEセキュリティに対するWebLogicサポートを使用します。

SSOに対するWebLogicサポートの詳細は、『Oracle WebLogic Serverセキュリティの管理』の「WebブラウザおよびHTTPクライアントを使用したシングル・サインオンの構成」を参照してください。

一般的なシナリオ2

このシナリオでは、開発中のJava EEアプリケーションを示します。

認証: このアプリケーションではデフォルトの認証プロバイダを使用します。これは、開発環境では一般的な扱いです。

認可: ポリシー・ストアと資格証明ストアは、LDAPベースであり、Oracle Internet Directory LDAPサーバーの同じインスタンスのサービスを使用します。

バリエーション: JAASは有効化されており、ポリシーには匿名ロールおよび認証ロールのパーミッションが含まれています。

匿名ロールおよび認証ロールのサポートの構成の詳細は、第2.3項「認証ロール」および第2.4項「匿名ユーザーとロール」を参照してください。

一般的なシナリオ3

このシナリオでは、開発中のJava EEアプリケーションを示します。

認証: このアプリケーションではデフォルトの認証プロバイダを使用します。これは、開発環境では一般的な扱いです。

認可: ポリシー・ストアと資格証明ストアは、LDAPベースであり、Oracle Internet Directory LDAPサーバーの同じインスタンスのサービスを使用します。

バリエーション: このアプリケーションではJava EEセキュリティを使用し、JAASは有効化します。ポリシーには匿名ロールおよび認証ロールのパーミッションを設定します。また、ポリシーの問合せ、取得および管理には、資格証明ストア・フレームワーク(CSF) APIが使用されます。

匿名ロールおよび認証ロールのサポートの構成の詳細は、第2.3項「認証ロール」および第2.4項「匿名ユーザーとロール」を参照してください。

CSF APIの詳細は、第21.1項「資格証明ストア・フレームワークAPIについて」を参照してください。

4.5 その他のシナリオ

次のシナリオでは、アプリケーション開発段階で一般的に使用するDefaultAuthenticatorではない認証プロバイダまたはなんらかのAPIをアプリケーションで使用して、セキュリティ・データにアクセスします。

シナリオ4

認証: このアプリケーションでは、DefaultAuthenticatorではないLDAP認証プロバイダを使用します。

認可: このアプリケーションでは、Oracle Internet Directory LDAPベースのストアを使用します。

バリエーション: このアプリケーションでは、DBのユーザー・プロファイルへのアクセスにユーザー/ロールAPIを使用し、資格証明へのアクセスに資格証明ストア・フレームワーク(CSF) APIを使用します。

CSF APIの詳細は、第21.1項「資格証明ストア・フレームワークAPIについて」を参照してください。

シナリオ5

認証: このアプリケーションでは、テスト環境および本番環境で一般的なOracle Internet Directory LDAP認証プロバイダを使用します。

認可: ポリシー・ストアと資格証明ストアは、ファイルベースであり、アプリケーションとパッケージ化されます。これらのデータは、デプロイ時に自動的にドメイン・セキュリティ・データにマップされます。

バリエーション: デプロイ後、一方向SSL伝送チャネルで構成したLDAPベースのストアに、ポリシー・ストアおよび資格証明ストアを再度関連付けします。

デプロイ時に、アプリケーションのセキュリティ・データを自動的に移行する方法の詳細は、第9.6項「OPSSセキュリティ・ストアの移行」を参照してください。

再関連付けの詳細は、第9.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

SSLの構成の詳細および関連トピックは、次のサイトを参照してください。

- 『Oracle WebLogic Serverセキュリティの管理』の「SSLの構成」。

- 『Oracle Fusion Middlewareの管理』。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのSSLの設定に関する説明。

- 『WebLogicセキュリティ・サービスによるアプリケーションの開発』の「Java ClientでのSSL認証の使用」。

シナリオ6

このシナリオでは、OPPS APIを使用するJava SEアプリケーションを示します。

認証: このアプリケーションでは、LoginService APIを使用します。

認可: このアプリケーションではメソッドCheckPermissionを使用します。

また、このアプリケーションでは、ドメイン認証プロバイダへの属性の問合せにユーザー/ロールAPIを使用し、資格証明ストアへの問合せに資格証明ストア・フレームワークAPIを使用します。

第II部

OPSSの基本的な管理

この部では、次の各章でOPSSの基本的な管理機能について説明します。

- 第5章「セキュリティ管理」

- 第6章「セキュア・アプリケーションのデプロイ」

5 セキュリティ管理

この章では、セキュリティ管理者が使用できるツール、およびアプリケーションのセキュリティを管理するために必要な一般的なタスクについて説明します。

これらについては次の項で説明します。

- 第5.1項「テクノロジに応じた管理ツールの選択」

- 第5.2項「基本的なセキュリティ管理タスク」

- 第5.3項「Fusion Middleware Controlを使用した一般的なセキュリティ操作」

- 第5.4項「管理コンソールを使用した一般的なセキュリティ操作」

- 第5.5項「Oracle Entitlements Serverを使用した一般的なセキュリティ操作」

- 第5.6項「WLSTコマンドを使用した一般的なセキュリティ操作」

高度な管理タスクは、付録E「スクリプトおよびMBeanプログラミングを使用した管理」を参照してください。

5.1 テクノロジに応じた管理ツールの選択

セキュリティ管理者が使用できる基本ツールは、Oracle Enterprise Manager Fusion Middleware Control、Oracle WebLogic管理コンソール、Oracle Entitlements ServerおよびOracle WebLogic Scripting Tool (WLST)の4点です。これらのツールおよびその他のツールの詳細は、『Oracle Fusion Middlewareの管理』の第3章「Oracle Fusion Middlewareの管理の開始」を参照してください。

アプリケーションのセキュリティ管理に使用するツールを決定する基準は、そのアプリケーションでコンテナ管理セキュリティ(Java EEアプリケーション)のみを使用するのか、Oracle ADFのセキュリティ(Oracle ADFアプリケーション)も扱うのかという点です。

Oracle Application Development Framework (Oracle ADF)アプリケーション、Oracle Server Oriented Architecture (SOA)アプリケーション、WebCenterアプリケーションなどのOracle固有のアプリケーションのデプロイ、保護およびメンテナンスにはFusion Middleware ControlおよびOracle Entitlements Serverを使用します。

サード・パーティが開発したアプリケーション、Java SEアプリケーション、Java EEアプリケーションなどその他のアプリケーションのデプロイ、保護および管理には、Oracle WebLogic管理コンソールまたはWLSTを使用することが普通です。

Javaアプリケーションを開発するための推奨ツールは、Oracle JDeveloper 11gです。このツールは、専用のグラフィカル・エディタによって、開発者によるファイルベースのアイデンティティ・ストア、ポリシー・ストアおよび資格証明ストアの構成を支援します。特に、Oracle ADFアプリケーションを開発する際は、開発者はウィザードを実行してOracle ADFリソースに関連付けられたWebページに対するセキュリティ(Oracle ADFタスク・フローやページ定義など)を構成し、ファイルjazn-data.xml専用の視覚的なエディタを使用してセキュリティ・アーティファクトを定義できます。

手順の詳細と関連トピックは、Oracle JDeveloperオンライン・ヘルプ・ドキュメントの次の項を参照してください。

- Oracle ADFのセキュリティを使用したWebアプリケーションの保護に関する項

- Java EE Securityを使用したWebアプリケーションの保護に関する項

- セキュリティ制約に対する代替としてのOracle ADFのセキュリティに関する項

- Webアプリケーションの保護に関する項

Oracle ADFのセキュリティおよびそれとOracle JDeveloperとの統合の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』のOracle ADFのセキュリティの設計時ツールへのアクセスに関する説明を参照してください。

Oracle Entitlements Serverの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

5.2 基本的なセキュリティ管理タスク

表5-1は、いくつかの基本的なセキュリティ・タスクとそれらを実行するために使用するツールのリストです。アプリケーションのセキュリティの構成と管理に使用するツールは、アプリケーションのタイプに応じて選択します。コンテナ管理セキュリティのみを使用するJava EEアプリケーションの場合は、Oracle WebLogic管理コンソールを使用します。OPSS認可を使用するOracle ADFアプリケーションの場合は、Fusion Middleware ControlとOracle Entitlements Serverを使用します。

次に示すツールを使用せずに手動で設定することはお薦めしません。Oracle WebLogic管理コンソールを使用する方法は、次の表に続いて示す各リンクを参照してください。Oracle Entitlements Serverの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

5-1 基本的な管理セキュリティ・タスクとツール

タスク

Fusion Middleware Controlの「セキュリティ」メニューで選択する項目

その他のツール

WebLogicドメインの構成

WebLogic管理コンソール

WebLogicセキュリティ・レルムの構成

WebLogic管理コンソール

WebLogicドメイン認証プロバイダの管理

WebLogic管理コンソール

MSクライアント、WebブラウザおよびHTTPクライアントに対するSSOの有効化

WebLogic管理コンソール

ドメイン管理アカウントの管理

WebLogic管理コンソール

アイデンティティ・ストア・サービスの構成

WebLogic管理コンソール

Oracle ADFアプリケーションに対する資格証明の管理

資格証明

Oracle ADFアプリケーションでの匿名ロールの有効化

セキュリティ・プロバイダ構成

Oracle ADFアプリケーションでの認証ロールの有効化

セキュリティ・プロバイダ構成

Oracle ADFアプリケーションでのJAASの有効化

セキュリティ・プロバイダ構成

Oracle ADFアプリケーションでのエンタープライズ・グループへのアプリケーション・グループのマップ

アプリケーション・ロールまたは
アプリケーション・ポリシー

Oracle Entitlements Server

Oracle ADFアプリケーションでのシステム全体のポリシーの管理

システム・ポリシー

OPSSのプロパティの構成

セキュリティ・プロバイダ構成

ポリシーおよび資格証明ストアの再関連付け

セキュリティ・プロバイダ構成

前述のタスクのためのOracle WebLogic管理コンソールの使用方法の詳細は、次のドキュメントを参照してください。

- 管理コンソールの一般的な使用については、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

- WebLogicドメインを構成する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverドメイン構成の理解』を参照してください。

- WebLogicセキュリティ・レルムを構成する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の新しいセキュリティ・レルムの作成および構成の主要な手順に関する項を参照してください。

- WebLogicドメイン認証プロバイダを管理する方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の第5章を参照してください。

- MSクライアントでSSOを構成するには、『Oracle WebLogic Serverセキュリティの管理』の第6章を参照してください。

- ドメイン管理アカウントを管理する方法は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の第6章を参照してください。

- LDAPアイデンティティ・ストアの構成の詳細は、第3.1.2項「WebLogic認証プロバイダ」を参照してください。

注意:

OPSSでは、サーバー・ファイルの自動バックアップおよび自動リカバリはサポートされません。サーバー管理者が、必要に応じてすべてのサーバー構成ファイルを定期的にバックアップすることをお薦めします。

Oracle Fusion Middlewareのバックアップよびリカバリの詳細は、『Oracle Fusion Middlewareの管理』の第15章「バックアップおよびリカバリの導入」を参照してください。

5.2.1 新しい本番環境の設定

既存の環境に基づいた新しい本番環境は、次の方法で設定できます。

- Oracleクローニング・ユーティリティを使用して、構築済の環境をレプリケートします。詳細は、『Oracle Fusion Middlewareの管理』の第9.5項にあるOracle Fusion Middlewareエンティティのクローニングに関する説明を参照してください。

- 構築済の環境を設定したときと同様にソフトウェアを再インストールし、環境を構成します。

5.3 Fusion Middleware Controlを使用した一般的なセキュリティ操作

Fusion Middleware Controlは、アプリケーションのネットワークの管理を1か所でできるようにするWebベースのツールです。Oracle SOAアプリケーション、Oracle ADFアプリケーション、Oracle WebCenter、およびOPSSを使用するその他のOracleアプリケーションのデプロイ、構成、監視、診断および監査にFusion Middleware Controlを使用します。この項では、セキュリティ関連の操作についてのみ説明します。

Fusion Middleware Controlでは、いくつかのセキュリティ関連管理タスクを使用できます。このツールを使用すると、管理者は次を実行できます。

- インストール後にアプリケーションをデプロイする前に、ポリシーと資格証明ストアを再度関連付けます。詳細は、第9.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。

- インストール後、アプリケーションをデプロイする前にOPSSのプロパティを定義します。詳細は、第9.7項「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

- デプロイ時に、ファイルベースのアプリケーション・ポリシーおよび資格証明からLDAPベースのドメイン・ポリシーおよび資格証明への自動的な移行を構成します。
詳細は、次の各項を参照してください。

- 第6.3項「テスト環境へのOracle ADFアプリケーションのデプロイ」

- 第9.6項「OPSSセキュリティ・ストアの移行」

- アプリケーションのデプロイ後、そのアプリケーションで次のタスクを実行できます。

- アプリケーション・ポリシーの管理。詳細は、第10.1項「ポリシー・ストアの管理」を参照してください。

- 資格証明の管理。詳細は、第11章「資格証明ストアの管理」を参照してください。

- アプリケーション・ロールからユーザー、グループおよびアプリケーション・ロールへのマッピングの指定。詳細は、第10.2.2項「アプリケーション・ロールの管理」を参照してください。

- ドメインについて、システム・ポリシーを管理します。詳細は、第10.2.3項「システム・ポリシーの管理」を参照してください。

- ドメインについて、OPSSプロパティを管理します。詳細は、第9.7項「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

セキュリティ管理タスクの要約およびこれらのタスクの実行に使用するツールは、「基本的なセキュリティ管理タスク」を参照してください。

その他の機能の詳細は、Fusion Middleware Controlオンライン・ヘルプ・ドキュメントを参照してください。

5.4 管理コンソールを使用した一般的なセキュリティ操作

Oracle WebLogic管理コンソールは、Webベースのツールであり、いくつかある機能の中でも特に、アプリケーションのデプロイと再デプロイ、ドメインの構成およびアプリケーション・ステータスの監視ができます。この項では、セキュリティ関連の操作についてのみ説明します。

Oracle WebLogic管理コンソールで実行する一般的なタスクは、次のとおりです。

- Oracle WebLogicサーバーの起動と停止。詳細は、『Oracle WebLogic Serverサーバーの起動と停止の管理』の「サーバーの起動と停止」を参照してください。

- Oracle WebLogicサーバーおよびドメインの構成。詳細は、『WebLogic Scripting Toolの理解』の既存のドメインの構成に関する説明を参照してください。

- アプリケーションのデプロイ。詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

- フェイルオーバー・サポートの構成。詳細は、『Oracle WebLogic Serverクラスタの管理』の「クラスタにおけるフェイルオーバーおよびレプリケーション」を参照してください。

- WebLogicドメインおよびWebLogicレルムの構成。

- ドメイン認証プロバイダでのユーザーおよびグループの管理。

- MSクライアント、WebブラウザおよびHTTPクライアントに対するシングル・サインオンの使用の有効化。

- 管理ユーザーおよび管理ポリシーの管理。

Oracle WebLogic管理コンソールの詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプを参照してください。

5.5 Oracle Entitlements Serverを使用した一般的なセキュリティ操作

Oracle Entitlements Serverで実行する一般的なセキュリティ・タスクは、次のとおりです。

- アプリケーションのセキュリティ・アーティファクトの検索。

- ポリシーなどの、アプリケーションのセキュリティ・アーティファクトの管理。

- 外部のロールの階層の表示。

- アプリケーション・ロールの階層の管理。

Oracle Entitlements Serverによるアプリケーションのセキュリティ管理に最も頻繁に使用するセキュリティ・タスクのリストは、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

5.6 WLSTコマンドを使用した一般的なセキュリティ操作

Oracle WebLogic管理コンソールで使用可能なセキュリティ関連操作のほとんどを、WLSTコマンドを使用して実行できます(WLSTコマンドは、ドメインの構成やアプリケーションのデプロイメントなどの管理タスクのスクリプティングおよび自動化を可能にする一連のコマンドライン・インタフェースです)。

注意:

WLSTシェル・セッションは、一意の構成ファイルに関連付けられ、一般的には、JVMインスタンスは最大限で1つの構成ファイルを指すことができます。

JVMインスタンスごとに一意のjps-config.xmlファイルが必要であるという点から、1つのWLSTシェル内で、特定の構成ファイルを取得する1つのWLSTコマンド(migrateSecurityStoreなど)を呼び出した場合、それに続いて同じWLSTシェル内で呼び出されるコマンドではすべて、コマンドに渡される構成の場所に関係なく、同じ構成ファイルが使用されます。

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

アプリケーションをOracle WebLogic Serverにデプロイするには、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware ControlまたはOracle JDeveloperのいずれかのツールを使用します。WebLogicサーバーに認識されている場所にビットを設定することによって、アプリケーションを起動することもできます。この場合、サーバーを再起動する必要はありません。このような種類のアプリケーション起動は、ホット・デプロイとして知られています。

アプリケーションをデプロイするための推奨方法は、プラットフォーム、アプリケーションのタイプ、およびそのアプリケーションが開発中フェーズと開発後フェーズのどちらのフェーズにあるかによって異なります。たとえば、開発後フェーズでは通常、ホット・デプロイを使用して本番環境でアプリケーションを起動します。

この章で説明する推奨事項は、Oracle ADFアプリケーションと、OPSSを使用するJava EEアプリケーションにのみ当てはまります。

開発時には、Oracle JDeveloperを使用してアプリケーションを組込みOracle WebLogic Serverにデプロイすることが普通です。テスト環境または本番環境に移行したアプリケーションは、通常、Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールあるいはホット・デプロイを使用してデプロイします。

この章では、Oracle ADFアプリケーションまたはPure Java EEアプリケーションのデプロイ時に実行する管理タスクを中心に説明します。最後の項では、アプリケーションを手動でパッケージ化する場合のみを対象として、セキュアJava EEアプリケーションのパッケージ要件について説明します。

これらについては次の項で説明します。

- 第6.1項「概要」

- 第6.2項「デプロイのためのツールの選択」

- 第6.3項「テスト環境へのOracle ADFアプリケーションのデプロイ」

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

- 第6.5項「監査機能を伴ったアプリケーションのデプロイ」

- 第6.6項「テスト環境から本番環境への移行」

補足ドキュメント

デプロイの詳細は、『Oracle Fusion Middlewareの管理』の第8章「アプリケーションのデプロイ」を参照してください。

デプロイ時のOracle ADFアプリケーションの保護の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

アプリケーション・ライフサイクルの詳細は、第16.7項「付録 - ADFアプリケーションのセキュリティ・ライフサイクル」を参照してください。

web.xmlやweblogic-application.xmlなど、アプリケーションのセキュリティ管理と構成に関連してEARファイルに含まれているファイルの詳細は、第18章「OPSSを使用するためのJava EEアプリケーションの手動構成」を参照してください。

6.1 概要

Oracle ADFアプリケーションをリモートのOracle WebLogic Serverにデプロイするまでの一般的な手順は次のとおりです。

- Oracle JDeveloperを使用して開発者がOracle ADFアプリケーションを開発し、その過程でOracle ADFセキュリティ・ウィザードを使用してOracle ADFのセキュリティを設定します。

- Oracle JDeveloperを使用し、テスト環境でのテスト・サイクルでアプリケーションの自動デプロイ先となる統合WebLogic Serverに、アプリケーションのユーザーとグループ、認可ポリシーおよび資格証明をコピーします。

- 開発者が、ポリシーと資格証明をパッケージ化した、アプリケーションのEARファイルを作成します。

- Fusion Middleware Controlを使用して、ドメイン管理者がこのEARファイルをリモートのOracle WebLogic Serverにデプロイします。

このフローを図示すると次のようになります。

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

この章で検討するアプリケーションのタイプは、Java EEアプリケーションです。Java EEアプリケーションは、さらにPure Java EEアプリケーションとOracle Fusion Middleware ADFアプリケーションに分類できます。この2種類のJava EEアプリケーションの相違点は、第1.5.1項「シナリオ1: Java EEアプリケーションのセキュリティ強化」および第1.5.2項「シナリオ2: Oracle ADFアプリケーションの保護」を参照してください。

表6-1は、開発したアプリケーションのデプロイに使用するツールをそのアプリケーションのタイプ別に示しています。

表6-1 開発したアプリケーションをデプロイするためのツール

アプリケーション・タイプ

使用するツール

Pure Java EEアプリケーション

Oracle WebLogic管理コンソール、Fusion Middleware Control。推奨するツールはOracle WebLogic管理コンソールです。

Oracle ADFアプリケーション

Fusion Middleware ControlまたはWLSTコマンド。推奨ツールはFusion Middleware Controlです。

6.2.1 Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ

この項では、Oracle ADFセキュリティを使用するアプリケーションまたはOPSSを使用するJava EEアプリケーションを、Fusion Middleware ControlによってWebLogicサーバーにデプロイする際に使用可能なセキュリティ構成を中心に説明します。

具体的には、デプロイ設定の3番目のステージで「アプリケーション・セキュリティの構成」ページに表示されるオプションについて説明します。

このページの外観は、EARファイルのパッケージ内容に応じて次のようになります。

- アプリケーション・ポリシーを設定したjazn-data.xmlをEARファイルにパッケージ化している場合は、アプリケーション・ポリシーの移行セクションが表示されます。

- cwallet.ssoに収めた資格証明をEARファイルにパッケージ化している場合は、資格証明の移行セクションが表示されます。

- 前述のいずれもEARファイルにパッケージ化していない場合、このページにはデフォルトのJava EEセキュリティ・オプションが表示されます。

このページには、ポリシーの移行セクションが表示されます。その一部を次に示します。

このページの設定は、該当のドメイン・ストアへのアプリケーション・ポリシーと資格証明(アプリケーションEARファイルにパッケージ化される)の移行に関連するものです。次では、これらの設定について説明します。

「アプリケーション・ポリシー移行」の設定

これらの設定では、次のシナリオでポリシーの移行を制御します。

- アプリケーションを初めてデプロイする場合、通常はOPSSセキュリティ・ストアにアプリケーション・ポリシーを移行します。そのためには、「アプリケーション・ポリシー移行」領域で「追加」を選択します。
なんらかの理由で移行しない場合は「無視」を選択します。オプションの「上書き」も使用できます。

- 以前のデプロイでアプリケーション・ポリシーを移行済であることを前提としてアプリケーションを再デプロイしている場合、パッケージ化したポリシーをドメイン内の既存のポリシーにマージするには「追加」を選択し、ポリシーを移行しないようにするには「無視」を選択します。
アプリケーションを再デプロイするときに、ドメインに設定した現在のアプリケーション・ポリシーを変更しない場合、つまり以前のデプロイの際に変更したOPSSセキュリティ・ストアの内容を保持する場合は、「無視」を選択します。

- 「追加」を選択すると、移行する権限とロールを指定できます。基本的な相違点は、ADFアプリケーションのロールと権限(本番環境で必要)と開発時のみのロールと権限(本番環境では不要)との差です。
ADFアプリケーションのロールと権限を移行して、開発時のみのセキュリティ・ロールと権限を移行しないようにするには、次のチェック・ボックスを選択します: アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。通常、本番環境へのデプロイ時には、このチェック・ボックスを選択します。このボックスを選択した場合は、アプリケーションをデプロイした後でそのアプリケーション・ロールをエンタープライズ・グループにマップする必要があります。

- 「追加」を選択した場合に、アプリケーション・ポリシーの移行先とする特定のストライプ(アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ)を指定するには、「アプリケーション・ストライプID」ボックスにそのストライプの名前を入力します。

アプリケーション・ストライプについて:

OPSSセキュリティ・ストアは、論理的に複数のストライプにパーティション化されており、ファイルsystem-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。各ストライプで、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。

一般的な使用例

このページでは、次の2つの一般的なシナリオで指定するポリシーの移行について説明します。

- EARファイル内の一貫性のない指定を解決する場合 - EARファイルに記述された指定が検証されます。web.application.xml、web.xmlおよびejb-jar.xmlの各ファイル(EARファイルにパッケージ化されているファイル)で指定されているアプリケーション・ストライプに一貫性がない(互いに一致しない)場合は、使用する新しいストライプ名を入力するか、ドロップダウン・リストから選択します。EARファイルにあるどの指定値より、ここで指定した値が優先され、その値が移行先として実行時環境で使用されます。

- 1つのアプリケーション・ストライプを複数のアプリケーションで共有できるようにする場合 - 既存のストライプ(別のアプリケーションで移入したストライプ)をアプリケーションで共有する場合は、そのストライプを指定できます。既存のアプリケーション・ストライプを共有している場合、「上書き」オプションの使用には注意が必要です。

- 何も指定しない場合のデフォルト設定は、「追加」(デプロイの場合)と「無視」(再デプロイの場合)です。

「アプリケーション資格証明移行」の設定

これらの設定では、次のシナリオで資格証明の移行を制御します。

- アプリケーションを初めてデプロイする場合、通常は資格証明ストアにアプリケーション資格証明を移行します。そのためには、「アプリケーション資格証明移行」領域で「追加」を選択します。

- いずれの場合も(初めてのデプロイでもその後のデプロイでも)、なんらかの理由で移行しない場合は「無視」を選択します。

注意:

資格証明の移行を無視すると、資格証明を使用するアプリケーション・コードが動作しない場合があります。通常は、マップとキーが同じで値が異なる資格証明を手動で作成するという前提の下で「無視」オプションを選択します。

- WebLogicサーバーを開発モードで稼働している場合にのみ、「上書き」オプションを使用できます。

- 何も入力しない場合は、デフォルトの「無視」になります。

6.3 テスト環境へのOracle ADFアプリケーションのデプロイ

Oracle ADFアプリケーションはJAAS認可を使用するJava EEアプリケーションで、通常はOracle JDeveloperを使用して開発し、テストします。この環境により、開発者はアプリケーションをパッケージ化し、このOracle JDeveloperと統合した組込みOracle WebLogic Serverにデプロイできます。テスト環境または本番環境にアプリケーションを移行するとき、デプロイにはOracle Fusion Middleware Controlを使用し、そのフレームワークで提供されるOracle ADFのセキュリティ機能すべてを活用します。詳細は、「概要」を参照してください。

Fusion Middleware Controlを使用してOracle ADFアプリケーションをデプロイする方法の具体的な手順は、次の項を参照してください。

- Oracle Fusion Middleware Controlのオンライン・ヘルプ・システムのFusion Middleware Controlを使用したアプリケーションのデプロイに関する項

- 『Oracle Fusion Middlewareの管理』の第8.4項にあるOracle ADFアプリケーションのデプロイおよびアンデプロイに関する説明を参照してください。

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

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

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

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

デプロイ時に使用できるセキュリティ・オプションは、「Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。

Fusion Middleware Controlを使用してOracle ADFアプリケーションをテスト環境にデプロイするときには次の手順が発生します。

ポリシー管理

- アプリケーションとパッケージ化されたアプリケーション固有のポリシーは、アプリケーションがデプロイされるときにOPSSセキュリティ・ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。

注意:

ファイルベースのOPSSセキュリティ・ストア(つまり、jazn-data.xmlファイル)を本番環境に移行する前に、すべての権限に重複したパーミッションが含まれていないことを確認します。権限でパーミッションが重複している(パーミッションの名前とクラスが同じ)場合は、移行でエラーが発生し、処理が停止します。この場合、jazn-data.xmlファイルを編集して、権限の定義から重複しているパーミッションをすべて削除した後、再度移行を起動します。

資格証明管理

- アプリケーションとパッケージ化されたアプリケーション固有の資格証明は、アプリケーションのデプロイ時に資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。

- 移行中にLDAPリポジトリにアクセスするために必要なブートストラップ資格証明は、Fusion Middleware Controlによって自動的に生成されます。

アイデンティティ管理

アプリケーションとパッケージ化されたアイデンティティは移行されません。ドメイン管理者はドメイン認証プロバイダを構成し(管理コンソールを使用)、必要に応じて、環境にあるアイデンティティ(エンタープライズ・ユーザーおよびグループ)を更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールをマップする(Fusion Middleware Controlを使用)必要があります。

その他の考慮事項

- LDAPベースのセキュリティ・ストアを持つドメインにデプロイする場合は、アプリケーションのデータの整合性を保持するために、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。

- アプリケーションを複数の管理対象サーバーにデプロイするときは、管理サーバーを含めてデータが予期したとおりに移行されるようにしてください。

- ドメイン・ストアの再関連付けは頻繁に行う操作ではなく、通常は、アプリケーションをデプロイする前のドメインを設定するときに行います。手順の詳細は、第9.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。

6.3.1.1 テスト環境へのデプロイ後の一般的な管理タスク

テスト環境へのアプリケーションのデプロイ後、管理者はFusion Middleware Controlまたは管理コンソールを使用していつでも次のタスクを実行できます。

- エンタープライズ・グループへのアプリケーション・ロールのマップ。このマッピングが完了するまで、セキュリティは予期したとおりに動作しません。手順の詳細は、第10.2.2項「アプリケーション・ロールの管理」を参照してください。

- 新しいアプリケーション・ロールの作成または既存のアプリケーション・ロールのカスタマイズ。詳細は、第10.2.2項「アプリケーション・ロールの管理」を参照してください。

- システム・ポリシーの管理。手順の詳細は、第10.2.3項「システム・ポリシーの管理」を参照してください。

- 資格証明の管理。手順の詳細は、第11章「資格証明ストアの管理」を参照してください。

注意:

Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、そのアプリケーション固有のポリシーがOPSSセキュリティ・ストアから自動的に削除されます。また、他のツールを使用してアプリケーションをアンデプロイする場合は、そのアプリケーション固有のポリシーを手動で削除する必要があります。

資格証明は、アプリケーションをアンデプロイしても削除できません。資格証明は、アプリケーションとパッケージ化することで有効になりますが、アプリケーションをアンデプロイしても資格証明は削除されません。

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

OPSSを使用せずにJavaの標準認可を使用するJava EEアプリケーションを保護するには、管理コンソールまたはWLSTコマンドを使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。

Oracle WebLogic ServerにデプロイしたJava EEアプリケーションは、WebLogicリソースとなります。したがって、管理者は、他のリソースの場合と同じ方法で、デプロイされたアプリケーションにセキュリティを設定できます。

デプロイ手順の詳細は、『Oracle Fusion Middlewareの管理』の第8.3項にあるJava EEアプリケーションのデプロイおよびアンデプロイに関する説明を参照してください。

WebLogic Serverのデプロイ機能の概要は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「WebLogic Serverデプロイメントの理解」を参照してください。

関連ドキュメント

アプリケーション・リソースの保護の詳細は、次のドキュメントに記載されています。

『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の次の各項

- アプリケーションのリソースに関する項

- WebアプリケーションおよびEJBリソースの保護のオプションに関する項

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの次の項

- ロールとポリシーの使用したリソースの保護に関する項

『Oracle WebLogic Server WebLogic Webサービスの保護』の次の項

- Webサービス・セキュリティの概要に関する項

『WebLogicセキュリティ・サービスによるアプリケーションの開発』の次の各項

- Webアプリケーションの保護に関する項特に、Webアプリケーションでの宣言セキュリティの使用に関する項

- Enterprise JavaBeans (EJBs)の保護に関する項

- Javaセキュリティを使用したWebLogicリソースの保護に関する項

6.5 監査機能を伴ったアプリケーションのデプロイ

アプリケーションでは、Oracle Fusion Middleware監査フレームワークを使用して、監査機能を提供できます。OPSSでは、監査フレームワークとの統合を可能にする監査サービスが提供されます。

監査機能を使用するには、アプリケーションをデプロイする際に、監査サービスにアプリケーションを登録する必要があります。

監査フレームワークの一般的な予備知識については、第13章を参照してください。

アプリケーションを監査サービスに統合する手順の詳細は、第25.2項を参照してください。

6.5.1 監査のパッケージ化要件

特定の構成ファイルをアプリケーションEARファイルでパッケージ化する必要があります。

- アプリケーションの監査可能イベントを記述するイベント定義ファイル

- ローカライズ可能な要素が含まれる翻訳ファイル

詳細は、第25.3項および第25.4項を参照してください。

6.5.2 監査サービスへの登録

第6.5.1項で説明したパッケージ・ファイルに加えて、OPSSデプロイメント・ディスクリプタ・ファイルに特定の監査登録パラメータを構成することもできます。このディスクリプタ・ファイルもEARでパッケージ化されます。これらのファイルは、アプリケーションのデプロイ時に、監査登録サービスによって自動的に処理されます。

詳細は、25.4項を参照してください。

6.5.3 監査データの移行

このトピックの詳細は、第6.6.3項を参照してください。

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

次の推奨事項は、JAAS認可を使用するJava EEアプリケーションにのみ当てはまります。このようなアプリケーションには、Oracle Application Development Frameworkアプリケーション、Oracle SOAアプリケーション、Oracle WebCenterアプリケーションなどがあります。標準認可を使用するJava EEアプリケーションは、この推奨事項の対象外です。標準認可を使用するJava EEアプリケーションのデプロイは、「標準Java EEアプリケーションのデプロイ」を参照してください。

アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlです。後述の項で説明する操作を実行するユーザーは、LDAPリポジトリでスキーマをシードする権限など、適切な権限を持っている必要があります。

第5.2.1項「新しい本番環境の設定」の説明に従って本番環境が設定されていることを前提とします。

重要事項:

本番環境ではファイルベース・ストアは推奨されません。

新しい本番環境への移行は、次の段階に分かれています。

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

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

- 監査情報の移行

- キーストア・サービス・アーティファクトの移行

移行はセキュリティ・データのバックアップおよびリカバリにも使用できます。セキュリティ・データをバックアップするには、XMLベース・ストアに移行します。セキュリティ・データをリカバリするには、保存済のXMLベース・ストアからターゲットのセキュリティ・ストアに移行します。

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

本番環境でのプロバイダ(ポリシー・プロバイダおよび資格証明プロバイダ以外)の構成は、テスト環境で使用した構成と同じものとする必要があります。この場合のタスクとして、次のものが考えられます。

- アイデンティティ・ストアの構成(WebLogic管理コンソールやWLSTコマンドmigrateSecurityStoreを使用して必要なユーザーやグループのプロビジョニングを行う場合など)。この最後のコマンドの詳細は、「migrateSecurityStoreを使用したアイデンティティの移行」を参照してください。

- テスト環境で実行したあらゆる特定のプロバイダの構成

注意:

Oracle WebLogic Serverには、packおよびunpackコマンドなど、ドメインの作成を容易にするためのツールがいくつか用意されています。詳細は、『Oracle Fusion Middleware PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

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

アイデンティティ・データは、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに移行できます。この移行が必要になる状況の例として、ファイルベースのアイデンティティ・ストアを使用するテスト環境からLDAPベースのアイデンティティ・ストアを使用する本番環境に移行する場合があります。

このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。

このコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

WLSTコマンドを実行するためのプラットフォーム固有の要件については、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。

スクリプト・モードおよびインタラクティブ・モードの構文

WebLogicにアイデンティティを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore -type idStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-dstLdifFile LdifFileLocation]

migrateSecurityStore(type="idStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [dstLdifFile="LdifFileLocation"])

引数(dstLdifFile以外はすべて必須)の意味は次のとおりです。

- configFileでは、構成ファイルjps-config.xmlの相対パスまたは絶対パスを指定します。

- srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。このコマンドでWLS組込みLDAPを移行元ストアにすることはできません。

- dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。移行先ストアは、LDAPベースのアイデンティティ・ストアにする必要があります。サポートされているタイプの一覧は、第3.1.1項「アイデンティティ・ストアのタイプとWebLogic認証プロバイダ」を参照してください。

- dstLdifFileでは、作成したLDIFファイルの相対パスまたは絶対パスを指定します。移行先が組込みLDAPなど、LDAPベースのOracle Internet Directoryストアである場合にのみ適用されます。LDIFファイルはLDAPサーバーにはインポートされず、通常は手動編集が必要です。

srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

LDIFファイルを生成した後、通常は、このファイルを手動で編集して、LDIFファイルの最終的なインポート先となるLDAPリポジトリの属性をカスタマイズします。

重要:

出力LDIFファイルの各ユーザーのパスワードは、実際のユーザー・パスワードではなく、仮の文字列weblogicです。移行先がLDAPベースのOracle Internet Directoryストアの場合、仮の文字列はchangeです。

LDIFファイルをターゲットのLDAPストアにインポートする前に、セキュリティ管理者がこのファイルを編集して、仮のパスワードを実際のパスワードに変更する必要があります。

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

本番環境では、OPSSセキュリティ・ストア(ポリシー、資格証明およびキー・ストア)をLDAPベースのOracle Internet Directoryに再関連付けすることを強くお薦めします。テスト用のポリシー・ストアおよび資格証明ストアもLDAPであったとしても、本番用のLDAPはテスト用のLDAPとは別のものとすることが前提となっています。テスト用のOPSSセキュリティ・ストアがファイルベースであったとしても、権限に重複したパーミッションがないことを確認してください。「ポリシー管理」の注意を参照してください。

ポリシー、資格証明およびキーの移行は、アプリケーションのデプロイ時に自動的に処理できる他、アプリケーションのデプロイ前またはデプロイ後にWLSTコマンドmigrateSecurityStoreを使用して実行することもできます(詳細は、次の各項を参照してください)。

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

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

- 大量のポリシー・ストアおよび資格証明ストアの移行

重要事項:

サーバーの停止と再起動を必要としない、アプリケーションのホット・デプロイを行う場合、セキュリティ・ストアにそのアプリケーションと同じ名前のストライプが含まれていない場合にかぎり、ファイルjazn-data.xmlのデータのドメイン・セキュリティ・ストアへの移行が実行されます。特に、アプリケーションのホット・デプロイの再実行時(つまり、2度目以降のホット・デプロイ実行時)には、ファイルjazn-data.xmlに加えられた変更内容は、ドメイン・セキュリティ・ストアに移行されません。

WebLogic Serverにデプロイしたすべてのアプリケーションについて、(アプリケーション移行に関する特定の設定とは関係なく)ポリシーと資格証明の自動移行を無効にするには、システム・プロパティjps.deployment.handler.disabledをTRUEに設定します。

アプリケーションを本番環境にデプロイする際、管理者は次の点を把握している必要があります。

アプリケーションEARにパッケージ化したポリシーまたは資格証明がテスト環境で変更されているかどうか

この点を把握していることを前提として、アプリケーションを本番環境にデプロイする手順は次のとおりです。

1. Fusion Middleware Controlで次のオプションを使用して、アプリケーションのEARファイルを本番環境にデプロイします。

- ポリシー(アプリケーションまたはシステム)がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション・ポリシー移行」領域で「無視」オプションを選択して、デプロイ時にポリシーを移行するオプションを無効にします。ポリシーが変更されていない場合は、「追加」を選択します。

注意:

テスト環境でのアプリケーション・ロールの変更がテスト用のエンタープライズ・グループへのマッピングにまで及んでいても、「追加」(アプリケーション・ポリシーの移行)を選択し、同時に「アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。」チェック・ボックスを選択できます。

この組合せを選択した場合、アプリケーション・ポリシーは移行されますが、テスト用のエンタープライズ・グループへのマッピングは無視されます。後述のステップ3で、アプリケーション・ロールを本番用のエンタープライズ・グループに再マップする必要があります。

- 資格証明がテスト環境で変更されている場合は、Fusion Middleware Controlの「アプリケーション・セキュリティの構成」ページの「アプリケーション資格証明移行」領域で「無視」オプションを選択して、デプロイ時に資格証明を移行するオプションを無効にします。資格証明が変更されていない場合は、「追加」を選択します。

2. 次の説明に従い、スクリプトmigrateSecurityStoreを使用して、変更済のデータを移行します。

- アプリケーション・ポリシーの移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPにアプリケーション・ポリシーおよびシステム・ポリシーを移行します。「migrateSecurityStoreを使用したポリシーの移行」のサンプルを参照してください。

- アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。「migrateSecurityStoreを使用した資格証明の移行」のサンプルを参照してください。

3. いずれの場合も、必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。

4. Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であることを確認します。特に、テスト用のパスワードと本番用のパスワードを照合してください。必要に応じて、本番用のデータを適宜変更します。

注意:

アプリケーションのデプロイでポリシーを移行したときに、GUIDを再作成しなくても元のGUIDが保持されるようにアプリケーションを構成する方法があります。

この設定は、手動でのみ構成できます。詳細は、第18.5.1項「ポリシーの移行を制御するパラメータ」でパラメータjps.approle.preserveguidの説明を参照してください。

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

デフォルトでは、スクリプトmigrateSecurityStoreでGUIDが再作成されるので、このコマンドを使用して大量のポリシーを移行すると長時間を要する場合があります。そのため、テスト環境から本番環境への移行時には、Oracle Internet Directoryの一括操作を使用する別の手順によるポリシーと資格証明の移行を検討するようお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。

スクリプトmigrateSecurityStoreを使用して手動でポリシーを移行するには、移行元および移行先が指定されている構成ファイルをアセンブルする必要があります。

次のt2p-policies.xmlという構成ファイルの完全なサンプルは、LDAPストレージ、DBストレージおよびXMLストレージのポリシーの移行元の指定と、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-based 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-based 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-based 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-based 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>

<!-- Destination LDAP-based policy store instance -->
<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap.destination">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. OID with OVD, if your destination LDAP is OVD; C. ldap://myDestHost.com:3060 with the URL and port number of your destination 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>

<!-- Destination DB-based policy store instance -->
<serviceInstance provider="db.policystore.provider" name="policystore.db.destination">
<description>Replace: myDestDomain and myDestRootName to appropriate values
according to your destination 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 destination 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 destination LDAPs or 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 destinationDomain/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="LDAPdestinationContext">
<serviceInstanceRef ref="policystore.ldap.destination"/>
</jpsContext>

<jpsContext name="DBdestinationContext">
<serviceInstanceRef ref="policystore.db.destination"/>
</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というjps-contextがファイルに含まれています。さらに、前述のサンプルのマップ名とキー名の各ペアに対して、次の例に示すように、WLSTコマンドaddBootStrapCredentialを使用して、対応するブートストラップ資格証明を指定する必要があります。

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="LDAPdestinationContext")

テスト用の(移行元)XMLストアから本番用の(移行先)LDAPストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="policyStore",configFile="t2p-policies.xml",src="XMLsourceContext",dst="LDAPdestinationContext")

テスト用の(移行元)DBストアから本番用の(移行先)DBストアにポリシーを移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="policyStore",configFile="t2p-policies.xml",src="DBsourceContext",dst="DBdestinationContext")

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

スクリプトmigrateSecurityStoreではGUIDが再作成されるので、このコマンドを使用して大量の資格証明を移行すると長時間を要する場合があります。そのため、テスト環境から本番環境への移行時には、Oracle Internet Directoryの一括操作を使用する別の手順でポリシーと資格証明を移行することを検討するようお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。

migrateSecurityStoreを使用して手動で資格証明を移行するには、移行元および移行先が指定された構成ファイルをアセンブルする必要があります。

migrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。

次のt2p-credentials.xmlという構成ファイルの完全なサンプルは、LDAPストレージ、DBストレージおよびXMLストレージの資格証明の移行元の指定と、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-based credential provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE">
<description>LDAP-based credential provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider" name="db.credentialstore.provider" type="CREDENTIAL_STORE">
<description>DB-based credential provider</description>
</serviceProvider>

</serviceProviders>

<serviceInstances>
<!-- Source file-based 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-based source credential store cwallet.sso is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
</serviceInstance>

<!-- Source LDAP-based 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-based 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>

<!-- Destination LDAP-based credential store instance -->
<serviceInstance provider="ldap.credentialstore.provider" name="credential.ldap.destination">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your destination 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>

<!-- Destination DB-based credential store instance -->
<serviceInstance provider="db.credentialstore.provider" name="credential.db.destination">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your destination 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 destination 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 destination 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 destinationDomain/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="LDAPdestinationContext">
<serviceInstanceRef ref="credential.ldap.destination"/>
</jpsContext>

<jpsContext name="DBdestinationContext">
<serviceInstanceRef ref="credential.db.destination"/>
</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というjps-contextがファイルに含まれています。

migrateSecurityStoreの使用方法を示す後述の例は、スクリプトを実行するターゲット・システム上のディレクトリにファイルt2p-credentials.xmlが格納されていることを前提とします。

この前提の下で、テスト用の(移行元)LDAPストアから本番用の(移行先)LDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="LDAPsourceContext",dst="LDAPdestinationContext")

テスト用の(移行元)XMLストアから本番用の(移行先)LDAPストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="FileSourceContext",dst="LDAPdestinationContext")

テスト用の(移行元)DBストアから本番用の(移行先)DBストアに資格証明を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="credStore",configFile="t2p-credentials.xml",src="DBSourceContext",dst="DBdestinationContext")

6.6.2.3 大量のポリシー・ストアおよび資格証明ストアの移行

この項で説明する別の手順によるストアの移行は、ソースのGUIDを保持する場合や、(スクリプトmigrateSecurityStoreによる移行では長時間を要する)大量のストアを移行する場合に適しています。

注意:

大量のストアの移行は、LDAPベースのストアでのみサポートされています。DBベースのストアではサポートされていません。

ここでは次のコードで示すように、ファイルjps-config.xmlでサービス・インスタンスを使用して移行元のLDAPベースのポリシー・ストアを構成しているものとします。

<serviceInstance provider="ldap.policystore.provider" name="policystore.ldap">
<property name="policystore.type" value="OID" />
<property name="bootstrap.security.principal" value="bootstrap"/>
<property  name="oracle.security.jps.farm.name" value="cn=base_domain"/>
<property  name="oracle.security.jps.ldap.root.name" value="cn=mySrcRootName"/>
<property  name="ldap.url" value="ldap://myCompany.com:7766"/>
</serviceInstance>

重要:

移行先のOracle Internet Directoryがリリース10.1.4.3.0の場合は、次の手順を実行する前にOracle Bug#8417224のパッチを適用する必要がありますOracle Internet Directoryパッチのリストは、第9章「LDAPベースのOPSSセキュリティ・ストアの使用」を参照してください。

一括コマンドを使用して移行元のOracle Internet Directoryストアを移行先のOracle Internet Directoryストアに移行する手順は次のとおりです。

1. 移行元のOracle Internet Directoryがあるシステムで、次の行に示すようにldifwriteを実行してLDIFファイルを生成します。

>ldifwrite connect="srcOidDbConnectStr" baseDN="cn=jpsnode, c=us" ldiffile="srcOid.ldif"

このコマンドでは、ノードcn=jpsnode, c=us以下のすべてのエントリがファイルsrcOid.ldifに書き込まれます。このファイルを、次に実行するコマンドで使用できるように、必要に応じて移行先のOracle Internet Directoryファイル・システムに移動します。

2. 移行先のOracle Internet Directoryノードで、JPSスキーマがシード済であることを確認します。

3. 移行元のOracle Internet Directoryシステムで、次の行に示すようにbulkloadを実行してスキーマ・エラーや不適切なエントリがないことを確認します。

>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"

重複するDN(移行元のディレクトリと移行先のディレクトリとの間で共通するエントリ)が検出された場合は、予期しない結果が生じないようにそれらのDNを確認します。

4. 移行先のDBをバックアップします。次の手順に失敗した場合(その結果、DBが破損した場合)は、DBをリストアする必要があります。

5. 次の行に示すようにbulkloadを実行して、移行先のOracle Internet Directoryにデータをロードします。

>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"

前述のコマンドの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の第14章「バルク操作の実行」を参照してください。

6.6.3 監査情報の移行

この項では、様々なタイプの監査コンテンツを移行する方法について説明します。

監査メタデータおよび監査ポリシーの移行

監査メタデータは、属性グループ、カテゴリ、イベントなどの監査アーティファクトで構成されています。この情報は監査メタデータ・ストアに保管されます。

移行元コンテキストから移行先コンテキストへの監査メタデータの移行には、WLSTコマンドmigrateSecurityStoreを使用します。いずれのコンテキストのメタデータも、XML、データベースまたはLDAPベースのストアに保管されます。このため、たとえば次の移行を実行できます。

- 監査メタデータをXMLファイルからドメインセキュリティ・ストアに移行する。

- 監査メタデータをドメイン・セキュリティ・ストアからXMLファイルに移行する。

次のことに留意してください:

- 監査メタデータのタイプは、システム定義とコンポーネント定義の2種類あります。

- 監査メタデータの移行時に、移行先ストアの既存のデータを上書きするか保持するかを選択できます。選択に基づき、後述のように、migrateSecurityStoreは特定のルールに従って、移行先ストアのシステムおよびコンポーネント定義を置き換える方法を決定します。

次の構文を使用して、監査メタデータを移行します。

migrateSecurityStore(type="auditStore",
configFile="jps_config_file_location",
src="sourceContext",
dst="destinationContext"
[,overWrite="{true|false}"])

このコマンドを使用して、移行元コンテキスト内に構成された監査サービスのメタデータを移行先コンテキストの監査サービスに移行できます。ソースおよびターゲット・コンテキストの監査メタデータは、XML、LDAPおよびDBベース・ストア内にある可能性があります。

このパラメータは次のとおりです。

- configFileでは、構成ファイルの絶対パスまたは相対パスによる場所を指定します。通常、この構成ファイルはスクリプトで使用するためにのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのjps-contextがあります。

- srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。これはソース・メタデータ・ストアです。

- dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。これはターゲット・メタデータ・ストアです。

- overWriteはターゲット・ストア内の既存のメタデータを上書きするかどうかを示します。trueは既存のメタデータを上書きし、falseは特定の条件に合致しないかぎり既存のメタデータを上書きしません。オプションで、デフォルトはfalseです。overWriteフラグは、次のように解釈されます。

1. システム定義はフラグの値にかかわらず上書きされません。

2. overwrite=trueの場合、ターゲット・ストア内のコンポーネント定義はソース・ストアの定義で置き換えられます。

3. overwrite=falseの場合、ソースおよびターゲット・ストア内のコンポーネント定義のメジャーおよびマイナー・バージョンが比較されます。メジャー・バージョンが同じで、ソース・コンポーネント定義内のマイナー・バージョンが高い場合、ターゲット・ストア内のコンポーネント定義はソース・ストアの定義で置き換えられます。そうでない場合、上書きはスキップされます。

監査レコードの移行

通常、テスト環境の監査データ・レコードを本番環境に移行することはありませんが、移行する場合は、データベースのインポート/エクスポート・ユーティリティを使用します。詳細は、第14.6.5項「データのインポートとエクスポート」を参照してください。

6.6.4 キーストア・サービス・アーティファクトの移行

この項では、キーストア・アーティファクト(つまり、キーおよび証明書)をキーストア間で移行する方法を説明します。内容は次のとおりです。

- キーストア移行の概要

- ドメイン内でのキーストア・サービス・アーティファクトの移行

- ドメイン間でのキーストア・サービス・アーティファクトの移行

6.6.4.1 キーストア移行の概要

キーストア・アーティファクト(キーおよび証明書)を次の2つの異なるコンテキストで移行できます。

- 移行元キーストアと移行先キーストアが同じドメインに含まれている場合。つまり、移行元キーストアと移行先キーストアで同じ暗号化鍵が使用される場合。

- 移行元キーストアと移行先キーストアが異なるドメインに含まれている場合。つまり、移行元キーストアと移行先キーストアで異なる暗号化鍵が使用される場合。

migrateSecurityStore WLSTコマンドを使用して、セキュリティ・アーティファクトを移行します。ドメイン内の移行の場合、このコマンドによって単一の構成ファイルが取得されます。ドメイン間の移行の場合は、次に説明するように別々のファイルが必要です。

6.6.4.2 ドメイン内でのキーストア・サービス・アーティファクトの移行

キーおよび証明書を、両方のストアが同じドメイン内に含まれる場合にmigrateSecurityStoreを使用して移行するには、構成ファイルを作成して、移行元および移行先のサービス・インスタンスを指定します。次に、WLSTコマンドmigrateSecurityStoreを、適切なオプションを指定して使用します(この項の最後のサンプルを参照してください)。

キーストアが同一ドメイン内に含まれる場合は、移行元サービス・コンテキストと移行先サービス・コンテキストの指定に1つの構成ファイルで十分です。

次の構成ファイルのサンプルt2p-keys.xmlは、LDAP、DBおよびXMLストア内の移行元キーストア・サービスと、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-based credential provider</description>
</serviceProvider>

<!--The following service provider configuration serves file-based, LDAP based
And DB based keystore service instance -->
<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 service 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-based source keystore service keystores.xml is located in the source file system; typically located in sourceDomain/config/fmwconfig/</description>
</serviceInstance>

<!-- Source LDAP-based keystore service 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-based keystore service 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>

<!-- Destination LDAP-based keystore service instance -->
<serviceInstance provider="keystore.provider" name="keystore.ldap.destination">
<description>Replace: A. myDestDomain and myDestRootName to appropriate values according to your destination LDAP directory structure; B. ldap://myDestHost.com:3060 with the URL and port number of your destination 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>

<!-- Destination DB-based keystore service instance -->
<serviceInstance provider="keystore.provider" name="keystore.db.destination">
<description>Replace: myDestDomain and myDestRootName to appropriate values according to your destination 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 destination 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 destination 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 destinationDomain/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="LDAPdestinationContext">
<serviceInstanceRef ref="keystore.ldap.destination"/>
</jpsContext>

<jpsContext name="DBdestinationContext">
<serviceInstanceRef ref="keystore.db.destination"/>
</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というjps-contextがファイルに含まれています。

例

注意:

次のmigrateSecurityStoreの各例は、スクリプトを実行するターゲット・システム上のディレクトリにファイルt2p-keys.xmlが格納されていることを前提とします。

テスト用の(移行元)LDAPストアから本番用の(移行先)LDAPストアにすべてのキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="keyStore",configFile="t2p-keys.xml",
src="LDAPsourceContext",dst="LDAPdestinationContext")

テスト用の(移行元)XMLストアから本番用の(移行先)LDAPストアにすべてのキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="keyStore",configFile="t2p-keys.xml",
src="FileSourceContext",dst="LDAPdestinationContext")

テスト用の(移行元)データベース・ストアから本番用の(移行先)データベース・ストアに、特定のアプリケーション・ストライプに対するキーと証明書を移行するには、ターゲット・システムで次のようにmigrateSecurityStoreを呼び出します。

>migrateSecurityStore(type="stripeKeyStore",configFile="t2p-keys.xml",
src="DBSourceContext",dst="DBdestinationContext", srcStripe="application1", dstStripe="application2")

6.6.4.3 ドメイン間でのキーストア・サービス・アーティファクトの移行

移行元キーストアと移行先キーストアが異なるドメインに含まれる場合にキーストア・データを移行するには、2つの異なる構成ファイルを使用する必要があります。これは、キーストアの暗号化に使用する暗号化鍵が異なれば、ブートストラップ資格証明ストアも異なるからです。

WLSTコマンドmigrateSecurityStoreを使用する場合は、次のようになります。

- 構成ファイル内の移行元キーストアのコンテキストが、個別パラメータsrcConfigFileとして渡されます。

- 第6.6.4.2項で説明したドメイン内の移行と同じように、構成ファイル内の移行先キーストアのコンテキストが、パラメータ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サービス

この部では、次の各章でOPSSサービスについて説明します。

- 第8章「アイデンティティ・ストア・サービスの構成」

- 第9章「OPSSセキュリティの構成」

- 第10章「ポリシー・ストアの管理」

- 第11章「資格証明ストアの管理」

- 第12章「キーストア・サービスでのキーと証明書の管理」

- 第13章「Oracle Fusion Middleware監査サービスの概要」

- 第14章「監査の構成と管理」

- 第15章「監査分析と監査レポートの使用」

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

この章では、ドメインの作成時または拡張時に、アプリケーションで、ドメイン・セキュリティ・ストアにアプリケーション固有のセキュリティ・アーティファクトのシードを指定する方法を説明します。ここでは、12.1.2へのアップグレード手順も説明します。

この章は次の項に分かれています:

- 第7.1項「概要」

- 第7.2項「FMWドメイン」

- 第7.3項「FMWドメインの作成」

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

- 第7.5項「12.1.2へのアップグレード」

- 第7.6項「OPSSセキュリティ・ストアのバックアップとリカバリ」

7.1 概要

11gドメインでは、デプロイメント・ディスクリプタが適切に設定されている場合に製品固有のセキュリティ・アーティファクトを指定すると、通常、それらのアーティファクトはアプリケーションEARファイルにバンドルされ、アプリケーションのデプロイ時にセキュリティ・ストアに移行されました。

12cドメインでは、製品テンプレートに製品固有のセキュリティ・アーティファクトをバンドルすると、それらのアーティファクトをドメイン・セキュリティ・ストアにシードできます。

7.2 FMWドメイン

JRFテンプレートを使用して作成または拡張されたドメインは、FMWドメインと呼ばれます。つまり、このテンプレートによって、ドメイン・セキュリティ・ストアのセキュリティ・アーティファクトのプロビジョニングが指定されます。具体的には、FMWドメインの作成時または拡張時に、次のタスクが自動的に実行されます。

- OPSSセキュリティ・アーティファクトの作成

- 暗号化鍵でシードされるブートストラップ・ウォレットの作成

- 追加設定なしの、次を含むキーストア・サービスの作成

- ドメイン・トラスト・ストア

- デモCAキーストア

- Oracle WebLogic Serverで使用するドメイン・アイデンティティ・キー・ストア

- 追加設定なしの、キーストア・サービスに接続されたトラスト・サービスの作成

拡張ドメインでは、前述の事項に加えて、次も指定されます。

- 追加設定なしの、DBベースのセキュリティ・ストアの構成

- デフォルトでの、DBベースの監査リポジトリの構成

重要事項:

JRFテンプレートでは、管理対象サーバーは作成されません。JRFテンプレートによって作成または拡張されたドメインでは、そのすべてのリソースが管理サーバーにのみターゲット指定されます。後で管理対象サーバーをドメインに追加するときは、applyJRFユーティリティを起動して、リソースが管理対象サーバーにもターゲット指定されるようにする必要があります。

つまり、再構成後のOPSSと監査データ・ソースを管理対象サーバーにターゲット指定するには、applyJRFを次の形式で実行する必要があります。

applyJRF('managedServer1', '<domain_dir>')

コンポーネント・テンプレートの詳細は、「階層型コンポーネントのセキュリティ・アーティファクト」を参照してください。

7.3 FMWドメインの作成

本番FMWドメインは拡張ドメインである必要があり、拡張ドメインにはDBベースのOPSSセキュリティ・ストアが必要です。このデータベースは、新しいデータベースにすることも、既存のデータベースを他のFMWドメインに関連付けて共有データベースにすることもできます。管理対象サーバーにターゲット指定されているリソースおよびapplyJRFユーティリティの使用については、「FMWドメイン」の「重要事項」を参照してください。

次の各項では、FMWドメインの作成方法を説明します。

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

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

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

新しいデータベースと関連付けられたFMWドメインを作成または拡張するには、次の手順を実行します。

1. 新しいデータベース・スキーマを作成します。詳細は、第9.3.1項「DBベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

2. 『Oracle Fusion Middleware構成ウィザードによるWebLogicドメインの作成』の第5章「構成画面」で説明されているように、構成ウィザードを使用してドメインを作成または拡張します。
このタスクでは特に、手順1で作成したデータベース・スキーマなど、使用するデータベース・スキーマに関する情報を指定したり、使用するJFRテンプレートを選択します。

注意1:

作成中のドメインに関連付けられるデータベース・スキーマは、新しいものである必要があり、以前に使用したものにすることはできません。

注意2:

JRFテンプレートが処理されると、ドメインの作成時または拡張時に、OPSSスキーマ用、OPSS監査ビューア・スキーマ用およびOPSS監査追加スキーマ用に3つのデータ・ソースが自動作成されます。JRFテンプレートのその他の機能の詳細は、「FMWドメイン」を参照してください。

ドメインの作成、拡張またはアップグレードのためのすべてのツールの詳細は、『Oracle Fusion Middlewareドメイン・テンプレート・リファレンス』のテンプレート・ツールに関する説明を参照してください。

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

ドメインの既存のデータベースと関連付けられる拡張FMWドメインを作成するには、次の手順を実行します。

注意:

前述の手順では構成ウィザードを使用できたのに対して、次の手順では、WLSTコマンドのみを使用できます。

1. ドメインdomain1で(他のドメインを結合する必要のある)既存のデータベースdb1を使用していると仮定した場合、次に示すWLSTオフライン・コマンドexportEncryptionKeyを使用して、domain1から、指定された場所に暗号化鍵をエクスポートします。

exportEncryptionKey(location, password)

コマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

2. WLSTコマンドを使用して新しいFMWドメインを作成し、そのドメインでデータベースdb1を共有します。ここで使用するスクリプトは、拡張ドメインの作成に使用するスクリプトと同様ですが、次の行を含む必要がある点が異なります。

setSharedSecretStoreWithPassword(location, password)

locationおよびpasswordの値は、exportEncryptionKeyへのコールで使用した値と同じです。前述のコールは、スクリプト内でupdateDomainへのコールの直前に配置されています。コマンド構文の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

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.1.2へのアップグレード

この項では、セキュリティ・アーティファクトをリリース11.1.1.6または11.1.1.7からリリース12.1.2にアップグレードする手順を説明します。

12.1.2へのOPSSのアップグレードには、次の作業が必要です。

- Oracle Fusion Middlewareのアップグレード・アシスタントを使用した、OPSSスキーマのアップグレード(OPSSセキュリティ・ストア・スキーマおよび監査スキーマのアップグレード)。

- 再構成ウィザードを使用した次の作業:

- ポリシー・ストア・データが格納されている、ポリシー・ストアのディレクトリ情報ツリーのアップグレード。

- OPSSセキュリティ・ストアのデータのアップグレード。

- ファイルjps-config.xmlおよびjps-config-jse.xmlのサービス構成のアップグレード。OPSSセキュリティ・ストアがDBベースの場合は、監査ログ・リポジトリもDBベースに設定されます。

7.5.1 アップグレード前に

アップグレード対象のOPSSセキュリティ・ストアがLDAPベースまたはDBベースの場合は、アップグレードが失敗した際に備えて、リカバリ用にセキュリティ・ストアをバックアップしておいてください。詳細は、「OPSSセキュリティ・ストアのバックアップとリカバリ」を参照してください。

7.5.2 アップグレード手順

OIDベースまたはDBベースのOPSSセキュリティ・ストアを11.1.1.6または11.1.1.7から12.1.2にアップグレードするには、次の手順を実行します。

1. Oracle Fusion Middlewareアップグレード・アシスタントを実行して、OPSSスキーマをアップグレードします。「使用可能なコンポーネント」ページで、必ず「Oracle Platform Security Services」を選択してください。アップグレード・アシスタントの詳細は、『Oracle Fusion Middleware Upgrade Assistantによるアップグレード』を参照してください。

2. リポジトリ作成ユーティリティ(RCU)を実行して、サービス表のスキーマのみを作成します。この表の詳細は、自動的に「データベース構成タイプ」ページに挿入されます。RCUの詳細は、『Repository Creation Utilityによるスキーマの作成』を参照してください。

3. 再構成ウィザードを実行してドメインの再構成を有効にし、OPSSデータ、DIT、構成アーティファクトおよび製品のセキュリティ・アーティファクトをアップグレードします。
この手順では、次の点に注意してください。

- 「データベース構成タイプ」ページで「RCUデータ」を選択し、手順2で作成したサービス表のスキーマを入力して、「RCU構成の取得」をクリックします。

- 「コンポーネント・データソース」ページで次のコンポーネントを選択し、スキーマの詳細を入力します。

- OPSS監査スキーマ - IAU_APPEND

- OPSS監査ビューア - IAU_VIEWER

- OPSSスキーマ - OPSS

製品の再構成テンプレートが自動的に選択され、処理されます。テンプレートの詳細は、第7.4項「階層型コンポーネントのセキュリティ・アーティファクト」を参照してください。

4. 11.1.1.6ドメインからアップグレードする場合のみ、11g JARファイル${common.components.home}/modules/oracle.jps_11.1.1/jps-wls-trustprovider.jarをアップグレード済ドメインの${domain.home}/lib/mbeantypesにコピーします。

注意:

12c拡張ドメインから12cのアップグレード済ドメインへの結合は、サポートされていません。

Oracle Fusion Middlewareのアップグレードの詳細は、『Oracle Fusion Middleware Oracle Fusion Middlewareのアップグレードのプランニング』を参照してください。

ファイルベースのOPSSセキュリティ・ストアを11.1.1.6または11.1.1.7から12.1.2にアップグレードするには、次の手順を実行します。

1. コマンドreassociateSecurityStoreを使用して、ファイルベースのセキュリティ・ストアをOIDベースまたはDBベースのセキュリティ・ストアに再度関連付けします(詳細は、第10.3.1項「reassociateSecurityStore」を参照してください)。

2. 前述の手順に従って、再度関連付けした(OIDベースまたはDBベースの)セキュリティ・ストアを12.1.2にアップグレードします。

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

この項では、ドメインのOPSSセキュリティ・ストアのバックアップ方法とリカバリ方法を説明します。その手順は、処理対象であるOPSSストアの種類(DBベースまたはOIDベース)によって異なります。

セキュリティ・ストアのバックアップに加え、リカバリを可能にするために、次のセキュリティ・ストア用の構成ファイルとデータ・ファイルも保存してください(アスタリスクでディレクトリ内のすべてのファイルを指定可能)。

{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

前述のファイルは通常、Oracle WebLogic Serverドメイン・バックアップの一部としてバックアップされます。Oracle WebLogicドメイン・バックアップの詳細は、『Oracle Fusion Middlewareの管理』の次のトピックを参照してください。

- 第17.3項「バックアップの実行」

- 第18.2.2項「Oracle WebLogic Serverドメインのリカバリ」

この項には次のトピックが含まれます:

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

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

- 推奨事項

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

この項の手順では、アクティブなデータベース複製を可能にするOracle DatabaseクライアントのRecovery Manager (RMAN)を使用します。これは、バックアップ戦略とリカバリの自動化でも一般的に使用されるツールです。RMANの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドの次のトピックを参照してください。

- RMANの概要

- データベースの完全リカバリの実行

次の手順では、ホストAにあるドメインのDBベースのセキュリティ・ストア・インスタンスをホストBのインスタンスにバックアップする方法を説明します。ここでは、ホストAのセキュリティ・ストアのjdbc urlがproddbに設定されていることが想定されており、その同じドメインで、jdbc urlがtestdb (ホストB)に設定されている(クローニングされた) DBベース・ストアを使用できるようにすることが目標です。

前述の想定でDBベースのセキュリティ・ストアをバックアップするには、次の手順を実行します。

1. 次のように、ホストBのインスタンスtestdbを準備します。

1. 新規インスタンス用のpfileを作成します。つまり、次の行の内容を持つinittestdb.oraファイルを作成します。

#
db_name=testdb
#

2. 次の行に示すように、testdbをlistener.oraに追加します。
(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を実行することで、初期化ファイルからバイナリspfileを生成します。次にサーバーを再起動します。

3. 次の行に示すように、リスナーを再起動します。
lsnrctl stop, lsnrctl start

4. 複製データベース・ファイルの名前の生成方法を決定します。具体的には、制御ファイル、データファイル、オンラインREDOログ・ファイルおよび一時ファイルの命名方法を決定します。
たとえば、proddbでは/oradata/proddbディレクトリにあるホストAのファイルを、ホスト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. (オプション)ドメインを切り替えて、バックアップされたばかりのデータベースをOPSSセキュリティ・ストアとして使用することで、バックアップ済のDBインスタンスtestdbが正しく機能することを確認します。

1. Oracle WebLogic Serverを停止します。

2. ファイル{domain}/config/fmwconfig/jps-config.xmlおよび{domain}/config/jdbc/*xmlで、jdbc urlをproddbからtestdbに変更します。

3. Oracle WebLogic Serverを再起動します。

4. ドメイン・セキュリティが正しく機能することを確認します。

7.6.2 OIDベースのセキュリティ・ストアのバックアップとリカバリ

バックアップ元のOracle Internet Directoryストアをバックアップ先のOracle Internet Directoryストアにバックアップするには、次の手順を実行します。

1. 移行元のOracle Internet Directoryがあるシステムで、次の行に示すようにldifwriteを実行してLDIFファイルを生成します。

>ldifwrite connect="srcOidDbConnectStr" basedn="cn=jpsnode, c=us" ldiffile="srcOid.ldif"

このコマンドでは、ノードcn=jpsnode, c=us以下のすべてのエントリがファイルsrcOid.ldifに書き込まれます。このファイルを、次に実行するコマンドで使用できるように、バックアップ先のOracle Internet Directoryファイル・システムに移動します。

2. バックアップ先のOracle Internet Directoryシステムで、JPSスキーマがシードされていることを確認します。

3. 移行元のOracle Internet Directoryシステムで、次の行に示すようにbulkloadを実行してスキーマ・エラーや不適切なエントリがないことを確認します。

>bulkload connect="dstOidDbConnectStr" check=true generate=true restore=true file="fullPath2SrcOidLdif"

重複するDN(バックアップ元のディレクトリとバックアップ先のディレクトリとの間で共通するエントリ)が検出された場合は、予期しない結果が生じないようにそれらのDNを確認します。

4. 次の行に示すようにbulkloadを実行して、移行先のOracle Internet Directoryにデータをロードします。

>bulkload connect="dstOidDbConnectStr" load=true file="fullPath2SrcOidLdif"

前述のコマンドの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次のトピックを参照してください。

- 第15.6項「ldifwriteを使用したOracle Internet Directoryからファイルへのデータのダンプ」

- 第37.2.1項「LDIFファイルとbulkloadを使用したLDAPデータの移行」

7.6.3 推奨事項

企業で設定したスケジュールに従って、定期的にOPSSセキュリティ・ストアをバックアップすることをお薦めします。また、次のイベントが発生した直後は、予定外のバックアップを実行してください。

- ドメイン用の新しい暗号化キーの(自動)生成

- 新しいポリシーの作成

- 新しいバインディング資格証明の設定

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

この章では、OPSSアイデンティティ・ストア・サービスの使用方法について説明します。アデンティティ・ストア・サービスを使用すると、ユーザーおよびロール(グループ)の情報を問い合せることができます。

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

- 第8.1項「アイデンティティ・ストア・サービスの概要」

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

- 第8.3項「アイデンティティ・ストア・サービスの構成」

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

- 第8.5項「アイデンティティ・ストア・サービスのSSL」

関連項目:

『Identity Governance Framework開発者ガイド』のIdentity Directory Serviceに関する説明。

8.1 アイデンティティ・ストア・サービスの概要

この項では、OPSSアイデンティティ・ストア・サービスにおける次の主要概念について説明します。

- アイデンティティ・ストア・サービスについて

- サービス・アーキテクチャ

- アプリケーション・サーバーのサポート

8.1.1 アイデンティティ・ストア・サービスについて

アイデンティティ・ストア・サービスを使用すると、アイデンティティ・ストアにユーザーおよびロール(グループ)の情報を問い合せることができます。

デフォルトでは、サービス・インスタンスは、単一のLDAPアイデンティティ・ストアへの問合せをサポートしています。複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。ID仮想化として知られているこの機能については、第8.3項「アイデンティティ・ストア・サービスの構成」を参照してください。

8.1.2 サービス・アーキテクチャ

図8-1は、アイデンティティ・ストア・サービスのアーキテクチャを示しています。構成に応じて、サービスではアイデンティティ・ストアとして、XMLファイルまたは1つ以上のLDAPサーバーをサポートできます。

LDAP用にサービスを構成すると、デフォルトでは、単一のLDAPストアに問合せが行われます。複数のLDAPストアに問い合せるように、サービスを構成することもできます。

図8-1 OPSSアイデンティティ・ストア・サービス

8.1.3 アプリケーション・サーバーのサポート

アイデンティティ・ストア・サービスは、次のプラットフォームでサポートされています。

- Oracle WebLogic Server

8.1.4 Java SEのサポート

アイデンティティ・ストア・サービスは、スタンドアロンのJava SE環境で使用できます。

詳細は、第8.3.6項「Java SE環境」を参照してください。

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

アイデンティティ・ストア・サービスを使用する前に、アイデンティティ・ストア・プロバイダを構成する必要があります。OPSSでは、ファイルベース(XML)とLDAPベースの両方のプロバイダがサポートされます。

次のjps-config.xmlファイルの断片は、XMLプロバイダとLDAPプロバイダの構成を示しています。serviceProviderは、serviceProviders要素の子要素です。

<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider"
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>LDAP-based 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)をオーバーライドする必要がある場合、USERNAME_ATTRプロパティおよびUSER_LOGIN_ATTRプロパティをjps-config.xml (またはjps-config-jse.xml)のsAMAccountNameに設定します。例:

<property value="sAMAccountName" name="username.attr"/>
<property value="sAMAccountName" name="user.login.attr"/>

詳細は、第9.7.1項「アイデンティティ・ストア・プロバイダの構成」を参照してください。

注意:

仮想化フラグをtrueに設定するときは、user.login.attrとusername.attrプロパティは設定しないでください。

8.3 アイデンティティ・ストア・サービスの構成

この項では、アイデンティティ・ストア・サービスをLDAPベースのストアに構成する方法について説明します。この項の内容は次のとおりです。

- 構成内容

- WebLogic Serverの構成

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

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

- 他のアプリケーション・サーバーの構成

- Java SE環境

関連項目:

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

8.3.1 構成内容

この項では、アイデンティティ・ストア・サービスの各種構成パラメータについて説明します。内容は次のとおりです。

- 複数のLDAP検索の構成

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

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

8.3.1.1 複数のLDAP検索の構成

複数のLDAP問合せ用にサービスを構成するには、次のパラメータを使用します。

- virtualizeプロパティ - このプロパティには、true (複数のLDAP検索)またはfalse (単一のLDAP検索)を設定できます。デフォルトはfalseです。

- グローバル接続パラメータ(virtualizeが有効の場合) - アプリケーションの呼び出す際に、これらのパラメータを使用して、グローバルLDAP構成(ベースの検索、ベースの作成など)を指定します。これらのパラメータのいずれかが構成されていない場合、OPSSはデフォルト値を使用します。

- バックエンド接続パラメータ - このパラメータは各LDAPストアに固有のものです。各LDAPに対して1セットのバックエンド・パラメータが指定されます。既存の値を上書きしないかぎり、このパラメータを設定する必要はありません。

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

表8-1は、グローバル・パラメータとそのデフォルト値(該当する場合)を示しています。

表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.4項「LDAPの汎用的なプロパティ」

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

前述のように、このパラメータはバックエンドLDAPストアに固有のものです。詳細は、次を参照してください:

- 表F-5「LDAPベースのアイデンティティ・ストアのプロパティ」

- 第F.2.1項「ポリシー・ストアのプロパティ」

8.3.2 WebLogic Serverにおける構成

Oracle WebLogic Serverでは、LDAP認証プロバイダは、WebLogicコンソールまたはWLSTコマンドラインを使用して構成します。実行時にOracle WebLogic Serverによって構成の詳細がOPSSに渡されます。Oracle WebLogic Serverでは、特定のコンテキストで複数の認証プロバイダを構成することができます。また、アイデンティティ・ストア・サービスを初期化する際に、デフォルトでは、最初の認証プロバイダが選択されます。この処理については、第3.1.2.1項「複数の認証プロバイダ」で説明しています。

認証プロバイダを構成した後で、アイデンティティ・ストア・サービスを設定して、1つのLDAPアイデンティティ・ストアまたは複数のストアに問い合せることができます。複数のストアを構成するにはvirtualizeプロパティを設定する必要があります。

この項では、これらのオプションの設定方法について説明します。

8.3.2.1 単一のLDAPを使用する場合のサービスの構成

アイデンティティ・ストア・サービスを構成して、問合せ可能なLDAPストアは1つだけです。単一のLDAPサービス・インスタンスを使用する場合のjps-config.xmlファイルの断片を示している例8-2を参照してください。

8.3.2.2 virtualizeプロパティを指定せずに複数のLDAPを使用する場合のサービスの構成

virtualizeプロパティを設定できない場合は、複数のLDAPストアを問い合せて、WebLogic Serverの構成をオーバーライドするようアイデンティティ・ストア・サービスを構成できます。jps-config.xmlファイルの断片を示している例8-1を参照してください。この例では、LDAP URLのカンマ区切りリストを使用して複数のLDAPサービス・インスタンスが定義されています。

例8-1 virtualizeプロパティを設定しない複数のLDAPの構成

<property name="ldap.url", value="ldap://host1:port1,ldap://host2:port2" />

8.3.2.3 Fusion Middleware Controlによる複数のLDAPを使用する場合のサービスの構成

単一のLDAPの場合の設定に記載されているように、Oracle WebLogic Serverに認証プロバイダを構成して起動します。

次に、Fusion Middleware Controlで次の手順を実行します。

1. 左側のナビゲーション・ペインでWebLogicドメインを選択します。

2. 「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

3. ページ上の「アイデンティティ・ストア・プロバイダ」セクションを開きます。

4. 「構成」をクリックします(「アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータの構成」に相当)。

5. 「アイデンティティ・ストア構成」ページが表示されます。

6. 「カスタム・プロパティ」で「追加」をクリックします。

7. 次のように、新しいプロパティを追加します。

Property Name=virtualize
Value=true

注意:

このプロパティは、デフォルト・コンテキストのアイデンティティ・ストアのサービス・インスタンスに追加してください。

8. 「OK」をクリックします。

8.3.2.4 WLSTによる複数のLDAPを使用する場合のサービスの構成

WLSTを使用してvirtualizeプロパティを構成するには、次の手順を実行します。

1. 対象ドメインの管理サーバーに接続するためのpyスクリプト・ファイルを作成します。この操作をするには、userName、userPass、localHost、およびportNumberを指定する必要があります。
このスクリプトの詳細は、付録E「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。

2. $ORACLE_HOME/common/binに移動します。

3. wlst.shコマンドを実行して、スクリプトを実行します。
たとえば、idstore.ldapという名前の認証プロバイダがドメイン構成ファイルに含まれている場合、次のようにコマンドを入力します。

wlst.sh /tmp/updateServiceInstanceProperty.py -si idstore.ldap
-key "virtualize" -value "true"

複数のLDAP検索に使用するプロバイダが構成されます。

関連項目:

第E.1項「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」

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

WLSTを使用してタイムアウト設定を構成するには、次の手順を実行します。

1. 次のWLSTコマンドを実行し、すべてのアダプタをリストします。listAdapters()

2. 次のWLSTコマンドを実行して、アダプタごとにタイムアウトを設定します。たとえば、120秒のタイムアウトを設定します。タイムアウトなしの場合はゼロに設定します。
modifyLDAPAdapter('<ADAPTER NAME>', 'OperationTimeout', 120000)

3. WebLogic Serverを再起動します。

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

必要に応じて、jps-config.xmlを更新して、第8.3.1項「構成内容」に記載されている問合せパラメータを設定できます。これらのパラメータはオプションです。デフォルト値が指定されています。

8.3.2.7 サーバーの再起動

複数のLDAP問合せを構成したら、WebLogic管理サーバーおよび管理対象サーバーを再起動します。

8.3.2.8 構成ファイルの例

例8-2に、単一のLDAP問合せ用にOracle WebLogic Server環境に構成されたjps-config.xmlのサンプル・ファイルを示します。

例8-2 Oracle WebLogic Serverにおける単一の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に、複数のLDAP問合せ用にOracle WebLogic Server環境に構成されたjps-config.xmlのサンプル・ファイルを示します。

例8-3 Oracle WebLogic Serverにおける複数のLDAP構成

<jpsConfig xmlns="http://xmlns.example.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.example.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">

<serviceProviders>
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider"
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>LDAP-based IdentityStore Provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<!-- IDstore instance connecting to multiple ldap  -->
<serviceInstance name="idstore.virtualize" provider="idstore.ldap.provider">

<!-- following property indicates using WLS ldap Authenticators -->
<property name="idstore.config.provider"
value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider"/>

<!-- following property enables virtualization i.e., support for multiple stores -->
<property name="virtualize" value="true"/>

<!-- Front end ldap properties (if not supplied, will use 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>

次のことに留意してください:

- 複数のLDAP問合せを有効にするために、サービス・インスタンスのvirtualizeプロパティをtrueに設定します。

- 必要に応じて、デフォルト値をオーバーライドする場合は、extendedProperty要素を使用することにより、フロントエンド・パラメータを設定できます。
詳細は、第8.3.1項「構成内容」の「フロントエンド・パラメータ」を参照してください。

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

ID仮想化では「分割プロファイル」がサポートされています。分割プロファイルでは、2つの異なるソースに格納されている単一IDの属性をアプリケーションが使用します。

この機能には、この章で説明している構成以外に追加構成が必要です。詳細は、付録I「ID仮想化のためのアダプタ構成」を参照してください。

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

OPSSでは、アイデンティティ・ストアにアクセスするための、複数のLDAPベースのOracle WebLogic Server認証プロバイダ(WebLogic認証プロバイダ)がサポートされています。出荷時に設定されているWebLogic認証プロバイダがLDAPサーバー・タイプに適していない場合は、このタスク用に汎用の認証プロバイダをカスタマイズできます。

この項では、アイデンティティ・ストア・サービスに対してvirtualizeフラグが有効になっている場合に、このような認証プロバイダを構成する方法について説明します。

このコンテキストでは、次の点に注意してください。

- 汎用のLDAP認証プロバイダの使用時には、適切なLDAPプラグインを見つけられるように、アイデンティティ・ストア・サービスに対して正確なLDAPタイプを指定する必要があります。これは、jps-config.xml内のidstore.typeプロパティをオーバーライドすることにより行います。

- virtualizeフラグが有効になっており、Oracle WebLogic Serverドメインに複数の認証プロバイダがあるため(たとえば、defaultAuthenticatorと汎用のLDAP)、アイデンティティ・ストア・サービスに対して、どのLDAPサーバーのidstore.typeをオーバーライドすべきかを指定する必要があります。

この情報は、jps-config.xml内で次のように指定します。

<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" />

<!-- the following refer to the Generic ldap name configured on the WLS
authenticator provider, you get this name from WebLogic config.xml file or admin
console  -->
<serviceInstanceRef ref="myGenericLDAPName"/>

</serviceInstance>

<!-- the following provide the overriding to the Generic ldap (e.g. AD)
-->
<!-- "myGenericLDAPName" is the name used on WLS for the generic LDAP
authenticator provider  -->
<serviceInstance name="myGenericLDAPName" provider="idstore.ldap.provider">

<!-- the following overrides the 'idstore.type' property to
"ACTIVE_DIRECTORY" -->
<property name="idstore.type" value="ACTIVE_DIRECTORY" />
</serviceInstance>

別のLDAPプロバイダ・インスタンスもオーバーライドする必要がある場合は、ファイルに同様のエントリを追加します。

8.3.5 その他のアプリケーション・サーバーの構成

この項のトピックは次のとおりです:

- 単一のLDAPを使用する場合のサービスの構成

- 複数のLDAPを使用する場合のサービスの構成

8.3.5.1 単一のLDAPを使用する場合のサービスの構成

詳細は、第19.3.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」の例を参照してください。

8.3.5.2 複数のLDAPを使用する場合のサービスの構成

サード・パーティのアプリケーション・サーバーにある複数のLDAPに対応するアイデンティティ・ストア・サービスを構成する手順は、次のとおりです。

1. jps-config.xmlファイルを変更して、LDAP対応のディレクトリごとにサービスのインスタンスを構成します。

2. アプリケーション・サーバーを再起動して、変更を有効にします。

例8-4に、サード・パーティのアプリケーション・サーバーに複数のLDAP問合せを実行するように構成されたjps-config.xmlファイルのサンプルを示します。

例8-4 サード・パーティのアプリケーション・サーバーにおける複数のLDAP構成

<jpsConfig xmlns="http://xmlns.example.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.example.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">

<serviceProviders>
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider"
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>LDAP-based IdentityStore Provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<!-- instance 'idstore.oid'  to represent an ldap server 'oid' -->
<serviceInstance name="idstore.oid" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=us,dc=example,dc=com"/>
<property name="idstore.type" value="OID"/>
<property name="security.principal.key" value="oid.ldap.credentials"/>
<property name="security.principal.alias" value="JPS"/>
<property name="ldap.url"
value="ldap://hostname.example.com:389,ldap://hostname.example.com:389"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=example,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=example,dc=com</value>
</values>
</extendedProperty>
<property name="username.attr" value="uid" />
<property name="groupname.attr" value="cn" />
</serviceInstance>

<!-- instance 'idstore.ad' to represent an ldap server 'ad' -->
<serviceInstance name="idstore.ad" provider="idstore.ldap.provider">
<property name="subscriber.name" value="dc=us,dc=example,dc=com"/>
<property name="idstore.type" value="ACTIVE_DIRECTORY"/>
<property name="security.principal.key" value="msad.ldap.credentials"/>
<property name="security.principal.alias" value="JPS"/>
<property name="ldap.url"
value="ldap://hostname.example.com:389,ldap://hostname.example.com:389"/>
<extendedProperty>
<name>user.search.bases</name>
<values>
<value>cn=users,dc=us,dc=example,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.search.bases</name>
<values>
<value>cn=groups,dc=us,dc=example,dc=com</value>
</values>
</extendedProperty>
<property name="username.attr" value="uid" />
<property name="groupname.attr" value="cn" />
</serviceInstance>

<!-- IDStore service "idservice.virtualize" to connect to multiple ldaps ( 'oid' and 'ad') using libOVD-->
<serviceInstance name="idservice.virtualize"          provider="idstore.ldap.provider">

<!--following property enables virtualization i.e., support for multiple stores -->
<property name="virtualize" value="true"/>
<!-- backend ldap instance "idstore.oid"-->
<serviceInstanceRef ref="idstore.oid"/>
<!-- backend ldap instance "idstore.ad"-->
<serviceInstanceRef ref="idstore.ad"/>
<!-- Front end ldap properties (if not supplied, will use 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">

<!-- IdStore service connect to  multiple ldaps ('oid'+'ad') through libOVD-->
<jpsContext name="default">
<!-- use multiple ldaps ('oid'+'ad') through libOVD-->
<serviceInstanceRef ref="idservice.virtualize"/>
<!-- .....other services -->
</jpsContext>

</jpsContexts>

</jpsConfig>

次のことに留意してください:

- 最初のサービス・インスタンスは、Oracle Internet Directoryのプロバイダを定義しています。

- 2番目のサービス・インスタンスは、Microsoft Active Directoryのプロバイダを定義しています。

- 複数のLDAP問合せを有効にするために、サービス・インスタンスのvirtualizeプロパティをtrueに設定します。

- 必要に応じて、デフォルト値をオーバーライドする場合は、extendedProperty要素を使用することにより、フロントエンド・パラメータを設定できます。
詳細は、第8.3.1項「構成内容」の「フロントエンド・パラメータ」を参照してください。

8.3.6 Java SE環境

Java SE環境では、すべての構成がjps-config-jse.xmlファイルに設定されます。必要に応じて次を実行できます。

1. 新しいアイデンティティ・ストアのサービス・インスタンスを定義します。

2. 新しいサービス・インスタンスをJPSコンテキストに追加して、事前に定義されているアイデンティティ・ストア・インスタンスをすべて置き換えます。

3. アイデンティティ・ストア・サービスのvirtualizeフラグを有効にします。例8-4を参照してください。

詳細は、第19.3.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」を参照してください。

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

プログラム上でLDAPアイデンティティ・ストアに問い合せるには、OPSSを使用してJPSコンテキストを取得します(これは、ストア・インスタンスを取得するブリッジのように機能します)。続いて、ユーザーおよびロールAPIを使用して、ストアに問い合せます。

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

try {
//find the JPS context
JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();

//find the JPS IdentityStore service instance
//(assuming the backend 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();
// ref. chapter "Developing with the Identity Directory API"
// on how to use IdentityDirectory

} catch (Exception e) {
e.printStackTrace()
}

アイデンティティ・ストア・サービスの「virtualize」プロパティを有効にする方法を確認するには、例8-4を参照してください。

MBeansの使用方法の詳細は、第E.2項「MBeanを使用したOPSSサービスの構成」を参照してください。

8.5 アイデンティティ・ストア・サービスでのSSLの使用

アイデンティティ・ストアとLDAPサーバー間の接続に対してSSLを有効にできます。アイデンティティ・ディレクトリAPIとユーザーおよびロールAPIのどちらも、複数のLDAPアイデンティティ・ストア構成(デフォルト設定のvirtualize = true)で動作できます。この項では、仮想環境におけるアイデンティティ・ストアからLDAPサーバーへの接続でSSLを有効にする方法について説明します。

この項には次のトピックが含まれます:

- Oracle WebLogic Serverからアイデンティティ・ストアへの接続

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

- JKSベースのキーストアでのSSLの構成

8.5.1 Oracle WebLogic Serverからアイデンティティ・ストアへの接続

アイデンティティ・ストアへの接続がOracle WebLogic Server上のクライアントから始まる場合、SSLの構成はOracle WebLogic Serverで行います。詳細は、第9.2.2項を参照してください。

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

キーストア・サービスで複数のLDAP SSLを使用する際に、ストア証明書は、ドメイン全体で一元的に格納されます。次のシナリオでは、キーストア・サービスWLSTコマンドを使用して、アイデンティティ・ストアからLDAPサーバーへのSSL通信を構成します。キーストア・サービスおよびWLSTコマンドの詳細は、第12章を参照してください。

JKSベースのキーストアでのSSLの構成の詳細は、第8.5.3項を参照してください。

8.5.2.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. Oracle WebLogic Serverを再起動します。

8.5.2.2 キーストア・サービスでの複数の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. appStripe='libovd', name='adapters'を指定してcreateKeyStoreコマンドを使用し、仮想化されたキーストアをキーストア・サービスに作成します。例:

svc.createKeyStore(appStripe='libovd',name='adapters',password='',permission=true)

4. generateKeyPairコマンドを実行して、CAによって署名された新しいキー・ペアを生成します。例:

svc.generateKeyPair(appStripe='libovd',name='adapters',password='',dn='cn=directory manager', keysize='1024',alias='alias',keypassword='')

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. Oracle WebLogic Serverを再起動します。

8.5.3 JKSベースのキーストアでのSSLの構成

JKSベースのキーストアで複数のLDAP SSLを使用する際に、ストア証明書は複数の場所に保持されます。たとえば、WLS認証プロバイダが構成され、adapters.jksファイルに存在する場合は、WebLogic Serverトラストストアに保持されます。

表8-2を使用して、JKSベースのキーストアを使用する場合のSSLの構成に適したプロシージャを判別します。

表8-2 JKSベースのキーストアを使用したSSL

仮想化フラグ

ユーザーおよびロールAPIの使用

アイデンティティ・ディレクトリ・サービスAPIの使用

virtualize=false (つまり仮想化フラグを設定しない)

第9.2.2項で説明しているように、JSSEパラメータを使用してトラストストアを指定します。

例:

-Djavax.net.ssl.trustStore=trust_store_path_name

第8.5.3.1項および第8.5.3.2項で示しているように、adapters.jksファイルを使用します。

virtualize=true (つまり、仮想化フラグを設定)。デフォルト設定は、virtualize=trueです。

第8.5.3.1項および第8.5.3.2項で示しているように、adapters.jksファイルを使用します。

第8.5.3.1項および第8.5.3.2項で示しているように、adapters.jksファイルを使用します。

8.5.3.1 JKSベースのキーストアを使用した複数のLDAPシナリオでの一方向SSL

複数のLDAPアイデンティティ・ストア構成で一方向SSL通信を有効にするには、次の手順を実行します。

注意:

libovdconfig.shスクリプトを実行する前に、ORACLE_HOMEがoracle_commonディレクトリに設定されている必要があります。

1. サービスが使用するLDAPサーバー証明書を格納するためのキーストアを作成します。WebLogic管理サーバーとキーストアの両方に対してパスワードを入力する必要があります。
$MW_HOME/oracle_common/bin/libovdconfig.shスクリプトを使用し、-createKeystoreオプションを指定して、キーストアを作成します。

libovdconfig.sh -host wls_host -port wls_adminserver_port -userName
wls_user_name -domainPath full_path_domain_home -createKeystore

説明:

- hostはOracle WebLogic Serverホストです。

- portはOracle WebLogic Serverの管理サーバーのポートです。

- usernameはOracle WebLogic Serverの管理ユーザー名です。

- domainPathはドメイン・ホームへの完全パスです。

2. 適切なエクスポート・コマンドを使用して、LDAPディレクトリから証明書をエクスポートします。

3. この証明書を、ステップ1で作成したキーストアにインポートします。
keytoolコマンドを使用して、証明書をキーストアにインポートします。adapters.jksという名前のキーストアに対する構文は次のとおりです。

$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. Oracle WebLogic Serverを再起動します。

8.5.3.2 JKSベースのキーストアを使用した複数のLDAPシナリオでの双方向SSL

複数のLDAPアイデンティティ・ストア構成で双方向SSLを有効にするには、次の手順を実行します。

1. 第8.5.3.1項の手順を実行します。

2. 第8.5.3.1項のステップ1で作成したキーストアで、CAによって署名された新しいキー・ペアを生成します。

3. この証明書をファイルにエクスポートします。

4. 証明書をサーバーのキーストアにインポートします。

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

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、キーおよび監査メタデータが格納されるリポジトリです。

この章では、OPSSセキュリティ・ストアの機能について、次の各項で説明します。

- 第9.1項「OPSSセキュリティ・ストアの概要」

- 第9.2項「LDAPベースのOPSSセキュリティ・ストアの使用」

- 第9.3項「DBベースのOPSSセキュリティ・ストアの使用」

- 第9.4項「OPSSセキュリティ・ストアの構成」

- 第9.5項「OPSSセキュリティ・ストアの再関連付け」

- 第9.6項「OPSSセキュリティ・ストアの移行」

- 第9.7項「Fusion Middleware Controlを使用したサービス・プロバイダの構成」

Java EEおよびWebLogicのセキュリティの詳細は、『Oracle WebLogic Serverセキュリティの理解』のJava EEおよびWebLogicのセキュリティに関する説明を参照してください。

注意:

この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。

重要:

OPSSセキュリティ・ストアのポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。

9.1 OPSSセキュリティ・ストアの概要

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。

OPSSセキュリティ・ストアは、選択したリポジトリ・タイプに応じてファイルベース、LDAPベース、またはDBベースにすることができます。また、ファイルベースからLDAPまたはDBベース、DBベースからLDAPまたはDBベース、LDAPベースからLDAPまたはDBベースに再関連付けができます(つまり、リポジトリ・タイプは変更可能ということです)。これ以外の再関連付けはサポートされていません。OPSSセキュリティ・ストアの再関連付けに使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した再関連付けおよびスクリプトreassociateSecurityStoreを使用した再関連付けの項を参照してください。出荷時に、OPSSセキュリティ・ストアは、本番WebLogicドメイン用にDBベースになっています。

Java EEアプリケーションに関するセキュリティ・アーティファクトは、通常、アプリケーションとともにパッケージされているため、デプロイ時にOPSSセキュリティ・ストアに移行できます。OPSSセキュリティ・ストアへの移行に使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した移行およびスクリプトmigrateSecurityStoreを使用した移行の項を参照してください。

9.1.1 マルチサーバー環境

複数のサーバー・インスタンス(管理サーバーおよび管理対象サーバー)が同じホスト上にあるか複数のマシンに分散されている本番WebLogicドメインでは、OIDベースまたはOracle RDBMSベースのOPSSセキュリティ・ストアを使用する必要があります。

注意:

本番環境ではファイルベースのプロバイダは推奨されません。

ポリシーおよび資格証明に設定可能なプロパティの詳細は、付録F「ポリシー・ストアのプロパティ」および付録F「資格証明ストアのプロパティ」を参照してください。

9.2 LDAPベースのOPSSセキュリティ・ストアの使用

LDAPベースのOPSSセキュリティ・ストアは、通常、本番環境で使用します。サポートされているLDAPサーバーは、Oracle Internet Directory(リリース10.1.4.3以降)のみです。

注意:

バージョンに応じて、次のパッチをOracle Internet Directoryに適用する必要があります。

- Oracle Internet Directory 10.1.4の場合は、Bug 9093298を修正するパッチを適用します。

- Oracle Internet Directory 11.1.xの場合は、Bug 8736355を修正するパッチを適用します。

- Oracle Internet Directory 11.1.xおよび10.1.4.3の場合は、Bug 8426457を修正するパッチを適用します。

- Oracle Internet Directory 10.1.4.3の場合は、Bug 8351672を修正するパッチを適用します。

- Oracle Internet Directory 10.1.4.3の場合は、Bug 8417224を修正するパッチを適用します。

- Oracle Internet Directory 11.1.1.6.0の場合は、Bug 13782459を修正するパッチを適用します。

パッチを適用するには、次のようにします。

1. Oracle自動リリース更新にアクセスします。

2. 「パッチ」タブをクリックします。

3. 「リクエスト番号」ボックスにバグ番号を入力して、「検索」をクリックします。

4. パッチを適用します。

ドメインでLDAPベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用し、その資格証明ストアを構成する必要があります。

重要:

OPSSは、Oracle Internet Directoryサーバーでの参照整合性の有効化をサポートしていません。参照整合性を有効化した場合、サーバーは想定したとおりには機能しません。

サーバーの参照整合性を無効にするには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにします。

1. 「管理」を選択してから、「Oracle Internet Directory」メニューの「共有プロパティ」を選択し、「一般」を選択します。

2. 「参照整合性の有効化」リストから「無効」を選択します。

サービス・インスタンスで指定可能なプロパティの一覧は、付録F「LDAPベースのすべてのインスタンスに共通するプロパティ」を参照してください。

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

LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directoryのみです。Oracle Internet Directoryに正しくアクセスできるようにするには、後述する手順で、ノードをサーバー・ディレクトリに設定する必要があります。

Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。これらの必要な資格証明を手動で指定する場合は、第18.5.7項「ブートストラップ資格証明の手動による指定」を参照してください。

Oracle Internet Directoryサーバーのノードの設定

次の手順は、Oracle Internet Directory管理者が実行します。

LDAP Oracle Internet Directoryにノードを設定する手順は、次のとおりです。

1. 次のDNエントリおよびCNエントリを指定するLDIFファイル(ここではjpstestnode.ldifというファイル名にします)を作成します。

dn: cn=jpsroot
cn: jpsroot
objectclass: top
objectclass: OrclContainer

ルート・ノードの識別名(前述の例では文字列jpsrootで示す)は、他のどの識別名とも異なる名前にする必要があります。一部のLDAPサーバーでは、デフォルトで大文字小文字が区別されます。1つのルート・ノードを複数のWebLogicドメインで共有できます。このノードは、サブツリーに対する読取りと書込みの権限がOracle Internet Directory管理者に付与されていれば、最上位レベルに作成する必要はありません。

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

このユーティリティは、初期プロビジョニングを行った後に実行する必要があります。このユーティリティの詳細は、Oracle Fusion Middleware Oracle Identity Managementリファレンスを参照してください。

OPSSセキュリティ・ストアの再関連付けを行う場合は、「OPSSセキュリティ・ストアの再関連付け」を参照してください。

9.2.2 LDAPへの一方向SSL接続の設定

この項では、Oracle WebLogic ServerまたはJava SEアプリケーションと、LDAP Oracle Internet Directory間で一方向SSLチャネルを設定する方法を説明します。このような接続は、たとえばLDAPベースのターゲット・ストアへの再関連付けを行う場合に必要になります。

前提条件: Oracle Internet Directoryサーバーの構成

Oracle Internet Directoryサーバーが一方向SSLモードでリスニングするように構成するには、『Oracle Fusion Middlewareの管理』のOracle Internet DirectoryリスナーでのSSLの有効化に関する説明を参照してください。

Oracle Internet Directoryの認証局(CA)のエクスポート

orapkiを使用して証明書を作成する必要があるのは、Oracle WebLogicサーバーでCAを認識できない場合のみです。

次の例は、このコマンドを使用して証明書serverTrust.certを作成する方法を示しています。

>orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert

前述の呼出しを実行すると、キーストア・パスワードの入力を求められます。

始める前に

SSLを構成する前に、次のことに注意してください。

- 確立されているSSLのタイプがサーバー認証の場合は、次の手順が必要です。それ以外(認証なしまたはクライアント認証)の場合には、次の手順は不要です。

- 次の手順で指定するフラグを複数アプリケーション環境で使用する場合は、それらすべてのアプリケーションでトラスト・ストアを共有する必要があります。

Java EEアプリケーションの場合のWebLogic Serverの設定

アイデンティティ・ストア・サービスとOPSSセキュリティ・ストア・サービスでは、使用するソケット・ファクトリが異なるため、次の手順も異なります。

サーバーとアイデンティティ・ストア間で一方向SSL接続を確立する手順は、次のとおりです(信頼できるCAがある場合は、エクスポートされていることが前提となります)。

1. Oracle WebLogicサーバーでCAを認識できる場合は、この手順を省略し、CAを認識できない場合は、ユーティリティkeytoolを使用してOracle Internet DirectoryのCAをWebLogicトラスト・ストアにインポートします。
ファイルmyKeys.jksを出力する次の呼出しは、このコマンドを使用してファイルserverTrust.certをインポートする方法を示しています。

>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>

サーバーとOPSSセキュリティ・ストア間で一方向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. OIDサーバーのSSL証明書でワイルド・カードを使用する場合は、WebLogic Serverを起動するスクリプトに次の行を追加します。

-Dweblogic.security.SSL.ignoreHostnameVerification=true

Java SEアプリケーションの場合のWebLogic Serverの設定

Java SEアプリケーションの場合、設定はアイデンティティ・ストアとOPSSセキュリティ・ストアの両方で同じです。

1. Oracle WebLogicサーバーでCAを認識できる場合は、この手順を省略し、CAを認識できない場合は、ユーティリティkeytoolを使用してOracle Internet DirectoryのCAをWebLogicトラスト・ストアにインポートします。
ファイルmyKeys.jksを出力する次の呼出しは、このコマンドを使用してファイルserverTrust.certをインポートする方法を示しています。

>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword

2. JMVを起動するスクリプトを変更して、次のような行を追加します。

-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>

9.3 DBベースのOPSSセキュリティ・ストアの使用

DBベースのセキュリティ・ストアは、通常、本番環境で使用します。本番環境でサポートされているDBベースのセキュリティ・ストアは、Oracle RDBMS(リリース10.2.0.4以降、リリース11.1.0.7以降およびリリース11.2.0.1以降)のみです。

注意:

開発環境でのみ、OPSSセキュリティ・ストアとして、Oracle RDBMS Express、Oracle RDBMS Standard EditionおよびOracle RDBMS Standard Edition Oneを使用できます。

DBベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用し、その資格証明ストアを構成する必要があります。サーバーが初期化を完了する前に任意のチェックが必要な場合は、第J.3.6項「サーバーの起動前のパーミッション・チェックの失敗」を参照してください。OPSSスキーマでは、エディション・ベースの再定義(EBR)がサポートされます。

構成可能なプロパティの一覧は、付録F「OPSS構成プロパティ」を参照してください。

この項には次のトピックが含まれます:

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

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

- DBへのSSL接続の設定

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

OPSSセキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。

このタスクの詳細は、『Repository Creation Utilityによるスキーマの作成』の付録A「Repository Creation Utilityの各画面の理解」を参照してください。OPSSスキーマを作成するには、次のスキーマを選択します。

- <prefix>_OPSS

- <prefix>_IAU

- <prefix>_IAU_APPEND

- <prefix>_IAU_VIEWER

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

この項では、管理者がDBベースのセキュリティ・ストアをメンテナンスする場合に実行する可能性のある一部のタスクについて説明します。

DBベースのセキュリティ・ストアには、変更ログが保持されますが、このログは定期的にパージする必要があります。変更ログをパージするには、管理者が、提供されているSQLスクリプトopss_purge_changelog.sqlを使用して、24時間以上前の変更ログをパージするか、データベースに接続して、次の行で示すように、SQLのdeleteを(適切な引数を指定して)実行します。

SQL>delete from jps_changelog where createdate < (select(max(createdate) - 1) from jps_changelog);
SQL>Commit;

DBベースのセキュリティ・ストアにアクセスする際に、OPSS管理APIの実行速度が遅い場合は、DBMS_STATSパッケージを実行して、DBの表、索引、クラスタの物理記憶域に関する統計情報を収集します。この情報はデータ・ディクショナリに格納され、分析対象のオブジェクトにアクセスする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は、RCUで作成されたDBスキーマの名前を示しています。DBMS_STATSパッケージの詳細は、『Oracle Database管理者ガイド』を参照してください。

DBMS_STATSを定期的に実行するには、次に説明するように、シェル・スクリプトまたはSQLスクリプトを使用します。

次のサンプル・スクリプトは、コマンド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;

また次のサンプルSQLスクリプトも、コマンド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 DBへのSSL接続の設定

DBベースのOPSSセキュリティ・ストアへの一方向または双方向SSL接続の確立はオプションであり、詳細は『Oracle Fusion Middlewareの管理』のデータベースでのSSLの構成に関する説明を参照してください。

SSL関連のトピックの補足情報は、次のドキュメントを参照してください。

- Oracle Database JDBC開発者ガイド

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

Java SEアプリケーション用のストア構成の例は、第20.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストア」を参照してください。

Java EEアプリケーション用のストア構成の例は、例1を参照してください。

その他のアーティファクトの構成の詳細は、「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

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

OPSSセキュリティ・ストアの再関連付けとは、セキュリティ・アーティファクトをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみがサポートされ、DBタイプのターゲットでは、Oracle Databaseのみがサポートされています。

再関連付けでは、格納データの整合性を保持しながらリポジトリが変更されます。すべてのセキュリティ・アーティファクトが、既存のセキュリティ・ストアから新しいターゲット・ストアに移行されます。この操作は、ドメインの作成後であればいつでも行うことができ、次の項で説明されているように、Fusion Middleware ControlまたはreassociateSecurityStoreのいずれかを使用して実行します。

- Fusion Middleware Controlを使用した再関連付け

- スクリプトreassociateSecurityStoreを使用した再関連付け

9.5.1 Fusion Middleware Controlを使用した再関連付け

再関連付けでは、OPSSセキュリティ・ストア(ポリシー、資格証明、キーおよび監査メタデータ)をリポジトリ間で移行し、適切なセキュリティ・ストア・プロバイダを再構成します。この項では、Fusion Middleware Controlのページを使用して再関連付けを行う方法を説明します。

「セキュリティ・プロバイダ構成」ページのその他の使用方法は、「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

重要ポイント

- ターゲットのLDAPストアに再関連付けを行う前に、「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。

- ターゲットのDBストアに再関連付けを行う前に、「DBベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。

- 再関連付けでターゲットLDAPへの一方向SSLが必要な場合は、再関連付けを行う前に、「LDAPへの一方向SSL接続の設定」の手順を実行してください。

- LDAPストアへの再関連付けの後、Oracle Internet Directoryストアのルート・ノードへのアクセスを保護するために、「Oracle Internet Directoryノードへのアクセスの保護」で説明する手順を実行してください。

- 再関連付けによって、ファイルjps-config.xmlおよびjps-config-jse.xmlが適切な新しい構成で更新されます。

Fusion Middleware Controlを使用してOPSSセキュリティ・ストアを再関連付けする手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します(次の図にページの一部を示します)。

「セキュリティ・ストア」領域の表には、現在ドメインで構成されているプロバイダの特性が表示されます。

2. 「アソシエーションの変更」ボタンをクリックして、「セキュリティ・プロバイダの設定」ページを表示し、プルダウン・リストから「ストア・タイプ」を選択します。このページに表示されるテキストは、選択したストア・タイプによって異なります。次の図に、Oracle Internet Directoryを選択した場合のこのページの一部を示します。

3. 「データベース」を選択している場合は、「データソース名」ボックスにデータソース名を入力します。これは、データ・ソースの作成時に入力したJDBCデータ・ソースの名前にする必要があります。必要に応じて、「選択」をクリックして、構成済のデータソース名のリストを取得します。

4. 「Oracle Internet Directory」を選択している場合は、「LDAPサーバーの詳細」領域で、ターゲットのLDAPサーバーの詳細と接続情報を入力します。

1. ターゲットのOracle Internet Directory LDAPサーバーのホスト名とポート番号を入力します。

2. オプションで、「SSLを接続に使用」ボックスを選択し、LDAPサーバーへの匿名SSL伝送を確立します。
このチェック・ボックスを選択するときには、次の点に注意してください。

ターゲットLDAPサーバーのポートは、匿名SSL伝送を処理するように構成されている必要があります。このポートは、デフォルトの(セキュアではない)LDAPサーバー・ポートとは異なります。

再関連付けでターゲットLDAPストアへの一方向SSLを使用する場合は、この手順を実行する前に、「LDAPへの一方向SSL接続の設定」で説明する手順を必ず実行してください。一方向SSL接続の設定で、一方向SSLチャネルをサポートするポートを特定し、以降の手順でそのポートを指定します。今回のリリースでは、双方向SSLチャネルを使用した再関連付けはサポートされていません。

Fusion Middleware Controlによって、匿名SSL接続をサポートするために必要な権限が追加されて、ファイルweblogic.policyが変更されます。

3. 「接続DN」テキスト・ボックスに、1から256文字の文字列で完全な識別名を入力します。たとえば、cn=orcladmin、dc=us、dc=oracle、dc=comです。

4. 「パスワード」ボックスに、1から256文字を含む文字列であるユーザー・パスワードを入力します。

5. 入力したデータを使用したLDAPサーバーへの接続が機能することを確認するには、「LDAP認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第J.5.5項「匿名SSL接続の確立の失敗」を参照してください。

5. 「ルート・ノードの詳細」領域で、「ルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。
この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第J.2.1項「再関連付けの失敗」を参照してください。

6. 必要に応じて「ポリシー・ストアのプロパティ」領域と「資格証明ストアのプロパティ」領域に、「遅延ロードの有効化」や「ロール・メンバーのキャッシュ・サイズ」などのサービス・インスタンスのプロパティを入力します。
新規のプロパティを追加するには、「追加」をクリックし、「新規プロパティの追加」ダイアログ・ボックスで「プロパティ名」と「値」に文字列を入力して、「OK」をクリックします。追加されたプロパティと値のペアが、表「カスタム・プロパティ」に表示されます。

これらのプロパティは通常、インスタンスの作成時にインスタンスを初期化するために使用されます。

ドメイン構成ファイルjps-config.xmlにあるLDAPサービス・インスタンスの構成に、入力したプロパティと値を指定した<property>要素が追加されて、この構成ファイルが変更されます。

サービス・インスタンスの変更例として、プロパティ名fooと値barを入力したとします。この場合は、次に示すような<property>要素が追加され、LDAPサービス・インスタンスの構成が変更されます。

<serviceInstance name="myNewLDAPprovider" provider="someProvider"
...
<property name="foo" value="bar"/>
...
</serviceInstance>

7. データの入力を完了したら、「OK」をクリックし、「セキュリティ・プロバイダ構成」ページに戻ります。再関連付けのステータスを示すダイアログ・ボックスが表示されます。「セキュリティ・ストア」領域の表が変更されて、指定したプロバイダが表示されます。

8. アプリケーション・サーバーを再起動します。サーバーが再起動するまで、変更は有効になりません。

再関連付けによって、ドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いストア・プロバイダの構成がすべて削除され、新しいストア・プロバイダの構成が追加されます。それにより、ポリシーと資格証明に関する情報が移行元ストアから移行先ストアに移動します。

移行先ストアがLDAPベースの場合、これらの情報は次の形式に従ってドメインDNの下位に保存されます。

cn=<domain_name>,cn=JpsContext,<JPS ROOT DN>

インストールの構成が上位のドメインDNに依存しているかぎり、その上位ドメインのノードはLDAPサーバーから削除しないでください。

9.5.1.1 Oracle Internet Directoryノードへのアクセスの保護

この項で説明する手順は必要に応じて実行するものであり、Oracle Internet Directoryにアクセスするときのセキュリティを強化することのみを目的としています。

アクセス制御リスト(ACL)とは、情報にアクセスできるユーザーとOracle Internet Directoryディレクトリ・オブジェクトに対して許可される操作を指定したリストです。この制御リストはノードで指定し、そのノードのすべてのサブツリーにあるすべてのエントリに、リストで指定した制限が適用されます。

ACLを使用して、LDAP Oracle Internet Directoryリポジトリに格納されているポリシー・データおよび資格証明データへのアクセスを制御できます。ACLは通常、ストアの最上位のルート・ノードで指定します。

Oracle Internet Directoryリポジトリのノードで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は管理者データのDN(再関連付けを実行する際に入力したuserDN)を表します。

2. Oracle Internet Directoryのユーティリティldapmodifyを使用して、これらの指定をOracle Internet Directoryに適用します。

ACLを指定するLDIFファイルの例を次に示します。

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)

アクセス制御リストおよびldapmodifyコマンドの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の第18章を参照してください。

9.5.2 スクリプトreassociateSecurityStoreを使用した再関連付け

OPSSストアの再関連付けは、WLSTコマンドreassociateSecurityStoreを使用して行うことができます。詳細は、第10.3.1項「reassociateSecurityStore」を参照してください。

9.6 OPSSセキュリティ・ストアの移行

ドメインには、セキュリティ・ストアが1つのみ含まれます。アプリケーションで独自のポリシーを指定することができ、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはセキュリティ・ストアの該当するストライプのアプリケーション・ポリシーとして格納されます。ドメインにデプロイまたは再デプロイされたすべてのアプリケーションは、共通のセキュリティ・ストアであるドメイン・セキュリティ・ストアを使用します。このストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。

OPSSセキュリティ・ストアの移行とは、ポリシー、資格証明、監査メタデータおよびキーをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのOPSSセキュリティ・ストアには、互換性のあるバージョンを使用する必要があります(詳細は、第J.8.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください)。

アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。

OPSSセキュリティ・ストアの構成は、管理者によって実行されます。

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

- Fusion Middleware Controlを使用した移行

- スクリプトmigrateSecurityStoreを使用した移行

注意:

WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティjps.deployment.handler.disabledを使用します。

このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイルweblogic-application.xmlにあるアプリケーション個別の設定は無視されます。

9.6.1 Fusion Middleware Controlを使用した移行

アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにOPSSセキュリティ・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにOPSSセキュリティ・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。

アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。

詳細は、第6.6.2項「ポリシーおよび資格証明の移行」の手順を参照してください。

9.6.2 スクリプトmigrateSecurityStoreを使用した移行

アプリケーション固有のポリシー、システム・ポリシーまたは資格証明は、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。

このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。

注意:

スクリプトmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、第6.6.2.3項「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。

WLSTコマンドを実行するためのプラットフォーム固有の要件については、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。使用方法の詳細は、「使用例」を参照してください。

WebLogicのすべてのポリシー(すべてのアプリケーションのシステム・ポリシーとアプリケーション固有のポリシー)を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext

migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

引数(すべて必須)の意味は、次のとおりです。

- configFileでは、構成ファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。この構成ファイルは、特別にアセンブルする必要があり、次の要素を含める必要があります。

- 移行元ストアを指定するコンテキスト

- 移行先ストアを指定するコンテキスト

- ブートストラップ資格証明を指定するコンテキスト

ブートストラップ・コンテキストでは、cwallet.ssoファイルの位置が参照されます。このファイルでは、移行元および移行先のストアへのアクセスおよびそこに含まれるセキュリティ・データの復号化と暗号化に必要なキーが指定されていることが想定されます。

ドメインで使用されるキーの抽出の詳細は「exportEncryptionKey」を、ウォレットへのキーの格納の詳細は「importEncryptionKey」を参照してください。

ウォレットの作成の詳細は、『Oracle Fusion Middlewareの管理』のウォレットの一般的な操作に関する説明を参照してください。

- srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。

- dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。

srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

WebLogicのシステム・ポリシーのみを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type globalPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext

migrateSecurityStore(type="globalPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

引数(すべて必須)の意味は、前述の場合と同じです。

WebLogicのアプリケーション固有のポリシーのみを移行するには、アプリケーションごとに、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type appPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
-srcApp srcAppName
[-dstApp dstAppName]
[-overWrite trueOrfalse]
[migrateIdStoreMapping trueOrfalse]
[mode laxOrstrict]

migrateSecurityStore(type="appPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", srcApp="srcAppName", [dstApp="dstAppName"], [overWrite="trueOrfalse"], [migrateIdStoreMapping="trueOrfalse"], [mode="strict"])

configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。その他の5つの引数の意味は次のとおりです。

- srcAppでは、ソース・アプリケーションの名前、つまり、ポリシーを移行するアプリケーションの名前を指定します。

- dstAppでは、ターゲット・アプリケーションの名前、つまり、ポリシーを書き込むアプリケーションの名前を指定します。指定しない場合は、デフォルトでソース・アプリケーションの名前になります。

- migrateIdStoreMappingでは、エンタープライズ・ポリシーを移行するかどうかを指定します。デフォルト値はTrueです。エンタープライズ・ポリシーを移行の対象から除外する場合、つまりアプリケーション・ポリシーのみを移行する場合は、Falseに設定します。

- overWriteでは、ソース・ポリシーと一致するターゲット・ポリシーをソース・ポリシーで上書きするか、ソース・ポリシーとマージするかを指定します。ターゲット・ポリシーを上書きする場合はTrueに設定し、一致するポリシーをマージする場合はFalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。

- modeでは、移行を停止して、アプリケーション・ポリシーでプリンシパルまたはパーミッションが重複していることを示すエラーを送信するかどうかを指定します。何も指定しないか、LAXに設定します。LAXに設定すると、重複項目があっても移行が継続して、重複項目のいずれかのみが移行し、この効果に対する警告がログに記録されます。

前述の構文要件に一致しない入力を指定すると、スクリプトの実行に失敗し、エラーが返されます。特に、入力は次の要件を満たす必要があります: (a) 渡された位置内でファイルjps-config.xmlが検出される; (b) 渡されたjps-contextsがファイルjps-config.xmlに含まれている; (c) ソースおよびターゲットのコンテキスト名が一意。

すべての資格証明を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type credStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext

migrateSecurityStore(type="credStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。

1つの資格証明マップのみを移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type folderCred
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-srcFolder map1]
[-dstFolder map2]
[-srcConfigFile alternConfigFileLocation]
[-overWrite trueOrFalse]

migrateSecurityStore(type="folderCred", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [srcFolder="map1"],
[dstFolder="map2"], [srcConfigFile="alternConfigFileLocation"], [overWrite="trueOrFalse"])

configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。最後の4つの引数(すべてオプション)の意味は次のとおりです。

- srcFolderでは、移行する資格証明を収めたマップの名前を指定します。オプション。指定しない場合、資格証明ストアにはマップが1つのみであると想定され、この引数の値はデフォルトでそのマップの名前になります。

- dstFolderでは、ソース資格証明の移行先のマップを指定します。この引数はオプションで、指定されない場合、srcFolderに渡されるマップがデフォルトになります。

- srcConfigFileでは、代替構成ファイルの場所を指定します。これは、configFileに渡されるファイルで資格証明が構成されていないという特別な場合に使用されます。この引数はオプションで、指定しない場合、デフォルトでconfigFileに渡される値になります。指定した場合、configFileに渡される値は無視されます。

- overWriteでは、ソース資格証明と一致するターゲット資格証明をソース資格証明で上書きするか、ソース資格証明とマージするかを指定します。ターゲット資格証明を上書きする場合はTrueに設定し、一致する資格証明をマージする場合はFalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。Falseに設定した場合、一致する資格証明が検出されると、ソース資格証明は無視され、警告がログに記録されます。

9.6.2.1 監査メタデータの移行

スクリプトmigrateSecurityStoreを使用して、監査メタデータをドメイン・セキュリティ・ストアに移行するか、監査メタデータをXMLファイルに移行できます。

詳細は6.6.3項を参照してください。

9.6.2.2 使用例

このスクリプトの使用を示している完全な例は、次の各項を参照してください。

- 第6.6.2.1項「migrateSecurityStoreを使用したポリシーの移行」

- 第6.6.2.2項「migrateSecurityStoreを使用した資格証明の移行」

- 第6.6.4項「キーストア・サービス・アーティファクトの移行」

9.7 Fusion Middleware Controlを使用したサービス・プロバイダの構成

この項では、Fusion Middleware Controlを使用して、いくつかのサービス・プロバイダを構成する方法を説明します。この項の内容は次のとおりです。

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

- シングル・サインオン・プロバイダの構成

- トラスト・サービス・プロバイダの構成

- プロパティとプロパティ・セットの構成

注意:

「セキュリティ・プロバイダ構成」ページの「Web Services Managerの認証プロバイダ」領域は、Web Services Managerのログイン・モジュールとキーストアの構成にのみ関連し、ADFアプリケーションとJava EEアプリケーションには関連しません。

ポリシー、資格証明、キーおよび監査を構成するには、次の各項を参照してください。

- 第10.2項「Fusion Middleware Controlを使用したポリシーの管理」

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

- 第12.2項「キーストア・サービスでの証明書の管理」

- 第14.1項「監査管理タスク」

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

アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータを構成する手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

2. 必要に応じて、「アイデンティティ・ストア・プロバイダ」領域を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。

3. 必要に応じて、「追加」ボタンと「削除」ボタンを使用してカスタム・プロパティを管理します。

4. 完了したら、「OK」をクリックして設定を保存し、「セキュリティ・プロバイダ構成」ページに戻ります。

9.7.2 シングル・サインオン・プロバイダの構成

ドメインで使用するSSOプロバイダを構成するには、次の手順を実行します。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

2. そのページで、「シングル・サインオン・プロバイダ」領域の「構成」をクリックして、「シングル・サインオン・プロバイダ」ページを表示します。

3. そのページで、「シングル・サインオン・プロバイダ」ボックスを選択して、プロバイダのデータを入力できるようにします。このボックスを選択するまで、すべてのボックスはグレー表示になっています。

4. プルダウン・リストから「ストア・タイプ」を選択し、選択したプロバイダに該当するデータを入力します(必要なデータは、選択したタイプによって異なります)。

5. 「ログインURL」、「自動ログインURL」および「ログアウトURL」をそれぞれのテキスト・ボックスに入力します。

6. プルダウン・リストから「認証レベル」を選択します。

7. 必要に応じ、ページの下部にある「追加」、「編集」および「削除」を使用してプロバイダの「カスタム・プロパティ」を管理します。

8. 完了したら、「OK」をクリックして、入力したデータを保存します。

9.7.3 トラスト・サービス・プロバイダの構成

ドメインで使用するトラスト・サービス・プロバイダを構成するには、次の手順を実行します。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

2. このページの「トラスト・サービス・プロバイダ」領域には、トラスト・サービスが構成されているかどうかが示されます。トラスト・サービスを構成するには、「構成」をクリックして、「トラスト・サービス・プロバイダ」ページを表示します。

3. このページには次の領域が含まれています。

- プロバイダ: 選択したプロバイダの名前が表示されます。

- トラスト・ストア: 表示される選択肢からストライプおよびトラスト・ストアを選択します。

- キーストアと別名: ストライプとキーストアを選択することによって証明書を選択し、使用可能なトラスト別名のリストから別名を選択します。この領域の下部にある読取り専用のエントリ(「発行者名」および「有効期限」)には、選択した証明書に関する情報が表示されます。

- トラスト・サービス構成: 次の値を入力します。

- 時間誤差: (トラスト・サービスの使用に関連している)2つのシステムのクロック間で許容される誤差を秒数で指定します。デフォルトは60です。

- トークンの有効期間: トークンの有効期間を秒数で指定します。デフォルトは1800です。

- 証明書を含める: 証明書をトークンに含める必要があるかどうかをブール値で指定します。

- コードソース権限: クライアント・コード(対象のトラスト・ストアにアクセスする)のURLを指定します。デフォルト値はありません。この情報は、指定されたコードに付与されるコードソース権限に変換されます。

4. 「OK」をクリックして、入力したデータを保存し、「セキュリティ・プロバイダ構成」ページに戻ります。入力した値は、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlに保存されます。

9.7.4 プロパティとプロパティ・セットの構成

プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。

OPSS構成プロパティのリストは、付録F「OPSS構成プロパティ」を参照してください。

プロパティおよびプロパティ・セットの定義には、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlで<property>要素と<properySet>要素を使用します。プロパティ・セットは、<propertySetRef>要素で参照できます。

プロパティまたはプロパティ・セットを定義する手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

2. 必要に応じて、「拡張プロパティ」領域を開き、「構成」をクリックして「拡張プロパティ」ページを表示します。

3. プロパティを入力するには、「プロパティ」領域の「追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。完了したら、「OK」をクリックします。入力したプロパティが「プロパティ」の表に表示されます。

4. プロパティ・セットを入力するには、「プロパティ・セット」領域の「プロパティ・セットの追加」をクリックして「プロパティ・セットの追加」ダイアログ・ボックスを表示し、プロパティ・セット名を入力します。

5. プロパティ・セットにプロパティを入力するには、既存のプロパティ・セットを選択し、「プロパティの追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。入力したプロパティが、選択したプロパティ・セットのプロパティのリストに追加されます。

6. どの表でも、選択した項目をその表から削除するには、「削除」ボタンを使用します。プロパティおよびプロパティ・セットの入力または編集が完了したら、「OK」をクリックします。

7. Oracle WebLogic Serverを再起動します。サーバーが再起動するまで、変更は有効になりません。

プロパティ・セットを追加または削除するとドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されますが、サーバーを再起動しないかぎり、その変更は有効になりません。

前述の手順で追加した<property>要素と<propertySet>要素は、<jpsConfig>要素の直下に挿入されます。

10 ポリシー・ストアの管理

この章では、セキュリティ管理者がFusion Middleware Control、WLSTコマンドまたはOracle Entitlements Serverのいずれかを使用してポリシーを管理する方法について説明します。

これらについては次の項で説明します。

- 第10.1項「ポリシー・ストアの管理」

- 第10.2項「Fusion Middleware Controlを使用したポリシーの管理」

- 第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」

- 第10.4項「キャッシングとキャッシュのリフレッシュ」

- 第10.5項「WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与」

- 第10.6項「WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ」

- 第10.7項「Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理」

10.1 ポリシー・ストアの管理

ポリシー・ストアのデータにアクセスできるのは、ドメイン管理者など、適切なパーミッションを持つユーザーに限られます。

次の各項で、Fusion Middleware Control、WLSTコマンドまたはOracle Entitlements Serverを使用して管理者がポリシーを管理する方法について説明します。代表的な操作は次のとおりです。

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

- WLSTコマンドを使用したアプリケーション・ポリシーの管理

- Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理

予期しない認可の失敗を防ぎ、効果的にポリシーを管理するには、次の重要ポイントに注意してください。

重要ポイント1:

ユーザーを削除する前に、ユーザーに付与されているすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに誤って継承される可能性があります。

ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、グループ)を更新して、変更後のデータでも予期したとおりに機能するようにする必要があります。

第J.4.4項「ユーザーによる予期しないパーミッションの取得」を参照してください。

重要ポイント2:

ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。

そのため、次のことをお薦めします。

- ポリシーのプロビジョニング時に、管理者は、ポリシーで使用するユーザーおよびグループの名前に、アイデンティティ・リポジトリに記録されているその名前とまったく同じ文字構成を使用します。これによって、ユーザー名またはグループ名を指定した問合せをポリシー・ストアに対して実行すると、想定したとおりに機能します。

- 実行時にユーザー名を入力するときに、エンドユーザーは、アイデンティティ・リポジトリで指定されている大文字/小文字の組合せと完全に一致する名前を入力します。これによって、予期したとおりにユーザーが認可されます。

第J.4.2項「パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致」を参照してください。

重要ポイント3:

リソース・タイプの名前、リソース、または権限には印刷可能文字のみを使用でき、先頭または末尾に空白を使用することはできません。

ロール名をはじめとしたポリシーにおける文字使用に関する考慮事項は、第J.9.5項「ポリシーに使用する文字」を参照してください。

重要ポイント4:

デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debugを-Djps.auth.debug=trueに設定する必要があります。

特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を前述のように設定する必要があります。

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

Fusion Middleware Controlでは、次の項の説明のように、ドメインで使用しているポリシー・ストア・プロバイダのタイプに関係なく、WebLogicドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理できます。

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

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

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

その他のサービス・プロバイダを管理する手順は、第9.7項「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

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

この項では、Fusion Middleware Controlを使用してアプリケーション・ポリシーを管理する方法について説明します。

注意:

複数のアプリケーションがパーミッションを共有している場合、パーミッション・チェックの失敗を防ぐには、該当するパーミッション・クラスをシステム・クラスパスで指定しておく必要があります。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ポリシー」に移動して「アプリケーション・ポリシー」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。

2. 指定したプリンシパルまたはパーミッションに一致するアプリケーションのポリシーを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、基準にする文字列(プリンシパル名、プリンシパル・グループまたはアプリケーション・ロール)を入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

3. 選択したアプリケーション・ストライプのアプリケーション・ポリシーを作成するには、「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。ここで、作成する権限に対するプリンシパルおよびパーミッションを追加します。

1. パーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログ・ボックスを表示します。
そのダイアログ・ボックスの「検索」領域で、まず「権限」または「リソース・タイプ」を選択します。「権限」を選択した場合は、クラスまたはリソース名に一致するパーミッションを指定し、「権限クラス」および「リソース名」を指定します。「リソース・タイプ」を選択した場合は、タイプ名に一致するリソース・タイプを指定し、タイプを指定します。「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したパーミッションが、「権限」領域の表に表示されます。

2. プリンシパルを追加するには、「権限受領者」領域の「追加」ボタンをクリックして、「プリンシパルの追加」ダイアログ・ボックスを表示します。
そのダイアログ・ボックスの「検索」領域で、「タイプ」を選択し、プリンシパル名または表示名に一致させる文字列を入力して、青いボタンをクリックします。問合せの結果が「検索済プリンシパル」表に表示されます。その表から1つ以上の行を選択し、「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したプリンシパルが、「権限受領者」領域の表に表示されます。

3. 「権限受領者」領域の表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。

4. 完了したら、「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。作成したポリシーのプリンシパルとパーミッションがページの下部の表に表示されます。

4. 既存のアプリケーション・ポリシーに基づいてアプリケーション・ポリシーを作成する手順は、次のとおりです。

1. 表から既存のポリシーを選択します。

2. 「類似作成」をクリックし、「アプリケーション権限の類似作成」ページを表示します。このページでは、選択したポリシーから抽出されたデータがパーミッションの表に自動的に入力されます。

3. 前述の手順3の下位手順の説明に従い、必要に応じてこれらの値を変更し、「OK」をクリックします。

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

この項では、Fusion Middleware Controlを使用してアプリケーション・ロールを管理する方法について説明します。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ロール」に移動して「アプリケーション・ロール」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。

2. アプリケーションのロールを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、ロール名に一致させるデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

3. アプリケーション・ロールを作成するには、「作成」をクリックして、「アプリケーション・ロールの作成」ページを表示します。すべての領域に一度にデータを入力する必要はないことに注意してください。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後から指定できます。同様に、ロール・マッピングに対するデータを後で入力することもできます。
領域「一般」で、作成するロールの次の属性を指定します。

1. 「ロール名」テキスト・ボックスにロールの名前を入力します。

2. 必要に応じて、ロールに表示する名前を「表示名」テキスト・ボックスに入力します。

3. オプションで、「説明」テキスト・ボックスに、ロールの説明を入力します。

「メンバー」領域で、作成するロールのマップ先とするユーザーまたはグループを指定します。マップ先とする他のアプリケーション・ロールがある場合は、それを指定します。

作成するアプリケーション・ロールにアプリケーション・ロールを追加する手順は、次のとおりです。

1. 「追加」をクリックして、「プリンシパルの追加」ダイアログを表示します。

2. このダイアログで、「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名に一致させる文字列を入力して、青いボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。その表から1つ以上のプリンシパルを選択します。

3. 完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したアプリケーション・ロールが「メンバー」表に表示されます。

4. 「メンバー」表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。

5. 「OK」をクリックし、ロールの作成(または更新)を完了し、「アプリケーション・ロール」ページに戻ります。作成したロールがそのページの下部の表に表示されます。

6. 既存のアプリケーション・ロールに基づいてアプリケーション・ロールを作成する手順は、次のとおりです。

1. 表から既存のロールを選択します。

2. 「類似作成」をクリックし、「アプリケーション・ロールの類似作成」ページを表示します。このページでは、選択したロールから抽出されたデータが一部のデータに自動的に入力されます。

3. ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。

ロール階層でパーミッションがどのように継承されるかを理解するには、第2.2.1項「パーミッションの継承とロールの階層」を参照してください。

10.2.3 システム・ポリシーの管理

この項では、Fusion Middleware Controlを使用して、Oracle WebLogic Serverドメインのシステム・ポリシーを管理する方法について説明します。

次の手順では、プリンシパルのポリシーとコードベースのポリシーという2種類のシステム・ポリシーを作成できます。プリンシパルのポリシーでは、ユーザーまたはグループのリストにパーミッションを付与します。コードベースのポリシーでは、コード(通常はURLまたはJARファイル)にパーミッションを付与します。たとえば、資格証明ストア・フレームワークを使用するアプリケーションには、適切なコードベースのポリシーが必要です。コードベースURLでは、ワイルドカードやパターンはサポートされていません。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「システム・ポリシー」に移動して「システム・ポリシー」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。

2. 指定したタイプ、名前およびパーミッションと一致するシステム・ポリシーを表示するには、「検索」領域を開き、一致対象のデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

3. 「編集」ボタンをクリックすると、選択したポリシーの特性をいつでも編集できます。リストからポリシーを削除するには、「削除」ボタンをクリックします。

システム・ポリシーを作成する手順は、次のとおりです。

1. 「作成」をクリックして、「システム権限の作成」ページを表示します。

2. 作成するポリシーのタイプとして、「プリンシパル」または「コードベース」を選択します。選択したタイプによってUIが多少異なります。次の手順は、「プリンシパル」を選択した場合に対するものです。

3. パーミッションを追加するには、「権限」領域の「追加」ボタンをクリックして、「権限の追加」ダイアログ・ボックスを表示し、作成しているポリシーに追加するパーミッションを選択します。

1. 「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。検索結果が「検索」領域の表に表示されます。

2. 追加するパーミッションを選択するには、表からパーミッションを選択します。パーミッションを選択すると、その詳細が読取り専用の「カスタマイズ」領域に表示されます。

3. 「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したパーミッションが、「権限」の表に追加されます。

4. 「パーミッション」表からパーミッションを選択し、「編集」ボタンを使用すると、パーミッションの特性をいつでも変更できます。リストからパーミッションを削除するには、「削除」ボタンを使用します。

5. 「OK」をクリックして、「システム・ポリシー」ページに戻ります。

6. 「コードベースに関する権限」領域の表は読取り専用であり、コードベース・システム・ポリシーに関連付けられているリソース名、アクションおよびパーミッション・クラスを示します。

10.3 WLSTコマンドを使用したアプリケーション・ポリシーの管理

オンライン・コマンドとは、実行中のサーバーとの接続が必要なコマンドです。特に指定がないかぎり、この項に記載されたスクリプトはオンライン・スクリプトで、タイプがファイル、LDAP、DBのいずれであるかにかかわりなくOPSSセキュリティ・ストアで動作します。動作にサーバーの実行を必要としないオフラインのスクリプトもいくつか存在します。

読取り専用スクリプトは、モニター、オペレータ、コンフィギュレータまたはAdminというWebLogicグループに属するユーザーのみが実行できます。読取り-書込みスクリプトは、AdminまたはコンフィギュレータのWebLogicグループに属するユーザーのみが実行できます。すべてのWLSTコマンドは、Oracle WebLogic Serverをインストールすれば、追加設定なしで使用できます。

WLSTコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力します。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

WASAdminスクリプトは、インタラクティブ・モードでのみ実行できます。

注意:

WLSTコマンドを呼び出す前は、次のスクリプトのいずれかを実行して、必要なJARがクラス・パスに追加されていることを確認する必要があります。

>sh $ORACLE_HOME/common/bin/wlst.sh

オンライン・コマンドを実行するには、次のようにWebLogicサーバーに接続します。

>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')

構成ファイルおよびJVMについては、第5.6項「WLSTコマンドを使用した一般的なセキュリティ操作」を参照してください。

OPSSはサポートされているすべてのプラットフォームでアプリケーション・ポリシーの管理に使用できる次のスクリプトが用意されています(特に指定がないかぎりこのスクリプトはすべてオンラインです)。

- listSecurityStoreInfo

- 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.6.2項「スクリプトmigrateSecurityStoreを使用した移行」を参照してください。

前述のスクリプトで指定するクラス名はすべて、完全修飾パス名にする必要があります。引数appStripeは、アプリケーション・ストライプ(通常はアプリケーション名)を参照し、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。

認証ロール、匿名ロールおよびWLSTコマンドに関する重要な情報は、第10.5項「WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与」を参照してください。

バージョン管理しているアプリケーションのアプリケーション・ストライプの正しい使用法は、第10.6項「WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ」を参照してください。

10.3.1 reassociateSecurityStore

コマンドreassociateSecurityStoreでは、OPSSセキュリティ・ストアがソースからターゲットのLDAPベース・ストアまたはDBベース・ストアに移行され、jps-config.xmlファイルおよびjps-config-jse.xmlファイル内のサービスがターゲット・リポジトリにリセットされます。また、OPSSセキュリティ・ストアを別のドメインのものと共有する指定もできます(後述のオプション引数joinを参照)。OPSSバイナリとターゲットのOPSSセキュリティ・ストアには、互換性のあるバージョンを使用する必要があります(詳細は、第J.8.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください)。

ソースは、ファイルベース、LDAPベース、またはDBベースのストアのいずれでもかまいません。サポート対象のLDAPターゲットのタイプは、Oracle Internet Directoryのみ、DBターゲットの場合はDB_ORACLEのみです。このコマンドは、インタラクティブ・モードでのみサポートされます。

このコマンドにより、該当するパラメータ(次の引数adminおよびpasswordを参照)が渡されて、ブートストラップ資格証明がリセットされます(ブートストラップ資格証明は、ターゲット・ストアへのアクセスに使用される資格証明です)。ブートストラップ資格証明をリセットする別の方法については、modifyBootStrapCredentialおよびaddBootStrapCredentialの各スクリプトを参照してください。

再関連付けに関連する推奨事項は、「重要ポイント」を参照してください。

インタラクティブ・モード構文

コマンド構文は、ターゲット・ストアのタイプに応じて若干異なります。

ターゲットがLDAPベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。

reassociateSecurityStore(domain="domainName",
servertype="OID",
ldapurl="hostAndPort",
jpsroot="cnSpecification",
admin="cnSpecification",
password="passWord",
[join="trueOrfalse"] [,keyFilePath="dirLoc", keyFilePassword="password"]])

ターゲットがDBベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。

reeassociateSecurityStore(domain="domainName",
servertype="DB_ORACLE",
datasourcename="datasourceName",
jpsroot="jpsRoot",
jdbcurl="jdbcURL",
jdbcdriver="jdbcDriverClass",
dbUser="dbUserName",
dbPassword="dbPassword",
[admin="adminAccnt", password="passWord",]
[join="trueOrfalse"
[,keyFilePath="<directory location>",keyFilePassword="<password>"]]
[odbcdsn="odbcDsnSting"])

引数の意味は、次のとおりです。

- domainでは、WebLogicで、再関連付けが実行されるドメイン名を指定します。

- adminでは、LDAPターゲットの場合、ターゲット・サーバーに対する管理者のユーザー名を指定します。形式はcn=usrNameです。
DBターゲットの場合は、DBに、(ユーザー/パスワードで保護される)保護データ・ソースがある場合にのみ必要です。この場合、データ・ソースが作成されたときにデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。指定した場合は、passwordも指定する必要があります。

- passwordでは、引数adminに関連付けられているパスワードを指定します。LDAPターゲットの場合にのみ必要です。
DBターゲットの場合は、DBに保護データ・ソースがある場合にのみ必要で、当該の場合は引数adminで指定されたユーザーに関連付けられたパスワードを指定します。指定した場合は、adminも指定する必要があります。

- ldapurlでは、LDAPサーバーのURIを指定します。デフォルトのポートを使用する場合の形式は、ldap//:host:portです。匿名SSLまたは一方向SSL伝送を使用する場合の形式は、ldaps://host:portです。目的のSSL接続モードを扱うことができるようにセキュア・ポートを構成する必要があります。また、このセキュア・ポートは、デフォルトの(セキュアではない)ポートとは別のポートとする必要があります。

- servertypeでは、ターゲットLDAPサーバーまたはDBサーバーの種類を指定します。有効なタイプは、OIDまたはDB_ORACLEのみです。

- jpsrootでは、ターゲットLDAPリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。

- joinでは、ドメインがOPSSセキュリティ・ストアを別のドメインと共有するかどうかを指定します。オプション。trueに設定すると既存のストアを別のドメインと共有します。falseに設定すると共有しません。指定しなかった場合は、デフォルトでfalseに設定されます。この引数を使用することにより、複数のWebLogicドメインから同一の論理OPSSセキュリティ・ストアを指定できるようになります。

注意1:

join=trueを指定して、OPSSセキュリティ・ストアを別のドメインに再度関連付ける場合、OPSS暗号化鍵を一方のドメインからエクスポートして他方のドメインにインポートする必要があり、ファイルkeystores.xmlも一方のドメインから他方のドメインにコピーする必要があります。

この注意では、このタスクの実行方法について説明しています(別の方法については、引数keyFilePathの説明にある注意を参照してください)。

具体的には、Domain1にセキュリティ・ストアがあり、join=trueを使用して、Domain2をDomain1のセキュリティ・ストアに再度関連付けした場合、次のように実行します。

1. WLSTコマンドexportEncryptionKeyを使用して、Domain1からewallet.p12ファイルにキーを抽出します(渡した引数keyFilePasswordの値は、後でそのキーを2つ目のドメインにインポートするときに使用する必要があります)。

2. WLSTコマンドimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2にインポートします。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じでなければならないことに注意してください。

3. Domain1のファイルkeystores.xmlをDomain2にコピーします。Domain2にkeystore.xmlが存在する場合は、それを上書きします。
Domain2で実施されたキーストア・サービスの(出荷時の設定とは異なる)いずれの変更も失われることに注意してください(これは、既存のセキュリティ・ストアの結合を目的としているため予期された動作です)。

4. Domain2のサーバーを再起動します。

キーをインポートまたはエクスポートするためのスクリプトの詳細は、exportEncryptionKeyおよびimportEncryptionKeyを参照してください。

- datasourcenameでは、JDBCデータ・ソースのJNDI名を指定します。これはデータ・ソース作成時に入力されたJNDI名データ・ソースの値と同じである必要があります。

- keyFilePathでは、ewallet.p12ファイルが作成されるディレクトリを指定します。このファイルの内容は暗号化され、keyFilePasswordに渡される値により保護されます。オプション。引数keyFilePasswordおよびjoinとともに使用する必要があります。

注意2:

join=trueを指定して、OPSSセキュリティ・ストアを別のドメインに再度関連付ける場合、OPSS暗号化鍵を一方のドメインからエクスポートして他方のドメインにインポートする必要があり、ファイルkeystores.xmlも一方のドメインから他方のドメインにコピーする必要があります。

この注意では、このタスクの実行方法について説明しています(別の方法については、引数joinの説明にある注意を参照してください)。

引数keyFilePathおよびkeyFilePasswordを使用する場合、コマンドreassociateSecurityStoreによってキーのエクスポートおよびインポートが自動的に実行されますが、コマンドの実行前に、ファイルkeystores.xmlを手動でコピーしておく必要があります。

具体的には、Domain1にセキュリティ・ストアがあり、join=trueおよびkeyFile引数を使用して、Domain2をDomain1のセキュリティ・ストアに再度関連付けする場合、次のように実行します。

1. reassociateSecurityStoreを実行する前に、Domain1のファイルkeystores.xmlをDomain2にコピーします。Domain2にkeystore.xmlが存在する場合は、それを上書きします。
Domain2で実施されたキーストア・サービスの(出荷時の設定とは異なる)いずれの変更も失われることに注意してください(これは、既存のセキュリティ・ストアの結合を目的としているため予期された動作です)。

2. 適切な引数値を指定して、コマンドreassociateSecurityStoreを実行します。

3. Domain2のサーバーを再起動します。

- keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。オプション。引数keyFilePathおよびjoinとともに使用する必要があります。

- jdbcurlでは、Java SEアプリケーションでデータベースへの接続に使用するJDBC URLを指定します。Java SEアプリケーションにのみ適用されます。必須。引数jdbcdriver、dbUserおよびdbPasswordとともに使用する必要があります。

- jdbcdriverでは、データベースへの接続に使用するJDBCドライバのクラスを指定します。必須。引数jdbcurlとともに使用する必要があります。

- dbUserでは、ブートストラップ資格証明に追加する資格証明ストア内のデータベース・ユーザーを指定します。必須。引数jdbcurlとともに使用する必要があります。

- dbPasswordでは、dbUserを使用して指定したユーザーのパスワードを指定します。必須。引数jdbcurlとともに使用する必要があります。

- odbcdsnでは、C CSF APIで使用するODBC DSN名を指定します。Cプログラムにのみ適用されます。

使用例

reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")

myDomainでOPSSセキュリティ・ストアを共有するには、次の例に示すようにコマンドを呼び出します。

reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode", join="true")

10.4 キャッシングとキャッシュのリフレッシュ

このトピックは、LDAPベースおよびDBベースのOPSSセキュリティ・ストアにのみ適用されます。ファイルベースのストアの場合、キャッシュは数秒後に更新されます(ファイルベースのストアは本番環境システムではお薦めしません。)

OPSSは、キャッシュ・セキュリティ・アーティファクトによって認可プロセスを最適化します。アプリケーション・ポリシー(またはその他のセキュリティ・アーティファクト)を変更した場合、アプリケーションおよびアーティファクトの変更に使用されたツールが実行されている場所によって変更が有効になるタイミングが異なります。

- アプリケーションとツールの両方が同じホスト上および同一ドメインで実行されている場合、変更は即座に有効化されます。

- 同じではなく、アプリケーションとツールが別のホストまたは別のドメインで実行されている場合は、ストア・キャッシュのリフレッシュ後に変更が有効になります。キャッシュのリフレッシュの頻度は、プロパティoracle.security.jps.ldap.policystore.refresh.intervalの値によって決まります。デフォルト値は10分です。
ドメイン内で、WLSTコマンドまたはFusion Middleware Controlを使用して有効になった変更はすべて、最初は管理サーバーのみで考慮され、サーバーの再起動時のみにドメイン内のすべての管理対象サーバーにプッシュされます。

10.4.1 例

次の使用例は、セキュリティ・アーティファクトの変更に(別のドメインまたはホストの)Oracle Entitlements Serverを使用し、oracle.security.jps.policystore.refresh.intervalプロパティを10分に設定した場合の4つのシナリオにおける認可の動作を示しています。

この使用例では次のように想定しています。

- ユーザーはエンタープライズ・ロールのメンバー

- このエンタープライズ・ロールは、アプリケーション・ロールのメンバーに含まれている

- このアプリケーション・ロールにはアプリケーション機能の一部を制御するパーミッションが付与されている

前述の想定に従って、次の4つのシナリオにおける認可の結果を調べます。

シナリオA

1. ユーザーがアプリケーションにログインします。

2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

4. ユーザーはアプリケーションからログアウトして、ただちにログインしなおします。

5. ユーザーは、この時点でもアプリケーション・ロールによって保護された機能にアクセスできます。

この結果の理由は、ポリシー・キャッシュで、まだ前述のステップ3で実施された変更を反映するリフレッシュが行われていないためです。

シナリオB

1. ユーザーがアプリケーションにログインします。

2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

4. ユーザーはアプリケーションからログアウトして、10分後にログインしなおします。

5. ユーザーは、アプリケーション・ロールによって保護された機能にアクセスできなくなっています。

この結果の理由は、ポリシー・キャッシュで、前述のステップ3で実施された変更を反映するリフレッシュが行われているためです。

シナリオC

1. ユーザーがアプリケーションにログインします。

2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

4. ユーザーがログアウトしない場合、10分以内はアプリケーション・ロールによって保護された機能へのアクセスが可能な状態に保持されます。

この結果の理由は、ポリシー・キャッシュで、まだ前述のステップ3で実施された変更を反映するリフレッシュが行われていないためです。

シナリオD

1. ユーザーがアプリケーションにログインします。

2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

4. ユーザーがログアウトせずに、10分より長く待ってからアプリケーション・ロールによって保護された機能へのアクセスを試行します。アクセスは拒否されます。

この結果の理由は、ポリシー・キャッシュで、前述のステップ3で実施された変更を反映するリフレッシュが行われているためです。

10.5 WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与

一部の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.6 WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ

一部のWLSTコマンドでは、アプリケーション・ストライプの指定が必要です。アプリケーションがバージョン付きではない場合は、アプリケーション・ストライプがデフォルトのアプリケーション名として使用されます。アプリケーションがバージョン付きの場合は、アプリケーション名とアプリケーション・ストライプが同じではなくなります。

たとえば、myAppというバージョン付きアプリケーションのバージョン1の名前は、「Fusion Middleware Control」ページでmyApp(v1.0)と表示されますが、このアプリケーションのアプリケーション・ストライプはmyApp#v1.0です。

一般に、表示名がappName(vers)のアプリケーションでは、アプリケーション・ストライプがappName#versになります。次の起動に示すように、WLSTコマンドでアプリケーション・ストライプとして渡す必要があるのは、この最後の文字列です。

>listAppRoles myApp#v1.0

ストライプを指定できるWLSTコマンドは次のとおりです。

- createAppRole

- deleteAppRole

- grantAppRole

- revokeAppRole

- listAppRoles

- listAppRoleMembers

- grantPermission

- revokePermission

- listPermissions

- deleteAppPolicies

10.7 Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理

Oracle Entitlements Serverを使用すると、WebLogicドメインのOracle Internet Directoryでアプリケーション・ポリシーおよびその他のセキュリティ・アーティファクトの管理および検索を実行できます。

詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの次のトピックを参照してください。

- セキュリティ・アーティファクトの問合せ

- ポリシーおよびロールの管理

11 資格証明ストアの管理

資格証明には、ユーザー名、パスワードおよびチケットを格納できます。資格証明は暗号化できます。資格証明は、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。

Oracle Platform Security Servicesは資格証明ストア・フレームワーク(CSF)を備えています。これは、アプリケーションで資格証明を安全に作成、読取り、更新および管理する際に使用できる一連のAPIです。資格証明ストアは、データベースやLDAPベースのリポジトリなどの外部システムにアクセスするためのユーザー名およびパスワードの格納に使用します。

この章は次の項に分かれています:

- 第11.1項「資格証明のタイプ」

- 第11.2項「資格証明の暗号化」

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

- 第11.4項「WLSTコマンドを使用した資格証明の管理」

11.1 資格証明のタイプ

OPSSでは、そこに置かれたデータに応じて次のタイプの資格証明がサポートされています。

- パスワード資格証明は、ユーザー名とパスワードをカプセル化します。

- 汎用資格証明は、対称キーなどの任意のカスタマイズされたデータまたは任意のトークンをカプセル化します。

資格証明は、マップ名およびキー名によって一意に識別されます。マップには複数のキーを保持することができ、通常、マップ名は、アプリケーションの名前に対応しており、同じマップ名を持つすべての資格証明により、資格証明の論理グループ(そのアプリケーションによって使用される資格証明など)が定義されます。マップ名とキー名のペアは、資格証明ストアにあるすべてのエントリで一意である必要があります。

Oracle Walletはデフォルトのファイルベース資格証明ストアであり、X.509証明書を格納でき、本番環境では通常、Oracle Internet Directory LDAPベースまたはDBベースの資格証明ストアを使用します。

11.2 資格証明の暗号化

OPSSでは、ファイルベースおよびLDAPベースの資格証明ストアでの暗号化データの格納がサポートされていますOPSSでは、暗号化鍵を使用して、資格証明ストアでの読み書き時にデータの暗号化と復号化を行います。この暗号化鍵には、ドメイン・スコープがあります。つまり、ドメインごとに1つのキー(現在のキー)があります。ファイルベースまたはLDAPベースのストアでの資格証明の暗号化を有効にするには、jps-config.xmlファイルの資格証明ストア・サービス・インスタンスで次のプロパティを設定します。

<property name="encrypt" value="true" />

DBベースの資格証明ストアでは、データは、常にクライアント側の鍵を使用して暗号化されます。

ドメイン暗号化鍵

プロパティencryptがtrueに設定されている場合、OPSSでは暗号化鍵を使用して、資格証明ストアに入力された新しい資格証明が暗号化されます。この暗号化鍵は、ドメインが初めて起動されたときにランダムに生成される128ビットのAESキーで、ドメイン全体で有効です。最終的には、このドメイン暗号化鍵を定期的にロールオーバーする必要がある場合があります。キーをロールオーバーすると、新しいキーが生成され、前のキーがアーカイブされます。アーカイブされたキーは旧データの復号化に使用され、新しいキーは、新規データの暗号化と復号化に使用されます。

新しいドメイン暗号化鍵が生成されても、資格証明ストア内のデータはこの新しいキーでただちに再暗号化されるわけではありません。データは書き込まれたときにのみ(新しいキーで)暗号化されます。つまり、すべてのデータが同じ暗号化鍵を使用するようにするには、すべての資格証明を読み取ってから書き込む必要があります。

資格証明ストアを共有するドメイン

2つ以上のドメインが資格証明ストアを共有し、そのストアで暗号化が有効になっている場合、各ドメインは同じ暗号化鍵を使用する必要があります。このために、OPSSにはドメイン・ブートストラップ・ウォレット内でキーをエクスポート、インポートおよびリストアするためのオフライン・スクリプトが用意されています。これにより、1つのドメインで生成された暗号化鍵を、資格証明ストアを共有する他のすべてのドメインに引き継ぐことができます。これらのコマンドの詳細は、「WLSTコマンドを使用した資格証明の管理」を参照してください。

次のシナリオは、Domain1とDomain2という2つのドメインから構成されるクラスタで資格証明の暗号化を設定する方法を示しています。(ドメインが3つ以上がある場合は、各追加ドメインを次の説明にあるDomain2として扱ってください。)

注意:

次のシナリオでは資格証明ストアがLDAPベースであることを前提としていますが、(データが常に暗号化されている)DBベースの資格証明ストアでも、importEncryptionKeyおよびexportEncryptionKeyを使用してドメイン間でキーをインポートおよびエクスポートできます。

シナリオ1

Domain1はLDAPベースの資格証明ストアに再関連付けされており、Domain2はそのストアにまだ結合していないものとします。そのストア上で資格証明の暗号化を有効にするには、次の手順を実行します。

1. Domain1のjps-config.xmlファイルでencryptプロパティをtrueに設定し、ドメインを再起動します。

2. WLSTコマンドexportEncryptionKeyを使用して、Domain1からewallet.p12ファイルにキーを抽出します。スクリプトに渡した引数keyFilePasswordの値は、後でそのキーを別のドメインにインポートするときに使用する必要があります。

3. Domain2のjps-config.xmlファイルでencryptプロパティをtrueに設定します。

その後、この手順は次の2つのいずれかの方法で完了できます。どちらもWLSTコマンドreassociateSecurityStoreを使用しますが、構文が異なります。このスクリプトの詳細は、第10.3.1項「reassociateSecurityStore」を参照してください。

1つ目の方法は次のとおりです。

1. WLSTコマンドreassociateSecurityStoreを使用して、Domain2の資格証明ストアをDomain1で使用されている資格証明ストアに再関連付けします。引数joinを使用し、引数keyFilePasswordとkeyFilePathは使用しないでください。

2. WLSTコマンドimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2にインポートします。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じでなければならないことに注意してください。

3. Domain2のサーバーを再起動します。

2つ目の方法は次のとおりです。

1. WLSTコマンドreassociateSecurityStoreを使用して、Domain2の資格証明ストアをDomain1で使用されている資格証明ストアに再関連付けします。引数join、keyFilePasswordおよびkeyFilePathを使用します。

2. Domain2のサーバーを再起動します。

シナリオ2

Domain1はLDAPベースの資格証明ストアに再関連付けされており、Domain2はそのストアにすでに結合しているものとします。そのストア上で資格証明の暗号化を有効にするには、次の手順を実行します。

1. Domain1のjps-config.xmlファイルでencryptプロパティをtrueに設定し、ドメインを再起動します。

2. WLSTコマンドexportEncryptionKeyを使用して、Domain1からewallet.p12ファイルにキーを抽出します。スクリプトに渡した引数keyFilePasswordの値は、後でそのキーを別のドメインにインポートするときに使用する必要があります。

3. Domain2のjps-config.xmlファイルでencryptプロパティをtrueに設定します。

4. WLSTコマンドimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2に書き込みます。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じでなければならないことに注意してください。

5. Domain2のサーバーを再起動します。

重要事項:

暗号化が有効になっている資格証明ストアを複数のドメインで共有している場合、これらのドメインのいずれかでロールオーバー・キーが生成されるたびに、管理者はWLSTコマンドexportEncryptionKeyおよびimportEncryptionKeyを使用して、クラスタ内の他の各ドメインにそのキーをインポートする必要があります。

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

この項では、Fusion Middleware Controlを使用して資格証明を管理する方法について説明します。その他のサービス・プロバイダを管理する手順は、第9.7項「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「資格証明」に移動して「資格証明」ページを表示します(次の図にページの一部を示します)。

「資格証明ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用している資格証明ストア・プロバイダが表示されます。

2. 指定したキー名と一致する資格証明を表示するには、「資格証明キー名」ボックスに一致対象の文字列を入力し、青いボタンをクリックします。検索結果がページの下部の表に表示されます。

3. 項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。資格証明マップを削除すると、そのマップにあるすべてのキーが削除されます。

資格証明マップを作成する手順は、次のとおりです。

1. 「マップの作成」をクリックして、「マップの作成」ダイアログ・ボックスを表示します。

2. このダイアログ・ボックスで、作成する資格証明のマップの名前を入力します。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しい資格証明マップ名が、マップ・アイコンとともに表に表示されます。

資格証明マップにキーを追加する手順は、次のとおりです。

1. 「キーの作成」をクリックして、「キーの作成」ダイアログ・ボックスを表示します。

2. このダイアログで、「マップの選択」メニューから作成しているキーのマップを選択し、「キー」ボックスにキーを入力して、「タイプ」プルダウン・メニューからタイプ(「パスワード」または「汎用」)を選択します。選択したタイプに応じてダイアログの外観が変わります。
「パスワード」を選択した場合は、必須フィールド(「キー」、「ユーザー名」、「パスワード」、「パスワードの確認」)に入力します。

「汎用」を選択した場合は、「キー」必須フィールドに入力し、「テキストとして入力」ラジオ・ボタンを選択して資格証明情報をテキストとして入力するか、「プロパティ名と値のペアのマップを入力」ラジオ・ボタンを選択してキーと値のペアのリストの形式でキーと値のペアを追加します。「行の追加」をクリックして、追加した行にプロパティ名、値、および値の確認を入力します。

図11-1は、パスワード・キーの作成に使用されるダイアログを示しています。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しいキーが、選択したマップに対応するマップ・アイコンの下に表示されます。

図11-1「キーの作成」ダイアログ

キーを編集する手順は次のとおりです。

1. 表からキーを選択します。

2. 「編集」をクリックして、「キーの編集」ダイアログを表示します。

3. このダイアログで、必要に応じてキーのデータを変更します。汎用キーを編集する場合は、行の横の赤のXを使用すると、対応するプロパティと値のペアが削除されます。
図11-2は、汎用キーの編集に使用されるダイアログを示しています。

4. 「OK」をクリックして変更内容を保存して、「資格証明」ページに戻ります。

ADFアプリケーションに固有の考慮事項については、『Oracle ADFアプリケーションの管理』のアプリケーションにデプロイされた資格証明の編集方法に関する説明を参照してください。

図11-2「キーの作成」ダイアログ

11.4 WLSTコマンドを使用した資格証明の管理

オンライン・スクリプトとは、実行中のサーバーとの接続が必要なスクリプトです。特に指定がないかぎり、この項に記載されたスクリプトはオンライン・スクリプトで、ベースがファイル、LDAP、DBのいずれであるかにかかわりなくポリシー・ストアで動作します。動作にサーバーの実行を必要としないオフラインのスクリプトもいくつか存在します。

読取り専用スクリプトは、モニター、オペレータ、コンフィギュレータまたはAdminというWebLogicグループに属するユーザーのみが実行できます。読取り-書込みスクリプトは、AdminまたはコンフィギュレータのWebLogicグループに属するユーザーのみが実行できます。すべてのWLSTコマンドは、Oracle WebLogic Serverをインストールすれば、追加設定なしで使用できます。

WLSTコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、スクリプトをコマンドライン・プロンプトに入力します。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

WLSTスクリプトを実行するためのプラットフォーム固有の要件については、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。

構成ファイルおよびJVMについては、第5.6項「WLSTコマンドを使用した一般的なセキュリティ操作」を参照してください。

OPSSにはサポートされているすべてのプラットフォームで資格証明の管理に使用できる次のスクリプトが用意されています(特に指定がないかぎりこのスクリプトはすべてオンラインです)。

- updateCred

- createCred

- deleteCred

- modifyBootStrapCredential

- addBootStrapCredential

- exportEncryptionKey

- importEncryptionKey

- restoreEncryptionKey

- rollOverEncryptionKey

注意:

指定したマップおよびキーを持つ資格証明を取得するには、スクリプトを使用して、MBean操作JpsCredentialMXBean.getPortableCredential(map, key)を起動します。

12 キーストア・サービスでのキーと証明書の管理

この章では、キーストア・サービスを使用してキーおよび証明書を管理する方法について説明します。

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

- 第12.1項「キーストア・サービスについて」

- 第12.2項「キーストア・サービスでの証明書の管理」

- 第12.3項「キーストア・サービスでの証明書の管理」

- 第12.4項「Oracle Fusion Middlewareコンポーネントでのキーストア・サービスの使用方法」

- 第12.5項「キーストア・サービス・コマンドについて」

- 第12.6項「キーストア・サービス・コマンドのヘルプの表示」

- 第12.7項「キーストア・サービス・コマンド・リファレンス」

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

OPSSキーストア・サービスでは、SSL、メッセージ・セキュリティ、暗号化および関連タスク用のキーおよび証明書を管理できます。キーストア・サービスは、キー、証明書およびその他のアーティファクトを含むキーストアを作成および管理するために使用します。次の各項目で、キーストア・サービスの概要を説明します。

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

- キーストアのタイプ

- ドメイン・トラスト・ストア

- 複数サーバーを持つドメイン用のキーストア

- キーストア・サービスのトラブルシューティング

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

キーストア・サービスで作成される各キーストアは、アプリケーション・ストライプおよびキーストアによって一意に参照されます。

- アプリケーション・ストライプ
キーストア内に作成されたキーおよび証明書はアプリケーション・ストライプまたは製品内に存在し、ドメイン内の各ストライプには一意の名前が付けられます。

- キーストア
キーストア名はアプリケーション・ストライプ内で一意です。各製品またはアプリケーションは、そのアプリケーション・ストライプ内に複数のキーストアを作成できます。

したがって、(appstripe1, keystoreA)は一意であり、(appstripe1, keystoreB)とも、(appstripe2, keystoreA)とも区別されます。

同様に、各キーストアは、キーストア内で一意の別名によって参照される次のエントリを含むことができます。

- 非対称鍵 - これには公開鍵と対応する秘密鍵が含まれ、通常はSSL通信に使用されます。公開鍵は証明書でラップされています。

- 対称鍵 - これらのキーは通常、暗号化に使用されます。

- 信頼できる証明書 - これらの証明書は通常、SSLピアとの信頼を構築するために使用されます。

12.1.2 キーストアのタイプ

キーストア・サービスでは、次の2つのタイプのキーストアを作成できます。

- 権限によって保護されるキーストア
このタイプのキーストアは認可ポリシーによって保護され、ランタイム・コードによるアクセスはコード・ソース権限によって保護されます。バックエンドのキー・データは、それぞれのドメインに対して一意に生成された暗号化鍵を使用して暗号化されます。

- パスワードによって保護されるキーストア
このタイプのキーストアは、キーストア・パスワードおよび/またはキー・パスワードによって保護されます。ランタイム・コードがこれらにアクセスするには、キーストア・パスワードとキー・パスワード(キーストア・パスワードと異なる場合)へのアクセスが必要になります。バックエンドのキー・データは、Password Based Encryption (PBE)によりキーストア/キー・パスワードを使用して暗号化されます。

アプリケーションには、権限によって保護されたキーストアを使用することをお薦めします。ただし、高度なセキュリティが必要であり、パスワードの管理をいとわない場合は、パスワードによって保護されるキーストアの使用を検討してください。

注意:

キーストア・サービスでは、キーストアまたはキーに対するパスワードは管理されません。製品またはアプリケーションで、適切なリポジトリ内でパスワードを管理する必要があります。たとえば、アプリケーションに対するパスワードを資格証明ストアに格納することを選択できます。

12.1.3 ドメイン・トラスト・ストア

注意:

このデモCAには、ハードコピーされた有名な秘密鍵があります。このデモCAによって署名された証明書を信頼しないように注意してください。信頼ストアのデモCA証明書を本番で使用しないでください。本番のドメイン信頼ストアからこれを削除してください。

各アプリケーションではSSL用に複数のキーストアを構成できますが、すべての製品およびアプリケーションに対して、信頼管理用のドメイン・レベルのトラスト・ストアが事前に構成されています。

このドメイン・トラスト・ストアには、一般的に知られているほとんどのサード・パーティ認証局(CA)の信頼できる証明書、およびキーストア・サービスに構成されているデモCAの信頼できる証明書が含まれます。各アプリケーションではSSLに対してこのドメイン・トラスト・ストアを指定でき、このタスク用に専用のトラスト・ストアを作成する必要はありません。

一方向SSL

一方向SSLでは、アプリケーションはドメイン・トラスト・ストアを使用するだけで、キーストアやトラスト・ストアを作成する必要はありません。

双方向SSL

双方向SSLについては、アプリケーションは自身のアイデンティティ証明書を含むキーストアのみを作成する必要があり、信頼にはドメイン・トラスト・ストアを使用します。

注意:

ドメイン・トラスト・ストアは、ドメイン内のすべての製品およびアプリケーションに対する共有ストアです。ドメイン内の他のすべての製品に影響する可能性があるため、信頼の追加または削除に関する決定は慎重に行う必要があります。

カスタム・トラスト・ストアの作成は、ドメイン・トラスト・ストアで製品の信頼管理要件を満たせない場合にのみ検討してください。

12.1.4 複数サーバーを持つドメイン用のキーストア

複数のサーバーがあるドメインでは、推奨されるストア・タイプはLDAPまたはDBのみです。このような環境では、ファイルベースのストアは構成しないでください。

12.1.5 キーストア・サービスのトラブルシューティング

キーストア・サービスのトラブルシューティングに関する項目については、付録Jで説明します。ここでは、次の項目を参照してください。

- 第J.9.6項「無効な鍵サイズ」。

12.2 キーストア・サービスでのキーストアの管理

この項では、キーストアおよび証明書の一般的なライフサイクル、およびキーストア・サービスを使用してキーストアおよび証明書を作成および保守する方法について説明します。次のトピックが含まれます:

- キーストア・ライフサイクルの概要

- 一般的なキーストアの操作

12.2.1 キーストア・ライフサイクルの概要

KSSキーストアの一般的なライフサイクル・イベントは、次のとおりです。

- キーストアはアプリケーション・ストライプのコンテキストで作成されます。キーストアは直接作成するか、ファイル・システムからキーストア・ファイルをインポートすることによって作成できます。

- 使用可能なキーストアのリストが表示され、特定のキーストアが選択されて更新されます。

- キーストアが更新または削除されます。パスワードで保護されたキーストアの場合は、更新操作ではキーストア・パスワードを入力する必要があります。

- キーストア・パスワードは変更できます。

- キーストアは削除できます。

- キーストアはエクスポートおよびインポートできます。KSSはJKSおよびJCEKSの証明書形式の移行をサポートしています。

12.2.2 一般的なキーストアの操作

この項では、Fusion Middleware Controlを通じてまたはコマンドラインで実行できる、次のキーストア操作を説明します。

- Fusion Middleware Controlでのキーストアの作成

- コマンドラインでのキーストアの作成

- Fusion Middleware Controlでのキーストアの削除

- コマンドラインでのキーストアの削除

- Fusion Middleware Controlでのキーストア・パスワードの変更

- コマンドラインでのキーストア・パスワードの変更

- コマンドラインでのキーストアのエクスポート

- コマンドラインでのキーストアのインポート

12.2.2.1 Fusion Middleware Controlでのキーストアの作成

次の手順を実行して、キーストアを作成します。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. その中にキーストアが作成されるストライプを選択します。必要に応じて、次のようにストライプを作成します。

1. 「ストライプの作成」をクリックします。「ストライプの作成」ダイアログが表示されます。

2. 一意のストライプ名を指定してください。任意の文字の組み合せが可能ですが、名前の中にはフォワード・スラッシュ(/)を使用しないことをお薦めします。

3. 「発行」をクリックします。新しいストライプがストライプの一覧に表示され、キーストアの作成用にそれを選択できます。

5. 「キーストアの作成」をクリックします。

6. 「キーストアの作成」ダイアログが表示されます。

7. 次のようにダイアログ・フォームを完了します。

- キーストア名: 一意のキーストア名を入力します。特殊(非ASCII)文字、またはエンコーディングやロケールの異なる文字は使用しないでください。

- 「保護」タイプ: キーストアの保護メカニズムを「ポリシー」および「パスワード」から選択します。

- パスワードで保護されたキーストアの場合は、有効なパスワードを入力します。

- 権限の付与: コードURLを使用して権限を付与するにはこのチェック・ボックスを選択します。

8. 「OK」をクリックします。新しいキーストアが適切なストライプの下に表示されます。

12.2.2.2 コマンドラインでのキーストアの作成

コマンドラインでcreateKeyStoreスクリプトを使用してキーストアを作成できます。たとえば、ストライプ名をteststripe1とすると、次のコマンドを使用してパーミッションベースのキーストアを作成します。

svc.createKeyStore(appStripe='teststripe1', name='keystore1', password='password',permission=true)

ここでpasswordは、このキーストアのパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

新しいストライプを指定する際は任意の文字の組み合せが可能ですが、名前の中にはフォワード・スラッシュ(/)を使用しないことをお薦めします。

一意のキーストア名を入力します。特殊(非ASCII)文字、またはエンコーディングやロケールの異なる文字は使用しないでください。

関連項目:

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

12.2.2.3 Fusion Middleware Controlでのキーストアの削除

キーストアを削除すると、キーストア内のすべての証明書も削除されることに注意してください。それらの証明書に依存している機能がある場合は、結果としてそれらの機能は使用できなくなります。

次の手順を実行して、キーストアを削除します。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「削除」をクリックします。

6. 「キーストアの削除」ダイアログが表示されます。

7. これがパスワードで保護されたキーストアの場合は、キーストア・パスワードを入力します。

8. 「OK」をクリックします。

12.2.2.4 コマンドラインでのキーストアの削除

コマンドラインでdeleteKeyStoreスクリプトを使用してキーストアを削除できます。たとえば、ストライプ名をappstripe1とすると、次のコマンドを使用してキーストアを削除します。

svc.deleteKeyStore(appStripe='appstripe1', name='keystore1', password='password')

ここでpasswordは、このキーストアのパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

12.2.2.5 Fusion Middleware Controlでのキーストア・パスワードの変更

パスワードで保護されたキーストアのパスワードを変更する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「パスワードの変更」をクリックします。

6. 「キーストア・パスワードの変更」ダイアログが表示されます。

7. 古いパスワードと新しいパスワードを入力します。

8. 「OK」をクリックします。

12.2.2.6 コマンドラインでのキーストア・パスワードの変更

コマンドラインでchangeKeyStorePasswordスクリプトを使用してキーストアのパスワードを変更できます。たとえば、インスタンス名をsystemとすると、次のコマンドを使用してキーストア・パスワードを変更します。

svc.changeKeyStorePassword(appStripe='system', name='keystore2', currentpassword='currentpassword', newpassword='newpassword')

ここで、currentpasswordがこのキーストアの現在のパスワードであり、newpasswordが新しいパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

12.2.2.7 コマンドラインでのキーストアのエクスポート

コマンドラインでexportKeyStoreスクリプトを使用してキーストアをエクスポートできます。たとえば、ストライプ名をmystripe、エクスポートする別名をmyorakey、別名のパスワードをkeypassword1とすると、次のコマンドでキーストアをファイルにエクスポートします。

svc.exportKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myorakey', keypasswords='keypassword1', type='JKS',filepath='/tmp/file.jks')

ここでpasswordは、このキーストアのパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

このコマンドを使用して複数のキーをエクスポートするには、aliasesとkey passwordsのカンマ区切りリストを指定します。

対称鍵を含むキーストアをエクスポートする場合は、JCEKSタイプを使用します。例:

svc.exportKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myorakey', keypasswords='keypassword1', type='JCEKS',filepath='/tmp/file.jks')

関連項目:

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

12.2.2.8 コマンドラインでのキーストアのインポート

コマンドラインでmportKeyStoreスクリプトを使用してキーストアをインポートできます。たとえば、ストライプ名をmystripe、インポートする別名をmyorakey、別名のパスワードをkeypassword1とすると、次のコマンドでオペレーティング・システム・ファイルからキーストアをインポートします。

svc.importKeyStore(appStripe='mystripe', name='keystore2', password='password',aliases='myorakey', keypasswords='keypassword1', type='JKS', permission=true, filepath='/tmp/file.jks')

ここでpasswordは、キーストア・パスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

このコマンドを使用して複数のキーをインポートするには、aliasesとkey passwordsのカンマ区切りリストを指定します。

関連項目:

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

12.3 キーストア・サービスでの証明書の管理

この項では、キーストア・サービスで証明書を管理する方法について説明します。内容は次のとおりです。

- 証明書のライフサイクルについて

- 一般的な証明書の操作

12.3.1 証明書のライフサイクルについて

キーストア・サービス・キーストアに存在する証明書の一般的なライフサイクル・イベントは、次のとおりです。

- 鍵のペアの自己署名証明書が自動的に作成されます。

- 証明書に対して証明書署名リクエスト(CSR)が生成され、ファイルに保存できます。

- CSRは認証局に送られます。認証局は送信者を検証し、署名し、署名付きの証明書を返送します。

- 証明書がキーストアにインポートされます。証明書はテキスト・ボックスに貼り付けることも、ファイル・システムからインポートすることもできます。ユーザー証明書も信頼できる証明書(CA証明書ともいいます)も、このようにインポートできます。

- 証明書または信頼できる証明書が、キーストアからファイルにエクスポートされます。

- 証明書または信頼できる証明書が、キーストアから削除されます。

12.3.2 一般的な証明書の操作

この項では、一般的な証明書の操作を説明します。

- Fusion Middleware Controlでの鍵ペアの生成

- コマンドラインでの鍵ペアの生成

- Fusion Middleware Controlでの証明書に対するCSRの生成

- コマンドラインでの鍵ペアに対するCSRの生成

- Fusion Middleware Controlを使用した証明書または信頼できる証明書のインポート

- コマンドラインでの証明書のインポート

- Fusion Middleware Controlでの証明書または信頼できる証明書のエクスポート

- コマンドラインでの証明書または信頼できる証明書のエクスポート

- Fusion Middleware Controlでの証明書の削除

- コマンドラインでの証明書の削除

- Fusion Middleware Controlでの証明書のパスワードの変更

- コマンドラインでの証明書のパスワードの変更

12.3.2.1 Fusion Middleware Controlでの鍵ペアの生成

関連する鍵ペアとともに証明書を生成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「管理」をクリックします。

6. パスワードで保護されたキーストアの場合は、パスワードの入力が求められます。キーストア・パスワードを入力し、「OK」をクリックします。

7. 「証明書の管理」ページが表示されます。

「有効期限」列を使用すると、有効期限が近付いている証明書および期限切れの証明書を迅速に評価できます。

「鍵ペアの生成」ボタンをクリックします。

8. 「鍵ペアの生成」ダイアログ・ボックスが表示されます。

9. 次の情報を入力します。

- 別名(必須)

- 共通名(必須)

- 組織単位

- 組織

- 市区町村

- 都道府県

- 国: ドロップダウン・ボックスから選択します。

- RSAキー・サイズ: ドロップダウン・ボックスから選択します。デフォルトは1024バイトです。

10. 「OK」をクリックします。
新しい証明書が証明書の一覧に表示されます。

11. 証明書の別名をクリックすることで、証明書の詳細を表示できます。

生成された鍵ペアはCA署名付き証明書でラップされています(デモCA使用)。この証明書をSSLなどの信頼を確立する必要のある場所で使用するには、アプリケーションはトラスト・ストアとしてドメイン・トラスト・ストア(デモCA証明書を含むため)を使用するか、もしくは証明書をカスタムのアプリケーション固有のトラスト・ストアにインポートする必要があります。

12.3.2.2 コマンドラインでの鍵ペアの生成

コマンドラインでgenerateKeyPairスクリプトを使用して、キーストア用の鍵ペアを生成できます。たとえば、appstripe2というアプリケーション・ストライプがあるとすると、次のコマンドでは別名がmyaliasの鍵ペアが作成されます。

svc.generateKeyPair(appStripe='appstripe2', name='keystore2', password='password', dn='cn=www.example.com', keysize='1024', alias='myalias', keypassword='keypassword')

ここで、passwordはキーストア・パスワードで、keypasswordは別名のパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

生成された鍵ペアはCA署名付き証明書でラップされています(デモCA使用)。この証明書をSSLなどの信頼を確立する必要のある場所で使用するには、アプリケーションはトラスト・ストアとしてドメイン・トラスト・ストア(デモCA証明書を含むため)を使用するか、もしくは証明書をカスタムのアプリケーション固有のトラスト・ストアにインポートする必要があります。

12.3.2.3 Fusion Middleware Controlでの証明書に対するCSRの生成

証明書または信頼できる証明書用のCSRを生成する手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「管理」をクリックします。

6. パスワードで保護されたキーストアの場合は、パスワードの入力が求められます。キーストア・パスワードを入力し、「OK」をクリックします。

7. 「証明書の管理」ページが表示されます。証明書に対応する行を選択して、「CSRの生成」をクリックします。

8. 「CSRの生成」ダイアログ・ボックスが表示されます。

次の操作を実行できます。

- CSR全体をテキスト・ファイルにコピーして貼り付けて、「閉じる」をクリックします。
または

- 「CSRのエクスポート」をクリックすると、CSRが自動的にファイルに保存されます。

生成された証明書リクエストを認証局(CA)に送信すると、CAから署名付きの証明書が返送されます。

12.3.2.4 コマンドラインでの鍵ペアに対するCSRの生成

コマンドラインでexportKeyStoreCertificateRequestスクリプトを使用して、鍵ペアに対してCSRを生成できます。たとえば、アプリケーション・ストライプをstripe1とすると、次のコマンドで鍵ペアtestaliasからCSRを生成できます。

svc.exportKeyStoreCertificateRequest(appStripe='stripe1', name='keystore1', password='password', alias='testalias', keypassword='keypassword', filepath='/tmp/csr-file')

ここで、passwordはキーストア・パスワードで、keypasswordは別名のパスワードです。CSRはオペレーティング・システム・ファイルにエクスポートされます。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

12.3.2.5 Fusion Middleware Controlを使用した証明書または信頼できる証明書のインポート

パスワードで保護されたキーストアに証明書をインポートする手順は次のとおりです。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「管理」をクリックします。

6. パスワードで保護されたキーストアの場合は、パスワードの入力が求められます。キーストア・パスワードを入力し、「OK」をクリックします。

7. 「証明書の管理」ページが表示されます。「インポート」をクリックします。

8. 「証明書のインポート」ダイアログ・ボックスが表示されます。

フォームに次のように入力します。

- 証明書のタイプについて、ドロップダウン・リストの「証明書」または「信頼できる証明書」のいずれかを選択します。

- ドロップダウン・リストから別名を選択します。

- 証明書ソースを指定します。「証明書または証明連鎖の貼付け」オプションを使用する場合は、証明書を直接テキスト・ボックスにコピーして貼り付けます。「証明書または証明連鎖を含むファイルの選択」オプションを使用する場合は、「参照」をクリックしてオペレーティング・システムからファイルを選択します。

- 「OK」をクリックします。インポートされた証明書または信頼できる証明書は、証明書の一覧に表示されます。

9. 「OK」をクリックします。
証明書が証明書の一覧に表示されます。

12.3.2.6 コマンドラインでの証明書のインポート

コマンドラインでimportKeyStoreCertificateスクリプトを使用して証明書をインポートできます。たとえば、アプリケーション・ストライプをappstripe1とすると、次のコマンドで別名がmykeyの証明書をオペレーティング・システム・ファイルからインポートできます。

svc.importKeyStoreCertificate(appStripe='appstripe1', name='keystore2', password='password', alias='mykey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

ここで、passwordはキーストア・パスワードで、keypasswordは別名のパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

12.3.2.7 Fusion Middleware Controlでの証明書または信頼できる証明書のエクスポート

次の手順を実行して、証明書または信頼できる証明書をエクスポートします。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「管理」をクリックします。

6. パスワードで保護されたキーストアの場合は、パスワードの入力が求められます。キーストア・パスワードを入力し、「OK」をクリックします。

7. 「証明書の管理」ページが表示されます。証明書に対応する行を選択して、「エクスポート」をクリックします。

8. 証明書のエクスポート・ダイアログが表示されます。

次の操作を実行できます。

- 証明書全体をテキスト・ファイルにコピーして貼り付けて、「閉じる」をクリックします。
または

- 「証明書のエクスポート」をクリックすると、証明書が自動的にファイルに保存されます。

12.3.2.8 コマンドラインでの証明書または信頼できる証明書のエクスポート

コマンドラインでexportKeyStoreCertificateスクリプトを使用して証明書をエクスポートできます。たとえば、アプリケーション・ストライプをappstripe1とすると、次のコマンドで別名がmykeyの証明書をオペレーティング・システム・ファイルにエクスポートできます。

svc.exportKeyStoreCertificate(appStripe='appstripe1', name='keystore2', password='password', alias='mykey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

ここで、passwordはキーストア・パスワードで、keypasswordは別名のパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

12.3.2.9 Fusion Middleware Controlでの証明書の削除

次の手順を実行して、証明書を削除します。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「管理」をクリックします。

6. パスワードで保護されたキーストアの場合は、パスワードの入力が求められます。キーストア・パスワードを入力し、「OK」をクリックします。

7. 「証明書の管理」ページが表示されます。証明書に対応する行を選択して、「削除」をクリックします。

8. 「証明書の削除」ダイアログが表示されます。

削除するかどうかを確認するメッセージが表示されます。「OK」をクリックします。

12.3.2.10 コマンドラインでの証明書の削除

コマンドラインでdeleteKeyStoreEntryスクリプトを使用してキーストアから証明書を削除できます。たとえば、アプリケーション・ストライプをappstripeとすると、次のコマンドで別名がorakeyの証明書を削除できます。

ssvc.deleteKeyStoreEntry(appStripe='appstripe', name='keystore2', password='password', alias='orakey', keypassword='keypassword')

ここで、passwordはキーストア・パスワードで、keypasswordは別名のパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

12.3.2.11 Fusion Middleware Controlでの証明書のパスワードの変更

次の手順を実行して、証明書のパスワードを変更します。

1. Fusion Middleware Controlにログインします。

2. ナビゲーション・ペインから、目的のドメインを見つけます。

3. 「セキュリティ」→「キーストア」に移動します。「キーストア」ページが表示されます。

4. キーストアがその中に存在するストライプを展開します。キーストアに対応する行を選択します。

5. 「管理」をクリックします。

6. パスワードで保護されたキーストアの場合は、パスワードの入力が求められます。キーストア・パスワードを入力し、「OK」をクリックします。

7. 「証明書の管理」ページが表示されます。証明書に対応する行を選択して、「パスワードの変更」をクリックします。

8. 「キー・パスワードの変更」ダイアログが表示されます。

9. 古いパスワードと新しいパスワードを入力し、「OK」をクリックします。

12.3.2.12 コマンドラインでの証明書のパスワードの変更

コマンドラインでchangeKeyPasswordスクリプトを使用して証明書のパスワードを変更できます。たとえば、アプリケーション・ストライプをsystem1とすると、次のコマンドで別名がtestkeyの証明書を削除できます。

svc.changeKeyPassword(appStripe='system1', name='keystore', password='password', alias='testkey', currentkeypassword='currentkeypassword', newkeypassword='newkeypassword')

ここで、passwordはキーストア・パスワードで、keypasswordは証明書の別名のパスワードです。第12.5項では、OPSSサービス・コマンド・オブジェクトの取得方法を説明します。

関連項目:

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

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

この項では、コンポーネントおよびサービスでキーストア・サービスを使用してキーおよび証明書を管理する方法について説明します。この項の内容は次のとおりです。

- syncKeyStoresコマンドの使用

- Oracle WebLogic Serverとの統合

- ノード・マネージャとの統合

- アイデンティティ・ストア・サービスとの統合

12.4.1 syncKeyStoresコマンドの使用

Oracle WebLogic Server環境では、キーストアおよびトラストストアの「実情のソース」はOPSSセキュリティ・ストアで、これは中央セキュリティ・ストアとして機能します。すべてのOracle Fusion Middlewareスタック・コンポーネントでこの中央ストアを使用することをお薦めしますが、中央インフラストラクチャ・コンポーネント(Oracle WebLogic Server、ノード・マネージャなど)では、ローカル・キーストア・インスタンスを使用するためのブートストラップが必要です。

中央セキュリティ・ストアからローカル・ファイル・インスタンスを作成するには、WLST syncKeyStoresコマンドを使用します。同期化は、データベース・セキュリティ・ストアからキー・データを読み取ってローカル・ファイル・インスタンスと同期化する、一方向の手順です。

たとえば、中央セキュリティ・ストアでドメイン・トラスト・ストアを更新する際に、このコマンドを使用すると、Oracle Weblogic Serverで使用されるローカル・キーストアのコピーを中央ストアと同期化できます。

- syncKeyStoresコマンドの使用方法

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

12.4.1.1 syncKeyStoresコマンドの使用方法

syncKeyStoresコマンドの構文は、次のとおりです。

syncKeyStores ()

このコマンドは、中央リポジトリで「システム」ストライプを検索し、そのコンテンツをDOMAIN_HOME/config/fmwconfigディレクトリの下にあるkeystores.xmlというファイルにダウンロードします。それは、同じファイルにドメイン・トラストストアのコンテンツもダウンロードします。

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

syncKeyStoresコマンドを使用するタイミングを判別するには、次のガイドラインを使用します。

- 更新中のキーストアがOracle WebLogic Serverに属する場合、そのキーストアは「システム」ストライプの下に表示されます(「demoidentity」キーストアなど)。

- (信頼できる証明書の追加または削除によって)ドメイン・トラスト・ストアを更新する場合は、Oracle WebLogic Serverの同期コマンドを起動します。

- Webサービスなどの階層型コンポーネントのキーストアを更新する場合、Oracle Web Services ManagerまたはJavaEEアプリケーションでは、同期コマンドを実行する必要はありません。このようなコンポーネントは、中央セキュリティ・ストアからキー・マテリアルに直接アクセスします。

12.4.2 Oracle WebLogic Serverとの統合

Oracle WebLogic Serverで使用するキーストアを構成する際に、キーストア・サービスを使用してキーおよび証明書を生成できます。

Oracle WebLogic ServerでのキーストアおよびSSL構成の詳細は、次を参照してください。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのキーストアの構成に関する説明

- 『Oracle WebLogic Serverセキュリティの管理』の「SSLの構成」

12.4.3 ノード・マネージャとの統合

キーストア・サービスを使用するようにノード・マネージャを構成できます。詳細は、『Oracle Fusion Middlewareの管理』のノード・マネージャの構成によるOPSSキーストア・サービスの使用に関する説明を参照してください。

ノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャの管理』を参照してください。

12.4.4 アイデンティティ・ストア・サービスとの統合

アイデンティティ・ストアからLDAPサーバーにSSL通信を構成できます。詳細は、8.5.2項を参照してください。

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

キーストア・サービスでは、キーストアの作成と管理、証明書のエクスポート、鍵ペアの生成などのキーストア操作に、専用のコマンドラインのコマンド・セットを使用します。これらのコマンドの使用方法は似ていますが、他のOPSSコマンドとは異なります。

キーストア・サービス・コマンド・セットを使用するための開始点はgetOpssServiceです。これは次の操作を可能にするOPSSサービス・コマンド・オブジェクトを取得します。

- サービスに対してコマンドを実行する

- コマンド・ヘルプを表示する

一般的な構文は次のとおりです。

variable = getOpssService(name='service_name')

説明

- variableはコマンド・オブジェクトを格納します。

- サービス名は、コマンド・オブジェクトを取得する対象のサービスを指します。有効な値は、KeyStoreServiceのみです。

例:

svc = getOpssService(name='KeyStoreService')

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

キーストア・サービス・コマンドに対するヘルプを表示するには、第12.5項に示したように、サービス・コマンド・オブジェクトの取得から始めます。このオブジェクトを、ヘルプ・コマンドおよび当該のコマンドとともに使用します。

すべてのキーストア・サービス・コマンドのリストを取得するには、次のように入力します。

svc.help()

特定のコマンドに対するヘルプを表示するには、次のように入力します。

svc.help('command-name')

たとえば次のように入力すると、exportKeyStoreコマンドに対するヘルプが表示されます。

svc.help('exportKeyStore')

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

キーストア・サービス・コマンドの構文情報および参照情報は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のOPSSキーストア・サービス・コマンドに関する説明を参照してください。

13 Oracle Fusion Middleware監査サービスの概要

この章では、Oracle Fusion Middlewareの監査サービスの概要を示します。

Oracle Fusion Middlewareにおいて、監査はアカウンタビリティを実現する手段であり、また、だれが、いつ、何を行ったかというタイプの質問への回答を提供します。この章の内容は次のとおりです。

- 第13.1項「Oracle Fusion Middleware監査フレームワークの利点と機能」

- 第13.2項「監査機能の概要」

- 第13.3項「Oracle Fusion Middleware監査フレームワークの概念」

- 第13.4項「監査メタデータ・モデル」

- 第13.5項「監査定義ファイルについて」

13.1 Oracle Fusion Middleware監査フレームワークの利点と機能

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

- 監査の目的

- 現在の監査の課題

- Oracle Fusion Middleware監査フレームワークについて

13.1.1 監査の目的

コンプライアンスがビジネス要件の不可欠な要素になりつつある現在、監査のサポートもエンタープライズ・デプロイメントにおける注目の的になりつつあります。顧客は、追加設定なしですぐに使用できる監査サポートを提供するアプリケーション・ベンダーを探しています。また、カスタム・アプリケーションをデプロイするミドルウェアの顧客は、デプロイされる監査が必要な全アプリケーションの監査を集中管理したいと考えています。

IT組織では、コンプライアンス、監視および分析という要件の観点から、主要な監査機能を探しています。

コンプライアンス

コンプライアンスがエンタープライズにおける主要な要件であることは、明白です。Sarbanes-Oxley法(財務)やHealth Insurance Portability and Accountability Act (HIPAA: 医療保険)のような規制により、多くの顧客は現在、アプリケーションやデバイスで、アイデンティティ情報およびユーザー・アクセスの監査を実行できる必要があります。これらには、次のようなイベントが含まれます。

- ユーザー・プロファイルの変更

- アクセス権の変更

- ユーザー・アクセス・アクティビティ

- 操作アクティビティ(アプリケーションの起動と停止、アップグレード、バックアップなど)

これにより、コンプライアンス担当者は、コンプライアンス・ポリシーを定期的に見直すことができます。

監視

監査データからは通常、監視目的のために、豊富なデータ・セットが得られます。公開されるログ・データおよびコンポーネント・メトリックだけでなく、監査データを使用してダッシュボードを作成したり、アラート用のキー・パフォーマンス・インディケータ(KPI)を設定したりして、様々なシステムの状態を継続的に監視することもできます。

分析

また、監査データを分析し、管理効果を評価することもできます。監査データは、リスク分析にも使用できます。履歴データに基づいてリスク・スコアを計算し、任意のユーザーに割り当てることもできます。ユーザー・アクセスのどのような実行時評価にも、システムに対するアクセスを保護するための追加の基準として様々なリスク・スコアを含めることができます。

13.1.2 現在の監査の課題

監査要件を満たすため、IT組織ではしばしばデプロイされるアプリケーションに対する監査サポートの欠如と闘っています。それは、次の点に対して信頼できる標準が存在していないからです。

- 監査レコードの生成

- 監査レコードのフォーマットと格納

- 監査ポリシーの定義

その結果、現在の監査ソリューションには、次のような多くの大きな問題点があります。

- 集中管理される監査フレームワークがありません。

- 監査サポートの品質がアプリケーションごとにまちまちです。

- 監査データがエンタープライズ全体に散乱しています。

- コンポーネント間の意味のある分析を実行するには、その前に複雑なデータの関係付けが必要となります。

- 監査ポリシーとその構成も散乱しています。

これらの要因により、IT組織は適切な監査ソリューションの構築および維持にかなりの時間とリソースを割いています。データが個々のサイロに散乱していて、一貫性も集中管理もない状態では、様々なベンダーが現時点における独自の監査機能を使用して実現しているアプリケーション間に統一性がなく、監査ソリューションも脆弱になりがちです。

13.1.3 Oracle Fusion Middleware監査フレームワークについて

Oracle Fusion Middleware監査フレームワークは、集中管理された監査フレームワークをミドルウェアの製品ファミリに提供するよう設計されています。このフレームワークは、次のものに対して監査サービスを提供します。

- ミドルウェア・プラットフォーム - これには、Oracle Platform Security Services (OPSS)やOracle Web ServicesなどのJavaコンポーネントが含まれます。これらは、ミドルウェアにデプロイされたアプリケーションによって活用されるコンポーネントです。間接的には、これらのJavaコンポーネントを使用するデプロイ済アプリケーションはすべて、プラットフォーム・レベルで発生する監査イベントから利点を得られます。

- Java EEアプリケーション - 目的は、Oracle自体のJava EEベースのコンポーネントをはじめとするJava EEアプリケーションにサービスを提供することです。Java EEアプリケーションは、アプリケーションに固有な監査イベントを作成できます。

- システム・コンポーネント - Oracle HTTP Serverなどのシステム・コンポーネントについても、監査サービスによって、Javaコンポーネントの場合と同様のエンドツーエンドの構造(C/C++ベースのアプリケーション用の監査APIなど)が実現されます。

関連項目:

『Oracle Fusion Middlewareの管理』のOracle Fusion Middleware主要概念の理解に関する説明

13.2 監査機能の概要

Oracle Fusion Middleware監査フレームワークおよび監査サービスの主な機能には、次のものがあります。

- 一連のJavaコンポーネント、システム・コンポーネントおよびアプリケーション全体にわたって監査を管理するための統一的なシステム

- 次の機能を含む、Javaコンポーネント監査の広範なサポート

- Oracle Platform Security Servicesによる非監査対応アプリケーションの監査のサポート

- 任意のアプリケーション・レベルでの監査データ検索機能

- 認証履歴および認証失敗、認可履歴、ユーザー管理およびその他の共通トランザクション・データの取得

- 柔軟な監査ポリシー

- 事前生成済の監査ポリシーや顧客でよく使用される監査イベントの取得機能などを利用した、容易なポリシー構成

- ツリー状のポリシー構造による簡便なポリシー設定

- ビルトインのコンプライアンス・レポート作成機能

- Oracle Fusion Middleware監査フレームワークは、Oracle BI Publisherのすぐに使用可能な分析レポート作成機能を提供します。複数のコンポーネントにわたって複数の次元(実行コンテキストID (ECID)やユーザーIDなど)でデータを分析できます。また、これらのレポートをプリファレンスに従ってカスタマイズすることもできます。

- 集中管理された監査データに基づいてレポートを作成します。

- 顧客は、レポートをカスタマイズしたり、公開された監査スキーマに基づいて独自のレポートを作成することができます。
詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

- 監査レコードの格納
監査データ・ストア(データベース)とファイル(バスストップ)を使用できます。すべての監査レコードに共通の場所を維持することにより、管理が容易になります。

監査データ・ストアを使用することにより、Oracle Business Intelligence Publisherを使用したレポートの生成が可能になります。

- 共通の監査レコード・フォーマット
監査証跡は次の特徴を持ちます。

- 結果(ステータス)、イベントの日時、ユーザーなどのベースライン属性

- 認証方式、ソースIPアドレス、ターゲット・ユーザー、リソースなどのイベント固有の属性

- 実行コンテキストID (ECID)やセッションIDなどのコンテキスト属性

- 監査ポリシー構成用の共通のメカニズム
Oracle Fusion Middleware監査フレームワークは、ドメイン内で監査ポリシーを構成するための統一的な手段を提供します。

- Oracle Fusion Middlewareのインフラストラクチャの活用

- Oracle Fusion Middlewareコンポーネントおよびサービス間での使用が可能

- Oracle Enterprise Manager Fusion Middleware Controlとの統合により、UIベースの構成と管理が可能

- wlstとの統合により、コマンドラインでのスクリプトベースの構成が可能

- Oracle Platform Security ServicesのSPIインフラストラクチャを活用

- アプリケーションでの監査フレームワークとの統合を可能にする動的メタデータ・モデルの使用

- アプリケーションはいつでも監査サービスに登録が可能

- 監査イベントを定義および記録するために監査フレームワークをアプリケーションが活用する機能を簡素化

- イベント定義のバージョニングを提供し、監査クライアントによるリリース・サイクルに依存しない定義のアップグレードが可能に

13.3 Oracle Fusion Middleware監査フレームワークの概念

この項では、Oracle Fusion Middleware監査フレームワークの次の基本概念を説明します。

- 監査アーキテクチャ

- 重要な技術的概念

- 監査メタデータ・ストア

- 監査データ記憶域

- 分析

13.3.1 監査アーキテクチャ

図13-1は、Oracle Fusion Middleware監査フレームワークのアーキテクチャを示しています。

図13-1 監査アーキテクチャ

この図は、開発時および実行時のサービス、監査イベント・フローおよび主要機能を含めた、アーキテクチャの必須要素を示しています。これらの要素については、次に説明しています。

13.3.1.1 監査サービス・モデル

フレームワークの中心に監査サービス・モデルがあり、他のOPSSサービスと同様に、このモデルではJava EEおよびSEアプリケーションおよびOracleコンポーネントに一様に標準ベースの統合フレームワークが提供されます。

Oracle Fusion Middleware全体で使用することによって、このモデルでは、プラットフォームの次のような監査機能を効率的に使用できるようになります。

- 監査クライアントが監査イベント定義を管理し、ビルドおよびリリース・サイクルに関係なくバージョン変更を行うことができる動的監査メタデータ・モデル。監査イベント定義は、再デプロイメント時に動的に更新できます。

- 設計から開発およびデプロイメントに至るまでのアプリケーション・ライフサイクルのすべての側面のサポート。

- 監査サービスにアプリケーションを登録する登録サービス。

- 宣言的: Java EEアプリケーションでは、デプロイメント時にMETA-INFディレクトリのearファイルとしてXML構成をパッケージ化することによって登録が実行されます。

- プログラムの使用: 監査登録APIを呼び出すことによって登録します。

- コマンドラインで、WLSTコマンドによって登録します。

- 製品テンプレートでセキュリティ・アーティファクトをバンドルすることによって登録します(第7.1項を参照)。

13.3.1.2 監査API

このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。アプリケーションでは実行時、これらのAPIを適宜コールして、監査ポリシーを管理したり、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査したりする場合もあります。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。

監査フレームワークにより、次のAPIが提供されます。

- 監査サービスAPI

- 監査クライアントAPI

- 監査管理サービスAPI

詳細は、第25章を参照してください。

13.3.1.3 ランタイム・サポートおよび監査イベント・フロー

このプロセスは、アプリケーション・サーバー・インスタンス内で監査可能なイベント(たとえばログイン)が発生した場合に、フレームワーク内で実行されるアクションを示すことにより説明できます。

注意:

図13-1で示したアーキテクチャには、監査データ・ストアが含まれ、監査データ・ストアが構成されていないサイトの場合、監査レコードはバスストップ・ファイル内にあります。

1. アプリケーションのデプロイメント時または監査サービスの起動時に、Java EEアプリケーションまたはOracleコンポーネントなどのクライアントが監査サービスに登録されます。

2. サービスはアプリケーションの事前構成済の監査定義ファイルを読み取り、監査定義でメタデータ・ストアを更新します。

3. ユーザーがそのコンポーネントまたはアプリケーションにアクセスすると、イベントを監査するために監査API関数がコールされます。

4. 監査フレームワークは、このタイプ、ステータス、および特定の属性のイベントを監査する必要があるかどうかを確認します。

5. 監査が必要な場合は監査関数が起動され、監査イベント構造体が作成されて、ステータス、イニシエータ、リソース、ECIDなどのイベント情報が収集されます。

6. イベントは、バスストップとして知られる中間的な場所にあるローカル・ファイルに格納されます。各コンポーネントは個別のバスストップを持ちます。

7. 監査ストアとしてデータベースが構成されている場合、監査ローダーはバスストップからイベントをプルし、アプリケーションのメタデータを使用してデータを書式化し、データを監査ストアに移動します。

8. Oracle BI Publisherを使用して、監査データからレポートを生成することもできます。事前定義済のレポート・セットも使用できます。(第15章「監査分析と監査レポートの使用」を参照してください。)

監査が失敗した場合のアプリケーションの動作

アプリケーションは、どのような理由で監査イベントを記録できない場合であっても、実行を中止することはありません。

13.3.2 重要な技術的概念

この項では、Oracle Fusion Middleware監査フレームワークの重要な概念を説明します。

監査対応コンポーネント

監査対応とは、Oracle Fusion Middleware監査フレームワークに統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントを指します。Oracle Internet Directoryは監査対応コンポーネントの一例です。

スタンドアロン・アプリケーションは、jps-config.xmlファイルを使用して構成を行うことで、Oracle Fusion Middleware監査フレームワークとの統合が可能です。詳細は、付録Aの<serviceInstances>を参照してください。

監査メタデータ・ストア

監査メタデータ・ストアには、コンポーネント、および監査フレームワークに統合されたアプリケーションに対する監査イベント定義が格納されます。

詳細は、13.3.3項を参照してください。

監査データ・ストア

監査データ・ストアは、監査イベント・レコードのリポジトリです。これは、リポジトリ作成ユーティリティ(RCU)によって作成される、事前定義済のOracle Fusion Middleware監査フレームワーク・スキーマが含まれるデータベースです。監査データ・ストアを構成すると、監査ローダーが監査データ・ストアを認識し、データが監査データ・ストアに定期的にアップロードされるようになります。監査ストア内の監査データは累積されることが想定され、時間の経過に伴って増加します。監査データ・ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型データベースであるのが理想的です。

監査データベースには、Oracleコンポーネントおよび監査フレームワークに統合されたユーザー・アプリケーションによって生成された監査イベントが格納されます。

注意:

監査メタデータ・ストアは、監査データ・ストアとは別のものです。

このデータ・ストアの詳細は、第13.3.4項を参照してください。RCUを使用した監査スキーマの作成の詳細は、第14.2.1項を参照してください。

監査定義ファイル

アプリケーションでは、監査定義ファイルを使用して、監査サービスに、監査アクションを管理する監査ルール(イベント、フィルタなど)を指定します。

詳細は、13.5項を参照してください。

監査イベント

Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。また、アプリケーションはこのフレームワークにより、アプリケーションに固有なイベントを定義することもできます。

これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンドライン・ツール)により更新できます。

監査ローダー

監査ローダーは、Oracle WebLogic Serverインスタンスのモジュールであり、そのインスタンスの監査アクティビティをサポートします。監査データ・ストを構成すると、監査ローダーは、そのインスタンス内で実行されているすべてのコンポーネントについての監査レコードを収集し、それらのレコードをデータ・ストアにロードします。

Javaコンポーネントの場合、監査ローダーは、コンテナ起動の一部として起動されます。

システム・コンポーネントでは、(registerAudit() WLSTコマンドを使用して)監査ストアに登録し、コンテナの監査ローダーを使用してイベントをアップロードすることも、コマンドラインのスタンドアロン監査ローダーを使用することもできます。

監査ポリシー

監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーは、コンポーネント・レベルまたはドメイン・レベルのいずれかで定義できます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

Oracle Fusion Middleware監査フレームワークには、次のようないくつかの事前定義済のポリシー・タイプが用意されています。

- なし(対象のコンポーネントに対して監査は無効になっています)

- 低(定義はコンポーネントによって異なります)

- 中(定義はコンポーネントによって異なります)

- 高(定義はコンポーネントによって異なります)

- カスタム(監査イベントの範囲を絞るためにフィルタを実装します)

監査ポリシーのコンポーネント・タイプ

監査するコンポーネントのタイプを指します。たとえば、Oracle Internet Directoryは認証時の監査可能イベントのソースになります。

コンポーネントごとに監査可能なイベントのリストは、第C.1項「監査イベント」を参照してください。

監査サービス

監査サービス・モデルは、Java EEおよびSEアプリケーションで監査機能を利用できるように、標準ベースの統合フレームワークを提供します。

バスストップ

バスストップは、監査データ・レコードが監査データ・ストアにプッシュされる前に格納されるローカル・ファイルです。監査データ・ストアが構成されていない場合、監査データはこれらのバスストップ・ファイルに残ります。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。監査データ・ストアが配備されている場合、バスストップはコンポーネントと監査データ・ストア間の中間的な場所として機能します。これらのローカル・ファイルは、構成可能な時間間隔に基づいて、監査データ・ストアに定期的にアップロードされます。

監査データ・ストアの主な利点は、複数のコンポーネントの監査データ(すべてのミドルウェア・コンポーネントやインスタンスにおける認証失敗など)をレポート内で関係付けて結合できる点です。

イベント・フィルタ

一部の監査イベントには、イベントをログに記録する時点を制御するフィルタが実装されています。たとえば、特定のユーザーのOracle Internet Directoryコンポーネントへの正常なログインのイベントにフィルタを適用できます。

詳細は、第14.3項「監査ポリシーの管理」を参照してください。

構成MBean

監査構成はすべて、監査構成用Mbeansによって管理されます。Javaコンポーネントおよびアプリケーションの場合、これらのMbeansはドメイン管理サーバー内に存在し、監査構成は集中管理されます。システム・コンポーネントの場合は、コンポーネント・インスタンスごとに別々のMbeanインスタンスが存在します。Enterprise ManagerのUIおよびコマンドライン・ツールでは、これらのMbeansを使用して、監査構成を管理します。

Oracle Business Intelligence Publisher

監査データ・ストア内のデータは、Oracle Business Intelligence Publisherの特定のコンポーネント(主にシステム・コンポーネント)で使用可能な事前定義済のレポートにより公開されます。ユーザーは、これらのレポートにより、様々な基準に基づいて監査データをドリルダウンすることができます。例:

- ユーザー名

- 時間範囲

- アプリケーション・タイプ

- 実行コンテキストID (ECID)

Oracle Business Intelligence Publisherを使用して、独自の監査レポートを作成することもできます。

Oracle Platform Security Services

Oracle Fusion Middlewareの主要コンポーネントであるOracle Platform Security Servicesは、Java Authentication and Authorization Service (JAAS)やJava EEセキュリティなどのJava機能に対応するOracle Fusion Middlewareのセキュリティの実装です。

OPSSの詳細は、第1.1項「Oracle Platform Security Servicesとは」を参照してください。

13.3.3 監査メタデータ・ストア

監査メタデータ・ストアはメタデータ・モデルに対するリポジトリを提供し、コンポーネント監査定義、NLS翻訳エントリ、実行時ポリシーおよびデータベース・マッピング表を含みます。

注意:

監査メタデータ・ストアは、実際の監査レコードが格納される監査データ・ストアとは別のものです。

監査メタデータ・ストアは、次のような重要な監査機能をサポートします。

- 監査登録サービスは、イベント定義エントリを作成、変更および削除します。

- 監査実行時サービスは、イベント定義および実行時ポリシーを取得します。

- 監査データ・ローダーは、監査データを格納するための属性データベース・マッピングを作成します。

- 監査MBeanコマンドは、コンポーネント監査定義および実行時ポリシーを検索して変更します。

監査フレームワークは、次の3つのタイプのメタデータ・ストアをサポートしています。

- XMLファイルベース

- データベース

- LDAP

新しいアプリケーションが監査サービスに登録されると、次の監査アーティファクトが監査ストアに格納されます。

- カスタム属性グループ、カテゴリ、イベントおよびフィルタ・プリセット定義を含む監査イベント定義

- ローカライズされた翻訳エントリ

- カスタム属性/データベース列マッピング表

- 実行時監査ポリシー

13.3.4 監査データ記憶域

図13-1に示すように、監査データは2つのタイプの記憶域に配置できます。

- 監査データの中間的な記憶域となるバスストップ・ファイル。各コンポーネント・インスタンスは個別のバスストップにデータを書き込みます。
バスストップ・ファイルは、監査レコード用にすぐに使用できるデフォルトの記憶域メカニズムです。コンポーネントごとに個別のバスストップ・ファイルがあります。

バスストップ・ファイルはテキストベースで問合せが容易です。詳細は、第13.3.1項「監査アーキテクチャ」を参照してください。

- データベース内の永続的記憶域(監査データ・ストアとも呼ばれます)。
データベースを使用する場合は、ドメイン内のすべてのOracle Fusion Middlewareインスタンスのすべてのコンポーネントによって生成された監査レコードが、同じストアに書き込まれます。Oracle Business Intelligence Publisherレポートを利用するには、監査データ・ストアを使用する必要があります。

ファイルベースの記憶域から監査データ・ストアに移行できます。これには固有の構成手順を実行する必要があります。詳細は、第14.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

データベース・ストアを使用する利点

バスストップ・ファイルに監査レコードを格納する場合、実用面で次のような制限があります。

- ドメイン・レベルの監査データを表示できません。

- Oracle BI Publisherでレポートを実行できません。

一方、データベース監査データ・ストアを使用すると、次のような利点が得られます。

- Oracle Business Intelligence Publisherを使用してレポートを作成できます。

- バスストップでは監査レコードがインスタンス単位で格納されますが、データベース・ストアではドメイン内のすべてのコンポーネントのレコードを集中管理できます。

- ファイルベースの記憶域と比較してパフォーマンスが向上する可能性があります。

このような理由から、オラクル社は、監査機能を拡張するためにデータベース・ストアへの切替えをお薦めします。

13.3.5 分析

Oracle Fusion Middlewareでは、構造化レポート作成用のフル機能ツールとして、Oracle Business Intelligence Publisherを利用できます。独自のレポート作成アプリケーションを使用することもできます。

Oracle Business Intelligence Publisherでは、次のような多様な事前定義済レポートを使用できます。

- 作成済ユーザーおよび削除済ユーザー

- ユーザー・トランザクション

- 認証と認可の失敗

- ポリシー違反

Oracle Business Intelligenceの使用

- ユーザー名や日時の範囲などの基準に基づいてレコードを選択できます。
Oracle Business Intelligenceは、データベース監査ストアでのみ機能します。バスストップ・ファイルでは使用できません。

Oracle Business Intelligenceで使用可能な事前定義済監査レポートのタイプは、次のとおりです。

- エラーと例外

- 操作

- ユーザー・アクティビティ

- 認証と認可の履歴

- トランザクション履歴

詳細は、第C.2項「ビルトイン監査レポート」を参照してください。また、監査スキーマの詳細情報を使用して、必要に応じてカスタム監査レポートを作成することもできます。

13.3.6 監査ライフサイクルの理解

Oracle Fusion Middlewareコンポーネントおよびアプリケーションで構成される環境を監査している管理者の観点からすると、機能的な監査システムの実装における重要な段階は、次のとおりです。

- 共通監査フレームワークのアーキテクチャを理解します。
フレームワークの必須要素、アクションのフローおよび監査サービス・モデルの機能を確認するには、第13.3.1項を参照してください。

- アプリケーションを監査フレームワークと統合します。
統合手順の詳細は、第25.2項を参照してください。

- アプリケーションの監査イベントおよびそれらを監査スキーマにマップする方法を記述した監査定義ファイルを作成します。
このトピックの詳細は、第25.3項を参照してください。

- アプリケーションを監査サービスに登録します。
登録を有効にする方法はいくつかあります。詳細は、25.4項を参照してください。

- 監査情報をテスト環境から本番環境に移行します。
第6.6.3項を参照してください。

- 監査レポートを生成します。
監査レポート作成のツールおよび技法の説明は、第15章および付録Cに記載されています。

13.4 監査メタデータ・モデル

監査フレームワークは、アプリケーションがその監査アーティファクトを柔軟に指定することを可能にするメタデータ・モデルをサポートしています。アプリケーションは属性グループ、カテゴリおよびイベントを動的に定義できます。

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

- 監査アーティファクトのネーミング規則

- 属性グループ

- イベント・カテゴリとイベント

13.4.1 監査アーティファクトのネーミング規則

次のネーミング規則が、カテゴリ名、イベント名および属性名に適用されます。

- すべて英語のみで記述する必要があります。

- 25文字以下にする必要があります。

- 使用できる文字は、aからz、AからZおよび0から9のみです。

- 先頭は英字にする必要があります。

13.4.2 属性グループ

属性グループは監査属性の広範な分類を提供し、次の3つのタイプから構成されます。

- 共通属性グループには、コンポーネント・タイプ、システムIPアドレス、ホスト名など、すべてのアプリケーションに共通のシステム属性が含まれます。
IAU_COMMONデータベース表には、このグループ内の属性が含まれます。

- 汎用属性グループには、認証やユーザー・プロビジョニングなどの監査アプリケーション領域に対する属性が含まれます。

- カスタム属性グループには、特定のニーズに応じてアプリケーションで定義された属性が含まれます。カスタム・グループの属性は、そのコンポーネントのスコープに限定されます。

関連項目:

一般的なOPSS属性のリストは、表C-5を参照してください。

13.4.2.1 監査属性のデータ型

表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.4.2.2 共通属性グループ

共通属性グループは、IAU_COMMONデータベース表に格納されています。

13.4.2.3 汎用属性グループ

汎用属性グループは、ネームスペース、バージョン番号および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.4.2.4 カスタム属性グループ

カスタム属性グループは、ネームスペース、バージョン番号および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>

カスタム属性グループおよび属性は、IAU_CUSTOM表に格納されます。

13.4.3 イベント・カテゴリとイベント

監査イベント・カテゴリには、機能領域内の関連イベントが含まれます。たとえば、セッション・カテゴリには、ユーザー・セッションのライフサイクルで重要なログインおよびログアウト・イベントが含まれます。

イベント・カテゴリ自体は属性を定義しません。かわりに、コンポーネント内の属性およびシステム属性グループを参照します。

イベント・カテゴリには次の2つのタイプがあります。

- システム・カテゴリ

- コンポーネントとアプリケーション・カテゴリ

関連項目:

システム・カテゴリおよびイベントの定義は、表C-1を参照してください。

13.4.3.1 システム・カテゴリとイベント

システム・カテゴリは、共通および汎用属性グループを参照し、監査イベントを含みます。システム・カテゴリは、コンポーネント・イベント・カテゴリおよびイベントのベース・セットです。アプリケーションはそれらを直接参照し、監査イベントを記録して、フィルタ・プリセット定義を設定できます。

次の例は、メタデータ・モデルのいくつかの要素を示しています。

- 共通属性グループ

- 汎用属性グループidentityとauthorization

- 共通属性AuthenticationMethodを参照する属性を持つシステム・カテゴリUserSession

- UserLoginおよびUserLogoutなどの監査イベント

<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.4.3.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 監査定義ファイルについて

次の2種類の定義ファイルがあります。

- component_events.xml定義ファイル

- 翻訳ファイル

13.5.1 component_events.xmlファイル

component_events.xmlファイルでは、監査サービスで監査イベントをログに記録する際に必要な次のようなプロパティを指定します。

- 基本プロパティとメジャーおよびマイナー・バージョン

- コンポーネント・タイプ(アプリケーションが監査サービスに登録し、実行時監査インスタンスを取得するために使用するプロパティ)

- アプリケーションのメジャーおよびマイナー・バージョン

- 1つのカスタム属性グループ(含まれない場合もある)

- 属性参照およびイベントを含むイベント・カテゴリ

- コンポーネント・レベル・フィルタ定義

- 次を含む実行時ポリシー

- filterPreset - 監査フィルタ・レベルを指定します。

- specialUsers - 常に監査するユーザーを指定します。

- maxBusstopDirSize

- maxBusstopFileSize

実行時ポリシーの詳細は、第14.3項を参照してください。

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>

13.5.2 翻訳ファイル

翻訳ファイルは、様々な言語で監査定義を表示するために使用されます。

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

登録サービスでは、特定のルールを使用して、アプリケーションに対して監査メタデータが作成されます。このメタデータは、監査定義の様々なバージョンを管理し、監査データをロードしてレポートを生成するために使用されます。

13.5.3.1 バージョン番号

各監査定義には、整数のメジャーおよびマイナー・バージョン番号が必要です(例: major = 1 minor=3)。監査イベント定義を変更した場合は、マイナーまたはメジャー番号あるいはその両方を変更することによりバージョンIDを変更する必要があります。

監査登録サービスは、バージョン番号を使用してイベント定義の互換性およびバージョン間の属性マッピングを決定します。

注意:

これらのバージョン番号はOracle Fusion Middlewareのバージョン番号とは関係ありません。

Oracleコンポーネントのバージョニング

Oracleコンポーネントの登録時、監査登録サービスは、これが初めての登録であるかアップグレードであるかを確認します。

新規登録では、サービスは次の操作を実行します。

1. コンポーネントの監査および翻訳情報を取得します。

2. 定義を解析して検証し、監査メタデータ・ストアに格納します。

3. 属性/列マッピング表を生成し、監査メタデータ・ストアに保存します。

アップグレードについては、メタデータ・ストア内のコンポーネントの現在のメジャーおよびマイナー番号が新しいメジャーおよびマイナー番号と比較され、アップグレードを続行するかどうかを決定します。

JavaEEアプリケーションのバージョニング

アプリケーションの監査定義の変更時には、メジャーおよびマイナー番号を次のように設定することをお薦めします。

- マイナー・バージョン番号は、バージョン互換の変更(新しい監査定義から生成される属性データベース・マッピング表が、以前の属性データベース・マッピング表で作成された監査データでもそのまま使用できるような監査定義の変更)を加える場合にのみ増やします。
たとえば、現在の定義バージョンがmajor=2およびminor=1であるとします。属性データベース・マッピング表に影響しない新規イベントの追加時には、マイナー・バージョンを2に変更し(minor=2)、メジャー番号はそのままにします(major=2)。

- 新しいマッピング表が以前の表と互換性がないようなバージョン変更を加える場合には、メジャー・バージョン番号を増やします。

13.5.3.2 カスタム属性からデータベース列へのマッピング

新しいコンポーネントまたはアプリケーションの登録時、登録サービスはコンポーネントのカスタム属性から属性/データベース列マッピング表を作成し、この表を監査メタデータ・ストアに保存します。

属性/データベース列マッピング表は、アプリケーションの属性定義とデータベース列間で一意なマッピングを行うために必要です。監査ローダーはマッピング表を使用してデータを監査ストアにロードします。表はカスタム・データベース表IAU_CUSTOMから監査レポートを生成するためにも使用されます。

コンポーネントの監査定義の表示

WLSTコマンドcreateAuditDBViewを使用して、コンポーネントの監査定義のデータベース・ビューを作成できます。

コマンド構文の詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

createAuditDBViewコマンドを使用するには、コンポーネントの属性がデータベース列にマップされるしくみを理解しておく必要があります。詳細は次の説明を参照してください。

コンポーネントのマッピング表の理解

カスタム属性/データベース列マッピングには、属性名、データベース列名およびデータ型のプロパティがあります。

各カスタム属性定義には、マッピング順序番号が含まれている必要があります。同じデータ型の属性は、属性マッピング順序に従ってデータベース列にマップされます。たとえば、次のような定義ファイルがあるとします。

<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>

属性/データベース列マッピング表のバージョンIDは、カスタム属性グループのバージョンIDに一致します。これにより、アプリケーションは異なる監査定義バージョン間でも、属性マッピングの後方互換性を維持できます。バージョニングの詳細は、第13.5.3.1項を参照してください。

14 監査の構成と管理

この章では、日常的な監査管理タスクの実行方法を説明します。

関連項目:

Oracle Fusion Middlewareでの監査の予備知識については、第13章「Oracle Fusion Middleware監査サービスの概要」を参照してください。

- 第14.1項「監査管理タスク」

- 第14.2項「監査データ・ストアの管理」

- 第14.3項「監査ポリシーの管理」

- 第14.4項「監査のタイムスタンプ」

- 第14.5項「監査ログとバスストップ・ファイル」

- 第14.6項「データベース・ストアの拡張管理」

14.1 監査管理タスク

監査管理者は、次の手順に従って、サイトの監査の設定を注意深く計画する必要があります。

- 実装の計画
これには、監査レコード用に使用するストアのタイプやデータ・ストアの詳細構成などの計画が含まれます。

詳細は、第14.2項「監査データ・ストアの管理」を参照してください。

- ポリシー管理
必要な監査イベントが確実に生成されるように、適切な監査ポリシーを構成する必要があります。

アプリケーション環境の変化やコンポーネントおよびユーザーの追加などを監査ポリシーに反映する必要があるため、ポリシー管理は継続的なアクティビティになります。

詳細は、第14.3項「監査ポリシーの管理」を参照してください。

- レポート管理
これには、監査レポートと監査問合せの計画と構成が含まれます。

詳細は、第15章「監査分析と監査レポートの使用」を参照してください。

- データ管理
これには、企業ポリシーに基づいた、生成される監査データの格納に必要なデータベース・サイズの計画/増加、監査データのバックアップ、監査データの消去が含まれます。

監査データ・ストアの管理の詳細は、第14.6項「データベース・ストアの拡張管理」を参照してください。

14.2 監査データ・ストアの管理

監査フレームワークでは、追加設定なしですぐに、ファイル・システムを使用して監査レコードを格納します。ただし本番環境では、データベース監査データ・ストアを使用して、監査フレームワークのスケーラビリティと高可用性を確保することをお薦めします。

また、データベース内の監査データ・ストアを使用すると、Oracle Business Intelligence Publisherで使用可能な事前パッケージ済の監査レポートにより監査データを表示することができます。Oracle Business Intelligence Publisherは、12c (12.1.2)のCDパックで使用できます。

この項では、監査データ・ストアの次のような管理タスクについて詳細に説明します。

- RCUによる監査スキーマの作成

- 監査データソースの設定

- Javaコンポーネント用のデータベース監査データ・ストアの構成

- システム・コンポーネント用のデータベース監査データ・ストアの構成

- バスストップ・ファイルのチューニング

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

14.2.1 RCUによる監査スキーマの作成

監査レコードの永続的ストアとしてデータベースに切り替えるには、最初にリポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・ストアを作成する必要があります。リリース12.1.2では、追加設定なしで、コンパクトおよび拡張(デフォルト)という2つのプロファイルが提供されます。

この項では、監査スキーマの作成方法を説明します。

注意:

バスストップ・ファイルは、データベース記憶域が存在しない場合の監査レコードの格納先になります。

注意:

この説明では、RCUおよびデータベースが環境にインストール済であることを前提としています。詳細は、インストレーション・ガイドを参照してください。

データベース・スキーマの作成後は、次のことが可能になります。

- このスキーマを指し示すデータソースを作成します。

- ドメインの構成を更新し、監査レコードの監査データ・ストアを切り替えます(第14.2.3.2項「監査データ・ストアとバスストップ・ストレージの構成」を参照)。

注意:

第7章で示しているように、これらの処理は、監査アーティファクトの詳細を指定している場合は必要ありません。

始める前に

作業を開始する前に、使用するデータベースの詳細情報を収集し、DBA資格証明を入手してください。

データベース・スキーマの構成

ここに示す手順で、監査データ・ストアのスキーマを構成します。

手順は次のとおりです。

1. $RCU_HOME/binに移動し、RCUユーティリティを実行します。

2. 開始画面で「作成」を選択します。「次へ」をクリックします。

3. 「データベース接続の詳細」ページが表示されます。データベースの詳細を入力します。

「次へ」をクリックします。RCUによって前提条件が確認されるため、「OK」をクリックして続行します。

4. 「コンポーネントの選択」ページが表示されます。接頭辞の新規作成を選択して、DEV4などを入力します。接頭辞がスキーマ所有者および表領域の名前に適用されます。スキーマ・ユーザーが接頭辞を使用して作成されます(この例では、スキーマ・ユーザーはDEV4_IAU、DEV4_IAU_APPENDおよびDEV4_IAU_VIEWERです)。
また、スキーマのリストから「監査サービス」を選択し、これによって、次の2つのスキーマが自動的に選択されます。(注意: これらの2つのスキーマは補助スキーマにすぎないため、これらのスキーマ自体を選択しないでください。)

「次へ」をクリックします。RCUによってコンポーネントの前提条件が確認されるため、「OK」をクリックして続行します。

5. 「スキーマ・パスワード」ページが表示されます。

パスワードを入力し、「次へ」をクリックします。

6. 「表領域のマップ」ページが表示されます。「次へ」をクリックして、表領域の作成を承認します。

「OK」をクリックして、表領域の作成の確認ボックスを閉じます。

7. 「サマリー」ページが表示されます。

詳細を確認し、「作成」をクリックします。

8. スキーマの作成中にエラーが発生していないか確認します。「完了サマリー」ページでジョブが成功したことを確認します。

このプロセスの完了には数分かかります。

注意:

Oracle Fusion Middleware 12c (12.1.2)では、Edition Based Redefinition (EBR)に対して有効化されたOracle DatabaseにおけるIAUスキーマの作成はサポートされていません。

14.2.2 監査データソースの設定

第14.2.1項「RCUによる監査スキーマの作成」で説明したように、データベースに監査レコードを格納するデータベース・スキーマを作成した後、そのスキーマを指すOracle WebLogic Serverの監査データソースを設定する必要があります。

監査データソースを設定するには、次の手順を実行します。

注意:

このタスクは、Oracle WebLogic Server管理コンソールで実行します。

1. Oracle WebLogic Server管理コンソールに接続します。

http://host:7001/console

2. 「JDBC」で、「データソース」リンクをクリックします。

3. 「データソース」ページが表示されます。「新規」をクリックして新しいデータソースを作成します。

4. 新しいデータソースに関して、次の詳細情報を入力します。

- 名前: Audit_Data_Source-0などの名前を入力します。

- JNDI名: jdbc/AuditDB。

- データベースのタイプ: Oracle

- データベース・ドライバ: Oracleドライバ(Thin XA)バージョン9.0.1、9.0.2、10、11。

管理対象クラスタ・サーバーにデプロイする場合は、「管理サーバー」も選択します。これにより、ファイルからデータベース・ストアに切り替える際、該当するデータソースが監査データ・ストアに表示されます。

「次へ」をクリックします。

5. 「トランザクション・オプション」ページが表示されます。「次へ」をクリックします。

6. 「接続プロパティ」ページが表示されます。次の情報を入力します。

- データベース名: 接続先のデータベース名を入力します。これは通常SIDに対応します。

- ホスト名: データベースのホスト名を入力します。

- ポート: データベース・ポートを入力します。

- データベース・ユーザー名: RCUで作成した監査スキーマ名です。次の規則がこのエントリに適用されます。

- すべて大文字を使用します。

- データベースで監視スキーマを作成する際に使用したスキーマ接頭辞を付加します。

- スキーマ名を追加します。このデータソースでは、スキーマ名はIAU_APPENDです。

たとえば、スキーマ接頭辞に"ENG"を使用した場合は、ここで入力する値は"ENG_IAU_APPEND"となります。

- パスワード: RCUで作成した監査スキーマのパスワードです。

「次へ」をクリックします。

7. 次のページに、JDBCドライバ・クラスとデータベースの詳細情報が表示されます。デフォルトを選択し、「構成のテスト」をクリックして、接続をテストします。「接続は正常に確立されました」というメッセージが表示されたら、「次へ」をクリックします。エラーが表示された場合は、接続の詳細情報に戻って確認します。

8. 「ターゲットの選択」ページで、このデータソースを構成するサーバーを選択して、「終了」をクリックします。

14.2.2.1 複数のデータソース

スケーラビリティおよび高可用性を実現するために、監査データのOracle Real Application Clustersを構成できます。

詳細は、『Oracle Fusion Middleware高可用性ガイド』のReal Application Clustersに関する説明を参照してください。

14.2.3 Javaコンポーネント用のデータベース監査データ・ストアの構成

スキーマの作成後にデータベース・ベースの監査データ・ストアを構成するには、次の作業を行います。

- 作成した監査スキーマを指し示すデータソースの作成

- データソースを指し示す監査データ・ストアの構成

この項では、監査データ・ストアの構成に関連する次のタスクを説明します。

- 監査データ・ストアの構成の表示

- 監査データ・ストアとバスストップ・ストレージの構成

注意:

この手順で構成されるのは、Javaコンポーネント用の監査データ・ストアのみです。システム・コンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第14.2.4項「システム・コンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。

14.2.3.1 監査データ・ストアの構成の表示

注意:

このタスクは、Oracle Enterprise Manager Fusion Middleware Controlで実行します。

現在の監査データ・ストアの構成を確認する手順は次のとおりです。

1. 「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

2. 「監査サービス」セクションで、「構成」をクリックします。

このページには、次の項目が表示されます。

- データソースのJNDI名 - 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソースのJNDI名が表示されます。監査データ・ストアが構成されていない場合、このフィールドは空になります。デフォルトでは、データベースは構成されておらず、監査レコードはバスストップ・ファイルに格納されています。

- 監査ローダー頻度 - このフィールドは、バスストップ・ファイルから監査データ・ストアへデータを移動する頻度を秒数で表示します。

データソースの例は、第14.2.2項「監査データソースの設定」を参照してください。

14.2.3.2 監査データ・ストアとバスストップ・ストレージの構成

12cドメインでは、Oracle Fusion Middlewareドメインの作成時または拡張時に、製品テンプレートを使用して監査ストアをプロビジョニングできます。このプロセスの詳細は、第7章を参照してください。

監査ストアの構成に関連する特定のタスクを手動で実行することもできます。

- 監査レコードをファイルに格納する方式からデータベース監査データ・ストアを使用する方式に変更します。

- コンポーネントの監査レコードのバスストップ・ストレージ・プロパティを構成します。

これらの機能を構成するには、次の手順を実行します(ユーザーはIAU_APPENDである必要があります)。

1. 「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動します。

2. 「監査サービス構成」ボタンをクリックします。「監査サービス構成」ページが表示されます。

3. 監査データ・ストアを構成する手順は次のとおりです。

- 「データソースのJNDI名」フィールドの横にあるサーチライトのアイコンをクリックします。

- ダイアログ・ボックスが表示され、ドメイン内で監査レコード用に使用可能なデータソースのリストが表示されます。目的のデータソースを選択して、「OK」をクリックします。

- 選択されたデータソースが「データソースのJNDI名」フィールドに表示されます。「適用」をクリックして続行するか、「元に戻す」をクリックして更新を中止します。

注意:

監査データ・ストアの設定は、WLST setAuditRepository()コマンドを使用して変更することもできます。詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

- 監査ローダーの頻度を秒単位で入力します。監査ローダーは指定された間隔でリポジトリをチェックし、レコードをリポジトリにプッシュします。

- 「適用」をクリックします。

4. コンポーネント用にバスストップ・ファイルのパラメータを構成する手順は次のとおりです。

- 「監査コンポーネント名」ドロップダウン・リストからコンポーネントを選択します。

- 最大ファイル・サイズを入力します。

- 最大ディレクトリ・サイズは使用されないため、このパラメータを設定しても構成に影響はありません。

- 「適用」をクリックします。

5. ドメイン内のすべてのOracle WebLogic Serverを再起動します。これにより、Oracle WebLogic Server内の起動クラス監査ローダーが構成を再度読み込むことができます。

6. 変更は、監査ポリシーでイベント収集のテストを設定することによってテストできます。たとえば、Oracle Platform Security Servicesの監査ポリシーを「中」に設定することもできます。詳細は、第14.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。

7. 監査によって監査イベントが生成されるように、シナリオを実行します。たとえば、ステップ6で構成したポリシーに基づき、資格証明の作成によって監査レコードがトリガーされます。

8. サーバー・ログ内のエラーおよび例外をチェックします。

- $DOMAIN_HOME/jrfServer_admin.outをチェックします。

- $DOMAIN_HOME/servers/$SERVER_NAME/logs/をチェックします。

14.2.3.3 監査データ・ストアの構成解除

データベースは監査レコードの推奨ストアであるため、データベースからファイル・モードへの切替えはお薦めできません。ただし、第14.3.4項「監査ポリシーの手動による管理」では、audit.repositoryTypeというプロパティの値をFileに設定することで、ファイルに格納する方式に切り替えることができると説明されています。

注意:

Fusion Middleware ControlやWLSTを使用してデータベースからファイル・モードに切り替えることはできません。この切替えを実現するには、第14.3.4項「監査ポリシーの手動による管理」で説明するように、手動による構成が必要です。

データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。

14.2.4 システム・コンポーネント用のデータベース監査データ・ストアの構成

StandAloneAuditLoader javaコマンドは、ローカルなバスストップ・ファイルからデータベース監査データ・ストアに監査イベントがプッシュされるメカニズムです。この項では、監査レコードが監査データ・ストアに送信されるように環境を構成する方法を説明します。

注意:

システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアを、すべてのインスタンスがレコードを該当ストアにプッシュするよう構成する必要があります。

監査データ・ストアを構成するには、コンポーネントの各インスタンスで、次の手順を実行する必要があります。

注意:

この手順で構成されるのは、システム・コンポーネント用の監査データ・ストアのみです。Javaコンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第14.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。

1. 次の場所にあるopmn.xmlファイルを開きます。

(UNIX) $ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml
(Windows) %ORACLE_INSTANCE%/config/OPMN/opmn/opmn.xml

2. 次のようなrmd-definitions要素を見つけます。

(UNIX)
<rmd-definitions>
<rmd name="AuditLoader" interval="15">
<conditional>
<![CDATA[({time}>=00:00)]]>
</conditional>
<action value="exec $ORACLE_HOME/jdk/bin/java -classpath
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$ORACLE_HOME/oracle_common/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
-Doracle.home=$ORACLE_HOME
-Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
oracle.security.audit.ajl.loader.StandaloneAuditLoader"/>
<exception value="exec /bin/echo
PERIODICAL CALL For Audit Loader FAILED"/>
</rmd>
</rmd-definitions>

(Windows)
<rmd-definitions>
<rmd name="AuditLoader" interval="15">
<conditional>
<![CDATA[({time}>=00:00)]]>
</conditional>
<action value="exec %ORACLE_HOME%\jdk\bin\java -classpath
%COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_cert.jar;
%COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_core.jar;
%ORACLE_HOME\oracle_common\modules/oracle.jdbc_11.2.0\ojdbc6dms.jar;
%COMMON_COMPONENTS_HOME%\modules\oracle.iau_11.1.1\fmw_audit.jar;
%COMMON_COMPONENTS_HOME%\modules\oracle.pki_11.1.1\oraclepki.jar;
-Doracle.home=%ORACLE_HOME%
-Doracle.instance=%ORACLE_INSTANCE%
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
oracle.security.audit.ajl.loader.StandaloneAuditLoader"/>
<exception value="exec \bin\echo
PERIODICAL CALL For Audit Loader FAILED"/>
</rmd>
</rmd-definitions>

3. 既存のRMD定義を監査ローダーに置き換えます。これらの値のみを変更する必要があります。

- jdbcString - これは、データベースJDBC接続文字列です。これをデフォルト文字列から有効な接続文字列に変更します。

- username

- interval - 監査レコードは、この間隔(秒)で、コンポーネントのバスストップ・ファイルから監査データ・ストアにプッシュされます。
デフォルトでは、intervalに非常に大きな値(31536000秒)が設定されるので、監査ローダーは実質的に無効です。この値を、15(秒)のような妥当な値に変更します。

注意:

これらの行を、<ias-instance>タグを閉じた後ろに挿入します。

4. ORACLE_HOME、ORACLE_INSTANCEおよびCOMMON_COMPONENTS_HOMEが定義されていることを確認します。例:

(UNIX) ORACLE_HOME = /u01/oracle/as11_oh
ORACLE_INSTANCE = /u01/oracle/instances/instance
COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common

(Windows) ORACLE_HOME = \u01\oracle\as11_oh
ORACLE_INSTANCE = \u01\oracle\instances\instance
COMMON_COMPONENTS_HOME = %MW_HOME%\oracle_common

5. シークレット・ストアの監査データ・ストア・パスワード(RCUで監査スキーマを作成した際に指定したパスワード)を移入します。

(UNIX) ORACLE_HOME/jdk/bin/java -classpath
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$ORACLE_HOME/oracle_common/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
-Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
-Dstore.password=true
-Dauditloader.password=password
oracle.security.audit.ajl.loader.StandaloneAuditLoader

(Windows) ORACLE_HOME\jdk\bin\java -classpath
%COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_cert.jar;
%COMMON_COMPONENTS_HOME%\modules\oracle.osdt_11.1.1\osdt_core.jar;
%ORACLE_HOME%\
oracle_common\modules\oracle.jdbc11.2.0\ojdbc6dms.jar;
%COMMON_COMPONENTS_HOME%\modules\oracle.iau_11.1.1\fmw_audit.jar;
%COMMON_COMPONENTS_HOME%\modules\oracle.pki_11.1.1\oraclepki.jar;
-Doracle.home=%ORACLE_HOME% -Doracle.instance=%ORACLE_INSTANCE%
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
-Dstore.password=true
-Dauditloader.password=password
oracle.security.audit.ajl.loader.StandaloneAuditLoader

jdbcString、usernameおよびpasswordに適切な値を入力します。

6. ファイルを保存し、終了します。

7. 次のようにしてOPMNをリロードします。

$ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits)
$ORACLE_INSTANCE/bin/opmnctl reload

8. 監査対象コンポーネントでなんらかのシナリオを実行して、監査イベントを生成します。たとえば、Oracle HTTP Serverが「ユーザー・セッション」カテゴリの"User Logins"を監査するよう構成されており、ログインによって監査イベントが生成される場合は、Oracle HTTP Serverインスタンスにログインします。

9. $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.outにアップロードされるエラーとイベントを確認します。この出力は次の例のようになります。

8/08/26 10:54:24 global:AuditLoader

14.2.4.1 監査データ・ストアの構成解除

データベースは、監査レコードの推奨ストアです。データベースからファイル・モードへの切替えはお薦めできません。ただし、必要であれば、opmn.xmlファイルを使用して監査データ・ストアを構成する前述のタスクで示したものと同じ手順により、RMDの定義を更新し、監査データ・ストアの構成を解除することもできます。rmd-definitions要素を見つけ、監査ローダーの既存のRMD定義を置き換えます。

注意:

システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアの構成を解除する必要があります。

- jdbcString - データベースJDBC接続文字列をデフォルト文字列jdbc:oracle:thin:@host:port:sidに戻します。

- interval - デフォルト値31536000に戻します。

ファイルを保存して終了し、OPMNをリロードします。

14.2.5 バスストップ・ファイルのチューニング

この項では、監査レコードのファイルベースの記憶域の管理に関連する次のトピックを説明します。

- バスストップ・ファイルの場所

- ファイル・サイズ

注意:

監査ファイルを手動で消去して領域を解放することは、お薦めしません。かわりに、後述のようなファイルおよびディレクトリのサイズ調整機能を使用して、領域を制御してください。

バスストップ・ファイルの場所

Javaコンポーネント用のバスストップ・ファイルは、次の場所にあります。

$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type

システム・コンポーネント用のバスストップ・ファイルは、次の場所にあります。

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

ファイル・サイズ

Javaコンポーネント

ファイル記憶域モードのファイルのサイズは、構成ファイルjps-config.xmlで示されているmax.fileSizeプロパティを使用して管理できます。このプロパティは、Javaコンポーネントのバスストップ・ファイルの最大サイズを制御します。

第14.3.4項「監査ポリシーの手動による管理」でも説明されていますが、このサイズはバイト単位で指定します。

システム・コンポーネント

ファイル記憶域モードのファイルのサイズは、auditconfig.xmlファイル内で設定できます。第14.3.4.4項「システム・コンポーネントの監査構成ファイル」を参照してください。

注意:

監査データをファイルからデータベース・ストアに切り替えると、監査ファイルに収集されたすべてのイベントがデータベース表にプッシュされ、監査ファイルが削除されます。

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

図13-1に示すように、共通監査フレームワークの監査ローダーは、レコードをバスストップ・ファイルから監査データ・ストアに移動します。監査ローダーを駆動するメカニズムは、アプリケーション環境に応じて変わります。

- Oracle WebLogic ServerにデプロイされたJava EEコンポーネントおよびアプリケーションでは、アプリケーション・サーバーによって提供された監査ローダー機能を使用します。

- システム・コンポーネントおよび非Javaアプリケーションでは、StandAloneAuditLoader javaコマンドによって提供された監査ローダー機能を使用します。

- アプリケーション・サーバー・コンテナの外部で実行されたJava SEアプリケーションでは、スタンドアロン監査ローダーも使用します。

この項では、スタンドアロン監査ローダーの設定および実行方法を説明します。

- 環境の構成

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

14.2.6.1 環境の構成

スタンドアロン監査ローダーを実行する前に、a) 特定のプロパティの構成、およびb) データベース・スキーマ・ユーザーのパスワードがシークレット・ストアに存在することの確認を行う必要があります。

14.2.6.1.1 プロパティの構成

次のプロパティを構成する必要があります。

- ORACLE_HOME環境変数

- COMMON_COMPONENTS_HOME環境変数

- ORACLE_INSTANCE環境変数

- auditloader.jdbcStringシステム・プロパティ

- auditloader.usernameシステム・プロパティ

14.2.6.1.2 データベース・スキーマ・ユーザーのパスワード記憶域

データベース・スキーマ・ユーザーのパスワードは、シークレット・ストアに格納されます。パスワードの格納は、javaのStandAloneAuditLoaderコマンドを-Dstore.password=trueプロパティ付きで使用する1回かぎりの操作です。

次のようにStandAloneAuditLoaderコマンドを発行してパスワードを格納します。

$COMMON_COMPONENTS_HOME/jdk/jre/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar
-Doracle.home=$ORACLE_HOME
-Doracle.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=db-user-name
-Dstore.password=true
oracle.security.audit.ajl.loader.StandaloneAuditLoader

パスワードがコマンドラインに含まれているかどうかによって、パスワードを格納するStandAloneAuditLoaderコマンドには2つのバリエーションがあります。

- コマンドの発行時にパスワード・プロパティ(-Dauditloader.password)を含めていない場合は、パスワードの入力を求められます。

- コマンドの発行時にパスワード・プロパティを含めることができます。

注意:

クラスパスの指定には空白文字を使用しないでください。

このコマンドにより、cwallet.ssoファイルが生成されます。

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

次のようにStandAloneAuditLoaderコマンドを発行して監査レコードをロードします。

$COMMON_COMPONENTS_HOME/jdk/jre/bin/java
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.2.0/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.dms_11.1.1/dms.jar:
-Doracle.home=$ORACLE_HOME
-Doracle.instance=$ORACLE_INSTANCE -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid -Dauditloader.username=db-user-name oracle.security.audit.ajl.loader.StandaloneAuditLoader

監査レコードを監査データ・ストアに定期的にアップロードするように、バッチ・ジョブまたはkronジョブによってこのコマンドをスケジュールできます。

14.3 監査ポリシーの管理

監査ポリシーとは

監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

たとえば、監査ポリシーでは、Oracle Internet Directoryインスタンスに対するすべての認証の失敗を監査するように指定することができます。

ポリシーの構成方法

Oracle Fusion Middleware監査フレームワークを使用すると、監査ポリシーを構成し、監視対象のイベントおよびデータのタイプをきわめて詳細に制御することができます。Oracle Enterprise Manager Fusion Middleware Control UIツールまたはWLSTコマンドを使用して、ポリシーを構成できます。

ポリシーの変更にはサーバーまたはインスタンスの再起動は不要です。

この項の残りの部分では、監査ポリシーの表示および更新方法を説明します。

- Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理

- Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理

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

- 監査ポリシーの手動による管理

関連項目:

- 補足的な予備知識については、第13.3.2項「重要な技術的概念」を参照してください。

- Javaコンポーネントおよびシステム・コンポーネントのリストは、付録Cを参照してください。

14.3.1 Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理

ドメインの「監査ポリシー設定」ページでは、Oracle Access ManagerなどのすべてのJavaコンポーネントの監査イベントと、Oracle Platform Security Servicesなどのシステム・ライブラリの監査イベントを管理します。

注意:

- システム・コンポーネントの監査ポリシーは、該当するコンポーネントのホーム・ページで管理されます。第14.3.2項「Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理」を参照してください。

- 第14.3項「監査ポリシーの管理」の最初にある「ポリシーの変更にはサーバーまたはインスタンスの再起動が必要」というタイトルの注意を参照してください。

関連項目:

監査可能なコンポーネントのリストは、第C.1.1項「監査可能なコンポーネント」を参照してください。

現在構成されている監査ポリシーを表示および更新するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 左側のトポロジ・パネルを使用して、「WebLogicドメイン」の下の目的のドメインに移動します。

3. ドメイン・メニューから、「ドメイン」→「セキュリティ」→「監査ポリシー」に移動します。「監査ポリシー」ページが表示されます。

4. 「監査コンポーネント名」ドロップダウン・リストを使用して、構成したい監査ポリシーがあるJavaコンポーネントを選択します。

コンポーネントを選択すると、そのコンポーネントに関連する監査カテゴリの表が「監査ポリシー設定」というページ領域に表示されます。Oracle Access Managerの場合の例を示します。

5. 「監査レベル」ドロップダウン・リストを使用して、そのコンポーネントの監査イベントのサブセットを選択します。次の選択肢があります。

- なし - イベント・カテゴリは選択されません。

- 低、中、高 - 監査の事前定義済レベルを表すイベント・カテゴリのサブセット。

- カスタム - カスタムのフィルタ定義を作成または変更できます。

選択するレベルに応じて、「監査用に選択」列にチェック・フラグが表示されます。選択されたカテゴリのイベントが監査されます。Oracle Access Managerの「中」レベルの例を示します。

フラグ付きのカテゴリが監査用に選択されています。フラグ付きカテゴリ内のイベントを確認するには、カテゴリ表でその行をクリックします。たとえば、「OAMサーバー」カテゴリをクリックすると、下部に次のようなイベント表が生成されます。

注意:

イベントの表はカスタム・レベルでのみ編集できます。事前定義済レベルでは編集できません。

6. 多くの場合、事前定義済レベルで十分ですが、コンポーネントの監査ポリシーの微調整が必要な場合もあります。
監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより事前定義済カテゴリは保持されたまま、チェック・ボックスとして緑色のチェックマークが表示され、すべてのカテゴリの選択が可能になります。

目的のカテゴリとイベントを選択して監査ポリシーを微調整できます。たとえば、「サーバー」カテゴリで、失敗した認証試行のみを監査したい場合があります。

7. フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。ポリシーをさらに微調整して、失敗した認証試行のタイプを絞り込んで監査する場合の例を示します。
「フィルタの編集」列の鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。アイコンをクリックし、「フィルタの編集」ダイアログを表示します。

「条件」ボックスを使用して、フィルタ条件、演算子および値で構成されるフィルタを指定します。条件を指定したら、「追加」ボタンをクリックします。条件の追加が完了したら、「OK」をクリックして変更を保存します。

この例では、保護されたアプリケーションをホストするサーバーの名前がmyhost1の場合のみ、失敗した認証試行が監査イベントをトリガーします。

注意:

各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。

8. インポート/エクスポート - これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。

9. オプションで、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。

注意:

- この機能を使用して、システム管理者などの主要ユーザーを監査するようにした場合は、そのユーザーがどのコンポーネントの監査可能イベントに関与しても監査トラフィックが発生します。たとえば、コンポーネントの監査ポリシーが「なし」に設定されている場合もありますが、該当するユーザーがコンポーネント・インスタンス内のアクティビティを実行すると、それも監査の対象となります。

- このフィールドに入力するユーザー名は検証されません。

10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。Javaコンポーネントの場合、この変更を有効にするには、管理対象Oracle WebLogic Server(影響を受けるJavaコンポーネントが実行されている)を再起動する必要があります。事前定義済のリフレッシュ間隔(デフォルトは10分)の後で、変更が有効になります。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。

コンポーネント・イベントについて

ドメイン内の各コンポーネントおよびアプリケーションでは、監査可能なイベントの独自のセットを定義します。そのため、表の「名前」列を開くと、コンポーネントごとにそのコンポーネントのインスタンスに適用されるイベントのリストが表示されます。

14.3.2 Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理

この項では、システム・コンポーネントに対する監査ポリシーの表示方法および更新方法について説明します。

注意:

- Javaコンポーネントの監査ポリシーは、ドメイン・コンテキスト内で管理されます。第14.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。

- 第14.3項「監査ポリシーの管理」の最初にある「ポリシーの変更にはサーバーまたはインスタンスの再起動が必要」というタイトルの注意を参照してください。Oracle Internet Directoryインスタンスの場合、再起動は不要です。

システム・コンポーネントの監査ポリシーは、それぞれのホーム・ページで管理されます。ドメインの「監査ポリシー設定」ページでは、ドメイン内で実行されるJavaコンポーネントの監査イベントを管理します。

関連項目:

監査可能なコンポーネントのリストは、第C.1.1項「監査可能なコンポーネント」を参照してください。

イベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。

システム・コンポーネントの監査ポリシーを表示および更新するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 左側のトポロジ・パネルを使用して、Oracle HTTP Serverなど、目的のシステム・コンポーネントに移動します。

3. コンポーネント・メニューから、「セキュリティ」→「監査ポリシー」とナビゲートします。「監査ポリシー設定」ページが表示されます。

4. 事前構成済監査レベルのドロップダウン・リストから選択できます。3つの事前定義済レベル(「低」、「中」、高)では、コンポーネントの監査イベントのサブセットを自動的に選択します。

注意:

事前定義済レベルについて、ドロップダウン・ボックスの下のイベント選択を編集することはできません。カスタム・レベルでの編集のみが可能です。

- なし - 監査対象のイベントは選択されません。

- 低 - 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。

- 中または高 - より大きなイベントのセット。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。

- カスタム - このレベルではポリシーを微調整できます。後述のステップ5を参照してください。

次の表は、コンポーネント・インスタンスに対して監査できるイベントを示しています。Oracle HTTP Serverの例を示します。

表は、次の列から構成されています。

- 名前 - タイプ別にまとめられたコンポーネント・イベント(認可イベントなど)が表示されます。

- 監査の有効化 - 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。

- フィルタ - イベント・タイプで有効なフィルタが表示されます。

5. 監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これによって、イベント・カテゴリの選択、開始、カスタマイズするカテゴリの「監査用に選択」ボックスのチェックが可能になります。
2つ目の表は各カテゴリのイベントを一覧表示しており、個々のイベント結果(成功および失敗)に対して追加のフィルタを使用して監査方法をより詳細に制御できます。手順6に示すように、フィルタを微調整できます。

6. フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。

鉛筆アイコンをクリックし、「フィルタの編集」ダイアログを表示します。

注意:

各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。

7. 「障害のみ選択」をクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。

8. インポート/エクスポート - これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。

9. オプションで、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。

注意:

- この機能を使用して、システム管理者などの主要ユーザーを監査するようにした場合は、そのユーザーがどのコンポーネントの監査可能イベントに関与しても監査トラフィックが発生します。たとえば、コンポーネントの監査ポリシーが「なし」に設定されている場合もありますが、該当するユーザーがコンポーネント・インスタンス内のアクティビティを実行すると、それも監査の対象となります。

- このフィールドに入力するユーザー名に対する検証は行われません。

10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。

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

この項では、Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーの表示や更新を実行する方法を説明します。

- WLSTを使用した監査ポリシーの表示

- WLSTを使用した監査ポリシーの更新

- 例1: WLSTを使用したユーザーに対する監査ポリシーの構成

- 例2: WLSTを使用したイベントに対する監査ポリシーの構成

- 監査レベルを変更する際に保持されるカスタム構成

注意:

WLSTの監査コマンドを実行するには、Oracle共通ホームからWLSTスクリプトを呼び出します。詳細は、『Oracle Fusion Middlewareの管理』のカスタムWLSTコマンドの使用に関する説明を参照してください。

14.3.3.1 WLSTを使用した監査ポリシーの表示

WLSTを使用した監査ポリシーを表示するには、次の手順を実行します。

注意:

ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびツールを起動する様々なオプションについては、『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)の使用の開始に関する説明を参照してください。

- 次のコマンドを使用して、WebLogicサーバーに接続します。

>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')

- getAuditPolicyコマンドを使用して、監査ポリシーの構成を表示します。たとえば、次のコマンドでは、すべての監査ポリシーが表示されます。

wls:/mydomain/serverConfig> getAuditPolicy()

次のコマンドでは、特定のコンポーネントの監査ポリシーが表示されます。

wls:/mydomain/serverConfig> getAuditPolicy(componentType="JPS")

- システム・コンポーネントの場合:

- getNonJava EEAuditMBeanNameコマンドを使用してMBean名を取得します。詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

- getAuditPolicyコマンドを使用してMBean名を含め、監査ポリシーの構成を表示します。例:

wls:/mydomain/serverConfig> getAuditPolicy
(on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")

14.3.3.2 WLSTを使用した監査ポリシーの更新

Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーを更新するには、次の手順を実行します。

注意:

ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびツールを起動する様々なオプションについては、『Oracle Fusion Middlewareの管理』のOracle WebLogic Scripting Tool (WLST)の使用の開始に関する説明を参照してください。

- 次のコマンドを使用して、WebLogicサーバーに接続します。

>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')

- Bean階層を移動し、目的のドメインにアクセスします。たとえば、ドメインがmydomainという名前の場合は、次のようになります。

wls:/mydomain/serverConfig>

- setAuditPolicyコマンドを使用して、監査ポリシーの構成を更新します。

- ポリシーをローカルで管理するコンポーネントの場合は、setAuditPolicyコマンドを使用し、MBean名を含めると、監査ポリシーの構成が更新されます。

- setAuditPolicyコマンドまたはimportAuditConfigコマンドを発行した後、saveを明示的にコールします。
saveを呼び出さないと、新しい設定が有効になりません。

このコールの例については、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のWLSTを使用した監査の管理に関する項を参照してください。このコールによるOracle Internet Directoryの監査が具体的に説明されています。

14.3.3.3 例1: WLSTを使用したユーザーに対する監査ポリシーの構成

このシナリオでは、ドメインの現在のポリシーにより、user1というユーザーが監査されています。管理者は、常に監査対象とするユーザーのリストに2つの名前(user2およびuser3)を追加し、リストからuser1を削除します。

このタスクは、setAuditPolicyを次のように起動して実行します。

setAuditPolicy
(filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")

関連項目:

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

14.3.3.4 例2: WLSTを使用したイベントに対する監査ポリシーの構成

このシナリオでは、ドメインの現在のポリシーにより、ユーザーのログアウト・イベントが監査されています。管理者は、ポリシーからログアウト・イベントを削除し、ログイン・イベントを監査するようにします。

このタスクは、setAuditPolicyを次のように起動して実行します。

注意:

この例では、Oracle HTTP Serverのコンポーネント・タイプOHSを使用します。コマンドの使用時に、適切なコンポーネント・タイプに置き換えてください。

setAuditPolicy
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")

イベントを追加および削除するために、Customフィルタ・プリセットが起動されたことに注意してください。

14.3.3.5 監査レベルを変更する際に保持されるカスタム構成

カスタム・レベルで監査を構成しているときに、WLSTを使用して別の(カスタムではない)監査レベルに切り替えても、明示的にそれらのカスタム監査設定を削除しないかぎり、そのカスタム監査設定は保持されます。

この動作を示す例は、次のとおりです。

1. カスタム監査レベルはコンポーネントのポリシーに対して設定します。構成の過程で監査フィルタを指定します。

2. 実行時には、指定したフィルタに従って監査データが収集されます。

3. ここで、WLST setAuditPolicyコマンドを使用して、コンポーネントの監査ポリシーがカスタム監査レベルから低監査レベルに変更されます。しかし、カスタム監査レベルの中で設定したフィルタは監査構成にそのまま残ります。

4. 監査データの収集は、カスタム・レベルではなく、低い監査レベルに基づいています。

5. コンポーネントの監査ポリシーはカスタム・レベルに戻されます。その他のフィルタが追加されます。このフィルタは、最初に構成されていたフィルタに追加されます。元のフィルタを明示的に削除しないかぎり、このフィルタは構成の中で保持されます。

6. 実行時には、効力があるすべてのフィルタに基づいてカスタム・レベルで監査データが収集されます。

14.3.4 監査ポリシーの手動による管理

この項では、次のファイルを手動で更新することによって監査ポリシーなどの機能を構成する方法について説明します。

- プラットフォーム構成ファイルjps-config.xml: Javaコンポーネントの場合

- コンポーネントに固有のファイル: システム・コンポーネントの場合

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

- Javaコンポーネントの構成ファイルの場所

- Javaコンポーネントのjps-config.xml内の監査サービス構成プロパティ

- Javaコンポーネントのデータベースからファイルへの切替え

- システム・コンポーネントの監査構成ファイル

14.3.4.1 Javaコンポーネントの構成ファイルの場所

jps-config.xmlドメイン構成ファイルは、次の場所にあります。

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

14.3.4.2 Javaコンポーネントのjps-config.xml内の監査サービス構成プロパティ

jps-config.xml内の監査サービス構成は、表F-9に示すプロパティで構成されています。一連のプロパティとその値は、まとめて監査ポリシーと呼ばれています。

注意:

- 監査ストアのポリシー設定は、jps-config.xmlのポリシー設定より優先されます。

- 動的メタデータ・モデルでは、特定のコンポーネントの監査ポリシーがaudit-store.xmlに格納されます。

jps-config.xmlファイルの例

監査ポリシーのサンプル・ファイルを次に示します。

<?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 name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name="audit" provider="audit.provider"       location="./audit-store.xml">
<description>Audit Service</description>
<property name="audit.filterPreset" value="None"/>
<property name="audit.maxDirSize" value="0"/>
<property name="audit.maxFileSize" value="104600"/>
<property name="audit.timezone" value="utc"/>
<property name="audit.loader.jndi" value="jdbc/AuditAppendDataSource"/>
<property name="audit.loader.interval" value="15"/>
<property name="audit.loader.repositoryType" value="File"/>
<property name="auditstore.type" value="file"/>
</serviceInstance>
</serviceInstances>
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="audit"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

14.3.4.3 Javaコンポーネントのデータベースからファイルへの切替え

まれに、監査レコードへの(データベース)データ・ストアの使用を、ファイルの使用に戻すことが必要になる場合もあります。その場合は、表F-9に記載されているプロパティaudit.loader.repositoryTypeを手動で構成する必要があります。

データベースからファイルに切り替えるには、audit.loader.repositoryTypeをFileに設定します。

データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。

14.3.4.4 システム・コンポーネントの監査構成ファイル

Oracle HTTP Serverなどのシステム・コンポーネントでは、監査構成の格納に、jps-config.xmlファイルは使用されません。Oracle HTTP Serverでは、かわりに、次の場所にあるauditconfig.xmlファイルが使用されます。

ORACLE_INSTANCE/instance_name/config/OHS/<ohs_name>/auditconfig.xml

auditconfig.xmlファイルの形式

auditconfig.xmlファイルの形式は次のとおりです。

<?xml version="1.0" encoding="UTF-8"?>
<ns0:AuditConfig xmlns:ns0="http://xmlns.oracle.com/ias/audit/audit.xsd">
<ns0:Filters>
<ns0:CustomEvents> </ns0:CustomEvents>
<ns0:FilterPreset>None</ns0:FilterPreset>
<ns0:SpecialUsers> </ns0:SpecialUsers>
</ns0:Filters>
<ns0:LogsDirectory>
<ns0:MaxDirSize></ns0:MaxDirSize>
<ns0:MaxFileSize></ns0:MaxFileSize>
<ns0:Location></ns0:Location>
</ns0:LogsDirectory>
</ns0:AuditConfig>

14.4 監査のタイムスタンプ

11gリリース1 (11.1.1.7)より前のリリースでは、監査サービスはアプリケーション・サーバーのタイムゾーンを使用してデータベース・レコードを書き出していました。11gリリース1 (11.1.1.7)では、監査サービスはアプリケーション・サーバーと監査データ・ストアに対して異なるタイムゾーンを構成できます。

詳細は、次のとおりです。

- 新しい11gリリース1 (11.1.1.7)のサイトは、監査イベントが協定世界時(UTC)で書かれていると見なします。

- 11gリリース1 (11.1.1.6)から11gリリース1 (11.1.1.7)にアップグレードするサイトは、デフォルトでは、明示的にUTCに切り替えないかぎり監査レコードに対してアプリケーション・サーバーのタイムゾーンを引き続き使用します。

注意:

バスストップ・ファイルへのレコードは常にUTCを使用します。

新しい11gリリース1 (11.1.1.7)のサイト

11gリリース1 (11.1.1.7)以降の新しいインストールでは、監査レコードはUTCタイムスタンプを使用します。デフォルトの監査サービス構成の新しいサービス・プロパティ(audit.timezone=utc)にはこの規則が実装されます。

すぐに使用できる監査サービス構成は、次のようになります。

<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>

11gリリース1 (11.1.1.7)にアップグレードするサイト

アップグレードの前に存在していた監査レコードでは、アプリケーション・サーバーのタイムスタンプが使用されていました。アップグレード後、監査サービスの構成には変化がなく、デフォルトでは、レコードは引き続きアプリケーション・サーバーのタイムスタンプを使用して書き込まれます。

アップグレード後にUTCタイムスタンプを使用したい場合は、構成ファイルに新しいサービス・プロパティaudit.timezone=utcを追加してUTCの動作を有効にすることができます。

アップグレード後にUTCに切り替える場合は、レポート作成に影響をおよぼす可能性がある潜在的な矛盾を回避するため、まず既存のレコードを移動することをお薦めします。

関連項目:

第F.2.7項

14.5 監査ログとバスストップ・ファイル

この項には次のトピックが含まれます:

- 監査ログの場所

- バスストップ・ファイルの監査タイムスタンプ

14.5.1 監査ログの場所

Fusion Middleware監査フレームワークでは、監査管理に役立つように、一連のログ・ファイルを提供しています。それらのログを使用すると、監査フレームワークが正しく機能しないときに、エラーをトレースしたり、診断を行うことができます。

すべての監査ログの場所のリスト、ロガーの構成方法およびログによる問題の診断方法は、第J.1.1.7項「監査ロガー」を参照してください。

14.5.2 バスストップ・ファイルの監査タイムスタンプ

監査のバスストップ・ファイルのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。

14.6 データベース・ストアの拡張管理

監査スキーマは、リポジトリ作成ユーティリティ(RCU)によって作成されます。この項では、監査スキーマの編成について説明し、スキーマの管理に関する次のトピックについて説明します。

- スキーマの概要

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

- 索引スキーム

- バックアップおよびリカバリ

- データのインポートおよびエクスポート

- パーティション化

関連項目:

RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

14.6.1 スキーマの概要

Oracle Fusion Middleware監査フレームワーク・スキーマの共通の表は、次のものから構成されています。

- IAU_COMMON表の共通属性

- 専用表の汎用属性

- IAU_CUSTOM_nnn表のカスタム属性表

これらの表の詳細は、第13.4項を参照してください。

監査スキーマには、次のものが含まれます。

- 実表

- 変換表

- 監査データのコンポーネントに固有な表のセット

これらの表の詳細は、第14.6.2項を参照してください。

バスストップ・ファイルについて

デフォルトでは、バスストップ・ファイルは次のディレクトリ内に保持されます。

WebLogic Domain Home/servers/server_name/diagnostics/auditlogs/JPS/audit.log

Oracle Platform Security Servicesのバスストップ・ファイルの次に例を示します。

#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key
#Remark Values:ComponentType="JPS"
2008-12-08 10:46:05.492  - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - -

共通表とカスタム表

図14-1は、共通表のデータと、それがカスタム表にどのように関係しているのかを示しています。

図14-1 共通監査表とカスタム監査表

実表とコンポーネント表

図14-2は、実表内のデータと、それがコンポーネントに固有な表にどのように関係しているのかを示しています。

図14-2 監査実表とコンポーネント表

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

監査レコードは生成時、1つのファイルに格納されます。監査データベース・ストアが構成されていると、監査ローダーは各監査レコードを実表の1つの行およびコンポーネント表の1つの行に格納します。

- 一般的な情報(Time、EventType、EventStatusなど)は、実表に書き込まれます。

- コンポーネントに固有な情報(CodeSourceなど)は、コンポーネント表に書き込まれます。

実表IAU_BASEの平均的なレコード・サイズは、約0.3 KBです。表領域のサイズを計画する際は、次のようにしてください。

- この数値を、平均的なレコード・サイズのガイドラインとして使用してください。

- 選択した監査ポリシーおよびアクティビティのレベルに基づいて、監査データベースのサイズが増加する様子を監視してください。

- 監査データの格納期間を考慮してください。

実表およびコンポーネントに固有な表の属性はそれぞれ、次のファイルから派生しています。

- $ORACLE_HOME/modules/oracle.iau_12.1.2/components/generic/generic_events.xml

(実表用)

- $ORACLE_HOME/modules/oracle.iau_12.1.2/components/componentName/component_events.xml

(各コンポーネント表用)

表14-1に、実表IAU_BASEで定義されている重要な属性をいくつか示します。最初の4つの属性は、その実表とすべてのコンポーネント表に共通する属性です。主キーは、IAU_ID + IAU_TSTZORIGINATINGと定義されます。

関連項目:

第C.4項「監査スキーマ」

表14-1 実表IAU_BASEの属性

属性

説明

IAU_ID

各監査レコードの一意な連番

IAU_TstzOriginating

監査イベントが生成された日付と時刻(データ型TIMESTAMP)

IAU_EventType

監査イベントのタイプ(名前)

IAU_EventCategory

監査イベントのカテゴリ

IAU_EventStatus

監査イベントの結果(失敗または成功)

IAU_MessageText

監査イベントの説明

IAU_Initiator

操作を実行していたユーザーのUID

注意:

Oracleデータベース・オブジェクトの1つであるSEQUENCEは、監査レコードの連番(IAU_ID)の割当てを調整するために作成されます。

WLSTコマンドlistAuditEventsを使用すると、各コンポーネント表のすべての属性名のリストを取得することができます。

関連項目:

- 付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

- 第C.4項「監査スキーマ」

14.6.3 索引スキーム

問合せを効率よく実行できるように、デフォルトでは、実表およびコンポーネントに固有の各表のタイムスタンプ(IAU_TSTZORIGINATING)に対して索引が作成されます。

デフォルトの索引は、IAU_BASEの場合はEVENT_TIME_INDEX、コンポーネント表の場合はtableName_INDEX (OVDCOMPONENT_INDEX、OIDCOMPONENT_INDEX、JPS_INDEXなど)です。

14.6.4 バックアップおよびリカバリ

コンプライアンスの規制では、監査データを長期間保存する必要があります。データを保護するには、バックアップおよびリカバリの計画が必要です。

優れたバックアップ計画を作成するには、次のような基本的なガイドラインを考慮します。

- 監査イベントの増加率
生成される監査イベントの数は、監査ポリシーによって決まります。監査データの消失を最小限に抑えるようバックアップを実行する頻度は、日々生成される監査イベントの数によって決まります。

- コンプライアンスの規制
バックアップの実行頻度および監査データの必須保存年数は、各組織のコンプライアンス規制を参照して決定してください。

- オンラインおよびオフラインのデータ管理
バックアップの実行頻度および簡単にアクセスできる必要がある監査データの割合は、各組織のコンプライアンス規制を参照して決定してください。

Oracle Databaseでは、Oracle Recovery Manager (RMAN)を使用してバックアップおよびリカバリを実行します。詳細は、次を参照してください:

http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm

http://www.oracle.com/technology/deploy/availability/htdocs/rman_overview.htm

注意:

変換表IAU_DISP_NAMES_TLは、時間が経過しても変化しないため、バックアップの実行は一度だけで十分です。

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

複数の監査データベースで開始した後、それらのデータベースを結合して単一の監査データ・ストアを構築する場合や、データベースを変更して規模を拡張する場合は、監査スキーマのインポートおよびエクスポートを実行して、データを移行することができます。

Oracle Databaseサイトでは、Oracle Data Pumpのユーティリティを使用してデータのインポートおよびエクスポートを実行できます。詳細は、次のサイトを参照してください。

http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html

14.6.6 パーティション化

すべてのデータベース・システムでパーティション化がサポートされているわけではなく、監査スキーマ内の表は、デフォルトではすべてパーティション化されていません。

監査データは累積され、古いデータが削除されることはありません。そのため、大量の監査データを格納する場合は、監査スキーマのパーティション化を考慮し、アーカイブ処理を容易にする必要があります。

パーティション化には、次のような利点があります。

- パフォーマンスの向上: 表がタイムスタンプでレンジ・パーティション化されていると、たとえばタイムスタンプによる問合せを処理できるのは、該当する時間枠内のパーティションのみとなります。

- 管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、比較的古いデータは比較的遅くて大きなディスクに移動し、比較的新しいデータは比較的高速で小型のディスクに保持することができます。
また、パーティション化により、アーカイブ処理もはるかに容易になります。たとえば、表全体をパーティション化することなく、単一のパーティションを圧縮することができます。

- 可用性の拡張: 単一のパーティションが使用できない場合、たとえば問合せでそのパーティションを処理対象から外しても問題がないことが判明しているのであれば、使用できないパーティションを待つことなく、問合せを正常に処理することができます。

14.6.6.1 パーティション表

注意:

この説明は11gリリース1 (11.1.1.7)より前のリリースに適用されます。11gの新しいリリース1 (11.1.1.7)のインストールではこれらの表を使用しないでください。

ここの例では、IAU_BASEを例として使用し、監査スキーマ内のパーティション化されていない表をパーティション化された表に変換する方法を示します。

アプリケーションの停止時間を最小化するため、監査データ・ストアにこのスキーマを使用する前にパーティション化を実行することをお薦めします。

注意:

この製品には、サンプルのSQLスクリプトが2つ含まれています。

- $MW_HOME/oracle_common
/common/sql/iau/scripts/convertPartitionedTables.sql (linux)または%MW_HOME\oracle_common
\common\sql\iau/scripts\convertPartitionedTables.sql (Windows)では、監査スキーマの実表およびコンポーネント表がパーティション表に変換されます。

- $MW_HOME/oracle_common
/common/sql/iau/scripts/createPartitionsByQuarter.sql (linux)または%MW_HOME\oracle_common
\common\sql\iau/scripts\createPartitionsByQuarter.sql (Windows)では、監査スキーマの実表およびコンポーネント表に対して、四半期のパーティションが作成されます。

パーティション化の手順は、次のとおりです。

注意:

パーティション化を実行する前に監査ローダーを非アクティブ化するようお薦めします。詳細は、第14.2.4.1項「監査データ・ストアの構成解除」を参照してください。

1. パーティション化されていない既存の表の名前を変更します。例:

RENAME IAU_BASE TO IAU_BASE_NONPART;

2. パーティション化されていない表の表構造に従う、新しいパーティション化された表を作成します。この例では、タイムスタンプによりレンジ・パーティション化するスキームを使用します。

CREATE TABLE IAU_BASE
PARTITION BY RANGE (IAU_TSTZORIGINATING)
(
PARTITION IAU_BASE_DEFAULT VALUES LESS THAN (MAXVALUE)
)
AS SELECT * FROM IAU_BASE_NONPART;

3. 行の移動を有効にし、新しいパーティションの作成時にデータがパーティション間で自動的に移動できるようにします。例:

ALTER TABLE IAU_BASE
ENABLE ROW MOVEMENT;

4. パーティション表のローカルな接頭辞索引を作成します。例:

ALTER INDEX EVENT_TIME_INDEX
RENAME TO EVENT_TIME_INDEX_NONPART;

CREATE INDEX EVENT_TIME_INDEX
ON IAU_BASE(IAU_TSTZORIGINATING) LOCAL;

5. これでパーティションを作成できます。この例では、暦の四半期別にパーティションを作成します。

ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/04/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q1_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;

ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/07/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q2_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;

ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/10/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q3_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;

ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/01/2009', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q4_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;

注意:

新しい四半期別に合わせて定期的に、新しいパーティションを作成する必要があります。

14.6.6.2 パーティション表のバックアップとリカバリ

バックアップとリカバリについては、第14.6.4項「バックアップおよびリカバリ」を参照してください。バックアップ・コピーが作成されているかぎり、データベースのバックアップ全体から読取り専用の表領域を除外することができます。そのため、それらの表領域上に存在するアーカイブ・データのパーティションに対するバックアップを反復的に実行する必要がなくなり、パフォーマンスが向上します。

14.6.6.3 インポートとエクスポート

インポートとエクスポートについては、第14.6.5項「データのインポートとエクスポート」を参照してください。レンジ・パーティション化された表で旧データを削除する際は、行を個別に削除するよりパーティションを削除した方がはるかに効率的であることを覚えておいてください。

ALTER TABLE IAU_BASE DROP PARTITION IAU_BASE_Q4_2008;

また、表全体を変更することなく新しいデータのパーティションをロードするのも簡単です。ただし、次のようなコマンドを使用して、まず"values less than (MAXVALUE)"のデフォルト・パーティションを削除し、完了後に付加しなおす必要があります。

ALTER TABLE IAU_BASE ADD PARTITION IAU_BASE_Q4_2008 VALUES LESS THAN ('01-JAN-2009');

パーティションを作成したら、特定のパーティションの消去またはバックアップを実行できます。詳細は、14.6.6.4項を参照してください。

データベース・モードの場合、バスストップ・ファイルは監査ローダーによって自動的に管理されます。

14.6.6.4 データ削除

Oracle Fusion Middleware監査フレームワークでは、監査ストアからのレコードの削除を可能にするSQLスクリプトが提供されています。

スクリプトの場所

削除スクリプトは、次の場所にあります。

[Linux]
$MW_HOME/oracle_common/common/sql/iau/scripts

[Windows]
%MW_HOME\oracle_common\common\sql\iau\scripts

次のスクリプトがこの場所にあります。

- auditDataPurge.sql

- auditDeleteData.sql

- auditReclaimSpace.sql

監査レコードの削除

その他のアクションなしにレコードを削除するには、auditDeleteData.sqlを使用します。このスクリプトは2つのパラメータを使用します。

- 監査スキーマ・ユーザー

- 保持する日数 - 古いレコードは削除されます。

auditDeleteData.sql audit_schema_user number_of_days_to_keep

例:

sqlplus> @auditDeleteData.sql DEV_IAU 100

100日を超過したレコードはすべて削除されます。

データ・ストアでの領域の再要求

領域を再要求するには、auditReclaimSpace.sqlスクリプトを使用します。このスクリプトは、監査スキーマ・ユーザーという1つのパラメータのみを使用します。

@auditReclaimSpace.sql audit_schema_user

例:

sqlplus> @auditDataPurge.sql DEV_IAU

レコードの削除と領域の再要求

監査レコードの削除と領域の再要求の両方を実行するには、auditDataPurge.sqlスクリプトを使用します。このスクリプトは2つのパラメータを使用します。

- 監査スキーマ・ユーザー

- 保持する日数 - 古いレコードは削除されます。

@auditDataPurge.sql audit_schema_user number_of_days_to_keep

例:

sqlplus> @auditDataPurge.sql DEV_IAU 100

100日より古いレコードをすべて削除し、領域を小さくするために行の移動を有効にします。

14.6.6.5 階層アーカイブ

パーティション化により、それぞれのパーティション(またはパーティションのグループ)を、記憶域の様々な層に格納できます。表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成できます。また、パーティション内のデータを表領域(記憶域の層)間で移動することも容易です。

次に例を示します。

ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008
TABLESPACE AUDITARCHIVE UPDATE INDEXES;

注意:

パーティションは、範囲、リスト、システムおよびハッシュのパーティション化スキームでのみ移動できます。

Oracle Information Lifecycle Management (ILM)はパーティション化と圧縮による合理化されたデータ管理を特徴としています。詳細は、次のサイトを参照してください。

http://www.oracle.com/technetwork/database/enterprise-edition/index-090321.html

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

この章では、監査レポートの構成方法と表示方法について説明します。

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

- 第15.1項「監査レポートについて」

- 第15.2項「監査データのレポート生成」

注意:

この章で説明するレポート機能が使用可能かどうかを確認するには、作業を進める前に、第15.1項を参照してください。

15.1 監査レポートについて

Oracle Fusion Middleware監査レポートでは、2つの方法で監査レポートを使用できます。採用する方法は、サイトで使用している監査モデルおよびコンポーネントによって指定されています。

- 動的メタデータ・モデル
この監査メタデータ・モデルは、11gリリース1 (11.1.1.6.0)で導入されました。新しいOracle Fusion Middleware 12c (12.1.2)をインストールすると、自動的にこのモデルが使用されます。

第15.2項では、このモデルに基づく監査レポートの作成方法を説明します。

- レポート・テンプレート・モデル
この古いモデルは、システム・コンポーネントによって使用されます。また、アップグレードの際に、監査フレームワークでは引き続きこのモデルが使用されます。

第C.2項および第C.3項では、このモデルに基づく監査レポートの作成方法を説明します。

15.2 監査データのレポート生成

監査統合の最終的な目的は、監査データベース表に保管された監査イベントのレポートを作成することです。第14.6.1項で説明されているように、監査イベントは共通属性テーブルiau_common (第13.4.2.2項)およびカスタム属性テーブルiau_custom_nnn (第13.4.2.4項)に保存されます。OPSS共通監査フレームワークは、コンポーネントに対してSQLスクリプトを生成し、レポート作成アプリケーションのコンポーネントが監査データベース表の監査イベント・データの問合せに使用できるOracleデータベース・ビューを作成します。

15.2.1 監査レポートの構成

次の手順(一部はすでに実行済)が必要です。

- 動的または宣言による登録を使用して、監査フレームワークに統合します(第25.2項から第25.4項)。

- 監査ポリシーを構成し、監査データを生成するイベントを、実行時監査サービスがログに記録できるようにします(第25.5項および第25.6項)。

- 監査ローダーを構成し、バスストップ・ファイルがデータベースに移行されたことを確認します(第14.2項)。

- createAuditDBViewコマンドを使用し、監査定義のSQLスクリプトを生成します(第13.5.3.2項の「コンポーネントの監査定義の表示」)。

- IAUスキーマ・ユーザーとしてデータベースにログインし、前述の手順のSQLスクリプトを使用したビューを作成します。

- ビューに問い合せるレポート作成アプリケーションを構成します。

関連項目:

第C.3.2項。

これは、ApplicationAuditコンポーネント用createAuditDBViewのサンプル出力です。

-- 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';

15.2.2 Oracle Business Intelligence Publisherの使用

Oracle Business Intelligence Publisherを利用することにより、Oracleコンポーネントで使用可能なものと同じレポート機能を使用して、アプリケーションの監査データからレポートを生成できます。

基本手順は次のとおりです。

1. (createAuditDBViewコマンドを使用して作成された)データベース・ビューを使用し、Oracle BI Publisherレポート・テンプレートを生成します。

2. Oracle BI Publisherレポート・サービスを設定します。

3. レポート・テンプレートをOracle BI Publisherにコピーして、コンポーネント監査イベントを表示します。

4. Oracle BI Publisherでレポートを生成します。

関連項目:

第C.2項

第IV部

Oracle Platform Security ServicesのAPIを使用した開発

この部では、次の各章で、OPSS APIを使用してアプリケーション内でカスタムのセキュリティ・ソリューションを開発する方法を説明しますす。

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

- 第17章「OPSSポリシー・モデル」

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

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

- 第20章「認可サービスを使用した開発」

- 第21章「資格証明ストア・フレームワークを使用した開発」

- 第23章「アイデンティティ・ディレクトリAPIを使用した開発」

- 第24章「キーストア・サービスを使用した開発」

- 第25章「監査サービスを使用した開発」

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

この章では、ドメイン内およびドメイン間のアイデンティティの伝播を含むセキュリティ関連のユースケース、およびADFアプリケーション・セキュリティの一般的なライフサイクルについて説明します。また、このガイドの他の章に掲載されているコードおよび構成例もリストします。

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

- 第16.1項「概要」

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

- 第16.3項「OPSSトラスト・サービス」

- 16.4項「HTTPプロトコルを介したIDの伝播」

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

- 第16.6項「カスタム・グラフィカル・ユーザー・インタフェース」

- 第16.7項「付録 - ADFアプリケーションのセキュリティ・ライフサイクル」

- 第16.8項「付録 - コードおよび構成例」

- 第16.9項「付録 - JKSベースのキーストアを使用したアイデンティティの伝播」

16.1 概要

この章の情報の対象読者は、開発者、セキュリティ設計者およびセキュリティ管理者です。情報は、このガイドのほとんどの項のように機能ごとではなく、ユースケースごとにまとめられています。アプリケーション・セキュリティの一般的な課題を解決するいくつかのユースケースが、特定のアプリケーション・セキュリティ要件を解決するための出発点として紹介されています。ユースケースには、宣言的なアプローチを使用する(アプリケーション・コードの変更を必要としない)ものと、プログラム的アプローチを使用するもの、さらに両方のアプローチを必要とするものがあります。

セキュリティ設計者や開発者が直面する主要なセキュリティ上の課題には、ユーザーの管理、ユーザー・パスワードの管理およびリソースへのアクセスの管理などがあります。OPSSは、次の機能をサポートすることでこれらの課題に対する解決策を提供するセキュリティ・サービス・スイートです。

- セキュリティ・アーティファクトおよびセキュリティ・ロジックのアプリケーションからの外部化

- セキュリティに対する宣言的アプローチ

- 完全なユーザー・アイデンティティ・ライフサイクル

- ポリシー主導のアクセス制御

図16-1は、アプリケーションがセキュリティ・ストアにアクセスする方法、およびこれらのストアを管理するためのツールを示します。

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

関連ドキュメントへのリンク

次の項目については、他の章で説明しています。

- OPSSセキュリティ・アーキテクチャ - 第1.2項「OPSSのアーキテクチャの概要」を参照してください。

- シングル・サインオン - Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。

- ADFアプリケーション - 『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』を参照してください。

- Oracle開発ツール - 『Oracle Fusion Middleware Oracle Security Developer Toolsリファレンス』を参照してください。

OPSS APIのリストについては、付録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ベースのストア

- 同じ種類(たとえば、すべてOID)の複数のLDAPベースのストア

- 異なる種類の複数のLDAPベースのストア (具体的には、1つがAD LDAP、もう1つがOID LDAPの2つのLDAPベースのストア)

- 単一のDBベースのストア

- 複数のLDAPベースおよびDBベースのストア

このユースケースでは、次のことが求められます。

- アプリケーションへのアクセスを認証されたユーザーにのみ許可する

- 顧客が別のリポジトリでユーザー・アイデンティティを管理している場合でも、アプリケーション・コードは変更しない

このユースケースでは、次の機能を使用します。

- WebLogicコンテナへのアプリケーションのデプロイ

- 特定のユーザー・リポジトリのセットに基づいた適切な認証プロバイダの構成

- LDAPタイプが混在するかLDAPとDBタイプが混在する場合は、OVD認証プロバイダの構成

使用されているリポジトリに基づき、このユースケースの詳細は、次のシナリオに分かれます。

- 単一のユーザー・リポジトリ - WebLogicコンソールで適切な認証プロバイダを構成します。

- 複数のユーザー・リポジトリ(同じまたは異なる種類のLDAPにまたがる分割プロファイル) - OVD認証プロバイダを構成します。

- DBベースのリポジトリ - OVD認証プロバイダを構成します。

詳細は、第3.1.2項「WebLogic認証プロバイダ」を参照してください。

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

デプロイメント・ディスクリプタを使用しないあるJava EEアプリケーションは、構成済のアイデンティティ・ストアに対してユーザーをプログラム的に認証する必要があります。これは、Oracle WebLogic Application ServerにデプロイされたJava EEアプリケーションにのみ当てはまります。

このユースケースでは、ユーザーを認証するためにOPSSパブリックAPIを使用する必要があり、次の機能を使用します。

- Java EEコンテナに対する認証プロバイダの構成

- ユーザーを認証するためのLoginService APIの使用

このユースケースの詳細は、第18.1項「Java EEアプリケーションの認証トピックへのリンク」を参照してください。

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

あるJava SEアプリケーションは、ドメイン内で使用されているLDAPアイデンティティ・ストアに対してユーザーを認証する必要があります。ドメインのアイデンティティ・ストアの詳細にかかわらず、認証をリクエストするアプリケーション・コードは同じでなければなりません。

このユースケースでは、認証に使用されるアイデンティティ・ストアを構成し、LoginServiceを使用する必要があります。Java SEアプリケーションでは、1つのidログイン・モジュールしか使用できないことに注意してください。

このユースケースの詳細は、第19.3.4項「Java SEアプリケーションでのOPSS API LoginServiceの使用方法」を参照してください。

16.2.2 アイデンティティ

アイデンティティ・ユースケースは次のとおりです。

- 2つの環境で実行されるアプリケーション - 2つの異なる環境で実行されるアプリケーションが、LDAPベースのストア内のユーザー・プロファイル情報にアクセスする必要があります。

- 複数のストア内のユーザー・プロファイルにアクセスするアプリケーション - アプリケーションは、複数のLDAPベースのストア内に格納されたユーザー・プロファイル情報にアクセスする必要があります。

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

あるアプリケーションが2つの異なる環境で実行されており、LDAPベースのストアに格納されている、ユーザーの電子メール・アドレスなどのユーザー・プロファイル情報にアクセスする必要があります。LDAPサーバーのタイプはサポートされているタイプならどれでもかまわず、そのタイプは環境ごとに異なる場合があります。サポートされるタイプの詳細は、第4.1項「サポートされているファイルベース、LDAPベースおよびDBベースのサービス」を参照してください。

さらに具体的には、このユースケースでは次のことを前提としています。

- アプリケーションはUserProfile.getEmail()メソッドを使用します。

- 1つ目の環境にはAD LDAPがあり、次のように構成されています。

mail.attr = msad_email

- 2つ目の環境にはOID LDAPがあり、次のように構成されています。

mail.attr = mail

コードを変更せず、また実行される環境(1つ目または2つ目)にかかわらず、アプリケーションが正しい情報を取得するには、各環境内でアイデンティティ・ストア・プロバイダが適切なプロパティで構成される必要があります。

1つ目の環境(AD LDAP)では、アイデンティティ・ストア・プロバイダには次のプロパティが設定されます。

<property name="mail.attr" value="msad_mail">

2つ目の環境(OID LDAP)では、アイデンティティ・ストア・プロバイダには次のプロパティが設定されます。

<property name="mail.attr" value="mail"

このユースケースの詳細は、第8.2項「アイデンティティ・ストア・プロバイダの構成」を参照してください。

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

あるアプリケーションは、複数のLDAPベースのストアに格納されたユーザー・プロファイル情報にアクセスする必要があります。

このユースケースでは、複数のLDAPベースのストアに対する環境を構成する必要があります。

詳細は、次の各項を参照してください。

- 複数のLDAPの構成については、第8.3.2.8項「構成ファイルの例」を参照してください。

- アイデンティティ・ストア・サービスの構成については、第8.3項「アイデンティティ・ストア・サービスの構成」を参照してください。

16.2.3 認可

認可ユースケースは次のとおりです。

- 特定のロールのみアクセス可能なJava EEアプリケーション - Webディスクリプタで構成されているユーザーのみがJava EEアプリケーションにアクセスできます。

- ファイングレイン認可が必要なADFアプリケーション - ADFアプリケーションにファイングレイン認可が必要です。

- Webサービスを保護するWebアプリケーション - Webサービス・アプリケーションはWebサービスを保護する必要があります。

- コードベースのパーミッションが必要なJava EEアプリケーション - Java EEアプリケーションにコードベースのパーミッションが必要です。

- ファイングレイン認可が必要な非ADFアプリケーション - 非ADFアプリケーションにファイングレイン認可が必要です。

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

あるJava EEアプリケーションには、Webディスクリプタで特定のロールが割り当てられたユーザーのみがアクセスできる必要があります。グループからロールへの割当ては、顧客の環境に応じて、デプロイメントで構成可能でなければなりません。

このユースケースの詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』のWebアプリケーションでの宣言によるセキュリティの使用に関する説明およびEJBでの宣言によるセキュリティの使用に関する説明を参照してください。

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

コンテナ内のあるADFアプリケーションには、Webアプリケーション内のページ上の個々のコントロール・レベルでのファイングレイン認可が必要です。認可チェックはアプリケーションで開始されますが、ポリシーは外部化し、アプリケーションのデプロイメント後に顧客ごとにカスタマイズ可能である必要があります。

Oracle ADFアプリケーションを開発および保護する方法の詳細は、『Oracle Application Development FrameworkによるFusion Webアプリケーションの開発』の第30章「Fusion WebアプリケーションでのADFセキュリティの有効化」を参照してください。

ADFアプリケーションの一般情報については、第1.5.2項「シナリオ2: Oracle ADFアプリケーションの保護」を参照してください。

ADFアプリケーションのライフサイクルの詳細は、「付録 - ADFアプリケーションのセキュリティ・ライフサイクル」を参照してください。

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

あるWebアプリケーションは、ファイングレイン・ポリシーを使用してWebサービスを保護する必要があります。

Webサービスのセキュリティ管理の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

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

あるJava EEアプリケーションには、特定のアクションを実行するためにコードベースのパーミッションが必要であり、アクションの代表的な例としては、資格証明ストアから資格証明を読み取る、またはOPSSセキュリティ・ストアでポリシーを検索するなどがあります。

Fusion Middleware Controlでのコードベース・ポリシーの作成の詳細は、第10.2.3項「システム・ポリシーの管理」を参照してください。

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

ある非ADFアプリケーションは、ファイングレイン認可チェックを使用して保護する必要があります。

このユースケースでは、次のことが求められます。

- アプリケーション・コード内の適切な箇所へのチェックの配置

- 適切なポリシーの構成

詳細は、第17.3項「JAAS/OPSS認可モデル」を参照してください。

16.2.4 資格証明

資格証明ユースケースは次のとおりです。

- システムへのアクセスに資格証明が必要なアプリケーション - アプリケーションには、バックエンド・システムにアクセスするために資格証明が必要です。

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

あるアプリケーションには、データベースまたはLDAPサーバーなどのバックエンド・システムに接続するために資格証明が必要です。アプリケーション・コードは、デプロイメント後にアプリケーション・コードを変更することなく顧客ごとに資格証明の詳細が変更可能になるよう、この資格証明を参照する必要があります。さらにこのユースケースでは、資格証明ストアにアクセスできるユーザー、および認可されたユーザーが資格証明ストアで実行できる操作を指定する必要もあります。

このユースケースでは、次の機能を使用します。

- 資格証明を永続化するための資格証明ストアの使用

- アプリケーション・コード内のCSF APIによる実行時の資格証明のフェッチ

- コードベース上でのシステム・ポリシーの定義と施行

詳細は、次の各項を参照してください。

- 構成およびコードの例については、第21.3項「Javaセキュリティ・ポリシーのパーミッションの設定」および第21.7項「例」を参照してください。

- 資格証明の管理については、第11章「資格証明ストアの管理」を参照してください。

- パッケージ化については、第18.4.2項「アプリケーションと資格証明とのパッケージ化」を参照してください。

16.2.5 監査

監査ユースケースは次のとおりです。

- セキュリティ関連アクティビティの監査 - アプリケーションは、セキュリティ関連のアクティビティを記録する必要があります。

- ビジネス関連アクティビティの監査 - アプリケーションは、フローのコンテキストでビジネス・アクティビティを記録する必要があります。

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

あるアプリケーションは、複数のセキュリティ領域でセキュリティ関連アクティビティを記録する必要があります。具体的には、次の情報を記録する必要があります。

- ポリシーへの変更: 何がいつ変更されたか

- 特定の時間間隔内に評価されたポリシー

- 資格証明またはキーへの変更: 何がいつ変更されたか

このユースケースで説明する設定は、ドメイン内のすべてのアプリケーションおよびコンポーネントに当てはまります。

このユースケースでは、監査可能なアプリケーションが次の条件を満たしている必要があります。

- 共通監査フレームワーク(CAF)に統合される

- セキュリティ・アクティビティを記録する機能が組み込まれている

- 特定のセキュリティ領域でアクティビティを取得するための適切な監査フィルタ・レベルが設定されている

このユースケースでは、次の機能を使用します。

- 共通監査フレームワークへの統合

- アプリケーションがセキュリティ領域内で独自の監査カテゴリおよびイベントを定義することを可能にし、アプリケーションを監査対応にする

- アプリケーションでの適切なフィルタ・レベルの設定を可能にする

詳細は、次の各項を参照してください。

- CAFへの統合については、第25.2項「監査フレームワークへのアプリケーションの統合」を参照してください。

- アプリケーションの登録については、第25.4項「登録サービスへのアプリケーションの登録」を参照してください。

- 監査イベントの記録については、第25.6項「監査イベントを記録するためのアプリケーション・コードの追加」を参照してください。

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

アプリケーションは、機能フローのコンテキストでビジネス関連アクティビティを記録する必要があります。具体的には、ユーザーおよびそのユーザーにより特定の間隔で実行されるビジネス・アクションのロギングを行う必要があります。

このユースケースで説明する設定は、ドメイン内のすべてのアプリケーションおよびコンポーネントに当てはまります。

このユースケースでは、アプリケーションが次の操作を行う必要があります。

- ビジネス・ニーズに基づいて独自の監査イベントを作成する

- データ・リポジトリを監査するための実行時属性とともにビジネス・アクティビティを記録する

- 監査イベントから監査レポートを生成する

- 実行時監査ポリシーを管理する

- 必要に応じて監査イベント定義を変更する

このユースケースでは、次の機能を使用します。

- アプリケーションがビジネス機能領域(監査カテゴリとして)、ビジネス・アクティビティ(カテゴリ内の監査イベントとして)、および各カテゴリ内に属性を定義することを可能にする

- デプロイメント時のアプリケーションの登録、監査定義の更新、デプロイメント後のアプリケーションの登録解除

- Fusion Middleware ControlまたはWSLTスクリプトを使用した監査アーティファクトの管理

詳細は、次の各項を参照してください。

- CAFへの統合については、第25.2項「監査フレームワークへのアプリケーションの統合」を参照してください。

- アプリケーションの登録については、第25.4項「登録サービスへのアプリケーションの登録」を参照してください。

- 監査イベントの記録については、第25.6項「監査イベントを記録するためのアプリケーション・コードの追加」を参照してください。

- component_events.xmlファイルの例については、第25.3項「監査定義ファイルの作成」を参照してください。

- 監査ポリシーの管理については、第14.3項「監査ポリシーの管理」を参照してください。

16.2.6 アイデンティティ伝播

アイデンティティ伝播ユースケースは次のとおりです。

- 実行ユーザー・アイデンティティの伝播 - SOAPを介したWebサービスへの実行ユーザー・アイデンティティの伝播。

- ユーザー・アイデンティティの伝播 - SOAPを介したWebサービスへのユーザー・アイデンティティの伝播。

- 別のドメインへのアイデンティティの伝播 - 別のWebLogicドメインへのユーザー・アイデンティティの伝播。

- HTTPを介したアイデンティティの伝播 - HTTPを介したユーザー・アイデンティティの伝播。

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

コンテナ内のあるクライアント・アプリケーションは、SOAPを介してWebサービスに実行ユーザー・アイデンティティを伝播する必要があります。Webサービスは、同じドメイン内または別のドメイン内の別の管理対象サーバー上で実行されています。

このユースケースでは、現在の実行ユーザー・アイデンティティをSOAPを介してWebサービスに伝播する必要があります。

このユースケースを実現するために、主にOracle Web Services Manager (OWSM)の機能を使用します。

OWSMの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

SOAPを介したアイデンティティの伝播の詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

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

コンテナ内のあるクライアント・アプリケーションは、SOAPを介してWebサービスにユーザー・アイデンティティ(実行ユーザー・アイデンティティではない)を伝播する必要があります。伝播するアイデンティティはOPSSセキュリティ・ストアに格納されています。

このユースケースでは、現在の実行ユーザーとは別のユーザーのアイデンティティを、SOAPを介してWebサービスに伝播する必要があります。

このユースケースでは、次の機能を使用します。

- 資格証明が格納され、アプリケーションがPasswordCredentialとして伝播する必要がある特定のアイデンティティを取得するOPSSセキュリティ・ストア

- アイデンティティをフェッチし、リモートWebサービスに伝播するOracle Web Services Managerの機能

このユースケースの詳細は、『Oracle Web Services ManagerによるWebサービスの保護とポリシーの管理』を参照してください。

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

WebLogicドメインのコンテナ内のあるクライアント・アプリケーションは、ユーザー・アイデンティティ(OPSSセキュリティ・ストアに格納されている)を、RMIを介して別のWebLogicドメインに伝播する必要があります。

このユースケースの詳細は、WebLogic Serverドメイン間の信頼の有効化に関する項を参照してください。

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

WebLogicドメインのコンテナ内のあるクライアント・アプリケーションは、HTTPを介してアイデンティティを伝播する必要があります。

このユースケースの要件および詳細は、「OPSSトラスト・サービスを使用したアイデンティティの伝播」の推奨される実装に関する項を参照してください。OPSSキーストア・サービスを使用しない代替の実装は、「付録 - JKSベースのキーストアを使用したアイデンティティの伝播」で説明します。

16.2.7 管理

管理ユースケースは次のとおりです。

- 中央ストアが必要なアプリケーション - アプリケーションに、セキュリティ・アーティファクトを管理するためのアーティファクトの中央リポジトリが必要です。

- カスタム管理ツールが必要なアプリケーション - アプリケーションに、外部化したセキュリティ・アーティファクトの中央リポジトリを管理するためのカスタム・ツールが必要です。

- 複数のサーバー環境で実行されるアプリケーション - アプリケーションは、複数ノードのサーバー環境でセキュリティ・アーティファクトを変更する必要があります。

16.2.7.1 中央ストアが必要なアプリケーション

あるアプリケーションには、ポリシー、資格証明、監査構成、信頼およびキーを格納する中央リポジトリ(OPSSセキュリティ・ストア)、およびその中央リポジトリを管理するためのツール・セットが必要です。

このユースケースでは、次の機能を使用します。

- OPSSセキュリティ・ストア

- Fusion Middleware Controlを使用したセキュリティ・アーティファクトの管理

- WLSTコマンドを使用したセキュリティ・アーティファクトの管理

詳細は、次の各項を参照してください。

- OPSSセキュリティ・ストアについては、第9.1項「OPSSセキュリティ・ストアの概要」を参照してください。

- セキュリティ・アーティファクトの管理については、次の各項を参照してください。

- 第10.2項「Fusion Middleware Controlを使用したポリシーの管理」

- 第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」

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

- 第11.4項「WLSTコマンドを使用した資格証明の管理」

- 第12章「キーストア・サービスでのキーと証明書の管理」

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

あるアプリケーションには、アプリケーションのビジネスに意味のあるコンテキストで、外部化したセキュリティ・アーティファクトを管理するためのカスタム・ツールが必要です。

このユースケースでは、アプリケーションに意味のあるコンテキストでOPSSセキュリティ・ストア内のセキュリティ・アーティファクトを表示および管理するためのOPSS APIへのコールを含む、カスタム・グラフィカル・ユーザー・インタフェースを構築する必要があります。

このユースケースでは、次の機能を使用します。

- OPSS APIを使用したセキュリティ・アーティファクトの管理

詳細は、次の各項を参照してください。

- OPSS APIを使用して、セキュリティ・アーティファクトを管理するために必要な操作の一部を実装する方法を示すコード・サンプルについては、「カスタム・グラフィカル・ユーザー・インタフェース」を参照してください。

- OPSS APIのリストについては、付録G「OPSS APIリファレンス」を参照してください。

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

複数のサーバー・インスタンスが複数のマシンに分散されているWebLogicドメイン内で実行されているアプリケーションが、セキュリティ・アーティファクトを変更する必要があります。変更は、どこで実行されているかにかかわらず、アプリケーションのすべてのコンポーネントに反映されなければなりません。

このユースケースでは、次の機能を使用します。

- 管理サーバー上でセキュリティ・アーティファクトの変更が開始された場合の変更の伝播。管理対象サーバー・ノード上のデータは、キャッシュ・ポリシーに基づいてリフレッシュされます。

- MBean APIまたは管理APIを使用したセキュリティ・アーティファクトの変更。

詳細は、次の各項を参照してください。

- 複数のサーバー・ノードについては、第9.1.1項「複数サーバー環境」を参照してください。

- OPSSサービスおよびMBeanについては、付録Eの「MBeanを使用したOPSSサービスの構成」を参照してください。

16.2.8 統合

統合ユースケースは次のとおりです。

- 複数のドメインで実行されるアプリケーション - セキュリティ・アーティファクトの単一のリポジトリを共有する複数のWebLogicドメイン。

16.2.8.1 複数のドメインで実行されるアプリケーション

ある製品では、複数のWebLogicドメインを実行する必要があり、これらのドメインは単一の中央OPSSセキュリティ・ストアを共有します。

このユースケースでは、次の機能を使用します。

- 1つのセキュリティ・ストアを共有する複数のドメインに対するOPSSのサポート

詳細は、次の各項を参照してください。

- 資格証明ストアを共有するドメインについては、第11.2項「資格証明の暗号化」を参照してください。

- reassociateSecurityStoreを使用して既存のOPSSセキュリティ・ストアに結合する方法については、第10.3.1項「reassociateSecurityStore」を参照してください。

16.3 OPSSトラスト・サービス

OPSSトラスト・サービスにより、トークンを提供および検証することによって、HTTP対応のアプリケーションにアイデンティティを伝播できます。OPSSトラスト・サービスは、次のプラットフォームでのみ使用可能なアサーション・プロバイダを使用します。

- Oracle WebLogic Application Server - IDアサーション・プロバイダ

WebLogicドメインごとに1つのアサーション・プロバイダが存在します。

サービス構成プロパティの詳細は、第F.2.6項「トラスト・サービスのプロパティ」を参照してください。Fusion Middleware Controlを使用したこのサービスの構成の詳細は、第9.7.3項「トラスト・サービス・プロバイダの構成」を参照するか、WLSTコマンドupdateTrustServiceConfigを使用してください。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

16.4 HTTPプロトコルを介したアイデンティティの伝播

HTTPコールを使用したアイデンティティ伝播は、一般的に次のように実行されます(図16-2を参照)。

1. Domain1のクライアント・アプリケーションが、Domain1のOPSSトラスト・サービス・インスタンスに対して、認証されたユーザーに対するトークンをリクエストします。

2. トラスト・サービスがDomain1のキーストアにアクセスし、トークンをクライアント・アプリケーションに発行します。

3. クライアント・アプリケーションがトークンをHTMLヘッダー内にエンコードし、HTTPリクエストをDomain2のサーブレット・アプリケーションにディスパッチします。Domain 2のアサーション・プロバイダがリクエストをインターセプトし、トークンを抽出します。

4. アサーション・プロバイダがDomain2のOPSSトラスト・サービス・インスタンスに対して、そのトークンの検証をリクエストします。

5. トラスト・サービスがトークンを検証するためにDomain2のキーストアにアクセスし、レスポンスを返します。

6. 検証が成功したとみなし、アサーション・プロバイダはアサートされたアイデンティティを使用して、リクエストをサーブレット・アプリケーションに送信します。

7. サーブレット・アプリケーションが、クライアント・アプリケーション・リクエストに対するHTTPレスポンスを送信します。

図16-2 HTTPコールを使用したアイデンティティ伝播

即時利用可能な構成では、キー別名はWebLogicサーバー名に基づいて設定されます。

注意:

アイデンティティの伝播を実装するには、「OPSSトラスト・サービスを使用したアイデンティティの伝播」の説明に従って、OPSSトラスト・サービスおよびOPSSキーストアを使用する方法をお薦めします。

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

この項では、複数ドメイン間および単一のドメイン内の複数コンテナ間で、OPSSトラスト・サービスを使用してアイデンティティを伝播する方法を説明します。トラスト・サービスを使用したアイデンティティの伝播は、Oracle Weblogic Serverプラットフォームでのみサポートされています。

OPSSキーストア・サービスの詳細は、第12章「キーストア・サービスでのキーと証明書の管理」を参照してください。

この項では、Oracle WebLogicプラットフォームのOPSSトラスト・サービスを使用したアイデンティティの伝播に必要とされるコードおよび構成のサンプルについて説明します。この項の内容は次のとおりです。

- 複数のWebLogicドメイン間

- 単一のWebLogicドメイン内のコンテナ間

- 埋込みトラスト・サービス・プロバイダのプロパティ

16.5.1 複数のWebLogicドメイン間

このシナリオでは、Domain1とDomain2という2つのドメインが存在します。クライアント・アプリケーションはDomain1で、サーブレット・アプリケーションはDomain2で実行されています。クライアント・アプリケーションはトークンの生成にDomain1のOPSSトラスト・サービスを使用し、サーブレット・アプリケーションはトークンの検証にDomain2のOPSSトラスト・サービスを使用します。

次の各項で、このシナリオで必要なサンプルおよび構成について説明します。

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

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

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

クライアント側、つまりトークンを発行するドメインでは、次の作業が必要です。

- クライアント・アプリケーションの開発

- OPSSキーストア・サービスの構成

- 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 OPSSキーストア・サービスの構成

トラスト・サービス・キーストアは、クライアント証明書および秘密鍵を使用してプロビジョニングされます。その証明書は、キーストアからエクスポートされてトラスト・ストアへインポートされます。これらのストア、キーストアおよびトラスト・ストアはいずれも、クライアント・ドメインのOPSS 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="")
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権限の追加

次のシステム・ポリシーは、トラスト・サービスAPIの使用をクライアントに許可するコードソースの権限付与を示しており、アプリケーションの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>

付与は、WLSTコマンドを使用してOPSSセキュリティ・ストアに追加できます(詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』でスクリプトgrantPermissionを参照してください)。

または、アプリケーションがJava EEアプリケーションで、jazn-data.xmlファイルがアプリケーションとパッケージ化されている場合は、アプリケーションのデプロイ時に権限がOPSSセキュリティ・ストアに移行されるように、ライフサイクル・リスナーを設定できます(詳細は、第18.2項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください)。

16.5.1.1.4 トラスト・サービス・プロバイダの構成

次のサンプルでは、jps-config.xmlファイルのトラスト・サービス・プロバイダの構成を示します。

<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 サーバー側つまりトークン検証ドメイン

サーバー側、つまりトークンを受信するドメインでは、次の作業が必要です。

- サーバー・アプリケーションの開発

- web.xmlの構成

- WebLogicトラスト・サービス・アサーション・プロバイダの構成

- OPSSキーストア・サービスのプロビジョニング

- TrustServiceAccessPermissionの追加

- トラスト・サービス・プロバイダの構成

16.5.1.2.1 サーバー・アプリケーションの開発

次のサンプルは、サーブレット・コードがアサートされたユーザーを取得する方法を示しています。

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 WebLogicトラスト・サービスのアサーション・プロバイダの構成

WebLogicトラスト・サービス・アサーション・プロバイダを構成するには、次の手順を実行します。

1. 次のいずれかを実行します。

- WebLogicコンソールに管理者としてログインし、「セキュリティ・レルム」→myrealm→「プロバイダ」タブ→「認証」の順に移動してTrustServiceIdentityAsserterを選択します。
このアサーション・プロバイダは、トラスト・サービスAPIをコールして受信するリクエストからのトークンをデコードし、検証します。そして、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 OPSSキーストア・サービスのプロビジョニング

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 TrustServiceAccessPermissionの追加

次のシステム・ポリシーは、トラスト・サービスAPIの検証をクライアントに許可するコードソースの権限付与を示しており、アプリケーションの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>validate</actions>
</permission>
</permissions>
</grant>

16.5.1.2.6 トラスト・サービス・プロバイダの構成

次のサンプルでは、jps-config.xmlファイルのトラスト・サービス・プロバイダの構成を示します。

<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ドメイン内のコンテナ間

このシナリオでは、クライアント・アプリケーションとサーバー・アプリケーションは同じドメインで稼働します。したがって、両方のアプリケーションが同じキーストアを使用できるため、(その他のキーストアに対して)クライアント証明書をインポートする必要がありません。その他の情報はすべて、複数ドメインのシナリオで説明された内容と同じです。

16.5.3 埋込みトラスト・サービス・プロバイダのプロパティ

次のプロパティは、単一ドメインまたは複数ドメインのシナリオで、埋込みトラスト・サービス・プロバイダの構成に使用されます。

- trust.keyStoreType

- trust.keyStoreName

- trust.trustStoreName

- trust.aliasName

- trust.issuerName

- trust.provider.className

- trust.clockSkew

- trust.token.validityPeriod

- trust.token.includeCertificate

次のサンプルでは、jps-config.xmlファイルの埋込みトラスト・サービス・プロバイダのサンプル構成を示します。

<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>

埋込みトラスト・サービス・プロバイダのプロパティを設定するには、WLSTコマンドupdateTrustServiceConfigを使用するか、または第9.7.3項「トラスト・サービス・プロバイダの構成」の説明に従ってFusion Middleware Controlを使用します。コマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

「OPSSキーストア・サービスの構成」で説明される構成では、<stripName>、<keystoreName>、<trustStoreName>、<aliasName>の値を適切に設定します。

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

このユースケースでは、たとえばポリシーを管理するためにカスタム・グラフィカルUIを実装する場合などに必要な操作の一部を示しています。紹介するサンプルはOPSS APIを使用し、次の操作について説明します。

- アイデンティティ・ストア内のユーザーの問合せ。

- OPSSセキュリティ・ストア内のアプリケーション・ロールの問合せ。

- ユーザーとグループからアプリケーション・ロールへのマッピングの問合せ。具体的には、ユーザーにマップされているすべてのアプリケーション・ロールを特定します(ユーザーとグループからアプリケーション・ロールへのマッピングは多対多関係です)。

- ユーザーとグループからアプリケーション・ロールへのマッピングの作成、読取り、更新および削除。

このユースケースは次のことを前提としています:

- アイデンティティ・ストアがOID LDAPベースのストアであること。

- OPSSセキュリティ・ストアは、OID LDAPベースのストアです。

- アイデンティティ・ストアに次のユーザーとグループの階層(エンタープライズ・ロール)が含まれること。

- ユーザー: Mary、John、TomおよびHelen。

- グループ: IT、TrainingおよびDevelopment。

- グループTrainingおよびDevelopmentはグループITのメンバーです。

- ユーザーMaryはグループTrainingのメンバーです。

- ユーザーTomとJohnはグループDevelopmentのメンバーです。

- OPSSセキュリティ・ストアには、次のアプリケーション・ポリシーおよびアプリケーション・ロールの階層が含まれます。

- アプリケーション・ポリシーApplicationPolicy1とApplicationPolicy2。

- ロールSystem Manager、System DeveloperおよびSystem Analystは、ポリシーApplicationPolicy1で参照されるアプリケーション・ロールです。ロールSystem ManagerはロールSystem Developerのメンバーで、ロールSystem DeveloperはロールSystem Analystのメンバーです。

- ロールDirector、InstructorおよびLecturerは、アプリケーション・ポリシーApplicationPolicy2で参照されるアプリケーション・ロールです。ロール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のメンバーです。

コード・サンプルについては、次の各項に詳しく示します。

- 前提とするインポート - インポートのリスト

- コード・サンプル1 - アイデンティティ・ストアの問合せ。

- コード・サンプル2 - アプリケーション・ロールの作成とロールへのメンバーの割当て。

- コード・サンプル3 - アプリケーション・ロールの問合せ。

- コード・サンプル4 - ユーザーとグループへのアプリケーション・ロールのマッピング。

- コード・サンプル5 - 特定のユーザーがメンバーであるすべてのロールの取得。

- コード・サンプル6 - アプリケーション・ロールからグループへのマッピングの削除。

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 コード・サンプル1

次のサンプル・コードは、アイデンティティ・ストア内のユーザーに対する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 コード・サンプル2

次のサンプル・コードは、アプリケーション・ロールを作成する方法およびロールを別のロールのメンバーにする方法を示しています。

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 コード・サンプル3

次のサンプル・コードは、アプリケーション・ロールを問い合せる様々な方法を示しています。

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 コード・サンプル4

次のサンプル・コードは、アプリケーション・ロールをユーザーとグループにマップする方法を示しています。

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 コード・サンプル5

次のサンプル・コードは、特定のユーザーがメンバーであるすべてのロールを取得する方法を示しています。

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.
// In the WebLogic Server, this setting is done by a login module
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 コード・サンプル6

次のサンプル・コードは、アプリケーション・ロールからグループへのマッピングを削除する方法を示しています。

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 付録 - ADFアプリケーションのセキュリティ・ライフサイクル

この項では、アプリケーションのセキュリティがたどるフェーズについて説明します。ここではアプリケーションがADFを使用し、Oracle JDeveloper環境を使用していることを前提として説明します。

アプリケーションのセキュリティ・ライフサイクルのフェーズとは、開発フェーズ、デプロイメント・フェーズ、および管理フェーズです。関係する担当者は製品マネージャ、アプリケーション設計者、アプリケーション開発者、およびアプリケーション・セキュリティ管理者です。タスクの概要については、「各フェーズの担当者別タスクの概要」を参照してください。

16.7.1 開発フェーズ

開発フェーズでは、開発者によってOracle Fusion Middlewareで使用可能な広範なセキュリティ・オプション機能がアプリケーションと連携するように設計されます。開発者はOracle JDeveloper、組込みのADFフレームワーク、およびOracle WebLogicサーバーで公開される豊富なセキュリティ・サービスを利用できます。これらのコンポーネントはすべてOPSSを基盤としています。OPSSによってアプリケーションの使用期間全体にわたってセキュリティ・アプローチの整合性が保持されることが保証されます。

通常、開発者はADFセキュリティ・ウィザード(認可エディタ)および式言語エディタを使用します。これらはすべてOracle JDeveloperにあります。さらに、必要に応じて、OPSS APIを使用してより複雑なセキュリティ・タスクを実装することもできます。これによってアプリケーションの一部で宣言によるセキュリティを使用し、別の部分でプログラムによるセキュリティを使用でき、また、いずれの場合も開発および実行時環境で使用可能なセキュリティ機能を利用できます。

アプリケーション開発者は、アプリケーションの保護に必要な複数のアプリケーション権限およびロール(ポリシー・シード・データ)も定義します。このポリシー・シード・データは、アプリケーションのソース・コードとともにソース・コントロール・システムに格納されます。

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

通常、開発後のアプリケーションは本番環境にデプロイする前にステージング環境でテストされます。本番環境では、アプリケーションと実行時サービスの両方が他のセキュリティ・コンポーネントと統合されます。このコンポーネントは、ユーザー・ディレクトリ、シングル・サインオン・システム、ユーザー・プロビジョニング・システム、監査機能などです。一般にセキュリティ・サービスはフェーズとともに変化します。たとえば、開発時は開発者がファイルまたはOracleウォレットを利用してユーザーの資格証明を格納しますが、本番環境では資格証明はLDAPディレクトリ(OPSSセキュリティ・ストア)に格納されます。

通常デプロイメント・フェーズでは、管理者がポリシー・シード・データを本番OPSSセキュリティ・ストアに移行し、アプリケーション・ポリシーに応じてアプリケーション・ロールをエンタープライズ・グループにマッピングします。

16.7.3 管理フェーズ

管理フェーズは、アプリケーションが本番環境にデプロイされたときに開始します。このフェーズではアプリケーション管理者またはエンタープライズ・セキュリティ管理者が日常的なセキュリティ・タスクを管理します。このタスクにはアプリケーション・リソースへのユーザー・アクセス権限の付与、監査ログの確認、セキュリティ・インシデントへの対応、セキュリティ・パッチの適用などが含まれます。

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

次の各表はセキュリティ・ライフサイクルのフェーズごとに、担当者別に主要な担当任務をまとめたもので、図16-4は、基本的なフローを示します。

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

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

フェーズ

タスク

開発

機能のセキュリティ要件およびデータのセキュリティ要件に基づいて高度なアプリケーション・ロールを定義します。

初期のファイルベースのアプリケーション・ポリシー・ストアを移入します(jazn-data.xml)。

デプロイメント

QAチームのテストに使用する実際のカスタマ・シナリオを定義します。

管理

アプリケーション・ポリシーのカスタマイズ要件を理解し、特定します。

垂直産業向けのテンプレートの定義を検討します。

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

フェーズ

タスク

開発

特にOracle JDeveloperのツールおよびプロセスを使用して、アプリケーションを構築し、アプリケーション・ロールやパーミッションなどのセキュリティ・アーティファクトを作成します。

FND権限を使用して、データレベルのセキュリティを指定します。

ローカル・ポリシー・ストア使用し、サンプルのユーザーとロールでアプリケーションをテストします。

デプロイメント

QAチームによる実行時の問題のトラブルシューティングおよび解決を支援します。

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

フェーズ

タスク

デプロイメント

デプロイメント・サービスを使用して、jazn-data.xmlのセキュリティ・シード・データを本番ポリシー・ストアに移行します。

アプリケーション・ロールをエンタープライズ・グループにマッピングして、セキュリティ・ポリシーの適用を可能にします。

管理

必要に応じてソフトウェアにパッチおよびアップグレードを適用します。

企業のユーザーおよびアプリケーション・ロールの階層は時間とともに変化するため、それに応じてユーザーとロールを管理します。

アプリケーションにパッケージ化されたポリシーを管理し、新たなポリシーを作成します。

IAMインフラストラクチャとの統合および管理を行います。

16.8 付録 - コードおよび構成例

この項では、このガイドの他の章に記載されている、ほとんどのコード・サンプルと構成サンプルのリストおよび完全なコード例を示します。

- コード例

- 構成例

- セキュリティが統合されたJava EEアプリケーションの完全なコード例

16.8.1 コード例

次のリストは、一般的なセキュリティ関連のプログラミング・タスクおよび実装方法を示すサンプル・コードへのリンクです。

- LDAPアイデンティティ・ストアの問合せ - 第8.4項「プログラムによるアイデンティティ・ストアの問合せ」を参照してください。

- アプリケーション・ロールの問合せ、およびユーザーとグループからアプリケーション・ロールへのマッピングの問合せ - 「カスタム・グラフィカル・ユーザー・インタフェース」を参照してください。

- メソッドisUserInRoleの呼出し - 第17.2.2.2項「プログラムによる認可」を参照してください。

- ポリシーの管理 - 第17.3.2項「ポリシーの管理」を参照してください。

- ポリシーの確認 - 第17.3.3項「ポリシーの確認」を参照してください。

- クラスResourcePermissionの使用方法 - 第17.3.4項「クラスResourcePermission」を参照してください。

- Java SEアプリケーションでの認証のためのアイデンティティ・ストア・ログイン・モジュールの使用方法 - 第19.3.3.1.1項「認証のためのアイデンティティ・ストア・ログイン・モジュールの使用」を参照してください。

- Java SEアプリケーションでのアサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用方法 - 第19.3.3.1.2項「アサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用」を参照してください。

16.8.2 構成例

次のリストは、一般的なセキュリティ関連の構成タスクおよびサンプル構成へのリンクです。

- リソース・パーミッションの構成 - 第17.3.4項「クラスResourcePermission」を参照してください。

- サーブレット・フィルタおよびEJBインターセプタの構成 - 第18.2項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

- migrateSecurityStoreでの構成 - 第6.6.2.1項「migrateSecurityStoreを使用したポリシーの移行」および第6.6.2.2項「migrateSecurityStoreを使用した資格証明の移行」を参照してください。

- LDAPアイデンティティ・ストアの構成 - 第8.3.2.8項「構成ファイルの例」および第19.3.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」を参照してください。

- Java SEアプリケーションでのポリシーと資格証明ストアの構成 - 第20.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストア」を参照してください。

16.8.3 セキュリティが統合されたJava EEアプリケーションの完全なコード例

ezshareは、セキュリティがOPSSに統合され、パーミッションベースの権限付与を使用し、Oracle Networkからダウンロード可能なJava EEアプリケーションの完全な例です。この例を見つけるには、キーワードezshareで検索してください。

16.9 付録 - JKSベースのキーストアを使用したアイデンティティの伝播

即時利用可能な構成では、トークン発行者名およびキー別名はWebLogicサーバー名に基づいて設定されます。これらのデフォルト値を変更するには、第16.9.1.8項「トラスト・サービス構成パラメータの更新」で説明されている手順を使用します。

次の各項で、HTTPプロトコルを介したアイデンティティの伝播(JKSベースのキーストアを使用)について説明します。

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

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

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

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

このシナリオでは、クライアント・アプリケーションとサーブレット・アプリケーションは同じトラスト・サービス・インスタンスを使用して、トークンを発行および検証します。次の各項では、同じドメイン内で実行されているクライアント・アプリケーションとサーブレット・アプリケーションのコードおよび構成サンプルを示します。

- クライアント・アプリケーションのコード・サンプル

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

- CSFの構成

- 権限付与の構成

- サーブレット・コードのサンプル

- web.xmlの構成

- WebLogicアサーション・プロバイダおよびトラスト・サービスの構成

- トラスト・サービス構成パラメータの更新

16.9.1.1 クライアント・アプリケーションのコード・サンプル

次のサンプルは、クライアント・アプリケーションを示しており、jps-api.jarファイルおよびOSDT 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 キーストア・サービスの構成

WebLogicサーバー名を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 CSFの構成

キーストアを開くために使用するマップ/キー・ペアと、トークンを発行するために使用する別のマップ/キー・ペアを作成します。次のコマンドは、WLSTコマンドcreateCredを使用してこれらの操作を行う方法を示しています。

// 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")

WLSTコマンドcreateCredの詳細は、第11.4項「WLSTコマンドを使用した資格証明の管理」を参照してください。

16.9.1.4 権限付与の構成

次のようなコードソースの権限付与を含むシステム・ポリシーをOPSSセキュリティ・ストアに追加し、これによって、クライアント・アプリケーションにトラスト・サービスAPIを使用することが許可されます。

<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>

この権限付与を有効にするには、Oracle WebLogic Serverを停止してから再起動する必要があります。

16.9.1.5 サーブレット・コードのサンプル

次のサンプルは、サーブレットがアサートされたユーザー名を取得する方法を示しています。

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 WebLogicアサーション・プロバイダおよびトラスト・サービスの構成

WebLogicアサーション・プロバイダを構成するには、次の手順を実行します。

1. 次のコマンドに示すように、WebLogic IDアサーション・プロバイダJARであるjps-wls-trustprovider.jarを${domain.home}/lib/mbeantypesにコピーし、WebLogic Serverを再起動します。

cp ${common.components.home}/modules/oracle.jps_11.1.1/jps-wls-trustprovider.jar ${domain.home}/lib/mbeantypes

2. WebLogicコンソールを使用して、アサーション・プロバイダを次のように構成します。

1. 管理者としてコンソールにログインします。

2. 「セキュリティ設定」→「セキュリティ・レルム」→「myrealm」→「プロバイダ」タブ→「認証」に移動し、「新規」をクリックして、「新しい認証プロバイダの作成」ダイアログを開きます。

3. そのダイアログで、名前ボックスにTrustServiceIdentityAsserterと入力し、タイプ・ボックスのプルダウンからTrustServiceIdentityAsserterを選択し、「OK」をクリックします。

3. OPSSセキュリティ・ストアに、アサーション・プロバイダがOPSSトラスト・サービスAPIを使用するために必要な次のような権限付与が存在することを確認します(必要であれば、WSLTスクリプトを使用して次のコードソース・システム・ポリシーを指定します)。

<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の初期状態の値はWebLogicサーバー名に設定されています。これらの値をデプロイ固有の値に変更するには、次のようなスクリプトを使用します。

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で、サーブレット・アプリケーションはDomain2で実行されています。各ドメインには、「単一ドメイン・シナリオ」の「WebLogicアサーション・プロバイダとトラスト・ストアの構成」の説明に従って適切に構成されたトラスト・ストア・サービスとキーストアがそれぞれ存在することを前提とします。このシナリオでは、クライアント・アプリケーションはトークンの生成にDomain1のトラスト・サービスを使用し、サーブレット・アプリケーションはトークンの検証にDomain2のトラスト・サービスを使用します。

Domain1では、クライアントのサンプル・コードと次の構成は、「単一ドメイン・シナリオ」で説明したものと同じです。

- クライアント・アプリケーションのコードについては、「クライアント・アプリケーションのコード・サンプル」を参照してください。

- キーストアの構成については、「キーストア・サービスの構成」を参照してください。

- CSFの構成については、「CSFの構成」を参照してください。

- 権限付与の構成については、「権限付与の構成」を参照してください。

Domain2では、サーブレットのサンプル・コードとweb.xmlの構成は、「単一ドメイン・シナリオ」で説明したものと同じですが、追加の設定が必要になります。

- サーブレット・アプリケーションのコードについては、「サーブレット・コードのサンプル」を参照してください。

- web.xmlファイルの構成については、「web.xmlの構成」を参照してください。

- Domain1でトークンを署名するために使用されたクライアント証明書がDomain2のキーストアに存在する必要があります。したがって、管理者は次の手順を実行します。

1. 次のコマンドを使用して、Domain1のキーストアから証明書をエクスポートします。

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. WLSTコマンドcreateCredを次のように使用して、Domain2のキーストア・パスワードを(Domain2の)資格証明ストアで設定します。

createCred(map="oracle.wsm.security", key="keystore-csf-key", user="keystore", password="password")

このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

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

このシナリオでは、アプリケーションはHTTPプロトコルまたはSOAPプロトコルのいずれかを使用し、ドメイン内のすべてのアプリケーションが同じプロトコルを使用するわけではありません。このようなシナリオでは、HTTPプロトコルで使用されるトラスト・サービスとOracle Web Services Managerで使用されるSOAPサービスで、キーストアを共有できます。ただしこの場合にトラスト・サービスが機能するには、次の各項で説明するように、jps-config.xmlファイルで特別な構成が必要になります。

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

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

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 be added in the token used by the destination
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 trust store 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>

注意1:

クライアント側では、trust.issuerNameの値はtrust.aliasNameと同じ値にすることができます。ただし、発行者名の値は、(前述の例で示されたように)trust.issuerNameに別の値を設定することで、オーバーライドすることが可能です。この発行者名は、クライアント側で生成されたトークンに設定されます。

注意2:

サーバーがトークンの検証のみに使用される場合は、サーバー側でtrust.aliasNameおよびtrust.issuerNameの設定は必須ではありません。トークンの生成中に設定された発行者名が、サーバー側で証明書を検索する間、使用されます。このため、クライアントからインポートされた証明書は、クライアント側の発行者名を別名としてサーバー側にエクスポートされます(前述の例のdomain1)。

次のスニペットは、別名がorakeyの証明書に対するトークンを受け取るドメインに必要な構成を示しています。

<!- important: 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ポリシー・モデル

この章では、OPSSポリシーおよび認可モデルについて説明します。

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

- 第17.1項「セキュリティ・ポリシー・モデル」

- 第17.2項「認可の概要」

- 第17.3項「JAAS/OPSS認可モデル」

17.1 セキュリティ・ポリシー・モデル

OPSSポリシー・モデルおよび使用されるセキュリティ・アーティファクトの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

17.2 認可の概要

この項では、Java EEとJAASのモデルで使用可能な認可を比較検討しています。この項の内容は次のとおりです。

- 認可について

- Java EE認可モデル

- JAAS認可モデル

17.2.1 認可について

Java 2ポリシーは、特定の場所からロードされた署名付きコードに付与されるパーミッションを指定します。JAASポリシーは、オプションのプリンシパル・リストを指定できるようにすることで、Java 2の権限を拡張します。これにより、特定の場所からロードされた(多くの場合は署名付きの)コードにのみパーミッションが付与され、このリストにあるプリンシパルで表されるユーザーによって実行されます。

OPSSセキュリティ・ストアは、システムおよびアプリケーションに固有のポリシーとロールを格納するリポジトリです。アプリケーション・ロールは、アプリケーション固有のエンタープライズ・ユーザーおよびグループ(管理ロールなど)に付与(マップ)できます。ポリシーでは、これらのロール、グループまたはユーザーにプリンシパルとしてパーミッションを付与できます。

ポリシー関連のセキュリティ・アーティファクトの詳細は、第3章「ポリシー・ストアの基本」を参照してください。

アプリケーションでは、認可の適用をコンテナに委任できる他、checkPermission、checkBulkAuthorization、getGrantedResourcesなどのメソッドのコールによってポリシー確認を自身で適用する実装も可能です。

APIコールを使用したポリシー確認の詳細は、「ポリシーの確認」を参照してください。

17.2.2 Java EE認可モデル

Java EE認可モデルでは、ロール・メンバーシップを使用して、EJBメソッドおよびURLで参照するWebリソースへのアクセスを制御します。ポリシーによってユーザーとロールにパーミッションが割り当てられ、ポリシーがコンテナで適用されてリソースが保護されます。

Java EEモデルでは、次のいずれかの方法で認可が実装されます。

- 宣言的。この方法では、認可ポリシーがデプロイメント・ディスクリプタで指定されます。コンテナはデプロイメント・ディスクリプタから認可ポリシーを読み取って実施します。認可を実施するための特別なアプリケーション・コードは必要ありません。

- プログラム的。この方法では、アプリケーション・コードで認可ポリシーを確認します。このコードによって、特定のコード・セクションの実行に適したパーミッションがサブジェクトにあるかどうかを確認します。サブジェクトに適切なパーミッションが与えられていない場合、コードは例外をスローします。

表17-1は、各方法の長所と短所を示しています。

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

認可のタイプ

長所

短所

宣言

コーディングが不要。デプロイメント・ディスクリプタのみを変更すればよいため、更新が簡単。

認可のレベルが大まかであり、URLレベルまたはメソッド・レベル(EJBの場合)で指定されます。

プログラム

アプリケーション・コードで指定され、よりきめ細かいレベルでコードを保護できます。

コード変更や再コンパイルを伴うため、更新は容易ではありません。

コンテナは、その内部で稼働中のアプリケーションに対して、宣言的およびプログラム的という2つの方法で認可を提供できます。次の各項ではこれらの方法を説明して例を示します。

- 宣言による認可

- プログラムによる認可

- Java EEコードの例

17.2.2.1 宣言による認可

宣言的な認可では、URLベースのリソース(サーブレットやページなど)やEJBのメソッドに対するアクセスを制御できます。

宣言的な認可を構成する基本手順は、次のとおりです。

1. 標準のデプロイメント・ディスクリプタで、保護するリソース(Web URL、EJBメソッドなど)と、そのリソースへのアクセス権を持つ論理ロールを指定します。
または、Java EE 1.5は注釈をサポートしているため、デプロイメント・ディスクリプタではなくコード注釈を使用します。

2. 固有デプロイメント・ディスクリプタ(web.xmlなど)では、ステップ1で定義した論理ロールをエンタープライズ・グループにマップします。

17.2.2.2 プログラムによる認可

プログラム的な認可では、宣言的な方法よりもきめ細かい認可を実現でき、メソッドisUserInRole(サーブレットおよびJSPの場合)またはメソッドisCallerInRole (EJBの場合)をアプリケーションのコードから呼び出す必要があります(これらはどちらも標準のJava APIに用意されています)。

これらのメソッドは、認可の決定に関してロール・メンバーシップにある程度は依存しますが、これらの使用により、ユーザーは、リソース・レベル(EJBのメソッドまたはURL)のアクセス制御に限定されることがないため、よりきめ細かく認可の決定を制御できるようになります。

17.2.2.3 Java EEコードの例

次の例では、メソッドisUserInRoleをコールするサーブレットを示しています。サーブレットをパッケージ化しているEARファイルには構成ファイルweb.xmlおよびweblogic-application.xmlが含まれており、これらのファイルには次の構成の断片が含まれていることを前提とします。

web.xml

<!-- security roles -->
<security-role>
<role-name>sr_developer</role-name>
</security-role>

weblogic-application.xml

次のスニペットは、ユーザーweblogicとセキュリティ・ロールsr_developer間のマッピングを示しています。

<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.3 JAAS認可モデル

JAAS認可ではパーミッションを使用しますが、ロールの概念も使用できます。認可ポリシーによって、パーミッションがサブジェクト(ロール、グループまたはユーザー)にバインドされ、さらに必要に応じてソース・コードにもバインドされます。ロールの付与は、addPrincipalsToAppRoleのコールで実現します。

パーミッションは静的メソッドAccessController.checkPermissionのコールによって評価されます。このモデルでは、リソースをきめ細かく制御できます。

このモデルでは、認可ポリシーで次の情報が指定されます。

- アプリケーション・ロールおよびエンタープライズ・グループ。

- ユーザー、(アプリケーション・ポリシー内の)グループおよび(システム・ポリシー内の)コード・ソースに付与されるパーミッション。ユーザーおよびグループの場合は、これによってアクセスが許可されるユーザーまたはグループのメンバーが決定されます。コード・ソースの場合は、これによって、コードが実行できるアクションが決定されます。

このモデルを使用してプログラミングする場合、機密性の高いコード行の前に、現在のユーザーまたはロールがそのコードにアクセスするための適切なパーミッションを付与されているかどうかを確認するコールを記述します。ユーザーが適切なパーミッションを持っている場合は、コードが実行されます。適切なパーミッションが与えられていない場合、コードは例外をスローします。

複数のパーミッションによるコード・ソースの付与の例は、第18.5.6項「サポートされているパーミッション・クラス」を参照してください。

17.3 JAAS/OPSS認可モデル

JAASおよびOPSS認可では、クラスを環境にロードして実行するときに、そのクラスで実行できる操作を制御することが基本になっています。

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

- リソース・カタログ

- ポリシーの管理

- ポリシーの確認

- クラスResourcePermission

17.3.1 リソース・カタログ

OPSSは、ファイルベース、LDAPベース、およびDBベースのOPSSセキュリティ・ストア内のリソース・カタログの仕様およびランタイム・サポートに対応します。

リソース・カタログの使用には次の利点があります。

- 判読可能な用語でポリシーおよび保護アーティファクトが記述されます。

- アプリケーション・ソース・コードに関係なく、またこれらのコードに関する知識を必要とせずに、ポリシーを定義し、変更できます。

- 保護アーティファクトを参照および検索できます。

- 後で認可ポリシーで使用できるビルディング・ブロック(権限またはパーミッションのセット)に保護アーティファクトをグループ化できます。

17.3.2 ポリシーの管理

リソース・カタログ・アーティファクトをポリシー管理APIで管理できます。具体的には、次のインタフェースがリソース・カタログのアーティファクトに直接関連しています。これらはすべてインタフェースoracle.security.jps.service.policystore.EntityManagerの下位インタフェースです。

- GrantManager - このインタフェースに用意されているメソッドでは、検索条件を使用して権限を問い合せ、リソース・カタログ・アーティファクトの様々な組合せに適合する権限のリストを取得して、プリンシパルに対してパーミッションを付与または取り消すことができます。

- PermissionSetManager - このインタフェースに用意されているメソッドでは、パーミッション・セット(権限)の作成、変更および問合せを実行できます。

- ResourceManager - このインタフェースに用意されているメソッドでは、リソース(リソース・インスタンス)の作成、削除および変更を実行できます。

- ResourceTypeManager - このインタフェースに用意されているメソッドでは、リソース・タイプの作成、削除、変更および問合せを実行できます。

これらのインタフェースの詳細は、JavadocドキュメントのOracle Fusion Middleware Oracle Platform Security Services Java APIリファレンスを参照してください。

次のコード・スニペットは、リソース・タイプ、リソース・インスタンス、アクションおよびパーミッション・セットの作成を示しています。

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 ポリシーの確認

この項では、プログラム上でポリシーを確認する方法をいくつか示します。この項の内容は次のとおりです。

- メソッドcheckPermissionの使用方法

- メソッドdoAsおよびdoAsPrivilegedの使用方法

- メソッドcheckBulkAuthorizationの使用方法

- メソッドgetGrantedResourcesの使用方法

重要な注意:

1. デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debugを-Djps.auth.debug=trueに設定する必要があります。

特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を前述のように設定する必要があります。

2. OPSSポリシー・プロバイダは、次の例に示すように、Java SEアプリケーションに明示的に設定する必要があります。

java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())

Java SEアプリケーションにポリシー・プロバイダを明示的に設定しておかないと、ランタイム・メソッド(JpsAuth.checkPermissionなど)が不正確な値を返す場合があります。

17.3.3.1 メソッドcheckPermissionの使用方法

Oracle Fusion Middlewareは、クラスjava.security.AccessControllerおよびoracle.security.jps.util.JpsAuthのメソッドcheckPermissionの使用をサポートしています。

クラスJpsAuthのcheckPermissionを使用することをお薦めします。これは、このクラスのほうがデバッグ・サポートとパフォーマンスにおいて優れており、監査もサポートされるためです。

静的メソッドAccessController.checkPermissionは、デフォルトのアクセス制御コンテキスト(スレッド作成時に継承されるコンテキスト)を使用します。その他のコンテキストでパーミッションを確認するには、特定のAccessControlContextインスタンスでインスタンス・メソッドcheckPermissionをコールします。

次の表に示すように、メソッドcheckPermissionはJAASモード(第18章「サーブレット・フィルタとEJBインターセプタの構成」を参照)の値に従って動作します。

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

JAASモードの設定

checkPermission

オフまたは未定義

有効なセキュリティ・ポリシーに基づくコードベースのセキュリティを実施します。サブジェクトベースのセキュリティに対するプロビジョニングはありません。

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-based permissions -->
<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で、doAsメソッドとdoAsPrivilegedメソッドをサポートします。

ただし、これらのメソッドは、パフォーマンスが高く、監査機能も備えているため、oracle.security.jps.util.JpsSubjectクラスで使用することをお薦めします。

注意:

checkPermissionをdoAsブロックの中でコールして、パーミッション・チェックのコールが失敗した場合、失敗した保護ドメインを表示するには、システム・プロパティjava.security.debug=access,failureを設定する必要があります。

17.3.3.3 メソッドcheckBulkAuthorizationの使用方法

メソッドcheckBulkAuthorizationでは、サブジェクトが1つ以上のリソース・アクションにアクセスできるかどうかを判断できます。具体的には、渡したリソースの中で、渡したサブジェクトに対してアクセスが許可されているリソース・アクションのセットを返します。

(Java SEアプリケーションで)このメソッドを呼び出す場合は次の点を確認してください。

1. システム・プロパティjava.security.policyが、OPSSまたはOracle WebLogic Serverのポリシー・ファイルの場所に設定されています。

2. ポリシー・プロバイダを明示的に設定するには、次に示すように、アプリケーションでまずメソッドsetPolicyからコールする必要があります。

java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaPolicyProvider())

3. アプリケーションでは、setPolicyをコールした後でcheckBulkAuthorization()がコールされます。

どのアプリケーションでも、checkBulkAuthorizationではコール元から次の情報が得られることが前提となっています。

- ユーザーおよびエンタープライズ・ロールのプリンシパルが指定されたサブジェクト

- 各リソースが属するストライプが含まれるリソースのリスト

リソース・パーミッションの使用の権限付与には、必須のリソース・タイプを含める必要があります。

checkBulkAuthorizationでも、アプリケーションを実行しているドメインに構成したOPSSセキュリティ・ストア・ストライプを、そのアプリケーションから認識できることが前提となっています。

checkBulkAuthorizationでは、OPSSセキュリティ・ストアにリソースが存在している必要はありません。

17.3.3.4 メソッドgetGrantedResourcesの使用方法

メソッドgetGrantedResourcesには、実行時の認可問合せが用意されているため、特定のサブジェクトに付与されているリソース・アクションをこの問合せから得ることで、そのサブジェクトに付与されているすべてのリソースをフェッチできます。このメソッドでは、(直接またはパーミッション・セットから間接的に)リソース・タイプに関連付けられているパーミッションのみが返されます。また、このメソッドは、OPSSセキュリティ・ストアがLDAPベースの場合にのみ使用できます。

17.3.4 クラスResourcePermission

パーミッション・クラスでは、リソースに対して権限受領者が実行できるアクションを制御する手段が提供されます。アプリケーションの設計段階では、アクション、ターゲット照合および暗黙の論理が実行時に想定どおりに機能するようにカスタムのパーミッション・クラスを使用して全面的に制御できます。その場合でも、サーバーのシステム・クラスパスでカスタムのパーミッション・クラスを指定し、必要に応じてそのパーミッション・クラスを使用可能にしてロードできるようにしておく必要があります。ただし、環境のシステム・クラス・パスの変更は困難で、環境によってはそのような変更ができないこともあります。

OPSSには、アプリケーションまたはシステム・リソースを保護するためにどのアプリケーション権限内でもパーミッション・クラスとして使用できるクラスoracle.security.jps.ResourcePermissionが用意されています。これにより、クラスResourcePermissionがそのままですぐに使用でき、サポート対象であればどのポリシー・プロバイダに格納されているアプリケーション権限でもパーミッションで容易に使用できるため、アプリケーション開発者がカスタムのパーミッション・クラスを作成する必要がなくなりました。このクラスはシステム・ポリシーでの使用を意図していません。アプリケーション・ポリシー専用として設計されています。

リソース・パーミッションの構成

ResourcePermissionクラスを使用するパーミッションは、リソース・パーミッションと呼ばれ、次のXMLサンプルで示している形式に基づいてリソース・タイプ、リソース名およびオプションのアクション・リストを指定します。

<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()メソッドで返されます。

- リソース・パーミッションでは、ワイルドカードの使用はサポートされていません。

リソース・パーミッションの管理と確認

次のコード・スニペットは、リソース・パーミッションのインスタンス化およびリソース・パーミッションをプログラム的に確認する方法を示しています。このコード・スニペットは、「リソース・パーミッションの構成」で説明している構成例の1つに基づいています。

ResourcePermission rp =
new ResourcePermission("oracle.bi.publisher.Reports","GLReports","develop");
JpsAuth.checkPermission(rp);

実行時にリソース・パーミッションで次の4つの条件が満たされると、そのパーミッションは適切であると判断されます。

- パーミッションがResourcePermisionクラスのインスタンスです。

- リソース・タイプ名(最初の引数)がリソース・タイプの名前に一致します(大文字小文字の区別はなし)。

- リソース名(2つ目の引数)がリソース・インスタンスの名前に完全に一致します。

- アクション・リスト(3つ目の引数)が、リソース・タイプで指定されているアクションのカンマ区切りリストです。

リソース・タイプのマッチャ・クラスについて

リソース・タイプの作成時にオプションでマッチャ・クラスを指定できます。指定しなかった場合は、デフォルトのoracle.security.jps.ResourcePermissionが使用されます。

ただし、2つ以上のリソース・タイプで同一のリソース・マッチャ・クラスが共有される場合は、次のクラスのいずれかにする必要があります。

- クラス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 OPSSを使用するためのJava EEアプリケーションの構成

この章では、Oracle ADFセキュリティを使用せずにOPSSを使用するJava EEアプリケーションでお薦めする手動による構成とパッケージ化について説明します。ただし、一部のトピックは、Oracle ADFアプリケーションにも当てはまります。対象読者は、Oracle JDeveloper環境の外部でJava EEアプリケーションを構成し、パッケージ化する開発者です。また、アサートされたユーザーとして実行に使用できるAPIについても説明します。

Java SEアプリケーションの情報は、第19章「OPSSを使用するためのJava SEアプリケーションの構成」を参照してください。

この章は次の項に分かれています:

- 第18.1項「Java EEアプリケーションの認証トピックへのリンク」

- 第18.2項「サーブレット・フィルタとEJBインターセプタの構成」

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

- 第18.4項「Java EEアプリケーションの手動によるパッケージ化」

- 第18.5項「OPSSを使用するためのアプリケーションの構成」

- 第18.6項「アサートされたユーザーとしての実行」

開発時、デプロイ時、実行時およびデプロイ後のアプリケーション管理に関係するファイルは、次のとおりです。

- 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ファイル内)

18.1 Java EEアプリケーションの認証トピックへのリンク

次にあげるドキュメントでは、Java EEアプリケーションの認証開発について説明します。

- Oracle WebLogic Serverでの認証に関する一般情報は、『Oracle WebLogic Serverセキュリティの理解』の第3章にある認証に関する説明を参照してください。

- WebLogic Securityサービスを使用したアプリケーションの開発

- 第3章「Webアプリケーションの保護」

- 第4章「Java ClientでのJAAS認証の使用」

- 第5章「Java ClientでのSSL認証の使用」

- Oracle WebLogic Serverのセキュリティ・プロバイダの開発

- 第4章「認証プロバイダ」

- 第5章「IDアサーション・プロバイダ」

- 第13章「サーブレットの認証フィルタ」

- Java EEアプリケーション内のカスタム・モジュールは、認証プロバイダでラップする必要があります。詳細は、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタム認証プロバイダの開発方法に関する説明を参照してください。

- Java EEアプリケーションで使用されるログイン・モジュールについては、次のドキュメントを参照してください。

- 『Oracle WebLogic Serverセキュリティ・プロバイダの開発』の第4章にあるLoginModuleに関する説明

- 『WebLogicセキュリティ・サービスによるアプリケーションの開発』の第4章にあるJAAS認証の開発環境に関する説明

- 第19.3.3項「ログイン・モジュール」

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

18.2 サーブレット・フィルタとEJBインターセプタの構成

OPSSはサーブレット・フィルタJpsFilterとEJBインターセプタJpsInterceptorを備えています。前者はWARファイルでパッケージ化されるファイルweb.xmlで、後者はJARファイルでパッケージ化されるファイルejb-jar.xmlで構成されます。アプリケーションMBeanがアクセスするストライプをファイルweb.xmlで構成する方法も、OPSSによって提供されます。詳細は、「アプリケーションMBeansのアプリケーション・ストライプの構成」を参照してください。

WebLogicでは、JpsFilterはデフォルトのパラメータ値で自動的に設定され、そのまますぐに使用できるため、デプロイメント・ディスクリプタで明示的に構成する必要はありません。デフォルト値以外の値を設定する場合にのみ手動構成が必要です。JpsInterceptorは手動で構成する必要があります。

注意:

Oracle ADFアプリケーションに必要なサーブレット・フィルタ(JpsFilter)およびEJBインターセプタ(JpsInterceptor)の構成は、Oracle JDeveloperによって自動的に挿入されます。

この項で説明している手動による構成は、次で説明しているOPSS機能をOracle JDeveloper環境の外部で使用してJava EEアプリケーションをパッケージ化または構成する場合にのみ必要です。

OPSSでは、MBeanが使用するアプリケーション・ストライプの指定が可能です。詳細は、「アプリケーションMBeansのアプリケーション・ストライプの構成」を参照してください。

サーブレット・フィルタとEJBインターセプタは同じパラメータ・セットを使用して構成できます。これらのパラメータによって、サーブレットまたはEnterprise Java Bean (EJB)の次の機能をカスタマイズできます。

- アプリケーション名(ストライプ)

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

- 匿名ユーザーおよび匿名ロールのサポート

- 認証ロールのサポート

- JAASモード

アプリケーション名(アプリケーション・ストライプと呼ぶ方がふさわしく、アプリケーションのweb.xmlファイル内で指定することも可能)は、適用可能なポリシー・セットを決定するために、実行時に使用されます。アプリケーション・ストライプは、指定しない場合、アプリケーションID(アプリケーション名が含まれる)がデフォルト値として使用されます。

アプリケーション・ストライプでは、ポリシー・ストア内のポリシーのサブセットが定義されます。アプリケーションでそのポリシー・サブセットを使用する場合は、そのアプリケーション名と同じ文字列を使用してアプリケーション・ストライプを定義します。この方法によって、ポリシー・ストア内のポリシーの同じサブセットを複数のアプリケーションで使用できます。

匿名ロールと認証ロールの機能は、「匿名ユーザーとロール」および「認証ロール」の項で説明します。

サーブレットでは、要素<filter-mapping>でフィルタの使用を指定します。このような要素は、サーブレットごと、フィルタごとに1つ必要です。

EJBでは、要素<interceptor-binding>でインターセプタの使用を指定します。このような要素は、EJBごと、インターセプタごとに1つ必要です。詳細は、「インターセプタ構成構文」を参照してください。

使用可能なパラメータの概要は、「フィルタおよびインターセプタ・パラメータの概要」を参照してください。

アプリケーション名(ストライプ)

この値は、次のパラメータで制御します。

application.name

このパラメータの指定はオプションです。指定時には大文字と小文字が区別されます。指定しないと、デフォルトでデプロイするアプリケーションの名前になります。この値によって、そのアプリケーションが使用する、ポリシー・ストア内のポリシーのサブセットが定義されます。

アプリケーション・ストライプを指定する1つの方法は、filter要素内に配置することです。次に例を示します。

<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>

もう1つの指定方法は、context-param要素内に配置することです。次に例を示します。

<context-param>
<description>JPS custom stripe id</description>
<param-name>application.name</param-name>
<param-value>stripeid</param-value>
</context-param>

この最後の構成が必要になるのは、アプリケーション・ポリシー・ストアにアクセスするMBeansがアプリケーションに含まれ、アプリケーション名がアプリケーション・ストライプ名と異なる場合です。詳細は、「アプリケーションMBeansのアプリケーション・ストライプの構成」を参照してください。

構成例

サーブレットの場合およびEJBの場合のこのパラメータの構成を、次の2つのサンプルで示します。

web.xmlファイルの次のフラグメントは、後続の認可チェックで正しく評価されるように、フィルタを使用して2つのサーブレット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の設定と、EJB 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>

この例で、インターセプタ構成構文の要件がどのように満たされているかに注意してください。

アプリケーション・ロールのサポート

サブジェクトへのアプリケーション・ロールの追加は、次のパラメータで制御します。これはtrueまたはfalseに設定できます。

add.application.roles

サブジェクトにアプリケーション・ロールを追加するには、このプロパティをtrueに設定します。追加しない場合は、falseに設定します。デフォルト値はtrueです。

アプリケーション・ロールのプリンシパル・クラスは、次のとおりです。

oracle.security.jps.service.policystore.ApplicationRole

匿名ユーザーおよび匿名ロールのサポート

サーブレットにおける匿名の使用は、次のパラメータで制御します。これはtrueまたはfalseに設定できます。

enable.anonymous
remove.anonymous.role

EJBの場合は、匿名ユーザーおよび匿名ロールの使用が常に有効であるため、前述の2番目のパラメータのみを使用できます。

サーブレットの場合、匿名ユーザーの使用を有効にするには最初のプロパティをtrueに設定し、無効にするにはfalseに設定します。デフォルト値はtrueです。

サブジェクトから匿名ロールを削除するには2番目のプロパティをtrueに設定し、保持するにはfalseに設定します。デフォルト値はfalseです。匿名ユーザーおよび匿名ロールは、通常は認証後に削除し、認証後に保持するのは特殊な場合のみです。

匿名ユーザーのデフォルト名とプリンシパル・クラスは、次のとおりです。

anonymous
oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl

匿名ロールのデフォルト名とプリンシパル・クラスは、次のとおりです。

anonymous-role
oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl

web.xmlファイルの次のフラグメントは、これらのパラメータの設定およびサーブレットMyServletによるフィルタ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ファイルの次のフラグメントは、第2パラメータに対するfalseの設定と、Enterprise Java Bean 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>

次のフラグメントは、プログラム的に匿名サブジェクトおよびサブジェクトの匿名ロールと匿名ユーザーにアクセスする方法を示しています。

import oracle.security.jps.util.SubjectUtil;

// The next call returns the anonymous subject
javax.security.auth.Subject subj = SubjectUtil.getAnonymousSubject();

// The next call extracts the anonymous role from the subject
java.security.Principal p = SubjectUtil.getAnonymousRole(javax.security.auth.Subject subj)
// Remove or retain anonymous role
...

// The next call extracts the anonymous user from the subject
java.security.Principal p = SubjectUtil.getAnonymousUser(javax.security.auth.Subject subj)
// Remove or retain anonymous user
...

認証ロールのサポート

認証ロールの使用は、次のパラメータで制御します。これはtrueまたはfalseに設定できます。

add.authenticated.role

認証ロールをサブジェクトに追加するにはこのパラメータをtrueに設定し、追加しない場合はfalseに設定します。デフォルト値はtrueです。

認証ロールのデフォルト名とプリンシパル・クラスは、次のとおりです。

authenticated-role
oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl

web.xmlファイルの次のフラグメントは、このパラメータの設定およびサーブレットMyServletによるフィルタ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>

JAASモード

JAASモードの使用は、次のパラメータで制御します。

oracle.security.jps.jaas.mode

このパラメータは、次の値に設定できます。

doAs
doAsPrivileged
off
undefined
subjectOnly

デフォルト値はdoAsPrivilegedです。これらの値によってメソッドcheckPermissionの動作を制御する方法の詳細は、第17.3.3.1項「メソッドcheckPermissionの使用方法」を参照してください。

このパラメータを使用するサーブレットおよびEJBの構成を、次の2つのサンプルで示します。

web.xmlファイルの次のフラグメントは、このパラメータの設定およびサーブレットMyServletによるフィルタ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>

ejb-jar.xmlファイルの次のフラグメントは、このパラメータに対するdoAsの設定と、Enterprise Java Bean MyEjbによるインターセプタ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>

18.2.1 インターセプタ構成構文

次の要件と指定の特性は、JpsInterceptorの場合に構成されるすべてのパラメータに適用されます。

- パラメータの設定では、そのタイプの指定(要素<env-entry-type>内)が必要です。

- パラメータの設定には、要素<injection-target>が必要であり、これをインターセプタのクラスと同じクラスに指定する必要があります(要素<injection-target-class>内)。また、ドットをアンダースコアに置換した文字列として再書き込みしたパラメータ名も必要です(要素<injection-target-name>内)。

- インターセプタのEJBへのバインディングは、EJB名とインターセプタのクラスによって指定します。つまり、インターセプタは、名前ではなくそのクラスによって参照されます。

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

次の表は、JpsFilterおよびJpsInterceptorによって使用されるパラメータの説明をまとめたものです。

表18-1 JpsFilterおよびJpsInterceptorパラメータの概要

パラメータ名

値

デフォルト

機能

注意

application.name

任意の有効な文字列。値では大文字と小文字が区別されます。

デプロイされるアプリケーションの名前

サーブレットまたはEJBによって使用されるポリシーのサブセットを指定します。

ポリシー・ストア内の同じポリシーのサブセットをいくつかのサーブレットまたはEJBで共有する場合は、指定する必要があります。

add.application.roles

TRUEまたはFALSE

TRUE

アプリケーション・ロールをサブジェクトに追加します。

TRUEがデフォルトなので、(FALSEに)設定する必要があるのは、アプリケーションがアプリケーション・ロールをサブジェクトに追加しない場合のみです。

enable.anonymous

TRUEまたはFALSE

TRUE

サブジェクトで匿名ユーザーを有効または無効にします。

TRUEに設定すると、匿名ユーザーおよび匿名ロールとともにサブジェクトが作成されます。

remove.anonymous.role

TRUEまたはFALSE

FALSE

認証後にサブジェクトのアプリケーション・ロールを保持または削除します。

サーブレットでのみ利用可能です。EJBでは、匿名ロールは常にサブジェクトから削除されます。FALSEに設定すると、匿名ロールが、認証後、サブジェクトで保持され、TRUEに設定すると、認証後、削除されます。

add.authenticated.role

TRUEまたはFALSE

TRUE

サブジェクト内で認証ロールの追加を許可します。

TRUEがデフォルト値なので、(FALSEに)設定する必要があるのは、認証ロールをサブジェクトに含めない場合のみです。

oracle.security.jps.jaas.mode

doAsPrivileged

doAs

Off

undefined

subjectOnly

doAsPrivileged

JAASモードを設定します。

18.2.3 アプリケーションMBeansのアプリケーション・ストライプの構成

アプリケーションが次の条件を満たす場合:

- ポリシー・ストアへのアクセスおよび認可チェックを実行するMBeansを含む。

- アプリケーション・ストライプ名がアプリケーション名と異なる。

MBeanがドメイン・セキュリティ・ストアのアプリケーション・ストライプにアクセスするために、ファイルweb.xmlのグローバル・パラメータ(またはコンテキスト・パラメータ)application.nameでストライプ名を指定する必要があります。次に例を示します。

<context-param>
<description>JPS custom stripe id</description>
<param-name>application.name</param-name>
<param-value>stripeid</param-value>
</context-param>

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

注意:

Oracle JDeveloperを使用している場合、このツールによって適切なクラスが選択されます。したがって、次に説明する構成は、ポリシーがOracle JDeveloper環境外で入力された場合にのみ必要です。

アプリケーション・ロールのメンバー内で指定されるクラスは、他のアプリケーション・ロールのクラスか、次のいずれかにする必要があります。

weblogic.security.principal.WLSUserImpl
weblogic.security.principal.WLSGroupImpl

次のフラグメントは、エンタープライズ・グループの指定におけるこれらのクラスの使用を示しています(太字の部分)。

重要:

アプリケーション・ロール名では、大文字小文字が区別されません(次のサンプルのapp_operatorなど)。

エンタープライズ・ユーザーおよびグループ名では、大文字小文字が区別されます(次のサンプルのDevelopersなど)。

大文字小文字の区別に関する情報は、第J.4.2項「パーミッションの付与または取消の失敗 - 大文字と小文字の不一致」を参照してください。

<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>

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

この項では、WebLogic Application ServerにデプロイするサーブレットまたはEJB(カスタムのポリシーと資格証明を使用)のパッケージ化要件について説明します。

アプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。

サーブレットは、構成ファイルweb.xmlを含むWARファイルでパッケージ化され、EJBは、構成ファイルejb-jar.xmlを含むWARファイルでパッケージ化されます。WARファイルでは、フィルタJpsFilter(サーブレット用)またはインターセプタJpsInterceptor (EJB用)の構成を、対応する構成ファイルに含める必要があります。

次の説明は、サーブレットのパッケージ化およびファイルweb.xmlでのJpsFilterの構成を考慮していますが、EJBのパッケージ化およびファイルejb-jar.xmlでのJpsInterceptorの構成にも同等に適用できます。

重要:

現在、EARファイル内にあるすべてのweb.xmlファイルのすべてのJpsFilter構成は、同じ構成にする必要があります。JpsInterceptorにも同じ制約が適用されます。

JpsFilterおよびJpsInterceptorの詳細は、「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

カスタムのポリシーおよび資格証明を使用するJava EEアプリケーションに対するパッケージ化の要件と前提条件は、次のとおりです。

- デプロイされるアプリケーションは、1つのEARファイルにパッケージ化する必要があります。

- EARファイルには、ファイルMETA-INF/jazn-data.xmlが1つ含まれている必要があります。このファイルで、アプリケーションのポリシーおよびロールが指定され、これらはそのEARファイル内のすべてのコンポーネントに同等に適用されます。

- EARファイルには、1つ以上のWARファイルを含めることができます。

- EARファイル内の各WARまたはJARファイルには、web.xml(またはejb-jar.xml)が1つ含まれている必要があります。ここで、JpsFilter(またはJpsInterceptor)が構成され、すべてのEARファイル内のこのような構成は同一である必要があります。

- cwallet.ssoファイル内のコンポーネント資格証明は、EARファイルにパッケージ化できます。これらの資格証明は、Oracle Enterprise Manager Fusion Middleware Controlを使用してアプリケーションをデプロイする際に資格証明ストアに移行できます。

注意:

コンポーネントで、他のコンポーネントとは異なるフィルタの構成が必要な場合は、別個のEARファイルにパッケージ化してデプロイする必要があります。

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

アプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。EARファイルには、ゼロ個以上のWARファイルを含めることができますが、ポリシーはEARディレクトリにあるこのXMLファイルでのみ指定できます。WARファイルで1つのコンポーネントに対して特定のポリシーを指定するには、前述の指定のようにそのコンポーネントを独自のjazn-data.xmlファイルで別個のEARファイルにパッケージ化する必要があります。他のポリシー・パッケージの組合せは、このリリースではサポートされていません。最上位のjazn-data.xml以外のポリシー・ファイルは無視されます。

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

アプリケーションの資格証明は、cwallet.ssoという名前のファイルで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。EARファイルには、ゼロ個以上のWARファイルを含めることができますが、資格証明はそのEARディレクトリにあるcwallet.ssoファイルでのみ指定できます。WARファイルで1つのコンポーネントに対して特定の資格証明を指定するには、前述の指定のようにそのコンポーネントを独自のcwallet.ssoファイルで別個のEARファイルにパッケージ化する必要があります。他の資格証明パッケージの組合せはこのリリースではサポートされていません。最上位のcwallet.sso以外の資格証明ファイルは無視されます。

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

この項では、Oracle JDeveloper環境の外部で開発されたJava EEアプリケーションのために開発者が手動で実行するいくつかの構成について説明します。この項の内容は次のとおりです。

- ポリシーの移行を制御するパラメータ

- 動作に従ったポリシー・パラメータの構成

- 資格証明の移行を制御するパラメータ

- 動作に従った資格証明パラメータの構成

- ウォレットベースの資格証明ストアの使用

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

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

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

- 構成ファイルjps-config.xmlの例

注意:

WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティjps.deployment.handler.disabledを使用します。

このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイルweblogic-application.xmlにあるアプリケーション個別の設定は無視されます。

18.5.1 ポリシーの移行を制御するパラメータ

デプロイでのアプリケーション・ポリシーの移行は、いくつかのパラメータによって制御されます。これらのパラメータはファイルMETA-INF/weblogic-application.xmlで構成します。

アプリケーションのデプロイまたは再デプロイでポリシーの移行を制御するパラメータおよびアンデプロイでポリシーの削除を制御するパラメータは、次のとおりです。

- 移行

- jps.policystore.migration

- jps.apppolicy.idstoreartifact.migration

- jps.policystore.removal

- リスナー

- JpsApplicationLifecycleListener

- プリンシパルの検証

- jps.policystore.migration.validate.principal

- 移行のターゲット(アプリケーション・ストライプ)

- jps.policystore.applicationid

前述の各パラメータの構成と機能を、次に説明します。

注意:

Fusion Middleware Controlでは、アプリケーションのデプロイ、再デプロイまたはアンデプロイの際に、これらのパラメータのほとんどを設定できます。詳細は、第6.2.1項「Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。

次に説明する構成は、Fusion Middleware Controlを使用しないでアプリケーションを管理する場合にのみ、手動で入力する必要があります。

管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ファイルベースのストアを使用するアプリケーションをデプロイする場合は、ライフサイクル・リスナーを使用しないでください。使用した場合、管理対象サーバーと管理サーバーによって管理されているデータが一致せず、セキュリティが期待どおりに機能しない場合があります。ライフサイクル・リスナーを使用するかわりにWLSTコマンドmigrateSecurityStoreを使用して、アプリケーションのポリシーおよび資格証明をドメイン・ストアに移行します。

この注意点は、ファイルベースのストアを使用する場合にのみ適用されます。

jps.policystore.migration

このパラメータでは、移行を実行するかどうか、移行の実行時期、およびターゲット・ストアのポリシーをマージするのか上書きするのかを指定します。

WebLogicでは、次のフラグメントに示すように構成します。

<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です。

jps.policystore.applicationid

このパラメータでは、ポリシーの移行先であるターゲット・ストライプを指定します。

WebLogicでは、次のフラグメントに示すように構成します。

<wls:application-param>
<wls:param-name>jps.policystore.applicationid</wls:param-name>
<wls:param-value>myApplicationStripe</wls:param-value>
</wls:application-param>

任意の有効な文字列をこのパラメータの値に設定できます。このパラメータの値を指定しない場合は、アプリケーション名とバージョン、すなわちapplication_name#versionに基づいて、Oracle WebLogic Serverがストライプ名を選択します。

このパラメータの値は、JpsServlet用に(ファイルweb.xmlで)、またはJpsInterceptor用に(ファイルejb-jar.xmlで)指定されているapplication.name値に一致させる必要があります。詳細は、「アプリケーション名(ストライプ)」を参照してください。

weblogic-application.xmlから選択された値はデプロイ時に使用され、web.xmlまたはejb-jar.xmlから選択された値は実行時に使用されます。

JpsApplicationLifecycleListener

このパラメータはWebLogicでのみサポートされています。次のフラグメントに示すように設定する必要があります。

<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>

jps.apppolicy.idstoreartifact.migration

このパラメータはWebLogicでのみサポートされています。このパラメータでは、エンタープライズ・ユーザーまたはグループに対するアプリケーション・ロールやパーミッションの付与など、エンタープライズ・ユーザーまたはグループに対する参照の移行をポリシーの移行から除外するかどうかを指定します。そのため、アプリケーション・ポリシーのみの移行が可能となり、有効にすると、エンタープライズ・グループまたはユーザーへのアプリケーション・ロールのマッピングが、移行時に無視されます。

これは、次のフラグメントに示すように構成されます。

<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に設定してアプリケーションをデプロイする(アプリケーションに固有でないポリシーの移行が除外される)場合、アプリケーションをドメイン内で使用する前に、管理者はFusion Middleware ControlまたはWebLogic管理コンソールを使用してアプリケーション・ロールからエンタープライズ・グループまたはユーザーへのマッピングを実行する必要があります。

この設定により、アプリケーション・ロールに対する管理者の制御がいかに強化されているかに注意してください。

次の例は、同じjazn-data.xmlファイルのフラグメントを示しています。アプリケーションEARファイルにパッケージ化されるこのファイルでは、アプリケーションの認可ポリシーを示します。

ファイル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>

jps.policystore.removal

このパラメータでは、アンデプロイ時にポリシーの削除を実行しないかどうかを指定します。

WebLogicでは、次のフラグメントに示すように構成します。

<wls:application-param>
<wls:param-name>jps.policystore.removal</wls:param-name>
<wls:param-value>OFF</wls:param-value>
</wls:application-param>

設定する場合は、このパラメータの値をOFFにする必要があります。デフォルトでは、このパラメータは設定されません。

OFFに設定した場合、ポリシーは削除されません。設定しない場合、ポリシーは削除されます。

同一のアプリケーション・ストライプを複数のアプリケーションで共有する場合は、前述の設定を考慮する必要があります。アプリケーションのアンデプロイ時は、他のアプリケーションが共通のポリシー・セットを使用している可能性があるため、アプリケーション・ポリシーを削除しないよう選択します。

注意:

特定のアプリケーションに対してこのパラメータをOFFに設定する場合は、そのアプリケーションのデプロイ時にアプリケーション・ストライプを他のアプリケーションと共有するように指定したかどうかを確認しておく必要があります。

jps.policystore.migration.validate.principal

このパラメータはWebLogicでのみサポートされています。このパラメータでは、デプロイ時または再デプロイ時に、システムおよびアプリケーションのポリシー内のプリンシパルをチェックするかどうかを指定します。

これは、次のフラグメントに示すように構成されます。

<wls:application-param>
<wls:param-name>jps.policystore.migration.validate.principal</wls:param-name>
<wls:param-value>TRUE</wls:param-value>
</wls:application-param>

設定する場合は、このパラメータの値をTRUEまたはFALSEにする必要があります。

TRUEに設定すると、エンタープライズ・ユーザーおよびグループの妥当性がシステムによってチェックされます。(アプリケーションまたはシステム・ポリシー内の)プリンシパルがアイデンティティ・ストアにないエンタープライズ・ユーザーまたはグループを参照した場合は、警告が発行されます。FALSEに設定すると、このチェックがスキップされます。

このパラメータを設定しなかった場合のデフォルト値は、FALSEです。

検証エラーはサーバー・ログに記録されます。検証エラーが発生しても動作は停止しません。

18.5.2 動作に従ったポリシー・パラメータの構成

この項では、アプリケーション・ポリシーの管理時に次のような動作を実行するのに必要な設定について説明します。

- ポリシーの移行をスキップする

- ポリシーをマージにより移行する

- ポリシーを上書きにより移行する

- ポリシーを削除する(またはポリシーを削除しない)

- 静的デプロイメントでポリシーを移行する

予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。詳細は、「推奨事項」を参照してください。

どの動作も、Fusion Middleware Controlによるアプリケーションのデプロイ時、再デプロイ時またはアンデプロイ時に、Fusion Middleware Controlで指定できます。

18.5.2.1 ポリシーの移行をスキップするには

次のマトリクスは、移行を行わない設定を示しています。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OFF

通常、ドメイン・ポリシーをそのまま保持する場合はアプリケーションの再デプロイ時にポリシーの移行をスキップしますが、初めてアプリケーションをデプロイするときはポリシーを移行します。

18.5.2.2 ポリシーをマージにより移行するには

次のマトリクスは、ターゲット・ストアにないポリシーのみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。

表18-3 マージによりポリシーを移行するための設定

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

MERGE

[jps.policystore.applicationid]

適切な文字列に設定します。デフォルト値はサーブレット名またはEJB名です。

[jps.apppolicy.idstoreartifact.migration]

エンタープライズ・アーティファクトを参照するポリシーの移行を除外する場合はFALSE、除外しない場合はTRUEに設定します。デフォルト値はTRUEです。

[jps.policystore.migration.validate.principal]

アプリケーション・ポリシーおよびシステム・ポリシーでエンタープライズのユーザーとロールを検証する場合は、TRUEに設定します。それ以外の場合は、FALSEに設定します。指定しなかった場合は、デフォルトのFALSEが設定されます。

ポリシーが変更され、これを既存のポリシーに追加する場合は通常、再デプロイ時にマージによるポリシーの移行を選択します。

18.5.2.3 ポリシーを上書きにより移行するには

次のマトリクスは、一致するターゲット・ポリシーを上書きして全ポリシーを移行する設定を示しています(オプション・パラメータは大カッコで囲んであります)。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OVERWRITE

[jps.policystore.migration.validate.principal]

アプリケーション・ポリシーおよびシステム・ポリシーでエンタープライズのユーザーとロールを検証する場合は、TRUEに設定します。それ以外の場合は、FALSEに設定します。指定しなかった場合は、デフォルトのFALSEが設定されます。

新しいポリシー・セットで既存のポリシーを置き換える場合は通常、再デプロイ時に上書きによるポリシーの移行を選択します。オプション・パラメータjps.policy.migration.validate.principalは、必要な場合、手動で設定する必要があります。

18.5.2.4 ポリシーを削除する(またはポリシーを削除しない)には

システム・ポリシー内でコード・ソースの付与が削除できないため、アンデプロイ時のアプリケーション・ポリシーの削除は制限されています。詳細は、「削除されるデータと削除されないデータ」を参照してください。

次のマトリクスは、アンデプロイ時にポリシーを削除する設定を示しています。

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

アンデプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.removal

設定しない(デフォルト)

注意:

アンデプロイ時に削除するポリシーは、デプロイ時または再デプロイ時にアプリケーションで指定したストライプによって決まります。元のものとは異なるストライプを指定して再デプロイしたアプリケーションでは、元のストライプのポリシーは削除されません。

次のマトリクスは、アンデプロイ時にアプリケーション・ポリシーを削除しない設定を示しています。

表18-6 ポリシーを削除しないための設定

アンデプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.removal

OFF

注意:

特定のアプリケーションに対してこのパラメータをOFFに設定する場合は、そのアプリケーションのデプロイ時にアプリケーション・ストライプを他のアプリケーションと共有するように指定したかどうかを確認しておく必要があります。

削除されるデータと削除されないデータ

ポリシーの移行と削除が自動的に実行されるように構成されているアプリケーションmyAppを考えます。アプリケーションのjazn-data.xmlファイル(アプリケーションEARファイルにパッケージ化されている)の次のフラグメントは、Fusion Middleware Controlによってアプリケーションがデプロイされるときに移行されるアプリケーション・ポリシーと、Fusion Middleware Controlによってアプリケーションがアンデプロイされるときに削除されるアプリケーション・ポリシーおよび削除されないアプリケーション・ポリシーを示しています。

<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 domain 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 codebase grant is migrated to the element
jazn-policy in domain system-jazn-data.xml; when myApp is undeployed
with EM, it is not removed from domain 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>

要約すると、削除されるデータに関しては、次の点が重要です。

- 要素<application>内のデータはすべて、アンデプロイ時に自動的に削除できます。LDAPベースのポリシー・ストアの場合、アプリケーション・スコープの認可ポリシー・データ・ノードはクリーンアップされます。

- 要素<jazn-policy>内のデータはすべて、アンデプロイ時に自動的に削除できません。

18.5.2.5 静的デプロイメントでポリシーを移行するには

表18-7は、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーを移行する設定を示しています。MERGEまたはOVERWRITEの操作は、アプリケーション・ポリシーがドメインにまだ存在していない場合にのみ実行できます。

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

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

MERGEまたはOVERWRITE

表18-8は、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーの移行をスキップする設定を示しています。

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

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OFF

18.5.2.6 推奨事項

次の点に留意してください。

LDAPベースのポリシー・ストアを使用し、アプリケーションを複数の管理対象サーバーにデプロイする場合は、それらのサーバーの1つに対してのみ移行を行うよう選択します。残りのデプロイでは、ポリシーを移行しないよう選択します。これにより、ポリシーはアプリケーション・ストアからポリシー・ストアに一度のみ移行されます。すべてのデプロイで、同じアプリケーションIDを使用する必要があります。

同じアプリケーションで同一のノードに対するポリシーの移行を複数回(たとえば異なる管理対象サーバー上で)試行すると、ポリシーの移行が失敗する場合があります。別の方法として、WLSTコマンドmigrateSecurityStoreを使用して、デプロイ・プロセスの外部でポリシー・データをストアに移行することもできます。

ただし、アプリケーションが複数のサーバーにデプロイされ、ポリシー・ストアがファイルベースである場合、移行によってポリシー・ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlを更新するには、デプロイに管理サーバーを含める必要があります。

18.5.3 ウォレットベースの資格証明ストアの使用

ウォレットベースの資格証明ストアのコンテンツは、cwallet.ssoという名前のファイルで定義します。ウォレットベースの資格証明ストアはファイルベースの資格証明ストアとも呼ばれます。

ウォレットの作成手順は、『Oracle Fusion Middlewareの管理』のウォレットの一般的な操作に関する説明を参照してください。

ファイルcwallet.ssoの場所は、次の例のように、構成ファイルjps-config.xmlの要素<serviceInstance>で指定します。

<serviceInstance name="credstore" provider="credstoressp">
<property name="location"  value="myCredStorePath"/>
</serviceInstance>

他のタイプの資格証明の格納については、『Oracle Fusion Middlewareの管理』の「キーストローク、ウォレットおよび資格証明の管理」を参照してください。

18.5.4 資格証明の移行を制御するパラメータ

デプロイ時、アプリケーションの資格証明の移行は、いくつかのパラメータで制御されます。これらのパラメータはファイルMETA-INF/weblogic-application.xmlで構成します。

資格証明の移行を制御するパラメータは、jps.credstore.migrationです。リスナーは、JpsApplicationLifecycleListener - Credentialsです。

jps.credstore.migration

このパラメータでは、移行を実行するかどうか、移行の実行時期、およびターゲット・ストアに存在する一致する資格証明をマージするのか上書きするのかを指定します。

WebLogicでは、次のフラグメントに示すように構成します。

<wls:application-param>
<wls:param-name>jps.credstore.migration</wls:param-name>
<wls:param-value>behaviorValue</wls:param-value>
</wls:application-param>

設定する場合、このパラメータの値は、MERGE、OVERWRITE、OFFのいずれかである必要があります。値OVERWRITEは、WebLogicのみを対象とし、またこのサーバーが開発モードで稼働している場合にのみ使用できます。

設定しない場合、資格証明の移行はオプションMERGEを使用して行われます。

JpsApplicationLifecycleListener - 資格証明

このリスナーはWebLogicでのみサポートされています。次のフラグメントに示すように構成します。

<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>

18.5.5 動作に従った資格証明パラメータの構成

この項では、アプリケーション資格証明の移行時に次のような動作を実行するのに必要な手動設定について説明します。

- 資格証明の移行をスキップする

- 資格証明をマージにより移行する

- 資格証明を上書きにより移行する

予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。

移行のターゲットがLDAPベースの資格証明ストアの場合、アプリケーションは1つの管理対象サーバーまたはクラスタにのみデプロイしてください。そうしないと、アプリケーション資格証明が予期したとおりに動作しない場合があります。

注意:

資格証明は、アプリケーションをアンデプロイしても削除できません。アプリケーションとパッケージ化した時点から資格証明が有効になっている可能性がありますが、そのアプリケーションをアンデプロイしても資格証明は削除されません。

18.5.5.1 資格証明の移行をスキップするには

次のマトリクスは、移行を行わない設定を示しています。

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

デプロイ時または再デプロイ時に有効

jps.credstore.migration

OFF

18.5.5.2 資格証明をマージにより移行するには

次のマトリクスは、ターゲット・ストアにない資格証明のみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.credstore.migration

MERGE

18.5.5.3 資格証明を上書きにより移行するには

この操作は、WebLogicサーバーのみを対象とし、またサーバーが開発モードで稼働している場合にのみ有効です。次のマトリクスは、一致するターゲットの資格証明を上書きしてすべての資格証明を移行する設定を示しています。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.credstore.migration

OVERWRITE

jps.app.credential.overwrite.allowed

このシステム・プロパティはTRUEに設定する必要があります。

18.5.6 サポートされているパーミッション・クラス

コードベースの権限付与のコンポーネントを、system-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.policystore.PolicyStoreAccessPermission
</class>
<name>context=SYSTEM</name>
<actions>getConfiguredApplications</actions>
</permission>
<permission>
<class>
oracle.security.jps.service.policystore.PolicyStoreAccessPermission
</class>
<name>context=APPLICATION,name=*</name>
<actions>getApplicationPolicy</actions>
</permission>
</permissions>
</grant>

この項では、<permission>内の要素<class>、<name>および<actions>でサポートされている値について説明します。

重要:

ポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。

18.5.6.1 ポリシー・ストアのパーミッション

クラス名:

oracle.security.jps.service.policystore.PolicyStoreAccessPermission

特定のアプリケーションにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。

context=APPLICATION,name=appStripeName

すべてのアプリケーションにパーミッションが適用される場合は、対応する要素<name>に対して次の名前パターンを使用します。

context=APPLICATION,name=*

すべてのアプリケーションおよびシステム・ポリシーにパーミッションが適用される場合は、対応する要素<name>に対して次の名前パターンを使用します。

context=SYTEM

対応する要素<actions>で使用できる値のリストを次に示します(*は許可された任意のアクションを表します)。

*
createPolicy
getConfiguredApplications
getSystemPolicy
getApplicationPolicy
createApplicationPolicy
deleteApplicationPolicy
grant
revoke
createAppRole
alterAppRole
removeAppRole
addPrincipalToAppRole
removePrincipalFromAppRole
hasPermission
containsAppRole

18.5.6.2 資格証明ストアのパーミッション

クラス名:

oracle.security.jps.service.credstore.CredentialAccessPermission

特定のマップとそのマップ内の特定のキーにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。

context=SYSTEM,mapName=myMap,keyName=myKey

特定のマップとそのマップ内のすべてのキーにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。

context=SYSTEM,mapName=myMap,keyName=*

対応する要素<actions>で使用できる値のリストを次に示します(*は許可された任意のアクションを表します)。

*
read
write
update
delete

18.5.6.3 一般的なパーミッション

クラス名:

oracle.security.jps.JpsPermission

oracle.security.jps.callback.IdentityCallbackのコールバック・インスタンスによって実行されたアサーションにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。

IdentityAssertion

対応する要素<actions>で使用できる唯一の値は、次のとおりです。

execute

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

このトピックは、LDAPベースのストアに対する再関連付けを実行する際にOracle Fusion Middleware Controlを使用しない管理者を対象としています。

管理者がLDAPディレクトリに接続およびアクセスするために必要な資格証明は、cwallet.ssoという別個のファイル(ブートストラップ資格証明)で指定し、ファイルjps-config.xmlで構成する必要があります。これらの資格証明は、LDAP再関連付けプロセスの後に格納されます。ブートストラップ資格証明は常にファイルベースです。

LDAPベースのポリシー・ストアまたは資格証明ストアのすべてのインスタンスでは、次に示すように<jpsContex>要素で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にあると想定されています。

LDAPベースのポリシー・ストアまたは資格証明ストアのインスタンスは、次のLDAPベースのポリシー・ストアのインスタンスに示すように、プロパティ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になります。

WLSTコマンドに対して変更を加えるかブートストラップ資格証明を追加するには、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のmodifyBootStrapCredentialに関する説明およびaddBootStrapCredentialに関する説明を参照してください。

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

アイデンティティ・データは、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲットLDAPリポジトリに移行できます。詳細は、第6.6.1.1項「migrateSecurityStoreを使用したアイデンティティの移行」を参照してください。

18.5.9 構成ファイルjps-config.xmlの例

次の例は、いくつかのサービスとプロパティの構成を示すjps-config.xmlファイル全体を示し、これらのサービスおよびプロパティはJava EEアプリケーションにもJava SEアプリケーションにも適用されます。

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd">
<property value="off" name="oracle.security.jps.jaas.mode"/>
<propertySets>
<propertySet name="saml.trusted.issuers.1">
<property value="www.oracle.com" name="name"/>
</propertySet>
</propertySets>

<serviceProviders>
<serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE">
<description>SecretStore-based CSF Provider</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider" name="idstore.ldap.provider" type="IDENTITY_STORE">
<description>LDAP-based IdentityStore Provider</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" name="idstore.xml.provider" type="IDENTITY_STORE">
<description>XML-based IdentityStore Provider</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE">
<description>XML-based PolicyStore Provider</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.login.jaas.JaasLoginServiceProvider" name="jaas.login.provider" type="LOGIN">
<description>JaasLoginServiceProvider to conf loginMod servInsts</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.keystore.KeyStoreProvider" name="keystore.provider" type="KEY_STORE">
<description>PKI Based Keystore Provider</description>
<property value="owsm" name="provider.property.name"/>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.audit.AuditProvider" name="audit.provider" type="AUDIT">
<description>Audit Service</description>
</serviceProvider>
<serviceProvider class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider" name="ldap.credentialstore.provider" type="CREDENTIAL_STORE"/>
<serviceProvider class="oracle.security.jps.internal.policystore.ldap.LdapPolicyStoreProvider" name="ldap.policystore.provider" type="POLICY_STORE">
<property value="OID" name="policystore.type"/>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance location="./" provider="credstoressp" name="credstore">
<description>File Based Credential Store Service Instance</description>
</serviceInstance>
<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
<property value="oracle.security.jps.wls.internal.idstore.WlsLdapIdStoreConfigProvider" name="idstore.config.provider"/>
</serviceInstance>
<serviceInstance location="./system-jazn-data.xml" provider="idstore.xml.provider" name="idstore.xml">
<description>File Based Identity Store Service Instance</description>
<property value="jazn.com" name="subscriber.name"/>
</serviceInstance>
<serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml">
<description>File Based Policy Store Service Instance</description>
</serviceInstance>
<serviceInstance location="./default-keystore.jks" provider="keystore.provider" name="keystore">
<description>Default JPS Keystore Service</description>
<property value="JKS" name="keystore.type"/>
<property value="oracle.wsm.security" name="keystore.csf.map"/>
<property value="keystore-csf-key" name="keystore.pass.csf.key"/>
<property value="enc-csf-key" name="keystore.sig.csf.key"/>
<property value="enc-csf-key" name="keystore.enc.csf.key"/>
</serviceInstance>
<serviceInstance provider="audit.provider" name="audit">
<property value="None" name="audit.filterPreset"/>
<property value="104857600" name="audit.maxFileSize"/>
<property value="jdbc/AuditDB" name="audit.loader.jndi"/>
<property value="15" name="audit.loader.interval"/>
<property value="File" name="audit.loader.repositoryType"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="saml.loginmodule">
<description>SAML Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.saml.JpsSAMLLoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
<propertySetRef ref="saml.trusted.issuers.1"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="krb5.loginmodule">
<description>Kerberos Login Module</description>
<property value="com.sun.security.auth.module.Krb5LoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
<property value="true" name="storeKey"/>
<property value="true" name="useKeyTab"/>
<property value="true" name="doNotPrompt"/>
<property value="./krb5.keytab" name="keyTab"/>
<property value="HOST/localhost@EXAMPLE.COM" name="principal"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="digest.authenticator.loginmodule">
<description>Digest Authenticator Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.digest.DigestLoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="certificate.authenticator.loginmodule">
<description>X509 Certificate Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.x509.X509LoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="wss.digest.loginmodule">
<description>WSS Digest Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.digest.WSSDigestLoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="user.authentication.loginmodule">
<description>User Authentication Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.authentication.JpsUserAuthenticationLoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
</serviceInstance>
<serviceInstance provider="jaas.login.provider" name="user.assertion.loginmodule">
<description>User Assertion Login Module</description>
<property value="oracle.security.jps.internal.jaas.module.assertion.JpsUserAssertionLoginModule" name="loginModuleClassName"/>
<property value="REQUIRED" name="jaas.login.controlFlag"/>
</serviceInstance>
<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://myHost.com:1234" name="ldap.url"/>
</serviceInstance>
<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>
<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=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>
</serviceInstances>

<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="keystore"/>
<serviceInstanceRef ref="audit"/>
<serviceInstanceRef ref="credstore.ldap"/>
<serviceInstanceRef ref="policystore.ldap"/>
</jpsContext>
<jpsContext name="oracle.security.jps.fmw.authenticator.DigestAuthenticator">
<serviceInstanceRef ref="digest.authenticator.loginmodule"/>
</jpsContext>
<jpsContext name="X509CertificateAuthentication">
<serviceInstanceRef ref="certificate.authenticator.loginmodule"/>
</jpsContext>
<jpsContext name="SAML">
<serviceInstanceRef ref="saml.loginmodule"/>
</jpsContext>
<jpsContext name="bootstrap_credstore_context">
<serviceInstanceRef ref="bootstrap.cred"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

18.6 アサートされたユーザーとしての実行

多くの場合、アプリケーションは、ユーザーが操作を実行したようにアクションを実行する、つまり、実行操作を起動する必要があります。OPSSでは、アサートされたユーザーのサブジェクトを使用して、ユーザーが実行したようなアプリケーション・ロジックの実行をJava EEアプリケーションおよびJava SEアプリケーションに許可することにより、この問題を解決します。この機能は、OPSSクラスSubjectSecurityでカプセル化され、Oracle WebLogicプラットフォームでサポートされています。

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

- ユースケース

- プログラミングのガイドラインおよび推奨事項

- コード例

18.6.1 ユースケース

プログラミング課題の解決にSubjectSecurityクラスを使用できる例をいくつか次に示します。

- UC1 - スケジューラはジョブの送信と実行を可能にします。通常これらのジョブは一度に送信され何回かに分けて実行されるため、ユーザーのアイデンティティをアサートし、ユーザーのセキュリティ・コンテキストでスケジュールされたジョブを実行する必要があります。

- UC2 - スケジュールされたジョブはエンティティBeanにより実行され、さらに、ジョブを完了するためにその他のエンティティBeanをコールする場合があります。ジョブを完了するためのすべてのコードは、ユーザーのセキュリティ・コンテキストで実行する必要があるため、このコンテキストはパスをコールことにより、エンティティBean間で伝播される必要があります。

- UC3 - スケジュールされたジョブを実行するパーミッションは、ユーザーのアプリケーション・ロールに基づいています。この場合は、エンティティBean間のコード・パスにかかわらず、ユーザーのセキュリティ・コンテキストはユーザーに付与されたアプリケーション・ロールを認識する必要があります。

- UC4 - 認証されていないユーザーがジョブを送信する場合は、ジョブ・メタデータは匿名ユーザーを保持する必要があります。その結果、ジョブは匿名ユーザーにより実行される必要があります。

- UC5 - アプリケーションで実行するMBeanは、MBeanサーバー経由でUIから起動されます。MBean操作は、特定のユーザーとして実行する必要のある一連の診断テストを起動します。

- UC6 - ユーザー・アイデンティティはユーザー・アサーションAPIによりアサートされており、該当のユーザーとして操作を実行するために使用できるユーザーのセキュリティ・コンテキストを作成します。

18.6.2 プログラミングのガイドラインおよび推奨事項

SubjectSecurity APIにより、事前計算されたサブジェクトが使用可能な場合(ユースケースUC6と同じ)、またはユーザーが最初にアサートされる必要がある場合は、ユーザーはコードを実行できます。アプリケーションのセキュリティ・コンテキストが設定されていない場合は、SubjectSecurity APIを使用する前に、アプリケーションはアプリケーションのIDを次のように設定する必要があります。

AppSecurityContext.setApplicationID(applicationID)

たとえば、ユースケースUC1、UC2、UC3、およびUC5と同様のシステムMbeanの場合は、アプリケーションIDをsetApplicationIDに設定する必要があります。アプリケーションのセキュリティ・コンテキストが設定されている場合は、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)は、ユーザーのJAASサブジェクトおよびアプリケーションのPrivilegedActionを使用してSubject.doAs()を呼び出します。

- SubjectSecurity.executeAs(Subject subject, PrivilegedAction<T> action)を使用して、アクションを即時に実行します。

- SubjectSecurity.executeAs(Subject subject, PrivilegedExceptionAction<T> action)を使用して、アクションを即時に実行します。このメソッドは、getActionExecutor(subject)を使用してアクション・エグゼキュータを取得し、アクションを実行します。

18.6.3 コード例

次のサンプル・コードは、SubjectSecurity APIを使用し、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

}

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

この章の情報はJava SEアプリケーションにのみ適用され、Java SEアプリケーションの開発者を対象読者としています。

Java EEアプリケーションについての同様の情報は、第18章「OPSSを使用するためのJava EEアプリケーションの構成」を参照してください。

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

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

- 第19.2項「Java SEアプリケーションのセキュリティ・サービス」

- 第19.3項「Java SEアプリケーションでの認証」

- 第19.4項「構成例」

19.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ファイルへのファイル・パス。

その他の設定可能な(オプションの)システム・プロパティの詳細は、第F.1項「OPSSシステム・プロパティ」を参照してください。

- 次のサンプル・スニペットで示すように、アプリケーションは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コールには、次のようなコードソース・パーミッションが必要です。

<grant>
<grantee>
<codesource>
<url>myJavaSEapp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>AppSecurityContext.setApplicationID.myAppStripeID</name>
</permission>
</permissions>
</grant>

OPSSセキュリティ・ストアを構成する方法の詳細は、第9章「OPSSセキュリティ・ストアの構成」を参照してください。

19.2 Java SEアプリケーションのセキュリティ・サービス

この項では、Java SEアプリケーションのOPSSサポートについて、サービスごとに説明します。

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

- 第20章「認可サービスを使用した開発」

- 第21.6.1項「Java SEアプリケーションでのCSF APIの使用」

- 第24.5.1項「Java SEアプリケーションでのキーストア・サービスAPIの使用」

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

この項では、Java SEアプリケーションに対するアイデンティティ・ストアのサポートについて説明します。内容は次のとおりです。

- アイデンティティ・ストア

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

- ログイン・モジュール

- Java SEアプリケーションでのOPSS API LoginServiceの使用方法

19.3.1 アイデンティティ・ストア

認証とは、コール元が特定のユーザーまたはシステムの代理として機能していることを証明するメカニズムです。認証では、名前とパスワードの組合せなどのデータを使用して、相手がだれであるかという質問への回答が提供されます。アイデンティティ・ストアという用語はアイデンティティ・データの格納場所を表し、認証プロバイダはアイデンティティ・ストアにアクセスするための手段です。

アプリケーションによるOPSSセキュリティ・ストア(アイデンティティ・ストア、ポリシー・ストアまたは資格証明ストア)からの情報の取得と、そのコンテンツの管理には、OPSS APIが使用されます。次の図はこれを示したものです。

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

Java SEアプリケーションは、次のスニペットに示すように、<serviceProvider>、<serviceInstance>および<jpsContext>の各要素を含むファイルjps-config-jse.xmlに構成されたLDAPベースのアイデンティティ・ストアを使用できます。

<serviceProviders>
<serviceProvider type="IDENTITY_STORE" name="idstore.ldap.provider" class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider">
<description>Prototype LDAP-based 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「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。

19.3.3 ログイン・モジュール

ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。このプロセスは、2つの異なる段階で行われます。第一段階では、ログイン・モジュールによって要求元のユーザー(必要に応じて名前、パスワードまたはその他の資格証明データ)の認証が試みられます。第一段階が成功した場合にのみ、第二段階が呼び出されます。第二段階では、ログイン・モジュールによって、関連プリンシパルがサブジェクトに割り当てられ、最終的にそれが権限が付与されたアクションを実行するために使用されます。

サポートされる任意のログイン・モジュールで、次のプロパティを設定できます。

enable.anonymous (default: false)
remove.anonymous.role (default: true)
add.application.roles (default: true)
add.authenticated.role (default: true)

サンプル構成は、「<serviceInstance>」を参照してください。

サポートされるログイン・モジュールは、次のとおりです。

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

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

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

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

Java SEアプリケーションではログイン・モジュールのスタックを使用してユーザーを認証でき、各モジュールではスタック内の他のモジュールとは無関係に独自の計算を実行できます。これらのサービスおよびその他のサービスは、ファイルjps-config-jse.xmlで指定されます。

OPSS APIには、インタフェースoracle.security.jps.service.login.LoginServiceが組み込まれており、これによってJava SEアプリケーションはスタック内のすべてのログイン・モジュールを呼び出せるのみでなく、それらのサブセットを指定の順序で呼び出すことができます。

LoginServiceインタフェースのメソッドLoginContextに渡されるjpsコンテキスト(構成ファイルjps-config-jse.xmlに定義されたもの)の名前によって、アプリケーションが使用するログイン・モジュールのスタックが判別されます。標準のJAAS API LoginContextを使用して、デフォルトのコンテキストで定義されたログイン・モジュールを呼び出すこともできます。

JPSコンテキストによってスタックにログイン・モジュールがリストされる順序は重要です。それは、認証アルゴリズムでは、モジュールのセキュリティ・レベルを特定するフラグ(required、sufficient、requisite、optional)などのデータに加えてこの順序が考慮されるためです。

すぐに使用できるアイデンティティ・ストア・サービスはファイルベースであり、そのコンテンツはファイルsystem-jazn-data.xmlでプロビジョニングされています。そのサービスを再構成して、LDAPベースのアイデンティティ・ストアを使用することも可能です。

OPSSでは、Java SEアプリケーションのアイデンティティ・ストア・ログイン・モジュールがサポートされており、次の項の説明に従って、認証またはアイデンティティ・アサーションに使用できます。

- 認証のためのアイデンティティ・ストア・ログイン・モジュールの使用

- アサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用

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

このログイン・モジュールに関連付けられているクラスは、次のとおりです。

oracle.security.jps.internal.jaas.module.idstore.IdStoreLoginModule

このモジュールのインスタンスは、次のフラグメントに示すように、ファイル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>

このログイン・モジュールに固有のプロパティは、次のとおりです。

remove.anonymous.role (defaults to true)
add.application.role (defaults to true)

19.3.3.1.1 認証のためのアイデンティティ・ストア・ログイン・モジュールの使用

この項では、基本的なユーザー名とパスワードの認証のためのアイデンティティ・ストア・ログイン・モジュールの使用方法を示します。

IdStoreLoginModuleの起動

次のフラグメントは、コールバック・ハンドラとコンテキストの設定方法を示しています。

import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;

Subject sub = new Subject();
CallbackHandler cbh = new YourCallbackHandler();
LoginContext context = new LoginContext(appName, subject,  cbh);
context.login();

コールバック・ハンドラでは、NameCallbackとPasswordCallbackを処理できる必要があります。

jps-config-jse.xmlの構成

次のjps-config-jse.xmlの断片は、コンテキスト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.callback.*;
import java.io.IOException;
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);
}
}
}
}
}

19.3.3.1.2 アサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用

アイデンティティ・ストアのログイン・モジュールをアサーションのために使用するには、開発者は次の処理を行う必要があります。

- コール元が保護されたメソッドsetIdentityを実行するための適切なパーミッションを提供します。これには、IdentityAssertionという名前を持つパーミッションoracle.security.jps.JpsPermissionを付与することが必要になります。

- 次のコード・サンプルに示すようなクラスoracle.security.jps.callback.IdentityCallbackを使用するコールバック・ハンドラを実装します。

この2つの要件を次の構成およびコード・サンプルに示します。

JpsPermissionのプロビジョニング

次の構成サンプルでは、必須JpsPermissionがアサーション・ログイン・モジュールの保護されたメソッドを実行できるようにコード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>
</permissions>
</grant>

次の構成サンプルでは、必須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>
</permission>
</permissions>
</grant>

CallbackHandlerの実装

次のコード部分は、コールバック・ハンドラの実装を示しています。

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();
}
}
}

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

ユーザー認証のログイン・モジュールは、ユーザー名とパスワードからユーザーを認証するために、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();

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

ユーザー・アサーションのログイン・モジュールは、ユーザー・アイデンティティをアサートするために、Java EEアプリケーションとJava SEアプリケーションの両方で使用できます。このログイン・モジュールは、ドメイン・アイデンティティ・ストアに対してアサートを行い、コールバックoracle.security.jps.callback.IdentityCallbackの実装を必要とします。さらに、このログイン・モジュールの実行では、oracle.security.jps.JpsPermissionにIdentityAssertionパーミッション(アクションとして実行)が要求されます。

ユーザー・アサーションのログイン・モジュールをプログラムのアサーションのために使用するには、開発者は次の処理を行う必要があります。

- コール元がログイン・モジュールで保護されたメソッドを実行するための適切なパーミッションを提供します。これには、IdentityAssertion (およびアクション実行)という名前を持つパーミッションoracle.security.jps.JpsPermissionを付与することが必要になります。

- クラスoracle.security.jps.callback.IdentityCallbackを使用するコールバック・ハンドラを実装します。プログラムのアサーション・コードを実行します。

これらの要件を次の構成およびコード・サンプルに示します。

- jpsPermissionのプロビジョニング

- CallbackHandlerの実装

- プログラムのアサーションの実装

19.3.3.3.1 jpsPermissionのプロビジョニング

次の構成サンプルでは、必須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>

コードソースの例は、第18.5.6項「サポートされているパーミッション・クラス」の付与サンプルを参照してください。

19.3.3.3.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);
}
}
}
}

19.3.3.3.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();
}
});

19.3.4 Java SEアプリケーションでのOPSS API LoginServiceの使用方法

Java SEアプリケーションでログイン・モジュールをプログラムによって呼び出すには、インタフェースoracle.security.jps.service.login.LoginServiceのメソッドgetLoginContextを使用します。

標準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>

19.4 構成例

この項では、次のアーティファクトの構成を示します。

- XMLのポリシー・ストアおよび資格証明ストア

- XMLおよびLDAPのアイデンティティ・ストア

- ログイン・モジュールのプリンシパル

XMLのポリシー・ストアおよび資格証明ストアの構成

次のスニペットは、XMLベースのポリシー・ストアおよび資格証明ストアの構成を示しています。XMLベースのポリシー・ストアのコンテンツは、ファイルsystem-jazn-data.xmlに指定されています。XMLベースの資格証明ストアのコンテンツは、ファイルcwallet.ssoに指定されています。

<serviceProviders> <serviceProvider class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider" name="policystore.xml.provider" type="POLICY_STORE">
<description>XML-based PolicyStore Provider</description>
</serviceProvider>

<serviceProvider class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider" name="credstoressp" type="CREDENTIAL_STORE">
<description>SecretStore-based CSF Provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance location="./" provider="credstoressp" name="credstore">
<description>File-based Credential Store Service Instance</description>
</serviceInstance>

<serviceInstance location="./system-jazn-data.xml" provider="policystore.xml.provider" name="policystore.xml">
<description>File-based Policy Store Service Instance</description>
</serviceInstance>
</serviceInstances>

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

次のスニペットは、XMLベースのアイデンティティ・ストアの構成を示しています。XMLベースのアイデンティティ・ストアのコンテンツは、ファイルsystem-jazn-data.xmlに指定されています。

<serviceProvider
class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider"
name="idstore.xml.provider"
type="IDENTITY_STORE">
<description>XML-based Identity Store Service Provider</description>
</serviceProvider>

<serviceInstance
location="./system-jazn-data.xml" provider="idstore.xml.provider"
name="idstore.xml">
<description>File Based Identity Store Service Instance</description>
<property value="jazn.com" name="subscriber.name"/>
</serviceInstance>

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

次のスニペットは、LDAPベースのアイデンティティ・ストアの構成を示しています。このアイデンティティ・ストアには、LDAPサーバーにアクセスするためのブートストラップ資格証明の必須構成が含まれています。サービス・インスタンス・プロパティidstore.typeでは、使用するLDAPに応じて、次の値を設定できます。

表19-1 Idstoreのタイプ

サポートされているLDAP

Idstore.typeの値

Oracle Internet Directory 10gおよび11g

OID

Oracle Virtual Directory 10gおよび11g

OVD

Sun Java System Directory Server 6.3

IPLANET

Active Directory 2003、2008

ACTIVE_DIRECTORY

Novell eDirectory 8.8

EDIRECTORY

Oracle Directory Server Enterprise Edition 11gR1 (11.1.1.3+)

IPLANET

IBM Tivoli DS 6.2

OPEN_LDAP

OpenLDAP 2.2。

OPEN_LDAP

<serviceProvider
class="oracle.security.jps.internal.idstore.ldap.LdapIdentityStoreProvider"
name="idstore.ldap.provider" type="IDENTITY_STORE">
<description>LDAP-based Identity Store Service Provider</description>
</serviceProvider>

<serviceProvider
class="oracle.security.jps.internal.credstore.ssp.SspCredentialStoreProvider"
name="credstoressp" type="CREDENTIAL_STORE">
<description>SecretStore-based CSF Provider</description>
</serviceProvider>

<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 value=ldap://myOID.com:3555 name="ldap.url"/>
<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"/>
<propperty name="group.attr" value="cn"/>
</serviceInstance>

<serviceInstance location="./bootstrap" provider="credstoressp"
name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>

ログイン・モジュールのプリンシパル

出荷時のjps-config-jse.xmlには、次のプロパティが設定されています。

<property name="oracle.security.jps.enterprise.user.class"
value="weblogic.security.principal.WLSUserImpl"/>

<property name="oracle.security.jps.enterprise.role.class"
value="weblogic.security.principal.WLSGroupImpl"/>

どのようなログイン・モジュールでも、前述のプロパティを使用する必要があります。これは、アイデンティティ・ストア内のユーザーおよびグループを表すプリンシパルが、次のとおりであることを意味しています。

weblogic.security.principal.WLSUserImpl
weblogic.security.principal.WLSGroupImpl

20 認可サービスを使用した開発

この章では、Java SEアプリケーションでOPSS認可を使用する方法を説明するとともに、サポートされていない一部のメソッドについて示します。

これらについては次の項で説明します。

- 第20.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストア」

- 第20.2項「ファイルベースのポリシー・ストアに対してサポートされていないメソッド」

Java SEアプリケーション用のその他のOPSSサービスの詳細は、第19.2項「Java SEアプリケーションのセキュリティ・サービス」を参照してください。

20.1 Java SEアプリケーションでのポリシー・ストアと資格証明ストア

Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成について、次の各項で説明します。

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

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

- DBベースのOPSSセキュリティ・ストアの構成

Java SEアプリケーションで認可が機能するためには、システム・プロパティを適切に設定しておく必要があります。すべてのプロパティのリストは、第F.1項「OPSSシステム・プロパティ」を参照してください。

Java SEアプリケーションでは、ファイルベース、LDAPベースまたはDBベースのストア・プロバイダを使用できます。これらのサービスはアプリケーション・ファイルjps-config-jse.xmlで構成します。

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

ファイルベースのポリシー・ストアはファイルsystem-jazn-data.xmlで指定し、ファイルベースの資格証明ストアはファイルcwallet.ssoで指定します(このウォレット・ファイルを、同じ名前のブートストラップ・ファイルcwallet.ssoと混同しないようにしてください。このブートストラップ・ファイルには、アプリケーション・セキュリティがLDAPベースの場合にLDAPストアにアクセスするための資格証明が格納されています)。

ウォレットの詳細は、第18.5.3項「ウォレットベースの資格証明ストアの使用」を参照してください。ブートストラップ資格証明の変更または追加の詳細は、「modifyBootStrapCredential」および「addBootStrapCredential」を参照してください。

次のコードは、ファイルベースのポリシー・ストアと資格証明ストアおよびそれらを参照するjpsContextの構成を示しています。

<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-based Credential Store Service Instance</description>
</serviceInstance>

<serviceInstance name="policystore.xml" provider="policystore.xml.provider" location="./system-jazn-data.xml">
<description>File-based 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に設定する必要がある点に留意してください。

20.1.2 LDAPベースのポリシー・ストアおよび資格証明ストアの構成

この項では、LDAPベースのストアをポリシー・ストアおよび資格証明ストアとして使用するように設定していることが前提となっています。Oracle Internet Directoryでのノードの設定の詳細は、第9.2.1項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

次のコードは、Java SEアプリケーションで使用するLDAPベースのポリシー・ストアおよび資格証明ストアのプロバイダおよびインスタンスの構成を示しています。

<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>

次のコードは、プログラムからLDAPサーバーにアクセスできるようにするためのブートストラップ資格証明ファイル(cwallet.sso)の構成を示しています。

<serviceInstance location="./bootstrap" provider="credstoressp" name="bootstrap.cred">
<property value="./bootstrap" name="location"/>
</serviceInstance>

次のコードは、前述のインスタンスを参照するために必要なjpsContextsの構成を示しています。

<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>

次のコードは、上記で構成したLDAPベースのポリシー・ストアへの参照をプログラム的に取得する方法を示しています。ここでは、システム・プロパティ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
...

20.1.3 DBベースのOPSSセキュリティ・ストアの構成

この項では、DBベースのストアをOPSSセキュリティ・ストアとして使用するように設定していることが前提となっています。DBでのノードの設定の詳細は、第9.3.1項「DBベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

この後に示す構成サンプルでは、次の重要事項に留意してください。

- 構成プロパティjdbc.urlの値は、データ・ソース作成時に入力されたJDBCデータ・ソースの名前と同じにする必要があります。

- ブートストラップ資格証明(マップとキー)の値は、ブートストラップ資格証明の作成時にWLSTコマンドaddBootStrapCredentialに渡したものと一致させる必要があります。

次のコードは、ファイルjps-config-jse.xmlにおけるDBベースのポリシー・ストア、資格証明ストアおよびキーストアの構成を示しています。

<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>

20.2 ファイルベースのポリシー・ストアに対してサポートされていないメソッド

このリリースでは、ファイルベースのポリシー・ストアに対して、次の機能に関連するメソッドはサポートされていません。

- 複雑な問合せ

- カスケード削除

複雑な問合せは、問合せを実行するすべてのメソッドに関連します。ポリシー・ストアがファイルベースの場合、問合せは単純であることが必要です。ファイルベースのポリシー・ストアを使用している場合に、問合せを実行するメソッドに複雑な問合せを渡すとそのメソッドは例外をスローします。

単純な問合せとは、検索条件が1つのみの問合せであり、複雑な問合せとは、複数の検索条件を持つ問合せです。addQueryをコールするたびに問合せには条件が1つ追加されます。

次のコードは、表示名が文字列MyDisplayNameに一致するすべてのパーミッションを返す単純な問合せの構造を示しています。

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.DISPLAY_NAME,
false,
ComparatorType.EQUALITY,
"MyDisplayName",
BaseSearchQuery.MATCHER.EXACT);
getPermissionSets(query);

次の例は、指定したリソース・タイプおよび指定したリソース・インスタンス名を持つすべてのパーミッション・セットを返す複雑な問合せの構造を示しています。

PermissionSetSearchQuery query = new PermissionSetSearchQuery();
query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.RESOURCE_TYPE,
false,
ComparatorType.EQUALITY,
"MyResourceType",
BaseSearchQuery.MATCHER.EXACT);

query.addQuery(PermissionSetSearchQuery.SEARCH_PROPERTY.RESOURCE_NAME,
false,
ComparatorType.EQUALITY,
"MyResourceInstanceName",
BaseSearchQuery.MATCHER.EXACT);

query.setANDMatch();
getPermissionSets(query);

カスケード削除は、ブール型引数cascadeDeleteを使用するメソッドに関連します。ポリシー・ストアがファイルベースの場合にこの引数に指定できる唯一の値は、FALSEです。インタフェースResourceTypeManagerでのこのようなメソッドの例を次に示します。

void deleteResourceType(EntryReference rtRef, boolean cascadeDelete)
throws PolicyObjectNotFoundException,
PolicyStoreOperationNotAllowedException,
PolicyStoreException

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

この章の次の各項では、資格証明ストア・フレームワーク(CSF)のAPIの使用方法について説明します。

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

- CSFを使用したアプリケーション開発の概要

- Javaセキュリティ・ポリシーのパーミッションの設定

- マップ名のガイドライン

- 資格証明ストアの構成

- CSF APIの使用

- 例

- ベスト・プラクティス

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

資格証明ストアは、資格証明のセキュアな保存のために使用します。資格証明ストア・フレームワーク(CSF) APIは、資格証明ストアの操作へのアクセスと実行に使用します。

資格証明ストア・フレームワークには、次の機能があります。

- 資格証明の安全な管理を可能にします。

- 各種バックエンド・リポジトリでの資格証明の格納、取得および管理のためのAPIを提供します。

- ファイルベース(Oracleウォレット)およびLDAPベースの資格証明管理をサポートします。

CSF APIは、次のような重要な機能(作成、更新、削除)を提供します。

- 資格証明マップ(特定のキーを持つ資格証明)がストア内に存在するかどうかを確認します。

- <mapname, key>に関連付けられた資格証明を返します。

- 資格証明を<mapname, key>に割り当てます。

- 特定のマップ名、または特定のマップ名とキーに関連付けられた資格証明を削除します。

- 指定された<mapname, key>の資格証明をリセットします。

CredentialStoreに対する操作は、CSFで使用されるファイングレイン・アクセス制御モデルを実装するCredentialAccessPermissionによって保護されます。

関連項目:

- 第11章「資格証明ストアの管理」

21.2 CSFを使用したアプリケーション開発の概要

次の領域に関する知識は、アプリケーションで資格証明ストア・フレームワークを使用する場合に役立ちます。

- 使用する適切なマップ名とキー名の決定。これは、複数のアプリケーションが資格証明を共通の資格証明ストアに格納する環境では非常に重要です。

- Javaセキュリティ・ポリシーのプロビジョニング。
ポリシー・パーミッションは、ファイルベース(system-jazn-data.xml)またはLDAPベースのポリシー・ストアに設定されます。データのセキュリティを損なわずにアプリケーションの使用を可能にする適切なパーミッションを設定するには、十分な配慮が必要です。

関連項目:

第10.1項「ポリシー・ストアの管理」

- jps-config.xmlでの資格証明ストア・インスタンスの定義方法。
jps-config.xmlでのサービス・インスタンスの定義は、構成ファイルをマニュアルで作成する場合のみ必要です。

注意:

デフォルトでは、ファイルベースのプロバイダが構成されており、これはLDAPベースのプロバイダに変更することができます。第9.6項「OPSSセキュリティ・ストアの移行」を参照してください。

- 環境設定の手順。
これらの手順はアプリケーションのタイプがJava SEアプリケーションかJava EEアプリケーションかによって異なります。

この章の次の各項で、アプリケーションのタイプごとに設定の詳細を説明します。

21.3 Javaセキュリティ・ポリシーのパーミッションの設定

Oracle Platform Security Servicesのポリシー・プロバイダは、サーバーの起動時に設定されます。プロバイダがファイルベースの場合、ポリシー・データはsystem-jazn-data.xmlに格納されます。

CSFは、資格証明の保護を次のようにサポートしています。

- マップ・レベルでの保護、または

- 特定の<mapname, key>に対するきめ細かな保護

注意:

- CSF APIに適切にアクセスするには、ポリシー・ストアにJavaパーミッションを付与する必要があります。

- CSF APIを呼び出すコードには、コード・ソースのパーミッションが必要です。パーミッションは通常、特定のコードjarに与えられるものであり、アプリケーション全体には与えられません。

21.3.1 パーミッション付与のガイドライン

資格証明ストア・フレームワークでは、Javaパーミッションに基づいて、資格証明ストアのオブジェクトにパーミッションを付与します。

必要なパーミッションのみを付与して、それ以外は付与しないことを強くお薦めします。

警告:

不要なパーミッション、特にすべてのマップやキーにアクセスできるパーミッションを付与することは危険であり、お薦めできません。

21.3.2 パーミッション付与例1

注意:

この例では、アプリケーションのjarファイル名はAppName.jarです。

CredentialStoreは、マップ名と資格証明マップ間のマッピングを保持します。各マップ名は、CredentialオブジェクトのキーのセキュアなマップであるCredentialMapにマップされます。

この例では、特定のマップ名と、そのマップの特定のキー名に対してパーミッションを付与しています。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<!-- This is the location of the jar -->
<!-- as loaded with the run-time -->
<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>
<!-- All actions are granted -->
<actions>*</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

説明:

- MapNameは、これらのパーミッション(ワイルドカード・アクションで示した読取り、書込み、更新および削除)を付与するマップの名前(通常はアプリケーション名)です。

- KeyNameは、使用するキー名です。

21.3.3 パーミッション付与例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>
<!-- Certain actions are explicitly specified -->
<!-- Compare to wild-card grant in previous example -->
<actions>read,write,update,delete</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

21.4 マップ名のガイドライン

ドメインレベルの資格証明ストアが使用される場合は、ストア内に異なるアプリケーション用の様々なマップ名が存在していることから、名前の競合が発生する場合があります。これを避けるために、各アプリケーションはストア内で一意なマップ名を持つ必要があります。

そのためには、使用するマップ名でアプリケーションが一意に識別されるようにすることをお薦めします。

アプリケーションは、特定のマップ名の中に、それぞれが特定のキーで識別される複数の資格証明を持つことができます。このマップ名とキーの組合せが、特定の資格証明ストア内の主キーになります。

アプリケーションで複数のマップ名を使用する必要が生じた場合でも、その一意性は維持されます。

たとえば、次の3つのアプリケーションを考えます。

- リポジトリ作成ユーティリティ(RCU)ベースのアプリケーション

- Oracle WebCenterアプリケーション

- Fusion Middleware Controlアプリケーション

RCUの場合は、RCUというマップ名が選択され、3つの資格証明のキーが次のようにKey1、Key2、Key3になっています。

注意:

ここで使用しているマップ名とキー名は任意であり、説明用に選択したものにすぎません。ユーザーのアプリケーションでは、まったく異なるマップ名とキー名が使用できます。

MapName -> RCU, Key -> Key1 and Credential -> PasswordCredential1
MapName -> RCU, Key -> Key2 and Credential -> PasswordCredential2
MapName -> RCU, Key -> Key3 and Credential -> GenericCredential1

Oracle WebCenterの場合は、マップ名がWebで、単一の資格証明のキーはKey1です。

MapName -> Web, Key -> Key1 and Credential -> PasswordCredential3

Fusion Middleware Controlでは、マップ名はEMで示され、2つの資格証明のキーは、それぞれKey1とKey2です。

MapName -> EM, Key -> Key1 and Credential -> PasswordCredential4
MapName -> EM, Key -> Key2 and Credential -> GenericCredential2

マップ名とキー名は、2つの任意の文字列にすぎないため、実際には任意の有効な文字列値を持つことができます。ただし、このように実装することにより、マップ名を容易に管理することができます。

21.5 資格証明ストアの構成

管理者は、資格証明ストアの場所とプロバイダ・クラスに関する情報が含まれている構成ファイル内で、資格証明ストア・インスタンスを定義する必要があります。構成ファイルは、次の場所にあります。

$DOMAIN_HOME/config/fmwconfig

名前は次のとおりです。

- jps-config.xml (Oracle WebLogic Serverの場合)

- jps-config-jse.xml (Java SEの場合)

詳細は、第11章「資格証明ストアの管理」を参照してください。

関連項目:

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

21.6 CSF APIの使用

資格証明ストア・フレームワークは、Oracle WebLogic Server内でもスタンドアロン環境でも使用できます。

- Java SEアプリケーションでのCSF APIの使用

- Java EEアプリケーションでのCSF APIの使用

21.6.1 Java SEアプリケーションでのCSF APIの使用

関連項目:

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

Java SEアプリケーションでCSF APIを使用するには、次の手順を実行します。

1. クラスパスを設定します。jps-manifest.jarファイルがそのクラスパスに入っていることを確認します。詳細は、第1.5.3項「シナリオ3: Java SEアプリケーションの保護」の「クラスパスで指定する必要のあるJAR」を参照してください。

2. ポリシーを設定します。CSF APIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第21.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. JVMコマンドライン・オプションを設定します。詳細は、次を参照してください。

4. アプリケーションを実行します。

コマンドライン・オプションは次のとおりです。

- -Doracle.security.jps.config

構成ファイルjps-config.xmlへのフル・パスを指定します。通常、domain_home/config/fmwconfigディレクトリに存在します。

- -Djava.security.policy

OPSS/Oracle WebLogic Serverポリシー・ファイルweblogic.policyの場所を指定します。通常、wl_home/server/libディレクトリに存在します。

- -Dcommon.components.home

Middlewareホームの下にあるoracle_commonディレクトリの場所を指定します。

- -Djrf.version

環境で使用されるバージョンの値、11.1.1を指定します。

- -Djava.security.debug=all

デバッグに役立ちます。

21.6.2 Java EEアプリケーションでのCSF APIの使用

Java EEアプリケーションでCSF APIを使用するには、次の手順を実行します。

1. jps-config.xmlファイルの資格証明ストアのサービス・プロバイダ・セクションは、次のディレクトリにすぐに使用できるように構成されています。

$DOMAIN_HOME/config/fmwconfig

必要に応じて、LDAP資格証明ストアへの再関連付けを行ってください。

2. ポリシーを設定します。CSF APIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第21.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. Oracle WebLogic Serverを起動します。

4. アプリケーションをデプロイしてテストします。

21.7 例

この項では、資格証明ストア・フレームワークAPIの使用を示すいくつかのコード・サンプルについて説明します。各コード・サンプルは、資格証明ストア操作がパーミッションから受ける影響を示しており、構成ファイルのサンプルも含まれます。

関連項目:

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

この項では、次のサンプルについて説明します。

- CSF操作の共通コード

- 例1: ウォレット・ストアを使用するJava SEアプリケーション

- 例2: ウォレット・ストアを使用するJava EEアプリケーション

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

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

21.7.1 CSF操作の共通コード

次のユーティリティ・プログラムはCSF 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 since 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 since 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. Either 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();
}

/*
* Since this method performs a privileged operation, only current class or
* jar containing this class needs CredentialAccessPermission
*/
public void doPrivilegedCredOperation() {
AccessController.doPrivileged(new PrivilegedAction<String>() {
public String run() {
doOperation();
return "done";
}
});
}
}

21.7.2 例1: ウォレット・ストアを使用するJava SEアプリケーション

この例では、ウォレット資格証明(つまりファイルベースのプロバイダ)を使用するサンプルJava SEアプリケーションを示します。

関連項目:

第19.1項「Java SEアプリケーションでのOPSSの使用」のOPSSを使用したJava SEアプリケーションの保護の詳細。

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

- xmlベースのポリシー・ストア(jazn-data-xml)でのパーミッションの設定方法

- 構成ファイルの設定方法

- Java SEコード

jazn-data.xmlファイル

この例では、ストアから特定の資格証明へのアクセスに必要とされる適切なパーミッションを持つxmlベースのポリシー・ストアを使用して説明しています。このファイルでは、マップ名(別名)とキーの様々な組合せに対するパーミッションを定義します。他の組合せや、ここで定義されたパーミッションを超えたストアへのアクセスは、許可されません。

注意:

この権限付与が追加されるデフォルトのポリシー・ストアは$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlです。

ここでは、システム・プロパティ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にはどのようなパーミッションも付与されていないので、第21.7.1項「CSF操作の共通コード」に示したこのマップとキーの組合せに対するsetCredentialのコールは失敗すると考えられます。

jps-config-jse.xmlファイル

注意:

完全な構成ファイルについては、製品に付属しているデフォルトのファイル($DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml)を参照してください。

資格証明ストア・サービスの場所プロパティは、ウォレット・ファイルを格納しているディレクトリを示しています。

<jpsConfig>
...
<serviceInstances>
<serviceInstance name="credstore_file_instance"
provider="credstore_file_provider">
<property name="location" value="store" />
</serviceInstance>
</serviceInstances>
...
</jpsConfig>

注意:

場所のデフォルト値は./です。つまり、jps-config-jse.xmlの場所を基準とする相対パスでの現行のディレクトリです。別のパスを使用する場合は、必ずフルパスを指定してください。

ウォレット名は常にcwallet.ssoであり、これはデフォルトのファイルベースのOracleウォレットです。

Javaコード

次に、ユーティリティ・プログラムをコールする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);
// #1 - this call is in a doPrivileged block
// #1 - this should succeed.
csf.doPrivilegedCredOperation();

// #2 - this will also pass since granted all application
// code necessary permission
// NOTE: Since this call is not in a doPrivileged block,
// this call would have failed if CredentialAccessPermission
// wasn't granted to this class.
/*
csf.doCredOperation();
*/
} catch (JpsException e) {
e.printStackTrace();
}

}
}

注意:

- JDK全体に及ぶポリシー・オブジェクトを置き換える必要はありません。この付与例は、OPSS XMLポリシー・ストアに従っているので、ポリシー・プロバイダをOPSSプロバイダに設定することが妥当です。

- サポートされるアプリケーション・サーバーのJava EE環境では、OPSSポリシー・プロバイダが初期化されています。

21.7.3 例2: ウォレット・ストアを使用するJava EEアプリケーション

この例では、ウォレットの資格証明を使用するサンプルJava EEアプリケーションを示します。シンプルなサーブレットがCSF APIをコールしています。

jazn-data.xmlファイル

この例の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>

最初のマップおよびキーのパーミッションでは読取り操作と書込み操作の両方が有効になりますが、2番目のパーミッションでは書込み操作のみが有効になり、読取り操作は有効にならないことに注意してください。

jps-config.xmlファイル

資格証明ストアの構成を示すデフォルトの構成ファイルjps-config.xmlの一部を次に示します。

<jpsConfig>
<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>
</jpsConfig>

locationプロパティはウォレットの場所を指定します。この指定は本質的には例1と同じですが、この例ではウォレットが構成ディレクトリ内に配置されている点が異なります。ウォレット名は常にcwallet.ssoです。

Javaコード

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>");

//This is to get hold of app-level CSF service store
//Outside app context, this call returns domain-level CSF store
//This call also works in Java SE env
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環境に関する注意

Java SE環境では、次の2つのコールは同等です。

CredentialStore store = JpsServiceLocator.getServiceLocator().lookup(CredentialStore.class);

および

CredentialStore store = JpsContextFactory.getContextFactory().getContext().getServiceInstance(CredentialStore.class);

後者のコールは、第21.7.2項「例1: ウォレット・ストアを使用するJava SEアプリケーション」で紹介しています。

21.7.4 例3: OID LDAPストアを使用するJava EEアプリケーション

この例では、例2: ウォレット・ストアを使用するJava EEアプリケーションで使用されるJava EEアプリケーションと同じものを使用します(唯一の違いは、次の例では、資格証明ストアがファイルベース(ウォレット)ではなくLDAPベースであることです)。

ドメインのjps-config.xmlは、次のプロパティを構成する必要があります。

- ルート名:

<property name="oracle.security.jps.ldap.root.name" value="cn=OracleJpsContainer"/>

- ファーム名:

<property name="oracle.security.jps.farm.name" value="cn=OracleFarmContainer" />

- LDAPのURL:

<property name="ldap.url" value="ldap://mynode.us.mycorp.com:1234"/>

- (前述の必須のプロパティとともに)LDAPストアにアクセスするための資格証明を見つけるために使用されるプリンシパル・キー:

<property name="bootstrap.security.principal.key" value="bootstrap"/>

次に、OID LDAPベースのストアに必須のプロパティを指定するjps-config.xmlファイルの例を示します。

<jpsConfig>
<serviceProviders>
<serviceProvider name="ldap.credentialstore.provider"
class="oracle.security.jps.internal.credstore.ldap.LdapCredentialStoreProvider">
<description>Prototype LDAP-based 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>
</jpsConfig>

21.7.5 例4: Oracle DBストアを使用するJava EEアプリケーション

この例では、例2: ウォレット・ストアを使用するJava EEアプリケーションのJava EEアプリケーションと同じものを使用します。唯一の違いは、次の例では、資格証明ストアがファイルベース(ウォレット)ではなくDBベースであることです。

ドメインのjps-config.xmlファイルで、次のプロパティを構成する必要があります。

- ルート名:

<property name="oracle.security.jps.ldap.root.name"
value="cn=OracleJpsContainer"/>

- ファーム名:

<property name="oracle.security.jps.farm.name"
value="cn=OracleFarmContainer"/>

- JDBCのURL:

<property name="jdbc.url" value="jdbc:oracle:thin:@<host>:<port>:<service>"/>

- JDBCドライバ:

<property name="jdbc.driver" value="oracle.jdbc.OracleDriver"/>

- データソースのJNDI名:

<property name="datasource.jndi.name" value="jdbc/OpssDS"/>

- (前述の必須のプロパティとともに)DBストアにアクセスするための資格証明を見つけるために使用されるプリンシパル・キー:

<property value="bootstrap" name="bootstrap.security.principal.key"/>

次に、DBベースのストアに必須のプロパティを指定するjps-config.xmlファイルの例を示します。

<jpsConfig>
<serviceProviders>
<serviceProvider type="CREDENTIAL_STORE" name="db.credentialstore.provider" class="oracle.security.jps.internal.credstore.rdbms.DbmsCredentialStoreProvider"/>
<description>DB-based 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>
</jpsConfig>

21.8 ベスト・プラクティス

クラスタ環境でストアがファイルベースの場合は、資格証明ストア・フレームワークAPI上で資格証明ストアMbean APIを使用して、アプリケーションの資格証明の作成、取得、更新および削除を行います。

ただし、単に資格証明を読み取るだけの場合は、いずれのAPIも使用できます。

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

この章では、ユーザーおよびロールAPIを使用してアイデンティティ情報にアクセスする方法を説明します。

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

- 第22.1項「ユーザーおよびロールAPIフレームワークの概要」

- 第22.2項「ロールとクラスの要約」

- 第22.3項「サービス・プロバイダの操作」

- 第22.4項「リポジトリの検索」

- 第22.5項「ユーザー認証」

- 第22.6項「アイデンティティ・ストアのエントリの作成と変更」

- 第22.7項「ユーザーおよびロールAPIの使用例」

- 第22.8項「LDAPベースのユーザーおよびロールAPIプロバイダのSSL構成」

- 第22.9項「ユーザーおよびロールAPIリファレンス」

- 第22.10項「カスタムのユーザーおよびロール・プロバイダの開発」

注意:

ユーザーおよびロールAPIは現在非推奨となっており、今後のリリースでは廃止される可能性があります。新しいアプリケーションの開発にはIdentity Governance Frameworkを使用してください。今後のリリースで既存のアプリケーションをIdentity Governance Frameworkに移行することを計画してください。

詳細は、『Identity Governance Framework開発者ガイド』を参照してください。

関連項目:

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

22.1 ユーザーおよびロールAPIフレームワークの概要

ユーザーおよびロールAPIフレームワークを使用すると、アプリケーションは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報(ユーザーとロール)にアクセスすることができます。このリポジトリとして、Oracle Internet Directory、Active Directory (Microsoft社)、Oracle Directory Server Enterprise EditionなどのLDAPディレクトリ・サーバーや、データベース、フラット・ファイルなどのカスタム・リポジトリを使用できます。

このAPIフレームワークには、移植可能な方法でプログラム的にリポジトリにアクセスするための便利な方法が用意されているため、アプリケーション開発者は、個々のアイデンティティ・ソースに対応した複雑な処理を考慮するという煩雑な作業から解放されます。このフレームワークにより、アプリケーションは異なるリポジトリをシームレスに操作できるようになります。アプリケーションは、コードを変更しなくても、各種のアイデンティティ・リポジトリを切り替えて使用することができます。

サポートされる操作には、ユーザーとロールの作成、更新、削除のほか、ユーザーおよびロールの属性や特定の情報の検索などがあります。たとえば、特定のロールのすべてのユーザーの電子メール・アドレスを検索できます。

注意:

これらのAPIは、認証機能または認可機能を対象としたものではなく、アイデンティティ情報の保持を目的としています。

基本使用モデル(コンテナ統合を使用しない)またはコンテナ統合を使用するモデル(コードの移植が可能)を使用できます。

Oracle WebLogic Serverコンテナのコンテキストの実行を目的としているアプリケーションでは、weblogic.security.principal.WLSUserImplにプリンシパル・クラスをキャストする必要があります。

注意:

Oracle WebLogic ServerコンテナのコンテキストでユーザーおよびロールAPIを起動するには、次が必要です。

- アイデンティティ・ストアがLDAPベースであること

- ドメイン管理サーバーが稼働していること

ユーザーおよびロールAPIを使用する際の注意

一般的に、認証はユーザーおよびロールAPIで実行せず、認証プロバイダでのみ実行する必要があります。

また、書込み権限のないユーザーの接続DNで認証プロバイダを構成することをお薦めします。

22.1.1 ユーザーおよびロールAPIとOracle WebLogic Serverの認証プロバイダ

ユーザーおよびロールAPIは、最初のOracle WebLogic Server認証プロバイダを使用するように自動的に構成されるため、特別な構成は必要ありません。

ただし、ユーザーおよびロールAPIがその他の認証プロバイダを使用する場合は構成が必要です。

APIは、Oracle WebLogic Serverドメインにリストされている最初のLDAP認証プロバイダからのみデータにアクセスできます。複数の認証プロバイダが存在する場合は、各プロバイダの制御フラグの優先度によって優先順位が決まります。優先度が同じ場合は、最初のプロバイダが選択されます。リスト上で最初の認証プロバイダの下位にあるLDAP認証プロバイダにはアクセスしません。

WebLogic APIの同時使用について

アプリケーションでのLDAPサーバーのエントリの操作に、ユーザーおよびロールAPIとWebLogic LDAPAuthenticator API (EmbeddedLDAPAuthenticator、OracleInternetDirectoryAuthenticator、OracleVirturalDirectoryAuthenticatorなど)の両方を同時に使用しないでください。その理由を理解するには、同じLDAPサーバーにアクセスする2つのLDAPクライアントについて考えます。これらのクライアントはどちらもキャッシュが有効に設定されており、一方はエントリを削除しようとし、もう一方は削除対象のエントリを使用しようとしているとします。

この2つのクライアントが引き起こす競合を解決するには、キャッシュ機能を無効にし、クライアント間でLDAP操作を調整する必要があります。

22.2 ロールとクラスの要約

表22-1は、ユーザーおよびロールAPIのクラスとインタフェースを示しています。

表22-1 ユーザーおよびロールAPIのクラスとインタフェース

名前

タイプ

説明

AuthenticationException

クラス

アイデンティティ・ストアへのアクセス中に認証エラーが発生すると、この例外がスローされます。認証エラーは、ユーザー・プログラムで指定された資格証明が無効な場合や、該当アイデンティティ・ストアでユーザーを認証できなかったときなどに発生する場合があります。

AuthenticationWarningException

クラス

このクラスは、IMException(次の説明を参照)を拡張したものです。

ComplexSearchFilter

インタフェース

複合検索フィルタは、基礎となるアイデンティティ・リポジトリから得られる結果のフィルタ処理に使用できる、複合的な論理式を表します。複合検索フィルタは、複数のSearchFilterインスタンスを1つの論理演算子(ANDまたはOR)で組合したものです。コンポーネントとなる各SearchFilter自体を複合フィルタにできるため、複雑なネストした検索フィルタの作成が可能です。

複合検索フィルタの作成例については、Javadoc(第22.9項「ユーザーおよびロールAPIリファレンス」)を参照してください。

ConfigurationException

クラス

この例外は、構成に問題がある場合にスローされます。この例外は、サービス・プロバイダへのアクセスに必要な構成情報が不正であるか、見つからないときに発生する場合があります。

Identity

インタフェース

このインタフェースは、アイデンティティ・リポジトリ内の基本的なアイデンティティを表します。

IdentityStore

インタフェース

IdentityStoreは、実際のアイデンティティ・リポジトリへのハンドルを表します。このハンドルを使用して、リポジトリ内のアイデンティティを検索、作成、削除または変更することができます。

IdentityStoreFactory

インタフェース

IdentityStoreFactoryは、基礎となるアイデンティティ・リポジトリをプログラム的に表したものです。アイデンティティ・リポジトリへの実際のハンドルは、このオブジェクトのgetIdentityStoreInstance(Hashtable)をコールすることによって取得できます。

IdentityStoreFactoryBuilder

クラス

このクラスは、アイデンティティ・ストア・ファクトリを構築します。

IMException

クラス

この例外は、ADFのアイデンティティ管理APIによってスローされるすべての例外のスーパークラスです。サブクラスの名前が障害の性質を示します。

既知の直接サブクラスのリストについては、Javadoc(第22.9項「ユーザーおよびロールAPIリファレンス」)を参照してください。

ModProperty

クラス

このクラスは、プロパティ・オブジェクトの変更を表します。ModPropertyは、プロパティ名、変更後の値(複数指定可能)および変更のタイプとともにコールされます。変更のタイプは、ADD、REMOVE、REPLACEのいずれかです。

NoPermissionException

クラス

この例外は、APIコール元がパーミッションを持たない操作を実行しようとしたときにスローされます。アクセス制御とパーミッションのモデルは、基礎となるアイデンティティ・ストアによって規定されます。

ObjectExistsException

クラス

この例外は、指定された名前のアイデンティティがすでに基礎となるアイデンティティ・ストアに存在している場合にスローされます。たとえば、この例外は、ユーザー作成APIコールが既存のユーザーの名前でユーザーを作成しようとするときにスローされます。

ObjectNotFoundException

クラス

この例外は、指定されたアイデンティティがアイデンティティ・ストアに存在しない場合にスローされます。

OperationFailureException

クラス

この例外は、基礎となるアイデンティティ・ストアでの実行中に操作が失敗した場合にスローされます。

OperationNotSupportedException

クラス

この例外は、サービス・プロバイダが特定の操作をサポートしていない場合に、サービス・プロバイダによってスローされます。たとえば、この例外は、サービス・プロバイダがUserManagerをサポートしていない場合に、IdentityStore.getUserManager()をコールすると、サービス・プロバイダによってスローされます。

PasswordPolicyException

クラス

このクラスは、IMException(前述の説明を参照)を拡張したものです。

プロパティ

クラス

Propertyには名前/値の情報が含まれます。

PropertySet

クラス

プロパティの名前/値ペアのコレクション。プロパティの名前/値ペアの表現にはPropertyクラスが使用されます。PropertySetでは、同じ名前のプロパティが重複しないことが保証されます。

ロール

インタフェース

このインタフェースは、アイデンティティ・ストア内のロールを表します。

RoleManager

インタフェース

このインタフェースは、アイデンティティ・リポジトリ内でロールに関係する様々な操作の実行を管理するロール・マネージャを表します。

RoleProfile

インタフェース

このインタフェースは、ロールの詳細なプロファイルを表します。

SearchFilter

インタフェース

このインタフェースは、アイデンティティ・リポジトリの検索に使用される検索フィルタを表します。

SearchParameters

クラス

このクラスは、アイデンティティ・ストアの検索を実行するときに指定する必要のある検索パラメータを表します。このような検索パラメータには、次のものがあります。

- 検索フィルタ

- 検索するアイデンティティ・タイプ

- ページ・サイズ

- 時間制限

- 件数制限

SearchResponse

インタフェース

このインタフェースは、アイデンティティ・ストアの検索後に取得された検索結果を表します。実装は、サービス・プロバイダごとに固有です。

SimpleSearchFilter

インタフェース

このインタフェースは、アイデンティティ・リポジトリを検索するときに使用される簡易検索フィルタを表します。各簡易検索フィルタは、検索の属性またはプロパティ、評価演算子および値で構成される論理式です。この論理式が検索時に基礎となるアイデンティティ・リポジトリに適用され、一致した結果がフィルタ処理されて除外されます。

単純な検索フィルタの例については、Javadoc(第22.9項「ユーザーおよびロールAPIリファレンス」)を参照してください。

StoreConfiguration

インタフェース

StoreConfigurationは、特定のIdentityStoreインスタンスの構成プロパティを保持します。この構成オブジェクトのプロパティを変更することにより、該当するIdentityStoreインスタンスの動作を制御することができます。実際の構成プロパティとその値は、サービス・プロバイダに固有です。構成プロパティをまったくサポートしないサービス・プロバイダもあります。

SubjectParser

インタフェース

このインタフェースは、特定のサブジェクトからユーザーとロールのプリンシパルを抽出するユーティリティ・メソッドを提供します。このインタフェースの実装は、サービス・プロバイダが提供する必要があります。

ユーザー

インタフェース

このインタフェースは、アイデンティティ・ストア内のユーザーを表します。

UserManager

インタフェース

このインタフェースは、アイデンティティ・リポジトリ内でユーザーに関係する様々な操作の実行を管理する、ユーザー・マネージャを表します。

UserProfile

インタフェース

このインタフェースは、ユーザーの詳細なプロファイルを表します。汎用的な方法でユーザー・プロパティにアクセスすることができます。

userのあらゆるプロパティの読取りまはた変更には、次のAPIを使用できます。

- getProperty(java.lang.String)

- getProperties(java.lang.String[])

- setProperty(oracle.security.idm.ModProperty)

- setProperties(oracle.security.idm.ModProperty[])

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

この項では、プロバイダの基本的な概念とライフサイクルについて説明し、プロバイダを設定、構成および使用してOracle Platform Security Services環境でユーザー・リポジトリを操作する方法を説明します。

環境が正しく設定されていることを確認した後で、プロバイダを実装する際には、次の作業が必要になります。

- 基礎となるリポジトリの指定とそのリポジトリに適したプロバイダ・ファクトリ・クラスの選択

- プロバイダ・ファクトリとアイデンティティ・ストアのインスタンスの作成

- プロバイダの構成

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

- サービス・プロバイダの理解

- 環境の設定

- プロバイダの選択

- プロバイダの構成プロパティ

- プログラミングの考慮事項

- プロバイダのライフサイクル

22.3.1 サービス・プロバイダの理解

ユーザーおよびロールAPIは、ユーザーとロールを管理するためにコールされますが、このAPIは基礎となるアイデンティティ・リポジトリと直接相互作用することはありません。セキュリティ・アプリケーションでは、かわりに、基礎となるリポジトリと実際の通信を実行するプロバイダが使用されます。このしくみでは、プロバイダと接続の情報を変更するだけで、基礎となる様々なリポジトリで同じコードを使用できるため、柔軟性が得られます。

22.3.2 環境の設定

この項では、ユーザーおよびロールAPIの環境を構成する方法について説明します。

22.3.2.1 Jarの構成

環境には、次のようないくつかのjarファイルが必要です。

- provider jarファイル。目的の基礎となるアイデンティティ・リポジトリを実装します。

- ユーザーおよびロールAPIのjarファイル

- プロバイダで必要とされる可能性のある、その他のコンポーネントのjarファイル(Toplink、jdbc、xdbなど)。

関連するjarファイルがアプリケーションのクラスパスに含まれていることを確認してください。

22.3.2.2 jps-config.xml内のユーザー・クラス(Oracle Virtual Directoryのみ)

注意:

この変更はOracle Virtual Directory用の認証システムにのみ適用してください。

ユーザー属性のフェッチ時の効率を高めるため、jps-config.xmlに次のエントリを追加し、検索対象のユーザー・オブジェクト・クラスを指定します。

.
.
<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>
.
.

22.3.2.3 プロバイダ・ユーザーの読取り権限(Oracle Internet Directoryのみ)

Oracle Internet Directoryプロバイダの場合、構成済ユーザーにルート・レベルのcn=common,cn=products,cn=oraclecontextコンテナを読み取る権限が必要です。

22.3.3 プロバイダの選択

Oracle Platform Security Servicesは、次のLDAPディレクトリをはじめとする様々なユーザー・リポジトリをサポートします。

- Microsoft Active Directory

- Novell eDirectory

- Oracle Directory Server Enterprise Edition

- Oracle Internet Directory

- Oracle Virtual Directory

- OpenLDAP

- Oracle WebLogic Server対応のLDAPディレクトリ

- Microsoft ADAM

- IBM Tivoli

選択したアイデンティティ・リポジトリによって、そのプロバイダに使用するプロバイダ・クラスが決まります。プロバイダ・クラスには、ユーザーおよびロールAPIフレームワークで指定されているインタフェースを実装する必要があります。表22-2は、使用可能なプロバイダ・クラスを示しています。

表22-2 LDAPアイデンティティ・プロバイダ・クラス

プロバイダ

ファクトリ名

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

Oracle WebLogic Server対応の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

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

プロバイダのクラス名を特定した後は、次の手順を実行してプロバイダを作成します。

1. IdentityStoreFactoryBuilderクラスのgetIdentityStoreFactoryメソッドを使用して、ファクトリ・インスタンスを構築します。このビルダー・クラスAPIは、次の情報を受け取ります。

- プロバイダのクラス名

- 必要な環境プロパティ(ハッシュ表から得られます)

2. IdentityStoreFactoryクラスのgetIdentityStoreInstanceメソッドを使用して、ストア・インスタンスを作成します。

次の例では、Oracle Internet Directoryストアのファクトリ・インスタンスを作成しています。

IdentityStoreFactoryBuilder builder = new
IdentityStoreFactoryBuilder ();

IdentityStoreFactory oidFactory = builder.getIdentityStoreFactory(
”oracle.security.idm.providers.oid.OIDIdentityStoreFactory", factEnv);

次のように、ストアへの参照(アイデンティティ・ストアへの実際のハンドル)を取得します。

oidStore = oidFactory.getIdentityStoreInstance(storeEnv);

この例では、次の2つのハッシュ表オブジェクトが指定されています。

- factEnvハッシュ表は、ファクトリ・インスタンス環境を指定します。

- storeEnvハッシュ表は、ストア・インスタンス環境を指定します。

これらのハッシュ表の詳細は、第22.7.1項の例を参照してください。

22.3.5 プロバイダの構成プロパティ

構成は、使用するアイデンティティ・ストア・プロバイダに依存します。

すべてのタイプのLDAPベースのアイデンティティ・ストア・プロバイダの動作は、ファクトリ・インスタンスやストア・インスタンスの多数のプロパティを構成することにより、微調整することができます。次のプロパティは、LDAPベースのプロバイダにのみ関連しています。

- URL

- リポジトリが実行されるポート

- リポジトリにアクセスするときに使用するユーザーとパスワード

サポートされているLDAPベースのプロバイダのリストは、第22.3.3項「プロバイダの選択」を参照してください。

この項では、プロバイダ構成に関する次の項目について説明します。

- 起動時と実行時の構成

- ECID伝播

- 構成の値を渡すタイミング

22.3.5.1 起動時と実行時の構成

構成可能なプロパティは、次の2つのカテゴリに分類されます。

- 起動時の構成 - 命名規則として、ST_で始まるプロパティ名が使用されます。

- 実行時の構成 - 命名規則として、RT_で始まるプロパティ名が使用されます。

起動時の構成プロパティ

起動時の構成は1回のみ実行され、いったん設定されると、構成の設定はプロバイダのライフタイムにわたって永続します。

ST_SUBSCRIBER_NAMEを除いて、起動時のプロパティはプロバイダのファクトリ・インスタンスの作成時に指定されます。ST_SUBSCRIBER_NAMEは、ストア・インスタンスの作成時に設定されます。

表22-3は、起動時の構成プロパティを示しています。

表22-3 起動時のアイデンティティ・プロバイダ構成プロパティ

プロパティ名

説明

ST_BINARY_ATTRIBUTES

基礎となるLDAPサーバーに格納されたバイナリ・オブジェクトの名前を含むStringオブジェクトの配列の配列。プロバイダは、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サーバーにおける操作の基本DN。このプロパティは、IdentityStoreインスタンスの作成時に指定され、残りのプロパティのデフォルト値を決定するために使用されます。このプロパティはIdentityStoreインスタンスの作成時に指定する必要がありますが、その後この値を変更しても、IdentityStoreの動作は影響を受けません。

ST_CONNECTION_POOL_CLASS

接続プールの完全修飾された実装クラス名。

ST_INITIAL_CONTEXT_FACTORY

初期コンテキストを作成する初期コンテキスト・ファクトリの完全修飾クラス名。

実行時の構成プロパティ

実行時に設定するプロパティは、プロバイダによって実行されるその後のすべての操作に影響し、そのプロバイダのIdentityStoreインスタンスの動作を制御します。

実行時のプロパティは、IdentityStoreインスタンスから取得されるStoreConfigurationオブジェクトで該当するパラメータと値を指定して構成します。すべての実行時プロパティには、IdentityStoreインスタンスの作成時にデフォルト値が設定されますが、これは後から変更することができます。

表22-4は、実行時の構成プロパティを示しています。

表22-4 実行時のアイデンティティ・プロバイダ構成プロパティ

プロパティ名

説明

RT_USER_OBJECT_CLASSES

LDAPサーバーでユーザーを作成するために必要なオブジェクト・クラスの配列。

RT_USER_MANDATORY_ATTRS

ユーザーの作成時に指定する必要のある属性名。

RT_USER_CREATE_BASES

新しいユーザーの作成が可能なLDAPサーバーでのベースDN。

RT_USER_SEARCH_BASES

RT_USER_SEARCH_BASES

ユーザーの検索が可能なLDAPサーバーでのベースDN。

RT_USER_FILTER_OBJECT_CLASSES

LDAPサーバーでユーザーを検索するときに使用するオブジェクト・クラスの配列。

RT_GROUP_OBJECT_CLASSES

LDAPサーバーにロールを作成するために必要なオブジェクト・クラスの配列。

RT_GROUP_MANDATORY_ATTRS

ロールの作成時に指定する必要のある属性名。

RT_GROUP_CREATE_BASES

新しいロールの作成が可能なLDAPサーバーでのベースDN。

RT_GROUP_SEARCH_BASES

ロールの検索が可能なLDAPサーバーでのベースDN。

RT_GROUP_MEMBER_ATTRS

ロールのメンバー属性の配列。ロールのすべてのメンバーは、この属性に関して値を持ちます。

RT_GROUP_FILTER_OBJECT_CLASSES

LDAPサーバーでロールを検索するときに使用するオブジェクト・クラスの配列。

RT_USER_SELECTED_CREATE_BASE

現在選択されているユーザー作成ベース。createUser()コールの実行時に、ユーザーはこのベースDNで作成されます。選択された作成ベースがNULLで、ST_SUBSCRIBER_NAMEが指定されていない場合は、最初に指定されたRT_USER_CREATE_BASEの値が使用されます。ST_SUBSCRIBER_NAMEを指定した場合は、アイデンティティ・ストアのタイプに基づくサブスクライバ名を基準とする相対値がデフォルト値になります。

RT_GROUP_SELECTED_CREATE_BASE

現在選択されているロール作成ベース。createRole()コールの実行時に、ロールはこのベースDNで作成されます。選択された作成ベースがNULLで、ST_SUBSCRIBER_NAMEが指定されていない場合は、最初に指定されたRT_GROUP_CREATE_BASEの値が使用されます。ST_SUBSCRIBER_NAMEを指定した場合は、アイデンティティ・ストアのタイプに基づくサブスクライバ名を基準とする相対値がデフォルト値になります。

RT_GROUP_GENERIC_SEARCH_BASE

特定のアイデンティティに関連付けられたロールの検索に使用する一般的なロール検索ベース。たとえば、特定のユーザーに付与されたすべてのロールや、特定のユーザーのすべての管理対象ロールを検索する場合は、目的となるすべてのグループが存在する検索ベースが必要になります。これは、検索の最適化に役立ちます。通常、この検索ベースは共通の親です。すべてのLDAPプロバイダでは、サブスクライバ名が存在していれば、この値はデフォルトでサブスクライバ名に設定されます。サブスクライバ名がない場合は、最初のグループ検索ベースが使用されます。

RT_SEARCH_TYPE

LDAPサーバーでの検索が、SIMPLE、PAGED、VIRTUAL_LIST_VIEWのどのタイプかを決定します。

22.3.5.2 ECID伝播

ユーザーおよびロールAPIでは、デフォルトでECIDのサポートが無効になっています。

APIを初期化するときは、ECIDサポートに対してST_ECID_ENABLEDプロパティをtrueに設定します。次に例を示します。

factEnv.put(OVDIdentityStoreFactory.ST_ECID_ENABLED, "true");

注意:

この処理は、バックエンド・アイデンティティ・ストアとしてOracle Internet DirectoryまたはOracle Virtual Directoryを使用している場合にのみ必要です。これ以外のリポジトリ(Microsoft Active DirectoryやNovell eDirectoryなど)を使用している場合は不要です。

22.3.5.3 構成の値を渡すタイミング

構成データは、次のタイミングで指定できます。

- ファクトリ・インスタンスを作成するとき。

関連項目:

第22.3.6項「ファクトリ・インスタンス作成時のプロバイダの構成」

- ストア・インスタンスを作成するとき。

関連項目:

第22.3.7項「ストア・インスタンス作成時のプロバイダの構成」

- 実行時(ストア構成オブジェクトを使用)。

関連項目:

第22.3.8項「実行時の構成」

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

この項では、ファクトリ・インスタンス作成時のプロバイダの構成に関連するトピックを説明します。

この段階での構成は、そのファクトリ・オブジェクト全体、および、その特定のファクトリ・インスタンスを使用して作成されるオブジェクトに影響を与えます。次の一般的なプロパティをはじめとして、多くの起動時のプロパティがこの時点で設定されます。

- ST_LDAP_URL - LDAPリポジトリのURL

- ST_SECURITY_PRINCIPAL - ユーザー名

- ST_SECURITY_CREDENTIAL - リポジトリへの接続に必要なユーザー資格証明

22.3.6.1 Oracle Internet Directoryプロバイダ

次の例では、Oracle Internet Directory (OID)ファクトリの設定時にプロバイダが構成されています。

IdentityStoreFactoryBuilder builder = new
IdentityStoreFactoryBuilder();
IdentityStoreFactory oidFactory = null;
Hashtable factEnv = 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);

注意:

イタリックの値は実行前に適切な値に置換する必要があります。

22.3.6.2 既存のロガー・オブジェクトの使用

ユーザーおよびロールAPIに名前付きのロガー・オブジェクトを指定することができます。APIは指定されたロガーを使用してメッセージを記録します。ファクトリの作成時に外部ロガー名を環境変数として指定する必要があります。

次に例を示します。

Logger mylogr = Logger.getLogger("mylogger.abc.com");
FileHandler fh = new FileHandler("userroleapi.log");
mylogr.addHandler(fh);

…

factEnv.put(OIDIdentityStoreFactory.ST_LOGGER_NAME,
"mylogger.abc.com");
oidFactory = builder.getIdentityStoreFactory(
"oracle.security.idm.providers.oid.
OIDIdentityStoreFactory", factEnv);

このコードにより、すべてのログ・メッセージは、userroleapi.logという名前のログ・ファイルにリダイレクトされます。

22.3.6.3 定数値の指定

ファクトリの作成時にST_PROPERTY_ATTRIBUTE_MAPPINGプロパティにマップを指定することにより、定数を上書きしたり、欠落している定数に事前に値を指定することができます。

次のサンプル・コードでは、RoleProfile.OWNERから"myowner"属性へのマッピングを設定しています。このようにすると、getOwners()やgetOwnedRoles()など、所有者に関連するすべての操作がこの属性を使用して実行されます。

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);

22.3.6.4 接続パラメータの構成

ST_CONNECTION_POOL_MIN_CONNECTIONSおよびST_CONNECTION_POOL_MAX_CONNECTIONSを使用して、接続プールの最大接続数と最小接続数のパラメータを構成することができます。デフォルトでは、これらのパラメータの値は、それぞれ0と10です。また、次の制約があります。

(ST_CONNECTION_POOL_MAX_CONNECTIONS  - ST_CONNECTION_POOL_MIN_CONNECTIONS) >= 10

次に例を示します。

factEnv.put
(LDIdentityStoreFactory.ST_CONNECTION_POOL_MIN_CONNECTIONS,  "3");

factEnv.put
(LDIdentityStoreFactory.ST_CONNECTION_POOL_MAX_CONNECTIONS, "16");

22.3.6.5 カスタム接続プール・クラスの構成

カスタム接続プールを使用するには、次のように、カスタム接続プール・クラスの完全修飾クラス名を指定する必要があります。

factEnv.put(OIDIdentityStoreFactory.ST_CONNECTION_POOL_CLASS,
"oracle.security.idm.providers.stdldap.JNDIPool");

関連情報は、第J.5.1項「組込みのLDAP認証プロバイダへの接続の失敗」を参照してください。

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

ストアで一般的に使用される構成パラメータは、この時点で受け入れられる唯一の起動時プロパティである、ST_SUBSCRIBER_NAMEです。ストアで一般的に使用される構成パラメータは、この時点で受け入れられる唯一の起動時プロパティである、ST_SUBSCRIBER_NAMEです(すべての実行時プロパティはアイデンティティ・ストアの作成時に指定可能です。)

第22.3.6項「ファクトリ・インスタンス作成時のプロバイダの構成」で示したファクトリ・インスタンスの作成例に続いて、次のコードではストアへのハンドル・インスタンスを作成しています。

IdentityStore oidStore = null;
Hashtable storeEnv = new Hashtable();

// Creating the store instance
storeEnv.put(OIDIdentityStoreFactory.ST_SUBSCRIBER_NAME,
"dc=us,dc=oracle,dc=com");
oidStore = oidFactory.getIdentityStoreInstance(storeEnv);

注意:

ディレクトリには有効なサブスクライバ名を指定する必要があります。Oracle Internet Directoryの場合は、STsubscriber名を正しいDNまたはレルムのニックネームで指定することができます。

22.3.8 実行時の構成

前述の、第22.3.6項「ファクトリ・インスタンス作成時のプロバイダの構成」および第22.3.7項「ストア・インスタンス作成時のプロバイダの構成」では、インスタンスの作成時に構成を実行する方法を示しました。実行時のプロパティの追加と変更を容易にするために、ユーザーおよびロールAPIにはConfigurationクラスも用意されています。

Configurationインスタンスは、IdentityStore.getStoreConfiguration() APIコールを使用して、ストア・インスタンスから取得できます。この構成オブジェクトを使用してプロパティを変更することができます。

このアプローチによる変更は、実行時のプロパティに対してのみ可能です。また、効果を確認できるのも実行時に限られます。

次の例では、RT_USER_SEARCH_BASESプロパティを設定します。

StoreConfiguration conf = oidStore.getStoreConfiguration();
conf.setProperty(”RT_USER_SEARCH_BASES”, ”dc=us,dc=oracle,dc=com”);

22.3.9 プログラミングの考慮事項

この項では、プロバイダとプロバイダ・アーティファクトの操作のヒントを説明します。

22.3.9.1 プロバイダの移植性に関する考慮事項

プロバイダを切り替えても(OpenLDAPプロバイダとOracle Internet Directoryプロバイダとの間での切替えなど)アプリケーションを移植できるようにするには、ユーザーおよびロールAPIを操作する際に次のガイドラインに従ってください。

1. ユーザー・プロパティを参照するときには、対応するoracle.security.idm.UserProfile定数のみを使用します。アイデンティティ・リポジトリ間で移植不可能なネイティブの名前は使用しないでください。たとえば、アプリケーションでユーザーのログイン名を取得する必要がある場合は、次のようにUserProfile.USER_NAME定数を使用してフェッチします。

Property prop = usrprofile.getProperty(UserProfile.USER_NAME);

2. 理由は明らかですが、ほとんどの標準的なユーザー・プロパティにはUserProfile定数が用意されています。ただし、すべてのプロパティに用意されているとはかぎりません。アプリケーションで特定のユーザーのすべてのプロパティを汎用的に取得する必要がある場合は、次のコードを使用します。

UserProfile upf = null;

// Obtain the user profile from user object. User object can be obtained using search

// get the properties supported for given user in currently configured repository
List proplst = store.getUserPropertyNames();

String[] proparr = (String[]) proplst.toArray(new String[proplst.size()]);

// get all properties of the user
PropertySet pset = upf.getProperties(proparr);

3. 検索フィルタを作成するときには、検索フィルタの文字列内で直接ネイティブのワイルド・カード文字を使用しないでください。かわりに、SimpleSearchFilter.getWildCardChar()メソッドを使用します。これにより、基礎となるプロバイダに基づいて正しいワイルド・カード文字がフェッチされます。たとえば、このAPIは、データベース・プロバイダの場合は%を返し、Oracle Internet Directoryプロバイダの場合は*を返します。

SmpleSearchFilter sf = m_identityStore.getSimpleSearchFilter(
attrName, SimpleSearchFilter.TYPE_EQUAL, null);

sf.setValue( filterStringWithoutWildcard+sf.getWildCardChar());

4. アプリケーションが事前定義済のワイルド・カード文字を含むユーザー指定のフィルタ文字列を受け入れる場合は、ユーザーおよびロールAPIのフィルタを生成するときに、フィルタに次の変換を適用します。

//User supplied filter which 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);

太字の行により、ユーザー指定のフィルタは汎用的なユーザーおよびロールAPIのフィルタ・フォーマットに変換されます。

22.3.9.2 IdentityStoreオブジェクト使用時の考慮事項

アプリケーションをコーディングするときは、次の考慮事項に留意してください。

スレッド・セーフティ

現在のIdentityStoreの実装は、スレッドセーフではありません。ユーザーおよびロールAPIでは、ストア・インスタンスは通常はスレッド間で共有されないと想定されています。ストア・インスタンスがスレッド間で共有される場合は、スレッド・セーフティに要求されるすべての問題点にアプリケーション・コードで対処する必要があります。

スレッド・セーフティとパフォーマンスの間には、トレードオフが存在します。スレッド・セーフティを実装する必要のあるユースケースでは、実装によるパフォーマンスへの影響を考慮に入れる必要があります。

セッションごとに1つのストア・インスタンス

委任管理サーバーなどのアプリケーションでは、各セッション(1人のユーザーのログインに対応)で作成/検索ベースやその他の様々な実行時設定を変更できます。これらはユーザーおよびロールAPIの実行時のプロパティとして定義します。IdentityStoreオブジェクトは、このようなすべての設定をカプセル化し、これに応じて実行時の動作を変更します。このような理由から、セッションごとに1つのIdentityStoreインスタンスというルールが適用されています。

22.3.10 プロバイダのライフサイクル

プロバイダは、そのプロバイダ用に作成されたファクトリ・インスタンスが存続している間、存在し続けます。ファクトリ・インスタンスの寿命は、そのインスタンスに対してclose() APIがコールされると終了します。プロバイダ・インスタンスが終了すると、そのインスタンスを使用して作成されたすべてのオブジェクトは無効になり、そのようなオブジェクトに対するその後のAPIコールでは、予期しない結果が返されます。

IdentityStoreのインスタンスにも、同様の考慮事項が当てはまります。

注意:

- ファクトリ・インスタンスはスレッドセーフですが、IdentityStoreインスタンスの場合はスレッドセーフではありません。

- ベスト・プラクティスとしては、サーバー接続を一括して閉じ、使用されなくなったオブジェクトとインスタンスを明示的に削除することです。

22.4 リポジトリの検索

ユーザーおよびロールAPIには、次の2種類の問合せ関数があります。

- 1つのアイデンティティを返す関数

- アイデンティティのリストを返す関数

この項では、これらのAPIを使用して実行可能な次の検索および関連タスクについて説明し、検索パラメータの指定方法を詳細に示します。

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

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

- 検索パラメータの指定

- 検索フィルタの使用

- GUIDによる検索

22.4.1 特定のアイデンティティの検索

searchUserおよびsearchRole APIを使用すると、アイデンティティ・ストアに対して次のように特定のユーザーまたはロールを直接問い合せることができます。

IdentityStore.searchUser(String name);

IdentityStore.searchUser(Principal principal);

IdentityStore.searchUser(int searchType, String name);

ここで、searchTypeには次のものを指定できます。

- SEARCH_BY_NAME

- SEARCH_BY_UNIQUE_NAME

IdentityStore.searchRole(int searchType, String value);

これらの関数は、特定のユーザーまたはロールのアイデンティティがストアに存在することがわかっているときに、そのアイデンティティへのオブジェクト参照が必要な場合に実行する単純な問合せで効果的です。これらの関数の機能は、次の点で最小限になっています。

- 文字列値のみを受け取ります。

- 正規表現をサポートしません。

これらの関数では、同じ値を持つ複数のエンティティがストアに存在すると例外が発生します。

22.4.2 複数のアイデンティティの検索

ユーザーおよびロールAPIには、検索を実行して複数のアイデンティティを返すことのできる、次のようないくつかの関数が含まれています。

IdentityStore.search(SearchParams params);
IdentityStore.searchUsers(SearchParams params);
IdentityStore.searchRoles(int searchType, SearchParams params);
IdentityStore.searchProfiles(SearchParams params);

各関数は、検索オブジェクトを受け取り、検索レスポンス・オブジェクトを返します。

22.4.3 検索パラメータの指定

SearchParamsオブジェクト

SearchParamsオブジェクトには、次の情報が格納されます。

- 検索フィルタ - 第22.4.4項「検索フィルタの使用」を参照してください。

- 検索するアイデンティティ・タイプ - RolesまたはUsersアイデンティティ・タイプを検索できます。

- ページ・サイズ - デフォルトでは、ページング・オプションは無効になっています。問合せでページングが必要な場合は、ページ・サイズを適切な正の値に設定してください。

- タイムアウト制限 - タイムアウトは秒単位で指定します。

- 件数制限 - 問合せによって返される結果の数を制限します。

SearchResponseオブジェクト

SearchResponseは、複数のアイデンティティを取得するときに使用されるデータ構造体です。コードでは、次の関数を使用して、この構造体に格納された複数のアイデンティティを繰り返し処理できます。

- hasNext() - さらに要素が存在する場合はtrueを返し、そうでない場合はfalseを返します。

- next() - 次の要素が使用可能であればその要素を返し、そうでなければ例外を返します。

22.4.4 検索フィルタの使用

ユーザーおよびロールAPIには、様々な検索操作を容易に実行するための各種の検索フィルタが含まれています。この項では、検索フィルタの使用の重要なポイントについて説明します。

- 検索フィルタの演算子

- 検索フィルタ使用時の特殊文字の処理

- ログイン・ユーザー用の検索フィルタ

- 検索フィルタの使用例

22.4.4.1 検索フィルタの演算子

検索フィルタの演算子を使用するときには、次のルールを順守してください。

サポートされる演算子

標準のLDAPストアは、= (「等しい」演算子)、< (「より小さい」演算子)、> (「より大きい」演算子)、& (AND演算子)、| (OR演算子)および ! のみを受け入れます(NOT演算子)。IdentityStoreでは、さらに2つの演算子<=(以下)および>=(以上)が用意されており、使用しやすくなっています。

演算子=、<、>、<=および>=は簡易検索フィルタの作成に使用され、演算子&および|は2つ以上の検索文字列の組合せによる複合検索フィルタの作成に使用されます。

NOT演算子

NOT演算子は、簡易検索フィルタと複合検索フィルタの両方で使用できます。この演算子は、フィルタの状態を否定する、つまりフィルタによって前に拒否されたエンティティを受け入れるように、または前に受け入れたエンティティを拒否するように、フィルタの状態を変更するために使用します。

NOT演算子には、次のSearchFilter APIを使用してアクセスできます。

- void negate();

- boolean isNegated();

22.4.4.2 検索フィルタ使用時の特殊文字の処理

RFC-2254 (LDAP検索フィルタの文字列表現)に従って、*、(、)、\およびNULL文字は個別に処理する必要があります。ユーザーおよびロールAPIは、演算子(、)および\を処理しますが、LDAPストアのワイルドカード文字でもある*演算子は処理されません。これらの文字はユーザーおよびロールAPIフレームワークで処理されるため、APIユーザーはこれらの文字を別途に処理する必要はありません。

22.4.4.3 ログイン・ユーザー用の検索フィルタ

アプリケーションでは一般に、ログイン・ユーザーのアイデンティティおよびユーザーのグループ名を取得する必要があります。

Oracle WebLogic Serverの認証プロバイダでは、ユーザー関連の2つの属性user.login.attrとgroupname.attrを使用します。ログイン時、認証プロバイダはuser.login.attrを使用してユーザーを格納し、groupname.attrを使用してグループを格納します。

アプリケーションでは、UserProfile.getUserName()(user.login.attrにマップされる)を使用して、ログイン・ユーザーのアイデンティティを取得します。ロール(グループ)名を取得するには、RoleProfile.getProperty(RoleProfile.NAME)(groupname.attrにマップされる)を使用します。

ログイン・ユーザーおよびロールの取得方法を示すサンプル・コールを、それぞれ例22-6と例22-7に示します。

22.4.4.4 検索フィルタの使用例

この項では、いくつかの使用例を示します。

例22-1 名前によってユーザーを取得するための簡易フィルタ

簡易検索フィルタの実装は、基礎となるストアに依存します。検索フィルタのインスタンスはストア・インスタンスを使用して取得できます。

この例のフィルタでは、名前フィールドの値が非NULLであるすべてのエントリが許可されます。

SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(UserProfile.NAME,
SimpleSearchFilter.TYPE_EQUAL, null);
sf.setValue(sf.getWildCardChar());

例22-2 言語プリファレンスによってユーザーを検索するための簡易フィルタ

この例では、優先言語が英語以外のユーザーが検索されます。

SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(
UserProfile.PREFERRED_LANGUAGE,
SimpleSearchFilter.TYPE_EQUAL,
"english");
sf.negate();

例22-3 先頭の文字による名前の複合フィルタ

この複合フィルタは、複数の検索フィルタを演算子の&または|で結合しています。これは、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);

例22-4 先頭の文字を制限する複合フィルタ

この例では、複合フィルタのネストにより、文字のiで始まるものを除いて、aからjまでの文字で始まる名前を持つユーザーを検索することができます。

[continue from Example 3]

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);

例22-5 出力付きの完全な検索

この例では、文字の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);

// 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());
}

例22-6 ログイン・ユーザーのアイデンティティの取得

この例は、ログイン・ユーザーの取得方法を示しています。

SimpleSearchFilter sf = oidStore.getSimpleSearchFilter(
UserProfile.USER_NAME,  SimpleSearchFilter.TYPE_EQUAL, "sampleUserName");
SearchParameters ssp = new SearchParameters(sf, SearchParameters.SEARCH_USERS_ONLY);

// Searching for users
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 );
}

注意:

((User)idy).getNameによって返される名前はRDNから導出されたもので、ログイン名と異なる場合があります。

例22-7 ロール/グループ名の取得

この例は、ロール(グループ)名の取得方法を示しています。

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 );
}

22.4.5 GUIDによる検索

この例では、ユーザーおよびロールAPIで取得されたGUIDの値を直接検索に使用することができます。

// up = user.getUserProfile();
String guid = up.getGUID();
SimpleSearchFilter sf1 = oidStore.getSimpleSearchFilter(
UserProfile.GUID,
SimpleSearchFilter.TYPE_EQUAL, guid);
SearchParameters params = new SearchParameters();
params.setFilter(sf1);
SearchResponse resp = oidStore.search(params);
while (resp.hasNext())
System.out.println("user for guid : " + guid + ","+ resp.next());

22.5 ユーザー認証

検証目的で、ユーザーおよびロールAPIをパスワードベースのユーザー認証に使用できます。(前述のとおり、このAPIは認証および認可を目的とはしていません。)

authenticateUser APIは、ユーザー・ログイン名を受け取り、指定されたパスワードを使用してユーザーの認証を試みます。認証が成功した場合は、ユーザー・オブジェクトを返します。

パスワードベースの認証の次に例を示します。

store.getUserManager().authenticateUser(”testuser”,”password”);

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

ユーザーおよびロールAPIを使用すると、アイデンティティ・ストアへの新規アイデンティティの追加やストアでのアイデンティティの変更が容易になります。UserManagerクラスとRoleManagerクラスは、それぞれ、ユーザーとロールに固有のデータの作成、変更および削除操作を処理します。

UserManagerとRoleManagerのインスタンスは、ストア・インスタンスから次のようにして取得できます。

UserManager um = oidStore.getUserManager();
RoleManager rm = oidStore.getRoleManager();

この項のトピックは次のとおりです:

- アイデンティティ作成時の特殊文字の処理

- アイデンティティの作成

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

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

22.6.1 アイデンティティ作成時の特殊文字の処理

RFC-2253によって、LDAP v3の識別名の文字列表現が定義されます。つまり、RFCで指定されたすべての文字が処理されます。ユーザーおよびロールAPIのユーザーは、これらの特殊文字をエスケープ/エスケープ解除する必要はありません。特殊文字をエスケープ/エスケープ解除すると、間違った結果になります。

これによって、空のプロパティを使用してアイデンティティを作成するときに問題が生じる可能性があります。この場合、RDN名を使用して様々な必須属性の値が指定されます。これらの必須属性の中には、より厳格な検証ルールが適用されるものもあります。その場合は、アイデンティティの作成が失敗して、例外が発行されます。

22.6.2 アイデンティティの作成

UserManagerクラスの次の2つの関数を使用すると、ユーザーを容易に作成できます。

- createUser(java.lang.String name, char[] password)

指定された名前とパスワードを持つユーザーを、基礎となるリポジトリに作成します。
アイデンティティ・ストアで一部の属性が必須として指定されている場合は、そのようなすべてのフィールドにnameの値が移入されます。

- createUser(java.lang.String name, char[] password, PropertySet suppliedProps)

プロパティは、指定されたプロパティ値を使用して設定されます。必須の属性値が指定されていない場合は、欠落した属性にデフォルトとしてnameの値が使用されます。

同様に、RoleManagerのAPIはロールの作成に使用されます。

ロールは次の2つのカテゴリに分類されます。

- アプリケーション・スコープ

- エンタープライズ・スコープ

RoleManagerを起動してロールを作成する場合、デフォルトでは、特に指定しないかぎり、ロールはエンタープライズ・スコープで作成されます。

ロールの作成をサポートするRoleManagerのAPIには、次のものがあります。

createRole(String roleName);
createRole(String roleName, int roleScope);

ロールの作成手順はユーザーの作成手順と類似しています。すべての必須の属性にはroleNameの値が指定されます。

22.6.3 アイデンティティの変更

アイデンティティを変更するには、そのアイデンティティへの参照が必要です。User、UserProfile、Role、RoleProfileの各クラスに、アイデンティティの変更を容易にするための次のようなAPIが用意されています。

user.setProperty(ModProperty prop);

user.setProperties(ModProperty [] props);

ModProperty構造体は、次のもので構成されます。

- フィールド名

- フィールドの新しい値(複数可)

- 変更演算子

有効な演算子は次のとおりです。

ModProperty.ADD
ModProperty.REMOVE
ModProperty.REPLACE

次の例では、表示名が置換されます。

UserProfile usrprofile = usr.getUserProfile();

ModProperty mprop = new ModProperty(UserProfile.DISPLAY_NAME,
"modified display name",
ModProperty.REPLACE);

usrprofile.setProperty(mprop);

複数の値を持つ属性の中の特定の値を変更する場合は、最初にその値を削除し、次に新しい値を追加するという2段階の手順になります。

22.6.4 アイデンティティの削除

アイデンティティの削除には、dropUserとdropRoleの各APIを使用します。

アイデンティティを削除する場合は、コードにユーザーとロールの両方の参照が必要になります。次に例を示します。

User usr;
Role role;
…
…
usrmanager.dropUser(usr);
rolemanager.dropRole(role);

22.7 ユーザーおよびロールAPIの使用例

関連項目:

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

この項では、ユーザーおよびロールAPIの実際のアプリケーションを示したいくつかの例を取り上げます。

- 例1: ユーザーの検索

- 例2: Oracle Internet Directoryストアにおけるユーザー管理

- 例3: Microsoft Active Directoryストアにおけるユーザー管理

22.7.1 例1: ユーザーの検索

この例では、Oracle Internet Directoryのアイデンティティ・ストアで、ユーザーを検索するための簡易検索フィルタを設定しています。

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);

// creating the store instance
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();
}
}
}

ユーザーの検索とグループの検索

ユーザーを検索する場合、前述のSimpleSearchFilterのように、UserProfileを呼び出します。ただし、グループを検索する場合はRoleProfileを使用します。

22.7.2 例2: Oracle Internet Directoryストアにおけるユーザー管理

この例では、Oracle Internet Directoryストアで、アイデンティティの作成、変更、削除を含む、次のようなユーザー管理タスクを実行しています。

- ユーザーの作成

- ユーザーの表示名の変更

- ユーザーの削除

public class CreateModifyDeleteUser
{
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);

// creating the store instance
storeEnv.put(OIDIdentityStoreFactory.RT_SUBSCRIBER_NAME,
"dc=us,dc=oracle,dc=com");
oidStore = oidFactory.getIdentityStoreInstance(storeEnv);

//get UserManager
UserManager usrmanager = oidStore.getUserManager();

// create user
String usrname = "testuser";
// delete user if already exists
try
{
User usr = oidStore.searchUser(usrname);
usrmanager.dropUser(usr);
}catch(IMException ime){}

System.out.println("creating user "+usrname);
User usr =
usrmanager.createUser(usrname,"passwd1".toCharArray());
System.out.println("user (" +usr.getUniqueName() + ") created");

// modifying user properties
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();

// drop user
System.out.println("Now dropping user "+usrname);
usrmanager.dropUser(usr);
System.out.println("user dropped");

}catch (IMException e)
{
e.printStackTrace();
}
}
}

22.7.3 例3: Microsoft Active Directoryストアにおけるユーザー管理

この例では、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");

// creating the factory instance
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);

// creating the store instance
storeEnv.put(ADIdentityStoreFactory.ST_SUBSCRIBER_NAME,
"dc=upad,dc=us,dc=oracle,dc=com");
adStore = adFactory.getIdentityStoreInstance(storeEnv);

//get UserManager
UserManager usrmanager = adStore.getUserManager();

// create user
String usrname = "amyd";
// delete user if already exists
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() );

// modifying user properties
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("now 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 SUCCESS !!");
else
System.out.println("password verification FAILED !!");

SimpleSearchFilter sf = adStore.getSimpleSearchFilter(
UserProfile.NAME, SimpleSearchFilter.TYPE_EQUAL, usrname);

SearchParameters params = new SearchParameters();
params.setFilter(sf);

// Searching for 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());
}

// drop user
System.out.println("Now dropping user "+usrname);
usrmanager.dropUser(usr);
System.out.println("user dropped");

}catch (Exception e)
{
e.printStackTrace();
}
}
}

22.8 LDAPベースのユーザーおよびロールAPIプロバイダのSSL構成

この項では、ユーザーおよびロールAPIのSSLサポートについて説明します。内容は次のとおりです。

- すぐに使用できるSSLのサポート

- ユーザーおよびロールAPIのSSLサポートのカスタマイズ

22.8.1 すぐに使用できるSSLのサポート

ユーザーおよびロールAPIのLDAPベースのプロバイダは、LDAPベースのアイデンティティ・ストアとのセキュアなSSL通信を可能にするために、Sun Java Secure Sockets Extension (JSSE)に依存しています。JSSEは、JDK 1.4以上に含まれます。

このようなLDAPプロバイダとして、次のものがあります。

- Microsoft Active Directory

- Novell eDirectory

- Oracle Directory Server Enterprise Edition

- Oracle Internet Directory

- OpenLDAP

- Oracle WebLogic Server対応のLDAPディレクトリ

22.8.1.1 システム・プロパティ

SSLをサポートするには、次の情報をシステム・プロパティとして指定する必要があります。

javax.net.ssl.keyStore

javax.net.ssl.keyStorePassword

javax.net.ssl.trustStore

javax.net.ssl.trustStorePassword

JSSEの完全な情報は、Java Secure Socket Extension (JSSE)リファレンス・ガイド(http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。

22.8.1.2 SSL構成

ユーザーおよびロールAPIの構成を行う際は、SSL構成の詳細を設定する必要があります。

JVMに対してキーストアの場所とパスワードをシステム・プロパティとして指定します。

String keystore = "<key store location>";
String keypasswd = "<key store password>";
System.setProperty("javax.net.ssl.trustStore",keystore);
System.setProperty("javax.net.ssl.trustStorePassword", keypasswd);

IdentityStoreFactoryインスタンスの作成時に、環境に次のプロパティを指定します。

1. 次の例にように、LDAPサーバーのSSL URLを設定します。

factEnv.put(ADIdentityStoreFactory.ST_LDAP_URL,
"ldaps://ldaphost:sslport/");

2. 次のように、セキュリティ・プロトコルをSSLに設定します。

factEnv.put("java.naming.security.protocol","SSL");

22.8.2 ユーザーおよびロールAPIのSSLサポートのカスタマイズ

ユーザーおよびロールAPIプロバイダのSSLSocketFactoryをカスタマイズすることにより、SSLサポートをカスタマイズすることができます。

22.8.2.1 SSL構成

IdentityStoreFactoryインスタンスの作成時に、次のプロパティを指定します。

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");

22.9 ユーザーおよびロールAPIリファレンス

ユーザーおよびロールAPIのリファレンス(Javadoc)は、次のドキュメントにあります。

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

22.10 カスタムのユーザーおよびロール・プロバイダの開発

この項では、セキュリティ開発者がアイデンティティ(ユーザーおよびロール)の管理に使用できるカスタム・プロバイダを開発する方法を説明します。内容は次のとおりです。

- SPIの概要

- ユーザーおよびロール・プロバイダのタイプ

- 読取り専用プロバイダの開発

- フル機能プロバイダの開発

- 開発のガイドライン

- テストと検証

- 例: アイデンティティ・プロバイダの実装

22.10.1 SPIの概要

ユーザーおよびロールAPIには、カスタムのユーザーおよびロール・プロバイダの開発を可能にするサービス・プロバイダ・インタフェース(SPI)が用意されています。このサービス・プロバイダ・インタフェースを使用して、任意のアイデンティティ・データ・リポジトリで使用するカスタム・プロバイダを開発できます。

このSPIは、抽象クラスのセットであるoracle.security.idm.spiパッケージとしてバンドルされています。カスタムのユーザーおよびロール・プロバイダは、要件に合せてこのSPIを拡張することで作成します。

関連項目:

「ユーザーおよびロールSPIリファレンス」

22.10.2 ユーザーおよびロール・プロバイダのタイプ

ユーザーおよびロールAPIは、検索操作の機能と作成、読取り、更新および削除(CRUD)の各操作の機能を提供します。読取り専用機能に基づくユーザーおよびロール・プロバイダでは、検索操作のみがサポートされます。フル機能プロバイダでは、検索操作とCRUD操作の両方がサポートされます。つまり、フル機能プロバイダは、読取り専用プロバイダのスーパーセットです。

開発者は、要件に応じて読取り専用とフル機能のいずれのプロバイダを作成するかを選択します。

次の場合は、読取り専用プロバイダの開発が適切です。

- 基礎となるアイデンティティ・リポジトリが読取り専用モードで動作している場合

- ユーザーおよびロールAPIを使用するアプリケーションでCRUD APIをコールしない場合

たとえば、SOAアイデンティティ・サービスで使用するプロバイダとしては読取り専用プロバイダが適切です。

22.10.3 読取り専用プロバイダの開発

この項では、プロバイダの実装に使用するクラスについて説明します。この項の内容は次のとおりです。

- 拡張が必要なSPIクラス

- oracle.security.idm.spi.AbstractIdentityStoreFactory

- oracle.security.idm.spi.AbstractIdentityStore

- oracle.security.idm.spi.AbstractRoleManager

- oracle.security.idm.spi.AbstractUserManager

- oracle.security.idm.spi.AbstractRoleProfile

- oracle.security.idm.spi.AbstractUserProfile

- oracle.security.idm.spi.AbstractSimpleSearchFilter

- oracle.security.idm.spi.AbstractComplexSearchFilter

- oracle.security.idm.spi.AbstractSearchResponse

22.10.3.1 拡張が必要なSPIクラス

表22-5は、読取り専用プロバイダを実装するために拡張が必要となるSPIクラスを示しています。

注意:

すべての抽象メソッドを実装する必要があります。

表22-5 カスタム・プロバイダ向けに拡張するSPIクラス

クラス

使用方法

oracle.security.idm.spi.AbstractIdentityStoreFactory

この拡張クラスには、デフォルト・コンストラクタおよびjava.util.Hashtableオブジェクトを受け取るコンストラクタを追加する必要があります。

oracle.security.idm.spi.AbstractIdentityStore

oracle.security.idm.spi.AbstractRoleManager

oracle.security.idm.spi.AbstractUserManager

oracle.security.idm.spi.AbstractRoleProfile

oracle.security.idm.spi.AbstractUserProfile

oracle.security.idm.spi.AbstractSimpleSearchFilter

拡張元クラスのコンストラクタは、抽象(スーパー)クラスのコンストラクタをコールする必要があります。

oracle.security.idm.spi.AbstractComplexSearchFilter

拡張元クラスのコンストラクタは、抽象(スーパー)クラスのコンストラクタをコールする必要があります。

oracle.security.idm.spi.AbstractSearchResponse

次に、各クラスのその他の要件および使用方法を示します。

22.10.3.2 oracle.security.idm.spi.AbstractIdentityStoreFactory

このSPIクラスを拡張するクラスには次のコンストラクタが必要です。

1. デフォルト・コンストラクタ(引数が指定されていないコンストラクタ)。

2. 引数としてjava.util.Hashtableオブジェクトを受け取るコンストラクタ。このハッシュ表を使用して、プロバイダで必要な構成プロパティを受け取ることができます。
この構成プロパティは、ユーザーおよびロールの構成段階でこのコンストラクタに渡されます。構成プロパティは、Hashtable引数で渡すキーと値のペアです。

- このキーはjava.lang.Stringとする必要があります。

- この値はjava.lang.Objectとする必要があります。

この値のタイプはStringにすることをお薦めします。これによって、テキスト・ファイルであるjps-config.xmlでプロパティを確実に指定できます。

関連項目:

「ユーザーおよびロールSPIリファレンス」: このクラスで実装する必要があるメソッドの詳細。ここにあげられているメソッドをすべて実装する必要があります。

22.10.3.3 oracle.security.idm.spi.AbstractIdentityStore

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。次のことに留意してください:

- メソッドgetStoreConfiguration()はオプションですが、OperationNotSupportedExceptionをスローすることがあります。

- メソッドgetSubjectParser()はnullを返すことがあります。

返す検索結果がない場合、すべての検索APIは次をスローします。

oracle.security.idm.ObjectNotFoundException

空のSearchResponseが返されることはありません。

22.10.3.4 oracle.security.idm.spi.AbstractRoleManager

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getGrantedRoles()

- getOwnedRoles()

- getManagedRoles()

- isGranted()

- isManagedBy()

- isOwnedBy()

- isDropRoleSupported() - 必ずfalseを返します。

- isCreateRoleSupported() - 必ずfalseを返します。

- isModifyRoleSupported() - 必ずfalseを返します。

残りのメソッドは、それぞれの実装で次の例外をスローする必要があります。

oracle.security.idm.OperationNotSupportedException

22.10.3.5 oracle.security.idm.spi.AbstractUserManager

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- authenticateUser(User, char[])

- authenticateUser(String, char[])

- isDropUserSupported() - 必ずfalseを返します。

- isCreateUserSupported() - 必ずfalseを返します。

- isModifyUserSupported() - 必ずfalseを返します。

残りのメソッドは、それぞれの実装で次の例外をスローする必要があります。

oracle.security.idm.OperationNotSupportedException

22.10.3.6 oracle.security.idm.spi.AbstractRoleProfile

oracle.security.idm.spi.AbstractRoleProfileは、詳細なロール・プロファイルを返すために使用できる抽象クラスです。

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getDisplayName()

- getGUID()

- getName()

- getUniqueName()

- getPrincipal()

- getDescription()

- getGrantees()

- getManagers()

- getOwners()

- getProperty() - リクエストされたプロパティが、対応するロールに設定されていないか有効でない場合は、値としてnullが返されます。

- isApplicationRole() - 必ずfalseを返します。

- isEnterpriseRole() - 必ずfalseを返します。

- isSeeded() - 必ずfalseを返します。

- getRoleProfile() – 現在のオブジェクトへの参照を返します。

残りのメソッドは、それぞれの実装で次の例外をスローする必要があります。

oracle.security.idm.OperationNotSupportedException

22.10.3.7 oracle.security.idm.spi.AbstractUserProfile

oracle.security.idm.spi.AbstractUserProfileは、詳細なユーザー・プロファイルを返すために使用できる抽象クラスです。

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getDisplayName()

- getGUID()

- getName()

- getUniqueName()

- getPrincipal()

- getProperty() - リクエストされたプロパティが、対応するロールに設定されていないか有効でない場合は、null値が返されます。

- getProperties() – リクエストされたプロパティが、対応するユーザーに設定されていないか有効でない場合は、null値が返されます。

- getAllUserProperties() – 対応するユーザーに設定されているプロパティのみが返されます。

- getReportees()

- getManagementChain()

- getUserProfile() – 現在のオブジェクトへの参照を返します。

次の2つのメソッドに関する考慮事項:

- setProperty()

- setProperties()

これらのメソッドは、それぞれの実装で次をスローする必要があります。

oracle.security.idm.OperationNotSupportedException

22.10.3.8 oracle.security.idm.spi.AbstractSimpleSearchFilter

oracle.security.idm.spi.AbstractSimpleSearchFilterは、単純な検索フィルタを実装するために拡張できる抽象クラスです。

実装クラスには、抽象クラスのコンストラクタをコールする次のようなコンストラクタが必要です。

AbstractSimpleSearchFilter (
String attrname, int type, Object value)

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getNativeRepresentation() – 基礎となるアイデンティティ・リポジトリで使用するネイティブな表現にフィルタを変換します。

- getWildCardChar() – 検索で使用する*などのワイルド・カード文字。具体的な文字は、基礎となるアイデンティティ・リポジトリによって異なります。

22.10.3.9 oracle.security.idm.spi.AbstractComplexSearchFilter

oracle.security.idm.spi.AbstractComplexSearchFilterは、任意の複雑性を備えた検索フィルタを実装するために拡張できる抽象クラスです。

実装クラスには、抽象クラスのコンストラクタをコールする次のようなコンストラクタが必要です。

AbstractComplexSearchFilter (
oracle.security.idm.SearchFilter[] filters, int oper_type)

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getNativeRepresentation() – 基礎となるアイデンティティ・リポジトリで使用するネイティブな表現にフィルタを変換します。

22.10.3.10 oracle.security.idm.spi.AbstractSearchResponse

SearchResponseオブジェクトには、リポジトリから返された検索結果が格納されます。結果の各エントリは、基礎となるアイデンティティ・リポジトリにある1つのユーザーまたはロールに対応しており、対応するUserProfileクラスまたはRoleProfileクラスの実装によって表されます。

SearchResponseオブジェクトは、1つ以上の結果を返す必要があります。つまり、hasNext()メソッドは少なくとも1回はTRUEを返す必要があります。

返す結果がない場合は使用しないでください。結果が返されないと、対応する検索APIが次の例外をスローします。

oracle.security.idm.ObjectNotFoundException

22.10.4 フル機能プロバイダの開発

フル機能プロバイダでは、読取り専用プロバイダで使用できるすべての機能が実装され、さらにCRUD操作も使用できます。このため、CRUD APIをSPI実装クラスに実装する必要があります。

読取り専用プロバイダでは、OperationNotSupportedExceptionをスローするだけでこれらのAPIを実装しています(第22.10.3項「読取り専用プロバイダの開発」のクラスの説明を参照してください)。

フル機能プロバイダでは、対応するCRUD操作の具体的で実際の実装が必要になります。

22.10.5 開発のガイドライン

この項では、プロバイダ開発のためのいくつかのガイドラインを示します。

名前のマッピング

UserProfile.NAME、UNIQUE_NAME、UserProfile.USER_NAME、UserProfile.USER_IDなどの命名定数の使用に注意してください。

- NAME – 基礎となるリポジトリにあるユーザーまたはロールの名前

- UNIQUE_NAME – 基礎となるリポジトリにあるユーザーまたはロールを表すフルネーム

- USER_NAME – 基礎となるリポジトリにあるユーザーのログインID

- USER_ID – USER_NAME定数のマッピングと必ず同一

アイデンティティ・リポジトリによっては、これらの定数が、基礎となるアイデンティティ・リポジトリの同一の属性にマップされることもあれば、異なる属性にマップされることもあります。基礎となるリポジトリがLDAP v3サーバーの場合、マッピングは次のようになります。

- NAME – cnなど、ユーザー・エントリまたはグループ・エントリの命名属性にマップされます。

- UNIQUE_NAME - ユーザー・エントリまたはグループ・エントリのDNにマップされます。

- USER_NAME/USER_ID – uidやmailなどのログイン属性にマップされます。

スレッド・セーフティ

多くの場合、次のオブジェクトは複数のスレッドで共有されます。

- IdentityStoreFactory

- IdentityStore

- UserManager

- RoleManager

プロバイダの対応する実装クラスでスレッド・セーフティに関連する問題がないことを確認する必要があります。

22.10.6 テストと検証

ユーザーおよびロールAPIには、開発するプロバイダの基本操作をテストできるように、テスト・スイートが付属しています。

このテスト・スイートは、読取り専用プロバイダとフル機能プロバイダの両方のテストで使用できます。

使用方法

java oracle.security.idm.tests.SPITest propertiesfile

propertiesfileには、プロバイダ・クラス名とそのプロバイダのあらゆる構成データを格納します。また、実行するテストに関する情報も格納します。テストを実行する前に、このファイルを編集して、正しい情報で更新する必要があります。このファイルの内容は、見ればすぐわかるようになっています。このようなファイルの1つ(ffprovider.properties)を、第22.10.7.1項「サンプル・プロバイダについて」で説明しているサンプル・プロバイダで使用しています。

結果

テストによって画面に結果が表示されます。開発するすべてのプロバイダが、テスト・スイートのルックアップ・テスト、ロール・メンバーシップ・テストおよびプロファイル・テストに合格する必要があります。フル機能プロバイダは、作成と削除のテストなど、スイートにあるすべてのテストに合格する必要があります。

テスト結果のログは、現在の作業ディレクトリのresults.outファイルに出力されます。

22.10.7 例: アイデンティティ・プロバイダの実装

製品にはサンプルのアイデンティティ・プロバイダが付属しているので、それを使用してカスタム・プロバイダの作成方法を理解できます。

この項では、このサンプル・プロバイダにアクセスする方法と、カスタム・プロバイダを実装するために必要な手順について説明します。手順は、説明に使用するサンプルに依存します。

- サンプル・プロバイダについて

- 実装の概要

- サンプル・アイデンティティ・プロバイダの使用に向けたjps-config.xmlの構成

- Oracle WebLogic Serverの構成

22.10.7.1 サンプル・プロバイダについて

プロバイダの開発を支援するために、Oracle Technology Networkのサンプル・プロバイダを使用できます。このプロバイダを操作する手順は次のとおりです。

1. 次のサンプル・コンテンツ・ページへ移動します。
http://www.oracle.com/technetwork/testcontent/index.html

2. 検索ボックスで、sampleprovider-157582.zipを検索します。

3. ファイルをダウンロードし、解凍します。次の構造が生成されます。

sampleprovider/
build.xml - ant build file
ffprovider.properties - properties file required for testing
jlib - provider jar file location
out -  location of generated class files
samples - Folder for samples
src - provider source code

4. ant helpを実行すると、このプロバイダの作成とテストの手順を知ることができます。

このプロバイダは、非定型のアイデンティティ・リポジトリを使用してアイデンティティ情報をフェッチしており、Oracle SOA Suiteによるテストを完了しています。これは、実際の環境で適切なテストを実行せずに本番で使用することを意図したものではありません。

22.10.7.2 実装の概要

この例で使用するサンプルのアイデンティティ・プロバイダは、アイデンティティと認証のためのカスタム・プロバイダであり、基礎となるストアとしてRDBMSを使用しています。アイデンティティ・プロバイダおよび認証プロバイダの両方として使用できます。

注意:

このサンプル・プロバイダは説明のみを目的としたものなので、十分なテストを経ずに本番で使用することはお薦めしません。

このサンプル・プロバイダを設定するには、次の手順が必要です。

1. ユーザーおよびロールAPIを実装して、アイデンティティ・ストアとして機能するデータベース・リポジトリにアクセスします。これには、次の処理が必要です。

1. サンプル・プロバイダの作成。その手順を知るには、ant helpを実行します。

2. データベースへのアイデンティティ・ストア・スキーマの作成。

2. 第22.10.7.3項「サンプル・アイデンティティ・プロバイダの使用に向けたjps-config.xmlの構成」で示しているように、サンプル・プロバイダをアイデンティティ・ストアとして構成します。

3. 第22.10.7.4項「Oracle WebLogic Serverの構成」の説明に従って、このプロバイダをSQLAuthenticatorとして使用するようにWeblogic認証プロバイダを設定します。

22.10.7.3 サンプル・アイデンティティ・プロバイダの使用に向けたjps-config.xmlの構成

次のようにjps-config.xmlを構成して、サンプル・アイデンティティ・プロバイダをアイデンティティ・ストアとして使用できるようにします。

1. 次のように、サービス・プロバイダ・リストに新しいプロバイダを追加します。

<serviceProviders>
............
<serviceProvider type="IDENTITY_STORE" name="custom.provider"  class="oracle.security.jps.internal.idstore.generic.GenericIdentityStoreProvider">
<description>Custom IdStore Provider</description>
</serviceProvider>
</serviceProviders>

2. 次のように、サービス・インスタンスを追加します。

<serviceInstances>
........
<serviceInstance name="idstore.custom" provider="custom.provider"           location="dumb">
<description>Custom Identity Store Service Instance</description>
<property name="idstore.type" value="CUSTOM"/>
<property name="ADF_IM_FACTORY_CLASS"
value="custom_provider_identityStoreFactoryClassName"/>
<property name="DB_SERVER_NAME" value="db_server_name"/>                     <property name="DB_SERVER_PORT" value="db_port"/>
<property name="DB_DATABASE_NAME" value="db_service_name"/>
<property name="ST_SECURITY_PRINCIPAL" value="user_name"/>
<property name="ST_SECURITY_CREDENTIALS" value="password"/>
</serviceInstance>
........
<serviceInstances>

注意:

サンプル・プロバイダのcustom_provider_identityStoreFactoryClassNameは、org.sample.providers.db.DBIdentityStoreFactoryです。

3. 次のように、デフォルトのjpsContextが、前述のステップ2で追加したアイデンティティ・ストアのサービス・インスタンスを指すようにします。

<jpsContext name="default">
<serviceInstanceRef ref="credstore"/>
<serviceInstanceRef ref="keystore"/>
<serviceInstanceRef ref="policystore.xml"/>
<serviceInstanceRef ref="audit"/>
<serviceInstanceRef ref="idstore.custom"/>
</jpsContext>

4. カスタム・プロバイダのjarファイルのパスをクラスパスに追加します。

5. サーバーを再起動します。

22.10.7.4 Oracle WebLogic Serverの構成

最後のタスクとして、SQLAuthenticatorを使用するようにOracle WebLogic Serverを構成します。手順は次のとおりです。

1. Oracle WebLogic Serverコンソールにログインします。「セキュリティ・レルム」→「myrealm」→「プロバイダ」を選択します。「新規」をクリックして新しいプロバイダを追加します。

2. プロバイダの名前を入力し、認証タイプとして「SQLAuthenticator」を選択します。

3. 「プロバイダ」ページで、新規作成した認証プロバイダをクリックします。

4. 「制御フラグ」をSUFFICIENTに設定します。「保存」をクリックします。

5. リスト内のすべての認証プロバイダについて、制御フラグをsufficientに設定します。

6. 「プロバイダ固有」タブをクリックして、認証プロバイダのサーバーの詳細を入力します。プロバイダのスキーマの作成に使用したデータソース名を入力します。「保存」をクリックします。

7. 「プロバイダ」タブに戻り、SQLAuthenticatorがリストの最上位になるようにプロバイダの順序を並べ替えます。

ユーザーおよびロールSPIリファレンス

この項では、ユーザーおよびロールSPIリファレンス(Javadoc)を示し、パッケージ名security.idm.spiを持つSPIの各抽象クラスについて説明します。抽象クラスは次のとおりです。

- oracle.security.idm.spi.AbstractUserProfile

- oracle.security.idm.spi.AbstractUserManager

- oracle.security.idm.spi.AbstractUser

- oracle.security.idm.spi.AbstractSubjectParser

- oracle.security.idm.spi.AbstractStoreConfiguration

- oracle.security.idm.spi. AbstractSimpleSearchFilter

- oracle.security.idm.spi.AbstractSearchResponse

- oracle.security.idm.spi.AbstractRoleProfile

- oracle.security.idm.spi.AbstractRoleManager

- oracle.security.idm.spi.AbstractRole

- oracle.security.idm.spi.AbstractIdentityStoreFactory

- oracle.security.idm.spi.AbstractIdentityStore

- oracle.security.idm.spi.AbstractComplexSearchFilter

oracle.security.idm.spi.AbstractUserProfile

このクラスは詳細なユーザー・プロファイルです。このクラスを使用すると、ユーザー・プロファイルの属性を設定または取得できます。

コンストラクタ

public AbstractUserProfile()

メソッド

public void setPassword(  char[] oldPasswd,         char[] newPasswd)
public byte[] getUserCertificate()
public void setUserCertificate( byte[] cert)
public java.lang.String getEmployeeNumber()
public void setEmployeeNumber(  String employeeNumber)
public java.lang.String getBusinessPostalAddr()
public void setBusinessPostalAddr(      String addr)
public java.lang.String getBusinessPOBox()
public void setBusinessPOBox(   String pobox)
public byte[] getJPEGPhoto()
public void setJPEGPhoto(       String imgpath)
public java.lang.String getTimeZone()
public void setTimeZone(        String zone)
public java.lang.String getDescription()
public void setDescription(     String desc)
public java.lang.String getDepartmentNumber()
public void setDepartmentNumber(        String departmentnumber)
public java.lang.String getGivenName()
public void setGivenName(       String givenname)
public java.lang.String getBusinessEmail()
public void setBusinessEmail(   String email)
public java.lang.String getBusinessPager()
public void setBusinessPager(   String pager)
public java.lang.String getOrganization()
public void setOrganization(    String org)
public void setName(    String name)
public java.lang.String getBusinessCity()
public void setBusinessCity(    String city)
public java.lang.String getMaidenName()
public void setMaidenName(      String maidenname)
public java.lang.String getDepartment()
public void setDepartment(      String dept)
public java.lang.String getBusinessFax()
public void setBusinessFax(     String fax)
public java.lang.String getUserName()
public void setUserName(        String uname)
public java.lang.String getBusinessMobile()
public void setBusinessMobile(  String mobile)
public java.lang.String getDateofHire()
public void setDateofHire(      String hiredate)
public java.lang.String getTitle()
public void setTitle(   String title)
public java.lang.String getNameSuffix()
public void setNameSuffix(      String suffix)
public java.lang.String getMiddleName()
public void setMiddleName(      String middlename)
public java.lang.String getHomePhone()
public void setHomePhone(       String homephone)
public void setDisplayName(     String dispname)
public java.lang.String getEmployeeType()
public void setEmployeeType(    String emptype)
public java.lang.String getLastName()
public void setLastName(        String lastname)
public java.lang.String getDateofBirth()
public void setDateofBirth(     String dob)
public java.lang.String getManager()
public void setManager( String manager)
public java.lang.String getBusinessState()
public void setBusinessState(   String state)
public java.lang.String getHomeAddress()
public void setHomeAddress(     String homeaddr)
public java.lang.String getBusinessStreet()
public void setBusinessStreet(  String street)
public java.lang.String getBusinessPostalCode()
public void setBusinessPostalCode(      String postalcode)
public java.lang.String getInitials()
public void setInitials(        String initials)
public java.lang.String getUserID()
public void setUserID(  String userid)
public java.lang.String getFirstName()
public void setFirstName(       String firstname)
public java.lang.String getDefaultGroup()
public void setDefaultGroup(    String defgroup)
public java.lang.String getOrganiztionalUnit()
public void setOrganizationalUnit(      String ouUnit)
public java.lang.String getWirelessAcctNumber()
public void setWirelessAcctNumber(      String wirelessacct)
public java.lang.String getBusinessPhone()
public void setBusinessPhone(   String phone)
public java.lang.String getBusinessCountry()
public void setBusinessCountry( String country)
public java.lang.String getPreferredLanguage()
public void setPreferredLanguage(       String language)
public java.lang.String getUIAccessMode()
public void setUIAccessMode(    String accessMode)
public java.lang.Object getPropertyVal( String prop)
public oracle.security.idm.SearchResponse getReportees( boolean direct)
public java.util.List getManagementChain(       int max,        String upToManagerName,         String upToTitle)
public oracle.security.idm.PropertySet getAllUserProperties()

oracle.security.idm.spi.AbstractUserManager

このクラスはユーザー・マネージャであり、基本的な認証メソッドを備えています。

コンストラクタ

public AbstractUserManager()

メソッド

public oracle.security.idm.User authenticateUser(
String user_id, String authProperty, char[] passwd)

public oracle.security.idm.User authenticateUser(
User user, char[] passwd)

oracle.security.idm.spi.AbstractUser

このクラスはユーザーを表します。

コンストラクタ

public AbstractUser()

メソッド

なし

oracle.security.idm.spi.AbstractSubjectParser

この抽象クラスは、サブジェクト・パーサーのコンストラクタを提供します。

コンストラクタ

public AbstractSubjectParser()

メソッド

なし

oracle.security.idm.spi.AbstractStoreConfiguration

この抽象クラスは、アイデンティティ・ストア構成のコンストラクタを提供します。

コンストラクタ

public AbstractStoreConfiguration()

メソッド

なし

oracle.security.idm.spi.AbstractSimpleSearchFilter

この抽象クラスは、アイデンティティ・ストアの検索に使用できる単純な検索フィルタを表します。単純なフィルタはそれぞれ、検索属性、照合する演算子タイプおよび値で構成されます。検索結果は、この条件に基づいてフィルタ処理されます。このクラスは、基礎となる実際の表現(@link #getNativeRepresentation()メソッドで指定)が実装に固有なので、抽象クラスになっています。このメソッドの固有の実装を設定することによって、任意のサービス・プロバイダでこのクラスを拡張できます。

コンストラクタ

public AbstractSimpleSearchFilter(
String attrname, int type, Object value)

メソッド

表22-6は、AbstractSimpleSearchFilterのメソッドを示しています。

表22-6 AbstractSimpleSearchFilterのメソッド

メソッド

説明

public void setAttribute( String name)

属性名を設定します。

public void setType(int type)

フィルタ・タイプを設定します。

public void setValue(Object value)

属性値を設定します。

public java.lang.String getAttributeName()

属性名を取得します。

public java.lang.Object getValue()

属性値を取得します。

public int getType()

フィルタ・タイプを取得します。

public void setNegate()

検索フィルタの現在のNOT状態を否定します。切替えスイッチのように動作します。

public void negate()

検索フィルタの現在のNOT状態を否定します。切替えスイッチのように動作します。

public boolean isNegated()

検索フィルタの現在のNOT状態を返します。NOT演算子が設定されている場合はtrue、設定されていない場合はfalseを返します。

oracle.security.idm.spi.AbstractSearchResponse

これは、検索レスポンスの結果を表す抽象クラスです。

コンストラクタ

public AbstractSearchResponse()

メソッド

なし

oracle.security.idm.spi.AbstractRoleProfile

このクラスは、ロールの詳細なプロファイルを表します。

コンストラクタ

public AbstractRoleProfile()

メソッド

public oracle.security.idm.SearchResponse getManagers(
SearchFilter filter,    boolean direct)

public oracle.security.idm.SearchResponse getManagers(
SearchFilter filter)

public oracle.security.idm.SearchResponse getOwners(
SearchFilter filter, boolean direct)

public oracle.security.idm.SearchResponse getOwners(
SearchFilter filter)

public void addManager(
Principal principal)

public void removeManager(
Principal principal)

public void addOwner(
Principal principal)

public void removeOwner(
Principal principal)

public boolean isOwnedBy(
Principal principal)

public boolean isManagedBy(
Principal principal)

public void addOwner(
User user)

public void removeOwner(
User user)

public void setDisplayName(
String displayName)

public void setDescription(
String discription)

public java.lang.String getDescription()

public oracle.security.idm.Property getProperty(
String propName)

oracle.security.idm.spi.AbstractRoleManager

このクラスは、ロール・マネージャの抽象表現です。

コンストラクタ

public AbstractRoleManager()

メソッド

public boolean isOwnedBy(
Role role, Principal principal)

public boolean isManagedBy(
Role role, Principal principal)

public oracle.security.idm.SearchResponse getOwnedRoles(
Principal principal, boolean direct)

public oracle.security.idm.SearchResponse getManagedRoles(
Principal principal, boolean direct)

oracle.security.idm.spi.AbstractRole

このクラスは、ロールのコンストラクタを提供します。

コンストラクタ

public AbstractRole()

メソッド

なし

oracle.security.idm.spi.AbstractIdentityStoreFactory

このクラスは、アイデンティティ・ストア・ファクトリを表します。

関連項目:

表22-1の「IdentityStoreFactory」。

コンストラクタ

public AbstractIdentityStoreFactory()

メソッド

public oracle.security.idm.IdentityStore getIdentityStoreInstance()

oracle.security.idm.spi.AbstractIdentityStore

この抽象クラスは、アイデンティティ・ストアを表します。

コンストラクタ

public AbstractIdentityStore()

メソッド

public oracle.security.idm.RoleManager getRoleManager() public oracle.security.idm.UserManager getUserManager() public java.util.List getMandatoryUserPropertyNames() public java.util.List getUserPropertySchema()

oracle.security.idm.spi.AbstractComplexSearchFilter

このクラスは、複雑な検索フィルタを表します。このタイプの検索フィルタは、1つのブール型AND演算子またはOR演算子を使用して複数のSearchFilterインスタンスを結合する場合に使用します。構成要素となる各検索フィルタ自体に複雑なフィルタを使用できるので、複雑性の高いネストした検索フィルタの作成が可能です。

このクラスは、基礎となる実際の表現(@link #getNativeRepresentation()メソッドで指定)が実装に固有なので、抽象クラスになっています。

このメソッドの固有の実装を作成することによって、任意のサービス・プロバイダでこのクラスを拡張できます。

関連項目:

"oracle.security.idm.spi. AbstractSimpleSearchFilter"

コンストラクタ

public AbstractComplexSearchFilter(       SearchFilter[] filters,   int oper_type)

メソッド

表22-7 複雑な検索フィルタのメソッド

メソッド

説明

public void addFilterComponent( SearchFilter filter)

この複雑なフィルタのリストに、構成要素であるSearchFilterを追加します。

public void setNegate()

検索フィルタの現在のNOT状態を否定します。切替えスイッチのように動作します。

public void negate()

検索フィルタの現在のNOT状態を否定します。切替えスイッチのように動作します。

public boolean isNegated()

検索フィルタの現在のNOT状態を返します。NOT演算子が設定されている場合はtrue、設定されていない場合はfalseを返します。

public int getOperatorType()

複数のSearchFilterを結合する論理演算子タイプ。

23 アイデンティティ・ディレクトリAPIを使用した開発

この章では、アイデンティティ・ディレクトリAPIを使用して、アイデンティティ・ストアにアクセスして操作する方法について説明します。

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

- 第23.1項「アイデンティティ・ディレクトリAPIについて」

- 第23.2項「クラスの概要」

- 第23.3項「アイデンティティ・ディレクトリの構成」

- 第23.4項「アイデンティティ・ディレクトリAPIの操作」

- 第23.5項「アイデンティティ・ディレクトリAPIの例」

- 第23.6項「SSLの構成」

23.1 アイデンティティ・ディレクトリAPIについて

アイデンティティ・ディレクトリAPIを使用すると、アプリケーションは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報(ユーザーやその他のエンティティ)にアクセスすることができます。

アイデンティティ・ディレクトリAPIの特徴:

- 柔軟性が高い

- 標準スキーマおよび特定のスキーマを持つ様々なアイデンティティ・ストアをサポートし、クライアントによって完全に構成可能

- ユーザーおよびグループの取得と管理をサポートする

- 拡張可能であり、新しいエンティティ・タイプおよびそれらのエンティティ間の関係の定義をサポートする

- 堅牢であり、高可用性/フェイルオーバー・サポートを提供する

アイデンティティ・ディレクトリAPIはIdentity Governance Frameworkを使用し、このフレームワークのすべての利点を提供することにより、個人情報(PII)、アクセス権限、属性およびその他のエンティティなどのアイデンティティ関連の情報が使用および格納され、組織間で伝播される方法を制御することを可能にします。

23.1.1 機能の概要

この項では、アイデンティティ・ディレクトリAPIによってサポートされている機能について説明します。

ユーザー・エンティティに対する機能

ユーザーに対して次の機能がサポートされています。

- ユーザーに対する作成、読取り、更新、削除(CRUD)の操作の実行

- 次の手順を実行します。

- ユーザー属性の取得と設定

- アイデンティティ・ストアのネイティブ認証メカニズムでのユーザーの認証

- ユーザーが属するグループの取得(オプションで、ネストされたグループも含む)

- グループのメンバーとしてのユーザーの追加

- ユーザー・パスワードの変更

- ユーザー・パスワードの変更の強制

- ユーザー状態(有効/無効、ロックアウト、パスワード変更が必要)の取得と設定

グループ・エンティティに対する機能

グループに対して次の機能がサポートされています。

- グループに対するCRUD操作の実行

- 次の手順を実行します。

- 属性の取得と設定

- グループのメンバーの取得と検索

- グループが属するグループの取得(オプションで、ネストされたグループも含む)

- グループが別のグループのメンバーであるかどうかの判別

- 複数の値を持つ属性のサポート

- 静的グループおよび動的グループのサポート

23.2 クラスの概要

表23-1に、アイデンティティ・ディレクトリAPIのクラスをリストします。

表23-1 アイデンティティ・ディレクトリAPIのクラス

クラス

説明

Capabilities

エンティティの機能を含みます。

CreateOptions

エンティティ作成操作に対するオプションを含みます。

DeleteOptions

エンティティ削除操作に対するオプションを含みます。

Entity

検索または読取りメソッドを使用してフェッチされたエンティティの属性リストを格納する汎用エンティティ・クラス。

EntityAlreadyExistsException

既存のエンティティの作成を試みると返されます。

EntityCapabilities

EntityManager

汎用エンティティの読取り、作成、検索などの操作を処理します。

EntityNotFoundException

リクエストされたエンティティが見つからない場合に返されます。

EntityNotUniqueException

エンティティが一意に定義されていない場合に返されます。

EntityRelationManager

関係の読取り、作成、削除、検索などのエンティティ関係操作を処理します。

Group

グループのメンバー・リストを格納する汎用エンティティ・クラス。グループ・メンバーシップを変更するメソッドも提供します。

GroupManager

グループの作成、削除、検索などの操作を処理します。

IDSException

例外を処理します。

IDSPrincipal

例外に関連するプリンシパルを含みます。

IdentityDirectory

IdentityDirectoryインスタンスを作成するためのIdentityDirectoryへのハンドルを表します。

対応するエンティティに対する操作を実行できるように、インスタンスはUser、Groupおよび汎用エンティティ・マネージャのハンドルを提供します。

IdentityDirectoryFactory

IdentityDirectoryServiceを作成するためのファクトリ・クラス。

IdentityDirectoryInfo

InvalidAttributesException

無効なエンティティ属性に関連する例外に使用されます。

InvalidFilterException

アイデンティティBean内で生成された例外に使用されます。

ModAttribute

ModifyOptions

エンティティ変更操作に対するオプションを含み、OperationOptionsを拡張します。

OperationNotSupportedException

アイデンティティBean内で生成された例外に使用されます。

ReadOptions

エンティティ読取り操作に対するオプションを含み、OperationOptionsを拡張します。読取りオプションにはLocaleおよびRequested Attributes設定が含まれます。

ResultSet

ページングの結果との検索相互作用により返されるオブジェクトに対するインタフェース。

SearchFilter

エンティティを検索するための簡易検索フィルタまたは複雑なネストされた検索フィルタを作成するために使用されます。

SearchOptions

エンティティ検索操作に対するオプションを含み、ReadOptionsを拡張します。

User

ユーザー・エンティティに対する汎用クラス。

UserCapabilities

ユーザー機能属性を含みます。

UserManager

様々な基準によりユーザーを作成、削除、検索するためのメソッドを含みます。

23.3 アイデンティティ・ディレクトリの構成

アイデンティティ・ディレクトリの構成は、論理的なエンティティ構成と物理的なアイデンティティ・ストア構成の組合せになります。

論理エンティティ構成を使用するアイデンティティ・ディレクトリは次の場所に格納されています。

DOMAIN_HOME/config/fmwconfig/ids-config.xml

デフォルトのアイデンティティ・ディレクトリに対する物理的なアイデンティティ・ストア構成は次の場所にあります。

DOMAIN_HOME/config/fmwconfig/ovd/default

デフォルトのアイデンティティ・ディレクトリでは、OPSS (WebLogic認証プロバイダまたはjps-config.xml)で構成されているものと同じアイデンティティ・ストア・プロパティ(つまり、ホスト、ポート、資格証明、検索ベース、作成ベース、名前属性など)が使用されます。詳細は、第F.2.3項「LDAPアイデンティティ・ストアのプロパティ」を参照してください。

23.4 アイデンティティ・ディレクトリAPIの操作

この項では、アプリケーションがアイデンティティ・ディレクトリAPIを使用して、アイデンティティ・ストア・データを表示および管理する方法について説明します。次のセクションが含まれます:

- アイデンティティ・ディレクトリAPIインスタンスの取得

- ユーザーとグループに対するCRUD操作の実行

23.4.1 アイデンティティ・ディレクトリAPIインスタンスの取得

次のように、jps-contextからアイデンティティ・ディレクトリ・ハンドルを取得し、ディレクトリ・インスタンスを取得できます。

JpsContextFactory ctxFactory = JpsContextFactory.getContextFactory();
JpsContext ctx = ctxFactory.getContext();

//find the JPS IdentityStore service instance
IdentityStoreService idstoreService =   ctx.getServiceInstance(IdentityStoreService.class)

//get the Identity Directory instance
oracle.igf.ids.IdentityDirectory ids = idstoreService.getIdentityStore();

23.4.2 ユーザーとグループに対するCRUD操作の実行

ユーザーとグループに対して、作成、取得、更新および削除(CRUD)操作を実行できます。

- ユーザー操作

- グループ操作

23.4.2.1 ユーザー操作

ユーザーに対する基本的なCRUD操作は次のとおりです。

ユーザーの作成

Principal UserManager.createUser(List<Attribute> attrVals, CreateOptions opts)

ユーザーの取得

User UserManager.getUser(Principal principal, ReadOptions opts)

ユーザーの検索

User UserManager.searchUser(String id, ReadOptions opts)

ユーザーの削除

void UserManager.deleteUser(String id, DeleteOtions opts)

ユーザーの更新

void UserManager.modify(List<ModAttribute> attrVals, ModifyOptions opts)

ユーザー・リストの取得

ResultSet UserManager.searchUsers(SearchFilter filter, SearchOptions opts)

23.4.2.2 グループ操作

グループに対する基本的なCRUD操作は次のとおりです。

グループの作成

Principal GroupManager.createGroup(List<Attribute> attrVals, CreateOptions opts)

グループの取得

User GroupManager.getGroup(Principal principal, ReadOptions opts)

グループの検索

User GroupManager.searchGroup(String id, ReadOptions opts)

グループの削除

void GroupManager.deleteGroup(String id, DeleteOtions opts)

グループ属性の変更

void GroupManager.modify(List<ModAttribute> attrVals, ModifyOptions opts)

グループ・リストの取得

ResultSet GroupManager.searchGroups(SearchFilter filter, SearchOptions opts)

23.5 アイデンティティ・ディレクトリAPIの例

この項では、次のアイデンティティ・ディレクトリAPIの使用例を紹介します。

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

- ユーザーの作成

- ユーザーの取得

- ユーザーの変更

- ユーザーの簡易検索

- ユーザーの複合検索

- グループの作成

- グループの取得

- 検索フィルタを使用したグループの取得

- グループの削除

- グループへのメンバーの追加

- グループからのメンバーの削除

関連項目:

第19.1項「Java SEアプリケーションでのOPSSの使用」のOPSSを使用したJava SEアプリケーションの保護の詳細。

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

このサンプル・コードでは、アイデンティティ・ディレクトリへのハンドルを初期化して取得します。

/**
* This is a sample program for initializing Identity Directory Service with the configuration
* that is already persisted in IDS config location.
* Basic User and Group CRUDS are performed using this IDS instance
*/

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;

/**
* Get Identity Store Service
*/
public Ids1Test() throws IDSException {

// Set Operational Config
OperationalConfig opConfig = new OperationalConfig();

// Set the application credentials: this overrides the credentials
// set in physical ID store configuration
//opConfig.setApplicationUser("cn=test_user1,l=amer,dc=example,dc=com");
//opConfig.setApplicationPassword("welcome123".toCharArray());

// 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.getDefaultIdentityDirectory(opConfig);
ids = factory.getIdentityDirectory("userrole", opConfig);

// Get UserManager and GroupManager handles
uMgr = ids.getUserManager();
gMgr = ids.getGroupManager();
}

23.5.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"));
// Adding locale specific value
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;
}

23.5.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;
}

23.5.4 ユーザーの変更

このサンプル・コードでは、新しいユーザー属性を追加することにより既存のユーザーを変更します。

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();
}
}

23.5.5 ユーザーの簡易検索

このサンプル・コードでは、基本的なユーザー検索を実行します。

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();
}
}

23.5.6 ユーザーの複合検索

このサンプル・コードでは、複合検索フィルタを使用して一致するユーザーを返します。

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")));

// Requesting 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();
//printEntity(user);
//System.out.println(" ");
System.out.println(user.getSubjectName());
System.out.println("    " + user.getAttributeValue("commonname"));
}

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

23.5.7 グループの作成

このサンプル・コードではグループを作成します。

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;
}

23.5.8 グループの取得

このサンプル・コードでは特定のグループを返します。

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;
}

23.5.9 検索フィルタを使用したグループの取得

このサンプル・コードでは、検索フィルタを使用してグループを返します。

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();
}
}

23.5.10 グループの削除

このサンプル・コードでは、ストアからグループを削除します。

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();
}
}

23.5.11 グループへのメンバーの追加

このサンプル・コードでは、グループにメンバーを追加します。

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();
}
}

23.5.12 グループからのメンバーの削除

このサンプル・コードでは、グループからメンバーを削除します。

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();
}
}

23.6 SSL構成

アイデンティティ・ディレクトリAPIの使用時のSSL構成の詳細は、第8.5項「アイデンティティ・ストア・サービスでのSSLの使用」を参照してください。

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

この章では、アプリケーションの開発時にキーストア・サービスを利用する方法について説明します。

この章では、キーストア・サービスAPIの概説に始まり、アプリケーションでサービスを呼び出す際の必知事項を記載し、サービスの構成方法を説明し、一般的なキーストア操作の例および実行時のキーの取得方法を示します。

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

- 第24.1項「キーストア・サービスAPIについて」

- 第24.2項「キーストア・サービスを使用したアプリケーション開発の概要」

- 第24.3項「Javaセキュリティ・ポリシーのパーミッションの設定」

- 第24.4項「キーストア・サービスの構成」

- 第24.5項「キーストア・サービスAPIの使用」

- 第24.6項「キーストア・サービスAPIの使用例」

- 第24.7項「ベスト・プラクティス」

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

キーストアは、キーおよび証明書の安全な格納とアクセスに使用します。キーストア・サービスAPIは、キーストアにアクセスして操作を実行するために使用します。

キーストア・サービスの特徴

- キーおよび証明書の安全な管理を可能にします。

- 各種バックエンド・リポジトリでのキーおよび証明書の格納、取得および管理のためのAPIを提供します。

- ファイルベース、データベース・ベースおよびLDAPベースのキーストア管理をサポートします。

キーストア・サービスAPIは、次のような重要な機能(作成、更新、削除)を提供します。

- キーストアの作成

- キーストアの削除

- ドメイン・トラスト・ストアへのハンドルの取得

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

- キーストアに対する構成済のプロパティの取得

- アプリケーション・ストライプ内のキーストアのリストの取得

KeyStoreに対する操作は、キーストア・サービスで使用されるファイングレイン・アクセス制御モデルを実装するKeyStoreAccessPermissionによって保護されます。

関連項目:

- 第12章「キーストア・サービスでのキーと証明書の管理」

24.2 キーストア・サービスを使用したアプリケーション開発の概要

アプリケーションがキーストア・サービスと連携するように設計するうえで、次の項目に関する知識が役立ちます。

- 使用する適切なアプリケーション・ストライプとキーストア名の決定。

- Javaセキュリティ・ポリシーのプロビジョニング。
ポリシー・パーミッションは、ファイルベース(system-jazn-data.xml)またはLDAPベースのポリシー・ストアに設定されます。データのセキュリティを損なわずにアプリケーションの使用を可能にする適切なパーミッションを設定するには、十分な配慮が必要です。

関連項目:

第10.1項「ポリシー・ストアの管理」

- jps-config.xmlでのキーストア・サービスの定義。
jps-config.xmlでのサービス・インスタンスの定義は、構成ファイルをマニュアルで作成する場合のみ必要です。

注意:

デフォルトでは、ファイルベースのプロバイダが構成されており、これはLDAPベースのプロバイダに変更することができます。第9.6項「OPSSセキュリティ・ストアの移行」を参照してください。

- 環境の設定手順。
スタンドアロン・アプリケーションの場合と、Oracle WebLogic Server環境で動作するアプリケーションの場合は手順が異なります。

24.3 Javaセキュリティ・ポリシーのパーミッションの設定

Oracle Platform Security Servicesキーストア・プロバイダは、サーバーの起動時に設定されます。プロバイダがファイルベースの場合、データはsystem-jazn-data.xmlに格納されます。

キーストア・サービスでは、次のレベルでのキーの保護をサポートしています。

- アプリケーション・ストライプ・レベル

- キーストア・レベル

- 特定の<application stripe, keystore, key>に対するきめ細やかな保護

注意:

- キーストア・サービスAPIに適切にアクセスするには、ポリシー・ストアでJavaパーミッションを付与する必要があります。

- キーストア・サービスAPIを呼び出すコードには、コード・ソースのパーミッションが必要です。パーミッションは通常、特定のコードjarに与えられるものであり、アプリケーション全体には与えられません。

この項では、キーストア・オブジェクトへのパーミッションの付与に関するガイドラインおよびいくつかの例を紹介します。

- パーミッション付与のガイドライン

- パーミッション付与例1

- パーミッション付与例2

- パーミッション付与例3

注意:

この例では、アプリケーションのjarファイル名はAppName.jarです。

24.3.1 パーミッション付与のガイドライン

キーストア・サービスでは、Javaパーミッションを使用して、キーストアまたはキー・オブジェクトにパーミッションを付与します。必要なパーミッションのみを付与して、それ以外は付与しないことを強くお薦めします。

警告:

不要なパーミッション、特にすべてのアプリケーション・ストライプやキーストアにアクセスできるパーミッションを付与することは危険であり、お薦めできません。

24.3.2 パーミッション付与例1

キーストア・サービスでは、オブジェクトは階層に格納されます。

アプリケーション・ストライプ -> キーストア -> キー/証明書

関連項目:

キーストア・サービスのオブジェクト階層の詳細は、第12.1.1項を参照してください。

この例では、特定のアプリケーション・ストライプおよびそのストライプ内の特定のキーストア名に対するパーミッションを付与します。

<jazn-policy>
<grant>
<grantee>
<principals>...</principals>
<!-- This is the location of the jar -->
<!-- as loaded with the run-time -->
<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はキーストア内のキー別名を示します。

注意:

ワイルドカードは、すべての別名に対するパーミッションがアプリケーションに付与されることを意味します。

24.3.3 パーミッション付与例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>
<!-- Certain actions are explicitly specified -->
<!-- Compare to wild-card grant in previous example -->
<actions>read,write,update,delete</actions>
</permission>
</permissions>
</grant>
</jazn-policy>

24.3.4 パーミッション付与例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>

24.4 キーストア・サービスの構成

キーストアの場所とプロバイダ・クラスに関する情報が含まれている構成ファイル内で、キーストア・サービス・インスタンスを定義する必要があります。構成ファイルは、次の場所にあります。

$DOMAIN_HOME/config/fmwconfig

名前は次のとおりです。

- jps-config.xml (Oracle WebLogic Serverの場合)

- jps-config-jse.xml (Java SEの場合)

関連項目:

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

24.5 キーストア・サービスAPIの使用

キーストア・サービスは、Oracle WebLogic Server内またはスタンドアロン環境で使用できます。

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

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

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

関連項目:

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

Java SEアプリケーションでキーストア・サービスAPIを使用するには、次の手順を実行します。

1. クラスパスを設定します。jps-manifest.jarファイルがそのクラスパスに入っていることを確認します。詳細は、第1.5.3項「シナリオ3: Java SEアプリケーションの保護」の「クラスパスで指定する必要のあるJAR」を参照してください。

2. ポリシーを設定します。キーストア・サービスAPIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第24.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. JVMコマンド・オプションを設定します。詳細は、次を参照してください。

4. アプリケーションを実行します。

コマンドライン・オプションは次のとおりです。

- -Doracle.security.jps.config

構成ファイルjps-config.xmlへのフル・パスを指定します。通常、domain_home/config/fmwconfigディレクトリに存在します。

- -Djava.security.policy

OPSS/Oracle WebLogic Serverポリシー・ファイルweblogic.policyの場所を指定します。通常、wl_home/server/libディレクトリに存在します。

- -Dcommon.components.home

Middlewareホームの下にあるoracle_commonディレクトリの場所を指定します。

- -Djrf.version

環境で使用されるバージョンの値、11.1.1を指定します。

- -Djava.security.debug=all

デバッグに役立ちます。

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

Java EEアプリケーションでAPIを使用するには、次の手順を実行します。

1. 出荷時、jps-config.xmlファイルのキーストア・サービス・プロバイダ・セクションは、次のディレクトリに構成されています。

$DOMAIN_HOME/config/fmwconfig

必要に応じて、LDAPストアまたはデータベース・ストアへの再関連付けを行ってください。

2. ポリシーを設定します。キーストア・サービスAPIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第24.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. Oracle WebLogic Serverを起動します。

4. アプリケーションをデプロイしてテストします。

24.6 キーストア・サービスAPIの使用例

この項では、キーストア・サービスAPIの使用例を紹介します。内容は次のとおりです。

- キーストア・サービス管理操作用のJavaプログラム

- 実行時のキーの読取り

- ポリシー・ストアのセットアップ

- 構成ファイル

- Java SE環境でのキーストア・サービスの使用について

関連項目:

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

24.6.1 キーストア・サービス管理操作用のJavaプログラム

次のJavaコードは、一般的なキーストア・サービス操作を示しています。

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();
}

/*
* Since 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);

// #1 - this call is in a doPrivileged block
// #1 - this should succeed.
doPrivilegedKeyStoreOperation();

// #2 - this will also pass since granted all application
// code necessary permission
// NOTE: Since this call is not in a doPrivileged block,
// this call would have failed if KeyStoreAccessPermission
// wasn't granted to this class.

/*
doKeyStoreOperation();
*/

} catch (JpsException je) {
je.printStackTrace();
}

}
}

関連項目:

http://docs.oracle.com/javase/6/docs/api/index.htmlにあるキーストアAPIのドキュメント

24.6.2 実行時のキーの読取り

この項では、アプリケーションが実行時にキーストア・アーティファクトにアクセスする方法について説明します。内容は次のとおりです。

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

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

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

24.6.2.1 キーストア・ハンドルの取得

実行時にキーストアにアクセスしてキーと証明書を取得するには、アプリケーションは最初に、キーストア・サービスからキーストア・ハンドルを取得する必要があります。

このタスクの方法は2つあります。

1. アプリケーション・ストライプおよびキーストア名を個別のパラメータとして明示的に指定し、ハンドルを取得

2. アプリケーション・ストライプおよびキーストア名を1つのパラメータとして指定し、ハンドルを取得

アプリケーションはいずれのメソッドも自由に使用できます。いずれのメソッドも、まったく同じ方法でキーおよび証明書を取得する動作をします。唯一の相違はキーストアのロード方法です。メソッド1ではOPSS APIを使用するのに対して、メソッド2ではJDKキーストアAPIを使用します。

24.6.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. There are two ways to
// do this:
// Method 1: Explicitly specify application stripe and keystore name as
// separate parameters. In this example, the last parameter is null since
// we are demonstrating a permission-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.
// Since we are demonstrating Method 1 in this
// example, method 2 is commented out

// java.security.KeyStore keyStore kss.getKeyStore("kss://keystoreapp/ks1", null);

// Now you have a handle to the JDK KeyStore object. Use this handle to get
// key(s) and/or certificate(s)

// Get the private key or secret key associated with this alias. Pass the
// key password as the second parameter. In this case, it is null due to
// permission protected keystore.

Key key = keyStore.getKey("key-alias", null);

// Get the certificate associated with this alias

Certificate cert = keyStore.getCertificate("cert-alias");

注意:

次のコードの一部には示されていませんが、load、getKey、getCertへのコールはすべて権限のある操作で、このためdoPrivileged()ブロックでラップする必要があります。

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

次の例では、JDKキーストアURIを使用した、アプリケーション・ストライプおよびキーストア名が1つのパラメータとして指定されるメソッドを示します。

// Create an object with parameters indicating the keystore to be loaded
FarmKeyStoreLoadStoreParameter param = new FarmKeyStoreLoadStoreParameter();
param.setAppStripeName("keystoreapp");
param.setKeyStoreName("ks1");
// The password is set to null in this example since 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. Since 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 or secret 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()ブロックでラップする必要があります。

24.6.3 ポリシー・ストアのセットアップ

関連項目:

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

この例では、ストアから特定のキーストアへのアクセスに必要とされる適切なパーミッションを持つXMLベースのポリシー・ストア・ファイル(system-jazn-data.xml)を使用して説明しています。このファイルでは、アプリケーション・ストライプとキーストア名の様々な組合せに対するパーミッションを定義します。他の組合せや、ここで定義されたパーミッションを超えたストアへのアクセスは、許可されません。

注意:

この権限付与は、
$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlのデフォルトのポリシー・ストアに追加されます。

ここでは、システム・プロパティ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.keystore.KeyStoreAccessPermission
</class>
<name>stripeName=keystoreapp,keystoreName=ks1,alias=*</name>
<actions>*</actions>
</permission>
</permissions>
</grant>

24.6.4 構成ファイル

サンプル構成ファイル(jps-config-jse.xml)を示します。キーストア・サービスのkeystore.file.pathプロパティは、keystores.xmlファイルを含むディレクトリを示しています。

注意:

完全な構成ファイルについては、製品に付属しているデフォルトのファイル($DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml)を参照してください。

<jpsConfig>
...
<serviceInstances>
<serviceInstance name="keystore_file_instance"
provider="keystore_file_provider">
<property name="keystore.file.path" value="store" />
<property name="keystore.provider.type" value="file" />
</serviceInstance>
</serviceInstances>
...
</jpsConfig>

24.6.5 Java SE環境でのキーストア・サービスの使用について

Java SE環境では、次の2つのコールは同等です。

KeyStoreService store = JpsServiceLocator.getServiceLocator().lookup(KeyStoreService.class);

および

KeyStoreService store = JpsContextFactory.getContextFactory().getContext().getServiceInstance
(KeyStoreService.class);

関連項目:

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

24.7 ベスト・プラクティス

クラスタ環境でストアがファイルベースの場合は、キーストア・サービスAPI上でキーストア・サービスMBean APIを使用して、アプリケーションに対するキーの作成、取得、更新および削除を行います。

ただし、単にキーを読み取るだけの場合は、いずれのAPIも使用できます。

25 監査サービスを使用した開発

この章では、アプリケーションがOracle Fusion Middleware監査フレームワークを使用して監査機能を提供する方法について説明します。

Oracle Fusion Middleware監査フレームワークには、監査サービスが含まれ、このサービスは、アプリケーションをプログラム的に監査フレームワークに統合することにより、Oracleコンポーネントで使用可能な機能を使用して、監査イベントをログに記録し、コンプライアンス・レポートを生成することを可能にします。

監査サービスを使用して、アプリケーション(監査クライアントとも呼ばれます)は次のことを行えます。

- カスタム表を使用せずにイベント定義を作成する

- アプリケーションのデプロイ時に監査サービスに登録する

- アプリケーションの再デプロイ時にイベント定義を変更する

- 実行時に監査構成設定を変更する

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

- 第25.1項「監査フローへのアプリケーションの統合」

- 第25.2項「監査フレームワークへのアプリケーションの統合」

- 第25.3項「監査定義ファイルの作成」

- 第25.4項「登録サービスへのアプリケーションの登録」

- 第25.5項「管理サービスAPIの使用」

- 第25.6項「監査イベントを記録するためのアプリケーション・コードの追加」

- 第25.7項「監査定義の更新と保守」

関連項目:

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

25.1 監査フローへのアプリケーションの統合

図25-1に示すように、Oracle WebLogic Server上で動作するJava EEアプリケーションは、シームレスに監査フレームワークに統合でき、それを活用できます。

図25-1 監査フレームワークへのアプリケーションの統合

アプリケーションのデプロイメント時または監査サービスの起動時に、Java EEアプリケーションまたはOracleコンポーネントなどのクライアントが監査サービスに登録されます。登録サービスは、component_events.xmlおよび関連ファイルに含まれる最新の監査定義でメタデータ・ストアを更新します。

関連項目:

監査フローの詳細は、第13.3項を参照してください。

この章の残りの項では、アプリケーションを監査フローに統合することにより監査イベントを記録して監査レポートを作成する方法について説明します。

25.2 監査フレームワークへのアプリケーションの統合

アプリケーションを監査フレームワークに統合するには、次の手順を実行します。

1. 監査定義ファイルcomponent_events.xmlを作成します。

2. アプリケーションのEARファイルにcomponent_events.xmlファイルおよびcomponent_events_xlf.jarをパッケージ化します。

3. 監査イベントを記録できるように、監査イベントAPIをアプリケーション・コードに追加します。

4. レポート用にOracle Business Intelligence Publisherなどのレポート作成ツールを統合します。

5. 監査イベント定義を更新し、必要に応じて再デプロイします。

次の各項では、これらのタスクについて詳しく説明します。

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

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

- 監査イベントを記録するためのアプリケーション・コードの追加

- 監査定義の更新と保守

関連項目:

監査アーティファクトを処理する代替のテンプレート・モードについては、第7章を参照してください。

25.3 監査定義ファイルの作成

このタスクでは、次のファイルを作成します。

- component_events.xmlファイル

- 翻訳ファイル

component_events.xmlファイル

アプリケーションで使用する監査定義component_events.xmlファイルを作成します。

component_events.xmlファイル作成の詳細およびファイルの例は、第13.5.1項を参照してください。

監査定義ファイルの作成時には、アプリケーションに対する監査メタデータの作成時に登録サービスが使用する特定のルールについて理解する必要があります。次のものがあります。

- バージョン番号。監査イベント定義を変更した場合は、マイナーまたはメジャー番号あるいはその両方を変更することによりバージョンIDを変更する必要があります。
バージョニングの詳細は、第13.5.3.1項を参照してください。

- アプリケーションの属性定義とデータベース列間で一意なマッピングを行うための属性マッピング表。各カスタム属性定義には、マッピング順序番号が含まれている必要があります。
属性マッピングの詳細は、第13.5.3.2項を参照してください。

翻訳ファイル

アプリケーションに必要な翻訳ファイルを作成します。

ファイルはXLIFF形式で生成し、component_events_xlf.jarに保管します。登録時に、この情報はコンポーネント監査イベント定義とともに監査メタデータ・ストアに格納されます。

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

Java EEアプリケーションは、component_events.xmlとcomponent_events_xlf.jarを、アプリケーションEARファイルのMETA-INFフォルダにパッケージ化することにより登録できます。監査登録サービスはアプリケーションのデプロイ時にそれらを自動的に処理します。

注意:

ファイル名はそれぞれ、component_events.xmlおよびcomponent_events_xlf.jarとする必要があります。

このセクションでは、アプリケーションの監査サービスへの登録を可能にする、次の様々なメカニズムについて説明します。

- デフォルトのアプリケーション監査登録

- カスタム・アプリケーション監査登録

- プログラム登録

25.4.1 デフォルトのアプリケーション監査登録

アプリケーションをデプロイ、再デプロイまたはアンデプロイする際に、次の登録アクティビティがデフォルトで発生します。

- デプロイ - アプリケーションがまだ登録されていなければ、監査イベント定義を監査メタデータ・ストアに登録します。

- 再デプロイ - コンポーネントがすでに登録済であれば、コンポーネントの監査イベント定義をアップグレードします。詳細は13.5.3.1項を参照してください。

- アンデプロイ - アプリケーションの監査イベント定義を監査メタデータ・ストアから削除します。

25.4.2 カスタム・アプリケーション監査登録

カスタム監査登録パラメータは、WebLogicデプロイメント・ディスクリプタweblogic-application.xmlで設定されます。これもアプリケーションEARファイルのMETA-INFフォルダにパッケージ化されます。

表25-1に、パラメータとそのオプションを示します。

表25-1 監査登録サービスのパラメータ

パラメータ

オプション

説明

opss.audit.registration

OVERWRITE

登録されているかどうかにかかわらず、コンポーネント監査定義を登録します。

UPGRADE (デフォルト・オプション)

バージョニングのサポートに応じてコンポーネント監査定義を登録します。

DISABLE

コンポーネント監査定義を登録しません。

opss.audit.deregistration

DELETE(デフォルト・オプション)

アプリケーションのアンデプロイ時に、コンポーネント監査定義を監査ストアから削除します。

DISABLE

アプリケーションのアンデプロイ時に、コンポーネント監査定義を監査ストアに残します。

opss.audit.componentType

カスタム・コンポーネント・タイプを設定します。(オプション)

weblogic-application.xmlの例

次のweblogic-application.xmlファイルのサンプルは、登録オプションおよび登録解除オプションの使用を示しています。

<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>

25.4.3 プログラム登録

監査登録サービスをプログラムで呼び出して、アプリケーションを監査サービスに登録できます。登録のロジックは次のとおりです。

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の作成アクションおよびアップグレード・アクションの権限を付与されていることが必要です。権限付与の設定の詳細は、第25.6.2項を参照してください。

次に、プログラムにより監査サービスを登録する例を示します。

//
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 audit service API to register audit event definition
AccessController.doPrivileged(new PrivilegedExceptionAction<Object>() {
public Object run() throws AuditException, IOException {
auditService.register(auditReg);
return null;
}
});

25.5 管理サービスAPIの使用

監査フレームワークの監査管理サービス(管理サービス)によりAPIのセットが提供され、監査メタデータの問合せおよび監査ランタイム・ポリシーの取得、設定に使用されます。管理サービスは次のように呼び出されます。

AuditService auditService = JpsContextFactory.getContextFactory().getContext().getServiceInstance(AuditService.class);
AuditAdminService auditAdminService = auditService.getAdminService();

この項では、管理サービスAPIの使用方法を説明します。

- 監査メタデータの問合せ

- 監査ランタイム・ポリシーの表示と設定

25.5.1 監査メタデータの問合せ

監査メタデータに問合せをするAPIは次のとおりです。

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;

次の例では、監査メタデータの問合せにAPIを使用する方法を示します。

//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();

}
}
}

25.5.2 監査ランタイム・ポリシーの表示と設定

監査ランタイム・ポリシーを取得し、設定するAPIは次のとおりです。

AuditPolicy getAuditPolicy(String componentType) throws AuditException;

void setAuditPolicy(String componentType, AuditPolicy auditPolicy) throws AuditException;

次の例では、コンポーネントの監査ポリシーを取得してから設定するAPIを使用する方法を示します。

//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("All", null, null);
//setAuditPolicy() requires AuditStoreAccessPermission(<componentType>, "modify");
AccessController.doPrivileged(new PrivilegedExceptionAction<Object>(){
public Object run() throws AuditException {
auditAdminService.setAuditPolicy(componentType, newPolicy);
return null;
}
});

25.6 監査イベントを記録するためのアプリケーション・コードの追加

アプリケーションはプログラムにより実行時監査サービスにアクセスし、クライアントAPIを使用して独自の監査イベントを生成できます。

25.6.1 監査クライアントAPI

監査クライアントAPIは次のとおりです。

関連項目:

第25.6.2項のgetAuditorを使用する前提条件。

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)
}

次の各項では、パーミッションおよび実行時監査インスタンスの取得方法について説明します。

25.6.2 システム権限の設定

監査クライアントが監査APIを呼び出すには、AuditStoreAccessPermissionが必要です。この例では、権限によりアプリケーションMyAppはAccessController.doPrivilegedブロック内のauditService.getAuditor("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.audit.AuditStoreAccessPermission</class>
<name>comp1</name>
<actions>action1,action2,….</actions>
</permission>
</permissions>
</grant>

<actions>は、監査クライアントの呼出しに必要な監査APIに関連する、認可されたアクションのカンマ区切りのリストです。指定可能なアクションは次のとおりです。

アクション

クライアントへの認可

作成

新規監査コンポーネントを登録するためのAuditService.register(AuditRegistration)のコール。

アップグレード

既存の監査コンポーネントのイベント定義をアップグレードするためのAuditService.register(AuditRegistration)のコール。

削除

監査コンポーネントを登録解除するためのAuditService.unregister(AuditRegistration)のコール。

読取り

コンポーネントの監査インスタンスを取得するためのAuditService.getAuditor(String componentType)のコール。

変更

監査ポリシーを変更するためのAuditAdminService.setAuditPolicy(String componentType, AuditPolicy auditPolicy)のコール。

25.6.3 監査インスタンスの取得

次のサンプル・コードが示すように、監査サービスへの登録後、アプリケーションはプログラムにより実行時監査インスタンスをOPSS監査サービスから取得できます。

//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);
}

25.7 監査定義の更新と保守

アプリケーションの監査要件の変化に応じて、変化を反映するように統合を更新できます。手順は次のとおりです。

1. 監査ファイル定義を更新します。この手順の実行時にはバージョニング・ルールに注意してください。

関連項目:

第13.5.3項。

2. 更新されたイベント定義ファイルとともにアプリケーションEARファイルを再デプロイします。または、監査登録サービスに新しいバージョンの存在を通知することもできます。

3. 変更を検証します。

第V部

付録

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

- 付録A「OPSS構成ファイル・リファレンス」

- 付録B「ファイルベースのアイデンティティ・ストアとポリシー・ストアのリファレンス」

- 付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

- 付録E「スクリプトおよびMBeanプログラミングを使用した管理」

- 付録F「OPSSのシステムおよび構成プロパティ」

- 付録G「OPSS APIリファレンス」

- 付録H「OpenLDAPアイデンティティ・ストアの使用」

- 付録I「ID仮想化のためのアダプタ構成」

- 付録J「OPSSのトラブルシューティング」

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

この付録では、OPSSサービスを構成するファイルの要素階層と属性について説明します。このファイルのデフォルトの名前は、jps-config.xml (Java EEアプリケーションの場合)またはjps-config-jse.xml (Java SEアプリケーションの場合)です。

デフォルトで、OPSS構成ファイルは$DOMAIN_HOME/config/fmwconfigディレクトリにありますが、Java SEアプリケーションの場合は、システム・プロパティoracle.security.jps.configを使用して別の場所を指定できます。

構成ファイルは、セキュリティ・ストア、ログイン・モジュールおよび監査サービスの構成に使用されます。完全な構成ファイルの例は、第18.5.9項「構成ファイルjps-config.xmlの例」を参照してください。

プログラムによるサービスの構成方法は、第E.2項「MBeansを使用したOPSSサービスの構成」を参照してください。

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

- 第A.1項「トップレベルおよび第2レベルの要素階層」

- 第A.2項「下位レベルの要素」

A.1 トップレベルおよび第2レベルの要素階層

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 下位レベルの要素

この項では、「トップレベルおよび第2レベルの要素階層」で説明した第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>XML-based IdStore Provider</description>
...
</serviceProvider>

<extendedProperty>

この要素は、次のシナリオで拡張プロパティを定義します。

表A-2 <extendedProperty>のシナリオ

のシナリオ" title="<extendedProperty>のシナリオ" width="100%">

jps-config.xml内での位置

機能

<jpsConfig>の直下

汎用的な拡張プロパティを定義します。<jpsConfig>の子として、拡張プロパティは、たとえばLDAPベースの認証プロバイダのすべてのベースDNを指定できます。

<extendedPropertySet>の直下

拡張プロパティ・セットの一部である汎用的な拡張プロパティを定義します。

<serviceInstance>の直下

特定のサービス・インスタンスの拡張プロパティを定義します。

拡張プロパティには通常、複数の値が含まれています。それぞれの値を指定するには、<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 Service 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%">

名前

説明

default

指定がない場合にアプリケーションによって使用されるコンテキストを指定します。<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-3 <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}

例

次の例は、認可の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>Oracle Access Manager 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項「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」で説明されている手順を使用できます。

サービス・インスタンスのプロパティと拡張プロパティを、次の方法で設定します。

- <property>サブ要素を使用してプロパティを直接設定します。

- <extendedProperty>サブ要素を使用して拡張プロパティを直接設定します。

- <propertySetRef>サブ要素を使用して事前定義済のプロパティ・セットを参照します。

- <extendedPropertySetRef>サブ要素を使用して事前定義済の拡張プロパティ・セットを参照します。

属性

の属性" title="<serviceInstance>の属性" width="100%">

名前

説明

name

このサービス・インスタンスの名前を指定します。1つのjps-config.xmlファイル中に同じname属性の設定を持つ<serviceInstance>要素が複数存在することはできません。

値: 文字列

デフォルト: 該当なし(必須)

provider

このインスタンスがどのサービス・プロバイダのものであるかを示します。

<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 XML Identity Store -->
<property name="subscriber.name" value="jazn.com"/>
<!-- This is the location of XML 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 Service
Instance</description>
<property name="location"
value="${oracle.instance}/config/JpsDataStore/JpsSystemStore" />
</serviceInstance>
...
</serviceInstances>

例3

次の例では、Oracle Internet Directoryを使用した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

実装クラスでは、ファイルベースのアイデンティティ・ストアやLDAPベースのポリシー・ストアを実装するなどして、より具体的にプロバイダのタイプが定義されます。

値: 文字列(上記の値)

デフォルト: 該当なし(必須)

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 ファイルベースのアイデンティティ・ストアとポリシー・ストアのリファレンス

この付録では、Oracle Platform Security Servicesのファイルベースのアイデンティティ・ストアとポリシー・ストアのデフォルトのストアであるsystem-jazn-data.xml内の要素と属性について説明します。

注意:

ファイルベースのアイデンティティ・ストアは、Java SEアプリケーションに対してのみサポートされます。

内容は次のとおりです。

- 第B.1項「system-jazn-data.xmlの要素の階層」

- 第B.2項「system-jazn-data.xmlの要素と属性」

B.1 system-jazn-data.xmlの要素の階層

この項では、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の要素の階層

階層

説明

<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}

<jazn-realm>セクションでは、セキュリティ・レルム、および各レルムに含まれるユーザーとエンタープライズ・グループを指定します(アプリケーション・レベルのロールは指定しません)。

<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}

<policy-store>セクションでは、アプリケーション・レベルのポリシーを構成します。アプリケーション・レベルのロールや、ロールのメンバーを定義できます。メンバーには、ユーザーまたはロールを指定できます。

<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の要素と属性

この項では、system-jazn-data.xmlファイルの要素と属性について説明します。

注意:

- system-jazn-data.xml内の大半の設定は、Oracle Enterprise Manager Fusion Middleware Controlを通じて更新できます。

- <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>

この要素は、通常GUIツールで使用される項目の名前を指定します。項目は、親要素に応じて、アプリケーション・ロール、ユーザーまたはエンタープライズ・グループのいずれかです。

親要素

<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)を指定します。

親要素に応じて、参照される項目は、アプリケーション・ロール、アプリケーション・ロール・メンバー、プリンシパル、エンタープライズ・グループまたはユーザーのいずれかになります。通常は、LDAPプロバイダで使用され、項目(ユーザーなど)を一意に識別します。GUIDは、ユーザーやロールを別のセキュリティ・プロバイダに移行する場合などに、Oracle Platform Security Servicesで生成され、内部的に使用されることがあります。ユーザーが自分で設定する項目ではありません。

親要素

<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 11.1.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}

例

例B-1 <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>

例B-2 <jazn-policy>

<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-file-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%">

名前

説明

default

この要素の下に定義されているレルムのうちどれがデフォルトのレルムであるのかを指定します。この属性の値は、いずれかの<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>要素を通じて決まります。
オプションのサブ要素には、<uniquename>と<guid>があり、一意の名前とグローバル一意識別子を指定します。これらのサブ要素は、内部使用のみを目的としています。

親要素

<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では、ロール所有者はロールのワークフロー・ルールの作成や更新ができます。

注意:

Oracle Internet Directoryでグループ所有者を作成するには、Oracle Delegated Administration Servicesを使用します。

親要素

<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スキーマ定義では、この要素は必須要素として指定されませんが、Oracle Platform Securityランタイム実装では、任意の<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>サブ要素を通じてアプリケーション・レベルのポリシーを構成します。<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つは内部使用のみを目的としています)。

プリンシパル名を比較する方法の詳細は、第2.7項「プリンシパル名の比較ロジック」を参照してください。

親要素

<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>

この要素は、リソース・タイプ・プロバイダの名前を指定します。リソースは、OPSSポリシー・ストアの外部の場所にあります。値では、大文字と小文字は区別されません。

親要素

<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>

リソース・タイプの指定では次の点が適用されます。

- 名前は必須で、大文字と小文字は区別されません。

- プロバイダ名は省略可能で、大文字と小文字は区別されません。外部ストア(OPSSドメイン・ポリシー・ストア以外のストア)で管理しているリソースがある場合にプロバイダを使用することが普通です。
プロバイダ名を指定する場合、<provider-name>要素に記述したクラスはリソース・ファインダとして使用されます。このタイプのリソースに対する問合せ(ResourceManager検索APIを使用して実行)は、OPSSドメイン・ポリシー・ストアに対して組込みのリソース・ファインダを使用せずに、このマッチャ・クラスに委任されます。

- マッチャ・クラス名は必須で、大文字と小文字が区別されます。

- 説明の文字列は省略可能で、大文字と小文字は区別されません。

- 表示名は省略可能で、大文字と小文字は区別されません。

- アクションの文字列はオプションで、大文字と小文字が区別されます。リソース・タイプのアクションのリストは空でもかまいません。アクション・リストが空の場合、リソース・タイプのインスタンスに対するアクションは外部で指定され、OPSSでは不定になります。

<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によって算出されます。)親要素に応じて、項目はアプリケーション・ロール、アプリケーション・ロール・メンバー(エンタープライズ・グループ・メンバーではない)、またはプリンシパルになりえます。通常は、LDAPプロバイダで使用され、項目(アプリケーション・ロール・メンバーなど)を一意に識別します。一意の名前は、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監査フレームワークの監査レポートに関する参照情報が含まれています。

この章の情報は、監査レコードの管理およびシステム・コンポーネントの監査レポートの開発に役立ちます。

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

- 第C.1項「監査イベント」

- 第C.2項「ビルトイン監査レポート」

- 第C.3項「監査レポートのカスタマイズ」

- 第C.4項「監査スキーマ」

- 第C.5項「監査のためのWLSTコマンド」

- 第C.6項「監査フィルタ式の構文」

- 第C.7項「監査ファイルの命名およびロギング形式」

注意:

この付録では、Oracle Business Intelligence Publisher 10gを使用したレポート・テンプレート・モデルに基づくレポートについて説明します。動的メタデータ・モデルに基づく監査には、異なる方法を使用します(詳細は、第15章を参照してください)。

C.1 監査イベント

この項では、監査対象のコンポーネントと監査可能なイベント・タイプについて説明します。

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

Oracle Fusion Middleware監査フレームワークは、Oracle Fusion Middlewareコンポーネントおよびアプリケーションを使用して監査するための基礎を提供します。12c (12.1.2)では、多くのJavaコンポーネントおよびシステム・コンポーネントで監査レコードを生成でき、これらのコンポーネントは監査対応コンポーネントと呼ばれます。

Fusion Middleware監査フレームワークを使用するJavaコンポーネントの例は、次のとおりです。

- ディレクトリ統合プラットフォーム・サーバー

- Oracle Platform Security Services

- Oracle Web Services Manager

- Oracle Webサービス

- Reportsサーバー

Fusion Middleware監査フレームワークを使用するシステム・コンポーネントの例は、次のとおりです。

- Oracle HTTP Server

- Oracle Internet Directory

この付録では、Oracle Platform Security Servicesによって生成されたイベントについてのみ、監査情報を示します。他のコンポーネントおよびアプリケーションの監査の詳細は、それぞれの管理ガイドを参照してください。

C.1.2 監査可能なイベント

この項の一連の表は、監査できるイベント・タイプを示しています。

- Oracle Platform Security Servicesのイベントとその属性

C.1.2.1 Oracle Platform Security Servicesのイベントとその属性

この項には、次の表が含まれます。

- 表C-2「Oracle Platform Security Servicesの主要なイベント」

- 表C-3「アイデンティティ・ディレクトリ・サービスのイベント」

- 表C-4「Identity Virtualization Libraryのイベント」

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

カテゴリ

イベント

説明

UserSession

このイベント・セットは、システムでユーザー・セッションを作成および使用するために使用します。

これらのイベントの共通属性は、AuthenticationMethodです。

UserLogin

ユーザー・ログイン

複数層アプリケーションでは、通常、内部の層が次の層にログインする際に、特別なユーザーID (エンド・ユーザーまたは管理者)を使用します。監査レポートをより有意義にするために、これらの特別なユーザーによるログインは、内部ログインという個別のカテゴリに含まれます。ユーザー・ログイン/ログアウトのイベントには、(管理者を含む)通常のユーザーによる処理のみが記録されます。

UserLogout

ユーザー・ログアウト

エンド・ユーザーまたは管理者がログアウトします。

認証

認証は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

このイベント・セットは、サービス構成の監査に適用されます。

これらのイベントの共通属性は、次のとおりです。

TransactionId

ConfigureAuditPolicy

監査を制御するパラメータを変更します(監査イベントのフィルタ処理など)。

ConfigureAuditRepository

監査リポジトリを構成します(ファイルベース・リポジトリからデータベース・リポジトリへの変更のためなど)。

関連項目:

システム・カテゴリおよびイベントの概要は、第13.4.3項を参照してください。

表C-2 Oracle Platform Security Servicesの主要なイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

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

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

表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

C.1.3 OPSSイベント属性の説明

表C-5は、OPSS監査イベントに対するすべての属性を示します。この表を使用して、目的のイベントで使用される属性について理解してください。

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

ネームスペース

属性名

説明

共通

ApplicationName

Java EEアプリケーション名。

AuditUser

アプリケーションを実行しているユーザーのユーザー名を識別する属性。

ComponentData

スキーマにコンポーネント固有の表がない場合に、コンポーネント固有のデータが格納される場所。

ComponentName

このコンポーネントの名前。

ComponentType

コンポーネントのタイプ

ContextFields

dmsコンテキストから抽出されたコンテキスト・フィールドを含む属性。

DomainName

WebLogic ServerまたはIBM WebSphereドメイン。

EventCategory

監査イベントのカテゴリ

EventStatus

監査イベントの結果(失敗または成功)。

EventType

監査イベントのタイプすべてのイベントを表示するには、wlst listAuditEventsコマンドを使用します。

FailureCode

EventStatusがfailureの場合のエラー・コード

HomeInstance

このコンポーネントのORACLE_INSTANCEディレクトリ。

HostId

開始ホストのDNSホスト名。

HostNwaddr

開始ホストのIPアドレスまたは他のネットワーク・アドレス。

Initiator

操作を実行しているユーザーのUIDを識別する属性。

InstanceId

このコンポーネントが属しているOracleインスタンスの名前。

MajorVersion

メジャー・バージョンのコンポーネント。

MessageText

監査イベントの説明。

MinorVersion

マイナー・バージョンのコンポーネント。

ModuleId

メッセージを生成したモジュールのID。解釈はコンポーネントID内で一意です。

OracleHome

コンポーネントのORACLE_HOMEディレクトリ。

ProcessId

メッセージの起点となったプロセスのID。

RemoteIP

このイベントを開始するクライアントのIPアドレス。

Resource

アクセス中のリソースを識別する属性リソースには、Webページ、ファイル、ディレクトリ共有、Webサービス、XMLドキュメント、ポートレットなど、多くのものを指定できます。リソースの名前は、ホスト名とURIを組み合せて付けることができます。

RID

リレーションシップ識別子(スレッドとプロセスの間に完全かつ適切なコールのリレーションシップを提供)。

Roles

ログイン時にユーザーに付与されたロール

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.4.2項を参照してください。

C.2 ビルトイン監査レポート

Oracle Fusion Middleware監査フレームワークは、Oracle Business Intelligence Publisherを介してアクセス可能なシステム・コンポーネントに対して、すぐに使用可能なレポートの範囲を指定します。この項では、Oracle Business Intelligence Publisherでの監査レポートの構成方法と表示方法について説明します。

C.2.1 監査レポート用のOracle Business Intelligence Publisherの設定

監査データがデータベース内に存在する場合は、事前定義済のOracle Business Intelligence Publisherレポートを実行して、データに関する独自のレポートを作成できます。この項では、監査レポート用の環境の構成に関する次のトピックを説明します。

- Oracle Business Intelligence Publisherについて

- Oracle Business Intelligence Publisherのインストール

- Oracle Business Intelligence PublisherでのOracle Reportsの設定

- 監査レポート・テンプレートの設定

- 監査レポート・フィルタの設定

- Oracle Business Intelligence Publisherのスケジューラの構成

関連項目:

次のサイトのOracle Business Intelligence Publisher Enterpriseドキュメント

http://www.oracle.com/technology/documentation/bi_pub.html

C.2.1.1 Oracle Business Intelligence Publisherについて

HIPPAやSOXなどの各種業界規制やその他の規制に対するコンプライアンス要求に関して、管理者が違反の有無を確認する際には、レポートが役立ちます。Oracle Fusion Middleware監査フレームワークは、Oracle Business Intelligence Publisherに統合され、すぐに使用可能なレポートを提供しています。

Oracle Fusion Middleware監査フレームワークの一部として、事前定義済のレポートを使用できます。これらのレポートは、Oracle Business Intelligence Publisherに統合されており、監査ストア内の監査データとともに機能します。

12c (12.1.2)において、Oracle Fusion Middleware監査フレームワークには、20を超えるビルトイン・レポートが含まれています。便宜上、それらのレポートはOracle Business Intelligence Publisher内で機能領域に従い、コンポーネント別にグループ化されています。

機能領域には、次のものがあります。

- エラーと例外に関するレポート(認証と認可の失敗など)

- ユーザー・アクティビティ(トランザクション履歴や認可履歴など)

- 運用に関するレポート(作成済、削除済、ロックアウトされたユーザーなど)

- 監査サービス・イベント

Oracle HTTP Serverレポートなど、コンポーネント固有レポートは、名前からわかるように、コンポーネント自体に基づいてグループ化されます。

Oracle Business Intelligence Publisherのその他の機能は、次のとおりです。

- 柔軟なレポート表示
レポートのオンライン表示、レポート・パラメータの変更、出力タイプ(PDF、HTML、RTF、Excelなど)の変更、レポートの外観の変更、目的のフォーマットへのエクスポート、および、電子メール・アドレスやFAXなどの宛先への送信が可能です。

- レポート・フィルタ
一連のオプションを使用して、レポートに含める監査レコードをフィルタ処理できます。オプションには、監査リポジトリからのレコードの抽出に使用されたSQLの変更機能も含まれます。

- レポートのスケジュール
フィルタ、テンプレート、フォーマット、ロケール、表示制限などの一連の基準に基づいてレポートを実行するようにスケジュールできます。

関連項目:

スケジューリング機能の詳細は、次のサイトにあるOracle Business Intelligence Publisher Enterpriseのドキュメントを参照してください。

http://www.oracle.com/technology/documentation/bi_pub.html

- カスタム・レポート作成
独自のレポートを設計して、データ・モデル、レイアウト、パラメータ、バースティング(配信プリファレンスに基づいた配信を可能にするなど)を指定することができます。

関連項目:

- Oracle Business Intelligenceに関するトラブルシューティングのヒントおよびその他の有用な情報は、第J.6項「Oracle Business Intelligenceレポート作成のトラブルシューティング」を参照してください。

- 次のサイトのOracle Business Intelligence Publisher Enterpriseドキュメント
http://www.oracle.com/technology/documentation/bi_pub.html

Oracle Business Intelligence Publisherで使用可能なすべての監査レポートには、次のようなレポートのフィルタ処理オプションとフォーマット・オプションが用意されています。

- ビュー - 現在のパラメータを使用してレポートを表示します。

- スケジュール - レポートのスケジュールをジョブ・パラメータとデータ・フィルタとともに設定します。

- 履歴 - 履歴を表示します。

- 編集 - 問合せとパラメータ表示フォーマットを変更します。

- 構成 - ランタイムの構成制御を設定します。

- エクスポート - ファイルにエクスポートします。

C.2.1.2 Oracle Business Intelligence Publisherのインストール

サイトにOracle Business Intelligence Publisher 10.1.3.4以降がインストールされている場合は、この項を省略して、第C.2.1.3項に進んでください。

Oracle Business Intelligence Publisherをインストールする必要がある場合は、Oracle Business Intelligence PublisherのCompanion CDに示されている手順に従ってください。

関連項目:

次のサイトのOracle Business Intelligence Publisher Enterpriseドキュメント

http://www.oracle.com/technology/documentation/bi_pub.html

C.2.1.3 Oracle Business Intelligence PublisherでのOracle Reportsの設定

この項では、監査データソースで機能するようにOracle Business Intelligence Publisherを構成する方法について説明します。

注意:

11gリリース1 (11.1.1.4.0) PS3のレポートは、11g リリース1 (11.1.1.4.0) PS3のスキーマでのみ機能し、12c (12.1.2)などの古いバージョンのスキーマでは機能しません。

パッチ・セット・アシスタントを使用したスキーマのアップグレードの詳細は、『Oracle Fusion Middlewareパッチ適用ガイド』を参照してください。

監査レポート用にOracle Business Intelligence Publisherを設定するには、次の手順を実行します。

1. Oracle Business Intelligence Publisherのインストール先の「レポート」フォルダに移動します。デフォルトでは、「レポート」フォルダは%BIP_HOME%\XMLP\Reportsです。

2. AuditReportTemplates.jarを「Reports」フォルダに解凍します。Oracle_Fusion_Middleware_Auditという新しいフォルダが表示されます。AuditReportTemplates.jarは次の場所にあります。

$MW_ORA_HOME/oracle_common/modules/oracle.iau_12.1.2/reports/
AuditReportTemplates.jar

3. 次のようにして、監査リポジトリのデータソースを設定します。

- 「管理」タブに移動します。

- ステップ1でOracle WebLogic Serverをデプロイした場合は、次のようにしてJNDIを設定します。

- 「JNDI接続」をクリックします。

- 「データソースの追加」をクリックします。

- データソースの詳細を指定します。
データソースにはAuditという名前を付けます。

注意:

レポートは監査データソースを参照するため、命名規則は重要です。

JNDI名 - jdbc/AuditDB。

- 接続が正常かどうかをテストします。接続が正常でない場合は、入力した値を確認します。

- 「適用」をクリックして変更を保存します。

- ステップ1でOracle Containers for Java EEをデプロイした場合は、次のようにしてJNDIを設定します。

- 「JDBC接続」をクリックします。

- 「データソースの追加」をクリックします。

- データソースの詳細を指定します。
データソースにはAuditという名前を付けます。

注意:

レポートは監査データソースを参照するため、命名規則は重要です。

監査スキーマのURL、ユーザー名およびパスワードの詳細情報を入力します(注意: ユーザー名とパスワードは接頭辞と監査スキーマ名(IAU_VIEWER)で構成されます。たとえば、dev_iau_viewerやtest_iau_viewerです。)

- 接続が正常かどうかをテストします。接続が正常でない場合は、入力した値を確認します。

- 「適用」をクリックして変更を保存します。

C.2.1.4 監査レポート・テンプレートの設定

標準の監査レポートをデフォルトの形式でそのまますぐに使用することができます。ただし、レポートの外観やその他の関連する側面をカスタマイズする場合は、監査レポート・テンプレートを設定します。

レポートの「編集」ダイアログで、左側のパネルの「レイアウト」オプションをクリックすると、レイアウトと出力フォーマットを管理できます。この機能を使用して、次の操作を実行できます。

- レポート・テンプレートのカスタマイズと独自のレイアウトの設計。たとえば、フィールドの再配置や選択したフィールド・ラベルの強調表示ができます。

- レポート出力を生成するフォーマットの制限。デフォルトでは、HTML、PDF、Excelスプレッドシート、RTFなどの多数の出力フォーマットが使用可能になっています。

関連項目:

『Oracle Business Intelligence Publisherユーザーズ・ガイド』

C.2.1.5 監査レポート・フィルタの設定

標準の監査レポートをデフォルトの形式でそのまますぐに使用することができます。ただし、レポートのデータの範囲やその他の関連する側面をカスタマイズする場合は、監査レポート・フィルタを設定します。

Oracle Business Intelligence Publisherは、監査レポートに基本と詳細の両方のフィルタリング・オプションを提供します。

関連項目:

『Oracle Business Intelligence Publisherユーザーズ・ガイド』

基本フィルタ

レポートの「スケジュール」ボタンをクリックして表示されるページでは、スケジュールを使用してレポートを管理できます。

「レポート・パラメータ」領域では、レポートを制限する次のような高水準のフィルタを指定できます。

- 日付フィルタ

- 直前の1時間や先週など、最近の監査レコードのみを表示します。

- 指定した開始および終了日付の間に生成されたレコードを表示します。

- 返されるレコードの数を制限します。

- 選択されたレポート・フィールド
たとえば、認証失敗レポートは、次の項目でフィルタ処理できます。

- ユーザー名

- コンポーネント・タイプ

- コンポーネント名

- アプリケーション名

- ドメイン名

詳細フィルタ

レポートの「編集」ボタンをクリックして表示されるページでは、さらに詳細なレポート・フィルタおよびプロパティを指定できます。該当ページは、次の2つのパネルから構成されています。左のパネルを使用すると、それらのオプションによって変更するレポートの要素を選択できます。選択した要素ごとに、対応する情報が右のパネルに表示されます。

- データ・モデル - レポートの生データをフェッチするSQL問合せが含まれます。この問合せは、ニーズに合せて変更できます。

- 値リスト - レポートのすべての列が表示されます。列を選択すると、属性のデータをフィルタ処理する、基盤となるSQL問合せが表示されます。問合せは、必要に応じて変更できます。たとえば、制限がさらに厳格なフィルタ値も指定できます。

- パラメータ - レポートのすべての列が表示されるので、列を選択し、その列の表示値を変更できます。たとえば、タイムスタンプ・フィールドの日付の表示形式も指定できます。

- レイアウトと出力フォーマット - この機能については、第C.2.1.6項で説明します。

C.2.1.6 Oracle Business Intelligence Publisherのスケジューラの構成

レポートの「スケジュール」ボタンをクリックして表示されるページでは、スケジュールを使用してレポートを管理できます。このページでは、次の情報を指定できます。

注意:

この機能では、Oracle Business Intelligence Publisherリポジトリが構成済であることを前提としています。

- レポート・パラメータ - レポートに含まれるデータをフィルタ処理して制限します。たとえば、直前の1時間のレコードのみに制限できます。

関連項目:

第C.2.1.5項

- ジョブ・プロパティ - ジョブ名、フォーマット・ロケール、タイムゾーンなどです。

- 通知 - ジョブが完了または失敗したときに電子メールで通知する1人以上のユーザーです。

- 時間 - レポートのスケジューリング・オプションです。レポートの定期的な実行や1回かぎりの実行をスケジュールできます。

- 配信 - 1人以上のユーザーにレポートを配信します。

C.2.2 監査レポートの編成

Oracle Fusion Middleware監査フレームワークには、追加設定なしですぐにOracle Fusion Middlewareコンポーネントと連携できるように設計された一連の事前定義済レポートが添付されています。これらのレポートは、次の2つの主なカテゴリに分類されます。

- 共通レポート
これらのレポートは、認証の成功と失敗、アカウント関連のステータス(ロックアウト、無効など)のような共通のイベントを取得します。このような共通のイベントに対する監査機能は、多くのコンポーネントに実装されています。共通レポートは監査レポートの「共通レポート」サブフォルダにあり、一連のコンポーネントからのすべての監査対応のイベントはこれらのレポートに格納されます。

たとえば、「認証履歴」には、認証イベントが取得される全コンポーネントの認証履歴が表示されます。

これらのレポートを使用すると、コンポーネント間の特定領域について監査レコードを調査したり、その特定領域に対し、複数のコンポーネントにわたる単一ユーザーの監査レコードをチェックすることができます。

- コンポーネント固有レポート
これらのレポートは、個々のコンポーネントを重視しています。すべての監査イベントが各コンポーネントに関連しているとはかぎらないため、これらのレポートが必要となります。「コンポーネント固有」フォルダには、2つの目的があります。第1に、コンポーネントに関連し、そのコンポーネントの監査レコードのみを表示する共通レポートの中から有効なレポートを特定します。第2に、一部のコンポーネントでは、該当するコンポーネントの特定のニーズに合うように、コンポーネントに固有なレポートが定義されています。監査レコード自体がすべてのコンポーネントに対して汎用的である一方、監査レコードの表現にはコンポーネントに固有な要件がある可能性があります。たとえば、アクセス・ポリシーを、有用となる形式で示す必要がある場合もあります。

たとえば、全コンポーネントの認証イベントが表示される「共通」フォルダに、認証履歴レポートを配置することができます。また、同じレポートが、該当するコンポーネントの認証イベントのみが表示されるコンポーネントに固有なフォルダに存在する場合もあります。

- また、最上位には「すべてのイベント」という汎用的なレポートが存在し、このレポートでは監査対応の全コンポーネントのすべてのイベントが表示されます。「すべてのイベント」レポートは、それぞれのコンポーネント固有フォルダでも使用でき、各コンポーネントの全イベントを表示することができます。
このレポートは、監査データの問合せにも使用できます。

C.2.3 監査レポートの表示

この項では、Oracle Business Intelligence Publisherを使用して監査レポートを表示する方法を説明します。

監査レポートを表示するには、次の手順を実行します。

1. 次の形式のURLを使用して、Oracle Business Intelligence Publisherにログインします。
http://host.domain.com:port/xmlpserver/

2. メイン・ページで、共有フォルダの「Oracle Fusion Middleware監査」をクリックします。

3. 監査レポートは、次の2つに分類されます。

- 複数のコンポーネントに共通のレポート(さらにレポート・タイプ別に分類されます)。

- 単一のコンポーネントに固有なレポート(さらにコンポーネント別に分類されます)。

関連項目:

標準的なレポートの説明は、表C-6を参照してください。

4. 目的のレポートに移動します。たとえば、共通レポート→エラーと例外→「すべてのエラーと例外」をクリックします。
レポートが表示されます。

5. レポート表示ページには、次の主要な領域があります。

- ページ上部にあるフィルタ。フィルタを使用して、レポートに含めるレコードのタイプ、範囲および数を決定できます。このようなフィルタには、次のものがあります。

- ユーザー

- 開始日と終了日

- 最後のn回

- コンポーネントのタイプと名前

- アプリケーション名

- ドメイン名

適切なフィルタを使用し、目的のレコードに限定してレポートを作成してください。

注意:

レポートは、初期状態ではデフォルトのフィルタ値を使用して表示されます。このデフォルト値は変更可能です。

- フォーマット制御ボタン。これにより、次の内容を決定できます。

- テンプレート・タイプ。次の選択肢があります。
HTML - デフォルトの表示形式です。

PDF - 印刷可能なPDFビューが表示されます。

データ - フォーマットされていないXMLデータセットが表示されます。

レポートの表示中にテンプレート・タイプを変更するには、ドロップダウン・リストからテンプレート・タイプを選択し、「表示」をクリックします。

- 出力フォーマット

- 配信オプション

- レポートのレコード表示領域。この領域の外観と列数は、その前に選択されたオプションとフィルタによって異なります。
各列ヘッダーはソート・オプションとしても機能します。

6. 必要に応じてレポートを表示、保存またはエクスポートします。

C.2.4 Oracle Business Intelligence Publisherレポートの例

この項では、一般的なシナリオを使用して、Oracle Platform Security Servicesのイベントによって生成された監査データを、Oracle Business Intelligence Publisherレポートで表示する方法を示します。

この例では、Oracle WebLogic Serverドメインの資格証明ストア上でいくつかのアクティビティが生成されます。その後、Oracle Business Intelligence Publisherを使用して関連レポートを表示し、監査レコードを確認します。その後で、その他のいくつかのレポートを調査します。

1. システム管理者として、資格証明が管理対象になっているドメインを検索します。

2. 関連コマンドを使用して、資格証明管理レコードをいくつか生成します。例として、いくつかのユーザー資格証明の作成と削除を実行します。

関連項目:

資格証明管理の詳細は、第11章「資格証明ストアの管理」を参照してください。

3. 次の形式のURLを使用して、Oracle Business Intelligence Publisherにログインします。
http://host.domain.com:port/xmlpserver/

4. 「レポート」タブの「共有フォルダ」→Fusion Middleware監査を選択します。

5. メイン・ページで、共有フォルダの「Fusion Middleware監査」をクリックします。

6. 監査レポート・メニューが表示されます。監査レポートは、タイプ別に整理されて様々なフォルダに表示されます。

7. たとえば、Oracle Platform Security Servicesの監査レコードを表示するには、「コンポーネント固有」フォルダに移動し、「Oracle Platform Security Services」をクリックします。

8. 「Oracle Platform Security Services」フォルダには、いくつかのレポートが含まれています。「すべてのイベント」をクリックします。
このレポートには、デフォルトの時間範囲内に発生したアクティビティが表示されます。時間範囲を変更して、その日のイベントのみを表示します。

その日に実行したアクティビティがページに表示されます。

レポートの様々なリージョンおよび機能(レポート・フィルタ、書式制御、スケジューリング、およびデータ表示自体)を確認します。

9. 各レポートの最後のデータ列は、「詳細」列です。詳細情報をクリックして、特定の監査レコードの属性をすべて表示します。

10. メイン・フォルダに戻って、興味のあるその他のレポートをいくつか表示します。たとえば、「共通レポート」フォルダで「アカウント管理」フォルダに移動し、「アカウントのプロファイル履歴」をクリックします。
「アカウントのプロファイル履歴」レポートが表示されます。

11. 目的のイベントの「イベント詳細」をクリックします。

12. 最後に、「共通レポート」フォルダに戻り、「エラーと例外」を選択します。「すべてのエラーと例外」レポートを選択します。

13. 多くのレコードが表示されます。レポートの表示を目的のレコードに絞るには、「イベント」ドロップダウンを使用して「CheckPermission」イベントを選択します。
認可チェックに適合しなかったレコードを示す1行が返されます。

14. 「詳細」をクリックすると、詳細情報が表示されます。

C.2.5 監査レポートの詳細

この項では、標準的な(ビルトイン)監査レポートに関する詳細なリファレンス情報を示します。

標準的な監査レポートは、次のように分類されます。

1. 「すべてのイベント」レポート
このレポートには、事前定義済の時間間隔で生成されたすべての監査レコードが含まれます。

2. 共通レポート
これらは、複数のコンポーネントにわたる監査レコードが含まれるレポートです。

3. コンポーネント固有レポート
どのレポートも、特定の1つのコンポーネント専用です。

共通レポート

共通レポートには次のようなものがあります。

- アカウント管理

- アカウント・プロファイル履歴

- 削除済アカウント

- 有効化されたアカウント

- 無効化されたアカウント

- 作成されたアカウント

- ロック・アウトされたアカウント

- パスワード変更

- ダッシュボード

- ユーザー・アクティビティ

- 認証履歴

- 同じIPの複数ログイン

- 認可履歴

- イベント詳細

- 関連監査イベント

- ダッシュボード

- エラーと例外

- すべてのエラーと例外

- 認可失敗

- 認証失敗

- ダッシュボード

重要:

11gリリース1 (11.1.1.4.0) PS3(パッチ・セット3)のスキーマに対してのみ「イベント詳細」レポートを実行します。

C.2.5.1 Oracle Business Intelligence Publisherの監査レポートのリスト

表C-6に、Oracle Business Intelligence Publisherの各監査レポートの簡単な説明を示します。

注意:

「格納先フォルダ」という列に示されるフォルダ・パスは、「Oracle Fusion Middleware監査」フォルダを基準としています。このフォルダにアクセスするには、Oracle Business Intelligence Publisherにログインした後、「共有フォルダ」→Oracle Fusion Middleware監査に移動します。

表C-6 監査レポートのリスト

レポート

説明

格納先フォルダ

作成されたアカウント

各種コンポーネントで作成されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

削除済アカウント

各種コンポーネントで削除されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

無効化されたアカウント

各種コンポーネントで無効化されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

有効化されたアカウント

各種コンポーネントで有効化されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

ロック・アウトされたアカウント

認証の失敗が多すぎるためにロック・アウトされたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

アカウント・プロファイル履歴

アドレスやパスワードの変更など、アカウントにおけるプロファイルの変更が表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

すべてのエラーと例外

コンポーネント間にわたるすべてのエラーと例外が取得されます。

共通レポート→エラーと例外。および「コンポーネント固有」フォルダ。

すべてのイベント

すべての監査イベントが表示されます。

Oracle Fusion Middleware監査。および「コンポーネント固有」フォルダ。

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

アプリケーション・レベルのポリシー管理が表示されます。

「コンポーネント固有」→「Oracle Platform Security Services」。

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

アプリケーション・ロールからエンタープライズ・ロールへのマッピングが表示されます。

「コンポーネント固有」→「Oracle Platform Security Services」。

アサーション・アクティビティ

Oracle Identity Federationにおけるアサーション・アクティビティが表示されます。

「コンポーネント固有」→「Oracle Identity Federation」。

アサーション・テンプレート管理

Oracle Web Services Manager内のアサーション・テンプレート管理操作のリストが表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」→「ポリシー管理」。

認証失敗

認証エラーと例外が表示されます(複数のコンポーネントにまたがっていても、単一のコンポーネントに固有なものでもかまいません)。

共通レポート→エラーと例外。および「コンポーネント固有」フォルダ。

認証履歴

すべてのコンポーネントにわたる認証がリスト表示されます。

共通レポート→ユーザー・アクティビティ。および「コンポーネント固有」フォルダ。

認可失敗

認可失敗が取得されます。

共通レポート→エラーと例外。および「コンポーネント固有」フォルダ。

認可履歴

すべてのコンポーネントにわたる認可が表示されます。

共通レポート→ユーザー・アクティビティ。および「コンポーネント固有」フォルダ。

機密性の施行

Oracle Web Services Manager内の機密性に関連した施行がリスト表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」→「ポリシー施行」。

構成の変更

Fusion Middleware監査フレームワークで行われた構成の変更がリスト表示されます。

「コンポーネント固有」→Oracle Fusion Middleware監査フレームワーク。

資格証明アクセス

Oracle Platform Security Servicesにおけるユーザーおよびアプリケーションによる資格証明アクセスが表示されます。

「コンポーネント固有」→「Oracle Platform Security Services」。

資格証明管理

Oracle Platform Security Services内で実行された資格証明管理操作が表示されます。

「コンポーネント固有」→「Oracle Platform Security Services」。

フェデレーション・ユーザー・アクティビティ

Oracle Identity Federation内のフェデレーション・ユーザー・アクティビティのリストが表示されます。

「コンポーネント固有」→「Oracle Identity Federation」。

メッセージ整合性の施行

Oracle Web Services Manager内のメッセージ整合性に関連した施行が表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」→「ポリシー施行」。

同じIPの複数ログイン

様々なユーザー・アカウントに正常にログインにするマシンのリストが表示されます。

共通レポート→ユーザー・アクティビティ。

パスワード変更

様々なアカウントで実行されたパスワードの変更が表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

ポリシー・アタッチメント

Webサービス・エンドポイントへのポリシー・アタッチメントが表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」。

ポリシー施行

Oracle Web Services Managerに対する一般的なポリシー施行がリスト表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」→「ポリシー施行」。

プロファイル管理イベント

ディレクトリ統合プラットフォームのプロファイルに対する変更が表示されます。

「コンポーネント固有」→「ディレクトリ統合プラットフォーム」。

リクエスト・レスポンス

Webサービスで送信されたリクエストと受信したレスポンスが表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」。

システム・ポリシー管理

システム・レベルのポリシー管理操作が表示されます。

「コンポーネント固有」→「Oracle Platform Security Services」。

違反

施行違反が表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」→「ポリシー施行」。

Webサービスのポリシー管理

ポリシー管理操作が表示されます。

「コンポーネント固有」→「Oracle Web Services Manager」→「ポリシー管理」。

C.2.5.2 Oracle Business Intelligence Publisherの監査レポートの属性

表C-7に、各種監査レポートに表示される属性のリストを示します。レポートを表示する際は、この表を使用すると、レポートに表示される属性の詳細がわかります。

次の点に注意してください。

- 各レポートにすべての属性が表示されるとはかぎりません。

- 各レポートに表示されるユーザーまたはユーザー属性は、レポートによって意味が異なる場合があります(この属性の説明は、表C-6を参照してください)。

- Oracle Business Intelligence Publisher監査レポートにすべての属性が表示されるとはかぎりません。カスタム・レポートに属性を追加する場合は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

表C-7 監査レポートの属性

属性

説明

アクティビティ

アクションのタイプ(ユーザーによって起動されたか、システムによって起動されたか)

アプリケーション名

アプリケーションの完全なパスと名前。

Application Serverインスタンス

使用中のApplication Serverのインスタンス

試行済

試行されたアクション(ユーザーによって試行されたシングル・サインオンなど)

コンポーネント名

コンポーネント・インスタンスの名前

コンポーネント・タイプ

コンポーネントのタイプ(Oracle Identity Federationなど)

ドメイン名

Oracle WebLogic Serverのドメイン名。

ECID

実行コンテキストID

イベント・タイプ

発生したイベントのタイプ(アカウントの作成など)

Initiator

イベントを起動したユーザー

インターネット・プロトコル・アドレス、IPアドレス

アクション起動元ユーザー・マシンのIPアドレス

メッセージ・テキスト

メッセージのテキスト、イベントの説明

ポリシー名

アクションに関与するポリシーの名前

時間範囲

この時間範囲を使用すると、データセットを特定の時間間隔(最後の24時間など)に限定することができます。

タイムスタンプ

イベントの日付と時刻

トランザクションID

トランザクションの識別子。

C.3 監査レポートのカスタマイズ

この項では、拡張レポートの生成および作成オプションについて説明します。

- ビルトイン・レポートに対する拡張フィルタの使用

- カスタム・レポートの作成

C.3.1 ビルトイン・レポートに対する拡張フィルタの使用

レポートの「編集」ボタンをクリックして表示されるページでは、さらに詳細なレポート・フィルタおよびプロパティを指定できます。該当ページは、次の2つのパネルから構成されています。左のパネルを使用すると、それらのオプションによって変更するレポートの要素を選択できます。選択した要素ごとに、対応する情報が右のパネルに表示されます。

- データ・モデル - レポートの生データをフェッチするSQL問合せが含まれます。この問合せは、ニーズに合せて変更できます。

- 値リスト - レポートのすべての列が表示されます。列を選択すると、属性のデータをフィルタ処理する、基盤となるSQL問合せが表示されます。問合せは、必要に応じて変更できます。たとえば、制限がさらに厳格なフィルタ値も指定できます。

- パラメータ - レポートのすべての列が表示されるので、列を選択し、その列の表示値を変更できます。たとえば、タイムスタンプ・フィールドの日付の表示形式も指定できます。

- レイアウトと出力フォーマット - この機能については、後述の項で説明します。

C.3.2 カスタム・レポートの作成

Oracle Business Intelligence Publisherは、カスタム・レポートを設計および作成するためのすべての機能のセットを提供します。

関連項目:

- 『Oracle Business Intelligence Publisherユーザーズ・ガイド』

- 第C.4項「監査スキーマ」

Oracle Business Intelligence Publisherを使用して既存の監査レポートをカスタマイズする基本手順を、簡単な例を使用して示します。

1. Oracle Business Intelligence Publisherに管理者としてログインします。

2. 「Oracle Fusion Middleware監査」フォルダに移動します。

3. カスタム・レポートを格納するフォルダを作成します。「フォルダとイベント・タスク」の下で、「新規フォルダ」をクリックします。
フォルダ名を入力します。

4. 監査レポートのメイン・フォルダに「Custom BI Reports」という新しいフォルダが表示されます。

5. レポート左側のアイコンをクリックして、カスタム・レポートを作成するための開始点となる既存のレポートを選択します。この例では、「すべてのイベント」レポートを選択します。

「このレポートをコピー」をクリックします。

6. すると、レポートがクリップボードにコピーされます。これを新しいフォルダに送るには、次の手順を実行します。

- 「Custom BI Reports」フォルダを選択します。

- 「フォルダとレポート・タスク」の下で、「クリップボードから貼付け」をクリックします。

- 確認を求めるダイアログ・ボックスが表示されます。「はい」をクリックします。

これで、レポートがクリップボードからカスタム・フォルダに移動されました。

- レポート左側のアイコンを選択し、「このレポートを変更」をクリックして、新しいレポートにわかりやすい名前を付けます。

7. これで、レポートをカスタマイズする準備ができました。レポート・タイトルの下にあるメニュー選択肢から「編集」をクリックします。

8. 「編集」ページが表示されます。

2つのパネルが表示されます。「一般設定」というタイトルのメイン・パネルでは、レポートのタイトルや実行時コントロールなどの基本的な機能を制御できます。このメイン・パネルの左側にある第2のパネルに表示される2組の情報を使用すると、レポートに関連するコンテンツを作成できます。

- 「値リスト」には、レポートで現在使用されているフィールドが表示されます。フィールドをクリックすると、そのフィールドを含める値の選択に使用される名前とSQL問合せがメイン・パネルに自動的に表示されます。

- 「パラメータ」には、使用可能なパラメータが表示され、ここからレポートに含めるパラメータを選択できます。パラメータのサブセットは、すでにレポートに含まれています。たとえば、userid(監査イベントのイニシエータ)はユーザー・データを提供し、timeRangeは時間範囲データを提供します。

左側のパネル上の選択肢のパレットは、状況依存型のパレットであり、レポートの作成に役立つ情報が得られます。

9. クエリー・ビルダーを使用すると、レポートに含めるデータをカスタマイズできます。たとえば、あるコンポーネントのログイン・イベントのみを含めるには、次のようにします。

- 値リストから「ComponentName」を選択し、「クエリー・ビルダー」をクリックします。

- 使用可能なコンポーネントが表にリスト表示されます。コンポーネント(たとえばJPS)を選択します。コンポーネント・イベント・フィールドを示す2つ目の表が表示されます。

- JPS表で、「IAU_EVENTTYPE」を選択します。

- 「条件」をクリックして条件「login」を入力した後、「保存」をクリックします。

10. これで、条件がレポートに含まれました。左上隅の「保存」を再度クリックして、レポート定義に対する変更をコミットしてください。

11. これで、「Custom BI Reports」フォルダ内のレポートに戻り、データを表示することができます。

C.4 監査スキーマ

第C.2項「ビルトイン監査レポート」で説明したビルトイン・レポート以外の追加の監査レポート要件がある場合は、希望のレポート作成ツールを使用してカスタム・レポートを作成できます。たとえば、ビルトイン・レポートでイベント属性のサブセットを使用している場合でも、カスタム・レポートを作成する際にはイベントの監査属性セット全体を使用できます。

表C-8および表C-9では、カスタム・レポートを作成する際に役立つ監査スキーマについて説明します。

表C-8 監査スキーマ

表名

列名

データ型

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-9は、動的メタデータ・モデルがサポートされる、監査スキーマの追加の表を示します。

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

表名

列名

データ型

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.5 監査のためのWLSTコマンド

Oracle WebLogic Serverスクリプトはコマンドラインで使用され、様々な機能を管理します。WLSTは、Oracle WebLogic Server環境で、Oracle Fusion Middlewareのコンポーネントとアプリケーションの管理に使用するコマンドライン・ユーティリティです。Oracle Enterprise Manager Fusion Middleware Controlに加えて、管理のための別のオプションが用意されています。

監査ポリシーを表示および管理するためのWLSTコマンドおよび監査ストアの構成の詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』の監査構成コマンドに関する説明を参照してください。

注意:

監査コマンドを実行するときには、Oracle CommonホームからWLSTスクリプトを呼び出す必要があります。詳細は『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

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

カスタム監査ポリシーを選択する際、イベントとともにフィルタ式を指定できるオプションがあります。

たとえば、

Host Id -eq "myhost123"

この式を使用して、特定のホストのみに対して監査イベントを有効化することができます。

この式を入力するには、Fusion Middleware Controlのフィルタ編集ダイアログまたはsetAuditPolicyコマンドを使用します。

関連項目:

- 第14.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」

- 第14.3.2項「Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理」

フィルタ式を作成する際は、いくつかの構文ルールに従う必要があります。

式は、ブール式でもリテラルでも構いません。

<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, 2006"、"06/26/2006 2:00 pm"はいずれも有効です)。

- 文字列リテラルは引用符で囲む必要があり、埋込み二重引用符をエスケープするために、バックスラッシュを使用できます。

- 数値リテラルは、通常の形式で使用できます。

例:

<Literal> ::=  <NumericLiteral> | <BooleanLiteral> | <DateTimeLiteral> | <StringLiteral><BooleanLiteral> ::= "true” | "false”

C.7 監査ファイルの命名およびロギング形式

この項では、監査ファイルのメンテナンスのルールについて説明します。

Javaコンポーネントの場合(Java EEとJava SEの両方)、audit.logファイルは監査レコードを含み、バスストップ・ファイルで構成されます。

このファイルが一杯になると(設定されている最大監査ファイル・サイズの100MBに達した場合)、その名前はaudit1.logに変わり、レコードは新しいaudit.logに書き込まれます。このファイルが一杯になると、audit.logファイルの名前は「audit2.log」に変わり、新しいaudit.logに書込みが開始されます。

構成済の最大監査ディレクトリ・サイズ(デフォルトは0、つまり無制限のサイズ)に達するまで、この処理が続きます。最大ディレクトリ・サイズに達すると、システムは最も古いauditn.logファイルを削除します。

データベース監査ストアを構成する場合、監査ローダーはこれらのファイルを読み取って、レコードをバッチ内のデータベースに転送します。audit<n>.logファイルを完全に読み取った後で、このファイルを削除します。

注意:

監査ローダーは、現在のファイル、つまりaudit.logを削除しません。アーカイブ・ファイルであるaudit<n>.logのみを削除します。

システム・コンポーネントも同じモデルに従いますが、ファイル名が若干異なります。ファイル名にプロセスIDが埋め込まれるため、プロセスIDが11925であれば、現在のファイルはaudit-pid11925.logとなり、ローテーション後にaudit-pid11925-1.logとなります。

動的モデルの監査定義を持つアプリケーションについては、ファイル名形式はaudit_major version number_minor version number.logになります(例: audit_1_2.log)。

次にサンプルのaudit.logファイルを示します。

#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key
#Remark Values:ComponentType="JPS"
2008-12-08 10:46:05.492 - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - -

このファイルはW3C拡張ロギング形式に従っています。これは、多くのWebサーバー(ApacheやIISなど)で使用される一般的なログ形式です。

- 1行目は、#Fields行であり、ファイルのその他の箇所にあるフィールドをすべて指定します。

- 2行目は、#Remarkなどのコメントであり、ComponentTypeなどの共通属性を示すコメントが記載されます。

- 後続行はすべて、データ行であり、#Fields行で定義した形式に従います。属性はすべて空白で区切られ、複合属性はダッシュを使って示されます。

D ユーザーおよびロールAPIリファレンス

この付録には、ユーザーおよびロールAPIに基づいてLDAPディレクトリのアプリケーションを開発する際に必要となる参照情報が含まれています。

注意:

ユーザーおよびロールAPIは非推奨です。ユーザーおよびロールAPIを使用するアプリケーションは、アイデンティティ・ディレクトリ・サービスAPIに移行する必要があります。詳細は第23章を参照してください

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

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

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

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

- 第D.4項「Microsoft Active Directoryのためのセキュアな接続」

関連項目:

第22章「ユーザーおよびロールAPIを使用した開発」

注意:

IBM Tivoliディレクトリ・パラメータは、openLDAPに対して指定するものと同じです。

Microsoft ADAMパラメータは、Microsoft Active Directoryに対して指定するものと同じです。

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

表D-1は、UserProfile.propertyの各ユーザー属性と、異なるディレクトリ・サーバーにおけるその対応する属性を示しています。

表D-1 UserProfile.Propertyのユーザー属性

属性

Oracle Internet Directory

Oracle WebLogic Server組込みLDAP

Microsoft Active Directory

Oracle Directory Server Enterprise Edition

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

注意:

username* : 通常UIDですが、技術的にはサブスクライバのOracleコンテキスト製品の共通エントリのorclCommonNicknameAttributeで指定される属性です。

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

表D-2は、UserProfile.propertyの各ロール属性と、異なるディレクトリ・サーバーにおけるその対応する属性を示しています。

表D-2 LDAPディレクトリのロール属性の値

ロール属性

Oracle Internet Directory

Oracle WebLogic Server組込みLDAP

Microsoft Active Directory

Oracle Directory Server Enterprise Edition

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 デフォルトの構成パラメータ

この項では、APIでデフォルトの構成値を使用できるパラメータと、異なるディレクトリ・サーバーにおける値のソースを示します。

表D-3は、Oracle Internet DirectoryとMicrosoft Active Directoryのソースを示しています。

表D-3 デフォルト値 - Oracle Internet DirectoryおよびMicrosoft Active Directory

パラメータ

Oracle Internet Directory

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

Binary Basic Attribute (BBA)を選択

BBAの詳細は、表の下の「注意」を参照してください。

Binary Basic
Attribute (BBA)+
{ "objectguid" , "unicodepwd" }

BBAの詳細は、表の下の「注意」を参照してください。

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole

注意:

- Basic Binary Attributesには次のものが含まれます。{"photo", "personalsignature", "audio","jpegphoto", "Java SErializeddata", "thumbnailphoto", "thumbnaillogo", "userpassword", "usercertificate", "cacertificate", "authorityrevocationlist", "certificaterevocationlist", "crosscertificatepair", "x500UniqueIdentifier"}

- #configは、ディレクトリに存在するメタ情報から抽出されます。

- #schemaは、ディレクトリのスキーマから抽出されます。

表D-4は、Oracle Directory Server Enterprise EditionとNovell eDirectoryのソースを示しています。

表D-4 デフォルト値 - Oracle Directory Server Enterprise EditionおよびNovell eDirectory

パラメータ

Oracle Directory Server Enterprise Edition

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

Binary Basic Attribute (BBA)を選択

BBAの詳細は、表の下の「注意」を参照してください。

Binary Basic
Attribute (BBA)+
{ "guid"}

BBAの詳細は、表の下の「注意」を参照してください。

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole

注意:

- Basic Binary Attributesには次のものが含まれます。{"photo", "personalsignature", "audio","jpegphoto", "Java SErializeddata", "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

Binary Basic Attribute (BBA)を選択

BBAの詳細は、表の下の「注意」を参照してください。

Binary Basic
Attribute (BBA)+
{ "guid"}

BBAの詳細は、表の下の「注意」を参照してください。

ST_LOGGER_NAME

oracle.idm.userrole

oracle.idm.userrole

注意:

- Basic Binary Attributesには次のものが含まれます。{"photo", "personalsignature", "audio","jpegphoto", "Java SErializeddata", "thumbnailphoto", "thumbnaillogo", "userpassword", "usercertificate", "cacertificate", "authorityrevocationlist", "certificaterevocationlist", "crosscertificatepair", "x500UniqueIdentifier"}

- #configは、ディレクトリに存在するメタ情報から抽出されます。

- #schemaは、ディレクトリのスキーマから抽出されます。

表D-6は、Oracle WebLogic Server LDAPのパラメータを示しています。

表D-6 デフォルト値 - Oracle WebLogic Server LDAP

パラメータ

Oracle WebLogic Server組込み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

D.4 Microsoft Active Directoryのためのセキュアな接続

Active Directoryでは、パスワードのような機密情報を設定する際に、接続でSSLが有効である必要があります。そのため、(パスワードを設定する)ユーザーの作成のような操作は、接続でSSLが有効にされていない場合成功しません。

E スクリプトおよびMBeanプログラミングを使用した管理

この付録では、WLSTコマンドとMBeanプログラミングを使用して実行される拡張管理タスクについて説明します。

次の項目について説明します。

- 第E.1項「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」

- 第E.2項「MBeanを使用したOPSSサービスの構成」

- 第E.3項「アクセス制限」

E.1 スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成

アプリケーションでユーザーおよびロールAPIを使用しており、デフォルト属性(cn)とは異なる認証プロバイダのユーザー属性にアクセスする必要がある場合には、WebLogic管理コンソールを使用して、必要なユーザー属性を使用できるように認証プロバイダを構成します。デフォルトとは異なる属性を使用するユーザーおよびロールAPI以外でも、認証プロバイダの適切な初期化は必要です。

次の手順では、スクリプトを使用して認証プロバイダの初期化を変更する方法について説明します。これにより、構成されたユーザー属性をユーザーおよびロールAPIで使用して、構成された認証プロバイダのデータにアクセスできるようになります。

WebLogicスクリプトの詳細は、『WebLogic Scripting Toolの理解』を参照してください。

サービス・インスタンスのカスタム・プロパティを追加または更新するには、次の手順を実行します。

1. 次のコンテンツを含むpyスクリプト・ファイルを作成します。

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. wlst.shファイルが格納されているディレクトリ$ORACLE_HOME/common/binに変更します。

>cd $ORACLE_HOME/common/bin

4. 次のコマンドを実行します。

>wlst.sh /tmp/updateServiceInstanceProperty.py -si servInstName -key propKey -value propValue

説明:

- servInstNameは、変更対象のプロパティがあるサービス・インスタンス・プロバイダの名前です。

- propKeyは、挿入または変更するプロパティの名前を識別します。

- propValueは、追加または更新する値の名前です。

空白文字が含まれている引数は、二重引用符で囲む必要があります。

前述のコマンドが起動するたびに、渡されたインスタンス・プロバイダにプロパティを追加または更新することによって、ドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。渡されたキーが既存のプロパティの名前と一致する場合、そのプロパティは渡された値で更新されます。

5. Oracle WebLogicサーバーを再起動します。構成に加えられた変更は、サーバーを再起動しないと有効になりません。

使用例

ここでは、ドメイン構成ファイルに、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>

前述の構成を使用して認証プロバイダが初期化されると、ユーザーおよびロールAPIは、ユーザー属性mailを使用して、この認証プロバイダのユーザー情報にアクセスできます。

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

Oracle Platform Security Servicesには、Oracle Enterprise Manager Fusion Middleware ControlおよびOPSSのセキュリティ・スクリプトによってOracle Platform Security Servicesの管理、構成および監視に使用されるJMX準拠のJava EE Beansが用意されています。

MBeansは、Java EEアプリケーションでのみ使用することをお薦めします。

OPSS MBeans API javadocを含むOPSS API javadocsへのリンクは、第G.1項の「OPSS APIリファレンス」に記載されています。

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

- サポートされるOPSS MBeansのリスト

- OPSS MBeanの起動

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

E.2.1 サポートされるOPSS MBeansのリスト

表E-1は、サポートされるMBeansとその基本機能、およびタスクを実行するためにカスタム・スクリプトまたは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を起動するには、次の2つの基本的な方法があります。

- Oracle WebLogic Scripting Toolを使用してスクリプトを作成し、実行します(詳細は、『WebLogic Scripting Toolの理解』の「MBeanの移動(WLSTオンライン)」を参照してください)。

- Javaプログラムを作成します。第E.2.3項の「OPSS MBeansを使用したプログラミング」に、このアプローチを説明するサンプル・プログラムが記載されています。

注意:

別の方法として、Fusion Middleware ControlでMBeanブラウザを使用してMBeanを起動することもできます。ただし、この方法ではかぎられた操作しか実行できず、データの作成手順も複雑です。

このブラウザにアクセスするには、Fusion Middleware Controlにログインし、次の手順を実行します。

1. 該当するドメインで、メニュー項目「管理サーバー」→「システムMBeanブラウザ」を選択し、「システムMBeanブラウザ」ページを表示します。

2. 階層が表示されているペインで、ノード「アプリケーション定義のMBeans」、「com.oracle.jps」および「ドメイン: myDomain」(この場合のmyDomainはユーザーのドメイン名です)を開きます。この最後のノードの下には、OPSS MBeanごとに1つのノードが表示されます。

3. このいずれかのノードを開いた後で、アイテムとしてMBeanを選択し、右ペインの「属性」、「操作」および「通知」の各タブを使用して、現在の属性値を調べるか、選択したMBeanのメソッドを起動します。

たとえば、「Jps Configuration MBean」は、この階層の次の場所にあります。

Application Defined MBeans/com.oracle.jps/Domain:myDomain/JpsConfig/JpsConfig

このブラウザの詳細は、Fusion Middleware Controlのオンライン・ヘルプ・システムを参照してください。

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

次のサンプル・コードは、WebLogic Server t3プロトコルを使用してJps Configuration MBeanを起動する方法を示しています。このサンプルでは、次の重要な点に留意してください。

- 次のJARファイルがクラスパスに入っていることを前提とします。

- $ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-api.jar

- $ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-mbeans.jar

- $ORACLE_HOME/oracle_common/modules/oracle.jmx_11.1.1/jmxframework.jar

- $ORACLE_HOME/oracle_common/modules/oracle.idm_11.1.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};
//code source 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();
}
}
}

プログラムによるサービスの構成の詳細は、第IV部「Oracle Platform Security ServicesのAPIを使用した開発」を参照してください。

E.3 アクセス制限

ここでの説明はOPPS MBeansにのみ限定されるものではなく、Oracle Fusion Middleware MBeans全般に当てはまります。

MBeansへのセキュリティ・アクセスは、セキュリティ許可ではなく、論理ロールに基づいています。MBeansには、JMX Frameworkによって実行時に適用されるロールベースの制約を使用して注釈が付けられます。

この項では、注釈の使用法や注釈の意味について説明し、特定のアクセス制限を示して、Oracle WebLogic Serverエンタープライズ・グループへの論理ロールのマッピングについて解説します。

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は、ユーザーがsetメソッドsetActiveにアクセスするには、Adminロールに属している必要があることを指定します。

- @OperationRequiredGlobalSecurityRoleは、ユーザーがMBeanメソッドsetActiveVirtualScreenIdにアクセスするには、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が含まれています。

詳細は、oracle.jmx.framework Javadocのドキュメントを参照してください。

E.3.2 WebLogicロールへの論理ロールのマッピング

表E-2は、エンタープライズ・グループへの論理ロールのマッピングを示しています。

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

論理ロール

デフォルトの権限

WebLogicグループ

Admin

すべてのMBeansへの読取り/書込み権限

Admin

Configurator

構成MBeansへの読取り/書込み権限

Admin

Operator

構成MBeansへの読取り権限、すべての実行時MBeansへの読取り/書込み権限

Operator

Monitor

すべてのMBeansへの読取り権限

Monitor

ApplicationAdmin

すべてのアプリケーションMBeansへの読取り/書込み権限

Admin

ApplicationConfigurator

すべてのアプリケーションMBeansへの読取り/書込み権限

Admin

ApplicationOperator

アプリケーション構成MBeansへの読取り権限、アプリケーション実行時MBeansへの読取り/書込み権限

Operator

ApplicationMonitor

すべてのアプリケーション実行時MBeansおよび構成MBeansへの読取り権限

Monitor

WebLogicのロールの詳細は、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』の「ユーザー、グループ、セキュリティ・ロール」を参照してください。

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

デフォルトでは、すべての書込みおよび更新操作の実行には、ユーザーがAdminロールまたはConfiguratorロールのメンバーである必要があります。また、タグ@Impact(value=1)で注釈を付けられた操作の場合、ユーザーはAdminロールのメンバーであり、タグ@Impact(value=0)で注釈を付けられた操作の場合はAdminロールまたはOperatorロールのメンバーである必要があります。

表E-3は、Fusion Middleware Control MBeansの属性と操作へのアクセスに必要なロールを説明しています。

表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のシステム・プロパティ(サーバー起動時にスイッチ-Dを使用して設定)および構成プロパティ(構成ファイルjps-config.xmlで要素<property>および<extendedProperty>を使用して設定)について説明します。

次の項目について説明します。

- 第F.1項「OPSSシステム・プロパティ」

- 第F.2項「OPSS構成プロパティ」

サーバー・プロパティをプログラムによって管理するには、OPSS MBeansを使用します。詳細と例は、第E.2.3項「OPSS Mbeansを使用したプログラミング」を参照してください。

注意:

すべてのOPSSの構成変更を有効にするには(手動で、またはJpsConfiguration MBeanを使用して)、サーバーを再起動する必要があります。

OPSSのデータ・ドメイン変更は、サーバーを再起動しなくても有効になります。データの変更には、アプリケーション・ポリシーの変更と、資格証明の作成、削除または更新があります。

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

導入または変更したシステム・プロパティは、サーバーを再起動するまで有効になりません。システム・プロパティを設定するには、管理者はsetDomainEnv.shシェル・スクリプトを編集し、そのスクリプト内の環境変数EXTRA_JAVA_PROPERTIESにプロパティを追加する必要があります。

表F-1は、OPSSで使用可能なシステム・プロパティを示しています。

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

名前

説明

common.components.home

共通のコンポーネント・ホームの場所を指定します。

SEアプリケーションの場合、必須です。

デフォルト値なし

java.security.debug=access,failure

JpsAuth.checkPermissionメソッドがSubject.doAsブロック内で呼び出されたときにパーミッション・チェックが失敗すると、その失敗について通知します。

setting jps.auth.debugまたはjps.auth.debug.verboseだけでは、この場合に失敗の通知を受け取ることはできません。

オプション。

java.security.policy

Javaセキュリティ・ポリシー・ファイルの場所を指定します。

jps.app.permissioncollectionmap.size

メモリーに保持されるpermissioncollectionmapエントリの数を制御します。各エントリは、パーミッションのセットに相当します。この設定を有効にするには、プロパティjps.policystore.ref.useSoftHardMapForSelectedMapsをtrueに設定する必要があります。

オプション。

有効な値: 負でない整数。

デフォルト値: 512。

jps.authz

実行時およびデバッグのオーバーヘッドを軽減するJDK APIのAccessController.checkPermissionのコールの委任を有効または無効にします。

オプション。

有効な値: NULL、SM、ACCおよびDEBUG_NULL

デフォルト値なし

jps.auth.debug

サーバーのロギング出力を制御します。デフォルト値はFALSEです。詳細は、第J.1.2.1項「jps.auth.debug.」を参照してください。

オプション。

jps.auth.debug.verbose

サーバーのロギング出力を制御します。デフォルト値はFALSEです。詳細は、第J.1.2.2項「jps.auth.debug.verbose」を参照してください。

オプション。

jps.combiner.optimize

サブジェクトの保護ドメインのキャッシュを有効または無効にします。

オプション。

有効な値: TRUE、FALSE

デフォルト値: FALSE

jps.combiner.optimize.lazyeval

パーミッション・チェックのトリガー時にサブジェクトの保護ドメインの評価を有効または無効にします。

オプション。

有効な値: TRUE、FALSE

デフォルト値: FALSE

jps.combinermap.size

メモリーに保持されるcombinermapエントリの数を制御します。各エントリは、プリンシパルのセットに相当します。この設定を有効にするには、プロパティ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

混合モードを有効または無効にします。

混合モードを使用すると、Sun java.security.PolicyからOPSS Java PolicyProviderへの移行が容易になります。混合モードが有効になっている場合、OPSS Java Policy Providerでは、java.policyとsystem-jazn-data.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

グループ・メンバーシップの変更が有効になるまでの秒数を指定します。

この値はWebLogic認証プロバイダのGroup Hierarchy Cacheの値と同期している必要があります。Group Hierarchy Cacheの値を変更した場合は、新しい値に一致するようにjps.subject.cache.ttlをリセットする必要があります。

オプション。

有効な値: 任意の正の整数。

デフォルト値: 60000

jps.subjectmap.size

メモリーに保持されるsubjectmapエントリの数を制御します。各エントリは、サブジェクトに関する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

指定した部分文字列を含むアプリケーション・ロール名をログに記録します。一致対象の部分文字列を指定しないと、すべてのアプリケーション・ロール名が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第J.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.permeffect

指定した値に従って、付与された権限または拒否された権限をログに記録します。値を指定しないと、(付与または拒否にかかわらず)すべての権限が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第J.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.permclassname

指定した名前に完全一致するパーミッション・クラス名をログに記録します。一致対象の名前を指定しないと、すべてのパーミッション・クラス名が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第J.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.permtarget.substring

指定した部分文字列を含むパーミッション・ターゲット名をログに記録します。一致対象の部分文字列を指定しないと、すべてのパーミッション・ターゲットが記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第J.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.enterprise.principalname

指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)名をログに記録します。一致対象の名前を指定しないと、すべてのプリンシパル名が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第J.1.2.3項「認可プロセスのデバッグ」を参照してください。

wlst.offline.log

オフラインのWLSTコマンドを実行する際は、ログ・ファイルの場所を指定します。

オプション。

デフォルト値なし

有効な値: <filename>、stdout、strerr、disable。

wlst.offline.log.priority

通知のレベルを指定します。

オプション。

デフォルト値なし

有効な値: OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、ALL、デバッグ、情報、警告、エラー、致命的。

F.2 OPSS構成プロパティ

この項では、様々なインスタンスのプロパティについて説明します。この項の内容は次のとおりです。

- ポリシー・ストアのプロパティ

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

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

- LDAPベースのすべてのインスタンスに共通するプロパティ

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

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

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

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

F.2.1 ポリシー・ストアのプロパティ

次の各項では、ポリシー・ストアのプロパティについて説明します。

- ポリシー・ストアの構成

- 実行時ポリシー・ストアの構成

F.2.1.1 ポリシー・ストアの構成

LDAPベースまたはDBベースのインスタンスで使用できるポリシー・ストア・プロバイダ・クラスは次のとおりです。

oracle.seurity.jps.internal.policystore.ldap.LdapPolicyStoreProvider

表F-2は、ポリシー・ストア・インスタンスのプロパティを示しています。このプロパティのリストは、使用可能なアプリケーションの種類に基づく3つのブロックで構成されています。

表F-2 ポリシー・ストアのプロパティ

名前

説明

次のプロパティは、Java EEアプリケーションとJava SEアプリケーションの両方で有効です。

bootstrap.security.principal.key

LDAPポリシー・ストアにアクセスするためのパスワード資格証明のキーで、CSFストアに格納されています。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

出荷時の値はbootstrapです。

bootstrap.security.principal.map

LDAPポリシー・ストアにアクセスするためのパスワード資格証明のマップで、CSFストアに格納されています。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値: BOOTSTRAP_JPS

oracle.security.jps.farm.name

LDAPポリシー・ストア内のドメイン・ノードのRDN形式。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

oracle.security.jps.ldap.root.name

LDAPポリシー・ストア内のルート・ノードのRDN形式。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

ldap.url

LDAPポリシー・ストアのURLです。形式は、ldap://host:portです。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアにのみ適用されます。

必須。

デフォルト値なし

policystore.type

LDAPポリシー・ストアのタイプ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

値の例: OID、DB_ORACLE

oracle.security.jps.policystore.resourcetypeenforcementmode

次のいずれかのチェックに合格しなかった場合に、例外のスローを制御します。

- 2つのリソース・タイプが同じパーミッション・クラスの場合、そのパーミッションはResourcePermissionまたは拡張AbstractTypedPermissionでなければならず、この最後のリソース・タイプが作成不可能であることの確認。

- すべてのパーミッションにリソース・タイプが定義されており、リソース・マッチャ・パーミッション・クラスと付与するパーミッションが一致することの確認。

Strictに設定した場合、前述のいずれかのチェックで不合格になると、例外がスローされ、操作が中止されます。

Lenientに設定した場合、前述のいずれかのチェックで不合格になっても、例外はスローされません。操作は途切れることなく続行され、検出されたあらゆる矛盾がログ・ファイルに記録されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

オプション。

デフォルト値: Lenient

有効な値: Strict、Lenient

次のプロパティは、Java EEアプリケーションでのみ有効です。

datasource.jndi.name

JDBCデータ・ソース・インスタンスのJNDI名。

Java EEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

必須。

デフォルト値なし

failover.retry.times

再試行回数。

Java EEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

オプション。

デフォルト値: 3

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

jdbc.url

JBDCのURL。

Java SEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

必須。

デフォルト値なし

値の例: jdbc:oracle:thin:@xxx27.com:1345:asi102cn

eclipselink.jdbc.read-connections.min

JDBC読取り接続プールで使用できる最小接続数。

Java SEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

オプション。

デフォルト値: 5

eclipselink.jdbc.read-connections.max

JDBC読取り接続プールで使用できる最大接続数。

Java SEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

オプション。

デフォルト値: 20

例1

次のコードは、Java EEアプリケーションで使用するLDAPベースのポリシー・ストア・インスタンスの構成を示しています。

<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=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"/>
<property value="STATIC" name="oracle.security.jps.policystore.rolemember.cache.type"/>
<property value="FIFO" name="oracle.security.jps.policystore.rolemember.cache.strategy"/>
<property value="1000" name="oracle.security.jps.policystore.rolemember.cache.size"/>
<property value="true" name="oracle.security.jps.policystore.policy.lazy.load.enable"/>
<property value="PERMISSION_FIFO" name="oracle.security.jps.policystore.policy.cache.strategy"/>
<property value="1000" name="oracle.security.jps.policystore.policy.cache.size"/>
<property value="true" name="oracle.security.jps.policystore.refresh.enable"/>
<property value="43200000" name="oracle.security.jps.ldap.policystore.refresh.purge.timeout"/>
<property value="600000" name="oracle.security.jps.ldap.policystore.refresh.interval"/>
</serviceInstance>

例2

次のコードは、Java SEアプリケーションで使用するLDAPベースのポリシー・ストア・インスタンスの構成を示しています。

<serviceInstance name="policystore.oid" provider="policy.oid">
<property value="OID" name="policystore.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>

Java SEアプリケーションの構成の追加サンプルは、第20.1.2項「LDAPベースのポリシー・ストアと資格証明ストアの構成」を参照してください。

例3

次の例は、Java EEアプリケーションで使用するDBベースのストア(ランタイム・サービス・プロバイダのインスタンスを含む)の構成を示しています。

<jpsConfig>
...
<propertySets>
<!-- property set props.db.1 common to all DB services -->
<propertySet name="props.db.1">
<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="policystore.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="keystore.provider.type"  value="db"/>
</serviceInstance>

<serviceInstance name="pdp.service" provider="pdp.service.provider">
<property name="sm_configuration_name" value="permissionSm"/>
<property name="work_folder" value="../../tempdir/permissionSm-work"/>
<property name="authorization_cache_enabled" value="true"/>
<property name="role_cache_enabled" value="true"/>
<property name="session_eviction_capacity" value="500"/>
<property name="session_eviction_percentage" value="10"/>
<property name="session_expiration_sec" value="60"/>
<property name="failover.retry.times"  value="5"/>
<property name="failover.retry.interval" value="20"/>
<property name="oracle.security.jps.policystore.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="policystore.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>

Java SEアプリケーションの構成の追加サンプルは、第20.1.3項「DBベースのOPSSセキュリティ・ストアの構成」を参照してください。

F.2.1.2 実行時ポリシー・ストアの構成

LDAPベースまたはDBベースのインタンスで使用できる実行時ポリシー・ストア・プロバイダ・クラスは、次のとおりです。

oracle.seurity.jps.az.internal.runtime.provider.PDPServiceProvider

表F-3は、ポリシー・ストア・インスタンスの実行時のプロパティを示しています。

表F-3 実行時のポリシー・ストアのプロパティ

名前

説明

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.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.refresh.permissions.invalidate.threshold

パーミッションのキャッシュが無効になるまでのユーザーのパーミッションの数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

オプション。

デフォルト値: 50。

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アプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: システムの一時フォルダ。

oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled

認可キャッシュを有効にするかどうかを指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

有効な値: TRUE、FALSE

デフォルト値: FALSE

oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage

削除容量に達したときに削除するセッションの比率。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: 10

oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionCapacity

維持する認可とロールのマッピング・セッションの最大数。最大数に達すると、古いセッションが削除され、必要になったときに再確立されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: 500

oracle.security.jps.pdp.AuthotizationDecisionCacheTTL

セッション・データをキャッシュする秒数。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: 60

oracle.security.jps.policystore.resourcetypeenforcementmode

次のいずれかのチェックに合格しなかった場合に、例外のスローを制御します。

- 2つのリソース・タイプが同じパーミッション・クラスの場合、そのパーミッションはResourcePermissionまたは拡張AbstractTypedPermissionでなければならず、この最後のリソース・タイプが作成不可能であることの確認。

- すべてのパーミッションにリソース・タイプが定義されており、リソース・マッチャ・パーミッション・クラスと付与するパーミッションが一致することの確認。

Strictに設定した場合、前述のいずれかのチェックで不合格になると、例外がスローされ、操作が中止されます。

Lenientに設定した場合、前述のいずれかのチェックで不合格になっても、例外はスローされません。操作は途切れることなく続行され、検出されたあらゆる矛盾がログ・ファイルに記録されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

オプション。

デフォルト値: Lenient

有効な値: Strict、Lenient

F.2.2 資格証明ストアのプロパティ

表F-4は、資格証明ストア・インスタンスのプロパティを示しています。このプロパティのリストは、使用可能なアプリケーションの種類に基づく2つのブロックで構成されています。

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

名前

説明

次のプロパティは、Java EEアプリケーションでのみ有効です。

bootstrap.security.principal.key

LDAP資格証明ストアにアクセスするためのパスワード資格証明のキーで、CSFストアに格納されています。

Java EEアプリケーションでのみ有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

出荷時の値はbootstrapです。

bootstrap.security.principal.map

LDAP資格証明ストアにアクセスするためのパスワード資格証明のマップで、CSFストアに格納されています。

Java EEアプリケーションでのみ有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値: BOOTSTRAP_JPS

次のプロパティは、Java EEアプリケーションとJava SEアプリケーションの両方で有効です。

oracle.security.jps.farm.name

LDAP資格証明ストア内のドメイン・ノードのRDN形式。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

oracle.security.jps.ldap.root.name

LDAPポリシー・ストア内のルート・ノードのRDN形式。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアとDBストアに適用されます。

必須。

デフォルト値なし

ldap.url

LDAP資格証明ストアのURLをldap://host:portの形式で指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

LDAPストアにのみ適用されます。

必須。

デフォルト値なし

encrypt

資格証明を暗号化するかどうかを指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

ファイルおよびLDAPストアにのみ適用されます。

有効な値: true、false

オプション。

デフォルト値: false

次のコードは、Java EEアプリケーションの資格証明ストアの構成を示しています。

<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://myHost.com:1234" name="ldap.url"/>
<property value="true" name="encrypt"/>
</serviceInstance>

F.2.3 LDAPアイデンティティ・ストアのプロパティ

表F-5は、LDAPベースのアイデンティティ・ストア・インスタンスのプロパティを示しています。拡張プロパティはその旨明示しています。それぞれのプロパティに対応する、ユーザーおよびロールAPIのプロパティも示しています。

関連項目:

第8章「アイデンティティ・ストア・サービスの構成」

表F-5 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

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"/>

注意:

認証プロバイダ属性usernameを変更した場合(たとえば、プロビジョニング後またはテスト環境から本番環境への移行時)、それに応じてアイデンティティ・ストア・サービスのアイデンティティ・ストア・サービス・パラメータusername.attrも変更する必要があります。これらの2つの値は同じにしておく必要があります。

次のコード例は、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>

F.2.4 LDAPベースのすべてのインスタンスに共通するプロパティ

表F-6は、あらゆるサービス・インスタンスで指定できる、LDAPベースのストアの汎用的なプロパティを示しています。

LDAPベースのアイデンティティ・ストアのサービス・インスタンスの場合は、ユーザーおよびロールAPIでJNDI接続ファクトリを使用するときに接続プールのプロパティが必ず選択されるように、アイデンティティ・ストアのサービス・インスタンスで次のプロパティを指定する必要があります。

<property
name="INITIAL_CONTEXT_FACTORY" value="com.sun.jndi.ldap.LdapCtxFactory"/>

表F-6 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

次のコードは、いくつかのプロパティの構成を示しています。

<jpsConfig ... >
...
<!-- 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"/>
...
</jpsConfig>

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

表F-7は、ファイルベース、LDAPベースまたはDBベースの匿名ユーザー、匿名ロールおよび認証ロールの構成に使用できるプロパティを示しています。

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

名前

説明

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

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

表F-8は、トラスト・サービスの構成に使用できるプロパティを示しています。

表F-8 トラスト・サービスのプロパティ

名前

説明

trust.keystoreType

トラスト・サービス・ストアのタイプ、JKSまたはKSSを指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

有効な値: JKSまたはKSS。

デフォルトなし。

指定されていない場合は、KSSストアがすでにプロビジョニングされていれば、値はKSSに設定されます。それ以外の場合はJKSに設定されます。

trust.keyStoreName

trust.keystoreTypeがKSSに設定されている場合にのみ適用し、次の形式でストア名を指定します。

kss://<stripeName>/<keyStoreName>

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: kss://opss/trustservice_ks。

trust.trustStoreName

trust.keystoreTypeがKSSに設定されている場合にのみ適用し、次の形式でストアのURLを指定します。

kss://<stripeName>/<keyStoreName>

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: kss://opss/trustservice_ts。

trust.aliasName

キーストアからX.509証明書と秘密鍵を取得するために使用する別名を指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: WLSドメインの名前。

trust.issuerName

トークンに含める名前を指定します。発行先のトラスト・サービスにより、トークンを取得して検証するために使用されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: WLSドメインの名前。

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

trust.keystoreTypeがJKSに設定されている場合にのみ適用し、キーストアにアクセスするための資格証明のキーを指定します(マップはtrust.csf.mapにより設定されます)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.sig.csf.keyの値。

trust.token.includeCertificate

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>

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

表F-9は、監査サービスの構成に使用するプロパティを示しています。

表F-9 監査サービスのプロパティ

プロパティ

説明

必須

値

デフォルト値

auditstore.type

監査メタデータ・ストアのタイプ。

はい

file、ldapまたはdb

file

audit.filterPreset

監査のレベル。

いいえ

None、Low、MediumまたはHigh

なし

audit.customEvents

Customの場合、監査の対象となる監査イベントのリスト。イベントは、コンポーネント・タイプを使用して修飾する必要があります。イベントはカンマ、コンポーネント・タイプはセミコロンで区切ります。

例:

JPS:CheckAuthorization, CreateCredential; OIF:UserLogin

いいえ

audit.specialUsers

filterPresetがNoneの場合もアクティビティが常に監査の対象となる1名以上のユーザーから構成されるリスト。

カンマが含まれるユーザー名は、適切にエスケープ処理する必要があります。たとえば、Fusion Middleware Controlを使用する場合、3名のユーザーは"admin, fmwadmin, cn=test\,cn=user\,ou:ST\,L=RS\,c=is\,"のように指定します。

WLSTの場合は、バックスラッシュ(\)もエスケープ処理する必要があります。例:

setAuditPolicy(addSpecialUsers="cn=orcladmin\\\,cn=com")

詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

いいえ

audit.maxFileSize

監査イベントが書き込まれるバスストップ・ファイルのサイズを制御しますバイト単位

いいえ

104857600

audit.loader.interval

監査ローダーがデータベースにアップロードする頻度を制御します。秒単位

いいえ

15秒

audit.loader
.repositoryType

監査イベントのストア・タイプ。タイプがデータベース(DB)の場合は、audit.loader.jndiまたはJDBCプロパティも定義します。

はい

File、DB

File

audit.loader.jndi

データベースに監査イベントをアップロードするための、アプリケーション・サーバー内のデータソースのJNDI名。

いいえ

jdbc/AuditDB

audit.db.principal.map / audit.db.principal.key

JavaSEで実行されており、repositoryTypeがDBの場合の、ブートストラップ資格証明ストア内のJDBCユーザー名とパスワード資格証明に対するマップとキー。

いいえ

audit.loader.jdbc.string

JavaSEで実行されており、repositoryTypeがDBの場合の、JDBC接続に対するJDBC文字列。

いいえ

audit.logDirectory

バスストップ・ファイルのベース・ディレクトリ。

JavaSEでは必須

jse

audit.timezone

Oracle WebLogic ServerタイムスタンプまたはUTCのどちらでイベントを記録するかを決定します。詳細は、14.4項を参照してください。

いいえ

utc、local

utc

audit.change.scanning.
interval

LDAPベースまたはDBベースの監査ストアを使用した分散環境では、監査サービスは、インスタンスを実行する各OPSSの監査実行時ポリシーの変更を監視し、任意のキャッシュ済のポリシーを動的に再ロードします。

このプロパティは、任意の変更をサービスがチェックする頻度をミリ秒単位で決定します。

いいえ

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/AuditDB"/>
<property name="audit.loader.repositoryType" value="DB" />
<property name="auditstore.type" value="file"/>
<property name="audit.timezone" value="local" />
</serviceInstance>

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

表F-10は、キーストア・サービスの構成に使用するプロパティを示しています。

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

プロパティ

説明

必須

値

デフォルト

keystore.provider.type

キーストア・リポジトリのタイプ。

はい

file、ldap、db

file

keystore.file.path

ファイル・プロバイダが構成されている場合のkeystores.xmlファイルの場所。

ファイルベースのキーストア・プロバイダが構成されている場合は、はい。

-

./

ca.key.alias

キーストア・サービス・インスタンスに使用されているサード・パーティCAのsystem/castore内のキー別名。

いいえ

-

-

location

キーストアの場所。絶対パスまたは相対パスを指定できます。

keystore.typeがJKSの場合は、はい。keystore.typeがPKCS11またはHSM (LunaSA)の場合は、いいえ。

キーストアへのパス

./default-keystore.jks

keystore.type

キーストアのタイプ。

はい

JKS、PKCS11、Luna

JKS

keystore.csf.map

Oracle Web Services Managerによって使用される資格証明ストア・マップ名。

はい

資格証明ストアのマップ名

oracle.wsm.security

keystore.pass.csf.key

キーストア・パスワードを指す資格証明ストア・キー。

JKSおよびPKCS11の場合は、はい。HSMの場合は、いいえ。

資格証明ストアのcsfキー名

keystore-csf-key

keystore.sig.csf.key

キーストア内の署名鍵の別名およびパスワードを指す資格証明ストアのキー名。HSMの場合は、資格証明ストアのキー名ではなく、ダイレクト・キー別名になります。

はい

資格証明ストアのcsfキー名、またはHSMの場合はダイレクト別名

sign-csf-key

keystore.enc.csf.key

キーストア内の暗号化鍵の別名およびパスワードを指す資格証明ストアのキー名。HSMの場合は、資格証明ストアのキー名ではなく、ダイレクト・キー別名になります。

はい

資格証明ストアのcsfキー名、またはHSMの場合はダイレクト別名

enc-csf-key

次の例は、ファイルベースのプロバイダに対するキーストア・サービスの構成を示しています。

<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>

次の例は、LDAPベースのプロバイダに対するキーストア・サービスの構成を示しています。

<serviceInstance name="keystore" provider="keystore.provider"       location="./default-keystore.jks">
<description>Default JPS Keystore Service</description>
<property name="keystore.provider.type" value="ldap"/>
<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>

次の例は、RDBMSベースのプロバイダに対するキーストア・サービスの構成を示しています。

<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="keystore.provider.type"  value="db"/>
<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>

G OPSS APIリファレンス

この付録には、OPSS APIのリファレンスが含まれています。

次の項では、使用可能なOPSS APIのリストを示します。

- 第G.1項「OPSS APIリファレンス」

G.1 OPSS APIリファレンス

次のJavadocドキュメントでは、OPSSが公開している様々なAPIを説明しています。

OPSS API

Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services

OPSS MBean API

Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services Mbeans

OPSSユーザーおよびロールAPI

Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services

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

この付録では、アイデンティティ・ストアでOpenLDAP 2.2を使用する場合に必要となる特殊な設定について説明します。

内容は次のとおりです。

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

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

OpenLDAP 2.2をアイデンティティ・ストアとして使用するには、次のようにします。

1. WebLogic Server管理コンソールを使用して、新しい認証プロバイダを作成します。この新規プロバイダに対して:

- 認証元のリストから「OpenLDAPAuthenticator」を選択します。

- OpenLDAPAuthenticatorの制御フラグをSUFFICIENTに設定します。

- DefaultAuthenticatorの制御フラグをSUFFICIENTに設定します。

- OpenLDAPAuthenticatorがリストの先頭になるように認証元の順序を変更します。

- OpenLDAPAuthenticatorの「プロバイダ固有」ページで、「ユーザー・ベースDN」と「グループ・ベースDN」を入力し、「名前指定によるグループ・フィルタ」のオブジェクト・クラスの値をgroupofnames以外の値に設定します。

2. OpenLDAPインストールのホーム・ディレクトリから、次の手順を実行します。

- ファイルslapd.confを編集のために開きます。

- このファイル内の一番上にあるincludeセクションに次の行を挿入します。

include ./schema/inetorgperson.schema

- ファイルを保存し、OpenLDAPを再起動します。

前述の設定を行うと、OpenLDAPで新規の外部ロールを作成するたびに、オブジェクト・クラスinetorgpersonをその外部ロールに追加できます。外部ロールをアプリケーション・ロールにマッピングするためには、このオブジェクト・クラスが必要です。

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

第8.3項「アイデンティティ・ストア・サービスの構成」で説明しているID仮想化機能では、分割プロファイルをサポートするために追加の構成がいくつか必要です。この付録では、分割プロファイルに使用されるアダプタの作成方法および管理方法について説明します。

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

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

- 第I.2項「分割プロファイルの構成」

- 第I.3項「結合ルールの削除」

- 第I.4項「結合アダプタの削除」

- 第I.5項「アダプタの可視性の変更」

- 第I.6項「Identity Virtualization Libraryに対するアクセス・ログの有効化」

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

ID仮想化機能を使用すると、OPSSで複数のLDAPディレクトリを問い合せることができます。たとえば、Oracle Internet DirectoryとMicrosoft Active Directory両方のデータを1つの問合せでフェッチできます。

ID仮想化では「分割プロファイル」のファイルがサポートされています。分割プロファイルでは、アプリケーションが、2つの異なるソースに格納されている単一IDの属性を使用します。たとえば、ある人間のユーザー名、パスワードおよび従業員IDがMicrosoft Active Directoryに格納されていて、その人間の従業員IDと業務上の役割がOracle Internet Directoryに格納されている場合です。

たとえば、WebCenterアプリケーションが、複数のソース・ディレクトリから単一IDの属性を取得する必要がある場合には、分割プロファイルを使用して、ID仮想化の結合機能を活用します。これらの結合では、標準的な結合アダプタが使用されます。詳細は、次を参照してください:

- 『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のOracle Virtual Directoryのアダプタの理解に関する項

- 『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』の結合ビュー・アダプタの理解に関する項

アダプタ構成はadapters.os_xmlに格納されていますが、ホスト、ポート、バックエンド・ディレクトリの資格証明など、接続に関する詳細はOPSSから取り込まれます。

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

同じユーザーが両方のアイデンティティ・ストアに存在していて、それぞれのストアでユーザー属性が別々になっています。ユーザー・レコードを問い合せる場合には、両方のストアのデータが必要です。構成タスクは次のとおりです。

1. virtualizeプロパティを使用してアイデンティティ・ストア・サービスを構成し、複数のLDAPストアに対して問合せができるようにします。
詳細は、第8.3項「アイデンティティ・ストア・サービスの構成」を参照してください。

2. WebLogic管理サーバーに接続してコマンドを実行し、アイデンティティ・ストアの結合アダプタを構成します。使用可能なWLSTコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のLibrary Oracle Virtual Directory (LibOVD)コマンドに関する説明を参照してください。
WLSTプロンプトを呼び出す方法の詳細は、『Oracle Fusion Middlewareの管理』のコマンドライン・ツールの使用の概要に関する説明を参照してください。

情報の参照先

3. プライマリ・アイデンティティ・ストアに結合アダプタを作成します。

createJoinAdapter(adapterName="Join Adapter Name",  root="Namespace", primaryAdapter="Primary adapter Name")

4. セカンダリ・ストアに結合ルールを追加します。

addJoinRule(adapterName="Join Adapter Name", secondary="Secondary Adapter Name", condition="Join Condition")

注意:

セカンダリ・アイデンティティ・ストアが複数ある場合は、セカンダリ・ストアごとにaddJoinRuleコマンドを実行します。

5. modifyLDAPAdapterコマンドを実行します。

modifyLDAPAdapter(adapterName="AuthenticatorName", attribute="Visible", value="Internal")

注意:

セカンダリ・アイデンティティ・ストアが複数ある場合は、セカンダリIDストアごとにmodifyLDAPAdapterコマンドを実行します。

例

この例では、同じユーザーが2つのストアに存在していて、最初のストアはMicrosoft Active Directory、2番目のストアはOracle Internet Directoryです。この例では、Microsoft Active Directoryがプライマリ・ストア、Oracle Internet Directoryがセカンダリ・ストアと想定しています。

注意:

LDAP接続のパラメータを構成するときには、user.create.basesとgroup.create.basesがプライマリ・アダプタのネームスペースに対応している必要があります。パラメータの詳細は、第8.3.1項「構成内容」を参照してください。

認証プロバイダ1
認証プロバイダ名: Microsoft Active Directory (AD)
ユーザー・ベース: cn=users,dc=acme,dc=com
認証プロバイダ2
認証プロバイダ名: Oracle Internet Directory (OID)
ユーザー・ベース: cn=users,dc=oid,dc=com
拡張プロファイルを実装する手順は次のとおりです。

1. 結合アダプタを作成します。

createJoinAdapter(adapterName="JoinAdapter1", root="dc=acme,dc=com", primaryAdapter="AD")

ここに示したアダプタ名はあくまで例で、実際に使用するときには適切な名前を使用してください。

2. 結合ルールを指定します。

addJoinRule(adapterName="JoinAdapter1", secondary="OID", condition="uid=cn")

「uid=cn」は前述の例における結合条件で、Oracle Internet Directory(セカンダリ)のユーザーのuidの値がMicrosoft Active Directory(プライマリ)のユーザーのcnの値と一致した場合に属性が組み合されることを示しています。

条件の左側の属性がセカンダリ・アダプタの属性で、右側の属性がプライマリ・アダプタの属性です。

3. アダプタを変更します。

modifyLDAPAdapter(adapterName="OID", attribute="Visible", value="Internal")

modifyLDAPAdapter(adapterName="AD", attribute="Visible", value="Internal")

ここで使用されているアダプタ名は認証プロバイダの実際の名前です。プライマリとセカンダリすべてのパラメータにあるアダプタ名は、認証プロバイダ名も参照しています。結合アダプタ名には、どのような名前を選択してもかまいません。

4. WebLogic管理サーバーと管理対象サーバーを再起動します。

I.3 結合ルールの削除

removeJoinRuleコマンドを使用して、結合アダプタから結合ルールを削除します。

構文

removeJoinRule

adapterName ="アダプタ名"

secondary="結合ルールに関連付けられているセカンダリ・アダプタ"

例

removeJoinRule(adapterName="JoinAdapter1", secondary="OID")

I.4 結合アダプタの削除

deleteAdapterコマンドを使用して、結合アダプタを削除します。

構文

deleteAdapter(adapterName="名前")

例

deleteAdapter(adapterName="JoinAdapter1")

I.5 アダプタの可視性の変更

modifyLDAPAdapterコマンドを使用して、アダプタの可視性を変更します。例:

modifyLDAPAdapter(adapterName="AuthenticatorName", attribute="Visible", value="Yes")

I.6 Identity Virtualization Libraryに対するアクセス・ログの有効化

Identity Virtualization Libraryに対してアクセス・ログを有効化すると、Identity Virtualization Libraryを通過するすべてのリクエストおよびレスポンスを捕捉できます。これは、パフォーマンスの問題を選別する場合に大変便利です。

Identity Virtualization Libraryに対してアクセス・ログを有効化する手順は、次のとおりです。

1. デバッグ・モードで前に構成されたIdentity Virtualization Libraryログ出力をすべて削除します。実際のパフォーマンス数値を調べるには、これらのログ出力を削除する必要があります。

2. WebLogic ServerにNOTIFICATIONレベルでoracle.ods.virtualization.accesslogという名前のWebLogicログ出力を作成します。

3. ovd-access.logに類似したファイル名を指定してWebLogicログ・ハンドラを作成し、そのログ・ハンドラを手順2で作成したログ出力と関連付けます。
このログ・ハンドラは、すべてのOracle Virtual Directoryアクセス・ログ・メッセージを別のファイルに記録します。

4. DOMAIN_HOME/config/fmwconfig/ovd/default/provider.os_xmlファイルのバックアップを作成し、次の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の管理サーバーおよび管理対象サーバーを再起動します。

これで、Oracle Virtual Libraryによってovd-access.logファイルにアクセス・ログを生成できるようになります。

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

この付録では、OPSSの構成および使用時に発生する可能性のある一般的な問題と、それらの解決方法について説明します。

次の項目が含まれます。

- 第J.1項「セキュリティ・エラーの診断」

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

- 第J.3項「サーバーの起動のトラブルシューティング」

- 第J.4項「パーミッションのトラブルシューティング」

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

- 第J.6項「Oracle Business Intelligenceレポート作成のトラブルシューティング」

- 第J.7項「検索のトラブルシューティング」

- 第J.8項「バージョニングのトラブルシューティング」

- 第J.9項「その他のエラーのトラブルシューティング」

- 第J.10項「追加のヘルプ」

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

この項では、様々なセキュリティ・エラーの診断と解決に利用できるツールについて説明します。次の項目が含まれます。

- ログ・ファイルとOPSSロガー

- システム・プロパティ

- セキュリティ・エラーの解決

Fusion Middleware Controlでは、フォルトの管理、分離または解釈に役立つ可能性がある場合は、ロギングのサポートが明示的に提示されます。

J.1.1 ログ・ファイルとOPSSロガー

次の各項では、Oracle WebLogic Serverでサポートされている様々なログ・ファイルとOPSSロガーを紹介し、Fusion Middleware ControlおよびWLSTコマンドでロガー・レベルの構成と設定、およびログ・ファイルの検索と表示を行う方法について説明します。

- 診断ログ・ファイル

- 一般的なログ・ファイル

- 認可ロガー

- オフラインWLSTコマンド・ロガー

- その他のOPSSロガー

- ユーザーおよびロールAPIロガー

- 監査ロガー

- Fusion Middleware Controlを使用したロガーの管理

- スクリプトを使用したロガーの管理

J.1.1.1 診断ログ・ファイル

ドメイン内の各サーバー・インスタンスは、そのサブシステムとアプリケーションで発生したOPSSベースのすべての例外を、ローカル・ホスト・コンピュータのファイル・システムにあるサーバー・ログ・ファイルに書き込みます。

デフォルトでは、このログ・ファイルは、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName-diagnostic.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。

診断ファイルの完全な名前の例を、いくつか次に示します。DomainName/servers/AdminServer/logs/AdminServer-diagnostic.log00001(管理サーバー・ログ)、DomainName/servers/soa/logs/soa-diagnostic.log00013(管理対象サーバー・ログ)。

すべてのサーバー・インスタンスは、セキュリティ関連のエラーを診断ファイルに出力します。サーバー関連のセキュリティ・エラー(サブジェクトやプリンシパルの問題で発生した例外など)、およびドメイン・セキュリティ・データを移行または再関連付けするときに発生する可能性のあるエラーは、管理サーバー診断ログに書き込まれます。アプリケーション関連のセキュリティ・エラー(アプリケーション固有のポリシーまたは資格証明で発生した例外など)は、対応する管理対象サーバーの診断ログに書き込まれます。

J.1.1.2 一般的なログ・ファイル

Oracle WebLogic Serverでは、診断ログ・ファイルに加えて、ドメイン内の各サーバーおよびトポロジ内の各ドメインに関するその他のログ・ファイルがサポートされています。

デフォルトでは、サーバー・ログ・ファイルは、診断ログ・ファイルと同様に、サーバー・インスタンス・ルート・ディレクトリの下のlogsディレクトリにあります。ドメイン・ログ・ファイルは、管理サーバー・ルート・ディレクトリの下のlogsディレクトリにあります。これらのログ・ファイルの名前の形式は、ServerName.logxxxxxおよびdomain.logxxxxxとなっています。ここで、xxxxxは1から99999の整数を示します。

サーバー・ログ・ファイルおよびドメイン・ログ・ファイルの完全な名前の例を、いくつか次に示します。DomainName/servers/AdminServer/logs/AdminServer.log00001、DomainName/servers/AdminServer/logs/domain1.log00033。

認証プロバイダまたはその他のドメイン・サービス・プロバイダで発生した例外など、一般的なエラーを探す場合には、サーバーおよびドメインのログ・ファイルを調べます。

ドメイン・ログは、(そのドメイン内のサーバーに対する)サーバー・ログに書き込まれたメッセージと一部重複しており、多数のサーバーを含むドメインで、フォルトが発生したサーバーの特定に役立ちます。

注意:

新しいログ・ファイルの生成は、そのローテーション・ポリシーによって決まり、ローテーションは通常、ファイル・サイズによって決まります。そのため、ログ・ファイルが指定されたサイズを超えると、整数の接尾辞が1つ増えた名前を持つ、新しいログ・ファイルが生成されます。

特定のロガーの詳細は、「認可ロガー」および「監査ロガー」を参照してください。

関連ドキュメント

サーバー・ログ・ファイルとドメイン・ログ・ファイルについては、『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する説明を参照してください。

Oracle WebLogicフレームワークについては、『Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

ロギング・サービスの詳細は、『Oracle WebLogic ServerにデプロイされたアプリケーションへのWebLogicロギング・サービスの追加』を参照してください。

Oracle Fusion Middlewareへのログインの詳細は、『Oracle Fusion Middlewareの管理』の「ログ・ファイルと診断データの管理」を参照してください。

J.1.1.3 認可ロガー

OPSSでは、実行時の認可の失敗をトラブルシューティングするのに役立つ2つのロガーを提供しています。

- oracle.security.jps.util.JpsAuth

- oracle.security.jps.trace.logger

この2つのロガーは、他のOPSSロガーと同様に、有効と無効を動的に切り替えることができます。つまり、Oracle WebLogic Application Serverを停止して再起動する必要はありません。ロガーのプロパティを設定する方法の詳細は、「Fusion Middleware Controlを使用したロガーの管理」を参照してください。通常、ロガーのレベルはTRACE:32に設定されます。

追加のロガーの詳細は、「その他のOPSSロガー」を参照してください。

J.1.1.3.1 oracle.security.jps.util.JpsAuth

ロガーoracle.security.jps.util.JpsAuthは、メソッドcheckPermissionの起動とリターンをログに記録し、ログ・ファイルの次のスニペットは、ログ・ファイル内のこのメソッドに対する開始境界と終了境界を示しています。

[SRC_CLASS: oracle.security.jps.util.JpsAuth] [APP: JeeScenarioApp]
[SRC_METHOD: Entering checkPermission] ENTRY
(oracle.security.jps.ResourcePermission
resourceType=TaskFlowResourceType,resourceName=ResourceNameX read)

[SRC_CLASS: oracle.security.jps.util.JpsAuth] [APP: JeeScenarioApp]
[SRC_METHOD: Exiting checkPermission] RETURN
java.security.AccessControlException: access denied (oracle.security.jps.ResourcePermission
resourceType=TaskFlowResourceType,resourceName=ResourceNameX read)

次のスニペットは、成功した場合の認可ログを示しています。

[JpsAuth] Check Permission
PolicyContext: [JeeScenarioApp]
Resource/Target: [getSubjectFromDomainCombiner]
Action:[null]
Permission Class: [javax.security.auth.AuthPermission]
Result:               [SUCCEEDED]
Subject:              [null]
Evaluator:            [SM]

次のスニペットは、失敗した場合の認可ログを示しています。

[JpsAuth] Check Permission
PolicyContext: [JeeScenarioApp]
Resource/Target: [resourceType=TaskFlowResourceType,resourceName=ResourceNameX]
Action:[read]
Permission Class: [oracle.security.jps.ResourcePermission]
Result:               [FAILED]
Evaluator:            [ACC]
Failed

J.1.1.3.2 oracle.security.jps.trace.logger

ロガーoracle.security.jps.trace.loggerは、アプリケーション・ロール、パーミッション、ターゲット、プリンシパルおよび付与されたポリシーと拒否されたポリシーに関する情報をログに記録します。このロガーを有効にすると、出力が大きくなる可能性があるため、単一使用ケースのデバッグにのみ使用することをお薦めします。具体的には、このロガーは次のものを記録します。

- 認可リクエストに関する次の情報。エンタープライズ・ロールに付与されたアプリケーション・ロール、すべての拒否と付与、パーミッション・クラス名、パーミッション・ターゲットおよびプリンシパル名。

- ロールにプリンシパルが追加されたときなどの、メンバー・キャッシュの更新。キーワード: 「プリンシパル:」、「挿入されたロール:」。

- 情報を管理するロール。キーワード: 「アプリケーション内:」、「プリンシパルのクエリー・ストア:」、「ダイレクト・アプリケーション・ロールの数:」。

- メソッドgetPermissionsに対するコール。

J.1.1.4 オフラインWLSTコマンド・ロガー

migrateSecurityStoreなどのオフラインWLSTコマンドの使用時には、次のシステム・プロパティを指定してJVMを起動することにより、OPSSロガーを有効にできます。

-Dwlst.offline.log
-Dwlst.offline.log.priority

これらのプロパティを次のように設定します。

- 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.1.1.5 その他のOPSSロガー

認可ロガーに加えて、OPSSは次のロガーを提供します。

oracle.jps.commonは、OPSS JpsFilterおよびOPSS JpsInterceptorに関する問題の診断を可能にします。

oracle.jps.deploymentは、アプリケーションのデプロイ時に、アプリケーションとパッケージ化されたOPSSアーティファクトに関する問題の診断を可能にします。キーワード:「移行」。

oracle.jps.openazは、PEP APIコールに関する問題の診断を可能にします。oracle.jps.openaz.levelをFINESTに設定すると、送信されたリクエストに関する情報(アイデンティティ、リソース、アクション、コンテキスト)および認可結果が記録されます。

J.1.1.6 ユーザーおよびロールAPIロガー

OPSSユーザーおよびロールAPIコールを追跡するには、oracle.idm.userroleapiロガーをTRACE:32に設定します。

J.1.1.7 監査ロガー

Fusion Middleware監査フレームワークには、いくつかのランタイム・コンポーネントがあります。この項では、これらのコンポーネントの診断ログ・ファイルを紹介し、診断メッセージの解釈方法について説明します。

これらのログ・ファイルは、次の場所にあります。

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

表J-1は、様々な診断ログ・ファイルを示しています。

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

コンポーネント

ログの保存場所

ロガーの構成

監査APIを使用するJava EEコンポーネント

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

監査APIを使用するOPMNコンポーネント

第J.1.1.7.3項を参照してください。

第J.1.1.7.3項を参照してください。

起動クラス監査ローダー

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(この表の下の手順を参照)

監査スキーマ・サポート

RCUログの保存場所(デフォルトでは$ORACLE_HOME/rcu/log/): この場所を変更するにはRCU_LOG_LOCATIONを設定します。

RCUログ・レベル(デフォルトではERROR): RCU_LOG_LEVEL - [SEVERE; ERROR; NOTIFICATION; TRACE

J.1.1.7.1 監査ロガーの構成

Fusion Middleware Controlを使用してoracle.security.audit.loggerを構成できます。

oracle.security.audit.loggerでは、ERRORからTRACEまでの任意のログ・レベルを設定し、ログに記録される情報の量を制御できます。

Fusion Middleware Controlを使用して、これらの診断ファイルを表示することもできます。

関連項目:

次の各項の詳細は、『Oracle Fusion Middlewareの管理』の第10章「ログ・ファイルと診断データの管理」を参照してください。

- ロガーの構成手順

- ドメイン、サーバーおよび各アプリケーションのログ表示に関する詳細

J.1.1.7.2 監査診断の解釈

監査診断メッセージは、エラー・メッセージとトレース・メッセージという2つのタイプに分類できます。

すべてのエラー・メッセージには、IAU-XXXという番号が付けられます。これらのメッセージについては、考えられる原因とエラーへの対処方法が記載されたエラー・メッセージ・ガイドを参照してください。

これに対し、トレース・メッセージは、実行されているコンポーネントの詳細情報を示すためのものです。メッセージの性質に応じて、なんらかの処置が必要になることもあります。

J.1.1.7.3 OPMNコンポーネント用の監査ログの構成

OPMNで管理されるシステム・コンポーネントの監査ログを構成できます。

auditconfig.xml構成ファイルを使用して、コンポーネントの監査ログを書き込むログ・ディレクトリの場所を指定できます。LogsDirectory要素を使用して、監査ログの場所を指定します。次の例では、ログは/tmp/audit/auditlogsにあります。

<LogsDirectory>
<MaxFileSize></MaxFileSize>
<Location>/tmp/audit/auditlogs</Location>
</LogsDirectory>

J.1.1.8 Fusion Middleware Controlを使用したロガーの管理

Fusion Middleware Controlには、ログ情報を管理するためのページがいくつか用意されています。このツールを使用して、次の操作を実行できます。

- ログのレベルとローテーションなど、ログ・ファイルの属性を構成します。

- ドメイン内にあるすべてのログ・ファイルのコンテンツを検索し、メッセージID別またはタイプ別に問合せ結果をグループ分けします。

- コンテキストまたは期間により特定のエラーとその他のエラーの相関を分析します。

- ログ・ファイルの一部または問合せ結果を複数のフォーマットのいずれかでダウンロードします。

この項では、ログ・ファイルの構成方法について簡単に説明します。前述の他の機能についても、第J.1.3項「セキュリティ・エラーの解決」に簡単な説明があります。

これらの各項のすべての詳細は、『Oracle Fusion Middlewareの管理』のログ・ファイルと診断データの管理に関する説明を参照してください。

Fusion Middleware Controlを使用してログ・ファイルを構成するには、次の手順を実行します。

1. 「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。このページを使用して、永続ロガーとアクティブなランタイム・ロガーの両方に対するログ・レベルを構成できます。

2. 必要なログ出力に対するログ・ファイル・エントリをクリックして、そのファイルに対する現在のパラメータ設定を示すページを表示します。

3. このページで、行を選択し、「構成の編集」ボタンをクリックして、「ログ・ファイルの編集」ダイアログ・ボックスを表示します。このダイアログ・ボックスで、ログ・レベルやローテーション・ポリシーなどの様々なパラメータを設定できます。通常は、ロガー・レベルをTRACE:32に設定します。

Fusion Middleware Controlでロガーが表示されないように指定するには、次の手順を実行します。

1. 「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。

2. 「ログ・レベル」タブの「表示」プルダウンから、「永続ログ・レベル状態のログ出力」を選択します。

3. ページ下部の「ログ出力の指定」領域で、ロガー名を入力し、「Oracle Diagnostic Loggingレベル(Javaレベル)」・プルダウンからロガーのレベルを選択します。

J.1.1.9 スクリプトを使用したロガーの管理

次の呼出しのように、setLoggerLevelスクリプトを使用してロガーを管理できます。

setLogLevel(logger="oracle.idm.userroleapi", level="TRACE:32", addLogger=1, persist=1)

J.1.2 システム・プロパティ

デバッグ出力を増やすには、Oracle WebLogic Serverを起動するスクリプトに次のシステム・プロパティを設定して、サーバーを再起動します。

- jps.auth.debug

- jps.auth.debug.verbose

認可プロセス中のデバッグ出力を取得するには、「認可プロセスのデバッグ」の項で説明しているいずれかのシステム・プロパティを設定してください。

サーバー起動時に渡すことができ、セキュリティ問題のデバッグに役立つ可能性のあるその他の2つのシステム・プロパティを、次に示します。

- -DDebugOPSSPolicyLoading、OPSSポリシー・プロバイダの進行状況と設定を監視するフラグ。

- -Djava.security.debug=policy、ファイル・システム内の保存場所、付与されるパーミッション、および署名付きコードに使用される証明書など、解析したポリシー・ファイルに関する印刷情報を生成する、標準のJavaセキュリティ・デバッグ・フラグ。

注意:

ロギング出力を高く設定すると、特にファイルのロード時に、スタック状態のスレッドが多数レポートされる可能性があります。この状況を避けるには、Oracle WebLogic Serverでスレッドをスタックとしてマークするために使用するタイムアウト値を、より高い値に変更します。

サーバーを再起動せずにシステム・プロパティを設定することはできません。システム・プロパティを設定するには、管理者はsetDomainEnv.shシェル・スクリプトを編集し、そのスクリプト内の環境変数EXTRA_JAVA_PROPERTIESにプロパティを追加する必要があります。

J.1.2.1 jps.auth.debug

次のシステム・プロパティのみをtrueに設定すると仮定します。

-Djps.auth.debug=true

この場合、パーミッション・チェックが失敗すると出力が生成され、次の例に示すような詳細が表示されます。

[JpsAuth] Check Permission
PolicyContext:        [jps-wls-Demo]
Resource/Target:      [app.monitor]
Action:               [read,write]
Permission Class:     [java.util.PropertyPermission]
Evaluator:            [ACC]
Result:               [FAILED]
Failed ProtectionDomain:ClassLoader=weblogic.servlet.jsp.JspClassLoader@fb111c finder: weblogic.utils.classloaders.CodeGenClassFinder@106bb21 annotation:
CodeSource=file:/C:/MyOracle/domains/base_domain/servers/AdminServer/tmp/_WL_user/jps-wls-Demo/kebqfo/jsp_servlet/test.class
Principals=total 5 of principals(
1. weblogic.security.principal.WLSUserImpl "duane"
2. weblogic.security.principal.WLSGroupImpl "employee"
3. JpsPrincipal: oracle.security.jps.principals.JpsAuthenticatedRoleImpl "authenticated-role"
4. JpsPrincipal: oracle.security.jps.principals.JpsAnonymousRoleImpl "anonymous-role"
5. JpsPrincipal: oracle.security.jps.service.policystore.ApplicationRole "appRoleEmployee")
Permissions=(
(java.util.PropertyPermission line.separator read)
...
(oracle.security.jps.service.credstore.CredentialAccessPermission context=SYSTEM,mapName=default,keyName=* read,write))

パーミッション・チェックが成功した場合は、何も出力されません。パーミッション・チェックのメッセージを無効にするには、このプロパティをfalseに設定します。デフォルトで、これはtrueに設定されています。本番環境では、パーミッション・チェック・メッセージの無効化はお薦めしません。

J.1.2.2 jps.auth.debug.verbose

jps.auth.debugとjps.auth.debug.verboseを両方ともtrueに設定すると仮定します。

-Djps.auth.debug=true
-Djps.auth.debug.verbose=true

この場合、パーミッション・チェックが成功すると出力が生成され、次の例に示すような詳細が表示されます。

[JpsAuth] Check Permission
PolicyContext:        [jps-wls-Demo]
Resource/Target:      [app.monitor]
Action:               [read,write]
Permission Class:     [java.util.PropertyPermission]
Result:               [SUCCEEDED]
Subject:              [total 5 of principals(
1. weblogic.security.principal.WLSGroupImpl "manager"
2. weblogic.security.principal.WLSUserImpl "shawn"
3. JpsPrincipal: oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl "authenticated-role" GUID=null DN=null
4. JpsPrincipal: oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl "anonymous-role" GUID=null DN=null
5. JpsPrincipal: oracle.security.jps.service.policystore.ApplicationRole "appRoleManager" GUID=null DN=null)]
Evaluator:            [ACC]

パーミッション・チェックが失敗すると、次のような詳細な情報を記録した出力が生成されます。

JpsAuth] Check Permission
PolicyContext:        [jps-wls-Demo]
Resource/Target:      [app.monitor]
Action:               [read,write]
Permission Class:     [java.util.PropertyPermission]
Evaluator:            [ACC]
Result:               [FAILED]
Failed ProtectionDomain:ClassLoader=weblogic.servlet.jsp.JspClassLoader@1b7682d finder: weblogic.utils.classloaders.CodeGenClassFinder@7d32cf annotation:
CodeSource=file:/C:/Mydom/domains/domain/servers/AdminServer/jspservlet/test.class
Principals=total 5 of principals(
1. weblogic.security.principal.WLSUserImpl "duane"
2. weblogic.security.principal.WLSGroupImpl "employee"
3. JpsPrincipal: oracle.security.principals.JpsAuthenticatedRoleImpl "authenticated-role" GUID=null DN=null
4. JpsPrincipal: oracle.security.principals.JpsAnonymousRoleImpl "anonymous-role" GUID=null DN=null
5. JpsPrincipal: oracle.security.jps.service.policystore.ApplicationRole "appRoleEmployee" GUID=null DN=null)
Permissions=(
(java.util.PropertyPermission line.separator read)
...
(java.lang.RuntimePermission stopThread))
Call Stack: java.security.AccessControlException: access denied (java.util.PropertyPermission app.monitor read,write)
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
...
weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
ProtectionDomains for class stack:
Class[0]: class oracle.security.jps.util.JpsAuth$Diagnostic$SMSupport
ProtectionDomain: ClassLoader=sun.misc.Launcher$AppClassLoader@360be0
CodeSource=file:/C:/MyOracle/jdeveloper/modules/oracle.jps_11.1.1/jps-api.jar
Principals=total 0 of principals<no principals>
Permissions=(
(java.io.FilePermission \C:\MyOracle\jdeveloper\modules\jps-api.jar read)
...
)
Class[1]: class oracle.security.jps.util.JpsAuth$Diagnostic$SMSupport

パーミッション・チェックのメッセージを無効にするには、jps.auth.debugとjps.auth.debug.verboseの両方をfalseに設定します。デフォルトで、jps.auth.debug.veboseはfalseに設定されています。

J.1.2.3 認可プロセスのデバッグ

この項では、各種基準に基づく認可プロセスのデバッグに役立ついくつかのその他のシステム・プロパティの使用について説明します。特に次のシステム・プロパティについて説明します。

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

これらのプロパティは、次の認可フェーズ中にロギング・メッセージを生成します。

- フェーズ1 - OPSSサブジェクト計算中にエンタープライズ・ユーザーまたはエンタープライズ・ロールに付与されたアプリケーション・ロール。

- フェーズ2 - 権限受領者に付与されたパーミッション・インスタンス。

- フェーズ3 - パーミッション・チェックの結果。つまり、権限が付与されたか、拒否されたか。

次に、前述の各プロパティと、これらが適用されるフェーズについて説明します。

oracle.security.jps.log.for.approle.substring - フェーズ1、2、3の間、指定した部分文字列を含むアプリケーション・ロール名をログに記録します。一致対象の部分文字列を指定しないと、すべてのアプリケーション・ロール名が記録されます。

oracle.security.jps.log.for.permeffect - フェーズ3の間、指定した値に従って、付与された権限または拒否された権限をログに記録します。値を指定しないと、(付与または拒否にかかわらず)すべての権限が記録されます。

oracle.security.jps.log.for.permclassname - フェーズ2および3の間、指定した名前に完全一致するパーミッション・クラス名をログに記録します。一致対象の名前を指定しないと、すべてのパーミッション・クラス名が記録されます。

oracle.security.jps.log.for.permtarget.substring - フェーズ2および3の間、指定した部分文字列を含むパーミッション・ターゲット名をログに記録します。一致対象の部分文字列を指定しないと、すべてのパーミッション・ターゲットが記録されます。

oracle.security.jps.log.for.enterprise.principalname - フェーズ1、2および3の間、指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)名をログに記録します。一致対象の名前を指定しないと、すべてのプリンシパル名が記録されます。

次の特性は、前述のシステム・プロパティのすべてに該当します。

- オプションです。

- 最大で1回のみ設定可能です。

- 一致では、大文字と小文字は区別されません(一致が適用される場合)。

前述のシステム・プロパティのロギングを有効にするには、次のようにします。

1. 必要なシステム・プロパティを設定します。

2. JVMを停止します。

3. JVMを再起動します。

4. ロガーoracle.security.jps.dbg.loggerをTRACE:32に設定します。ロガーの設定方法の詳細は、「Fusion Middleware Controlを使用したロガーの管理」を参照してください。

5. デバッグするシナリオを実行します。

6. ログ出力を調べます。前述のいずれかのプロパティの設定によるメッセージ出力を見つけるには、ログ・ファイル内でキーワード[oracle.security.jps.dbg.logger]を検索します。

J.1.2.3.1 使用例

次の例では、前述のシステム・プロパティの一般的な設定を示しています。

- 部分文字列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の両方を前述の手順で設定します。

- すべてのアプリケーション・ロール名とすべてのプリンシパル名をログに記録するには、oracle.security.jps.log.for.approle.substringもoracle.security.jps.log.for.enterprise.principalnameも設定しません。

J.1.3 セキュリティ・エラーの解決

エラーが発生したときに、そのエラーを解決する一般的な方法はありません。そのため、ヒントを検索し、できればエラーの原因を分離して理解するまで、多くの場合複数の仮定に従う必要があります。この目的を達成するために、この項では、ログ情報を検索して解釈し、最も一般的なセキュリティ・エラーを解決する方法について説明します。この項の内容は次のとおりです。

- サンプル・ログ・エントリの理解

- Fusion Middleware Controlを使用したログの検索

- Fusion Middleware Controlを使用したメッセージ・コンテキストの識別

- Fusion Middleware Controlを使用したエラー・リスト・ファイルの生成

J.1.3.1 サンプル・ログ・エントリの理解

エラーを分離して解決するには、ログ・エラー出力を理解することが重要です。ここでは、診断ログ・ファイルの内容を詳しく調べ、このファイルに記録されているエラーに関して得られる情報について説明します。この場合、実際の例を使用して説明するのが最も効果的です。

次の例は、AdminServer-diagnostic.logファイルに記載されたエラーの抜粋です。

[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を識別します。通常、イベントの順序を関連付けて追跡するために使用します。ecidは、リクエストからWebLogicサーバー、またはOracle Internet Directoryサーバーへのフローなど、プロセスをまたがるフローに関する情報を提供します。

- 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.1.3.2 Fusion Middleware Controlを使用したログの検索

ドメイン内のすべてのログ・ファイルのコンテンツで検索を開始するには、「ドメイン」→「ログ」→「ログ・メッセージの表示」を選択して、「ログ・メッセージ」ページを表示します。

このページには、検索問合せを指定するために選択できる複数のパラメータがあります。具体的には、次の操作が可能です。

- 適切な「日付範囲」を選択することで、メッセージが発行される期間を選択できます。

- 「メッセージ・タイプ」ボックスのいずれかを選択することで、特定の重大度エラーを含むメッセージを表示できます。

- 「メッセージ」メニューから項目を選択し、その横にあるボックスに文字列を入力することで、さらなる制約を満たすメッセージを表示できます。たとえば、文字列exceptionを含むメッセージに対してのみ問合せを行うことができます。

- 「フィールドの追加」ボタンをクリックし、選択肢のいずれかを選択することによって、新たな問合せフィールドを追加できます。たとえば、「ホスト」フィールドを追加し、特定の文字列を先頭文字として指定した問合せ(「次で始まる」フィールドに入力)などを実行できます。

これらのパラメータを設定して、「検索」をクリックすると、問合せの結果がこのページに表示されます。問合せの結果は、「表示」メニューから項目を選択することで、メッセージ・タイプ別、メッセージID別、またはメッセージの単純なリストで詳細に表示しなおすことができます。さらにこの結果を、ページの右上にあるメニューから項目を選択することで、自動的にリフレッシュすることもできます(デフォルトでは「手動リフレッシュ」に設定)。

検索範囲をドメインを越えたログ・ファイルにまで拡張するには、ページの右上にある「広範囲のターゲット・スコープ」ボタンを使用します。

J.1.3.3 Fusion Middleware Controlを使用したメッセージ・コンテキストの識別

場合によっては、メッセージが発生したコンテキストを知ることが必要になります。たとえば、特定のエラー・メッセージの2分前または2分後に発生したメッセージがわかると役に立つ場合があります。

「関連メッセージの表示」タブにはこの機能があります。この機能を使用する手順は次のとおりです。

1. 「表示」を「メッセージ」に設定して、問合せの結果を表示します。

2. 結果の表内でメッセージを選択します。このとき、「関連メッセージの表示」タブおよび「メッセージをファイルにエクスポート」タブが使用可能になっていることに注意してください。たとえば、選択したメッセージのタイムスタンプが、Jan 21, 2009 4:05:00 PM PSTであると仮定します。

3. 「日付範囲」メニューから「時間間隔」を選択し、「開始日」と「終了日」を入力します。たとえば、開始日としてJan 21, 2009 4:02:00 PM、終了日としてJan 21, 2009 4:07:00 PMを入力できます。

4. 「関連メッセージの表示」メニューから「時間ごと」を選択すると、選択したメッセージに関連する、指定した期間内のすべてのメッセージが表示されたページが開きます。

5. 「時間別の関連メッセージ」ページで、ページの右側にある「有効範囲」メニューから項目を選択することで、選択したメッセージの時間前後の時間ウィンドウを変更できます。

J.1.3.4 Fusion Middleware Controlを使用したエラー・リスト・ファイルの生成

別のファイルに表示されたエラーのリストをダウンロードし、転送することが必要になる場合があります(サポート・センターに転送する場合や、記録として残しておく場合など)。

「メッセージのエクスポート」タブが使用可能な場合はいつでも、メニューから項目を選択することで、表示された結果のみを含むファイルを生成できます。生成できるファイルの形式は、プレーン・テキスト、XMLまたはCSVです。

次の例は、このようにして生成されたテキスト・ファイルの抜粋であり、29件のメッセージのうちの最初の部分のみが示されています。

#
#Search Criteria
#        Start Time: 2009-01-21T16:34:41.381-08:00
#        End Time:  2009-01-21T16:39:41.381-08:00
#        Message Types: ERROR, WARNING

#Selected Targets List
#        /Farm_base_domain/base_domain/AdminServer:Oracle WebLogic Server
#        /Farm_base_domain/base_domain/AdminServer/DMS Application(11.1.1.1.0):Application Deployment
#        /Farm_base_domain/base_domain/AdminServer/em:Application Deployment
#        /Farm_base_domain/base_domain/AdminServer/wsil-wls:Application Deployment
#        /Farm_base_domain/base_domain/AdminServer/wsm-pm:Application Deployment
#
[2009-01-21T16:34:54.045-08:00] [AdminServer] [WARNING] [] [org.apache.myfaces.trinidad.bean.PropertyKey] [host: stacz39] [nwaddr: 140.87.5.40] [tid: 13] [userId: <anonymous>] [ecid: 0000HvvkgjVEîMT6uBj8EH19TvXj000008,0] [APP: em] [Target: /Farm_base_domain/base_domain/AdminServer/em] [Target Type: Application Deployment] Unserializable value:oracle.sysman.core.view.tgtctls.common.DefaultTreeModel@1fcadd2 for key:UINodePropertyKey[value,17]
…
#
#Number of messages exported: 29
#

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

この項では、次の問題について説明します。

- 再関連付けの失敗

- 移行の失敗

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

- 再関連付けしたポリシー・ストアのポリシーの欠落

- 移行の失敗

J.2.1 再関連付けの失敗

ファイルベースのストアからLDAPベースのストアへのポリシーおよび資格証明の再関連付けは、いくつかの理由で失敗することがあります。この項では、この操作が失敗する3つの理由について説明します。

現象1- エラー・コード32

再関連付けが失敗し、次のようなエラーが管理サーバー診断ファイルserverName.diagnostic.logに記録されます。

[LDAP: error code 32 - No Such Object]
Authentication to LDAP server ldap://myServer.com:3060 is unsuccessful.

診断1

前述のエラーは、LDAPサーバーのターゲット・ノードにおける問題を識別します。つまり、指定したノードが存在しません。

再関連付けを起動する前に、「JPSルートDN」テキスト・ボックス(「セキュリティ・プロバイダの設定」ページ)で指定したルート・ノードが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」ノードの子孫(正確には、孫)であることを示しています。

指定するドメインはルート・ノードの子孫であってはなりません。

解決策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 - 監査ストアが再関連付けされていない

リリース11gR1 (11.1.1.6.0)では、Fusion Middleware Control Enterprise Manager (EM)コンソールを使用してセキュリティ・ストアを再関連付けした場合、ほとんどのストア(ポリシー・ストア、資格証明ストアなど)が移動されましたが、監査ストアは移動されませんでした。これは、監査ストアでは、WLSTコマンドreassociateSecurityStoreを使用した再関連付けのみがサポートされ、コンソールを使用した再関連付けがサポートされていないためです。

診断4

リリース11gR1 (11.1.1.6.0)からリリース12c (12.1.2)への移行がEnterprise Managerを使用して行われた場合、監査リポジトリはファイルベースのまま残ります。次の解決策を使用すると、すべてのセキュリティ・ストア・データをLDAP/DBに移動して、監査を有効にできます。

解決策4

元の環境で、WLSTコマンドreassociateSecurityStoreを異なるjpsrootノードで実行します。これによって、OIDディレクトリ間の再関連付けが行われ、既存の任意のデータも新しいノードに移行されます。この動作を行った場合、監査データはファイル・ベースではなくなり、jps-configに新規ノードが含まれます。

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

この項では、LDAPサーバーへの再関連付けに失敗する理由について説明します。

現象

セキュリティ・ストアのLDAPリポジトリへの再関連付けに失敗すると、AdminServerログに、次のようなエラーがレポートされます。

[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: error code 32」のエラーは、再関連付けターゲットLDAPリポジトリのスキーマがサポートされていない、つまりターゲットLDAPリポジトリのバージョンが、OPSSでサポートされているLDAPストアのいずれでもないことを示しています。

解決策

ターゲットLDAPリポジトリをサポートされているLDAPストアのいずれかに更新して、再関連付けを再度実行します。LDAP OIDストアのバージョンは、10.1.4.3以上であることが必要です。サポートされているバージョンのリストは、第9.2項「LDAPベースのOPSSセキュリティ・ストアの使用方法」を参照してください。

J.2.3 再関連付けしたポリシー・ストアのポリシーの欠落

現象

LDAPベースのOracle Internet Directoryポリシー・ストアを使用するようにファイルベースのポリシー・ストアを再関連付けすると、この再関連付けが正常に完了したとレポートされる場合があります。

ところが、実行時にシステムが予期したとおりに動作しません。移行後にシステム・ポリシーに存在するはずのコードベースのポリシーが欠落しています。

診断

実行時にサーバーは次のようなスタック・トレースをレポートします。

<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診断ログで次のようなメッセージを確認します。

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

このタイプのメッセージは、再関連付けの際にスキーマがシードされなかったことを示しています。Oracle Internet Directoryサーバーで適切なスキーマがシードされていないと、システムは予期したとおりに動作しません。

再関連付けの際にスキーマが必ずシードされるようにするには、次の手順に従います。

1. Oracle Internet Directoryサーバーのcn=OracleSchemaVersionコンテナの下にあるcn=OPSSコンテナを削除します。

2. このファイルベースのストアを使用しているOPSSポリシー・ストアの正常に動作しているインスタンスを起動します。

3. このファイルベースのストアをOracle Internet Directoryサーバーに再関連付けします。

AdminServer診断ログで次のメッセージを探して、OPSS LDAPスキーマが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になります。

ポリシー・ストアのスキーマのバージョンは、Oracle Internet Directoryサーバーで次のコンテナによって設定されます。

cn=PolicyStore,cn=OPSS,cn=OracleSchemaVersion

同様に、資格証明ストアのスキーマのバージョンは、Oracle Internet Directoryサーバーで次のコンテナによって設定されます。

cn=CredentialStore,cn=OPSS,cn=OracleSchemaVersion

J.2.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)...

前述の抜粋はファイルserver_soa-diagnostic.logから取られたものであり、アプリケーション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_roleという名前のアプリケーション・ロールであるはずのものが、誤ってtest_rolleとスペルミスされていました。

<application>
<name>JpsJdev</name>
<app-roles>
<app-role>
<name>test_rolle</name>
<class>oracle.security.jps.service.policystore.ApplicationRole</class>
<members> ...

解決策

アプリケーション・ポリシー内で参照されているすべてのアプリケーション・ロールが、jazn-data.xmlファイルで適切に定義されていることを確認します。参照されたロール名が、前述の例のように一致しない場合、移行は失敗します。

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

この項では、Oracle WebLogic Serverの起動に失敗する理由をいくつか説明します。この項の内容は次のとおりです。

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

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

- パーミッションの欠落

- サーバーの起動の失敗

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

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

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

この項では、ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗する可能性がある理由について説明します。

現象

ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗し、出力されるエラー・メッセージに次の内容が含まれます。

java.lang.IllegalArgumentException: null KeyStore name

診断

この問題の原因の1つは、ドメイン内の認証プロバイダのリストに、LDAP認証プロバイダが含まれていないことです。

重要:

OPSSを使用するすべてのドメインで、このリストのいずれかのLDAP認証プロバイダが必須です。

解決策

サーバーを起動できず、LDAP認証プロバイダが欠落しているため、次の手順に従って、手動でLDAP認証プロバイダを追加する必要があります。

1. ファイルDOMAIN_NAME/config/config.xmlを開きます。

2. config.xmlを編集し、<realm>要素内に、次の例に示すデフォルトの認証プロバイダなどの、LDAP認証プロバイダを含めます。

<realm>
...
<sec:authentication-provider xsi:type="wls:default-authenticatorType">
</sec:authentication-provider>
...
</realm>

3. サーバーを再起動します。

サーバーが再起動して稼働したら、WebLogic管理コンソールを使用して、希望のプロバイダを含むようにプロバイダのリストを変更できますが、少なくとも1つのプロバイダをLDAP認証プロバイダにする必要があります。

この目的のために、次の手順に従って、WebLogic管理コンソールを使用します。

1. 「新しい認証プロバイダの作成」ページに移動します。

2. 認証プロバイダ名を入力して、認証プロバイダのタイプ(次に示すLDAPベースのもの)を選択します。

- ActiveDirectoryAuthenticator

- DefaultAuthenticator(これは、前述の例で手動で挿入したものです)

- LDAPAuthenticator

- LDAPX509IdentityAsserter

- OpenLDAPAuthenticator

- OracleInternetDirectoryAuthenticator

- OracleVirtualDirectoryAuthenticator

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

この項では、Oracle WebLogic Serverの起動に失敗する理由について説明します。

現象

追加設定なしで使用できるデフォルトの認証プロバイダを削除して、Oracle Internet Directory認証プロバイダなどを追加すると、サーバーの起動に失敗します。

診断

追加した認証プロバイダにAdministratorsグループのアカウント・メンバーを入力することを忘れている可能性が高いと考えられます。サーバーでは、1つのドメイン認証プロバイダにこのようなアカウントが存在することが要求されます。このアカウントは、デフォルトの認証プロバイダに常に存在します。

解決策

サーバーを起動できないため、次の手順に従って、削除された1つのLDAP認証プロバイダを手動で追加する必要があります。

1. ファイルDOMAIN_NAME/config/config.xmlを開きます。

2. config.xmlを編集し、<realm>要素内に、次の例に示すデフォルトの認証プロバイダを含めます。

<realm>
...
<sec:authentication-provider xsi:type="wls:default-authenticatorType">
</sec:authentication-provider>
...
</realm>

3. サーバーを再起動します。

サーバーが再起動して稼働したら、次の手順を実行します。

1. OID LDAP認証プロバイダにAdministratorsグループのメンバーであるアカウントを作成します。

2. Oracle Internet Directory認証プロバイダのフラグを、SUFFICIENTに設定します。

3. サーバーを再起動します。デフォルトの認証プロバイダに指定されたAdministratorsグループのアカウントを使用しているので、問題なく起動するはずです。

4. Oracle Internet Directory認証プロバイダのフラグをREQUIREDに再設定して、デフォルトの認証プロバイダを削除します。これで、Oracle Internet Directory認証プロバイダに作成したAdministratorsグループのアカウントを使用して、サーバーが起動します。

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

この項では、Oracle WebLogic Serverの起動に失敗する理由について説明します。

現象

システム・プロパティ-Djava.security.managerを使用して、セキュリティ・マネージャを有効にした状態でサーバーを起動すると、起動に失敗します。

診断

この問題が発生する理由の1つは、サーバー起動時にセキュリティ・マネージャを有効にした際、oraclepki.jarでPKI APIへのパーミッションの付与が欠落していることです。

解決策

ファイルweblogic.policyに次のような権限付与が存在することを確認し、存在しない場合は追加します。

grant codeBase "file:${oracle.home}/modules/oracle.pki_${jrf.version}/*" {
permission java.security.AllPermission;
};

デフォルトでは、前述の権限付与が指定されています。セキュリティ・マネージャを有効にした場合、すべてのシステム・リソースへのアクセスに、コードベースのパーミッション付与が要求されることに注意してください。

Java Security Managerを使用したWebLogicリソースの保護の詳細は、『WebLogicセキュリティ・サービスによるアプリケーションの開発』を参照してください。

注意:

Printing Security Managerは、Javaセキュリティ・マネージャに対するWebLogicサーバーの拡張機能です。Printing Security Managerを使用して、Javaセキュリティ・マネージャの下で実行されているJavaアプリケーションで必要なすべてのパーミッションを識別できます。必要なパーミッションを一度に1つずつ識別するJavaセキュリティ・マネージャとは異なり、Printing Security Managerは、必要なパーミッションのすべてを自動的に識別します。

J.3.4 サーバーの起動の失敗

この項では、Oracle 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.

注意:

orapkiデバッグを有効にするには、プロパティ-Doracle.pki.debug=trueを設定してサーバーを起動します。

診断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.3.5 サーバーの起動に関するその他の問題

この項では、Oracle WebLogic Serverの起動に失敗する理由をいくつか説明します。

現象

ポリシー・プロバイダをロードして設定しようとするときに、Oracle 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の定義に基づくポリシー・プロバイダのロードと設定が含まれます。このタスクが正常に終了しないと、Oracle 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. 次の2つのサンプルは、誤ったコード・ソースURLと正しいコード・ソースURLの一般的な例を示しています。

Sample 1 - Incorrect URL
<grantee>
<codesource>
<url>${my.oracle.home}/jlib/webcacheua.jar</url>
</codesource>
</grantee>

Sample 1 - Corrected URL (in bold)
<grantee>
<codesource>
<url>file:/${my.oracle.home}/jlib/webcacheua.jar</url>
</codesource>
</grantee>

Sample 2 - Incorrect URL
<grantee>
<codesource>
<url>c:/myfolder/jlib/webcacheua.jar</url>
</codesource>
</grantee>

Sample 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.3.6 サーバーの起動前のパーミッション・チェックの失敗

この項では、サーバーが起動フェーズを完了する前にパーミッション・チェックが失敗する理由について説明します。

現象

サーバーの起動前に認可チェックが失敗します。サーバーの起動が完了すると、次のような行が出力されます。

<WebLogicServer> <BEA-000365> <Server state changed to STARTING>

診断

サーバーのステータスがSTARTINGに変わる前のパーミッション・チェック・エラーは、通常、そのパーミッション・チェックに必要な認可サービスがリクエスト時に完全に初期化されていなかったことを示します。

解決策

この問題を回避するには、次の手順を実行します。

1. weblogic.policyファイルを編集して、適切な権限付与を追加します。

2. 次の2つのシステム・プロパティを設定してOracle WebLogic Serverを起動します。

- java.security.policyをweblogic.policyファイルの場所に設定します。

- jps.policystore.hybrid.modeをtrueに設定します。

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

この項では、次の問題について説明します。

- コードソースの付与のトラブルシューティング

- パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致

- 認可チェックの失敗

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

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

- 12c HA環境で認識されないアプリケーション・ポリシー

J.4.1 コードソースの付与のトラブルシューティング

この項では、コードソースの付与に関する問題の解決方法について説明します。

現象

アプリケーションで、セキュリティ管理操作を使用するための認可が拒否され、次のような例外がログに記録されます。

java.security.AccessControlException: access denied
(oracle.security.jps.service.credstore.CredentialAccessPermission
context=SYSTEM,mapName=oracle.patching,keyName=FUSION_APPS_PATCH_WLS_ADMIN-KEY read)

ログに記録されたエラーの詳細から、アプリケーションがアクセスに失敗した操作がわかります。

診断

アプリケーション・コードが次のいずれかの操作にアクセスする必要がある場合は、コードソースへの付与が必要です。

- ポリシー管理

- 資格証明管理

- キー管理

- 監査管理

注意:

コードソースの付与はシステム・ポリシーであり、アプリケーション・ポリシーにパッケージ化することはできません。

解決策

前述のような実行時の失敗を解決するには、次の手順を実行します。

1. エラーを調べ、ランタイム・システムによって確認されたコードソースURLを特定します。
URL情報が利用できない場合は、該当する特定の管理対象サーバーと管理サーバーで次のロガーを有効にして、失敗を再現します。

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);

注意:

ログ・ファイルで、コードソースはJARファイルの絶対パスで指定されますが、URLは環境変数を基準として指定されます。

2. 具体的なコードソースが特定されたら、構成済の付与をセキュリティ・ストアで表示し、適切なパーミッション、ターゲットおよびアクションが実際に指定されていることを確認します。
付与を表示するには、第10.2項「Fusion Middleware Controlを使用したポリシーの管理」の説明に従ってFusion Middleware Controlを使用するか、またはWSLTオンライン・コマンドlistCodeSourcePermissionsを使用します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

3. セキュリティ・ストアの付与がランタイム・エラーのデータと一致しない場合は、Fusion Middleware ControlまたはWSLTオンライン・コマンドgrantPermissionを使用して、付与を変更します。このコマンドの詳細は、『Oracle Fusion Middlewareインフラストラクチャ・セキュリティWLSTコマンド・リファレンス』を参照してください。

注意:

権限が付与されたブロック内でコードを実行する必要がある場合は、そのブロック内で実行されていることを確認します。

J.4.2 パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致

この項では、エンタープライズ・ユーザーまたはロール(グループ)へのパーミッションの付与または取消に失敗する、よくある理由について説明します。

現象

ドメイン認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに対して、権限付与で定義されたパーミッションが付与または取り消されません。

診断

この問題は、(ドメイン認証プロバイダに)格納されている名前と、(ユーザーがアクティブに入力したか、プログラムによって取得された)指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致の例として、格納されているユーザー名がJdOEで、指定されたユーザー名がjdoeである場合があげられます。

解決策

この問題を解決するには、次の2つの方法があります。

1つ目の解決策としては、ドメインに使用されている認証プロバイダで適切なプロパティを設定します。両方の文字列(格納されているものと指定されたもの)に、(大文字小文字関係なく)同じ順序の文字が含まれているかぎり、この設定により、対応する文字の大文字小文字が異なっている場合でも、サブジェクトに入力されたユーザー名が、ドメイン認証プロバイダに存在するユーザー名に一致することが保証されます。したがって、この設定が機能している場合、JdOEというユーザー名とjdoeというユーザー名は一致します。

ドメイン認証プロバイダのプロパティを設定するには、次の手順に従います。

1. 管理コンソールを使用して認証プロバイダの構成ページに移動します。たとえば、デフォルトの認証プロバイダを使用している場合は、「レルム」→「myrealm」→「プロバイダ」→「DefaultAuthenticator」を選択して、DefaultAuthenticatorページに移動します。

2. 「プロバイダ固有」タブを選択します。

3. プロパティuserRetrievedUserNameAsPrincipalをtrueに設定します。

4. サーバーを再起動します。

2つ目の解決策では、指定された名前をプログラムによって取得する、つまりユーザー名からプリンシパルを生成する場合を考えます。

正しいユーザーまたはグループ名を取得するには、認証プロバイダに格納されている名前を正確にそのまま渡すか、次のコード・スニペットに示すコール・シーケンスを使用します。

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);

重要:

ユーザーまたはロールのプリンシパルを作成するときには、次のコールを使用する必要があります。

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());

J.4.3 認可チェックの失敗

この項では、認可チェックが失敗する理由について説明します。

現象

アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。

Servlet failed with Exception oracle.adf.controller.security.AuthorizationException:ADFC-0619:
Authorization check failed: '/StartHere.jspx' 'VIEW'.

診断

このような認可の失敗が発生する理由の1つは、実行時ポリシー・コンテキストと、アプリケーションで使用するポリシー・ストア・ストライプとの間の不一致です。

一方では、アプリケーションで使用するアプリケーション・ストライプ(またはポリシー・ストア内のポリシーのサブセット)が、パラメータapplication.nameを含むファイルweb.xmlに指定されています。このパラメータは、JpsFilterを構成するフィルタ(サーブレットの場合)またはJpsInterceptorを構成するインターセプタ(EJBの場合)内にあります。詳細および例は、「アプリケーション名(ストライプ)」を参照してください。アプリケーション・ストライプが指定されていない(または空白になっている)場合、アプリケーション名に基づいて、アプリケーション・ストライプが取得されます。

もう一方では、アプリケーションで使用する実行時ポリシーが、要素<application.name>を含むファイルsystem-jazn-data.xmlに指定されています。

これらの2つの名前が一致しない場合、または使用するストライプを明示的に指定していない場合、アプリケーションが間違ったポリシー・ストライプにアクセスするため、予期したとおりにアプリケーション・ユーザーを認可できなくなる可能性が高くなります。

解決策

アプリケーション・ストライプを明示的に指定し、そのストライプが、アプリケーションで使用することになっているストライプであることを確認します。ほとんどの場合、(前述したように)これらの2つの異なるファイルに指定された2つの名前は一致します。ただし、複数のアプリケーションが同じポリシー・ストライプを共有する場合は、異なる可能性があります。

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

この項では、ユーザーが予期したもの以外のパーミッションを取得する、よくある理由について説明します。

現象

新しいユーザーまたは変更されたユーザーが、予期しないパーミッションを取得します。

診断

この問題は、すでに削除されたユーザーの名前を使用してユーザーを追加した場合、または古いユーザーがその名前またはuidを変更した場合に、よく起こります。ユーザーが予期したより多くの(または少ない)パーミッションを取得する、よくある理由は、ユーザーを削除する前またはユーザー・データを変更する前に、ポリシー・ストアが適切に更新されていないことです。

解決策

ユーザーを削除する前に、ユーザーに付与されていたすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに継承される可能性があります。

ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、ロール)を更新して、新しいデータでも予期したとおりに機能するようにする必要があります。

J.4.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が使用されています。

注意:

この同じ問題が、Principal[]またはPrincipalEntry[]を受け入れるバリアントをオーバーロードするメソッドrevokeにも適用されます。

J.4.6 12c HA環境で認識されないアプリケーション・ポリシー

この項では、12c HA (高可用性)ドメインでアプリケーション・ポリシーが適用されなくなる順序と、その解決方法について説明します。

現象

次の順序によって、例外がスローされます。

1. 12c HA環境で、ドメイン管理サーバーかドメイン管理対象サーバーのいずれか(一方のみ)に対して、(アプリケーション・ポリシーとパッケージ化された)カスタム・アプリケーションをデプロイします。

2. アプリケーションをアンデプロイします。

3. 手順1でデプロイしたサーバーとは異なるサーバーに、アプリケーションを再デプロイします。

前述の手順3の結果、例外が発生し、アプリケーション・ポリシーは有効になりません。この問題は、12c HAドメインでのみ検出されます。

診断

この問題は、ドメイン・サーバーでキャッシュが同期化されていないことが原因で発生します(様々なサーバーが個別のJVM (Java Virtual Machine)で実行されていることに注意してください)。

たとえば、HAドメインにサーバーA (管理サーバー)、サーバーB (管理対象サーバー)およびサーバーC (管理対象サーバー)の3つのサーバーがあるとします。さらに、アプリケーションが最初にドメイン管理サーバー(サーバーA)にデプロイされた後、3つのサーバーすべてが再起動されたとすると、(ポリシーがセキュリティ・ストアから読み込まれて)サーバーA、BおよびCのキャッシュが初期化され、同期化されます。

アプリケーションが(サーバーAから)アンデプロイされると、サーバーAのキャッシュは消去されますが、サーバーBおよびCのキャッシュは消去されません。また、アプリケーションが(たとえばサーバーBに)再デプロイされた場合は、キャッシュが同期しなくなり、例外がスローされます(これは、ポリシー・オブジェクトがすでに存在するためです)。

解決策

この問題の回避策は次のとおりです。

前述の手順2の後、手順3の前に、HAドメインのすべてのサーバーを再起動します。この手順を加えた手順によって、HAドメインのすべてのサーバーでキャッシュが同期化されるため、アプリケーション・ポリシーが予期したとおりに表示されます。

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

この項では、次の問題について説明します。

- 組込みのLDAP認証プロバイダへの接続の失敗

- LDAPサーバーへの接続の失敗

- ドメイン資格証明ストアのデータへのアクセスの失敗

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

- 匿名SSL接続の確立の失敗

J.5.1 組込みのLDAP認証プロバイダへの接続の失敗

この項では、組込みのLDAP認証プロバイダへの接続に失敗する場合に多く見られる理由について説明します。

現象

クライアント・アプリケーションがユーザーおよびロールAPIを介して組込みのLDAP認証プロバイダに問合せをリクエストするために使用される接続は、接続プールに格納され、維持されます。デフォルトおよび出荷時の状態では、このプールは、JNDIプールとしてファイルjps-config.xmlに指定されています。

このプールの同時接続数が、LDAPサービスの最大許容数を超えると、クライアント・アプリケーションはサービスに接続できなくなり、すでに接続中の場合は「ソケットがクローズされました」という例外を受信します。この場合、サーバーのログで、許容される同時接続数を超えたことが示されます。

診断

この制限を超えないようにするには、LDAPサービスで許容する最大同時接続数をアプリケーションのニーズに合わせて調整する必要があります。このしきい値はきめ細かく調整する必要があります。最大値が小さすぎると十分でなく(その結果、前述の例外が発生します)、最大値が大きすぎると、DoS攻撃のリスクが生じる場合があります。適切な最大値は、アプリケーションと、そのアプリケーションで使用する特定のLDAPサービスに依存します。

解決策

この問題の解決方法として次の2つの選択肢があります。

- その認証プロバイダで許容する最大同時接続数を増やします。

- アプリケーションで使用している認証プロバイダがWebLogic組込みの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になっています)。

注意点として、(a)これらの設定は相互排他的ではなく、両方実行することも可能なことと、(b)どちらの場合も変更を有効化するにはサーバーを再起動する必要があることに留意してください。

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

この項では、Oracle Internet Directory LDAPサーバーへの接続が失敗する場合に多く見られる理由について説明します。この失敗は、再関連付け時にも発生する可能性があります。

現象

ソース・リポジトリからターゲットLDAPサーバー・リポジトリへのデータの移行が失敗します。

診断

通常、この種の問題は、ターゲットLDAPサーバーのパラメータ設定が間違っていることが原因です。

Oracle WebLogic Serverのログ・ファイルを調査する場合は、DomainName/servers/AdminServerディレクトリまたはDomainName/servers/ManagedServersディレクトリ内のログ・ファイルで、<Error>、<Critical>および<Warning>という文字列を検索してください。

エラーを特定して解決する方法の詳細は、第J.1項「セキュリティ・エラーの診断」を参照してください。

解決策

移行用に指定したターゲット・サーバー・データが、すべて有効であることを確認します。この確認を行うために、LDAPサーバー管理者の支援が必要になる場合があります。

注意:

Fusion Middleware Controlを使用して、LDAPサーバーへの再関連付けを行う場合、操作を開始する前に、「LDAP認可のテスト」ボタンを使用してください。通常は、このテストにより、間違って指定されたパラメータを見つけることができます。

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

この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。

現象

アプリケーションが、ドメイン資格証明ストアからの資格証明データの取得に失敗し、(次に示すような行を含む)エラー・メッセージがログに記録されます(角カッコ内のテキストには、特定の失敗に固有の情報が記述されます)。

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.2項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。

WLSTコマンドを使用してパーミッションを指定するには、第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」を参照してください。

ファイルjazn-data.xmlの次のフラグメントには、アプリケーションmyApp内のすべてのコードに、フォルダmyAlias内のすべての資格証明を読み取るパーミッションを付与する方法が示されています。

<jazn-data>
<!--  codebase 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.5.4 セキュリティ・アクセス制御の例外

この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。

現象

実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。

<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ファイルまたはWARファイル内のすべてのアプリケーション・コードにパーミッションを付与する方法です。この場合、保護された操作へのコールを、アプリケーション・コードの任意の場所に挿入できます。

2つ目は、JARファイルにのみ権限を付与する方法です。この場合、保護された操作へのコールが、権限が付与されたブロック内部にある必要があります。

これらの解決策をそれぞれ、資格証明ストアへのアクセスを試みるアプリケーションの例によって次に示します。

アプリケーションjazn-data.xmlの次のコードは、資格証明ストアにあるマップ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のコードを、次のコードSnippetに示すように、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.5.5 匿名SSL接続の確立の失敗

この項では、ポリシーと資格証明の再関連付けを行うときに匿名SSL接続を確立できない、よくある理由について説明します。

現象

Fusion Middleware Controlを使用してOracle Internet Directoryサーバーによるファイルベースのポリシーおよび資格証明とLDAPベースの記憶域の再関連付けを行う際の手順として、LDAPサーバーへの匿名SSL接続をテストします(具体的には、「LDAPのテスト」ボタンを使用します)。その結果、このテストに失敗します。

診断

ターゲットLDAPサーバーがOracle WebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。

解決策

LDAPサーバーへの接続を確立するには、LDAPサーバー上であらかじめ一部の構成を行っておく必要があります。詳細は、第9.2.1項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このポートを使用してLDAPサーバーを構成しなかった場合、接続は失敗します。

指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。通常、このポートの設定はLDAPサーバーの管理者が行います。

J.6 Oracle Business Intelligenceレポート作成のトラブルシューティング

この項では、Oracle Business IntelligenceをOracle Fusion Middlewareセキュリティのレポート作成ツールとして使用した場合に多く見られる問題とその解決策について説明します。次のトピックが含まれます:

- Oracle Business Intelligence Publisherの監査テンプレート

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

J.6.1 Oracle Business Intelligence Publisherの監査テンプレート

Oracle Business IntelligenceでOracle Fusion Middleware監査フレームワークのレポートを表示するには、適切な監査テンプレートを使用する必要があります。

詳細は、第C.2項を参照してください。

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

Oracle Business Intelligence Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、Oracle Fusion Middleware監査フレームワークのレポートに問題が発生することがあります。

この問題を防止するには、Oracle Business Intelligence Publisherとデータベースが、同じタイムゾーンにインストールされていることを確認します。

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

この項では、次の問題について説明します。

- ポリシー・ストアでの属性照合時の検索の失敗

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

J.7.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をポリシー・ストアの検索のフィルタとして使用するには事前にこの属性をカタログ化する必要があることを示しています。

解決策

検索フィルタで使用するOracle Internet Directoryの属性は、索引を作成したうえでカタログ化する必要があります。索引作成やカタログ化は通常は必須ではありませんが、OPSS関連の属性の場合は必須です。属性の索引作成およびカタログ化は、WLSTコマンドreassociateSecurityStoreによって自動的に実行されます。

属性のカタログの管理と属性の索引が作成済であることの確認の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項を参照してください。

属性を手動でカタログ化するには、次に示すように、ldapmodifyコマンドを使用します。

>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>

たとえば、属性createtimestampとmodifytimestampをカタログ化するには、次のようなLDIFファイルを使用します。

dn: cn=catalogs
changetype: modify
add: orclindexedattribute
orclindexedattribute: modifytimestamp
orclindexedattribute: createtimestamp

索引を作成する必要があるOracle Internet Directory属性のリストは次のとおりです。

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.7.2 不明なホスト例外による検索の失敗

LDAP参照用に構成されているActive Directory環境で情報を検索するときに、参照先のホストがActive Directoryサーバーと異なるドメインにある場合、参照は失敗します。

現象

ユーザーがリソースをリクエストしたときに、ディレクトリでのユーザーのアイデンティティの検証が不可能なためにユーザーのアイデンティティの検証に失敗することがあります。このエラーは、Active Directory環境でユーザーのブラウザがWindows以外のコンピュータで実行されている場合、またはユーザーのブラウザを実行するコンピュータが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ファイルに追加します。

IP_address_of_AD_host AD_host_name

このAD_host_nameは、参照で指定されるホスト名です。例:

123.123.123.123 my2003ad.com

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

この項では、次の問題について説明します。

- バイナリとポリシー・ストアのバージョンの非互換性

- ポリシー・ストアのバージョンの非互換性

J.8.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バイナリの11.1.1.4.0はそれよりも新しいバージョンのポリシー・ストアを使用できません。

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を使用して、11.1.1.4.0のポリシー・ストア(別のドメインにあるもの)を結合しようとします。

- この操作は失敗します。この共有によってバージョンの非互換性が発生するためです。
再関連付けは、OPSSバイナリとポリシー・ストアのバージョンが一致している場合にのみ可能です。

解決策

これらの3つのシナリオすべてに対処する解決策として、次のいずれかを使用できます。

- ドメインのOPSSバイナリを更新して、そのドメインが指しているポリシー・ストアのバージョンと一致させます。

- ドメインのポリシー・ストアの再関連付けを実行し、そのドメインのOPSSバイナリのバージョンと同じかそれより古いバージョンのポリシー・ストアに関連付けます。

J.8.2 ポリシー・ストアのバージョンの非互換性

この項では、OPSSセキュリティ・ストアの移行中にPolicyStoreIncompatibleVersionException例外が発生する理由について説明します。「バイナリとポリシー・ストアのバージョンの非互換性」も参照してください。

前述の例外は、移行元のストアのバージョンが移行先のストアのバージョンよりも高く、バージョンの組合せが無効であることを示しています。移行は、移行元のバージョンが移行先のバージョンよりも高くない場合にのみ実行されます。

回避策は、移行先のストアのバージョンを移行元のストアのバージョンと互換性のあるバージョンにアップグレードすることです。

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

この項では、次の問題について説明します。

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

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

- Oracle Internet Directoryの例外

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

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

- 無効な鍵サイズ

J.9.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.9.2 サイズ変更の必要な表領域

この項では、DBベースのOPSSセキュリティ・ストアで、ポリシーSQL操作が失敗する場合の理由について説明します。

現象

ポリシー操作の実行中に、Oracleデータベースは次のような警告を発行します。

"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.9.3 Oracle Internet Directoryの例外

Oracle Internet Directory 11.1.1.6.0を使用したセキュリティ・ストアを持つドメインでは、次のようなLDAP例外が発生します。

[LDAP: error code 53 - OID-5018: Cataloging for attr orcljpsextensiontype
is already in progress.]:cn=catalogs

レポートされた属性(前述のサンプルではorcljpsextensiontype)に相違がある可能性がありますが、解決策は同じで、つまり、Oracle Internet Directory 11.1.1.6.0のBug 13782459を修正するパッチを適用します。Oracle Internet Directoryのパッチの一覧は、第9.2項「LDAPベースのOPSSセキュリティ・ストアの使用」を参照してください。

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

この項では、ユーザーおよびロールAPIでドメイン認証プロバイダのデータへのアクセスに失敗する理由をいくつか説明します。

現象

ユーザーおよびロールAPIで、構成された認証プロバイダのデータへのアクセスに失敗します。

診断1

OPSSユーザーおよびロールAPIでは、ドメイン内で最初に構成されたLDAP認証プロバイダのデータにのみアクセスできます。このような認証プロバイダが少なくとも1つ、ドメイン内に存在する必要があります。その認証プロバイダにターゲット・ユーザーが存在しない場合、そのユーザーが他のドメイン認証プロバイダに存在しても、APIではその最初のLDAP認証プロバイダへのアクセスに失敗します。

解決策1

この存在していないユーザーを最初のLDAP認証プロバイダに入力するか、またはドメイン内のLDAP認証プロバイダのリストの順序を並べ替えます。

診断2

ドメイン内で最初に構成されたLDAP認証プロバイダに、APIが失敗した際のターゲット・ユーザーが存在すると仮定します。

デフォルトでは、ユーザーおよびロールAPIでは、属性uidを使用してLDAP認証プロバイダでユーザー検索を実行します。らかの理由で、LDAPで入力したユーザーにこの属性が欠落している場合、ユーザーおよびロールAPIは失敗します。

解決策2

最初のLDAP認証プロバイダのすべてのユーザーに、属性uidが設定されていることを確認します。

注意:

Java SEアプリケーションを開発する場合のみ、ユーザーおよびロールAPIでデフォルト(uid)以外の属性(mailなど)を使用してユーザーを検索するには、次のコードにあるように、username.attrプロパティおよびuser.login.attrプロパティを、(jps-config-jse.xmlファイルにある)アイデンティティ・ストアのLDAPプロバイダ・インスタンスで構成する必要があります。

<serviceInstance provider="idstore.ldap.provider" name="idstore.ldap">
...
<property name="username.attr" value="mail"/>
<property name="user.login.attr" value="mail"/>
...
</serviceInstance>

指定したスクリプトを使用してプロバイダ・インスタンスにプロパティを追加するには、第E.1項「スクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。

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

この項では、ポリシーに使用する文字に関する問題をいくつか説明します。この項の内容は次のとおりです。

- Oracle Internet Directory 10.1.4.3での特殊文字の使用

- 特定の文字が含まれるXMLポリシー・ストア

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

- XMLポリシー・ストアでの改行文字の欠落

J.9.5.1 Oracle Internet Directory 10.1.4.3での特殊文字の使用

ポリシー・ストアが、LDAPベースのOracle Internet Directory 10.1.4.3リポジトリの場合、RFC 2252/2253フィルタで*、(、)または\を使用すると、エラー53 (DSAによる操作拒否)が発生します。このエラーを解決するには、バグ番号7711351用のパッチをOracle Internet Directory 10.1.4.3に適用します。

J.9.5.2 特定の文字が含まれるXMLポリシー・ストア

この項で説明する問題は、XMLポリシー・ストアにのみ関連します。つまり、LDAPベースのポリシー・ストアには適用されません。

ここで問題となる文字は次のとおりです。

< "  &  $ ? * , / \ ` :    ( ) î ' % +  { }

これらの文字は、ファイルベースのポリシー・ストアを使用する場合には、アプリケーション・ロール名に使用しないことをお薦めします。

たとえばロールを作成するために、これらのいずれかの文字の使用が必要になった場合は、正常な結果が返されるように、ApplicationPolicy.searchAppRoles()などのAPIポリシー・ストア・メソッドへの入力でそれらの文字をエスケープ処理します。

たとえば、アプリケーション・ロールにappRoleî$という名前を付けた場合、ポリシー・ストアで一致を検索するにはApplicationPolicy.searchAppRoles("appRole\\î\\$")のように入力する必要があります。

または、このようにエスケープ処理した特殊文字を使用せずに、次のように検索式にワイルド・カードを使用して、アプリケーション・ロールとの一致が得られるようにすることもできます。

ApplicationPolicy.searchAppRoles("appRole*")

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

アプリケーション・ロール名は、空白以外の印刷可能な文字列です。つまり、アプリケーション・ロール名は、英数字(ASCIIまたはUnicode)と、空白以外のその他の印刷可能文字(アンダースコアや大カッコなど)で構成することができます。このルールはサポートされている3種類の記憶域XML、LDAPおよびDBのすべてに適用されます。

J.9.5.4 XMLポリシー・ストアでの改行文字の欠落

ファイルベースのポリシー・ストアでは、<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.9.6 無効な鍵サイズ

この項では、無効な鍵サイズの例外を取得する理由をいくつか説明します。

現象

「java.security.InvalidKeyException: Illegal key size」というメッセージの例外がログに記録されます。

java.security.InvalidKeyException: Illegal key size

診断1

ドメインの作成時に、OPSSはキーストア・サービスを使用して、セキュリティ・ストア・データの暗号化に使用されるAES対称鍵を作成します。OPSSは、最初に256ビットの鍵を生成しようとします。これがサポートされていない場合は、192ビットの鍵の生成を試行しますが、それもサポートされていない場合は、128ビットの鍵を作成します。128ビットの鍵がサポートされていない場合は、前述の例外がスローされます。

診断2

(Java EEアプリケーションとSEアプリケーションの両方で)OPSSの起動時に、実行時のJDKでAESアルゴリズムがサポートされていないためにOPSS暗号化鍵が読取り不可能な場合、またはドメインがプロビジョニングされた鍵サイズがJDKでサポートされているサイズと異なる場合、前述の例外がスローされます。

解決策

前述の問題の一般的な解決策として、JDKにJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Filesをインストールし、ドメインの作成またはOPSSの起動を再試行します。

J.10 追加のヘルプ

My Oracle Support(以前のMetaLink)(http://myoraclesupport.oracle.com)でより多くの解決策を参照できます。問題に対する解決策が見つからない場合は、サービス・リクエストを登録してください。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2014, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

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の登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

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

保証免責

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

制限付権利

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

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）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

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

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。