OAuth 2.0は、保護されたリソースへのアクセスを制御するための許可フレームワークです。そこで、導入に際してまずは使用可能なリソースと、それらにアクセスする必要があるクライアントを特定することが、重要な最初の手順になります。

REST API呼び出しを発行する際にOAuth 2.0を使用するクライアントと、それらのクライアントのアクセス先になるAPIエンドポイントを決定する必要があります。

RESTロールやローカル ユーザなど、既存のONTAP IDの定義を確認する必要があります。OAuth 2.0の設定方法によっては、これらの定義を使用してアクセスを制御できます。

OAuth 2.0許可は段階的に導入することもできますが、各許可サーバにグローバル フラグを設定することで、すべてのREST APIクライアントを一気にOAuth 2.0に移行することもできます。これにより、自己完結型スコープを作成しなくても、ONTAPの既存の設定に基づいてアクセスを制御できます。

許可サーバは、OAuth 2.0環境において、アクセス トークンを発行し、管理ポリシーを適用するという重要な役割を果たします。

1つ以上の許可サーバを選択し、インストールする必要があります。スコープの定義方法など、アイデンティティ プロバイダの設定オプションと手順を理解しておくことが重要です。Microsoft Entra IDなど、一部の許可サーバは、名前ではなく、UUIDを使用してグループを表します。

ONTAPは、許可サーバの証明書を使用して、クライアントから提示された署名済みアクセス トークンを検証します。そのためにONTAPに必要なのが、ルートCA証明書と中間証明書です。これらの証明書は、事前にONTAPにインストールされている可能性があります。インストールされていない場合には、インストールする必要があります。

許可サーバがファイアウォールの内側にある場合は、プロキシ サーバを使用するようにONTAPを設定する必要があります。

クライアントの認証と許可には、考慮すべき側面がいくつかあります。

大きく分けて、許可サーバで自己完結型スコープを定義する方法と、ロールやユーザを含む既存のローカルONTAP ID定義を使用する方法があります

ONTAP ID定義を使用する場合は、次のどれを適用するのかを決定する必要があります。

アクセス トークンがONTAPによってローカルで検証されるか、イントロスペクションによって許可サーバで検証されるかを決定する必要があります。また、更新間隔など、いくつかの関連する値についても検討する必要があります。

高度なセキュリティが必要な環境には、mTLSベースの送信者限定アクセス トークンを使用できます。この場合、クライアントごとに証明書が必要です。

UUIDを使用してグループを表す許可サーバを使用している場合は、これらをグループ名に、場合によっては関連付けられているロールにもマッピングする方法を計画する必要があります。

OAuth 2.0は、次のいずれかのONTAPインターフェイスを通じて管理できます。

クライアント アプリケーションは、許可サーバに直接アクセス トークンを要求しなければなりません。グラント タイプを含めて、これをどのように行うかを決定する必要があります。

ONTAPで、いくつかの設定タスクを実行する必要があります。

許可の設定に基づいて、ローカルのONTAP識別処理を使用できます。その場合は、RESTロールとユーザ定義を確認および定義する必要があります。また、許可サーバによっては、UUID値に基づいたグループの管理も含まれる場合があります。

ONTAPのコア設定を行うには、主に次の3つの手順が必要です。