Citrix ADC

Citrix ADCアプライアンスを使用したAPI認証

最新のアプリケーションがクライアントとやり取りする方法には、パラダイムシフトがあります。従来、ブラウザクライアントはサービスにアクセスするために使用されていました。アプリケーションは、通常、セッションcookieを設定してユーザーコンテキストを追跡します。最新の分散アプリケーションでは、マイクロサービス間でユーザーセッションを維持することが難しくなっています。このため、ほとんどのアプリケーションアクセスはAPIベースになっています。 これらの分散サービスと通信するクライアントも進化してきました。ほとんどのクライアントは、認証サーバーと呼ばれる信頼されたエンティティからトークンを取得し、ユーザーの身元とアクセスを証明します。これらのクライアントは、各アクセス要求でアプリケーションにトークンを提示します。したがって、Citrix ADCのような従来のプロキシデバイスは、これらのクライアントをサポートするために進化 する必要があります。Citrix ADCアプライアンスは、管理者がこのようなトラフィックを処理する方法を提供します。Citrix ADCは、公開サービス宛てのすべてのトラフィックをフロントエンドにAPIゲートウェイとして展開できます。APIゲートウェイは、従来型(ハイブリッドマルチクラウドまたはHMC)またはクラウドネイティブ環境にデプロイできます。API Gateway は、認証、認可、レート制限、ルーティング、キャッシュ、SSL オフロード、アプリケーションファイアウォールなどのいくつかのサービスを提供するために、すべてのインバウンドトラフィックを終了します。したがって、インフラストラクチャでは重要なコンポーネントになります。

トークンの種類

APIアクセス中に交換されるトークンは、主に OAuth/OpenID Connect (OIDC) プロトコルに準拠します。「委任アクセス」にのみ使用されるアクセストークンは、OAuthプロトコルに準拠しますが、OIDCに準拠するIDトークンは、ユーザー情報も持ちます。 アクセストークンは、通常、不透明なまたはランダムなデータのブロブです。ただし、JWT(Json Web Token)標準に準拠した署名トークンであることがあります。IDトークンは常に署名されたJWTです。

OAuthを使用したAPI アクセス

Citrix ADCアプライアンスでのOAuth認証タイプは、OAuthプロトコルとOIDCプロトコルの両方を処理するために使用できます。OIDCは、OAuthプロトコルの拡張です。

Citrix ADCアプライアンス上のOAuthActionは、ブラウザなどの対話型クライアントやクライアントアプリなどのネイティブクライアントを処理するために使用できます。対話型クライアントは、OIDC プロトコルを使用してログインするために ID プロバイダーにリダイレクトされます。ネイティブクライアントは帯域外トークンを取得し、Citrix ADCアプライアンスでこれらのトークンを提示してアクセスすることができます。

注: エンドポイントから取得したアクセストークンは、後続の要求に対してキャッシュできるため、API のパフォーマンスが向上します。

コマンドラインインターフェイスを使用してトークンキャッシュサポートを構成するには、コマンドプロンプトで次のコマンドを入力します。

set aaaparameter –apITokenCache <ENABLED>

次のセクションでは、ネイティブクライアントによって実行される API アクセスメソッドについて説明します。

API アクセス用の仮想サーバー

APIアクセス用にCitrix ADCアプライアンスを展開するには、401認証を使用してトラフィック管理(TM)仮想サーバーを展開します。これは、認証(認証、認可、監査)仮想サーバーに関連付けられ、認証ポリシーとセッションポリシーを保持します。設定スニペットに続いて、そのような仮想サーバーを 1 つ作成します。

Add lb vserver lb-api-access SSL <IP> 443 -authn401 On -AuthnVsName auth-api-access

Bind ssl vserver lb-api-access -certkeyName <ssl-cert-entity>

Add authentication vserver auth-api-access SSL

注: 構成を完了するには、サービスをTM vserverにバインドし、認証ポリシー(OAuthActionを次のように記述する)を認証仮想サーバーにバインドする必要があります。

仮想サーバーを作成した後、対応するポリシーとともにOAuthActionを追加する必要があります。OAuthアクションには、トークンの種類やその他のセキュリティメカニズムに応じて、他にもいくつかのオプションがあります。

IDトークンのOAuth設定

IDトークンは常に署名されたJWTです。つまり、ヘッダー、ペイロード、および署名を運びます。これらは自己完結型のトークンであるため、Citrix ADCアプライアンスはこれらのトークンをローカルで検証できます。これらのトークンを検証するには、アプライアンスは、これらのトークンの署名に使用される対応する秘密キーの公開鍵を知っている必要があります。

以下は、「certEndpoint」と一緒に特定の必須引数を持つOAuthActionの例です。

