How will we approach user login to the application?

[pdushkin]

Per our discussion about how to log a user/customer into the mobile application, I am guessing it works such that the user is required to login and then the user's credentials are stored in the headers for future requests. Unfortunately, I don't know how Java does it. However, maybe these links are helpful?

http://stackoverflow.com/questions/6828344/spring-security-login-with-rest-web-service

Which led me to this:

http://static.springsource.org/spring-security/site/docs/3.0.x/reference/preauth.html

Follow up to this thread if the above links are not helpful and you have questions. Maybe Peter P has ideas.

[pdushkin]

Hi guys,

Sorry for being missing in action. I finished moving house, now living surrounded by packing boxes.

Shekhar, can you explain in an email what the problem regrading authentication is? Perhaps I can help. Overall, we should try that the Libereco middleware never has to store Ebay/Etsy passwords directly, only authentication tokens provided by marketplaces.

Cheers, Peter P

[pdushkin]

Hi Peter,

The question Shekhar had was related to user authorization (simply, logging into the application). I have done this in the past (using WCF/IIS) using HTTP digest authentication. At the time, we chose Digest becaue it was a more secure choice than Basic (no clear text transmission & challenge/response) but I am open to other options. Unfortunately, I don't know how to implement this in Java but below are the basic concepts for Digest:

The client sends an HTTP request (e.g. a GET) to a web server The server sees the URL being accessed has been configured to require Digest authentication and replies with a 401 "Authentication Required" status plus a "nonce": a unique hash of several data items, one of which is a secret key known only to the server. The client shows a dialog box requesting username and password. Once the user enters their information, an MD5 hash of the username, password, nonce and URL are computed and the browser re-sends the original request along with the hash. The web server compares that hash with it’s own computation of the same values. If they match, the original HTTP request is allowed to complete.

That's the basic idea. Also, @Shekhar, below is a useful link that explains how to use Digest authentication in SoapUI. This might be a good place to start if we are agreed that Digest is the way to go for us.

http://blog.smartbear.com/software-quality/bid/169684/How-to-Use-Digest-HTTP-Authentication-in-soapUI

@Peter, what do you think?

Best, Peter D

[pdushkin]

Hi guys,

I spent some time looking into this. HTTP digest authentication is certainly one way to go. Spring Security has support for it. The only question is if it integrates well with our Libereco REST API and can be supported easily by Android/iOS clients.

What does the Libereco REST API look like? Do you assume that each API call includes authentication data (eg a token)?

There is much discussion of this on the web but there are no simple out-of-the-box solutions:

http://stackoverflow.com/questions/3963877/creating-an-api-for-mobile-applications-authentication-and-authorization

google for "spring security rest authentication android client"

On a different but related note, I would suggest to make all REST requests use https. The world is moving in that direction and in general it is a good idea.

Peter, do you own a domain that you could get SSL certificates for?

Let me know what you think.

Cheers, Peter P