プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Platform Security Servicesによるアプリケーションの保護
12c (12.1.3)
E59413-03
  目次へ移動
目次

前
 
次
 

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

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

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

10.1 ドメイン・セキュリティ・ストアの特性の確認

管理者はWLSTのオフライン・コマンドlistSecurityStoreを使用して、ドメイン・セキュリティ・ストアの属性の一部を確認できます。このコマンドの詳細は、「listSecurityStoreInfo」を参照してください。

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

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

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

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


重要ポイント1:

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

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

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



重要ポイント2:

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

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

  • ポリシーのプロビジョニング時に、管理者は、ポリシーで使用するユーザーおよびグループの名前に、アイデンティティ・リポジトリに記録されているその名前とまったく同じ文字構成を使用します。これによって、ユーザー名またはグループ名を指定した問合せをポリシー・ストアに対して実行すると、想定したとおりに機能します。

  • 実行時にユーザー名を入力するときに、エンドユーザーは、アイデンティティ・リポジトリで指定されている大文字/小文字の組合せと完全に一致する名前を入力します。これによって、予期したとおりにユーザーが認可されます。

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



重要ポイント3:

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

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



重要ポイント4:

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

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


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

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

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

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

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


注意:

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

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

    emapppols.gifについては周囲のテキストで説明しています。

    「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。

  2. 指定したプリンシパルまたはパーミッションに一致するアプリケーションのポリシーを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、基準にする文字列(プリンシパル名、プリンシパル・グループまたはアプリケーション・ロール)を入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

  3. 選択したアプリケーション・ストライプのアプリケーション・ポリシーを作成するには、「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。ここで、作成する権限に対するプリンシパルおよびパーミッションを追加します。

    1. パーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログ・ボックスを表示します。

      そのダイアログ・ボックスの「検索」領域で、まず「権限」または「リソース・タイプ」を選択します。「権限」を選択した場合は、クラスまたはリソース名に一致するパーミッションを指定し、「権限クラス」および「リソース名」を指定します。「リソース・タイプ」を選択した場合は、タイプ名に一致するリソース・タイプを指定し、タイプを指定します。「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したパーミッションが、「権限」領域の表に表示されます。

    2. プリンシパルを追加するには、「権限受領者」領域の「追加」ボタンをクリックして、「プリンシパルの追加」ダイアログ・ボックスを表示します。

      そのダイアログ・ボックスの「検索」領域で、「タイプ」を選択し、プリンシパル名または表示名に一致させる文字列を入力して、青いボタンをクリックします。問合せの結果が「検索済プリンシパル」表に表示されます。その表から1つ以上の行を選択し、「OK」をクリックして「アプリケーション権限の作成」ページに戻ります。選択したプリンシパルが、「権限受領者」領域の表に表示されます。

    3. 「権限受領者」領域の表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。

    4. 完了したら、「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。作成したポリシーのプリンシパルとパーミッションがページの下部の表に表示されます。

  4. 既存のアプリケーション・ポリシーに基づいてアプリケーション・ポリシーを作成する手順は、次のとおりです。

    1. 表から既存のポリシーを選択します。

    2. 「類似作成」をクリックし、「アプリケーション権限の類似作成」ページを表示します。このページでは、選択したポリシーから抽出されたデータがパーミッションの表に自動的に入力されます。

    3. 前述の手順3の下位手順の説明に従い、必要に応じてこれらの値を変更し、「OK」をクリックします。

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

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

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

    emapproles.gifについては周囲のテキストで説明しています。

    「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。

  2. アプリケーションのロールを表示するには、「検索」領域を開き、検索対象のアプリケーション・ストライプを選択し、ロール名に一致させるデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

  3. アプリケーション・ロールを作成するには、「作成」をクリックして、「アプリケーション・ロールの作成」ページを表示します。すべての領域に一度にデータを入力する必要はありません。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後から指定できます。同様に、ロール・マッピングに対するデータを後で入力することもできます。

    領域「一般」で、作成するロールの次の属性を指定します。

    1. 「ロール名」テキスト・ボックスにロールの名前を入力します。

    2. 必要に応じて、ロールに表示する名前を「表示名」テキスト・ボックスに入力します。

    3. オプションで、「説明」テキスト・ボックスに、ロールの説明を入力します。

    「メンバー」領域で、作成するロールのマップ先とするユーザーまたはグループを指定します。マップ先とする他のアプリケーション・ロールがある場合は、それを指定します。

    作成するアプリケーション・ロールにアプリケーション・ロールを追加する手順は、次のとおりです。

    1. 「追加」をクリックして、「プリンシパルの追加」ダイアログを表示します。

    2. このダイアログで、「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名に一致させる文字列を入力して、青いボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。その表から1つ以上のプリンシパルを選択します。

    3. 完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したアプリケーション・ロールが「メンバー」表に表示されます。

  4. 「メンバー」表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。

  5. 「OK」をクリックし、ロールの作成(または更新)を完了し、「アプリケーション・ロール」ページに戻ります。作成したロールがそのページの下部の表に表示されます。

  6. 既存のアプリケーション・ロールに基づいてアプリケーション・ロールを作成する手順は、次のとおりです。

    1. 表から既存のロールを選択します。

    2. 「類似作成」をクリックし、「アプリケーション・ロールの類似作成」ページを表示します。このページでは、選択したロールから抽出されたデータが一部のデータに自動的に入力されます。

    3. ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。

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

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

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

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

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

    emsyspols.gifについては周囲のテキストで説明しています。

    「ポリシー・ストア・プロバイダ」領域は読取り専用であり、この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。

  2. 指定したタイプ、名前およびパーミッションと一致するシステム・ポリシーを表示するには、「検索」領域を開き、一致対象のデータを入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。

  3. 「編集」ボタンをクリックすると、選択したポリシーの特性をいつでも編集できます。リストからポリシーを削除するには、「削除」ボタンをクリックします。

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

  1. 「作成」をクリックして、「システム権限の作成」ページを表示します。

  2. 作成するポリシーのタイプとして、「プリンシパル」または「コードベース」を選択します。選択したタイプによってUIが多少異なります。次の手順は、「プリンシパル」を選択した場合に対するものです。

  3. パーミッションを追加するには、「権限」領域の「追加」ボタンをクリックして、「権限の追加」ダイアログ・ボックスを表示し、作成しているポリシーに追加するパーミッションを選択します。

    1. 「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。検索結果が「検索」領域の表に表示されます。

    2. 追加するパーミッションを選択するには、表からパーミッションを選択します。パーミッションを選択すると、その詳細が読取り専用の「カスタマイズ」領域に表示されます。

    3. 「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したパーミッションが、「権限」の表に追加されます。

  4. 「パーミッション」表からパーミッションを選択し、「編集」ボタンを使用すると、パーミッションの特性をいつでも変更できます。リストからパーミッションを削除するには、「削除」ボタンを使用します。

  5. 「OK」をクリックして、「システム・ポリシー」ページに戻ります。

  6. 「コードベースに関する権限」領域の表は読取り専用であり、コードベース・システム・ポリシーに関連付けられているリソース名、アクションおよびパーミッション・クラスを示します。

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

オンライン・コマンドとは、実行中のサーバーとの接続が必要なコマンドです。特に指定がないかぎり、この項に記載されたスクリプトはオンライン・スクリプトで、タイプがファイル、OID、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には、アプリケーション・ポリシーの管理に使用できる次のコマンドが用意されています(特に指定がないかぎりコマンドはすべてオンラインです)。

  • 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.6項「WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与」を参照してください。

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

10.4.1 reassociateSecurityStore

コマンドreassociateSecurityStoreは、ソース・ストアからターゲット・ストアにOPSSセキュリティ・ストアを移行し、jps-config.xmlファイルおよびjps-config-jse.xmlファイル内のサービス構成をターゲット・リポジトリにリセットします。

ソース・ストアは、ファイルベース、OIDベースまたはDBベース・ストアのいずれかです。ターゲット・ストアには、まったく新しいストア、または他のドメインにある既存のストア(後述のオプションの引数joinを参照)を使用できます。既存のストアの場合、結合したターゲット・ストアにソース・ストアのデータを追加するかどうかを指定できます(後述のオプションの引数migrateを参照)。

ソース・ストアのバージョンは、ターゲット・ストアのバージョンと同じかまたはそれ以降である必要があります。バージョンが異なる場合(つまり、ソースのバージョンがターゲットのバージョンよりも新しい場合)、コマンドはソースとターゲットのセキュリティ・アーティファクトの間の互換性チェックを行います。アーティファクトのいずれかでチェックがエラーとなった場合、コマンドは互換性のないアーティファクトの移行をスキップできるように、引数skipをtrueに設定します。この引数がtrueに設定されていないときに互換性のないアーティファクトが検出されると、コマンドはそこで終了します。

