1. Oracle Advanced AuthenticationおよびOracle Adaptive Risk Managementの管理
  2. Oracle Advanced Authenticationの管理
  3. Oracle Advanced Authenticationの構成

11 Oracle Advanced Authenticationの構成

トピック

11.1 OAAでの統合エージェントの作成

クライアント・アプリケーションをOAAと統合するには、統合エージェントを作成する必要があります。OAM統合エージェントとOracle RADIUS統合エージェントを作成できます。独自のREST APIクライアント・アプリケーションで使用するその他の統合エージェントを作成することも可能です。

統合エージェントは、REST APIまたはOAA管理UIコンソールのいずれかを使用して作成できます。REST APIを使用した統合エージェントの作成の詳細は、Oracle Advanced Authenticationでの管理用REST APIを参照してください。

Oracle RADIUS統合エージェントを作成するには、マルチファクタ認証のためのOracle RADIUSエージェントとOracle Advanced Authenticationの使用を参照してください

OAA管理UIコンソールでOAM統合エージェントを作成するには:

ノート:

OAMとOAAの統合の詳細は、Oracle Access ManagementとOracle Advanced Authenticationの統合を参照してください
  1. OAA管理コンソールhttps://<AdminUrl>にログインします。コンソールはOAM OAuthで保護されているため、OAMログイン・ページにリダイレクトされます。資格証明およびログインを指定します。
  2. 「クイック・アクション」で、OAM統合エージェントの作成を選択します。
  3. 統合エージェントの作成ウィンドウで、次の指定を行います:
    1. 名前: OAM統合の場合、値は、OAAをTAPパートナとして登録する際に作成されたパートナ名と同じである必要があります。詳細は、OAMのTAPパートナとしてのOAAの登録に関する項を参照してください
    2. 説明: 統合エージェントの説明を追加します。
    3. 統合エージェント・タイプ: デフォルトでOracle Access Managementが選択されています。
    4. クライアントID: 「再生成」をクリックしてクライアントIDを作成し、「コピー」をクリックして生成されたクライアントIDをコピーします。

      ノート:

      OAAAuthnPluginを使用してOAAと統合するようにOAMを構成する場合は、クライアントIDを指定する必要があります。詳細は、OAMでのOAAプラグインのインストールおよび構成に関する項を参照してください
    5. クライアント・シークレット: 「再生成」をクリックしてクライアント・シークレットを作成し、「コピー」をクリックして生成されたクライアント・シークレットをコピーします。

      ノート:

      OAAAuthnPluginを使用し、OAAとの統合に備えてOAMを構成する場合は、クライアント・シークレットを指定する必要があります
    6. 秘密キー・ファイル: OAAのTAPパートナとしてOAMを登録した後に作成されたJavaキーストア・ファイル(.jks)をドラッグ・アンド・ドロップします。たとえば、OAMOAAKeyStore.jksです。
    7. 秘密キーのパスワード: OAAのTAPパートナとしてOAMを登録する際に指定したパスワードを指定します。
  4. 「保存」をクリックします

独自のREST APIクライアント・アプリケーションで使用する統合エージェントを作成するには:

  1. OAA管理コンソールhttps://<AdminUrl>にログインします。コンソールはOAM OAuthで保護されているため、OAMログイン・ページにリダイレクトされます。資格証明およびログインを指定します。
  2. 「クイック・アクション」で、その他の統合エージェントの作成を選択します。
  3. 統合エージェントの作成ウィンドウで、次の指定を行います:
    1. 名前: 統合エージェントの名前を入力します。
    2. 説明: 統合エージェントの説明を追加します。
    3. 統合エージェント・タイプ: デフォルトで「API」が選択されています。
    4. クライアントID: 「再生成」をクリックしてクライアントIDを作成し、「コピー」をクリックして生成されたクライアントIDをコピーします。

      ノート:

      アプリケーションの構成時には、クライアントIDを指定する必要があります。
    5. クライアント・シークレット: 「再生成」をクリックしてクライアント・シークレットを作成し、「コピー」をクリックして生成されたクライアント・シークレットをコピーします。

      ノート:

      アプリケーションの構成時には、クライアント・シークレットを指定する必要があります。
  4. 「保存」をクリックします。

11.2 OAAでの保証レベルの作成

統合エージェントの保証レベルは、REST APIまたはOAA管理UIコンソールのいずれかを使用して作成できます。REST APIの使用の詳細は、保証レベルの作成に関する項を参照してください。

次のステップでは、OAA管理UIコンソールで統合エージェントの保証レベルを作成する手順を説明します:
  1. OAA管理コンソールhttps://<AdminUrl>にログインします。コンソールはOAM OAuthで保護されているため、OAMログイン・ページにリダイレクトされます。資格証明およびログインを指定します。
  2. 統合エージェントが最近作成された場合は、「最近のアクティビティ」の下に表示されます。ただし、統合エージェントが「最近のアクティビティ」に表示されない場合は、次のいずれかを実行します:
    • 他のエージェントも表示をクリックします
    • ページの左上にある「アプリケーション・ナビゲーション」アイコンをクリックし、統合エージェントの管理を選択します
  3. 統合エージェント・ウィンドウで、保証レベルを作成する必要がある統合エージェントを選択します。
  4. 「保証レベル」タブで、「作成」をクリックします
  5. 必要な詳細を指定します:
    • 名前: この保証レベルの名前を指定します
    • 説明: 保証レベルの説明を入力します。
  6. 「作成」をクリックします。

11.3 OAAでの保証レベルのルールの構成

OAA管理UIコンソールまたはREST APIを使用して、保証レベルのルールを管理できます。OAA管理UIコンソールで保証レベルのルールを作成すると、それらのルールのポリシーが自動的に作成されます。REST APIでルールを作成する場合は、REST APIを使用して、先にポリシーを作成する必要があります。REST APIを使用したポリシーおよび関連ルールの作成の詳細は、ポリシーの作成に関する項を参照してください

次のステップでは、OAA管理UIコンソールで保証レベルのルールを作成する手順を説明します:

  1. OAA管理コンソールhttps://<AdminUrl>にログインします。コンソールはOAM OAuthで保護されているため、OAMログイン・ページにリダイレクトされます。資格証明およびログインを指定します。
  2. 統合エージェントが最近作成された場合は、「最近のアクティビティ」の下に表示されます。ただし、統合エージェントが「最近のアクティビティ」に表示されない場合は、次のいずれかを実行します:
    • 他のエージェントも表示をクリックします
    • ページの左上にある「アプリケーション・ナビゲーション」アイコンをクリックし、統合エージェントの管理を選択します
  3. 統合エージェント・ウィンドウで、必要な統合エージェントを選択します。
  4. 「保証レベル」タブで、ルールの定義が必要な必須保証レベルを選択します
  5. 「使用」で、保証レベルへの割当てに必要なファクタを選択します。たとえば、「Oracle Mobile Authenticator」、「電子メール・チャレンジ」および「SMSチャレンジ」を選択します
  6. 「次の条件を満たす場合」で、「属性名」、「演算子」および「値」を選択して、ルールを作成します。選択した「属性名」に基づいて、「演算子」ドロップダウンおよび「値」フィールドに対応するオプションが表示されます。たとえば、「グループ内ユーザー」を演算子「いずれかを含む」とともに選択した場合、「値」フィールドに値を指定します。「グループ内ユーザー」を演算子「グループ内」とともに選択した場合、「値」フィールドは, 「グループ」に変更され、ドロップダウンからグループ名を選択できます。
    「属性名」では次のオプションがサポートされています:
    • グループ内ユーザー
    • ユーザーのグループ
    • ユーザー・ログイン
    • ユーザー属性
    • 現在の認証レベル
    • IPアドレス
    • アプリケーションID
    • パラメータ
    • リソースURL
    • 新しい認証レベル
    • エージェント
    • IPアドレスX-Forwaded-For
  7. 「ルールの検証」をクリックします。
  8. 「保存」をクリックします。
  9. 必要に応じて、「+」アイコンをクリックして、追加のルールを作成します。

