この章では、Oracle Access Managementに関連する問題について説明します。内容は次のとおりです。
この項では、特定のサービスに関してまとめた一般的な問題および回避方法について説明します。説明を簡潔にするために、一般的な問題のあるサービスについてのみ説明します。
サービス関連のトピック(セキュリティ・トークン・サービスなど)がなければ、この時点で一般的な問題はありません。
トピックは次のとおりです。
このトピックでは、Oracle Access Management Access Manager (Access Manager)の一般的な問題および回避方法について説明します。内容は次のとおりです。
第5.1.1.4項「OSSO Agent for 11g OHSによって保護されている場合、"/"コンテキスト・ルートにアクセスできない」
第5.1.1.6項「Oracle Entitlements Serverによって保護されているときにAccess Managerを起動すると例外がスローされる」
第5.1.1.8項「認証の失敗: WNAチャレンジ、Active Directory、非ASCII文字が含まれるユーザー」
外部資格証明コレクタ(DCC)は、X509認証モジュール、プラグインまたはスキームでは機能しません。
DCCでのX509認証の使用は避けてください。
外部資格証明コレクタ(DCC)は、DAP認証チャレンジ・メソッドでは機能しません。
DCCでのDAP認証チャレンジ・メソッドの使用は避けてください。
外部資格証明コレクタ(DCC)は、アクティブ/アクティブ・マルチデータ・センター構成では機能しません。
11g OHSに付属のmod_ossoエージェントは、@コンテキスト・ルート'/'を保護するように構成できません。
Access Manger Serverを起動すると、ArmeRUNTIME例外エラーがスローされます。
この例外エラーによって、なんらかの機能を失うことはありません。
Oracle Entitlements Serverによって保護されているAccess Managerのインスタンスを起動すると、実行時例外が発生します。この例外は無視してかまいません。
非ASCII名を使用してAccess ManagerにWebgateを登録します。アクセス・テスターで、有効なIPアドレス、ポートおよびエージェントID (非ASCII名)を入力し、「接続」をクリックします。
接続テストに失敗します。
WNAチャレンジ・メソッドが含まれるKerberos認証スキームを使用するようにAccess Managerを構成し、Microsoft Active Directoryに非ASCIIユーザーを作成します。
問題
ユーザー詳細を取得してサブジェクトにユーザーDNおよびGUID属性を移入しようとすると、例外が発生します。Active Directoryの非ASCIIユーザーがAccess Managerによって保護されたリソースにアクセスしようとすると、認証に失敗し、OAMサーバー・ログに次のエラーが記録されます。
... Failure getting users by attribute : cn, value ....
原因
属性のユーザー名はJava文字列としてそのまま渡されます。
解決策
非ASCIIユーザーは、次のJVMシステム・プロパティを$DOMAIN_HOME/binのstartManagedWeblogic.shスクリプトに適用することで、Kerberos WNAスキームによって保護されたリソースにアクセスできます。
-Dsun.security.krb5.msinterop.kstring=true
簡易モードは、JDK 1.6およびAIXプラットフォームではサポートされません。かわりに、オープンまたは証明書モードを使用します。
問題
外部資格証明コレクタ対応のWebgateとリソースWebgateを組み合せている場合、ユーザーは資格証明を2度提供する必要がある場合があります。これは、Oracle HTTP Serverによる内部フォワードが生じるURLでログインがトリガーされる場合に発生する可能性があります。
回避方法
この問題を解決するには、次の回避方法を使用できます。
httpd.confファイルを編集し、(Webgate構成にインクルードされる前に)ディレクトリ・アクセス用にブラウザをリダイレクトするリライト・ルールを追加します。次に例を示します。
RewriteEngine On RewriteRule ^(.*)/$ "$1/welcome-index.html" [R]
SSL対応のWebサーバー: SSL構成でこれらのルールを繰り返します。
このトピックでは、Oracle Access Managementセキュリティ・トークン・サービス(セキュリティ・トークン・サービス)の一般的な問題および回避方法について説明します。内容は次のとおりです。
ブラウザの言語が英語以外の言語に設定されている場合、セキュリティ・トークン・サービス検索では期待した結果が返されないことがあります。たとえば、これは次の設定の場合に発生します。
Oracle Access Managementコンソール・ブラウザの設定が英語以外のときに、「リクエスタ」、「リライイング・パーティ」および「発行局」の「パートナ・タイプ」
フィールドを「リクエスタ」
、「リライイング・パーティ」
または「発行局」
に設定した場合。
Oracle Directory Services Managerブラウザの設定が英語以外のときに、「トークン発行テンプレート|Token Issuance Templates|Ngam」の「トークンのタイプ」
を「ユーザー名」
に設定した場合。
Oracle Directory Services Managerブラウザの設定が英語以外のときに、「トークン検証テンプレート|Token Validation Templates|Ngam」の「トークンのタイプ」
を「ユーザー名」
に設定した場合。
ブラウザの言語が英語の場合、検索では期待した結果が返されます。
このトピックでは、Oracle Access Management Identity Federation (Identity Federation)の一般的な問題および回避方法について説明します。内容は次のとおりです。
PS1からR2にアップグレードした後、新しい環境にもIdentity Federationが含まれます。Identity Federationを有効にし、Federationメタデータにアクセスしようとすると、エラーが発生します。
この問題を回避するには、次のWLSTコマンドを発行します。
connect('<username>', '<password>', 't3://<host>:port') domainRuntime() putStringProperty('/stsglobal/jaxbcontextpath','oracle.security.fed.xml.soap.v 11:oracle.security.fed.xml.soap.v12:oracle.security.fed.xml.security.dsig:orac le.security.fed.xml.security.enc:oracle.security.fed.xml.security.trust.v12:or acle.security.fed.xml.security.trust.v13:oracle.security.fed.xml.security.trus t.v14:oracle.security.fed.xml.ws.addressing.v09:oracle.security.fed.xml.ws.add ressing.v10:oracle.security.fed.xml.ws.policy.v12:oracle.security.fed.xml.secu rity.wss.ext.v10:oracle.security.fed.xml.security.wss.ext.v11:oracle.security. fed.xml.security.wss.policy.v11:oracle.security.fed.xml.security.wss.policy.v1 2:oracle.security.fed.xml.security.wss.utility.v10:oracle.security.fed.xml.sec urity.saml.v11.assertion:oracle.security.fed.xml.security.saml.v11.protocol:or acle.security.fed.xml.security.saml.v1x.assertion:oracle.security.fed.xml.secu rity.saml.v1x.protocol:oracle.security.fed.xml.security.saml.v1x.metadata:orac le.security.fed.xml.security.saml.v20.assertion:oracle.security.fed.xml.securi ty.saml.v20.protocol:oracle.security.fed.xml.security.saml.v20.metadata:oracle .security.fed.xml.security.identity.v10:oracle.security.fed.xml.security.openi d.v20:oracle.security.fed.xml.security.openid.v20.xrd')
複数のクライアントが同時にFederationのAccess Managerサーバーを使用する並行性モードでは、クライアントのためにAccess ManagerとFederationプラグインによって作成されたリダイレクトURLが別のクライアント用に作成されたリダイレクトURLに上書きされる場合があります。
この問題は、次の状況で発生します。
Webgateがリソースのフロンドエンド処理を行っている。
「資格証明コレクタ操作の許可」オプションがこのWebgateで選択されている。
リソースがFederationSchemeを使用するポリシーによって保護されている。
この問題により、リソースへのアクセスをリクエストすると、サーバーからはURLで200が返され、ここでブラウザはPOSTを使用してリクエストをそのURLにポストしますが、ブラウザは302を介してリダイレクトされる必要があります。
この問題を解決するには、FederationSchemeで保護されているリソースのフロンドエンド処理を行うWebgateエージェントに対して、「資格証明コレクタ操作の許可」オプションを無効にします。
この項では、特定のサービスに関してまとめた構成の問題およびその回避方法について説明します。説明を簡潔にするために、問題のあるサービスについてのみ説明します。たとえば、Identity Contextにはこの時点で既知の問題がないため、ここには含まれていません。トピックは次のとおりです。
このトピックでは、Oracle Access Management Access Manager (Access Manager)の構成の問題および回避方法について説明します。内容は次のとおりです。
OpenSSOエージェント構成のホットスワップを有効にするには、OAMサーバーのOpenSSOプロキシで、openssoエージェントの登録の「その他」
プロパティ・セクションに次のプロパティが設定され、エージェント・サーバーが再起動されることを確認します。
J2eeエージェント: com.sun.identity.client.notification.url =http://
<AGENT_SERVER_HOST
>:<AGENT_SERVER_PORT
>/agentapp/notification
Webエージェント:
com.sun.identity.client.notification.url=http://
<AGENT_SERVER_HOST
>:<AGENT_SERVER_PORT
>/UpdateAgentCacheServlet?shortcircuit=false
Webエージェントではサポートされていません: com.sun.identity.agents.config.change.notification.enable=true
エージェントをホストしているOAMサーバーを再起動します。
このトピックでは、Oracle Access Managementセキュリティ・トークン・サービス(セキュリティ・トークン・サービス)の構成の問題およびその回避方法について説明します。内容は次のとおりです。
セキュリティ・トークン・サービスの類似作成(複製)ボタンを使用しても、元の「発行局プロファイル」テンプレートの一部のプロパティ(「セキュリティ」セクションや「属性マッピング」セクションなど)はコピーされません。
管理者は、新しく作成した「発行局プロファイル」に必要な構成項目を手動で入力する必要があります。
Oracle Access Managementコンソールの「システム構成」タブの「セキュリティ・トークン・サービス」セクションから、「発行テンプレート」に移動します。
既存の「発行テンプレート」を選択し、類似作成(複製)ボタンをクリックします。
新しいコピーした「発行テンプレート」を作成し、新しく作成したテンプレートに必要な構成項目を手動で入力します。
セキュリティ・トークン・サービスのKerberos検証テンプレートで、ドロップ・ダウン・リストの「Kerberosプリンシパル・ドメインなし」値に不正な値が設定されます。
不正な値: STS_KERBEROS_NODOMAIN
正しい値: STS_KERBEROS_PRINCIPAL_NODOMAIN
「Kerberosプリンシパル・ドメインなし」オプションを使用するには、管理者は、ドロップ・ダウン・リストで空白のフィールドを選択し、リストの近くのフィールドでSTS_KERBEROS_PRINCIPAL_NODOMAINを手動で設定する必要があります。
Oracle Access Managementコンソールの「システム構成」タブの「セキュリティ・トークン・サービス」セクションから、「トークン検証テンプレート」に移動します。
「追加」ボタンをクリックします。
名前を指定し、トークン・タイプをKerberosとして選択し、その他の詳細を入力します。
「トークン・マッピング」タブで、ドロップ・ダウン・リストから「トークンの宛先ユーザーのマップ」を選択し、「簡易ユーザー・マッピングの有効化」を有効にします。
「ユーザー・トークン属性」ドロップ・ダウンから「Kerberosプリンシパル・ドメインなし」を選択します。ドロップ・ダウン・リストから空白のフィールドを選択し、リストの近くのフィールドでSTS_KERBEROS_PRINCIPAL_NODOMAINを手動で設定します。
「データストア属性」に値を指定し、保存します。
oam-config.xmlでは、「ユーザー・トークン属性」に値としてSTS_KERBEROS_PRINCIPAL_NODOMAINを設定する必要があります。
Oracle Access Managementコンソールは、セキュリティ・トークン・サービスのパートナ用に設定された、署名する証明書または暗号化証明書を削除する方法を用意していません。
管理者は、次のWLSTコマンドを使用して、これらを手動で削除する必要があります。
セキュリティ・トークン・サービスのパートナの署名する証明書を削除するには:
deletePartnerSigningCert
セキュリティ・トークン・サービスのパートナの暗号化証明書を削除するには:
deletePartnerEncryptionCert
既存の「リライイング・パーティ」でセキュリティ・トークン・サービスの類似作成(複製)ボタンを使用すると、元のリライイング・パーティの「リソースURL」セクションにリストされているURLが削除されます(ただし変更されません)。
管理者は、必要なURLを手動で再入力する必要があります。または、「リライイング・パーティ」を作成するときに「類似作成」ボタンを使用しないでください。
NONCEを指定してUSERNAME TOKENを送信すると、セキュリティ・トークン・サービス・ログに次のエラーが表示されます。
<oracle.security.fed.model.util.rdbms.RDBMSBatchExecutor> <FEDSTS-11013> <SQL
データベースとの相互作用中に表示されるエラー:
java.sql.BatchUpdateException: ORA-12899: value too large for column "DEV_OAM"."ORAFEDBLOBSTORE"."BLOBID"
クライアントがより小さいnonceを送信するようにします。
このトピックでは、Oracle Access Management Identity Federation (Identity Federation)の構成の問題およびその回避方法について説明します。内容は次のとおりです。
IdPを作成/編集するとき、署名する証明書に不正なファイルをアップロードすると、ファイルに証明書が含まれていないことを示す適切なメッセージではなく、NULLポインタ例外
エラー・メッセージが表示されます。
Oracle Access Managementコンソールのキーストア・テンプレート表に入力したデータが検証エラーのために拒否されるとき、エラーが表示され、表の無効な行が保存されません。
しかし、この無効な行はユーザー・インタフェースでキャッシュされ、「フェデレーション設定」タブを閉じてから再度開いてもデータはリフレッシュされません。データをリフレッシュするには、再度ログインする必要があります。
Oracle Access Managementコンソールの「フェデレーション設定」ページにある「非プロキシ・ホスト」フィールドには、セミコロン(;)セパレータで区切られた非プロキシ・ホストのリストを指定します。
ただし、このフィールドは、現在、入力文字にセミコロン(;)を許可していません。
複数の非プロキシ・ホスト(host1とhost2など)を指定する必要がある場合、その回避方法は、次のようにWLSTを使用することです。
connect(<adminuser>,<adminpassword>,'t3://<HOST_NAME>:<WLS_ADMIN_PORT>') domainRuntime() putStringProperty("/fedserverconfig/nonproxyhosts", "host1;host2")
Oracle Access ManagementコンソールでIdPを作成するとき、無効なメタデータXMLファイル(SPメタデータ・ファイルなど)を選択すると、メタデータが無効であることを示すエラー・メッセージが表示されます。次にメッセージを示します。
ADFC-10001: cannot instantiate class
'oracle.security.am.fed.oif.managedbeans.idp.EditIDProviderMB'
ただし、タスクを継続し、「保存」をクリックすると、不正なメタデータ・ファイルを使用してIdPが作成され、コンソールで例外が発生し、再ログインするまでコンソールを使用できなくなります。
OpenID IdPパートナを追加するフェデレーションのWLSTコマンドは、WLSTフェデレーションのヘルプにリストされていません。
サポートされているコマンドは次のとおりです。
addOpenID20IdPFederationPartner
: OpenID 2.0 IdPフェデレーション・パートナを作成します
addOpenID20GoogleIdPFederationPartner
: GoogleをOpenID 2.0 IdPパートナとして追加します
addOpenID20YahooIdPFederationPartner
: YahooをOpenID 2.0 IdPパートナとして追加します
addOpenID20IdPFederationPartner
構文は、次のとおりです。
addOpenID20IdPFederationPartner(partnerName, ssoURL, discoveryURL, description)
このパラメータは次のとおりです。
partnerName
=作成するパートナの名前です。
ssoURL
=IdP (OP)のエンドポイントURLです。
discoveryURL
=IdP (OP)の検出URLです。
description
=パートナの説明です。これはオプションです。
addOpenID20GoogleIdPFederationPartner
構文は、次のとおりです。
addOpenID20GoogleIdPFederationPartner()
このコマンドは、パラメータを取りません。
addOpenID20YahooIdPFederationPartner
構文は、次のとおりです。
addOpenID20YahooIdPFederationPartner()
このコマンドは、パラメータを取りません。
Oracle Access Managementコンソールの「システム構成」タブ、「Identity Federation」、アイデンティティ・プロバイダからアクセスされるフェデレーションIdPパートナページは、OpenID IdP/OPパートナのサポートを提供しません。
回避方法として、フェデレーションOpenID WLSTコマンドを使用して、OpenID IdP/OPパートナを追加できます。詳細は、5.2.3.5項を参照してください。
この問題は、次のシナリオで発生します。
フェデレーションIdPパートナが追加された。
認証スキームおよびモジュールが、そのIdPパートナに対してOracle Access ManagementコンソールまたはWLSTコマンドを使用して作成された。
認証ポリシーが、そのパートナに対して新しく作成した認証スキームを使用して作成されている。
リソースがこのポリシーで保護されている。
そのパートナに対して新しく作成された認証モジュールの不正な構成のため、ブラウザおよびログにエラーが表示されます。
回避方法は次のとおりです。
Oracle Access Managementコンソールにログインします。
「システム構成」タブをクリックします。
左側で、「Access Manager」をクリックします。
「認証モジュール」を開きます。
「カスタム認証モジュール」を開きます。
新しいフェデレーション認証モジュール(IdPNameFederationPlugin)をダブルクリックします。
右側の「ステップ編成」タブに移動します。
「最初のステップ」
というドロップ・ダウンをFedAuthnRequestPlugin
に変更します。
Identity Federationがリモート・プロバイダに接続して、SSLクライアント証明書を提供する必要がある場合は、アイデンティティ・キーストアおよび信頼キーストアのパスワードを使用してIdentity Federationを構成する必要があります。リモート・プロバイダでクライアント証明書が必要ない場合は、Identity Federationに対してトラスト・ストアのみを構成する必要があります。
SSLクライアントとしてのIdentity Federationにアイデンティティおよびトラスト・ストアを構成するには、複数の方法があります。
WebLogic Serverで構成されたアイデンティティおよびトラスト・ストアを使用するようにIdentity Federationを設定
この場合、WebLogic (WLS) SSLは、トラストおよびアイデンティティ・ストアを使用して構成済です。Identity Federationがクライアントとして動作する場合、WLS SSLと同じアイデンティティおよびトラスト・ストアを使用する必要があります。クライアント証明書が必要な場合は、次のコマンドを実行し、必要な構成を指定します。
putBooleanProperty("/serverconfig/usewlssslconfig", "true") putBooleanProperty("/serverconfig/usejresslconfig", "false") createCred(map="STS", key="wlsclientsslkeystorepwd", user="UniqueUserNameCredential", password="<wlsclientsslkeystorepwd>", desc="wls identity keystore pwd") createCred(map="STS", key="wlsclientssltruststorepwd", user="UniqueUserNameCredential", password="<wlsclientssltruststorepwd>", desc="wls trust keystore pwd")
クライアント証明書が必要ない場合は、次のコマンドを実行し、トラストストアのみを構成します。
putBooleanProperty("/serverconfig/usewlssslconfig", "true") putBooleanProperty("/serverconfig/usejresslconfig", "false") createCred(map="STS", key="wlsclientssltruststorepwd", user="UniqueUserNameCredential", password="<wlsclientssltruststorepwd>", desc="wls trust keystore pwd")
JREアイデンティティおよびトラストストアを使用するようにIdentity Federationを設定
この場合、Identity FederationはJREアイデンティティおよびトラストストアを使用する必要があります。次のWLSTコマンドを実行し、この動作を有効にします。
putBooleanProperty("/serverconfig/usejresslconfig", "true")
Identity Federation固有のアイデンティティおよびトラストストアを設定
この場合、アイデンティティおよびトラストストアは、Identity Federationで完全に構成されています。クライアント証明書の提示が必要な場合は、次のWLSTコマンドを実行してアイデンティティ・ストアおよびトラスト・ストアの場所、タイプおよびパスワードを構成する必要があります。
putBooleanProperty("/serverconfig/usejresslconfig", "false") putBooleanProperty("/serverconfig/usewlssslconfig", "false") putStringProperty("/serverconfig/clientsslkeystoreloc", “<keystorelocation>") putStringProperty("/serverconfig/clientsslkeystoretype", “<keystoretype>") putStringProperty("/serverconfig/clientssltruststoreloc", "<truststorelocation>") putStringProperty("/serverconfig/clientssltruststoretype", "<truststoretype>") createCred(map="STS", key="clientsslkeystorepwd", user="UniqueUserNameCredential", password=”<keystorepassword>", desc="identity keystore pwd") createCred(map="STS", key="clientssltruststorepwd", user="UniqueUserNameCredential", password="<truststorepassword>", desc="trust keystore pwd")
クライアントが証明書の提示を必要としない場合は、次のWLSTコマンドを実行してトラスト・ストアの場所、タイプおよびパスワードのみを構成する必要があります。
putBooleanProperty("/serverconfig/usejresslconfig", "false") putBooleanProperty("/serverconfig/usewlssslconfig", "false") putStringProperty("/serverconfig/clientssltruststoreloc", "<truststorelocation>") putStringProperty("/serverconfig/clientssltruststoretype", "<truststoretype>") createCred(map="STS", key="clientssltruststorepwd", user="UniqueUserNameCredential", password="<truststorepassword>", desc="trust keystore pwd")
このトピックでは、Oracle Access Management Mobile and Social (Mobile and Social)の構成の問題およびその回避方法について説明します。内容は次のとおりです。
「ジェイルブレーク検出ポリシー」の「最高OSバージョン」設定に一度値を割り当てると、値を削除してフィールドを空のままにできません。ドキュメントによると、「最高OSバージョン」フィールドは、ジェイルブレーク・ポリシーを適用する最高iOSバージョンを構成するために使用されます。値が空の場合、最高iOSバージョン番号が確認されず、ポリシーは、「最低OSバージョン」で指定した値よりも上位の任意のiOSバージョンに適用されます。ただし、一度設定すると、値を空に戻せません。この問題を回避するには、「最高OSバージョン」フィールドに値を設定します。
Mobile and Socialをテスト環境から本番環境に移行するとき、テストから本番に移行するスクリプトを実行した後に各本番マシンで次の構成ステップを実行します。
Oracle Access Managementコンソールを起動します。
「ポリシー構成」タブで、「共有コンポーネント」→「認証スキーム」→OICスキームの順に選択してから、「開く」をクリックします。
「認証スキーム」構成ページが開きます。
テスト・マシンではなく本番マシンを指すように「チャレンジ・リダイレクトURL」値を更新し、「適用」をクリックします。
例: https://
production_machine:
port/oic_rp/login.jsp
テスト・マシンから本番マシンを指すようにMobile and Social資格証明ストア・フレームワーク(CSF)エントリを更新します。これを行うには、次のWLSTコマンドを実行します。
createCred(map="OIC_MAP", key=" https://<production machine host>:<production machine port>/oam/server/dap/cred_submit ", user="="<description>", password=" DCC5332B4069BAB4E016C390432627ED", desc="<description>");
password
に、本番マシンのdomain home/config/fmwconfig
ディレクトリにあるoam-config.xml
の値を使用します。RPPartner
エントリの値、TapCipherKey
属性を使用します。
Oracle Access Managementコンソールで、次の手順を実行します。
「システム構成」タブを選択します。
「Mobile and Social」→「インターネット・アイデンティティ・サービス」の順に選択します。
「アプリケーション・プロファイル」セクションで、OAMApplicatonを選択し、「編集」をクリックします。(OAMApplication以外のアプリケーション・プロファイル名を使用している場合、かわりにそれを編集します。)
本番マシンを指すように、「登録URL」フィールドのホスト名およびポートを更新します。
「適用」をクリックします。
この項では、Oracle Access Managementコンソールに影響する問題について説明します。内容は次のとおりです。
Oracle Access Management Access Managerが組込みLDAP以外のユーザー・アイデンティティ・ストアで構成されている場合、次のものを開くことはできません。
「システム構成」、「共通設定」、「使用可能なサービス」
「システム構成」、「共通設定」、「証明書検証」
「システム構成」、「フェデレーション設定」
「システム構成」、トークン・サービス設定
「Oracle Identity Connect」
この問題を解決するには、次の手順に従います。
WebLogic Server管理コンソールにログインします。
セキュリティ・レルムを選択し、「ロールとポリシー」タブを選択します。
「グローバル・ロール」を開いて、「ロール」を開きます。
Adminロールの「ロール条件の表示」をクリックします。
「条件の追加」をクリックします。
述部リストの「グループ」を選択します。
「次へ」をクリックします。
作成したAdminグループの名前を入力します。次に例を示します。
oamadministrator
を追加します。「終了」をクリックします。
必要に応じてWebLogic Serverを再起動します。
OAMサーバーおよびOracle Access Managementコンソールのクライアントが別のロケール用に構成されていると、サーバーは、サーバーで構成されている言語が何であってもクライアントにエラー・メッセージを報告します。
11.1.2のアプリケーション・ドメインの「サマリー」タブの「セッション・アイドル・タイムアウト」および「資格証明有効性タイムアウト」のフィールドは、実装されていません。
セッション設定を構成するには、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の説明に従って、共通セッション・ライフサイクル設定ページを使用します。
次のドキュメントに関するドキュメントの問題はありません。
『Oracle Fusion Middleware Oracle Access Management管理者ガイド』
『Oracle Fusion Middleware Oracle Access Management開発者ガイド』