このコマンドはブートストラップ資格証明をリセットします(後述の引数adminおよびpasswordを参照)。ブートストラップ資格証明をリセットする別の方法については、WLSTコマンドのmodifyBootStrapCredentialaddBootStrapCredentialを参照してください。

再関連付けに関連する推奨事項は、「重要ポイント」を参照してください。このコマンドは、インタラクティブ・モードでのみサポートされます。


注意:

指定されたドメインと、指定されたメジャー・リリース(11gまたは12c)で、OPSSバイナリのバージョンはOPSSセキュリティ・ストアのバージョンと同じか、またはそれ以降である必要があります。第J.9.1項「バイナリとポリシー・ストアのバージョンの非互換性」を参照してください。

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

コマンド構文は、ターゲット・ストアのタイプに応じて若干異なります。ターゲットがOIDベース・ストアの場合は、次の構文を使用します(見やすくするために各引数をそれぞれ別の行に記述しています)。

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

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

reassociateSecurityStore(domain="domainName", 
       servertype="DB_ORACLE", 
       datasourcename="datasourceName", 
       jpsroot="jpsRoot",
       jdbcurl="jdbcURL",
       jdbcdriver="jdbcDriverClass",
       dbUser="dbUserName",
       dbPassword="dbPassword",
       [admin="adminAccnt", password="passWord",]
       [,join="trueOrfalse" 
          [,keyFilePath="dirLoc", keyFilePassword="password"]                         [,migrate="trueOrfalse" [,skip="trueOrfalse"]]])
       [odbcdsn="odbcDsnSting"]
       [migrate="trueOrfalse"]
       [skip="trueOrfalse"])

