RE: Issue with CXF-2.5.2 regarding UsernameToken
Hello,
I don't understand because the 2 ways of coding seem feasible according the
article at: http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile
So do you mean that the client code provided in this article is wrong ?
Best Regards
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: vendredi 3 février 2012 18:17
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
Hi Francois,
In the code you have that works, you are (correctly) setting the username via
the tag ws-security.username. This is defined in the following documentation
Configuring the extra properties:
http://cxf.apache.org/docs/ws-securitypolicy.html
However in the code that does not work, you are setting the username via the
tag WSHandlerConstants.USER. This is a configuration tag used by WSS4J and it
works with CXF for the non-WS-SecurityPolicy use-case.
As you are using WS-SecurityPolicy (TransportBindingHandler), it does not work.
Colm.
On Fri, Feb 3, 2012 at 5:10 PM, COURTAULT Francois
francois.courta...@gemalto.com wrote:
Hello everybody,
For UsernameToken, in my client code I have used the following code which is:
MapString, Object ctx = ((BindingProvider)
port).getRequestContext();
ctx.put(ws-security.username, myusername);
ctx.put(ws-security.password, mypassword); It
works :)
But if I replace this one with:
MapString, Object outProps = new HashMapString,
Object();
outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
outProps.put(WSHandlerConstants.USER, myusername);
outProps.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCB.class.getName());
WSS4JOutInterceptor wssOut = new
WSS4JOutInterceptor(outProps);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(port);
Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(wssOut);
with
public class ClientPasswordCB implements CallbackHandler {
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
// TODO Auto-generated method stub
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (myusername.equals(pc.getIdentifier())) {
pc.setPassword(mypassword);
}
}
}
I got the following error:
févr. 2012 18:04:50 org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
ATTENTION: Interceptor for
{http://gemalto/test/ws/}SimpleWSEJBService#{http://gemalto/test/ws/}h
elloWorld has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: No username available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.TransportBindingHandle
r.handleBinding(TransportBindingHandler.java:151)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Policy
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInte
rceptor.java:158)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Policy
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInte
rceptor.java:88)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:263)
at
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134
)
at $Proxy27.helloWorld(Unknown Source)
at
com.gemalto.test.cxf.TestSimpleWSCXFClientHttpsUsername.main(TestSimpl
eWSCXFClientHttpsUsername.java:85)
Caused by: org.apache.cxf.ws.policy.PolicyException: No username
available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.policyNotAsserted(AbstractBindingBuilder.java:301)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.addUsernameToken(AbstractBindingBuilder.java:804)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.handleSupportingTokens(AbstractBindingBuilder.java:475)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.handleSupportingTokens(AbstractBindingBuilder.java:462)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.TransportBindingHandle
r.handleNonEndorsingSupportingTokens(TransportBindingHandler.java:200)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.TransportBindingHandle
r.handleBinding
Re: Issue with CXF-2.5.2 regarding UsernameToken
The only reference to WSHandlerConstants.USER in the blog article is in
the case where you're using WSS4J interceptors and not
WS-SecurityPolicy. Remember just before that code block the article
says to activate the section of the code depending on the method you're
using--WSS4J interceptors or WS-SecurityPolicy.
Glen
On 02/03/2012 01:03 PM, COURTAULT Francois wrote:
Hello,
I don't understand because the 2 ways of coding seem feasible according the
article at: http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile
So do you mean that the client code provided in this article is wrong ?
Best Regards
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: vendredi 3 février 2012 18:17
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
Hi Francois,
In the code you have that works, you are (correctly) setting the username via the tag
ws-security.username. This is defined in the following documentation Configuring
the extra properties:
http://cxf.apache.org/docs/ws-securitypolicy.html
However in the code that does not work, you are setting the username via the
tag WSHandlerConstants.USER. This is a configuration tag used by WSS4J and it
works with CXF for the non-WS-SecurityPolicy use-case.
As you are using WS-SecurityPolicy (TransportBindingHandler), it does not work.
Colm.
On Fri, Feb 3, 2012 at 5:10 PM, COURTAULT
Francoisfrancois.courta...@gemalto.com wrote:
Hello everybody,
For UsernameToken, in my client code I have used the following code which is:
MapString, Object ctx = ((BindingProvider)
port).getRequestContext();
ctx.put(ws-security.username, myusername);
ctx.put(ws-security.password, mypassword); It
works :)
But if I replace this one with:
MapString, Object outProps = new HashMapString,
Object();
outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
outProps.put(WSHandlerConstants.USER, myusername);
outProps.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCB.class.getName());
WSS4JOutInterceptor wssOut = new
WSS4JOutInterceptor(outProps);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(port);
Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(wssOut);
with
public class ClientPasswordCB implements CallbackHandler {
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
// TODO Auto-generated method stub
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (myusername.equals(pc.getIdentifier())) {
pc.setPassword(mypassword);
}
}
}
I got the following error:
févr. 2012 18:04:50 org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
ATTENTION: Interceptor for
{http://gemalto/test/ws/}SimpleWSEJBService#{http://gemalto/test/ws/}h
elloWorld has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: No username available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.TransportBindingHandle
r.handleBinding(TransportBindingHandler.java:151)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Policy
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInte
rceptor.java:158)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Policy
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInte
rceptor.java:88)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercepto
rChain.java:263)
at
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:134
)
at $Proxy27.helloWorld(Unknown Source)
at
com.gemalto.test.cxf.TestSimpleWSCXFClientHttpsUsername.main(TestSimpl
eWSCXFClientHttpsUsername.java:85)
Caused by: org.apache.cxf.ws.policy.PolicyException: No username
available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.policyNotAsserted(AbstractBindingBuilder.java:301)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.addUsernameToken(AbstractBindingBuilder.java:804)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
.handleSupportingTokens(AbstractBindingBuilder.java:475)
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder
RE: Issue with CXF-2.5.2 regarding UsernameToken
Hello,
OK but how do you choose the method WSS4J interceptors or WS-SecurityPolicy ?
Best Regards.
-Original Message-
From: Glen Mazza [mailto:gma...@talend.com]
Sent: vendredi 3 février 2012 19:29
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
The only reference to WSHandlerConstants.USER in the blog article is in the
case where you're using WSS4J interceptors and not WS-SecurityPolicy. Remember
just before that code block the article says to activate the section of the
code depending on the method you're using--WSS4J interceptors or
WS-SecurityPolicy.
Glen
On 02/03/2012 01:03 PM, COURTAULT Francois wrote:
Hello,
I don't understand because the 2 ways of coding seem feasible
according the article at:
http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile
So do you mean that the client code provided in this article is wrong ?
Best Regards
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: vendredi 3 février 2012 18:17
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
Hi Francois,
In the code you have that works, you are (correctly) setting the username via
the tag ws-security.username. This is defined in the following
documentation Configuring the extra properties:
http://cxf.apache.org/docs/ws-securitypolicy.html
However in the code that does not work, you are setting the username via the
tag WSHandlerConstants.USER. This is a configuration tag used by WSS4J and it
works with CXF for the non-WS-SecurityPolicy use-case.
As you are using WS-SecurityPolicy (TransportBindingHandler), it does not
work.
Colm.
On Fri, Feb 3, 2012 at 5:10 PM, COURTAULT
Francoisfrancois.courta...@gemalto.com wrote:
Hello everybody,
For UsernameToken, in my client code I have used the following code which is:
MapString, Object ctx = ((BindingProvider)
port).getRequestContext();
ctx.put(ws-security.username, myusername);
ctx.put(ws-security.password, mypassword); It
works :)
But if I replace this one with:
MapString, Object outProps = new HashMapString,
Object();
outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
outProps.put(WSHandlerConstants.USER, myusername);
outProps.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCB.class.getName());
WSS4JOutInterceptor wssOut = new
WSS4JOutInterceptor(outProps);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(port);
Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(wssOut);
with
public class ClientPasswordCB implements CallbackHandler {
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
// TODO Auto-generated method stub
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (myusername.equals(pc.getIdentifier())) {
pc.setPassword(mypassword);
}
}
}
I got the following error:
févr. 2012 18:04:50 org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
ATTENTION: Interceptor for
{http://gemalto/test/ws/}SimpleWSEJBService#{http://gemalto/test/ws/}
h elloWorld has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: No username available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.TransportBindingHandl
e
r.handleBinding(TransportBindingHandler.java:151)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Polic
y
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInt
e
rceptor.java:158)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Polic
y
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInt
e
rceptor.java:88)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
o
rChain.java:263)
at
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:13
4
)
at $Proxy27.helloWorld(Unknown Source)
at
com.gemalto.test.cxf.TestSimpleWSCXFClientHttpsUsername.main(TestSimp
l
eWSCXFClientHttpsUsername.java:85)
Caused by: org.apache.cxf.ws.policy.PolicyException: No username
available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilde
Re: Issue with CXF-2.5.2 regarding UsernameToken
Once *you* decide which one you want--your choice but if the WSDL
doesn't have security policy statements it will need to be WSS4J--just
follow my blog entry, making changes as explained in the tutorial
depending on the option you wanted. For example, the code segment
referenced had instructions just before it telling you to comment out /
uncomment the particular segment depending on the method you chose.
Glen
On 02/03/2012 01:33 PM, COURTAULT Francois wrote:
Hello,
OK but how do you choose the method WSS4J interceptors or WS-SecurityPolicy ?
Best Regards.
-Original Message-
From: Glen Mazza [mailto:gma...@talend.com]
Sent: vendredi 3 février 2012 19:29
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
The only reference to WSHandlerConstants.USER in the blog article is in the
case where you're using WSS4J interceptors and not WS-SecurityPolicy. Remember
just before that code block the article says to activate the section of the
code depending on the method you're using--WSS4J interceptors or
WS-SecurityPolicy.
Glen
On 02/03/2012 01:03 PM, COURTAULT Francois wrote:
Hello,
I don't understand because the 2 ways of coding seem feasible
according the article at:
http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile
So do you mean that the client code provided in this article is wrong ?
Best Regards
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: vendredi 3 février 2012 18:17
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
Hi Francois,
In the code you have that works, you are (correctly) setting the username via the tag
ws-security.username. This is defined in the following documentation Configuring
the extra properties:
http://cxf.apache.org/docs/ws-securitypolicy.html
However in the code that does not work, you are setting the username via the
tag WSHandlerConstants.USER. This is a configuration tag used by WSS4J and it
works with CXF for the non-WS-SecurityPolicy use-case.
As you are using WS-SecurityPolicy (TransportBindingHandler), it does not work.
Colm.
On Fri, Feb 3, 2012 at 5:10 PM, COURTAULT
Francoisfrancois.courta...@gemalto.com wrote:
Hello everybody,
For UsernameToken, in my client code I have used the following code which is:
MapString, Object ctx = ((BindingProvider)
port).getRequestContext();
ctx.put(ws-security.username, myusername);
ctx.put(ws-security.password, mypassword); It
works :)
But if I replace this one with:
MapString, Object outProps = new HashMapString,
Object();
outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
outProps.put(WSHandlerConstants.USER, myusername);
outProps.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCB.class.getName());
WSS4JOutInterceptor wssOut = new
WSS4JOutInterceptor(outProps);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(port);
Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(wssOut);
with
public class ClientPasswordCB implements CallbackHandler {
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
// TODO Auto-generated method stub
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (myusername.equals(pc.getIdentifier())) {
pc.setPassword(mypassword);
}
}
}
I got the following error:
févr. 2012 18:04:50 org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
ATTENTION: Interceptor for
{http://gemalto/test/ws/}SimpleWSEJBService#{http://gemalto/test/ws/}
h elloWorld has thrown exception, unwinding now
org.apache.cxf.interceptor.Fault: No username available
at
org.apache.cxf.ws.security.wss4j.policyhandlers.TransportBindingHandl
e
r.handleBinding(TransportBindingHandler.java:151)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Polic
y
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInt
e
rceptor.java:158)
at
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor$Polic
y
BasedWSS4JOutInterceptorInternal.handleMessage(PolicyBasedWSS4JOutInt
e
rceptor.java:88)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseIntercept
o
rChain.java:263)
at
org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:533)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:463)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:366)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:319)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:88
RE: Issue with CXF-2.5.2 regarding UsernameToken
Hello Glen,
First, my WDSL contains policy statements.
I have read again more carefully your article.
Let me know if I have well understood:
- if the WSDL contains policy statements, the WS-SecurityPolicy option is
the preferred approach: right ?
- if the WSDL doesn't contain policy statements, the WSS4J interceptors
option is required: right ?
But does that mean also that you cannot use this option if the WSDL
contains policy statements ?
So, if the answer to above question is yes, the CXF client coding rules are:
- if your WSDL contains policy statements, you have no choice, you have
to use WS-SecurityPolicy option: right ?
- if your WSDL doesn't contains policy statements, you have no choice,
you have to use WSS4J interceptors option: right ?
Best Regards.
-Original Message-
From: Glen Mazza [mailto:gma...@talend.com]
Sent: vendredi 3 février 2012 19:42
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
Once *you* decide which one you want--your choice but if the WSDL doesn't have
security policy statements it will need to be WSS4J--just follow my blog entry,
making changes as explained in the tutorial depending on the option you wanted.
For example, the code segment referenced had instructions just before it
telling you to comment out / uncomment the particular segment depending on the
method you chose.
Glen
On 02/03/2012 01:33 PM, COURTAULT Francois wrote:
Hello,
OK but how do you choose the method WSS4J interceptors or WS-SecurityPolicy ?
Best Regards.
-Original Message-
From: Glen Mazza [mailto:gma...@talend.com]
Sent: vendredi 3 février 2012 19:29
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
The only reference to WSHandlerConstants.USER in the blog article is in the
case where you're using WSS4J interceptors and not WS-SecurityPolicy.
Remember just before that code block the article says to activate the section
of the code depending on the method you're using--WSS4J interceptors or
WS-SecurityPolicy.
Glen
On 02/03/2012 01:03 PM, COURTAULT Francois wrote:
Hello,
I don't understand because the 2 ways of coding seem feasible
according the article at:
http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile
So do you mean that the client code provided in this article is wrong ?
Best Regards
-Original Message-
From: Colm O hEigeartaigh [mailto:cohei...@apache.org]
Sent: vendredi 3 février 2012 18:17
To: users@cxf.apache.org
Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken
Hi Francois,
In the code you have that works, you are (correctly) setting the username
via the tag ws-security.username. This is defined in the following
documentation Configuring the extra properties:
http://cxf.apache.org/docs/ws-securitypolicy.html
However in the code that does not work, you are setting the username via the
tag WSHandlerConstants.USER. This is a configuration tag used by WSS4J and
it works with CXF for the non-WS-SecurityPolicy use-case.
As you are using WS-SecurityPolicy (TransportBindingHandler), it does not
work.
Colm.
On Fri, Feb 3, 2012 at 5:10 PM, COURTAULT
Francoisfrancois.courta...@gemalto.com wrote:
Hello everybody,
For UsernameToken, in my client code I have used the following code which
is:
MapString, Object ctx = ((BindingProvider)
port).getRequestContext();
ctx.put(ws-security.username, myusername);
ctx.put(ws-security.password, mypassword); It
works :)
But if I replace this one with:
MapString, Object outProps = new HashMapString,
Object();
outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
outProps.put(WSHandlerConstants.USER, myusername);
outProps.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCB.class.getName());
WSS4JOutInterceptor wssOut = new
WSS4JOutInterceptor(outProps);
Client client =
org.apache.cxf.frontend.ClientProxy.getClient(port);
Endpoint cxfEndpoint = client.getEndpoint();
cxfEndpoint.getOutInterceptors().add(wssOut);
with
public class ClientPasswordCB implements CallbackHandler {
@Override
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
// TODO Auto-generated method stub
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (myusername.equals(pc.getIdentifier())) {
pc.setPassword(mypassword);
}
}
}
I got the following error:
févr. 2012 18:04:50 org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
ATTENTION: Interceptor for
{http://gemalto/test/ws
Re: Issue with CXF-2.5.2 regarding UsernameToken
On Friday, February 03, 2012 8:02:35 PM COURTAULT Francois wrote: Hello Glen, First, my WDSL contains policy statements. I have read again more carefully your article. Let me know if I have well understood: - if the WSDL contains policy statements, the WS-SecurityPolicy option is the preferred approach: right ? Quite likely the required approach, yes. If the WSDL contains policies and the policy engine is turned on (which is the default starting in CXF 2.3), then the policy based interceptors will be automatically engaged. Using the non-policy based approach may interfere with it. - if the WSDL doesn't contain policy statements, the WSS4J interceptors option is required: right ? You CAN, using configuration, provide a policy attachment that would define a security policy and drive the policy based interceptors that way. Definitely tricky though. But does that mean also that you cannot use this option if the WSDL contains policy statements ? So, if the answer to above question is yes, the CXF client coding rules are: - if your WSDL contains policy statements, you have no choice, you have to use WS-SecurityPolicy option: right ? - if your WSDL doesn't contains policy statements, you have no choice, you have to use WSS4J interceptors option: right ? I think that's the easy answer.The more complete answer is that you COULD use the WSS4J interceptors along with a custom interceptor that assert the various policies and likely remove/skip the policy based things.Definitely more work though. Dan Best Regards. -Original Message- From: Glen Mazza [mailto:gma...@talend.com] Sent: vendredi 3 février 2012 19:42 To: users@cxf.apache.org Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken Once *you* decide which one you want--your choice but if the WSDL doesn't have security policy statements it will need to be WSS4J--just follow my blog entry, making changes as explained in the tutorial depending on the option you wanted. For example, the code segment referenced had instructions just before it telling you to comment out / uncomment the particular segment depending on the method you chose. Glen On 02/03/2012 01:33 PM, COURTAULT Francois wrote: Hello, OK but how do you choose the method WSS4J interceptors or WS-SecurityPolicy ? Best Regards. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Issue with CXF-2.5.2 regarding UsernameToken
On 02/03/2012 02:08 PM, Daniel Kulp wrote: On Friday, February 03, 2012 8:02:35 PM COURTAULT Francois wrote: Hello Glen, First, my WDSL contains policy statements. I have read again more carefully your article. Let me know if I have well understood: - if the WSDL contains policy statements, the WS-SecurityPolicy option is the preferred approach: right ? Quite likely the required approach, yes. If the WSDL contains policies and the policy engine is turned on (which is the default starting in CXF 2.3), then the policy based interceptors will be automatically engaged. Using the non-policy based approach may interfere with it. Clarification: if you *don't* include the cxf-rt-ws-policy dependency (as listed in the blog article), then any WS-Policy statements in the WSDL will be ignored, and in that case you can use the WSS4J interceptor approach to manually add headers. - if the WSDL doesn't contain policy statements, the WSS4J interceptors option is required: right ? You CAN, using configuration, provide a policy attachment that would define a security policy and drive the policy based interceptors that way. Definitely tricky though. But does that mean also that you cannot use this option if the WSDL contains policy statements ? So, if the answer to above question is yes, the CXF client coding rules are: - if your WSDL contains policy statements, you have no choice, you have to use WS-SecurityPolicy option: right ? - if your WSDL doesn't contains policy statements, you have no choice, you have to use WSS4J interceptors option: right ? I think that's the easy answer.The more complete answer is that you COULD use the WSS4J interceptors along with a custom interceptor that assert the various policies and likely remove/skip the policy based things.Definitely more work though. Dan Best Regards. -Original Message- From: Glen Mazza [mailto:gma...@talend.com] Sent: vendredi 3 février 2012 19:42 To: users@cxf.apache.org Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken Once *you* decide which one you want--your choice but if the WSDL doesn't have security policy statements it will need to be WSS4J--just follow my blog entry, making changes as explained in the tutorial depending on the option you wanted. For example, the code segment referenced had instructions just before it telling you to comment out / uncomment the particular segment depending on the method you chose. Glen On 02/03/2012 01:33 PM, COURTAULT Francois wrote: Hello, OK but how do you choose the method WSS4J interceptors or WS-SecurityPolicy ? Best Regards. -- Glen Mazza Talend Community Coders - coders.talend.com blog: www.jroller.com/gmazza
RE: Issue with CXF-2.5.2 regarding UsernameToken
Hello Dan and Glen, Quite likely the required approach, yes. If the WSDL contains policies and the policy engine is turned on (which is the default starting in CXF 2.3), then the policy based interceptors will be automatically engaged. Using the non-policy based approach may interfere with it. Yes, this is what I have seen. Clarification: if you *don't* include the cxf-rt-ws-policy dependency (as listed in the blog article), then any WS-Policy statements in the WSDL will be ignored, and in that case you can use the WSS4J interceptor approach to manually add headers. In fact I don't use maven, I have, in my Eclipse project, included all the jars of the apache-cxf-2.5.2/lib folder. Does that mean that, by doing that, I have included the cxf-rt-ws-policy ? What is the standard classpath for an CXF client ? Now I have another issue: I try to write a client which has to target a Webservice which uses Asymmetric bindings. Again, the WSDL contains policy statements. So according to what you have said, I have to use the SecurityPolicy option in order to not have interference. The problem I have is I haven't found any sample with this option for this kind of configuration :-( I have only found some info at http://cxf.apache.org/docs/ws-securitypolicy.html but the ws-security samples (specially the signing part) available at http://cxf.apache.org/docs/ws-security.html uses the WSS4J interceptors option and not the SecurityPolicy one. Could anybody help me about this issue: find a sample using the SecurityPolicy for X509Token (only signing) ? Best Regards. -Original Message- From: Glen Mazza [mailto:gma...@talend.com] Sent: vendredi 3 février 2012 20:22 To: users@cxf.apache.org Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken On 02/03/2012 02:08 PM, Daniel Kulp wrote: On Friday, February 03, 2012 8:02:35 PM COURTAULT Francois wrote: Hello Glen, First, my WDSL contains policy statements. I have read again more carefully your article. Let me know if I have well understood: - if the WSDL contains policy statements, the WS-SecurityPolicy option is the preferred approach: right ? Quite likely the required approach, yes. If the WSDL contains policies and the policy engine is turned on (which is the default starting in CXF 2.3), then the policy based interceptors will be automatically engaged. Using the non-policy based approach may interfere with it. Clarification: if you *don't* include the cxf-rt-ws-policy dependency (as listed in the blog article), then any WS-Policy statements in the WSDL will be ignored, and in that case you can use the WSS4J interceptor approach to manually add headers. - if the WSDL doesn't contain policy statements, the WSS4J interceptors option is required: right ? You CAN, using configuration, provide a policy attachment that would define a security policy and drive the policy based interceptors that way. Definitely tricky though. But does that mean also that you cannot use this option if the WSDL contains policy statements ? So, if the answer to above question is yes, the CXF client coding rules are: - if your WSDL contains policy statements, you have no choice, you have to use WS-SecurityPolicy option: right ? - if your WSDL doesn't contains policy statements, you have no choice, you have to use WSS4J interceptors option: right ? I think that's the easy answer.The more complete answer is that you COULD use the WSS4J interceptors along with a custom interceptor that assert the various policies and likely remove/skip the policy based things.Definitely more work though. Dan Best Regards. -Original Message- From: Glen Mazza [mailto:gma...@talend.com] Sent: vendredi 3 février 2012 19:42 To: users@cxf.apache.orgmailto:users@cxf.apache.org Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken Once *you* decide which one you want--your choice but if the WSDL doesn't have security policy statements it will need to be WSS4J--just follow my blog entry, making changes as explained in the tutorial depending on the option you wanted. For example, the code segment referenced had instructions just before it telling you to comment out / uncomment the particular segment depending on the method you chose. Glen On 02/03/2012 01:33 PM, COURTAULT Francois wrote: Hello, OK but how do you choose the method WSS4J interceptors or WS-SecurityPolicy ? Best Regards. -- Glen Mazza Talend Community Coders - coders.talend.com blog: www.jroller.com/gmazzahttp://www.jroller.com/gmazza
Re: Issue with CXF-2.5.2 regarding UsernameToken
On 02/03/2012 02:38 PM, COURTAULT Francois wrote: Hello Dan and Glen, Quite likely the required approach, yes. If the WSDL contains policies and the policy engine is turned on (which is the default starting in CXF 2.3), then the policy based interceptors will be automatically engaged. Using the non-policy based approach may interfere with it. Yes, this is what I have seen. Clarification: if you *don't* include the cxf-rt-ws-policy dependency (as listed in the blog article), then any WS-Policy statements in the WSDL will be ignored, and in that case you can use the WSS4J interceptor approach to manually add headers. In fact I don't use maven, I have, in my Eclipse project, included all the jars of the apache-cxf-2.5.2/lib folder. I strongly encourage you to switch to Maven, and then import the Maven project into Eclipse. My WSDL-first blog tutorial shows the whole process (end of Step #5 for Eclipse import): http://www.jroller.com/gmazza/entry/web_service_tutorial. Web service development is much more clumsy/stressful without it. Does that mean that, by doing that, I have included the cxf-rt-ws-policy ? I presume. What is the standard classpath for an CXF client ? Much too complex today to define outside of Maven. There's a WHICH_JARS file that might help if you want to do things manually: http://svn.apache.org/viewvc/cxf/trunk/distribution/src/main/release/lib/WHICH_JARS?view=markup Now I have another issue: I try to write a client which has to target a Webservice which uses Asymmetric bindings. Again, the WSDL contains policy statements. So according to what you have said, I have to use the SecurityPolicy option in order to not have interference. Unless, again, you've not included the policy dependency which would cause it to be ignored. But the WS-SecPol security configuration method anyway should be fine for your needs. The problem I have is I haven't found any sample with this option for this kind of configuration :-( I have only found some info at http://cxf.apache.org/docs/ws-securitypolicy.html but the ws-security samples (specially the signing part) available at http://cxf.apache.org/docs/ws-security.html uses the WSS4J interceptors option and not the SecurityPolicy one. Could anybody help me about this issue: find a sample using the SecurityPolicy for X509Token (only signing) ? Link #14 here: http://www.jroller.com/gmazza/entry/blog_article_index offers two articles: WSS4J interceptor and WS-SecPol, but you're going to need to use Maven to follow them. I don't know of any non-Mavenized samples on the 'Net for this, but hopefully others can help in that regard. Glen Best Regards. -Original Message- From: Glen Mazza [mailto:gma...@talend.com] Sent: vendredi 3 février 2012 20:22 To: users@cxf.apache.org Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken On 02/03/2012 02:08 PM, Daniel Kulp wrote: On Friday, February 03, 2012 8:02:35 PM COURTAULT Francois wrote: Hello Glen, First, my WDSL contains policy statements. I have read again more carefully your article. Let me know if I have well understood: - if the WSDL contains policy statements, the WS-SecurityPolicy option is the preferred approach: right ? Quite likely the required approach, yes. If the WSDL contains policies and the policy engine is turned on (which is the default starting in CXF 2.3), then the policy based interceptors will be automatically engaged. Using the non-policy based approach may interfere with it. Clarification: if you *don't* include the cxf-rt-ws-policy dependency (as listed in the blog article), then any WS-Policy statements in the WSDL will be ignored, and in that case you can use the WSS4J interceptor approach to manually add headers. - if the WSDL doesn't contain policy statements, the WSS4J interceptors option is required: right ? You CAN, using configuration, provide a policy attachment that would define a security policy and drive the policy based interceptors that way. Definitely tricky though. But does that mean also that you cannot use this option if the WSDL contains policy statements ? So, if the answer to above question is yes, the CXF client coding rules are: - if your WSDL contains policy statements, you have no choice, you have to use WS-SecurityPolicy option: right ? - if your WSDL doesn't contains policy statements, you have no choice, you have to use WSS4J interceptors option: right ? I think that's the easy answer.The more complete answer is that you COULD use the WSS4J interceptors along with a custom interceptor that assert the various policies and likely remove/skip the policy based things.Definitely more work though. Dan Best Regards. -Original Message- From: Glen Mazza [mailto:gma...@talend.com] Sent: vendredi 3 février 2012 19:42 To: users@cxf.apache.orgmailto:users@cxf.apache.org Subject: Re: Issue with CXF-2.5.2 regarding UsernameToken Once
