57.1 Access ManagerとWindowsネイティブ認証の概要

Access Managerは、Windowsネイティブ認証(WNA)とのActive Directoryのマルチドメインおよびマルチフォレスト・トポロジ統合をサポートします。

Active Directoryのディレクトリ・サービスでは、オブジェクト(ユーザー、グループ、コンピュータ、ドメイン、組織単位およびセキュリティ・ポリシー)に関する情報にデータ・ストア(ディレクトリと呼ばれる)を使用します。

関連項目:

Oracle Identity and Access Management 11gR1のシステム要件とサポート対象プラットフォーム: https://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html

統合では、アプリケーションをAccess Manager認証ポリシーによって保護する必要があり、このポリシーでは、Kerberos認証スキーム(KerberosScheme)と、KerberosPlugin認証モジュールを使用したチャレンジ・メソッドとしてのWNAを組み合せて使用します。この場合は、ユーザー・アイデンティティ・ストアとしてAccess Managerに登録されたWindows Active Directoryインスタンスに、資格証明を保存する必要があります。

保護されるリソースそれぞれをアプリケーション・ドメイン内に定義します。認証ポリシーには、デフォルトのユーザー・アイデンティティ・ストアに関連付けられている認証モジュール(Kerberos)を使用する認証スキーム(KerberosScheme)が含まれています。このストアは、認証に「ユーザー名属性」の値を使用します。この値は、特定のAccess Managerリリースに応じて、Active Directoryのユーザーおよびuserprincipalname = username@domianまたはSamAccountName = usernameの値に関連付けられています。

Access Managerシングル・サインオンをWNAと組み合せると、ユーザーのログイン資格証明などが含まれたKerberosセッション・チケットが生成されます。このKerberosセッション・チケットはユーザーには表示されません。

Access Managerは、ユーザーがWindowsドメインにログインしたときに取得するKerberos資格証明を使用して、WNAと相互運用します。このクロス・プラットフォーム認証は、Kerberosプロトコルを使用するWindows間のネイティブ認証サービスのネゴシエーション動作をエミュレートすることによって実現します。このクロス・プラットフォーム認証を機能させるため、OAMサーバーは、SPNEGOトークンを解析して、認証に使用されるKerberosトークンを抽出する必要があります。

SPNEGOは、考えられる多数の実際のメカニズムの1つをネゴシエートするために使用されるGSSAPI (Generic Security Services Application Programming Interface)「擬似メカニズム」です。SPNEGOは、これを使用してイニシエータおよびアクセプタでKerberosメカニズムまたはNTLMSSPメカニズムのいずれかをネゴシエートできるようにするMicrosoftの「HTTPネゴシエート」認証拡張子でよく使用されます。GSSAPI実装は、ほとんどの主なKerberosの配布に含まれています。

SPNEGOの詳細は、http://tools.ietf.org/html/rfc4559を参照してください。
Kerberosは、秘密キー暗号化を使用してクライアント/サーバー・アプリケーションおよびサービスに強力な認証を提供するネットワーク認証プロトコルです。Kerberosプロトコルの無料実装は、マサチューセッツ工科大学から入手でき、また市販されています。

次を参照してください。

57.1.1 Access Manager WNAログインおよびフォール・バック認証の理解

WNAを実装すると、Kerberosセッション・チケットがブラウザを介してOAMサーバーに渡されるので、ユーザーは別の資格証明のチャレンジなしに、Webアプリケーションを開くことができます。

OAMサーバーは、受信したトークンを(キー・タブを使用して)復号化し、そこから認証済ユーザーの名前を取得します。認証が成功した場合、ユーザーは自動的にWebアプリケーションへのアクセスを許可されます。

57.1.1.1 Access Manager WNA認証の成功

ブラウザは、統合Windows認証(IWA)用に構成されます。

これはブラウザのセキュリティ構成です。ブラウザが統合Windows認証を使用するように構成されていない場合、Kerberos認証モジュールによって保護されたリソースが要求されたときに、TGTは提供されません。ブラウザのBasic認証ウィンドウが表示され、このウィンドウで、デフォルトのアイデンティティ・ストアでUser login attributeに対して定義されている有効なユーザー名/パスワードの組合せを入力できます。
Access ManagerおよびWNAによって保護されるリソースが呼び出されます。

保護されたリソースは、イントラネット・リソースとして構成する必要があります。これは、ブラウザ設定の「ローカル・イントラネット」ゾーンにサイトを追加することによって行われます。
有効なKerberosチケットが表示されます: Http headers... Authorization: Negotiate YIIJ/...
ユーザーは、認証に関してチャレンジされません。リクエストしたリソースが表示され、WNAが機能することが証明されます。

つまり、ブラウザが統合Windows認証を使用するように構成されていて、リソースがKerberos認証モジュールで保護されている場合は、次のようになります。

