Security

The security mechanisms aim toward ensuring players follow the game rules which is very important in multi-player games.

Security handlers are introduced to cope with cheat detection and to protect the game from being corrupted.

Therefore the basic protections are :

  • players can only send orders to the moderator (no result nor update)
  • orders must only contain references to data
  • players should not be able to issue orders pretending they come from another player
  • order parameters should be validated statically (depending on the order) and dynamically (depending on context)
  • players should only be able to send orders of a specific type if allowed by the game rules

Some of those security handlers may be by-passed in a trusted environnement (like a non-distributed game) however they also may be usefull to check the handlers architecture consistency.



Another form of security handlers cope with checking that players send the proper orders at the proper time (mainly in a serial game).

The orders to compute sometimes depend on a sequence defined by the game design, like one player and/or one kind of orders at a time.

Identification

On player side all commands are assumed to be correctly identified because they only come from the moderator.

Indeed in a distributed environnement the client is supposed to trust the server to which it connects.



On the moderator side unserialized orders must be validated according to the user sending them.

Therefore the moderator should be able to trace the origin of the received orders : players have to identify themselves before sending anything.

Login process e.g. does the io handle the identification ?

UserFactory

Authentication

Password

Private/Public keys

Encryption

Encryption is not specified yet but will probably be handled by serializers (or even by the transport layer ?).

Validator

A specific handler called a validator is in charge of the static checks, it will typically be placed right after the serialization input producer.

It may also be used for debugging purpose before a serialization output consumer in order to check that the commands sent should be accepted by the matching input.

A static check is simply a validation that does not require a context to be performed.



Any command has to be validated before being forwarded to the next consumer according to the following specifications :

  • for an order, the user sending it and the user issuing it must be compatible
  • for an order, the parameters must be references e.g. match data held by the moderator context
  • for an update or result, they should not be sent by another user than a moderator

An order must contain a user parameter identifying who issues the order and the validator must be configured with the user sending the orders once it has been identified and authenticated.



The user issuing a command does not have to be exactly the same as the user sending it : the only requirement is that they are compatible based on game rules.

A given order may be allowed to a group of players, therefore the player sending the order must belong to this group.

Hence the validation is simply ensuring the user sending the order is compatible with the user issuing it e.g. the player belongs to the group.

Order#check()

Computation

dynamic checks : Order#check( Context ) in computation handlers

Order type filters

security handlers for orders (User,Order)

Finite state machines

~ dynamic order type filters