※ 本記事は、Michael Fischerによる”OCI API Gateway and OpenID Connect Authentication with IAM Domain, IDCS and Azure AD/B2C“を翻訳したものです。
2023年8月16日
Oracle Cloud Infrastructure (OCI) API Gatewayでは、認証および認可を使用してAPIを保護できます。これは、デプロイメントの構成およびゲートウェイ上のルート(オプション)によって強制されます。通常、正しい署名、対象者および発行者に対して少なくとも証明されているJWTの場合です。署名テストは静的キーで最速ですが、署名を変更したために署名テスト用のライブURLを使用できます。有効なJWTがない場合は、401が認可されていないデフォルト構成でコールが終了します。
API Gatewayは2022年末からOpenID Connectをサポートしています。つまり、コールが認可されていない場合、API Gatewayは、構成されたOIDCプロバイダにコール元をリダイレクトできます。OpenID Connectの認可コード・フローがトリガーされ、さらにトークン処理に必要なスコープ(少なくともopenid)がリクエストされます。いくつかのオプションと依存関係があるため、このブログではIDCS/IAMドメインの構成を示し、現在のAzure AD B2C統合について説明します。これはAlberto CampagnaとMichael Fischerからの共通ブログです。
API Gatewayには多くのユースケースがあります。たとえば、プライベート・オブジェクト・ストレージにマテリアルがあり、認証済およびオプションの認可済ユーザーのみにそれを配信する場合などです。
このOpenIDをAPI Gatewayで使用するには、OpenIDサーバー(認可サーバー)がイントロスペクトAPIを提供する必要があります。Azure ADおよびAzure B2Cは、2023年8月現在、イントロスペクションをサポートしていません。API Gatewayでの認証およびオプションの認可としてAzure ADおよびAzure B2Cを使用する可能性は、次のとおりです。:
- API Gatewayで認可プロバイダFNを使用: これを使用して、トークン処理を独自にコーディング
- Azure ADまたはAzure B2Cを介したフェデレーテッド・ログインでIDCS/IAMトークンを使用
現在のブログには、IDCS/IAMドメインとの統合が含まれています。Azureフェデレーションの設定については、ドキュメントまたはその他のブログを参照してください。
設定:
事前条件
最初の前提条件は既存のAPI Gatewayです。API Gatewayに認証なしでデプロイメントにアクセスでき、標準レスポンスのあるルートを使用できる場合に、簡単にテストできます。
2つ目の前提条件は、OIDCサーバーで定義されたOAuthクライアントです。このクライアントは、トークンおよびOpenID Connect認可コード・フローのイントロスペクションに使用されます。このために、クライアントは、1) 代理でイントロスペクションを実行し、2) OIDCコード・フローをトリガーする関連認可を必要とします。ClientIDおよびSecretを、さらに処理するために必要に応じてコピーします。ルートがすでにわかっている場合は、リダイレクトURLにルートを追加します。後で追加することもできます。リダイレクトURLは、コード・フローに必要であり、すべてのルートに必要です。次のサンプルでは、イントロスペクト用とコード・フロー用の2つの異なるクライアントが使用されています。
3つ目の前提条件は、事前条件2からOAuthクライアントのシークレットを格納するOCI Vaultがあることです。OCI Vaultでシークレットを作成するには、OCI VaultとOCI Vaultキーが事前に必要です。存在しない場合は作成します。OCI Vaultシークレットを作成し、IAMドメインとAzureの両方のケースでテキストとして、テキスト形式で値をコピーします。Vaultのシークレット名およびコンパートメントとシークレットは、設定で指定する必要があることに注意してください。
API GWがシークレットにアクセスできるようにOCIポリシーが設定されていることを確認します。これには、ゲートウェイを指定する動的グループと、このグループがボールトおよびシークレットを読み取れるようにするステートメントを含むポリシーを作成する必要があります。ポリシーのドキュメントを参照してください。
次のようになります。
ステップ
ステップ1 新しいデプロイメントを作成し、認証(例: 単一認証)を設定します。これにより、さらに構成が開きます
ステップ2 認証、構成および値を構成します。:
- Authentication type: OAuth 2.0 / OpenID Connect
- Token location: Header
- JWT Name: Authorization
- Authentication Scheme: Bearer
- Validation: OAuth 2.0 イントロスペクション・エンドポイント
- Client IDとSecret (OCI Vault経由)を指定する必要があります。
- プロバイダのOpenIDエンドポイントの検出URL
IDCS/IAMドメインの場合:
検出URLは一般的なURLではありません
ttps://idcs-9f7xxxx.identity.oraclecloud.com/.well-known/idcs-configuration
ただし、openidに固有です(サンプルを参照)。誤りを使用すると、実行時に500の内部サーバー・エラーが発生します。
https://idcs-9f7xxxx.identity.oraclecloud.com/.well-known/openid-configuration
次の構成に指定する場合は、ブラウザでこのURLをコールして発行者を表示します。
オプションの設定:
- issuers: IDCS “https://identity.oraclecloud.com/” の前または後に検出URLから値を入力
- audiences: これは、フローに指定されたスコープによって異なります。
- 複数の値を受け入れると、IAMのインスタンスと2番目のエントリ・クライアントIDを追加できます。
- Claims: より具体的なトークンを強制するように設定できます。
詳細設定:
- Validation failure policy: OAuth2.0リダイレクト・クライアントからアイデンティティ・プロバイダを選択
- scopes: イントロスペクトURLには、少なくともopenid、さらにサポートされる値が表示され、ClientIDになります。
- response type: code
- イントロスペクト・クライアントを使用しない場合、認可コード・フロー・クライアントのClientIDおよびシークレットを指定します
権限が最小であるため、2つのクライアントを使用することをお薦めします。
ステップ3 ストック・レスポンスなど、1つ以上のルートを指定します
注意: リダイレクトURLとしてコード・フロー・クライアントに完全なURLを追加します。
ケース IDCS/IAMドメイン
ルートが1つしかない場合、これはUIを介して機能し、複数のルートで残りのクライアントとAPIを使用する場合:
https://docs.oracle.com/en/cloud/paas/iam-domains-rest-api/op-admin-v1-apps-id-patch.html
3つのルートのサンプル:
curl --location --request PATCH 'https://idcs-9f7xxxx.identity.oraclecloud.com/admin/v1/Apps/af3xxx' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer eyJ4NXQxxxx' \ --data '{ "schemas": [ "urn:ietf:params:scim:api:messages:2.0:PatchOp" ], "Operations": [{ "op": "replace", "path": "redirectUris", "value": [ "https://c5axxxx.apigateway.eu-frankfurt-1.oci.customer-oci.com/test/test1", "https://c5axxxx.apigateway.eu-frankfurt-1.oci.customer-oci.com/test/test2", "https://c5arxxxx.apigateway.eu-frankfurt-1.oci.customer-oci.com/testx/test" ] }] }'
ステップ4 新しいブラウザでルートをコールしてみる
これは、IDCS/Azureログインにリダイレクトされ、APIの正常なログイン後にリダイレクトされます。
エラーの場合は、「トラブルシューティング」の項を参照してください。
トラブルシューティング:
構成中:
- デプロイメントの認証設定を保存できません
仮定はすべて必須の値が設定されています
UIは少し不公平です。セクションJWT検証(発行者、対象者など)に値を設定し、後で削除すると格納できなくなります。APIまたは新規デプロイメントのいずれかを使用します。 - アクセスできないシークレット
UIで、「リソース・プリンシパルを使用してOpenID Connectシークレットを取得できません….」と表示されます。 処置: ドキュメント内のポリシーを確認してください。
実行中:
デプロイ時のLogleve (APIロギング・ポリシーの設定)またはルート(ロギング・ポリシーの表示セクション)が最大(情報レベル)に設定されていることを確認します。
関連するデプロイメントのAPI Gatewayでアクセスおよび実行ログを有効にします。
ログに最大の詳細があることを確認します。これは、ルート内のレベル “情報” を意味します。
ログを検索します。一般的なエラーは
- 不正なSecret/Client
{“code”:401、”message”:”Unauthorized”}などのブラウザ・メッセージ
間違ったClientIDまたはSecretについても同じエラーです
アクセス・ログには、302のルートのみが表示されます
実行ログに、「アイデンティティ・プロバイダへのコールがエラーで失敗しました: invalid_client」と表示されています
アクション: ClientIDおよびSecretをチェックして修正します。OIDCプロバイダのRestAPIは、コールがまったく機能するかどうかを確認する残りのクライアントで使用できます。 - リダイレクト・エラー/正常ではないログイン
{“error”:”invalid_redirect_uri”、”error_description”:”Client 5cxxxが無効なリダイレクトURLを要求しました: https://c5axxxx.apigateway.eu-frankfurt-1.oci.customer-oci.com/test/1. ECID: KhU7xxxx”}
アクセス・ログには、ログインへの302リダイレクトのみが表示されます
実行ログには、”タイプがOAUTH2のFound Validation Failure Policyが示されています。OAUTH2を開始しています”
アクション: OAuth Clientで「リダイレクトURL」を訂正してください。これはAPI GWルートのフルパスである必要があります。 - 指定した発行者または対象者が正しくありません:
ブラウザ: {“code”:401,”message”:”Unauthorized”}で終わるERR_TOO_MANY_REDIRECTS
API GWはトークンを数回取得しようとした後、トークンが無効なため、何回か繰り返して停止します。最後に、ログ・メッセージは「State value mismatch during OAuth2」です。この理由は、「”Token not issuers.” or case of wrong Audience “Token not issue for the configured Audience”」の前のメッセージです。
処理: 発行者/対象者をチェックおよび訂正します。値がわからない場合は、指定されたJWTをつかみ、発行者/対象者を確認します。
- {“code”:502,”message”:”Bad Gateway”}
これは、API Gatewayでリクエストを実行できないように、API Gatewayの構成の誤りを示します。ゲートウェイの実行ログを確認してください。
リンク
OIDC Flows: https://openid.net/specs/openid-connect-basic-1_0.html
IDCS/IAMリダイレクトURLを設定するREST API: https://docs.oracle.com/en/cloud/paas/iam-domains-rest-api/op-admin-v1-apps-id-patch.html