I'm trying to find a solid architecture for authenticating users against a database. I have a game client, which I plan to serve up a request with. The transport doesn't really matter, but at this point I'm thinking HTTP and leveraging either SSL or WS-Security to ensure the encryption of data over the wire.
I'd like to avoid middle-man attacks if possible so I'm leaning towards WS-Security even though I know it costs more in terms of overhead.
On the service side, I'd like to use an authentication framework such as Apache Shiro to authenticate users against a MySQL database. I'm not sure if I can leverage the session features or not, as I haven't looked that for into it, but it'd be great if I could.
It will probably be a mix of storing some session information in the database and if I can leverage Shiro's session features then that's a bonus.
My real question is about the handshake between the client and server. If I use WS-Security isn't all that taken care of for me? Does that alone make the overhead worth it?
If not, what should I do here? I want to make sure all of the requests from the client are authenticated but I also don't want to have to jump through hoops to make it happen. Would something as simple as HTTP digest authentication work here?
One constraint I have is access to libraries. If it's not free and can't be used in a commercial product then I can't leverage it. My client is going to be written in C++ and I can use whatever language makes it easiest (I'm leaning towards Java) to make it happen on the server side.
I plan on adding support for users to purchase in-game items through micropayments down the road, so this handshake mechanism definitely needs to be secure.
I keep hearing people suggest REST + SSL, and to examine Amazon's Signing and Authenticating REST Requests page. Is that a viable alternative? If I used that and something like Apache Shiro would I have a winner?