Changes between Version 20 and Version 21 of Internal/Rbac
- Timestamp:
- Oct 6, 2006, 4:30:49 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/Rbac
v20 v21 3 3 Role-Based Access Control (RBAC) will be used by ORBIT to ''control'' each user's ''access'' to ORBIT resources based on his or her ''role''. RBAC promises simpler administration of access control than maintaining access control lists for each resource. It enables an organization to enforce separation of duty, the principle of least privilege and timely revocation of trust. Because it is based on a formal model, a given assignment of users to roles may be checked for consistency with the organization's security design goals. 4 4 5 RBAC is being implemented in ORBIT to protect a project's information from access or disruption by other projects, to minimize some problems within projects, and to provide tools for project administration by each project's Principal Investigator. 5 RBAC is being implemented in ORBIT to protect a project's information from access or disruption by other projects, to minimize some problems within projects, and to provide tools for project administration by each project's Principal Investigator. That is, to insure that an ORBIT user has access only to information that belongs to the project he or she is working on, and is granted permissions in accord with the roles in which he or she is active. 6 6 7 7 To explain RBAC's specific use of roles, first some terminology. In normal, scheduled operation, ORBIT is designed to insure that each person using an ORBIT resource is allowed to do so at that time. The Lightweight Directory Access Protocol (LDAP) is used by ORBIT to ''authenticate'' each user's password when he or she logs into an ORBIT controller or server. LDAP authentication and the proper use of ORBIT user id's and passwords allows each user id to be related to a single human user although a single person may have one or more ORBIT user id's. Each ORBIT user id may be logged into one or more sessions, and during each session there may well be multiple computer processes initiated by the user. A ''process'' is an instance of a user running an application program like a spreadsheet, editor or browser. … … 11 11 The use of roles to control access is based on the observation that there may be thousands of users in a given organization, but there are fewer than a hundred different roles they act in at any given time to access resources. Users are assigned to one or more roles. Each role has a defined set of permissions, each permission either allowing or disallowing an operation invoked by a subject process run by a user acting in that role to access a given object. 12 12 13 Two special constraints are needed with role-based access control for ORBIT. A primary goal of ORBIT's is to insure each user has access to data and results only for his or her project(s). Second, use of the grid and sandboxes is scheduled and control of access to each of them has to be integrated with the ORBIT scheduler. 14 15 As with any access control mechanism, role-based access control will have some performance penalties. Role-based access control should provide sufficiently flexible control with acceptable performance for reasonable administrative cost. In ORBIT, role-based access control will be implemented using LDAP. Besides authenticating users, a schema will be developed for a directory of projects and roles. ORBIT RBAC will also require modifications to the services that control ORBIT resources so that access to the methods those servicess present to users can be controlled. Further, a monitor program based on the NIST RBAC/Web code is needed to grant access quickly to users when accessing these methods. It is expected that this implementation will have acceptable performance while providing the desired levels of protection and administrative capability. 13 As with any access control mechanism, role-based access control will have some performance penalties. Role-based access control should provide sufficiently flexible control with acceptable performance for reasonable administrative cost. In ORBIT, role-based access control will be implemented using LDAP. Besides authenticating users, an LDAP schema will be developed for a directory of projects and roles. ORBIT RBAC will also require modifications to the services that control ORBIT resources so that access to the methods those servicess present to users can be controlled. Further, a monitor program based on the NIST RBAC/Web code is needed to grant access quickly to users when accessing these methods. It is expected that this implementation will have acceptable performance while providing the desired levels of protection and administrative capability. 16 14 17 15 The rest of the wiki pages for the ORBIT Role-Based Access Control project are organized as follows. The [wiki:Internal/Rbac/OrbitRbacLevels RBAC Reference Model] page briefly describes the core, hierarchical, static separation of duty and dynamic separation of duty components of the RBAC specification. The [wiki:Internal/Rbac/OrbitRbacDesign ORBIT RBAC Design] page and its subsidiary pages contain design issues and decisions. The [wiki:Internal/Rbac/LdapResources LDAP Resources] and [wiki:Internal/Rbac/RbacResources RBAC Resources] pages each briefly describe important sources then give a fairly comprehensive list of references. All of the bracketed wiki references like [[http://orbit-lab.org/attachment/wiki/Internal/Rbac/RbacResources/ANSI+INCITS+359-2004.pdf Ame04]] are on the [wiki:Internal/Rbac/RbacResources RBAC Resources] page.