ライフサイクルを通してAPIを 管理するうえで重要な要素の一つは、APIアクセスとトラフィックルーティングに対するきめ細かな制御です。APIへのアクセス制御のためのデファクト スタンダードとして、アクセストークンが登場しました。JSON Web Token（JWT）をベースにした認証スキームの利点の一つは、JWTのクレームを活用してきめ細かなアクセス制御を実行できることです。アクセス許可はカスタムクレームとしてエンコードでき、API所有者はそれを APIへのアクセス制御のために利用可能です。APIプロキシがいったんJWTを有効にすると、変数としてトークンの全フィールドにアクセスできるようになり、それらに基づいてアクセス判断が可能となります。
前回の投稿では、API Connectivity Managerによっていかに運用者と開発者が共に協力し合えるかについて説明しました。APIを所有および運用する異なるビジネスラインの各チームは、APIやサービスのエクスペリエンスを構築および強化するにあたり、完全な管理が必要になります。
API Connectivity Manager が提供するポリシーによって、API所有者は、APIの認証や許可、追加のセキュリティ要件などのサービスレベル設定を行うことが可能になります。今回の投稿では、API所有者がアクセス制御ルーティングポリシーを活用して特定のルートのきめ細かな制御を行い、それをさらに微調整して、トークンの特定のクレームに基づいてHTTPメソッドごと、およびルートごとに適用する手法をご紹介します。
必須条件
F5 NGINX Management Suiteのトライアル版または有料サブスクリプションが必要となります。これには、Instance ManagerとAPI Connectivity Managerに加え、APIゲートウェイとしてのNGINX Plus、さらにはAPIを保護するNGINX App Protectが含まれています。まずは、NGINX Management Suiteの30日間無料のトライアル版をお試しください。
NGINX Management SuiteとAPI Connectivity Managerをインストールする手順は、導入ガイドを参照してください。
特定のサービスへのアクセスの付与とトラフィックのルーティング
インベントリやオーダーなど、いくつかのエンドポイントのあるウェアハウスAPIプロキシを発行したとしましょう。そこで、プライシングと呼ばれる新サービスを導入するにあたり、すでにベータ版トライアルに申し込み済みの少数のクライアントに限定してアクセスを可能にしたいと考えます。そのクライアントは、betatesterと呼ばれるクレームによって識別されます。この例のアクセストークンにて、そのクレームはsubクレームにて識別されたユーザー、user1@abc.com が trueとなっています。
Header
{
"kid": "123WoAbc4xxxX-o8LiartvSA9zzzzzLIiAbcdzYx",
"alg": "RS256"
}
Payload
{
"ver": 1,
"jti": "AT.xxxxxxxxxxxx",
"iss": "https://oauthserver/oauth2/",
"aud": "inventoryAPI",
"iat": 1670290877,
"exp": 1670294477,
"cid": "AcvfDzzzzzzzzz",
"uid": "yyyyyyyWPXulqE4x6",
"scp": [
"apigw"
],
"auth_time": 1670286138,
"sub": "user1@abc.com",
"betatester": true,
"domain": "abc"
} ベータプログラムに選ばれなかったuser2@abc.comについて、betatesterのクレームは
falseとなっています。
"sub": "user2@abc.com",
"betatester": false,次に、アクセス制御ルーティング（access-control-routing）ポリシーを設定し、true（トゥルー）値のbetatesterクレームを含むJWTをもつユーザーに、プライシングサービスへのアクセスを付与します。
簡潔に表現するため、ポリシーのペイロードのみを表示しています。本ポリシーは、JWT Assertion やOAuth2 Introspectionなど、API Connectivity Managerにおけるトークンベースのポリシーに限って機能します。
"policies": {
"access-control-routing": [
{
"action": {
"conditions": [
{
"allowAccess": {
"uri": "/pricing"
},
"when": [
{
"key": "token.betatester",
"matchOneOf": {
"values": [
"true"
]
}
}
]
}
],
"returnCode": 403
}
}
]
}いったんこのポリシーを適用すると、APIプロキシが認証ユーザーのJWTクレームの有効性を検証し、きめ細かなアクセス制御を実行してuser1@abc.comからのリクエストを送信し、user2@abc.comからのリクエストを拒否します。
特定のメソッドの利用を管理
アクセス制御ルーティング（access-control-routing）ポリシーをさらに微調整し、特定のHTTPメソッドを利用可能にするユーザーを管理できます。この例では、APIプロキシによって、管理者（Adminの値を含むトークンをもつユーザー）に限りDELETEメソッドの利用を可能にしています。
"policies":{
"access-control-routing":[
"action":{
"conditions":[
{
"when":[
{
"key":"token.{claims}",
"matchOneOf":{
"values":[
"Admin"
]
}
}
],
"allowAccess":{
"uri":"/v1/customer",
"httpMethods":[
"DELETE"
]
},
"routeTo" : {
"targetBackendLabel" : ""
}
}
]
}
]
}ヘッダーベースのルーティング
アクセス制御ルーティング（access-control-routing）ポリシーのさらにもう一つの活用法として、入ってくるリクエストのヘッダー値に基づいてルーティングを決定します。API 所有者は、送信されるリクエストが適合しているべきヘッダー値を特定するためにルールや条件を設定することができます。適合するヘッダーをリクエストが含んでいれば送信され、含んでいなければ取り下げられます。
この例では、versionリクエストのヘッダーがv1の値をもつ場合に限り、リクエストが /seasonsのエンドポイントに送信されます。returnCode値によってエラーコードが識別され、versionがv1でない場合は戻されます。 – このケースでは 403 (Forbidden：禁止)です。
"access-control-routing": [
{
"action": {
"conditions": [
{
"allowAccess": {
"uri": "/seasons"
},
"when": [
{
"key": "header.version",
"matchOneOf": {
"values": [
"v1"
]
}
}
]
}
],
"returnCode": 403
}
}
]この例のcurlリクエストでは、versionヘッダーがv2となる場合にseasonsサービスにリクエストを送信します。
curl -H "version: v2" http://example.com/seasonsversionヘッダーの値がポリシーによって要求されるv1ではないので、サービスはステータスコード403に戻ります。
ポリシーに複数のルールを含める
アクセス制御ルーティング（access-control-routing）ポリシーに複数のルールを取り入れ、本投稿にて説明したJWTクレーム、有効メソッド、リクエストヘッダー値といった3つの基準のうち1つ、2つ、または3つすべてをベースにルーティングを管理できます。送信されるリクエストはすべてのルールの条件に適合している必要があり、そうでない場合にはブロックされます。
まとめ
API Connectivity ManagerによってAPI所有者は、きめ細かなアクセス制御を適用して動的なルーティング決定を行うAPIレベルポリシーにて、APIやサービスのエクスペリエンスを管理および強化できます。
API Connectivity Managerを開始するにあたり、まずはNGINX Management Suiteの30日間無料のトライアル版をお試しください。
