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

この章では、セキュリティ管理者がFusion Middleware Control、WLSTコマンドまたはOracle Entitlements Serverのいずれかを使用してポリシーを管理する方法について説明します。

これらについては次の項で説明します。

第10.1項「ポリシー・ストアの管理」
第10.2項「Fusion Middleware Controlを使用したポリシーの管理」
第10.3項「WLSTコマンドを使用したアプリケーション・ポリシーの管理」
第10.4項「キャッシングとキャッシュのリフレッシュ」
第10.5項「WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与」
第10.6項「WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ」
第10.7項「Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理」

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

ポリシー・ストアのデータにアクセスできるのは、ドメイン管理者など、適切なパーミッションを持つユーザーに限られます。

次の各項で、Fusion Middleware Control、WLSTコマンドまたはOracle Entitlements Serverを使用して管理者がポリシーを管理する方法について説明します。代表的な操作は次のとおりです。

Fusion Middleware Controlを使用したポリシーの管理
WLSTコマンドを使用したアプリケーション・ポリシーの管理
Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理

予期しない認可の失敗を防ぎ、効果的にポリシーを管理するには、次の重要ポイントに注意してください。

重要ポイント1:

ユーザーを削除する前に、ユーザーに付与されているすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに誤って継承される可能性があります。

ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー(権限付与、パーミッション、グループ)を更新して、変更後のデータでも予期したとおりに機能するようにする必要があります。

第J.4.4項「ユーザーによる予期しないパーミッションの取得」を参照してください。

重要ポイント2:

ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。

そのため、次のことをお薦めします。

ポリシーのプロビジョニング時に、管理者は、ポリシーで使用するユーザーおよびグループの名前に、アイデンティティ・リポジトリに記録されているその名前とまったく同じ文字構成を使用します。これによって、ユーザー名またはグループ名を指定した問合せをポリシー・ストアに対して実行すると、想定したとおりに機能します。
実行時にユーザー名を入力するときに、エンドユーザーは、アイデンティティ・リポジトリで指定されている大文字/小文字の組合せと完全に一致する名前を入力します。これによって、予期したとおりにユーザーが認可されます。

第J.4.2項「パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致」を参照してください。

重要ポイント3:

リソース・タイプの名前、リソース、または権限には印刷可能文字のみを使用でき、先頭または末尾に空白を使用することはできません。

ロール名をはじめとしたポリシーにおける文字使用に関する考慮事項は、第J.9.5項「ポリシーに使用する文字」を参照してください。

重要ポイント4:

デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗がコンソールに送信されるようにするには、システム変数jps.auth.debugを-Djps.auth.debug=trueに設定する必要があります。

特に、JpsAuth.checkPermissionの失敗がコンソールに送信されるようにするには、この変数を前述のように設定する必要があります。

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

Fusion Middleware Controlでは、次の項の説明のように、ドメインで使用しているポリシー・ストア・プロバイダのタイプに関係なく、WebLogicドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理できます。

アプリケーション・ポリシーの管理
アプリケーション・ロールの管理
システム・ポリシーの管理

その他のサービス・プロバイダを管理する手順は、第9.7項「Fusion Middleware Controlを使用したサービス・プロバイダの構成」を参照してください。

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

この項では、Fusion Middleware Controlを使用してアプリケーション・ポリシーを管理する方法について説明します。

注意:

複数のアプリケーションがパーミッションを共有している場合、パーミッション・チェックの失敗を防ぐには、該当するパーミッション・クラスをシステム・クラスパスで指定しておく必要があります。

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ポリシー」に移動して「アプリケーション・ポリシー」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
指定したプリンシパルまたはパーミッションに一致するアプリケーションのポリシーを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、基準にする文字列(プリンシパル名、プリンシパル・グループまたはアプリケーション・ロール)を入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。
選択したアプリケーション・ストライプのアプリケーション・ポリシーを作成するには、「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。ここで、作成する権限に対するプリンシパルおよびパーミッションを追加します。
1. パーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログ・ボックスを表示します。
  
  そのダイアログ・ボックスの「検索」領域で、まず「権限」または「リソース・タイプ」を選択します。「権限」を選択した場合は、クラスまたはリソース名に一致するパーミッションを指定し、「権限クラス」および「リソース名」を指定します。「リソース・タイプ」を選択した場合は、タイプ名に一致するリソース・タイプを指定し、タイプを指定します。「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したパーミッションが、「権限」領域の表に表示されます。
