NetScalerアプライアンスによるAPI認証
現代のアプリケーションがクライアントとやり取りする方法にはパラダイムシフトがあります。従来、サービスへのアクセスにはブラウザクライアントが使用されていました。アプリケーションは通常、ユーザーコンテキストを追跡するためにセッションクッキーを設定します。最新の分散アプリケーションでは、マイクロサービス間でユーザーセッションを維持することが難しくなっています。このため、ほとんどのアプリケーションアクセスはAPIベースになっています。 これらの分散サービスと通信するクライアントも進化してきました。ほとんどのクライアントは、認証サーバーと呼ばれる信頼できるエンティティからトークンを取得して、ユーザーの身元とアクセスを証明します。次に、これらのクライアントは、アクセス要求のたびにトークンをアプリケーションに提示します。そのため、NetScalerのような従来のプロキシデバイスは、これらのクライアントをサポートするように進化させる必要があります。NetScalerアプライアンスは、管理者がこのようなトラフィックを処理する方法を提供します。NetScalerは、公開サービスを宛先とするすべてのトラフィックをフロントエンドするAPIゲートウェイとして展開できます。API Gateway は、従来の (ハイブリッドマルチクラウドまたは HMC) 環境またはクラウドネイティブ環境にデプロイできます。API Gateway は、認証、承認、レート制限、ルーティング、キャッシュ、SSL オフロード、アプリケーションファイアウォールなどの複数のサービスを提供するために、すべてのインバウンドトラフィックを終了します。したがって、これはインフラストラクチャの重要なコンポーネントになります。
トークンの種類
API アクセス中に交換されるトークンは、主に OAuth/OpenID コネクト (OIDC) プロトコルに準拠しています。「委任アクセス」にのみ使用されるアクセストークンはOAuthプロトコルに準拠していますが、OIDCに準拠するIDトークンはユーザー情報も保持します。 アクセストークンは通常、不透明またはランダムなデータの塊です。ただし、JWT (Json Web Token) 標準に準拠した署名付きトークンである場合もあります。ID トークンは常に署名された JWT です。
OAuth による API アクセス
NetScalerアプライアンスのOAuth認証タイプは、OAuthプロトコルとOIDCプロトコルの両方を処理するために使用できます。OIDC は OAuth プロトコルの拡張です。
NetScalerアプライアンスのOAuthActionを使用して,ブラウザなどのインタラクティブクライアントやクライアントアプリなどのネイティブクライアントを処理できます。インタラクティブクライアントは ID プロバイダにリダイレクトされ、OIDC プロトコルを使用してログインされます。ネイティブクライアントは帯域外でトークンを取得し、そのトークンをNetScalerアプライアンスに提示してアクセスすることができます。
注:
エンドポイントから取得したアクセストークンは、後続のリクエスト用にキャッシュできるため、API のパフォーマンスが向上します。
コマンドラインインターフェイスを使用してトークンキャッシュサポートを設定するには、コマンドプロンプトで次のコマンドを入力します。
set aaaparameter –apITokenCache
以下のセクションでは、ネイティブクライアントが実行する API アクセス方法について説明します。
API アクセス用仮想サーバー
APIアクセス用のNetScalerアプライアンスをデプロイするには、401認証を使用してトラフィック管理(TM)仮想サーバーをデプロイします。認証 (認証、承認、監査) 仮想サーバーに関連付けられ、認証とセッションのポリシーを保持します。以下の構成スニペットは、このような仮想サーバーを 1 つ作成します。
Add lb vserver lb-api-access SSL 443 -authn401 On -AuthnVsName auth-api-access Bind ssl vserver lb-api-access -certkeyName Add authentication vserver auth-api-access SSL
注:
構成を完了するには、サービスをトラフィック管理仮想サーバーにバインドし、認証ポリシー (後述の OAuthAction を含む) を認証仮想サーバーにバインドする必要があります。
仮想サーバーを作成したら、対応するポリシーとともに OAuthAction を追加する必要があります。OAuth アクションには、トークンの種類やその他のセキュリティメカニズムに応じて、他にもいくつかのオプションがあります。
ID トークンの OAuth 設定
ID トークンは常に署名された JWT です。つまり、ヘッダー、ペイロード、署名が含まれています。これらは自己完結型のトークンであるため、NetScalerアプライアンスはこれらのトークンをローカルで検証できます。これらのトークンを検証するには、アプライアンスはこれらのトークンの署名に使用された対応する秘密鍵の公開鍵を知っている必要があります。
以下は、特定の必須引数と「CerTendPoint」を使用したOAuthActionの例です。
Add authentication OAuthAction oauth-api-access -clientid -clientsecret -authorizationEndpoint -tokenEndpoint -certEndpoint
各項目の意味は次のとおりです。
クライアント ID:SP を識別する一意の文字列。認可サーバは、この ID を使用してクライアント設定を推測します。最大文字数:127。
Client Secret— ユーザーと認可サーバーによって確立されたシークレット文字列。最大長:239
AuthorizationEndpoint-ユーザーが通常ログインする URL (インタラクティブクライアントを使用している場合)。
TokenEndpoint-トークン/コードが取得/交換される承認サーバー上の URL
CerTendPoint-認証サーバーがトークンの署名に使用される公開鍵を公開するURL。承認サーバーは複数のキーを公開し、そのうちの 1 つを選択してトークンに署名できます。
注:
クライアントID/クライアントシークレット/承認エンドポイント/トークンエンドポイントは、API Accessのオプションパラメータです。ただし、アクションエンティティはさまざまな目的で再利用できるため、これらのパラメータに値を指定することをお勧めします。
前述の構成では、ID トークンの検証には「CertEndpointPoint」が不可欠です。このエンドポイントには、トークンの署名に使用される証明書の公開鍵が含まれています。これらの公開鍵は JWK (Json Web キー) 仕様に対応している必要があります。
NetScalerアプライアンスでCertendPointを構成すると、公開鍵を最新の状態に保つために、エンドポイントを定期的に(構成でカスタマイズできるデフォルトの間隔は1日)ポーリングします。公開鍵が利用可能になると、ADCは受信したIDトークンのローカル検証を実行できます。
不透明アクセストークンのOAuth設定
不透明なトークンは、NetScalerアプライアンス上でローカルに検証できません。これらは認証サーバーで検証する必要があります。NetScalerアプライアンスは、OAuth仕様に記載されている「イントロスペクションプロトコル」を使用してこれらのトークンを検証します。不透明トークンを検証するための新しいオプション IntrospectURL が OAuth 設定で提供されました。
set oauthAction oauth-api-acccess -introspectURL
イントロスペクション API の形式は、以下のようにhttps://tools.ietf.org/html/rfc7662#section-2.1
の仕様に準拠しています。
POST /introspect HTTP/1.1 Host: server.example.com Accept: application/json Content-Type: application/x-www-form-urlencoded Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW token=mF_9.B5f-4.1JqM&token_type_hint=access_token
認証仮想サーバーへのバインディングポリシー
OAuthAction を作成したら、それを呼び出すための対応するポリシーを作成する必要があります。
add authentication policy oauth-api-access -rule <> -action bind authentication vserver auth-api-access -policy oauth-api-access -pri 100
NetScalerアプライアンスのその他のセキュリティ設定
トークンの検証には、トークンの有効期間チェックが含まれます。許容時間外のトークンは拒否されます。セキュリティを強化するための追加設定は次のとおりです。これらの中には、常に設定することが推奨されるものもあります。
対象者:OAuth アクションは、トークンの受信者を指定して設定できます。すべてのトークンは、この設定された URL と照合されます。NetScalerアプライアンスには、オーディエンスフィールドが実際にアプライアンスに設定されているパターンを指すという追加機能があります。このパターンセットを使用すると、管理者はオーディエンスに複数の URL を設定できます。
add policy patset oauth_audiences bind patset oauth_audiences https://app1.company.com bind patset oauth_audiences https://app2.company.com bind patset oauth_audiences httpsL//app1.company.com/path1 set oAuthAccess oauth-api-access -audience oauth_audiences
前の例では、パターンセットに複数のオーディエンスが指定されています。したがって、受信トークンは、パターンセットに設定された URL のいずれかが含まれている場合にのみ許可されます。
発行者:トークンを承認するサーバーのID。最大文字数:127。OAuthアクションでトークンの発行者を設定するとよいでしょう。これにより、間違った認証サーバーによって発行されたトークンが許可されなくなります。
SkewTime: NetScalerアプライアンスが受信トークンで許容する許容クロックスキューを分単位で指定します。たとえば、SkewTime が 10 の場合、トークンは (現在の時刻-10) 分から (現在時刻 + 10) 分、つまり 20 分まで有効です。デフォルト値:5
AllowedAlgorithms: このオプションを使用すると、管理者は受信トークンの特定のアルゴリズムを制限できます。デフォルトでは、サポートされているすべてのメソッドが許可されています。ただし、これらはこのオプションを使用して制御できます。
次の構成では、RS256とRS512を使用するトークンのみが許可されます。
set oAuthAction oauth-api-access -allowedAlgorithms RS256 RS512
上記の構成を実行すると、RS256とRS512を使用するトークンのみが許可されます。
特定のトラフィックを認証からバイパスする
多くの場合、クライアントが公開しているディスカバリ API がいくつかあります。これらの API は通常、サービス自体の構成と機能を明らかにします。管理者は、次のように説明されている「認証なし」ポリシーを使用して、これらのメタデータURLからの認証をバイパスするようにNetScalerアプライアンスを構成できます。
add authentication policy auth-bypass-policy -rule <> -action NO_AUTHN bind authentication vserver auth-api-access -policy auth-bypass-policy -pri 110
NO_AUTHN は暗黙のアクションで、ルールが一致すると認証が完了します。API アクセスの範囲を超えた NO_AUTHN アクションの用途は他にもあります。