1. Oracle Access Management管理者ガイド
  2. アダプティブ認証サービスおよびOracle Mobile Authenticatorの管理
  3. アダプティブ認証サービスの概要

34 アダプティブ認証サービスの概要

アダプティブ認証サービスは、ユーザー名とパスワードによる標準的なタイプの認証に加えて、より高いセキュリティを必要とするセンシティブ・アプリケーションのために、より強力なマルチファクタ(第2ファクタとも呼ばれる)認証を提供します。

マルチファクタ認証では、サーバーから、またはネットワークでサービスへのアクセスを試行するエンティティのアイデンティティを検証する際に、複数のステージが関連します。たとえば、マルチファクタ認証が有効化および構成されている場合、従来のユーザー名とパスワードが第1ファクタです。もう1つのセキュリティを適用するには、ワンタイムPIN(OTP)ステップまたはアクセス・リクエスト(プッシュ)通知ステップを認証プロセスの第2ファクタとして追加します。

次の各トピックでは、アダプティブ認証サービスおよびAccess Manager第2ファクタ認証について説明します。

34.1 アダプティブ認証サービスについて

アダプティブ認証サービスでは、複数のステップを認証プロセスに追加できます。

もう1つのセキュリティを適用するには、OTPステップまたはアクセス・リクエスト(プッシュ)通知ステップを初回のユーザー認証後に追加します。これには、時間ベースのワンタイム・パスワードを使用し、通知をプッシュして第2ファクタ認証スキームでユーザーを認証するモバイル・デバイス・アプリケーションのOracle Mobile Authenticatorの使用を伴うことも、そうでないこともあります。

ノート:

アダプティブ認証サービスでは、Oracle Mobile Authenticatorを使用してOTPステップを実行可能にする一連のライブラリを使用するため、Oracle Adaptive Access Managerのインストールは不要です。

アダプティブ認証サービスを使用するには、そのライセンスを取得して明示的に有効にする必要があります。適切な製品ライセンスを入手したら、Oracle Access Managementコンソールを使用してアダプティブ認証サービスを有効にできます。Oracle Access Managementコンソールから、「構成」起動パッドの「使用可能なサービス」リンクをクリックして、アダプティブ認証サービスを有効または無効にできます。

関連項目:

34.2 アダプティブ認証サービスの使用

アダプティブ認証サービスは、第2ファクタ認証を提供します。第2ファクタは、ワンタイムPIN (OTP)またはアクセス・リクエスト(プッシュ)通知のいずれかになります。ユーザー/パスワードの初回認証に成功すると、「第2ファクタ認証」ページが表示され、ユーザーは第2ファクタ認証の優先メソッドを選択します。

次のオプションを使用できます。

  • Oracle Mobile AuthenticatorからのワンタイムPIN

  • SMSによるOTP

  • 電子メールによるOTP

  • Oracle Mobile Authenticatorからのアクセス・リクエスト通知

図34-1は、「電子メールによるワンタイムPIN」オプションが選択された「第2ファクタ認証」ページを示しています。

この場合、ユーザーは構成済の電子メール・アドレス経由でOTPを受信します。

図34-1 「第2ファクタ認証」優先メソッド・ページ

図34-1の説明が続きます
「図34-1 「第2ファクタ認証」の優先メソッドのページ」の説明

「Oracle Mobile AuthenticatorからのワンタイムPIN」または「Oracle Mobile Authenticatorからのアクセス・リクエスト通知」オプションを選択すると、アダプティブ認証サービスは、時間ベースのワンタイム・パスワードを使用し、通知をプッシュして第2ファクタ認証スキームでユーザーを認証するモバイル・デバイス・アプリケーションのOracle Mobile Authenticator (OMA)と連携して動作します。

「Oracle Mobile AuthenticatorからのワンタイムPIN」または「Oracle Mobile Authenticatorからのアクセス・リクエスト通知」オプションを使用する前に、ユーザーは、サポートされているオーセンティケータ・アプリケーションをモバイル・デバイスに(たとえば、Oracle Mobile AuthenticatorをApple iPhoneに)ダウンロードし、Access Manager管理者から提供されたリンクをクリックしてこれを構成する必要があります。(「電子メールによるワンタイムPIN」または「SMSによるワンタイムPIN」オプションを使用する場合、OMAアプリケーションは必要ありません。)

ノート:

Oracle Mobile Authenticatorモバイル・デバイス・アプリケーションは、OTPの生成に必要な秘密キーを取得するように構成する必要があります。

秘密キーの詳細は、「Oracle Mobile Authenticatorの秘密キーの生成」を参照してください。

OMAの構成方法の詳細は、「Oracle Mobile Authenticator構成の理解」を参照してください。

次の各トピックでは、それぞれのオプションおよびOracle Mobile Authenticatorの仕組みについて説明します。

34.2.1 ワンタイム・パスワード・オプションの理解

初期資格証明が正常に認証されると、ユーザーは第2ファクタ認証としてOTPオプションのいずれかを選択する必要があります。ユーザーが受信したOTPをOTPログイン・ページに入力すると、保護されたリソースにアクセスできるようになります。

ここでは、第2ファクタ認証に対してアダプティブ認証サービスが有効化および構成されていると想定します。Access Managerによって保護されたリソースにユーザーがアクセスすると、ユーザー名とパスワードを要求するページが表示されます。これらの初期資格証明が正常に認証されると、「第2ファクタ認証」優先メソッド・ページが表示され、ユーザーはいずれかのオプションを選択します。このユースケースでは、ユーザーはいずれかのOTPオプションを選択し、OMAアプリケーションによって生成および表示されたSMS/電子メールによるOTPを受信します。ユーザーはOTPをOTPログイン・ページに入力します。

図34-2に、OTPログイン・ページを示します。

図34-2 ワンタイム・パスワードのログイン・ページ

図34-2の説明が続きます
「図34-2 ワンタイム・パスワードのログイン・ページ」の説明

Access ManagerによるOTPの検証が成功すると、ユーザーに保護されたリソースが表示されます。いずれかのOTPオプションが失敗すると、エラー・メッセージが表示され、ユーザーは同じOTPページに戻ります。

ノート:

Access Managerは、時間ベースのワンタイム・パスワード(TOTP)アルゴリズムを使用してOTPを検証します。TOTPは、Internet Engineering Task Force (IETF)によってRFC 6238で規定された2ファクタ認証スキームであり、アダプティブ認証サービスで使用されています。TOTPは、HMACベースのワンタイム・パスワード・アルゴリズムを拡張したものであり、時間ベースの移動要素(新規パスワードを生成するたびに変更が必要な値)をサポートしています。

次の各トピックでは、ユーザーがOTPを受信する方法について説明します。

34.2.1.1 電子メールまたはSMSによるOTPの使用について

ユーザーは、電子メールまたはSMSによってOTPを受信し、OTPログイン・ページに入力します。

電子メールまたはSMSによるOTPを選択した場合、Access Managerによって、構成済の電子メール・アドレスまたは電話番号にそれぞれOTPが送信されます。次に、ユーザーが受信したOTPを入力し、Access Managerによってそれが検証されます。検証が成功すると、ユーザーに保護されたリソースが表示されます。