11.4 OAAでのグループの作成

統合エージェントのグループは、REST APIまたはOAA管理UIコンソールのいずれかを使用してOAAに作成できます。REST APIの使用の詳細は、グループの作成に関する項を参照してください。

次のステップでは、OAA管理UIコンソールに統合エージェントのグループを作成する手順を説明します:
  1. OAA管理コンソールhttps://<AdminUrl>にログインします。コンソールはOAM OAuthで保護されているため、OAMログイン・ページにリダイレクトされます。資格証明およびログインを指定します。
  2. 統合エージェントが最近作成された場合は、「最近のアクティビティ」の下に表示されます。ただし、統合エージェントが「最近のアクティビティ」に表示されない場合は、次のいずれかを実行します:
    • 他のエージェントも表示をクリックします
    • ページの左上にある「アプリケーション・ナビゲーション」アイコンをクリックし、統合エージェントの管理を選択します
  3. 統合エージェント・ウィンドウで、グループを作成する必要がある統合エージェントを選択します。
  4. 「グループ」タブで、「作成」をクリックします。
  5. 必要な詳細を指定します:
    1. 名前: グループの名前を指定します。
    2. 説明: グループの説明を指定します
    3. タイプ: ドロップダウンから、必要なタイプを選択します。
    4. 「作成」をクリックします。
    5. 「値」タブで、「追加」をクリックします。前のステップで選択したタイプに対応する値を追加します。詳細は次の表を参照してください。
  6. 「保存」をクリックします。

表11-1 グループのタイプ値リファレンス

タイプ 説明と値
ユーザーID

ユーザーIDに基づいてグループを作成するには、これを選択します。

値フィールドにユーザーIDを指定します。
IPアドレス

IPアドレスに基づいてグループを作成するには、これを選択します

値フィールドにIPアドレスを指定します。
IPアドレス範囲 指定したIP範囲の間にある値に基づいてグループを作成するには、これを選択します:
  1. 名前: 名前を指定します。
  2. 説明: 説明を指定します。
  3. 開始: 範囲の開始IPアドレスを指定します。
  4. 終了: 範囲の終了IPアドレスを指定します。
文字列

必要な指定値に基づいてグループを作成するには、これを選択します。

値フィールドに文字列を指定します。

11.5 OAAでのチャレンジ・ファクタへのユーザーの登録

OAAは、ユーザーを特定のチャレンジ・ファクタに登録するためのREST APIを提供します。

<OAAService>/preferences/v1 REST APIを使用して、ユーザーに必要なチャレンジ・ファクタを登録します。

<OAAService> URLの検索および認証の詳細は、「OAAランタイムAPI」を参照してください。

プリファレンスRESTエンドポイントの詳細は、「OAAランタイムのREST API」を参照してください。これらのファクタは、ユーザーがユーザー・プリファレンスUIでさらに管理できます。詳細は、「ユーザー・プリファレンスUIでのファクタの管理」を参照してください

例1: ユーザーをOracle Mobile Authenticator (OMA)に登録するサンプル・リクエスト

次のサンプル・リクエストは、groupID UserGroup1のユーザーtestuser1をOMAに登録する方法を示しています: 

curl --location -g --request POST '<OAAService>/preferences/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \
--data '{
    "userId": "testUser1",
    "groupId": "UserGroup1",
  "factorsRegistered": [            
            {
              "factorAttributes": [
                {
                  "factorAttributeValue": [
                    {
                      "value": "omasecretvalue1",
                      "name": "Device1",
                      "isEnabled": true
                    }
                  ],
                  "factorAttributeName": "omatotpsecretkey"
                }
              ],
              "factorKey": "ChallengeOMATOTP",
              "isPreferred": false,
              "isValidated": true
            }
          ]
        }'

ノート:

factorAttribueValueのvalueは、英数字のみをサポートします。

例2: ユーザーを電子メールに登録するサンプル・リクエスト

次のサンプル・リクエストは、groupID UserGroup1のユーザーtestuser1を電子メールに登録する方法を示しています: 

