Configuring OAuth Authentication

PubSub+ event brokers support authentication with OAuth 2.0 and OpenID Connect (OIDC) to grant management access to the event broker.

There are two ways you can use OAuth for management access in the event broker:

  • Interactive: OAuth is used to authenticate a user interacting with PubSub+ Broker Manager.
  • Automated: An OAuth token is used as credentials to authenticate REST request from SEMPv2.

The information that follows describes the interactive options to configure OAuth for management access to the event broker. To set up automation using SEMPV2, see OAuth Authentication.

Terms you should know

Authorization server: The server where the user is sent to authenticate and receive an authorization code.

Token Server: The server where you get the issued ID token or access token based on the code you provide to the authorization server. Note that the token server can issue an access token, ID token, or both based on the request. For example, if the event broker is serving as a client (oauth-role client), you may receive an ID token and optionally an access token.

Resource Owner : The end user that grants permission to access the resource server with an access token.

Client: The application that requests the token (ID token or access token)from the token server and then passes it to the resource server. By default, event brokers play the role of the client. In this mode, all the configuration under resource-server is ignored.

Resource server: Accepts the access token and verifies that it's valid. The event broker can be configured to play the role of the resource server.

ID token: The OpenID Connect ID token represented as a JWT, given to the client by the token server.

Access token: The URL-encoded or JSON Web Token (JWT) version of the access token given to the client by the token server. The access-token format is not specified; from the client point of view it is an opaque data—the client has no information about the user.

Discovery endpoint: The endpoint that can be used to determine information about the OAuth identity provider, including all the necessary endpoints and the issuer identifier.

OAuth Configuration

To implement OAuth authentication for management access to an event broker, the following configurations are required:

  • The event broker must be configured to use TLS by setting a server certificate. For more information, see Managing Server Certificates.
  • OAuth profile must be created on the event broker with following additional configuration:

    • client-id: Client ID configured on the event broker must match with the OAuth Client ID.

    • client-secret: Client secret configured on the event broker must match with the OAuth Client Secret.

    • endpoints: It is a best practice to either: configure the discovery endpoint and leave the other endpoints unset; or leave the discovery endpoint unset and configure the other endpoints. In addition, be sure to carefully consider endpoint timeouts during configuration. Depending on your deployment, the default timeout may be too short.

You will need to perform additional configurations depending on what token you want to get your claims from (id-token or access-token), claims you expect to receive from the token, and whether you want to use OAuth in the interactive or automated context. The additional configuration will depend on your specific setup. Detailed configuration information is provided in the topics below.

OAuth Profile

To implement OAuth authentication to provide management access to an event broker, you must first create an oauth-profile. There is a limit of ten OAuth profiles per event broker.

To create an oauth-profile, enter the following commands:

solace(configure/authentication)# create oauth-profile <oauth-profile>
solace(configure/authentication/oauth-profile)#

To configure an existing profile, enter the following command:

solace(configure/authentication)# oauth-profile <oauth-profile>

To enable the profile, enter the following command:

solace(configure/authentication/oauth-profile)# no shutdown

To specify a default profile, enter the following command:

solace(configure/authentication)# oauth-profile-default <profile-name>

Where:

<profile-name> is the name of the OAuth profile.

The configuration tasks you can perform for an OAuth profile include:

OAuth Role

You can configure the event broker to act as OAuth client or resource server. By default, the event broker role is set to client. If oauth-role is set to resource-server and client scope does not contain openid scope, the oauth-role cannot be changed to client. The change will be rejected and oauth-role will remain as resource-server. The client scope configuration must contain the openid scope before switching from resource-server to client role. If oauth-role is client, the introspection endpoint is not used and need not be configured, and similarly, the userinfo endpoint will not be used if oauth-role is resource-server.

To set the event broker as a OAuth client or resource server, enter the following command: 

solace(configure/authentication/oauth-profile)# oauth-role [client | resource-server]

The no version of the command, no oauth-role, sets the event broker role to the default client role.

Access Level

The OAuth groups determine the access-level for the dynamic user created by logging in with OAuth. Specific access levels can be configured for each OAuth group. A user may belong to more than one OAuth group, and the access levels defined for each group may differ.

To assign a global access level for CLI users that belong to a given OAuth group, enter the following command:

solace(configure/authentication/oauth-profile)# access-level
solace(...uthentication/oauth-profile/access-level)# create group <group-name>

Where:

group-name is the name of an OAuth group that exists on the OAuth server.

  • To edit the properties for an OAuth group that has already been provisioned on the event broker, enter the following command: solace(...tication/oauth-profile/access-level)# group <group-name>.
  • The group name is case sensitive and must match the case of the groups returned by the OAuth server.

The no version of this command, no group name <group-name>, removes the given group name.

Global Access Levels

To assign a global access level for a given OAuth group, enter the following command:

solace(...on/oauth-profile/access-level/group)# global-access-level [none | read-only | mesh-manager | read-write | admin]

Where:

none specifies a global access level of none.

read‑only specifies a global access level of read-only. The default value is read‑only.

mesh-manager specifies a global access level of mesh-manager.

read-write specifies a global access level of read-write.

admin specifies a global access level of admin.

Message VPN Default Access Levels

To assign a Message VPN default access level for CLI users that belong to a given OAuth group, enter the following commands:

solace(...on/oauth-profile/access-level/group)# message-vpn
solace(...s/access-level/group/message-vpn)# default-access-level [none | read-only | read-write]

Where:

none specifies a default Message VPN access level of none. The default value is none.

read‑only specifies a default Message VPN access level of read-only.

read-write specifies a default Message VPN access level of read-write

Message VPN Access Level Exceptions

To configure an exception to the Message VPN access level for CLI users that belong to the given OAuth group, enter the following command:

solace(...rofile/access-level/group/message-vpn)# create access-level-exception <vpn-name> access-level [none | read-only | read-write]

To modify an existing exception to the default Message VPN access level for CLI users that belong to the given OAuth group, enter the following command:

solace(...rofile/access-level/group/message-vpn)# access-level-exception <vpn-name> access-level [none | read-only | read-write]

Where:

<vpn-name> is the name of a Message VPN that the exception to the default Message VPN access level will apply to.

none specifies a Message VPN access level of none. The default value is none.

read‑only specifies a Message VPN access level of read-only.

read-write specifies a Message VPN access level of read-write.

The no version of this command, no access-level-exception, removes any exceptions so that the CLI user has the default Message VPN access level for all Message VPNs.

Endpoints

OAuth endpoints are the URLs that you use to make authentication requests. All endpoints must be TLS. Any endpoint that does not start with https:// (case insensitive) will be rejected at configuration. Endpoints that are determined through discovery will be rejected at runtime if they are not TLS.

To configure OAuth endpoints, enter the following command:

solace(configure/authentication/oauth-profile)# endpoints

From this level, you can configure the following endpoints:

solace(configure/authentication/oauth-profile)# [authorization | discovery | discovery-refresh-interval | introspection | introspection-timeout | jwks | jwks-refresh-interval | token | token-timeout | userinfo | userinfo-timeout]

Authorization Endpoint

Authorization endpoint is used to obtain an authorization code during the interactive OAuth flow.

To configure an authorization endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# authorization <value>

Where:

<value> is the URL to set for the authorization endpoint.

The no version of the command, no authorization, returns the endpoint value to none.

Discovery Endpoint

The discovery endpoint is the OpenID Connect Discovery endpoint or the OAuth 2.0 Authorization Server Metadata endpoint. Generally, this is the only endpoint that you will need to configure, as this endpoint provides information about the OAuth issuer and all the other endpoints. It is a best practice to either: configure the discovery endpoint and leave the other endpoints unset; or leave the discovery endpoint unset and configure the other endpoints.

To configure a discovery endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# discovery <value>

Where:

<value> is the discovery URL.

The no version of the command, no discovery <value>, returns the endpoint value to none.

Discovery Refresh Interval Endpoint

The discovery refresh interval endpoint is used to configure the number of seconds between a discovery endpoint requests.

To configure a discovery refresh interval request, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# discovery-refresh-interval <value>

Where:

<value> is number of seconds between discovery endpoint requests.

The no version of the command, discovery-refresh-interval, returns its value to the default of 86400 seconds (1 day).

Introspection Endpoint

The token introspection endpoint returns claims associated with the user identified by the access token.

To configure an introspection endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# introspection <value>

Where:

<value> is the URI of the OAuth introspection endpoint. Only HTTPS is supported. If you specify an HTTPS address, certificates and certificate authorities must be configured on the event broker. For more information, see Managing Server Certificates.

The no version of the command, no introspection, returns the endpoint value to none.

Introspection Timeout Endpoint

The configure introspection timeout endpoint is the maximum time in seconds a token introspection request is allowed to occur.

To configure an introspection timeout endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# introspection-timeout <value>

Where:

<value> is the value to set in seconds.

The no version of the command, no introspection-timeout, returns its value to 1 second.

JWKS Endpoint

To verify the ID and access tokens, the event broker needs access to the public keys. These keys are available from the OAuth identity provider's JSON Web Key Set (JWKS) endpoint. This endpoint can be explicitly configured or determined from the discovery document. Thejwks endpoint returns the keys that was used to verify JSON Web Tokens (JWTs) from the OAuth identity provider. The event broker retrieves these keys from that URL to validate token signatures and caches

To configure a JWKS endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# jwks <value>

Where:

<value> is the URI of the jwks endpoint. Only HTTPS is supported. If you specify an HTTPS address, certificates and certificate authorities must be configured on the event broker. For more information, see Managing Server Certificates.

The no version of the command, no jwks, returns the endpoint value to none.

JWKS Refresh Interval

By default, PubSub+ event brokers refresh any JWKS public keys obtained from an OAuth authorization server once every twenty four hours.

Keys are also refreshed any time the following occurs:

  • The refresh interval is changed.
  • The JWKS endpoint is changed.
  • The issuer is changed.
  • The OAuth profile is enabled.
  • The event broker is restarted.

Once every jwks-refresh-interval, the event broker will refresh the set of keys. If the event broker attempts to refresh the key and the request fails, the following retries are performed:

  • retry every 60s indefinitely if valid data is missing
  • retry three times every 60s if valid data exists. The event broker will then stop and wait for the next scheduled refresh or data expiry

In addition, JWKS keys expire when they are older than three times the jwks-refresh-interval.

To configure the JWKS refresh interval, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# jwks-refresh-interval <value>

Where:

<value> is the number of seconds between forced public key refreshes.

The no version of the command, no jwks-refresh-interval, returns its value to the default of 86400 seconds (1 day).

Token Endpoint

Token endpoint is used to obtain the ID token and access token during the interactive OAuth Authorization Code Grant flow.

To configure a token endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# token <value>

Where:

<value> is the URL of the token server.

The no version of the command, no token,returns the endpoint value to none.

Token Timeout Endpoint

Using the token timeout endpoint, you can set the maximum time (in seconds) a token request is allowed to take.

Take careful consideration when deciding how to configure this value. On one hand, depending on the speed of your network, the default of one second may be too short for a token request to complete. On the other hand, longer timeouts may cause performance issues as request queues stack up.

To configure the token timeout endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# token-timeout <value>

Where:

<value> is the number of seconds that a token request is allowed to take.

The no version of the command, no token, returns its value to the default value of 1 second.

Userinfo Endpoint

The UserInfo endpoint is part of the OpenID Connect standard (OIDC), designed to return claims about the authentication user. The endpoints is used in situations where ID token may not contain all the required claims, in which case the access token is used to retrieve the userinfo.

To configure a userinfo endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# userinfo <value>

Where:

<value> is the URL of the userinfo endpoint.

The no version of the command, no userinfo, returns the endpoint value to none.

Userinfo Timeout Endpoint

Using the userinfo timeout endpoint, you can set the maximum time a userinfo request is allowed to take.

To configure a userinfotimeout endpoint, enter the following command:

solace(configure/authentication/oauth-profile/endpoints)# userinfo-timeout <value>

Where:

<value> is the number of seconds is the number of seconds that a userinfo request is allowed to take.

The no version of the command, no userinfo-timeout, returns its value to the default value of 1 second.

