The OAuth 2.0 implementation within ONTAP is designed to be flexible and robust, providing the options you need to secure the ONTAP environment. At a high level, there are three main configuration categories for defining the ONTAP client authorization. These configuration options are mutually exclusive.

ONTAP applies the single most appropriate option based on your configuration. See How ONTAP determines access for more about how ONTAP processes your configuration definitions to make access decisions.

These scopes contain one or more custom REST roles, each encapsulated in a single string. They are independent of the ONTAP role definitions. You need to define these scope strings at your authorization server.

Based on your configuration, the local ONTAP identity definitions can be used to make access decisions. The options include:

The scope syntax for a named role is ontap-role-<URL-encoded-ONTAP-role-name>. For example, if the role is "admin" the scope string will be "ontap-role-admin".

If the local ONTAP definitions are examined but no access decision can be made, the Active Directory ("domain") or LDAP ("nsswitch") groups are used. Group information can be specified in one of two ways:

Self-contained scopes are strings carried in the access token. Each is a complete custom role definition and includes everything ONTAP needs to make an access decision. The scope is separate and distinct from any of the REST roles defined within ONTAP itself.

To properly design and implement OAuth 2.0, you need to understand how your authorization configuration is used by ONTAP to make access decisions for the clients.

If the access token contains any self-contained scopes, ONTAP examines those scopes first. If there are no self-contained scopes, go to step 2.

With one or more self-contained scopes present, ONTAP applies each scope until an explicit ALLOW or DENY decision can be made. If an explicit decision is made, processing ends.

If ONTAP can’t make an explicit access decision, continue to step 2.

ONTAP examines the value of the flag use-local-roles-if-present. The value of this flag is set separately for each authorization server defined to ONTAP.

If the access token contains a named REST role, ONTAP uses the role to make the access decision. This always results in an ALLOW or DENY decision and processing ends.

If there is no named REST role or the role is not found, continue to step 4.

Extract the username from the access token and attempt to match it to a local ONTAP user.

If a local ONTAP user is matched, ONTAP uses the role defined for the user to make an access decision. This always result in an ALLOW or DENY decision and processing ends.

If a local ONTAP user is not matched or if there’s no username in the access token, continue to step 5.

Extract the group from the access token and attempt to match it to a group. The groups are defined using Active Directory or an equivalent LDAP server.

If there’s a group match, ONTAP uses the role defined for the group to make an access decision. This always result in an ALLOW or DENY decision and processing ends.

If there’s no group match or if there’s no group in the access token, access is denied and processing ends.