アダプティブ認証サービスでは、必要な電子メール・アドレスまたは電話番号が適切なフィールドに構成されていると想定しています。

「Oracle Access Managementコンソールでのアダプティブ認証プラグインの構成」を参照してください。

電子メールによるOTPまたはSMSによるOTPのオプションを使用している場合、OTPには、電子メール・アドレスにアクセスできる任意のデバイス、または指定の電話番号に関連付けられたSMSアプリケーションからそれぞれアクセスできます。

ノート:

電子メールによるOTPまたはSMSによるOTPのオプションでは、OMAモバイル・アプリケーションは使用されません。

34.2.1.2 Oracle Mobile AuthenticatorからのOTPの使用について

モバイル・デバイスでOMAアプリケーションによりOTPが生成および表示される事例では、Access Managerサーバー詳細を指定してアプリケーションを構成する必要があります。

この構成の後、ユーザーは適切な資格証明を使用してAccess Managerに対する認証を行い、Access Managerは秘密キーを返します。この秘密キーは各ユーザーに固有のものであり、Access ManagerとOMAによってのみ認識されます。この秘密キーは、OTPの生成に使用されます。

秘密キーに必要なデータを移入する方法は、「Oracle Mobile Authenticatorの秘密キーの生成」を参照してください。

Access Managerが秘密キーを使用してユーザーのOTPを生成すると、OTPはOMAにプッシュされます。ユーザーは、次にOTPをワンタイムPINのログイン・ページに入力します。Access Managerによって生成されたOTPがユーザーが入力したOTPと一致すれば、保護されたリソースへのアクセスが許可されます。入力されたOTPが一致しない場合には、アクセスは許可されません。

「Oracle Mobile AuthenticatorとOTPおよびアクセス・リクエストの使用」を参照してください。

ノート:

OMAはOTPを30分ごとにリフレッシュするため、ユーザーが入力したOTPはその期間内だけ有効です。

34.2.2 アクセス・リクエスト(プッシュ)通知オプションの理解

アクセス・リクエスト通知が、Access Managerから通知サーバーに送信され、その後ユーザーの構成済デバイスにプッシュされます。

ここでは、第2ファクタ認証に対してアダプティブ認証サービスが有効化および構成されていると想定します。Access Managerによって保護されたリソースにユーザーがアクセスすると、ユーザー名とパスワードを要求するページが表示されます。これらの初期資格証明が正常に認証されると、「第2ファクタ認証」優先メソッド・ページが表示され、ユーザーはいずれかのオプションを選択します。このユースケースでは、ユーザーは「Oracle Mobile Authenticatorからのアクセス・リクエスト通知」を選択します。

ノート:

これは、OMAと連携して動作するプッシュ通知オプションです。

「Oracle Mobile AuthenticatorとOTPおよびアクセス・リクエストの使用」を参照してください。

図34-3は、アクセス・リクエスト通知が選択された「第2ファクタ認証」の優先メソッド・ページを示しています。

図34-3 アクセス・リクエスト通知の優先メソッド・ページ

図34-3の説明が続きます
「図34-3 アクセス・リクエスト通知の優先メソッド・ページ」の説明

ユーザーが「第2ファクタ認証」優先メソッド・ページから「Oracle Mobile Authenticatorからのアクセス・リクエスト通知」をクリックすると、Access Managerは、ユーザーの構成済デバイスに応じてApple Push Notification ServerまたはGoogle Notification Serverのいずれかにアクセス・リクエスト通知を送信します。通知サーバーは、次に通知をモバイル・デバイスにプッシュし、ユーザーは承認または拒否します。成功した応答に基づいて、保護されたリソースがユーザーに表示されます。失敗すると、エラー・メッセージが表示され、ユーザーは同じOTPページに戻ります。

図34-4は、このプロセス中に表示されるアクセス・リクエスト通知メッセージを示しています。

図34-4 アクセス・リクエスト通知の待機画面

図34-4の説明が続きます
「図34-4 アクセス・リクエスト通知の待機画面」の説明

34.2.3 Oracle Mobile AuthenticatorとOTPおよびアクセス・リクエストの使用

ユーザーは、OMAアプリケーションをモバイル・デバイスにダウンロードし、アクセス・リクエスト通知を受信するように構成します。

選択したオプションに応じて、アダプティブ認証サービスは、時間ベースのワンタイム・パスワードを使用し、通知をプッシュして第2ファクタ認証スキームでユーザーを認証するモバイル・デバイス・アプリケーションのOracle Mobile Authenticator (OMA)と連携して動作する必要があります。OMAを使用してOTPまたはアクセス・リクエスト通知を受信するには、ユーザーはそれをAppleまたはAndroidモバイル・デバイスにダウンロードし、Access Manager管理者から提供されたリンクをクリックして構成します。Access ManagerおよびOMAは秘密キーを共有する必要があります。

秘密キーの詳細は、「Oracle Mobile Authenticatorの秘密キーの生成」を参照してください。

OMAの構成方法の詳細は、「Oracle Mobile Authenticator構成の理解」を参照してください。

ノート:

「電子メールによるワンタイムPIN」または「SMSによるワンタイムPIN」オプションを使用する場合、OMAアプリケーションは必要ありません。

「電子メールまたはSMSによるOTPの使用について」を参照してください。

34.3 アダプティブ認証サービスおよびOMA構成の理解

アダプティブ認証サービスを構成し、(選択したオプションによっては) OMAも構成する必要があります。

アダプティブ認証サービスを構成するには、次の手順を実行します。

34.4 アダプティブ認証サービスの構成

Access Manager、WebゲートおよびOracle HTTP Server (OHS)をすでにインストールしている場合は、アダプティブ認証サービスを構成できます。

これらの構成の一部は、アダプティブ認証サービス・オプションのいずれかに固有の構成です。

この節では、以下のトピックについて説明します。

34.4.1 Oracle Mobile Authenticatorの秘密キーの生成

秘密キーは、Access ManagerとOMAアプリケーションの間で共有される必要があります。ビジネスでは様々な方法で秘密キーが生成される可能性があるため、秘密キーが生成される手段は重要ではありません。

次のRESTfulエンドポイントは、ユーザーの秘密キーをOracle Access Managementアイデンティティ・ストアに生成する場合に使用されます。 

http://<HOST>:<PORT>/oauth2/rest/resources/secretkey HTTP/1.1

ここで、<HOST>および<PORT>は、OAMサーバーのものです。

OMAオンライン構成(Oracleの推奨の構成方法)の場合、OMAはRESTfulエンドポイントを使用してユーザーのキーをアイデンティティ・ストアに格納します。OMA手動構成またはGoogle Authenticatorの場合、ユーザーが前述のRESTfulエンドポイントを使用しても秘密キーを生成できるWebアプリケーションを管理者が設定します。秘密キーは、アイデンティティ・ストアのLDAP属性に文字列として格納され、秘密キーを生成する前に、この属性の名前をRESTfulエンドポイント構成のビジネスに渡す必要があります。

