https://wiki.bzflag.org/api.php?action=feedcontributions&feedformat=atom&user=Wyk3d 2026-05-10T12:50:05Z User contributions MediaWiki 1.43.5 https://wiki.bzflag.org/index.php?title=Google_Summer_of_Code:_2009:OrgApplication&diff=5549 2009-03-13T17:39:12Z

<p>Wyk3d: /* What steps will you take to encourage contributors to interact with your community before, during, and after the program? */</p> <hr /> <div>= Description = <br /> BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world.. It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community. There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night. The project has actually become more popular over the years as we continue to improve and enhance the game. BZFlag has been under active development since 1992.<br /> <br /> Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it. There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span. Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers. Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.<br /> <br /> All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration. We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members. Extensive discussions are held for any changes to BZFlag that affect the game's traditional &quot;spirit&quot;, mood of gameplay, tone of the user environment, and types of interactions possible in the game. These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay. We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.<br /> <br /> From IRC, we administer network operations for the approximate 18638 registered player base and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers. As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.<br /> <br /> = Why is your group applying to participate? What do you hope to gain by participating =<br /> <br /> Our primary intention for participating in GSoC 2009 is to hopefully attract new developers. We already have visibility, popularity, familiarity, and a very active community. The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.<br /> <br /> GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term. It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our own developers more organized and collaborating more effectively.<br /> <br /> We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process. BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers). Just this past year, Indiana University worked with our staff to use BZFlag as a platform for conducting a social network analysis. We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.<br /> <br /> Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game. We found out last year that participating in GSoC simulates our project development activities and forces us to become more organized, collaborative, and deliberate in our focus. Our community is simply filled with great ideas on how to improve the game in wide impacting ways and we would like to encourage these developments. GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.<br /> <br /> = What criteria do you use to select the members of your group? Please be as specific as possible. =<br /> <br /> All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators. Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis . All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end. The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.<br /> <br /> Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes. Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users. They form a critical part of our technical support infrastructure.<br /> <br /> Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development. As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students. Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.<br /> <br /> = Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =<br /> <br /> Yes, we participated for the first time in 2007 and again in 2008. We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking. Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.<br /> <br /> We found that being involved in GSoC encouraged our community to become more organized and accountable than usual. It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.<br /> <br /> The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort. In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again. We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.<br /> <br /> = What is your plan for dealing with disappearing contributors? = <br /> <br /> If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress. Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something &quot;fun&quot; that rather easily captures and maintains interest. However, should the student's focus still remain diminished or should the student unexpectedly disappear without notice, the administrator will relay this status with Google after repeated attempts to contact the student fail.<br /> <br /> Also, as a learned measure from last year, the students are going to be required to make very frequent commits. If they're not committing, then they are not working. At least they won't be working effectively. Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process. We strongly adhere to &quot;commit early, commit often&quot;.<br /> <br /> If the student is not around or is not working as much as they need to be, we will have discussions with them, see what's going on, and do so proactively. We learned from one of our students last year when they were in serious danger of failing that a simple change in their accountability can have a massive impact on their motivation. We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers. Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that slip consistently fall behind schedule.<br /> <br /> Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them. As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible. The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and near immediate response to questions and comments.<br /> <br /> Other than that, the formula for dealing with disappearing students really just boils down to communication. It's a very organic process and we don't believe that there is one answer for all students. The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually. Issues that we cannot resolve will be brought forward to Google for guidance, as was done last year. <br /> <br /> = What is your plan for dealing with disappearing members? = <br /> <br /> BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions. The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel. We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).<br /> <br /> One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual. It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.<br /> <br /> The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions. If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.<br /> <br /> Should some situation arise that incapacitates a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off. Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online. That said, all mentors selected based on their activity this year to help minimize any issues.<br /> <br /> This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects. This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors. Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.<br /> <br /> = What steps will you take to encourage contributors to interact with your community before, during, and after the program? =<br /> <br /> Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often &quot;addictive&quot;. Most people enjoy playing BZFlag and often after they play the game for a little while, they can &quot;get hooked&quot; on the game. &quot;Quick to learn, difficult to master&quot; is our motto and this holds true both in the game and for development. Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players. We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.<br /> <br /> Before the program, we have a specific checklist of tasks that we have prepared to give them definitive actions that they need to perform. These steps include introducing themselves to our IRC channel, having a Sourceforge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see. <br /> <br /> As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion. We have lots of existing documentation, web infrastructure, and network resources available to get new developers familiar and interested in development directions quickly. Given our involvement with GSoC last year, we now also have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.<br /> <br /> One of the interactions that worked very well last year was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers. We intend to take additional steps this year to continuously integrate the students' code throughout the program and work on introducing our player community to the features being developed even more early on. The goal will be to instill a sense of belonging and a sense of appreciation for the hard-work they are putting into their code.<br /> <br /> = What will you do to ensure that your accepted contributors stick with the project after the program concludes? =<br /> <br /> It is our responsibility to not neglect or abandon the students. We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved. BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time. There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.<br /> <br /> New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small. For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student and other developers as well. We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.<br /> <br /> It's our job to encourage their passion for BZFlag development long after GSoC concludes.</div>

