On Sun, Feb 9, 2014 at 11:06 AM, Pritchard, Charles X. -ND < charles.x.pritchard....@disney.com> wrote:
> > ________________________________________ > From: Mike Percy [mpe...@apache.org] > Sent: Friday, February 07, 2014 8:12 PM > To: user@flume.apache.org > Subject: Re: Adding SSL peer cert info to AvroSource > > On Fri, Feb 7, 2014 at 6:50 PM, Pritchard, Charles X. -ND < > charles.x.pritchard....@disney.com<mailto: > charles.x.pritchard....@disney.com>> wrote: > >> I'd like to be able to use the client CN in subsequent > configuration/routing parameters. > >> The bulk of the Flume config (e.g. selectors, sinks) works with event > headers. > > > Does it need to be the client CN? Can it be the client hostname? If so, > why not just add that info to the event on the client side or with a > hostname interceptor on the previous hop? > > Isn't the hostname interceptor for the server hostname? Some form of data > needs to be validated from the SSL cert; > that's the purpose -- giving the client an SSL cert signed by the server > which verifies that a particular field is trusted. In this case, the client > CN is trusted. > > >> At the point the event is submitted, we've confirmed that the cert is > valid and we can add a timestamp [if really really needed] via interceptor. > >> This is meant to be client-facing -- that is, the client is connecting > to AvroSource using an SSL cert. > > > I don't think I fully understand why you're doing it this way, but I > guess you're saying you want to mark the event as having been accepted from > a validated source, and you want to identify that source. > > Another way to do this is to have the client mark his event with some > source header, and have an interceptor that marks that the event made it > through the source with some tag. Do you think that would be sufficient? > > Provided that the interceptor has the information it needs [the info being > the data from the SSL cert gleaned in the first step]. > > > I see what you're saying about the responder though... because it's an > Avro thing, you might have to modify Avro code to get to the SSL context. > Might be tricky. I haven't spent a lot of time on this but maybe you could > write a responder that hands off the request to the avro responder after > doing whatever it needs to do. I see what you're saying though, because of > the way the Avro proxy stuff works, it goes through a bunch of funky > reflection, etc. That makes it hard to get back out once you go in, if you > know what I'm saying. > > Yeah, I'm getting the impression that I'll have to step in front or behind > the Avro responder, somewhere there. Reflection sometimes gets tricky -- > hall of mirrors effect? > Well basically you would have to work at Avro-Netty level. My knowledge is a bit rusty at the moment, but SSL end at the 1st layer in the channel pipeline, so you may need to hack Avro's usage of Netty to get this working, passing the required information from SSL layer to codecs higher in the chain. I am a bit tied up for new few weeks, but ready to hack in after that. HTH! > > I appreciate you taking the time to talk through this with me. > > -Charles -- thanks ashish Blog: http://www.ashishpaliwal.com/blog My Photo Galleries: http://www.pbase.com/ashishpaliwal
