OAuth + Microsoft Azure AD

Stany
Stany Member Posts: 5

Hello guys,

does anyone have experience with how to set up the Solace connection using Microsoft Azure AD? I am aware of OAuth profiles in Solace admin, but not really sure what to input there.

Thank you very much,

Regards,

Stan.

Tagged:

Best Answer

  • VvT
    VvT Member, Employee Posts: 15 Solace Employee
    #2 Answer ✓

    Hi Stan,

    I think you're on the right track here. In order to connect your client app to Solace via OAuth, you need to create an OAuth Profile, which contains the settings for Solace to be able to connect to Azure and inspect the token you provide.

    OAuth Profile works in two different modes: Client and Resource server. For OIDC compatible tokens Solace recommends to use Client mode. Resource server usually is for non-OIDC compliant JWT tokens or when username or group information isn't present in the token and must be retrieved from an RFC 7662 OAuth 2.0 Token Introspection server. In the case of Azure you can use Resource server for the Access tokens issued by Azure.

    Before you are able to connect your application, you need to setup the OAuth profile and OAuth group(s) matching the names of the Roles defined in Azure and returned in the token. Let's say you define a role named "SolaceClient". The obtained token should contain a claim part:"..."roles": ["SolaceClient"] ..." . You need to create an OAuth Group called SolaceClient, which will be used to map the logged in client app into Solace to a that particular OAuth group matching the name of the role.

    The OAuth profile you configure should have at least:

    "OAuth Client ID": configured to the client ID you define in Azure to allow Solace broker to validate tokens.

    "Issuer Identifier": obtained from the token "iss" claim (if different from the one provided by the Azure endpoint).

    "Discovery Endpoint": the discovery endpoint provided by the Azure Endpoints page (OpenID connect metadata document).

    "Authorization Groups Claim Name": the claim that maps to the roles in the token. In our example value should be "roles".

    "Username Claim Name": a claim from the token which can be used as a username/userId, used for the connection to the Solace broker.

    "Required ID Token Type": the type of the token. For the Azure token the token header value of "typ" should be "JWT".

    After you setup the OAuth Profile and the OAuth Group(s), you should be able to connect with your token to Solace. The client application should set the authentication type to OAuth: AUTHENTICATION_SCHEME_OAUTH2 and set the Access Token for session parameter: OAUTH2_ACCESS_TOKEN.

    Also, make sure the OAuth authentication is enabled on the Solace broker.

    Regards,

    Victor

Answers

  • VvT
    VvT Member, Employee Posts: 15 Solace Employee

    Hi Stan,

    What are you trying to do? Are you trying to connect a publisher to Solace using OAuth? What is your flow and which API are you trying to use?

    Regards,

    Victor

  • Stany
    Stany Member Posts: 5

    Hello Victor,

    thank you for taking this case. Essentially what I am trying to do is replace Kerberos right, so I would like to be able to connect to Solace from the console app and do publish/ subscribe with OAuth. At this moment I am manually setting some JWT token from Azure which is a valid token. On the side of Solace, I am not really sure if I understand the concept of Client or Resource Server, but I have configured the resource server OAuth profile, based on the fields JWT token I pretty set the required AUD to match in the Solace (in parse token section) and hit save.

    I can see in the Stats tab that the requests are coming but it fails on the invalid token part, so maybe you can point me in the right direction maybe how to get some logs on why it is invalid in my .NET console I have set debug logging, but it really does not say anything about the token and also if you are able to clarify the difference between the Client and the resource server would be very valuable, since, for example, I do have Client Secret, Client Id from the registered app in Azure, but that is not really in the token, so does it mean that if I provide it, that the solace would act as a client which can ask the Azure for the token itself? If so, how can I leverage that from the .NET console?

    Thank you for your help.

    Kind regards,

    Stan.

  • VvT
    VvT Member, Employee Posts: 15 Solace Employee
    #5 Answer ✓

    Hi Stan,

    I think you're on the right track here. In order to connect your client app to Solace via OAuth, you need to create an OAuth Profile, which contains the settings for Solace to be able to connect to Azure and inspect the token you provide.

    OAuth Profile works in two different modes: Client and Resource server. For OIDC compatible tokens Solace recommends to use Client mode. Resource server usually is for non-OIDC compliant JWT tokens or when username or group information isn't present in the token and must be retrieved from an RFC 7662 OAuth 2.0 Token Introspection server. In the case of Azure you can use Resource server for the Access tokens issued by Azure.

    Before you are able to connect your application, you need to setup the OAuth profile and OAuth group(s) matching the names of the Roles defined in Azure and returned in the token. Let's say you define a role named "SolaceClient". The obtained token should contain a claim part:"..."roles": ["SolaceClient"] ..." . You need to create an OAuth Group called SolaceClient, which will be used to map the logged in client app into Solace to a that particular OAuth group matching the name of the role.

    The OAuth profile you configure should have at least:

    "OAuth Client ID": configured to the client ID you define in Azure to allow Solace broker to validate tokens.

    "Issuer Identifier": obtained from the token "iss" claim (if different from the one provided by the Azure endpoint).

    "Discovery Endpoint": the discovery endpoint provided by the Azure Endpoints page (OpenID connect metadata document).

    "Authorization Groups Claim Name": the claim that maps to the roles in the token. In our example value should be "roles".

    "Username Claim Name": a claim from the token which can be used as a username/userId, used for the connection to the Solace broker.

    "Required ID Token Type": the type of the token. For the Azure token the token header value of "typ" should be "JWT".

    After you setup the OAuth Profile and the OAuth Group(s), you should be able to connect with your token to Solace. The client application should set the authentication type to OAuth: AUTHENTICATION_SCHEME_OAUTH2 and set the Access Token for session parameter: OAUTH2_ACCESS_TOKEN.

    Also, make sure the OAuth authentication is enabled on the Solace broker.

    Regards,

    Victor

  • Stany
    Stany Member Posts: 5

    Hello Victor,

    thank you so much for explaining the difference and also for providing the minimalist way to make it run. The point I was missing was the creation of an authorization group that would match the claim in "groups".

    Best regards,

    Stan.

  • VvT
    VvT Member, Employee Posts: 15 Solace Employee

    Hi Stan,

    I'm glad that worked. There will be more information very soon on the Solace OAuth configuration.

    Best wishes,

    Victor

  • hong
    hong Guest Posts: 480 ✭✭✭✭✭

    Hi @Stany, FYI. We just published the blog post "How To Connect to Solace PubSub+ SMF with OAuth OpenID Connect". You may find it useful for your project.

  • Stany
    Stany Member Posts: 5

    Hi @hong thank you for the blog post, it is very nicely written and totally helps to get it running.

  • hong
    hong Guest Posts: 480 ✭✭✭✭✭

    Hi @Stany, I'm glad that it is helpful to you. Meanwhile, as you go through your project, consider writing about anything you think other people in the community will benefit from your experience. You can also get paid through the Solace Scholars Program. 😀

  • Stany
    Stany Member Posts: 5

    Hi, @hong I may write about how to integrate it specifically with Microsoft Azure AD. I do not know if it has some value, anyway thank you for the information I look forward to asking more questions on this forum!

    Kind regards,

    Stan.

  • hong
    hong Guest Posts: 480 ✭✭✭✭✭

    Hi @Stany, we have actually already started writing a blog post about the integration with Azure AD. Can you suggest a different topic?