You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Chris <cz...@ybs.co.uk> on 2014/10/10 13:00:30 UTC
CXF client send nonce and timestamp
We need to access a service with username/password protection and message
protection, against an Oracle server. After some tests we realised that it
did not protect against replay attacks. Configuring the server to require
timestamp and nonce resulted in an error.
To simplify tings I then configured the service without message protection.
I can call the service succesfully by setting:
Map<String, Object> props = client.getRequestContext();
props.put(SecurityConstants.CALLBACK_HANDLER,
new
Invoker_CXFNameCallbackHandler("password");
props.put(SecurityConstants.USERNAME, "user");
This adds:
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
soap:mustUnderstand="true">
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="UsernameToken-bcfd47d6-33cd-477f-8847-0cf21f2b0006">
<wsse:Username>user</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
However I tried adding the nonce and timestamp:
props.put(ConfigurationConstants.ADD_USERNAMETOKEN_NONCE,
"true");
props.put(ConfigurationConstants.ADD_USERNAMETOKEN_CREATED, "true");
This made no difference - the nonce and timestamp are still not set. I also
tried Boolean values instead of the String "true" and "false"
I have also tried removing the above code and setting:
Map<String, Object> iprops = new HashMap<String,Object>();
iprops.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
iprops.put(WSHandlerConstants.USER , "user");
iprops.put(WSHandlerConstants.PW_CALLBACK_REF,
new
Invoker_CXFNameCallbackHandler("password");
iprops.put(WSHandlerConstants.ADD_USERNAMETOKEN_CREATED, "true");
iprops.put(WSHandlerConstants.ADD_USERNAMETOKEN_NONCE, "true");
iprops.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
//client.getEndpoint().getInInterceptors().clear();
client.getEndpoint().getInInterceptors().add(new
WSS4JInInterceptor(iprops));
//client.getEndpoint().getOutInterceptors().clear();
client.getEndpoint().getOutInterceptors().add(new
WSS4JOutInterceptor());
This gives an error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: No username
available
at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
at com.sun.proxy.$Proxy33.whoAmI(Unknown Source)
at uk.co.ybs.ep10test.Invoker.main(Invoker.java:132)
Caused by: org.apache.cxf.ws.policy.PolicyException: No username available
at
org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:277)
at
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addUsernameToken(UsernameTokenInterceptor.java:395)
at
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addToken(UsernameTokenInterceptor.java:340)
I think I need to find how to pass the ADD_USERNAMETOKEN_NONCE and
ADD_USERNAMETOKEN_CREATED to the underlying wss4j. How do I do this?
Thanks
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Thanks,
I'll try this when I'm back at work on Monday.
Chris
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749789.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Chris <cz...@ybs.co.uk>.
Thanks,
That's unfortunate because Oracle's
*oracle/wss11_username_token_with_message_protection_service_policy* and
*oracle/wss11_message_protection_service_policy* don't behave themselves and
come up with an error:
BSP:R5215: Any SECURITY_TOKEN_REFERENCE to a PKIPATH_TOKEN MUST contain a
wsse11:TokenType attribute with a value of
"http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509PKIPathv1"
(the response contains
<wsse:SecurityTokenReference
TokenType="http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#EncryptedKey">
)
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749957.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Ok you are using a WS-SecurityPolicy 1.1 policy. sp13:Created + sp13:Nonce
do not apply for this version of the specification, and so that is why they
are not in the message.
Colm.
On Wed, Oct 15, 2014 at 12:13 PM, Chris <cz...@ybs.co.uk> wrote:
> Here is the policy from the WSDL:
>
> /<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="Service6Soap1p2Soap12HttpPort_Fault_Policy">
> <sp:SignedParts
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> <sp:SignedElements
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> <sp:EncryptedParts
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> <sp:EncryptedElements
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> </wsp:Policy>
> <wsp:Policy xmlns:wsp="
> http://schemas.xmlsoap.org/ws/2004/09/policy"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="Service6Soap1p2Soap12HttpPort_Input_Policy">
> <sp:SignedParts
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <sp:Body />
> <sp:Header Name="fmw-context"
> Namespace="http://xmlns.oracle.com/fmw/context/1.0" />
> <sp:Header Name="" Namespace="
> http://www.w3.org/2005/08/addressing" />
> <sp:Header Name=""
> Namespace="
> http://schemas.xmlsoap.org/ws/2004/08/addressing" />
> </sp:SignedParts>
> <sp:SignedElements
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> <sp:EncryptedParts
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <sp:Body />
> <sp:Header Name="fmw-context"
> Namespace="http://xmlns.oracle.com/fmw/context/1.0" />
> </sp:EncryptedParts>
> <sp:EncryptedElements
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> </wsp:Policy>
> <wsp:Policy xmlns:wsp="
> http://schemas.xmlsoap.org/ws/2004/09/policy"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="Service6Soap1p2Soap12HttpPort_Output_Policy">
> <sp:SignedParts
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <sp:Body />
> </sp:SignedParts>
> <sp:SignedElements
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> <sp:EncryptedParts
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <sp:Body />
> </sp:EncryptedParts>
> <sp:EncryptedElements
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
> </wsp:Policy>
> <wsp:Policy xmlns:wsp="
> http://schemas.xmlsoap.org/ws/2004/09/policy"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
>
>
> wsu:Id="wss10_username_token_with_message_protection_service_policy_timestamp_nonce">
> <sp:AsymmetricBinding
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:InitiatorToken>
> <wsp:Policy>
> <sp:X509Token
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
> <wsp:Policy>
>
> <sp:WssX509V3Token10 />
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:InitiatorToken>
> <sp:RecipientToken>
> <wsp:Policy>
> <sp:X509Token
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
> <wsp:Policy>
>
> <sp:WssX509V3Token10 />
> </wsp:Policy>
> </sp:X509Token>
> </wsp:Policy>
> </sp:RecipientToken>
> <sp:AlgorithmSuite>
> <wsp:Policy>
> <sp:Basic128 />
> </wsp:Policy>
> </sp:AlgorithmSuite>
> <sp:Layout>
> <wsp:Policy>
> <sp:Lax />
> </wsp:Policy>
> </sp:Layout>
> <sp:IncludeTimestamp />
> <sp:OnlySignEntireHeadersAndBody />
> </wsp:Policy>
> </sp:AsymmetricBinding>
> <sp:Wss10 xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy />
> </sp:Wss10>
> <sp:SignedSupportingTokens
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:UsernameToken
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
> <wsp:Policy
>
> xmlns:sp13="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802">
> <sp:WssUsernameToken10 />
> <sp13:Created />
> <sp13:Nonce />
> </wsp:Policy>
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SignedSupportingTokens>
> </wsp:Policy>
> /
> The following is the usename token part as produced by oracle, I added the
> Created and Nonce myself. Oracle does not request them even if if you set
> "required" on the server:
>
> /<sp:SignedSupportingTokens
> xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:UsernameToken
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
> <wsp:Policy>
> <sp:WssUsernameToken10 />
> </wsp:Policy>
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SignedSupportingTokens>
> </wsp:Policy>/
>
>
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749913.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Chris <cz...@ybs.co.uk>.
Here is the policy from the WSDL:
/<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Service6Soap1p2Soap12HttpPort_Fault_Policy">
<sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
<sp:SignedElements
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
<sp:EncryptedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
<sp:EncryptedElements
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
</wsp:Policy>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Service6Soap1p2Soap12HttpPort_Input_Policy">
<sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
<sp:Header Name="fmw-context"
Namespace="http://xmlns.oracle.com/fmw/context/1.0" />
<sp:Header Name="" Namespace="http://www.w3.org/2005/08/addressing" />
<sp:Header Name=""
Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing" />
</sp:SignedParts>
<sp:SignedElements
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
<sp:EncryptedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
<sp:Header Name="fmw-context"
Namespace="http://xmlns.oracle.com/fmw/context/1.0" />
</sp:EncryptedParts>
<sp:EncryptedElements
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
</wsp:Policy>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Service6Soap1p2Soap12HttpPort_Output_Policy">
<sp:SignedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
</sp:SignedParts>
<sp:SignedElements
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
<sp:EncryptedParts
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<sp:Body />
</sp:EncryptedParts>
<sp:EncryptedElements
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" />
</wsp:Policy>
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="wss10_username_token_with_message_protection_service_policy_timestamp_nonce">
<sp:AsymmetricBinding
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Always">
<wsp:Policy>
<sp:WssX509V3Token10 />
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
<sp:AlgorithmSuite>
<wsp:Policy>
<sp:Basic128 />
</wsp:Policy>
</sp:AlgorithmSuite>
<sp:Layout>
<wsp:Policy>
<sp:Lax />
</wsp:Policy>
</sp:Layout>
<sp:IncludeTimestamp />
<sp:OnlySignEntireHeadersAndBody />
</wsp:Policy>
</sp:AsymmetricBinding>
<sp:Wss10 xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy />
</sp:Wss10>
<sp:SignedSupportingTokens
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy
xmlns:sp13="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802">
<sp:WssUsernameToken10 />
<sp13:Created />
<sp13:Nonce />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
</wsp:Policy>
/
The following is the usename token part as produced by oracle, I added the
Created and Nonce myself. Oracle does not request them even if if you set
"required" on the server:
/<sp:SignedSupportingTokens
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10 />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SignedSupportingTokens>
</wsp:Policy>/
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749913.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Colm O hEigeartaigh <co...@apache.org>.
And what does the security policy in question look like?
Colm.
On Wed, Oct 15, 2014 at 11:34 AM, Chris <cz...@ybs.co.uk> wrote:
> At the time the lines you show are called the token "created" and "nonce"
> are
> false, and password type null:
>
> <http://cxf.547215.n5.nabble.com/file/n5749908/eclipse-ide.png>
>
> Tracing where and how these whould be set would have been too hard in the
> time I have, my fix is a "work-around" rather than a nice solution.
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749908.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Chris <cz...@ybs.co.uk>.
At the time the lines you show are called the token "created" and "nonce" are
false, and password type null:
<http://cxf.547215.n5.nabble.com/file/n5749908/eclipse-ide.png>
Tracing where and how these whould be set would have been too hard in the
time I have, my fix is a "work-around" rather than a nice solution.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749908.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Chris,
I'm confused by your mail. Nonce + Created are already supported in the
AbstractBindingBuilder:
if (token.isCreated() && token.getPasswordType() !=
UsernameToken.PasswordType.HashPassword) {
utBuilder.addCreated();
}
if (token.isNonce() && token.getPasswordType() !=
UsernameToken.PasswordType.HashPassword) {
utBuilder.addNonce();
}
Can I see the exact encrypted + signed security policy that is not working?
Colm.
On Wed, Oct 15, 2014 at 11:03 AM, Chris <cz...@ybs.co.uk> wrote:
> coheigea wrote
> > Actually, the UsernameTokenInterceptor (which is used when there is no
> > security binding) does not support Nonce + Created. I've added support
> > here:
> >
> > https://issues.apache.org/jira/browse/CXF-6051
> >
> > Colm.
>
> Thanks Colm,
> It is also not supported with the encrypred and signed username token
> policy
> (Oracle server with
> *oracle/wss10_username_token_with_message_protection_service_policy*).
>
> Again I have a "working fix" to CXF 3.0.1, which I will give here
>
> org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor.java
>
> In/ PolicyBasedWSS4JOutInterceptorInternal.public void
> handleMessage(SoapMessage message) throws Fault / (at about line 140),
> here we assert the "Created" and Nonce if they are present so that they can
> be picked up from "aim" later.
>
> / ais = getAllAssertionsByLocalname(aim,
> SPConstants.SYMMETRIC_BINDING);
> if (!ais.isEmpty()) {
> for (AssertionInfo ai : ais) {
> transport = (AbstractBinding)ai.getAssertion();
> ai.setAsserted(true);
> }
> }
>
> //**************************
> // BEGIN MODIFICATION
> //**************************
> ais = aim.get(SP13Constants.CREATED);
> if (ais != null && !ais.isEmpty()) {
> for (AssertionInfo ai : ais) {
> ai.setAsserted(true);
> }
> }
>
>
> ais = aim.get(SP13Constants.NONCE);
>
> if (ais != null && !ais.isEmpty()) {
> for (AssertionInfo ai : ais) {
> ai.setAsserted(true);
> }
> }
> //**************************
> // END MODIFICATION
> //**************************
>
> if (transport == null && isRequestor(message)) {
> Policy policy = new Policy();
> transport = new
> TransportBinding(org.apache.wss4j.policy.SPConstants.SPVersion.SP11,
> policy);
> }/
>
> org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.java
>
> In /protected void handleUsernameTokenSupportingToken( UsernameToken token,
> boolean endorse, boolean encryptedToken, List<SupportingToken> ret ) throws
> WSSecurityException/ (around line 596), here we set the properties in the
> utBuilder if they are asserted in the "aim":
> /
> } else {
>
> WSSecUsernameToken utBuilder = addUsernameToken(token);
> if (utBuilder != null) {
>
> //***************************
> // Beginning of Modification
> //***************************
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
> boolean haveNonce = false;
> boolean haveCreated = false;
>
> Collection<AssertionInfo> nonces =
> aim.getAssertionInfo(SP13Constants.NONCE);
> for(AssertionInfo nonce: nonces) {
> if (nonce.isAsserted()) {
> haveNonce = true;
> }
> }
>
> Collection<AssertionInfo> createds =
> aim.getAssertionInfo(SP13Constants.CREATED);
> for(AssertionInfo created: createds) {
> if(created.isAsserted()) {
> haveCreated = true;
> }
> }
>
> if (haveCreated) {
> utBuilder.addCreated();
> }
>
> if (haveNonce) {
> utBuilder.addNonce();
> }
>
> //***************************
> // End of modification
> //***************************
> utBuilder.prepare(saaj.getSOAPPart());
>
> Element e = utBuilder.getUsernameTokenElement();
>
> //********************************************
> // Beginning of Modification (Logging only)
> //********************************************
>
> if(LOG.isLoggable(Level.FINE)) {
> Document d = e.getOwnerDocument();
> DOMImplementationLS domImplLS =
> (DOMImplementationLS)
> d.getImplementation();
> LSSerializer serializer =
> domImplLS.createLSSerializer();
> LOG.fine("Username Token: " +
> serializer.writeToString(e));
> }
> //********************************************
> // End of Modification (Logging only)
> //********************************************
>
> addSupportingElement(utBuilder.getUsernameTokenElement());
> ret.add(new SupportingToken(token, utBuilder));
>
> //WebLogic and WCF always encrypt these/
>
> Also I just wanted to sat thank you for your support to get a "real" fix
> info a future release, so hopefully we can use vanilla unpached code in
> future.
>
>
>
>
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749905.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
I have a wotking fix in the signed/encrypted version now (and
thanks Colm)
Posted by Chris <cz...@ybs.co.uk>.
coheigea wrote
> Actually, the UsernameTokenInterceptor (which is used when there is no
> security binding) does not support Nonce + Created. I've added support
> here:
>
> https://issues.apache.org/jira/browse/CXF-6051
>
> Colm.
Thanks Colm,
It is also not supported with the encrypred and signed username token policy
(Oracle server with
*oracle/wss10_username_token_with_message_protection_service_policy*).
Again I have a "working fix" to CXF 3.0.1, which I will give here
org.apache.cxf.ws.security.wss4j.PolicyBasedWSS4JOutInterceptor.java
In/ PolicyBasedWSS4JOutInterceptorInternal.public void
handleMessage(SoapMessage message) throws Fault / (at about line 140),
here we assert the "Created" and Nonce if they are present so that they can
be picked up from "aim" later.
/ ais = getAllAssertionsByLocalname(aim,
SPConstants.SYMMETRIC_BINDING);
if (!ais.isEmpty()) {
for (AssertionInfo ai : ais) {
transport = (AbstractBinding)ai.getAssertion();
ai.setAsserted(true);
}
}
//**************************
// BEGIN MODIFICATION
//**************************
ais = aim.get(SP13Constants.CREATED);
if (ais != null && !ais.isEmpty()) {
for (AssertionInfo ai : ais) {
ai.setAsserted(true);
}
}
ais = aim.get(SP13Constants.NONCE);
if (ais != null && !ais.isEmpty()) {
for (AssertionInfo ai : ais) {
ai.setAsserted(true);
}
}
//**************************
// END MODIFICATION
//**************************
if (transport == null && isRequestor(message)) {
Policy policy = new Policy();
transport = new
TransportBinding(org.apache.wss4j.policy.SPConstants.SPVersion.SP11,
policy);
}/
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.java
In /protected void handleUsernameTokenSupportingToken( UsernameToken token,
boolean endorse, boolean encryptedToken, List<SupportingToken> ret ) throws
WSSecurityException/ (around line 596), here we set the properties in the
utBuilder if they are asserted in the "aim":
/
} else {
WSSecUsernameToken utBuilder = addUsernameToken(token);
if (utBuilder != null) {
//***************************
// Beginning of Modification
//***************************
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
boolean haveNonce = false;
boolean haveCreated = false;
Collection<AssertionInfo> nonces =
aim.getAssertionInfo(SP13Constants.NONCE);
for(AssertionInfo nonce: nonces) {
if (nonce.isAsserted()) {
haveNonce = true;
}
}
Collection<AssertionInfo> createds =
aim.getAssertionInfo(SP13Constants.CREATED);
for(AssertionInfo created: createds) {
if(created.isAsserted()) {
haveCreated = true;
}
}
if (haveCreated) {
utBuilder.addCreated();
}
if (haveNonce) {
utBuilder.addNonce();
}
//***************************
// End of modification
//***************************
utBuilder.prepare(saaj.getSOAPPart());
Element e = utBuilder.getUsernameTokenElement();
//********************************************
// Beginning of Modification (Logging only)
//********************************************
if(LOG.isLoggable(Level.FINE)) {
Document d = e.getOwnerDocument();
DOMImplementationLS domImplLS = (DOMImplementationLS)
d.getImplementation();
LSSerializer serializer = domImplLS.createLSSerializer();
LOG.fine("Username Token: " + serializer.writeToString(e));
}
//********************************************
// End of Modification (Logging only)
//********************************************
addSupportingElement(utBuilder.getUsernameTokenElement());
ret.add(new SupportingToken(token, utBuilder));
//WebLogic and WCF always encrypt these/
Also I just wanted to sat thank you for your support to get a "real" fix
info a future release, so hopefully we can use vanilla unpached code in
future.
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749905.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: Current situation: CXF client send nonce and timestamp
Posted by Colm O hEigeartaigh <co...@apache.org>.
Actually, the UsernameTokenInterceptor (which is used when there is no
security binding) does not support Nonce + Created. I've added support here:
https://issues.apache.org/jira/browse/CXF-6051
Colm.
On Tue, Oct 14, 2014 at 2:12 PM, Chris <cz...@ybs.co.uk> wrote:
> I have not yet been able to build a simple test case, but it seems clear
> that
> the <sp13:Created /> and
> <sp13:Nonce /> elements are ignored in the client code. As I mentioned in a
> previous message
> <
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749800.html
> >
> these are being read correctly by the
>
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
>
> at the beginning of
> protected UsernameToken assertTokens(SoapMessage message, String
> localname, boolean signed)
>
> in org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor
>
> but not being returned in the token produced by that method.
>
> Meanwhile I came up with a "fix" by modifying the UsernameTokenInterceptor:
>
> / protected void addToken(SoapMessage message) {
> UsernameToken tok = assertTokens(message);
>
> Header h = findSecurityHeader(message, true);
> WSSecUsernameToken utBuilder =
> addUsernameToken(message, tok);
> if (utBuilder == null) {
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
> Collection<AssertionInfo> ais =
> getAllAssertionsByLocalname(aim,
> SPConstants.USERNAME_TOKEN);
> for (AssertionInfo ai : ais) {
> if (ai.isAsserted()) {
> ai.setAsserted(false);
> }
> }
> return;
> }
>
> //***************************
> // Beginning of Modification
> //***************************
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
> boolean haveNonce = false;
> boolean haveCreated = false;
>
> Collection<AssertionInfo> nonces =
> aim.getAssertionInfo(SP13Constants.NONCE);
> for(AssertionInfo nonce: nonces) {
> if (nonce.isAsserted()) {
> haveNonce = true;
> }
>
> }
>
> Collection<AssertionInfo> createds =
> aim.getAssertionInfo(SP13Constants.CREATED);
> for(AssertionInfo created: createds) {
> if(created.isAsserted()) {
> haveCreated = true;
> }
> }
>
> if (haveCreated) {
> utBuilder.addCreated();
> }
>
> if (haveNonce) {
> utBuilder.addNonce();
> }
>
> //***************************
> // End of modification
> //***************************
>
> Element el = (Element)h.getObject();
> utBuilder.prepare(el.getOwnerDocument());
> el.appendChild(utBuilder.getUsernameTokenElement());
> }
> /
>
>
> So I thought "all well and good" and then tried the username token with
> message protection only to find that it uses a totally different class to
> generate the embedded username token, and the changed code is not called!
> As
> soon as I set the server to "created time and nonce required" it fails!
> This
> also appears to be much more complex processing so finding where to fix the
> code is a little difficult.
>
> BTW I know that my "fix" is probably not the right way to do it, fixing the
> underlying code to produce the correct values in the token, then passing
> that through to the builder looked like much to much work within our
> timescales
>
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749873.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Current situation: CXF client send nonce and timestamp
Posted by Jason Pell <ja...@pellcorp.com>.
I think you need to be looking in the wss4j out interceptor.
We use WS policy based cxf clients and it all just works. If your wsdl
includes the policies might be good to give that a go.
Lots of samples in the systests and also on my github project too.
On 15/10/2014 12:12 AM, "Chris" <cz...@ybs.co.uk> wrote:
> I have not yet been able to build a simple test case, but it seems clear
> that
> the <sp13:Created /> and
> <sp13:Nonce /> elements are ignored in the client code. As I mentioned in a
> previous message
> <
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749800.html
> >
> these are being read correctly by the
>
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
>
> at the beginning of
> protected UsernameToken assertTokens(SoapMessage message, String
> localname, boolean signed)
>
> in org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor
>
> but not being returned in the token produced by that method.
>
> Meanwhile I came up with a "fix" by modifying the UsernameTokenInterceptor:
>
> / protected void addToken(SoapMessage message) {
> UsernameToken tok = assertTokens(message);
>
> Header h = findSecurityHeader(message, true);
> WSSecUsernameToken utBuilder =
> addUsernameToken(message, tok);
> if (utBuilder == null) {
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
> Collection<AssertionInfo> ais =
> getAllAssertionsByLocalname(aim,
> SPConstants.USERNAME_TOKEN);
> for (AssertionInfo ai : ais) {
> if (ai.isAsserted()) {
> ai.setAsserted(false);
> }
> }
> return;
> }
>
> //***************************
> // Beginning of Modification
> //***************************
> AssertionInfoMap aim = message.get(AssertionInfoMap.class);
> boolean haveNonce = false;
> boolean haveCreated = false;
>
> Collection<AssertionInfo> nonces =
> aim.getAssertionInfo(SP13Constants.NONCE);
> for(AssertionInfo nonce: nonces) {
> if (nonce.isAsserted()) {
> haveNonce = true;
> }
>
> }
>
> Collection<AssertionInfo> createds =
> aim.getAssertionInfo(SP13Constants.CREATED);
> for(AssertionInfo created: createds) {
> if(created.isAsserted()) {
> haveCreated = true;
> }
> }
>
> if (haveCreated) {
> utBuilder.addCreated();
> }
>
> if (haveNonce) {
> utBuilder.addNonce();
> }
>
> //***************************
> // End of modification
> //***************************
>
> Element el = (Element)h.getObject();
> utBuilder.prepare(el.getOwnerDocument());
> el.appendChild(utBuilder.getUsernameTokenElement());
> }
> /
>
>
> So I thought "all well and good" and then tried the username token with
> message protection only to find that it uses a totally different class to
> generate the embedded username token, and the changed code is not called!
> As
> soon as I set the server to "created time and nonce required" it fails!
> This
> also appears to be much more complex processing so finding where to fix the
> code is a little difficult.
>
> BTW I know that my "fix" is probably not the right way to do it, fixing the
> underlying code to produce the correct values in the token, then passing
> that through to the builder looked like much to much work within our
> timescales
>
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749873.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Current situation: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
I have not yet been able to build a simple test case, but it seems clear that
the <sp13:Created /> and
<sp13:Nonce /> elements are ignored in the client code. As I mentioned in a
previous message
<http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749800.html>
these are being read correctly by the
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
at the beginning of
protected UsernameToken assertTokens(SoapMessage message, String
localname, boolean signed)
in org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor
but not being returned in the token produced by that method.
Meanwhile I came up with a "fix" by modifying the UsernameTokenInterceptor:
/ protected void addToken(SoapMessage message) {
UsernameToken tok = assertTokens(message);
Header h = findSecurityHeader(message, true);
WSSecUsernameToken utBuilder =
addUsernameToken(message, tok);
if (utBuilder == null) {
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
Collection<AssertionInfo> ais =
getAllAssertionsByLocalname(aim,
SPConstants.USERNAME_TOKEN);
for (AssertionInfo ai : ais) {
if (ai.isAsserted()) {
ai.setAsserted(false);
}
}
return;
}
//***************************
// Beginning of Modification
//***************************
AssertionInfoMap aim = message.get(AssertionInfoMap.class);
boolean haveNonce = false;
boolean haveCreated = false;
Collection<AssertionInfo> nonces =
aim.getAssertionInfo(SP13Constants.NONCE);
for(AssertionInfo nonce: nonces) {
if (nonce.isAsserted()) {
haveNonce = true;
}
}
Collection<AssertionInfo> createds =
aim.getAssertionInfo(SP13Constants.CREATED);
for(AssertionInfo created: createds) {
if(created.isAsserted()) {
haveCreated = true;
}
}
if (haveCreated) {
utBuilder.addCreated();
}
if (haveNonce) {
utBuilder.addNonce();
}
//***************************
// End of modification
//***************************
Element el = (Element)h.getObject();
utBuilder.prepare(el.getOwnerDocument());
el.appendChild(utBuilder.getUsernameTokenElement());
}
/
So I thought "all well and good" and then tried the username token with
message protection only to find that it uses a totally different class to
generate the embedded username token, and the changed code is not called! As
soon as I set the server to "created time and nonce required" it fails! This
also appears to be much more complex processing so finding where to fix the
code is a little difficult.
BTW I know that my "fix" is probably not the right way to do it, fixing the
underlying code to produce the correct values in the token, then passing
that through to the builder looked like much to much work within our
timescales
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749873.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Thanks I'll try to build a test case. Unfortunately I cannot build the source
from mvn (and I don't want to get sidetrecaked into debugging build from
source) , so I cannot base it on one of the existing cases
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749806.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Colm O hEigeartaigh <co...@apache.org>.
If you create a test-case that reproduces the problem I can take a look.
Colm.
On Mon, Oct 13, 2014 at 11:30 AM, Chris <cz...@ybs.co.uk> wrote:
> That does not seem to work. I'm trying to trace why this is, but it seems
> that in org.apache.cxf.ws.security.wss4j.assertTokens (at line 269) the
> "assertPolicy" lines come up with a valid list of policies:
>
> (value of aim)
> {{
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Created=[{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Created:true]
> ,
> {
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}UsernameToken=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}UsernameToken:true]
> ,
> {
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}SupportingTokens=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}SupportingTokens:true]
> ,
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Nonce=[{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Nonce:true]
> ,
> {
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}WssUsernameToken10=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}WssUsernameToken10:true]
> }
>
> but after the (UsernameToken)assertTokens(message,
> SPConstants.USERNAME_TOKEN, true) line the returned token has "nonce" and
> "timestamp" set to false.
>
> I'm not sure that this is the cause though
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749800.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
That does not seem to work. I'm trying to trace why this is, but it seems
that in org.apache.cxf.ws.security.wss4j.assertTokens (at line 269) the
"assertPolicy" lines come up with a valid list of policies:
(value of aim)
{{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Created=[{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Created:true],
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}UsernameToken=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}UsernameToken:true],
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}SupportingTokens=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}SupportingTokens:true],
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Nonce=[{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802}Nonce:true],
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}WssUsernameToken10=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}WssUsernameToken10:true]}
but after the (UsernameToken)assertTokens(message,
SPConstants.USERNAME_TOKEN, true) line the returned token has "nonce" and
"timestamp" set to false.
I'm not sure that this is the cause though
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749800.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Colm O hEigeartaigh <co...@apache.org>.
Yes the "action" driven approach of WSS4J + WS-SecurityPolicy are
configured differently. You can add a nonce + Created timestamps in
WS-SecurityPolicy as follows:
<sp:UsernameToken sp:IncludeToken="
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient
">
<wsp:Policy>
<sp:WssUsernameToken10/>
<sp13:Created/>
<sp13:Nonce/>
</wsp:Policy>
</sp:UsernameToken>
Example:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob_plain;f=systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/ut/DoubleItUt.wsdl;hb=HEAD
Colm.
On Mon, Oct 13, 2014 at 10:07 AM, Chris <cz...@ybs.co.uk> wrote:
> Summary
>
> I have discovered that when the WSDL contains a policy the "interceptor"
> method of configuring CXF is never invoked, it trues to use the policy
> method with high-level parameters from SecurityConstants parameters.
>
> Is there a way of forcing the policy-based CXF security processing to
> include a nonce and timestamp?
> Alternatively, is there a way to prevent CXF from going down the
> policy-based execution path?
>
>
> Detail
>
> This is what I have discovered this morning. I downloaded and saved the
> WSDL
> from the Oracle system, and as previously the program setting an explicit
> interceptor failed:
>
> Code
>
> Client client = ClientProxy.getClient(port);
>
> client.getInInterceptors().add(new LoggingInInterceptor());
> client.getOutInterceptors().add(new LoggingOutInterceptor());
>
> WSSSecurityProperties properties = new WSSSecurityProperties();
> List<WSSConstants.Action> actions = new ArrayList<WSSConstants.Action>();
> actions.add(WSSConstants.USERNAMETOKEN);
> properties.setActions(actions);
>
>
>
> properties.setUsernameTokenPasswordType(WSSConstants.UsernameTokenPasswordType.PASSWORD_TEXT);
> properties.setTokenUser("user");
> properties.setCallbackHandler(new CXFNameCallbackHandler("test1234"));
> properties.setAddUsernameTokenNonce(true);
> properties.setAddUsernameTokenCreated(true);
> WSS4JStaxOutInterceptor ohandler = new
> WSS4JStaxOutInterceptor(properties);
>
> client.getOutInterceptors().add(ohandler);
>
>
> Error
>
> Oct 13, 2014 9:30:41 AM
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean
> buildServiceFromWSDL
> INFO: Creating Service {http://tempuri.org/}Service10Soap1p2Service from
> WSDL:
>
> file:/C:/Users/u08654/work/workspaces/OwsmWEblogicEclipse/TestCallerWithStaticWsdl/wsdl/Service10Soap1p2Soap12HttpPort.wsdl
> Invoking whoAmI...
> Oct 13, 2014 9:30:42 AM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://tempuri.org/}Service10Soap1p2Service#{http://tempuri.org/}whoAmI
> has
> thrown exception, unwinding now
> org.apache.cxf.ws.policy.PolicyException: No username available
> at
>
> org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:277)
>
>
> As it was saying "No Username Created" I thought that it was looking for
> the
> SecurityConstants.USERNAME, and in fact proved that if I add the code for
> the "non interceptor" version it does not fail but does not send nonce or
> timestamp. This made me think that interceptors were ignored when there is
> a
> policy in the WSDL - so I edited the wsdl
> Part of Original WSDL
>
> <definitions name="Service10Soap1p2Service"
> targetNamespace="http://tempuri.org/"
> xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:tns="http://tempuri.org/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
> <wsp:Policy xmlns:wsp="
> http://schemas.xmlsoap.org/ws/2004/09/policy"
> xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:sp13="
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802"
> wsu:Id="wss_username_token_service_policy">
> <sp:SupportingTokens
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:UsernameToken
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
> <wsp:Policy>
> <sp:WssUsernameToken10 />
> </wsp:Policy>
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SupportingTokens>
> </wsp:Policy>
> <types>
> ...
> <binding name="Service10Soap1p2Soap12HttpPortBinding"
> type="tns:Service10Soap1p2">
> <soap12:binding style="document"
> transport="
> http://www.w3.org/2003/05/soap/bindings/HTTP/" />
> <wsp:PolicyReference
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
> URI="#wss_username_token_service_policy"
> wsdl:required="false" />
> <operation name="echoWithChevrons">
> Edited WSDL
>
>
> <definitions name="Service10Soap1p2Service"
> targetNamespace="http://tempuri.org/"
> xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:tns="http://tempuri.org/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
> <types>
> ...
> </portType>
> <binding name="Service10Soap1p2Soap12HttpPortBinding"
> type="tns:Service10Soap1p2">
> <soap12:binding style="document"
> transport="
> http://www.w3.org/2003/05/soap/bindings/HTTP/" />
> <operation name="echoWithChevrons">
>
> This now works fine:
> Message sent with above code and no policy in WSDL
>
> <?xml version="1.0" encoding="http://www.w3.org/2003/05/soap-envelope"
> standalone="no"?>
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
> <soap:Header>
> <wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> soap:mustUnderstand="true">
> <wsse:UsernameToken
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="G572ee91e-c4de-4722-be41-7fb9d5c1bfe2">
> <wsse:Username>u08654</wsse:Username>
> <wsse:Password
> Type="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">test1234</wsse:Password>
> <wsse:Nonce
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> ">6g154NEn/nAXwVHQ0m3m5w==
> </wsse:Nonce>
> <wsu:Created>2014-10-13T09:56:01.062+01:00</wsu:Created>
> </wsse:UsernameToken>
> </wsse:Security>
>
> Now downloading and editing the WSDL is obviously not very desirable to
> have
> to download and edit WSDLs to remove policies and then set up interceptors
> for the security.
>
> Ideally there would be a way to force the nonce and timestamp on the
> policy-based authentication. In fact I would have thought that it should be
> the default following OASIS recommendations
> <
> https://www.oasis-open.org/committees/download.php/13392/wss-v1.0-spec-pr-UsernameTokenProfile-01.htm
> >
> :
>
> /1. It is RECOMMENDED that web service producers reject any
> UsernameToken not using both nonce and creation timestamps.
> 2. It is RECOMMENDED that web service producers provide a
> timestamp
> “freshness” limitation, and that any UsernameToken with “stale” timestamps
> be rejected. As a guideline, a value of five minutes can be used as a
> minimum to detect, and thus reject, replays.
> 3. It is RECOMMENDED that used nonces be cached for a period at
> least as long as the timestamp freshness limitation period, above, and that
> UsernameToken with nonces that have already been used (and are thus in the
> cache) be rejected./
>
> If this is not possible is there an easy way to get CXF to ignore the
> policy
> in the WSDL and use the interceptor-based configuration?
>
> Thanks
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749798.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF client send nonce and timestamp
Posted by Jason Pell <ja...@pellcorp.com>.
Ok sorry for the noise :-)
On Oct 14, 2014 10:22 PM, "Chris" <cz...@ybs.co.uk> wrote:
> Jason Pell wrote
> > See this is where I don't see nonce as useful if connection is protected.
> > TLS should be immune to replay attacks.
>
> Yes you are right - but I was attempting to use username password with
> message protection i.e. signed and encrypted. (that's in my original
> message
> but very easy to miss!)
>
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749865.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Jason Pell wrote
> See this is where I don't see nonce as useful if connection is protected.
> TLS should be immune to replay attacks.
Yes you are right - but I was attempting to use username password with
message protection i.e. signed and encrypted. (that's in my original message
but very easy to miss!)
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749865.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Jason Pell <ja...@pellcorp.com>.
See this is where I don't see nonce as useful if connection is protected.
TLS should be immune to replay attacks.
http://security.stackexchange.com/questions/23607/replaying-ssl-traffic-in-an-active-connection
So this is why I was suggesting that a nonce is not useful if you are using
username password
My logic is that if you are using username password I am assuming you are
also using TLS. If you are not using TLS then the username and password
are in clear text and an attacker can use them to submit additional web
service requests. So not classic replay.
Whereas if you use digest and nonce even on a non TLS connection there is
no way for an attacker to acquire your password and a replay wont work
because of the replay protection.
Perhaps someone like Colm can tell me if I have missed something obvious
about nonce for non TLS non digest username tokens.
And also how a nonce adds additional protection to a TLS connection which
already has replay protection at the protocol level
On 14/10/2014 9:27 PM, "Jason Pell" <ja...@pellcorp.com> wrote:
> Hi,
>
> Yes sorry I was thinking of man in the middle. I was not aware it was
> possible to replay a TLS transaction. I think that is the only way a TLS
> protected web service request could be compromised via replay is to attempt
> to resend the TLS encrypted bytes. However from some additional reading it
> does look as though replaying TLS is not straight forward as TLS itself has
> replay protection due to the way the hand shakes work.
>
> Anyway I am not going to claim to be any kind of expert on TLS!
>
> But nonce and digest username tokens are naturally replay resistent as the
> nonce is part of the digested password valur .
> On 14/10/2014 6:09 PM, "Chris" <cz...@ybs.co.uk> wrote:
>
>> Jason Pell wrote
>> > As an aside having a timestamp and nonce with a username password does
>> > notprevent replay attacks. Because attacker has all info to replay they
>> > justneed to generate new timestamp and nonce and use existing
>> > password.From what I read digest passwords are actually encoded with the
>> > nonce valueso there is no way to reproduce the password as its one
>> way.On
>> > 13/10/2014 8:08 PM, "Chris" <
>>
>> > czbrooking@.co
>>
>> > > wrote:
>>
>> That's not the case with Oracle (or indeed CXF) servers. When you have a
>> nonce and a timestamp the system will prevent the same nonec being used
>> until the timestamp expires. See Web Services Security 3 UsernameToken
>> Profile 1.0
>> <
>> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
>> >
>> :/103 Two optional elements are introduced in the element to provide a
>> 104
>> countermeasure for replay attacks: and . A nonce is a 105 random value
>> that
>> the sender creates to include in each UsernameToken that it sends.
>> Although
>> 106 using a nonce is an effective countermeasure against replay attacks,
>> it
>> requires a server to 107 maintain a cache of used nonces, consuming server
>> resources. Combining a nonce with a 108 creation timestamp has the
>> advantage
>> of allowing a server to limit the cache of nonces to a 109 "freshness"
>> time
>> period, establishing an upper bound on resource requirements. If either or
>> both 110 of and are present they MUST be included in the digest value
>> 111
>> as follows: /
>>
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749843.html
>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>
Re: CXF client send nonce and timestamp
Posted by Jason Pell <ja...@pellcorp.com>.
Hi,
Yes sorry I was thinking of man in the middle. I was not aware it was
possible to replay a TLS transaction. I think that is the only way a TLS
protected web service request could be compromised via replay is to attempt
to resend the TLS encrypted bytes. However from some additional reading it
does look as though replaying TLS is not straight forward as TLS itself has
replay protection due to the way the hand shakes work.
Anyway I am not going to claim to be any kind of expert on TLS!
But nonce and digest username tokens are naturally replay resistent as the
nonce is part of the digested password valur .
On 14/10/2014 6:09 PM, "Chris" <cz...@ybs.co.uk> wrote:
> Jason Pell wrote
> > As an aside having a timestamp and nonce with a username password does
> > notprevent replay attacks. Because attacker has all info to replay they
> > justneed to generate new timestamp and nonce and use existing
> > password.From what I read digest passwords are actually encoded with the
> > nonce valueso there is no way to reproduce the password as its one way.On
> > 13/10/2014 8:08 PM, "Chris" <
>
> > czbrooking@.co
>
> > > wrote:
>
> That's not the case with Oracle (or indeed CXF) servers. When you have a
> nonce and a timestamp the system will prevent the same nonec being used
> until the timestamp expires. See Web Services Security 3 UsernameToken
> Profile 1.0
> <
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
> >
> :/103 Two optional elements are introduced in the element to provide a 104
> countermeasure for replay attacks: and . A nonce is a 105 random value
> that
> the sender creates to include in each UsernameToken that it sends. Although
> 106 using a nonce is an effective countermeasure against replay attacks, it
> requires a server to 107 maintain a cache of used nonces, consuming server
> resources. Combining a nonce with a 108 creation timestamp has the
> advantage
> of allowing a server to limit the cache of nonces to a 109 "freshness" time
> period, establishing an upper bound on resource requirements. If either or
> both 110 of and are present they MUST be included in the digest value 111
> as follows: /
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749843.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Jason Pell wrote
> As an aside having a timestamp and nonce with a username password does
> notprevent replay attacks. Because attacker has all info to replay they
> justneed to generate new timestamp and nonce and use existing
> password.From what I read digest passwords are actually encoded with the
> nonce valueso there is no way to reproduce the password as its one way.On
> 13/10/2014 8:08 PM, "Chris" <
> czbrooking@.co
> > wrote:
That's not the case with Oracle (or indeed CXF) servers. When you have a
nonce and a timestamp the system will prevent the same nonec being used
until the timestamp expires. See Web Services Security 3 UsernameToken
Profile 1.0
<http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf>
:/103 Two optional elements are introduced in the element to provide a 104
countermeasure for replay attacks: and . A nonce is a 105 random value that
the sender creates to include in each UsernameToken that it sends. Although
106 using a nonce is an effective countermeasure against replay attacks, it
requires a server to 107 maintain a cache of used nonces, consuming server
resources. Combining a nonce with a 108 creation timestamp has the advantage
of allowing a server to limit the cache of nonces to a 109 "freshness" time
period, establishing an upper bound on resource requirements. If either or
both 110 of and are present they MUST be included in the digest value 111
as follows: /
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749843.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Jason Pell <ja...@pellcorp.com>.
As an aside having a timestamp and nonce with a username password does not
prevent replay attacks. Because attacker has all info to replay they just
need to generate new timestamp and nonce and use existing password.
>From what I read digest passwords are actually encoded with the nonce value
so there is no way to reproduce the password as its one way.
On 13/10/2014 8:08 PM, "Chris" <cz...@ybs.co.uk> wrote:
> Summary
>
> I have discovered that when the WSDL contains a policy the "interceptor"
> method of configuring CXF is never invoked, it trues to use the policy
> method with high-level parameters from SecurityConstants parameters.
>
> Is there a way of forcing the policy-based CXF security processing to
> include a nonce and timestamp?
> Alternatively, is there a way to prevent CXF from going down the
> policy-based execution path?
>
>
> Detail
>
> This is what I have discovered this morning. I downloaded and saved the
> WSDL
> from the Oracle system, and as previously the program setting an explicit
> interceptor failed:
>
> Code
>
> Client client = ClientProxy.getClient(port);
>
> client.getInInterceptors().add(new LoggingInInterceptor());
> client.getOutInterceptors().add(new LoggingOutInterceptor());
>
> WSSSecurityProperties properties = new WSSSecurityProperties();
> List<WSSConstants.Action> actions = new ArrayList<WSSConstants.Action>();
> actions.add(WSSConstants.USERNAMETOKEN);
> properties.setActions(actions);
>
>
>
> properties.setUsernameTokenPasswordType(WSSConstants.UsernameTokenPasswordType.PASSWORD_TEXT);
> properties.setTokenUser("user");
> properties.setCallbackHandler(new CXFNameCallbackHandler("test1234"));
> properties.setAddUsernameTokenNonce(true);
> properties.setAddUsernameTokenCreated(true);
> WSS4JStaxOutInterceptor ohandler = new
> WSS4JStaxOutInterceptor(properties);
>
> client.getOutInterceptors().add(ohandler);
>
>
> Error
>
> Oct 13, 2014 9:30:41 AM
> org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean
> buildServiceFromWSDL
> INFO: Creating Service {http://tempuri.org/}Service10Soap1p2Service from
> WSDL:
>
> file:/C:/Users/u08654/work/workspaces/OwsmWEblogicEclipse/TestCallerWithStaticWsdl/wsdl/Service10Soap1p2Soap12HttpPort.wsdl
> Invoking whoAmI...
> Oct 13, 2014 9:30:42 AM org.apache.cxf.phase.PhaseInterceptorChain
> doDefaultLogging
> WARNING: Interceptor for
> {http://tempuri.org/}Service10Soap1p2Service#{http://tempuri.org/}whoAmI
> has
> thrown exception, unwinding now
> org.apache.cxf.ws.policy.PolicyException: No username available
> at
>
> org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:277)
>
>
> As it was saying "No Username Created" I thought that it was looking for
> the
> SecurityConstants.USERNAME, and in fact proved that if I add the code for
> the "non interceptor" version it does not fail but does not send nonce or
> timestamp. This made me think that interceptors were ignored when there is
> a
> policy in the WSDL - so I edited the wsdl
> Part of Original WSDL
>
> <definitions name="Service10Soap1p2Service"
> targetNamespace="http://tempuri.org/"
> xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:tns="http://tempuri.org/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
> <wsp:Policy xmlns:wsp="
> http://schemas.xmlsoap.org/ws/2004/09/policy"
> xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy"
>
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:sp13="
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802"
> wsu:Id="wss_username_token_service_policy">
> <sp:SupportingTokens
> xmlns:sp="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
> <wsp:Policy>
> <sp:UsernameToken
>
> sp:IncludeToken="
> http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient
> ">
> <wsp:Policy>
> <sp:WssUsernameToken10 />
> </wsp:Policy>
> </sp:UsernameToken>
> </wsp:Policy>
> </sp:SupportingTokens>
> </wsp:Policy>
> <types>
> ...
> <binding name="Service10Soap1p2Soap12HttpPortBinding"
> type="tns:Service10Soap1p2">
> <soap12:binding style="document"
> transport="
> http://www.w3.org/2003/05/soap/bindings/HTTP/" />
> <wsp:PolicyReference
> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
> URI="#wss_username_token_service_policy"
> wsdl:required="false" />
> <operation name="echoWithChevrons">
> Edited WSDL
>
>
> <definitions name="Service10Soap1p2Service"
> targetNamespace="http://tempuri.org/"
> xmlns="http://schemas.xmlsoap.org/wsdl/"
> xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
> xmlns:tns="http://tempuri.org/"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
> <types>
> ...
> </portType>
> <binding name="Service10Soap1p2Soap12HttpPortBinding"
> type="tns:Service10Soap1p2">
> <soap12:binding style="document"
> transport="
> http://www.w3.org/2003/05/soap/bindings/HTTP/" />
> <operation name="echoWithChevrons">
>
> This now works fine:
> Message sent with above code and no policy in WSDL
>
> <?xml version="1.0" encoding="http://www.w3.org/2003/05/soap-envelope"
> standalone="no"?>
> <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
> <soap:Header>
> <wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> soap:mustUnderstand="true">
> <wsse:UsernameToken
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="G572ee91e-c4de-4722-be41-7fb9d5c1bfe2">
> <wsse:Username>u08654</wsse:Username>
> <wsse:Password
> Type="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">test1234</wsse:Password>
> <wsse:Nonce
> EncodingType="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary
> ">6g154NEn/nAXwVHQ0m3m5w==
> </wsse:Nonce>
> <wsu:Created>2014-10-13T09:56:01.062+01:00</wsu:Created>
> </wsse:UsernameToken>
> </wsse:Security>
>
> Now downloading and editing the WSDL is obviously not very desirable to
> have
> to download and edit WSDLs to remove policies and then set up interceptors
> for the security.
>
> Ideally there would be a way to force the nonce and timestamp on the
> policy-based authentication. In fact I would have thought that it should be
> the default following OASIS recommendations
> <
> https://www.oasis-open.org/committees/download.php/13392/wss-v1.0-spec-pr-UsernameTokenProfile-01.htm
> >
> :
>
> /1. It is RECOMMENDED that web service producers reject any
> UsernameToken not using both nonce and creation timestamps.
> 2. It is RECOMMENDED that web service producers provide a
> timestamp
> “freshness” limitation, and that any UsernameToken with “stale” timestamps
> be rejected. As a guideline, a value of five minutes can be used as a
> minimum to detect, and thus reject, replays.
> 3. It is RECOMMENDED that used nonces be cached for a period at
> least as long as the timestamp freshness limitation period, above, and that
> UsernameToken with nonces that have already been used (and are thus in the
> cache) be rejected./
>
> If this is not possible is there an easy way to get CXF to ignore the
> policy
> in the WSDL and use the interceptor-based configuration?
>
> Thanks
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749798.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Summary
I have discovered that when the WSDL contains a policy the "interceptor"
method of configuring CXF is never invoked, it trues to use the policy
method with high-level parameters from SecurityConstants parameters.
Is there a way of forcing the policy-based CXF security processing to
include a nonce and timestamp?
Alternatively, is there a way to prevent CXF from going down the
policy-based execution path?
Detail
This is what I have discovered this morning. I downloaded and saved the WSDL
from the Oracle system, and as previously the program setting an explicit
interceptor failed:
Code
Client client = ClientProxy.getClient(port);
client.getInInterceptors().add(new LoggingInInterceptor());
client.getOutInterceptors().add(new LoggingOutInterceptor());
WSSSecurityProperties properties = new WSSSecurityProperties();
List<WSSConstants.Action> actions = new ArrayList<WSSConstants.Action>();
actions.add(WSSConstants.USERNAMETOKEN);
properties.setActions(actions);
properties.setUsernameTokenPasswordType(WSSConstants.UsernameTokenPasswordType.PASSWORD_TEXT);
properties.setTokenUser("user");
properties.setCallbackHandler(new CXFNameCallbackHandler("test1234"));
properties.setAddUsernameTokenNonce(true);
properties.setAddUsernameTokenCreated(true);
WSS4JStaxOutInterceptor ohandler = new WSS4JStaxOutInterceptor(properties);
client.getOutInterceptors().add(ohandler);
Error
Oct 13, 2014 9:30:41 AM
org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean
buildServiceFromWSDL
INFO: Creating Service {http://tempuri.org/}Service10Soap1p2Service from
WSDL:
file:/C:/Users/u08654/work/workspaces/OwsmWEblogicEclipse/TestCallerWithStaticWsdl/wsdl/Service10Soap1p2Soap12HttpPort.wsdl
Invoking whoAmI...
Oct 13, 2014 9:30:42 AM org.apache.cxf.phase.PhaseInterceptorChain
doDefaultLogging
WARNING: Interceptor for
{http://tempuri.org/}Service10Soap1p2Service#{http://tempuri.org/}whoAmI has
thrown exception, unwinding now
org.apache.cxf.ws.policy.PolicyException: No username available
at
org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:277)
As it was saying "No Username Created" I thought that it was looking for the
SecurityConstants.USERNAME, and in fact proved that if I add the code for
the "non interceptor" version it does not fail but does not send nonce or
timestamp. This made me think that interceptors were ignored when there is a
policy in the WSDL - so I edited the wsdl
Part of Original WSDL
<definitions name="Service10Soap1p2Service"
targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://tempuri.org/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<wsp:Policy xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns="http://schemas.xmlsoap.org/ws/2004/09/policy"
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sp13="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200802"
wsu:Id="wss_username_token_service_policy">
<sp:SupportingTokens
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
<wsp:Policy>
<sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
<wsp:Policy>
<sp:WssUsernameToken10 />
</wsp:Policy>
</sp:UsernameToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:Policy>
<types>
...
<binding name="Service10Soap1p2Soap12HttpPortBinding"
type="tns:Service10Soap1p2">
<soap12:binding style="document"
transport="http://www.w3.org/2003/05/soap/bindings/HTTP/" />
<wsp:PolicyReference
xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
URI="#wss_username_token_service_policy" wsdl:required="false" />
<operation name="echoWithChevrons">
Edited WSDL
<definitions name="Service10Soap1p2Service"
targetNamespace="http://tempuri.org/"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:tns="http://tempuri.org/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
<types>
...
</portType>
<binding name="Service10Soap1p2Soap12HttpPortBinding"
type="tns:Service10Soap1p2">
<soap12:binding style="document"
transport="http://www.w3.org/2003/05/soap/bindings/HTTP/" />
<operation name="echoWithChevrons">
This now works fine:
Message sent with above code and no policy in WSDL
<?xml version="1.0" encoding="http://www.w3.org/2003/05/soap-envelope"
standalone="no"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">
<soap:Header>
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
soap:mustUnderstand="true">
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="G572ee91e-c4de-4722-be41-7fb9d5c1bfe2">
<wsse:Username>u08654</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">test1234</wsse:Password>
<wsse:Nonce
EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">6g154NEn/nAXwVHQ0m3m5w==
</wsse:Nonce>
<wsu:Created>2014-10-13T09:56:01.062+01:00</wsu:Created>
</wsse:UsernameToken>
</wsse:Security>
Now downloading and editing the WSDL is obviously not very desirable to have
to download and edit WSDLs to remove policies and then set up interceptors
for the security.
Ideally there would be a way to force the nonce and timestamp on the
policy-based authentication. In fact I would have thought that it should be
the default following OASIS recommendations
<https://www.oasis-open.org/committees/download.php/13392/wss-v1.0-spec-pr-UsernameTokenProfile-01.htm>
:
/1. It is RECOMMENDED that web service producers reject any
UsernameToken not using both nonce and creation timestamps.
2. It is RECOMMENDED that web service producers provide a timestamp
“freshness” limitation, and that any UsernameToken with “stale” timestamps
be rejected. As a guideline, a value of five minutes can be used as a
minimum to detect, and thus reject, replays.
3. It is RECOMMENDED that used nonces be cached for a period at
least as long as the timestamp freshness limitation period, above, and that
UsernameToken with nonces that have already been used (and are thus in the
cache) be rejected./
If this is not possible is there an easy way to get CXF to ignore the policy
in the WSDL and use the interceptor-based configuration?
Thanks
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749798.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Colm O hEigeartaigh <co...@apache.org>.
> My understanding is that the WSHandlerConstants.ADD_USERNAMETOKEN_CREATED
and
> ADD_USERNAMETOKEN_NONCE are the replacements for these
Correct. I added a (spring-based) test that shows how to use them. If you
are still having problems after looking at this, then create a test-case +
I will take a look:
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blobdiff;f=systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action/client.xml;h=d48aeb495aad84b89ef481726718796544d4b10d;hp=835ec066ecce90f55c4f04c184d51f58d71fc5b4;hb=8e930bcf;hpb=fac67a202f3303b1709ebccef0bc48ddc4838639
Colm.
On Fri, Oct 10, 2014 at 3:06 PM, Chris <cz...@ybs.co.uk> wrote:
> Jason Pell wrote
> > You are using cxf 3.0?
>
> Yes I am
>
>
> Jason Pell wrote
> > For 2.7.x you can use:
> >
> > outProps.put(WSHandlerConstants.ADD_UT_ELEMENTS, WSConstants.NONCE_LN + "
> > "
> > + WSConstants.CREATED_LN);
> >
> >
> > Not sure what the equivalent is for 3.0
>
> My understanding is that the WSHandlerConstants.ADD_USERNAMETOKEN_CREATED
> and ADD_USERNAMETOKEN_NONCE are the replacements for these
>
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749756.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Jason Pell wrote
> You are using cxf 3.0?
Yes I am
Jason Pell wrote
> For 2.7.x you can use:
>
> outProps.put(WSHandlerConstants.ADD_UT_ELEMENTS, WSConstants.NONCE_LN + "
> "
> + WSConstants.CREATED_LN);
>
>
> Not sure what the equivalent is for 3.0
My understanding is that the WSHandlerConstants.ADD_USERNAMETOKEN_CREATED
and ADD_USERNAMETOKEN_NONCE are the replacements for these
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749756.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: CXF client send nonce and timestamp
Posted by Jason Pell <ja...@pellcorp.com>.
You are using cxf 3.0?
For 2.7.x you can use:
outProps.put(WSHandlerConstants.ADD_UT_ELEMENTS, WSConstants.NONCE_LN + " "
+ WSConstants.CREATED_LN);
Not sure what the equivalent is for 3.0
Some examples of what works for 2.7
https://github.com/pellcorp/cxf/blob/master/JavaFirst/src/test/java/com/pellcorp/server/TestUtils.java
On Fri, Oct 10, 2014 at 10:22 PM, Chris <cz...@ybs.co.uk> wrote:
> Not sure if first message got through!
>
> We need to access a service with username/password protection and message
> protection, against an Oracle server. After some tests we realised that it
> did not protect against replay attacks. Configuring the server to require
> timestamp and nonce resulted in an error.
>
> To simplify tings I then configured the service without message protection.
> I can call the service succesfully by setting:
>
> Map<String, Object> props = client.getRequestContext();
>
> props.put(SecurityConstants.CALLBACK_HANDLER,
> new
> Invoker_CXFNameCallbackHandler("password");
> props.put(SecurityConstants.USERNAME, "user");
>
> This adds:
> <wsse:Security
> xmlns:wsse="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
> "
> soap:mustUnderstand="true">
> <wsse:UsernameToken
> xmlns:wsu="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd
> "
> wsu:Id="UsernameToken-bcfd47d6-33cd-477f-8847-0cf21f2b0006">
> <wsse:Username>user</wsse:Username>
> <wsse:Password
> Type="
> http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText
> ">password</wsse:Password>
> </wsse:UsernameToken>
> </wsse:Security>
>
> However I tried adding the nonce and timestamp:
>
> props.put(ConfigurationConstants.ADD_USERNAMETOKEN_NONCE,
> "true");
> props.put(ConfigurationConstants.ADD_USERNAMETOKEN_CREATED,
> "true");
>
>
> This made no difference - the nonce and timestamp are still not set. I also
> tried Boolean values instead of the String "true" and "false"
>
> I have also tried removing the above code and setting:
>
> Map<String, Object> iprops = new HashMap<String,Object>();
> iprops.put(WSHandlerConstants.ACTION,
> WSHandlerConstants.USERNAME_TOKEN);
> iprops.put(WSHandlerConstants.USER , "user");
> iprops.put(WSHandlerConstants.PW_CALLBACK_REF,
> new
> Invoker_CXFNameCallbackHandler("password");
> iprops.put(WSHandlerConstants.ADD_USERNAMETOKEN_CREATED,
> "true");
> iprops.put(WSHandlerConstants.ADD_USERNAMETOKEN_NONCE, "true");
> iprops.put(WSHandlerConstants.PASSWORD_TYPE,
> WSConstants.PW_TEXT);
>
>
> //client.getEndpoint().getInInterceptors().clear();
> client.getEndpoint().getInInterceptors().add(new
> WSS4JInInterceptor(iprops));
> //client.getEndpoint().getOutInterceptors().clear();
> client.getEndpoint().getOutInterceptors().add(new
> WSS4JOutInterceptor());
>
> This gives an error:
>
> Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: No
> username
> available
> at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
> at com.sun.proxy.$Proxy33.whoAmI(Unknown Source)
> at uk.co.ybs.ep10test.Invoker.main(Invoker.java:132)
> Caused by: org.apache.cxf.ws.policy.PolicyException: No username available
> at
>
> org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:277)
> at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addUsernameToken(UsernameTokenInterceptor.java:395)
> at
>
> org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addToken(UsernameTokenInterceptor.java:340)
>
>
> I think I need to find how to pass the ADD_USERNAMETOKEN_NONCE and
> ADD_USERNAMETOKEN_CREATED to the underlying wss4j. How do I do this?
>
> Thanks
> Chris
>
>
>
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749747.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
Re: CXF client send nonce and timestamp
Posted by Chris <cz...@ybs.co.uk>.
Not sure if first message got through!
We need to access a service with username/password protection and message
protection, against an Oracle server. After some tests we realised that it
did not protect against replay attacks. Configuring the server to require
timestamp and nonce resulted in an error.
To simplify tings I then configured the service without message protection.
I can call the service succesfully by setting:
Map<String, Object> props = client.getRequestContext();
props.put(SecurityConstants.CALLBACK_HANDLER,
new
Invoker_CXFNameCallbackHandler("password");
props.put(SecurityConstants.USERNAME, "user");
This adds:
<wsse:Security
xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
soap:mustUnderstand="true">
<wsse:UsernameToken
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
wsu:Id="UsernameToken-bcfd47d6-33cd-477f-8847-0cf21f2b0006">
<wsse:Username>user</wsse:Username>
<wsse:Password
Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">password</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
However I tried adding the nonce and timestamp:
props.put(ConfigurationConstants.ADD_USERNAMETOKEN_NONCE,
"true");
props.put(ConfigurationConstants.ADD_USERNAMETOKEN_CREATED,
"true");
This made no difference - the nonce and timestamp are still not set. I also
tried Boolean values instead of the String "true" and "false"
I have also tried removing the above code and setting:
Map<String, Object> iprops = new HashMap<String,Object>();
iprops.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
iprops.put(WSHandlerConstants.USER , "user");
iprops.put(WSHandlerConstants.PW_CALLBACK_REF,
new
Invoker_CXFNameCallbackHandler("password");
iprops.put(WSHandlerConstants.ADD_USERNAMETOKEN_CREATED,
"true");
iprops.put(WSHandlerConstants.ADD_USERNAMETOKEN_NONCE, "true");
iprops.put(WSHandlerConstants.PASSWORD_TYPE,
WSConstants.PW_TEXT);
//client.getEndpoint().getInInterceptors().clear();
client.getEndpoint().getInInterceptors().add(new
WSS4JInInterceptor(iprops));
//client.getEndpoint().getOutInterceptors().clear();
client.getEndpoint().getOutInterceptors().add(new
WSS4JOutInterceptor());
This gives an error:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: No username
available
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:159)
at com.sun.proxy.$Proxy33.whoAmI(Unknown Source)
at uk.co.ybs.ep10test.Invoker.main(Invoker.java:132)
Caused by: org.apache.cxf.ws.policy.PolicyException: No username available
at
org.apache.cxf.ws.security.wss4j.AbstractTokenInterceptor.policyNotAsserted(AbstractTokenInterceptor.java:277)
at
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addUsernameToken(UsernameTokenInterceptor.java:395)
at
org.apache.cxf.ws.security.wss4j.UsernameTokenInterceptor.addToken(UsernameTokenInterceptor.java:340)
I think I need to find how to pass the ADD_USERNAMETOKEN_NONCE and
ADD_USERNAMETOKEN_CREATED to the underlying wss4j. How do I do this?
Thanks
Chris
--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-client-send-nonce-and-timestamp-tp5749743p5749747.html
Sent from the cxf-user mailing list archive at Nabble.com.