Client

A client is the application that wants to access the resource server data. It is the application that requests the access token or ID token from the authorization server and then passes it to the token server to get access to the data.

To configure OAuth client settings on the event broker, enter the following command:

solace(configure/authentication/oauth-profile)# client
solace(...e/authentication/oauth-profile/client)#

From this level, you can configure the following settings:

solace(...e/authentication/oauth-profile/client)# [allowed-host | authorization-parameter | redirect-uri | required-type | scope | validate-type]

Allowed Host

The allowed host is a host:port combination configured as an allowed Host header value for the given event broker. The current best practice is to configure the hostname as a fully qualified domain name. A maximum of four allowed-host can be configured per OAuth profile.

To create an allowed host, enter the following command:

solace(configure/authentication/oauth-profile/client)# create allowed-host <host>

Where:

<host> is the allowed host value for the Host header.

The no version of the command, no allowed-host <host>, deletes the configured allowed host value.

Authorization Parameter

You can add additional parameters to be passed to the OAuth authorization endpoint. A maximum of four additional authorization parameters can be added per OAuth profile. The authorization parameter names must be unique and are case-sensitive.

To add an additional authorization parameter, enter the following command:

solace(configure/authentication/oauth-profile/client)# create authorization-parameter <para-name>

To modify an existing authorization parameter, enter the following command:

solace(configure/authentication/oauth-profile/client)# authorization-parameter <para-name>

Where:

<para-name> is the name of the authorization parameter.

The no version of the command, no authorization-parameter <para-name>, deletes the configured parameter.

Redirect URI

A redirect URI is the endpoint where the authorization server sends the user once the application has been successfully authorized. While setting allowed-host is generally required, it is not necessary to set redirect URI. If redirect URI is not set, the event broker uses the host value provided by the browser to create the correct value. Before using this setting, we recommend that you contact Solace.

To configure a redirect URI, enter the following command:

solace(configure/authentication/oauth-profile/client)# redirect-uri <value>

Where:

<value> is the URL to set for the redirect-uri.

The no version of the command, no redirect-uri <value>, returns the endpoint value to none.

Required Type

The content type required for the ID token header. The default value is JWT.

To configure required type value, enter the following command:

solace(configure/authentication/oauth-profile/client)# required-type <value>

Where:

<value> is the value to set for the required-type.

The no version of the command, no required-type <value>, returns its value to JWT.

Scope

The scope is a mechanism in OAuth 2.0 to limit an application's access to a user's account. It is used to initiate an OAuth flow that supports OpenID Connect. The event broker passes the scope parameter to the OAuth authorization endpoint. The default scope is the openid email. If oauth-role is client, it is an error to change the scope to a value that doesn't include openid, and the change will be rejected. If oauth-role is set to resource-server and validate-scope is true, the scope value returned in the response must be verified to contain all the scope values specified in the required-scope.

To configure the scope parameter, enter the following command:

solace(configure/authentication/oauth-profile/client)# scope <value>

Where:

<value> is the space-separated list of values to set for the scope.

The no version of the command, no scope <value>, returns its value to the default openid email.

Validate Type

The validate-type parameter verifies the token ID type. By default, it is set to true. If validate-type is true, tokens that don't have the typ header field will fail to validate. Generally, most OAuth identity providers set typ to JWT. Also, if validate-type is enabled (default), the typ field in the JWT header must match the value configured in required-type.

To configure the validate type parameter, enter the following command:

solace(configure/authentication/oauth-profile/client)# validate-type

The no version of the command, no validate, changes the default value (true) to false.

Required Claim

You can configure required claims in the event broker to verify the ID token. All claims specified under required-claim must match exactly. The required-claim values are specified as JSON, and may be strings, numbers, or arbitrary JSON objects. A maximum of four required claims can be configured per OAuth profile.

To create a required claim, enter the following command:

solace(configure/authentication/oauth-profile/client)# create required-claim <name> <value>

Where:

<name> is name of the ID token claim to verify. The claim names must be unique and are case-sensitive.

<value> is the required claim value, which must be a string containing a valid JSON value.

The no version of the command, no required-claim <value>, deletes the configured claim.

