key size and algorithm choices...

[Ron Reynolds <Ro...@RonReynolds.com>]

(repost from axis-users@ per dims' suggestion)

i'm working on adding signatures to my ws requests and want to issue a unique key pair to each
approved client application.  since i want the overhead of security to be insignificant compared
to the overhead of the requested method (i.e., i don't want the addition of security to be a
serious performance hit compared to the system without security) is there an accepted
algorithm/key-size pair that works well?  this is (currently) an in-house app to a resource
management system so i'm not too worried about the ficticious "black-hat" with a Cray and
75 years to try to crack the message - in fact i could probably get by with a MD5 xor with the
client's id to do the trick, but i would like to leverage what basic security xml-sig gives
to give some assurance to my bosses that not just anybody can send messages to the service.

options/experiences folks have had with finding the equilibrium point between security and
performance with ws-security would be greatly appreciated. :)

oh, while on the topic of ws security - in this case the client application is acting on the
part of a user and my thought was to pass all 3 pieces of info (user's staff-id, client's
app-id, and client's message-sig value) as headers (i.e., not have to declare them as part
of the WS interface).  has anyone done this with wss4j?  if so could you send a sample of your
server- and client-config.wsdd files?  i'm not sure if i need 2 WSDoAllSenders or 3 - ditto
with the WSDoAllReceivers.  and i'm sure i'll have questions when i get to working out the
crypto.properties files but that's for a later email. :)  also are there any good sites out
there other than the deployment tutorial and deployment examples on using wss4j?

thanks. :)
.............ron.



---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org