本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。
Higress: AIネイティブAPIゲートウェイとしての強化された認証機能
Higressは、強力なAIネイティブAPIゲートウェイであり、AIと現実世界のサービスを結びつけることに優れています。その中核的な能力の一つは、既存のOpenAPI仕様をシームレスにMCPサーバーに変換するサポートです。これにより、AIエージェントは迅速かつコスト効率よく多数のAPIに接続でき、それらを直ちにアクセス可能なツールに変換し、AIがデジタル世界と相互作用するための最短ルートを提供します。
HigressでホストされているMCPサーバーを介してAIと外部サービスを統合する際には、通常、次の2つの主な認証ステージがあります:
-
クライアントからMCPサーバーへの認証:これは、MCPクライアント(例:AIエージェント)がMCPサーバーがホストされているHigress Gatewayエンドポイントに対して行う認証です。Higressは、このステージのために強力なゲートウェイレベルの認証メカニズムを提供しており、Key Auth、JWT Auth、OAuth2のサポートなどがあります。これらの既存のHigress機能により、承認されたクライアントのみがMCPサーバーにアクセスできるようになります。
-
MCPサーバーからバックエンドAPIへの認証:承認されたクライアントがMCPツールを呼び出すと、MCPサーバープラグイン自体がそのツールが表す最終的なバックエンドREST APIに対して認証を行う必要がある場合があります。今回の発表では、第2ステージの大幅な強化に焦点を当てています。具体的には、Higress MCPサーバープラグイン内でバックエンドREST APIとの通信における包括的なAPI認証機能を提供します。このアップデートにより、開発者は資格情報や認証フローを管理する柔軟で堅牢なメカニズムを活用して、より幅広いバックエンドサービスを安全に統合することが可能になります。すべての設定はMCPサーバープラグイン内で行われ、OpenAPI標準に準拠しています。
新しく追加されたコア認証機能(MCPサーバーからバックエンドAPIへ)
このリリースでは、API認証を管理するためのいくつかの重要な機能が導入されました:
- 再利用可能なセキュリティスキーム:サーバーレベルで共通の認証方法(HTTP Basic、HTTP Bearer、API Key)を定義します。
- ツール固有のバックエンド認証:定義されたセキュリティスキームを個々のツールに適用し、MCPサーバーがバックエンドREST APIを呼び出す際にどのように自身を認証するかを指定します。
- 透過的な資格情報パススルー:強力な機能で、MCPクライアント(例:AIアシスタント)によって提供された資格情報を安全にバックエンドAPIに渡すことができます。
- 柔軟な資格情報管理:スキームレベルでのデフォルト資格情報のサポートと、特定のツールに対してそれを上書きする機能。
これらを活用する方法について詳しく見ていきましょう。
セキュリティスキームの定義 (server.securitySchemes)
これまでは、MCPサーバーの設定でサーバーレベルでsecuritySchemesのコレクションを定義できます。このアプローチは、OpenAPI仕様(OAS3)でセキュリティ要件を定義するものと一致しており、使いやすく標準化されています。各スキームは、バックエンドAPIが使用する可能性のある異なる認証方法を表します。現在、Higress MCPサーバープラグインは次のスキームタイプをサポートしています:
-
http
with scheme: basic (HTTP Basic Auth) -
http
with scheme: bearer (HTTP Bearer Token) -
apiKey
with in: header or in: query (API Key in header or query parameter)
将来的には、oauth2
およびopenIdConnect (OIDC)
スキームのサポートも計画されており、さらに多くのAPIを安全に統合できるようになります。
securitySchemesの設定フィールド
フィールド | 型 | 説明 |
---|---|---|
id | string | このセキュリティスキームの一意の識別子。 |
type | string | セキュリティスキームの種類(例:http, apiKey)。 |
scheme | string | type: httpの場合、スキームを指定します(例:basic, bearer)。 |
in | string | type: apiKeyの場合、APIキーの位置を指定します(例:header, query)。 |
name | string | type: apiKeyの場合、ヘッダまたはクエリパラメータの名前。 |
defaultCredential | string | このスキームで使用するデフォルトの資格情報(例:basicの場合はuser:pass、bearerの場合はトークン、APIキー値)。 |
**例:**yaml
server:
name: my-secure-api-server
securitySchemes:
- id: backendBasicAuth
type: http
scheme: basic
defaultCredential: service_user:p@$$wOrd
- id: backendBearerToken
type: http
scheme: bearer
defaultCredential: your_static_bearer_token_for_backend
- id: backendApiKeyHeader
type: apiKey
in: header
name: X-Internal-ApiKey
defaultCredential: secret_backend_api_key
バックエンドAPI呼び出しへのセキュリティの適用 (requestTemplate.security)
セキュリティスキームが定義されると、MCPサーバーがバックエンドREST APIに対して行うリクエストにそれらを適用できます。これは、各ツールのrequestTemplate
内で設定されます:
-
requestTemplate.security.id
:server.securitySchemes
で定義されたスキームのIDを参照します。 -
requestTemplate.security.credential
: (オプション)特定のツールのバックエンド呼び出しのためにスキームからのdefaultCredentialを上書きします。
**例:**yaml
tools:
- name: fetch-sensitive-data
description: Bearerトークンを要求するバックエンドサービスから機密データを取得します。
args: # ...
requestTemplate:
url: https://api.internal.com/data
method: GET
security:
id: backendBearerToken # backendBearerTokenスキームを使用
# credential: override_token_for_this_tool_if_needed
透過的な資格情報パススルー
最も強力な新機能の一つは、着信クライアントリクエスト(例:AIエージェントからMCPサーバー)からバックエンドAPI呼び出し(MCPサーバーから実際のREST API)に資格情報を透過的に渡す機能です。これは、バックエンドAPIがAIクライアントが持っているユーザー固有の認証を必要とする場合に特に重要です。
動作の仕組み:
-
クライアント側スキーム定義: MCPサーバーは、クライアントがどのように自身を認証しているか知る必要があります。これも
server.securitySchemes
のスキームを使用して定義されます。 -
ツールレベルのセキュリティ設定 (tools[].security):
-
id
: このMCPツールを呼び出す際にクライアントが使用すると予想されるセキュリティスキームを参照します。MCPサーバーはこれを使用してクライアントの資格情報を抽出します。 -
passthrough: true
: このフラグはパススルー機構を有効にします。
-
-
バックエンド認証: 上記で説明した
requestTemplate.security
は、パススルーされた資格情報をバックエンドAPI呼び出しにどのように適用するかを定義します。
例:
AIクライアントがユーザー固有のJWT Bearerトークンを使用してMCPツールを呼び出し、その同じトークンを使用してバックエンドサービスを呼び出したいとします。yaml
server:
name: user-data-passthrough-server
securitySchemes:
- id:
始めに
Higress MCP Server プラグインを更新し、詳細な設定手順や追加の例については、MCP Server README ドキュメントを参照してください。私たちは、Higress を強力で開発者に優しい AI ネイティブ API ゲートウェイにすることを目指しており、LLM API、MCP API、および Agent API と連携できるように取り組んでいます。さらなるアップデートにご期待ください!