| Oracle® Fusion Middleware Oracle Access Management開発者ガイド 11g リリース2 (11.1.2.2.0) for All Platforms B69537-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management開発者ガイド 11g リリース2 (11.1.2.2.0) for All Platforms B69537-08 |
|
前 |
次 |
OAMサーバーでは、保護対象とするリソースへのアクセスを制限するために、認証と認可の両方の制御が利用されます。認証は特定の認証スキームにより制御され、認証スキームは、ユーザーがリソースへのアクセス試行時に入力した資格証明をテストする、1つ以上のプラグインに依存します。プラグインは、OAMサーバーのインストールで提供される標準セット、または独自のJava開発者が作成したカスタム・プラグインから取得できます。この章の内容は次のとおりです。
|
参照: Oracle Access Management管理コンソールを使用した認証プラグインのデプロイおよび管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。 |
11gは、初期状態ですぐに使用できる認証モジュールの他に、次のものを提供します。
カスタマイズされた認証モジュール(プラグイン)を構築してデフォルトの機能を個々の要件に合せるための、認証プラグイン・インタフェースおよびSDKツール。新規インタフェースおよびSDKツールは次のとおりです。
Oracle Access Manager 10gのカスタム・プラグインをサポートするための下位互換性を提供します。
カスタム・プラグインを編成するための決定論的メソッドを認証モジュール内に含めます。
カスタマイズされた認証プラグインを素早くデプロイできるようにするメカニズム。
プラグインの状態ライフサイクルを完全に管理するメカニズム。
資格証明コレクション用のカスタム・プラグインの開発が、認証のためにサポートされています(編成可能な手順)。
図3-1では、カスタム・プラグインのデプロイ・タスクの概要を示しています。
次の概要では、カスタム・プラグインのデプロイ・タスクを識別しています。
タスクの概要: カスタム・プラグインのデプロイ
計画: 第3.1.2項「計画、認証モデルおよびプラグインについて」で説明しているように、このプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討します。
セキュリティ・アーキテクトは、Access Manager 11gの使用方法および顧客のユーザー・ベースを把握しています。システム・アーキテクトは、顧客の実装における改善点を識別できます。
開発:
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。
プラグインを記述します。
カスタム・モジュールのメタデータXMLを記述します。
マニフェスト・ファイルを作成します。
felix.jar、identitystore.jar、oam-plugin.jar、utilities.jarのjarファイルをCLASSPATHに追加します。
デプロイ:
Oracle Access Management管理者は、複数のプラグインが認証モジュールで連携するようにデプロイおよび編成し、プラグインをテストおよびモニターします。一般的なデプロイ・タスクは次のとおりです。
カスタム・プラグインの追加。これには、プラグイン・データ・ソースまたはドメインの構成、プラグインの配布およびアクティブ化が含まれます。
カスタム・プラグインに対応したカスタム認証モジュールの作成。これには、手順および結果(OnSuccess、OnFailureおよびOnError)の追加および編成が含まれます。
カスタム認証モジュールを含む認証スキームの作成。
カスタム・プラグインのロギングの構成。
アクセス・テスターによるプラグインのテスト。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
必要に応じてビジネス要件およびアーキテクチャを修正できるように、プラグインをモニターし、セキュリティ・アーキテクトまたはシステム・アーキテクトにフィードバックを提供。
Oracle Access Management管理コンソールを使用した認証プラグインのデプロイの詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
プラグインのライフ・サイクルは、OAMサーバーへのプラグインの追加およびプラグインを使用した機能の追加作成の機能を中心としています。これによりユーザーは、サーバーの拡張機能の役割を果たす標準(すぐに使用できる)プラグインおよびユーザーが追加したプラグインに基づいて、機能およびワークフローを作成できます。
一般的なプラグインのライフ・サイクルは次のとおりです。
計画
プラグイン開発時間、プラグイン・メタデータ・アーティファクトの生成が含まれます
プラグインのロードおよびライフサイクル
インポート: プラグインをAccess Managerにアップロードし、サーバーを再起動せずにこれを使用
配布: サーバーの停止時間なしで、プラグインjarファイルを1つのローカルOAMサーバー・ファイルシステムからクラスタ内のすべての管理サーバーに伝播
アクティブ化: プラグインが認証モジュール・フローで使用される際に、このプラグイン実装を実行時にロード
プラグインのスタートアップ・パラメータまたは構成を使用
プラグイン構成データをoam-config.xmlにプッシュおよびプル
OAMサーバーの状態ライフサイクル全体を管理
デプロイされたプラグインの状態
プラグインのモニターおよび監査
プラグイン実行の所要時間およびプラグインの実行回数に関するマトリクス・データを収集
プラグイン入出力のマトリクス・データを収集
プラグイン実行開始時間および終了時間のマトリクス・データを収集
プラグインのライフサイクル・メソッド・コードの監査
新規のプラグインJARファイルがある場合、開発者はこのファイルを管理コンソールのインポート・アクションからWeblogic ServerのDOMAIN_HOME/oam/pluginsにインポートできます。
表3-1では、Oracle Access Management管理者が制御するプラグイン・ライフサイクルの状態を示しています。詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
表3-1 プラグイン・ライフサイクルの状態
| 状態 | 説明 |
|---|---|
|
インポート |
プラグインJARファイルをWeblogic ServerのDOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。 |
|
配布 |
登録済のすべてのOAMサーバーにプラグインを伝播します。 |
|
アクティブ化 |
プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。 |
|
非アクティブ化 |
非アクティブ化では、oam-config.xmlのプラグイン・エントリ・フラグがチェックされます。 非アクティブ化プロセスでOAMサーバーに障害が発生した場合、「非アクティブ化に失敗しました」というメッセージが伝播されます。 |
|
削除 |
Weblogic ServerのDOMAIN_HOME/config/fmwconfig/oam/pluginsディレクトリから指定されたプラグイン(JAR)を削除し、Weblogic ServerがすべてのOAMサーバーに通知します。 |
OAMサーバーのプラグインは、カスタム認証スキームの一部です。各種プラグインを次の目的に使用できます。
ユーザー・アイデンティティ・マッピング
プラグインにより、ログイン・ユーザー名の形式ではなくユーザー入力の形式に対応するための機能を追加できます。フィンガープリント、一連のセキュリティ質問およびその他の方法を使用できます。プラグインによりこれらの入力が翻訳され、データベースと照らしあわせてチェックされます。
ユーザー認証
ユーザーの認証時には、レスポンス(すぐに使用できる提供なし)が必要となる場合があります。カスタム・プラグインによりこのニーズに応えることができます。
カスタム・レスポンス
レスポンスおよびこれらのレスポンスが残りのシステムと対話する方法について、カスタム・プラグインを使用できます。
その他のタイプのプラグインもサポート
図3-2は、ユーザーが保護されたリソースをリクエストした場合の認証フローを示しています。認証はプロセスであり、プロトコルではありません。緑色の点線矢印は、OAMサーバーにデプロイされたプラグインによって生成されたカスタム・レスポンスです。
カスタム認証プラグインを設計および開発する前に、開発者はAccess Manager認証決定プロセスを綿密に分析し、ユーザーをどのように認証する必要があるかを確認することをお薦めします。
あるリクエストを受け取った場合、これを処理するには2通りの方法が考えられます。1つは、リクエストの属性に応じて特定のスキームを実行する方法であり、デシジョン・エンジンを使用して1つ以上のスキームを実行し、ユーザーを正しく認証します。これは、各スキーム内のコードが少なくて済み、モジュール性が高くなります。もう1つのオプションは、特定の目的でリクエストの様々な属性を処理するためにすべてのスキームをハードコードする方法であり、デシジョン・エンジンを使用せずに、どのスキームを実行する必要があるかを全体から把握します(1つのスキームのみ実行されます)。
例: デシジョン・エンジン対ハードコード認証
ユーザーが夜中に自宅のコンピュータを使用して、オンラインバンクの口座にログインすると仮定します。次の概要では、デシジョン・エンジンおよびハードコードのそれぞれの方法における処理の相違点を説明しています。開発者は、どの方法が要件に最も合うかを判断する必要があります。
2つの方法の相違点は単純ですが、重要です。
プロセスの概要: デシジョン・エンジンを使用する方法
夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。
デシジョン・エンジンにより、このIPアドレスが以前処理されたことが確認されます。また、夜中に認証を試みるユーザーは疑わしいと判断され、ユーザーはユーザー名およびパスワードだけでなく、セキュリティ質問に回答することが要求されます。
指定されたユーザーに対してセキュリティ質問スキームが実行され、成功します。これは、デシジョン・エンジンによって選択された2つの認証スキームのうちの1つ目です。
ユーザーパスワード・スキームが実行され、ユーザーは正常に認証されます。これは、デシジョン・エンジンによって選択された2つ目の認証スキームです。
プロセスの概要: ハードコードを使用する方法
夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。
オンラインバンク口座のアクセス・スキームが他の認証スキーム(クレジット・カード・アクセス・スキーム、新規口座作成および検証など)の中から選択されます。
このスキームでは最初にIPアドレスがチェックされ、ユーザーが以前このコンピュータから接続を試みたことがあるかどうかが確認されます。ユーザーが以前そうしたと確認されます。
スキームにより時間がチェックされます。セキュリティ質問の回答が要求され、正しく回答されます。
スキームによりユーザーはログイン資格証明の入力が要求され、正常に認証されます。
どちらのリクエスト方法にも、それぞれメリットとデメリットがあります。デシジョンエンジン・モデルの場合、コードの再利用が主なメリットですが、ハードコードを使用した方法はセキュリティが向上する場合があります。開発者は、どの方法を採用するかを決定する必要があります。
この項の内容は次のとおりです。
マルチステップ認証フレームワークでは、ログイン・プロセス中に数回にわたって情報をバックエンド認証スキームに送信するためのカスタム認証プラグインが必要になります。このプラグインによって収集され、コンテキストに保存された情報はすべて、認証プロセスを通じてプラグインから利用できます。コンテキスト・データは、Cookieまたはログイン・ページのヘッダーの設定にも使用できます。
認証フローのビルディング・ブロックはイベントです。イベントは、認証モジュール・プラグイン実装の公開メソッドを使用して作成されます。これらのイベントをルールと組み合せることで、認証の決定論的ワークフローを構築できます。ワークフロー・コントローラは、認証ワークフローの編成を担当するモジュールです。ワークフロー構成はワークフロー定義言語で定義されます。
多要素認証とは、ユーザーの認証に必要な複数の資格証明のコレクションを意味するビジネス用語です。マルチステップ認証フレームワークでは、多要素認証の要件を実装できます。また、必要に応じて、複数の手順を使用する単一要素認証も実装できます。たとえば、ユーザー名とパスワードを別々のページで収集できます。
マルチステップ認証は、次のものに依存しています。
資格証明コレクタ(DCCまたはECC)を使用してマルチステップ認証フローによる動的資格証明収集を実現するWebgate。これにより、複数のユーザー識別方式を含む認証関連情報の収集時に、ユーザーまたはプログラム的なエンティティとの対話の柔軟性が向上します。
認証モジュール連鎖。類似したチャレンジ・メカニズムのモジュールをグループ化し、資格証明を1つのパスに収集して各モジュールに対して検証します。複数の認証モジュールを1個の新しい認証スキームで連鎖させ、フローを含む新規のスキーム・プラグインを定義できます。
チャレンジ・メカニズムは、資格証明の収集方法を定義したものです。使用できるメカニズムは、FORM、BASIC、X509、WNA、OAM10G、TAPおよびNONEです。チャレンジ・メカニズムは、必要な資格証明の収集方法を制御します。現在、このメカニズムは認証スキームにリンクされています。
|
参照: 『Oracle Fusion Middleware Oracle Access Management管理者ガイド』の11g Webgateの外部資格証明収集のための構成に関する項 |
プロセス・リクエスト: マスター・コントローラが認証リクエストを処理してプラグインに渡します。
プロセス・イベント: 認証スキームが実行され、認証を続行するために入力が必要かどうかをプラグインが判断します。入力が必要な場合、プラグインはPAUSEという実行ステータスを返します。これによりイベント・フローが一時停止します。
PAUSEは、ユーザーから追加情報を取得するまで、認証プロセスを続行できないことを示します。したがって、リダイレクションが許可されます。リクエストした情報が供給されると、一時停止したポイントから処理が継続されます。実行する必要がある、関連付けられたACTIONの詳細によってリクエストが更新されます。ActionContextは、ACTIONを実行するためのすべての情報を持っています。
たとえば、PAUSEがCREDCOLLECT_ACTIONに関連付けられている場合、マスター・コントローラはプラグインの実行状態を保存してから、このCREDCOLLECT_ACTIONをCRED_COLLECTイベントにマップし、プラグインのCredentialParameterオブジェクトの指定どおりにコレクションを処理して、ACTIONに対応するイベントの実行を開始します。
保存されたプラグインの状態が再活性化され、SUCESSまたはFAILUREの状態に達するまでプラグインの実行が再開されます。FAILUREは、認証の試行に失敗したことを示します。その場合、OAMサーバーはユーザーの再認証を試みます。たとえば、ユーザーにログイン・フォームが表示されます。
有効なサブジェクトが存在する場合、ユーザー・セッションが作成され、実行状態の保存に使用されます。それ以外の場合は、実行状態がリクエスト・オブジェクトに保存されます。このセッションには、グローバル(共通)システム構成によって構成された最低の認証レベルが割り当てられています。
ユーザー認証が終了すると、このセッションは完全に有効なセッションに更新され、認証スキームで定義された認証レベルとOAMサーバーに対して構成されたセッション・タイムアウトが割り当てられます。
動的フロー・コントローラ内のイベントの実行が終了すると、制御が親コントローラに戻り、実行状態が更新されます。
認証が完了すると、リクエストしたリソースへのアクセスが許可されます。
マルチステップ認証モードでは、プラグインが資格証明を最初から収集することも、デフォルトのログイン・ページから取得した資格証明を使用したうえで必要に応じてさらに資格証明を収集することも可能です。チャレンジ・パラメータinitial_command=NONEが認証スキームに設定されている場合、プラグインが直接制御することとなり、プラグインによって資格証明の収集が制御されます。
プラグインでは、PAUSEステータスを使用して、資格証明の収集の際にユーザーとやりとりできるようUserActionパラメータを渡すことができます。1回以上クライアントに渡すことで、モジュールで必要なすべての資格証明を収集できます。PAUSE実行の間、プラグインの実行状態およびコンテキスト・データは保存されます。制御がプラグインに戻ると、停止していた実行が再開され、収集されたすべてのデータがプラグインで使用できるようになります。
プラグインがPAUSE状態に設定されている場合、プラグインでは次のことが可能です。
収集するデータの指定
リダイレクトまたは転送先のURLの指定
問合せ文字列の指定(存在する場合)
次のタイプの情報を資格証明コレクタ・ページに送ることができます。
UserContextDataでは、メタデータ(ログイン・ページで収集されるパラメータの名前、表示名およびタイプ)を指定します。たとえば、ログイン・アプリケーションからユーザー名を収集する場合、次のようになります。
final UserContextData userNameContext = new UserContextData(form_username, form_username, new CredentialMetaData(PluginConstants.TEXT));
ここで属性の名前はform_usernameです。
UserContextDataでは、資格証明の収集のため、ユーザーに表示するログイン・ページのURLを指定します。URLタイプを指定したCredentialMetaDataにより、ログイン・ページのURLが指定されます。次に例を示します。
final UserContextData urlContext = new UserContextData (loginPageURL, new CredentialMetaData("URL"))
ここでloginPageURLは、表示されるページのURLを指定します。
UserContextDataは、問合せパラメータをログイン・ページURLに渡す際に使用されます。QUERY_STRINGタイプを指定したCredentialMetaDataにより、loginPageURLとともに送信される問合せパラメータが指定されます。これはログイン・ページで処理できます。次に例を示します。
String queryString = "queryParam1=testParameter";
final UserContextData queryStringContext =new UserContextData
(queryString, new CredentialMetaData("QUERY_STRING"));
UserActionContextでは、ログイン・ページから収集されたUserContextDataメタデータを保持します。
UserActionクラスは、資格証明の収集に使用されます。さらに資格証明を収集するため、アクションはログイン・ページに転送またはリダイレクト(UserActionMetaDataパラメータによる)されます。
次の例で、これらのクラスを使用して、ログイン・ページに情報を指定する方法を示します。
//create a user name context data.
UserContextData userNameContext =
new UserContextData("form_username", "form_username",
new CredentialMetaData(PluginConstants.TEXT));
//create a password context data
// Any form parameter containing the words "password", "passcode" and "_pin" will be treated as sensitive values for debug logging
UserContextData passwordContext =
new UserContextData("form_password", "form_password",
new CredentialMetaData(PluginConstants.PASSWORD));
// create URl context data for login page
UserContextData urlContext = new UserContextData (loginPageURL,
new CredentialMetaData ("URL"));
UserActionContext actionContext = new UserActionContext ();
//add the UserContextData to the CredentialActionContext
actionContext.getContextData().add(userNameContext);
actionContext.getContextData().add(passwordContext);
actionContext.getContextData().add(urlContext);
//specify if we FORWARD or REDIRECT with a GET/POST to the login page
UserActionMetaData userAction = UserActionMetaData. FORWARD;
// create a UserAction object and set it to the authentication context.
UserAction action = new UserAction (actionContext, userAction);
authContext.setAction(action);
UserActionMetaDataでは、UserActionで使用されるアクション・タイプを指定します。UserActionは、UserActionMetaData値に基づいてログイン・ページへの転送またはリダイレクト(GETまたはPOSTを使用)を実行します。UserActionMetaDataに使用できる値は、FORWARD、REDIRECT_GETおよびREDIRECT_POSTです。
この項の内容は次のとおりです。
このトピックでは、パッケージ、クラス、インタフェースおよび注釈の階層について概要を説明します。
カスタム・プラグイン実装には、プラグイン実装クラス・アーティファクトの記述が含まれます。プラグイン実装クラスは、AbstractAuthenticationPlugInクラスを拡張し、initializeおよびprocessメソッドを実装する必要があります。カスタム・プラグイン実装者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。
プラグインの構成要件はXML形式で指定する必要があります。この構成データ(メタデータ)には、プラグイン名、作成者、作成日、バージョン、インタフェース・クラス、実装クラスおよび構成データが、属性/値ペアの形式で含まれます。新規のプラグイン名をマニフェスト・ファイルに追加する必要があります。ピリオド( . )は、プラグイン名として有効な文字ではありません。
11gは、次に説明する汎用プラグイン・インタフェースおよびより詳細な認証インタフェースを提供します。
oracle.security.am.plugin
パブリック・インタフェースoracle.security.am.pluginは、プラグイン名、プラグイン実装クラス名、プラグイン・バージョン、プラグイン実行ステータス、プラグイン・モニター・データ、プラグイン構成データを取得するメソッドや、プラグインを起動および停止するメソッドを提供する汎用プラグイン・インタフェースです。
AbstractAMPlugin
パブリック抽象クラスoracle.security.am.plugin.AbstractAMPluginは、java.lang.Object implements GenericPluginServiceおよびorg.osgi.framework.BundleActivatorを拡張します。
oracle.security.am.plugin.AbstractAMPlugin
これは、すべてのAccess Managerプラグインによって拡張される必要がある抽象プラグイン・クラスです。これは、プラグインの起動および停止メソッドのための基本実装を提供します。
|
参照: Oracle Fusion Middleware Oracle Access Management Access Manager Access SDK Java APIリファレンス |
oracle.security.am.plugin.authn.AuthnPluginService
パブリック・インタフェースoracle.security.am.plugin.authn.AuthnPluginServiceは、GenericPluginServiceを拡張します。
これは認証プラグイン・インタフェースであり、AuthenticationContextオブジェクトで使用可能なすべてのデータにアクセスおよび処理し、プロセス実行ステータスを戻すための追加認証固有メソッドを提供します。プラグインはSESSIONに追加されるレスポンスを設定し、コンテキストをリクエストおよびリダイレクトできます。
AbstractAuthenticationPlugIn
パブリック抽象クラスoracle.security.am.plugin.authn.AbstractAuthenticationPlugInは、AbstractAMPluginを拡張し、AuthnPluginServiceを実装します。
oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn
これはプラグイン開発者に公開される認証抽象プラグイン・クラスです。カスタム・プラグイン実装はすべて、このAbstractPlugInServiceクラスを拡張する必要があります。リソース・クリーン・アップを処理する必要があるプラグインは、shutdown(Map < String, Object > OAMEnvironmentContext)メソッドをオーバーライドします。また、これはjava.util.Loggerのインスタンスをプラグインに提供します。
このトピックでは、階層の一覧を提供します。
|
参照: Oracle Fusion Middleware Oracle Access Management Access Manager Access SDK Java APIリファレンス |
この項では、データベース・ユーザー認証プラグインのサンプル実装のスナップショットを提供し、開発者タスクを示しています。この項の内容は次のとおりです。
次の各図では、データベース・ユーザー認証プラグインのサンプル実装を3つの部分に分けて示しています。
|
参照: Oracle Fusion Middleware Oracle Access Manager Java APIリファレンス |
続く..
続く...
プラグインの構成要件はXML形式で指定する必要があります。
この構成データ(メタデータ)には、プラグイン名、プラグイン作成者、作成日、プラグイン・バージョン、プラグイン・インタフェース・クラス、プラグイン実装クラスおよびプラグイン構成データが、属性/値ペアの形式で含まれます。
図3-11では、サンプル: データベース・ユーザー認証プラグイン実装のメタデータが含まれるXMLスキーマ定義(XSD)ファイルを示しています。
例3-1は、サンプル: データベース・ユーザー認証プラグインのXMLメタデータです。
例3-1 XMLメタデータ: データベース・ユーザー認証プラグイン
<Plugin type="Authentication"> <author>uid=User1</author> <email>User1@example.com</email> <creationDate>09:32:20, 2010-12-02</creationDate> <description>Custom User Authentication Plugin Validation Against Domain Name</description> <configuration> <AttributeValuePair> <Attribute type="string" length="20">DataSource</Attribute> <mandatory>true</mandatory> <instanceOverride>false</instanceOverride> <globalUIOverride>true</globalUIOverride> <value>jdbc/CISCO</value> </AttributeValuePair> </configuration> </Plugin>
11.1.2リリースより、プラグイン・マニフェスト・ファイルに次の情報が追加されています。
Bundle-Versionフィールドから取得したプラグイン・バージョン。このフィールドは整数にする必要があります。
以前のリリースではXMLファイルから読み込むために使用されていたname=attributeパラメータが、Bundle-SymbolicNameまたはBundle-Nameフィールドから読み込まれるようになりました。このパラメータはXMLファイル内には必要ありません。
以前のリリースではXMLファイルから読み込むために使用されていたimplementationパラメータが、Bundle-Activatorフィールドから読み込まれるようになりました。このパラメータはXMLファイル内には必要ありません。
XMLファイルから<interface>oracle.security.am.plugin.authn.AbstractAuthenticationPlugIn</interface>を削除してかまいません。
例3-2 サンプル・マニフェスト・ファイル
Manifest-Version: 1.0 Bundle-Version: 10-->Note this to be an integer. Bundle-Name: MFASamplePlugin Bundle-Activator: mfasampleplugin.MFASamplePlugin Bundle-ManifestVersion: 2 Import-Package: org.osgi.framework;version="1.3.0",oracle.security.am.plugin,oracle.security.a m.plugin.authn,oracle.security.am.plugin.impl,oracle.security.am.plugin.api,or acle.security.am.common.utilities.principal,oracle.security.idm,javax.security .auth Bundle-SymbolicName: MFASamplePlugin . A corresponding sample modified XML file is : <Plugin type="Authentication"> <author>uid=User2</author> <email>User2@example.com</email> <creationDate>09:32:20 2010-12-02</creationDate> <description>Custom MFA Sample Auth Plugin</description> <configuration> <!-- Attribute "actiontype" indicates if the plugin wants to REDIRECT or FORWARD to the login page to collect credentials--> <AttributeValuePair> <Attribute type="string" length="20">actiontype</Attribute> <mandatory>false</mandatory> <instanceOverride>false</instanceOverride> <globalUIOverride>true</globalUIOverride> <value>FORWARD</value> </AttributeValuePair> . </configuration> . </Plugin>
サンプル(データベース・ユーザー認証プラグイン)のJARファイル構造を次に示します。
<plugin>.xml
<plugin>.class (パッケージ構造、第3.3項「プラグイン・インタフェースの概要」を参照)
META-INF (MANIFEST.MF)
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。
この項では、Access Manager 11g認証スキームで使用する認証プラグインの開発について説明します。内容は次のとおりです。
カスタム・プラグイン実装の記述には、次を行うためのプラグイン実装クラスの記述が含まれます。
AbstractAuthenticationPlugInクラスの拡張(第3.3.1項「プラグイン・インタフェースについて」を参照)
initializeメソッドの実装
processメソッドの実装
表3-3では、プラグインの機能に必要なメソッドについて説明します。
表3-3 必要なプラグイン・メソッド
| 必要なメソッド | 説明 |
|---|---|
|
initialize |
|
|
process |
さらに、
|
|
注意: カスタム・プラグイン開発者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。 |
この項では、カスタム認証プラグインの記述ステップを示します。
次の概要では、システム・アーキテクトがこのプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討した後に開発者が実行する必要があるアクションについて説明します。詳細は、第3.1.2項「計画、認証モデルおよびプラグインについて」を参照してください。
前提条件
サンプル・コード: カスタム・データベース・ユーザー認証プラグイン
タスクの概要: 開発者によるカスタム認証プラグインの記述
AbstractAuthenticationPlugInクラスを拡張し、次のメソッドを実装します(第3.5.1項「カスタム認証プラグインの記述について」も参照)。
initializeメソッドの実装
processメソッドの実装
適切なAccess Manager 11gインタフェースおよびパッケージを使用して、プラグイン・コードを開発します。参照:
カスタム・プラグインのメタデータを作成します。参照:
プラグインJarファイルおよびマニフェストを作成し、これらをデプロイ・チームに引き継ぎます。参照:
次に進みます。
カスタム認証プラグインのデプロイと管理の詳細は、『Oracle Fusion Middleware Oracle Access Management管理者ガイド』を参照してください。
プラグインでログイン・ページ、エラー・ページまたはクライアント・アプリケーション・ページとデータをやり取りする必要がある場合は、このデータをPluginResponsesとして送信できます。レスポンスはName=Valueのペアという形式で、データに関する詳細を提供します。OAMサーバーは、これらのレスポンスをHTTPレスポンス・パラメータとしてカスタム・ページに送信します。次のレスポンス・タイプによって、やり取りが容易になります。
CLIENT: 認証プロセスまたはユーザーに関するデータをプラグインがクライアント・アプリケーションに伝達できるようにします。リクエスト・パラメータはPLUGIN_CLIENT_RESPONSEです。
ERROR: 認証プロセスに関するエラーをプラグインが伝達できるようにします。リクエスト・パラメータはPLUGIN_ERROR_RESPONSEです。
例3-3 カスタム認証プラグインのエラー・コード
//Setting responses
PluginResponse rsp = new PluginResponse();
rsp = new PluginResponse();
rsp.setName("PluginClientCode");
rsp.setType(PluginAttributeContextType.CLIENT);
rsp.setValue("Err-100");
context.addResponse(rsp);
rsp = new PluginResponse();
rsp.setName("PluginErrorCode");
rsp.setType(PluginAttributeContextType.ERROR);
rsp.setValue("Card Expired");
context.addResponse(rsp);
String errorResponse = request.getParameter(GenericConstants.PLUGIN_ERROR_RESPONSE);
String clientResponse = request.getParameter(GenericConstants.PLUGIN_CLIENT_RESPONSE);
カスタム認証プラグインのコンパイルには、複数のJARファイルが必要です。
felix.jar
oam-plugin.jar
utilities.jar
identity-provider.jar
これらのJARファイルは、次のパスに置かれています。
DOMAIN_HOME/servers/MANAGED_INSTANCE_NAME/tmp/_WL_user/oam_server/RANDOM_STRING /APP-INF/lib
