Shoals Surfer
Posts: 270
Joined: Sunday, 23rd March 2014, 23:51
Crawl Central Authentication/Single Sign On
One thing that's been brought up often has been making a single sign-on style system for Crawl Scoring in order to resolve issues involved with how the Scoring website collects it's data, such as some players registering another player's name on a server where the latter had not yet registered their name (whether or not it is malicious) and influencing that player's score page/streaks. I've been working on a potential solution to this through the introduction of a central authentication website that would either be integrated into Scoring itself, or working with it as a companion site. I was going to wait until I had at least a semi-functional prototype (which I am currently developing using C#/.NET) running before posting anything about it here, but I've been busy/slacking for most of the free time that I would have to mess around with making it for the past couple months. Thus, I'm sharing all the design documentation I've created thus far. Even though I will still be working on it myself, I feel it may be beneficial to anyone with more free time/more work ethic to have this information in case they may feel that I am working too slowly towards creating it.
------------------------------------------------------
What is Crawl Central Authentication?
The idea behind Crawl Central Authentication (or CCA, from now on) is to allow users to create a centralized account for players to link any accounts they may have on any server that is connected to Scoring. This will enable players who have multiple accounts on a single server (or different nicknames on multiple servers) to properly aggregate and score their Crawl games on a single Scoring page, as well as protecting their records from malicious players. CCA will achieve this through the use of a web-based interface that would share information with the Scoring website.
How does it work in general?
A user will register an account on the CCA website that is tied to their email. After successfully registering, a player will then be able to choose a specific account from any Scoring-associated server to link to their CCA account (as long as they have not already been linked to another CCA account), the list of which is generated based off of the information that Scoring currently pulls to create the leaderboards/score pages. The system then requires the user to verify the link by proving that they have access to the server account. Once verified, this change is propagated to the CCA database (or the Scoring database, if the two are integrated), which is then used to make sure any morgues/games associated with that server account (as well as any other linked accounts associated with that CCA account) are aggregated under a single Scoring player page based on the CCA account. In the instances of an account not being linked to a CCA account, there are two potential outcomes. First, if the account is likely to be a shared or open account (for example, *robin accounts), there will be an administration page to 'whitelist' an account nickname; any account nickname that is whitelisted will follow the current Scoring rules of compiling all morgues/games from all Scoring-associated servers whenever the nicknames match, as well as preventing any CCA user from linking an account with that nickname from any server. Second, if an account is not linked or whitelisted, it will be displayed on the Scoring website under page with the player name of "<server>/<nickname>", allowing the games to still be displayed on the Scoring leaderboards, as well as allowing players who only play on one server to still have a Scoring page without needing to register a CCA account if they do not desire to do so.
Why is this specific approach the one that is being taken?
The advantages of designing a system like this (instead of other potential solutions to the single sign-on issue) are:
-No 'always online' requirement: The linking process is designed to be a one-time verification, and thus will not require the user to create a CCA account to play Crawl, nor will a player be restricted from playing on any server if anything happens to the CCA website. Likewise, it does not 'phone home' to verify every time a player wants to play.
-Minimal traffic/server pinging required: CCA will only be required to ping the servers once during the verification process (for a total of one time per account, lasting forever), meaning that the servers will not see any noticeable increase in traffic that would hinder the performance of the server.
-No changes to Crawl servers: By making CCA work off of the collected data that Scoring already gathers, no patches or changes need to be made to any current or future servers, meaning that there will be minimal issues with compatibility or ensuring all servers update when deploying CCA.
-No changes to current server accounts: By allowing CCA users to create a single account that links any number of existing nicknames (same or different, from the same or multiple servers), the only set-up required to preparing accounts for it is for the user to manage their account a single time upon initial registration (and then a bit of small maintenance every time they make a new account they want to add)
-No requirement to register: Scores are still preserved and visible on the leaderboards even if a player does not register; the only thing lost if a user does not register is automatically aggregating the accounts together under a single page.
There are some disadvantages to this system that should be mentioned, to put the full picture into perspective:
-Centralized verification: If the database containing the CCA data goes down, aggregation of data for Scoring will not be performed correctly until it comes back up. This will not hinder actual play for anybody, but may be inconvenient for leaderboard/score page purposes until restored.
-Modifications to Scoring: Scoring scripts that create the player pages will need to be adjusted to receive the CCA data first to determine how to sort/aggregate the player pages properly, which means some modifications to the create/update scripts as well as a potential adjustment to existing database structure. It may also require updates to any scripts that query the database for information.
-Modifications to Tournament Scripts: Tournament scripts will need to be adjusted in order to work with how CCA adjusts the way that Scoring creates Players.
-Initial User Registration: There will be an initial influx where existing players who want to link their accounts. The process for doing so may be short, but will have heavy traffic during this period that may cause stress/lag on any of the end points associated.
-Backup Requirements: As the intention is for users to not have to constantly re-link their accounts, the information stored in relation to CCA will need to be backed up in a reliable and consistent manner to ensure minimal information in lost in case it needs to be restored.
More specific information?
See below if you want a bigger breakdown as to how everything 'should' function/work once completed. Skip past the dashed lines if you aren't interested.
------------------------------------------------------
DATABASE
![Image](http://i.imgur.com/Cn98hTd.png)
Accounts represents all server/nickname combinations from logfiles pulled from all scoring-integrated servers (populated on creation and through updates by querying for distinct nickname+server combos from log files). Users is for accounts created on the CCA site itself; currently, email is the unique identifier for accounts to allow players to share/change nicknames if desired (but can be changed to make nicknames unique if that is not preferable), and Role is to designate whether the user has admin/moderator rights on the CCA site. Authentications is a joining table to track links between Accounts and Users whenever a user links their CCA account to a server account. Depending on if these tables are added to the Scoring database, a fourth table (or an index) should be added for linking Accounts to Players or whatever associated table would keep track of tying into the CCA data (adjusted as described below under Scoring Aggregation).
WEB PAGES
Login/Logout/Register/Forgot Password/Master Page (Unregistered/User/Admin/Mod)
-For the most part, these pages can be ripped from the web app template that Visual Studio creates (with any extraneous features stripped out/removed), and modified to fit the needs of the web site
Edit Profile (User/Admin/Mod)
-Same as above, but Edit Profile may require more customization. Only listed separately to highlight permission differences.
Link Account (User/Admin/Mod)
-Link Account is for the actual linking of the user's CCA account with a server account. One of two methods will be used (unsure which one to use yet, or to include both):
a) The user must select the server their account is located on. Once selected, the will be prompted to log in to their account via WebSocket. If they successfully log in and the server account has not yet been registered or whitelisted, a new entry is made in Authentications to link the user's CCA account to the logged in server account.
b) It will bring the user to a page with a two stage dropdown list selection: the first is selecting the server that contains the server account, the second being the name of the account to be linked (generated from Accounts that are not Whitelisted or already in Authentications). Once selected, they are given a randomly generated string to insert at the top of the server account's rcfile. The user then clicks a Verify button which sends a request to the server to scrape that account's rcfile and check the top line to compare against the generated string. If it matches, a new entry is made in Authentications to link the user's CCA to the selected server account. The string can then be removed afterwards.
-In either case, the link cannot be reversed by a normal user once made. Additionally, it should detect and time out a user if too many failed attempts to verify occur in a short period of time to prevent easily DDoSing a server.
-The list of servers should probably be hard coded in order to ensure connection strings to each of the servers is not leaked publicly (and thus, no Manage Servers page). This is unlikely to be an issue due to how infrequently a new server needs to be added to the list that contributes to Scoring.
Account Whitelist (Admin/Mod)
-Account Whitelist shows a distinct list of nicknames from the Accounts table, where whitelisted is true. An admin/mod can select from a distinct list of nicknames from all servers (that are not already whitelisted and where no shared nickname is already connected to an existing entry in Authentications) to add to the whitelist, or select a name on the whitelist to remove. When a name is added or removed to/from the whitelist, it sets Whielisted to true/false for all entries with a matching nickname. Whenever a new entry is made to Accounts, it should check to see if the nickname matches any others that are whitelisted, and whitelist the new entry if it is. When an account is whitelisted, it follows the same score aggregation rules that current scoring does (if the name is the same across any server, aggregate those scores under a single page). This is intended mainly as support for *robin or other shared accounts without needing to create and link a CCA account for them by hand.
Unlink Account (Admin/Mod)
-Unlink Account allows an admin/mod to remove a link from a CCA account, for the purposes of fixing malicious activity. The admin/mod selects the CCA account, then selects the link on that account to remove. This ensures players do not just toss away accounts whenever they feel like and cause potential stress on the database/servers.
Manage Permissions (Admin/Mod)
-Manage Permissions lets an admin/mod promote or demote a user from the role of moderator. Moderators and administrators have the same level of permissions in terms of access and actions for the most part, with the exception that no user can be promoted or demoted to/from administrator from within the website. Administrators, unlike mods, should be hard set with a SQL query to the database only (and only when first launching the website, preferably), and should be whomever is the owner/maintainer of the CCA server/website, as well as any other trusted individuals. This is to ensure that a malicious user finding a way to be promoted to moderator is limited in the damage they can perform (as in, they can't lock everyone out through the website). This can be pared down to only having a moderator level, but this may create trust issues in the future.
SCORING INTEGRATION/AGGREGATION
Scoring should be modified to have players be generated through the following process:
1) CCA populates/updates Accounts whenever an update would be pulled by Scoring. Accounts should not have records removed or IDs modified, nor should it be rebuilt, in order to make sure Authentications isn't invalidated. If this has to occur for whatever reason, then there may need to be an email warning about users needing to re-verify/re-link accounts.
2) Scoring generates Player pages/entries while sorting through logfiles/Accounts based on the following three categories:
a) If a logfile belongs to a server account that is linked to a CCA account, aggregate under a personal scoring page where the scores are aggregated from all logfiles from accounts linked to that CCA UserID (checked through Authentications). The CCA User nickname should be displayed on scoreboards when linking to this page.
b) If a logfile belongs to a server account that is not linked to a CCA account but is whitelisted, aggregate under a personal scoring page where the scores are aggregated from all logfiles from accounts matching the AccountNick (or, similar to how the current system generates Scoring pages). The Account nickname should be displayed on the scoreboards when linking to this page.
c) If a logfile belongs to a server account that is neither linked or whitelisted, aggregate under a personal scoring page where the scores are aggregated from all logfiles belonging only to that specific server+nickname combo. It should be displayed as "<server>/<nickname>" on the scoreboards when linking to this page.
3) There are two methods to generating URLs for Player pages on Scoring:
a) Use the Player unique ID (?playerID=****). This method keeps the IDs based on what Scoring already stores, but has the issue of potentially shuffling IDs and screwing up bookmarks if/when the table is re-initialized.
b) Give what category/type the Player falls under in the URL (ex. ?type=r&userID=****, ?type=w&AccountNick=****, ?type=u&AccountID=****). This is a more stable link, but requires more communication with the CCA data, as well as potentially requiring adding another field to the Players table to accommodate it.
SECURITY
Given that this is a web application, it needs to be scanned with a security vulnerability detection tool to ensure that at least the majority of exploits (cross site scripting, SQL injection, exposed back-end, connection strings, or web.config settings, etc.) are sanitized and protected against once it is finished and put together. This should be redone if the source code has been modified since the last scan. Likewise, the database the information is stored in should also ensure that passwords (and potentially user emails) are encrypted.
------------------------------------------------------
If there are any questions, comments, etc...please state them here and I will answer to the best of my ability. Again, I will be working on this when I have free time and am willing/able to hobby around with it.
- For this message the author Floodkiller has received thanks: 7
- all before, Brannock, chequers, dpeg, floatboth, vergil, Wahaha