[jira] [Comment Edited] (SOLR-12120) New plugin type AuditLoggerPlugin

["Hrishikesh Gadre (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-12120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16411877#comment-16411877 ] 

Hrishikesh Gadre edited comment on SOLR-12120 at 3/23/18 6:44 PM:
------------------------------------------------------------------

[~janhoy] Thanks for this great feature!
{quote}can you have a look and consider whether your Audit logger plugin would be possible to realise with this API?
{quote}
I took a cursory look and we should be integrate this with the Sentry authorization framework. I will do a more thorough review next couple of days and will let you know. 

 
{quote}I made it asynchronous so you can call {{auditLoggerPlugin.auditAsync(event);}} and continue the request immediately, while the audit framework processes the events on queue with a background thread. Very simple but powerful concept.
{quote}
While I get the value of async processing, I am not sure why the audit logging plugin needs to expose this concept. This can be implemented inside the concrete implementation of AuditLoggerPlugin (e.g. log4j does support [async appender|https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/AsyncAppender.html]). My concern is that HttpSolrCall.java is using this method directly. This makes async behavior mandatory for all (?) audit logging implementations. What do you think?

 


was (Author: hgadre):
[~janhoy] Thanks for this great feature!
{quote}can you have a look and consider whether your Audit logger plugin would be possible to realise with this API?
{quote}
I took a cursory look and we should be integrate this with the Sentry authorization framework. I will do a more thorough review next couple of days and will let you know. 

 
{quote}I made it asynchronous so you can call {{auditLoggerPlugin.auditAsync(event);}} and continue the request immediately, while the audit framework processes the events on queue with a background thread. Very simple but powerful concept.
{quote}
While I get the value of async processing, I am not sure why the audit logging plugin needs to expose this concept. This can be implemented inside the concrete implementation of AuditLoggerPlugin (e.g. log4j does support [async appender|https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/AsyncAppender.html]). My concern is that HttpSolrCall.java is using this method directly. This makes async behavior is mandatory for all (?) audit logging implementations. What do you think?

 

> 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: 1h 10m
>  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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org