Jenkins Authentication & Authorization Strategy
Jenkins Authentication & Authorization Strategy - Using Active Directory & Role Based Strategy plugins
The following document describes the methodology of using ActiveDirector/LDAP Groups and Role Based Strategy plugins to Authenticate and Authorize Jenkins users in A give domain.
The Active Directory plugin is used to configure the AD/LDAP authentication method and in our case we will be using the Active Directory Authentication method (https://
Figure #1: LDAP configuration section in Global Security
As emphasized above we have the Active Directory domain + a read only username/password which is used as a read only user in LDAP which is used just to validate the user logging in via the plugin is indeed a valid AD/LDAP account. Every user under his username page for example see Figure #2, has the Group list which is fetched from Active Directory / LDAP service and hence can be used in the Authorization strategy as emphasized below.
Figure #2: User page in Jenkins + Active Directory Groups
Authorization is achieved considering every user connecting via AD also populates a list of AD groups it is associated with this feature enables us to create a Match between the LDAP group and the Role we create under the Manage Roles section under Jenkins configuration page -> https://
Figure #3 - Role Strategy Management
In this section of the configuration there are a number of tasks to perform: Create Global authorization roles - the 2 roles which are the best example are the ReadOnly and Admin roles which determine who has Overall Administrative permissions and who has View Only permissions like seen in Figure #4:
Figure #4 - Global Roles
These roles will be assigned to Admins or all other users in the Active Directory domain which apply to the non-authenticated / Anonymous role. Global roles can be defined under the following url -> https://
Create Project specific Roles with the same motivation as above specifying who has build capabilities (similar to Admin but for a specific set of builds) and who has read/trigger permissions (an elevated rank above the ReadOnly group affiliation). As an example for the ARM project we have the following 2 roles [ Figure #5 ]
Figure #5 - Project specific roles
Project roles apply to all job which apply to the regular expression specified in our example “(arm.*)”.
Please note this will probably make more sense in conjunction with the “Restrict project naming” convention strategy which can be configured in Jenkins’s Global configuration (https://
Figure #6 - Project naming convention
The above configuration allows users with the regex (arm.*) to create jobs with that naming convention whilst enabling global roles to create any job name they please.
Affiliate Global Roles with Active Directory Groups as displayed above in the user page [Figure #1] can be done from the Assign roles page (https://
Figure #7 - Assign Global roles per user / group
In this screenshot we can see that CI_admin AD group memebers will have full administrative permissions in Jenkins in addition to all the users above.
Affiliate Project Roles with Active Directory Groups as displayed above in the user page [Figure #1] we can identify that there are unique / specific LDAP groups which were designed to segment the access / features enabled for project Admins and project Users as displayed in Figure #6 below:
Figure #8 - Assign Project specific roles
Same as with global roles but specifically to the ARM_ADMINS & ARM_DEVELOPER AS groups.
The role strategy plugin + Active Directory plugins enables us to achieve a granular enough authorization scheme in Jenkins which enables us to better manage access & security.