I've been designed a WS and I really dont know where is the best place to receive credencial informations ! here the options:
1 - HTTP Headers ? Why ?
2 - SOAP Headers ? What's diferents between HTTP and SOAP headers ?
3 - Methods signature ? It's not a good place, but works !
4 - I can use HTTP Basic login/password too.
So...where have you been used ?
My bet is 2 - in the SOAP headers.
In addition, security code should preferably be implemented in a handler, to keep it separate from the service implementation and make it easily exchangeable.
First of all, if you change the underlying transport protocol from HTTP to, for instance, JMS, then there are no HTTP headers and you will have to change the entire security model.
Putting the information in the SOAP headers is the solution that does not limit future options.
Regarding 3: Mixing business and security implementations is not a good idea. If you ever want to change the security used by the service and have credential information in method parameters, then you have quite some work to do.
Regarding 4: HTTP basic security works well with HTTP. Again, if you decide to change transport protocol, then you will need to perform some extra work to change the security model.
Thanks a lot for yours tips
I'll use SOAP headers...But I dont know wich API I'll choose, maybe AXIS that dont have handler or have ?
By the way, I'm using your PDF to study for JWS certifications !!
The standard way to secure SOAP services is to use WS-Security, which is supported by all major SOAP stacks, including Axis (check out its Rampart module). It adds all the required SOAP headers so you don't need to mess with those.
Thanks for sugestion...I've just started in WS...I certainly will read about.
However, I think SSL + SOAP WS + Login/password in SOAP Header solve everything.
Any objections ?
Joined: Mar 22, 2005
If you're asking me whether I think that rolling your own WS security solution is a good idea, then - no, I don't think it is. Security (not just for WS) is a hard issue to get right, and rolling your own -when a very capable and trustworthy implementation already exists- means re-inventing the wheel with fewer features and most likely less security.