Wyk3d https://wiki.bzflag.org/index.php?title=User:Wyk3d&diff=4760 2008-07-08T16:11:33Z

<p>Wyk3d: /* V. Work Log */</p> <hr /> <div>=BZAuthd - the global authentication daemon=<br /> <br /> ==I. Abstract==<br /> <br /> BZFlag currently employs a php list server that, besides sending the list of servers and managing permissions, handles global authentication for players by their callsign and password. I propose implementing BZAuthd, a standalone C++ authentication daemon that would address some of its issues, as well as add multiple other desirable features.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem.<br /> The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> Full backwards compatibility will be kept. Users of older versions of the client/server could continue using the existing list server except that its data layer would need to be changed to LDAP to share authentication data with the daemon. From what I was told this aspect could be implemented easily in the php list server rewrite that blast007 is working on.<br /> <br /> ==II. Long term goals==<br /> <br /> Many of the list server functions are closely tied in with authentication. If the two are left as separate entities, they would need to communicate with eachother or duplicate some of the eachother's tasks. Also, the larger part of the load on the list server is probably not authentication. So there is little to no point in having the list server separate from the auth daemon and therefore the end goal is to have the daemon handle all functions that the list server does now.<br /> <br /> Since that might be impossible given the time frame, I propose implementing the following:<br /> <br /> - a solid foundation for the daemon that would handle the authentication related aspects fully<br /> <br /> - complete integration with the client/server<br /> <br /> - a menu for user registration in the client<br /> <br /> - ability to choose between standard authentication and the daemon<br /> <br /> Should I finish with those early, I will continue with the rest of the implementation:<br /> <br /> - memory cached storage of the server list and a MySQL backend and replication<br /> <br /> - permissions, group management, player tracking etc<br /> <br /> - linking the authentication data to the server list<br /> <br /> - additional chatter between the server/client/daemon<br /> <br /> ==III. Detailed Description==<br /> <br /> ===III.1 Low level networking===<br /> <br /> The ServerLink/NetHandler classes are already written generic enough to be reused by the daemon to host TCP sessions. I propose moving these classes into their own library, as part of the net project and making specialized classes for non-generic code.<br /> <br /> ===III.2 Authentication Process===<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> I propose using the primitives in the OpenSSL library for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> ===III.3 LDAP backend===<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server.<br /> When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> ===III.4 Client/server integration===<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> ===III.5 Registration menu in the client===<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> ===III.6 Design goals===<br /> <br /> Since this is a project that will probably have plenty on the TODO list long after the summer deadline, a very important design goal will be for it to be easily maitainable. As such, I will try to code in a generic manner wherever possible, create clear/easy to use class interfaces and always think ahead for future expansion.<br /> <br /> ===III.7 Other===<br /> <br /> Settings like IPs of the LDAP servers, timeout delays, security options, minimum password length etc will be read from the command line and from a configuration file, in the same format as bzfs.conf for example.<br /> <br /> All connections to the daemon as well as it's internal operations will be logged to a text file and to the console if desired.<br /> <br /> ==IV. Timeline==<br /> <br /> June 16th: move the ServerLink/NetHandler code into its own lib<br /> <br /> July 7th: create the foundation for the daemon that can accept connections from the client/server<br /> <br /> July 14th: link OpenLDAP to the project, implement the LDAP backend for the daemon<br /> <br /> July 21th: add the option to the client and server to connect to the daemon for authentication<br /> <br /> July 28th: link OpenSSL to the projects, implement the RSA handshake and the auth chatter<br /> <br /> August 4th: create registration menus in the client<br /> <br /> August 11th: make use of RSA for sending the email address/password for the registration<br /> <br /> August 18th: The implemented features should be tweaked/tested and most bugs fixed.<br /> <br /> ==V. Work Log==<br /> <br /> June 30: So far I got some server framework basics laid down. I finished the RSA support code based on libgcrypt (instead of OpenSSL) and wrote C++ wrappers for it. LDAP has been tested but still needs more work. Some networking has been added but there's still plenty to do there as well.<br /> <br /> July 8: Made lots of progress with the network code. Got the design laid out for sending, receiving packets, implemented some of the message handling on the daemon side too.</div>

Wyk3d https://wiki.bzflag.org/index.php?title=User:Wyk3d&diff=4759 2008-07-08T16:11:13Z

