Advertisement

Login and Passoff

Started by January 25, 2005 10:31 AM
5 comments, last by hplus0603 20 years ago
Is it possible to have a dedicated process (login server) on one machine (IP 123.456.789.012) validate a player's login and then pass it off to another dedicated process (game server) on another machine (IP 987.654.321.098)? And can we limit the game server(s) to accept handoff only from the login server(s)? I'm wanting to make sure that the login server is the only process that can hand off a connecting player to a game server! I'm new to TCP programming so please be easy on me. Thanks -- Eric
Fear is the mind killer. But if you have no mind, do you have no fear?
Here's what I think....

Have only one *public* server handling login connections.
Have 'n' *private* server(s) behind firewall managing the game. Thoses servers only accept players validated by the public server.

This way, internet players can't directly connect / attack private servers.
- Iliak -
[ ArcEngine: An open source .Net gaming framework ]
[ Dungeon Eye: An open source remake of Eye of the Beholder II ]
Advertisement
Yes, but I am trying to get mutiple 'public' login servers that are the only processes that can pass off the a game server. I am looking at pushing my game to multiple countries so having just 1 login server is not a viable solution fo people across the world connecting to. Each country are may have 1 to N game servers and 1 to N login servers.

What I need to know is can one machine pass off a client's connection to another machine at another IP Address and port? Can you restrict where a process accepts it passoff to avoid direct connections that attempt to bypass the login server?

The process for my architecture is the following:

User contacts known login server. [Passes UserID/Password encrypted]
Login server decrypts data and validates against database. [User is valid]
Login server knows the IP address/port of the game server(s) and passes off user's connection to the game server.

Is this possible?

Thanks

-- Eric

Fear is the mind killer. But if you have no mind, do you have no fear?
The client will have to connect to the new server and reauthenticate after the passoff. The authentication can be simpler than a full userid/password exchange though. Something like:

Client connects to login server and gives id/password.
Login server authenticates the client.
Login server generates a ticket (basically a long random number)
Login server tells the game server (via a private LAN connection) that if somebody connects and gives the above ticket then assume they're cool.
Login server tells the client the address of the game server and gives them thier ticket.
Client disconnects from the login server and connects to the game server.
Client gives the game server it's ticket and is in.

Note that because of NATs the login and game servers could see the client as coming from completely different addresses. So you can't use the client IP address as part of the authentication.

That should be enough to get you started. If you're really serious about this then eventually you want to google for 'kerberos' and start reading up on that.
-Mike
Quote:
Original post by Anon Mike
Note that because of NATs the login and game servers could see the client as coming from completely different addresses.


Thanks for posting this. NATs what does this stand for? Network Authetication Tickets (assuming) ?

This is exactly (not exactly but pretty damn close) to what I want and need. I assume you will encrypt the ticket and server ip/port to ensure that a user doesn't sniff the packet and get ip addresses.

Thanks for the idea/help and I'll be looking up 'kerberos'.

-- Eric
Fear is the mind killer. But if you have no mind, do you have no fear?
NAT - http://www.webopedia.com/TERM/N/NAT.html

here's how i'd do it:

User connects to login server & authenticates
login server/process accesses a database and flags the user as authenticated
Login server forwards the client to the world server
upon receiving a connection world server checks same database to see if user is flagged as authenticated.

now you just throw the database behind an internal firewall and only allow conenctions from teh login and world servers and your're good to go.

it's a pretty easy to implement solution that is easily expandable. you can just throw in more login servers, db servers, world servers as load requires. 99% sure that this or something very similar is what Blizzard uses for Worlds of Warcraft

-me
Advertisement
The suggested solutions aren't really secure. I wrote up a web page on authentication for games, which addresses this issue (and others). I recommend using digital signature tickets using a shared server secret. See mindcontrol.org for more information.
enum Bool { True, False, FileNotFound };

This topic is closed to new replies.

Advertisement