curl --location -g --request POST '<OAAService>/preferences/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \
--data '{
    "userId": "testUser1",
    "groupId": "UserGroup1",
  "factorsRegistered": [
            {
              "factorAttributes": [
                {
                  "factorAttributeValue": [
                    {
                      "value": "test.user@example.com",
                      "name": "Device1",
                      "isEnabled": true
                    }
                  ],
                  "factorAttributeName": "email"
                }
              ],
              "factorKey": "ChallengeEmail",
              "isPreferred": false,
              "isValidated": true
            },
ユーザーが登録されると、ユーザー・プリファレンスUIを使用してファクタを管理できます。「ユーザー・プリファレンスUIでのファクタの管理」を参照してください。

ノート:

パラメータisValidatedはデフォルトでtrueです。「ファクタ検証の構成」に従ってファクタ検証を使用する場合、isValidatedがtrueの場合、ユーザーは検証済として登録されますが、値がfalseに設定されている場合、ユーザーは未検証として登録されます。

11.6 ユーザー・プリファレンスUIでのファクタの管理

OAAでは、ファクタの管理にユーザー・プリファレンスUIを使用できます。

ブラウザを起動し、https://<SpuiURL>にアクセスして、ユーザー・プリファレンスUIにアクセスします。ユーザーは、OAMのOAuthアイデンティティ・ストアに設定されたユーザー名(testuser1など)とパスワードを使用してコンソールにログインします。

ノート:

<SpuiUrl>の検索の詳細は、「デプロイメントの詳細の出力」を参照してください。

「ユーザー・プリファレンス」ページで、登録されたファクタごとに、対応するチャレンジ・ファクタ・タイルが表示されます。たとえば、ユーザーがOracle Mobile Authenticator (OMA)および電子メール・チャレンジのファクタに登録されている場合は、「Oracle Mobile Authenticator」および「電子メール・チャレンジ」という名前の対応するタイルが表示されます。

ファクタ・タイルでは、優先認証ファクタの無効化、有効化、削除または設定を選択できます。ファクタ・タイルの「...」メニュー・ボタンをクリックし、次のいずれかのオプションを選択します:
  • 無効化: このファクタは無効化され、第2ファクタ認証時には表示されません。
  • 優先認証ファクタ: このファクタはデフォルトのチャレンジ・ファクタとして設定されており、第2ファクタ認証時に自動的に表示されます。「ユーザー・プリファレンス」UIページのデフォルトのファクタには、緑色のドットが表示されます。
  • 削除: 登録されたファクタを削除します。
  • 有効化: ファクタが無効化されている場合、このオプションを選択して有効にできます。

登録されたファクタに加えて、第2ファクタ認証用のファクタを追加することもできます。「認証ファクタの追加」をクリックし、表示されるリストから必要なファクタを選択します。ユーザーに登録されているファクタに基づいて、次のファクタの1つ、一部またはすべてが表示されます:

ファクタ 値
Oracle Mobile Authenticator

わかりやすい名前: 名前を指定します。

キー: キーはOAAによって生成されます。

QRコード: Oracle Mobile Authenticator、Google AuthenticatorまたはMicrosoft Authenticatorアプリケーションを使用して、QRコードをスキャンします。

電子メール・チャレンジ

わかりやすい名前: 名前を指定します。

電子メール: 必要な電子メールを指定します。

FIDO2チャレンジ

わかりやすい名前: 名前を指定します。

「登録」をクリックし、FIDO2デバイスのボタンを押します。キーはOAAにコピーされます。
OMAプッシュ通知チャレンジ

QRコードをスキャンするか、デバイスを手動で登録します。OMAアプリケーションで、ここに表示されるユーザーIDとPINを入力します。
セキュリティの質問チャレンジ

質問1: 回答する質問を選択します。

回答1: 質問の回答を入力します。

残りの質問と回答を繰り返します。
SMSチャレンジ

わかりやすい名前: 名前を指定します。

電話: 電話番号を指定します。

Yubico OTPチャレンジ

わかりやすい名前: 名前を指定します。

パブリックID: パブリックIDを入力します。これは、YubiKeyデバイスのYubico OTPの構成時に指定されたパブリックID (またはシリアル)と同じである必要があります。

秘密キー: 秘密キーを入力します。これは、YubiKeyデバイスのYubico OTPの構成時に生成された秘密キーと同じである必要があります。

プライベートID: プライベートIDを入力します。これは、YubiKeyデバイスのYubico OTPの構成時に生成されたプライベートIDと同じである必要があります。

モバイル・オーセンティケータ、セキュリティ質問チャレンジ、Yubikey OTPチャレンジおよびFIDO2チャレンジの構成の詳細は、次のチュートリアルを参照してください:

11.7 電子メールおよびSMS用のOracle UMSサーバーの構成

OAAでは、電子メールおよびSMSのチャレンジを提供するために、すぐに利用できるOracle UMSをサポートしています

電子メールおよびSMSのチャレンジ・ファクタを提供するためにOracle UMSをOAAと統合するには、次のサンプル・リクエストに示すように<PolicyUrl>/policy/config/property/v1 REST APIを使用します。

ノート:

この場合は、<PolicyUrl>から/oaa-policyを削除します。たとえば、https://<host>:<port>/oaa-policy/policy/config/property/v1ではなくhttps://<host>:<port>/policy/config/property/v1を使用します

PolicyUrlの検索および認証の詳細は、「OAA管理API」を参照してください。

構成プロパティREST APIの詳細は、「構成プロパティRESTエンドポイント」を参照してください。

サンプル・リクエスト

curl --location -g --request PUT '<PolicyUrl>/policy/config/property/v1' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic <Base64Encoded(<username>:<password>)>' \--data '[
                {
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientURL",
        "value": "<UMS_SERVER_URL>"          
},
{
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientName",
        "value": "<UMS_ADMIN_USER>"          
},
{
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.umsClientPass",
        "value": "<UMS_ADMIN_PASSWORD>"          
},
{        "name": "bharosa.uio.default.challenge.type.enum.ChallengeEmail.fromAddress",
        "value": "<fromAddress>"
},
{
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientURL",
        "value": "<UMS_SERVER_URL>"                
},
{
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientName",
        "value": "<UMS_ADMIN_USER>"                
},
{
        "name": "bharosa.uio.default.challenge.type.enum.ChallengeSMS.umsClientPass",
        "value": "<UMS_ADMIN_PASSWORD>"                
}
]'
説明:
  • <UMS_SERVER_URL>は、UMSサーバーURLです(例: http://ums.example.com:8001/ucs/messaging/webservice)。
  • <UMS_ADMIN_USER>は、UMSサービスのユーザー名です。
  • <UMS_ADMIN_PASSWORD>は、<ums_username>に対応するパスワードです。
  • <fromAddress>は、エンド・ユーザーがワンタイム・パスワード(OTP)を受信する電子メール・アドレスです(例: oaa@example.com)

独自の電子メールおよびSMSサーバーの実装については、「電子メールおよびSMSメッセージング・プロバイダのカスタマイズ」を参照してください。

11.8 OAAの構成プロパティ

OAAには、チャレンジ・ファクタおよびその他の設定のプロパティを構成するためのREST APIが用意されています。

<PolicyUrl>/policy/config/property/v1 REST APIを使用して、プロパティを構成します。

ノート:

この場合は、<PolicyUrl>から/oaa-policyを削除します。たとえば、https://<host>:<port>/oaa-policy/policy/config/property/v1ではなくhttps://<host>:<port>/policy/config/property/v1を使用します

PolicyUrlの検索および認証の詳細は、「OAA管理API」を参照してください。

構成プロパティRESTエンドポイントの詳細は、「構成プロパティRESTエンドポイント」を参照してください。

表11-2 OAAの構成プロパティ

プロパティ名 デフォルト値 説明
bharosa.uio.default.all.factor.challengecounter.expiryTime 1800000ミリ秒 ファクタのチャレンジ・カウンタ・ロックの有効期限。これは、最大再試行失敗数が原因でチャレンジがロックされた後、ユーザーがチャレンジを使用できない状態のままになる期間です。
bharosa.uio.default.all.factor.retry.count 10 ファクタのチャレンジの最大失敗再試行回数。この数を超えると、チャレンジはロックされます。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.appName OAA アプリケーションの名前。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.challengeText {0}に送信されたOTPを入力します。 エンドユーザーのチャレンジ・ページにワンタイムPIN (OTP)の入力を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.fromAddress oaa@oracle.com 電子メール送信エンティティの電子メール・アドレス。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.fromName OAA 送信元電子メール送信エンティティの名前。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.msgIPTemplate IPアドレス: メッセージIPアドレスを表示する電子メール・テンプレートの一部
bharosa.uio.default.challenge.type.enum.ChallengeEmail.msgPinTemplate 次のワンタイムPINを使用して、保護されたリソースにログインしてください: ワンタイムPIN (OTP)を表示する電子メール・テンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.msgResourceURLTemplate リソースURLアクセス: メッセージ・リソースURLを表示する電子メール・テンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.msgSubject ワンタイムPIN: OAA 電子メール・テンプレートの件名タイトル
bharosa.uio.default.challenge.type.enum.ChallengeEmail.challengeCounterExpiryTime 1800000ミリ秒 チャレンジ・カウンタ・ロックの有効期限。これは、最大再試行失敗数が原因でチャレンジがロックされた後、ユーザーがチャレンジを使用できない状態のままになる期間です。

値を指定しない場合、bharosa.uio.default.all.factor.challengecounter.expiryTimeの値が使用されます(デフォルトは1800000ミリ秒)

.
bharosa.uio.default.challenge.type.enum.ChallengeEmail.retrycount チャレンジの最大失敗再試行回数。この数を超えると、チャレンジはロックされます。

値を指定しない場合、bharosa.uio.default.all.factor.retry.countの値が使用されます(デフォルトは10)。

bharosa.uio.default.challenge.type.enum.ChallengeEmail.msgTimeTemplate アクセス時間: メッセージ時間を表示する電子メール・テンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.promptmessage {0}にOTPを送信します エンドユーザーのチャレンジ・ページで使用される電子メールを介してワンタイムPIN (OTP)の送信を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeEmail.promptselectmessage OTPを受信するアドレスを次の中から1つ選択してください。 エンドユーザーのチャレンジ・ページでワンタイムPIN (OTP)をユーザーに送信するアドレスの選択を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.challengeText デバイス{1}で受信したOTPを入力します エンドユーザーのチャレンジ・ページに時間ベースのワンタイムPIN (OTP)を入力するよう求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.promptselectmessage 次のチャネルのいずれかを選択してください エンドユーザーのチャレンジ・ページでユーザーに時間ベースのワンタイムPIN (OTP)を送信するチャネルの選択を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.challengeCounterExpiryTime 1800000ミリ秒 チャレンジ・カウンタ・ロックの有効期限。これは、最大再試行失敗数が原因でチャレンジがロックされた後、ユーザーがチャレンジを使用できない状態のままになる期間です。

値を指定しない場合、bharosa.uio.default.all.factor.challengecounter.expiryTimeの値が使用されます(デフォルトは1800000ミリ秒)

bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.retrycount チャレンジの最大失敗再試行回数。この数を超えると、チャレンジはロックされます。

値を指定しない場合、bharosa.uio.default.all.factor.retry.countに指定された値が使用されます(デフォルトは10)。

bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.registration.showSecretKeyText true Oracle Mobile Authenticator、Google AuthenticatorまたはMicrosoft Authenticatorで使用するために、ユーザー・プリファレンスUIに秘密キーを表示します。値がfalseに設定されている場合、秘密キーは表示されません。
bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.registration.showQrcode true Oracle Mobile Authenticator、Google AuthenticatorまたはMicrosoft Authenticatorで使用するために、ユーザー・プリファレンスUIにQRコードを表示します。値がfalseに設定されている場合、QRコードは表示されません。
bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.keyExpiryEnabled false 秘密キーの有効期限が有効であるかどうかを示すブール値。有効にすると、チャレンジ・フロー中に時間ベースのワンタイム・パスワード(TOTP)秘密キーの有効期限がチェックされます。キーの期限が切れている場合、チャレンジ・フローは失敗し、キーは削除されます。キーの期限が切れていない場合、チャレンジ・フローは通常どおり続行されます。
bharosa.uio.default.challenge.type.enum.ChallengeOMATOTP.keyExpiryTimeMinutes 60分 キーの有効期限(分)を指定します。これは正の整数にする必要があります。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.challengeCounterExpiryTime 1800000ミリ秒 チャレンジ・カウンタ・ロックの有効期限。これは、最大再試行失敗数が原因でチャレンジがロックされた後、ユーザーがチャレンジを使用できない状態のままになる期間です。

値を指定しない場合、bharosa.uio.default.all.factor.challengecounter.expiryTimeの値が使用されます(デフォルトは1800000ミリ秒)

bharosa.uio.default.challenge.type.enum.ChallengeSMS.retrycount チャレンジの最大失敗再試行回数。この数を超えると、チャレンジはロックされます。

値を指定しない場合、bharosa.uio.default.all.factor.retry.countに指定された値が使用されます(デフォルトは10)。

bharosa.uio.default.challenge.type.enum.ChallengeSMS.appName OAA アプリケーションの名前。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.challengeText {0}に送信されたOTPを入力します。 エンドユーザーのチャレンジ・ページにワンタイムPIN (OTP)の入力を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.fromAddress oaa@oracle.com SMS送信エンティティの携帯電話番号。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.fromName OAA 送信元SMS送信エンティティの名前。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.msgIPTemplate IPアドレス: メッセージIPアドレスを表示するSMSテンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.msgPinTemplate 次のワンタイムPINを使用して、保護されたリソースにログインしてください: ワンタイムPIN (OTP)を表示するSMSテンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.msgResourceURLTemplate リソースURLアクセス: メッセージ・リソースURLを表示するSMSテンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.msgSubject ワンタイムPIN: OAA SMSテンプレートの件名タイトル
bharosa.uio.default.challenge.type.enum.ChallengeSMS.msgTimeTemplate アクセス時間: メッセージ時間を表示するSMSテンプレートの一部。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.promptmessage 電話{0}にOTPを送信します エンドユーザーのチャレンジ・ページで使用されるSMSを介したワンタイムPIN (OTP)の送信を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeSMS.promptselectmessage OTPを受信する番号を次の中から1つ選択してください。 エンドユーザーのチャレンジ・ページでワンタイムPIN (OTP)をユーザーに送信するアドレスの選択を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeTOTP.promptmessage 登録済の電話で受信したOTPを入力します エンドユーザーのチャレンジ・ページで使用される時間ベースのワンタイムPIN (OTP)の送信を求めるメッセージ。
bharosa.uio.default.challenge.type.enum.ChallengeYubicoOTP.challengeCounterExpiryTime 1800000ミリ秒 チャレンジ・カウンタ・ロックの有効期限。これは、最大再試行失敗数が原因でチャレンジがロックされた後、ユーザーがチャレンジを使用できない状態のままになる期間です。

値を指定しない場合、bharosa.uio.default.all.factor.challengecounter.expiryTimeの値が使用されます(デフォルトは1800000ミリ秒)

bharosa.uio.default.challenge.type.enum.ChallengeYubicoOTP.retrycount   チャレンジの最大失敗再試行回数。この数を超えると、チャレンジはロックされます。

値を指定しない場合、bharosa.uio.default.all.factor.retry.countに指定された値が使用されます(デフォルトは10)。

bharosa.uio.default.challenge.type.enum.ChallengeFIDO2.challengeCounterExpiryTime 1800000ミリ秒 チャレンジ・カウンタ・ロックの有効期限。これは、最大再試行失敗数が原因でチャレンジがロックされた後、ユーザーがチャレンジを使用できない状態のままになる期間です。

値を指定しない場合、bharosa.uio.default.all.factor.challengecounter.expiryTimeの値が使用されます(デフォルトは1800000ミリ秒)

bharosa.uio.default.challenge.type.enum.ChallengeFIDO2.retrycount   チャレンジの最大失敗再試行回数。この数を超えると、チャレンジはロックされます。

値を指定しない場合、bharosa.uio.default.all.factor.retry.countに指定された値が使用されます(デフォルトは10)。

oracle.security.oaa.kba.challenge.number 1

チャレンジ・フロー中にユーザーが回答を求められるセキュリティ質問の数。これは、セキュリティ質問の登録時にユーザーが回答したアクティブな質問の最大数以下の値に設定する必要があります。

ノート: このプロパティは、次の行で説明されているoracle.security.oaa.kba.challenge.separatorプロパティとともに使用する必要があります。

oracle.security.oaa.kba.challenge.separator | oracle.security.oaa.kba.challenge.numberが1より大きい値に設定されている場合、生成されたチャレンジには、oracle.security.oaa.kba.challenge.separatorの値で区切られた複数のチャレンジが1つの文字列として含まれます。例: What is your name?|What is your age?|What is your birthplace?。

チャレンジへの回答がOAAサーバーに提示されると、レスポンスも同じセパレータで区切られることが予想されます。

デフォルトの値は"|"です。

いずれかの質問または回答に値"|"が含まれる可能性がある場合は、質問または回答に含まれないセパレータを使用するようにこのパラメータを変更する必要があります。

この値をオーバーライドするには、oracle.security.oaa.kba.challenge.separatorを任意の文字または文字の組合せに設定します。

ノート: セパレータを変更すると、処理中のKBA認証に影響を与える可能性があるため、この構成の更新はKBAサービスがオフラインのときに実行してください。

oaa.user.auth.question.authn.counter.enabled true このプロパティがtrueの場合、リスク・カウンタが増分されます。
oaa.user.auth.question.next.seq false このプロパティがfalseで、oaam.kba.questions.randomorderがtrue、かつoracle.security.oaa.kba.challenge.numberが1の場合、ピックリストから選択された質問はランダムになります。それ以外の場合は、ピックリストからの質問が順番にチャレンジされます。
oaam.kba.questions.randomorder false このプロパティがtrueで、oaa.user.auth.question.next.seqがfalse、かつoracle.security.oaa.kba.challenge.numberが1の場合、ピックリストから選択された質問はランダムになります。それ以外の場合は、ピックリストからの質問が順番にチャレンジされます。
bharosa.kba.questions.trim.answers.for.matching true このプロパティをtrueに設定すると、照合前に回答および一致した値が切り捨てられます。
oaa.browser.cookie.domain   OAA-OARMインストールの場合、デバイスCookieを正しく収集するには、これがOAAホスト・ドメインに設定されている必要があります。たとえば、https://oaa.example.comでOAAにアクセスできる場合は、値をoaa.example.comに設定します。
oaa.risk.integration.postauth.cp postauth

OAA保証レベルのデフォルトのリスク保証レベルを定義します。デフォルト値はpostauthで、変更することはできません。

ノート: このプロパティは、OAA-OARM統合に関連しています。

oaa.policy.assurance.level.default.action チャレンジ

OAA保証レベルに関連付けるデフォルト・アクションを定義します。

ノート: このプロパティは、OAA-OARM統合に関連しています。

profile.type.enum.<AssuranceLevelKey>.riskcheckpoint  

既存の保証レベルに関連付けられたチェックポイント。

ノート: このプロパティは、OAA-OARM統合に関連しています。

profile.type.enum.<AssuranceLevelKey>.defaultaction  

既存の保証レベルに関連付けられたデフォルト・アクション。使用可能な値は、Allow、BlockおよびChallengeです。次に例を示します: 

[
{
        "name": "profile.type.enum.ChallengeMFA.defaultaction",
        "value": "<Allow/Block/Challenge>",
        "source": "database"
 }
]

ノート: このプロパティは、OAA-OARM統合に関連しています。

rule.action.enum.<actionName>.priority  

アクションの優先度を定義します。整数値または最も高い優先度を示す文字列"max"を指定できます。次に例を示します:

[
    {
        "name": "rule.action.enum.Block.priority",
        "value": "max",
        "source": "database"
    }
]

ノート: このプロパティは、OAA-OARM統合に関連しています。

OAA管理コンソール、ユーザー・プリファレンス・コンソールおよびランタイムUIのユーザー・インタフェース(UI)をカスタマイズするプロパティを構成するには、「OAAユーザー・インタフェースのカスタマイズ」を参照してください。

ファクタ検証のプロパティを構成するには、「ファクタ検証の構成」を参照してください。

11.9 ファクタ検証の構成

OAAでは、ファクタ検証を構成できます。ファクタ検証では、ファクタが追加された後、ユーザーがユーザー・プリファレンスUIでファクタを検証できます。これにより、ユーザーはユーザー・チャレンジでファクタが使用される前に、ファクタが機能していることを確認できます。デフォルトでは、ファクタ検証は無効になっています。

トピック

次のトピックで、ファクタ検証を構成する方法について説明します:

11.9.1 検証統合エージェントの作成

ファクタ検証を有効にするには、検証統合エージェントを作成する必要があります。

統合エージェントは、REST APIまたはOAA管理UIコンソールのいずれかを使用して作成できます。REST APIを使用した統合エージェントの作成の詳細は、Oracle Advanced Authenticationでの管理用REST APIを参照してください。

検証統合エージェントを作成するには:

  1. OAA管理コンソールhttps://<AdminUrl>にログインします。コンソールはOAM OAuthで保護されているため、OAMログイン・ページにリダイレクトされます。資格証明およびログインを指定します。
  2. 「クイック・アクション」で、その他の統合エージェントの作成を選択します。
  3. 統合エージェントの作成ウィンドウで、次の指定を行います:
    1. 名前: 統合エージェントの名前を入力します(例: VerificationFlowAgent)。

      ノート:

      プロパティoaa.default.spui.pref.runtime.verification.agentIdは、デフォルトでVerificationFlowAgentに設定されます。エージェントに別の名前を指定する場合は、一致するようにプロパティを構成する必要があります。「ファクタ検証のプロパティの構成」を参照してください。
    2. 説明: 統合エージェントの説明を追加します。
    3. 統合エージェント・タイプ: デフォルトで「API」が選択されています。
    4. 「保存」をクリックします。

次のステップ: 検証統合エージェントの保証レベルの作成。

11.9.2 検証統合エージェントの保証レベルの作成

検証統合エージェントの保証レベルを作成します。

保証レベルは、REST APIまたはOAA管理UIコンソールを使用して作成できます。REST APIを使用した統合エージェントの作成の詳細は、Oracle Advanced Authenticationでの管理用REST APIを参照してください。

検証統合エージェントの保証レベルを作成するには:

  1. 「統合エージェント」ウィンドウで、保証レベルを作成する必要がある検証統合エージェントを選択します。
  2. 「保証レベル」タブで、「作成」をクリックします
  3. 必要な詳細を指定します:
    1. 名前: この保証レベルの名前を指定します(たとえば、FactorVerificationAL)。

      ノート:

      プロパティoaa.default.spui.pref.runtime.verification.assuranceLevelは、デフォルトでFactorVerificationALに設定されます。保証レベルに別の名前を指定する場合は、一致するようにプロパティを構成する必要があります。「ファクタ検証のプロパティの構成」を参照してください
    2. 説明: 保証レベルの説明を入力します。
    3. 「作成」をクリックします。
    4. 作成された保証レベルをクリックします。
    5. 「使用」で、ファクタ検証を構成するファクタを選択します。

      ノート:

      ファクタ検証は、Oracle Mobile Authenticator、電子メール・チャレンジ、Yubico OTPチャレンジおよびSMSチャレンジでのみサポートされています。
  4. 「保存」をクリックします。

次のステップ: ファクタ検証のプロパティの構成。

11.9.3 ファクタ検証のプロパティの構成

ファクタ検証を有効にするには、構成プロパティを設定する必要があります。

次の表に、ファクタ検証を有効にするために構成する必要があるOAAプロパティを示します。

表11-3 ファクタ検証プロパティ

プロパティ名 説明 デフォルト値
oaa.default.spui.pref.runtime.verification.enabled このプロパティは、ファクタ検証が有効か無効かを決定します。ファクタ検証を有効にするには、この値をtrueに設定します false
oaa.default.spui.pref.runtime.verification.agentId 検証統合エージェントの名前。デフォルトのVerificationFlowAgent以外の名前で検証エージェントを作成する場合は、このプロパティを、作成したエージェントの名前に設定する必要があります。 VerificationFlowAgent
oaa.default.spui.pref.runtime.verification.assuranceLevel 検証エージェントの保証レベルの名前。デフォルトのFactorVerificationAL以外の名前で保証レベルを作成する場合は、このプロパティを、作成した保証レベルの名前に設定する必要があります。 FactorVerificationAL
<PolicyUrl>/policy/config/property/v1 REST APIを使用して、プロパティを構成します。

ノート:

この場合は、<PolicyUrl>から/oaa-policyを削除します。たとえば、https://<host>:<port>/oaa-policy/policy/config/property/v1ではなくhttps://<host>:<port>/policy/config/property/v1を使用します

PolicyUrlの検索および認証の詳細は、「OAA管理API」を参照してください。

構成プロパティRESTエンドポイントの詳細は、「構成プロパティRESTエンドポイント」を参照してください。

次のステップ: ファクタ検証のテスト。

11.9.4 ファクタ検証のテスト

ファクタ検証をテストするには:

  1. ブラウザを起動し、https://<SpuiURL>にアクセスして、ユーザー・プリファレンスUIにアクセスします。ユーザーは、OAM OAuthアイデンティティ・ストアで設定されたユーザー名とパスワードを使用してコンソールにログインします。

    ノート:

    <SpuiUrl>の検索の詳細は、「デプロイメントの詳細の出力」を参照してください。
  2. 「認証ファクタ」で、「認証ファクタの追加」を選択し、認証ファクタを選択します。この例では、「電子メール・チャレンジ」が選択されています。
  3. 「電子メールによるセキュリティ・コードの設定」ページで、「わかりやすい名前」および「電子メール・アドレス」を入力します。ファクタ検証が有効になっている場合、「今すぐ確認」と「後で確認」の2つの新しいオプションが表示されます。

「今すぐ確認」を選択した場合は、検証コードを入力するよう求められます。この例では、検証コードは電子メール・アドレスに送信されます。電子メールの検証コードを入力し、「確認および保存」を選択します。検証が成功すると、「認証ファクタ」画面に戻り、認証ファクタが「有効」として表示されます。

「後で確認」を選択すると、「認証ファクタ」画面に戻ります。追加されたファクタは「未検証」と表示されます。

ノート:

「後で確認」を選択した場合、追加されたファクタは、検証されるまでユーザー・チャレンジに表示されません。

「後で確認」を選択すると、ファクタは「未検証」として保存されます。「認証ファクタ」画面のファクタ・ドロップダウン・メニューから「確認」を選択して検証できます。ファクタが検証されると、「有効」と表示されます。

ノート:

ファクタ検証を有効にする前に追加したファクタには、「有効」または「無効」のいずれかが表示され、検証を実行する必要はありません。

アップグレードに関する重要なノート

ファクタ検証がサポートされていない以前のリリースからアップグレードする場合、アップグレード後に、以前に登録されたすべてのユーザーのファクタが自動的に検証されます。これは、ユーザーに対して以前に有効または無効にしたすべてのファクタに当てはまります。アップグレード後にユーザー用に登録される新規ファクタでは、ファクタ検証が使用されます。

11.10 ナレッジベース認証のセキュリティの質問の構成

ナレッジベース認証(KBA)は、リアルタイムの対話型質問および回答プロセスで実証されるユーザーの回答に基づいて身元を証明するようユーザーに求める認証方法です。

KBA機能は、豊富な一連のチャレンジ質問、これらのチャレンジ質問をユーザーに提示するロジック、およびユーザーが提供できる回答を制御する検証を提供します。

KBAは第2認証機能で、第1認証(ユーザーがユーザー名とパスワードを入力するなど)が成功した後にユーザーに提示され、セキュリティを強化します。

KBAでは、次のことのためのインフラストラクチャを提供します。

  • 質問: ユーザーがチャレンジ質問を選択して回答を提供し、これが後でチャレンジに使用されます。
  • カテゴリ: システム内の質問カテゴリを管理します。
  • 登録ロジック: チャレンジ質問および回答の登録に使用されるアルゴリズム・ロジックのレベルを管理します。
  • 回答ロジック: チャレンジ・レスポンス・プロセスで正しい回答をインテリジェントに検出します。
  • 検証: 登録時にユーザーが指定した回答の検証を管理します。

この章では、KBAの背後にある主な概念について説明します。次の項目が含まれます。

11.10.1 KBA登録について

登録(登録、新しいアカウントの開設、またはリセットなどのその他のイベント)時、ユーザーは質問を選択して回答を入力するよう求められます。登録フェーズ時にユーザーに示される質問の順序は、構成可能なパラメータを使用してランダムに決められます。

登録時またはリセット時に選択されたチャレンジ質問は、チャレンジ/レスポンス・プロセスを使用したユーザーの認証に使用されます。ユーザは、リスクの高いログインの続行やトランザクションへのアクセスの前に、本人確認のために1つ以上の質問を受けます。

11.10.2 登録ロジックの構成

登録ロジックによって、チャレンジ質問および回答の登録が管理されます。

KBA機能は、登録またはリセット時にユーザーから回答を得るための質問の大きなフレームワークを提供します。KBA登録時に、ユーザーに質問セット(チャレンジ質問ライブラリのサブセット)が表示されます。ユーザーに割り当てられる質問セットは、登録ロジックで構成された設定に基づいて生成されます。この質問セットは、詐欺師がフィッシング行為で使用するために質問を収集することを防ぎます。

質問セットは複数のドロップダウン・リストに分割され、ここから質問を選択します。質問が含まれているドロップダウン・リストは「メニュー」と呼ばれます。

登録ロジックを構成するには、次のように質問セット生成の設定を指定します:
  • 登録される質問の数
  • 1メニュー当たりの質問の数
  • 1メニュー当たりのカテゴリの数

ユーザーが登録する必要がある質問の数、各メニューに表示される質問の数およびメニュー当たりのカテゴリ数を構成できます。標準の質問はカテゴリに分類されています。ユーザーは、各メニューから1つの質問を選択し、回答を入力できます。質問メニューごとに1つのみ質問を登録できます。

次の例で、登録ロジックの設定が顧客の質問セットにどのように影響するかを見てみましょう。

質問/メニュー カテゴリ/メニュー メニュー内の質問/カテゴリ
7 4 2+2+2+1

この例では、カテゴリAの2つの質問、カテゴリBの2つの質問、カテゴリCの2つの質問、カテゴリDの1つの質問を含む登録メニューになります。これは、必要に応じてラウンド・ロビン形式で続行されます。質問の数が不足しているカテゴリが存在したり、カテゴリの数が不足している場合は、質問が重複する結果となる場合があります。

たとえば、次のような質問セットを生成します。

  • 3メニュー
  • 1メニュー当たり5つの質問
  • 1メニュー当たり5つのカテゴリ

このアルゴリズムでは、15のカテゴリが使用可能な場合、15のカテゴリそれぞれから1つの質問を選択します。1カテゴリ当たりの最小質問数は、質問セットの質問の数/カテゴリの合計数と等しい必要があります。

ロケールの登録ロジックを構成する場合の前提条件

管理者は、デプロイメント中にOAA管理で構成されているサポートされる各ロケールについて、データベースに十分な質問があることを確認する必要があります。そうでない場合は、登録時に英語の質問のみが表示されます。

ロケール固有の質問の数は、「ユーザーが登録する質問数」に「1メニュー当たりの質問数」を乗算し、「1メニュー当たりのカテゴリ」を乗算した数以上である必要があります。

11.10.3 回答ロジックの構成

回答ロジックは、ユーザーが指定した回答が登録時に指定した回答と一致するかどうかを検証します。

KBAの機能である回答ロジックにより、チャレンジ質問のユーザビリティが向上します。管理者は、エンド・ユーザーが指定したチャレンジ回答が、登録時に指定した回答とどれだけ正確に一致する必要があるかを調整します。ユーザーが指定した回答が、基本的には正しいが、誤入力、スペル・ミス、省略形などのわずかな違いがある場合、成功とする必要があります。KBAの向上したユーザビリティにより、リスクの小さい状況およびセルフサービス・フローでのコール・センターによる不要な関与の必要性が軽減または排除されます。

回答ロジックは、誤った回答の許容範囲レベルを構成するためにシステムによって選択された拡張アルゴリズムで構成されます。アルゴリズムは、一般的な省略形、キーボード・ファット・フィンガリング(キーボード上の隣接したキーを間違って押すこと)および音声の3つのカテゴリに分けられます。

表11-4 回答ロジック・アルゴリズムの例

アルゴリズム 説明 理由
一般的な省略形 このアルゴリズムでは、一般的な省略形、一般的な愛称、一般的な頭文字および日付書式が処理されます。許可されている一致に関するファイルを確認します。 ファイルにMrs=Missesが含まれている場合は、いずれかの方向で一致が生成されます。
キーボード・ファット・フィンガリング このアルゴリズムでは、標準キーボードのキーの近接による回答の誤入力を処理します。 uはiのすぐ左にあるため、許可されます。
音声 このアルゴリズムでは、登録された回答と音声が類似した回答、地域によるスペルの違いおよび一般的なスペル・ミスが処理されます。 SmiithはSmithと類似しています。

回答ロジック・アルゴリズムを有効または無効にできます。チャレンジ質問に対する回答を評価するために、キーボード・ファット・フィンガリングや音声など、一部のアルゴリズムの強度を構成することもできます。

この項には次の情報が含まれます:

11.10.3.1 一般的なレスポンス・エラーの理解

この項では、最も一般的なレスポンス・エラーについて重点的に説明し、チャレンジ・レスポンス処理でシステムが正しい回答をインテリジェントに検出するために回答ロジック・アルゴリズムが使用される仕組みを示します。

省略形、音声およびキーボード・ファット・フィンガリングの例も提供しています。

この項には次の情報が含まれます:

11.10.3.1.1 省略形について

このアルゴリズムでは、一般的な省略形、一般的な愛称、一般的な頭文字および日付書式が処理されます。

一般的な省略形

このアルゴリズムは、次のペアの語句を同じものとして一致させます。OAA管理には、一般的な省略形、一般的な愛称および一般的な頭字語を網羅する事前定義された語句のペアのリストがあります。

  • Street - St.
  • Drive - Dr.
  • California - CA

一般的な愛称

Oracleには、チャレンジ・レスポンス処理で使用される最も一般的な愛称の事前定義されたリストがあります。たとえば:

  • Timothy - Tim
  • Matthew - Matt

日付書式

回答として日付が求められる質問では、ユーザーが回答を入力する必要がある書式を指定します。書式はYYYYまたはMMDDのいずれかで、両方は指定できません。ただし、経験から、ユーザーはチャレンジ・レスポンス処理時に他の書式を依然として使用します。日付書式の省略形ロジックでは、次のことを同じとみなします。

  • 0713
  • 713
  • July 13th
  • July 13
  • July 13, 1970
11.10.3.1.2 音声について

このアルゴリズムでは、登録された回答と音声が類似した回答、地域によるスペルの違いおよび一般的なスペル・ミスが処理されます。

音声アルゴリズムは、英語でのみサポートされています。

一般的なスペル・ミス

Oracleの音声回答ロジック・アルゴリズムでは、スペル・ミスが考慮されます。

  • ph - f
  • 正しい語句: elephant - スペルの誤り: elefant
11.10.3.1.3 キーボード・ファット・フィンガリングについて

このアルゴリズムでは、標準キーボードのキーの近接や文字の転置による誤入力を考慮します。標準キーボードのキーの近接による誤入力がある回答は、このアルゴリズムにより処理されます。

許可されるファット・フィンガリング文字数は、元の語句の長さおよびレベル・セットにより異なります。このアルゴリズムは、完全一致を含む文字に関連付けるスコアの割合を返します。この割合が、回答が登録済の回答と一致するために必要な最小スコアを決定します。

ファット・フィンガリング・アルゴリズムは、英語でのみサポートされています。

一般的な誤入力

  • wとeの入れ替わり
  • uとiの入れ替わり
  • tとrの入れ替わり

ファット・フィンガリングの例

正しい語句: signature - ファット・フィンガリング: signatire

11.10.3.2 回答ロジックのレベルの構成

チャレンジ質問に指定された回答の評価に使用される回答ロジックのレベル(アルゴリズムの強度)は、構成可能です。

各アルゴリズムは有効化または無効化でき、使用されるアルゴリズムに次のレベルを指定することもできます。

  • オフ: 回答ロジックは使用されません。回答は、登録時に提供された回答と正確に一致する必要があります。
  • 低: 低レベルの回答ロジックが使用されます。ユーザーから提供される回答は、登録時に提供された回答と一致するか、ほぼ一致する必要があります。
  • 中: より高いレベルの回答ロジックが使用されます。提供される回答に対して、ある程度の自由度が与えられます。たとえば、Streetに対してSt.は許容されます。
  • 高: 最も高いレベルの回答ロジックが使用されます。一致に関する制約は厳しくありません。

ノート:

設定が低いほど、回答の受入れに必要な正確性が高くなります。

たとえば、電信送金などの高リスク・トランザクションでは高い確実度(完全一致)が必要とされる一方で、機密でない個人情報にアクセスする場合には、必要とされるレスポンスの確実性はより低くなることがあります。次の例は、回答ロジック・アルゴリズムがどのように機能するかを示しています:

質問: 高校時代の好きな先生は誰でしたか。

登録済の回答: Mrs. Smith

指定された回答: Misses Smuth

ロジック・レベル: 「高」に設定されている場合、この回答は受け入れられます。

各アルゴリズムは、指定された回答が、登録された回答とどれだけ近いかを表すスコアを生成します。アルゴリズムごとに異なるしきい値スコア範囲を個別に受け入れられるようにOAA管理を構成できます。各アルゴリズムの個別のしきい値(低、中、高)は、プロパティ・ファイルで設定されます。デフォルトのしきい値を次で説明します。

省略形

値を次に示します。

  • 戻り値: 範囲0から100 (不一致または一致)
  • レベル: オンまたはオフ
  • ロジック:
    • 指定した文字列にリンクされた省略形エントリが存在する場合、スコアは100です。
    • それ以外の場合、スコアは0です。
ファット・フィンガリング

値を次に示します。

  • 戻り値: 範囲0から100
  • レベル: オフ、低(90以上)、中(75以上)、高(60以上)
  • ロジック:
    • 文字列長が一致しない場合、スコアは0です。
    • 任意の位置に予期された文字またはその隣接文字が含まれていない場合、スコアは0です。
    • それ以外の場合は、隣接文字が含まれた位置の数を計算します。
    • スコア = (文字列長 - 隣接位置数) * 100 /文字列長
音声

値を次に示します。

  • 戻り値: 0、60、75、90
  • レベル: オフ、低(90)、中(75)、高(60)
  • ロジック:
    • DoubleMetaphoneアルゴリズムを使用して、指定された文字列の主音声キーと代替音声キーを計算します。
    • 両方の文字列の主キーが一致する場合、スコアは高です。
    • いずれかの文字列の主キーが、もう一方の文字列の代替キーに一致する場合、スコアは中です。
    • 両方の文字列の代替キーが一致する場合、スコアは低です。
    • それ以外の場合、スコアは0です。

11.10.4 上位のカテゴリについて

質問は、複数のカテゴリに分類され、ユーザーはこれらのカテゴリから質問を選択できます。「トップ・カテゴリ」パネルには、カテゴリにリンクされた質問の数に基づいて上位5つのカテゴリが降順でリストされます。

質問がグループ化される標準カテゴリは次のとおりです:

  • 幼児期
  • スポーツ
  • 出生
  • 父母、祖父母、兄弟姉妹
  • 子
  • 職業
  • 大切な人
  • ペット
  • 自動車
  • 学歴
  • その他

KBA機能では、カテゴリを管理できます。カテゴリを作成、編集、削除および表示できます。質問をグループ化できる標準カテゴリが要件を満たしていない場合、作成する予定の関連質問を含めるカテゴリを作成できます。新規カテゴリの作成に関する項を参照してください。

11.10.5 上位の質問について

「上位の質問」パネルには、ユーザーおよび検証の統計に基づいて、最も使用されている5つの質問がリストされます。

顧客は、ユーザーの認証に使用される一連のチャレンジ質問を構成できます。登録時に、ユーザーは、登録ロジックで構成された設定に基づいて複数の質問メニューが表示されます。たとえば、3つの質問メニューがユーザーに表示されます。登録中、ユーザーはメニューごとに質問を1つ選択し、その回答を入力する必要があります。質問メニューごとに1つのみ質問を登録できます。これらの質問は、ユーザーの登録済質問になります。

KBA機能により、チャレンジ質問を管理できます。チャレンジ質問を作成、編集、削除、表示、エクスポートおよびインポートできます。標準のチャレンジ質問が要件を満たしていない場合は、必要に応じて質問を作成できます。必要に応じて、検証をシステムに追加することもできます。検証を使用して、登録時にユーザーが指定した回答を確認します。新規質問の作成に関する項を参照してください。

11.10.6 質問およびカテゴリ・ロジックの無効化について

KBA機能では、質問およびカテゴリを無効にできます。

この項では、無効化された質問およびカテゴリを処理するロジックについて説明します。

ロジックの無効化

KBAでは、ロジックの無効化は次のようになります。

  • カテゴリ内の最後に残った質問を無効化すると、そのカテゴリも同様に自動的に無効化されます。
  • アクティブなカテゴリの数は、質問メニューのカテゴリの最大数以上である必要があります。カテゴリを無効化しようとしたときに、この要件が満たされていない場合は、エラー・メッセージが表示されます。

結果

次の表に、無効化の結果の概要を示します。

質問またはカテゴリの無効化 新規顧客 質問セットに無効化された質問があるユーザー 質問が登録されているユーザー
質問 無効化された質問は、新規ユーザーの質問セットの再生に使用されません。 再登録時、またはユーザーが自分のプリファレンスを変更した場合、無効化された質問は同じカテゴリからの別の質問で置換されます。 無効化された質問は、引き続きアクティブです。

ユーザーがユーザー・プリファレンスを再登録または変更する場合、無効化された質問は、同じカテゴリからの別の質問で置換されます。
カテゴリ 無効化されたカテゴリは、新規ユーザーの質問セットの再生に使用されません。 再登録時、またはユーザーが自分のプリファレンスを変更した場合、無効化されたカテゴリ内のすべての質問が、現在の質問セットの生成に使用されていない新しいカテゴリからの質問で置換されます。 無効化されたカテゴリの質問は、引き続きアクティブです。

ユーザーがユーザー・プリファレンスを再登録または変更する場合、無効化されたカテゴリ内のすべての質問は、現在の質問セットの生成に使用されていない新規カテゴリからの質問で置換されます。

11.10.7 質問およびカテゴリ・ロジックの削除について

KBA機能では、質問およびカテゴリを削除できます。

この項では、削除された質問およびカテゴリを処理するロジックについて説明します。

削除ロジック

KBAの削除ロジックは次のとおりです:

  • 登録済ユーザーが使用している質問は削除できません。
  • 削除された質問は新規登録には使用できませんが、これらの質問に対して現在登録されているユーザーは、引き続きこれらの質問を使用できます。
  • 使用中の質問で参照されていない場合は、カテゴリを削除できます。

11.10.8 回答登録の検証の構成

登録時にユーザーがすべての質問に登録できる回答を制御するために使用できる検証を構成できます。

検証を使用して、登録時にユーザーが指定した回答を確認します。回答について、正規表現検証を追加することによって、ユーザーの入力を英数字およびいくつかの特定の特殊文字に制限できます。たとえば、質問「中学校入学は何年でしたか。」に月日年(MMDDYY)検証が割り当てられている場合、この質問に対するユーザー登録の回答として「April 1st 1920」を指定することはできません。

各質問に一意の検証を割り当てて、ユーザーが登録できる回答を制御できます。質問の作成または編集時、「登録検証」リストから検証タイプを選択して検証を割り当てることができます。検証をインポートおよびエクスポートすることもできます。

検証タイプについて学習するには、新規検証の作成に関する項を参照してください。