ポリシーの管理

10 ポリシーの管理

この章では、Oracle Enterprise Manager Fusion Middleware Control (Fusion Middleware Control)、WebLogic Scripting Tool (WLST)およびOracle Entitlements Server (OES)を使用してポリシーを管理する方法について説明します。

この章の内容は次のとおりです。

親トピック: OPSSサービス

セキュリティ・ストアの特性の確認

listSecurityStoreInfo WLSTコマンドを使用して、セキュリティ・ストアの属性をいくつか確認します。このコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のlistSecurityStoreInfoを参照してください。

親トピック: ポリシーの管理

ポリシー・ストアの管理

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

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

ユーザー名を変更する場合にも、同様の考え方が当てはまります。認可が変更後のデータでも予期したとおりに機能するように、古いデータを参照するポリシー(権限付与、パーミッション、グループ)をすべて更新する必要があります。
ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。次のことをお薦めします:
- ポリシーのプロビジョニング時に、ポリシーで使用するユーザーおよびグループの名前の文字構成をアイデンティティ・ストアでの文字構成とまったく同じにします。
- 実行時にユーザー名を入力する際には、アイデンティティ・ストアでの大文字/小文字の組合せと完全に一致する名前を入力します。
リソース・タイプ、リソースまたは権限の名前には印刷可能文字のみを使用でき、先頭または末尾に空白を使用することはできません。
デフォルトでは、認可の失敗がコンソールに表示されません。認可の失敗(JpsAuth.checkPermissionの失敗など)がコンソールに表示されるようにするには、システム変数jps.auth.debugをtrueに設定します。

次の各項では、Fusion Middleware Control、WLSTおよびOESを使用してポリシーを管理する方法について説明します。代表的な操作は:

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

Fusion Middleware Controlでは、次の各項で説明しているように、WebLogic Serverドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理することができます。

親トピック: ポリシーの管理

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

この項に記載されている手順に従って、Fusion Middleware Controlを使用してアプリケーション・ポリシーを管理します。

タスク1: 「アプリケーション・ポリシー」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ポリシー」の順に移動します。「アプリケーション・ポリシー」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: アプリケーション・ポリシーの検索

「検索」領域で、アプリケーション・ストライプを選択し、(プリンシパル名、プリンシパル・グループまたはアプリケーション・ロールと)照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。

タスク3: アプリケーション・ポリシーの作成

アプリケーション・ストライプを選択して、「作成」をクリックします。「アプリケーション権限の作成」ページが表示されます。このページで、必要に応じてプリンシパルおよびパーミッションを権限付与に追加します。

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

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

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

タスク4: 別のアプリケーション・ポリシーに似たアプリケーション・ポリシーの作成

ポリシーを選択します。
「類似作成」をクリックします。アプリケーション権限の類似作成ページが表示され、選択したポリシーから抽出されたデータがパーミッションの表に入力されます。
必要に応じて値を変更して「OK」をクリックします。

親トピック: Fusion Middleware Controlを使用したポリシーの管理

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

この項に記載されている手順に従って、Fusion Middleware Controlを使用してアプリケーション・ロールを管理します。

タスク1: 「アプリケーション・ロール」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ロール」の順に移動します。「アプリケーション・ロール」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: アプリケーション・ロールの検索

「検索」領域で、アプリケーション・ストライプを選択し、照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。

タスク3: アプリケーション・ロールの作成

「作成」をクリックして「アプリケーション・ロールの作成」ページを表示します。

このページでは、データを一度に全部入力する必要はありません。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後で指定できます。同様に、後でロール・マッピングを指定することもできます。

「一般」領域で、次の情報を入力します。

「ロール名」テキスト・フィールドに、ロールの名前を入力します。
「表示名」テキスト・フィールドに、ロールに表示する名前を入力します(オプション)。
「説明」テキスト・フィールドに、ロールの説明を入力します(オプション)。
「メンバー」領域で、ロールのマップ先とするユーザー、グループまたは他のアプリケーション・ロールを指定します。

タスク4: ロールへのアプリケーション・ロールの追加

ロールを選択し、「追加」をクリックします。「プリンシパルの追加」ダイアログが表示されます。
「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名と照合する文字列を入力して検索ボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。この表からプリンシパルを1つ以上選択します。
ロールを追加するプリンシパルを1つ以上選択します。
「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。新しいアプリケーション・ロールが「メンバー」表に表示されます。

タスク5: 別のアプリケーション・ロールに似たアプリケーション・ロールの作成

ロールを選択します。
「類似作成」をクリックします。アプリケーション・ロールの類似作成ページが表示され、選択したロールから抽出されたデータが一部のエントリに入力されます。
ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。

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