次に、引数joinmigateおよびskipの使用に関する要点をまとめます。

  • 引数migratejoinがtrueに設定されている場合のみ使用され、それ以外の場合は無視されます。したがって、移行が必要である場合は、joinmigrateの両方をtrueに設定する必要があります。

  • joinmigrateが両方ともtrueに設定されている場合、引数keyFilePathkeyFilePasswordは必須です。

  • joinmigrateの両方がtrueに設定されているときに、skipがtrueの場合、ターゲット・ストアと互換性のないアーティファクトの移行はスキップされます。skipがfalse(デフォルト値)の場合、互換性のないアーティファクトが検出されるとコマンドはそこで終了します。このリリースでは、汎用資格証明のみ、スキップがサポートされています。

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

  • domain: WebLogicでは、ターゲット・ストアが配置されているドメイン名を指定します。

  • adminでは、OIDターゲットの場合、ターゲット・サーバーに対する管理者のユーザー名を指定します。形式はcn=usrNameです。

    DBターゲットの場合は、DBに保護データ・ソースがある(つまり、ユーザー/パスワードで保護されている)場合にのみ必要です。この場合、データ・ソースが作成されたときにデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。指定した場合は、passwordも指定する必要があります。

  • passwordでは、引数adminに関連付けられているパスワードを指定します。OIDターゲットの場合にのみ必要です。

    DBターゲットの場合は、DBに保護データ・ソースがある場合にのみ必要で、当該の場合は引数adminで指定されたユーザーに関連付けられたパスワードを指定します。指定した場合は、adminも指定する必要があります。

  • ldapurlでは、OIDサーバーのURIを指定します。デフォルトのポートを使用する場合の形式は、ldap://host:portです。匿名SSLまたは一方向SSL伝送を使用する場合の形式は、ldaps://host:portです。目的のSSL接続モードを扱うことができるようにセキュア・ポートを構成する必要があります。また、このセキュア・ポートは、デフォルトの(セキュアではない)ポートとは別のポートとする必要があります。

  • servertypeでは、ターゲット・ストアの種類を指定します。有効なタイプは、OIDまたはDB_ORACLEのみです。

  • jpsrootでは、ターゲットOIDリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。

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


    注意1:

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

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

    たとえば、Domain1にセキュリティ・ストアがあるときに、joinをtrueに指定して、Domain2をDomain1のセキュリティ・ストアに再度関連付けした場合は次の手順を実行します。

    1. WLSTコマンドexportEncryptionKeyを使用して、Domain1からewallet.p12ファイルにキーを抽出します。渡された引数keyFilePasswordの値は、後でそのキーを2つ目のドメインにインポートするときに使用する必要があります。

    2. WLSTコマンドimportEncryptionKeyを使用して、抽出されたewallet.p12をDomain2にインポートします。引数keyFilePasswordの値は、ewallet.p12ファイルの生成時に使用されたものと同じにする必要があります。

    3. Domain2のサーバーを再起動します。

    キーのインポートやエキスポートに使用するコマンドの詳細は、exportEncrytionKeyとimportEncryptionKeyを参照してください。


  • migratejoinがtrueに設定されている場合のみ有効で、それ以外の場合は無視されます。migrateは結合したストアにソース・ストア内のデータを追加するかどうかを表します。ソース・データをターゲット・ストアに追加する場合はtrue、ソース・データを追加せずにターゲット・ストアに結合する場合はfalseに設定します。オプション。指定しなかった場合は、デフォルトでFalseに設定されます。

  • skipjoinmigrateの両方がtrueに設定されている場合のみ有効で、それ以外の場合は無視されます。skipは互換性のないアーティファクトの移行をスキップするかどうかを表します。互換性のないアーティファクトをターゲット・ストアに追加し、コマンドの実行をそのまま続ける場合はtrue、ソース・ストアで互換性のないアーティファクトを検出したときにコマンドを終了する場合はfalseに設定します。オプション。指定しなかった場合は、デフォルトでfalseに設定されます。

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

  • keyFilePathでは、ターゲット・ドメインのewallet.p12ファイルの配置先ディレクトリを指定します。このファイルの内容は、keyFilePasswordに渡される値により暗号化され、保護されます。joinがtrueに設定されている場合のみ必須です。


    注意2:

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

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

    引数keyFilePathおよびkeyFilePasswordを使用すると、コマンドreassociateSecurityStoreにより、キーのエクスポートおよびインポートが自動的に行われます。

    たとえば、Domain1にセキュリティ・ストアがあるときに、joinをtrueに指定し、keyFile引数を使用して、Domain2をDomain1のセキュリティ・ストアに再度関連付けする場合は次の手順を実行します。

    1. 適切な引数値を指定して、コマンドreassociateSecurityStoreを実行します。

    2. Domain2のサーバーを再起動します。


  • keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。joinがtrueに設定されている場合のみ必須です。

  • jdbcurlでは、Java SEアプリケーションでデータベースへの接続に使用するJDBC URLを指定します。Java SEアプリケーションにのみ適用されます。必須。引数jdbcdriverdbUserおよびdbPasswordとともに使用する必要があります。

  • jdbcdriverでは、データベースへの接続に使用するJDBCドライバのクラスを指定します。必須。引数jdbcurlとともに使用する必要があります。

  • dbUserでは、ブートストラップ資格証明に追加する資格証明ストア内のデータベース・ユーザーを指定します。必須。引数jdbcurlとともに使用する必要があります。

  • dbPasswordでは、dbUserを使用して指定したユーザーのパスワードを指定します。必須。引数jdbcurlとともに使用する必要があります。

  • odbcdsnでは、C CSF APIで使用するODBC DSN名を指定します。Cプログラムにのみ適用されます。