2. プリンシパルを追加するには、「権限受領者」領域の「追加」ボタンをクリックして、「プリンシパルの追加」ダイアログ・ボックスを表示します。
  
  そのダイアログ・ボックスの「検索」領域で、「タイプ」を選択し、プリンシパル名または表示名に一致させる文字列を入力して、青いボタンをクリックします。問合せの結果が「検索済プリンシパル」表に表示されます。その表から1つ以上の行を選択し、「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したプリンシパルが、「権限受領者」領域の表に表示されます。
3. 「権限受領者」領域の表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。
4. 完了したら、「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。作成したポリシーのプリンシパルとパーミッションがページの下部の表に表示されます。
既存のアプリケーション・ポリシーに基づいてアプリケーション・ポリシーを作成する手順は、次のとおりです。
1. 表から既存のポリシーを選択します。
2. 「類似作成」をクリックし、「アプリケーション権限の類似作成」ページを表示します。このページでは、選択したポリシーから抽出されたデータがパーミッションの表に自動的に入力されます。
3. 前述の手順3の下位手順の説明に従い、必要に応じてこれらの値を変更し、「OK」をクリックします。

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

この項では、Fusion Middleware Controlを使用してアプリケーション・ロールを管理する方法について説明します。

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ロール」に移動して「アプリケーション・ロール」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
アプリケーションのロールを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、ロール名に一致させるデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。
アプリケーション・ロールを作成するには、「作成」をクリックして、「アプリケーション・ロールの作成」ページを表示します。すべての領域に一度にデータを入力する必要はないことに注意してください。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後から指定できます。同様に、ロール・マッピングに対するデータを後で入力することもできます。

領域「一般」で、作成するロールの次の属性を指定します。
1. 「ロール名」テキスト・ボックスにロールの名前を入力します。
2. 必要に応じて、ロールに表示する名前を「表示名」テキスト・ボックスに入力します。
3. オプションで、「説明」テキスト・ボックスに、ロールの説明を入力します。
「メンバー」領域で、作成するロールのマップ先とするユーザーまたはグループを指定します。マップ先とする他のアプリケーション・ロールがある場合は、それを指定します。

作成するアプリケーション・ロールにアプリケーション・ロールを追加する手順は、次のとおりです。
1. 「追加」をクリックして、「プリンシパルの追加」ダイアログを表示します。
2. このダイアログで、「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名に一致させる文字列を入力して、青いボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。その表から1つ以上のプリンシパルを選択します。
3. 完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したアプリケーション・ロールが「メンバー」表に表示されます。
「メンバー」表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。
「OK」をクリックし、ロールの作成(または更新)を完了し、「アプリケーション・ロール」ページに戻ります。作成したロールがそのページの下部の表に表示されます。
既存のアプリケーション・ロールに基づいてアプリケーション・ロールを作成する手順は、次のとおりです。
1. 表から既存のロールを選択します。
2. 「類似作成」をクリックし、「アプリケーション・ロールの類似作成」ページを表示します。このページでは、選択したロールから抽出されたデータが一部のデータに自動的に入力されます。
3. ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。

ロール階層でパーミッションがどのように継承されるかを理解するには、第2.2.1項「パーミッションの継承とロールの階層」を参照してください。

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

この項では、Fusion Middleware Controlを使用して、Oracle WebLogic Serverドメインのシステム・ポリシーを管理する方法について説明します。

