Web Service Authentication
Paul Michael
Ranch Hand
Posts: 697
posted 9 years ago
I'm new to web services and would like to know the best way for performing user authentication.
Do we just need to send the user/pass every time we make a request? How do we prevent sniffing? If we try to make everything run through HTTPS then this will definitely sacrifice the performance of the application.
Hoping for your suggestions!
Thank you very much.
Do we just need to send the user/pass every time we make a request? How do we prevent sniffing? If we try to make everything run through HTTPS then this will definitely sacrifice the performance of the application.
Hoping for your suggestions!
Thank you very much.
SCJP 1.2 (89%), SCWCD 1.3 (94%), IBM 486 (90%), SCJA Beta (96%), SCEA (91% / 77%), SCEA 5 P1 (77%), SCBCD 5 (85%)
posted 9 years ago
There is a spec for web service security, I'll go look for it.
Basically it provides options for data in the soap header, and includes provisions for authentication, thumbprinting, preventing record and resubmit and other issues at this level. It doesn't prevent snooping.
I had a discussion with a friend a while ago and they recommended using 'INstream' authentication, so that the security part is not included in your message XSD and get managed by a filter separately to the message handling.
It now looks like the conversation and links have been backed up over the weekend and are at home...
Basically it provides options for data in the soap header, and includes provisions for authentication, thumbprinting, preventing record and resubmit and other issues at this level. It doesn't prevent snooping.
I had a discussion with a friend a while ago and they recommended using 'INstream' authentication, so that the security part is not included in your message XSD and get managed by a filter separately to the message handling.
It now looks like the conversation and links have been backed up over the weekend and are at home...
Paul Michael
Ranch Hand
Posts: 697
posted 9 years ago
Hi David!
Thanks for the very quick reply. Is this the same as the WS-Security standard? How mature is it in terms of industry adoption? I'm thinking of using FLEX as front-end with web services as back-end which is probably why all of a sudden I became interested in how to handle authentication with Web Services.
Anyway, hope to see your notes/links soon! Thanks again.
Thanks for the very quick reply. Is this the same as the WS-Security standard? How mature is it in terms of industry adoption? I'm thinking of using FLEX as front-end with web services as back-end which is probably why all of a sudden I became interested in how to handle authentication with Web Services.
Anyway, hope to see your notes/links soon! Thanks again.
SCJP 1.2 (89%), SCWCD 1.3 (94%), IBM 486 (90%), SCJA Beta (96%), SCEA (91% / 77%), SCEA 5 P1 (77%), SCBCD 5 (85%)
posted 9 years ago
I was referring to WS-A
We used FLEX-WS communication using HTTP BASIC authentication and that worked fine, since FLEX manages to keep sending the authentication header. No reason you can't use something more mature like WS-A, but you would need to write the FLEX side yourself, while you should be able to find something that manages the server side already.
We used FLEX-WS communication using HTTP BASIC authentication and that worked fine, since FLEX manages to keep sending the authentication header. No reason you can't use something more mature like WS-A, but you would need to write the FLEX side yourself, while you should be able to find something that manages the server side already.
Ulf Dittmer
Rancher
Posts: 42972
73
posted 9 years ago
WS-Security is mature, and supported by all major SOAP stacks (the spec is linked at http://faq.javaranch.com/java/SpecificationUrls if you're really interested).
If you're concerned about sniffing then I don't really see the difference between sending the password once, or sending it multiple times (for each request). In that case, you should use encryption (not HTTPS, but WS-Encryption, which is also part of WS-Security). By the way, passwords can be sent digested, not in cleartext.
Generally, you'd need to send passwords for each request because there WS don't use sessions - each request looks new to the server. But the WS-Security implementation I've seen let you configure all the authentication and encryption details outside of the code, so it's not something that clutters up the code everywhere you make a WS call.
I wrote an article on how to use WS-Security authentication with Axis 2 that may be of interest.
[ April 15, 2008: Message edited by: Ulf Dittmer ]
If you're concerned about sniffing then I don't really see the difference between sending the password once, or sending it multiple times (for each request). In that case, you should use encryption (not HTTPS, but WS-Encryption, which is also part of WS-Security). By the way, passwords can be sent digested, not in cleartext.
Generally, you'd need to send passwords for each request because there WS don't use sessions - each request looks new to the server. But the WS-Security implementation I've seen let you configure all the authentication and encryption details outside of the code, so it's not something that clutters up the code everywhere you make a WS call.
I wrote an article on how to use WS-Security authentication with Axis 2 that may be of interest.
[ April 15, 2008: Message edited by: Ulf Dittmer ]
Ulf Dittmer
Rancher
Posts: 42972
73
posted 9 years ago
Compared to the overhead of network connections, any effect local computations may have is likely to be negligible.
But more importantly, you can't dispense with security. If you're worried about sniffing, traffic needs to be encrypted - every single call. And being stateless, WS needs authentication for each call.
Trading in security for performance needs to be carefully thought through. In my experience it's easier to improve performance of a system that needs it, than to patch low-grade security (and live with its risks in the first place).
Wont the performance get affected if we send username/password during each request and also that we are encrypting them.
Compared to the overhead of network connections, any effect local computations may have is likely to be negligible.
But more importantly, you can't dispense with security. If you're worried about sniffing, traffic needs to be encrypted - every single call. And being stateless, WS needs authentication for each call.
Trading in security for performance needs to be carefully thought through. In my experience it's easier to improve performance of a system that needs it, than to patch low-grade security (and live with its risks in the first place).
posted 9 years ago
Does ws-security work with ws-resource http://www.ibm.com/developerworks/library/specification/ws-resource/ which aims to make WS stateful
Ulf Dittmer
Rancher
Posts: 42972
73
Peer Reynders
Bartender
Posts: 2968
6
posted 9 years ago
That is an ambiguous smiley. The web service itself doesn't become stateful. It seems to be a specification for a systematic use of correlation identifiers to refer to resources as containers of state.
Originally posted by Prad Dip:
which aims to make WS stateful
That is an ambiguous smiley. The web service itself doesn't become stateful. It seems to be a specification for a systematic use of correlation identifiers to refer to resources as containers of state.
Peer Reynders
Bartender
Posts: 2968
6
posted 9 years ago
If Flex is your primary client then SOAP web services (WS-Security requires SOAP) may not be the ideal choice anyway.
IBM's Project Zero for example uses RESTful web services for its RIAs which can use standard HTTP security measures. Currently the most mature Java API for building RESTful applications is Restlet - Jersey is still a bit away from being ready. Security would be largely handled by the web server hosting the resources.
Is this simply an assumption or did somebody actually profile this? Because you may be causing yourself an awful lot of effort in trying to find and implementing an alternative (which usually introduces a different set of problems) when using HTTPS judiciously may actually do the the trick. Use of HTTPS is so commonplace on the web that I find it difficult to believe that there aren't already all sorts of workarounds to any potential performance problems.
[ April 15, 2008: Message edited by: Peer Reynders ]
Originally posted by Paul Michael:
I'm thinking of using FLEX as front-end with web services as back-end
If Flex is your primary client then SOAP web services (WS-Security requires SOAP) may not be the ideal choice anyway.
IBM's Project Zero for example uses RESTful web services for its RIAs which can use standard HTTP security measures. Currently the most mature Java API for building RESTful applications is Restlet - Jersey is still a bit away from being ready. Security would be largely handled by the web server hosting the resources.
Originally posted by Paul Michael:
If we try to make everything run through HTTPS then this will definitely sacrifice the performance of the application.
Is this simply an assumption or did somebody actually profile this? Because you may be causing yourself an awful lot of effort in trying to find and implementing an alternative (which usually introduces a different set of problems) when using HTTPS judiciously may actually do the the trick. Use of HTTPS is so commonplace on the web that I find it difficult to believe that there aren't already all sorts of workarounds to any potential performance problems.
[ April 15, 2008: Message edited by: Peer Reynders ]
posted 9 years ago
You are right. It is the resource which is stateful.
Originally posted by Peer Reynders:
That is an ambiguous smiley. The web service itself doesn't become stateful. It seems to be a specification for a systematic use of correlation identifiers to refer to resources as containers of state.
You are right. It is the resource which is stateful.
H. Hall
Greenhorn
Posts: 8
posted 9 years ago
If you are running an application server like Tomcat, then you might want to create a session for each user and save state information like "isValidUser" in the user's session object. The web service can then interrogate the session object to insure a valid user is making the request.
For several years, modern user hardware, browsers, and bandwidth has made it possible for Software as a Service providers like salesforce.com and reedyrive.com (my company) to run the entire user's session through a SSL socket while maintaining good performance. Also, SSL not only encrypts the information passed between user and app but also ensures against man in the middle attacks.
----------------------
Hmmm...
After thinking about this, SSL may create too much overhead if you will have lots of small, infrequent requests, and the user interface is not a browser. The overhead is the time required to first exchange certificates which occurs once per session. An alternative is to encrypt and decrypt on both ends, using a key.
You can find an example on Encrypting-Decrypting a File or Stream with DES here:
http://exampledepot.com/egs/javax.crypto/DesFile.html
[ April 18, 2008: Message edited by: H. Hall ]
Do we just need to send the user/pass every time we make a request?
If you are running an application server like Tomcat, then you might want to create a session for each user and save state information like "isValidUser" in the user's session object. The web service can then interrogate the session object to insure a valid user is making the request.
How do we prevent sniffing? If we try to make everything run through HTTPS then this will definitely sacrifice the performance of the application.
For several years, modern user hardware, browsers, and bandwidth has made it possible for Software as a Service providers like salesforce.com and reedyrive.com (my company) to run the entire user's session through a SSL socket while maintaining good performance. Also, SSL not only encrypts the information passed between user and app but also ensures against man in the middle attacks.
----------------------
Hmmm...
After thinking about this, SSL may create too much overhead if you will have lots of small, infrequent requests, and the user interface is not a browser. The overhead is the time required to first exchange certificates which occurs once per session. An alternative is to encrypt and decrypt on both ends, using a key.
You can find an example on Encrypting-Decrypting a File or Stream with DES here:
http://exampledepot.com/egs/javax.crypto/DesFile.html
[ April 18, 2008: Message edited by: H. Hall ]