親トピック: Fusion Middleware Controlを使用したポリシーの管理

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

この項に記載されている手順に従って、Fusion Middleware Controlを使用してシステム・ポリシーを管理します。

タスク1: 「システム・ポリシー」ページのオープン

Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「システム・ポリシー」の順に移動します。「システム・ポリシー」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。

タスク2: システム・ポリシーの検索

「検索」領域で、タイプを選択し、照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。

タスク3: システム・ポリシーの作成

「作成」をクリックします。「システム権限の作成」ページが表示されます。
作成するポリシーのタイプとして、「プリンシパル」または「コードベース」を選択します。次のステップは、「プリンシパル」を選択した場合のものです。
パーミッションを追加するには、「追加」ボタンをクリックします。「権限の追加」ダイアログが表示されます。作成しているポリシーに追加するパーミッションを選択します。
- 「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。検索結果が「検索」領域の表に表示されます。
- 追加するパーミッションを選択します。詳細が読取り専用の「カスタマイズ」領域に表示されます。
- 「OK」をクリックして、「システム権限の作成」ページに戻ります。パーミッションが「権限」表に表示されます。
「OK」をクリックして、「システム・ポリシー」ページに戻ります。
「コードベースに関する権限」領域の表は読取り専用であり、新しいシステム・ポリシーに関連付けられているリソース名、アクションおよびパーミッション・クラスが表示されます。

親トピック: Fusion Middleware Controlを使用したポリシーの管理

WLSTを使用したポリシーの管理

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

読取り専用コマンドは、WebLogic ServerグループMonitor、Operator、ConfiguratorまたはAdminに属するユーザーのみが実行できます。読取り/書込みコマンドは、WebLogic ServerグループAdminまたはConfiguratorに属するユーザーのみが実行できます。すべてのコマンドは、Oracle WebLogic Serverをインストールすると使用できます。

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。「migrateSecurityStoreを使用したセキュリティ・ストアの移行」を参照してください。

reassociateSecurityStore

reassociateSecurityStore WLSTコマンドは、セキュリティ・ストアをソース・ストアからターゲット・ストアに移行し、jps-config.xmlファイルとjps-config-jse.xmlファイルでサービス構成をターゲット・リポジトリに再設定します。このコマンドは、インタラクティブ・モードでのみサポートされます。

ソース・ストアは、ファイル、LDAPまたはDBのいずれかのセキュリティ・ストアです。ターゲット・ストアは、新しいストアでも他のドメインにある既存のストア(後述のオプションのjoin引数を参照)でもかまいません。ターゲット・ストアが他のドメインにあるストアの場合、ソース・データをターゲット・ストアに追加するかどうかを指定します(後述のオプションのmigrate引数を参照)。

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

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

コマンド構文

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

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"])

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

migrate引数が意味を持つのはjoinがtrueである場合のみです。それ以外の場合は、無視されます。したがって、移行が必要である場合は、joinとmigrateの両方をtrueに設定する必要があります。
joinとmigrateが両方ともtrueである場合、引数keyFilePathおよびkeyFilePasswordは必須です。
join引数とmigrate引数がいずれもtrueであるときに、skipがtrueの場合、ターゲット・ストアと互換性のないアーティファクトの移行はスキップされます。skipがfalseの場合、互換性のないアーティファクトが検出されるとコマンドは終了します。スキップがサポートされているのは、汎用の資格証明に対してのみです。

引数の説明は、次のとおりです。

domain: ターゲット・ストアが配置されているドメイン名を指定します。
adminでは、LDAPターゲットの場合、ターゲット・サーバーでの管理者のユーザー名を指定します。形式はcn=usrNameです。

DBセキュリティ・ストアの場合は、ユーザーおよびパスワードで保護されているデータ・ソースがデータベースにあるときのみ必要です。その場合、この引数ではデータ・ソースの作成時にデータ・ソースを保護するために設定されたユーザー名を指定します。そのユーザーとパスワードは、ブートストラップ資格証明ストアに存在する必要があります。指定した場合は、passwordも指定する必要があります。
passwordでは、adminで指定したユーザーに関連付けられているパスワードを指定します。LDAPターゲットの場合にのみ必要です。