<p>Wyk3d: </p> <hr /> <div>=BZAuthd - the global authentication daemon=<br /> <br /> ==I. Abstract==<br /> <br /> BZFlag currently employs a php list server that, besides sending the list of servers and managing permissions, handles global authentication for players by their callsign and password. I propose implementing BZAuthd, a standalone C++ authentication daemon that would address some of its issues, as well as add multiple other desirable features.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem.<br /> The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> Full backwards compatibility will be kept. Users of older versions of the client/server could continue using the existing list server except that its data layer would need to be changed to LDAP to share authentication data with the daemon. From what I was told this aspect could be implemented easily in the php list server rewrite that blast007 is working on.<br /> <br /> ==II. Long term goals==<br /> <br /> Many of the list server functions are closely tied in with authentication. If the two are left as separate entities, they would need to communicate with eachother or duplicate some of the eachother's tasks. Also, the larger part of the load on the list server is probably not authentication. So there is little to no point in having the list server separate from the auth daemon and therefore the end goal is to have the daemon handle all functions that the list server does now.<br /> <br /> Since that might be impossible given the time frame, I propose implementing the following:<br /> <br /> - a solid foundation for the daemon that would handle the authentication related aspects fully<br /> <br /> - complete integration with the client/server<br /> <br /> - a menu for user registration in the client<br /> <br /> - ability to choose between standard authentication and the daemon<br /> <br /> Should I finish with those early, I will continue with the rest of the implementation:<br /> <br /> - memory cached storage of the server list and a MySQL backend and replication<br /> <br /> - permissions, group management, player tracking etc<br /> <br /> - linking the authentication data to the server list<br /> <br /> - additional chatter between the server/client/daemon<br /> <br /> ==III. Detailed Description==<br /> <br /> ===III.1 Low level networking===<br /> <br /> The ServerLink/NetHandler classes are already written generic enough to be reused by the daemon to host TCP sessions. I propose moving these classes into their own library, as part of the net project and making specialized classes for non-generic code.<br /> <br /> ===III.2 Authentication Process===<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> I propose using the primitives in the OpenSSL library for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> ===III.3 LDAP backend===<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server.<br /> When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> ===III.4 Client/server integration===<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> ===III.5 Registration menu in the client===<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> ===III.6 Design goals===<br /> <br /> Since this is a project that will probably have plenty on the TODO list long after the summer deadline, a very important design goal will be for it to be easily maitainable. As such, I will try to code in a generic manner wherever possible, create clear/easy to use class interfaces and always think ahead for future expansion.<br /> <br /> ===III.7 Other===<br /> <br /> Settings like IPs of the LDAP servers, timeout delays, security options, minimum password length etc will be read from the command line and from a configuration file, in the same format as bzfs.conf for example.<br /> <br /> All connections to the daemon as well as it's internal operations will be logged to a text file and to the console if desired.<br /> <br /> ==IV. Timeline==<br /> <br /> June 16th: move the ServerLink/NetHandler code into its own lib<br /> <br /> July 7th: create the foundation for the daemon that can accept connections from the client/server<br /> <br /> July 14th: link OpenLDAP to the project, implement the LDAP backend for the daemon<br /> <br /> July 21th: add the option to the client and server to connect to the daemon for authentication<br /> <br /> July 28th: link OpenSSL to the projects, implement the RSA handshake and the auth chatter<br /> <br /> August 4th: create registration menus in the client<br /> <br /> August 11th: make use of RSA for sending the email address/password for the registration<br /> <br /> August 18th: The implemented features should be tweaked/tested and most bugs fixed.<br /> <br /> ==V. Work Log==<br /> <br /> June 30: So far I got some server framework basics laid down. I finished the RSA support code based on libgcrypt (instead of OpenSSL) and wrote C++ wrappers for it. LDAP has been tested but still needs more work. Some networking has been added but there's still plenty to do there as well.<br /> July 8: Made lots of progress with the network code. Got the design laid out for sending, receiving packets, implemented some of the message handling on the daemon side too.</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4754 2008-07-04T16:37:33Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Opcode descriptions and data contents:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 1 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_HANDSHAKE - the client specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer for the client version and a 2 byte integer for the type of initial communication requested (can be 0 - auth, 1 - register get form, 2 - register request) - Note: the client may request other communication types without closing the connection later on<br /> <br /> DMSG_HANDSHAKE - the daemon specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer containing the daemon version and a 2 byte integer denoting the daemon rank<br /> <br /> SMSG_HANDSHAKE - the server specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer for the server version<br /> <br /> CMSG_AUTH_REQUEST - this may be sent to notify the daemon that an auth is requested, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_AUTH_FAIL - sent after the auth request or response, if the auth failed for some reason (e.g unknown user name, incorrect password etc) - Contains: a 4 byte error code, perhaps followed by a C string with more information<br /> <br /> DMSG_AUTH_CHALLENGE - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_AUTH_RESPONSE - sent if the auth request was accepted, after the public key was received - Contains: binary string for an encrypted message containing the username and the password delimited by a space<br /> <br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> CMSG_REGISTER_GET_FORM - sent when the user tries to access the register menu, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_REGISTER_FAIL - sent whenever if getting the form failed or if the request was denied or if the challenge failed etc - Contains: a 4 byte error code, perhaps followed by a C string with more information<br /> <br /> DMSG_REGISTER_SEND_FORM - sent after a form request - Contains: C String that describes the fields that the user is asked to complete<br /> <br /> CMSG_REGISTER_REQUEST - sent when the user completed the form, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_REGISTER_CHALLENGE - sent if the provided preliminary information is valid - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_REGISTER_RESPONSE - sent if the register request was accepted and a key was received - Contains: <br /> a binary string for an encrypted message contain the username, the password and other information, each delimited by a space<br /> <br /> DMSG_REGISTER_SUCCESS - sent if the registration was successful - Contains: nothing<br /> <br /> SMSG_TOKEN_VALIDATE - sent when the server wishes to validate tokens that it got from a client - Contains: a 1 byte integer &quot;n&quot; for the number of tokens to be validated followed by &quot;n&quot; 4 byte integer tokens<br /> <br /> DMSG_TOKEN_VALIDATE - sent when the daemon processed a validation request - Contains: a 1 byte integer &quot;n&quot; for the number of tokens to be validated followed by &quot;n&quot; 4 byte integer error codes which are 0 where the the token was successfully validated<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4741 2008-06-30T13:59:14Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Opcode descriptions and data contents:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 2 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_HANDSHAKE - the client specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer for the client version and a 2 byte integer for the type of initial communication requested (can be 0 - auth, 1 - register get form, 2 - register request) - Note: the client may request other communication types without closing the connection later on<br /> <br /> DMSG_HANDSHAKE - the daemon specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer containing the daemon version and a 2 byte integer denoting the daemon rank<br /> <br /> SMSG_HANDSHAKE - the server specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer for the server version<br /> <br /> CMSG_AUTH_REQUEST - this may be sent to notify the daemon that an auth is requested, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_AUTH_FAIL - sent after the auth request or response, if the auth failed for some reason (e.g unknown user name, incorrect password etc) - Contains: a 4 byte error code, perhaps followed by a C string with more information<br /> <br /> DMSG_AUTH_CHALLENGE - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_AUTH_RESPONSE - sent if the auth request was accepted, after the public key was received - Contains: binary string for an encrypted message containing the username and the password delimited by a space<br /> <br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> CMSG_REGISTER_GET_FORM - sent when the user tries to access the register menu, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_REGISTER_FAIL - sent whenever if getting the form failed or if the request was denied or if the challenge failed etc - Contains: a 4 byte error code, perhaps followed by a C string with more information<br /> <br /> DMSG_REGISTER_SEND_FORM - sent after a form request - Contains: C String that describes the fields that the user is asked to complete<br /> <br /> CMSG_REGISTER_REQUEST - sent when the user completed the form, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_REGISTER_CHALLENGE - sent if the provided preliminary information is valid - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_REGISTER_RESPONSE - sent if the register request was accepted and a key was received - Contains: <br /> a binary string for an encrypted message contain the username, the password and other information, each delimited by a space<br /> <br /> DMSG_REGISTER_SUCCESS - sent if the registration was successful - Contains: nothing<br /> <br /> SMSG_TOKEN_VALIDATE - sent when the server wishes to validate tokens that it got from a client - Contains: a 1 byte integer &quot;n&quot; for the number of tokens to be validated followed by &quot;n&quot; 4 byte integer tokens<br /> <br /> DMSG_TOKEN_VALIDATE - sent when the daemon processed a validation request - Contains: a 1 byte integer &quot;n&quot; for the number of tokens to be validated followed by &quot;n&quot; 4 byte integer error codes which are 0 where the the token was successfully validated<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4740 2008-06-30T13:41:58Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Opcode descriptions and data contents:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 2 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_HANDSHAKE - the client specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer for the client version and a 2 byte integer for the type of communication requested (can be 0 - auth, 1 - register get form, 2 - register request) - Note: the client may request other communication types without closing the connection later on<br /> <br /> DMSG_HANDSHAKE - the daemon specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer containing the daemon version and a 2 byte integer denoting the daemon rank<br /> <br /> SMSG_HANDSHAKE - the server specific version of the handshake - Contains: the data from MSG_HANDSHAKE followed by a 4 byte integer for the server version<br /> <br /> CMSG_AUTH_REQUEST - this may be sent to notify the daemon that an auth is requested, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_AUTH_FAIL - sent after the auth request or response, if the auth failed for some reason (e.g unknown user name, incorrect password etc) - Contains: a 4 byte error code, perhaps followed by a C string with more information<br /> <br /> DMSG_AUTH_CHALLENGE - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_AUTH_RESPONSE - sent if the auth request was accepted, after the public key was received - Contains: binary string for an encrypted message containing the username and the password delimited by a space<br /> <br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> CMSG_REGISTER_GET_FORM - sent when the user tries to access the register menu, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_REGISTER_FAIL - sent whenever if getting the form failed or if the request was denied or if the challenge failed etc - Contains: a 4 byte error code, perhaps followed by a C string with more information<br /> <br /> DMSG_REGISTER_SEND_FORM - sent after a form request - Contains: C String that describes the fields that the user is asked to complete<br /> <br /> CMSG_REGISTER_REQUEST - sent when the user completed the form, but is not needed if this was already specified in the handshake - Contains: nothing<br /> <br /> DMSG_REGISTER_CHALLENGE - sent if the provided preliminary information is valid - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_REGISTER_RESPONSE - sent if the register request was accepted and a key was received - Contains: <br /> a binary string for an encrypted message contain the username, the password and other information, each delimited by a space<br /> <br /> DMSG_REGISTER_SUCCESS - sent if the registration was successful - Contains: nothing<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4739 2008-06-29T23:45:11Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Opcode descriptions and data contents:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 2 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_AUTH_REQUEST - sent before a client connects to a server - Contains: C string username<br /> <br /> DMSG_AUTH_REQUEST_DENIED - sent after an auth request if it was denied - Contains: a 4 byte error code<br /> <br /> DMSG_AUTH_REQUEST_ACCEPTED - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_AUTH_CIPHER - sent if the auth request was accepted - Contains: binary string for the cipher of the password<br /> <br /> DMSG_AUTH_FAIL - sent if the auth failed - Contains: 4 byte error code<br /> <br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> CMSG_REGISTER_GET_FORM - sent when the user tries to access the register menu - Contains: nothing<br /> <br /> DMSG_REGISTER_SEND_FORM - sent after a form request - Contains: C String that describes the fields that the user is asked to complete<br /> <br /> CMSG_REGISTER_REQUEST - sent when the user completed the form - Contains: nothing<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4738 2008-06-29T23:44:03Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Packet structure and descriptions:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 2 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_AUTH_REQUEST - sent before a client connects to a server - Contains: C string username<br /> <br /> DMSG_AUTH_REQUEST_DENIED - sent after an auth request if it was denied - Contains: a 4 byte error code<br /> <br /> DMSG_AUTH_REQUEST_ACCEPTED - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_AUTH_CIPHER - sent if the auth request was accepted - Contains: binary string for the cipher of the password<br /> <br /> DMSG_AUTH_FAIL - sent if the auth failed - Contains: 4 byte error code<br /> <br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> CMSG_REGISTER_GET_FORM - sent when the user tries to access the register menu - Contains: nothing<br /> <br /> DMSG_REGISTER_SEND_FORM - sent after a form request - Contains: C String that describes the fields that the user is asked to complete<br /> <br /> CMSG_REGISTER_REQUEST - sent when the user completed the form - Contains: nothing<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4737 2008-06-29T23:22:10Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Packet structure and descriptions:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 2 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_AUTH_REQUEST - sent before a client connects to a server - Contains: C string username<br /> <br /> DMSG_AUTH_REQUEST_DENIED - sent after an auth request if it was denied - Contains: a 4 byte error code<br /> <br /> DMSG_AUTH_REQUEST_ACCEPTED - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> <br /> CMSG_AUTH_CIPHER - sent if the auth request was accepted - Contains: binary string for the cipher of the password<br /> <br /> DMSG_AUTH_FAIL - sent if the auth failed - Contains: 4 byte error code<br /> <br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4736 2008-06-29T23:20:52Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - boolean type of 1 byte (0 - false, 1 - true)<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> Packet structure and descriptions:<br /> <br /> The opcodes will be denoted by constants, they will be prefixed with either CMSG, SMSG or DMSG to <br /> denote whether they originated from a server a client or a daemon, or just MSG if it may originate from either of these. For inter-node communication, the additional prefixes might be used.<br /> <br /> MSG_HANDSHAKE - first packet sent by both parties when opening any communication - Contains: 2 byte type id (0 - client/1 - server/2 - daemon) 2 byte protocol version number, x bytes of additional information based on the type and protocol version (e.g client version, daemon rank, etc)<br /> <br /> Protocol version 1:<br /> <br /> CMSG_AUTH_REQUEST - sent before a client connects to a server - Contains: C string username<br /> DMSG_AUTH_REQUEST_DENIED - sent after an auth request if it was denied - Contains: a 4 byte error code<br /> DMSG_AUTH_REQUEST_ACCEPTED - sent after an auth request if it was accepted - Contains: a binary string containing the public key &quot;n&quot; value and a 2 byte integer containing the public key &quot;e&quot; value<br /> CMSG_AUTH_CIPHER - sent if the auth request was accepted - Contains: binary string for the cipher of the password<br /> DMSG_AUTH_FAIL - sent if the auth failed - Contains: 4 byte error code<br /> DMSG_AUTH_SUCCESS - sent if the auth succeeded - Contains: 4 byte integer session token to be sent to a server<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4735 2008-06-29T22:20:13Z

