Skip to main content

security oauth2 client create

Contributors
Suggest changes
PDFs

Configure OAuth 2.0 Provider

Availability: This command is available to cluster administrators at the admin privilege level.

Description

The security oauth2 client create command creates OAuth 2.0 Provider configuration with the specified configuration name for token-based authentication. This command does not enable the OAuth 2.0 feature, it only configures it. Configuring and enabling the OAuth2.0 feature is a two-step process:

  • Create an OAuth 2.0 Provider configuration using the security oauth2 client create command.

  • Enable the OAuth 2.0 feature using the security oauth2 modify`-enabled`true command. This step must be performed once regardless of the number of providers configured. If you have already enabled the OAuth 2.0 feature as part of configuring another provider, you do not have to perform this step again for this provider.

After an OAuth 2.0 configuration is created, it cannot be modified. It must be deleted and created again to change any settings.

Note Enabling/Disabling OAuth 2.0 restarts the web server. Any HTTP/S connections that are active will be disrupted.

Parameters

-config-name <text> - Configuration Entry Name

This is the OAuth 2.0 configuration entry name.

-application <OAuth 2.0 Applications> - Application

This is the application for which OAuth 2.0 is configured. Currently only the http application is supported.

-issuer {scheme://(hostname|IPv4 Address|'['IPv6 Address']')…​} - OAuth 2.0 Issuer

This is the OAuth 2.0 issuer to match with the "iss" field from the access token.

[-audience <text>] - OAuth 2.0 Audience

This is the OAuth 2.0 audience to match with the "aud" field from the access token. If this parameter is not set, then the "aud" field will not be matched and the REST API request will be forwarded to the provider with the matching "iss" field.

[-client-id <text>] - OAuth 2.0 Client ID

This is the Client identifier used in token introspection calls to the IdP server.

[-introspection-endpoint {scheme://(hostname|IPv4 Address|'['IPv6 Address']')…​}] - OAuth 2.0 Token Introspection Endpoint Location

This is the URI of the desired IdP server used for token introspection.

[-introspection-interval {P[<integer>D]T[<integer>H][<integer>M][<integer>S] | P<integer>W | disabled}] - OAuth 2.0 Token Introspection Refresh Interval in ISO-8601 format

This is the refresh interval in ISO-8601 format for caching the introspected tokens. When not set, the default value of 0s is used, which caches introspected tokens for a period of "exp" value in the access token. This can be set to the value disabled to disable caching of tokens. Otherwise, it can be set to a value from 1s to 2147483647s .

[-remote-user-claim <text>] - OAuth 2.0 Remote User Claim

When the -use-local-roles-if-present parameter is set to true, and the token scope rules do not explicitly allow or deny the request, the value of the -remote-user-claim field will be used to find a match in the local user database for a user of the same name with the application of type http and authentication method password . When not set, the default value of sub is used.

[-provider-jwks-uri {scheme://(hostname|IPv4 Address|'['IPv6 Address']')…​}] - OAuth 2.0 Provider JSON Web Key Set Location

This is the URI where the JSON Web Key Set (JWKS) is hosted by the Identity Provider server.

[-jwks-refresh-interval {P[<integer>D]T[<integer>H][<integer>M][<integer>S] | P<integer>W}] - OAuth 2.0 JSON Web Key Set Refresh Interval in ISO-8601 format

This is the refresh interval in ISO-8601 format for caching the JSON Web Key Set (JWKS) key set obtained from the provider-jwks-uri. When not set, the default value of 1h is used. This can be set to a value from 3600s to 2147483647s .

[-outgoing-proxy <text>] - OAuth 2.0 Outgoing Proxy To Access External IdPs

This is the value for outgoing proxy to access external identity providers (IdPs). Use this parameter for local validation to download the JWKS key set in the JWKS URI, or for remote introspection for validating the access token in the Bearer field of the REST API request when the system is behind a proxy.

[-use-local-roles-if-present {true|false}] - Use Local Roles, If Present

When this parameter is set to true , and the scopes in the access token do not explicitly allow or deny the request, the local user role matching the user in the -remote-user-claim field (defaults to value of the "sub" field of the access token if not specified) will be checked for authorization of the request. The default value is false when not set, which means only the scopes in the access token is used to approve or deny the request.

[-skip-uri-validation {true|false}] - Skip URI Validations

When this parameter is set to true , validation of provider-jwks-uri is skipped. The default value of this parameter is false .

[-use-mutual-tls {none|request|required}] - Mutual TLS enforcement

This is the Mutual TLS setting for the OAuth 2.0 configuration. When set to required , OAuth 2.0 mutual TLS authentication is enforced for all access tokens and any token that does not have x5t#S256 property in the cnf section is rejected. The default value is request when not set, which means OAuth 2.0 mutual TLS authentication is enforced only if the x5t#S256 property is present in the cnf section of the access token. This can be disabled by setting to value none .

Examples

The following example creates OAuth 2.0 Provider configuration for Local Validation:

cluster1::> security oauth2 client create -config-name auth1 -application http -issuer https://issuer.example.com/ -provider-jwks-uri https://issuer.example.com/.well-known/jwks.json -use-local-roles-if-present true -remote-user-claim preferred_username -outgoing-proxy https://outgoing_proxy

The following example creates OAuth 2.0 Provider configuration for Remote Introspection:

cluster1::> security oauth2 client create -config-name auth1 -application http -issuer https://issuer.example.com/ -client-id client_id -client-secret client_secret -use-local-roles-if-present true -remote-user-claim preferred_username -outgoing-proxy https://outgoing_proxy -use-mutual-tls required