Resource Server

In the OAuth flow, the resource server accepts the access token and verifies that it's valid. The configurations under resource-server only has effect if oauth-role is resource-server.

To configure OAuth resource server settings, enter the following command:

solace(configure/authentication/oauth-profile)# resource-server
solace(...e/authentication/oauth-profile/resource-server)#

From this level, you can configure the following settings:

solace(...e/authentication/oauth-profile/resource-server)# [parse-access-token | required-audience | required-claim | required-issuer | required-scope | required-type | validate-audience | validate-issuer | validate-scope | validate-type]

Parse Access Token

You can enable or disable parsing of the access token as a JWT. It is enabled by default. When parse-access-token is enabled, the access token is examined to determine whether it contains the claims specified for the username and groups. If it contains both claims, no further processing is required, and values of the appropriate claims are used. However, if an introspection endpoint is provided (either directly or via discovery), every access token is checked even if the token contains the username and groups. If parse-access-token is disabled, the introspection-endpoint must be specified.

To disable the default parse-access-token, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# no parse-access-token

Required Type

The content type required for the access token header. The default value is JWT.

To configure required type value, enter the following command:

solace(configure/authentication/oauth-profile/client)# required-type <value>

Where:

<value> is the value to set for the required-type.

The no version of the command, no required-type <value>, returns its value to JWT.

Required Audience

You can configure the event broker to validate the required audience parameter provided by the client. The required-audience value must match the aud claim if the aud claim is a string and if it is an array of strings, it must match one of the values of the aud claims. If the required-audience value is incorrect, the event broker rejects the connection attempt.

To configure OAuth required audience value, enter the following command:

solace(...e/authentication/oauth-profile/resource-server)# required-audience <value>

The no version of the command, no required-audience <value>, returns the value to none.

Required Claim

You can configure required claims in the event broker to verify the access token or introspection response. All claims specified under required-claim must match exactly. The required-claim values are specified as JSON, and may be strings, numbers, or arbitrary JSON objects. A maximum of 8 required claims can be configured per OAuth profile.

To create a required claim, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# create required-claim <name> <value>

Where:

<name> is name of the id-token claim to verify. The claim names must be unique and are case-sensitive.

<value> is the required claim value, which must be a string containing a valid JSON value.

The no version of the command, no required-claim <value>, deletes the configured claim.

Required Issuer

You can configure the required issuer claim value in the event broker as part verifying the access token or introspection response. The configured required-issuer value must match the iss claim. If the required-issuer is not specified, the issuer from the discovery endpoint is used to verify the iss claim.

To configure a required issuer claim, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# required-issuer <value>

Where:

<value> is the value to configure for the required issuer claim.

The no version of the command, no required-claim <value>, returns the value to none.

Required Scope

The required scopes are space-separated list of scopes that must be present in the scope claim The scope claim must contain all of the values in required-scope, but may contain other scopes, and the scopes may be in a different order. If the required-scope is empty or not set, no scope verification is performed.

To configure the required scope on the event broker, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# required-scope <value>

Where:

<value> is the value to configure for the required issuer claim.

The no version of the command, no required-scope <value>, returns the value to none.

Validate Audience

You can configure the event broker to validate audience parameter to verify the aud claim in the access token or introspection response. By default this feature is enabled. If validate-audience is disabled, required-audience validation is not performed. If it is enabled, the validation described at required-audience will be performed.

To configure the event broker to validate the audience claim, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# validate-audience

The no version of the command, no validate-audience, disables it.

Validate Issuer

You can configure the event broker to validate issuer parameter to verify the iss claim in the access token or introspection response. By default this feature is enabled. If validate-issuer is disabled, required-issuer validation is not performed. If it is enabled, the validation described at required-issuer will be performed.

To configure the event broker to validate the issuer claim, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# validate-issuer

The no version of the command, no validate-issuer, disables it.

Validate Scope

You can configure the event broker to validate scope parameter to verify the scope claims in the access token or introspection response. By default this feature is enabled. If validate-scope is disabled, required-scope validation is not performed. If it is enabled, the validation described at required-scope will be performed.