<p>Wyk3d: /* Network Protocol */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> <br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> <br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> <br /> The information in the data field will be structured into:<br /> <br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> <br /> - C strings, with a 0 delimiter at the end<br /> <br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4734 2008-06-29T22:18:48Z

<p>Wyk3d: /* Design */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> == Network Protocol ==<br /> <br /> The packet format for all communication between client/server/daemons will be as follows:<br /> - 4 byte packet header containing: a 2 byte opcode followed by the 2 byte data length<br /> - the rest of the data, between 0 and a theoretical maximum of 65k bytes, but capped at 4096 bytes, this can be increased later if larger packets are needed<br /> The information in the data field will be structured into:<br /> - integer types of 1,2,4 or 8 bytes in size, sent in binary, little-endian, with no delimiter<br /> - C strings, with a 0 delimiter at the end<br /> - binary strings, preceded by a 2 byte length descriptor<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4626 2008-05-20T21:42:04Z

<p>Wyk3d: /* Replication and Redundancy */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and Redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> <br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or at least error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> <br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> <br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4625 2008-05-20T21:40:54Z

<p>Wyk3d: /* Design */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> == Replication and redundancy ==<br /> <br /> The clients and servers could have a list of auth daemons to try and connect to. If one fails they try the next and so on.<br /> External sources like forum registration can alter the LDAP data and thus caching reads would be impossible or atleast error prone unless those external sources notify the daemons of these changes or do these through them. Even so, each instance of the daemon could have its own read cache, that does not need to be replicated.<br /> The write cache for the case when the LDAP server goes down would need to be replicated however. Each daemon would need to send the writes to every other daemon (that is still active) for the caches to remain consistent.<br /> When the LDAP master server comes online only one of them should commit the changes. One could establish a hierarchy between daemons and the highest one still active could do the job.<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4624 2008-05-20T21:33:16Z