次の手順では、プリンシパルのポリシーとコードベースのポリシーという2種類のシステム・ポリシーを作成できます。プリンシパルのポリシーでは、ユーザーまたはグループのリストにパーミッションを付与します。コードベースのポリシーでは、コード(通常はURLまたはJARファイル)にパーミッションを付与します。たとえば、資格証明ストア・フレームワークを使用するアプリケーションには、適切なコードベースのポリシーが必要です。コードベースURLでは、ワイルドカードやパターンはサポートされていません。

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「システム・ポリシー」に移動して「システム・ポリシー」ページを表示します(次の図にページの一部を示します)。

「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
指定したタイプ、名前およびパーミッションと一致するシステム・ポリシーを表示するには、「検索」領域を開き、一致対象のデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。
「編集」ボタンをクリックすると、選択したポリシーの特性をいつでも編集できます。リストからポリシーを削除するには、「削除」ボタンをクリックします。

システム・ポリシーを作成する手順は、次のとおりです。

「作成」をクリックして、「システム権限の作成」ページを表示します。
作成するポリシーのタイプとして、「プリンシパル」または「コードベース」を選択します。選択したタイプによってUIが多少異なります。次の手順は、「プリンシパル」を選択した場合に対するものです。
パーミッションを追加するには、「権限」領域の「追加」ボタンをクリックして、「権限の追加」ダイアログ・ボックスを表示し、作成しているポリシーに追加するパーミッションを選択します。
1. 「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。検索結果が「検索」領域の表に表示されます。
2. 追加するパーミッションを選択するには、表からパーミッションを選択します。パーミッションを選択すると、その詳細が読取り専用の「カスタマイズ」領域に表示されます。
3. 「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したパーミッションが、「権限」の表に追加されます。
「パーミッション」表からパーミッションを選択し、「編集」ボタンを使用すると、パーミッションの特性をいつでも変更できます。リストからパーミッションを削除するには、「削除」ボタンを使用します。
「OK」をクリックして、「システム・ポリシー」ページに戻ります。
「コードベースに関する権限」領域の表は読取り専用であり、コードベース・システム・ポリシーに関連付けられているリソース名、アクションおよびパーミッション・クラスを示します。

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

オンライン・コマンドとは、実行中のサーバーとの接続が必要なコマンドです。特に指定がないかぎり、この項に記載されたスクリプトはオンライン・スクリプトで、タイプがファイル、LDAP、DBのいずれであるかにかかわりなくOPSSセキュリティ・ストアで動作します。動作にサーバーの実行を必要としないオフラインのスクリプトもいくつか存在します。

読取り専用スクリプトは、モニター、オペレータ、コンフィギュレータまたはAdminというWebLogicグループに属するユーザーのみが実行できます。読取り-書込みスクリプトは、AdminまたはコンフィギュレータのWebLogicグループに属するユーザーのみが実行できます。すべてのWLSTコマンドは、Oracle WebLogic Serverをインストールすれば、追加設定なしで使用できます。

WLSTコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力します。スクリプト・モードの場合は、スクリプトをテキスト・ファイル(ファイル名拡張子は.py)に記述して、シェル・スクリプトのディレクティブのように入力なしで実行できます。

WASAdminスクリプトは、インタラクティブ・モードでのみ実行できます。

注意:

WLSTコマンドを呼び出す前は、次のスクリプトのいずれかを実行して、必要なJARがクラス・パスに追加されていることを確認する必要があります。

>sh $ORACLE_HOME/common/bin/wlst.sh

オンライン・コマンドを実行するには、次のようにWebLogicサーバーに接続します。

>java weblogic.WLST
>connect('userName', 'userPassword', 'url', 'adminServerName')

構成ファイルおよびJVMについては、第5.6項「WLSTコマンドを使用した一般的なセキュリティ操作」を参照してください。

OPSSはサポートされているすべてのプラットフォームでアプリケーション・ポリシーの管理に使用できる次のスクリプトが用意されています(特に指定がないかぎりこのスクリプトはすべてオンラインです)。

