Client Authorization for Messaging Access

After a client connection to an event broker service is successfully authenticated, access to the event broker resources and messaging capabilities within that event broker service must be authorized for the client.

For a client to be authorized, it must provide the host event broker with a client username that matches one that is provisioned on the event broker service. Client usernames can either be provided by the connected client or be automatically generated for the client based on an LDAP or OAuth group that it is a member of. If the client provides a valid client username and credentials, the client’s connection is authorized.

Once authorized, the following profiles, which are assigned to the provisioned client username are used to provide the client with its access permissions and messaging capabilities:

ACL profiles

ACL profiles define whether the client is permitted to connect to the event broker service, and which permissions are assigned to the client that determine whether it can publish messages to topics, whether it can subscribe to topics, and whether its publish and subscribe rights are limited to an explicit set of topics. For more information, see to Controlling Client Access with ACL Profiles.

Client profiles

Client profiles are sets of common configuration parameters that can be applied to groups of clients. Client profiles allow consistent configurations to be readily defined for many clients. For more information, see to Using Client Profiles and Client Usernames.

For more information about configuring client authentication and client profiles, see Managing Access and Authentication.

The following diagram shows the basic process for authorizing an authenticated client according to the authorization properties assigned to the client username.

The authorization process occurs as follows:

1. The client authenticates with the event broker service.
2. The event broker service checks the client credentials to determine authorization in the following order:
   1. Checks that the client provided a valid client username. If so, then it proceeds to step 3.
   2. If a valid client username isn't provided, checks if the client presented an OAuth token and that OAuth is enabled. If so, then proceeds to Authorizing Clients Through OAuth.
   3. If unable to authorize the client using OAuth, checks if LDAP group authorization is enabled and, if so, proceeds to Authorizing Clients Through LDAP Groups. If LDAP group authorization is not enabled, the event broker service binds the client to the default client username and proceeds to step 3.
3. If client authorization continues using the client username, the event broker service checks if the bound client username is active on the event broker. If it is not, the client is disconnected.
4. If the bound client username is active, the event broker service checks if the assigned ACL profile for the client username allows the client to connect. If it does not, the client is disconnected.
5. The client is authorized to perform actions and access resources allowed by the assigned client profile and ACL profile.

Authorizing Clients Through Client Usernames

When event brokers authorize clients using the internal database, client usernames provisioned on the Message VPN determine a client’s authorization. This is the default authorization mode for event broker services. If the client provides a client username that matches a client username provisioned on the event broker service, the client profile and ACL profile configured for that client username are applied to the client. If the client does not provide a client username, the event broker attempts to apply the client username named default and the client profile and ACL profile configured for that client username.

The default client username in not enabled by default.

After the client binds to a client username, the event broker checks whether that client username is enabled. If the client username is not enabled, the client is disconnected. The event broker sends the response “403 Client Username Is Shutdown” before disconnecting.

If the bound client username is enabled, the client is then created with the properties of the client profile and ACL profile configured for the client username account object.

Authorizing Clients Through OAuth

Clients that log in using an OAuth token can receive authorizations based on whether they belong to specific authorization groups. For more information about configuring OAuth authentication, see Configuring an Event Broker Service to Use OAuth Identity Provider Authorization.

When OAuth authorization is enabled for an event broker service that an authenticated client is attempting to connect to, the event broker extracts authorization groups from the provided OAuth token or the token introspection result. The event broker then compares the extracted groups with authorization groups configured on the event broker. Once the client's authorization group is determined, the client profile and ACL profile configured for the group are applied to the client. These profiles provide the client with its authorizations.

The following diagram shows the basic process for authorizing an authenticated client that belongs to a configured authorization group using OAuth.

The authorization process occurs as follows:

1. The client authenticates with the event broker service. During the authentication process it receives a token from the OAuth service provider, which it presents to the event broker.
2. The event broker service checks that the OAuth authorization group claim it receives from the client matches an active authorization group on the event broker. If not, the client is disconnected. If so, the client receives a dynamically created username and is assigned the client profile and ACL profile associated with the username.
3. The event broker service checks if the assigned ACL profile allows the client to connect. If it does not, the client is disconnected.
4. The client is authorized to perform actions and access resources allowed by the assigned client profile and ACL profile.

Authorizing Clients Through LDAP Groups

Clients can receive authorization based on whether they belong to specific LDAP authorization groups. Using LDAP authorization groups can assist network administrators that deal with large numbers of clients, especially when those clients are already configured in a corporate server, and churn frequently as employees join and leave an organization.

When LDAP authorization is enabled for the event broker service that an authenticated client is attempting to connect to, an LDAP attribute (typically MEMBEROF) is retrieved for the client, and an LDAP lookup is made to an external LDAP server to determine the LDAP groups that the client belongs to.

Any LDAP groups that the lookup returns are compared against the LDAP authorization groups configured on the event broker, and the client is assigned the matching enabled authorization group that has the highest priority.

The maximum number of authorization groups that can be retrieved for a client from an external LDAP server is 128. The client is not authorized if more authorization groups are returned.

A client username is then automatically generated for the client, and the client profile and the ACL profile configured for the matching group are applied to the client username that the client is bound to. These profiles provide the client with its authorizations.

The following diagram shows the basic process for authorizing an authenticated client that belongs to a configured LDAP authorization group.

The authorization process occurs as follows:

1. The client authenticates with the event broker service.
2. The event broker service performs an LDAP lookup for the groups that the client belongs to.
3. The event broker service checks it has an active group matching a group returned by the LDAP lookup. If not, the client is disconnected. If so, the client receives a dynamically created username and is assigned the client profile and ACL profile associated with the username.
4. The event broker service checks if the assigned ACL profile allows the client to connect. If it does not, the client is disconnected.
5. The client is authorized to perform actions and access resources allowed by the assigned client profile and ACL profile.