OAMおよびOAMを使用したDCC HTTPリバース・プロキシ

この記事では、11.1.2.2.0リリースで導入されたDetached Credential Collector (DCC) HTTP Reverse Proxy機能について説明します。

この機能を有効にするデプロイメントでは、WebGate SSOエージェント:

このモードでは、ユーザー/クライアントとOAM間のすべての相互作用は、WebGate DCC HTTPリバース・プロキシを介して行われます。ユーザーがOAMサーバーに直接アクセスすることはなくなります。

この新しいDCC HTTPリバース・プロキシ機能は、以前のHTTPBasic/FORMのDCCベースのログインとは異なります。後者はフェデレーションSSOフローでは動作しません(IdPモードまたはSPモード)。

概要

この記事には、様々なOAMコンポーネント(OAMサーバー自体またはWebGateエージェント)の前に存在するHTTPリバース・プロキシやロード・バランサを含むトポロジは含まれていませんが、ロード・バランサによって開始されたHAデプロイメントでDCC HTTPリバース・プロキシを使用する方法を示すユースケースが最後まで含まれています。

DCCを使用しない認証

DCCを使用しない認証フローが最も一般的なユースケースで、ユーザーはセキュリティ・ドメイン内のリソースを保護するSSOエージェントからOAMにリダイレクトされ、チャレンジと認証が行われます。一般的なOAMデプロイメントは、次のエンティティで構成されます。

次の図に、このような環境を示します。

図local_security_domain.jpgの説明

テスト・フローで、ローカル・セキュリティ・ドメインのリソースを保護するスキームとしてLDAPScheme OOTBを使用します。

LDAPSchemeを使用したローカル認証フローは、次のもので構成されます。

  1. ユーザーは、LDAPSchemeによって保護されるようにOAMで定義されている保護されたリソースへのアクセスをリクエストします。

  2. WebGate SSOエージェントはHTTPリクエストをインターセプトし、ユーザーを認証する必要があると判断し、認証のためにユーザーをOAMサーバーにリダイレクトします。

  3. ユーザーはOAMサーバーにアクセスし、サーバーはLDAPSchemeを使用して認証フローを開始し、ログイン・ページを表示します。

図local_authentication_flow.jpgの説明

ユーザーが資格証明を入力して「ログイン」ボタンをクリックすると、次の処理が実行されます。

  1. OAMサーバーは、資格証明の検証、ユーザーのセッションの作成、ユーザーのブラウザでのCookieの設定、保護されたリソースへのユーザーのリダイレクトを行います。

  2. ユーザーがリソースへのアクセスをリクエストします。今回、WebGate SSOエージェントは、ユーザーが認証されていることを検出し、リソースへのアクセス権を付与します

図local_security_workflow.jpgの説明

HTTP- Basic/FORMベースのログイン用のDCC

以前のリリースのOAM 11gでは、HTTP- Basic/FORMベースのログイン用のDCCが導入され、管理者が次のエンティティとしてWebGate SSOエージェントを指定できるようになりました。

テスト・フローで、LDAPScheme OOTBに基づくDCCLDAPSchemeを使用しますが、チャレンジURLはDCC WebGateを参照するように更新されています。このスキームは、ローカル・セキュリティ・ドメインのリソースを保護するために使用されます。

そのカスタムDCCLDAPSchemeを使用するローカル認証フローは、次のもので構成されます。

  1. ユーザーは、DCCLDAPSchemeによって保護されるようにOAMで定義されている保護されたリソースへのアクセスをリクエストします。

  2. WebGate SSOエージェントはHTTPリクエストをインターセプトし、ユーザーを認証する必要があると判断し、認証のためにユーザーをDCC Webゲートのログイン・ページにリダイレクトします。

  3. ユーザーはDCC Webゲートのログイン・ページにアクセスし、資格証明を提供します。

  4. DCC WebGateは、OAMサーバーと他のOAM NAPプロトコルと直接対話して資格証明を検証し、ユーザーのセッションを作成します。次に、DCC WebGateは、保護されたリソースにユーザーをリダイレクトします。

  5. ユーザーがリソースへのアクセスをリクエストします。今回、WebGate SSOエージェントは、ユーザーが認証されていることを検出し、リソースへのアクセス権を付与します。

DCC HTTPリバース・プロキシ

DCC HTTPリバース・プロキシは、11.1.2.2.0リリースのOAMで導入され、管理者は、OAMおよびOAMサーバーのパブリック・エンドポイントとして機能するようにWebGate SSOエージェントを構成できます。

