| Oracle® Fusion MiddlewareOracle Adaptive Access Manager開発者ガイド 11gリリース2 (11.1.2.3.0) E67356-01 |
|
 前 |
 次 |
| Oracle® Fusion MiddlewareOracle Adaptive Access Manager開発者ガイド 11gリリース2 (11.1.2.3.0) E67356-01 |
|
前 |
次 |
Oracle Adaptive Access Managerをアプリケーションとネイティブ統合することで、高パフォーマンスなカスタマイズ性の高いセキュリティを実現できます。ネイティブIn-Proc統合では、保護されるアプリケーション内に、プロセス内のOAAMが組み込まれます。アプリケーションでは、Oracle Adaptive Access Manager APIを直接起動して、リスクとチャレンジのフローにアクセスします。SOAP統合では、OAAM SOAPクライアント・ライブラリ(SOAP APIを起動するJava/.Netラッパー)を含めて、デバイスのフィンガープリント処理、リスク評価およびKBA関連アクティビティ用にOAAMサーバーと通信する必要があります。
この章では、サーバーが公開しているAPIを使用してOracle Adaptive Access Managerをクライアント・アプリケーションに統合する際のガイドラインを示しています。この開発者ガイドの他に、Javadocツールによって生成されるAPIドキュメントが使用可能です。このドキュメントは、HTMLとして提供され、Oracle Adaptive Access Manager Java APIリファレンスとして、HTML形式でIdentity Managementドキュメンテーション・ライブラリからダウンロードすることもできます。
この章では、次の内容を説明します。
Oracle Adaptive Access Managerによって提供されるAPIで、デバイスのフィンガープリント処理、認証およびトランザクション・ログの収集、セキュリティ・ルールの実行、事前登録済の質問に対する正しい回答をユーザーに求めるチャレンジ、ワンタイム・パスワードの指定をユーザーに求めるチャレンジ、仮想認証デバイス(KeyPad、TextPad、またはQuestionPad)の生成を行えます。
OAAMネイティブ統合では、ログイン・プロセスの様々な段階でOAAM APIコールを組み込むようにクライアント・アプリケーションをカスタマイズします。ネイティブ統合では、クライアント・アプリケーションからOracle Adaptive Access Managerが直接起動されますが、認証およびチャレンジのフローはアプリケーションによって管理されます。
ネイティブAPIのオプションは、次のとおりです。
Javaまたは.NETアプリケーションのSOAPサービス・ラッパーAPI
Javaアプリケーション専用のIn-Proc(静的リンク・ライブラリ)
図2-1に、SOAPサービス・ラッパーAPI統合のシナリオを示します。このシナリオでは、アプリケーションはOAAMネイティブ・クライアントAPI (SOAPサービス・ラッパーAPI)を使用してOracle Adaptive Access Managerと通信します。アプリケーションはまた、Webサービスを介してOAAMと通信することもできます。
SOAPサービス・ラッパーAPIでは、SOAPオブジェクトを作成してSOAPコールを起動したり、SOAPのWeb Service Definition Language (WSDL)やその他のWebサービス詳細をアプリケーション・コードから抽象化できます。このAPIのライブラリは、Java、.NETおよびC++で提供されています。この統合では、クライアント・ライブラリへの軽量クライアント・ライブラリ(JARまたはDLLファイル)の追加が必要になります。
図2-2に、In-Proc統合のシナリオを示します。このシナリオで関与するのはローカルAPIコールのみであるため、リモート・サーバーのリスク・エンジン・コール(SOAPコール)はありません。
この統合では、アプリケーションにOracle Adaptive Access Managerの処理エンジンが埋め込まれるため、基礎となるデータベースを処理に直接活用することが可能になります。このシナリオでは、アプリケーションにサーバーのJARファイルと構成されたプロパティを適宜含める必要があります。
|
注意: In-Proc統合は、OAAMが存在するWebLogicコンテナ上でのみ機能します。 |
ルール・エンジンと通信する場合、すべての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サービスの直接的な使用をお薦めします。ただし、適応厳密認証機能を使用するには、ネイティブJavaまたは.NET統合を使用する必要があります。
OAAM SOAPサービスは、次の5つの主要モジュールで構成されています。
VCryptCommonには、共通APIが含まれています。
VCryptTrackerには、認証ログとトランザクション・ログのフィンガープリント処理および収集に対応するAPIが含まれています。
VCryptAuthには、オーセンティケータおよびKBAモジュールへのアクセスに対応するAPIが含まれています。
VCryptRulesEngineには、ルールの実行に対応するAPIが含まれています。
VCryptCCには、カスタマ・ケア関連のリクエストの起動に対応するAPIが含まれています。
この項では、OAAMサンプル・アプリケーションの設定方法について説明します。OAAMサンプル・アプリケーションは、ユーザーがOAAM APIおよびフローに慣れることを目的としたデモンストレーション用アプリケーションです。これは、API使用方法の基本的な要素のみを提供しているため、本番コードとしての使用を対象としていません。ネイティブ統合を実装している場合は、OAAMサンプル・アプリケーションを参照として使用して、アプリケーションを開発できます。
これらのデプロイメント用に開発されたカスタム・アプリケーションに対する直接サポートはありませんが、Oracleサポート・サービスでは、製品に関する問題、たとえば提供されているAPIの使用時に発生した問題などの解決を支援できます。
API統合を示す11.1.2.x OAAMサンプル・アプリケーションは、My Oracle SupportのドキュメントID 1542025.1からダウンロードできます。
|
注意: このOAAMサンプル・アプリケーションは、タスク・プロセッサ・フレームワーク用のものとは異なります。どちらかのOAAMサンプル・アプリケーションを使用してください。ただし、一緒にはデプロイできません。タスク・プロセッサの統合の詳細は、第21章「タスク・プロセッサの統合」を参照してください。 |
ネイティブ統合に似た高度な要件があり、かつ、直接的なJava API統合ではなくSOAP Webサービスを使用することが必要な場合は、このオプションを選択できます。
ネイティブSOAP統合オプションでは、OAAM SOAPクライアント・ライブラリ(SOAP APIを起動するJava/.Netラッパー)を含めて、デバイスのフィンガープリント処理、リスク評価およびKBA関連アクティビティ用にOAAMサーバーと通信する必要があります。
この項では、OAAMサンプル・アプリケーションの設定方法について説明します。
次に、SOAPベースのネイティブ統合に関する重要な注意事項をいくつか示します。
OAAMサーバー(管理対象サーバーのデフォルト名: oaam_server_server1およびEnterprise Application oaam_server.ear)は、SOAPベース統合のWebサービスを公開します。
公開されるWebサービスのWSDLは、http://OAAM_Server_Host:Port/oaam_server/services?wsdlにあります
OAAMはネイティブ統合用のOAAMクライアント・ライブラリを提供するため、同じクライアント・ライブラリを使用して、Webサービスを直接使用することは回避する(OAAMで提供されるクライアント・ライブラリを使用しない)ことをお薦めします。
OAAM共有ライブラリが使用されていない場合は、oaam_soap_client.jarファイルとbharosa_propertiesフォルダをIAM_ORACLE_HOME/oaam/oaam_libs/jar/oaam_soap_client.jarおよびIAM_ORACLE_HOME/oaam/oaam_libs/war/oaam_native_lib.war/WEB-INF/classes/bharosa_propertiesの使用可能ファイルで置換することをお薦めします。
OAAMサーバー側で認可を構成する場合は(Webサービスの公開)、第4.4項「OAAM SOAP統合の実行」を参照してください。
oaam_custom.propertiesの構成可能プロパティにすべての変更を含めます。デフォルトでは、多くのプロパティはoaam_custom.propertiesですでに設定されており、一部のプロパティは統合およびデプロイメント・シナリオに基づいて変更または削除する必要があります。
プリファレンスに基づいて、更新されたプロパティおよびライブラリ・ファイルを含め、EARまたはWARを準備する必要があります。
OAAMサンプル・アプリケーションを設定する前に、次の処理を行う必要があります。
Oracle Adaptive Access Managerのインストール、設定および実行
Oracle Adaptive Access ManagerのSOAPサービスを有効にして、OAAMサンプル・アプリケーションのデプロイ先のホストからアクセス可能にする
Oracle Adaptive Access Managerが使用するデータベース・ホスト、ユーザー名およびパスワードの詳細
Java API統合を示す最新OAAMサンプル・アプリケーションは、My Oracle Supportからダウンロードできます。
最新のwebserviceclient+ssl.jarファイル。
webserviceclient+ssl.jarというランタイムJARファイルには、SSLのランタイム実装が含まれています。サンプル・アプリケーションをWebLogicコンテナにデプロイしない場合は、Oracle WebLogic Serverインストールからこのファイルを取得して、自分のクライアント・アプリケーション開発コンピュータにコピーします。
OAAMサンプル・アプリケーションを設定するには、次の手順を実行します。
oaam_sampleディレクトリを作成します。
OAAMサンプル・ファイルをoaam_sampleディレクトリに抽出します。
customer application deployment/WEB-INF/classesディレクトリで、oaam_custom.propertiesファイルを次のように編集します。
同じOAAMクライアント・ライブラリは、SOAPまたはIn-Proc統合に使用できます。OAAMクライアント・ライブラリでSOAPベースの統合を使用する場合は、oaam_custom.propertiesで次のプロパティを設定します。
vcrypt.tracker.soap.useSOAPServer=true vcrypt.soap.disable=false vcrypt.tracker.impl.classname=com.bharosa.vcrypt.tracker.impl.VCryptTrackerSOAPImpl vcrypt.tracker.soap.url=http://hostname:port/oaam_server/services
vcrypt.tracker.soap.url設定によって、アプリケーションが通信するWebサービスの場所が指定されます。
OAAM SOAPクライアントがWebLogicベースのSOAP実装を使用するように次のプロパティを設定します。
vcrypt.common.util.vcryptsoap.impl.classname=com.bharosa.vcrypt.common.impl.VCryptSOAPGenericImpl
異なるSOAP実装(たとえばAXISなど)の使用については、VCryptSOAPのカスタマイズされた実装(VCryptSOAPGenericImplなど)を準備および構成する必要があります。
OAAMクライアント・ライブラリは、データベースおよびプロパティ・ファイルから構成パラメータを読み取ることができます。ほとんどのデプロイメント・シナリオでは、OAAMサンプルはデータベースにアクセスできません。OAAMクライアントで構成可能なパラメータをプロパティ・ファイルからのみ読み取る場合は、oaam_custom.propertiesで次のプロパティを設定します。
bharosa.config.impl.classname=com.bharosa.common.util.BharosaConfigPropsImpl bharosa.config.load.impl.classname=com.bharosa.common.util.BharosaConfigLoadPropsImpl
デフォルトのSOAP実装(VCryptSOAPGenericImpl)は、BASIC (ユーザー名とパスワード)ベースのHTTP認証を使用するように設計されています。oaam_custom.propertiesで次の構成可能なプロパティを設定して、SOAP通信に対して認証が有効になるようにします。キーストア関連の詳細は、第4.4.4項「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> vcrypt.soap.auth.keystoreFile=<Keystore File name should be available from the classpath, i.e., WEB-INF/classes>
SOAP認証が有効になっていない場合は、次のプロパティを設定します。
vcrypt.soap.auth=false
OAAMは、構成可能なプロパティおよびデータベース表/列に暗号化/復号化を使用します。構成可能なプロパティは、各暗号化/復号化のアルゴリズムと実装を制御します。プロパティは、OAAMクライアントの初期化中に最初に読み取られます。
デフォルトでは、このような暗号化/復号化に必要な構成は、CSF (OAAMサーバー/管理の起動時に初期化されています)から読み取られます。OAAMサーバーが実行されているのと同じWebLogic Serverドメイン上にOAAMサンプル・アプリケーションのデプロイメントがある場合は、oaam_custom.propertiesでbharosa.cipher.encryption.algorithm.enum properties*をコメントアウトします。
OAAMサンプル・アプリケーションのデプロイメントがWebLogic Server以外またはIdentity Access Management WebLogic Server以外のドメイン上にある場合は、oaam_custom.propertiesで次のプロパティを設定します。
bharosa.cipher.encryption.algorithm.enum.DESede_config.keyRetrieval.classname=com.bharosa.common.util.cipher.KeystoreKeyRetrieval bharosa.cipher.encryption.algorithm.enum.DESede_config.keystoreFile=<Keystore File name which should be available from classpath. i.e. WEB-INF/classes> bharosa.cipher.encryption.algorithm.enum.DESede_config.keystorePassword=<Java-keystore-password> bharosa.cipher.encryption.algorithm.enum.DESede_config.aliasPassword=<Keystore-alias-password> bharosa.cipher.encryption.algorithm.enum.DESede_db.keyRetrieval.classname=com.bharosa.common.util.cipher.KeystoreKeyRetrieval bharosa.cipher.encryption.algorithm.enum.DESede_db.keystoreFile=<Keystore File name which should be available from classpath. i.e. WEB-INF/classes> bharosa.cipher.encryption.algorithm.enum.DESede_db.keystorePassword=<Java-keystore-password> bharosa.cipher.encryption.algorithm.enum.DESede_db.aliasPassword=<Keystore-alias-password>
bharosa.image.dirlistを、OAAMイメージが格納されている絶対ディレクトリ・パスに設定します。たとえば、bharosa.image.dirlist=/scratch/orafmw/r2ps2/products/access/iam/oaam/oaam_images/などです
vcrypt.user.image.dirlist.property.name=bharosa.image.dirlistを設定します。
oaam_custom.propertiesファイルの変更がピックアップされるようにOAAMサンプル・アプリケーションを更新します。Oracle WebLogic管理コンソールに移動して、「デプロイメント」→「デプロイメントのサマリー」を選択します。「次へ」をクリックしてOAAMサンプル・アプリケーションを表示し、「更新」ボタンをクリックします。「終了」をクリックします。
管理対象サーバーを起動します。
OAAM SOAPサービスへのアクセスが許可されるようにOAAM Webサービスのセキュリティを変更します。デフォルトでは、Oracle Web Services Manager (OWSM)によって保護されています。手順は次のとおりです。
Identity ManagementドメインのOracle Enterprise Manager Fusion Middleware Controlに、次のURLを使用してログインします。
http://weblogic-admin-hostname:port/em
左ペインで「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サンプル・アプリケーションを検索して選択します。「起動」→「すべてのリクエストを処理」をクリックします。「はい」をクリックして確認します。
OAAM Adminアプリケーションにログインし、Oracle Adaptive Access Manager管理コンソールを使用してOAAMスナップショットoaam_base_snapshot.zipファイルをシステムにインポートします。スナップショットには、Oracle Adaptive Access Managerが必要とするポリシー、チャレンジ質問、依存コンポーネントおよび構成が含まれています。
OAAMスナップショットのインポートの手順は、『Oracle Adaptive Access Managerの管理』を参照してください。
次のURLに移動します。
http://host-name:port/oaam_sample
OAAMサンプル・アプリケーションのログイン・ページが表示されます。
ユーザー名を入力し、次ページにパスワードを入力します。登録プロセスが行われます。
|
注意: 最初のログイン時のパスワードはtestである必要があります。このパスワードはすぐに変更してください。 |
ネイティブ統合では、保護されるアプリケーション内に、プロセス内のOAAMが組み込まれます。アプリケーションでは、OAAM APIを直接起動して、リスクとチャレンジのフローにアクセスします。この統合では、OAAMコア・ライブラリ(JARファイル)およびプロパティ・ファイルを保護されたアプリケーションに含めます。OAAMは、この統合のためにアプリケーションに埋め込まれているため、保護されたアプリケーションからのOAAMデータベース・アクセスが必要な場合があります。
この項では、OAAMサンプル・アプリケーションの設定方法について説明します。
次に、In-ProcモードでのネイティブOAAM統合に関する重要な注意事項を示します。
同じOAAMサンプル・パッケージがSOAPまたはIn-Proc統合で動作します。OAAMサンプルで特定の統合(SOAPまたはIn-Proc)を使用するようにOAAM構成可能プロパティおよびライブラリに変更を加える必要があります。
In-Proc統合では、OAAMクライアント・ライブラリはJava APIを(SOAPクライアントなしで)直接起動します。したがって、OAAMクライアントからのデータベース・アクセスが必要です(OAAMクライアントはOAAMコア・ライブラリおよびデータ・ソースにアクセスする必要があります)。WebLogicではOAAM共有ライブラリおよびデータ・ソースを使用することをお薦めします。In-Proc統合が非WebLogicコンテナで使用される場合、OAAMサンプル・デプロイメントでは永続(データベース・アクセス)レイヤーおよびOAAMコア・ライブラリに変更を含める必要があります。
OAAMクライアント・ライブラリは、データベースおよびプロパティ・ファイルから構成パラメータを読み取ることができます。In-Proc 統合では、OAAMサンプルはデータベースおよびプロパティ・ファイルにアクセスする必要があります。oaam_custom.propertiesに次のプロパティを設定しないでください。
bharosa.config.impl.classname bharosa.config.load.impl.classname
oaam_custom.propertiesの構成可能なプロパティにすべての変更を含める必要があります。デフォルトでは、多くのプロパティはoaam_custom.propertiesですでに設定され、統合およびデプロイメントのシナリオに基づいてプロパティを変更または削除する必要があります。
プリファレンスに基づいて、更新されたプロパティおよびライブラリ・ファイルを含め、EARまたはWARを準備する必要があります。
OAAMサンプル・アプリケーションを設定する前に、次の処理を行う必要があります。
OAAM Adminをインストール、構成および実行する
Oracle Adaptive Access ManagerのSOAPサービスを有効にして、OAAMサンプル・アプリケーションのデプロイ先のホストからアクセス可能にする
Oracle Adaptive Access Managerが使用するデータベース・ホスト、ユーザー名およびパスワードの詳細を入手する
Java API統合を示す最新OAAMサンプル・アプリケーションは、My Oracle Supportからダウンロードできます。
OAAMサンプル・アプリケーションを設定する手順:
oaam_sampleディレクトリを作成します。
OAAMサンプル・ファイルをoaam_sampleディレクトリに抽出します。
customer application deployment/WEB-INF/classesディレクトリで、oaam_custom.propertiesファイルを次のように編集します。
同じOAAMクライアント・ライブラリは、SOAPまたはIn-Proc統合に使用できます。OAAMクライアント・ライブラリでIn-Proc統合を使用する場合は、oaam_custom.propertiesで次のプロパティを設定する必要があります。
vcrypt.tracker.soap.useSOAPServer=false vcrypt.soap.disable=true
OAAMは、構成可能なプロパティおよび一部のデータベース表/列に暗号化/復号化を使用します。構成可能なプロパティは、各暗号化/復号化のアルゴリズムと実装を制御します。これらのプロパティは、OAAMクライアントの初期化中に最初に読み取られます。
デフォルトでは、このような暗号化/復号化に必要な構成は、CSF (OAAMサーバー/管理の起動時に初期化されています)から読み取られます。OAAMサーバーが実行されているのと同じWebLogic Serverドメイン上にOAAMサンプル・アプリケーションのデプロイメントがある場合は、oaam_custom.propertiesでbharosa.cipher.encryption.algorithm.enum*プロパティをコメントアウトします。
OAAMサンプル・アプリケーションのデプロイメントがWebLogic Server以外またはIdentity Access Management WebLogic Server以外のドメイン上にある場合は、oaam_custom.propertiesで次のプロパティを設定します。
bharosa.cipher.encryption.algorithm.enum.DESede_config.keyRetrieval.classname=com.bharosa.common.util.cipher.KeystoreKeyRetrieval bharosa.cipher.encryption.algorithm.enum.DESede_config.keystoreFile=<Keystore File name which should be available from classpath. i.e. WEB-INF/classes> bharosa.cipher.encryption.algorithm.enum.DESede_config.keystorePassword=<Java-keystore-password> bharosa.cipher.encryption.algorithm.enum.DESede_config.aliasPassword=<Keystore-alias-password> bharosa.cipher.encryption.algorithm.enum.DESede_db.keyRetrieval.classname=com.bharosa.common.util.cipher.KeystoreKeyRetrieval bharosa.cipher.encryption.algorithm.enum.DESede_db.keystoreFile=<Keystore File name which should be available from classpath. i.e. WEB-INF/classes> bharosa.cipher.encryption.algorithm.enum.DESede_db.keystorePassword=<Java-keystore-password> bharosa.cipher.encryption.algorithm.enum.DESede_db.aliasPassword=<Keystore-alias-password>
デプロイメント・ディスクリプタ・ファイルで、OAAM共有ライブラリoracle.oaam.libsへの参照を設定します。
IAM_ORACLE_HOME/oaam/oaam_libs/earまたはIAM_ORACLE_HOME/oaam/oaam_libs/warから入手できるOAAM共有ライブラリ(oaam_native_lib)には、2つのバージョン(EARおよびWAR)があります。共有ライブラリのターゲットは、OAAMサンプル・アプリケーションがアクセスできるように正しく更新する必要があります。
OAAMサンプルがWARファイルとしてパッケージ化されている(およびデプロイされている)場合、oaam_native_libのWARバージョン(IAM_ORACLE_HOME/oaam/oaam_libs/war/oaam_native_lib.war)をWebLogicの共有ライブラリとしてデプロイする必要があります。
OAAMサンプル・アプリケーションからWARバージョンの共有ライブラリを使用するには、次のエントリをWebLogicデプロイメント・ディスクリプタ・ファイルweblogic.xmlに追加することで共有ライブラリを参照する必要があります。
<library-ref>
<library-name>oracle.oaam.libs</library-name>
</library-ref>
OAAMサンプルがEARファイルとしてパッケージ化されている(およびデプロイされている)場合、oaam_native_libのEARバージョン(IAM_ORACLE_HOME/oaam/oaam_libs/ear/oaam_native_lib.ear)をWebLogicの共有ライブラリとしてデプロイする必要があります。
OAAMサンプル・アプリケーションからEARバージョンの共有ライブラリを使用するには、次のエントリをWebLogicデプロイメント・ディスクリプタ・ファイルweblogic-application.xmlに追加することで共有ライブラリを参照する必要があります。
<library-ref>
<library-name>oracle.oaam.libs</library-name>
</library-ref>
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共有ライブラリのデプロイ先である管理対象サーバーに、OAAMサンプル・アプリケーションをアプリケーションとしてデプロイします。
「制御」タブの「デプロイメントのサマリー」にある「IAMDomain」(左側のペイン)で、「デプロイメント」をクリックします。
「インストール」ボタンをクリックします。パスで、OAAMサンプル・アプリケーションの場所を指定します。「次へ」をクリックします。
「このデプロイメントをアプリケーションとしてインストールする」オプションを選択します。「次へ」をクリックします。
「デプロイ・ターゲットの選択」ページで、サーバーのリストから管理対象サーバーを選択し、「次へ」をクリックします。
「終了」をクリックします。
「チェンジ・センター」の「変更のアクティブ化」をクリックします。
管理対象サーバーを起動します。
Oracle WebLogic管理コンソールに移動します。「ロックして編集」をクリックして「デプロイメント」ノードを選択します。「デプロイメントのサマリー」ページで、OAAMサンプル・アプリケーションを検索して選択します。「起動」→「すべてのリクエストを処理」をクリックします。「はい」をクリックして確認します。
OAAM Adminアプリケーションにログインし、Oracle Adaptive Access Manager管理コンソールを使用してOAAMスナップショットoaam_base_snapshot.zipファイルをシステムにインポートします。スナップショットには、Oracle Adaptive Access Managerが必要とするポリシー、チャレンジ質問、依存コンポーネントおよび構成が含まれています。
OAAMスナップショットのインポートの手順は、『Oracle Adaptive Access Managerの管理』を参照してください。
次のURLに移動します。
http://managed_server:port/oaam_sample
OAAMサンプル・アプリケーションのログイン・ページが表示されます。
次のページで、ユーザー名とパスワードを入力します。登録が行われます。
|
注意: 最初のログイン時のパスワードはtestである必要があります。このパスワードはすぐに変更してください。 |
この項に記載されている統合フローの例は、仮想認証デバイス、ナレッジベース認証およびワンタイム・パスワードを統合します。
この項で理解する必要のある用語を次に示します。
認証: 認証フローは、セキュリティ制約に従ってリソースへのアクセスを要求する個人または他のエンティティのIDを検証するために使用されるプロセスです。マルチファクタ認証とは、様々なファクタを同時に使用して個人または他のエンティティを認証するシステムです。
仮想認証デバイス: 仮想認証デバイスは、認証資格証明の入力と送信のプロセスにおいて、エンド・ユーザー情報の保護に使用されるオーセンティケータ・インタフェースで、エンド・ユーザーは、有効なアプリケーションに対して認証していることを確認できます。OAAMには、非常にセキュアな仮想認証デバイス一式が、ユーザーの選択に応じてデプロイできるサンプルとして組み込まれています。これらのサンプルの変更は、カスタム開発と見なされます。デプロイメントでローカライゼーションがサポートされている場合は、デプロイメント・チームが、グローバル化された仮想認証デバイスのイメージ・ファイルを登録フローを含めて開発する必要があります。
ナレッジベース認証(KBA): ナレッジベース認証(KBA)は、登録済チャレンジ質問に基づいてインフラストラクチャを提供するセカンダリ認証方式です。これにより、エンドユーザーは、質問を選択して、必要に応じてシステムが後でチャレンジするきに必要な回答を提供できます。セキュリティ管理には、次のものがあります。
チャレンジ質問および回答の登録を管理する登録ロジック
チャレンジのレスポンス・プロセスで適切な回答をインテリジェントに検出する回答ロジック
登録時にユーザーから提供された回答の検証
詳細は、『Oracle Adaptive Access Managerの管理』のナレッジ・ベース認証の管理に関する項を参照してください。
ワンタイム・パスワード: ワンタイム・パスワード(OTP)はリスク・ベースのチャレンジ・ソリューションであり、構成済のアウト・オブ・バンド・チャネルを経由してエンドユーザーに送信されるサーバー生成のワンタイム・パスワードから構成されます。サポートされるOTP配信チャネルには、ショート・メッセージ・サービス(SMS)、電子メール、インスタント・メッセージング(IM)などがあります。OTPは、KBAチャレンジを補完するために使用することも、KBAのかわりに使用することもできます。
詳細は、『Oracle Adaptive Access Managerの管理』のOTP Anywhereの設定に関する項を参照してください。
図2-3では、仮想認証デバイス、KBAおよびOTPを使用した認証フローの例を説明しています。ここに示すフローは例であり、他の認証フローも考えられます。
チェックポイントとルーの詳細は、以降の各項で説明します。
ユーザー名の送信を要求するページが表示されます。ユーザーがこの最初のページにログインID(ユーザー名)を入力すると、このユーザー名がHTTPセッションに格納されます。
|
注意: アプリケーションでカスタム・ログイン・ページを使用する場合は、ログイン・ページを2つのページに分割する必要があります。 |
図2-4に、ユーザー名ページの例を示します。
ユーザー名ページに続いて、フラッシュCookieとセキュアCookieを取得し、ユーザー・デバイスのフィンガープリントを処理するための一時ページが表示されます。
デバイスのフィンガープリント処理では、ブラウザ・タイプ、ブラウザ・ヘッダー、オペレーティング・システム・タイプ、ロケールなどのデバイスに関する情報が収集されます。フィンガープリント・データは、デバイスについてログイン・プロセス中に収集されるデータを表します。このデータは、ユーザーがシステムへのログインに使用するデバイスの識別に必要です。フィンガープリント処理プロセスでは、ユーザー固有のフィンガープリントが生成されます。フィンガープリント詳細は、デバイスの識別、それがセキュアであるかどうかの確認および認証またはトランザクションのリスク・レベルの特定に役立ちます。表2-1に、デバイスのフィンガープリント処理に使われるAPIを示します。
表2-1 デバイスのフィンガープリント処理API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
フィンガープリントを作成するAPIは、次のとおりです。
|
updateLog()の詳細は、第4.6.35項「updateLog」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
デバイス識別のCookie
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.6.26項「processRules」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
|
Authentipadチェックポイントによって、使用する仮想認証デバイスが判別されます。
|
注意: シングル・ログイン・ページを使用するようにOAAMが構成されている場合、仮想認証デバイスはフローで使用されません。シングル・ログイン・ページの詳細は、第8.5項「シングル・ログイン・ページの構成」を参照してください。 |
ユーザーがイメージまたはフレーズを登録していない場合は、汎用TextPadがルールによって割り当てられます。ユーザーが登録している場合は、パーソナライズされたTextPadまたはKeyPadのいずれかがルールによって割り当てられます。仮想認証デバイスによって返される共通の値は、次のとおりです。
汎用TextPad: デフォルトの汎用TextPadを使用します。
TextPad: パーソナライズされたTextPadを使用します。
KeyPad: パーソナライズされたKeyPadを使用します。
パーソナライズされたTextpadは、キーボードを使用してパスワードまたはPINを入力するためのデバイスです。このデータ入力方法は、フィッシングからの防御に役立ちます。TextPadは、大規模デプロイメントのすべてのユーザーに対してデフォルトとしてデプロイできます。その後、各ユーザーは必要に応じて別のデバイスにアップグレードできます。ユーザーが登録した個人イメージおよびフレーズは、ユーザーが有効なWebサイトにログインするたびに表示され、ユーザーとサーバーとの間の共有シークレットとして機能します。
Keypadは、入力用のキーボードを使用してパスワード、クレジットカード番号などを入力するためのデバイスです。KeyPadによって、トロイの木馬やキーロギングからの保護が提供されます。
表2-3に、仮想認証デバイスのルールを実行するAPIを示します。
表2-3 仮想認証デバイスのルールのAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.26項「processRules」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
|
ユーザーがイメージおよびフレームをまだOAAMに登録していない場合は、図2-5に示すように、一般的な、パーソナライズされていないTextPadが表示されます。
このデバイスには特定のイメージまたはフレーズはありませんが、ログイン・プロンプトの正当性の証明に役立つタイムスタンプが表示されます。
表2-4に、汎用TextPadの生成に使用するAPIを示します。
表2-4 汎用TextPad APIの生成
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.20項「getUserByLoginId」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
|
|
|
クライアント |
|
ユーザーがフレーズとイメージをOAAMに登録している場合は、ユーザーに対してパーソナライズされたTextPadが使用されます。図2-6と図2-7に、パーソナライズされたテキストおよび生成される重要な仮想認証デバイスを示します。
表2-5に、パーソナライズされたTextPadまたはKeyPadの生成に使用するAPIを示します。
表2-5 パーソナライズされたTextPadまたはKeyPadのAPIの生成
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.20項「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の表示
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
|
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
Oracle Adaptive Access Managerのサンプル |
|
仮想認証デバイスを出力します。 |
|
BharosaHelper |
|
|
|
クライアント |
|
図2-6に、パーソナライズされたTextPadを示します。
図2-7に、パーソナライズされたKeyPadを示します。
イメージとフレーズが、ユーザーのローカル・タイムゾーンにおける現在のタイムスタンプとともにデバイスに埋め込まれています。
この段階では、ユーザーが指定したデータが、選択した仮想認証デバイスによってデコードされます。デコードされた値はRAWテキスト・フォーマットで出力されます。デコードされた値は、HTTPセッションに保存しておくことをお薦めします。仮想認証デバイスのオブジェクトはシリアライズされ、データベースまたはファイルシステムに格納されます。仮想認証デバイスは、システムが入力のデコードに使用するため、セッション中に格納されます。これは、PinPadやKeyPadのように、ユーザー入力がクリアテキストではない仮想認証デバイスで必要とされます。整合性を確保するために、この処理はすべての仮想認証デバイスで実行されます。仮想認証デバイスは、相互に交換できるように設計されているからです。
表2-7に、ユーザー入力のデコードに使用するAPIを示します。
この段階は、クライアントがローカルAPIを起動してユーザーを認証し、認証結果がOAAMサーバーに渡されるという、クライアントの既存のプロセスを表しています。使用するAPIについては、表2-8で詳述します。
表2-8 ユーザーとパスワード検証のAPI
| モジュール | API | 説明 |
|---|---|---|
|
Oracle Adaptive Access Managerのサンプル |
|
|
ユーザーのパスワード検証後に、表2-9に説明するAPIを使用してステータスが更新されます。
表2-9 認証ステータス更新のAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.34項「updateAuthStatus」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
|
パスワード認証ステータスに応じて、再試行ページが表示されるか、認証後のページに進みます。
これらのルールは、ユーザー・パスワードの認証後に実行されます。認証後によって返される共通のアクションは、次のとおりです。
ALLOW
BLOCK
CHALLENGE
認証後の結果がALLOWの場合、ユーザーを登録する必要があるかどうかが判別され、ユーザーが登録フローに送られます。認証後の結果がBLOCKの場合、ユーザーはブロックされ、アクセスを試みたWebアプリケーションにアクセスできなくなります。認証後の結果がCHALLENGEであり、ユーザーが1つ以上のチャレンジ・メカニズムにすでに登録されている場合、ユーザーはチャレンジ・フローに送られます。
認証後に使用されるAPIを表2-10に示します。
表2-10 認証後ルールの参照API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.26項「processRules」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
handlePassword.jsp |
次の値を返す
|
|
BharosaHelper |
|
登録確認ルールが実行されます。ユーザーが未登録の場合は、登録するよう指示されます。
ビジネスおよびセキュリティ要件によって、登録が必須か、または任意であるかが指定されます。登録ルールによって返される値は、次のとおりです。
Register: ユーザー登録を必要とします。
Registration Optional: ユーザー登録は任意です。
Skip Registration: このセッションの登録をスキップします。
表2-11に、登録ルールの実行に使用されるAPIを示します。
表2-11 登録必須ルールの参照API
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.26項「processRules」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
BharosaHelper |
|
登録とは、アカウントを新規に開く場合など、ユーザーに情報を求めるイベントからなる登録プロセスのことです。登録フローにより、ユーザーは質問、イメージ、フレーズおよびOTP(電子メール、電話など)の登録を許可されます。登録が成功すると、KBAとOTPをセカンダリ認証ファクタとして使用してユーザーにチャレンジできます。
表2-12では、登録フローのモジュールとAPIについて説明しています。
表2-12 登録フロー
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.26項「processRules」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
|
|
|
|
|
|
|
|
|
|
BharosaHelper |
|
チャレンジ・ルールは、ユーザーに表示するチャレンジのタイプを判別するために起動されます。チャレンジ・ルールによって返される値は、次のとおりです。
ChallengeQuestion: ユーザーに質問でチャレンジします。
ChallengeSMS: ユーザーにSMSを通してOTPでチャレンジします。
ChallengeEmail: ユーザーに電子メールを通してOTPでチャレンジします。
ChallengeChoice: ユーザーにチャレンジ・タイプの選択を許可します
BLOCK: ユーザーをブロックします。
表2-13に、チャレンジ・ルールの実行に使用されるAPIを示します。
表2-13 チャレンジ・ルール実行のAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.26項「processRules」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
このメソッドが |
|
BharosaHelper |
|
BharosaHelper::getAuthentiPadは、認証デバイスの作成に使用します。このメソッドは認証デバイスのルールをコールして、使用するデバイスを判別します。
ユーザーが質問でチャレンジされる場合、このルールはQuestionPadを割り当てます。ユーザーがOTPでチャレンジされる場合、このルールはTextPadを割り当てます。
ユーザーは、必要に応じて、ナレッジ・ベース認証(KBA)またはOTP(ワンタイム・パスワード)のいずれかでチャレンジされます。
KBAは既存のユーザーID/パスワード認証の拡張であり、ユーザーが質問でチャレンジされるチャレンジ/レスポンス・プロセスを使用してアプリケーションのセキュリティを保証します。ユーザーは、リクエストしたサインオン、トランザクション、サービスなどの処理を続行するためには、質問に正しく回答する必要があります。
OTPも既存のユーザーID/パスワード認証の拡張であり、特別のセキュリティ・レイヤーを追加してアプリケーションを保護します。OTPはユーザーIDとパスワードの検証後に生成され、アプリケーションで必要と見なされた場合に電子メールまたは携帯電話を通してユーザーに配布されます。その後、ユーザーはこのOTPを使用してアプリケーションにサインインします。
表2-14に、登録済の質問でユーザーにチャレンジするAPIを示します。
|
注意: generateOTP() APIは、OAAM JAVAおよびSOAP APIでは非推奨になりました。本番コードを作成する場合は、かわりにgetOTPCode() APIを使用してください。getOTPCode() APIの使用方法の詳細は、Oracle Adaptive Access Manager Java APIリファレンスを参照してください。 |
表2-14 ユーザーにチャレンジするAPI
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
|
|
Oracle Adaptive Access Managerのサンプル |
|
使用するチャレンジのタイプを判別します。 返されたチャレンジ・タイプがKBA ( チャレンジ・タイプがOTP (
認証パッド・ルールを使用して、ユーザーに表示するauthentipadを判別します。第2.3.4項「仮想認証デバイスのルールの実行(r3)」を参照してください。 回答を
|
|
BharosaHelper |
|
|
|
クライアント |
|
この段階では、チャレンジに対するユーザーの入力を検証します。
KBAの場合、Oracle Adaptive Access Managerサーバーがコールされて、ユーザーが指定した回答が登録済の返答と一致するかどうかを判別します。
OTPの場合、ユーザーの入力値と、生成されてユーザーに送信されたOTPの入力値が比較されます。
表2-15に、チャレンジの検証に使用されるAPIを示します。
表2-15 チャレンジに対する回答の検証
| モジュール | API | 説明 |
|---|---|---|
|
サーバー |
|
メソッドの詳細は、第4.6.26項「processRules」および第4.6.34項「updateAuthStatus」を参照してください。 |
|
Oracle Adaptive Access Managerのサンプル |
|
このメソッドが |
|
BharosaHelper |
|
検証中のチャレンジのタイプがKBA ( 検証中のチャレンジのタイプがOTP ( メソッドによって、 |
ロックアウト・ページは、認証後ルールでBLOCKが返されたときにユーザーがリダイレクトされるページです。
このページはログインの成功後、つまり、認証後ルールでALLOWが返されたときにユーザーがリダイレクトされるページです。
