[BIG-IP APM] JWT形式のAPIキーによるアクセス制御 Part1

BIG-IP APMはOAuth 2.0 Authorization Frameworkにおける役割の中でClient、Resource Server、Authorization Serverとして動作させることができます。

本投稿では、Authorization Server(以下ASサーバ)とResource Server(以下RSサーバ)にAPMを利用するケースでその設定などをご紹介します。

はじめに
APMはOAuthにおけるアクセストークン形式として、OPAQUE・JWTが利用可能です。
OPAQUEは独自形式となっており、APMでトークンの管理やAPMへのNorthbandAPIを介しての管理が可能という利点があります。
一方で発行元サーバへ検証する必要がありJWT形式に比べるとパフォーマンスが低下します。

JWT形式では事前に設定されたJWKSに対して、機器内部で検証可能となりパフォーマンスが高くなります。
また、APMのAPI ProtectionのProfile設定でJWTペイロードに含まれるClaimなどを通信制御に利用することが簡単に行うことが可能です。

今回はJWTを利用したケースをご紹介します。

ASサーバの設定
APMをASサーバとして利用するための設定を行います。
ご紹介設定や環境の前提は以下です。
・LocalDBを利用(MS-ADなど利用いただけます)
・VSに適用するSSL ProfileやJWT Key設定に利用する証明書はOpenSSLで作成した自己認証局が署名した自己証明書
・クライアントアプリケーションにPostManを利用

1. Scope/Claimの作成
Access > Federation > OAuth Authorization ServerからScope、Claimをそれぞれ作成します。
以下は本記事でご紹介する環境の作成例です。

・Claim

・Scope

2. Oauthクライアントアプリを登録
Access > Federation > OAuth Authorization Server > Client Applicationからクライアントアプリを登録します。

「Authorization Code Grant」タイプを使用して POSTMAN でアクセストークンを取得するため、ここでは「Authorization Code / Hybrid」メニューを選択します。「Redirect URI」についてASサーバーはこの「Redirect URI」を使用して、Authorization Codeを OAuth クライアント アプリケーションに送信するために利用されます。この値は POSTMAN ソフトウェアの値に設定する必要があります。その他、Support OpenID Connectにチェックを入れます。

3. Key Configurationの設定
Access > Federation > JSON Web Token > Key ConfigurationからJWKを作成を行います。

証明書はOpenSSLで作成した自己認証局が署名した証明書を利用しています。
環境に合わせて適切なものをご利用いただければと存じます。

4. Oauthプロファイルの作成
Access > Federation > OAuth Authorization Server > OAuth Profileから設定を行います。

 
5. AccessProfileの作成
Access > Profiles / Policies > Access Profiles(Per-Session Policies)から設定を行います。

プロファイル作成後、Access > Profiles / Policies > Access Profiles(Per-Session Policies)に表示されるプロファイルのPer-Session Policy項目のEditよりVPEの設定に入ります。

6.AccessProfileのVPE設定
以下のようなVPEを作成します。

6-1. [Start] の横にある (+) アイコンを選択し、[Logon]タブ に移動します。[Logon Page] オプションを選択し、[Add Item] ボタンを選択します。次に、以下のように構成し、構成が完了したら「Save」を選択します。

6-2.作成したログオンページの横にある (+) アイコンを選択します。「Authentication」タブに移動し、「LocalDB Auth」オプションを選択して、「Add Item」ボタンを選択します。次に、以下のように構成し、構成が完了したら「Save」を選択します。

6-3. LocalDB Auth横の[+] を選択し、[General Purpose]タブの[Local Database]を選択し、[Add Item]を選択します。次に、以下のように構成し、構成が完了したら「Save」を選択します。

LocalDB Instanceは事前に作成したものを適用ください。(作成方法は本投稿では割愛しています)
 
7. Virtual Serverの作成
Local Traffic > Virtual Servers > Virtual Server List からASサーバとして受けるVSを作成し、前項で作成したAccessProfileを適用します。

以上でASサーバの設定は完了です。

テスト
作成したASサーバに対してPostmanを利用しアクセストークンの取得を試みます。

事前にPostmanアプリケーションでAuthorizationの設定を行う必要があります。
参考としてGrant TypeはAuthorization Codeを使用し、Callback URLやClient ID/Client Secretは作成したClient Application設定(Access > Federation > OAuth Authorization Server > Client Application)からご確認いただけます。
Auth URL、Access Token URLはASサーバのVirtual ServerアドレスもしくはFQDNとパスは作成したOAuth Profile(Access > Federation > OAuth Authorization Server > OAuth Profile)のAuthorization Server Endpointsで設定されているものを利用します。

Postmanアプリケーションの設定が完了しましたらAccess Tokenの取得を試みます。

1. Postmanからトークンを取得開始するとAPMからログオンページが表示されます。

2. ユーザ名、パスワードを入力し認証を通るとJWT形式のトークンが払い出されます。

3. 払い出しされたトークンをデコードすると、作成したScopeやClaimがペイロード部分に含まれていることを確認できます。

まとめ
APMのAPI Protection機能を活用すると、上記で確認した、Claimの値を利用してレート制限等を行うことができます。

今回はAPMでのASサーバ構成方法をご紹介しました、次回はRSサーバで実際にASサーバで払い出したアクセストークンを検証し通信を許可、拒否する構成方法をご紹介します。

Published Nov 18, 2022
Version 1.0
No CommentsBe the first to comment