ノート: 基本的に、DCC WebGateはOAMおよびOAMのパブリック・エンドポイントになり、OAM NAPプロトコルを介してHTTPリバース・プロキシとして機能します。

このテストでは、OAMおよびWebGateがDCC HTTPリバース・プロキシ用に構成された後、LDAPScheme OOTBをローカル・セキュリティ・ドメインのリソースを保護するスキームとして使用します(スキームは変更されません)。

ノート: 相対パスを含むチャレンジURLを持つ認証スキームは、FederationSchemeなど、このDCCモードで使用できます。また、IdP機能はそのDCCモードと互換性があります

LDAPSchemeを使用したローカル認証フローは、次のもので構成されます。

  1. ユーザーは、LDAPSchemeによって保護されるようにOAMで定義されている保護されたリソースへのアクセスをリクエストします。

  2. WebGate SSOエージェントはHTTPリクエストをインターセプトし、ユーザーを認証する必要があると判断し、認証のためにユーザーをDCC WebGateにリダイレクトします。

  3. ユーザーはDCC WebGateにアクセスし、リクエストをOAMサーバーに転送します。サーバーはLDAPSchemeを使用して認証フローを開始し、DCC WebGateに表示されるログイン・ページを返し、DCC WebGateはログイン・ページをユーザーに表示します。

図local_authentication_flow_LDAP.jpgの説明

ユーザーが資格を入力し、「ログイン」ボタンをクリックすると、次の処理が実行されます。

  1. DCC WebGateは、資格証明を含むHTTPリクエストをOAMサーバーに送信します。これにより、資格証明が検証され、ユーザーのセッションが作成され、Cookieが作成され、Cookieおよびリダイレクト・コマンドを使用してHTTPレスポンスがDCC WebGateに返されます。DCC WebGateは、ユーザーのブラウザにCookieを設定し、ユーザーを保護されたリソースにリダイレクトします。

  2. ユーザーがリソースへのアクセスをリクエストします。今回、WebGate SSOエージェントは、ユーザーが認証されていることを検出し、リソースへのアクセス権を付与します

図local_security_LDAPworkflow.jpgの説明

DCC HTTPリバース・プロキシの設定

初期設定

DCC HTTPリバース・プロキシ用にOAMデプロイメントを構成するために必要なステップは、次のとおりです。