listSecurityStoreInfo
listAppStripes
listCodeSourcePermissions
createAppRole
deleteAppRole
grantAppRole
revokeAppRole
listAppRoles
listAppRolesMembers
grantPermission
revokePermission
listPermissions
deleteAppPolicies
createResourceType
getResourceType
deleteResourceType
createResource
deleteResource
listResources
listResourceActions
createEntitlement
getEntitlement
deleteEntitlement
addResourceToEntitlement
revokeResourceFromEntitlement
listEntitlements
grantEntitlement
revokeEntitlement
listResourceTypes
reassociateSecurityStore
migrateSecurityStore。第9.6.2項「スクリプトmigrateSecurityStoreを使用した移行」を参照してください。

前述のスクリプトで指定するクラス名はすべて、完全修飾パス名にする必要があります。引数appStripeは、アプリケーション・ストライプ(通常はアプリケーション名)を参照し、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。

認証ロール、匿名ロールおよびWLSTコマンドに関する重要な情報は、第10.5項「WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与」を参照してください。

バージョン管理しているアプリケーションのアプリケーション・ストライプの正しい使用法は、第10.6項「WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ」を参照してください。

10.3.1 reassociateSecurityStore

コマンドreassociateSecurityStoreでは、OPSSセキュリティ・ストアがソースからターゲットのLDAPベース・ストアまたはDBベース・ストアに移行され、jps-config.xmlファイルおよびjps-config-jse.xmlファイル内のサービスがターゲット・リポジトリにリセットされます。また、OPSSセキュリティ・ストアを別のドメインのものと共有する指定もできます(後述のオプション引数joinを参照)。OPSSバイナリとターゲットのOPSSセキュリティ・ストアには、互換性のあるバージョンを使用する必要があります(詳細は、第J.8.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください)。

ソースは、ファイルベース、LDAPベース、またはDBベースのストアのいずれでもかまいません。サポート対象のLDAPターゲットのタイプは、Oracle Internet Directoryのみ、DBターゲットの場合はDB_ORACLEのみです。このコマンドは、インタラクティブ・モードでのみサポートされます。

このコマンドにより、該当するパラメータ(次の引数adminおよびpasswordを参照)が渡されて、ブートストラップ資格証明がリセットされます(ブートストラップ資格証明は、ターゲット・ストアへのアクセスに使用される資格証明です)。ブートストラップ資格証明をリセットする別の方法については、modifyBootStrapCredentialおよびaddBootStrapCredentialの各スクリプトを参照してください。

再関連付けに関連する推奨事項は、「重要ポイント」を参照してください。

インタラクティブ・モード構文

コマンド構文は、ターゲット・ストアのタイプに応じて若干異なります。

ターゲットがLDAPベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。

reassociateSecurityStore(domain="domainName", 
      servertype="OID",  
      ldapurl="hostAndPort", 
      jpsroot="cnSpecification", 
      admin="cnSpecification", 
      password="passWord",
      [join="trueOrfalse"] [,keyFilePath="dirLoc", keyFilePassword="password"]])

ターゲットがDBベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。

reeassociateSecurityStore(domain="domainName", 
       servertype="DB_ORACLE", 
       datasourcename="datasourceName", 
       jpsroot="jpsRoot",
       jdbcurl="jdbcURL",
       jdbcdriver="jdbcDriverClass",
       dbUser="dbUserName",
       dbPassword="dbPassword",
       [admin="adminAccnt", password="passWord",]
       [join="trueOrfalse" 
          [,keyFilePath="<directory location>",keyFilePassword="<password>"]]
       [odbcdsn="odbcDsnSting"])

引数の意味は、次のとおりです。

