24.7 パスワード・ポリシー認証の構成

パスワード・ポリシー、デフォルト・ストアおよび管理者の準備が完了すると、認証モジュールと認証スキームを開発できます。

パスワード・ポリシー検証認証モジュール
PasswordPolicyValidationSchemeの構成
ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加: DCCを使用している場合は、このトピックをスキップして、「DCC対応の11g Webゲートと認証ポリシーの構成」に進みます。
認証前ルールによるDCC認証スキームのサポート

24.7.1 パスワード・ポリシー検証認証モジュール

デフォルト・ストアを使用するには、パスワード・ポリシー検証認証モジュールも構成する必要があります。

ノート:

認証用のパスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。

サンプル・モジュールを図24-2に示します。ユーザー・パスワードのステータス・ステップは、UserPasswordPolicyPluginに基づく一意のステップです。

ノート:

UserPasswordPolicyPluginは、LDAPベースの認証モジュールを使用する場合にのみサポートされます。非LDAP認証モジュールを使用する場合は使用できません。

図24-2 パスワード・ポリシー検証認証モジュールと編成済プラグイン

「図24-2 パスワード・ポリシー検証認証モジュールと編成済プラグイン」の説明

各ステップは、特定の名前付きプラグインが提供するアクションを特定します。

関連項目:

「プラグイン・ベースのモジュールによるマルチステップ認証の編成」。

図24-3は、認証モジュール内でのステップの編成を示しています。モジュールおよびステップの詳細は、「マルチステップ認証モジュールによるAccess Managerの構成のための事前移入済プラグイン」を参照してください。

図24-3 パスワード・ポリシー検証モジュールのステップ編成

「図24-3 パスワード・ポリシー検証モジュールのステップ編成」の説明

表24-8では、指定したパスワード・ポリシー検証モジュール・ステップの詳細を説明します。

表24-8 ユーザー・パスワード・ステップの詳細

ステップ名	ステップの詳細	説明
ユーザー識別ステップ	KEY_LDAP_FILTER	KEY_LDAP_FILTER属性にLDAPフィルタを追加します。LDAP検索フィルタの定義に使用できるのは、標準LDAP属性のみです。次に例を示します。 (uid={KEY_USERNAME}) 関連項目: アイデンティティ・ストアの正確な構文については、表25-15およびベンダーのドキュメントを参照してください。
ユーザー識別ステップ	KEY_IDENTITY_STORE_REF	モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。デフォルト: 登録済デフォルト・ストア
ユーザー識別ステップ	KEY_SEARCH_BASE_URL	ユーザーの検索のベースURL。次に例を示します。 dc=us,dc=example,dc=com
ユーザー認証ステップ	KEY_IDENTITY_STORE_REF	モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。デフォルト: 登録済デフォルト・ストア
ユーザー認証ステップ	KEY_PROP_AUTHN_EXCEPTION	LDAPエラーの伝播を有効または無効にします。認証モジュールでプラグイン実行の次のステップが「パスワード・ポリシー・プラグイン」である場合は、KEY_PROP_AUTHN_EXCEPTIONをTRUEに設定する必要があります。たとえば、モジュールで、認証プラグイン→パスワード・プラグインである場合は、このパラメータをTRUEに変更します。
ユーザー・パスワード・ステータス・ステップ	PLUGIN_EXECUTION_MODE	プラグインの実行モード。このプラグインは、構成に従って、単独または他のプラグインとともに動作可能です。値は次のいずれかになります。 PSWDONLY: パスワードのステータスのみを決定する、最も推奨される構成です。IDと認証は、UserIdentificationおよびUserAuthenticationプラグインを使用して実行する必要があります。 AUTHWITHPSWD: このプラグインの実行によって、認証とパスワードの両方が実行されます。 AUTHONLY: ユーザーの識別と認可はこのプラグインを使用した場合にのみ実行されます。デフォルト: PSWDONLY
ユーザー・パスワード・ステータス・ステップ	OBJECTCLASS_EXTENSION_SUPPORTED	オブジェクト・クラス"oblixpersonpwdpolicy"および"oblixorgperson"は、このプラグインを正常に実行するために、OAMユーザーのエントリに存在する必要があります。このパラメータがFALSEの場合、プラグインはこれらのオブジェクト・クラスに追加されません。このパラメータがTRUEの場合、プラグインはこれらのオブジェクト・クラスをユーザーのエントリに追加することを試みます(現在のユーザーのエントリにそれらがまだ存在しない場合)。デフォルト: FALSE
ユーザー・パスワード・ステータス・ステップ	KEY_IDENTITY_STORE_REF	モジュール・ユーザーを含んだ、登録済アイデンティティ・ストアの名前。デフォルト: 登録済デフォルト・ストア
ユーザー・パスワード・ステータス・ステップ	NEW_USERPSWD_BEHAVIOR	新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。値は、次のいずれかになります。 FORCEPASSWORDCHANGE: パスワード変更を強制します。 NOFORCEPASSWORDCHANGE: パスワードのポリシー変更は、設定済のユーザー・パスワードには影響しません。デフォルト: NOFORCEPASSWORDCHANGE
ユーザー・パスワード・ステータス・ステップ	POLICY_SCHEMA	パスワード・サービスのポリシー・スキーマ。現在はOAM10Gのみがサポートされています。デフォルト: OAM10G
ユーザー・パスワード・ステータス・ステップ	URL_ACTION	ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。 REDIRECT_POST REDIRECT_GET FORWARD デフォルト: REDIRECT_POST
ユーザー・パスワード・ステータス・ステップ	DISABLED_STATUS_SUPPORT	無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。デフォルト: TRUE

