[Freeipa-devel] Re-send

[Dmitri Pal]

Hello Aldo,

We need contributions in many areas. Thanks for asking!
We am actively working on the design pages.
They will be put on the freeIPA site for review and comments.
We will be publishing them throughout September.
This would be a great opportunity for anyone to get involved more closely.
As pages published the announcements will be sent and we will start 
coordination of the task execution between contributers.

Thank you for your interest in freeIPA!
Dmitri Pal


Aldo Pietropaolo wrote:
> Hello John,
>
> I completely agree with your assessment. There would be some sort of 
> authentication protocol between sender and receiver for both the 
> client monitor / IPA and any third party receiver. Now there would 
> also be some hashing mechanism or CRC to ensure that the message sent 
> was intact. The other ideas that I have tested are client caching 
> mechanisms to ensure the message gets sent in case of receiver 
> failure. Although PKI might be a natural choice to provide keys for 
> data encryption and confidentiality, there might be other options to 
> make it less complicated to deploy and administer. There is of course 
> an option to also include some sort of key server to rotate any 
> symmetric keys used for clients and servers. Now the topic of kernel 
> audit ability is an interesting topic I have not thought about before 
> which is very interesting and necessary. It would be a very exciting 
> to see this added to IPA. In any case, what areas do you need 
> contribution in?
>
> Thank you for your feedback!
>
> Aldo Pietropaolo
>
> On 8/25/08 7:44 AM, "John Dennis" <jdennis at redhat.com> wrote:
>
>     Aldo Pietropaolo wrote:
>
>         Re-send 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.
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
Dmitri Pal
Engineering Manager
Red Hat Inc.