I would like to use the STSClient class to programmatically obtain a token from
an STS. Everything works fine when I use an XML configuration with an STS
subsection. However I'm having problems getting the same behavior
programmatically as when I use the configuration file.
1) When I run the following code, the username token does not get created in
the header, but it works just fine when configured via XML. Any reason why
policies including the username token would not be applied in the following
programmatic approach:
Bus bus = BusFactory.getDefaultBus();
List<AbstractFeature> features = new ArrayList<AbstractFeature>();
features.add(new WSAddressingFeature());
features.add(new WSPolicyFeature());
features.add(new LoggingFeature());
for(AbstractFeature feature : features) {
feature.initialize(bus);
}
STSClient client = new STSClient(bus);
client.setWsdlLocation("https://nonexistanturl:9445/TrustServerWST13/services/RequestSecurityToken?wsdl";);
client.setServiceName("{http://docs.oasis-open.org/ws-sx/ws-trust/200512}SecurityTokenService";);
client.setEndpointName("{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken";);
client.setRequiresEntropy(false);
Map<String, Object> properties = new HashMap<String, Object>();
properties.put(SecurityConstants.USERNAME,"scott");
properties.put(SecurityConstants.PASSWORD, "tiger");
client.setProperties(properties);
client.setFeatures(features);
client.setAddressingNamespace("http://schemas.xmlsoap.org/ws/2004/08/addressing";);
client.setTrust(new Trust10(SP11Constants.INSTANCE));
client.requestSecurityToken("http://foo.org/VER/SAML1.1";);
2) When I configure the sts client as below and inject it as a named bean, it
almost works. Right now I have to subclass the STSClient because the
applies-to property is not being picked up from the client. It looks like the
IssuedTokenInterceptorProvider class expects the property to be set on the
message and not on the STSClient. How do I get the applies-to property set on
the message since it doesn't seem to be picked up from the client?
<bean id="stsClient" class="org.apache.cxf.ws.security.trust.STSClient">
<constructor-arg ref="cxf" />
<property name="requiresEntropy" value="false" />
<property name="wsdlLocation"
value="https://nonexistanturl:9445/TrustServerWST13/services/RequestSecurityToken?wsdl";
/>
<property name="serviceName"
value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512}SecurityTokenService";
/>
<property name="endpointName"
value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityToken";
/>
<property name="properties">
<map>
<entry key="ws-security.username" value="scott" />
<entry key="ws-security.password" value="tiger" />
<entry key="ws-security.sts.applies-to" value="http
http://foo.org/VER/SAML1.1"; />
</map>
</property>
</bean>
3) I hoped to bridge my solution by just configuring the bus with XML then
getting a handle to the stsClient bean. When I try to get the sts client
directly from the bus configuration using
(STSClient)bus.getExtension(BusApplicationContext.class).getBean("stsClient") I
get the same behavior as when I call it programmatically. So I've got two
questions here. Is using getExtension an acceptable way to get a hold of a
bean/service (not including standard dependency injection)? I'm guessing that
calling directly I'm missing some interceptors that get invoked when it's
called indirectly. What interceptors should I focus on to try to call it
directly instead of piggy backing on another service?
SpringBusFactory bf = new SpringBusFactory();
URL busFile = EchoTest3.class.getResource("/echoTest.xml");
Bus bus = bf.createBus(busFile.toString());
BusFactory.setDefaultBus(bus);
STSClient stsClient =
(STSClient)bus.getExtension(BusApplicationContext.class).getBean("stsClient");
stsClient.setAddressingNamespace("http://schemas.xmlsoap.org/ws/2004/08/addressing";);
SecurityToken token =
stsClient.requestSecurityToken("http://intermountainhealthcare.org/VER/ICM/SAML1.1";);
Thanks,
Brandon Richins
ECIS Migration
Intermountain Healthcare
4646 Lake Park Blvd
Salt Lake City, UTÂ 84120
p. 801.442.5523
c. 801.589.2428
