3 カスタム認証プラグインの開発
この章には、認証プラグインに関する次の各項があります。
『Fusion Middleware Oracle Access Management管理者ガイド』の個別の認証用プラグインのデプロイおよび管理に関する項も参照してください。
3.1 認証プラグインの概要
このリリースでは、初期状態ですぐに使用できる認証モジュールの他に、次のものを提供します。
-
カスタマイズされた認証モジュール(プラグイン)を構築してデフォルトの機能を個々の要件に合せるための、認証プラグイン・インタフェースおよびSDKツール。新規インタフェースおよびSDKツールは次のとおりです。
-
Oracle Access Managerの以前のリリースのカスタム・プラグインをサポートするための下位互換性を提供します。
-
カスタム・プラグインを編成するための決定論的メソッドを認証モジュール内に含めます。
-
-
カスタマイズされた認証プラグインを素早くデプロイできるようにするメカニズム。
-
プラグインの状態ライフサイクルを完全に管理するメカニズム。
資格証明コレクション用のカスタム・プラグインの開発が、認証のためにサポートされています(編成可能なステップ)。
「プラグイン・インタフェースについて」も参照してください
図3-1では、カスタム・プラグインのデプロイ・タスクの概要を示しています。
次の概要では、カスタム・プラグインのデプロイ・タスクを識別しています。
-
計画:
「計画、認証モデルおよびプラグインについて」で説明しているように、このプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討します。
セキュリティ・アーキテクトは、Access Managerの使用方法および顧客のユーザー・ベースを把握しています。システム・アーキテクトは、顧客の実装における改善点を識別できます。
-
開発:
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。
-
プラグインを記述します。
-
カスタム・モジュールのメタデータXMLを記述します。
-
マニフェスト・ファイルを作成します。
-
felix.jar、identitystore.jar、oam-plugin.jar、utilities.jarのjarファイルをCLASSPATHに追加します。
-
-
デプロイ:
Oracle Access Management管理者は、複数のプラグインが認証モジュールで連携するようにデプロイおよび編成し、プラグインをテストおよびモニターします。一般的なデプロイ・タスクは次のとおりです。
-
カスタム・プラグインの追加。これには、プラグイン・データ・ソースまたはドメインの構成、プラグインの配布およびアクティブ化が含まれます。
-
カスタム・プラグインに対応したカスタム認証モジュールの作成。これには、ステップおよび結果(OnSuccess、OnFailureおよびOnError)の追加および編成が含まれます。
-
カスタム認証モジュールを含む認証スキームの作成。
-
カスタム・プラグインのロギングの構成。
-
アクセス・テスター・コンソールからのユーザー認証のテストに関する項で説明されている、アクセス・テスターを使用したプラグインのテスト
-
必要に応じてビジネス要件およびアーキテクチャを修正できるように、プラグインをモニターし、セキュリティ・アーキテクトまたはシステム・アーキテクトにフィードバックを提供。
-
Oracle Access Management管理コンソールを使用した認証プラグインのデプロイの詳細は、『Fusion Middleware Oracle Access Management管理者ガイド』の個別の認証用プラグインのデプロイおよび管理に関する項を参照してください。
3.1.1 カスタム・プラグインのライフ・サイクルについて
プラグインのライフ・サイクルは、OAMサーバーへのプラグインの追加およびプラグインを使用した機能の追加作成の機能を中心としています。これによりユーザーは、サーバーの拡張機能の役割を果たす標準(すぐに使用できる)プラグインおよびユーザーが追加したプラグインに基づいて、機能およびワークフローを作成できます。
一般的なプラグインのライフ・サイクルは次のとおりです。
-
計画
-
プラグイン開発時間、プラグイン・メタデータ・アーティファクトの生成が含まれます
-
プラグインのロードおよびライフサイクル
-
インポート: プラグインをAccess Managerにアップロードし、サーバーを再起動せずにこれを使用
-
配布: サーバーの停止時間なしで、プラグインjarファイルを1つのローカルOAMサーバー・ファイル・システムからクラスタ内のすべての管理サーバーに伝播
-
アクティブ化: プラグインが認証モジュール・フローで使用される際に、このプラグイン実装を実行時にロード
-
プラグインのスタートアップ・パラメータまたは構成を使用
-
プラグイン構成データをoam-config.xmlにプッシュおよびプル
-
OAMサーバーの状態ライフサイクル全体を管理
-
-
デプロイされたプラグインの状態
-
プラグインのモニターおよび監査
-
プラグイン実行の所要時間およびプラグインの実行回数に関するマトリクス・データを収集
-
プラグイン入出力のマトリクス・データを収集
-
プラグイン実行開始時間および終了時間のマトリクス・データを収集
-
プラグインのライフサイクル・メソッド・コードの監査
-
新規のプラグインJARファイルがある場合、開発者はこのファイルを管理コンソールのインポート・アクションからWeblogic ServerのDOMAIN_HOME/oam/pluginsにインポートできます。
表3-1では、Oracle Access Management管理者が制御するプラグイン・ライフサイクルの状態を示しています。詳細は、『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サーバーに通知します。 |
3.1.2 計画、認証モデルおよびプラグインについて
OAMサーバーのプラグインは、カスタム認証スキームの一部です。様々な種類のプラグインを使用して、次の機能を追加できます。これは完全なリストではありません。他のタイプのプラグインもサポートされます。
-
ユーザー・アイデンティティ・マッピング
プラグインにより、ログイン・ユーザー名の形式ではなくユーザー入力の形式に対応するための機能を追加できます。フィンガープリント、一連のセキュリティ質問およびその他の方法を使用できます。プラグインによりこれらの入力が翻訳され、データベースと照らしあわせてチェックされます。
-
ユーザー認証
ユーザーの認証時には、レスポンス(すぐに使用できる提供なし)が必要となる場合があります。カスタム・プラグインによりこのニーズに応えることができます。
-
カスタム・レスポンス
レスポンスおよびこれらのレスポンスが残りのシステムと対話する方法について、カスタム・プラグインを使用できます。
図3-2は、ユーザーが保護されたリソースをリクエストした場合の認証フローを示しています。認証はプロセスであり、プロトコルではありません。緑色の点線矢印は、OAMサーバーにデプロイされたプラグインによって生成されたカスタム・レスポンスです。
カスタム認証プラグインを設計および開発する前に、開発者はAccess Manager認証決定プロセスを綿密に分析し、ユーザーをどのように認証する必要があるかを確認することをお薦めします。
あるリクエストを受け取った場合、これを処理するには2通りの方法が考えられます。1つは、リクエストの属性に応じて特定のスキームを実行する方法であり、デシジョン・エンジンを使用して1つ以上のスキームを実行し、ユーザーを正しく認証します。これは、各スキーム内のコードが少なくて済み、モジュール性が高くなります。もう1つのオプションは、特定の目的でリクエストの様々な属性を処理するためにすべてのスキームをハードコードする方法であり、デシジョン・エンジンを使用せずに、どのスキームを実行する必要があるかを全体から把握します(1つのスキームのみ実行されます)。表3-2に示すとおり、どちらのリクエスト方法にも、それぞれメリットとデメリットがあります。
表3-2 リクエスト方法の比較
方法 | 説明 |
---|---|
デシジョン・エンジン |
認証スキームをより小さい連続モジュールに分割し、必要に応じて連携するよう編成できます。 メリット:
|
ハードコード |
決定事項はありません。ユーザーが認証のために渡す必要があるIf-Else文一式に類似します。 メリット: セキュリティが向上する可能性があります。 |
ユーザーが夜中に自宅のコンピュータを使用して、オンラインバンクの口座にログインすると仮定します。2つの手法の相違点は、単純ですが重要で、開発者はどちらの手法が要件によく適合するかを判断する必要があります。次の処理概要では、デシジョン・エンジンおよびハードコードのそれぞれの方法における処理の相違点を説明しています。
3.1.2.1 デシジョン・エンジンを使用する方法のプロセスについて
デシジョン・エンジンを使用して認可リクエストを処理する方法は、次のようになります。
-
夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。
-
デシジョン・エンジンにより、このIPアドレスが以前処理されたことが確認されます。また、夜中に認証を試みるユーザーは疑わしいと判断され、ユーザーはユーザー名およびパスワードだけでなく、セキュリティ質問に回答することが要求されます。
-
指定されたユーザーに対してセキュリティ質問スキームが実行され、成功します。これは、デシジョン・エンジンによって選択された2つの認証スキームのうちの1つ目です。
-
ユーザーパスワード・スキームが実行され、ユーザーは正常に認証されます。これは、デシジョン・エンジンによって選択された2つ目の認証スキームです。
3.1.2.2 ハードコードを使用する方法のプロセスについて
ハードコードを使用して認可リクエストを処理する方法は、次のようになります。
-
夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。
-
オンラインバンク口座のアクセス・スキームが他の認証スキーム(クレジット・カード・アクセス・スキーム、新規口座作成および検証など)の中から選択されます。
-
このスキームでは最初にIPアドレスがチェックされ、ユーザーが以前このコンピュータから接続を試みたことがあるかどうかが確認されます。ユーザーが以前そうしたと確認されます。
-
スキームにより時間がチェックされます。セキュリティ質問の回答が要求され、正しく回答されます。
-
スキームによりユーザーはログイン資格証明の入力が要求され、正常に認証されます。
3.2 マルチステップ認証フレームワークの概要
この項では次のトピックを記載しています:
3.2.1 マルチステップ・フレームワークについて
マルチステップ認証フレームワークでは、ログイン・プロセス中に数回にわたって情報をバックエンド認証スキームに送信するためのカスタム認証プラグインが必要になります。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはログイン・ページのヘッダーの設定にも使用できます。
認証フローのビルディング・ブロックはイベントです。イベントは、認証モジュール・プラグイン実装の公開メソッドを使用して作成されます。これらのイベントをルールと組み合せることで、認証の決定論的ワークフローを構築できます。ワークフロー・コントローラは、認証ワークフローの編成を担当するモジュールです。ワークフロー構成はワークフロー定義言語で定義されます。
多要素認証とは、ユーザーの認証に必要な複数の資格証明のコレクションを意味するビジネス用語です。マルチステップ認証フレームワークでは、多要素認証の要件を実装できます。また、必要に応じて、複数のステップを使用する単一要素認証も実装できます。たとえば、ユーザー名とパスワードを別々のページで収集できます。マルチステップ認証は、次のものに依存しています。
-
資格証明コレクタ(DCCまたはECC)を使用してマルチステップ認証フローによる動的資格証明収集を実現するWebGate。これにより、複数のユーザー識別方式を含む認証関連情報の収集時に、ユーザーまたはプログラム的なエンティティとの対話の柔軟性が向上します。
-
認証モジュール連鎖。類似したチャレンジ・メカニズムのモジュールをグループ化し、資格証明を1つのパスに収集して各モジュールに対して検証します。複数の認証モジュールを1個の新しい認証スキームで連鎖させ、フローを含む新規のスキーム・プラグインを定義できます。
チャレンジ・メカニズムは、資格証明の収集方法を定義したものです。使用できるメカニズムは、FORM、BASIC、X509、WNA、OAM、TAPおよびNONEです。チャレンジ・メカニズムは、必要な資格証明の収集方法を制御します。現在は、認証スキームに関連付けられています。
ノート:
『Fusion Middleware Oracle Access Management管理者ガイド』の外部資格証明コレクタとして構成されたWebGateに関する項
3.2.2 プロセスの概要: マルチステップ認証
-
プロセス・リクエスト: マスター・コントローラが認証リクエストを処理してプラグインに渡します。
-
プロセス・イベント: 認証スキームが実行され、認証を続行するために入力が必要かどうかをプラグインが判断します。入力が必要な場合、プラグインは
PAUSE
という実行ステータスを返します。これによりイベント・フローが一時停止します。PAUSE
は、ユーザーから追加情報を取得するまで、認証プロセスを続行できないことを示します。したがって、リダイレクションが許可されます。リクエストした情報が供給されると、一時停止したポイントから処理が継続されます。実行する必要がある、関連付けられたACTION
の詳細によってリクエストが更新されます。ActionContext
は、ACTION
を実行するためのすべての情報を持っています。たとえば、
PAUSE
がCREDCOLLECT_ACTION
に関連付けられている場合、マスター・コントローラはプラグインの実行状態を保存してから、このCREDCOLLECT_ACTION
をCRED_COLLECT
イベントにマップし、プラグインのCredentialParameter
オブジェクトの指定どおりにコレクションを処理して、ACTION
に対応するイベントの実行を開始します。 -
保存されたプラグインの状態が再活性化され、
SUCESS
またはFAILURE
の状態に達するまでプラグインの実行が再開されます。FAILURE
は、認証の試行に失敗したことを示します。その場合、OAMサーバーはユーザーの再認証を試みます。たとえば、ユーザーにログイン・フォームが表示されます。-
有効なサブジェクトが存在する場合、ユーザー・セッションが作成され、実行状態の保存に使用されます。それ以外の場合は、実行状態がリクエスト・オブジェクトに保存されます。このセッションには、グローバル(共通)システム構成によって構成された最低の認証レベルが割り当てられています。
-
ユーザー認証が終了すると、このセッションは完全に有効なセッションに更新され、認証スキームで定義された認証レベルとOAMサーバーに対して構成されたセッション・タイムアウトが割り当てられます。
-
-
動的フロー・コントローラ内のイベントの実行が終了すると、制御が親コントローラに戻り、実行状態が更新されます。
-
認証が完了すると、リクエストしたリソースへのアクセスが許可されます。
3.2.3 PAUSE状態について
マルチステップ認証モードでは、プラグインが資格証明を最初から収集することも、デフォルトのログイン・ページから取得した資格証明を使用したうえで必要に応じてさらに資格証明を収集することも可能です。チャレンジ・パラメータinitial_command=NONE
が認証スキームに設定されている場合、プラグインが直接制御することとなり、プラグインによって資格証明の収集が制御されます。
プラグインでは、PAUSE
ステータスを使用して、資格証明の収集の際にユーザーとやりとりできるようUserAction
パラメータを渡すことができます。1回以上クライアントに渡すことで、モジュールで必要なすべての資格証明を収集できます。PAUSE
実行の間、プラグインの実行状態およびコンテキスト・データは保存されます。制御がプラグインに戻ると、停止していた実行が再開され、収集されたすべてのデータがプラグインで使用できるようになります。
プラグインがPAUSE
状態に設定されている場合、プラグインでは次のことが可能です。
-
収集するデータの指定
-
リダイレクトまたは転送先のURLの指定
-
問合せ文字列の指定(存在する場合)
3.2.4 資格証明コレクタ・ページで共有される情報のタイプ
次のタイプの情報を資格証明コレクタ・ページに送ることができます。
3.2.4.1 UserContextData
-
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"));
3.2.4.3 UserAction
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);
3.3 プラグイン・インタフェースの概要
この項では次のトピックを記載しています:
3.3.1 プラグイン・インタフェースについて
このトピックでは、パッケージ、クラス、インタフェースおよび注釈の階層について概要を説明します。
カスタム・プラグイン実装には、プラグイン実装クラス・アーティファクトの記述が含まれます。プラグイン実装クラスは、AbstractAuthenticationPlugIn
クラスを拡張し、initialize
およびprocess
メソッドを実装する必要があります。カスタム・プラグイン実装者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。
プラグインの構成要件はXML形式で指定する必要があります。この構成データ(メタデータ)には、プラグイン名、作成者、作成日、バージョン、インタフェース・クラス、実装クラスおよび構成データが、属性/値ペアの形式で含まれます。新規のプラグイン名をマニフェスト・ファイルに追加する必要があります。ピリオド( . )は、プラグイン名として有効な文字ではありません。
このリリースのOAMは、次に説明する汎用プラグイン・インタフェースおよびより詳細な認証インタフェースを提供します。
3.3.1.1 GenericPluginServiceについて
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プラグインによって拡張される必要がある抽象プラグイン・クラスです。これは、プラグインの起動および停止メソッドのための基本実装を提供します。
3.3.1.2 AuthnPluginServiceについて
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
のインスタンスをプラグインに提供します。
3.4 サンプル・コード: カスタム・データベース・ユーザー認証プラグイン
この項では、データベース・ユーザー認証プラグインのサンプル実装のスナップショットを提供し、開発者タスクを示しています。この項の内容は次のとおりです。
3.4.2 プラグイン構成メタデータ要件のサンプル
プラグインの構成要件はXML形式で指定する必要があります。
この構成データ(メタデータ)には、プラグイン名、プラグイン作成者、作成日、プラグイン・バージョン、プラグイン・インタフェース・クラス、プラグイン実装クラスおよびプラグイン構成データが、属性/値ペアの形式で含まれます。
図3-11では、サンプル: データベース・ユーザー認証プラグイン実装のメタデータが含まれるXMLスキーマ定義(XSD)ファイルを示しています。
図3-11 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>
3.4.3 プラグインのサンプル・マニフェスト・ファイル
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>
3.4.4 プラグインJARファイル構造の理解
サンプル(データベース・ユーザー認証プラグイン)のJARファイル構造を次に示します。
-
<plugin>.xml
-
<plugin>.class (パッケージ構造、「プラグイン・インタフェースの概要」を参照)
-
META-INF (MANIFEST.MF)
3.4.5 プラグイン・フレームワークでサポートされるエラー・コード
プラグイン・フレームワーク(oracle.security.am.plugin.authn.AuthenticationErrorCode
)では、認証エラー・コードが公開されます。
表3-3 oracle.security.am.plugin.authn.AuthenticationErrorCode
プラグイン・フレームワークでサポートされるエラー・コード
エラー・コード | エラー・メッセージ |
---|---|
OAM-1001 | INVALID_USER |
OAM-1002 | AUTHENTICATION_FAILED |
OAM-1003 | INVALID_PASSWORD |
OAM-1004 | INTERNAL_ERROR |
OAM-1005 | UNSPECIFIED_ERROR |
OAM-1006 | USER_LOCKED_ERROR / DISABLED_USER |
OAM-1007 | USER_PASSWORD_EXPIRED |
OAM-1009 | IDSTORE_UNREACHABLE_ERROR |
OAM-10015 | INVALID_TENANT_NAME |
OAM-10016 | INVALID_OPERATION |
OAM-10017 | INVALID_REMEMBER_ME_TOKEN / CHALLENGES_NOT_DEFINED |
OAM-10018 | USER_PWD_CANNOT_CHANGE |
OAM-10019 | INVALID_CHALLENGE_RESPONSE |
OAM-10020 | CHALLENGES_DISABLED |
OAM-10021 | PASSWORD_MUST_CHANGE_WARNING |
OAM-10022 | PASSWORD_EXPIRE_WARNING |
他のカスタム・プラグインがこれらのエラー・コードを使用して、適切なカスタマイズ・アクションを実行できます。
3.5 認証プラグインの開発
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。
次の内容について説明します。
3.5.1 カスタム認証プラグインの記述について
カスタム・プラグイン実装の記述には、次を行うためのプラグイン実装クラスの記述が含まれます。
-
AbstractAuthenticationPlugIn
クラスの拡張(「プラグイン・インタフェースについて」を参照) -
initialize
メソッドの実装 -
process
メソッドの実装
表3-4では、プラグインの機能に必要なメソッドについて説明します。
表3-4 必要なプラグイン・メソッド
必要なメソッド | 説明 |
---|---|
initialize |
|
process |
さらに、
|
ノート:
カスタム・プラグイン開発者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。
次のヒントは、カスタム・プラグインを開発する助けになります。
-
プラグイン内部の外部JARには可視性がないため、WebLogicクラス・パスとプラグイン内部の両方に外部JARが必要です。
-
プラグインはWebLogicクラス・パスを使用せず、外部JAR用の独自のクラス・パスをマニフェスト・ファイルで定義しておく必要があります。たとえば、Bundle-ClassPathの場合は次のようになります。
,jndi-1.2.1.jar,ldap.jar,providerutil.jar,oaam_soap_client.jar,oaam_core.jar,oaam_uio.jar
-
パッケージ名は、マニフェスト・ファイルで個別に指定する必要があります。ワイルドカードはサポートされません。ネストされたパッケージもImport-Package:セクションで指定する必要があります。たとえば:
javax.naming;resolution:=optional,javax.naming.spi;resolution:=optional
-
プラグイン・アクティブ化時のバンドル制約例外を回避するには、
;resolution:=optional
をパッケージに配置します。 -
JARファイルがプラグイン内部とそのクラスパスに存在しない場合(WebLogicクラス・パスで利用できる場合も含む)、classnotfound例外を送出します。
-
JARファイルがWebLogicクラスパスで利用できない場合、タイプ・キャスト例外が送出されます。
3.5.2 カスタム認証プラグインの記述
この項では、カスタム認証プラグインの記述ステップを示します。次の概要では、システム・アーキテクトがこのプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討した後に開発者が実行する必要があるアクションについて説明します。詳細は、「計画、認証モデルおよびプラグインについて」を参照してください。
3.5.3 認証プラグインのエラー・コード
プラグインでログイン・ページ、エラー・ページまたはクライアント・アプリケーション・ページとデータをやり取りする必要がある場合は、このデータを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);