「Oracle Mobile Authenticator構成の理解」を参照してください。

34.4.2 秘密キーAPIを有効化するOAuthサービスの構成

秘密キーAPIの有効化には3つの部分があります。

最初の部分は秘密キー・エンドポイントの有効化です。2番目の部分では、OAM構成で時間ベースのワンタイム・パスワード(TOTP)を使用できるようにします。3番目の部分では、特定のユーザー・アカウントのTOTPを作成するようにOAMを設定します。

秘密キーAPIを有効化するには、次のようにします。

  1. 次の説明に従って、customAttrsを持つDefaultDomainを作成します:
    1. 次が同じLDAPを参照していることを確認します。
      • 認証モジュール。たとえば、アプリケーション・ドメインのLDAPSchemeなどです
      • AdaptiveAuthenticationModule。詳細は、「認証ポリシーの作成」参照してください
      • AdaptiveAuthenticationPlugin
      • デフォルト・ストア。たとえば、OAMコンソールの「構成」の下にある「ユーザー・アイデンティティ・ストア」などです。
    2. 次に示すように、customAttrsを持つDefaultDomainを作成します。次の例は、OIDがアイデンティティ・ストアであることを示しています。
      curl -u username:password -X POST
http://<Host>:<Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain -H 'content-type: application/json' -d
'{"name":"DefaultDomain","identityProvider":"OID","enableMultipleResourceServe
r":false,"description":" Test
Domain","tokenSettings":[{"refreshTokenEnabled":true,"refreshTokenLifeCycleEna
bled":true,"refreshTokenExpiry":5400,"lifeCycleEnabled":true,"tokenType":"ACCE
SS_TOKEN","tokenExpiry":1800},{"refreshTokenEnabled":true,"refreshTokenLifeCyc
leEnabled":true,"refreshTokenExpiry":10800,"lifeCycleEnabled":true,"tokenType"
:"AUTHZ_CODE","tokenExpiry":240}],
"customAttrs":"{\"keyAttributeName\":\"description\"}"}'
Sucessfully created entity - OAuthIdentityDomain, detail - OAuth Identity
Domain :: Name - DefaultDomain, Id - 5c75aeece3154fdc9af691e21b70b1b9,
Description - Test Domain, TrustStore Identifiers -
[DefaultDomain], Identity Provider - OID, TokenSettings -
[{"tokenType":"SSO_LINK_TOKEN","tokenExpiry":3600,"lifeCycleEnabled":false,"re
freshTokenEnabled":false,"refreshTokenExpiry":86400,"refreshTokenLifeCycleEnab
led":false},
{"tokenType":"ACCESS_TOKEN","tokenExpiry":1800,"lifeCycleEnabled":true,"refres
hTokenEnabled":true,"refreshTokenExpiry":5400,"refreshTokenLifeCycleEnabled":t
rue},
{"tokenType":"AUTHZ_CODE","tokenExpiry":240,"lifeCycleEnabled":true,"refreshTo
kenEnabled":true,"refreshTokenExpiry":10800,"refreshTokenLifeCycleEnabled":tru
e}], ConsentPageURL - /oam/pages/consent.jsp, ErrorPageURL -
/oam/pages/servererror.jsp, CustomAttrs -
{"keyAttributeName":"description"}

      ノート:

      使用される属性Nameが他の目的のために使用されていないことを確認します

      ドメインを削除するには、次のコマンドを使用します:

      curl -u username:password -X DELETE
http://<Host>:<Port>/oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain?name=DefaultDomain

      アイデンティティ・ドメインを作成するコマンドで使用するパラメータの詳細は、「アイデンティティ・ドメインの作成」を参照してください

  2. サンプル・ユーザーを使用して、秘密キーを生成できることをテストします。たとえば:

    方法1

    1. 次のHTMLファイルを作成します:
      
<html>
    <head>
        <title>Oracle Mobile Authenticator</title>
    </head>
    <body>
        <a href="oraclemobileauthenticator://settings?LoginURL::=http://<Host>:<ManagedServerPort>/oauth2/rest/resources/secretkey">
          Click Here
        </a>
    </body>
</html>
    2. OMAアプリケーションがインストールされているモバイル・デバイスで、このHTMLページを開きます。
    3. 「ここをクリック」をクリックします
    4. 保護されたリソースにアクセスするユーザーのユーザー名およびパスワードを入力します
    5. ユーザーがOMAアプリケーションに自動的に追加され、秘密キーが作成されます。これで、モバイル・デバイスのOMAアプリケーションに、OTPメッセージが表示されるようになります。

    方法2

    1. ユーザーがOIDにあるか、UseridentityStore1にあるかに関係なく、秘密キーを作成してからモバイル・デバイスのOMAアプリケーションに手動で入力します。
      curl -u username:password  -X POST http://<Host>:<Port>/oauth2/rest/resources/secretkey 
-H 'cache-control: no-cache' -H 'content-type:application/x-www-form-urlencoded' 
-H 'x-oauth-identity-domain-name:DefaultDomain' 
{"secret_key": "PTBHAITFH25W3BOD"}
    2. モバイル・デバイスでOMAアプリケーションを開きます
    3. +記号をクリックしてアカウントを追加します
    4. 「キーを手動で入力」をクリックします
    5. キーを手動で入力します。

34.4.3 Oracle Access Managementコンソールでのアダプティブ認証プラグインの構成

Access Managerには、2ファクタ認証に使用できるアダプティブ認証プラグインが用意されています。

Oracle Access Managementコンソールでアダプティブ認証プラグインを構成するには、次のようにします。

  1. システム管理者としてOracle Access Managementコンソールにログインします。
  2. 「アプリケーション・セキュリティ」起動パッドから、「プラグイン」パネルの「認証プラグイン」をクリックします。
  3. 「認証プラグイン」タブから、「プラグイン名」列の上のクイック検索ボックスにAdaptiveと入力して[Enter]を押します。

    「AdaptiveAuthenticationPlugin」が表示されます。

  4. 「プラグインの詳細: AdaptiveAuthenticationPlugin」の下に表示されたプロパティを、使用環境に応じて適宜変更します。

    表34-1では、アダプティブ認証プラグインのプロパティについて説明します。

    表34-1 アダプティブ認証プラグインのプロパティ

    プロパティ 説明 デフォルト値 このプロパティを必要とするチャレンジ・メソッド

    IdentityStoreRef

    アイデンティティ・ストア名

    Default_Store

    すべて

    TotpSecretKeyAttribute

    秘密キーが格納されるユーザー属性の名前。

    属性の説明

    OMAを使用する、時間ベースOTP

    TotpTimeWindow

    Access Managerが検証で受け入れるモバイル・デバイスによって生成されるOTPコードの数。モバイル・デバイスは30秒ごとに新しいOTPを生成するため、この値が3の場合、Access Managerは、モバイル・デバイスによって生成された現在のものを含む最後の3個のOTPを受け入れます。

    3

    OMAを使用する、時間ベースOTP

    PushAPNsProdServer

    trueに設定した場合、APNS本番サーバーが通知の送信に使用されます。

    false

    アクセス・リクエスト通知(iOS)

    PushProxyHost

    プロキシを使用して通知をサーバーに送信する場合のプロキシ・ホストの名前。

    アクセス・リクエスト通知

    PushProxyPort

    プロキシを使用して通知をサーバーに送信する場合のプロキシ・ポート。

    80

    アクセス・リクエスト通知

    PushProxyProtocol

    プロキシ・プロトコル

    https://

    アクセス・リクエスト通知

    UmsAvailable

    アダプティブ認証サービスで電子メールおよびSMSの送信にUMSが必要な場合は、trueに設定します。

    false

    SMS、電子メール

    UmsClientUrl

    UMS WebサービスのURL

    SMS、電子メール

    PhoneField

    ユーザーの電話番号が格納されるアイデンティティ・ストア内の属性

    mobile

    SMS

    EmailField

    ユーザーの電子メール・アドレスが格納されるアイデンティティ・ストア内の属性

    mail

    電子メール

    Totp_Enabled

    Email_Enabled

    Sms_Enabled

    Push_Enabled

    UIに表示されるオプションを制御します。有効になっており、ユーザーがプッシュに登録されていない、TOTPの設定が行われていない、またはIDストアに移入してある電子メール/電話がない場合、これらのオプションは表示されません。たとえば、ユーザーがTOTPおよびプッシュに登録していないが、電子メールが移入されている場合は、電子メールのオプションのみが表示されます。

    true

    ノート: プロパティは、管理者がすべてのユーザーに対して特定の機能を無効にする場合にのみ、falseに設定する必要があります。

    OTP RESTの構成オプション

    ValidateAnyPin

    trueの場合、ユーザーは、そのユーザーに対して生成されたPINがまだ有効であれば、それを送信できます。PINが有効であるのは、まだ正常に使用されておらず、期限が切れていない場合です。

    falseの場合、ユーザーは、PINの検証のために送信されるcorrelationIdに一致するPINのみを送信できます。

    false

    		  

    MaxAttempts

    ユーザーがPINを検証する際の最大試行回数。

    MaxAttemptsを超過する場合、ユーザーはリセットされる必要があります。

    値0は制限がないことを示します。

    0

    		  

    MaxPins

    単一ユーザーのために格納するPINの最大数。

    最大数に到達した後にさらにPINがリクエストされると、最も古いPINが置換されます。

    5

    		  

    VerboseOutput

    trueの場合、REST出力にエラーの詳細な情報が含まれます。

    falseの場合、REST出力にエラーの最小限の情報が含まれます。

    true

    		  

    pinExpiry

    ワンタイムPIN (OTP)の可用性。単位はミリ秒です。

    AdaptiveAuthenticationPluginのpinExpiryフィールドで、電子メール/SMS OTPコードの失効を制御します。

    300000

    SMS、電子メール

    ノート:

    表34-1に指定された(アダプティブ認証プラグインのOTP生成に関連する)プロパティに加え、それらをOAMMFAOTP定義のConfigParamsセクションに追加することで、oam-config.xmlの設定をオーバーライドできます。

    これにより、プロパティ名の接頭辞としてappを追加することで、アプリケーション固有の構成が可能になります。たとえば、"app1.ValidateAnyPin"とすることで、他のアプリケーションの構成に影響を与えることなく、特にapp1のPIN設定を指定して検証できます。

  5. 「保存」をクリックします。
  6. 「Access Manager」起動パッドで「プラグイン」の下の「認証モジュール」をクリックして、AdaptiveAuthenticationModule内の同じプロパティを適宜更新します。

    「認証モジュール」タブで、「AdaptiveAuthenticationModule」を検索します。

    表34-1には、使用可能なアダプティブ認証サービスのすべてのプロパティが示されているわけではありません。

34.4.4 マルチファクタ認証フロー中のユーザー・ロックアウトの有効化

第2ファクタ認証中に不正なPINを使用して無効なログイン試行が一定回数行われた後、ユーザーをロックできます。

無効な試行回数は、OAMコンソールのアダプティブ認証プラグインで構成されたMaxAttemptsで指定されている値に基づきます。

構成されたMaxAttemptsの回数を超えてユーザーが不正なPINを指定すると、OAMパスワード・スキーマ属性を使用してユーザー・アカウントがロックされます。

ユーザー・ロックアウトを有効にするには:

  1. oam-config.xmlファイルのAdaptiveAuthenticationPluginのセクションの下にlockoutEnabledプロパティを追加します。
    たとえば:
    
<Setting Name="28" Type="htf:map">
<Setting Name="globalUIOverride" Type="xsd:boolean">false</Setting>
 <Setting Name="instanceOverride" Type="xsd:boolean">false</Setting>
<Setting Name="value" Type="xsd:string">true</Setting>
<Setting Name="name" Type="xsd:string">LockoutEnabled</Setting>
 <Setting Name="length" Type="xsd:integer">100</Setting>
 <Setting Name="mandatory" Type="xsd:boolean">false</Setting>
 <Setting Name="type" Type="xsd:string">string</Setting>
</Setting

    oam-config.xmlファイルの編集の詳細は、「OAM構成の更新」を参照してください

  2. OAMパスワード・ポリシーを構成します:
    1. コンソールのユーザー・アイデンティティ・ストア構成で、「パスワード管理」を有効にします
    2. OAMパスワード・ポリシーの必要に応じて、その他の属性を構成します。詳細は、「「パスワード・ポリシー」構成ページへのアクセス」を参照してください
    3. 必要なスキーマがまだ環境にインポートされていない場合は、必ずそれを拡張してください: $OAM_HOME/idm/oam/server/pswdservice/ldif/OID_PWDPersonSchema.ldif
    4. 認証後にユーザーのロックに使用されるOAMスキーマ属性を評価するためのPasswordManagementPluginが認証モジュールに含まれていることを確認します。

34.4.5 第2ファクタ認証時のPIN生成の制限

そのいずれかの検証前に生成できるOTPピンの数は、OAMコンソールのアダプティブ認証プラグインのMaxSendAttemptsおよびMaxSendAttemptsLockoutEnabledプロパティの値に基づきます。生成されたピンが構成済のMaxSendAttempts以上である場合、MaxSendAttemptsLockoutEnabledがtrueに設定されていると、ユーザー・アカウントはロックされます。

LDAPストレージを使用する場合、PinGenerationCountFieldプロパティは、PIN生成カウンタを格納するために使用されるLDAP属性の名前に設定する必要があります。

アダプティブ認証プラグインに新しいパラメータを追加するには:
  1. oam-config.xmlファイルをエクスポートします。
  2. AdaptiveAuthenticationPluginの最新パラメータの索引(43など)を確認します。その後、次のエントリを追加します:
    <Setting Name="44" Type="htf:map">
                      <Setting Name="globalUIOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="instanceOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="value" Type="xsd:string">3</Setting>
                      <Setting Name="name" Type="xsd:string">MaxSendAttempts</Setting>
                      <Setting Name="length" Type="xsd:integer">100</Setting>
                      <Setting Name="mandatory" Type="xsd:boolean">false</Setting>
                      <Setting Name="type" Type="xsd:string">string</Setting>
                    </Setting>
                    <Setting Name="45" Type="htf:map">
                      <Setting Name="globalUIOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="instanceOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="value" Type="xsd:string">true</Setting>
                      <Setting Name="name" Type="xsd:string">MaxSendAttemptsLockoutEnabled</Setting>
                      <Setting Name="length" Type="xsd:integer">100</Setting>
                      <Setting Name="mandatory" Type="xsd:boolean">false</Setting>
                      <Setting Name="type" Type="xsd:string">string</Setting>
                    </Setting>
                    <Setting Name="46" Type="htf:map">
                      <Setting Name="globalUIOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="instanceOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="value" Type="xsd:string">true</Setting>
                      <Setting Name="name" Type="xsd:string">UseUdmStore</Setting>
                      <Setting Name="length" Type="xsd:integer">100</Setting>
                      <Setting Name="mandatory" Type="xsd:boolean">false</Setting>
                      <Setting Name="type" Type="xsd:string">string</Setting>
                    </Setting>                      
                    <Setting Name="47" Type="htf:map">
                      <Setting Name="globalUIOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="instanceOverride" Type="xsd:boolean">false</Setting>
                      <Setting Name="value" Type="xsd:string">description</Setting>
                      <Setting Name="name" Type="xsd:string">PinGenerationCountField</Setting>
                      <Setting Name="length" Type="xsd:integer">100</Setting>
                      <Setting Name="mandatory" Type="xsd:boolean">false</Setting>
                      <Setting Name="type" Type="xsd:string">string</Setting>
                    </Setting>
  3. oam-config.xmlファイルをインポートし、管理サーバーおよび管理対象サーバーを再起動します。

34.4.6 UMS、iOSおよびAndroidの資格証明の設定

WLSTコマンド行スクリプトを使用して、Oracle User Messaging Service (UMS)、iOS証明書またはAndroid APIキーの資格証明を設定します。

これらの資格証明は、SMS/電子メールおよびプッシュの通知を送信する過程でOAMサーバーによって使用されます。表34-2に、手順の完了に必要な情報を示します。

表34-2 アダプティブ認証サービスのサーバー側の構成

構成 情報 チャレンジ・メソッド

iOSの証明書/パスワード

https://developer.apple.com/library/mac/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/Chapters/ApplePushService.html

iOSを使用したアクセス・リクエスト(プッシュ)通知

APIキー

https://developers.google.com/web/updates/2015/03/push-notificatons-on-the-open-web?hl=en

Androidを使用したアクセス・リクエスト(プッシュ)通知

UMSの資格証明

OAMがUMS Webサービスへの接続を確立するために使用するUMSの資格証明。

電子メール/SMS

UMS、iOSおよびAndroidの資格証明を設定するには、次のようにします。

  1. cd <MW_HOME>/oracle_common/common/bin
  2. ./wlst.sh
  3. connect()
  4. プロンプトが表示されたら、WebLogicのユーザー名およびパスワードを入力します。
  5. [Enter]を押してデフォルトのURLを受け入れるか、必要に応じてホストとポートを変更して[Enter]を押します。
  6. 次の1つ以上のコマンドを実行して、デプロイメントに応じてUMSサーバー、iOSまたはAndroidの資格証明を設定します。

    ノート:

    <UMS SERVER USER NAME>、<UMS SERVER PASSWORD>、<CERTIFICATE STORE PASSWORD>および<API KEY VALUE>を環境に固有の値で置き換えます。これらのコマンドのパラメータの値は、変数としてマークされているリストされたパラメータの値以外は変更しないでください。

    • 電子メール/SMSによるOTPの場合のみ:

      createCred(map="OAM_CONFIG", key="umsKey", user="<UMS SERVER USER NAME>", 
  password="<UMS SERVER PASSWORD>")

      たとえば:

      createCred(map="OAM_CONFIG", key="umsKey", user="weblogic", 
  password="password")

    • iOSのアクセス・リクエスト(プッシュ)通知の場合のみ:

      createCred(map="OAM_CONFIG", key="pushApnsCertKey", user="apnskey", 
  password="<CERTIFICATE STORE PASSWORD>")

      たとえば:

      createCred(map="OAM_CONFIG", key="pushApnsCertKey", user="apnskey", 
  password="password")

      iOSを使用する場合は、「iOSアクセス・リクエスト(プッシュ)通知用のJavaキーストアの作成」を参照してください。

    • Androidのアクセス・リクエスト(プッシュ)通知の場合のみ:

      createCred(map="OAM_CONFIG", key="omaApiKey", user="omaApiKey", 
  password="<API KEY VALUE>")

      たとえば:

      createCred(map="OAM_CONFIG", key="omaApiKey", user="omaApiKey", 
  password="ADDGFDGDFGRTERSDFSDFSDFTYERTERTASDASDASD")
  7. キーを確認するには、Fusion Middleware Controlにログインし、「ドメイン」→「セキュリティ」→「資格証明」にナビゲートし、コマンドを使用してキー入力のOAM_CONFIGマップをチェックします。

ノート:

Fusion Middleware Controlを使用した資格証明の更新、削除または他の方法による管理の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』を参照してください。

34.4.7 iOSアクセス・リクエスト(プッシュ)通知用のJavaキーストアの作成

iOSでアクセス・リクエスト通知を使用する場合は、証明書ファイルおよびキー・ファイルを使用してJavaキーストア(JKS)を作成します。

JKSの作成後、APNsCertificate.jksという名前に変更して、Oracle Access Managementインストールの<domain>/config/fmwconfigディレクトリに格納します。JKSには、ローカルに生成されたユーザーの秘密キーおよびApple Developer CenterからダウンロードしたApple Push Notificationサービス(APNs)の証明書が含まれている必要があります。

次のサンプル・コマンドでは、証明書が生成されてインポートされます。

openssl x509 -in aps_production.cer -inform DER -out aps_production.pem 
 -outform PEM

openssl pkcs12 -nocerts -in OMAKey.p12 -out OMAKey.pem

openssl pkcs12 -export -inkey OMAKey.pem -in aps_production.pem 
 -out iOS_prod.p12

keytool -import -keystore APNsCertificate.jks -file aps_production.cer 
 -alias PushCert

keytool -importkeystore -destkeystore APNsCertificate.jks 
 -deststoretype JKS -srcstoretype PKCS12 -srckeystore iOS_prod.p12

これらのコマンドは次を想定しています。

  • aps_production.cerがApple Developer CenterからダウンロードしたAPNs証明書の名前である。

  • OMAKey.p12は、ローカルに生成されたユーザーの秘密キーである。

「UMS、iOSおよびAndroidの資格証明の設定」も参照してください。

ノート:

次のApple URLの証明書、識別子およびプロファイルのメンテナンスに関する項では、アプリケーション配信の証明書およびAPNsの関連情報が提供されます。https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/Introduction/Introduction.html

34.4.8 モバイル・デバイスでのプッシュ通知の構成

この項では、モバイル・デバイスでプッシュ通知を構成するステップを示します

34.4.8.1 Androidアクセス・リクエスト(プッシュ)通知用のホスト名検証の構成

Androidのアクセス・リクエスト通知を設定する場合は、WebLogicコンソールを使用してWebLogic管理対象サーバーのホスト名検証を更新します。

このステップは、Androidのアクセス・リクエスト通知を構成する場合にのみ必要です。これにより、ホスト名の検証にワイルドカードを使用できます。たとえば、*.googleapis.com

Androidアクセス・リクエスト(プッシュ)通知用にホスト名検証を構成するには、次のようにします。

  1. 「base_domain」→「環境のサマリー」→「サーバーのサマリー」→「oam_server1」の順に選択します。
  2. 「SSL」タブをクリックします。
  3. 「詳細」を開き、「ホスト名の検証」エントリを選択してホスト名検証を構成します。
  4. 「カスタム・ホスト名の検証」としてweblogic.security.utils.SSLWLSWildcardHostnameVerifierを入力します。
  5. 「保存」をクリックします。
  6. oam_server1を再起動します。
34.4.8.2 OTPRestUserGroupの作成およびOAMMFAOTPの変更

OTPRestUserGroupという名前のグループを作成し、このグループのユーザー・メンバーを使用中のLDAPに追加します。

  1. データベースからoam-config.xmlファイルをエクスポートします。詳細は、「OAM構成の更新」を参照してください。
  2. LDAPストアを現在のLDAPストアに変更します。つまり、oamconsoleのUser Identity Storeセクションで指定されているLDAP名と同じになるように、次の設定の値UserIdentityStore1を変更します。
    
<Setting Name="OAMMFAOTP" Type="htf:map">
...
...
  <Setting Name="UserStore" Type="xsd:string">UserIdentityStore1</Setting>
  3. oam-config.xmlをインポートします。詳細は、「OAM構成の更新」を参照してください。
  4. 管理サーバーと管理対象サーバーを再起動します。
34.4.8.3 プッシュ通知設定の確認

AdaptiveAuthenticationModuleおよびAdaptiveAuthenticationPluginでプッシュ通知設定を確認します

  1. OAMコンソールにログインして、認証モジュールのセクションに移動します。AdaptiveAuthenticationModuleを検索し、「ステップ」タブで次のパラメータを編集します:
    • SFATypesにプッシュが含まれていることを確認します。
    • Push_Enabledがtrueに設定されていることを確認します。
    • IdentityStoreRefを、作成されたIDSプロファイルの名前に設定します。

      ノート:

      これには、IDSPROFILE-を接頭辞として含める必要があります。たとえば、作成されたIDSプロファイルの名前がOUDの場合、値はIDSPROFILE-OUDと入力します。
    • OAM管理対象サーバーがGoogleサーバーにアクセスするためにプロキシ・サーバー接続を確立する必要がある場合は、PushProxyHost、PushProxyPortおよびPushProxyProtocolが正しく設定されていることを確認します。
  2. OAMコンソールで、認証プラグイン・セクションに移動します。AdaptiveAuthenticationPluginを検索し、前のステップの同じパラメータおよび値がプラグインにも反映されていることを確認します。

    ノート:

    OAMでは、認証モジュールが使用されることもあれば、プラグインが使用されることもあるため、両方に同じ値を設定すると、確実に正しい設定が使用されます。
34.4.8.4 認証ポリシーの作成

AdaptiveAuthenticationスキームに切り替える認証後ルールが構成された認証ポリシーを作成して、リソースを保護します。

アダプティブ認証スキームは、既存のLDAPSchemeの上にピギーバックする必要があります。エンド・ユーザーがユーザー名/パスワードを使用して認証を行い、その後で、認証後ルールによりAdaptiveAuthenticationSchemeへの切替えが行われます。認証スキームLDAPSchemeを使用して保護されたリソースを作成してから、AdaptiveAuthenticationSchemeに切り替える認証後ルールを定義します。たとえば、次の条件「3>2」は常に真になるため、この認証ポリシーで保護されたリソースはすべて前述の「SFA」ページを表示します。

34.4.8.5 メッセージング・サーバーとの接続

Google Cloud Messaging (GCM)に対応したGoogle Firebaseプロジェクトを作成します。

モバイル・デバイスにプッシュ通知を送信するには、OAMがGoogle Cloud Messagingサーバーに接続してGoogleに通知を配信し、その後でGoogleがモバイル・デバイスにその通知を配信します。Google Cloud Messagingでは、Google Firebaseプロジェクトの作成が必要です。Googleプロジェクトの作成方法の詳細は、次の情報を参照してください。

ノート:

Firebaseプロジェクトを作成するステップはGoogleに固有であり、今後変更される可能性があります。
  1. Google Firebaseコンソール(https://console.firebase.google.com/u/0/)にログインします。
  2. 「Add Project」ボタンをクリックし、プロジェクトの名前を指定します。この名前は、OAMでは使用しないため、任意のテキストにできます。たとえば、OMA-OAMです。
  3. ブラウザの左上部分にあるプロジェクト名の横の歯車アイコンをクリックして、プロジェクト設定に移動します。
  4. 青いバーにある「Cloud Messaging」オプションをクリックし、Sender IDとServer Keyをノートにとります(これらは後のステップで必要となります)。

    ノート:

    Googleから、しばらくの間はレガシー・サーバー・キーが機能することを示唆されます。ただし、期間の長いサーバー・キーの使用をお薦めします。
34.4.8.6 OAM資格証明ストア内でのGCM APIキーの設定

Googleプロジェクトのサーバー・キーをOAM資格証明ストア内に保存して、そのサーバー・キーを送信者IDとともに使用してGCMサーバーに接続できるようにする必要があります。

次の説明に従って、WLSTを使用して新しいキーを作成します:
  1. $MW_HOME/oracle_common/common/binディレクトリに移動し、wlst.shコマンドを実行してAdminServerに接続します。
  2. 次のコマンドを実行して、omaApiKeyという名前の新しいキーを作成します(ここで、passwordの値は、作成されたGoogleプロジェクトのサーバー・キーです)。
    createCred(map="OAM_CONFIG", key="omaApiKey", user="omaApiKey",
password="<API KEY VALUE>")

    ノート:

    omaApiKey資格証明がすでに存在する場合は、EMコンソール内からキーを編集できます。
    1. Farm_base_domain/WebLogic Domain/<domain name>に移動します
    2. 右クリックして、「セキュリティ」/「資格証明」を選択します。
    3. OAM_CONFIGキーを展開し、omaApiKeyをクリックして新しい値で編集します
34.4.8.7 Google CAファイルのOAMキーストアへのインストール

GoogleではGlobalSign認証局が使用されるため、CAルート証明書をOAM管理対象サーバーで使用する信頼キーストアにロードする必要があります。

OAMサーバーは、GCMサーバーにSSL接続を確立して、プッシュ通知を送信します。

デフォルトでは、OAMはMW_HOME/wlserver_10.3/server/lib/DemoTrust.jksキーストアを使用します。
  1. 次のコマンドを実行して、必要なルート証明書を収集します。証明書チェーンが返され、これを使用して、OAMキーストアにロードするファイルを作成できます。
    openssl s_client -connect android.googleapis.com:443 -showcerts
  2. 証明書ファイルが使用可能になったら、次のコマンドを使用して、それらのファイルをMW_HOME/wlserver_10.3/server/lib/DemoTrust.jksキーストアにロードします:
    cd MW_HOME/wlserver_10.3/server/lib
keytool -importkeystore -srckeystore trust.jks -destkeystore DemoTrust.jks
-srcstorepass <password> -deststorepassDemoTrustKeyStorePassPhrase
  3. 次のコマンドを実行して、すべての証明書が存在することを確認します
    -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase -storetype
jks'
  4. OAMサーバーを再起動して、キーストア・ファイルを再度読み込みます。

ノート:

Googleでは、CA証明書に関連するWebページを管理しています。詳細は、https://pki.google.comを参照してください。
34.4.8.8 OMAアプリケーション・プロファイルをモバイル・デバイスに配信するためのWebページの作成

デフォルトでは、OMAアプリケーションにはOAMサーバーへの接続がありません。OMAアプリケーションをOAMサーバーに接続するには、ユーザー・プロファイルを生成する必要があります。

OMAアプリケーションをOAMサーバーに接続するには、構成設定ファイルをOMAにロードします。

  1. 構成設定へのリンクが含まれるHTMLファイルを作成します。これにより、モバイル・デバイスがブラウザでWebページにアクセスできるようになり、OMAアプリケーションが自動的に起動してプロファイルが構成されます。プッシュ通知の場合、構成設定には次のパラメータを含める必要があります:
    • ServiceName - モバイル・デバイスのOMAアプリケーションに表示されるプロファイルの名前を定義します。
    • ServiceType - OTP、プッシュ通知、またはその両方を有効にするかどうかを定義します。プッシュ通知の場合、タイプは「通知」にする必要があります
    • PushPreferencesEndpoint - モバイル・デバイス識別情報を保存する場合など、プッシュ通知プリファレンスを送信する必要がある場所。
    • ChallengeAnswerEndpoint - ユーザーによる許可/拒否アクションをリレーする場合など、プッシュ通知レスポンスを送信する必要がある場所。
    • SenderID - 作成されたGoogle Firebaseプロジェクトから取得した送信者ID。送信者IDはサーバー・キーとは異なることに注意してください。送信者IDはこの構成ファイルで使用されますが、サーバー・キーは資格証明ストアにomaApiKeyとして設定されます。
    • NotificationAuthServerType - サポートされる値はHTTPBasicAuthenticationのみです
    
<html>
  <head>
    <title>OMA Configuration</title>
  </head>
  <body>
    <a href="oraclemobileauthenticator://settings?ServiceName
::=Google-OMA-Push&ServiceType::=Notification&PushPreferencesEndpoint
::=http://hostname:14100/oam/services/rest/11.1.2.0.0/oma/Preferences&ChallengeAnswerEndpoint
::=http://hostname:14100/oam/services/rest/11.1.2.0.0/oma/ChallengeResponse&NotificationAuthServerType
::=HTTPBasicAuthentication&SenderID::=xxxx">Google OMA Push</a>
  </body>
</html>
  2. このHTMLファイルを、モバイル・デバイスにアクセス可能なWebサーバーに配置します

    ノート:

    通常、このURLはOAMで保護されません。これはユーザーが第2ファクタ認証で使用するために各自のデバイスを登録する場合に必要な登録リンクなので、ユーザーはSFAが設定される前に、このデバイスにアクセスできる必要があります。リソースをWebGateで保護することはできますが、その場合は、ユーザーが各自のアカウントに対してSFAをまだ構成していないため、AdaptiveAuthenticationSchemeを使用しない認証スキームを選択してください。
  3. OMAアプリケーションをモバイル・デバイスにインストールします

    プッシュ通知が表示されるデバイスに、Oracle Mobile Authenticatorアプリケーションがインストールされている必要があります。OMAアプリケーションは、Google PlayストアとApple App Storeの両方で、無料アプリケーションとして入手できます。

  4. OMAアプリケーション内にユーザー・アカウントを登録します
    ユーザーは、モバイル・デバイスでブラウザを開き、指定されたOMA構成設定Webページにアクセスする必要があります。これはOMAの構成設定(oraclemobileauthenticator://settingsで指定)であるため、OMAアプリケーションを開いて、OAMログイン用のLDAP資格証明を指定するようエンド・ユーザーに要求する必要があります。OAMによって資格証明が検証されると、管理対象サーバーのOMAでOMAアプリケーション・プロファイルが作成されます。

    ノート:

    モバイル・デバイスで、「設定」→「サウンドと通知」→「アプリ通知」→OMAの選択に移動します。優先として扱うオプションをオンにします。
34.4.8.9 プッシュ通知によるSFAのテスト

保護されたリソースにアクセスしてプッシュ通知フローをテストし、ステップアップ認証スキームを使用して必要なSFAのタイプを選択します。

ユーザーは、使用しているモバイル・デバイスの名前を確認する必要があります。

アクセス・リクエスト通知オプションを選択すると、OAMサーバーでプッシュ通知が生成され、GCMサーバーに配信されます。それがユーザーのモバイル・デバイスに表示され、ユーザーはアクセスを許可または拒否するよう求められます。

デフォルトでは、OAMサーバーはユーザーの応答を8秒間隔で確認します。ブラウザは、タイムアウト期間が経過してブラウザにエラー・メッセージが表示されるか、ユーザーの応答が検出されてブラウザが適切にリダイレクトされるまで待機している間、短く点滅します。

34.4.8.10 プッシュ通知のトラブルシューティング

この項では、プッシュ通知のトラブルシューティングについて、様々なエラー、修正および回避策を示します

ロギングの有効化

この構成は、OAMサーバー、Googleサーバーおよびモバイル・デバイス間の通信に依存するため、様々な面で問題が発生する可能性があります。

問題をデバッグするには、次のログ・モジュールをOAM管理対象サーバーで有効にし、詳細な出力を取得する必要があります。

oracle.oam.plugin - TRACE:32
oracle.oam.admin.service.config - TRACE:32

ノート:

OAMとGCM間のメッセージ・ログは、TRACE: 32でのみ記録されます。

401未認可エラー

次のコマンドの実行時に401未認可エラーが発生した場合:
curl -u username:password -X POST
http://<Host>:<Port>/oam/services/rest/auth/api/v1/mfa/createOTP -H 'content-type: application/json' -d
'{"userId":"user1","appName":"asasas","deliveryChannel":"none"}'
{"correlationId":"1ad7b4bd-4ac9-4960-9da8-a28cc2c8f856","resultCode":"0",
"validTime":"1544092972705","minorCode":"6571511656"}

ディレクトリ・サーバーがシステム・ストアとして使用されているか(デフォルトでは、UserIdentityStore1で使用されるWebLogic Server組込みディレクトリ)、グループOTPRestUserGroupが作成されているか、およびこのグループにuser1が追加されているかどうかを確認します。

モバイル・デバイスでプッシュ通知が受信されない

次のことを確認します:
  • モバイル・デバイスがVPNソフトウェアに接続されていないことを確認します。
  • OMAアプリケーションが長期間にわたりOMAサーバーに接続できない状態になっているかどうかを確認します。
  • LDAPユーザー・アカウントが1回かぎりのパスワードとプッシュ通知の両方に使用されているかどうかを確認します。

以前は機能していたプッシュ通知が機能しなくなった

OMAアプリケーション・プロファイルを削除し、OMAアプリケーションからユーザーを再度登録します。

既存のプロファイルを削除するには、プロファイル名を長押しして、強調表示されたら、ごみ箱オプションをクリックします。

ノート:

これは、プッシュ通知が過去に機能していた場合にのみ有効です。デバイスでプッシュ通知を正常に受信したことがない場合、再登録しても問題は解消されないので、OAM診断ログを確認する必要があります。
次の点に注意してください

LDAPディレクトリでユーザーが見つからない

モバイル・デバイスの登録時に、ユーザーはログインするための資格証明の入力を求められます。ユーザーが見つからない場合は、OAM診断ログに次のエラーが表示されます:


<Error> <oracle.oam.user.identity.provider>
<OAMSSA-20142> <Authentication Failure for user user1, user not found in
idstore UserIdentityStore1 with exception
oracle.igf.ids.EntityNotFoundException: Entity not found for the search
filter (&(objectclass=person)(uid=usr1)).>

リストされたIDストアがUserIdentityStore1であることに注意してください。デフォルトでは、OAMは組込みWebLogic LDAPでユーザーを検索します。エラーにUserIdentityStore1が表示された場合は、「OTPRestUserGroupの作成およびOAMMFAOTPの変更」のステップを確認してください。リストされたIDストアがカスタム・ストアである場合は、生成されたldapsearchをチェックして、ユーザーが見つからない理由を確認します。デバイスでプッシュ通知を受信したら、エンド・ユーザーはログイン・リクエストの許可または拒否を選択する必要があります。

ユーザーが許可オプションを選択すると、OMAアプリケーションが確認画面を表示すると同時にOAM管理対象サーバーと通信して、ユーザーがアクセスを許可したことを伝えます

OAMサーバーがログインの承認を受信すると、リクエストされたURLにリダイレクトします。

34.4.9 ユースケースにおけるVPN用のAccess Managerの構成

ユーザーが保護されたリソースにVPNソフトウェアを使用してアクセスする必要がある場合に、Access Managerを構成できます。

ユースケースでVPN用にAccess Managerを構成するには、次のようにします。

  1. システム管理者としてOracle Access Managementコンソールにログインします。
  2. 「アプリケーション・セキュリティ」起動パッドから、「Access Manager」パネルの「アプリケーション・ドメイン」をクリックします。

    「アプリケーション・ドメイン」タブが表示されます。

  3. 「検索」をクリックして、すべての使用可能なアプリケーション・ドメインを表示します。
  4. 保護するリソースが含まれるアプリケーション・ドメイン名をクリックします。

    新しいタブに「アプリケーション・ドメイン」が開きます。

  5. 「アプリケーション・ドメイン」タブで、「認証ポリシー」をクリックします。
  6. 2ファクタ認証を構成する特定のリソースの保護に使用する認証ポリシーの名前をクリックします。

    新しいタブに、該当する認証ポリシーが開きます。

  7. 「認証ポリシー」タブで、「拡張ルール」をクリックします。
  8. ポスト認証の下にあるプラス記号(+)をクリックして、新しいルールを追加します。

    「ルールの追加」ダイアログが表示されます。

  9. ルール名および次のjythonスクリプトを入力します。

    location.clientIP.startswith('10.')

    「拡張ルールのコンテキスト・データ」を参照してください。

  10. 「条件がtrueの場合」ドロップダウン・リストから、「AdaptiveAuthenticationScheme」認証スキームを選択します。

    定義された条件がtrueの場合、この認証スキームが使用されます。

  11. 「追加」→「適用」の順にクリックして、手順を完了します。

34.4.10 シークレット・キーの管理

シークレット・キー・ライフサイクルの有効化

デフォルトでは、OAMでは、ユーザー名とパスワードをベーシック認可ヘッダーとともに使用してOAuthシークレット・キーを作成できるのみです。シークレット・キー・ライフサイクル機能を有効にすることで、BEARER認可ヘッダーとともにアクセス・トークンを使用してシークレット・キーを管理できます。これを行うには、ONLINEモードでupdateConfigProperty WLSTコマンドを使用します。

この機能を有効にする構文は、次のとおりです:
updateConfigProperty(propertyIdentifier="EnableSecretKeyLifecycle",propertyValue="true")
この機能を無効にする構文は、次のとおりです:
updateConfigProperty(propertyIdentifier="EnableSecretKeyLifecycle",propertyValue="false")

シークレット・キーの作成

シークレット・キーを作成するには、次のREST APIを使用します:
curl -X POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/resources/secretkey -H 'Content-Type: application/x-www-form-urlencoded' -H'x-oauth-identity-domain-name: <OAuthIdentityDomain>' -H 'Authorization:Bearer <AccessToken>'

シークレット・キーの取得

シークレット・キーを取得するには、次のREST APIを使用します:
curl -X GET http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/resources/secretkey -H 'Content-Type: application/x-www-form-urlencoded' -H'x-oauth-identity-domain-name: <OAuthIdentityDomain>' -H 'Authorization:Bearer <AccessToken>'

シークレット・キーの更新

シークレット・キーを更新するには、次のREST APIを使用します:
curl -X PUT http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/resources/secretkey -H 'Content-Type: application/x-www-form-urlencoded' -H 'x-oauth-identity-domain-name: <OAuthIdentityDomain>' -H 'Authorization:Bearer <AccessToken>'

シークレット・キーの削除

シークレット・キーを削除するには、次のREST APIを使用します:
curl -X DELETE http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/resources/secretkey -H 'Content-Type: application/x-www-form-urlencoded' -H 'x-oauth-identity-domain-name: <OAuthIdentityDomain>' -H 'Authorization:Bearer <AccessToken>'

ベーシック認証を使用したシークレット・キーの作成

ベーシック認証を使用してシークレット・キーを作成するには、次のREST APIを使用します:
curl -X POST http://<ManagedServerHost>:<ManagedServerPort>/oauth2/rest/resources/secretkey -H 'Content-Type: application/x-www-form-urlencoded' -H 'authorization:Basic <Base64EncodedUsernamePassword>' -H 'x-oauth-identity-domain-name:<OAuthIdentityDomain>'