This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
TeamForge Git-Integration 8.2.1 adds more federated RBAC to Gerrit
We are proud to announce and release version 8.2.1 of our Git/Gerrit integration with TeamForge today. This version exposes even more federated RBAC (role base access control) capabilities of TeamForge within Gerrit. What do I mean by federated RBAC? There is just one central place (TeamForge) where you can define permissions for all tools of your software development tool chain. For example, when a new employee joins your company as a developer, you have to create their account in TeamForge and automatically make sure that they can log into all connected tools like Gerrit, SVN, ReviewBoard, Trackers, Wikis, discussion forums, Code Search, Jenkins, and… I think you get the idea.
It does not matter how many Jenkins, Subversion or Git servers you have, all can be accessed with the same credentials, given appropriate role based permissions. Furthermore, you can now assign the new employee to your developer role which governs the level of access to every integrated tool. You can also be very specific and set permissions down to the individual branch/file of a repository, document folder or tracker type, or you can also be more generic (e.g. so that developers have at least read access to all your source code repositories no matter which server they are on–whether Git, Subversion or CVS repositories. You can use those roles within a project, within a set of projects and globally. Role definitions can even be templatized so that you can roll them out whenever your version of a Scrum/Kanban/RUP/Waterfall (you name it) project definition is instantiated.
If a user account gets deleted or disabled in TeamForge, access is immediately revoked acrosss all tools. For example, “jdoe” decides to leave your company without a federated RBAC, you will have to compile a list of systems this user has access and disable him on all of them. Good luck with that, especially if you have hundreds of them and on some his account is called jdoe2 because a different user with that name still works for you.
I hope this clarifies what we mean by federated RBAC. So what specifically got improved in our latest TeamForge-Git-Integration? First of all, we made sure that TeamForge site administrators can now access all Git repositories and change their permissions, no matter whether they have been explicitly granted permissions via a project role. This is in line how Subversion and CVS are integrated as well.
The screenshot above shows the newly introduced TF: Site Admins group and its Gerrit READ and OWN permissions inheriting down to all TeamForge projects. While TeamForge Site Admins can access and modify access permissions for all Git repositories on that server, they do not automatically get any special capabilities like ADMINISTRATE_SERVER. These capabilities are still reserved to the Gerrit Administrators group.
Furthermore, we took the TeamForge project scope feature that was featured in one of my previous blog post to the next level. If you turn on support for project hierarchies with our latest release, you will see that the parent/child relationship between TeamForge projects is now reflected in Gerrit too.
If a TeamForge project has a parent project, this project will be its parent in Gerrit too. As permissions in Gerrit inherit down, you can now define permissions for TeamForge parent projects that will affect the Git repositories of all direct and indirect TeamForge child projects. For example, if you have three departments, A, B and C. Each department has dozens of products and hundreds of repositories. For department A there is a special group of users that can veto any Gerrit change: The NoNos. In department B you have the Super Approvers, a group of users that can approve that can approve every review. Department C has both, NoNos and Super Approvers. With TeamForge’s parent/child project feature, you can create projects A, B and C with all their products being child projects of them. As a consequence, the Gerrit projects representing the products will be child projects of A, B or C too. You can now go ahead and give NoNos veto rights in A and C and Super Approvers approver rights in B and C. Rights will inherit down to the individual repository level as needed. If you move a product to a different department (change its TeamForge parent project), this will be reflected in Gerrit too. If you have multiple Gerrit servers, the project hierarchy will be reflected in all of them. That’s federated RBAC in action!
Detailed release notes for 8.2.1 can be found here. If you are using (or think about using) our cool quality gate wizard for Gerrit and experienced problems with the 4-Eye principle policy, you should update too.
Stay tuned for our next federated RBAC feature, site wide roles for Gerrit!