[Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release Coordination - Metrics
Gavin M. Bell
gavin at llnl.gov
Wed Apr 20 11:15:54 MDT 2011
oops... s/rouge/rogue/g
(so embarrassing)
On 4/20/11 10:04 AM, Gavin M. Bell wrote:
> Hi...
>
> On 4/20/11 8:13 AM, Don Middleton wrote:
>> Hi all - I thought we had group consensus yesterday on the path
>> forward. Also, going back to Eric's post - we worked on this as a
>> group quite a bit back in 2009, and from the wiki:
>>>
>>>
>>> Basic Course of Events
>>>
>>> * The ESG Gateway authenticates with a Datanode.
>>> * The ESG Gateway requests metrics data from the Datanode for a
>>> specific time range.
>>> * The Datanode retrieves the metrics data for the specific time
>>> range.
>>> * The Datanode returns the metric data to the ESG Gateway
>>> * The ESG Gateway persists the returned metric data to its Database.
>>>
>> One of the hard requirements that drove this was the ability to
>> detect unwanted user behavior, know who that is, disable them, and
>> possibly take other action.
>>
>> cheers - don
>>
> You can still do this... The only difference is that you won't be able
> to directly see that the rouge is say, "donmiddleton" you'll know the
> rouge as "da39a3ee5e6b4b0d3255bfef95601890afd80709". If you need to
> know exactly that that value resolves to "donmiddleton" you will know
> who to contact, da39a3ee5e6b4b0d3255bfef95601890afd80709's IDP (in the
> esg case, the gateway), which is provided in the metrics report. This
> is exactly the usage scenario as we do with email addresses. There is
> no real difference with what the String is that identifies the user as
> far as any of the system is concerned. The obfuscation allows us to
> be a bit less intrusive. In this case, if I was a malicious person, I
> could not be inspired to open a credit card account in the name of Don
> Middleton because I saw it in the metrics log. Most credit card
> companies would frown on giving a card to
> da39a3ee5e6b4b0d3255bfef95601890afd80709. There is absolutely no
> functional reason to provide usernames in logs. As I mentioned if you
> want to resolve this person then you can, but that additional step
> thwarts abuse and having us on the hook for putting this unnecessary
> bit of information out there. There still remains no cogent reason to
> put an individuals username or openid out in the clear in metrics logs
> that are transferred on the wire. I think it would be a positive
> thing to be able to make the righteous claim that we don't expose our
> users to undo information exposure. It is a good policy, prevents
> bias and makes us look good. - win win win
>
> If you want to be Big Brother, you can still block mischievous
> da39a3ee5e6b4b0d3255bfef95601890afd80709 from coming into your system :-).
>
> You may want to re-examine what you are doing that is using people's
> usernames/openids and why that is necessary. There still doesn't seem
> to be any scenario that would support this 1:1 string replacement. IMHO.
>
> We will pilot it and see how you like it. fair enough?
>
> On the technical side it is pretty straight forward.
>
>> On Apr 19, 2011, at 4:10 PM, Gavin M. Bell wrote:
>>
>>> 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
>>> _______________________________________________
>>> GO-ESSP-TECH mailing list
>>> GO-ESSP-TECH at ucar.edu <mailto: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
--
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/20110420/85ec9928/attachment.html
More information about the GO-ESSP-TECH
mailing list