[Go-essp-tech] GO-ESSP-Tech 4/19/2011 - Release Coordination - Metrics
Eric Nienhouse
ejn at ucar.edu
Wed Apr 20 15:21:54 MDT 2011
Hi All,
I thought we had consensus on the simple approach of securing the
metrics access service via SSL and providing user identifiers as
OpenIDs. This was identified as the lowest impact approach that
maintained strong security around user identities and other metrics details.
We should take this path forward. Others are advocating it as well.
Gavin, are you suggesting we keep the metrics service unsecured? (eg:
without client authentication using SSL?) Maintaining these records
behind a secured web service does allow us to prevent "undo information
exposure" from the metrics service.
I don't think the added complexity of OpenID hashing on top of that buys
us very much. Further, there will be impact on the gateway to lookup
users via the OpenID hash and IDP base. I'm not comfortable with trying
this out as a pilot so close to releasing the 1.3.0 version.
Please consider taking the simple approach :-)
Regards,
-Eric
Gavin M. Bell wrote:
> (I had to edit my gaffs - just too embarrassing - too early for me...
> need mountain dew i.v. drip stat.)
>
> 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 rogue is say, "donmiddleton" you'll
>> know the rogue 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, that additional step
>> thwarts abuse and having us on the hook for putting this unnecessary
>> bit of information out there. Furthermore the user put their trust
>> in their chosen IDP to have their information not in every metrics
>> client in our system. 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 and is the right thing to do. - win 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/if that is necessary. There still doesn't
>> seem to be any scenario that would NOT support this simple 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
>
More information about the GO-ESSP-TECH
mailing list