You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by SRog <sr...@outlook.de> on 2014/10/20 18:27:29 UTC
Username/PWD on STS
Hi,
I try to configure a simple STS which satisfys the need of BiPRO (a standard
to transfer insurance data) with Secure Conversation.
In WSDL of the STS the BiPRO defines a policy like this for
username/password authentication:
<wsp:Policy wsu:Id="BiPROAuthSecurityPolicy"
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
<wsp:ExactlyOne>
<wsp:All>
<sp:TransportBinding>
<wsp:Policy>
<sp:TransportToken>
<wsp:Policy>
<sp:HttpsToken RequireClientCertificate="false"/>
</wsp:Policy>
</sp:TransportToken>
</wsp:Policy>
</sp:TransportBinding>
<sp:SupportingTokens>
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<sp:UsernameToken wsu:Id="BiPROBasicToken"/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
Then I configured the service in cxf-servlet.xml like this:
...
<bean id="mySTSProviderBean"
class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider">
<property name="issueSingleOperation" ref="transportIssueDelegate"/>
<property name="validateOperation" ref="transportValidateDelegate"/>
<property name="cancelOperation" ref="transportCancelDelegate"/>
</bean>
<bean id="transportIssueDelegate"
class="org.apache.cxf.sts.operation.TokenIssueOperation">
<property name="tokenProviders" ref="transportTokenProviders"/>
<property name="services" ref="transportService"/>
<property name="stsProperties" ref="transportSTSProperties"/>
<property name="tokenStore" ref="defaultTokenStore"/>
<property name="returnReferences" value="false" />
</bean>
<bean id="transportValidateDelegate"
class="org.apache.cxf.sts.operation.TokenValidateOperation">
<property name="tokenProviders" ref="transportTokenProviders"/>
<property name="tokenValidators" ref="transportTokenValidators"/>
<property name="stsProperties" ref="transportSTSProperties"/>
<property name="tokenStore" ref="defaultTokenStore"/>
</bean>
<bean id="transportCancelDelegate"
class="org.apache.cxf.sts.operation.TokenCancelOperation">
<property name="tokenCancellers" ref="transportTokenCancellers"/>
<property name="stsProperties" ref="transportSTSProperties"/>
<property name="tokenStore" ref="defaultTokenStore"/>
</bean>
<util:list id="transportTokenProviders">
<ref bean="transportSCTProvider"/>
</util:list>
<util:list id="transportTokenValidators">
<ref bean="transportSCTValidator"/>
</util:list>
<util:list id="transportTokenCancellers">
<ref bean="transportSCTCanceller"/>
</util:list>
<bean id="transportSCTProvider" class="sts.BiPROTokenProvider">
<property name="returnEntropy" value="false" />
</bean>
<bean id="transportSCTValidator"
class="org.apache.cxf.sts.token.validator.SCTValidator">
</bean>
<bean id="transportSCTCanceller"
class="org.apache.cxf.sts.token.canceller.SCTCanceller">
</bean>
<bean id="transportService"
class="org.apache.cxf.sts.service.StaticService">
<property name="endpoints" ref="transportEndpoints"/>
</bean>
<util:list id="transportEndpoints">
<value>http://localhost:(\d)*/doubleit/services/doubleit.*
</value>
</util:list>
<bean id="defaultTokenStore"
class="org.apache.cxf.sts.cache.DefaultInMemoryTokenStore">
</bean>
<bean id="encProperties"
class="org.apache.cxf.sts.service.EncryptionProperties">
<property name="encryptionAlgorithm"
value="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
</bean>
<bean id="transportSTSProperties"
class="org.apache.cxf.sts.StaticSTSProperties">
</bean>
<bean id="sctInterceptor"
class="org.apache.cxf.sts.interceptor.SCTInInterceptor"/>
<bean id="sctOutInterceptor"
class="org.apache.cxf.sts.interceptor.SCTOutInterceptor"/>
<jaxws:endpoint id="CXFSTS" implementor="#mySTSProviderBean"
address="/STS"
wsdlLocation="/WEB-INF/wsdl/bipro/SecurityTokenService-2.5.0.1.0.wsdl"
xmlns:ns1="http://www.bipro.net/namespace"
serviceName="ns1:SecurityTokenService_2.5.0.1.0"
endpointName="ns1:UserPasswordLogin">
<jaxws:inInterceptors>
<ref bean="sctInterceptor"/>
</jaxws:inInterceptors>
<jaxws:outInterceptors>
<ref bean="sctOutInterceptor"/>
</jaxws:outInterceptors>
<jaxws:outFaultInterceptors>
<ref bean="sctOutInterceptor"/>
</jaxws:outFaultInterceptors>
<jaxws:properties>
<entry key="ws-security.callback-handler"
value="sts.PasswordCallbackHandler" />
<entry key="org.apache.cxf.ws.security.tokenstore.TokenStore">
<ref bean="defaultTokenStore"/>
</entry>
</jaxws:properties>
<jaxws:features>
<logging xmlns="http://cxf.apache.org/core" />
<ref bean="transformFeature" />
</jaxws:features>
</jaxws:endpoint>
If I try to acces the services with a request containing username and pwd I
got the message "*None of the policy alternatives can be satisfied.*"
The request:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
<wsse:UsernameToken
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:bipro="http://www.bipro.net/namespace">
<wsse:Username>alice</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-387
username-token-profile-1.0#PasswordText">clarinet</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</soap:Header>
<soap:Body>
<wst:RequestSecurityToken
xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
<wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue</wst:RequestType>
<wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType>
</wst:RequestSecurityToken>
<soap:Body>
<soap:Envelope>
What I have to configure in cxf-servlet.xml to get things working? I could
not change the WSDL while this is standard BiPRO.
Thanks for your response,
SRog
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
No, simply assert the UsernameToken policies + the SupportingToken policy.
Colm.
On Fri, Oct 31, 2014 at 5:42 PM, SRog <sr...@outlook.de> wrote:
> Ah, okay. My problem is that there is no x.509 token in the supporting
> tokens
> collection.
>
> Collection<AssertionInfo> ais =
> aim.getAssertionInfo(SP12Constants.SUPPORTING_TOKENS);
>
> You mean that I first have to add the X.509 token to the supporting tokens
> collection and then assert it in secound step?
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750547.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Ah, okay. My problem is that there is no x.509 token in the supporting tokens
collection.
Collection<AssertionInfo> ais =
aim.getAssertionInfo(SP12Constants.SUPPORTING_TOKENS);
You mean that I first have to add the X.509 token to the supporting tokens
collection and then assert it in secound step?
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750547.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
I don't understand your question. No you should not assert a UsernameToken
if an X.509 token was checked. You assert the policies depending on what
was received, and let the CXF policy runtime figure out what policy
alternative was satisfied. If you are using an old version of CXF (e.g.
2.6.x) then you might want to upgrade, as there were fixes a while back to
how policy alternatives are handled.
Colm.
On Fri, Oct 31, 2014 at 6:29 AM, SRog <sr...@outlook.de> wrote:
> Hi,
> Okay I could insert the policies with the assert Method but why there is no
> x.509 in the supporting tokens? The same problem with wsdl policy
> description here?
> Should I assert an usernametoken if x.509 token was checked?
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750512.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hi,
Okay I could insert the policies with the assert Method but why there is no
x.509 in the supporting tokens? The same problem with wsdl policy
description here?
Should I assert an usernametoken if x.509 token was checked?
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750512.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
Both. You can see the logic in the base class
"AbstractTokenInterceptor.handleMessage"
Colm.
On Fri, Oct 31, 2014 at 4:30 AM, Malisetti, Ramanjaneyulu <
Ramanjaneyulu.Malisetti@ca.com> wrote:
> Is this (AbstractTokenInterceptor) engaged on client side or server side?
>
> Regards
> Raman
>
>
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Friday, October 31, 2014 12:16 AM
> To: users@cxf.apache.org
> Subject: Re: Username/PWD on STS
>
> Yeah, take a look at the "assertTokens" method here:
>
>
> https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java;hb=HEAD
>
> Obviously you only want to assert the policies if the correct type of
> UsernameToken was received, etc.
>
> Colm.
>
> On Thu, Oct 30, 2014 at 5:21 PM, SRog <sr...@outlook.de> wrote:
>
> > Hey there,
> > now I got the following fault:
> >
> > <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> > <soap:Body>
> > <soap:Fault>
> > <faultcode>soap:Server</faultcode>
> > <faultstring>These policy alternatives can not be satisfied:
> > {
> > http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTo
> > kens
> > {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameTok
> > en
> > </faultstring>
> > </soap:Fault>
> > </soap:Body>
> > </soap:Envelope>
> >
> > This is what you meant when talking about policy validation stage will
> > fail?
> >
> > When I take a look at DefaultCryptoCoverageChecker I do not see the
> > right place where I could add the assertion. Is there an example how I
> > could do this?
> >
> > Thanks,
> > SRog
> >
> >
> >
> >
> > --
> > View this message in context:
> > http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750471.
> > html Sent from the cxf-user mailing list archive at Nabble.com.
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Username/PWD on STS
Posted by "Malisetti, Ramanjaneyulu" <Ra...@ca.com>.
Is this (AbstractTokenInterceptor) engaged on client side or server side?
Regards
Raman
-----Original Message-----
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, October 31, 2014 12:16 AM
To: users@cxf.apache.org
Subject: Re: Username/PWD on STS
Yeah, take a look at the "assertTokens" method here:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java;hb=HEAD
Obviously you only want to assert the policies if the correct type of UsernameToken was received, etc.
Colm.
On Thu, Oct 30, 2014 at 5:21 PM, SRog <sr...@outlook.de> wrote:
> Hey there,
> now I got the following fault:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>These policy alternatives can not be satisfied:
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTo
> kens
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameTok
> en
> </faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
>
> This is what you meant when talking about policy validation stage will
> fail?
>
> When I take a look at DefaultCryptoCoverageChecker I do not see the
> right place where I could add the assertion. Is there an example how I
> could do this?
>
> Thanks,
> SRog
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750471.
> html Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
Yeah, take a look at the "assertTokens" method here:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java;hb=HEAD
Obviously you only want to assert the policies if the correct type of
UsernameToken was received, etc.
Colm.
On Thu, Oct 30, 2014 at 5:21 PM, SRog <sr...@outlook.de> wrote:
> Hey there,
> now I got the following fault:
>
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
> <soap:Body>
> <soap:Fault>
> <faultcode>soap:Server</faultcode>
> <faultstring>These policy alternatives can not be satisfied:
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameToken
> </faultstring>
> </soap:Fault>
> </soap:Body>
> </soap:Envelope>
>
> This is what you meant when talking about policy validation stage will
> fail?
>
> When I take a look at DefaultCryptoCoverageChecker I do not see the right
> place where I could add the assertion. Is there an example how I could do
> this?
>
> Thanks,
> SRog
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750471.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hey there,
now I got the following fault:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<soap:Fault>
<faultcode>soap:Server</faultcode>
<faultstring>These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameToken</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>
This is what you meant when talking about policy validation stage will fail?
When I take a look at DefaultCryptoCoverageChecker I do not see the right
place where I could add the assertion. Is there an example how I could do
this?
Thanks,
SRog
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750471.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
Yes that could work. You could use the WSS4JInInterceptor to handle
processing the Signature. You would need to extend the
DefaultCryptoCoverageChecker though to assert the policies, or else the
policy validation stage will fail.
Colm.
On Thu, Oct 30, 2014 at 8:05 AM, SRog <sr...@outlook.de> wrote:
> Hi Colm,
> thanks for your response.
> I read somting about WSS4JInInterceptor together with
> DefaultCryptoCoverageChecker to check a signature.
>
> Could this be a solution, too?
>
> SRog
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750433.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hi Colm,
thanks for your response.
I read somting about WSS4JInInterceptor together with
DefaultCryptoCoverageChecker to check a signature.
Could this be a solution, too?
SRog
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750433.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
Normally, a "SupportingTokens" policy comes with a security binding policy,
one of either TransportBinding, AsymmetricBinding or SymmetricBinding.
However, it is also possible to have a SupportingTokens policy without a
security binding. This use-case is handled by separate code. Currently, we
support UsernameTokens, KerberosTokens and SAMLTokens as SupportingTokens.
We don't support the X509Token use-case.
I recommend starting by getting a test working with a SupportingToken
UsernameToken, and then debug through the CXF security runtime to see how
this is handled.
Colm.
On Mon, Oct 27, 2014 at 2:13 PM, SRog <sr...@outlook.de> wrote:
> Hi Colm,
> thanks for your response.
> Sorry, I didn't quite understand. If I take a look at the examples I found
> on the internet, there is no interceptor written for X.509. What is the
> security binding you are describing? Do you have an example how I have to
> do
> it?
>
> Thanks,
> SRog
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750298.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hi Colm,
thanks for your response.
Sorry, I didn't quite understand. If I take a look at the examples I found
on the internet, there is no interceptor written for X.509. What is the
security binding you are describing? Do you have an example how I have to do
it?
Thanks,
SRog
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750298.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
You could try with a more recent version of CXF. There some fixes based
around policy alternatives that didn't make it into CXF 2.6.6 which is what
you are using (iirc).
Secondly, you will need to write an interceptor to assert the appropriate
policies for the X.509 case. The main policy driven code in CXF only kicks
in when there is a security binding. However, there are separate
non-binding interceptors to work with USernameTokens, Kerberos + SAML
tokens. Not X.509 tokens though.
Colm.
On Wed, Oct 22, 2014 at 12:16 PM, SRog <sr...@outlook.de> wrote:
> Hi Colm,
> I took the next steps to get things working. The authentication with
> username and pwd works on STS. Now I have to get x.509 authentication
> working, too.
>
> The Policy in WSDL looks like this:
>
> <sp:SupportingTokens
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <wsp:ExactlyOne>
>
> <wsp:All>
>
> <sp:UsernameToken wsu:Id="BiPROBasicToken"/>
> </wsp:All>
>
> <wsp:All>
>
> <sp:X509Token
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
>
> <wsp:Policy>
>
> <sp:WssX509V3Token11/>
>
> </wsp:Policy>
>
> </sp:X509Token>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </sp:SupportingTokens>
>
> The configuration in cxf-servlet.xml:
>
> <jaxws:endpoint id="CXFSTS" implementor="#mySTSProviderBean"
> address="/STS"
> wsdlLocation="/WEB-INF/wsdl/bipro/SecurityTokenService-2.5.0.1.0.wsdl"
> xmlns:ns1="http://www.bipro.net/namespace"
> serviceName="ns1:SecurityTokenService_2.5.0.1.0"
> endpointName="ns1:UserPasswordLogin">
>
> <jaxws:properties>
> <entry key="ws-security.callback-handler"
> value="sts.PasswordCallbackHandler" />
> <entry key="ws-security.signature.properties"
> value="stsKeystore.properties" />
> <entry key="ws-security.signature.username"
> value="test-zertifikat" />
> <entry key="ws-security.encryption.username"
> value="useReqSigCert" />
> </jaxws:properties>
> <jaxws:features>
> <logging xmlns="http://cxf.apache.org/core" />
> <ref bean="transformFeature" />
> </jaxws:features>
>
> If I try to access the service with a request like the following, I got the
> message "*These policy alternatives can not be satisfied:
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameToken*"
>
>
> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/
> "
> xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
> <soapenv:Header>
> <wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> ">
> <wsse:BinarySecurityToken
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> "
> ValueType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
> "
>
> wsu:Id="X509-9BECC0307376C4B7A6141396887568237">MIIDjjCCAnagAwIBAgIFBTaKnOswDQYJKoZIhvcNAQEFBQAwPjELMAkGA1UEBhMCREUxFjAUBgNVBAoTDUFsbGlhbnogR3JvdXAxFzAVBgNVBAMTDkFsbGlhbnogVXNlckNBMB4XDTEzMDIyODE1MTM0MloXDTE1MDIyODE1MTM0MlowUjELMAkGA1UEBhMCREUxEDAOBgNVBAoTB0FsbGlhbnoxFTATBgNVBAsTDE1ha2xlcnBvcnRhbDEaMBgGA1UEAxMRUm9iZXJ0IEZyZWlsaW5nZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/s+UF8S6imHKg9y31GdzvcML6XoDCjgzzv2IVbVFD+33pSuf4KSWjctcSng6TtfxtaWHZlbAMk3PdD9vCKJgi7Mm9Fnxw33e9z5dolpZ5WUCkfiIFl8cH8YbTKLUDwU5zYNnYSpYDYzmrs7hSDWStnssaryi+YdtpZXUd4RiZrWi2DjfXmRHxH0yO7mJwSzotxjdJaJSWhMvJ5HAyhUDD9vfnSkT24riXiSQQtKE0Jf22xlZSgown98u0V2wEDjOnEklyjQkx0NqVXrJuZ2ave3HwhmGLHqXtr2jMSbZf2hGrWCWbleE2sqMDu5UFsVRikoi7Z2WnXzXoBXzNThM/AgMBAAGjfzB9MA4GA1UdDwEB/wQEAwIHgDAfBgNVHSMEGDAWgBTexNb/epBIwBRzv/5vG7L09Yj4bDATBgNVHSUEDDAKBggrBgEFBQcDAjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vcm9vdGNhLmFsbGlhbnouY29tL3VzZXJjYS5jcmwwDQYJKoZIhvcNAQEFBQADggEBAFjzt/0e53CECiTnI6zQgbFOG7HiClvAaQykukdwIDuCJQpBjr158H/NMBpJEWV+dzRx3ZCl4KkvNPw3PhsqP98G42L+ZPTBtwVCtBwjGqFmXTncQ64A7bu8uLkJJz7ubjlXrLt04tFTSeu8O4UbQgv8M8FD+vm2Nf7FvKLwcFJcKPq92uJ8X2GoImbm88BVLLzstiBmJzKDMs/ZnhErPd/d6Sjl/B6JTAfcwZNuI2D+wBPCDj2xZI0q4rfJZHaBf+d97rjn1dfY9HdCYsY0wi3G0eYG7aNeW3iNkeQ3tnaUg4h+QqDKFBCi36A436cfqpQis3sPzNiqJBWYhDNh32U=</wsse:BinarySecurityToken>
> <ds:Signature Id="SIG-39"
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
> <ds:SignedInfo>
> <ds:CanonicalizationMethod
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
> <ec:InclusiveNamespaces PrefixList="soapenv wst"
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:CanonicalizationMethod>
> <ds:SignatureMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
> <ds:Reference URI="#id-38">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
> <ec:InclusiveNamespaces PrefixList="wst"
> xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <ds:DigestValue>3AEvtITIY5+7+G5NVea7HCOcsD0=</ds:DigestValue>
> </ds:Reference>
> <ds:Reference URI="#TS-37">
> <ds:Transforms>
> <ds:Transform
> Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
> <ec:InclusiveNamespaces PrefixList="wsse soapenv
> wst" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
> </ds:Transform>
> </ds:Transforms>
> <ds:DigestMethod
> Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
>
> <ds:DigestValue>XzpIOxUqhq6GObJrWn3U24KOP4M=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
>
>
> <ds:SignatureValue>CsPndMeeOv4XaHa9dsoWs80t8L6O2kMSZgJG1MTqa7FCKomYvPdQbhJc9bg//RcQFsM1E2ujjInn
>
> moi70YYpld5JvFZvVnhC5i/wPCJ63ZfFIjtp5H36o4StfJB4q03vmfgF+qH7skq3P6PWbDt1QtLF
>
> 2KjuEx15nNyJU0s4OOBje5FYx4KqVSrdJeo4oqUvjML5jcEVd/Ymj4Oy0fydEHNkSt52WI8zaiB0
>
> Du0ZfEIrwFJe8zrhxBQNGWJoHRo4LJ2Be5j97FttyVtTUbxsfJIPvZAsDAl222100y+xUDUpfChy
> ZcRDqW8gE9/aU+Y9tTdIy7i//bfKvi5YNQGbdw==</ds:SignatureValue>
> <ds:KeyInfo Id="KI-9BECC0307376C4B7A6141396887568238">
> <wsse:SecurityTokenReference
> wsu:Id="STR-9BECC0307376C4B7A6141396887568239">
> <wsse:Reference
> URI="#X509-9BECC0307376C4B7A6141396887568237"
> ValueType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3
> "/>
> </wsse:SecurityTokenReference>
> </ds:KeyInfo>
> </ds:Signature>
> <wsu:Timestamp wsu:Id="TS-37">
> <wsu:Created>2014-10-22T09:07:55.682Z</wsu:Created>
> <wsu:Expires>2014-10-22T11:54:35.682Z</wsu:Expires>
> </wsu:Timestamp>
> </wsse:Security>
> </soapenv:Header>
> <soapenv:Body wsu:Id="id-38"
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> ">
> <wst:RequestSecurityToken>
>
> <wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> </wst:TokenType>
>
> <wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue
> </wst:RequestType>
> </wst:RequestSecurityToken>
> </soapenv:Body>
> </soapenv:Envelope>
>
> Something I missed in configuration?
>
> Thanks,
> SRog
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750188.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hi Colm,
I took the next steps to get things working. The authentication with
username and pwd works on STS. Now I have to get x.509 authentication
working, too.
The Policy in WSDL looks like this:
<sp:SupportingTokens
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<wsp:ExactlyOne>
<wsp:All>
<sp:UsernameToken wsu:Id="BiPROBasicToken"/>
</wsp:All>
<wsp:All>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssX509V3Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
</sp:SupportingTokens>
The configuration in cxf-servlet.xml:
<jaxws:endpoint id="CXFSTS" implementor="#mySTSProviderBean"
address="/STS"
wsdlLocation="/WEB-INF/wsdl/bipro/SecurityTokenService-2.5.0.1.0.wsdl"
xmlns:ns1="http://www.bipro.net/namespace"
serviceName="ns1:SecurityTokenService_2.5.0.1.0"
endpointName="ns1:UserPasswordLogin">
<jaxws:properties>
<entry key="ws-security.callback-handler"
value="sts.PasswordCallbackHandler" />
<entry key="ws-security.signature.properties"
value="stsKeystore.properties" />
<entry key="ws-security.signature.username"
value="test-zertifikat" />
<entry key="ws-security.encryption.username"
value="useReqSigCert" />
</jaxws:properties>
<jaxws:features>
<logging xmlns="http://cxf.apache.org/core" />
<ref bean="transformFeature" />
</jaxws:features>
If I try to access the service with a request like the following, I got the
message "*These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SupportingTokens
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}UsernameToken*"
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
<soapenv:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wsse:BinarySecurityToken
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"
wsu:Id="X509-9BECC0307376C4B7A6141396887568237">MIIDjjCCAnagAwIBAgIFBTaKnOswDQYJKoZIhvcNAQEFBQAwPjELMAkGA1UEBhMCREUxFjAUBgNVBAoTDUFsbGlhbnogR3JvdXAxFzAVBgNVBAMTDkFsbGlhbnogVXNlckNBMB4XDTEzMDIyODE1MTM0MloXDTE1MDIyODE1MTM0MlowUjELMAkGA1UEBhMCREUxEDAOBgNVBAoTB0FsbGlhbnoxFTATBgNVBAsTDE1ha2xlcnBvcnRhbDEaMBgGA1UEAxMRUm9iZXJ0IEZyZWlsaW5nZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC/s+UF8S6imHKg9y31GdzvcML6XoDCjgzzv2IVbVFD+33pSuf4KSWjctcSng6TtfxtaWHZlbAMk3PdD9vCKJgi7Mm9Fnxw33e9z5dolpZ5WUCkfiIFl8cH8YbTKLUDwU5zYNnYSpYDYzmrs7hSDWStnssaryi+YdtpZXUd4RiZrWi2DjfXmRHxH0yO7mJwSzotxjdJaJSWhMvJ5HAyhUDD9vfnSkT24riXiSQQtKE0Jf22xlZSgown98u0V2wEDjOnEklyjQkx0NqVXrJuZ2ave3HwhmGLHqXtr2jMSbZf2hGrWCWbleE2sqMDu5UFsVRikoi7Z2WnXzXoBXzNThM/AgMBAAGjfzB9MA4GA1UdDwEB/wQEAwIHgDAfBgNVHSMEGDAWgBTexNb/epBIwBRzv/5vG7L09Yj4bDATBgNVHSUEDDAKBggrBgEFBQcDAjA1BgNVHR8ELjAsMCqgKKAmhiRodHRwOi8vcm9vdGNhLmFsbGlhbnouY29tL3VzZXJjYS5jcmwwDQYJKoZIhvcNAQEFBQADggEBAFjzt/0e53CECiTnI6zQgbFOG7HiClvAaQykukdwIDuCJQpBjr158H/NMBpJEWV+dzRx3ZCl4KkvNPw3PhsqP98G42L+ZPTBtwVCtBwjGqFmXTncQ64A7bu8uLkJJz7ubjlXrLt04tFTSeu8O4UbQgv8M8FD+vm2Nf7FvKLwcFJcKPq92uJ8X2GoImbm88BVLLzstiBmJzKDMs/ZnhErPd/d6Sjl/B6JTAfcwZNuI2D+wBPCDj2xZI0q4rfJZHaBf+d97rjn1dfY9HdCYsY0wi3G0eYG7aNeW3iNkeQ3tnaUg4h+QqDKFBCi36A436cfqpQis3sPzNiqJBWYhDNh32U=</wsse:BinarySecurityToken>
<ds:Signature Id="SIG-39"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="soapenv wst"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:CanonicalizationMethod>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#id-38">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="wst"
xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>3AEvtITIY5+7+G5NVea7HCOcsD0=</ds:DigestValue>
</ds:Reference>
<ds:Reference URI="#TS-37">
<ds:Transforms>
<ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
<ec:InclusiveNamespaces PrefixList="wsse soapenv
wst" xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>XzpIOxUqhq6GObJrWn3U24KOP4M=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>CsPndMeeOv4XaHa9dsoWs80t8L6O2kMSZgJG1MTqa7FCKomYvPdQbhJc9bg//RcQFsM1E2ujjInn
moi70YYpld5JvFZvVnhC5i/wPCJ63ZfFIjtp5H36o4StfJB4q03vmfgF+qH7skq3P6PWbDt1QtLF
2KjuEx15nNyJU0s4OOBje5FYx4KqVSrdJeo4oqUvjML5jcEVd/Ymj4Oy0fydEHNkSt52WI8zaiB0
Du0ZfEIrwFJe8zrhxBQNGWJoHRo4LJ2Be5j97FttyVtTUbxsfJIPvZAsDAl222100y+xUDUpfChy
ZcRDqW8gE9/aU+Y9tTdIy7i//bfKvi5YNQGbdw==</ds:SignatureValue>
<ds:KeyInfo Id="KI-9BECC0307376C4B7A6141396887568238">
<wsse:SecurityTokenReference
wsu:Id="STR-9BECC0307376C4B7A6141396887568239">
<wsse:Reference
URI="#X509-9BECC0307376C4B7A6141396887568237"
ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
<wsu:Timestamp wsu:Id="TS-37">
<wsu:Created>2014-10-22T09:07:55.682Z</wsu:Created>
<wsu:Expires>2014-10-22T11:54:35.682Z</wsu:Expires>
</wsu:Timestamp>
</wsse:Security>
</soapenv:Header>
<soapenv:Body wsu:Id="id-38"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
<wst:RequestSecurityToken>
<wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType>
<wst:RequestType>http://schemas.xmlsoap.org/ws/2005/02/trust/Issue</wst:RequestType>
</wst:RequestSecurityToken>
</soapenv:Body>
</soapenv:Envelope>
Something I missed in configuration?
Thanks,
SRog
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750188.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Thanks Colm,
one step forward.
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750115.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
The problem is that the "sp" namespace is defined incorrectly in the STS
WSDL. It is currently:
xmlns:sp="
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
"
It should be:
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
That fixes the policy alternative error. There is an error associated with
the TransformFeature stuff as well, but at least this fix gets you a bit
further.
Colm.
On Tue, Oct 21, 2014 at 10:06 AM, SRog <sr...@outlook.de> wrote:
> Hi Colm,
> lets have a new try.
>
> STS.zip <http://cxf.547215.n5.nabble.com/file/n5750105/STS.zip>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750105.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hi Colm,
lets have a new try.
STS.zip <http://cxf.547215.n5.nabble.com/file/n5750105/STS.zip>
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750105.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
I don't see an original SecurityTokenServiceProvider in the file. Please
send me a test-case that I can run without having to edit things.
Colm.
On Tue, Oct 21, 2014 at 9:44 AM, SRog <sr...@outlook.de> wrote:
> Ah sorry,
> please uncomment the original SecurityTokenServiceProvider in
> cxf-servlet.xml and comment BiPROSecurityTokenServiceProvider. The error is
> the same in both cases.
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750100.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Ah sorry,
please uncomment the original SecurityTokenServiceProvider in
cxf-servlet.xml and comment BiPROSecurityTokenServiceProvider. The error is
the same in both cases.
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750100.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
I get the following error in Tomcat:
java.lang.ClassNotFoundException:
de.helvetia.helbs.security.sts.BiPROSecurityTokenServiceProvider
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
On Tue, Oct 21, 2014 at 8:19 AM, SRog <sr...@outlook.de> wrote:
> Hi Colm,
> I added a testproject to show what I am doing. There is a soapui project in
> there, too.
>
> STS.zip <http://cxf.547215.n5.nabble.com/file/n5750091/STS.zip>
>
> Maybe you could take a look at it.
>
>
> Thank you,
> SRog
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750091.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Username/PWD on STS
Posted by SRog <sr...@outlook.de>.
Hi Colm,
I added a testproject to show what I am doing. There is a soapui project in
there, too.
STS.zip <http://cxf.547215.n5.nabble.com/file/n5750091/STS.zip>
Maybe you could take a look at it.
Thank you,
SRog
--
View this message in context: http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076p5750091.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Username/PWD on STS
Posted by Colm O hEigeartaigh <co...@apache.org>.
Do you have a test-case that I can take a look at?
Colm.
On Mon, Oct 20, 2014 at 5:27 PM, SRog <sr...@outlook.de> wrote:
> Hi,
> I try to configure a simple STS which satisfys the need of BiPRO (a
> standard
> to transfer insurance data) with Secure Conversation.
>
> In WSDL of the STS the BiPRO defines a policy like this for
> username/password authentication:
>
> <wsp:Policy wsu:Id="BiPROAuthSecurityPolicy"
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
> <wsp:ExactlyOne>
> <wsp:All>
>
> <sp:TransportBinding>
> <wsp:Policy>
> <sp:TransportToken>
> <wsp:Policy>
> <sp:HttpsToken RequireClientCertificate="false"/>
> </wsp:Policy>
> </sp:TransportToken>
> </wsp:Policy>
> </sp:TransportBinding>
>
> <sp:SupportingTokens>
> <wsp:Policy>
> <wsp:ExactlyOne>
>
> <wsp:All>
> <sp:UsernameToken wsu:Id="BiPROBasicToken"/>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> </sp:SupportingTokens>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
>
> Then I configured the service in cxf-servlet.xml like this:
>
> ...
> <bean id="mySTSProviderBean"
>
> class="org.apache.cxf.ws.security.sts.provider.SecurityTokenServiceProvider">
> <property name="issueSingleOperation"
> ref="transportIssueDelegate"/>
> <property name="validateOperation"
> ref="transportValidateDelegate"/>
> <property name="cancelOperation" ref="transportCancelDelegate"/>
> </bean>
>
> <bean id="transportIssueDelegate"
> class="org.apache.cxf.sts.operation.TokenIssueOperation">
> <property name="tokenProviders" ref="transportTokenProviders"/>
> <property name="services" ref="transportService"/>
> <property name="stsProperties" ref="transportSTSProperties"/>
> <property name="tokenStore" ref="defaultTokenStore"/>
> <property name="returnReferences" value="false" />
> </bean>
>
> <bean id="transportValidateDelegate"
> class="org.apache.cxf.sts.operation.TokenValidateOperation">
> <property name="tokenProviders" ref="transportTokenProviders"/>
> <property name="tokenValidators" ref="transportTokenValidators"/>
> <property name="stsProperties" ref="transportSTSProperties"/>
> <property name="tokenStore" ref="defaultTokenStore"/>
> </bean>
>
> <bean id="transportCancelDelegate"
> class="org.apache.cxf.sts.operation.TokenCancelOperation">
> <property name="tokenCancellers" ref="transportTokenCancellers"/>
> <property name="stsProperties" ref="transportSTSProperties"/>
> <property name="tokenStore" ref="defaultTokenStore"/>
> </bean>
>
> <util:list id="transportTokenProviders">
> <ref bean="transportSCTProvider"/>
> </util:list>
> <util:list id="transportTokenValidators">
> <ref bean="transportSCTValidator"/>
> </util:list>
> <util:list id="transportTokenCancellers">
> <ref bean="transportSCTCanceller"/>
> </util:list>
>
> <bean id="transportSCTProvider" class="sts.BiPROTokenProvider">
> <property name="returnEntropy" value="false" />
> </bean>
> <bean id="transportSCTValidator"
> class="org.apache.cxf.sts.token.validator.SCTValidator">
> </bean>
> <bean id="transportSCTCanceller"
> class="org.apache.cxf.sts.token.canceller.SCTCanceller">
> </bean>
> <bean id="transportService"
> class="org.apache.cxf.sts.service.StaticService">
> <property name="endpoints" ref="transportEndpoints"/>
> </bean>
> <util:list id="transportEndpoints">
> <value>http://localhost:(\d)*/doubleit/services/doubleit.*
> </value>
> </util:list>
>
> <bean id="defaultTokenStore"
> class="org.apache.cxf.sts.cache.DefaultInMemoryTokenStore">
> </bean>
>
> <bean id="encProperties"
> class="org.apache.cxf.sts.service.EncryptionProperties">
> <property name="encryptionAlgorithm"
> value="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
> </bean>
>
> <bean id="transportSTSProperties"
> class="org.apache.cxf.sts.StaticSTSProperties">
> </bean>
>
> <bean id="sctInterceptor"
> class="org.apache.cxf.sts.interceptor.SCTInInterceptor"/>
> <bean id="sctOutInterceptor"
> class="org.apache.cxf.sts.interceptor.SCTOutInterceptor"/>
>
> <jaxws:endpoint id="CXFSTS" implementor="#mySTSProviderBean"
> address="/STS"
> wsdlLocation="/WEB-INF/wsdl/bipro/SecurityTokenService-2.5.0.1.0.wsdl"
> xmlns:ns1="http://www.bipro.net/namespace"
> serviceName="ns1:SecurityTokenService_2.5.0.1.0"
> endpointName="ns1:UserPasswordLogin">
> <jaxws:inInterceptors>
> <ref bean="sctInterceptor"/>
> </jaxws:inInterceptors>
> <jaxws:outInterceptors>
> <ref bean="sctOutInterceptor"/>
> </jaxws:outInterceptors>
> <jaxws:outFaultInterceptors>
> <ref bean="sctOutInterceptor"/>
> </jaxws:outFaultInterceptors>
> <jaxws:properties>
> <entry key="ws-security.callback-handler"
> value="sts.PasswordCallbackHandler" />
> <entry key="org.apache.cxf.ws.security.tokenstore.TokenStore">
> <ref bean="defaultTokenStore"/>
> </entry>
> </jaxws:properties>
> <jaxws:features>
> <logging xmlns="http://cxf.apache.org/core" />
> <ref bean="transformFeature" />
> </jaxws:features>
> </jaxws:endpoint>
>
> If I try to acces the services with a request containing username and pwd I
> got the message "*None of the policy alternatives can be satisfied.*"
>
> The request:
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
> xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust">
> <soap:Header>
> <wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> ">
> <wsse:UsernameToken
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> xmlns:bipro="http://www.bipro.net/namespace">
> <wsse:Username>alice</wsse:Username>
> <wsse:Password
> Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-387
> username-token-profile-1.0#PasswordText">clarinet</wsse:Password>
> </wsse:UsernameToken>
> </wsse:Security>
> </soap:Header>
> <soap:Body>
> <wst:RequestSecurityToken
> xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
>
> <wst:RequestType>http://docs.oasis-open.org/ws-sx/ws-trust/200512/Issue
> </wst:RequestType>
>
> <wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct
> </wst:TokenType>
> </wst:RequestSecurityToken>
> <soap:Body>
> <soap:Envelope>
>
> What I have to configure in cxf-servlet.xml to get things working? I could
> not change the WSDL while this is standard BiPRO.
>
> Thanks for your response,
> SRog
>
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Username-PWD-on-STS-tp5750076.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com