Thanks mayank .I will give that a try.It would be of great help if you can
provide more information/sample code from your server side call
back/configuration(cxf-servlet.xml).
--- Begin Message ---
On Fri, Jun 5, 2009 at 11:48 AM, bharath thippireddy <
[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.
>
> 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
");*
**
*outProps.put("signaturePropFile","etc/Client_Sign.properties");
....*
**
With Regards,
Mayank
>
>
> Thanks,
> Bharath
>
> -----Original Message-----
> From: Mayank Mishra [mailto:[email protected]]
> Sent: Thursday, June 04, 2009 6:54 AM
> To: [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]> 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...........}UsernameToken
>
>
> Dan
>
> >
> >
> > >
> > > Thanks and regards,
> > > Bharath
> > >
> > > -----Original Message-----
> > > From: Daniel Kulp [mailto:[email protected]]
> > > Sent: Tuesday, June 02, 2009 3:57 PM
> > > To: [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]
> > > http://www.dankulp.com/blog
> >
> > --
> > Daniel Kulp
> > [email protected]
> > http://www.dankulp.com/blog
> >
>
>
>
--- End Message ---
