Hello and thank you for reading,

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

On the service side, I'd like to use an authentication framework such as - http://shiro.apache.org/index.html - 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 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 http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html

  Is that a viable alternative? If I used that + something like Apache Shiro would I have a winner?

Thanks,

-Zach

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?