I followed this blog tutorial on how to configure Oauth with Keycloak and manage to configure it correctly, managing the oauth mapping groups to ACL profiles in Solace.
So, first question is: Is this type of Oauth flow still recommended?
Then I also tried to use client credentials flow, but didn’t manage to map the oauth groups with solace authorization groups the same way.
Using client credentials flow, can I use a single clientId/solace oauth profile and having the groups mapping functionality? Or do I need to configure 1 solace oauth profile per each clientId that connects to Solace?
Hi there, I’m Solly AI, I generate responses to your questions using the power of the Solace Agent Mesh:
Please remember that AI technology can make mistakes so ensure that you read our Disclaimer.
AI Generated responses are a work in progress, your help in evaluating my response would be awesome! If my response makes sense, please mark it as a solution or give a . If my response doesn’t make sense for your topic, please react to it with a .
Looking at the documentation, I can provide information about configuring OAuth with Keycloak for a software broker. Here’s the key information:
For OAuth configuration with Keycloak, you need to:
Create and configure an OAuth profile at the Message VPN level:
- Configure the OAuth role (client or resource-server)
- Set up endpoints (discovery or individual endpoints)
- Configure client ID and client secret
- Set up authorization groups claim name for group mapping
For group mapping specifically:
- Use the `authorization-groups-claim-name` setting to specify which claim contains the groups
- The claim must be at the top level of the JWT
- The claim value must be either a string or array of strings
- Can configure string format as either single value or space-delimited
For client credentials flow:
- Set OAuth role to "resource-server"
- Configure introspection endpoint if using opaque tokens
- Enable parse-access-token if using JWTs
- Configure required scopes and claims as needed
The documentation doesn’t specifically address password grant deprecation, but provides the framework for implementing client credentials flow as an alternative.
For specific Keycloak configuration steps and commands, please refer to the Solace documentation as the exact details will depend on your Keycloak setup and requirements.
The reason that I used the password grant in the blog was for simplicity. Typically, for a user account, you would use an authorization code grant. The authorization code grant requires two calls, one to get the authorization code and then another to exchange it for the token. I was just trying to simplify my blog; I didn’t intend to recommend a particular grant type. The type of grant you select should be based on details of your use-case. Certain grant types are not appropriate for some situations.
You should be able to setup a single OAuth Profile in the broker and use the groups mapping to authorize different users with different client and ACL profiles. I’m not sure exactly how to configure it in Keycloak; there are usually differences in how service accounts are configured vs. user accounts in most IDPs. A service account would typically be for a machine to machine use-cases and you would normally use a client credentials grant for this type of use. It sounds to me like you are on the right track.
I’m assuming here many client Ids/oauth profiles in Solace, because is the only secured way I see to have different clients mapped with corresponding authorization groups. If we use one single clientId/oauth profile, we can have different scopes, but the client credentials are shared, meaning if one application knows what scope is used by another, it can access their Solace objects… or am I seeing it completely wrong?
In another hand, when using password Oauth grant type flow, since each user on Oauth Server belongs to a group, we can map 1-1 Oauth server group<->Authorization group and allows to have a more fine-grained and secured control.
Since the client_credentials is the recommended way to setup this, can you please advise how we should approach this?
We switched to client_credentials flow, and tried both oauthRole = Client and oauthRole = Resource Server, successfully.
But we have 2 questions here:
oauthRole = Client is the Solace’s default configuration and it uses the ID token from OIDC. Seems this is not the recommended way to this use-case (invocation of an API): ID Token and Access Token: What Is the Difference? | Auth0
"One of the most common mistakes developers make with an ID token is using it to call an API.
As said above, an ID token proves that a user has been authenticated. In a first-party scenario, i.e. in a scenario where the client and the API are both controlled by you, you may decide that your ID token is good to make authorization decisions: maybe all you need to know is the user identity."
For oauthRole = Resource Server, each solace client can have a different clientId/secret and it’s the way we used to configure oauth.
We have a doubt here: is Solace using introspection endpoint in every API invocation??
Means the total requests to API using oauth, or means the total “discoveries” using the discovering endpoint, in the frequency of “Discovery Endpoint Refresh Interval”?
Sorry about the delayed reply, I didn’t receive a notification, I’ll have to check my account settings.
The good news is I think we can support what you want to do, with the client credentials grant. I believe the trick to understanding this is that the client ID that your application user is using is not the same as the client ID that you configure in the OAuth Profile on the broker (this will depend on how your authorization server behaves). The OAuth Profile should be set to be in client mode. Your client application will will present its client ID and secret to the token endpoint of the authorization server (this is the client credentials grant). The token returned is a JWT and the “aud” claim in that token must match the client ID that is configured in the OAuth Profile (see Configuring Client Authentication). The client ID configured on the broker corresponds to an application in the greater sense rather than a specific application instance. You may need to do some configuration on your Authorization server to get it to populate the “aud” claim in the correct way. Now you can have ClientID A and ClientID B as two different application instances and they can both use a single OAuth Profile that is associated with the application.
If we can get that part working, the authorization part of this should work as you have drawn for the password grant. You configure a claim that contains the groups in the OAuth profile and the broker will parse out a list of groups from that claim. That list of groups is compared against the authorization groups configured in the message-VPN. If one of the groups (from the token) matches with the name of one of the authorization groups, that user will be assigned to that authorization group (the authorization group points to the ACL and client profiles).
. If my response doesn’t make sense for your topic, please react to it with a 
.