KerberosチケットをAccess Manager(ドメインにかかわりなく)が受け取ると、認証が試行されます。
- 成功: アクセスが付与されます。
- 失敗: Kerberosチケットの情報が提示されないかまたはデフォルトのユーザー・アイデンティティ・ストアで定義したユーザー名属性の値と一致しない場合、「不適切なユーザー名またはパスワード。」エラーが表示されます。アクセスは拒否されます。ブラウザはチケットを自動的に送信して、Access Managerとの相互作用はユーザーがロックアウトされるまで繰り返されます。ブラウザは、各交換の開始前に一時停止できません。
ユーザーがKerberos認証によってWindowsドメインにログオンされない場合、ブラウザはOAMに認証のためにKerberosトークンではなくNTLMトークンを送信します。Access Managerの構成方法によって、NTLMトークンの受信時にWNAフォールバック認証が使用されるか、認証が失敗します。

ノート:
ブラウザがNTLMトークンを送信したときにフォールバック認証を提供するようにAccess Managerを構成する必要があります。構成しないと、認証は失敗します。構成ステップについては、「WNAのNTLMフォールバックの構成」を参照してください。

NTLMSSPは、すべてのバージョンのDCOM (Distributed Component Object Model)で使用できるセキュリティ・サポート・プロバイダです。これは、認証中にユーザーのパスワードをサーバーに実際には渡さない認証にNTLMプロトコルを使用します。

ノート:

KerberosチケットがAccess Manager(ブラウザ、オペレーティング・システム、ドメイン・ログインなどには関係ない)によって識別できない場合、フォールバック・メカニズムが呼び出されます。

57.1.1.2 Access Manager WNAフォールバック認証

フォールバックは、「基本」のチャレンジ・メソッドを使用した認証スキーム「BasicScheme」および認証モジュール「LDAP」を使用します。

このLDAP認証モジュールは、LDAPプラグインを使用します。このプラグインでは、ユーザー・アイデンティティ・ストアを、ユーザー名属性に使用する属性を定義する、現在登録されている任意のユーザー・アイデンティティ・ストアとして定義できます。この認証モジュールは、コンソールを使用して変更できます。

ブラウザは、統合Windows認証(IWA)用に構成されます。

これはブラウザのセキュリティ構成です。Access Managerは、2種類のWNAフォールバック認証を処理します。
- IWAが有効なドメイン内: OAMは、SPNEGOトークンのWNAをサポートします。しかし、構成または他の問題により、OAMはSPNEGOではなく、NTLMトークンをクライアントから受け取ります。デフォルトのフロー中に、OAMはNTLMトークンを使用して認証を試みますが、OAMにはNTLMトークンを認証する機能がないので失敗します。したがって、HandleNTLMResponse構成の導入により、OAMサーバーは基本認証のプロンプトでクライアントにチャレンジします。すなわち、ここでのフォールバックは、クライアントがOAMサーバーにNTLM認証を送信している場合、認証の基本モードのプロンプトを表示することです。詳細は、「WNAのNTLMフォールバックの構成」を参照してください。
- IWAが無効なドメイン外: ここでは、追加の構成は必要ではありません。デフォルトで、OOTBユーザーには認証時にBASICプロンプトが表示されます。
Access ManagerおよびWNAによって保護されるリソースが呼び出されます。

保護されたリソースは、イントラネット・リソースとして構成する必要があります。これは、ブラウザ設定の「ローカル・イントラネット」ゾーンにサイトを追加することによって行われます。
チケットは表示されません(NTLM/Kerberos) - Http headers... Authorization: Basic
基本認証ウィンドウのポップアップが表示されます。
ユーザーは有効なユーザー名/パスワードを入力します。
リクエストしたリソースが表示されます(WNAフォールバックが機能します)。

57.1.2 サポートされるKerberos認証モジュール

Windowsネイティブ認証のAccess Managerを構成する場合は、Kerberos認証モジュールまたはKerberosPlugin認証モジュールを使用します。Kerberos認証モジュールは、キー・タブ・ファイルおよびkrb5構成ファイルの名前およびプリンシパルを識別します。

KerberosPlugin認証モジュールは、同梱のプラグイン(またはAccess Manager認証拡張機能Java APIを使用して開発されたプラグイン)に依存しています。このモジュールでは、複数のプラグインが使用され、各プラグインが特定の認証機能を実行できるように編成できます。KerberosPlugin認証モジュールは、Kerberos認証モジュールよりも堅牢で豊富な機能を持ちます。KerberosPlugin認証モジュールは(プレーンWNA構成とともに)、次のアプローチをサポートします。

Oracle Virtual Directoryを使用したKerberosプラグイン: Oracle Virtual Directoryと統合された、編成された認証プラグインとともにAccess Managerを使用すると、複数のActive Directoryグローバル・カタログが仮想化されます
複数のADGC間で検索フェイルオーバーを使用するKerberosプラグイン: Access Managerを編成された認証プラグインとともに使用します。このプラグインは、複数のActive Directoryグローバル・カタログ間でフェイルオーバー・パターンを実行します。