同じAPIデプロイメントへの複数の認証サーバーの追加

コンソールを使用して、同じAPIデプロイメントの複数の認証サーバーをAPIデプロイメント仕様に追加するには:

1. コンソールを使用してAPIデプロイメントを作成し、「最初から」オプションを選択して、「基本情報」ページで詳細を入力します。

   詳細は、APIデプロイメントの作成によるAPIゲートウェイへのAPIのデプロイおよびAPIゲートウェイの更新を参照してください。

2. 「次へ」を選択して、「認証」ページを表示します。
3. 入力したコンテキスト変数およびルールに従って、認証リクエストを別の認証サーバーにルーティングするように指定するには、「複数認証」を選択します。
   1. 「セレクタ」リストから、認証リクエストの送信先となる認証サーバーの決定時に使用するコンテキスト表(コンテキスト変数を含む)を次のように選択します。
      • 認証: JWTに含まれている(およびrequest.authコンテキスト表に保存されている)クレームの値を使用して、認証サーバーを決定します。「認証」を選択した場合は、APIデプロイメントのすべての認証サーバー・ルールにJSON Web Token (JWT)タイプの認証サーバーを指定する必要があります。「セレクタ」リストから「認証」を選択した場合、JWTの場所は、すべてのJSON Web Token (JWT)認証サーバー(同じリクエスト・ヘッダーと認可スキーム、または同じ問合せパラメータ)で同じである必要があります。
      • ヘッダー:元のリクエスト(およびrequest.headersコンテキスト表に保存)のヘッダーの値を使用して、認証サーバーを決定します。
      • ホスト:元のリクエストが送信されたホストの名前(リクエスト内のホスト・ヘッダーのホスト・フィールドから抽出され、request.hostコンテキスト表に保存される)を使用して、認証サーバーを決定します。
      • パス:元のリクエスト(およびrequest.pathコンテキスト表に保存)のパス・パラメータを使用して、認証サーバーを決定します。
      • 問合せパラメータ:認証サーバーを決定するには、元のリクエスト(およびrequest.queryコンテキスト表に保存)の問合せパラメータの値を使用します。
      • サブドメイン:元のリクエストが送信されたホスト名の先頭部分(キーとして指定されておらず、request.subdomainコンテキスト表に保存されているホスト名の部分のみ)を使用して、認証サーバーを決定します。キーは、使用しないホスト名の末尾部分です。
   2. 選択したコンテキスト表に応じて、認証リクエストの送信先となる認証サーバーを決定する際に使用するキーの名前を入力します。
4. 「ポリシーの定義」を選択して、コンテキスト変数のルールを入力します。このルールが満たされた場合、認証リクエストは定義した認証サーバーにルーティングされます。
5. 認証サーバー・ルールの詳細を次のように入力します。
   • 名前:認証サーバー・ルールの名前を入力します。ログおよびメトリックを参照する際に、入力した名前を使用して認証サーバーを識別します。この名前は、APIデプロイメントに定義されているすべての認証サーバー・ルールで一意である必要があります。
   • 一致タイプ:リクエストをこの認証サーバーにルーティングするために、コンテキスト変数値が入力した値とどの程度一致する必要があるかを指定します。コンテキスト変数が「値」フィールドの値と完全に一致する必要がある場合は、「いずれか」を選択します。コンテキスト変数が、ワイルドカードを含む「式」フィールドの値と一致する必要がある場合は、「ワイルドカード」を選択します。値の一致では、「いずれか」を選択した場合は大文字と小文字が区別されず、「ワイルドカード」を選択した場合は大文字と小文字が区別されます。
   • 値: (「照合タイプ」フィールドで「いずれか」を選択した場合に表示されます。)コンテキスト変数が正確に一致する必要がある値(またはカンマ区切りリスト内の複数の値)を指定します。「いずれか」を選択した場合、一致では大文字と小文字が区別されないことに注意してください。また、値は、単一の認証サーバー・ルール内、およびAPIデプロイメント用に定義されたすべての認証サーバー・ルール間で一意である必要があります。
   • 式: (「一致タイプ」フィールドで「ワイルドカード」を選択した場合に表示されます)コンテキスト変数が一致する必要があるワイルドカードで始まる値、またはそれで終わる値を指定します。* (アスタリスク)ワイルドカードは、0文字以上の文字を示す場合、+ (プラス記号)ワイルドカードは1文字以上の文字を示す場合に使用します。「ワイルドカード」を選択した場合、一致では大文字と小文字が区別されます。1つの値に複数のワイルドカードを含めることはできず、値の途中にワイルドカードを含めることもできないことに注意してください。
   • デフォルトにする:コンテキスト変数値に一致する他の認証サーバー・ルールがない場合、このルールに定義されている認証サーバーを使用するかどうかを指定します。APIデプロイメントのデフォルトとして指定できる認証サーバー・ルールは1つのみです。ルールがデフォルトとしてマークされておらず、受信リクエストのコンテキスト変数値がAPIデプロイメントに定義された認証サーバー・ルールと一致しない場合、リクエストは401 Unauthorizedエラー・レスポンスを返します。

