<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 5/24/17 9:27 PM, Cantor, Scott

      wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:A87BA3A9-02AF-453D-A5C0-FA0704B46297@osu.edu">

      <pre wrap="">Brent, please review [1] when you have a moment, especially the warnings and suggestions around the way to apply these features to the system.</pre>

    </blockquote>

    <br>

    Looks pretty good.  It is a somewhat complex topic, so it's hard to

    dumb this stuff down.<br>

    <br>

    On the TBD HTTP Authentication section:  We probably need some

    pretty simple factory beans in spring-extensions to facilitate

    building an HC CredentialsProvider and its constituent components

    (AuthScope, Credentials).  Once we have those, I think documenting

    that for the advanced cases is pretty easy.  IIRC all of the IdP

    schemas for HTTP-oriented components support a direct username and

    password property, which still works even if you supply an

    HttpClientSecurityParameters.  So it really only matters for 4.0

    when those deprecated properties go away.<br>

    <br>

    <br>

    <blockquote type="cite"

      cite="mid:A87BA3A9-02AF-453D-A5C0-FA0704B46297@osu.edu">

      <pre wrap="">

I couldn't come up with a good way to really explain this other than to suggest that the best thing is to configure it to fail deliberately and then flip the right switch to fix it. Otherwise it seems pretty risky to set up because once you toggle on the special SocketFactory, you leave the client wide open if there's no TrustEngine applied by the object using the client.

</pre>

    </blockquote>

    <br>

    I see what you mean.  It was honestly intended as a feature that the

    caller can supply a TrustEngine or not, and if not then it skips the

    trust eval.  However, since that seems legitimately dangerous wrt

    accidental misconfiguration, etc, in the IdP, I think it's pretty

    easy to add a trustEngineRequired boolean to the

    SecurityEnhancedTLSSocketFactory, and have it throw if true and no

    engine is supplied.  We could even default it to true, either in the

    factory itself or in the support class factory constructing code. 

    (And if you turn that off, then you must know what you are doing.) 

    So maybe that would be a way to default it to a secure config

    out-of-the-box and avoid the caveats and warnings around this, and

    the fail-then-fix instructions.  Should we consider for 3.4?<br>

  </body>

</html>