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): Use of Basic Authentication| Code Block |
|---|
| <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. Basic Authentication with host/port AuthScope| Code Block |
|---|
| <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. |