Skip to content
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

ARTEMIS-4210 audit connection creation & destruction #4408

Merged
merged 1 commit into from
Mar 28, 2023

Conversation

jbertram
Copy link
Contributor

No description provided.

@@ -2639,4 +2644,18 @@ static void isAutoDelete(Object source) {

@LogMessage(id = 601766, value = "User {} is getting auto-delete property on target resource: {}", level = LogMessage.Level.INFO)
void isAutoDelete(String user, Object source);

static void createdConnection(String protocol, Object connectionID, String remoteAddress) {
CONNECTION_LOGGER.createdConnection(protocol, connectionID.toString(), String.format("unknown%s", formatRemoteAddress(remoteAddress)));
Copy link

Choose a reason for hiding this comment

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

Why does the user value always start with 'unknown'?
If there is no way to find the user here, maybe we could review the
@LogMessage(id = 601767, value = "{} connection {} for user {} created", level = LogMessage.Level.INFO) void createdConnection(String protocol, String connectionID, String user);
log template, replacing the 'user' info with some other field... what do you think?

Copy link
Contributor Author

@jbertram jbertram Mar 22, 2023

Choose a reason for hiding this comment

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

At the point where this is logged the user isn't actually known yet since that data hasn't been parsed. We definitely don't want to add any additional parsing here as this is on the hot path for every connection. However, I left the user information in the log for 2 main reasons:

  • To show the IP address
  • To be consistent with the rest of the audit logging

The connection ID is also logged here as well as in the authentication message so these audit messages can be correlated.

@@ -2639,4 +2644,18 @@ static void isAutoDelete(Object source) {

@LogMessage(id = 601766, value = "User {} is getting auto-delete property on target resource: {}", level = LogMessage.Level.INFO)
void isAutoDelete(String user, Object source);

static void createdConnection(String protocol, Object connectionID, String remoteAddress) {
Copy link

Choose a reason for hiding this comment

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

Why is the 'connectionID' an Object, while in other methods it is a String?
If it is possible, it would be better to manage it in the same way, and having a String seems to me a cleaner way.
Furthermore, managing it as an Object could bring to unexpected NPE, in case it is null, once the 'toString' method will be invoked.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The difference is to disambiguate the two createdConnection methods from each other otherwise the code wouldn't even compile. Also, while there is a technical risk of NPE there is no practical risk because if the connection ID is null the code will fail before it even gets to the audit logging.

@@ -380,7 +380,7 @@ private void authenticationFailed(String user, RemotingConnection connection) th
ActiveMQServerLogger.LOGGER.securityProblemWhileAuthenticating(e.getMessage());

if (AuditLogger.isResourceLoggingEnabled()) {
AuditLogger.userFailedAuthenticationInAudit(null, e.getMessage());
AuditLogger.userFailedAuthenticationInAudit(null, e.getMessage(), connection.getID().toString());
Copy link

Choose a reason for hiding this comment

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

I have a doubt here: why is the user (first parameter) always null? Is there no way to find it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

That's a fair question, but it's not really germane to this PR since it hasn't been changed. I recommend you follow-up on the ActiveMQ users list about this.

@jbertram jbertram merged commit d2e5ddf into apache:main Mar 28, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
2 participants