Changes between Version 14 and Version 15 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis
- Timestamp:
- Sep 18, 2006, 8:30:34 PM (18 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Internal/Rbac/OrbitRbacDesign/ThreatAnalysis
v14 v15 3 3 The primary motivation for using role-based access control with the ORBIT Testbed is to insure that every user has sufficient access to each and every ORBIT resource that he or she needs to perform each phase of an experiment without giving each user root privileges. Each identifiable task of each phase of each type of experiment could be a role, and a user need only have certain privileges when acting in a given role. 4 4 5 A longer term goal is to simplify the administration of ORBIT projects and project members using RBAC's administrative functions by delegating project administration to project leaders. Once a project was defined and a Project Leader assigned to it, that Project Leader would be able to add ORBIT users and add project members and assign them roles within the project as he or she sees fit.5 A longer term goal is to simplify the administration of ORBIT projects and project members by delegating project administration to project leaders and using RBAC's administrative functions. Once a project was defined and a Project Leader assigned to it, that Project Leader would be able to add ORBIT users and add project members and assign them roles within the project as he or she sees fit. 6 6 7 7 Because ORBIT is designed to be operated as a service available to the research community, no one experiment should affect a future one, and each project must be protected from other projects.