Re: Use case not covered by the audit library?
Hello,
On Tuesday, December 15, 2015 05:13:14 AM Gulland, Scott A wrote:
I have a fairly common use case that I'm not sure is covered by
the audit
library and I need some advice on how best to handle it. I have a daemon
running as root that services REST API calls (or a web UI from a browser).
An external application first establishes a session by authenticating a
user which returns a token/session ID to the caller. All future REST API
calls, supplies the token/session ID which allows them authenticated access
to the requested resource. The token/session ID indicates what user the
request is associated with. Obviously, there can be many users
simultaneously issuing requests.
What I need to do is specify the user on each audit log call. For example,
I need to have a way to specify which user is issuing the request when I
call audit_log_user_message(). Is this possible? This is a very common
use case and really needs to be handled.
Would these users be able to interact with the system in any way they please?
If its not an interactive session, then I don't think its a _system_ event.
There are perfectly fine application logging frameworks to choose from. The
main issue is making sure that users cannot influence the records being written
about what they are doing.
But if you feel that you really would like to have this in the audit trail,
then you can use the AUDIT_TRUSTED_APP event type and format the event any way
that you wish. The audit tools sort of ignore those events because there's no
telling what's in them.
-Steve