Add authentication OAuthAction oauth-api-access -clientid <your-client-id> -clientsecret <your-client-secret> -authorizationEndpoint <URL to which users would be redirected for login> -tokenEndpoint <endpoint at which tokens could be obtained> -certEndpoint <uri at which public keys of IdP are published>

各項目の意味は次のとおりです。

  • クライアントID :SPを識別する一意の文字列。認可サーバは、この ID を使用してクライアント設定を推測します。最大長さ:127。

  • Client Secret — ユーザーと認可サーバーによって確立されたシークレット文字列。最大長さ:239。

  • AuthorizationEndpoint -ユーザーが通常ログインするURL(対話型クライアントを使用する場合)。

  • TokenEndpoint -トークン/コードを取得/交換する認可サーバ上のURL

  • CertendPoint -承認サーバーがトークンの署名に使用する公開キーを発行するURL。認可サーバーは複数の鍵を公開し、そのうちの1つを選択してトークンに署名できます。

注: Client ID/Client Secret/authorizationEndpoint/TokenEndpointは、APIアクセスのオプションのパラメータです。ただし、アクションエンティティはさまざまな目的に再利用できるため、これらのパラメータに値を指定することをお勧めします。

前述の構成では、「certEndpointpoint」は、IDトークンの検証に不可欠です。このエンドポイントには、トークンの署名に使用される証明書の公開キーが含まれています。これらの公開鍵は、JWK (Json Web Keys) 仕様に対応している必要があります。

Citrix ADCアプライアンスでCertendPointを構成すると、公開キーを最新の状態に保つために、エンドポイントを定期的にポーリングします(デフォルト間隔は1日で、構成でカスタマイズできます)。公開鍵が利用可能になった後、ADCは着信IDトークンのローカル検証を実行できます。

図1:IDトークンのOAuthフロー

IDトークンのOAuthフロー

不透明なアクセストークンのOAuth設定

不透明なトークンは、Citrix ADCアプライアンスではローカルで検証できません。これらは、認証サーバー上で検証する必要があります。Citrix ADCアプライアンスは、これらのトークンを検証するために、OAuth仕様に記載されている「イントロスペクションプロトコル」を使用します。OAuth 設定では、不透明なトークンを検証するための新しいオプション IntroSpecturl が提供されています。

Set oauthAction oauth-api-acccess -introspectURL <uri of the Authorization Server for introspection>

図2:アクセストークンのOAuthフロー

アクセストークンのOAuthフロー

イントロスペクション 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 <oauth-api-access>```

bind authentication vserver auth-api-access -policy oauth-api-access -pri 100

Citrix ADCアプライアンスの追加のセキュリティ設定

トークン検証には、トークンの有効期間チェックが含まれます。許容時間外のトークンは拒否されます。以下は、追加のセキュリティのための追加設定です。これらのいくつかは、常に設定することをお勧めします。

対象ユーザー:OAuth アクションは、トークンの意図した受信者で構成できます。すべてのトークンは、この設定された URL と照合されます。Citrix ADCアプライアンスには、オーディエンスフィールドが実際にアプライアンスのパターンセットを指す追加機能があります。このパターンセットを使用して、管理者はオーディエンスに複数の 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

前の例では、1 つのパターンセットに複数のオーディエンスが指定されています。したがって、着信トークンは、パターンセット内に設定された URL のいずれかが含まれている場合にのみ許可されます。

発行者: トークンが受け入れられるサーバーの ID。最大長さ:127。OAuthアクションでトークンの発行者を設定することをお勧めします。これにより、誤った認可サーバによって発行されたトークンが許可されないようになります。

SkewTime:Citrix ADCアプライアンスが受信トークンに対して許可するクロックスキューを分単位で指定します。たとえば、SkewTimeが10の場合、トークンは(現在の時間-10)分から(現在の時間+10)分まで、つまり20分の範囲で有効です。デフォルト値:5

AllowedAlgorithms: このオプションを使用すると、管理者は受信トークン内の特定のアルゴリズムを制限できます。デフォルトでは、サポートされているすべてのメソッドが許可されています。ただし、このオプションを使用して制御することができます。

次の構成では、RS256 および RS512 を使用するトークンだけが許可されます。

Set oAuthAction oauth-api-access -allowedAlgorithms RS256 RS512

上記の設定後、RS256とRS512を使用するトークンだけが許可されます。

認証からの特定のトラフィックのバイパス

多くの場合、クライアントがパブリックにアクセス可能な検出APIがいくつかあります。これらのAPIは、通常、サービス自体の構成と機能を明らかにします。管理者は、次のように「認証なし」ポリシーを使用して、これらのメタデータURLからの認証をバイパスするようにCitrix ADCアプライアンスを構成できます。

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アクションの他の用途があります。