Stream: hapi
Topic: automatic Audit logs
John Moehrke (Aug 30 2019 at 14:03):
Does the HAPI server auto generate AuditEvent records for all api access? Is this a configurable setting? also see my discussion on how this enables privacy Audit on #Security and Privacy
James Agnew (Sep 01 2019 at 21:57):
@John Moehrke - Not currently. I mean, certainly all of the framework is there for someone to be able to implement this kind of rule using our interceptors.. But there is nothing out of the box.
Would this be a useful thing to add? I could certainly see it being fairly easy to build at least..
Morten Ernebjerg (Sep 02 2019 at 07:53):
I reckon this would be a very nice feature to have out-of-the-box :+1:
John Moehrke (Sep 03 2019 at 12:16):
I, as a Privacy advocate and Security professional, think it is essential to have. It is available in a few other platforms, and is configurable with default off. The reason is that auditEntry will quickly overwhelm the total real data. Also there should be some purge rule, with a default purge rule of something like a nothing-older-than-a-year.
Jose Costa Teixeira (Sep 03 2019 at 13:29):
I, as a potential patient, also think this is important.
John Moehrke (Sep 03 2019 at 15:07):
Does the HAPI server auto generate AuditEvent records for all api access? Is this a configurable setting? also see my discussion on how this enables privacy Audit on #Security and Privacy
see this thread for further development and CR recommending it
James Agnew (Sep 03 2019 at 15:21):
Makes sense. Seems worth trying to implement.
@John Moehrke how would you foresee things like search results (and page loads for subsequent pages of search results) working? A single AuditEvent gets created with AuditEvent.entity references to each resource that appeared in the search results?
Also, WRT adding this to our public test server: are there any concerns with the fact that presumably we'd now be making it possible for someone to check which IPs had recently accessed the test server? How have other test servers addressed this? I guess I could mask the IP address..
John Moehrke (Sep 03 2019 at 15:25):
for search/query/operations that return many results, you do NOT duplicate the result in the AuditEvent. You record the query/operation parameters in an .entity, and another .entity holds the Patient. When the results include more than one patient's data, then multiple AuditEvent resources are recorded, one for each patient.
James Agnew (Sep 03 2019 at 15:30):
Ahhh interesting. I guess in my mind I've always seen AuditEvent as a complete record of "who has seen what" but that makes a lot of sense for it to be fully centred around the more specific question of "who has seen which patients" at least as a default use case.
John Moehrke (Sep 03 2019 at 15:32):
I guess this behavior on query/search/operations did not get mentioned on the AuditEvent page. I guess that should be another CR?
John Moehrke (Sep 15 2019 at 01:55):
@James Agnew did you happen to get audit logging into your server? I have a patient app for notifying a patient when activity on their subject based on AuditEvent activity. Just wondering if you implemented this in an experimental way, or in a way that is not turned on in your sandbox servers
James Agnew (Sep 15 2019 at 02:04):
@John Moehrke not yet- will try to do this in the AM. would be fun to test while you're around the connectathon
John Moehrke (Sep 15 2019 at 02:08):
Im around all week...
Virendra Shinde (Jul 26 2020 at 13:44):
Did either of you went ahead and implemented the AuditEvent in HAPI ?
Jens Villadsen (Jul 26 2020 at 13:50):
@James Agnew if you are interested, we actually have done this
Jens Villadsen (Jul 26 2020 at 13:51):
In HAPI
Jens Villadsen (Jul 26 2020 at 13:51):
With it being patient centric
Jens Villadsen (Jul 26 2020 at 13:59):
@John Moehrke
John Moehrke (Jul 26 2020 at 14:01):
+1
Keerthivasan Ramanathan (Jul 29 2020 at 16:06):
@Jens Villadsen I'm curious to know how did you achieve it. Can you help?
Jens Villadsen (Jul 29 2020 at 22:19):
We ended up implementing an interceptor invoked on the pointcuts for SERVER_OUTGOING_RESPONSE, STORAGE_PRECOMMIT_RESOURCE_CREATED, STORAGE_PRECOMMIT_RESOURCE_UPDATED, STORAGE_PRECOMMIT_RESOURCE_DELETED and SERVER_INCOMING_REQUEST_PRE_HANDLED. Be cautious about when you actually generate the auditevent as the point cuts are hit by multiple threads pr request, which means you must delay invocation of the actual generation of auditevent until you get a call to the pointcut SERVER_PROCESSING_COMPLETED from the main thread of the request again. We successfully got it to work as intended over XA meaning that our auditevents are put on a queue for async processing iff data is to be returned to a user
Keerthivasan Ramanathan (Jul 30 2020 at 07:20):
Thanks @Jens Villadsen this is really helpful. i would further investigate it. For us, its mostly READ operations for now. I think pointcuts for SERVER_INCOMING_REQUEST_PRE_HANDLED and SERVER_OUTGOING_RESPONSE should be helpful. Is there any way we can map the request with a response sharing the same AuditEvent resource or something like that? we also need to parse the request headers. Any suggestions will be appreciated. Thanks so much
Jens Villadsen (Jul 30 2020 at 07:38):
That is what you need to do by eg. storing the request in the servletRequestDetails so that you can retrieve later on in the SERVER_PROCESSING_COMPLETED pointcut. Be aware that if you intend to produce this on READ, then you also should produce it on SEARCH at least.
Keerthivasan Ramanathan (Jul 31 2020 at 05:05):
Sure, @Jens Villadsen We will have to do for search as well. Where do you suggest that we store the request. Do you have any recommendations? Do you think that we should maintain in a map or something in the application layer?
Thanks for your time and support.
Jens Villadsen (Jul 31 2020 at 07:56):
you have the request in the ServletRequestDetails so you can access the contents there
Keerthivasan Ramanathan (Jul 31 2020 at 08:04):
oh, I got it. Thanks.. Sorry, I missed it.
Last updated: Apr 12 2022 at 19:14 UTC
