[muscle] Authenticated access / private data

I am writing multiplayer card games which may very well use the MUSCLE toolkit 
for communication and server state data. As with most multiplayer games, the 
server needs to handle user authentication and hold private state information 
on the server side (assuming any client can be hacked).

MUSCLE's elegant design makes most of this very easy, but I would like advice 
from somebody with more MUSCLE experience than I have on the best strategies 
for doing user authentication and holding private state information on the 
server side.

For user authentication, I typically want the server to authenticate the 
client using a challenge/response scheme (think md5 or traditional 
username/password authentication) and setting some flag in the server-side 
state data that says "authenticated". The natural place to put it would be 
below the session tree in a StorageReflectSession (to allow people playing 
multiple sessions simultaneously), but since the clients have full read and 
write access below their respective trees, this could hardly be considered 
safe, and best case "security by obscurity".

Holding server state data is similar. In any card game, and lots of other 
games, some information is "public" (table cards, game board) and other 
information is "private" (private cards, event cards etc.). My software will 
allow disconnected clients to reconnect and "resume" where they left off, 
which means server side state data (except possibly authentication data as 
explained earlier) will be stored _outside_ the IP-address/session trees for 
each client (since these trees are lost when clients disconnect). So I am 
probably going to be creating a similar tree to the IP address/session trees 
which does not go away when the client disconnects, so that on a client 
reconnect event the server will be able to figure out where the client left 
off. Each client will get full access to its state data after successful 
authentication.

When explaining this, I get the feeling that the authentication part and 
holding authentication tokens is trivial _if_ I am able to solve the other 
challenge; controlling access to parts of a MUSCLE database based on some 
authentication token which can be stored below the IP-address/session tree.

Any advice would be appreciated.

Regards,

Marius Kjeldahl

Other related posts: