> On Nov 19, 2015, at 12:08 PM, Emmanuel Lécharny <[email protected]> wrote: > > The journal currently only log updates (ie, not the Binds, Searches, > Compares). It can be imrpoved easily. Storing teh permissions is another > story : what exactly do you want to store ?
The requirement is to track for audit all invocations into the fortress core APIs. The apacheds journal will work well for the admin apis I think. But we also need a way to track the policy enforcement apis also (accessMgr). For example createSession (may do an ldapbind), and checkAccess (always performs an ldapsearch). The slapo access log tracks binds and mods quite well. It has option to log ldapsearch, but as you might imagine this is too granular and is too much overhead. So fortress core does a ‘trick’ on the checkaccess call. After the call to ldapsearch (to pull back the permission) it calls ldapcompare which tricks the slapo access log into storing the result. Since ldapcompare is not performed as much as ldapsearch this works ok with openldap cases. At a minimum we need userid, timestamp, object name, object id, operation name, and result for calls into checkAccess. We need similar capability for createSession. Note: For accessmgr calls using the openldap accelerator the audit is done directly from inside the slapo-rbac overlay. This is better and more efficient and negates the need for enabling slapo-access log for binds and searches. (another reason for using accelerator I suppose) Shawn
