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
>