domainでは、WebLogicで、再関連付けが実行されるドメイン名を指定します。
adminでは、LDAPターゲットの場合、ターゲット・サーバーに対する管理者のユーザー名を指定します。形式はcn=usrNameです。
DBターゲットの場合は、DBに、(ユーザー/パスワードで保護される)保護データ・ソースがある場合にのみ必要です。この場合、データ・ソースが作成されたときにデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。指定した場合は、passwordも指定する必要があります。
passwordでは、引数adminに関連付けられているパスワードを指定します。LDAPターゲットの場合にのみ必要です。

DBターゲットの場合は、DBに保護データ・ソースがある場合にのみ必要で、当該の場合は引数adminで指定されたユーザーに関連付けられたパスワードを指定します。指定した場合は、adminも指定する必要があります。
ldapurlでは、LDAPサーバーのURIを指定します。デフォルトのポートを使用する場合の形式は、ldap//:host:portです。匿名SSLまたは一方向SSL伝送を使用する場合の形式は、ldaps://host:portです。目的のSSL接続モードを扱うことができるようにセキュア・ポートを構成する必要があります。また、このセキュア・ポートは、デフォルトの(セキュアではない)ポートとは別のポートとする必要があります。
servertypeでは、ターゲットLDAPサーバーまたはDBサーバーの種類を指定します。有効なタイプは、OIDまたはDB_ORACLEのみです。
jpsrootでは、ターゲットLDAPリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。

joinでは、ドメインがOPSSセキュリティ・ストアを別のドメインと共有するかどうかを指定します。オプション。trueに設定すると既存のストアを別のドメインと共有します。falseに設定すると共有しません。指定しなかった場合は、デフォルトでfalseに設定されます。この引数を使用することにより、複数のWebLogicドメインから同一の論理OPSSセキュリティ・ストアを指定できるようになります。

注意1:

join=trueを指定して、OPSSセキュリティ・ストアを別のドメインに再度関連付ける場合、OPSS暗号化鍵を一方のドメインからエクスポートして他方のドメインにインポートする必要があり、ファイルkeystores.xmlも一方のドメインから他方のドメインにコピーする必要があります。

この注意では、このタスクの実行方法について説明しています(別の方法については、引数keyFilePathの説明にある注意を参照してください)。

具体的には、Domain1にセキュリティ・ストアがあり、join=trueを使用して、Domain2をDomain1のセキュリティ・ストアに再度関連付けした場合、次のように実行します。

WLSTコマンドexportEncryptionKeyを使用して、Domain1からewallet.p12ファイルにキーを抽出します(渡した引数keyFilePasswordの値は、後でそのキーを2つ目のドメインにインポートするときに使用する必要があります)。
WLSTコマンドimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2にインポートします。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じでなければならないことに注意してください。
Domain1のファイルkeystores.xmlをDomain2にコピーします。Domain2にkeystore.xmlが存在する場合は、それを上書きします。

Domain2で実施されたキーストア・サービスの(出荷時の設定とは異なる)いずれの変更も失われることに注意してください(これは、既存のセキュリティ・ストアの結合を目的としているため予期された動作です)。
Domain2のサーバーを再起動します。

キーをインポートまたはエクスポートするためのスクリプトの詳細は、exportEncryptionKeyおよびimportEncryptionKeyを参照してください。

datasourcenameでは、JDBCデータ・ソースのJNDI名を指定します。これはデータ・ソース作成時に入力されたJNDI名データ・ソースの値と同じである必要があります。

keyFilePathでは、ewallet.p12ファイルが作成されるディレクトリを指定します。このファイルの内容は暗号化され、keyFilePasswordに渡される値により保護されます。オプション。引数keyFilePasswordおよびjoinとともに使用する必要があります。

注意2:

join=trueを指定して、OPSSセキュリティ・ストアを別のドメインに再度関連付ける場合、OPSS暗号化鍵を一方のドメインからエクスポートして他方のドメインにインポートする必要があり、ファイルkeystores.xmlも一方のドメインから他方のドメインにコピーする必要があります。

この注意では、このタスクの実行方法について説明しています(別の方法については、引数joinの説明にある注意を参照してください)。

