You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Brandon Richins <Br...@imail.org> on 2010/06/22 22:00:34 UTC
STSClient settings
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
Re: STSClient settings
Posted by Daniel Kulp <dk...@apache.org>.
Any chance you could create a simple project that shows these? Having the
wsdl for the STS wired into your sample code and such would be a big help in
debugging.
More answers inline.
On Tuesday 22 June 2010 4:00:34 pm Brandon Richins wrote:
> 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/servi
> ces/RequestSecurityToken?wsdl");
> client.setServiceName("{http://docs.oasis-open.org/ws-sx/ws-trust/200512}S
> ecurityTokenService");
> 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/addre
> ssing"); 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?
The custom AppliesTo value is always passed into the STSClient's
requestSecurityToken. It's currently never read in any other way so there
isn't a way to do this right now. A patch would be nice. :-)
> <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/RequestSecuri
> tyToken?wsdl" /> <property name="serviceName"
> value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512}SecurityTokenServ
> ice" /> <property name="endpointName"
> value="{http://docs.oasis-open.org/ws-sx/ws-trust/200512}RequestSecurityTo
> ken" /> <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("stsClien
> t") I get the same behavior as when I call it programmatically.
Kind of expected. Spring should be doing the same thing you are doing in
your code in this case.
> 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)?
Kind of. However, if you have multiple beans of the same type configured, it
really wouldn't work. Normally, you would grab the ApplicationContect
(likely injected someplace via ApplicationContextAware interface) and you grab
the bean by name from the spring ApplicationContext.
> 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("stsClien
> t");
> stsClient.setAddressingNamespace("http://schemas.xmlsoap.org/ws/2004/08/ad
> dressing"); SecurityToken token =
> stsClient.requestSecurityToken("http://intermountainhealthcare.org/VER/ICM
> /SAML1.1");
>
I'm really not sure why that isn't working unless the names you are
configuring in don't match what's in the WSDL. All the
issuedTokenInterceptor stuff does is:
client.setTrust(....);
client.setTemplate(...);
client.setAddressingNamespace(maps.getNamespaceURI());
tok = client.requestSecurityToken(s);
Which is pretty much exactly what you are doing. Thus, I'm not sure why it
wouldn't be working.
Dan
> Thanks,
>
> Brandon Richins
> ECIS Migration
> Intermountain Healthcare
> 4646 Lake Park Blvd
> Salt Lake City, UT 84120
> p. 801.442.5523
> c. 801.589.2428
--
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog