[Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release Coordination - Metrics

[Drach, Bob]

Thanks, Phil. That's exactly what we need.

--Bob


On 4/20/11 6:54 AM, "philip.kershaw at stfc.ac.uk" <philip.kershaw at stfc.ac.uk>
wrote:

> Hi all,
> 
> My understanding from the call was that we would go with an SSL based solution
> securing the metrics endpoint.   This was because the alternative would mean a
> lot of re-engineering in the Gateway code base.
> 
> Gavin, I think what you're proposing now is to include the domain name of the
> user's OpenID in its un-hashed form.  The question then would be, does this
> still involve a lot of re-working of code on the Gateway side?
> 
> I found this post on setting up SSL with mutual authentication and filtering
> by certificate subject name:
> 
> http://twoguysarguing.wordpress.com/2009/11/03/mutual-authentication-with-clie
> nt-cert-tomcat-6-and-httpclient/
> 
> Yes, note the jaded opening remarks :) but if it's a recipe that can be
> followed by someone who's been there and done it already it should be OK.
> Doing this with Apache is much more straightforward via the SSLRequire
> directive.
> 
> Regardless of what happens with the metrics service it would be good to know
> how to do this for rolling out whitelisting of Attribute and Authorisation
> Services.   The sooner the better especially for the former service because
> without it we expose user's e-mail addresses to anyone curious enough to find
> out how to get them.
> 
> Cheers,
> Phil
> 
> From: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov>>
> Reply-To: "Gavin M. Bell" <gavin at llnl.gov<mailto:gavin at llnl.gov>>
> Date: Tue, 19 Apr 2011 15:10:09 -0700
> To: Eric Nienhouse <ejn at ucar.edu<mailto:ejn at ucar.edu>>
> Cc: "go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>"
> <go-essp-tech at ucar.edu<mailto:go-essp-tech at ucar.edu>>,
> <esgf-mechanic at lists.llnl.gov<mailto:esgf-mechanic at lists.llnl.gov>>
> Subject: Re: [Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release Coordination -
> Metrics
> 
> Hi Eric
> 
> (comments below)
> 
> On 4/19/11 1:46 PM, Eric Nienhouse wrote:
> 
> Hi All,
> 
> We discussed the Data Node metrics access logging service in our GO-ESSP
> call today.  This is a key integration point between Gateways and Data
> Nodes and is a high priority feature for the 1.3.0 release.
> 
> Following is a summary of our conclusions.  Please note anything that
> may be incorrect or unclear.
> 
> 1)  The Data Node metrics access logging service should be secured via SSL.2)
> Gateway access to the metrics service should require (GW client)
> authentication.
> 3)  Email address should not be included in the metrics records exchanged.
> 
> 
> nod
> 
> 4)  There are a number of use cases which imply tracking user OpenID's
> at the GW and DN.
> 
> 
> 
> I sill think that the openid's should be obfuscated.  The one bit of
> information in the openid that will be in a different field will be the
> hostname value of the user's openid i.e. their IDP.  With that bit of
> information there will be everything that one would need in a metrics context.
> Thus you would be able to answer the metrics question: How many people
> accessing Y data have accounts on X? X being the IDP of an organization.
> 
> I share Bob's and Philip's concern about data exposure.  In the scenario
> above, the  openid of person Z can still be positively gotten by asking idp X,
> 'hey who is Z?', but this is not the general case.  This also follows the
> basic pattern that we employ for email addresses which we all agree should not
> be passed around on the wire, regardless of transfer mechanism.  The pattern
> for email is that we have to run a special resolution service in order to
> perform the lookup, because that information is not made directly available.
> 
> So, the returned metrics would not have the openid but have two bits of
> information:
> 1 - the openid / userid hash
> 2 - the hostname of the IDP for whom the openid is in custody.
> 
> I think this should be sufficient to provide reasonable privacy regardless of
> using secured ssl or not.
> I cannot see a use case in the context of metrics that require any additional
> information.
> Do you concur?
> 
> We discussed providing examples or best practices for securing the
> metrics service.  (Ideally for a Non-Spring  Tomcat environment.)
> (Phil, Luca, Nate?)
> 
> We noted the Gateway 1.3.0 RC1 release is waiting on finalizing the
> metrics service interface and security configuration.  We need to
> identify the time-line for accomplishing securing the metrics service.
> (Gavin?)
> 
> For further background, the ESG Metrics Use Cases can be found below.
> These Use Cases support our conclusions above.
> 
>   https://wiki.ucar.edu/display/esgcet/Metrics
> 
> I appreciate all the input today.
> 
> Thanks,
> 
> -Eric
> 
> 
> _______________________________________________
> GO-ESSP-TECH mailing list
> GO-ESSP-TECH at ucar.edu<mailto:GO-ESSP-TECH at ucar.edu>http://mailman.ucar.edu/mai
> lman/listinfo/go-essp-tech
> 
> 
> --
> Gavin M. Bell
> Lawrence Livermore National Labs
> --
> 
>  "Never mistake a clear view for a short distance."
>                -Paul Saffo
> 
> (GPG Key - http://rainbow.llnl.gov/dist/keys/gavin.asc)
> 
>  A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E