Web Service Authentication

[Paul Michael]

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.

[David O'Meara]

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...

[Paul Michael]

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.

[David O'Meara]

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.

[Ulf Dittmer]

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 ]

[Pradeep bhatt]

Ulf,

Wont the performance get affected if we send username/password during each request and also that we are encrypting them.

[Ulf Dittmer]

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).

[Pradeep bhatt]

Does ws-security work with ws-resource http://www.ibm.com/developerworks/library/specification/ws-resource/ which aims to make WS stateful

[Ulf Dittmer]

ws-resource

A 5-part specification to make WS stateful!

[Peer Reynders]

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]

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 ]

[Pradeep bhatt]

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]

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 ]