ポータルアプリケーションを追加する

受信トラフィックを特定のバックエンドサーバーにルーティングするために、ヘッダーベースのアプリケーションを作成し、構成します。

Access Gatewayアプリケーションは、ポリシーと特別なポリシー構成を使用してポータルアプリケーションを作成できます。ポータルは、アクセスポリシーとURIリクエストに基づき、特定のバックエンドサーバーに一部のトラフィックを誘導し、残りのトラフィックを別のバックエンドサーバーに誘導します。

アーキテクチャ

ユーザーがリソースを要求すると、ポータルはリクエストを受け取り、適切なバックエンドサーバーに送信します。各リクエストは、コアURL(たとえば、www.myportal.com)と、コアURLに続く要素である特定のリソース(例:前の図の/2nd参照)から構成されます。

これは、前述のアーキテクチャ図で示したように、www.myportal.com/2ndへのリクエストは2ndbackend.myportal.comへ、www.myportal.com/3rdへのリクエストは3rdbackend.myportal.comへ、それ以外のリクエストはbackend.myportal.comにルーティングされます。

書き換え

ポータルアプリケーションは、複数のバックエンドサーバーへのアクセスを定義するために、カスタムポリシーおよび構成を使用します。デフォルトポリシーは、他のポリシーに該当しないURIを、デフォルトのバックエンドアプリケーションにリダイレクトします。追加のポリシーステートメントとその設定は、リクエストを書き換え、リクエストを特定のバックエンドアプリケーションにリダイレクトするために使用されます。

次の表は、期待される動作を満たすために、ユーザーリクエストがどのように書き換えられるかの例を示しています。

ユーザーリクエスト 期待される動作

インバウンドおよびアウトバウンドの書き換え

myportal.com/ backend.myportal.comにリダイレクトされます。 backend.myportal.com

myportal.com/

myportal.com/abc.htm backend.myportal.com/abc.htmにリダイレクトされます。 backend.myportal.com/abc.htm

myportal.com/abc.htm

myportal.com/2nd /2ndに基づき2ndbackend.myportal.comにリダイレクトされます。 2ndbackend.myportal.com

myportal.com/2nd

myportal.com/2nd/efg.html /2ndに基づき2ndbackend.myportal.comにリダイレクトされます。

インバウンドの書き換えで/2ndを取り除きます。アウトバウンドの書き換えで/2ndを追加し直します。

2ndbackend.myportal.com/efg.htm

myportal.com/2nd/efg.htm

myportal.com/3rd /3rdに基づき3rdbackend.myportal.comにリダイレクトされます。 3rdbackend.myportal.com

myportal.com/3rd

myportal.com/3rd/hij.html /3rdに基づき3rdbackend.myportal.comにリダイレクトされます。

インバウンドの書き換えで/3rdを取り除きます。アウトバウンドの書き換えで/3rdを追加し直します。

3rdbackend.myportal.com/hij.htm

myportal.com/3rd/hij.htm

以下のセクションでは、前述の例に適用された各ポリシーについて説明します。

デフォルト

デフォルトポリシーは、他の特定のポリシーと一致しないすべてのリクエストに適用されます。デフォルトポリシーによって、リクエストはデフォルトアプリケーションドメインに対して書き換えられ、その後バックエンドアプリケーションに転送されます。リクエストが処理された後、結果は元のドメインに書き戻され、返されます。

/2ndへのリクエストのポリシーの書き換え

後続の各バックエンドには、必要に応じてリクエストを書き換えるためのポリシーと高度な構成が含まれています。この例では、ポリシーは、書き換えをトリガーするルートURIとして/2ndを指定します。書き換えルールはURIを削除し、リクエストをセカンダリバックエンドアプリケーション(2ndbackend.myportal.com)にリダイレクトします。

/3rdへのリクエストのポリシーの書き換え

後続の各バックエンドには、必要に応じてリクエストを書き換えるためのポリシーと高度な構成が含まれています。この例では、ポリシーは、書き換えをトリガーするルートURIとして/3rdを指定します。書き換えルールはURIを削除し、リクエストをセカンダリバックエンドアプリケーション(3rdbackend.myportal.com)にリダイレクトします。

はじめに

  • アプリケーションで使用する外部URLを決定します(この例ではwww.myportal.com
  • 可能なURIの範囲とそれに関連するバックエンドを決定します。たとえば、サンプルアーキテクチャには次のものを使用します:

    www.myportal.com/2nd > 2ndbackend.myportal.com

    www.myportal.com/3rd > 3rdbackend.myportal.com

    他のすべてのURIではバックエンドとしてbackend.myportal.comを使用します。

  • 認証で必要なすべての必須ヘッダー属性を決定します。

一般的なワークフロー

タスク

説明

包含するグループを作成する

ベストプラクティスとして、アプリケーションに割り当てる任意グループを作成します。

ヘッダーアプリケーションを作成する

共有された共通バックエンドをデフォルトとするヘッダーアプリケーションを作成します。

ポータルアプリケーションに証明書を割り当てます

任意で証明書をアプリケーションに割り当てます。

その他の属性を追加する

(任意ですが、多くは必須の)その他の属性をアプリケーションに追加します。

必要なアクセスポリシーを追加する

すべてのサービスURIに対して必要なポリシーを追加します。

アプリケーションをテストする

ヘッダーおよびポリシーシミュレーションを使用してアプリケーションをテストします。