特定のWebGate SSOエージェントをDCC WebGateとして構成するには、次のステップを実行します。

  1. OAM管理コンソール(http(s)://OAM-admin-host:OAM-adminport/oamconsole)に移動します。

  2. Access Manager、SSOエージェントに移動します。

  3. すでに登録したWebGateエントリを検索します。

  4. WebGateエントリをクリックして開きます。

  5. 「資格証明コレクタ操作の許可」ボックスを選択します。

  6. 「ユーザー定義パラメータ」ボックスに、TunneledUrls=/oam,/oamfedという行を追加します。

  7. 「適用」をクリックします。

図Setting_DCC.jpgの説明

OAMおよびOAMサービスの認証ポリシーを更新するには、次のステップを実行します。

  1. OAM管理コンソール(http(s)://OAM-admin-host:OAM-adminport/oamconsole)に移動します。

  2. 「アクセス・マネージャ」、「アプリケーション・ドメイン」にナビゲートします。

  3. DCC WebGateに関連するアプリケーション・ドメインを検索します。

  4. アプリケーション・ドメインを開きます。

  5. 「リソース」タブをクリックします。

  6. リソースを「保護されていない」としてマークし、パブリック認証ポリシーおよびパブリック認可ポリシーを設定することで、次のリソースをパブリック・リソースとして構成します:

  7. 「適用」をクリックします

図Authentication_Policies.jpgの説明

OAM構成を更新して、OAMの新しいパブリック・エンドポイントとしてDCC WebGateを指定するには

  1. OAM管理コンソール(http(s)://OAM-admin-host:OAM-adminport/oamconsole)に移動します。

  2. 「構成」、「Access Managerの設定」にナビゲートします。

  3. OAMサーバー・ホストで、ブラウザを介してDCC WebGateにアクセスするために使用するホスト名を入力します。

  4. OAMサーバー・ポートで、ブラウザを介してDCC WebGateにアクセスするために使用するポートを入力します。

  5. OAMサーバー・プロトコルで、ブラウザを介してDCC WebGateにアクセスするために使用するhttpプロトコルを入力します。

  6. 完了すると、これらの3つのフィールドはDCC WebGate HTTP/HTTPSエンドポイントを参照する必要があります。

  7. 「適用」をクリックします。

図OAM_configuration.jpgの説明

3つの構成変更が完了すると、OAMおよびOAMは、NAPプロトコルを介したHTTPリバース・プロキシとしてDCC WebGateを使用するように構成されます。

テストとして、OAM管理コンソールの「構成使用可能サービス」セクションでフェデレーションが有効になっている場合は、DCCのWebGate URL (http(s)://DCC-webgatehost:DCC-webgate-port/oamfed/idp/metadata)を介してOAMメタデータにアクセスでき、OAM用のSAML 2.0 Metadataが表示されます。設定では、サービスを再起動せずにMetadataが表示され、フェデレーション・サービスのURLはOAMサーバーではなくDCC WebGateの場所を参照しています。

ノート: フェデレーションProviderIDを更新する必要がある場合は、OAM管理コンソール、構成、フェデレーションを使用して更新でき、MetadataのentityID属性に変更が反映されます。

メタデータの例は次のとおりです(entityIDは、OAM管理コンソール、構成、フェデレーション・セクションから導出されます)。

<md:EntityDescriptor entityID="hUp://oam.acme.com
/oam/fed" ...>
  ...
  <md:IDPSSODescriptor>
    ...
    <md:ArtifactResolutionService ...
Location="hUp://dcc-webgate.acme.com:7777
/oamfed/idp/soap"/>
    <md:SingleLogoutService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>     <md:SingleSignOnService ... Location="hUp://dccwebgate.acme.com:7777/oamfed/idp/samlv20"/>
    ...
  </md:IDPSSODescriptor>
  ...
</md:EntityDescriptor>

ローカル認証

テスト・デプロイメントでは、次のものがデプロイされています。

LDAPSchemeはOOTBであり、変更されていません。具体的には、チャレンジURLパラメータはWebGate DCCを参照しません。

図Local_Authentication.jpgの説明

OAM、OAMおよびWebGate2をDCC HTTPリバース・プロキシ用に構成する前に、OHS1で/cgi-bin/printenvで保護されたリソースへのアクセスをリクエストすると、WebGate1によってリクエストがインターセプトされ、認証のためにブラウザがOAMサーバーにリダイレクトされました。

図Access_Manager_Screen.jpgの説明

正しい資格証明を入力すると、OAMはユーザー名/パスワードを検証し、ブラウザを保護されたリソースにリダイレクトしていました。

OAM、OAMおよびWebGate2をDCC HTTPリバース・プロキシ用に構成した後、OHS1で/cgi-bin/printenv保護されたリソースへのアクセスをリクエストすると、WebGate1がリクエストをインターセプトし、リダイレクトしますブラウザで認証のためにDCC WebGateに移動し、ここから表示されるページをDCC WebGateに送信するOAMサーバーにNAPプロトコルを介してHTTPリクエストを転送します。

図Protected_Access_Screen.jpgの説明

正しい資格証明を入力すると、次のようになります。

SPとしてのOAM

このモードは、ローカル認証のユースケースとは少し異なります。異なる点は次のとおりです。

ノート: DCC HTTPリバース・プロキシでFederationSchemeを使用するために特別な構成は必要ありません。

FederationSchemeはOOTBであり、変更されていません。具体的には、チャレンジURLパラメータはWebGate DCCを参照しません。

図Authentication_Schemes.jpgの説明

保護されたリソースがリクエストされると、次のようになります。

  1. ユーザーは、FederationSchemeによって保護されるようにOAMで定義されている保護されたリソースへのアクセスをリクエストします。

  2. WebGate SSOエージェントはHTTPリクエストをインターセプトし、ユーザーを認証する必要があると判断し、認証のためにユーザーをDCC WebGateにリダイレクトします。

  3. ユーザーは、HTTPリクエストをパッケージ化し、NAP経由でOAMサーバーに送信するDCC WebGateにアクセスします。サーバーは、ユーザーがFederationSchemeを介してチャレンジする必要があると判断し、OAM/SPモジュールが起動されます。

  4. OAM/SPはSAMLリクエストを作成し、SAMLメッセージを使用して302のリダイレクトURLを構築します。OAMはデータをパッケージ化し、ユーザーのブラウザにHTTPレスポンスを返すDCC WebGateにレスポンスを送信します。

  5. ユーザーのブラウザは、SAMLリクエストを使用してIdPにリダイレクトされます

図Protected_Resource_Request.jpgの説明

ユーザーがIdPで資格証明を入力すると、次のようになります。

  1. IdPによってSAMLアサーションが作成され、SAMLメッセージを含むユーザーのブラウザがDCC WebGate (SAML 2.0 Metadataで公開されるOAMのフェデレーション・エンドポイント)にリダイレクトされます。

  2. ユーザーのブラウザでは、SAMLアサーションがDCC WebGateに提示され、HTTPリクエストがパッケージ化され、NAP経由でOAMサーバーに送信され、次にOAM/SPモジュールが起動されてSAMLアサーションが処理されます。

  3. OAM/SPはSAMLアサーションを検証し、OAMはユーザー・セッションを作成し、保護されたリソースへの302リダイレクトを構築し、ユーザーのブラウザにHTTPレスポンスを返すDCC WebGateにレスポンスを返します。

  4. ユーザーは保護されたリソースにリダイレクトされます

  5. WebGate SSOエージェントはアクセス権を付与します

図local_security_Webgatedomain.jpgの説明

IdPとしてのOAM

このユースケースでは、OAMはアイデンティティ・プロバイダとして機能し、DCC WebGateはIdPのパブリック・エンドポイントです。この設定では、次を行います。

ノート: DCC HTTPリバース・プロキシでIdPを使用するために特別な構成は必要ありません。

ユーザーがリモートSPからフェデレーションSSOを開始すると、次のようになります。

  1. ユーザーはリモートSPでフェデレーションSSO操作を開始します。

  2. リモートSPはSAMLリクエストを作成し、SAMLリクエストを使用してユーザーをIdP SAML 2.0エンドポイントにリダイレクトします。このエンドポイントは、IdP SAML 2.0 Metadataで公開されているように、DCC WebGate HTTP Reverse Proxyです。

  3. ユーザーは、SAMLリクエストを使用してDCC WebGateのIdPパブリックSAML 2.0エンドポイントにアクセスします。DCC WebGateはHTTPリクエストとSAMLメッセージをパッケージ化し、OAM NAPプロトコルを介してIdPサーバーに転送します。

  4. IdPサーバーは、SAMLリクエストを処理し、ユーザーがLDAPSchemeを介して認証される必要があると判断し、認証のために内部的にOAMを呼び出します。次に、ログイン・ページが表示されるようにDCC WebGateに戻ります。DCC WebGateは、NAP経由で送信されたOAMからのレスポンスをデコードし、ユーザーのブラウザにHTTPレスポンスを返します。

図local_security_FedSSO.jpgの説明

ログイン・ページの表示後、次のようになります。

  1. ユーザーが資格証明を入力し、「ログイン」ボタンをクリックします。

  2. DCC WebGateは、受信データを収集し、パッケージ化して、NAPを介してOAMサーバーに送信します。

  3. OAMは資格証明を検証し、ユーザーのセッションを作成し、ユーザーのアイデンティティを内部的にIdPに返します。フェデレーション・サーバーはSAMLアサーションを作成し、アサーションを含むレスポンスを構築し、それをパッケージ化してDCC WebGateに返します。これにより、データがデコードされ、SAMLアサーションを含むHTTPレスポンスがユーザーのブラウザに送信されます。

  4. ユーザーのブラウザは、アサーションを正常に検証するSAMLレスポンスをSPにポストします。

図local_security_DCCWebgate.jpgの説明

DCC HTTPリバース・プロキシおよびHA

HAデプロイメントでは、様々なコンポーネント(ロード・バランサ、OAM...)の構成に必要なステップは、DCC HTTPリバース・プロキシ機能の使用時にも適用されます。

次のデプロイメントの例を考えてみましょう(他の種類のHAトポロジでは同様のアプローチが使用されます)。

この例のトポロジは次のようになります。

図local_security_Topology.jpgの説明

この例で必要なステップは、次に基づいています。

その他の学習リソース

docs.oracle.com/learnで他のラボを探すか、Oracle Learning YouTubeチャネルで無料のラーニング・コンテンツにアクセスしてください。また、education.oracle.com/learning-explorerにアクセスしてOracle Learning Explorerになります。

製品ドキュメントについては、Oracle Help Centerを参照してください。