高度な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;