Page Comparison

...

• loading service configuration resources from an HTTP server (HTTPResource)
• advanced/custom configuration of remote metadata sources (HTTPMetadataProvidersFileBackedHTTPMetadataProvider, DynamicHTTPMetadataProvider)
• reporting of metrics via an HTTP collector (MetricsConfiguration)
• a forthcoming HTTPDataConnector the HTTP DataConnector for web service access in the attribute resolver

...

<bean id="ShortTimeoutHttpClient" parent="shibboleth.NonCachingHttpClient" p:socketTimeout="PT5S" />

...

For more advanced control over this process, you need to perform additional steps, and add more complex Spring wiring involving the org.opensaml.security.httpclient.HttpClientSecurityParameters class, which provides a mechanism for using a TrustEngine to evaluate the server's certificate. There are a variety of TrustEngine implementations that can perform simple or advanced checks, but the critical difference is that they're contextual. That is, they can be applied to one component such that the rules it uses can be specific to that component alone and not the whole system.

A particularly useful approach is to abandon the fundamentally flawed use of commercial certificates with non-browser-facing services and use self-signed certificates evaluated on the basis of public key comparisons, much like Shibboleth does with SAML, or even certificates issued on an automated short-term basis by dedicated CAs.

Repeating: you can tell the HttpClient bean that you want to support a more "advanced mode" of processing, but you configure the rules not on the HttpClient bean but rather on the component using the client bean. This is because the injection of the rules you want to apply have to be added at runtime when the client gets used and not into the client's own data structures. It's a consequence of the library's design. The risk in versions of the software prior to V3.4 is that if you tell the client you want this, but don't configure the component that's using it properly, the default Java behavior is also skipped, and you get no security at all. The following explains what you should do, in detail, for older versions, because on newer versions it fails closed anyway.

TrustEngine Examples

To use a TrustEngine, you need to define an HttpClientSecurityParameters bean with a tLSTrustEngine property. While you can define any compatible object, the two most common cases are supported via a pair of factory beans:

...

The examples below are semi-complete, in that they include a portion of the "real" component that the security rules are being supplied for. Most of the components that can support this will carry both httpClient and httpClientSecurityParameters properties. Components defined in custom (non-Spring) XML syntax will usually support httpClientRef and httpClientSecurityParametersRef XML attributes to reference Spring beans of the proper type.

...

The full range of PKIX options is quite complex, but for basic use cases a factory bean makes it simple. To validate the server's certificate against a fixed CA (name checking is turned off because the HttpClient is already doing this step for us):

<bean id="CustomHttpSecurity" class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
	<property name="tLSTrustEngine">
		<bean parent="shibboleth.StaticPKIXTrustEngine"
			p:certificates="%{idp.home}/credentials/rootca.pem"
			p:checkNames="false" />
	</property>
</bean>

<!-- Sample feature we're actually trying to use, which we inject custom rules into. -->
<bean id="PushReporter" parent="shibboleth.metrics.HTTPReporter" c:name="MyCollector"
	p:httpClient-ref="CustomHttpClient"
	p:httpClientSecurityParameters-ref="CustomHttpSecurity"
	p:collectorURL="https://log.example.org/cgi-bin/collector.cgi" />

...

Applying a TrustEngine to HttpClient

You should always start by configuring a component using the HttpClient with the HttpClientSecurityParameters wiring needed to implement your needs, as in the above examples.

...

The category and details in the ERROR will vary by component, but the WARN and SSLPeerUnverifiedException messages will consistently indicate that the component was configured to apply a TrustEngine to the connection but couldn't do so. This will may happen after the connection is established, possibly even after data is sent and consumed, but it should happen at the end. If not, something is wrong and has to be corrected to be confident that the eventual configuration will work.

...

<bean id="SecurityEnhancedHttpClient" parent="shibboleth.NonCachingHttpClient"
	p:tLSSocketFactory-ref="shibboleth.SecurityEnhancedTLSSocketFactory" />

...

TLS Client Authentication

...

Note
The code as it stands does not generally support TLS Renegotiation, which is most commonly encountered when using a virtual host that applies client TLS to only a subset of paths and not the host as a whole.

Configuring a component using the HttpClient with a private key and certificate for authenticating itself to a server is a simple two step process:

...

The syntax for supplying a keypair can be essentially copied from the credentials.xml file that contains the more "usual" keys and certificates used by the IdP. Note that the beans defined in that file are not visible outside the RelyingPartyConfiguration so if you try to reuse them elsewhere by reference, you'll get errors. The example builds on the previous one and includes server authentication.