DBセキュリティ・ストアの場合は、保護されているデータ・ソースがデータベースにあるときのみ必要です。その場合、adminで指定したユーザーに関連付けられているパスワードを指定します。指定した場合は、adminも指定する必要があります。
ldapurlでは、LDAPサーバーのURIを指定します。形式は、デフォルトのポートを使用している場合はldap//host:port、匿名Secure Sockets Layer (SSL)または一方向SSLを使用している場合はldaps://host:portを使用します。セキュア・ポートは、目的のSSL接続モードを処理するように構成し、デフォルトの(セキュアではない)ポートとは別のポートにする必要があります。
servertypeでは、ターゲット・ストアの種類を指定します。有効なタイプは、OIDまたはDB_ORACLEです。
jpsrootでは、ターゲットLDAPリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。
joinでは、ターゲット・ストアが他のドメインにあるストアであるかどうかを指定します。オプション。他のドメインにあるターゲット・ストアを共有する場合は、trueに設定します。それ以外の場合は、falseに設定します。指定しない場合は、デフォルトのfalseに設定されます。この引数を使用すると、複数のWebLogic Serverドメインで同じセキュリティ・ストアを指すことができるようになりますが、次の点に注意してください。
- セキュリティ・ストアへの結合がサポートされるのは、新しいドメインを作成する場合のみです。
- 2つのドメインにある異なる2つのセキュリティ・ストアのマージはサポートされていません。
- joinがtrueの場合、OPSS暗号化キーを一方のドメインからエクスポートして他方のドメインにインポートする必要があります。
ノート:

暗号化キーをエクスポートしてインポートするには、次の手順を実行します。代替手順については、keyFilePath引数を参照してください。

Domain1にセキュリティ・ストアがあり、joinをtrueに設定してDomain2がDomain1のセキュリティ・ストアに再関連付けされたとします。次のコマンドを実行します:
1. exportEncryptionKey WLSTコマンドを使用して、Domain1からewallet.p12ファイルにキーを抽出します。渡されたkeyFilePassword引数の値は、後でそのキーを2つ目のドメインにインポートするときに使用する必要があります。
2. importEncryptionKey WLSTコマンドを使用して、抽出したewallet.p12ファイルをDomain2にインポートします。keyFilePassword引数の値は、ewallet.p12ファイルの生成時に使用したものと同一である必要があります。
3. Domain2のサーバーを再起動します。
エクスポートおよびインポートのコマンドの詳細は、『インフラストラクチャ・セキュリティWLSTコマンド・リファレンス』のexportEncrytionKeyおよびimportEncryptionKeyを参照してください。
migrateが意味を持つのはjoinがtrueである場合のみで、それ以外の場合は無視されます。結合したストアにソース・ストアのデータを追加するかどうかを指定します。ソース・データをターゲット・ストアに追加する場合はtrueに設定します。ソース・データを追加せずにターゲット・ストアに結合する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。
skipが意味を持つのはjoinとmigrateの両方がtrueである場合のみで、それ以外の場合は無視されます。互換性のないアーティファクトの移行をスキップするかどうかを指定します。ターゲット・ストアへの互換性のないアーティファクトの追加をスキップしてコマンドを終了しない場合はtrueに設定します。ソース・ストアで互換性のないアーティファクトが検出されたときにコマンドを終了する場合はfalseに設定します。オプション。指定しない場合は、デフォルトのfalseに設定されます。
datasourcenameでは、Java Database Connectivity (JDBC)データ・ソースのJava Naming and Directory Interface (JNDI)名を指定します。この値は、データ・ソースの作成時に入力したJNDI名データ・ソースの値と同一である必要があります。
keyFilePathでは、ターゲット・ドメインのewallet.p12ファイルが配置されているディレクトリを指定します。このファイルの内容は、keyFilePasswordに渡される値により暗号化され、保護されます。joinがtrueである場合のみ必須です。

joinがtrueの場合、暗号化キーを一方のドメインからエクスポートして他方にインポートする必要があります。これらのタスクは、keyFilePath引数とkeyFilePassword引数を使用すると、自動的に実行されます。

Domain1にセキュリティ・ストアがあり、joinをtrueに設定し、keyFileの引数を使用してDomain2がDomain1のセキュリティ・ストアに再関連付けされているとします。その場合、まず適切な引数値を指定してreassociateSecurityStore WLSTコマンドを実行し、次にDomain2のサーバーを再起動します。暗号化キーをエクスポートしてインポートする代替手順については、join引数の説明のノートを参照してください。
keyFilePasswordでは、ewallet.p12ファイルを保護するためのパスワードを指定します。joinがtrueである場合のみ必須です。
jdbcurlでは、Java SEアプリケーションでデータベースへの接続に使用するJDBC URLを指定します。Java SEアプリケーションにのみ適用されます。必須。jdbcdriver、dbUserおよびdbPasswordの各引数とともに使用する必要があります。
jdbcdriverでは、データベースへの接続に使用するJDBCドライバのクラスを指定します。必須。jdbcurl引数とともに使用する必要があります。
dbUserでは、ブートストラップ資格証明に追加する(資格証明ストア内の)データベース・ユーザーを指定します。必須。jdbcurl引数とともに使用する必要があります。
dbPasswordでは、dbUserを使用して指定したユーザーのパスワードを指定します。必須。jdbcurl引数とともに使用する必要があります。
odbcdsnでは、C資格証明ストア・フレームワークAPIで使用するOpen Database Connectivity (ODBC)データ・ソース名を指定します。Cプログラムにのみ適用されます。

