Server Configuration > Access Control List Permissions > Setting Your Permission Strategy > Sample ACL Implementation
 
Sample ACL Implementation
To illustrate how an administrator might implement policies and permissions at a specific site, consider xyzBusiness, a company with two major software projects under development.
The xyzBusiness DemoApp team is an established operation producing an application that is crucial to the health of the company. The DemoDotCom project, on the other hand, is experimental looking into new online products and areas of future diversification. These two projects require different management approaches and operating policies:
As the main income source, management must ensure that DemoApp stays on track and always delivers on time. Controls for DemoApp must be relatively stringent.
Because the DemoDotCom project is designed to research unknown territory, its policies do not need to be so restrictive. In fact, correcting mistakes and making development changes should be straightforward.
The following sections show how the administrator at xyzBusiness might set up the ACLs for configuration management taking into account the critical aspects of DemoApp while allowing the freedom and innovation needed for DemoDotCom.
The environment at xyzBusiness supports two divergent sets of development practices. The first thing the administrator must do is to establish control parameters for the entire site. The management team at xyzBusiness, however, wants to apply strict locking to its development environment to better protect valuable data. The outcome is that all member files are write-protected to maintain the integrity of the revision control process.
To implement these rules, the administrator enables and enforces an exclusive locking policy in the global configuration management policy options. For details, see “Configuration Management Policy Options”.
The next step is to provide appropriate permissions to the developers on each project and to guarantee there are no overlaps that could result in a security breach.
After studying the needs of various users, the administrator decides all registered users should be permitted to perform the following actions:
open projects, Sandboxes, and member histories
check out read-only copies of project members or archived revisions
view summary reports of project and archive activity
To accomplish this, the administrator first restricts site-wide permissions by defining the following set of ACL permissions in the everyone group on the mks:si ACL.
Login
FetchRevision
OpenProject
With this permission, the administrator ensures that, unless project ACLs assign additional permissions to them, users registered at the site can perform only the desired operations. Users who are not registered have no access to Integrity Lifecycle Manager’s configuration management functionality.
The final step is to assign appropriate permissions to the members of each project team.
Most programmers at xyzBusiness work on one project or the other, but some work on both. The administrator’s challenge is to establish ACL entries that give different permissions to programmers on each team without letting them overlap.
Because some programmers work on both projects, the administrator decides to create a role called DemoApp Developer and a role called DemoDotCom Developer in the network authentication system. By defining different permissions for the role in each project’s ACL, the administrator can assign the same programmer different permissions for each project.
At xyzBusiness, the administrator defines the allowed permissions for the Developer group for each project.
DemoApp Developermks:si:project:id:DemoApp
DemoDotCom Developermks:si:project:id:DemoDotCom
CheckIn
ApplyLabel
FetchRevision
AddMember
Lock
CheckIn
Login
Checkpoint
OpenProject
CreateProject
CreateSubproject
Demote
DropMember
FetchRevision
Lock
Login
OpenProject
Promote
Next, the administrator assigns users in each role. Programmers on the DemoApp team receive only those permissions defined in the Developer role in the DemoApp project, while the DemoDotCom’s programmers receive those defined in the DemoDotCom project.
The result is that programmers for DemoApp can work freely with their project and its member files. They can create Sandboxes, check in, check out, and so forth, but they cannot:
promote or demote project members
add or delete members
create new projects or archives
add labels
These permissions satisfy management’s need for control, while leaving programmers free to update files as required.
For a detailed description of configuration management permissions, see “Configuration Management Permissions”.
The Developer group for the DemoDotCom project is different. Its permissions allow a more open access to the project for all team members. Because the DemoDotCom project is exploratory and creative in nature, it does not require the more conservative restrictions set for DemoApp.