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つの手順が必要です。