Abstract:
A computer security system automatically updates an access status and a level of access privilege for each user based on outside feeds related to current status of the user with respect to an organization, such as a business or school and the membership of the user in a group or department within the organization. A unique user identifier is assigned to each user across all computing systems. The computing system retains the relationship between the user and the user identifier even after the user&#39;s access to the computing system is terminated. The user may be reassigned the same user identifier should the user again be granted access to the system resources. The computing security system may be implemented as an overlay to an existing resource allocation system, such as the RACF system commonly found on many mainframe computers and may allow decentralization of certain security functions.

Description:
TECHNICAL FIELD 
     This invention relates to computers, computer networks, and more particularly to providing automated security in such systems. 
     BACKGROUND OF THE INVENTION 
     Computers and computing systems are often interlinked in a network to provide easy communications and data transfer between the various components of the network. Such networks may be composed of mainframes, minicomputers, and microcomputers, and may indeed be composed of combinations of all of the above. Each system on the network will typically operate under control of a software program, providing access to a database. In some systems, dummy terminals, or microcomputers configured to act as dummy terminals, will provide communications with the computing system. 
     Security for system resources and data stored on the system, are a primary concern for most computing systems. Many systems have been proposed for controlling access to computing resources and the data. For example, one of the most commonly used security systems for mainframe computers is the Resource Access Control Facility (RACF) provided by International Business Machines Corporation (IBM). The RACF employs controlling software on a mainframe associated with a RACF database. The RACF not only controls access to the computing system, but also controls the level or amount of access allowed to a user. In the RACF security system, a unique RACF user identifier is assigned to each user. Each RACF user identifier has a unique password to verify the identity of the user requesting access to the computing system. 
     The RACF enables organizations to define individuals and groups who use the system that the RACF protects. For example, a group may be defined that encompasses a collection of individuals having common needs and requirements. The RACF also enables an installation to define authority levels for a user or a group of users. The authority levels control what a user or member of a group can do on the system. The RACF also protects the system&#39;s resources, protecting an organization&#39;s information stored on the system by controlling which users have authority to access a system resource, such as a document or program. 
     The RACF stores all information about users, groups and resources in user, group and resource profiles. A profile is a record of RACF information that has been defined by a security administrator. A user profile provides user attributes that describe the system-wide and group-wide access privileges to protected resources for a user. Similarly, a group profile defines the authority that a user who is a member of the group has to access resources belonging to the group. A resource profile defines the type of authority a user needs to access a specific resource. A resource profile may contain an access list as well as a default level of access authority for the resources the profile protects. An access list identifies the access authorities of specific users and groups, while the default level of access authority applies to any user not specifically included in the access list. 
     As the number of computers or data centers increases, and as the number of users increase, the security system becomes more difficult to maintain. Even the process of assigning new user identifiers takes up an inordinate amount of time and expense. 
     Such computing systems are often used in businesses and schools. In such situations, each computing system or data center is often associated with a group or department within the business or school. As the number of users increases, the number of changes required to maintain the security system overwhelms the ability of security personnel to maintain the system. For example, the level of access privilege may be associated with a department to which a user is assigned. Each time the user is reassigned to a new department, security personnel have to adjust the level of access privilege for the user identifier assigned to that user. 
     Such a large system presents numerous problems for those in charge of system security. Problems may include assigning duplicate user identifiers to more than one user, failure to provide timely access for new users or to terminate access to terminated users in a timely manner, and failure to update the level of access privilege in a timely manner. A related problem, is the assignment of multiple user identifiers to a single user across a number of computing systems. Such multiple assignment makes it difficult for the user to remember the correct user identifier, often causing the user to write the user identifier and any associated password down, making the user identifier and password vulnerable to theft. Such multiple assignment of user identifiers may also make it difficult to screen the system for improper access privilege and level of access privilege. Such systems are particularly vulnerable to terminated employees and contractors, who may seek access to the system resources and/or data after the end date of their employment. 
     SUMMARY OF THE INVENTION 
     The present invention overcomes the limitations of the prior art and provides additional benefits by providing a centralized data center including a database and an overlay of software for automating maintenance of a security system across multiple data centers. The system provides for automatically updating access status based on an outside feed to the system concerning the status of the user associated with the user identifier, such as employment status. The system automatically maintains an access privilege level based on an outside feed related to a group or department to which a user associated with a user identifier belongs. The system automatically assigns a uniform user identifier to a user across all data centers or computing systems. Each user is assigned a unique user identifier, the user identifier being unique across all data centers. The system retains the association between the user identifier and the user even after access for the user has been terminated. The user is then automatically reassigned the same user identifier at a later date. The system provides for multiple reporting functions to ensure adequate security. 
     While the security system is discussed as an overlay to existing security systems on mainframes, such as RACF, the security system may be implemented with the mainframe or data center level security functions integrated into the security system. Also, while discussed in terms of mainframes, other networks of computers may also realize similar advantages, such as networks of minicomputers, workstations, microcomputers, or networks combining a combination of various computers. 
     In one exemplary embodiment, a method for automatically providing security in a computing system comprises assigning a key to one of a plurality of accounts, obtaining a group identifier from a database based on the key, and assigning a level of access privilege to the account that corresponds to a default level of access privilege associated with the group identifier. 
     In another exemplary embodiment, a method for automatically providing security in a computing system comprises assigning each user a unique user identifier, maintaining a database associating each of the users with the assigned identifiers, associating the user identifier with an account, automatically terminating the association between the identifier and the account when the user is terminated, and continually maintaining the relationship between the user identifier and the terminated user in the database after the association between the account and the user identifier has been terminated. 
     In a further exemplary embodiment, a method for providing security in a first and a second computing system comprises assigning each user a unique user identifier, automatically maintaining a database associating each user with the assigned user identifier, associating the user identifier assigned to the user with an account on the first computing system for each user that will be given access to the first computing system, and for each user that will be given access to the second computing system, automatically searching the database for the user and if the user exists in the database associating a previously assigned user identifier with an account on the second computing system, or associating a new user identifier with the account on the second computing system if the user does not exist in the database. 
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS 
     FIG. 1 is a logical block diagram of a computer network including an administrative data center and a number of networked data centers. 
     FIG. 2 is a schematic diagram of an exemplary RACF data structure which resides in a RACF database on a computer. 
     FIG. 3 is a block diagram showing various data structures of a security database. 
     FIG. 4 is a block diagram showing data flows in the exemplary embodiment. 
     FIG. 5 is a block diagram according to an exemplary embodiment, illustrating a logical process of periodically updating the security database. 
     FIG. 6 is a logical block diagram of the computer network including a terminal for providing input and output to an administrator. 
     FIG. 7 is a flow diagram according to an exemplary embodiment, illustrating a logical process of assigning a user identifier an employee. 
     FIG. 8 is a flow diagram according to an exemplary embodiment, illustrating a logical process of assigning a user identifier to a contractor. 
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     In the following description, certain specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. However, one skilled in the art will understand that the present invention may be practiced without these details. In other instances, well-known structures and methods associated with computers, computer networks, and related security have not been shown in detail in order to avoid unnecessarily obscuring the description of the embodiments of the invention. 
     Most organizations, including companies, schools, and other associations, are arranged in a hierarchical fashion. Such organizations may, for example, be composed of multiple companies, each company consisting of a number of departments. The people associated with the organization, such as employees associated with a business, and even the resources of the organization, such as computing systems, are often associated with a department or other grouping. Organizations rely on a hierarchical structure to establish management and accounting functions throughout the organization. 
     Many of the personnel and resources that comprise a department share similar tasks and authority. The exemplary embodiments of the present invention take advantage of the similarity in tasks and authority by assigning a default level of access privilege for the organization&#39;s computing resources to each account assigned to each member of the department. While all members of any given department receive the same default level of access privilege, the default level of access privilege between different departments may be varied according to the departments assigned tasks. A department member&#39;s level of access privilege may be modified from the department&#39;s default level of access privilege as the need arises. 
     FIG. 1 shows a computer network 10 including multiple data centers, each of the data centers having at least one computing system associated therewith. A central computing system 12 is designated as a central repository for data related to a security system 11. The central computer system 12 is linked to a number of peripheral computing systems, such as computing systems 14, 16 and 18. Communication may be provided by conventional means such as fiber optic cable, infrared, or satellite transmission. While the computing system 12 has been designated as the central computing system, such designation should not be read to imply any particular topology on the system. 
     Each of the computing systems 12-18 has a respective RACF database 22-28. Each of the RACF databases 22-28 stores information for controlling access, access privilege level, passwords and authority for accessing the respective computing system. Relevant details of the RACF databases 22-28 will be discussed below. 
     The central computing system 12 includes a security database 30. The security database 30 includes numerous data structures or records that in conjunction with software provides for the automated maintenance of the security system across all of the data centers. The details of the specific data structures and their relationships will be discussed below. 
     Maintenance software 40 for interacting with the security database 30 may be resident in the central computing system 12 or in an external system (not shown). The software periodically updates the security database 30 and permits security personnel to generate reports and to make special updates of the system. Propagation software 32-38 automatically communicates changes in the central computing system&#39;s RACF database 22 to the peripheral computing systems 14-18 for updating the RACF databases 24-28, respectively. Propagation software is commercially available in packages such as NC-SYNCOM® from CKS, Inc. 
     FIG. 2 shows an exemplary data structure 52 for the RACF database 22-28. The RACF data structure 52 comprises a number of fields, of which only the ones particularly relevant to the invention will be discussed in detail. A user field 54 includes a user identifier. An RVKE field 56 holds a value that corresponds to an access status. The RVKE field 56 may be set to provide access or to deny access to the computing system for the user identifier associated with the RVKE field 56. The RACF data structure 52 includes a DFLTGRP field 58 which holds an eight character value that corresponds to a default group to which the user identifier is assigned. The RACF data structure 52 also includes an installation data field INSTALL 60, that may be customized for particular purposes. 
     FIG. 3 shows a number of data structures that comprise the security database 30 and which provide storage for data the security system 11 receives from various feeds. The data structures are shown in the form of tables of records having associated fields, although one skilled in the art will recognize that other data structures may be used. Data structures including ORG --  DATA 62, HR --  DATA 68 and CONTRACT --  DATA 80 data structures store information relating to the organization and the personnel associated with the organization, such as employees and contractors. Data structures including USERID --  PROF 92, GROUP --  PROF 110 and USERID --  DATA 200 data structures store information relating to user accounts on the computing systems 12-18. A data structure USER --  GROUP --  CONNECT 118 stores information that relates the data in the organizational data structures to the data in the user system account data structures. The specific details of the various data structures are discussed immediately below. 
     A data structure ORG --  DATA 62 stores information about an organization, such as a business or school. The information may, for example, be related to a hierarchical structure of the organization, such as companies and departments. In the exemplary embodiment, a field OD --  COMPANY 64 stores a company identifier, while a field OD --  DEPT 66 stores a department identifier. 
     A data structure HR --  DATA 68 stores information relating to members of the organization, such as the employees of a business. A field HD --  SSN 70 stores an employee identifier such as a social security number, for uniquely identifying each employee. A field HD --  NAME 72 stores the name of the employee associated with the unique employee identifier. A field HD --  DEPT 74 and a field HD --  COMPANY 76 store, respectively, a department identifier and a company identifier to which the employee is assigned. Similarly, a field HD --  STATUS 78 stores a status, such as the employment status of the employee. One skilled in the art will understand that the labels chosen and the particular information represented is selected for convenience and the fields may relate to other groupings depending on the situation or organization using the security system. For example, department and company may correspond to the schools and departments of a university, while the employees correspond to registered students. The claims should therefore not be limited to the particular exemplary embodiment discussed. 
     A data structure CONTRACT --  DATA 80 may hold data related to contractors that are working for the organization. The CONTRACT --  DATA 80 structure includes a field CD --  SSN 82 for storing a unique contractor identifier, such as the contractor&#39;s social security number. A field CD --  NAME 84 is provided for storing the name of the contractor associated with the unique contractor identifier. A field CD --  DEPT 86 and a field CD --  COMPANY 88, respectively store a department identifier and a company identifier of the department and company to which the contractor is assigned. A field CD --  TERMDATE 90 stores the termination date of a contract under which the contractor has been hired. 
     A data structure USERID --  PROF 92 stores most of the information required for the RACF data structure 52 (FIG. 2), with the INSTALL field 60 customized for the application. The USERID --  PROF data structure 92 includes a field UP --  USER 94 to store a user identifier. A field UP --  RVKE 96 stores an access status, such as access granted or access denied. A field UP --  DFLTGRP 98 stores a group identifier of a group to which the employee associated with the user identifier belongs. A field UP --  SSN 100 stores a unique employee or contractor identifier, such as the social security number. Thus an employee or contractor is associated to the user identifier through the USERID --  PROF data structure 92. The USERID --  PROF data structure 92, also includes a field UP --  DEPT 102 for storing the department identifier for the employee or contractor associated with the user identifier. A field UP --  OWNER 104 stores the identifier of an owner that has authority over the user identifier. Additionally, fields UP --  CREADATE 106 and UP --  PASSDATE 108 fields store the account creation and password creation dates, respectively. 
     A data structure GROUP --  PROF 110 stores hierarchical ownership information for the computing system. A field GP --  GROUP 112 stores a group identifier. A field GP --  OWNER 114 stores an owner identifier for the group. A field GP --  SUPRGROUP 116 stores a superior group identifier for the group. Each group has an owner, identified by the owner identifier and a superior group, identified by the superior group identifier. The owner of a group has authority to control the attributes associated with the group and the attributes associated with user identifiers in the group. 
     A data structure USER --  GROUP --  CONNECT 118 provides the connection between the user identifier and the group to which the user identifier belongs. A field UGC --  USER 120 stores the user identifier, while a field UGC --  GROUP 122 stores a group identifier. Additional fields may be provided, such as UGC --  OWNER 124 for storing the identifier of an owner, and UGC --  REVOKE 126 for storing an access status. 
     A data structure USERID --  DATA 200 permanently stores user and user identifier relationships. The USERID --  DATA 200 table includes a UD --  SSN 202 field for storing a unique identifier, such as the user&#39;s social security number. A UD --  ID 204 field stores the unique user identifier. A UD --  STATUS 206 field stores the status of the user identifier. The USERID --  DATA data structure 200, maintains the relationship between the user and the user identifier even if the user ceases her association with the business, school or organization. In this way, unique user identifiers may be assigned, and reassigned if the user should again become associated with the organization. 
     While certain fields of the data structures have been enumerated, each data structure may comprise additional fields for storing a variety of information, such as passwords, account creation date, password assignment date, and company information, such as information regarding the manager of the employee or contractor. Such additional information may also include location, addresses, telephone numbers and email addresses for the employees and the contractors. Such information may for example, be stored in fields in the HR --  DATA 68 and CONTRACT --  DATA 80 data structures. 
     FIG. 4 shows the generalized inputs and outputs to the security system 11 for establishing and maintaining access authority and access privilege levels. The security system 11 automatically receives data for the fields of the above described data structures from various databases in various departments of the organization. The data comprising the inputs may reside on the central computing system 12, on the peripheral computing systems 14-18, or on other systems. The inputs will generally be used to update the security database 30 and for running verification checks on the data using the maintenance software 40. Similarly, the outputs from the security system 11 may reside on the central computing system 12, the peripheral computing systems 14-18, or other systems. 
     The security system 11 receives the organization&#39;s hierarchical structure information from a general ledger 130. The general ledger 130 includes information such as the organization&#39;s departments with associated department identifiers, and the organization&#39;s companies, if appropriate. Many companies, schools, and other organizations maintain a general ledger to assist in managing and accounting for the organization. Often, it is the duty of a management department to maintain the general ledger 130. Computer security personnel will often not know of the addition or deletion of departments until long after such changes have been made. The present security system 11 remedies this problem, as will be described below. 
     Many companies have a human resources department that maintains information regarding employees in a database. The security system 11 receives employee information from a human resources database 132. The human resources database 132 will typically include personal information such as, employee&#39;s social security number, employee&#39;s name, home address and telephone number. The human resources database 132 will also typically include work related information such as, the employee&#39;s work address, company, department, paycode or salary information and employment status. The human resources database 132 may also include information regarding the employee&#39;s supervisor. The security system 11 may directly access the human resources database 132, or the human resources department may provide periodic extracts of the human resources information to the security system 11. 
     Similarly, many companies will have a department that maintains information regarding contractors in a database. The security system 11 receives contractor information from a contractor services database 134. Such information may include, the contractor&#39;s name and social security number, the company and department to which the contractor is assigned, and the termination date of the contract under which the contractor has been hired. The security system 11 may directly access the contractor services database 134, or the contractor services department may provide periodic extracts of the contractor information to the security system 11. 
     Additional information about the employees and contractors, such as work related telephone numbers and e-mail address may be stored in a locator system database 136. The security system 11 may directly access the locator system database 136, or extracts of the locator information may be periodically provided to the security system 11. 
     In order to decentralize control, and to permit rapid updates, administrators 138 are assigned in each department. The administrators 138 are given authority through the security system 11 to set and change the attributes for user accounts assigned to users in the administrator&#39;s department. The administrators 138 also receive reports generated by the security system 11 regarding the user identifiers over which the administrators 138 have authority. 
     Systems security personnel 140 have authority through the security system 11 over all user identifiers, including those assigned to administrators 138. Systems security personnel 140 will often also have RACF authority, allowing the system security personnel 140 to directly modify the RAFC attributes at the RACF level of mainframe security. An input/output device such as a terminal (not shown) provides security personnel with access to information, reports and control over the security system. 
     The security system 11 interacts with the RACF database 22 on the central computing system 12 for receiving data and issuing RACF commands. An exemplary method of periodically updating the security database 30 is shown in FIG. 5. FIG. 5 is not an exhaustive flowchart, and additional steps may be added and other steps deleted as the situation requires. In step 142, the RACF databases 22-28 are unloaded by the security system 11 periodically, such as nightly. In step 144, the unloaded data from the RACF databases 22-28 populates the USER --  GROUP --  CONNECT 118, GROUP --  PROF 110 and USERID --  PROF 92 data structures of the security database 30. In step 146, the security system imports the human resources data from the human resources database 132. In step 148, the human resources data populates the HR --  DATA 68 table of the security database 30. Similarly, in step 150, the security system 11 imports the contractor data from the contractor services database 134 and uses the contractor data to populate the CONTRACT --  DATA 80 table of the security database 30 in step 152. In step 154 the security system imports organizational data from the general ledger 130, and in step 156 uses the imported organizational data to populate the ORG --  DATA 62 table of the security database 30. One skilled in the art will note that data such as the organizational data does not change frequently and therefore may be loaded into the security database 30 on a less frequent schedule than the other data. 
     In step 157, the security system 11 uses the data in the HR --  DATA 68, CONTRACT --  DATA 80 and ORG --  DATA 62 tables to verify the accuracy of the data loaded into the USER --  GROUP --  CONNECT 118, USERID --  PROF 92 and GROUP --  PROF 110 tables from the RACF databases 22-28. For instance, the security system 11 may verify that the department to which an employee or contractor is assigned has not changed. The security system 11 may also verify the status of each employee and termination date of each contractor. In cases where the data is inconsistent, the security system 11 issues RACF commands to update the RACF database 22 on the central computing system 12, as in accord with step 158. The security system 11 may also automatically provide a message to system security personnel, the administrator 138 or the user regarding any changes in access or level of access privilege. Where a user&#39;s access is being terminated, the user identifier assigned to the user may be associated with a hold account, by issuing a RACF command. The hold account is owned by the security personnel and does not permit the user to access any of the computing systems 12-18. As discussed above, the propagation software 32-38 propagates the changes made to the RACF database 22 to the peripheral computers 14-18, where the respective RACF databases 24-28 are updated. In this way, security is maintained across the entire network of computers 10. 
     FIG. 6 shows an exemplary embodiment of the computer network 10 and the general data flow in the computer network 10 for the situation in which the administrator 138 (FIG. 4) selectively updates data for a particular user or user identifier, such as assigning a user identifier. A terminal 162 is coupled to the central computing system 12 for permitting the administrator 138 (FIG. 4) to access user information and to assign user identifiers. The general data flow shown of FIG. 6 is described in further detail below, with reference to FIGS. 7 and 8. 
     FIG. 7 shows an exemplary embodiment of the steps performed by the administrators 138 in periodically assigning a user identifier to an employee on the computer network 10 of FIG. 6. In step 164, the administrator enters the employee&#39;s social security number on the terminal 162. In step 166, the security system 11 retrieves human resources data about the employee from the HR --  DATA 68 table of the security database 30. In step 168, the security system 11 displays the retrieved human resources data on the terminal 162. The security system 11 checks the HD --  STATUS 78 field of the HR --  DATA 68 data structure to determine the employment status of the user in step 170. If the employment status is inactive, then in step 172 the security system 11 displays a message telling the administrator 138 that the employee is on inactive status and may not be assigned a user identifier. If the employment status is active, then the security system 11 determines whether the administrator 138 has authority to assign a user identifier to the employee, as in step 174. In step 175, the administrator 138 is prompted with a message if the administrator 138 does not have authority over the user. 
     In step 176, the security system 11 checks to determine whether the employee has been previously assigned a user identifier. The security system inspects the UD --  SSN 202 field of the USERID --  DATA 200 table for matches to the employee&#39;s identifier. If the employee has already had a user identifier assigned, the previous user identifier will be reactivated. In step 178, the security system 11 updates the UD --  STATUS 206 field of the USERID --  DATA table 200 as a first step in reactivating the user identifier. If no previous user identifier has been assigned, the security system 11 generates a new user identifier in step 180. At least some portion of the user identifier should be randomly generated to provide a high degree of security for the security system 11. In step 181, the security system 128 verifies that the new user identifier is unique by checking the USERID --  DATA data structure 200. The security system 128 generates another new user identifier if the previously generated user identifier is not unique. In step 182, the security system 11 updates the USERID --  DATA table 200 with the new user identifier. The appropriate level of access privilege is automatically assigned to the user by way of the relationship between the fields of the various data structures HR --  DATA 68, USERID --  PROF 92, GROUP --  PROF 110 and USER --  GROUP --  CONNECT 118. 
     The security system 11 then issues a RACF command, in step 184, against the RACF database 22 of the central computing system 12 to update the RACF database 22 with the changes made to the USERID --  DATA 200 table. In step 186, the changes in the central computing system&#39;s 12 RACF database 22 are propagated through the network to the appropriate RACF databases 24-28 of the peripheral computing systems 14-18. 
     FIG. 8 shows an exemplary embodiment of the steps performed by the administrators 138 in periodically assigning a user identifier to a contractor on the computer network 10 of FIG. 6. In step 188, the administrator enters the contractor&#39;s social security number on the terminal 162 (FIG. 6). In step 190, the security system 11 retrieves contractor data about the contractor from the CONTRACT --  DATA 80 table of the security database 30. In step 192, the retrieved contractor data is displayed on the terminal 162 (FIG. 6). The security system 11 checks the CD --  TERMDATE 90 field of the CONTRACT --  DATA 80 table to determine the termination date of the contractor in step 194. If the termination date is at or before the current date, the contractor has been terminated and, in step 196, the security system 11 displays a message telling the administrator 138 that the contractor is terminated and may not be assigned a user identifier. The security system 11 may also determine whether the termination date is within some set period of the current date, as in step 198, and provide a message warning the administrator 138 that the contract will soon terminate, as in step 199. If the contractor&#39;s status is active then the security system 11 determines whether the administrator 138 has authority to assign a user identifier to the contractor, as in step 208. In step 210, the administrator 138 is prompted with a message if the administrator 138 does not have authority over the user. 
     Steps 212-220 of FIG. 8 are similar to steps 176-184 of FIG. 7, whereby the security system 11 determines whether the contractor has been previously assigned a user identifier, reactivates a previously assigned user identifier or generating a unique new user identifier, updates the fields of the data structures appropriately and issues RACF commands against the RACF database 22 of the central computing system 12. The changes in the central computing system&#39;s 12 RACF database 22 are propagated through the network to the appropriate RACF databases 24-28 of the peripheral computing systems 14-18 in a manner similar to that shown in step 186 of FIG. 7. 
     In a similar manner, the administrators 128 may authorize additional access for a user identifier such as time sharing access (TSO) to one of the computing systems 12-18, or may revoke a user identifier, resume a revoked user identifier, or reset passwords. 
     Additionally, the systems security personnel may grant a level of access privilege different from the default level of access privilege assigned to the user identifier based on the department to which the user of the user identifier belongs. This is accomplished by issuing appropriate RACF commands against each of the relevant RACF databases 22-28. 
     Although specific embodiments of, and examples for, the present invention are described herein for illustrative purposes, various equivalent modifications may be made without departing from the spirit and scope of the invention, as will be recognized by those skilled in the relevant art. The teachings provided herein of the present invention may be applied to computer networks in schools, associations, and other organizations not necessarily the exemplary business based computer network generally described above. Accounts having user identifiers may be assigned to individuals, groups of individuals, or even inanimate objects, such as other computers. The organization employing the system may not have an equivalent of a company hierarchy, but may consist of a number of groups that equate to departments. The choice of a business structure to describe the exemplary embodiment was selected for convenience, and one skilled in the art will recognize that the names of the various data structures and fields do not imply any particular information necessary for practicing the invention. For example, the social security number is not required, and any unique identifier may be used. Additionally, the security system may work with other computer based security systems, not necessarily Resources Access Control Facility described in the exemplary embodiments. 
     These and other changes may be made to the invention in light of the above-detailed description. In general, in the following claims, the terms used should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims, but should be construed to include all automated security systems and methods of operating such security systems that operate in accordance with the claims. Accordingly, the invention is not limited by the disclosure, but instead its scope is to be determined entirely by the following claims.