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

[Gavin M. Bell]

 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
> http://mailman.ucar.edu/mailman/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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/go-essp-tech/attachments/20110419/ede9eb59/attachment.html