<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffcc">
    Hi...<br>
    <br>
    On 4/20/11 8:13 AM, Don Middleton wrote:
    <blockquote cite="mid:D9CF70B2-8B68-4A6D-8E83-43946571CBB0@ucar.edu"
      type="cite">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:
      <div><span class="Apple-style-span" style="font-family:
          Helvetica,Arial,sans-serif; font-size: 13px; line-height:
          17px;">
          <blockquote type="cite">
            <h4 style="line-height: normal; font-weight: bold; padding:
              0px; font-size: 13pt; margin: 25px 0px 4px; color: rgb(0,
              51, 102);">Basic Course of Events</h4>
            <ul style="font-size: 10pt; line-height: 13pt;
              list-style-type: disc;">
              <li style="font-size: 10pt; line-height: 13pt; margin:
                0px; padding: 0px;">The ESG Gateway authenticates with a
                Datanode.</li>
              <li style="font-size: 10pt; line-height: 13pt; margin:
                0px; padding: 0px;">The ESG Gateway requests metrics
                data from the Datanode for a specific time range.</li>
              <li style="font-size: 10pt; line-height: 13pt; margin:
                0px; padding: 0px;">The Datanode retrieves the metrics
                data for the specific time range.</li>
              <li style="font-size: 10pt; line-height: 13pt; margin:
                0px; padding: 0px;">The Datanode returns the metric data
                to the ESG Gateway</li>
              <li style="font-size: 10pt; line-height: 13pt; margin:
                0px; padding: 0px;">The ESG Gateway persists the
                returned metric data to its Database.</li>
            </ul>
          </blockquote>
        </span>
        <div>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.</div>
        <div><br>
        </div>
        <div>cheers - don</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    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".&nbsp; 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.&nbsp; This is exactly
    the usage scenario as we do with email addresses.&nbsp; There is no real
    difference with what the String is that identifies the user as far
    as any of the system is concerned.&nbsp; The obfuscation allows us to be
    a bit less intrusive.&nbsp; 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.&nbsp; Most credit card
    companies would frown on giving a card to
    da39a3ee5e6b4b0d3255bfef95601890afd80709.&nbsp; There is absolutely no
    functional reason to provide usernames in logs.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; It is
    a good policy, prevents bias and makes us look good. - win win win<br>
    <br>
    If you want to be Big Brother, you can still block mischievous
    da39a3ee5e6b4b0d3255bfef95601890afd80709 from coming into your
    system :-).<br>
    <br>
    You may want to re-examine what you are doing that is using people's
    usernames/openids and why that is necessary.&nbsp; There still doesn't
    seem to be any scenario that would support this 1:1 string
    replacement. IMHO.<br>
    <br>
    We will pilot it and see how you like it. fair enough?<br>
    <br>
    On the technical side it is pretty straight forward.<br>
    <br>
    <blockquote cite="mid:D9CF70B2-8B68-4A6D-8E83-43946571CBB0@ucar.edu"
      type="cite">
      <div>
        <div>
          <div>On Apr 19, 2011, at 4:10 PM, Gavin M. Bell wrote:</div>
          <br class="Apple-interchange-newline">
          <blockquote type="cite">
            <div text="#000000" bgcolor="#ffffcc"> Hi Eric <br>
              <br>
              (comments below)<br>
              <br>
              On 4/19/11 1:46 PM, Eric Nienhouse wrote:
              <blockquote cite="mid:4DADF4AA.504@ucar.edu" type="cite">
                <pre wrap="">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.
</pre>
              </blockquote>
              nod<br>
              <blockquote cite="mid:4DADF4AA.504@ucar.edu" type="cite">
                <pre wrap="">4)  There are a number of use cases which imply tracking user OpenID's 
at the GW and DN.

</pre>
              </blockquote>
              I sill think that the openid's should be obfuscated.&nbsp; 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.&nbsp; With that bit of information there
              will be everything that one would need in a metrics
              context.&nbsp; 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.<br>
              <br>
              I share Bob's and Philip's concern about data exposure.&nbsp;
              In the scenario above, the&nbsp; openid of person Z can still
              be positively gotten by asking idp X, 'hey who is Z?', but
              this is not the general case.&nbsp; 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.&nbsp; 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.<br>
              <br>
              So, the returned metrics would not have the openid but
              have two bits of information:<br>
              1 - the openid / userid hash<br>
              2 - the hostname of the IDP for whom the openid is in
              custody.<br>
              <br>
              I think this should be sufficient to provide reasonable
              privacy regardless of using secured ssl or not.<br>
              I cannot see a use case in the context of metrics that
              require any additional information.<br>
              Do you concur?&nbsp; <br>
              <blockquote cite="mid:4DADF4AA.504@ucar.edu" type="cite">
                <pre wrap="">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.

  <a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://wiki.ucar.edu/display/esgcet/Metrics">https://wiki.ucar.edu/display/esgcet/Metrics</a>

I appreciate all the input today.

Thanks,

-Eric


_______________________________________________
GO-ESSP-TECH mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a>
</pre>
              </blockquote>
              <br>
              <pre class="moz-signature" cols="72">-- 
Gavin M. Bell
Lawrence Livermore National Labs
--

 "Never mistake a clear view for a short distance."
                      -Paul Saffo

(GPG Key - <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)

 A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E
</pre>
            </div>
            _______________________________________________<br>
            GO-ESSP-TECH mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:GO-ESSP-TECH@ucar.edu">GO-ESSP-TECH@ucar.edu</a><br>
            <a class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/go-essp-tech">http://mailman.ucar.edu/mailman/listinfo/go-essp-tech</a><br>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Gavin M. Bell
Lawrence Livermore National Labs
--

 "Never mistake a clear view for a short distance."
                      -Paul Saffo

(GPG Key - <a class="moz-txt-link-freetext" href="http://rainbow.llnl.gov/dist/keys/gavin.asc">http://rainbow.llnl.gov/dist/keys/gavin.asc</a>)

 A796 CE39 9C31 68A4 52A7  1F6B 66B7 B250 21D5 6D3E
</pre>
  </body>
</html>