| Oracle® Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド 11g リリース1 (11.1.1) B66696-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド 11g リリース1 (11.1.1) B66696-01 |
|
前 |
次 |
OAMサーバーでは、保護対象とするリソースへのアクセスを制限するために、認証と認可の両方の制御が利用されます。認証は特定の認証スキームにより制御され、認証スキームは、ユーザーがリソースへのアクセス試行時に入力した資格証明をテストする、1つ以上のプラグインに依存します。プラグインは、OAMサーバーのインストールで提供される標準セット、または独自のJava開発者が作成したカスタム・プラグインから取得できます。
この章の内容は次のとおりです。
Oracle Access Manager 11gは、初期状態ですぐに使用できる認証モジュールの他に、次のものを提供します。
カスタマイズされた認証モジュール(プラグイン)を構築してデフォルトの機能を個々の要件に合せるための、認証プラグイン・インタフェースおよびSDKツールを提供します。新規インタフェースおよびSDKツールは次のとおりです。
Oracle Access Manager 10gのカスタム・プラグインをサポートするための下位互換性を提供します。
カスタム・プラグインを編成するための決定論的メソッドを認証モジュール内に含めます。
カスタマイズされた認証プラグインをOracle Access Manager 11gに素早くデプロイできるようにするメカニズムを提供します。
管理対象サーバーの状態ライフサイクルのプラグインすべてを保持し、これと同じものがAdminServerにも伝播されます。
資格証明コレクション用のカスタム・プラグインの作成が、認証のためにサポートされています(編成可能なステップ)。
図3-1では、カスタム・プラグインのデプロイ・タスクの概要を示しています。
次の概要では、カスタム・プラグインのデプロイ・タスクを識別しています。
タスク概要: カスタム・プラグイン要件のデプロイ
計画: 第3.1.2項「計画、認証モデルおよびプラグインについて」で説明しているように、このプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討します。
セキュリティ・アーキテクトは、Oracle Access Manager 11gの使用方法および顧客のユーザー・ベースを把握しています。システム・アーキテクトは、顧客の実装における改善点を識別できます。
開発:
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。
プラグインを記述します。
カスタム・モジュールのメタデータXMLを記述します。
マニフェストを作成します。
次のjarファイルをクラスパスに追加します: felix.jar、identitystore.jar、oam-plugin.jar、utilities.jar。
デプロイ:
Oracle Access Manager管理者は、複数のプラグインが認証モジュールで連携するようにデプロイおよび編成し、プラグインをテストおよびモニターします。
カスタム・プラグインの追加には、プラグイン・データ・ソースまたはドメインの構成、プラグインの配賦およびアクティブ化が含まれます。
カスタム・プラグインに対応したカスタム認証モジュールの作成には、ステップおよび結果(OnSuccess、OnFailureおよびOnError)の追加および編成が含まれます。
『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』の説明にあるように、Oracle Access Managerアクセス・テスターを使用してプラグインをテストします。
プラグインをモニターし、セキュリティ・アーキテクトまたはシステム・アーキテクトにフィードバックを提供して、ビジネス要件およびアーキテクチャに対するリビジョンを可能にします。
プラグインのライフ・サイクルは、OAMサーバーへのプラグインの追加およびプラグインを使用した機能の追加作成の機能を中心としています。これによりユーザーは、サーバーの拡張機能の役割を果たす標準(すぐに使用できる)プラグインおよびユーザーが追加したプラグインに基づいて、機能およびワークフローを作成できます。
次のリストは、標準的なプラグインのライフ・サイクルの概要を示しています。
計画
プラグイン開発時間、プラグイン・メタデータ・アーティファクトの生成が含まれます
プラグインのロードおよびライフサイクル
インポート: プラグインをOracle Access Managerにアップロードし、サーバーを再起動せずにこれを使用
配布: サーバーの停止時間なしで、プラグインjarを1つのローカルAdminServerファイル・システムからクラスタ内のすべての管理サーバーに伝播
アクティブ化: プラグインが認証モジュール・フローで使用される際に、このプラグイン実装を実行時にロード
プラグインのスタートアップ・パラメータまたは構成を使用
プラグイン構成データをoam-config.xmlにプッシュおよびプル
管理対象サーバーの状態ライフサイクルのすべてを保持し、これと同じものがAdminServerに伝播
デプロイされたプラグインの状態
プラグインのモニターおよび監査
プラグイン実行の所要時間およびプラグインの実行回数に関するマトリクス・データを収集
プラグイン入出力のマトリクス・データを収集
プラグイン実行開始時間および終了時間のマトリクス・データを収集
プラグインのライフサイクル・メソッド・コードの監査
新規プラグインJARが使用可能な場合、デプロイヤはこれをOracle Access Suiteのインポート・アクションからAdminServer DOMAIN_HOME/oam/pluginsにインポートできます。
表3-1では、Oracle Access Manager管理者が制御するプラグイン・ライフサイクルの状態を示しています。詳細は、第3.5項「カスタム・プラグインの追加」を参照してください。
表3-1 プラグイン・ライフサイクルの状態
| 状態 | 説明 |
|---|---|
|
インポート |
プラグインJARファイルをAdminServer DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。 |
|
配布 |
登録済のすべてのOAMサーバーにプラグインを伝播します。 |
|
アクティブ化 |
プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。 |
|
非アクティブ化 |
非アクティブ化では、oam-config.xmlのプラグイン・エントリ・フラグがチェックされます。 非アクティブ化プロセスでOAMサーバーに障害が発生した場合、非アクティブ化に失敗しましたというメッセージが伝播されます。 |
|
削除 |
AdminServerのDOMAIN_HOME/config/fmwconfig/oam/pluginsディレクトリから指定されたプラグイン(JAR)を削除し、AdminServerがすべてのOAMサーバーに通知します。 |
OAMサーバーのプラグインは、カスタム認証スキームの一部です。各種プラグインを次の目的に使用できます。
ユーザー・アイデンティティ・マッピング
プラグインにより、ログイン・ユーザー名の形式ではなくユーザー入力の形式に対応するための機能を追加できます。フィンガープリント、一連のセキュリティ質問およびその他の方法を使用できます。プラグインによりこれらの入力が翻訳され、データベースと照らしあわせてチェックされます。
ユーザー認証
ユーザーの認証時には、レスポンス(すぐに使用できる提供なし)が必要となる場合があります。カスタム・プラグインによりこのニーズに応えることができます。
カスタム・レスポンス
レスポンスおよびこれらのレスポンスが残りのシステムと対話する方法について、カスタム・プラグインを使用できます。
その他のタイプのプラグインもサポート
図3-2は、ユーザーが保護されたリソースをリクエストした場合の認証フローを示しています。認証はプロセスであり、プロトコルではありません。緑色の矢印は、OAMサーバーにデプロイされたプラグインによって生成されたカスタム・レスポンスです。
カスタム認証プラグインを設計および開発する前に、開発者はOracle Access Manager認証決定プロセスを綿密に分析し、ユーザーをどのように認証する必要があるかを確認することをお薦めします。
あるリクエストを受け取った場合、これを処理するには2通りの方法が考えられます。1つは、リクエストの属性に応じて特定のスキームを実行する方法であり、デシジョン・エンジンを使用して1つ以上のスキームを実行し、ユーザーを正しく認証します。これは、各スキーム内のコードが少なくて済み、モジュール性が高くなります。もう1つのオプションは、特定の目的でリクエストの様々な属性を処理するためにすべてのスキームをハードコードする方法であり、デジション・エンジンを使用せずに、どのスキームを実行する必要があるかを全体から把握します(1つのスキームのみ実行されます)。
例: デジション・エンジン対ハードコード認証
ユーザーが夜中に自宅のコンピュータを使用して、オンラインバンクの口座にログインすると仮定します。次の概要では、デシジョン・エンジンおよびハードコードのそれぞれの方法における処理の相違点を説明しています。開発者は、どの方法が要件に最も合うかを判断する必要があります。
プロセスの概要: デシジョン・エンジンを使用する方法
2つの方法の相違点は単純ですが、重要です。
夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。
デシジョン・エンジンにより、このIPアドレスが以前処理されたことが確認されます。また、夜中に認証を試みるユーザーは疑わしいと判断され、ユーザーはユーザー名およびパスワードだけでなく、セキュリティ質問に回答することが要求されます。
指定されたユーザーに対してセキュリティ質問スキームが実行され、成功します。これは、デジション・エンジンによって選択された2つの認証スキームのうちの1つ目です。
ユーザーパスワード・スキームが実行され、ユーザーは正常に認証されます。これは、デジション・エンジンによって選択された2つ目の認証スキームです。
プロセスの概要: ハードコードを使用する方法
夜中に、あるIPアドレスを持つユーザーからリクエストを受け取ります。
オンラインバンク口座のアクセス・スキームが他の認証スキーム(クレジット・カード・アクセス・スキーム、新規口座作成および検証など)の中から選択されます。
このスキームでは最初にIPアドレスがチェックされ、ユーザーが以前このコンピュータから接続を試みたことがあるかどうかが確認されます。ユーザーが以前そうしたと確認されます。
スキームにより時間がチェックされます。セキュリティ質問の回答が要求され、正しく回答されます。
スキームによりユーザーはログイン資格証明の入力が要求され、正常に認証されます。
どちらの方法にも、それぞれメリットとデメリットがあります。デシジョンエンジン・モデルの場合、コードの再利用が主なメリットですが、ハードコードを使用した方法はセキュリティが向上する場合があります。開発者は、どの方法を選択するかを決定する必要があります。
ここでは、次の内容について説明します。
このトピックでは、パッケージ、クラス、インタフェースおよび注釈の階層について概要を説明します。
カスタム・プラグイン実装には、プラグイン実装クラス・アーティファクトの記述が含まれます。プラグイン実装クラスは、AbstractAuthenticationPlugInクラスを拡張し、initializeおよびprocessメソッドを実装する必要があります。カスタム・プラグイン実装者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。
プラグインの構成要件はXML形式で指定する必要があります。この構成データ(メタデータ)には、プラグイン名、作成者、作成日、バージョン、インタフェース・クラス、実装クラスおよび構成データが、属性/値ペアの形式で含まれます。
Oracle Access Manager 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 Managementプラグインによって拡張される必要がある抽象プラグイン・クラスです。これは、プラグインの起動および停止メソッドのための基本実装を提供します。
|
参照: Oracle Fusion Middleware Oracle Access Manager 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 Manager Java APIリファレンス |
この項では、データベース・ユーザー認証プラグインのサンプル実装のスナップショットを提供し、開発者タスクを示しています。この項の内容は次のとおりです。
次の各図では、データベース・ユーザー認証プラグインのサンプル実装を3つの部分に分けて示しています。
|
参照: Oracle Fusion Middleware Oracle Access Manager Java APIリファレンス |
続く..
続く...
プラグインの構成要件はXML形式で指定する必要があります。
この構成データ(メタデータ)には、プラグイン名、プラグイン作成者、作成日、プラグイン・バージョン、プラグイン・インタフェース・クラス、プラグイン実装クラスおよびプラグイン構成データが、属性/値ペアの形式で含まれます。
図3-11では、サンプル: データベース・ユーザー認証プラグイン実装のメタデータが含まれるXMLスキーマ定義(XSD)ファイルを示しています。
図3-12では、サンプル: データベース・ユーザー認証プラグインのXMLメタデータを示しています。
図3-13では、データベース・ユーザー認証プラグイン・サンプルのMANIFEST.MFファイルを示しています。
サンプル(データベース・ユーザー認証プラグイン)のJARファイル構造を次に示します。
<plugin>.xml
<plugin>.class (パッケージ構造、第3.2項「プラグイン・インタフェースの概要」を参照)
META-INF (MANIFEST.MF)
開発者は、セキュリティ・アーキテクトが共通ライブラリを使用して実際のプラグインに設計した内容を翻訳し、カスタム認証モジュールをインタフェースします。
この項では、Oracle Access Manager 11g認証スキームで使用する認証プラグインの開発について説明します。内容は次のとおりです。
カスタム・プラグイン実装の記述には、次を行うためのプラグイン実装クラスの記述が含まれます。
AbstractAuthenticationPlugInクラスの拡張(第3.2.1項「プラグイン・インタフェースについて」を参照)
initializeメソッドの実装
processメソッドの実装
表3-3では、プラグインの機能に必要なメソッドについて説明します。
表3-3 必要なプラグイン・メソッド
| 必要なメソッド | 説明 |
|---|---|
|
initialize |
|
|
process |
さらに、
|
|
注意: カスタム・プラグイン開発者は、実際のカスタム認証処理ロジックをこのメソッドに実装し、最終的な認証実行ステータスを戻す必要があります。 |
この項では、カスタム認証プラグインの記述ステップを示します。
次の概要では、システム・アーキテクトがこのプラグインのビジネス要件を識別し、ユーザーがリソースをリクエストした場合の認証フローを検討した後に開発者が実行する必要があるアクションについて説明します。詳細は、第3.1.2項「計画、認証モデルおよびプラグインについて」を参照してください。
前提条件
サンプル・コード: カスタム・データベース・ユーザー認証プラグイン
タスクの概要: 開発者によるカスタム認証プラグインの記述
AbstractAuthenticationPlugInクラスを拡張し、次のメソッドを実装します(第3.4.1項「カスタム認証プラグインの記述について」も参照)。
initializeメソッドの実装
processメソッドの実装
適切なOracle Access Manager 11gインタフェースおよびパッケージを使用して、プラグイン・コードを開発します。参照:
カスタム・プラグインのメタデータを作成します。参照:
プラグインJarファイルおよびマニフェストを作成し、これらをデプロイ・チームに引き継ぎます。参照:
次に進みます。
カスタム認証プラグインのコンパイルには、複数のJARファイルが必要です。次のjarがあります。
extensibility_lifecycle.jar
. felix.jar
.felix-service.jar
oam-plugin.jar
これらのJARファイルは、次のパスに置かれています。
DOMAIN_HOME/servers/MANAGED_INSTANCE_NAME/tmp/_WL_user/oam_server/RANDOM_STRING /APP-INF/lib
ここでは、次の内容について説明します。
カスタム認証プラグインは、カスタム認証モジュールで作成および使用し、同様に認証スキームで使用できます。
プラグインの開発後、JARファイルとして管理サーバーにデプロイする必要があり、自動的に検証されます。検証後、管理者はOracle Access Suiteを使用してプラグインを構成および配布できます。
サーバーは、プラグインJARファイル内のXML構成ファイルを処理し、プラグインに関するデータを抽出します。プラグインがインポートされた後、管理者はAdminServerから使用できる情報に基づいて様々なプラグインの状態を参照し、変更できます。
図3-14は、「システム構成」タブの「共通構成」セクションにあるプラグイン・ノードおよびプラグイン・ページを示しています。このページに含まれるツールバーのコマンド・ボタンは、その多くが表で選択されたプラグインに作用します。この表は、既存のカスタム・プラグインとその状態に関する情報を提供します。ページ最下部の「プラグインの詳細」セクションは、表内の選択されたプラグインの構成詳細を反映しています。
表3-4に示すように、管理者はプラグイン・ページ上部の表の上にあるコマンド・ボタンを使用して、プラグインの状態を制御します。
表3-4 カスタム・プラグインの管理アクション
| アクション | 説明 |
|---|---|
|
プラグインのインポート  |
プラグインJARファイルをAdminServer DOMAIN_HOME/oam/pluginsに追加し、プラグインの検証を開始します。
成功時: ステータスが「アップロード済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アップロード済」と報告し、AdminServerにおけるステータスも「アップロード済」となります。 失敗時: ステータスは「アップロードに失敗しました」と報告されます。 関連項目: 『Oracle Fusion Middleware Oracle Access ManagerおよびOracle Security Token Service開発者ガイド』の「カスタム・プラグインのライフ・サイクルについて」 |
|
選択項目の配布  |
成功時: ステータスが「配布済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「配布済」と報告し、AdminServerにおけるステータスも「配布済」となります。 失敗時: ステータスは「配布に失敗しました」と報告されます。 |
|
選択項目のアクティブ化  |
プラグインは、正常に配布された後、登録済のすべてのOAMサーバーでアクティブ化できます。 アクティブ化:
成功時: ステータスが「アクティブ化済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「アクティブ化済」と報告し、AdminServerにおけるステータスも「アクティブ化済」となります。 失敗時: ステータスは「アクティブ化に失敗しました」と報告されます。 すべてのOAMサーバーについてアクティブ化した後、認証モジュールの作成または編成でプラグインを使用および実行できます。 |
|
選択項目の非アクティブ化  |
プラグインをアクティブ化した後で、管理者はプラグインが認証モジュールまたはスキームで使用されていない場合などに、プラグインの非アクティブ化を選択できます。登録済のすべてのOAMサーバーから選択されたプラグイン。 非アクティブ化:
成功時: ステータスが「非アクティブ化」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「非アクティブ化」と報告し、AdminServerにおけるステータスも「非アクティブ化」となります。oam-config.xmlからプラグイン構成が削除されます。 注意: 非アクティブ化の後は、認証モジュールまたは編成でプラグインを使用または実行できません。 失敗時: ステータスは「非アクティブ化に失敗しました」と報告されます。 |
|
選択項目の削除  |
プラグインを非アクティブ化した後、管理者は選択したプラグインを削除できます。このプロセスでは、Oracle Access Managerは次の処理を実行します。 削除:
成功時: ステータスが「削除済」として報告されます(OAMサーバーが停止している場合も同様)。登録されたすべてのOAMサーバーが「削除済」と報告し、AdminServerにおけるステータスも「削除済」となります。oam-config.xmlからプラグイン構成が削除されます。 失敗時: ステータスは「削除に失敗しました」と報告されます。 |
表3-4では、プラグイン・ステータス表の要素について説明します。
表3-5 プラグイン・ステータス表の要素
| 要素 | 説明 |
|---|---|
|
プラグイン名 |
XMLメタデータ・ファイルのプラグイン名要素から抽出されます。 |
|
説明 |
XMLメタデータ・ファイルの説明要素から抽出されます。 |
|
アクティブ化のステータス |
AdminServerの情報に基づいてアクティブ化のステータスが報告されます。 |
|
タイプ |
XMLメタデータ・ファイルのタイプ要素から抽出されます。 |
|
最終更新日 |
XMLメタデータ・ファイルの作成日要素から抽出されます。 |
|
最終更新者 |
XMLメタデータ・ファイルの作成者要素から抽出されます。 |
このページの「プラグインの詳細」セクションでは、表3-6に示すように、「アクティブ化のステータス」がAdminServerによって維持されます。
プラグインによっては、様々な構成詳細がXMLメタデータ・ファイルの構成要素から抽出され、「プラグインの詳細」セクションの「構成パラメータ」に移入されます。表3-6に例を示します。
有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。
前提条件
カスタム認証プラグインを追加する手順は、次のとおりです。
プラグインをインポートします。
Oracle Access Suiteにアクセスし、通常どおりログインします。次に例を示します。
https://hostname:port/oamconsole/
「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。
「プラグインのインポート」ボタンをクリックします。
「プラグインのインポート」ダイアログ・ボックスで、「参照」をクリックしてプラグインJARファイルの名前を選択します。
ダイアログ・ボックスのメッセージを確認し、「インポート」をクリックします。
『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』で説明しているように、JARファイルが検証されます。
パラメータの構成: 「プラグインの詳細」セクションを開き、「構成パラメータ」をクリックして、必要に応じて適切な情報を入力します。次に例を示します。
プラグインをOAMサーバーに配布します。
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目の配布」ボタンをクリックし、「アクティブ化のステータス」をチェックします。
プラグイン(およびカスタム・プラグイン実装クラス)をアクティブ化し、OAMサーバーで使用できるようにします。
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目のアクティブ化」ボタンをクリックし、「アクティブ化のステータス」をチェックします。
必要に応じて次のタスクを実行します。
有効な管理者資格証明を持つユーザーは、次のタスクを実行して、カスタム・プラグインを追加、検証、配布およびアクティブ化できます。
前提条件
カスタム認証プラグインのアクティブ化ステータスをチェックする手順は、次のとおりです。
「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。
プラグイン表で、目的のプラグイン名をクリックして選択します。
サーバー・インスタンス名: 「プラグインの詳細」セクションを開き、「アクティブ化のステータス」をクリックしてプラグインの場所とステータスを表示します。次に例を示します。
必要に応じて次のタスクを実行します。
有効な管理者資格証明を持つユーザーは、次の手順を使用してカスタム・プラグインを非アクティブ化してから削除できます。
管理者がカスタム認証プラグインを削除した場合、その名前はプラグインのリストから削除されません。プラグインを削除するには(同じプラグインを後で再インポートするため)、管理者はWebLogic Serverを停止し、oam-config.xmlを手動で編集する必要があります。
前提条件
カスタム認証プラグインを削除する手順は、次のとおりです。
Oracle Access Suiteにアクセスし、通常どおりログインします。次に例を示します。
https://hostname:port/oamconsole/
「システム構成」タブの「共通構成」セクションから、「プラグイン」をクリックし、「アクション」メニューから開くをクリックします。
プラグインの非アクティブ化: プラグインを削除する前に、これを実行する必要があります。
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目の非アクティブ化」ボタンをクリックし、プラグインの「アクティブ化のステータス」をチェックします。
非アクティブ化したプラグインの削除:
プラグイン表で、プラグイン名をクリックして選択します。
「選択項目の削除」ボタンをクリックします。
WebLogic管理サーバーを停止し、oam-config.xmlの場所を確認し手動で編集して、非アクティブ化したプラグインを削除してから、WebLogic管理サーバーを再起動します。
必要に応じて次のタスクを実行します。
ここでは、次の内容について説明します。
「システム構成」ナビゲーション・ツリーの「Access Managerの設定」セクションには、認証モジュール・ノードが含まれます。カスタム認証モジュールを作成する場合、モジュールに必要な情報のタイプごとにサブタブが表示されます。
一般
ステップ
ステップ編成
図3-16では、「システム構成」ナビゲーション・ツリーの「Access Managerの設定」セクションの認証モジュール・ノードと、モジュールの情報を入力する3つのサブタブを示しています。
「一般」サブタブには、モジュール名およびオプションの説明を入力するスペースがあります。名前は、最大60文字で指定できます。オプションの説明は、最大250文字で指定できます。
図3-17では、カスタム認証モジュールに関する「ステップ」サブタブおよび「詳細」セクションを示しています。「ステップの詳細」の下の「プラグイン・パラメータ」として、ステップごとに有効な値のみが受け入れられます。無効な値は、カスタム認証モジュールを保存する際にエラーとなります。ステップを追加する際には、表に表示するデータはありません。ただし、1つ以上のステップがあれば、表および「詳細」セクションは移入されます。
新規ステップを追加すると、次のダイアログ・ボックスが表示されます。表3-7に示すように、入力した情報はページの表および「詳細」セクションの移入に使用されます。
表3-7では、新規ステップの追加に必要な情報を説明しています。
表3-7 「新規ステップの追加」のエントリ、ステップ結果表および「詳細」セクション
| 要素 | 説明 |
|---|---|
|
ステップ名 |
このステップの追加時に入力された名前。 |
|
説明 |
このステップの追加時に入力された、このステップのオプションの説明。 |
|
プラグイン名 |
このステップの追加時に選択されたプラグイン名。 |
|
ステップの詳細 |
結果表の選択済ステップの詳細、プラグインの追加およびアクティブ化の際に設定されたプラグイン構成詳細。 |
図3-19では、カスタム認証モジュールの「ステップ編成」サブタブを示しており、ここでは定義済の各ステップ(および各操作条件について選択したアクション)の情報が移入されます。
表3-8では、「ステップ編成」サブタブの要素を説明します。OnSuccess、OnFailureおよびOnErrorで使用できるリストには、次の選択肢が含まれます。
success
failure
StepName (モジュール内のステップは、操作条件に対するアクションとして選択できます)
有効な管理者資格証明を持つユーザーは、次の手順を使用して、Oracle Access Suiteにインポートされアクティブ化された1つ以上のカスタム認証プラグインを使用する認証モジュールを作成できます。
|
注意: テンプレートとして使用する既存のカスタム・モジュールは複製できません。 |
前提条件
カスタム・プラグインを使用するカスタム認証モジュールを作成する手順は、次のとおりです。
「システム構成」タブの「Access Managerの設定」セクションから、認証モジュール・ノードを開きます。
ナビゲーション・ツリーから、「カスタム認証モジュール」をクリックします。
ツールバーの「作成」ボタンをクリックします。
一般情報(「名前」およびオプションの「説明」)を追加します。
モジュールにステップを追加します。
「ステップ」サブタブをクリックします。
ステップ表の上の「追加」ボタンをクリックします。
「新規ステップの追加」ダイアログ・ボックスで、「ステップ名」およびオプションの「説明」を入力します。
目的のカスタム・プラグイン名を参照して選択し、「OK」をクリックします。
結果表の情報を確認します。
bからeまでを繰り返し、このモジュールの必要なすべてのプラグインがリストされるまで、他のステップを追加します。
各ステップの構成: リクエストされたパラメータに適切な値を使用します。
表の「StepName」をクリックし、必要な詳細を表示します。
リクエストされたパラメータの有効な値を入力します。
「保存」ボタンをクリックします。
aからcまでを繰り返し、各ステップを適切に構成します。
ステップの使用方法を編成します。
「ステップ編成」サブタブをクリックします。
InitialStepリストから、使用する最初のステップの名前を選択します。
表の「StepName」を選択します。
OnSuccessリストから、条件(成功または失敗)またはステップ名を選択します。
OnFailureリストから、目的の条件またはStepNameを選択します。
OnErrorリストから、目的の条件またはStepNameを選択します。
cからeまでを繰り返し、このモジュール内の各プラグインの操作を編成します。
編成を確認します。
方針の検証の開始: 「適用」をクリックし、編成方針の検証を開始します。
正常な方針: 編成方針が適用され、モジュールが認証スキームに含められるようになります。ステップ9および10に進みます。
無効な方針: 「エラー」ボックスで「OK」をクリックしてから、OnSuccess、OnFailure、OnErrorの方針を編集(あるいはプラグインを追加または削除)し、問題を修正します。方針が正常になるまでこのステップを繰り返します。
ナビゲーション・ツリーで、新しいカスタム認証モジュールがリストされていることを確認し、ページを閉じて終了します。
有効な管理者資格証明を持つユーザーは、次の手順を使用して、カスタム認証モジュールを含む新規認証スキームを作成できます。
これは、標準認証モジュールを含む認証スキームを作成する際に使用する手順と基本的には同じです。唯一の相違点は、カスタム・プラグインを使用するために定義された編成済ステップを含む認証モジュールを選択できることです。
|
参照: 『Oracle Fusion Middleware Oracle Access Manager with Oracle Security Token Service管理者ガイド』の認証スキームに関する詳細 |
前提条件
カスタム認証スキームを作成する手順は、次のとおりです。
「ポリシー構成」タブのナビゲーション・ツリーから「共有コンポーネント」ノードを拡張します。
「認証スキーム」ノードをクリックし、ツールバーの「作成」ボタンをクリックします。
新規の認証スキーム・ページに入力します。
名前
説明
認証レベル
デフォルト
チャレンジ・メソッド
チャレンジ・リダイレクト
認証モジュール(カスタム・プラグインがあるものを含む)
「適用」をクリックして新しいスキームを送信します(または変更を適用しないでページを閉じます)。
確認ウィンドウを閉じます。
オプション: 「デフォルトとして設定」ボタンをクリックして、新しいアプリケーション・ドメインでこれを自動的に使用し、確認ウィンドウを閉じます。
ナビゲーション・ツリーで、新しいスキームがリストされていることを確認し、ページを閉じます。
Oracle Access Manager with Oracle Security Token Serviceは、WebLogic Serverコンテナのロギング・デフォルトを使用します。カスタム・プラグインの必要な属性とともに、Oracle Access Manager固有のカスタム・ログ出力およびログ・ハンドラを指定するには、ここで説明するようにWLSTコマンドを使用できます。
|
参照: Oracle Security Token Serviceを伴うOracle Fusion Middleware Oracle Access Manager管理者ガイド |
カスタム・プラグインのログ出力およびハンドラを変更する手順は、次のとおりです。
OAMサーバーが稼動中であることを確認します。
Oracle Access Manager用のカスタムWLSTスクリプトを取得します。次に例を示します。
<ORACLE_HOME>/common/bin/wlst.sh
WebLogic Serverに接続してWebLogic管理者としてログインします。次に例を示します。
sh wlst.sh wls:/offline> connect ('adminID','password','adminURL')
カスタム・プラグインの使用可能なログ出力をリストします。次に例を示します。
wls:/base_domain/serverConfig> listLoggers(pattern="oracle.oam.*",target="oam_ server1")
ここで、pattern=はoam.controllerコンポーネントを表し、target=は希望のOAMサーバー(登録時に指定されたもの)を表します。
このOAMサーバーに関連付けられているOracle Access Managerログ出力のリストを表示します。次に例を示します。
Logger | Level --------------------------------------------+----------------- oracle.oam | <Inherited> oracle.oam.commonutil | <Inherited> oracle.oam.config | <Inherited> oracle.oam.controller | <Inherited> ...
自身の要求に基づいてoracle.oam.controllerログ・レベルを変更します。たとえば、TRACE:32(永続性なし)は次のようになります。
wls:/base_domain/serverConfig> domainRuntime() wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam.controller", level="TRACE:32", persist="0", target="oam_server1")
ステップ4を繰り返して再びロガーをリストし、ログ・レベルの変更を確認します。次に例を示します。
wls:/base_domain/serverConfig> listLoggers(pattern="oracle.oam.*",target="oam_ server1")
Logger | Level --------------------------------------------+----------------- oracle.oam | <Inherited> oracle.oam.commonutil | <Inherited> oracle.oam.config | <Inherited> oracle.oam.controller | TRACE:32 ...
生成されたログ・ファイルを検証して、コントローラが指定レベルでロギングされていることを確認します。
DOMAIN_HOME/server/SERVER_INSTNCE_NAME/logs/
次のように、Oracle Access Manager固有のカスタム・ログ出力およびログ・ハンドラを追加し、ログ・ファイル・パスおよび必要な属性を指定します。
次のようにOAMログ出力を追加します。
wls:/base_domain/serverConfig> domainRuntime> wls:/base_domain/domainRuntime> setLogLevel(logger="oracle.oam",level="WAR NING", persist="0", target="oam_server1")
次に示すように、カスタム・ログ・ハンドラを追加して、それにOAMログ出力を関連付けます。
wls:/base_domain/domainRuntime> configureLogHandler(name="oam-log-handler",
target="oam_server1", rotationFrequency="daily", retentionPeriod="week",
path="${domain.home}/oamlogs", maxFileSize ="10485760", maxLogSize =
"104857600",addHandler="true", handlerType="oracle.core.ojdl.logging.ODLHan
dlerFactory", addToLogger="oracle.oam")
wls:/base_domain/domainRuntime>configureLogHandler(name="oam-log-handler",
addProperty="true", propertyName="supplementalAttributes",
propertyValue="OAM.USER, OAM.COMPONENT", target="oam_server1")
DOMAIN_HOME/oamlogsフォルダにすべてのOAMログが表示されていることを確認します。
生成されたログ・ファイルを検証して、コントローラがTRACE:32レベルでロギングされていることを確認します。
DOMAIN_HOME/server/SERVER_INSTNCE_NAME/logs/
