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が環境にインストールされ、構成されている
- アクティブなMicrosoft Azureアカウントである
- RESTクライアント（このチュートリアルではPostmanを使用）である
API Connectivity Managerへのアクセスが必要な場合は、NGINX Management Suiteの30日間無料トライアル版にサインアップします。
Azure ADアプリケーションの作成
ブラウザを開き、Azure Portal（Azureポータル）にログインします。
左側メニューの「App registrations（App登録）」をクリックします。
図１：Azure ADポータルのホームページ
「New registration（新規登録）」ボタンをクリックします。
図２：Azure ADアプリの登録
新しいアプリケーションを作成するには、name（名前）とredirect URI（リダイレクトURI）を入力し、「Register（登録）」ボタンをクリックします。このデモではPostmanを使用するので、Postman OIDCリダイレクトURIを使うことになります。
図３：Azure ADアプリの新規作成
アプリが作成されたので、APIへのアクセスを提供するOAuthスコープを作成する必要があります。 左側メニューの「Expose an API（APIを公開） 」リンクをクリックします。
図4：APIの公開
「Add a scope（スコープの追加）」をクリックします。
図5：スコープの追加
デフォルトのアプリケーションID URIをそのまま使用するか、独自のURIを作成して、「Save and continue（保存して続行）」 ボタンをクリックします。独自のアプリケーション ID URI を作成する場合は、希望のドメインをAzure ADに登録する必要があります。
図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（従業員データへの読み取り専用アクセスを許可する）
図7：スコープの追加
次に、クライアントアプリケーションを承認する必要があります。これを行うには、クライアントIDを取得します。左側メニューの「Overview（概要）」リンクをクリックし、「Application (client) ID（アプリケーション（クライアント）ID）」をコピーします。
図8：アプリケーションクライアントID
「Expose an API（APIの公開）」リンクを再びクリックし、 「Add a client application（クライアントアプリケーションの追加）」ボタンをクリックします。
図9：クライアントアプリケーションの追加
「Client ID（クライアントID）」フィールドにアプリケーションクライアントIDを貼り付け、アプリケーションID URIの横にあるチェックボックスをオンにします。その後、「Add application（アプリケーションの追加）」ボタンをクリックします。
図10：クライアントアプリケーションの追加
次に、このデモでは、Authorization Code Flowで認可コードを活用するため、Postmanにはクライアントシークレットが必要となります。左側メニューの「Certificates & secrets（証明書とシークレット）」リンクをクリックし、「New client secret（新しいクライアントシークレット）」ボタンをクリックします。
図11：新しいクライアントシークレット
シークレットに名前を付け、有効期限はデフォルトのままにしておきます。
図12：シークレットの名前
次は、クライアントのシークレットをコピーして、パスワードボールトに保存し、後で使用できるようにします。
図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ペイロードが表示されます。後で、この値をコピーする必要があります。
図14：Azure ADテナントの既知のエンドポイント
JWKS URIを取得したら、API Connectivity Managerコンソールを開き、サービスプロキシの設定に移動します。「Add Policy（ポリシーの追加）」をクリックし、JSON Web Token Assertionに関するポリシーを追加します。
図15：Gateway Service Proxyに関するポリシー
次に、Azure ADテナントのJKWS URIを「URI Location（URIの場所）」フィールドに貼り付け、その後、「Add（追加）」ボタンをクリックします。
図16：JSON Webトークンアサーションに関するポリシー
「Save & Publish（保存して公開）」ボタンをクリックし、このポリシーをAPIゲートウェイクラスタにプッシュします。
図17：サービスゲートウェイに関するポリシー
以上です！これで、API Connectivity Managerのインスタンスは、設定されたサービスゲートウェイでJWTアサーションを実行するように設定されました。
Postmanによるテスト
では、ここからはいよいよセットアップをテストして、期待通りの動作であるかを確認しましょう。その前に、まずは、次のようなAzure ADアプリケーションから取得する必要があるものがいくつかあります。
- アプリケーションのクライアントシークレット（以前に保存済み）
- OAuthスコープ
- OAuth認可エンドポイント
- OAuthトークンエンドポイント
OAuthスコープを取得するには、Azureポータルを開き、アプリの登録ページに戻ります。次に、左側メニューの「Expose an API（APIを公開）」リンクをクリックし、「Copy（コピー）」のマークをクリックします。この値を保存し、後ほどすぐに使用できるようにします。
図18：APIのスコープ
OAuth認可とトークンのエンドポイントを取得するには、左側メニューの「Overview（概要）」リンクをクリックし、次に「Endpoints（エンドポイント）」ボタンをクリックします。その後、認可とトークンのエンドポイントURIをコピーします。
図19：Azure ADアプリケーションエンドポイント
図20：Azure ADアプリケーションエンドポイントのURL
Postmanを開き 「Environments（環境）」メニューをクリックします。その後、「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スコープ
図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（新しいアクセストークンの取得）」ボタンをクリックする
図23：Postmanのリクエスト
図24：Postman Authの設定
ブラウザーウィンドウが開き、Azure ADのクレデンシャルを使ってログインするように求められます。認証に成功すると、Postmanにリダイレクトされ、次のウィンドウが表示されます。「Use Token（トークンの使用）」ボタンをクリックします。
図25：Postmanのトークン使用
これでOAuthアクセストークンが取得できたので、いよいよAPI呼び出しを行います。「Save（保存）」ボタンをクリックした後、「Send（送信）」ボタンをクリックします。
すべてが正しく設定されている場合は、200 OKレスポンスが表示されます。
図26：Postmanのリクエスト成功
結論
これで、API Connectivity ManagerがAzure AD OAuth Accessトークンを使用してAPIを保護できることが可能になりました。次の手順では、OAuthスコープを追加し、API Connectivity ManagerでAPIゲートウェイクラスタを設定し、これらのスコープを保護されたAPIに渡すことですが、これに関しては別の記事で説明します!
今すぐ始めましょう
NGINX Management Suiteの30日間無償トライアル版をお試しください。これには、API Connectivity ManagerとInstance Managerが含まれています。
A version of this post first appeared on codygreen.com. It is edited and reprinted here with permission from the author.
