You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by "liav.ezer" <li...@gmail.com> on 2011/07/08 23:04:06 UTC

CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Hello,

I've wrote a CXF based service & added ws security (wss4j 1.5.1) through
Spring xml.

This is the end point configuration:

  	
  		
	      
	      
	        
	          
	            
	            
	            
	          
	        
	      
	    
  	

This is part of the client configuration:


    
      
        
        
        
        
      
    
  

The service is working with the security policy (username-password).
My question is regarding the wsdl file.

I don't understand how the service wsdl doesn't enforce the ws security
policy.
How does the service client will be able to know where & how to add the user
name password.

Thanks.


--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-sw-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4566648.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by "liav.ezer" <li...@gmail.com>.
Ok, thanks for your help & well done on the weblog.

--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4575200.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by Glen Mazza <gm...@talend.com>.
CXF has only a Java interface.  If you're using C++, python, perl, etc., 
or another Java web service stack besides CXF--everything below is 
irrelevant.  If somebody doesn't want to use CXF for the SOAP client, 
that person needs to go that language and/or framework--google it--and 
find out how to create a SOAP client that supports WS-Security with the 
UsernameToken method.  (I wouldn't personally know, so I can't answer 
your question.)  The CXF web service provider will still work with it, 
as long as the incoming XML is correct.  The WSS4J that you mention 
won't be used with most non-Java alternatives--but something else in 
that competitor language that does the same thing would be.

I can only explain CXF and Metro clients (the latter in another 
forum).   If the SOAP client solution you're looking at is so poorly 
documented that it doesn't explain what you want to do with it, has no 
framework, or forum, etc., again, I would recommend switching to a 
solution that *is* documented--CXF, Metro, .NET, Spring Web 
Services--rather than ask people on those forums how to create a 
solution for an undocumented competitor.

Glen

On 07/10/2011 03:51 PM, liav.ezer wrote:
> Yes, i understand that the request is SOAP hence pure xml but what about the
> *Callback *object&  what about the java *interceptor *which need to be
> overloaded with the map properties as below?
> What about the *cxf client*?
>
>          *Client client =
> org.apache.cxf.frontend.ClientProxy.getClient(port);
>          Endpoint cxfEndpoint = client.getEndpoint();
>
>          // Manual WSS4JOutInterceptor interceptor process
>          outProps.put(WSHandlerConstants.ACTION,
> WSHandlerConstants.USERNAME_TOKEN);
>          outProps.put(WSHandlerConstants.USER, "cellact");
>          outProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
>          outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
> ClientPasswordCallback.class.getName());
>
>          WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
>          cxfEndpoint.getOutInterceptors().add(wssOut);*
>
> How will a C++ client (for example) comply to this techniques? Isn't that
> the reason it is called WSS4 Java?
> Thanks.
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4572319.html
> Sent from the cxf-user mailing list archive at Nabble.com.


-- 
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza



Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by "liav.ezer" <li...@gmail.com>.
Yes, i understand that the request is SOAP hence pure xml but what about the
*Callback *object & what about the java *interceptor *which need to be
overloaded with the map properties as below?
What about the *cxf client*?

        *Client client =
org.apache.cxf.frontend.ClientProxy.getClient(port);
        Endpoint cxfEndpoint = client.getEndpoint();

        // Manual WSS4JOutInterceptor interceptor process
        outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
        outProps.put(WSHandlerConstants.USER, "cellact");
        outProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
        outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCallback.class.getName());
                
        WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
        cxfEndpoint.getOutInterceptors().add(wssOut);*

How will a C++ client (for example) comply to this techniques? Isn't that
the reason it is called WSS4 Java?
Thanks.

--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4572319.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by Glen Mazza <gm...@talend.com>.
Not a problem, because with SOAP all you're doing is sending XML back 
and forth--the web service provider is oblivious to the technology used 
by the client--Python, Perl, Java, C++--to create the XML (SOAP) request 
message.  You will require--one way or another--for the XML SOAP request 
envelope, in its SOAP header, to contain the UsernameToken user and 
password information following the WS-Security standard.  At that stage, 
you're done.

