Page Comparison

...

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="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

TBDCurrently it is less than straightforward to configure more typical HTTP credentials such as a basic-auth name 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 name/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 name 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.

<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

...