10 ポリシーの管理
この章の内容は次のとおりです。
セキュリティ・ストアの特性の確認
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を使用してアプリケーション・ロールを管理します。
タスク1: 「アプリケーション・ロール」ページのオープン
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「アプリケーション・ロール」の順に移動します。「アプリケーション・ロール」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。
タスク2: アプリケーション・ロールの検索
「検索」領域で、アプリケーション・ストライプを選択し、照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。
タスク3: アプリケーション・ロールの作成
「作成」をクリックして「アプリケーション・ロールの作成」ページを表示します。
このページでは、データを一度に全部入力する必要はありません。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後で指定できます。同様に、後でロール・マッピングを指定することもできます。
「一般」領域で、次の情報を入力します。
-
「ロール名」テキスト・フィールドに、ロールの名前を入力します。
-
「表示名」テキスト・フィールドに、ロールに表示する名前を入力します(オプション)。
-
「説明」テキスト・フィールドに、ロールの説明を入力します(オプション)。
-
「メンバー」領域で、ロールのマップ先とするユーザー、グループまたは他のアプリケーション・ロールを指定します。
タスク4: ロールへのアプリケーション・ロールの追加
-
ロールを選択し、「追加」をクリックします。「プリンシパルの追加」ダイアログが表示されます。
-
「タイプ」(アプリケーション・ロール、グループまたはユーザー)を選択し、プリンシパル名と照合する文字列を入力して検索ボタンをクリックします。検索結果が「検索済プリンシパル」表に表示されます。この表からプリンシパルを1つ以上選択します。
-
ロールを追加するプリンシパルを1つ以上選択します。
-
「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。新しいアプリケーション・ロールが「メンバー」表に表示されます。
タスク5: 別のアプリケーション・ロールに似たアプリケーション・ロールの作成
- ロールを選択します。
- 「類似作成」をクリックします。アプリケーション・ロールの類似作成ページが表示され、選択したロールから抽出されたデータが一部のエントリに入力されます。
- ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。
ロールの階層でパーミッションがどのように継承されるかを理解するには、「パーミッションの継承とロールの階層」を参照してください。
システム・ポリシーの管理
この項に記載されている手順に従って、Fusion Middleware Controlを使用してシステム・ポリシーを管理します。
タスク1: 「システム・ポリシー」ページのオープン
Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「システム・ポリシー」の順に移動します。「システム・ポリシー」ページが表示されます。「ポリシー・ストア・プロバイダ」領域は読取り専用で、ドメインで現在使用されているプロバイダが表示されます。
タスク2: システム・ポリシーの検索
「検索」領域で、タイプを選択し、照合する文字列を入力して検索ボタンをクリックします。検索の結果がページの下部の表に表示されます。
タスク3: システム・ポリシーの作成
WLSTを使用したポリシーの管理
WLSTオンライン・コマンドとは、実行中のサーバーとの接続が必要なコマンドです。特に指定がないかぎり、この項に記載されているコマンドはオンライン・コマンドで、タイプに関係なくセキュリティ・ストアに対して動作します。動作に実行中のサーバーを必要としないオフラインのコマンドもいくつか存在します。
読取り専用コマンドは、WebLogic ServerグループMonitor
、Operator
、Configurator
またはAdmin
に属するユーザーのみが実行できます。読取り/書込みコマンドは、WebLogic ServerグループAdmin
またはConfigurator
に属するユーザーのみが実行できます。すべてのコマンドは、Oracle WebLogic Serverをインストールすると使用できます。
WLSTコマンドは、インタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力します。スクリプト・モードでは、シェル・スクリプトのディレクティブのように、コマンドをテキスト・ファイルに記述してスクリプトを実行します。
コマンドで指定するクラス名はすべて、完全修飾パス名にする必要があります。
OPSSでは、アプリケーション・ポリシーを管理するために次のコマンドが用意されています。
-
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のセキュリティ・ストアに再関連付けされたとします。次のコマンドを実行します:-
exportEncryptionKey
WLSTコマンドを使用して、Domain1からewallet.p12
ファイルにキーを抽出します。渡されたkeyFilePassword
引数の値は、後でそのキーを2つ目のドメインにインポートするときに使用する必要があります。 -
importEncryptionKey
WLSTコマンドを使用して、抽出したewallet.p12
ファイルをDomain2にインポートします。keyFilePassword
引数の値は、ewallet.p12
ファイルの生成時に使用したものと同一である必要があります。 -
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")
ポリシー・キャッシュのリフレッシュ
このトピックは、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