高度なAccess Gatewayポリシーを開発する
高度なポリシーは、1つ以上のステートメントで構成されます。ポリシーステートメントは：
- 指定した順序で実行します。
- セミコロンで終わります。
- 変数を定義できます。
- Access GatewayとHTTPセッション変数の参照と更新ができます。
- if/then形式の条件構文をサポートします。
- ステートメントをブロックにグループ化することをサポートします。
- 短絡をサポートし、その時点で実行を停止させます。
- HTTPステータスコードの変更および返しをサポートします。
- URLの書き換えをサポートします。
既知の問題
以前に作成した有効なポリシーの編集と検証
以前に有効だったポリシーカスタム構成の構文エラーが検出されない場合があります。Oktaは、ポリシーコードの検証にのみ使用される新しいポリシーで、更新されたポリシーカスタム構成ステートメントを検証し、検証の直後に破棄することを推奨します。
高度なポリシーを定義する
高度なポリシーを定義するには：
- Access Gateway 管理者 UI コンソールにサインインします。
- [Application（アプリケーション）]タブをクリックします。
- ［Edit（編集）］をクリックします。
- [Policies（ポリシー）]をクリックします。
- ［Edit（編集）］をクリックします。
- [Advanced（詳細設定）]を展開します。
- [Custom Configuration（カスタム構成）]ボックスで、高度なポリシーを入力します。For example:set $TEST "some value"; proxy_set_header header_test $TEST;
-
カスタム構成の構文を検証するには[Not Validated（未検証）]をクリックします。検証が問題なく終了したら、ボタンが[Validated（検証済み）]に変わります。変わらない場合、構文エラーを修正して再検証します。
- [Okay（OK）]をクリックしてカスタム構成を保存します。
- [Done（完了）] をクリックしてアプリケーション編集セッションを完了します。
カスタム構成
カスタム構成はコメント、1つ以上のステートメント、セッションデータ、さまざまなテストの実行、それらのテストでのフォローアップアクションの実行により構成されます。カスタム構成は以下の構造をサポートします。
コメント
すべてのコメントの前には#を付けます。
#This is a comment. #This comment, preceded by a space. set $TEST "some value"; #this is also a valid comment.埋め込み変数または事前定義変数
埋め込み変数には、すべてのHTTPセッション、クッキー、クエリ、リクエストヘッダーフィールド、50を超える名前付き変数が含まれます。これらの変数に名前を付けてアクセスする場合は、プレフィックスを使用するのが一般的です。一般的なプレフィックスには次のものがあります。
| Prefix（プレフィックス） |
用途 |
例 |
|---|---|---|
| arg_ |
クエリ引数へのアクセス |
arg_name、nameはクエリ変数を表します。 |
| cookie_ | クッキーフィールドへのアクセス | cookie_name、nameは任意のクッキーフィールドを表します。 |
| http_ | 任意のヘッダーフィールドへのアクセス | http_emailのemailは、ヘッダーの任意のフィールドを表します。 |
| sent_http_ | レスポンスヘッダーフィールド | sent_http_emailのemailは、レスポンスヘッダーの任意のフィールドを表します。 |
変数のリストの一部には、次のものがあります。
- $args－リクエスト内のすべての引数
- $request_uri－完全なオリジナルのリクエストURI（引数付）
- $uri－リクエスト内のコンテンツURI
- $request_body－リクエスト本文
次の手順を参照してください： 「埋め込み変数」を参照してください。
ユーザー変数
カスタム構成で変数を定義することができます。割り当てや条件ステートメントで使用できます。
一般的な形式：
set $variablename value;例：
条件
条件ステートメントでは、変数の状態に応じてコードを実行するかどうかを選択できます。
条件ステートメントの一般的な形式：
if (condition) { statement1; statement2; . . . statementn; }conditionは：
- 変数名偽の場合、空か0とし、それ以外の場合は真です。
- 等式（=）演算子と不等式（!=）演算子を使用した2つの変数の比較。
- 正規表現に対する変数の照合。
例：
if ($arg_test = "demo") { set $policy_type "NO_AUTH";}
さらに、breakディレクティブは追加のステートメントの実行を停止します。breakディレクティブの使用例を次に示します。
if ($arg_test = "demo") { set $policy_type "NO_AUTH"; break; } #Statements after break not executed if condition is trueifステートメントに関する詳細については、「ifステートメント」を参照してください。
リターンコード
処理を停止し、指定したコードをクライアントに返します。
一般的な形式：
return numericReturnCode [optional url];例：
#Stop executing and return a 404 return 404;ディレクティブ
プログラミング言語の関数呼び出しと同様に、カスタム構成からディレクティブを呼び出します。ディレクティブはパラメータの場合があります。次の手順を参照してください： すべてのNGNIXディレクティブのアルファベット順のリスト
ディレクティブの一般的な形式：
directive_name [parameter1 [parameter2 [parametern]]];カスタム構成はロケーションコンテキストを指定するディレクティブのみをサポートします。例：
ディレクティブの例には次のものがあります。
プロキシ非表示ヘッダー
デフォルトでは、特定のヘッダーフィールドは非表示です。proxy_hide_headerフィールドディレクティブを使用して、他のヘッダーを非表示にすることができます。
一般的な形式：
proxy_set_header field value;valueにはテキスト、変数、およびそれらの組み合わせが含まれます。
例：
proxy_set_header Host $proxy_host;プロキシ設定ヘッダー
リクエストヘッダーにフィールドを再定義または追加できます。
一般的な形式：
proxy_hide_header field;例：
proxy_hide_header secondaryEmailAddress;プロキシリダイレクト
プロキシサーバーレスポンスの[Location（ロケーション）]および[Refresh（更新）]ヘッダーフィールドで変更する値を指定します。
一般的な形式：
proxy_redirect redirect replacement;例：
proxy_redirect http://general.domain.tbd/abc http://abc.domain.tld;