| Oracle Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for HP-UX Itanium B55937-01 |
|
 戻る |
 次へ |
この章では、次の項でOracle Platform Security Services（OPSS）に関連するトピックについて説明します。
この章に含まれるトピックには次のドキュメントが関連します。
『Oracle Fusion Middlewareセキュリティ・ガイド』
『Oracle Fusion Middlewareセキュリティ概要』
Oracle Fusion Middlewareの管理者ガイド
この項では、一般的な問題および回避方法について説明します。内容は次のとおりです。
この項に、OPSSに必要なパッチをリストします。
Oracle Internet Directory 10.1.4.3をOPSSに使用する場合、Oracle Internet Directory 10.1.4.3にOracle Bug#8351672の必須個別パッチを適用することをお薦めします。使用しているプラットフォーム用のパッチをOracleサポート（http://myoraclesupport.oracle.com）からダウンロードします。
パフォーマンスが最適になるよう次のOracle Internet Directoryチューニングをお薦めします。
ldapmodify -D cn=orcladmin -w <password> -v <<EOF dn: cn=dsaconfig,cn=configsets,cn=oracle internet directory changetype: modify add: orclinmemfiltprocess orclinmemfiltprocess: (objectclass=orcljaznpermission) orclinmemfiltprocess: (objectclass=orcljazngrantee) EOF
ポリシー・ストア内の文字列には特殊ASCII文字を範囲[0, 15]に含めることができません。
次の文字を確認してください。
< " & $ ? * , / \ ` : ( ) ^ ' % + { }
XMLポリシー・ストアを使用する場合、これらをアプリケーション・ロール名に含めないようお薦めします。
ロールの作成時にこれらを使用する必要がある場合、ApplicationPolicy.searchAppRoles() APIを使用してXMLポリシー・ストアを検索する際、入力でこれらの文字を必ずエスケープし、正しい結果が得られるようにします。
たとえば、"applicationRole^$"という名前のアプリケーション・ロールがある場合、ポリシー・ストアでこのロールを見つけるには、ApplicationPolicy.searchAppRoles("applicationRole\\^\\$")と検索する必要があります。
あるいは、検索式にこれらの特殊文字を含めるのではなく、ワイルド・カードを使用することもできます。次に例を示します。
ApplicationPolicy.searchAppRoles("applicationRole*")
|
注意: これは、LDAPポリシー・ストアでは問題ではありません。 |
XMLファイル・ベースのポリシー・ストアで、<permission>または<principal>の終了タグと次のタグの開始タグの間に改行文字が必要です。
次に、正しくない形式と正しい形式の例を示します。
正しくないポリシー・ストア（一部）の例は次のとおりです。
<permission>
<class>java.lang.RuntimePermission</class>
<name>getClassLoader</name>
</permission> <permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>
正しいポリシー・ストア（一部）の例は次のとおりです。
<permission>
<class>java.lang.RuntimePermission</class>
<name>getClassLoader</name>
</permission>
<permission>
<class>java.io.FilePermission</class>
<name>/foo</name>
<actions>read,write</actions>
</permission>
検索フィルタに使用されるOracle Internet Directory属性は索引付けされている必要があります。
属性カタログの管理方法および属性が索引付けされているかどうかの確認方法の詳細は、『Oracle Fusion Middleware Oracle Internet Directory管理者ガイド』の次の項を参照してください。
Oracle Directory Services Managerを使用した新規属性への索引の追加
Oracle Directory Services Managerを使用した既存の属性への索引の追加
Oracle Directory Services Managerを使用した属性からの索引の削除
データが存在する属性へのOracle Directory Services Managerを使用した索引付け
既存の属性に対するカタログを使用した索引の追加および削除
LDIFファイルで指定した属性の索引付けに、コマンドldapmodifyを使用することもできます。次に構文を示します。
>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属性について詳細に説明します。Oracle Internet Directory 10.1.4.3に必要はパッチについては、29.1.1.1項「Oracle Internet Directory 10.1.4.3用必須パッチ」を参照してください。
カタログ化される必要のあるOPSS属性のリスト
次の各OPSS属性はカタログ化される必要があります。
orclrolescope
orclassignedroles
orclApplicationCommonName
orclAppFullName
orclCSFAlias
orclCSFKey
orclCSFName
orclCSFDBUrl
orclCSFDBPort
orclCSFCredentialType
orclCSFExpiryTime
modifytimestamp
createtimestamp
orcljpsassignee
問題
XMLファイル・ベースのポリシー・ストアでOracle Internet Directoryを使用するよう再関連付けすると、再関連付けが正常に完了したとレポートされます。しかし、実行時、システムが所定のとおり動作しません。移行後システム・ポリシーにあるはずの付与されているコード・ベースのポリシーがありません。この結果、サーバーで次のようなスタック・トレースがレポートされます。
<BEA-000000> <JspServlet: initialization complete>
####<May 4, 2009 8:32:50 AM PDT> <Error> <HTTP> <ap626atg> <WLS_Spaces>
<[ACTIVE] ExecuteThread: '3' for queue: 'weblogic.kernel.Default
(self-tuning)'> <<WLS Kernel>> <> <> <1241451170341> <BEA-101020>
<[ServletContext@20193148[app:webcenter module:/webcenter path:/webcenter
spec-version:2.5]] Servlet failed with Exception
java.security.AccessControlException: access denied
(oracle.security.jps.service.policystore.PolicyStoreAccessPermission
context=APPLICATION,name=webcenter getApplicationPolicy)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)
at
java.security.AccessController.checkPermission(AccessController.java:546)
at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$3.checkPermission(JpsAuth.java:348)
at
oracle.security.jps.util.JpsAuth$Diagnostic.checkPermission(JpsAuth.java:268)
at
oracle.security.jps.util.JpsAuth$AuthorizationMechanism$6.checkPermission(JpsAuth.java:372)
at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:408)
at oracle.security.jps.util.JpsAuth.checkPermission(JpsAuth.java:431)
at
oracle.security.jps.internal.policystore.AbstractPolicyStore.checkPolicyStoreAccessPermission(AbstractPolicyStore.java:246)
at
oracle.security.jps.internal.policystore.ldap.LdapPolicyStore.getApplicationPolicy(LdapPolicyStore.java:281)
at
oracle.security.jps.internal.policystore.PolicyUtil.getGrantedAppRoles(PolicyUtil.java:898)
at
oracle.security.jps.internal.policystore.PolicyUtil.getJpsAppRoles(PolicyUtil.java:1354)
at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:273)
at
oracle.security.jps.wls.JpsWlsSubjectResolver$1.run(JpsWlsSubjectResolver.java:270)
at java.security.AccessController.doPrivileged(Native Method)
次に権限を示します。
oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=webcenter getApplicationPolicy
これがコード・ベースに付与されており、認可決定がfalseと評価されます。
解決策
AdminServer診断ログに次のようなメッセージがないかチェックします。
AdminServer-diagnostic.log:[2009-05-28T02:27:52.249-07:00] [AdminServer] [NOTIFICATION] [JPS-00072] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Policy schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0 AdminServer-diagnostic.log:[2009-05-28T02:28:58.012-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-39] [ecid: 0000I66Z0KH0fplp4sm3Ui1A7_Rl00002s,1:5001] [arg: 11.1.1.1.0] [arg: 11.1.1.0.0] Credential store schema upgrade not required. Store Schema version 11.1.1.1.0 is compatible to the seed schema version 11.1.1.0.0
この種のメッセージは、再関連付け時にスキーマがシードされていないことを表します。正しいスキーマがOracle Internet Directoryサーバーにシードされていない場合、システムは所定どおり機能しません。スキーマが再関連付け時にシードされるようにするには、次のようにします。
Oracle Internet Directoryサーバーでcn=OracleSchemaVersionコンテナ下のcn=OPSSコンテナを削除します。
ファイル・ベースのストアを使用するOPSSポリシー・ストアのクリーンな実働インスタンスを起動します。
このファイル・ベースのストアをOracle Internet Directoryサーバーに再関連付けます。
AdminServer診断ログで次のメッセージを検索して、OPSS LDAPスキーマがLDAPサーバーにシードされたことを確認します。
AdminServer-diagnostic.log:[2009-05-29T07:18:18.002-07:00] [AdminServer] [NOTIFICATION] [JPS-00078] [oracle.jps.config] [tid: Thread-12] [ecid: 0000I61Z0MH0fplp4sm3Ui1A7_Ll00002s,1:5001] [arg: 11.1.1.0.0] Policy schema version set to 11.1.1.0.0
リリース11g Oracle Internet Directoryサーバーと再関連付けする場合、スキーマ・バージョンに11.1.1.1.0と表示されます。
10.1.4.3 Oracle Internet Directoryサーバーと再関連付けする場合、スキーマ・バージョンに11.1.1.0.0と表示されます。
PolicyStoreスキーマ・バージョンは、Oracle Internet Directoryサーバーの次のコンテナ下で設定されます。
cn=PolicyStore,cn=OPSS,cn=OracleSchemaVersion
CredentialStoreスキーマ・バージョンは、Oracle Internet Directoryサーバーの次のコンテナ下で設定されます。
cn=CredentialStore,cn=OPSS,cn=OracleSchemaVersion
Oracle Business Intelligence Publisherで使用可能な共通監査フレームワークに次の問題が見られます。
ユーザー・アクティビティ・ダッシュボードの問題
共通レポート→ユーザー・アクティビティ→「ダッシュボード」と移動します。次の問題が見られます。
特定のデータ文字列に対応するハイパーリンクで、イベントが正しく表示されません。たとえば、データがcn=%host%.us.oracle.comなどのパーセント記号を含む文字列で構成される場合、対応するイベント・ハイパーリンクをクリックすると、パーセント記号が正しく処理されないため、イベントが結果のレポートに正しく表示されません。文字列に空白が埋め込まれている場合も同様の問題が起こります。
認証成功、認証失敗、認可成功、認可失敗に対応するハイパーリンクを使用してレポートに移動すると、データが表示されません。
コンポーネント名およびアプリケーション名フィルタの問題
これらのレポート・フィルタで、一部のフィルタ・オプションが所定どおりに表示されません。
たとえば、すべてのイベント・レポートでレポートにOracle Internet Directory（OID）のデータ行とOracle Identity Federation（OIF）の行が含まれる場合、コンポーネント名ドロップダウン・リストに「すべて」、「OID」、「OIF」オプションが表示されるはずです。しかし、「すべて」および「OIF」フィルタ・オプションのみ表示されます。このため、欠落しているオプション（この例ではOIF）でレポートをフィルタ処理できません。
解決策
Oracle Bug#8524140用の個別パッチを適用します。
この項では、構成に関する問題およびその回避方法について説明します。内容は次のとおりです。
この項では、Oracle Fusion Middleware Audit Frameworkの構成に関する問題について説明します。内容は次のとおりです。
監査がカスタム監査レベルで構成されていて、その後WLSTを使用して別の（カスタム以外の）監査レベルに切り替えた場合、カスタム設定を明示的に削除しないかぎり、カスタム監査設定が残ります。
|
注意: この動作は、WLSTを使用した場合にのみ起こります。Fusion Middleware Controlを使用して監査構成を管理する場合、カスタム監査レベルから別の監査レベルへの切替え時、カスタム監査設定はクリアされます。 |
例を使用してこの動作を説明します。
カスタム監査レベルがコンポーネントのポリシーに設定されています。構成の一部として監査フィルタが指定されています。
実行時、指定されたフィルタに従って監査データが収集されます。
ここで、WLST setauditpolicyコマンドを使用して、コンポーネントの監査ポリシーがカスタム監査レベルから低監査レベルに変更されます。しかし、カスタム監査レベルの一部として設定されたフィルタが監査構成に残ります。
監査データは現在カスタム監査レベルではなく、低監査レベルに基づいて収集されます。
コンポーネントの監査ポリシーをカスタム・レベルに戻します。別のフィルタを追加すると、このフィルタが元々構成されていたフィルタに付加されます。元のフィルタを明示的に削除しないかぎり、構成の一部として残ります。
実行時、監査データは、カスタム・レベルのすべての有効なフィルタに基づいて収集されます。
Oracle Business Intelligence Publisherにパッケージされている標準監査レポートでは、多数の管理者用言語がサポートされます。Oracle Business Intelligence Publisherは異なるロケールで起動できます。起動時、管理者は「プリファレンス」で優先使用するロケールを設定することで使用する言語を指定できます。
不具合のため、Oracle Business Intelligence Publisherが次の3つのロケールのいずれかで起動されるとそのロケールでレポートが表示されません（ラベル、ヘッダー、タイトルなどを含むレポート全体が英語で表示されます）。
zh_CN（簡体字中国語）
zh_TW（繁体字中国語）
pt_BR（ポルトガル語（ブラジル））
他のロケールでは翻訳されたテキストが所定のとおり表示されます。たとえば、Oracle Business Intelligence Publisherをzh_CNで起動すると、優先使用されるロケールはzh_CNに設定されますが、テキストはzh_CNで表示されません。情報は英語で表示されます。
この問題は、Oracle Business Intelligence Publisherの今後のリリースで修正される予定です。
Oracle Business Intelligence Publisherにパッケージされている標準監査レポートでは、多数の言語がサポートされます。
不具合のため、翻訳されている場合でも、レポート・タイトルと説明が常に英語で表示されます。
この問題は、Oracle Business Intelligence Publisherの今後のリリースで修正される予定です。
Oracle Fusion Middlewareでは、カスタム・アイデンティティ・ストアと対話するユーザーおよびロールAPIを有効にするプロバイダがサポートされます。
カスタムのユーザーおよびロール・プロバイダの作成の詳細は、Oracle Technology NetworkのOPSSのページを参照してください。
http://www.oracle.com/technology/products/id_mgmt/opss/index.html
この項では、ドキュメントの訂正箇所を示します。内容は次のとおりです。
この項には、WLSTコマンドと使用方法に関係するドキュメントの訂正箇所の最新情報が含まれます。
一部のWLSTコマンドでは、操作に使用するロールのプリンシパル名とプリンシパル・クラスを指定する必要があります。
たとえば、次の起動では、アプリケーション・ストライプがmyAppで名前がmyAppRoleのロールにプリンシパルが追加されます。
grantAppRole.py -appStripe myApp -appRoleName myAppRole
-principalClass myPrincipalClass -principalName myPrincipal
このようなコマンドで、プリンシパルによって認証ロールまたは匿名ロールが参照される場合、プリンシパル名とプリンシパル・クラスは固定で、次の組合せのいずれかである必要があります。
認証ロール
名前: authenticated-role
クラス: oracle.security.jps.internal.core.principals.JpsAuthenticatedRoleImpl
匿名ロール
名前: anonymous-role
クラス: oracle.security.jps.internal.core.principals.JpsAnonymousRoleImpl
プリンシパル名とクラスの指定が必要なWLSTコマンドのリストは次のとおりです。
grantAppRole
revokeAppRole
grantPermission
revokePermission
listPermissions
一部のWLSTコマンドでは、アプリケーション・ストライプの指定が必要です。デフォルトでは、アプリケーションがバージョニングされていない場合、アプリケーション・ストライプはアプリケーション名です。ただし、アプリケーションがバージョニングされている場合、アプリケーション名とアプリケーション・ストライプは同じではありません。
たとえば、名前がmyAppでバージョン1のバージョニングされているアプリケーションの名前は、Oracle Fusion Middleware ControlのページでmyApp(v1.0)と表示されますが、このアプリケーションのアプリケーション・ストライプはmyApp#v1.0です。
通常、表示名がappName(vers)のアプリケーションのアプリケーション・ストライプはappName#versです。次の起動に示すように、WLSTコマンドでアプリケーション・ストライプとして渡す必要があるのは、この最後の文字列です。
>listAppRoles myApp#v1.0
ストライプ指定を使用できるWSLTコマンドのリストは次のとおりです。
createAppRole
deleteAppRole
grantAppRole
revokeAppRole
listAppRoles
listAppRoleMembers
grantPermission
revokePermission
listPermissions
deleteAppPolicies
次の項に、OPSSパラメータ、プロパティおよびプロファイルの設定に関するガイドラインを示します。
表29-1に、OPSSシステム・プロパティについて推奨される特別な設定のいくつかをリストします。これらは通常Oracle WebLogic Serverを起動するスクリプトで指定されます。
表29-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の認可パフォーマンスが改善されます。 |
表29-2に、LDAPポリシー・ストア・サービス・インスタンスに必要なプロパティをリストします。インスタンスのプロパティは、『Oracle Fusion Middlewareセキュリティ・ガイド』のE.1項で説明されているスクリプトを使用して指定および変更できます。
表29-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.cache.updateable |
true |
true |
trueの場合、ポリシー・キャッシュが管理操作用に増分更新されます。 |
|
oracle.security.jps.policystore.refresh.enable |
true |
true |
リフレッシュを有効にします。 |
|
oracle.security.jps.policystore.refresh.purge.timeout |
43200000 |
43200000 |
強制ポリシー・ストア・リフレッシュ時間（ミリ秒）。 |
|
oracle.security.jps.ldap.policystore.refresh.interval |
600000 |
600000 |
ポリシー・ストア・リフレッシュ・ポーリング時間（ミリ秒）。 |
表29-3に、LDAPポリシー・ストア・ランタイムAPIのタイミングをプロファイルするロガーをリストします。『Oracle Fusion Middlewareセキュリティ・ガイド』のI.1.1.4項で説明されているとおり、これらのプロファイラはOracle Fusion Middleware Controlのページで指定されます。
表29-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インターセプタによるアプリケーション・ロールの導出にかかる時間。 |
|
カテゴリ |
ロガー名 |
ログ・レベル |
プロファイル |
|
リフレッシュ |
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インターセプタによるアプリケーション・ロールの導出にかかる時間。 |
この項には、『Oracle Fusion Middlewareセキュリティ・ガイド』の第17章「資格証明ストア・フレームワークを使用した開発」の訂正を示します。
ウォレット・ストアを使用するJavaSEアプリケーション例に関する項で、サンプルjazn-data.xmlのname要素を次のように変更します。
変更前:
<name>*context=SYSTEM,mapName=pc_map,keyName=**</name>
変更後:
<name>context=SYSTEM,mapName=pc_map,keyName=*</name>
変更前:
<name>*context=SYSTEM,mapName=gc_map,keyName=gc_key*</name>
変更後:
<name>context=SYSTEM,mapName=gc_map,keyName=gc_key</name>
ウォレット・ストアを使用するJavaEEアプリケーション例に関する項で、サンプルjazn-data.xmlのcodesource要素がデプロイされているアプリケーション名を含むよう次のように変更します。
変更前:
<codesource> <url>file:${domain.home}/servers/${weblogic.Name}/tmp/_WL_user/-</url></codesource>
変更後:
<codesource>
<url>file:${domain.home}/servers/${weblogic.Name}
/tmp/_WL_user/myTestApp/-</url>
</codesource>
この項には、『Oracle Fusion Middlewareセキュリティ・ガイド』の第19章「ユーザーおよびロールAPIを使用した開発」の訂正を示します。
ユーザーおよびロールAPIの使用に関する注意
一般に、認証はユーザーおよびロールAPIではなく、認証プロバイダによってのみ行われる必要があります。
また、認証プロバイダは、書込み権限を持たないユーザーの接続DNで構成することをお薦めします。
ユーザーの検索例の追加情報
ユーザーの検索例に関する項に、次の検索フィルタが示されています。
. . SimpleSearchFilter sf = oidStore.getSimpleSearchFilter( UserProfile.NAME, SimpleSearchFilter.TYPE_EQUAL, null); . .
ユーザーを検索する場合、前述の例のとおりUserProfileを起動します。ただし、グループを検索する場合は、そのかわりにRoleProfileを使用します。
『Oracle Fusion Middlewareセキュリティ概要』のロックダウンに関する項に、誤ったリンクが含まれています。正しい参照先は、『Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server』のアプリケーションの保護に関する項です。
Oracle Fusion Middleware 11gでは2つの新しいシングル・サインオン・ソリューションがサポートされ、周辺認証の確立および強化にアプリケーションで使用できます。
Oracle Access Manager
Oracle Single Sign-On（OSSO）ソリューション
この項では、これらのソリューションについて記載された『Oracle Fusion Middlewareセキュリティ・ガイド』の章の既知の問題について説明します。次の事項が、このマニュアルの次のリリースで修正される予定です。
29.3.6.2項「Oracle HTTP ServerとOracle WebLogic Serverとの間の信頼の確立」
29.3.6.10項「既知の問題: Oracle Access ManagerプロバイダJARファイルとOAMCfgTool」
29.3.6.13項「スタンドアロンWebLogic Serverにデプロイされているアプリケーションに対するOSSOソリューション」
このタスクは必要なくなったため、省略してください。
Oracle Access Managerアイデンティティ・アサーションのシングル・サインオン用構成に関する項のこのタスクは、シングル・サインオンにOracle Access Managerを使用する場合もOracle Application Serverを使用する場合も同じです。このため、次のように変更されます。
「Oracle WebLogic Serverと他のエンティティとの間の信頼の確立」
WebLogic管理コンソールには、「全般」タブまたはドメイン全体のセキュリティ設定の表示リンクはありません。このため、次の手順のステップ2、3および4は、WebLogic管理コンソールの実際のナビゲーション・パスおよびタブ名を反映し、次に示すように修正される予定です。
11g Oracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成する手順
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」下の「ドメイン」をクリックします。
「セキュリティ」タブをクリックし、「フィルタ」タブをクリックします。
サーバー接続に関連する問題をデバッグする場合、「接続ログの有効化」をクリックして承認メッセージのロギングを使用できるようにします。
ドメインで使用する接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドにweblogic.security.net.ConnectionFilterImplと指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。これは、Oracle WebLogic ServerのCLASSPATHにも指定する必要があります。
接続フィルタ・ルールに適切な構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
「IDアサーション・プロバイダに対する認証スキーム、ポリシー・ドメインおよびWebゲート・プロファイルの構成」に進みます。
このトピックは、OSSOを使用する場合もOracle Access Managerを使用する場合も同じです。WebLogic管理コンソールには、「全般」タブまたはドメイン全体のセキュリティ設定の表示リンクはありません。このため、次の手順のステップ2、3および4は、WebLogic管理コンソールの実際のナビゲーション・パスおよびタブ名を反映し、次に示すように修正される予定です。
11g Oracle HTTP Serverのホストからのリクエストを許可するよう接続フィルタを構成する手順
Oracle WebLogic管理コンソールにログインします。
「ドメイン構成」下の「ドメイン」をクリックします。
「セキュリティ」タブをクリックし、「フィルタ」タブをクリックします。
サーバー接続に関連する問題をデバッグする場合、「接続ログの有効化」をクリックして承認メッセージのロギングを使用できるようにします。
ドメインで使用する接続フィルタを指定します。
デフォルト接続フィルタ: 「接続フィルタ」属性フィールドにweblogic.security.net.ConnectionFilterImplと指定します。
カスタム接続フィルタ: 「接続フィルタ」属性フィールドに、ネットワーク接続フィルタを実装するクラスを指定します。これは、Oracle WebLogic ServerのCLASSPATHにも指定する必要があります。
接続フィルタ・ルールに適切な構文を入力します。
「保存」をクリックします。
Oracle WebLogic Serverを再起動します。
「OAMCfgToolを使用してフォーム認証スキーム、ポリシー・ドメインおよびアクセス・ポリシーを作成する手順」に進みます。
Oracle Access Manager IDアサーション・プロバイダ用mod_weblogicの確認に関する項に、次の記載があります。
Webサーバーのhttpd.confファイルにmod_weblogic構成がない場合、リクエストは、HTTPサーバーからOracle WebLogic Serverにプロキシ設定されません。
情報は次のように変更される予定です。
Oracle HTTP Server 11gを使用する場合、mod_weblogic構成がmod_wl_ohs.confにデフォルトで含まれ、このファイルのパスがhttpd.confに含まれます。mod_weblogic構成がない場合、httpd.confを編集する必要があります。
次の変更が行われる予定です。
ステップ1で、Oracle TechnologyのOAMCfgToolの実際の場所は記載されている場所と異なります。
OAMCfgToolを実行する前に適切なJDKがインストールされるよう新しいステップ2が追加される予定です。
OAMCfgToolを使用してフォーム認証スキーム、ポリシー・ドメインおよびアクセス・ポリシーを作成する手順
... （ステップは変更されません）
JDK 1.6（または最新バージョン）がインストールおよび構成されていることを確認します。
... （ステップは変更されません）
WebLogicドメインでOracle Access Manager認証プロバイダ用のプロバイダを構成する手順のステップ4e「OAM認証プロバイダ: 拡張構成」に次の変更が行われる予定です。
AccessGateとAccess Serverで共有される簡易通信モードのパスワードは、表10-7に示すとおり簡易モード・パスフレーズと呼ばれます。
OAMCfgToolを使用してOracle Access Manager IDアサーション・プロバイダのアクセス・ポリシーを作成する場合、ポリシー内のパブリックURIのURLパターンは/.../public/.../とする必要があります。ただし、URLパターンがポリシー内に設定されない場合があります。
これは機能に影響を及ぼしません。しかし、章内の記述により、これで混乱が生じる可能性があります。
『Oracle Fusion Middlewareセキュリティ・ガイド』の「Oracle Fusion Middlewareでのシングル・サインオンの構成」、OAMCfgToolの使用に関する項は、次のリリースで次の情報を使用して更新される予定です。
必須パスワードを入力しなかった場合、デフォルトでは、OAMCfgToolからコマンドラインでのセキュアな方法での入力を求められます。次に例を示します。
Enter app_agent_password: Enter ldap_userpassword: Enter oam_aaa_passphrase: Processed input parameters
パスワード・プロンプトが表示されないようにするnopromptオプションを使用できます。
スタンドアロンWebLogic Server（Oracle Fusion Middlewareなし）上のアプリケーション用にOracle Access Managerソリューションを構成する場合、『Oracle Fusion Middlewareセキュリティ・ガイド』の「Oracle Fusion Middlewareでのシングル・サインオンの構成」には、Oracle Technology Networkから特定の必須ファイルを入手するよう記載されています。
|
注意: 非Fusion Middlewareアプリケーションというフレーズは、スタンドアロンOracle WebLogic Serverにデプロイされているアプリケーションを指します。 |
マニュアルには現在、次の間違った詳細が含まれています。
誤: 非Fusion Middlewareアプリケーション
正: スタンドアロンWebLogic Serverにデプロイされているアプリケーション
|
注意: 非Fusion Middlewareアプリケーションというフレーズは、スタンドアロンOracle WebLogic Serverにデプロイされているアプリケーションを指します。 |
OAMCfgToolおよびスタンドアロンOracle WebLogic Server用プロバイダの正しい場所:
アプリケーションをスタンドアロンWebLogic Server（Oracle Fusion Middlewareなし）にデプロイする場合、次のものを記載のように入手します。
OAMCfgTool: Oracle Access Manager 10g（10.1.4.3）Serverのメディア:
oamcfgtool<version>.zip
oamAuthnProvider.zip: Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gのメディア:
oamAuthnProvider<version number>.zip
スタンドアロンOracle WebLogic Server用OAMCfgToolの間違った場所:
非Fusion Middlewareアプリケーション: 次のようにOAMCfgToolを入手します。
Oracle Technology Networkにログインします。
Oracle Access Manager 10g（10.1.4.3）WebGate for Oracle HTTP Server 11gでOAMCfgTool ZIPファイルを見つけます。
oamcfgtool<version>.zip
スタンドアロンOracle WebLogic Server用OAMCfgToolの正しい場所:
非Fusion Middlewareアプリケーション: 次のようにOAMCfgToolを入手します。
Oracle Technology Networkにログインします。
Oracle Access Manager 10g（10.1.4.3）ServerのメディアでOAMCfgToolを見つけます。
oamcfgtool<version>.zip
他の既知の問題については、『Oracle Fusion Middlewareセキュリティ・ガイド』の第10章のこのトピックを参照してください。
問題
次のようなメッセージを受け取ります。
Oracle SSO Failure - Unable to process request Either the requested URL was not specified in terms of a fully-qualified host name or Oracle HTTP Server single sign-on is incorrectly configured. Please notify your administrator.
解決策
ServerNameがポート番号を含むようOracle HTTP Serverのhttpd.confファイルを変更し、Webサーバーを再起動します。次に例を示します。
変更前: ServerName host.domain.com
変更後: ServerName host.domain.com:port
Oracle HTTP Server監査構成の「常に監査するユーザー」セクションでSSOユーザーを指定する際、SSOユーザー名は大文字で指定する必要があります。
カンマ区切りのユーザーのリストを指定して、これらのユーザーが開始したイベントを監査フレームワークで監査するよう強制することもできます。指定した監査レベルまたはフィルタに関係なく監査は行われます。これは、すべての監査タイプに当てはまります。
詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』の「監査の構成と管理」、監査ポリシーの管理に関する項を参照してください。
『Oracle Fusion Middlewareセキュリティ・ガイド』には、Oracle Fusion Middleware Oracle WebLogic Serverにデプロイされているアプリケーション用にシングル・サインオン（SSO）を構成する方法が記載されています。ただし、スタンドアロンOracle WebLogic Serverにデプロイされているアプリケーションについての記載はここのみです。
2つの環境の違いは次のとおりです。
OSSO付きOracle Fusion Middleware: 必要なOSSO IDアサーション・プロバイダ（ossoiap.jar）は、Oracle Fusion Middlewareをインストールすると自動的に用意されます。Oracle Identity Management、Oracle SOA Suite、またはOracle WebCenterが必要です。
|
注意: OSSO付きOracle Fusion Middlewareでは、Oracle HTTP Server 10gまたは11g Webサーバーのいずれかを使用できます。 |
OSSO付きスタンドアロンOracle WebLogic Server: OSSO IDアサーション・プロバイダ（ossoiap.jar）は、ここに示すとおりOracle Web層から取得する必要があります。
|
注意: OSSO付きスタンドアロンOracle WebLogic ServerにはOracle HTTP Server 11g Webサーバーが必要です。 |
OSSOをOracle Fusion Middlewareアプリケーションに使用する場合も他のアプリケーションに使用する場合も、IDアサーション・プロバイダは『Oracle Fusion Middlewareセキュリティ・ガイド』の「Oracle Fusion Middlewareでのシングル・サインオンの構成」、OSSO IDアサーション・プロバイダの使用に関する項に示すとおりに機能します。
セッション無効化およびSSO CookieとJSESSIONID Cookieとの間の同期用シングル・ログアウトの構成とテストに、必要に応じて使用できる追加の詳細も次に記載します。ここに記載のとおり必須ファイルをOracle Web層から取得する必要もあります。
タスクの概要: スタンドアロンWebLogic Server上のアプリケーション用OSSO IDアサーション・プロバイダのデプロイおよび構成
Oracle WebLogic Server 10.3.1および他の必須コンポーネントを次のようにインストールします。
『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項、OSSO IDアサーション・プロバイダのデプロイおよび構成タスクの概要のステップ1aからdまでを実行します。
ステップ1eは省略し、かわりにアプリケーションをデプロイします。
Oracle WebLogic Serverに用意されており、$WLS_HOME/common/bin/config.shから使用できるwebloginドメイン拡張テンプレートを使用してWebLogicセキュリティ・ドメインを作成します。
『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項、mod_weblogicの構成に関する項で説明されているとおり、リクエストをOracle WebLogic Serverへフォワードするようmod_weblogicを構成します。
『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項に記載のとおり、モジュールmod_ossoをパートナ・アプリケーションとして10g SSOサーバーに登録および構成します。
Oracle HTTP Server mod_ossoのOSSOサーバー10.1.4への再登録に関する項に記載の手順を実行します。
Webリソースを保護するためのmod_ossoの構成に関する項に記載の手順を実行します。
次のように認証プロバイダを適切なセキュリティ・ドメインに追加します。
次のOracle Web層からOSSO IDアサーション・プロバイダ（ossoiap.jar）を取得します。
$ORACLE_INSTANCE/modules/oracle.ossoiap_11.1.1/ossoiap.jar
ossoiap.jarを$WLS_HOME/wlserver_10.x/server/lib/mbeantypeにコピーし、Oracle WebLogic Serverを再起動します。
『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項、OSSO用WebLogicドメインへのプロバイダの追加に関する項に記載のとおりプロバイダを構成します。
『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項、Oracle WebLogic Serverと他のエンティティとの間の信頼の確立に関する項に説明されているとおり、アクセス制御リストを作成し、Oracle HTTP ServerとフロントエンドWebサーバーが稼働しているホストからリクエストを受け取るようOracle WebLogic接続フィルタ・メカニズムを構成します。
|
注意: 保護されたアプリケーションをテストし、Oracle WebLogic Serverのホストとポートを使用してデフォルトの認証プロバイダと連携していることを確認します。 |
『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項、IDアサーション・プロバイダ用アプリケーションの構成に関する項で説明されているとおり、OSSO IDアサーション・プロバイダのアプリケーション認証方法を構成します（アプリケーションEARファイル内のすべてのweb.xmlファイルで要素auth-methodにCLIENT-CERTが含まれる必要があります）。
|
注意: Oracle HTTP Serverのホストとポートを使用してアプリケーションにアクセスし、OSSOで認証されているユーザーでアプリケーションをテストします。 |
オプション: 次のようにシングル・ログアウト（セッションの無効化とSSO CookieとJSESSIONID Cookieとの間の同期）を構成およびテストできます。
|
関連項目: SSOFilterの詳細は、『Oracle Fusion Middlewareセキュリティ・ガイド』のOSSO IDアサーション・プロバイダの新規ユーザーに関する項、ユーザーとSSOセッションの同期（SSO同期フィルタ）に関する項を参照してください。 |
次のようにssofilter.jarを取得し、これを使用するようOracle WebLogic Serverを構成します。
1. 次のOracle Web層からssofilter.jarを取得します。
$ORACLE_INSTANCE/modules/oracle.ssofilter_11.1.1/ssofilter.jar
2. Oracleミドルウェア・ホームの適切なディレクトリ（WLS_INSTALL/Oracle/Middleware/modulesディレクトリなど）にコピーします。
3. （setDomainEnv.shスクリプトのPOST_CLASSPATH変数またはCLASSPATH変数を編集して）ssofilter.jarの絶対パスをOracle WebLogic Serverのクラスパスに追加します。
次のようにsystem-filters.warをシステム・フィルタとしてデプロイします。
1. 次のOracle Web層からsystem-filters.warを取得します。
$ORACLE_INSTANCE/modules/oracle.jrf_11.1.1/system-filters.war
2. system-filters.warをOracleミドルウェア・ホームの適切なディレクトリ（WLS_INSTALL/Oracle/Middleware/modulesディレクトリなど）にコピーします。
3. system-filters.warをアプリケーション・フィルタとしてデプロイします。WebLogic管理コンソールから「デプロイメント」をクリックし、「新規」を選択してファイルの場所を選択します。
4. 要求に応じてOracle WebLogic Serverを再起動します。
次のようにログを有効にし、SSOFilterが機能していることを確認します。
1. WebLogic管理コンソールから「ドメイン」→「環境」→「サーバー」→「AdminServer」とクリックします。
2. 「ロギング」タブをクリックします。
3. 「詳細」ドロップダウンから「ログの最低の重大度」に「デバッグ」を選択します。
4. 「詳細」ドロップダウンの「メッセージの宛先」から、LogFileの「重大度」に「デバッグ」を選択します。
5. 変更を保存し、Oracle WebLogic Serverを再起動します。
SSOFilterがシステム・フィルタとしてロードされていることを確認します。
1. DomainHome/Servers/AdminServer/log/AdminServer.logのAdminServer.logファイルを開きます。
2. "SSOFilter"を検索して<Debug>メッセージがあることを確認します。これは、SSOFilterが初期化され、フィルタがロードされたことを示します。
フィルタ機能をテストし、ユーザーのログアウト後にSSOおよびJSESSIONID Cookieがクリーンアップされること、およびログアウト後のアプリケーションへのアクセスで再度ログインが要求されることを確認します。
|
注意: WebLogicセキュリティ・ドメインにOSSO IDアサーション・プロバイダが構成されている必要があります。構成されていない場合、初期化時にフィルタが自動的に無効になります。 |
アプリケーションからテストでログアウトし、セッションが正常に終了することを確認します。
