Skip to content

Conversation

emelialei88
Copy link
Collaborator

@emelialei88 emelialei88 commented May 13, 2025

Handing authentication logic on the broker side:

  • Added authentication protocol.
  • Introduced a new AuthenticationEvent event type.
  • Implemented the authenticator component to handle authentication logic, using AuthenticationContext to encapsulate relevant context data.
  • Updated InitialConnectionHandler to handle the authentication flow.

At this stage, we only handle incoming authentication requests and always allow them to succeed. Outbound, reverse authentication requests initiated by a broker, and re-authentication are not supported.

We also updated the unit test m_bmqstoragetool_cslprinter.t to align with changes made by bascodegen.

@emelialei88 emelialei88 requested a review from a team as a code owner May 13, 2025 14:39
@emelialei88 emelialei88 requested a review from dorjesinpo May 13, 2025 15:19
@emelialei88 emelialei88 requested a review from 678098 May 13, 2025 15:40
@emelialei88 emelialei88 force-pushed the feat-authn-protocol-mqb branch from f71824d to aa65195 Compare May 13, 2025 19:57
const AuthenticationContextSp& context)
{
// PRECONDITIONS
BSLS_ASSERT_SAFE(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fine to have preconditions, but they aren't preconditions if they're not documented in the function contract: The behavior of this function is undefined unless .... Otherwise, how would a caller of this function know it will crash if !context->d_initialConnectionContext_p->isIncoming() && !context->d_isReversed? We'd be lying to them.

Second concern: are these preconditions checked or enforced by the caller? I think they are, but the second one below has me worried. Is there any way we could get a bad message over the wire from a client and crash?

Copy link
Collaborator Author

@emelialei88 emelialei88 May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand the second concern.
isIncoming is set by us when TcpSessionFactory receives an incoming call (true) or sending an outbound message (false).
For negotiation, (and it should be the same for authentication),d_isReversed is default to be false unless we receive an reversed connection request (type bmqp_ctrlmsg::NegotiationMessage ::SELECTION_INDEX_REVERSE_CONNECTION_REQUEST) or we're about to send out a reverse connection request.

bmqp_ctrlmsg::AuthenticateRequest& authenticateRequest =
context->d_authenticationMessage.authenticateRequest();

BALL_LOG_DEBUG
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am a little concerned about logging arbitrary data that we get from the network, but I think the operator<< for authenticateRequest as generated is fine with this. This is another place where base64 may help compress the logs.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could get rid of printing the data, but sometime maybe we just want to debug and see what it is. Is setting it to debug mode still not okay?

Copy link
Collaborator

@dorjesinpo dorjesinpo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to at least document/comment how are we going to enforce authentication. Is AuthenticationContext going to have a state/status that someone (InitialConnectionHandler? ClientSession?) is going to check?

else if (event.isControlEvent()) {
const int rc = event.loadControlEvent(&negotiationMessage);
if (rc != 0) {
BALL_LOG_ERROR << "Invalid response from broker [reason: 'control "
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a response from broker (used to be negotiation message)?
And we do need to log/dump the blob

Copy link
Collaborator Author

@emelialei88 emelialei88 May 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And we do need to log/dump the blob

Is this a question? Do you mean we need to keep the error log of event or I should log even there's not an error?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And we do need to log/dump the blob

Is this a question? Do you mean we need to keep the error log of event or I should log even there's not an error?

I think, it would be helpful; to log/dump the blob when there is an error (rc != 0). Seems like we had this in the previous version of the code

@dorjesinpo dorjesinpo assigned emelialei88 and unassigned dorjesinpo May 16, 2025
@emelialei88 emelialei88 force-pushed the feat-authn-protocol-mqb branch 9 times, most recently from e1fe5b9 to d8123e8 Compare May 20, 2025 21:34
@emelialei88 emelialei88 force-pushed the feat-authn-protocol-mqb branch 2 times, most recently from 501f217 to 95f9480 Compare May 20, 2025 21:44
@emelialei88 emelialei88 force-pushed the feat-authn-protocol-mqb branch 3 times, most recently from ce8e150 to fa1fdd7 Compare May 22, 2025 18:15
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
@emelialei88 emelialei88 force-pushed the feat-authn-protocol-mqb branch from b20015d to 02917f1 Compare May 23, 2025 17:53
Copy link
Collaborator

@dorjesinpo dorjesinpo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good as is and we could merge it. but would be good to outline how we move forward

response.status().code() = 0;
response.lifetimeMs() = 10 * 60 * 1000;

authenticationContext->state().testAndSwap(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

checking return value would look good

} break; // BREAK
case bmqp_ctrlmsg::AuthenticationMessage::
SELECTION_ID_AUTHENTICATE_RESPONSE: {
rc = onAuthenticationResponse(errStream, authenticationMsg, context);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will there be a case when brokers receive AuthenticationResponse? If so, need a comment.

authenticationResponse,
authenticationContext);

return rc;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

making a note. when it becomes asynchronous, we need to

  1. handle authentication failure in the auth thread (how? by disconnecting the channel?)
  2. to make sure there is an authentication timeout and somebody enforces it

}

if (negotiationMsg.has_value()) {
// Authentication or Negotiation based on the type of message received.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need a check to reject negotiation message in between authentication request and authentication response.
Also a check to reject (another) authentication request in between authentication request and authentication response.
This could be checking InitialConnectionContext::d_authenticationCtxSp although explicit state would be better (we may need more checks or a mini FSM even)

State::e_AUTHENTICATING // state
);

context->setAuthenticationContext(authenticationContext);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What would we give to Client/Admin/ClusterNode session for future authorization(s) if Authenticator::handleAuthentication was never called? What's the plan? Can we document it?

@dorjesinpo dorjesinpo assigned emelialei88 and unassigned dorjesinpo May 26, 2025
Copy link
Collaborator

@pniedzielski pniedzielski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this is going in the integration branch, let's merge. We'll eventually make a PR into main with somethings from the integration branch, so it's not a big issue if this isn't fully fleshed out yet.

Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
@emelialei88 emelialei88 merged commit a401707 into bloomberg:integration/authn-authz May 29, 2025
33 checks passed
emelialei88 added a commit to emelialei88/blazingmq that referenced this pull request May 29, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jun 12, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jun 18, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jun 20, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jun 20, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit to emelialei88/blazingmq that referenced this pull request Jun 20, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jun 23, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jun 25, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit to emelialei88/blazingmq that referenced this pull request Jun 25, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jul 10, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jul 25, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jul 28, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Jul 30, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Aug 11, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Aug 15, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Aug 22, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Aug 29, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Sep 8, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Sep 11, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Sep 22, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Sep 23, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
emelialei88 added a commit that referenced this pull request Oct 3, 2025
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants