BLOG | NGINX

セキュアなAPIアクセスを実現/NGINXとAzure Active Directory

NGINX-Part-of-F5-horiz-black-type-RGB
Cody Green サムネール
Cody Green
Published October 06, 2022

APIはアプリケーションの接続性において重要な役割を果たす一方で、攻撃され易いという脆弱な面があります。これまで、モノリシックアプリでは、セキュリティを対策すべきエントリポイントは1つしかありませんでした。マイクロサービスアーキテクチャでは、1つのアプリがAPIを介して接続された多くのマイクロサービスで構成され、これらのAPIのそれぞれに数百のエンドポイントが存在する場合があります。このため、APIの潜在的な攻撃対象は膨大になり、新しいAPIが増えるたびに、セキュリティ境界にエントリポイントがうまれます。

APIを保護するための戦略はたくさんあります。最も基本的なものの1つはアクセス制御です。簡単に言えば、ユーザのIDを確認(認証、またはAuthN)し、特定のリソースにアクセス可能であることを確認(認可、またはAuthZ)する必要があります。OpenID Connect (OIDC) の実装は、APIで使用される最も一般的なアクセス制御アプローチの1つです。F5 NGINX Management Suiteの一部であるAPI Connectivity Managerを使用すると、数分で起動し、実行することが可能です。

このチュートリアルでは、API Connectivity ManagerとAzure Active Directory(Azure AD)を使用してJSON Web Token(JWT)検証を設定し、OIDCワークフローの認可部分を実行する方法を学習します。

OpenID Connectとは

OpenID Connect (OIDC)とは、OAuth 2.0プロトコルの上に構築されたアイデンティティプロトコルです。OIDCにより、クライアントはエンドユーザまたはデバイスのIDを確認できます。これは、次に示す認証と認可の両方を含むアクセス制御の一部です。

  • 認証は、ユーザまたはデバイスが本人であることを確認する
  • 認可は、検証済みのユーザまたはデバイスがアクセスできるものを決定する

このチュートリアルで使用するAzure ADなど、OIDCにはさまざまな実装があります。また、F5 BIG-IP Access Policy Manager (APM)、Okta、Auth0、Ping Identityなど、他のOIDCソリューションもAPI Connectivity Managerで使用することが可能です。

はじめるために必要なもの

次の前提条件を満たしていることを確認します。

API Connectivity Managerへのアクセスが必要な場合は、NGINX Management Suiteの30日間無料トライアル版にサインアップします。

Azure ADアプリケーションの作成

ブラウザを開き、Azure Portal(Azureポータル)にログインします。

左側メニューの「App registrations(App登録)」をクリックします。

Azure AD Portal Home Page

図1:Azure ADポータルのホームページ

New registration(新規登録)」ボタンをクリックします。

Azure AD App Registration

図2:Azure ADアプリの登録

新しいアプリケーションを作成するには、name(名前)redirect URI(リダイレクトURI)を入力し、「Register(登録)」ボタンをクリックします。このデモではPostmanを使用するので、Postman OIDCリダイレクトURIを使うことになります。

Create a New Azure AD App

図3:Azure ADアプリの新規作成

アプリが作成されたので、APIへのアクセスを提供するOAuthスコープを作成する必要があります。 左側メニューの「Expose an API(APIを公開) 」リンクをクリックします。

Expose an API

図4:APIの公開

Add a scope(スコープの追加)」をクリックします。

Add a Scope

図5:スコープの追加

デフォルトのアプリケーションID URIをそのまま使用するか、独自のURIを作成して、「Save and continue(保存して続行)」 ボタンをクリックします。独自のアプリケーション ID URI を作成する場合は、希望のドメインをAzure ADに登録する必要があります。

Application ID URL

図6:アプリケーションIDのURL

このデモでは、スコープはMicrosoftのサンプルに基づいています。フォームに次の情報を入力し、「Add scope(スコープの追加)」ボタンをクリックします。