使用例

次のコードは、DBベースのセキュリティ・ストアを再度関連付けるための呼出しの例です。

reassociateSecurityStore(domain="farm", servertype="DB_ORACLE", 
jpsroot="cn=jpsroot", datasourcename="jdbc/opssds", 
jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb", 
dbUser="test_opss", dbPassword="mypass", 
jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource")

ソース・セキュリティ・ストアの内容を移行せずにotherDomain内のOPSSセキュリティ・ストアを共有するには、次の例のようにコマンドを呼出します。

reassociateSecurityStore(domain="otherDomain", servertype="DB_ORACLE", 
jpsroot="cn=jpsroot", datasourcename="jdbc/opssds", 
jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",dbUser="test_opss", 
dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", 
join="true", keyFilePath="/tmp/myFileDirectory", keyFilePassword="password") 

otherDomain内のOPSSセキュリティ・ストアを共有し、互換性のないアーティファクトをスキップしながら、ソース・セキュリティ・ストアの内容をDBベースのターゲット・セキュリティ・ストアに移行するには、次の例のようにコマンドを呼出します。

reassociateSecurityStore(domain="otherDomain", servertype="DB_ORACLE", 
jpsroot="cn=jpsroot", datasourcename="jdbc/opssds", 
jdbcurl="jdbc:oracle:thin:@myhost.oracle.com:5555:testdb",dbUser="test_opss", 
dbPassword="mypass", jdbcdriver="oracle.jdbc.xa.client.OracleXADataSource", 
join="true", migrate="true", skip="true", 
keyFilePath="/tmp/myFileDirectory", keyFilePassword="password") 

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

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

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

  • アプリケーションとツールの両方が同じホスト上および同一ドメインで実行されている場合、変更は即座に有効化されます。

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

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

10.5.1

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

このケースの前提は次のとおりです。

  • ユーザーはエンタープライズ・ロールのメンバー

  • このエンタープライズ・ロールは、アプリケーション・ロールのメンバーに含まれている

  • このアプリケーション・ロールにはアプリケーション機能の一部を制御するパーミッションが付与されている

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

シナリオA

  1. ユーザーがアプリケーションにログインします。

  2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

  3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

  4. ユーザーはアプリケーションからログアウトして、ただちにログインしなおします。

  5. ユーザーは、この時点でもアプリケーション・ロールによって保護された機能にアクセスできます。

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

シナリオB

  1. ユーザーがアプリケーションにログインします。

  2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

  3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

  4. ユーザーはアプリケーションからログアウトして、10分後にログインしなおします。

  5. ユーザーは、アプリケーション・ロールによって保護された機能にアクセスできなくなっています。

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

シナリオC

  1. ユーザーがアプリケーションにログインします。

  2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

  3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

  4. ユーザーがログアウトしない場合、10分以内はアプリケーション・ロールによって保護された機能へのアクセスが可能な状態に保持されます。

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

シナリオD

  1. ユーザーがアプリケーションにログインします。

  2. ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。

  3. 別のホスト(またはドメイン)から、Oracle Entitlements Serverを使用してアプリケーション・ロールからエンタープライズ・ロールを削除します。

  4. ユーザーがログアウトせずに、10分より長く待ってからアプリケーション・ロールによって保護された機能へのアクセスを試行します。アクセスは拒否されます。

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

10.6 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.7 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.8 Oracle Entitlements Serverを使用したアプリケーション・ポリシーの管理

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

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

  • セキュリティ・アーティファクトの問合せ

  • ポリシーおよびロールの管理