________________________________________
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

Reply via email to