Difference between revisions of "BZAuthd"

From BZFlagWiki
Jump to: navigation, search
(import fiberchunk's original writeup (entirely unedited nor reviewed still) as a starting point)
m (Protected "BZAuthd": this page is a developer planning page, not intended for public edit [edit=autoconfirmed:move=autoconfirmed])
(No difference)

Revision as of 18:20, 20 March 2007

BZAuthd is the name being given to the game authorization and account management daemon, being implemented as a replacement to the current global account management system used in 2.0.

Problem Statement

Currently, BZFlag implements authorization in a mixed-mode fashion. The majority of authorization processes are carried out by querying the forum username / password database. Essentially, a player starts the game client, enters in their username and password info, and clicks the 'Connect' menu item. The client then contacts my.bzflag.org and transmits the username password pair, wherein the MySQL database for the forum is queried and my.bzflag.org transmits to the server if the client is identified.

The problem can be summed up as follows: there should be one 'unified' gatekeeper for any and all clients in the bzflag world (e.g. Bzflag, bzfs, web services, stats, etc). That gatekeeper should be able to query a singular point for validation and permissions associated to a particular client. This allows not only for easy maintenance, but also for easier administration of user actions (adding to groups, cancelling accounts, removal of abusers, etc.) This system aims to also support 'passwordless' authentication and authorization of any given client, and will eventually support a 'karma' system of credibility for server and bzflag clients. The system should also support temporary, or anonymous, users for a period of time. Of course, anonymous servers (i.e. Servers that do not require the registration or the identification process), will exist, and thus people will play there who do not wish to run identified or authorized. Their accounts will be severely limited, and hopefully, those clients who wish to have a long-term presence in the bzflag community, will register, thus reaping the rewards of those associated actions.

What we need to do is to clarify the problem domain further, and then, break the component parts down into manageable pieces.

Definitions

CLIENTS

anything that needs read-write, read-only, or authorization services from my.bzflag.org

BZAUTHD

Essentially, the gatekeeper that talks to all clients. Responsible for negotiating the sending and receiving of tokens between client and server applications for purposes of joining a game, receiving a list of servers (and their capabilities), and registering new clients. Talks to all clients of the bzflag universe. Responds to server requests for user identity information and permissions. Informs bzflag clients of their permissions. Reads and writes to LDAP server and potentially certificate generating authority. Should serve as interim caching mechanism for writes to LDAP server in case main goes offline for whatever reason. Once main is online, cache pops data out in timed intervals to sync whatever data needs to be synced until cache is empty. INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).

LDAP SERVER

The main storage for all clients (bzfs clients, bzflag clients, web services (phpbb, drupal, etc), anything else). Should be broken down further into a 'main' repository (i.e. The master), and replications (read-only in case of failure of primary). INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).

CERTIFICATE GENERATOR

The primary driver behind certificate generation and revocation for clients. Certificate generation for a user should give registered and validated users (whether a service or an actual player) some manner of positive karma because of that process. INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)

KARMA DATABASE

The database that ties in with the Directory of clients that primary LDAP provides. 'Grades' clients based on a number of factors (registered / validated, 3rd party ratings, length of time in community and activity, volunteer activities, etc) and assigns appropriate pre-defined levels of positive karma. Distributes this information across the bzflag spectrum. INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS.

BZFLAG

The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play. INTERFACES WITH: BZAUTHD, BZFS.

BZFS

The game server. Responsible for verifying the identity of users, informing users if they need to register to play there, and keeping track of karmic issues. INTERFACES WITH: BZAUTHD, BZFLAG.

BZPORTAL

Primary BZFlag 'jumping off point' that aggregates all known official BZFlag entities in one easy to access, user-friendly area. Integrates the following items listed below. INTERFACES WITH: BZAUTHD, LDAP.

BZFORUMS

Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc. INTERFACES WITH: BZPORTAL.

BZSTATS

Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients. INTERFACES WITH: BZPORTAL.

Overview Diagram

Diagram not yet uploaded.

Notice also that for redunancy, we've allowed for multiple LDAP replicants. However, these replicants should not be fully read-write, but just readable, in case of failure of primary 'master' LDAP server – thus contributing to only one area of maintenance. The LDAP replicants should be self-syncing to the master LDAP server.

The karma database, it should be noted, with proper initial design and setup, should essentially be self-maintaining.

Use Cases

FAILURE CASES

  • LDAP SERVER (master) dies:
    • BZAUTHd falls over to querying the LDAP replicants for player information.
    • New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.
  • KARMA SERVER (master) dies:
    • BZAUTHd falls over to querying Karma replicant(s) for client karma.
  • BZAUTHD dies:
    • Fall over to other hosted, trusted BZAUTHd process.
    • Fail gracefully – no cache data blown away, etc.
  • CERTIFICATE GENERATOR dies:
    • Temporarily suspend new account creation.
    • Limit new account creation to temporary account types only.
    • Cache new account data, and resubmit when service is available.

Design Questions

  • Should or can the Karma server and LDAP server be one and the same?
    • PROVIDES: easier maintenance, both autonomously and manually
    • PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)
    • PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)
  • Should or can certificate generation be done by one of the preexisting processes?
    • BZAUTHD (not sure)
    • LDAP (likely if possible)
    • KARMA (unlikely – doesn't seem to make logical sense)