| Oracle® Fusion Middlewareアプリケーション・セキュリティ・ガイド 11gリリース1（11.1.1） B56235-02 |
|
 戻る |
 次へ |
ドメイン・ポリシー・ストアは、システム・ポリシーおよびアプリケーション固有のポリシーのリポジトリです。ドメインには、そのドメインにデプロイしたすべてのアプリケーションで使用できるすべてのポリシー（および資格証明）を格納するストアが1つあります。
ポリシー・ストアの主な機能の概要は、「ポリシー・ストアの基本」を参照してください。
この章の内容は次のとおりです。
JavaEEおよびWebLogicセキュリティの詳細は、『Oracle Fusion Middleware Understanding Security for Oracle WebLogic Server』のJ2EEおよびWebLogicのセキュリティに関する項を参照してください。
|
注意: この章の説明のように、ポリシー・ストアに基づいてポリシーを使用するようにドメインをセットアップする場合、そのドメイン内のすべての管理対象サーバーに対してJACCポリシーおよびJavaセキュリティ・マネージャが使用不可になります。 |
LDAPベースのポリシー・ストアは本番環境に適しているので、本番環境での使用をお薦めします。今回のリリースでサポートされているLDAPサーバーは、Oracle Internet Directoryです。
ドメイン・ポリシー・ストアの特性とドメイン資格証明ストアの特性は、緊密に相関しており、両方を同じ種類（ファイルベースまたはLDAPベース）にする必要があります。LDAPベースのリポジトリを使用する場合は、両方で同じタイプのLDAPサーバーを使用する必要があります。追加設定なしの状態では、ポリシー・ストアも資格証明ストアもファイルベースです。
ドメインでLDAPベースのポリシー・ストアを使用する場合、ドメイン管理者は必要に応じてOracle Enterprise Manager Fusion Middleware ControlまたはWLSTコマンドを使用し、そのポリシー・ストアを構成する必要があります。
サービス・インスタンスで指定できるプロパティの詳細なリストは、付録F「LDAPの汎用的なプロパティ」を参照してください。
この項の内容は次のとおりです。
サーバー・インスタンスが複数のマシンに分散しているドメインでは、ドメインのポリシー・ストアおよび資格証明ストアをLDAPベースとし、1つのストアにすべてのポリシー・データおよび資格証明データを格納して、そこで集中管理することを強くお薦めします。
通常、アプリケーションによってポリシー・データが変更されることはありません。そのような変更が発生した場合は、それらの変更がドメインにあるすべての管理対象サーバーとクラスタに適切に伝播されることが重要です。したがって、このような変更は、管理対象サーバーではなく、必ずドメイン管理サーバーで実行する必要があります。
単一ノード・サーバー・ドメインの場合は、セキュリティ・データのローカル変更の伝播を考慮する必要はありません。このシナリオでは、ローカル変更はグローバル変更と同じです。
一方、複数ノード・サーバー・ドメインの場合は、ファイルベースのポリシーに対するローカル変更がJMXフレームワークによって各ランタイム環境に伝播され、キャッシング・ポリシーおよび構成に基づいてデータがリフレッシュされます。
要約すると、複数ノード・サーバー環境における推奨事項は次のとおりです。
ドメイン・ポリシー・ストアとドメイン資格証明ストアの両方をLDAPベースのストアで集中管理し、管理サーバーで構成します。
ストアがファイルベースの場合は、ポリシー・データまたは資格証明データに対するローカル変更をドメイン管理サーバーでのみ実行して、管理サーバーからドメイン内のすべての管理対象サーバーにローカル変更が適切に伝播されるようにします。
Oracle Internet Directoryへの適切なアクセスを確実に実現するには、サーバー・ディレクトリにノードを設定する必要があります。
Fusion Middleware Controlを使用してLDAPベースのリポジトリに再関連付けするときに、ブートストラップ資格証明がファイルcwallet.ssoに自動的に設定されます。手動で指定する場合は、第14.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"
次の例に示すように、ユーティリティoidstats.sqlを実行して、データベースのパフォーマンスを最適にするためにデータベース統計を生成します。
>$ORACLE_HOME/ldap/admin/oidstats.sql
前述のユーティリティの実行が必要なのは、初期プロビジョニング後の1回のみです。このユーティリティの詳細は、『Oracle Fusion Middleware Oracle Identity Managementユーザー・リファレンス』を参照してください。
ポリシー・ストアの再関連付けの方法は、「ドメイン・ポリシー・ストアの再関連付け」を参照してください。
ポリシー・ストアの再関連付けとは、ファイルベースまたはLDAPベースのリポジトリからLDAPベースのリポジトリにポリシー・データを移行することです。つまり、再関連付けでは、格納されているデータの整合性を保持したまま、リポジトリを変更します。ソース・ポリシー・ストアのポリシーごとに、再関連付けによって、ターゲットLDAPディレクトリが検索され、一致するものが見つかると、その一致したポリシーが必要に応じて更新されます。見つからない場合は、そのポリシーがそのまま移行されます。
ドメイン・ポリシー・ストアをインスタンス化すると、ファイルベースまたはLDAPベースのポリシー・ストアを、同じデータを格納しているLDAPベースのポリシー・ストアに再関連付けできます。この操作をサポートするには、必要に応じて、LDAPポリシー・ストアを使用するようにドメインを構成する必要があります。
再関連付けを行うには、Fusion Middleware ControlまたはWLSTコマンドreassociateSecurityStoreを使用します。この操作は通常、追加設定がない場合に使用されるファイル・ベースのドメイン・ストアではなく、LDAPベースのストアを使用するようにドメインを設定するときに実行します。
|
重要: ポリシー・ストアおよび資格証明ストアのリポジトリは、両方ともファイルベースであるか、両方ともLDAPベースである必要があります。さらに、LDAPベースの場合、両方のストアが同じ種類のLDAPサーバーを使用する必要があります。この一貫性を保持するために、1つのストアの再関連付けは、もう一方のストアの再関連付けを意味することに注意してください。 |
セキュリティ・ストアの再関連付けによって、リポジトリ間でポリシーおよび資格証明が移行され、それらのセキュリティ・ストア・プロバイダが再構成されます。この再構成は通常、テスト環境から本番環境への移行時などに行われます。OPSSでは、LDAPベースからLDAPベースへの再関連付けとファイルベースからLDAPベースへの再関連付けがサポートされています。この場合のLDAPサーバーは、Oracle Internet Directoryです。LDAPベースからファイルベースへの再関連付けはサポートされていません。
この項では、Oracle Internet Directoryサーバーを使用するLDAPベースの記憶域にポリシーおよび資格証明を再関連付けする手順について説明します。
ドメイン・ストアを手動で再関連付けするには、WLSTコマンドreassociateSecurityStoreを使用します。
「セキュリティ・プロバイダ構成」ページのその他の使用方法は、「Oracle Fusion Middleware Controlを使用したその他のアーティファクトの構成」を参照してください。
|
注意:
|
Fusion Middleware Controlを使用して、指定したドメイン内のポリシー・ストアと資格証明ストアの両方を新しいLDAPリポジトリに再関連付けする手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。このページの一部を次の図に示します。
「アソシエーションの変更」ボタンの下の表に、ドメインに現在構成されているプロバイダの特性が表示されます。
「ポリシー・ストア・プロバイダと資格証明ストア・プロバイダ」領域の「アソシエーションの変更」ボタンをクリックして、「セキュリティ・プロバイダの設定」ページを表示します。そのページの一部を図7-1に示します。
「LDAPサーバーの詳細」領域で、ターゲットLDAPサーバーに関する詳細および接続情報を指定します。
ターゲットOID 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認証のテスト」ボタンをクリックします。接続の問題が発生した場合は、第J.10項「匿名SSL接続の確立の失敗」を参照してください。
「LDAPルート・ノードの詳細」領域で、「JPSルートDN」ボックスにルートDNを入力します。ルートDNは、LDAPリポジトリにあるデータを表すツリーの最上位レベルを示します。デフォルトでは、選択したドメインの名前が「ドメイン名」に表示されています。
この2つのフィールドで指定した値が原因となって発生することが多いエラーを解決するには、第J.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が変更されます。古いストア・プロバイダの構成がすべて削除され、新しいストア・プロバイダの構成が追加されます。それにより、ポリシーと資格証明に関する情報が移行元ストアから移行先ストアに移動します。
移行先ストアがLDAPベースの場合、これらの情報は次の形式に従ってドメインDNの下位に保存されます。
cn=<domain_name>,cn=JpsContext,<JPS ROOT DN>
インストールの構成が上位のドメインDNに依存しているかぎり、その上位ドメインのノードはLDAPサーバーから削除しないでください。
この項では、ドメイン・ストアを再関連付けするために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」を参照してください。
検索フィルタで使用するOracle Internet Directoryの属性は、索引を作成したうえでカタログ化する必要があります。索引作成やカタログ化は必須ではありませんが、OPSS関連の属性に適用するとパフォーマンスが向上するので実施をお薦めします。
本番環境では、ドメイン・ポリシー・ストアの再関連付けが完了してから属性の索引作成とカタログ化を実行することをお薦めします。
属性のカタログの管理と属性の索引が作成済であることの確認の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項を参照してください。
Oracle Directory Services Managerを使用して新規属性に索引を追加する方法に関する項
Oracle Directory Services Managerを使用して既存属性に索引を追加する方法に関する項
Oracle Directory Services Managerを使用して属性から索引を削除する方法に関する項
Oracle Directory Services Managerを使用して、データを格納済の属性に索引を作成する方法に関する項
カタログを使用して既存属性に索引を作成する方法と索引を削除する方法に関する項
次に示す構文を持つコマンドldapmodifyを使用して、LDIFファイルで指定した属性に索引を作成することもできます。
>ldapmodify -h <host> -p <port> -D <bind DN> -w <bind password> -v -f <catalogue modify ldif file name>
たとえば、次のサンプルLDIFファイルで前述のコマンドを使用して、createtimestamp属性とmodifytimestamp属性をカタログ化できます。
dn: cn=catalogs changetype: modify add: orclindexedattribute orclindexedattribute: modifytimestamp orclindexedattribute: createtimestamp
次のOracle Internet Directoryの各属性には索引を作成する必要があります。
orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee
1つのドメインに設定できるポリシー・ストアは1つのみです。アプリケーションで独自のポリシーを指定することはできますが、アプリケーションをサーバーにデプロイすると、アプリケーションのポリシーはそのドメイン・ポリシー・ストアのポリシーとして格納されます。したがって、ドメインにデプロイされたすべてのアプリケーションは、共通のポリシー・ストアであるドメイン・ポリシー・ストアを使用します。ドメイン・ポリシー・ストアは、論理的に複数のストライプにパーティション化されており、ファイル$DOMAIN_HOME/config/fmwconfig/system-jazn-data.xmlの<applications>要素で指定したアプリケーション名ごとにストライプが1つずつあります。
アプリケーションの開発時に独自のポリシーをアプリケーションで指定しておくと、Fusion Middleware Controlを使用してアプリケーションをデプロイするときに、これらのポリシーをドメイン・ポリシー・ストアに移行できます。ポリシーを手動で移行することもできます。この場合は、匿名ユーザー、匿名ロール、認証ロールおよびJAASモードの使用をアプリケーションのコンポーネントごとに指定できます。
ドメイン・ポリシー・ストアの構成は、ドメイン管理者が行います。
この章の内容は次のとおりです。
アプリケーション・ポリシーは、アプリケーション・ファイルjazn-data.xmlで指定し、Fusion Middleware Controlを使用してWebLogic環境のサーバーにアプリケーションをデプロイするときにドメイン・ポリシー・ストアに移行できます。また、これらは、アプリケーションをアンデプロイするときにドメイン・ポリシー・ストアから削除したり、アプリケーションを再デプロイするときに更新することもできます。
アプリケーション・ポリシーの移行、削除および更新の3つの操作はすべて、ポリシー・リポジトリのタイプに関係なく実行できますが、特定の構成が必要です。
詳細は、第6.5.2項「デプロイ時のポリシーおよび資格証明の移行」の手順を参照してください。
アプリケーション固有のポリシーまたはシステム・ポリシーは、WLSTコマンドmigrateSecurityStoreを使用してソース・リポジトリからターゲット・リポジトリに手動で移行できます。
このコマンドはオフラインなので、実行中のサーバーに接続しなくても機能します。したがって、引数configFileで渡す構成ファイルは実際のドメイン構成ファイルである必要はなく、移行のソース・リポジトリとターゲット・リポジトリを指定するようにアセンブルするだけで済みます。
|
注意: コマンドmigrateSecurityStoreではGUIDが再作成されるので、大量のデータを移行する場合は長時間を要します。そのため、Oracle Internet Directoryの一括操作を使用する別の手順によるストアの移行を検討することをお薦めします。詳細は、第6.5.2.3項「大量のポリシー・ストアおよび資格証明ストアの移行」を参照してください。 |
WLSTコマンドとその構文の詳細は、『Oracle Fusion Middleware WebLogic Scripting Toolコマンド・リファレンス』のWLSTコマンドのカテゴリの概要に関する項を参照してください。
すべてのポリシー（システム・ポリシーおよびすべてのアプリケーションのアプリケーション固有のポリシー）を移行するには、スクリプト（1番目）またはインタラクティブな（2番目）構文を使用します（明確にするために引数は別の行に記述）。
migrateSecurityStore.py -type policyStore
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
migrateSecurityStore(type="policyStore", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")
引数（すべて必須）の意味は、次のとおりです。
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の名前を指定します。
srcおよびdstで渡すコンテキストは、渡される構成ファイル内で定義し、一意である必要があります。これら2つのコンテキストから、このコマンドは移行に関与するソース・リポジトリおよびターゲット・リポジトリの位置を特定します。
システム・ポリシーのみを移行するには、スクリプト（1番目）またはインタラクティブな（2番目）構文を使用します（明確にするために引数は別の行に記述）。
migrateSecurityStore.py -type globalPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
migrateSecurityStore(type="globalPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext")
引数（すべて必須）の意味は、前述の場合と同じです。
1つのアプリケーションのアプリケーション固有のポリシーのみを移行するには、スクリプト（1番目）またはインタラクティブな（2番目）構文を使用します（明確にするために引数は別の行に記述）。
migrateSecurityStore.py -type appPolicies
-configFile jpsConfigFileLocation
-src srcJpsContext
-dst dstJpsContext
-srcApp srcAppName
[-dstApp dstAppName]
[-overWrite trueOrfalse]
[migrateIdStoreMapping trueOrfalse]
[mode laxOrstrict]
migrateSecurityStore(type="appPolicies", configFile="jpsConfigFileLocation", src="srcJpsContext", dst="dstJpsContext", srcApp="srcAppName", [dstApp="dstAppName"], [overWrite="trueOrfalse"], [migrateIdStoreMapping="trueOrfalse"], [mode="strict"])
configFile、srcおよびdstの各引数の意味は、前述の場合と同じです。その他の5つの引数の意味は次のとおりです。
srcAppでは、ソース・アプリケーションの名前、つまり、ポリシーを移行するアプリケーションの名前を指定します。
dstAppでは、ターゲット・アプリケーションの名前、つまり、ポリシーを書き込むアプリケーションの名前を指定します。指定しない場合は、デフォルトでソース・アプリケーションの名前になります。
migrateIdStoreMappingでは、エンタープライズ・ポリシーを移行するかどうかを指定します。デフォルト値はTrueです。エンタープライズ・ポリシーを移行の対象から除外する場合、つまりアプリケーション・ポリシーのみを移行する場合は、Falseに設定します。
overWriteでは、ソース・ポリシーと一致するターゲット・ポリシーをソース・ポリシーで上書きするか、ソース・ポリシーとマージするかを指定します。ターゲット・ポリシーを上書きする場合はTrueに設定し、一致するポリシーをマージする場合はFalseに設定します。この引数はオプションです。指定しなかった場合は、デフォルトでFalseに設定されます。
modeでは、移行を停止して、アプリケーション・ポリシーでプリンシパルまたはパーミッションが重複していることを示すエラーを送信するかどうかを指定します。何も指定しないか、LAXに設定します。LAXに設定すると、重複項目があっても移行が継続して、重複項目のいずれかのみが移行し、この効果に対する警告がログに記録されます。
前述の構文要件に一致しない入力を指定すると、コマンドの実行に失敗し、エラーが返されます。特に、入力は次の要件を満たす必要があります。（a）渡された位置内でファイルjps-config.xmlが検出されること、（b）渡されたjps-contextsがファイルjps-config.xmlに含まれていること、（c）ソースおよびターゲットのコンテキスト名が一意であること。
次の項では、Fusion Middleware Control、WLSTコマンドまたはOracle Authorization Policy Managerを使用して管理者がポリシーを管理する方法について説明します。代表的な操作は次のとおりです。
既存のアプリケーション・ロールの権限の変更
プリンシパルのパーミッションの取消し
アプリケーション・ロールの作成と削除
すべてのアプリケーション・ロール、およびアプリケーション・ロールのすべてのメンバーのリスト
ドメイン・ポリシー・ストアのデータにアクセスできるのは、ドメイン管理者など、適切なパーミッションを持つユーザーのみです。
予期しない認可の失敗を防ぎ、効果的にポリシーを管理するには、次の重要ポイントに注意してください。
|
重要ポイント1: ユーザーを削除する前に、ユーザーに付与されているすべてのパーミッション、アプリケーション・ロールおよびエンタープライズ・グループを取り消します。削除対象のユーザーを参照するセキュリティ・アーティファクトが残っていると、これらは中途半端に孤立した状態になり、同じ名前またはuidを持つ別のユーザーを後で作成したときに誤って継承される可能性があります。ユーザー名またはuidを変更する場合にも、同様の考え方が当てはまります。古いデータを参照するすべてのポリシー（権限付与、パーミッション、グループ）を更新して、変更後のデータでも予期したとおりに機能するようにする必要があります。 第J.12,項「ユーザーによる予期しないパーミッションの取得」を参照してください。 |
|
重要ポイント2: ポリシーの適用時には、名前の大文字と小文字が区別されます。ユーザー名またはグループ名の大文字と小文字の違いによる認可エラーを防ぐ最善の方法は、アイデンティティ・ストアで指定されているとおりの文字構成による名前を使用することです。そのため、次のことをお薦めします。
第J.6項「パーミッションの付与または取消しの失敗 - 大文字と小文字の不一致」を参照してください。 |
|
重要ポイント3: ポリシー・ストア内の文字列には、[0, 15]の範囲の特殊なASCII文字を使用できません。ポリシー・ストア内の文字の使用に関するその他の問題は、第J.16項「ポリシーに使用する文字」を参照してください。 |
Fusion Middleware Controlでは、次の項の説明のように、ドメインで使用しているポリシー・ストア・プロバイダのタイプに関係なく、WebLogicドメインでシステム・ポリシーおよびアプリケーション・ポリシーを管理できます。
この項では、Fusion Middleware Controlを使用してデプロイ済アプリケーションのポリシーを管理する手順（既存のアプリケーション・ロールのパーミッション付与の変更など）について説明します。システム・ポリシーの管理方法は、「システム・ポリシーの管理」を参照してください。
Fusion Middleware Controlにログインし、「アプリケーション名」→「セキュリティ」→「アプリケーション・ポリシー」に移動して、選択したアプリケーションの「アプリケーション・ポリシー」ページを表示します。このページの一部を次の図に示します。
「ポリシー・ストア・プロバイダ」領域は読取り専用です。この領域を開くと、アプリケーションのデプロイ先ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
|
注意: 最初、このページにポリシーとロールが表示されていない場合は、青いボタンをクリックするとすべての項目が表示されます。 |
指定したプリンシパルまたはパーミッションに一致する既存のアプリケーション・ポリシーを表示するには、「検索」領域を開き、一致を必要とするデータ（プリンシパル名、パーミッション名またはその両方）を入力して、青いボタンをクリックします。検索の結果がページの下部の表に表示されます。
|
注意: 選択したアプリケーションがアプリケーション名と異なるポリシー・ストライプ名を使用している場合にのみ、「検索するアプリケーション・ストライプの選択」ボックスが表示されます。この場合には、そのボックスを選択してプルダウン・リストからストライプ名を選択します。 |
アプリケーション・ポリシーを作成するには、「作成」をクリックして、「アプリケーション権限の作成」ページを表示します。ページ上部の「権限の詳細」領域に、アプリケーションに関する読取り専用の情報が表示されます。
作成するポリシーにパーミッションを追加するには、「権限」領域の「追加」をクリックして、「権限の追加」ダイアログ・ボックスを表示します。
「検索」を使用して、クラス名またはリソース名が一致するパーミッションを特定し、パーミッションの「権限クラス」と「リソース名」を決定します。必要に応じ、「カスタマイズ」領域を使用してパーミッションを限定します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。作成したパーミッションが、「権限」領域の表に表示されます。
作成するポリシーにユーザーを追加するには、「権限受領者」領域の「ユーザーの追加」ボタンをクリックして、「ユーザーの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、文字列が一致するユーザー名を特定します。問合せの結果が「使用可能なユーザー」ボックスに表示されます。
様々なボタンを使用して、パーミッションを付与するユーザーを「使用可能なユーザー」ボックスから「選択したユーザー」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。選択したユーザーが、「権限受領者」領域の表に表示されます。
作成するポリシーにアプリケーション・ロールを追加するには、「権限受領者」領域の「アプリケーション・ロールの追加」ボタンをクリックして、「アプリケーション・ロールの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、タイプまたは名前が一致するロール名を特定します。問合せの結果が「使用可能なロール」ボックスに表示されます。
様々なボタンを使用して、パーミッションを付与するロールを「使用可能なロール」ボックスから「選択したロール」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。選択したロールが、「権限受領者」領域の表に表示されます。
作成するポリシーにグループを追加するには、「権限受領者」領域の「グループの追加」ボタンをクリックして、「グループの追加」ダイアログ・ボックスを表示します。
「検索」を使用して、文字列が一致するグループ名を特定します。問合せの結果が「使用可能なグループ」ボックスに表示されます。
様々なボタンを使用して、ポリシーの追加先とするグループを「使用可能なグループ」ボックスから「選択したロール」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション権限の作成」ページに戻ります。選択したグループが、「権限受領者」領域の表に表示されます。
この表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。
完了したら、「OK」をクリックして、「アプリケーション・ポリシー」ページに戻ります。作成したポリシーのプリンシパルとパーミッションがページの下部の表に表示されます。
既存のアプリケーション・ポリシーに基づいてアプリケーション・ポリシーを作成する手順は、次のとおりです。
表から既存のポリシーを選択します。
「類似作成」をクリックし、「アプリケーション権限の類似作成」ページを表示します。このページでは、選択したポリシーから抽出されたデータがパーミッションの表に自動的に入力されます。
前述の手順3の下位手順の説明に従い、必要に応じてこれらの値を変更し、ユーザー、アプリケーション・ロールまたはグループを入力して「OK」をクリックします。
この項では、Fusion Middleware Controlを使用してデプロイ済アプリケーションのロールを管理する手順について説明します。ユーザーまたはグループによるリソースへのアクセスを制御する管理操作には、アプリケーション・ロールの作成、ユーザー、グループまたは他のアプリケーション・ロールへのアプリケーション・ロールのマップ、アプリケーション・ロールのメンバーの管理などがあります。
Fusion Middleware Controlにログインし、「アプリケーション名」→「セキュリティ」→「アプリケーション・ロール」に移動して、「アプリケーション・ロール」ページを表示します。このページの一部を次の図に示します。
「ポリシー・ストア・プロバイダ」領域は読取り専用です。この領域を開くと、アプリケーションのデプロイ先ドメインで現在使用しているポリシー・ストア・プロバイダが表示されます。
|
注意: 最初、このページにアプリケーション・ロールが表示されていない場合は、青いボタンをクリックするとすべての項目が表示されます。 |
検索対象のアプリケーション・ロールが設定されているアプリケーションを選択します。アプリケーション名とアプリケーション・ストライプ名が同じ場合は、「検索するアプリケーション名の選択」ラジオ・ボタンを選択し、アプリケーションを選択します。アプリケーション名がアプリケーション・ストライプと異なる場合は、「検索するアプリケーション・ストライプの選択」ラジオ・ボタンを選択し、アプリケーション・ストライプを選択します。
指定した名前と一致するアプリケーション・ロールを表示するには、一致対象のデータを「ロール名」ボックスに入力し、青いボタンをクリックします。問合せの結果がページの下部の表に表示されます。
現在のすべてのアプリケーション・ポリシーの表を再表示するには、「ロール名」を空白のままにし、青いボタンをクリックします。
アプリケーション・ロールを作成するには、「作成」をクリックして、「アプリケーション・ロールの作成」ページを表示します。すべての領域のデータを一度に入力する必要はありません。たとえば、ロール名と表示名を入力してロールを作成し、データを保存しておき、そのロールに属するメンバーを後で指定できます。同様に、後でロール・マッピングのためのデータを入力することもできます。
領域「一般」で、作成するロールの次の属性を指定します。
「ロール名」テキスト・ボックスにロールの名前を入力します。
必要に応じて、ロールに表示する名前を「表示名」テキスト・ボックスに入力します。
オプションで、「説明」テキスト・ボックスに、ロールの説明を入力します。
「メンバー」領域で、作成するロールのマップ先とするユーザーまたはグループを指定します。マップ先とする他のアプリケーション・ロールがある場合は、それを指定します。
作成するアプリケーション・ロールにアプリケーション・ロールを追加する手順は、次のとおりです。
「アプリケーション・ロールの追加」をクリックして、「アプリケーション・ロールの追加」ダイアログ・ボックスを表示します。
このダイアログ・ボックスで、ロールを特定する文字列を「ロール名」ボックスに入力し、その文字列と一致する名前を持つ使用可能なロールを特定して青いボタンをクリックします。問合せの結果が「使用可能なロール」ダイアログ・ボックスに表示されます。
必要に応じて「使用可能なロール」ボックスからロールを選択し、ボックスの間にあるボタンを使用して「選択したロール」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したアプリケーション・ロールが表「ロール」に表示されます。
作成するアプリケーション・ロールにグループを追加する手順は、次のとおりです。
「グループの追加」をクリックして、「グループの追加」ダイアログ・ボックスを表示します。
このダイアログ・ボックスで、グループを特定する文字列を「グループ名」ボックスに入力し、その文字列と一致する名前を持つ使用可能なグループを特定して青いボタンをクリックします。問合せの結果が「使用可能なグループ」ダイアログ・ボックスに表示されます。
必要に応じて「使用可能なグループ」ボックスからグループを選択し、ボックスの間にあるボタンを使用して、「選択したグループ」ボックスにそのグループを移動します。
完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したグループが表「ロール」に表示されます。
作成するアプリケーション・ロールにユーザーを追加する手順は、次のとおりです。
「ユーザーの追加」をクリックして、「ユーザーの追加」ダイアログ・ボックスを表示します。
このダイアログ・ボックスで、ユーザーを特定する文字列を「ユーザー名」ボックスに入力し、その文字列と一致する名前を持つ使用可能なユーザーを特定して青いボタンをクリックします。問合せの結果が「使用可能なユーザー」ダイアログ・ボックスに表示されます。
必要に応じて「使用可能なユーザー」ボックスからユーザーを選択し、ボックスの間にあるボタンを使用して「選択したユーザー」ボックスに移動します。
完了したら、「OK」をクリックして、「アプリケーション・ロールの作成」ページに戻ります。選択したユーザーが、表「ユーザー」に表示されます。
この表にある項目はいつでも削除できます。削除するには、項目を選択して「削除」ボタンをクリックします。同様に、この表の項目を選択して「編集」ボタンをクリックすると、その項目の内容を変更できます。
「OK」をクリックし、ロールの作成（または更新）を完了し、「アプリケーション・ロール」ページに戻ります。作成したロールがそのページの下部の表に表示されます。
既存のアプリケーション・ロールに基づいてアプリケーション・ロールを作成する手順は、次のとおりです。
表から既存のロールを選択します。
「類似作成」をクリックし、「アプリケーション・ロールの類似作成」ページを表示します。このページでは、選択したロールから抽出されたデータがロールの表とユーザーの表に自動的に入力されます。
ロールおよびユーザーのリストを必要に応じて変更し、「OK」をクリックします。
ロール階層でパーミッションがどのように継承されるかを理解するには、第2.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は、アプリケーション・ストライプ（アプリケーション名）を参照します。これによって、特定のアプリケーションに関するドメイン・ポリシーのサブセットを特定します。
認証ロール、匿名ロールおよびWLSTコマンドに関する重要な情報は、第7.4.2.15項「WLSTコマンドを使用した匿名ロールおよび認証ロールへのポリシーの付与」を参照してください。
バージョン管理しているアプリケーションのアプリケーション・ストライプの正しい使用法は、第7.4.2.16項「WLSTコマンドのバージョン付きアプリケーションのアプリケーション・ストライプ」を参照してください。
コマンド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では、クラスの完全修飾名を指定します。このクラスは、実行時に使用できるようにクラスパスで指定しておく必要があります。通常、プリンシパルがユーザーの場合、このクラスはweblogic.security.principal.WLSUserImplであり、プリンシパルがグループの場合、このクラスはweblogic.security.principal.WLSGroupImplです。
principalNameでは、プリンシパル名を指定します。
使用例
次の呼出しでは、デフォルトのプリンシパル実装クラスWLSGroupImplで定義したプリンシパルmyPrincipalが、アプリケーション・ストライプmyAppのロールmyRoleに追加されます。
grantAppRole.py -appStripe myApp
-appRoleName myRole
-principalClass weblogic.security.principal.WLSGroupImpl
-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では、プリンシパル名を指定します。
使用例
次の呼出しでは、デフォルトのプリンシパル実装クラスWLSGroupImplで定義したプリンシパルmyPrincipalが、アプリケーション・ストライプmyAppのロールmyRoleから削除されます。
revokeAppRole.py -appStripe myApp
-appRoleName myRole
-principalClass weblogic.security.principal.WLSGroupImpl
-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] [-permActions comma_separated_list_of_actions]
インタラクティブ・モード構文
grantPermission([appStripe="appName",] [codeBaseURL="url",] [principalClass="prClassName",] [principalName="prName",] permClass="permissionClassName", [permTarget="permName",] [permActions="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
-permActions read,write
コマンドrevokePermissionによって、アプリケーションまたはグローバル・ポリシー・セクションで定義されたプリンシパルまたはコードベースからパーミッションが削除されます。
スクリプト・モード構文
revokePermission [-appStripe appName] [-codeBaseURL url] [-principalClass prClassName] [-principalName prName] -permClass permissionClassName [-permTarget permName] [-permActions comma_separated_list_of_actions]
インタラクティブ・モード構文
revokePermission([appStripe="appName",][codeBaseURL="url",] [principalClass="prClassName",] [principalName="prName",] permClass="permissionClassName", [permTarget="permName",] [permActions="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
-permActions 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
コマンドcreateResourceTypeでは、特定のアプリケーション・ストライプにあるドメイン・ポリシー・ストアに、指定した名前、表示名、説明およびアクションが設定された新規<resource-type>エントリが挿入されます。オプションの引数は角カッコで囲まれています。それ以外のすべての引数は必須です。
スクリプト・モード構文
createResourceType -appStripe appStripeName -resourceTypeName resTypeName -displayName displName -description descripString [-provider resTypeProvider] [-matcher resTypeClass] -actions resTypeActions [-delimiter delimChar]
インタラクティブ・モード構文
createResourceType(appStripe="appStripeName", resourceTypeName="resTypeName", displayName="displName", description="descripString" [, provider="resTypeProvider", matcher="resTypeClass"], actions="resTypeActions"[, delimiter="delimChar"])
引数の意味は、次のとおりです。
appStripeでは、リソース・タイプの挿入先のアプリケーション・ストライプを指定します。
resourceTypeNameでは、挿入するリソース・タイプの名前を指定します。
displayNameでは、UIガジェットで使用するリソース・タイプの名前を指定します。
descriptionでは、リソース・タイプの簡単な説明を指定します。
providerでは、リソース・タイプのプロバイダを指定します。
matcherでは、リソース・タイプのクラスを指定します。指定しなかった場合には、デフォルトのoracle.security.jps.ResourcePermissionに設定されます。
actionsでは、リソース・タイプのインスタンスに許可されたアクションを指定します。
delimiterでは、アクションのリストを区切る際に使用する文字を指定します。指定しなかった場合は、デフォルトのカンマ','に設定されます。
使用例
次の呼出しでは、セミコロンで区切って指定したアクションBWPrintおよびアクションColorPrintを設定したリソース・タイプがストライプmyApplicationに作成されます。
createResourceType -appStripe myApplication
-resourceTypeName Printer
-displayName PRINTER
-description A resource type representing a Printer
-provider Printer
-matcher com.printer.Printer
-allowedActions BWPrint;ColorPrint
-delimiter ;
コマンドgetResourceTypeでは、特定のアプリケーション・ストライプにあるドメイン・ポリシー・ストアから、指定した名前の<resource-type>エントリの関連パラメータが返されます。
スクリプト・モード構文
getResourceType -appStripe appStripeName -resourceTypeName resTypeName
インタラクティブ・モード構文
getResourceType(appStripe="stripeName", resourceTypeName="resTypeName")
引数の意味は、次のとおりです。
appStripeでは、リソース・タイプのフェッチ元のアプリケーション・ストライプを指定します。
resourceTypeNameでは、フェッチするリソース・タイプの名前を指定します。
使用例
次の呼出しでは、ストライプmyApplicationからリソース・タイプmyResTypeがフェッチされます。
getResourceType -appStripe myApplication
-resourceTypeName myResType
コマンドdeleteResourceTypeでは、渡したアプリケーション・ストライプから、指定した名前のリソース・タイプが削除されます。このコマンドは、指定のリソース・タイプのリソース・インスタンスを使用するすべてのパーミッション・セット（権限）とすべての権限から、そのリソース・タイプのすべてのリソース・インスタンスを削除することで連鎖的な削除を適用します。
スクリプト・モード構文
deleteResourceType -appStripe appStripeName -resourceTypeName resTypeName
インタラクティブ・モード構文
deleteResourceType(appStripe="stripeName", resourceTypeName="resTypeName")
引数の意味は、次のとおりです。
appStripeでは、リソース・タイプの削除元のアプリケーション・ストライプを指定します。
resourceTypeNameでは、削除するリソース・タイプの名前を指定します。
使用例
次の呼出しでは、ストライプmyApplicationからリソース・タイプmyResTypeが削除されます。
deleteResourceType -appStripe myApplication
-resourceTypeName myResType
コマンドreassociateSecurityStoreでは、指定したドメインの中でポリシー・ストアと資格証明ストアの両方がターゲットLDAPサーバー・リポジトリに移行されます。デフォルトのポリシー・サービスと資格証明サービスはターゲット・リポジトリのものに変更されます。また、このドメインのポリシー・ストアと資格証明ストアを別のドメインで共有する指定も可能です（次に説明するオプションの引数joinを参照）。
このコマンドの機能は、Fusion Middleware Controlを使用したドメイン・ストアの再関連付けと同じです。
ターゲットとしてサポートされているサーバーは、LDAPベースのOracle Internet 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" [,join="trueOrfalse"])
引数（すべて必須）の意味は、次のとおりです。
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）のみです。
jpsrootでは、ターゲットLDAPリポジトリのルート・ノードを指定します。すべてのデータがその下に移行されます。形式は、cn=nodeNameです。
joinでは、ドメインがポリシー・ストアを別のドメインと共有するかどうかを指定します（オプション）。trueに設定すると既存のストアを別のドメインと共有します。falseを設定すると共有しません。この引数を使用することにより、複数のWebLogicドメインから同一の論理ポリシー・ストアを指定できるようになります。
使用例
reassociateSecurityStore(domain="myDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode")
myDomainとは別のドメイン（otherDomainなど）のいくつかで、myDomainにあるポリシー・ストアを共有できるようにするとします。その場合は、このコマンドを次のように呼び出します。
reassociateSecurityStore(domain="otherDomain", admin="cn=adminName", password="myPass", ldapurl="ldaps://myhost.example.com:3060", servertype="OID", jpsroot="cn=testNode", join="true")
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コマンドの中には、アプリケーション・ストライプの指定を必要とするものがあります。アプリケーションがバージョン付きではない場合は、アプリケーション・ストライプがデフォルトのアプリケーション名として使用されます。アプリケーションがバージョン付きである場合、アプリケーション名とアプリケーション・ストライプは異なります。
たとえば、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
Oracle Internet Directory LDAPポリシー・ストアを使用するWebLogicドメインでは、Oracle Authorization Policy Managerを使用して、アプリケーション・ポリシーと他のセキュリティ・アーティファクトを管理および検索でき、さらに外部ロールとアプリケーション・ロールとの多対多マッピングを管理できます。
詳細は、Oracle Authorization Policy Manager管理者ガイドの次の章を参照してください。
セキュリティ・アーティファクトの問合せ
セキュリティ・アーティファクトの管理
外部ロールに対するアプリケーション・ロールのマッピング
アプリケーション・ロールに対する外部ロールのマッピング
この項では、Fusion Middleware Controlを使用して、ユーザー/ロールAPI、プロパティおよびプロパティ・セットで使用するパラメータを構成し、シングル・サインオン・プロバイダを指定する方法を説明します。この項の内容は次のとおりです。
アイデンティティ・ストアと対話するユーザー/ロールAPIで使用するパラメータを構成する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて、「アイデンティティ・ストア・プロバイダ」領域を開き、「構成」をクリックして、「アイデンティティ・ストア構成」ページを表示します。
必要に応じて、「追加」ボタンと「削除」ボタンを使用してカスタム・プロパティを管理します。
完了したら、「OK」をクリックして設定を保存し、「セキュリティ・プロバイダ構成」ページに戻ります。
プロパティ・セットは、サービス・インスタンスのプロパティまたはドメインの汎用プロパティを定義するために多用するプロパティの集合です。
OPSS構成プロパティのリストは、付録F「OPSS構成プロパティ」を参照してください。
プロパティおよびプロパティ・セットの定義には、ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlで<property>要素と<properySet>要素を使用します。プロパティ・セットは、<propertySetRef>要素で参照できます。
プロパティまたはプロパティ・セットを定義する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて、「拡張プロパティ」領域を開き、「構成」をクリックして「拡張プロパティ」ページを表示します。このページで、プロパティおよびプロパティ・セットを入力できます。
プロパティを入力するには、「プロパティ」領域の「追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。完了したら、「OK」をクリックします。入力したプロパティが「プロパティ」の表に表示されます。
プロパティ・セットを入力するには、「プロパティ・セット」領域の「プロパティ・セットの追加」をクリックして「プロパティ・セットの追加」ダイアログ・ボックスを表示し、プロパティ・セット名を入力します。
プロパティ・セットにプロパティを入力するには、既存のプロパティ・セットを選択し、「プロパティの追加」をクリックして「新規プロパティの追加」ダイアログ・ボックスを表示し、プロパティ名とその値を入力します。入力したプロパティが、選択したプロパティ・セットのプロパティのリストに追加されます。
どの表でも、選択した項目をその表から削除するには、「削除」ボタンを使用します。プロパティおよびプロパティ・セットの入力または編集が完了したら、「OK」をクリックします。
Oracle WebLogic Serverを再起動します。サーバーが再起動するまで、変更は有効になりません。
プロパティ・セットを追加または削除するとドメイン構成ファイル$DOMAIN_HOME/config/fmwconfig/jps-config.xmlが変更されますが、サーバーを再起動しないかぎり、その変更は有効になりません。
前述の手順で追加した<property>要素と<propertySet>要素は、<jpsConfig>要素の直下に挿入されます。
この項では、OPSSシングル・サインオン（SSO）フレームワークを説明し、Fusion Middleware Controlを使用してSSOソリューションを構成する方法を紹介します。この項の内容は、次のとおりです。
OPSS SSOフレームワークにより、ドメインにあるアプリケーションをSSOソリューションに統合できます。具体的には、複数のSSO製品に共通のAPIセットをアプリケーションに提供することで、ログイン、ログアウトおよび自動ログインを処理します。
これらのソリューションの1つであるOAMソリューションは特別な設定をせずに使用でき、次の機能が用意されています。
動的認証: 認証が必要な保護されたアーティファクトの一部にユーザーがアクセスすると、アプリケーションが認証をトリガーし、ユーザーを適切なソリューションで認証できるようにリダイレクトします。
自動ログイン: 最初に匿名でアプリケーションにアクセスしたユーザーが、そのアプリケーションにアカウントを登録します。正常に登録されると、そのユーザーは認証のURLにリダイレクトされます。また、プロンプトの表示なしで自動的にログインすることも可能です。
グローバル・ログアウト: ユーザーが1つのアプリケーションからログアウトすると、OAMソリューションで有効になっているあらゆるアプリケーションにそのログアウトが伝播されます。
OAMソリューションの構成例は、「OAM構成の例」を参照してください。
SSOソリューションでは、ユーザーがアプリケーションにログインおよびログアウトするための標準的な手段を用意する必要があります。ユーザーが正常に認証された後は、SSOサービスがユーザーを適切なURLにリダイレクトします。そのためには、このソリューションの適用先であるドメインが、ログイン前とログアウト後には匿名のユーザーとロールをサブジェクトに追加でき、ログイン後には認証されたロールをサブジェクトに追加できるように構成されていることが前提となります。また、SSOプロバイダが資格証明マッピング・サービスを実装していることも前提となっています。特別な設定を必要とせずに使用できるOAMソリューションの場合、SSOプロバイダは適切なOAMトークンを生成するCredentialMapperServiceを実装しています。
OPSS SSOフレームワークは、複数レベルの認証をサポートしていません。
目的のSSOソリューションと統合するには、そのSSOソリューションを個別にインストールして、適切に構成する必要があります。推奨ソリューションの詳細は、第9章「Oracle Fusion Middlewareでのシングル・サインオンの構成」を参照してください。
ドメインで使用するSSOソリューションを指定する手順は、次のとおりです。
Fusion Middleware Controlにログインし、「ドメイン名」→「セキュリティ」→「セキュリティ・プロバイダ構成」に移動して、「セキュリティ・プロバイダ構成」ページを表示します。
必要に応じて「シングル・サインオン・プロバイダ」領域を開き、「構成」をクリックして、「シングル・サインオン・プロバイダ」ページを表示します。
「シングル・サインオン・プロバイダ」ボックスを選択して、プロバイダのデータを入力できるようにします。このボックスを選択するまで、すべてのボックスはグレー表示になっています。
プルダウン・リストから「プロバイダ・タイプ」を選択し、選択したプロバイダに該当するデータを入力します（データのリストは、選択したプロバイダによって異なります）。
必要に応じ、ページの下部にある「追加」、「編集」および「削除」を使用してプロバイダの「カスタム・プロパティ」を管理します。
完了したら、「OK」をクリックして、入力したデータを保存します。
「Fusion Middleware Controlを使用したSSOソリューションの構成」の手順で入力したSSOサービスの構成は、jps-config.xmlファイルに書き込まれます。指定するデータは次のとおりです。
特定のSSOサービス
自動ログインのURIおよび自動ログアウトのURI
認証レベル
選択したSSOサービスで返されるURLに記述される問合せパラメータ
トークン生成のための適切な設定
jps-config.xmlファイルにある次のコードはOAM SSOプロバイダの構成を示しています。
<propertySets>
<propertySet name = "props.auth.url">
<property name = "login.url.BASIC" value = "http://host:port/oam_login.cgi?level=BASIC"/>
<property name = "login.url.FORM" value = "http://host:port/oam_login.cgi?level=FORM"/>
<property name = "login.url.DIGEST" value = "http://host:port/oam_login.cgi?level= DIGEST"/>
<property name = "autologin.url" value = " http://host:port/obrar.cgi"/>
<property name = "logout.url" value = "http://host:port/logout.cgi"/>
<property name = "param.login.successurl" value = "successurl"/>
<property name = "param.login.cancelurl" value = "cancelurl"/>
<property name = "param.autologin.targeturl" value = "redirectto"/>
<property name = "param.autologin.token" value = "cookie"/>
<property name = "param.logout.targeturl" value = "targeturl"/>
</propertySet>
<propertySet name="props.auth.uri">
<property name="login.url.BASIC" value="/${app.context}/adfauthentication?level=BASIC" />
<property name="login.url.FORM" value="/${app.context}/adfauthentication?level=FORM" />
<property name="login.url.DIGEST" value="/${app.context}/adfauthentication?level=DIGEST" />
<property name="autologin.url" value="/obrar.cgi" />
<property name="logout.url" value="/${app.context}/adfauthentication?logout=true" />
</propertySet>
<propertySet name = "props.auth.level">
<property name = "level.anonymous" value = "0"/>
<property name = "level.BASIC" value = "1"/>
<property name = "level.FORM" value = "2"/>
<property name = "level.DIGEST" value = "3"/>
</propertySet>
<propertySets>
<serviceProviders>
<serviceProvider name = "sso.provider"
class = "oracle.security.jps.internal.sso.SsoServiceProvider"
type = "SSO">
<description>SSO service provider</description>
</serviceProvider>
</serviceProviders>
<serviceInstances>
<serviceInstance name = "sso" provider = "sso.provider">
<propertySetRef ref = "props.auth.url"/>
<propertySetRef ref = "props.auth.level"/>
<property name = "default.auth.level" value = "2"/>
<property name = "token.type" value = "OAMSSOToken"/>
<property name = "token.provider.class" value = "oracle.security.jps.wls.internal.sso.WlsTokenProvider"/>
<property name="sso.provider.class" value="oracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImpl"/>
</serviceInstance>
</serviceInstances>
<jpsContexts default = "default">
<jpsContext name = "default">
<serviceInstanceRef ref = "sso"/>
</jpsContext>
</jpsContexts>
SSOプロバイダの構成については、次の重要な注意点に留意してください。
すべてのSSOプロバイダは、少なくともFORMログイン用のURIをプロパティlogin.url.FORMで定義する必要があります。値はURLである必要はありません。
アプリケーションで自動登録ページのURIまたはURLがサポートされている場合は、それをプロパティautologin.urlで指定する必要があります。
SSOソリューションでグローバル・ログアウトのURIまたはURLがサポートされている場合は、それをプロパティlogout.urlで指定する必要があります。OAMソリューションではグローバル・ログアウトがサポートされています。
前述の例にある次のプロパティはオプションです。
param.login.successurl
param.login.cancelurl
param.autologin.targeturl
param.login.token
param.logout.targeturl
前述の例でプロパティ・セットprops.auth.uri内の値で示された、URI指定の変数app.contextは、ADFアプリケーションがOAMソリューションと統合している場合にのみ使用できます。
SSOプロバイダのサービス・インスタンス内のプロパティsso.provider.classは、固有のSSOソリューションを実装するクラスの完全修飾名です。
OAMソリューションの場合、提供されているクラス名はoracle.security.wls.oam.providers.sso.OAMSSOServiceProviderImplです。
SSOプロバイダのサービス・インスタンス内のプロパティdefault.auth.levelは、上記の例に示されているとおり、2に設定する必要があります。
SSOプロバイダのサービス・インスタンス内のプロパティtoken.typeは必須です。
このトークンのタイプは、正常な認証後にSSOプロバイダが発行するHTTPリクエストのトークン・セットを特定します。2回目以降は、このトークンがSSOプロバイダで使用されるので、ユーザーの再認証が不要となり、ユーザーのサインオンが引き続き有効となります。OAMソリューションの場合、上記の例に示されているとおり、トークン・タイプをOAMSSOTokenとします。
SSOプロバイダのサービス・インスタンス内のプロパティtoken.provider.classは、トークン・クラスの完全修飾名で、プロバイダ固有です。
自動登録論理を実装したアプリケーションで、正常な自動登録後はユーザーが自動的にログインできるようにする場合、そのアプリケーションではOPSS autoLogin APIをコールする必要があります。このコールを可能にするには、クラスがJpsPermissionであるCredentialMappingというコード・ソースのパーミッションをそのアプリケーションに付与する必要があります。
system-jazn-data.xmlファイルにある次のコードでは、アプリケーションMyAppに対してこのパーミッションを指定しています。
<grant>
<grantee>
<codesource>
<url>file:${domain.home}/servers/MyApp/-</url>
</codesource>
</grantee>
<permissions>
<permission>
<class>oracle.security.jps.JpsPermission</class>
<name>CredentialMapping</name>
</permission>
</permissions>
</grant>
この項では、OPSSのパラメータとプロパティの設定方法、およびLDAPベースのポリシー・ストアのプロファイリングについて説明します。
表7-1は、OPSSシステム・プロパティの推奨設定です。これらのプロパティは、通常、Oracle WebLogic Serverを起動するスクリプトで指定します。
表7-1 JVM用のOPSSシステム・プロパティ
| プロパティ名 | 値 | 説明 |
|---|---|---|
|
domain.home |
$DOMAIN_HOME |
このシステム・プロパティの値に応じて異なるコードベースの付与で必要です。 JVMブートストラップ上の制限があることから、このプロパティはコマンドライン・パラメータとして設定する必要があります。 |
|
jps.authz |
ACC |
特別な設定を必要とせずに使用できる現在の設定（DEBUG_ACC）とは異なります。 -Djps.auth=ACCの設定により、実行時とデバッグのオーバーヘッドを削減できます。 |
|
jps.policystore.hybrid.mode |
false |
特別な設定を必要とせずに使用できる現在の設定（true）とは異なります。 -Djps.policystore.hybrid.mode=falseの設定により、実行時のオーバーヘッドを削減できます。 |
|
jps.combiner.optimize |
true |
特別な設定を必要とせずに使用できる現在の設定（false）とは異なります。 -Djps.combiner.optimize=trueの設定により、Java2認証のパフォーマンスが向上します。 |
|
jps.combiner.optimize.lazyeval |
true |
特別な設定を必要とせずに使用できる現在の設定（false）とは異なります。 -Djps.combiner.optimize.lazyeval=trueの設定により、Java2認証のパフォーマンスが向上します。 |
表7-2は、LDAPポリシー・ストア・サービスのどのインスタンスにも必須のプロパティを示しています。インスタンスのプロパティは、第E.1項「WLSTスクリプトを使用したOPSSサービス・プロバイダ・インスタンスの構成」の説明にあるスクリプトを使用して指定および変更できます。
表7-2 LDAPポリシー・ストア・サービスのインスタンスのプロパティ
| 名前 | デフォルト | 推奨値 | 説明 |
|---|---|---|---|
|
oracle.security.jps.policystore.rolemember.cache.type |
STATIC |
STATIC |
ロール・メンバーのキャッシュ・タイプ |
|
oracle.security.jps.policystore.rolemember.cache.strategy |
FIFO |
FIFO |
ロール・メンバーのキャッシュ方針 |
|
oracle.security.jps.policystore.rolemember.cache.size |
1000 |
5000 |
ロール・メンバーのキャッシュ・サイズ |
|
oracle.security.jps.policystore.policy.lazy.load.enable |
true |
true |
ポリシーの遅延ロードの有効化 |
|
oracle.security.jps.policystore.policy.cache.strategy |
PERMISSION_FIFO |
PERMISSION_FIFO |
権限キャッシュの方針 |
|
oracle.security.jps.policystore.policy.cache.size |
1000 |
1000 |
権限キャッシュ・サイズ |
|
oracle.security.jps.policystore.refresh.enable |
true |
true |
LDAPサーバーからのポリシー・ストア・リフレッシュの有効化 |
|
oracle.security.jps.policystore.refresh.purge.timeout |
43200000 |
43200000 |
強制ポリシー・ストア・リフレッシュ時間（ミリ秒） |
|
oracle.security.jps.ldap.policystore.refresh.interval |
600000 |
600000 |
ポリシー・ストア・リフレッシュ・ポーリング時間（ミリ秒） |
表7-3は、いくつかのLDAPポリシー・ストアの実行時APIのタイミングをプロファイルするログ出力を示しています。これらのプロファイラは「Fusion Middleware Control」ページで指定します。詳細は、第J.1.1.4項「Fusion Middleware Controlロギングのサポートの使用」を参照してください。
表7-3 OPSSプロファイラ
| カテゴリ | ログ出力名 | ログ・レベル | プロファイル |
|---|---|---|---|
|
リフレッシュ |
oracle.security.jps.policystore.refresh.full.profiler |
FINE |
ポリシーのリフレッシュにかかる時間 |
|
リフレッシュ |
oracle.security.jps.policystore.refresh.partial.profiler |
FINE |
ポリシーのリフレッシュの際の様々なきめ細かいアクティビティにかかる時間 |
|
ポリシー管理API |
oracle.security.jps.policystore.management.profiler |
FINE |
選択したポリシー管理API（getAllAppRoleEntries、searchAppRoles）にかかる時間 |
|
ポリシー実行時API |
oracle.security.jps.policystore.runtime.profiler |
FINE |
特定のユーザーの直接ロールおよびそのユーザーに付与されたパーミッションのオンデマンド・ロード（キャッシュ・ミス時）にかかる時間 |
|
OPSSフィルタおよびEJBインターセプタ |
oracle.security.jps.policystore.runtime.profiler |
FINE |
OPSSフィルタとOPSS EJBインターセプタで特定のサブジェクトに対するアプリケーション・ロールを計算するためにかかる時間 |
