
Contributor
2014-10-03
04:46 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Problem with WS-Security from Client-Side
Hi there,
I developed a webservice with WS-Security, some costumers works with it without any problems.
Now I've a costumer, he can't connect to this service because of some problems of his software... is it possible to help him with some changes in the configuration? He can't change anything in his software.
the possibility of:
“The Nonce of a UsernameToken must contain a Base64 EncodingType as per the Basic Security Profile 1.1 specification: You can disable Basic Security Profile enforcement in CXF by setting the SecurityConstants property "ws-security.is-bsp-compliant" to "false"”
we tested without any success..
his example of request:
"<SOAP-ENV:Header>
<wsse
ecurity SOAP-ENV:mustUnderstand="1" xmlns:wsse="">
<wsse:UsernameToken xmlns:wsse="">
<wsse:Username xmlns:wsse="">Username</wsse:Username>
<wsse
assword Type="" xmlns:wsse="">Password</wsse
assword>
<wsu:Created xmlns:wsu="">2014-09-26T13:52:05.274Z</wsu:Created>
<wsse:Nonce xmlns:wsse="">pcDxvAc+9phr5JrnvxeJ5g==</wsse:Nonce>
</wsse:UsernameToken>
</wsse
ecurity>
</SOAP-ENV:Header>"
my example request via SOAPUI:
"<soapenv:Header>
<wsse
ecurity xmlns:wsse="" xmlns:wsu="">
<wsse:UsernameToken wsu:Id="UsernameToken-41413B728CF7E395B614117328261961">
<wsse:Username>Username</wsse:Username>
<wsse
assword Type="">Password</wsse
assword><wsse:Nonce EncodingType="">59Y4JmEZXNixwyuBoNouWQ==</wsse:Nonce><wsu:Created>2014-09-26T12:00:26.180Z</wsu:Created>
</wsse:UsernameToken></wsse
ecurity>
</soapenv:Header>"
thanks for help!
I developed a webservice with WS-Security, some costumers works with it without any problems.
Now I've a costumer, he can't connect to this service because of some problems of his software... is it possible to help him with some changes in the configuration? He can't change anything in his software.
the possibility of:
“The Nonce of a UsernameToken must contain a Base64 EncodingType as per the Basic Security Profile 1.1 specification: You can disable Basic Security Profile enforcement in CXF by setting the SecurityConstants property "ws-security.is-bsp-compliant" to "false"”
we tested without any success..
his example of request:
"<SOAP-ENV:Header>
<wsse
<wsse:UsernameToken xmlns:wsse="">
<wsse:Username xmlns:wsse="">Username</wsse:Username>
<wsse
<wsu:Created xmlns:wsu="">2014-09-26T13:52:05.274Z</wsu:Created>
<wsse:Nonce xmlns:wsse="">pcDxvAc+9phr5JrnvxeJ5g==</wsse:Nonce>
</wsse:UsernameToken>
</wsse
</SOAP-ENV:Header>"
my example request via SOAPUI:
"<soapenv:Header>
<wsse
<wsse:UsernameToken wsu:Id="UsernameToken-41413B728CF7E395B614117328261961">
<wsse:Username>Username</wsse:Username>
<wsse
</wsse:UsernameToken></wsse
</soapenv:Header>"
thanks for help!
471 Views
5 Replies

Creator
2014-10-06
08:01 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've verified with WSS4J that the first example request passes when BSP (Basic Security Profile) compliance is turned off. So the problem appears to be that turning off BSP compliance via "ws-security.is-bsp-compliant" is not working with your configuration.
Could you clarify whether you are using WS-SecurityPolicy to configure the service, or just manually adding the WSS4JInInterceptor? If the latter, then the "ws-security.is-bsp-compliant" tag won't work, as this only works with WS-SecurityPolicy. If this is the case, then you can turn off BSP compliance via setting "isBSPCompliant" to "false".
If this doesn't work, could you also paste the service configuration?
Colm.
Could you clarify whether you are using WS-SecurityPolicy to configure the service, or just manually adding the WSS4JInInterceptor? If the latter, then the "ws-security.is-bsp-compliant" tag won't work, as this only works with WS-SecurityPolicy. If this is the case, then you can turn off BSP compliance via setting "isBSPCompliant" to "false".
If this doesn't work, could you also paste the service configuration?
Colm.
471 Views

