Access Groups: A Practical Approach

Build Forge Access Groups are designed to allow very granular control over permissions and access . However, the system is not very intuitive, and the best implementation not always obvious.

There are a few things that must be understood before developing any plan to control permissions:

  1. Individual users can never receive permissions directly. Permissions can only be granted to access groups. Individual users inherit their permissions from the group by virtue of their membership in it.
  2. An individual user can be a member of multiple access groups, but their permissions will always reflect, exactly, the combined permissions of those groups to which they belong. As a result, there is no way to set different permissions for the same user based on context. If they have a permission in one context, they have that permission in all contexts.
  3. Every artifact in Build Forge is controlled by one, and only one group. If a user is not a member of the object’s controlling group, then that user cannot even see, let alone act upon, objects controlled by that group.

There are two main approaches to managing permissions within this framework.

  1. Assign an object’s controlling group as one with minimal permissions and then create child groups with increasingly greater permissions. Users are then assigned to these groups.
  2. Assign an object’s controlling group with no permissions, and create separate groups which do contain permissions, but which never inherit from and are never assigned to any group which controls a Build Forge artifact.

The first method is fine, as long as the number of users and projects is limited. It quickly becomes unwieldy, however, as the number of projects increases. The more projects and other artifacts to which a user has access, the greater the number of places that will need to be considered when changes need to be made.

The advantage of the second method is that it completely separates the actions a user can take from the objects upon which those actions can be taken. Users can easily be granted or denied access to projects, servers, environments and other Build Forge artifacts by adding or deleting them from the controlling groups. If permissions for that user need adjusting, all that is needed is to change the permission group to which they belong.

As noted earlier, a user has the combined permissions of all the groups to which he or she belongs. If, for example, s/he is a member of several groups, and has delete access in one of them, s/he will have delete access in all of them. If a user’s permissions are defined in one place, it is less likely that something will be overlooked when changes are made. By the same token, it becomes very simple to control which users are associated with which artifacts.

 Inheritance of Access Groups

The difference in the way Build Forge users are contained, vs how their permissions are inherited can lead to some confusion. Any “sub groups” in Build Forge cause the group to inherit all permissions of the main group. Members, however, are not inherited by the subgroup, but are contained in the main group.

access Groups: Membership Inheritance

Build Forge Access Groups: Membership Inheritance


Access Group Members
Child A Peter, Paul, Mary, Casper, Betelgeuse
Child B Huey, Louie, Dewey, Casper, Betelgeuse
Grandchild   A Casper, Betelgeuse
Parent Group Everyone


Build Forge Access Groups: Permission Inheritance

Access Groups Permissions
Parent Group Run Projects
Child Group A Run Projects, Create Projects, Edit Projects
Child Group B Run Projects. Create Servers, Create Selectors, Create Server Auths
Grandchild A Run Projects. Create Projects, Edit Projects, Create Servers, Create Selectors, Create Server Auths, Delete Projects

Bringing it Together: A Practical Example:

Consider the following diagram,and examples. The following naming conventions are used for clarity.

Build Forge access groups that control projects are prefixed with Access_. Those that control permissions are prefixed with Prmsn_. A third type, not previously discussed and prefixed with Notify_ are associated with neither objects nor permissions, but are intended to be used for Build Forge’s built-in notifications. For example, a manager with no Build Forge rights may need to be notified of a completed project. Or another group which does not have rights to this set of projects may need notification of successful completion before kicking off their own, unrelated process.

Build Forge Access Groups -- Diagram

Access Groups
Access_Any_Public Ann. Arnie View any Build Forge artifacts owned by group
Access_WAS_Public Bill, Barney View artifacts owned by the group. Additionally, a member of this group will be able to see projects owned by the parent group, Access_Any_Public.
Access_WPS_Public Carol View Artifacts owned by group. additionally, a member of this group inherits visibility of projects in its parent group, Access_Any_Public.
Access_BF_Admins Denise, Darlene, Erin View Artifacts owned by this group, as well as those owned by it’s two parent groups (Access_WAS_Public and Access_WPS_Public), as well as the mutual grandparent, Access_Any_Public.
Prmsn_Admins Ann, Bill, Denise, Ed, Read, Create, Edit, Alter, Schedule, Delete, or Run projects
Prmsn_Run_Projects Arnie,Carol, and Darlene Run projects
Prmsn_Schedule_Projects  Barney Schedule projects, additionally, a member of this group inherits the permissions of the parent group, Prmsn_Run_Projects.
 Notify_Admins Denise, Darlene, Erin Can’t see or do anything via membership in this group, but group can be used for pass/fail notifications
 Notify_All Denise, Darlene, Erin, Arnie, Carol, Barney,Ann, Bill, Ed, Can’t see or do anything via membership in this group, but group can be used for pass/fail notifications

Ann can read, create, edit, alter, delete or run projects by virtue of her membership in the Prmsn_Admins group. However, she can do this ONLY for projects owned by the Access_Any_Public group. She will not be able to see, or act on projects belonging to any of it’s subgroups.

Bill can read, create, edit, alter, delete or run projects by virtue of his membership in the Prmsn_Admins group. He can do this on any project in the Access_WAS_Public group, as well as any projects in the Access_Any_Public group, since he is a member of that group via inheritance.

Ed has the same permissions as Ann and Bill, however, he can see nothing, and therefore do nothing, since he is not a member of any visibility group.

Denise can read, create, edit, alter delete and run any project in any group. Her membership in the Prmsn_BF_Admins gives her all rights, and her membership in Access_BF_Admins gives her inherited rights to all Build Forge access groups.

Arnie, Barney, Carol, and Darlene all have permission to run projects, but the projects they can run differ.

  • Arnie can only run projects that are in the Access_Any_Public group.
  • Darlene can run any project, since she is a member of the Access_BF_Admins group, which inherits from all other access groups, as well as a member of the Prmsn_Admins group.
  • Barney can run projects in the Access_Was_Public or Access_Any_Public access groups. He can run the projects, even though he is not a member of the Prmsn_Run_Projects group, by virtue of the rights he inherits through his membership in the Prmsn_Schedule_Projects group. He also can schedule any of these projects.
  • Carol, can run projects in the Access_WPS_Public or Access_Any_Public access groups.

Erin can see everything, but act on nothing.

Notice that the Prmsn_Admins group is a stand-alone group that does not inherit from any other. The same result could be obtained by creating it as a sub group of Prmsn_Schedule_Projects, and simply adding the other permissions. I chose to have it stand-alone in this example, to illustrate that inheritance is an option in Build Forge, but it is never a requirement. If it makes maintenance easier, by all means use it. If not, the same effect can always be achieved without it.

I also included notification groups in this example. This allows a project to send notifications, independently of it’s ownership. The notification group can be used on the notification chains of the project itself, or any of its steps. Members of the notification access group will receive an email when the relevant condition occurs whether they are assigned any other rights to that job or not.

This example is overly simplified, in that there are well over 100 different permissions that can be granted in BuildForge, and a project requires quite a few associated objects such as environments, servers, selectors, and other artifacts that also must belong to groups. In the case of this model, they would controlled by various Access_  groups. Often, but not always, these would be the same groups that control the project. This allows for more fine-grained control than might, at first, appear feasible.

For an example of how this can work in practice to control permissions in ways that may not seem obvious, at first, see the article “How to Assign Build Forge Permissions by Project


Leave a Reply