<p>Wyk3d: /* Design */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Design =<br /> <br /> == Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> The primitives in the OpenSSL library will be used for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4623 2008-05-20T21:28:56Z

<p>Wyk3d: /* BZAuthd Design */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = BZAuthd Design =<br /> <br /> == 1. Authentication Process ==<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> I propose using the primitives in the OpenSSL library for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> == 2. LDAP backend ==<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server. When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> == 3. Client/server integration ==<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> == 4. Registration menu in the client ==<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=BZAuthd&diff=4622 2008-05-20T21:17:46Z

<p>Wyk3d: /* Problem Statement */</p> <hr /> <div>{{DesignDocument}}<br /> <br /> 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.<br /> <br /> = Problem Statement =<br /> <br /> 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.<br /> <br /> 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, canceling 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.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem. The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> = Definitions =<br /> <br /> == CLIENTS ==<br /> anything that needs read-write, read-only, or authorization services from my.bzflag.org<br /> <br /> == BZAUTHD ==<br /> <br /> 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.<br /> INTERFACES WITH: LDAP, KARMA, BZFS, BZFLAG, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==LDAP SERVER==<br /> <br /> 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).<br /> INTERFACES WITH: BZAUTHD, KARMA, REPLICANTS, CERTIFICATE GENERATOR (perhaps).<br /> <br /> ==CERTIFICATE GENERATOR==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP (see above 'perhaps'.)<br /> <br /> ==KARMA DATABASE==<br /> <br /> 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.<br /> INTERFACES WITH: BZAUTHD, LDAP, REPLICANTS. <br /> <br /> == BZFLAG==<br /> <br /> The actual game client. Responsible for registering of players, joining servers, retrieval of server list (with associated server capabilities and restrictions), and game play.<br /> INTERFACES WITH: BZAUTHD, BZFS.<br /> <br /> == BZFS ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, BZFLAG.<br /> <br /> == BZPORTAL ==<br /> <br /> 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. <br /> INTERFACES WITH: BZAUTHD, LDAP.<br /> <br /> == BZFORUMS ==<br /> <br /> Community site that can also register clients. Talks to bzauthd and perhaps ldap directly for user certificates, etc.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> == BZSTATS ==<br /> <br /> Community site that tracks player and other client statistics (bzfs, primarily). Talks to bzauthd. Collects data from bzfs clients.<br /> INTERFACES WITH: BZPORTAL.<br /> <br /> = Overview Diagram =<br /> Diagram not yet uploaded.<br /> <br /> Notice also that for redundancy, 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.<br /> <br /> The karma database, it should be noted, with proper initial design and setup, should essentially be self-maintaining. <br /> <br /> = Use Cases =<br /> <br /> == FAILURE CASES ==<br /> * LDAP SERVER (master) dies:<br /> ** BZAUTHd falls over to querying the LDAP replicants for player information.<br /> ** New player / client information is cached by BZAUTHd for later insertion into master LDAP directory.<br /> <br /> * KARMA SERVER (master) dies:<br /> ** BZAUTHd falls over to querying Karma replicant(s) for client karma.<br /> <br /> * BZAUTHD dies:<br /> ** Fall over to other hosted, trusted BZAUTHd process.<br /> ** Fail gracefully – no cache data blown away, etc.<br /> <br /> * CERTIFICATE GENERATOR dies:<br /> ** Temporarily suspend new account creation.<br /> ** Limit new account creation to temporary account types only.<br /> ** Cache new account data, and resubmit when service is available.<br /> <br /> = Design Questions =<br /> * Should or can the Karma server and LDAP server be one and the same?<br /> ** PROVIDES: easier maintenance, both autonomously and manually<br /> ** PROVIDES: easier ability for maintaining a consistent data state (no fuzzy syncing issues – it either is or isn't synced with replicants)<br /> ** PROBLEMATIC: multiple areas of entry for possible abuse (unless replicants are hosted on 'trusted' systems, as far as that can be determined.)<br /> <br /> * Should or can certificate generation be done by one of the preexisting processes?<br /> ** BZAUTHD (not sure)<br /> ** LDAP (likely if possible)<br /> ** KARMA (unlikely – doesn't seem to make logical sense)<br /> <br /> {{stub}}<br /> [[Category:TODO]]</div>