The software developer creating the SOAP client has a choice of several 
programming languages and frameworks to send the XML SOAP message over 
HTTP.  (You don't even need a web service stack--Java's 
HTTPUrlConnection can send a raw stream of XML over the wire, and 
probably most other languages have an equivalent.)  Now I documented how 
to create a Java client to access a web service.  If somebody else wants 
to use a different programming language, most fine, but he or she will 
need to find documentation on how to create a SOAP client using that 
language.  If there's no documentation for that developer's choice, 
well, then that person made a pretty poor choice and needs to choose 
another language instead.  :)

Glen


On 07/10/2011 03:26 AM, liav.ezer wrote:
> Thank you Glen for the elaborated answer.
>
> I now understand the 2 approaches.
>
> One thing you mention which i want to make sure is the client step to invoke
> my service (WSS4J based):
>
>
>     1. Create proxy objects based on the wsdl file
>     2. Create a CallBack class such as:
>
> *public class ClientPasswordCallback implements CallbackHandler {
>      private static String password;
>      static {
>          password = "123"; *// we agreed on that over the phone/email*
>      }
>      public void handle(Callback[] callbacks) throws IOException,
> UnsupportedCallbackException {
>          WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
>          pc.setPassword(password);
>      }
> }*
>
> 3. Invoke the Service with additional SOAP header params as follows:
> *
>          UpdateDepositIndSvc ss = new UpdateDepositIndSvc(wsdlURL,
> SERVICE_NAME);
>          DepositIntf port = ss.getDepositSvcPort();
>
>          Map outProps = new HashMap();
>          Client client = org.apache.cxf.frontend.ClientProxy.getClient(port);
>          Endpoint cxfEndpoint = client.getEndpoint();
>
>        *  // Manual WSS4JOutInterceptor interceptor process*
>          outProps.put(WSHandlerConstants.ACTION,
> WSHandlerConstants.USERNAME_TOKEN);
>          outProps.put(WSHandlerConstants.USER, "bob");
>          outProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
>          outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
> ClientPasswordCallback.class.getName());
>
>          WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
>          cxfEndpoint.getOutInterceptors().add(wssOut);
>
>          long id = 1;
>          boolean ind = false;
>          java.lang.Boolean updateDepositIndSvc = port.updateDepositIndSvc(id,
> ind);*
>
> What if the client isn't a Java one but rather C++ or other platform?
>
> Thanks.
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4569834.html
> Sent from the cxf-user mailing list archive at Nabble.com.


-- 
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza



Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by "liav.ezer" <li...@gmail.com>.
Thank you Glen for the elaborated answer.

I now understand the 2 approaches.

One thing you mention which i want to make sure is the client step to invoke
my service (WSS4J based):


   1. Create proxy objects based on the wsdl file
   2. Create a CallBack class such as:

*public class ClientPasswordCallback implements CallbackHandler {
    private static String password;
    static {
        password = "123"; *// we agreed on that over the phone/email*
    }
    public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
        WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
        pc.setPassword(password);
    }
}*

3. Invoke the Service with additional SOAP header params as follows:
*
        UpdateDepositIndSvc ss = new UpdateDepositIndSvc(wsdlURL,
SERVICE_NAME);
        DepositIntf port = ss.getDepositSvcPort();

        Map outProps = new HashMap();
        Client client = org.apache.cxf.frontend.ClientProxy.getClient(port);
        Endpoint cxfEndpoint = client.getEndpoint();

      *  // Manual WSS4JOutInterceptor interceptor process*
        outProps.put(WSHandlerConstants.ACTION,
WSHandlerConstants.USERNAME_TOKEN);
        outProps.put(WSHandlerConstants.USER, "bob");
        outProps.put(WSHandlerConstants.PASSWORD_TYPE, WSConstants.PW_TEXT);
        outProps.put(WSHandlerConstants.PW_CALLBACK_CLASS,
ClientPasswordCallback.class.getName());

        WSS4JOutInterceptor wssOut = new WSS4JOutInterceptor(outProps);
        cxfEndpoint.getOutInterceptors().add(wssOut);

        long id = 1;
        boolean ind = false;
        java.lang.Boolean updateDepositIndSvc = port.updateDepositIndSvc(id,
ind);*

