User authentication logging

adp · June 8, 2020, 1:26pm

I am using sonarqube 7.9.x (on prem/DC edition) and am looking to enable logging of which users are accessing and doing what tasks.

I’ve discovered that enabling DEBUG for the web server causes these details to be produced which is great but I don’t really want full debug logs. Is there a way to enable specific log messages (such as auth.event) should be sent to the log or even to a seperate log file.

I’m probably missing something as this must be a feature that exists if I can just find the relevant docs.

Thanks

-Andrew

OlivierK · June 8, 2020, 1:38pm

Hello @adp

I am curious about what is your source of information about logging of user activity ? I don’t think that there is any way of being able to audit everything.
The best way to audit activity is to look at the contents of the <SONARQUBE_HOME>/logs/access.*.log files and you don’t need to enable DEBUG level to get this information. Each API call is logged there (but without all the parameters).

Note: In order to have the richest (but not absolutely exhaustive) audit logs in access.*.log I recommend to set in sonar.properties:

sonar.web.accessLogs.pattern=%h %l %u [%t] "%r" %s %b "%i{Referer}" "%i{User-Agent}" "%reqAttribute{ID}" "%reqAttribute{LOGIN}"

The log format configuration is according to logback syntax.

Olivier

adp · June 8, 2020, 1:48pm

Hi Olivier,

That looks like an improvment to the log formatting in the access.log (I’ll look at that now!)

I really want to be able to get the auth details too (such as login sucess/fail)

Thanks,

-A

OlivierK · June 8, 2020, 2:17pm

Hello,

OK I see. That DEBUG logging shows you the details of the user authentication, but nothing else (ie once logged in, you would not be able to audit what the users do). That’s possibly the key audit trail you want to follow. In that case there is no better solution than activating DEBUG logs.
From the sonar.properties file you can be a bit more selective than in the UI and you actually only need DEBUG logs for the Web process. See below properties to separately set different log levels for the different SonarQube pieces:

sonar.log.level.app=INFO
sonar.log.level.web=DEBUG
sonar.log.level.ce=INFO
sonar.log.level.es=INFO

That’s all I can propose.

Olivier

adp · June 9, 2020, 10:42am

Hey Olivier,

Thanks - that’s what I’ve got inplace on my dev instance but it does produce a bunch more data than I want (and the system info page suggests making the system not run slowly by having debug enabled)

I guess I’ll have a look to see if it’s a simple update… It’s been ages since I’ve tried to do any java development…

Thanks for your help.

-A

cheper · June 19, 2020, 10:23am

Hello @OlivierK !
Can you link all attributes, that i can put in “reqAttribute”? I cant find any information about it anywhere.
Regadring the same problem OP have, i found that most of useful audit information you can get from “requestContent” argument in access log pattern, but unfortunatly it shows user password in log. If there was any way to hide it it would be perfect without any need of DEBUG level.

OlivierK · June 19, 2020, 1:08pm

Hello @cheper,

Unfortunately I don’t have the list of possible reqAttribute. I guess this is an HTTP request concept, abstracted in Java and that can be anything (even though there are some standard attributes).
I quickly searched for java request.getAttribute but did not find anything super clear.
This page seems one of the most interesting, without any guarantees…

And indeed adding %requestContent in the log formatting string is nice since it displays all parameters of a POST … but it also shows user password during authentication requests

Olivier

coofercat · August 30, 2022, 11:07am

I just found this looking for the same thing. It seems that Sonarqube doesn’t log auth.event lines, unless it’s in DEBUG, which it nags you to change back because of potential performance issues.

I’ve got to say, this looks pretty bad. Saying “xyz logged in successfully” and “failed login for xyz” are really pretty basic things, and clearly within the functionality of the software. They’re just buried in DEBUG when they should be INFO. I see the Enterprise tier has some audit capabilities too.

Is this a bug? Or possibly a feature request?