Dan/Mayank,

Thanks a lot for all the sample code and information .I could get the UT and 
encryption working together.I could not configure the interceptors at a bus 
level using the cxf-servlet.xml.Is this the right file or should we use a 
separate cxf.xml?

Thanks again,
Bharath

-----Original Message-----
From: Mayank Mishra [mailto:[email protected]] 
Sent: Thursday, June 11, 2009 2:15 AM
To: [email protected]
Subject: Re: Securing User Name Token using CXF?

Mayank Mishra wrote:
>
>
> On Fri, Jun 5, 2009 at 11:48 AM, bharath thippireddy
> <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Thanks Mayank.I currently have a call back defined for the
>     usernametoken password like below and it works fine.
>
>     <entry key="passwordCallbackRef">
>             <ref bean="myPasswordCallback"/>
>      </entry>
>
>     Can you please let me know ,how do we declare another call back
>     for the keystore password retrieval?
>
>
> I have used only one callback, so eventually the same usename and
> keystore alias entry. I will check out the patch and will let you know
> about this soon.
It works! Even I tried applying the patch submitted by Colm for wss4j
1.5.8-SNAPSHOT. This makes it work with different username and keystore
alias entry. The same callback will be used by WSHandler to invoke
hanlder() but with different WSCallBack usage()
{WSPasswordCallback.USERNAME_TOKEN and WSPasswordCallback.SIGNATURE}. We
just require to specify one more entry on OUT configuration props as
("signatureUser","x509user");

With Regards,
Mayank

[1]. http://people.apache.org/~coheigea/stage/wss4j/1.5.8-SNAPSHOT/
>
>
>     And when I use <entry key="action" value="UsernameToken Encrypt"/>
>     the deployment doesn't go through.Has any one tried using
>     UsernameToken and encryption together?
>
>
> Yes, I have used both UsernameToken Encrypt together, they all work
> fine. Can you give the exception trace of the deployment failure.
>
> Following is my sample code for your reference:
>
> /Map<String, Object> outProps = new HashMap<String, Object>();
> outProps.put("action", "UsernameToken Timestamp Signature Encrypt");/
> //
> /outProps.put("passwordType", "PasswordDigest");
> outProps.put("user", "clientx509v1");
> outProps.put("passwordCallbackClass",
> "demo.wssec.client.UTPasswordCallback");/
> //
> /outProps.put("encryptionUser", "serverx509v1");
> outProps.put("encryptionPropFile", "etc/Client_Encrypt.properties");
> outProps.put("encryptionKeyIdentifier", "IssuerSerial");
> outProps.put("encryptionParts","{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd}Timestamp;{Element}{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}UsernameToken;{Content}{http://schemas.xmlsoap.org/soap/envelope/}Body
> <http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd%7DTimestamp;%7BElement%7D%7Bhttp://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd%7DUsernameToken;%7BContent%7D%7Bhttp://schemas.xmlsoap.org/soap/envelope/%7DBody>");/
> //
> /outProps.put("signaturePropFile","etc/Client_Sign.properties");
> ..../
> //
>
> With Regards,
> Mayank
>
>
>
>     Thanks,
>     Bharath
>
>     -----Original Message-----
>     From: Mayank Mishra [mailto:[email protected]
>     <mailto:[email protected]>]
>     Sent: Thursday, June 04, 2009 6:54 AM
>     To: [email protected] <mailto:[email protected]>
>     Cc: bharath thippireddy
>     Subject: Re: Securing User Name Token using CXF?
>
>     On Thu, Jun 4, 2009 at 1:31 AM, Daniel Kulp <[email protected]
>     <mailto:[email protected]>> wrote:
>
>     > On Wed June 3 2009 2:48:32 pm bharath thippireddy wrote:
>     > > Thanks for the answers Dan.From the following post I see that
>     using the
>     > > UsernameToken header and encryption together with wss4j/cxf
>     has issues.
>     >  Are
>     > > they resolved now.
>     >
>     > From that thread, I'm not really sure what the "issue" is.   It
>     looks like
>     > it's mostly Fred being Fred.   (Fred is incredibly paranoid)
>     If the goal
>     > is
>     > just to make sure the UsernameToken is encrypted with a
>     particular key,
>     > then
>     > it should work fine to not expose the password.   Fred is also
>     concerned
>     > about
>     > about other attacks where someone takes the encrypted element
>     (and all the
>     > other relevant stuff from the security header) and attaches it to a
>     > different
>     > soap "body".   In that case, the attacker doesn't need to know the
>     > password.
>     > Thus, to avoid that, you then start to need signatures using a
>     client cert,
>     > probably timestamps with nonces, etc....   That's where Fred was
>     going.
>     >
>     > > If yes will there be two password callbacks ,one for the
>     > > keystore password and the other for the password in the
>     usernametoken.
>     >
>     > Yep.
>     >
>     > > This post on X509 encryptiong usingCXF is interesting but does
>     not use
>     > > UserNameTokens
>     > >
>     > >
>     http://www.jroller.com/gmazza/entry/implementing_ws_security_with_the
>     > >
>     > > Can you please point me to some CXF samples which use the x509
>     cert
>     > > encryption or other wss4j-encryption methods which encrypt
>     only the Soap
>     > > Headers(usernametoken) .
>     >
>     > Well, one thought is to use SecurityPolicy, but that then loses
>     your "apply
>     > to
>     > global bus level" thing that you want as the SecurityPolicy
>     stuff is just
>     > wsdl
>     > based right now.  (on my todo list to address)
>
>
>     "Different callbacks" - patch for the Issue [1] is there, but
>     issue is not
>     yet been resolved, wss4j versions before 1.5.8 will use only one
>     callback
>     for both. Hence, username and encryption users requires to be the
>     same.
>     Unless you apply patches.
>
>     "apply to globas bus level" - But even with WS-SecurityPolicy, we
>     can apply
>     the PolicyReference [2] or embed policy at Service level, which
>     applies to
>     any message exchange using any of the endpoints offered by that
>     service,
>     right?
>
>     With Regards,
>     Mayank
>
>     [1]. https://issues.apache.org/jira/browse/WSS-194
>     [2]. http://www.w3.org/TR/ws-policy-attach/
>
>
>     I THINK you can do it with another property to the WSS4J handlers:
>
>     encryptionParts={Element}{http://docs.oasis-op.
>     <http://docs.oasis-op./>..........}UsernameToken
>
>
>     Dan
>
>     >
>     >
>     > >
>     > > Thanks and regards,
>     > > Bharath
>     > >
>     > > -----Original Message-----
>     > > From: Daniel Kulp [mailto:[email protected]
>     <mailto:[email protected]>]
>     > > Sent: Tuesday, June 02, 2009 3:57 PM
>     > > To: [email protected] <mailto:[email protected]>
>     > > Cc: bharath thippireddy
>     > > Subject: Re: Securing User Name Token using CXF?
>     > >
>     > > On Tue June 2 2009 3:06:52 pm bharath thippireddy wrote:
>     > > > We are implementing User Name Token Profile for login on
>     each web
>     > service
>     > > > call to our application. Can you please answer the following
>     questions.
>     > > >
>     > > >
>     > > >
>     > > > 1)We use the cxf-servlet.xml file to configure our
>     endpoints. Is there
>     > a
>     > > > way to enable wss4j and username token profile callback
>     functionality
>     > at
>     > > > a global(BUS) level instead of adding the line below to each
>     endpoint.
>     > >
>     > > Yea.   The "<cxf:bus>" element can be used to add the
>     interceptors to the
>     > > Bus itself.   That will apply to all the endpoint on the bus.
>     > >
>     > > > 2) What is best recommended approach to secure the username and
>     > password
>     > > > on each call? Is it HTTPS or are there  other ways to do it
>     which are
>     > > > also interoperable?
>     > >
>     > > HTTPs would be the best performing.   The other option is to
>     fully use
>     > WS-
>     > > Security and use an X509 cert to encrypt the UsernameToken
>     header in the
>     > > message.
>     > >
>     > >
>     > > --
>     > > Daniel Kulp
>     > > [email protected] <mailto:[email protected]>
>     > > http://www.dankulp.com/blog
>     >
>     > --
>     >  Daniel Kulp
>     > [email protected] <mailto:[email protected]>
>     > http://www.dankulp.com/blog
>     >
>
>
>


Reply via email to