| Oracle® Fusion Middleware Oracle Entitlements Server管理者ガイド 11gリリース2 (11.1.2.2) B71695-05 |
|
 前 |
 次 |
この章では、セキュリティ・モジュールとキャッシュの構成、監査および様々なタイプのポリシー・ストアからのポリシーの移行など、様々な管理タスクと構成タスクについて説明します。この章には次の項目があります。
テスト環境から本番環境への移行(T2P)は、Oracle Entitlements Server管理コンソールをテスト環境から本番環境に移行するプロセスです。セキュリティ・モジュールは固有のデータを保持していないので、T2Pプロセスはコンソール・コンポーネント(WebLogic Serverドメインで実行されているアプリケーション)にのみ適用可能です。次の手順は、T2Pプロセスを示します。
『Oracle Fusion Middleware管理者ガイド』の説明に従って、データベース、Middlewareホームおよびドメイン構成を新しい本番環境に移動します。
新しい本番環境にOracle Entitlements Serverをインストールします。
『Oracle Fusion Middleware管理者ガイド』の説明に従って、Oracle Platform Security Servicesを新しい本番環境に移動します。
Oracle Entitlements Serverでは、管理コンソールからポリシーをシミュレートする機能が提供されます。ポリシー・シミュレーションを使用すると、ポリシー変更の影響についてのトラブルシューティング、テスト、分析を行ったり、特定のアプリケーションにポリシーが実行される様子を理解したりできます。次の各項では、詳細を説明します。
最も単純なポリシー・シミュレーション・ケースでは、ユーザーおよびリソースとアクションのペアが指定され、パラメータに基づいて次の情報が取得されます。
プリンシパルに付与される外部ロールおよび静的なロール付与とロール・マッピング・ポリシーのリスト。
関連するロールまたは認可ポリシーを評価するために必要な属性のリスト。
関連するロールまたは認可ポリシーの一部として実行される評価関数の値。
関連するロール、認可ポリシーまたは責任の一部である動的属性の値。動的属性値が不明な場合、ユーザーが明示的に設定できるように空白が返される必要があります。
返される最終的な認可決定(付与または拒否)、責任および関連する認可ポリシー
認可決定の一部として属性値が評価される場合、値を変更しながら様々なシミュレーションを実行できます。イベントは次の順序で実行されます。
プリンシパル、リソースおよびアクションを指定します。
プリンシパルには、ユーザー、外部ロールのセットまたはアプリケーション・ロールのセットを指定できます。外部ロールとアプリケーション・ロールがユーザーとともに明示的に指定されている場合、ロールの解決は実行されません。
ポリシーをシミュレートします。
オーバーライドする属性を指定し、オーバーライドする属性の値を指定します。
ポリシー・シミュレータを再実行して、結果の変化を確認します。
ポリシー・シミュレータには、簡易モードと拡張モードの2つのモードがあります。モードごとに異なる目的があります。簡易モードは通常デバッグ目的で使用され、特定のサブジェクトとリソースの組合せに対する認可結果を決定します。これにより、セキュリティ管理者は、特定のユーザーが指定されたリソースに対するアクセス権を持つ(または持たない)理由を理解できます。拡張モードは、ユーザーが外部ロールとアプリケーション・ロールの特定のセットのメンバーになっているかどうかなど、発生している状況を確認するためにポリシー・シミュレーションで使用されます。シミュレーションに基づき、セキュリティ管理者は、指定されたリソースの実行時の認可決定に応じたユーザーのロール・メンバーシップを追加または取消できます。簡易モードで値を定義して、「アクセスの確認」をクリックすると、次のようになります。
認可決定、責任(存在する場合)、および関連するロールまたはポリシーの評価に必要な属性のリストなど、ポリシー評価の結果が表示されます。属性値を取得できない場合、空白が返されます。
指定されたユーザーが属する外部ロールのセットが表示されます。このリストを使用すると、ポリシー・シミュレータを拡張モードで実行する場合のユーザーの外部ロールを簡単に選択できます。
指定されたユーザーが付与(または拒否)されたアプリケーション・ロールおよびユーザーが指定されているロール・マッピング・ポリシーが表示されます。これらのロールには、ロール・マッピング・ポリシーによって直接的または間接的に(継承を通じて)付与された静的ロールと動的ロールが含まれる可能性があります。
アクセス権の評価に使用された認可ポリシーが表示されます。
拡張モードでの値の定義には、プリンシパルとして、0ユーザーまたは1ユーザー、外部ロールのセット、アプリケーション・ロールのセットまたはこれら3つの任意の組合せを指定する作業が含まれます。表示される結果は、外部ロールとアプリケーション・ロールが指定された場合を除けば、簡易モードの場合と同じであり、このときグループの解決は実行されません。
ポリシー・シミュレータは、管理コンソールで構成済アプリケーションを開いたときに、タブとして表示されます。このタブは、アプリケーション・オブジェクトが作成された後、そのアプリケーションの変更権限を持つ管理者にのみ表示されます。次の各項では、ポリシー・シミュレータを実行する方法について説明します。
図13-1は、ポリシー・シミュレータの簡易モードのスクリーンショットです。この項の手順を使用して、ポリシー・シミュレータを簡易モードで実行します。
ポリシーが含まれるアプリケーション名を選択し、「開く」をクリックします。
「シミュレーション」タブをクリックします。
「簡易」ラジオ・ボタンを選択します。
プリンシパルとして1ユーザーを定義する場合は、「簡易」実行が使用されます。
プリンシパルを1つ検索し、選択します。
「ユーザー名」ボックスに検索条件を入力し、検索矢印をクリックします。
ユーザー検索結果が表示されます。
ユーザー検索の該当する行を選択して「追加」をクリックし、そのユーザーをプリンシパルとして選択します。
リソースを1つ検索し、選択します。
ドロップダウン・メニューから(リソースがそのインスタンスである)リソース・タイプを選択します。
ドロップダウン・メニューから適切なアクション名を選択します。
リソース・インスタンス名の検索条件を入力し、検索矢印をクリックします。
リソースが表示されます。オプションで、ポリシー・ドメインを選択して検索条件を入力し、検索矢印をクリックすることによって検索結果を絞り込むことができます。
ポリシー・シミュレーション・テストに属性を追加します。
属性は条件で使用されます。ポリシーを評価するには、属性の値が必要です。属性にデフォルト値が存在する場合、それが使用されます。(デフォルト値はここでオーバーライドすることもできます。)デフォルト値が存在しない場合、シミュレータにより入力を要求されます。
緑のプラスをクリックし、属性を追加します。
検索ポップアップを使用して定義済属性を選択し、そのデータ型に応じた値を指定します。
「名前」に入力します。
「新しい値」に入力します。
「アクセスの確認」をクリックします。
ポリシー・シミュレータが実行されます。結果の詳細は、13.2.2項「ポリシー・シミュレーション・モードの選択」を参照してください。
図13-2は、ポリシー・シミュレータの拡張モードのスクリーンショットです。拡張モードでは、アプリケーション・ロールまたは外部ロールとともに1ユーザーのみ定義できます。この項の手順を使用して、ポリシー・シミュレータを拡張モードで実行します。
ポリシーが含まれるアプリケーション名を選択し、「開く」をクリックします。
「シミュレーション」タブをクリックします。
「拡張」ラジオ・ボタンを選択します。
プリンシパルとして、ユーザー名、外部ロールまたはアプリケーション・ロールを検索し、選択します。
ユーザー名、外部ロールまたはアプリケーション・ロールの少なくとも1つを定義する必要があります。
「ユーザー名」ボックスに検索条件を入力し、検索矢印をクリックします。
ユーザー検索結果が表示されます。
ユーザー検索の該当する行を選択して「追加」をクリックし、そのユーザーをプリンシパルとして選択します。
緑のプラスをクリックし、外部ロールを追加します。
「外部ロールの検索」ダイアログが表示されます。
検索条件を入力し、「検索」をクリックします。
「検索結果」が表示されます。
「検索結果」の該当する行を選択して「選択項目の追加」をクリックするか、または「すべて追加」をクリックしてすべての結果を追加します。
ロールが追加されます。拡張モードでは、ポリシー・シミュレータでユーザーの外部ロールは計算されません。その計算が必要な場合は、具体的にそれらを追加する必要があります。
緑のプラスをクリックし、アプリケーション・ロールを追加します。
「アプリケーション・ロールの検索」ダイアログが表示されます。
検索条件を入力し、「検索」をクリックします。
「検索結果」が表示されます。
「検索結果」の該当する行を選択して「選択項目の追加」をクリックするか、または「すべて追加」をクリックしてすべての結果を追加します。
ロールが追加されます。拡張モードでは、ポリシー・シミュレータでユーザーのアプリケーション・ロールは計算されません。その計算が必要な場合は、具体的にそれらを追加する必要があります。
リソースを1つ検索し、選択します。
ドロップダウン・メニューから(リソースがそのインスタンスである)リソース・タイプを選択します。
ドロップダウン・メニューから適切なアクション名を選択します。
リソース・インスタンス名の検索条件を入力し、検索矢印をクリックします。
結果が表示されます。オプションで、ポリシー・ドメインを選択して検索条件を入力し、検索矢印をクリックすることによって、「リソース・ファインダ」で検索結果を絞り込むことができます。
ポリシー・シミュレーション・テストに属性を追加します。
属性は条件で使用されます。ポリシーを評価するには、属性の値が必要です。属性にデフォルト値が存在する場合、それが使用されます。(デフォルト値はここでオーバーライドすることもできます。)デフォルト値が存在しない場合、シミュレータにより入力を要求されます。
緑のプラスをクリックし、属性を追加します。
検索ポップアップを使用して定義済属性を選択し、そのデータ型に応じた値を指定します。
「名前」に入力します。
「新しい値」に入力します。
「アクセスの確認」をクリックします。
ポリシー・シミュレータが実行されます。結果の詳細は、13.2.2項「ポリシー・シミュレーション・モードの選択」を参照してください。
米国連邦情報処理標準(FIPS)は、暗号化モジュールのセキュリティ要件を標準化するためにアメリカ合衆国政府によって開発されています。FIPSのサポートにより、Oracle Entitlements Serverと様々なJava Cryptography Extension (JCE)セキュリティ・プロバイダの統合が実現します。
|
注意: 以前のリリースでは、セキュリティ・サービスは、コンテナのデフォルトのセキュリティ・プロバイダに制限されていました。 |
JCEプロバイダは、構成する前に、インストールして登録する必要があります。これを行う方法の詳細は、Java暗号化拡張機能API仕様およびリファレンスを参照してください。
|
注意: Java暗号化拡張機能(JCE)のドキュメントは、次のURLに移動して、Oracle Technology Network (OTN)のWebサイトからダウンロードできます。 |
jps-config.xmlの次のパラメータは、JCEセキュリティ・プロバイダの構成に使用されます。これらのJCEプロバイダ・パラメータを変更する前に、ポリシー・キャッシュ・ファイルをバックアップします。
oracle.security.jps.runtime.pd.client.localpolicy.JCEProviderNameは、使用されるJCEプロバイダを示します。これはオプションであり、指定しなければデフォルトのJDKプロバイダが使用されます。デフォルト値は未定義であり、使用される値は大/小文字が区別されます。
oracle.security.jps.runtime.pd.client.localpolicy.CipherKeyLengthは、指定されたJCEプロバイダのCipherクラスで使用される鍵の長さを示します。これはオプションであり、デフォルト値は128です。3つの鍵の長さ(128、192および256)のみサポートされています。
oracle.security.jps.runtime.pd.client.localpolicy.CipherModePaddingは、指定されたJCEプロバイダのCipherクラスで使用される暗号アルゴリズム名、モードおよびパディングのスキーマを示します。アルゴリズム名/モード/パディングという形式で設定する必要があります。これはオプションであり、大/小文字は区別されません。デフォルト値はAES/CBC/PKCS5Paddingです。
Oracle Entitlements Serverは、すべての管理アクティビティおよび認可リクエスト、オプションでファイルへの情報の記録を監査します。監査フレームワークは、Oracle Platform Security Services用に開発されたフレームワークを基にしています。Oracle Platform Security Servicesの監査フレームワークの概要は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。次の情報は、Oracle Entitlements Serverの監査機能に固有です。
|
注意: Oracle Entitlements Serverは、Oracle Entitlements Server自体、Oracle Platform Security Services、またはその組合せによって構成されたポリシーの結果として生じる決定を監査します。 |
表13-1では、Oracle Entitlements Serverが監査するイベント(機能カテゴリごとに編成)をリストします。
表13-1 Oracle Entitlements Serverで監査されるイベント
| 機能カテゴリ | 機能タスク |
|---|---|
|
管理ロール管理 |
|
|
アプリケーション管理 |
|
|
権限付与管理 |
|
|
権限設定管理 |
|
|
ポリシー・ドメイン管理 |
|
|
ポリシー管理 |
|
|
リソース管理 |
|
|
ロール管理 |
|
|
ロール・ポリシー管理 |
|
|
認可 |
|
|
構成バインディング管理 |
|
|
構成管理 |
|
|
ポリシー配布管理 |
|
JPS.IAU_ACCESSRESULT列およびIAU_BASE.IAU_FAILURECODE列のOES監査データベースの説明
JPS.IAU_ACCESSRESULTの値は、次のようになります。
(DecisionTime:xxx) (IsAllowed:[true|false])
または
(DecisionTime:xxx) (IsAllowed: [true|false]) (ResponseAttributes([(Name:xxx) (value:xxx)] [responseAttribute2] [responseAttribute3]))
IAU_BASE.IAU_FAILURECODEの値は、success、エラー・メッセージ・キーJPS-XXXXX(例外メッセージ)です。
デフォルトでは、監査ロギングは無効になっています。監査は、Java EEコンテナが使用する構成ファイルであるjps-config.xmlで構成されます。このファイルは、$DOMAIN_HOME/config/fmwconfigディレクトリにあります。例13-1は、jps-config.xmlでの監査の構成例を示します。
例13-1 jps-config.xmlでの監査サービスの構成パラメータ
<!-- Audit Service Instance-->
<serviceInstance name="audit" provider="audit.provider"
location="./audit-store.xml">
<description>Audit Service</description>
<property name="audit.filterPreset" value="None"/>
<property name="audit.maxDirSize" value="0"/>
<property name="audit.maxFileSize" value="104857600"/>
<property name="audit.loader.jndi" value="jdbc/AuditDB"/>
<property name="audit.loader.interval" value="15"/>
<property name="audit.loader.repositoryType" value="File"/>
<property name="auditstore.type" value="file"/>
</serviceInstance>
jps-config.xmlファイルを変更した後は、Oracle Entitlements Server管理サーバーを再起動します。表13-2では、構成パラメータの詳細を説明します。
表13-2 jps-config.xmlでの監査パラメータ
| パラメータ | 説明 |
|---|---|
|
audit.filterPreset |
監査を有効化するには、None、Low、Medium、AllまたはCustomのいずれかの値を選択します。 |
|
audit.maxDirSize |
監査ファイルが書き込まれるディレクトリのサイズを制御します。整数値をバイト単位で指定します。 |
|
audit.maxFileSize |
監査イベントが書き込まれるバス・ストップ・ファイルのサイズを制御します。整数値をバイト単位で指定します。 |
|
audit.loader.jndi |
データベースが使用中の場合、監査イベントがアップロードされるJNDIデータ・ソースへのパスを指定します。 |
|
audit.loader.interval |
データベースが使用中の場合、監査ローダーのアップロードの頻度を制御します。整数値を秒単位で指定します。 |
|
audit.loader.RepositoryType |
監査リポジトリ・タイプを定義します。FileまたはDbのいずれかの値を指定します。
|
|
auditstore.type |
監査ストア・タイプに応じて、値として |
Oracle Entitlements Serverセキュリティ・モジュールの監査を構成するには、まずOracle Entitlements Serverバンドル・パッチ1 (BP1)を適用し、次に監査データベースを作成します。
|
注意: Oracle Entitlements Server監査スキーマ定義の詳細は、Oracle Fusion Middlewareリリース・ノート for Microsoft Windows x64 (64-Bit)を参照してください。この手順は、監査データベースを作成する前または作成した後に実行できます。 |
これらの手順が完了したら、デプロイされているセキュリティ・モジュールに応じて、次のどちらかの手順を使用します。
監査データベースへのデータソースを作成および構成し、WebLogic Serverコンソールを使用してそのデータソースをサーバーにデプロイします。
詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
サーバーを再起動します。
jps-config.xmlファイルの最後の</serviceInstances>タグの前に次の内容を追加します。
非JRFドメインでは、jps-config.xmlはWLSSM_Client_Domain\config\oeswlssmconfig\AdminServer\ディレクトリにあります。JRFドメインでは、jps-config.xmlはWLSSM_Client_Domain\config\fmwconfig\ディレクトリにあります。
<serviceInstance name="audit" provider="audit.provider"> <property name="audit.filterPreset" value="All"/> <property name="audit.maxDirSize" value ="0"/> <property name="audit.maxFileSize" value ="104857600"/> <property name="audit.loader.jndi" value="auditdb"/> <property name="audit.loader.interval" value="15" /> <property name="audit.loader.repositoryType" value="Db" /> </serviceInstance>
サーバーを再起動します。
audit.logがWLSSM_Client_Domain/servers/AdminServer/logs/auditlogs/JPS/ディレクトリに作成されます。
データベースのset passwordコマンドを実行して、監査データベースのパスワードを設定します。
入力を要求されたら、監査スキーマのパスワードを入力します。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
監査ローダーを実行して、audit.logファイルからイベントとアクションを監査データベースにロードします。
アクションに成功すると、転送するイベントの数を確認するメッセージが表示されます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
監査データベース・ローダーを設定するには、jps-config.xmlファイル(OES_Client11115\oes_sm_instances\SM_Name\config\ディレクトリにあります)の最後の</serviceInstances>タグの前に次の内容を追加します。
<serviceInstance name="audit" provider="audit.provider"
location="./audit-store.xml">
<description>Audit Service</description>
<property name="audit.loader.jndi" value="jdbc/AuditDB"/>
<property name="audit.loader.interval" value="15"/>
<property name="audit.loader.repositoryType" value="Db"/>
これらの意味は、次のとおりです。
audit.loader.repositoryTypeの値はDbである必要があります。
リポジトリ作成ユーティリティ(RCU)を使用して、監査ローダーのデータベース・スキーマを作成する必要があります。
データベースに接続するデータソースをaudit.loader.jndiの値として構成する必要があります。
データベースのset passwordコマンドを実行して、監査データベースのパスワードを設定します。
入力を要求されたら、監査スキーマのパスワードを入力します。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
監査ローダーを実行して、audit.logファイルからイベントとアクションを監査データベースにロードします。
アクションに成功すると、転送するイベントの数を確認するメッセージが表示されます。-Doracle.instanceパラメータに、必ずセキュリティ・モジュール・インスタンスとデータベースの詳細を定義してください。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
次のリストは、監査フレームワークに関する情報が記載されている他のドキュメントを示します。
入門資料は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
失敗コードなどの共通の監査属性の詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド, 11gリリース1 (11.1.1)の「Oracle Fusion Middleware監査フレームワーク参照」の章のイベント属性の説明に関する項を参照してください。
認可属性およびポリシー管理属性の詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド11gリリース1 (11.1.1)の「Oracle Fusion Middleware監査フレームワーク参照」の章のOracle Platform Security Servicesのイベントおよび属性に関する項を参照してください。
監査スキーマの詳細は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド11gリリース1 (11.1.1)の「Oracle Fusion Middleware監査フレームワーク参照」の章の監査スキーマに関する項を参照してください。
Enterprise Managerユーザー・インタフェースまたはWebLogic Scripting Tool (WLST)コマンド行インタフェースを使用して、監査ポリシーを管理できます。詳細は、『Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイド』を参照してください。
「Oracle Fusion Middleware監査フレームワーク参照」の章は、Oracle Fusion Middlewareアプリケーション・セキュリティ・ガイドにあります。
その他の構成情報は、『Oracle Fusion Middlewareセキュリティ・ガイド』を参照してください。
この項では、あるタイプのストアから別のタイプのストアへのポリシーの移行について説明します。次の手順について説明します。
次に、XMLベースのポリシー・ストアからLDAPベースのディレクトリにポリシーを移行する手順を示します。
次のサブ手順で説明するように、jps-config.xmlを変更します。
例13-2に示すように、ソースおよび宛先のポリシー・ストアの両方にserviceInstanceを作成します。
ソース・ポリシー・ストア・インスタンスの場所は、migrateSecurityStoreコマンドを使用する際にconfigFileの値として定義するjps-config.xmlの場所からの相対で定義する必要があります。例13-2では、jps-config.xmlとjazn-data.xml(ソース・ポリシー・ストア)が同じディレクトリにあると仮定しています。
例13-2 ソースおよび宛先のポリシー・ストアのためのXMLからLDAPへのserviceInstance
<!-- Source XML-based policy store instance -->
<serviceInstance name="src.xml" provider="policystore.xml.provider"
location="./jazn-data.xml">
<description>File Based Policy Store Service Instance</description>
</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. 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>
例13-3に示すように、宛先LDAPディレクトリへのアクセスに使用されるブートストラップ資格証明に対応するserviceInstanceを作成します。
例13-3 ブートストラップ資格証明のためのXMLからLDAPへのserviceInstance
<!-- Bootstrap credentials to access destination LDAP -->
<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>
例13-4に示すように、ソースおよび宛先のストアの両方にjpsContextを作成します。
例13-4 ソースおよび宛先のポリシー・ストアのためのXMLからLDAPへのjpsContext
<jpsContext name="sourceContext"> <serviceInstanceRef ref="src.xml"/> </jpsContext> <jpsContext name="destinationContext"> <serviceInstanceRef ref="policystore.ldap.destination"/> </jpsContext> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext>
WebLogic Scripting Toolを起動します。
移行コマンドがオフライン・コマンドのときは、WebLogic Scripting ToolをWebLogic Serverに接続する必要はありません。
WebLogic Scripting ToolのmigrateSecurityStoreコマンドを実行して、次のようにポリシー・ストアおよびアプリケーションを移行します。
ポリシー・ストアを移行するには、次を実行します。
migrateSecurityStore
(type="policyStore", src="sourceContext",
dst="destinationContext",
configFile="myDir/jps-config.xml")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
アプリケーションを移行するには、次を実行します。
migrateSecurityStore
(type="appPolicies", src="sourceContext",
dst="destinationContext",
configFile="myDir/jps-config.xml",
srcApp="sourceApplication", dstApp="destinationApplication",
overWrite="true")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
移行されるアプリケーションの名前は、srcAppパラメータの値です。type="appPolicies"の場合、srcAppは必須パラメータです。この値が設定されていない場合、アプリケーション固有のポリシーを移行するためにソース・アプリケーションが必要ですが定義されていません。というエラー・メッセージが表示され、移行は失敗します。
宛先ポリシー・ストアにあるアプリケーションに割り当てられる名前は、dstAppパラメータの値です。このパラメータが渡されない場合、宛先ストアにあるアプリケーションの名前は、ソース・ストアで使用されている名前と同じです。
overWriteパラメータがtrueとして定義されている場合、宛先アプリケーションに固有のポリシーは、ソース・アプリケーションからのポリシーによって置き換えられます。このパラメータのデフォルト値はfalseであり、この場合は追加された変更のみが移行されます。
次に、LDAPベースのディレクトリからXMLベースのポリシー・ストアにポリシーを移行する手順を示します。
次のサブ手順で説明するように、jps-config.xmlを変更します。
例13-5に示すように、ソースおよび宛先のポリシー・ストアの両方にserviceInstanceを作成します。
例13-5 ソースおよび宛先のポリシー・ストアのためのLDAPからXMLへのserviceInstance
<!-- Source LDAP-based policy store instance -->
<serviceInstance provider="ldap.policystore.provider"
name="policystore.ldap.source">
<description></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>
<!-- Destination XML-based policy store instance -->
<serviceInstance name="dst.xml" provider="policystore.xml.provider"
location="/scratch/example_user/WithPSR/jazn-data-fscm.xml">
<description>File Based Policy Store Service Instance</description>
</serviceInstance>
例13-6に示すように、宛先LDAPディレクトリへのアクセスに使用されるブートストラップ資格証明に対応するserviceInstanceを作成します。
例13-6 ブートストラップ資格証明のためのLDAPからXMLへのserviceInstance
<!-- Bootstrap credentials to access source LDAP -->
<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>
例13-7に示すように、ソースおよび宛先のストアの両方にjpsContextを作成します。
例13-7 ソースおよび宛先のポリシー・ストアのためのLDAPからXMLへのjpsContext
<jpsContext name="sourceContext"> <serviceInstanceRef ref="policystore.ldap.source"/> </jpsContext> <jpsContext name="destinationContext"> <serviceInstanceRef ref="dst.xml"/> </jpsContext> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext>
WebLogic Scripting Toolを起動します。
移行コマンドがオフライン・コマンドのときは、WebLogic Scripting ToolをWebLogic Serverに接続する必要はありません。
WebLogic Scripting ToolのmigrateSecurityStoreコマンドを実行して、次のようにポリシー・ストアおよびアプリケーションを移行します。
ポリシー・ストアを移行するには、次を実行します。
migrateSecurityStore
(type="policyStore", src="sourceContext",
dst="destinationContext",
configFile="myDir/jps-config.xml")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
アプリケーションを移行するには、次を実行します。
migrateSecurityStore
(type="appPolicies", src="sourceContext",
dst="destinationContext",
configFile="myDir/jps-config.xml",
srcApp="sourceApplication", dstApp="destinationApplication",
overWrite="true")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
移行されるアプリケーションの名前は、srcAppパラメータの値です。type="appPolicies"の場合、srcAppは必須パラメータです。この値が設定されていない場合、アプリケーション固有のポリシーを移行するためにソース・アプリケーションが必要ですが定義されていません。というエラー・メッセージが表示され、移行は失敗します。
宛先ポリシー・ストアにあるアプリケーションに割り当てられる名前は、dstAppパラメータの値です。このパラメータが渡されない場合、宛先ストアにあるアプリケーションの名前は、ソース・ストアで使用されている名前と同じです。
overWriteパラメータがtrueとして定義されている場合、宛先アプリケーションに固有のポリシーは、ソース・アプリケーションからのポリシーによって置き換えられます。このパラメータのデフォルト値はfalseであり、この場合は追加された変更のみが移行されます。
次に、XMLベースのポリシー・ストアからデータベースにポリシーを移行する手順を示します。
|
注意: bootstrap.security.principal.keyプロパティの値として、リポジトリ・タイプを変更する場合のポリシー、資格証明およびキーストアの再関連付けの際に生成される鍵を設定する必要があります。 |
次のサブ手順で説明するように、jps-config.xmlを変更します。
例13-8に示すように、ソースおよび宛先のポリシー・ストアの両方にserviceInstanceを作成します。
例13-8 ソースおよび宛先のポリシー・ストアのためのXMLからデータベースへのserviceInstance
<!-- Source XML-based policy store instance -->
<serviceInstance name="src.xml" provider="policystore.xml.provider"
location="/scratch/example_user/WithPSR/jazn-data-fscm.xml">
<description>File Based Policy Store Service Instance</description>
</serviceInstance>
<!-- Destination DB-based policy store instance -->
<serviceInstance provider="ldap.policystore.provider"
name="policystore.db.destination">
<description>DB Based Policy Store Service Instance</description>
<property name="policystore.type" value="DB_ORACLE"/>
<property name="jdbc.url"
value="jdbc:oracle:thin:@sc.domainexample.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>
例13-9に示すように、宛先LDAPディレクトリへのアクセスに使用されるブートストラップ資格証明に対応するserviceInstanceを作成します。
例13-9 ブートストラップ資格証明のためのXMLからデータベースへのserviceInstance
<!-- Bootstrap credentials to access source DB -->
<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>
例13-10に示すように、ソースおよび宛先のストアの両方にjpsContextを作成します。
例13-10 ソースおよび宛先のポリシー・ストアのためのXMLからデータベースへのjpsContext
<jpsContext name="sourceContext"> <serviceInstanceRef ref="src.xml"/> </jpsContext> <jpsContext name="destinationContext"> <serviceInstanceRef ref="policystore.db.destination"/> </jpsContext> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext>
WebLogic Scripting Toolを起動します。
移行コマンドがオフライン・コマンドのときは、WebLogic Scripting ToolをWebLogic Serverに接続する必要はありません。
WebLogic Scripting ToolのmigrateSecurityStoreコマンドを実行して、次のようにポリシー・ストアおよびアプリケーションを移行します。
ポリシー・ストアを移行するには、次を実行します。
migrateSecurityStore
(type="policyStore", src="sourceContext",
dst="destinationContext",
configFile="/scratch/example_user/WithPSR/jps-config.xml")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
アプリケーションを移行するには、次を実行します。
migrateSecurityStore
(type="appPolicies", src="sourceContext",
dst="destinationContext",
configFile="/scratch/example_user/WithPSR/jps-config.xml",
srcApp="sourceApplication", dstApp="destinationApplication",
overWrite="true")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
移行されるアプリケーションの名前は、srcAppパラメータの値です。type="appPolicies"の場合、srcAppは必須パラメータです。この値が設定されていない場合、アプリケーション固有のポリシーを移行するためにソース・アプリケーションが必要ですが定義されていません。というエラー・メッセージが表示され、移行は失敗します。
宛先ポリシー・ストアにあるアプリケーションに割り当てられる名前は、dstAppパラメータの値です。このパラメータが渡されない場合、宛先ストアにあるアプリケーションの名前は、ソース・ストアで使用されている名前と同じです。
overWriteパラメータがtrueとして定義されている場合、宛先アプリケーションに固有のポリシーは、ソース・アプリケーションからのポリシーによって置き換えられます。このパラメータのデフォルト値はfalseであり、この場合は追加された変更のみが移行されます。
次に、データベースからXMLベースのポリシー・ストアにポリシーを移行する手順を示します。
|
注意: bootstrap.security.principal.keyプロパティの値として、リポジトリ・タイプを変更する場合のポリシー、資格証明およびキーストアの再関連付けの際に生成される鍵を設定する必要があります。 |
次のサブ手順で説明するように、jps-config.xmlを変更します。
例13-11に示すように、ソースおよび宛先のポリシー・ストアの両方にserviceInstanceを作成します。
例13-11 ソースおよび宛先のポリシー・ストアのためのデータベースからXMLへのserviceInstance
<!-- Source DB-based policy store instance -->
<serviceInstance provider="policystore.provider"
name="policystore.db.source">
<description>DB Based Policy Store Service Instance</description>
<property name="policystore.type" value="DB_ORACLE"/>
<property name="jdbc.url"
value="jdbc:oracle:thin:@sc.domainexample.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>
<!-- Destination XML-based policy store instance -->
<serviceInstance name="dst.xml" provider="policystore.xml.provider"
location="/scratch/example_user/WithPSR/jazn-data-fscm.xml">
<description>File Based Policy Store Service Instance</description>
</serviceInstance>
例13-12に示すように、宛先XMLディレクトリへのアクセスに使用されるブートストラップ資格証明に対応するserviceInstanceを作成します。
例13-12 ブートストラップ資格証明のためのデータベースからXMLへのserviceInstance
<!-- Bootstrap credentials to access source and destination stores -->
<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>
例13-13に示すように、ソースおよび宛先のストアの両方にjpsContextを作成します。
例13-13 ソースおよび宛先のポリシー・ストアのためのデータベースからXMLへのjpsContext
<jpsContext name="sourceContext"> <serviceInstanceRef ref="policystore.db.source"/> </jpsContext> <jpsContext name="destinationContext"> <serviceInstanceRef ref="dst.xml"/> </jpsContext> <jpsContext name="bootstrap_credstore_context"> <serviceInstanceRef ref="bootstrap.cred"/> </jpsContext>
移行のためにWebLogic Scripting Toolを起動します。
移行コマンドがオフライン・コマンドのときは、WebLogic Scripting ToolをWebLogic Serverに接続する必要はありません。
WebLogic Scripting ToolのmigrateSecurityStoreコマンドを実行して、次のようにポリシー・ストアおよびアプリケーションを移行します。
ポリシー・ストアを移行するには、次を実行します。
migrateSecurityStore
(type="policyStore", src="sourceContext",
dst="destinationContext",
configFile="/scratch/example_user/WithPSR/jps-config.xml")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
アプリケーションを移行するには、次を実行します。
migrateSecurityStore
(type="appPolicies", src="sourceContext",
dst="destinationContext",
configFile="/scratch/example_user/WithPSR/jps-config.xml",
srcApp="sourceApplication", dstApp="destinationApplication",
overWrite="true")
ここでは、次の事項が適用されます。
対応するjpsContext (ステップ1ですでに作成済)の名前は、srcおよびdstパラメータに渡されます。
jps-config.xmlファイル(ステップ1ですでに変更済)の名前は、configFileパラメータに渡されます。値は、完全パス情報を持つ完全修飾ファイル名である必要があります。
移行されるアプリケーションの名前は、srcAppパラメータの値です。type="appPolicies"の場合、srcAppは必須パラメータです。この値が設定されていない場合、アプリケーション固有のポリシーを移行するためにソース・アプリケーションが必要ですが定義されていません。というエラー・メッセージが表示され、移行は失敗します。
宛先ポリシー・ストアにあるアプリケーションに割り当てられる名前は、dstAppパラメータの値です。このパラメータが渡されない場合、宛先ストアにあるアプリケーションの名前は、ソース・ストアで使用されている名前と同じになります。
overWriteパラメータがtrueとして定義されている場合、宛先アプリケーションに固有のポリシーは、ソース・アプリケーションからのポリシーによって置き換えられます。このパラメータのデフォルト値はfalseであり、この場合は追加された変更のみが移行されます。
Oracle Entitlements Serverでは、キャッシング機能が提供されています。キャッシュ設定は、jps-config.xmlファイルで構成されます。次の各項では、適切な詳細を説明します。
認可決定キャッシングによって、Oracle Entitlements Serverは、同一コールが行われると、認可コールの結果をキャッシュし、その決定を今後使用できます。決定キャッシュは、2つの階層レベルで構成されます。
第1レベル(L1)は、認可コールで使用されるサブジェクトをキャッシュします。
第2レベル(L2)は、指定したサブジェクトの認可決定およびロール・マッピング決定をキャッシュします。
|
注意: 決定キャッシュは、ポリシーが変更されると自動的に無効化されます。 |
キャッシュのキーは、ポリシー評価中に使用される受信サブジェクト、権限および属性です。キャッシュの値は、決定および責任です。
すべてのパラメータ名には、接頭辞としてoracle.security.jps.pdpが付けられます。例13-14は、決定キャッシュ・パラメータをjps-config.xmlに設定する方法を示します。
例13-14 決定キャッシングを構成するXML
<serviceInstance name="pdp.service" provider="pdp.service.provider">
…
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled"
value="true"/>
<property name="oracle.security.jps.pdp.
AuthorizationDecisionCacheEvictionCapacity"
value="1000"/>
<property name="oracle.security.jps.pdp.
AuthorizationDecisionCacheEvictionPercentage"
value="15"/>
<property name="oracle.security.jps.pdp.AuthorizationDecisionCacheTTL"
value="180"/>
…
</serviceInstance>
表13-3では、決定キャッシング・パラメータを説明します。
表13-3 決定キャッシング・パラメータ
| 名前 | 説明 | 許容値 |
|---|---|---|
|
|
ポリシー決定キャッシュを有効化するかどうかを指定するオプション・パラメータ。 |
true (デフォルト) false |
|
|
L1キャッシュの最大容量を指定するオプション・パラメータ。エントリ数がこの値を超えると、いくつかのエントリが削除されます。 |
エントリ数を表す整数 500 (デフォルト) |
|
|
最大容量に達したときに削除する必要があるL1キャッシュ内のエントリの比率を指定するオプション・パラメータ。たとえば、最大容量が200で、このパラメータの値が10の場合、20エントリがキャッシュから削除されます。 |
エントリの割合を表す整数 10 (デフォルトは10%) |
|
|
L2キャッシュ内のエントリの存続時間の値(秒)を指定するオプション・パラメータ。認可決定をキャッシュする長さを定義します。 |
時間を秒で表す整数 60 (デフォルトは1分) |
渡された各属性にcachedプロパティが定義されている場合、その属性をキャッシュできます。cachedが有効化されている場合、対応する存続時間(TTL)の値も定義する必要があります。キャッシュのキーは、属性URIです。キャッシュの値は、属性オブジェクトです。例13-15は、属性キャッシュをjps-config.xmlに設定する方法を示します。
例13-15 属性キャッシングを構成するXML
<propertySet name="ootb.pip.attribute.age.based.on.myattr.rdbms">
<property name="ootb.pip.attr.type" value="OOTB_PIP_ATTRIBUTE"/>
<property name="ootb.pip.ref" value="pip.service.ootb.db"/>
<property name="name" value="myattr"/>
<property name="query" value=
"select myattr from test where username=%SYS_USER%"/>
<property name="cached" value="true"/>
<property name="TTL" value="60"/>
</propertySet>
|
注意: cachedが属性に定義されていない場合、属性はキャッシュされません。 |
Oracle Entitlements Serverでは、標準のJavaパッケージjava.util.loggingがロギングに使用されます。ロギング設定ファイルの名前はlogging.propertiesです。これはJava Development Kit (JDK)の標準ファイルであり、(デフォルトで)$JAVA_HOME/jre/lib/にあります。
|
注意: コマンド行でインストールに合わせて実際のパスに置き換えて次を実行することによって、logging.propertiesの場所を構成します。
-Djava.util.logging.config.file=/path/filename
|
Javaロギングでは、FINEST(最も詳細なトレース・メッセージを示します)からSEVERE(致命的なプログラム・エラーなどを示します)まで、出力を制御するためのログ・レベルが定義されています。特定のレベルでのロギングが有効化されると、それより高いすべてのレベルでのロギングも有効化されます。表13-4は、サーバーの問題をトラブルシューティングするための情報を提供するためにFINE(デバッグおよび問題の診断のための詳細)に設定できる具体的なロガー・プロパティを示します。
表13-4 サーバーの問題のロギング
| トラブルシューティングする問題 | FINEに設定するプロパティ |
|---|---|
|
ポリシー管理の問題 |
|
|
基本認可の問題 |
|
|
ポリシー配布の問題 |
|
|
セキュリティ・モジュールの問題 |
|
|
特定のツール( |
|
logging.propertiesを変更した後は、次のコマンドを実行して、必ずjava.util.logging.config.fileシステム・プロパティを設定してください。
-Djava.util.logging.config.file=/<directory>/logging.properties
例13-16は、Oracle Entitlements Serverのデフォルトのlogging.propertiesファイルです。
例13-16 デフォルトのlogging.properties構成ファイル
############################################################ # Default Logging Configuration File # You can use a different file by specifying a filename # with the java.util.logging.config.file system property. # For example java -Djava.util.logging.config.file=myfile ############################################################ # Global properties ############################################################ # "handlers" specifies a comma separated list of log Handler # classes. These handlers will be installed during VM startup. # Note that these classes must be on the system classpath. # By default we only configure a ConsoleHandler, which will only # show messages at the INFO and above levels. handlers= java.util.logging.ConsoleHandler, java.util.logging.FileHandler # To also add the FileHandler, use the following line instead. #handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler # Default global logging level. # This specifies which kinds of events are logged across # all loggers. For any given facility this global level # can be overriden by a facility specific level # Note that the ConsoleHandler also has a separate level # setting to limit messages printed to the console. .level= WARNING ############################################################ # Handler specific properties. # Describes specific configuration info for Handlers. ############################################################# default file output is in user's home directory. java.util.logging.FileHandler.pattern = /logs/java%u.log java.util.logging.FileHandler.limit = 50000000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter # Limit the message that are printed on the console to INFO and above. java.util.logging.ConsoleHandler.level = FINE java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter ############################################################ # Facility specific properties. ############################################################ # Provides extra control for each logger. ############################################################ # For example, set the com.xyz.foo logger to only log SEVERE # messages: oracle.oes.sm.level=FINE oracle.oes.common.level=FINE oracle.oes.tool.level=FINE oracle.oes.pd.level=FINE oracle.jps.policymgmt.level=FINE oracle.jps.authorization.level=FINE oracle.jps.common.level=FINE
ポリシーをデバッグすることで、特定の認可コールに対するポリシー評価プロセスを分析できます。Oracle Entitlements Serverランタイムのデバッグ機能はDebugStoreに収集され、(各種の情報の中でも)次を提供します。
評価プロセスに関連する認可ポリシーとロール・マッピング・ポリシー(および適切なポリシー・オブジェクト)
評価された属性とその値
関数を起動した結果
リクエストしたサブジェクトが付与または拒否されたロール
ポリシー評価結果(GRANT、DENY、NOT APPLICABLE)
責任と条件(該当する場合)
失敗した認証、不足しているグループ・メンバーシップおよび不正なアイデンティティ値
クライアントは次のどちらかの方法でデバッグ情報にアクセスできます。1つめの方法は、デバッグ・パラメータを構成して標準デバッグ・ログの情報を確認します。2つめの方法は、isAccessAllowed_debug()メソッドとgetRoles_debug()メソッドをオーバーロードします。これらの2つのメソッドは、ポリシー評価中のデバッグ情報が設定されたDebugInfoパラメータを返します。この2つめの方法は、ポリシー・シミュレーション・ツールとともに、エンド・ユーザーによって使用されます。次の各項では、これらの方法の詳細を説明します。
13.8.3項「ポリシー配布のデバッグ」では、ポリシー配布プロセスのデバッグについて説明します。
次の各項では、デバッグ・パラメータの構成方法とデバッグ・ログの読み方について説明します。
ポリシーから予想外の結果が得られた場合、デバッグを有効化して、ポリシー決定に関するすべてのイベントがセキュリティ・モジュールのログに記録されるようにすると、役に立つ可能性があります。次の各項では、Oracle Entitlements Serverを使用して作成された認可ポリシーのデバッグ方法とポリシー配布プロセスのデバッグ方法について説明します。
Oracle Entitlements Serverでは、デバッグ詳細を取得するために標準のJavaロギング・フレームワークが使用されます。ロギングは、特定のイベントのエンティティを通知するプロセスです。Oracle Entitlements Serverの場合、エンティティはファイルまたは管理コンソールになり、イベントはデバッグ情報、ランタイム例外、またはユーザーが実行するアクションの記録になります。ロギング・フレームワークは、Oracle Entitlements Serverデプロイメントに基づいて構成されます。詳細は、次の各項に記載されています。
|
注意: java.util.loggingパッケージは、プラットフォームのコア・ロギング機能のクラスおよびインタフェースを提供します。 |
Javaセキュリティ・モジュールがデプロイされている場合、ロギングを有効化するには、次の構成を行う必要があります。
セキュリティ・モジュールを開始する際に次のコマンドを実行して、ロギング構成ファイルを指定します。
-Djava.util.logging.config.file=logging.properties
構成ファイルに次の行を追加して、ロギング・レベルを設定します。
oracle.jps.authorization.level=FINEST oracle.jps.openaz.level=FINEST oracle.jps.authorization.debugstore.level=FINEST
1番目のプロパティのレベルは変更しないで、残り2つのレベルをFINESTに設定します。この構成により、ポリシー評価の結果が記録されます。ロギング・レベルは、ロギング・レコードの複雑度を定義し、(複雑度の低い順に)FINEST(単純な情報)、FINER、FINE、CONFIG、INFO、WARNINGおよびSEVERE(複雑な情報)があります。
構成ファイルを指定しない場合、$JAVA_HOME/jre/lib/にあるlogging.propertiesファイルが使用されます。例13-17は、管理コンソールに情報を記録するようにlogging.propertiesを構成する方法を示します。
例13-17 管理コンソール・ロギングのための構成
#The messages will we printed to the standard output handlers=java.util.logging.ConsoleHandler #The default level for all loggers is INFO .level=INFO #Override the default level for OES authorization to FINEST oracle.jps.authorization.level=FINEST oracle.jps.openaz.level=FINEST #Use default formatter to print the messages java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
例13-18は、ファイルに情報を記録するようにlogging.propertiesを構成する方法を示します。
例13-18 ファイル・ロギングのための構成
#The messages will be written to a file handlers=java.util.logging.FileHandler #The default level for all loggers is INFO .level=INFO #Override the default level for OES authorization to FINEST oracle.jps.authorization.level=FINEST oracle.jps.openaz.level=FINEST #Configure file information. %h – is the user home directory java.util.logging.FileHandler.pattern = %h/java%u.log java.util.logging.FileHandler.limit = 50000 java.util.logging.FileHandler.count = 1 java.util.logging.FileHandler.formatter = java.util.logging.SimpleFormatter
WebLogic Serverセキュリティ・モジュールがデプロイされている場合、ロギングを有効化するには、WebLogic Serverドメインを起動する際に、次のコマンドを実行して、ロギング構成ファイルを指定します。
startWeblogic.sh -Djava.util.logging.config.file=logging.properties
|
ヒント: 相対パスを指定する場合、ベース・ディレクトリはドメイン・ホームです。startWeblogic.shがあるディレクトリではありません。 |
WebLogic Serverセキュリティ・モジュールに関連するその他の構成は、13.8.1.1.1項「Javaセキュリティ・モジュールのロギングの構成」で定義されている構成と同様です。
次の各項では、ロギング・ファイルに記録された情報を検索する方法について説明します。各項には、実行するコマンドが記載されており、多くの項には、サンプル出力も記載されています。
次のコマンドをロギング・ファイルに対して実行して、PEPリクエスト関連の情報(認証ID、ランタイム・リソース、ランタイム・アクション、およびアプリケーション・コンテキストなど)を出力します。
grep "PepRequestImpl"
例13-19は、DebugStoreロガーが有効化されている場合にログ・ファイルに出力される可能性がある内容を示すサンプル出力です。ここには、アプリケーションの名前、リクエストされたリソース、アクション、サブジェクトおよび評価されたポリシーが出力されています。
例13-19 DebugStoreのサンプル・ロギング出力
========== Start Of Policy Evaluation Info ==========
Application: Library
Requested Resource Type: LibraryResource
Requested Resource: books/CrimeAndPunishment
Requested Resource Present: false
Requested Action: borrow
Request Subject Principals:
class weblogic.security.principal.WLSUserImpl:John
Effective Roles Granted: [authenticated-role, Member, PrivilegedMember]
Role-Mapping Policies:
1.Policy Name: GrantPrivilegedMemberPolicy
Matched Policy Principals:
class weblogic.security.principal.WLSUserImpl:John
Policy Principals Semantics: OR
Policy Roles: [PrivilegedMember]
Matched Policy Resources: NONE
Policy Evaluation Result: NOT_APPLICABLE
Policy Rules:
Rule Name: GrantPrivilegedMemberRule
Rule Effect: GRANT
Rule Condition: (MembershipLength >= 5)
Evaluated Rule Attributes and Functions:
MembershipLength(Dynamic, Integer) = 4
Rule Evaluation Result: NOT_APPLICABLE
2.Policy Name: DenyMemberPolicy
Matched Policy Principals:
class weblogic.security.principal.WLSUserImpl:John
Policy Principals Semantics: OR
Policy Roles: [Member]
Matched Policy Resources: [.*]
Policy Evaluation Result: NOT_APPLICABLE
Policy Rules:
Rule Name: DenyMemberRule
Rule Effect: DENY
Rule Condition: (MemberState = MA)
Evaluated Rule Attributes and Functions:
MemberState(Dynamic, String) = CA
Rule Evaluation Result: NOT_APPLICABLE
Static Role Grants:
Principal= class oracle.security.jps.service.policystore.ApplicationRole:
Member, Roles= [PrivilegedMember]
Principal= class weblogic.security.principal.WLSUserImpl:John,
Roles= [Member]
Denied Static Role Grants: NONE
Authorization Policies:
1.Policy Name: DenyBorrowLibResourcesPolicy
Matched Policy Principals:
class oracle.security.jps.service.policystore.ApplicationRole:Member
class weblogic.security.principal.WLSUserImpl:John
Policy Principals Semantics: AND
Matched Policy Resource-Actions:
Resource = books/.*, Action = borrow
Policy Obligations: NONE
Policy Evaluation Result: NOT_APPLICABLE
Policy Rules:
Rule Name: DenyBorrowLibResourcesRule
Rule Effect: DENY
Rule Condition: (NumBorrowedBooks >= 6)
Evaluated Rule Attributes and Functions:
NumBorrowedBooks(Dynamic, Integer) = 2
Rule Evaluation Result: NOT_APPLICABLE
2.Policy Name: GrantBorrowLibResourcesPolicy
Matched Policy Principals:
class oracle.security.jps.service.policystore.ApplicationRole:Member
Policy Principals Semantics: OR
Matched Policy Resource-Actions:
Resource = .*books.*, Action = ANY
Resource = .*, Action = borrow
Policy Obligations: NONE
Policy Evaluation Result: GRANT
Policy Rules:
Rule Name: GrantBorrowLibResourcesRule
Rule Effect: GRANT
Rule Condition: ((NumBorrowedBooks < 4) && (age() >= 12))
Evaluated Rule Attributes and Functions:
NumBorrowedBooks(Dynamic, Integer) = 2
age(Function, Integer) = 24
Rule Evaluation Result: GRANT
========== End Of Policy Evaluation Info ==========
次のコマンドをロギング・ファイルに対して実行して、特定のセキュリティ・モジュールのキャッシュ構成パラメータを出力します。
grep "AuthorizationDecisionCacheTTL"
この検索では、次のプロパティが返されます。プロパティがログに表示されない場合、プロパティはjps-config.xmlで指定されていません。このような場合、プロパティのデフォルト値が使用されます。
AuthorizationDecisionCacheTTLは、認可決定キャッシュの存続時間(秒)を定義します。デフォルト値は60です。
AuthorizationDecisionCacheEvictionPercentageは、認可決定キャッシュが最大容量に達したときに削除する認可決定の比率を定義します。デフォルト値は10です。
AuthorizationDecisionCacheEvictionCapacityは、決定キャッシュ・サイズがこのサイズに達した場合に認可決定キャッシュを削除するのに使用する数を定義します。デフォルト値は500です。
AuthorizationDecisionCacheEnabledは、認可決定キャッシュを有効化するかどうかを指定します。デフォルト値はtrueです。
例13-20は、この検索での出力を示します。
例13-20 キャッシュ構成パラメータ検索でのサンプル出力
oracle.security.jps.az.internal.runtime.service.AbstractPDPService
FINE: properties : {
oracle.security.jps.pdp.AuthorizationDecisionCacheTTL=60,
oracle.security.jps.pdp.AuthorizationDecisionCacheEvictionPercentage=10,
oracle.secuirty.jps.pdp.AuthorizationDecisionCacheEvictionCapacity=1000,
oracle.security.jps.pdp.AuthorizationDecisionCacheEnabled=true}
次のコマンドをロギング・ファイルに対して実行して、認可リクエストの形式でOracle Entitlements Serverが受信するプリンシパルの名前を出力します。
grep "Principal:"
例13-21は、プリンシパル検索での出力を示します。
次のコマンドをロギング・ファイルに対して実行して、認可リクエストの形式でOracle Entitlements Serverが受信するリソースおよびアクションの名前を出力します。
grep "Resource:"
例13-22は、情報を返す方法を示します。定義される値は、ポリシー・オブジェクトの名前です。
アプリケーション = Lib
リソース・タイプ = libraryresourcetype
リソース = Book
アクション = borrow
次のコマンドをロギング・ファイルに対して実行して、認可リクエストの形式でOracle Entitlements Serverが受信する属性の値を出力します。
grep "<name-of-the-attribute>:" EXAMPLE: grep "NumberOfBorrowedBooksAttribute:"
例13-23は、属性の名前がNumberOfBorrowedBooksAttributeで、値が2の場合に返される情報を示します。
次のコマンドをロギング・ファイルに対して実行して、格納された認可決定を取得します。
grep "AccessResultLogger"
例13-24は、返される情報を示し、認可決定が肯定的であったことを確認します。
UNIXシステムで、次のコマンドをロギング・ファイルに対して実行して、特定の責任の値を出力します。grep <string_to_find> <filename>。
次に例を示します。
grep "adding response attribute:" | grep "obligations"
例13-25は、プリンシパルが現在チェックアウトしているライブラリ・ブックの量が3より多い場合、責任(DenyObligationという名前)はリクエストを拒否することを示している場合に返される情報を示します。次の場合、プリンシパルは5つのブックをチェックアウトしています。
次のコマンドをロギング・ファイルに対して実行して、静的に付与されるアプリケーション・ロールの名前を出力します。
grep "AbstractRoleManager" | grep "getGrantedStaticAppRoles"
例13-26は、2つの静的ロール(組込みロールとReaderの認証ロール、およびLibraryという名前のアプリケーションで定義されるアプリケーション・ロール)をプリンシパルのリストに追加する方法を示します。
例13-26 静的ロール検索でのサンプル出力
oracle.security.jps.az.internal.runtime.entitymanager.AbstractRoleManager getGrantedStaticAppRoles(Set) FINER: RETURN [authenticated-role, ApplicationRoleLibrary/Readeruname: cn=Writer,cn=Roles,cn=Lib,cn=akapisni_dwps1_ view1.atzsrg,cn=JPSContext,cn=jpsTestNode,guid: 411EBF807CD411E0BF887FB1A0F3878F]
isAccessAllowed_DebugとgetRoles_Debugは、デバッグ情報を返すためにコードで使用できるメソッドです。DebugInfoは、isAccessAllowed_DebugコールとgetRoles_Debugコールで返されるオブジェクトです。これらのメソッドをオーバーロードする際、ポリシー・デバッグ機能(ポリシー・シミュレーション・ツールを含む)のコンシューマに次の情報が渡される必要があります。
リクエストしたサブジェクトが付与されたロール。
リクエストしたサブジェクトが拒否されたロール。
リクエストしたサブジェクトが付与された有効なロール。
リクエストしたサブジェクト、リソース・タイプ、リソースおよびアクション(該当する場合)が一致するロール・マッピング・ポリシーと認可ポリシー。各ポリシーには、名前、プリンシパル(ユーザーまたはロール・サブジェクトと一致)、リソースまたはリソース式(入力リソースに一致)、アクションまたはロール(ポリシー・タイプに依存)、ポリシー・ルール(ルール名、GRANTまたはDENYのどちらかの影響、条件を表す文字列、評価された属性とその値(動的、関数およびリソース・タイプを含む)、およびルール評価結果(Grant、Deny、Not Applicable)が必要です。
ポリシー評価結果(Grant、Deny、Not Applicable)。
責任(認可ポリシーの場合のみ)。
詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理Java APIリファレンスを参照してください。
ポリシー配布コンポーネントでは、ポリシー管理のLoggerインタフェースを使用します。ポリシー配布コンポーネントのデバッグを有効化するには、ロギング構成ファイルのoracle.jps.policymgmt.levelプロパティのロギング・レベルをFINESTに変更します。手順は、13.8.1.1項「デバッグのためのロギングの構成」を参照してください。ポリシー配布をデバッグする際は、次も確認する必要があります。
セキュリティ・モジュール配布モード・パラメータoracle.security.jps.runtime.pd.client.policyDistributionModeが正しく定義されていることを確認します。付録A「ポリシー配布構成」を参照してください。
制御プッシュ・モードまたは制御プル・モードでポリシーを配布する場合、ローカル・キャッシュ・ファイルの存在を確認します。ローカル・キャッシュ・ディレクトリは、oracle.security.jps.runtime.pd.client.localpolicy.work_folderパラメータの値として定義されます。このディレクトリのpolicyA/やpolicyB/などのサブディレクトリで、各ポリシーのXML_CACHE_FILEを参照します。キャッシュ・ファイルのタイムスタンプが、最後の配布の開始時刻と一致することを確認します。付録A「ポリシー配布構成」を参照してください。
制御プッシュ・モードでポリシーを配布する場合、ポリシーの配布先のセキュリティ・モジュールのインスタンスがアプリケーションの「ポリシー配布」ページに表示され、同期していることを確認します。
セキュリティ・モジュール側をデバッグして、正しいポリシーが評価されていることを確認します。
