SocketFactory property duplication

[Brent Putman]

On 5/24/17 9:27 PM, Cantor, Scott wrote:
> Brent, please review [1] when you have a moment, especially the warnings and suggestions around the way to apply these features to the system.

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

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.


>
> 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.

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20170526/7f8564b4/attachment.html>