________________________________________ 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? I appreciate you taking the time to talk through this with me. -Charles