RATS: The Big Picture

    RATS stands for Rutgers Account Tools and Services. It is a suite of daemons, clients, and tools that allow you to set up automated account creation on your Unix machines running Solaris. It provides a means of contacting a central repository of demographic information (the People Data Base) about the population of Rutgers University for the purposes of authentication and and access restriction with regards to account creation. The information it has available to it for the authentication phase of account creation is first name, last name, date of birth, and social security number. These are all fairly self explainatory. However, the information available for access control is not as intuitive and bears somewhat more explanation. First of all, you have the person's ROLE. This is a role they occupy at the university such as student faculty or staff. What ROLEs you have in the database are determined by the university, and are not really within your control. Next, you have HERDs. A HERD is like a ROLE in that it is basically a category that a user has membership in. The HERD, unlike the ROLE, is assigned by someone with the appropriate privileges who is involved with the RATS system. HERDS are like ROLES that you have control over if you have the right permissions, and getting these permissions are easier (possible) than with ROLEs, so you can influence who is or is not in a HERD. The full impact of this on your system is explained in greater detail in other documentation. Another bit of data you have to control access with is campus location. Campus location so far only applies to the ROLEs that represent students, and in reality turns their unit of registration code into a two letter campus location like NB, NK or CM via some internal reference tables. You can also restrict access by major. Finally, you can control access by roster information. You can see if they are in a particular class, or in a specific section of a particular class. Each of these pieces of data has an ANDed and an ORed list, and the ANDed list supports NOTing an element. These requirements can be set up for each account type you specify for your machine in the config file. In theory you can specify an infinite number of account types. RATS not only lets you use these demographics at creation time to control who can create accounts, but it lets you use them at cleanup time to assist in the cleanup process. RATS as a university wide service, provides a centralized username space. It ensures that there is only ever one person with username X among all the machines using the RATS system. Additionally, the information available to rats from the central data base, and from the local system could be useful in many aspects of account management. Since it is not within the scope of RATS purose to determine how a system should be run beyond account creation, we have simply documented the API and provided a programmers guide so that you may use RATS underlying code to creat your own tools. As a more architectural overview, for any given process performed using RATS, there will usually be a tool, a client daemon, the rats server, and a central database involved. The tool talks to the client daemon and possibly the rats server. The client daemon can talk to other client daemons, or performs tasks on the system. The rats server talks to the central database, and the kerberos server. The central database just answers the rats server. If the task being performed requires demographic data, the rats server is usually queried by the tool directly, and the rats server queries the central database. If demographic information is not required, the rats server and the central data base never become involved. If no local information is needed by the tool, the client daemon never becomes involved. All communication between the rats server, the client daemon(s), and the tools are encrypted using triple CBC_DES encryption for security. And that in a nutshell is what RATS does.