[Freeipa-devel] "Commit comments log" functionality in IPA

[Dmitri Pal]

Hello,

One of the ideas that we are exploring for IPA v2 is to have sort of 
“commit comment” feature. The examples of the use cases are:
* Administrator changed and pushed out the policy. As he saves it or 
applies it (pushes it) he will be prompted to make a comment mainly 
describing why the operation was performed.
* Administrator changed mapping of the users and hosts to a role. He is 
prompted to make a comment about the operation he performed.
* Administrator changed host based access control rule. Same thing as 
above.

These are just several examples of where the commenting on the operation 
performed might be very important for audit purposes.
The main differentiator between the logging of different activity and 
such feature is that it allows administrator to leave some tips, reasons 
and answers to questions “why this or that operation was performed and 
why it was done this way”. We believe that having such functionality 
would be very valuable for IPA customers.

Bugzilla bug has a very similar functionality. It records not only 
comments themselves, but who left the comment and when. It also allows 
modifying comments later on. I have seen the implementations where the 
comments can't be modified but just added.

In our case we would have to implement some similar functionality but in 
DS. That pauses a challenge.
Here are some ideas that I wanted to run by you:

   1. I do not think that it would be a good idea to keep the comments
      separately from the entries being modified. It can be done but I
      think it would be a database approach to solving the problem, not
      a DS one. So I suggest that attributes that would be involved in
      storing this information would be stored in the same entry that
      gets modified.
   2. If it is the same entry but there might be different kinds of
      entries the attributes that would store comments would be combined
      into an auxiliary object class. This way we would be able to do
      comments on any kind of entry we want. It can be role mapping,
      access control rule, policy or something else we do not have in
      the system yet.
   3. One of the important aspects of such commit log is that it should
      be ordered can be easily orderable. It is known that multi value
      attributes can't be ordered. So we have several options:
         1. Use one structured attribute and stick everything into it.
            Though it solves the problem of sorting it makes replication
            less efficient. One and the same data will be replicated
            over and over again.
         2. Use dynamic number of attributes – one attribute for a
            comment. I do not know if it is possible but even sounds
            like a bad practice even if possible.
         3. Use a multi value attribute. If we have a header at the
            beginning of the mv-attribute that would have a time stamp
            and sequence number or both, then we would be able to easily
            sort the attribute values and present them in the right
            order. We would also minimize replication burden and have a
            pretty easy reporting mechanism

   4. So based on analyses above the MV approach seems like a good
      starting point. Ok now it makes sense to enforce same behavior
      related to this attribute(s) regardless whether one uses
      management interface (UI/CLI) or direct LDAP calls. This means
      that all the logic related to our commit log object class should
      be handled via DS plugin.
   5. Let us list the operations that the DS should support against the
      attribute(s) that would store the commit log data:

Add: Add a new comment to the end of the list (low level privilege 
operation)
Modify: Change comment in the list (high level privilege operation)
Delete: Comment from the list (high level privilege operation)
List: Return all entries sorted the order they have been added. (low 
level privilege operation)
Get: Get specific item from the list by some sort of identifier – needed 
to be able to modify/replace the right comment. (low level privilege 
operation)
If we do not allow modification of the list then we do not need 
“modify”, “delete” and “get” operations. Is this acceptable? Then it 
would be much simpler to create a DS plugin that will just respond to 
add, and search requests and would reject attempts to delete or modify 
value. One would be able to delete the whole entry though.

   6. The value would be structured like this:
         1. sequence number (integer as string left zero padded to 10
            characters)
         2. length of user CN as left zero padded 4 digit string
         3. user CN of the user who created a comment
         4. time stamp of creation in YYYYMMDDHHMMSS in UTC
         5. time stamp of last modification in YYYYMMDDHHMMSS in UTC
         6. comment itself
      Since the size of the items is fixed or can be easily determined
      we do not need any separators thus there is no need to escape
      anything in data itself.
   7. To be able to efficiently maintain the list we would need another
      attribute. This attribute will contain a current max sequence
      number. That attribute would be updated each time a new comment is
      added to the list. The plugin will control access to it and
      prevent any direct modification of this attribute.
   8. In future is we decide to change the format we would be able to
      add other attributes that would contain a version or a format
      specifier. The logic of the plugin would then be changed to check
      those attributes and if they are not present it will fall back to
      original (this format). So I do not see a need to add any format
      or version attribute in the first implementation.
   9. The ldap search will return all the values of the mv-attribute
      already sorted. It would be a responsibility of the caller to
      parse parts of it out and present the information to the user in a
      usable format.

Any ideas or comments or suggestions are appreciated.

Thank you
Dmitri