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

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

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

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

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

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

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

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

ノート:

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

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

関連項目:

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

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

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

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

  • SMSによるOTP

  • 電子メールによるOTP

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

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

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

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

図32-1の説明が続きます
「図32-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の仕組みについて説明します。

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

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

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

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

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

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

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

ノート:

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

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

32.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モバイル・アプリケーションは使用されません。

32.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はその期間内だけ有効です。

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

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

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

ノート:

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

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

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

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

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

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

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

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

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

32.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の使用について」を参照してください。

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

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

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

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

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

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

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

32.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構成の理解」を参照してください。

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

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

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

  1. 次の説明に従ってcustomAttrsを持つDefaultDomainを作成します。
    認可ヘッダー・ベーシック = 管理者ユーザー(weblogicなど)のユーザー名とパスワード
    POST /oam/services/rest/ssa/api/v1/oauthpolicyadmin/oauthidentitydomain HTTP/1.1
    <HOST>:<PORT>,

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

    Authorization: Basic d2VibG9naWM6d2VsY29tZTE= Content-Type: application/json
    {"name":"DefaultDomain","identityProvider":"UserIdentityStore1","description":"Secret Key Test Domain","tokenSettings":[{"refreshTokenEnabled":false,"refreshTokenLifeCycleEnabled":false,"refreshTokenExpiry":0,"lifeCycleEnabled":false,"tokenType":"ACCESS_TOKEN","tokenExpiry":0},{"refreshTokenEnabled":false,"refreshTokenLifeCycleEnabled":true,"refreshTokenExpiry":3600,"lifeCycleEnabled":false,"tokenType":"AUTHZ_CODE","tokenExpiry":0}],"errorPageURL":"http://<HOST>:<PORT>/oam/pages/error.jsp", "consentPageURL":"http://<HOST>:<PORT>/oam/pages/consent.jsp", "customAttrs":"{\"keyAttributeName\":\"title\"}"

    ノート:

    使用される属性Nameが他の目的のために使用されていないことを確認します
    アイデンティティ・ドメインを作成するコマンドで使用するパラメータの詳細は、「アイデンティティ・ドメインの作成」を参照してください
  2. サンプル・ユーザーを使用して、秘密キーを生成できることをテストします。
    POST /oauth2/rest/resources/secretkey HTTP/1.1
    <HOST>:<PORT>
    Authorization: Basic ZGhhcm0xOndlbGNvbWUx
    X-OAUTH-IDENTITY-DOMAIN-NAME: DefaultDomain
    Cache-Control: no-cache
    Postman-Token: e85ec697-cee1-71e9-8ba5-a106907de0c8
    Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
    Sample Response: { "secret_key": "XHPA7HBVI5KR2F73" }

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

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

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

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

    「AdaptiveAuthenticationPlugin」が表示されます。

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

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

    表32-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

    		  

    ノート:

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

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

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

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

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

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

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

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

表32-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によるアプリケーションの保護』を参照してください。

32.4.5 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

32.4.6 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を再起動します。

32.4.7 ユースケースにおける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. 「追加」→「適用」の順にクリックして、手順を完了します。