Fusion Middleware アプリケーション・セキュリティ・ガイド

11g リリース1 (11.1.1)

B56235-06(原本部品番号:E10043-12)

目次

例一覧

図一覧

表一覧

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

はじめに

- 対象読者

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

- 関連ドキュメント

- 表記規則

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

- リリース11gR1 PS5の新機能

- Oracle Identity Management 11gR1 PS1の新機能

- リリース11gR1 PS3の新機能

- Oracle Identity Management 11gR1の新機能

- リリース11gR1 PS2の新機能

- リリース11gR1 PS1の新機能

- リリース11gR1の新機能

- 10.1.3.xでサポートが終了した機能

- アップグレードに関するドキュメントへのリンク

第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 サポートされているLDAPアイデンティティ・ストアのタイプ

- 3.1.2 Oracle WebLogicの認証プロバイダ

- 3.1.2.1 LDAP認証プロバイダの使用

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

- 3.1.2.3 その他の認証方式

- 3.1.3 WebSphereのアイデンティティ・ストア

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

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

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

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

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

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 OPSSスクリプトを使用した一般的なセキュリティ操作

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.1.1 アイデンティティの手動による移行

- 6.5.2 デプロイ時のポリシーおよび資格証明の移行

- 6.5.2.1 ポリシーの手動による移行

- 6.5.2.2 資格証明の手動による移行

- 6.5.2.3 大量のポリシー・ストアおよび資格証明ストアの移行

- 6.5.3 監査ポリシーの移行

- 6.5.4 キーストア・サービスのキーおよび証明書の移行

第III部 OPSSの高度な管理

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

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

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

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

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

- 7.1.4 Java SEのサポート

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

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

- 7.3.1 構成内容

- 7.3.1.1 複数のLDAP検索の構成

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

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

- 7.3.2 WebLogic Serverにおける構成

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

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

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

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

- 7.3.2.5 サーバーの再起動

- 7.3.2.6 構成ファイルの例

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

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

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

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

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

- 7.3.6 Java SE環境

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

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

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

- 7.5.2 複数のLDAPシナリオでの一方向SSL

- 7.5.3 複数のLDAPシナリオでの双方向SSL

- 7.5.4 単一のLDAPシナリオの接続

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

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

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

- 8.2.1 複数ノード・サーバー環境

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

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

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

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

- 8.3.1.1 OracleデータベースでのOPSSスキーマの作成

- 8.3.1.2 OracleデータベースでのOPSSスキーマの削除

- 8.3.1.3 データソース・インスタンスの作成

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

- 8.3.3 DBへのSSL接続の設定

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

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

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

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

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

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

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

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

- 8.6.2.1 使用例

- 8.7 アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成

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

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

- 8.7.3 シングル・サインオン・ソリューションの指定

- 8.7.3.1 OPSS SSOフレームワーク

- 8.7.3.2 Fusion Middleware Controlを使用したSSOソリューションの構成

- 8.7.3.3 OAM構成の例

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

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

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

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

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

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

- 9.3 OPSSスクリプトによるアプリケーション・ポリシーの管理

- 9.3.1 listAppStripes

- 9.3.2 createAppRole

- 9.3.3 deleteAppRole

- 9.3.4 grantAppRole

- 9.3.5 revokeAppRole

- 9.3.6 listAppRoles

- 9.3.7 listAppRolesMembers

- 9.3.8 grantPermission

- 9.3.9 revokePermission

- 9.3.10 listPermissions

- 9.3.11 deleteAppPolicies

- 9.3.12 createResourceType

- 9.3.13 getResourceType

- 9.3.14 deleteResourceType

- 9.3.15 createResource

- 9.3.16 deleteResource

- 9.3.17 listResources

- 9.3.18 listResourceActions

- 9.3.19 createEntitlement

- 9.3.20 getEntitlement

- 9.3.21 deleteEntitlement

- 9.3.22 addResourceToEntitlement

- 9.3.23 revokeResourceFromEntitlement

- 9.3.24 listEntitlements

- 9.3.25 grantEntitlement

- 9.3.26 revokeEntitlement

- 9.3.27 listEntitlement

- 9.3.28 listResourceTypes

- 9.3.29 reassociateSecurityStore

- 9.3.30 DBベース・ストアへの再関連付け後のオフライン・スクリプトの実行

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

- 9.4.1 例

- 9.5 WLSTスクリプトを使用した匿名ロールおよび認証ロールへのポリシーの付与

- 9.6 WLSTスクリプトのバージョン付きアプリケーションのアプリケーション・ストライプ

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

- 9.8 ポリシー・ストア構成のガイドライン

10 資格証明ストアの管理

- 10.1 資格証明のタイプ

- 10.2 資格証明の暗号化

- 10.3 資格証明ストアの管理

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

- 10.5 OPSSスクリプトによる資格証明の管理

- 10.5.1 listCred

- 10.5.2 updateCred

- 10.5.3 createCred

- 10.5.4 deleteCred

- 10.5.5 modifyBootStrapCredential

- 10.5.6 addBootStrapCredential

- 10.5.7 exportEncryptionKey

- 10.5.8 importEncryptionKey

- 10.5.9 restoreEncryptionKey

11 キーストア・サービスでのキーと証明書の管理

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

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

- 11.1.2 キーストアのタイプ

- 11.1.3 ドメイン・トラスト・ストア

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

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

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

- 11.4.1 changeKeyPassword

- 11.4.2 changeKeyStorePassword

- 11.4.3 createKeyStore

- 11.4.4 deleteKeyStore

- 11.4.5 deleteKeyStoreEntry

- 11.4.6 exportKeyStore

- 11.4.7 exportKeyStoreCertificate

- 11.4.8 exportKeyStoreCertificateRequest

- 11.4.9 generateKeyPair

- 11.4.10 generateSecretKey

- 11.4.11 getKeyStoreCertificates

- 11.4.12 getKeyStoreSecretKeyProperties

- 11.4.13 importKeyStore

- 11.4.14 importKeyStoreCertificate

- 11.4.15 listExpiringCertificates

- 11.4.16 listKeyStoreAliases

- 11.4.17 listKeyStores

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

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

- 12.1.1 監査の目的

- 12.1.2 現在の監査の課題

- 12.1.3 Oracle Fusion Middleware 11gの監査フレームワーク

- 12.2 監査機能の概要

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

- 12.3.1 監査アーキテクチャ

- 12.3.2 重要な技術的概念

- 12.3.3 監査メタデータ記憶域

- 12.3.4 監査データ記憶域

- 12.3.5 分析

13 監査の構成と管理

- 13.1 監査管理タスク

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

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

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

- 13.2.2.1 複数のデータソース

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

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

- 13.2.3.2 監査データ・ストアの構成

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

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

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

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

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

- 13.2.6.1 環境の構成

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

- 13.3 監査ポリシーの管理

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

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

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

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

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

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

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

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

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

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

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

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

- 13.3.4.4 システム・コンポーネント用の監査の手動構成

- 13.4 監査ログ

- 13.4.1 監査ログの場所

- 13.4.2 監査ログのタイムスタンプ

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

- 13.5.1 スキーマの概要

- 13.5.2 表の属性

- 13.5.3 索引スキーム

- 13.5.4 バックアップとリカバリ

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

- 13.5.6 パーティション化

- 13.5.6.1 パーティション表

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

- 13.5.6.3 データのインポート、エクスポート、消去

- 13.5.6.4 階層アーカイブ

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

- 14.1 監査レポート用のOracle Business Intelligence Publisherの設定

- 14.1.1 Oracle Business Intelligence Publisherについて

- 14.1.2 Oracle Business Intelligence Publisherのインストール

- 14.1.3 Oracle Business Intelligence PublisherでのOracle Reportsの設定

- 14.1.4 監査レポート・テンプレートの設定

- 14.1.5 監査レポート・フィルタの設定

- 14.1.6 Oracle Business Intelligence Publisherのスケジューラの構成

- 14.2 監査レポートの編成

- 14.3 監査レポートの表示

- 14.4 Oracle Business Intelligence Publisherレポートの例

- 14.5 監査レポートの詳細

- 14.5.1 Oracle Business Intelligence Publisherの監査レポートのリスト

- 14.5.2 Oracle Business Intelligence Publisherの監査レポートの属性

- 14.6 監査レポートのカスタマイズ

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

- 14.6.2 カスタム・レポートの作成

第IV部 シングル・サインオンの構成

15 Oracle Fusion Middlewareにおけるシングル・サインオンの概要

- 15.1 デプロイメントに適したSSOソリューションの選択

- 15.2 概要: WebLogic ServerのOAM認証プロバイダ

- 15.2.1 Oracle Access ManagerでのIDアサーション・プロバイダ機能の使用について

- 15.2.2 Oracle Access Managerでの認証プロバイダ機能の使用について

- 15.2.3 Oracle Access Manager SSOのシナリオとソリューションに対応するアプリケーションの選択

- 15.2.3.1 アプリケーションでのOracle Access Managerの初めての使用

- 15.2.3.2 アプリケーションでのOracle Application ServerからOracle WebLogic Serverへの移行

- 15.2.3.3 アプリケーションでのWebLogic SSPI用のOAMセキュリティ・プロバイダの使用

- 15.2.4 実装: プロバイダの使用におけるOAM 11gとOAM 10gの相違点

- 15.2.5 Oracle Access Managerで使用されるプロバイダの要件

- 15.3 WebLogic管理コンソールでのデバッグの設定

16 Oracle Access Manager 11gを使用したシングル・サインオンの構成

- 16.1 Oracle Access Manager 11g SSOの概要

- 16.1.1 10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー

- 16.2 Oracle Access Manager 11g SSOソリューションのデプロイ

- 16.2.1 Oracle Access Manager 11gでの認証プロバイダのインストール

- 16.2.2 Oracle Access Manager証明書のJavaキーストア形式への変換

- 16.2.3 セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング

- 16.2.3.1 Oracle Access Manager 11gでのWebゲートのプロビジョニング・メソッドについて

- 16.2.3.2 Oracle Access Manager 11gでのWebゲートのプロビジョニング

- 16.2.4 Oracle Access Manager 11gでのSSO用のIDアサーションの構成

- 16.2.4.1 Oracle WebLogic Serverとの間の信頼の確立

- 16.2.4.2 WebLogicドメインでのプロバイダの構成

- 16.2.4.3 トラステッド・ヘッダー・アサーション: デジタル署名検証の構成

- 16.2.4.4 トラステッド・ヘッダー・アサーション: ポリシーの構成

- 16.2.4.5 シングル・サインオン用のOracle Access Manager IDアサーションのテスト

- 16.2.5 Oracle Access Manager 11g用の認証プロバイダ機能の構成

- 16.2.5.1 WebLogicドメインでの認証プロバイダの構成

- 16.2.5.2 認証プロバイダのアプリケーション認証方式の構成

- 16.2.5.3 LDAP内のグループへの認証ユーザーのマッピング

- 16.2.5.4 Oracle Access Manager認証プロバイダの実装のテスト

- 16.2.6 Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成

- 16.2.6.1 Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成

- 16.2.6.2 Oracle Web Services Manager用のIDアサーション・プロバイダのテスト

- 16.3 Oracle Access Manager 11g用の集中管理ログアウトの構成

- 16.3.1 11g WebゲートおよびOAM 11gのログアウト

- 16.3.2 Oracle Access Manager 11gでの10g Webゲートのログアウト

- 16.4 ユーザーとSSOセッションの同期: SSO同期フィルタ

- 16.5 トラブルシューティングのヒント

17 Oracle Access Manager 10gを使用したシングル・サインオンの構成

- 17.1 Oracle Access Manager 10gを使用したSSOソリューションのデプロイ

- 17.1.1 OAM 10g用の認証プロバイダのインストールおよび設定

- 17.1.1.1 Oracle Access Manager 10gのインストールと設定について

- 17.1.1.2 認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール

- 17.1.1.3 Oracle Access Manager証明書のJavaキーストア形式への変換

- 17.1.1.4 Oracle Access Manager 10gでのリソース・タイプの作成

- 17.1.2 Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

- 17.1.2.1 ログアウトを構成するための推奨プロセス

- 17.1.2.2 ログアウトを構成するための代替プロセス

- 17.2 Oracle Access Manager認証プロバイダのパラメータ・リスト

- 17.3 OAMCfgToolの概要

- 17.3.1 OAMCfgToolのプロセス概要

- 17.3.2 OAMCfgToolのパラメータと値

- 17.3.2.1 CREATEモードのパラメータと値

- 17.3.2.2 VALIDATEモードのパラメータと値

- 17.3.2.3 DELETEモードのパラメータと値

- 17.3.3 OAMCfgToolで作成したポリシー・ドメインとアクセス・ゲート・プロファイルのサンプル

- 17.3.4 既知の問題: JARファイルとOAMCfgTool

- 17.4 Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成

- 17.4.1 Oracle WebLogic Serverとの間の信頼の確立

- 17.4.1.1 シングル・サインオン用アプリケーション認証方式の設定

- 17.4.1.2 Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認

- 17.4.1.3 Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

- 17.4.2 IDアサーション・プロバイダの認証スキームの構成

- 17.4.2.1 認証スキーム、ポリシー・ドメイン、およびWebゲート・プロファイルの作成

- 17.4.3 WebLogicドメインでのプロバイダの構成

- 17.4.3.1 Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて

- 17.4.3.2 Oracle WebLogic Scripting Tool (WLST)について

- 17.4.3.3 Oracle Access Manager IDアサーションのプロバイダの設定

- 17.4.4 IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定

- 17.4.5 OAM 10gでのSSO用のIDアサーションのテスト

- 17.5 Oracle Access Manager 10g用の認証プロバイダの構成

- 17.5.1 認証プロバイダの認証スキームの作成

- 17.5.2 Oracle Access Manager認証プロバイダのポリシー・ドメインの構成

- 17.5.2.1 ポリシー・ドメインの作成について

- 17.5.2.2 認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成

- 17.5.3 WebLogicドメインでの認証プロバイダの構成

- 17.5.4 認証プロバイダのアプリケーション認証方式の構成

- 17.5.5 LDAP内のグループへの認証ユーザーのマッピング

- 17.5.6 Oracle Access Manager認証プロバイダの実装のテスト

- 17.6 Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成

- 17.6.1 Oracle Web Services Managerで使用されるポリシー・ドメインの作成

- 17.6.2 Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成

- 17.6.3 Oracle Web Services Manager用のIDアサーション・プロバイダのテスト

- 17.7 ユーザーとSSOセッションの同期: SSO同期フィルタ

- 17.8 OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント

- 17.8.1 IPv6の使用について

- 17.8.2 Apacheブリッジの失敗: タイムアウト

- 17.8.3 認証済ユーザーがアクセスを拒否される

- 17.8.4 ブラウザの「戻る」ボタンを押すとエラーが発生する

- 17.8.5 OAMおよびOID認証プロバイダを追加した後に再起動できない

- 17.8.6 ロード・バランシングされるWebゲートを持つクラスタのクライアント

- 17.8.7 エラー401: アプリケーションにアクセスできません

- 17.8.8 エラー403: アプリケーションにアクセスできません

- 17.8.9 エラー404: リクエストURIに合致するものを見つけられませんでした

- 17.8.10 フォーム・ログイン・ページのアクションURLでエラーが発生する

- 17.8.11 Oracle WebLogic Serverの起動中にエラーが発生するか、失敗する

- 17.8.12 JAAS制御フラグ

- 17.8.13 資格証明の送信時にログイン・フォームが繰り返し表示される: エラーなし

- 17.8.14 ログアウトとセッション・タイムアウトの問題

- 17.8.15 見つかりません: リクエストされたURLまたはリソースが見つかりません

- 17.8.16 Oracle WebLogic Serverの起動に失敗する

- 17.8.17 Oracle ADF統合と証明書モード

- 17.8.18 Protected_JSessionId_Policyについて

18 OracleAS SSO 10gを使用したシングル・サインオンの構成

- 18.1 OracleAS 10g Single Sign-On (OSSO)ソリューションのデプロイ

- 18.1.1 OSSO IDアサーション・プロバイダの使用

- 18.1.1.1 Oracle WebLogicセキュリティ・フレームワーク

- 18.1.1.2 OSSO IDアサーション・プロバイダの処理

- 18.1.1.3 OSSO IDアサーション・プロバイダによるヘッダーの使用

- 18.1.2 OSSO IDアサーション・プロバイダの新規ユーザー

- 18.1.2.1 mod_weblogicの構成

- 18.1.2.2 OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録

- 18.1.2.3 Webリソースを保護するためのmod_ossoの構成

- 18.1.2.4 OSSO用WebLogicドメインへのプロバイダの追加

- 18.1.2.5 Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

- 18.1.2.6 OSSO IDアサーション・プロバイダ用のアプリケーションの構成

- 18.2 ユーザーとSSOセッションの同期: SSO同期フィルタ

- 18.3 OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング

- 18.3.1 SSO関連の問題

- 18.3.2 OSSO IDアサーション・プロバイダ関連の問題

- 18.3.3 URL再書込みとJSESSIONID

- 18.3.4 mod_osso、OSSO Cookieおよびディレクティブについて

- 18.3.4.1 mod_ossoの新しいOssoHTTPOnlyディレクティブ

- 18.3.4.2 mod_ossoのOssoSecureCookiesディレクティブ

- 18.3.4.3 mod_ossoが戻りURLをエンコードしない

- 18.3.4.4 mod_osso: デフォルトのインストール後に「ページが見つかりません」と表示される

- 18.3.5 IPv6の使用について

第V部 Oracle Platform Security ServicesのAPIを使用した開発

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

- 19.1 概要

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

- 19.2.1 認証

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

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

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

- 19.2.2 アイデンティティ

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

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

- 19.2.3 認可

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

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

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

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

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

- 19.2.4 資格証明

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

- 19.2.5 監査

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

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

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

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

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

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

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

- 19.2.7 管理

- 19.2.7.1 中央ストアが必要なアプリケーション

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

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

- 19.2.8 統合

- 19.2.8.1 複数のドメインで実行されるアプリケーション

- 19.3 ユースケースの詳細

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

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

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

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

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

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

- 19.3.2.2 コード・サンプル1

- 19.3.2.3 コード・サンプル2

- 19.3.2.4 コード・サンプル3

- 19.3.2.5 コード・サンプル4

- 19.3.2.6 コード・サンプル5

- 19.3.2.7 コード・サンプル6

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

- 19.4.1 開発フェーズ

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

- 19.4.3 管理フェーズ

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

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

- 19.5.1 コード例

- 19.5.2 構成例

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

20 OPSSポリシー・モデル

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

- 20.2 認可の概要

- 20.2.1 認可の概要

- 20.2.2 Java EE認可モデル

- 20.2.2.1 宣言的な認可

- 20.2.2.2 プログラム的な認可

- 20.2.2.3 Java EEコードの例

- 20.2.3 JAAS認可モデル

- 20.3 JAAS/OPSS認可モデル

- 20.3.1 リソース・カタログ

- 20.3.2 ポリシーの管理

- 20.3.3 ポリシーの確認

- 20.3.3.1 メソッドcheckPermissionの使用方法

- 20.3.3.2 メソッドdoAsおよびdoAsPrivilegedの使用方法

- 20.3.3.3 メソッドcheckBulkAuthorizationの使用方法

- 20.3.3.4 メソッドgetGrantedResourcesの使用方法

- 20.3.4 クラスResourcePermission

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 21.4.2.4 アプリケーション・ポリシーを削除する(またはアプリケーション・ポリシーを削除しない)には

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

- 21.4.2.6 推奨事項

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

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

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

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

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

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

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

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

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

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

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

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

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

22 Java SEアプリケーションの認証

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

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

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

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

- 22.2.3 Java SEアプリケーション向けにサポートされるログイン・モジュール

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

- 22.2.3.2 認証のためのアイデンティティ・ストア・ログイン・モジュールの使用

- 22.2.3.3 アサーションのためのアイデンティティ・ログイン・モジュールの使用

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

- 22.3 構成例

23 Java SEアプリケーションの認可

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 24.6 APIの使用手順

- 24.6.1 スタンドアロン環境でのCSF APIの使用方法

- 24.6.2 Oracle WebLogic ServerでのCSF APIの使用方法

- 24.7 例

- 24.7.1 CSF操作のコード

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

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

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

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

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

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

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

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

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

- 25.3.1 サービス・プロバイダについて

- 25.3.2 環境の設定

- 25.3.3 プロバイダの選択

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

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

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

- 25.3.5.2 ECID伝播

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

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

- 25.3.6.1 Oracle Internet Directoryプロバイダ

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

- 25.3.6.3 定数値の指定

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

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

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

- 25.3.8 実行時の構成

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

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

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

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

- 25.4 リポジトリの検索

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

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

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

- 25.4.4 検索フィルタの使用

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

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

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

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

- 25.4.5 GUIDによる検索

- 25.5 ユーザー認証

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

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

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

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

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

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

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

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

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

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

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

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

- 25.8.1.2 SSLの構成

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

- 25.8.2.1 SSLの構成

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

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

- 25.10.1 SPIの概要

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

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

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

- 25.10.3.2 oracle.security.idm.spi.AbstractIdentityStoreFactory

- 25.10.3.3 oracle.security.idm.spi.AbstractIdentityStore

- 25.10.3.4 oracle.security.idm.spi.AbstractRoleManager

- 25.10.3.5 oracle.security.idm.spi.AbstractUserManager

- 25.10.3.6 oracle.security.idm.spi.AbstractRoleProfile

- 25.10.3.7 oracle.security.idm.spi.AbstractUserProfile

- 25.10.3.8 oracle.security.idm.spi.AbstractSimpleSearchFilter

- 25.10.3.9 oracle.security.idm.spi.AbstractComplexSearchFilter

- 25.10.3.10 oracle.security.idm.spi.AbstractSearchResponse

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

- 25.10.5 開発のガイドライン

- 25.10.6 テストと検証

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

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

- 25.10.7.2 実装の概要

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

- 25.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

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

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

- 26.1.1 機能の概要

- 26.2 クラスの概要

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

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

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

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

- 26.4.2.1 ユーザー操作

- 26.4.2.2 グループ操作

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

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

- 26.5.2 ユーザーの作成

- 26.5.3 ユーザーの取得

- 26.5.4 ユーザーの変更

- 26.5.5 ユーザーの簡易検索

- 26.5.6 ユーザーの複合検索

- 26.5.7 グループの作成

- 26.5.8 グループの取得

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

- 26.5.10 グループの削除

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

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

- 26.6 SSL構成

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

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

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

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

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

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

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

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

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

- 27.5 キーストア・サービスAPIの使用方法

- 27.5.1 スタンドアロン環境でのキーストア・サービスAPIの使用方法

- 27.5.2 Oracle WebLogic Serverでのキーストア・サービスAPIの使用方法

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

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

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

- 27.6.3 構成ファイル

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

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

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

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

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

- 28.2.1 属性グループ

- 28.2.1.1 監査属性のデータ型

- 28.2.1.2 共通属性グループ

- 28.2.1.3 汎用属性グループ

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

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

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

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

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

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

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

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

- 28.5.1.1 バージョン番号

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

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

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

- 28.7.1 監査クライアントAPI

- 28.7.2 システム権限の設定

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

- 28.8 Oracle Business Intelligence Publisherとの統合

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

第VI部 付録

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 Directory Integration Platformのイベントとその属性

- C.1.2.2 Oracle Platform Security Servicesのイベントとその属性

- C.1.2.3 Oracle HTTP Serverのイベントとその属性

- C.1.2.4 Oracle Internet Directoryのイベントとその属性

- C.1.2.5 Oracle Identity Federationのイベントとその属性

- C.1.2.6 Oracle Virtual Directoryのイベントとその属性

- C.1.2.7 OWSM-Agentのイベントとその属性

- C.1.2.8 OWSM-PM-EJBのイベントとその属性

- C.1.2.9 Reportsサーバーのイベントとその属性

- C.1.2.10 WSポリシー・アタッチメントのイベントとその属性

- C.1.2.11 Oracle Web Cacheのイベントとその属性

- C.1.2.12 Oracle Web Services Managerのイベントとその属性

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

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

- C.2.1 共通監査レポート

- C.2.2 コンポーネント固有の監査レポート

- C.3 監査スキーマ

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

- C.4.1 getNonJava EEAuditMBeanName

- C.4.1.1 説明

- C.4.1.2 構文

- C.4.1.3 例

- C.4.2 getAuditPolicy

- C.4.2.1 説明

- C.4.2.2 構文

- C.4.2.3 例

- C.4.3 setAuditPolicy

- C.4.3.1 説明

- C.4.3.2 構文

- C.4.3.3 例

- C.4.4 getAuditRepository

- C.4.4.1 説明

- C.4.4.2 構文

- C.4.4.3 例

- C.4.5 setAuditRepository

- C.4.5.1 説明

- C.4.5.2 構文

- C.4.5.3 例

- C.4.6 listAuditEvents

- C.4.6.1 説明

- C.4.6.2 構文

- C.4.6.3 例

- C.4.7 exportAuditConfig

- C.4.7.1 説明

- C.4.7.2 構文

- C.4.7.3 例

- C.4.8 importAuditConfig

- C.4.8.1 説明

- C.4.8.2 構文

- C.4.8.3 例

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

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

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

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

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

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

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

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

- E.1 WLSTスクリプトを使用した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 セキュリティ・データのアップグレード

- G.1 upgradeSecurityStoreを使用したアップグレード

- G.1.1 使用例

- G.1.1.1 例1 - アイデンティティのアップグレード

- G.1.1.2 例2 - ファイルベース・ポリシーへのアップグレード

- G.1.1.3 例3 - Oracle Internet Directory LDAPベースのポリシーへのアップグレード

- G.1.1.4 例4 -リソース・カタログを使用するようファイルベースのポリシーをアップグレード

- G.2 upgradeOpssを使用したポリシーのアップグレード

- G.2.1 コマンド構文

H リファレンス

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

I OPSSスクリプト

- I.1 ポリシー関連のスクリプト

- I.2 資格証明関連のスクリプト

- I.3 その他のセキュリティ・スクリプト

- I.4 監査スクリプト

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

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

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

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

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

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

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

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

L Oracle Fusion Middlewareのセキュリティのトラブルシューティング

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

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

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

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

- L.1.1.3 認可ロガー

- L.1.1.4 オフラインOPSSスクリプト・ロガー

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

- L.1.1.6 監査ロガー

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

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

- L.1.2.1 jps.auth.debug

- L.1.2.2 jps.auth.debug.verbose

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

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

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

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

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

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

- L.2 再関連付けの失敗

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

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

- L.3 サーバーの起動の失敗

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

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

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

- L.3.4 NFSマウントされたドメイン・ディレクトリを持つサーバーの起動失敗

- L.3.5 その他の原因

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

- L.5 LDAPサーバーへの接続の失敗

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

- L.7 ユーザーおよびロールAPIの失敗

- L.8 ドメイン資格証明ストアのデータへのアクセスの失敗

- L.9 匿名SSL接続の確立の失敗

- L.10 認可チェックの失敗

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

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

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

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

- L.15 ポリシーの移行の失敗

- L.16 ポリシーに使用する文字

- L.16.1 Oracle Internet Directory 10.1.4.3での特殊文字の使用

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

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

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

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

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

- L.18.1 Oracle Business Intelligence Publisherの監査テンプレート

- L.18.2 Oracle Business Intelligence Publisherのタイムゾーン

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

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

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

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

- L.23 追加のヘルプ

索引

例一覧

- 7-1 Oracle WebLogic Serverにおける単一のLDAP構成

- 7-2 Oracle WebLogic Serverにおける複数のLDAP構成

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

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

- 17-1 logout.htmlのスクリプト

- 17-2 例16-2 OIM統合関連パラメータの使用方法

- 18-1 動的ディレクティブによるSSO認証

- 18-2 動的ディレクティブによるSSOログアウト

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

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

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

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

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

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

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

- B-1 <jazn-policy>

- B-2 <jazn-policy>

図一覧

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

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

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

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

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

- 12-1 監査イベント・フロー

- 13-1 監査スキーマ

- 15-1 Oracle Access ManagerおよびWebゲートを使用したIDアサーション・プロバイダの構成

- 15-2 Webおよび非Webリソース用の認証プロバイダ

- 16-1 User ID Assertion認証ポリシーで事前シードされたリソース

- 16-2 User ID Assertionポリシーで事前シードされたレスポンス

- 16-3 事前シード済の認証ポリシーApplication SSOとリソース

- 16-4 認証ポリシーApplication SSOに対して事前シードされたレスポンス

- 16-5 事前シード済の認可ポリシーApplication SSOとリソース

- 16-6 トラステッド・ヘッダー・アサーションに対する認可ポリシーの例

- 17-1 OAMCfgToolのサンプル・ポリシー・ドメインの「一般」タブ

- 17-2 OAMCfgToolのサンプル・ポリシー・ドメインの「リソース」タブ

- 17-3 OAMCfgToolのサンプル・ポリシー・ドメインの「認可ルール」タブ

- 17-4 OAMCfgToolのサンプル・ポリシー・ドメインの「デフォルト・ルール」タブ

- 17-5 OAMCfgToolのサンプル・ポリシー・ドメインの「ポリシー」タブ

- 17-6 OAMCfgToolのポリシー・ドメインの「委任アクセス管理」タブ

- 17-7 OAMCfgToolのサンプル・ホスト識別子

- 17-8 OAMCfgToolのサンプル・アクセス・ゲート・プロファイル

- 17-9 10g Webゲートでのシングル・サインオン用のデフォルト・ログイン・フォーム

- 17-10 Oracle Access Managerポリシー・マネージャの「ポリシー・ドメインの作成」ページ

- 18-1 Oracle WebLogicセキュリティ・フレームワーク内のOSSOコンポーネントの配置

- 18-2 OSSO IDアサーション・プロバイダの処理

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

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

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

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

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

表一覧

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

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

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

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

- 8-1 SSOプロバイダのプロパティ

- 11-1 キーストア・サービス・コマンド

- 13-1 実表IAU_BASEの属性

- 14-1 監査レポートのリスト

- 14-2 監査レポートの属性

- 15-1 概要: Oracle Access ManagerのIDアサーション・メカニズム

- 15-2 OAM 11gとOAM 10gでの認証プロバイダ実装タスクの違い

- 16-1 PEMからDER形式ファイルを作成するためのオプション

- 16-2 OAM 11g用のメソッドのプロビジョニング

- 16-3 OAMエージェントに必須の登録の詳細

- 16-4 接続フィルタ・ルール

- 16-5 addOAMSSOProviderコマンドライン引数

- 16-6 SSO同期フィルタの各プロパティと同期動作

- 17-1 PEMからDER形式ファイルを作成するためのオプション

- 17-2 Oracle Access Manager認証プロバイダの共通パラメータ

- 17-3 プロバイダ固有のパラメータ

- 17-4 Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータ

- 17-5 OAMCfgToolのCREATEモードでのパラメータと値

- 17-6 OIM統合関連の追加パラメータと値

- 17-7 OAMCfgToolのVALIDATEモードでのパラメータと値

- 17-8 OAMCfgToolのDELETEモードのパラメータ

- 17-9 OAMCfgToolの既知の問題

- 17-10 接続フィルタ・ルール

- 17-11 addOAMSSOProviderコマンドライン引数

- 17-12 SSO同期フィルタの各プロパティと同期動作

- 18-1 Oracle HTTP Serverによって送信されるヘッダー

- 18-2 Oracle HTTP Serverのmod_ossoを登録するためのssoregパラメータ

- 18-3 接続フィルタ・ルール

- 18-4 SSO同期フィルタの各プロパティと同期動作

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 22-1 Idstoreのタイプ

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

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

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

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

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

- 25-6 AbstractSimpleSearchFilterのメソッド

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

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

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

- 28-2 監査登録サービスのパラメータ

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

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

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

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

- C-1 Oracle Directory Integration Platformのイベント

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

- C-3 Oracle HTTP Serverのイベント

- C-4 Oracle Directory Integration Platformのイベント

- C-5 Oracle Identity Federationのイベント

- C-6 Oracle Virtual Directoryのイベント

- C-7 OWSM-Agentのイベント

- C-8 OWSM-PM-EJBのイベント

- C-9 Reportsサーバーのイベント

- C-10 WSポリシー・アタッチメントのイベント

- C-11 Oracle Web Cacheのイベント

- C-12 Oracle Web Services Managerのイベント

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

- C-14 監査スキーマ

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

- C-16 WLST監査コマンド

- 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で使用されるJavaシステム・プロパティ

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

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

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

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

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

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

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

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

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

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

Oracle® Fusion Middleware

アプリケーション・セキュリティ・ガイド

11g リリース1 (11.1.1)

B56235-06(原本部品番号:E10043-12)

2012年4月

Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド, 11g リリース1 (11.1.1)

B56235-06

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

原本著者: Carlos Subi

原本協力著者:  Vinaye Misra、Gail Flanegin

原本協力者:  Amit Agarwal、Soumya Aithal、Moushmi Banerjee、Andre Correa、Marc Chanliau、Pratik Datta、Jordan Douglas、Guru Dutt、Todd Elwood、Vineet Garg、Vikas Ghorpade、Sandeep Guggilam、Shiang-Jia Huang、Dan Hynes、Michael Khalandovsky、Supriya Kalyanasundaram、Lakshmi Kethana、Ganesh Kirti、Ashish Kolli、Rohit Koul、Nithya Muralidharan、Frank Nimphius、Craig Perez、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およびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

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

はじめに

このマニュアルでは、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 Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』

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

- 『Oracle Fusion Middleware Oracle Identity Management統合ガイド』

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

- 『Oracle Fusion Middleware Oracle Application Development FrameworkのためのFusion開発者ガイド』

- 『Oracle Fusion Middlewareセキュリティ概要』

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

- Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイド

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

Oracleドキュメントの総合的なリストが必要な場合、またはOracleドキュメント・ライブラリの特定のトピックを検索する場合は、http://www.oracle.com/technology/documentation/index.htmlを参照してください。

表記規則

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

規則

意味

太字

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

イタリック

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

固定幅

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

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

この章では、リリース11gR1、11gR1 PS1、11gR1 PS2、Oracle Identity Management 11gR1、11gR1 PS3、Oracle Identity Management 11gR1 PS1および11gR1 PS5で導入された最も重要な変更内容について説明します。

リリース11gR1 PS5の新機能

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

- 資格証明の暗号化。詳細は、第10.2項「資格証明の暗号化」を参照してください。

- Oracle Access Manager IDアサーション・プロバイダを使用したトラステッド・ヘッダー・アサーション。詳細は、第15章「Oracle Fusion Middlewareにおけるシングル・サインオンの概要」および第16章「Oracle Access Manager 11gを使用したシングル・サインオンの構成」を参照してください。

- アプリケーション・セキュリティのOPSSとの統合。詳細は、第19章「アプリケーション・セキュリティのOPSSとの統合」を参照してください。

- 監査サービスを使用したアプリケーションの開発。詳細は、第28章「監査サービスを使用した開発」を参照してください。

- アプリケーションでのアイデンティティ・ディレクトリAPIの使用。詳細は、第26章「アイデンティティ・ディレクトリAPIを使用した開発」を参照してください。

- キーストア・サービスの管理。詳細は、第11章「キーストア・サービスでのキーと証明書の管理」を参照してください。

- キーストア・サービスを使用したアプリケーションの開発。詳細は、第27章「キーストア・サービスを使用した開発」を参照してください。

- upgradeOpssを使用したPS5へのアップグレード。詳細は、付録G「セキュリティ・データのアップグレード」を参照してください。

次のドキュメントが更新されています。

- 共通監査フレームワークの説明の更新。詳細は、第12章「Oracle Fusion Middleware監査フレームワークの概要」および第13章「監査の構成と管理」を参照してください。

- アイデンティティ・ストア・サービスに対してSSLを有効にする手順。第7.5項を参照してください。

Oracle Identity Management 11gR1 PS1の新機能

Oracle Indentity Management 11gR1 PS1で導入された機能は次のとおりです。

- Oracle Entitlements Server。Oracle Authorization Policy Managerを破棄するツールです。詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

- スタンドアロン監査ローダー。

リリース11gR1 PS3の新機能

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

- DBベースのストアのサポート。

- IBM WebSphere Application Serverのサポート。

- 複数のアイデンティティ・ストアの問合せを可能にするID仮想化のサポート。

- IBM WebSphere Application Serverのセキュリティ管理スクリプトのサポート。

- セキュリティ・データを11gR1 PS1または11gR1 PS2から11gR1 PS3にアップグレードするためのOPSSスクリプトupgradeOpss。

- その他のOPSSスクリプト。

- Fusion Middleware Controlのセキュリティ・ページにおける機能向上。

- 追加パラメータによるOAM 10g SSO用OAMCfgToolの拡張。

- IBM TivoliおよびMicrosoft ADAMディレクトリに対するユーザーおよびロールAPIのサポート。

Oracle Identity Management 11gR1の新機能

Oracle Identity Management 11gR1で導入された機能は次のとおりです。

- Oracle Authorization Policy Manager。アプリケーション・セキュリティ・アーティファクトを管理するツールです。アプリケーションのセキュリティを管理するために使用できる一連のツールは、Oracle WebLogic管理コンソール、Oracle Enterprise Manager Fusion Middleware Control、WLSTコマンドおよびOracle Authorization Policy Managerです。

このガイドで追加された事項

このガイドで新たに追加された事項には次のものがあります。

- セキュリティ関連のWLSTコマンドがすべて記載された付録。

リリース11gR1 PS2の新機能

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

- リソース・カタログ。リソース・タイプ、リソース、アクションおよびアプリケーション・ポリシーの付与における権限を指定する方法。このリリースから、リソース・カタログの導入によってリソースベースのポリシーのサポートが開始されました。

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

- パーミッションでのResourcePermissionクラスの使用。

- リソース・タイプを管理する新しいWLSTコマンド。

- Oracle WebLogic Serverのシステム・プロパティjps.deployment.handler.disabledが導入されました。

- upgradeSecurityStoreコマンドの新規使用。

- 重複項目の発生時の移行動作を制御する、migrateSecurityStoreコマンドに対する新規引数。これは、アプリケーション・ポリシーの移行の際にのみ適用されます。

リリース11gR1 PS1の新機能

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

- リソース・パーミッション・クラス

- プリンシパル名の比較機能が拡張されました。

- ポリシーの移行の手動設定が容易になりました。特に、アプリケーションのバージョン管理が不要になっています。

- WLSTコマンドmigrateSecurityStoreは、組込みLDAPストアをターゲットとしてサポートします。

- アイデンティティ・ストアの構成が容易になりました。たとえば、以前必要だったusername.attrやlogin.name.attrなどのプロパティは、LDAPアイデンティティ・ストアの構成時に不要になりました。

- WLSTコマンドreassociateSecurityStoreは、既存のLDAPノードをターゲットとしてサポートします。

- Oracle Fusion Middleware Controlのページが新しくなり、その機能が向上しました。特に、これらのページを使用すると、ドメインで使用するSSOサービスを指定できます。

リリース11gR1の新機能

11gR1リリースの最も重要な新機能は、アプリケーションを実行する環境およびセキュリティをプロビジョニングする環境としてOracle WebLogic Serverを導入したことです。

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

- アプリケーション・ポリシーとロール、認証ユーザーとロールおよび匿名ユーザーとロールのサポート

- 資格証明ストア・フレームワーク

- 資格証明とポリシーの管理および認可チェックを目的とした、Oracle Platform Security Services (OPSS)イベントの監査フレームワーク

- JDeveloperに統合されたアプリケーション・セキュリティ・ライフサイクルのサポート

- 強化された認可フレームワーク

- system-jazn-data.xmlでのコードベースのポリシーとサブジェクトベースのポリシーの統合

- Oracle Fusion MiddlewareおよびWLSTコマンドを使用したセキュリティの管理

- セキュリティ関連の新しいWLSTコマンド

10.1.3.xでサポートが終了した機能

リリース11gR1でサポート対象外となった機能は次のとおりです。

- JaznがOPSSに置き換えられました。

- JaznレルムAPIがユーザー/ロールAPIに置き換えられました。

- 独自のオブジェクトからJCEへのOSDTツールキットの移行がサポートされなくなりました。

- 以前にsystem-jazn-data.xmlで構成されていたアイデンティティ・ストアにかわって、WebLogic認証プロバイダが使用されるようになりました。

- Oracle Jazn管理ツールの各機能が次のように置き換えられました。

- ユーザー/ロールのCRUD操作にかわって、Oracle WebLogic管理コンソールで構成および操作する組込みLDAPを使用するようになりました。

- ログイン・モジュールの構成にかわって、Oracle WebLogic管理コンソールを使用して認証プロバイダが構成されるようになりました。

- JavaSSOがサポートされなくなりました。Oracle WebLogic Serverドメインでは、セッションのレプリケーションが有効になっている場合にのみ、クラスタでシングル・サインオン(SSO)を自動的に使用できます。

アップグレードに関するドキュメントへのリンク

以前のリリースから現在のリリースにアップグレードする場合は、次のドキュメントを参照してください。

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- 『Oracle Fusion Middleware Java EEアップグレード・ガイド』

- 『Oracle Fusion Middleware Oracle SOA Suite, WebCenterおよびADFアップグレード・ガイド』

- 『Oracle Fusion Middleware Oracle Portal, Forms, Reports and Discovererアップグレード・ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』

第I部

セキュリティの概念について

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

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

- 第2章「ユーザーおよびロールについて」

- 第3章「アイデンティティ、ポリシー、資格証明、キーおよび証明書について」

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

1 Oracle Platform Security Servicesの概要

Oracle Platform Security Services (OPSS)は、サポート対象のプラットフォームまたはスタンドアロン・アプリケーションにデプロイされるアプリケーションの保護に使用可能なセキュリティ・プラットフォームです。この章では、次の各項でこのプラットフォームの主な機能を紹介します。

- Oracle Platform Security Servicesとは

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

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

- 管理者向けのOPSS

- 開発者向けのOPSS

このドキュメントでは、Oracle Webサービスのセキュリティについては説明しません。詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』を参照してください。

Oracle Fusion Middlewareのセキュリティに関する概要は、『Oracle Fusion Middlewareセキュリティ概要』を参照してください。

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は、サード・パーティのアプリケーション・サーバーに移植できるように設計されているので、OPSSを使用すれば1つのセキュリティ・フレームワークでOracle環境とサード・パーティ環境の両方に対応できます。これにより、アプリケーションの開発、管理およびメンテナンスに要する費用を削減できます。

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 for Containers (JAAC)

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

WebLogic監査プロバイダの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogic監査プロバイダの構成に関する項を参照してください。

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

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

- Oracle WebLogic Server

- IBM WebSphere Application Server Network Deployment (ND) 7.0

- IBM WebSphere Application Server 7.0

このガイドでは、Oracle WebLogic Serverに関連するOPSS機能について記載しています。この機能は、他のすべてのプラットフォームに対しても一様に適用できます。特にサード・パーティのサーバーに該当する内容は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

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

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

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

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

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

セキュリティ・サービス・プロバイダ・インタフェース(SSPI)は、Java EEコンテナのセキュリティをパーミッションベース・モード(JACCの場合)またはリソースベース・モード(JACCではない場合)で提供します。また、環境にリソースベースの認可を提供します。

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

詳細は、『Oracle Fusion Middleware 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リポジトリに再関連付けすることができます。

注意:

このガイドでは、WebLogicのセキュリティ機能については詳しく説明しません。SSPIに関する特定の情報を使用または想定している箇所では、適切なドキュメントを参照先として示しています。

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

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

Oracle ADFのセキュリティはJAASセキュリティ・モデルに基づいており、このモデルはOPSSを使用しています。Oracle ADFのセキュリティでは、LDAPベースまたはファイルベースのポリシー・ストアおよび資格証明ストアをサポートし、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管理コンソール、OPSSスクリプト、Fusion Middleware ControlまたはOracle Entitlements Serverを使用してアプリケーション・セキュリティを管理するガイドラインは次のようになります。

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

- 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アプリケーションの保護

その他のユースケースについては、第19.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 Fusion Middleware Oracle Application Development Framework Fusion開発者ガイドの第29章を参照してください。

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

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

構成

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アプリケーション向けセキュリティの構成の詳細は、第22.2項「Java SEアプリケーション向け認証」および第23.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。

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

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

$ORACLE_HOME/oracle_common/modules/oracle.jps_11.1.1/jps-manifest.jar

ログイン・モジュール

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

Java SEアプリケーションでの使用にお薦めするログイン・モジュールはIdentityStoreログイン・モジュールです。

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

2 ユーザーおよびロールについて

この章では、匿名ロール、認証ロール、ロール・マッピング、ロール・カテゴリなどのユーザーとロールの様々な特性について説明します。また、このガイド全体で使用する用語の定義と、ユーザーおよびロールAPIフレームワークの概要についても説明します。

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

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

- 用語

- ロール・マッピング

- 認証ロール

- 匿名ユーザーとロール

- 管理ユーザーとロール

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

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

- ロール・カテゴリ

プログラムによるユーザーとロールの管理の詳細は、第25章「ユーザー/ロール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つ以上の権限を使用するポリシーはリソースに基づくポリシーと呼ばれます。

図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のみです。

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

その他の用語

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

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

2.2 ロール・マッピング

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

注意:

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

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

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

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

重要:

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

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

OPSSスクリプトによるアプリケーション・ロール階層の管理方法の詳細は、第9.3.4項「grantAppRole」および第9.3.5項「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.WLSGroupImpl</class>
<name>developer_group</name>
</membe>
<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)サブジェクトが正常に認証された場合は、認証ロールが含まれるほか、構成によっては匿名ロールも含まれます。

- アプリケーション・ロールです。したがって、あらゆるアプリケーションで使用でき、アプリケーションのロール階層に追加できます。

認証ロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。

認証ロールの一般的な用途は、共通のアプリケーション・リソース、つまり認証されたユーザーが利用できるリソースへのアクセスを、認証されたユーザーに許可することです。

認証されたロールの使用をアプリケーション側で手動で構成する方法の詳細は、第21.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

2.4 匿名ユーザーとロール

OPSSでは、匿名ユーザーと匿名ロールという、2つの特殊なエンティティを使用できます。認証ロールと同様に、これらのエンティティを宣言する必要はなく、アプリケーションによってJpsFilterまたはJpsInterceptorでその使用が構成されます。これらのどのエンティティも、アプリケーションのロール階層内でアプリケーションによって使用できます。

この匿名のエンティティを有効にしておくと、認証されていないユーザーが非保護リソースにアクセスするとき、そのユーザーは匿名ユーザーと匿名ロールのみが移入されたサブジェクトで表されます。そのサブジェクトが保護されたリソースにアクセスを試みた場合、認可過程でサブジェクトは「匿名サポートとサブジェクト」の説明のように処理されます。

匿名ユーザーおよびロールに付与するパーミッションは、明示的に指定する必要はなく、所属先のエンタープライズ・グループおよびアプリケーション・ロールから暗黙的に派生します。

匿名ユーザーおよびロールの一般的な用途は、認証されていないユーザーにパブリックな非保護リソースへのアクセスを許可することです。

匿名ユーザーおよび匿名ロールの使用をアプリケーション側で手動で構成する方法の詳細は、第21.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

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

この項では、全体を通じて匿名ユーザーおよび匿名ロールの使用が有効になっていることを前提とします。

エンドユーザーが初めて非保護リソースにアクセスした場合、サブジェクトが作成され、そのサブジェクトに匿名ユーザーと匿名ロールに対応した2つのプリンシパルが移入されます。非保護リソースに関するかぎり、そのサブジェクトは変更されず認証は行われません。

保護されたリソースにそのサブジェクトがアクセスすると認証が始まり、この時点までは匿名ロールのみを持っていたサブジェクトが、認証プロセスの結果に応じて次のように変更されます。

認証に成功した場合は次のようになります。

1. 匿名ユーザーがサブジェクトから削除され、必要に応じて、認証されたユーザーに置換されます。

2. 匿名ロールは削除され、認証ロールが追加されます。

3. その他のロールが、必要に応じてサブジェクトに追加されます。

認証に成功すると、サブジェクトには、非匿名ユーザーに対応した1つのプリンシパル、認証ロールに対応した1つのプリンシパル、および場合によってはエンタープライズ・ロールまたはアプリケーション・ロールに対応した他のプリンシパルが含まれるようになります。

認証が成功しなかった場合は、匿名ユーザーが保持されます。匿名ロールは、アプリケーションによるJpsFilterまたはJpsInterceptorの構成に応じて削除または保持されます。他のプリンシパルは追加されません。デフォルトでは、匿名ロールはサブジェクトから削除されます。

2.5 管理ユーザーとロール

(WebLogic)管理者は、グループAdministratorsのユーザー・メンバーであり、このグループにはセキュリティ・レルムに存在している任意のユーザーを追加できます。

セキュリティ・レルムに存在するデフォルト・グループの詳細は、Oracle Fusion Middlewareのロールとポリシーを使用したリソースの保護のユーザー、グループ、およびセキュリティ・ロールに関する項を参照してください。

通常、管理者にはデフォルト名はありません。唯一の例外は実行例をインストールした場合で、その際はサンプル・ドメインの管理者のデフォルト・ユーザー名とパスワードが提供されます。ただし、これらの例は本番環境では使用しないでください。

詳細は、『Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護』のセキュアな方法によるWebLogic Serverのインストールに関する項を参照してください。

ドメインを構成すると、Administratorsグループのメンバーは、セキュリティ・レルムに作成されたユーザーを、いつでもAdministratorsグループに追加したりグループから削除することができます。これらのアカウントを管理するための2つの基本ツールが、Oracle WebLogic管理コンソールとOracle WebLogic Scripting Tool (WLST)です。

詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのグループへのユーザーの追加に関する項および『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』のWebLogic Scripting Toolの使用に関する項を参照してください。

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

この項では、ユーザー・アカウントの作成とこれらのパスワードの保護に関する情報へのリンクをいくつか紹介します。

- パスワードの作成の一般的なガイドラインは、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのユーザーおよびグループの管理に関する項を参照してください。デフォルトの認証プロバイダでは、8文字以上の長さのパスワードが必要ですが、これは構成可能です。
パスワードの作成に関するいくつかの推奨事項は、『Oracle Fusion Middleware Oracle WebLogic Server本番環境の保護』のWebLogic Serverホストの保護に関する項を参照してください。

- 一般的に、パスワードは、LDAPサーバーまたはRDBMSに格納されます。これらのパスワードが格納される特定の場所は、環境(正確にはドメインのセキュリティ・レルム)内で構成された固有の認証プロバイダによって決定されます。追加設定なしで使用できる認証プロバイダの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の組込みLDAPサーバーの管理に関する項を参照してください。

- カスタマイズ可能なパスワード作成ルールを適用するパスワード検証プロバイダを、パスワードを作成したときに自動的にコールできるオプションがあります。このオプションの構成方法は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のパスワード検証プロバイダの構成に関する項を参照してください。

- ユーザーの追加または削除の際は、第L.11項「ユーザーによる予期しないパーミッションの取得」の説明にある推奨事項を考慮してください。

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

この項では、プリンシパルの比較がOPSS認可に及ぼす影響とプリンシパル名の比較ロジックを制御するシステム・パラメータについて説明します。この項の内容は次のとおりです。

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

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

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

ユーザーが適切に認証されると、そのユーザーについてアイデンティティ・ストアに格納されているユーザー名およびエンタープライズ・グループ名(ユーザーが所属するエンタープライズ・グループ名)と一致するプリンシパルを持つサブジェクトが移入されます。

これに対し、ユーザー(またはエンタープライズ・グループ)を認可する必要がある場合は、アプリケーション・ロールがエンタープライズ・グループにどのようにマップされているかがシステムで考慮され、ポリシー・ストアに格納されているアプリケーション権限の名前から別のプリンシパルが構築されます。

プリンシパルを認可するために、サブジェクトに(アイデンティティ・ストアで検出された名前から)移入されたプリンシパル名とポリシー・ストアの名前から構築されたプリンシパル名が比較されます。これらのプリンシパル名が一致した場合にのみ、そのユーザー(またはグループ)が認可されます。

したがって、想定どおりにプリンシパル名が機能するには、認可プロバイダでプリンシパル名を適切に比較することが重要です。

たとえば、アイデンティティ・ストアに格納されているユーザー名が「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. サーバーを再起動します。サーバーが再起動するまで、変更は有効になりません。

OPSSスクリプトを使用してこれらのパラメータを設定することもできます。WebLogic Serverの構成の詳細は、『Oracle Fusion Middleware 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管理者ガイドを参照してください。

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

<role-categories>
<role-category>
<name>RC_READONLY</name>
<display-name>RC_READONLY display name</display-name>
<description>RC_READONLY description</description>
<members>
<role-name-ref>AppRole1</role-name-ref>
<role-name-ref>AppRole2</role-name-ref>
<role-name-ref>AppRole3</role-name-ref>
</members>
</role-category>
</role-categories>

ロール・カテゴリでは、大文字と小文字は区別されません。ロール・カテゴリは、インタフェースRoleCategoryManagerを使用して管理できます。

このインタフェースの詳細は、Javadocドキュメントの『Oracle Fusion Middleware Java API Reference for Oracle Platform Security Services』を参照してください。

3 アイデンティティ、ポリシー、資格証明、キーおよび証明書について

アプリケーションでは、それを実行しているドメインで構成されたアイデンティティ・ストア、ポリシー・ストア、資格証明ストア、およびキーストアを使用します。この章では、アイデンティティ、ポリシー、資格証明およびキーストア・データに関する基本概念について説明します。ここでは、次の項目について説明します。

- 認証の基本

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

- 資格証明ストアの基本

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

この章で使用する用語の定義は、第2.1項「用語」を参照してください。

ストアの利用法を示すシナリオは、第4章「Oracle Platform Security Servicesのシナリオについて」を参照してください。

3.1 認証の基本

OPSSではサーバー認証プロバイダを使用します。この認証プロバイダは、ユーザー名とパスワードの組合せまたはデジタル証明書に基づき、ユーザーの資格証明またはシステム・プロセスを検証するコンポーネントです。認証プロバイダには、必要に応じ、ドメイン内の他のコンポーネントでサブジェクトを介してユーザー・アイデンティティ情報を使用できるようにする機能もあります。

Java EEアプリケーションではLDAPベースの認証プロバイダを使用する必要があります。Java SEアプリケーションの場合、追加設定なしで使用できるアイデンティティ・ストアはファイルベースですが、LDAPベースのアイデンティティ・ストアとして構成することもできます。

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

注意:

OPSSでは、アプリケーション開発で使用したユーザーおよびグループを、アプリケーションのデプロイ先とするリモートOPSSスクリプトに自動的に移行することはできません。そのかわりに、ドメインに構成済みの認証プロバイダに応じて、Oracle WebLogic管理コンソール、OPSSスクリプトまたは適切なツールを使用し、必要なアプリケーション・アイデンティティを別途作成する必要があります。

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

- サポートされているLDAPアイデンティティ・ストアのタイプ

- Oracle WebLogicの認証プロバイダ

- WebSphereのアイデンティティ・ストア

3.1.1 サポートされているLDAPアイデンティティ・ストアのタイプ

アイデンティティ・ストアでサポートされているLDAPリポジトリは、次のとおりです。

- Oracle Internet Directory 11g

- Oracle Virtual Directory

- Oracle Directory Server Enterprise Edition 11.1.1.3.0

- Active Directory 2008

- Novell eDirectory 8.8

- OpenLDAP 2.2。このタイプに必要な特殊構成については、付録J「OpenLDAPアイデンティティ・ストアの使用」を参照してください。

- Tivoli Access Manager

- Sun DS 6.3、7.0

- Oracle DB 10g、11gR1、11gR2

- iPlanet Directory Server

- カスタム認証プロバイダ

Oracle Fusion Middlewareの動作保証およびサポートされている構成の詳細は、http://www.oracle.com/technology/software/products/ias/files/fusion_certification.htmlを参照してください。

Oracle Internet Directoryサーバーにおける参照整合性のサポートについては、第8.2項「LDAPベースのOPSSセキュリティ・ストアの使用」の重要事項を参照してください。

3.1.2 Oracle WebLogicの認証プロバイダ

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

利用可能な認証プロバイダ、およびその認証プロバイダの選択と構成の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項、およびOracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの認証プロバイダおよびIDアサーションの構成に関する項を参照してください。

追加設定がない状態のOracle WebLogic Serverでは、ユーザーとグループがデフォルトでDefaultAuthenticatorに格納されます。この認証プロバイダは、デフォルト属性としてcnを使用するように設定されています。

LDAP認証プロバイダに格納されたデータには、ユーザー/ロールAPIでアクセスしてユーザー・プロファイル属性を問い合せることができます。WebLogicのLDAP認証プロバイダの詳細は、次の各項を参照してください。

- LDAP認証プロバイダの使用

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

- その他の認証方式

重要:

ドメインでDefaultAuthenticatorを使用する場合は、アプリケーションでユーザー/ロールAPIを使用してデータを問い合せることができるように、ドメイン管理サーバーを実行している必要があります。

OPSSでは、ドメインにLDAPベースの認証プロバイダを1つ以上構成しておく必要があります。

X.509 IDアサーションの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のLDAP X509 IDアサーション・プロバイダのしくみに関する項を参照してください。

IDアサーション・プロバイダとしてSAML 1.1またはSAML 2.0を使用した認証の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSAML認証プロバイダの構成に関する項を参照してください。

3.1.2.1 LDAP認証プロバイダの使用

Oracle WebLogic Serverでは、LDAPベースの認証プロバイダをいくつか提供しています。利用可能なLDAPサーバーの詳細は、サポートされているLDAPアイデンティティ・ストアのタイプを参照してください。WebLogicのDefaultAuthenticatorは構成済みのデフォルトの認証プロバイダであり、、インストール後すぐに使用できます。その他の認証プロバイダはWebLogic管理コンソールを使用して構成可能です。

Java SEアプリケーションでの認証の使用の詳細は、第22.2.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」を参照してください。

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

Oracle WebLogic Serverでは、複数の認証プロバイダのそれぞれに制御フラグを設定し、特定のコンテキストでこれらの認証プロバイダを構成できます。そのうちの1つは、LDAPベースの認証プロバイダとする必要があります。

OPSSでは、構成済のLDAP認証プロバイダのリストから次のアルゴリズムに従って選択したLDAP認証プロバイダを使用して、アイデンティティ・ストア・サービスを初期化します。

1. 構成されているLDAP認証プロバイダのサブセットを検討します。コンテキストではLDAP認証プロバイダが1つ以上指定されていることが前提なので、このサブセットは空ではありません。

2. そのサブセットの中で、最大のフラグが設定されている認証プロバイダを検討します。このサブセットでの計算に使用するフラグの順序は次のとおりです。

REQUIRED > REQUISITE > SUFFICIENT > OPTIONAL

このサブセット(最大のフラグを実現するLDAPのサブセット)も空ではありません。

3. そのサブセットの中から、該当のコンテキストで最初に構成された認証プロバイダを検討します。

ステップ3で選択したLDAP認証プロバイダを、アイデンティティ・ストア・サービスの初期化に使用します。LDAP認証プロバイダを使用してSSL接続を確立する際のホスト名検証の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』を参照してください。

サポートされている様々なLDAP認証プロバイダの初期化にOPPSが使用するデフォルト値の詳細は、第H.1項「OPSS APIリファレンス」のユーザーおよびロールAPIに関する説明を参照してください。サービス・インスタンスの初期化値が、デフォルトでもサービス・インスタンスの構成でも(明示的に)提供されている場合は、構成された値がデフォルト値よりも優先されます。

重要:

DefaultAuthenticatorを除き、ドメインで使用するすべてのLDAPベースの認証プロバイダでは、フラグUseRetrievedUserNameAsPrincipalを設定する必要があります。DefaultAuthenticatorでは、追加設定なしでこのフラグが設定されています。

3.1.2.3 その他の認証方式

WebLogic IDアサーション・プロバイダでは、X.509証明書、SPNEGOトークン、SAMLアサーション・トークンおよびCORBA Common Secure Interoperability version 2(CSIv2)IDアサーションを使用した証明認証がサポートされています。

ネゴシエート・アイデンティティ・プロバイダは、SPNEGOプロトコルをサポートするMicrosoftクライアントでSSOに使用します。このプロバイダは、SPNEGOトークンをデコードしてKerberosトークンを取得し、このKerberosトークンを検証してWebLogicユーザーにマップします。

IDアサーション・プロバイダの一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティについて』のIDアサーション・プロバイダに関する項を参照してください。

Microsoftクライアントを使用したSSOの概要は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のMicrosoftクライアントでのシングル・サインオンの概要に関する項を参照してください。

Kerberos IDの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogic Server用のKerberos IDの作成に関する項を参照してください。

3.1.3 WebSphereのアイデンティティ・ストア

WebSphereの場合、OPSSはLDAPベースのレジストリのみをサポートします。特に、WebSphereに組み込まれているファイルベースのユーザー・レジストリはサポートしません。

レジストリの構成方法およびシード方法の詳細は、Oracle Fusion Middleware サード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

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(リリース10.2.0.4以降、リリース11.1.0.7以降、およびリリース11.2.0.1以降)のみでサポートされています。

ポリシー・ストアのスコープ、移行、および再関連付け

1つのドメインに1つのポリシー・ストアがあります。開発段階では、アプリケーション・ポリシーはファイルベースで、ファイルjazn-data.xmlで指定します。

Fusion Middleware Controlを使用してアプリケーションをWebLogicにデプロイすると、ポリシー・ストアに自動的に移行することができます。この機能の詳細は、第8.6.1項「Fusion Middleware Controlを使用した移行」を参照してください。デフォルトでは、ポリシー・ストアはファイル・ベースになります。

アプリケーションをWebSphereにデプロイすると、第21.4.項「ポリシーの移行を制御するパラメータ」および第21.4.4項「資格証明の移行を制御するパラメータ」に記載されているように、デプロイ時の移行の動作を手動で指定できます。

再関連付けの詳細は、第8.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

注意:

パーミッション・クラスはすべて、システム・クラスパスで指定する必要があります。

ポリシー・ストアでのリソース・カタログのサポートの詳細は、第20.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でのみサポートされています。

アプリケーションがデプロイされるときに、アプリケーションの資格証明が自動的に資格証明ストアに移行されるように構成することができます。詳細は、第8.6.1項「Fusion Middleware Controlを使用した移行」を参照してください。

あるタイプのストアから別のタイプのストアに、資格証明を再び関連付けることもできます。詳細は、第8.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

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

キーストア・サービスは、ドメインのコンポーネントおよびアプリケーションによって使用されるすべてのキーと証明書を含むキーストアおよびトラスト・ストアに対する中央リポジトリを提供します。これにより、キーストアを個々のアプリケーションに関連付ける必要がなくなります。

管理者は単一のユーザー・インタフェースを使用して、一貫した方法ですべてのキーストアを表示および管理できます。

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

中央リポジトリには次のものを使用できます。

- XMLファイルベース
これが出荷時のキーストア・リポジトリであり、名前はfile-keystores.xmlです。

注意:

このファイルはインストール直後には存在せず、後で作成されます。

- Oracle Database

- LDAPディレクトリ

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

ドメイン・キーストア・リポジトリ内のキーおよび証明書は、1つのタイプから別のタイプへと関連付けを変更できます。詳細は、第8.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

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

この章では、Oracle Platform Security Servicesでサポートされているいくつかの一般的なセキュリティ・シナリオについて説明します。また、サポートされているLDAPサーバー、DBサーバー、XMLサーバーや、各シナリオで管理者がセキュリティ・データを管理するために使用する管理ツール、さらに、ポリシーおよび資格証明に対するパッケージ要件についても取り上げます。

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

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

- 管理ツール

- パッケージ要件

- シナリオの例

- その他のシナリオ

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

Oracle Platform Security Servicesでは、次のLDAPベース、DBベース、およびファイルベースのリポジトリがサポートされています。

- 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)

- RDBMS (Oracle Database)

重要:

Oracle Internet Directory 10.1.4.3をOPSSとともに使用する場合は、Oracle Bug#8351672に対する必須の個別パッチをOracle Internet Directory 10.1.4.3に適用することをお薦めします。使用しているプラットフォームのパッチをMy Oracle Support(http://myoraclesupport.oracle.com)からダウンロードします。

最適なパフォーマンスを確保するには、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 Fusion Middleware Oracle WebLogic Serverの保護』のLDAP認証プロバイダの構成に関する項を参照してください。特に、DefaultAuthenticatorは追加設定なしで使用できますが、その使用は、ユーザーに対してはエントリが10,000以下、グループに対してはエントリが2,500以下の開発環境に限定することをお薦めします。

1つのLDAPベースのストアに格納されているポリシー、資格証明およびキーは、同一の物理永続リポジトリを使用する必要があります。詳細は、次の各章を参照してください。

- 第9章「ポリシー・ストアの管理」

- 第10章「資格証明ストアの管理」

- 第11章「キーストア・サービスでのキーと証明書の管理」

Oracle WebLogic Serverでは、サーバーが起動するには、ドメインDBベースのOPSSセキュリティ・ストアが稼働している必要があります。

4.2 管理ツール

セキュリティ管理者が使用できるツールは、次のとおりです。

- WebLogic管理コンソール

- Oracle Enterprise Manager Fusion Middleware Control

- Oracle Entitlements Server

- OPSSスクリプト(サポートされているすべてのプラットフォームで使用可能)

- LDAPサーバー固有のユーティリティ

セキュリティ・データの管理に使用するツールは、格納するデータのタイプと、そのデータの保持に使用するストアの種類に応じて異なります。WebSphere Application Serverにデプロイされたアプリケーションの場合、WebSphere Application Server管理コンソールもあります。詳細は、WebSphere Application Serverドキュメントを参照してください。OPSSスクリプトは、WebLogicとWebSphereの両方のプラットフォームで使用できます。

ユーザーとグループ

DefaultAuthenticatorを使用してアイデンティティを格納するドメインでは、Oracle WebLogic Server管理コンソールを使用して、格納したデータを管理します。DefaultAuthenticatorに格納したデータにユーザー/ロールAPIを使用してアクセスし、ユーザー・プロファイル属性を問い合せることもできます。また、DefaultAuthenticatorでユーザーまたはグループに別の属性を挿入する場合も、アプリケーションでユーザー/ロールAPIを使用します。

重要:

ドメインでDefaultAuthenticatorを使用する場合は、アプリケーションでユーザー/ロールAPIを使用してアイデンティティ・データを操作できるように、ドメイン管理サーバーを実行している必要があります。

この認証プロバイダの構成の詳細は、第3.1.2.1項「LDAP認証プロバイダの使用」を参照してください。

また、デフォルトの認証プロバイダとは異なる他のLDAPサーバー、またはDBを認証に使用する場合は、そのLDAPサーバーのサービスを使用してユーザーとグループを管理します。

ポリシー、資格証明、キーおよび証明書

ポリシー、キーおよび資格証明は、同じ種類の記憶域(ファイルベース、LDAPベース、またはDBベース)を使用する必要があり、LDAPベースの場合は、同じ種類のLDAPサーバー(Oracle Internet Directoryに限る)を使用する必要があります。

ポリシーおよび資格証明データを管理するには、第9.2項「Fusion Middleware Controlを使用したポリシーの管理」および第10.4項「Fusion Middleware Controlを使用した資格証明の管理」の説明に従ってFusion Middleware Controlを使用するか、第9.3項「OPSSスクリプトによるアプリケーション・ポリシーの管理」および第10.5項「OPSSスクリプトによる資格証明の管理」の説明に従ってOPSSスクリプトを使用します。

また、ポリシー・データを管理するには、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの説明に従って、Oracle Entitlements Serverを使用します。

キーと証明書を管理するには、Fusion Middleware ControlおよびWLSTを使用します。詳細は、第11章「キーストア・サービスでのキーと証明書の管理」を参照してください。

セキュリティ・データの管理で使用する各種ツールを次にあげます。

- アイデンティティ・データ

- デフォルトの認証プロバイダ: 管理コンソールを使用

- その他のLDAPまたはDBストア: LDAPサーバーまたはDBに用意されているユーティリティを使用

- ポリシーおよび資格証明データ

- ファイルベース: Fusion Middleware ControlまたはWLSTを使用

- LDAPベース: Fusion Middleware Control、WLSTまたはOracle Entitlements Serverを使用して、ポリシーを管理します。

- キーと証明書

- WLSTを使用

ポリシー、資格証明またはキーを変更してもサーバーを再起動する必要はありません。ファイルjps-config.xmlを変更した場合はサーバーを再起動する必要があります。

注意:

一般に、ドメインの構成を変更した場合はサーバーを再起動する必要があります。ただし、ドメイン・データを変更してもサーバーを再起動する必要はありません。ドメインの構成の変更の一例として、ドメイン・ストアの再関連付けがあります。

アプリケーションのデプロイ時に、アプリケーションのポリシーと資格証明をドメイン・ストアに自動的に移行する方法の詳細は、第8.6項「OPSSセキュリティ・ストアの移行」を参照してください。

WebSphere Application Serverでツールを管理する方法の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

4.3 パッケージ要件

ファイルベースのアプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションとパッケージ化するためにサポートされている唯一の方法は、このファイルをEARファイルのディレクトリMETA-INFに置くことです。

ファイルベースのアプリケーション資格証明は、ファイルcwallet.ssoで定義します。このファイルをアプリケーションとパッケージ化するためにサポートされている唯一の方法は、このファイルをEARファイルのディレクトリMETA-INFに置くことです。詳細は、第21.3項「Java EEアプリケーションの手動によるパッケージ化」を参照してください。

WebLogicへのデプロイの詳細は、第6章「セキュア・アプリケーションのデプロイ」を参照してください。

WebSphereでは、デプロイ時の動作はファイルMETA-INF/opss-application.xmlで指定したプロパティによって制御されます。ポリシーの移行に関する詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。資格証明の移行に関する詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

注意:

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 Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの認証プロバイダとIDアサーション・プロバイダの構成に関する項を参照してください。

OPSSセキュリティ・ストアの構成方法の詳細は、第8章「OPSSセキュリティ・ストアの構成」を参照してください。

ポリシー管理の詳細は、第9章「ポリシー・ストアの管理」を参照してください。

資格証明管理の詳細は、第10章「資格証明ストアの管理」を参照してください。

WebSphere Application ServerでOracle Fusion Middlewareを管理する方法の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

キーストア・サービスの管理の詳細は、キーストアの管理に関する章を参照してください。

一般的なシナリオ1

このシナリオでは、開発中のJava EEアプリケーションを示します。

認証: このアプリケーションではデフォルトの認証プロバイダを使用します。これは、開発環境では一般的な扱いです。

認可: ポリシー・ストアと資格証明ストアはファイルベースです。

バリエーション: このアプリケーションでは、SSOおよびJava EEセキュリティに対するWebLogicサポートを使用します。

WebLogicのSSOに関するサポートの詳細は、『Oracle Fusion Middleware 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の詳細は、第24.1項「資格証明ストア・フレームワークAPIについて」を参照してください。

4.5 その他のシナリオ

次のシナリオは、アプリケーション開発段階で一般的に使用するDefaultAuthenticatorではない認証プロバイダまたはなんらかのAPIをアプリケーションで使用してセキュリティ・データにアクセスするという点で、一般的なシナリオとは異なります。

シナリオ4

認証: このアプリケーションでは、DefaultAuthenticatorではないLDAP認証プロバイダを使用します。

認可: ポリシーと資格証明の両方で、LDAPベースの同じOracle Internet Directoryストアを使用します。

バリエーション: このアプリケーションでは、DBのユーザー・プロファイルへのアクセスにユーザー/ロールAPIを使用し、資格証明へのアクセスに資格証明ストア・フレームワーク(CSF) APIを使用します。

ユーザー/ロールAPIの詳細は、第25章「ユーザーおよびロールAPIを使用した開発」を参照してください。

CSF APIの詳細は、第24.1項「資格証明ストア・フレームワークAPIについて」を参照してください。

シナリオ5

認証: このアプリケーションでは、テスト環境および本番環境で一般的なOracle Internet Directory LDAP認証プロバイダを使用します。

認可: ポリシー・ストアと資格証明ストアは、ファイルベースであり、アプリケーションとパッケージ化されます。これらのデータは、デプロイ時に自動的にドメイン・セキュリティ・データにマップされます。

バリエーション: デプロイ後、一方向SSL伝送チャネルで構成したLDAPベースのストアに、ポリシー・ストアおよび資格証明ストアを再度関連付けします。

デプロイ時に、アプリケーションのセキュリティ・データを自動的に移行する方法の詳細は、第8.6項「OPSSセキュリティ・ストアの移行」を参照してください。

再関連付けの詳細は、第8.5項「OPSSセキュリティ・ストアの再関連付け」を参照してください。

SSLの構成の詳細および関連トピックは、次のサイトを参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のSSLの構成に関する項

- 『Oracle Fusion Middleware管理者ガイド』

- Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプのSSLの設定に関する項

- 『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』のJavaクライアントにおけるSSL認証の使用に関する項

シナリオ6

このシナリオでは、OPPS APIを使用するJava SEアプリケーションを示します。

認証: このアプリケーションでは、LoginService APIを使用します。

認可: このアプリケーションではメソッドCheckPermissionを使用します。

また、このアプリケーションでは、ドメイン認証プロバイダへの属性の問合せにユーザー/ロールAPIを使用し、資格証明ストアへの問合せに資格証明ストア・フレームワークAPIを使用します。

第II部

OPSSの基本的な管理

このパートでは、次の各章でOPSSの基本的な管理機能について説明します。

- 第5章「セキュリティ管理」

- 第6章「セキュア・アプリケーションのデプロイ」

5 セキュリティ管理

この章では、管理者が使用できるツール、およびアプリケーションのセキュリティを管理するための一般的なタスクについて説明します。この章の内容は次のとおりです。

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

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

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

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

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

- OPSSスクリプトを使用した一般的なセキュリティ操作

高度な管理タスクは、付録E「WLSTスクリプトおよび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 Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』の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管理コンソールまたはWebSphereのコマンドconfigureIdentityStore

Oracle ADFアプリケーションに対する資格証明の管理

資格証明

Oracle ADFアプリケーションでの匿名ロールの有効化

セキュリティ・プロバイダ構成

Oracle ADFアプリケーションでの認証ロールの有効化

セキュリティ・プロバイダ構成

Oracle ADFアプリケーションでのJAASの有効化

セキュリティ・プロバイダ構成

Oracle ADFアプリケーションでのエンタープライズ・グループへのアプリケーション・グループのマップ

アプリケーション・ロールまたは
アプリケーション・ポリシー

Oracle Entitlements Server

Oracle ADFアプリケーションでのシステム全体のポリシーの管理

システム・ポリシー

OPSSのプロパティの構成

セキュリティ・プロバイダ構成

ポリシーおよび資格証明ストアの再関連付け

セキュリティ・プロバイダ構成

前述のタスクのためのOracle WebLogic管理コンソールの使用方法の詳細は、次のドキュメントを参照してください。

- 管理コンソールの一般的な使用方法は、Oracle Fusion Middleware 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 Fusion Middleware Oracle WebLogic Serverの保護』の第6章を参照してください。

- ドメイン管理アカウントを管理する方法は、『Oracle WebLogic Server ロールおよびポリシーによるリソースの保護』の第6章を参照してください。

- LDAPアイデンティティ・ストアの構成の詳細は、第3.1.2項「Oracle WebLogicの認証プロバイダ」および第3.1.3項「WebSphereのアイデンティティ・ストア」を参照してください。

注意:

OPSSでは、サーバー・ファイルの自動バックアップおよび自動リカバリはサポートされません。サーバー管理者が、必要に応じてすべてのサーバー構成ファイルを定期的にバックアップすることをお薦めします。

Oracle Fusion Middlewareのバックアップとリカバリの詳細は、『Oracle Fusion Middleware管理者ガイド』の第15章「バックアップとリカバリの概要」を参照してください。

5.2.1 新しい本番環境の設定

既存の環境に基づいた新しい本番環境は、次の方法で設定できます。

- Oracleクローニング・ユーティリティを使用して、構築済の環境をレプリケートします。詳細は、『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middlewareエンティティのクローニングに関する項を参照してください。

- 構築済の環境を設定したときと同様にソフトウェアを再インストールし、環境を構成します。

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

Fusion Middleware Controlは、アプリケーションのネットワークの管理を1か所でできるようにするWebベースのツールです。Oracle SOAアプリケーション、Oracle ADFアプリケーション、Oracle WebCenter、およびOPSSを使用するその他のOracleアプリケーションのデプロイ、構成、監視、診断および監査にFusion Middleware Controlを使用します。この項では、セキュリティ関連の操作についてのみ説明します。

このツールには、セキュリティに関連する様々な管理タスクが用意されています。管理者は、このツールを使用して次のタスクを実行できます。

- インストール後、アプリケーションをデプロイする前にポリシー・ストアと資格証明ストアを再関連付けします。詳細は、第8.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。

- インストール後、アプリケーションをデプロイする前にOPSSのプロパティを定義します。詳細は、第8.7項「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。

- デプロイ時に、ファイルベースのアプリケーション・ポリシーおよび資格証明からLDAPベースのドメイン・ポリシーおよび資格証明への自動的な移行を構成します。
詳細は、次の各項を参照してください。

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

- 第8.6項「OPSSセキュリティ・ストアの移行」

- アプリケーションのデプロイ後、そのアプリケーションで次のタスクを実行できます。

- アプリケーション・ポリシーの管理。詳細は、第9.1項「ポリシー・ストアの管理」を参照してください。

- 資格証明の管理。詳細は、第10.3項「資格証明ストアの管理」を参照してください。

- アプリケーション・ロールからユーザー、グループおよびアプリケーション・ロールへのマッピングの指定。詳細は、第9.2.2項「アプリケーション・ロールの管理」を参照してください。

- ドメインでのシステム・ポリシーの管理。詳細は、第9.2.3項「システム・ポリシーの管理」を参照してください。

- ドメインでのOPSSのプロパティの管理。詳細は、第8.7項「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。

セキュリティ管理タスクの要約およびこれらのタスクの実行に使用するツールは、「基本的なセキュリティ管理タスク」を参照してください。

その他の機能の詳細は、Fusion Middleware Controlオンライン・ヘルプ・ドキュメントを参照してください。

WebSphere Application ServerでOracle Fusion Middlewareを管理する方法の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

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

Oracle WebLogic管理コンソールは、Webベースのツールであり、いくつかある機能の中でも特に、アプリケーションのデプロイと再デプロイ、ドメインの構成およびアプリケーション・ステータスの監視ができます。この項では、セキュリティ関連の操作についてのみ説明します。

Oracle WebLogic管理コンソールで実行する一般的なタスクは、次のとおりです。

- Oracle WebLogic Serverの起動と停止。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverサーバーの起動と停止の管理』のサーバーの起動と停止に関する項を参照してください。

- Oracle WebLogic Serverおよびドメインの構成。詳細は、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』の既存のドメインの構成に関する項を参照してください。

- アプリケーションのデプロイ。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』を参照してください。

- フェイルオーバー・サポートの構成。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverクラスタの使い方』のクラスタでのフェイルオーバーとレプリケーションに関する項を参照してください。

- WebLogicドメインおよびWebLogicレルムの構成。

- ドメイン認証プロバイダでのユーザーおよびグループの管理。

- MSクライアント、WebブラウザおよびHTTPクライアントに対するシングル・サインオンの使用の有効化。

- 管理ユーザーおよび管理ポリシーの管理。

Oracle WebLogic管理コンソールの詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプを参照してください。

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

Oracle Entitlements Serverで実行する一般的なセキュリティ・タスクは、次のとおりです。

- アプリケーションのセキュリティ・アーティファクトの検索。

- ポリシーなどの、アプリケーションのセキュリティ・アーティファクトの管理。

- 外部のロールの階層の表示。

- アプリケーション・ロールの階層の管理。

Oracle Entitlements Serverによるアプリケーションのセキュリティ管理に最も頻繁に使用するセキュリティ・タスクのリストは、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

5.6 OPSSスクリプトを使用した一般的なセキュリティ操作

Oracle WebLogic管理コンソールで実行できるほとんどの操作は、OPSSスクリプトで行えます。これは、ドメインの構成やアプリケーションのデプロイメントなどの管理タスクのスクリプト作成と自動化を実現する一連のコマンドライン・インタフェースです。

セキュリティ関連のOPSSスクリプトのリストは、付録I「OPSSスクリプト」を参照してください。すべてのWLSTスクリプトのリストは、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』を参照してください。

WebSphere Application ServerでOracle Fusion Middlewareを管理する方法の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

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

アプリケーションをOracle WebLogic Serverにデプロイするには、Oracle WebLogic Server管理コンソール、Oracle Enterprise Manager Fusion Middleware Control、Oracle JDeveloper、またはWebSphere Application Serverコンソールのいずれかのツールを使用します。WebLogicサーバーに認識されている場所にビットを設定することで、アプリケーションを起動することもできます。この場合、サーバーを再起動する必要はありません。このような種類のアプリケーション起動は、ホット・デプロイとして知られています。

アプリケーションをデプロイするための推奨方法は、プラットフォーム、アプリケーションのタイプ、およびそのアプリケーションが開発中フェーズと開発後フェーズのどちらのフェーズにあるかによって異なります。たとえば、開発後フェーズでは通常、ホット・デプロイを使用して本番環境でアプリケーションを起動します。

この章で説明する推奨事項は、Oracle ADFアプリケーションと、OPSSを使用するJava EEアプリケーションにのみ当てはまります。

開発時には、Oracle JDeveloperを使用してアプリケーションを組込みOracle WebLogic Serverにデプロイすることが普通です。テスト環境または本番環境に移行したアプリケーションは、通常、Fusion Middleware ControlまたはOracle WebLogic Server管理コンソールあるいはホット・デプロイを使用してデプロイします。

この章では、Oracle ADFアプリケーションまたはPure Java EEアプリケーションのデプロイ時に実行する管理タスクを中心に説明します。最後の項では、アプリケーションを手動でパッケージ化する場合のみを対象として、セキュアJava EEアプリケーションのパッケージ要件について説明します。

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

- 概要

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

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

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

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

補足ドキュメント

デプロイメントの詳細は、『Oracle Fusion Middleware管理者ガイド』の第8章「アプリケーションのデプロイ」を参照してください。

デプロイメントから本番に至るまで、アプリケーション全体のセキュリティ・ライフサイクルの概要は、『Oracle Fusion Middlewareセキュリティ概要』を参照してください。

デプロイ時におけるOracle ADF アプリケーションの保護の詳細は、『Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド』を参照してください。

アプリケーションのライフ・サイクルの詳細は、第19.4項「付録: ADFアプリケーションのセキュリティ・ライフ・サイクル」を参照してください。

web.xmlやweblogic-application.xmlなど、アプリケーションのセキュリティ管理と構成に関連してEARファイルに含まれているファイルの詳細は、第21章「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、WebSphere Application Server Administrator Console、WebSphere Application Server WASAdminコマンド。推奨するツールはOracle WebLogic管理コンソールです。

Oracle ADFアプリケーション

Fusion Middleware ControlまたはOPSSスクリプト。推奨ツールは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ファイルにパッケージ化される)の移行に関連するものです。次では、これらの設定について説明します。

「アプリケーション・ポリシー移行」の設定

これらの設定では、次のシナリオでポリシーの移行を制御します。

- アプリケーションを初めてデプロイする場合、通常はポリシー・ストアにアプリケーション・ポリシーを移行します。そのためには、「アプリケーション・ポリシー移行」領域で「追加」を選択します。
なんらかの理由で移行しない場合は「無視」を選択します。オプションの「上書き」も使用できます。

- 以前のデプロイでアプリケーション・ポリシーを移行済であることを前提としてアプリケーションを再デプロイしている場合、パッケージ化したポリシーをドメイン内の既存のポリシーにマージするには「追加」を選択し、ポリシーを移行しないようにするには「無視」を選択します。
アプリケーションを再デプロイするときに、ドメインに設定した現在のアプリケーション・ポリシーを変更しない場合、つまり以前のデプロイの際に変更したポリシー・ストアの内容を保持する場合は、「無視」を選択します。

- 「追加」を選択すると、移行する権限とロールを指定できます。基本的な相違点は、ADFアプリケーションのロールと権限(本番環境で必要)と開発時のみのロールと権限(本番環境では不要)との差です。
ADFアプリケーションのロールと権限を移行して、開発時のみのセキュリティ・ロールと権限を移行しないようにするには、次のチェック・ボックスを選択します: アプリケーション・ロールおよび権限のみを移行します。アイデンティティ・ストア・アーティファクトは無視します。通常、本番環境へのデプロイ時には、このチェック・ボックスを選択します。このボックスを選択した場合は、アプリケーションをデプロイした後でそのアプリケーション・ロールをエンタープライズ・グループにマップする必要があります。

- 「追加」を選択した場合に、アプリケーション・ポリシーの移行先とする特定のストライプ(アプリケーション名を名前としたデフォルトのストライプとは異なるストライプ)を指定するには、「アプリケーション・ストライプID」ボックスにそのストライプの名前を入力します。

アプリケーション・ストライプについて:

ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル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管理者ガイド』のOracle ADFのデプロイおよびアンデプロイに関する項を参照してください。

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

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

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

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

デプロイ時に使用できるセキュリティ・オプションは、「Fusion Middleware Controlを使用したJava EEアプリケーションとOracle ADFアプリケーションのデプロイ」を参照してください。

Fusion Middleware Controlを使用してOracle ADFアプリケーションをテスト環境にデプロイするときには次の手順が発生します。

ポリシー管理

- アプリケーションとパッケージ化されたアプリケーション固有のポリシーは、アプリケーションのデプロイ時に資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。

注意:

ファイルベースのポリシー・ストア(つまり、jazn-data.xmlファイル)を本番環境に移行する前に、すべての権限に重複したパーミッションが含まれていないことを確認します。権限でパーミッションが重複している(パーミッションの名前とクラスが同じ)場合は、移行でエラーが発生し、処理が停止します。この場合、手動でjazn-data.xmlファイルを編集して、権限の定義から重複しているパーミッションをすべて削除した後、再度移行を起動します。

資格証明管理

- アプリケーションとパッケージ化されたアプリケーション固有の資格証明は、アプリケーションのデプロイ時に資格証明ストアに自動的に移行されます。
Oracle JDeveloperでは、この移行を実行するために必要な構成が自動的に書き込まれます。

- 移行中にLDAPリポジトリにアクセスするために必要なブートストラップ資格証明は、Fusion Middleware Controlによって自動的に生成されます。手動設定の詳細は、第21.4.7項「ブートストラップ資格証明の手動による指定」を参照してください。

アイデンティティ管理

アプリケーションとパッケージ化されたアイデンティティは移行されません。ドメイン管理者はドメイン認証プロバイダを構成し(管理コンソールを使用)、必要に応じて、環境にあるアイデンティティ(エンタープライズ・ユーザーおよびグループ)を更新して、エンタープライズ・ユーザーおよびグループにアプリケーション・ロールをマップする(Fusion Middleware Controlを使用)必要があります。

その他の考慮事項

- LDAPベースのセキュリティ・ストアを持つドメインにデプロイする場合は、アプリケーションのデータの整合性を保持するために、アプリケーションをクラスタ・レベルでデプロイするか、1つの管理対象サーバーにのみデプロイすることをお薦めします。

- アプリケーションを複数の管理対象サーバーにデプロイするときは、管理サーバーを含めてデータが予期したとおりに移行されるようにしてください。

- ドメイン・ストアの再関連付けは頻繁に行う操作ではなく、通常は、アプリケーションをデプロイする前のドメインを設定するときに行います。手順の詳細は、第8.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。

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

テスト環境へのアプリケーションのデプロイ後、管理者はFusion Middleware Controlまたは管理コンソールを使用していつでも次のタスクを実行できます。

- エンタープライズ・グループへのアプリケーション・ロールのマップ。このマッピングが完了するまで、セキュリティは予期したとおりに動作しません。手順の詳細は、第9.2.2項「アプリケーション・ロールの管理」を参照してください。

- 新しいアプリケーション・ロールの作成または既存のアプリケーション・ロールのカスタマイズ。詳細は、第9.2.2項「アプリケーション・ロールの管理」を参照してください。

- システム・ポリシーの管理。手順の詳細は、第9.2.3項「システム・ポリシーの管理」を参照してください。

- 資格証明の管理。手順の詳細は、第10.3項「資格証明ストアの管理」を参照してください。

注意:

Fusion Middleware Controlを使用して、本番モードで実行しているサーバーからアプリケーションをアンデプロイすると、そのアプリケーション固有のポリシーがポリシー・ストアから自動的に削除されます。また、他のツールを使用してアプリケーションをアンデプロイする場合は、そのアプリケーション固有のポリシーを手動で削除する必要があります。

資格証明は、アプリケーションをアンデプロイしても削除できません。資格証明は、アプリケーションとパッケージ化することで有効になりますが、アプリケーションをアンデプロイしても資格証明は削除されません。

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

OPSSを使用せずにJavaの標準認可を使用するJava EEアプリケーションを保護するには、管理コンソールまたはOPSSスクリプトを使用して管理面で保護する方法と、デプロイメント・ディスクリプタを使用してプログラムで保護する方法の2通りがあります。

Oracle WebLogic ServerにデプロイしたJava EEアプリケーションは、WebLogicリソースとなります。したがって、管理者は、他のリソースの場合と同じ方法で、デプロイされたアプリケーションにセキュリティを設定できます。

デプロイ手順の詳細は、『Oracle Fusion Middleware管理者ガイド』のJava EEアプリケーションのデプロイおよびアンデプロイに関する項を参照してください。

WLSTコマンドを使用したアプリケーションのデプロイの詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のデプロイ・コマンドに関する項を参照してください。

WebLogic Serverのデプロイ機能の概要は、『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』の「WebLogic Serverのデプロイについて」の章を参照してください。

関連ドキュメント

アプリケーション・リソースの保護の詳細は、次のドキュメントに記載されています。

Oracle Fusion Middleware Oracle WebLogic Serverのロールとポリシーを使用したリソースの保護の次の各項

- アプリケーションのリソースに関する項

- WebアプリケーションおよびEJBリソースの保護のオプションに関する項

Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・ヘルプの次の項

- ロールとポリシーの使用したリソースの保護に関する項

『Oracle Fusion Middleware Oracle WebLogic Server WebLogic Webサービスの保護』の次の項

- Webサービス・セキュリティの概要に関する項

『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』の次の各項

- Webアプリケーションの保護に関する項特に、Webアプリケーションでの宣言セキュリティの使用に関する項

- Enterprise JavaBeans (EJBs)の保護に関する項

- Javaセキュリティを使用したWebLogicリソースの保護に関する項

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

次の推奨事項は、JAAS認可を使用するJava EEアプリケーションにのみ当てはまります。このようなアプリケーションには、Oracle Application Development Frameworkアプリケーション、Oracle SOAアプリケーション、Oracle WebCenterアプリケーションなどがあります。標準認可を使用するJava EEアプリケーションは、この推奨事項の対象外です。標準認可を使用するJava EEアプリケーションのデプロイは、「標準Java EEアプリケーションのデプロイ」を参照してください。

アプリケーションをデプロイするための推奨ツールはFusion Middleware Controlです。後述の項で説明する操作を実行するユーザーは、LDAPリポジトリでスキーマをシードする権限など、適切な権限を持っている必要があります。

第5.2.1項「新しい本番環境の設定」の説明に従って本番環境が設定されていることを前提とします。

重要事項:

本番環境ではファイルベース・ストアは推奨されません。

新しい本番環境への移行は、ポリシー・プロバイダおよび資格証明プロバイダ以外のプロバイダの移行、ポリシー・プロバイダおよび資格証明プロバイダの移行、監査ポリシーの移行という3段階に分かれています。それぞれの段階の詳細は次の各項を参照してください。

- ポリシー・プロバイダおよび資格証明プロバイダ以外のプロバイダの移行

- デプロイ時のポリシーおよび資格証明の移行

- 監査ポリシーの移行

- キーストア・サービスのキーおよび証明書の移行

移行はセキュリティ・データのバックアップおよびリカバリに使用できます。セキュリティ・データをバックアップするには、XMLベース・ストアに移行します。セキュリティ・データをリカバリするには、保存済のXMLベース・ストアからターゲットのセキュリティ・ストアに移行します。

6.5.1 ポリシー・プロバイダおよび資格証明プロバイダ以外のプロバイダの移行

本番環境でのプロバイダ(ポリシー・プロバイダおよび資格証明プロバイダ以外)の構成は、テスト環境で使用した構成と同じものとする必要があります。この場合のタスクとして、次のものが考えられます。

- アイデンティティ・ストアの構成(WebLogic管理コンソールやOPSSスクリプトconfigureIdentityStoreを使用して必要なユーザーやグループのプロビジョンを行う場合など)。この最後のコマンドの詳細は、「アイデンティティの手動による移行」を参照してください。

- テスト環境で実行したあらゆる特定のプロバイダの構成

注意:

Oracle WebLogic Serverには、packおよびunpackコマンドなど、ドメインの作成を容易にするためのツールがいくつか用意されています。詳細は、『Oracle Fusion Middleware PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

6.5.1.1 アイデンティティの手動による移行

アイデンティティ・データは、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。この移行が必要になる状況の例として、ファイルベースのアイデンティティ・ストアを使用するテスト環境からLDAPベースのアイデンティティ・ストアを使用する本番環境に移行する場合があります。

このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。

このコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。

スクリプト・モードおよびインタラクティブ・モードの構文

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"])

WebSphereへのアイデンティティの移行は、同じスクリプトを使用して行います。詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

引数(dstLdifFile以外はすべて必須)の意味は次のとおりです。

- configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。

- srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。

- dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。移行先ストアは、LDAPベースのアイデンティティ・ストアにする必要があります。サポートされているタイプの一覧は、第3.1.1項「サポートされているLDAPアイデンティティ・ストアのタイプ」を参照してください。

- dstLdifFileでは、作成したLDIFファイルの相対パスまたは絶対パスを指定します。移行先がLDAPベースのOracle Internet Directoryストアである場合にのみ必要です。LDIFファイルはLDAPサーバーにはインポートされません。

srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

LDIFファイルを生成した後、通常は、このファイルを手動で編集して、LDIFファイルの最終的なインポート先となるLDAPリポジトリの属性をカスタマイズします。

6.5.2 デプロイ時のポリシーおよび資格証明の移行

本番環境では、OPSSセキュリティ・ストア(ポリシー、資格証明、およびキー・ストア)LDAPベースのOracle Internet Directoryに再関連付けすることを強くお薦めします。テスト用のポリシー・ストアおよび資格証明ストアもLDAPであったとしても、本番用のLDAPはテスト用のLDAPとは別のものとすることが前提となっています。テスト用のポリシー・ストアがファイルベースであったとしても、 権限に重複したパーミッションがないことを確認してください。「ポリシー管理」の注意を参照してください。

ストアを再関連付けする方法の詳細は、第8.5.1項「Fusion Middleware Controlを使用した再関連付け」を参照してください。

ポリシーおよび資格証明の移行は、アプリケーションのデプロイ時に自動的に処理できるほか、アプリケーションのデプロイ前またはデプロイ後に手動で実行することもできます。

重要事項:

サーバーの停止と再起動を必要としない、アプリケーションのホット・デプロイを行う場合、セキュリティ・ストアにそのアプリケーションと同じ名前のストライプが含まれていない場合にかぎり、ファイル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にアプリケーション・ポリシーおよびシステム・ポリシーを移行します。「ポリシーの手動による移行」のサンプルを参照してください。

- アプリケーション資格証明の移行で「無視」を選択した場合は、テスト用のLDAPから本番用のLDAPに資格証明を移行します。「資格証明の手動による移行」のサンプルを参照してください。

3. いずれの場合も、必要に応じ、Fusion Middleware Controlを使用してアプリケーション・ロールを本番用のエンタープライズ・グループにマップします。

4. Fusion Middleware Controlを使用して、本番環境の管理資格証明が有効であることを確認します。特に、テスト用のパスワードと本番用のパスワードを照合してください。必要に応じて、本番用のデータを適宜変更します。

注意:

アプリケーションのデプロイでポリシーを移行したときに、GUIDを再作成しなくても元のGUIDが保持されるようにアプリケーションを構成する方法があります。

この設定は、手動でのみ構成できます。詳細は、第21.4.1項「ポリシーの移行を制御するパラメータ」でパラメータjps.approle.preserveguidの説明を参照してください。

6.5.2.1 ポリシーの手動による移行

デフォルトでは、スクリプト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.cred">
<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.cred"/>
</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.5.2.2 資格証明の手動による移行

スクリプト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.cred">
<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.cred"/>
</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.5.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のパッチを適用する必要があります使用しているプラットフォームに対応するパッチをダウンロードするには、My Oracle Support(http://myoraclesupport.oracle.com)にアクセスしてください。

一括コマンドを使用して移行元の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.5.3 監査ポリシーの移行

監査ポリシーを移行するには、次に説明するエクスポート操作とインポート操作を使用します。

まず、次のいずれかのツールを使用して、テスト環境からファイルに監査構成をエクスポートします。

- Fusion Middleware Control: 「ドメイン名」→「セキュリティ」→「監査ポリシー」に移動し、「エクスポート」をクリックします。

- OPSSスクリプトexportAuditConfig。詳細は、付録C「exportAuditConfig」を参照してください。

次に、次のいずれかのツールを使用して、本番環境にファイルをインポートします。

- Fusion Middleware Control: 「ドメイン名」→「セキュリティ」→「監査ポリシー」に移動し、「インポート」をクリックします。

- OPSSスクリプトimportAuditConfig。詳細は、付録C「importAuditConfig」を参照してください。

前述のインポートとエクスポートの操作で移行できるのは監査ポリシーのみです。監査データ・ストアの設定は移行できません。テスト環境で監査データソースを構成していた場合は、本番環境でデータソースを構成する手順を繰り返します。詳細は、第13.2.2項「監査データソースの設定」を参照してください。

通常、テスト環境の監査データ・レコードを本番環境に移行することはありませんが、移行する場合は、データベースのインポート/エクスポート・ユーティリティを使用します。詳細は、第13.5.5項「データのインポートとエクスポート」を参照してください。

6.5.4 キーストア・サービスのキーおよび証明書の移行

migrateSecurityStoreを使用して手動でキーおよび証明書を移行するには、移行元と移行先のサービス・インスタンスを指定する構成ファイルを作成します。次に、この項の末尾にある例に示すように、適切なオプションを指定してmigrateSecurityStoreコマンドを実行します。

次の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.cred">
<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.cred"/>
</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")

第III部

OPSSの高度な管理

このパートでは、次の各章でOPSSの高度な管理機能について説明します。

- 第7章「アイデンティティ・ストア・サービスの構成」

- 第8章「OPSSセキュリティの構成」

- 第9章「ポリシー・ストアの管理」

- 第10章「資格証明ストアの管理」

- 第11章「キーストア・サービスでのキーと証明書の管理」

- 第12章「Oracle Fusion Middleware監査フレームワークの概要」

- 第13章「監査の構成と管理」

- 第14章「監査分析と監査レポートの使用」

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

この章では、OPSSでアイデンティティ・ストア・サービスを使用する方法について説明します。この章の内容は次のとおりです。

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

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

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

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

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

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

この項では、OPSSアイデンティティ・ストア・サービスにおける次の主要概念について説明します。

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

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

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

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

アデンティティ・ストア・サービスを使用すると、アデンティティ・ストアにユーザーおよびロール(グループ)の情報を問い合せることができます。

デフォルトでは、サービス・インスタンスは、単一のLDAPアイデンティティ・ストアへの問合せをサポートしています。複数のLDAPアイデンティティ・ストアに問合せを行う仮想アイデンティティ・ストアをサポートするようにサービスを構成できます。ID仮想化として知られているこの機能については、第7.3項「アイデンティティ・ストア・サービスの構成」を参照してください。

7.1.2 サービス・アーキテクチャ

図7-1は、アイデンティティ・ストア・サービスのアーキテクチャを示しています。構成に応じて、サービスではアイデンティティ・ストアとして、XMLファイルまたは1つ以上のLDAPサーバーをサポートできます。

LDAP用にサービスを構成すると、デフォルトでは、単一のLDAPストアに問合せが行われます。複数のLDAPストアに問い合せるように、サービスを構成することもできます。

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

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

アイデンティティ・ストア・サービスは、次のサーバーをサポートしています。

- Oracle WebLogic Server

- サード・パーティのアプリケーション・サーバー

サービスの構成内容は、アプリケーション・サーバーによって異なるため、そのサービスをサポートするプロバイダを指定する必要があります。

7.1.4 Java SEのサポート

アイデンティティ・ストア・サービスは、スタンドアロンのJava SE環境で使用できます。

詳細は、第7.3.6項「Java SE環境」を参照してください。

7.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>

詳細は、第8.7.1項「アイデンティティ・ストア・プロバイダの構成」を参照してください。

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

この項では、アイデンティティ・ストア・サービスをLDAPベースのストアに構成する方法について説明します。この項の内容は次のとおりです。

- 構成内容

- WebLogic Serverの構成

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

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

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

- Java SE環境

関連項目:

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

7.3.1 構成内容

この項では、アイデンティティ・ストア・サービスの各種構成パラメータについて説明します。内容は次のとおりです。

- 複数のLDAP検索の構成

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

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

7.3.1.1 複数のLDAP検索の構成

複数のLDAP問合せ用にサービスを構成するには、次のパラメータを使用します。

- virtualizeプロパティ - このプロパティには、true (複数のLDAP検索)またはfalse (単一のLDAP検索)を設定できます。デフォルトはfalseです。

- グローバル接続パラメータ(virtualizeが有効の場合) - アプリケーションの呼び出す際に、これらのパラメータを使用して、グローバルLDAP構成(ベースの検索、ベースの作成など)を指定します。これらのパラメータのいずれかが構成されていない場合、OPSSはデフォルト値を使用します。

- バックエンド接続パラメータ - このパラメータは各LDAPストアに固有のものです。各LDAPに対して1セットのバックエンド・パラメータが指定されます。既存の値を上書きしないかぎり、このパラメータを設定する必要はありません。

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

表7-1は、グローバル・パラメータとそのデフォルト値(該当する場合)を示しています。

表7-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の汎用的なプロパティ」

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

前述のように、このパラメータはバックエンドLDAPストアに固有のものです。詳細は、次を参照してください:

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

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

7.3.2 WebLogic Serverにおける構成

Oracle WebLogic Serverでは、LDAP認証プロバイダは、WebLogicコンソールまたはWLSTコマンドラインを使用して構成します。実行時にOracle WebLogic Serverによって構成の詳細がOPSSに渡されます。Oracle WebLogic Serverでは、特定のコンテキストで複数の認証プロバイダを構成することができます。また、アイデンティティ・ストア・サービスを初期化する際に、デフォルトでは、最初の認証プロバイダが選択されます。このプロセスについては、第3.1.2.2項「LDAPアイデンティティ・ストア・サービスの構成」を参照してください。

認証プロバイダを構成した後で、アイデンティティ・ストア・サービスを設定して、1つのLDAPアイデンティティ・ストアまたは複数のストアに問い合せることができます。複数のストアを構成するにはvirtualizeプロパティを設定する必要があります。

この項では、これらのオプションの設定方法について説明します。

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

アイデンティティ・ストア・サービスを構成して、問合せ可能なLDAPストアは1つだけです。単一のLDAPサービス・インスタンスを使用する場合のjps-config.xmlファイルの断片を示す例7-1を参照してください。

7.3.2.2 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」をクリックします。

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

WLSTを使用してvirtualizeプロパティを構成するには、次の手順を実行します。

1. 対象ドメインの管理サーバーに接続するためのpyスクリプト・ファイルを作成します。この操作をするには、userName、userPass、localHost、およびportNumberを指定する必要があります。
このスクリプトの詳細は、付録E「WLSTスクリプトを使用した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項「WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」

7.3.2.4 その他のパラメータの構成

必要に応じて、jps-config.xmlを更新して、第7.3.1項「構成内容」に記載されている問合せパラメータを設定できます。これらのパラメータはオプションです。デフォルト値が指定されています。

7.3.2.5 サーバーの再起動

複数のLDAP問合せを構成したら、Weblogic管理サーバーおよび管理対象サーバーを再起動します。

7.3.2.6 構成ファイルの例

例7-1に、単一のLDAP問合せ用にOracle WebLogic Server環境に構成されたjps-config.xmlのサンプル・ファイルを示します。

例7-1 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>

例7-2に、複数のLDAP問合せ用にOracle WebLogic Server環境に構成されたjps-config.xmlのサンプル・ファイルを示します。

例7-2 Oracle WebLogic Serverにおける複数のLDAP構成

<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 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=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.create.bases</name>
<values>
<value>cn=groups_front,dc=us,dc=oracle,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要素を使用することにより、フロントエンド・パラメータを設定できます。
詳細は、第7.3.1項「構成内容」の「フロントエンド・パラメータ」を参照してください。

7.3.3 分割プロファイルの構成

ID仮想化では「分割プロファイル」がサポートされています。分割プロファイルでは、2つの異なるソースに格納されている単一IDの属性をアプリケーションが使用します。

この機能には、この章で説明している構成以外に追加構成が必要です。詳細は、付録K「ID仮想化のためのアダプタ構成」を参照してください。

7.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プロバイダ・インスタンスもオーバーライドする必要がある場合は、ファイルに同様のエントリを追加します。

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

この項のトピックは次のとおりです:

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

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

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

詳細は、第22.2.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」の例を参照してください。

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

サード・パーティのアプリケーション・サーバーにある複数のLDAPに対応するアイデンティティ・ストア・サービスを構成する手順は、次のとおりです。

1. jps-config.xmlファイルを変更して、LDAP対応のディレクトリごとにサービスのインスタンスを構成します。

2. アプリケーション・サーバーを再起動して、変更を有効にします。

例7-3に、サード・パーティのアプリケーション・サーバーに複数のLDAP問合せを実行するように構成されたjps-config.xmlファイルのサンプルを示します。

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

<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 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=oracle,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://oid1.us.oracle.com:389,ldap://oid2.us.oracle.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>
<extendedProperty>
<name>username.attr</name>
<values>
<value>uid</value>
</values>
</extendedProperty>
<extendedProperty>
<name>groupname.attr</name>
<values>
<value>cn</value>
</values>
</extendedProperty>
</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=oracle,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://msad1.us.oracle.com:389,ldap://msad2.us.oracle.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>
<extendedProperty>
<name>username.attr</name>
<values>
<value>cn</value>
</values>
</extendedProperty>
<extendedProperty>
<name>groupname.attr</name>
<values>
<value>cn</value>
</values>
</extendedProperty>
</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=oracle,dc=com</value>
</values>
</extendedProperty>
<extendedProperty>
<name>group.create.bases</name>
<values>
<value>cn=groups_front,dc=us,dc=oracle,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要素を使用することにより、フロントエンド・パラメータを設定できます。
詳細は、第7.3.1項「構成内容」の「フロントエンド・パラメータ」を参照してください。

7.3.6 Java SE環境

Java SE環境では、次のようにjps-config.xmlファイルを直接変更します。

1. 新しいアイデンティティ・ストアのサービス・インスタンスを定義します。

2. 新しいサービス・インスタンスをJPSコンテキストに追加して、事前に定義されているアイデンティティ・ストア・インスタンスをすべて置き換えます。

3. アイデンティティ・ストア・サービスのvirtualizeフラグを有効にするには、例7-3を参照してください。

詳細は、第22.2.2項「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」を参照してください。

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

プログラム上でLDAPアイデンティティ・ストアに問い合せるには、OPSSを使用してJPSコンテキストを取得します(これは、ストア・インスタンスを取得するブリッジのように機能します)。続いて、ユーザーおよびロールAPIを使用して、ストアに問い合せます。

例7-4 プログラムによる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」プロパティを有効にする方法を確認するには、例7-3を参照してください。

MBeansの使用方法の詳細は、第E.2項「MBeanを使用したOPSSサービスの構成」を参照してください。

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

アイデンティティ・ストアとLDAPサーバー間の接続に対してSSLを有効にできます。この項では、様々なシナリオで接続を構成する方法について説明します。

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

- 複数のLDAPシナリオでの一方向SSL

- 複数のLDAPシナリオでの双方向SSL

- 単一のLDAPシナリオの接続

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

アイデンティティ・ストアへの接続がOracle WebLogic Server上のクライアントから始まる場合、SSLの構成はOracle WebLogic Serverで行います。詳細は、第8.2.3項を参照してください。

7.5.2 複数のLDAPシナリオでの一方向SSL

アイデンティティ・ディレクトリAPIとユーザーおよびロールAPIのどちらも、複数のLDAPアイデンティティ・ストア構成(virtualize = true)で動作できます。

このシナリオでは、アイデンティティ・ストアからLDAPサーバーへの接続に対してSSLを有効にできます。

手順は次のとおりです。

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を再起動します。

7.5.3 複数のLDAPシナリオでの双方向SSL

複数のLDAPアイデンティティ・ストア構成に双方向SSLを実装するには、次の手順を実行します。

1. 第7.5.2項の手順を実行します。

2. 第7.5.2項のステップ1で作成したキーストアで、CAによって署名された新しいキー・ペアを生成します。

3. この証明書をファイルにエクスポートします。

4. 証明書をサーバーのキーストアにインポートします。

7.5.4 単一のLDAPシナリオの接続

アイデンティティ・ディレクトリAPIとユーザーおよびロールAPIのどちらも、単一のLDAPアイデンティティ・ストア構成(virtualize = false)で動作できます。

このシナリオでは、アイデンティティ・ストアとLDAPサーバー間のSSLは、第7.5.2項に示した基本的な手順を使用して構成します。ただし、libovdconfig.shを使用してキーストアを作成する必要はありません。かわりに、信頼できる証明書をアプリケーション・サーバーのトラスト・ストアにインポートする必要があります。

例:

keytool -import -v -trustcacerts -alias mytrust -file oidServerTrust.cert -keystore myTrustStore.jks -storepass trustStorePassword

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

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。ポリシー、資格証明、キーおよび証明書の概要は、次の各項を参照してください。

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

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

- 第3.4項「キーストア・サービスの基本」

この章では、ポリシー、資格証明およびキーに共通のOPSSセキュリティ・ストアの機能について説明します。この章の内容は次のとおりです。

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

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

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

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

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

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

- アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成

Java EEおよびWebLogicのセキュリティの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティの理解』のJava EEおよびWebLogicのセキュリティに関する項を参照してください。

注意:

この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用できなくなります。

重要:

OPSSセキュリティ・ストアのポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。

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

OPSSセキュリティ・ストアは、システムやアプリケーションに固有のポリシー、証明資格、およびキーに関するリポジトリです。この集中化により、ポリシー、資格証明、およびキーに関するデータの管理と保守が容易になります。

OPSSセキュリティ・ストアは、選択したリポジトリ・タイプに応じてファイルベース、LDAPベース、またはDBベースにすることができます。また、ファイルベースからLDAPまたはDBベース、DBベースからLDAPまたはDBベース、LDAPベースからLDAPまたはDBベースに再関連付けができます(つまり、リポジトリ・タイプは変更可能ということです)。これ以外の再関連付けはサポートされていません。OPSSセキュリティ・ストアの再関連付けに使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した再関連付けおよびスクリプトreassociateSecurityStoreを使用した再関連付けの項を参照してください。追加設定なしですぐに使用できるOPSSセキュリティ・ストアはファイルベースです。

Java EEアプリケーションに関するセキュリティ・データは、通常、アプリケーションとともにパッケージされているため、デプロイ時にOPSSセキュリティ・ストアに移行できます。OPSSセキュリティ・ストアへの移行に使用可能なツールや手順の詳細は、Fusion Middleware Controlを使用した移行およびスクリプトmigrateSecurityStoreを使用した移行の項を参照してください。

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

LDAPベースのポリシー・ストアは、通常、本番環境で使用します。今回のリリースでサポートされている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.0の場合は、Bug 8426457を修正するパッチを適用します。

- Oracle Internet Directory 10.1.4.3.0の場合は、Bug 8351672を修正するパッチを適用します。

パッチを適用するには、次のようにします。

1. Oracle自動リリース更新にアクセスします。

2. 「パッチ」タブをクリックします。

3. 「リクエスト番号」ボックスにバグ番号を入力して、「検索」をクリックします。

4. パッチを適用します。

ドメインでLDAPベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。

重要:

OPSSは、Oracle Internet Directoryサーバーでの参照整合性の有効化をサポートしていません。参照整合性を有効化した場合、サーバーは想定したとおりには機能しません。

サーバーの参照整合性を無効にするには、Oracle Enterprise Manager Fusion Middleware Controlを使用して、次のようにします。

1. 「管理」を選択してから、「Oracle Internet Directory」メニューの「共有プロパティ」を選択し、「一般」を選択します。

2. 参照整合性の有効化一覧で、「無効」を選択します。

サービス・インスタンスで指定可能なプロパティの一覧は、付録F「LDAPベースのすべてのインスタンスに共通するプロパティ」を参照してください。

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

- 複数ノード・サーバー環境

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

8.2.1 複数ノード・サーバー環境

複数のマシンに複数のサーバー・インスタンスが分散されているドメインでは、OPSSセキュリティ・ストアをLDAPベースまたはDBベースにすることを強くお薦めします。

通常、アプリケーションによってポリシー、資格証明、またはキーのデータが変更されることはありません。そのような変更が発生した場合は、それらの変更がドメインにあるすべての管理対象サーバーとクラスタに適切に伝播されることが重要です。したがって、このような変更は、管理対象サーバーではなく、ドメイン管理サーバーで実行することを強くお薦めします。

単一ノード・サーバー・ドメインの場合は、セキュリティ・データのローカル変更の伝播を考慮する必要はありません。このシナリオでは、ローカル変更はグローバル変更と同じです。

ただし、複数ノード・サーバー・ドメインでは、ファイルベースのポリシーに対するローカル変更は、JMXフレームワークによってそれぞれのランタイム環境に伝播されるため、キャッシュ・ポリシーと構成に基づいてデータが更新されます。ポリシーおよび資格証明に設定可能なプロパティの詳細は、付録F「ポリシー・ストアのプロパティ」および付録F「資格証明ストアのプロパティ」を参照してください。

複数ノードのサーバー環境では、ポリシー・ストアおよび資格証明ストアの両方をLDAPベースまたはDBベースのストアで集中管理し、管理サーバーで構成することを強くお薦めします。

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

LDAPベースのOPSSセキュリティ・ストアでサポートされているのは、Oracle Internet Directoryのみです。Oracle Internet Directoryに正しくアクセスできるようにするには、後述する手順で、ノードをサーバー・ディレクトリに設定する必要があります。

Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。これらの必要な資格証明を手動で指定する場合は、第21.4.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セキュリティ・ストアの再関連付け」を参照してください。

8.2.3 LDAPへの一方向SSL接続の設定

この項では、Oracle WebLogic ServerまたはJava SEアプリケーションと、LDAP Oracle Internet Directory間で一方向SSLチャネルを設定する方法を説明します。このような接続は、たとえばLDAPベースのターゲット・ストアへの再関連付けを行う場合に必要になります。

前提条件: Oracle Internet Directoryサーバーの構成

一方向SSLモードでリスニングするようにOracle Internet Directoryサーバーを構成する方法は、『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の設定

アイデンティティ・ストア・サービスとポリシー・ストア・サービスでは、使用するソケット・ファクトリが異なるため、次の手順も異なります。

サーバーとアイデンティティ・ストア間で一方向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>

サーバーとポリシー・ストア間で一方向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アプリケーションの場合、アイデンティティ・ストア・サービスとポリシー・ストア・サービスの設定は同じです。

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>

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

DBベースのセキュリティ・ストアは、通常、本番環境で使用します。サポートされているDBベースのセキュリティ・ストアは、Oracle RDBMS (リリース10.2.0.4以降、リリース11.1.0.7以降、およびリリース11.2.0.1以降)のみです。

DBベースのOPSSセキュリティ・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはOPSSスクリプトを使用し、その資格証明ストアを構成する必要があります。サーバーが初期化を完了する前になんらかのチェックが必要な場合は、第L.14項「サーバー起動前のパーミッション・チェックの失敗」を参照してください。

構成可能なプロパティの一覧は、付録F「OPSS構成プロパティ」を参照してください。

この項には次のトピックが含まれます:

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

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

- DBへのSSL接続の設定

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

OPSSセキュリティ・ストアにデータベース・リポジトリを使用するには、まずOracle Fusion Middleware Repository Creation Utility (RCU)を使用して必要なスキーマを作成し、一部の初期データをシードする必要があります。この設定は、OPSSセキュリティ・ストアをDBベースのセキュリティ・ストアに再関連付けする前にも必要です。

RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』の「リポジトリ作成ユーティリティの概要」および「リポジトリ作成ユーティリティの実行」の章を参照してください。

スキーマの作成および初期データのシードについては、次の各項で説明します。

- OracleデータベースでのOPSSスキーマの作成

- OracleデータベースでのOPSSスキーマの削除

- データソース・インスタンスの作成

8.3.1.1 OracleデータベースでのOPSSスキーマの作成

RCUを使用して、OracleデータベースにOPSSスキーマを作成する手順は、次のとおりです。

1. RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの作成」ページを表示します。

2. そのページで「作成」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。

3. そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。
続いて、「次へ」をクリックすると、入力したデータがチェックされ、作成前の操作が実行されます。このチェックが正常に終了すると、「コンポーネントの選択」ダイアログが表示されます。

4. そのダイアログで、既存スキーマの接頭辞を使用するか、新規の接頭辞を作成するかを選択して、スキーマにインストールするOPSSコンポーネントを選択します。
コンポーネントを選択したら、「次へ」をクリックして、「スキーマ・パスワード」ダイアログを表示します。ダイアログでパスワードを入力したら、「次へ」をクリックして、「表領域のマップ」ダイアログを表示します。このダイアログには表領域のサマリーが表示されます。デフォルト表領域を1つと一時表領域を1つ使用します。デフォルトの表領域名は、それぞれPREFIX_IAS_OPSSおよびPREFIX_IAS_TEMPです。

デフォルト以外の表領域またはデータファイルを作成する場合は、「表領域の管理」ボタンをクリックして、「表領域の管理」ダイアログを表示します。表示されたダイアログで、表領域またはデータファイルを作成するための情報を入力します。入力が終了したら、「OK」をクリックします。入力した表領域がデータベースにまだ存在しない場合は、その表領域が作成され、その内容が、表領域の作成中に表示されます。「OK」をクリックすると、「サマリー」ダイアログに、入力したデータのサマリーが表示されます。続いて、「作成」をクリックして、追加の表領域またはデータファイルの作成を有効にします。

5. 作成が完了すると、「完了サマリー」に、データベースの詳細が表示されます。

6. 次に示すようにSQLPlusコマンドを呼び出して、データベース・スキーマが適切に作成されていることを確認します。

SQL> desc jps_dn;

8.3.1.2 OracleデータベースでのOPSSスキーマの削除

OPSSスキーマの削除は、OPSSセキュリティ・ポリシーの格納用としてそのDBを使用しなくなった場合にのみ必要です。

OPSSスキーマが正常に作成された後で、RCUを使用して、次のようにOPSSスキーマを削除します。

1. RCUを起動して、RCUの「ようこそ」ページを表示します。このページで、「次へ」をクリックして、「リポジトリの削除」ページを表示します。

2. そのページで「削除」ラジオ・ボタンを選択し、「次へ」をクリックして、「データベース接続の詳細」ページを表示します。

3. そのページで 「データベース・タイプ」、「ホスト名」、「ポート」、「サービス名」、「ユーザー名」、「パスワード」、および「ロール」に適切な接続情報を入力します。続いて、「次へ」をクリックして、「コンポーネントの選択」ダイアログを表示します。

4. そのダイアログで、接頭辞を選択し、「コンポーネント」階層で、「AS共通スキーマ」および「Oracle Platform Security Services」を選択します。「次へ」をクリックして「サマリー」ページを表示します。

5. そのページで、収集された詳細情報が正しいことを確認し、「削除」をクリックして削除処理を起動します。正常に処理が完了すると、「完了サマリー」ページに、削除されたスキーマの詳細情報が表示されます。

8.3.1.3 データソース・インスタンスの作成

Oracle WebLogic管理コンソールを使用してWebLogicドメイン内にJDBCデータソースを作成するには、次の手順を実行します。

1. コンソールにログインし、「サービス」→「データソース」に移動して、「新規」→「汎用データソース」を選択します。

2. 「JNDI名」を入力し、「次へ」をクリックします。この名前は、jps-config.xmlファイルでのDBベース・ストアの構成に使用することに注意してください。

3. 「データベース・ドライバ」プルダウンで、「Oracleのインスタンス接続用ドライバ(Thin)、バージョン:9.0.1以降」(これは非XA JDBCドライバです)を選択し、「次へ」をクリックします。

4. 「グローバル・トランザクションのサポート」の選択が解除されていることを確認し、「次へ」をクリックします。

5. 「接続プロパティ」領域で、「データベース名」、「ホスト名」、「ポート」、「データベース・ユーザー名」および「パスワード」にデータを入力します。「次へ」をクリックします。

6. 設定を検証してテストし、問題がなければ「終了」をクリックします。

7. 作成したデータソースを適切なサーバーにデプロイします。

前述の手順の詳細は、Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理のJDBCデータソースの作成に関する項を参照してください。

WebSphere Application Serverでデータソースを設定するには、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

注意:

11.2のOracle JDBCドライバでは、Etc/UCT、UCT、Etc/UTC、Etc/Universal、Etc/ZuluおよびUniversalのタイムゾーンは非推奨です 。Oracle JDBCドライバのタイムゾーンを設定したら、そのタイムゾーンが、非推奨ではないことを確認してください。

8.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の設定時(「OracleデータベースでのOPSSスキーマの作成」の項を参照)に作成された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);

8.3.3 DBへのSSL接続の設定

DBベースのOPSSセキュリティ・ストアへの一方向または双方向SSL接続の確立はオプションであり、詳細は『Oracle Fusion Middleware管理者ガイド』のデータベースでのSSLの構成に関する項を参照してください。

SSL関連のトピックの補足情報は、次のドキュメントを参照してください。

- Oracle JDBC Thin Driverを使用したSSL: http://www.oracle.com/technology/tech/java/sqlj_jdbc/pdf/wp-oracle-jdbc_thin_ssl_2007.pdf.

- Oracle Database JDBC開発者ガイド

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

Java SEアプリケーション用のストア構成の例は、第23.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。

Java EEアプリケーション用のストア構成の例は、例1および例4を参照してください。

その他のアーティファクトの構成に関する詳細は、「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。

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

OPSSセキュリティ・ストアの再関連付けとは、ポリシー 、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。LDAPタイプのターゲットでは、Oracle Internet Directoryのみサポートされています。DBタイプのターゲットでは、DB_ORACLEのみサポートされています。

再関連付けでは、格納データの整合性を維持しながらリポジトリが変更されます。再関連付けでは、各セキュリティ・アーティファクトに対して、ターゲット・ストアを検索し、一致するストアが見つかった場合は、一致するアーティファクトが更新され、見つからない場合は、新しいアーティファクトが作成されます。

再関連付けを実行する代表的な例として、すぐに使用可能なファイルベース・ストアのかわりに、LDAPベースまたはDBベースのOPSSストアをドメインで使用するように設定する場合があります。この操作は、OPSSストアの構成およびインスタンス化の後であればいつでも行うことができます。また、この操作は、次の項で説明されているように、Fusion Middleware ControlまたはreassociateSecurityStoreのいずれかを使用して実行します。

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

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

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

再関連付けでは、OPSSポリシー・ストア(ポリシー、資格証明、およびキー)をリポジトリ間で移行し、適切なセキュリティ・ストア・プロバイダを構成します。この項では、Fusion Middleware Controlのページを使用して再関連付けを行う方法を説明します。

「セキュリティ・プロバイダ構成」ページのその他の使用方法については、「アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成」を参照してください。

重要ポイント

- ターゲットのLDAPストアに再関連付けを行う前に、「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。

- ターゲットのDBストアに再関連付けを行う前に、「DBベースのセキュリティ・ストアを使用する場合の前提条件」を満たすように設定されていることを確認してください。

- 再関連付けでターゲットLDAPへの一方向SSLが必要な場合は、再関連付けを行う前に、「LDAPへの一方向SSL接続の設定」の手順を実行してください。

- LDAPストアへの再関連付けの後、Oracle Internet Directoryストアのルート・ノードへのアクセスを保護するために、「Oracle Internet Directoryノードへのアクセスの保護」で説明する手順を実行してください。

- 再関連付けで生成されたjps-config.xmlファイルは、Java EEアプリケーションにのみ適しています。Java SEアプリケーションの場合は、第23.1.3項「DBベースのOPSSセキュリティ・ストアの構成」に記載されている構成と一致するようにjps-config-jse.xmlファイルを編集してください。

Fusion Middleware Controlを使用してOPSSセキュリティ・ストアを再関連付けする手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」(Oracle WebLogic Serverに接続している場合)、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」(WebSphere Application Serverに接続している場合)に移動して、「セキュリティ・プロバイダ構成」ページを表示します(次の図にページの一部を示します)。

「セキュリティ・ストア」領域の表には、現在ドメインで構成されているプロバイダの特性が表示されます。

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認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第L.9項「匿名SSL接続の確立の失敗」を参照してください。

5. 「ルート・ノードの詳細」領域で、「ルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。
この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第L.2項「再関連付けの失敗」を参照してください。

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サーバーから削除しないでください。

8.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章を参照してください。

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

OPSSストアは、OPSSスクリプトreassociateSecurityStoreを使用して再関連付けできます。詳細は、第9.3.29項「reassociateSecurityStore」を参照してください。

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

1つのドメインに設定できるポリシー・ストアは1つのみです。アプリケーションで独自のポリシーを指定することはできますが、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはそのポリシー・ストアのポリシーとして格納されます。したがって、ドメインにデプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるポリシー・ストアを使用します。ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。

OPSSセキュリティ・ストアの移行とは、ポリシー 、資格証明、およびキー・ストアをリポジトリ間で再配置することです。ソースは、ファイルベース、LDAPベース、またはDBベースにすることができます。ターゲットは、LDAPベースまたはDBベースにすることができます。OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第L.21項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。

アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをOPSSセキュリティ・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。

ポリシー・ストアの構成は、管理者が行います。

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

- Fusion Middleware Controを使用した移行

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

注意:

WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティ jps.deployment.handler.disabledを使用します。

このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイルweblogic-application.xmlにあるアプリケーション個別の設定は無視されます。

8.6.1 Fusion Middleware Controlを使用した移行

アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。

アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。

詳細は、第6.5.2項「デプロイ時のポリシーおよび資格証明の移行」の手順を参照してください。

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

アプリケーション固有のポリシーまたはシステム・ポリシーは、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。

このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。

注意:

スクリプトmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、第6.5.2.3項「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。

OPSSスクリプトとその構文の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドのカテゴリの概要に関する項を参照してください。

OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。

WebLogicのすべてのポリシー(すべてのアプリケーションのシステム・ポリシーとアプリケーション固有のポリシー)を移行するには、次のスクリプト構文(1番目の記述)またはインタラクティブな構文(2番目の記述)を使用します(ここでは、見やすくするために各引数をそれぞれ別の行に記述しています)。

migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext

migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")

引数(すべて必須)の意味は、次のとおりです。

- configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。通常、この構成ファイルはスクリプトで使用するためにのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのjps-contextがあります。
また、1つまたは2つのLDAPベースのストアを移行する場合は、このファイルにcwallet.ssoファイルの場所を参照するブートストラップjps-contextを含める必要があります。このファイルには、移行対象のLDAPベースのストアにアクセスするための資格証明が格納されます。

- 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) ソースおよびターゲットのコンテキスト名が一意。

8.6.2.1 使用例

このスクリプトの使用方法を示す例は、第6.5.2.1項「ポリシーの手動による移行」を参照してください。

8.7 アイデンティティ・プロバイダ、プロパティ・セットおよびSSOの構成

この項では、Fusion Middleware Controlを使用して、ユーザー/ロールAPI、プロパティおよびプロパティ・セットで使用するパラメータを構成し、シングル・サインオン・プロバイダを指定する方法を説明します。この項の内容は次のとおりです。

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

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

- シングル・サインオン・ソリューションの指定

注意:

「セキュリティ・プロバイダ構成」ページの「Web Services Managerの認証プロバイダ」領域は、Web Services Managerのログイン・モジュールとキーストアの構成にのみ関連します。ADFアプリケーションとJava EEアプリケーションには関連しません。

使用可能なログイン・モジュールとそのパラメータ、およびそれらのコンポーネントのキー・ストアの詳細は、『Oracle Fusion Middleware Web Servicesセキュリティおよび管理者ガイド』の第9章を参照してください。

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

アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータを構成する手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

2. 必要に応じて、「アイデンティティ・ストア・プロバイダ」領域を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。

3. 必要に応じて、「追加」ボタンと「削除」ボタンを使用してカスタム・プロパティを管理します。

4. 完了したら、「OK」をクリックして設定を保存し、「セキュリティ・プロバイダ構成」ページに戻ります。

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

プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。

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>要素の直下に挿入されます。

8.7.3 シングル・サインオン・ソリューションの指定

この項では、OPSSシングル・サインオン(SSO)フレームワークを説明し、Fusion Middleware Controlを使用してSSOソリューションを構成する方法を紹介します。この項の内容は、次のとおりです。

- OPSS SSOフレームワーク

- Fusion Middleware Controlを使用したSSOソリューションの構成

- OAM構成の例

8.7.3.1 OPSS SSOフレームワーク

OPSS SSOフレームワークにより、ドメインにあるアプリケーションをSSOソリューションに統合できます。具体的には、複数のSSO製品に共通のAPIセットをアプリケーションに提供することで、ログイン、ログアウトおよび自動ログインを処理します。

これらのソリューションの1つであるOAMソリューションは特別な設定をせずに使用でき、次の機能が用意されています。

- 動的認証: 認証が必要な保護されたアーティファクトの一部にユーザーがアクセスすると、アプリケーションが認証をトリガーし、ユーザーを適切なソリューションで認証できるようにリダイレクトします。

- 自動ログイン: 最初に匿名でアプリケーションにアクセスしたユーザーが、そのアプリケーションにアカウントを登録します。正常に登録されると、そのユーザーは認証のURLにリダイレクトされます。また、プロンプトの表示なしで自動的にログインすることも可能です。

- グローバル・ログアウト: ユーザーが1つのアプリケーションからログアウトすると、ソリューションで有効になっているあらゆるアプリケーションにそのログアウトが伝播されます。

OAMソリューションの構成例は、「OAM構成の例」を参照してください。

SSOソリューションでは、ユーザーがアプリケーションにログインおよびログアウトするための標準的な手段を用意する必要があります。ユーザーが正常に認証された後は、SSOサービスがユーザーを適切なURLにリダイレクトします。そのためには、このソリューションの適用先であるドメインが、ログイン前とログアウト後には匿名のユーザーとロールをサブジェクトに追加でき、ログイン後には認証されたロールをサブジェクトに追加できるように構成されていることが前提となります。また、SSOプロバイダが資格証明マッピング・サービスを実装していることも前提となっています。すぐに使用できるOAMソリューションの場合、プロバイダは適切なOAMトークンを生成するCredentialMapperServiceを実装しています。

OPSS SSOフレームワークは、複数レベルの認証をサポートしていません。

目的のSSOソリューションと統合するには、そのSSOソリューションを個別にインストールして、適切に構成する必要があります。推奨ソリューションの詳細は、第IV部「シングル・サインオンの構成」を参照してください。

8.7.3.2 Fusion Middleware Controlを使用したSSOソリューションの構成

ドメインで使用するSSOソリューションを指定する手順は、次のとおりです。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「セキュリティ・プロバイダ構成」、またはセル→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。

2. そのページで、「シングル・サインオン・プロバイダ」領域の「構成」をクリックして、「シングル・サインオン・プロバイダ」ページを表示します。

3. そのページで、「シングル・サインオン・プロバイダ」ボックスを選択して、プロバイダのデータを入力できるようにします。このボックスを選択するまで、すべてのボックスはグレー表示になっています。

4. プルダウン・リストから「プロバイダ・タイプ」を選択し、選択したプロバイダに該当するデータを入力します(必要なデータは、選択したタイプによって異なります)。

5. プルダウン・リストから「認証レベル」を選択します。

6. 必要に応じ、ページの下部にある「追加」、「編集」および「削除」を使用してプロバイダの「カスタム・プロパティ」を管理します。

7. 完了したら、「OK」をクリックして、入力したデータを保存します。

8.7.3.3 OAM構成の例

「Fusion Middleware Controlを使用したSSOソリューションの構成」の手順で入力したSSOサービスの構成は、jps-config.xmlファイルに書き込まれます。指定するデータは次のとおりです。

- 特定のSSOサービス

- 自動ログインのURIおよび自動ログアウトのURI

- 認証レベル

- 選択したSSOサービスで返されるURLに記述される問合せパラメータ

- トークン生成のための適切な設定

jps-config.xmlファイルにある次のコードはOAM SSOプロバイダの構成を示しています。

<propertySets>
<propertySet name = "props.auth.url">
<property name = "login.url.BASIC" value = "http://host:port/oam_login.cgi?level=BASIC"/>
<property name = "login.url.FORM" value = "http://host:port/oam_login.cgi?level=FORM"/>
<property name = "login.url.DIGEST" value = "http://host:port/oam_login.cgi?level= DIGEST"/>
<property name = "autologin.url" value = " http://host:port/obrar.cgi"/>
<property name = "logout.url" value = "http://host:port/logout.cgi"/>
<property name = "param.login.successurl"  value = "successurl"/>
<property name = "param.login.cancelurl"   value = "cancelurl"/>
<property name = "param.autologin.targeturl" value = "redirectto"/>
<property name = "param.autologin.token"   value = "cookie"/>
<property name = "param.logout.targeturl"   value = "targeturl"/>
</propertySet>

<propertySet name="props.auth.uri">
<property name="login.url.BASIC" value="/${app.context}/adfauthentication?level=BASIC" />
<property name="login.url.FORM" value="/${app.context}/adfauthentication?level=FORM" />
<property name="login.url.DIGEST" value="/${app.context}/adfauthentication?level=DIGEST" />
<property name="autologin.url" value="/obrar.cgi" />
<property name="logout.url" value="/${app.context}/adfauthentication?logout=true" />
</propertySet>

<propertySet name = "props.auth.level">
<property name = "level.anonymous" value = "0"/>
<property name = "level.BASIC"    value = "1"/>
<property name = "level.FORM"    value = "2"/>
<property name = "level.DIGEST"   value = "3"/>
</propertySet>
<propertySets>

<serviceProviders>
<serviceProvider name = "sso.provider"
class = "oracle.security.jps.internal.sso.SsoServiceProvider"
type = "SSO">
<description>SSO service provider</description>
</serviceProvider>
</serviceProviders>

<serviceInstances>
<serviceInstance name = "sso" provider = "sso.provider">
<propertySetRef ref = "props.auth.url"/>
<propertySetRef ref = "props.auth.level"/>
<property name = "default.auth.level" value = "2"/>
<property name = "token.type" value = "OAMSSOToken"/>
<property name = "token.provider.class" value = "oracle.security.jps.wls.internal.sso.WlsTokenProvider"/>
<property name="sso.provider.class" value="oracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImpl"/>
</serviceInstance>
</serviceInstances>

<jpsContexts default = "default">
<jpsContext name = "default">
<serviceInstanceRef ref = "sso"/>
</jpsContext>
</jpsContexts>

表8-1は、SSOプロバイダの構成に関与するプロパティの意味を示しています。

表8-1 SSOプロバイダのプロパティ

プロパティ名

説明

logout.url

SSOプロバイダのログアウトURL。

login.url.BASIC

SSOプロバイダのBASICログアウトURL。

login.url.FORM

SSOプロバイダのFORMログアウトURL。

login.url.DIGEST

SSOプロバイダのDIGESTログアウトURL。

autologin.url

自動ログイン用の自動登録URL。

logout.url

SSOプロバイダのログアウトURL。

param.login.successurl

ログインの成功後のURLリダイレクト。

param.login.cancelurl

問合せの取消し後のURLリダイレクト。

param.autologin.targeturl

自動ログイン後のURLリダイレクト。

param.autologin.token

自動ログイン用のトークン。

param.logout.targeturl

ログアウト後のURLリダイレクト。

SSOプロバイダの構成については、次の重要な注意点に留意してください。

- すべてのSSOプロバイダは、少なくともFORMログイン用のURIをプロパティlogin.url.FORMで定義する必要があります。値はURLである必要はありません。

- アプリケーションで自動登録ページのURIまたはURLがサポートされている場合は、それをプロパティautologin.urlで指定する必要があります。

- SSOソリューションでグローバル・ログアウトのURIまたはURLがサポートされている場合は、それをプロパティlogout.urlで指定する必要があります。OAMソリューションではグローバル・ログアウトがサポートされています。

- 前述の例にある次のプロパティはオプションです。

- param.login.successurl

- param.login.cancelurl

- param.autologin.targeturl

- param.login.token

- param.logout.targeturl

- 前述の例でプロパティ・セットprops.auth.uri内の値で示された、URI指定の変数app.contextは、ADFアプリケーションがOAMソリューションと統合している場合にのみ使用できます。

- プロパティ・セットprops.auth.levelは必須です。

- props.auth.urlへの参照は必須です。

- SSOプロバイダのサービス・インスタンス内のプロパティsso.provider.classは、固有のSSOソリューションを実装するクラスの完全修飾名です。
OAMソリューションの場合、提供されているクラス名はoracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImplです。

- SSOプロバイダのサービス・インスタンス内のプロパティdefault.auth.levelは、上記の例に示されているとおり、2に設定する必要があります。

- SSOプロバイダのサービス・インスタンス内のプロパティtoken.typeは必須です。
このトークンのタイプは、正常な認証後にSSOプロバイダが発行するHTTPリクエストのトークン・セットを特定します。2回目以降は、このトークンがSSOプロバイダで使用されるので、ユーザーの再認証が不要となり、ユーザーのサインオンが引き続き有効となります。OAMソリューションの場合、上記の例に示されているとおり、トークン・タイプをOAMSSOTokenとします。

- SSOプロバイダのサービス・インスタンス内のプロパティtoken.provider.classは、トークン・クラスの完全修飾名で、プロバイダ固有です。

- 自動登録論理を実装したアプリケーションで、正常な自動登録後はユーザーが自動的にログインできるようにする場合、そのアプリケーションではOPSS autoLogin APIをコールする必要があります。このコールを可能にするには、クラスがJpsPermissionであるCredentialMappingというコード・ソースのパーミッションをそのアプリケーションに付与する必要があります。
system-jazn-data.xmlファイルにある次のコードでは、アプリケーションMyAppに対してこのパーミッションを指定しています。

<grant>
<grantee>
<codesource>
<url>file:${oracle.deployed.app.dir}/<MyApp>${oracle.deployed.app.ext}
</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>CredentialMapping</name>
</permission>
</permissions>
</grant>

URLの指定に使用するシステム変数に注意してください。詳細は、<url>の例を参照してください。

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

次の各項で、Fusion Middleware Control、OPSSスクリプトまたはOracle Entitlements Serverを使用して管理者がポリシーを管理する方法について説明します。

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

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

- OPSSスクリプトを使用したアプリケーション・ポリシーの管理

- Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理
代表的な操作は次のとおりです。

- 既存のアプリケーション・ロールの権限の変更

- プリンシパルのパーミッションの取消し

- アプリケーション・ロールの作成と削除

- すべてのアプリケーション・ロール、およびアプリケーション・ロールのすべてのメンバーのリスト

この章では、次の項目についても説明します。

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

- WLSTスクリプトを使用した匿名ロールおよび認証ロールへのポリシーの付与

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

- ポリシー・ストア構成のガイドライン

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

ポリシー・ストアのデータにアクセスできるのは、ドメイン管理者など、適切なパーミッションを持つユーザーに限られます。

次の各項で、Fusion Middleware Control、OPSSスクリプトまたはOracle Entitlements Serverを使用して管理者がポリシーを管理する方法について説明します。代表的な操作は次のとおりです。

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

- OPSSスクリプトを使用したアプリケーション・ポリシーの管理

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

予期しない認可の失敗を防ぎ、効果的にポリシーを管理するには、次の重要ポイントに注意してください。

重要ポイント1:

ユーザーを削除する前に、ユーザーに付与されているすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに誤って継承される可能性があります。

ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、グループ)を更新して、変更後のデータでも予期したとおりに機能するようにする必要があります。

第L.11項「ユーザーによる予期しないパーミッションの取得」を参照してください。

重要ポイント2:

ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。

そのため、次のことをお薦めします。

- ポリシーのプロビジョニング時に、管理者は、ポリシーで使用するユーザーおよびグループの名前に、アイデンティティ・リポジトリに記録されているその名前とまったく同じ文字構成を使用します。これによって、ユーザー名またはグループ名を指定した問合せをポリシー・ストアに対して実行すると、想定したとおりに機能します。

- 実行時にユーザー名を入力するときに、エンドユーザーは、アイデンティティ・リポジトリで指定されている大文字/小文字の組合せと完全に一致する名前を入力します。これによって、予期したとおりにユーザーが認可されます。

第L.4項「パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致」を参照してください。

重要ポイント3:

リソース・タイプの名前、リソース、または権限には印刷可能文字のみを使用でき、先頭または末尾に空白を使用することはできません。

ロール名をはじめとしたポリシーにおける文字使用に関する考慮事項は、第L.16項「ポリシーに使用する文字」を参照してください。

重要ポイント4:

デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debugを-Djps.auth.debug=trueに設定する必要があります。

特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を前述のように設定する必要があります。

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

Fusion Middleware Controlでは、次の項の説明のように、ドメインで使用しているポリシー・ストア・プロバイダのタイプに関係なく、WebLogicドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理できます。

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

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

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

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

この項では、Fusion Middleware Controlを使用してアプリケーション・ポリシーを管理する方法について説明します。

注意:

複数のアプリケーションがパーミッションを共有している場合、パーミッション・チェックの失敗を防ぐには、該当するパーミッション・クラスをシステム・クラスパスで指定しておく必要があります。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ポリシー」(アプリケーションがOracle WebLogic Serverにデプロイされている場合)、または「セル」→「セキュリティ」→「アプリケーション・ポリシー」(WebSphere Application Serverにデプロイされている場合)と移動して、「アプリケーション・ポリシー」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用です。それを開くと、ドメインまたはセルで現在使用しているポリシー・ストア・プロバイダが表示されます。

2. 指定したプリンシパルまたはパーミッションに一致するアプリケーションのポリシーを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、基準にする文字列(プリンシパル名、プリンシパル・グループまたはアプリケーション・ロール)を入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

3. 選択したアプリケーション・ストライプのアプリケーション・ポリシーを作成するには、「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。ここで、作成する権限に対するプリンシパルおよびパーミッションを追加します。

1. パーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログ・ボックスを表示します。
そのダイアログ・ボックスの「検索」領域で、まず「権限」または「リソース・タイプ」を選択します。「権限」を選択した場合は、クラスまたはリソース名に一致するパーミッションを指定し、「権限クラス」および「リソース名」を指定します。「リソース・タイプ」を選択した場合は、タイプ名に一致するリソース・タイプを指定し、タイプを指定します。「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したパーミッションが、「権限」領域の表に表示されます。

2. プリンシパルを追加するには、「権限受領者」領域の「追加」ボタンをクリックして、「プリンシパルの追加」ダイアログ・ボックスを表示します。
そのダイアログ・ボックスの「検索」領域で、「タイプ」を選択し、プリンシパル名または表示名に一致させる文字列を入力して、青いボタンをクリックします。問合せの結果が「検索済プリンシパル」表に表示されます。その表から1つ以上の行を選択し、「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したプリンシパルが、「権限受領者」領域の表に表示されます。

3. 「権限受領者」領域の表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。

4. 完了したら、「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。作成したポリシーのプリンシパルとパーミッションがページの下部の表に表示されます。

4. 既存のアプリケーション・ポリシーに基づいてアプリケーション・ポリシーを作成する手順は、次のとおりです。

1. 表から既存のポリシーを選択します。

2. 「類似作成」をクリックし、「アプリケーション権限の類似作成」ページを表示します。このページでは、選択したポリシーから抽出されたデータがパーミッションの表に自動的に入力されます。

3. 前述の手順3の下位手順の説明に従い、必要に応じてこれらの値を変更し、「OK」をクリックします。

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

この項では、Fusion Middleware Controlを使用してアプリケーション・ロールを管理する方法について説明します。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ロール」(アプリケーションがOracle WebLogic Serverにデプロイされている場合)、または「セル」→「セキュリティ」→「アプリケーション・ロール」(WebSphere Application Serverにデプロイされている場合)と移動して、「アプリケーション・ロール」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用です。それを開くと、ドメインまたはセルで現在使用しているポリシー・ストア・プロバイダが表示されます。

2. アプリケーションのロールを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、ロール名に一致させるデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

3. アプリケーション・ロールを作成するには、「作成」をクリックして、「アプリケーション・ロールの作成」ページを表示します。すべての領域に一度にデータを入力する必要はないことに注意してください。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後から指定できます。同様に、ロール・マッピングに対するデータを後で入力することもできます。
領域「一般」で、作成するロールの次の属性を指定します。

1. 「ロール名」テキスト・ボックスにロールの名前を入力します。

2. 必要に応じて、ロールに表示する名前を「表示名」テキスト・ボックスに入力します。

3. オプションで、「説明」テキスト・ボックスに、ロールの説明を入力します。

「メンバー」領域で、作成するロールのマップ先とするユーザーまたはグループを指定します。マップ先とする他のアプリケーション・ロールがある場合は、それを指定します。

作成するアプリケーション・ロールにアプリケーション・ロールを追加する手順は、次のとおりです。

1. 「追加」をクリックして、「プリンシパルの追加」ダイアログを表示します。

2. このダイアログで、「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名に一致させる文字列を入力して、青いボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。その表から1つ以上のプリンシパルを選択します。

3. 完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したアプリケーション・ロールが「メンバー」表に表示されます。

4. 「メンバー」表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。

5. 「OK」をクリックし、ロールの作成(または更新)を完了し、「アプリケーション・ロール」ページに戻ります。作成したロールがそのページの下部の表に表示されます。

6. 既存のアプリケーション・ロールに基づいてアプリケーション・ロールを作成する手順は、次のとおりです。

1. 表から既存のロールを選択します。

2. 「類似作成」をクリックし、「アプリケーション・ロールの類似作成」ページを表示します。このページでは、選択したロールから抽出されたデータが一部のデータに自動的に入力されます。

3. ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。

ロール階層でパーミッションがどのように継承されるかを理解するには、第2.2.1項「パーミッションの継承とロールの階層」を参照してください。

9.2.3 システム・ポリシーの管理

この項では、Fusion Middleware Controlを使用して、Oracle WebLogic ServerドメインまたはWebSphere Application Serverセルのシステム・ポリシーを管理する方法について説明します。

次の手順では、プリンシパルのポリシーとコードベースのポリシーという2種類のシステム・ポリシーを作成できます。プリンシパルのポリシーでは、ユーザーまたはグループのリストにパーミッションを付与します。コードベースのポリシーでは、コード(通常はURLまたはJARファイル)にパーミッションを付与します。たとえば、資格証明ストア・フレームワークを使用するアプリケーションには、適切なコードベースのポリシーが必要です。コードベースURLでは、ワイルドカードやパターンはサポートされていません。

1. Fusion Middleware Controlにログインし、状況に応じて「ドメイン」→「セキュリティ」→「システム・ポリシー」、またはセル→「セキュリティ」→「システム・ポリシー」とナビゲートして、「システム・ポリシー」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用です。それを開くと、ドメインまたはセルで現在使用しているポリシー・ストア・プロバイダが表示されます。

2. 指定したタイプ、名前およびパーミッションと一致するシステム・ポリシーを表示するには、「検索」領域を開き、一致対象のデータを入力して、青いボタンをクリックします。検索結果がページの下部の表に表示されます。現在のすべてのシステム・ポリシーを表示するには、タイプとして「すべて」を選択し、名前とパーミッションのボックスは空のままにします。

3. 「編集」ボタンをクリックすると、選択したポリシーの特性をいつでも編集できます。リストからポリシーを削除するには、「削除」ボタンをクリックします。

システム・ポリシーを作成する手順は、次のとおりです。

1. 「作成」をクリックして、「システム権限の作成」ページを表示します。

2. 作成するポリシーのタイプとして、「プリンシパル」または「コードベース」を選択します。選択したタイプによってUIが多少異なります。次の手順は、「プリンシパル」を選択した場合に対するものです。

3. パーミッションを追加するには、「権限」領域の「追加」ボタンをクリックして、「権限の追加」ダイアログ・ボックスを表示し、作成しているポリシーに追加するパーミッションを選択します。

1. 「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。検索結果が「検索」領域の表に表示されます。

2. 追加するパーミッションを選択するには、表からパーミッションを選択します。パーミッションを選択すると、その詳細が読取り専用の「カスタマイズ」領域に表示されます。

3. 「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したパーミッションが、「権限」の表に追加されます。

4. 「パーミッション」表からパーミッションを選択し、「編集」ボタンを使用すると、パーミッションの特性をいつでも変更できます。リストからパーミッションを削除するには、「削除」ボタンを使用します。

5. 「OK」をクリックして、「システム・ポリシー」ページに戻ります。

6. 「コードベースに関する権限」領域の表は読取り専用であり、コードベース・システム・ポリシーに関連付けられているリソース名、アクションおよびパーミッション・クラスを示します。

9.3 OPSSスクリプトによるアプリケーション・ポリシーの管理

OPSSスクリプトは、Oracle WebLogic ServerのコンテキストではWLSTスクリプトであり、WebSphere Application ServerのコンテキストではWASAdminスクリプトです。この項に記載されたスクリプトは、WebLogic Application ServerとWebSphere Application Serverの両プラットフォームに適用されます。

オンライン・スクリプトとは、実行中のサーバーとの接続が必要なスクリプトです。特に指定がないかぎり、この項に記載されたスクリプトはオンライン・スクリプトで、ベースがファイル、LDAP、DBのいずれであるかにかかわりなくポリシー・ストアで動作します。動作にサーバーの実行を必要としないオフラインのスクリプトもいくつか存在します。

読取り専用スクリプトは、モニター、オペレータ、コンフィギュレータまたはAdminというWebLogicグループに属するユーザーのみが実行できます。読取り-書込みスクリプトは、AdminまたはコンフィギュレータのWebLogicグループに属するユーザーのみが実行できます。WLSTスクリプトはすべて、Oracle WebLogic Serverをインストールすれば、追加設定なしで使用できます。

WLSTスクリプトは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

WASAdminスクリプトは、インタラクティブ・モードでのみ実行できます。

重要事項

OPSSスクリプトを呼び出す前は、次のスクリプトのいずれか(使用するプラットフォームによって決まります)を実行して、必要なJARがクラス・パスに追加されていることを確認する必要があります。

WebLogicの場合:

>sh $ORACLE_HOME/common/bin/wlst.sh

オンライン・スクリプトを実行するには、次のようにWebLogicサーバーに接続しておく必要があります。

>java weblogic.WLST
>connect('servername', 'password', 'localhost:portnum')

WebSphereでOPSSスクリプトを実行する方法の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

OPSSはサポートされているすべてのプラットフォームでアプリケーション・ポリシーの管理に使用できる次のスクリプトが用意されています(特に指定がないかぎりこのスクリプトはすべてオンラインです)。

- listAppStripes

- 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

- listEntitlement

- listResourceTypes

- reassociateSecurityStore

前述のスクリプトで指定するクラス名はすべて、完全修飾パス名にする必要があります。引数appStripeは、アプリケーション・ストライプ(通常はアプリケーション名)を参照し、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。

認証ロール、匿名ロールおよびWLSTコマンドに関する重要な情報は、第9.5項「WLSTスクリプトを使用した匿名ロールおよび認証ロールへのポリシーの付与」を参照してください。

バージョン付きアプリケーションにおけるアプリケーション・ストライプの正しい使用法については、第9.6項「WLSTスクリプトのバージョン付きアプリケーションのアプリケーション・ストライプ」を参照してください。

9.3.1 listAppStripes

スクリプトlistAppStripesは、アプリケーション・ストライプをリストします。このスクリプトは、オフライン・モードでもオンライン・モードでも実行できます。オフライン・モードで実行する場合は構成ファイルが渡される必要があり、渡された構成ファイルのデフォルト・コンテキストの構成で参照されるポリシー・ストア内のアプリケーション・ストライプをリストします。オンライン・モードで実行する場合は、構成ファイルを渡すことはできず、接続先のドメインのポリシー・ストアのストライプをリストします。いずれのモードでも、正規表現が渡された場合はその正規表現と一致する名前のアプリケーション・ストライプがリストされ、これ以外の場合はすべてのアプリケーション・ストライプがリストされます。

このコマンドがDBベースへの再関連付けの後にオフライン・モードで使用される場合、「DBベース・ストアへの再関連付け後のオフライン・スクリプトの実行」の説明に従って、再関連付けで生成された構成ファイルを手動で編集する必要があります。

スクリプト・モード構文

listAppStripes.py [-configFile configFileName]
[-regularExpression aRegExp]

インタラクティブ・モード構文

listAppStripes([configFile="configFileName"] [, regularExpression="aRegExp"])

引数の意味は、次のとおりです。

- configFileは、OPSS構成ファイルへのパスを指定します。オプション。指定した場合はスクリプトがオフラインで実行されます。指定された構成ファイルのデフォルト・コンテキストにアイデンティティ・ストアに対するサービス・インスタンスの参照を含めることはできません。指定しない場合はスクリプトがオンラインで実行され、ポリシー・ストア内のアプリケーション・ストライプがリストされます。

- regularExpressionは、正規表現を指定しこれに一致するストライプ名が返されます。オプション。指定しない場合はすべての名前が一致することになります。サブストリングの一致を返す場合は文字*(アスタリスク)を使用します。

使用例

次の(オンラインの)呼出しでは、ポリシー・ストア内のアプリケーション・ストライプのリストが返されます。

listAppStripes.py

次の(オフラインの)呼出しでは、指定された構成ファイルのデフォルト・コンテキストで参照されるポリシー・ストア内のアプリケーション・ストライプのリストが返されます。

listAppStripes.py -configFile /home/myFiles/jps-config.xml

次の(オンラインの)呼出しでは、接頭辞Appが含まれるアプリケーション・ストライプのリストが返されます。

listAppStripes.py -regularExpression App*

9.3.2 createAppRole

スクリプトcreateAppRoleでは、指定したアプリケーション・ストライプおよびロール名を持つアプリケーション・ロールがポリシー・ストア内に作成されます。

スクリプト・モード構文

createAppRole.py -appStripe appName
-appRoleName roleName

インタラクティブ・モード構文

createAppRole(appStripe="appName", appRoleName="roleName")

引数(すべて必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。

- appRoleNameでは、ロール名を指定します。

使用例

次の呼出しでは、アプリケーション・ストライプmyAppおよびロール名myRoleを持つアプリケーション・ロールが作成されます。

createAppRole.py -appStripe myApp -appRoleName myRole

9.3.3 deleteAppRole

スクリプトdeleteAppRoleでは、渡されたストライプからアプリケーション・ロールが削除されます。具体的に言うと、このスクリプトでは次のものを削除することによってカスケード削除を実施します。

- ロールが存在するすべての権限

- 他のロールに属しているロール

- 特定のロールに属しているすべてのロール

スクリプト・モード構文

deleteAppRole.py -appStripe appName -appRoleName roleName

インタラクティブ・モード構文

deleteAppRole(appStripe="appName", appRoleName="roleName")

引数(すべて必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。

- appRoleNameでは、ロール名を指定します。

使用例

次の呼出しでは、アプリケーション・ストライプmyAppおよび名前myRoleを持つロールが削除されます。

deleteAppRole.py -appStripe myApp -appRoleName myRole

9.3.4 grantAppRole

スクリプトgrantAppRoleでは、指定したアプリケーション・ストライプおよび名前を持つロールにプリンシパル(クラスと名前)が追加されます。このスクリプトは、アプリケーション・ロール階層の構築や変更に使用できます。

スクリプト・モード構文

grantAppRole.py -appStripe appName
-appRoleName roleName
-principalClass className
-principalName prName

インタラクティブ・モード構文

grantAppRole(appStripe="appName", appRoleName="roleName", principalClass="className", principalName="prName")

引数(すべて必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。

- appRoleNameでは、ロール名を指定します。

- principalClassでは、クラスの完全修飾名を指定します。このクラスは、実行時に使用できるようにクラスパスで指定しておく必要があります。通常、プリンシパルがユーザーの場合、このクラスはweblogic.security.principal.WLSUserImplであり、プリンシパルがグループの場合、このクラスはweblogic.security.principal.WLSGroupImplです。

- principalNameでは、プリンシパル名を指定します。

使用例

次の呼出しでは、デフォルトのプリンシパル実装クラスWLSGroupImplで定義したプリンシパルmyPrincipalが、アプリケーション・ストライプmyAppのロールmyRoleに追加されます。

grantAppRole.py -appStripe myApp
-appRoleName myRole
-principalClass weblogic.security.principal.WLSGroupImpl
-principalName myPrincipal

9.3.5 revokeAppRole

スクリプトrevokeAppRoleでは、指定したアプリケーション・ストライプおよび名前を持つロールからプリンシパル(クラスと名前)が削除されます。このスクリプトは、アプリケーション・ロール階層の構築や変更に使用できます。

スクリプト・モード構文

revokeAppRole.py -appStripe appName
-appRoleName roleName
-principalClass className
-principalName prName

インタラクティブ・モード構文

revokeAppRole(appStripe="appName", appRoleName="roleName", principalClass="className", principalName="prName")

引数(すべて必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。

- appRoleNameでは、ロール名を指定します。

- principalClassでは、完全修飾プリンシパル・クラス名を指定します。

- principalNameでは、プリンシパル名を指定します。

使用例

次の呼出しでは、デフォルトのプリンシパル実装クラスWLSGroupImplで定義したプリンシパルmyPrincipalが、アプリケーション・ストライプmyAppのロールmyRoleから削除されます。

revokeAppRole.py -appStripe myApp
-appRoleName myRole
-principalClass weblogic.security.principal.WLSGroupImpl
-principalName myPrincipal

9.3.6 listAppRoles

スクリプトlistAppRolesでは、指定したアプリケーション・ストライプを持つすべてのロールがリストされます。

スクリプト・モード構文

listAppRoles.py -appStripe appName

インタラクティブ・モード構文

listAppRoles(appStripe="appName")

引数(必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。

使用例

次の呼出しでは、アプリケーション・ストライプmyAppを持つすべてのロールが返されます。

listAppRoles.py -appStripe myApp

9.3.7 listAppRolesMembers

スクリプトlistAppRoleMembersでは、指定したアプリケーション・ストライプおよびロール名を持つロール内のすべてのメンバーがリストされます。

スクリプト・モード構文

listAppRoleMembers.py -appStripe appName
-appRoleName roleName

インタラクティブ・モード構文

listAppRoleMembers(appStripe="appName", appRoleName="roleName")

引数(すべて必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。

- appRoleNameでは、ロール名を指定します。

使用例

次の呼出しでは、アプリケーション・ストライプmyAppおよび名前myRoleを持つロール内のすべてのメンバーが返されます。

listAppRoleMembers.py -appStripe myApp
-appRoleName myRole

9.3.8 grantPermission

スクリプトgrantPermissionでは、アプリケーション・ポリシーまたはグローバル・ポリシー・セクションで、コードベース、URLまたはプリンシパルに付与するパーミッションが作成されます。

スクリプト・モード構文

grantPermission [-appStripe appName]
[-codeBaseURL url]
[-principalClass prClassName]
[-principalName prName]
-permClass permissionClassName
[-permTarget permName]
[-permActions comma_separated_list_of_actions]

インタラクティブ・モード構文

grantPermission([appStripe="appName",] [codeBaseURL="url",] [principalClass="prClassName",] [principalName="prName",] permClass="permissionClassName", [permTarget="permName",]
[permActions="comma_separated_list_of_actions"])

引数(オプションの引数は、大カッコで囲んであります)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。この指定がない場合はスクリプトがシステム・ポリシーに対して機能します。

- codeBaseURLでは、パーミッションが付与されたコードのURLを指定します。

- principalClassでは、完全修飾クラス名を指定します(権限受領者)。

- principalNameでは、権限受領者プリンシパルの名前を指定します。

- permClassでは、パーミッション・クラスの完全修飾名を指定します

- permTargetでは、パーミッション・ターゲットの名前を指定します(使用可能な場合)。この属性が含まれていないパーミッションもあります。

- permActionでは、付与するアクションのリストを指定します。この属性が含まれていないパーミッションもあります。また、使用できるアクションはパーミッション・クラスによって異なります。

使用例

次の呼出しでは、指定したデータを持つアプリケーション・パーミッションが(アプリケーション・ストライプmyAppを持つアプリケーションに対して)作成されます。

grantPermission.py -appStripe myApp
-principalClass my.custom.Principal
-principalName manager
-permClass java.security.AllPermission

次の呼出しでは、指定したデータを設定したシステム・パーミッションが作成されます。

grantPermission.py -principalClass my.custom.Principal
-principalName manager
-permClass java.io.FilePermission
-permTarget /tmp/fileName.ext
-permActions read,write

9.3.9 revokePermission

スクリプトrevokePermissionでは、アプリケーションまたはグローバル・ポリシー・セクションで定義されたプリンシパルまたはコードベースからパーミッションが削除されます。

スクリプト・モード構文

revokePermission [-appStripe appName]
[-codeBaseURL url]
[-principalClass prClassName]
[-principalName prName]
-permClass permissionClassName
[-permTarget permName]
[-permActions comma_separated_list_of_actions]

インタラクティブ・モード構文

revokePermission([appStripe="appName",][codeBaseURL="url",]
[principalClass="prClassName",] [principalName="prName",]
permClass="permissionClassName", [permTarget="permName",] [permActions="comma_separated_list_of_actions"])

引数(オプションの引数は、大カッコで囲んであります)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。この指定がない場合はスクリプトがシステム・ポリシーに対して機能します。

- codeBaseURLでは、パーミッションが付与されたコードのURLを指定します。

- principalClassでは、完全修飾クラス名を指定します(権限受領者)。

- principalNameでは、権限受領者プリンシパルの名前を指定します。

- permClassでは、パーミッション・クラスの完全修飾名を指定します

- permTargetでは、パーミッション・ターゲットの名前を指定します(使用可能な場合)。この属性が含まれていないパーミッションがあることに注意してください。

- permActionでは、削除するアクションのリストを指定します。この属性が含まれていないパーミッションがあり、使用できるアクションはパーミッション・クラスによって異なることに注意してください。

使用例

次の呼出しでは、指定したデータを持つアプリケーション・パーミッションが(アプリケーション・ストライプmyAppを持つアプリケーションに対して)削除されます。

revokePermission.py -appStripe myApp
-principalClass my.custom.Principal
-principalName manager
-permClass java.security.AllPermission

次の呼出しでは、指定したデータを持つシステム・パーミッションが削除されます。

revokePermission.py -principalClass my.custom.Principal
-principalName manager
-permClass java.io.FilePermission
-permTarget /tmp/fileName.ext
-permActions read,write

9.3.10 listPermissions

スクリプトlistPermissionsでは、指定したプリンシパルに付与されたすべてのパーミッションがリストされます。

スクリプト・モード構文

listPermissions [-appStripe appName]
-principalClass className
-principalName prName

インタラクティブ・モード構文

listPermissions([appStripe="appName",] principalClass="className", principalName="prName")

引数(オプションの引数は、大カッコで囲んであります)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。この指定がない場合はスクリプトがシステム・ポリシーに対して機能します。

- principalClassでは、完全修飾クラス名を指定します(権限受領者)。

- principalNameでは、権限受領者プリンシパルの名前を指定します。

使用例

次の呼出しでは、アプリケーションmyAppのポリシーによってプリンシパルに付与されたすべてのパーミッションがリストされます。

listPermissions.py -appStripe myApp
-principalClass my.custom.Principal
-principalName manager

次の呼出しでは、システム・ポリシーによってプリンシパルに付与されたすべてのパーミッションがリストされます。

listPermissions.py -principalClass my.custom.Principal
-principalName manager

9.3.11 deleteAppPolicies

スクリプトdeleteAppPoliciesでは、指定したアプリケーション・ストライプを持つすべてのポリシーが削除されます。

スクリプト・モード構文

deleteAppPolicies -appStripe appName

インタラクティブ・モード構文

deleteAppPolicies(appStripe="appName")

引数(必須)の意味は、次のとおりです。

- appStripeは、アプリケーション・ストライプを指定します。この指定がない場合はスクリプトがシステム・ポリシーのみに対して機能します。

使用例

deleteAppPolicies -appStripe myApp

9.3.12 createResourceType

スクリプトcreateResourceTypeでは、特定のアプリケーション・ストライプにあるポリシー・ストアに、指定した名前、表示名、説明およびアクションが設定された新規<resource-type>エントリが挿入されます。オプションの引数は角カッコで囲まれています。それ以外のすべての引数は必須です。

スクリプト・モード構文

createResourceType -appStripe appStripeName
-resourceTypeName resTypeName
-displayName displName
-description descripString
[-provider resTypeProvider]
[-matcher resTypeClass]
-actions resTypeActions
[-delimiter delimChar]

インタラクティブ・モード構文

createResourceType(appStripe="appStripeName", resourceTypeName="resTypeName", displayName="displName", description="descripString"
[, provider="resTypeProvider", matcher="resTypeClass"], actions="resTypeActions"[, delimiter="delimChar"])

引数の意味は、次のとおりです。

- appStripeでは、リソース・タイプの挿入先のアプリケーション・ストライプを指定します。

- resourceTypeNameでは、挿入するリソース・タイプの名前を指定します。

- displayNameでは、UIガジェットで使用するリソース・タイプの名前を指定します。

- descriptionでは、リソース・タイプの簡単な説明を指定します。

- providerでは、リソース・タイプのプロバイダを指定します。

- matcherでは、リソース・タイプのクラスを指定します。指定しなかった場合は、デフォルトのoracle.security.jps.ResourcePermissionが使用されます。

- actionsでは、リソース・タイプのインスタンスに許可されたアクションを指定します。

- delimiterでは、アクションのリストを区切る際に使用する文字を指定します。指定しなかった場合は、デフォルトのカンマ','に設定されます。

使用例

次の呼出しでは、セミコロンで区切って指定したアクションBWPrintおよびアクションColorPrintを設定したリソース・タイプがストライプmyApplicationに作成されます。

createResourceType -appStripe myApplication
-resourceTypeName Printer
-displayName PRINTER
-description A resource type representing a Printer
-provider Printer
-matcher com.printer.Printer
-allowedActions BWPrint;ColorPrint
-delimiter ;

9.3.13 getResourceType

スクリプトgetResourceTypeでは、特定のアプリケーション・ストライプにあるポリシー・ストアから、指定した名前の<resource-type>エントリの関連パラメータが返されます。

スクリプト・モード構文

getResourceType -appStripe appStripeName
-resourceTypeName resTypeName

インタラクティブ・モード構文

getResourceType(appStripe="stripeName", resourceTypeName="resTypeName")

引数の意味は、次のとおりです。

- appStripeでは、リソース・タイプのフェッチ元のアプリケーション・ストライプを指定します。

- resourceTypeNameでは、フェッチするリソース・タイプの名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationからリソース・タイプmyResTypeがフェッチされます。

getResourceType -appStripe myApplication
-resourceTypeName myResType

9.3.14 deleteResourceType

スクリプトdeleteResourceTypeでは、渡されたアプリケーション・ストライプから、指定した名前のリソース・タイプが削除されます。このスクリプトは、指定のリソース・タイプのリソース・インスタンスを使用するすべての権限および付与権限から、そのリソース・タイプのすべてのリソース・インスタンスを削除することによってカスケード削除を実施します。

重要:

作成を完了したリソース・タイプは変更できません。リソース・タイプをなんらかの方法で(リソース・タイプのアクションの追加、名前変更、削除など)変更する必要がある場合は、そのリソース・タイプを削除し、適切な値を使用してリソース・タイプを新規作成する必要があります。具体的には次の操作を実行します。

- 新規リソース・タイプの作成

- 必要な新規リソース・インスタンスの作成

- 必要な権限の作成

スクリプト・モード構文

deleteResourceType -appStripe appStripeName
-resourceTypeName resTypeName

インタラクティブ・モード構文

deleteResourceType(appStripe="stripeName", resourceTypeName="resTypeName")

引数の意味は、次のとおりです。

- appStripeでは、リソース・タイプの削除元のアプリケーション・ストライプを指定します。

- resourceTypeNameでは、削除するリソース・タイプの名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationからリソース・タイプmyResTypeが削除されます。

deleteResourceType -appStripe myApplication
-resourceTypeName myResType

9.3.15 createResource

スクリプトcreateResourceでは、指定したアプリケーション・ストライプに指定したタイプの新しいリソースが作成されます。渡されるリソース・タイプは、渡されたアプリケーション・ストライプに存在している必要があります。

スクリプト・モード構文

createResource -appStripe appStripeName
-name resName
-type resTypeName
[-displayName dispName]
[-description descript]

インタラクティブ・モード構文

createResource(appStripe="appStripeName", name="resName", type="resTypeName" [,-displayName="dispName"] [,-description="descript"])

引数の意味は、次のとおりです。

- appStripeは、リソースを作成するアプリケーション・ストライプを指定します。

- nameは、作成するリソースの名前を指定します。

- typeは、作成するリソースのタイプを指定します。スクリプトの呼出し時に渡されるリソース・タイプがアプリケーション・ストライプ内に存在している必要があります。

- diplayNameは、作成するリソースの表示名を指定します。オプション。

- descriptionは、作成するリソースの説明を指定します。オプション。

使用例

次の呼出しでは、ストライプmyApplicationにリソースmyResourceが作成されます。

createResource -appStripe myApplication
-name myResource
-type myResType
-displayName myNewResource

9.3.16 deleteResource

スクリプトdeleteResourceでは、特定のアプリケーション・ストライプの権限から特定のリソースとそのすべての参照が削除されます。このスクリプトはカスケード削除を実行します。権限が参照するリソースが1つのみの場合はその権限が削除され、それ以外の場合は、権限から渡されたタイプのリソース・アクションが削除されます。

スクリプト・モード構文

deleteResource -appStripe appStripeName
-name resName
-type resTypeName

インタラクティブ・モード構文

deleteResource(appStripe="appStripeName", name="resName", type="resTypeName")

引数の意味は、次のとおりです。

- appStripeは、リソースの削除が実行されるアプリケーション・ストライプを指定します。

- nameは、削除対象のリソース名を指定します。

- typeは、削除されるリソースのタイプを指定します。スクリプトの呼出し時に渡されるリソース・タイプがアプリケーション・ストライプ内に存在している必要があります。

使用例

次の呼出しでは、ストライプmyApplicationのリソースmyResourceが削除されます。

deleteResource -appStripe myApplication
-name myResource
-type myResType

9.3.17 listResources

スクリプトlistResourcesは、指定したアプリケーション・ストライプ内のリソースをリストします。リソース・タイプを指定した場合は、指定したリソース・タイプのすべてのリソースがリストされ、この指定がない場合はすべてのタイプのすべてのリソースがリストされます。

スクリプト・モード構文

listResources -appStripe appStripeName
[-type resTypeName]

インタラクティブ・モード構文

listResources(appStripe="appStripeName" [,type="resTypeName"])

引数の意味は、次のとおりです。

- appStripeは、リソースがリストされるアプリケーション・ストライプを指定します。

- typeは、リストされるリソースのタイプを指定します。スクリプトの呼出し時に渡されるリソース・タイプがアプリケーション・ストライプ内に存在している必要があります。

使用例

次の呼出しでは、ストライプmyApplicationのタイプmyResTypeのすべてのリソースがリストされます。

listResources -appStripe myApplication
-type myResType

次の呼出しでは、ストライプmyApplicationのすべてのリソースがリストされます。

listResources -appStripe myApplication

9.3.18 listResourceActions

スクリプトlistResourceActionsは、特定のアプリケーション・ストライプ内の権限のリソースおよびアクションをリストします。

スクリプト・モード構文

listResourceActions -appStripe appStripeName
-permSetName entitlementName

インタラクティブ・モード構文

listResourceActions(appStripe="appStripeName", permSetName="entitlementName")

引数の意味は、次のとおりです。

- appStripeは、権限の場所であるアプリケーション・ストライプを指定します。

- permSetNameは、リソースとアクションがリストされる権限の名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationの権限myEntitlementのリソースとアクションがリストされます。

listResourceActions -appStripe myApplication
-permSetName myEntitlement

9.3.19 createEntitlement

スクリプトcreateEntitlementでは、リソース1つのみの新しい権限と指定したアプリケーション・ストライプのアクションのリストが作成されます。addResourceToEntitlementは、既存の権限へのリソースの追加に使用されます。既存の権限からリソースを削除するには、revokeResourceFromEntitlementを使用します。

スクリプト・モード構文

createEntitlement -appStripe appStripeName
-name entitlementName
-resourceName resName
-actions actionList
[-displayName dispName]
[-description descript]

インタラクティブ・モード構文

createEntitlement(appStripe="appStripeName", name="entitlementName", resourceName="resName", actions="actionList" [,-displayName="dispName"] [,-description="descript"])

引数の意味は、次のとおりです。

- appStripeは、権限を作成するアプリケーション・ストライプを指定します。

- nameは、作成する権限の名前を指定します。

- resourceNameは、作成される権限の特定のリソース・メンバーの名前を指定します。

- actionsは、リソースresourceNameのアクションのカンマ区切りリストを指定します。

- diplayNameは、作成するリソースの表示名を指定します。オプション。

- descriptionは、作成する権限の説明を指定します。オプション。

使用例

次の呼出しでは、ストライプmyApplicationにリソースmyResourceのみの権限myEntitlementが作成されます。

createEntitlement -appStripe myApplication
-name myEntitlement
-resourceName myResource
-actions read,write

9.3.20 getEntitlement

スクリプトgetEntitlementでは、特定のアプリケーション・ストライプの権限の名前、表示名、すべてのリソース(およびそのアクション)が返されます。

スクリプト・モード構文

getEntitlement -appStripe appStripeName
-name entName

インタラクティブ・モード構文

getEntitlement(appStripe="appStripeName", name="entName")

引数の意味は、次のとおりです。

- appStripeは、権限が配置されるアプリケーション・ストライプを指定します。

- nameは、アクセスする権限の名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationの権限myEntitlementの情報が返されます。

getEntitlement -appStripe myApplication
-name myEntitlement

9.3.21 deleteEntitlement

スクリプトdeleteEntitlementでは、指定したアプリケーション・ストライプの権限が1つ削除されます。このスクリプトは、アプリケーション・ストライプ内で指定した権限のすべての参照を削除することによってカスケード削除を実行します。

スクリプト・モード構文

deleteEntitlement -appStripe appStripeName
-name entName

インタラクティブ・モード構文

deleteEntitlement(appStripe="appStripeName", name="entName")

引数の意味は、次のとおりです。

- appStripeは、権限が削除されるアプリケーション・ストライプを指定します。

- nameは、削除対象の権限の名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationの権限myEntitlementが削除されます。

deleteEntitlement -appStripe myApplication
-name myEntitlement

9.3.22 addResourceToEntitlement

スクリプトaddResourceToEntitlementでは、指定したアクションのリソースが指定したアプリケーション・ストライプの特定の権限に追加されます。渡されるリソース・タイプは、渡されたアプリケーション・ストライプに存在している必要があります。

スクリプト・モード構文

addResourceToEntitlement -appStripe appStripeName
-name entName
-resourceName resName
-resourceType resType
-actions actionList

インタラクティブ・モード構文

addResourceToEntitlement(appStripe="appStripeName", name="entName", resourceName="resName",actions="actionList")

引数の意味は、次のとおりです。

- appStripeは、権限が配置されるアプリケーション・ストライプを指定します。

- nameは、変更対象の権限の名前を指定します。

- resourceNameは、追加するリソースを指定します。

- resourceTypeは、追加するリソースのタイプを指定します。スクリプトの呼出し時に渡されるリソース・タイプがアプリケーション・ストライプ内に存在している必要があります。

- actionsは、追加されるリソースのアクションのカンマ区切りリストを指定します。

使用例

次の呼出しでは、ストライプmyApplicationの権限myEntitlementにリソースmyResourceが追加されます。

addResourceToEntitlement -appStripe myApplication
-name myEntitlement
-resourceName myResource
-resourceType myResType
-actions view,edit

9.3.23 revokeResourceFromEntitlement

スクリプトrevokeResourceFromEntitlementでは、指定したアプリケーション・ストライプの権限から特定のリソースが削除されます。

スクリプト・モード構文

revokeResourceFromEntitlement -appStripe appStripeName
-name entName
-resourceName resName
-resourceType resTypeName
-actions actionList

インタラクティブ・モード構文

revokeResourceFromEntitlement(appStripe="appStripeName", name="entName", resourceName="resName" ,-resourceType="resTypeName", actions="actionList")

引数の意味は、次のとおりです。

- appStripeは、権限が配置されるアプリケーション・ストライプを指定します。

- nameは、変更対象の権限の名前を指定します。

- resourceNameは、削除対象のリソースのタイプを指定します。

- resourceTypeは、削除対象のリソースのタイプを指定します。

- actionsは、削除対象のアクションのカンマ区切りリストを指定します。

使用例

次の呼出しでは、ストライプmyApplicationの権限myEntitlementからリソースmyResourceが削除されます。

revokeResourceFromEntitlement -appStripe myApplication
-name myEntitlement
-resourceName myResource
-resourceType myResType
-actions view,edit

9.3.24 listEntitlements

スクリプトlistEntitlementsでは、特定のアプリケーション・ストライプ内のすべての権限がリストされます。リソース名とリソース・タイプが指定されている場合は、指定したタイプで指定したリソース名と一致するリソースを持つ権限がリストされます。このような指定がない場合はアプリケーション・ストライプ内のすべての権限がリストされます。

スクリプト・モード構文

listEntitlements -appStripe appStripeName
[-resourceTypeName resTypeName]
[-resourceName resName]

インタラクティブ・モード構文

listEntitlements(appStripe="appStripeName" [,resourceTypeName="resTypeName", resourceName="resName"])

引数の意味は、次のとおりです。

- appStripeでは、リストされる権限が含まれるアプリケーション・ストライプを指定します。

- resourceTypeNameは、リスト対象のリソースのタイプ名を指定します。オプション。

- resourceNameは、一致が求められるリソースの名前を指定します。オプション。

使用例

次の呼出しでは、ストライプmyApplicationのすべての権限がリストされます。

listEntitlements -appStripe myApplication

次の呼び出しでは、ストライプmyApplicationから、リソース・タイプがmyResTypeでリソース名がmyResNameと一致するすべての権限がリストされます。

listEntitlements -appStripe myApplication
-resourceTypeName myResType
-resourceName myResName

9.3.25 grantEntitlement

スクリプトgrantEntitlementでは、指定したアプリケーション・ストライプに指定したプリンシパルの権限が作成されます。

スクリプト・モード構文

grantEntitlement -appStripe appStripeName
-principalClass principalClass
-principalName principalName
-permSetName entName

インタラクティブ・モード構文

grantEntitlement(appStripe="appStripeName", principalClass="principalClass", principalName="principalName" ,-permSetName="entName")

引数の意味は、次のとおりです。

- appStripeは、権限を作成するアプリケーション・ストライプを指定します。

- principalClassでは、プリンシパルに関連付けられるクラスを指定します。

- nameは、権限が付与されるプリンシパルの名前を指定します。

- permSetNameは、作成する権限の名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationで権限myEntitlementが作成されます。

grantEntitlement -appStripe myApplication
-principalClass oracle.security.jps.service.policystore.ApplicationRole
-principalName myPrincipalName
-permSetName myEntitlement

9.3.26 revokeEntitlement

スクリプトrevokeEntitlementでは、指定したアプリケーション・ストライプで権限が削除され、プリンシパルの権限が取り消されます。

スクリプト・モード構文

revokeEntitlement -appStripe appStripeName
-principalClass principalClass
-principalName principalName
-permSetName entName

インタラクティブ・モード構文

revokeEntitlement(appStripe="appStripeName", principalClass="principalClass", principalName="principalName" ,-permSetName="entName")

引数の意味は、次のとおりです。

- appStripeは、権限が削除されるアプリケーション・ストライプを指定します。

- principalClassでは、プリンシパルに関連付けられるクラスを指定します。

- principalNameは、権限が取り消されるプリンシパルの名前を指定します。

- permSetNameは、削除される権限の名前を指定します。

使用例

次の呼出しでは、ストライプmyApplicationの権限myEntitlementが削除されます。

revokeEntitlement -appStripe myApplication
-principalClass oracle.security.jps.service.policystore.ApplicationRole
-principalName myPrincipalName
-permSetName myEntitlement

9.3.27 listEntitlement

スクリプトlistEntitlementでは、指定したアプリケーション・ストライプの権限がリストされます。プリンシパル名とクラスが指定されている場合は、指定したプリンシパルと一致する権限がリストされ、指定がない場合はすべての権限がリストされます。

スクリプト・モード構文

listEntitlement -appStripe appStripeName
[-principalName principalName
-principalClass principalClass]

インタラクティブ・モード構文

listEntitlement(appStripe="appStripeName" [, principalName="principalName", principalClass="principalClass"])

引数の意味は、次のとおりです。

- appStripeは、権限が配置されるアプリケーション・ストライプを指定します。

- principalNameは、一致が求められるプリンシパルの名前を指定します。オプション。

- principalClassは、一致が求められるプリンシパルのクラスを指定します。オプション。

使用例

次の呼出しでは、ストライプmyApplicationのすべての権限がリストされます。

listEntitlement -appStripe myApplication

9.3.28 listResourceTypes

スクリプトlistResourceTypesでは、指定したアプリケーション・ストライプのすべてのリソース・タイプがリストされます。

スクリプト・モード構文

listResourceTypes -appStripe appStripeName

インタラクティブ・モード構文

listResourceTypes(appStripe="appStripeName")

引数の意味は、次のとおりです。

- appStripeは、リソース・タイプが配置されているアプリケーション・ストライプを指定します。

使用例

次の呼出しでは、ストライプmyApplicationのすべてのリソース・タイプがリストされます。

listResourceTypes -appStripe myApplication

9.3.29 reassociateSecurityStore

スクリプトreassociateSecurityStoreでは、OPSSセキュリティ・ストアがソースからターゲットのLDAPベース・ストアまたはDBベース・ストアに移行され、デフォルトのポリシー・サービスおよび資格証明サービスがターゲット・リポジトリにリセットされます。また、OPSSセキュリティ・ストアを別のドメインのものと共有する指定もできます(後述のオプション引数joinを参照)。OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第L.21項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。

ソースは、ファイルベース、LDAPベース、またはDBベースのストアのいずれでもかまいません。サポート対象のLDAPターゲットのタイプは、Oracle Internet Directoryのみ、DBターゲットの場合はDB_ORACLEのみです。このスクリプトで使用および変更されるのはドメイン構成ファイルjps-config.xmlで、インタラクティブ・モードでのみサポートされます。

再関連付けに関連する推奨事項は、「重要ポイント」を参照してください。DBベース・ストアへの再関連付けの後、オフライン・モードでいずれかのOPSSスクリプトを使用する前に、手動での編集が必要になります。詳細は、「DBベース・ストアへの再関連付け後のオフライン・スクリプトの実行」を参照してください。

インタラクティブ・モード構文

スクリプト構文は、ターゲット・ストアのタイプに応じて若干異なります。

ターゲットが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"[,admin="adminAccnt"] [,password="passWord"][join="trueOrfalse"][)

引数(すべて必須)の意味は、次のとおりです。

- domain: WebLogicでは、再関連付けが行われるドメイン名を指定し、WebSphereではWebSphereセル名を指定します。

- adminでは、LDAPターゲットの場合、ターゲット・サーバーに対する管理者のユーザー名を指定します。形式はcn=usrNameです。
DBターゲットの場合は、DBに、(ユーザー/パスワードで保護される)保護データ・ソースがある場合にのみ必要です。この場合、データ・ソースが作成されたときにデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。

- passwordでは、引数adminに関連付けられているパスワードを指定します。LDAPターゲットの場合にのみ必要です。
DBターゲットの場合は、DBに保護データ・ソースがある場合にのみ必要で、当該の場合は引数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セキュリティ・ストアを指定できるようになります。

重要:

OPSSセキュリティ・ストアとjoin=trueの再関連付けを行う場合は、第1ドメインのブートストラップ・ウォレットを第2ドメインに手動でコピーする必要があります。この要件の理由は、キーストア・データの暗号化に使用されるローカル・キーが第1ドメインで生成され、データを復号化するには第2ドメインのブートストラップ・ウォレットにも同じキーが必要であるためです。

- datasourcenameでは、JDBCデータ・ソースのJNDI名が指定されます。これはデータ・ソース作成時に入力されたJNDI名データ・ソースの値と同じでなければなりません。第8.3.1.3項「データソース・インスタンスの作成」を参照してください。

- keyFilePathでは、ewallet.p12ファイルが作成されるディレクトリを指定します。このファイルの内容は暗号化され、keyFilePasswordに渡される値により保護されます。オプション。引数keyFilePasswordとともに使用します。

- keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。オプション。引数keyFilePathとともに使用します。

使用例

reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")

myDomainとは別のドメイン(otherDomainなど)で、myDomainにあるポリシー・ストアを共有する必要があるとします。その場合は、このスクリプトを次のように呼び出します。

reassociateSecurityStore(domain="otherDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode", join="true")

9.3.30 DBベース・ストアへの再関連付け後のオフライン・スクリプトの実行

DBベース・ストアへの再関連付けによって生成されたjps構成ファイルをそのままオフラインOPSSスクリプトに渡すことはできません。DBベース・ストアへの再関連付け後にOPSSスクリプトをオフライン・モードで実行する前に、次に示すように、構成ファイルを手動で編集する必要があります。

次の例は、DBベースのOPSSセキュリティ・ストアへの再関連付け前後のjps構成ファイルの一部、および再関連付けで生成された構成ファイルに必要な変更を示しています。

再関連付け前

次の部分は、DBベース・ストアへの再関連付け前のファイルベース・ポリシー・ストアの構成を示しています。

<serviceInstance name="policystore.xml" provider="policystore.xml.provider" location="./system-jazn-data.xml">
<description>File Based Policy Store Service Instance</description>
</serviceInstance>

再関連付け後

次の部分は、前述のストアのDBベース・ストアへの再関連付け後に生成されたファイル内のプロパティ・セットprops.db.1を示しています。

<propertySet name="props.db.1">
<property value="cn=soa_domain" name="oracle.security.jps.farm.name"/>
<property value="cn=jpsroot" name="oracle.security.jps.ldap.root.name"/>
<property value="jdbc/opss" name="datasource.jndi.name"/>
</propertySet>

<serviceInstance provider="policystore.provider" name="policystore.db">
<property value="DB_ORACLE" name="policystore.type"/>
<propertySetRef ref="props.db.1"/>
</serviceInstance>

必要な編集

前述のプロパティ・セットを次のプロパティ・セットに置換する必要があります。

<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>

プロパティjdbc.urlの値は、JDBCデータソースの作成時に入力されたデータソースの名前と一致する必要があります。ブートストラップ資格証明(マップとキー)の値は、ブートストラップの作成時にOPSSスクリプトaddBootStrapCredentialに渡された値と一致する必要があります。

この後、編集したファイルをオフライン・スクリプトに渡します。

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

OPSSは、キャッシュ・セキュリティ・アーティファクトによって認可プロセスを最適化します。

アプリケーション・ポリシー(またはその他のセキュリティ・アーティファクト)を変更した場合、アプリケーションおよびアーティファクトの変更に使用されたツールが実行されている場所によって変更が有効になる状況が異なります。

- アプリケーションとツールの両方が同じホスト上および同一ドメインで実行されている場合、変更は即座に有効化されます。

- 同じではなく、アプリケーションとツールが別のホストまたは別のドメインで実行されている場合は、ポリシー・ストア・キャッシュのリフレッシュ後に変更が有効になります。キャッシュのリフレッシュの頻度は、プロパティoracle.security.jps.ldap.policystore.refresh.intervalの値によって決まります。デフォルト値は10分です。

9.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で実施された変更を反映するリフレッシュが行われているためです。

9.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

9.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

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

Oracle Entitlements Serverを使用すると、Oracle Internet Directory LDAPポリシー・ストアを使用するWebLogicドメインでアプリケーション・ポリシーおよびその他のセキュリティ・アーティファクトの管理および検索を実行できます。

詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの次のトピックを参照してください。

- セキュリティ・アーティファクトの問合せ

- ポリシーおよびロールの管理

9.8 ポリシー・ストア構成のガイドライン

OPSSプロパティの調整方法の詳細は、『Oracle Fusion Middlewareパフォーマンスおよびチューニング・ガイド』のOracle Platform Security Servicesの調整に関する項を参照してください。

10 資格証明ストアの管理

資格証明には、ユーザー名、パスワードおよびチケットを格納できます。資格証明は暗号化できます。資格証明は、認証の際、プリンシパルをサブジェクトに移入するときに使用し、さらに認可時には、サブジェクトが実行できるアクションを決定するときに使用します。

Oracle Platform Security Servicesは資格証明ストア・フレームワーク(CSF)を備えています。これは、アプリケーションで資格証明を安全に作成、読取り、更新および管理する際に使用できる一連のAPIです。資格証明ストアは、データベースやLDAPベースのリポジトリなどの外部システムにアクセスするためのユーザー名およびパスワードの格納に使用します。

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

- 資格証明のタイプ

- 資格証明の暗号化

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

- OPSSスクリプトによる資格証明の管理

10.1 資格証明のタイプ

OPSSでは、そこに置かれたデータに応じて次のタイプの資格証明がサポートされています。

- パスワード資格証明には、ユーザー名とパスワードがカプセル化されています。

- 汎用資格証明には、カスタマイズされたデータや、対称鍵などの任意のトークンがカプセル化されています。

CSFでは、資格証明は、マップ名およびキー名によって一意に識別されます。通常、マップ名は、アプリケーションの名前に対応しており、同じマップ名を持つすべての資格証明により、資格証明の論理グループ(そのアプリケーションによって使用される資格証明など)が定義されます。マップ名とキー名のペアは、資格証明ストアにあるすべてのエントリで一意である必要があります。

Oracle Walletはデフォルトのファイルベース資格証明ストアであり、X.509証明書を格納できます。本番環境では通常、Oracle Internet Directory LDAPベースまたはRDBMS DBベースの資格証明ストアを使用します。

10.2 資格証明の暗号化

OPSSでは、ファイルベースおよびLDAPベースの資格証明ストアでの暗号化データの格納がサポートされています(DBベースの資格証明ストアでは、データは常に暗号化されます)。OPSSでは、暗号化鍵を使用して、資格証明ストアでの読み書き時にデータの暗号化と復号化を行います。ファイルベースまたはLDAPベースのストアでの資格証明の暗号化を有効にするには、jps-config.xmlファイルの資格証明ストア・サービス・インスタンスで次のプロパティを設定します。

<property name="encrypt" value="true" />

デフォルトでは、資格証明はクリアテキストで格納されます。

暗号化鍵

前述のプロパティが設定されていると、ドメインの再起動時にOPSSによってランダムな256ビットのAESキーが自動的に生成されます。生成されるキーは毎回異なるため、ドメインは一意の暗号化鍵を使用することになります。最初に生成される暗号化鍵に加え、その他のキー(ロールオーバー・キー)もその後自動的に生成され、データの暗号化と復号化に使用されます。ロールオーバー・キーを取得する唯一の方法は、ドメインを再起動することです。

新しいロールオーバー・キーが生成されても、資格証明ストア内のデータは新しいキーでただちに再暗号化されるわけではありません。データは書き込まれたときにのみ(新しいキーで)再暗号化されます。つまり、すべてのデータが同じ暗号化鍵を使用するようにするには、すべての資格証明を読み取ってから書き込む必要があります。

資格証明ストアを共有するドメイン

2つ以上のドメインが資格証明ストアを共有し、そのストアで暗号化が有効になっている場合、各ドメインは同じ暗号化鍵を使用する必要があります。これは、資格証明ストアのタイプ(LDAPまたはDB)にかかわらず当てはまります。このために、OPSSにはドメイン・ブートストラップ・ウォレット内でキーをエクスポート、インポートおよびリストアするためのオフライン・スクリプトが用意されています。これにより、1つのドメインで生成された暗号化鍵を、資格証明ストアを共有する他のすべてのドメインに引き継ぐことができます。これらのコマンドの詳細は、「OPSSスクリプトによる資格証明の管理」を参照してください。

次のシナリオは、Domain1とDomain2という2つのドメインから構成されるクラスタで資格証明の暗号化を設定する方法を示しています(ドメインが3つ以上がある場合は、各追加ドメインを次の説明にあるDomain2として扱ってください)。

注意:

次のシナリオでは資格証明ストアがLDAPベースであることを前提としていますが、(データが常に暗号化されている)DBベースの資格証明ストアでも、exportEncryptionKeyおよびexportEncryptionKeyを使用してドメイン間でキーをインポートおよびエクスポートできます。

シナリオ1

Domain1はLDAPベースの資格証明ストアに再関連付けされており、Domain2はそのストアにまだ結合していないものとします。そのストア上で資格証明の暗号化を有効にするには、次の手順を実行します。

1. Domain1のjps-config.xmlファイルでencryptプロパティをtrueに設定し、ドメインを再起動します。

2. OPSSスクリプトexportEncryptionKeyを使用して、Domain1のブートストラップ・ウォレットからewallet.p12ファイルにキーを抽出します。スクリプトに渡した引数keyFilePasswordの値は、後でそのキーを別のドメインにインポートするときに使用する必要があります。

3. Domain2のjps-config.xmlファイルでencryptプロパティをtrueに設定します。

その後、この手順は次の2つのいずれかの方法で完了できます。どちらもOPSSスクリプトreassociateSecurityStoreを使用しますが、構文が異なります。このスクリプトの詳細は、第9.3.29項「reassociateSecurityStore」を参照してください。

1つ目の方法は次のとおりです。

1. OPSSスクリプトreassociateSecurityStoreを使用して、Domain2の資格証明ストアをDomain1で使用されている資格証明ストアに再関連付けします。引数joinを使用し、引数keyFilePasswordとkeyFilePathは使用しないでください。

2. OPSSスクリプトimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2のブートストラップ・ウォレットに書き込みます。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じでなければならないことに注意してください。

3. Domain2のサーバーを再起動します。

2つ目の方法は次のとおりです。

1. OPSSスクリプトreassociateSecurityStoreを使用して、Domain2の資格証明ストアをDomain1で使用されている資格証明ストアに再関連付けします。引数join、keyFilePasswordおよびkeyFilePathを使用します。

2. Domain2のサーバーを再起動します。

シナリオ2

Domain1はLDAPベースの資格証明ストアに再関連付けされており、Domain2はそのストアにすでに結合しているものとします。そのストア上で資格証明の暗号化を有効にするには、次の手順を実行します。

1. Domain1のjps-config.xmlファイルでencryptプロパティをtrueに設定し、ドメインを再起動します。

2. OPSSスクリプトexportEncryptionKeyを使用して、Domain1のブートストラップ・ウォレットからewallet.p12ファイルにキーを抽出します。スクリプトに渡した引数keyFilePasswordの値は、後でそのキーを別のドメインにインポートするときに使用する必要があります。

3. Domain2のjps-config.xmlファイルでencryptプロパティをtrueに設定します。

4. OPSSスクリプトimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2のブートストラップ・ウォレットに書き込みます。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じでなければならないことに注意してください。

5. Domain2のサーバーを再起動します。

重要事項:

暗号化が有効になっている資格証明ストアを複数のドメインで共有している場合、これらのドメインのいずれかでロールオーバー・キーが生成されるたびに、管理者はOPSSスクリプトexportEncryptionKeyおよびimportEncryptionKeyを使用して、クラスタ内の他の各ドメインにそのキーをインポートする必要があります。

10.3 資格証明ストアの管理

資格証明をプロビジョニング、取得、変更または削除できるのは、適切な管理ロールのユーザーのみに限られます。次の項では、管理者がFusion Middleware ControlページまたはOPSSスクリプトを使用して資格証明を管理する方法、およびコードからCSF内のデータにアクセスする方法を説明します。

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

この項では、Fusion Middleware Controlを使用して資格証明を管理する方法について説明します。

1. Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「資格証明」(アプリケーションがOracle WebLogic Serverにデプロイされている場合)、または「セル」→「セキュリティ」→「アプリケーション・ポリシー」(WebSphere Application Serverにデプロイされている場合)と移動して、「資格証明」ページを表示します(次の図にページの一部を示します)。

「資格証明ストア・プロバイダ」領域は読取り専用です。それを開くと、ドメインまたはセルで現在使用している資格証明ストア・プロバイダが表示されます。

2. 指定したキー名と一致する資格証明を表示するには、「資格証明キー名」ボックスに一致対象の文字列を入力し、青いボタンをクリックします。検索結果がページの下部の表に表示されます。

3. 項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。資格証明マップを削除すると、そのマップにあるすべてのキーが削除されます。

資格証明マップを作成する手順は、次のとおりです。

1. 「マップの作成」をクリックして、「マップの作成」ダイアログ・ボックスを表示します。

2. このダイアログ・ボックスで、作成する資格証明のマップの名前を入力します。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しい資格証明マップ名が、マップ・アイコンとともに表に表示されます。

資格証明マップにキーを追加する手順は、次のとおりです。

1. 「キーの作成」をクリックして、「キーの作成」ダイアログ・ボックスを表示します。

2. このダイアログで、「マップの選択」メニューから作成しているキーのマップを選択し、「キー」ボックスにキーを入力して、「タイプ」プルダウン・メニューからタイプ(「パスワード」または「汎用」)を選択します。選択したタイプに応じてダイアログの外観が変わります。
「パスワード」を選択した場合は、必須フィールド(「キー」、「ユーザー名」、「パスワード」、「パスワードの確認」)に入力します。

「汎用」を選択した場合は、「キー」必須フィールドに入力し、「テキストとして入力」ラジオ・ボタンを選択して資格証明情報をテキストとして入力するか、「プロパティ名と値のペアのマップを入力」ラジオ・ボタンを選択してキーと値のペアのリストの形式でキーと値のペアを追加します。「行の追加」をクリックして、追加した行にプロパティ名、値、および値の確認を入力します。

図10-1は、パスワード・キーの作成に使用されるダイアログを示しています。

3. 「OK」をクリックして「資格証明」ページに戻ります。新しいキーが、選択したマップに対応するマップ・アイコンの下に表示されます。

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

キーを編集する手順は次のとおりです。

1. 表からキーを選択します。

2. 「編集」をクリックして、「キーの編集」ダイアログを表示します。

3. このダイアログで、必要に応じてキーのデータを変更します。汎用キーを編集する場合は、行の横の赤のXを使用すると、対応するプロパティと値のペアが削除されます。
図10-2は、汎用キーの編集に使用されるダイアログを示しています。

4. 「OK」をクリックして変更内容を保存して、「資格証明」ページに戻ります。

ADFアプリケーションに固有の考慮事項については、Oracle Fusion Middleware Oracle Application Development Framework管理者ガイドのアプリケーションを使用してデプロイする資格証明の編集方法に関する項を参照してください。

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

10.5 OPSSスクリプトによる資格証明の管理

OPSSスクリプトは、Oracle WebLogic ServerのコンテキストではWLSTスクリプトであり、WebSphere Application ServerのコンテキストではWASAdminスクリプトです。この項に記載されたスクリプトは、WebLogic Application ServerとWebSphere Application Serverの両プラットフォームに適用されます。

オンライン・スクリプトとは、実行中のサーバーとの接続が必要なスクリプトです。特に指定がないかぎり、この項に記載されたスクリプトはオンライン・スクリプトで、ベースがファイル、LDAP、DBのいずれであるかにかかわりなくポリシー・ストアで動作します。動作にサーバーの実行を必要としないオフラインのスクリプトもいくつか存在します。

読取り専用スクリプトは、モニター、オペレータ、コンフィギュレータまたはAdminというWebLogicグループに属するユーザーのみが実行できます。読取り-書込みスクリプトは、AdminまたはコンフィギュレータのWebLogicグループに属するユーザーのみが実行できます。WLSTスクリプトはすべて、Oracle WebLogic Serverをインストールすれば、追加設定なしで使用できます。

WLSTスクリプトは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

WASAdminスクリプトは、インタラクティブ・モードでのみ実行できます。詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。

OPSSにはサポートされているすべてのプラットフォームで資格証明の管理に使用できる次のスクリプトが用意されています(特に指定がないかぎりこのスクリプトはすべてオンラインです)。

- listCred

- updateCred

- createCred

- deleteCred

- modifyBootStrapCredential

- addBootStrapCredential

- exportEncryptionKey

- importEncryptionKey

- restoreEncryptionKey

10.5.1 listCred

スクリプトlistCredでは、資格証明ストア内の、指定したマップ名とキー名を持つ資格証明の属性値のリストが返されます。このスクリプトでは、パスワード・タイプの資格証明にカプセル化されたデータのみがリストされます。

スクリプト・モード構文

listCred.py -map mapName -key keyName

インタラクティブ・モード構文

listCred(map="mapName", key="keyName")

引数(すべて必須)の意味は、次のとおりです。

- mapでは、マップ名(フォルダ)を指定します。

- keyでは、キー名を指定します。

使用例

次の呼出しでは、マップ名myMapおよびキー名myKeyを持つ資格証明内のすべての情報(ユーザー名、パスワード、説明など)が返されます。

listCred.py -map myMap -key myKey

10.5.2 updateCred

スクリプトupdateCredでは、資格証明ストア内の、指定したマップ名およびキー名を持つ資格証明のタイプ、ユーザー名およびパスワードが変更されます。このスクリプトでは、パスワード・タイプの資格証明にカプセル化されたデータのみが更新されます。インタラクティブ・モードのみがサポートされます。

インタラクティブ・モード構文

updateCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])

引数(オプションの引数は、大カッコで囲んであります)の意味は、次のとおりです。

- mapでは、資格証明ストアのマップ名(フォルダ)を指定します。

- keyでは、キー名を指定します。

- userでは、資格証明のユーザー名を指定します。

- passwordでは、資格証明のパスワードを指定します。

- descでは、資格証明を説明する文字列を指定します。

使用例

次の呼出しでは、マップ名myMapおよびキー名myKeyを持つパスワード資格証明のユーザー名、パスワードおよび説明が更新されます。

updateCred(map="myMap", key="myKey", user="myUsr", password="myPassw")

10.5.3 createCred

スクリプトcreateCredでは、資格証明ストア内に、指定したマップ名、キー名、ユーザー名およびパスワードの資格証明が作成されます。このスクリプトで作成できるのは、パスワード・タイプの資格証明に限られます。インタラクティブ・モードのみがサポートされます。

インタラクティブ・モード構文

createCred(map="mapName", key="keyName", user="userName", password="passW", [desc="description"])

引数(オプションの引数は、大カッコで囲んであります)の意味は、次のとおりです。

- mapでは、資格証明のマップ名(フォルダ)を指定します。

- keyでは、資格証明のキー名を指定します。

- userでは、資格証明のユーザー名を指定します。

- passwordでは、資格証明のパスワードを指定します。

- descでは、資格証明を説明する文字列を指定します。

使用例

次の呼出しでは、指定したデータでパスワード資格証明が作成されます。

createCred(map="myMap", key="myKey", user="myUsr", password="myPassw")

10.5.4 deleteCred

スクリプトdeleteCredでは、指定したマップ名およびキー名を持つ資格証明が、資格証明ストアから削除されます。

スクリプト・モード構文

deleteCred.py -map mapName -key keyName

インタラクティブ・モード構文

deleteCred(map="mapName",key="keyName")

引数(すべて必須)の意味は、次のとおりです。

- mapでは、マップ名(フォルダ)を指定します。

- keyでは、キー名を指定します。

使用例

次の呼出しでは、マップ名myMapおよびキー名myKeyを持つ資格証明が削除されます。

deleteCred.py -map myMap -key myKey

10.5.5 modifyBootStrapCredential

オフライン・スクリプトmodifyBootStrapCredentialでは、デフォルトのjps contextで構成されているブートストラップ資格証明が変更されます。このスクリプトは通常、次のシナリオで使用されます。ポリシー・ストアおよび資格証明ストアがLDAPベースで、LDAPストア(LDAPサーバーに格納)にアクセスするための資格証明が変更されたとします。このような場合にこのスクリプトを使用すると、ブートストラップ資格証明ストアにそれらの変更をシードできます。

このスクリプトは、インタラクティブ・モードでのみ実行できます。

インタラクティブ・モード構文

modifyBootStrapCredential(jpsConfigFile="pathName", username="usrName", password="usrPass")

引数(すべて必須)の意味は、次のとおりです。

- jpsConfigFileでは、このスクリプトを実行する場所を基準とした相対パスでファイルjps-config.xmlの場所を指定します。

- usernameでは、LDAPストアでのユーザーの識別名を指定します。

- passwordでは、ユーザーのパスワードを指定します。

使用例

LDAPストアで、cn=orcladminという識別名のユーザーのパスワードがwelcome1に変更されたとします。また、構成ファイルjps-config.xmlは現在のディレクトリにあるとします。この場合、次の呼出しでは、ブートストラップ資格証明ストアにあるパスワードがwelcome1に変更されます。

modifyBootStrapCredential(jpsConfigFile='./jps-config.xml', username='cn=orcladmin', password='welcome1')

監査サービスに関する出力は無視してかまいません。

10.5.6 addBootStrapCredential

オフライン・スクリプトaddBootStrapCredentialでは、jps 構成ファイルのデフォルトのjps contextで構成されているブートストラップ資格証明に指定のマップ、キー、ユーザー名、ユーザー・パスワードを持つパスワード資格証明が追加されます。

このスクリプトは、インタラクティブ・モードでのみ実行できます。

インタラクティブ・モード構文

addBootStrapCredential(jpsConfigFile="pathName", map="mapName", key="keyName", username="usrName", password="usrPass")

引数(すべて必須)の意味は、次のとおりです。

- jpsConfigFileでは、このスクリプトを実行する場所を基準とした相対パスでファイルjps-config.xmlの場所を指定します。

- mapでは、追加する資格証明のマップを指定します。

- keyでは、追加する資格証明のキーを指定します。

- usernameでは、追加する資格証明のユーザーの名前を指定します。

- passwordでは、追加する資格証明のユーザーのパスワードを指定します。

使用例

次の呼出しでは、ブートストラップ資格証明ストアに資格証明が追加されます。

addBootStrapCredential(jpsConfigFile='./jps-config.xml', map='myMapName', key='myKeyName', username='myUser', password='myPassword')

10.5.7 exportEncryptionKey

オフライン・スクリプトexportEncryptionKeyは、暗号化鍵をドメインのブートストラップ・ウォレットからewallet.p12ファイルに抽出します。

インタラクティブ・モード構文

exportEncryptionKey(jpsConfigFile="pathName", keyFilePath="dirloc" ,keyFilePassword="password")

引数(すべて必須)の意味は、次のとおりです。

- jpsConfigFileでは、このスクリプトを実行する場所を基準とした相対パスでファイルjps-config.xmlの場所を指定します。

- keyFilePathでは、ewallet.p12ファイルが作成されるディレクトリを指定します。このファイルの内容は暗号化され、keyFilePasswordに渡される値により保護されます。

- keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。このファイルのインポート時には、この同じパスワードを使用する必要があります。

10.5.8 importEncryptionKey

オフライン・スクリプトimportEncryptionKeyは、暗号化鍵をewallet.p12ファイルからドメインのブートストラップ・ウォレットに書き込みます。

インタラクティブ・モード構文

importEncryptionKey(jpsConfigFile="pathName", keyFilePath="dirloc" ,keyFilePassword="password")

引数(すべて必須)の意味は、次のとおりです。

- jpsConfigFileでは、このスクリプトを実行する場所を基準とした相対パスでファイルjps-config.xmlの場所を指定します。

- keyFilePathでは、ewallet.p12が置かれているディレクトリを指定します。

- keyFilePasswordでは、ewallet.p12ファイルの生成時に使用されるパスワードを指定します。

10.5.9 restoreEncryptionKey

オフライン・スクリプトrestoreEncryptionKeyは、最後に使用したキーをブートストラップ・ウォレットにリストアします。

インタラクティブ・モード構文

restoreEncryptionKey(jpsConfigFile="pathName")

引数(必須)の意味は、次のとおりです。

- jpsConfigFileでは、このスクリプトを実行する場所を基準とした相対パスでファイルjps-config.xmlの場所を指定します。

11 キーストア・サービスでのキーと証明書の管理

この章では、キーストア・サービスを使用してキーおよび証明書を管理する方法について説明します。

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

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

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

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

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

OPSSキーストア・サービスでは、SSL、メッセージ・セキュリティ、暗号化および関連タスク用のキーおよび証明書を管理できます。キーストア・サービスは、キー、証明書およびその他のアーティファクトを含むキーストアを作成および管理するために使用します。

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

- キーストアのタイプ

- ドメイン・トラスト・ストア

11.1.1 キーストア・サービスの構造

キーストア・サービスで作成される各キーストアは、アプリケーション・ストライプおよびキーストアによって一意に参照されます。

- アプリケーション・ストライプ
キーストア内に作成されたキーおよび証明書はアプリケーション・ストライプまたは製品内に存在し、ドメイン内の各ストライプには一意の名前が付けられます。

- キーストア
キーストア名はアプリケーション・ストライプ内で一意です。各製品またはアプリケーションは、そのアプリケーション・ストライプ内に複数のキーストアを作成できます。

したがって、(appstripe1, keystoreA)は一意であり、(appstripe1, keystoreB)とも、(appstripe2, keystoreA)とも区別されます。

同様に、各キーストアは、キーストア内で一意の別名によって参照される次のエントリを含むことができます。

- 非対称鍵 - これには公開鍵と対応する秘密鍵が含まれ、通常はSSL通信に使用されます。公開鍵は証明書でラップされています。

- 対称鍵 - これらのキーは通常、暗号化に使用されます。

- 信頼できる証明書 - これらの証明書は通常、SSLピアとの信頼を構築するために使用されます。

11.1.2 キーストアのタイプ

キーストア・サービスでは、次の2つのタイプのキーストアを作成できます。

- 権限によってのみ保護されるキーストア
このタイプのキーストアは認可ポリシーによって保護され、ランタイム・コードによるアクセスはコード・ソース権限によって保護されます。バックエンドのキー・データは、ドメインごとに一意に生成された暗号化鍵を使用して暗号化されます。

- 権限とパスワードの両方によって保護されるキーストア
このタイプのキーストアは、認可ポリシーと、キーストアまたはキー・パスワードあるいはその両方によって保護されます。ランタイム・コードがこれらにアクセスするには、コード・ソース権限およびキーストアとキー・パスワード(キーストア・パスワードと異なる場合)へのアクセスの両方が必要になります。バックエンドのキー・データは、Password Based Encryption (PBE)によりキーストア/キー・パスワードを使用して暗号化されます。

アプリケーションには、権限によって保護されたキーストアを使用することをお薦めします。ただし、高度なセキュリティが必要であり、パスワードの管理をいとわない場合は、パスワードと権限の両方によって保護されるキーストアの使用を検討してください。

注意:

キーストア・サービスでは、キーストアまたはキーに対するパスワードは管理されません。製品またはアプリケーションで、適切なリポジトリ内でパスワードを管理する必要があります。たとえば、アプリケーションに対するパスワードを資格証明ストアに格納することを選択できます。

11.1.3 ドメイン・トラスト・ストア

各アプリケーションではSSL用に複数のキーストアを構成できますが、すべての製品およびアプリケーションに対して、信頼管理用のドメイン・レベルのトラスト・ストアが事前に構成されています。

このドメイン・トラスト・ストアには、一般的に知られているほとんどのサード・パーティ認証局(CA)の信頼できる証明書、およびキーストア・サービスに構成されているデモCAの信頼できる証明書が含まれます。各アプリケーションではSSLに対してこのドメイン・トラスト・ストアを指定でき、このタスク用に専用のトラスト・ストアを作成する必要はありません。

一方向SSL

一方向SSLでは、アプリケーションはドメイン・トラスト・ストアを使用するだけで、キーストアやトラスト・ストアを作成する必要はありません。

双方向SSL

双方向SSLについては、アプリケーションは自身のアイデンティティ証明書を含むキーストアのみを作成する必要があり、信頼にはドメイン・トラスト・ストアを使用します。

注意:

ドメイン・トラスト・ストアは、ドメイン内のすべての製品およびアプリケーションに対する共有ストアです。ドメイン内の他のすべての製品に影響する可能性があるため、信頼の追加または削除に関する決定は慎重に行う必要があります。

カスタム・トラスト・ストアの作成は、ドメイン・トラスト・ストアで製品の信頼管理要件を満たせない場合にのみ検討してください。

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

キーストア・サービスでは、キーストアの作成と管理、証明書のエクスポート、キー・ペアの生成などのキーストア操作に、専用のコマンド・セットを使用します。これらのコマンドの使用方法は似ていますが、他のOPSSコマンドとは異なります。

キーストア・サービス・コマンド・セットを使用するための開始点はgetOpssServiceです。これは次の操作を可能にするOPSSサービス・コマンド・オブジェクトを取得します。

- サービスに対してコマンドを実行する

- コマンド・ヘルプを表示する

一般的な構文は次のとおりです。

variable = getOpssService(name='service_name')

説明

- variableはコマンド・オブジェクトを格納します。

- サービス名は、コマンド・オブジェクトを取得する対象のサービスを指します。有効な値は、KeyStoreServiceのみです。

例:

svc = getOpssService(name='KeyStoreService')

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

キーストア・サービス・コマンドに対するヘルプを表示するには、第11.2項に示したように、サービス・コマンド・オブジェクトの取得から始めます。このオブジェクトを、ヘルプ・コマンドおよび当該のコマンドとともに使用します。

すべてのキーストア・サービス・コマンドのリストを取得するには、次のように入力します。

svc.help()

特定のコマンドに対するヘルプを表示するには、次のように入力します。

svc.help('command-name')

たとえば次のように入力すると、exportKeyStoreコマンドに対するヘルプが表示されます。

svc.help('exportKeyStore')

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

この項では、表11-1に示すキーストア・サービス・コマンドのリファレンスを提供します。

表11-1 キーストア・サービス・コマンド

コマンド

説明

changeKeyPassword

キーに対するパスワードを変更します。

changeKeyStorePassword

キーストアに対するパスワードを変更します。

createKeyStore

新しいキーストアを作成します。

deleteKeyStore

指定されたキーストアを削除します。

deleteKeyStoreEntry

キーストア・エントリを削除します。

exportKeyStore

キーストアをファイルにエクスポートします。

exportKeyStoreCertificate

証明書、信頼できる証明書または証明書チェーンをエクスポートします。

exportKeyStoreCertificateRequest

証明書リクエストを生成してエクスポートします。

generateKeyPair

キーストア内にキー・ペアを生成します。

generateSecretKey

キーストア内に対称鍵を生成します。

getKeyStoreCertificates

証明書または信頼できる証明書に関する情報を取得します。

getKeyStoreSecretKeyProperties

秘密鍵のプロパティを取得します。

importKeyStore

キーストアをファイルからインポートします。

importKeyStoreCertificate

証明書、信頼できる証明書または証明書チェーンをインポートします。

listExpiringCertificates

期限が切れる証明書をリストし、オプションで更新します。

listKeyStoreAliases

キーストア内の別名をリストします。

listKeyStores

ストライプ内のキーストアをリストします。

11.4.1 changeKeyPassword

説明

キーに対するパスワードを変更します。

構文

svc.changeKeyPassword(appStripe='stripe', name='keystore', password='password', alias='alias', currentkeypassword='currentkeypassword', newkeypassword='newkeypassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= パスワードが変更されるキー・エントリの別名。

- currentkeypassword= キーの現在のパスワード。

- newkeypassword= キーの新しいパスワード。

例

svc.changeKeyPassword(appStripe='system', name='keystore', password='password', alias='orakey', currentkeypassword='currentkeypassword', newkeypassword='newkeypassword')

11.4.2 changeKeyStorePassword

説明

キーストアに対するパスワードを変更します。

構文

svc.changeKeyStorePassword(appStripe='stripe', name='keystore', currentpassword='currentpassword', newpassword='newpassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= パスワードが変更されるキーストアの名前。

- currentpassword= キーストアの現在のパスワード。

- newpassword= キーストアの新しいパスワード。

例

svc.changeKeyStorePassword(appStripe='system', name='keystore2', currentpassword='currentpassword', newpassword='newpassword')

11.4.3 createKeyStore

説明

新しいキーストアを作成します。

構文

svc.createKeyStore(appStripe='stripe', name='keystore', password='password',permission=true|false)

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= その中にキーストアが作成されるストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- permission= キーストアが権限によってのみ保護される場合はtrue、権限とパスワードの両方によって保護される場合はfalse。

例

svc.createKeyStore(appStripe='system', name='keystore1', password='password',permission=true)

11.4.4 deleteKeyStore

説明

指定されたキーストアを削除します。

構文

svc.deleteKeyStore(appStripe='stripe', name='keystore', password='password')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= その中のキーストアが削除されるストライプの名前。

- name= 削除するキーストアの名前。

- password= 削除するキーストアのパスワード。

例

svc.deleteKeyStore(appStripe='system', name='keystore1', password='password')

11.4.5 deleteKeyStoreEntry

説明

キーストア・エントリを削除します。

構文

svc.deleteKeyStoreEntry(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= 削除するエントリの別名。

- keypassword= 削除するエントリのキー・パスワード。

例

svc.deleteKeyStoreEntry(appStripe='system', name='keystore2', password='password', alias='orakey', keypassword='keypassword')

11.4.6 exportKeyStore

説明

キーストアをファイルにエクスポートします。

構文

svc.exportKeyStore(appStripe='stripe', name='keystore', password='password', aliases='comma-separated-aliases', keypasswords='comma-separated-keypasswords', type='keystore-type', filepath='absolute_file_path')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- aliases= エクスポートする別名のカンマ区切りリスト。

- keypasswords= 別名に対応するキー・パスワードのカンマ区切りリスト。

- type= エクスポートされるキーストアのタイプ。有効な値は、JKSまたはJCEKSです。

- filepath= キーストアのエクスポート先のファイルの絶対パス。

例

svc.exportKeyStore(appStripe='system', name='keystore2', password='password',aliases='orakey,seckey', keypasswords='keypassword1,keypassword2', type='JKS',filepath='/tmp/file.jks')

11.4.7 exportKeyStoreCertificate

説明

証明書、信頼できる証明書または証明書チェーンをエクスポートします。

構文

svc.exportKeyStoreCertificate(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword', type='entrytype',filepath='absolute_file_path')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= エクスポートするエントリの別名。

- keypassword= キーのパスワード。

- type= エクスポートするキーストア・エントリのタイプ。有効な値は、Certificate、TrustedCertificateまたはCertificateChainです。

- filepath= 証明書、信頼できる証明書または証明書チェーンのエクスポート先のファイルの絶対パス。

例

svc.exportKeyStoreCertificate(appStripe='system', name='keystore2', password='password', alias='orakey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

11.4.8 exportKeyStoreCertificateRequest

説明

証明書リクエストを生成してエクスポートします。

構文

svc.exportKeyStoreCertificateRequest(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword', filepath='absolute_file_path')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= 証明書リクエストの生成元のキー・ペアの別名。

- keypassword= キー・ペアのパスワード。

- filepath= 証明書リクエストのエクスポート先のファイルの絶対パス。

例

svc.exportKeyStoreCertificateRequest(appStripe='system', name='keystore2', password='password', alias='orakey', keypassword='keypassword', filepath='/tmp/certreq.txt')

11.4.9 generateKeyPair

説明

キーストア内にキー・ペアを生成し、それをデモCAによって署名された証明書でラップします。

構文

svc.generateKeyPair(appStripe='stripe', name='keystore', password='password', dn='distinguishedname', keysize='keysize', alias='alias', keypassword='keypassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キー・ペアが生成されるキーストアの名前。

- password= キーストアのパスワード。

- dn= キー・ペアをラップする証明書の識別名。

- keysize= キーのサイズ。

- alias= キー・ペア・エントリの別名。

- keypassword= キーのパスワード。

例

svc.generateKeyPair(appStripe='system', name='keystore2', password='password', dn='cn=www.oracle.com', keysize='1024', alias='orakey', keypassword='keypassword')

11.4.10 generateSecretKey

説明

キーストア内に対称鍵を生成します。

構文

svc.generateSecretKey(appStripe='stripe', name='keystore', password='password', algorithm='algorithm', keysize='keysize', alias='alias', keypassword='keypassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= 対称鍵が生成されるキーストアの名前。

- password= キーストアのパスワード。

- algorithm= 対称鍵アルゴリズム。

- keysize= キーのサイズ。

- alias= キー・エントリの別名。

- keypassword= キーのパスワード。

例

svc.generateSecretKey(appStripe='system', name='keystore2', password='password', algorithm='AES', keysize='128', alias='seckey', keypassword='keypassword')

11.4.11 getKeyStoreCertificates

説明

証明書または信頼できる証明書に関する情報を取得します。

構文

svc.getKeyStoreCertificates(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。
keypassword= キーのパスワード。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= 表示する証明書、信頼できる証明書または証明書チェーンの別名。

例

svc.getKeyStoreCertificates(appStripe='system', name='keystore3', password='password', alias='orakey', keypassword='keypassword')

11.4.12 getKeyStoreSecretKeyProperties

説明

アルゴリズムなどの秘密鍵のプロパティを取得します。

構文

svc.getKeyStoreSecretKeyProperties(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= プロパティを表示する秘密鍵の別名。

- keypassword= 秘密鍵のパスワード。

例

svc.getKeyStoreSecretKeyProperties(appStripe='system', name='keystore3', password='password', alias='seckey', keypassword='keypassword')

11.4.13 importKeyStore

説明

キーストアをファイルからインポートします。

構文

svc.importKeyStore(appStripe='stripe', name='keystore', password='password', aliases='comma-separated-aliases', keypasswords='comma-separated-keypasswords', type='keystore-type', permission=true|false, filepath='absolute_file_path')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- aliases= ファイルからインポートするエントリのカンマ区切りの別名。

- keypasswords= ファイル内のキーのカンマ区切りのパスワード。

- type= インポートされるキーストアのタイプ。有効な値は、JKSまたはJCEKSです。

- filepath= インポートするキーストア・ファイルの絶対パス。

例

svc.importKeyStore(appStripe='system', name='keystore2', password='password',aliases='orakey,seckey', keypasswords='keypassword1, keypassword2', type='JKS', permission=true, filepath='/tmp/file.jks')

11.4.14 importKeyStoreCertificate

説明

証明書、信頼できる証明書または証明書チェーンをインポートします。

構文

svc.importKeyStoreCertificate(appStripe='stripe', name='keystore', password='password', alias='alias', keypassword='keypassword', type='entrytype',filepath='absolute_file_path')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- alias= インポートするエントリの別名。

- keypassword= 新たにインポートするエントリのキー・パスワード。

- type= インポートするキーストア・エントリのタイプ。有効な値は、Certificate、TrustedCertificateまたはCertificateChainです。

- filepath= 証明書、信頼できる証明書または証明書チェーンのインポート元のファイルの絶対パス。

例

svc.importKeyStoreCertificate(appStripe='system', name='keystore2', password='password', alias='orakey', keypassword='keypassword', type='Certificate', filepath='/tmp/cert.txt')

11.4.15 listExpiringCertificates

説明

期限が切れる証明書をリストし、オプションで更新します。

構文

svc.listExpiringCertificates(days='days', autorenew=true|false)

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- days= 期限までの日数がこの日数以下の証明書のみをリストします。

- autorenew= 期限が切れる証明書を自動的に更新する場合はtrue、表示するだけの場合はfalse。

例

svc.listExpiringCertificates(days='365', autorenew=true)

11.4.16 listKeyStoreAliases

説明

キーストア内の特定のエントリ・タイプに対する別名をリストします。

構文

svc.listKeyStoreAliases(appStripe='stripe', name='keystore', password='password', type='entrytype')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアを含むストライプの名前。

- name= キーストアの名前。

- password= キーストアのパスワード。

- type= 別名をリストするエントリのタイプ。有効な値は、Certificate、TrustedCertificate、SecretKeyまたは*です。

例

svc.listKeyStoreAliases(appStripe='system', name='keystore2', password='password', type='Certificate')

svc.listKeyStoreAliases(appStripe='system', name='keystore2', password='password', type='TrustedCertificate')

svc.listKeyStoreAliases(appStripe='system', name='keystore2', password='password', type='SecretKey')

svc.listKeyStoreAliases(appStripe='system', name='keystore2', password='password', type='*')

11.4.17 listKeyStores

説明

ストライプ内のすべてのキーストアをリストします。

構文

svc.listKeyStores(appStripe='stripe')

説明:

- svc= getOpssService()へのコールによって取得したサービス・コマンド・オブジェクト。

- appStripe= キーストアをリストするストライプの名前。

例

svc.listKeyStores(appStripe='system')

svc.listKeyStores(appStripe='*')

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

Oracle Fusion Middleware 11g リリース1 (11.1.1)において、監査はアカウンタビリティを実現する手段であり、また、誰が、いつ、何を行ったかというタイプの質問への回答を提供します。この章では、Oracle Fusion Middlewareにおける監査の概要を説明します。次のトピックが含まれます:

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

- 監査機能の概要

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

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

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

- 監査の目的

- 現在の監査の課題

- Oracle Fusion Middleware 11gの監査フレームワーク

12.1.1 監査の目的

コンプライアンスがビジネス要件の不可欠な要素になりつつある現在、監査のサポートもエンタープライズ・デプロイメントにおける注目の的になりつつあります。顧客は、追加設定なしですぐに使用できる監査サポートを提供するアプリケーション・ベンダーを探しています。また、カスタム・アプリケーションをデプロイするミドルウェアの顧客は、デプロイされる監査が必要な全アプリケーションの監査を集中管理したいと考えています。

IT 組織では、コンプライアンス、監視および分析という要件の観点から、主要な監査機能を探しています。

コンプライアンス

コンプライアンスがエンタープライズにおける主要な要件であることは、明白です。Sarbanes-Oxley法(財務)やHealth Insurance Portability and Accountability Act (HIPAA: 医療保険)のような規制により、多くの顧客は現在、アプリケーションやデバイスで、アイデンティティ情報およびユーザー・アクセスの監査を実行できる必要があります。これらには、次のようなイベントが含まれます。

- ユーザー・プロファイルの変更

- アクセス権の変更

- ユーザー・アクセス・アクティビティ

- 操作アクティビティ(アプリケーションの起動と停止、アップグレード、バックアップなど)

これにより、コンプライアンス担当者は、コンプライアンス・ポリシーを定期的に見直すことができます。

監視

監査データからは通常、監視目的のために、豊富なデータ・セットが得られます。公開されるログ・データおよびコンポーネント・メトリックだけでなく、監査データを使用してダッシュボードを作成したり、アラート用のキー・パフォーマンス・インディケータ(KPI)を設定したりして、様々なシステムの状態を継続的に監視することもできます。

分析

また、監査データを分析し、管理効果を評価することもできます。監査データは、リスク分析にも使用できます。履歴データに基づいてリスク・スコアを計算し、任意のユーザーに割り当てることもできます。ユーザー・アクセスのどのような実行時評価にも、システムに対するアクセスを保護するための追加の基準として様々なリスク・スコアを含めることができます。

12.1.2 現在の監査の課題

監査要件を満たすため、IT組織ではしばしばデプロイされるアプリケーションに対する監査サポートの欠如と闘っています。それは、次の点に対して信頼できる標準が存在していないからです。

- 監査レコードの生成

- 監査レコードのフォーマットと格納

- 監査ポリシーの定義

その結果、現在の監査ソリューションには、次のような多くの大きな問題点があります。

- 集中管理される監査フレームワークがありません。

- 監査サポートの品質がアプリケーションごとにまちまちです。

- 監査データがエンタープライズ全体に散乱しています。

- コンポーネント間の意味のある分析を実行するには、その前に複雑なデータの関係付けが必要となります。

- 監査ポリシーとその構成も散乱しています。

これらの要因により、IT組織は適切な監査ソリューションの構築および維持にかなりの時間とリソースを割いています。データが個々のサイロに散乱していて、一貫性も集中管理もない状態では、様々なベンダーが現時点における独自の監査機能を使用して実現しているアプリケーション間に統一性がなく、監査ソリューションも脆弱になりがちです。

12.1.3 Oracle Fusion Middleware 11gの監査フレームワーク

11gリリース1 (11.1.1)で導入されたOracle Fusion Middleware監査フレームワークは、集中管理された監査フレームワークをミドルウェアの製品ファミリに提供するよう設計されています。このフレームワークは、次のものに対して監査サービスを提供します。

- ミドルウェア・プラットフォーム: これには、Oracle Platform Security Services (OPSS)やOracle Web ServicesなどのJavaコンポーネントが含まれます。これらは、ミドルウェアでデプロイされるアプリケーションによって使用されるコンポーネントです。これらのJavaコンポーネントを使用するデプロイされたアプリケーションはすべて間接的に、プラットフォーム・レベルで発生するイベントを監視する際、監査フレームワークから恩恵を受けることになります。

- Java EEアプリケーション: 目的は、Oracle自体のJava EEベースのコンポーネントをはじめとするJava EEアプリケーションにフレームワークを提供することです。Java EEアプリケーションは、アプリケーションに固有な監査イベントを作成できます。

- システム・コンポーネント: Oracle Process Manager and Notification Serverによって管理されるミドルウェア内のシステム・コンポーネントの場合、監査フレームワークはJavaコンポーネントのエンドツーエンド構造に類似したエンドツーエンド構造も提供します。

関連項目:

『Oracle Fusion Middleware管理者ガイド』のOracle Fusion Middleware主要概念に関する項

12.2 監査機能の概要

Oracle Fusion Middleware監査フレームワークの主要な機能には、次のものがあります。

- 一連のJavaコンポーネント、システム・コンポーネントおよびアプリケーション全体にわたって監査を管理するための統一的なシステム

- 次の機能を含む、Javaコンポーネント監査の広範なサポート

- Oracle Platform Security Servicesによる非監査対応アプリケーションの監査のサポート

- 任意のアプリケーション・レベルでの監査データ検索機能

- 認証履歴および認証失敗、認可履歴、ユーザー管理およびその他の共通トランザクション・データの取得

- 柔軟な監査ポリシー

- 事前生成済の監査ポリシーや顧客でよく使用される監査イベントの取得機能などを利用した、容易なポリシー構成

- ツリー状のポリシー構造による簡便なポリシー設定

- ビルトインのコンプライアンス・レポート作成機能

- Oracle Fusion Middleware監査フレームワークは、Oracle BI Publisherのすぐに使用可能な分析レポート作成機能を提供します。複数のコンポーネントにわたって複数の次元(実行コンテキストID (ECID)やユーザーIDなど)でデータを分析できます。また、これらのレポートをプリファレンスに従ってカスタマイズすることもできます。

- 集中管理された監査データに基づいてレポートを作成します。

- 顧客は、レポートをカスタマイズしたり、公開された監査スキーマに基づいて独自のレポートを作成することができます。
詳細は、第14章「監査分析と監査レポートの使用」を参照してください。

- 監査レコードの格納
監査データ・ストア(データベース)とファイル(バスストップ)を使用できます。すべての監査レコードに共通の場所を維持することにより、管理が容易になります。

監査データ・ストアを使用することにより、Oracle Business Intelligence Publisherを使用したレポートの生成が可能になります。

- 共通の監査レコード・フォーマット
監査証跡は次の特徴を持ちます。

- 結果(ステータス)、イベントの日時、ユーザーなどのベースライン属性

- 認証方式、ソースIPアドレス、ターゲット・ユーザー、リソースなどのイベント固有の属性

- 実行コンテキストID (ECID)やセッションIDなどのコンテキスト属性

- 監査ポリシー構成用の共通のメカニズム
Oracle Fusion Middleware監査フレームワークは、ドメイン内で監査ポリシーを構成するための統一的な手段を提供します。

- Oracle Fusion Middleware 11gのインフラストラクチャの活用

- Oracle Web Services Manager、Oracle Internet Directory、Oracle Virtual Directory、Oracle Directory Integration and Provisioningなど、複数のOracle Fusion Middleware 11gコンポーネントおよびサービス間で使用可能

- Oracle Enterprise Manager Fusion Middleware Controlとの統合により、UIベースの構成と管理が可能

- wlstとの統合により、コマンドラインでのスクリプトベースの構成が可能

- Oracle Platform Security ServicesのSPIインフラストラクチャを活用

- 11gリリース1 (11.1.1)パッチ・セット5から、監査フレームワークへのアプリケーションの統合を可能にする新しい動的メタデータ・モデルを採用

- アプリケーションはいつでも監査サービスに登録が可能

- 監査イベントを定義および記録するために監査フレームワークをアプリケーションが活用する機能を簡素化

- イベント定義のバージョニングを提供し、監査クライアントによるリリース・サイクルに依存しない定義のアップグレードが可能に

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

この項では、Oracle Fusion Middleware監査フレームワークの次の基本概念を説明します。

- 監査アーキテクチャ

- 重要な技術的概念

- 監査メタデータ記憶域

- 監査データ記憶域

- 分析

12.3.1 監査アーキテクチャ

Oracle Fusion Middleware監査フレームワークは、次の主要なコンポーネントから構成されています。

- 監査API
このAPIは、Oracle Fusion Middleware監査フレームワークと統合される監査対応の任意のコンポーネントのために、監査フレームワークによって提供されます。アプリケーションは実行時、これらのAPIを適宜コールして、アプリケーション・コード内で発生する特定のイベントに関して必要な情報を監査する場合もあります。アプリケーションはこのインタフェースにより、監視対象イベントのコンテキストの提供に必要な、ユーザー名やその他属性などのイベント詳細を指定できます。

- 監査フレームワークにより、次のAPIが提供されます。

- 監査サービスAPI

- 監査クライアントAPI

- 監査イベントと構成
Oracle Fusion Middleware監査フレームワークでは、アプリケーションの監査イベントに簡単にマッピングできる一連の汎用イベントが提供されます。それらの汎用イベントには、認証などの共通のイベントも含まれています。また、アプリケーションはこのフレームワークにより、アプリケーションに固有なイベントを定義することもできます。

これらのイベントの定義と構成は、Oracle Platform Security Servicesの監査サービスの一部として実装されます。構成は、Enterprise Manager (UI)およびWLST(コマンドライン・ツール)により更新できます。

- 監査バスストップ
バスストップは、監査データ・レコードが監査データ・ストアにプッシュされる前に格納されるローカル・ファイルです。監査データ・ストアが構成されていない場合、監査データはこれらのバスストップ・ファイルに残ります。バスストップ・ファイルは、問い合せて特定の監査イベントを簡単に見つけることができるシンプルなテキスト・ファイルです。監査データ・ストアが配備されている場合、バスストップはコンポーネントと監査データ・ストア間の中間的な場所として機能します。これらのローカル・ファイルは、構成可能な時間間隔に基づいて、監査データ・ストアに定期的にアップロードされます。

監査データ・ストアの主な利点は、複数のコンポーネントの監査データ(すべてのミドルウェア・コンポーネントやインスタンスにおける認証失敗など)をレポート内で関係付けて結合できる点です。

- 監査ローダー
名前からわかるように、監査ローダー(構成されている場合)は監査バスストップの監査データを監査データ・ストアにロードします。Javaコンポーネントの監査の場合、監査ローダーはコンテナ起動の一部として起動される起動クラスです。システム・コンポーネントの場合、監査ローダーはOPMNによって起動される、定期的に作成されるプロセスです。

- 監査データ・ストア
監査データ・ストアは、リポジトリ作成ユーティリティ(RCU)によって作成される、事前定義済のOracle Fusion Middleware監査フレームワーク・スキーマが含まれるデータベースです。構成が完了すると、すべての監査ローダーが監査データ・ストアを認識し、データを監査データ・ストアに定期的にアップロードします。監査ストア内の監査データは累積されることが想定され、時間の経過に伴って増加します。監査ストアは、他のアプリケーションによって使用される運用データベースではなく、監査専用のスタンドアロン型RDBMSであるのが理想的です。

監査データベースには、Oracleコンポーネントおよび監査フレームワークに統合されたユーザー・アプリケーションによって生成された監査イベントが格納されます。

- 監査メタデータ・ストア
監査メタデータ・ストアには、コンポーネントおよびアプリケーションに対する監査イベント定義が含まれます。

- 監査構成用Mbeans
監査構成はすべて、監査構成用Mbeansによって管理されます。Javaコンポーネントおよびアプリケーションの場合、これらのMbeansはドメイン管理サーバー内に存在し、監査構成は集中管理されます。システム・コンポーネントの場合は、コンポーネント・インスタンスごとに別々のMbeanインスタンスが存在します。Enterprise ManagerのUIおよびコマンドライン・ツールでは、これらのMbeansを使用して、監査構成を管理します。

- Oracle Business Intelligence Publisher
監査データ・ストア内のデータは、Oracle Business Intelligence Publisherの事前定義済のレポートにより公開されます。ユーザーは、これらのレポートにより、様々な基準に基づいて監査データをドリルダウンすることができます。例:

- ユーザー名

- 時間範囲

- アプリケーション・タイプ

- 実行コンテキストID (ECID)

Oracle Business Intelligence Publisherを使用して、独自の監査レポートを作成することもできます。

図12-1 監査イベントのフロー

監査フロー

このプロセスは、アプリケーション・サーバー・インスタンス内で監査可能なイベント(たとえばログイン)が発生した場合に、フレームワーク内で実行されるアクションを示すことにより説明できます。

注意:

図12-1で示したアーキテクチャには、監査データ・ストアが含まれています。監査データ・ストアが構成されていないサイトの場合、監査レコードはバスストップ・ファイル内にあります。

1. アプリケーションのデプロイメント時または監査サービスの起動時に、Java EEアプリケーションまたはOracleコンポーネントなどのクライアントが監査サービスに登録されます。

2. サービスはアプリケーションの事前構成済の監査定義ファイルを読み取り、監査定義でメタデータ・ストアを更新します。

3. ユーザーがそのコンポーネントまたはアプリケーションにアクセスすると、イベントを監査するために監査API関数がコールされます。

4. 監査フレームワークは、このタイプ、ステータス、および特定の属性のイベントを監査する必要があるかどうかを確認します。

5. 監査が必要な場合は監査関数が起動され、監査イベント構造体が作成されて、ステータス、イニシエータ、リソース、ECIDなどのイベント情報が収集されます。

6. イベントは、バスストップとして知られる中間的な場所にあるローカル・ファイルに格納されます。各コンポーネントは個別のバスストップを持ちます。

7. 監査ストアとしてデータベースが構成されている場合、監査ローダーはバスストップからイベントをプルし、アプリケーションのメタデータを使用してデータを書式化し、データを監査ストアに移動します。

8. Oracle BI Publisherを使用して、監査データからレポートを生成することもできます。事前定義済のレポート・セットも使用できます(第14章「監査分析と監査レポートの使用」を参照してください)。

監査が失敗した場合のアプリケーションの動作

アプリケーションは、どのような理由で監査イベントを記録できない場合であっても、実行を中止することはありません。

12.3.2 重要な技術的概念

この項では、Oracle Fusion Middleware監査フレームワークの重要な概念を説明します。

監査対応コンポーネント

監査対応とは、Oracle Fusion Middleware監査フレームワークに統合され、監査ポリシーの構成とイベントの監査が可能なコンポーネントを指します。Oracle Internet Directoryは監査対応コンポーネントの一例です。

スタンドアロン・アプリケーションは、jps-config.xmlファイルを使用して構成を行うことで、Oracle Fusion Middleware監査フレームワークとの統合が可能です。詳細は、第28章を参照してください。

監査メタデータ・ストア

監査メタデータ・ストアには、コンポーネント、および監査フレームワークに統合されたアプリケーションに対する監査イベント定義が格納されます。

監査データ・ストア

監査データ・ストアは、監査イベント・データ用のリポジトリです。

注意:

メタデータ・ストアは監査データ・ストアとは別のものです。

監査ローダー

監査ローダーは、Oracle WebLogic Serverインスタンスのモジュールであり、そのインスタンスに対するプロセス管理を行います。監査ローダーは、そのインスタンス内で実行されているすべてのコンポーネントに対する監査レコードを収集し、監査データ・ストアにロードします。

監査ポリシー

監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

Oracle Fusion Middleware監査フレームワークには、次のようないくつかの事前定義済のポリシー・タイプが用意されています。

- なし

- 低(少数のイベントを監査し、定義はコンポーネントによって異なります)

- 中(多数のイベントを監査し、定義はコンポーネントによって異なります)

- カスタム(監査イベントの範囲を絞るためにフィルタを実装します)

監査ポリシーのコンポーネント・タイプ

監査するコンポーネントのタイプを指します。たとえば、Oracle Internet Directoryは認証時の監査可能イベントのソースになります。

コンポーネントごとに監査可能なイベントのリストは、第C.1項「監査イベント」を参照してください。

イベント・フィルタ

一部の監査イベントには、イベントをログに記録する時点を制御するフィルタが実装されています。たとえば、特定のユーザーのOracle Internet Directoryコンポーネントへの正常なログインのイベントにフィルタを適用できます。

詳細は、第13.3項「監査ポリシーの管理」を参照してください。

Oracle Platform Security Services

Oracle Fusion Middleware 11gの主要コンポーネントであるOracle Platform Security Servicesは、Java Authentication and Authorization Service (JAAS)やJava EEセキュリティなどのJava機能に対応するOracle Fusion Middlewareのセキュリティの実装です。

OPSSの詳細は、第1.1項「Oracle Platform Security Servicesとは」を参照してください。

12.3.3 監査メタデータ記憶域

監査メタデータとは、監査イベント、その属性およびカテゴリに関する情報を指します。

詳細は第28章を参照してください

12.3.4 監査データ記憶域

図12-1に示すように、監査データは2つのタイプの記憶域に配置できます。

- 監査データの中間的な記憶域となるバスストップ・ファイル。各コンポーネント・インスタンスは個別のバスストップにデータを書き込みます。
バスストップ・ファイルは、監査レコード用にすぐに使用できるデフォルトの記憶域メカニズムです。

- Javaコンポーネントの場合は、Oracle WebLogic Serverインスタンスごとに1つのバスストップが存在します。特定のOracle WebLogic Serverインスタンスで実行されるすべてのJava EEコンポーネントに対して生成された監査レコードが、同じバスストップに格納されます。

- システム・コンポーネントの場合は、コンポーネントごとに独立したバスストップが存在します。たとえば、Oracle Internet Directoryの各インスタンスは、個別にバスストップを持ちます。

バスストップ・ファイルはテキストベースで問合せが容易です。詳細は、第12.3.1項「監査アーキテクチャ」を参照してください。

- データベース内の永続的記憶域(監査データ・ストアとも呼ばれます)。
データベースを使用する場合は、ドメイン内のすべてのOracle Fusion Middleware 11gインスタンスのすべてのコンポーネントによって生成された監査レコードが、同じストアに格納されます。Oracle Business Intelligence Publisherレポートを利用するには、監査データ・ストアを使用する必要があります。

ファイルベースの記憶域から監査データ・ストアに移行できます。これには固有の構成手順を実行する必要があります。詳細は、第13.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

データベース・ストアを使用する利点

バスストップ・ファイルに監査レコードを格納する場合、実用面で次のような制限があります。

- ドメイン・レベルの監査データを表示できません。

- Oracle BI Publisherでレポートを実行できません。

一方、データベース監査データ・ストアを使用すると、次のような利点が得られます。

- Oracle Business Intelligence Publisherを使用してレポートを作成できます。

- バスストップでは監査レコードがインスタンス単位で格納されますが、データベース・ストアではドメイン内のすべてのコンポーネントのレコードを集中管理できます。

- ファイルベースの記憶域と比較してパフォーマンスが向上する可能性があります。

このような理由から、オラクル社は、監査機能を拡張するためにデータベース・ストアへの切替えをお薦めします。

12.3.5 分析

Oracle Fusion Middleware 11gでは、構造化レポート作成用のフル機能ツールとしてOracle Business Intelligenceを利用できます。

また、次のような多数の事前定義済レポートも使用できます。

- 作成済ユーザーおよび削除済ユーザー

- ユーザー・トランザクション

- 認証と認可の失敗

- ポリシー違反

Oracle Business Intelligenceの使用

- ユーザー名や日時の範囲などの基準に基づいてレコードを選択できます。
Oracle Business Intelligenceは、データベース監査ストアでのみ機能します。バスストップ・ファイルでは使用できません。

illustration cafintro1.gifの説明

Oracle Business Intelligenceで使用可能な事前定義済監査レポートのタイプは、次のとおりです。

- エラーと例外

- 操作

- ユーザー・アクティビティ

- 認証と認可の履歴

- トランザクション履歴

詳細は、第C.2項「ビルトイン監査レポート」を参照してください。また、監査スキーマの詳細情報を使用して、必要に応じてカスタム監査レポートを作成することもできます。

13 監査の構成と管理

この章では、日常的な監査管理タスクの実行方法を説明します。

関連項目:

Oracle Fusion Middlewareでの監査の予備知識については、第12章「Oracle Fusion Middleware監査フレームワークの概要」を参照してください。

- 監査管理タスク

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

- 監査ポリシーの管理

- 監査ログ

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

13.1 監査管理タスク

監査管理者は、次の手順に従って、サイトの監査の設定を注意深く計画する必要があります。

- 実装の計画
これには、監査レコード用に使用するストアのタイプやデータ・ストアの詳細構成などの計画が含まれます。

詳細は、第13.2項「監査データ・ストアの管理」を参照してください。

- ポリシー管理
管理者は、必要な監査イベントが確実に生成されるように、適切な監査ポリシーを構成する必要があります。

アプリケーション環境の変化やコンポーネントおよびユーザーの追加などを監査ポリシーに反映する必要があるため、ポリシー管理は継続的なアクティビティになります。

詳細は、第13.3項「監査ポリシーの管理」を参照してください。

- レポート管理
これには、監査レポートと監査問合せの計画と構成が含まれます。

詳細は、第14章「監査分析と監査レポートの使用」を参照してください。

- データ管理
これには、企業ポリシーに基づいた、生成される監査データの格納に必要なデータベース・サイズの計画/増加、監査データのバックアップ、監査データの消去が含まれます。

監査データ・ストアの管理の詳細は、第13.5項「データベース・ストアの拡張管理」を参照してください。

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

監査フレームワークでは、追加設定なしですぐに、ファイル・システムを使用して監査レコードを格納します。ただし本番環境では、データベース監査データ・ストアを使用して、監査フレームワークのスケーラビリティと高可用性を確保することをお薦めします。

また、データベース内の監査データ・ストアを使用すると、Oracle Business Intelligence Publisherで使用可能な事前パッケージ済の監査レポートにより監査データを表示することができます。Oracle Business Intelligence Publisherは、11g リリース1 (11.1.1)のCDパックで使用できます。

この項では、監査データ・ストアの次のような管理タスクについて詳細に説明します。

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

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

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

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

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

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

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

監査レコードの永続的ストアとしてデータベースに切り替えるには、最初にリポジトリ作成ユーティリティ(RCU)を使用して監査データ用のデータベース・ストアを作成する必要があります。

注意:

バスストップ・ファイルは、データベース記憶域が存在しない場合の監査レコードの格納先になります。

この項では、監査スキーマの作成方法を説明します。データベース・スキーマの作成後は、次のことが可能になります。

- このスキーマを指し示すデータソースを作成します。

- ドメインの構成を更新し、監査レコードの監査データ・ストアを切り替えます(第13.2.3.2項「監査データ・ストアの構成」を参照)。

注意:

この説明では、RCUおよびデータベースが環境にインストール済であることを前提としています。詳細は、インストレーション・ガイドを参照してください。

開始する前に

作業を開始する前に、使用するデータベースの詳細情報を収集し、DBA資格証明を入手してください。

データベース・スキーマの構成

監査データ・ストア用のスキーマを構成するには、次の手順を実行します。

1. $RCU_HOME/binに移動し、RCUユーティリティを実行します。

2. 開始画面で「作成」を選択します。「次へ」をクリックします。

3. データベースの詳細情報を入力して、「次へ」をクリックします。

4. 接頭辞の新規作成を選択して、IDMなどを入力します。

5. また、スキーマのリストから「監査サービス」を選択します。

6. 「次へ」をクリックして、表領域の作成を承認します。

7. スキーマの作成中にエラーが発生していないか確認します。

このプロセスの完了には数分かかります。

13.2.2 監査データソースの設定

第13.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です。たとえば、接頭辞をtestとした場合、スキーマ名はtest_iauになります。

- パスワード: RCUで作成した監査スキーマのパスワードです。

「次へ」をクリックします。

7. 次のページに、JDBCドライバ・クラスとデータベースの詳細情報が表示されます。デフォルトを選択し、「構成のテスト」をクリックして、接続をテストします。「接続は正常に確立されました」というメッセージが表示されたら、「次へ」をクリックします。エラーが表示された場合は、接続の詳細情報に戻って確認します。

8. 「ターゲットの選択」ページで、このデータソースを構成するサーバーを選択して、「終了」をクリックします。

13.2.2.1 複数のデータソース

スケーラビリティおよび高可用性を実現するために、監査データのOracle Real Application Clustersを構成できます。

詳細は、次を参照してください:

- 『Oracle Fusion Middleware高可用性ガイド』のRACデータベース・ストアを使用した監査の設定に関する項

- 『Oracle Fusion Middleware高可用性ガイド』のWebLogic Serverを使用した監査データ・ソースおよびマルチ・データ・ソースの構成に関する項

- 『Oracle Fusion Middleware高可用性ガイド』の監査ローダー用JDBC文字列の構成に関する項

- 『Oracle Fusion Middleware Oracle WebLogic Server JDBCの構成と管理』のOracle RACとともに使用するWebLogic Serverの使用に関する項

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

スキーマの作成後にデータベース・ベースの監査データ・ストアを構成するには、次の作業を行います。

- 作成した監査スキーマを指し示すデータソースの作成

- データソースを指し示す監査データ・ストアの構成

この項では、監査データ・ストアの構成に関連する次のタスクを説明します。

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

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

注意:

この手順で構成されるのは、Javaコンポーネント用の監査データ・ストアのみです。システム・コンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第13.2.4項「システム・コンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。

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

注意:

このタスクは、Oracle Enterprise Manager Fusion Middleware Controlで実行します。

現在の監査データ・ストアの構成を表示するには、ドメイン→「セキュリティ」→「監査ストア」に移動します。

図audrepos1.gifの説明

このページには、次の項目が表示されます。

- データベースが監査データ・ストアとして構成されているかどうか。デフォルトでは、データベースは構成されておらず、監査レコードはバスストップ・ファイルに格納されています。

- データソースのJNDI名: 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソースのJNDI名が表示されます。監査データ・ストアが構成されていない場合、このフィールドは空になります。

- データソース名: 監査レコード用にデータベース・ストアが構成されている場合は、このフィールドにデータソース名が表示されます。監査データ・ストアがファイルベースである場合、このフィールドは表示されません。

- URL: 監査レコード用にデータベース・リポジトリが構成されている場合は、このフィールドにデータソースのURL(データベースへの接続に使用される接続文字列)が表示されます。監査データ・ストアがファイルベースである場合、このフィールドは表示されません。

データソースの例は、第13.2.2項「監査データソースの設定」を参照してください。

13.2.3.2 監査データ・ストアの構成

監査レコードをファイルに格納する方式からデータベース監査データ・ストアを使用する方式に変更できます。

監査データ・ストアを構成するには、次の手順を実行します。

1. ドメイン→「セキュリティ」→「監査ストア」に移動します。「監査ストア」ページが表示されます。

2. 「データソースのJNDI名」フィールドの横にあるサーチライトのアイコンをクリックします。

3. ダイアログ・ボックスが表示され、ドメイン内で監査レコード用に使用可能なデータソースのリストが表示されます。目的のデータソースを選択して、「OK」をクリックします。

4. 選択されたデータソースが「データソースのJNDI名」フィールドに表示されます。「適用」をクリックして続行するか、「元に戻す」をクリックして更新を中止します。

注意:

監査データ・ストアの設定は、WLST setAuditRepository()コマンドを使用して変更することもできます。詳細は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

5. ドメイン内のすべてのOracle WebLogic Serverを再起動します。これにより、Oracle WebLogic Server内の起動クラス監査ローダーが構成を再度読み込むことができます。

6. 変更は、監査ポリシーでイベント収集のテストを設定することによってテストできます。たとえば、Oracle Platform Security Servicesの監査ポリシーを「中」に設定することもできます。詳細は、第13.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。

7. 監査によって監査イベントが生成されるように、シナリオを実行します。たとえば、ステップ6で構成したポリシーに基づき、資格証明の作成によって監査レコードがトリガーされます。

8. サーバー・ログ内のエラーおよび例外をチェックします。

- $DOMAIN_HOME/jrfServer_admin.outをチェックします。

- $DOMAIN_HOME/servers/$SERVER_NAME/logs/をチェックします。

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

データベースは監査レコードの推奨ストアであるため、データベースからファイル・モードへの切替えはお薦めできません。ただし、第13.3.4項「監査ポリシーの手動による管理」では、audit.repositoryTypeというプロパティの値をFileに設定することで、ファイルに格納する方式に切り替えることができると説明されています。

注意:

Fusion Middleware ControlやWLSTを使用してデータベースからファイル・モードに切り替えることはできません。この切替えを実現するには、第13.3.4項「監査ポリシーの手動による管理」で説明するように、手動による構成が必要です。

データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。

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

Oracle Process Manager and Notification Server (OPMN)は、Oracle WebLogic Server内で実行されるいくつかのシステム・コンポーネントを管理します。これらのコンポーネントの場合、ローカルなバスストップ・ファイルからデータベース監査データ・ストアに監査イベントがプッシュされるメカニズムは、OPMNによって処理されます。

注意:

システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアを、すべてのインスタンスがレコードを該当ストアにプッシュするよう構成する必要があります。

監査データ・ストアを構成するには、コンポーネントの各インスタンスで、次の手順を実行する必要があります。

注意:

この手順で構成されるのは、システム・コンポーネント用の監査データ・ストアのみです。Javaコンポーネント用の監査データ・ストアを構成するには、別の手順が必要です。第13.2.3項「Javaコンポーネント用のデータベース監査データ・ストアの構成」を参照してください。

同じデータベースでJavaコンポーネントとシステム・コンポートの両方の監査レコードを格納するように構成することによって、両方のタイプのコンポーネントのレポートを一緒に表示することができます。

1. 次の場所にあるopmn.xmlファイルを開きます。

$ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml

2. 次のようなrmd-definitions要素を見つけます。

<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/jdbc/lib/ojdbc5.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. ファイルを保存し、終了します。

5. ORACLE_HOME、ORACLE_INSTANCEおよびCOMMON_COMPONENTS_HOMEが定義されていることを確認します。例:

ORACLE_HOME = /u01/oracle/as11_oh
ORACLE_INSTANCE = /u01/oracle/instances/instance
COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common

6. 監査データ・ストアのパスワードをシークレット・ストアに移入します。これは、RCUで監査スキーマを作成する際に指定したパスワードです。

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/jdbc/lib/ojdbc5.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に適切な値を入力します。

注意:

前述の構文は、Linuxの場合の構文です。Windowsの場合は、クラスパス内のjarを区切る":"を";"に置換します。

7. 次のようにしてOPMNをリロードします。

$ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits)
$ORACLE_INSTANCE/bin/opmnctl reload

8. 監査対象コンポーネントでなんらかのシナリオを実行して、監査イベントを生成します。

9. $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.outにアップロードされるエラーとイベントを確認します。この出力は次の例のようになります。

8/08/26 10:54:24 global:AuditLoader

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

データベースは監査レコードの推奨ストアなので、データベースからファイル・モードへの切替えはお薦めできません。ただし、必要であれば、opmn.xmlファイルを使用して監査データ・ストアを構成する前述のタスクで示したものと同じ手順により、RMDの定義を更新し、監査データ・ストアの構成を解除することもできます。rmd-definitions要素を見つけ、監査ローダーの既存のRMD定義を置き換えます。

注意:

システム・コンポーネントがクラスタ化されたデプロイメント内で実行される場合は、コンポーネントの各インスタンスにある監査データ・ストアの構成を解除する必要があります。

- jdbcString: データベースJDBC接続文字列をデフォルト文字列jdbc:oracle:thin:@host:port:sidに戻します。

- interval: デフォルト値31536000に戻します。

ファイルを保存して終了し、OPMNをリロードします。

13.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コンポーネントのバスストップ・ファイルの最大サイズを制御します。

第13.3.4項「監査ポリシーの手動による管理」でも説明されていますが、このサイズはバイト単位で指定します。

システム・コンポーネント

ファイル記憶域モードのファイルのサイズは、auditconfig.xmlファイル内で設定できます。第13.3.4.4項「システム・コンポーネント用の監査の手動構成」を参照してください。

注意:

監査データをファイルからデータベース・ストアに切り替えると、監査ファイルに収集されたすべてのイベントがデータベース表にプッシュされ、監査ファイルが削除されます。

ディレクトリ・サイズ

Javaコンポーネント

ファイルのディレクトリのサイズは、構成ファイルjps-config.xmlで示されているmax.DirSizeプロパティを使用して管理できます。このプロパティは、バスストップ・ディレクトリの最大サイズを制御します。

第13.3.4項「監査ポリシーの手動による管理」でも説明されていますが、このサイズはバイト単位で指定します。

システム・コンポーネント

ファイル記憶域モードのディレクトリのサイズは、auditconfig.xmlファイル内で設定できます。第13.3.4.4項「システム・コンポーネント用の監査の手動構成」を参照してください。

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

図12-1に示すように、共通監査フレームワークの監査ローダーは、レコードをバスストップ・ファイルから監査データ・ストアに移動します。監査ローダーを駆動するメカニズムは、アプリケーション環境に応じて変わります。

- Oracle WebLogic ServerにデプロイされたJava EEコンポーネントおよびアプリケーションでは、アプリケーション・サーバーによって提供された監査ローダー機能を使用します。

- システム・コンポーネントおよび非Javaアプリケーションでは、Oracle Process Manager and Notification Server (OPMN)によって提供された監査ローダー機能を使用します。

- アプリケーション・サーバー・コンテナの外部で実行されたJava SEアプリケーションでは、スタンドアロン監査ローダーを使用します。

この項では、スタンドアロン監査ローダーの設定および実行方法を説明します。

- 環境の構成

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

13.2.6.1 環境の構成

スタンドアロン監査ローダーを実行する前に、a) 特定のプロパティの構成、およびb) データベース・スキーマ・ユーザーのパスワードがシークレット・ストアに存在することの確認を行う必要があります。

13.2.6.1.1 プロパティの構成

次のプロパティを構成する必要があります。

- ORACLE_HOME環境変数

- COMMON_COMPONENTS_HOME環境変数

- ORACLE_INSTANCE環境変数

- auditloader.jdbcStringシステム・プロパティ

- auditloader.usernameシステム・プロパティ

13.2.6.1.2 データベース・スキーマ・ユーザーのパスワード記憶域

データベース・スキーマ・ユーザーのパスワードは、シークレット・ストアに格納されます。パスワードの格納は、StandAloneAuditLoaderコマンドを-Dstore.password=trueオプション付きで使用する1回かぎりの操作です。

次のようにStandAloneAuditLoaderコマンドを発行してパスワードを格納します。

$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:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/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.instance=$ORACLE_INSTANCE
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid
-Dauditloader.username=username
-Dstore.password=true
oracle.security.audit.ajl.loader.StandaloneAuditLoader

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

次のようにStandAloneAuditLoaderコマンドを発行して監査レコードをロードします。

$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:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/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

監査レコードを監査データ・ストアに定期的にアップロードするように、バッチ・ジョブまたはkronジョブによってこのコマンドをスケジュールできます。

13.3 監査ポリシーの管理

監査ポリシーとは

監査ポリシーとは、特定のコンポーネントの監査フレームワークによって取得されるイベントのタイプの宣言です。Javaコンポーネントの場合、監査ポリシーはドメイン・レベルで定義されます。システム・コンポーネントの場合、監査ポリシーはコンポーネント・インスタンス・レベルで管理されます。

たとえば、監査ポリシーでは、Oracle Internet Directoryインスタンスに対するすべての認証の失敗を監査するように指定することができます。

ポリシーの構成方法

Oracle Fusion Middleware監査フレームワークを使用すると、監査ポリシーを構成し、監視対象のイベントおよびデータのタイプをきわめて詳細に制御することができます。ポリシーは、Enterprise ManagerのUIツールおよびWLSTコマンドライン・インタフェースを使用して構成できます。

ポリシーの変更にはサーバーまたはインスタンスの再起動は不要です。

この項の残りの部分では、監査ポリシーの表示および更新方法を説明します。

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

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

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

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

関連項目:

- 補足的な予備知識については、第12.3.2項「重要な技術的概念」を参照してください。

- Javaコンポーネントおよびシステム・コンポーネントのリストは、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

- サード・パーティのアプリケーション・サーバー上での監査コマンドの実行の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

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

ドメインの「監査ポリシー設定」ページでは、Oracle Identity FederationなどのすべてのJavaコンポーネントの監査イベントと、Oracle Platform Security Servicesなどのシステム・ライブラリの監査イベントを管理します。

注意:

- システム・コンポーネントの監査ポリシーは、該当するコンポーネントのホーム・ページで管理されます。第13.3.2項「Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理」を参照してください。

- 第13.3項「監査ポリシーの管理」の最初にある「ポリシーの変更にはサーバーまたはインスタンスの再起動が必要」というタイトルの注意を参照してください。

関連項目:

監査可能なコンポーネントのリストは、第C.1.1項「監査可能なコンポーネント」を参照してください。

各コンポーネントとそのイベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。

現在構成されている監査ポリシーを表示および更新するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 左側のトポロジ・パネルを使用して、「WebLogicドメイン」の下の目的のドメインに移動します。

3. ドメイン・メニューから、「ドメイン」→「セキュリティ」→「監査ポリシー設定」とナビゲートします。「監査ポリシー設定」ページが表示されます。

4. 事前構成済監査レベルのドロップダウン・リストを選択できます。2つの事前定義済レベル(「低」、「中」)では、すべてのコンポーネントの監査イベントのサブセットを自動的に選択します。ほとんどの場合は、事前定義済のレベルで十分です。

注意:

事前定義済レベルについて、ドロップダウン・ボックスの下のイベントの表を編集することはできません。カスタム・レベルでの編集のみが可能です。

- なし: 監査対象のイベントは選択されません。

- 低: 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。

- 中: 「低」のイベント・セットのスーパーセットです。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。

- カスタム: このレベルではポリシーを微調整できます。後述のステップ5を参照してください。

次の表は、ドメイン内で実行中のアプリケーションを示しています。

表は、次の列から構成されています。

- 名前: ドメイン内のコンポーネントとアプリケーションが表示されます。

- 監査の有効化: 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。

- フィルタ: イベント・タイプで有効なフィルタが表示されます。

5. 監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより、すべてのイベントを選択するか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択することができます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用でき、後述のステップ6に示すように、監査方法をより詳細に制御できます。

6. フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。

アイコンをクリックし、「フィルタの編集」ダイアログを表示します。

注意:

各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。

7. 「障害のみ選択」ボタンをクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。

8. インポート/エクスポート: これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。

9. 必要に応じ、ユーザーのカンマ区切りリストを「常に監査するユーザー」で指定することで、これらのユーザーが開始したイベントを監査フレームワークで監査できるようになります。これにより、指定した監査レベルやフィルタに関係なく監査が行われます。

注意:

- この機能を使用して、システム管理者などの主要ユーザーを監査するようにした場合は、そのユーザーがどのコンポーネントの監査可能イベントに関与しても監査トラフィックが発生します。たとえば、コンポーネントの監査ポリシーが「なし」に設定されている場合もありますが、該当するユーザーがコンポーネント・インスタンス内のアクティビティを実行すると、それも監査の対象となります。

- このフィールドに入力するユーザー名に対する検証は行われません。

10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。Javaコンポーネントの場合、この変更を有効にするには、管理対象Oracle WebLogic Server(影響を受けるJavaコンポーネントが実行されている)を再起動する必要があります。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。

コンポーネント・イベントについて

ドメイン内の各コンポーネントおよびアプリケーションでは、監査可能なイベントの独自のセットを定義します。そのため、表の「名前」列を開くと、コンポーネントごとにそのコンポーネントのインスタンスに適用されるイベントのリストが表示されます。

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

この項では、OPMNを使用して管理されるシステム・コンポーネントの監査ポリシーを表示および更新する方法を説明します。

注意:

- Javaコンポーネントの監査ポリシーは、ドメイン・コンテキスト内で管理されます。第13.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」を参照してください。

- 第13.3項「監査ポリシーの管理」の最初にある「ポリシーの変更にはサーバーまたはインスタンスの再起動が必要」というタイトルの注意を参照してください。Oracle Internet Directoryインスタンスの場合、再起動は不要です。

システム・コンポーネントの監査ポリシーは、それぞれのホーム・ページで管理されます。ドメインの「監査ポリシー設定」ページでは、ドメイン内で実行されるJavaコンポーネントの監査イベントを管理します。

関連項目:

監査可能なコンポーネントのリストは、第C.1.1項「監査可能なコンポーネント」を参照してください。

イベントは、「名前」列にツリー構造で表示されます。ツリーを開くと、使用できるイベントの詳細が表示されます。

OPMN管理コンポーネントの監査ポリシーを表示および更新するには、次の手順を実行します。

1. Fusion Middleware Controlにログインします。

2. 左側のトポロジ・パネルを使用して、Oracle Internet Directoryなど、目的のシステム・コンポーネントに移動します。

3. コンポーネント・メニューから、「セキュリティ」→「監査ポリシー」とナビゲートします。「監査ポリシー設定」ページが表示されます。

4. 事前構成済監査レベルのドロップダウン・リストを選択できます。2つの事前定義済レベル(「低」、「中」)では、すべてのコンポーネントの監査イベントのサブセットを自動的に選択します。

注意:

事前定義済レベルについて、ドロップダウン・ボックスの下のイベントの表を編集することはできません。カスタム・レベルでの編集のみが可能です。

- なし: 監査対象のイベントは選択されません。

- 低: 小さなイベント・セットが選択され、通常これらによるコンポーネント・パフォーマンスへの影響は最小限に抑えられます。

- 中: 「低」のイベント・セットのスーパーセットです。これらのイベントは、コンポーネント・パフォーマンスにより大きな影響を与えます。

- カスタム: このレベルではポリシーを微調整できます。後述のステップ5を参照してください。

次の表は、コンポーネント・インスタンスに対して監査できるイベントを示しています。この例は、Oracle Internet Directoryの場合です。

表は、次の列から構成されています。

- 名前: タイプ別にまとめられたコンポーネント・イベント(認可イベントなど)が表示されます。

- 監査の有効化: 対応するイベント・タイプが監査されるかどうかが表示されます。「カスタム」監査ポリシーが無効な場合、この列はグレー表示されます。

- フィルタ: イベント・タイプで有効なフィルタが表示されます。

5. 監査ポリシーをカスタマイズするには、ドロップダウンの「カスタム」オプションを使用します。これにより、すべてのイベントを選択するか、「監査の有効化」列の関連するボックスを選択することにより、必要に応じて適切なサブセットを手動で選択することができます。「カスタム」レベルを選択した場合、個々のイベント結果(成功および失敗)に対してオプションのフィルタを使用でき、後述のステップ6に示すように、監査方法をより詳細に制御できます。

6. フィルタは、監査対象のイベントの選択やフィルタ処理のために定義できる、ルールベースの式です。式は、イベントの属性に基づきます。たとえば、ログイン・タイプのイベントでは、ユーザー・フィルタとしてイニシエータを指定できます。そのような場合、イベントは、指定されたユーザーがログインするたびに監査レコードを生成します。
鉛筆のアイコンは、該当するイベントでフィルタを使用できることを示します。

アイコンをクリックし、「フィルタの編集」ダイアログを表示します。

注意:

各フィルタ属性には、正式名と表示名があります。フィルタの編集ダイアログには、いずれかの名前が表示されます。表示名はドロップダウンに表示され、正式名は編集ダイアログに表示されます。たとえば、ドロップダウン・ボックスで「Client Address IP」を選択した場合、これをフィルタ式に追加すると、名前が「RemoteIP」に変更されます。

7. 「障害のみ選択」をクリックして、ポリシー内の失敗したイベント(失敗した認証など)のみを選択します。これで、失敗したイベントに対して「監査の有効化」ボックスが選択されます。

8. インポート/エクスポート: これらのボタンにより、ポリシー構成を保存し、再度使用することができます。ポリシーの編集の際、いつでも「エクスポート」をクリックして現在の設定をファイルに保存したり、「インポート」をクリックして保存したファイルから設定をロードすることができます。

9. オプションで、「常に監査するユーザー」の下にあるユーザーのカンマ区切りリストを指定し、監査フレームワークでこれらのユーザーによって起動されたイベントを監査するようにすることができます。監査は、指定された監査レベルやフィルタに関係なく行われます。

注意:

- この機能を使用して、システム管理者などの主要ユーザーを監査するようにした場合は、そのユーザーがどのコンポーネントの監査可能イベントに関与しても監査トラフィックが発生します。たとえば、コンポーネントの監査ポリシーが「なし」に設定されている場合もありますが、該当するユーザーがコンポーネント・インスタンス内のアクティビティを実行すると、それも監査の対象となります。

- このフィールドに入力するユーザー名に対する検証は行われません。

10. ポリシーを変更した場合、「適用」をクリックしてその変更を保存します。
ポリシーの変更を取り消し、既存のポリシーに戻すには、「回復」をクリックします。

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

この項では、Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーの表示や更新を実行する方法を説明します。

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

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

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

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

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

注意:

WLSTの監査コマンドを実行するには、Oracle共通ホームからWLSTスクリプトを呼び出します。詳細は『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

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

WLSTを使用した監査ポリシーを表示するには、次の手順を実行します。

注意:

ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびWLSTを起動する際の様々なオプションの詳細は、『Oracle Fusion Middleware管理者ガイド』のWebLogic Scripting Tool (WLST)の使用方法の概要に関する項を参照してください。

- 次のコマンドを使用して、WebLogicサーバーに接続します。

java weblogic.WLST
connect('servername', 'password', 'localhost:portnum')

- getAuditPolicyコマンドを使用して、監査ポリシーの構成を表示します。例:

wls:/mydomain/serverConfig> getAuditPolicy()

- システム・コンポーネントの場合:

- getNonJava EEAuditMBeanNameコマンドを使用してMBean名を取得します。詳細は、第C.4.1項「getNonJava EEAuditMBeanName」を参照してください。

- getAuditPolicyコマンドを使用してMBean名を含め、監査ポリシーの構成を表示します。例:

wls:/mydomain/serverConfig> getAuditPolicy
(on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")

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

Oracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して監査ポリシーを更新するには、次の手順を実行します。

注意:

ここでは、WLSTをインタラクティブに起動するものとします。WLSTの詳細およびWLSTを起動する際の様々なオプションの詳細は、『Oracle Fusion Middleware管理者ガイド』のWebLogic Scripting Tool (WLST)の使用方法の概要に関する項を参照してください。

- 次のコマンドを使用して、WebLogicサーバーに接続します。

java weblogic.WLST
connect('servername', 'password', 'localhost:portnum')

- Bean階層を移動し、目的のドメインにアクセスします。たとえば、ドメインがmydomainという名前の場合は、次のようになります。

wls:/mydomain/serverConfig>

- setAuditPolicyコマンドを使用して、監査ポリシーの構成を更新します。

- ポリシーをローカルで管理するコンポーネントの場合は、setAuditPolicyコマンドを使用し、MBean名を含めると、監査ポリシーの構成が更新されます。

- setAuditPolicyコマンドまたはimportAuditConfigコマンドを発行した後、saveを明示的にコールします。
saveを呼び出さないと、新しい設定が有効になりません。

このコールの例については、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』のWLSTを使用した監査の管理に関する項を参照してください。このコールによるOracle Internet Directoryの監査が具体的に説明されています。

関連項目:

監査用のWLSTコマンドの詳細は、WLSTコマンド・リファレンスを参照してください。

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

このシナリオでは、ドメインの現在のポリシーにより、user1というユーザーが監査されています。ここでは、常に監査されるユーザーのリストにuser2およびuser3という2つの名前を追加し、user1をリストから削除します。

このタスクは、setAuditPolicyを次のように起動して実行します。

setAuditPolicy
(filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")

関連項目:

第C.4.3項「setAuditPolicy」

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

このシナリオでは、ドメインの現在のポリシーにより、ユーザーのログアウト・イベントが監査されています。ここでは、ポリシーからログアウト・イベントを削除し、ログイン・イベントを監査するようにします。

このタスクは、setAuditPolicyを次のように起動して実行します。

注意:

この例では、Oracle HTTP Serverのコンポーネント・タイプOHSを使用します。コマンドの使用時に、適切なコンポーネント・タイプに置き換えてください。

setAuditPolicy
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")

イベントを追加および削除するには、Customフィルタを事前設定する必要があることに注意してください。

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

カスタム・レベルで監査を構成しているときに、WLSTを使用して別の(カスタムではない)監査レベルに切り替えても、明示的にそれらのカスタム監査設定を削除しないかぎり、そのカスタム監査設定は保持されます。

注意:

この動作は、WLSTを使用している場合にのみ得られます。Fusion Middleware Controlを使用して監査の構成を管理している場合は、カスタム監査レベルから別の監査レベルに切り替えると、カスタム監査の設定はクリアされます。

この動作を示す例は、次のとおりです。

1. カスタム監査レベルはコンポーネントのポリシーに対して設定します。構成の過程で監査フィルタを指定します。

2. 実行時には、指定したフィルタに従って監査データが収集されます。

3. WLSTコマンドのsetauditpolicyを使用して、コンポーネントの監査ポリシーをカスタム監査レベルから、たとえば低い監査レベルに変更したとします。しかし、カスタム監査レベルの中で設定したフィルタは監査構成にそのまま残ります。

4. 監査データの収集は、カスタム・レベルではなく、低い監査レベルに基づいています。

5. コンポーネントの監査ポリシーはカスタム・レベルに戻されます。別のフィルタが追加され、元々構成されているフィルタに追加されます。元のフィルタを明示的に削除しないかぎり、このフィルタは構成の中で保持されます。

6. 実行時には、効力があるすべてのフィルタに基づいてカスタム・レベルで監査データが収集されます。

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

この項では、次のファイルを手動で更新することによって監査ポリシーなどの機能を構成する方法について説明します。

- プラットフォーム構成ファイルjps-config.xml: Javaコンポーネントの場合

- コンポーネントに固有のファイル: システム・コンポーネントの場合

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

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

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

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

- システム・コンポーネント用の監査の手動構成

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

jps-config.xmlドメイン構成ファイルは、次の場所にあります。

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

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

jps-config.xml内の監査サービス構成は、表F-9に示すプロパティで構成されています。一連のプロパティとその値は、まとめて監査ポリシーと呼ばれています。

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">
<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.maxDirSize" value="102400" />
<property name="audit.maxFileSize" value="10240" />
<property name=" audit.loader.repositoryType " value="Db" />
</serviceInstance>
</serviceInstances>
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="audit"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

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

まれに、監査レコードへの(データベース)データ・ストアの使用を、ファイルの使用に戻すことが必要になる場合もあります。その場合は、表F-9に記載されているプロパティaudit.loader.repositoryTypeを手動で構成する必要があります。

データベースからファイルに切り替えるには、audit.loader.repositoryTypeをFileに設定します。

データベースからファイルに切り替えると、データベースに収集されたイベントは、ファイル・システムに再転送されることはありません。この切替えが一時的な場合、ファイルに収集された監査イベントは、データベース・ストアに再度切り替える際、データベースに自動的にプッシュされます。

13.3.4.4 システム・コンポーネント用の監査の手動構成

システム・コンポーネントでは、監査構成の格納にjps-config.xmlファイルを使用しません。かわりに次のようにします。

- Oracle HTTP Serverの場合は、次の場所にあるauditconfig.xmlファイルを使用します。

ORACLE_INSTANCE/instance_name/config/OHS/<ohs_name>/auditconfig.xml

- Oracle Web Cacheの場合は、次の場所にあるauditconfig.xmlファイルを使用します。

ORACLE_INSTANCE/instance_name/config/WebCache/<webcache_name>/auditconfig.xml

- Oracle Reportsの場合は、次の場所にあるjps-config-jse.xmlファイルを使用します。

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

- Oracle Virtual Directoryの場合は、次の場所にあるjps-config.-jse.xmlファイルを使用します。

ORACLE_INSTANCE/instance_name/config/JPS/jps-config-jse.xml

- Oracle Internet Directoryの監査構成は、データベースに格納されます。

auditconfig.xmlファイルの形式

auditconfig.xmlファイルの形式は次のとおりです。

<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd">
<Filters>
<!-- FilterPreset can be None,Low,Medium,All or Custom.  Default value: None -->
<FilterPreset>Low</FilterPreset>

<!-- Comma separated list of special users for whom auditing is always turned on. Default value: no users -->
<SpecialUsers>u1,u2</SpecialUsers>

<!-- In case of custom, a comma separate list of events that are to be enabled for auditing. Default value: no events -->
<CustomEvents>e1,e1</CustomEvents>

</Filters>
<LogsDir>

<!-- Maximum dir size of the log directory (busstop). 0 implies unlimited size. Default value: 0 -->
<MaxDirSize>0</MaxDirSize>

<!-- Maximum file size of each audit.log file. Default value: 100MB -->
<MaxFileSize>104857600</MaxFileSize>

</LogsDir>
<AuditConfig>

13.4 監査ログ

Fusion Middleware監査フレームワークでは、監査管理に役立つように、一連のログ・ファイルを提供しています。それらのログを使用すると、監査フレームワークが正しく機能しないときに、エラーをトレースしたり、診断を行うことができます。

この項には次のトピックが含まれます:

- 監査ログの場所

- 監査ログのタイムスタンプ

13.4.1 監査ログの場所

すべての監査ログの場所のリスト、ロガーの構成方法およびログによる問題の診断方法は、第L.1.1.6項「監査ロガー」を参照してください。

13.4.2 監査ログのタイムスタンプ

監査ログのタイムスタンプは、協定世界時で記録されます。これは、マシンのタイムゾーンの設定によっては、マシン時間と異なる場合があります。

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

監査スキーマは、リポジトリ作成ユーティリティ(RCU)によって作成されます。この項では、監査スキーマの編成について説明し、スキーマの管理に関するトピックについて説明します。

関連項目:

RCUの詳細は、『Oracle Fusion Middleware Repository Creation Utilityユーザーズ・ガイド』を参照してください。

13.5.1 スキーマの概要

Oracle Fusion Middleware監査フレームワークのスキーマは、次のものから構成されています。

- 実表: IAU_BASE

- 変換表: IAU_DISP_NAMES_TL

- 監査データから構成される、コンポーネントに固有な一連の表(OVDCOMPONENT、OIDCOMPONENT、JPSなど)

監査レコードは生成時、1つのファイルに格納されます。監査データベース・ストアが構成されていると、監査ローダーは各監査レコードを実表の1つの行およびコンポーネント表の1つの行に格納します。

- 一般的な情報(Time、EventType、EventStatusなど)は、実表に書き込まれます。

- コンポーネントに固有な情報(CodeSourceなど)は、コンポーネント表に書き込まれます。

注意:

レコードが格納されるコンポーネント表は、バスストップ・ファイル内の属性ComponentTypeによって決定されます。

監査ローダーは格納時、すべてのレコードに一意な連番を割り当てます。

Oracle Platform Security Servicesのバスストップ・ファイルの次に例を示します。デフォルトでは、このファイルは次のディレクトリ内に保持されます。

WebLogic Domain Home/servers/server_name/diagnostics/auditlogs/JPS/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" - "[]" - - - -

図13-1は、実表内のデータと、それがコンポーネントに固有な表にどのように関係しているのかを示しています。

図13-1 監査スキーマ

実表IAU_BASEの平均的なレコード・サイズは、約0.3 KBです。表領域のサイズを計画する際は、次のようにしてください。

- この数値を、平均的なレコード・サイズのガイドラインとして使用してください。

- 選択した監査ポリシーおよびアクティビティのレベルに基づいて、監査データベースのサイズが増加する様子を監視してください。

- 監査データの格納期間を考慮してください。

13.5.2 表の属性

実表およびコンポーネントに固有な表の属性はそれぞれ、次のファイルから派生しています。

- $ORACLE_HOME/modules/oracle.iau_11.1.1/components/generic/generic_events.xml

(実表用)

- $ORACLE_HOME/modules/oracle.iau_11.1.1/components/componentName/component_events.xml

(各コンポーネント表用)

表13-1に、実表IAU_BASEで定義されている重要な属性をいくつか示します。最初の4つの属性は、その実表とすべてのコンポーネント表に共通する属性です。主キーは、IAU_ID + IAU_TSTZORIGINATINGと定義されます。

関連項目:

第C.3項「監査スキーマ」

表13-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.4項「監査のためのWLSTコマンド」

- 第C.3項「監査スキーマ」

13.5.3 索引スキーム

問合せを効率よく実行できるように、デフォルトでは、実表およびコンポーネントに固有の各表のタイムスタンプ(IAU_TSTZORIGINATING)に対して索引が作成されます。

デフォルトの索引は、IAU_BASEの場合はEVENT_TIME_INDEX、コンポーネント表の場合はtableName_INDEX(OVDCOMPONENT_INDEX、OIDCOMPONENT_INDEX、JPS_INDEXなど)です。

13.5.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は、時間が経過しても変化しないため、バックアップの実行は一度だけで十分です。

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

複数の監査データベースで開始した後、それらのデータベースを結合して単一の監査データ・ストアを構築する場合や、データベースを変更して規模を拡張する場合は、監査スキーマのインポートおよびエクスポートを実行して、データを移行することができます。

Oracle Databaseサイトでは、Oracle Data Pumpのユーティリティを使用してデータのインポートおよびエクスポートを実行できます。詳細は、次のサイトを参照してください。

http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html

13.5.6 パーティション化

すべてのデータベース・システムでパーティション化がサポートされているわけではなく、監査スキーマ内の表は、デフォルトではすべてパーティション化されていません。

監査データは累積され、古いデータが削除されることはありません。そのため、大量の監査データを格納する場合は、監査スキーマのパーティション化を考慮し、アーカイブ処理を容易にする必要があります。

パーティション化には、次のような利点があります。

- パフォーマンスの向上: 表がタイムスタンプでレンジ・パーティション化されていると、たとえばタイムスタンプによる問合せを処理できるのは、該当する時間枠内のパーティションのみとなります。

- 管理性の向上: パーティションを、個別の表領域(つまり、異なるディスク)に作成できます。そのため、比較的古いデータは比較的遅くて大きなディスクに移動し、比較的新しいデータは比較的高速で小型のディスクに保持することができます。
また、パーティション化により、アーカイブ処理もはるかに容易になります。たとえば、表全体をパーティション化することなく、単一のパーティションを圧縮することができます。

- 可用性の拡張: 単一のパーティションが使用できない場合、たとえば問合せでそのパーティションを処理対象から外しても問題がないことが判明しているのであれば、使用できないパーティションを待つことなく、問合せを正常に処理することができます。

13.5.6.1 パーティション表

ここの例では、IAU_BASEを例として使用し、監査スキーマ内のパーティション化されていない表をパーティション化された表に変換する方法を示します。

アプリケーションの停止時間を最小化するため、監査データ・ストアにこのスキーマを使用する前にパーティション化を実行することをお薦めします。

注意:

この製品には、サンプルのSQLスクリプトが2つ含まれています。

- $RCU_HOME/rcu/integration/iau/scripts/convertPartitionedTables.sql(linux)または%RCU_HOME\rcu\integration\iau\scripts\convertPartitionedTables.sql(Windows)は、監査スキーマ内の実表およびコンポーネント表をパーティション化された表に変換します。

- $RCU_HOME/rcu/integration/iau/scripts/createPartitionsByQuarter.sql(linux)または%RCU_HOME\rcu\integration\iau\scripts\createPartitionsByQuarter.sql(Windows)は、監査スキーマ内の実表およびコンポーネント表に対し、四半期別のパーティションを作成します。

パーティション化の手順は、次のとおりです。

注意:

パーティション化を実行する前に監査ローダーを非アクティブ化するようお薦めします。詳細は、第13.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;

注意:

新しい四半期別に合わせて定期的に、新しいパーティションを作成する必要があります。

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

バックアップとリカバリについては、第13.5.4項「バックアップとリカバリ」を参照してください。バックアップ・コピーが作成されているかぎり、データベースのバックアップ全体から読取り専用の表領域を除外することができます。そのため、それらの表領域上に存在するアーカイブ・データのパーティションに対するバックアップを反復的に実行する必要がなくなり、パフォーマンスが向上します。

13.5.6.3 データのインポート、エクスポート、消去

インポートとエクスポートについては、第13.5.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');

パーティションを作成したら、特定のパーティションの消去およびバックアップを実行できます。詳細は、データベースのドキュメントを参照してください。

データベース・モードの場合、バスストップ・ファイルは監査ローダーによって自動的に管理されます。

13.5.6.4 階層アーカイブ

パーティション化により、それぞれのパーティション(またはパーティションのグループ)を、記憶域の様々な層に格納できます。表領域を高パフォーマンスまたは低コストのディスクに作成し、データの値またはその他の基準に基づいて様々な表領域にパーティションを作成できます。また、パーティション内のデータを表領域(記憶域の層)間で移動することも容易です。

次に例を示します。

ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008
TABLESPACE AUDITARCHIVE UPDATE INDEXES;

注意:

パーティションは、範囲、リスト、システムおよびハッシュのパーティション化スキームでのみ移動できます。

Oracle Information Lifecycle Management (ILM) Assistantというフリーのツールを使用すると、表をパーティション化する方法を知ることができ、パーティションを移動する時期についての助言が得られます。詳細は、次のサイトを参照してください。

http://www.oracle.com/technology/deploy/ilm/index.html

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

この章では、監査レポートの構成方法と表示方法について説明します。次のトピックが含まれます:

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

- 監査レポートの編成

- 監査レポートの表示

- Oracle Business Intelligence Publisherレポートの例

- 監査レポートの詳細

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

14.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

14.1.1 Oracle Business Intelligence Publisherについて

HIPPAやSOXなどの各種業界規制やその他の規制に対するコンプライアンス要求に関して、管理者が違反の有無を確認する際には、レポートが役立ちます。Oracle Fusion Middleware監査フレームワークは、Oracle Business Intelligence Publisherに統合され、すぐに使用可能なレポートを提供しています。

Oracle Fusion Middleware監査フレームワークの一部として、事前定義済のレポートを使用できます。これらのレポートは、Oracle Business Intelligence Publisherに統合されており、監査ストア内の監査データとともに機能します。

11g リリース1 (11.1.1)において、Oracle Fusion Middleware監査フレームワークには、20を超えるビルトイン・レポートが含まれています。便宜上、それらのレポートはOracle Business Intelligence Publisher内で機能領域に従い、コンポーネント別にグループ化されています。

機能領域には、次のものがあります。

- エラーと例外に関するレポート(認証と認可の失敗など)

- ユーザー・アクティビティ(トランザクション履歴や認可履歴など)

- 運用に関するレポート(作成済、削除済、ロックアウトされたユーザーなど)

- 監査サービス・イベント

Oracle HTTP ServerレポートやOracle Identity Federationレポートなど、コンポーネント固有レポートは、名前からわかるように、コンポーネント自体に基づいてグループ化されます。

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に関するトラブルシューティングのヒントおよびその他の有用な情報は、第L.18項「Oracle Business Intelligenceレポート作成のトラブルシューティング」を参照してください。

- 次のサイトのOracle Business Intelligence Publisher Enterpriseドキュメント
http://www.oracle.com/technology/documentation/bi_pub.html

Oracle Business Intelligence Publisherで使用可能なすべての監査レポートには、次のようなレポートのフィルタ処理オプションとフォーマット・オプションが用意されています。

- ビュー: 現在のパラメータを使用してレポートを表示します。

- スケジュール: レポートのスケジュールをジョブ・パラメータとデータ・フィルタとともに設定します。

- 履歴

- 編集: 問合せとパラメータ表示フォーマットを変更します。

- 構成: ランタイムの構成制御を設定します。

- エクスポート

14.1.2 Oracle Business Intelligence Publisherのインストール

サイトにOracle Business Intelligence Publisher 10.1.3.4以降がインストールされている場合は、この項を省略して、第14.1.3項「Oracle Business Intelligence PublisherでのOracle Reportsの設定」に進んでください。

Oracle Business Intelligence Publisherをインストールする必要がある場合は、Oracle Business Intelligence PublisherのCompanion CDに示されている手順に従ってください。

関連項目:

次のサイトのOracle Business Intelligence Publisher Enterpriseドキュメント

http://www.oracle.com/technology/documentation/bi_pub.html

14.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のスキーマでのみ機能します。11g リリース1 (11.1.1)などの古いバージョンのスキーマでは機能しません。

パッチ・セット・アシスタントを使用したスキーマのアップグレードの詳細は、『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_11.1.1/reports/
AuditReportTemplates.jar

3. 次のようにして、監査リポジトリのデータソースを設定します。

- 「管理」タブに移動します。

- ステップ1でOracle WebLogic Serverをデプロイした場合は、次のようにしてJNDIを設定します。

- 「JNDI接続」をクリックします。

- 「データソースの追加」をクリックします。

- データソースの詳細を指定します。
データソースにはAuditという名前を付けます。

注意:

レポートは監査データソースを参照するため、命名規則は重要です。

JNDI名: jdbc/AuditDB。

- 接続が正常かどうかをテストします。接続が正常でない場合は、入力した値を確認します。

- 「適用」をクリックして変更を保存します。

- ステップ1でOracle Containers for Java EEをデプロイした場合は、次のようにしてJNDIを設定します。

- 「JDBC接続」をクリックします。

- 「データソースの追加」をクリックします。

- データソースの詳細を指定します。
データソースにはAuditという名前を付けます。

注意:

レポートは監査データソースを参照するため、命名規則は重要です。

監査スキーマのURL、ユーザー名およびパスワードの詳細情報を入力します(注意: ユーザー名とパスワードは接頭辞が含まれる監査スキーマ名から構成され、たとえばユーザー名はdev_iauやtest_iauのようになります)。

- 接続が正常かどうかをテストします。接続が正常でない場合は、入力した値を確認します。

- 「適用」をクリックして変更を保存します。

14.1.4 監査レポート・テンプレートの設定

標準の監査レポートをデフォルトの形式でそのまますぐに使用することができます。ただし、レポートの外観やその他の関連する側面をカスタマイズする場合は、監査レポート・テンプレートを設定します。

レポートの「編集」ダイアログで、左側のパネルの「レイアウト」オプションをクリックすると、レイアウトと出力フォーマットを管理できます。この機能を使用して、次の操作を実行できます。

- レポート・テンプレートのカスタマイズと独自のレイアウトの設計。たとえば、フィールドの再配置や選択したフィールド・ラベルの強調表示ができます。

- レポート出力を生成するフォーマットの制限。デフォルトでは、HTML、PDF、Excelスプレッドシート、RTFなどの多数の出力フォーマットが使用可能になっています。

関連項目:

『Oracle Business Intelligence Publisherユーザーズ・ガイド』

14.1.5 監査レポート・フィルタの設定

標準の監査レポートをデフォルトの形式でそのまますぐに使用することができます。ただし、レポートのデータの範囲やその他の関連する側面をカスタマイズする場合は、監査レポート・フィルタを設定します。

Oracle Business Intelligence Publisherは、監査レポートに基本と詳細の両方のフィルタリング・オプションを提供します。

関連項目:

『Oracle Business Intelligence Publisherユーザーズ・ガイド』

基本フィルタ

レポートの「スケジュール」ボタンをクリックして表示されるページでは、スケジュールを使用してレポートを管理できます。

「レポート・パラメータ」領域では、レポートを制限する次のような高水準のフィルタを指定できます。

- 日付フィルタ

- 直前の1時間や先週など、最近の監査レコードのみを表示します。

- 指定した開始および終了日付の間に生成されたレコードを表示します。

- 返されるレコードの数を制限します。

- 選択されたレポート・フィールド
たとえば、認証失敗レポートは、次の項目でフィルタ処理できます。

- ユーザー名

- コンポーネント・タイプ

- コンポーネント名

- アプリケーション名

- ドメイン名

詳細フィルタ

レポートの「編集」ボタンをクリックして表示されるページでは、さらに詳細なレポート・フィルタおよびプロパティを指定できます。該当ページは、次の2つのパネルから構成されています。左のパネルを使用すると、それらのオプションによって変更するレポートの要素を選択できます。選択した要素ごとに、対応する情報が右のパネルに表示されます。

- データ・モデル: レポートの生データをフェッチするSQL問合せが含まれます。この問合せは、ニーズに合せて変更できます。

- 値リスト: レポートのすべての列が表示されます。列を選択すると、属性のデータをフィルタ処理する、基盤となるSQL問合せが表示されます。問合せは、必要に応じて変更できます。たとえば、制限がさらに厳格なフィルタ値も指定できます。

- パラメータ: レポートのすべての列が表示されるので、列を選択し、その列の表示値を変更できます。たとえば、タイムスタンプ・フィールドの日付の表示形式も指定できます。

- レイアウトと出力フォーマット: この機能については、第14.1.6項「Oracle Business Intelligence Publisherのスケジューラの構成」を参照してください。

14.1.6 Oracle Business Intelligence Publisherのスケジューラの構成

レポートの「スケジュール」ボタンをクリックして表示されるページでは、スケジュールを使用してレポートを管理できます。このページでは、次の情報を指定できます。

注意:

この機能では、Oracle Business Intelligence Publisherリポジトリが構成済であることを前提としています。

- レポート・パラメータ: レポートに含まれるデータをフィルタ処理して制限します。たとえば、直前の1時間のレコードのみに制限できます。

関連項目:

第14.1.5項「監査レポート・フィルタの設定」

- ジョブ・プロパティ: ジョブ名、フォーマット・ロケール、タイムゾーンなどです。

- 通知: ジョブが完了または失敗したときに電子メールで通知する1人以上のユーザーです。

- 時間: レポートのスケジューリング・オプションです。レポートの定期的な実行や1回かぎりの実行をスケジュールできます。

- 配信: 1人以上のユーザーにレポートを配信します。

14.2 監査レポートの編成

Oracle Fusion Middleware監査フレームワークには、追加設定なしですぐにOracle Fusion Middlewareコンポーネントと連携できるように設計された一連の事前定義済レポートが添付されています。これらのレポートは、次の2つの主なカテゴリに分類されます。

- 共通レポート
これらのレポートは、認証の成功と失敗、アカウント関連のステータス(ロックアウト、無効など)のような共通のイベントを取得します。このような共通のイベントに対する監査機能は、多くのコンポーネントに実装されています。共通レポートは監査レポートの「共通レポート」サブフォルダにあり、一連のコンポーネントからのすべての監査対応のイベントはこれらのレポートに格納されます。

たとえば、「認証履歴」には、認証イベントが取得される全コンポーネントの認証履歴が表示されます。

これらのレポートを使用すると、コンポーネント間の特定領域について監査レコードを調査したり、その特定領域に対し、複数のコンポーネントにわたる単一ユーザーの監査レコードをチェックすることができます。

- コンポーネント固有レポート
これらのレポートは、個々のコンポーネントを重視しています。すべての監査イベントが各コンポーネントに関連しているとはかぎらないため、これらのレポートが必要となります。「コンポーネント固有」フォルダには、2つの目的があります。第1に、コンポーネントに関連し、そのコンポーネントの監査レコードのみを表示する共通レポートの中から有効なレポートを特定します。第2に、一部のコンポーネントでは、該当するコンポーネントの特定のニーズに合うように、コンポーネントに固有なレポートが定義されています。監査レコード自体がすべてのコンポーネントに対して汎用的である一方、監査レコードの表現にはコンポーネントに固有な要件がある可能性があります。たとえば、アクセス・ポリシーを、有用となる形式で示す必要がある場合もあります。

たとえば、全コンポーネントの認証イベントが表示される「共通」フォルダに、認証履歴レポートを配置することができます。また、同じレポートが、該当するコンポーネントの認証イベントのみが表示されるコンポーネントに固有なフォルダに存在する場合もあります。

- また、最上位には「すべてのイベント」という汎用的なレポートが存在し、このレポートでは監査対応の全コンポーネントのすべてのイベントが表示されます。「すべてのイベント」レポートは、それぞれのコンポーネント固有フォルダでも使用でき、各コンポーネントの全イベントを表示することができます。
このレポートは、監査データの問合せにも使用できます。

14.3 監査レポートの表示

この項では、Oracle Business Intelligence Publisherを使用して監査レポートを表示する方法を説明します。

監査レポートを表示するには、次の手順を実行します。

1. 次の形式のURLを使用して、Oracle Business Intelligence Publisherにログインします。
http://host.domain.com:port/xmlpserver/

2. メイン・ページで、共有フォルダの「Oracle Fusion Middleware監査」をクリックします。

3. 監査レポートは、次の2つに分類されます。

- 複数のコンポーネントに共通のレポート。さらにレポート・タイプ別に分類されます。

- 単一のコンポーネントに固有なレポート。さらにコンポーネント別に分類されます。

関連項目:

標準的なレポートの説明は、表14-1を参照してください。

4. 目的のレポートに移動します。たとえば、共通レポート→エラーと例外→「すべてのエラーと例外」をクリックします。
レポートが表示されます。

5. レポート表示ページには、次の主要な領域があります。

- ページ上部にあるフィルタ。フィルタを使用して、レポートに含めるレコードのタイプ、範囲および数を決定できます。このようなフィルタには、次のものがあります。

- ユーザー

- 開始日と終了日

- 最後のn回

- コンポーネントのタイプと名前

- アプリケーション名

- ドメイン名

適切なフィルタを使用し、目的のレコードに限定してレポートを作成してください。

注意:

レポートは、初期状態ではデフォルトのフィルタ値を使用して表示されます。このデフォルト値は変更可能です。

- フォーマット制御ボタン。これにより、次の内容を決定できます。

- テンプレート・タイプ。次の選択肢があります。
HTML: デフォルトの表示形式です。

PDF: 印刷可能なPDFビューが表示されます。

データ: フォーマットされていないXMLデータセットが表示されます。

レポートの表示中にテンプレート・タイプを変更するには、ドロップダウン・リストからテンプレート・タイプを選択し、「表示」をクリックします。

- 出力フォーマット

- 配信オプション

- レポートのレコード表示領域。この領域の外観と列数は、その前に選択されたオプションとフィルタによって異なります。
各列ヘッダーはソート・オプションとしても機能します。

6. 必要に応じてレポートを表示、保存またはエクスポートします。

14.4 Oracle Business Intelligence Publisherレポートの例

この項では、一般的なシナリオを使用して、Oracle Platform Security Servicesのイベントによって生成された監査データを、Oracle Business Intelligence Publisherレポートで表示する方法を示します。

この例では、Oracle WebLogic Serverドメインの資格証明ストア上でいくつかのアクティビティが生成されます。その後、Oracle Business Intelligence Publisherを使用して関連レポートを表示し、監査レコードを確認します。その後で、その他のいくつかのレポートを調査します。

1. システム管理者として、資格証明が管理対象になっているドメインを検索します。

2. 関連コマンドを使用して、資格証明管理レコードをいくつか生成します。例として、いくつかのユーザー資格証明の作成と削除を実行します。

関連項目:

資格証明管理の詳細は、第10.3項「ドメイン資格証明ストアの管理」を参照してください。

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. 「詳細」をクリックすると、詳細情報が表示されます。

14.5 監査レポートの詳細

この項では、標準的な(ビルトイン)監査レポートに関する詳細なリファレンス情報を示します。

標準的な監査レポートは、次のように分類されます。

1. 「すべてのイベント」レポート
このレポートには、事前定義済の時間間隔で生成されたすべての監査レコードが含まれます。

2. 共通レポート
これらは、複数のコンポーネントにわたる監査レコードが含まれるレポートです。

3. コンポーネント固有レポート
どのレポートも、特定の1つのコンポーネント専用です。

共通レポート

共通レポートには次のようなものがあります。

- アカウント管理

- アカウント・プロファイル履歴

- 削除済アカウント

- 有効化されたアカウント

- 無効化されたアカウント

- 作成されたアカウント

- ロック・アウトされたアカウント

- パスワード変更

- ダッシュボード

- ユーザー・アクティビティ

- 認証履歴

- 同じIPの複数ログイン

- 認可履歴

- イベント詳細

- 関連監査イベント

- ダッシュボード

- エラーと例外

- すべてのエラーと例外

- 認可失敗

- 認証失敗

- ダッシュボード

重要:

11gリリース1 (11.1.1.4.0) PS3(パッチ・セット3)のスキーマに対してのみ「イベント詳細」レポートを実行します。

コンポーネント固有レポート

レポートのリストは、第C.2.2項「コンポーネント固有の監査レポート」を参照してください。

14.5.1 Oracle Business Intelligence Publisherの監査レポートのリスト

表14-1に、Oracle Business Intelligence Publisherの各監査レポートの簡単な説明を示します。

注意:

「格納先フォルダ」という列に示されるフォルダ・パスは、「Oracle Fusion Middleware監査」フォルダを基準としています。このフォルダにアクセスするには、Oracle Business Intelligence Publisherにログインした後、「共有フォルダ」→Oracle Fusion Middleware監査に移動します。

表14-1 監査レポートのリスト

レポート

説明

格納先フォルダ

作成されたアカウント

各種コンポーネントで作成されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

削除済アカウント

各種コンポーネントで削除されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

無効化されたアカウント

各種コンポーネントで無効化されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

有効化されたアカウント

各種コンポーネントで有効化されたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

ロック・アウトされたアカウント

認証の失敗が多すぎるためにロック・アウトされたアカウントが表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

アカウント・プロファイル履歴

アドレスやパスワードの変更など、アカウントにおけるプロファイルの変更が表示されます。

共通レポート→「アカウント管理」。および「コンポーネント固有」フォルダ。

すべてのエラーと例外

コンポーネント間にわたるすべてのエラーと例外が取得されます。

共通レポート→エラーと例外。および「コンポーネント固有」フォルダ。

すべてのイベント

すべての監査イベントが表示されます。

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」→「ポリシー管理」。

14.5.2 Oracle Business Intelligence Publisherの監査レポートの属性

表14-2に、各種監査レポートに表示される属性のリストを示します。レポートを表示する際は、この表を使用すると、レポートに表示される属性の詳細がわかります。

次の点に注意してください。

- 各レポートにすべての属性が表示されるとはかぎりません。

- 各レポートに表示されるユーザーまたはユーザー属性は、レポートごとに異なる意味を持つ場合があります。この属性の説明は、表14-1を参照してください。

- Oracle Business Intelligence Publisher監査レポートにすべての属性が表示されるとはかぎりません。カスタム・レポートに属性を追加する場合は、付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」を参照してください。

表14-2 監査レポートの属性

属性

説明

アクティビティ

アクションのタイプ(ユーザーによって起動されたか、システムによって起動されたか)

アプリケーション名

アプリケーションの完全なパスと名前。

Application Serverインスタンス

使用中のApplication Serverのインスタンス

試行済

試行されたアクション(ユーザーによって試行されたシングル・サインオンなど)

コンポーネント名

コンポーネント・インスタンスの名前

コンポーネント・タイプ

コンポーネントのタイプ(Oracle Identity Federationなど)

ドメイン名

Oracle WebLogic Serverのドメイン名。

ECID

実行コンテキストID

イベント・タイプ

発生したイベントのタイプ(アカウントの作成など)

イニシエータ

イベントを起動したユーザー

インターネット・プロトコル・アドレス、IPアドレス

アクション起動元ユーザー・マシンのIPアドレス

メッセージ・テキスト

メッセージのテキスト、イベントの説明

ポリシー名

アクションに関与するポリシーの名前

時間範囲

この時間範囲を使用すると、データセットを特定の時間間隔(最後の24時間など)に限定することができます。

タイムスタンプ

イベントの日付と時刻

トランザクションID

トランザクションの識別子

14.6 監査レポートのカスタマイズ

この項では、拡張レポートの生成および作成オプションについて説明します。

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

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

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

レポートの「編集」ボタンをクリックして表示されるページでは、さらに詳細なレポート・フィルタおよびプロパティを指定できます。該当ページは、次の2つのパネルから構成されています。左のパネルを使用すると、それらのオプションによって変更するレポートの要素を選択できます。選択した要素ごとに、対応する情報が右のパネルに表示されます。

- データ・モデル: レポートの生データをフェッチするSQL問合せが含まれます。この問合せは、ニーズに合せて変更できます。

- 値リスト: レポートのすべての列が表示されます。列を選択すると、属性のデータをフィルタ処理する、基盤となるSQL問合せが表示されます。問合せは、必要に応じて変更できます。たとえば、制限がさらに厳格なフィルタ値も指定できます。

- パラメータ: レポートのすべての列が表示されるので、列を選択し、その列の表示値を変更できます。たとえば、タイムスタンプ・フィールドの日付の表示形式も指定できます。

- レイアウトと出力フォーマット: この機能については、後述の項で説明します。

14.6.2 カスタム・レポートの作成

Oracle Business Intelligence Publisherは、カスタム・レポートを設計および作成するためのすべての機能のセットを提供します。

関連項目:

- 『Oracle Business Intelligence Publisherユーザーズ・ガイド』

- 第C.3項「監査スキーマ」

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」フォルダ内のレポートに戻り、データを表示することができます。

第IV部

シングル・サインオンの構成

このパートでは、次の各章で、Oracle Fusion Middlewareでシングル・サインオンを構成する方法について説明します。

- 第15章「Oracle Fusion Middlewareにおけるシングル・サインオンの概要」

- 第16章「Oracle Access Manager 11gを使用したシングル・サインオンの構成」

- 第17章「Oracle Access Manager 10gを使用したシングル・サインオンの構成」

- 第18章「OracleAS SSO 10gを使用したシングル・サインオンの構成」

15 Oracle Fusion Middlewareにおけるシングル・サインオンの概要

ここでは、Oracle Fusion Middlewareで推奨される一連のシングル・サインオン・ソリューションの概略を説明します。内容は次のとおりです。

- デプロイメントに適したSSOソリューションの選択

- 概要: WebLogic ServerのOAM認証プロバイダ

- WebLogic管理コンソールでのデバッグの設定

15.1 デプロイメントに適したSSOソリューションの選択

Oracle Platform Security Servicesは、Oracle WebLogic Serverの内部セキュリティ・フレームワークを構成します。WebLogicドメインは、認証プロバイダと呼ばれる個別のソフトウェア・コンポーネントを使用してセキュリティ・データの格納、トランスポート、およびセキュリティ・データへのアクセスを提供します。認証プロバイダでは、各種システムを使用してセキュリティ・データを格納できます。WebLogic Serverによってインストールされる認証プロバイダは、組込みLDAPサーバーを使用します。

Oracle Fusion Middleware 11gは、アプリケーションによる境界認証の確立および実施のために使用できる、次の新しいシングル・サインオン・ソリューションをサポートしています。

- Oracle Access Managerソリューション

- Oracle Single Sign-On(OSSO)ソリューション

ニーズに応じたソリューションを注意深く選択する必要があります。適切なSSOソリューションの選択は、十分な検討を必要とし、それぞれの要件に応じて異なります。この項では、ニーズにあわせて最適なソリューションを選択するための一般的な情報とガイドラインについて説明します。

注意:

Access Manager 11g Single Sign-onソリューションが提供する多くの機能とアーキテクチャを活用するために、このソリューションへのアップグレードを検討することをお薦めします。

関連項目:

- 『Oracle Fusion Middlewareセキュリティ概要』

- Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

- 開発環境または小規模なスタンドアロン環境: デプロイされたアプリケーションをエンタープライズ・レベルのシングル・サインオン・フレームワークに統合しない場合、軽量なSSOソリューションの使用をお薦めします。
この場合は、Oracle WebLogic ServerのSAML資格証明マッピング・プロバイダを使用するSAMLベース・ソリューションが最適です。デフォルト・ユーザー・リポジトリとして、組込みLDAPサーバーが使用されます。また、外部LDAPサーバーをユーザー・リポジトリとして使用するようにLDAP認証プロバイダを構成することもできます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebブラウザとHTTPクライアントでのシングル・サインオンの構成に関する項

- Oracle Fusion Middleware 11gによるエンタープライズ・レベルのSSO: Oracle Access Managerは次の機能をサポートしています。

- ユーザー・リポジトリおよびグループ・リポジトリとして多様なLDAPベンダーをサポートし、Oracle Virtual Directoryでの使用も可能です。

- Oracle以外のアプリケーション・サーバー・ベンダーおよび多彩なOSプラットフォーム上のWeb層コンポーネントとの統合をサポートし、柔軟性の高いソリューションを提供します。

- Oracle Access Manager 11gは、特別な設定を必要とせずにOracle Fusion Middlewareアプリケーションと統合できます。

Oracle Access Manager 11g(リリース1): Oracle Access Manager 11gをお薦めできる状況は次のとおりです。

- Oracle Fusion Middlewareを初めて使用する場合

- OSSOからの移行を検討している場合

- エンタープライズ・レベルのSSOソリューションを検討している場合

- Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの説明に従って、OAMトークンを使用してID伝播を実装する場合

Oracle Access Manager 10g(10.1.4.3): 次のものがあれば、このアプリケーションを継続して使用できます。

- 既存のOracle Access Manager 10gの実装

- エンタープライズ・レベルのSSOソリューション

エンタープライズ・レベルのSingle-Sign-onソリューションとして、Oracle Access Managerソリューションの10g(10.1.4.3)または11gのどちらを選択するかは、現実の要件に応じて異なります。この章の製品ドキュメントおよび各管理ガイドを参照して、全体の要件に最適なリリースを評価してください。

関連項目:

「概要: WebLogic ServerのOAM認証プロバイダ」

- 現在OSSO 10gを使用しているお客様: Oracle Single Sign-Onは、10g Oracle Application Serverスイートに同梱されています。OSSOは、Oracle Internet DirectoryおよびOracle HTTP Server 11gと組み合せたOC4Jアプリケーション・サーバーで使用できるエンタープライズ・レベルのシングル・サインオン・ソリューションです。
既存のOracleデプロイメントにOSSOがエンタープライズ・ソリューションとしてすでにデプロイされている場合、Oracle Fusion Middlewareは、既存のOSSOソリューションを引き続きサポートします。それであっても、戦略的Oracle SSOソリューションである、Oracle Access Manager 11g Single Sign-onソリューションへのアップグレードを検討することをお薦めします。アップグレードの計画で必要となる情報の詳細は、http://www.oracle.com/support/lifetime-support-policy.htmlのLifetime Support Middleware PolicyでOSSOのサポート終了日を確認してください。

関連項目:

- 「概要: WebLogic ServerのOAM認証プロバイダ」

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- 10gで使用できるJava EE環境のタイプに関する詳細と、その環境からOracle Fusion Middleware 11gにアップグレードする手順は、『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』を参照してください。

- Portal、Forms、ReportsおよびDiscoverer 11g: Oracle Access Manager 11gは、Oracle Portal、Forms、ReportsおよびDiscover 11gで認定済です。Oracleの代表的な各種コンポーネントでは、Oracle Delegated Administration Services 10gがOracle Identity Managementインフラストラクチャに必須で重要な機能となっています。
次の場所にある、Oracle Identity Management 10g (10.1.4.0.1)オンライン・ドキュメント・ライブラリの『Oracle Identity Management委任管理ガイド』を参照してください:

http://www.oracle.com/technology/documentation/oim1014.html

詳細は、次の場所にある、Oracle Fusion Middlewareがサポートしているシステム構成に関するページを参照してください:

http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html

関連項目:

次の各項および他の11gマニュアル

- 「概要: WebLogic ServerのOAM認証プロバイダ」

- 第18章「OracleAS SSO 10gを使用したシングル・サインオンの構成」

- 『Oracle Fusion Middleware Oracle Portal管理者ガイド』

- 『Oracle Fusion Middleware Forms Servicesデプロイメント・ガイド』

- 『Oracle Fusion Middleware Oracle Reports ServicesレポートWeb公開ガイド』

- Oracle Fusion Middleware Oracle Business Intelligence Discoverer管理者ガイド

- Oracle Access ManagerとOSSOの統合: Oracle Access Manager 11gは、エンタープライズ規模のソリューションとしてお薦めできます。従来からOracleAS Single Sign-Onを必要とするアプリケーション(Oracle Portalなど)をデプロイしている場合は、OSSO 10gからOracle Access Manager 11gに認証を委任できます。Oracle Access ManagerとOSSOの統合を必要とするアプリケーションでは、Oracle Internet Directoryが必要です。

関連項目:

- 「概要: WebLogic ServerのOAM認証プロバイダ」

- Oracle Access Manager 11gにOSSO (mod_osso) Agentを登録することによる認証の委任の詳細、およびアップグレード中のOSSO 10gとOracle Access Manager 11gとの共存の詳細は、Oracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。

- 10gで使用できるJava EEの環境の詳細とその環境をOracle Fusion Middleware 11gにアップグレードする手順は、『Oracle Fusion Middleware Java EEアップグレード・ガイド』を参照してください。

- 『Oracle Access Manager統合ガイド 10g (10.1.4.3)』のOracle Application Serverとの統合に関する項

- MicrosoftクライアントのWindowsネイティブ認証: OSSOとOracle Access Manager 11gは、どちらもこの統合をサポートしています。Simple and Protected Negotiate (SPNEGO)認証メカニズムを使用するようにOracle WebLogic Serverを構成して、Windowsネイティブ認証を提供できます。

関連項目:

- 『Oracle Fusion Middleware Oracle Access Manager統合ガイド』の、MicrosoftクライアントでWindowsネイティブ認証を使用するためのOracle Access Manager 11gの構成に関する章

- 『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のMicrosoftクライアントでのシングル・サインオンの構成に関する項

15.2 概要: WebLogic ServerのOAM認証プロバイダ

特に明記されていなければ、ここで説明する情報はOracle Access Manager 11gと10gの両方のデプロイに同じように当てはまります。

Oracle Access Manager認証プロバイダは、Oracle WebLogic Serverで動作するプロバイダの1つです。Oracle Access Manager 11gまたは10gでOracle Access Manager認証プロバイダが動作するには、Oracle WebLogic Suite全体もOracle Java Required Files (JRF)も必要としません。

JRFをインストールしたWebLogic Serverドメインには、Oracle Fusion Middleware製品のドメインの一部としてJRFテンプレートが存在します。この場合、OAM IDアサーション・プロバイダとOAM認証プロバイダは自動的に構成に使用できるようになっています。WebLogicドメインにJRFがインストールされていない場合には、後述するようにドメインの特定の場所にOAMAuthnProvider.jarを追加する必要があります。

注意:

Oracle Fusion Middleware製品のドメインの一部としてJRFテンプレートが存在します。

次に該当する場合は、WebLogic ServerでOAM認証プロバイダを使用できます。

- Identity Managementドメイン外にあるWebLogicコンテナにアプリケーションをデプロイ済であるか、そこにアプリケーションをデプロイする予定です。

- 認証プロバイダのフロントエンドにWebGateをデプロイ済であるか、デプロイする予定です。

WebLogicユーザーが次の機能のいずれか(または両方)を使用できるように認証プロバイダを構成できます。

- シングル・サインオンのIDアサーション・プロバイダ機能

- 認証プロバイダ機能

シングル・サインオン機能のためのIDアサーション・プロバイダ

アプリケーションが境界Webゲートを使用して保護されている場合、WebLogic Serverに通知される認証されたユーザーのアイデンティティは、Oracle Access Manager IDアサーション・プロバイダを使用してコンテナ・セキュリティ・レイヤーに提供されます。IDアサーション・プロバイダは着信IDのみをアサートし、構成済の認証プロバイダに制御を渡して残りの認証プロセス(サブジェクトへの適切なプリンシパルの移入)を続行します。

注意:

Web専用アプリケーションの実装では、SSOの用途のほとんどすべてを扱うことができます。例外は、Oracle Web Services ManagerによってWebサービスが保護されている場合です。この場合は信頼されているWebゲートがありません。かわりに、IDアサーション・プロバイダが提供するアクセス・ゲートにアクセスすると、このアクセス・ゲートがOAM 10gアクセス・サーバーまたは11g OAMサーバーと対話します。それ以外の処理は基本的には同じです。

Oracleでは次のメカニズムを提供しています。それぞれ特性および要件が多少異なります。

- トラステッド・ヘッダー・アサーション: Oracle Access Manager 11.1.1.5.2以降(および10gまたは11gのWebゲート)で使用できるこの最新のメカニズムは、11gまたは10gのWebゲートで保護されているアプリケーション用のOAM_IDENTITY_ASSERTIONトークンに対してトリガーされます。これにより最大のセキュリティが得られ、また構成も容易です。

- クリアテキスト・ヘッダー: このデフォルトのメカニズムは、10gまたは11gのWebゲートで保護されているアプリケーション用のOAM_REMOTE_USERトークンに対してトリガーされます。

- セッション・トークン: このメカニズムは、境界10g Webゲートおよび10gアクセス・サーバーまたは11g OAMサーバーでのみ使用できます。

表15-1に、各メカニズムの利点と要件を示します。

関連項目:

「Oracle Access ManagerでのIDアサーション・プロバイダ機能の使用について」

表15-1 概要: Oracle Access ManagerのIDアサーション・メカニズム

メカニズム

利点

要件

トラステッド・ヘッダー・アサーション

OAM_IDENTITY_ASSERTION

最大のセキュリティ

容易な構成

Oracle Access Manager 11.1.1.5.2以降

10gまたは11g Webゲート

クリアテキスト・ヘッダー

OAM_REMOTE_USER

最大のパフォーマンス

デフォルトのメカニズム

Oracle Access Manager 11.1.1.5.0

10gまたは11g Webゲート

セッション・トークン(ObSSOCookie)

非推奨となる予定

10g WebゲートとOAM 10gまたは11gサーバー

Oracle Access Manager 11.1.1.3.0

Oracle Access Manager 10.1.4.3

10g Webゲート

認証プロバイダの機能

認証プロバイダ機能に、シングル・サインオン機能はありません。認証プロバイダは、Oracle Access Manager認証スキームではなく、アプリケーション構成ファイルweb.xmlで指定されている認証方式に従ってユーザーに資格証明を要求します。ただし、アプリケーション・ドメインにはOracle Access Manager認証スキームが必要です。

注意:

IDアサーション・プロバイダ機能を使用している場合は、この項は省略できます。

詳細は、次の項目を参照してください。

- Oracle Access ManagerでのIDアサーション・プロバイダ機能の使用について

- Oracle Access Managerでの認証プロバイダ機能の使用について

- Oracle Access Manager SSOのシナリオとソリューションに対応するアプリケーションの選択

15.2.1 Oracle Access ManagerでのIDアサーション・プロバイダ機能の使用について

ここでは、Oracle Access Manager 11gおよび10g WebゲートでのIDアサーション・プロバイダ機能の使用について説明し、手順を紹介します。OAM 11gで11g(または10g)のWebゲートを使用する場合も、OAM 10gで10gのWebゲートを使用する場合も、処理は一部の例外を除きほぼ共通しています。たとえば、Oracle Access Manager 11gでは、アクセス・サーバーがOAMサーバーと呼ばれます。

リクエストはすべて、まずリバース・プロキシWebサーバーにルーティングされ、Webゲートでインターセプトされます。Oracle Access Manager内に構成されている認証スキームに基づいて、ユーザーに対して資格証明の提示が要求されます。認証スキームとしては、フォームの使用(フォームベースのログイン)をお薦めします。

IDアサーション・プロバイダ機能は、Web層でWebゲートが実行する境界認証を利用しています。IDアサーション・プロバイダ機能をトリガーするにはWebゲートのリリースに適合するアクティブ・タイプが選択されている必要があります。

IDアサーション・プロバイダ機能をトリガーすると、構成済の認証プロバイダ(ログイン・モジュール)が呼び出され、サブジェクトを作成して適切なプリンシパルが移入されます。

注意:

IDアサーション・プロバイダ機能の使用における11g Webゲートと10g Webゲートとの唯一の違いは、プロバイダで選択されるアクティブ・タイプです。

選択アクティブ・タイプ

IDアサーション・プロバイダ機能のアクティブ・タイプ構成パラメータの「使用可能なUI」セクションには、サポートされる値がリストされます。IDアサーション・プロバイダ機能がトリガーされるようにするには、次のいずれかを「選択済」タイプとして選択する必要があります。

関連項目:

表15-1「概要: Oracle Access ManagerのIDアサーション・メカニズム」

- Identity Assertion: トラステッド・ヘッダーOAM_IDENTITY_ASSERTIONに基づいて、IDアサーションをトリガーします。

- OAM_REMOTE_USER: OAM_REMOTE_USERヘッダーに基づいて、IDアサーションをトリガーします。

- ObSSOCookie: obSSOCookieに基づいて、IDアサーションをトリガーします。

OAM_REMOTE_USERヘッダーには、ログイン・ユーザーのuidが記述されています。IDアサーション・プロバイダで使用する選択済アクティブ・タイプにOAM_REMOTE_USERを構成する場合、認可成功時のレスポンス・ヘッダーの構成部分としてOAM_REMOTE_USERを設定するOracle Access Managerポリシーが必要です。

認証処理およびIDアサーション・プロバイダ機能

特に指定がないかぎり、ここに記載された情報はOracle Access Manager 11gとOracle Access Manager 10gの双方に同様に適用されます。

Webゲートが構成されている認証スキームを使用してユーザーを認証すると、次のように処理されます。

- Webゲート:
11g WebゲートがOAMAuthnCookieを設定し、トークン(OAM_IDENTITY_ASSERTIONまたはOAM_REMOTE_USER)をトリガーします。

10g Webゲートは、obSSOCookie、OAM_REMOTE_USERまたはOAM_IDENTITY_ASSERTIONが使用可能かどうかに基づいてアサーションをトリガーします。

- OHS Webサーバーのmod_weblogicモジュールにより、リクエストがOracle WebLogic Serverに転送されます。

注意:

mod_weblogicは、Apache用のWebLogic Serverプラグインの汎用名です。Oracle HTTP Server 11gの場合、このプラグインの名前はmod_wl_ohsで、実際のバイナリ名はmod_wl_ohs.soです。

- コンテナに着信するリクエストに構成済のアクティブ・トークン・タイプ(OAM_REMOTE_USER(デフォルト)、obSSOCookie、OAM_IDENTITY_ASSERTION)が存在する場合、IDアサーション・プロバイダが呼び出されます。

- アサーション・プロセス後: セキュリティ・レルムに構成されている認証プロバイダが呼び出されて、サブジェクトにプリンシパル(ユーザーとグループ)が移入されます。

図15-1およびそれに続く概要では、Web専用アプリケーションでIDアサーション・プロバイダ機能を使用した場合のコンポーネント間の処理について説明します。この実装で、SSOの使用状況のほぼすべてに対応できます。ただしOracle Web Services Managerで保護されたWebサービスは例外です。この場合は信頼されているWebゲートがありません。かわりに、IDアサーション・プロバイダが提供するアクセス・ゲート(図15-1の点線)にアクセスし、このアクセス・ゲートが11g OAMサーバー(またはOAM 10gアクセス・サーバー)と対話します。それ以外の処理は基本的には同じです。

正しい構成のリストについては、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。

図15-1に、Oracle Access Manager 11gおよびWebゲートを使用したIDアサーション・プロバイダ構成での処理の概要を示します。

図15-1 Oracle Access ManagerおよびWebゲートを使用したIDアサーション・プロバイダの構成

アサーションは、認可ポリシーで構成されているトークン・タイプに基づいて行われます。リクエスト内にトークンが存在するだけでは、アサーション・プロバイダは呼び出されません。WebLogicで特定のアクティブ・トークン・タイプを構成するだけでは十分ではありません。OAM_IDENTITY_ASSERTIONが認可ポリシーで構成されていれば、これがリクエスト内に設定されます。

プロセス概要: OAM 11g、11g WebゲートおよびWeb専用アプリケーションを使用したIDアサーション・プロバイダ

1. ユーザーが、Oracle WebLogic Serverにデプロイされている、Oracle Access Managerによって保護されたWebアプリケーションにアクセスしようとします。

2. リバース・プロキシWebサーバーのWebゲートがリクエストをインターセプトし、リクエストされたリソースが保護されているかどうかをOAMサーバーに問い合せます。

3. リクエストされたリソースが保護されている場合、Webゲートは、そのリソースに対して構成されているOracle Access Manager認証スキームのタイプ(フォーム・ログインを推奨)に基づいてユーザーの資格証明を要求します。ユーザーは、ユーザー名やパスワードなどの資格証明を入力します。

4. Webゲートは、認証リクエストをOAMサーバーに転送します。

5. OAM 11g Serverによって、ユーザーの資格証明がプライマリ・ユーザー・アイデンティティ・ストアに照らして検証され、レスポンスがWebゲートに返されます(OAM 10gアクセス・サーバーでは構成されているユーザー・ディレクトリに照らしてユーザーが検証されます)。検証結果に応じて次のように処理されます。

- 正常な認証: ステップ6に進みます。

- 認証失敗: ログイン・フォームが表示され、ユーザーは資格証明の再入力を求められます。エラーは報告されません。

6. OAMサーバーはセッション・トークンを作成し、Webゲートに送信します。
11g Webゲート: それに対するポリシーが構成されている場合、OAMAuthn Cookieが設定されて返され、OAM_REMOTE_USER(またはOAM_IDENTITY_ASSERTER)トークンがトリガーされます。

10g Webゲート: それに対するポリシーが構成されている場合、リクエスト内でOAM_REMOTE_USERまたはOAM_IDENTITY_ASSERTIONヘッダーが設定されて返されます。

Webサーバーはこのリクエストをプロキシに転送し、プロキシはmod_weblogicプラグインを使用してリクエストをOracle WebLogic Serverに転送します。

mod_weblogicは、その構成設定に従ってリクエストを転送します。

注意:

mod_weblogicは、Apache用のWebLogic Serverプラグインの汎用名です。Oracle HTTP Server 11gの場合、このプラグインの名前はmod_wl_ohsです。

7. WebLogic Serverのセキュリティ・サービスは、タイプOAM_REMOTE_USER(またはOAM_IDENTITY_ASSERTER)のトークンを受け入れるように構成されているOracle Access Manager IDアサーション・プロバイダを呼び出します。このIDアサーション・プロバイダは、ヘッダーを使用してCallbackHandlerを初期化します。さらに、ダウンストリームLoginModule用として、NameCallbackにユーザー名を設定します。

8. Oracle WebLogicセキュリティ・サービスがユーザーを認可し、リクエストしたリソースへのアクセスを許可します。

9. レスポンスがリバース・プロキシWebサーバーに返されます。

10. レスポンスがブラウザに返されます。

15.2.2 Oracle Access Managerでの認証プロバイダ機能の使用について

この項では、Oracle Access ManagerでのWebリソースおよび非Webリソースへのアクセスを保護するために構成した認証プロバイダの使用について説明します。

注意:

特に指定がないかぎり、ここに記載された情報はOracle Access Manager 11gとOracle Access Manager 10gの双方に同様に適用されます。

この認証プロバイダ機能は、Oracle Access Managerサービスを使用して、WebLogic Serverにデプロイされたアプリケーションにアクセスするユーザーを認証します。ユーザーは、ユーザー名やパスワードなどの資格証明に基づいて認証されます。

ユーザーが保護されたリソースへのアクセスを試みると、Oracle WebLogic Serverによって、アプリケーションのweb.xmlファイルで指定されている認証方式に基づいたユーザー資格証明が要求されます。次に、Oracle WebLogic Serverが認証プロバイダを呼び出し、認証プロバイダは資格証明をOracle Access Managerアクセス・サーバーに転送します。この資格証明は、エンタープライズ・ディレクトリ・サーバーによって検証されます。

図15-2は、Webおよび非Webリソースに対してOracle Access Manager認証を行うコンポーネントの配置と情報フローを示しています。詳細は、図の後に説明します。この場合、認証プロバイダはカスタム・アクセス・ゲートを介して11g OAMサーバー(またはOAM 10gアクセス・サーバー)と通信します。

図15-2 Webおよび非Webリソース用の認証プロバイダ

図15-2「Webおよび非Webリソース用の認証プロバイダ」の説明

プロセス概要: Webおよび非Webリソース用の認証プロバイダ機能

1. ユーザーが、Oracle WebLogic Serverにデプロイされている(アプリケーションのweb.xmlファイルにある認証方式で保護されている)Java EEアプリケーションにアクセスしようとします。

2. Oracle WebLogic Serverがリクエストをインターセプトします。

3. Oracle WebLogicセキュリティ・サービスが、Oracle Access Manager認証プロバイダのLoginModuleを呼び出します。LoginModuleは、OAPライブラリを使用して11g OAMサーバー(または10gアクセス・サーバー)と通信し、ユーザー資格証明を検証します。

- ユーザー・アイデンティティが正常に認証されると、WLSUserImplプリンシパルとWLSGroupImplプリンシパルがサブジェクトに移入されます。

- Oracle Access ManagerのLoginModuleがユーザーのアイデンティティを正常に認証できない場合は、LoginException(認証失敗)が返され、Oracle WebLogicリソースへのアクセスは拒否されます。

4. Oracle Access Manager認証プロバイダは、Oracle WebLogic ServerのUserNameAssertionをサポートします。

5. Oracle Access Manager認証プロバイダは、任意のIDアサーション・プロバイダとともに使用できます。この場合、Oracle Access Manager認証プロバイダはユーザー名を解決し、そのユーザー名に関連付けられているロールとグループを取得します。

関連項目:

- 「Oracle Access Manager 11g用の認証プロバイダ機能の構成」

- 「Oracle Access Manager 10g用の認証プロバイダの構成」

15.2.3 Oracle Access Manager SSOのシナリオとソリューションに対応するアプリケーションの選択

この項では、現在のアプリケーション設定に応じて、Oracle Access Managerと認証プロバイダを使用するアプリケーションの選択について説明します。認証プロバイダでOracle Access Manager 11gまたは10gのどちらを使用する場合でも、詳細はよく似ています。

- アプリケーションでのOracle Access Managerの初めての使用

- アプリケーションでのOracle Application ServerからOracle WebLogic Serverへの移行

- アプリケーションでのWebLogic SSPI用のOAMセキュリティ・プロバイダの使用

15.2.3.1 アプリケーションでのOracle Access Managerの初めての使用

アプリケーションでOracle Access Manager認証プロバイダを初めて使用する場合、使用する機能に応じて、次の項を参照してください。

- シングル・サインオン用のIDアサーション・プロバイダ: Web専用アプリケーションの実装では、SSOを使用するほとんどすべての状況を扱うことができます。「Oracle Access Manager 11gでの認証プロバイダのインストール」を参照してください。
Oracle Web Services Managerによって保護されているWebサービス: この場合OAMサーバーと通信するには、IDアサーション・プロバイダで提供されるアクセス・ゲートが必要です。「Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成」を参照してください。

- 認証プロバイダ: シングル・サインオン機能は提供されません。認証プロバイダは、アプリケーション構成ファイルweb.xmlに指定されている認証方式に基づいてユーザーに資格証明を要求します。「Oracle Access Manager 11g用の認証プロバイダの構成」を参照してください。

15.2.3.2 アプリケーションでのOracle Application ServerからOracle WebLogic Serverへの移行

旧型のOracle Application Server (OC4J)にアプリケーションをデプロイしている場合、次のわずかな手順を実行すると、Oracle WebLogic Serverでそのアプリケーションから認証プロバイダを使用できるようになります。

- すべてのOC4J固有の設定をアプリケーション構成から削除します。

- シングル・サインオン用のIDアサーション・プロバイダ: Web専用アプリケーションの実装では、SSOを使用するほとんどすべての状況を扱うことができます。ご使用の環境に該当する項を参照してください。
—OAM 11g: 「Oracle Access Manager 11gでのSSO用のIDアサーションの構成」

—OAM 10g: 「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」

- Oracle Web Services Managerによって保護されているWebサービス: IDアサーション・プロバイダが提供するアクセス・ゲートが必要です。ご使用の環境に該当する項を参照してください。
—OAM 11g: 「Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成」

—OAM 10g: 「Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成」

- 認証プロバイダ: シングル・サインオン機能は提供されません。認証プロバイダは、アプリケーション構成ファイルweb.xmlに指定されている認証方式に基づいてユーザーに資格証明を要求します。ご使用の環境に該当する項を参照してください。
—OAM 11g: 「Oracle Access Manager 11g用の認証プロバイダ機能の構成」

—OAM 10g: 「Oracle Access Manager 10g用の認証プロバイダの構成」

15.2.3.3 アプリケーションでのWebLogic SSPI用のOAMセキュリティ・プロバイダの使用

Oracle Access ManagerのWebLogic SSPI用セキュリティ・プロバイダは、WebLogicプラットフォームにデプロイした複数のJava EEアプリケーションにわたって認証、認可およびシングル・サインオンを提供します。WebLogic SSPI用セキュリティ・プロバイダでは、Oracle Access Managerを使用して、ビジネス・アプリケーションへのユーザー・アクセスも管理できます。

注意:

WebLogic SSPI用セキュリティ・プロバイダは、10g(10.1.4.3)の『Oracle Access Manager統合ガイド』ではセキュリティ・プロバイダとも呼ばれています。

Oracle Access ManagerのWebLogic SSPI用セキュリティ・プロバイダは、Oracle WebLogic Portalリソースへのアクセスを認証し、Oracle Access ManagerとOracle WebLogic Portal Webアプリケーション間のシングル・サインオンをサポートします。さらに、ユーザーおよびグループの管理機能も提供します。

Oracle Access Manager認証プロバイダは、WebLogic SSPI用セキュリティ・プロバイダよりも簡単にインストールおよび構成できます。認証プロバイダは、認証とシングル・サインオン(SSO)のサービスを提供するほか、Oracle WebLogic Serverがサポートするすべてのプラットフォームで機能します。

認証とSSOの目的でのみアプリケーションでOracle Access Manager WebLogic SSPI用セキュリティ・プロバイダを使用している場合は、最新の認証プロバイダのデプロイメントをお薦めします。ただし、最新のOracle Access Manager認証プロバイダでは得られない機能を使用している場合は、引き続きOracle Access Manager 10g WebLogic SSPI用セキュリティ・プロバイダを使用してもかまいません。

注意:

WebLogic SSPIコネクタは、Oracle Access Manager 10gでは使用できますが、Oracle Access Manager 11gではサポートされていません。

関連項目:

「アプリケーションでのWebLogic SSPI用のOAMセキュリティ・プロバイダの使用」

15.2.4 実装: プロバイダの使用におけるOAM 11gとOAM 10gの相違点

若干の違いはありますが、WebLogicコンテナのアプリケーションの保護にOAM 11gとOAM 10gのどちらを使用しても、実装ソリューションはよく似ています。

表15-2では、OAM 11gで認証プロバイダをデプロイする場合とOAM 10gでデプロイする場合の違いを説明しています。項の見出しが強調表示されています。

表15-2 OAM 11gとOAM 10gでの認証プロバイダ実装タスクの違い

OAM 11gの実装の詳細

OAM 10gの実装の詳細

OAM 11gの実装では次のタスクを実行します。詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。

- Oracle Access Manager 11gでの認証プロバイダのインストール

- OAM 10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー

- セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング(ObSSOCookieのみ)
注意: OAM 11gリモート登録ツールは、Webゲートとポリシーのプロビジョニングを自動化します。WebLogic Serverリソースについては、デフォルトでwl_authenリソース・タイプが作成されます。

- Oracle Access Manager 11gでのSSO用のIDアサーションの構成
または

Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成

または

Oracle Access Manager 11g用の認証プロバイダ機能の構成

- Oracle Access Manager 11g用の集中管理ログアウトの構成

OAM 10gでSSOソリューションを実装するタスクは、この章の次の項を参照してください。

- OAM 10g用の認証プロバイダのインストールおよび設定

- Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成
注意: OAM 10gのOAMCfgToolは、Webゲートとポリシーのプロビジョニングを自動化します。

10g Webゲートのインストール: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

- Oracle Access Manager10g用の認証プロバイダの構成では、ポリシー・ドメインを手動で作成する必要があります。
Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成

- Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

15.2.5 Oracle Access Managerで使用されるプロバイダの要件

認証プロバイダの実装に必要なコンポーネントとファイルは、SSOソリューションとしてOAM 11gとOAM 10gのどちらを使用してもほとんど同じです。次のようなわずかな例外があります。

- Oracle Access ManagerとOracle WebLogic Serverで使用するエンタープライズ・ディレクトリ・サーバー(Oracle Internet DirectoryまたはOracle Sun Oneディレクトリ・サーバー)

- Oracle Access Manager認証プロバイダを使用するように構成した10.3.1以降のOracle WebLogic Server(この章の後半にある説明を参照)

- オプション: Fusion Middleware製品(Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど)

- 認証プロバイダ: WebLogicコンテナにデプロイしたアプリケーションの場合、Oracle Fusion Middleware製品(Oracle Identity Management、Oracle SOA SuiteまたはOracle WebCenter)をインストールすると、Oracle Access ManagerのJARファイルおよびWARファイルを利用できるようになります。

注意:

Fusion Middlewareを組み込まずにスタンドアロンのOracle WebLogic Serverを使用している場合は、この章の後半にある手順のステップ1に従ってOracle Technology NetworkからJARファイルおよびWARファイルを取得する必要があります。

- oamAuthnProvider.jar: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのファイルとOracle WebLogic Server 10.3.1以降の認証プロバイダのファイルが含まれています。ユーザーやアプリケーションからのWebリソースおよび非Web(非HTTP)リソースに対するリクエストを処理するために、カスタムのOracle Access Managerアクセス・ゲートも用意されています。

- oamauthenticationprovider.war: Oracle WebLogic Serverコンソールに表示されるプロバイダを、Oracle Access Managerで使用するために必要なプロバイダのみに制限します。
拡張をデプロイする際に、WebLogic管理コンソールでは、そのWARファイルに記述されたファイルおよびディレクトリと、拡張のWARファイルに記述されたファイルおよびディレクトリとのメモリー内結合が作成されます。デプロイした拡張機能は、WebLogic管理コンソールの完全なメンバーになります。この拡張機能は、WebLogic Serverのセキュリティ・レルムで保護され、管理コンソールの他のセクションに移動できます。また、拡張機能からWebLogic Serverリソースを変更する場合、拡張機能は変更制御プロセスに参加します。詳細は、Oracle Fusion Middleware Oracle WebLogic Serverの管理コンソールの拡張を参照してください。

- Oracle Access Manager 11g: リモート登録コマンドライン・ユーティリティは、Webゲートのプロビジョニングを合理化し、セキュリティ・ポリシーを備えた新しいアプリケーション・ドメインを作成します。管理者は、テンプレートを使用してWebゲートのパラメータと値を指定できます。

- Oracle Access Manager 10g: プラットフォームに依存しないOAMCfgToolとスクリプト(oamcfgtool.jar)によって、IDアサーション・プロバイダ機能でシングル・サインオンに使用されるOracle Access Managerのフォームベースの認証スキーム、ポリシー・ドメイン、アクセス・ポリシー、およびWebゲートプロファイルの作成が自動化されます。OAMCfgToolにはJRE 1.5または1.6が必要です。Fusion Middlewareアプリケーション用の国際化されたログイン・フォームはこれらのアプリケーションを保護するポリシーに対応しています。

- Webゲートのリバース・プロキシとして、OHS 11gを構成する必要があります(Oracle Access Manager IDアサーション・プロバイダで必要)。

- Oracle Access Manager:
OAM 11g: Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明されているように、Oracle Fusion Middleware構成ウィザードを使用して初期構成でデプロイされます。「Oracle Access Manager 11g SSOソリューションのデプロイ」を参照してください。

OAM 10g: Oracle Access Managerインストレーション・ガイドで説明されているように、初期設定でインストールされます。「Oracle Access Manager 10gを使用したSSOソリューションのデプロイ」を参照してください。

- Webゲート/アクセス・ゲート: Oracle Access ManagerでWebゲートまたはアクセス・ゲートのどちらのプロビジョニングが必要であるかは、OAM認証プロバイダの使用方法によって決まります。
シングル・サインオン用のIDアサーション・プロバイダ: 境界認証を定義するために、アプリケーションごとに個別のWebゲートが必要です。

認証プロバイダ(またはOracle Web Services Manager): 認証プロバイダで使用できるカスタム10gアクセス・ゲートが必要です。

15.3 WebLogic管理コンソールでのデバッグの設定

認証プロバイダでは、デバッグ・モードで動作する場合、アプリケーション内の低レベルのアクティビティの詳細な説明を提供するメッセージが使用されます。通常、この情報はそれほど必要とされません。ただし、Oracleサポート・サービスへの連絡が必要な場合、デバッグを設定することをお薦めします。デバッグを設定すると、Oracle WebLogic Serverのデフォルト・ログの場所に認証プロバイダのメッセージが表示されます。

デバッグを設定するには

1. WebLogic管理コンソールにログインします。

2. 「ドメイン」→「環境」→「サーバー」に移動し、使用するサーバーを選択します。

3. 「デバッグ」タブをクリックします。

4. 「このサーバーのデバッグ設定」で、「weblogic」→「security」→「atn」をクリックして開きます。

5. 「DebugSecurityAtn」の隣にあるオプションをクリックして有効にします。

6. 変更を保存します。

7. Oracle WebLogic Serverを再起動します。

8. Oracle WebLogic Serverのデフォルト・ログの場所で、SSOAssertionProviderを検索します。例:

####<Apr 10, 2009 2:32:16 AM PDT> <Debug> <SecurityAtn> <sta00483> <AdminServer> <[ACTIVE]
ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'>
<<WLS Kernel>> <> <> <1239355936490> <BEA-000000>
<SSOAssertionProvider:Type          = Proxy-Remote-User>

16 Oracle Access Manager 11gを使用したシングル・サインオンの構成

ここでは、Oracle Access Manager 11gを使用したシングル・サインオンの構成について説明します。内容は次のとおりです。

- Oracle Access Manager 11g SSOの概要

- Oracle Access Manager 11g SSOソリューションのデプロイ

- Oracle Access Manager 11g用の集中管理ログアウトの構成

- ユーザーとSSOセッションの同期: SSO同期フィルタ

- トラブルシューティングのヒント

16.1 Oracle Access Manager 11g SSOの概要

Oracle Access Manager 11gは、Oracleのエンタープライズ・クラス・スイートのセキュリティ製品に属しています。新規のSSOデプロイメントと既存のSSOデプロイメントでの使用を目的としたOracle Access Manager 11gは、Webシングル・サインオン、認証と認可、ポリシー管理などの広範なWeb境界セキュリティ機能を提供します。

Oracle Access Manager 11gシングル・サインオン(SSO)およびシングル・ログアウト(SLO)は、次のような様々なアプリケーション・プラットフォームをサポートします。

- SOA

- WebCenter

Oracle Fusion Middleware Oracle Access Manager統合ガイドの説明にあるように、Oracle Access Manager 11gは次のような様々なアプリケーションとの統合をサポートしています。

- Oracle Identity Navigator

- Oracle Identity Federation

- Oracle Identity Manager

- Oracle Adaptive Access Manager

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドに説明されているように、Oracle Access Manager 11gがOracle Access Manager 10gと異なる点は、アイデンティティ管理機能がOracle Identity Manager 11gに移行されていることです。ユーザー・セルフサービスおよび自己登録、ワークフロー機能、動的グループ管理、アイデンティティ管理の委任などの機能があります。

Oracle Identity Managementアプリケーションのコンソール保護

Oracle Access Manager 11gおよびその他のOracle Identity Managementアプリケーションは、WebLogicコンテナにデプロイされています。個々の管理コンソールには、Oracle Access Manager、Oracle Adaptive Access Manager、Oracle Identity Navigator、Oracle Identity Manager、Oracle WebLogic Server、Oracle Entitlements Serverなどがあります。

これらは、デフォルトで、WebLogic管理コンソールの事前構成済の認証プロバイダおよび事前登録済のOracle Access Manager 11gのIAMSuiteAgentで保護されています。OAM 11g SSOポリシーは事前シード済です。コンソールをこれ以上構成する必要はありません。

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

OAM 11gデプロイメントのプレビュー

新規WebLogic管理ドメインまたは既存のWebLogic管理ドメインで、Oracle Fusion Middleware構成ウィザードを使用してOracle Access Managerを構成できます。

「Oracle Access Managerで使用されるプロバイダの要件」を参照してください。

関連項目:

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

Oracle Access Manager 11gには、新規または既存のポリシー適用エージェントとの下位互換性を保持する新しいサーバー側のコンポーネントが用意されています。サーバー側で開始する動的な更新が、ポリシーや構成に対するあらゆる変更で実行されます。

- OAM 10gポリシー・マネージャにかわって、Oracle Access Managerコンソール(WebLogic管理サーバーにインストール)が稼働します。

- OAM 10gアクセス・サーバーにかわって、OAMサーバー(WebLogic管理対象サーバーにインストール)が稼働します。

Oracle Access Manager 11gは、リソースを保護する次のような登録済エージェントの任意の組合せに対し、シングル・サインオン(SSO)、認証、その他の認可などのサービスを提供します。

- 11g Webゲート

- 10g Webゲート

- JavaベースのIAMSuiteAgent

- OSSOエージェント(10g mod_osso)

Oracle Access Manager 11gは、現在Oracle ADFのセキュリティとOPSS SSOフレームワークを使用しているどのWebアプリケーションとも統合できます。

Oracle Access Manager管理コンソールへのログインやOAM管理コマンドライン・ツールの使用は、適切な権限を持ったユーザーにのみ許可されています。企業によっては、OAM管理を担当するユーザーとWebLogic管理を担当するユーザーに別の管理者グループが必要になることがあります。詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの新しいOAM管理ロールの定義に関する項を参照してください。

OAM 11gの概要

Oracle Access Manager 11gの基本機能の概要は、次のとおりです。

プロビジョニング/リモート登録: 新しいリモート登録ツールにより、ネットワーク内外の管理者はエージェントとポリシーを登録できます。OAM 11gのプライマリ・ユーザー・アイデンティティ・ストアにユーザー名とパスワードを設定する必要があります。

認証: Oracle Access Manager 11gアプリケーション・ドメインは、リソースとセキュリティ・ポリシー(リソースごとに1つのポリシー)を集約します。Oracle Access Manager 11gの認証ポリシーには、固有のスキームがあります。サポートされる認証モジュールには、LDAP、X.509、Kerberosなどがあります。認証ユーザーは、集中管理された資格証明コレクタによってプライマリ・ユーザー・アイデンティティ・プロバイダにマッピングされます。

認可: アプリケーション・ドメインで定義して、データベースで永続化したセキュリティ・ポリシーに基づいて、Oracle Access Manager 11gで認可が実行されます。認可ポリシーはリソースと制約の評価を定義します。

レスポンス: 管理者は、認証レスポンスと認可レスポンスを使用してセッション属性を設定できます。セッションの属性以外に、ユーザー関連のデータおよびリクエスト関連のデータもレスポンスで取得できます。設定したレスポンスは、その立証に効果的なエージェントにHTTPヘッダーまたはCookieとして送信されます。Cookieの値およびヘッダーの変数に対し、レスポンスは別のレスポンスで事前に設定されたセッション属性を取得できます。たとえば、レスポンスによって認証時に設定されたセッション属性を、認可の際にヘッダー値として取得できます。

セッション管理: Oracle Access Manager 11gセッション管理サービスでは、Oracle Coherenceのテクノロジに基づく高パフォーマンス分散キャッシュ・システムを介してアクティブ・ユーザー・セッションを追跡します。各Oracle Access Managerの実行時インスタンスは、この分散キャッシュ・システムにあるノードとなります。これらのノード間のセキュアな通信は、対称鍵を使用すると容易に実行できます。Oracle Access Managerの実行時インスタンスは、ローカルのキャッシュにあるユーザー・セッション・データを分散キャッシュに移動して、他のノードから選択できるようにします。また、Oracle Access Managerの実行時インスタンスごとにレプリケーション・ファクタを構成して、セッション・データをどのように分散するかを指定することもできます。管理者は、セッションのライフサイクルの構成、固有のアクティブ・セッションの検索と削除、任意の時点でユーザーが同時に実行できるセッション数の制限などが可能です。バンド外のセッションを終了すると、ユーザーがセッションを終了した後でシステムへの認可されないアクセスを防止します。

キー: Oracle Access Manager 11gのランタイムは、アプリケーションとしてWebLogic管理対象サーバーまたはクラスタにデプロイされます。新しいOracle Access Manager 11g WebGatesは、エージェントの信頼モデルごとに機密情報の共有をサポートします。11g Webゲートでは、エージェントとホストに固有のCookieを使用して優れたセキュリティを実現できます。Oracle Access Manager 11g Webゲートは、すべて同レベルで信頼されます。Webゲートにはそれぞれに固有のCookieが設定されるので、あるWebゲートのCookieを使用しても、他のWebゲートで保護されたアプリケーションにユーザーにかわってアクセスすることはできません。これにより、Cookieリプレイ・タイプの攻撃から防御できます。

SSOおよびSLO: Oracle Access Manager 11gサーバー・セッション・トークンは、Oracle Access ManagerとOSSOエージェント間のSSOの基礎を形成します。ログアウトは、Oracle Access Manager 11gサーバーのグローバル・ログアウトで実行します。これにより、中央のセッションは終了し、ユーザーはアクセスした各エージェントからログアウトします。

- Oracle Access Manager 10g Webゲートでは、ログアウトによりObSSOCookieが削除され、「グローバル・ログアウト」ページにリダイレクトされます。

- Oracle Access Manager 11gのWebゲートおよびmod_ossoエージェントでは、ログアウトは「グローバル・ログアウト」ページにリダイレクトされ、各エージェントはエージェント固有のCookieを削除するためにコールバックされます。

ロギングと監査: Oracle Access Manager 11gコンポーネントでは、Oracle Fusion Middleware 11gの他のコンポーネントと同じロギング・インフラストラクチャとロギング・ガイドラインを使用します。Oracle Access Manager 11gでは、エージェントとサーバーの監視機能が用意されています。Oracle Access Manager 11gの監査機能は共通監査フレームワークに基づいています。監査レポートの生成は、Oracle Business Intelligence Publisherによりサポートされています。

アクセス・テスター: Oracle Access Manager 11gの新しいアクセス・テスターを使用すると、IT専門家や管理者は登録されたOracle Access Managerエージェントとサーバー間の相互作用をシミュレートできます。これは、セキュリティ・ポリシー定義のテストやエージェントの接続が関係する問題のトラブルシューティングで役立ちます。

テストから本番への移行: Oracle Access Manager 11gを使用して、構成やポリシーのデータを1つのOracle Access Manager 11gデプロイメントから別のデプロイメントに移動できます(小規模なテストデプロイメントから本番デプロイメントへの移動など)。テンプレートに基づく新規トポロジの作成がサポートされています。ポリシーに対する変更のコピーや移動も可能です。

OSSO 10gとの共存およびOSSO 10gのアップグレード: Oracleが提供するUpgrade Assistantは、既存のOracleAS 10g SSOサーバー構成をスキャンし、10g OSSOポリシー・プロパティ・ファイルおよびスキーマ情報を入力として受け入れ、構成済のパートナ・アプリケーションを移行先のOracle Access Manager 11g SSOに転送します。

関連項目:

- Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOracle Access Manager 11gとOSSO 10g Server間におけるアップグレード後の共存の概要に関する項

- 『Oracle Fusion Middlewareアップグレード・プランニング・ガイド』

- 『Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイド』

16.1.1 10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー

この項の操作は、10gカスタム・アクセス・ゲートでのみ必要です。ご使用の環境に当てはまらない場合は、この項は省略してください。

Application Authenticatorアプリケーション・ドメインはOAM 11gで提供されます。これは、OAM認証プロバイダをセキュリティ・プロバイダとしてWebLogic環境にデプロイしたアプリケーションとの統合を実現するポリシー・オブジェクトによって事前シードされています。これは、Webゲートのプロビジョニングに関連付けられていません。このドメイン(または既存のアプリケーション・ドメイン)を使用するためにWebゲートまたはアクセス・ゲートをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。

OAM認証プロバイダ(およびOracle Web Services Manager用IDアサーション・プロバイダ)で使用するカスタムの10gアクセス・ゲートで、Application Authenticatorアプリケーション・ドメインが機能するようになりました。この場合、カスタムのアクセス・ゲート(Webゲートではありません)が、OAM 11gにアクセスする前のユーザーを認証するためのトークンを使用して、WebLogic Serverに直接アクセスします。

Application Authenticatorアプリケーション・ドメインは、タイプwl_authenのリソースのみを保護し、2つの認証ポリシーと1つの認可ポリシーでシードされます。次のwl_authenリソースもこのドメインにシードされます。

- /Authen/Basic

- /Authen/SSOToken

- /Authen/UsernameAssertion (LDAPNoPasswordValidationSchemeによって保護)

注意:

このドメインで許可されているのは、タイプwl_authenのリソースのみです。他のリソース・タイプは追加できません。wl_authenリソースのポリシーとレスポンスは追加可能です。ただし、このドメインの変更が不要であることが理想です。

図16-1は、OAM 11g管理コンソールのシードされたApplication Authenticatorアプリケーション・ドメインの詳細を示しています。このページは、/Authen/UsernameAssertionリソースを保護する、事前シード済の認証ポリシーUser ID Assertionを示しています。このポリシーで保護しているリソースのほかに、ポリシーの認証スキームも表示されています。

図16-1 User ID Assertion認証ポリシーで事前シードされたリソース

図16-2は、User ID Assertion認証ポリシーに事前シードされたレスポンスを示しています。レスポンスの詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。

図16-2 User ID Assertionポリシーで事前シードされたレスポンス

図16-3は、事前シード済の認証ポリシーApplication SSO、このポリシーで保護されたリソースおよび認証スキームを示しています。

図16-3 事前シード済の認証ポリシーApplication SSOとリソース

図16-4は、アプリケーション・ドメインに事前シードされた認証ポリシーApplication SSOのレスポンスを示しています。

図16-4 認証ポリシーApplication SSOに対して事前シードされたレスポンス

図16-5は、アプリケーション・ドメインで事前シードされた認可ポリシーApplication SSOとリソースを示しています。

図16-5 事前シード済の認可ポリシーApplication SSOとリソース

認可の制約: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドで説明されているように、制約を追加することはできます。

認可のレスポンス: このアプリケーション・ドメインには、事前シード済の認可ポリシーApplication SSOの制約がありません。ただし、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドで説明されているように、レスポンスを追加することはできます。

関連項目:

- Oracle Access Manager 11g用の認証プロバイダ機能の構成

- Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成

16.2 Oracle Access Manager 11g SSOソリューションのデプロイ

この項では、WebLogicコンテナにデプロイしたアプリケーションまたはそこにデプロイする予定のアプリケーションがある場合に、認証プロバイダでOAM 11gを実装する方法を説明します。

この項の内容は次のとおりです。これらは、アプリケーションをWebLogicコンテナにデプロイする場合のOAM 11g SSOの実装で役に立ちます。ここで取り上げているOAMソリューションの実装は、OAM 11gに固有なもの以外は、OAM 11gとOAM 10gのどちらでも同じです。

- Oracle Access Manager 11gでの認証プロバイダのインストール

- セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング

- Oracle Access Manager 11gでのSSO用のIDアサーションの構成

- Oracle Access Manager 11g用の認証プロバイダ機能の構成

- Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成

- Oracle Access Manager 11g用の集中管理ログアウトの構成

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOAMトークンを使用したID伝播のシナリオの詳細に関する項

16.2.1 Oracle Access Manager 11gでの認証プロバイダのインストール

次の概要では、認証プロバイダを使用してOracle Access Manager 11g SSOソリューションに必要なコンポーネントとファイルをインストールする際に完了する必要があるタスクについて説明します。Oracle Access Manager 11gとOracle Access Manager 10gとでは、これらのタスクの多くはほとんど同じですが、いくつかの相違点があります。

関連項目:

『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』のOracle Access Manager 11gのインストールと初期構成の詳細に関する項

タスクの概要: 認証プロバイダおよびOAM 11gで使用するコンポーネントのインストール

1. Oracle Access ManagerのOracle Internet Directoryをインストールおよび設定します。

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

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

2. Oracle WebLogic Server 10.3.1以降をインストールおよび設定します。

関連項目:

このリストの手順3および『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』

3. オプション: Fusion Middleware製品(Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど)をインストールします。

注意:

Fusion Middlewareアプリケーションがインストールされていない場合は、以降の手順に従って、必要なJARファイルおよびWARファイルを入手する必要があります。

4. 必要に応じて、Oracle Access Manager Webゲート用にOHS 11gをインストールします。

- IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。
Webゲート: OAM IDアサーション・プロバイダでIDアサーションを行うために、OHS Webサーバー上に境界Webゲートがインストールおよび構成されている必要があります。

- 認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。

5. 認証プロバイダ・ファイル: 次のように必要なJARファイルとWARファイルを確認します。

1. 次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar

2. 次のパスで、コンソール拡張WARファイルを見つけます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov
ider.war

3. WARファイルを、WebLogic Serverホームの次のパスにコピーします。

WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war

6. Oracle Access Manager 11g:

1. 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』で説明されているように、Oracle Access Managerをインストールして、初期構成を実行します。

2. トラステッド・ヘッダー・アサーション: My Oracle Support(http://support.oracle.com)にアクセスし、バンドル・パッチ02 (Oracle Access Manager Bundle Patch 11.1.1.5.2)を入手し、付属のreadmeファイルの説明に従って適用します。

7. 認証プロバイダ(またはOracle Web Services Manager)用のアクセス・ゲート:

- 「セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」に説明されているように(または、認証プロバイダの構成時に既存のOAMエージェントの登録を参照)、10gアクセス・ゲートをプロビジョニングできます。

- oamAuthnProvider.jarで使用できるカスタム10gアクセス・ゲートをデプロイします。

16.2.2 Oracle Access Manager証明書のJavaキーストア形式への変換

すべてのJavaコンポーネントおよびアプリケーションでキーストア形式としてJKSを使用することをお薦めします。この項では、Oracle Access Manager X.509証明書をJavaキーストア(JKS)形式に変換する手順について説明します。この手順に適切に従うことで、Java NAPクライアントがOAMサーバーと簡易モードまたは証明書モードで通信するときに使用できるJKSストアが生成されます。

注意:

この手順は、選択するSSOメカニズムにかかわらず必要です。

簡易モードまたは証明書モードで通信する際、OAMサーバーは、次のキー・ファイル、サーバー証明書ファイルおよびCAチェーン・ファイルを使用します。

- aaa_key.pem: ルートCAにリクエストを送信するときに証明書生成ユーティリティによって生成されるランダム・キー情報。これは秘密鍵です。WebGateの証明書リクエストでは、証明書リクエスト・ファイルaaa_req.pemが生成されます。このWebGate証明書リクエストを、OAMサーバーによって信頼されるルートCAに送信する必要があります。ルートCAは、WebGate証明書を返します。この証明書は、WebGateのインストール中またはインストール後にインストールできます。

- aaa_cert.pem: ルートCAによって署名される、OAMサーバーに対する実際の証明書。

- aaa_chain.pem: ルートCAのパブリック証明書。これは、簡易モードまたは証明書モードで通信するピア同士が、SSLハンドシェイクを実行して、妥当性確認のための証明書を交換するときに使用されます。簡易モードでは、aaa_chain.pemは、OAMServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pemにあるOpenSSL証明書です。

ここで、aaaは、ファイルについて指定する名前です(証明書ファイルおよびチェーン・ファイルにのみ適用されます)。

テキスト編集ユーティリティを使用して既存の証明書を編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除できます。次に、編集された証明書をJKS形式に変換し、キーストアにインポートします。Javaキー・ツールでは、すでに保持している証明書に対する既存の秘密鍵をインポートできません。OpenSSLユーティリティを使用して、PEM形式ファイルをDER形式ファイルに変換する必要があります。

Oracle Access Manager証明書をJKS形式に変換してインポートする手順は次のとおりです。

1. Java 1.6または最新のバージョンをインストールして構成します。

2. 編集する前に次のファイルをコピーして、元のファイルを保持します。

- aaa_chain.pem

- aaa_cert.pem

- cacert.pem(簡易モードで構成する場合のみ)

3. TextPadを使用してaaa_chain.pemを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、そのファイルを新しい場所に保管して元のファイルを保持します。

-----BEGIN CERTIFICATE-----
...
CERTIFICATE
...
-----END CERTIFICATE-----

4. 編集されたaaa_chain.pemに対して次のコマンドを実行します。

JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore
rootcerts

ここでは、別名(短縮名)root_caをキーに割り当てています。入力ファイルaaa_chain.pemは、手順3で手動で編集したファイルです。キーストア名は、rootcertsです。

新規作成したキーストアに格納されているキーにアクセスするためのパスワードを指定する必要があります。

注意:

セキュリティを確保するために、キーツールでパスワードの入力を求めるプロンプトが表示されるようにすることをお薦めします。コマンド・ラインから「-storepass」フラグを省くと、このプロンプトが自動的に表示されます。

5. 入力を求められたら、キーストアのパスワードを入力します。例:

Enter keystore password: <keystore_password>
Re-enter new keystore password: <keystore_password>

6. このツールを信用するかどうかを質問されたら、「Yes」と入力します。

Trust this certificate? [no]: yes

7. 次のコマンドを実行してパスワードを入力し、証明書がJKS形式にインポートされていることを確認します。

JDK_HOME\bin\keytool" -list -v -keystore "rootcerts"
Enter keystore password: <keystore_password>

8. 次のようなレスポンスを探します。

Keystore type: JKS
Keystore provider: SUN
Your keystore contains n entries
Alias name: root_ca
Creation date: April 19, 2009
Entry type: trustedCertEntry

Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint,
O="Oblix, Inc.", L=Cupertino, ST= California , C=US

Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint,
O="Oblix, Inc.", L=Cupertino, ST= California ,C=US

Serial number: x
Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57
GMT+05:30 2010

Certificate fingerprints
MD5:  CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC
SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95
Signature algorithm name: MD5withRSA
Version: 1
*******************************************

9. 他のPEMファイルについて、手順3 - 7を繰り返します(チェーンがない場合のaaa_chain.pemを除く)。

10. OAMサーバーのインストール・ディレクトリ・パスでOpenSSLユーティリティを使用して、aaa_key.pemファイルをDER形式に変換します。例:

OAM_Server_HOME\access\oblix\tools\openssl>openssl pkcs8 -topk8
-nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER

ここで、入力ファイルはaaa_key.pem、出力ファイルはaaa_key.derです。追加のオプションは次のとおりです。

表16-1 PEMからDER形式ファイルを作成するためのオプション

オプション

説明

-topk8

従来の形式の秘密鍵を読み込んで、PKCS#8形式の鍵を書き出します。これにより、デフォルトと逆の状態になります。デフォルトでは、入力でPKCS#8の秘密鍵が要求され、従来の形式の秘密鍵が書き出されます。

-nocrypt

出力で暗号化されていないPrivateKeyInfo構造が要求されます。

-inform

入力形式を指定します。入力でPKCS#8形式の鍵が要求される場合、DERまたはPEMでエンコードされたバージョンのPKCS#8鍵が要求されます。それ以外の場合、DERまたはPEM形式の従来形式の秘密鍵が使用されます。

-outform

出力形式を指定します。出力でPKCS#8形式の鍵が要求される場合、DERまたはPEMでエンコードされたバージョンのPKCS#8鍵が要求されます。それ以外の場合、DERまたはPEM形式の従来形式の秘密鍵が使用されます。

11. 簡易モードまたは証明書モード: 簡易モードまたは証明書モードで構成されている場合、PEMファイル(この場合、aaa_cert.pem)で、OAMサーバーに対するパスフレーズを入力します。

Passphrase for the certificate

12. 次のコマンドを実行して、aaa_cert.pemファイルをDER形式に変換します。

AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in
aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER

13. ImportKeyユーティリティを使用して、DER形式ファイルをJavaキーストアにインポートします。例:

Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der
aaa_cert.der

14. ウィンドウで結果を確認します。次の例のように表示されます。

Using keystore-file : jkscerts
One certificate, no chain
Key and certificate stored
Alias:importkey  Password:your_password

16.2.3 セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング

このタスクは、セッション・トークン・メカニズム(ObSSOCookie)にのみ必要です。トラステッド・ヘッダー・アサーションまたはクリアテキスト・ヘッダー・メカニズムを実装している場合は、この項は省略してください。

プロビジョニングとは、OAM 11gの認証と認可のサービスを使用するために、エージェントを登録してアプリケーション・ドメインを作成するプロセスです。新しい11gインスタンスまたは10gインスタンスをインストールする場合でも、レガシーの10g Webゲートがインストール済の場合でも、OAM 11gでWebゲートをプロビジョニングする必要があります。

用語としてのWebゲートは、複数のWebゲートを表します(Oracle Web Services Managerの認証プロバイダおよびIDアサーション・プロバイダで使用するカスタムの10gアクセス・ゲートも指します)。特に明記されていなければ、この項の内容は両方に同様に当てはまります。

複数のエージェントがある場合、それぞれを別々にプロビジョニングできるほか、複数のエージェントに単一のOAMエージェント登録を使用することもできます。

注意:

Application Authenticatorアプリケーション・ドメインは事前シード済で、OAM 11gで提供されます。このアプリケーション・ドメイン(または別の既存のアプリケーション・ドメイン)を使用するためにOAMエージェントをプロビジョニングする際には、自動的に作成されたポリシーを拒否します。

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

- Oracle Access Manager 11gでのWebゲートのプロビジョニング・メソッドについて

- Oracle Access Manager 11gでのWebゲートのプロビジョニング

16.2.3.1 Oracle Access Manager 11gでのWebゲートのプロビジョニング・メソッドについて

このタスクは、セッション・トークン・メカニズム(ObSSOCookie)にのみ必要です。トラステッド・ヘッダー・アサーションまたはクリアテキスト・ヘッダー・メカニズムを実装している場合は、この項は省略してください。

表16-2は、OAM 11gで使用するためにWebゲートをプロビジョニングする際に使用できるメソッドとツールについて説明しています。リモート登録ツールを使用すると、テンプレートを使用して一部またはすべてのWebゲート・パラメータを指定できます。

表16-2 OAM 11g用のメソッドのプロビジョニング

メソッド

説明

Oracle Access Manager管理コンソール

Oracle Access ManagerでOAMの管理者が手動で情報を入力し、直接パラメータを設定できるようにします。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。

リモート登録

アプリケーションの管理者は、シングル・サインオン用のIDアサーション・プロバイダを実装する際に、コマンドラインを使用してWebゲートを登録できます。また、これによって新しいWeb層または既存のWeb層のセキュリティ・ポリシーを持つ新規アプリケーション・ドメインが作成されます。

必須パラメータは、テンプレートで指定する、環境に適した値を使用してプロビジョニングします。必須ではないパラメータについては、デフォルト値を使用します。登録が終了すると、Oracle Access Managerコンソールで値を変更できるようになります。

リモート登録の際には、表16-3に記載された詳細を指定する必要があります。

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのすべてのWebゲート・パラメータのリストに関する項

表16-3 OAMエージェントに必須の登録の詳細

OAMエージェントの要素

説明

<serverAddress>

ホストとポートを含む、Oracle Access Manager管理コンソールの実行中のインスタンスを指します。

<webDomain>

OSSOリクエスト専用

エージェント・ベースのURLが内部的に保存されているWebサーバー・ドメインを定義します。

<agentName>

OAM(管理)サーバーでのエージェントの一意な識別子を定義します。

同じサーバー・インスタンス上のエージェントごとにこのタグは一意にして、同一エージェントの再登録を回避する必要があります。

同一のサーバー・インスタンス上で1つのエージェントを再登録することはできません。

<hostIdentifier>

この識別子は、Webサーバーのホストを表しています。このフィールドは、OAMエージェント名の値を指定すると自動的に入力されます。同じ名前のエージェント名またはホスト識別子がすでに存在する場合には、登録時にエラーが発生します。

<protectedResourcesList>

一部の認証スキームでOAMエージェントを保護するリソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。

<publicResourcesList>

公開する(OAMエージェントで保護しない)リソースURLを指定します。リソースURLは、agentBaseUrlを基準とした相対パスである必要があります。たとえば、アプリケーションのホームページやようこそページを指定します。

16.2.3.2 Oracle Access Manager 11gでのWebゲートのプロビジョニング

このタスクは、セッション・トークン・メカニズム(ObSSOCookie)にのみ必要です。トラステッド・ヘッダー・アサーションまたはクリアテキスト・ヘッダー・メカニズムを実装している場合は、この項は省略してください。

Webゲートやアクセス・ゲートのプロビジョニングには、前述と同じ手順を実行します。認証プロバイダで使用する新規インスタンスのプロビジョニングや、プロバイダを構成する際に既存の登録の参照などができます。

この例では、OAMRequest_short.xmlテンプレートを使用してOAM 10g Webゲートをプロビジョニングします。登録されたエージェントは、my-wl-agent1と名付けられ、/.../*を保護し、パブリック・リソースの/public/index.htmlを宣言します。実際の値はこれとは異なります。

注意:

OAM 11g Webゲートのプロビジョニングでは、OAM11gRequest_short.xmlテンプレートを使用します。

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

OAM 11gでWebゲートをプロビジョニングするには

1. ツールの入手: Webゲートをホストするコンピュータ上でリモート登録ツールを入手し、使用する環境に合せてスクリプトを設定します。例:

1. 次のパスでRREG.tar.gzファイルを見つけます。

WLS_home/Middleware/domain_home/oam/server/rreg/client/RREG.tar.gz

2. RREG.tar.gzファイルを任意の適切な場所に展開します。例: rreg/bin/oamreg。

3. oamregスクリプトで、実際の状況がクライアント側であるかサーバー側であるかに応じて次の環境変数を設定し、さらにOracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの表6と表7にある情報を設定します。
OAM_REG_HOME = exploded_dir_for_RREG.tar/rreg
JDK_HOME = Java_location_on_the_computer

2. 登録リクエストの作成:

1. *Request_short.xmlファイルを探し、新しい場所にコピーして名前を付けます。例:

WLS_home/Middleware/domain_home/oam/server/rreg/bin/oamreg/

コピー元ファイル: OAMRequest_short.xml(またはOAM 11gRequest.xml)

コピー先ファイル: my-wl-agent1.xml

2. my-wl-agent1.xmlを編集して、環境の詳細を指定し、自動ポリシーの作成をfalseに設定します。例:

<OAMRegRequest>
<serverAddress>http://sample.us.oracle.com:7001</serverAddress>
<hostIdentifier>my-wl</hostIdentifier>
<agentName>my-wl-agent1</agentName>
<primaryCookieDomain>.us.example.com</primaryCookieDomain>
<autoCreatePolicy>false</autoCreatePolicy>
<logOutUrls><url>/oamsso/logout.html</url></logOutUrls>
</OAMRegRequest>

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの登録リクエストの作成に関する項

3. エージェントをプロビジョニングします。例:

1. リモート登録スクリプトを見つけます。
Linuxの場合: rreg/bin/oamreg.sh
このスクリプトに実行のパーミッションがあることの確認: chmod +x oamreg.sh

Windowsの場合: rreg\bin\oamreg.bat

2. スクリプトが存在するディレクトリから、inbandモードを使用してこのスクリプトを実行します。例:
$ ./bin/oamreg.sh inband input/my-wl-agent1.xml

Welcome to OAM Remote Registration Tool!
Parameters passed to the registration tool are:
Mode: inband
Filename: ...

3. プロンプトが表示されたら、環境に応じた値を使用して次の情報を入力します。

Enter your agent username: userame
Username:  userame
Enter agent password: ********
Do you want to enter a Webgate password?(y/n)
n
iv.Do you want to import an URIs file?(y/n)
n

4. 最後のメッセージを参照して、正常な登録が行われたことを確認します。

Inband registration process completed successfully! Output artifacts are
created in the output folder"

4. コンソールの確認: Oracle Access Managerコンソールにログインして、新規登録を確認します。

1. OAM 11gコンソールの「システム構成」タブから、「Access Managerの設定」セクションに移動し、「SSOエージェント」ノードを開いて、プロビジョニングしたエージェントを検索します。
Access Managerの設定
SSOエージェント
OAMエージェント
検索

2. 「検索結果」表で、エージェント名をクリックして登録のページを表示し、詳細を確認します。これは後で使用します。例:
エージェント名: Webゲートのインストール時に、WebゲートIDとして入力します。カスタム10gアクセス・ゲートをデプロイする場合は、WebLogic管理コンソールでOAM認証プロバイダを構成する際に、これをアクセス・ゲート名として入力します。

アクセス・クライアント・パスワード: Webゲートのインストールの際に、Webゲートのパスワードとして入力します。パスワードを入力しなかった場合、このフィールドは空白のままでかまいません。

アクセス・サーバー・ホスト名: このWebゲートの登録先とするプライマリOAM 11gサーバーのDNSホスト名を入力します。

3. OAMプロキシ・ポート: Oracle Access Managerコンソールの「システム構成」タブで、「共通構成」セクションに移動し、「サーバー・インスタンス」を開いて、OAMプロキシが実行中のポートを検索します。

5. プロビジョニングの際に作成されたObaccessclient.xmlファイルは、この段階では無視します。

6. それぞれの環境に応じて次の手順を実行します。

- エージェントをインストール済の環境: 実装に応じて、次の適切な項に移動します。

- Oracle Access Manager 11gでのSSO用のIDアサーションの構成

- Oracle Access Manager 11g用の認証プロバイダ機能の構成

- Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成

- Oracle Access Manager 11g用の集中管理ログアウトの構成

- エージェントをインストールしていない環境:
11g WebGateの場合: 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』を参照してください。

10g WebGateの場合: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドを参照してください。

16.2.4 Oracle Access Manager 11gでのSSO用のIDアサーションの構成

この項では、アプリケーションでのシングル・サインオン用のOracle Access Manager 11g IDアサーションの構成に必要な固有の手順について説明します。

タスクの概要: OAM 11gでのSSO用IDアサーション・プロバイダのデプロイ

1. 実装しているメカニズムに対するすべての前提条件タスクの完了

- Oracle Access Manager 11gでの認証プロバイダのインストール

- Oracle Access Manager証明書のJavaキーストア形式への変換

- セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング

2. Oracle WebLogic Serverとの間の信頼の確立

3. WebLogicドメインでのプロバイダの構成

4. トラステッド・ヘッダー・アサーション: デジタル署名検証の構成

5. トラステッド・ヘッダー・アサーション: ポリシーの構成

6. Oracle Access Manager 11g用の集中管理ログアウトの構成

7. ユーザーとSSOセッションの同期: SSO同期フィルタ

8. シングル・サインオン用のOracle Access Manager IDアサーションのテスト

16.2.4.1 Oracle WebLogic Serverとの間の信頼の確立

次の各項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。

タスクの概要: Oracle WebLogic Serverとの間の信頼の確立

1. シングル・サインオン用のIDアサーション・プロバイダでのアプリケーション認証方式の設定

2. Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認

3. クリアテキスト・ヘッダー: Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

16.2.4.1.1 シングル・サインオン用のIDアサーション・プロバイダでのアプリケーション認証方式の設定

この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』

Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。

WebLogic Serverのhost:portを介して直接アプリケーションにアクセスし、コンテナで認証されるようにする場合は、ここにカンマで区切った複数の値を指定できます。たとえば、<auth-method>CLIENT-CERT,FORM</auth-method>とします。

auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。

IDアサーション・プロバイダのweb.xmlで認証を指定するには

1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。

my_app/WEB-INF/web.xml

2. login-configでauth-methodを検索し、CLIENT-CERTと入力します。

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>

3. ファイルを保存します。

4. アプリケーションを再デプロイして再起動します。

5. アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。

6. 「Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認」に進みます。

16.2.4.1.2 Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認

Oracle HTTP Serverには、mod_weblogicプラグイン・モジュール(11gではmod_wl_ohs.so)が含まれており、すでに有効になっています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。

Oracle HTTP Server 11gを使用する場合、mod_weblogic構成がmod_wl_ohs.confにデフォルトで含まれ、このファイルのパスがhttpd.confに含まれます。mod_weblogic構成が存在しない場合は、httpd.confを編集する必要があります。

Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicを構成するには

1. httpd.confを見つけます。例:

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

2. ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します(必要に応じてコメントを追加または削除します)。

<IfModule mod_weblogic.c>
WebLogicHost myHost.myDomain.com
WebLogicPort myWlsPortNumber
</IfModule>

<Location http://request-uri-pattern>
SetHandler weblogic-handler
</Location>

3. ファイルを保存します。

4. 実装に応じて次の手順を実行します。

- クリアテキスト・ヘッダー: Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

- WebLogicドメインでのプロバイダの構成

16.2.4.1.3クリアテキスト・ヘッダー: Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。

注意:

このフィルタは、IDアサーションをクリア・テキスト・ヘッダー・メカニズムとともに使用する場合に、セキュリティ上必要になります。他のメカニズムを使用する場合は、このタスクはオプションです。

ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。これは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。

接続フィルタを構成してmod_weblogicとOHS 11gが実行されているホストからのリクエストのみを許可するには、ここで説明する手順を実行します。

注意:

この章では、Apache用WebLogic Serverプラグインの汎用名(mod_weblogic)を使用します。Oracle HTTP Server 11gの場合、このプラグインの名前はmod_wl_ohsで、実際のバイナリ名はmod_wl_ohs.soです。例では実装のための正確な構文を示します。

WebLogic Serverでは、デフォルト接続フィルタweblogic.security.net.ConnectionFilterImplが提供されます。このフィルタは、すべての着信接続を受け入れ、サーバーによる現在の接続フィルタの取得を許可する静的ファクトリ・メソッドも提供します。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力します。

また、weblogic.security.netパッケージにクラスを実装することにより、カスタム接続フィルタを使用することもできます。デフォルト接続フィルタと同様、カスタム接続フィルタはWebLogic Server管理コンソールで構成します。

接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。

targetAddress localAddress localPort action protocols

表16-4は、接続フィルタの各パラメータを説明しています。

表16-4 接続フィルタ・ルール

パラメータ

説明

target

フィルタ対象の1つ以上のシステムを指定します。

localAddress

WebLogic Serverインスタンスのホスト・アドレスを定義します。(アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます。)

localPort

WebLogic Serverインスタンスのリスニング・ポートを定義します。(アスタリスク(*)を指定すると、サーバー上のすべての使用可能なポートが返されます。)

action

実行するアクションを指定します。この値は、allowまたはdenyである必要があります。

protocols

フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。

「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項

Oracle HTTP Serverホストからのリクエストを許可するための接続フィルタを構成する手順は次のとおりです。

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構成」の下の「ドメイン」をクリックします。

3. 「セキュリティ」タブ→「フィルタ」タブをクリックします。

4. 「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。

5. ドメインで使用する次の接続フィルタを指定します。

- デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。

- カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。

6. 適切な接続フィルタ・ルールの構文を入力します。

7. 「保存」をクリックします。

8. Oracle WebLogic Serverを再起動します。

9. 「WebLogicドメインでのプロバイダの構成」に進みます。

16.2.4.2 WebLogicドメインでのプロバイダの構成

ここでの情報は、OAM 11gおよびOAM 10gに同じように当てはまります。この項の内容は次のとおりです。

- Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて

- Oracle WebLogic Scripting Tool (WLST)について

- ADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成

- Oracle Access Manager 11g IDアサーションのプロバイダの設定

16.2.4.2.1 Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて

この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。

WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ(および複数のLoginModule)をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。

Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。

- デフォルトのWebLogic認証プロバイダ(デフォルトの認証プロバイダ)では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。

- IDアサーションは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。これは、インストール済Webゲート(10gまたは11g)の適切なアクションを使用するように構成する必要があります。

- LDAP認証プロバイダは、ユーザーおよびグループ情報を外部LDAPサーバーに格納します。このプロバイダは主に、一般的なディレクトリ・スキーマが反映されるように、対応するLDAPサーバーがデフォルトで構成されている点が異なります。
Oracle WebLogic Server 10.3.1以降では、OracleInternetDirectoryAuthenticatorを使用できます。

複数の認証プロバイダを構成する場合、各プロバイダに対してJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの使用方法を制御します。たとえば、次のJAAS制御フラグ設定を選択できます。

- REQUIRED: 認証プロバイダが常に呼び出され、ユーザーはその認証テストを常にパスする必要があります。認証の成否に関係なく、プロバイダ・リストの最後まで認証が続行されます。

- SUFFICIENT: ユーザーは、認証プロバイダの認証テストをパスする必要はありません。認証に成功した場合、後続の認証プロバイダは実行されません。認証に失敗した場合、プロバイダ・リストの最後まで認証が続行されます。

- OPTIONAL: ユーザーは、認証プロバイダの認証テストをパスしても失敗してもかまいません。ただし、セキュリティ・レルムに構成されているすべての認証プロバイダでJAAS制御フラグがOPTIONALに設定されている場合は、ユーザーは構成されているプロバイダのいずれかの認証テストをパスする必要があります。

既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。場合によっては、認証シーケンスで各認証プロバイダが適切に機能するように、制御フラグの設定とプロバイダの順序を変更する必要があります。

関連項目:

すべての認証プロバイダのリストと、ユーザーおよびグループ属性をLDAPスキーマと一致させるためのOracle Internet Directoryプロバイダの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。

16.2.4.2.2 Oracle WebLogic Scripting Tool (WLST)について

この項では、WLSTを初めて使用するユーザーのために、WLSTについて説明します。

Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して、WebLogicドメインにプロバイダを追加できます。

WLSTはJythonベースのコマンドライン・スクリプト環境で、WebLogic Serverドメインの管理と監視のために使用できます。通常、このツールはオンラインまたはオフラインで使用できます。このツールは、ファイルで提供されるバッチ(ユーザーの入力を介在せずに、スクリプトが一連のWLSTコマンドを呼び出すスクリプト・モード)において、コマンドラインで対話的に実行することができます。また、Javaコードに組み込むことも可能です。

WebLogicドメインに認証プロバイダを追加する場合、WLSTをオンラインで使用して認証プロバイダと対話し、ユーザー、グループおよびロールを追加、削除または変更できます。

WLSTをオフラインで使用してドメイン・テンプレートを作成する場合、WLSTによって認証プロバイダのデータ・ストアとその他のドメイン文書がパッケージ化されます。ドメイン・テンプレートからドメインを作成すると、新しいドメインは、ドメイン・テンプレートの認証プロバイダのデータ・ストアとまったく同じコピーになります。ただし、WLSTをオフラインで使用して認証プロバイダのデータ・ストア内のデータを変更することはできません。

注意:

WLSTをオフラインで使用して、認証プロバイダのデータ・ストア内のデータを変更することはできません。

関連項目:

- 「ADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「インフラストラクチャ・セキュリティ・コマンド」

16.2.4.2.3 ADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成

Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Oracle Access Manager Single Sign On (SSO)と統合し、ユーザー認証にOracle Platform Security Services (OPSS) SSOを使用するWebアプリケーションをOracle WebLogic Server上で実行できます。ただし、Webアプリケーションを実行する前に、アプリケーションのターゲットのOracle WebLogic Server上で、Oracle Access Managerセキュリティ・プロバイダ用にドメインレベルのjps-config.xmlファイルを構成する必要があります。

ドメインレベルのjps-config.xmlファイルは次のパスに存在します。デプロイ済のアプリケーションのjps-config.xmlファイルと混同しないでください。

domain_home/config/fmwconfig/jps-config.xml

Webアプリケーションのデプロイ前またはデプロイ後に、Oracle Access Manager固有のWLSTスクリプトを使用して、ドメインレベルのjps-config.xmlファイルを構成できます。このOracle JRF WLSTスクリプトの名前は次のとおりです。

Linux: wlst.sh

Windows: wlst.cmd

JDevを使用して実行している場合、Oracle JRF WLSTスクリプトは次のパスにあります。

$JDEV_HOME/oracle_common/common/bin/

JRF WebLogicをスタンドアロンでインストールしている場合のパスは次のとおりです。

$Middleware_home/oracle_common/wlst

注意:

Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files (JRF)用のWLSTを実行している場合は、$JDEV_HOME/wlserver_10.3/common/binにあるWLSTスクリプトを使用しないでください。

コマンド構文

addOAMSSOProvider(loginuri, logouturi, autologinuri)

表16-5では、addOAMSSOProviderコマンドラインにおける各引数の期待値を定義しています。

表16-5 addOAMSSOProviderコマンドライン引数

引数

定義

loginuri

ログイン・ページのURIを指定します。

autologinuri

自動ログイン・ページのURIを指定します。

logouturi

ログアウト・ページのURIを指定します。

関連項目:

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「インフラストラクチャ・セキュリティ・コマンド」

前提条件

WebLogicドメインでのプロバイダの構成

Oracle ADFセキュリティが有効なFusion Webアプリケーション用のドメインレベルのjps-config.xmlを変更するには:

1. Oracle WebLogic ServerおよびOracle ADFセキュリティを使用しているWebアプリケーションをホストするコンピュータ上で、Oracle JRF WLSTスクリプトを見つけます。例:

cd $ORACLE_HOME/oracle_common/common/bin

2. Oracle WebLogic Serverをホストするコンピュータに接続します。

connect login_id password hostname:port

たとえば、Oracle WebLogic管理サーバーのホストは、ポート7001を使用するlocalhostであることが考えられます。ただし、これは使用する環境によって異なる可能性があります。

3. ADFセキュリティが有効なアプリケーション用の値を使用して、次のコマンドライン引数を入力します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")

4. Oracle WebLogic Serverを停止して起動します。

5. 次の項で説明されているタスクを実行します。

- Oracle Access Manager 11g IDアサーションのプロバイダの設定

- Oracle Access Manager 11g用の集中管理ログアウトの構成

- シングル・サインオン用のOracle Access Manager IDアサーションのテスト

16.2.4.2.4 Oracle Access Manager 11g IDアサーションのプロバイダの設定

この項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。

- OAM IDアサーション・プロバイダ: REQUIRED(使用しているメカニズムに対する選択済アクティブ・タイプも指定します(表15-1))。

- OID認証プロバイダ: SUFFICIENT

- デフォルトの認証プロバイダ: SUFFICIENT

関連項目:

「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

次の手順では、WebLogic管理コンソールを使用します。

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。ステップ1を省略してください。

シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。

oamAuthnProvider<version number>.zip

3. Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle Fusion Middlewareアプリケーションをインストール済の場合:

1. 次のパスでoamauthenticationprovider.warを見つけます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
der.war

2. oamauthenticationprovider.warを次の場所にコピーします。

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

3. WebLogic管理コンソールにログインします。

4. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

5. OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。

1. 「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OAM Identity Asserter

タイプ: OAMIdentityAsserter

OK

2. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

3. 「共通」タブをクリックし、「制御フラグ」をREQUIREDに設定します。

4. 「共通」タブで、使用しているSSOメカニズムに対する選択済アクティブ・タイプを1つ指定します(表15-1)。例:
OAM_IDENTITY_ASSERTION

5. 構成を保存します。

6. OID認証プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator

タイプ: OracleInternetDirectoryAuthenticator

OK

3. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

4. 「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。

5. 「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。

ポート: LDAPホストのリスニング・ポート。例: 6050。

プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。

資格証明: LDAPの管理ユーザー・パスワード。

ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。

すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))

ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。

グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。

デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。

保存します。

7. デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。

3. 「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。

4. 保存します。

8. プロバイダを並べ替えます。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。

3. 「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)

OID認証プロバイダ: (SUFFICIENT)

デフォルトの認証プロバイダ: (SUFFICIENT)

4. 「OK」をクリックして変更を保存します。

9. 変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。

10. Oracle WebLogic Serverを再起動します。

11. 次のようにします。

- 成功: 実装に応じて次の手順を実行します。
トラステッド・ヘッダー・アサーション: デジタル署名検証の構成

シングル・サインオン用のOracle Access Manager IDアサーションのテスト

- 失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。

前述のとおり、10g Webゲートに付属のログイン・フォームは、OAM 10gアクセス・サーバーでのみ使用します。OAM 11gの場合、10g Webゲートでも11g Webゲートでもログイン・ページは提供されません。

注意:

OAM 11g Serverでは、ログイン・ページが表示されます。設定は必要ありません。

16.2.4.3 トラステッド・ヘッダー・アサーション: デジタル署名検証の構成

これは手動で行うタスクです。デジタル署名検証には、Oracle Access Manager証明書の公開鍵が必要です。IDアサーション・プロバイダによって使用される証明書は、.oamkeystoreに格納されている必要があります。

SSO同期フィルタが証明書を使用するには、フィルタに対してトラスト・ストアを指定する必要があります。SSO同期フィルタの動作は、WebLogicに各種の優先システム・プロパティを渡すことにより、アプリケーションの要件に応じて変更できます。これには、Oracle WebLogicの起動スクリプト(setDomainEnv.sh)で、EXTRA_JAVA_PROPERTIESの下にプロパティを追加します。トラスト・ストアの場所はシステム・プロパティとして指定できます。デフォルトでは、フィルタはssofilter.jarの場所でキーストアを探します。見つからない場合は、次にシステム・プロパティ内を探します。

次の手順は、エクスポートおよびインポート操作を実行するために必要な.oamkeystoreパスワードの取得方法を示します。必要なOAM証明書をエクスポートおよびインポートしたら、IDアサーション・プロバイダが証明書を使用できるように、キーストアをプロビジョニングします。最後に、OAM_IDENTITY_ASSERTIONトークン・タイプを選択し、SSO同期フィルタ内で証明書をプロビジョニングして、認可ポリシーでIDアサーションが有効になっていることを確認します。

トラステッド・ヘッダー・アサーション用にデジタル署名検証を構成する手順は次のとおりです。

1. WLSTスクリプト・ツールを使用して、次のように.oamkeystoreパスワードを取得します。

1. $MW_HOME/Oracle_IDM1/common/binでWLSTツールを探します。

2. wlst.sh($ ./wlst.sh)を実行します。

3. 画面に表示される次のメッセージで実行を確認します。

Initializing WebLogic Scripting Tool (WLST) ...

Jython scans all the jar files it can find at first startup. Depending on
the system, this process may take a few minutes to complete, and WLST may
not return a prompt right away

Welcome to WebLogic Server Administration Scripting Shell

Type help() for help on available commands

4. wls:/offline> connect()を実行し、環境に対する情報(WebLogic管理者のユーザー名とパスワードおよびAdminServerのURL)を指定します。例:

Please enter your username: weblogic
Please enter your password: password
Please enter your server URL //localhost:7001
not return a prompt right away

Connecting to ...
Successfully connected to Admin Server 'AdminServer' ... domain 'base_domain'.

Warning: An insecure protocol was used to connect to the server.
To ensure on-the-wire security, the SSL port or Admin port should be used
instead.
wls:/base_domain/serverConfig

5. wls:/base_domain/serverConfig> domainRuntime()を実行し、画面に表示される次のメッセージを確認します。例:

Location changed to domainRuntime tree. This is a read-only tree with
DomainMBean as the root

For more help, use help(domainRuntime)

wls:/base_domain/domainRuntime>

6. wls:/base_domain/domainRuntime> listCred(map="OAM_STORE",key="jks")を実行します。例:

Already in Domain Runtime Tree
PASSWORD: lleoi4sbkpo3bj8fg55k7jgbgh
wls:/base_domain/domainRuntime>

2. JDK6 keytoolを使用して、次のように別名を証明書ファイルにエクスポートします。

jdk/bin]$ keytool -exportcert -alias "assertion-cert" -keystore .oamkeystore
-storepass gtml6es9qderjc66f76hvtqm5a -storetype JCEKS -file assertion.cer

3. JDK6 keytoolを使用して、次のように証明書ファイルをインポートします。

注意:

キーストア別名oam.assertion.certおよびキーストア名oamiap-keystore.jksは固定です。これらの名前のみ使用してください。

jdk/bin $ keytool -importcert -trustcacerts -alias "oam.assertion.cert" -file
assertion.cer -keystore /scratch/oamiap-keystore.jks -storepass password
-storetype JKS

4. oamiap-keystore.jks内の公開鍵を使用して、OAM証明書を使用できるように、IDアサーション・プロバイダのキーストアをプロビジョニングします。

1. WebLogicコンソールのセキュリティ・レルムの下のIDアサーション・プロバイダ・エントリで、プロバイダ固有の構成にoamiap-keystore.jksの絶対パスを追加します。

2. プロバイダ固有の構成で、トークン・タイプOAM_IDENTITY_ASSERTIONを選択します。

3. この構成を保存します。

5. 次のように、SSO同期ファイル内で.oamkeystoreをプロビジョニングします。
デフォルトでは、フィルタはssofilter.jarの場所でキーストアを探します。そこで見つからない場合は、システム・プロパティを調べます。

1. デフォルト構成: キーストア・ファイルoamiap-keystore.jksをssofilter.jarと同じ場所に置きます。例: $MW_HOME/oracle_common/modules/oracle.ssofilter_11.1.1

2. フォールバック・メカニズム: キーストア・ファイルoamiap-keystore.jksを、setDomainEnv.sh($MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.sh)でシステム・プロパティとして設定します。

-Dsso.filter.oam.keystore=/scratch/keystore/oamiap-keystore.jks

6. 次のように、OAM_IDENTITY_ASSERTIONのシステム・プロパティを設定します。

1. WebLogic Serverを停止します。

2. $MW_HOME/user_projects/domains/base_domain/bin/setDomainEnv.shにある、setDomainEnv.shファイルを開きます。

3. 次のプロパティをEXTRA_JAVA_PROPERTIESの下に追加し、ファイルを保存します。

-Dsso.filter.ssotoken=OAM_IDENTITY_ASSERTION

7. WebLogic Serverを起動します。

8. 「トラステッド・ヘッダー・アサーション: ポリシーの構成」に進みます。

16.2.4.4 トラステッド・ヘッダー・アサーション: ポリシーの構成

アサーションのトークン・タイプとしてOAM_IDENTITY_ASSERTIONを使用するには、リソースを保護する認可ポリシーで「IDアサーション」オプションを有効にする必要があります。デフォルト・ポリシーはエージェントの登録時に生成されます。Oracle Access Managerコンソールを使用して手動でポリシーを作成することもできます。

図16-6に、トラステッド・ヘッダー・アサーション・メカニズムに対する認可ポリシーの例を示します。

図16-6 トラステッド・ヘッダー・アサーションに対する認可ポリシーの例

次の手順では、リソースを保護するOracle Access Manager 11gの認可ポリシー内でIDアサーションを有効にする方法を示します。

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

トラステッド・ヘッダー・アサーションに対してIDアサーションを有効にする手順は次のとおりです。

1. 「ポリシー構成」タブのナビゲーション・ツリーから次のノードを開きます。
アプリケーション・ドメイン
目的のドメイン
認可ポリシー
ポリシー名

2. 「IDアサーション」を有効にします(ボックスを選択します)。

3. リソース:

- 「リソース」タブで、適切なリソースがこのポリシーによって保護されていることを確認します。

- 必要に応じてリソースを追加または削除します。

4. 「適用」をクリックして変更を保存し、確認ウィンドウを閉じます。

5. 終了する場合はページを閉じます。

6. 「シングル・サインオン用のOracle Access Manager IDアサーションのテスト」に進みます。

16.2.4.5 シングル・サインオン用のOracle Access Manager IDアサーションのテスト

次の手順では、使用しているメカニズムにかかわらず、Oracle Access Manager IDアサーションの設定をテストする方法を示します。

また、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。

シングル・サインオン用のOracle Access Manager IDアサーションを検証するには

1. ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:

http://ohs_server:port/<protected url>

2. ログイン・フォームが表示されたら、適切な資格証明を入力します。

- 成功: 正常に実装されます。

- 失敗: 「トラブルシューティングのヒント」を参照してください。

16.2.5 Oracle Access Manager 11g用の認証プロバイダ機能の構成

認証プロバイダ機能を使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、Oracle Access Manager認証スキームが必要です。これは、Oracle Access Manager 11gで提供されている事前シード済アプリケーション・ドメインにあります。これは、次のリソース(resource type wl_authen)を保護します。

- /Authen/Basic

- /Authen/SSOToken

- /Authen/UsernameAssertion

ポリシーにはレスポンスと制約を追加できます。ただし、それ以外の構成は必要ありません。

事前シード済アプリケーション・ドメインの詳細は、「10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー」を参照してください。

前提条件

- Oracle Access Manager 11gでの認証プロバイダのインストール

- セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング

注意:

認証プロバイダで使用するカスタムの10gアクセス・ゲートをプロビジョニングすることも、認証プロバイダのプロバイダの構成時に既存のOAMエージェント登録を参照することもできます。

Oracle Access Manager認証プロバイダを構成するためのタスクについては、次の概要で説明します。

タスクの概要: OAM用の認証プロバイダ機能の構成には次の手順が含まれます。

1. 前提条件のすべてのタスクが実行されていることの確認

2. WebLogicドメインでの認証プロバイダの構成

3. 認証プロバイダのアプリケーション認証方式の構成

4. LDAP内のグループへの認証ユーザーのマッピング

5. Oracle Access Manager 11g用の集中管理ログアウトの構成

6. Oracle Access Manager認証プロバイダの実装のテスト

16.2.5.1 WebLogicドメインでの認証プロバイダの構成

この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。

Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。

- デフォルトの認証プロバイダ: SUFFICIENT

- OAM認証プロバイダ: OPTIONAL

次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool (WLST)を使用して追加することもできます。

関連項目:

- 「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なファイルはすでにインストールされているので、ステップ1は省略できます。

WebLogicドメインにOracle Access Manager認証プロバイダを構成するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:

oamAuthnProvider<version>.zip

3. Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle WebLogic管理コンソールに移動します。

3. Oracle Fusion Middlewareアプリケーションをインストール済の場合:

1. 次のパスでoamauthenticationprovider.warを見つけます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
der.war

2. oamauthenticationprovider.warを次の場所にコピーします。

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

4. Oracle WebLogic管理コンソールに移動します。

5. 必要に応じて、「ロックして編集」をクリックします。

6. OAM認証プロバイダ:

1. 「セキュリティ・レルム」をクリックし、構成するレルムを選択します。

2. 「プロバイダ」→「認証」を選択し、「新規」をクリックして、「新しい認証プロバイダの作成」ページを表示します。

3. 名前を入力して、タイプを選択します。
名前: OAMAuthN

タイプ: OAMAuthenticator

OK

4. 作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。

5. 「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、Oracle Access ManagerコンソールのOAMエージェント登録の名前と完全に一致している必要があります。

注意:

OAM 11gでは1つ以上の10g OAMエージェントを登録できます。正しいエージェント登録名を選択してください。

アクセス・ゲートのパスワード: エージェント登録に対してパスワードが定義されている場合は、それと同じパスワード(Oracle Access Managerコンソールを参照)。

プライマリ・アクセス・サーバー: Oracle Access Managerコンソールでこのアクセス・ゲートに関連付けられているプライマリOAMサーバーのhost:port。

詳細構成: 次に、いくつかの詳細構成の値を示します。

トランスポート・セキュリティ: OAMサーバーとアクセス・ゲート間の通信モード(オープン、簡易、証明書)。

トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。

トラスト・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSトラスト・ストアの絶対パス。

キー・ストア: プロバイダとOAM Server間のSSL通信で使用するJKSキー・ストアの絶対パス。

キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。

簡易モード・パスフレーズ: アクセス・ゲートとOAM Serverで共有する簡易通信モード用パスワード。

セカンダリOAMサーバー: Oracle Access Managerコンソールでこのアクセス・ゲートに関連付けられているセカンダリOAMサーバーのhost:port。

プール内の最大OAMサーバー接続数: アクセス・ゲートがOAMサーバーに対してオープンする最大接続数。デフォルト値は10です。

注意:

WebLogic管理コンソールで指定するプール内の最大OAMサーバー接続数(またはプール内の最小OAMサーバー接続数)の設定は、Oracle Access Managerコンソールで指定する「最大接続数」や「最小接続数」とは異なります。

プール内の最小アクセス・サーバー接続数: 認証プロバイダからOAMサーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は5です。

関連項目:

共通パラメータとプロバイダ固有パラメータの説明と値については、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。

6. パラメータ「制御フラグ」がOPTIONALに初期設定されていることを確認します。

注意:

認証プロバイダが機能し、正しく構成されていることを確認するまで、パラメータ「制御フラグ」をREQUIREDに設定しないでください。

7. チェンジ・センターで、変更のアクティブ化をクリックします。

8. DefaultAuthenticator: 「プロバイダ」タブでDefaultAuthenticatorを選択します。これにより、その制御フラグがSUFFICIENTに変更されます。

9. 並べ替え: 「プロバイダ」タブで、DefaultAuthenticatorが先頭になるように(DefaultAuthenticatorの後にOAMAuthenticator)プロバイダを並べ替えます。

注意:

Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。

10. Oracle Access Manager認証プロバイダのREQUIREDまたは唯一の認証プロバイダである場合: 次の手順を実行して、Oracle WebLogic Serverを起動するためのユーザー権限を設定します。

1. 管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。

注意:

その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。

2. Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。

3. WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。

4. Adminロールの「条件の表示」を選択します。

5. グループを追加して「保存」をクリックします。

11. WebLogic Serverを再起動します。

12. サーバーを起動すると、認証プロバイダ・パラメータ「制御フラグ」が適切な値(REQUIRED、OPTIONAL、またはSUFFICIENT)にリセットされます。

注意:

推奨値は、REQUIREDです。既知の問題を防止するには、「JAAS制御フラグ」を参照してください。

13. 「認証プロバイダのアプリケーション認証方式の構成」に進みます。

16.2.5.2 認証プロバイダのアプリケーション認証方式の構成

この項では、Oracle Access Manager認証プロバイダのアプリケーション認証方式の作成方法について説明します。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』

Oracle Access Manager認証プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をBASICに指定する必要があります。

auth-methodには、BASICまたはFORMの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。

注意:

Oracle Access Manager認証プロバイダの場合、web.xml内のlogin-configにauth-method BASICを指定することをお薦めします。

認証プロバイダのアプリケーション認証方式を構成するには

1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。

WEB-INF/web.xml

2. login-configでauth-methodを検索し、BASICと入力します。例:

<security-constraint>
<web-resource-collection>
<web-resource-name>protected</web-resource-name>
<url-pattern>/servlet</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>auth-users</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<description>Authenticated Users</description>
<role-name>auth-users</role-name>
</security-role>

3. ファイルを保存します。

4. アプリケーションを再デプロイして再起動します。

5. アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。

6. 「LDAP内のグループへの認証ユーザーのマッピング」に進みます。

16.2.5.3 LDAP内のグループへの認証ユーザーのマッピング

この項では、認証ユーザーをLDAP内のグループにマップする方法について説明します。このためには、weblogic.xmlファイルを編集する必要があります。たとえば、ロール名auth-usersをLDAP内のmanagersというグループにマップできます。

Oracle Access Manager認証プロバイダ用に認証ユーザーをLDAP内のグループにマップするには

1. アプリケーションのweblogic.xmlファイルに移動します。

2. ファイル内の任意の場所に、環境に応じて次の情報を追加します。

<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>

3. ファイルを保存します。

4. WebLogic Serverを再起動します。

5. 「Oracle Access Manager 11g用の集中管理ログアウトの構成」に説明されているように集中管理ログアウトを構成し、ここに戻ってOracle Access Manager認証プロバイダの実装のテストを実行します。

16.2.5.4 Oracle Access Manager認証プロバイダの実装のテスト

認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。

次の手順では、認証プロバイダの設定をテストする方法について説明します。また、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドの説明にあるように、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。

Oracle Access Manager認証プロバイダの実装を検証するには

1. ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:

http://yourdomain.com:port

2. ログイン・フォームが表示されたら、適切な資格証明を入力します。

- 成功: 正常に実装されます。

- 失敗: 「トラブルシューティングのヒント」を参照してください。

16.2.6 Oracle Web Services ManagerおよびOAM 11g用のIDアサーションの構成

この項では、Oracle Web Services ManagerでWebサービスを保護している場合に、トークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。

前述のとおり、Oracle Access Manager IDアサーション・プロバイダは2つのモードで機能します。デフォルト・モードの操作では、Webゲートが境界で設定したヘッダーがアサートされます。これで、ほとんどのSSOの処理を扱うことができます。もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合、ヘッダーが存在しないと、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager 11gでの認証プロバイダのインストール」を参照してください。

注意:

Oracle Web Services ManagerのIDアサーション・プロバイダには、認証プロバイダが提供する10gカスタム・アクセス・ゲートが必要です。

OAM 10gでは、ポリシー・ドメインおよびこの構成に対応するポリシーの手動での作成が必要になることがあります。一方、OAM 11gでは、次のリソース(resource type wl_authen)を保護するポリシーを設定した事前シード済アプリケーション・ドメインが提供されます。

- /Authen/Basic

- /Authen/SSOToken

- /Authen/UsernameAssertion

タイプwl_authenのリソースのポリシー、レスポンスおよび制約のみを追加できます。ただし理論上はこのアプリケーション・ドメインは構成を追加することなく使用することができます。詳細は、「10gアクセス・ゲートで使用される事前シード済OAM 11gポリシーのプレビュー」を参照してください。

Oracle Access Manager IDアサーション・プロバイダがヘッダーとトークンの両方の検証モードで構成されている場合、ヘッダー検証モードが優先します。ヘッダーが存在しない場合、IDアサーション・プロバイダはOAMサーバーにアクセスしてトークンを検証します。トークンの詳細は、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。

前提条件

Oracle Access Manager 11gでの認証プロバイダのインストール

セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング

タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ

1. Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成

2. Oracle Access Manager 11g用の集中管理ログアウトの構成

3. Oracle Web Services Manager用のIDアサーション・プロバイダのテスト

16.2.6.1 Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成

Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。

- OAM IDアサーション・プロバイダ: REQUIRED

- OID認証プロバイダ: SUFFICIENT

- デフォルトの認証プロバイダ: SUFFICIENT

この手順は、OAM 11gでのOracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。

- プライマリ・アクセス・サーバー: プライマリOAMサーバーのホストとポートを指定します。例: mnop:8888。

- アクセス・ゲート名: アプリケーションを保護するアクセス・ゲート登録の名前。例: AG1。

- アクセス・ゲートのパスワード: Oracle Access Managerコンソールで指定したアクセス・ゲート・パスワード。

これらは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して追加できます。

関連項目:

- 「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダ・ファイルはすでにインストールされています。ステップ1を省略してください。

WebLogicドメインでプロバイダを設定するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:

oamAuthnProvider<version>.zip

3. Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle WebLogic管理コンソールにログインします。

3. OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter

タイプ: OAMIdentityAsserter

OK

3. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

4. 「共通」タブで、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。

5. 「共通」タブをクリックして、10gカスタム・アクセス・ゲートの選択済アクティブ・タイプとしてObSSOCookieを指定し、「保存」をクリックします。

6. 「プロバイダ固有」タブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: プライマリOAMサーバーのホストとポートを指定します。例: abcd:7777。

アクセス・ゲート名: アプリケーションを保護するOAMエージェントの登録名。例: AG1。

アクセス・ゲートのパスワード: プロビジョニングの際に指定したアクセス・ゲート・パスワードがあれば、そのパスワード。

保存します。

4. OID認証プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator

タイプ: OracleInternetDirectoryAuthenticator

「OK」をクリックします。

3. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

4. 「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。

5. 「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。

ポート: LDAPホストのリスニング・ポート。例: 6050。

プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。

資格証明: LDAPの管理ユーザー・パスワード。

ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。

すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))

ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。

グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。

注意:

デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。

「保存」をクリックします。

5. デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。

3. 「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。

4. 「保存」をクリックします。

6. プロバイダを並べ替えます。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。

3. 「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)

OID認証プロバイダ: (SUFFICIENT)

デフォルトの認証プロバイダ: (SUFFICIENT)

4. 「OK」をクリックして変更を保存します。

7. 変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。

8. Oracle WebLogic Serverを再起動します。

9. 次のようにします。

- 成功: 「Oracle Access Manager 11g用の集中管理ログアウトの構成」に進み、ここに戻って「Oracle Web Services Manager用IDアサーション・プロバイダのテスト」を実行します。

- 失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「Oracle Access Manager 11gでの認証プロバイダのインストール」の説明にあるように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。

16.2.6.2 Oracle Web Services Manager用のIDアサーション・プロバイダのテスト

Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダとの併用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスが許可されれば、実装は機能しています。失敗した場合は、「トラブルシューティングのヒント」を参照してください。

16.3 Oracle Access Manager 11g用の集中管理ログアウトの構成

この項では、Oracle Access Manager 11g用の集中管理ログアウトについて説明します。

OAM 11gでは、集中管理ログアウトとはアクティブなユーザー・セッションを終了するプロセスを意味します。ガイドラインの内容は次のとおりです。

- SSO環境で使用するアプリケーションは、自身のログアウト・ページを表示しないようにする必要があります。

- アプリケーションは、OAM Webゲート管理者が指定したログアウトURLを指す値でログアウト・リンクを構成できるようにする必要があります。

注意:

アプリケーションでADF認証サーブレットを使用することを強くお薦めします。これにより、このサーブレットはOPSSとインタフェース接続し、OPSSでドメイン全体の構成パラメータを使用してログアウトURLを指定できます。この方法であれば、ログアウトの構成を変更するためにアプリケーションの変更や再デプロイが必要になることがありません。

詳細は、次を参照してください:

- 「11g WebゲートおよびOAM 11gのログアウト」

- 「Oracle Access Manager 11gでの10g Webゲートのログアウト」

16.3.1 11g WebゲートおよびOAM 11gのログアウト

OAM 11gエージェントの登録ページのいくつかの要素によって、OAM 11g Webゲートの中央管理されたログアウトが有効になります。エージェントの登録後、その情報がObAccessClient.xmlファイルに移入されます。

エージェントの登録の際に指定する必要のある11g Webゲートのログアウトオプションには、次のものがあります。

- ログアウトURL: ログアウト・ハンドラをトリガーします。これにより、Cookie(10g Webゲート用ObSSOCookie、11g Webゲート用OAMAuthnCookie)が削除されるので、Oracle Access Managerで保護されたリソースにこのユーザーが次回アクセスする際には再認証が必要になります。

- ログアウト・コールバックURL: oam_logout_successへのURLです。コールバックの際にCookieを消去します。これには、host:portのないURI形式を指定できます(推奨)。これにより、OAMサーバーは元のリソース・リクエストのhost:portでコールバックします。

- ログアウト・リダイレクトURL: このパラメータには、エージェントの登録が完了すると自動的に情報が移入されます。デフォルトでは、ポートをデフォルトの14200としたOAMサーバーのホスト名に基づきます。

- ログアウト・ターゲットURL: この値は、ログアウトの際にOPSSアプリケーションがWebゲートに渡す問合せパラメータの名前です。この問合せパラメータは、ログアウト後のランディング・ページのターゲットURLを指定します。

詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOAM 11gサーバーによる11g WebGateの一元化されたログアウトの構成に関する項を参照してください。

16.3.2 Oracle Access Manager 11gでの10g Webゲートのログアウト

OAMエージェント(この場合は10g Webゲート)向けに構成されたlogout.htmlファイルをアプリケーションで呼び出すと、ログアウトが始まります。アプリケーションはend_urlも問合せ文字列としてlogout.htmlに渡します。end_urlパラメータはURIまたはURLとすることができます。

関連項目:

Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド

- OAM 10gエージェントおよびOAM 11gサービスの一元化されたログアウトについて

- 例15-5: logout.htmlのスクリプト

- OAMによる10g Webゲートの一元化されたログアウトの構成

タスクの概要: 10g Webゲート向けの中央管理ログアウトの構成。

1. デフォルトのログアウト・ページ(logout.html)を作成して、それをWebゲートのインストール・ディレクトリに置きます。例: WebGate_install_dir/oamsso/logout.html。

2. logout.htmlで、logOutUrlsパラメータが各リソースWebゲートに構成されていること、および<callBackUri>が「logOutUrls」の2番目の値であることを確認します。

3. logout.htmlで、(ステップ1から)確認し、ユーザーがOAM 11g Server上の中央ログアウトURI「/oam/server/logout」にリダイレクトされていることを確認します。

4. オプション: ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータをアプリケーションで渡すことができます。

5. 10g Webゲートを構成したOHS Webサーバー構成ファイルhttpd.confを確認し、次の行が存在する場合には削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのOAM 11gサーバーによる10g WebGateの一元化されたログアウトの構成に関する項を参照してください。

16.4 ユーザーとSSOセッションの同期: SSO同期フィルタ

Fusion Middleware 11gには、コンテナ・ユーザー・セッションとSSOセッションを同期する新しいコンポーネントが導入されています。SSO同期フィルタは、Oracle WebLogicシステム・フィルタの実装です。SSO同期フィルタは、コンテナへのすべてのリクエストをインターセプトし、保護されたリソース・リクエストを操作して、コンテナのユーザー・セッションとOSSOのユーザー識別ヘッダー(Proxy-Remote-User)、またはOracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データとの同期を試みます。

SSO同期フィルタは、Javaサーブレット仕様バージョン2.3に基づくサーブレット・フィルタの実装です。SSO同期フィルタにより、アプリケーションはSSOユーザー・セッションを追跡して各セッションと同期する必要がなくなります。アプリケーションは、コンテナのユーザー・セッションと同期するだけで済みます。

SSO同期フィルタは、コンテナへの各リクエストをインターセプトし、そのリクエストに添付されているHTTPヘッダーに基づいて操作するかどうかを決定します。フィルタは、SSOエージェントがこれらのヘッダーをWeb層で設定していることを必要とします。保護されていないアプリケーション領域にアクセスする場合、フィルタはパススルーとして機能します。保護されたリソースにアクセスした後、Web層のSSOエージェントは、Oracle Access ManagerなどのSSOシステムで認証を実行するようユーザーに指示します。認証後、Oracle Access Manager IDアサーション・プロバイダによってユーザー・アイデンティティがJAASサブジェクトとしてコンテナに確立され、ユーザー・セッションが作成されます。WebLogicでは、ユーザー・セッション・データがHTTPセッションCookieの一部(JSESSIONID)として保持されます。

アプリケーション・リソースへの後続アクセスでは、SSO同期フィルタに次の2つの情報が提供されます。

- OSSOのユーザー識別ヘッダー(Proxy-Remote-User)

- Oracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データ

SSO同期フィルタの役割は、コンテナのユーザー・アイデンティティとSSOセッションのユーザー・アイデンティティが一致していることを確認することです。不一致がある場合、フィルタはそのコンテナのユーザー・セッションを無効にします。このため、ダウンストリーム・アプリケーションはコンテナのユーザー・セッションを追跡するだけで済み、使用しているSSO環境に関係なく一貫した方法で作用できます。

注意:

- デフォルトで有効: SSO同期フィルタは、構成されたトークンからユーザー情報をフェッチし、既存セッション(存在する場合)からユーザーを取得し、CurrentSessionUserが着信SSOユーザーと一致していない場合はセッションを無効にしてリクエストされたURLにリダイレクトします。そうでない場合、リクエストは単にパススルーされます。
ドメインでOSSOまたはOracle Access Managerアサーション・プロバイダを構成していない場合、フィルタはWebLogic Serverの起動中に自動的に無効になります。

- デフォルトですべてのURIに対して有効(/*): アプリケーション・コードでの変更は不要です。

- OSSOトークン/ヘッダーに対する構成: Proxy-Remote-Userが検索され、大/小文字を区別しない一致が実行されます。

- Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_REMOTE_USERとREMOTE_USERが検索され、大/小文字を区別しない一致が実行されます。

- Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_IDENTITY_ASSERTIONが検索され、大/小文字を区別しない一致が実行されます。詳細は、「トラステッド・ヘッダー・アサーション: デジタル署名検証の構成」を参照してください。

- グローバル・ログアウト: SSO同期フィルタは、OSSOまたはOracle Access Managerソリューションを使用するOracle Fusion Middlewareアプリケーションに対してシングル・ログアウト操作を提供します。これは、シングル・サインオンと同様に処理されます。グローバル・ログアウトが実行されると、セッションのクリーンアップが実行されていないアプリケーションに対して後続アクセスが行われたときに、SSOフィルタによってセッションが調整されます。
OSSOまたはOracle Access Managerソリューションを使用するアプリケーションは、OSSOログアウトまたはOracle Access Managerログアウトのコールを実行する前にそのセッションを無効にする必要があります。OSSOログアウトの詳細は、例18-2「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。

- アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。

様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表16-6に、各プロパティと同期動作を示します。

表16-6 SSO同期フィルタの各プロパティと同期動作

領域

優先システム・プロパティ

システム・プロパティのデフォルト値

同期フィルタのデフォルト動作

ステータス(有効または無効)

sso.filter.enable

構成なし

有効

大/小文字を区別した一致

sso.filter.name.exact.match

構成なし

大/小文字を区別しない一致

構成されたトークン

sso.filter.ssotoken

構成なし

- OSSO: Proxy-Remote-Userを検索する

- Oracle Access Manager: OAM_REMOTE_USERおよびREMOTE_USERを検索する
OAM_REMOTE_USERが優先される

URIマッピング

なし

なし

/*

一部のアプリケーションに対してフィルタを有効にすることはできません。SSO同期フィルタは、システム・フィルタです。このため、デプロイされているすべてのアプリケーションに対して有効になります(URIマッピングは/*)。

注意:

一部のアプリケーションに対してフィルタを有効にすることはできません。

次の手順に、SSO同期フィルタのプロパティと動作の変更に関するヒントを示します。

SSO同期フィルタのプロパティと動作を変更するには

1. フィルタの無効化: システム・プロパティsso.filter.enableをfalseに変更し(jvmに-Dとして渡す)、Oracle WebLogic Serverを再起動します。これにより、フィルタ・ステータスが切り替わります。

2. ユーザー識別ヘッダーと事前構成済同期フィルタ・トークンの不一致: システム・プロパティsso.filter.ssotokenを使用して、同期フィルタによって検索されるSSOトークンを上書きします。
たとえば、WebLogic Serverの起動スクリプト(-Dsso.filter.ssotoken=HEADERNAME)でWebLogic Server JVMに渡し、サーバーを再起動します。

Oracleサポート・サービスにお問合せの際は、「WebLogic管理コンソールでのデバッグの設定」の説明に従ってデバッグを設定するように求められる場合があります。

16.5 トラブルシューティングのヒント

詳細は、Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイドのトラブルシューティングに関する項を参照してください。

関連項目:

「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」

17 Oracle Access Manager 10gを使用したシングル・サインオンの構成

ここでは、Oracle Access Manager 10gを使用したシングル・サインオンの構成について説明します。内容は次のとおりです。

- Oracle Access Manager 10gを使用したSSOソリューションのデプロイ

- Oracle Access Manager認証プロバイダのパラメータ・リスト

- OAMCfgToolの概要

- Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成

- Oracle Access Manager 10g用の認証プロバイダの構成

- Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成

- ユーザーとSSOセッションの同期: SSO同期フィルタ

- OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント

17.1 Oracle Access Manager 10gを使用したSSOソリューションのデプロイ

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

- OAM 10g用の認証プロバイダのインストールおよび設定

- Oracle Access Manager認証プロバイダのパラメータ・リスト

- Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

17.1.1 OAM 10g用の認証プロバイダのインストールおよび設定

この項では、Oracle Access Managerのインストールおよび初期設定の概要と、Oracle Access Manager認証プロバイダのデプロイ時に使用するコンポーネントとファイルのインストール方法の追加情報を示します。

特に明記されていないかぎり、次の各項では、Oracle Access Manager IDアサーション・プロバイダとOracle Access Manager認証プロバイダの要件を両方とも説明します。

- Oracle Access Manager 10gのインストールと設定について

- 認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール

- Oracle Access Manager証明書のJavaキーストア形式への変換

- Oracle Access Manager 10gでのリソース・タイプの作成

17.1.1.1 Oracle Access Manager 10gのインストールと設定について

この項では、Oracle Access Managerを初めて使用するユーザーのために、インストールと設定の概要を簡潔に説明します。

関連項目:

「Oracle Access Managerで使用されるプロバイダの要件」

アクセス・サーバー: Oracle Access Manager認証プロバイダでは、Webゲートまたはアクセス・ゲート用のアクセス・サーバーが2つ必要になります(1つのプライマリ・サーバーと1つのセカンダリ・サーバー)。現時点では、セカンダリ・アクセス・サーバーは1つしかサポートされません。アクセス・サーバーのインストールには、次の手順が含まれます。

- アクセス・システム・コンソールで、プライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」(ポリシー・マネージャAPIのサポート・モードとも呼ばれます)になっていることを確認します。

- 「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。

- プライマリ・アクセス・サーバーのインスタンスをインストールします。

- セカンダリ・アクセス・サーバーのインスタンスをインストールします。

Webゲート/アクセス・ゲート: Webゲートまたはアクセス・ゲートのどちらが必要であるかは、使用するOracle Access Manager認証プロバイダによって決まります。次に例を示します。

- シングル・サインオン用のIDアサーション・プロバイダ: 境界認証を定義するために、アプリケーションごとに個別のWebゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。

- 認証プロバイダまたはOracle Web Services Manager: アプリケーションごとに個別のアクセス・ゲートと構成プロファイルが必要です。「アクセス管理サービス」が「オン」になっていることを確認します。

OAM 10g Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメインについて

この項では、Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメイン、およびこれらの作成方法について説明します。

Webゲートとアクセス・ゲートには微妙な違いがありますが、多くの場合、これらの用語は同じ意味で使用されます。アクセス・システム・コンソールでは、Webゲートまたはアクセス・ゲートの構成プロファイルがアクセス・ゲート・プロファイルと呼ばれています。ポリシー・マネージャでは、Oracle Access Managerのポリシー・ドメインが作成されます。

アクセス・システム・コンソールを使用する方法: 特定のOracle Access Manager管理者権限を持つユーザーが、Oracle Access Managerで直接情報を入力して、パラメータを設定できます。この方法は、認証プロバイダを使用している場合、またはOracle Web Services ManagerポリシーでWebサービスを保護している場合に必要です。

OAMCfgToolを使用する方法: シングル・サインオン用のIDアサーション・プロバイダを実装するアプリケーション管理者は、OAMCfgToolを使用して新しいWeb層用の新しいWebゲート・プロファイルを作成できます。必須パラメータは、コマンドラインで指定する、環境に適した値を使用してプロビジョニングされます。必須ではないパラメータについては、デフォルト値が受け入れられます。アクセス管理サービスはオンに設定されます。プロファイルを作成したら、アクセス・システム・コンソールで値を変更できます。

各アクセス・ゲート・プロファイルには、次のパラメータが含まれている必要があります。アスタリスク(*)付きのパラメータは、OAMCfgToolを使用してプロビジョニングされます。

- *アクセス・ゲート名: 空白を含まない一意の名前。OAMCfgToolツールでは、この名前はapp_domain値から導出され、末尾に_AGが付けられます。

- *ホスト名: Webゲートまたはアクセス・ゲートがインストールされている(またはインストールされる)コンピュータの名前。OAMCfgToolでは、ホスト名としてapp_domain値が使用されます。

- *アクセス・ゲートのパスワード: コンポーネントを検証および識別するための一意のパスワード。これにより、認可されていないアクセス・ゲートがアクセス・サーバーに接続してポリシー情報を取得する事態を防ぐことができます。OAMCfgToolでは、app_agent_passwordパラメータを使用して指定されます。このパスワードは、Webゲート/アクセス・ゲート・インスタンスごとに異なっている必要があります。

- トランスポート・セキュリティ: アクセス・サーバーと関連するWebゲート間のトランスポート・セキュリティ・レベル(これらは一致する必要があります)。デフォルト値はOpenです。OAMCfgToolのoam_aaa_mode値を使用して、別の値を指定できます。

- *優先HTTPホスト: ユーザーが保護されたWebサーバーへのアクセスを試みたときに、すべてのHTTPリクエストに表示されるホスト名。ユーザーのHTTPリクエストでどのように定義されたかに関係なく、HTTPリクエストのホスト名は、このフィールドに入力した値に変換されます。OAMCfgToolの優先HTTPホストはapp_domain値です。
優先ホスト機能により、ホストの識別子がホスト識別子リストに含まれていない場合に、セキュリティ・ホールが誤って作成される事態を防ぐことができます。ただし、この機能は仮想Webホスティングには使用できません。仮想ホスティングでは、ホスト識別子機能を使用する必要があります。

- *プライマリHTTP Cookieドメイン: WebゲートがデプロイされているWebサーバー・ドメイン。Cookieドメインは、Webサーバー間のシングル・サインオンを有効にするために必要です。各Webサーバーの「プライマリHTTP Cookieドメイン」の値は一致している必要があります。この値を設定するには、OAMCfgToolのcookie_domainパラメータを使用します。

関連項目:

- 「アクセス・ゲート・プロファイルとポリシー・ドメインの管理要件について」

- 「OAMCfgToolの概要」

- 『Oracle Access Managerアクセス管理ガイド』のWebゲートおよびアクセス・サーバーの構成に関する項

アクセス・ゲート・プロファイルとポリシー・ドメインの管理要件について

この項では、Oracle Access Managerの新しいWebゲート/アクセス・ゲート・プロファイル、ポリシー・ドメインの作成方法、およびその際に必要な管理権限について説明します。

Oracle Access Managerのマスター・アクセス管理者は、ポリシー・ドメイン・ルートを定義した後、最初のポリシー・ドメインを作成する必要があります。その後、最初のポリシー・ドメインの下にURLのポリシー・ドメインを作成し、それらのポリシー・ドメインの管理を他の管理者に委任できます。

アクセス・システム・コンソールを使用する方法: アクセス・システム・コンソールを使用して新しいアクセス・ゲート・プロファイルを作成し、それをアクセス・サーバーに関連付けて、認証スキームを作成するには、マスター・アクセス管理者または委任アクセス管理者である必要があります。マスター・アクセス管理者または委任アクセス管理者は、ポリシー・マネージャを使用してポリシー・ドメインを作成することもできます。この方法は、次のデプロイメントで必要です。

- 認証プロバイダ

- Oracle Web Services ManagerによってWebサービスが保護されている場合にはIDアサーション・プロバイダ

OAMCfgToolを使用する方法: OAMCfgToolを使用するために、特定のOracle Access Manager管理者権限は必要ありません。OAMCfgToolにより、Webゲート・プロファイルの作成と関連付け、および新しいポリシー・ドメインの作成が自動化されます。ただし、この方法はIDアサーションでのみ使用できます。次のことが可能です。

- 新規Web層: OAMCfgToolを使用して、IDアサーション・プロバイダ専用の新しいWebゲート・プロファイルとポリシー・ドメインの作成を合理化できます。
OAMCfgToolを使用してプロファイルとポリシー・ドメインを作成した後、アクセス・システム・コンソールでこれらを変更できます。

関連項目:

「OAMCfgToolの概要」

- 既存Web層: Web層に1つ以上のWebゲートが存在する場合、新しいWebゲートは必要ありません。ただし、既存のホスト識別子を指定して、既存のWebゲートが新たに確立されたポリシーを実施できるようにすることができます。

関連項目:

- 「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」

- 『Oracle Access Managerアクセス管理ガイド』のWebゲートおよびアクセス・サーバーの構成に関する項

17.1.1.2 認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール

次のタスク概要は、インストールする必要のあるコンポーネントとファイル、および詳細情報の参照先を示しています。

注意:

コンポーネントがすでにインストールおよび設定されている場合は、新たにコンポーネントをインストールする必要はありません。ご使用のデプロイメントに該当しない手順は省略してください。

特に明記されていないかぎり、シングル・サインオン用のIDアサーション・プロバイダまたは認証プロバイダのどちらがデプロイされているか、またはOracle Web Services ManagerポリシーによってWebサービスが保護されているかどうかに関係なく、すべての詳細が適用されます。

タスクの概要: Oracle Access Manager認証プロバイダの必須コンポーネントおよびファイルのインストール

1. Oracle Access Managerアクセス・サーバーで使用するようにOracle Internet DirectoryまたはOracle Sun One LDAPディレクトリ・サーバーを構成します。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。

関連項目:

次のリリース11g (11.1.1.1.0)のマニュアル

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

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

2. Oracle WebLogic Server 10.3.1以降をインストールおよび設定します。

関連項目:

このリストの手順3および『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』

3. オプション: Fusion Middleware製品(Oracle Identity Manager、Oracle SOA Suite、Oracle WebCenterなど)をインストールします。

注意:

Fusion Middlewareアプリケーションがインストールされていない場合は、以降の手順に従って、必要なJARファイルおよびWARファイルを入手する必要があります。

1. 次のFusion Middlewareパスで、必要なJARファイルの場所を確認します。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamAuthnProvider.jar
ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamcfgtool.jar

2. 次のパスで、コンソール拡張WARファイルを見つけます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprov
ider.war

3. WARファイルを、WebLogic Serverホームの次のパスにコピーします。

WL_HOME/server/lib/console-ext/autodeploy/oamauthenticationprovider.war

4. 必要に応じて、Oracle Access Manager 10g(10.1.4.3)のWebゲート用にOHS 11gをインストールします。

- 認証プロバイダまたはOracle Web Services Manager: カスタム・アクセス・ゲートでは、Webサーバーは必要ありません。保護されているリソースには、Oracle WebLogic Serverでそのリソース用のURLを使用してアクセスします。

- Oracle Access Manager IDアサーション・プロバイダ: Oracle HTTP Server 11gのWebサーバーが、Oracle WebLogic Serverのフロントエンドにリバース・プロキシとして構成されている必要があります。

5. Oracle Access Manager 10g(10.1.4.3)のコンポーネントをインストールし、次の手順に従って初期設定を行います。

関連項目:

「Oracle Access Manager 10gのインストールと設定について」

1. アイデンティティ・サーバー、Webパスをインストールして、アイデンティティ・システムを設定します。

2. ポリシー・マネージャをインストールおよび設定します。ポリシー・マネージャを保護するポリシー(/access)とデフォルト認証スキームが作成および有効化されていることを確認してください。

3. アクセス・サーバー(Webゲートのプライマリ・サーバーとセカンダリ・サーバーとして1つずつ)をインストールします。

- アクセス・システム・コンソールで、Webゲートのプライマリ・サーバーのアクセス・サーバー構成プロファイルを追加します。「アクセス管理サービス」が「オン」(ポリシー・マネージャAPIのサポート・モードとも呼ばれます)になっていることを確認します。

- 「アクセス管理サービス」を「オン」にして、セカンダリ・アクセス・サーバー構成プロファイルを追加します。

- プライマリ・アクセス・サーバーのインスタンスをインストールしてから、セカンダリ・アクセス・サーバーのインスタンスをインストールします。

注意:

1つのセカンダリ・アクセス・サーバーのみがサポートされています。

4. シングル・サインオン用のIDアサーション・プロバイダのWebゲート: 1つ以上のWebゲートが存在する既存Web層では、新しいWebゲートまたはプロファイルは必要ありません。

関連項目:

「OAMCfgToolの概要」

新規Web層では、次の手順に従って、境界認証のWebゲートを定義するためのプロファイルを作成する必要があります。

- 境界認証用のWebゲートを定義するアクセス・ゲート構成プロファイルを作成します。「アクセス管理サービス」が「オン」になっていることを確認します。OAMCfgToolまたはアクセス・システム・コンソールを使用できます。

- Webゲート・プロファイルをプライマリおよびセカンダリ・アクセス・サーバーに関連付けます。

- 各アプリケーションについて、リバース・プロキシとして構成されているOracle HTTP Server 11gのWebゲートをインストールします。

- それぞれのアプリケーションを保護するプロファイルとWebゲートがインストールされるまで、手順を繰り返します。

5. アクセス・ゲート: 認証プロバイダまたはOracle Web Services Managerを使用する場合は、アクセス・システム・コンソールでカスタム・アクセス・ゲート用の新しいプロファイルを追加する必要があります。

関連項目:

「OAM 10g Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメインについて」

- アクセス・システム・コンソールでアクセス・ゲート構成プロファイルを追加し、「アクセス管理サービス」が「オン」になっていることを確認します。

- アクセス・ゲート・プロファイルをプライマリおよびセカンダリ・アクセス・サーバーに関連付けます。

- oamAuthnProvider.jarに含まれているカスタム・アクセス・ゲートをデプロイします。

- それぞれのアプリケーションを保護するプロファイルとアクセス・ゲートがインストールされるまで、手順を繰り返します。

6. 次のようにします。

- 簡易モードまたは証明書モード: 「Oracle Access Manager証明書のJavaキーストア型式への変換」

- 認証プロバイダまたはOracle Web Services Manager: Oracle Access Manager認証プロバイダを使用する場合、またはOracle Web Services ManagerポリシーによってWebサービスが保護されている場合は、「Oracle Access Manager 10gでのリソース・タイプの作成」を実行します。

- シングル・サインオン用のIDアサーション・プロバイダ: 「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」で説明されているタスクを実行します。

17.1.1.3 Oracle Access Manager証明書のJavaキーストア形式への変換

すべてのJavaコンポーネントおよびアプリケーションでキーストア形式としてJKSを使用することをお薦めします。この項では、Oracle Access Manager X.509証明書をJavaキーストア(JKS)形式に変換する手順について説明します。この手順に適切に従うことで、Java NAPクライアントがOracle Access Managerアクセス・サーバーと簡易モードまたは証明書モードで通信するときに使用できるJKSストアが生成されます。

簡易モードまたは証明書モードで通信する際、アクセス・サーバーは、次のキー・ファイル、サーバー証明書ファイルおよびCAチェーン・ファイルを使用します。

- aaa_key.pem: ルートCAにリクエストを送信するときに証明書生成ユーティリティによって生成されるランダム・キー情報。これは秘密鍵です。WebGateの証明書リクエストでは、証明書リクエスト・ファイルaaa_req.pemが生成されます。このWebGate証明書リクエストを、アクセス・サーバーによって信頼されるルートCAに送信する必要があります。ルートCAは、WebGate証明書を返します。この証明書は、WebGateのインストール中またはインストール後にインストールできます。

- aaa_cert.pem: ルートCAによって署名される、アクセス・サーバーに対する実際の証明書。

- aaa_chain.pem: ルートCAのパブリック証明書。これは、簡易モードまたは証明書モードで通信するピア同士が、SSLハンドシェイクを実行して、妥当性確認のための証明書を交換するときに使用されます。簡易モードでは、aaa_chain.pemは、AccessServer_install_dir/access/oblix/tools/openssl/simpleCA/cacert.pemにあるOpenSSL証明書です。

ここで、aaaは、ファイルについて指定する名前です(証明書ファイルおよびチェーン・ファイルにのみ適用されます)。

テキスト編集ユーティリティを使用して既存の証明書を編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除できます。次に、編集された証明書をJKS形式に変換し、キーストアにインポートします。Javaキー・ツールでは、すでに保持している証明書に対する既存の秘密鍵をインポートできません。OpenSSLユーティリティを使用して、PEM形式ファイルをDER形式ファイルに変換する必要があります。

Oracle Access Manager証明書をJKS形式に変換してインポートする手順は次のとおりです。

1. Java 1.6または最新のバージョンをインストールして構成します。

2. 編集する前に次のファイルをコピーして、元のファイルを保持します。

- aaa_chain.pem

- aaa_cert.pem

- cacert.pem(簡易モードで構成する場合のみ)

3. TextPadを使用してaaa_chain.pemを編集し、CERTIFICATEブロック内に含まれるデータを除くすべてのデータを削除し、そのファイルを新しい場所に保管して元のファイルを保持します。

-----BEGIN CERTIFICATE-----
...
CERTIFICATE
...
-----END CERTIFICATE-----

4. 編集されたaaa_chain.pemに対して次のコマンドを実行します。

JDK_HOME\bin\keytool" -import -alias root_ca -file aaa_chain.pem -keystore
rootcerts

ここでは、別名(短縮名)root_caをキーに割り当てています。入力ファイルaaa_chain.pemは、手順3で手動で編集したファイルです。キーストア名は、rootcertsです。

新規作成したキーストアに格納されているキーにアクセスするためのパスワードを指定する必要があります。

注意:

セキュリティを確保するために、キーツールでパスワードの入力を求めるプロンプトが表示されるようにすることをお薦めします。コマンド・ラインから「-storepass」フラグを省くと、このプロンプトが自動的に表示されます。

5. 入力を求められたら、キーストアのパスワードを入力します。例:

Enter keystore password: <keystore_password>
Re-enter new keystore password: <keystore_password>

6. このツールを信用するかどうかを質問されたら、「Yes」と入力します。

Trust this certificate? [no]: yes

7. 次のコマンドを実行してパスワードを入力し、証明書がJKS形式にインポートされていることを確認します。

JDK_HOME\bin\keytool" -list -v -keystore "rootcerts"
Enter keystore password: <keystore_password>

8. 次のようなレスポンスを探します。

Keystore type: JKS
Keystore provider: SUN
Your keystore contains n entries
Alias name: root_ca
Creation date: April 19, 2009
Entry type: trustedCertEntry

Owner: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint,
O="Oblix, Inc.", L=Cupertino, ST= California , C=US

Issuer: CN=NetPoint Simple Security CA - Not for General Use, OU=NetPoint,
O="Oblix, Inc.", L=Cupertino, ST= California ,C=US

Serial number: x
Valid from: Tue Jul 25 23:33:57 GMT+05:30 2000 until: Sun Jul 25 23:33:57
GMT+05:30 2010

Certificate fingerprints
MD5:  CE:45:3A:66:53:0F:FD:D6:93:AD:A7:01:F3:C6:3E:BC
SHA1: D6:86:9E:83:CF:E7:24:C6:6C:E1:1A:20:28:63:FE:FE:43:7F:68:95
Signature algorithm name: MD5withRSA
Version: 1
*******************************************

9. 他のPEMファイルについて、手順3 - 7を繰り返します(チェーンがない場合のaaa_chain.pemを除く)。

10. アクセス・サーバーのインストール・ディレクトリ・パスでOpenSSLユーティリティを使用して、aaa_key.pemファイルをDER形式に変換します。例:

AccessServer_install_dir\access\oblix\tools\openssl>openssl pkcs8 -topk8
-nocrypt -in aaa_key.pem -inform PEM -out aaa_key.der –outform DER

ここで、入力ファイルはaaa_key.pem、出力ファイルはaaa_key.derです。追加のオプションは次のとおりです。

表17-1 PEMからDER形式ファイルを作成するためのオプション

オプション

説明

-topk8

従来の形式の秘密鍵を読み込んで、PKCS#8形式の鍵を書き出します。これにより、デフォルトと逆の状態になります。デフォルトでは、入力でPKCS#8の秘密鍵が要求され、従来の形式の秘密鍵が書き出されます。

-nocrypt

出力で暗号化されていないPrivateKeyInfo構造が要求されます。

-inform

入力形式を指定します。入力でPKCS#8形式の鍵が要求される場合、DERまたはPEMでエンコードされたバージョンのPKCS#8鍵が要求されます。それ以外の場合、DERまたはPEM形式の従来形式の秘密鍵が使用されます。

-outform

出力形式を指定します。出力でPKCS#8形式の鍵が要求される場合、DERまたはPEMでエンコードされたバージョンのPKCS#8鍵が要求されます。それ以外の場合、DERまたはPEM形式の従来形式の秘密鍵が使用されます。

11. 簡易モードまたは証明書モード: 簡易モードまたは証明書で構成されている場合、PEMファイル(この場合、aaa_cert.pem)で、Oracle Access Managerアクセス・サーバーに対するパスフレーズを入力します。

Passphrase for the certificate

12. 次のコマンドを実行して、aaa_cert.pemファイルをDER形式に変換します。

AccessServer_install_dir\access\oblix\tools\openssl>openssl x509 -in
aaa_cert.pem -inform PEM -out aaa_cert.der -outform DER

13. ImportKeyユーティリティを使用して、DER形式ファイルをJavaキーストアにインポートします。例:

Java_install_dir\doc>java -Dkeystore=jkscerts ImportKey aaa_key.der
aaa_cert.der

14. ウィンドウで結果を確認します。次の例のように表示されます。

Using keystore-file : jkscerts
One certificate, no chain
Key and certificate stored
Alias:importkey  Password:your_password

15. 次のようにします。

- シングル・サインオン用のIDアサーション・プロバイダ: 「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」に移動してください。

- 認証プロバイダまたはOracle Web Services Manager: 「Oracle Access Manager 10gでのリソース・タイプの作成」の手順を実行してください。

17.1.1.4 Oracle Access Manager 10gでのリソース・タイプの作成

この項では、ポリシー・ドメインで保護するリソース・タイプを識別するリソース・タイプをOracle Access Managerで作成する方法について説明します。このタスクはOracle Access Managerを使用する場合、およびOracle Web Services ManagerのポリシーでWebサービスを保護している場合に必要とされます。

ここで説明するリソース・タイプを定義するには、Oracle Access Managerアクセス・システム・コンソールを使用します。

注意:

シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを使用している場合、このタスクは省略できます。その場合、デフォルトのhttpリソース・タイプのみが使用されます。

Oracle Access Managerでwl_authenリソース・タイプを定義する必要があるのは、次のコンポーネントを使用している場合のみです。

- Oracle Access Manager認証プロバイダ

- Oracle Web Services Manager用のIDアサーション・プロバイダ

Oracle Access Manager 10gでリソース・タイプを定義するには

1. アクセス・システム・コンソールに移動して、ログインします。

2. 「アクセス・システム構成」タブを選択して、「共通情報の構成」、「リソース・タイプ定義」をクリックし、「すべてのリソース・タイプをリスト」ページを表示します。

3. 「すべてのリソース・タイプをリスト」ページで、「追加」をクリックし、「新規リソース・タイプの定義」ページを表示します。

4. 次の詳細を指定して、リソース・タイプを定義します。

- 名前: wl_authen

- 表示名: wl_authen

- リソースの一致: 大/小文字を区別しない

- リソース操作: LOGIN

5. 定義したリソース・タイプを保存します。

6. 次のようにします。

- 認証プロバイダ: 「Oracle Access Manager 10g用の認証プロバイダの構成」

- Oracle Web Services Manager: 「Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成」

17.1.2 Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

この項では、Oracle Access Manager 10gでの10g Webゲートで保護されたアプリケーションのログアウトの構成について説明します。Oracle Access Manager 10gでは、様々な方法でグローバル・ログアウト(シングル・ログアウト(SLO)ともいいます)を処理できます。この項では、推奨方法について説明します。

注意:

Oracle Access Manager SSOユーザー・セッションの追跡は、ドメインのCookie、つまりObSSOCookieを使用して実行されます。Webゲートは、ObSSOCookieを検索します。Oracle Access Managerのグローバル・ログアウトまたはSLOは、単にObSSOCookieをクリアすることを意味します。ObSSOCookieがない場合、Webゲートは再認証ワークフローを実施します。

ObSSOCookieをクリアする方法の詳細は、次の各項を参照してください。

- 「ログアウトを構成するための推奨プロセス」

- 「ログアウトを構成するための代替プロセス」

17.1.2.1 ログアウトを構成するための推奨プロセス

ログアウトを構成するための推奨方法には、次の2つの手順があります。

- サンプル・ログアウト・ファイルを使用したログアウト用Webゲートの構成

- ログアウト用アプリケーションの構成

17.1.2.1.1 サンプル・ログアウト・ファイルを使用したログアウト用Webゲートの構成

Webゲートの構成は、次のもので構成されています。

- logout.html: ログアウト・ページは、Webゲートのインストール・ディレクトリ内のWebサーバーで使用可能である必要があります(WebGate_install_dir/oamsso/logout.html)。
ファイルがWebサーバー上の別の場所に格納されている場合には、logout.htmlをロードするためのログアウト・リンクが正しく指定されていることを確認します。例17-1のlogout.htmlを参照してください。この例を参照すると、ニーズに応じてさらにカスタマイズすることができます。

- logOutUrls(オプション): このパラメータがすでにWebゲートに対して構成されている場合には、値「/oamsso/logout.html」を既存のリストに追加する必要があります。

- Webサーバーの構成: 10g Webゲートが構成されている、Oracle HTTP Server Webサーバーの構成ファイルhttpd.confを確認し、次の行が存在する場合には、それを削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

OAM 10gデプロイメントで10g Webゲートによって保護されているアプリケーションのログアウト構成に使用されるlogout.htmlを作成する際は、例17-1を使用します。

例17-1 logout.htmlのスクリプト

<html>
<head>
<script language="javascript" type="text/javascript">

function handleLogout() {

//get protocol used at the server (http/https)
var webServerProtocol = window.location.protocol;
//get server host:port
var webServerHostPort = window.location.host;
//get query string present in this URL
var origQueryString = window.location.search.substring(1);

//vars to parse the querystring
var params = new Array();
var par = new Array();
var val;

if (origQueryString != null && origQueryString != "") {

params = origQueryString.split("&");

//search for end_url and redirect the user to this
for (var i=0; i<params.length; i++) {

par = params[i].split("=");

if ("end_url" == par[0]) {

endUrlVal = par[1];

//check if val (value of end_url) begins with "/" or "%2F" (is it an URI?)
if (endUrlVal.substring(0,1) == "/" || endUrlVal.substring(0,1) == "%") {

if (endUrlVal.substring(0,1) == "%")
endUrlVal = "/" + endUrlVal.substring(3);

//modify the end_url value now
endUrlVal = webServerProtocol + "//" + webServerHostPort + endUrlVal;
}
//redirect the user to this URL
window.location.href = endUrlVal;
}
}
}
}
</script>
</head>

<body onLoad="handleLogout();">

<h3>You have been logged out<h3>

</body>
</html>

17.1.2.1.2 ログアウト用アプリケーションの構成

ログアウト用のアプリケーション構成は、ADFアプリケーションがOPSSと統合されているか統合されていないに応じて異なります。

注意:

ログアウトの構成は、アプリケーションが1つのDNSドメイン内に存在することが前提となっています。別のDNSドメインにデプロイしたアプリケーション全体にわたってシングル・ログアウト(SLO)する場合には、各Webゲートを処理できるようにログアウト・スクリプトをカスタマイズする必要があります。複数のDNSドメインのデプロイを指定している場合には、Oracle Access Manager Access管理ガイドを参照してください。

アプリケーションのログアウトを構成する際には、次のいずれかを実行する必要があります。

- 非ADFアプリケーションは、ログアウト・リンク(/oamsso/logout.html?end_url=<target uri>)を呼び出すようにコード化されている必要があります。

- OPSSと統合されているADFアプリケーションでは、OAM SSOプロバイダのOPSSが構成されている必要があり、アプリケーションではend_urlパラメータを送信する必要があります。

非ADFアプリケーション

非ADFアプリケーションは、ログアウト・リンク(/oamsso/logout.html?end_url=<target uri>)を呼び出すようにコード化されている必要があります。

このアプリケーションは、ログアウトしたユーザーの最終的なリダイレクト先を示すパラメータ(end_url)を渡すことができます。end_urlの一部であるパラメータの値は、URLまたはURIのいずれかです。たとえば、アプリケーションのログアウト・リンクは次のように指定できます。

/oamsso/logout.html?end_url=<someUri>

または

/oamsso/logout.html?end_url=<someUrl>

end_urlの問合せ文字列がURIの場合、logout.htmlがホスティングされるサーバーのhost:portを決定することにより、logout.htmlはURLを構成する必要があります。

ADFコード化アプリケーション

アプリケーションがOPSSと統合されたADFアプリケーションの場合、次の手順に従ってログアウトを構成できます。

ADFコード化アプリケーションの集中管理ログアウトを構成するには

1. OAM管理者にエージェントで構成されたlogout.htmlスクリプトの場所を確認します。それには、次の手順を実行する必要があります。

2. OAMのOPSSをSSOプロバイダとして構成し、次のようにWebLogic管理ドメインのjps-config.xmlを更新します。

1. 次のディレクトリ・パスからwlst.sh (Linux)またはwlst.cmd (Windows)を実行します。

WLST_install_dir/middleware/oracle_common/common/bin

2. WLSのプロンプトで、OAM管理者IDとパスワード、およびWebゲートのホストとポートを入力します

wls:/> /connect("admin_ID", "admin_pw", "hostname:port"

デフォルト・ポート(7001)でローカルホスト上でサーバーが実行している場合、最後のパラメータはオプションです。

3. ADF認証用のログインURIとログアウトURIを入力します(エージェントによって構成されたlogout.htmlスクリプトの場所)。ホストとポートは必要ありません。

wls:/>addOAMSSOProvider(loginuri="/$<loginuri>",
logouturi="<logouturival>," autologinuri=None")

ここで、logouturivalはログアウト・スクリプト/oamsso/logout.htmlのURIです。logouturlは「logout」で始めるか(logout.gifとlogout.jpgは例外)、OAM管理者によって構成された他の値にできます。

3. 必須: ADFアプリケーションは、ログアウトしたユーザーのリダイレクト先を示すend_urlパラメータを渡す必要があります。ADFアプリケーションの場合、アプリケーションによって次のURIが呼び出されたときにログアウトが開始されます。

/<app context root>/adfAuthentication?logout=true&end_url=<any uri>

17.1.2.2 ログアウトを構成するための代替プロセス

アプリケーションにすでにカスタムのログアウトページがあり、いかなる理由でも変更しない場合を除いて、この方法を使用しないようお薦めします。

Webゲートは、文字列「logout.」が含まれているURLへのリクエストをすべてログアウトします。例外: logout.gifやlogout.jpgなどのイメージ・ファイルは例外です。これは、アプリケーションをOAM SLOと統合する最も簡単な方法です。ログアウト・ページが「logout.」で始まっている場合(例: logout.jsp)は、何もする必要はありません。

注意:

ログアウト・ページが「logout.」で始まっている場合(例: logout.jsp)は、何もする必要はありません。

ログアウト・ページが「logout.」で始まっていない場合、ログアウトURLをWebGate LogOutUrlsパラメータに追加する必要があります。例: LogOutUrls = "/myapplication /customscript.jsp"。

17.2 Oracle Access Manager認証プロバイダのパラメータ・リスト

この項では、Oracle Access Manager認証プロバイダに関係する共通およびプロバイダ固有のパラメータを列挙します。これらのパラメータは、Oracle WebLogic管理コンソールで指定します。詳細は、次を参照してください:

- 表17-2「Oracle Access Manager認証プロバイダの共通パラメータ」

- 表17-3「プロバイダ固有のパラメータ」

- 表17-4「Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータ」

表17-2 Oracle Access Manager認証プロバイダの共通パラメータ

パラメータ名

パラメータの説明

名前

プロバイダの名前。読取り専用。

説明

プロバイダの説明。読取り専用。

バージョン

プロバイダのバージョン。読取り専用。

制御フラグ

プロバイダJAAS制御フラグ。REQUIRED、REQUISITE、OPTIONALまたはSUFFICIENTの1つを設定します。複数の認証プロバイダを構成する場合、このフラグを使用してログイン・シーケンスでのそれらの使用方法を制御します。「JAAS制御フラグ」を参照してください。

アクティブ・タイプ

このパラメータは、Oracle Access Manager IDアサーション・プロバイダにのみ関連しています。このパラメータは、IDアサーション・プロバイダによって処理されるトークン・タイプを決定します。OAM 10gおよび10g Webゲートでは次のように設定します。

- OAM 10gおよび10g Webゲート: ObSSOCookie

- OAM_REMOTE_USER

Base64でのデコーディングが必要

Falseは読取り専用(デフォルト)。

新しいセキュリティ・プロバイダを作成すると、WebLogic Server管理コンソールによって、JAAS制御フラグがOPTIONALに設定されます。すぐに使用できるセキュリティ・プロバイダのデフォルト値はREQUIREDです。制御フラグの詳細は、オンライン・ヘルプを参照してください。

表17-3は、Oracle Access Manager認証プロバイダまたはOracle Web Services ManagerのIDアサーション・プロバイダのプロバイダ固有のパラメータを示しています。

注意:

OAM 11gでは、アクセス・サーバーはOAMサーバーと呼ばれています。

表17-3 プロバイダ固有のパラメータ

パラメータ名

パラメータの説明

トランスポート・セキュリティ

アクセス・ゲートとアクセス・サーバーの間の通信モード。

プール内の最小アクセス・サーバー接続数

許可される最小接続数。デフォルト値は5です。

アクセス・ゲートのパスワード

プロバイダによって使用されるアクセス・ゲートのパスワード。

キー・ストアのパスフレーズ

キー・ストアにアクセスするためのパスワード。

アクセス・ゲート名

プロバイダによって使用されるアクセス・ゲートの名前。必須。

プライマリ・アクセス・サーバー

プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須。「OAM 10g用の認証プロバイダのインストールおよび設定」を参照してください。

プール内の最大アクセス・サーバー接続数

許可される最大接続数。デフォルトは10です。1に設定します。

簡易モードのパスフレーズ

簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。

トラスト・ストア

プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。

SSOヘッダー名

OAM_REMOTE_USER

セカンダリ・アクセス・サーバー

セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。「OAM 10g用の認証プロバイダのインストールおよび設定」を参照してください。

キー・ストア

プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。

表17-4は、Oracle Access Manager認証プロバイダのプロバイダ固有パラメータを示しています。

表17-4 Oracle Access Manager認証プロバイダのプロバイダ固有のパラメータ

パラメータ名

パラメータの説明

トランスポート・セキュリティ

アクセス・ゲートとアクセス・サーバーの間の通信モード。

プール内の最大アクセス・サーバー接続数

許可される最大接続数。デフォルトは10です。1に設定します。

簡易モードのパスフレーズ

簡易通信モードまたは証明書通信モードに対してアクセス・ゲートとアクセス・サーバーによって共有されるパスワード。

プール内の最小アクセス・サーバー接続数

許可される最小接続数。デフォルト値は5です。

トラスト・ストア

プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSトラスト・ストアの絶対パス。

取得したユーザー名をプリンシパルとして使用する

Oracle Access Managerから取得したユーザー名をサブジェクトのプリンシパルとして使用するかどうかを指定します。

アクセス・ゲートのパスワード

プロバイダによって使用されるアクセス・ゲートのパスワード。

キー・ストアのパスフレーズ

キー・ストアにアクセスするためのパスワード。

アクセス・ゲート名

プロバイダによって使用されるアクセス・ゲートの名前。必須。

セカンダリ・アクセス・サーバー

セカンダリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。次の各項を参照してください。

- 「OAM 10g用の認証プロバイダのインストールおよび設定」

キー・ストア

プロバイダとOracle Access Managerアクセス・サーバーとの間のSSL通信に使用されるJKSキー・ストアの絶対パス。

プライマリ・アクセス・サーバー

プライマリ・アクセス・サーバーの名前。host:portの形式に準拠している必要があります。必須。次の各項を参照してください。

- 「OAM 10g用の認証プロバイダのインストールおよび設定」

17.3 OAMCfgToolの概要

この項では、OAMCfgToolについて説明します。このツールは、シングル・サインオンに使用されるOracle Access Manager 10g IDアサーション・プロバイダをデプロイしている場合にのみ使用できます。

OAMCfgToolは、一連のスクリプトを起動して情報をリクエストし、必要なプロファイルとポリシーをOracle Access Manager 10gに設定します。OAMCfgToolは、次のモードで実行されます。

- CREATEモード

java -jar oamcfgtool.jar mode=CREATE param=value

- VALIDATEモード

java -jar oamcfgtool.jar mode=VALIDATE param=value

- DELETEモード

java -jar oamcfgtool.jar mode=DELETE param=value

LDIF出力ファイルを指定していない場合は、Oracle Access Managerを使用して構成されたDAPディレクトリ・サーバーに、構成の変更が直接書き込まれます。また、LDIFファイルがなければ、OAMアクセス・サーバーのキャッシュも構成の変更によって更新されます。

注意:

構成の変更がLDIFファイルに書き込まれる場合は、後からOracle Access Managerのディレクトリ・サーバーに構成の変更をロードすることができます。

ログ・レベルとログ詳細の出力ファイルも指定できます。OAMCfgToolの実行中にエラーが発生した場合は、コマンドラインでエラーが報告されます。

パスワード

OAMCfgTool では、LDAPユーザー、アプリケーション・エージェント、OAMモードおよびテスト・ユーザーの4つのパスワードが受け入れられます。

パラメータ-nopromptがない場合、OAMCfgToolはまずコマンドラインからパスワードをフェッチしようとします。パスワードが見つからない場合は、OAMCfgToolが一時停止し、コマンドラインにパスワードを入力するように要求します。

しかし、-nopromptパラメータが指定されている場合、OAMCfgToolはコマンドラインから渡されたパスワードをチェックします。

- コマンドラインからパスワードが渡されなかった場合、OAMCfgToolはSystem.inから渡されたパスワードをチェックします。

- System.inからパスワードが渡されない場合、OAMCfgToolは、必須のパスワードが提示されなかったことを示す例外を生成して実行を停止します。

パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。たとえば、次のように入力します。

- 4つのパスワードのすべてを指定する入力は次のとおりです。
$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd) | java -jar oamcfgtool.jar <args> -noprompt

- ldapUsrPwdとappAgentPwdのみを指定する入力は次のとおりです。
$ (echo ldapUserPwd; echo appAgentPwd) | java -jar oamcfgtool.jar <args> -noprompt

- appAgentPwdのみを指定する入力は次のとおりです。
$ (echo; echo appAgentPwd) | java -jar oamcfgtool.jar <args> -noprompt

詳細は、「OAMCfgToolのパラメータと値」を参照してください。

17.3.1 OAMCfgToolのプロセス概要

この項では、環境に適した各種パラメータと値を指定してOAMCfgToolを使用する場合の処理について説明します。

この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合には、この項を省略して、第16章「Oracle Access Manager 11gを使用したシングル・サインオンの構成」を参照してください。

関連項目:

- 「OAMCfgToolのパラメータと値」

- 「OAMCfgToolで作成したポリシー・ドメインとアクセス・ゲート・プロファイルのサンプル」

プロセスの概要: OAMCfgToolによる認証スキーム、ポリシー・ドメインおよびWebゲート・プロファイルの作成

1. app_domainパラメータは、ポリシー・マネージャのポリシー・ドメインを作成することでアプリケーション認証を可能にします。

2. web_domainパラメータは、リクエストの送信元であるWebゲート・ホストを送信先のアプリケーションに接続したり、ポリシーを既存Webゲートにリンクするホスト識別子を作成します。

注意:

web_domainパラメータについては表17-5を参照してください。

3. protected_urisパラメータは、ホスト識別子を使用して、HTTPリソースを保護するためのアプリケーション固有のURLを定義します。

4. public_urisパラメータは、匿名認証スキームを使用して特定のURIのapp_domain名のhttpリソース(GETおよびPOST操作)を保護するポリシーを作成します。

注意:

特定のファイルの保護付きURIおよび公開URIを指定する方法の詳細は、表17-5でuris_fileパラメータを参照してください。

5. LDAPパラメータではディレクトリ・サーバーが指定されます。Oracle Access Managerはこのサーバーを使用してすべてのLDAP問合せが実行される検索ベースを特定します。詳細は、表17-5を参照してください。

6. log fileおよびlog levelパラメータは、OAMCfgToolの出力ファイルとログ・レベルを指定します。

7. output_ldif_fileパラメータは、LDIFファイルの名前を定義します。ここで作成したLDIFファイルは、ユーザーの指定に応じて後でディレクトリ・サーバーにロードできます。このファイルを使用しない場合、構成変更はディレクトリ・サーバーに書き込まれます。

17.3.2 OAMCfgToolのパラメータと値

内容は次のとおりです。

- CREATEモードのパラメータと値

- VALIDATEモードのパラメータと値

- DELETEモードのパラメータと値

17.3.2.1 CREATEモードのパラメータと値

表17-5は、OAMCfgToolのCREATEモードにおける必須パラメータとオプション・パラメータ、および値を示しています。パラメータは、一度に複数個指定できます。

表17-5 OAMCfgToolのCREATEモードでのパラメータと値

パラメータ

CREATEモードの値

必須パラメータ

必須パラメータの値

app_domain

アプリケーションを保護するOracle Access Managerポリシー・ドメインの名前。ポリシー・マネージャ内では、ポリシー・ドメイン名と呼ばれています。

protected_uris

保護されるアプリケーションのURIのカンマ区切りリスト(空白あり/なし)(例: /myapp/login)。

この表のパラメータuris_fileも参照してください。

uris_file

任意の数の保護付きURIまたは公開URIが保存されたファイルへのフルパスで、パラメータprotected_urisまたはpublic_urisを使用する必要をなくします。このファイルでは次の構文および形式が使用されていることを確認します。

--少なくとも1つの保護付きURIが必要です。
--1つのファイルにつき1つの製品ファミリのみが許可されます。
--コメントは「#」で始まります。
--キーワード: public_uris。このキーワードの後に個別の行に公開URIをリストします。
--キーワード: protected_uris。このキーワードの後に個別の行に保護付きURIをリストします。
たとえば、次のようになります。

########################
#Finance
########################
.
########################
protected_uris
########################
/finance/protected/test1
/finance/protected/test2
########################
public_uris
########################
/finance/public
/finance/protected/test1/public

app_agent_password

Webゲートに対してプロビジョニングされるパスワード。10gアクセス・システム・コンソール内のアクセス・ゲート・プロファイルでは、このパラメータがアクセス・ゲート・パスワードと呼ばれています。入力したパスワードは、コマンドラインにクリアテキストで表示されますが、ログ・ファイルには記録されません。

注意: Webゲート・プロファイルを作成しない場合、このパラメータは必要ありません。この表の後続部分にある-noprompt、および「パスワード」の説明も参照してください。

ldap_host

Oracle Access ManagerのLDAPディレクトリ・サーバーをホストするコンピュータのDNS名。これはOAMポリシー・データが格納されるディレクトリ・サーバーです。

注意: ディレクトリ・サーバーとのSSL対応通信はサポートされていません。

ldap_port

LDAPディレクトリ・サーバーのポート。

ldap_userdn

引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。

ldap_userpassword

LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。この表の後続部分にある「-noprompt」を参照してください。

この表の後続部分にある-noprompt、および「パスワード」の説明も参照してください。

oam_aaa_host

アクセス可能なアクセス・サーバーをホスティングしているコンピュータのDNS名。

必要に応じてディレクトリ・サーバーを変更すると、キャッシュ・フラッシュ・リクエストがこのアクセス・サーバーに送信され、アクセス・サーバーのキャッシュが適宜リフレッシュされます。

「primary_oam_servers」パラメータが指定されていない場合、作成中のWebゲート・プロファイルではoam_aaa_hostの指定に含まれるアクセス・サーバーがプライマリ・アクセス・サーバーとして使用されるように構成されます。デフォルトの接続数は1です。

この表の後続部分にあるprimary_oam_serversおよびsecondary_oam_serversも参照してください。

oam_aaa_port

アクセス可能なアクセス・サーバーのリスニング・ポート。

オプション・パラメータ

オプション・パラメータの値

help

パラメータと説明のリストを提供します。

version

OAMCfgToolのバージョンをリストします。

web_domain

主にホスト識別子の指定に使用されます。

注意: OAMCfgToolは、次の2つのシナリオに示すように、ホスト識別子とWebゲート・プロファイルをまとめて作成するか、いずれも作成しません。

新規Web層の作成: パラメータ「web_domain」(「web_domain」の指定がない場合は「app_domain」)によって指定されたホスト識別子がOAMに存在しない場合は、OAMに次のものが作成されます。

1. 「web_domain」(「web_domain」が指定されていない場合は「app_domain」)で指定された値で作成された新規のホスト識別子。

2. 新規のWebゲート・プロファイル。この名前は次のルールを使用して取得されます。
a.「webgate_id」が指定されている場合は、「webgate_id」で指定された値を使用してWebゲートファイルが作成されます。

b.「webgate_id」が指定されていない場合は、「_AG」が付加された「web_domain」で指定された値を使用してWebゲートプロファイルが作成されます。例: <web_domain>_AG。

c.「webgate_id」と「web_domain」が指定されていない場合は、「_AG」が付加された「app_domain」で指定された値を使用してWebゲートプロファイルが作成されます。例: <app_domain>_AG。

3. Webゲート・プロファイルの優先Httpホスト・フィールドの値、および前述のステップ1で作成したホスト識別子に含まれるホスト名バリエーション・フィールドには自動的に同じ値が入力されます。

仮想ホストの構成については、この表のパラメータhostname_variationsを参照してください。

既存Web層の使用(Webドメインの結合): 「web_domain」(「web_domain」がない場合は「app_domain」)の一部として指定されたホスト識別子がOAMに存在する場合は次のようになります。

- ホスト識別子が作成されません。

- Webゲート・プロファイルが作成されません。

注意: 新規Web層で作成されたホスト識別子は、使用中のポリシー・ドメインで使用されます。

仮想Webホスティングがサポートされる場合は、「ホスト名のバリエーション」ではなく、「優先HTTPホスト」フィールドに予約名を入力します。

この表のhostname_variationsパラメータおよび『Oracle Access Managerアクセス管理ガイド』を参照してください。

cookie_domain

ObSSOCookieに使用するドメインの名前。アクセス・システム・コンソールのアクセス・ゲート・プロファイル内では、プライマリHTTP Cookieドメインと呼ばれています。

このパラメータは、新規Web層に新しいWebゲート・プロファイルを作成するときに使用します。

public_uris

匿名認証スキームを使用して非保護にする必要があるURI。公開URIは、たとえば「uri1,uri2,uri3」などのカンマ区切りリストを指定することによって識別できます。

この表のパラメータuris_fileも参照してください。

ldap_base

すべてのLDAP検索が実行されるベース。

oam_aaa_mode

アクセス可能なAccess Serverのトランスポート・セキュリティ・モード。OPEN、SIMPLEまたはCERTを指定します。デフォルト値はOPENです。

oam_aaa_passphrase

SIMPLEトランスポート・セキュリティ・モード専用のパスフレーズ。パスフレーズはクリアテキストで表示されますが、ログ・ファイルには記録されません。

「パスワード」の説明も参照してください。

log_file

OAMCfgToolログ・ファイルの名前。デフォルトでは、画面出力されます。

log_level

OAMCfgToolのロギングのレベル: ALL、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST、OFF。

デフォルト= WARNING

output_ldif_file

OAMCfgTool操作の詳細が格納されるLDIFファイルの名前。このファイルは、後でLDAPディレクトリ・サーバーにロードされます。何も指定しない場合、変更は即時にLDAPディレクトリ・サーバーに書き込まれ、Oracle Access Managerのキャッシュがフラッシュされて新しい情報が使用可能になります。

noprompt

OAMCfgToolによるパスワード・プロンプトを無効化して、次のパスワード・チェックを有効化します。

- コマンドラインからパスワードが渡されなかった場合、OAMCfgToolはSystem.inから渡されたパスワードをチェックします。詳細は「パスワード」も参照してください。

- System.inからパスワードが渡されない場合、OAMCfgToolは、必須のパスワードが提示されなかったことを示す例外を生成して実行を停止します。

authenticating_wg_url

認証Webゲートのホストおよびポートが含まれるURI(認証WebゲートとリソースWebゲートの両方がある場合)。例:

authenticating_wg_uri=http://host:port

このパラメータによって、次の両認証スキームの「チャレンジ・リダイレクト・パラメータ」が構成されます。

- OraDefaultFormAuthenNScheme

- OraDefaultI18NformAuthenNScheme

注意: 「チャレンジ・リダイレクト」パラメータは、認証スキームの作成時に追加されます。既存の認証スキームの「チャレンジ・リダイレクト」パラメータは更新されません。

configOIMPwdPolicy

Oracle Access Managerとの統合を自動化するOracle Identity Manager (OIM)パスワード・ポリシーを作成します。また、このポリシーで使用される当該の認証スキームで、パスワードをチェックするポリシーが有効化されます。

「OIM統合関連パラメータと値」も参照してください。

OimOhsHostPort

Oracle Identity Manager (OIM)をOracle Access Managerを統合し、認証WebゲートとリソースWebゲートを統合する場合に必要です。

「OIM統合関連パラメータと値」も参照してください。

認証Webゲートがない場合は必要ではありません。この場合はOracle Identity Manager (OIM)パスワード・ポリシー(OraOIMDefPasswdPolicy)によって、Oracle Access Managerとの統合が自動化され、ポリシーで使用される当該認証スキームで、パスワードをチェックするポリシーが有効化されます。デフォルト値は付加されているOimOhsHostPortに値があるパスワード・ポリシー関連パラメータで使用されます。例:

-OimLostPwdRedirectUrl  (Lost Password Redirect URL):
<OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx
-OimPwdRedirectUrl (Password Change Redirect URL):
<OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE%
-OimLockoutRedirectUrl (Account Lockout Redirect URL):
<OimOHSHostPort>/ApplicationLockoutURI

OimOhsHostPortパラメータは、-configOimPwdPolicyフラグが存在する場合にのみ使用されます。

「OIM統合関連パラメータと値」も参照してください。

logouturi

ログアウトに使用されるPerlスクリプトが構成されている認証Webゲート上のURLの場所を指定することによって、リソースWebゲート上のLogoutRedirectUrlの構成が容易になります。

logouturiパラメータの値はURIであることが要求されます。WebゲートLogoutRedirectUrlパラメータは、authenticating_wg_url and logouturiパラメータを使用して構成されます。

http://<awghost>:<awgport>/cgi-bin/logout.pl

LogoutRedirectUrl http://myhost.us.myco.com:7777/cgi-bin/logout.pl.

注意: 認証WEBゲート上では、LogoutRedirectUrlパラメータを構成しないでください。認証WebゲートのLogoutRedirectUrlは、空白にしておきます。

次のサンプルは、アプリケーション・ドメインを作成し、新規Webゲートのプロビジョニングの際にログアウトURIを構成します。

$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd)
java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri"
ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager"
oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_
base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_
url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl
-noprompt

注意: 既存のWebゲートを使用する場合は、次に説明するようにwebgate_idパラメータを使用します。

webgate_id

既存で、「LogoutRedirectUrl」が未構成のWebゲートの名前を指定します。

注意: Webゲート・プロファイルは、対応するホスト識別子がOracle Access Managerにまだ存在していない場合にのみ作成されます。また、次の条件も適用されます。

- webgate_idを指定していない場合は、web_domainの値で指定された値に_AGを付加した(web_domain_AG)名前を使用してプロファイルが作成されます。

- web_domainを指定していない場合は、app_domainを使用し、_AGを付加して(app_domain_AG)、プロファイルの名前が作成されます。

次に、webgate_idを使用したサンプル・コマンドを示します。

$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd)
java -jar oamcfgtool.jar app_domain=myapp webgate_id=MyWebgate
protected_uris="/protUri"
ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager"
oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_
base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_
url=http://myhost.us.myco.com:7777 -logouturi=/cgi-bin/logout.pl
-noprompt

hostname_variations

Oracle Access Managerのホスト識別子のホスト名のバリエーション・セクションへの値の追加を可能にします。

ApacheベースのWebサーバー(OHSを含む)の仮想ホストを構成する場合は、このパラメータを次のように組み込みます。

java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ...
hostname_variations=vhost1,vhost2

注意:

- Oracle Access Managerにパラメータweb_domainによって指定されたホスト識別子が存在しない場合は、この識別子が作成され、hostname_variationsの値がこのホスト識別子のホスト名のバリエーション・セクションに追加されます。

- 指定したホスト識別子がOracle Access Managerに既存の場合は、hostname_variationsの値がそのホスト識別子に既存のホスト名のバリエーション・セクションのセットに追加されます。

- パラメータwebgate_id(またはパラメータweb-domain parameterかapp_domain)によって特定されるWebゲート・プロファイルが存在しない場合、その「優先HTTPホスト」フィールドには「SERVER_NAME」が設定されます。この場合パラメータpreferred_http_hostは必須ではありません。

非ApacheベースのWebサーバーの仮想ホストを構成する場合は、パラメータpreferred_http_hostを次に説明するように組み込みます。

preferred_http_host

Webゲート・プロファイルの優先HTTPホスト・フィールドを構成可能にします。

非ApacheベースのWebサーバーの仮想ホストを構成する場合は、次のようにHOST_HTTP_HEADERの値でこのパラメータを組み込みます。

java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ...
hostname_variations=vhost1,vhost2 preferred_http_host=HOST_HTTP_HEADER

パラメータhostname_variationsおよびpreferred_http_hostを次のように使用すると、ホスト識別子に複数のホスト名のバリエーションを簡単な方法で追加できます。

java -jar oamcfgtool.jar app_domain=<app domain> web_domain=<hostid1> ...
hostname_variations=hostname1,hostname2 preferred_http_host=SOME_
HOSTNAME_VARIATION_VALUE

仮想環境の注意が適用されます。また、Webゲート・プロファイルを作成している場合、このプロファイルの優先HTTPフィールドの値には、ホスト名のバリエーションの値から任意の値を設定できます。

一般に、非仮想ホスト環境でホスト識別子を作成する場合、追加のホスト名のバリエーションは必要ありません。OAMCfgToolによってWebゲート・プロファイルの優先HTTPホスト・フィールド、および作成しているホスト識別子のホスト名のバリエーション・セクションにデフォルト値が追加されます。

default_authn_scheme

ポリシー・ドメインのデフォルトの認証スキームを構成します。認証スキーム名はアクセス・システム・コンソールでの表示どおりに渡す必要があります。

OAMCfgToolは、常に次の認証スキームのプロビジョニングを行います。

- OraDefaultBasicAuthNScheme: デフォルトのBasic認証スキーム

- OraDefaultFormAuthNScheme: デフォルトのForm認証スキーム

- OraDefaultI18NFormAuthNScheme: デフォルトのi18n認証スキーム

- OraDefaultAnonAuthNScheme: デフォルトの匿名認証スキーム

新規のデプロイメントでのツールの初回実行時に上記リストのスキームが作成されます。

パラメータ「default_authn_scheme」の一部として指定された認証スキームを使用して、構成しているポリシー・ドメインのデフォルト認証ルール・セクションが構成されます。

OAMのURIファイルを使用して、ポリシー・ドメインの保護付きポリシーの認証スキームを構成できます。保護付きポリシーはキーワード「protected_uris」の以降に指定されているポリシーです。URIファイルの認証スキーム名は次の形式で渡す必要があります(ポリシー名と認証スキーム名はタブ文字で区切る必要があります)。

<ポリシー名> 'タブ' <認証スキーム名>

URIファイルのエントリの例は次のとおりです(詳細は、この表で前出のパラメータuris_fileを参照してください)。

#-----------------------------------------------------
protected_uris

protected policy1   Basic Over LDAP
/protected1 public1/mystuff.html

protected policy2   OraDefaultFormAuthNScheme
/protected2/public2/prot2    /.../{*.js,*.png,*.gif}

protected policy3   Client Certificate
/protected2/public2/prot2/.../{*.js,*.png,*.gif}
#------------------------------------------------------

URIファイルの上記のエントリによって、次の名前付きポリシーが生成されます。

- protected policy1では、Basic Over LDAPスキームの使用が構成されます。

- protected policy2では、OraDefaultFormAuthNSchemeの使用が構成されます。

- protected policy3では、クライアント証明書スキームの使用が構成されます。

max_oam_connections

作成しているWebゲート・プロファイルに接続の最大数(「最大接続数」)を指定することによって、高可用性および複数のアクセス・サーバーの使用をサポートします。

primary_oam_servers

作成しているWebゲート・プロファイルに複数のプライマリ・アクセス・サーバーを構成することによって、高可用性および複数のアクセス・サーバーの使用をサポートします。このパラメータの形式は次のとおりです。

- コロンを使用してアクセス・サーバー名のそれぞれをWebゲートへの接続数と結合します。たとえば、primary_oam_servers="aaaid1:3"のようにします。数値の指定がない場合、デフォルトは1です。

- アクセス・サーバー名とWebゲートへの接続数のカンマ区切りリストです。たとえばprimary_oam_servers="aaaid1:3,aaaid2:1,aaaid3,aaaid4:2"のようにします。

注意:

- アクセス・サーバーのIDは、OAM内に存在していることおよび一意であること(重複がなく、さらにプライマリ値とセカンダリ値の両方には存在していない)が要求されます。

- Webゲートとアクセス・サーバーのトランスポート・セキュリティ・モードが一致している必要があります。

- Webゲートとアクセス・サーバーのアクセス管理サービス・モードが一致している必要があります。

secondary_oam_servers

作成しているWebゲート・プロファイルに複数のセカンダリ・アクセス・サーバーを構成することによって、高可用性および複数のアクセス・サーバーの使用をサポートします。このパラメータの形式は次のとおりです。

- コロンを使用してアクセス・サーバー名のそれぞれをWebゲートへの接続数と結合します。たとえば、secondary_oam_servers="aaaid1:3"のようにします。数値の指定がない場合、デフォルトは1です。

- アクセス・サーバー名とWebゲートへの接続数のカンマ区切りリストです。たとえばsecondary_oam_servers="aaaid1:3,aaaid2:1,aaaid3,aaaid4:2"のようにします。

注意:

- アクセス・サーバーのIDは、OAM内に存在していることおよび一意であること(重複がなく、さらにプライマリ値とセカンダリ値の両方には存在していない)が要求されます。

- Webゲートとアクセス・サーバーのトランスポート・セキュリティ・モードが一致している必要があります。

- Webゲートとアクセス・サーバーのアクセス管理サービス・モードが一致している必要があります。

17.3.2.1.1 OIM統合関連パラメータと値

表17-6は、OAMCfgToolのOIM統合関連パラメータと値を示しています。

関連項目:

『Oracle Fusion Middleware Oracle Identity Managementエンタープライズ・デプロイメント・ガイド』のOracle Access Manager 10gとOracle Identity Manager 11gとの統合に関する項も参照してください。

表17-6 OIM統合関連の追加パラメータと値

パラメータ

説明

configOIMPwdPolicy

Oracle Access Managerとの統合を自動化するOracle Identity Manager (OIM)パスワード・ポリシー(OraOIMDefPasswdPolicy)を作成します。また、このポリシーで使用される当該の認証スキームで、パスワードをチェックするポリシーが有効化されます。

たとえば、このポリシーをデフォルトの認証スキーム(OraDefaultFormAuthnScheme)で使用する場合、スキームの「Validate_Password」プラグインが更新され'obReadPasswdMode="LDAP",obWritePasswdMode="LDAP"'が組み込まれます。

注意: アイデンティティ・システム・コンソールのパスワード関連パラメータにはデフォルト値にOimOhsHostPortで指定された値を付加して使用します。

configOIMPwdPolicyを使用する場合は、これまでにこのツールを使用して作成されたデフォルトのOIMパスワード・ポリシーがないこと、および次のパラメータのいずれも渡さないことを確認します。

configOIMPwdPolicyを使用する場合は、これまでにこのツールを使用して作成されたデフォルトのOIMパスワード・ポリシーがないこと、および次のパラメータのいずれも渡さないことを確認します。

OimOhsHostPort

Oracle Identity Manager (OIM)をOracle Access Managerを統合し、認証WebゲートとリソースWebゲートを統合する場合に必要です。

認証Webゲートがない場合は必要ではありません。この場合はOracle Identity Manager (OIM)パスワード・ポリシー(OraOIMDefPasswdPolicy)によって、Oracle Access Managerとの統合が自動化され、ポリシーで使用される当該認証スキームで、パスワードをチェックするポリシーが有効化されます。デフォルト値は付加されているOimOhsHostPortに値があるパスワード・ポリシー関連パラメータで使用されます。例:

-OimLostPwdRedirectUrl  (Lost Password Redirect URL):
<OimOHSHostPort>/admin/faces/pages/forgotpwd.jspx
-OimPwdRedirectUrl (Password Change Redirect URL):
<OimOHSHostPort>/admin/faces/pages/pwdmgmt.jspx?backUrl=%RESOURCE%
-OimLockoutRedirectUrl (Account Lockout Redirect URL):
<OimOHSHostPort>/ApplicationLockoutURI

OimOhsHostPortパラメータは、-configOimPwdPolicyフラグが存在する場合にのみ使用されます。

OimPwdRedirectUrl

configOIMPwdPolicyで必須です。Oracle Access Managerのパスワード変更のリダイレクトURLパラメータを構成します。

OimLockoutRedirectUrl

configOIMPwdPolicyで必須です。Oracle Access Managerのカスタム・アカウント・ロックアウトのリダイレクトURLパラメータを構成します。

OimLostPwdRedirectUrl

configOIMPwdPolicyで必須です。Oracle Access Managerのロスト・パスワードのリダイレクトURLパラメータを構成します。

注意:

これは1回のみ設定する必要があります。OraOIMDefPasswdPolicyポリシーが既存の場合、新たには作成されません。この操作の後はアイデンティティ・サーバーとアクセス・サーバーを再起動する必要があります。例17-2を参照してください。

例17-2 OIM統合関連パラメータの使用方法

$ (echo ldapUserPwd; echo appAgentPwd; echo OAMModePwd; echo TestUserPwd)
java -jar oamcfgtool.jar app_domain=app_domain protected_uris="/protUri"
ldap_host=<ldap-host> ldap_port=3899 ldap_userdn="cn=Directory Manager"
oam_aaa_host=<aaa_host> oam_aaa_port=7054 oam_aaa_mode=simple ldap_
base="o=company,c=us" oam_aaa_passphrase=welcome1 authenticating_wg_
url=http://myhost.us.myco.com:7777 -configOIMPwdPolicy
OimPwdRedirectUrl="http://oimredirectutl.com
OimLockoutRedirectUrl="http://oimlockouturl.com"
OimLostPwdRedirectUrl="http://oimLostpwdurl.com"
-noprompt

17.3.2.2 VALIDATEモードのパラメータと値

マスター・アクセス管理者または委任アクセス管理者は、Oracle Access Managerを直接チェックして、ポリシー・ドメインとWebゲート・プロファイルの設定を検証できます。

注意:

アクセス・ゲート・プロファイル作成の検証には、OAMCfgToolモードを使用できません。

OAMCfgToolをVALIDATEモードで使用することにより、シングル・サインオン構成のポリシー・ドメインが正しいことを確認できます。この場合、一連のリクエストは保護されたリソースに自動的に送信されます。

表17-7は、OAMCfgToolの必須パラメータとオプション・パラメータ、およびVALIDATEモードでの各値を示しています。

表17-7 OAMCfgToolのVALIDATEモードでのパラメータと値

VALIDATEモードのパラメータ

必須パラメータのVALIDATEモード値

必須パラメータ

値

app_domain

アプリケーションを保護するために作成されたOracle Access Managerポリシー・ドメインの名前。

ldap_host

Oracle Access ManagerのLDAPディレクトリ・サーバーをホストするコンピュータのDNS名。

ldap_port

LDAPディレクトリ・サーバーのポート。

ldap_userdn

引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。

ldap_userpassword

LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。この表の「noprompt」も参照してください。

ldap_base

すべてのLDAP検索が実行されるベース。Oracle Access Managerでは、検索ベースまたは構成ベースと呼ばれています。たとえば、dc=company、c=usのように指定します。

oam_aaa_host

アクセス・サーバーをホスティングしているコンピュータのDNS名。

oam_aaa_port

アクセス・サーバー・ホストのリスニング・ポート。

test_username

ポリシー検証に使用するユーザー名。

test_userpassword

ポリシー検証に使用されるユーザー・パスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。この表の「noprompt」も参照してください。

noprompt

安全な受け渡しを保証するため、OAMCfgToolでSystem.inからのパスワードを読み取れるようにします。パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。ConfigToolでは、Ldapユーザーr、Appエージェント、OAM モード、およびテスト・ユーザーの4つのパスワードが受け入れられます。

表17-5の「noprompt」も参照してください。

オプション・パラメータ

値

web_domain

ホスト識別子。

ldap_base

すべてのLDAP検索が実行されるベース。Oracle Access Managerでは、検索ベースまたは構成ベースと呼ばれています。たとえば、dc=company、c=usのように指定します。

oam_aaa_mode

アクセス可能なAccess Serverのトランスポート・セキュリティ・モード。OPEN、SIMPLEまたはCERTを指定します。デフォルト値はOPENです。

oam_aaa_passphrase

SIMPLEトランスポート・セキュリティ・モード専用のパスフレーズ。入力はクリアテキストで表示されます。しかし、ログ・ファイルには記録されません。

log_file

OAMCfgToolログ・ファイルの名前。デフォルトでは、画面出力されます。

log_level

OAMCfgToolロギング・レベル: ALL、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびOFF(デフォルト)。

noprompt

安全な受け渡しを保証するため、OAMCfgToolでSystem.inからのパスワードを読み取れるようにします。パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。OAMCfgToolでは、LDAPユーザー、Appエージェント、OAMモード、およびテスト・ユーザーの4つのパスワードが受け入れられます。

表17-5も参照してください。

17.3.2.3 DELETEモードのパラメータと値

OAMCfgToolをDELETEモードで使用すると、プロビジョニングしたポリシー、Webドメイン、Webゲートの登録および認証スキームを削除できます。

表17-8は、OAMCfgToolのDELETEモードにおける必須パラメータとオプション・パラメータ、および値を示しています。

表17-8 OAMCfgToolのDELETEモードのパラメータ

DELETEモードのパラメータ

必須パラメータのDELETEモード値

ldap_host

Oracle Access ManagerのLDAPディレクトリ・サーバーをホストするコンピュータのDNS名。

ldap_port

LDAPディレクトリ・サーバーのポート。

ldap_userdn

引用符で囲んだ文字列として入力されている、LDAP管理ユーザーの有効なDN。Oracle Access Managerでは、ルートDNまたはバインドDNと呼ばれています。

ldap_userpassword

LDAP管理ユーザーのパスワード。パスワードはクリアテキストで表示されますが、ログ・ファイルには記録されません。表17-5の「-noprompt」も参照してください。

oam_aaa_host

アクセス・サーバーをホスティングしているコンピュータのDNS名。

oam_aaa_port

アクセス・サーバー・ホストのリスニング・ポート。

オプション・パラメータ

値

app_domain

アプリケーション・ドメイン全体を削除するには、URI関連パラメータなしでapp_domainのみを指定します。

web_domain

web_domain=existing_host_Identifier

このパラメータおよびWebゲート登録で特定されるホスト識別子を削除します。

表17-5も参照してください。

protected_uris

保護されるアプリケーションのURIのカンマ区切りリスト(空白あり/なし)(例: /myapp/login)。

アプリケーション・ドメインから1つ以上の保護付きURIを削除します。

この表のパラメータuris_fileも参照してください。

public_uris

アプリケーション・ドメインから1つ以上の公開URIを削除します。

この表のパラメータuris_fileも参照してください。

uris_file

任意の数の保護付きURIまたは公開URIが保存されたファイルへのフルパスで、パラメータprotected_urisまたはpublic_urisを使用する必要をなくします。このファイルでは次の構文および形式が使用されていることを確認します。

表17-5も参照してください。

authn_scheme

削除する認証スキームの名前。OraDefAuthSchemes、OraDefaultAWGFormAuthNScheme、およびOraDefaultI18NFormAuthNSchemeから指定します。

3つすべてを削除するには、OraDefAuthSchemesを指定します。

次のオプションを組み込むことができます。

-noconfirm: このパラメータを使用すると削除前の確認プロンプトが省略されます。

noprompt

安全な受け渡しを保証するため、OAMCfgToolでSystem.inからのパスワードを読み取れるようにします。パスワードは、echoコマンドを使用し、セパレータにはセミコロンを使用してシェルから渡すことができます。OAMCfgToolでは、LDAPユーザー、Appエージェント、OAMモード、およびテスト・ユーザーの4つのパスワードが受け入れられます。

表17-5も参照してください。

17.3.3 OAMCfgToolで作成したポリシー・ドメインとアクセス・ゲート・プロファイルのサンプル

この項では、Oracle Access Managerで表示した場合のOAMCfgToolの実行結果について説明します。

- ポリシー・ドメイン

- 「ポリシー・ドメイン」の「一般」タブ

- 「ポリシー・ドメイン」の「リソース」タブ

- 「ポリシー・ドメイン」の「認可ルール」タブ

- 「ポリシー・ドメイン」の「デフォルト・ルール」タブ

- 「ポリシー・ドメイン」の「ポリシー」タブ

- 「ポリシー・ドメイン」の「委任アクセス管理」タブ

- ホスト識別子

- アクセス・ゲート・プロファイル

ポリシー・ドメイン

名前: OAMCfgToolで指定したapp_domain値。

「ポリシー・ドメイン」の「一般」タブ

図17-1は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「一般」タブを示しています。説明は、自動的に表示されます。

名前: OAMCfgToolで指定したapp_domain値。
説明: user@hostname ...で作成したapp_domain値を含みます。

注意:

説明について、Java APIは稼働プラットフォームの現在のユーザーとコンピュータ・ホスト名user@hostnameを取得します。

図17-1 OAMCfgToolのサンプル・ポリシー・ドメインの「一般」タブ

図17-1「OAMCfgToolのサンプル・ポリシー・ドメインの「一般」タブ」の説明

「ポリシー・ドメイン」の「リソース」タブ

図17-2は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「リソース」タブを示しています。httpはデフォルトのリソース・タイプです。ホスト識別子とURL接頭辞は、入力したOAMCfgToolパラメータとその値から導出されます。説明は、自動的に表示されます。

ホスト識別子: app_domain値。
URL接頭辞: protected_uris値。

図17-2 OAMCfgToolのサンプル・ポリシー・ドメインの「リソース」タブ

図17-2「OAMCfgToolのサンプル・ポリシー・ドメインの「リソース」タブ」の説明

「ポリシー・ドメイン」の「認可ルール」タブ

図17-3は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「認可ルール」タブを示しています。図の後にサブ・タブの詳細を示します。OAMCfgToolを使用すると、ポリシー・ドメインの認可ルールが自動的に構成されます。

図17-3 OAMCfgToolのサンプル・ポリシー・ドメインの「認可ルール」タブ

図17-3「OAMCfgToolのサンプル・ポリシー・ドメインの「認可ルール」タブ」の説明

タイミング条件: タイミング条件が定義されていません。このルールは常に有効です。
アクション: アクションが定義されていません。
アクセスの許可: ロール: すべてのユーザー。
アクセスの拒否: アクセスが拒否されたユーザーはありません。

「ポリシー・ドメイン」の「デフォルト・ルール」タブ

図17-4は、OAMCfgToolで作成したサンプル・ポリシー・ドメインの「デフォルト・ルール」タブを示しています。ポリシー・ドメインに対してすべての値が自動的に構成されます。図の後にサブ・タブの詳細を示します。

認証ルール
一般、図17-4を参照してください。
アクション: アクションが定義されていません。

図17-4 OAMCfgToolのサンプル・ポリシー・ドメインの「デフォルト・ルール」タブ

図17-4「OAMCfgToolのサンプル・ポリシー・ドメインの「デフォルト・ルール」タブ」の説明

認可条件式
認可条件式: Default_Authorization。
重複アクション: この認可条件式のポリシーが定義されていません。重複アクション・ヘッダーを処理するアクセス・システム・レベルのデフォルトのポリシーが使用されます。
重複アクション・ヘッダーを処理するアクセス・システム・レベルのデフォルトの
ポリシーが使用されます。
アクション
認可成功
戻りタイプ 名前 属性
HeaderVar REMOTE_USER uid
HeaderVar OAM_REMOTE_USER uid

「ポリシー・ドメイン」の「ポリシー」タブ

図17-5は、OAMCfgToolで指定したパラメータと値を使用して作成した、サンプル・ポリシー・ドメインの「ポリシー」タブにある「一般」サブ・タブを示しています。ホスト識別子は、app_domain値に基づきます。図の後に他のサブ・タブの詳細を示します。

図17-5 OAMCfgToolのサンプル・ポリシー・ドメインの「ポリシー」タブ

図17-5「OAMCfgToolのサンプル・ポリシー・ドメインの「ポリシー」タブ」の説明

認証ルール
一般
名前: 匿名。
説明: 認証スキームでは、一部の
URIへの未認証アクセスが許可されます。
認証スキーム: 匿名認証(デフォルト)
アクション: アクションが定義されていません。

認可条件式
認可条件式が定義されていません。

監査ルール
マスター監査ルールが定義されていません。
このポリシーに監査ルールを追加する場合は、
担当のアクセス・システム管理者に問い合せてください。

「ポリシー・ドメイン」の「委任アクセス管理」タブ

図17-6は、OAMCfgToolを使用して作成されたサンプル・ポリシー・ドメインの「委任アクセス管理」タブを示しています。このツールでは、マスターWebリソース管理の委任権限を設定するパラメータは指定されていません。

図17-6 OAMCfgToolのポリシー・ドメインの「委任アクセス管理」タブ

図17-6「OAMCfgToolのポリシー・ドメインの「委任アクセス管理」タブ」の説明

関連項目:

『Oracle Access Managerアクセス管理ガイド』のポリシー・ドメインによるリソースの保護に関する項

ホスト識別子

OAMCfgToolで作成したホスト識別子は、アクセス・システム・コンソールの「アクセス・システム構成」タブで確認できます。

図17-7は、OAMCfgToolを使用して作成されたサンプル・ホスト識別子を示しています。ここで説明されているように、必須パラメータはOAMCfgToolのapp_domainパラメータに入力した値から導出されます。説明は、OAMCfgToolが表示します。

図17-7 OAMCfgToolのサンプル・ホスト識別子

図17-7「OAMCfgToolのサンプル・ホスト識別子」の説明

アクセス・ゲート・プロファイル

図17-8は、OAMCfgToolを使用し、web_domainパラメータを省略して作成されたサンプル・アクセス・ゲート・プロファイルを示しています。このプロファイルは、アクセス・システム・コンソールにあります。ここで説明するように、プロファイルの必須パラメータはOAMCfgToolで入力された値から導出されます。その他のプロファイル・パラメータはデフォルト値が使用されます。説明は、OAMCfgToolが表示します。

名前: app_domain値_AG。
ホスト名: app_domain値。
アクセス・ゲートのパスワード: app_agent_password値。
ASDKクライアント
アクセス管理サービス: オン。
Webサーバー・クライアント
プライマリHTTP Cookieドメイン: cookie_domain値。
優先HTTPホスト: app_domain値。

図17-8 OAMCfgToolのサンプル・アクセス・ゲート・プロファイル

図17-8「OAMCfgToolのサンプル・アクセス・ゲート・プロファイル」の説明

17.3.4 既知の問題: JARファイルとOAMCfgTool

表17-9に、このリリースに関する既知の問題を示します。ツール、パラメータおよび値の詳細は、「OAMCfgToolの概要」を参照してください。

表17-9 OAMCfgToolの既知の問題

バグ番号

説明

該当なし

Oracle Fusion MiddlewareアプリケーションをインストールしていないときにアクセスするOracle Access Manager認証プロバイダとOAMCfgToolのJARファイルのダウンロード元は、変更される可能性があります。この章に記載されている場所とは異なっている場合、リリース・ノートを参照して最新情報を確認してください。

8362080

OAMCfgToolには、CREATE、VALIDATE、およびDELETEのモードがあります。上書きオプションはありません。

8362039

OAMCfgToolでは、Web層のホストおよびポートを指定するための明示的なオプションは提供されません。かわりに、web_domainが指定されていない場合、app_domain値によってWebゲート名、ホストおよび優先HTTPホストが指定されます。例:

- app_domain=ABC(web_domainを指定しない)

- アクセス・ゲート名: ABC_AG

- ホスト名: ABC

- ポート: 指定しない

- 優先HTTPホスト: ABC

該当なし

OAMCfgToolでは、web_domainパラメータがコマンドラインに含まれている場合、Webゲートのパスワードを指定する必要があります。指定しない場合、コマンドラインは失敗する可能性があります。

app_agent_passwordパラメータは、等号(=)に続く任意の文字列をパスワードとして受け入れます。たとえば、app_agent_password=と入力し、空白を入力してからweb_domain=valueと入力すると、app_agent_passwordは、空白の後にweb_domainが付いた文字列であるとみなされます。

該当なし

ディレクトリ・サーバーとのSSL対応通信は、OAMCfgToolによってサポートされていません。

17.4 Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成

この項では、シングル・サインオン用のOracle Access Manager IDアサーションの構成に固有の手順について説明します。

前提条件

認証プロバイダまたはOracle Web Services Managerに関して特に明記されていないかぎり、次のタスクを含め、「OAM 10g用の認証プロバイダのインストールおよび設定」で説明されているすべてのタスクを実行する必要があります。

- 認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール

注意:

実装に応じて、次の処理を実行します。

- OAM 11g: 「セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」で説明されているとおり、リモート登録ツールを使用して、Webゲートとセキュリティ・ポリシーをプロビジョニングします。

- OAM 10g: 次のタスク3で説明されているように、OAMCfgToolを使用してWebゲート・プロファイルおよびポリシーを追加します。

アプリケーションでシングル・サインオン用のOracle Access Manager IDアサーション・プロバイダを構成するには、次のタスクの概要で説明されている手順を実行します。

タスクの概要: シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダのデプロイおよび構成

1. 前提条件のすべてのタスクが実行されていることの確認

2. Oracle WebLogic Serverとの間の信頼の確立

3. IDアサーション・プロバイダの認証スキームの構成

4. WebLogicドメインでのプロバイダの構成

5. IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定

6. OAM 10gでのSSO用のIDアサーション・プロバイダのテスト

7. Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

17.4.1 Oracle WebLogic Serverとの間の信頼の確立

次の項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンをアプリケーションで設定するための手順について説明します。

注意:

このタスクはOAM 11gとOAM 10gの両方で同じです。

- シングル・サインオン用アプリケーション認証方式の設定

- Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認

- Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

17.4.1.1 シングル・サインオン用アプリケーション認証方式の設定

この項では、Oracle Access Manager IDアサーションのアプリケーション認証方式の作成方法について説明します。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』

Oracle Access Manager IDアサーション・プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をCLIENT-CERTに指定する必要があります。

auth-methodには、BASIC、FORMまたはCLIENT-CERTの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。

注意:

WebLogicを介して直接アプリケーションにアクセスして、WebLogic認証スキームを呼び出すようにする場合には、CLIENT-CERT、FORMを指定できます。

IDアサーション・プロバイダおよびOAM 10gに対してweb.xmlで認証を指定するには

1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。

your_app/WEB-INF/web.xml

2. login-configでauth-methodを検索し、CLIENT-CERTと入力します。

<login-config>
<auth-method>CLIENT-CERT</auth-method>
</login-config>

3. ファイルを保存します。

4. アプリケーションを再デプロイして再起動します。

5. アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。

6. 「Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認」に進みます。

17.4.1.2 Oracle Access Manager IDアサーション・プロバイダ用のmod_weblogicの確認

Oracle HTTP Serverには、mod_weblogicプラグイン・モジュール(11gではmod_wl_ohs.so)が含まれ、あらかじめ有効化されています。次の手順を実行してこれを確認するか、またはこの手順を省略できます。

Oracle HTTP Server 11gを使用する場合、mod_weblogic構成がmod_wl_ohs.confにデフォルトで含まれ、このファイルのパスがhttpd.confに含まれます。mod_weblogic構成が存在しない場合は、httpd.confを編集する必要があります。

IDアサーション・プロバイダおよびOAM 10gに対してmod_weblogicを構成するには

1. httpd.confを見つけます。例:

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

2. ファイル内に次の文があり、デプロイメントに適した値が指定されていることを確認します(必要に応じてコメントを追加または削除します)。

<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>

<Location http://request-uri-pattern>
SetHandler weblogic-handler
</Location>

3. ファイルを保存します。

4. 「Oracle WebLogic Serverとその他のエンティティ間の信頼の確立」に進みます。

17.4.1.3 Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。

注意:

この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。

ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。これは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。

接続フィルタを構成してmod_weblogicとOHS 11gが実行されているホストからのリクエストのみを許可するには、ここで説明する手順を実行します。

注意:

この章では、Apache用WebLogic Serverプラグインの汎用名(mod_weblogic)を使用します。Oracle HTTP Server 11gの場合、このプラグインの名前はmod_wl_ohsで、実際のバイナリ名はmod_wl_ohs.soです。例では実装のための正確な構文を示します。

WebLogic Serverでは、デフォルト接続フィルタweblogic.security.net.ConnectionFilterImplが提供されます。このフィルタは、すべての着信接続を受け入れ、サーバーによる現在の接続フィルタの取得を許可する静的ファクトリ・メソッドも提供します。アクセスを拒否するようにこの接続フィルタを構成するには、WebLogic Server管理コンソールで接続フィルタ・ルールを入力します。

また、weblogic.security.netパッケージにクラスを実装することにより、カスタム接続フィルタを使用することもできます。デフォルト接続フィルタと同様、カスタム接続フィルタはWebLogic Server管理コンソールで構成します。

接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。

targetAddress localAddress localPort action protocols

表17-10は、接続フィルタの各パラメータを説明しています。

表17-10 接続フィルタ・ルール

パラメータ

説明

target

フィルタ対象の1つ以上のシステムを指定します。

localAddress

WebLogic Serverインスタンスのホスト・アドレスを定義します。(アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます。)

localPort

WebLogic Serverインスタンスのリスニング・ポートを定義します。(アスタリスク(*)を指定すると、サーバー上のすべての使用可能なポートが返されます。)

action

実行するアクションを指定します。この値は、allowまたはdenyである必要があります。

protocols

フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。

「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項

11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構成」の下の「ドメイン」をクリックします。

3. 「セキュリティ」タブ→「フィルタ」タブをクリックします。

4. 「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。

5. ドメインで使用する次の接続フィルタを指定します。

- デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。

- カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。

6. 適切な接続フィルタ・ルールの構文を入力します。

7. 「保存」をクリックします。

8. Oracle WebLogic Serverを再起動します。

9. 「IDアサーション・プロバイダの認証スキームの構成」に進みます。

17.4.2 IDアサーション・プロバイダの認証スキームの構成

この項では、OAM 10g用のOAMCfgToolの使用を中心に説明します。OAM 11gを使用している場合には、この項を省略して、「セッション・トークン: Oracle Access Manager 11gでのOAMエージェントのプロビジョニング」の説明にあるタスクを実行してください。

アプリケーションを設定したら、Oracle Access Managerを使用して保護する必要があります。このタスクの自動化を支援する、OAMCfgToolというコマンドライン・ツールが用意されています。このツールは、Fusion MiddlewareアプリケーションのOAM 10g用oamcfgtool.jarファイル内にあります。

この手順は、アクセス・システム・コンソールとポリシー・マネージャで手動で実行できますが、オプションのOAMCfgToolを使用して、フォームベース認証スキーム、アプリケーションのポリシー・ドメイン、およびシングル・サインオン用IDアサーションで必要とされるOracle Access Managerアクセス・ポリシーを設定および検証することができます。また、新規Web層に新しいWebゲート・プロファイルを作成したり、既存Web層のWebゲート・プロファイルを変更することもできます。

関連項目:

「OAMCfgToolの概要」

詳細は、「認証スキーム、ポリシー・ドメイン、およびWebゲート・プロファイルの作成」を参照してください。

17.4.2.1 認証スキーム、ポリシー・ドメイン、およびWebゲート・プロファイルの作成

この項では、OAMCfgToolの実行時にモデルとして使用できる手順について説明します。

この例では、新しいWebゲート・プロファイルを必要とする新規Web層を想定しています。このため、web_domain=パラメータは省略されます。新しいプロファイルが作成され、app_domain値から名前が付けられます(_AGが付加されます)。

次の手順は、このツールの使用方法の一例にすぎません。その値は、使用する環境によって異なります。

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。

OAMCfgToolを使用してフォーム認証スキーム、ポリシー・ドメインおよびアクセス・ポリシーを作成するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Fusion Middlewareアプリケーションがない場合には、OAMCfgTool を入手します。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Managerのコア・コンポーネント(10.1.4.3.0)を使用してOAMCfgTool ZIPファイルを見つけます。

oamcfgtool<version>.zip

3. oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。

2. JDK 1.6(または最新バージョン)がインストール済および構成済であることを確認します。

3. 保護するアプリケーションをホスティングしているコンピュータにログインし、OAMCfgToolが含まれているファイル・システム・ディレクトリに移動します。

注意:

- 新規Web層: web_domainパラメータを省略して、新しいプロファイルを作成および関連付けます。cookie_domainパラメータを含めます。

- 既存Web層: web_domainパラメータを含めて、既存のホスト識別子の値を指定します。

4. Webゲート・プロファイル、認証スキームおよびポリシー・ドメインを作成します。表17-5の説明に従い、環境に適した値を使用して次のコマンドを実行します。例:

(echo ldappwd | java -jar oamcfgtool.jar
mode=CREATE app_domain=IASSO_App1
protected_uris=/myapp/login
cookie_domain=<preferred_http_cookie_domain>
ldap_host=wxyz
ldap_port=6633
ldap_userdn=orcladmin
oam_aaa_host=abcd
oam_aaa_port=7789
oam_aaa_mode=cert
log_file=OAMCfg_date.log
log_level=INFO
output_ldif_file=<LDIF_filename>
-noprompt

5. このツールで指定した情報を確認します。たとえば、ステップ3のパラメータと値は次のとおりです。

Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain  : IASSO_App1
Host Identifier: IASSO_App1
Access Gate ID : IASSO_App1_AG

6. 出力LDIFの作成: LDIFをインポートし、その情報をディレクトリ・サーバーに書き込みます。該当しない場合は、この手順を省略します。

7. 検証: OAMCfgToolを実行して、作成されたポリシー・ドメインを検証します(表17-7を参照)。例:

(echo ldappwd | java -jar oamcfgtool.jar mode=VALIDATE app_domain=IASSO_App1
protected_uris=/myapp/login
ldap_host=wxyz
ldap_port=6633
ldap_userdn=orcladmin
oam_aaa_host=abcd
oam_aaa_port=7789
log_file=OAMCfg_date.log
log_level=INFO
test_username=gcf
test_userpassword=<test_userpassword>
-noprompt

8. Webゲートがインストールされていない新規Webゲート・プロファイル: Webゲートをインストールするときに、プロファイルの作成時に指定した値と同じ値(および、インストールの完了に必要なその他の値)を指定します。

9. Webゲートがインストールされている新規Webゲート・プロファイル: OAMCfgToolのCreateコマンド出力を使用してOracle Access ManagerのconfigureWebGateツールを実行し、インストールされているWebゲートを設定します。例:

1. 次の場所に移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate

ここで、WebGate_install_dirは、Webゲートのインストール先ディレクトリです。

2. 次のコマンドを実行し、OAMCfgToolで指定した値とプロファイルの完了に必要なその他の値を使用して、Webゲートを構成します。例:

configureWebGate -i WebGate_install_dir -t WebGate WebGate_Name -P
WebGate_password
-m <open|simple|cert>
-h Access_Server_Host_Name
-p Access_Server_Port
-a Access_Server_ID
-r Access_Server_Pass_Phrase (must be the same as the WebGate_password)
-Z Access_Server_Retry count

関連項目:

『Oracle Access Managerアクセス管理ガイド』のアクセス・ゲートとWebゲートの構成に関する項

10. アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。

1. マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。例:

http://hostname:port/access/oblix

hostnameはWebパスのWebサーバーをホストするコンピュータで、portはWebパスのWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。

2. 「アクセス・システム構成」をクリックし、「アクセス・ゲート構成」をクリックします。

3. 「すべて」ボタンをクリックしてすべてのプロファイルを検索し(または、リストから検索属性と条件を選択し)、「実行」をクリックします。

4. Webゲートの名前をクリックして、その詳細を表示します。

5. 「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、『Oracle Access Managerアクセス管理ガイド』の説明に従って値を変更します。

11. 保護するアプリケーションごとに、ステップ3から8を繰り返します。

12. 「WebLogicドメインでのプロバイダの構成」に進みます。

17.4.3 WebLogicドメインでのプロバイダの構成

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

- Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて

- Oracle WebLogic Scripting Tool (WLST)について

- ADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成

- Oracle Access Manager IDアサーションのプロバイダの設定

17.4.3.1 Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて

この項では、WebLogicセキュリティ・レルムの認証プロバイダを初めて使用するユーザーのために、いくつかのタイプの認証プロバイダのみを説明します。

WebLogicセキュリティ・レルムごとに、少なくとも1つの認証プロバイダを構成する必要があります。WebLogicセキュリティ・フレームワークは、マルチパート認証用に複数の認証プロバイダ(および複数のLoginModule)をサポートするように設計されています。このため、1つのセキュリティ・レルムで複数の認証プロバイダと複数のタイプの認証プロバイダを使用できます。制御フラグ属性により、認証プロセスにおいて各認証プロバイダのLoginModuleがどのように使用されるかが決定されます。

Oracle WebLogic Serverは、次のものを含め、複数のタイプの認証プロバイダとIDアサーション・プロバイダを提供します。

- デフォルトのWebLogic認証プロバイダ(デフォルトの認証プロバイダ)では、ユーザーとグループを1箇所で、つまり、WebLogic Serverの組込みLDAPサーバーで管理できます。この認証プロバイダは、Oracle WebLogic Serverでの管理ユーザー・ログインに使用されます。

- IDアサーション・プロバイダは、トークンベース認証を使用します。Oracle Access Manager IDアサーション・プロバイダはその一例です。

- LDAP認証プロバイダは、ユーザーおよびグループ情報を外部LDAPサーバーに格納します。このプロバイダは主に、一般的なディレクトリ・スキーマが反映されるように、対応するLDAPサーバーがデフォルトで構成されている点が異なります。
Oracle WebLogic Server 10.3.1以降は、OracleInternetDirectoryAuthenticatorを提供します。

複数の認証プロバイダを構成する場合、各プロバイダに対してJAAS制御フラグを使用して、ログイン・シーケンスでの認証プロバイダの使用方法を制御します。たとえば、次のJAAS制御フラグ設定を選択できます。

- REQUIRED: 認証プロバイダが常に呼び出され、ユーザーはその認証テストを常にパスする必要があります。認証の成否に関係なく、プロバイダ・リストの最後まで認証が続行されます。

- SUFFICIENT: ユーザーは、認証プロバイダの認証テストをパスする必要はありません。認証に成功した場合、後続の認証プロバイダは実行されません。認証に失敗した場合、プロバイダ・リストの最後まで認証が続行されます。

- OPTIONAL: ユーザーは、認証プロバイダの認証テストをパスしても失敗してもかまいません。ただし、セキュリティ・レルムに構成されているすべての認証プロバイダでJAAS制御フラグがOPTIONALに設定されている場合は、ユーザーは構成されているプロバイダのいずれかの認証テストをパスする必要があります。

既存のセキュリティ・レルムに認証プロバイダを追加した場合、制御フラグはデフォルトでOPTIONALに設定されます。場合によっては、認証シーケンスで各認証プロバイダが適切に機能するように、制御フラグの設定とプロバイダの順序を変更する必要があります。

関連項目:

すべての認証プロバイダのリストと、ユーザーおよびグループ属性をLDAPスキーマと一致させるためのOracle Internet Directoryプロバイダの構成方法の詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverの保護』の認証プロバイダの構成に関する項を参照してください。

17.4.3.2 Oracle WebLogic Scripting Tool (WLST)について

この項では、WLSTを初めて使用するユーザーのために、WLSTについて説明します。

Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して、WebLogicドメインにプロバイダを追加できます。

WLSTはJythonベースのコマンドライン・スクリプト環境で、WebLogic Serverドメインの管理と監視のために使用できます。通常、このツールはオンラインまたはオフラインで使用できます。このツールは、ファイルで提供されるバッチ(ユーザーの入力を介在せずに、スクリプトが一連のWLSTコマンドを呼び出すスクリプト・モード)において、コマンドラインで対話的に実行することができます。また、Javaコードに組み込むことも可能です。

WebLogicドメインに認証プロバイダを追加する場合、WLSTをオンラインで使用して認証プロバイダと対話し、ユーザー、グループおよびロールを追加、削除または変更できます。

WLSTをオフラインで使用してドメイン・テンプレートを作成する場合、WLSTによって認証プロバイダのデータ・ストアとその他のドメイン文書がパッケージ化されます。ドメイン・テンプレートからドメインを作成すると、新しいドメインは、ドメイン・テンプレートの認証プロバイダのデータ・ストアとまったく同じコピーになります。ただし、WLSTをオフラインで使用して認証プロバイダのデータ・ストア内のデータを変更することはできません。

注意:

WLSTをオフラインで使用して、認証プロバイダのデータ・ストア内のデータを変更することはできません。

関連項目:

- 「ADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「インフラストラクチャ・セキュリティ・コマンド」

17.4.3.2.1 ADFセキュリティ、OAM SSOおよびOPSS SSOを使用した、Webアプリケーション用のOracle WebLogic Serverの構成

Oracle Application Development Framework (Oracle ADF)セキュリティを使用し、Oracle Access Manager Single Sign On (SSO)と統合し、ユーザー認証にOracle Platform Security Services (OPSS) SSOを使用するWebアプリケーションをOracle WebLogic Server上で実行できます。ただし、Webアプリケーションを実行する前に、アプリケーションのターゲットのOracle WebLogic Server上で、Oracle Access Managerセキュリティ・プロバイダ用にドメインレベルのjps-config.xmlファイルを構成する必要があります。

ドメインレベルのjps-config.xmlファイルは次のパスに存在します。デプロイ済のアプリケーションのjps-config.xmlファイルと混同しないでください。

domain_home/config/fmwconfig/jps-config.xml

Webアプリケーションのデプロイ前またはデプロイ後に、Oracle Access Manager固有のWLSTスクリプトを使用して、ドメインレベルのjps-config.xmlファイルを構成できます。このOracle JRF WLSTスクリプトの名前は次のとおりです。

Linux: wlst.sh

Windows: wlst.cmd

JDevを使用して実行している場合、Oracle JRF WLSTスクリプトは次のパスにあります。

$JDEV_HOME/oracle_common/common/bin/

JRF WebLogicをスタンドアロンでインストールしている場合のパスは次のとおりです。

$Middleware_home/oracle_common/wlst

注意:

Oracle JRF WLSTスクリプトが必要です。Oracle Java Required Files (JRF)用のWLSTを実行している場合は、$JDEV_HOME/wlserver_10.3/common/binにあるWLSTスクリプトを使用しないでください。

コマンド構文

addOAMSSOProvider(loginuri, logouturi, autologinuri)

表17-11では、addOAMSSOProviderコマンドラインにおける各引数の期待値を定義しています。

表17-11 addOAMSSOProviderコマンドライン引数

引数

定義

loginuri

ログイン・ページのURIを指定します。

logouturi

ログアウト・ページのURIを指定します。

autologinuri

自動ログイン・ページのURIを指定します。

関連項目:

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』の「インフラストラクチャ・セキュリティ・コマンド」

前提条件

このタスクを開始する前に、次の項の説明にあるとおりにこれまでのすべてのタスクが実行済であることを確認します。

- Oracle WebLogic Serverとの間の信頼の確立

- IDアサーション・プロバイダの認証スキームの構成

Oracle ADFセキュリティが有効なFusion Webアプリケーション用のドメインレベルのjps-config.xmlを変更するには:

1. Oracle WebLogic ServerおよびOracle ADFセキュリティを使用しているWebアプリケーションをホストするコンピュータ上で、Oracle JRF WLSTスクリプトを見つけます。例:

cd $ORACLE_HOME/oracle_common/common/bin

2. Oracle WebLogic Serverをホストするコンピュータに接続します。

connect login_id password hostname:port

たとえば、Oracle WebLogic管理サーバーのホストは、ポート7001を使用するlocalhostであることが考えられます。ただし、これは使用する環境によって異なる可能性があります。

3. ADFセキュリティが有効なアプリケーション用の値を使用して、次のコマンドライン引数を入力します。

addOAMSSOProvider(loginuri="/${app.context}/adfAuthentication",
logouturi="/oamsso/logout.html", autologinuri="/obrar.cgi")

4. Oracle WebLogic Serverを停止して起動します。

5. この章で説明されているように次のタスクを実行します。

- IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定

- OAM 10gでのSSO用のIDアサーション・プロバイダのテスト

- Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

6. アプリケーションを実行します。

17.4.3.3 Oracle Access Manager IDアサーションのプロバイダの設定

この項では、Oracle Access Manager IDアサーション・プロバイダによるシングル・サインオンを実行するために、WebLogicセキュリティ・ドメインのプロバイダを構成する方法について説明します。次の認証プロバイダ・タイプを構成して並べ替える必要があります。

- OAM IDアサーション・プロバイダ: REQUIRED

- OID認証プロバイダ: SUFFICIENT

- デフォルトの認証プロバイダ: SUFFICIENT

関連項目:

「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

次の手順では、WebLogic管理コンソールを使用します。

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダJARファイルはすでにインストールされています。ステップ1を省略してください。

シングル・サインオン用のOracle Access ManagerプロバイダをWebLogicドメインに設定するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順でダウンロードします。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。

oamAuthnProvider<version number>.zip

3. Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle Fusion Middlewareアプリケーションをインストール済の場合:

1. 次のパスでoamauthenticationprovider.warを見つけます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
der.war

2. oamauthenticationprovider.warを次の場所にコピーします。

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

3. WebLogic管理コンソールにログインします。

4. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

5. OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。

1. 「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter

タイプ: OAMIdentityAsserter

OK

2. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

3. 「共通」タブをクリックし、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。

6. OID認証プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator

タイプ: OracleInternetDirectoryAuthenticator

OK

3. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

4. 「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。

5. 「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。

ポート: LDAPホストのリスニング・ポート。例: 6050。

プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。

資格証明: LDAPの管理ユーザー・パスワード。

ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。

すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))

ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。

グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。

デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。

保存します。

7. デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。

3. 「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。

4. 保存します。

8. プロバイダを並べ替えます。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。

3. 「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)

OID認証プロバイダ: (SUFFICIENT)

デフォルトの認証プロバイダ: (SUFFICIENT)

4. 「OK」をクリックして変更を保存します。

9. 変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。

10. Oracle WebLogic Serverを再起動します。

11. 次のようにします。

- 成功: 「IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定」に進みます。

- 失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。

17.4.4 IDアサーション・プロバイダおよびOAM 10gのログイン・フォームの設定

この項では、シングル・サインオン用のOracle Access Manager IDアサーション・プロバイダで提供されるログイン・フォームの概要を示し、このフォームをデプロイするための手順について説明します。

図17-9のフォームは、Oracle HTTP Server 11g Webサーバー用のWebゲート・インストールで提供されます。このフォームには、2つのフィールド(「ユーザーID」および「パスワード」)と「ログイン」ボタンがあります。このフォーム上の変数は、フォーム・ログイン認証スキームで必要とされます。この認証スキームはOAMCfgToolによって生成され、IDアサーション用リソースを保護しているポリシー・ドメインで使用されます。

図17-9 10g Webゲートでのシングル・サインオン用のデフォルト・ログイン・フォーム

図17-9「10g Webゲートでのシングル・サインオン用のデフォルト・ログイン・フォーム」の説明

注意:

このログイン・フォームの変数は変更しないでください。これらの変数は、Oracle Access Manager IDアサーション・プロバイダで使用する必要があります。

Webゲートのインストールおよび構成中に、Oracle HTTP Server 11g Webサーバーのhttpd.confファイルに次の情報が追加されます。これにより、Oracle HTTP Server 11gのWebゲートがデフォルト・ログイン・フォームを検索できるようになります。

Alias /oamsso "/oam/webgate/access/oamsso"

次の3行が存在する場合には、削除します。

<LocationMatch "/oamsso/*">
Satisfy any
</LocationMatch>

次の手順を参考にして、環境に適したログイン・フォームを設定してください。

注意:

このログイン・フォームは、OAM 10gでの10g Webゲート専用です。

IDアサーション・プロバイダおよびOAM 10gのログイン・フォームを設定するには

1. アプリケーションをホスティングしているコンピュータの次のOracle HTTP Server11g Webゲート・パスに、ログイン・フォームが存在することを確認します。
WebGate_install_dir/access/oamsso/login.html

2. ブラウザから、次のURLにアクセスします。
http://WebGatehost:port/oamsso/login.html

3. ログイン・プロセスで認証ユーザーを、元のリクエストしたアプリケーションURLにリダイレクトできるようにするために、ポリシー・マネージャのリソースを保護するように/accessポリシーが作成および有効化されていることを確認します。

4. 次の手順に進みます。

- Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

- OAM 10gでのSSO用のIDアサーション・プロバイダのテスト

17.4.5 OAM 10gでのSSO用のIDアサーションのテスト

次の手順では、Oracle Access Manager IDアサーションの設定をテストする方法について説明します。

また、10g Oracle Access Manager Access管理者ガイドの説明にあるように、Oracle Access Manager 10gのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。

OAM 10gでのSSO用のIDアサーションを検証するには

1. ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:

http://ohs_server:port/<protected url>

2. ログイン・フォームが表示されたら、適切な資格証明を入力します。

- 成功: 正常に実装されます。

- 失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。

17.5 Oracle Access Manager 10g用の認証プロバイダの構成

Oracle Access Manager認証プロバイダを構成するには、この項の各タスクを実行する必要があります。

前提条件

IDアサーション固有の手順として特に明記されていないかぎり、「OAM 10g用の認証プロバイダのインストールおよび設定」で説明されているすべてのタスクを完了する必要があります。

- 認証プロバイダおよびOAM 10g用のコンポーネントとファイルをインストールし、その際にアクセス・システム・コンソールでカスタム・アクセス・ゲートのアクセス・ゲート・プロファイルを手動で作成し、ポリシー・マネージャの設定でデフォルト値を受け入れます。

関連項目:

- 「Oracle Access Manager 10gのインストールと設定について」

- 「OAM 10g Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメインについて」

- Oracle Access Manager証明書のJavaキーストア形式への変換(簡易または証明書トランスポート・セキュリティ・モードを使用する場合)

- Oracle Access Manager 10gでのリソース・タイプの作成

Oracle Access Manager認証プロバイダを構成するためのその他のタスクについては、次のタスク概要で説明します。

注意:

この項のタスクを実行するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。Oracle Access Manager以外に、このタスクを自動化できるツールはありません。

タスクの概要: Oracle Access Manager認証プロバイダの構成

1. 前提条件のすべてのタスクが実行されていることの確認

2. 認証プロバイダの認証スキームの作成

3. Oracle Access Manager認証プロバイダのポリシー・ドメインの構成

4. WebLogicドメインでの認証プロバイダの構成

5. 認証プロバイダのアプリケーション認証方式の構成

6. LDAP内のグループへの認証ユーザーのマッピング

7. Oracle Access Manager認証プロバイダの実装のテスト

17.5.1 認証プロバイダの認証スキームの作成

この項では、ポリシー・ドメインにおける認証スキームの作成方法について説明します。ポリシー・ドメインは、後で認証プロバイダに対して定義します。Oracle Access Manager認証スキームは、ポリシー・ドメインの前に作成しておく必要があります。

認証プロバイダを使用する場合、ユーザーには、アプリケーションのweb.xml内で構成されている認証方式に基づいて資格証明の入力が要求されます。ただし、ポリシー・ドメインではOracle Access Manager認証スキームが必要です。

17.5.2 Oracle Access Manager認証プロバイダのポリシー・ドメインの構成

認証プロバイダの認証スキームを作成した後、そのスキームを使用するには、Oracle Access Managerでポリシー・ドメインを作成する必要があります。

Oracle Access Managerのポリシー・ドメインには、各種の情報が含まれています。図17-10に示されているように、個別のタブにそれぞれの詳細を入力できます。

図17-10 Oracle Access Managerポリシー・マネージャの「ポリシー・ドメインの作成」ページ

図17-10「Oracle Access Managerポリシー・マネージャの「ポリシー・ドメインの作成」ページ」の説明

詳細は、次の項目を参照してください。

- 「ポリシー・ドメインの作成について」

- 「認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成」

17.5.2.1 ポリシー・ドメインの作成について

この項では、ポリシー・マネージャの各タブについて説明します。これらのタブを使用してポリシー・ドメインとアクセス・ポリシーの詳細を入力できます。ポリシー・ドメインのすべてのタブを使用しない場合もありますが、次のような一般情報が提供されます。

- 「一般」タブ: このポリシー・ドメインの名前を指定する簡潔な英数字の文字列を入力します。「名前」フィールドでは、空白を使用できます。説明はオプションです。すべての詳細を保存し、ドメインを使用する準備が整うまで、このポリシー・ドメインを有効にしないでください。

- 「リソース」タブ: このポリシー・ドメインによって保護されるリソースを追加します。URL接頭辞を使用して、ポリシー・ドメインのコンテンツを定義します。説明はオプションです。

- 「認可ルール」タブ: 認可ルールを指定します。認可ルールは、一般情報、「アクセスの許可」と「アクセスの拒否」の各条件、および後で認可条件式で使用されるルールのアクション(存在する場合)で構成されます。定義するそれぞれの認可ルールに対し、1つの認証スキームを指定する必要があります。

- 「デフォルト・ルール」タブ: リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインによって保護されるリソースに適用するデフォルト・ルールを作成します。このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。
認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。

認可条件式: これには、認可ルールとそれらを組み合せる演算子が含まれています。認証プロバイダ機能では、すべてのユーザーにアクセスを許可する認可ルールが必要です。

監査ルール: マスター監査ルールが定義されていない場合は、アクセス・システム管理者に連絡するよう指示されます。

- 「ポリシー」タブ: ルールが定義されていない場合、ポリシー・ドメインのデフォルト・ルールが有効です。作成した各ポリシーに対して、特定の認証ルール、認可条件式および監査ルールを割り当てることができます。詳細に記載されたURLパターンを使用して、ポリシーを作成できます。ポリシーを設定する前に、保護するURLに対して必要なアクセス制御レベルを決定してください。

- 「委任管理者」タブ: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。

関連項目:

「認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成」、および『Oracle Access Managerアクセス管理ガイド』の次の各項

- ポリシー・ドメインの認証ルールの作成に関する項

- ポリシー・ドメインの監査ルールの作成に関する項

17.5.2.2 認証プロバイダのポリシー・ドメインとアクセス・ポリシーの作成

認証プロバイダの実装では、ポリシー・ドメインにいくつかのデフォルト値と一意の値を指定する必要があります。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。

次の手順では、認証プロバイダに対して次のようなポリシー・ドメインを作成します。

- (ポリシー・マネージャで設定された)デフォルトのBasic認証スキームを内部的に使用して、ユーザーを認証し、/Authen/Basicという接頭辞の付いたURLリソースを保護します。

- 以前に定義されたタイプwl_authenのリソースを保護します。「Oracle Access Manager 10gでのリソース・タイプの作成」も参照してください。

- 以前に作成したOracle Access Manager認証スキームを使用して、ユーザーの資格証明をリクエストします。

注意:

認証プロバイダでは、アプリケーションのweb.xmlファイルで定義されているBasic認証方式が必要です。この認証方式は、「認証プロバイダのアプリケーション認証方式の構成」の説明に従って後で設定します。

- デフォルト認証ルールとアクションが必要です。次の手順で、認証の成功時にユーザーとグループが返されるようにこれらを構成します。

- アクションが定義されていないデフォルト認可ルールが必要です。これを、次の手順で構成して、すべてのユーザーにアクセスを許可するようにします。

注意:

認証プロバイダでは、認可は実行されません。ただし、認可ルールを作成して、すべてのユーザーにアクセスを許可する必要があります(認可条件式は必要ありません)。

次の例は、説明のみを目的としています。環境に応じて適切な値を入力してください。

Oracle Access Manager認証プロバイダのポリシー・ドメインを作成するには

1. ポリシー・マネージャに移動して、ログインします例:

http://Webserver:port/access/oblix

ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システムに接続します。

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のナビゲーション・ペインの「ポリシー・ドメインの作成」をクリックして、「ポリシー・ドメインの作成」ページを表示します。

4. 「一般」タブ: ポリシー・ドメイン・リストを示すページに表示される名前とオプションの説明を入力し、「保存」をクリックします。例:
名前: Default OAM Authenticator

説明: For Username Resolution

注意:

すべての指定が完了するまで、このポリシー・ドメインを有効にしないでください。

5. 「リソース」タブ: 「リソース」タブ→「追加」ボタンをクリックし、リソース・タイプを選択してURL接頭辞を入力します。次の内容を保存します。
リソース・タイプ: wl_authen

ホスト識別子(オプション): アクセス・ゲートの優先HTTPホストを選択します。

URL接頭辞: /Authen/Basic

説明: OAM Authenticator validates user name, password

「追加」をクリックします。

リソース・タイプ: wl_authen

URL接頭辞: /Authen/UsernameAssertion

説明: Authenticator Resource to validate user name

「保存」をクリックします。

6. 「デフォルト・ルール」タブ: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加します。リソースが特定のポリシーによって保護されている場合を除き、ポリシー・ドメインのデフォルト・ルールがポリシー・ドメイン内のリソースに適用されます。

1. 「デフォルト・ルール」をクリックし、「追加」をクリックしてBasic認証スキームのルールを作成します。

2. 認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームと複数の認証アクションを指定します。名前とオプションの説明を入力し、「認証スキーム」を選択します。
「認証ルール」をクリックし、「一般」タブに次の情報を入力します。

名前: Basic Authentication Scheme

説明: User name and password based authentication

認証スキーム: Basic Over LDAP

「保存」をクリックします。

注意:

認証プロバイダでは、ObMyGroups属性のルールでAuthentication Success Returnアクションのみが必要です。このアクセス・サーバー固有の属性は、ユーザーが属しているすべてのグループを返します。手順Cで説明されているように、他の2つの実装でもこのアクションが必要です。

3. 認証ルール、アクション: 認証プロバイダを使用する場合(またはOracle Access Managerに存在する管理者ユーザーとしてOracle WebLogicを起動する場合、あるいはOracle Web Services Managerを使用している場合)に指定します。
「アクション」タブ→「追加」をクリックします。

「認証成功」に、次の情報を入力します。

リダイレクションURL: 空白

戻り値

タイプ: WL_REALM

名前: obmygroups

戻り属性: obmygroups

この戻り属性は、ユーザーが属しているすべてのグループを返すようにアクセス・サーバーに指示します。

次に、LDAPディレクトリ・サーバーでユーザーを一意に識別するために、ユーザー名のログイン・パラメータの名前を入力します。

タイプ: WL_REALM

名前: uid

戻り属性: uid

この戻り属性は、ユーザー名のログイン・パラメータの名前を返します。これは、Oracle Access Managerで使用されるLDAPディレクトリ・サーバーのユーザーを一意に識別するために役立ちます。

7. 認可ルール: 「認可ルール」タブをクリックし、「追加」をクリックして、

1. ルール名と簡単な説明(省略可能)を指定します。例:
名前: Default rule for Authenticator.

説明: Default rule enables Authenticator function for anyone.

2. 「有効」リストから「はい」を選択して、「保存」をクリックします。

3. ルールをクリックして、「アクセスの許可」タブをクリックし、「追加」をクリックして、「ロール」で、「すべてのユーザー」を選択して、保護されているリソースへのアクセスをすべてのユーザーに許可します。

4. 「保存」をクリックします。

8. 「ポリシー」タブ: 「ポリシー」タブ→「追加」をクリックします。
情報を入力し、「一般」の詳細を保存します。

名前: Default Username Resolution Policy

説明: Default Username Policy for Authenticator

リソース・タイプ: wl_authen

リソース操作: LOGIN

リソース: /Authen/UsernameAssertion

他の項目は変更せず、そのままにしておきます。

「保存」をクリックします。

「認証ルール」サブ・タブ→「追加」をクリックし、「一般」の詳細を入力します(名前、オプションの説明、認証スキーム)。

名前: Username Resolution Authentication Rule

認証スキーム: UsernameAssertion認証スキーム

「認証プロバイダの認証スキームの作成」を参照してください。

「保存」をクリックします。

「アクション」サブ・タブをクリックし、「認証成功」に次の情報を追加します。

- 戻り型: WL_REALM

- 戻り名: uid

- 戻り属性: uid

注意:

「戻り属性」には、必ず値を入力してください。uidは、LDAP ObjectClassのログイン属性名で、Oracle Access Managerによって使用されるディレクトリ・サーバーでユーザーを一意に識別するために役立ちます。

「アクション」サブ・タブをクリックし、「認証成功」に次の情報を追加します。

- 戻り型: WL_REALM

- 戻り名: obmygroups

- 戻り属性: obmygroups

注意:

obmygroupsは、メンバーが属しているすべてのグループを返します。

9. 委任アクセス管理: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。

関連項目:

『Oracle Access Managerアクセス管理ガイド』のポリシー・ドメイン管理の委任に関する項

10. 「WebLogicドメインでの認証プロバイダの構成」に進みます。

17.5.3 WebLogicドメインでの認証プロバイダの構成

この項では、WebLogicドメインに適切な認証プロバイダを追加および構成するための手順について説明します。

Oracle Access Manager認証プロバイダは、WebLogicドメインのデフォルト認証プロバイダに従って構成する必要があります。

- デフォルトの認証プロバイダ: SUFFICIENT

- OAM認証プロバイダ: OPTIONAL

次の手順では、WebLogic管理コンソールを使用してこのタスクを実行する方法について説明します。これらは、Oracle WebLogic Scripting Tool (WLST)を使用して追加することもできます。

関連項目:

- 「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なファイルはすでにインストールされているので、ステップ1は省略できます。

WebLogicドメインにOracle Access Manager認証プロバイダを構成するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:

oamAuthnProvider<version>.zip

3. Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle WebLogic管理コンソールに移動します。

3. Oracle Fusion Middlewareアプリケーションをインストール済の場合:

1. 次のパスでoamauthenticationprovider.warを見つけます。

ORACLE_INSTANCE/modules/oracle.oamprovider_11.1.1/oamauthenticationprovi
der.war

2. oamauthenticationprovider.warを次の場所にコピーします。

BEA_HOME/wlserver_10.x/server/lib/console-ext/autodeploy/oamauthentication
provider.war

4. Oracle WebLogic管理コンソールに移動します。

5. 必要に応じて、「ロックして編集」をクリックします。

6. OAM認証プロバイダ:

1. 「セキュリティ・レルム」をクリックし、構成するレルムを選択します。

2. 「プロバイダ」→「認証」を選択し、「新規」をクリックして、「新しい認証プロバイダの作成」ページを表示します。

3. 名前を入力して、タイプを選択します。
名前: OAMAuthN

タイプ: OAMAuthenticator

OK

4. 作成した認証プロバイダの名前をクリックして、「プロバイダ構成」ページを表示します。

5. 「プロバイダ構成」ページで、次のように必要な値を設定します。
アクセス・ゲート名: プロバイダによって使用されるアクセス・ゲートの名前。これは、アクセス・システム・コンソールのアクセス・ゲート構成プロファイル内の名前と完全に一致している必要があります。

注意:

認証プロバイダ用のアクセス・ゲート構成プロファイルが1つしかない場合もあります。

アクセス・ゲートのパスワード: アクセス・システム・コンソールでアクセス・ゲート構成プロファイルに対してパスワードが定義されている場合は、それと同じパスワード。

プライマリ・アクセス・サーバー: アクセス・システム・コンソールでこのアクセス・ゲートに関連付けられているプライマリ・アクセス・サーバーのhost:port。

詳細構成: 次に、いくつかの詳細構成の値を示します。

トランスポート・セキュリティ: アクセス・サーバーとアクセス・ゲート間の通信モード(オープン、簡易、証明書)。

トランスポート・セキュリティが簡易または証明書である場合、次のパラメータと値を含めてください。

トラスト・ストア: プロバイダとOracle Access Server間のSSL通信で使用されるJKSトラスト・ストアの絶対パス。

キー・ストア: プロバイダとOracle Access Server間のSSL通信で使用されるJKSキー・ストアの絶対パス。

キー・ストアのパスフレーズ: キー・ストアにアクセスするためのパスワード。

簡易モード・パスフレーズ: アクセス・ゲートとアクセス・サーバーで共有される簡易通信モード用パスワード。

セカンダリ・アクセス・サーバー: アクセス・システム・コンソールでこのアクセス・ゲートに関連付けられているセカンダリ・アクセス・サーバーのhost:port。

プール内の最大アクセス・サーバー接続数: アクセス・ゲートがアクセス・サーバーに対してオープンする最大接続数。デフォルト値は10です。

注意:

WebLogic管理コンソールでのプール内の最大アクセス・サーバー接続数(またはプール内の最小アクセス・サーバー接続数)の設定は、アクセス・システム・コンソール内でプロファイルに指定されている「最大接続数」または「最小接続数」とは異なります。

プール内の最小アクセス・サーバー接続数: 認証プロバイダからアクセス・サーバーへの認証リクエストの送信に使用する最小接続数。デフォルト値は5です。

関連項目:

共通パラメータとプロバイダ固有パラメータの説明と値については、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。

6. パラメータ「制御フラグ」がOPTIONALに初期設定されていることを確認します。

注意:

認証プロバイダが機能し、正しく構成されていることを確認するまで、パラメータ「制御フラグ」をREQUIREDに設定しないでください。

7. チェンジ・センターで、変更のアクティブ化をクリックします。

8. DefaultAuthenticator: 「プロバイダ」タブでDefaultAuthenticatorを選択します。これにより、その制御フラグがSUFFICIENTに変更されます。

9. 並べ替え: 「プロバイダ」タブで、DefaultAuthenticatorが先頭になるように(DefaultAuthenticatorの後にOAMAuthenticator)プロバイダを並べ替えます。

注意:

Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。

10. Oracle Access Manager認証プロバイダのREQUIREDまたは唯一の認証プロバイダである場合: 次の手順を実行して、Oracle WebLogic Serverを起動するためのユーザー権限を設定します。

1. 管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。

注意:

その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。

2. Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。

3. WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。

4. Adminロールの「条件の表示」を選択します。

5. グループを追加して「保存」をクリックします。

11. WebLogic Serverを再起動します。

12. サーバーを起動すると、認証プロバイダ・パラメータ「制御フラグ」が適切な値(REQUIRED、OPTIONAL、またはSUFFICIENT)にリセットされます。

注意:

推奨値は、REQUIREDです。既知の問題を防止するには、「JAAS制御フラグ」を参照してください。

13. 「認証プロバイダのアプリケーション認証方式の構成」に進みます。

17.5.4 認証プロバイダのアプリケーション認証方式の構成

この項では、Oracle Access Manager認証プロバイダのアプリケーション認証方式の作成方法について説明します。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』

Oracle Access Manager認証プロバイダを使用する場合、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素をBASICに指定する必要があります。

auth-methodには、BASICまたはFORMの値を指定できます。Oracle Access Managerでは、どの値を使用しても同様の結果になりますが、web.xmlファイルのauth-methodは、Oracle Access Managerではなく、Oracle WebLogic Serverで使用されることに注意してください。

注意:

Oracle Access Manager認証プロバイダの場合、web.xml内のlogin-configにauth-method BASICを指定することをお薦めします。

認証プロバイダのアプリケーション認証方式を構成するには

1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。

WEB-INF/web.xml

2. login-configでauth-methodを検索し、BASICと入力します。例:

<security-constraint>
<web-resource-collection>
<web-resource-name>protected</web-resource-name>
<url-pattern>/servlet</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>auth-users</role-name>
</auth-constraint>
</security-constraint>
<login-config>
<auth-method>BASIC</auth-method>
</login-config>
<security-role>
<description>Authenticated Users</description>
<role-name>auth-users</role-name>
</security-role>

3. ファイルを保存します。

4. アプリケーションを再デプロイして再起動します。

5. アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。

6. 「LDAP内のグループへの認証ユーザーのマッピング」に進みます。

17.5.5 LDAP内のグループへの認証ユーザーのマッピング

この項では、認証ユーザーをLDAP内のグループにマップする方法について説明します。このためには、weblogic.xmlファイルを編集する必要があります。たとえば、ロール名auth-usersをLDAP内のmanagersというグループにマップできます。

Oracle Access Manager認証プロバイダ用に認証ユーザーをLDAP内のグループにマップするには

1. アプリケーションのweblogic.xmlファイルに移動します。

2. ファイル内の任意の場所に、環境に応じて次の情報を追加します。

<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app
http://www.bea.com/ns/weblogic/weblogic-web-app/1.0/weblogic-web-app.xsd"
xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">
<security-role-assignment>
<principal-name>managers</principal-name>
<role-name>auth-users</role-name>
</security-role-assignment>
</weblogic-web-app>

3. ファイルを保存します。

4. WebLogic Serverを再起動します。

5. 次の手順に進みます。

- Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成

- Oracle Access Manager認証プロバイダの実装のテスト

17.5.6 Oracle Access Manager認証プロバイダの実装のテスト

認証プロバイダの実装タスクをすべて実行した後、有効な資格証明を使用してアプリケーションへのログインを試行して実装をテストできます。構成が正しくない場合、有効なユーザーがアクセスを拒否されます。

次の手順では、認証プロバイダの設定をテストする方法について説明します。『Oracle Access Managerアクセス管理ガイド』の説明に従って、Oracle Access Managerのアクセス・テスターを実行してポリシー・ドメインをテストする方法もあります。

Oracle Access Manager認証プロバイダの実装を検証するには

1. ご使用の環境の保護されているリソースをアクセスするURLを入力します。例:

http://yourdomain.com:port

2. ログイン・フォームが表示されたら、適切な資格証明を入力します。

- 成功: 正常に実装されます。

- 失敗: 「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。

17.6 Oracle Web Services ManagerおよびOAM 10g用のIDアサーションの構成

この項では、Oracle Web Services ManagerがWebサービスを保護している場合に、ObSSOCookieトークンの検証を有効にするようにOracle Access Manager IDアサーション・プロバイダを設定する方法について説明します。

Oracle Access Manager IDアサーション・プロバイダがヘッダーとObSSOCookieトークンの両方の検証モードで構成されている場合、ヘッダーが優先されます。ヘッダーが存在しない場合は、IDアサーション・プロバイダはアクセス・サーバーにアクセスしてObSSOCookieトークンを検証します。

Oracle Access Manager IDアサーション・プロバイダは、次の2つのモードで機能します。

- デフォルト・モードの操作では、Webゲートが境界に設定したヘッダーがアサートされます。

- もう1つのモードでは、oamAuthnProvider.jarにあるカスタム・アクセス・ゲートを使用します。この場合(ヘッダーも存在しない場合)、IDアサーション・プロバイダはアクセス・サーバーにアクセスしてObSSOCookieトークンを検証します。

注意:

Oracle Web Services Managerでは、アクセス・ゲートが必要です。

前提条件

- 認証プロバイダおよびOAM 10g用のコンポーネントとファイルをインストールし、その際にアクセス・システム・コンソールでカスタム・アクセス・ゲートのアクセス・ゲート・プロファイルを手動で作成し、ポリシー・マネージャの設定でデフォルト値を受け入れます。

関連項目:

- 「Oracle Access Manager 10gのインストールと設定について」

- 「OAM 10g Webゲート/アクセス・ゲート・プロファイルとポリシー・ドメインについて」

- Oracle Access Manager 10gでのリソース・タイプの作成

タスクの概要: Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ

1. 前提条件のすべてのタスクが実行されていることの確認

2. Oracle Web Services Managerで使用されるポリシー・ドメインの作成

3. Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成

4. Oracle Web Services Manager用のIDアサーション・プロバイダのテスト

17.6.1 Oracle Web Services Managerで使用されるポリシー・ドメインの作成

この項では、Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダによって使用されるポリシー・ドメインを設定する方法について説明します。ポリシー・ドメインを作成、表示または変更するには、Oracle Access Managerのマスター・アクセス管理者または委任アクセス管理者である必要があります。

このポリシー・ドメインでは、次の一意の値が必要です。

- (ポリシー・マネージャで設定された)デフォルトのBasic Over LDAP認証スキームを内部的に使用して、ユーザーを認証し、/Authen/SSOTokenという接頭辞の付いたURLリソースを保護します。

- 「Oracle Access Manager 10gでのリソース・タイプの作成」で定義した、タイプwl_authenのリソースを保護します。

- アクションが定義されていないデフォルト認証ルールが必要です。これは、次の手順で設定します。

- アクションが定義されているデフォルト認可ルールが必要です。これは、次の手順で設定します。

次の手順では、Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダによって使用されるポリシー・ドメインを作成する方法について説明します。

Oracle Web Services Managerを使用するIDアサーション・プロバイダのポリシー・ドメインを作成するには

1. ポリシー・マネージャに移動して、ログインします例:

http://Webserver:port/access/oblix

ここで、Webserverはポリシー・マネージャのWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。

2. 「ポリシー・マネージャ」をクリックします。

3. 左側のナビゲーション・ペインの「ポリシー・ドメインの作成」をクリックして、「ポリシー・ドメインの作成」ページを表示します。

4. 「一般」タブ: ポリシー・ドメイン・リストを示すページに表示される名前とオプションの説明を入力し、「保存」をクリックします。例:
名前: OAM IA OWSM

説明: Used by Identity Asserter with Oracle Web Services Manager

注意:

すべての詳細が完了するまで、このポリシー・ドメインを有効にしないでください。

5. 「リソース」タブ: 「リソース」タブ→「追加」ボタンをクリックし、リソース・タイプを選択してURL接頭辞を入力します。次の内容を保存します。
リソース・タイプ: wl_authen

URL接頭辞: /Authen/SSOToken

説明: Used by IA OWS to validate SSO token

保存します。

6. 「認可ルール」タブ: 後で認可条件式で使用する認可ルールを追加します。
「認可ルール」タブ→「追加」ボタンをクリックします。

1. 「一般」タブ: 認可ルールの名前と、オプションで簡潔な説明を入力します。
名前: Default_OAM_IA_OWS_AuthZ_Rule

説明: For use with OWS and Identity Asserter

有効: はい

許可を優先: いいえ

キャッシュの更新: はい(すべてのアクセス・サーバーのキャッシュを即時に更新)

2. タイミング条件: このシナリオには必要ありません。

3. アクション: このタブでの設定は必要ありません。かわりに、「デフォルト・ルール」タブでこれらを設定します。

4. アクセスの許可: ルールの「アクセスの許可」部分を適用するユーザーの詳細を追加します。
ロール: 任意の個人

5. アクセスの拒否: このシナリオでは必要ありません。

6. 認可ルールの「一般」タブに戻り、ルールを有効にして、後で認可条件式に追加できるようにします。

関連項目:

認可スキームとルールの構成の詳細は、『Oracle Access Managerアクセス管理ガイド』の第6章を参照してください。

7. 「デフォルト・ルール」タブ: このタブから、このポリシー・ドメインの認証ルール、認可条件式および監査ルールを追加できます。リソースが特定のポリシーによって保護されている場合を除き、これらのデフォルト・ルールがポリシー・ドメイン内のリソースに適用されます。
「デフォルト・ルール」→「追加」をクリックします。

1. 認証ルール: ポリシー・ドメインには、少なくとも1つの認証ルールが含まれている必要があります。認証ルールは、1つの認証スキームとオプションの認証アクションを指定します。名前とオプションの説明を入力し、「認証スキーム」を選択します。
「一般」タブ: 次のように入力します。

名前: Default AuthN Rule

説明: Default Rule for OAM IA OSW

認証スキーム: Basic Over LDAP

「保存」をクリックします。

「アクション」タブ: Oracle Web Services Managerのデフォルト・ルールでは、認証アクションは必要ありません。

注意:

Oracle Web Services Managerを使用している場合は、認可ルールが必要です。

2. 認可条件式: 条件式を含むポリシーによってリソースが保護されている場合を除き、ポリシー・ドメインのデフォルト・ルールの認可条件式は、ドメイン内のすべてのリソースに適用されます。
「認可条件式」タブ→「追加」をクリックします。

「式」タブ: ステップ6で作成した認可ルールを選択します。

認可ルールDefault_OAM_IA_OWS_AuthZ_Ruleを選択します。

「追加」をクリックします。

「保存」をクリックします。

「アクション」タブ: ステップ6で、ルールの「アクセスの許可」部分を適用するユーザーを定義しました。ここでは、ルールと式の両方について、認証成功のアクションを指定します。

「アクション」→「追加」をクリックし、次のように認証が成功した場合に呼び出されるアクションを指定して、「認可成功」の戻りアクションを作成します。

認可成功: 「アクセスの許可」の条件に適用されます。

戻り型: WL_REALM

戻り名: uid

戻り属性: uid

「保存」をクリックします。

注意:

戻り属性uidは、Oracle Access ManagerのLDAPリポジトリでユーザーを一意に識別するために、ユーザー名のログイン・パラメータの値に一致させる必要があります。uidは、ログイン属性の正規名です。LDAPディレクトリで異なる属性がログイン属性として使用されている場合でも、名前はuidになります。ただし、戻り属性は、ログイン属性の構成に一致します(mailなど)。これらの値は、(「戻り値」ではなく)「戻り属性」に入力する必要があります。

8. 「ポリシー」タブ: ポリシーは必要ありません。デフォルト・ルールが適用されます。

9. 委任アクセス管理: ポリシー・ドメインにURL接頭辞を追加する場合、委任アクセス管理者は、そのURL接頭辞をホスティングするサーバーを指定する必要があります。

関連項目:

『Oracle Access Managerアクセス管理ガイド』のポリシー・ドメイン管理の委任に関する項

10. ポリシー・ドメインの検証: 「ポリシー・ドメイン」をクリックし、作成した新しいポリシー・ドメインをクリックした後、「ページとして表示」をクリックしてすべての詳細をまとめて表示します。

11. 「Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成」に進みます。

17.6.2 Oracle Web Services ManagerのWebLogicドメインでのプロバイダの構成

Oracle Web Services ManagerがWebサービスを保護している場合に、Oracle Access Manager IDアサーション・プロバイダを使用するには、WebLogicドメインでいくつかの認証プロバイダを構成し、並べ替える必要があります。

- OAM IDアサーション・プロバイダ: REQUIRED

- OID認証プロバイダ: SUFFICIENT

- デフォルトの認証プロバイダ: SUFFICIENT

この手順は、Oracle Access Manager IDアサーション・プロバイダの場合とほとんど同じです。この場合の相違点は、Oracle Web Services Managerはカスタム・アクセス・ゲートを必要とし、追加のプロバイダ固有の値が必要になることです。

- プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。

- アクセス・ゲート名: アプリケーションを保護するアクセス・ゲートの名前。例: mmmm。

- アクセス・ゲートのパスワード: アクセス・システム・コンソールで指定したアクセス・ゲート・パスワード。

これらは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して追加できます。

関連項目:

- 「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』

注意:

Oracle Fusion Middlewareアプリケーションをインストール済の場合、必要なプロバイダ・ファイルはすでにインストールされています。ステップ1を省略してください。

WebLogicドメインでプロバイダを設定するには

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Access Managerプロバイダを、次の手順で入手します。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Manager Webゲート(10.1.4.3.0)を使用してoamAuthnProvider ZIPファイルを見つけます。例:

oamAuthnProvider<version>.zip

3. Oracle WebLogic Serverをホスティングしているコンピュータで、次のパスにoamAuthnProvider.jarを抽出およびコピーします。

BEA_HOME/wlserver_10.x/server/lib/mbeantypes/oamAuthnProvider.jar

2. Oracle WebLogic管理コンソールにログインします。

3. OAM IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証」→「新規」をクリックし、名前を入力してから次のプロバイダ・タイプを選択します。
名前: OAM Identity Asserter

タイプ: OAMIdentityAsserter

OK

3. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

4. 「共通」タブで、「制御フラグ」をREQUIREDに設定して「保存」をクリックします。

5. プラットフォーム固有のタブをクリックし、次のパラメータを構成します。
プライマリ・アクセス・サーバー: ホストとポート番号を指定します。例: abcd:7777。

アクセス・ゲート名: アプリケーションを保護するアクセス・ゲートの名前。例: mmmm。

アクセス・ゲートのパスワード: アクセス・システム・コンソールで指定したアクセス・ゲート・パスワード。

保存します。

4. OID認証プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「新規」をクリックして名前を入力し、プロバイダ・タイプを選択します。
名前: OID Authenticator

タイプ: OracleInternetDirectoryAuthenticator

「OK」をクリックします。

3. 認証プロバイダの表で、新たに追加した認証プロバイダをクリックします。

4. 「設定」ページで「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定して「保存」をクリックします。

5. 「プロバイダ固有」タブをクリックした後、使用する環境の値を使用して次の必要な設定を指定します。
ホスト: LDAPホスト。例: localhost。

ポート: LDAPホストのリスニング・ポート。例: 6050。

プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。

資格証明: LDAPの管理ユーザー・パスワード。

ユーザー・ベースDN: Oracle Access Managerと同じ検索ベース。

すべてのユーザーのフィルタ: 例: (&(uid=*)(objectclass=person))

ユーザー名属性: LDAPディレクトリのユーザー名のデフォルト属性として設定します。例: uid。

グループ・ベースDN: グループ検索ベース(ユーザー・ベースDNと同じ)。

注意:

デフォルト設定でも正常に機能するため、「すべてのグループのフィルタ」は設定しないでください。

「保存」をクリックします。

5. デフォルトの認証プロバイダ: 次の手順を実行して、デフォルトの認証プロバイダをIDアサーション・プロバイダと使用するために設定します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証」→「DefaultAuthenticator」をクリックし、構成ページを表示します。

3. 「共通」タブをクリックし、「制御フラグ」をSUFFICIENTに設定します。

4. 「保存」をクリックします。

6. プロバイダを並べ替えます。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. プロバイダが一覧表示される「概要」ページで、「並べ替え」ボタンをクリックします。

3. 「認証プロバイダの並べ替え」ページでプロバイダ名を選択してから、この一覧の隣にある矢印を使用して、次のようにプロバイダを並べ替えます。
OAM IDアサーション・プロバイダ: (REQUIRED)

OID認証プロバイダ: (SUFFICIENT)

デフォルトの認証プロバイダ: (SUFFICIENT)

4. 「OK」をクリックして変更を保存します。

7. 変更のアクティブ化: チェンジ・センターで、「変更のアクティブ化」をクリックします。

8. Oracle WebLogic Serverを再起動します。

9. 次のようにします。

- 成功: 「Oracle Web Services Manager用のIDアサーション・プロバイダのテスト」に進みます。

- 失敗: すべてのプロバイダで環境に適した値が適切な順序で指定されていることを確認し、「認証プロバイダおよびOAM 10g用のコンポーネントとファイルのインストール」で説明されているように、oamAuthnProvider.jarが正しい場所に格納されていることを確認してください。

17.6.3 Oracle Web Services Manager用のIDアサーション・プロバイダのテスト

Oracle Web Services ManagerとOracle Access Manager IDアサーション・プロバイダとの併用を検証するには、IDアサーション・プロバイダとOracle Web Services Managerのポリシーによって保護されているWebサービスにアクセスします。アクセスが許可されれば、実装は機能しています。失敗した場合は、「OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント」を参照してください。

17.7 ユーザーとSSOセッションの同期: SSO同期フィルタ

Fusion Middleware 11gには、コンテナ・ユーザー・セッションとSSOセッションを同期する新しいコンポーネントが導入されています。SSO同期フィルタは、Oracle WebLogicシステム・フィルタの実装です。SSO同期フィルタは、コンテナへのすべてのリクエストをインターセプトし、保護されたリソース・リクエストを操作して、コンテナのユーザー・セッションとOSSOのユーザー識別ヘッダー(Proxy-Remote-User)、またはOracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データとの同期を試みます。

SSO同期フィルタは、Javaサーブレット仕様バージョン2.3に基づくサーブレット・フィルタの実装です。SSO同期フィルタにより、アプリケーションはSSOユーザー・セッションを追跡して各セッションと同期する必要がなくなります。アプリケーションは、コンテナのユーザー・セッションと同期するだけで済みます。

SSO同期フィルタは、コンテナへの各リクエストをインターセプトし、そのリクエストに添付されているHTTPヘッダーに基づいて操作するかどうかを決定します。フィルタは、SSOエージェントがこれらのヘッダーをWeb層で設定していることを必要とします。保護されていないアプリケーション領域にアクセスする場合、フィルタはパススルーとして機能します。保護されたリソースにアクセスした後、Web層のSSOエージェントは、Oracle Access ManagerなどのSSOシステムで認証を実行するようユーザーに指示します。認証後、Oracle Access Manager IDアサーション・プロバイダによってユーザー・アイデンティティがJAASサブジェクトとしてコンテナに確立され、ユーザー・セッションが作成されます。WebLogicでは、ユーザー・セッション・データがHTTPセッションCookieの一部(JSESSIONID)として保持されます。

アプリケーション・リソースへの後続アクセスでは、SSO同期フィルタに次の2つの情報が提供されます。

- OSSOのユーザー識別ヘッダー(Proxy-Remote-User)

- Oracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データ

SSO同期フィルタの役割は、コンテナのユーザー・アイデンティティとSSOセッションのユーザー・アイデンティティが一致していることを確認することです。不一致がある場合、フィルタはそのコンテナのユーザー・セッションを無効にします。このため、ダウンストリーム・アプリケーションはコンテナのユーザー・セッションを追跡するだけで済み、使用しているSSO環境に関係なく一貫した方法で作用できます。

注意:

- デフォルトで有効: SSO同期フィルタは、構成されたトークンからユーザー情報をフェッチし、既存セッション(存在する場合)からユーザーを取得し、CurrentSessionUserが着信SSOユーザーと一致していない場合はセッションを無効にしてリクエストされたURLにリダイレクトします。そうでない場合、リクエストは単にパススルーされます。
ドメインでOSSOまたはOracle Access Managerアサーション・プロバイダを構成していない場合、フィルタはWebLogic Serverの起動中に自動的に無効になります。

- デフォルトですべてのURIに対して有効(/*): アプリケーション・コードでの変更は不要です。

- OSSOトークン/ヘッダーに対する構成: Proxy-Remote-Userが検索され、大/小文字を区別しない一致が実行されます。

- Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_REMOTE_USERとREMOTE_USERが検索され、大/小文字を区別しない一致が実行されます。

- グローバル・ログアウト: SSO同期フィルタは、OSSOまたはOracle Access Managerソリューションを使用するOracle Fusion Middlewareアプリケーションに対してシングル・ログアウト操作を提供します。これは、シングル・サインオンと同様に処理されます。グローバル・ログアウトが実行されると、セッションのクリーンアップが実行されていないアプリケーションに対して後続アクセスが行われたときに、SSOフィルタによってセッションが調整されます。
OSSOまたはOracle Access Managerソリューションを使用するアプリケーションは、OSSOログアウトまたはOracle Access Managerログアウトのコールを実行する前にそのセッションを無効にする必要があります。OSSOログアウトの詳細は、例18-2「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。

- アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。

様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表17-12に、各プロパティと同期動作を示します。

表17-12 SSO同期フィルタの各プロパティと同期動作

領域

優先システム・プロパティ

システム・プロパティのデフォルト値

同期フィルタのデフォルト動作

ステータス(有効または無効)

sso.filter.enable

構成なし

有効

大/小文字を区別した一致

sso.filter.name.exact.match

構成なし

大/小文字を区別しない一致

構成されたトークン

sso.filter.ssotoken

構成なし

- OSSO: Proxy-Remote-Userを検索する

- Oracle Access Manager: OAM_REMOTE_USERおよびREMOTE_USERを検索する
OAM_REMOTE_USERが優先される

URIマッピング

なし

なし

/*

一部のアプリケーションに対してフィルタを有効にすることはできません。SSO同期フィルタは、システム・フィルタです。このため、デプロイされているすべてのアプリケーションに対して有効になります(URIマッピングは/*)。

注意:

一部のアプリケーションに対してフィルタを有効にすることはできません。

次の手順に、SSO同期フィルタのプロパティと動作の変更に関するヒントを示します。

SSO同期フィルタのプロパティと動作を変更するには

1. フィルタの無効化: システム・プロパティsso.filter.enableをfalseに変更し(jvmに-Dとして渡す)、Oracle WebLogic Serverを再起動します。これにより、フィルタ・ステータスが切り替わります。

2. ユーザー識別ヘッダーと事前構成済同期フィルタ・トークンの不一致: システム・プロパティsso.filter.ssotokenを使用して、同期フィルタによって検索されるSSOトークンを上書きします。
たとえば、WebLogic Serverの起動スクリプト(-Dsso.filter.ssotoken=HEADERNAME)でWebLogic Server JVMに渡し、サーバーを再起動します。

Oracleサポート・サービスにお問合せの際は、「WebLogic管理コンソールでのデバッグの設定」の説明に従ってデバッグを設定するように求められる場合があります。

17.8 OAMプロバイダ・デプロイメントのトラブルシューティング・ヒント

この項には次のトピックが含まれます:

- IPv6の使用について

- Apacheブリッジの失敗: タイムアウト

- 認証済ユーザーがアクセスを拒否される

- ブラウザの「戻る」ボタンを押すとエラーが発生する

- OAMおよびOID認証プロバイダを追加した後に再起動できない

- ロード・バランシングされるWebゲートを持つクラスタのクライアント

- エラー401: アプリケーションにアクセスできません

- エラー403: アプリケーションにアクセスできません

- エラー404: リクエストURIに合致するものを見つけられませんでした

- フォーム・ログイン・ページのアクションURLでエラーが発生する

- Oracle WebLogic Serverの起動中にエラーが発生するか、失敗する

- JAAS制御フラグ

- 資格証明の送信時にログイン・フォームが繰り返し表示される: エラーなし

- ログアウトとセッション・タイムアウトの問題

- 見つかりません: リクエストされたURLまたはリソースが見つかりません

- Oracle WebLogic Serverの起動に失敗する

- Oracle ADF統合と証明書モード

関連項目:

「WebLogic管理コンソールでのデバッグの設定」

17.8.1 IPv6の使用について

Oracle Fusion MiddlewareとOracle Access Managerは、Internet Protocol Version 4 (IPv4)とInternet Protocol Version 6 (IPv6)をサポートしています。IPv6の特筆すべき機能は、Pv4 (32ビット)よりも大きいアドレス空間(128ビット)をサポートしていることです。これにより、Web上でアドレッシングできるコンピュータの数が飛躍的に増えます。

関連項目:

IPv6使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

17.8.2 Apacheブリッジの失敗: タイムアウト

Apacheブリッジが失敗する場合、接続できるバックエンド・サーバーが存在しないことを示すメッセージが表示されることがあります。この場合、接続はタイムアウトします。

Oracle WebLogic Serverが停止しているか、mod_weblogicに不正な値が設定されている可能性があります。

Apacheブリッジの失敗からリカバリするには

1. Oracle WebLogic Serverが使用可能であることを確認します。

2. WebゲートのWebサーバーのhttpd.confで、ホスト情報とポート情報が正しく指定されていることを確認します。例:

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>

17.8.3 認証済ユーザーがアクセスを拒否される

認証されたユーザーが、リクエストしたリソースへのアクセス権限を持っていない可能性があります。

ユーザー・ログインが決定的ではない場合や無効な場合、ユーザーは認証されますが、リスエストしたリソースに対して認可されたとは認識されません。この場合、問題を指摘する明示的なエラー・メッセージは表示されません。かわりに、再度ログインするよう求められます。

17.8.4 ブラウザの「戻る」ボタンを押すとエラーが発生する

認証に成功した後、ブラウザ・ウィンドウの「戻る」ボタンを押すと、access/oblix/apps/webgate/bin/webgate.soに対するエラーが表示されることがあります。

フォームベース認証を使用している場合、Oracle Access Managerにより、リクエストされたリソースに関する情報を保持するフォーム・ログインCookieが作成されます。認証に成功すると、Cookieの状態が変更されます。ユーザーが「戻る」ボタンをクリックすると、ログイン・フォームが表示されます。再ポストされると、フォーム・ログインCookieにはリダイレクトの詳細が含まれなくなります。

また、フォーム・ログインCookieと一緒にObSSOCookieも送信されます。ObSSOCookieは正しくチェックされます。フォーム・ログインCookieの状態が変更されているため、フォームベース認証は行われず、フォーム・アクションはリソースのリクエストとみなされます。

解決策

元のURLを使用して、リクエストを再試行してください。

17.8.5 OAMおよびOID認証プロバイダを追加した後に再起動できない

Oracle Access Managerの認証プロバイダ・フラグがREQUIREDに設定されている場合、またはOracle Access Manager認証プロバイダのみが使用可能な場合、このタスクに対する実行権限を持っている管理者グループにOracle WebLogic Serverを起動するLDAPユーザーが含まれるように、次の手順を実行します。デフォルトでは、Oracle WebLogic ServerのAdminロールに管理者グループが含まれています。

その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。

WebLogic Serverを再起動できるようにするには

1. 管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。

2. Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。

3. WebLogic管理コンソールで、「セキュリティ・レルム」→「myrealm」→「ロールとポリシー」→「グローバル・ロール」を選択します。

4. Adminロールの「構成の表示」を選択します。

5. グループを追加して「保存」をクリックします。

17.8.6 ロード・バランシングされるWebゲートを持つクラスタのクライアント

初期状態のOracle Access Managerでは、ロード・バランシングされるアクセス・ゲートはサポートされていません。かわりに、サード・パーティのロード・バランサを使用する必要があります。

WebGateAおよびWebGateBという2つのWebゲートがあるとします。OAMCfgToolを使用して、2つのWebゲートで共有されるプロファイルを作成できます。

関連項目:

「OAMCfgToolの概要」

Oracle Fusion Middlewareアプリケーションをインストール済の場合、OAMCfgToolはすでにインストールされています。この場合、手順1を省略します。

解決策:

1. Oracle Fusion Middlewareアプリケーションがない場合: Oracle Fusion Middlewareアプリケーションがインストールされていない場合には、OAMCfgToolを入手します。

1. Oracle Technology Networkにログインします:

http://www.oracle.com/technology/software/products/middleware/htdocs/111110_fmw.html

2. Access Managerのコア・コンポーネント(10.1.4.3.0)を使用してOAMCfgTool ZIPファイルを見つけます。

oamcfgtool<version>.zip

3. oamcfgtool.jarを抽出し、Webゲートをホスティングしているコンピュータにコピーします。

2. WebGateAのコンピュータにログインします(Webゲートがまだインストールされていない場合も含む)。

3. OAMCfgToolが含まれているファイル・システム・ディレクトリに移動し、次のようなコマンドを実行して、2つのWebゲートによって共有される1つのアクセス・ゲート・プロファイルを作成します。例:

java -jar oamcfgtool.jar mode=CREATE app_domain=SharedA_B
app_agent_password=<WebGate_password>
cookie_domain=<preferred_http_cookie_domain>
ldap_host=wxyz
ldap_port=6633
ldap_userdn=orcladmin
ldap_userpassword=<ldap_userpassword>
oam_aaa_host=abcd
oam_aaa_port=7789
oam_aaa_mode=cert
log_file=OAMCfg_date.log
log_level=INFO
output_ldif_file=<LDIF_filename>

4. このツールで指定した情報を確認します。たとえば、ステップ3のパラメータと値は次のとおりです。

Processed input parameters
Initialized Global Configuration
Successfully completed the Create operation.
Operation Summary:
Policy Domain  : SharedA_B
Host Identifier: SharedA_B_WD
Access Gate ID : SharedA_B_AG

注意:

- Webゲートがインストールされている場合は、ステップ5を実行してください。

- Webゲートがまだインストールされていない場合は、ステップ6を実行してください。

5. 出力LDIFの作成: LDIFをインポートし、その情報をディレクトリ・サーバーに書き込みます。該当しない場合は、この手順を省略します。

6. Webゲートがインストールされていない場合: WebGateAとWebGateBをインストールし、プロファイルの作成時に指定した値と同じ値(および、インストールの正常完了に必要なその他の値)を指定します。

7. Webゲートがインストールされている場合: OAMCfgToolのCreateコマンド出力を使用してOracle Access ManagerのconfigureWebGateツールを実行し、Webゲートを設定します。例:

1. 次の場所に移動します。
WebGate_install_dir\access\oblix\tools\configureWebGate

ここで、WebGate_install_dirは、Webゲートのインストール先ディレクトリです。

2. 次のコマンドを実行し、OAMCfgToolで指定した値とインストールの完了に必要なその他の値を使用して、Webゲートを構成します。例:

configureWebGate -i WebGate_install_dir -t WebGate SharedA_B_AG
-P WebGate_password
-m <open|simple|cert>
-h Access_Server_Host_Name
-p Access_Server_Port
-a Access_Server_ID
-r Access_Server_Pass_Phrase (must be the same as the WebGate_password)
-Z Access_Server_Retry count

関連項目:

『Oracle Access Managerアクセス管理ガイド』のアクセス・ゲートとWebゲートの構成に関する項

3. 前述の手順を繰り返して、WebGateBを構成します。

8. アクセス・システム・コンソールでのプロファイルの確認: 次の手順を実行して、Webゲート・プロファイルを表示または変更します。

1. マスター・アクセス管理者または委任アクセス管理者として、アクセス・システム・コンソールにログインします。例:

http://hostname:port/access/oblix

hostnameはWebサーバーをホストするコンピュータで、portはWebサーバー・インスタンスのHTTPポート番号です。/access/oblixは、アクセス・システム・コンソールに接続します。

2. 「アクセス・システム構成」をクリックし、「アクセス・ゲート構成」をクリックします。

3. 「すべて」ボタンをクリックしてすべてのプロファイルを検索し(または、リストから検索属性と条件を選択し)、「実行」をクリックします。

4. Webゲートの名前をクリックして、その詳細を表示します。

5. 「取消」をクリックしてこのページの変更内容を消去するか、「変更」をクリックして、『Oracle Access Managerアクセス管理ガイド』の説明に従って値を変更します。

9. ロード・バランサのホスト識別子に、両方のWebゲートのホスト名バリエーション(WebGateAおよびWebGateB)を追加します。

17.8.7 エラー401: アプリケーションにアクセスできません

次のようなエラー・メッセージが表示されます。

401 Authorization Required

これは通常、Oracle Access Manager認証プロバイダが正しく構成されていないことを意味します。正しい構成のリストについては、「Oracle Access Manager認証プロバイダのパラメータ・リスト」を参照してください。

17.8.8 エラー403: アプリケーションにアクセスできません

次のようなエラー・メッセージが表示されます。

403 Forbiden

これは通常、ポリシー・ドメインで認証後のアクションが正しく構成されていないことを意味します。ポリシー・ドメインの認証成功アクションで、(「戻り値」フィールドではなく)「戻り属性」フィールドにobmygroupsとuidが設定されていることを確認してください。

詳細は、「Oracle Access Manager認証プロバイダのポリシー・ドメインの構成」を参照してください。

17.8.9 エラー404: リクエストURIに合致するものを見つけられませんでした

このエラーは通常、サーバーがリクエストURIに合致するものを見つけられなかったことを示します。このメッセージは、Oracle WebLogic Serverがリソースを見つけられないことを通知します。

状況が一時的であるか、永続的であるかどうかは示されません。

- サーバーが一時的または永続的にクライアントに情報を提供できない場合、ステータス・コード403 (Forbidden)が使用されることがあります。

- 内部的に構成できるなんらかのメカニズムによって、古いリソースが永続的に使用不可で、転送アドレスが存在しないことを通知できる場合は、410 (Gone)ステータス・コードが使用されます。

エラー404からリカバリするには

リソースがOracle WebLogic Serverにデプロイされていることを確認します。たとえば、パターンが/private1/Helloである場合、ルートがprivate1のサーバー上でHelloにアクセスできるかどうかを確認します。

17.8.10 フォーム・ログイン・ページのアクションURLでエラーが発生する

この問題は、Oracle Access Managerでフォーム認証スキームが適切に構成されていない場合に発生します。ただし、OAMCfgToolを使用してポリシー・ドメインを設定する場合、この問題は発生しません。例:

次のような兆候があります。

- ログイン・フォームの「ユーザー名」フィールドと「パスワード」フィールドが、フォーム認証スキームの詳細と合致している必要があります。

- フォーム認証スキームで、credential_mappingフィルタが正しく指定されている必要があります。

- ログイン・フォームのアクションURLがポリシーによって保護されている必要があります。

- ログイン・フォームのアクションURLが、認証スキームのチャレンジ・パラメータに指定されたアクション値と合致している必要があります。

17.8.11 Oracle WebLogic Serverの起動中にエラーが発生するか、失敗する

WebLogic ServerユーザーがOracle Access Managerの管理者グループに含まれていない場合、Oracle WebLogic Serverが再起動し、認証プロバイダの初期化に失敗する可能性があります。この場合、$DOMAIN_HOME/servers/AdminServer/logs/AdminServer.logのAdminServer.logに、次のいずれかのメッセージが表示されます。

)<Failed ---- FatalError:InvalidSchemeMapping
...
Authentication Failed.
...
Login failed.
...

解決策

1. 実装で、Oracleが提供するデフォルト・ログイン・フォームが使用されていることを確認します。

2. Oracle Access Managerアイデンティティ・システムでAdministratorsという名前のグループを作成し、Oracle WebLogic Serverユーザーを含めます。

関連項目:

「Oracle Access Manager IDおよび共通管理ガイド」

3. Oracle Access Managerアイデンティティ・システム内で定義されたAdministratorsグループに属するユーザーの資格証明を使用して、Oracle WebLogic Serverにログインします。

4. Oracle WebLogic Serverを再起動します。

17.8.12 JAAS制御フラグ

このフラグをREQUIREDに設定し、他のパラメータを不適切な値に設定した場合、サーバーは起動しません。

この問題を回避するには、このパラメータ値をOPTIONALに設定して、Oracle Access Manager認証プロバイダが適切に構成されていることを確認します。この方法で適切に動作することを確認した後にのみ、制御フラグをREQUIREDにリセットしてください。

詳細は、「WebLogicドメインでの認証プロバイダの構成」を参照してください。

17.8.13 資格証明の送信時にログイン・フォームが繰り返し表示される: エラーなし

この問題は通常、ユーザー名またはパスワードが正しくないことを示しています。エラーは表示されません。

正しいユーザー名とパスワードが入力されていることを確認してください。ユーザーのログイン名は、フォーム・ログイン認証スキームで構成された属性の値である必要があります。たとえば、チャレンジ・パラメータcreds: useridのようになります。

17.8.14 ログアウトとセッション・タイムアウトの問題

ユーザーがログアウトした場合、またはユーザーのセッションがタイムアウトした場合は、ユーザーは再認証を要求されます。ただし、次のことが発生する場合があります。

- ログアウト: ログアウトした後、ユーザーが同じブラウザ・ウィンドウでアプリケーションにアクセスしようとすると、再認証なしでアプリケーションにアクセスできます。

- セッション・タイムアウト: ユーザーがセッション・タイムアウトした後、再認証が要求されます。ただし、ユーザーが別のユーザーIDを入力した場合に、前のユーザーと同じ権限が付与されます。

ObSSOCookieがまだ存在しています。ObSSOCookieをクリアするには、いくつかの構成をアプリケーション・レベルで行う必要があります。適切に動作させるには、WebLogicアプリケーションのセッション・タイムアウト値とWebゲートのセッション・タイムアウト値を合致させる必要があります。

WebLogicアプリケーション・コンソールでIDアサーション・プロバイダを設定している場合、IDアサーション・プロバイダを使用するWebアプリケーションのauth-methodがCLIENT-CERTに設定されている必要があります。詳細は、「Oracle Access Manager 10gでのSSO用のOAM IDアサーションの構成」を参照してください。

17.8.15 見つかりません: リクエストされたURLまたはリソースが見つかりません

リクエストされたURLまたはリソースがこのサーバーに見つからなかったことを示すメッセージが表示された場合、リバース・プロキシWebサーバーがリクエストをOracle WebLogic Serverに転送していない可能性があります。

リバース・プロキシがリクエストをOracle WebLogic Serverに転送していることを確認するには

1. リバース・プロキシWebゲートのWebサーバーで、httpd.confファイルを検索します。例:

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

2. Oracle WebLogic Serverの正しいホストとポートにリクエストが転送されるように、正しく設定されていることを確認します。

#httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost <host>
WebLogicPort yourWlsPortNumber
</IfModule>

<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>

17.8.16 Oracle WebLogic Serverの起動に失敗する

Oracle WebLogic Serverの起動に失敗する場合、次の操作を実行できます。

1. Oracle Access Manager認証プロバイダが、Oracle WebLogic Serverレルムに構成されている唯一のプロバイダであるかどうかを確認します。そうである場合は、ステップ2に進みます。

2. Oracle Access Manager認証プロバイダが正しく構成されていることを確認し、必要に応じて変更します。

3. Oracle Access Manager認証プロバイダの制御フラグがREQUIREDに設定されているかどうかを確認します。設定されている場合は、次の手順を実行します。

1. 管理者グループが存在しない場合、ディレクトリ・サーバーでこのグループ(または、起動権限を付与する必要があるその他のグループ)を作成します。

注意:

その他のグループにアクセス権限を付与するには、そのグループをディレクトリ・サーバーで作成してから、グループ内にWebLogic Serverの起動ユーザーを追加する必要があります。

2. Oracle WebLogic Serverを起動するLDAPユーザーが、管理者やその他のグループに追加されていることを確認します。

3. WebLogic管理コンソールで、「セキュリティ・レルム」→「Your Realm」→「ロールとポリシー」→「グローバル・ロール」を選択します。

4. 管理者(またはその他の)ロールの「条件の表示」を選択します。

5. グループを追加して「保存」をクリックします。

17.8.17 Oracle ADF統合と証明書モード

問題

Microsoft Officeドキュメント(.xls、.docなど)をダウンロードできる特定のURLにアクセスしたときに、Webゲートのキャッシュ・ディレクティブの構成が特定のブラウザのバージョン(特にInternet Explorer v7)に対応していない可能性があります。

たとえば、Oracle Access Managerの証明書ベースの環境に、Oracle ADFアプリケーションと一緒にExcelワークブックがデプロイされているとします。

ADFDiコンポーネントが2つのURLにアクセスする際に、2番目のURLへのアクセスを先に試行すると、ADFDiのクライアント側のコードに関係なく失敗します。Oracle Access Manager WebゲートからSSL対応エンドポイントへのリダイレクトを処理できずに失敗し、次のスタック・トレースが生成されます。

WebException: The request was aborted: Could not create SSL/TLS secure channel

ワークブックにアクセスしようとすると、次のメッセージが表示されます。

Microsoft Office Excel cannot access the file

次の原因が考えられます。

- ファイル名またはパスが存在しません。

- ファイルが別のプログラムによって使用されています。

- 保存しようとしているワークブックと現在開いてるワークブックの名前が同じです。

ただし、ワークブックのURLをInternet Explorer v7のアドレス・バーに明示的に貼り付けたときにこのメッセージが表示された場合は、Webゲートのデフォルト・キャッシュ・ディレクティブが原因である可能性があります。

Webゲートには、デフォルト・キャッシュ・ディレクティブ(Pragma=no-cacheおよびCacheControl=no-cache)があります。これらは、Internet Explorer v7で.xlsワークブックのURLをブラウザのアドレス・バーに直接貼り付けた場合に問題を引き起こします。

解決策

ワークブックのURLをInternet Explorer v7のアドレス・バーに明示的に貼り付けたときにこのメッセージが表示された場合は、アクセス・システム・コンソールのWebゲート構成の各ページからキャッシュ・ディレクティブを削除することをお薦めします。

各Webゲート構成からキャッシュ・ディレクティブを削除するには

1. アクセス・システム・コンソールで、「アクセス・システム構成」タブをクリックします。

2. 「アクセス・ゲート構成」をクリックし、検索ページの「実行」をクリックした後、該当するアクセス・ゲート構成ページへのリンクをクリックします。

3. 「アクセス・ゲートの詳細」ページで、「変更」をクリックします。

4. 「アクセス・ゲートの変更」ページで「Webサーバー・クライアント」ラベルを検索し、次のフィールドをクリアします。

- CachePragmaHeader

- CacheControlHeader

5. 「保存」をクリックします。

17.8.18 Protected_JSessionId_Policyについて

OAMポリシーは、渡されたURIに基づいて評価されます。以前のリリースでは*;jsessionid*を保護するポリシーがありませんでした。アプリケーション・リソースURLへのアクセス時にJSESSIONID Cookieが見つからない場合、WebLogic Serverは、JSESSIONIDをURLの一部として含めてURLの書込みを行います。対象のURLが保護されているときは、Oracle Access ManagerとOSSO Webエージェントでは書き込みなおされたURLのマッチングが困難になる場合があります。

このリリースでは、コンテキスト・ルートの下位のすべてのURIに対してパターン「*;jessionid=*」を使用するポリシーが新たに提供されています。このため、コンテキスト・ルートにあり、「;jsessionid=string」が追加されたすべてのURIが保護されていると見なされます。

/context-root自体をリソースとしてリストする必要があります。URLパターンは、*;jsessionid=*です。デフォルトの認証ルールは、保護された認証スキームです。また、デフォルトの認可条件式も使用されます。ポリシーの順序付けでは、このポリシーを第1にする必要があります。

/test/protectedUriという名前の保護されたリソースと/testという名前の公開リソースがあるとします。パターン*jessionid;*で公開ポリシーを作成し、このポリシーをこの両リソースに適用すると、公開ポリシーが公開リソースより優先されます。

- /test;jessionid=blahがリクエストされた場合、OAMではまず「/test;jessionid=blah」のデフォルト・ルールの有無がチェックされます。このルールがない場合は次に「/」のルールの有無がチェックされます。このルールもない場合、「/test;jessionid=blah」は保護されていないと見なされます。

- 「/test/protectedUri;jessionid=blah」がリクエストされると、OAMはこれを保護するデフォルトのルールの有無をチェックします。このルールがない場合は、「/test」のルールの有無をチェックします。リソース・リストに「/test」が存在する場合は、さらに適用されるポリシーが判定されます。この例の場合は、jessionidポリシーが適用され、リクエストが保護されていると見なされます。

18 OracleAS SSO 10gを使用したシングル・サインオンの構成

この章では、OracleAS SSO (OSSO) 10gを使用してSSOを実装する方法について説明します。内容は次のとおりです。

- OracleAS 10g Single Sign-On (OSSO)ソリューションのデプロイ

- ユーザーとSSOセッションの同期: SSO同期フィルタ

- OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング

18.1 OracleAS 10g Single Sign-On (OSSO)ソリューションのデプロイ

OracleAS Single Sign-Onソリューションは、Webアプリケーションへのシングル・サインオン・アクセスを提供します。Oracle Internet Directoryは、LDAPベースのリポジトリです。

このソリューションは、Oracle WebLogic Serverにデプロイされていて、シングル・サインオンがまだ実装されていないアプリケーションを対象としています。OSSOソリューションの構成に関する要件と手順については、「OSSO IDアサーション・プロバイダの新規ユーザー」を参照してください。

注意:

「Oracle Access Manager 11g SSOの概要」で説明されているように、Oracle Access Manager 11gを使用することをお薦めします。

JPSログイン・モジュールを介してOracleAS Single Sign-Onソリューションを使用していて、OSSOにリクエストを動的にリダイレクトするアプリケーションは、新しいOSSOソリューションの影響を受けることはありません。この場合、この項の説明に従って新しいOSSO認証プロバイダを構成する必要はありません。

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

- OSSO IDアサーション・プロバイダの使用

- OSSO IDアサーション・プロバイダの新規ユーザー

- OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング

18.1.1 OSSO IDアサーション・プロバイダの使用

この項では、OracleAS Single Sign-On IDアサーション・プロバイダの実装時に想定される動作について説明します。この項の内容は次のとおりです。

- Oracle WebLogicセキュリティ・フレームワーク

- OSSO IDアサーション・プロバイダの処理

- OSSO IDアサーション・プロバイダによるヘッダーの使用

18.1.1.1 Oracle WebLogicセキュリティ・フレームワーク

図18-1は、OSSO IDアサーション・プロバイダを含む、Oracle WebLogicセキュリティ・フレームワーク内のコンポーネントの配置を示しています。詳細は、図の後に説明します。

図18-1 Oracle WebLogicセキュリティ・フレームワーク内のOSSOコンポーネントの配置

図18-1「Oracle WebLogicセキュリティ・フレームワーク内のOSSOコンポーネントの配置」の説明

図の最上部に、Oracle HTTP Serverがインストールされています。このインストールにはmod_weblogicとmod_ossoが含まれています。これらは、アイデンティティ・トークンをプロバイダとOracle WebLogic Serverに渡すために必要になります。Oracle WebLogic Serverには、パートナ・アプリケーションとIDアサーション・プロバイダが含まれています。図の右側にある10g OracleAS Single Sign-Onサーバー(OSSO Server)は、ディレクトリ・サーバーおよびOracle HTTP Serverと直接通信します。

注意:

説明を簡潔にするために、この章では、Apache用WebLogic Serverプラグインの汎用名(mod_weblogic)を使用します。Oracle HTTP Serverの10gと11gでは、このプラグインが次の名前になります。

- Oracle HTTP Server 10g: mod_wl(実際のバイナリ名はmod_wl_20.so)

- Oracle HTTP Server 11g: mod_wl_ohs(実際のバイナリ名はmod_wl_ohs.so)

18.1.1.2 OSSO IDアサーション・プロバイダの処理

図18-2は、IDアサーション・プロバイダでOSSOを実装した場合に発生する処理を示しています。詳細は、図の後に説明します。

図18-2 OSSO IDアサーション・プロバイダの処理

図18-2「OSSO IDアサーション・プロバイダの処理」の説明

保護されたリソースに対するリクエストが初めて中間層のWebサーバーに到達すると、そのリクエストは、ユーザー資格証明を要求する10g OracleAS Single Sign-Onサーバーにリダイレクトされます。証明書ベースの認証の場合は、ログイン・ページは表示されません。ユーザーが正常に認証されると、そのユーザーによるすべての後続リクエストでは、JAASサブジェクトの移入前に、OSSO IDアサーション・プロバイダがユーザー・アイデンティティをアサートするだけで済みます。サブジェクトは、ダウンストリーム・アプリケーションによって使用されます。

たとえば、フロントエンドにOracle HTTP ServerがデプロイされているOracle WebLogic Serverにアプリケーションが存在するとします。このアプリケーションは、mod_osso構成のリソース・マッピングを使用して保護されます。これについては、次のプロセス概要で説明します。

プロセス概要: OSSO IDアサーション・プロバイダ

1. ユーザーが保護されたアプリケーションをリクエストします。

2. Oracle HTTP Serverはリクエストをインターセプトし、mod_ossoを使用してリクエストを処理して、既存の有効なOracle HTTP Server Cookieがあるかどうかをチェックします。

3. 有効なOracle HTTP Server Cookieがない場合、mod_ossoはOracleAS SSO Serverにリダイレクトし、SSO Serverは認証中にディレクトリと通信します。

4. 正常に認証されると、mod_ossoはOSSOサーバーによって移入された暗号化済のユーザー・アイデンティティを復号化し、ヘッダーにユーザー属性を設定します。

5. mod_weblogicが後続処理を完了し、リクエストをOracle WebLogic Serverにリダイレクトします。

6. WebLogicセキュリティ・レイヤーにより、設定と指定された順序に従ってプロバイダが呼び出されます。たとえば、セキュリティ・レイヤーによって次のものが呼び出されます。

- 取得したトークンに基づいてアイデンティティ・アサーションを行うIDアサーション・プロバイダ。

- サブジェクトに必要なプリンシパルを移入するOracle Internet Directory認証プロバイダ(OID認証プロバイダ)。

関連項目:

「OSSO IDアサーション・プロバイダによるヘッダーの使用」

7. Oracle HTTP Serverを介してレスポンスがユーザーに送信され、アプリケーションへのアクセスが許可されます。

18.1.1.3 OSSO IDアサーション・プロバイダによるヘッダーの使用

この項では、Oracle HTTP Serverによって送信されるヘッダーとヘッダーに設定されるトークン、およびOSSO IDアサーション・プロバイダが使用するヘッダーについて説明します。アプリケーションでJAASサブジェクトを使用する必要がある場合は、OSSO IDアサーション・プロバイダを構成してください。

表 18-1は、Oracle HTTP Serverによって設定されるヘッダー(mod_ossoおよびmod_weblogic)のリストを示しています。アプリケーション・ロジックで、ユーザー情報の識別にJAASサブジェクトを使用するアプリケーションは、OSSO IDアサーション・プロバイダを使用するよう構成されている必要があります。OSSO IDアサーション・プロバイダは、表内の太字で示されているOracleAS SSOトークン・タイプ(Proxy-Remote-User)を使用します。OSSO IDアサーション・プロバイダはProxy-Remote-Userヘッダーを検索し、ユーザーのアイデンティティをアサートします。その後、OID認証プロバイダがJAASサブジェクトを移入します。

表 18-1 Oracle HTTP Serverによって送信されるヘッダー

属性

サンプル値

説明

Cookie

OHS-Stads42.us.oracle.com:7777=.......

Cookie

Osso-User-Guid

4F4E3D2BF4BFE250E040548CE9816D7E

認証されたユーザーのGUID

Osso-User-Dn

cn=orcladmin,cn=users, dc=us,dc=oracle,dc=com

認証されたユーザーのDN

Osso-Subscriber

DEFAULT COMPANY

サブスクライバ名

Osso-Subscriber-Dn

dc=us,dc=oracle,dc=com

サブスクライバのベースDN

Osso-Subscriber-Guid

4F4E3D2BF410E250E040548CE9816D7E

サブスクライバのGUID

Proxy-Remote-User

ORCLADMIN

認証されたユーザー

Proxy-Auth-Type

Basic SSO

認証タイプ

ユーザー情報の識別にJAASサブジェクトを必要としないアプリケーションは、request.getHeader() APIを使用してヘッダーを直接読み取ることができます。このようなアプリケーションは、必要なヘッダーを自由に読み取ることができます。ユーザー情報を含むヘッダーは、Osso-User-Dn、Osso-User-GuidおよびProxy-Remote-Userです。

18.1.2 OSSO IDアサーション・プロバイダの新規ユーザー

新しいOracleAS Single Sign-Onソリューションでは、OSSO IDアサーション・プロバイダが提供されています。これは、Oracle WebLogic Serverで使用可能な2つの新しい認証プロバイダの1つです。

アプリケーションでOSSOソリューションを使用するには、次のタスクで説明されているコンポーネントが必要です。

注意:

コンポーネントがすでにインストールおよび設定されている場合、新しいコンポーネントは必要ありません。デプロイメントに該当しない手順は省略できます。

タスクの概要: OSSO IDアサーション・プロバイダのデプロイおよび構成

1. 次のコンポーネントをインストールします。

1. OracleAS Single Sign-On Server 10g (10g OSSO Server)

関連項目:

Oracle Technology NetworkにあるOracle Application Serverのインストレーション・ガイド(http://www.oracle.com/technology/documentation/oim1014.html)

2. 10g OSSO Serverで使用するように構成されたOracle Internet Directory。ディレクトリ・サーバーがデプロイメント用に調整されていることを確認してください。

関連項目:

次のリリース11g (11.1.1.1.0)のマニュアル

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

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

3. 次のWebサーバーのいずれか1つ(Apache 2に基づく)。

- Oracle WebLogic ServerのフロントエンドとしてのOracle HTTP Server 11g。このインストールには、mod_ossoとmod_weblogicが含まれています。

- リリース10.1.3のOracle HTTP ServerのCompanion CDに含まれているOHS 10g。これには、mod_ossoが含まれています。ただし、mod_weblogicを追加する必要があります。

関連項目:

次のリリース11g (11.1.1.1.0)のマニュアル

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』

- 『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』

4. Oracle WebLogic Server 10.3.1以降

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverインストレーション・スタート・ガイド』

5. Oracle Identity Management、Oracle SOA Suite、Oracle WebCenterなどのOracle Fusion Middleware製品が必要です。該当する製品の次のパスに、Oracle WebLogic ServerによるOSSOのために必要なプロバイダが含まれています。

ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar

関連項目:

- 『Oracle Fusion Middleware Oracle Identity Managementインストレーション・ガイド』

- 『Oracle Fusion Middleware Oracle SOA Suiteインストレーション・ガイド』

- 『Oracle Fusion Middleware Oracle WebCenterインストレーション・ガイド』

2. 「mod_weblogicの構成」の説明に従って、Oracle WebLogic Serverにリクエストを転送するようにmod_weblogicを構成します。

3. 「OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録」の説明に従って、モジュールmod_ossoをパートナ・アプリケーションとして10g SSO Serverに登録します。

4. 「Webリソースを保護するためのmod_ossoの構成」の説明に従って、mod_ossoを構成します。

5. 「OSSO用WebLogicドメインへのプロバイダの追加」の説明に従って、OSSO IDアサーション・プロバイダを適切なドメインに追加します。

6. 「Oracle WebLogic Serverとその他のエンティティの間の信頼の確立」の説明に従って、接続フィルタを構成します。

7. 「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明に従って、アプリケーションによるソリューションの使用を構成します。

8. 「OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング」を参照して、OSSO IDアサーション・プロバイダの実装に関する問題を特定して解決します。

18.1.2.1 mod_weblogicの構成

Oracle HTTP Serverのhttpd.confファイルを直接編集するか、別のファイルにmod_weblogic構成を追加して、そのファイルをhttpd.confに含めることができます。

次に、2つの異なるWebサーバー・リリース向けの手順について説明します。デプロイメントに応じて、必要な手順を実行してください。

- OHS 11gにはmod_wl_ohs.soが含まれています。この場合、手順1を省略します。

- OHS 10gには、mod_weblogic (mod_wl_.so)が含まれていません。Oracle HTTP Server 10gがインストールされている場合、ステップ1から開始して、構成を行う前に、mod_wl_20.soをコピーしてください。

注意:

Oracle HTTP Serverの10gと11gでは、このプラグインが次の名前になります。

- Oracle HTTP Server 10g: mod_wl(実際のバイナリ名はmod_wl_20.so)

- Oracle HTTP Server 11g: mod_wl_ohs(実際のバイナリ名はmod_wl_ohs.so)

mod_weblogicをインストールして構成するには

1. Oracle HTTP Server 10.1.3: 次の例のように、mod_wl_20.soをOracle HTTP Serverモジュール・ディレクトリにコピーします。
コピー元: WL_HOME/wlserver_10.0/server/plugin/linux/i686

コピー先: ORACLE_HOME/ohs/modules

2. Oracle HTTP Serverのhttpd.confファイルを見つけます。例:
Oracle HTTP Server 10.1.3:

ORACLE_HOME/ohs/conf/httpd.conf

Oracle HTTP Server 11g:

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

3. 適切な構成ファイルを含めるか、構成自体を直接含めて、mod_weblogic構成がhttpd.confに含まれていることを確認します。たとえば、Oracle HTTP Server 10gの場合は次のようにします。

LoadModule weblogic_module ${ORACLE_HOME}/ohs/modules/mod_wl_20.so
<IfModule mod_weblogic.c>
WebLogicHost yourHost.yourDomain.com
WebLogicPort yourWlsPortNumber
</IfModule>

<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>

18.1.2.2 OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録

mod_ossoモジュールは、OracleASアプリケーションへの認証を提供するOracle HTTP Serverモジュールです。このモジュールはOracle HTTP Server上に存在します。これにより、ユーザーがOracleAS Single Sign-Onサーバーにログインした後、OracleAS Single Sign-Onによって保護されているアプリケーションが、ユーザー名とパスワードのかわりにHTTPヘッダーを受け入れるようになります。これらのヘッダーの値は、mod_osso Cookieに格納されます。

mod_ossoモジュールは着信リクエストを調べて、リクエストされたリソースが保護されているかどうかを特定することにより、Oracle HTTP Serverに対するシングル・サインオンを可能にします。保護されている場合、Oracle HTTP Server Cookieが取得されます。

状況によっては、10.1.4のOracle Identity Managerのシングル・サインオン登録ツール(ssoreg.shまたはssoreg.bat)を使用して、Oracle HTTP Serverのmod_ossoを登録する必要があります。表18-2は、このために使用するパラメータと値の概要を示しています。登録ツールを実行すると、osso.confファイル内のmod_osso登録レコードが更新されます。このツールを実行するたびに、このファイルが生成されます。

表18-2 Oracle HTTP Serverのmod_ossoを登録するためのssoregパラメータ

パラメータ

説明

-oracle_home_path

10.1.4 SSO Oracle_Homeのパス。

-site_name

対象となる任意のサイト名。

-config_mod_osso

TRUE。TRUEに設定すると、このパラメータは、登録中のアプリケーションがmod_ossoであることを示します。osso.confを生成するには、config_mod_ossoを含める必要があります。

-mod_osso_url

フロンドエンドOracle HTTP Serverのホスト:ポートのURL。これは、パートナ・アプリケーションへのアクセスに使用されるURLです。値は、URL形式(http://oracle_http_host.domain:port)で指定する必要があります。

-update_mode

オプション。デフォルト値のCREATEでは、新しいレコードが生成されます。

-remote_midtier

登録するmod_ossoパートナ・アプリケーションがリモート中間層にあることを指定します。このオプションは、構成するmod_ossoパートナ・アプリケーションが別のORACLE_HOMEに存在し、OracleAS Single Sign-Onサーバーが現在のORACLE_HOMEでローカルに実行されている場合にのみ使用してください。

-config_file

osso.confが生成されるパス。

[-admin_info

オプション。mod_osso管理者のユーザー名。このパラメータを省略すると、「パートナ・アプリケーションの編集」ページの「管理者情報」フィールドが空白になります。

admin_id

オプション。電子メール・アドレスや管理者などに関する追加情報。このパラメータを省略すると、「パートナ・アプリケーションの編集」ページの「管理者の電子メール」フィールドが空白になります。

<VirtualHost ...>

ホスト名。オプション。このパラメータは、Oracle HTTP仮想ホストをシングル・サインオン・サーバーに登録している場合にのみ指定してください。仮想ホストを登録していない場合、このパラメータは省略します。

HTTP仮想ホストを作成している場合、httpd.confファイルを使用して、保護された各URLに対するディレクティブを入力します。

関連項目:

Oracle Technology Networkにある(http://www.oracle.com/technology/documentation/oim1014.html)次の文書

- Oracle Application Server Single Sign-On管理者ガイド 10g (10.1.4.0.1)原典部品番号: B15988-01

- Oracle Identity Managementアプリケーション開発者ガイド10g (10.1.4.0.1) 原典部品番号: B15997-01

次の手順には、mod_ossoを登録するためのサンプル・コマンドが記載されています。その値は、使用する環境によって異なります。

mod_ossoを登録するには

1. 次の10.1.4のOracle Identity Managerディレクトリのパスに移動します。

ORACLE_HOME/sso/bin/ssoreg

2. 環境に応じて、次のパラメータと値を指定してssoregを実行します。たとえば、Unixでは、次のようになります。

./ssoreg.sh -oracle_home_path \OraHome -site_name wls_server
-config_mod_osso TRUE -mod_osso_url http://oracle_http_host.domain:7788
-update_mode CREATE -remote_midtier -config_file \tmp\osso.conf

3. 必要なOracle HTTP Serverのモジュールmod_ossoが登録されていることを確認します。

4. 「Webリソースを保護するためのmod_ossoの構成」に進みます。

18.1.2.3 Webリソースを保護するためのmod_ossoの構成

mod_ossoは、リクエストしたURLが保護されるよう構成されている場合にのみ、ユーザーをシングル・サインオン・サーバーにリダイレクトします。URLは、静的または動的に保護できます。静的ディレクティブは、ユーザー操作からmod_ossoに制御を渡すことでアプリケーションを保護します。動的ディレクティブは、アプリケーションを保護するだけでなく、アプリケーションによるユーザー・アクセスの規制も可能にします。

詳細は、次を参照してください:

- 静的ディレクティブによるmod_ossoの構成

- URLとログアウトの動的保護(mod_ossoなし)

18.1.2.3.1 静的ディレクティブによるmod_ossoの構成

mod_osso.confファイルにディレクティブを適用することにより、mod_ossoを使用してURLを静的に保護できます。リクエストが適切にインターセプトされるように、mod_ossoを構成する必要があります。さらに、保護されるURIの場所、タイムアウト時間および認証方式を指定します。httpd.confファイルにおけるweblogic_module文のロード箇所より前に、mod_osso.confのinclude文を配置することをお薦めします。

次の手順では、mod_osso.confファイルを編集してmod_ossoを構成する方法について説明します。この手順には、2つの異なるリリース向けの詳細が示されています。OHSデプロイメントの指示に従ってください。

- Oracle HTTP Server 11g: 手順2と手順4のAuthType Ossoが必要です。手順5のパス名は、Oracle HTTP Server 11gでは異なります。

- Oracle HTTP Server 10g: 手順3と手順4のAuthType Basicが必要です。手順5のパス名は、Oracle HTTP Server 10gでは異なります。

Webリソースを保護するためにmod_ossoを構成するには

1. osso.confを生成場所から次の場所にコピーします。
コピー元: /tmp/osso.conf

コピー先:

ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf

2. Oracle HTTP Server 11g: 編集するために、mod_osso.confを無効なディレクトリからmoduleconfディレクトリにコピーします。例:
コピー元:

ORACLE_INSTANCE/config/OHS/<ohs_name>/disabled/mod_osso.conf

コピー先:

ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

3. Oracle HTTP Server 10g: 編集するために、mod_osso.confを見つけます。例:

ORACLE_HOME/ohs/conf/mod_osso.conf

4. mod_osso.confを編集して、デプロイメントに応じた値を使用して次の情報を追加します。ここでは、例としてOracle HTTP Serverを使用します(10gの場合はパスが異なります)。

LoadModule osso_module ${ORACLE_HOME}/ohs/modules/mod_osso.so
<IfModule mod_osso.c>

OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf

#Location is the URI you want to protect
<Location />
require valid-user
#OHS 11g AuthType Osso
#OHS 10g AuthType Basic
AuthType Osso

</Location>

</IfModule>

5. 編集するために、httpd.confファイルを見つけます。例:
Oracle HTTP Server 10.1.3:

ORACLE_HOME/ohs/config/httpd.conf

Oracle HTTP Server 11g:

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

6. httpd.confで、環境に応じたmod_osso.confファイルのパスが含まれていることを確認します。例:

include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

7. Oracle HTTP Serverを再起動します。

ヒント:

リクエストのインターセプトが正常に機能しない場合、httpd.conf内でLoadModule weblogic_module文の前にmod_osso.confのinclude文を配置してください。

8. 「OSSO用WebLogicドメインへのプロバイダの追加」に進みます。

18.1.2.3.2 URLとログアウトの動的保護(mod_ossoなし)

動的ディレクティブを使用するアプリケーションでは、mod_ossoによる保護が1つ以上の動的ディレクティブとして直接アプリケーションに書き込まれるため、mod_osso.confへの入力は必要ありません。

動的ディレクティブは、特殊なエラー・コードを含むHTTPレスポンス・ヘッダーです。これにより、アプリケーションは複雑なシングル・サインオン・プロトコルを実装することなく、シングル・サインオン・システムから詳細な機能をリクエストできます。アプリケーションからシンプルなHTTPレスポンスの一部としてディレクティブを受け取ると、mod_ossoは適切なシングル・サインオン・プロトコル・メッセージを作成し、それをシングル・サインオン・サーバーに通信します。

OracleASでは、JavaサーブレットおよびJSP向けの動的ディレクティブがサポートされています。現時点では、PL/SQLアプリケーション向けの動的ディレクティブはサポートされていません。次のJSPは、このようなディレクティブの組込み方法を示しています。対応する静的アプリケーションと同様、これらの動的サンプル・アプリケーションではユーザー情報が生成されます。

- 例18-1「動的ディレクティブによるSSO認証」

- 例18-2「動的ディレクティブによるSSOログアウト」

注意:

動的ディレクティブを追加したら、Oracle HTTP Serverを再起動して「OSSO用WebLogicドメインへのプロバイダの追加」に進んでください。

例18-1 動的ディレクティブによるSSO認証

home.jspには、request.getUserPrincipal().getName()メソッドを使用してセッション内のユーザーをチェックするssodynauth.jspが含まれています。ユーザーが存在しない場合、動的ディレクティブ499(簡易認証のリクエスト)が発行されます。重要な行は太字で示されています。

//home.jsp

<%@ include file="ssodynauth.jsp" %>
<%
//page content goes here
%>

//ssodynauth.jsp

<%
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Pragma", "no-cache");
response.setHeader("Expires", "0");
%>
<%
// Check for user
String ssoUser = null;
try
(
//ssoUser = request.getRemoteUser();
ssoUser = request.getUserPrincipal( ).getName( );
ssoUser = ssoUser.trim( );
}
catch(Exception e)
{
ssoUser = null;
}

// If user is not authenticated then generate
// dynamic directive for authentication
if((ssoUser == null) || (ssoUser.length() < 1))
{
response.sendError(499, "Oracle SSO");
return;
}%>

関連項目:

Oracle Technology NetworkのOracle Identity Managementアプリケーション開発者ガイド 10g (10.1.4.0.1) 原典部品番号: B15997-01 (http://www.oracle.com/technology/software/products/ias/htdocs/101401.html)

例18-2 動的ディレクティブによるSSOログアウト

グローバル・ログアウト(シングル・ログアウトとも呼ばれます)を実現するには、アプリケーションによってセッションが無効化された後にOSSOログアウトがコールされる必要があります。logout.jspにより、動的ディレクティブ470 (OSSOログアウトのリクエスト)が発行されます。ログアウト後の戻りURLを指定するために、アプリケーションによってosso-return-logoutが設定されます。

動的ディレクティブによるSSOログアウトの重要な行は、次の例で太字で示されています。11gでは、SSOFilterによってセッション同期が処理されます。

//logout.jsp
<%@page session="false"%>
<%
response.setHeader("Osso-Return-Url", "http://my.oracle.com/");
HttpSession session =  null;
session = request.getSession();
if (null != session )
{
// necessary for achieving SLO
session.invalidate();
}
response.sendError(470, "Oracle SSO");
%>

関連項目:

- 「ユーザーとSSOセッションの同期: SSO同期フィルタ」

- Oracle Technology NetworkのOracle Identity Managementアプリケーション開発者ガイド 10g (10.1.4.0.1) 原典部品番号: B15997-01 (http://www.oracle.com/technology/software/products/ias/htdocs/101401.html)

注意:

動的ディレクティブを追加したら、Oracle HTTP Serverを再起動して「OSSO用WebLogicドメインへのプロバイダの追加」に進んでください。

18.1.2.4 OSSO用WebLogicドメインへのプロバイダの追加

OSSO IDアサーション・プロバイダをWebLogicドメインに追加する必要があります。OSSO IDアサーション・プロバイダに加えて、次の認証プロバイダをお薦めします。

- OSSO IDアサーション・プロバイダ

- デフォルトの認証プロバイダ

- OID認証プロバイダ

関連項目:

「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

これらのプロバイダは、Oracle WebLogic管理コンソールまたはOracle WebLogic Scripting Tool (WLST)コマンドライン・ツールを使用して追加できます。

関連項目:

- 「Oracle WebLogic Serverの認証プロバイダとIDアサーション・プロバイダについて」

- 『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』

- 『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』

次の手順では、Oracle WebLogic管理コンソールを使用して認証プロバイダを追加する方法を示します。開始する前に、次の条件に注意してください。

ステップ10: アプリケーションでOracle Internet Directoryユーザーと大/小文字が一致しているユーザー(大文字、小文字、先頭大文字)が要求される場合は、「取得したユーザー名をプリンシパルとして使用する」を選択します。要求されない場合は、選択しないでください。

OSSO IDアサーション用のWebLogicドメインにプロバイダを追加するには

1. WebLogic管理コンソールにログインします。

2. OSSO IDアサーション・プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「認証プロバイダ」の表で、「新規」を選択します。

3. 新しいプロバイダの名前を入力し、タイプを選択して「OK」をクリックします。例:
名前: OSSO Identity Asserter

タイプ: OSSOIdentityAsserter

OK

4. 新しく追加されたプロバイダの名前をクリックします。

5. 「共通」タブで、共通パラメータに適切な値を設定し、「制御フラグ」をSUFFICIENTに設定してその内容を保存します。

3. デフォルト認証プロバイダ:

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. デフォルト認証プロバイダをクリックします。

3. 制御フラグをOPTIONALに設定し、「保存」をクリックします。

4. OID認証プロバイダ: このプロバイダを次の手順で追加します。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「新規」をクリックして、名前とタイプを入力します。
名前:OID認証プロバイダ

タイプ: OracleInternetDirectoryAuthenticator

「保存」をクリックします。

3. 新しく追加された認証プロバイダをクリックして、「設定」ページを表示します。デフォルト設定を保持します。Oracle Internet Directory構成が有効であることを確認するまで、制御フラグを変更しないでください。

注意:

OID認証プロバイダが唯一のプロバイダである場合、WebLogic Serverのユーザー・アカウントとそのアカウントに付与されたグループ・メンバーシップがOracle Internet Directoryで作成されていることを確認してください。作成されていない場合、WebLogicドメインは正常に開始されません。

4. 「プロバイダ固有」タブをクリックして、次の必要な設定を指定します。
ログイン例外の原因を伝播: 選択。

プリンシパル: LDAP管理ユーザー。例: cn=orcladmin。

ホスト: Oracle Internet Directoryのホスト名。

取得したユーザー名をプリンシパルとして使用する: 選択。

資格証明: LDAPの管理ユーザー・パスワード。例: password。

資格証明の確認: 例: password。

グループ・ベースDN: Oracle Internet Directoryのグループ検索ベース。

ユーザー・ベースDN: Oracle Internet Directoryのユーザー検索ベース。

ポート: Oracle Internet Directoryのポート。

5. プロバイダの並べ替え: プロバイダによってサブジェクトにプリンシパルが移入される順序は重要であり、レルム内のすべてのプロバイダのリストを並べ替えて、新しく追加されたプロバイダをリストの先頭に移動できます。

6. すべての構成設定を保存します。

7. 変更を有効にするために、Oracle WebLogic Serverを停止してから再起動します。

8. WebLogic管理コンソールにログインします。

1. 「セキュリティ・レルム」→「デフォルトのレルム名」→「プロバイダ」をクリックします。

2. 「ユーザーとグループ」タブを選択して、構成された認証プロバイダに含まれているユーザーとグループのリストを確認します。
Oracle Internet Directory構成のユーザー名が表示されます。これは、この構成が機能していることを暗黙的に表しています。

- Oracle Internet Directoryインスタンスが正常に構成されている場合、制御フラグを変更できます。

- Oracle Internet Directory認証のみでアプリケーションのユーザーを識別できる場合、SUFFICIENTフラグを選択します。SUFFICIENTは、ユーザーがOracle Internet Directoryに対して認証された場合、その他の認証は処理されないことを意味します。REQUIREDは、別のプロバイダによってユーザーがすでに認証されている場合でも、認証プロバイダによって正常に認証される必要があることを意味します。

9. アプリケーションでOracle Internet Directoryユーザーと大/小文字が一致しているユーザーが要求される場合: 「取得したユーザー名をプリンシパルとして使用する」を選択します。要求されない場合は、選択しないでください。

10. 変更を保存します。

11. 変更をアクティブ化して、Oracle WebLogic Serverを再起動します。

12. 「Oracle WebLogic Serverとその他のエンティティ間の信頼の確立」に進みます。

18.1.2.5 Oracle WebLogic Serverとその他のエンティティ間の信頼の確立

Oracle WebLogicの接続フィルタ・メカニズムを構成すると、アクセス制御リストを作成したり、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストのみからリクエストを受け入れることができます。

注意:

この項は、OSSOとOracle Access Managerのいずれを使用していても同じです。WebLogic管理コンソールで。

ネットワーク接続フィルタは、ネットワーク・レベルのリソースに対するアクセスを制御するコンポーネントです。これは、個々のサーバー、サーバー・クラスタまたは内部ネットワーク全体のリソースを保護できます。たとえば、フィルタを使用すると、企業ネットワークの外部から発信された非SSL接続を拒否できます。ネットワーク接続フィルタは、プロトコル、IPアドレスまたはDNSノード名をフィルタリングするように構成できるため、ファイアウォールのような機能を果たします。これは通常、Oracle WebLogic Serverと外部エンティティ間で信頼を確立する際に使用します。

接続フィルタ・ルール: フィルタ・ルールの形式は、フィルタ・ルールの入力にフィルタ・ファイルまたは管理コンソールのどちらを使用するかによって異なります。管理コンソールでは、次の形式でフィルタ・ルールを入力します。

targetAddress localAddress localPort action protocols

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverの保護』のWebLogicドメインのセキュリティの構成に関する項

表18-3は、接続フィルタの各パラメータを説明しています。

表18-3 接続フィルタ・ルール

パラメータ

説明

target

フィルタ対象の1つ以上のシステムを指定します。

localAddress

WebLogic Serverインスタンスのホスト・アドレスを定義します。(アスタリスク(*)を指定すると、すべてのローカルIPアドレスが返されます。)

localPort

WebLogic Serverインスタンスのリスニング・ポートを定義します。(アスタリスク(*)を指定すると、サーバー上のすべての使用可能なポートが返されます。)

action

実行するアクションを指定します。この値は、allowまたはdenyである必要があります。

protocols

フィルタ対象のプロトコル名の一覧。プロトコル名として、http、https、t3、t3s、giop、giops、dcom、ftpおよびldapを指定できます。プロトコル名を定義しない場合、すべてのプロトコルがフィルタ・ルールと一致します。

「接続ログの有効化」属性によって、正常な接続とサーバー上の接続データがログに記録されます。この情報は、サーバー接続の問題をデバッグする際に使用できます。

11gのOracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成するには

1. Oracle WebLogic管理コンソールにログインします。

2. 「ドメイン構成」の下の「ドメイン」をクリックします。

3. 「セキュリティ」タブ→「フィルタ」タブをクリックします。

4. 「接続ログの有効化」属性をクリックして、承認メッセージのロギングを有効にし、サーバー接続の問題をデバッグする際に使用できるようにします。

5. ドメインで使用する次の接続フィルタを指定します。

- デフォルト接続フィルタ: 「接続フィルタ」属性フィールドに、weblogic.security.net.ConnectionFilterImplを指定します。

- カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。このクラスは、Oracle WebLogic ServerのCLASSPATHでも指定する必要があります。

6. 適切な接続フィルタ・ルールの構文を入力します。

7. 「保存」をクリックします。

8. Oracle WebLogic Serverを再起動します。

9. 「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」に進みます。

18.1.2.6 OSSO IDアサーション・プロバイダ用のアプリケーションの構成

この項では、OSSO IDアサーション・プロバイダ用のアプリケーション認証方式の作成方法について説明します。

関連項目:

『Oracle Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ』

Oracle WebLogic Serverは、複数のauth-methodsの追加をサポートしています。WebLogicアプリケーション・コンソールでOSSO IDアサーション・プロバイダを設定している場合、OSSO IDアサーション・プロバイダを使用するWebアプリケーションのauth-methodがCLIENT-CERTに設定されている必要があります。

Oracle WebLogic Serverにアプリケーションをデプロイした後、次の手順で説明されているように、アプリケーションEARファイル内のすべてのweb.xmlファイルで、該当するレルムのauth-method要素にCLIENT-CERTが含まれている必要があります。

OSSO IDアサーション・プロバイダ用にweb.xmlを編集するには

1. アプリケーションEARファイルにある次のweb.xmlファイルを見つけます。例:

WEB-INF/web.xml

2. 該当するレルムのauth-methodを検索し、CLIENT-CERTと入力します。例:

<login-config>
<auth-method>CLIENT-CERT</auth-method>
<realm-name>myRealm</realm-name>
</login-config>

3. ファイルを保存します。

4. アプリケーションを再デプロイして再起動します。

5. アプリケーションEARファイルの各web.xmlファイルで、前述の手順を繰り返します。

18.2 ユーザーとSSOセッションの同期: SSO同期フィルタ

Fusion Middleware 11gには、コンテナ・ユーザー・セッションとSSOセッションを同期する新しいコンポーネントが導入されています。SSO同期フィルタは、Oracle WebLogicシステム・フィルタの実装です。SSO同期フィルタは、コンテナへのすべてのリクエストをインターセプトし、保護されたリソース・リクエストを操作して、コンテナのユーザー・セッションとOSSOのユーザー識別ヘッダー(Proxy-Remote-User)、またはOracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データとの同期を試みます。

SSO同期フィルタは、Javaサーブレット仕様バージョン2.3に基づくサーブレット・フィルタの実装です。SSO同期フィルタにより、アプリケーションはSSOユーザー・セッションを追跡して各セッションと同期する必要がなくなります。アプリケーションは、コンテナのユーザー・セッションと同期するだけで済みます。

SSO同期フィルタは、コンテナへの各リクエストをインターセプトし、そのリクエストに添付されているHTTPヘッダーに基づいて操作するかどうかを決定します。フィルタは、SSOエージェントがこれらのヘッダーをWeb層で設定していることを必要とします。保護されていないアプリケーション領域にアクセスする場合、フィルタはパススルーとして機能します。保護されたリソースにアクセスした後、Web層のSSOエージェントは、Oracle Access ManagerなどのSSOシステムで認証を実行するようユーザーに指示します。認証後、Oracle Access Manager IDアサーション・プロバイダによってユーザー・アイデンティティがJAASサブジェクトとしてコンテナに確立され、ユーザー・セッションが作成されます。WebLogicでは、ユーザー・セッション・データがHTTPセッションCookieの一部(JSESSIONID)として保持されます。

アプリケーション・リソースへの後続アクセスでは、SSO同期フィルタに次の2つの情報が提供されます。

- OSSOのユーザー識別ヘッダー(Proxy-Remote-User)

- Oracle Access Manager SSOセッションCookie (ObSSOCookie)内のユーザー・データ

SSO同期フィルタの役割は、コンテナのユーザー・アイデンティティとSSOセッションのユーザー・アイデンティティが一致していることを確認することです。不一致がある場合、フィルタはそのコンテナのユーザー・セッションを無効にします。このため、ダウンストリーム・アプリケーションはコンテナのユーザー・セッションを追跡するだけで済み、使用しているSSO環境に関係なく一貫した方法で作用できます。

注意:

- デフォルトで有効: SSO同期フィルタは、構成されたトークンからユーザー情報をフェッチし、既存セッション(存在する場合)からユーザーを取得し、CurrentSessionUserが着信SSOユーザーと一致していない場合はセッションを無効にしてリクエストされたURLにリダイレクトします。そうでない場合、リクエストは単にパススルーされます。
ドメインでOSSOまたはOracle Access Managerアサーション・プロバイダを構成していない場合、フィルタはWebLogic Serverの起動中に自動的に無効になります。

- デフォルトですべてのURIに対して有効(/*): アプリケーション・コードでの変更は不要です。

- OSSOトークン/ヘッダーに対する構成: Proxy-Remote-Userが検索され、大/小文字を区別しない一致が実行されます。

- Oracle Access Manager SSOトークン/ヘッダーに対する構成: OAM_REMOTE_USERとREMOTE_USERが検索され、大/小文字を区別しない一致が実行されます。

- グローバル・ログアウト: SSO同期フィルタは、OSSOまたはOracle Access Managerソリューションを使用するOracle Fusion Middlewareアプリケーションに対してシングル・ログアウト操作を提供します。これは、シングル・サインオンと同様に処理されます。グローバル・ログアウトが実行されると、セッションのクリーンアップが実行されていないアプリケーションに対して後続アクセスが行われたときに、SSOフィルタによってセッションが調整されます。
OSSOまたはOracle Access Managerソリューションを使用するアプリケーションは、OSSOログアウトまたはOracle Access Managerログアウトをコールする前にそのセッションを無効にする必要があります。OSSOログアウトの詳細は、「動的ディレクティブによるSSOログアウト」を参照してください。Oracle Access Managerログアウトの詳細は、「Oracle Access Manager 10gおよび10g Webゲート用のグローバル・ログアウトの構成」を参照してください。

- アプリケーション・セッション・タイムアウト: 通常、SSO Cookieはユーザーの非アクティブ/アイドル・タイムを追跡し、タイムアウトが発生した場合はユーザーにログインを要求します。OSSOとOracle Access Managerも例外ではありません。Oracle Access Managerでは、より高度なアプローチが採用されており、SSOセッションの作成時間と最終リフレッシュ時間に加えて、最大アイドル・セッション時間と最長アイドル・セッション時間が追跡されます。
独自のセッションを保持しているアプリケーションとSSOシステムの統合に関する一般的な推奨事項は、SSOのセッション・タイムアウトとアプリケーションのセッション・タイムアウト間で一貫した操作性が得られるように、アプリケーションのセッション・タイムアウトをSSOのセッション・タイムアウトに近い値に構成することです。

様々な優先システム・プロパティをWebLogicに渡すことにより、アプリケーションの要件に応じてSSO同期フィルタの動作を変更できます。このためには、Oracle WebLogic起動スクリプトを変更して、setDomainEnv.shにEXTRA_JAVA_PROPERTIESがあるか確認します。表18-4に、各プロパティと同期動作を示します。

表18-4 SSO同期フィルタの各プロパティと同期動作

領域

優先システム・プロパティ

システム・プロパティのデフォルト値

同期フィルタのデフォルト動作

ステータス(有効または無効)

sso.filter.enable

構成なし

有効

大/小文字を区別した一致

sso.filter.name.exact.match

構成なし

大/小文字を区別しない一致

構成されたトークン

sso.filter.ssotoken

構成なし

- OSSO: Proxy-Remote-Userを検索する

- Oracle Access Manager: OAM_REMOTE_USERおよびREMOTE_USERを検索する
OAM_REMOTE_USERが優先される

URIマッピング

なし

なし

/*

一部のアプリケーションに対してフィルタを有効にすることはできません。SSO同期フィルタは、システム・フィルタです。このため、デプロイされているすべてのアプリケーションに対して有効になります(URIマッピングは/*)。

注意:

一部のアプリケーションに対してフィルタを有効にすることはできません。

次の手順に、SSO同期フィルタのプロパティと動作の変更に関するヒントを示します。

SSO同期フィルタのプロパティと動作を変更するには

1. フィルタの無効化: システム・プロパティsso.filter.enableをfalseに変更し(jvmに-Dとして渡す)、Oracle WebLogic Serverを再起動します。これにより、フィルタ・ステータスが切り替わります。

2. ユーザー識別ヘッダーと事前構成済同期フィルタ・トークンの不一致: システム・プロパティsso.filter.ssotokenを使用して、同期フィルタによって検索されるSSOトークンを上書きします。
たとえば、WebLogic Serverの起動スクリプト(-Dsso.filter.ssotoken=HEADERNAME)でWebLogic Server JVMに渡し、サーバーを再起動します。

Oracleサポート・サービスにお問合せの際は、「WebLogic管理コンソールでのデバッグの設定」の説明に従ってデバッグを設定するように求められる場合があります。

18.3 OSSO IDアサーション・プロバイダのデプロイメントのトラブルシューティング

この項で説明するトラブルシューティング項目は、次のカテゴリに分かれています。

- SSO関連の問題

- OSSO IDアサーション・プロバイダ関連の問題

- URL再書込みとJSESSIONID

- mod_osso、OSSO Cookieおよびディレクティブについて

- IPv6の使用について

関連項目:

- 「WebLogic管理コンソールでのデバッグの設定」

- Oracle Technology Networkの『Oracle Application Server Single Sign-On管理者ガイド』の「トラブルシューティング」(http://www.oracle.com/technology/documentation/oim1014.html)

18.3.1 SSO関連の問題

この項では、次のトラブルシューティング項目について説明します。

- OHSがSSOにリダイレクトしない - 内部サーバー・エラー500

- 属性AuthNameは必要か

- URLリクエストがSSOにリダイレクトされない

- エラー404 - 「見つかりません」が発行される(OHS側)

- エラー404 - 「見つかりません」が発行される(Oracle WebLogic Server側)

- Oracle SSOの失敗 - リクエストを処理できません

- スタンドアロンのWebLogic Serverにデプロイされたアプリケーション用のOSSOソリューション

OHSがSSOにリダイレクトしない - 内部サーバー・エラー500

この問題の原因として可能性が高いのは、不適切な構成です。

次のサンプルでは、Oracle HTTP Server 11gを使用しています。Oracle HTTP Server 10gを使用している場合は、パス名が異なります。

それに対処する手順は、次のとおりです。

1. ファイルmod_osso.confを開き、リソースが保護されていることを確認します。例:

ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

<Location /protected-resource-uri>
require valid-user
AuthType Basic
</Location>

2. osso.confが存在しており、mod_osso.confに組み込まれていることを確認します。ここでは、例としてOracle HTTP Server 11gを使用します(10gの場合はパスが異なります)。

OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf

注意:

osso.confの場所は特に設定されていません。値は登録時に決定され、任意の絶対パスになります。

3. httpd.confに、mod_osso.confが組み込まれていることを確認します。ここでは、例としてOracle HTTP Server 11gを使用します(10gの場合はパスが異なります)。

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

include /ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

4. 前述の設定をすべて適切に指定してもSSOの登録が正常に完了しない場合、SSOの再登録が必要になります。
SSOを登録するには、プラットフォームに適したssoregツールを使用して次の手順を実行します。例:

1. 10.1.4のORACLE_HOME/sso/binにあるssoreg.shを実行し、ファイルosso.confを作成します。次に、ファイル/tmp/osso.confを作成するこのユーティリティの使用例を示します(例示のためにのみ、引数を別の行に記述しています)。

>ssoreg.sh -oracle_home_path /OraHome
-site_name wls_server
-config_mod_osso TRUE
-mod_osso_url http://host.domain.com:6666
-update_mode CREATE
-remote_midtier
-config_file /tmp/osso.conf

2. 生成されたosso.confを、別のファイル・システム・ディレクトリにコピーします。例: ORACLE_INSTANCE/config/OHS/<ohs_name>/osso。

3. OHSを再起動します。

属性AuthNameは必要か

ログ・メッセージは、属性AuthNameが必要なことを示している場合があり、特定のバージョンのApacheにはこの属性が必要です。

この例では、Oracle HTTP Server 11gを使用しています。Oracle HTTP Server 10gを使用している場合は、パス名が異なります。

この属性を組み込むには、ファイルmod_osso.confを編集し、次の断片を挿入します。

LoadModule osso_module modules/mod_osso.so
<IfModule mod_osso.c>
OssoIdleTimeout off
OssoIpCheck on
OssoConfigFile  ORACLE_INSTANCE/config/OHS/<ohs_name>/osso/osso.conf

<Location />
AuthName "Oracle Single Sign On"
require valid-user
AuthType Basic
</Location>
</IfModule>

URLリクエストがSSOにリダイレクトされない

URLリクエストを発行したとき、SSOにリダイレクトされるかわりに基本ポップアップが表示される場合は、URLリクエストがApache認証モジュールにインターセプトされた可能性が高いです。

この問題に対処する方法は、次のとおりです。

1. ファイルhttpd.confを編集し、次の断片に示すように、認可モジュールのロードをコメント・アウトします。

ORACLE_INSTANCE/config/OHS/<ohs_name>/httpd.conf

LoadModule access_module modules/mod_access.so
#LoadModule auth_module modules/mod_auth.so
#LoadModule auth_anon_module modules/mod_auth_anon.so
#LoadModule auth_db_module modules/mod_auth_dbm.so
LoadModule proxy_module modules/mod_proxy.so

2. OHSを再起動します。

エラー404 - 「見つかりません」が発行される(OHS側)

このエラーは通常、次の形式です。

The requested URL <request-uri> was not found on this server

WebLogicリダイレクトが実行されておらず、リクエストが、使用できないOHSリソースを使用しようとしている可能性が高いです。

この問題に対処するには、次の断片に示すようにmod_weblogicがファイルhttpd.confに組み込まれていることと、WebLogicハンドラがリクエスト・パターンに対して設定されていることを確認します。

#httpd.conf
<IfModule mod_weblogic.c>
WebLogicHost <host>
WebLogicPort yourWlsPortNumber
</IfModule>

<Location /request-uri-pattern>
SetHandler weblogic-handler
</Location>

エラー404 - 「見つかりません」が発行される(Oracle WebLogic Server側)

このエラーは通常、次の形式です。

Error 404--Not Found

原因

このメッセージは、Oracle WebLogic Serverがリソースを見つけられないことを通知します。

解決策

この問題に対処するには、リソースがサーバーにデプロイされていることを確認します。たとえば、パターンが/private1/Helloである場合、ルートがprivate1であるサーバー上でHelloにアクセスできるかどうかを確認します。

Oracle SSOの失敗 - リクエストを処理できません

問題

次のようなメッセージを受信します。

Oracle SSO Failure - Unable to process request
Either the requested URL was not specified in terms of a fully-qualified host
name or Oracle HTTP Server single sign-on is incorrectly configured.
Please notify your administrator.

解決策

Oracle HTTP Server httpd.confファイルを変更し、ServerNameにポート番号を追加してWebサーバーを再起動します。例:

変更前: ServerName host.domain.com

変更後: ServerName host.domain.com:port

スタンドアロンのWebLogic Serverにデプロイされたアプリケーション用のOSSOソリューション

この章では、Oracle Fusion Middleware Oracle WebLogic Serverにデプロイされたアプリケーションのシングル・サインオン(SSO)の構成方法を説明しています。一方、(Fusion Middlewareが組み込まれていない)スタンドアロンのOracle WebLogic Serverにデプロイされたアプリケーションの詳細は次のとおりです。

- OSSOでのOracle Fusion Middleware: 必須OSSO IDアサーション・プロバイダ(ossoiap.jar)は、Oracle Fusion MiddlewareのOracle Identity Management、Oracle SOA SuiteまたはOracle WebCenterのインストール時に自動的に設定されます。

注意:

OSSOでのOracle Fusion Middlewareにより、Oracle HTTP Server 10gまたは11g Webサーバーのどちらでも使用できます。

- OSSOでのスタンドアロンOracle WebLogic Server: 必須OSSO IDアサーション・プロバイダ(ossoiap.jar)を、ここで説明したように、Oracle Web層から入手する必要があります。

注意:

Fusion Middlewareがない場合には、OSSOにはOracle HTTP Server 11gが必要です。

OSSOをOracle Fusion Middlewareアプリケーションで使用しても、他のアプリケーションで使用しても、IDアサーション・プロバイダは「OSSO IDアサーション・プロバイダの使用」の説明にある同じ機能を実行します。

以下に記載されているのは、セッションを無効するためのシングル・ログアウトおよびSSO CookieとJSESSIONID Cookieの間の同期を構成してテストする際に使用できる、追加事項、オプション、詳細などです。必須のファイルはOracle Web層から入手する必要があります。

タスクの概要: スタンドアロンのWebLogic Server上のアプリケーションで使用するOSSO IDアサーション・プロバイダのデプロイおよび構成

1. Oracle WebLogic Server 10.3.1以降とその他の必須コンポーネントを次のとおりインストールします。

1. 「タスクの概要: スタンドアロンのWebLogic Server上のアプリケーション用OSSO IDアサーション・プロバイダのデプロイおよび構成」の説明にあるステップ1のaからdを実行します。

2. ステップ1eを省略して、使用するアプリケーションをかわりにデプロイします。

2. webloginドメイン拡張テンプレートを使用してWebLogicセキュリティ・ドメインを作成します。この拡張テンプレートは、Oracle WebLogic Serverに付属しており、$WLS_HOME/common/bin/config.shから使用できます。

3. 「mod_weblogicの構成」の説明に従って、Oracle WebLogic Serverにリクエストを転送するようにmod_weblogicを構成します。

4. 「OSSO IDアサーション・プロバイダの新規ユーザー」の説明に従って、モジュールmod_ossoをパートナ・アプリケーションとして10g SSO Serverに登録して構成します。

1. 「OSSO Server 10.1.4へのOracle HTTP Server mod_ossoの登録」で説明されている手順を実行します。

2. 「Webリソースを保護するためのmod_ossoの構成」で説明されている手順を実行します。

5. 認証プロバイダを、次のように適切なセキュリティ・ドメインに追加します。

1. OSSO IDアサーション・プロバイダ(ossoiap.jar)を次のOracle Web層から入手します。

$ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar

2. ossoiap.jarを$WLS_HOME/wlserver_10.x/server/lib/mbeantypeにコピーし、Oracle WebLogic Serverを再起動します。

3. 「OSSO用WebLogicドメインへのプロバイダの追加」の説明に従って、プロバイダを構成します。

6. 「Oracle WebLogic Serverとその他のエンティティ間の信頼の確立」の説明に従って、Oracle WebLogicの接続フィルタ・メカニズムを構成し、アクセス制御リストを作成して、Oracle HTTP ServerとフロントエンドWebサーバーが実行されているホストからのリクエストを受け入れます。

注意:

Oracle WebLogic Serverのホストとポートを使用し、保護されたアプリケーションをテストして、デフォルトの認証プロバイダでそのアプリケーションが機能していることを確認します。

7. 「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明に従って、OSSO IDアサーション・プロバイダ用のアプリケーション認証メソッドを構成します(アプリケーションEARファイル内のすべてのweb.xmlファイルで、要素auth-methodにCLIENT-CERTが含まれている必要があります)。

注意:

Oracle HTTP Serverのホストとポートを使用してアプリケーションにアクセスする際に、OSSOが認証したユーザーを使用してアプリケーションをテストします。

8. オプション: 次のように、シングル・ログアウト(セッション無効化およびSSO CookieとJSESSIONID Cookieとの同期)を構成およびテストできます。

関連項目:

"「ユーザーとSSOセッションの同期: SSO同期フィルタ」のSSOFilterに関する項

1. 次のとおり、ssofilter.jarを入手し、それを使用できるようにOracle WebLogic Serverを構成します。
1. ssofilter.jarを次のOracle Web層から入手します。

$ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar

2. それをOracle Middlewareホームの適切なディレクトリにコピーします(例: WLS_INSTALL/Oracle/Middleware/modules)。

3. Oracle WebLogic Serverのクラスパスにssofilter.jarの絶対パスを追加します(setDomainEnv.shスクリプトのPOST_CLASSPATH変数またはCLASSPATH変数を編集します)。

2. 次のように、system-filters.warをシステム・フィルタとしてデプロイします。
1. system-filters.warを次のOracle Web層から入手します。

$ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war

2. system-filters.warをOracle Middlewareホームの適切なディレクトリにコピーします(例: WLS_INSTALL/Oracle/Middleware/modules directory)。

3. system-filters.warをアプリケーション・ライブラリとしてデプロイします。WebLogic管理コンソールから、「デプロイ」をクリックして、「新規」を選択してファイルの場所を選択します。

4. プロンプトが表示されたら、Oracle WebLogic Serverを再起動します。

3. 次のようにログを有効化してSSOFilterが機能していることを確認します。
1. WebLogic管理コンソールから、「ドメイン」→「環境」→「サーバー」→「管理サーバー」をクリックします。

2. 「ロギング」タブをクリックします。

3. 「詳細」ドロップダウンで、「デバッグ」として「ログの最低の重大度」を選択します。

4. 「詳細」ドロップダウンで「メッセージの宛先」を選択し、「デバッグ」として「ログ・ファイル: 重大度」を選択します。

5. 変更内容を保存して、Oracle WebLogic Serverを再起動します。

4. SSOFilterがシステム・フィルタとしてロードされていることを確認します。
1. DomainHome/Servers/AdminServer/log/AdminServer.logファイルを開きます。

2. 「SSOFilter」を検索して、<Debug>メッセージが表示されることを確認します。このメッセージは、SSOFilterの初期化を示し、フィルタのロードを確認するものです。

5. フィルタの機能をテストして、SSO CookieおよびJSESSIONID Cookieがユーザーのログアウト後にクリーンアップされ、ログアウト後のアプリケーションへのアクセス試行では、再度ログインする必要があることを確認します。

注意:

OSSO IDアサーション・プロバイダがWebLogicセキュリティ・ドメインで構成されるようにする必要があります。そうしないと、フィルタの初期化実行中にフィルタが自動的に無効になります。

6. アプリケーションでログアウトのテストをして、セッションが正確に終了していることを確認します。

「常に監査するユーザー」で指定したSSOユーザーに対する大文字指定

Oracle HTTP Serverの監査の構成にある「常に監査するユーザー」セクションでSSOユーザーを指定する場合、SSOユーザー名を大文字で指定する必要があります。

カンマ区切りのリストで複数のユーザーを指定して、これらのユーザーが開始した監査イベントにこの監査フレームワークが適用されるようにすることができます。監査は、指定された監査レベルやフィルタとは関係なく行われます。これは、あらゆるタイプの認証に当てはまります。

詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』の「監査ポリシーの管理」の章で監査の構成と管理に関する項を参照してください。

18.3.2 OSSO IDアサーション・プロバイダ関連の問題

この項では、次のトラブルシューティング項目について説明します。

- エラー403 - 禁止

- エラー401 - 未認可

- OSSO IDアサーションが起動されていない

エラー403 - 禁止

このメッセージは、ユーザーがリソースにアクセスするために必要なパーミッションを持っていないことを通知します。このメッセージは、たとえば、アプリケーションがWLSグループSSOUsersに属するユーザーにアクセスを許可するように構成されていて、アサートされたユーザーが別のグループに属している場合に表示されます。

これがパーミッションの問題ではないと確認した場合は、デフォルトのID認証プロバイダのJAAS制御フラグがREQUIREDに設定されているかどうかを確認し、設定されている場合は、その設定を必要に応じてOPTIONALまたはSUFFICIENTに変更します。

エラー401 - 未認可

このメッセージは、リソースにアクセスするには、ユーザーは最初に認証が必要なことを通知します。

解決策

1. ユーザーが本当に認証されているかどうかを確認します。

2. SSOを使用した認証を最初に受けずにサーバーにアクセスしようとしていないかどうかを確認します。

OSSO IDアサーションが起動されていない

保護されたソースに対してOSSO IDアサーション・プロバイダを呼び出せない状況には、通常、不適切な構成が関与しています。環境に、「OSSO IDアサーション・プロバイダ用のアプリケーションの構成」の説明のような構成が正確に組み込まれていることを確認してください。

18.3.3 URL再書込みとJSESSIONID

アプリケーション・リソース(URL)へのアクセス時にJSESSIONID Cookieが見つからない場合、WebLogic Serverは、JSESSIONIDをURLの一部として含めることによりURLの再書込みを行います。対象のURLが保護されているときは、再書込みしたURLのマッチングが、Oracle Access ManagerとOSSO Webエージェントでは困難な場合があります。

不一致の問題を回避するには、mod_osso.confに指定されている保護されたリソースの最後にアスタリスク(*)を追加します。たとえば、次のような保護されたURLがあるとします。

/myapp/login

これは、mod_ossoエントリの次の場所にあります。

<Location /myapp/login*>
valid user
AuthType OSSO
</Location>

18.3.4 mod_osso、OSSO Cookieおよびディレクティブについて

Mod_ossoモジュールは、SSO対応ログイン・サーバーとOracle HTTP Serverリスナー間の通信を提供します。mod_ossoモジュールは、mod_osso.confファイルを編集することで制御されます。

- Oracle HTTP Server 11gのインストールには、mod_ossoとmod_weblogicが含まれています。

- Oracle HTTP Server 10.1.3のリリースのCompanion CDに含まれているOHS 10gには、mod_ossoが含まれています。

関連項目:

次の各項とリリース1 (11.1.1)のマニュアル

- 「Webリソースを保護するためのmod_ossoの構成」

- 『Oracle Fusion Middleware Oracle Web Tierインストレーション・ガイド』

- 『Oracle Fusion Middleware Oracle HTTP Server管理者ガイド』

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

- mod_ossoの新しいOssoHTTPOnlyディレクティブ

- mod_ossoのOssoSecureCookiesディレクティブ

- mod_ossoが戻りURLをエンコードしない

- mod_osso: デフォルトのインストール後に「ページが見つかりません」と表示される

18.3.4.1 mod_ossoの新しいOssoHTTPOnlyディレクティブ

OSSO CookieにHTTPOnlyフラグ設定を構成するための新しい構成ディレクティブがmod_ossoに追加されました。新しいディレクティブは、OssoHTTPOnlyです。値は、On(フラグの有効化)またはOff(フラグの無効化)です。デフォルトでは、HTTPOnlyフラグはOnに設定されます。このディレクティブは、構成では設定されません。

このディレクティブは、ブラウザに設定されたOSSO CookieにHttpOnlyフラグを追加します。このフラグの目的は、クロスサイト・スクリプティングを防止することです。このフラグが設定されたCookieは、ブラウザで実行されているJavaScriptコードまたはアプレットからはアクセスできません。このフラグが設定されたCookieは、特定のドメインにhttpまたはhttpsを介してCookieを設定したサーバーにのみ送信されます。

これはVirtualHostディレクティブごとに指定します。グローバル・スコープまたはVirtualHostセクション内でのみ設定できます。次の例は、新しいディレクティブを示しています。

<VirtualHost *.7778>
OssoConfigFile  conf/osso.conf
OssoHTTPOnly On
---
---
---
<Location /osso>
AuthType Osso
---
---
</Location>

</VirtualHost>

18.3.4.2 mod_ossoのOssoSecureCookiesディレクティブ

mod_osso 10gでは、OssoSecureCookiesディレクティブはデフォルトで無効になっています。ただし、mod_osso 11gでは、この動作はデフォルトで有効になっています。mod_osso 11gでOssoSecureCookiesディレクティブを無効にするには、対応する構成ファイルでOssoSecureCookiesをOffに設定する必要があります。mod_ossoを有効にすると、次の場所にmod_osso.confファイルが作成されます。

ORACLE_INSTANCE/config/OHS/<ohs_name>/moduleconf/mod_osso.conf

OssoSecureCookiesディレクティブを設定する手順は、次のとおりです。

OssoSecureCookies "Off"

18.3.4.3 mod_ossoが戻りURLをエンコードしない

ログアウトのためにOracle SSO Serverにリダイレクトしたときに、mod_ossoが問合せに戻りURLをエンコードしません。

この問題を修正するには、エンコードされたURLを渡す必要があります。例: response.setHeader("Osso-Return-Url", encoded-url)。

18.3.4.4 mod_osso: デフォルトのインストール後に「ページが見つかりません」と表示される

SSOページを表示しようとしたときに「ページが見つかりません」というエラーが発生する原因としては、次のものが考えられます。

- ロード・バランサがない状態で同じOHSとのルーティング関係が複数ある: これはサポートされていません。

- ルーティング関係がない

解決策: ルーティング関係が複数ある場合

このoc4j_imに関連付けられていない余分なルーティング関係を見つけて削除します。このoc4j_imに関連付けられているルーティング関係は残しておきます。

1. 次のコマンドを使用して、環境内のルーティング関係をすべて表示します。

asctl:/imha/inst1/ohs_im>ls -a -l
oc4j_im_ohs_im_routing_relationship -> /imha/inst12/oc4j_im
oc4j_im_ohs_im_routing_relationship_ -> /imha/inst11/oc4j_im

2. 操作環境に対応する値を使用して次のコマンドを使用し、特定のoc4j_imに関連付けられていないルーティング関係を削除します。例:

asctl:/imha/inst1/ohs_im> rmrel(name='oc4j_im_ohs_im_routing_relationship_
',pt='/imha/inst11/oc4j_im')

3. OHS Webサーバーとoc4j_imの両方を停止して起動します。

4. SSOページが表示されたことを確認します。

解決策: ルーティング関係がない場合

デフォルトでは、インストーラによって、各OHSと各oc4j_imの間にルーティング関係が作成されます。OHSとoc4j_imの間にルーティング関係がない場合は作成する必要があります。

1. 操作環境に対応する値を使用して次のコマンドを使用し、ルーティング関係を作成します。

createRoutingRelationship(name='rr1',ut='/imha/inst1/ohs_im',pt='/imha/inst12/
@ oc4j_im')

2. OHS Webサーバーとoc4j_imの両方を停止して起動します。

3. SSOページが表示されたことを確認します。

18.3.5 IPv6の使用について

Oracle Fusion Middlewareでは、インターネット・プロトコル・バージョン4 (IPv4)およびインターネット・プロトコル・バージョン6 (IPv6)がサポートされます。IPv6の特筆すべき機能は、Pv4 (32ビット)よりも大きいアドレス空間(128ビット)をサポートしていることです。これにより、Web上でアドレッシングできるコンピュータの数が飛躍的に増えます。

関連項目:

Oracle Single Sign-on ServerでのIPv6使用の詳細は、『Oracle Fusion Middleware管理者ガイド』を参照してください。

第V部

Oracle Platform Security ServicesのAPIを使用した開発

このパートでは、次の各章で、OPSS APIを使用してアプリケーション内でカスタムのセキュリティ・ソリューションを開発する方法を説明しますす。

- 第19章「アプリケーション・セキュリティのOPSSとの統合」

- 第20章「OPSSポリシー・モデル」

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

- 第22章「Java SEアプリケーションの認証」

- 第24章「資格証明ストア・フレームワークを使用した開発」

- 第23章「Java SEアプリケーションの認可」

- 第25章「ユーザーおよびロールAPIを使用した開発」

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

この章では、セキュリティ関連のユースケースおよびADFアプリケーション・セキュリティの一般的なライフ・サイクルについて説明します。また、このガイドの他の章に掲載されているコードおよび構成例もリストします。

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

- 概要

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

- ユースケースの詳細

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

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

19.1 概要

この章の情報の対象読者は、開発者、セキュリティ設計者およびセキュリティ管理者です。情報は、このガイドのほとんどの項のように機能ごとではなく、ユースケースごとにまとめられています。アプリケーション・セキュリティの一般的な課題を解決するいくつかのユースケースが、特定のアプリケーション・セキュリティ要件を解決するための出発点として紹介されています。ユースケースには、宣言的なアプローチを使用する(アプリケーション・コードの変更を必要としない)ものと、プログラム的アプローチを使用するもの、さらに両方のアプローチを必要とするものがあります。

セキュリティ設計者や開発者が直面する主要なセキュリティ上の課題には、ユーザーの管理、ユーザー・パスワードの管理およびリソースへのアクセスの管理などがあります。OPSSは、次の機能をサポートすることでこれらの課題に対する解決策を提供するセキュリティ・サービス・スイートです。

- セキュリティ・アーティファクトおよびセキュリティ・ロジックのアプリケーションからの外部化

- セキュリティに対する宣言的アプローチ

- 完全なユーザー・アイデンティティ・ライフ・サイクル

- ポリシー主導のアクセス制御

図19-1は、アプリケーションがセキュリティ・ストアにアクセスする方法、およびこれらのストアを管理するためのツールを示します。

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

関連ドキュメントへのリンク

次の項目については、他の章で説明しています。

- OPSSセキュリティ・アーキテクチャ: 第1.2項「OPSSのアーキテクチャの概要」を参照してください。

- シングル・サインオン: 第IV部を参照してください。

- ADFアプリケーション: Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイドを参照してください。

- Oracle開発ツール: 『Oracle Fusion Middleware Oracle Security Developer Toolsリファレンス』を参照してください。

OPSS APIのリストについては、付録H「リファレンス」を参照してください。

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

この項では、次の主なセキュリティ機能またはセキュリティ・アーティファクトに基づいて分類したいくつかのユースケースを紹介します。

- 認証

- アイデンティティ

- 認可

- 資格証明

- 監査

- アイデンティティ伝播

- 管理

- 統合

各ユースケースには、解決を試みる問題の簡単な説明、必要なセキュリティ・アーティファクト、関連する機能、およびその問題を解決するための詳細情報へのリンクが含まれます。特に明記しないかぎり、すべての説明はOracle WebLogic Application ServerおよびWebSphere Application Serverに当てはまります。

19.2.1 認証

認証ユースケースは次のとおりです。

- 認証されたユーザーが必要なJava EEアプリケーション: Java EEアプリケーションにアクセスするには、ユーザーは認証を受ける必要があります。

- プログラム認証が必要なJava EEアプリケーション: Java EEアプリケーションは、ユーザーをプログラムにより認証する必要があります。

- 認証が必要なJava SEアプリケーション: Java SEアプリケーションは、ドメイン・アイデンティティ・ストアに対して認証を行う必要があります。

19.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項「Oracle WebLogicの認証プロバイダ」を参照してください。

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

デプロイメント・ディスクリプタを使用しないあるJava EEアプリケーションは、構成済のアイデンティティ・ストアに対してユーザーをプログラム的に認証する必要があります。これは、Oracle WebLogic Application ServerにデプロイされたJava EEアプリケーションにのみ当てはまります。

このユースケースでは、ユーザーを認証するためにOPSSパブリックAPIを使用する必要があり、次の機能を使用します。

- Java EEコンテナに対する認証プロバイダの構成

- ユーザーを認証するためのLoginService APIの使用

このユースケースの詳細は、第22.1項「Java EEアプリケーションの認証トピックへのリンク」を参照してください。

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

あるJava SEアプリケーションは、ドメイン内で使用されているLDAPアイデンティティ・ストアに対してユーザーを認証する必要があります。ドメインのアイデンティティ・ストアの詳細にかかわらず、認証をリクエストするアプリケーション・コードは同じでなければなりません。

このユースケースでは、認証に使用されるアイデンティティ・ストアを構成し、LoginServiceを使用する必要があります。Java SEアプリケーションでは、1つのidログイン・モジュールしか使用できないことに注意してください。

このユースケースの詳細は、第22.2.4項「Java SEアプリケーションでのOPSS API LoginServiceの使用方法」を参照してください。

19.2.2 アイデンティティ

アイデンティティ・ユースケースは次のとおりです。

- 2つの環境で実行されるアプリケーション: 2つの異なる環境で実行されるアプリケーションが、LDAPベースのストア内のユーザー・プロファイル情報にアクセスする必要があります。

- 複数のストア内のユーザー・プロファイルにアクセスするアプリケーション: アプリケーションは、複数のLDAPベースのストア内に格納されたユーザー・プロファイル情報にアクセスする必要があります。

19.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"

このユースケースの詳細は、第7.2項「アイデンティティ・ストア・プロバイダの構成」を参照してください。

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

あるアプリケーションは、複数のLDAPベースのストアに格納されたユーザー・プロファイル情報にアクセスする必要があります。

このユースケースでは、複数のLDAPベースのストアに対する環境を構成する必要があります。

詳細は、次の各項を参照してください。

- 複数のLDAPの構成については、第7.3.2.6項「構成ファイルの例」を参照してください。

- アイデンティティ・ストア・サービスの構成については、第7.3項「アイデンティティ・ストア・サービスの構成」を参照してください。

19.2.3 認可

認可ユースケースは次のとおりです。

- 特定のロールのみアクセス可能なJava EEアプリケーション: Webディスクリプタで構成されているユーザーのみがJava EEアプリケーションにアクセスできます。

- ファイングレイン認可が必要なADFアプリケーション: ADFアプリケーションにファイングレイン認可が必要です。

- Webサービスを保護するWebアプリケーション: Webサービス・アプリケーションはWebサービスを保護する必要があります。

- コードベースのパーミッションが必要なJava EEアプリケーション: Java EEアプリケーションにコードベースのパーミッションが必要です。

- ファイングレイン認可が必要な非ADFアプリケーション: 非ADFアプリケーションにファイングレイン認可が必要です。

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

あるJava EEアプリケーションには、Webディスクリプタで特定のロールが割り当てられたユーザーのみがアクセスできる必要があります。グループからロールへの割当ては、顧客の環境に応じて、デプロイメントで構成可能でなければなりません。

このユースケースの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』のWebアプリケーションでの宣言によるセキュリティの使用に関する項およびEJBでの宣言によるセキュリティの使用に関する項を参照してください。

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

コンテナ内のあるADFアプリケーションには、Webアプリケーション内のページ上の個々のコントロール・レベルでのファイングレイン認可が必要です。認可チェックはアプリケーションで開始されますが、ポリシーは外部化し、アプリケーションのデプロイメント後に顧客ごとにカスタマイズ可能である必要があります。

Oracle ADFアプリケーションの開発および保護の詳細は、Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイドの第30章「Fusion WebアプリケーションのADFセキュリティの導入」を参照してください。

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

ADFアプリケーションのライフ・サイクルの詳細は、「付録: ADFアプリケーションのセキュリティ・ライフ・サイクル」を参照してください。

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

あるWebアプリケーションは、ファイングレイン・ポリシーを使用してWebサービスを保護する必要があります。

Webサービスのセキュリティ管理の詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドを参照してください。

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

あるJava EEアプリケーションには、特定のアクションを実行するためにコードベースのパーミッションが必要です。アクションの代表的な例としては、資格証明ストアから資格証明を読み取る、またはポリシー・ストアでポリシーを検索するなどがあります。

Fusion Middleware Controlでのコードベース・ポリシーの作成の詳細は、第9.2.3項「システム・ポリシーの管理」を参照してください。

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

ある非ADFアプリケーションは、ファイングレイン認可チェックを使用して保護する必要があります。

このユースケースでは、次のことが求められます。

- アプリケーション・コード内の適切な箇所へのチェックの配置

- 適切なポリシーの構成

詳細は、第20.3項「JAAS/OPSS認可モデル」を参照してください。

19.2.4 資格証明

資格証明ユースケースは次のとおりです。

- システムへのアクセスに資格証明が必要なアプリケーション: アプリケーションには、バックエンド・システムにアクセスするために資格証明が必要です。

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

あるアプリケーションには、データベースまたはLDAPサーバーなどのバックエンド・システムに接続するために資格証明が必要です。アプリケーション・コードは、デプロイメント後にアプリケーション・コードを変更することなく顧客ごとに資格証明の詳細が変更可能になるよう、この資格証明を参照する必要があります。さらにこのユースケースでは、資格証明ストアにアクセスできるユーザー、および認可されたユーザーが資格証明ストアで実行できる操作を指定する必要もあります。

このユースケースでは、次の機能を使用します。

- 資格証明を永続化するための資格証明ストアの使用

- アプリケーション・コード内のCSF APIによる実行時の資格証明のフェッチ

- コードベース上でのシステム・ポリシーの定義と施行

詳細は、次の各項を参照してください。

- 構成およびコードの例については、第24.3項「Javaセキュリティ・ポリシーのパーミッションの設定」および第24.7項「例」を参照してください。

- 資格証明の管理については、第10.3項「資格証明ストアの管理」を参照してください。

- パッケージ化については、第21.3.2項「アプリケーションと資格証明とのパッケージ化」を参照してください。

19.2.5 監査

監査ユースケースは次のとおりです。

- セキュリティ関連アクティビティの監査: アプリケーションは、セキュリティ関連のアクティビティを記録する必要があります。

- ビジネス関連アクティビティの監査: アプリケーションは、フローのコンテキストでビジネス・アクティビティを記録する必要があります。

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

あるアプリケーションは、複数のセキュリティ領域でセキュリティ関連アクティビティを記録する必要があります。具体的には、次の情報を記録する必要があります。

- ポリシーへの変更: 何がいつ変更されたか

- 特定の時間間隔内に評価されたポリシー

- 資格証明またはキーへの変更: 何がいつ変更されたか

このユースケースで説明する設定は、ドメイン内のすべてのアプリケーションおよびコンポーネントに当てはまります。

このユースケースでは、監査可能なアプリケーションが次の条件を満たしている必要があります。

- 共通監査フレームワーク(CAF)に統合される

- セキュリティ・アクティビティを記録する機能が組み込まれている

- 特定のセキュリティ領域でアクティビティを取得するための適切な監査フィルタ・レベルが設定されている

このユースケースでは、次の機能を使用します。

- 共通監査フレームワークへの統合

- アプリケーションがセキュリティ領域内で独自の監査カテゴリおよびイベントを定義することを可能にし、アプリケーションを監査対応にする

- アプリケーションでの適切なフィルタ・レベルの設定を可能にする

詳細は、次の各項を参照してください。

- CAFへの統合については、第28.4項「監査フレームワークへのアプリケーションの統合」を参照してください。

- アプリケーションの登録については、第28.6項「登録サービスへのアプリケーションの登録」を参照してください。

- 監査イベントの記録については、第28.7項「監査イベントを記録するためのアプリケーション・コードの追加」を参照してください。

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

あるアプリケーションは、機能フローのコンテキストでビジネス関連アクティビティを記録する必要があります。具体的には、ユーザーおよび特定の時間間隔内にそれらのユーザーが実行したビジネス・アクションを記録する必要があります。

このユースケースで説明する設定は、ドメイン内のすべてのアプリケーションおよびコンポーネントに当てはまります。

このユースケースでは、アプリケーションが次の操作を行う必要があります。

- ビジネス・ニーズに基づいて独自の監査イベントを作成する

- データ・リポジトリを監査するための実行時属性とともにビジネス・アクティビティを記録する

- 監査イベントから監査レポートを生成する

- 実行時監査ポリシーを管理する

- 必要に応じて監査イベント定義を変更する

このユースケースでは、次の機能を使用します。

- アプリケーションがビジネス機能領域(監査カテゴリとして)、ビジネス・アクティビティ(カテゴリ内の監査イベントとして)、および各カテゴリ内に属性を定義することを可能にする

- デプロイメント時のアプリケーションの登録、監査定義の更新、デプロイメント後のアプリケーションの登録解除

- Fusion Middleware ControlまたはWSLTスクリプトを使用した監査アーティファクトの管理

詳細は、次の各項を参照してください。

- CAFへの統合については、第28.4項「監査フレームワークへのアプリケーションの統合」を参照してください。

- アプリケーションの登録については、第28.6項「登録サービスへのアプリケーションの登録」を参照してください。

- 監査イベントの記録については、第28.7項「監査イベントを記録するためのアプリケーション・コードの追加」を参照してください。

- component_events.xmlファイルの例については、第28.5項「監査定義ファイルの作成」を参照してください。

- 監査ポリシーの管理については、第13.3項「監査ポリシーの管理」を参照してください。

19.2.6 アイデンティティ伝播

アイデンティティ伝播ユースケースは次のとおりです。

- 実行ユーザー・アイデンティティの伝播: SOAPを介したWebサービスへの実行ユーザー・アイデンティティの伝播。

- ユーザー・アイデンティティの伝播: SOAPを介したWebサービスへのユーザー・アイデンティティの伝播。

- 別のドメインへのアイデンティティの伝播: 別のWebLogicドメインへのユーザー・アイデンティティの伝播。

- HTTPを介したアイデンティティの伝播: HTTPを介したユーザー・アイデンティティの伝播。

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

コンテナ内のあるクライアント・アプリケーションは、SOAPを介してWebサービスに実行ユーザー・アイデンティティを伝播する必要があります。Webサービスは、同じドメイン内または別のドメイン内の別の管理対象サーバー上で実行されています。

このユースケースでは、現在の実行ユーザー・アイデンティティをSOAPを介してWebサービスに伝播する必要があります。

このユースケースを実現するために、主にOracle Web Services Manager (OWSM)の機能を使用します。

OWSMの詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドの第4章「Oracle Fusion MiddlewareにおけるOracle WSMの再設計の詳細」を参照してください。

SOAPを介したアイデンティティの伝播の詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドの第11章「ポリシーの構成」を参照してください。

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

コンテナ内のあるクライアント・アプリケーションは、SOAPを介してWebサービスにユーザー・アイデンティティ(実行ユーザー・アイデンティティではない)を伝播する必要があります。伝播するアイデンティティはOPSSセキュリティ・ストアに格納されています。

このユースケースでは、現在の実行ユーザーとは別のユーザーのアイデンティティを、SOAPを介してWebサービスに伝播する必要があります。

このユースケースでは、次の機能を使用します。

- 資格証明が格納され、アプリケーションがPasswordCredentialとして伝播する必要がある特定のアイデンティティを取得するOPSSセキュリティ・ストア

- アイデンティティをフェッチし、リモートWebサービスに伝播するOracle Web Services Managerの機能

このユースケースの詳細は、Oracle Fusion Middleware Webサービスのためのセキュリティおよび管理者ガイドの第9章「ポリシー・セットの作成および管理」を参照してください。

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

WebLogicドメインのコンテナ内のあるクライアント・アプリケーションは、ユーザー・アイデンティティ(OPSSセキュリティ・ストアに格納されている)を、RMIを介して別のWebLogicドメインに伝播する必要があります。

このユースケースの詳細は、WebLogic Serverドメイン間の信頼の有効化に関する項を参照してください。

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

WebLogicドメインまたはWASセルのコンテナ内のあるクライアント・アプリケーションは、HTTPを介してアイデンティティを伝播する必要があります。

このユースケースの要件および詳細は、「HTTPを介したアイデンティティの伝播」を参照してください。

19.2.7 管理

管理ユースケースは次のとおりです。

- 中央ストアが必要なアプリケーション: アプリケーションに、セキュリティ・アーティファクトを管理するためのアーティファクトの中央リポジトリが必要です。

- カスタム管理ツールが必要なアプリケーション: アプリケーションに、外部化したセキュリティ・アーティファクトの中央リポジトリを管理するためのカスタム・ツールが必要です。

- 複数のサーバー環境で実行されるアプリケーション: アプリケーションは、複数ノードのサーバー環境でセキュリティ・アーティファクトを変更する必要があります。

19.2.7.1 中央ストアが必要なアプリケーション

あるアプリケーションには、ポリシー、資格証明、監査構成、信頼およびキーを格納する中央リポジトリ(OPSSセキュリティ・ストア)、およびその中央リポジトリを管理するためのツール・セットが必要です。

このユースケースでは、次の機能を使用します。

- OPSSセキュリティ・ストア

- Fusion Middleware Controlを使用したセキュリティ・アーティファクトの管理

- WLSTスクリプトを使用したセキュリティ・アーティファクトの管理

詳細は、次の各項を参照してください。

- OPSSセキュリティ・ストアについては、第8.1項「OPSSセキュリティ・ストアの概要」を参照してください。

- セキュリティ・アーティファクトの管理については、次の各項を参照してください。

- 第9.2項「Fusion Middleware Controlを使用したポリシーの管理」

- 第9.3項「OPSSスクリプトによるアプリケーション・ポリシーの管理」

- 第10.4項「Fusion Middleware Controlを使用した資格証明の管理」

- 第10.5項「OPSSスクリプトによる資格証明の管理」

- 第11章「キーストア・サービスでのキーと証明書の管理」

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

あるアプリケーションには、アプリケーションのビジネスに意味のあるコンテキストで、外部化したセキュリティ・アーティファクトを管理するためのカスタム・ツールが必要です。

このユースケースでは、アプリケーションに意味のあるコンテキストでOPSSセキュリティ・ストア内のセキュリティ・アーティファクトを表示および管理するためのOPSS APIへのコールを含む、カスタム・グラフィカル・ユーザー・インタフェースを構築する必要があります。

このユースケースでは、次の機能を使用します。

- OPSS APIを使用したセキュリティ・アーティファクトの管理

詳細は、次の各項を参照してください。

- OPSS APIを使用して、セキュリティ・アーティファクトを管理するために必要な操作の一部を実装する方法を示すコード・サンプルについては、「カスタム・グラフィカル・ユーザー・インタフェース」を参照してください。

- OPSS APIのリストについては、付録H「リファレンス」を参照してください。

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

複数のサーバー・インスタンスが複数のマシンに分散されているWebLogicドメイン内で実行されているアプリケーションが、セキュリティ・アーティファクトを変更する必要があります。変更は、どこで実行されているかにかかわらず、アプリケーションのすべてのコンポーネントに反映されなければなりません。

このユースケースでは、次の機能を使用します。

- 管理サーバー上でセキュリティ・アーティファクトの変更が開始された場合の変更の伝播。管理対象サーバー・ノード上のデータは、キャッシュ・ポリシーに基づいてリフレッシュされます。

- MBean APIまたは管理APIを使用したセキュリティ・アーティファクトの変更。

詳細は、次の各項を参照してください。

- 複数のサーバー・ノードについては、第8.2.1項「複数ノード・サーバー環境」を参照してください。

- OPSSサービスおよびMBeanについては、付録Eの「MBeanを使用したOPSSサービスの構成」を参照してください。

19.2.8 統合

統合ユースケースは次のとおりです。

- 複数のドメインで実行されるアプリケーション: セキュリティ・アーティファクトの単一のリポジトリを共有する複数のWebLogicドメイン。

19.2.8.1 複数のドメインで実行されるアプリケーション

ある製品では、複数のWebLogicドメインを実行する必要があり、これらのドメインは単一の中央OPSSセキュリティ・ストアを共有します。

このユースケースでは、次の機能を使用します。

- 1つのセキュリティ・ストアを共有する複数のドメインに対するOPSSのサポート

詳細は、次の各項を参照してください。

- 資格証明ストアを共有するドメインについては、第10.2項「資格証明の暗号化」を参照してください。

- reassociateSecurityStoreを使用して既存のOPSSセキュリティ・ストアに結合する方法については、第9.3.29項「reassociateSecurityStore」を参照してください。

19.3 ユースケースの詳細

この項では、次のユースケースについて詳しく説明します。

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

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

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

この項では、OPSSトラスト・サービスとHTTPプロトコルを使用して、別のコンテナおよびドメインにアイデンティティを伝播する方法について説明します。

- OPSSトラスト・サービス

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

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

19.3.1.1 OPSSトラスト・サービス

OPSSトラスト・サービスにより、トークンを提供および検証することによって、HTTP対応のアプリケーションにアイデンティティを伝播できます。OPSSトラスト・サービスは、次のプラットフォームでのみ使用可能なアサーション・プロバイダを使用します。

- Oracle WebLogic Application Server: IDアサーション・プロバイダ

- IBM WebSphere Application Server: Trust Asserter Interceptor (TAI)

この項のシナリオの説明ではWebLogicドメイン上で実行されるアプリケーションを使用していますが、これらのシナリオはWebSphereセル上で実行されるアプリケーションにも当てはまります。アサーション・プロバイダの構成を除き、その他すべての構成およびサンプルはどちらのプラットフォームにも共通です。構成プロパティについては、第F.2.6項「トラスト・サービスのプロパティ」を参照してください。

WebLogicドメインまたはWebSphereセルごとに1つのアサーション・プロバイダが存在します。キーストアには、デジタル証明書、秘密鍵および信頼できるCAの証明書が格納されます。キーストアによって使用される記憶域サービスはJKSです。

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

HTTPコールを使用したアイデンティティ伝播は、一般的に次のように実行されます(図19-2を参照)。

1. Domain1のクライアント・アプリケーションが、Domain1のOPSSトラスト・サービス・インスタンスに対して、認証されたユーザーに対するトークンをリクエストします。

2. トラスト・サービスがDomain1のキーストアにアクセスし、トークンをクライアント・アプリケーションに発行します。

3. クライアント・アプリケーションがトークンをHTMLヘッダー内にエンコードし、HTTPリクエストをDomain2のサーブレット・アプリケーションにディスパッチします。Domain 2のアサーション・プロバイダがリクエストをインターセプトし、トークンを抽出します。

4. アサーション・プロバイダがDomain2のOPSSトラスト・サービス・インスタンスに対して、そのトークンの検証をリクエストします。

5. トラスト・サービスがトークンを検証するためにDomain2のキーストアにアクセスし、レスポンスを返します。

6. 検証が成功したとみなし、アサーション・プロバイダはアサートされたアイデンティティを使用して、リクエストをサーブレット・アプリケーションに送信します。

7. サーブレット・アプリケーションが、クライアント・アプリケーション・リクエストに対するHTTPレスポンスを送信します。

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

この項の残りでは、次の各項で、前述のシナリオが機能するために必要な構成について説明します。

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

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

19.3.1.2.1 単一ドメイン・シナリオ

このシナリオでは、クライアント・アプリケーションとサーブレット・アプリケーションは同じトラスト・サービス・インスタンスを使用して、トークンを発行および検証します。次のコードおよび構成サンプルは、同じドメイン内で実行されているサンプルのクライアント・アプリケーションとサーブレット・アプリケーションを示しています。

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

次のサンプルはクライアント・アプリケーションに対するコードです。コードをコンパイルするには、クラスパスにjps-api.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());

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

次のコマンドは、ドメイン名がjrfServer_adminである場合のドメイン・キーストアの作成方法を示しています。ドメインの作成は、default-keystore.jksファイルが生成されることにより確認できます。

JAVA_HOME/bin/keytool -genkeypair
-alias jrfServer_admin
-keypass welcome
-keyalg RSA
-dname "CN=jrfServer_admin,O=Oracle,C=US"
-keystore default-keystore.jks
-storepass password

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 >

CSFの構成

キーストアを開くために使用するマップ/キー・ペアと、トークンを発行するために使用する別のマップ/キー・ペアを作成します。次のコマンドは、OPSSスクリプト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")

OPSSスクリプトcreateCredの詳細は、第10.5項「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を停止してから再起動する必要があります。

サーブレット・コード

次のサンプルは、サーブレットがアサートされたユーザー名を取得する方法を示しています。

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();
}

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>

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トラスト・サービス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ファイルに変更を加えた場合、更新を有効にするにはサーバーを再起動する必要があります。

WebSphere Trust Asserter Interceptorの構成

この項目の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドのTrust Association Interceptorの構成に関する項を参照してください。

19.3.1.2.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
-alias jrfServer_admin.cer
-keystore default-keystore.jks
-storepass password

2. 次のコマンドに示すように、証明書をDomain2のキーストアにインポートします。渡す別名はステップ1でエクスポートに使用した別名と同じである必要があります。クライアント側で発行者名を上書きした場合は、その発行者名を別名として使用します。

JAVA_HOME/bin/keytool -importcert
-alias jrfServer_admin
-keypass welcome
-keyalg RSA
-dname "CN=jrfServer_admin,O=Oracle,C=US"
-keystore default-keystore.jks
-storepass password

3. OPSSスクリプトcreateCredを次のように使用して、Domain2のキーストア・パスワードを(Domain2の)資格証明ストアで設定します。

createCred(map="oracle.wsm.security", key="keystore-csf-key", user="keystore", password="password")

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

このシナリオでは、アプリケーションはHTTPプロトコルまたはSOAPプロトコルのいずれかを使用し、ドメイン内のすべてのアプリケーションが同じプロトコルを使用するわけではありません。このようなシナリオでは、HTTPプロトコルで使用されるトラスト・サービスとOracle Web Services Managerで使用されるSOAPサービスで、キーストアを共有できます。ただしこの場合にトラスト・サービスが機能するには、次の各項で説明するように、jps-config.xmlファイルで特別な構成が必要になります。

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

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

19.3.1.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>

19.3.1.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>

次のスニペットは、別名が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>

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

このユースケースでは、たとえばポリシーを管理するためにカスタム・グラフィカルUIを実装する場合などに必要な操作の一部を示しています。紹介するサンプルはOPSS APIを使用し、次の操作について説明します。

- アイデンティティ・ストア内のユーザーの問合せ。

- ポリシー・ストア内のアプリケーション・ロールの問合せ。

- ユーザーとグループからアプリケーション・ロールへのマッピングの問合せ。具体的には、ユーザーにマップされているすべてのアプリケーション・ロールを特定します(ユーザーとグループからアプリケーション・ロールへのマッピングは多対多関係です)。

- ユーザーとグループからアプリケーション・ロールへのマッピングの作成、読取り、更新および削除。

このユースケースは次のことを前提としています:

- アイデンティティ・ストアがOID LDAPベースのストアであること。

- ポリシー・ストアがOID LDAPベースのストアであること。

- アイデンティティ・ストアに次のユーザーとグループの階層(エンタープライズ・ロール)が含まれること。

- ユーザー: Mary、John、TomおよびHelen。

- グループ: IT、TrainingおよびDevelopment。

- グループTrainingおよびDevelopmentはグループITのメンバーです。

- ユーザーMaryはグループTrainingのメンバーです。

- ユーザーTomとJohnはグループDevelopmentのメンバーです。

- ポリシー・ストアには、次のアプリケーション・ポリシーおよびアプリケーション・ロールの階層が含まれます。

- アプリケーション・ポリシー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にマップされています。

図19-3に、このユースケースの前提となる、アプリケーション・ロールの階層、ユーザーとグループ、およびアプリケーション・ロールからユーザーとグループへのマッピングを示します。

図19-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: アプリケーション・ロールからグループへのマッピングの削除。

19.3.2.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;

19.3.2.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();
}

19.3.2.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();

}

19.3.2.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();
}

19.3.2.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();
}

19.3.2.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());
}
}
}

19.3.2.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();
}

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

この項では、アプリケーションのセキュリティがたどるフェーズについて説明します。ここではアプリケーションがADFを使用し、Oracle JDeveloper環境を使用していることを前提として説明します。

アプリケーションのセキュリティ・ライフ・サイクルのフェーズとは、開発フェーズ、デプロイメント・フェーズ、および管理フェーズです。関係する担当者は製品マネージャ、アプリケーション設計者、アプリケーション開発者、およびアプリケーション・セキュリティ管理者です。タスクの概要については、「各フェーズの担当者別タスクの概要」を参照してください。

19.4.1 開発フェーズ

開発フェーズでは、開発者によってOracle Fusion Middlewareで使用可能な広範なセキュリティ・オプション機能がアプリケーションと連携するように設計されます。開発者はOracle JDeveloper、組込みのADFフレームワーク、およびOracle WebLogicサーバーで公開される豊富なセキュリティ・サービスを利用できます。これらのコンポーネントはすべてOPSSを基盤としています。OPSSによってアプリケーションの使用期間全体にわたってセキュリティ・アプローチの整合性が保持されることが保証されます。

通常、開発者はADFセキュリティ・ウィザード(認可エディタ)および式言語エディタを使用します。これらはすべてOracle JDeveloperにあります。さらに、必要に応じて、OPSS APIを使用してより複雑なセキュリティ・タスクを実装することもできます。これによってアプリケーションの一部で宣言によるセキュリティを使用し、別の部分でプログラムによるセキュリティを使用でき、また、いずれの場合も開発および実行時環境で使用可能なセキュリティ機能を利用できます。

アプリケーション開発者は、アプリケーションの保護に必要な複数のアプリケーション権限およびロール(ポリシー・シード・データ)も定義します。このポリシー・シード・データは、アプリケーションのソース・コードとともにソース・コントロール・システムに格納されます。

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

通常、開発後のアプリケーションは本番環境にデプロイする前にステージング環境でテストされます。本番環境では、アプリケーションと実行時サービスの両方が他のセキュリティ・コンポーネントと統合されます。このコンポーネントは、ユーザー・ディレクトリ、シングル・サインオン・システム、ユーザー・プロビジョニング・システム、監査機能などです。一般にセキュリティ・サービスはフェーズとともに変化します。たとえば、開発時は開発者がファイルまたはOracleウォレットを利用してユーザーの資格証明を格納しますが、本番環境では資格証明はLDAPディレクトリ(OPSSセキュリティ・ストア)に格納されます。

通常デプロイメント・フェーズでは、管理者がポリシー・シード・データを本番ポリシー・ストア(OPSSセキュリティ・ストア)に移行し、アプリケーション・ロールをエンタープライズ・グループにマッピングして、アプリケーション・セキュリティ・ポリシーを施行します。

19.4.3 管理フェーズ

管理フェーズは、アプリケーションが本番環境にデプロイされたときに開始します。このフェーズではアプリケーション管理者またはエンタープライズ・セキュリティ管理者が日常的なセキュリティ・タスクを管理します。このタスクにはアプリケーション・リソースへのユーザー・アクセス権限の付与、監査ログの確認、セキュリティ・インシデントへの対応、セキュリティ・パッチの適用などが含まれます。

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

次の各表はセキュリティ・ライフ・サイクルのフェーズごとに、担当者別に主要な担当任務をまとめたものです。図19-4は、基本的なフローを示します。

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

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

フェーズ

タスク

開発

機能のセキュリティ要件およびデータのセキュリティ要件に基づいて高度なアプリケーション・ロールを定義します。

初期のファイルベースのアプリケーション・ポリシー・ストアを移入します(jazn-data.xml)。

デプロイメント

QAチームのテストに使用する実際のカスタマ・シナリオを定義します。

管理

アプリケーション・ポリシーのカスタマイズ要件を理解し、特定します。

垂直産業向けのテンプレートの定義を検討します。

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

フェーズ

タスク

開発

特にOracle JDeveloperのツールおよびプロセスを使用して、アプリケーションを構築し、アプリケーション・ロールやパーミッションなどのセキュリティ・アーティファクトを作成します。

FND権限を使用して、データレベルのセキュリティを指定します。

ローカル・ポリシー・ストア使用し、サンプルのユーザーとロールでアプリケーションをテストします。

デプロイメント

QAチームによる実行時の問題のトラブルシューティングおよび解決を支援します。

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

フェーズ

タスク

デプロイメント

デプロイメント・サービスを使用して、jazn-data.xmlのセキュリティ・シード・データを本番ポリシー・ストアに移行します。

アプリケーション・ロールをエンタープライズ・グループにマッピングして、セキュリティ・ポリシーの適用を可能にします。

管理

必要に応じてソフトウェアにパッチおよびアップグレードを適用します。

企業のユーザーおよびアプリケーション・ロールの階層は時間とともに変化するため、それに応じてユーザーとロールを管理します。

アプリケーションにパッケージ化されたポリシーを管理し、新たなポリシーを作成します。

IAMインフラストラクチャとの統合および管理を行います。

19.5 付録: コードおよび構成例

この項では、このガイドの他の章に記載されている、ほとんどのコード・サンプルと構成サンプルのリストおよび完全なコード例を示します。

- コード例

- 構成例

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

19.5.1 コード例

次のリストは、一般的なセキュリティ関連のプログラミング・タスクおよび実装方法を示すサンプル・コードへのリンクです。

- LDAPアイデンティティ・ストアの問合せ: 第7.4項「プログラムによるアイデンティティ・ストアの問合せ」を参照してください。

- アプリケーション・ロールの問合せ、およびユーザーとグループからアプリケーション・ロールへのマッピングの問合せ: 「カスタム・グラフィカル・ユーザー・インタフェース」を参照してください。

- メソッドisUserInRoleの呼出し: 第20.2.2.2項「プログラムによる認可」を参照してください。

- ポリシーの管理: 第20.3.2項「ポリシーの管理」を参照してください。

- ポリシーの確認: 第20.3.3項「ポリシーの確認」を参照してください。

- クラスResourcePermissionの使用方法: 第20.3.4項「クラスResourcePermission」を参照してください。

- Java SEアプリケーションでの認証のためのアイデンティティ・ストア・ログイン・モジュールの使用方法: 第22.2.3.2項「認証のためのアイデンティティ・ストア・ログイン・モジュールの使用」を参照してください。

- Java SEアプリケーションでのアサーションのためのアイデンティティ・ストア・ログイン・モジュールの使用方法: 第22.2.3.3項「アサーションのためのアイデンティティ・ログイン・モジュールの使用」を参照してください。

19.5.2 構成例

次のリストは、一般的なセキュリティ関連の構成タスクおよびサンプル構成へのリンクです。

- OAM SSOプロバイダの構成: 第8.7.3.3項「OAM構成の例」を参照してください。

- リソース・パーミッションの構成: 第20.3.4項「クラスResourcePermission」を参照してください。

- サーブレット・フィルタおよびEJBインターセプタの構成: 第21.1項「サーブレット・フィルタとEJBインターセプタの構成」を参照してください。

- migrateSecurityStoreでの構成: 第6.5.2.1項「ポリシーの手動による移行」および第6.5.2.2項「資格証明の手動による移行」を参照してください。

- LDAPアイデンティティ・ストアの構成: 第7.3.2.6項「構成ファイルの例」および第22.2.2「Java SEアプリケーションでのLDAPアイデンティティ・ストアの構成」を参照してください。

- Java SEアプリケーションでのポリシーと資格証明ストアの構成: 第23.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。

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

ezshareは、セキュリティがOPSSに統合され、パーミッションベースの権限付与を使用し、Oracle Networkからダウンロード可能なJava EEアプリケーションの完全な例です。この例を見つけるには、キーワードezshareで検索してください。

20 OPSSポリシー・モデル

この章では、OPSSポリシーおよび認可モデルについて説明します。内容は次のとおりです。

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

- 認可の概要

- JAAS/OPSS認可モデル

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

OPSSポリシー・モデルおよび使用されるセキュリティ・アーティファクトの詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドを参照してください。

20.2 認可の概要

この項では、Java EEとJAASのモデルで使用可能な認可を比較検討しています。この項の内容は次のとおりです。

- 認可について

- Java EE認可モデル

- JAAS認可モデル

20.2.1 認可について

Java 2ポリシーは、特定の場所からロードされた署名付きコードに付与されるパーミッションを指定します。JAASポリシーは、オプションのプリンシパル・リストを指定できるようにすることで、Java 2の権限を拡張します。これにより、特定の場所からロードされた(多くの場合は署名付きの)コードにのみパーミッションが付与され、このリストにあるプリンシパルで表されるユーザーによって実行されます。

ポリシー・ストアは、システムおよびアプリケーションに固有のポリシーとロールを格納するリポジトリです。アプリケーション・ロールは、アプリケーション固有のエンタープライズ・ユーザーおよびグループ(管理ロールなど)に付与(マップ)できます。ポリシーでは、これらのロール、グループまたはユーザーにプリンシパルとしてパーミッションを付与できます。

ポリシー関連のセキュリティ・アーティファクトの詳細は、第3章「ポリシー・ストアの基本」を参照してください。

アプリケーションでは、認可の適用をコンテナに委任できるほか、checkPermission、checkBulkAuthorization、getGrantedResourcesなどのメソッドのコールによってポリシー確認を自身で適用する実装も可能です。

APIコールを使用したポリシー確認の詳細は、「ポリシーの確認」を参照してください。

20.2.2 Java EE認可モデル

Java EE認可モデルでは、ロール・メンバーシップを使用して、EJBメソッドおよびURLで参照するWebリソースへのアクセスを制御します。ポリシーによってユーザーとロールにパーミッションが割り当てられ、ポリシーがコンテナで適用されてリソースが保護されます。

Java EEモデルでは、次のいずれかの方法で認可が実装されます。

- 宣言的。この方法では、認可ポリシーがデプロイメント・ディスクリプタで指定されます。コンテナはデプロイメント・ディスクリプタから認可ポリシーを読み取って実施します。認可を実施するための特別なアプリケーション・コードは必要ありません。

- プログラム的。この方法では、アプリケーション・コードで認可ポリシーを確認します。このコードによって、特定のコード・セクションの実行に適したパーミッションがサブジェクトにあるかどうかを確認します。サブジェクトに適切なパーミッションが与えられていない場合、コードは例外をスローします。

表20-1は、各方法の長所と短所を示しています。

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

認可のタイプ

長所

短所

宣言

コーディングが不要。デプロイメント・ディスクリプタのみを変更すればよいため、更新が簡単。

認可のレベルが大まかであり、URLレベルまたはメソッド・レベル(EJBの場合)で指定されます。

プログラム

アプリケーション・コードで指定され、よりきめ細かいレベルでコードを保護できます。

コード変更や再コンパイルを伴うため、更新は容易ではありません。

コンテナは、その内部で稼働中のアプリケーションに対して、宣言的およびプログラム的という2つの方法で認可を提供できます。次の各項ではこれらの方法を説明して例を示します。

- 宣言による認可

- プログラムによる認可

- Java EEコードの例

20.2.2.1 宣言による認可

宣言的な認可では、URLベースのリソース(サーブレットやページなど)やEJBのメソッドに対するアクセスを制御できます。

宣言的な認可を構成する基本手順は、次のとおりです。

1. 標準のデプロイメント・ディスクリプタで、保護するリソース(Web URL、EJBメソッドなど)と、そのリソースへのアクセス権を持つ論理ロールを指定します。
または、Java EE 1.5は注釈をサポートしているため、デプロイメント・ディスクリプタではなくコード注釈を使用します。

2. 固有デプロイメント・ディスクリプタ(web.xmlなど)では、ステップ1で定義した論理ロールをエンタープライズ・グループにマップします。

詳細は、Oracle Fusion Middleware Enterprise JavaBeans Oracle Containers for Java EE開発者ガイドの章「セキュリティ・サービスの使用」を参照してください。

20.2.2.2 プログラムによる認可

プログラム的な認可では、宣言的な方法よりもきめ細かい認可を実現できます。プログラム的な認可では、メソッドisUserInRole(サーブレットおよびJSPの場合)またはメソッドisCallerInRole(EJBの場合)をアプリケーションのコードから呼び出す必要があります。これらはどちらも標準のJava APIに用意されています。

これらのメソッドは、認可の決定に関してロール・メンバーシップにある程度は依存しますが、これらの使用により、ユーザーは、リソース・レベル(EJBのメソッドまたはURL)のアクセス制御に限定されることがないため、よりきめ細かく認可の決定を制御できるようになります。

20.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>");
}
}

20.2.3 JAAS認可モデル

JAAS認可ではパーミッションを使用しますが、ロールの概念も使用できます。認可ポリシーによって、パーミッションがサブジェクト(ロール、グループまたはユーザー)にバインドされ、さらに必要に応じてソース・コードにもバインドされます。ロールの付与は、addPrincipalsToAppRoleのコールで実現します。

パーミッションはAccessControllerのコールによって評価されます。このモデルでは、リソースをきめ細かく制御できます。

このモデルでは、認可ポリシーで次の情報が指定されます。

- アプリケーション・ロールおよびエンタープライズ・グループ。

- ユーザー、グループおよびコード・ソースに付与されるパーミッション。ユーザーおよびグループの場合は、これによってアクセスが許可されるユーザーまたはグループのメンバーが決定されます。コード・ソースの場合は、これによって、コードが実行できるアクションが決定されます。

このモデルを使用してプログラミングする場合、機密性の高いコード行の前に、現在のユーザーまたはロールがそのコードにアクセスするための適切なパーミッションを付与されているかどうかを確認するコールを記述します。ユーザーが適切なパーミッションを持っている場合は、コードが実行されます。適切なパーミッションが与えられていない場合、コードは例外をスローします。

JAASの標準パーミッションの詳細は、http://java.sun.com/Java SE/6/docs/technotes/guides/security/permissions.htmlを参照してください。

20.3 JAAS/OPSS認可モデル

JAASおよびOPSS認可では、クラスを環境にロードして実行するときに、そのクラスで実行できる操作を制御することが基本になっています。

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

- リソース・カタログ

- ポリシーの管理

- ポリシーの確認

- クラスResourcePermission

20.3.1 リソース・カタログ

OPSSは、ファイルベース、LDAPベース、およびDBベースのポリシー・ストア内のリソース・カタログの仕様およびランタイム・サポートに対応します。

リソース・カタログの使用には次の利点があります。

- 判読可能な用語でポリシーおよび保護アーティファクトが記述されます。

- アプリケーション・ソース・コードに関係なく、またこれらのコードに関する知識を必要とせずに、ポリシーを定義し、変更できます。

- 保護アーティファクトを参照および検索できます。

- 後で認可ポリシーで使用できるビルディング・ブロック(権限またはパーミッションのセット)に保護アーティファクトをグループ化できます。

20.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);

20.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など)が不正確な値を返す場合があります。

20.3.3.1 メソッドcheckPermissionの使用方法

Oracle Fusion Middlewareは、クラスjava.security.AccessControllerおよびoracle.security.jps.util.JpsAuthのメソッドcheckPermissionの使用をサポートしています。

クラスJpsAuthのcheckPermissionを使用することをお薦めします。これは、このクラスのほうがデバッグ・サポートとパフォーマンスにおいて優れており、監査もサポートされるためです。

静的メソッドAccessController.checkPermissionは、デフォルトのアクセス制御コンテキスト(スレッド作成時に継承されるコンテキスト)を使用します。その他のコンテキストでパーミッションを確認するには、特定のAccessControlContextインスタンスでインスタンス・メソッドcheckPermissionをコールします。

次の表に示すように、メソッドcheckPermissionはJAASモード(第21章「サーブレット・フィルタとEJBインターセプタの構成」を参照)の値に従って動作します。

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

JAASモードの設定

checkPermission

オフまたは未定義

有効なセキュリティ・ポリシーに基づくコードベースのセキュリティを実施します。サブジェクトベースのセキュリティに対するプロビジョニングはありません。

doAs

doAsブロックを使用して作成されたアクセス制御コンテキストを使用して、コードベースおよびサブジェクトベースのセキュリティを組み合せて適用します。

doAsPrivileged

NULLアクセス制御コンテキストを使用してサブジェクトベースのセキュリティを適用します。

subjectOnly

パーミッションの評価時に、プリンシパルにかかわる権限付与のみが考慮されます(コードベースにかかわる権限付与は無視されます)。

注意:

doAsブロック内でcheckPermissionがコールされてパーミッション・チェックのコールが失敗した場合に、失敗した保護ドメインを表示するにはシステム・プロパティ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>

<role-categories>
<role-category>
<name>MyAppRoleCategory</name>
<display-name>MyAppRoleCategory display name</display-name>
<description>MyAppRoleCategory description</description>
</role-category>
</role-categories>

<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();
}
}
}

20.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を設定する必要があります。

20.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 でも、アプリケーションを実行しているドメインに構成したポリシー・ストア・ストライプを、そのアプリケーションから認識できることが前提となっています。

checkBulkAuthorizationでは、ポリシー・ストアにリソースが存在している必要はありません。

20.3.3.4 メソッドgetGrantedResourcesの使用方法

メソッドgetGrantedResourcesには、実行時の認可問合せが用意されているので、特定のサブジェクトに付与されているリソース・アクションをこの問合せから得ることで、そのサブジェクトに付与されているすべてのリソースをフェッチできます。このメソッドでは、(直接またはパーミッション・セットから間接的に)リソース・タイプに関連付けられているパーミッションのみが返されます。また、このメソッドは、ポリシー・ストアがLDAPベースの場合にのみ使用できます。

20.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を拡張するクラス。

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

この章では、Oracle ADFセキュリティを使用せずにOPSSを使用するJava EEアプリケーションでお薦めする手動による構成とパッケージ化について説明します。ただし、一部のトピックは、Oracle ADFアプリケーションにも当てはまります。

ここで示す情報は、Oracle JDeveloper環境の外部でJava EEアプリケーションを構成し、パッケージ化する開発者を対象としています。

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

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

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

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

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

開発時、デプロイ時、実行時およびデプロイ後のアプリケーション管理に関係するファイルは、次のとおりです。

- 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ファイル内)

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

OPSSはサーブレット・フィルタJpsFilterとEJBインターセプタJpsInterceptorを備えています。前者はWARファイルでパッケージ化されるファイルweb.xmlで構成され、後者はJARファイルでパッケージ化されるファイルejb-jar.xmlで構成されます。アプリケーションMbeansがアクセスするストライプをファイルweb.xmlで構成する方法も、OPSSによって提供されます。詳細は、「アプリケーションMbeansのアプリケーション・ストライプの構成」を参照してください。

これらはいずれもWebLogicとWebSphereで利用可能です。利用できる構成は、次に示すように、サーバー・プラットフォームに応じてやや異なります。

WebLogicでは、JpsFilterはデフォルトのパラメータ値で自動的に設定され、そのまますぐに使用できるため、デプロイメント・ディスクリプタで明示的に構成する必要はありません。デフォルト値以外の値を設定する場合にのみ手動構成が必要です。JpsInterceptorは手動で構成する必要があります。

WebSphereでは、JpsFilterとJpsInterceptorをいずれも手動で構成する必要があります。

注意:

Oracle ADFアプリケーションに必要なサーブレット・フィルタ(JpsFilter)およびEJBインターセプタ(JpsInterceptor)の構成は、Oracle JDeveloperによって自動的に挿入されます。

この項で説明している手動による構成は、次で説明しているOPSS機能をOracle JDeveloper環境の外部で使用してJava EEアプリケーションをパッケージ化または構成する場合にのみ必要です。

OPSSでは、MBeansが使用するアプリケーション・ストライプの指定が可能です。詳細は、「アプリケーション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の動作を制御する方法の詳細は、第20.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>

21.1.1 インターセプタ構成構文

次の要件と指定の特性は、JpsInterceptorの場合に構成されるすべてのパラメータに適用されます。

- パラメータの設定では、そのタイプの指定(要素<env-entry-type>内)が必要です。

- パラメータの設定には、要素<injection-target>が必要であり、これをインターセプタのクラスと同じクラスに指定する必要があります(要素<injection-target-class>内)。また、ドットをアンダースコアに置換した文字列として再書き込みしたパラメータ名も必要です(要素<injection-target-name>内)。

- インターセプタのEJBへのバインディングは、EJB名とインターセプタのクラスによって指定します。つまり、インターセプタは、名前ではなくそのクラスによって参照されます。

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

次の表は、JpsFilterおよびJpsInterceptorによって使用されるパラメータの説明をまとめたものです。

表21-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モードを設定します。

21.1.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>

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

注意:

Oracle JDeveloperを使用している場合、このツールによって適切なクラスが選択されます。したがって、次に説明する構成は、ポリシーがOracle JDeveloper環境外で入力された場合にのみ必要です。

アプリケーション・ロールのメンバー内で指定されるクラスは、他のアプリケーション・ロールのクラスか、次のいずれかにする必要があります。

weblogic.security.principal.WLSUserImpl
weblogic.security.principal.WLSGroupImpl

次のフラグメントは、エンタープライズ・グループの指定におけるこれらのクラスの使用を示しています(太字の部分)。

重要:

アプリケーション・ロール名では、大文字小文字が区別されません(次のサンプルのapp_operatorなど)。

エンタープライズ・ユーザーおよびグループ名では、大文字小文字が区別されます(次のサンプルのDevelopersなど)。

大文字小文字の区別に関する情報は、第L.4項「パーミッションの付与または取消の失敗 - 大文字と小文字の不一致」を参照してください。

<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>

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

この項では、WebLogic Application ServerまたはWebSphere 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ファイルにパッケージ化してデプロイする必要があります。

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

アプリケーション・ポリシーは、ファイルjazn-data.xmlで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。EARファイルには、ゼロ個以上のWARファイルを含めることができますが、ポリシーはEARディレクトリにあるこのXMLファイルでのみ指定できます。WARファイルで1つのコンポーネントに対して特定のポリシーを指定するには、前述の指定のようにそのコンポーネントを独自のjazn-data.xmlファイルで別個のEARファイルにパッケージ化する必要があります。他のポリシー・パッケージの組合せは、このリリースではサポートされていません。最上位のjazn-data.xml以外のポリシー・ファイルは無視されます。

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

アプリケーションの資格証明は、cwallet.ssoという名前のファイルで定義します。このファイルをアプリケーションに追加するためにサポートされている唯一の方法は、EARファイルのディレクトリMETA-INFでこのファイルをパッケージ化することです。EARファイルには、ゼロ個以上のWARファイルを含めることができますが、資格証明はそのEARディレクトリにあるcwallet.ssoファイルでのみ指定できます。WARファイルで1つのコンポーネントに対して特定の資格証明を指定するには、前述の指定のようにそのコンポーネントを独自のcwallet.ssoファイルで別個のEARファイルにパッケージ化する必要があります。他の資格証明パッケージの組合せはこのリリースではサポートされていません。最上位のcwallet.sso以外の資格証明ファイルは無視されます。

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

この項では、Oracle JDeveloper環境の外部で開発されたJava EEアプリケーションのために開発者が手動で実行するいくつかの構成について説明します。この項の内容は次のとおりです。

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

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

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

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

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

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

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

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

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

注意:

WebLogic Serverにデプロイしたアプリケーションのアプリケーション・ポリシーと資格証明の移行を無効にするには、システム・プロパティjps.deployment.handler.disabledを使用します。

このシステム・プロパティをTRUEに設定すると、すべてのアプリケーションで、デプロイメント時のポリシーおよび資格証明の移行が無効になります。アプリケーション・ファイルweblogic-application.xmlにあるアプリケーション個別の設定は無視されます。

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

デプロイでのアプリケーション・ポリシーの移行は、いくつかのパラメータによって制御されます。これらのパラメータはファイルMETA-INF/weblogic-application.xmlで構成します。

WebSphereでのパラメータの指定の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

アプリケーションのデプロイまたは再デプロイでポリシーの移行を制御するパラメータおよびアンデプロイでポリシーの削除を制御するパラメータは、次のとおりです。

- 移行

- 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を使用しないでアプリケーションを管理する場合にのみ、手動で入力する必要があります。

管理サーバーが稼働しているコンピュータとは異なるコンピュータで稼働している管理対象サーバーに、ファイルベースのストアを使用するアプリケーションをデプロイする場合は、ライフ・サイクル・リスナーを使用しないでください。使用した場合、管理対象サーバーと管理サーバーによって管理されているデータが一致せず、セキュリティが期待どおりに機能しない場合があります。ライフ・サイクル・リスナーを使用するかわりにOPSSスクリプト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のいずれかを表します。

WebSphereでのこのパラメータの構成の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

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>

WebSphereでのこのパラメータの構成の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

任意の有効な文字列をこのパラメータの値に設定できます。このパラメータの値を指定しない場合は、アプリケーション名とバージョン、すなわち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>

WebSphereでのこのパラメータの構成の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

設定する場合は、このパラメータの値を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です。

検証エラーはサーバー・ログに記録されます。検証エラーが発生しても動作は停止しません。

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

この項では、アプリケーション・ポリシーの管理時に次のような動作を実行するのに必要な設定について説明します。

- 全ポリシーの移行をスキップする

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

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

- アプリケーション・ポリシーを削除する(またはアプリケーション・ポリシーを削除しない)

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

予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。詳細は、「推奨事項」を参照してください。

どの動作も、Fusion Middleware Controlによるアプリケーションのデプロイ時、再デプロイ時またはアンデプロイ時に、Fusion Middleware Controlで指定できます。

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

次のマトリクスは、移行を行わない設定を示しています。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OFF

通常、ドメイン・ポリシーをそのまま保持する場合はアプリケーションの再デプロイ時にポリシーの移行をスキップしますが、初めてアプリケーションをデプロイするときはポリシーを移行します。

21.4.2.2 全ポリシーをマージにより移行するには

次のマトリクスは、ターゲット・ストアにないポリシーのみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。

表21-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が設定されます。

ポリシーが変更され、これを既存のポリシーに追加する場合は通常、再デプロイ時にマージによるポリシーの移行を選択します。

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

次のマトリクスは、一致するターゲット・ポリシーを上書きして全ポリシーを移行する設定を示しています(オプション・パラメータは大カッコで囲んであります)。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OVERWRITE

[jps.policystore.migration.validate.principal]

アプリケーション・ポリシーおよびシステム・ポリシーでエンタープライズのユーザーとロールを検証する場合は、TRUEに設定します。それ以外の場合は、FALSEに設定します。指定しなかった場合は、デフォルトのFALSEが設定されます。

新しいポリシー・セットで既存のポリシーを置き換える場合は通常、再デプロイ時に上書きによるポリシーの移行を選択します。オプション・パラメータjps.policy.migration.validate.principalは、必要な場合、手動で設定する必要があります。

21.4.2.4 アプリケーション・ポリシーを削除する(またはアプリケーション・ポリシーを削除しない)には

システム・ポリシー内でコード・ソースの付与が削除されないため、アンデプロイ時のアプリケーション・ポリシーの削除は制限されています。詳細は、「削除されるデータと削除されないデータ」を参照してください。

次のマトリクスは、アンデプロイ時にポリシーを削除する設定を示しています。

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

アンデプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.policystore.removal

設定しない(デフォルト)

注意:

アンデプロイ時に削除するポリシーは、デプロイ時または再デプロイ時にアプリケーションで指定したストライプによって決まります。元のものとは異なるストライプを指定して再デプロイしたアプリケーションでは、元のストライプのポリシーは削除されません。

次のマトリクスは、アンデプロイ時にアプリケーション・ポリシーを削除しない設定を示しています。

表21-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 application 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>内のデータはすべて、アンデプロイ時に自動的に削除できません。

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

表21-7は、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーを移行する設定を示しています。MERGEまたはOVERWRITEの操作は、アプリケーション・ポリシーがドメインにまだ存在していない場合にのみ実行できます。

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

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

MERGEまたはOVERWRITE

表21-8は、アプリケーションを静的にデプロイするときにアプリケーション・ポリシーの移行をスキップする設定を示しています。

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

JpsApplicationLifecycleListener

設定する

jps.policystore.migration

OFF

21.4.2.6 推奨事項

次の推奨事項を覚えておいてください。

LDAPベースのポリシー・ストアを使用し、アプリケーションを複数の管理対象サーバーにデプロイする場合は、それらのサーバーの1つに対してのみ移行を行うよう選択します。残りのデプロイでは、ポリシーを移行しないよう選択します。これにより、ポリシーはアプリケーション・ストアからポリシー・ストアに一度のみ移行されます。すべてのデプロイで、同じアプリケーションIDを使用する必要があります。

同じアプリケーションで同一のノードに対するポリシーの移行を複数回(たとえば異なる管理対象サーバー上で)試行すると、ポリシーの移行が失敗する場合があります。別の方法として、OPSSスクリプトmigrateSecurityStoreを使用して、デプロイ・プロセスの外部でポリシー・データをストアに移行することもできます。

ただし、アプリケーションが複数のサーバーにデプロイされ、ポリシー・ストアがファイルベースである場合、移行によってポリシー・ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlを更新するには、デプロイに管理サーバーを含める必要があります。

21.4.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管理者ガイド』の「キーストローク、ウォレットおよび資格証明の管理」の章を参照してください。

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

デプロイ時、アプリケーションの資格証明の移行は、いくつかのパラメータで制御されます。これらのパラメータはファイルMETA-INF/weblogic-application.xmlで構成します。

WebSphereでのこれらのパラメータの指定の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

資格証明の移行を制御するパラメータは、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>

WebSphereでのこのパラメータの指定の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

設定する場合、このパラメータの値は、MERGE、OVERWRITE、OFFのいずれかである必要があります。値OVERWRITEは、WebLogicのみを対象とし、またこのサーバーが開発モードで稼働している場合にのみ使用できます。

設定しない場合、資格証明の移行はオプションMERGEを使用して行われます。

JpsApplicationLifecycleListener - 資格証明

このリスナーはWebLogicでのみサポートされています。次のフラグメントに示すように構成します。

<wls:listener>
<wls:listener-class>
oracle.security.jps.wls.listeners.JpsApplicationLifecycleListener
</wls:listener-class>
</wls:listener>

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

この項では、アプリケーション資格証明の移行時に次のような動作を実行するのに必要な手動設定について説明します。

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

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

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

予期しない移行動作が生じる場合があるため、次の項に示す値以外の値を設定することはお薦めしません。

移行のターゲットがLDAPベースの資格証明ストアの場合、アプリケーションは1つの管理対象サーバーまたはクラスタにのみデプロイしてください。そうしないと、アプリケーション資格証明が予期したとおりに動作しない場合があります。

注意:

資格証明は、アプリケーションをアンデプロイしても削除できません。アプリケーションとパッケージ化した時点から資格証明が有効になっている可能性がありますが、そのアプリケーションをアンデプロイしても資格証明は削除されません。

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

次のマトリクスは、移行を行わない設定を示しています。

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

デプロイ時または再デプロイ時に有効

jps.credstore.migration

OFF

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

次のマトリクスは、ターゲット・ストアにない資格証明のみを移行する必須およびオプションのパラメータ設定を示しています(オプション・パラメータは大カッコで囲んであります)。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.credstore.migration

MERGE

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

この操作は、WebLogicサーバーのみを対象とし、またサーバーが開発モードで稼働している場合にのみ有効です。次のマトリクスは、一致するターゲットの資格証明を上書きしてすべての資格証明を移行する設定を示しています。

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

デプロイ時または再デプロイ時に有効

JpsApplicationLifecycleListener

設定する

jps.credstore.migration

OVERWRITE

jps.app.credential.overwrite.allowed

このシステム・プロパティはTRUEに設定する必要があります。

21.4.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>でサポートされている値について説明します。

重要:

ポリシーで使用するすべてのパーミッション・クラスをクラス・パスで指定しておく必要があります。これにより、サービス・インスタンスを初期化する際に、ポリシー・プロバイダでそれらのパーミッション・クラスがロードされます。

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

クラス名:

oracle.security.jps.service.policystore.PolicyStoreAccessPermission

特定のアプリケーションにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。

context=APPLICATION,name=appStripeName

すべてのアプリケーションにパーミッションが適用される場合は、対応する要素<name>に対して次の名前パターンを使用します。

context=APPLICATION,name=*

すべてのアプリケーションおよびシステム・ポリシーにパーミッションが適用される場合は、対応する要素<name>に対して次の名前パターンを使用します。

context=APPLICATION

対応する要素<actions>で使用できる値のリストを次に示します(*は許可された任意のアクションを表します)。

*
createPolicy
getConfiguredApplications
getSystemPolicy
getApplicationPolicy
createApplicationPolicy
deleteApplicationPolicy
grant
revoke
createAppRole
alterAppRole
removeAppRole
addPrincipalToAppRole
removePrincipalFromAppRole
hasPermission
containsAppRole

21.4.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

21.4.6.3 一般的なパーミッション

クラス名:

oracle.security.jps.JpsPermission

oracle.security.jps.callback.IdentityCallbackのコールバック・インスタンスによって実行されたアサーションにパーミッションが適用される場合は、対応する要素<name>に対して次のパターンを使用します。

IdentityAssertion

対応する要素<actions>で使用できる唯一の値は、次のとおりです。

execute

21.4.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になります。

OPSSスクリプトを使用してブートストラップ資格証明を変更または追加するには、第10.5.5項「modifyBootStrapCredential」および第10.5.6項「addBootStrapCredential」を参照してください。

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

アイデンティティ・データは、OPSSスクリプトmigrateSecurityStoreを使用してソース・リポジトリからターゲットLDAPリポジトリに手動で移行できます。このスクリプトで作成されるLDIFファイルを、(手動で多少の編集を行った後で)LDAPベースのアイデンティティ・ストアにインポートして、移行元の10gまたは11gファイルベースのあらゆるアイデンティティ・ストアで使用できます。

たとえば、このスクリプトを使用して、10.1.xのjazn-data.xmlファイルにあるユーザーおよびロール情報をWebLogic LDIF形式のユーザーおよびロール情報に変換できます。各ユーザーのパスワードを変更した後、このLDIF出力ファイルをWebLogicに組み込まれているLDAPアイデンティティ・ストアにインポートできます(この項の末尾にある注意を参照してください)。

このスクリプトはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。

このスクリプトは、WebLogic Serverではインタラクティブ・モードまたはスクリプト・モードで、WebSphereではインタラクティブ・モードでのみ実行可能です。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。

スクリプト・モードおよびインタラクティブ・モードの構文

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"])

WebSphere Application ServerでのOPSS スクリプトの実行の詳細は、次を参照してください

引数(dstLdifFile以外はすべて必須)の意味は次のとおりです。

- configFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。

- srcでは、引数configFileで渡す構成ファイルで移行元ストアを指定しているjps-contextの名前を指定します。

- dstでは、引数configFileで渡す構成ファイルで移行先ストアを指定している別のjps-contextの名前を指定します。
移行先ストアは、LDAPベースのアイデンティティ・ストアにする必要があります。サポートされているタイプの一覧は、第3.1.1項「サポートされているLDAPアイデンティティ・ストアのタイプ」を参照してください。

- dstLdifFileでは、作成したLDIFファイルの相対パスまたは絶対パスを指定します。移行先が組込みLDAPなど、LDAPベースのOracle Internet Directoryストアである場合にのみ適用されます。LDIFファイルはLDAPサーバーにはインポートされず、通常は手動編集が必要です。

srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このスクリプトは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。

重要:

出力LDIFファイルの各ユーザーのパスワードは、実際のユーザー・パスワードではなく、仮の文字列weblogicです。移行先がLDAPベースのOracle Internet Directoryストアの場合、仮の文字列はchangeです。

このため、LDIFファイルをターゲットのLDAPストアにインポートする前に、セキュリティ管理者がこのファイルを編集して、仮のパスワードを実際のパスワードに変更する必要があります。

21.4.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="0" name="audit.maxDirSize"/>
<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://stadw12.us.oracle.com:3060" 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://stadw12.us.oracle.com:3060" 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>

22 Java SEアプリケーションの認証

この章の情報はJava SEアプリケーションにのみ適用され、Java SEアプリケーションの開発者を対象読者としています。Java EEアプリケーションの認証の詳細は、「Java EEアプリケーションの認証トピックへのリンク」にリストされているドキュメントを参照してください。

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

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

- 構成例

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

次にあげるドキュメントは、Java EEアプリケーションの認証開発に役立つ情報ソースです。

- Oracle WebLogic Serverにおける認証の一般情報は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティについて』の第3章にある認証に関する項を参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』

- 第3章「Webアプリケーションの保護」

- 第4章「Java ClientでのJAAS認証の使用」

- 第5章「Java ClientでのSSL認証の使用」

- 『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』

- 第4章「認証プロバイダ」

- 第5章「IDアサーション・プロバイダ」

- 第13章「サーブレットの認証フィルタ」

- Java EEアプリケーション内のカスタム・モジュールは、認証プロバイダでラップする必要があります。詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』のカスタムの認証プロバイダの開発方法に関する項を参照してください。

- Java EEアプリケーションで使用されるログイン・モジュールについては、次のドキュメントを参照してください。

- 『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティ・プロバイダの開発』の第4章にあるログイン・モジュールに関する項

- 『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』の第4章にあるJAAS認証の開発環境に関する項

- すべてのOPSS API javadocへのリンクについては、第H.1項「OPSS APIリファレンス」を参照してください。

22.2 Java SEアプリケーションの認証

この項では、Java SEアプリケーションに対するアイデンティティ・ストアのサポートについて説明します。内容は次のとおりです。

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

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

- Java SEアプリケーション向けにサポートされるログイン・モジュール

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

Java SEアプリケーションでの認可の詳細は、第23.1項「Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成」を参照してください。

22.2.1 アイデンティティ・ストア

認証とは、コール元が特定のユーザーまたはシステムの代理として機能していることを証明するメカニズムです。認証では、名前とパスワードの組合せなどのデータを使用して、相手が誰であるかという質問への回答が提供されます。アイデンティティ・ストアという用語はアイデンティティ・データの格納場所を表し、認証プロバイダはアイデンティティ・ストアにアクセスするための手段です。

アプリケーションによるOPSSセキュリティ・ストア(アイデンティティ・ストア、ポリシー・ストアまたは資格証明ストア)からの情報の取得と、そのコンテンツの管理には、OPSS APIが使用されます。次の図はこれを示したものです。

22.2.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="security.principal.alias" value="MyCredentialMapName"/>
<property name="security.principal.key" value="MyCredentialMapKey"/>
<property name="ldap.url" value="${LDAP_URI}"/>
<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「WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。

- アイデンティティLDAPストアにアクセスするための資格証明は、インスタンス・プロパティのsecurity.principal.keyおよびsecurity.principal.aliasで指定し、ブートストラップ資格証明ストアに格納します。

22.2.3 Java SEアプリケーション向けにサポートされるログイン・モジュール

ログイン・モジュールは、ユーザーを認証し、サブジェクトにプリンシパルを移入するコンポーネントです。このプロセスは、2つの異なる段階で行われます。第一段階では、ログイン・モジュールによって要求元のユーザー(必要に応じて名前、パスワードまたはその他の資格証明データ)の認証が試みられます。第一段階が成功した場合にのみ、第二段階が呼び出されます。第二段階では、ログイン・モジュールによって、関連プリンシパルがサブジェクトに割り当てられ、最終的にそれが権限が付与されたアクションを実行するために使用されます。

22.2.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)

22.2.3.2 認証のためのアイデンティティ・ストア・ログイン・モジュールの使用

この項では、基本的なユーザー名とパスワードの認証のためのアイデンティティ・ストア・ログイン・モジュールの使用方法を示します。

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);
}
}
}
}
}

22.2.3.3 アサーションのためのアイデンティティ・ログイン・モジュールの使用

アイデンティティ・ストアのログイン・モジュールをアサーションのために使用するには、開発者は次の処理を行う必要があります。

- コール元が保護されたメソッド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();
}
}
}

22.2.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 Sting[]{"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>

22.3 構成例

この項では、次のアーティファクトの構成を示します。

- 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に応じて、次の値を設定できます。

表22-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

23 Java SEアプリケーションの認可

この章では、Java SEアプリケーションで認可を開発、構成する方法を説明するとともに、サポートされていない一部のメソッドについて示します。この章は次の項で構成されています。

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

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

ポリシー・モデルの詳細は、第20.3項「JAAS/OPSS認可モデル」を参照してください。

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

Java SEアプリケーションでのポリシー・ストアと資格証明ストアの構成について、次の各項で説明します。

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

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

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

Java SEアプリケーションの認証の構成の詳細は、第22.2項「Java SEアプリケーションの認証」を参照してください。

Java SEアプリケーションで認可が機能するためには、システム・プロパティを適切に設定しておく必要があります。すべてのプロパティのリストは、第F.1項「OPSSシステム・プロパティ」を参照してください。

Java SEアプリケーションでは、ファイルベース、LDAPベースまたはDBベースのストア・プロバイダを使用できます。これらのサービスはアプリケーション・ファイルjps-config-jse.xmlで構成します。

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

ファイルベースのポリシー・ストアはファイルsystem-jazn-data.xmlで指定し、ファイルベースの資格証明ストアはファイルcwallet.ssoで指定します(このウォレット・ファイルを、同じ名前のブートストラップ・ファイルcwallet.ssoと混同しないようにしてください。このブートストラップ・ファイルには、アプリケーション・セキュリティがLDAPベースの場合にLDAPストアにアクセスするための資格証明が格納されています)。

ウォレットの詳細は、第21.4.3項「ウォレットベースの資格証明ストアの使用」を参照してください。ブートストラップ資格証明の変更または追加の詳細は、第10.5.5項「modifyBootStrapCredential」および第10.5.6項「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に設定する必要がある点に留意してください。

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

この項では、LDAPベースのストアをポリシー・ストアおよび資格証明ストアとして使用するように設定していることが前提となっています。Oracle Internet Directoryでのノードの設定の詳細は、第8.2.2項「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
...

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

この項では、DBベースのストアをOPSSセキュリティ・ストアとして使用するように設定していることが前提となっています。DBでのノードの設定の詳細は、第8.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>

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

このリリースでは、ファイルベースのポリシー・ストアに対して、次の機能に関連するメソッドはサポートされていません。

- 一括認可

- 複雑な問合せ

- カスケード削除

一括認可は、インタフェースoracle.security.jps.service.policystoreの次のメソッドでカプセル化されます。

java.util.Set<ResourceActionsEntry>
checkBulkAuthorization(javax.security.auth.Subject subject,
java.util.Set<ResourceActionsEntry> requestedResources)
throws PolicyStoreException

複雑な問合せは、問合せを実行するすべてのメソッドに関連します。ポリシー・ストアがファイルベースの場合、問合せは単純であることが必要です。ファイルベースのポリシー・ストアを使用している場合に、問合せを実行するメソッドに複雑な問合せを渡すとそのメソッドは例外をスローします。

単純な問合せとは、検索条件が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

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

この章の次の各項では、資格証明ストア・フレームワーク(CSF)のAPIの使用方法について説明します。

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

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

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

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

- 資格証明ストアの構成

- APIの使用手順

- 例

- ベスト・プラクティス

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

資格証明ストアは、資格証明のセキュアな保存のために使用します。資格証明ストア・フレームワーク(CSF) APIは、資格証明ストアの操作へのアクセスと実行に使用します。

資格証明ストア・フレームワークには、次の機能があります。

- 資格証明の安全な管理を可能にします。

- 各種バックエンド・リポジトリでの資格証明の格納、取得および管理のためのAPIを提供します。

- ファイルベース(Oracleウォレット)およびLDAPベースの資格証明管理をサポートします。

CSF APIは、次のような重要な機能(作成、更新、削除)を提供します。

- 資格証明マップ(特定のキーを持つ資格証明)がストア内に存在するかどうかを確認します。

- <mapname, key>に関連付けられた資格証明を返します。

- 資格証明を<mapname, key>に割り当てます。

- 特定のマップ名、または特定のマップ名とキーに関連付けられた資格証明を削除します。

- 指定された<mapname, key>の資格証明をリセットします。

CredentialStoreに対する操作は、CSFで使用されるファイングレイン・アクセス制御モデルを実装するCredentialAccessPermissionによって保護されます。

関連項目:

- 第10章「資格証明ストアの管理」

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

次の領域に関する知識は、アプリケーションで資格証明ストア・フレームワークを使用する場合に役立ちます。

- 使用する適切なマップ名とキー名の決定。これは、複数のアプリケーションが資格証明を共通の資格証明ストアに格納する環境では非常に重要です。

- Javaセキュリティ・ポリシーのプロビジョニング。
ポリシー・パーミッションは、ファイルベース(system-jazn-data.xml)またはLDAPベースのポリシー・ストアに設定されます。データのセキュリティを損なわずにアプリケーションの使用を可能にする適切なパーミッションを設定するには、十分な配慮が必要です。

関連項目:

第9.1項「ポリシー・ストアの管理」

- jps-config.xmlでの資格証明ストア・インスタンスの定義方法。
jps-config.xmlでのサービス・インスタンスの定義は、構成ファイルをマニュアルで作成する場合のみ必要です。

注意:

デフォルトでは、ファイルベースのプロバイダが構成されており、これはLDAPベースのプロバイダに変更することができます。第8.6項「OPSSセキュリティ・ストアの移行」を参照してください。

- 環境の設定手順。
スタンドアロン・アプリケーションの場合と、Oracle WebLogic Server環境で動作するアプリケーションの場合は手順が異なります。

以降の項で、それぞれのタスクについて詳しく説明します。

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

Oracle Platform Security Servicesのポリシー・プロバイダは、サーバーの起動時に設定されます。プロバイダがファイルベースの場合、ポリシー・データはsystem-jazn-data.xmlに格納されます。

CSFは、資格証明の保護を次のようにサポートしています。

- マップ・レベルでの保護、または

- 特定の<mapname, key>に対するきめ細かな保護

注意:

- CSF APIに適切にアクセスするには、ポリシー・ストアにJavaパーミッションを付与する必要があります。

- CSF APIを呼び出すコードには、コード・ソースのパーミッションが必要です。パーミッションは通常、特定のコードjarに与えられるものであり、アプリケーション全体には与えられません。

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

資格証明ストア・フレームワークでは、Javaパーミッションに基づいて、資格証明ストアのオブジェクトにパーミッションを付与します。

必要なパーミッションのみを付与して、それ以外は付与しないことを強くお薦めします。

警告:

不要なパーミッション、特にすべてのマップやキーにアクセスできるパーミッションを付与することは危険であり、お薦めできません。

24.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は、使用するキー名です。

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.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>

24.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つの任意の文字列にすぎないため、実際には任意の有効な文字列値を持つことができます。ただし、このように実装することにより、マップ名を容易に管理することができます。

24.5 資格証明ストアの構成

管理者は、資格証明ストアの場所とプロバイダ・クラスに関する情報が含まれている構成ファイル内で、資格証明ストア・インスタンスを定義する必要があります。構成ファイルは、次の場所にあります。

$DOMAIN_HOME/config/fmwconfig

名前は次のとおりです。

- jps-config.xml(Oracle WebLogic Serverの場合)

- jps-config-jse.xml(Java SEの場合)

詳細は、第10章「資格証明ストアの管理」を参照してください。

24.6 APIの使用手順

資格証明ストア・フレームワークは、Oracle WebLogic Server内でもスタンドアロン環境でも使用できます。

- スタンドアロン環境でのCSF APIの使用方法

- Oracle WebLogic ServerでのCSF APIの使用方法

24.6.1 スタンドアロン環境でのCSF APIの使用方法

スタンドアロン環境でAPIを使用する手順は、次のとおりです。

1. クラスパスを設定します。jps-manifest.jarファイルがそのクラスパスに入っていることを確認します。詳細は、第1.5.3項「シナリオ3: Java SEアプリケーションの保護」の「クラスパスで指定する必要のあるJAR」を参照してください。

2. ポリシーを設定します。CSF APIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第24.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. アプリケーションを実行します。

コマンドライン・オプションは次のとおりです。

- -Doracle.security.jps.config

構成ファイルのフルパスを指定します。

- -Djava.security.policy

OPSSおよびOracle WebLogic Serverのポリシー・ファイルの場所を指定します。

- -Djava.security.debug=all

デバッグに役立ちます。

24.6.2 Oracle WebLogic ServerでのCSF APIの使用方法

Oracle WebLogic Server環境でAPIを使用する手順は、次のとおりです。

1. jps-config.xmlファイルの資格証明ストアのサービス・プロバイダ・セクションは、次のディレクトリにすぐに使用できるように構成されています。

$DOMAIN_HOME/config/fmwconfig

必要に応じて、LDAP資格証明ストアへの再関連付けを行ってください。

2. ポリシーを設定します。CSF APIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第24.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. Oracle WebLogic Serverを起動します。

4. アプリケーションをデプロイしてテストします。

24.7 例

この項では、資格証明ストア・フレームワークAPIの使用例をいくつか示します。次の例を示します。

- すべての例でコールされ、資格証明ストアの実際の操作を実行するユーティリティJavaプログラム

- ユーティリティ・プログラムをコールするJava SEコードまたはJava EEコード

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

- 構成ファイル

それぞれの例では、パーミッションが資格証明ストアの操作にどのような影響を与えるかを示すようにテスト・コードが設定されています。それぞれの例では、ポリシー・ファイル、テスト・コードおよび構成ファイルが用意され、プロバイダ情報の指定方法を示し、マップとキーに定義されたパーミッションとコード内で試行されている操作を比較できるようになっています。

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

- CSF操作のコード

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

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

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

24.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 {
System.out.print("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";
}
});
}
}

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

この例では、ウォレット資格証明(つまりファイルベースのプロバイダ)を使用するサンプル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にはどのようなパーミッションも付与されていないので、第24.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.JpsContextFactory;
import oracle.security.jps.JpsException;
import oracle.security.jps.internal.policystore.JavaPolicyProvider;
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 {

// set the OPSS policy provider explicitly, as required in a Java SE application
static {
java.security.Policy.setPolicy(new oracle.security.jps.internal.policystore.JavaProvider());
}

public CsfApp() {
super();
}

public static void main(String[] a) {
// perform operation as privileged code
JpsContextFactory ctxFactory;
try {
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プロバイダに設定することが妥当です。

- サポートされるアプリケーション・サーバーへのJRFインストールのJava EE環境では、OPSSポリシー・プロバイダが初期化されています。

24.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);
}
}
}

資格証明作成操作は、権限のあるコードを使用して実行されます。操作が正常に行われたことを確認するには、次のようにWLST listCredコマンドを使用します。

listCred(map="pc_map", key="pc_key")

Java SE環境に関する注意

Java SE環境では、次の2つのコールは同等です。

CredentialStore store = JpsServiceLocator.getServiceLocator().lookup(CredentialStore.class);

および

CredentialStore store = JpsContextFactory.getContextFactory().getContext().getServiceInstance(CredentialStore.class);

後者のコールは、第24.7.2項「例1: ウォレット・ストアを使用するJava SEアプリケーション」で紹介しています。

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

この例では、例2で使用したものと同じ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" />

jps-config.xml内のLDAPストアの構成は、次のとおりです。

<jpsConfig>
<serviceProviders>
<serviceProvider name="credstore_ldap_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_instance"/>
</jpsContext>
</jpsContexts>
</jpsConfig>

強調表示された行では、資格証明を検索するために必要なLDAPパラメータが定義されています。

24.8 ベスト・プラクティス

クラスタ環境では、資格証明ストア・フレームワークAPI上で資格証明ストアMbean APIを使用して、アプリケーションの資格証明の作成、取得、更新および削除を行います。

ただし、単に資格証明を読み取るだけの場合は、いずれのAPIも使用できます。

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

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

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

- ロールとクラスの要約

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

- リポジトリの検索

- ユーザー認証

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

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

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

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

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

注意:

ユーザーおよびロールAPIは現在非推奨となっており、今後のリリースでは廃止される可能性があります。新しいアプリケーションの開発にはIdentity Governance Frameworkを使用してください。今後のリリースで既存のアプリケーションをIdentity Governance Frameworkに移行することを計画してください。

詳細は、Oracle Fusion Middleware Identity Governance Framework ArisID API開発者ガイドを参照してください。

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

ユーザーおよびロールAPIフレームワークを使用すると、アプリケーションは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報(ユーザーとロール)にアクセスすることができます。このリポジトリとして、Oracle Internet Directory、Active Directory (Microsoft社)、Oracle Directory Server Enterprise EditionなどのLDAPディレクトリ・サーバーや、データベース、フラット・ファイルなどのカスタム・リポジトリを使用できます。

このAPIフレームワークには、移植可能な方法でプログラム的にリポジトリにアクセスするための便利な方法が用意されているため、アプリケーション開発者は、個々のアイデンティティ・ソースに対応した複雑な処理を考慮するという煩雑な作業から解放されます。このフレームワークにより、アプリケーションは異なるリポジトリをシームレスに操作できるようになります。アプリケーションは、コードを変更しなくても、各種のアイデンティティ・リポジトリを切り替えて使用することができます。

サポートされる操作には、ユーザーとロールの作成、更新、削除のほか、ユーザーおよびロールの属性や特定の情報の検索などがあります。たとえば、特定のロールのすべてのユーザーの電子メール・アドレスを検索できます。

注意:

これらのAPIは、認証機能または認可機能を対象としたものではなく、アイデンティティ情報の保持を目的としています。

基本使用モデル(コンテナ統合を使用しない)またはコンテナ統合を使用するモデル(コードの移植が可能)を使用できます。

Oracle WebLogic Serverコンテナのコンテキストの実行を目的としているアプリケーションでは、weblogic.security.principal.WLSUserImplにプリンシパル・クラスをキャストする必要があります。

注意:

ユーザーおよびロールAPIを呼び出すには、次のことが条件になります。

- アイデンティティ・ストアがLDAPベースであること

- ドメイン管理サーバーが稼働していること

ユーザーおよびロールAPIを使用する際の注意

一般的に、認証はユーザーおよびロールAPIで実行せず、認証プロバイダでのみ実行する必要があります。

また、書込み権限のないユーザーの接続DNで認証プロバイダを構成することをお薦めします。

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

ユーザーおよびロールAPIは、最初のOracle WebLogic Server認証プロバイダを使用するように自動的に構成されるため、特別な構成は必要ありません。F

ただし、ユーザーおよびロールAPIがその他の認証プロバイダを使用する場合は構成が必要です。

APIは、Oracle WebLogic Serverドメインにリストされている最初のLDAP認証プロバイダからのみデータにアクセスできます。複数の認証プロバイダが存在する場合は、各プロバイダの制御フラグの優先度によって優先順位が決まります。優先度が同じ場合は、最初のプロバイダが選択されます。リスト上で最初の認証プロバイダの下位にあるLDAP認証プロバイダにはアクセスしません。

WebLogic APIの同時使用について

アプリケーションでのLDAPサーバーのエントリの操作に、ユーザーおよびロールAPIとWebLogic LDAPAuthenticator API (EmbeddedLDAPAuthenticator、OracleInternetDirectoryAuthenticator、OracleVirturalDirectoryAuthenticatorなど)の両方を同時に使用しないでください。その理由を理解するには、同じLDAPサーバーにアクセスする2つのLDAPクライアントについて考えます。これらのクライアントはどちらもキャッシュが有効に設定されており、一方はエントリを削除しようとし、もう一方は削除対象のエントリを使用しようとしているとします。

この2つのクライアントが引き起こす競合を解決するには、キャッシュ機能を無効にし、クライアント間でLDAP操作を調整する必要があります。

25.2 ロールとクラスの要約

表25-1は、ユーザーおよびロールAPIのクラスとインタフェースを示しています。

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

名前

タイプ

説明

AuthenticationException

クラス

アイデンティティ・ストアへのアクセス中に認証エラーが発生すると、この例外がスローされます。認証エラーは、ユーザー・プログラムで指定された資格証明が無効な場合や、該当アイデンティティ・ストアでユーザーを認証できなかったときなどに発生する場合があります。

AuthenticationWarningException

クラス

このクラスは、IMException(次の説明を参照)を拡張したものです。

ComplexSearchFilter

インタフェース

複合検索フィルタは、基礎となるアイデンティティ・リポジトリから得られる結果のフィルタ処理に使用できる、複合的な論理式を表します。複合検索フィルタは、複数のSearchFilterインスタンスを1つの論理演算子(ANDまたはOR)で組合したものです。コンポーネントとなる各SearchFilter自体を複合フィルタにできるため、複雑なネストした検索フィルタの作成が可能です。

複合検索フィルタの作成例については、Javadoc(第25.9項「ユーザーおよびロールAPIリファレンス」)を参照してください。

ConfigurationException

クラス

この例外は、構成に問題がある場合にスローされます。この例外は、サービス・プロバイダへのアクセスに必要な構成情報が不正であるか、見つからないときに発生する場合があります。

Identity

インタフェース

このインタフェースは、アイデンティティ・リポジトリ内の基本的なアイデンティティを表します。

IdentityStore

インタフェース

IdentityStoreは、実際のアイデンティティ・リポジトリへのハンドルを表します。このハンドルを使用して、リポジトリ内のアイデンティティを検索、作成、削除または変更することができます。

IdentityStoreFactory

インタフェース

IdentityStoreFactoryは、基礎となるアイデンティティ・リポジトリをプログラム的に表したものです。アイデンティティ・リポジトリへの実際のハンドルは、このオブジェクトのgetIdentityStoreInstance(Hashtable)をコールすることによって取得できます。

IdentityStoreFactoryBuilder

クラス

このクラスは、アイデンティティ・ストア・ファクトリを構築します。

IMException

クラス

この例外は、ADFのアイデンティティ管理APIによってスローされるすべての例外のスーパークラスです。サブクラスの名前が障害の性質を示します。

既知の直接サブクラスのリストについては、Javadoc(第25.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(第25.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[])

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

この項では、プロバイダの基本的な概念とライフサイクルについて説明し、プロバイダを設定、構成および使用してOracle Platform Security環境でユーザー・リポジトリを操作する方法を説明します。

環境が正しく設定されていることを確認した後で、プロバイダを実装する際には、次の作業が必要になります。

- 基礎となるリポジトリの指定とそのリポジトリに適したプロバイダ・ファクトリ・クラスの選択

- プロバイダ・ファクトリとアイデンティティ・ストアのインスタンスの作成

- プロバイダの構成

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

- サービス・プロバイダについて

- 環境の設定

- プロバイダの選択

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

- プログラミングの考慮事項

- プロバイダのライフサイクル

25.3.1 サービス・プロバイダについて

ユーザーおよびロールAPIは、ユーザーとロールを管理するためにコールされますが、このAPIは基礎となるアイデンティティ・リポジトリと直接相互作用することはありません。セキュリティ・アプリケーションでは、かわりに、基礎となるリポジトリと実際の通信を実行するプロバイダが使用されます。このしくみでは、プロバイダと接続の情報を変更するだけで、基礎となる様々なリポジトリで同じコードを使用できるため、柔軟性が得られます。

25.3.2 環境の設定

Jarの構成

環境には、次のようないくつかのjarファイルが必要です。

- provider jarファイル。目的の基礎となるアイデンティティ・リポジトリを実装します。

- ユーザーおよびロールAPIのjarファイル

- プロバイダで必要とされる可能性のある、その他のコンポーネントのjarファイル(Toplink、jdbc、xdbなど)。

関連するjarファイルがアプリケーションのクラスパスに含まれていることを確認してください。

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>
.
.

25.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フレームワークで指定されているインタフェースを実装する必要があります。表25-2は、使用可能なプロバイダ・クラスを示しています。

表25-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

25.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ハッシュ表は、ストア・インスタンス環境を指定します。

25.3.5 プロバイダの構成プロパティ

構成は、使用するアイデンティティ・ストア・プロバイダに依存します。

すべてのタイプのLDAPベースのアイデンティティ・ストア・プロバイダの動作は、ファクトリ・インスタンスやストア・インスタンスの多数のプロパティを構成することにより、微調整することができます。次のプロパティは、LDAPベースのプロバイダにのみ関連しています。

- URL

- リポジトリが実行されるポート

- リポジトリにアクセスするときに使用するユーザーとパスワード

サポートされているLDAPベースのプロバイダのリストは、第25.3.3項「プロバイダの選択」を参照してください。

この項では、プロバイダ構成に関する次の項目について説明します。

- 起動時と実行時の構成

- ECID伝播

- 構成の値を渡すタイミング

25.3.5.1 起動時と実行時の構成

構成可能なプロパティは、次の2つのカテゴリに分類されます。

- 起動時の構成: 命名規則として、ST_で始まるプロパティ名が使用されます。

- 実行時の構成: 命名規則として、RT_で始まるプロパティ名が使用されます。

起動時の構成プロパティ

起動時の構成は一回のみ実行され、いったん設定されると、構成の設定はプロバイダのライフタイムにわたって永続します。

ST_SUBSCRIBER_NAMEを除いて、起動時のプロパティはプロバイダのファクトリ・インスタンスの作成時に指定されます。ST_SUBSCRIBER_NAMEは、ストア・インスタンスの作成時に設定されます。

表25-3は、起動時の構成プロパティを示しています。

表25-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インスタンスの作成時にデフォルト値が設定されますが、これは後から変更することができます。

表25-3は、実行時の構成プロパティを示しています。

表25-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のどのタイプかを決定します。

25.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など)を使用している場合は不要です。

25.3.5.3 構成の値を渡すタイミング

構成データは、次のタイミングで指定できます。

- ファクトリ・インスタンスを作成するとき。

関連項目:

第25.3.6項「ファクトリ・インスタンス作成時のプロバイダの構成」

- ストア・インスタンスを作成するとき。

関連項目:

第25.3.7項「ストア・インスタンス作成時のプロバイダの構成」

- 実行時(ストア構成オブジェクトを使用)。

関連項目:

第25.3.8項「実行時の構成」

25.3.6 ファクトリ・インスタンス作成時のプロバイダの構成

この項では、ファクトリ・インスタンス作成時のプロバイダの構成に関連するトピックを説明します。

この段階での構成は、そのファクトリ・オブジェクト全体、および、その特定のファクトリ・インスタンスを使用して作成されるオブジェクトに影響を与えます。次の一般的なプロパティをはじめとして、多くの起動時のプロパティがこの時点で設定されます。

- ST_LDAP_URL: LDAPリポジトリのURL

- ST_SECURITY_PRINCIPAL: ユーザー名

- ST_SECURITY_CREDENTIAL: リポジトリへの接続に必要なユーザー資格証明

25.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);

注意:

イタリックの値は実行前に適切な値に置換する必要があります。

25.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という名前のログ・ファイルにリダイレクトされます。

25.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);

25.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");

25.3.6.5 カスタム接続プール・クラスの構成

カスタム接続プールを使用するには、次のように、カスタム接続プール・クラスの完全修飾クラス名を指定する必要があります。

factEnv.put(OIDIdentityStoreFactory.ST_CONNECTION_POOL_CLASS,
"oracle.security.idm.providers.stdldap.JNDIPool");

関連情報は、第L.6項「組込みのLDAP認証プロバイダへの接続の失敗」を参照してください。

25.3.7 ストア・インスタンス作成時のプロバイダの構成

IdentityStore構成は、ストア・オブジェクトと、このストア・インスタンスを使用して作成されるすべてのストア・オブジェクトに影響します。ストアで一般的に使用される構成パラメータは、この時点で受け入れられる唯一の起動時プロパティである、ST_SUBSCRIBER_NAMEです(すべての実行時プロパティはアイデンティティ・ストアの作成時に指定可能です)。

第25.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またはレルムのニックネームで指定することができます。

25.3.8 実行時の構成

前述の、第25.3.6項「ファクトリ・インスタンス作成時のプロバイダの構成」および第25.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”);

25.3.9 プログラミングの考慮事項

この項では、プロバイダとプロバイダ・アーティファクトの操作のヒントを説明します。

25.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のフィルタ・フォーマットに変換されます。

25.3.9.2 IdentityStoreオブジェクト使用時の考慮事項

アプリケーションをコーディングするときは、次の考慮事項に留意してください。

スレッド・セーフティ

現在のIdentityStoreの実装は、スレッドセーフではありません。ユーザーおよびロールAPIでは、ストア・インスタンスは通常はスレッド間で共有されないと想定されています。ストア・インスタンスがスレッド間で共有される場合は、スレッド・セーフティに要求されるすべての問題点にアプリケーション・コードで対処する必要があります。

スレッド・セーフティとパフォーマンスの間には、トレードオフが存在します。スレッド・セーフティを実装する必要のあるユースケースでは、実装によるパフォーマンスへの影響を考慮に入れる必要があります。

セッションごとに1つのストア・インスタンス

委任管理サーバーなどのアプリケーションでは、各セッション(1人のユーザーのログインに対応)で作成/検索ベースやその他の様々な実行時設定を変更できます。これらはユーザーおよびロールAPIの実行時のプロパティとして定義します。IdentityStoreオブジェクトは、このようなすべての設定をカプセル化し、これに応じて実行時の動作を変更します。このような理由から、セッションごとに1つのIdentityStoreインスタンスというルールが適用されています。

25.3.10 プロバイダのライフサイクル

プロバイダは、そのプロバイダ用に作成されたファクトリ・インスタンスが存続している間、存在し続けます。ファクトリ・インスタンスの寿命は、そのインスタンスに対してclose() APIがコールされると終了します。プロバイダ・インスタンスが終了すると、そのインスタンスを使用して作成されたすべてのオブジェクトは無効になり、そのようなオブジェクトに対するその後のAPIコールでは、予期しない結果が返されます。

IdentityStoreのインスタンスにも、同様の考慮事項が当てはまります。

注意:

- ファクトリ・インスタンスはスレッドセーフですが、IdentityStoreインスタンスの場合はスレッドセーフではありません。

- ベスト・プラクティスとしては、サーバー接続を一括して閉じ、使用されなくなったオブジェクトとインスタンスを明示的に削除することです。

25.4 リポジトリの検索

ユーザーおよびロールAPIには、次の2種類の問合せ関数があります。

- 1つのアイデンティティを返す関数

- アイデンティティのリストを返す関数

この項では、これらのAPIを使用して実行可能な次の検索および関連タスクについて説明し、検索パラメータの指定方法を詳細に示します。

- 特定のアイデンティティの検索

- 複数のアイデンティティの検索

- 検索パラメータの指定

- 検索フィルタの使用

- GUIDによる検索

25.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, Sting value);

これらの関数は、特定のユーザーまたはロールのアイデンティティがストアに存在することがわかっているときに、そのアイデンティティへのオブジェクト参照が必要な場合に実行する単純な問合せで効果的です。これらの関数の機能は、次の点で最小限になっています。

- 文字列値のみを受け取ります。

- 正規表現をサポートしません。

これらの関数では、同じ値を持つ複数のエンティティがストアに存在すると例外が発生します。

25.4.2 複数のアイデンティティの検索

ユーザーおよびロールAPIには、検索を実行して複数のアイデンティティを返すことのできる、次のようないくつかの関数が含まれています。

IdentityStore.search(SearchParams params);
IdentityStore.searchUsers(SearchParams params);
IdentityStore.searchRoles(int searchType, SearchParams params);
IdentityStore.searchProfiles(SearchParams params);

各関数は、検索オブジェクトを受け取り、検索レスポンス・オブジェクトを返します。

25.4.3 検索パラメータの指定

SearchParamsオブジェクト

SearchParamsオブジェクトには、次の情報が格納されます。

- 検索フィルタ: 第25.4.4「検索フィルタの使用」を参照してください。

- 検索するアイデンティティ・タイプ: RolesまたはUsersアイデンティティ・タイプを検索できます。

- ページ・サイズ: デフォルトでは、ページング・オプションは無効になっています。問合せでページングが必要な場合は、ページ・サイズを適切な正の値に設定してください。

- タイムアウト制限: タイムアウトは秒単位で指定します。

- 件数制限: 問合せによって返される結果の数を制限します。

SearchResponseオブジェクト

SearchResponseは、複数のアイデンティティを取得するときに使用されるデータ構造体です。コードでは、次の関数を使用して、この構造体に格納された複数のアイデンティティを繰り返し処理できます。

- hasNext(): さらに要素が存在する場合はtrueを返し、そうでない場合はfalseを返します。

- next(): 次の要素が使用可能であればその要素を返し、そうでなければ例外を返します。

25.4.4 検索フィルタの使用

ユーザーおよびロールAPIには、様々な検索操作を容易に実行するための各種の検索フィルタが含まれています。この項では、検索フィルタの使用の重要なポイントについて説明します。

- 検索フィルタの演算子

- 検索フィルタ使用時の特殊文字の処理

- ログイン・ユーザー用の検索フィルタ

- 検索フィルタの使用例

25.4.4.1 検索フィルタの演算子

検索フィルタの演算子を使用するときには、次のルールを順守してください。

サポートされる演算子

標準のLDAPストアは、= (「等しい」演算子)、< (「より小さい」演算子)、> (「より大きい」演算子)、& (AND演算子)、| (OR演算子)および ! のみを受け入れます(NOT演算子)。IdentityStoreでは、さらに2つの演算子<=(以下)および>=(以上)が用意されており、使用しやすくなっています。

演算子=、<、>、<=および>=は簡易検索フィルタの作成に使用され、演算子&および|は2つ以上の検索文字列の組合せによる複合検索フィルタの作成に使用されます。

NOT演算子

NOT演算子は、簡易検索フィルタと複合検索フィルタの両方で使用できます。この演算子は、フィルタの状態を否定する、つまりフィルタによって前に拒否されたエンティティを受け入れるように、または前に受け入れたエンティティを拒否するように、フィルタの状態を変更するために使用します。

NOT演算子には、次のSearchFilter APIを使用してアクセスできます。

- void negate();

- boolean isNegated();

25.4.4.2 検索フィルタ使用時の特殊文字の処理

RFC-2254 (LDAP検索フィルタの文字列表現)に従って、*、(、)、\およびNULL文字は個別に処理する必要があります。ユーザーおよびロールAPIは、演算子(、)および\を処理しますが、LDAPストアのワイルドカード文字でもある*演算子は処理されません。これらの文字はユーザーおよびロールAPIフレームワークで処理されるため、APIユーザーはこれらの文字を別途に処理する必要はありません。

25.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にマップされる)を使用します。

ログイン・ユーザーおよびロールの取得方法を示すサンプル・コールを、それぞれ例25-6と例25-7に示します。

25.4.4.4 検索フィルタの使用例

この項では、いくつかの使用例を示します。

例25-1 名前によってユーザーを取得するための簡易フィルタ

簡易検索フィルタの実装は、基礎となるストアに依存します。検索フィルタのインスタンスはストア・インスタンスを使用して取得できます。

この例のフィルタでは、名前フィールドの値が非NULLであるすべてのエントリが許可されます。

SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(UserProfile.NAME,
SimpleSearchFilter.TYPE_EQUAL, null);
sf.setValue(sf.getWildCardChar());

例25-2 言語プリファレンスによってユーザーを検索するための簡易フィルタ

この例では、優先言語が英語以外のユーザーが検索されます。

SimpleSearchFilter sf =
oidStore.getSimpleSearchFilter(
UserProfile.PREFERRED_LANGUAGE,
SimpleSearchFilter.TYPE_EQUAL,
"english");
sf.negate();

例25-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);

例25-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);

例25-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());
}

例25-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(params);
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から導出されたもので、ログイン名と異なる場合があります。

例25-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 );
}

25.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());

25.5 ユーザー認証

検証目的で、ユーザーおよびロールAPIをパスワードベースのユーザー認証に使用できます(前述のとおり、このAPIは認証および認可を目的とはしていません)。

authenticateUser APIは、ユーザー・ログイン名を受け取り、指定されたパスワードを使用してユーザーの認証を試みます。認証が成功した場合は、ユーザー・オブジェクトを返します。

パスワードベースの認証の次に例を示します。

store.getUserManager().authenticateUser(“testuser”,”password”);

25.6 アイデンティティ・ストアのエントリの作成と変更

ユーザーおよびロールAPIを使用すると、アイデンティティ・ストアへの新規アイデンティティの追加やストアでのアイデンティティの変更が容易になります。UserManagerクラスとRoleManagerクラスは、それぞれ、ユーザーとロールに固有のデータの作成、変更および削除操作を処理します。

UserManagerとRoleManagerのインスタンスは、ストア・インスタンスから次のようにして取得できます。

UserManager um = oidStore.getUserManager();
RoleManager rm = oidStore.getRoleManager();

この項のトピックは次のとおりです:

- アイデンティティ作成時の特殊文字の処理

- アイデンティティの作成

- アイデンティティの変更

- アイデンティティの削除

25.6.1 アイデンティティ作成時の特殊文字の処理

RFC-2253によって、LDAP v3の識別名の文字列表現が定義されます。つまり、RFCで指定されたすべての文字が処理されます。ユーザーおよびロールAPIのユーザーは、これらの特殊文字をエスケープ/エスケープ解除する必要はありません。特殊文字をエスケープ/エスケープ解除すると、間違った結果になります。

これによって、空のプロパティを使用してアイデンティティを作成するときに問題が生じる可能性があります。この場合、RDN名を使用して様々な必須属性の値が指定されます。これらの必須属性の中には、より厳格な検証ルールが適用されるものもあります。その場合は、アイデンティティの作成が失敗して、例外が発行されます。

25.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の値が指定されます。

25.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段階の手順になります。

25.6.4 アイデンティティの削除

アイデンティティの削除には、dropUserとdropRoleの各APIを使用します。

アイデンティティを削除する場合は、コードにユーザーとロールの両方の参照が必要になります。次に例を示します。

User usr;
Role role;
…
…
usrmanager.dropUser(usr);
rolemanager.dropRole(role);

25.7 ユーザーおよびロールAPIの使用例

この項では、ユーザーおよびロールAPIの実際のアプリケーションを示したいくつかの例を取り上げます。

- 例1: ユーザーの検索

- 例2: Oracle Internet Directoryストアにおけるユーザー管理

- 例3: Microsoft Active Directoryストアにおけるユーザー管理

25.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(sf.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を使用します。

25.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();
}
}
}

25.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@upad.us.oracle.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();
}
}
}

25.8 LDAPベースのユーザーおよびロールAPIプロバイダのSSL構成

この項では、ユーザーおよびロールAPIのSSLサポートについて説明します。次のトピックが含まれます:

- すぐに使用できるSSLのサポート

- ユーザーおよびロールAPIのSSLサポートのカスタマイズ

25.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ディレクトリ

25.8.1.1 システム・プロパティ

SSLをサポートするには、次の情報をシステム・プロパティとして指定する必要があります。

javax.net.ssl.keyStore

javax.net.ssl.keyStorePassword

javax.net.ssl.trustStore

javax.net.ssl.trustStorePassword

詳細は、Sun Microsystems社のJSSEに関するドキュメントを参照してください。

25.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");

25.8.2 ユーザーおよびロールAPIのSSLサポートのカスタマイズ

ユーザーおよびロールAPIプロバイダのSSLSocketFactoryをカスタマイズすることにより、SSLサポートをカスタマイズすることができます。

25.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");

25.9 ユーザーおよびロールAPIリファレンス

ユーザーおよびロールAPIのリファレンス(Javadoc)は、次のドキュメントにあります。

『Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services』

25.10 カスタムのユーザーおよびロール・プロバイダの開発

この項では、セキュリティ開発者がアイデンティティ(ユーザーおよびロール)の管理に使用できるカスタム・プロバイダを開発する方法を説明します。次のトピックが含まれます:

- SPIの概要

- ユーザーおよびロール・プロバイダのタイプ

- 読取り専用プロバイダの開発

- フル機能プロバイダの開発

- 開発のガイドライン

- テストと検証

- 例: アイデンティティ・プロバイダの実装

25.10.1 SPIの概要

ユーザーおよびロールAPIには、カスタムのユーザーおよびロール・プロバイダの開発を可能にするサービス・プロバイダ・インタフェース(SPI)が用意されています。このサービス・プロバイダ・インタフェースを使用して、任意のアイデンティティ・データ・リポジトリで使用するカスタム・プロバイダを開発できます。

このSPIは、抽象クラスのセットであるoracle.security.idm.spiパッケージとしてバンドルされています。カスタムのユーザーおよびロール・プロバイダは、要件に合せてこのSPIを拡張することで作成します。

関連項目:

「ユーザーおよびロールSPIリファレンス」

25.10.2 ユーザーおよびロール・プロバイダのタイプ

ユーザーおよびロールAPIは、検索操作の機能と作成、読取り、更新および削除(CRUD)の各操作の機能を提供します。読取り専用機能に基づくユーザーおよびロール・プロバイダでは、検索操作のみがサポートされます。フル機能プロバイダでは、検索操作とCRUD操作の両方がサポートされます。つまり、フル機能プロバイダは、読取り専用プロバイダのスーパーセットです。

開発者は、要件に応じて読取り専用とフル機能のいずれのプロバイダを作成するかを選択します。

次の場合は、読取り専用プロバイダの開発が適切です。

- 基礎となるアイデンティティ・リポジトリが読取り専用モードで動作している場合

- ユーザーおよびロールAPIを使用するアプリケーションでCRUD APIをコールしない場合

たとえば、SOAアイデンティティ・サービスで使用するプロバイダとしては読取り専用プロバイダが適切です。

25.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

25.10.3.1 拡張が必要なSPIクラス

表25-5は、読取り専用プロバイダを実装するために拡張が必要となるSPIクラスを示しています。

注意:

すべての抽象メソッドを実装する必要があります。

表25-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

次に、各クラスのその他の要件および使用方法を示します。

25.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リファレンス」: このクラスで実装する必要があるメソッドの詳細。ここにあげられているメソッドをすべて実装する必要があります。

25.10.3.3 oracle.security.idm.spi.AbstractIdentityStore

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。次のことに留意してください:

- メソッドgetStoreConfiguration()はオプションですが、OperationNotSupportedExceptionをスローすることがあります。

- メソッドgetSubjectParser()はnullを返すことがあります。

返す検索結果がない場合、すべての検索APIは次をスローします。

oracle.security.idm.ObjectNotFoundException

空のSearchResponseが返されることはありません。

25.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

25.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

25.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

25.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

25.10.3.8 oracle.security.idm.spi.AbstractSimpleSearchFilter

oracle.security.idm.spi.AbstractSimpleSearchFilterは、単純な検索フィルタを実装するために拡張できる抽象クラスです。

実装クラスには、抽象クラスのコンストラクタをコールする次のようなコンストラクタが必要です。

AbstractSimpleSearchFilter (
String attrname, int type, Object value)

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getNativeRepresentation() – 基礎となるアイデンティティ・リポジトリで使用するネイティブな表現にフィルタを変換します。

- getWildCardChar() – 検索で使用する*などのワイルド・カード文字。具体的な文字は、基礎となるアイデンティティ・リポジトリによって異なります。

25.10.3.9 oracle.security.idm.spi.AbstractComplexSearchFilter

oracle.security.idm.spi.AbstractComplexSearchFilterは、任意の複雑性を備えた検索フィルタを実装するために拡張できる抽象クラスです。

実装クラスには、抽象クラスのコンストラクタをコールする次のようなコンストラクタが必要です。

AbstractComplexSearchFilter (
oracle.security.idm.SearchFilter[] filters, int oper_type)

「ユーザーおよびロールSPIリファレンス」には、このクラスでの実装が必要となるメソッドの詳細についての説明があります。具体的な実際の実装が必要なメソッドは、次にあげるもののみです。

- getNativeRepresentation() – 基礎となるアイデンティティ・リポジトリで使用するネイティブな表現にフィルタを変換します。

25.10.3.10 oracle.security.idm.spi.AbstractSearchResponse

SearchResponseオブジェクトには、リポジトリから返された検索結果が格納されます。結果の各エントリは、基礎となるアイデンティティ・リポジトリにある1つのユーザーまたはロールに対応しており、対応するUserProfileクラスまたはRoleProfileクラスの実装によって表されます。

SearchResponseオブジェクトは、1つ以上の結果を返す必要があります。つまり、hasNext()メソッドは少なくとも1回はTRUEを返す必要があります。

返す結果がない場合は使用しないでください。結果が返されないと、対応する検索APIが次の例外をスローします。

oracle.security.idm.ObjectNotFoundException

25.10.4 フル機能プロバイダの開発

フル機能プロバイダでは、読取り専用プロバイダで使用できるすべての機能が実装され、さらにCRUD操作も使用できます。このため、CRUD APIをSPI実装クラスに実装する必要があります。

読取り専用プロバイダでは、OperationNotSupportedExceptionをスローするだけでこれらのAPIを実装しています(第25.10.3項「読取り専用プロバイダの開発」のクラスの説明を参照してください)。

フル機能プロバイダでは、対応するCRUD操作の具体的で実際の実装が必要になります。

25.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

プロバイダの対応する実装クラスでスレッド・セーフティに関連する問題がないことを確認する必要があります。

25.10.6 テストと検証

ユーザーおよびロールAPIには、開発するプロバイダの基本操作をテストできるように、テスト・スイートが付属しています。

このテスト・スイートは、読取り専用プロバイダとフル機能プロバイダの両方のテストで使用できます。

使用方法

java oracle.security.idm.tests.SPITest propertiesfile

propertiesfileには、プロバイダ・クラス名とそのプロバイダのあらゆる構成データを格納します。また、実行するテストに関する情報も格納します。テストを実行する前に、このファイルを編集して、正しい情報で更新する必要があります。このファイルの内容は、見ればすぐわかるようになっています。このようなファイルの1つ(ffprovider.properties)を、第25.10.7.1項「サンプル・プロバイダについて」で説明しているサンプル・プロバイダで使用しています。

結果

テストによって画面に結果が表示されます。開発するすべてのプロバイダが、テスト・スイートのルックアップ・テスト、ロール・メンバーシップ・テストおよびプロファイル・テストに合格する必要があります。フル機能プロバイダは、作成と削除のテストなど、スイートにあるすべてのテストに合格する必要があります。

テスト結果のログは、現在の作業ディレクトリのresults.outファイルに出力されます。

25.10.7 例: アイデンティティ・プロバイダの実装

製品にはサンプルのアイデンティティ・プロバイダが付属しているので、それを使用してカスタム・プロバイダの作成方法を理解できます。

この項では、このサンプル・プロバイダにアクセスする方法と、カスタム・プロバイダを実装するために必要な手順について説明します。手順は、説明に使用するサンプルに依存します。

- サンプル・プロバイダについて

- 実装の概要

- サンプル・アイデンティティ・プロバイダの使用に向けたjps-config.xmlの構成

- Oracle WebLogic Serverの構成

25.10.7.1 サンプル・プロバイダについて

サンプル・プロバイダは、sampleprovider.zipにバンドルされています。このファイルを解凍します。次の構造が生成されます。

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

ant helpを実行すると、このプロバイダの作成とテストの手順を知ることができます。

このプロバイダは、非定型のアイデンティティ・リポジトリを使用してアイデンティティ情報をフェッチしており、Oracle SOA Suiteによるテストを完了しています。これは、実際の環境で適切なテストを実行せずに本番で使用することを意図したものではありません。

25.10.7.2 実装の概要

この例で使用するサンプルのアイデンティティ・プロバイダは、アイデンティティと認証のためのカスタム・プロバイダであり、基礎となるストアとしてRDBMSを使用しています。アイデンティティ・プロバイダおよび認証プロバイダの両方として使用できます。

注意:

このサンプル・プロバイダは説明のみを目的としたものなので、十分なテストを経ずに本番で使用することはお薦めしません。

このサンプル・プロバイダを設定するには、次の手順が必要です。

1. ユーザーおよびロールAPIを実装して、アイデンティティ・ストアとして機能するデータベース・リポジトリにアクセスします。これには、次の処理が必要です。

1. サンプル・プロバイダの作成。その手順を知るには、ant helpを実行します。

2. データベースへのアイデンティティ・ストア・スキーマの作成。

2. 第25.10.7.3項「サンプル・アイデンティティ・プロバイダの使用に向けたjps-config.xmlの構成」で示しているように、サンプル・プロバイダをアイデンティティ・ストアとして構成します。

3. 第25.10.7.4項「Oracle WebLogic Serverの構成」の説明に従って、このプロバイダをSQLAuthenticatorとして使用するようにWeblogic認証プロバイダを設定します。

25.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. サーバーを再起動します。

25.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)

メソッド

表25-6は、AbstractSimpleSearchFilterのメソッドを示しています。

表25-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

このクラスは、アイデンティティ・ストア・ファクトリを表します。

関連項目:

表25-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)

メソッド

表25-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を結合する論理演算子タイプ。

26 アイデンティティ・ディレクトリAPIを使用した開発

この章では、アイデンティティ・ディレクトリAPIを使用して、アイデンティティ・ストアにアクセスして操作する方法について説明します。

この章の内容は次のとおりです。

- アイデンティティ・ディレクトリAPIについて

- クラスの概要

- アイデンティティ・ディレクトリの構成

- アイデンティティ・ディレクトリAPIの操作

- アイデンティティ・ディレクトリAPIの例

- SSL構成

26.1 アイデンティティ・ディレクトリAPIについて

アイデンティティ・ディレクトリAPIを使用すると、アプリケーションは、基礎となるアイデンティティ・リポジトリの種類を問わず、統一的で移植可能な方法でアイデンティティ情報(ユーザーやその他のエンティティ)にアクセスすることができます。

アイデンティティ・ディレクトリAPIの特徴:

- 柔軟性が高い

- 標準スキーマおよび特定のスキーマを持つ様々なアイデンティティ・ストアをサポートし、クライアントによって完全に構成可能

- ユーザー、グループおよび組織の取得と管理をサポートする

- 拡張可能であり、新しいエンティティ・タイプおよびそれらのエンティティ間の関係の定義をサポートする

- 堅牢であり、高可用性/フェイルオーバー・サポートを提供する

アイデンティティ・ディレクトリAPIはIdentity Governance Frameworkを使用し、このフレームワークのすべての利点を提供することにより、個人情報(PII)、アクセス権限、属性およびその他のエンティティなどのアイデンティティ関連の情報が使用および格納され、組織間で伝播される方法を制御することを可能にします。

26.1.1 機能の概要

この項では、アイデンティティ・ディレクトリAPIによってサポートされている機能について説明します。

ユーザー・エンティティに対する機能

ユーザーに対して次の機能がサポートされています。

- ユーザーに対する作成/更新/削除(CRUD)操作の実行

- 次の手順を実行します。

- ユーザー属性の取得と設定

- アイデンティティ・ストアのネイティブ認証メカニズムでのユーザーの認証

- ユーザーが属するグループの取得(オプションで、ネストされたグループも含む)

- グループのメンバーとしてのユーザーの追加

- ユーザー・パスワードの変更

- ユーザー・パスワードの変更の強制

- ユーザー状態(有効/無効、ロックアウト、パスワード変更が必要)の取得と設定

グループ・エンティティに対する機能

グループに対して次の機能がサポートされています。

- グループに対するCRUD操作の実行

- 次の手順を実行します。

- 属性の取得と設定

- グループのメンバーの取得と検索

- グループが属するグループの取得(オプションで、ネストされたグループも含む)

- グループが別のグループのメンバーであるかどうかの判別

- 複数の値を持つ属性のサポート

- 静的グループおよび動的グループのサポート

26.2 クラスの概要

表26-1に、アイデンティティ・ディレクトリAPIのクラスをリストします。

表26-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

様々な基準によりユーザーを作成、削除、検索するためのメソッドを含みます。

26.3 アイデンティティ・ディレクトリの構成

アイデンティティ・ディレクトリの構成は、論理的なエンティティ構成と物理的なアイデンティティ・ストア構成の組合せになります。

論理エンティティ構成を使用するアイデンティティ・ディレクトリは次の場所に格納されています。

DOMAIN_HOME/config/fmwconfig/ids-config.xml

デフォルトのアイデンティティ・ディレクトリに対する物理的なアイデンティティ・ストア構成は次の場所にあります。

DOMAIN_HOME/config/fmwconfig/ovd/default

デフォルトのアイデンティティ・ディレクトリでは、OPSS (WebLogic認証プロバイダまたはjps-config.xml)で構成されているものと同じアイデンティティ・ストア・プロパティ(つまり、ホスト、ポート、資格証明、検索ベース、作成ベース、名前属性など)が使用されます。詳細は、第F.2.3項「LDAPアイデンティティ・ストアのプロパティ」を参照してください。

26.4 アイデンティティ・ディレクトリAPIの操作

この項では、アプリケーションがアイデンティティ・ディレクトリAPIを使用して、アイデンティティ・ストア・データを表示および管理する方法について説明します。次のセクションが含まれます:

- アイデンティティ・ディレクトリAPIインスタンスの取得

- ユーザーとグループに対するCRUD操作の実行

26.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();

26.4.2 ユーザーとグループに対するCRUD操作の実行

ユーザーとグループに対して、作成、取得、更新および削除(CRUD)操作を実行できます。

- ユーザー操作

- グループ操作

26.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)

26.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)

26.5 アイデンティティ・ディレクトリAPIの例

この項では、次のアイデンティティ・ディレクトリAPIの使用例を紹介します。

- アイデンティティ・ディレクトリ・ハンドルの初期化と取得

- ユーザーの作成

- ユーザーの取得

- ユーザーの変更

- ユーザーの簡易検索

- ユーザーの複合検索

- グループの作成

- グループの取得

- 検索フィルタを使用したグループの取得

- グループの削除

- グループへのメンバーの追加

- グループからのメンバーの削除

26.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=venkat_medam,l=amer,dc=oracle,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=oracle,dc=com");
opConfig.setEntityProperty("User", opConfig.CREATE_BASE,          "l=amer,dc=oracle,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=oracle,dc=com");
opConfig.setEntityProperty("Group", opConfig.CREATE_BASE,          "cn=dlcontainerOCS,dc=oracle,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();
}

26.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@oracle.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=oracle,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;
}

26.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;
}

26.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", "venkatmedam"));

user.modify(attrs, modifyOpts);

System.out.println("Modified user " + user.getName());

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

26.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();
}
}

26.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();
}
}

26.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;
}

26.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;
}

26.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();
}
}

26.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();
}
}

26.5.11 グループへのメンバーの追加

このサンプル・コードでは、グループにメンバーを追加します。

public void addMember() {
try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("amsharma", readOpts);
Group group = gMgr.searchGroup("test1_group1", readOpts);

ModifyOptions modOpts = new ModifyOptions();
user.addMemberOf(group, modOpts);

System.out.println("added amsharma as member of test1_group1");

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

26.5.12 グループからのメンバーの削除

このサンプル・コードでは、グループからメンバーを削除します。

public void deleteMember() {
try {
ReadOptions readOpts = new ReadOptions();
User user = uMgr.searchUser("amsharma", readOpts);
Group group = gMgr.searchGroup("test1_group1", readOpts);

ModifyOptions modOpts = new ModifyOptions();
group.deleteMember(user, modOpts);

System.out.println("deleted amsharma from the group test1_group1");

} catch (Exception e) {
System.out.println(e.getMessage());
e.printStackTrace();
}
}

26.6 SSL構成

アイデンティティ・ディレクトリAPIの使用時のSSL構成の詳細は、第7.5項「アイデンティティ・ストア・サービスでのSSLの使用」を参照してください。

27 キーストア・サービスを使用した開発

この章では、アプリケーションの開発時にキーストア・サービスを利用する方法について説明します。

- キーストア・サービスAPIについて

- キーストア・サービスを使用したアプリケーション開発の概要

- Javaセキュリティ・ポリシーのパーミッションの設定

- キーストア・サービスの構成

- キーストア・サービスAPIの使用方法

- キーストア・サービスAPIの使用例

- ベスト・プラクティス

27.1 キーストア・サービスAPIについて

キーストアは、キーおよび証明書の安全な格納とアクセスに使用します。キーストア・サービスAPIは、キーストアにアクセスして操作を実行するために使用します。

キーストア・サービスの特徴

- キーおよび証明書の安全な管理を可能にします。

- 各種バックエンド・リポジトリでのキーおよび証明書の格納、取得および管理のためのAPIを提供します。

- ファイルベース、データベース・ベースおよびLDAPベースのキーストア管理をサポートします。

キーストア・サービスAPIは、次のような重要な機能(作成、更新、削除)を提供します。

- キーストアの作成

- キーストアの削除

- ドメイン・トラスト・ストアへのハンドルの取得

- キーストアへのハンドルの取得

- キーストアに対する構成済のプロパティの取得

- アプリケーション・ストライプ内のキーストアのリストの取得

KeyStoreに対する操作は、キーストア・サービスで使用されるファイングレイン・アクセス制御モデルを実装するKeyStoreAccessPermissionによって保護されます。

関連項目:

- 第11章「キーストア・サービスでのキーと証明書の管理」

27.2 キーストア・サービスを使用したアプリケーション開発の概要

アプリケーションがキーストア・サービスと連携するように設計するうえで、次の項目に関する知識が役立ちます。

- 使用する適切なアプリケーション・ストライプとキーストア名の決定。

- Javaセキュリティ・ポリシーのプロビジョニング。
ポリシー・パーミッションは、ファイルベース(system-jazn-data.xml)またはLDAPベースのポリシー・ストアに設定されます。データのセキュリティを損なわずにアプリケーションの使用を可能にする適切なパーミッションを設定するには、十分な配慮が必要です。

関連項目:

第9.1項「ポリシー・ストアの管理」

- jps-config.xmlでのキーストア・サービスの定義。
jps-config.xmlでのサービス・インスタンスの定義は、構成ファイルをマニュアルで作成する場合のみ必要です。

注意:

デフォルトでは、ファイルベースのプロバイダが構成されており、これはLDAPベースのプロバイダに変更することができます。第8.6項「OPSSセキュリティ・ストアの移行」を参照してください。

- 環境の設定手順。
スタンドアロン・アプリケーションの場合と、Oracle WebLogic Server環境で動作するアプリケーションの場合は手順が異なります。

27.3 Javaセキュリティ・ポリシーのパーミッションの設定

Oracle Platform Security Servicesキーストア・プロバイダは、サーバーの起動時に設定されます。プロバイダがファイルベースの場合、データはsystem-jazn-data.xmlに格納されます。

キーストア・サービスでは、次のレベルでのキーの保護をサポートしています。

- アプリケーション・ストライプ・レベル

- キーストア・レベル

- 特定の<application stripe, keystore, key>に対するきめ細やかな保護

注意:

- キーストア・サービスAPIに適切にアクセスするには、ポリシー・ストアでJavaパーミッションを付与する必要があります。

- キーストア・サービスAPIを呼び出すコードには、コード・ソースのパーミッションが必要です。パーミッションは通常、特定のコードjarに与えられるものであり、アプリケーション全体には与えられません。

この項では、キーストア・オブジェクトへのパーミッションの付与に関するガイドラインおよびいくつかの例を紹介します。

- パーミッション付与のガイドライン

- パーミッション付与例1

- パーミッション付与例2

- パーミッション付与例3

注意:

この例では、アプリケーションのjarファイル名はAppName.jarです。

27.3.1 パーミッション付与のガイドライン

キーストア・サービスでは、Javaパーミッションを使用して、キーストアまたはキー・オブジェクトにパーミッションを付与します。必要なパーミッションのみを付与して、それ以外は付与しないことを強くお薦めします。

警告:

不要なパーミッション、特にすべてのアプリケーション・ストライプやキーストアにアクセスできるパーミッションを付与することは危険であり、お薦めできません。

27.3.2 パーミッション付与例1

キーストア・サービスでは、オブジェクトは階層に格納されます。

アプリケーション・ストライプ -> キーストア -> キー/証明書

関連項目:

キーストア・サービスのオブジェクト階層の詳細は、第11.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はキーストア内のキー別名を示します。

注意:

ワイルドカードは、すべての別名に対するパーミッションがアプリケーションに付与されることを意味します。

27.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>

27.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>

27.4 キーストア・サービスの構成

キーストアの場所とプロバイダ・クラスに関する情報が含まれている構成ファイル内で、キーストア・サービス・インスタンスを定義する必要があります。構成ファイルは、次の場所にあります。

$DOMAIN_HOME/config/fmwconfig

名前は次のとおりです。

- jps-config.xml(Oracle WebLogic Serverの場合)

- jps-config-jse.xml(Java SEの場合)

27.5 キーストア・サービスAPIの使用方法

キーストア・サービスは、Oracle WebLogic Server内またはスタンドアロン環境で使用できます。

- スタンドアロン環境でのキーストア・サービスAPIの使用方法

- Oracle WebLogic Serverでのキーストア・サービスAPIの使用方法

27.5.1 スタンドアロン環境でのキーストア・サービスAPIの使用方法

スタンドアロン環境でAPIを使用する手順は、次のとおりです。

1. クラスパスを設定します。jps-manifest.jarファイルがそのクラスパスに入っていることを確認します。詳細は、第1.5.3項「シナリオ3: Java SEアプリケーションの保護」の「クラスパスで指定する必要のあるJAR」を参照してください。

2. ポリシーを設定します。キーストア・サービスAPIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第27.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. アプリケーションを実行します。

コマンドライン・オプションは次のとおりです。

- -Doracle.security.jps.config

構成ファイルのフルパスを指定します。

- -Djava.security.policy

OPSSおよびOracle WebLogic Serverのポリシー・ファイルの場所を指定します。

- -Djava.security.debug=all

デバッグに役立ちます。

27.5.2 Oracle WebLogic Serverでのキーストア・サービスAPIの使用方法

Oracle WebLogic Server環境でAPIを使用する手順は、次のとおりです。

1. 出荷時、jps-config.xmlファイルのキーストア・サービス・プロバイダ・セクションは、次のディレクトリに構成されています。

$DOMAIN_HOME/config/fmwconfig

必要に応じて、LDAPストアまたはデータベース・ストアへの再関連付けを行ってください。

2. ポリシーを設定します。キーストア・サービスAPIにアクセスできるようにするには、参照ポリシー・ストアでアクセス・パーミッションを構成する必要があります。例は、第27.3項「Javaセキュリティ・ポリシーのパーミッションの設定」を参照してください。

3. Oracle WebLogic Serverを起動します。

4. アプリケーションをデプロイしてテストします。

27.6 キーストア・サービスAPIの使用例

この項では、キーストア・サービスAPIの使用例を紹介します。次のトピックが含まれます:

- キーストア・サービス操作用のJavaプログラム

- ポリシー・ストアのセットアップ

- 構成ファイル

- Java SE環境でのキーストア・サービスの使用について

27.6.1 キーストア・サービス操作用のJavaプログラム

次のJavaコードは、一般的なキーストア・サービス操作を示しています。

import oracle.security.jps.JpsContext;
import oracle.security.jps.JpsContextFactory;
import oracle.security.jps.JpsException;
import oracle.security.jps.internal.policystore.JavaPolicyProvider;
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 {

static {
java.security.Policy.setPolicy(new JavaPolicyProvider());
}

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();
}

/*
* 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 {

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();
}

}
}

27.6.2 ポリシー・ストアのセットアップ

この例では、ストアから特定のキーストアへのアクセスに必要とされる適切なパーミッションを持つ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>

27.6.3 構成ファイル

サンプル構成ファイル(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>

27.6.4 Java SE環境でのキーストア・サービスの使用について

Java SE環境では、次の2つのコールは同等です。

KeyStoreService store = JpsServiceLocator.getServiceLocator().lookup(KeyStoreService.class);

および

KeyStoreService store = JpsContextFactory.getContextFactory().getContext().getServiceInstance
(KeyStoreService.class);

27.7 ベスト・プラクティス

クラスタ環境では、キーストア・サービスAPI上でキーストア・サービスMBean APIを使用して、アプリケーションに対するキーの作成、取得、更新および削除を行います。

ただし、単にキーを読み取るだけの場合は、いずれのAPIも使用できます。

28 監査サービスを使用した開発

この章では、アプリケーション(監査クライアントとも呼ばれます)がどのようにOracle Fusion Middleware監査フレームワークを使用して監査機能を提供するかを説明します。11gリリース1(11.1.1.6)では、監査サービスが導入されています。このサービスは、アプリケーションをプログラム的に監査フレームワークに統合することにより、Oracleコンポーネントで使用可能な機能を使用して、監査イベントをログに記録し、コンプライアンス・レポートを生成することを可能にします。

監査サービスを使用して、アプリケーションは次のことを行えます:

- カスタム表を使用せずにイベント定義を作成する

- アプリケーションのデプロイ時に監査サービスに登録する

- アプリケーションの再デプロイ時にイベント定義を変更する

- 実行時に監査構成設定を変更する

この章の内容は次のとおりです。

- 監査フローへのアプリケーションの統合

- 監査メタデータ・モデル

- 監査メタデータ・ストア

- 監査フレームワークへのアプリケーションの統合

- 監査定義ファイルの作成

- 登録サービスへのアプリケーションの登録

- 監査イベントを記録するためのアプリケーション・コードの追加

- Oracle Business Intelligence Publisherとの統合

- 監査定義の更新と保守

28.1 監査フローへのアプリケーションの統合

図28-1に示すように、Oracle WebLogic Server上で動作するJava EEアプリケーションは、シームレスに監査フレームワークに統合でき、それを活用できます。

図28-1 監査フレームワークへのアプリケーションの統合

アプリケーションのデプロイメント時または監査サービスの起動時に、Java EEアプリケーションまたはOracleコンポーネントなどのクライアントが監査サービスに登録されます。登録サービスは、component_events.xmlおよび関連ファイルに含まれる最新の監査定義でメタデータ・ストアを更新します。

関連項目:

監査フローの詳細は、第12.3項を参照してください。

この章の残りの項では、メタデータ・モデルの詳細、およびアプリケーションを監査フローに統合することにより監査イベントを記録して監査レポートを作成する方法について説明します。

28.2 監査メタデータ・モデル

監査フレームワークは、アプリケーションがその監査アーティファクトを柔軟に指定することを可能にするメタデータ・モデルをサポートしています。アプリケーションは属性グループ、カテゴリおよびイベントを動的に定義できます。

28.2.1 属性グループ

属性グループは監査属性の広範な分類を提供し、次の3つのタイプから構成されます。

- 共通属性グループには、コンポーネント・タイプ、システムIPアドレス、ホスト名など、すべてのアプリケーションに共通のシステム属性が含まれます。
IAU_COMMONデータベース表には、このグループ内の属性が含まれます。

- 汎用属性グループには、認証やユーザー・プロビジョニングなどの監査アプリケーション領域に対する属性が含まれます。

- カスタム属性グループには、特定のニーズに応じてアプリケーションで定義された属性が含まれます。カスタム・グループの属性は、そのコンポーネントのスコープに限定されます。

28.2.1.1 監査属性のデータ型

表28-1に、サポートされる属性のデータ型と対応するJavaオブジェクト・タイプを示します。

表28-1 監査属性のデータ型

属性のデータ型

Javaオブジェクト・タイプ

注意

Integer

Integer

Long

Long

Float

Float

Double

Double

Boolean

Boolean

DateTime

java.util.Date

String

String

最大長2048バイト

LongString

String

無限長

Binary

byte[]

28.2.1.2 共通属性グループ

共通属性グループは、IAU_COMMONデータベース表に格納されています。

28.2.1.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

28.2.1.4 カスタム属性グループ

カスタム属性グループは、ネームスペース、バージョン番号および1つ以上の属性で定義されます。

属性は次のものから構成されます。

- 属性名

- データ型

- 属性/データベース列マッピング順序(属性が、カスタム属性表内の特定のデータ型のデータベース列にマップされる順序を指定します)

- ヘルプ・テキスト(オプション)

- 最大長

- 表示名

この例は、ネームスペース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>

カスタム属性グループおよび属性は、IAU_CUSTOM表に格納されます。

28.2.2 イベント・カテゴリとイベント

監査イベント・カテゴリには、機能領域内の関連イベントが含まれます。たとえば、セッション・カテゴリには、ユーザー・セッションのライフ・サイクルで重要なログインおよびログアウト・イベントが含まれます。

イベント・カテゴリ自体は属性を定義しません。かわりに、コンポーネント内の属性およびシステム属性グループを参照します。

イベント・カテゴリには次の2つのタイプがあります。

- システム・カテゴリ

- コンポーネントとアプリケーション・カテゴリ

28.2.2.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>

28.2.2.2 コンポーネント/アプリケーション・カテゴリ

コンポーネントまたはアプリケーションは、システム・カテゴリを拡張するか、新しいコンポーネント・イベント・カテゴリを定義できます。この例では、トランザクション・カテゴリはaccounting属性グループの属性AccountNumber、DateおよびAmountを参照し、イベントpurchaseおよびdepositを含みます。

<Category displayName="Transaction" name="Transaction">
<Attributes>
<Attribute name="AccountNumber" ns="accounting" version="1.0"/>
<Attribute name="Date" ns="accounting" version="1.0" />
<Attribute name="Amount" ns="accounting" version="1.0" />
</Attributes>

<Event displayName="purchase" name="purchase"/>
<Event displayName="deposit" name="deposit">
<HelpText>depositing funds.</HelpText>
</Event>
……
</Category>

システム・カテゴリを拡張するには、アプリケーション監査定義内にカテゴリ参照を作成します。システム・カテゴリに含まれるシステム・イベントをリストし、そこに新しい属性参照およびイベントを追加します。

この例では、新しいカテゴリが、新しい属性参照ServiceTimeと新しいイベントrestartServiceで、システム・カテゴリServiceManagementを参照します。

<CategoryRef name="ServiceManagement" componentType="SystemComponent">
<Attributes>
<Attribute name="ServiceTime" ns="accounting" version="1.0" />
</Attributes>

<EventRef name="startService"/>
<EventRef name="stopService"/>

<Event displayName="restartService" name="restartService">
<HelpText>restart service</HelpText>
</Event>

</CategoryRef>

28.3 監査メタデータ・ストア

監査メタデータ・ストアはメタデータ・モデルに対するリポジトリを提供し、コンポーネント監査定義、NLS翻訳エントリ、実行時ポリシーおよびデータベース・マッピング表を含みます。

注意:

メタデータ・ストアは監査データ・ストアとは別のものです。

監査メタデータ・ストアは、次のような重要な監査機能をサポートします。

- 監査登録サービスは、イベント定義エントリを作成、変更および削除します。

- 監査実行時サービスは、イベント定義および実行時ポリシーを取得します。

- 監査データ・ローダーは、監査データを格納するための属性データベース・マッピングを作成します。

- 監査MBeanコマンドは、コンポーネント監査定義および実行時ポリシーを検索して変更します。

監査フレームワークは、次の3つのタイプのメタデータ・ストアをサポートしています。

- XMLファイルベース

- データベース

- LDAP

新しいアプリケーションが監査サービスに登録されると、次の監査アーティファクトが監査ストアに格納されます。

- カスタム属性グループ、カテゴリ、イベントおよびフィルタ・プリセット定義を含む監査イベント定義

- ローカライズされた翻訳エントリ

- カスタム属性/データベース列マッピング表

- 実行時監査ポリシー

28.4 監査フレームワークへのアプリケーションの統合

アプリケーションを監査フレームワークに統合するには、次の手順を実行します。

1. 監査定義ファイルcomponent_events.xmlを作成します。

2. アプリケーションのEARファイルにcomponent_events.xmlファイルをパッケージ化します。

3. 監査イベントを記録できるように、監査イベントAPIをアプリケーション・コードに追加します。

4. レポート用にOracle Business Intelligence Publisherを統合します。

5. 監査イベント定義を更新し、必要に応じて再デプロイします。

次の各項では、これらのタスクについて詳しく説明します。

- 監査定義ファイルの作成

- 登録サービスへのアプリケーションの登録

- 監査イベントを記録するためのアプリケーション・コードの追加

- Oracle Business Intelligence Publisherとの統合

- 監査定義の更新と保守

28.5 監査定義ファイルの作成

このタスクでは、次のファイルを作成します。

- component_events.xml定義ファイル

- 翻訳ファイル

component_events.xmlファイル

component_events.xmlファイルには次の要素が含まれます。

- 基本プロパティとメジャーおよびマイナー・バージョン

- コンポーネント・タイプ(アプリケーションが監査サービスに登録し、実行時監査インスタンスを取得するために使用するプロパティ)

- アプリケーションのメジャーおよびマイナー・バージョン

- 1つのカスタム属性グループ(含まれない場合もある)

- 属性参照およびイベントを含むイベント・カテゴリ

- コンポーネント・レベル・フィルタ定義

- 次を含む実行時ポリシー

- filterPreset: 監査フィルタ・レベルを指定します。

- Custom FilterPresetDefinition: カスタム・フィルタ・プリセット定義を指定します。

- specialUsers: 常に監査するユーザーを指定します。

- maxBusstopDirSize

- maxBusstopFileSize

実行時ポリシーの詳細は、第13.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>

翻訳ファイル

アプリケーションに必要な翻訳ファイルを作成します。

翻訳ファイルは、様々な言語で監査定義を表示するために使用されます。ファイルはXLIFF形式で生成します。登録時に、この情報はコンポーネント監査イベント定義とともに監査メタデータ・ストアに格納されます。

28.5.1 マッピングとバージョニング・ルールについて

監査定義ファイルの作成時には、アプリケーションに対する監査メタデータの作成時に登録サービスが使用する特定のルールについて理解する必要があります。このメタデータは、監査定義の様々なバージョンを管理し、監査データをロードしてレポートを生成するために使用されます。

28.5.1.1 バージョン番号

各監査定義には、整数のメジャーおよびマイナー・バージョン番号が必要です(例: major = 1 minor=3)。監査イベント定義を変更した場合は、マイナーまたはメジャー番号あるいはその両方を変更することによりバージョンIDを変更する必要があります。

監査登録サービスは、バージョン番号を使用してイベント定義の互換性およびバージョン間の属性マッピングを決定します。

注意:

これらのバージョン番号はOracle Fusion Middlewareのバージョン番号とは関係ありません。

Oracleコンポーネントのバージョニング

Oracle Virtual DirectoryなどのOracleコンポーネントの登録時、監査登録サービスは、これが初めての登録であるかアップグレードであるかを確認します。

新規登録では、サービスは次の操作を実行します。

1. コンポーネントの監査および翻訳情報を取得します。

2. 定義を解析して検証し、監査メタデータ・ストアに格納します。

3. 属性/列マッピング表を生成し、監査メタデータ・ストアに保存します。

アップグレードについては、メタデータ・ストア内のコンポーネントの現在のメジャーおよびマイナー番号が新しいメジャーおよびマイナー番号と比較され、アップグレードを続行するかどうかを決定します。

JavaEEアプリケーションのバージョニング

アプリケーションの監査定義の変更時には、メジャーおよびマイナー番号を次のように設定することをお薦めします。

- マイナー・バージョン番号は、バージョン互換の変更(新しい監査定義から生成される属性データベース・マッピング表が、以前の属性データベース・マッピング表で作成された監査データでもそのまま使用できるような監査定義の変更)を加える場合にのみ増やします。
たとえば、現在の定義バージョンがmajor=2およびminor=1であるとします。属性データベース・マッピング表に影響しない新規イベントの追加時には、マイナー・バージョンを2に変更し(minor=2)、メジャー番号はそのままにします(major=2)。

- 新しいマッピング表が以前の表と互換性がないようなバージョン変更を加える場合には、メジャー・バージョン番号を増やします。

28.5.1.2 カスタム属性からデータベース列へのマッピング

新しいコンポーネントまたはアプリケーションの登録時、登録サービスはコンポーネントのカスタム属性から属性/データベース列マッピング表を作成し、この表を監査メタデータ・ストアに保存します。

属性/データベース列マッピング表は、アプリケーションの属性定義とデータベース列間で一意なマッピングを行うために必要です。監査ローダーはマッピング表を使用してデータを監査ストアにロードします。表はカスタム・データベース表IAU_CUSTOMから監査レポートを生成するためにも使用されます。

カスタム属性/データベース列マッピングには、属性名、データベース列名およびデータ型のプロパティがあります。

各カスタム属性定義には、マッピング順序番号が含まれている必要があります。同じデータ型の属性は、属性マッピング順序に従ってデータベース列にマップされます。たとえば、次のような定義ファイルがあるとします。

<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に一致します。これにより、アプリケーションは異なる監査定義バージョン間でも、属性マッピングの下位互換性を維持できます。バージョニングの詳細は、第28.5.1.1項を参照してください。

28.6 登録サービスへのアプリケーションの登録

Java EEアプリケーションは、component_events.xmlとcomponent_events_xlf.jarを、アプリケーションEARファイルのMETA-INFフォルダにパッケージ化することにより登録できます。監査登録サービスはアプリケーションのデプロイ時にそれらを自動的に処理します。

次のオプションがあります。

- デプロイ: アプリケーションがまだ登録されていなければ、監査イベント定義を監査メタデータ・ストアに登録します。

- 再デプロイ: コンポーネントがすでに登録済であれば、コンポーネントの監査イベント定義をアップグレードします。詳細は28.5.1項を参照してください。

- アンデプロイ: アプリケーションの監査イベント定義を監査メタデータ・ストアから削除します。

登録パラメータはOPSSデプロイメント・ディスクリプタopss-application.xmlで設定されます。これもアプリケーションEARファイルのMETA-INFフォルダにパッケージ化されます。表28-2に、パラメータとそのオプションを示します。

表28-2 監査登録サービスのパラメータ

パラメータ

オプション

説明

opss.audit.registration

OVERWRITE

登録されているかどうかにかかわらず、コンポーネント監査定義を登録します。

UPGRADE

バージョニングのサポートに応じてコンポーネント監査定義を登録します。

DISABLE

コンポーネント監査定義を登録しません。

opss.audit.deregistration

DELETE(デフォルト・オプション)

アプリケーションのアンデプロイ時に、コンポーネント監査定義を監査ストアから削除します。

DISABLE

アプリケーションのアンデプロイ時に、コンポーネント監査定義を監査ストアに残します。

28.7 監査イベントを記録するためのアプリケーション・コードの追加

アプリケーションはプログラムにより実行時監査サービスにアクセスし、クライアントAPIを使用して独自の監査イベントを生成できます。

28.7.1 監査クライアントAPI

監査クライアントAPIは次のとおりです。

Interface AuditService {

Auditor getAuditor(String componentType);

void register(AuditRegistration auditRegistration);

void unregister(AuditRegistration auditRegistration);

}

Interface Auditor {

boolean log(AuditEvent ev);

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 setInitiator(String initiator);
public void setAttributeBoolean(String attributeName, Boolean attributeValue);
public void setAttributeDouble(String attributeName, double attributeValue);
public void setAttributeDate(String attributeName, Date attributeValue);
public void setAttributeByteArray(String attributeName, byte[] attributeValue);
public void setAttributeFloat(String attributeName, float attributeValue);
public void setAttributeLong(String attributeName, long attributeValue);
public void setAttributeInt(String attributeName, int attributeValue);
public void setAttributeString(String attributeName, String attributeValue);
public void setAttribute(String attributeName, Object attributeValue)

}

次の各項では、パーミッションおよび実行時監査インスタンスの取得方法について説明します。

28.7.2 システム権限の設定

監査サービスから監査インスタンスを取得するには、システム権限が必要です。この例では、権限によりアプリケーション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>MyApp</name>
<actions>read</actions>
</permission>
</permissions>
</grant>

28.7.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);
}

28.8 Oracle Business Intelligence Publisherとの統合

Oracle Business Intelligence Publisherを利用することにより、Oracleコンポーネントで使用可能なものと同じレポート機能を使用して、アプリケーションの監査データからレポートを生成できます。

基本手順は次のとおりです。

1. マッピング表を使用して、Oracle BI Publisherレポート・テンプレートを生成します。

2. Oracle BI Publisherレポート・サービスを設定します。

3. レポート・テンプレートをOracle BI Publisherにコピーして、コンポーネント監査イベントを表示します。

4. Oracle BI Publisherでレポートを生成します。

関連項目:

第14章「監査分析と監査レポートの使用」

28.9 監査定義の更新と保守

アプリケーションの監査要件の変化に応じて、変化を反映するように統合を更新できます。手順は、次のとおりです:

1. 監査ファイル定義を更新します。この手順の実行時にはバージョニング・ルールに注意してください。

関連項目:

第28.5.1項「マッピングとバージョニング・ルールについて」

2. 更新されたイベント定義ファイルとともにアプリケーションEARファイルを再デプロイします。または、監査登録サービスに新しいバージョンの存在を通知することもできます。

3. 変更を検証します。

第VI部

付録

このパートは、次の付録で構成されています。

- 付録A「OPSS構成ファイル・リファレンス」

- 付録B「ファイルベースのアイデンティティ・ストアとポリシー・ストアのリファレンス」

- 付録C「Oracle Fusion Middleware監査フレームワーク・リファレンス」

- 付録D「ユーザーおよびロールAPIリファレンス」

- 付録E「WLSTスクリプトおよびMBeanプログラミングを使用した管理」

- 付録F「OPSSのシステムおよび構成プロパティ」

- 付録G「セキュリティ・データのアップグレード」

- 付録H「リファレンス」

- 付録I「OPSSスクリプト」

- 付録J「OpenLDAPアイデンティティ・ストアの使用」

- 付録L「Oracle Fusion Middlewareのセキュリティのトラブルシューティング」

A OPSS構成ファイル・リファレンス

この付録では、OPSSサービスを構成するファイルの要素階層と属性について説明します。デフォルトでは、このファイルの名前はjps-config.xml(Java EEアプリケーションの場合)またはjps-config-jse.xml(Java SEアプリケーションの場合)であり、ディレクトリ$DOMAIN_HOME/config/fmwconfigに格納されています。

Java SEアプリケーションの場合は、システム・プロパティoracle.security.jps.configを使用して別の場所を指定できます。

構成ファイルを使用して、ポリシー、資格証明、アイデンティティ・ストア、ログイン・モジュールおよび監査サービスを構成できます。完全な構成ファイルの例は、第21.4.9項「構成ファイルjps-config.xmlの例」を参照してください。

プログラムによるサービスの構成方法は、第E.2項「MBeansを使用したOPSSサービスの構成」を参照してください。

この付録の内容は次のとおりです。

- トップレベルおよび第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項「WLSTスクリプトを使用した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.maxDirSize" value="102400" />
<property name="audit.maxFileSize" value="10240" />
<property name=" audit.loader.repositoryType " value="Db" />
</serviceInstance>
</serviceInstances>

関連項目:

- ここで参照されているサービス・プロバイダの定義の例については、<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アプリケーションに対してのみサポートされます。

この付録の内容は次のとおりです。

- system-jazn-data.xmlの要素の階層

- 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>
|   <role-category>
|      <name>
|      <display-name>
|      <description>
|      <members>
|         <role-name-ref>
<resource-types>
|   <resource-type>
|      <name>
|      <display-name>
|      <description>
|      <provider-name>
|      <matcher-class>
|      <actions-delimiter>
|      <actions>
<resources>
|    <resource>
|       <name>
|       <display-name>
|       <description>
|       <type-name-ref>
<permission-sets>
|   <permission-set>
|       <name>
|       <member-resources>
|          <member-resource>
|              <resource-name>
|              <type-name-ref>
|              <actions>
<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>
...
<resource-types>
<resource-type>
<name>
<display-name>
<description>
<provider-name>
<matcher-class>
<actions-delimiter>
<actions>

例

例については、<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>
...
<permission-sets>
<permission-set>
<name>
<member-resources>
<member-resource>
<resource-name>
<type-name-ref>
<actions>

例

例については、<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>
...
<permission-sets>
<permission-set>
<name>
<member-resources>
<member-resource>
<resource-name>
<type-name-ref>
<actions>

例

例については、<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を使用します。外部(サード・パーティ)のLDAPサーバーについては、グループの所有者の属性値は、ldapmodifyまたは特定のディレクトリ・サーバーのツールを使用して設定します。

親要素

<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>
...
<permission-sets>
<permission-set>
<name>
<member-resources>
<member-resource>
<resource-name>
<type-name-ref>
<actions>

例

次のコードは、パーミッション・セット(または権限)の構成を示しています。

<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>
...
<permission-sets>
<permission-set>
<name>
<member-resources>
<member-resource>
<resource-name>
<type-name-ref>
<actions>

例

例については、<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>
...
<resource-types>
<resource-type>
<name>
<display-name>
<description>
<provider-name>
<matcher-class>
<actions-delimiter>
<actions>

例

例については、<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>の下に必要です。

<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>
...
<permission-sets>
<permission-set>
<name>
<member-resources>
<member-resource>
<resource-name>
<type-name-ref>
<actions>

例

例については、<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>
...
<resource-types>
<resource-type>
<name>
<display-name>
<description>
<provider-name>
<matcher-class>
<actions-delimiter>
<actions>

例

次のコードは、リソース・タイプの構成を示しています。

<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>
...
<resource-types>
<resource-type>
<name>
<display-name>
<description>
<provider-name>
<matcher-class>
<actions-delimiter>
<actions>

例

例については、<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>
<role-category>
<name>
<description>
<display-name>

例

例については、第20.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>
<role-category>
<name>
<description>
<display-name>
<members>

例

例については、第20.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>
<role-category>
<name>
<description>
<members>
<role-name-ref>

<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>

子要素

なし

出現

<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が必要だとします。

On WebLogic
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/myApp/-</url>
</codesource>
</grantee>
<permissions> ... </permissions>
</grant>

On WebSphere
<grant>
<grantee>
<codesource>
<url>file:${user.install.root}/installedApps/${was.cell.name}/myApp/-</url>
</codesource>
</grantee>
<permissions> ... </permissions>
</grant>

その後、次のシステム変数設定を使用します。

On WebLogic
-Doracle.deployed.app.dir=${DOMAIN_HOME}/servers/${SERVER_NAME}/tmp/_WL_user
-Doracle.deployed.app.ext=/-

On WebSphere
-Doracle.deployed.app.dir=${USER_INSTALL_ROOT}/installedApps/${CELL}
-Doracle.deployed.app.ext=.ear/-

次の指定は、WebLogicとWebSphere両方のプラットフォームで有効です。

<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監査フレームワークに関する参照情報が含まれています。次のトピックが含まれます:

- 監査イベント

- ビルトイン監査レポート

- 監査スキーマ

- 監査のためのWLSTコマンド

- 監査フィルタ式の構文

- 監査ファイルの命名およびロギング形式

C.1 監査イベント

この項では、監査対象のコンポーネントと監査可能なイベント・タイプについて説明します。

C.1.1 監査可能なコンポーネント

11g リリース1(11.1.1)では、特定のJavaコンポーネントとシステム・コンポーネントで監査レコードを生成できます。これらのコンポーネントは監査対応コンポーネントと呼ばれます。

監査可能なJavaコンポーネント

Fusion Middleware監査フレームワークを使用して監査できるコンポーネントは、次のとおりです。

- ディレクトリ統合プラットフォーム・サーバー

- Oracle Platform Security Services

- Oracle Web Services Manager

- エージェント

- ポリシー・マネージャ

- ポリシー・アタッチメント

- Oracle Webサービス

- Oracle Identity Federation

- Reportsサーバー

監査可能なシステム・コンポーネント

Fusion Middleware監査フレームワークを使用して監査できるコンポーネントは、次のとおりです。

- Oracle HTTP Server

- Oracle Web Cache

- Oracle Internet Directory

- Oracle Virtual Directory

C.1.2 監査可能なイベント

この項に記載する表では、監査可能なイベント・タイプを監査対応システム・コンポーネントおよびサブコンポーネント別に説明しています。

- Oracle Directory Integration Platformのイベントとその属性

- Oracle Platform Security Servicesのイベントとその属性

- Oracle HTTP Serverのイベントとその属性

- Oracle Internet Directoryのイベントとその属性

- Oracle Identity Federationのイベントとその属性

- Oracle Virtual Directoryのイベントとその属性

- OWSM-Agentのイベントとその属性

- OWSM-PM-EJBのイベントとその属性

- Reportsサーバーのイベントとその属性

- WSポリシー・アタッチメントのイベントとその属性

- Oracle Web Cacheのイベントとその属性

- Oracle Web Services Managerのイベントとその属性

C.1.2.1 Oracle Directory Integration Platformのイベントとその属性

表C-1 Oracle Directory Integration Platformのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

ServiceUtilize

InvokeService

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

TerminateService

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

SynchronizationEvents

Add

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、AssociateProfileName、ProfileName、EntryDN

Modify

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、AssociateProfileName、ProfileName、EntryDN

Delete

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、AssociateProfileName、ProfileName、EntryDN

ProvisioningEvents

UserAdd

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

UserModify

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

UserDelete

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

GroupAdd

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

GroupModify

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

GroupDelete

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

IdentityAdd

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

IdentityModify

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

IdentityDelete

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

SubscriptionAdd

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

SubscriptionModify

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

SubscriptionDelete

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、ProfileName、ProvEvent

ProfileManagementEvents

DeleteProvProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

UpdateProvProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

ActivateProvProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

DeactivateProvProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

CreateSyncProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

DeleteSyncProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

UpdateSyncProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

ActivateSyncProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

DeactivateSyncProfile

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

SyncProfileUpdateChgNum

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

ExpressSyncSetup

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

SyncProfileBootstrap

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

SyncProfileExtAuthPlugins

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

ProvProfileBulkProv

ComponentType、InstanceId、HostId、HostNwaddr、ModuleId、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode

SchedulerEvents

AddJob

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、JobName、JobType

RemoveJob

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、JobName、JobType

C.1.2.2 Oracle Platform Security Servicesのイベントとその属性

表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.1.2.3 Oracle HTTP Serverのイベントとその属性

表C-3 Oracle HTTP Serverのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

UserLogin

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AuthenticationMethod、Reason

UserLogout

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AuthenticationMethod、Reason

認証

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AuthenticationMethod、Reason、SSLConnection

Authorization

CheckAuthorization

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、Reason、AuthorizationType

C.1.2.4 Oracle Internet Directoryのイベントとその属性

表C-4 Oracle Directory Integration Platformのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

UserLogin

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Roles、custEventStatusDetail、custEventOp、AuthenticationMethod

UserLogout

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Roles、custEventStatusDetail、custEventOp

Authorization

CheckAuthorization

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

DataAccess

ModifyDataItemAttributes

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、custEventStatusDetail、custEventOp

CompareDataItemAttributes

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、custEventStatusDetail、custEventOp

AccountManagement

ChangePassword

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

CreateAccount

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

DeleteAccount

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

DisableAccount

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

EnableAccount

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

ModifyAccount

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

LockAccount

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、custEventStatusDetail、custEventOp

LDAPEntryAccess

custInternalOperation

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、custEventStatusDetail、custEventOp

C.1.2.5 Oracle Identity Federationのイベントとその属性

表C-5 Oracle Identity Federationのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

LocalAuthentication

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、SessionID、AuthenticationMethod、UserID、AuthenticationMechanism、AuthenticationEngineID

LocalLogout

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、SessionID、AuthenticationMethod、UserID

CreateUserSession

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、SessionID、AuthenticationMethod、UserID、AuthenticationMechanism

DeleteUserSession

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、SessionID、AuthenticationMethod、UserID

CreateUserFederation

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、FederationID、UserID、FederationType

DeleteUserFederation

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、FederationID、UserID、FederationType

CreateActiveUserFederation

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、RemoteProviderID、ProtocolVersion、SessionID、FederationID、AuthenticationMethod、UserID、FederationType

DeleteActiveUserFederation

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、RemoteProviderID、ProtocolVersion、SessionID、FederationID、AuthenticationMethod、UserID、FederationType

UpdateUserFederation

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、FederationID、UserID、FederationType、OldNameIDQualifier、OldNameIDValue

ProtocolFlow

IncomingMessage

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、RemoteProviderID、ProtocolVersion、Binding、Role、UserID、MessageType、IncomingMessageString、IncomingMessageStringCLOB

OutgoingMessage

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、RemoteProviderID、ProtocolVersion、Binding、Role、UserID、MessageType、OutgoingMessageString、OutgoingMessageStringCLOB

AssertionCreation

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、UserID、AssertionVersion、IssueInstant、Issuer、AssertionID

AssertionConsumption

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、UserID、AssertionVersion、IssueInstant、Issuer、AssertionID

Security

CreateSignature

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、Type

VerifySignature

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、Type

EncryptData

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、Type

DecryptData

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、Type

ServerConfiguration

ChangeCOT

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、COTBefore、COTAfter

ChangeServerProperty

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、ServerConfigBefore、ServerConfigAfter

ChangeDataStore

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、DataStoreBefore、DataStoreAfter

CreateConfigProperty

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、PropertyName、PropertyType、PeerProviderID、PropertyContext、NewValue

ChangeConfigProperty

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、PropertyName、PropertyType、PeerProviderID、PropertyContext、OldValue、NewValue

DeleteConfigProperty

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、PropertyName、PropertyType、PeerProviderID、PropertyContext、Description、OldValue

CreatePeerProvider

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、PeerProviderID、Description、ProviderType

UpdatePeerProvider

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、PeerProviderID、Description、ProviderType

DeletePeerProvider

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、RemoteProviderID、ProtocolVersion、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、PeerProviderID、Description、ProviderType

LoadMetadata

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、Description、Metadata

SetDataStoreType

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、RemoteProviderID、NameIDQualifier、NameIDValue、NameIDFormat、SessionID、FederationID、OldValue、NewDataStoreType、DataStoreName

C.1.2.6 Oracle Virtual Directoryのイベントとその属性

表C-6 Oracle Virtual Directoryのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

UserLogin

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、AuthenticationMethod

UserLogout

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

Authorization

CheckAuthorization

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

DataAccess

QueryDataItemAttributes

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

ModifyDataItemAttributes

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

CompareDataItemAttributes

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

ServiceManagement

RemoveService

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、ServiceOperation

ModifyServiceConfig

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、ServiceOperation

AddService

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、ServiceOperation

LDAPEntryAccess

Add

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

Delete

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

Modify

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

Rename

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

Compare

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

C.1.2.7 OWSM-Agentのイベントとその属性

表C-7 OWSM-Agentのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

認証

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AssertionName、CompositeName、Endpoint、AgentMode、ModelObjectName、Operation、ProcessingStage、Version、Protocol

Authorization

CheckAuthorization

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AssertionName、CompositeName、Endpoint、AgentMode、ModelObjectName、Operation、ProcessingStage、Version、Protocol

PolicyEnforcement

EnforceConfidentiality

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AssertionName、CompositeName、Endpoint、AgentMode、ModelObjectName、Operation、ProcessingStage、Version、Protocol

EnforceIntegrity

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AssertionName、CompositeName、Endpoint、AgentMode、ModelObjectName、Operation、ProcessingStage、Version、Protocol

EnforcePolicy

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Resource、AssertionName、CompositeName、Endpoint、AgentMode、ModelObjectName、Operation、ProcessingStage、Version、Protocol

C.1.2.8 OWSM-PM-EJBのイベントとその属性

表C-8 OWSM-PM-EJBのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

AssertionTemplateAuthoring

CreateAssertionTemplate

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、Resource、Version

DeleteAssertionTemplate

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、Resource、Version、ToVersion

ModifyAssertionTemplate

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、Resource、Version

PolicyAuthoring

CreatePolicy

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、Resource、Version

DeletePolicy

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、Resource、Version、ToVersion

ModifyPolicy

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、Resource、Version

C.1.2.9 Reportsサーバーのイベントとその属性

表C-9 Reportsサーバーのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

UserLogin

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

Authorization

CheckAuthorization

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

C.1.2.10 WSポリシー・アタッチメントのイベントとその属性

表C-10 WSポリシー・アタッチメントのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

PolicyAttachment

PolicyAttachmentEvent

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、PolicyChangeType、PolicyURI、PolicyCategory、PolicyStatus、ServiceEndPoint、PolicySubjRescPattern

C.1.2.11 Oracle Web Cacheのイベントとその属性

表C-11 Oracle Web Cacheのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

UserSession

UserLogin

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、AuthenticationMethod

UserLogout

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、AuthenticationMethod

Authorization

CheckAuthorization

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

DataAccess

FilterRequest

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

ServiceManagement

ModifyServiceConfig

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

ConfigServicePermissions

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

ServiceUtilize

InvokeService

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

TerminateService

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

PeerAssocManagement

CreatePeerAssoc

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

TerminatePeerAssoc

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

ChallengePeerAssoc

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

Authentication

ClientAuthentication

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

ServerAuthentication

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

C.1.2.12 Oracle Web Services Managerのイベントとその属性

表C-12 Oracle Web Services Managerのイベント

イベント・カテゴリ

イベント・タイプ

イベントで使用される属性

WS-Processing

RequestReceived

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Protocol、Endpoint、Operation、FaultUrl

ResponseSent

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、Protocol、Endpoint、Operation、FaultUri

WS-Fault

SoapFaultEvent

ComponentType、InstanceId、HostId、HostNwaddr、ProcessId、OracleHome、HomeInstance、ECID、RID、ContextFields、SessionId、TargetComponentType、ApplicationName、EventType、EventCategory、EventStatus、TstzOriginating、ThreadId、ComponentName、Initiator、MessageText、FailureCode、RemoteIP、Target、Resource、URI、Source、Protocol、Endpoint、Operation

C.1.3 イベント属性の説明

ここでは、すべての監査イベントに対するすべての属性を示します。この表を使用して、目的のイベントで使用される属性について理解してください。

表C-13 監査イベントの属性

属性名

説明

AgentMode

エージェントがポリシー施行を実行したモード

ApplicationName

Java EEアプリケーション名

ApplicationRole

ロール・メンバーシップ管理のアプリケーション・ロール監査に使用される属性

AssertionID

アサーションのAssertionID属性の値

AssertionName

施行に失敗したアサーションの名前

AssertionVersion

このイベントに対応するアサーションのバージョン番号(例: 2.0)

AssociateProfileName

プロファイル名の関連付けの監査に使用される属性

AuthenticationEngineID

ローカル認証で使用される認証エンジンの識別子

AuthenticationMechanism

ローカル認証で使用される認証メカニズム

AuthenticationMethod

認証方式(パスワード、SSL、Kerberosなど)

AuthorizationType

アクセス/認可構成ディレクティブ: Regular = 'Require' ディレクティブ、SSL = 'SSLRequire' ディレクティブ

Binding

メッセージの送信に使用されるバインド(SOAP、POST、GET、Aritifactなど)

COTAfter

変更後のフェデレーション構成ファイルの内容

COTBefore

変更前のフェデレーション構成ファイルの内容

CodeSource

RoleMembershipManagementのコード・ソース監査に使用される属性

ComponentName

コンポーネント名

ComponentType

コンポーネントのタイプ

CompositeName

ポリシーが施行されるコンポジットの名前(SOAアプリケーションにのみ適用)

ContextFields

dmsコンテキストから抽出されたコンテキスト・フィールドを含む属性

custEventOp

このイベントに関連付けられるLDAP操作名を指定する属性(例: ldapbind、ldapadd、ldapsearchなど)

custEventStatusDetail

関連付けられたLDAP操作に失敗した際にエラー・コードなどのイベント・ステータス詳細情報およびその他の詳細を伝達する属性

DataStoreAfter

変更後のデータ・ストア構成

DataStoreBefore

変更前のデータ・ストア構成

DataStoreName

変更中のデータ・ストアの名前(例: ユーザー・データ・ストア、フェデレーション・データ・ストア)

Description

信頼できるプロバイダの説明

ECID

開始コンポーネントが参加する実行のスレッドを識別します。

Endpoint

イベントがトリガーされたエンドポイントを識別するURIたとえば、HTTPではURLを記録する必要がある

EnterpriseRoles

RoleMembershipManagementのエンタープライズ・ロール監査に使用される属性

EntryDN

エントリ識別名の監査に使用される属性

EventCategory

監査イベントのカテゴリ

EventStatus

監査イベントの結果(失敗または成功)

EventType

監査イベントのタイプすべてのイベントを表示するには、wlst listAuditEventsを使用します。

FailureCode

EventStatusがfailureの場合のエラー・コード

FaultUri

処理によりフォルトが発生した場合、送信されるフォルトのURI

FederationID

フェデレーションのID

FederationType

作成または削除中のフェデレーションのタイプ(SP/IdP)

HomeInstance

このコンポーネントのORACLE_INSTANCEディレクトリ

HostId

開始ホストのDNSホスト名

HostNwaddr

開始ホストのIPアドレスまたは他のネットワーク・アドレス

IncomingMessageString

null

IncomingMessageStringCLOB

null

Initiator

操作を実行しているユーザーのUIDを識別する属性

InitiatorGUID

認可のイニシエータGUID監査に使用される属性

InstanceId

このコンポーネントが属しているOracleインスタンスの名前

IssueInstant

アサーションのIssueInstant属性の値

Issuer

アサーションのIssuer属性の値

JobName

スケジューラ・ジョブ名の監査に使用される属性

JobType

スケジューラ・ジョブ名の監査に使用される属性

key

資格証明ストアの資格証明キー

mapName

資格証明ストアのマップ名(別名)

MessageText

監査イベントの説明

MessageType

メッセージのタイプ(例:SSOLoginRequest/SSOLoginResponse/SSOLogoutRequest/...)

Metadata

ロードされたプロバイダ・メタデータ

ModelObjectName

ポリシーが施行されるWebサービスまたはクライアントの名前

ModuleId

メッセージの起点となったモジュールのID解釈はコンポーネントIDに固有

NameIDFormat

サブジェクトの名前IDのフォーマット

NameIDQualifier

サブジェクトの名前IDの修飾子

NameIDValue

サブジェクトの名前IDの値

NewDataStoreType

データ・ストアの新規タイプ

NewValue

構成変更後のプロパティの値

OldNameIDQualifier

更新が行われる前の名前ID修飾子

OldNameIDValue

更新が行われる前の名前ID値

OldValue

構成変更前のプロパティの値

Operation

SOAPリクエストの場合は、イベントがトリガーされた操作

OracleHome

コンポーネントのORACLE_HOMEディレクトリ

OutgoingMessageString

null

OutgoingMessageStringCLOB

null

PeerProviderID

変更されたプロパティに関連付けられる信頼できるプロバイダのID(変更されたプロパティが信頼できるプロバイダに対応しない場合、この属性は空)

PermissionAction

認可の権限アクション監査に使用される属性

PermissionClass

ポリシー・ストアの権限クラス監査に使用される属性

PermissionScope

ロール・メンバーシップ管理の権限範囲監査に使用される属性

PermissionTarget

ポリシー・ストアの権限ターゲット監査に使用される属性

PolicyCategory

イベントがトリガーされたポリシーのカテゴリ(カンマ区切りリスト)

PolicyChangeType

生じた変更のタイプ

PolicyStatus

イベントがトリガーされたポリシーのステータス(カンマ区切りリスト)

PolicySubjRescPattern

イベントがトリガーされたポリシー・サブジェクトを識別するポリシー・サブジェクト・リソース・パターン

PolicyURI

イベントがトリガーされたポリシーを識別するURI(カンマ区切りリスト)

Principals

ロール・メンバーシップ管理のプリンシパル監査に使用される属性

ProcessId

メッセージの起点となったプロセスのID

ProcessingStage

ポリシー施行が発生した処理ステージ

ProfileName

同期プロファイル名の監査に使用される属性

PropertyContext

構成内のプロパティの場所

PropertyName

構成プロパティの名前

PropertyType

プロパティのタイプ(例: PropertiesList、PropertiesMap、String、Boolean)

Protocol

リクエストのプロトコル

ProtocolVersion

使用されるプロトコルのバージョン(例: SAML2.0、Libv11)

ProvEvent

プロビジョニング・イベントの監査に使用される属性

ProviderType

プロバイダのタイプ(例: sp、idp、sp idp)

RID

リレーションシップ識別子(スレッドとプロセスの間に完全かつ適切なコールのリレーションシップを提供)

Reason

このイベントが発生した理由

RemoteIP

このイベントを開始するクライアントのIPアドレス

RemoteProviderID

リモート・サーバーのプロバイダID

Resource

アクセス中のリソースを識別する属性リソースには、Webページ、ファイル、ディレクトリ共有、Webサービス、XMLドキュメント、ポートレットなど、多くのものを指定できます。リソースの名前は、ホスト名とURIを組み合せて付けることができます。

Role

プロトコル・ステップ実行中のOracle Identity Federationのロール(例: サービス・プロバイダ/アイデンティティ・プロバイダ/属性権限など)

Roles

ログイン時にユーザーに付与されたロール

SSLConnection

リクエストを転送するためにクライアントによってSSL接続が使用されたかどうか

ServerConfigAfter

変更後のサーバー構成

ServerConfigBefore

変更前のサーバー構成

ServiceEndPoint

イベントがトリガーされたサービスを識別するURI

ServiceOperation

サービス構成の変更を実行した操作の名前

SessionID

現在のセッションのID

SessionId

ログイン・セッションのID

Source

フォルトのソース

Subject

認可のサブジェクト監査に使用される属性

Target

実行中の操作の対象であるユーザーのUIDを識別する属性たとえば、AliceがBobのパスワードを変更する場合、Aliceはイニシエータ、Bobはターゲット

TargetComponentType

ターゲット・コンポーネント・タイプ

ThreadId

このイベントを生成したスレッドのID

ToVersion

一定範囲のポリシー・バージョンを削除するときの最大値

TstzOriginating

監査イベントが生成された日時

Type

処理中の暗号データのタイプ(XML、String)

URI

フォルトのURI

UserID

このプロトコル・ステップのユーザーの識別子

Version

変更されたポリシーのバージョン

C.2 ビルトイン監査レポート

Oracle Fusion Middleware監査フレームワークには、Oracle Business Intelligence Publisherを通してアクセス可能な、すぐに使用できる一連のレポートが用意されています。これらのレポートは、含まれている監査データのタイプに応じて、次のように分類されます。

- 共通監査レポート

- コンポーネント固有の監査レポート

C.2.1 共通監査レポート

共通レポートのリストは、第14.5項「監査レポートの詳細」に記載されています。

C.2.2 コンポーネント固有の監査レポート

コンポーネント固有のレポートには次のようなものがあります。

- Oracle Fusion Middleware監査フレームワーク

- 構成の変更

- Oracle HTTP Server

- エラーと例外

- ユーザー・アクティビティ

- すべてのイベント

- Oracle Internet Directory

- アカウント管理

- アカウント・プロファイル履歴

- 削除済アカウント

- 有効化されたアカウント

- パスワード変更

- 作成されたアカウント

- 無効化されたアカウント

- ロック・アウトされたアカウント

- ユーザー・アクティビティ

- 認証履歴

- 認可履歴

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- 認可失敗

- すべてのイベント

- Oracle Virtual Directory

- ユーザー・アクティビティ

- 認証履歴

- 認可履歴

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- 認可失敗

- すべてのイベント

- Reportsサーバー

- ユーザー・アクティビティ

- 認証履歴

- 認可履歴

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- 認可失敗

- すべてのイベント

- Oracle Directory Integration Platform

- すべてのエラーと例外

- プロファイル管理イベント

- すべてのイベント

- Oracle Identity Federation

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- すべてのイベント

- フェデレーション・ユーザー・アクティビティ

- 認証履歴

- アサーション・アクティビティ

- Oracle Platform Security Services

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- すべてのイベント

- アプリケーション・ロール管理

- 資格証明管理

- 認可履歴

- アプリケーション・ポリシー管理

- 資格証明アクセス

- システム・ポリシー管理

- Oracle Web Services Manager

- ユーザー・アクティビティ

- 認証履歴

- 認可履歴

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- 認可失敗

- すべてのイベント

- ポリシー管理

- アサーション・テンプレート管理

- Webサービスのポリシー管理

- ポリシー施行

- 機密性の施行

- ポリシー施行

- メッセージ整合性の施行

- 違反

- リクエスト・レスポンス

- ポリシー・アタッチメント

- Oracle Web Cache

- ユーザー・アクティビティ

- 認証履歴

- 認可履歴

- エラーと例外

- すべてのエラーと例外

- 認証失敗

- 認可失敗

- すべてのイベント

C.3 監査スキーマ

第C.2項「ビルトイン監査レポート」で説明したビルトイン・レポート以外の追加の監査レポート要件がある場合は、希望のレポート作成ツールを使用してカスタム・レポートを作成できます。たとえば、ビルトイン・レポートでイベント属性のサブセットを使用している場合でも、カスタム・レポートを作成する際にはイベントの監査属性セット全体を使用できます。

表C-14および表C-15では、カスタム・レポートを作成する際に役立つ監査スキーマについて説明します。

表C-14 監査スキーマ

表名

列名

データ型

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

OPSS

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_CODESOURCE

VARCHAR2(1024)

はい

5

IAU_PRINCIPALS

VARCHAR2(1024)

はい

6

IAU_INITIATORGUID

VARCHAR2(1024)

はい

7

IAU_SUBJECT

VARCHAR2(1024)

はい

8

IAU_PERMISSIONACTION

VARCHAR2(1024)

はい

9

IAU_PERMISSIONTARGET

VARCHAR2(1024)

はい

10

IAU_PERMISSIONCLASS

VARCHAR2(1024)

はい

11

IAU_MAPNAME

VARCHAR2(1024)

はい

12

IAU_KEY

VARCHAR2(1024)

はい

13

IAU_PERMISSIONSCOPE

VARCHAR2(1024)

はい

14

IAU_APPLICATIONROLE

VARCHAR2(1024)

はい

15

IAU_ENTERPRISEROLES

VARCHAR2(1024)

はい

16

IAU_INITIATORDN

VARCHAR2(1024)

はい

17

IAU_GUID

VARCHAR2(1024)

はい

18

IAU_PERMISSION

VARCHAR2(1024)

はい

19

IAU_MODIFIEDATTRIBUTENAME

VARCHAR2(1024)

はい

20

IAU_MODIFIEDATTRIBUTEVALUE

VARCHAR2(2048)

はい

21

IAU_PERMISSIONSETNAME

VARCHAR2(1024)

はい

22

IAU_RESOURCEACTIONS

VARCHAR2(1024)

はい

23

IAU_RESOURCETYPE

VARCHAR2(1024)

はい

24

OHS/OHS Component

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_REASON

CLOB

はい

5

IAU_SSLCONNECTION

VARCHAR2(255)

はい

6

IAU_AUTHORIZATIONTYPE

VARCHAR2(255)

はい

7

OID/OID Component

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_CUSTEVENTSTATUSDETAIL

VARCHAR2(255)

はい

5

IAU_CUSTEVENTOP

VARCHAR2(255)

はい

6

OIF

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_REMOTEPROVIDERID

VARCHAR2(255)

はい

5

IAU_PROTOCOLVERSION

VARCHAR2(255)

はい

6

IAU_NAMEIDQUALIFIER

VARCHAR2(255)

はい

7

IAU_NAMEIDVALUE

VARCHAR2(255)

はい

8

IAU_NAMEIDFORMAT

VARCHAR2(255)

はい

9

IAU_SESSIONID

VARCHAR2(255)

はい

10

IAU_FEDERATIONID

VARCHAR2(255)

はい

11

IAU_USERID

VARCHAR2(255)

はい

12

IAU_FEDERATIONTYPE

VARCHAR2(255)

はい

13

IAU_AUTHENTICATIONMECHANISM

VARCHAR2(255)

はい

14

IAU_AUTHENTICATIONENGINEID

VARCHAR2(255)

はい

15

IAU_OLDNAMEIDQUALIFIER

VARCHAR2(255)

はい

16

IAU_OLDNAMEIDVALUE

VARCHAR2(255)

はい

17

IAU_BINDING

VARCHAR2(255)

はい

18

IAU_ROLE

VARCHAR2(255)

はい

19

IAU_MESSAGETYPE

VARCHAR2(255)

はい

20

IAU_ASSERTIONVERSION

VARCHAR2(255)

はい

21

IAU_ISSUEINSTANT

VARCHAR2(255)

はい

22

IAU_ISSUER

VARCHAR2(255)

はい

23

IAU_ASSERTIONID

VARCHAR2(255)

はい

24

IAU_INCOMINGMESSAGESTRING

VARCHAR2(3999)

はい

25

IAU_INCOMINGMESSAGESTRINGCLOB

CLOB

はい

26

IAU_OUTGOINGMESSAGESTRING

VARCHAR2(3999)

はい

27

IAU_OUTGOINGMESSAGESTRINGCLOB

CLOB

はい

28

IAU_TYPE

VARCHAR2(255)

はい

29

IAU_PROPERTYNAME

VARCHAR2(255)

はい

30

IAU_PROPERTYTYPE

VARCHAR2(255)

はい

31

IAU_PEERPROVIDERID

VARCHAR2(255)

はい

32

IAU_PROPERTYCONTEXT

VARCHAR2(255)

はい

33

IAU_DESCRIPTION

VARCHAR2(255)

はい

34

IAU_OLDVALUE

VARCHAR2(255)

はい

35

IAU_NEWVALUE

VARCHAR2(255)

はい

36

IAU_PROVIDERTYPE

VARCHAR2(255)

はい

37

IAU_COTBEFORE

CLOB

はい

38

IAU_COTAFTER

CLOB

はい

39

IAU_SERVERCONFIGBEFORE

CLOB

はい

40

IAU_SERVERCONFIGAFTER

CLOB

はい

41

IAU_DATASTOREBEFORE

CLOB

はい

42

IAU_DATASTOREAFTER

CLOB

はい

43

IAU_METADATA

VARCHAR2(255)

はい

44

IAU_NEWDATASTORETYPE

VARCHAR2(255)

はい

45

IAU_DATASTORENAME

VARCHAR2(255)

はい

46

OVD/OVD Component

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_SERVICEOPERATION

VARCHAR2(255)

はい

5

OWSM Agent

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_APPNAME

VARCHAR2(255)

はい

5

IAU_ASSERTIONNAME

VARCHAR2(255)

はい

6

IAU_COMPOSITENAME

VARCHAR2(255)

はい

7

IAU_ENDPOINT

VARCHAR2(4000)

はい

8

IAU_AGENTMODE

VARCHAR2(255)

はい

9

IAU_MODELOBJECTNAME

VARCHAR2(255)

はい

10

IAU_OPERATION

VARCHAR2(255)

はい

11

IAU_PROCESSINGSTAGE

VARCHAR2(255)

はい

12

IAU_VERSION

NUMBER

はい

13

IAU_PROTOCOL

VARCHAR2(255)

はい

14

OWSM_PM_EJB

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_VERSION

NUMBER

はい

5

IAU_TOVERSION

NUMBER

はい

6

ReportsServer/ReportsServer
Components

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

WebCache/ WebCache
Component

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

WebServices

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_PROTOCOL

VARCHAR2(255)

はい

5

IAU_ENDPOINT

VARCHAR2(4000)

はい

6

IAU_OPERATION

VARCHAR2(255)

はい

7

IAU_FAULTURI

VARCHAR2(4000)

はい

8

IAU_URI

VARCHAR2(4000)

はい

9

IAU_SOURCE

VARCHAR2(255)

はい

10

WS_Policy
Attachment

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_PROTOCOL

VARCHAR2(255)

はい

5

IAU_ENDPOINT

VARCHAR2(4000)

はい

6

IAU_OPERATION

VARCHAR2(255)

はい

7

IAU_FAULTURI

VARCHAR2(4000)

はい

8

IAU_URI

VARCHAR2(4000)

はい

9

IAU_SOURCE

VARCHAR2(255)

はい

10

OAM (Oracle Access Manager)

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_APPLICATIONDOMAINNAME

VARCHAR2(40)

はい

5

IAU_AUTHENTICATIONSCHEMEID

VARCHAR2(40)

はい

6

IAU_AGENTID

VARCHAR2(40)

はい

7

IAU_SSOSESSIONID

VARCHAR2(100)

はい

8

IAU_ADDITIONALINFO

VARCHAR2(1000)

はい

9

IAU_AUTHORIZATIONSCHEME

VARCHAR2(40)

はい

10

IAU_USERDN

VARCHAR2(255)

はい

11

IAU_RESOURCEID

VARCHAR2(40)

はい

12

IAU_AUTHORIZATIONPOLICYID

VARCHAR2(40)

はい

13

IAU_AUTHENTICATIONPOLICYID

VARCHAR2(255)

はい

14

IAU_USERID

VARCHAR2(40)

はい

15

IAU_RESOURCEHOST

VARCHAR2(255)

はい

16

IAU_REQUESTID

VARCHAR2(255)

はい

17

IAU_POLICYNAME

VARCHAR2(40)

はい

18

IAU_SCHEMENAME

VARCHAR2(40)

はい

19

IAU_RESOURCEHOSTNAME

VARCHAR2(100)

はい

20

IAU_OLDATTRIBUTES

VARCHAR2(1000)

はい

21

IAU_NEWATTRIBUTES

VARCHAR2(1000)

はい

22

IAU_SCHMETYPE

VARCHAR2(40)

はい

23

IAU_RESPONSETYPE

VARCHAR2(40)

はい

24

IAU_AGENTTYPE

VARCHAR2(40)

はい

25

IAU_CONSTRAINTTYPE

VARCHAR2(40)

はい

26

IAU_INSTANCENAME

VARCHAR2(40)

はい

27

IAU_DATASOURCENAME

VARCHAR2(100)

はい

28

IAU_DATASOURCETYPE

VARCHAR2(100)

はい

29

IAU_HOSTIDENTIFIERNAME

VARCHAR2(100)

はい

30

IAU_RESOURCEURI

VARCHAR2(255)

はい

31

IAU_RESOURCETEMPLATENAME

VARCHAR2(100)

はい

32

OAAM (Oracle Adaptive Access Manager)

IAU_ID

NUMBER

はい

1

IAU_TSTZORIGINATING

TIMESTAMP(6)

はい

2

IAU_EVENTTYPE

VARCHAR2(255)

はい

3

IAU_EVENTCATEGORY

VARCHAR2(255)

はい

4

IAU_ACTIONNOTES

VARCHAR2(4000)

はい

5

IAU_CASEACTIONENUM

NUMBER(38)

はい

6

IAU_CASEACTIONRESULT

NUMBER

はい

7

IAU_CASECHALLENGEQUESTION

VARCHAR2(4000)

はい

8

IAU_CASECHALLENGERESULT

NUMBER(38)

はい

9

IAU_CASEDISPOSITION

NUMBER(38)

はい

10

IAU_CASEEXPRDURATIONINHRS

NUMBER(38)

はい

11

IAU_CASEID

NUMBER

はい

12

IAU_CASEIDS

VARCHAR2(4000)

はい

13

IAU_CASESEVERITY

NUMBER(38)

はい

14

IAU_CASESTATUS

NUMBER(38)

はい

15

IAU_CASESUBACTIONENUM

NUMBER(38)

はい

16

IAU_DESCRIPTION

VARCHAR2(4000)

はい

17

IAU_GROUPID

NUMBER

はい

18

IAU_GROUPIDS

VARCHAR2(4000)

はい

19

IAU_GROUPNAME

VARCHAR2(4000)

はい

20

IAU_GROUPDETAILS

VARCHAR2(4000)

はい

21

IAU_GROUPELEMENTID

NUMBER

はい

22

IAU_GROUPELEMENTIDS

NUMBER

はい

23

IAU_GROUPELEMENTVALUE

VARCHAR2(4000)

はい

24

IAU_GROUPELEMENTSDETAILS

VARCHAR2(4000)

はい

25

IAU_KBACATEGORYID

NUMBER

はい

26

IAU_KBACATEGORYIDS

VARCHAR2(4000)

はい

27

IAU_KBACATEGORYNAME

VARCHAR2(4000)

はい

28

IAU_KBACATEGORYDETAILS

VARCHAR2(4000)

はい

29

IAU_KBAQUESTIONID

NUMBER

はい

30

IAU_KBAQUESTIONIDS

VARCHAR2(4000)

はい

31

IAU_KBAQUESTION

VARCHAR2(4000)

はい

32

IAU_KBAQUESTIONTYPE

NUMBER(38)

はい

33

IAU_KBAQUESTIONDETAILS

VARCHAR2(4000)

はい

34

IAU_KBAVALIDATIONID

NUMBER

はい

35

IAU_KBAVALIDATIONIDS

VARCHAR2(4000)

はい

36

IAU_KBAVALIDATIONNAME

VARCHAR2(4000)

はい

37

IAU_KBAVALIDATIONDETAILS

VARCHAR2(4000)

はい

38

IAU_KBAREGLOGICDETAILS

VARCHAR2(4000)

はい

39

IAU_KBAANSWERLOGICDETAILS

VARCHAR2(4000)

はい

40

IAU_LOGINID

VARCHAR2(255)

はい

41

IAU_POLICYDETAILS

VARCHAR2(4000)

はい

42

IAU_POLICYID

NUMBER

はい

43

IAU_POLICYIDS

VARCHAR2(4000)

はい

44

IAU_POLICYNAME

NUMBER

はい

45

IAU_POLICYOVERRIDEDETAILS

VARCHAR2(4000)

はい

46

IAU_POLICYOVERRIDEID

NUMBER

はい

47

IAU_POLICYOVERRIDEIDS

VARCHAR2(4000)

はい

48

IAU_POLICYOVERRIDEROWID

NUMBER

はい

49

IAU_POLICYRULEMAPID

NUMBER

はい

50

IAU_POLICYRULEMAPIDS

VARCHAR2(4000)

はい

51

IAU_POLICYRULEMAPDETAILS

VARCHAR2(4000)

はい

52

IAU_RULEID

NUMBER

はい

53

IAU_RULECONDITIONID

NUMBER

はい

54

IAU_RULECONDITIONIDS

VARCHAR2(4000)

はい

55

IAU_RULENAME

VARCHAR2(4000)

はい

56

IAU_RULEDETAILS

VARCHAR2(4000)

はい

57

IAU_RULECONDITIONMAPID

NUMBER

はい

58

IAU_RULECONDITIONMAPIDS

VARCHAR2(4000)

はい

59

IAU_RULEPARAMVALUEDETAILS

VARCHAR2(4000)

はい

60

IAU_SOURCEPOLICYID

NUMBER

はい

61

IAU_USERGROUPNAME

VARCHAR2(255)

はい

62

IAU_USERID

NUMBER

はい

63

IAU_USERIDS

VARCHAR2(4000)

はい

64

表C-15は監査スキーマの追加の表を示します。これらの表では動的メタデータ・モデルがサポートされます。

表C-15 追加の監査スキーマ表

表名

列名

データ型

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.4 監査のためのWLSTコマンド

WLSTは、Oracle Fusion Middlewareのコンポーネントとアプリケーションの管理に使用するコマンドライン・ユーティリティです。Oracle Enterprise Manager Fusion Middleware Controlに加えて、管理のための別のオプションが用意されています。

表C-16に示すWLSTコマンドを使用して、監査ポリシーと監査ストア構成を表示および管理できます。

注意:

WLSTの監査コマンドを実行するには、Oracle共通ホームからWLSTスクリプトを呼び出します。詳細は『Oracle Fusion Middleware管理者ガイド』のカスタムWLSTコマンドの使用に関する項を参照してください。

関連項目:

サード・パーティのアプリケーション・サーバー上での監査コマンドの実行の詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

表C-16 WLST監査コマンド

使用するコマンド

機能

WLSTでの使用

getNonJava EEAuditMBeanName

システム・コンポーネントのMBean名を表示します。

オンライン

getAuditPolicy

監査ポリシー設定を表示します。

オンライン

setAuditPolicy

監査ポリシー設定を更新します。

オンライン

getAuditRepository

監査ストア設定を表示します。

オンライン

setAuditRepository

監査ストア設定を更新します。

オンライン

listAuditEvents

1つまたはすべてのコンポーネントの監査イベントのリストを表示します。

オンライン

exportAuditConfig

コンポーネントの監査構成をエクスポートします。

オンライン

importAuditConfig

コンポーネントの監査構成をインポートします。

オンライン

C.4.1 getNonJava EEAuditMBeanName

システム・コンポーネントのMBean名を表示するオンライン・コマンドです。

システム・コンポーネントに対してWLSTコマンドを使用するには、MBean名を入力する必要があります。MBean名の構造は複雑な場合があるため、このコマンドを使用してMBean名を取得します。

C.4.1.1 説明

このコマンドは、システム・コンポーネントのMBean名(インスタンス名、コンポーネント名、コンポーネント・タイプを指定)、およびコンポーネントの監査MBeanが実行されているOracle WebLogicサーバーの名前を表示します。システム・コンポーネントを管理する際、MBean名は他の監査WLSTコマンドの必須パラメータです。

C.4.1.2 構文

getNonJava EEAuditMBeanName('instance-name', 'component-name', 'component-type')

引数

定義

instName

アプリケーション・サーバー・インスタンスの名前を指定します。

compName

コンポーネント・インスタンスの名前を指定します。

compType

コンポーネントのタイプを指定します。有効値はohs、oid、ovdおよびWebCacheです。

C.4.1.3 例

次のインタラクティブ・コマンドは、Oracle Internet DirectoryコンポーネントのmBean名を表示します。

wls:/mydomain/serverConfig> getNonJava EEAuditMBeanName(instName='inst1', compName='oid1', compType='oid')

C.4.2 getAuditPolicy

監査ポリシー設定を表示するオンライン・コマンドです。

C.4.2.1 説明

監査レベル、特別なユーザー、カスタム・イベント、最大ログ・ファイル・サイズ、最大ログ・ディレクトリ・サイズなどの監査ポリシー設定を表示するオンライン・コマンドです。コンポーネントのMBean名はオプションのパラメータです。パラメータが指定されていない場合は、ドメイン監査ポリシーが表示されます。

C.4.2.2 構文

getAuditPolicy(['mbeanName', componentType])

引数

定義

mbeanName

システム・コンポーネントのコンポーネント監査MBeanの名前を指定します。

componentType

監査ストアに登録されている特定のコンポーネント・タイプに対する監査ポリシーを要求します。指定しない場合は、jps-config.xml内の監査ポリシーが返されます。

C.4.2.3 例

次のコマンドは、WebLogicサーバー・ドメインで構成されたすべてのJava EEコンポーネントの監査設定を表示します。

wls:/mydomain/serverConfig> getAuditPolicy()

次のコマンドは、MBeanのCSAuditProxyMBeanの監査設定を表示します。

wls:/mydomain/serverConfig> getAuditPolicy(on='oracle.security.audit.test:type=CSAuditMBean,
name=CSAuditProxyMBean')

C.4.3 setAuditPolicy

監査ポリシーを更新するオンライン・コマンドです。

C.4.3.1 説明

監査ポリシー設定を構成するオンライン・コマンドです。監査レベルの設定、特別なユーザーの追加や削除、およびカスタム・イベントの追加や削除を実行できます。Oracle Internet DirectoryやOracle Virtual Directoryなどのシステム・コンポーネントには、コンポーネントMBean名が必要です。

システム・コンポーネントに対してsetAuditPolicyを発行した後で、saveをコールすることを忘れないでください。そうしないと、新しい設定は有効になりません。

C.4.3.2 構文

setAuditPolicy(['mbeanName'],['filterPreset'],['addSpecialUsers'],
['removeSpecialUsers'],['addCustomEvents'],['removeCustomEvents'], [componentType], [maxDirSize], [maxFileSize], [andCriteria],  [orCriteria], [componentEventsFile])

引数

定義

mbeanName

システム・コンポーネントのコンポーネント監査MBeanの名前を指定します。

filterPreset

変更する監査レベルを指定します。

addSpecialUsers

追加する特別なユーザーを指定します。

removeSpecialUsers

削除する特別なユーザーを指定します。

addCustomEvents

追加するカスタム・イベントを指定します。

removeCustomEvents

削除するカスタム・イベントを指定します。

componentType

更新するコンポーネント定義タイプを指定します。指定しない場合は、jps-config.xmlで定義されている監査構成が変更されます。

maxDirSize

ログ・ディレクトリの最大サイズを指定します。

maxFileSize

ログ・ファイルの最大サイズを指定します。

andCriteria

カスタム・フィルタ・プリセット定義内のand基準を指定します。

orCriteria

カスタム・フィルタ・プリセット定義内のor基準を指定します。

componentEventsFile

11gリリース1 (11.1.1) PS5メタデータ・モデルのコンポーネント定義ファイルを指定します。このパラメータは、11gリリース1 (11.1.1) PS5メタデータ・モデル・コンポーネントに対する監査ストア内で監査ポリシーを作成または更新する必要があり、フィルタ・プリセット・レベルが「カスタム」に設定されている場合に必要です。

C.4.3.3 例

次のインタラクティブ・コマンドは、a) 監査レベルをLowに設定し、b) ユーザーuser1をポリシーから削除すると同時に、ユーザーuser2およびuser3を追加します。

wls:/mydomain/serverConfig> setAuditPolicy (filterPreset='Low',addSpecialUsers='user2,user3',removeSpecialUsers='user1')

次のインタラクティブ・コマンドは、ポリシーからログアウト・イベントを削除すると同時に、ログイン・イベントを追加します。

wls:/mydomain/serverConfig> setAuditPolicy(filterPreset='Custom',addCustomEvents='UserLogin',removeCustomEvents='UserLogout')

C.4.4 getAuditRepository

監査ストア設定を表示するオンライン・コマンドです。

C.4.4.1 説明

Javaコンポーネントおよびアプリケーションの監査ストア設定を表示するオンライン・コマンドです(Oracle Internet Directoryなどのシステム・コンポーネントの場合は、構成はopmn.xmlに存在しています)。また、データがデータベースに格納されている場合は、データベース構成も表示します。

C.4.4.2 構文

getAuditRepository

C.4.4.3 例

次のコマンドは、監査ストアの構成を表示します。

wls:/mydomain/serverConfig> getAuditRepository()

C.4.5 setAuditRepository

監査ストア設定を更新するオンライン・コマンドです。

C.4.5.1 説明

Javaコンポーネントおよびアプリケーションの監査ストア設定を行うオンライン・コマンドです(Oracle Internet Directoryなどのシステム・コンポーネントの場合は、opmn.xmlを編集することでストアが構成されます)。

C.4.5.2 構文

setAuditRepository(['switchToDB'],['dataSourceName'],['interval'])

引数

定義

switchToDB

trueの場合、ストアをファイルからデータベースに切り替えます。

dataSourceName

データソースの名前を指定します。

interval

監査ローダーがファイル・レコードをデータベースに移動する間隔を指定します。

C.4.5.3 例

次のインタラクティブ・コマンドは、データソースjdbcAuditDBによって定義されたデータベースに監査ストアを変更し、監査ローダーの間隔を14秒に設定します。

wls:/mydomain/serverConfig> setAuditRepository(switchToDB='true',dataSourceName='jdbcAuditDB',interval='14')

注意:

データソースは、Oracle WebLogicサーバー管理コンソールを使用して作成されます。

C.4.6 listAuditEvents

コンポーネントの監査イベントの定義(コンポーネントの属性も含む)を表示するオンライン・コマンドです。

C.4.6.1 説明

このコマンドは、コンポーネントの監査イベントと属性を表示します。システム・コンポーネントの場合、パラメータとしてコンポーネントMBean名を渡します。Javaアプリケーション、およびOracle Platform Security Services (OPSS)などのJavaサービスでは、MBeanパラメータは必要ありません。コンポーネント・タイプが指定されていない場合は、すべてのコンポーネントに適用できる一般的な属性がすべて表示されます。

C.4.6.2 構文

listAuditEvents(['mbeanName'],['componentType'])

引数

定義

mbeanName

コンポーネントMBeanの名前を指定します。

componentType

コンポーネント・タイプを指定して、リストをそのコンポーネント・タイプのすべてのイベントに限定します。

C.4.6.3 例

次のコマンドは、Oracle Internet Directoryインスタンスの監査イベントを表示します。

wls:/mydomain/serverConfig> listAuditEvents(on='oracle.as.management.mbeans.register:
type=component.auditconfig,name=auditconfig1,instance=oid1,component=oid')

次のコマンドは、Oracle Identity Federationの監査イベントを表示します。

wls:/mydomain/serverConfig> listAuditEvents(componentType='oif')

C.4.7 exportAuditConfig

コンポーネントの監査構成をエクスポートするオンライン・コマンドです。

関連項目:

このコマンドは、運用環境への移行の際に役に立ちます。詳細は、第6.5.3項「監査ポリシーの移行」を参照してください。

C.4.7.1 説明

このコマンドは、監査構成をファイルにエクスポートします。システム・コンポーネントの場合、パラメータとしてコンポーネントMBean名を渡します。Javaアプリケーション、およびOracle Platform Security Services (OPSS)などのJavaサービスでは、MBeanパラメータは必要ありません。

C.4.7.2 構文

exportAuditConfig(['mbeanName'],'fileName', [componentType])

引数

定義

mbeanName

システム・コンポーネントMBeanの名前を指定します。

fileName

監査構成のエクスポート先のパスとファイル名を指定します。

componentType

特定のコンポーネントのイベントのみをファイルにエクスポートすることを指定します。指定しない場合は、jps-config.xml内の監査構成がエクスポートされます。

C.4.7.3 例

次のインタラクティブ・コマンドは、コンポーネントの監査構成をエクスポートします。

wls:/mydomain/serverConfig> exportAuditConfig(on='oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean',fileName='/tmp/auditconfig')

次のインタラクティブ・コマンドは、コンポーネントの監査構成をエクスポートします(MBeanは指定されません)。

wls:/mydomain/serverConfig> exportAuditConfig(fileName='/tmp/auditconfig')

C.4.8 importAuditConfig

コンポーネントの監査構成をインポートするオンライン・コマンドです。

関連項目:

このコマンドは、運用環境への移行の際に役に立ちます。詳細は、第6.5.3項「監査ポリシーの移行」を参照してください。

C.4.8.1 説明

このコマンドは、監査構成を外部ファイルからインポートします。システム・コンポーネントの場合、パラメータとしてコンポーネントMBean名を渡します。Javaアプリケーション、およびOracle Platform Security Services (OPSS)などのJavaサービスでは、MBeanパラメータは必要ありません。

システム・コンポーネントに対してimportAuditConfigを発行した後で、saveをコールすることを忘れないでください。そうしないと、新しい設定は有効になりません。

C.4.8.2 構文

importAuditConfig(['mbeanName'],'fileName', [componentType])

引数

定義

mbeanName

システム・コンポーネントMBeanの名前を指定します。

fileName

監査構成のインポート元のパスとファイル名を指定します。

componentType

特定のコンポーネントのイベントのみをファイルからインポートすることを指定します。指定しない場合は、jps-config.xml内の監査構成がインポートされます。

C.4.8.3 例

次のインタラクティブ・コマンドは、コンポーネントの監査構成をインポートします。

wls:/mydomain/serverConfig> importAuditConfig(on='oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean',fileName='/tmp/auditconfig')

次のインタラクティブ・コマンドは、Java EEアプリケーションの監査構成をインポートします(MBeanは指定されません)。

wls:/mydomain/serverConfig> importAuditConfig(fileName='/tmp/auditconfig')

C.5 監査フィルタ式の構文

カスタム監査ポリシーを選択する際、イベントとともにフィルタ式を指定できるオプションがあります。

たとえば、

Host Id -eq "myhost123"

この式を使用して、特定のホストのみに対して監査イベントを有効化することができます。

この式を入力するには、Fusion Middleware Controlのフィルタ編集ダイアログまたはsetAuditPolicy WLSTコマンドを使用します。

関連項目:

- 第13.3.1項「Fusion Middleware ControlによるJavaコンポーネントの監査ポリシーの管理」

- 第13.3.2項「Fusion Middleware Controlによるシステム・コンポーネントの監査ポリシーの管理」

- 第C.4.3項「setAuditPolicy」

フィルタ式を作成する際は、いくつかの構文ルールに従う必要があります。

式は、ブール式でもリテラルでも構いません。

<Expr> ::= <BooleanExpression> | <BooleanLiteral>

ブール式では、RelationalExpressionを–and、-or、-notおよびカッコと組み合せて使用できます(例: Host Id -eq "stadl17" -or ")。

<BooleanExpression> ::=  <RelationalExpression>
| “(” <BooleanExpression> “)”
| <BooleanExpression> “-and” <BooleanExpression>
| <BooleanExpression> “-or” <BooleanExpression>
| “-not” <BooleanExpression>

リレーショナル式では(左側の)属性名と(右側の)リテラルが比較されます。リテラルと演算子は、属性に対して適切なデータ型である必要があります。

<RelationalExpression> ::= <AttributeName> <RelationalOperator> <Literal>

関係演算子とデータ型との関係は次のとおりです。

- -eq、-neは、すべてのデータ型で使用できます。

- -contains、-startswith、-endswithは、文字列でのみ使用できます。

- -contains_case、-startswith_caseおよび-endswith_caseは、前述の3つの関数の、大/小文字を区別するバージョンです。

- -lt、-le、-gt、-geは、数値と日時で使用できます。

<RelationalOperator> : = "-eq" | "-ne" | "-lt" | "-le" | "-gt" | "-ge"
| "-contains" | "-contains_case"
| "-startswith" | "-startswith_case"
| "-endswith" | "-endswith_case"

リテラルに関するルールは、次のとおりです。

- ブール型リテラルはtrueまたはfalseで、引用符を使用しません。

- 日時のリテラルは二重引用符で囲む必要があります。これには様々な形式が使用でき、"June 25, 2006"、"06/26/2006 2:00 pm"はすべて有効です。

- 文字列リテラルは引用符で囲む必要があります。埋込み二重引用符をエスケープするために、バックスラッシュを使用できます。

- 数値リテラルは、通常の形式で使用できます。

<Literal> ::=  <NumericLiteral> | <BooleanLiteral> | <DateTimeLiteral> | <StringLiteral><BooleanLiteral> ::= "true” | "false”

C.6 監査ファイルの命名およびロギング形式

この項では、監査ファイルのメンテナンスのルールについて説明します。

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のみを削除します。

OPMNで管理されるコンポーネントも同じモデルに従いますが、ファイル名が若干異なります。ファイル名にプロセス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ディレクトリのアプリケーションを開発する際に必要となる参照情報が含まれています。次のセクションが含まれます:

- LDAPディレクトリへのユーザー属性のマッピング

- LDAPディレクトリへのロール属性のマッピング

- デフォルトの構成パラメータ

- Microsoft Active Directoryのためのセキュアな接続

関連項目:

第25章「ユーザーおよびロール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 WLSTスクリプトおよびMBeanプログラミングを使用した管理

この付録では、WLSTスクリプトとMBeanプログラミングを使用して実行される拡張管理タスクについて次の各項で説明します。

- WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成

- MBeanを使用したOPSSサービスの構成

- アクセス制限

E.1 WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成

アプリケーションでユーザーおよびロールAPIを使用しており、デフォルト属性(cn)とは異なる認証プロバイダのユーザー属性にアクセスする必要がある場合には、WebLogic管理コンソールを使用して、必要なユーザー属性を使用できるように認証プロバイダを構成します。デフォルトとは異なる属性を使用するユーザーおよびロールAPI以外でも、認証プロバイダの適切な初期化は必要です。

次の手順では、WLSTスクリプトを使用して認証プロバイダの初期化を変更する方法について説明します。これにより、構成されたユーザー属性をユーザーおよびロールAPIで使用して、構成された認証プロバイダのデータにアクセスできるようになります。

WebLogicスクリプトの詳細は、『Oracle Fusion Middleware Oracle WebLogic Scripting Tool』を参照してください。

サービス・インスタンスのカスタム・プロパティを追加または更新するには、次の手順を実行します。

1. 次のコンテンツを含むpyスクリプト・ファイルを作成します。

import sys
connect('userName','userPass','t3://localHost:portNumber')
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へのリンクは、第H.1項の「OPSS APIリファレンス」に記載されています。

この項の内容は次のとおりです。

- サポートされるOPSS MBeansのリスト

- OPSS MBeanの起動

- OPSS MBeansを使用したプログラミング

E.2.1 サポートされるOPSS MBeansのリスト

表E-1は、サポートされるMBeansとその基本機能、およびタスクを実行するためにカスタムWLSTスクリプトまたは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を使用してスクリプトを作成し、実行します。詳細は、『Oracle Fusion Middleware Oracle 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();
}
}
}

プログラムによるサービスの構成の詳細は、第V部「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 Fusion Middleware 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>を使用して設定)について次の各項で説明します。

- OPSSシステム・プロパティ

- OPSS構成プロパティ

サーバー・プロパティをプログラムによって管理するには、OPSS MBeansを使用します。詳細と例は、第E.2.3項「OPSS Mbeansを使用したプログラミング」を参照してください。

注意:

すべてのOPSSの構成変更を有効にするには(手動で、またはJpsConfiguration MBeanを使用して)、サーバーを再起動する必要があります。

OPSSのデータ・ドメイン変更は、サーバーを再起動しなくても有効になります。データの変更には、アプリケーション・ポリシーの変更と、資格証明の作成、削除または更新があります。

F.1 OPSSシステム・プロパティ

導入または変更したシステム・プロパティは、サーバーを再起動するまで有効になりません。システム・プロパティを設定するには、管理者はsetDomainEnv.shシェル・スクリプトを編集し、そのスクリプト内の環境変数EXTRA_JAVA_PROPERTIESにプロパティを追加する必要があります。

表F-1は、OPSSで使用可能なJavaシステム・プロパティを示しています。

表F-1 OPSSで使用されるJavaシステム・プロパティ

名前

説明

java.security.debug=access,failure

JpsAuth.checkPermissionメソッドがSubject.doAsブロック内で呼び出されたときにパーミッション・チェックが失敗すると、その失敗について通知します。

setting jps.auth.debugまたはjps.auth.debug.verboseだけでは、この場合に失敗の通知を受け取ることはできません。

オプション。

java.security.policy

Javaセキュリティ・ポリシー・ファイルの場所を指定します。

jps.authz

実行時およびデバッグのオーバーヘッドを軽減するJDK APIのAccessController.checkPermissionのコールの委任を有効または無効にします。

オプション。

有効な値: NULL、SM、ACCおよびDEBUG_NULL

デフォルト値なし

jps.auth.debug

サーバーのロギング出力を制御します。デフォルト値はFALSEです。詳細は、第L.1.2.1項「jps.auth.debug」を参照してください。java.security.debugの説明も参照してください。

オプション。

jps.auth.debug.verbose

サーバーのロギング出力を制御します。デフォルト値はFALSEです。詳細は、第L.1.2.2項「jps.auth.debug.verbose」を参照してください。java.security.debugの説明も参照してください。

オプション。

jps.combiner.optimize

サブジェクトの保護ドメインのキャッシュを有効または無効にします。

オプション。

有効な値: TRUE、FALSE

デフォルト値: FALSE

jps.combiner.optimize.lazyeval

パーミッション・チェックのトリガー時にサブジェクトの保護ドメインの評価を有効または無効にします。

オプション。

有効な値: TRUE、FALSE

デフォルト値: FALSE

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.subject.cache.ttl

グループ・メンバーシップの変更が有効になるまでの秒数を指定します。

この値はWebLogic認証プロバイダのGroup Hierarchy Cacheの値と同期している必要があります。Group Hierarchy Cacheの値を変更した場合は、新しい値に一致するようにjps.subject.cache.ttlをリセットする必要があります。

オプション。

有効な値: 任意の正の整数

デフォルト値: 60000

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

指定した部分文字列を含むアプリケーション・ロール名をログに記録します。一致対象の部分文字列を指定しないと、すべてのアプリケーション・ロール名が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第L.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.permeffect

指定した値に従って、付与された権限または拒否された権限をログに記録します。値を指定しないと、(付与または拒否にかかわらず)すべての権限が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第L.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.permclassname

指定した名前に完全一致するパーミッション・クラス名をログに記録します。一致対象の名前を指定しないと、すべてのパーミッション・クラス名が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第L.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.permtarget.substring

指定した部分文字列を含むパーミッション・ターゲット名をログに記録します。一致対象の部分文字列を指定しないと、すべてのパーミッション・ターゲットが記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第L.1.2.3項「認可プロセスのデバッグ」を参照してください。

oracle.security.jps.log.for.enterprise.principalname

指定した名前に完全一致するプリンシパル(エンタープライズ・ユーザーまたはエンタープライズ・ロール)名をログに記録します。一致対象の名前を指定しないと、すべてのプリンシパル名が記録されます。

オプション。

デフォルト値なし

使用例と詳細は、第L.1.2.3項「認可プロセスのデバッグ」を参照してください。

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

jps.change.notifier.file.delay

システムがドメイン・ファイルsystem-jazn-data.xmlとcwallet.ssoで変更の有無を確認する頻度を指定します(ミリ秒単位)。

本番環境では、約10分(600000ミリ秒)の頻度をお薦めします。開発環境では、約3分(180000ミリ秒)の頻度をお薦めします。

デフォルト値: 1000

次のプロパティは、Java EEアプリケーションでのみ有効です。

datasource.jndi.name

JDBCデータ・ソース・インスタンスのJNDI名。

Java EEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

必須。

デフォルト値なし

failover.retry.times

再試行回数。

Java EEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

オプション。

デフォルト値: 3

failover.retry.interval

次に再試行するまでの秒数。

Java EEアプリケーションでのみ有効です。

DBストアにのみ適用されます。

オプション。

デフォルト値: 15

次のプロパティは、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://stadk06.us.oracle.com:3060" 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.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://sttt:3060"/>
<property name="oracle.security.jps.ldap.root.name" value="cn=jpsNode"/>
<property name="oracle.security.jps.farm.name" value="cn=domain1"/>
</serviceInstance>

Java SEアプリケーションの構成の追加サンプルは、第23.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:@sc.us.oracle.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アプリケーションの構成の追加サンプルは、第23.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.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

work_folder

一時的な保存に使用するフォルダ。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: システムの一時フォルダ。

authorization_cache_enabled

認可キャッシュを有効にするかどうかを指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

有効な値: TRUE、FALSE

デフォルト値: FALSE

session_eviction_percentage

削除容量に達したときに削除するセッションの比率。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: 10

session_eviction_capacity

維持する認可とロールのマッピング・セッションの最大数。最大数に達すると、古いセッションが削除され、必要になったときに再確立されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

XMLストア、LDAPストアおよびDBストアに適用されます。

オプション。

デフォルト値: 500

session_expiration_sec

セッション・データをキャッシュする秒数。

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://stttt.us.oracle.com:3060" name="ldap.url"/>
<property value="true" name="encrypt"/>
</serviceInstance>

F.2.3 LDAPアイデンティティ・ストアのプロパティ

表F-5は、LDAPベースのアイデンティティ・ストア・インスタンスのプロパティを示しています。拡張プロパティはその旨明示しています。それぞれのプロパティに対応する、ユーザーおよびロールAPIのプロパティも示しています。

関連項目:

第7章「アイデンティティ・ストア・サービスの構成」

表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

security.principal.alias

CSFマップ名。

Java SEアプリケーションとJava EEアプリケーションで有効です。

必須。

デフォルト値なし

値の例: myalias。

security.principal.key

CSFキー名。

Java SEアプリケーションでのみ有効です。

必須。

デフォルト値なし

値の例: mykey。

ユーザーおよびロールAPIの対応するプロパティ: ADF_IM_SECURITY_PRINCIPAL

ldap.url

LDAP URL値。

Java SEアプリケーションとJava EEアプリケーションで有効です。

必須。

デフォルト値なし

値の例: ldap://myServerName.com:389。

ユーザーおよびロール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="security.principal.alias" value="MAP_NAME"/>
<property name="security.principal.key" value="KEY_NAME"/>
<property name="ldap.url" value="ldap://stadk06:3060"/>
<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.aliasName

キーストアからX.509証明書と秘密鍵を取得するために使用する別名を指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: WASセルのWLSドメインの名前。

trust.issuerName

トークンに含める名前を指定します。発行先のトラスト・サービスにより、トークンを取得して検証するために使用されます。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: WASセルのWLSドメインの名前。

trust.csf.map

キーストアにアクセスするための資格証明のマップを指定します。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.csf.mapの値。

trust.csf.keystorePass

秘密鍵にアクセスするための資格証明のキーを指定します(マップはtrust.csf.mapにより設定されます)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.pass.csf.keyの値。

trust.csf.keyPass

キーストアにアクセスするための資格証明のキーを指定します(マップはtrust.csf.mapにより設定されます)。

Java EEアプリケーションとJava SEアプリケーションで有効です。

オプション。

デフォルト: キーストア・インスタンス・プロパティkeystore.sig.csf.keyの値。

次の例では、トラスト・サービスの構成を示します。

<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"/>
<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、Custom。

いいえ

None、Low、MediumまたはAll

なし

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.4.3項「setAuditPolicy」を参照してください。

いいえ

audit.maxDirSize

監査ファイルが書き込まれるディレクトリのサイズを制御しますバイト単位

いいえ

102400000

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

次の例は、監査サービスの構成を示しています。

<serviceInstance name="audit" provider="audit.provider" location="./audit-store.xml">
<property name="audit.filterPreset" value="None"/>
<property name="audit.loader.jndi" value="jdbc/AuditDB"/>
<property name="audit.loader.repositoryType" value="File" />
<property name="auditstore.type" value="file"/>
</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://stadk06.us.oracle.com:3060" name="ldap.url"/>
</serviceInstance>

次の例は、RDBMSベースのプロバイダに対するキーストア・サービスの構成を示しています。

<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>

…
…
<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 セキュリティ・データのアップグレード

この付録では、セキュリティ・データを更新するいくつかの手順について説明します。具体的には、メジャー・リリース(10.1.3.x)からメジャー・リリース(11.1.1)へのセキュリティ・データのアップグレード方法、およびマイナー・リリース(11g OPSS PS1、PS2、PS3またはPS4)から11g OPSS PS5へのデータのアップグレード方法について、次の各項で説明します。

- upgradeSecurityStoreを使用したアップグレード

- upgradeOpssを使用したポリシーのアップグレード

11gR1から11gR1 PS1にアップグレードする場合:

このアップグレードの組合せの詳細は、『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』のOracle Fusion Middleware 11gリリース1 (11.1.1.1.0)の特別な手順に関する項を参照してください。

Identity Managementのアップグレードの概要および詳細は、Oracle Fusion Middleware Oracle Identity Managementアップグレード・ガイドを参照してください。

G.1 upgradeSecurityStoreを使用したアップグレード

OPSSスクリプトupgradeSecurityStoreは、以前のメジャー・リリース(10.1.1.3など)からより新しいメジャー・リリース(11.1.1.1など)にアプリケーション・セキュリティ・データをアップグレードする場合にのみ使用します。11gのマイナー・リリース間でのアップグレードには、「upgradeOpssを使用したポリシーのアップグレード」で説明しているように、upgradeOpssを使用してください。

アップグレードの対象がLDAPベースのリポジトリの場合には、スクリプトを実行する前にいくつかの設定が必要になります。第8.2.2項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

このスクリプトはオフラインです。つまり、実行中のサーバーに接続しなくても動作し、WebLogicではインタラクティブ・モードまたはスクリプト・モードで、WebSphereではインタラクティブ・モードでのみ実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにスクリプトを入力すると、応答が即座に表示されます。スクリプト・モードの場合、スクリプトはテキスト・ファイルに記述し、シェル・スクリプトのディレクティブのように入力なしで実行できます。

OPSSスクリプトを実行する場合のプラットフォーム固有の要件は、「重要事項」を参照してください。

スクリプト・モードおよびインタラクティブ・モードの構文

スクリプト構文は、アップグレードされるストアのタイプによって異なります。オプションの引数は角カッコで囲まれています。スクリプト・モードの構文では、わかりやすいように引数が別々の行に記述されています。

10.1.3.x XMLのアイデンティティ・データを11g リリース1 (11.1.1) XMLのアイデンティティ・データにアップグレードするには、次のいずれかの構文を使用します。

updateSecurityStore -type xmlIdStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
-srcRealm jaznRealm
[-dst dstJpsContext]

updateSecurityStore(type="xmlIdStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", srcRealm="jaznRealm", [dst="dstJpsContext"])

10.1.3.x XMLのポリシー・データを11g リリース1 (11.1.1) XMLのポリシー・データにアップグレードするには、次のいずれかの構文を使用します。

updateSecurityStore -type xmlPolicyStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
[-dst dstJpsContext]

updateSecurityStore(type="xmlPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", [dst="dstJpsContext"])

10.1.3.x Oracle Internet DirectoryのLDAPベースのポリシー・データを11g リリース1 (11.1.1) XMLのポリシー・データにアップグレードするには、次のいずれかの構文を使用します。

updateSecurityStore -type oidPolicyStore
-jpsConfigFile jpsConfigFileLocation
-srcJaznConfigFile srcJazn
[-dst dstJpsContext]

updateSecurityStore(type="oidPolicyStore", jpsConfigFile="jpsConfigFileLocation", srcJaznConfigFile="srcJazn", [dst="dstJpsContext"])

ファイルベースのアプリケーション・ポリシーをリリース11.1.1.1.0からリリース11.1.1.2.0にアップグレードするには、次のいずれかの構文を使用します。

updateSecurityStore -type xmlAppPolicies
-srcApp applicationStripeName
-jpsConfigFile jpsConfigFileLocation
-srcJaznDataFile srcJazn
-dstJaznDataFile dstJazn
-resourceTypeFile resTypeJazn

updateSecurityStore(type="xmlAppPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", srcJaznDataFile="srcJazn", dstJaznDataFile="dstJazn", srcJaznDataFile="resTypeJazn")

11.1.1.1.0のアプリケーション・ポリシーを11.1.1.2.0形式にアップグレードするには、次のいずれかの構文を使用します。

updateSecurityStore -type appPolicies
-srcApp applicationStripeName
-jpsConfigFile jpsConfigFileLocation
-dst dstContext
[-resourceTypeFile resTypeJazn]

updateSecurityStore(type="appPolicies", srcApp="applicationStripeName", jpsConfigFile="jpsConfigFileLocation", dst="dstContext" [, resourceTypeFile="resTypeJazn"])

このアップグレードは所定の位置で動作し、指定したリソース・タイプ、および権限内のパーミッションに対応するリソースが作成されます。

実行が完了したら、jpsConfigFileで渡された構成ファイル内のdstで渡されたコンテキストによって指定されたポリシー・ストアには、srcAppで渡されたアプリケーションに対して定義された新しいリソース・タイプと新しいリソースが格納されます。リソース・タイプはresourceTypeFileで指定されたファイルから読み取られ、リソースはアプリケーション権限内のパーミッションに対応して作成されます。

引数の意味は、次のとおりです。

- typeは、アップグレードするセキュリティ・データの種類を指定します。有効な値は、xmlIdStore、xmlPolicyStore、oidPolicyStore、xmlCredStore、xmlAppPoliciesおよびappPoliciesのみです。

- jpsConfigFileでは、構成ファイルjps-config.xmlの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。アップグレードのターゲット・ストアは、引数dstで指定したコンテキストから読み取られます。
typeがxmlAppPoliciesの場合、構成ファイルは、ソースやターゲットの参照では使用されず、監査サービスの構成でのみ使用されます。監査サービスがjps-config.xmlファイルで指定されていない場合でも、その場所を渡す必要があることに注意してください。

- srcJaznDataFileでは、10.1.3.x jazn-data.xmlファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。指定したtypeがxmlIdStore、xmlPolicyStoreまたはxmlCredStoreの場合、この引数は必須です。
指定したtypeがxmlAppPoliciesの場合、この引数はアプリケーション11.1.1.1.0のjazn-data.xmlファイルの場所を指定します。このファイルにはリソース・タイプの指定はありません。

- srcJaznConfigFileでは、10.1.3.x jazn構成ファイルの位置を、このスクリプトを実行するディレクトリを基準とした相対パスで指定します。指定したtypeがoidPolicyStoreの場合、この引数は必須です。

- usersは、それぞれrealmName/userNameという形式で表されたユーザーのカンマ区切りリストを指定します。指定したtypeがxmlCredStoreの場合、この引数は必須です。

- srcRealmは、引数srcJaznDataFileで渡されるファイル内の、移行するアイデンティティを識別するレルム名を指定します。指定したtypeがxmlIdStoreの場合、この引数は必須です。

- dstは、引数jpsConfigFileで渡されるファイル内の、宛先ストアを構成しているjpsContextの名前を指定しますオプション。指定しない場合は、デフォルトのjpsContextが使用されます。

- srcAppでは、アプリケーション・ストライプを指定します。これは、srcJaznDataFileファイルおよびresourceTypeFileファイルに存在するアプリケーション名と一致する必要があります。この名前のストライプは、dstJaznDataFileファイルで作成します。

- dstJaznDataFileでは、アプリケーション11.1.1.2.0のjazn-data.xmlファイルの場所を指定します。このファイルは、リソース・タイプとリソース・インスタンスを指定しており、srcJaznDataFileで指定した元のjazn-data.xmlにかわるものです。

- resourceTypeFileでは、リソース・タイプを指定している11.1.1.2.0 jazn-data.xmlファイルの場所を指定します。

- dstでは、更新するポリシー・ストアを指定している宛先コンテキストを指定します。

G.1.1 使用例

次の各項には、様々なシナリオでのスクリプトupgradeSecurityStoreの使用を示した例が記載されています。

- 例1 - アイデンティティのアップグレード

- 例2 - ファイルベース・ポリシーへのアップグレード

- 例3 - Oracle Internet Directory LDAPベースのポリシーへのアップグレード

- 例4 - リソース・カタログを使用するようファイルベースのポリシーをアップグレード

G.1.1.1 例1 - アイデンティティのアップグレード

次のコマンドを起動すると、10.1.3のファイルベースのアイデンティティが11g リリース1 (11.1.1)のファイルベースのアイデンティティ・ストアに移行します。

upgradeSecurityStore -type xmlIdStore
-jpsConfigFile jps-config-idstore.xml
-srcJaznDataFile jazn-data.xml
-srcRealm jazn.com

このスクリプトの使用では、(a)ファイルjps-config-idstore.xmlおよびjazn-data.xmlが、スクリプトが実行されているディレクトリに格納されていること、(b)ファイルjps-config-idstore.xml内のデフォルトのjpsContextがターゲットのアイデンティティ・ストアを参照していること、および(c)ファイルjazn-data.xmlにjazn.comという名前のレルムが含まれていることを前提としています。

上のサンプルで使用されている2つのファイルから関連する部分を抜粋したものを次に示します。

<!-- excerpt from file jps-config-idstore.xml -->
<serviceProviders>
<serviceProvider name="R11idstore" class="oracle.security.jps.internal.idstore.xml.XmlIdentityStoreProvider" type="IDENTITY_STORE">
<description>11g XML-based IdStore</description>
</serviceProvider>
</serviceProviders>
...
<serviceInstances>
<serviceInstance name="idstore.xml1" provider="R11idstore" location="./jazn-data-11.xml">
<property name="subscriber.name" value="jazn.com"/>
<property name="jps.xml.idstore.pwd.encoding" value="OBFUSCATE"/>
</serviceInstance>
</serviceInstances>
...
<jpsContexts default="default">
<jpsContext name="default">
<serviceInstanceRef ref="idstore.xml1" />
</jpsContext>
</jpsContexts>

<!-- excerpt from jazn-data.xml -->
<jazn-realm>
<realm>
<name>jazn.com</name>
<users> ... </users>
<roles> ... </roles>
</realm>
</jazn-realm>

このサンプルを実行すると、要素<users>内のすべてのユーザーがXMLアイデンティティ・ストアR11idStoreに移行します。

G.1.1.2 例2 - ファイルベース・ポリシーへのアップグレード

次のコマンドを起動すると、10.1.3のファイルベースのポリシー・ストアが11g リリース1 (11.1.1)のポリシー・ストアに移行します。

upgradeSecurityStore -type xmlPolicyStore
-jpsConfigFile jps-config.xml
-srcJaznDataFile jazn-data.xml
-dst destContext

このスクリプトの使用では、ファイルjps-config.xmlおよびjazn-data.xmlが、スクリプトが実行されているディレクトリに格納されていること、ファイルjps-config.xmlにdestContextという名前のjpsContextが含まれていることを前提としています。

上のサンプルで使用されている2つのファイルから関連する部分を抜粋したものを次に示します。

<!-- excerpt from file jps-config.xml -->
<serviceProviders>
<serviceProvider type="POLICY_STORE" name="policystore.xml.provider" class="oracle.security.jps.internal.policystore.xml.XmlPolicyStoreProvider">
<description>R11 XML-based PolicyStore Provider</description>
</serviceProvider>
</serviceProviders>
...
<serviceInstances>
<serviceInstance name="policystore1.xml" provider="policystore.xml.provider">
<property name="R11PolStore" value="jazn-data1.xml"/>
</serviceInstance>
...
<jpsContexts default="default1">
<jpsContext name="default1"> ... </jpsContext>
<jpsContext name="destContext">
...
<serviceInstanceRef ref="policystore1.xml"/>
</jpsContext>
</jpsContexts>

<!-- excerpt from jazn-data.xml -->
<jazn-realm>
<realm>
...
<roles> ... </roles>
</realm>
</jazn-realm>
...
<jazn-policy> ... </jazn-policy>

このサンプルを起動すると、要素<roles>内のすべてのロールと要素<jazn-policy>内のすべてのポリシーがXMLポリシー・ストアR11PolStoreに移行します。

G.1.1.3 例3 - Oracle Internet Directory LDAPベースのポリシーへのアップグレード

次のように起動すると、10.1.4 Oracle Internet DirectoryのLDAPベースのポリシー・ストアが11g リリース1 (11.1.1) Oracle Internet DirectoryのLDAPベースのポリシー・ストアにアップグレードします。

upgradeSecurityStore -type oidPolicyStore
-jpsConfigFile jps-config.xml
-srcJaznConfigFile jazn.xml
-dst destContext

この例に含まれる2つのXMLファイルの場所についての前提は、例2の場合とほぼ同じですこの他に、(a)ターゲットのOracle Internet Directory LDAPベースのポリシー・ストアを指すjpsContext destContextがファイルjps-config.xmlに含まれていること、および(b)移行するポリシーのOracle Internet Directory LDAPサーバーの場所がファイルjazn.xmlに記述されていることを前提としています。

ファイルjazn.xmlから関連する部分を抜粋したものを次に示します。

<jazn provider="LDAP" location="ldap://myCompany.com:3843">
<property name="ldap.user" value="cn=orcladmin"/>
<property name="ldap.password" value="!welcome1"/>
<property name="ldap.protocol" value="no-ssl"/>
<property name="ldap.cache.policy.enable" value="false"/>
<property name="ldap.initctx" value="com.sun.jndi.ldap.LdapCtxFactory"/>
</jazn>

G.1.1.4 例4 -リソース・カタログを使用するようファイルベースのポリシーをアップグレード

次のサンプルを実行すると、アプリケーション11.1.1.1.0のファイルベースのポリシー・ストアがアプリケーション11.1.1.2.0のファイルベースのポリシー・ストアにアップグレードされます。

updateSecurityStore -type xmlAppPolicies
-srcApp PolicyServlet1
-jpsConfigFile ./folder/jps-config.xml
-srcJaznDataFile ./11.1.1.1.0/jazn-data.xml
-dstJaznDataFile ./11.1.1.2.0/final-jazn-data.xml
-resourceTypeFile ./resCat/res-jazn-data.xml

このアップグレードの重要な点は、元の11.1.1.1.0ファイルではリソース・カタログの要素が使用されていませんが、アップグレード後の11.1.1.2.0ファイルではリソース・タイプおよびリソース・インスタンスの要素が使用されることです。

このスクリプトでは、基本的に元のアプリケーションの構成ファイルとリソース・タイプの要素を指定する別のファイルを取得して新しい構成ファイルを作成します。この新しい構成ファイルは、元のファイルと同様にポリシーを指定していますが、リソース・カタログの指定を使用するように変更されています。

元の構成ファイルと新しいアプリケーション構成ファイルのアプリケーションに対する動作はまったく同じです。

このサンプルの実行では、次のことが前提となっています。

- ソース・ファイル./11.1.1.1.0/jazn-data.xmlでアプリケーションPolicyServlet1のポリシーを指定しています。

- リソース・タイプ・ファイル./resCat/res-jazn-data.xmlでアプリケーションPolicyServlet1のリソース・タイプを指定しています。

- 構成ファイル./folder/jps-config.xmlは任意の有効な構成ファイルで、監査サービス・インスタンスを使用していても、使用していなくてもかまいません。いずれの場合も、監査サービスを指定する必要があります。

次のサンプルは、3つのデータ・ファイル(入力ソースのjazn-data.xml、入力リソースのres-jazn-data.xmlおよび出力のfinal-jazn-data.xml)の関連部分を示しています。

入力ソース・ファイルjazn-data.xml

<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<app-roles>
<app-role>
<name>myAppRole2</name>
<display-name>application role myAppRole</display-name>
<members>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole</name>
<display-name>application role myAppRole</display-name>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<app-role>
<name>testrole_DATA</name>
<display-name>application role test</display-name>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>test-entrole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole_PRIV</name>
<display-name>application role private</display-name>
<description>app role private description</description>
<members>
<member>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>developers</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</member>
</members>
</app-role>
</app-roles>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole_PRIV</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>
oracle.adf.share.security.authorization.RegionPermission</class>
<name>dummyName</name>
<actions>view,edit</actions>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.lang.XYZPermission</class>
<name>newxyz</name>
</permission>
</permissions>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.internal.core.principals.JpsXmlEnterpriseRoleImpl</class>
<name>test-entrole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>newxy</name>
<actions>view,edit</actions>
</permission>
</permissions>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>

入力リソース・ファイルres-jazn-data.xml

<jazn-data>
<jazn-realm default="jazn.com">
</jazn-realm>
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<resource-types>
<resource-type>
<name>FileResourceType</name>
<display-name>File Access</display-name>
<description>Resource Type Modelling File Access</description>
<provider-name>provider</provider-name>
<matcher-class>oracle.security.jps.JpsPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>delete,write,read</actions>
</resource-type>
</resource-types>
<jazn-policy>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>

出力データ・ファイルfinal-jazn-data.xml

<jazn-data>
<jazn-realm>
</jazn-realm>
<policy-store>
<applications>
<application>
<name>PolicyServlet1</name>
<app-roles>
<app-role>
<name>myAppRole2</name>
<display-name>application role myAppRole</display-name>
<guid>4341CC10EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole</name>
<display-name>application role myAppRole</display-name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
</members>
</app-role>
<app-role>
<name>testrole_DATA</name>
<display-name>application role test role</display-name>
<guid>4342B670EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>weblogic.security.principal.WLSGroupImpl</class>
<name>test-entrole</name>
</member>
</members>
</app-role>
<app-role>
<name>myAppRole_PRIV</name>
<display-name>application role private</display-name>
<description>app role private description</description>
<guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<members>
<member>
<class>
weblogic.security.principal.WLSGroupImpl</class>
<name>developers</name>
</member>
<member>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</member>
</members>
</app-role>
</app-roles>
<resource-types>
<resource-type>
<name>FileResourceType</name>
<display-name>File Access</display-name>
<description>Resource Type Modelling File Access</description>
<provider-name>provider</provider-name>
<matcher-class>oracle.security.jps.JpsPermission</matcher-class>
<actions-delimiter>,</actions-delimiter>
<actions>delete,write,read</actions>
</resource-type>
</resource-types>
<resources>
<resource>
<name>getClassLoader</name>
<type-name-ref>FileResourceType</type-name-ref>
</resource>
<resource>
<name>newxy</name>
<type-name-ref>FileResourceType</type-name-ref>
</resource>
</resources>
<jazn-policy>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole_PRIV</name>
<guid>4342B671EAFB11DE9F7F17D892026AF8</guid>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>
oracle.adf.share.security.authorization.RegionPermission</class>
<name>dummyName</name>
<actions>view,edit</actions>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
oracle.security.jps.service.policystore.ApplicationRole</class>
<name>myAppRole</name>
<guid>43428F60EAFB11DE9F7F17D892026AF8</guid>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>java.lang.XYZPermission</class>
<name>newxyz</name>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
<grant>
<grantee>
<principals>
<principal>
<class>
weblogic.security.principal.WLSGroupImpl</class>
<name>test-entrole</name>
</principal>
</principals>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>newxy</name>
<actions></actions>
</permission>
</permissions>
<permission-set-refs>
</permission-set-refs>
</grant>
</jazn-policy>
</application>
</applications>
</policy-store>
<jazn-policy>
</jazn-policy>
</jazn-data>

G.2 upgradeOpssを使用したポリシーのアップグレード

upgradeOpssは、PS1、PS2、PS3またはPS4の構成およびストアをPS5の構成およびストアに更新するオフラインのスクリプトです。

アップグレードするストアはファイルベース、LDAPベースまたはDBベースのいずれでもかまわず、複数のWebLogicドメインで共有されている場合もあります。スクリプトは、システム・ポリシー、アプリケーション・ポリシーおよびjps-config.xmlファイルをアップグレードします。

OPSSバイナリとターゲットのポリシー・ストアには、互換性のあるバージョンを使用する必要があります。詳細は、第L.21項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。

重要事項:

サーバーの起動時にアップグレードされたデータがクラスタ内のすべての管理対象サーバーにプッシュされるように、upgradeOpssは管理サーバー・インスタンスをホストするシステム上で実行する必要があります。

これを使用する前に、アップグレードするストアをバックアップしておいてください。LDAPストアの場合には、(構成ファイルでストアのプロパティとして指定されている)ストアのルート・ノードの下にあるデータをすべてバックアップします。アップグレードが失敗した場合には、そのノード全体をリストアします。バックアップの詳細は、特定のLDAPストアのドキュメントを参照してください。

PS1、PS2、PS3またはPS4からPS5にアップグレードするには、次の手順を実行します。

1. アプリケーション・サーバーを停止します。

2. 新しいバイナリをインストールします。

3. DBベースのストアをアップグレードする場合は、Oracle Fusion Middlewareパッチ・セット・アシスタントを使用してDBスキーマを次のようにアップグレードします。

1. 「OPSSスキーマ」ページに移動します。

2. 「接続文字列」、「DBAユーザー名」、「DBAパスワード」、「スキーマ・ユーザー名」および「スキーマ・パスワード」にデータを入力し、「次」をクリックします。

4. 「コマンド構文」の説明に従って、upgradeOpssを実行します。

5. アプリケーション・サーバーを再起動します。

次の点に注意してください:

- オフライン・スクリプトupgradeOpssについては、次の注意が必要です。

- リポジトリ・タイプを変更しません。つまり、アップグレード先のポリシー・ストアのタイプは、アップグレード元のポリシー・ストアのタイプと同じになります。

- 既存のドメインに適用されます。このドメインを再作成する必要はありません。

- アップグレード先のストアがすでにPS5に更新済の場合、スクリプトを実行しても何も変更されません。

- LDAPベースのストアの場合、アップグレード元およびアップグレード先のストアへの接続パラメータは、jps-config.xmlファイルから読み取られるか、引数としてスクリプトに渡されます。

- DBベースのストアの場合、接続パラメータは引数としてスクリプトに渡されます。

- アップグレードするセキュリティ・ストアが複数のドメインによって共有されている場合(結合操作により)、ストアをアップグレードする前に、そのストアを参照するすべてのドメインに新しいPS5バイナリをインストールする必要があります。そうしないと、OPSSセキュリティ・ストアのバージョンがOPSSバイナリのバージョンよりも新しいことを示すPolicyStoreIncompatibleVersionException例外がシステムによってスローされることがあります。

G.2.1 コマンド構文

ファイルベース、LDAPベースまたはDBベースのストアをアップグレードするには、次の構文を使用します。接続引数は、ファイルベースのストアについては不要であり、LDAPベースのストアについてはオプションであり、DBベースのストアについては必須であることに注意してください。

upgradeOpss(jpsConfig="<full path to the old version jps config file>",
jaznData="<full path to the new version OOTB JAZN data file>",
[auditStore="<full path to the OOTB audit-store.xml file>"],
[jdbcDriver="<jdbc driver>",
url="<jdbc-ldap url>",
user="<jdbc-ldap user>",
password="<jdbc-ldap password>"],

引数の意味は、次のとおりです。

- jpsConfigは、PS1、PS2、PS3またはPS4のjps-config.xml構成ファイルの場所へのフルパスを指定します。この構成ファイルは、名前に接尾辞.bakが追加されたファイルとして、スクリプトにより同じディレクトリにバックアップされます。この引数は必須です。

- jaznDataは、PS5の出荷時のsystem-jazn-data.xmlファイルの場所へのフルパスを指定します。この引数は必須です。

- auditStoreは、PS5の出荷時のaudit-store.xmlファイルの場所へのフルパスを指定します。この引数はオプションです。指定しない場合は、デフォルトでaudit-store.xmlが使用されます。

- jdbcDriverは、ストアに対するJDBCドライバを指定します。LDAPベースのストアについてはオプション、DBベースのストアについては必須です。

- urlは、JDBC URLまたはLDAP URLをdriverType:host:port:sid形式で指定します。DBベースおよびLDAPベースのストアの両方に必須です。指定しない場合は、構成ファイルから読み取られます。

- userは、JDBCユーザー名またはLDAPバインド名を指定します。LDAPベースのストアについてはオプション、DBベースのストアについては必須です。指定しない場合は、構成ファイルから読み取られます。LDAPベースのストアの場合、アップグレードを実行するユーザーには、スキーマ、ルート・ノード、およびcn=OPSS,cn=OracleSchemaVersionの下のすべてのノードに対する読取りおよび書込み権限が必要です。DBベースのストアの場合は、OPSS DBスキーマ・ユーザーとしてアップグレードを実行します。

- passwordは、指定されたuserに対するパスワードを指定します。これは、DBベースのストアの場合はJDBCパスワード、LDAPベースのストアの場合はJDBCバインド・パスワードになります。LDAPベースのストアについてはオプション、DBベースのストアについては必須です。指定しない場合は、構成ファイルから読み取られます。

H リファレンス

この付録には、開発者にとって役立つ参照ドキュメントが記載されています。

H.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 MBeans Java API Reference for Oracle Platform Security Services』

OPSSユーザーおよびロールAPI

『Oracle Fusion Middleware User and Role Java API Reference for Oracle Platform Security Services』

Oracle Security Developer Tools API

『Oracle Fusion Middleware PKI SDK CMP Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware CMS Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware Crypto Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware PKI SDK LDAP Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware Liberty 1.1 Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware Liberty 1.2 Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware S/MIME Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware PKI SDK OCSP Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware Security Engine Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware SAML 1.0/1.1 Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware SAML 2.0 Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware PKI SDK TSP Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware Web Services Security Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware XKMS Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware XML Security Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware Crypto FIPS Java API Reference for Oracle Security Developer Tools』

『Oracle Fusion Middleware JCE Java API Reference for Oracle Security Developer Tools』

I OPSSスクリプト

OPSSスクリプトは、Oracle WebLogic ServerのコンテキストではWLSTスクリプトであり、WebSphere Application ServerのコンテキストではWASAdminスクリプトです。この章で示すスクリプトは、WebLogic Application ServerとWebSphere Application Serverの両方のプラットフォームに適用されます。

WebSphere Application Server固有のOPSSスクリプトの詳細は、Oracle Fusion Middlewareサード・パーティ・アプリケーション・サーバー・ガイドを参照してください。

次の各項で、OPSSのセキュリティ関連のスクリプトについて説明します。

- ポリシー関連のスクリプト

- 資格証明関連のスクリプト

- その他のセキュリティ・スクリプト

- 監査スクリプト

I.1 ポリシー関連のスクリプト

次のスクリプトの詳細は、第9.3項「OPSSスクリプトによるアプリケーション・ポリシーの管理」を参照してください。

- listAppStripes

- 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

- listEntitlement

- listResourceTypes

I.2 資格証明関連のスクリプト

次のスクリプトの詳細は、第10.5項「OPSSスクリプトによる資格証明の管理」を参照してください。

- listCred

- updateCred

- createCred

- deleteCred

- modifyBootStrapCredential

- addBootStrapCredential

- exportEncryptionKey

- importEncryptionKey

- restoreEncryptionKey

I.3 その他のセキュリティ・スクリプト

- migrateSecurityStore
詳細は、第8.6.2項「スクリプトmigrateSecurityStoreを使用した移行」を参照してください。

- reassociateSecurityStore
詳細は、第9.3.29項「reassociateSecurityStore」を参照してください。

- upgradeSecurityStore
詳細は、第G.1項「upgradeSecurityStoreを使用したアップグレード」を参照してください。

- upgradeOpss
詳細は、第G.2項「upgradeOpssを使用したポリシーのアップグレード」を参照してください。

I.4 監査スクリプト

監査関連のスクリプトの詳細は、第C.4項「監査のためのWLSTコマンド」を参照してください。

J OpenLDAPアイデンティティ・ストアの使用

この付録では、アイデンティティ・ストアでOpenLDAP 2.2を使用する場合に必要となる特殊な設定について説明します。

J.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をその外部ロールに追加できます。外部ロールをアプリケーション・ロールにマッピングするためには、このオブジェクト・クラスが必要です。

K ID仮想化のためのアダプタ構成

第7.3項「アイデンティティ・ストア・サービスの構成」で説明しているID仮想化機能では、分割プロファイルをサポートするために追加の構成がいくつか必要です。

この付録では、分割プロファイルに使用されるアダプタの作成方法および管理方法について説明します。

- 分割プロファイルについて

- 分割プロファイルの構成

- 結合ルールの削除

- 結合アダプタの削除

- アダプタの可視性の変更

K.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から取り込まれます。

K.2 分割プロファイルの構成

同じユーザーが両方のアイデンティティ・ストアに存在していて、それぞれのストアでユーザー属性が別々になっています。ユーザー・レコードを問い合せる場合には、両方のストアのデータが必要です。構成タスクは次のとおりです。

1. virtualizeプロパティを使用してアイデンティティ・ストア・サービスを構成し、複数のLDAPストアに対して問合せができるようにします。
詳細は、第7.3項「アイデンティティ・ストア・サービスの構成」を参照してください。

2. Weblogic AdminServerに接続してWLSTコマンドを実行し、アイデンティティ・ストアの結合アダプタを構成します。
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がプライマリ・アダプタのネームスペースに対応している必要があります。パラメータの詳細は、第7.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管理サーバーと管理対象サーバーを再起動します。

K.3 結合ルールの削除

removeJoinRuleコマンドを使用して、結合アダプタから結合ルールを削除します。

構文

removeJoinRule

adapterName ="アダプタ名"

secondary="結合ルールに関連付けられているセカンダリ・アダプタ"

例

removeJoinRule(adapterName="JoinAdapter1", secondary="OID")

K.4 結合アダプタの削除

deleteAdapterコマンドを使用して、結合アダプタを削除します。

構文

deleteAdapter(adapterName="名前")

例

deleteAdapter(adapterName="JoinAdapter1")

K.5 アダプタの可視性の変更

modifyLDAPAdapterコマンドを使用して、アダプタの可視性を変更します。例:

modifyLDAPAdapter(adapterName="AuthenticatorName", attribute="Visible", value="Yes")

L Oracle Fusion Middlewareのセキュリティのトラブルシューティング

この付録では、Oracle Enterprise Manager Fusion Middlewareセキュリティを構成および使用する際に発生する可能性のある共通の問題について説明し、その解決方法を紹介します。次の項目が含まれます。

- セキュリティ・エラーの診断

- 再関連付けの失敗

- サーバーの起動の失敗

- パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致

- LDAPサーバーへの接続の失敗

- 組込みのLDAP認証プロバイダへの接続の失敗

- ユーザーおよびロールAPIの失敗

- ドメイン資格証明ストアのデータへのアクセスの失敗

- 匿名SSL接続の確立の失敗

- 認可チェックの失敗

- ユーザーによる予期しないパーミッションの取得

- セキュリティ・アクセス制御の例外

- 実行時のパーミッション・チェックの失敗

- サーバーの起動前のパーミッション・チェックの失敗

- ポリシーの移行の失敗

- ポリシーに使用する文字

- Java SEアプリケーションにおけるパーミッションの付与

- Oracle Business Intelligenceレポート作成のトラブルシューティング

- ポリシー・ストアでの属性照合時の検索の失敗

- 不明なホスト例外による検索の失敗

- バイナリとポリシー・ストアのバージョンの非互換性

- ポリシー・ストアのバージョンの非互換性

- 追加のヘルプ

L.1 セキュリティ・エラーの診断

この項では、様々なセキュリティ・エラーの診断と解決に利用できるツールについて説明します。次の項目が含まれます。

- ログ・ファイルとOPSSロガー

- システム・プロパティ

- セキュリティ・エラーの解決

Fusion Middleware Controlでは、発生したフォルトの管理、分離または解釈に役立つ可能性がある場合はいつでも、ロギングのサポートが明示的に提示されます。

L.1.1 ログ・ファイルとOPSSロガー

この項では、Oracle WebLogic Serverでサポートされている様々なログ・ファイルとOPSSロガーを紹介し、Fusion Middleware Controlでロガー・レベルの構成と設定、およびログ・ファイルの検索と表示を行う方法について説明します。この項の内容は次のとおりです。

- 診断ログ・ファイル

- 一般的なログ・ファイル

- 認可ロガー

- オフラインOPSSスクリプト・ロガー

- その他のOPSSロガー

- 監査ロガー

- Fusion Middleware Controlを使用したロガーの管理

L.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(管理対象サーバー・ログ)。

すべてのサーバー・インスタンスは、セキュリティ関連のエラーを診断ファイルに出力します。サーバー関連のセキュリティ・エラー(サブジェクトやプリンシパルの問題で発生した例外など)、およびドメイン・セキュリティ・データを移行または再関連付けするときに発生する可能性のあるエラーは、管理サーバー診断ログに書き込まれます。アプリケーション関連のセキュリティ・エラー(アプリケーション固有のポリシーまたは資格証明で発生した例外など)は、対応する管理対象サーバーの診断ログに書き込まれます。

L.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 Fusion Middleware Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・ログ・ファイルとドメイン・ログ・ファイルに関する項を参照してください。

Oracle WebLogicフレームワークについては、『Oracle Fusion Middleware Oracle WebLogic Server診断フレームワークの構成と使用』を参照してください。

ロギング・サービスの詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverロギング・サービスによるアプリケーション・ロギング』を参照してください。

Oracle Fusion Middlewareにおけるロギングのすべての詳細は、『Oracle Fusion Middleware管理者ガイド』の「ログ・ファイルと診断データの管理」の章を参照してください。

L.1.1.3 認可ロガー

OPSSでは、実行時の認可の失敗をトラブルシューティングするのに役立つ2つのロガーを提供しています。

- oracle.security.jps.util.JpsAuth

- oracle.security.jps.trace.logger

この2つのロガーは、他のOPSSロガーと同様に、有効と無効を動的に切り替えることができます。つまり、Oracle WebLogic Application Serverを停止して再起動する必要はありません。ロガーのプロパティを設定する方法の詳細は、「Fusion Middleware Controlを使用したロガーの管理」を参照してください。前述の2つのロガーのレベルは、TRACE:32に設定する必要があります。

追加のロガーの詳細は、「その他のOPSSロガー」を参照してください。

L.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

L.1.1.3.2 oracle.security.jps.trace.logger

ロガーoracle.security.jps.trace.loggerは、アプリケーション・ロール、パーミッション、ターゲット、プリンシパルおよび付与されたポリシーと拒否されたポリシーに関する情報をログに記録します。このロガーを有効にすると、出力が大きくなる可能性があるため、単一使用ケースのデバッグにのみ使用することをお薦めします。具体的には、このロガーは次のものを記録します。

- 認可リクエストに関する次の情報。エンタープライズ・ロールに付与されたアプリケーション・ロール、すべての拒否と付与、パーミッション・クラス名、パーミッション・ターゲットおよびプリンシパル名。

- ロールにプリンシパルが追加されたときなどの、メンバー・キャッシュの更新。キーワード: 「プリンシパル:」、「挿入されたロール:」。

- 情報を管理するロール。キーワード: 「アプリケーション内:」、「プリンシパルのクエリー・ストア:」、「ダイレクト・アプリケーション・ロールの数:」。

- メソッドgetPermissionsに対するコール。

L.1.1.4 オフラインOPSSスクリプト・ロガー

migrateSecurityStoreなどのオフラインOPSSスクリプトの使用時には、次のシステム・プロパティを指定してJVMを起動することにより、OPSSロガーを有効にできます。

-Djava.util.logging.config.file=<path>/logging.properties

logging.propertiesは必要なロガー・プロパティが有効になっているテキスト・ファイルです。このファイルの形式については、java.util.logging.LogManagerクラスのドキュメントを参照してください。適切なレベルでOPSSロガーを有効にするlogging.propertiesファイルの例を示します。

#The messages will be written to a file
handlers=java.util.logging.FileHandler

#The default level for all loggers is INFO
.level=INFO

#For common usage - user manager, jps config etc.
oracle.jps.common.level=FINEST

# For Migration and Upgrade
oracle.jps.upgrade.level=FINEST
oracle.jps.patching.level=FINEST
oracle.jps.policymgmt.level=FINEST

#Configure file information. %h is the user home directory (user.home)
java.util.logging.FileHandler.pattern = /tmp/opss/opss_upgrade%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter

L.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に設定すると、送信されたリクエストに関する情報(アイデンティティ、リソース、アクション、コンテキスト)および認可結果が記録されます。

L.1.1.6 監査ロガー

Fusion Middleware監査フレームワークには、いくつかのランタイム・コンポーネントがあります。この項では、これらのコンポーネントの診断ログ・ファイルを紹介し、診断メッセージの解釈方法について説明します。

これらのログ・ファイルは、次の場所にあります。

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

表L-1は、様々な診断ログ・ファイルを示しています。

表L-1 監査診断のログ・ファイル

コンポーネント

ログの保存場所

ロガーの構成

監査APIを使用するJava EEコンポーネント

DomainName/servers/$SERVER_NAME/logs/$SERVER_NAME-diagnostic.log

oracle.security.audit.logger(この表の下の手順を参照)

監査APIを使用するOPMNコンポーネント

コンポーネントのログ・ファイルを探す方法については、管理者ガイドを参照してください。

ロガーは、OPMNコンポーネントの場所に基づいています。該当するコンポーネント・ガイドを参照してください。

起動クラス監査ローダー

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

L.1.1.6.1 監査ロガーの構成

Fusion Middleware Controlを使用してoracle.security.audit.loggerを構成できます。

oracle.security.audit.loggerでは、ERRORからTRACEまでの任意のログ・レベルを設定し、ログに記録される情報の量を制御できます。

Fusion Middleware Controlを使用して、これらの診断ファイルを表示することもできます。

関連項目:

次の各項の詳細は、『Oracle Fusion Middleware管理者ガイド』の第10章「ログ・ファイルと診断データの管理」を参照してください。

- ロガーの構成手順

- ドメイン、サーバーおよび各アプリケーションのログ表示に関する詳細

L.1.1.6.2 監査診断の解釈

監査診断メッセージは、エラー・メッセージとトレース・メッセージという2つのタイプに分類できます。

すべてのエラー・メッセージには、IAU-XXXという番号が付けられます。これらのメッセージについては、考えられる原因とエラーへの対処方法が記載されたエラー・メッセージ・ガイドを参照してください。

これに対し、トレース・メッセージは、実行されているコンポーネントの詳細情報を示すためのものです。メッセージの性質に応じて、なんらかの処置が必要になることもあります。

L.1.1.7 Fusion Middleware Controlを使用したロガーの管理

Fusion Middleware Controlには、ログ情報を管理するためのページがいくつか用意されています。このツールを使用して、次の操作を実行できます。

- ログのレベルとローテーションなど、ログ・ファイルの属性を構成します。

- ドメイン内にあるすべてのログ・ファイルのコンテンツを検索し、メッセージID別またはタイプ別に問合せ結果をグループ分けします。

- コンテキストまたは期間により特定のエラーとその他のエラーの相関を分析します。

- ログ・ファイルの一部または問合せ結果を複数のフォーマットのいずれかでダウンロードします。

この項では、ログ・ファイルの構成方法について簡単に説明します。前述の他の3つの機能についても、第L.1.3項「セキュリティ・エラーの解決」に簡単な説明があります。

これらの各項のすべての詳細は、『Oracle Fusion Middleware管理者ガイド』のログ・ファイルと診断データの管理に関する項を参照してください。

Fusion Middleware Controlを使用してログ・ファイルを構成するには、次の手順を実行します。

1. 「サーバー」→「ログ」→「ログ構成」に移動して、選択したサーバーの「ログ構成」ページを表示します。このページを使用して、永続ロガーとアクティブなランタイム・ロガーの両方に対するログ・レベルを構成できます。

2. 必要なログ出力に対するログ・ファイル・エントリをクリックして、そのファイルに対する現在のパラメータ設定を示すページを表示します。

3. このページで、行を選択し、「構成の編集」ボタンをクリックして、「ログ・ファイルの編集」ダイアログ・ボックスを表示します。このダイアログ・ボックスで、ログ・レベルやローテーション・ポリシーなどの様々なパラメータを設定できます。通常は、ロガー・レベルをTRACE:32に設定します。

L.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にプロパティを追加する必要があります。

L.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に設定されています。本番環境では、パーミッション・チェック・メッセージの無効化はお薦めしません。

L.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に設定されています。

L.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]を検索します。

L.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も設定しません。

L.1.3セキュリティ・エラーの解決

エラーが発生したときに、そのエラーを解決する一般的な方法はありません。そのため、ヒントを検索し、できればエラーの原因を分離して理解するまで、多くの場合複数の仮定に従う必要があります。この目的を達成するために、この項では、ログ情報を検索して解釈し、最も一般的なセキュリティ・エラーを解決する方法について説明します。この項の内容は次のとおりです。

- サンプル・ログ・エントリの理解

- Fusion Middleware Controlを使用したログの検索

- Fusion Middleware Controlを使用したメッセージ・コンテキストの識別

- Fusion Middleware Controlを使用したエラー・リスト・ファイルの生成

L.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エラー・コードのリストについては、Oracle Fusion Middlewareエラー・メッセージ・リファレンスの第41章を参照してください。

- [oracle.jps.admin]
ロガーのカテゴリを識別します。oracle.jpsのサブカテゴリ(前述のadminなど)は、発生したエラーの種類に対するヒントを与えます。oracle.jpsのサブカテゴリの詳細なリストは、「oracle.jpsのサブカテゴリ」を参照してください。

- [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
発生した例外とその理由を識別します。

oracle.jpsのサブカテゴリ

次のリストは、oracle.jpsのサブカテゴリと、各カテゴリで記録されるエラーの種類を示しています。

- common - 一般的なエラー。

- config - 構成エラー。

- deployment - デプロイ・エラー。

- authentication - Java SEアプリケーションのみのログイン・モジュール・エラー。

- idmgmt - アイデンティティ・ストア・エラー。

- credstore - 資格証明ストア・エラー。

- authorization - 実行時のポリシー・ストア・エラー。

- policymgmt - ポリシー・ストア管理エラー。

- admin - JMXエラーおよびWLSTエラー。

L.1.3.2 Fusion Middleware Controlを使用したログの検索

ドメイン内のすべてのログ・ファイルのコンテンツで検索を開始するには、「ドメイン」→「ログ」→「ログ・メッセージの表示」を選択して、「ログ・メッセージ」ページを表示します。

このページには、検索問合せを指定するために選択できる複数のパラメータがあります。具体的には、次の操作が可能です。

- 適切な「日付範囲」を選択することで、メッセージが発行される期間を選択できます。

- 「メッセージ・タイプ」ボックスのいずれかを選択することで、特定の重大度エラーを含むメッセージを表示できます。

- 「メッセージ」メニューから項目を選択し、その横にあるボックスに文字列を入力することで、さらなる制約を満たすメッセージを表示できます。たとえば、文字列exceptionを含むメッセージに対してのみ問合せを行うことができます。

- 「フィールドの追加」ボタンをクリックし、選択肢のいずれかを選択することによって、新たな問合せフィールドを追加できます。たとえば、「ホスト」フィールドを追加し、特定の文字列を先頭文字として指定した問合せ(「次で始まる」フィールドに入力)などを実行できます。

これらのパラメータを設定して、「検索」をクリックすると、問合せの結果がこのページに表示されます。問合せの結果は、「表示」メニューから項目を選択することで、メッセージ・タイプ別、メッセージID別、またはメッセージの単純なリストで詳細に表示し直すことができます。さらにこの結果を、ページの右上にあるメニューから項目を選択することで、自動的にリフレッシュすることもできます(デフォルトでは「手動リフレッシュ」に設定)。

検索範囲をドメインを越えたログ・ファイルにまで拡張するには、ページの右上にある「広範囲のターゲット・スコープ」ボタンを使用します。

L.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. 「時間別の関連メッセージ」ページで、ページの右側にある「有効範囲」メニューから項目を選択することで、選択したメッセージの時間前後の時間ウィンドウを変更できます。

L.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
#

L.2 再関連付けの失敗

ファイルベースのストアから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)再関連付けを再実行します。

L.2.1 再関連付けしたポリシー・ストアのポリシーの欠落

現象

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

L.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以上であることが必要です。サポートされているバージョンのリストは、第8.2項「LDAPベースのOPSSセキュリティ・ストアの使用方法」を参照してください。

L.3 サーバーの起動の失敗

この項では、Oracle WebLogic Serverの起動に失敗する理由をいくつか説明します。この項の内容は次のとおりです。

- 必須のLDAP認証プロバイダの欠落

- 管理者アカウントの欠落

- パーミッションの欠落

- NFSマウントされたドメイン・ディレクトリを持つサーバーの起動失敗

L.3.1 必須のLDAP認証プロバイダの欠落

この項では、ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗する可能性がある理由について説明します。

現象

ドメイン内の認証プロバイダのリストを変更すると、Oracle WebLogic Serverの起動に失敗し、出力されるエラー・メッセージに次の内容が含まれます。

java.lang.IllegalArgumentException: null KeyStore name

診断

この問題の原因の1つは、ドメイン内の認証プロバイダのリストに、LDAP認証プロバイダが含まれていないことです。

重要:

OPSSを使用するすべてのドメインで、このリストのいずれかのLDAP認証プロバイダが必須です。

解決策

サーバーを起動できないため、次の手順に従って、手動で1つの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

L.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. WebLogic管理コンソールを使用して、Oracle Internet Directory認証プロバイダに、Administratorsグループのメンバーであるアカウントを作成します。

2. Oracle Internet Directory認証プロバイダのフラグを、SUFFICIENTに設定します。

3. サーバーを再起動します。デフォルトの認証プロバイダに指定されたAdministratorsグループのアカウントを使用しているので、問題なく起動するはずです。

4. Oracle Internet Directory認証プロバイダのフラグをREQUIREDに再設定して、デフォルトの認証プロバイダを削除します。これで、Oracle Internet Directory認証プロバイダに作成したAdministratorsグループのアカウントを使用して、サーバーが起動します。

L.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リソースの保護のすべての詳細は、『Oracle Fusion Middleware Oracle WebLogic Serverセキュリティのプログラミング』を参照してください。

注意:

Printing Security Managerは、Javaセキュリティ・マネージャに対するWebLogicサーバーの拡張機能です。Printing Security Managerを使用して、Javaセキュリティ・マネージャの下で実行されているJavaアプリケーションで必要なすべてのパーミッションを識別できます。必要なパーミッションを一度に1つずつ識別するJavaセキュリティ・マネージャとは異なり、Printing Security Managerは、必要なパーミッションのすべてを自動的に識別します。

L.3.4 NFSマウントされたドメイン・ディレクトリを持つサーバーの起動失敗

この項では、Oracle WebLogic Serverの起動に失敗する理由について説明します。

現象

ドメイン・ディレクトリ${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を設定してサーバーを起動します。

診断

orapkiを有効にすると、サーバーの起動失敗の本当の原因が前述の2つ目のエラー・メッセージで報告されます。OPSSではファイルベースのストアでのセキュリティ・アーティファクトの管理時にファイルのロックが必要であるため、このエラー・メッセージはドメイン・ディレクトリがNFSマウントされているファイル・システムでファイルのロックがサポートされていないことを示しています。

解決策

次のいずれかの方法を実行します。

- NFS v3からNFS v4にアップグレードします。

- nolockオプションを有効にしてリモート・ファイル・システムをマウントします。

- ${domain.home}/config/fmwconfig内のファイルをローカル記憶域に移動します。

L.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>を参照してください。

L.4 パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致

この項では、エンタープライズ・ユーザーまたはロール(グループ)へのパーミッションの付与または取消に失敗する、よくある理由について説明します。

現象

ドメイン認証プロバイダに適切に入力されたエンタープライズ・ユーザーまたはグループに対して、権限付与で定義されたパーミッションが付与または取消されません。

診断

この問題は、(ドメイン認証プロバイダに)格納されている名前と、(ユーザーがアクティブに入力したか、プログラムによって取得された)指定された名前の間に、大文字小文字の不一致がある場合によく発生します。たとえば、このような不一致の例として、格納されているユーザー名が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());

L.5 LDAPサーバーへの接続の失敗

この項では、Oracle Internet Directory LDAPサーバーへの接続が失敗する場合に多く見られる理由について説明します。この失敗は、再関連付け時にも発生する可能性があります。

現象

ソース・リポジトリからターゲットLDAPサーバー・リポジトリへのデータの移行が失敗します。

診断

通常、この種の問題は、ターゲットLDAPサーバーのパラメータ設定が間違っていることが原因です。

Oracle WebLogic Serverのログ・ファイルを調査する場合は、DomainName/servers/AdminServerディレクトリまたはDomainName/servers/ManagedServersディレクトリ内のログ・ファイルで、<Error>、<Critical>および<Warning>という文字列を検索してください。

エラーを特定して解決する方法の詳細は、第L.1項「セキュリティ・エラーの診断」を参照してください。

解決策

移行用に指定したターゲット・サーバー・データが、すべて有効であることを確認します。この確認を行うために、LDAPサーバー管理者の支援が必要になる場合があります。

注意:

Fusion Middleware Controlを使用して、LDAPサーバーへの再関連付けを行う場合、操作を開始する前に、「LDAP認可のテスト」ボタンを使用してください。通常は、このテストにより、間違って指定されたパラメータを見つけることができます。

L.6 組込みのLDAP認証プロバイダへの接続の失敗

この項では、組込みのLDAP認証プロバイダへの接続に失敗する場合に多く見られる理由について説明します。

現象

クライアント・アプリケーションがユーザーおよびロールAPIを介して組込みのLDAP認証プロバイダに問合せをリクエストするために使用される接続は、接続プールに格納され、維持されます。デフォルトおよび出荷時の状態では、このプールは、JNDIプールとしてファイルjps-config.xmlに指定されています。

このプールの同時接続数が、LDAPサービスの最大許容数を超えると、クライアント・アプリケーションはサービスに接続できなくなり、すでに接続中の場合はsocket closed例外を受信します。この場合、サーバーのログで、許容される同時接続数を超えたことが示されます。

診断

この制限を超えないようにするには、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)どちらの場合も変更を有効化するにはサーバーを再起動する必要があることに留意してください。

L.7 ユーザーおよびロール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項「WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」を参照してください。

L.8 ドメイン資格証明ストアのデータへのアクセスの失敗

この項では、ドメイン資格証明ストアのデータへのアクセスに失敗する、よくある理由について説明します。

現象

アプリケーションが、ドメイン資格証明ストアからの資格証明データの取得に失敗し、(次に示すような行を含む)エラー・メッセージがログに記録されます(角カッコ内のテキストには、特定の失敗に固有の情報が記述されます)。

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を使用してパーミッションを指定するには、第9.2項「Fusion Middleware Controlを使用したポリシーの管理」を参照してください。

OPSSスクリプトを使用してパーミッションを指定するには、第9.3項「OPSSスクリプトによるアプリケーション・ポリシーの管理」を参照してください。

ファイル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>

L.9 匿名SSL接続の確立の失敗

この項では、ポリシーと資格証明の再関連付けを行うときに匿名SSL接続を確立できない、よくある理由について説明します。

現象

Fusion Middleware Controlを使用してOracle Internet Directoryサーバーによるファイルベースのポリシーおよび資格証明とLDAPベースの記憶域の再関連付けを行う際の手順として、LDAPサーバーへの匿名SSL接続をテストします(具体的には、「LDAPのテスト」ボタンを使用します)。その結果、このテストに失敗します。

診断

ターゲットLDAPサーバーがOracle WebLogic Serverによって信頼され、LDAPサーバーへの接続に使用するポート番号がSSLポートである必要があります。

解決策

LDAPサーバーへの接続を確立するには、LDAPサーバー上であらかじめ一部の構成を行っておく必要があります。詳細は、第8.2.2項「LDAPベースのセキュリティ・ストアを使用する場合の前提条件」を参照してください。

さらに、匿名SSL接続を使用するには、セキュアなデータを受信するために設定されたポートを入力する必要があります。このポートを使用してLDAPサーバーを構成しなかった場合、接続は失敗します。

指定されたLDAPサーバー・ポートが、匿名SSLモードでリスニングするように構成されたSSLポートであること、および指定されたサーバー名にアクセス可能であることを確認します。通常、このポートの設定はLDAPサーバーの管理者が行います。

L.10 認可チェックの失敗

この項では、認可チェックが失敗する理由について説明します。

現象

アプリケーションによるユーザーの認可が失敗し、次のような行を含むエラーがログに記録されます。

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つの名前は一致します。ただし、複数のアプリケーションが同じポリシー・ストライプを共有する場合は、異なる可能性があります。

L.11 ユーザーによる予期しないパーミッションの取得

この項では、ユーザーが予期したもの以外のパーミッションを取得する、よくある理由について説明します。

現象

新しいユーザーまたは変更されたユーザーが、予期しないパーミッションを取得します。

診断

この問題は、すでに削除されたユーザーの名前を使用してユーザーを追加した場合、または古いユーザーがその名前またはuidを変更した場合に、よく起こります。ユーザーが予期したより多くの(または少ない)パーミッションを取得する、よくある理由は、ユーザーを削除する前またはユーザー・データを変更する前に、ポリシー・ストアが適切に更新されていないことです。

解決策

ユーザーを削除する前に、ユーザーに付与されていたすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに継承される可能性があります。

ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、ロール)を更新して、新しいデータでも予期したとおりに機能するようにする必要があります。

L.12 セキュリティ・アクセス制御の例外

この項では、コードでセキュリティ・アクセス制御の例外が発生する理由について説明します。

現象

実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。

<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;
...

前述の権限付与の例では、読取り操作のみを許可しているため、権限が付与されたブロック内であっても、設定操作またはリセット操作のいずれも機能しないことに注意してください。

L.13 実行時のパーミッション・チェックの失敗

この項では、パーミッションで、パーミッション・チェックに合格できない理由について説明します。

現象

実行時に、アプリケーションが次のようなエラーを出力します(最初の数行のみが表示されています)。

[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つのパーミッション・クラスを共有する場合、システム・クラス・パスにそのクラスを含めてください。

L.14 サーバーの起動前のパーミッション・チェックの失敗

この項では、サーバーが起動フェーズを完了する前にパーミッション・チェックが失敗する理由について説明します。

現象

サーバーの起動前に認可チェックが失敗します。サーバーの起動が完了すると、次のような行が出力されます。

<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に設定します。

L.15 ポリシーの移行の失敗

この項では、アプリケーション・デプロイ時のポリシーの自動移行が失敗する理由について説明します。アプリケーションのデプロイは、ポリシーの移行に失敗しても、成功する場合があることに注意してください。

注意:

この項で説明されている自動移行に失敗する理由が、ドメイン・ストアの再関連付けを行う際にも、同様の失敗につながる可能性があります。

移行に関連する失敗については、「ポリシー・ストアのバージョンの非互換性」も参照してください。

現象

デプロイ時にポリシーを自動的に移行するように、アプリケーションが構成されています。アプリケーションのデプロイは成功しますが、デプロイされていたサーバーに対応する診断ファイルに、次のようなメッセージが出力されます。

[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ファイルで適切に定義されていることを確認します。参照されたロール名が、前述の例のように一致しない場合、移行は失敗します。

L.16 ポリシーに使用する文字

この項では、ポリシーに使用する文字に関する問題をいくつか説明します。この項の内容は次のとおりです。

- Oracle Internet Directory 10.1.4.3での特殊文字の使用

- 特定の文字が含まれるXMLポリシー・ストア

- アプリケーション・ロール名に使用する文字

- XMLポリシー・ストアでの改行文字の欠落

L.16.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に適用します。

L.16.2 特定の文字が含まれるXMLポリシー・ストア

この項で説明する問題は、XMLポリシー・ストアにのみ関連します。つまり、LDAPベースのポリシー・ストアには適用されません。

ここで問題となる文字は次のとおりです。

< "  &  $ ? * , / \ ` :    ( ) ^ ' % +  { }

これらの文字は、ファイルベースのポリシー・ストアを使用する場合には、アプリケーション・ロール名に使用しないことをお薦めします。

たとえばロールを作成するために、これらのいずれかの文字の使用が必要になった場合は、正常な結果が返されるように、ApplicationPolicy.searchAppRoles()などのAPIポリシー・ストア・メソッドへの入力でそれらの文字をエスケープ処理します。

たとえば、アプリケーション・ロールにappRole^$という名前を付けた場合、ポリシー・ストアで一致を検索するはApplicationPolicy.searchAppRoles("appRole\\^\\$")のように入力する必要があります。

または、このようにエスケープ処理した特殊文字を使用せずに、次のように検索式にワイルド・カードを使用して、アプリケーション・ロールとの一致が得られるようにすることもできます。

ApplicationPolicy.searchAppRoles("appRole*")

L.16.3 アプリケーション・ロール名に使用する文字

アプリケーション・ロール名は、空白以外の印刷可能な文字列です。つまり、アプリケーション・ロール名は、英数字(ASCIIまたはUnicode)と、空白以外のその他の印刷可能文字(アンダースコアや大カッコなど)で構成することができます。このルールはサポートされている3種類の記憶域XML、LDAPおよびDBのすべてに適用されます。

L.16.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>

L.17 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にも適用されます。

L.18 Oracle Business Intelligenceレポート作成のトラブルシューティング

この項では、Oracle Business IntelligenceをOracle Fusion Middlewareセキュリティのレポート作成ツールとして使用した場合に多く見られる問題とその解決策について説明します。次のトピックが含まれます:

- Oracle Business Intelligence Publisherの監査テンプレート

- Oracle Business Intelligence Publisherのタイムゾーン

L.18.1 Oracle Business Intelligence Publisherの監査テンプレート

Oracle Business IntelligenceでOracle Fusion Middleware監査フレームワークのレポートを表示するには、適切な監査テンプレートを使用する必要があります。

詳細は、第14.1.3項「Oracle Business Intelligence PublisherでのOracle Reportsの設定」を参照してください。

L.18.2 Oracle Business Intelligence Publisherのタイムゾーン

Oracle Business Intelligence Publisherとデータベースが、異なるタイムゾーンのサイトにインストールされている場合、Oracle Fusion Middleware監査フレームワークのレポートに問題が発生することがあります。

この問題を防止するには、Oracle Business Intelligence Publisherとデータベースが、同じタイムゾーンにインストールされていることを確認します。

L.19 ポリシー・ストアでの属性照合時の検索の失敗

この項では、属性のカタログ化が必要な理由について説明します。

現象

ポリシー・ストアの検索中に、次のような例外が発生します。

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関連の属性の場合は必須です。属性の索引作成およびカタログ化は、OPSSスクリプト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

L.20 不明なホスト例外による検索の失敗

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

L.21 バイナリとポリシー・ストアのバージョンの非互換性

この項では、サーバーによって例外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バイナリのバージョンよりも新しいことを示しています。PS3 OPSSバイナリでは、ポリシー・ストアよりも新しいバージョンは使用できません。

OPSSバイナリでこのような非互換性が発生するシナリオには、次の3つがあります。

- シナリオ1

- Domain1とDomain2は同じポリシー・ストアを指しています。Domain1、Domain2およびポリシー・ストアのバージョンはいずれもPS2です。

- Domain1のバイナリをPS3にアップグレードします。

- ポリシー・ストアをPS3にアップグレードします(コマンドupgradeOPSSを使用)。

- Domain2を再び起動すると、そのバージョンとポリシー・ストアのバージョンが非互換になります。

- シナリオ2

- Domain1と、このドメインが指しているポリシー・ストアのバージョンはどちらもPS2です。

- ポリシー・ストアをPS3ポリシー・ストアにアップグレードしようとすると、失敗します。移行した場合、バージョンの非互換性が発生するためです。
移行は、OPSSバイナリとポリシー・ストアのバージョンが一致している場合にのみ可能です。

- シナリオ3

- PS2のDomain1で、join引数を指定したコマンドreassociateSecurityStoreを使用して、PS3のポリシー・ストア(別のドメインにあるもの)を結合しようとします。

- この操作は失敗します。この共有によってバージョンの非互換性が発生するためです。
再関連付けは、OPSSバイナリとポリシー・ストアのバージョンが一致している場合にのみ可能です。

解決策

これらの3つのシナリオすべてに対処する解決策として、次のいずれかを使用できます。

- ドメインのOPSSバイナリを更新して、そのドメインが指しているポリシー・ストアのバージョンと一致させます。

- ドメインのポリシー・ストアの再関連付けを実行し、そのドメインのOPSSバイナリのバージョンと同じかそれより新しいバージョンのポリシー・ストアに関連付けます。

L.22 ポリシー・ストアのバージョンの非互換性

この項では、OPSSセキュリティ・ストアの移行中にPolicyStoreIncompatibleVersionException例外が発生する理由について説明します。「バイナリとポリシー・ストアのバージョンの非互換性」も参照してください。

前述の例外は、移行元のストアのバージョンが移行先のストアのバージョンよりも高く、バージョンの組合せが無効であることを示しています。移行は、移行元のバージョンが移行先のバージョンよりも高くない場合にのみ実行されます。

回避策は、移行先のストアのバージョンを移行元のストアのバージョンと互換性のあるバージョンにアップグレードすることです。

L.23 追加のヘルプ

My Oracle Support(以前のMetaLink)(http://myoraclesupport.oracle.com)でより多くの解決策を参照できます。問題に対する解決策が見つからない場合は、サービス・リクエストを登録してください。

索引

A B C D E F G H I J K L M N O P R S T U V W X

A

AbstractTypedPermission, 20.3.4

アクセス制御リスト, 8.5.1.1

アクセス・サーバー

キャッシュ, 17.6.1

アクセス・ゲート

configureAccessGateツール, 17.4.2.1, 17.8.6

ACL, 8.5.1.1 add.application.roles, 21.1 add.authenticated.role, 21.1 addBootStrapCredential, 10.5.6 addPrincipalsToAppRole, 20.2.3 管理ツール, 5.1 管理タスク, 5.4 administrators group, 2.5 匿名ロールと認証ロールのプロパティ, F.2.5 匿名ロール, 2.4, 2.4.1, 5.2 匿名ロールと認証, 2.4.1 匿名SSL, 8.5.1 匿名ユーザー, 2.1, 2.4, 2.4.1 匿名ユーザーおよびロール, 21.1 app.context, 8.7.3.3 アプリケーション名またはストライプ, 21.1 アプリケーション・ポリシー, 2.1 アプリケーション・ロール, 2.1, 21.1 アプリケーション・ロールの階層, 9.3.4 アプリケーション・ストライプ, 21.1, 21.1 アプリケーション名, 21.1, 21.1 ApplicationRoleクラス, 2.2.1 アプリケーション固有のポリシーとロール, 3.2 監査データ

バスストップ・ファイル, 13.2.5

ファイル管理, C.6

移行, 13.5.5

レポート, 14.1

監査データ・ストア

バックアップとリカバリ, 13.5.6.2

Javaコンポーネントの構成, 13.2.3.2

システム・コンポーネントの構成, 13.2.4

データ削除, 13.5.6.3

構成解除, 13.2.4.1

パーティション化, 13.5.6.1

スキーマ, 13.5.1

階層アーカイブ, 13.5.6.4

監査フロー, 12.3.1 監査ログ, 13.4 監査ポリシーの移行, 6.5.3 監査ポリシー, 13.3

イベント・フィルタ, 12.3.2

監査レポート

例, 14.4

監査レポート

属性, 14.5.2

コンポーネント別, C.2.2

カスタム, 14.6.2

標準のリスト, 14.5.1

タイプ, 14.2

表示, 14.3

監査スキーマ, C.3 監査サービス, 28 監査対応コンポーネント, C.1.1 監査

イベントの属性, C.1.3

イベント, C.1.2

フィルタ式構文, C.5

Oracle Fusion Middlewareのコンポーネント, 13.3

in Oracle Fusion Middleware, 12

Javaコンポーネント, C.1.1

手動ポリシー管理, 13.3.4

Javaコンポーネントの手動構成, 13.3.4.2

システム・コンポーネントの手動構成, 13.3.4.4

Oracle Directory Integration Platform, C.1.2.1

Oracle HTTP Server, C.1.2.3

Oracle Identity Federation, C.1.2.5

Oracle Internet Directory, C.1.2.4

Oracle Platform Security Services, C.1.2.2

Oracle Virtual Directory, C.1.2.6

Oracle Web Cache, C.1.2.11

Oracle Web Services Manager, C.1.2.12

概要, 12.2

OWSM-Agent, C.1.2.7

OWSM-PM-EJB, C.1.2.8

Fusion Middleware Controlを使用したポリシーの管理, 13.3.1, 13.3.2

WLSTを使用したポリシーの管理, 13.3.3

レコードの格納, 12.3.4

レポート・フィルタ, 14.1.5

Oracle Business Intelligence Publisherのレポート設定, 14.1.3

レポート・テンプレート, 14.1.4

Reportsサーバー, C.1.2.9

システム・コンポーネント, C.1.1

WLSTコマンド, C.4

WSポリシー・アタッチメント, C.1.2.10

認証ロール, 21.1 認証ロール, 2.3, 5.2, 21.1 認証ユーザー, 2.1 認証プロバイダ, 18.1.2.4

デフォルトの認証プロバイダ, 16.2.4.2.4, 16.2.5.1, 16.2.6.1, 17.4.3.3, 17.5.3, 17.6.2, 18.1.2.4

LDAP認証, 16.2.4.2.1, 17.4.3.1

OAM, 15.2, 15.2

OAM認証プロバイダ, 16.2.5.1, 17.5.3

OAM IDアサーション・プロバイダ, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2

OID認証プロバイダ, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2, 18.1.1.2, 18.1.2.4

OSSO IDアサーション・プロバイダ, 18.1.2.4

WebLogic, 15.1

認証プロバイダ・フラグ, 3.1.2.2 OAMの認証プロバイダ, 15.2 認可失敗, 20.3.3 認可失敗, 9.1 自動ログイン, 8.7.3.1 autologin.url, 8.7.3.3

B

バックアップ, 5.2

基本的なセキュリティ・タスク, 5.2

ブートストラップ資格証明, 6.3.1, 23.1.2

一括認可, 23.2

bulkload, 6.5.2.3

C

キャッシュ

アクセス・サーバー, 17.6.1

リフレッシュ頻度, 9.4.1

キャッシュのリフレッシュ, 9.4 キャッシュ, 9.4, 9.4 カスケード削除, 23.2 ポリシーで許可されている文字, L.16.2 セキュリティ・アーティファクトに使用する文字, 9.1 checkBulkAuthorization, 20.3.3.3 checkPermission, 20.3.3, 20.3.3.1, 20.3.3.1, L.1.1.3.1 選択

適切なSSOソリューション, 15

クラスパス, 1.5.3, 3.2, 8, 9.2.1, 9.3.4, 21.4.6, E.2.3 パーミッション・クラス, 21.4.6

CredentialAccessPermission, 21.4.6.2

JpsPermission, 21.4.6.3

PolicyStoreAccessPermission, 21.4.6.1

環境のクローニング, 5.2.1 資格情報を管理するコマンド, 9.3, 10.5 複雑な問合せ, 23.2 コンプライアンス, 12.1.1 構成ファイル, 21.4.9 複数の認証プロバイダの構成, 3.1.2.2 configureAccessGateツール, 17.4.2.1, 17.8.6 構成

グローバル・ログアウト

Oracle Access Manager, 17.1.2

IDアサーション

OAMを使用したシングル・サインオン, 16.2.4, 17.4

Oracle Web Services Manager, 16.2.6, 17.6

OAM認証プロバイダ, 17.5 OAMCfgToolを使用したシングル・サインオンのためのOAM, 17.4.2.1 OAMCfgToolを使用したSSOのためのOAM, 17.4.2 OSSO, 18.1 Oracle Web Services Managerのプロバイダ, 16.2.6.1, 17.6.2 Oracle Fusion Middlewareでのシングル・サインオン, 15, 16, 17, 18 ドメインの構成, 5.4 リソース・パーミッションの構成, 20.3.4 WebLogicドメインの構成, 5.4 CONNECTION_POOL_CLASS, L.6 createAppRole, 9.3.1, 9.3.2 createCred, 10.5.3 createResourceType, 9.3.12 ユーザー・アカウントの作成, 2.6 資格証明移行の設定, 6.2.1 資格証明ストア, 2.1 資格証明ストアのタイプ, 3.3 CredentialAccessPermission, 21.4.6.2 CredentialMappingパーミッション, 8.7.3.3 CSF

LDAPストアを使用するJ2EEの例, 24.7.4

ウォレットを使用するJ2EEの例, 24.7.3

ウォレットを使用するJ2SEの例, 24.7.2

CSIv2 IDアサーション, 3.1.2.3 カスタム認可プロバイダ, 3.2 cwallet.sso, 4.3, 6.2.1, 21, 21.4.3 cwallet.ssoファイル, 21.3

D

DBベースの資格証明ストア, 3.3

DBベースのポリシー・ストア, 8.3

DBベースのセキュリティ・ストア, 4.1

DBMS_STATS, 8.3.2

認可のデバッグ, L.1.2.3

デフォルトの認証プロバイダ, 16.2.4.2.4, 16.2.5.1, 16.2.6.1, 17.4.3.3, 17.5.3, 17.6.2, 18.1.2.4

default.auth.level, 8.7.3.3

deleteAppPolicies, 9.3.11

deleteAppRole, 9.3.3

deleteResourceType, 9.3.14

ロールの削除, 9.3.3

デプロイ済アプリケーション, 5.3

アプリケーションのデプロイ, 6.1

JavaEEアプリケーションのデプロイ, 6.4

テスト環境へのデプロイ, 6.3.1

デプロイ・ツール, 6.2

開発モード, 21.4.4, 21.4.5.3

環境の配布, 8.2.1

DN, 2.7.2

doAs, 20.3.3.2

doAsPrivileged, 20.3.3.2

動的認証, 8.7.3.1

E

EARファイル, 21.3, 21.3.1, 21.3.2

EJBインターセプタ, 21.1

ejb-jar.xml, 3.2, 21.1, 21.3

組込みLDAP, 3.1.2, 4.2

enable.anonymous, 21.1

エンタープライズ・グループ, 2.1

エンタープライズ・グループおよびユーザーのクラス, 21.2

エンタープライズ・ユーザー, 2.1

エンタープライズレベルSSO, 15.1

資格に基づくポリシー, 2.1

イベント・ソース・タイプ, 12.3.2

既存のOSSO, 15.1

exportAuditConfig, C.4.7

EXTRA_JAVA_PROPERTIES, F.1, L.1.2

F

フェイルオーバー・サポート, 5.4

FAQ, 1.1

ファイルベースのポリシー・ストア, 3.2

ファイルベースのセキュリティ・ストア, 4.1

G

一般資格証明, 10.1

LDAPの汎用的なプロパティ, F.2.4

getAuditPolicy, C.4.2

getGrantedResources, 20.3.3.4

getNonJavaEEAuditMBeanName, C.4.1

getPermissions, L.1.1.3.2

getResourceType, 9.3.13, 9.3.15, 9.3.15, 9.3.16, 9.3.16, 9.3.17, 9.3.17, 9.3.17, 9.3.18, 9.3.19, 9.3.19, 9.3.20, 9.3.20, 9.3.21, 9.3.21, 9.3.22, 9.3.22, 9.3.23, 9.3.23, 9.3.24, 9.3.24, 9.3.24, 9.3.25, 9.3.25, 9.3.26, 9.3.26, 9.3.27, 9.3.27, 9.3.28, 9.3.28

グローバル・ログアウト, 8.7.3.1

権限付与

パーミッションベース, 2.2.1

grantAppRole, 9.3.4 GrantManagerクラス, 20.3.2 grantPermission, 9.3.8 グループ, 2.1 GUID, 2.7.2

H

ヘッダー

Oracle HTTP Serverによる送信, 18.1.1.3

ホスト名検証, 3.1.2.2 ホット・デプロイ, 6.5.2

I

OAMを使用したシングル・サインオンのためのIDアサーション・プロバイダ, 15.2

アイデンティティ・ストア, 2.1

プロバイダの作成, 25.3.4

プロバイダ構成プロパティ, 25.3.5

プロバイダの選択, 25.3.3

WebLogic, 3.1.2

WebSphere, 3.1.3

JavaSEのアイデンティティ・ストア, 22.2.2 アイデンティティ・ストア・サービス, 7.1 アイデンティティ・ストア・タイプ, 3.1.1 ID仮想化, 7.1.1 idstore.type, F.2.3 importAuditConfig, C.4.8 バージョンの非互換性, L.21, L.22 LDAP認証プロバイダの初期化, 3.1.2.2 MBeansの起動, E.2.2 isCallerInRole, 1.5.1 isUserInRole, 1.5.1, 20.2.2.2

J

JAASモード, 21.1

Javaコンポーネント, 2.1

javadocs

OPSS API, H.1

OPSS MBeans API, H.1

OPSSユーザーおよびロールAPI, H.1

JavaSEアプリケーション, 23.1 java.security.policy, F.1 jazn-data.xml, 4.3, 6.2.1, 21, 21.3, 21.3.1 結合, 9.3.29 JpsApplicationLifecycleListener, 21.4.4 jpsApplicationLifecycleListener, 21.4.1 jps.apppolicy.idstoreartifact.migration, 21.4.1, 21.4.1 jps.auth.debug, L.1.2.1 jps.auth.debug.verbose, L.1.2.2 jps-config-jse.xml, 1.5.3 jps-config.xml, 21, A jps-config.xmlの例, 21.4.9 jps-config.xmlの全体の例, 21.4.9 jps.credstore.migration, 21.4.4 jps.deployment.handler.disabled, 8.6, 21.4 JpsFilter, 21.1, 21.3, L.1.1.5 JpsInterceptor, 21.1, 21.1.1, 21.3, L.1.1.5 JpsPermission, 21.4.6.3 jps.policystore.applicationid, 21.4.1 jps.policystore.hybrid.mode, F.1, F.1 jps.policystore.migration, 21.4.1 jps.policystore.migration.validate.principal, 21.4.1 jps.policystore.removal, 21.4.1

K

キーと証明書

管理, 11

キーストア・サービス, 11, 27

コマンド, 11.2

L

大量のストア, 6.5.2.3

LDAP資格証明ストアのプロパティ, F.2.2

LDAPアイデンティティ・ストアのプロパティ, F.2.3

LDAPポリシー・ストアのプロパティ, F.2.1

LDAPサーバー, 4.1

ldapadd, 8.2.2

LDAPベースのポリシー・ストア, 3.2, 8.2

ldapmodify, 8.5.1.1

ldapsearch, 8.2.2

LDIFファイル, 8.2.2

ldifwrite, 6.5.2.3

listAppRoleMembers, 9.3.7

listAppRoles, 9.3.6

listAuditEvents, C.4.6

listPermissions, 9.3.10

ログ出力

oracle.security.jps.trace.logger, L.1.1.3.2

oracle.security.jps.util.JpsAuth, L.1.1.3.1

論理ロール, 2.1, E.3 login.url.FORM, 8.7.3.3 logout.url, 8.7.3.3

M

管理ツール, 4.2

管理

キーと証明書, 4.2

ポリシーと資格証明, 4.2

資格証明の管理, 6.3.1, 6.3.1.1 ドメイン認証プロバイダの管理, 5.4 アイデンティティの管理, 4.2, 6.3.1 ポリシーの管理, 6.3.1 ポリシーおよび資格証明の管理, 4.2 システム・ポリシーの管理, 6.3.1.1 ユーザーおよびグループの管理, 4.2 手動構成

WebゲートWebサーバー, 16.2.3

エンタープライズ・グループへのアプリケーション・ロールのマッピング, 6.3.1.1 アプリケーション・ロールのマッピング, 2.2 ロールのマッピング, 6.5.2 マッチャ・クラス, 20.3.4 リソース・タイプのマッチャ・クラス, 20.3.4 MBean

管理ポリシー・ストア, E.2.1

注釈, E.3.1

アプリケーション・ポリシー・ストア, E.2.1

サンプル・コード, E.2.3

資格証明ストア, E.2.1

グローバル・ポリシー・ストア, E.2.1

Jps構成, E.2.1

migrateSecurityStore, 6.5.1.1, 6.5.2, 8.6.2, 21.4.8, I.3

DBからDB, 6.5.2.1, 6.5.2.2

LDAPからLDAP, 6.5.2.1, 6.5.2.2

XMLからLDAP, 6.5.2.1, 6.5.2.2

資格証明の移行の例, 6.5.2.2 アイデンティティの移行, 21.4.8 アイデンティティの手動による移行, 6.5.1.1 大量のストアの移行, 6.5.2.3 その他のプロバイダの移行, 6.5.1 デプロイ時のポリシーおよび資格証明の移行, 6.5.2 ポリシーの移行の例, 6.5.2.1 資格証明の移行, 3.3 ポリシーの移行, 3.2 mod_osso, 18.1.2, 18.3.1 modifyBootStrapCredential, 10.5.5 リソース・タイプの変更, 9.3.14 監視, 12.1.1 複数ノード・サーバー・ドメイン, 8.2.1

N

名前の比較ロジック, 2.7.2

O

OAM

認証プロバイダ, 15.2, 15.2

パラメータ, 17.2

トラブルシューティング, 17.8

認証プロバイダ, 15.2, 16.2.5.1, 17.5.3 IDアサーション・プロバイダ, 15.2, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2 OAM 10g SSOソリューション, 17 OAM 11g SSOソリューション, 16 OAMソリューション, 8.7.3.1 oamauthenticationprovider.war, 16.2.1, 17.1.1.2 oamAuthnProvider.jar, 15.2.5, 16.2.1, 16.2.1, 17.1.1.2, 17.1.1.2 OAMCfgTool, 17.1.1.1, 17.1.1.2, 17.4, 17.4.2

使用方法, 17.3

Createモードのパラメータ, 17.3.2.1

作成されたホスト識別子, 17.3.3

既知の問題, 17.3.4

プロセスの概要, 17.3.1

Validateモードのパラメータ, 17.3.2.2

oamcfgtool.jar, 15.2.5, 17.1.1.2 OID認証プロバイダ, 16.2.4.2.4, 16.2.6.1, 17.4.3.3, 17.6.2, 18.1.1.2, 18.1.2.4 OIDパッチ, 8.2 一方向SSL, 8.5.1 OPSS API

ユーザーおよびロール, D

OPSSセキュリティ・ストア, 2.1 OPSS SSOフレームワーク, 8.7.3.1 OPSSシステム・プロパティ, F.1 opss_purge_changelog, 8.3.2 Oracle Access Manager

OSSOとの統合, 15.1, 15.1

Oracle ADFセキュリティ, 5.1 Oracle Business Intelligence Publisher, 14.1

監査レポートの例, 14.4

Oracle Entitlements Server, 5.2, 5.5, 9, 9.1, 9.7 Oracle Fusion Middlewareの監査フレームワーク, 12.1, 12.1.3

アーキテクチャ, 12.3.1

概念, 12.3, 12.3.2

Oracle Information Lifecycle Management Assistant, 13.5.6.4 Oracle Internet Directory, 4.1 Oracle Internet Directory 10.1.4.3パッチ, 4.1 Oracle Internet Directoryのチューニング, 4.1 Oracle JDeveloper 11g, 5.1 Oracle Platform Security Services, 15.1 OracleAS Single Sign-Onソリューション、「OSSO」も参照, 18.1 oracle.deployed.app.dir, B.2 oracle.deployed.app.ext, B.2 oracle.security.jps.config, 1.5.3, A oracle.security.jps.jaas.mode, 21.1 oracle.security.jps.log.for.approle.substring, L.1.2.3 oracle.security.jps.log.for.enterprise.principalname, L.1.2.3 oracle.security.jps.log.for.permclassname, L.1.2.3 oracle.security.jps.log.for.permeffect, L.1.2.3 oracle.security.jps.log.for.permtarget.substring, L.1.2.3 Oracle固有のアプリケーション, 5.1 OSSO

既存の実装, 15.1

IDアサーション・プロバイダ, 18.1.1, 18.1.2.4, 18.1.2.4

新規ユーザー, 18.1.2

処理, 18.1.1.2

ヒントおよびトラブルシューティング, 18.3

ソリューション, 15.1, 15.1, 18 OSSO IDアサーション・プロバイダ, 18.1.1.1

P

J2EEアプリケーションのパッケージ化, 21.3

資格証明のパッケージ化, 21.3.2

ポリシーのパッケージ化, 21.3.1

パスワード資格証明, 10.1

パスワード検証, 2.6

パスワード, 2.6

パーミッション, 20.3.4

パーミッション・クラス, 20.3.4

パーミッション・クラス, 3.2, 8, 21.4.6

パーミッションの継承, 2.2.1

匿名ロールに対するパーミッション, 2.4

認証ロールに対するパーミッション, 2.3

PermissionSetManagerクラス, 20.3.2

ポリシー・ドメイン

URL接頭辞, 17.5.2.1, 17.5.2.2, 17.6.1

ポリシー移行の設定, 6.2.1 ポリシー・ストア, 3.2 ポリシー・ストア, 2.1 ポリシー・ストア・キャッシュ, 9.4 ポリシー・ストアの削除, 3.2 PolicyStoreAccessPermission, 21.4.6.1 PolicyStoreIncompatibleVersionException, L.21, L.22 policystore.refresh.interval, 9.4 インストール後のタスク, 5.3 プリンシパル, 2.1 プリンシパル名の比較, 2.7.1, 2.7.2 principal.cache.key, 23.1.1 PrincipalEqualsCaseInsensitive, 2.7.2 PrincipalEqualsCompareDnAndGuid, 2.7.2 手順

Webゲート

Webサーバーを手動で構成する手順, 16.2.3.2

プロセスの概要

OAMCfgTool, 17.3.1

Webおよび非Webリソース用のOracle Access Manager認証プロバイダ, 15.2.2

OSSO IDアサーション・プロバイダ, 18.1.1.2

本番環境, 5.2.1 props.auth.level, 8.7.3.3 props.auth.uri, 8.7.3.3 props.auth.url, 8.7.3.3

R

RCU, 8.3.1

reassociateSecurityStore, 9.3.29, I.3

資格証明の再関連付け, 3.3

ポリシーの再関連付け, 3.2

サーバー・ファイルのリカバリ, 5.2

参照整合性, 3.1.1

参照整合性, 8.2

remove.anonymous.role, 21.1

リソース・カタログ, 20.3.1

リソース・パーミッション, 20.3.4

管理, 20.3.4

リソース・タイプ, 20.3.4 リソースに基づくポリシー, 2.1 ResourceManagerクラス, 20.3.2 ResourcePermissionクラス, 20.3.4 resourcetypeenforcementmode, F.2.1.1, F.2.1.2 ResourceTypeManagerクラス, 20.3.2 revokeAppRole, 9.3.5 revokePermission, 9.3.9 ロール・カテゴリ, 2.8 ロール階層, 2.2.1 RoleCategoryManagerクラス, 2.8

S

SAML 1.1 IDアサーション, 3.1.2

SAML 2.0 IDアサーション, 3.1.2

シナリオ, 4.4, 4.4

セキュリティ・プロバイダ構成, 8.5.1, 8.7

WebLogic SSPIのセキュリティ・プロバイダ, 15.2.3.3

セキュリティ・ストア, 2.1

セキュリティ関連のコマンド, 5.6

サーバーの再起動, 4.2, F

サービス・インスタンス更新スクリプト E.1

サービス・プロバイダ, 25.3

概要, 25.3

理解, 25.3.1

セキュリティ・プロバイダの設定, 8.5.1 setAuditPolicy, C.4.3 setAuditRepository, C.4.5 setDomainEnvシェル・スクリプト, F.1, L.1.2 setPolicy, 20.3.3, 20.3.3.3 LDAPサーバーのノードの設定, 8.2.2 プロバイダの設定

Oracle Web Services Manager用のOAMアサーション・プロバイダ, 16.2.6.1

OAM認証プロバイダ, 16.2.5.1

OAM IDアサーション, 16.2.4.2.4, 17.4.3.3

OSSO IDアサーション・プロバイダ, 18.1.2.4

シングル・サインオン, 8.7.3 Fusion Middlewareでのシングル・サインオン・ソリューション、「SSO」も参照, 15 分割プロファイル, 7.3.3 SPNEGO, 3.1.2.3 SPNEGO tokens, 3.1.2.3 SSL

ユーザーおよびロールAPI, 25.8

匿名, 8.5.1

一方向, 8.5.1

DBへのSSL, 8.3.3 SSO

エンタープライズ・レベル, 15.1

既存の10g SSO, 15.1

Oracle Access Manager, 15.2

同期フィルタ, 16.4, 17.7, 18.2

SSOログアウトURL, 16.3.1 SSOサービス, 8.7.3.1 SSOサービスの構成, 8.7.3.3 sso.provider.class, 8.7.3.3 ポリシーおよび資格証明の格納, 4.1 サブジェクト, 2.1, 2.4.1, 2.7.1 サポート対象

アイデンティティ・ストア・タイプ, 3.1.1

同期

ユーザーおよびSSOセッション, 16.4, 17.7, 18.2

システム・コンポーネント, 2.1 system-jazn-data.xml, 21

T

タスクの概要

OAM認証プロバイダの構成, 16.2.5, 17.5

シングル・サインオンに対するOAM IDアサーションのデプロイと構成の内容, 16.2.4, 17.4

OSSO IDアサーション・プロバイダのデプロイ, 18.1.2

Oracle Web Services Manager用のIDアサーション・プロバイダのデプロイ, 16.2.6, 17.6

OAM認証プロバイダに必要なコンポーネントのインストール, 16.2.1, 17.1.1.2

テスト環境, 6.3 token.provider.class, 8.7.3.3 トラブルシューティング

Microsoft Active Directoryに対する検索の失敗, L.20

一般的なセキュリティ・プラクティス, 5.3

U

PS2でサポートされていないメソッド, 23.2

updateServiceInstanceProperty, E.1

スクリプトを使用したインスタンスの更新, E.1

upgradeSecurityStore, G

URL

SSOログアウトURL, 16.3.1

ユーザーおよびロールAPI, D

Javadoc, 25.9

プログラミングのヒント, 25.3.9.1

ユーザーおよびロールAPI

WebLogic認証プロバイダ, 25.1.1

環境設定, 25.3.2

概要, 25.1

プログラミングのヒント, 25.3.9

サマリー, 25.2

ユーザーおよびロールSPI

Javadoc, 25.10.7.4

UseRetrievedUserNameAsPrincipal, 3.1.2.2 user.login.attr, L.7 username.attr, L.7

V

仮想化, 7.3.1.1, 7.3.2, 7.3.2.3, F.2.3

仮想化されたID, 7.1.1

W

WARファイル, 21.1

WebLogic

認証プロバイダ, 15.1, 16.2.4.2.1, 17.4.3.1

認証プロバイダ

IDアサーション, 16.2.4.2.1, 17.4.3.1

J2EEアプリケーション, 15.2.3.3 WebLogic管理コンソール, 4.2 WebLogic Scripting Tool (WLST), 16.2.4.2.2, 17.4.3.2 weblogic-application.xml, 21 web.xml, 3.2, 21, 21.1, 21.3 WLSGroupImpl, 2.2.1, 9.3.4, 9.3.5, 21.2, 22.3 WLST

createAppRole, 9.3.1, 9.3.2

createCred, 10.5.3

createResourceType, 9.3.12

deleteAppPolicies, 9.3.11

deleteAppRole, 9.3.3

deleteCred, 10.5.4

deleteResourceType, 9.3.14

getResourceType, 9.3.13, 9.3.15, 9.3.15, 9.3.16, 9.3.16, 9.3.17, 9.3.17, 9.3.17, 9.3.18, 9.3.19, 9.3.19, 9.3.20, 9.3.20, 9.3.21, 9.3.21, 9.3.22, 9.3.22, 9.3.23, 9.3.23, 9.3.24, 9.3.24, 9.3.24, 9.3.25, 9.3.25, 9.3.26, 9.3.26, 9.3.27, 9.3.27, 9.3.28, 9.3.28

grantAppRole, 9.3.4

grantPermission, 9.3.8

listAppRoleMembers, 9.3.7

listAppRoles, 9.3.6

listCred, 10.5.1

listPermissions, 9.3.10

reassociateSecurityStore, 9.3.29

revokeAppRole, 9.3.5

revokePermission, 9.3.9

updateCred, 10.5.2

WLSUserImpl, 2.2.1, 21.2, 22.3

X

X509 IDアサーション, 3.1.2

Copyright © 2003, 2012, Oracle and/or its affiliates. All rights reserved.