前提条件

グローバル・パスワード・ポリシーの定義

ノート:

パスワード・ポリシー検証モジュールを定義するときには、資格証明コレクタの依存性はありません。3つの各プラグイン/ステップのKEY_IDSTORE_REFとしてデフォルト・ストアを入力します(失敗時のエラーのリダイレクトも指定します)。

Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「認証モジュール」をクリックします。
「認証モジュール」ページで、「検索」→パスワード・ポリシー認証モジュールの順にクリックします。
「ステップ」タブを選択し、3つのステップのそれぞれについて、KEY_IDSTORE_REFの横のフィールドでデフォルト・ストア名を追加します(変更のたびに保存してください)。次に例を示します。
1. ユーザー識別ステップ
  
  KEY_IDSTORE_REF: OID
  
  保存します。
2. ユーザー認証ステップ
  
  KEY_IDSTORE_REF: OID
  
  保存します。
3. ユーザー・パスワード・ステータス・ステップ
  
  KEY_IDSTORE_REF: OID
  
  保存します。
「適用」をクリックします。
「PasswordPolicyValidationSchemeの構成」に進みます。

24.7.2 PasswordPolicyValidationSchemeの構成

管理者の資格証明を持つユーザーは、PasswordPolicyValidationSchemeを構成できます。

グローバル・パスワード・ポリシーには複数の認証スキームを使用することができます。

ノート:

ECCとDCCの値の相違点(表24-3)には、次の項目が含まれます。

チャレンジ・リダイレクトURL: 資格証明コレクタのホストとポート
チャレンジURL: 資格証明コレクタのページ
チャレンジ・パラメータ: 表22-22

前提条件

パスワード・ポリシー検証認証モジュール

ECCチャレンジ・パラメータ	DCCチャレンジ・パラメータ
`OverrideRetryLimit=0` `initial_command=NONE`	`OverrideRetryLimit=0` `creds=userid password` 関連項目: 表22-23 `action` 指定していない場合、ECCとDCCは、どちらもデフォルトの/oam/server/auth_cred_submitになります。 `DCCCtxCookieMaxLength` (デフォルトは4096) `TempStateMode` パラメータ値での指定に応じて、DCCがOAMサーバーの状態をCookieで格納するか、フォーム(デフォルト)で格納するかを制御します。 `MaxPostDataBytes`ユーザーの資格証明として送信さるPOSTデータの最大バイト数を制限します。 `creds` 『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、渡す内容を`ObUserSession`オブジェクトの`obMap`資格証明パラメータで指定する必要があります。

24.7.3 ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加

管理権限を持つユーザーは、保護Webゲート(リソースWebゲート)のアプリケーション・ドメインで、ECC用に構成したPasswordPolicyValidationSchemeを使用できます。

前提条件

PasswordPolicyValidationSchemeの構成

ECC: コンソールで、該当するアプリケーション・ドメインを検索して開きます。(「既存のアプリケーション・ドメインの検索」を参照)。

関連項目:
「ECC認証ポリシーへのPasswordPolicyValidationSchemeの追加」
ECC: PasswordPolicyValidationSchemeを使用してリソースを保護します。
1. 「認証ポリシー」タブで保護されたリソース・ポリシーを探して開きます(「認証ポリシーの表示または編集」を参照)。
  - 認証ポリシー
  - 保護されたリソース・ポリシー
2. 保護されたリソース・ポリシー(認証スキーム)の「PasswordPolicyValidationScheme」を選択して、「適用」をクリックします。
3. 必要に応じて、認証ポリシーと認可ポリシーの更新を終了します(「リソースの保護およびSSOの有効化ポリシーの管理」)。
使用する環境の必要に応じて次に進みます:
- ECC: 「パスワード・ポリシー構成の完了」
- DCC: 「DCC対応の11g Webゲートと認証ポリシーの構成」

24.7.4 認証前ルールによるDCC認証スキームのサポート

DCC認証スキームが使用される場合は、認証前ルールで、様々なプロキシからの内部URLと外部URLとを区別できません。DCC認証スキームをサポートするには、returnHostパラメータを使用して新しい認証前ルールを作成する必要があります。

認証前ルールでは、ユーザーへのアクセスをブロックできるポリシー、または特定の条件に基づいてOAMで異なる認証スキームを使用できるようにするポリシーを定義できます。

リクエスト・データ内のhostパラメータにより、認証前ルールを保護されたリソースのホスト名に対して実行できます。リクエストがDCC WebGateから発生している場合、hostパラメータでは、様々なプロキシからの内部URLと外部URLとを区別できません。DCC WebGateをプロキシと機能させる必要がある場合は、次のように、新しい認証前ルールを作成する必要があります。

request.returnHost.lower().find('<proxy_host_name>')>0

returnHostパラメータには、リクエストがECCまたはDCC WebGateから発生しているかどうかに関係なく、内部URLと外部URLのプロキシ・ホスト名があります。指定したプロキシを介してリソースにアクセスすると、認証スキームが、新しい認証前ルールで指定したとおりに切り替えられます。構成されているその他のプロキシの場合は、「認証ポリシー」タブで指定されている元の認証スキームのままになります。