What if the client isn't a Java one but rather C++ or other platform?

Thanks.


--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4569834.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by Glen Mazza <gm...@talend.com>.
It won't--with the traditional WSS4J interceptor approach, client-side, 
you hardcode it to send the username and password via those 
interceptors, and since you hardcoded it, the client will do so every 
time.  Service-side, if you properly configured the WSS4J interceptors, 
it will throw an error if the client doesn't send this information 
(obviously test beforehand with clients that don't send UT info to make 
sure your service is securely configured).  If you're using WSS4J 
service-side, you'll need to use some out-of-band method (phone call, 
email, Tweet, message taped to a pigeon, newspaper or TV advertisement) 
to tell your clients they need to send SOAP headers with UT information.

Alternatively, you can use the WS-SecurityPolicy approach in which you 
add policy statements requiring UT security, and if the SOAP client's 
framework supports WS-SecurityPolicy (Metro and CXF both do), it will 
automatically handle the usernameToken security on their side.  But how 
they handle UT security on their side is really immaterial, whether 
their SOAP framework can automatically read the WS-SecPol and send UT 
that way, or if they choose to hardcode the SOAP Header with the UT 
stuff and ignore the WSDL Policy statements--it doesn't matter, what's 
important is that your web service provider returns an error if it 
doesn't get the UT stuff.

The blog entry covers both types -- WSS4J interceptor approach and 
WS-SecPol approach.

Glen

