Support for OpenSAML security features in HTTPResource layer

Description

We don't have real security support other than via the HttpClient instances themselves in the HTTPResource class in spring-extensions.

We have models to follow for that in OpenSAML now, but the Spring dependency has to live in the IdP. Unfortunately that may mean duplicating FileBackedHTTPResource also unless some kind of refactoring could be done down in spring-extensions to allow some of the logic to be injected somehow.

Environment

None

Activity

Show:

Scott Cantor December 30, 2016 at 8:30 PM
Edited

IdP, r8590

Added a factory bean to handle basic setup of HTTP resources using PKIX trust or simple key pinning.
Pinned key:

PKIX:

Scott Cantor December 30, 2016 at 2:12 AM

r4591

Added a handler to wrap the standard sequence of parameter setting and sanity checks, with unit tests.

Scott Cantor December 30, 2016 at 12:37 AM

Which of course is just wrong, the extension interface needs to be in java-support so OpenSAML can leverage it.

java-support, 7d46fec0a24e58ee91aca131ef02c3b6e4a1a0be
spring-extensions, a13a9adfcce38644ed4a98b51c01ff818757f81f

Scott Cantor December 30, 2016 at 12:28 AM

spring-extensions, eb429703cebb54dce0bf74ef47802f1589a37748

Add an extension point to manipulate the client context. Supports access to context before and after, which is required to perform the sanity check in the checkTLSCredentialEvaluated method.

Scott Cantor December 29, 2016 at 8:16 PM

I think we can just extend the HTTPResource class with a minimal hook to modify the HttpClientContext its using, and then build a component in OpenSAML to do the right things.

Fixed
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Reporter

Components

Fix versions

Created December 29, 2016 at 7:43 PM
Updated October 9, 2018 at 6:01 PM
Resolved December 30, 2016 at 2:12 AM