ポータルアプリケーションを追加する
受信トラフィックを特定のバックエンドサーバーにルーティングするために、ヘッダーベースのアプリケーションを作成し、構成します。
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に対して必要なポリシーを追加します。 |
アプリケーションをテストする |
ヘッダーおよびポリシーシミュレーションを使用してアプリケーションをテストします。 |