[Freeipa-devel] Re-send

John Dennis jdennis at redhat.com
Mon Aug 25 12:44:31 UTC 2008


Aldo Pietropaolo wrote:
> I apologize for the re-send but the .pptx file might be corrupt so I 
> attached a pdf. Below are some notes I had in the second slide.
>
> "The idea is to provide a stand alone freeIPA identity monitor that 
> listens to real time event information performed in the directory 
> service such as adds, modifications, deletes, password expiry, etc. 
> These events would then be sent to freeIPA server and be processed by 
> freeIPA Audit extensions in slide 1. Client side plugins may also be 
> written to handle message normalization of event data and to send 
> event to multiple event consumers if desired.
>
>
> ClientMonitor will register for identity events and receive the events 
> asynchronously from the directory server. Call back interface may 
> normalize the data with default schema and send to freeIPA Server for 
> processing. Client monitor may also instantiate an audit plugin for 
> additional processing."
This is an interesting idea. I would imagine the functionality could be 
provided by some sort of "trigger" which could be registered with IPA. 
When a matching event is seen then an action is taken.  Directory server 
is one of the applications which we anticipate would be IPA audit aware 
and would use the IPA audit API. However, as I alluded to earlier we are 
not currently designing a real time monitoring system, although that may 
very well be a follow-on feature. One of my initial concerns with audit 
triggers distributing audit information to a listener is the security 
implications. It is vital audit data does not escape, if audit data were 
to be re-transmitted to a third party there would have to be a robust 
mechanism to assure the authenticity of the receiver and a centralized 
mechanism to shut the stream down. It is very hard to verify audit data 
sent to a third party will not escape from the 3rd party even if it's 
identity is verified. So while the idea of registering to receive audit 
events via a trigger has a lot of appeal in some scenarios I also 
imagine such a feature would be globally defeated by many organizations 
because it might violate enterprise security policy. These are some of 
the issues which would have to be solved.

-- 
John Dennis <jdennis at redhat.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20080825/9417d671/attachment.htm>


More information about the Freeipa-devel mailing list