Contributor
2014-10-06
08:25 AM
Author
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've verified with WSS4J that the first example request passes when BSP (Basic Security Profile) compliance is turned off. So the problem appears to be that turning off BSP compliance via "ws-security.is-bsp-compliant" is not working with your configuration.
Could you clarify whether you are using WS-SecurityPolicy to configure the service, or just manually adding the WSS4JInInterceptor? If the latter, then the "ws-security.is-bsp-compliant" tag won't work, as this only works with WS-SecurityPolicy. If this is the case, then you can turn off BSP compliance via setting "isBSPCompliant" to "false".
If this doesn't work, could you also paste the service configuration?
Colm.
Hi Colm,
I addet the security in the Talend Open Studio at the service... and via the jaas: addet the username and passwort in the karaf-console...
This works with all other clients...
here my config:
# cat org.talend.esb.job.client.sts.cfg ### # #%L # Talend :: ESB :: Job :: Controller # %% # Copyright (C) 2011 Talend Inc.
# %%
# Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License.
# You may obtain a copy of the License at #
#
#
# Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and # limitations under the License.
# #L%
###
#STS endpoint configuration
#sts.wsdl.location =
sts.wsdl.location =
sts.x509.wsdl.location =
sts.namespace =
sts.service.name = SecurityTokenService
sts.endpoint.name = UT_Port
sts.x509.endpoint.name = X509_Port
#STS properties configuration
ws-security.sts.token.username = myclientkey ws-security.sts.token.usecert = true ws-security.is-bsp-compliant = false ws-security.sts.token.properties = file:${tesb.home}/etc/keystores/clientKeystore.properties
ws-security.encryption.username = mystskey ws-security.encryption.properties = file:${tesb.home}/etc/keystores/clientKeystore.properties
# cat org.talend.esb.sts.server.cfg ### # #%L # TESB :: STS :: CONFIG # %% # Copyright (C) 2011 Talend Inc.
# %%
# Licensed under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License.
# You may obtain a copy of the License at #
#
#
# Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and # limitations under the License.
# #L%
###
stsServiceUrl=/SecurityTokenService/UT
stsX509ServiceUrl=/SecurityTokenService/X509
jaasContext=karaf
signatureProperties=file:${tesb.home}/etc/keystores/stsKeystore.properties
signatureUsername=mystskey
bspCompliant=false
useMessageLogging=false
samlTokenLifetime=1800
thanks
Wolfgang
471 Views

Creator
2014-10-16
11:55 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Wolfgang,
Sorry for the delay in replying. The answer is that there is no way to disable Basic Security Profile compliance in the container configuration files right now. To disable Basic Security Profile compliance, you will need to open up the .kar + change the blueprint configuration for the service, adding "<entry key="ws-security.is-bsp-compliant" value="false"/>" as a JAX-WS property. For example:
<jaxws:endpoint xmlns:jaxws=""
id="DoubleItService"
implementor="#genericServiceProvider"
xmlns:tns=""
serviceName="tns
oubleItService"
endpointName="tns
oubleItServicePort"
address="/DoubleItService"
wsdlLocation="classpath:/DoubleItService_0.1.wsdl">
<jaxws
roperties>
<entry key="ws-security.ut.validator">
<bean class="org.apache.ws.security.validate.JAASUsernameTokenValidator">
<property name="contextName" value="karaf" />
</bean>
</entry>
<entry key="ws-security.is-bsp-compliant" value="false"/>
<entry key="use.service.registry" value="false" />
</jaxws
roperties>
<jaxws:features>
<p
olicies xmlns
="">
<wsp
olicy xmlns:wsp="">
<wsp
olicyReference URI="org.talend.esb.job.token.policy" />
</wsp
olicy>
</p
olicies>
</jaxws:features>
</jaxws:endpoint>
Colm.
Sorry for the delay in replying. The answer is that there is no way to disable Basic Security Profile compliance in the container configuration files right now. To disable Basic Security Profile compliance, you will need to open up the .kar + change the blueprint configuration for the service, adding "<entry key="ws-security.is-bsp-compliant" value="false"/>" as a JAX-WS property. For example:
<jaxws:endpoint xmlns:jaxws=""
id="DoubleItService"
implementor="#genericServiceProvider"
xmlns:tns=""
serviceName="tns
endpointName="tns
address="/DoubleItService"
wsdlLocation="classpath:/DoubleItService_0.1.wsdl">
<jaxws
<entry key="ws-security.ut.validator">
<bean class="org.apache.ws.security.validate.JAASUsernameTokenValidator">
<property name="contextName" value="karaf" />
</bean>
</entry>
<entry key="ws-security.is-bsp-compliant" value="false"/>
<entry key="use.service.registry" value="false" />
</jaxws
<jaxws:features>
<p
<wsp
<wsp
</wsp
</p
</jaxws:features>
</jaxws:endpoint>
Colm.
471 Views

Anonymous
Not applicable
2015-03-23
11:47 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
How can we open the .kar file to change the blueprint configuration?
How can we open the .kar file to change the blueprint configuration?
471 Views

Anonymous
Not applicable
2017-03-20
09:03 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can use winrar to open kar file.
Right click on .kar and select open with win rar.
Right click on .kar and select open with win rar.
471 Views
