This is a proposal for change in the way security is defined within the University's administrative NSM applications (this currently includes all Natural applications other than BUDGET). It also addresses the means for defining and maintaining the reviewers for TARGET transactions (the approval chain for a transaction). These two areas are proposed to be addressed by a common solution involving the creation of desks. Some agreement and consensus on this proposal is required so that development of TARGET functions can proceed.
Security definitions have traditionally been associated with an individual. This works well as long as the person's responsibilities are constant. However, it means these definitions must be reviewed, removed, and re-established whenever an employee is hired, terminated, assigned a new job, or the individual's job responsibilities otherwise change. The track record for performing such changes is abysmal. It could certainly be improved by automation. For example, a security administrator could be notified of personnel changes as they are recorded within the human resource system. However, the maintenance effort associated with these changes would be continuous and burdensome to the administrators of application security and TARGET transaction routing. This situation will worsen as BASIS is implemented since it will be composed of many new applications to which users must be defined; will involve many new users due to its reliance on distributed access, data entry, and electronic approval; and will require TARGET routing definitions.
The security administration task for many systems is performed within Computing Services. However, with NSM applications the owners of applications are their own security administrators and are responsible for defining who has what type of access. The situation will be similar with TARGET routing information, a user (the TARGET administrator) will be responsible for maintaining the routing definitions.
Alternatives to individualized security have been utilized at other institutions, specifically Boston College and Penn State University. We would like to follow their lead. These sites have used different approaches, but the same basic concept: do not associate access rights directly with an individual but instead with the position, desk, or job to which the individual is assigned. This design is based upon the premise that the job being performed is less volatile than the individual performing it (the job itself changes less often than the person that is assigned to it). Using this approach, an individual's assignment is all that needs to be recorded since the system access privileges for that position, desk, or job automatically follow. Mass changes to security definitions throughout all systems will no longer be required with every personnel change.
The following proposal outlines specific changes to security definitions and security administration procedures for administrative applications.
Computing Services will create a desk entity. It will represent the job being performed (specifically those tasks related to the use of computerized administrative systems) more than the unique position an individual is filling. This concept permits several individuals to be associated with the same desk when they perform the same job (e.g., registration data entry operators). However, the norm will be that one desk is associated with one individual since most jobs are unique. In addition, one employee will typically be associated with only one desk (see the section on Interim Assignments for exceptions to this condition).
Desks will be associated with and defined within departments or budgetary units. The department heads, or individuals they choose to designate, will be responsible for the creation and definition of the specific desks within their department. The definition of a desk will include a description of the functions or responsibilities of the desk, as defined and to the extent desired by the department. Department heads will then be responsible for associating employees within their department to the desks they created. This definition of desks and association of employees to desk is only required when there is a need for access to an NSM application (this excludes SAFARI, MSA, and a few other systems). This assignment of responsibility to the department head is logical since he is the one that:
Initially, the association of an employee with a desk will be done via the employee's user-ID (assigned by Computing Services and retained by the employee for the duration of his career at the University). Later, this association will be accomplished via positions defined within the BASIS Position Control system. The department head will be provided online facilities to directly update the desks associated with user-IDs (and later billets) assigned to his department.
Note: In the interim and until billets are defined, Computing Services will be responsible for maintaining the correct department for all user-IDs. This will require close monitoring of personnel changes within the University (this will probably be accomplished by developing programs to access data within the Payroll or Budget system). When there are changes, the user's department will have to be updated and the old desk association removed.
NSM application access and TARGET transaction routing will be based upon desks. The current user definition for access to an application and association with selected privileges will be replaced by a desk definition. The establishment of these access rights will continue to be the responsibility of the application owners (personnel from the central offices for whom the application was built, who will also be defined in terms of desks). It will not be necessary for the owners to know who is assigned to the desk that they are giving access to, since it could change at any time without their knowledge. The owners may limit or question the need for access as they deem necessary, but essentially they are giving that department head the right to reassign that access. The department head will continue to initiate (or authorize) the request for access, except the request will be in terms of a desk. The department head will be able to assign as many employees as desired to work that desk.
This system will work as follows. Users will sign-in with individualized IDs using confidential passwords (as they do currently). The system will automatically make the association of that user with a desk. The access rights and privileges of that user will then be those established for that desk. For TARGET transactions, that user will be allowed to review those transactions that have been routed to that desk.
Note: A desk that is associated with several individuals should generally not be established as a review point for TARGET transactions. Many individuals attempting to review the same transactions might lead to confusion. This should not be a problem because at the management level where transactions are being approved, several people would not be assigned to the same desk (those jobs are not shared by many people).
Once the position control system is in place, the above process will be accomplished by looking up the individual's current billet information by SSN (required for each user-ID) and retrieving the desk defined for that billet. In this manner, new hires, terminations, and re-assignments will automatically carry with them appropriate changes in an individual's system access rights. On the other hand, changes in the responsibilities of an individual or a desk will require updates to the definition of the desk and its security privileges. The need for such reassessments must be identified by, and will be the responsibility of, the department head who will work with application owners and the TARGET administrator to effect such changes.
There are occasions where an individual is asked to perform two jobs on a temporary or interim basis. Since both jobs may involve the performance of administrative tasks using the University's computer system and since the system access rights and TARGET approval routings are pre-established for the two separate desks represented by the two jobs, the person needs to be authorized to work two desks. This proposal includes provision for allowing a user (and later a billet) to be assigned to two desks concurrently. However, for technical reasons a user that is assigned to two desks will be required to explicitly identify which desk he will be working at any one time. His security restrictions and TARGET transaction approval ability will be determined by his choice of desk. Since this procedure may be somewhat troublesome for the user, it is recommended that this dual desk feature only be used in situations where there are true interim assignments.
In some situations, temporary help is used to perform computerized administrative functions. It is not practical to issue personal IDs to these temporary employees nor should the IDs of permanent staff be loaned to them. Instead, it is proposed that temporary IDs be requested by and issued to a supervisor. These IDs will be coded as temporary and will be associated with the supervisor via SSN and name, and also associated with the supervisor's department. The supervisor will be responsible for assigning an ID and providing the password to a temporary employee for the performance of a specific task. When that task has been completed, the supervisor will be responsible for changing the password for the ID. The supervisor will be held responsible for the actions performed with the temporary IDs he was issued.
Access rights for temporary IDs will be determined by an association with a desk, as it is for full time staff. However, the process used to establish that access will be slightly different. When a user logs on with a temporary ID, the system will not attempt to associate that ID with a billet to determine a desk assignment but will get the desk ID directly from the definition of the temporary user-ID (as it will be done for everyone initially). The department head will make the assignments of desks to temporary IDs just as he does for billets and full time staff.
The following steps have been defined for the implementation of the desk concept at the University. Note that all initial responsibilities have been assumed by Computing Services.
The security administration procedures outlined in this proposal are very similar to those currently in place. They are more automated in that facilities are provided for departments to directly make many assignments which currently require written requests or telephone calls. The object of the administration is very different since it is in terms of the more abstract concept of a desk instead of a real and tangible person.
There are many benefits to making the transition outlined here. Some departments may object to the responsibility for maintaining desks and assigning them to their employees since this may be perceived as a burden. However, initial response from a few areas indicates that some will relish the opportunity to directly control their computerized access of administrative systems.
The outcome of this proposal will determine how we will manage and administer our application systems. It is not clear what approval is required in order to proceed. Computing Services shoulders almost all of the initial burden of implementation. However, some responsibility will fall on the individuals assigned the task of defining and maintaining the definitions of desks and associating those with individuals/billets. The application owners are also affected in that they will be defining access to their systems in terms of desks and not individuals. The initial implementation will be difficult for Computing Services, but the long term benefits to the University are expected to far outweigh the cost of this transition. It is hoped that there will be a consensus to pursue this proposal, or a modified version of it. Significant objections will block the implementation.