<bean id="

Code Block
language xml title Client TLS example collapse true
<bean id="CustomHttpSecurity" class="org.opensaml.security.httpclient.HttpClientSecurityParameters"> <property name="tLSTrustEngine"> <bean parent="shibboleth.StaticExplicitTrustEngine" p:certificates="%{idp.home}/credentials/server.pem" /> </property> <property name="clientTLSCredential"> <bean class="net.shibboleth.idp.profile.spring.factory.BasicX509CredentialFactoryBean" p:privateKeyResource="%{idp.home}/credentials/tlsclient.key" p:certificateResource="%{idp.home}/credentials/tlsclient.crt" /> </property> </bean> <!-- Sample feature we're actually trying to use, which we inject custom rules into. --> <bean id="PushReporter" parent="shibboleth.metrics.HTTPReporter" c:name="MyCollector" p:httpClient-ref="CustomHttpClient" p:httpClientSecurityParameters-ref="CustomHttpSecurity" p:collectorURL="https://log.example.org/cgi-bin/collector.cgi" />

HTTP Authentication

...

bin/collector.cgi" />

HTTP Authentication

Currently it is less than straightforward to configure more typical HTTP credentials such as a basic-auth username and password, due to a lack of abstraction methods in our code to hide some of the gory details of the HttpClient's data model. In particular, some of the methods that need to be called take multiple parameters, which violates the bean convention for a setter. It's possible to invoke more complex methods in Spring, but it takes some extra wiring. We intend to supply some additional code for this in a future release.

Note that some of the older custom schemas such as the metadata configuration schema may support shorthand for supplying username/password credentials, and while these do work, they're deprecated in favor of the more generic httpClientSecurityParameters-ref syntax.

At the moment, it's fairly simple to supply a username and password that gets used unilaterally with a given component's requests. That is, it's not "scoped" to limit its use to a particular server. This implies that you have a working configuration in place to authenticate the server's certificate so that the password isn't sent inadvertently to a malicious location. An example follows (again, building on the server authentication case):

<bean id="CustomHttpSecurity" class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
	<property name="tLSTrustEngine">
		<bean parent="shibboleth.StaticExplicitTrustEngine"
			p:certificates="%{idp.home}/credentials/server.pem" />
	</property>
	<property name="basicCredentials">
		<bean class="org.apache.http.auth.UsernamePasswordCredentials"
			c:_0="webauth" c:_1="%{idp.collector.password}" />
	</property>
</bean>

<!-- Sample feature we're actually trying to use, which we inject custom rules into. -->
<bean id="PushReporter" parent="shibboleth.metrics.HTTPReporter" c:name="MyCollector"
	p:httpClient-ref="CustomHttpClient"
	p:httpClientSecurityParameters-ref="CustomHttpSecurity"
	p:collectorURL="https://log.example.org/cgi-bin/collector.cgi" />

The next level up in complexity is the desirable ability to limit the scope of the credentials for safety's sake. The example relies on the hostname and port of the server to scope the password. There are more advanced ways to build the AuthScope object being passed into the API such as including the Realm challenge from the server.

<bean id="CustomHttpSecurity" class="org.opensaml.security.httpclient.HttpClientSecurityParameters">
	<property name="tLSTrustEngine">
		<bean parent="shibboleth.StaticExplicitTrustEngine"
			p:certificates="%{idp.home}/credentials/server.pem" />
	</property>
</bean>

<bean id="ScopedBasicAuth" class="org.springframework.beans.factory.config.MethodInvokingBean"
		p:targetObject-ref="CustomHttpSecurity"
		p:targetMethod="setBasicCredentialsWithScope">
	<property name="arguments">
		<list>
			<bean class="org.apache.http.auth.UsernamePasswordCredentials"
				c:_0="webauth" c:_1="%{idp.collector.password}" />
			<bean class="org.apache.http.auth.AuthScope"
				c:_0="log.example.org" c:_1="443" />
		</list>
	</property>
</bean>

<!-- Sample feature we're actually trying to use, which we inject custom rules into. -->
<bean id="PushReporter" parent="shibboleth.metrics.HTTPReporter" c:name="MyCollector"
	p:httpClient-ref="CustomHttpClient"
	p:httpClientSecurityParameters-ref="CustomHttpSecurity"
	p:collectorURL="https://log.example.org/cgi-bin/collector.cgi" />

A more advanced example would be to configure multiple sets of credentials for different servers, assuming a component that potentially contacts different servers. Since this is not a common case with any of our components, it's not likely to be needed much.

Reference

Beans

Properties