Permission Strategies
Across the industry, software development sites show considerable diversity in how they structure their development environments and the degree of security they impose. Strategies range from tightly controlled, highly restrictive installations to wide open, free-fire development zones.
Whatever approach your site takes, you can tailor ACLs to deliver as much, or as little, access control as you require.
 |
Before you set up your permission strategy, it is important to understand the inheritance of permissions and the difference between allowing, denying, and clearing a permission. These concepts are fully explained in Permissions.
|
Tightly Controlled Environments
Those segments of the industry that deal with highly sensitive or confidential material can use ACLs to provide strict controls on access to configuration management functionality. To accomplish this, institute a permission structure that provides no site-wide capabilities, but grants permissions to users on a per-project basis.
To set up a tightly controlled development environment
1. In the mks:si ACL, allow the Login and OpenProject permission for the everyone principal, and then clear all the remaining permissions from the everyone principal.
|
|
It is important to understand the difference between clearing and denying a permission. For more information on this concept, see Creating a Configuration Management ACL Control.
This creates a baseline position that provides only minimal permissions to any user. All user permissions must now explicitly come from administrator-defined groups or users. For more details, see Changing Permissions.
|
2. Create a new ACL for each project. For more details, see ACL Configuration.
By associating projects with their own ACLs, you can control who has access to each project and what permissions the ACLs grant each user.
3. In each project’s ACL, add ACL entries defining the users who are allowed to work on the associated project and the permissions you allow. You may do this either by explicitly specifying each user, or by specifying groups that are controlled through your authentication scheme.
This restricts access to project data to developers and managers who are directly involved in the project.
At medium-to-large sites, assigning permissions to groups is a convenient strategy and can save hours of work required to assign roles to hundreds—or thousands—of individual users. Consider the advantages of defining groups in your authentication scheme. Working with groups is the most efficient approach, particularly when you want to tightly control access on a project-by-project basis.
4. Define roles and assign them to team members.
Even within the group, access to data and the ability to manipulate it can be distributed on an as-needed basis. For example, you may want all developers to be able to check out and lock objects, but only allow the team leader to create new projects or promote objects to a higher state.
This approach allows finely tuned control over access to PTC RV&S’s configuration management functionality and, therefore, to the development objects at your site. You can grant permissions on a per-project and per-user basis satisfying even the most stringent security requirements.
Lightly Structured Environments
Sites with less pressing security requirements can define more relaxed structures to make generalized permission sets available, while still only allowing users to access those projects they are directly involved with.
To set up a lightly structured development environment
1. In the mks:si ACL, allow the Login and OpenProject permission for the everyone principal and then clear all the remaining permissions from the everyone principal. For more details, see Changing Permissions.
This creates a baseline position that provides only minimal permissions to any user. All user permissions must now explicitly come from administrator-defined groups or users.
2. If you have not done so already, create groups in your network’s authentication system that reflect the distribution of users at your site. This facilitates role and permission assignments. For example, you might create one group for programmers, another for testers, and a third for project managers.
3. In the mks:si ACL, define new ACL entries associating the groups with particular permissions.