KDC Audit project

[Benjamin Kaduk]

On Mon, 7 Jan 2013, Dmitri Pal wrote:

> On 01/07/2013 02:25 PM, Zhanna Tsitkov wrote:
>>
>> On Jan 7, 2013, at 2:02 PM, Dmitri Pal wrote:
>>
>>> There should be recognized and known keys like: type of the event
>>> (example KDC start/stop) and may be subtype (start or stop), timestamp,
>>> principal operation is performed with etc.
>>>
>>> It will be up to the plugin to decide what to do with the data.

With one-interface-per-event, the plugin knows exactly what it has to do 
with the data, there is no room for ambiguity and no need to attempt a 
possibly-incorrect "best effort" treatment of unknown data.

>>> Such approach would allow evolving the interface and adding more data to
>>> the events over time without breaking the existing plugins.
>>> Approach listed on the page would make it very hard to evolve the
>>> interface on both sides, we effectively create a "one shot do it right"
>>> which is always hard to accomplish.

The structure of the plugin interface is such that an existing plugin can 
continue to do what it originally did, even if new events/interfaces are 
added.  If a plugin does not supply a handler for an event, it just does 
not handle that event.

>>> A generic interface is a bit more work but existing libraries help to
>>> reduce the cost of development.

My sense is that the generic interface would put a heavy burden on the 
plugin module author to make an attempt to cover "all possible cases".
Are you saying that it would be more work for us the framework author and 
less work for the plugin module author?

>> As a matter of fact we have discussed exactly this approach inside the
>> group.  However,  it was suggested that too generalized API is not a
>> good idea because of possible confusion while debugging and/or
>> collecting information to be reported.  Hence, one-api-per-event
>> approach.
>> We will definitely revisit this topic. Thanks for the comment!
>
> It depends on the helpers you provide.
> If you use JSON it is easy to print and visualize so it might be the
> best of all approach.

I had the impression that audit tracing was intended to be more structured 
than just a simple logfile, so I am not sure that the ease of printing and 
visualization is the most relevant feature.  If audit records are to be 
treated as more of a database to be queried than a static logfile, then 
having very structured data is useful.  Of course, structured data can be 
encoded/serialized in JSON or other ways, but the benefit of serializing 
structured data just to decode it again is not clear.