| Oracle Fusion Middlewareセキュリティ・ガイド 11gリリース1（11.1.1） B56235-01 |
|
 戻る |
 次へ |
ドメイン・ポリシー・ストアは、システム・ポリシーおよびアプリケーション固有のポリシーのリポジトリです。ドメインには、そのドメインにデプロイしたすべてのアプリケーションで使用できるすべてのポリシー（および資格証明）を格納するストアが1つあります。
ポリシー・ストアの主な機能の概要は、「ポリシー・ストアの基本」を参照してください。Java 2およびJAASの詳細は、「Javaセキュリティ・モデル」および「Java Authentication and Authorization Service」を参照してください。
この章の内容は次のとおりです。
JavaEEおよびWebLogicセキュリティの詳細は、『Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server』のJ2EEおよびWebLogicのセキュリティに関する項を参照してください。
|
注意: この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用不可になります。 |
LDAPベースのポリシー・ストアは本番環境に適しているので、本番環境での使用をお薦めします。今回のリリースでサポートされているLDAPサーバーは、Oracle Internet DirectoryとOracle Virtual Directoryです。
ドメイン・ポリシー・ストアの特性とドメイン資格証明ストアの特性は、緊密に相関しており、両方を同じ種類（ファイルベースまたはLDAPベース）にする必要があります。LDAPベースのリポジトリを使用する場合は、両方で同じタイプのLDAPサーバーを使用する必要があります。追加設定なしの状態では、ポリシー・ストアも資格証明ストアもファイルベースです。
ドメインでLDAPベースのポリシー・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用し、そのポリシー・ストアを構成する必要があります。
LDAPベースのドメイン・ポリシー・ストアを使用するには事前にいくつかの設定が必要です。詳細は、「LDAPベースのポリシー・ストアを使用する場合の前提条件」を参照してください。
サービス・インスタンスで指定できるプロパティの詳細なリストは、付録F「LDAPプロパティ」を参照してください。
サーバー・インスタンスが複数のマシンに分散しているドメインでは、ドメインのポリシー・ストアおよび資格証明ストアをLDAPベースとし、1つのストアにすべてのポリシー・データおよび資格証明データを格納して、そこで集中管理することを強くお薦めします。
通常、アプリケーションによってポリシー・データが変更されることはありません。そのような変更が発生した場合は、それらの変更がドメインにあるすべての管理対象サーバーに適切に伝播されることが重要です。したがって、このような変更は、管理対象サーバーで実行するのではなく、必ずドメイン管理サーバーで実行する必要があります。
単一ノード・サーバー・ドメインの場合は、セキュリティ・データのローカル変更の伝播を考慮する必要はありません。このシナリオでは、ローカル変更はグローバル変更と同じです。
一方、複数ノード・サーバー・ドメインの場合は、ファイルベースのポリシーに対するローカル変更がJMXフレームワークによって各ランタイム環境に伝播され、キャッシング・ポリシーおよび構成に基づいてデータがリフレッシュされます。
要約すると、複数ノード・サーバー環境における推奨事項は次のとおりです。
ドメイン・ポリシー・ストアもドメイン資格証明ストアもLDAPベースのストアで集中管理します。
ストアがファイルベースの場合は、ポリシー・データまたは資格証明データに対するローカル変更をドメイン管理サーバーでのみ実行して、管理サーバーからドメイン内のすべての管理対象サーバーにローカル変更が適切に伝播されるようにします。
LDAPサーバー・ディレクトリ（Oracle Internet DirectoryまたはOracle Virtual Directory）への適切なアクセスを実現するには、サーバー・ディレクトリにノードを設定する必要があります。
Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。手動で指定する場合は、第15.4.7項「ブートストラップ資格証明の手動による指定」を参照してください。
Oracle Internet Directoryサーバーのノードの設定
次の手順は、Oracle Internet Directory管理者が実行します。
LDAP Oracle Internet Directoryディレクトリにノードを設定する手順は、次のとおりです。
次のDNエントリおよびCNエントリを指定するLDIFファイル（ここではjpstestnode.ldifというファイル名にします）を作成します。
dn: cn=jpsroot cn: jpsroot objectclass: top objectclass: OrclContainer
ルート・ノードの識別名（前述の例では文字列jpsrootで示す）は、他のどの識別名とも異なる名前にする必要があります。一部のLDAPサーバーでは、デフォルトで大文字小文字が区別されます。1つのルート・ノードを複数のWebLogicドメインで共有できます。このノードは、サブツリーに対する読取りと書込みの権限がOracle Internet Directory管理者に付与されていれば、最上位レベルに作成する必要はありません。
次の例に示すように、コマンドldapaddを使用してこのデータをLDAPサーバーにインポートします（コマンド呼出し内で改行しないでください）。
>ldapadd -h ldap_host -p ldap_port -D cn=orcladmin -w password -c -v -f jpstestnode.ldif
次の例に示すように、コマンドldapsearchを使用してノードが正常に挿入されたことを確認します（コマンド呼出し内で改行しないでください）。
>ldapsearch -h ldap_host -p ldap_port -D cn=orcladmin -w password -b "cn=jpsroot" objectclass="orclContainer"
LDAPサーバーがOracle Internet Directoryの場合、次の例に示すように、ユーティリティoidstats.sqlを実行して、データベースのパフォーマンスを最適にするためにデータベース統計を生成します。
>$ORACLE_HOME/ldap/admin/oidstats.sql
前述のユーティリティの実行が必要なのは、初期プロビジョニング後の1回のみです。このユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。
|
注意: LDAPベースのOracle Internet Directoryポリシー・ストアを使用している場合は、Oracle Virtual Directoryの構成に関する次の項を省略し、「ドメイン・ポリシー・ストアの再関連付け」の説明に従ってポリシー・ストアの再関連付けをただちに開始してかまいません。 |
ローカル・ストア・アダプタを使用したOracle Virtual Directoryサーバーの構成
Oracle Virtual Directoryでは、既存のエンタープライズ・アイデンティティ情報をインターネットと業界で標準となっているLDAP形式やXML形式で表示できます。そのために、データの同期や元の場所からのデータの移動が必要になることもありません。この項で説明する構成は、Oracle Virtual Directory管理者が実行します。
LSAを使用してポリシーの格納にファイルを使用するようにOracle Virtual Directoryを構成する手順は、次のとおりです。
Oracle Directory Services Managerを起動します。
「アダプタ」タブを選択します。
アダプタの作成を選択して、次の図に示す「新規アダプタ・ウィザード」ダイアログ・ボックスを表示します。
ウィザードの「タイプ」フェーズで、（a）「アダプタ・タイプ」を「ローカル・ストア」に設定します。（b）「アダプタ名」を一意の名前に設定します。（c）「アダプタ・テンプレート」を「Opss」に設定します。
「次へ」をクリックして、次の図に示す「新規ローカル・ストア・アダプタ・ウィザード」の「設定」フェーズを表示します。
「アダプタ接尾辞/ネームスペース」テキスト・ボックスに、作成するアダプタのルート名を入力します（この値は、OVDで指定したノードのDNと一致している必要があります）。他のフィールドはすべて、デフォルト値のままにします。
「次へ」をクリックして、ウィザードの「概要」フェーズですべての設定を確認し、問題がなければ入力を確定します。
詳細は、『Oracle Fusion Middleware Oracle Virtual Directory管理者ガイド』のLocal Store Adapterに関する第2.4項を参照してください。
ポリシー・ストアの再関連付けとは、ファイルベースまたはLDAPベースのリポジトリからLDAPベースのリポジトリにポリシー・データを移行することです。つまり、再関連付けでは、格納されているデータの整合性を保持したまま、リポジトリを変更します。ソース・ポリシー・ストアのポリシーごとに、再関連付けによって、ターゲットLDAPディレクトリが検索され、一致するものが見つかると、その一致したポリシーが必要に応じて更新されます。見つからない場合は、そのポリシーがそのまま移行されます。
ドメイン・ポリシー・ストアをインスタンス化すると、ファイルベースまたはLDAPベースのポリシー・ストアを、同じデータを格納しているLDAPベースのポリシー・ストアに再関連付けできます。この操作をサポートするには、必要に応じて、LDAPポリシー・ストアを使用するようにドメインを構成する必要があります。
再関連付けを行うには、Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用します。この操作は通常、追加設定がない場合に使用されるファイル・ベースのドメイン・ストアではなく、LDAPベースのストアを使用するようにドメインを設定するときに実行します。
|
重要: ポリシー・ストアおよび資格証明ストアのリポジトリは、両方ともファイルベースであるか、両方ともLDAPベースである必要があります。さらに、LDAPベースの場合、両方のストアが同じ種類のLDAPサーバーを使用する必要があります。この一貫性を保持するために、1つのストアの再関連付けは、もう一方のストアの再関連付けを意味することに注意してください。 |
セキュリティ・ストアの再関連付けによって、リポジトリ間でポリシーおよび資格証明が移行され、それらのセキュリティ・ストア・プロバイダが再構成されます。この再構成は通常、テスト環境から本番環境への移行時などに行われます。OPSSでは、LDAPベースからLDAPベースへの再関連付けとファイルベースからLDAPベースへの再関連付けがサポートされています。この場合のLDAPサーバーは、Oracle Internet DirectoryまたはOracle Virtual Directoryです。LDAPベースからファイルベースへの再関連付けはサポートされていません。
この項では、Oracle Internet DirectoryサーバーまたはOracle Virtual Directoryサーバーを使用するLDAPベースの記憶域にポリシーおよび資格証明を再関連付けする手順について説明します。
ドメイン・ストアを手動で再関連付けするには、WLSTコマンドreassociateSecurityStoreを使用します。
|
注意:
|
Fusion Middleware Controlを使用して、指定したドメイン内のポリシー・ストアと資格証明ストアの両方を新しいLDAPリポジトリに再関連付けする手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。このページの一部を次の図に示します。
「構成」ボタンの下の表に、そのドメインに現在構成されているプロバイダの特性が表示されます。
「ポリシー・ストア・プロバイダと資格証明ストア・プロバイダ」領域の「構成」ボタンをクリックして、「セキュリティ・プロバイダの設定」ページを表示します。このページで、ターゲットLDAPサーバーに関する詳細および接続情報を入力します。
メニューからLDAPサーバーのタイプを選択します。ローカル・ストア・アダプタを使用してOracle Virtual Directoryを構成している場合はOracle Virtual Directoryを選択し、それ以外の場合はOracle Internet Directoryを選択します。
ターゲットLDAPサーバーのホスト名とポート番号を入力します。
オプションで、「SSLを接続に使用」ボックスを選択し、LDAPサーバーへの匿名SSL伝送を確立します。
このチェック・ボックスを選択するときには、次の点に注意してください。
ターゲットLDAPサーバーのポートは、匿名SSL伝送を処理するように構成されている必要があります。このポートは、デフォルトの（セキュアではない）LDAPサーバー・ポートとは異なります。
再関連付けで一方向SSLを使用する場合は、この手順を実行する前に、「一方向SSL接続の設定」で説明する手順を必ず実行してください。一方向SSL接続の設定で、一方向SSLチャネルをサポートするポートを特定し、以降の手順でそのポートを指定します。今回のリリースでは、双方向SSLチャネルを使用した再関連付けはサポートされていません。
Fusion Middleware Controlによって、匿名SSL接続をサポートするために必要な権限が追加されて、ファイルweblogic.policyが変更されます。
「ユーザーDN」テキスト・ボックスで、1〜256文字を含む文字列である完全な識別名を入力します。たとえば、cn=orcladmin、dc=us、dc=oracle、dc=comです。
「パスワード」ボックスに、1〜256文字を含む文字列であるユーザー・パスワードを入力します。
入力したデータを使用したLDAPサーバーへの接続が機能することを確認するには、「LDAP認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第I.10項「匿名SSL接続の確立の失敗」を参照してください。
「JPSルート・ノードの詳細」領域で、「JPSルートDN」ボックスにルートDNを入力します。このノードは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。「WebLogicドメイン名」は、デフォルトで、選択したドメインの名前になります。この2つのフィールドで指定した値が原因となって最もよく発生するエラーを解決するには、第I.2項「再関連付けの失敗」を参照してください。
オプションで、サービス・インスタンスのプロパティを入力します。「追加」をクリックし、「新規プロパティの追加」ダイアログ・ボックスで「プロパティ名」と「値」に文字列を入力して、「OK」をクリックします。追加されたプロパティと値のペアが、表「カスタム・プロパティ」に表示されます。
これらのプロパティは通常、インスタンスの作成時にインスタンスを初期化するために使用されます。
ドメイン構成ファイルjps-config.xmlにあるLDAPサービス・インスタンスの構成に、入力したプロパティと値を指定した<property>要素が追加されて、この構成ファイルが変更されます。
サービス・インスタンスの変更例として、プロパティ名fooと値barを入力したとします。この場合は、次に示すような<property>要素が追加され、LDAPサービス・インスタンスの構成が変更されます。
<serviceInstance name="myNewLDAPprovider" provider="someProvider" ... <property name="foo" value="bar"/> ... </serviceInstance>
データの入力を完了したら、「OK」をクリックし、「セキュリティ・プロバイダ構成」ページに戻ります。再関連付けのステータスを示すダイアログ・ボックスが表示されます。「ポリシー・ストア・プロバイダと資格証明ストア・プロバイダ」領域の表が変更されて、指定したプロバイダが現在のプロバイダとして表示されます。
Oracle WebLogic Serverを再起動します。サーバーが再起動するまで、変更は有効になりません。
再関連付けによって、ドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されます。古いプロバイダの構成がすべて削除され、新しいストア・プロバイダの構成が挿入されます。サーバーを再起動すると、新しい構成が有効になります。
この項では、ドメイン・ストアを再関連付けするためにOracle WebLogicサーバーとターゲットLDAP Oracle Internet Directoryストア間の一方向SSLチャネルを設定する方法について説明します。この設定は、Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用する前に行う必要があります。
前提条件: Oracle Internet Directoryサーバーの構成
一方向SSLモードでリスニングするようにOracle Internet Directoryサーバーを構成するには、Oracle Fusion Middlewareの管理者ガイドのOracle Internet DirectoryリスナーでのSSLの有効化に関する項を参照してください。
Oracle Internet Directoryの認証局（CA）のエクスポート
orapkiを使用して証明書を作成する必要があるのは、Oracle WebLogicサーバーでCAを認識できない場合のみです。
次の例は、このコマンドを使用して証明書serverTrust.certを作成する方法を示しています。
>orapki wallet export -wallet CA -dn "CN=myCA" -cert serverTrust.cert
前述の呼出しを実行すると、キーストア・パスワードの入力を求められます。
WebLogicサーバーの設定
再関連付けするストアがドメインに存在するサーバーを設定する手順は、次のとおりです。
Oracle WebLogicサーバーでCAを認識できる場合は、この手順を省略します。CAを認識できない場合は、ユーティリティkeytoolを使用してOracle Internet DirectoryのCAをWebLogicトラストストアにインポートします。
ファイルmyKeys.jksを出力する次の呼出しは、このコマンドを使用してファイルserverTrust.certをインポートする方法を示しています。
>keytool -import -v -trustcacerts -alias trust -file serverTrust.cert -keystore myKeys.jks -storepass keyStorePassword
WebLogic管理コンソールを使用して、ファイルmyKeys.jksを指し示すトラストストアを適切なドメイン内に設定します。その手順は次のとおりです。
「環境」→「サーバー」に移動します。
ドメインの管理サーバーの名前を選択します。
「キーストア」タブを選択します。
キーストア・モードを「デモIDとデモ信頼」から「カスタムIDとカスタム信頼」に変更します。
「信頼」セクションで、データを次のように入力します。「カスタム信頼キーストア」フィールドに、キーストア・ファイルmyKeys.jksの絶対パス名を入力します。「キーストアのタイプ」フィールドに、JKSを入力します。「カスタム信頼キーストアのパスフレーズ」フィールドと「カスタム信頼キーストアのパスフレーズを確認」フィールドに、キーストア・パスワードを入力します。
サーバーを起動するスクリプト（通常はstartWebLogic.sh）に次のような行を追加して変更し、サーバーを再起動します。
-Djavax.net.ssl.trustStore=<absolute path name to file myKeys.jks>
この項で説明する手順は必要に応じて実行するものであり、Oracle Internet Directoryにアクセスするときのセキュリティを強化することのみを目的としています。
アクセス制御リスト（ACL）とは、情報にアクセスできるユーザーとOracle Internet Directoryディレクトリ・オブジェクトに対して許可される操作を指定したリストです。この制御リストはノードで指定し、そのノードのすべてのサブツリーにあるすべてのエントリに、リストで指定した制限が適用されます。
ACLを使用して、LDAP Oracle Internet Directoryリポジトリに格納されているポリシー・データおよび資格証明データへのアクセスを制御できます。ACLは通常、ストアの最上位のルート・ノードで指定します。
Oracle Internet DirectoryリポジトリのノードでACLを指定する手順は、次のとおりです。
ACLを指定する内容を記述したLDIFファイルを作成します。
dn: <storeRootDN> changetype: modify add: orclACI access to entry by dn="<userDN>" (browse,add,delete) by * (none) access to attr=(*) by dn="<userDN>" (search,read,write,compare) by * (none)
storeRootDNはノード（通常はストアのルート・ノード）を表し、userDNは管理者データのDN（再関連付けを実行する際に入力したuserDN）を表します。
Oracle Internet Directoryのユーティリティldapmodifyを使用して、これらの指定をOracle Internet Directoryに適用します。
ACLを指定するLDIFファイルの例を次に示します。
dn: cn=jpsRootNode changetype: modify add: orclACI access to entry by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (browse,add,delete) by * ( none ) access to attr=(*) by dn="cn=myAdmin,cn=users,dc=us,dc=oracle,dc=com" (search,read,write,compare) by * (none)
アクセス制御リストおよびコマンドldapmodifyの詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の第18章を参照してください。
ドメイン・ストアは、WLSTコマンドreassociateSecurityStoreを使用して手動で再関連付けすることもできます。このコマンドの詳細は、「reassociateSecurityStore」を参照してください。
1つのドメインに設定できるポリシー・ストアは1つのみです。アプリケーションで独自のポリシーを指定することはできますが、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはそのドメイン・ポリシー・ストアのポリシーとして格納されます。したがって、ドメインにデプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるドメイン・ポリシー・ストアを使用します。ドメイン・ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。
アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをドメイン・ポリシー・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。
ドメイン・ポリシー・ストアの構成は、ドメイン管理者が行います。
この章の内容は次のとおりです。
アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにドメイン・ポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにドメイン・ポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。
アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。
詳細は、第7.5.2項「デプロイ時のポリシーおよび資格証明の移行」の手順を参照してください。
アプリケーション固有のポリシーまたはシステム・ポリシーは、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。
このコマンドはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
|
注意: コマンドmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、第7.5.2.3項「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。 |
WLSTコマンドとその構文の詳細は、『Oracle Fusion Middleware WebLogic Scripting Tool Command Reference』のWSLTコマンドのカテゴリの概要に関する項を参照してください。
すべてのポリシー（システム・ポリシーおよびすべてのアプリケーションのアプリケーション固有のポリシー）を移行するには、スクリプト（1番目）またはインタラクティブな（2番目）構文を使用します（明確にするために引数は別の行に記述）。
migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-overWrite TrueOrFalse]
migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [overWrite="TrueOrFalse"])
引数（overWrite以外はすべて必須）の意味は次のとおりです。
configFileでは、構成ファイルjps-config.xmlの位置を、このコマンドを実行するディレクトリを基準とした相対パスで指定します。通常、この構成ファイルはコマンドで使用するためにのみ作成し、他の目的には使用しません。このファイルには、ソース・ストアとターゲット・ストアを指定する2つのjps-contextがあります。
また、1つまたは2つのLDAPベース・ストアを対象とする移行では、cwallet.ssoファイルの場所を指すブートストラップjps-contextをこのファイルに追加する必要があります。cwallet.ssoファイルには、移行の対象となるLDAPベース・ストアにアクセスするための資格証明を格納します。後述の2番目のサンプルを参照してください。
srcでは、引数configFileで渡す構成ファイル内のjps-contextの名前を指定します。
dstでは、引数configFileで渡す構成ファイル内の別のjps-contextの名前を指定します。
overWriteでは、ソース・ポリシーと一致するターゲット・ポリシーをソース・ポリシーで上書きするか、ソース・ポリシーとマージするかを指定します。ターゲット・ポリシーを上書きする場合はTrueに設定し、一致するポリシーをマージする場合はFalseに設定します。この引数はオプションです。指定しなかった場合は、デフォルトでFalseに設定されます。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
システム・ポリシーのみを移行するには、スクリプト（1番目）またはインタラクティブな（2番目）構文を使用します（明確にするために引数は別の行に記述）。
migrateSecurityStore.py -type globalPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
[-overWrite TrueOrFalse]
migrateSecurityStore(type="globalPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", [overWrite="TrueOrFalse"])
引数（overWrite以外はすべて必須）の意味は、前述の場合と同じです。
1つのアプリケーションのアプリケーション固有のポリシーのみを移行するには、スクリプト（1番目）またはインタラクティブな（2番目）構文を使用します（明確にするために引数は別の行に記述）。
migrateSecurityStore.py -type appPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
-srcApp srcAppName
[-dstApp dstAppName]
[-overWrite TrueOrFalse]
[migrateIdStoreMapping TrueOrFalse]
migrateSecurityStore(type="appPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", srcApp="srcAppName", [dstApp="dstAppName"], [overWrite="TrueOrFalse"], [migrateIdStoreMapping="TrueOrFalse"])
引数configFile、src、dstおよびoverWriteの意味は、前述の場合と同じです。他の3つの引数の意味は次のとおりです。
srcAppでは、ソース・アプリケーションの名前、つまり、ポリシーを移行するアプリケーションの名前を指定します。
dstAppでは、ターゲット・アプリケーションの名前、つまり、ポリシーを書き込むアプリケーションの名前を指定します。指定しない場合は、デフォルトでソース・アプリケーションの名前になります。
migrateIdStoreMappingでは、エンタープライズ・ポリシーを移行するかどうかを指定します。デフォルト値はTrueです。エンタープライズ・ポリシーを移行の対象から除外する場合、つまりアプリケーション・ポリシーのみを移行する場合は、Falseに設定します。
前述の構文要件に一致しない入力を指定すると、コマンドの実行に失敗し、エラーが返されます。特に、入力は次の要件を満たす必要があります。（a）渡された位置内でファイルjps-config.xmlが検出されること、（b）渡されたjps-contextsがファイルjps-config.xmlに含まれていること、（c）ソースおよびターゲットのコンテキスト名が一意であること。
次の項では、管理者がFusion Middleware ControlまたはWLSTコマンドを使用してポリシーを管理する方法について説明します。代表的な操作は次のとおりです。
既存のアプリケーション・ロールの権限の変更
プリンシパルのパーミッションの取消し
アプリケーション・ロールの作成と削除
すべてのアプリケーション・ロール、およびアプリケーション・ロールのすべてのメンバーのリスト
ドメイン・ポリシー・ストアのデータにアクセスできるのは、ドメイン管理者など、適切なパーミッションを持つユーザーのみです。
予期しない認可の失敗を防ぎ、効果的にポリシーを管理するには、次の重要ポイントに注意してください。
|
重要ポイント1: ユーザーを削除する前に、ユーザーに付与されているすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに誤って継承される可能性があります。ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー（権限付与、パーミッション、グループ）を更新して、変更後のデータでも予期したとおりに機能するようにする必要があります。 第I.12項「ユーザーによる予期しないパーミッションの取得」を参照してください。 |
|
重要ポイント2: ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。そのため、次のことをお薦めします。
第I.6項「パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致」を参照してください。 |
Fusion Middleware Controlでは、次の項の説明のように、ドメインで使用しているポリシー・ストア・プロバイダのタイプに関係なく、WebLogicドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理できます。
この項では、Fusion Middleware Controlを使用してデプロイ済アプリケーションのポリシーを管理する手順（既存のアプリケーション・ロールのパーミッション付与の変更など）について説明します。システム・ポリシーの管理方法は、「システム・ポリシーの管理」を参照してください。
|
注意: 複数のアプリケーションがパーミッションを共有している場合、パーミッション・チェックの失敗を防ぐには、該当するパーミッション・クラスをシステム・クラスパスで指定しておく必要があります。 |
Fusion Middleware Controlにログインし、「アプリケーション名」→「セキュリティ」→「アプリケーション・ポリシー」に移動して、選択したアプリケーションの「アプリケーション・ポリシー」ページを表示します。このページの一部を次の図に示します。
「ポリシー・ストア・プロバイダ」領域は読取り専用です。この領域を開くと、アプリケーションのデプロイ先ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
|
注意: 最初、このページにポリシーとロールが表示されていない場合は、青いボタンをクリックするとすべての項目が表示されます。 |
指定したプリンシパルまたはパーミッションと一致する既存のアプリケーション・ポリシーを表示するには、必要に応じて「検索」領域を開き、一致対象のデータ（プリンシパル、パーミッションまたは両方）を入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。
アプリケーション・ポリシーを作成するには、「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。ページ上部の「権限の詳細」領域に、アプリケーションに関する読取り専用の情報が表示されます。
作成するポリシーにパーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログ・ボックスを表示します。
「検索」を使用して、クラス名またはリソース名が一致するパーミッションを特定し、パーミッションの「権限クラス」と「リソース名」を決定します。必要に応じ、「カスタマイズ」領域を使用してパーミッションを限定します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。作成したパーミッションが、「権限」領域の表に表示されます。
作成するポリシーにユーザーを追加するには、「権限受領者」領域の「ユーザーの追加」ボタンをクリックして、「ユーザーの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、文字列が一致するユーザー名を特定します。問合せの結果が「使用可能なユーザー」ボックスに表示されます。
様々なボタンを使用して、パーミッションを付与するユーザーを「使用可能なユーザー」ボックスから「選択したユーザー」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。選択したユーザーが、「権限受領者」領域の表に表示されます。
作成するポリシーにロールを追加するには、「権限受領者」領域の「ロールの追加」ボタンをクリックして、「ロールの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、タイプまたは名前が一致するロール名を特定します。問合せの結果が「使用可能なロール」ボックスに表示されます。
様々なボタンを使用して、パーミッションを付与するロールを「使用可能なロール」ボックスから「選択したロール」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。選択したロールが、「権限受領者」領域の表に表示されます。
「削除」ボタンを使用すると、選択した項目をいつでも削除できます。
完了したら、「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。作成したポリシーのプリンシパルとパーミッションがページの下部の表に表示されます。
既存のアプリケーション・ポリシーに基づいてアプリケーション・ポリシーを作成する手順は、次のとおりです。
表から既存のポリシーを選択します。
「類似作成」をクリックし、「アプリケーション権限の作成」ページを表示します。このページでは、選択したポリシーから抽出されたデータを使用して、すべてのパーミッションが自動的に入力されます。
前述の手順3の下位手順の説明に従い、必要に応じてこれらの値を変更し、ユーザーおよびロールを入力します。
この項では、Fusion Middleware Controlを使用してデプロイ済アプリケーションのロールを管理する手順について説明します。ユーザーまたはグループによるリソースへのアクセスを制御する管理操作には、アプリケーション・ロールの作成、ユーザー、グループまたは他のアプリケーション・ロールへのアプリケーション・ロールのマップ、アプリケーション・ロールのメンバーの管理などがあります。
Fusion Middleware Controlにログインし、「アプリケーション名」→「セキュリティ」→「アプリケーション・ロール」に移動して、「アプリケーション・ロール」ページを表示します。このページの一部を次の図に示します。
「ポリシー・ストア・プロバイダ」領域は読取り専用です。この領域を開くと、アプリケーションのデプロイ先ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
|
注意: 最初、このページにアプリケーション・ロールが表示されていない場合は、青いボタンをクリックするとすべての項目が表示されます。 |
指定した名前と一致するアプリケーション・ロールを表示するには、一致対象のデータを「ロール名」ボックスに入力し、青いボタンをクリックします。問合せの結果がページの下部の表に表示されます。
現在のすべてのアプリケーション・ポリシーの表を再表示するには、「ロール名」を空白のままにし、青いボタンをクリックします。
アプリケーション・ロールを作成するには、「作成」をクリックして、「アプリケーション・ロールの作成」ページを表示します。すべての領域のデータを一度に入力する必要はありません。たとえば、ロールおよび表示名を入力することによってロールを作成し、データを保存し、後でその中のメンバーを指定できます。同様に、後でロール・マッピングのためのデータを入力することもできます。
領域「一般」で、作成するロールの次の属性を指定します。
「ロール名」テキスト・ボックスにロールの名前を入力します。
「表示名」テキスト・ボックスに、ロールに対して表示する名前を指定します。
オプションで、「説明」テキスト・ボックスに、ロールの説明を入力します。
「メンバー」領域で、作成するロールのマップ先となるユーザー、グループまたは他のアプリケーション・ロールがある場合はそれを指定します。
「ロールの追加」をクリックして、「ロールの追加」ダイアログ・ボックスを表示します。
このダイアログ・ボックスで、「ロール・タイプ」の横にあるメニューから、追加するロールのタイプを選択します。必要に応じ、「ロール名」テキスト・ボックスにロール名を入力します。青いボタンをクリックすると、入力した条件と一致するロールが「使用可能なロール」ボックスに表示されます。
必要に応じて「使用可能なロール」ボックスからロールを選択し、ボックスの間にあるボタンを使用して「選択したロール」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したロールが表「ロール」に表示されます。
「ユーザー」領域で、作成するロールのメンバーを指定します。
「ユーザーの追加」をクリックして、「ユーザーの追加」ダイアログ・ボックスを表示します。
「使用可能なユーザー」ボックスに、すべての使用可能なユーザーが表示されます。指定した文字列と一致する名前のユーザーのみを表示するには、その文字列を「ユーザー名」ボックスに入力し、青いボタンをクリックします。
必要に応じて「使用可能なユーザー」ボックスからユーザーを選択し、ボックスの間にあるボタンを使用して「選択したユーザー」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したユーザーが、表「ユーザー」に表示されます。
「OK」をクリックし、ロールの作成（または更新）を完了し、「アプリケーション・ロール」ページに戻ります。作成したロールがそのページの下部の表に表示されます。
ロール階層でのパーミッションの継承方法を理解するには、第3.2.1項「パーミッションの継承とロールの階層」を参照してください。
この項では、Fusion Middleware Controlを使用してドメインのシステム・ポリシーを管理する手順について説明します。アプリケーション・ポリシーの管理方法は、「アプリケーション・ポリシーの管理」を参照してください。
次の手順では、プリンシパルのポリシーとコードベースのポリシーという2種類のシステム・ポリシーを作成できます。プリンシパルのポリシーでは、ユーザーまたはグループのリストにパーミッションを付与します。コードベースのポリシーでは、コード（通常はURLまたはJARファイル）にパーミッションを付与します。たとえば、資格証明ストア・フレームワークを使用するアプリケーションには、適切なコードベースのポリシーが必要です。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「システム・ポリシー」に移動して、「システム・ポリシー」ページを表示します。このページの一部を次の図に示します。
「ポリシー・ストア・プロバイダ」領域は読取り専用です。この領域を開くと、ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
指定したタイプ、名前またはパーミッションと一致するアプリケーション・ポリシーを表示するには、「検索」領域を開き、一致対象のデータを入力して、青いボタンをクリックします。問合せの結果がページの下部の表に表示されます。
現在のアプリケーション・ポリシーの表を再表示するには、タイプとして「すべて」を選択し、名前とパーミッションのボックスを空白のままにします。
「編集」ボタンをクリックすると、選択したポリシーの特性をいつでも編集できます。リストからポリシーを削除するには、「削除」ボタンをクリックします。
システム・ポリシーを作成する手順は、次のとおりです。
「作成」をクリックして、「システム権限の作成」ページを表示します。
「権限の詳細」領域で、作成するポリシーのタイプを選択します。有効なタイプは、「プリンシパル」または「コードベース」です。選択したタイプによって、表示されるUIが多少異なります。後述の手順では、｢プリンシパル｣を選択した場合を想定しています。
作成するポリシーにパーミッションを追加するには、「権限」領域の「追加」ボタンをクリックして、「権限の追加」ダイアログ・ボックスを表示します。このダイアログ・ボックスで、作成するポリシーに追加するパーミッションを選択します。
「検索」領域を使用して、タイプ、プリンシパル名またはパーミッション名が一致するパーミッションを問い合せます。問合せの結果が「検索」領域の表に表示されます。
追加するパーミッションを選択するには、この表からパーミッションを選択します。パーミッションを選択すると、その詳細が読取り専用の「カスタマイズ」領域に表示されます。
「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したパーミッションが、「権限」の表に追加されます。
表からパーミッションを選択し、「編集」ボタンを使用すると、パーミッションの特性をいつでも変更できます。リストからパーミッションを削除するには、「削除」ボタンを使用します。
作成するポリシーにユーザーを追加するには、「権限受領者」領域の「ユーザーの追加」ボタンをクリックして、「ユーザーの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、パターンが一致するユーザー名を表示します。問合せの結果が「使用可能なユーザー」ボックスに表示されます。
ボックスの間にあるボタンを使用して、「使用可能なユーザー」ボックスから「選択したユーザー」ボックスにユーザーを移動します。
「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したユーザーが、「権限受領者」の表に追加されます。
作成するポリシーにロールを追加するには、「権限受領者」領域の「ロールの追加」ボタンをクリックして、「ロールの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、タイプまたはロール名が一致するロール名を表示します。問合せの結果が「使用可能なロール」ボックスに表示されます。
ボックスの間にあるボタンを使用して、「使用可能なロール」ボックスから「選択したロール」ボックスにロールを移動します。
「OK」をクリックして、「システム権限の作成」ページに戻ります。選択したロールが、「権限受領者」の表に追加されます。
「OK」をクリックして、「システム・ポリシー」ページに戻ります。ページの上部に表示されるメッセージは、操作の結果を示します。操作が正常に完了すると、ページの下部の表にポリシーが追加されます。
既存のシステム・ポリシーに基づいてシステム・ポリシーを作成する手順は、次のとおりです。
表からポリシーを選択します。
「類似作成」をクリックして、「システム権限の作成」ページを表示します。このページのエントリの中には、前の手順で選択したポリシーから抽出されたデータが入力されるものがあります。
システム・ポリシーを作成する前述の手順を実行して、それらの値を変更し、必要に応じて新しい値を入力します。
ポリシーの管理にFusion Middleware Controlを使用しない場合や多用するタスクを自動的に実行する場合、ドメイン管理者は、セキュリティ関連のWLSTコマンドを呼び出すWLSTスクリプトを作成できます。
オンライン・コマンドとは、それが機能するためには実行中のOracle WebLogic Serverへの接続を必要とするコマンドです。後述のコマンドはすべてオンライン・コマンドであり、ファイルベースであるかLDAPベースであるかに関係なく、すべてのドメイン・ポリシー・ストアに対して機能します。
読取り専用コマンドは、モニター、オペレータ、コンフィギュレータまたはAdminというグループに属するユーザーのみが実行できます。読取り-書込みコマンドは、Adminまたはコンフィギュレータというグループに属するユーザーのみが実行できます。すべてのWLSTコマンドは、Oracle WebLogic Serverをインストールすれば、追加設定なしで使用できます。
特に明記のないかぎり、後述のコマンドはインタラクティブ・モードでもスクリプト・モードでも実行できます。インタラクティブ・モードの場合は、コマンドライン・プロンプトにコマンドを入力すると、応答が即座に表示されます。スクリプト・モードの場合、コマンドはテキスト・ファイル（ファイル名拡張子は.py）に記述されるので、シェル・スクリプトのディレクティブのように入力なしで実行できます。
|
重要: シェル内でセキュリティ関連のWLSTコマンドを起動する前に、次のサンプルで説明するように、wlst.shスクリプトを実行する必要があります。
> sh $ORACLE_HOME/common/bin/wlst.sh これにより、必要なJARがクラスパスに確実に追加されるようになります。新しいシェル内で前述のコマンドを実行しないと、WLSTコマンドが使用できない状態になります。 オンライン・コマンドを実行する前に、次のようにサーバーに接続します。
>java weblogic.WLST
>connect(' |
OPSSでは、ポリシーを管理するために次のオンライン・コマンドがサポートされています。
これらのコマンドで指定するクラス名は、すべて完全修飾パス名にする必要があります。引数appStripeは、アプリケーション・ストライプ（アプリケーション名）を参照します。これによって、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。
コマンドcreateAppRoleによって、ドメイン・ポリシー・ストア内に、指定したアプリケーション・ストライプおよびロール名を持つアプリケーション・ロールが作成されます。
スクリプト・モード構文
createAppRole.py -appStripe appName -appRoleName roleName
インタラクティブ・モード構文
createAppRole(appStripe="appName", appRoleName="roleName")
引数（すべて必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。
appRoleNameでは、ロール名を指定します。
使用例
次の呼出しでは、アプリケーション・ストライプmyAppおよびロール名myRoleを持つアプリケーション・ロールが作成されます。
createAppRole.py -appStripe myApp -appRoleName myRole
コマンドdeleteAppRoleによって、ドメイン・ポリシー・ストアから、指定したアプリケーション・ストライプおよびロール名を持つアプリケーション・ロールが削除されます。
スクリプト・モード構文
deleteAppRole.py -appStripe appName -appRoleName roleName
インタラクティブ・モード構文
deleteAppRole(appStripe="appName", appRoleName="roleName")
引数（すべて必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。
appRoleNameでは、ロール名を指定します。
使用例
次の呼出しでは、アプリケーション・ストライプmyAppおよび名前myRoleを持つロールが削除されます。
deleteAppRole.py -appStripe myApp -appRoleName myRole
コマンドgrantAppRoleによって、指定したアプリケーション・ストライプおよび名前を持つロールにプリンシパル（クラスと名前）が追加されます。
grantAppRole.py -appStripe appName -appRoleName roleName -principalClass className -principalName prName
インタラクティブ・モード構文
grantAppRole(appStripe="appName", appRoleName="roleName", principalClass="className", principalName="prName")
引数（すべて必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。
appRoleNameでは、ロール名を指定します。
principalClassでは、完全修飾クラス名を指定します。
principalNameでは、プリンシパル名を指定します。
使用例
次の呼出しでは、アプリケーション・ストライプmyAppおよび名前myRoleを持つロールにプリンシパルが追加されます。
grantAppRole.py -appStripe myApp
-appRoleName myRole
-principalClass com.Example.XyzPrincipal
-principalName myPrincipal
コマンドrevokeAppRoleによって、指定したアプリケーション・ストライプおよび名前を持つロールからプリンシパル（クラスと名前）が削除されます。
スクリプト・モード構文
revokeAppRole.py -appStripe appName -appRoleName roleName -principalClass className -principalName prName
インタラクティブ・モード構文
revokeAppRole(appStripe="appName", appRoleName="roleName", principalClass="className", principalName="prName")
引数（すべて必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。
appRoleNameでは、ロール名を指定します。
principalClassでは、完全修飾クラス名を指定します。
principalNameでは、プリンシパル名を指定します。
使用例
次の呼出しでは、アプリケーション・ストライプmyAppおよび名前myRoleを持つロールからプリンシパルが削除されます。
revokeAppRole.py -appStripe myApp
-appRoleName myRole
-principalClass com.Example.XyzPrincipal
-principalName myPrincipal
コマンドlistAppRolesによって、指定したアプリケーション・ストライプを持つすべてのロールがリストされます。
スクリプト・モード構文
listAppRoles.py -appStripe appName
インタラクティブ・モード構文
listAppRoles(appStripe="appName")
引数（必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。
使用例
次の呼出しでは、アプリケーション・ストライプmyAppを持つすべてのロールが返されます。
listAppRoles.py -appStripe myApp
コマンドlistAppRoleMembersによって、指定したアプリケーション・ストライプおよびロール名を持つロール内のすべてのメンバーがリストされます。
スクリプト・モード構文
listAppRoleMembers.py -appStripe appName -appRoleName roleName
インタラクティブ・モード構文
listAppRoleMembers(appStripe="appName", appRoleName="roleName")
引数（すべて必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。
appRoleNameでは、ロール名を指定します。
使用例
次の呼出しでは、アプリケーション・ストライプmyAppおよび名前myRoleを持つロール内のすべてのメンバーが返されます。
listAppRoleMembers.py -appStripe myApp
-appRoleName myRole
コマンドgrantPermissionによって、アプリケーション・ポリシーまたはグローバル・ポリシー・セクションで、コードベース、URLまたはプリンシパルに付与するパーミッションが作成されます。
スクリプト・モード構文
grantPermission [-appStripe appName] [-codeBaseURL url] [-principalClass prClassName] [-principalName prName] -permClass permissionClassName [-permTarget permName] [-permAction comma_separated_list_of_actions]
インタラクティブ・モード構文
grantPermission([appStripe="appName",] [codeBaseURL="url",] [principalClass="prClassName",] [principalName="prName",] permClass="permissionClassName", [permTarget="permName",] [permAction="comma_separated_list_of_actions"])
引数（オプションの引数は、大カッコで囲んであります）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。指定されていない場合、コマンドはシステム・ポリシーに対して機能します。
codeBaseURLでは、パーミッションが付与されたコードのURLを指定します。
principalClassでは、完全修飾クラス名を指定します（権限受領者）。
principalNameでは、権限受領者プリンシパルの名前を指定します。
permClassでは、パーミッション・クラスの完全修飾名を指定します
permTargetでは、パーミッション・ターゲットの名前を指定します（使用可能な場合）。この属性が含まれていないパーミッションもあります。
permActionでは、付与するアクションのリストを指定します。この属性が含まれていないパーミッションもあります。また、使用できるアクションはパーミッション・クラスによって異なります。
使用例
次の呼出しでは、指定したデータを持つアプリケーション・パーミッションが（アプリケーション・ストライプmyAppを持つアプリケーションに対して）作成されます。
grantPermission.py -appStripe myApp
-principalClass my.custom.Principal
-principalName manager
-permClass java.security.AllPermission
次の呼出しでは、指定したデータを設定したシステム・パーミッションが作成されます。
grantPermission.py -principalClass my.custom.Principal
-principalName manager
-permClass java.io.FilePermission
-permTarget /tmp/fileName.ext
-permAction read,write
コマンドrevokePermissionによって、アプリケーションまたはグローバル・ポリシー・セクションで定義されたプリンシパルまたはコードベースからパーミッションが削除されます。
スクリプト・モード構文
revokePermission [-appStripe appName] [-codeBaseURL url] [-principalClass prClassName] [-principalName prName] -permClass permissionClassName [-permTarget permName] [-permAction comma_separated_list_of_actions]
インタラクティブ・モード構文
revokePermission([appStripe="appName",][codeBaseURL="url",] [principalClass="prClassName",] [principalName="prName",] permClass="permissionClassName", [permTarget="permName",] [permAction="comma_separated_list_of_actions"])
引数（オプションの引数は、大カッコで囲んであります）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。指定されていない場合、コマンドはシステム・ポリシーに対して機能します。
codeBaseURLでは、パーミッションが付与されたコードのURLを指定します。
principalClassでは、完全修飾クラス名を指定します（権限受領者）。
principalNameでは、権限受領者プリンシパルの名前を指定します。
permClassでは、パーミッション・クラスの完全修飾名を指定します
permTargetでは、パーミッション・ターゲットの名前を指定します（使用可能な場合）。この属性が含まれていないパーミッションがあることに注意してください。
permActionでは、削除するアクションのリストを指定します。この属性が含まれていないパーミッションがあり、使用できるアクションはパーミッション・クラスによって異なることに注意してください。
使用例
次の呼出しでは、指定したデータを持つアプリケーション・パーミッションが（アプリケーション・ストライプmyAppを持つアプリケーションに対して）削除されます。
revokePermission.py -appStripe myApp
-principalClass my.custom.Principal
-principalName manager
-permClass java.security.AllPermission
次の呼出しでは、指定したデータを持つシステム・パーミッションが削除されます。
revokePermission.py -principalClass my.custom.Principal
-principalName manager
-permClass java.io.FilePermission
-permTarget /tmp/fileName.ext
-permAction read,write
コマンドlistPermissionsによって、指定したプリンシパルに付与されたすべてのパーミッションがリストされます。
スクリプト・モード構文
listPermissions [-appStripe appName] -principalClass className -principalName prName
インタラクティブ・モード構文
listPermissions([appStripe="appName",] principalClass="className", principalName="prName")
引数（オプションの引数は、大カッコで囲んであります）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。指定されていない場合、コマンドはシステム・ポリシーに対して機能します。
principalClassでは、完全修飾クラス名を指定します（権限受領者）。
principalNameでは、権限受領者プリンシパルの名前を指定します。
使用例
次の呼出しでは、アプリケーションmyAppのポリシーによってプリンシパルに付与されたすべてのパーミッションがリストされます。
listPermissions.py -appStripe myApp
-principalClass my.custom.Principal
-principalName manager
次の呼出しでは、システム・ポリシーによってプリンシパルに付与されたすべてのパーミッションがリストされます。
listPermissions.py -principalClass my.custom.Principal
-principalName manager
コマンドdeleteAppPoliciesによって、指定したアプリケーション・ストライプを持つすべてのポリシーが削除されます。
スクリプト・モード構文
deleteAppPolicies -appStripe appName
インタラクティブ・モード構文
deleteAppPolicies(appStripe="appName")
引数（必須）の意味は、次のとおりです。
appStripeでは、アプリケーション・ストライプを指定します。指定されていない場合、コマンドはシステム・ポリシーに対してのみ機能します。
使用例
deleteAppPolicies -appStripe myApp
コマンドreassociateSecurityStoreによって、指定したドメイン内で、ポリシー・ストアと資格証明ストアの両方がターゲットLDAPサーバー・リポジトリに移行されます。このコマンドの機能は、Fusion Middleware Controlを使用したドメイン・ストアの再関連付けと同じです。
ターゲットとして使用できるLDAPサーバーは、Oracle Internet DirectoryとOracle Virtual Directoryのみです。ソース・リポジトリは、ファイルベースでもLDAPベースでもかまいません。このコマンドでは、ドメイン構成ファイルjps-config.xmlを使用し、またそれを変更します。このコマンドは、インタラクティブ・モードでのみ使用できます。
このコマンドを発行する前に、「LDAPベースのポリシー・ストアを使用する場合の前提条件」で説明する前提条件を満たしていることを確認してください。
Fusion Middleware Controlを使用して再関連付けを行う方法は、「Fusion Middleware Controlを使用したドメイン・ストアの再関連付け」を参照してください。
この操作でターゲット・ストアへの一方向SSL接続を使用する場合は、このコマンドを呼び出す前に「一方向SSL接続の設定」の説明にある手順を実行します。
再関連付けの後、Oracle Internet Directoryストアのルート・ノードへのアクセスを保護するために、「Oracle Internet Directoryノードへのアクセスの保護」で説明する手順を実行してください。
インタラクティブ・モード構文
reassociateSecurityStore(domain="domainName", admin="cnSpecification", password="passWord", ldapurl="hostAndPort", servertype="ldapSrvrType", jpsroot="cnSpecification")
引数（すべて必須）の意味は、次のとおりです。
domainでは、再関連付けが実行されるドメイン名を指定します。
adminでは、LDAPサーバー上の管理者のユーザー名を指定します。形式は、cn=usrNameです。
passwordでは、引数adminに対して指定したユーザーと関連付けられたパスワードを指定します。
ldapurlでは、LDAPサーバーのURIを指定します。デフォルトのポートを使用する場合の形式は、ldap//:host:portです。匿名SSLまたは一方向SSL伝送を使用する場合の形式は、ldaps://host:portです。目的のSSL接続モードを扱うことができるようにセキュア・ポートを構成する必要があります。また、このセキュア・ポートは、デフォルトの（セキュアではない）ポートとは別のポートとする必要があります。
servertypeでは、ターゲットLDAPサーバーの種類を指定します。有効なタイプはOID（Oracle Internet Directory）とOVD（Oracle Virtual Directory）のみです。
jpsrootでは、ターゲットLDAPリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。
使用例
reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")
この項では、Fusion Middleware Controlの「セキュリティ・プロバイダ構成」ページを使用してプロパティおよびプロパティ・セットを構成する方法について説明します。
|
注意: 「セキュリティ・プロバイダ構成」ページの「Web Services Managerの認証プロバイダ」領域は、Web Services Managerのログイン・モジュールとキーストアの構成にのみ関連します。ADFアプリケーションとJavaEEアプリケーションには関連しません。キーストアについて: キーストアの構成は変更しないでください。キーストアの設定を変更する場合は、まず既存の構成を削除し（「キーストアの構成」チェック・ボックスの選択を解除し、「OK」をクリックする）、その後で新しい構成を指定します。この手順に従わなかった場合、エラーや予期しない動作が発生します。 使用可能なログイン・モジュール、それらのパラメータ、およびそれらのコンポーネントのキーストアの詳細は、『Oracle Fusion Middleware Security and Administrator's Guide for Oracle Web Services』の第9章を参照してください。 |
プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。
OPSS構成プロパティのリストは、付録F「OPSS構成プロパティ」を参照してください。
プロパティおよびプロパティ・セットの定義には、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlで<property>要素と<properySet>要素を使用します。プロパティ・セットは、<propertySetRef>要素で参照できます。
Fusion Middleware Controlを使用してプロパティまたはプロパティ・セットを定義する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて、ページの下部にある「拡張プロパティ」領域を開き、「構成」をクリックして「拡張プロパティ」ページを表示します。このページで、プロパティおよびプロパティ・セットを入力できます。
プロパティを入力するには、「プロパティ」領域の「追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。完了したら、「OK」をクリックします。入力したプロパティが「プロパティ」の表に表示されます。
プロパティ・セットを入力するには、「プロパティ・セット」領域の「プロパティ・セットの追加」をクリックして「プロパティ・セットの追加」ダイアログ・ボックスを表示し、プロパティ・セット名を入力します。
プロパティ・セットにプロパティを入力するには、既存のプロパティ・セットを選択し、「プロパティの追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。入力したプロパティが、選択したプロパティ・セットのプロパティのリストに追加されます。
どの表でも、選択した項目をその表から削除するには、「削除」ボタンを使用します。プロパティおよびプロパティ・セットの入力または編集が完了したら、「OK」をクリックします。
Oracle WebLogic Serverを再起動します。サーバーが再起動するまで、変更は有効になりません。
プロパティ・セットを追加または削除するとドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されますが、サーバーを再起動しないかぎり、その変更は有効になりません。
前述の手順で追加した<property>要素と<propertySet>要素は、<jpsConfig>要素の直下に挿入されます。