Wyk3d https://wiki.bzflag.org/index.php?title=User:Wyk3d&diff=4386 2008-04-03T21:22:12Z

<p>Wyk3d: New page: =BZAuthd - the global authentication daemon= ==I. Abstract== BZFlag currently employs a php list server that, besides sending the list of servers and managing permissions, handles global...</p> <hr /> <div>=BZAuthd - the global authentication daemon=<br /> <br /> ==I. Abstract==<br /> <br /> BZFlag currently employs a php list server that, besides sending the list of servers and managing permissions, handles global authentication for players by their callsign and password. I propose implementing BZAuthd, a standalone C++ authentication daemon that would address some of its issues, as well as add multiple other desirable features.<br /> <br /> The list server does not perform well under high load and since it's run through an apache web server, it is not easy to profile either. The web server is considered a burden to maintain and the fact that it's not written in the same programming language as the majority of the code base is also a disadvantage.<br /> <br /> The current system is tied in with the phpBB forums and does not offer a viable method of using the same authentication data for other services like MediaWiki. A good solution is to use LDAP as a backend for storing the auth data since both phpBB and MediaWiki have plugins that support LDAP authentication and Drupal has full support for it.<br /> <br /> Another big issue is the lack of data redundancy, the MySQL tables are a single point of failure for the system. The daemon would allow the auth data will to be replicated by using OpenLDAP's built in replication. The daemon would fall back to reading data from the slaves and cache writes to the master until it comes back online. Should the daemon die aswell during this time, clients and servers could fall back to additional instances of it.<br /> <br /> The callsign and password are sent in clear text form to the list server and this is a risk to the users' privacy since they may use those passwords elsewhere. The auth daemon would use a public key cryptography algorithm called RSA that would effectively solve this problem.<br /> The only way to register at the moment is at the forums. The daemon would allow users to register through a secure, RSA encrypted channel from inside the game.<br /> <br /> Full backwards compatibility will be kept. Users of older versions of the client/server could continue using the existing list server except that its data layer would need to be changed to LDAP to share authentication data with the daemon. From what I was told this aspect could be implemented easily in the php list server rewrite that blast007 is working on.<br /> <br /> ==II. Long term goals==<br /> <br /> Many of the list server functions are closely tied in with authentication. If the two are left as separate entities, they would need to communicate with eachother or duplicate some of the eachother's tasks. Also, the larger part of the load on the list server is probably not authentication. So there is little to no point in having the list server separate from the auth daemon and therefore the end goal is to have the daemon handle all functions that the list server does now.<br /> <br /> Since that might be impossible given the time frame, I propose implementing the following:<br /> <br /> - a solid foundation for the daemon that would handle the authentication related aspects fully<br /> <br /> - complete integration with the client/server<br /> <br /> - a menu for user registration in the client<br /> <br /> - ability to choose between standard authentication and the daemon<br /> <br /> Should I finish with those early, I will continue with the rest of the implementation:<br /> <br /> - memory cached storage of the server list and a MySQL backend and replication<br /> <br /> - permissions, group management, player tracking etc<br /> <br /> - linking the authentication data to the server list<br /> <br /> - additional chatter between the server/client/daemon<br /> <br /> ==III. Detailed Description==<br /> <br /> ===III.1 Low level networking===<br /> <br /> The ServerLink/NetHandler classes are already written generic enough to be reused by the daemon to host TCP sessions. I propose moving these classes into their own library, as part of the net project and making specialized classes for non-generic code.<br /> <br /> ===III.2 Authentication Process===<br /> <br /> Before the client connects to a server, it first connects to the daemon and initiates an RSA handshake. The daemon sends its public key to the client, which in turn encrypts the username and password and sends it. The daemon decrypts the message using its private key and replies with a random token generated for the client's new session and stores that token for future validation. Tokens could have a period after which they expire and may be invalidated after being verified by the server. The daemon could also periodically generate new public-private key pairs to maintain a decent level of security.<br /> <br /> When connecting to the server, the client sends this token for it to verify. If the server requires global authentication, it connects to the daemon and passes the token along with the player's callsign and the daemon replies if the token is correct.<br /> <br /> For in game registration, the client initiates an RSA session with the daemon in the same manner as described above and sends the encrypted registration data. After the daemon finishes the registration process it sends an error code to the client which displays a message accordingly. Errors that could occur are for example the callsign being already registered or the password being too short or if access to the LDAP server times out.<br /> <br /> I propose using the primitives in the OpenSSL library for RSA. These are simple enough to use and provide everything we need.<br /> <br /> Note that public key cryptography is necessary for registration because at that point there is no shared secret between the client and daemon yet. For authentication however, a simpler solution might also suffice like salted hashing.<br /> <br /> If the client chooses not to use the new auth method, the token is retrieved as usual from the list server. When sending the token over, the client also tells the server to use the list server for validating the token.<br /> <br /> ===III.3 LDAP backend===<br /> <br /> The daemon invokes functions from the OpenLDAP library. First it binds to the LDAP master server.<br /> When auth requests arrive it issues an asynchronous search operation. It queues the message identifier and periodically polls for results. When it gets a result it sends a reply to the client accordingly.<br /> <br /> When register requests arrive first of all it checks if the callsign is already registered with a search operation. If that succeeds it carries on with an async modify operation. It queues this as well and polls for the result. If it fails for some reason it tries again a couple of times. If it times out it sends an error message, otherwise it signals a successful registration to the client.<br /> <br /> If the search or modify operations return the LDAP_SERVER_DOWN error code for example, the daemon will fall back to one of the replicated slaves. It will cache the modify operations in memory until the master LDAP server comes back online and until then, search operations would first check the cache and then the slaves.<br /> <br /> ===III.4 Client/server integration===<br /> <br /> Additional instances of ServerLink classes will be made in both the client and server when connecting to the daemon. For example a global authLink variable could exist for this purpose.<br /> <br /> ===III.5 Registration menu in the client===<br /> <br /> There could be a &quot;Register&quot; menu point in the main menu of the client that would bring up the registration menu. For starters this could ask for the user's desired callsign, password and an email address. Interfaces for changing username/password could also be considered.<br /> <br /> Validation of the provided registration info is done by the daemon and a message is displayed once it responds, or a time out message if it doesn't. Depending on the error message, certain fields in the form could be highlighted.<br /> <br /> ===III.6 Design goals===<br /> <br /> Since this is a project that will probably have plenty on the TODO list long after the summer deadline, a very important design goal will be for it to be easily maitainable. As such, I will try to code in a generic manner wherever possible, create clear/easy to use class interfaces and always think ahead for future expansion.<br /> <br /> ===III.7 Other===<br /> <br /> Settings like IPs of the LDAP servers, timeout delays, security options, minimum password length etc will be read from the command line and from a configuration file, in the same format as bzfs.conf for example.<br /> <br /> All connections to the daemon as well as it's internal operations will be logged to a text file and to the console if desired.<br /> <br /> ==IV. Timeline==<br /> <br /> June 16th: move the ServerLink/NetHandler code into its own lib<br /> <br /> July 7th: create the foundation for the daemon that can accept connections from the client/server<br /> <br /> July 14th: link OpenLDAP to the project, implement the LDAP backend for the daemon<br /> <br /> July 21th: add the option to the client and server to connect to the daemon for authentication<br /> <br /> July 28th: link OpenSSL to the projects, implement the RSA handshake and the auth chatter<br /> <br /> August 4th: create registration menus in the client<br /> <br /> August 11th: make use of RSA for sending the email address/password for the registration<br /> <br /> August 18th: The implemented features should be tweaked/tested and most bugs fixed.</div>

Wyk3d