[Feature]: Support for OAuth authentication

[pascalre]

Feature Description

Currently solace-pretty-dump does only support basic auth as authentication scheme against the PubSub+ Broker. OAuth2 could be used as a more secure way of authentication.

Use Case

Basic Authentication sends the username and password with each request in plain text, which can be intercepted and compromised. OAuth2, on the other hand, uses tokens and cryptographic signatures, reducing the risk of exposing credentials.

Proposed Solution

No response

[aaron-613]

Hey @pascalre ..! Thanks for raising the issue... unfortunately I just noticed it now after more than a month. That's weird.

Yes, it's been on my mind to improve the way it does authentication. Since you raised this, maybe I'll prioritize it. Thanks! Stay tuned.

EDIT: I thought that if you're using TLS to connect to the broker (tcps//blahblahblahb:55443) that the basic username and password (part of SMF connect) would be sent within the encrypted TLS channel. No? Just did a quick Wireshark to confirm. So... how would it be intercepted? Still... OAuth authentication would be a nice feature.

[aaron-613]

How would you expect this to work? Would cutting/pasting tokens and ID strings via command-line parameters work? (or obviously environment/shell variables, to hide from command history).

Since v1.1, I've added the ability to override some (most?) JCSMPProperties from the comand line, using a double-hyphen and the property name. If you run prettydump --defaults it will list out all the JCSMPProperties it sees.

Looking at this OAuth JCSMP sample here, it just appears we need to pass it in some Strings with the the token and ID. So maybe it could be as easy as:

prettydump --AUTHENTICATION_SCHEME=AUTHENTICATION_SCHEME_OAUTH2 --OAUTH2_ACCESS_TOKEN="long-access-token-here" --OAUTH2_ISSUER_IDENTIFIER="issuer-id-here"

Using either OAUTH2_ACCESS_TOKEN or OIDC_ID_TOKEN. What do you think of this approach? I don't have access to any OAuth infrastructure for testing... maybe I should set something up.

[pascalre]

Hello @aaron-613, you're absolutely right that TLS encrypts the entire communication channel, including Basic Authentication credentials, which does prevent interception in transit. However, OAuth2 offers additional layers of security beyond just transport encryption. In the meantime, I developed a small message browser for myself that supports OAuth, so I no longer need this tool to include it. I understand that adding OAuth support to an official tool would be challenging, given the variety of OAuth flows available. The snippet you posted looks good and would definitely enhance the tool. However, it’s also essential for the application to retrieve the token initially, which can vary depending on the customer setup.

[aaron-613]

Hi again @pascalre , ok sounds good. Seems like a lot of people are building queue browsers recently. Not sure how involved your OAuth token retrieval/refresh is, but surely it would've been easier to just forke this project and override the authentiation part with your own vs. building a whole 'nother application?

Either way, whatever works for you! I will still add ability to pass OAuth tokens from the command line, since that's pretty straightforward. But yeah: retrieval of the token is outside the scope of this app. That's all custom code? How would any generic app do this, I'm quite interested.

[pascalre]

I already had a queue publisher and receiver adapted to our OAuth setup, so integrating browsing functionality was straightforward. I'm not sure yet, how a generic app could retrieve the token. As a starting point, it might be best to simply pass the token directly as argument to the app.