project-based security, use the system level matrix to define minimum default permissions applicable
across all of your projects, and set up projects with additional project-specific authorizations.
There are many approaches to managing project permissions, and they depend as much on organizational
culture as on technical considerations. One common strategy approach is to allow team members to have
full access to their own projects, and read-only access to other projects. The Extended Read Permission
plugin is a useful extension to have for this scenario. This plugin lets you let users from other teams see
a read-only view of your project configuration, without being able to modify anything (see Figure 7.22,
“Setting up Extended Read Permissions”). This is a great way to share build configuration practices and
tips with other teams without letting them tamper with your builds.
Figure 7.22. Setting up Extended Read Permissions
It is worth noting that, whenever large and/or multiple teams are involved, the internal Jenkins database
reaches its limits quite quickly, and it is worth considering integrating with a more specialized directory
service such as an LDAP server, Active Directory or Atlassian Crowd, or possibly a more sophisticated
permission system such as role-based security, discussed in the following section.
7.5.3. Role-based Security
Sometimes managing user permissions individually can be cumbersome, and you may not want to
integrate with an LDAP server to set up groups that way. A more recent alternative option is to use
the Role Strategy plugin, which allows you to define global and project-level roles, and assign these
roles to users.
You install the plugin in the usual way, via the Plugin Manager. Once installed, you can activate
this authorization strategy in the main configuration page (see Figure 7.23, “Setting up Role-based
security”).
Figure 7.23. Setting up Role-based security