引数keyFilePathおよびkeyFilePasswordを使用する場合、コマンドreassociateSecurityStoreによってキーのエクスポートおよびインポートが自動的に実行されますが、コマンドの実行前に、ファイルkeystores.xmlを手動でコピーしておく必要があります。

具体的には、Domain1にセキュリティ・ストアがあり、join=trueおよびkeyFile引数を使用して、Domain2をDomain1のセキュリティ・ストアに再度関連付けする場合、次のように実行します。

reassociateSecurityStoreを実行する前に、Domain1のファイルkeystores.xmlをDomain2にコピーします。Domain2にkeystore.xmlが存在する場合は、それを上書きします。

Domain2で実施されたキーストア・サービスの(出荷時の設定とは異なる)いずれの変更も失われることに注意してください(これは、既存のセキュリティ・ストアの結合を目的としているため予期された動作です)。
適切な引数値を指定して、コマンドreassociateSecurityStoreを実行します。
Domain2のサーバーを再起動します。

keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。オプション。引数keyFilePathおよびjoinとともに使用する必要があります。
jdbcurlでは、Java SEアプリケーションでデータベースへの接続に使用するJDBC URLを指定します。Java SEアプリケーションにのみ適用されます。必須。引数jdbcdriver、dbUserおよびdbPasswordとともに使用する必要があります。
jdbcdriverでは、データベースへの接続に使用するJDBCドライバのクラスを指定します。必須。引数jdbcurlとともに使用する必要があります。
dbUserでは、ブートストラップ資格証明に追加する資格証明ストア内のデータベース・ユーザーを指定します。必須。引数jdbcurlとともに使用する必要があります。
dbPasswordでは、dbUserを使用して指定したユーザーのパスワードを指定します。必須。引数jdbcurlとともに使用する必要があります。
odbcdsnでは、C CSF APIで使用するODBC DSN名を指定します。Cプログラムにのみ適用されます。

使用例

reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")

myDomainでOPSSセキュリティ・ストアを共有するには、次の例に示すようにコマンドを呼び出します。

reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode", join="true")

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

このトピックは、LDAPベースおよびDBベースのOPSSセキュリティ・ストアにのみ適用されます。ファイルベースのストアの場合、キャッシュは数秒後に更新されます(ファイルベースのストアは本番環境システムではお薦めしません。)

OPSSは、キャッシュ・セキュリティ・アーティファクトによって認可プロセスを最適化します。アプリケーション・ポリシー(またはその他のセキュリティ・アーティファクト)を変更した場合、アプリケーションおよびアーティファクトの変更に使用されたツールが実行されている場所によって変更が有効になるタイミングが異なります。

アプリケーションとツールの両方が同じホスト上および同一ドメインで実行されている場合、変更は即座に有効化されます。
同じではなく、アプリケーションとツールが別のホストまたは別のドメインで実行されている場合は、ストア・キャッシュのリフレッシュ後に変更が有効になります。キャッシュのリフレッシュの頻度は、プロパティoracle.security.jps.ldap.policystore.refresh.intervalの値によって決まります。デフォルト値は10分です。

ドメイン内で、WLSTコマンドまたはFusion Middleware Controlを使用して有効になった変更はすべて、最初は管理サーバーのみで考慮され、サーバーの再起動時のみにドメイン内のすべての管理対象サーバーにプッシュされます。

10.4.1 例

次の使用例は、セキュリティ・アーティファクトの変更に(別のドメインまたはホストの)Oracle Entitlements Serverを使用し、oracle.security.jps.policystore.refresh.intervalプロパティを10分に設定した場合の4つのシナリオにおける認可の動作を示しています。

この使用例では次のように想定しています。

ユーザーはエンタープライズ・ロールのメンバー
このエンタープライズ・ロールは、アプリケーション・ロールのメンバーに含まれている
このアプリケーション・ロールにはアプリケーション機能の一部を制御するパーミッションが付与されている

前述の想定に従って、次の4つのシナリオにおける認可の結果を調べます。

