OAuth 2.0 est un cadre d'autorisation permettant de contrôler l'accès aux ressources protégées. Dans un premier temps, il est donc important de déterminer quelles sont les ressources disponibles et quels clients ont besoin d'y accéder.

Vous devez décider quels clients utiliseront OAuth 2.0 lors de l'émission d'appels API REST et à quels terminaux API ils ont besoin d'accéder.

Vous devez examiner les définitions d'identité ONTAP existantes, y compris les rôles REST et les utilisateurs locaux. Selon la configuration d'OAuth 2.0, ces définitions peuvent être utilisées pour prendre des décisions d'accès.

Bien que vous puissiez implémenter l'autorisation OAuth 2.0 progressivement, vous pouvez également déplacer tous les clients API REST vers OAuth 2.0 immédiatement en définissant un indicateur global pour chaque serveur d'autorisation. Vous pouvez ainsi prendre des décisions d'accès en fonction de votre configuration ONTAP existante sans avoir à créer de étendues autonomes.

Les serveurs d'autorisation jouent un rôle important dans votre déploiement OAuth 2.0 en émettant des jetons d'accès et en appliquant une stratégie administrative.

Vous devez sélectionner et installer un ou plusieurs serveurs d'autorisation. Il est important de se familiariser avec les options de configuration et les procédures de vos fournisseurs d'identité, y compris la définition des périmètres. Notez que certains serveurs d'autorisation, y compris Microsoft Entra ID, représentent des groupes utilisant des UUID au lieu de noms.

ONTAP utilise le certificat du serveur d'autorisation pour valider les jetons d'accès signés présentés par les clients. Pour ce faire, ONTAP a besoin du certificat de l'autorité de certification racine et de tous les certificats intermédiaires. Ils peuvent être pré-installés avec ONTAP. Si ce n'est pas le cas, vous devez les installer.

Si le serveur d'autorisation est derrière un pare-feu, ONTAP doit être configuré pour utiliser un serveur proxy.

Il existe plusieurs aspects de l'authentification et de l'autorisation des clients que vous devez prendre en compte.

À un niveau élevé, vous pouvez définir des étendues autonomes définies sur le serveur d'autorisation ou vous appuyer sur les définitions d'identité ONTAP locales existantes, y compris les rôles et les utilisateurs.

Si vous utilisez les définitions d'identité ONTAP, vous devez choisir celles qui doivent être appliquées, notamment :

Vous devez décider si les jetons d'accès seront validés localement par ONTAP ou au niveau du serveur d'autorisation par introspection. Plusieurs valeurs connexes sont également à prendre en compte, telles que l'intervalle d'actualisation.

Pour les environnements nécessitant un niveau de sécurité élevé, vous pouvez utiliser des jetons d'accès avec limite d'envoi basés sur MTLS. Cela nécessite un certificat pour chaque client.

Si vous utilisez un serveur d'autorisation qui représente des groupes utilisant des UUID, vous devez planifier la façon de les mapper aux noms de groupe et éventuellement aux rôles associés.

Vous pouvez administrer OAuth 2.0 via n'importe quelle interface ONTAP, notamment :

Les applications client doivent demander des jetons d'accès directement à partir du serveur d'autorisation. Vous devez décider de la façon dont cela sera fait, y compris le type de subvention.

Vous devez effectuer plusieurs tâches de configuration ONTAP.

En fonction de votre configuration d'autorisation, le traitement local ONTAP Identify peut être utilisé. Dans ce cas, vous devez revoir et définir les rôles REST et les définitions d'utilisateur. En fonction de votre serveur d'autorisation, cela peut également inclure l'administration de groupes basés sur des valeurs UUID.

Trois étapes principales sont nécessaires pour effectuer la configuration principale de ONTAP, notamment :