Changes between Version 9 and Version 10 of Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

Timestamp:

Sep 8, 2006, 5:59:07 PM (18 years ago)

Author:

hedinger

Comment:

—

Internal/Rbac/OrbitRbacDesign/ThreatAnalysis

@@ -1 +1 @@
 [[TOC(Internal/Rbac, Internal/Rbac/OrbitRbacLevels, Internal/Rbac/OrbitRbacDesign, Internal/Rbac/OrbitRbacDesign/ThreatAnalysis, Internal/Rbac/OrbitRbacDesign/AuditingTools, Internal/Rbac/OrbitRbacDesign/ConsistencyChecking, Internal/Rbac/OrbitRbacDesign/NistRbacSoftware, Internal/Rbac/OrbitRbacDesign/SolarisRbac, Internal/Rbac/OrbitRbacDesign/OasisRbac, Internal/Rbac/OrbitRbacDesign/DesignByWiki, Internal/Rbac/OrbitRbacDesign/OpenIssues, Internal/Rbac/LdapResources, Internal/Rbac/RbacResources)]]
 ==== ORBIT Threat Analysis ====
-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 the certain privileges when acting in a given role. 
+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. 
 
 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.