| Oracle® Fusion Middleware Oracle Adaptive Access Manager開発者ガイド 11gリリース2(11.1.2) B71697-01 |
|
 前 |
 次 |
Oracle Adaptive Access Managerをアプリケーションとネイティブ統合することで、高パフォーマンスなカスタマイズ性の高いセキュリティを実現できます。ネイティブ統合では、保護されるアプリケーションのプロセス内にOAAMが組み込まれます。アプリケーションでは、Oracle Adaptive Access Manager APIを直接起動して、リスクとチャレンジのフローにアクセスします。
この章では、サーバーが公開しているAPIを使用してOracle Adaptive Access Managerをクライアント・アプリケーションに統合する際のガイドラインを示しています。OAAM APIの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager Java APIリファレンス』を参照してください。
統合オプションについては、次の各項で説明します。
Java API統合を説明しているサンプル・アプリケーションを参照用として使用できます。My Oracle Supportの記事ID1351899.1「OAAM 11g PS1(11.1.1.5)サンプル・アプリケーションのダウンロード」から、このサンプル・アプリケーションをダウンロードしてください。
My Oracle Supportにはhttps://support.oracle.comからアクセスできます。
|
注意: このサンプル・アプリケーションはJava API統合について説明したものであり、My Oracle Support記事ID1501759.1「タスク・プロセッサ統合用のOAAM 11gR2(11.1.2.0)サンプル・アプリケーションのダウンロード」で入手できるサンプル・アプリケーションとは異なります。Java API統合またはタスク・プロセッサ統合を示すサンプル・アプリケーションのいずれかを使用してください。これら2つのサンプル・アプリケーションは一緒にデプロイできません。 タスク・プロセッサ統合については、第21章「カスタム・アプリケーションの構築」を参照してください。 |
Oracle Adaptive Access Managerによって提供されるAPIで、デバイスのフィンガープリント処理、認証およびトランザクション・ログの収集、セキュリティ・ルールの実行、事前登録済の質問に対する正しい回答をユーザーに求めるチャレンジ、ワンタイム・パスワードの指定をユーザーに求めるチャレンジ、仮想認証デバイス(KeyPad、TextPad、またはQuestionPad)の生成を行えます。
OAAMネイティブ統合では、ログイン・プロセスの様々な段階でOAAM APIコールを組み込むようにアプリケーションをカスタマイズします。ネイティブ統合では、アプリケーションからOracle Adaptive Access Managerが直接起動されますが、認証およびチャレンジのフローはアプリケーションによって管理されます。
図2-1に、OAAM .NETおよびJava APIを使用したOAAMサーバーとクライアント・アプリケーションとの統合を示します。
ネイティブAPIのオプションは、次のとおりです。
このシナリオでは、アプリケーションは、OAAMネイティブ・クライアントAPI(SOAPサービス・ラッパーAPI)またはWebサービスを使用してOracle Adaptive Access Managerと通信します。
図2-2に示すように、クライアント・アプリケーションは配布済ルール・エンジンにSOAPコールを行います。
SOAPサービス・ラッパーAPIでは、SOAPオブジェクトを作成してSOAPコールを起動したり、SOAPのWeb Service Definition Language(WSDL)やその他のWebサービス詳細をアプリケーション・コードから抽象化できます。このAPIのライブラリは、Java、.NETおよびC++で提供されています。
この統合では、クライアント・ライブラリへの軽量クライアント・ライブラリ(JARまたはDLLファイル)の追加が必要になります。
このシナリオで関与するのはローカルAPIコールのみであるため、リモート・サーバーのリスク・エンジン・コール(SOAPコール)は関係ありません。
この統合では、アプリケーションにOracle Adaptive Access Managerの処理エンジンが埋め込まれるため、図2-3に示すように、基礎となるデータベースを処理に直接活用することが可能になります。このシナリオでは、アプリケーションにサーバーのJARファイルと構成されたプロパティを適宜含める必要があります。
ルール・エンジンと通信する場合、すべてのJARファイルをアプリケーション・サーバーにローカルで静的に組み込むかどうか、配布済ルール・エンジン(通常は、ルールを管理するホスト上にあります)に対してSOAPコールを行うかどうかを決定する必要があります。
SOAPコールを直接行うのではなく、SOAPサーバー・ラッパーAPIを使用することをお薦めします。この理由は、次のとおりです。
SOAPオブジェクトはクライアント・ライブラリによって構成されているため、SOAPコールに関連する詳細はクライアント・アプリケーションから抽象化されます。
SOAP APIのシグネチャを変更しても、クライアント・コードへの変更は生じません。
このAPIでは、HTTPリクエストおよびHTTPセッション・オブジェクトからパラメータを直接抽出するための、より高いレベルのユーティリティ・メソッドが提供されています。
フィンガープリント・データをエンコードおよびデコードするメソッドが提供されています。
In-Procのパフォーマンスが若干優れているとしても、これがすべてのJavaクライアントに適しているとはかぎりません。Oracle Adaptive Access ManagerがJ2EEまたはアプリケーションに組み込まれた独自のアプリケーションをクライアント側で開発する場合は、In-Procの使用をお薦めします。
In-Proc統合には、次のような利点があります。
アプリケーションではSOAPコールを行わないため、TCP/IP接続を作成したり削除する必要がなくなります。
ネットワークの待機時間が生じません。
ロード・バランサを必要としません。
クライアント・アプリケーションへのOAAMクライアントのJARファイルまたはDLLファイルの組込みを望まない場合、SOAPサービスの直接的な使用をお薦めします。ただし、Adaptive Strong Authenticator機能、ネイティブJavaまたは.NETを使用するには、ネイティブJavaまたは.NET統合を使用する必要があります。
OAAM SOAPサービスは、次の5つの主要モジュールで構成されています。
サンプル・アプリケーションは、参照用としてドキュメントの形式で提供されています。独自のアプリケーションにAPIを統合する前に、サンプル・アプリケーションをダウンロードしてください。サンプル・アプリケーションは、OAAM APIのコール方法を示しています。このサンプル・アプリケーションは、本番コードでの使用を目的としたものではありません。たとえば、サンプル・アプリケーションには適切なエラー処理機能がありません。APIの基本的な要素のみを使用しています。ネイティブ統合を実装するカスタマは、サンプル・アプリケーションを参照用として使用し、独自のアプリケーションを開発する必要があります。
|
注意: これらのデプロイメント用に開発されたカスタム・アプリケーションは、直接的にはサポートされていません。ただし、Oracleサポート・サービスでは、提供されているAPIで発生した問題の解決など、この製品に関する問題に対応しています。 |
この項では、ネイティブSOAPベースのOAAMサンプル・アプリケーションの設定方法について説明します。
SOAPベースのOAAMサンプル・アプリケーションを設定する前に、次の処理を行う必要があります。
Oracle Adaptive Access Managerをインストール、設定および実行する
Oracle Adaptive Access ManagerのSOAPサービスを有効にして、サンプル・アプリケーションのデプロイ先のホストからアクセス可能にする
Oracle Adaptive Access Managerが使用するデータベース・ホスト、ユーザー名およびパスワードの詳細を入手する
SOAPベースのOAAMサンプル・アプリケーションを設定するには、次の手順を実行します。
oaam_sampleフォルダを作成します。
oaam_sample_soap.zipファイルをoaam_sampleフォルダに抽出します。
customer application deployment/WEB-INF/classesディレクトリで、oaam_custom.propertiesファイルを次のように編集します。
vcrypt.tracker.soap.urlプロパティを設定します。
vcrypt.tracker.soap.url=http://host-name:port/oaam_server/services
この設定によって、アプリケーションが通信するWebサービスの場所が指定されます。
SOAPクラスvcrypt.common.util.vcryptsoap.impl.classnameプロパティを設定します。
この設定によって、OAAMサービスと交換するSOAPメッセージを作成するときにアプリケーションがどのライブラリを使用するかが指定されます。
使用可能なオプションは、次のとおりです。
com.bharosa.vcrypt.common.impl.VCryptSOAPGenericImpl
bharosa.image.dirlistを、OAAMイメージが格納されている絶対フォルダ・パスに設定します。
プロパティ・エディタを使用して、次のプロパティを設定します。
vcrypt.tracker.impl.classname=com.bharosa.vcrypt.tracker.impl.VCryptTrackerSOAPImpl vcrypt.user.image.dirlist.property.name=bharosa.image.dirlist bharosa.config.impl.classname=com.bharosa.common.util.BharosaConfigPropsImpl bharosa.config.load.impl.classname=com.bharosa.common.util.BharosaConfigLoadPropsImpl vcrypt.tracker.soap.useSOAPServer=true vcrypt.soap.disable=false vcrypt.soap.auth.keystoreFile=system_soap.keystore
SOAP認証が有効になっていない場合は、次のプロパティを設定します。
vcrypt.soap.auth=false
SOAP認証が有効になっている場合は、次のプロパティを設定します。
vcrypt.soap.auth=true vcrypt.soap.auth.keystorePassword=Java-keystore-password vcrypt.soap.auth.aliasPassword=Keystore-alias-password vcrypt.soap.auth.username=SOAP-User-name
OAAM管理コンソールを使用したプロパティの設定方法は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。
OAAMサーバーが実行されているのと同じWebLogic Serverドメイン上にサンプル・アプリケーションをデプロイする場合は、暗号化鍵関連のbharosa.cipher.encryption.algorithm.enumというプロパティをコメント・アウトしてください。
Oracle WebLogic Server以外またはIdentity Access Management WebLogic Server以外のドメインにデプロイする場合は、system_db.keystoreおよびsystem_config.keystoreの各キーストアを作成して、次のプロパティの値を設定する必要があります。
bharosa.cipher.encryption.algorithm.enum.DESede_config.keystorePassword bharosa.cipher.encryption.algorithm.enum.DESede_config.aliasPassword
oaam_custom.propertiesファイルの変更がピックアップされるようにサンプル・アプリケーションを更新します。Oracle WebLogic管理コンソールに移動して、「デプロイメント」→「デプロイメントのサマリー」を選択します。「次へ」をクリックしてサンプル・アプリケーションを表示し、「更新」ボタンをクリックします。「終了」をクリックします。
管理対象サーバーを起動します。
OAAM SOAPサービスへのアクセスが許可されるようにOAAM Webサービスのセキュリティを変更します。デフォルトでは、Oracle Web Services Manager(OWSM)によって保護されています。手順は次のとおりです。
URL(http://weblogic-admin-hostname:port/em)、およびWebLogic管理者のユーザー名とパスワードを使用して、Identity ManagementドメインのOracle Enterprise Manager Fusion Middleware Controlにログインします。
左ペインで「WebLogicドメイン」およびその下にあるOAAMドメインを開いて、oaam_server_server1を見つけます。
oaam_server_server1を右クリックして、「Webサービス」メニュー・オプションを選択します。
「ポリシーのアタッチ」をクリックします。
次ページでOAAM Webサービスに関連する行をすべて選択し、「次へ」ボタンをクリックします。
SOAP認証を有効にするには、行oracle/wss_http_token_service_policyを選択して「次へ」ボタンをクリックします。
SOAP認証を無効にするには、行oracle/no_authentication_service_policyおよびoracle/no_authorization_service_policyを選択して、「次へ」ボタンをクリックします。
次のページで「アタッチ」ボタンをクリックします。
必要に応じて、OAAMサーバーを再起動します。
Oracle WebLogic管理コンソールに移動します。「ロックして編集」をクリックして「デプロイメント」ノードを選択します。「デプロイメントのサマリー」ページで、サンプル・アプリケーションを検索して選択します。「起動」→「すべてのリクエストを処理」をクリックします。「はい」をクリックして確認します。
OAAM Adminアプリケーションにログインし、Oracle Adaptive Access Manager管理コンソールを使用してOAAMスナップショットoaam_base_snapshot.zipファイルをシステムにインポートします。スナップショットには、Oracle Adaptive Access Managerによって必要とされるポリシー、チャレンジ質問、依存コンポーネントおよび構成が含まれています。
OAAMスナップショットのインポートの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。
Sample_Transaction_Defs.zipファイルからトランザクション定義をインポートします。
Sample_Txn_Models.zipファイルからトランザクション・ポリシーをインポートします。
URL(http://host-name:port/oaam_sample)に移動します。サンプル・アプリケーションのログイン・ページが表示されます。
ユーザー名を入力し、次ページにパスワードを入力します。登録プロセスを経た後で、サンプル・トランザクションへのリンクが表示されます。
|
注意: 最初のログイン時のパスワードは |
この項では、ネイティブIn-ProcベースのOAAMサンプル・アプリケーションの設定方法について説明します。
ネイティブIn-ProcベースのOAAMサンプル・アプリケーションを設定するには、事前に次の処理を行っておく必要があります。
OAAM Adminをインストール、構成および実行する
Oracle Adaptive Access ManagerのSOAPサービスを有効にして、サンプル・アプリケーションのデプロイ先のホストからアクセス可能にする
Oracle Adaptive Access Managerが使用するデータベース・ホスト、ユーザー名およびパスワードの詳細を入手する
ネイティブIn-ProcベースのOAAMサンプル・アプリケーションを設定するには、次の手順を実行します。
oaam_sampleフォルダを作成します。
oaam_sample_inproc.zipファイルをoaam_sampleフォルダに抽出します。
Oracle WebLogic Serverを起動します。
次の場所のOracle WebLogic管理コンソールに移動します。
http://oaam_host:port/console
OAAM共有ライブラリ$MW_HOME\Oracle_IDM1\oaam\oaam_libs\war\oaam_native_lib.warを共有ライブラリとしてデプロイします。
「制御」タブの「デプロイメントのサマリー」にあるIAMDomain(左側のペイン)で、「デプロイメント」をクリックします。
「インストール」ボタンをクリックします。このパスで$MW_HOME\Oracle_IDM1\oaam\oaam_libs\warを指定し、oaam_native_lib.warを選択します。「次へ」をクリックします。
「このデプロイメントをライブラリとしてインストールする」オプションを選択します。「次へ」をクリックします。
「デプロイ・ターゲットの選択」ページで、サーバーのリストから管理対象サーバーを選択し、「次へ」をクリックします。共有ライブラリの名前はoracle.oaam.libsです。
管理対象サーバーがOAAMサーバーの場合、OAAMデータソースを作成する必要はありません。そうでない場合は、jdbc/OAAM_SERVER_DB_DSというJNDI名でデータソースを作成して、OAAMスキーマの接続詳細を指定します。
「終了」をクリックします。
OAAM共有ライブラリのデプロイ先である管理対象サーバーに、サンプル・アプリケーションをアプリケーションとしてデプロイします。
「制御」タブの「デプロイメントのサマリー」にあるIAMDomain(左側のペイン)で、「デプロイメント」をクリックします。
「インストール」ボタンをクリックします。パスで、サンプル・アプリケーションの場所を指定します。「次へ」をクリックします。
「このデプロイメントをアプリケーションとしてインストールする」オプションを選択します。「次へ」をクリックします。
「デプロイ・ターゲットの選択」ページで、サーバーのリストから管理対象サーバーを選択し、「次へ」をクリックします。
「終了」をクリックします。
「チェンジ・センター」の「変更のアクティブ化」をクリックします。
デプロイメント・ディスクリプタ・ファイルで、OAAM共有ライブラリoracle.oaam.libsへの参照を設定します。
Oracle Adaptive Access Managerの共有ライブラリをWebアプリケーションで使用するには、WebLogicデプロイメント記述子ファイルweblogic.xmlに次のエントリを追加して、その共有ライブラリを参照する必要があります。
<library-ref>
<library-name>oracle.oaam.libs</library-name>
</library-ref>
Oracle Adaptive Access Managerの共有ライブラリをエンタープライズ・アプリケーションで使用するには、WebLogicデプロイメント記述子ファイルweblogic-application.xmlに次のエントリを追加して、その共有ライブラリを参照する必要があります。
<library-ref>
<library-name>oracle.oaam.libs</library-name>
</library-ref>
管理対象サーバーを起動します。
Oracle WebLogic管理コンソールに移動します。「ロックして編集」をクリックして「デプロイメント」ノードを選択します。「デプロイメントのサマリー」ページで、サンプル・アプリケーションを検索して選択します。「起動」→「すべてのリクエストを処理」をクリックします。「はい」をクリックして確認します。
OAAM Adminアプリケーションにログインし、Oracle Adaptive Access Manager管理コンソールを使用してOAAMスナップショットoaam_base_snapshot.zipファイルをシステムにインポートします。スナップショットには、Oracle Adaptive Access Managerによって必要とされるポリシー、チャレンジ質問、依存コンポーネントおよび構成が含まれています。
OAAMスナップショットのインポートの詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』を参照してください。
Sample_Transaction_Defs.zipファイルからトランザクション定義をインポートします。
Sample_Txn_Models.zipファイルからトランザクション・ポリシーをインポートします。
URL(http://managed_server:port/oaam_sample)に移動します。サンプル・アプリケーションのログイン・ページが表示されます。
次のページで、ユーザー名とパスワードを入力します。登録プロセスを経た後で、サンプル・トランザクションへのリンクが表示されます。
|
注意: 最初のログイン時のパスワードは |
認証フローは、セキュリティ制約に従ってリソースへのアクセスを要求する個人または他のエンティティのIDを検証するために使用されるプロセスです。マルチファクタ認証とは、様々なファクタを同時に使用して個人または他のエンティティを認証するシステムです。
次の統合フローの例では、仮想認証デバイス、ナレッジ・ベース認証およびワンタイム・パスワードが統合されています。
仮想認証デバイスは、認証資格証明の入力と送信のプロセスにおいて、エンド・ユーザー情報の保護に使用されるオーセンティケータ・インタフェースで、エンド・ユーザーは、有効なアプリケーションに対して認証していることを確認できます。OAAMには、非常にセキュアな仮想認証デバイス一式が、ユーザーの選択に応じてデプロイできるサンプルとして組み込まれています。これらのサンプルの変更は、カスタム開発と見なされます。デプロイメントでローカライゼーションがサポートされている場合は、デプロイメント・チームが、グローバル化された仮想認証デバイスのイメージ・ファイルを登録フローを含めて開発する必要があります。
ナレッジベース認証(KBA)は、登録済チャレンジ質問に基づいてインフラストラクチャを提供するセカンダリ認証方式です。これにより、エンドユーザーは質問を選択し、後でチャレンジされるときに必要な回答を提供することができます。セキュリティ管理には、次のものがあります。
チャレンジ質問および回答の登録を管理する登録ロジック
チャレンジのレスポンス・プロセスで適切な回答をインテリジェントに検出する回答ロジック
登録時にユーザーから提供された回答の検証
詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』の「ナレッジ・ベース認証の管理」を参照してください。
ワンタイム・パスワードはリスク・ベースのチャレンジ・ソリューションであり、構成済のアウト・オブ・バンド・チャネルを経由してエンドユーザーに送信されるサーバー生成のワンタイム・パスワードから構成されます。 サポートされているOTPデリバリ・チャネルには、ショート・メッセージ・サービス(SMS)、電子メールおよびインスタント・メッセージがあります。OTPは、KBAチャレンジを補完するために使用することも、KBAのかわりに使用することもできます。
詳細は、『Oracle Fusion Middleware Oracle Adaptive Access Manager管理者ガイド』のOTP Anywhereの設定に関する項を参照してください。
図2-4では、3つのソリューション(仮想認証デバイス、KBAおよびOTP)を使用した認証フローの例を説明しています。ここに示すフローは例であり、他の認証フローも考えられます。
チェックポイントとルーの詳細は、以降の各項で説明します。
アプリケーションでカスタム・ログイン・ページを使用する場合は、ログイン・ページを2つのページに分割する必要があります。ユーザー名の送信を要求するページが表示されます。ユーザーがこの最初のページにログインID(ユーザー名)を入力すると、このユーザー名がHTTPセッションに格納されます。ユーザー名ページに続いて、フラッシュCookieとセキュアCookieを取得し、ユーザー・デバイスのフィンガープリントを処理するための一時ページが表示されます。図2-5に、ユーザー名ページの例を示します。
デバイスのフィンガープリント処理では、ブラウザ・タイプ、ブラウザ・ヘッダー、オペレーティング・システム・タイプ、ロケールなどのデバイスに関する情報が収集されます。フィンガープリント・データは、デバイスについてログイン・プロセス中に収集される、ログインに使用したデバイスの識別に必要なデータを表します。フィンガープリント処理プロセスでは、ユーザー固有のフィンガープリントが生成されます。フィンガープリント詳細は、デバイスの識別、それがセキュアであるかどうかの確認、および認証またはトランザクションのリスク・レベルの特定に役立ちます。表2-1に、デバイスのフィンガープリント処理に使われるAPIを示します。
表2-1 デバイスのフィンガープリント処理API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
フィンガープリントを作成するAPIは、次のとおりです。
|
updateLog()の詳細は、第4.5.33項「updateLog」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
Oracle Adaptive Access Managerのサンプル |
|
Oracle Adaptive Access Managerでは、2つのタイプのCookieを使用してデバイス識別を実行します。
1つはブラウザCookie(セキュアなCookieとも呼ばれます)であり、もう1つはFlash Cookie(デジタルCookieとも呼ばれます)です。
ブラウザCookie値は、ブラウザのユーザー・エージェント文字列を使用して作成されます。Flash Cookie値は、OAAMのFlash動画データを使用して作成されます。
次のサンプル・コードは、ブラウザCookieとフラッシュCookieを使用したデバイスのフィンガープリント処理方法を示しています。詳細は、handleFlash.jspのコードを参照してください。
//Get Browse/Secure cookie
String secureCookie = getCookie(request, "bharosa");
Locale locale = request.getLocale();
String browserFp = VCryptServletUtil.getBrowserFingerPrint(request.getHeader("user-agent"),
locale.getLanguage(),
locale.getCountry(), locale.getVariant());
String client = request.getParameter("client");
String fpStr = request.getParameter("fp");
String flashFp = bharosaHelper.constructFlashFingerPrint( client, fpStr );
//Get the flash cookie
String flashCookie = request.getParameter("v");
CookieSet cookieSet = bharosaHelper.fingerPrintFlash(bharosaSession, bharosaSession.getRemoteIPAddr(), request.getRemoteHost(),
BharosaEnumAuthStatus.PENDING, secureCookie, browserFp, flashCookie, flashFp);
また、認証前ルールはユーザーが認証される前に実行されます。認証前チェックポイントによって返される共通の値は、次のとおりです。
ALLOW: ユーザーに続行を許可します。
BLOCK: ユーザーを続行からブロックします。
表2-2に、認証前に使用するAPIを示します。
表2-2 認証前ルールの参照API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.25項「processRules」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
Authentipadチェックポイントによって、使用する仮想認証デバイスが判別されます。ユーザーがイメージまたはフレーズを登録していない場合は、Generic TextPadがルールによって割り当てられます。ユーザーが登録している場合は、パーソナライズされたTextPadまたはKeyPadのいずれかがルールによって割り当てられます。仮想認証デバイスによって返される共通の値は、次のとおりです。
Generic TextPad: デフォルトの一般的なTextPadを使用します。
TextPad: パーソナライズされたTextPadを使用します。
KeyPad: パーソナライズされたKeyPadを使用します。
パーソナライズされたTextpadは、キーボードを使用してパスワードまたはPINを入力するためのデバイスです。このデータ入力方法は、フィッシングからの防御に役立ちます。TextPadは、大規模デプロイメントのすべてのユーザーに対してデフォルトとしてデプロイできます。その後、各ユーザーは必要に応じて別のデバイスにアップグレードできます。ユーザーが登録した個人イメージおよびフレーズは、ユーザーが有効なWebサイトにログインするたびに表示され、ユーザーとサーバーとの間の共有シークレットとして機能します。
Keypadは、入力用のキーボードを使用してパスワード、クレジットカード番号などを入力するためのデバイスです。KeyPadによって、トロイの木馬やキーロギングからの保護が提供されます。
表2-3に、仮想認証デバイスのルールを実行するAPIを示します。
表2-3 仮想認証デバイスのルールのAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.25項「processRules」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
ユーザーがイメージおよびフレームをまだOAAMに登録していない場合は、図2-6に示すように、一般的な、パーソナライズされていないTextPadが表示されます。
このデバイスには特定のイメージまたはフレーズはありませんが、ログイン・プロンプトの正当性の証明に役立つタイムスタンプが表示されます。
表2-4に、一般的なTextPadの生成に使用するAPIを示します。
表2-4 Generic TextPad APIの生成
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.5.19項「getUserByLoginId」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
||
|
クライアント |
ユーザーがフレーズとイメージをOAAMに登録している場合は、ユーザーに対してパーソナライズされたTextPadが使用されます。図2-7および図2-8では、パーソナライズされたテキストおよび生成される重要な仮想認証デバイスを説明しています。
表2-5に、パーソナライズされたTextPadまたはKeyPadの生成に使用するAPIを示します。
表2-5 パーソナライズされたTextPadまたはKeyPadのAPIの生成
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.19項「getUserByLoginId」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
||
|
クライアント |
TextPadおよびKeyPadを表示するHTMLコードの例を、パスワード・ページに埋め込む必要があります。このHTMLではJavaScriptを使用してTextPadまたはKeyPadがレンダリングされます。また、TextPadまたはKeyPadイメージを取得するための、サーバーへのHTTPリクエストを実行する<img>タグが含まれています。
表2-6に、TextPadおよびKeyPadの表示に使用するAPIを示します。
表2-6 TextPadおよびKeyPad APIの表示
図2-7に、パーソナライズされたTextPadを示します。
図2-8に、パーソナライズされたKeyPadを示します。
イメージとフレーズが、ユーザーのローカル・タイムゾーンにおける現在のタイムスタンプとともにデバイスに埋め込まれています。
この段階では、ユーザーが指定したデータが、選択した仮想認証デバイスによってデコードされます。デコードされた値はRAWテキスト・フォーマットで出力されます。デコードされた値は、HTTPセッションに保存しておくことをお薦めします。仮想認証デバイスのオブジェクトはシリアライズされ、データベースまたはファイルシステムに格納されます。仮想認証デバイスは入力のデコードに使用されるため、セッション中に格納されます。これは、PinPadやKeyPadのように、ユーザー入力がクリアテキストではない仮想認証デバイスで必要とされます。整合性を確保するために、この処理はすべての仮想認証デバイスで実行されます。仮想認証デバイスは、相互に交換できるように設計されているからです。
表2-7に、ユーザー入力のデコードに使用するAPIを示します。
この段階は、クライアントがローカルAPIを起動してユーザーを認証し、認証結果がOAAMサーバーに渡されるという、クライアントの既存のプロセスを表しています。使用するAPIについては、表2-8で詳述します。
ユーザーのパスワード検証後に、表2-9に説明するAPIを使用してステータスが更新されます。
表2-9 認証ステータス更新のAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.32項「updateAuthStatus」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
これらのルールは、ユーザー・パスワードの認証後に実行されます。認証後によって返される共通のアクションは、次のとおりです。
ALLOW
BLOCK
CHALLENGE
認証後の結果がALLOWの場合、ユーザーを登録する必要があるかどうかが判別され、ユーザーが登録フローに送られます。認証後の結果がBLOCKの場合、ユーザーはブロックされ、アクセスを試みたWebアプリケーションにアクセスできなくなります。認証後の結果がCHALLENGEであり、ユーザーが1つ以上のチャレンジ・メカニズムにすでに登録されている場合、ユーザーはチャレンジ・フローに送られます。
認証後に使用されるAPIを表2-10に示します。
表2-10 認証後ルールの参照API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.25項「processRules」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
次の値を返す
|
|
|
BharosaHelper |
ビジネスおよびセキュリティ要件によって、登録が必須か、または任意であるかが指定されます。登録ルールによって返される値は、次のとおりです。
Register: ユーザー登録を必要とします。
Registration Optional: ユーザー登録は任意です。
Skip Registration: このセッションの登録をスキップします。
表2-11に、登録ルールの実行に使用されるAPIを示します。
表2-11 登録必須ルールの参照API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.25項「processRules」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
登録とは、アカウントを新規に開く場合など、ユーザーに情報を求めるイベントからなる登録プロセスのことです。登録フローにより、ユーザーは質問、イメージ、フレーズおよびOTP(電子メール、電話など)の登録を許可されます。登録が成功すると、KBAとOTPをセカンダリ認証ファクタとして使用してユーザーにチャレンジできるようになります。
表2-12では、登録フローのモジュールとAPIについて説明しています。
表2-12 登録フロー
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.25項「processRules」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
|
|
|
|
|
|
|
|
BharosaHelper |
|
チャレンジ・ルールは、ユーザーに表示するチャレンジのタイプを判別するために起動されます。チャレンジ・ルールによって返される値は、次のとおりです。
ChallengeQuestion: ユーザーに質問でチャレンジします。
ChallengeSMS: ユーザーにSMSを通してOTPでチャレンジします。
ChallengeEmail: ユーザーに電子メールを通してOTPでチャレンジします。
BLOCK: ユーザーをブロックします。
表2-13に、チャレンジ・ルールの実行に使用されるAPIを示します。
表2-13 チャレンジ・ルール実行のAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
メソッドの詳細は、第4.5.25項「processRules」を参照してください。 |
|
|
Oracle Adaptive Access Managerのサンプル |
このメソッドが |
|
|
BharosaHelper |
BharosaHelper::getAuthentiPadは、認証デバイスの作成に使用します。このメソッドは認証デバイスのルールをコールして、使用するデバイスを判別します。
ユーザーが質問でチャレンジされる場合、このルールはQuestionPadを割り当てます。ユーザーがOTPでチャレンジされる場合、このルールはTextPadを割り当てます。
ユーザーは、必要に応じて、ナレッジ・ベース認証(KBA)またはOTP(ワンタイム・パスワード)のいずれかでチャレンジされます。
KBAは既存のユーザーID/パスワード認証の拡張であり、ユーザーが質問でチャレンジされるチャレンジ/レスポンス・プロセスを使用してアプリケーションのセキュリティを保証します。ユーザーは、リクエストしたサインオン、トランザクション、サービスなどの処理を続行するためには、質問に正しく回答する必要があります。
OTPも既存のユーザーID/パスワード認証の拡張であり、特別のセキュリティ・レイヤーを追加してアプリケーションを保護します。OTPはユーザーIDとパスワードの検証後に生成され、アプリケーションで必要と見なされた場合に電子メールまたは携帯電話を通してユーザーに配布されます。その後、ユーザーはこのOTPを使用してアプリケーションにサインインします。
表2-14に、登録済の質問でユーザーにチャレンジするAPIを示します。
表2-14 ユーザーにチャレンジするAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
|
|
Oracle Adaptive Access Managerのサンプル |
使用するチャレンジのタイプを判別します。 返されたチャレンジ・タイプがKBA( チャレンジ・タイプがOTP(
認証パッド・ルールを使用して、ユーザーに表示するauthentipadを判別します。第2.1.11項「仮想認証デバイスのルールの実行(r3)」を参照してください。 回答を
|
|
|
BharosaHelper |
|
|
|
クライアント |
この段階では、チャレンジに対するユーザーの入力を検証します。
表2-15に、チャレンジの検証に使用されるAPIを示します。
表2-15 チャレンジに対する回答の検証
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.5.25項「processRules」および第4.5.32項「updateAuthStatus」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
このメソッドが |
|
|
BharosaHelper |
検証中のチャレンジのタイプがKBA( 検証中のチャレンジのタイプがOTP( メソッドによって、 |