To configure the event broker to validate scope claims, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# validate-scope

The no version of the command, no validate-scope, disables it.

Validate Type

You can configure the event broker to validate scope parameter to verify the typ field in the access token header. By default this feature is enabled. If validate-type is disabled, required-type validation is not performed. If it is enabled, the validation described at required-type will be performed.

To configure the event broker to validate the typ field, enter the following command:

solace(configure/authentication/oauth-profile/resource-server)# validate-type

The no version of the command, no validate-type, disables it.

Access Level Group Claim

The access level group claim name is the name of the claim that contains the groups that the event broker will use to authorize the user. Once all appropriate token verification has been performed, the event broker will determine the OAuth groups based on the access-level-groups-claim-name.

To configure an access level groups claim name, enter the following command:

solace(configure/authentication/oauth-profile)# access-level-groups-claim-name <value>

Where:

<value> is the field in the token used to determine the access level group. If no value is provided, groups is used as the default. When using JWTs, claim names must be at the top level of the JWT. In other words, they cannot be embedded. In addition, the value of any claim that you want to use as an access level group must be a string or an array of strings.

In this example the "aclevGroupClaim" field is used to determine the access level group, and its value is the string "abcdefghi":

{
...
   "aclevGroupClaim": "abcdefghi",
...
}

In this example the "aclevGroup" field is used to determine the authorization group, and its value is the string array ["a b c", "def", "ghi"]. The event broker interprets this array as three authorization groups, "a b c" (including the spaces), "def", and "ghi".

{
...
   "aclevGroup": ["a b c", "def", "ghi"],
...
}

The no version of the command, no access-level-groups-claim-name, returns its value to the default groups.

For compatibility, you can configure the event broker to interpret a string value for the claim as a space-delimited set of groups, similar to the scope claim. For example, a claim value of "a b c" would be interpreted as three groups: "a", "b", and "c".

To configure this behaviour, enter the following command:

solace(configure/authentication/oauth-profile)# access-level-groups-claim-string-format space-delimited

The no version of the command, no access-level-groups-claim-string-format, returns its value to the default single.

Client ID

When a client registers with an OAuth identity provider they receive a Client ID along with a Client Secret. These are essentially equivalent to username and password, which the authorization server uses to authenticate the application. The client-id identifies the client responsible for the OAuth request.

To configure client ID on your event broker, enter the following command:

solace(configure/authentication/oauth-profile)# client-id <value>

Where:

<value> is the OAuth provided Client ID.

The no version of the command, no client-id, returns the value to none.

Client Secret

When a client registers with an OAuth identity provider they receive a Client ID and Client Secret. These are essentially equivalent to username and password, which the authorization server uses to authenticate the application.

To configure client secret on your event broker, enter the following command:

solace(configure/authentication/oauth-profile)# client-secret <value>

Where:

<value> is the OAuth provided Client Secret.

The no version of the command, no client-secret, returns the value to none.

Interactive Login

The interactive login option is used to authenticate user interacting with Broker Manager or any other browser-based web applications that use SEMPv2. The feature is enabled by default. Disabling the feature will disable login via OAuth when using Broker Manager.

To disable interactive log in via OAuth, enter the following command:

solace(configure/authentication/oauth-profile)# no interactive

Display Name

You can configure a friendly display name to be used as your OAuth login profile. If display-name is not configured, OAuth profile name is used.

To configure the display name for your OAuth profile, enter the following command:

solace(configure/authentication/oauth-profile)# display-name <value>

Where:

<value> is the display name to be configured.

The no version of the command, no display-name <value>, returns its value to none.

Prompt For Expired Sessions

When an OAuth session has expired (not new or logged out), the prompt for expired sessions can be used to log back in.

To configure prompt for expired sessions for an OAuth profile, enter the following commands: 

solace(configure/authentication/oauth-profile)# prompt-for-expired-session <value>

Where:

<value> is the value of the prompt parameter provided to the OAuth authorization server for login requests where the session has expired.

The no version of the command, no prompt-for-expired-session <value>, returns its value to none.

Prompt for New Sessions

Prompt for new sessions is used for new OAuth session or to log back in if the user has explicitly logged out.

