-
Notifications
You must be signed in to change notification settings - Fork 153
Feat[MQB]: add authentication with basic logic #746
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feat[MQB]: add authentication with basic logic #746
Conversation
f71824d
to
aa65195
Compare
const AuthenticationContextSp& context) | ||
{ | ||
// PRECONDITIONS | ||
BSLS_ASSERT_SAFE( |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this 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 " |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
e1fe5b9
to
d8123e8
Compare
501f217
to
95f9480
Compare
ce8e150
to
fa1fdd7
Compare
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
b20015d
to
02917f1
Compare
There was a problem hiding this 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( |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
- handle authentication failure in the auth thread (how? by disconnecting the channel?)
- 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. |
There was a problem hiding this comment.
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); |
There was a problem hiding this comment.
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?
There was a problem hiding this 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>
a401707
into
bloomberg:integration/authn-authz
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Signed-off-by: Emelia Lei <wlei29@bloomberg.net>
Handing authentication logic on the broker side:
AuthenticationEvent
event type.AuthenticationContext
to encapsulate relevant context data.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 bybascodegen
.