| Oracle® Fusion Middleware Oracle Fusion Middlewareリリース・ノート 11g リリース1 (11.1.1) for HP-UX PA-RISC (64-Bit) B55939-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Fusion Middlewareリリース・ノート 11g リリース1 (11.1.1) for HP-UX PA-RISC (64-Bit) B55939-06 |
|
前 |
次 |
この章では、Oracle Adaptive Access Managerに関連する問題について説明します。内容は次のとおりです。
この項では、一般的な問題について説明します。内容は次のとおりです。
一部のヘッダーベースのIPアドレスについて、OAAMセッションは記録されていません。
デフォルトでは、ヘッダー・ベースのIPアドレスは受け入れられません。ヘッダーからのIPアドレスの読取りを有効にするには、vcrypt.tracker.ip.detectProxiedIPをtrueに設定します。ヘッダーのIPアドレスを使用可能にする場合、有効なIPアドレスのみを使用します。ヘッダーに無効なIPアドレスが含まれると、実際のリクエストIPアドレスが使用されます。
同じセッションで複数のトランザクションがトリガーされると、「セッション詳細」ページの「チェックポイント」ボックスには同じタイムスタンプが表示されます。このバグはOAAMオンラインでは修正されています。
OAAMエージェント・ケースが構成可能なアクションから自動生成される場合、「ユーザー詳細」ペインには、ケースが作成されたセッションのユーザーの詳細が移入されます。自動生成されたエージェント・ケースには、ユーザー固有データを含めないようにする必要があります。エスカレーション済エージェント・ケースが単一のエンド・ユーザーのみに固有のケースであるので、それでのみユーザーの詳細を表示する必要があります。
この項では、ポリシー管理の問題および回避策について説明します。内容は次のとおりです。
エンティティの2つのインスタンスがOAAMトランザクションに関連付けられており、フィルタ条件が一方のエンティティ・インスタンスと他方のエンティティ・インスタンスの属性を比較するように設計されている場合、OAAM管理コンソールでは同じ属性間の比較の構成のみが可能で、異なる属性間の比較はできません。
次に例を示します。
Addressエンティティの2つのインスタンスがトランザクションに関連付けられており、一方のインスタンス名はBillingAddrで、もう一方のインスタンス名はShippingAddrです。ユーザーがBilling.line1とShippingAddr.line1を比較するように「フィルタ条件を使用した現在のトランザクションの確認」を構成した場合、ルールを保存した後、OAAM管理コンソールでは常にユーザーが比較する必要がある属性のロックダウンおよびユーザーが比較している属性のドロップダウンにインスタンス「--- line1 of BillingAddr」が表示されます。
ルール条件「トランザクション: 特定期間中の連続トランザクションがフィルタ条件を満たすかどうかの確認」はトリガーしません。この条件はFalseを返し、エンティティ・チェックはデバッグ・ログに例外を出力して失敗します。
「IPリストの除外」パラメータが次の条件に追加されています。
デバイス: 最後のログインからの速度
ユーザー: 最後のログインからの速度
このパラメータを使用して、無視するIPアドレスのリストを指定できます。ユーザーのIPアドレスがそのリストにある場合、この条件は常にfalseに評価されアクションやアラートはトリガーされません。ユーザーのIPアドレスがこのリストに含まれないか、リストがnullまたはemptyである場合、条件は、最後のログインからのユーザーまたはデバイスの速度を評価します。最後のログインからのユーザーまたはデバイスの速度がルールで構成された値より大きい場合、条件はtrueに評価され、この条件はトリガーされます。
同じセッション内に複数のトランザクションが実行されている場合、最後のトランザクションでトリガーされたルールのみがOAAMオフラインで表示されます。前のトランザクションからのルールは上書きされます。このバグを修正するには、パッチを適用し、データベース・スキーマを更新する必要があります。
「ユーザー: 初回ログイン時間の確認」条件は、ユーザーがログインした時間にかかわらず同じ値を返していました。
この項では、OAAMトランザクションの問題について説明します。内容は次のとおりです。
複数のトランザクションが同じセッション内でトリガーされ、これにより複数のアラートおよびポリシーの実行が発生する場合、OAAMではトリガーされた最新のアラートおよびポリシーのみが表示され、前のトランザクションからのアラートおよびポリシーは上書きされます。
トランザクションで構成されたデータ要素が25を超える場合、「セッション詳細」には最初の25項目のトランザクションの詳細のみが表示されます。このページにはスクロール・バーはありません。
25番目を超えるトランザクションはアラートが表示されません。アラートを含むチェックポイント・ボックスが25より多い場合、そのデータはデータベースにあるにもかかわらず、「セッション詳細」には表示されません。
ユーザーがトランザクション・フィールドに16桁を超える数値を定義している場合、トランザクションの作成は「ORA-01438: この列に許可されている指定の精度より大きな値です」というサーバー上のエラーが出力されて失敗します。
「セッション詳細」の「セッション・トランザクション」セクションにリストされているトランザクションは、セッション内の25トランザクションの後で重複します。
processRules APIでtransactionIdを渡した後でも、トランザクションIDとアラートとの関連付けは機能しません。このバグは、サーバー側では修正されています。
トランザクション・ステータスは「トランザクション詳細」ページに表示されて、トランザクションを試行したが完了しなかったかどうかを不正チームがわかるようにする必要があります。これにより、顧客と不正行為者の両方の動作に関する情報を取得したり、ルールが機能しているか確認することもできます。トランザクション・ステータスを識別できないと、Fraudチームは職務を効率的に遂行できるという確信が持てません。この回避策は、「セッション・トランザクション」パネルで各トランザクションのステータス値を、「名前」、「トランザクションID」、「説明」および「タイムスタンプ」とともに表示することです。表示される値は、プロパティtracker.transaction.status.enum (たとえば、1=Success、99=Pendingなど)からマップされます。
ユーザーがSubStringタイプのトランザクション・マッピングを実行すると、その値の最初の文字がマッピングの結果から欠落します。これは、oaam.transaction.mapping.startindex.minプロパティが1に設定されているためです。このプロパティを1に設定すると、文字列の2番目の文字からサブストリング操作が開始されます。サブストリング操作が文字列の最初の文字から開始されるように、このプロパティは0に割り当てられるように修正されています。
トランザクションでトランザクション定義にマップされているエンティティを使用すると、エンティティ・データに変更がなくても、OAAMサーバーによりエンティティの更新時刻が更新されます(他のフィールドは更新されません)。これが発生するとデータベースのパフォーマンスに影響します。
この項では、ナレッジベース認証の問題について説明します。内容は次のとおりです。
「KBA登録ロジック」ページにはKBAロジック(「1メニュー当たりの質問数」、「1メニュー当たりのカテゴリ数」、「ユーザーが登録する質問数」)が表示されません。これは、前の即時利用可能なスナップショットに「KBA登録ロジック」ページのプロパティが含まれていないためです。パッチでこの問題を解決します。この修正を有効にするには、新しい即時利用可能なスナップショット・ファイル(oaam_base_snapshot.zip)をインポートする必要があります。このファイルをインポートすると、サーバー内の既存のコンテンツは上書きされるので注意してください。
スナップショット・ファイルをインポートせずに登録ロジックに関する問題を修正する場合は、次のプロパティを作成できます(次に示すデフォルト値を使用します)。
challenge.question.registration.groups.categories.count=5 challenge.question.registration.groups.count=3 challenge.question.registration.groups.minimum.questions.per.category.count=1 challenge.question.registration.groups.questions.count=5
パッチでは、ユーザーがOTPチャレンジに失敗した際にチャレンジでKBAをフォールバックとして使用するようにポリシー・オーバーライドも修正しています。コンテンツを上書きせず、より新しいポリシーのインポートのみを行う場合、ポリシーのインポートとしてoaam_policies.zipをインポートできます。ポリシーをインポートしても、バグに関連する登録ロジックは修正されません。
回答ロジックにより、ユーザーが指定した回答が登録時に指定された回答と厳密に一致するかどうかがチェックされます。回答ロジックは略語に依存します。
更新された回答ロジックの略語のリソース・バンドルは、OAAM 11.1.1.5で使用できます。新しいリソース・バンドルでは、次の項目が一致とみなされます。
| 登録済の回答 | 指定された回答 |
|---|---|
|
Missus |
Mrs |
|
Mister |
Mr |
|
Sergeant |
Sgt |
|
Mrs |
Missus |
|
Mr |
Mister |
|
Sgt |
Sergeant |
前のリリースでの次のKBA質問は、Federal Financial Institutions Examination Council (FFIEC)のコンプライアンスに対応し、kba_questions.zip (英語)ファイルおよびoaam_base_snapshot.zipファイルから削除されました。
子カテゴリ
次の10の質問を削除または非アクティブ化します。
一番年上のお子さんの誕生は何年でしたか。
一番年上のお子さんの小学校入学は何年でしたか。
一番年下のお子さんの小学校入学は何年でしたか。
一番年上のお子さんのミドル・ネームは何ですか。
一番年下のお子さんは何という名ですか。
一番年下のお子さんの誕生は何年でしたか。
一番年上のお子さんは何という名ですか。
一番年下のお子さんの誕生日はいつですか。
一番年下のお子さんのミドル・ネームは何ですか。
一番年上のお子さんの誕生日はいつですか。
教育カテゴリ
次の18の質問を削除または非アクティブ化します。
高校卒業は何年でしたか。
中学校卒業は何年でしたか。
高校があったのは何市でしたか。
大学のスクール・カラーは何色でしたか。
小学校卒業は何年でしたか。
大学のマスコットは何でしたか。
高校のスクール・カラーは何色でしたか。
高校のマスコットは何でしたか。
出願したが入学しなかった大学の名前は何ですか。
最初の小学校があったのは何市でしたか。
高校入学は何年でしたか。
中学校入学は何年でしたか。
小学校入学は何年でしたか。
大学卒業は何年でしたか。
大学入学は何年でしたか。
大学での専攻は何でしたか。
最初に通った学校は何でしたか。
大学があったのは何市でしたか。
その他のカテゴリ
次の2つの質問を削除または非アクティブ化します。
子供時代に一番親しかった友人は何という名ですか。
身長はどれくらいですか。
父母、祖父母、兄弟姉妹カテゴリ
次の17の質問を削除または非アクティブ化します。
父親が生まれたのは何年でしたか。
父親の誕生日はいつですか。
一番年上の兄弟姉妹の愛称は何ですか。
父親が生まれたのは何市ですか。
母親が生まれたのは何市ですか。
両親の現住所の番地は何番ですか。
両親の現住所は何町ですか。
一番年下の兄弟姉妹の愛称は何ですか。
両親の現住所の郵便番号は何番ですか。
母親が生まれたのは何年でしたか。
両親の電話番号の下4桁は何番ですか。
母方の祖母は何という名ですか。
父方の祖母は何という名ですか。
一番年下の兄弟姉妹は何という名ですか。
父方の祖父は何という名ですか。
母親の誕生日はいつですか。
一番年上の兄弟姉妹は何という名ですか。
重要なその他のカテゴリ
次の18の質問を削除または非アクティブ化します。
新婚旅行はどこに行きましたか。
あなたが結婚したのは何年ですか。
あなたの大切な人が生まれたのは何年ですか。
あなたの大切な人の誕生日はいつですか。
結婚記念日はいつですか。
初めて奥様/ご主人と知り合ったのは何市ですか。
あなたの大切な人が生まれたのは何市でしたか。
あなたの大切な人の母親は何という名ですか。
あなたの大切な人の父親は何という名ですか。
あなたの大切な人の一番年上の兄弟姉妹は何という姓ですか。
あなたの大切な人の一番年下の兄弟姉妹は何という名ですか。
あなたの大切な人はどの高校に通っていましたか。
あなたの花婿/花嫁付添人は何という姓でしたか。
あなたの花婿/花嫁付添人は何という名でしたか。
結婚披露宴会場の名称。
奥様/ご主人を何と呼んでいますか。
あなたの大切な人が生まれたのは何県でしたか。
あなたの大切な人の一番年下の兄弟姉妹は何という姓ですか。
スポーツ・カテゴリ
次の4つの質問を削除または非アクティブ化します。
好きなスポーツ・チームのマスコットは何ですか。
好きなスポーツ・チームのチーム・カラーは何色ですか。
好きなスポーツ・チームの最大のライバルはどのチームですか。
これまでで一番お気に入りのスポーツ・チームはどこですか。
出生カテゴリ
次の9つの質問を削除または非アクティブ化します。
育った場所の郵便番号は何番ですか。
あなたが生まれたとき米国大統領は誰でしたか。
あなたが生まれたとき父親は何歳でしたか。
あなたが生まれたとき母親は何歳でしたか。
あなたが生まれた病院の名前は何ですか。
生まれた場所の郵便番号は何番ですか。
誕生日に一番近い祝日は何ですか。
生まれたのは何県でしたか。
生まれたのは何市でしたか。
ユーザーが初めてセキュリティ・イメージおよびフレーズを登録しようとして、その処理中に登録およびユーザー・プリファレンス・ページでブラウザ・ウィンドウを閉じるか、ログイン・ページに戻ると、表示された最後のイメージおよびフレーズが、「続行」ボタンをクリックして明示的に選択していなくても、デフォルトとして受け入れられます。
これは、イメージおよびフレーズの登録で、ユーザーが登録およびユーザー・プリファレンス・ページの「続行」をクリックしないとイメージおよびフレーズが保存されないように修正されました。
OAAMおよびOIMでは「パスワードの変更」ページの「パスワード」フィールドに検証内容が表示されません。問題点は次のとおりです。
ユーザーがパスワードを入力せずに「送信」をクリックすると、検証は行われずフィールドは空になります。
ユーザーが新しいパスワードと確認パスワードを入力すると、それらのパスワードが同じでも異なってもパスワードは受け入れられます。
ユーザーがパスワードを変更する場合、古いパスワードが正しいかどうか検証されません。
新しいチャレンジ質問を追加するときに、ORA-01722エラーが発生する場合があります。
ユーザーの質問セットに削除された質問が含まれる場合、ユーザーの登録済の質問に削除された質問が含まれる場合、KBA登録ロジックがユーザーの登録済の質問および質問セットと整合しない場合(質問/カテゴリの数など)などに、ユーザーが質問セットを更新しようとしたが、そのブラウザ・ウィンドウを取り消したり閉じたとき、または保存せずにセッションがタイムアウトすると、そのユーザーの既存の質問はデータベースから削除されます。既存の質問が削除されているので、後続のチャレンジは成功しません。
この問題は、ユーザーの登録済の質問が質問の再設定の処理時に削除された場合、次のログイン時に新しい質問を再登録するようにユーザーに促すように修正されています。
この項では、OAAM統合の問題について説明します。内容は次のとおりです。
setupOAMTapIntegration.shスクリプトは、Oracle Access ManagerとOracle Adaptive Access Managerの統合のためにOracle Adaptive Access Managerを構成する間に、セカンダリOAMホスト情報(oaam.uio.oam.secondary.host.port値)を設定しません。回避策として、プロパティ・エディタを使用してプロパティ値を設定します。
Juniper SSLと統合されている場合、OAAM認証フローは呼び出されません。OAAMを呼び出すことで、統合は認証フローで不正行為を検出してリスクを特定でき、それに応じて、Challenge、Block、その他のアクションなどのOAAM機能を使用してユーザーを強力に認証します。Juniper SSLとOAAMの統合フローは次のようにする必要があります。
ユーザーがJuniper SSLで保護されるWebアプリケーションまたはURLにアクセスしようとすると、Juniper SSLはそのユーザーが認証済かどうかを検出します。
ユーザーが認証されると、そのWebアプリケーションに進むことができます。
認証されていないと、OAAMサーバーにリダイレクトされます。OAAMサーバーは「ユーザーID」ページを表示し、ユーザーIDを入力するようにユーザーに促します。ユーザーIDが入力されると、OAAMは認証前チェックポイント・ポリシーを評価して、ユーザーをブロックする必要があるかどうかを確認します。
次に、OAAMはユーザーが認証パッドを登録しているかどうかを確認します。ブロックの必要が確認された場合は、登録された認証パッドが表示され、確認されない場合は、汎用テキスト・パッドが表示されます。
OAAMサーバーは認証パッドのあるパスワード・ページを表示し、パスワードを入力するようユーザーに促します。パスワードが入力されると、それをユーザー・ストアと照合します(ユーザー・ストアにはLDAP、Active Directoryまたは任意のアクティブなユーザー・ストアが使用できます)。また、デバイス識別プロセスを実行してデバイスの識別も行われます。
資格証明が正しくない場合は、エラー・ページが表示されて、資格証明を再入力するようユーザーに要求します。
資格証明が正しい場合は、認証後チェックポイント・ポリシーが評価されます。ポリシーの結果に基づいて、OAAMはユーザーに対してチャレンジまたはブロックします。
認証後の結果がALLOWの場合は、ユーザーを登録する必要があるかどうかが判別されます。登録のタイプに基づいて、登録ページが順次に表示されます。
認証後の結果がCHALLENGEであり、ユーザーが1つ以上のチャレンジ・メカニズムにすでに登録されている場合、OAAMはユーザーにチャレンジします。ユーザーがチャレンジに回答できると、引き続き次のステップに進めます。次のステップでOAAMはユーザー・ストアからユーザー属性を取得して、SAMLレスポンスを作成し、それに署名して、そのレスポンスをJuniper SSLのリダイレクションURLにポストします。ここでJuniper SSLに制御が移り、SAMLペイロードを検証して、ユーザーにWebアプリケーションへのアクセスを許可します。
認証後の結果がBLOCKの場合は、ユーザーはブロックされ、Webアプリケーションにアクセスできません。
OAAMでセットアップ認証機能を使用できます。セットアップ認証機能を使用すると、下位レベルでOAMに認証されているユーザーが、比較的高い認証レベルで構成されたOAAMTAPSchemeによって保護されたリソースにアクセスできます。ユーザーが高いレベルで構成されている保護されたリソースにアクセスしようとすると、OAAMは保護されたリソースへのアクセスに必要な認証レベルを取得するためにさらにユーザーを認証する方法を決定するポリシーを実行します。ユーザーはすでに認証されているので、通常のログイン・フローには進みません。
TAP統合のセットアップ認証モードを有効化/無効化するプロパティ: デフォルトでは、セットアップ認証モードは有効です。ただし、この機能を無効にする場合、プロパティoaam.uio.oam.integration.stepup.enabledをfalseに設定します。
エンド・ユーザーの動作の変更: Access Manager-OAAM TAP統合を使用するエンド・ユーザーに対する動作の変更は次のとおりです。
ユーザーがすでにAccess Managerで認証されており、このユーザーがTAPパートナとしてOAAMでTAPSchemeの下で保護されるリソースにアクセスしようとする場合、OAAMログイン・フローには進みません(このユーザーはすでに認証されているため)。ただし、OAAMはその不正検出ポリシーを実行し、ポリシーで評価されたリスクに応じてチャレンジ質問をしたりユーザーをブロックします。
Access Manager-OAAM TAP統合では、無効なユーザー名またはパスワードが指定されると、OAAMにより次のエラーが表示されます。
There was some technical error processing your request. Please try again
パッチはこの問題を解決しています。エラー・メッセージは、技術的エラーでなく、無効なユーザー名またはパスワード・エラーと示されるようになりました。
Webサービスをコールするクライアントは、タイムアウトの例外が取得されません。そのためクライアントは、例外がSOAPタイムアウトか別の原因か判断できないため、SOAPタイムアウトを正しく処理できません。タイムアウトの特定のエラー・コードがクライアントに渡されるように、修正が実装されています。そのため、クライアントは例外に含まれる情報ごとにフォルトを処理できます。
メソッドhandleException()ではクラスVCryptSOAPGenericImplが導入され、ビジネス要件に基づいて多くのエラー・コードを含めるようにこれをオーバーライドできます。現在、これはsoaptimeoutエラーで設定されています。
protected String handleException(String requestName, Exception ex, String resultXml) {
Oracle Identity ManagerとAccess Managerの統合においてOAAMによって実行されるパスワードを忘れた場合のフローで、ユーザーがパスワードを変更する際にロック解除されません。OAAMがchangePassword() APIを実行する際、Oracle Identity Managerによってユーザーが自動的にロック解除されることはありません。
パスワードを忘れた場合のフローでOAAMがchangePassword () APIを実行する際に、Oracle Identity Manager側のユーザーのロックを自動的に解除できるようにするには、次の手順が必要です。
OAAM管理コンソールにログインします。
ナビゲーション・ペインで、「環境」をクリックしてから、「プロパティ」をダブルクリックします。「プロパティ」検索ページが表示されます。
oaam.oim.passwordflow.unlockuserをtrueに設定します。
デフォルトでは、このプロパティ値はfalseに設定されます。このプロパティをtrueに設定すると、OAAMはパスワードの変更タスク・フローでOracle Identity Managerのunlock APIをコールします。
この項では、OAAM BI Publisherレポートおよびセッションの問題および回避策について説明します。内容は次のとおりです。
「セッションの詳細」ページのアラート・メッセージ・リンクから「アラート詳細」ページにアクセスしようとしてもページが開きません。
この問題を回避するには、「セッション検索」ページのアラート・メッセージ・リンクを使用します。
BI Publisherルール・ブレークダウン・レポートには、チェックポイントおよびポリシーでトリガーされたルールのサマリーが示されません。示される値は不完全または不正確です。
レポートを機能させるには、次のスクリプトを実行します。
create or replace view OAAM_FIRED_RULES_VIEW as (
select actionMap.create_time, ruleMaps.rule_map_id, actionMap.request_id,
actionMap.runtime_type,
sessions.user_id, sessions.node_id, actionMap.action_list
from (select substr(attr_name, 7) ruleInstanceId, case when
length(trim(translate(attr_value, '+-.0123456789', ' '))) is null then
CAST(attr_value AS NUMBER(16)) else null end rule_map_id, fprint_id from
v_fp_map where attr_name like 'RLD_ID%') ruleMaps
inner join vt_session_action_map actionMap on actionMap.rule_trace_fp_id =
ruleMaps.fprint_id
inner join vcrypt_tracker_usernode_logs sessions on sessions.request_id =
actionMap.request_id
inner join (select substr(attr_name, 11) ruleInstanceId, case when
length(trim(translate(attr_value, '+-.0123456789', ' '))) is null then
CAST(attr_value AS NUMBER(16)) else null end attr_value, fprint_id from
v_fp_map where attr_name like 'RLD_STATUS%') ruleStatus
on ruleStatus.ruleInstanceId = ruleMaps.ruleInstanceId and
ruleStatus.fprint_id = ruleMaps.fprint_id
where ruleStatus.attr_value=1
union select ruleLogs.create_time, ruleLogs.rule_map_id,
policySetLogs.request_id, policySetLogs.runtime_type,
userNodeLogs.user_id, userNodeLogs.node_id, ruleLogs.action_list
from VR_RULE_LOGS ruleLogs
inner join VR_MODEL_LOGS modelLogs on ruleLogs.MODEL_LOG_ID =
modelLogs.MODEL_LOG_ID
inner join VR_POLICY_LOGS policyLogs on modelLogs.POLICY_LOG_ID =
policyLogs.POLICY_LOG_ID
inner join VR_POLICYSET_LOGS policySetLogs on policyLogs.POLICYSET_LOG_ID =
policySetLogs.POLICYSET_LOG_ID
inner join VCRYPT_TRACKER_USERNODE_LOGS userNodeLogs on
policySetLogs.REQUEST_ID = userNodeLogs.REQUEST_ID
where ruleLogs.status=1);
commit;
この項では、次の構成の問題とその回避策について説明します。
oaam_db_purging_scripts.zipファイルにケースおよび監視データ・パージ・スクリプトがありません。
ケース・データをパージするには、次のスクリプトが含まれる必要があります。
create_case_purge_proc.sql
Oracleデータベースのアーカイブを設定してルーチンをパージするには、create_case_purge_proc.sqlスクリプトが必要です。
exec_sp_purge_case_data.sql
ケース・データのアーカイブおよびパージを実行するには、exec_sp_purge_case_data.sqlが必要です。
監視データをパージするには、次のスクリプトが含まれる必要があります。
drop_monitor_partition.sql
Oracle表パーティション化オプションを使用していてレポーティング・データベースがない場合、監視データのパージ・ルーチンを設定する前に、drop_monitor_partition.sqlスクリプトを実行する必要があります。
exec_v_monitor_purge_proc.sql
exec_v_monitor_purge_proc.sqlスクリプトは、デバイス・フィンガープリント表からデータをアーカイブおよびパージするストアド・プロシージャをコールします。
create_v_monitor_purge_proc.sql
create_v_monitor_purge_proc.sqlスクリプトを使用すると、V_MONITOR_DATA_PURGE表およびストアド・プロシージャSP_V_MON_DATA_PURGE_PROCが作成され、トランザクション表のデータをアーカイブおよびパージできるようになります。
認証に成功した後、OAAMは、ユーザー・ストアからユーザー属性を取得し、SAMLアサーションのユーザー属性をJuniperに送信します。Juniperは、SAMLアサーションから読み取る属性を検索し、そのリポジトリのユーザーと照合するように設計されています。次に、リクエストしたターゲットのページまたはWebアプリケーションにユーザーをログインします。
この不具合では、Juniperがユーザーを識別できないため、ユーザーはOAAMを介してJuniperにログインできません。OAAMは正しいcn (一般名)の値をフェッチしておらず、SAMLレスポンスのuid (ユーザーID)属性を設定していません。
この項では、カスタマ・ケアおよび調査の問題について説明します。内容は次のとおりです。
ユーザーにInvestigatorとCSR Accessロールを付与すると、前者が後者のアクセス権限をオーバーライドし、ユーザーが持つのはInvestigatorアクセス権のみになり、CSRアクセス権はなくなります。InvestigatorとCSRの両方のタスクを実行できるようにするには、ユーザーがその両方のアクセス権を持つことが想定される動作になります。求められる動作は、ユーザーがInvestigatorとCSRの両方のアクセス権を持つことであり、InvestigatorとCSRのタスクを実行できるようにする必要があります。
低解像度のモニターを使用するユーザーは、「ケース詳細」ページの全画面を詳細に表示することができません。詳細情報は、ユーザーのロールに基づいて使用可能な情報を参照しています。低解像度のモニターを使用するユーザーがすべての詳細情報を表示できるように、「ケース詳細」ページにはスクロール・バーが必要です。
OAAMエージェント・ケースを「確認済不正」の処置で閉じた後、エージェントは処置で検索することでケースを特定できますが、「ケース」検索ページには、表示する列として「処置」を追加していても、「確認済不正」は表示されません。同じケースの「ケース詳細」ページを開くと、「処置」のフィールドは空になります。
OAAMでは2人のエージェントが同時に1つのケースにアクセスできます。2人のエージェントがノートをそのケースに追加する場合、OAAMは両方のエージェントのノートを保存しますが、2番目のエージェントのノートは最初のエージェントが追加したものとして表示されます。ケースの同時書込みアクセスはサポートされます: 2人のエージェントがケースに同時にアクセスすると、2番目のエージェントはケースが別のエージェントによって作業中であると警告メッセージで通知されます。2番目のエージェントが続行すると、そのケースの所有者になります。ノートは正しいエージェントに帰属します。
OAAMエージェント・ケースが構成可能なアクションから自動生成される場合、「ユーザー詳細」パネルには、ケースが作成されたセッションのユーザーの詳細が移入されます。手動でケースを作成してセッションをリンクすると、ユーザーの詳細は移入されません。その後UsernameまたはUser IDでケースを検索すると、自動的に作成されたケースのみが特定されます。
エージェント・ケースの作成ページは、oaam.customercare.agent.case.allow.userinfoプロパティがtrueに設定されていると、有効なUsernameやUser IDのエントリをオプションで受け取れます。UsernameやUser IDが入力されている場合、それはエージェント・ケースにマップされます。UsernameやUser IDにマップされたエージェント・ケースは、UsernameやUser IDで検索可能になります。これらのケースでは、「ケース」検索ページの「ユーザー名」や「ユーザーID」列にマップされたユーザー識別子が表示されます。CSRケースからエスカレートされたエージェント・ケースのみが、「ケース詳細」サマリー・タブの下の「ユーザー詳細」セクションに表示されます。
エージェント・ケースを閉じた後、別のユーザーがそれにアクセスすると、ケースの所有権を変更できてしまいます。ケースの所有者は、ケースにアクセスしたユーザーに変更されます。また、OAAMはケースを閉じた後もノートの追加および編集を許可します。本来は、エージェント・ケースを閉じた後は、いかなる変更も許されません。
構成可能なアクションでCreate Agent Caseアクションをトリガーする場合、これをアクション・グループに追加するときに、アクションの「名前」と「説明」の両方のAdd to IP Watch listとして表示されます。
チャレンジ失敗カウンタは、詳細ページのようにCSRケース詳細には表示されません。KBAおよびOTPの失敗カウンタは、新規またはカスタムのチャレンジ・プロセッサと同様に表示する必要があります。また、Resetアクションですべてのカウンタがリセットされません。Unlockアクションにより、すべてのカウンタ(KBAおよびOTP)をリセットする必要があります。Unlockアクションを実行するときに、カウンタに対して次の処理が必要です。
KBAをロック解除すると、KBAおよびOTP失敗カウンタが0にリセットされる
OTPをロック解除すると、KBAおよびOTP失敗カウンタが0にリセットされる
Resetアクションを実行するときに、失敗カウンタに対して次のアクションが必要です。
KBAをリセットすると、KBAおよびOTP失敗カウンタが0にリセットされる。ユーザーはチャレンジ質問を再登録する必要があります。
CSR KBAをリセットすると、KBAおよびOTP失敗カウンタが0にリセットされる。ユーザーはチャレンジ質問を再登録する必要があります。
OTPをリセットすると、KBAおよびOTP失敗カウンタが0にリセットされる。ユーザーはOTPを再登録する必要があります。
次のように機能強化されました。
OAAM管理コンソールの「ケース詳細」ページには、KBA、OTPおよびその他のカスタム・チャレンジ・メカニズムに関する失敗カウンタや登録などの情報が表示されます。
異なるチャネルのOTP失敗カウンタで失敗が統合されます。たとえば、複数のチャネルを使用している場合、まとめられたOTPカウンタがしきい値を上回ると、OTPステータスが「ロック済」と表示されます。そのため、しきい値が3の場合、ユーザーがSMSを2回失敗し、電子メールを一度失敗すると、統合されたOTPカウンタを使用してそれらがロックされます。
Resetアクションは、すべてのチャレンジ失敗カウンタをリセットします。
Unlockアクションは、KBAおよびOTPをロック解除する個々のアクションではなく、Unlock Userアクションに統合されます。Unlock Userアクションは、すべての失敗カウンタをリセットします
ユーザー名は、「ケースID」のかわりにまたは「ケースID」とともに「ケース詳細」タブに表示されます。
失敗カウンタのしきい値は、ルール条件、User: Challenge Channel Failureに設定できます。
この項では、パフォーマンスの問題について説明します。内容は次のとおりです。
「セッション検索」ページを上または下にスクロールすると、空またはnullの入力リストが渡されます。これにより、データベースから大量の行数を取得しようとして、エラーjava.lang.OutOfMemoryError:GC overhead limit exceededが発生する場合があります。
この項では、地理的位置情報ローダーの問題について説明します。内容は次のとおりです。
同じ位置データ・ファイルをリロードしたり、更新された位置データ・ファイルをロードすると、データは正しくロードされますが、ログ・ファイルには一意制約違反に関する大量の警告が出力され、パフォーマンスが低下します。
データ・ファイル内に空白行があると、OAAMデータ・ローダーはIP位置データのロードに失敗し、行番号をレポートしません。OAAMデータ・ローダーに求められる結果は、空白行をスキップして、行番号を含む警告メッセージを表示することです。
この問題を回避するには、IP位置データ・ファイルを開いて、空白行を削除し、そのファイルを保存します。この問題は、将来のリリースで修正される予定です。
この項では、多言語のサポートの問題および制限について説明します。内容は次のとおりです。
ブラウザの言語がイタリア語に設定されている場合、ユーザーは、OAAM管理コンソールでセッション・ページやケース・ページなどカレンダのあるページを開くことができません。次のエラー・メッセージを示すポップアップ・ウィンドウが表示されます。
java.lang.IllegalArgumentException: Illegal pattern character 'g'
ブラウザの言語がポルトガル語(ブラジル)またはスペイン語に設定されている場合、OAAM管理コンソールでの日付範囲によるセッションおよびケースの検索は機能しません。ユーザーがスペイン語またはポルトガル語(ブラジル)ロケールのセッションまたはケース・ページでカレンダを開くと、年の値は常に1970と表示され、正しい年に変更できません。その結果、検索は機能せず、必要なデータを検索結果に返すことができません。