To configure prompt for new sessions for an OAuth profile, enter the following commands: 

solace(configure/authentication/oauth-profile)# prompt-for-new-session <value>

Where:

<value> is the value of the prompt parameter provided to the OAuth authorization server for login requests where the session is new or the user has explicitly logged out.

The no version of the command, no prompt-for-new-session <value>, returns its value to none.

Global Forward Proxy

Depending on your deployment, you may require that communication between the event broker and authorization servers goes through a global forward proxy. This is often the case if your event broker sits behind a firewall and egress traffic needs to connect to a proxy server to go outside the firewall.

To configure a global forward proxy for an OAuth profile, enter the following command:

solace(configure/authentication/oauth-profile)# proxy <proxy-name>

Where:

<proxy-name> is the name of the global forward proxy configured on the event broker to use for discovery, token, user info, and introspection requests. For more information, see Global Forward Proxy Configuration.

The no version of this command, no proxy, removes any configured global forward proxy.

SEMP

This is the SEMP setting for the OAuth profile that controls whether the profile can be used for authentication of bearer tokens in SEMPv2 calls. This feature is enabled by default. To learn more about OAuth configuration with SEMPv2, see OAuth Authentication.

To configure OAuth for SEMP, enter the following commands: 

solace(configure/authentication/oauth-profile)# semp <value>

The no version of the command, no semp, disables the ability to authenticate SEMPv2 requests with OAuth.

Issuer

The issuer is the identifier of the authorization server. The issuer identifier is automatically determined from the discovery endpoint, if the discovery endpoint has been configured.

To configure issuer identifier, enter the following commands: 

solace(configure/authentication/oauth-profile)# issuer <value>

Where:

<value> is the value for issuer identifier. The value will be available in the discovery endpoint, if configured.

The no version of the command, no issuer <value>, returns the value to none.

Username Claim Name

Username claim name is the name of claim containing the username that the event broker verifies. You can configure a custom username-claim-name, which must be a string; for example, email. Claims of other types such as number, boolean, object, array, etc., are not supported.
To configure username claim name, enter the following commands: 

solace(configure/authentication/oauth-profile)# username-claim-name <value>

Where:

<value> is the name of the username-claim-name.

The no version of the command, no username-claim-name <value>, returns its value to the default sub.

OAuth for Management Access Example Configuration

The following example shows how to configure OAuth authentication for management access on an event broker with the event broker serving as a client.

In this example, it is assumed that the discovery endpoint contains the following information:

solace(configure/authentication)# create oauth-profile solace
solace(configure/authentication/oauth-profile)# client-id 863072204556-uf9jkn4i08429rsu91ejmi51ve5arjc1.apps.solace.com
solace(configure/authentication/oauth-profile)# client-secret 83nw9OsXglnbyrU7ZjUyvSRK
solace(configure/authentication/oauth-profile)# username-claim-name email
solace(configure/authentication/oauth-profile)# endpoints
solace(configure/authentication/oauth-profile/endpoints)# discovery https://accounts.solace.com/.well-known/openid-configuration
solace(configure/authentication/oauth-profile/endpoints/discovery)# exit
solace(configure/authentication/oauth-profile)# no shutdown
solace(configure/authentication/oauth-profile)# client
solace(...e/authentication/oauth-profile/client)# create allowed-host my.pubsubplus.manager.url:1943
solace(...e/authentication/oauth-profile/client)# exit
solace(configure/authentication/oauth-profile)# access-level-groups-claim-name my_groups_claim_name
solace(configure/authentication/oauth-profile)# access-level
solace(...entication/oauth-profile/access-level)# create group my_admin_group_claim_value
solace(...tion/oauth-profile/access-level/group)# global-access-level admin
solace(...entication/oauth-profile/access-level)# create group my_read_only_group_claim_value
solace(...tion/oauth-profile/access-level/group)# global-access-level read-only

Once OAuth is successfully configured on the event broker, a new log in button appears on the Broker Manager's login screen. Clicking the button will automatically log the users in to Broker Manager via the OAuth identity provider. For more information about accessing Broker Manager, see Accessing Broker Manager.