6. 「匿名アクセスの有効化」チェック・ボックスを選択または選択解除して、認証されていない(つまり、匿名)エンド・ユーザーがAPIデプロイメントのルートにアクセスできるかどうかを指定します。

   デフォルトでは、このオプションは選択されていません。匿名のユーザーがルートにアクセスできないようにする場合は、このオプションを選択しないでください。このオプションを選択した場合は、各ルートの認可ポリシーで「匿名」を「認可タイプ」として選択することで、匿名アクセスを許可する各ルートを明示的に指定する必要もあります。

7. 次のように、認証サーバーの詳細を入力します。
   1. 「認証タイプ」フィールドで、入力したルールが満たされた場合に認証リクエストのルーティング先となる認証サーバーとして、「JSON Webトークン(JWT)」または「認可プロバイダ・ファンクション」を選択します。

      「セレクタ」リストから「認証」を選択した場合は、認証サーバーのタイプとして「JSON Web Token (JWT)」を選択する必要があります。「セレクタ」リストから「認証」を選択した場合、JWTの場所は、すべてのJSON Web Token (JWT)認証サーバー(同じリクエスト・ヘッダーと認可スキーム、または同じ問合せパラメータ)で同じである必要があります。

   2. 選択した認証サーバーの詳細を入力します。入力する詳細は、選択した認証サーバー・タイプによって異なります:
      • JSON Webトークン(JWT)認証サーバーについては、コンソールを使用したトークン認証および認可リクエスト・ポリシーの追加を参照してください。
      • 認可プロバイダ・ファンクション認証サーバーの場合、認可プロバイダ・ファンクションの名前、それを含むOCIファンクションのアプリケーションを指定し、「複数引数の認可プロバイダ・ファンクション」または「単一引数の認可プロバイダ・ファンクション」を選択します。詳細は、次を参照してください:
        • コンソールを使用した複数引数の認証および認可のリクエスト・ポリシーの追加
        • コンソールを使用した単一引数の認証および認可のリクエスト・ポリシーの追加
   3. 「定義」を選択して、認証サーバーと関連ルールを作成します。
8. オプションで、「ポリシーの定義」を再度選択して、追加の認証サーバーおよび関連するルールを定義します。
9. 「次」を選択して、「ルート」ページのAPIデプロイメント内の個々のルートの詳細を入力します。
10. 「変更の保存」を選択し、「次」を選択してAPIデプロイメントに入力した詳細を確認します。
11. APIデプロイメントを作成または更新するには、「作成」または「変更の保存」を選択します。
12. (オプション) コールしてAPIが正常にデプロイされていることを確認します(APIゲートウェイにデプロイされたAPIのコールを参照)。

同じAPIデプロイメントの複数の認証サーバーをJSONファイルのAPIデプロイメント仕様に追加するには:

1. 任意のJSONエディタを使用して、次のフォーマットで新しいAPIデプロイメント仕様を作成します(APIデプロイメント仕様の作成を参照):

   {
     "requestPolicies": {
       "dynamicAuthentication": {
         "selectionSource": {
           "selector": "<context-table-key>",
           "type": "SINGLE"
         },
         "authenticationServers": [
           {
             "key": {
               "type": "<ANY_OF|WILDCARD>",
               "values": ["<context-variable-value>"],
               "isDefault": "<true|false>",
               "name": "<rule-name>"
             },
             "authenticationServerDetail": {
               "type": "<authentication-server-type>",
               "<auth-server-attribute-name>": "<auth-server-attribute-value>",
               ...
               "<auth-server-attribute-name>": "<auth-server-attribute-value>"
             }
           }
         ]
       }
     },
     "routes": []
   }

   ここでは:

   • "dynamicAuthentication"は、リクエスト内の要素に基づいて、リクエストの認証に使用する認証サーバーをAPIゲートウェイで動的に選択することを指定します。
   • "selector": "<context-table-key>"は、認証リクエストの送信先となる認証サーバーを決定するコンテキスト変数値を取得するコンテキスト表(および該当する場合はキー)を次のように指定します。
     • request.auth[<key>] JSON Webトークン(JWT)に含まれるクレームの値を使用して、認証サーバーを決定します。<key>はクレームの名前です。たとえば、request.auth[tenant]です。request.auth[<key>]を指定する場合は、APIデプロイメントのすべての認証サーバー・ルールに対して、JWT_AUTHENTICATIONタイプの認証サーバーを指定する必要があります。request.auth[<key>]を指定する場合、JWTの場所は、すべての認証サーバー(同じリクエスト・ヘッダーと認可スキーム、または同じ問合せパラメータ)で同じである必要があります。
     • request.headers[<key>]元のリクエストからのヘッダーの値を使用して、認証サーバーを決定します。<key>はヘッダー名です。たとえば、request.headers[Accept]です。
     • request.host元のリクエストが送信されたホストの名前(リクエストのホスト・ヘッダーのホスト・フィールドから抽出)を使用して、認証サーバーを決定します。
     • request.path[<key>]認証サーバーを決定するには、元のリクエストのパス・パラメータを使用します。<key>はパス・パラメータ名です。たとえば、request.path[region]です。
     • request.query[<key>]元のリクエストからの問合せパラメータの値を使用して、認証サーバーを決定します。<key>は問合せパラメータ名です。例: request.query[state]
     • request.subdomain[<key>]元のリクエストが送信されたホスト名の先頭部分(キーとして指定されていないホスト名のその部分のみ)を使用して、認証サーバーを決定します。<key>は、使用しないホスト名の末尾の部分です。例: request.subdomain[example.com]
   • "type": "SINGLE"は、認証サーバーを動的に選択するために単一のコンテキスト変数を使用することを指定します。
   • "key": {...}は、"authenticationServerDetail": {...}で指定された認証サーバーにリクエストを送信するために満たす必要があるルールを指定します。
   • "type": "<ANY_OF|WILDCARD>"は、リクエストが"authenticationServerDetail": {...}で指定された認証サーバーに送信されるために、<context-table-key>で識別されるコンテキスト変数の値が<context-variable-value>に入力した値にどの程度一致する必要があるかを指定します。<context-table-key>で識別されるコンテキスト変数の値が、<context-variable-value>で指定した値と完全に一致する必要がある場合は、ANY_OFを指定します。<context-table-key>で識別されるコンテキスト変数の値が、<context-variable-value>に指定したワイルドカードを含む値と一致する必要がある場合は、WILDCARDを指定します。値一致では、ANY_OFを指定する場合は大/小文字が区別されず、WILDCARDを指定する場合は大/小文字が区別されます。
   • <context-variable-value>は、<context-table-key>で識別されるコンテキスト変数の値と一致する可能性がある値です。複数の"<context-variable-value>"エントリをvalues:[...]配列にカンマで区切って含めることができます。値が一致する場合は、次のように、"authenticationServerDetail": {...}で指定された認証サーバーにリクエストが送信されます。
     • "type": "ANY_OF"を指定した場合、値は完全に一致する必要があります。値は、1つの認証サーバー・ルール内、およびAPIデプロイメントに定義されているすべての認証サーバー・ルール全体で一意である必要があります。ANY_OFを指定した場合、値の一致は大/小文字が区別されません。
     • "type": "WILDCARD"を指定した場合は、ワイルドカードで始まる、またはワイルドカードで終わる<context-variable-value>の値を指定できます。*(アスタリスク)ワイルドカードを使用して0文字以上の文字を指定し、+(プラス記号)ワイルドカードを使用して1文字以上の文字を指定します。1つの値に複数のワイルドカードを含めることはできません。また、値の途中にワイルドカードを含めることはできません。WILDCARDを指定した場合、値の一致は大/小文字が区別されます。
     たとえば、(リクエストのAcceptヘッダーに示されている) xmlレスポンスを受け入れることができるAPIクライアントからのリクエストを特定の認証サーバーにルーティングする場合は、次のように指定します。
     • "selector": "request.headers[Accept]"
     • "type": "ANY_OF"
     • "values": ["application/xml"]
   • "isDefault": "<true|false>"はオプションのブール値(trueまたはfalse)で、他の認証サーバー・ルールがコンテキスト変数値と一致しない場合、このルールに認証サーバーを使用するかどうかを示します。指定しない場合、"isDefault": "false"であると判断されます。APIデプロイメントのデフォルトとして指定できる認証サーバー・ルールは1つのみです。デフォルトとしてマークされたルールがなく、受信リクエストのコンテキスト変数値がAPIデプロイメントに定義された認証サーバー・ルールと一致しない場合、リクエストは401 Unauthorizedエラー・レスポンスを返します。
   • "name": "<rule-name>"は、ルールの名前を指定します。この名前を使用して、ログおよびメトリックを参照するときに認証サーバーを識別します。この名前は、APIデプロイメントに定義されているすべての認証サーバー・ルールで一意である必要があります。
   • "type": "<authentication-server-type>"は、認証サーバーのタイプを指定します。有効な値は、JWT_AUTHENTICATIONおよびCUSTOM_AUTHENTICATIONです。request.auth[<key>]を指定した場合は、APIデプロイメントのすべての認証サーバー・ルールに対して、JWT_AUTHENTICATIONタイプの認証サーバーを指定する必要があります。request.auth[<key>]を指定した場合、JWTの場所は、すべての認証サーバー(同じリクエスト・ヘッダーと認可スキーム、または同じ問合せパラメータ)で同じである必要があります。
   • "<auth-server-attribute-name>": "<auth-server-attribute-value>"は、指定した認証サーバーのタイプの属性および属性値です。入力する属性および属性値は、指定した認証サーバー・タイプのタイプによって異なります。
     • JWT_AUTHENTICATION認証サーバーについては、「JSONファイルの編集によるトークン認証および認可リクエスト・ポリシーの追加」を参照してください
     • CUSTOM_AUTHENTICATION認証サーバーについては、次を参照してください。
       • JSONファイルの編集による複数引数認証および認可のリクエスト・ポリシーの追加
       • JSONファイルの編集による単一引数の認証および認可のリクエスト・ポリシーの追加

   たとえば、次のAPIデプロイメント仕様には、リクエストで渡されたvehicle-type問合せパラメータの値に基づいて認証リクエストを処理する動的認証サーバー選択が含まれています。この例の詳細は、例1: 問合せパラメータ(ワイルドカード選択およびデフォルトを含む)を使用した認証サーバーとしてのJWTまたはサーバーレス関数の選択を参照してください。

   {
     "requestPolicies": {
       "dynamicAuthentication": {
         "selectionSource": {
           "selector": "request.query[vehicle-type]",
           "type": "SINGLE"
         },
         "authenticationServers": [
           {
             "key": {
               "type": "ANY_OF",
               "values": ["car"],
               "isDefault": "true",
               "name": "authServer1"
             },
             "authenticationServerDetail": {
               "type": "JWT_AUTHENTICATION",
               "tokenHeader": "Authorization",
               "tokenAuthScheme": "Bearer",
               "isAnonymousAccessAllowed": true,
               "issuers": ["https://recommend-app.eu.auth0.com/"],
               "audiences": ["api.dev.io"],
               "maxClockSkewInSeconds": 0,
               "verifyClaims": [
                 {
                   "key": "gty",
                   "value": ["client-credentials"],
                   "isRequired": true
                 }
               ],
               "publicKeys": {
                 "type": "REMOTE_JWKS",
                 "uri": "https://recommend-app.eu.auth0.com/.well-known/jwks.json",
                 "maxCacheDurationInHours": 1
               }
             }
           },
           {
             "key": {
               "type": "WILDCARD",
               "expression": "mini*",
               "name": "authServer2"
             },
             "authenticationServerDetail": {
               "type": "CUSTOM_AUTHENTICATION",
               "functionId": "ocid1.fnfunc.oc1.iad.aaaaaaaaac______dfa",
               "isAnonymousAccessAllowed": true
             }
           }
         ]
       }
     },
     "routes": []
   }

2. APIデプロイメント仕様を含むJSONファイルを保存します。

3. APIデプロイメント仕様は、次の方法でAPIデプロイメントを作成または更新するときに使用します:

   • 「既存のAPIのアップロード」オプションを選択して、コンソールでJSONファイルを指定します
   • APIゲートウェイREST APIへのリクエストでJSONファイルを指定します

   詳細は、APIデプロイメントの作成によるAPIゲートウェイへのAPIのデプロイおよびAPIゲートウェイの更新を参照してください。

4. (オプション) コールしてAPIが正常にデプロイされていることを確認します(APIゲートウェイにデプロイされたAPIのコールを参照)。