Authentication Groups Draft

Things that were bad

• "Group" authentication (subdirectories):
  • Terrible usability: One must specifically authenticate to the subgroup for it to work, or the authority has to do arbitrary guesswork.
    • ie. /login user@authority/directory
    • As for authority guesswork, they can currently guess from the server's IP. The remote port data at this point is irrelevant, and the IP can be hidden by a proxy authority.
  • Inability to express multiple groups
• Web Auth
  • Needs DB access on the consumer end. Could be avoided
  • Disabled by default in the reference implementations. Next to no adoption on the authority end.
  • Only interfaces with websites specifically designed for it (read: none)

Improvements that can be conducted

"Group" authentication

Group preference

The server could take a list of preferred authorities/groups and forward it to the authorities. The setting would be optional.

PREFER_AUTHORITIES authority...
PREFER_AUTHORITIES ct/senior x/ctseniors x/ctoverseniors

When authentifying someone, the server can send the applicable authorities(same host) with the check requestas a prefer parameter. For instance, when querying x.authentication.armagetronad.net:

/armaauth/0.1/?query=check&method=md5user=john&hash=abcd&salt=efgh&prefer=ctseniors&prefer=ctoverseniors

The authority respond with the first group in the list that the user is allowed into.

Additionally, the server can provide a setting that would automatically provide group preferences based on "best" AUTHORITY_LEVEL settings. Similar to /listadmins, this poses a moderate security threat, advertising what authorities grant high access, so this should be disabled by default.

PREFER_AUTHORITIES_AUTO 1
AUTHORITY_LEVEL ct/senior 2
AUTHORITY_LEVEL x/ctsenior 2
AUTHORITY_LEVEL x/ctoversenior 1

/armaauth/0.1/?query=check&method=md5&user=johnhash=abcd&salt=efgh&prefer=ctoverseniors&prefer=ctseniors

An authority could "abuse" this system to voluntarily return different authorities than those requested. This could be used to create server tokens. For example:

PREFER_AUTHORITIES x/tournaments/ladle/servers/myserver
AUTHORITY_LEVEL x/tournaments/players/playing 8
AUTHORITY_LEVEL x/tournaments/players/captain 7

If it were the time for the finals, the authority could identify "myserver" as referring to the server used in the finals, and identify each player as playing or captain or neither, at login time.

Updating preferences

If the preferences have changed while people are in the server, it might be in the best interest of everyone to update the current players' status. Of course, everyone could log out and back in, but that's very impractical.

I suggest instead a mass update mechanism, by sending a bulk query to each authority. For instance:

/armaauth/0.1/?query=refresh&prefer=tournaments/ladle/servers/myserver&users=john&users=may&users=jack

The server may merge all queries to one per authentication host. The authority responds:

USER john@x/tournaments/players/playing
USER may@x/tournaments/players/captain
USER jack@x/tournaments/players

In case a user is not found, the authority should replace the corresponding USER line with:

USER_NOT_FOUND username

This system can be otherwise used to check player GIDs. If it matters, a client should be able to override the server time like such:

/armaauth/0.1/?query=refresh&prefer=tournaments/ladle/servers/myserver&users=john&users=may&users=jack&time=1333333333

On the server end, the server should change the players' GIDs accordingly, elevating players where relevant.

The server could initiate such a refresh at the command of a server admin, or before every new warmup(side note: the warmup system allows for multiple matches to be played simultaneously). All priviledges could also be first revoked at first on such an occasion, for instance for resetting temporary captains.

Web Authentication

OpenID

OpenID would standardize the process into something that has software already available for it. This would result in making it an easier process to convert software to consume OpenIDs. It would be signaled as "openid" in the METHODS response. More info TBD.

Actually use MESSAGE

The server would print the message to the client.