On 07/09/2011 04:30 PM, liav.ezer wrote:
> Hi, thank you for the quick reply.
> I'm using wss4j interceptors to enforce username token via ws security.
> My question basically is to understand the concept.
> If my client want to invoke the service, I need to supply him with the wsdl file. Then he will generate a client&  should be able to invoke the service. But according to your article, this approach (wss4j interceptors) doesn't reflect the need for username nor password to invoke the service. So how will the client know the needs&  apply a proper request to the service?
> Thanks.
>
> Liav
>
> ב-9 ביול 2011, בשעה 23:11, "Glen Mazza-3 [via CXF]"<ml...@n5.nabble.com>  כתב/ה:
>
>> At least in my mail client I'm not seeing any configuration, just
>> whitespaces, in your question below.  If you're using UsernameToken,
>> that information will be added by CXF in the soap:header.  See:
>> http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile for more
>> detail.
>>
>> If you using basic auth with SSL, that's normally enforced by the
>> web.xml in the WAR hosting your web service provider, although I think
>> at least part of that can be additionally declared in policy statements
>> as well.
>>
>> Glen
>>
>> On 07/08/2011 05:04 PM, liav.ezer wrote:
>>
>>> Hello,
>>>
>>> I've wrote a CXF based service&   added ws security (wss4j 1.5.1) through
>>> Spring xml.
>>>
>>> This is the end point configuration:
>>>
>>>     	
>>>     	
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>     	
>>>
>>> This is part of the client configuration:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> The service is working with the security policy (username-password).
>>> My question is regarding the wsdl file.
>>>
>>> I don't understand how the service wsdl doesn't enforce the ws security
>>> policy.
>>> How does the service client will be able to know where&   how to add the user
>>> name password.
>>>
>>> Thanks.
>>>
>>>
>>> -- 
>>> View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-sw-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4566648.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>
>> -- 
>> Glen Mazza
>> Application Integration Division
>> Talend (http://www.talend.com/ai)
>> blog: http://www.jroller.com/gmazza
>>
>>
>>
>>
>> If you reply to this email, your message will be added to the discussion below:
>> http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4568867.html
>> To unsubscribe from CXF web service with ws security - Why the wsdl doesn't demand the username/pwd?, click here.
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4568888.html
> Sent from the cxf-user mailing list archive at Nabble.com.


-- 
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza



Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by "liav.ezer" <li...@gmail.com>.
Hi, thank you for the quick reply.
I'm using wss4j interceptors to enforce username token via ws security.
My question basically is to understand the concept.
If my client want to invoke the service, I need to supply him with the wsdl file. Then he will generate a client & should be able to invoke the service. But according to your article, this approach (wss4j interceptors) doesn't reflect the need for username nor password to invoke the service. So how will the client know the needs & apply a proper request to the service?
Thanks.

Liav

ב-9 ביול 2011, בשעה 23:11, "Glen Mazza-3 [via CXF]"<ml...@n5.nabble.com> כתב/ה:

> At least in my mail client I'm not seeing any configuration, just 
> whitespaces, in your question below.  If you're using UsernameToken, 
> that information will be added by CXF in the soap:header.  See: 
> http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile for more 
> detail. 
> 
> If you using basic auth with SSL, that's normally enforced by the 
> web.xml in the WAR hosting your web service provider, although I think  
> at least part of that can be additionally declared in policy statements 
> as well. 
> 
> Glen 
> 
> On 07/08/2011 05:04 PM, liav.ezer wrote:
> 
> > Hello, 
> > 
> > I've wrote a CXF based service&  added ws security (wss4j 1.5.1) through 
> > Spring xml. 
> > 
> > This is the end point configuration: 
> > 
> >    	
> >    	
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> >    	
> > 
> > This is part of the client configuration: 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > The service is working with the security policy (username-password). 
> > My question is regarding the wsdl file. 
> > 
> > I don't understand how the service wsdl doesn't enforce the ws security 
> > policy. 
> > How does the service client will be able to know where&  how to add the user 
> > name password. 
> > 
> > Thanks. 
> > 
> > 
> > -- 
> > View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-sw-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4566648.html
> > Sent from the cxf-user mailing list archive at Nabble.com.
> 
> 
> -- 
> Glen Mazza 
> Application Integration Division 
> Talend (http://www.talend.com/ai) 
> blog: http://www.jroller.com/gmazza
> 
> 
> 
> 
> If you reply to this email, your message will be added to the discussion below:
> http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4568867.html
> To unsubscribe from CXF web service with ws security - Why the wsdl doesn't demand the username/pwd?, click here.


--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-ws-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4568888.html
Sent from the cxf-user mailing list archive at Nabble.com.

Re: CXF web service with sw security - Why the wsdl doesn't demand the username/pwd?

Posted by Glen Mazza <gm...@talend.com>.
At least in my mail client I'm not seeing any configuration, just 
whitespaces, in your question below.  If you're using UsernameToken, 
that information will be added by CXF in the soap:header.  See: 
http://www.jroller.com/gmazza/entry/cxf_usernametoken_profile for more 
detail.

If you using basic auth with SSL, that's normally enforced by the 
web.xml in the WAR hosting your web service provider, although I think 
at least part of that can be additionally declared in policy statements 
as well.

Glen

On 07/08/2011 05:04 PM, liav.ezer wrote:
> Hello,
>
> I've wrote a CXF based service&  added ws security (wss4j 1.5.1) through
> Spring xml.
>
> This is the end point configuration:
>
>    	
>    		
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
> 	
>    	
>
> This is part of the client configuration:
>
>
>
>
>
>
>
>
>
>
>
>
> The service is working with the security policy (username-password).
> My question is regarding the wsdl file.
>
> I don't understand how the service wsdl doesn't enforce the ws security
> policy.
> How does the service client will be able to know where&  how to add the user
> name password.
>
> Thanks.
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-web-service-with-sw-security-Why-the-wsdl-doesn-t-demand-the-username-pwd-tp4566648p4566648.html
> Sent from the cxf-user mailing list archive at Nabble.com.


-- 
Glen Mazza
Application Integration Division
Talend (http://www.talend.com/ai)
blog: http://www.jroller.com/gmazza