OAuth 2.0 is an authorization framework for controlling access to protected resources. Given this, an important first step with any deployment is to determine what the available resources are and which clients need access to them.

You need to decide which clients will use OAuth 2.0 when issuing REST API calls and what API endpoints they need access to.

You should review the existing ONTAP identity definitions, including the REST roles and local users. Depending on how you configure OAuth 2.0, these definitions can be used for making access decisions.

While you might implement OAuth 2.0 authorization gradually, you can also move all the REST API clients to OAuth 2.0 immediately by setting a global flag for each authorization server. This allows access decisions to be made based on your existing ONTAP configuration without the need for creating self-contained scopes.

The authorization servers play an important role in your OAuth 2.0 deployment by issuing access tokens and enforcing administrative policy.

You need to select and install one or more authorization servers. It's important to become familiar with the configuration options and procedures of your identity providers, including how to define scopes. Note that some authorization servers, including Microsoft Entra ID, represent groups using UUIDs instead of names.

ONTAP uses the authorization server's certificate to validate the signed access tokens presented by the clients. To do this, ONTAP needs the root CA certificate and any intermediate certificates. These might be pre-installed with ONTAP. If not, you need to install them.

If the authorization server is behind a firewall, ONTAP needs to be configured to use a proxy server.

There are several aspects of client authentication and authorization you need to consider.

At a high level, you can either define self-contained scopes defined at the authorization server or rely on the existing local ONTAP identity definitions including roles and users.

If you use the ONTAP identity definitions, you must decide which to apply, including:

You need to decide if the access tokens will be validated locally by ONTAP or at the authorization server through introspection. There are also several related values to consider, such as the refresh interval.

For environments requiring a high level of security, you can use send-constrained access tokens based on mTLS. This requires a certificate for each client.

If you are using an authorization server that represents groups using UUIDs, you need to plan how to map these to group names and possibly to associated roles.

You can perform administration of OAuth 2.0 through any of the ONTAP interfaces, including:

The client applications must request access tokens directly from the authorization server. You need to decide how this will be done, including the grant type.

There are several ONTAP configuration tasks you need to perform.

Based on your authorization configuration, local ONTAP identify processing can be used. In this case, you need to review and define the REST roles and user definitions. And depending on your authorization server, this might also include administering groups based on UUID values.

There are three major steps needed to perform the core ONTAP configuration, including: