Roles for Typical Projects
As an example, consider two users who each have assigned roles:
• tester role in the QA group
• developer role in the Development group
Now suppose a particular project is configured with an ACL that gives full permissions to the Development group and restricts permissions to the QA group. When the QA user invokes a command that affects the project, the permission set used to determine whether this user may perform the operation consists of all the permissions in the QA group. When the Development user invokes a command that affects the project, the permissions in the Developer group apply.
|
|
Each group must be defined in your authentication scheme. For example, if you are using NT authentication, these groups of users must be defined as recognizable and authorized to access the machine hosting the Integrity Lifecycle Manager server.
|
Setting Site Wide Read-Only Permissions
As another example, consider a company that wants to permit all of its users to look at any project or member file on the system while restricting editing capabilities to developers on individual project teams. The administrator could assign the Login and OpenProject permissions to a general principal group such as the default everyone group or some similarly named principal. The administrator would then assign more specific permissions to a Development group for developers.
Although this use of mapping groups to roles can be a powerful way to control casual or unauthorized access to configuration management functions, it also requires some careful planning on the administrator’s part to provide users with the permissions necessary for performing their required work.
