[
https://issues.apache.org/jira/browse/SOLR-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575361#comment-16575361
]
Jan Høydahl commented on SOLR-12120:
------------------------------------
I'll continue with this issue soon. Any comments on what's done so far is
welcome.
The way it is now, AuditEvents are fired from various places, such as after
successful authentication, after successful authorization etc. But I wonder if
there would be a way to "stack up" all events happening in the same user
request, and then only log the request once, i.e. if the request ends up with
creating a new collection, then we could log an AuditEvent
{noformat}
type=ADMIN, method=POST, action=CREATE_COLLECTION, status=SUCCESS,
user=johndoe{noformat}
and not log all the intermediate events such as AUTHENTICATED, AUTHORIZED,
since that is implied with a successful action. And how to handle async
operations with collection API? Should we log one two events, first ordered,
and then let the Audit framework poll for status and log another event with
status either SUCCESS or FAILED::
{noformat}
type=ADMIN, method=POST, action=CREATE_COLLECTION, status=ORDERED, user=johndoe
type=ADMIN, method=POST, action=CREATE_COLLECTION, status=SUCCESS,
user=johndoe{noformat}
Also, there are several constructors in the AuditEvent class now, different
ones called depending on what context is available (post-authentication with
httpRequest, post-authorization with AuthorizationContext etc). Would it be
better to borrow the principle from
[MDC|https://www.baeldung.com/mdc-in-log4j-2-logback] and add info to the
thread as we go along, and only ever call
{{AuditLoggerPlugin#audit(AuditEvent)}} when we know that the request is
finished, either because we return data to user or due to some error. How would
that look like and how can we be sure that the request is audited also when
terminated due to exception, timeout etc?
> New plugin type AuditLoggerPlugin
> ---------------------------------
>
> Key: SOLR-12120
> URL: https://issues.apache.org/jira/browse/SOLR-12120
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Components: security
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Solr needs a well defined plugin point to implement audit logging
> functionality, which is independent from whatever {{AuthenticationPlugin}} or
> {{AuthorizationPlugin}} are in use at the time.
> It seems reasonable to introduce a new plugin type {{AuditLoggerPlugin}}. It
> could be configured in solr.xml or it could be a third type of plugin defined
> in {{security.json}}, i.e.
> {code:java}
> {
> "authentication" : { "class" : ... },
> "authorization" : { "class" : ... },
> "auditlogging" : { "class" : "x.y.MyAuditLogger", ... }
> }
> {code}
> We could then instrument SolrDispatchFilter to the audit plugin with an
> AuditEvent at important points such as successful authentication:
> {code:java}
> auditLoggerPlugin.audit(new SolrAuditEvent(EventType.AUTHENTICATED,
> request));
> {code}
> We will mark the impl as {{@lucene.experimental}} in the first release to
> let it settle as people write their own plugin implementations.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
