| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Access Management管理者ガイド 11g リリース2 (11.1.2.3) for All Platforms E61950-08 |
|
|
前 |
次 |
コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。
ノート:
カスタム認証モジュールの作成には、認証プラグインを使用するようにお薦めします。
この項では次のトピックを記載しています:
関連項目:
カスタム認証プラグインを作成する場合は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。
単純フォームベースの認証は、デフォルトであるため、フォームをカスタマイズしないときには、追加の設定は必要ありません。認証プラグインは、特定のマルチステップ認証のニーズを満たす処理を実現します。
単純フォームベースの認証は、デフォルトの埋込み資格証明コレクタまたはオプションの外部資格証明コレクタと、Access Manager認証メカニズムでユーザー・ログインを処理するWebフォームに依存します。単純フォームベースの認証を使用する場合:
すべての資格証明が1つの単純フォームで提供されます。
資格証明の検証および認証時に、成功または失敗のステータスが返されます。
認証は失敗時、再試行できます。
関連項目:
ログイン・ページおよびフォームのカスタマイズの詳細は、「カスタム・ページの開発」
動的なマルチステップ認証のために、Access Managerは、独自にカスタマイズした認証モジュールで設計および編成できる、いくつかのプラグインを提供しています。DCCとECCは、どちらも複雑なマルチファクタ(マルチステップ、反復および変数)の認証プロセスを、次のように処理します。
必要な資格証明が、一度に提供されない場合。
認証ステータスに応じて、PENDING状態になり、予期される資格証明とコンテキスト・データが返され、該当する資格証明が次回に提供されると予期されます。
成功または失敗のステータスが返されるまでは、各中間ステップで認証エンジンに必要な資格証明とコンテキスト・データが送信されます。
認証プラグインは、複数のステップで構成できます。
ノート:
管理者はAccess Managerに複数のユーザー・アイデンティティ・ストアをインストールできます。それぞれのアイデンティティ・ストアは、異なるLDAPプロバイダに依存できます。各認証プラグインは、別々のユーザー・アイデンティティ・ストアを使用するように構成できます。
表22-10に、これら2つの形式の認証についての詳細を示します。
表22-10 単純フォーム認証とマルチステップ認証
| 認証方式 | 説明 |
|---|---|
単純フォームベース認証 |
単純フォームベースの認証は、資格証明コレクタ(ECCおよびDCC)と、Access Manager認証メカニズムを使用してユーザー・ログインを処理するWebフォームに依存します。これはデフォルトであるため、フォームをカスタマイズしないときには、追加の構成は必要ありません。 関連項目: ログイン・ページおよびフォームのカスタマイズの詳細は、「カスタム・ページの開発」 |
マルチステップ認証 |
マルチステップ認証には、複数の認証プラグインで構成されるカスタム認証モジュールが必要になります。このモジュールは、ログイン処理時に、バックエンドの認証スキームに情報を複数回伝送します。プラグインにより収集され、コンテキストに保存されたすべての情報は、プラグインが認証プロセスを介してアクセスできます。コンテキスト・データは、Cookieまたはユーザーのログイン・ページのヘッダーの設定にも使用できます。 マルチステップ認証は、次のものに依存しています。
関連項目: 「カスタマイズされたステップアップ認証モジュール内のステップとプラグイン」 カスタム認証プラグインの詳細は、「カスタム認証プラグインの開発」 |
カスタム・プラグイン・ベースの認証モジュールは、既存のAccess Managerを使用して作成できます。『Oracle Fusion Middleware Oracle Access Management開発者ガイド』の説明に従って、ユーザー独自のプラグインを作成することもできます。
ノート:
標準(ネイティブの)認証モジュールは、非推奨になる予定です。将来の拡張機能は、標準モジュールでは使用できなくなる予定です。「プラグイン・ベースのモジュールによるマルチステップ認証の編成」で説明するように、プラグイン・ベースのモジュールを使用することをお薦めします。
図22-8は、即時利用可能なプラグインを示しています。カスタム認証モジュールを構築するためのステップを追加すると、これらのプラグインと、ユーザーがSDKや使用して作成したりインポートしたプラグインが、リストに表示されます。
一般的に、「名前」によって、プラグインに依存するコンポーネントが定義されます。「説明」はオプションです。「タイプ」列は、プラグインの目的を示しています。「アクティブ化のステータス」によって、このプラグインがアクティブで使用可能かどうかがわかります。
関連項目:
ユーザー独自のカスタム・プラグイン構築の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。新しいプラグインをインポートしたり、カスタム・プラグインを配布、アクティブ化、非アクティブ化、削除することができます。
Oracle提供のプラグインを使用する場合も、ユーザー独自のプラグインを作成する場合も、カスタム認証モジュールの作成時にプラグインを追加することは同じです。各カスタム・モジュールには、次のタイプの情報が必要です。
「一般」: 個々のプラグインの一意の名前とオプションの説明を識別します。
「ステップ」: 各プラグインの構成詳細(使用するユーザー・アイデンティティ・ストアを含む)に基づいて、使用する固有のプラグインと、その実行順序を識別します。
「ステップ編成」: 成功時、失敗時、またはエラー時に実行するアクションを指定します。
ノート:
マルチファクタ認証を使用している場合、認証プロセス中の最後のパスでUserIdentificationPluginを起動する必要があります。
図22-9は、「システム構成」ツリーの「Access Manager」セクションにある「カスタム認証モジュール」を示しています。各モジュールには3つの構成タブがあります。
表22-11は、「一般」タブの内容の説明です。
表22-11 「一般」タブ
| 要素 | 説明 |
|---|---|
名前 |
一意の名前で、60文字以内です。 |
説明 |
オプション。250文字以内です。 |
「ステップ」タブをクリックすると、新しいページが開き、そこで新規ステップを追加できます。新規のステップを追加するときには、次のダイアログ・ボックスが表示されます。ここで入力する情報を使用して、表と、ページの「詳細」セクションにデータが移入されます。
表22-12では、新規ステップの追加に必要な情報について説明します。各ステップに1つのプラグインが必要です。また、各プラグインには、適切な操作のための具体的な詳細が必要です。
表22-12 「新規ステップの追加」のエントリ、ステップの結果表、「詳細」セクション
| 要素 | 説明 |
|---|---|
ステップ名 |
ステップを識別するために入力する一意の名前で、60文字以内です。 |
説明 |
ステップを追加するときにオプションで入力する、このステップの説明(250文字以内)。 |
プラグイン名 |
特定のステップに対して選択するプラグインです。インポートされアクティブ化されているプラグインのリストから選択します。 関連項目: カスタム・プラグインの作成の詳細は、『Oracle Fusion Middleware Oracle Access Management開発者ガイド』を参照してください。 |
ステップの詳細 |
正しい操作を確実に実行するために、プラグインの構成詳細を指定する必要があります。詳細の内容は、選択したプラグインと、そのプラグインの要件によって異なることがあります。 関連項目: 表22-13。 |
表22-13に、Oracle付属のプラグインで必要になるプラグイン・パラメータの詳細を示します。この表に記載されていないプラグインのKerberosTokenIdentifier、FedAuthnRequestPluginおよびFedUserAuthenticationPluginは、例外的なプラグインです(これらのプラグインには、初期パラメータがありません)。
表22-13 各種プラグインのパラメータの詳細
| プラグイン・パラメータ | 表示名 | 説明 |
|---|---|---|
KEY_IDENTITY_STORE_REF |
アイデンティティ・ストア名 |
認証時に適切なユーザー・アイデンティティ・ストアが呼び出されるようにするために、ほとんどのプラグインでこの属性が必要になります。 次のプラグインは、このプロパティのみを使用します。
このプロパティを採用するプラグインに必要な追加の詳細は、次を参照してください。
|
CredentialCollectorPlugIn |
CredentialCollectorPlugIn |
このプラグインにより、管理者は、認証用にどの資格証明を収集するかを構成できます。収集される資格証明は、ステップ・パラメータとして構成されます。プラグインは、これらのパラメータを検証して、資格証明を収集するUIを表示します。ユーザーの入力後、資格証明パラメータを解析し、資格証明オブジェクトでユーザー・コンテキストを構築します。 ノート: 資格証明が無効で、プラグインが失敗を返した場合、プラグイン・エラー・レスポンスがコンテキストに設定されます。 このプラグインは、ステップ・レベル・パラメータとして4つの資格証明のコレクションをサポートします。
次の例は、ユーザー名とパスワードを収集する方法を示しています。 CRED_PARAM_1=
{ID=KEY_USERNAME},{DISPLAY_NAME=KEY_USERNAME},{TYPE=text}
{ID=KEY_PASSWORD},{DISPLAY_NAME=KEY_PASSWORD},{TYPE=password}
ID、DISPLAY_NAMEおよびTYPEは定数です。 |
Actiontype |
アクション・タイプ |
プラグインが資格証明を収集するログイン・ページにリダイレクト(REDIRECT)するか転送(FORWARD)するかを示します。 |
loginPageURL |
ログイン・ページのURL |
資格証明の収集においてユーザーを転送またはリダイレクトするURL。 |
NO_OF_CREDENTIALS |
プラグイン・インスタンスに対して提供される資格証明の数。インスタンス数が5つ以上ある場合、ユーザーは、oam-configファイルを更新して、プラグイン・パラメータのCRED_PARAMSを追加する必要があります。 |
|
UserIdentificationPlugIn |
UserIdentificationPlugIn |
このネイティブ・プラグインは、ユーザーを特定のLDAPユーザー・レコードにマップします。 |
KEY_LDAP_FILTER |
LDAPフィルタ |
ユーザーを特定するために必要な検索フィルタです。LDAP検索フィルタを定義するときは、LDAP属性を使用します。 |
KEY_SEARCHBASE_URL |
LDAP検索ベース |
問合せに必要な検索ベースです。ディレクトリ情報ツリー(DIT)のノードです。このノード以下にユーザー・データが格納されるため、すべてのユーザー・データ検索の最高位のベースになります。 |
UserAuthenticationPlugIn |
UserAuthenticationPlugIn |
このネイティブ・プラグインは、提供されたユーザー名とパスワードの資格証明をLDAPディレクトリに対して認証します。 |
KEY_PROP_AUTHN_EXCEPTION |
LDAPエラーの伝播 |
LDAPエラーの伝播を有効(または無効)にします。UserAuthenticationPlugInは、この属性を採用しています。 |
UserAuthnLevelCheckPlugin |
UserAuthnLevelCheckPlugin |
このネイティブ・プラグインは、ユーザーが認証レベルXに対して認証済かどうかを判断します(Xの値は、プラグイン・パラメータAUTHN_LEVEL_FOR_PLUGINによって提供される値です)。たとえば、指定値で、現在のユーザーの認証レベルをチェックします。加えて、このプラグインは、認証レベル・チェックが成功したか失敗したかに応じて、収集するパラメータのリストを指定します。 |
AUTHN_LEVEL_FOR_PLUGIN |
AUTHN_LEVEL_FOR_PLUGIN |
認証レベルを整数で指定します。 複数のステップの場合はUserAuthnLevelCheckPluginを使用できます。ただし、各ステップに一意の名前とAUTHN_LEVEL_FOR_PLUGINがある必要があります。 |
UserPasswordPolicyPlugin |
UserPasswordPolicyPlugin |
|
PLUGIN_EXECUTION_MODE |
操作モード |
UserPasswordPolicyPluginの実行モード。UserPasswordPolicyPluginは、LDAPベースの認証モジュールを使用する場合にのみサポートされます。非LDAP認証モジュールを使用する場合は使用できません。構成に応じて、単独で、または他のプラグインとともに動作できます。値は次のいずれかになります。
|
POLICY_SCHEMA |
使用するポリシー・スキーマ |
パスワード・サービス(UserPasswordPolicyPluginで使用)のスキーマを指定します。OAM10Gのみがサポートされています。 デフォルト: OAM10G |
NEW_USERPSWD_BEHAVIOR |
初回ログイン時にパスワードの変更を強制 |
新しいユーザー・パスワード・ポリシーの遡及的動作を構成します。UserPasswordPolicyPluginに使用します。値は、次のどちらかになります。
デフォルト: FORCECHANGEPASSWORD |
DISABLED_STATUS_SUPPORT |
無効化されたアカウント・ステータスのサポート |
無効のステータスをサポートし、このパスワード・サービスに従って処理するかどうかを指定します。有効値はTrueまたはFalseのいずれかです。 デフォルト: TRUE |
URL_ACTION |
パスワード管理アクションURL |
パスワード管理のために、ユーザーを移動するURLを指定します。ユーザーを期限切れのページや警告ページなどの特定のパスワード・ページにリダイレクトするために必要となるサーブレットの処理のタイプ。値は次のいずれかになります。
デフォルト: REDIRECT_POST |
FedUserProvisioningPlugin |
||
KEY_USER_RECORD_ATTRIBUTE_LIST |
ユーザー属性のリスト |
フェデレーション用です。ユーザー・レコードの作成に必要なアサーション属性を、カンマで区切ったリストです。 |
KEY_PROVIDERID_ATTRIBUTE_NAME |
パートナ属性名 |
フェデレーション用です。LDAPユーザー・レコードの属性名です。このレコードの値は、ユーザーをプロビジョニングするときにパートナのアイデンティティ・プロバイダIDに設定されます。最初のフィールドはオプションであり、このフィールドを空にすると、パートナのアイデンティティ・プロバイダIDは、LDAPユーザー・レコードに設定されなくなります。 |
KEY_USERID_ATTRIBUTE_NAME |
ユーザーのUserID属性 |
フェデレーション用です。LDAP UserIDとして使用されるアサーション属性の属性名です。 |
TAPIdentifyPlugIn |
||
KEY_TAP_RETURN_ATTRIBUTE |
ユーザー名マッピング属性 |
TAPIdentifyPlugInでアカウントをリンクするために使用する属性の名前です。 |
SequentialPlugInExecutionStrategy |
||
StrategyName |
編成戦略 |
SequentialPlugInExecutionStrategyに必要なプラグイン編成戦略の名前です。 |
KerberosTokenAuthenticator |
||
KEY_KEYTAB_FILE |
キー・タブ・ファイルの場所 |
Kerberosプリンシパルと暗号化されたキーを含むファイルの名前です。これは、KerberosTokenAuthenticatorに必要になります。 |
KEY_PRINCIPAL |
OAMサービス・プリンシパル |
OAMアカウントのSPNです。KerberosTokenAuthenticatorに必要になります。 |
KEY_KRB_CONFIG_FILE |
Kerberos構成ファイルの場所 |
Kerberos構成プロパティ・ファイルの場所です。KerberosTokenAuthenticatorに必要になります。 |
KEY_DOMAIN_DNS2DN_MAP |
ADドメインDNS名のDNへのマッピング |
Active Directory DNSドメインのDNへのマッピングをカンマで区切ったリストです。KerberosTokenAuthenticatorに必要になります。 |
X509CredentialExtractor |
||
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT |
ユーザーのマッピング属性 |
X509証明書属性です。X509CredentialExtractorに必要なユーザー・マッピングに使用します。 |
KEY_IS_CERT_VALIDATION_ENABLED |
証明書検証 |
X.509証明書の検証を有効または無効にします。X509CredentialExtractorに必要になります。 |
TAPRequestPlugin |
||
TAPS2PVersion |
統合プロトコルのバージョン |
統合用のトークン・バージョンです。 |
TAPPartnerId |
統合PartnerId |
統合パートナ識別子です。 |
TAPChallengeURL |
パートナ統合のエンドポイントURL |
リモート・パートナのエンド・ポイントURLです。 |
TAPUserAuthenticationPlugin |
||
KEY_USERNAME_ATTRIBUTE |
ユーザー名マッピング属性 |
アカウントのリンクに使用される属性の名前です。TAPUserAuthenticationPluginに必要になります。 |
KEY_CHECK_TOKEN_EXPIRY |
トークンの有効期限チェックの有効化 |
統合トークンの有効期限を有効または無効にします。 |
TenantDisambiguationPlugin |
||
KEY_FEDERATED_TENANTS |
FederatedTenantNames |
フェデレーテッド認証が有効にされている、オプションの各テナントの名前(カンマ区切り)です。プラグインは、フェデレーション・エンジンにテナントの名前が記述されていないことを問い合せます。 |
RSA SecurIDプラグイン |
||
username |
ユーザー名パラメータ |
ユーザー名プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
passcode |
パスコード・パラメータ |
パスコード・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
nexttoken |
次のトークン・パラメータ |
次のトークン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
newpin |
新規PINパラメータ |
新規ピン・プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
confirmnewpin |
新規PINの確認パラメータ |
新規pinの確認プラグイン・パラメータの名前です。RSA SecurIDプラグインに必要です。 |
HTTPTokenExtractor |
||
KEY_HEADER_PROPERTY |
HTTPヘッダー名 |
HTTPヘッダーのカンマ区切りのリストです。「HTTPTokenエクストラクタ・プラグインの構成」を参照してください。 |
KEY_COOKIE_PROPERTY |
HTTP Cookie名 |
Cookieのカンマ区切りのリストです。「HTTPTokenエクストラクタ・プラグインの構成」を参照してください。 |
図22-11は、カスタム認証モジュールの「ステップ」タブと「詳細」セクションを示しています。ステップを追加する際には、表に表示するデータはありません。ただし、1つ以上のステップを表に追加すると、「詳細」セクションに移入されます。
図22-12は、カスタム認証モジュールの「ステップ編成」タブを示しており、このタブには、定義された各ステップ(および各操作条件に対して選択したアクション)の情報が移入されます。
表22-14では、「ステップ編成」タブの要素について説明します。OnSuccess、OnFailure、OnErrorで選択できるリストの項目は次のとおりです。
成功
失敗
StepName (モジュールの任意のモジュールを、操作条件のアクションとして選択できます)
表22-14 「ステップ編成」タブ
| 要素 | 説明 |
|---|---|
最初のステップ |
リストから開始ステップを選択します。リストに含まれるのは、このモジュールに定義されているステップのみです。 |
名前 |
このモジュールに追加された各ステップが、追加するときに入力した名前別にリストされます。 |
説明 |
ステップを追加するときにオプションで入力した、このステップの説明。 |
成功時 |
操作が成功した場合に選択されるアクション。選択できるアクションがリストに示されます。
|
失敗時 |
このステップが失敗した場合に選択されるアクション。選択できるアクションがリストに示されます。
|
エラー発生時 |
このステップを実行してエラーになる場合に選択されるアクション。選択できるアクションがリストに示されます。
|
次の各項では、事前移入済のプラグインで提供されるネイティブなカスタム・モジュールのいくつかについて説明します。これらを使用すると、独自のカスタム認証モジュールを編成できます。
KerberosPlugin
「Windowsネイティブ認証のためのAccess Managerの構成」の説明に従い、Windowsネイティブ認証用にAccess Managerを構成するときには、このプラグインを使用します。
図22-13は、Access Manager 11gにバンドルされているKerberosPluginモジュールを示しています。これはリソースを暗号化された「Kerberosチケット」にリクエストするユーザーの資格証明(ユーザー名およびパスワード)と一致する資格証明マッピング・モジュールです。
図22-14は、デフォルトのステップと詳細を示しています。図22-15は、ステップの編成と条件を示しています。
LDAPPlugin
図22-16は、Access ManagerにバンドルされているLDAPPluginモジュールを示しています。デフォルトでは、図22-17のようにLDAPPluginには2つのステップがあります。図22-18は、LDAPpluginのステップのデフォルト編成を示しています。
X509Plugin
図22-19は、Access Manager 11gにバンドルされているX509Pluginモジュールを示しています。X509PluginはLDAPPluginと似ていますが、LDAPのユーザー属性に対して検証する必要があるクライアントのX.509証明書の属性を示すプロパティが追加されています。図22-20は、このプラグインのデフォルトのステップと詳細を示しています。図22-21は、X509Pluginのステップのデフォルト編成を示しています。
このプラグインでは、ルートとサブのCA証明書を$DOMAIN_HOME/config/fmwconfig/amtruststoreに追加する必要があります。X509CredentialExtractorプラグインがこの場所から証明書をロードするからです。
表22-15では、stepX509のサブジェクトとサブジェクト代替名の値をリストしています。これらの処理は、X509Pluginの使用時のみサポートされます。
表22-15 X509の「ステップの詳細」(KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT)
| issuer.D | サブジェクト |
|---|---|
subject. |
EDIPI ノート: EDIPIはElectronic Data Interchange Personal Identifierの略です。 |
subjectAltName. |
OTHER_NAME (FASC-N) ノート: FASC-NはFederal Agency Smart Credential Numberの略です。 |
subjectAltName. |
RFC822_NAME |
subjectAltName. |
UNIFORM_RESOURCE_IDENTIFIER |
パスワード・ポリシー検証モジュールとプラグイン
Oracleでは、認証プロセスで次のプラグインを個別のステップとして採用するパスワード・ポリシー検証モジュールを提供しています。
ユーザー識別ステップ
ユーザー認証ステップ
ユーザー・パスワード・ステータス・ステップ
図22-22は、「ステップ」タブを示しています。詳細は、図の後に説明します。
図22-23は、パスワード・ポリシー検証モジュールのプラグインの「ステップ編成」ページです。ステップの編成内容は、この図のとおりです。
Access Manager 11gはPIV (Personal Identity Verification)カード(米国連邦政府のスマート・カード)をサポートしており、これは、X.509認証時に、SubjectaltName拡張のFASC-NおよびEDIPI属性を使用してユーザーをマッピングするために使用されます。複数のOCSPプロバイダはサポートされませんが、OCSP Gatewayを使用するか、OSDT OCSP APIを使用するカスタム認証プラグインを作成することで、複数のOCSPプロバイダに対する検証を行うことができます。
次の機能は、X.509プラグイン(X.509認証モジュールではない)のみで使用できます。このプラグイン構成では、X.509クライアント証明書から抽出した属性のマップ先のLDAP属性を指定します。
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「プラグイン」セクションで、「認証モジュール」をクリックします。
モジュールのリストで、「X509Plugin」モジュールを選択します。
開かれたページで、「複製」をクリックして、各フィールドに次のように入力します。
「一般」タブ:
名前: CustomX509Plugin。
「説明」: X509のカスタム・プラグイン
「ステップ」タブ:
「+」をクリックして、プラグインにステップを追加します。
「名前」と「説明」を入力して、「X509CredentialExtractor」プラグインを選択します。
「ステップの詳細」:
KEY_IS_CERT_VALIDATION_ENABLED: true
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACT (表22-15): subject.EDIPI, subjectAltName.OTHER_NAME (FASC-N), subjectAltName.RFC822_NAME, subjectAltName.UNIFORM_RESOURCE_IDENTIFIER
「保存」ボタンをクリックします。
別のプラグインの追加:
「+」をクリックして、別のプラグインを追加します。
「名前」と「説明」を入力して、UserIdentificationPluginを選択します。
2つ目のプラグインの「ステップの詳細」:
必要なアイデンティティ・ストアに関するKEY_IDENTITY_STORE_REFを設定します。
KEY_LDAP_FILTER属性にLDAPフィルタを追加します。次に例を示します。
(&(uid=
Unknown macro: {subject.CN}
)(mail=
Unknown macro: {subject.E}
))
必要な場合は、KEY_SEARCH_BASE_URL属性にユーザー検索ベースを追加します。
「保存」ボタンをクリックします。
「ステップ編成」タブ(ステップ2)に進みます。
ステップの編成:
「最初のステップ」: ドロップダウンから「X509CredentialPlugin」ステップを選択します。
「成功時」: 「X509CredentialPlugin」ステップで、ドロップダウン・リストから「UserIdentificationPlugin」を選択します。
「成功時」: 「UserIdentificationPlugin」ステップで、ドロップダウン・リストから「Success」を選択します。
「失敗時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」を選択します。
「エラー発生時」: 「X509CredentialPlugin」および「UserIdentificationPlugin」ステップの両方で、「Failure」を選択します。
「適用」ボタンをクリックし、プラグインが正常に作成されたことを示す確認ウィンドウを確認します。
OCSPを使用して、「証明書検証」と「証明書失効」に証明書検証モジュールを設定します。
関連項目:
Oracle Access Managementコンソールで、ウィンドウの上部にある「構成」をクリックします。
「構成」コンソールで、「証明書検証」をクリックします。
「証明書失効リスト」セクションで、「有効」が選択されていることを確認し、「保存」をクリックします。
「OCSP/CDP」セクションでOCSPを有効にし、OCSPのURLと、OCSPサーバーの証明書のサブジェクトを入力し、「保存」をクリックします。
コマンド行でJavaのkeytoolアプリケーションを使用し、信頼できる証明書のエントリとして$DOMAIN_HOME/config/fmwconfig/amtruststoreキーストアに信頼できる証明書をインポートします。
ノート:
初期状態ではキーストアは空です。パスワードは、Java keytoolアプリケーションを最初に使用するときに設定されます。
有効な管理者の資格証明を持つユーザーは、1つ以上の認証プラグインを使用するカスタム認証モジュールを作成できます。
この手順は、認証モジュールの一般ステップの概要を示しています(オンライン証明書ステータス・プロトコル(OCSP)を使用して、サーバーのセキュリティおよび他のネットワーク・リソースをメンテナンスするために、認証X509モジュールを構成する場合のサンプル情報も含んでいます)。
前提条件
モジュールに関連付けられているユーザー・アイデンティティ・ストアが実行中であり、必要なユーザー移入が含まれていることを確認します。
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「アプリケーション・セキュリティ」コンソールで、「プラグイン」セクションの「作成」(+)ドロップダウン・リストから「カスタム認証モジュールの作成」を選択します。
表示されるページで、「名前」を入力し、オプションで「説明」を入力します。たとえば、順に「CustomX509Plugin」と「X509のプラグイン」とします。
「適用」をクリックして、一般情報を保存します。
ステップの追加:
「ステップ」サブタブをクリックします。
「ステップ」表の上にある「追加」(+)ボタンをクリックします。
「新規ステップの追加」ダイアログ・ボックスで、一意の「ステップ名」と、オプションで「説明」を入力します。
目的のカスタム・プラグイン名(たとえば、X509CredentialExtractor)を参照して選択し、「OK」をクリックします。
結果表の情報を確認します。
モジュールに必要なすべてのプラグインがリストされるまで、bからeを繰り返して他のステップを追加します。
「ステップの詳細」の定義: 要求されるパラメータに適切な値を使用します(表22-12、表22-13、表22-17および「例: SubjectAltName拡張データの利用と複数のOCSPエンドポイントの統合」)。
表の「StepName」をクリックして必要な詳細を表示させ、必要な詳細に適切な値を入力します。
OCSPを使用したユーザー証明書の検証:
KEY_IS_CERT_VALIDATION_ENABLEDがtrueに設定されていることを確認します。
KEY_CERTIFICATE_ATTRIBUTE_TO_EXTRACTで抽出される証明書属性を追加します(表22-15):
subject.EDIPI subjectAltName.OTHER_NAME (FASC-N) subjectAltName.RFC822_NAME subjectAltName.UNIFORM_RESOURCE_IDENTIFIER
「Save」ボタンをクリックします。
ステップを繰り返し、各ステップを適切に構成します。
ステップで割り当てるユーザー・アイデンティティ・ストアに、ユーザーがプロビジョニングされていることを確認します。
ステップの編成: 表22-14を参照して、次のステップを実行します。
「ステップ編成」サブタブをクリックします。
「最初のステップ」リストで、使用する最初のステップの名前を選択します。
表でステップ名を選択します。
「OnSuccess」リストから、条件(成功または失敗)またはステップ名を選択します。
「OnFailure」リストから必要な条件またはステップ名を選択します。
「OnError」リストから必要な条件またはステップ名を選択します。
ステップcからfを繰り返し、このモジュールの各プラグインの操作を編成します。
編成を確認します。
戦略の検証の開始: 「適用」をクリックして、編成戦略の検証を開始します。
戦略が正常な場合: 編成戦略が適用され、認証スキームにモジュールを追加できるようになります。ステップ9と10を続行します。
戦略が無効な場合: 「エラー」ボックスで「OK」をクリックし、OnSuccess、OnFailure、OnErrorの戦略を編集(プラグインを追加または削除)して問題を修正します。戦略が成功するまでこのステップを繰り返します。
ナビゲーション・ツリーで新しいカスタム認証モジュールがリストされていることを確認し、終わったらページを閉じます。
「認証スキームの管理」の説明に従って、カスタム・モジュールを認証スキーム内で使用します。
表22-16 カスタマイズされたステップアップ認証モジュール内のステップとプラグイン
| ステップ番号 | ステップ名 | プラグイン名 | 説明 |
|---|---|---|---|
1 |
StandardLevelCheck-2 |
UserAuthnLevelCheckPlugin |
LevelCheckルールと、チェック結果としてSUCCESSまたはFAILUREに関連付けられる資格証明パラメータで構成します。 このプラグインは、認証エンジンにアクセスして、ユーザーの現在の認証レベルを決定し、これを、プラグイン・レベル・パラメータAUTHN_LEVEL_FOR_PLUGINと比較します。また、カスタム資格証明コレクタとやり取りして、ユーザーの現在の認証レベルを指定値と比較します。たとえば、X値が2の場合:
認証レベル・チェックが成功したか失敗したかに応じて収集するパラメータのリストを指定します。
|
2 |
CollectUserNamePassword |
CredentialCollectorPlugin フローは、収集する資格証明パラメータを伝えるプラグインから開始する必要があります。アクションは、サーバーがパラメータを不変としてマークできることをサポートする必要があります。 |
このプラグインは、資格証明コレクタ(CustomReadServlet)と対話して、管理者が、認証用に収集した資格証明を構成できるようにします。収集される資格証明は、ステップ・パラメータとして構成されます。プラグインは、これらのパラメータを検証して、資格証明を収集するUIを表示します。 ユーザーが、ステップ・パラメータで収集する必要がある資格証明を提供します。この例では、前のステップで、ユーザーがレベル2の認証を受けていないので、ユーザーはユーザー名とパスワードを入力するように要求されます。
収集する資格証明は、UIインタフェースを表示する資格証明コレクタ用に、この形式で指定する必要があります。 また、次のアクションも指定します。
|
3 |
UserIdentificationProcess |
UserIdentificationPlugIn |
ユーザーを特定のLDAPユーザー・レコードにマップする即時使用プラグイン。
|
4 |
UserAuthenticationStep |
UserAuthenticationPlugin |
提供されたユーザー名とパスワードの資格証明をLDAPディレクトリに対して認証する即時使用可能プラグイン。
|
5 |
SensitiveLevelCheck-6 |
UserAuthnLevelCheckPlugin |
このプラグインは、認証エンジンにアクセスして、ユーザーの現在の認証レベルを決定し、これを、プラグイン・レベル・パラメータAUTHN_LEVEL_FOR_PLUGINと比較します。また、カスタム資格証明コレクタとやり取りして、ユーザーの現在の認証レベルを指定値と比較します。チェックが成功したか失敗したかに応じて収集するパラメータを指定します。
|
6 |
CollectSensitiveLevelCreds |
CredentialCollectorPlugin |
レベル6認証用に資格証明を収集するためのUIを表示します。これはCollectUserNamePwdと似ています。
|
7 |
ValidateSensitiveLevelCreds |
SubjectSetPlugin |
このカスタム・プラグインは、サーバーに対してセキュリティ・コードを検証します。
|
プラグインを定義して、認証モジュールに編成した後、認証スキームでモジュールを使用して、そのスキームをポリシーで使用できます。
カスタマイズしたモジュール内でプラグインを使用してステップアップ認証を定義できます。
この例では、社内ポータルのページにアクセスするための標準レベルのアクセス権を必要とするユーザーと、機密情報にアクセスするためのアクセス権を必要とするユーザーがいます。標準アプリケーションに対する認証資格証明にはユーザー名とパスワードが含まれます。センシティブ・アプリケーションに対する資格証明には、ユーザー名、パスワードおよびセキュリティ・コード(コードの検証を行うカスタム・プラグインで取得)が含まれます。
RSPS2リリースのOAMでは、Oracle Access Manager Mobile and Social (OAMMS)サービスで提供されるOAuth認可サービスの完全なサポートが導入されました。OAuthサービスは、ユーザーの認証または認可(あるいはその両方)の後にWebサービスにアクセスするためのJSON Webトークン(JWT)を発行します。したがって、ユーザーはOAM認証メカニズムにより認証された後、様々なリソースにアクセスするためにOAMとJWTの両方を持つことができます。これを使用できる典型的なシナリオは、Webゲートで保護されたアプリケーションにアクセスする場合です。ユーザーはOAM認証モジュールによって認証され、OAMトークンとJWTの両方が提供されます。Webゲートを介するアクセスにはOAMトークンが使用されますが、WebサービスまたはRESTサービスへのアクセスには必要に応じてJWTを使用できます。(WebサービスまたはRESTサービスは、Oracle API GatewayやOracle Web Services Managerなどの製品によって保護されます。)
OAMでは、JSON Webトークン・プラグインが使用できるようになりました。このJSON Webトークン・プラグインは、標準トークンでRESTサービスまたはWebサービスを保護する必要がある場合に使用します。JSON Webトークン・プラグインは、OAMトークンと、Webサービスへのアクセスに使用できるMobile and Social JWTの両方を発行します。Oracle API GatewayおよびOracle Web Services Managerでも、Webサービスの保護のためにこのJWTを使用できます。詳細は、次の各項を参照してください。
デプロイメントでJSON Webトークン・プラグインを使用できます。
次のフローでは、JSON Webトークン・プラグインが使用される仕組みについて説明します。
OAM認証およびJSON Webトークン・プラグインの両方を使用するように、Oracle Access Management WebGateを構成します。
ユーザーがWebGateで保護されたリソースにアクセスする場合、WebGateはユーザーをリダイレクトしてAccess Managerで認証します。
認証時に、プラグインは、どのOAuthサービス・エンド・ポイントでJWTを生成するかを特定します。(OAuthサービス・エンド・ポイントは一意であるため、特定のアイデンティティ・ドメイン内で特定のOAuthサービス・プロファイルを指すように構成できます。)Oracle Access Manager Mobile and SocialがJWTを作成し、プラグインがこれをCookieとして返します。(プラグイン構成でcookie名を構成できます。)
Webアプリケーションは、Webサービス・アクセス用に後で使用できるように、レスポンスを捕捉してcookieにアクセスします。Webアプリケーションのデプロイ方法によっては、JWTを取得するために他のオプションを使用できる場合があります。ユーザーは、これでWebリソースにアクセスできます。
WebリソースはWebサービスにアクセスする必要がある場合、OAM Mobile and Social JWTを抽出してOracle API Gatewayに送信します。
Oracle API Gatewayは、Oracle OAuth Service REST APIを使用してトークンを検証します。その後、Webサービスにアクセス権を付与します。Oracle API Gatewayは、OAuthサービスをリモートからコールせずに、ローカルにJWTを検証することもできます。
ノート:
現在、OAM認証でJWTを発行している間にOAuthサービスにスコープを渡すメカニズムはありません。したがって、トークンはグローバル・スコープを持つとみなされます。
OAMトークンのタイムアウトとJWTのタイムアウトの両方を同じ値に設定して、同じ有効期間にすることができます。OAMトークンとJWTはリンクされていないため、シングル・ログアウトを使用してこれらを終了することはできません。
JSON Webトークン・プラグインを構成できます。
カスタム認証モジュールを作成します。
Oracle Access Managementコンソールで、ウィンドウの上部にある「アプリケーション・セキュリティ」をクリックします。
「認証モジュールの検索」画面が表示されます。
「プラグイン」セクションの「作成」(+)ドロップダウン・メニューから、「カスタム認証モジュールの作成」を選択します。
「一般」タブが表示されます。
カスタム認証モジュールの名前および説明(オプション)を入力します。
この例のために、モジュールにJWTToken AuthnModuleという名前を付けます。
「ステップ」タブおよび+ (プラス記号)をクリックして、新しいステップを追加します。
「新規ステップの追加」ダイアログが表示されます。3つの新しいステップが追加されます。
ステップ名と説明(オプション)を指定し、「プラグイン名」ドロップダウン・リストからアクティブなプラグインを選択し、「OK」をクリックします。
この例では、値はStepUIおよびUserIdentificationPluginです。このプラグインのフロー・パラメータは、ステップに追加後、編集できるようになります。
UserIdentificationPluginパラメータの値を入力して、「保存」をクリックします。
+ (プラス記号)をクリックして2つ目のステップを追加します。名前としてStepUAと入力し、ドロップダウン・リストから「UserAuthenticationPlugin」を選択して「OK」をクリックします。
UserAuthenticationPluginパラメータの値を入力して、「保存」をクリックします。
+ (プラス記号)をクリックして3つ目のステップを追加します。名前としてStepOAuthと入力し、ドロップダウン・リストから「OAuthTokenResponsePlugin」を選択して「OK」をクリックします。
OAuthTokenResponsePluginパラメータの値を入力して、「保存」をクリックします。
「ステップ編成」タブをクリックして、次の順序でステップの編成を構成します。
StepUI
StepUA
StepOAuth
「適用」をクリックして、「カスタム認証モジュール」タブを閉じます。
「起動パッド」から「認証スキーム」をクリックします。
「LDAPScheme」を選択して、「複製」をクリックします。
LDAPSchemeのコピー画面が表示されます。
「名前」の値をJWTToken AuthnSchemeに、認証モジュールの値をJWTToken AuthnModuleに変更します。
「保存」をクリックします。
新しく定義されたJWTToken AuthnScheme認証スキームを使用して認証ポリシーを構成します。