再関連付けの例

次の例では、DBセキュリティ・ストアに再関連付けする方法を示します。

reassociateSecurityStore(domain="targetDomain", 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内のセキュリティ・ストアを共有するには、次のようにします。

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内のセキュリティ・ストアを共有し、互換性のないアーティファクトをスキップしながら、ソース・セキュリティ・ストアの内容をターゲット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")

親トピック: WLSTを使用したポリシーの管理

ポリシー・キャッシュのリフレッシュ

このトピックは、LDAPセキュリティ・ストアとDBセキュリティ・ストアにのみ適用されます。ファイル・ストアの場合、キャッシュは数秒後に更新されます。

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

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

ドメイン内で、WLSTまたはFusion Middleware Controlを使用して加えられた変更はいずれも、最初は管理サーバーでのみ考慮されます。サーバーの再起動時にのみ、その変更はドメイン内のすべての管理対象サーバーにプッシュされます。

ポリシー・リフレッシュを使用した認可のシナリオ

親トピック: ポリシーの管理

ポリシー・リフレッシュを使用した認可のシナリオ

次の使用例では、セキュリティ・データの変更に(別のドメインまたはホストの)OESを使用し、oracle.security.jps.ldap.policystore.refresh.intervalプロパティを10分に設定した場合のシナリオにおける認可の動作を示します。

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

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

次のシナリオを考えてみます。

ユーザーがアプリケーションにログインします。
ユーザーがアプリケーション・ロールによって保護された機能にアクセスします。
別のホスト(またはドメイン)から、エンタープライズ・ロールをアプリケーション・ロールから削除します。

続いて、次のアクションと結果を考えてみます。

ユーザーはアプリケーションからログアウトして、ただちにログインしなおします。ステップ3で加えた変更でポリシー・キャッシュがまだリフレッシュされていないため、ユーザーは依然としてアプリケーション・ロールによって保護された機能にアクセスできます。
ユーザーはアプリケーションからログアウトして、10分後にログインしなおします。ステップ3で加えた変更でポリシー・キャッシュがリフレッシュされているため、ユーザーはアプリケーション・ロールによって保護された機能にアクセスできません。
ユーザーはログアウトしないと、ステップ3で加えた変更でポリシー・キャッシュがまだリフレッシュされていないため、10分間はアプリケーション・ロールによって保護された機能へのアクセスが可能な状態のままです。
ユーザーはログアウトせず、10分より長く待機してから、アプリケーション・ロールによって保護された機能へのアクセスを試行すると、ステップ3で加えた変更でポリシー・キャッシュがリフレッシュされているため、アクセスは拒否されます。

親トピック: ポリシー・キャッシュのリフレッシュ

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

親トピック: ポリシーの管理

WLSTコマンドにおけるアプリケーション・ストライプ

一部のコマンドでは、アプリケーション・ストライプの指定が必要です。アプリケーションにバージョンがない場合は、アプリケーション・ストライプがアプリケーション名にデフォルト設定されます。そうではなく、アプリケーションにバージョンがある場合は、アプリケーション名とアプリケーション・ストライプが同じではありません。

たとえば、バージョン1のmyAppアプリケーションの名前はmyApp(v1.0)ですが、アプリケーション・ストライプの名前はmyApp#v1.0です。より一般的には、名前がappName(vers)のアプリケーションは、アプリケーション・ストライプappName#versに割り当てられます。このパターンの文字列をアプリケーション・ストライプ名として渡します。

>listAppRoles myApp#v1.0

次のWLSTコマンドでは、ストライプの指定が必要です。

createAppRole
deleteAppRole
grantAppRole
revokeAppRole
listAppRoles
listAppRoleMembers
grantPermission
revokePermission
listPermissions
deleteAppPolicies

親トピック: ポリシーの管理

OESを使用したアプリケーション・ポリシーの管理

OESを使用すると、WebLogic Serverドメインのアプリケーション・ポリシーおよびその他のセキュリティ・データを管理および検索できます。

OESを使用したポリシーの管理の詳細は、『Oracle Entitlements Serverの管理』の次のトピックを参照してください。

親トピック: ポリシーの管理