Skip to main content

OAuth 2.0 deployment scenarios

Contributors dmp-netapp netapp-dbagwell netapp-aherbin
PDFs

There are several configuration options available when defining an authorization server to ONTAP. Based on these options, you can define an authorization server appropriate for your environment using one of several deployment scenarios.

Summary of the configuration parameters

There are several configuration parameters available when defining an authorization server to ONTAP. These parameters are generally supported in all the administrative interfaces.

Note The name used for an individual parameter or field can vary depending on the ONTAP administrative interface. To accommodate the differences in the administrative interfaces, a single generic name is used for each parameter in the table. The exact name used with a specific interface should be obvious based on the context.
Parameter Description

Name

The name of the authorization server as it is known to ONTAP.

Application

The ONTAP internal application the definition applies to. This must be http.

Issuer URI

The FQDN with path identifying the site or organization that issues the tokens.

Provider JWKS URI

The FQDN with path and file name where ONTAP obtains the JSON Web Key Sets used to validate the access tokens.

JWKS refresh interval

The time interval determining how often ONTAP refreshes certificate information from the provider JWKS URI. The value is specified in ISO-8601 format.

Introspection endpoint

The FQDN with path that ONTAP uses to perform remote token validation through introspection.

Client ID

The name of the client as defined at the authorization server. When this value is included, you also need to provide the associated client secret based on the interface.

Outgoing proxy

This is to provide access to the authorization server when ONTAP is behind a firewall. The URI must be in curl format.

Use local roles if present

A boolean flag determining if the local ONTAP definitions are used, including a named REST role and local users.

Remote user claim

An alternative name that ONTAP uses to match local users. Use the sub field in the access token to match the local username.

Audience

This field defines the endpoints where the access token can be used.

Deployment scenarios

Several common deployment scenarios are presented below. They are organized based on whether token validation is performed locally by ONTAP or remotely by the authorization server. Each scenario includes a list of the required configuration options. See Deploy OAuth 2.0 in ONTAP for examples of the configuration commands.

Tip After defining an authorization server, you can display its configuration through the ONTAP administrative interface. For example, use the command security oauth2 client show with the ONTAP CLI.

Local validation

The following deployment scenarios are based on ONTAP performing token validation locally.

Use self-contained scopes without a proxy

This is the simplest deployment using only OAuth 2.0 self-contained scopes. None of the local ONTAP identity definitions are used. You need to include the following parameters:

  • Name

  • Application (http)

  • Provider JWKS URI

  • Issuer URI

You also need to add the scopes at the authorization server.

Use self-contained scopes with a proxy

This deployment scenario uses the OAuth 2.0 self-contained scopes. None of the local ONTAP identity definitions are used. But the authorization server is behind a firewall and so you need to configure a proxy. You need to include the following parameters:

  • Name

  • Application (http)

  • Provider JWKS URI

  • Outgoing proxy

  • Issuer URI

  • Audience

You also need to add the scopes at the authorization server.

Use local user roles and default username mapping with a proxy

This deployment scenario uses local user roles with default name mapping. The remote user claim uses the default value of sub and so this field in the access token is used to match the local username. The username must be 40 characters or less. The authorization server is behind a firewall so you also need to configure a proxy. You need to include the following parameters:

  • Name

  • Application (http)

  • Provider JWKS URI

  • Use local roles if present (true)

  • Outgoing proxy

  • Issuer

You need to make sure the local user is defined to ONTAP.

Use local user roles and alternate username mapping with a proxy

This deployment scenario uses local user roles with an alternate username which is used to match a local ONTAP user. The authorization server is behind a firewall, so you need to configure a proxy. You need to include the following parameters:

  • Name

  • Application (http)

  • Provider JWKS URI

  • Use local roles if present (true)

  • Remote user claim

  • Outgoing proxy

  • Issuer URI

  • Audience

You need to make sure the local user is defined to ONTAP.

Remote introspection

The following deployment configurations are based on ONTAP performing token validation remotely through introspection.

Use self-contained scopes with no proxy

This is a simple deployment based on using the OAuth 2.0 self-contained scopes. None of the ONTAP identity definitions are used. You must include the following parameters:

  • Name

  • Application (http)

  • Introspection endpoint

  • Client ID

  • Issuer URI

You need to define the scopes as well as the client and client secret at the authorization server.