Scope name(スコープ名): Employees.Read.All(従業員。読み取り。全員)
Who can consent?(誰が同意できますか?): 管理者とユーザ
Admin consent display name(管理者同意表示名): Read-only access to Employee records(従業員レコードへの読み取り専用アクセス)
Admin consent description(管理者の同意に関する説明): Allow read-only access to all Employee (dataすべての従業員データへの読み取り専用アクセスを許可する)
User consent display name(ユーザ同意表示名): Read-only access to your Employee records(従業員レコードへの読み取り専用アクセス)
User consent description(ユーザ同意に関する説明): Allow read-only access to your Employee data(従業員データへの読み取り専用アクセスを許可する)

Add a Scope

図7:スコープの追加

次に、クライアントアプリケーションを承認する必要があります。これを行うには、クライアントIDを取得します。左側メニューの「Overview(概要)」リンクをクリックし、「Application (client) ID(アプリケーション(クライアント)ID)」をコピーします。

Application Client ID

図8:アプリケーションクライアントID

Expose an API(APIの公開)」リンクを再びクリックし、 「Add a client application(クライアントアプリケーションの追加)」ボタンをクリックします。

Add a Client Application

図9:クライアントアプリケーションの追加

「Client ID(クライアントID)」フィールドにアプリケーションクライアントIDを貼り付け、アプリケーションID URIの横にあるチェックボックスをオンにします。その後、「Add application(アプリケーションの追加)」ボタンをクリックします。

Add a Client Application

図10:クライアントアプリケーションの追加

次に、このデモでは、Authorization Code Flowで認可コードを活用するため、Postmanにはクライアントシークレットが必要となります。左側メニューの「Certificates & secrets(証明書とシークレット)」リンクをクリックし、「New client secret(新しいクライアントシークレット)」ボタンをクリックします。

New Client Secret

図11:新しいクライアントシークレット

シークレットに名前を付け、有効期限はデフォルトのままにしておきます。

Secret Name

図12:シークレットの名前

次は、クライアントのシークレットをコピーして、パスワードボールトに保存し、後で使用できるようにします。

Client Secret

図13:クライアントシークレット

API Connectivity ManagerでのJWTアサーションの設定

Azure ADアプリケーションの設定を完了したら、API Connectivity ManagerでAPIゲートウェイクラスタを設定して、定義したサービスに対してJSON Web Token Assertionを実行できるようになります。この手順では、Azure ADテナントのJSON Web Key (JWK)セットのURIを決定する必要があります。

JWKS URIは、Azure ADテナントの既知のエンドポイントから取得できます:
https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration

このページには、jwks_uriキーを含むJSONペイロードが表示されます。後で、この値をコピーする必要があります。

Azure AD Tenant Well-Known Endpoint

図14:Azure ADテナントの既知のエンドポイント

JWKS URIを取得したら、API Connectivity Managerコンソールを開き、サービスプロキシの設定に移動します。「Add Policy(ポリシーの追加)」をクリックし、JSON Web Token Assertionに関するポリシーを追加します。

Gateway Service Proxy Policies

図15:Gateway Service Proxyに関するポリシー

次に、Azure ADテナントのJKWS URIを「URI Location(URIの場所)」フィールドに貼り付け、その後、「Add(追加)」ボタンをクリックします。

SON Web Token Assertion Policy

図16:JSON Webトークンアサーションに関するポリシー

Save & Publish(保存して公開)」ボタンをクリックし、このポリシーをAPIゲートウェイクラスタにプッシュします。

Service Gateway Policy

図17:サービスゲートウェイに関するポリシー

以上です!これで、API Connectivity Managerのインスタンスは、設定されたサービスゲートウェイでJWTアサーションを実行するように設定されました。

Postmanによるテスト

では、ここからはいよいよセットアップをテストして、期待通りの動作であるかを確認しましょう。その前に、まずは、次のようなAzure ADアプリケーションから取得する必要があるものがいくつかあります。

  • アプリケーションのクライアントシークレット(以前に保存済み)
  • OAuthスコープ
  • OAuth認可エンドポイント
  • OAuthトークンエンドポイント

OAuthスコープを取得するには、Azureポータルを開き、アプリの登録ページに戻ります。次に、左側メニューの「Expose an API(APIを公開)」リンクをクリックし、「Copy(コピー)」のマークをクリックします。この値を保存し、後ほどすぐに使用できるようにします。

API Scopes

図18:APIのスコープ

OAuth認可とトークンのエンドポイントを取得するには、左側メニューの「Overview(概要)」リンクをクリックし、次に「Endpoints(エンドポイント)」ボタンをクリックします。その後、認可とトークンのエンドポイントURIをコピーします。

Azure AD Application Endpoints

図19:Azure ADアプリケーションエンドポイント

Azure AD Application Endpoint URLs

図20:Azure ADアプリケーションエンドポイントのURL

Postmanを開き 「Environments(環境)」メニューをクリックします。その後、「Create Environment(環境の作成)」リンクをクリックします。

Postman Create Environment

図21:Postmanの作成環境

環境に名前を付け、(前の手順で保存した)値を持つ6つの変数を「Initial Value(初期値)」列と 「Current Value(現行値)」列に追加し 「Save(保存)」ボタンをクリックします。

  • client_id: Azure ADアプリケーションのクライアントID
  • client_secret: Azure ADアプリケーションのクライアントシークレット
  • auth_url: Azure ADテナントのOAuth認可URL
  • token_url: Azure ADテナントのOAuthトークンURL
  • tenant_id: Azure ADディレクトリ (テナント) ID
  • scope: アプリケーションID URLを持つAzure ADアプリケーションのAPIスコープ

Postman Environment Variables

図22:Postmanの環境変数

Postmanで新しいタブを開き、次の手順を実行します。

  • 右上の「Environment (環境)」をACMに変更する
  • アドレスバーにAPI URLを追加する
  • Auth」タブをクリックする
  • Type(タイプ)」をOAuth 2.0に変更する
  • Authの設定を下にスクロールし、次の変数を設定する
    • Auth URL: {{auth_url}}
    • Access Token URL: {{token_url}}
    • Client ID: {{client_id}}
    • Client Secret: {{client_secret}}
  • Get New Access Token(新しいアクセストークンの取得)」ボタンをクリックする

Postman Request

図23:Postmanのリクエスト

Postman Auth Configuration

図24:Postman Authの設定

ブラウザーウィンドウが開き、Azure ADのクレデンシャルを使ってログインするように求められます。認証に成功すると、Postmanにリダイレクトされ、次のウィンドウが表示されます。「Use Token(トークンの使用)」ボタンをクリックします。

Postman Use Token

図25:Postmanのトークン使用

これでOAuthアクセストークンが取得できたので、いよいよAPI呼び出しを行います。「Save(保存)」ボタンをクリックした後、「Send(送信)」ボタンをクリックします。

すべてが正しく設定されている場合は、200 OKレスポンスが表示されます。

Postman Successful Request

図26:Postmanのリクエスト成功

結論

これで、API Connectivity ManagerがAzure AD OAuth Accessトークンを使用してAPIを保護できることが可能になりました。次の手順では、OAuthスコープを追加し、API Connectivity ManagerでAPIゲートウェイクラスタを設定し、これらのスコープを保護されたAPIに渡すことですが、これに関しては別の記事で説明します!

今すぐ始めましょう

NGINX Management Suiteの30日間無償トライアル版をお試しください。これには、API Connectivity ManagerInstance Managerが含まれています。

A version of this post first appeared on codygreen.com. It is edited and reprinted here with permission from the author.


"This blog post may reference products that are no longer available and/or no longer supported. For the most current information about available F5 NGINX products and solutions, explore our NGINX product family. NGINX is now part of F5. All previous NGINX.com links will redirect to similar NGINX content on F5.com."