シナリオA

ユーザーがアプリケーションにログインします。
ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。
別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。
ユーザーはアプリケーションからログアウトして、ただちにログインしなおします。
ユーザーは、この時点でもアプリケーション・ロールによって保護された機能にアクセスできます。

この結果の理由は、ポリシー・キャッシュで、まだ前述のステップ3で実施された変更を反映するリフレッシュが行われていないためです。

シナリオB

ユーザーがアプリケーションにログインします。
ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。
別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。
ユーザーはアプリケーションからログアウトして、10分後にログインしなおします。
ユーザーは、アプリケーション・ロールによって保護された機能にアクセスできなくなっています。

この結果の理由は、ポリシー・キャッシュで、前述のステップ3で実施された変更を反映するリフレッシュが行われているためです。

シナリオC

ユーザーがアプリケーションにログインします。
ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。
別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。
ユーザーがログアウトしない場合、10分以内はアプリケーション・ロールによって保護された機能へのアクセスが可能な状態に保持されます。

この結果の理由は、ポリシー・キャッシュで、まだ前述のステップ3で実施された変更を反映するリフレッシュが行われていないためです。

シナリオD

ユーザーがアプリケーションにログインします。
ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。
別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。
ユーザーがログアウトせずに、10分より長く待ってからアプリケーション・ロールによって保護された機能へのアクセスを試行します。アクセスは拒否されます。

この結果の理由は、ポリシー・キャッシュで、前述のステップ3で実施された変更を反映するリフレッシュが行われているためです。

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

一部のWLSTコマンドでは、操作に使用するロールのプリンシパル名とプリンシパル・クラスを指定する必要があります。

たとえば、次の呼出しでは、アプリケーション・ストライプがmyAppで名前がmyAppRoleであるロールにプリンシパルが追加されます。

grantAppRole.py -appStripe myApp -appRoleName myAppRole 
                -principalClass myPrincipalClass -principalName myPrincipal

このようなスクリプトでプリンシパルが認証ロールまたは匿名ロールを参照する場合、プリンシパル名とプリンシパル・クラスは固定されており、次のペアのいずれかである必要があります。

認証ロール
- 名前: authenticated-role
- クラス: oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl
匿名ロール
- 名前: anonymous-role
- クラス: oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl

前述のプリンシパル名とクラスの指定が必要なWLSTコマンドは次のとおりです。

grantAppRole
revokeAppRole
grantPermission
revokePermission
listPermissions

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

一部のWLSTコマンドでは、アプリケーション・ストライプの指定が必要です。アプリケーションがバージョン付きではない場合は、アプリケーション・ストライプがデフォルトのアプリケーション名として使用されます。アプリケーションがバージョン付きの場合は、アプリケーション名とアプリケーション・ストライプが同じではなくなります。

たとえば、myAppというバージョン付きアプリケーションのバージョン1の名前は、「Fusion Middleware Control」ページでmyApp(v1.0)と表示されますが、このアプリケーションのアプリケーション・ストライプはmyApp#v1.0です。

一般に、表示名がappName(vers)のアプリケーションでは、アプリケーション・ストライプがappName#versになります。次の起動に示すように、WLSTコマンドでアプリケーション・ストライプとして渡す必要があるのは、この最後の文字列です。

>listAppRoles myApp#v1.0

ストライプを指定できるWLSTコマンドは次のとおりです。

createAppRole
deleteAppRole
grantAppRole
revokeAppRole
listAppRoles
listAppRoleMembers
grantPermission
revokePermission
listPermissions
deleteAppPolicies

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

Oracle Entitlements Serverを使用すると、WebLogicドメインのOracle Internet Directoryでアプリケーション・ポリシーおよびその他のセキュリティ・アーティファクトの管理および検索を実行できます。

詳細は、Oracle Fusion Middleware Oracle Entitlements Server管理者ガイドの次のトピックを参照してください。

セキュリティ・アーティファクトの問合せ
ポリシーおよびロールの管理