Thanks Marc that is what my hunch was too, just needed some confirmation. Perhaps we should use the WSS token to sign our XML payload. That will give us assurance that the caller is who they say they are + the added benefit of message integrity.
Can anyone share performance numbers on what the relative cost of using WSS4J signature processing is? For example how much added overhead to configure WSDoSender/Receiver to process token sig like this: <parameter name="action" value="UsernameTokenSignature UsernameToken Encrypt Timestamp"/> We're going to run some tests on it but would like to know what experiences others have had. We are a high-volume financial services HUB and want to ensure that we can sustain heavy load by doing these crypto functions in software. Thanks --- Marc Jadoul <[EMAIL PROTECTED]> wrote: > Does not seems reasonnable to me. Public key is > public. Public key is not > protected in the keystore, only private key are. In > addition, it is shared > by all client in your case. > So, if it (the public key) is "stolen", what do you > do? You should then > update all your client. > > But if you add a secret in the request, for instance > a password in the > usernametoken, it would be OK. But again, the > password should be unique for > each client. > > Marc > > On 8/7/07, Shawn McKinney <[EMAIL PROTECTED]> > wrote: > > > > (Sorry for the dup post I sent wrong list > earlier.) > > > > Greetings, > > > > We have been using WSS4J and Axis successfully in > our > > SOA's for a couple of years now. > > > > Specifically we use WSDoAllSender/Receiver WSS4J > > handler's to insert and validate the WSS Username > > token on both client and server sides. > > > > The config we generally use for WSS creds is: > > > > Usernametoken encrypt timestamp > > > > My question is sort of a general question in terms > of > > securing the server endpoint. > > > > We want to ensure that the server endpoint isn't > > vulnerable to attacker who can spoof a WSS > > transaction. We don't want an attacker to be able > to > > use the server's public key, generate a WSS token > and > > send transactions on behalf of an otherwise > authorized > > user. > > > > If we keep the server's public key only in the > > authorized client's java keystore and not share it > > with other parties can we be assured (reasonably > > speaking) that noone else could also generate a > WSS > > token? > > > > The server's public key would be generated by > internal > > mechanism and not be available via X.509 outside > of > > this network. > > > > Is this notion of keeping a public key secret to > > ensure others can't transaction with server > > reasonable? > > > > Thanks in advance for your reply, > > > > Shawn McKinney > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > -- > Please note that my messages are kept by google. Do > not send sensitive > information on this email address unencrypted. > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
