[Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release Coordination - Metrics
Drach, Bob
drach1 at llnl.gov
Wed Apr 20 14:43:05 MDT 2011
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
More information about the GO-ESSP-TECH
mailing list