In previous blog post, we discussed how to configure Jenkins for first time use. In large organizations, generally there is a separate team to manage and configure Jenkins and there is a separate team to manage and run jobs and do other stuff with it. As such it becomes important that you need to share Jenkins in a secure way with the other users and make sure that it is configured properly. In older versions of Jenkins, users could be authenticated anonymously and were able to do almost anything by default. This is not a default behavior as of now. This blog post is intended to cover how to configure user authentication in Jenkins in variety of ways.

For configuring user authentication, login to Jenkins with first user configured during default configuration. After this, go to Manage Jenkins -> Configure global security. Or you can go to http:///configureSecurity/.

Inside security realm, you would see two options:

1. Delegate to servlet container: Use the servlet container to authenticate users, as per defined by the servlet specification. It is mostly for legacy purposes. Or if you want to implement connections to a specific user realm. More details for same can be found on https://wiki.jenkins-ci.org/display/JENKINS/Delegate+security+to+servlet+container.
2. Jenkins’ own user database: Use Jenkins’s own user list for authentication, instead of delegating that to an external system. In this process, jenkins will create a local database to store usernames and encrypted passwords.

The next option is the checkbox for Allow users to sign up. It can be useful if you want to allow users to sign up for having access by themselves, which seems like a bad idea. Jenkins do allow some kind of captcha verification to be enabled by using JCaptcha Plugin, if you are afraid that way too many people can try to create user accounts for themselves. This should better be left unchecked by default.

If you leave the above box unchecked, you need to create accounts for new users by yourself. This can be done by going to Manage Jenkins -> Manage users or using url http:///securityRealm and then selecting create user:

Once you click the create user, you can fill the required details for new users as below:

Note that you won’t find any LDAP authentication for Jenkins by default. This used to be covered by ‘delegate to servlet container’ in earlier versions of Jenkins. Now you can simple go to Manage Jenkins -> Manage Plugins or http://, click on available tab and then search for ldap plugin:

Select the box in front of the LDAP Plugin and then select install without restart. Note that you should always go through the related plugin documentation to get familiar with the associated bugs and release history. Once you click install, you should be able to see an screen like below:

As you can note that few plugins have dependency on other plugins, which they will automatically download and install, if not installed already. Once Jenkins is restarted, you could see an extra option added for ldap in the security realm section:

In the same way, you can search and check what types of plugins are available for other types of authentication.

Next section is for authorization. You would see 3 options listed here:

1. Anyone can do anything: This is as bad as configuring no authentication at all. Everyone gets full control of Jenkins, including anonymous users who haven’t signed on. Unless you are doing it for learning purposes, there is no reason you should enable it.
2. Legacy mode: Legacy role is the same as Jenkins <1.164. So, if you have the admin role, you'll be granted full control over the system. Otherwise you'll only have the read access.
3. Logged-in users can do anything: In this mode, every logged-in user gets full control of Jenkins. Checking box for Allow anonymous read access, will allow anonymous users to login with read only access.

The most common and recommended way of configuring authorization is to use matrix based authorization which allows to configure detailed level of sub-permissions for different users. For this, install the ‘Matrix authorization strategy Plugin’ for Jenkins. Again, you can simple go to Manage Jenkins -> Manage Plugins or http://, click on available tab and then search for matrix plugin:

Once its done, you can go back to security options and see that two options are now added under authorization:

Let’s select matrix based security permissions. In the table shown, each row represents a user or a group (often called ‘role’, depending on the security realm.) This includes a special user ‘anonymous’, which represents unauthenticated users, as well as ‘authenticated’, which represents all authenticated users (or everyone except anonymous users). Permissions are additive. That is, if an user X is in group A, B, and C, then the permissions that this user actually has are the union of all permissions given to X, A, B, C, and anonymous. We can configure it simply like below:

Once you are done, go ahead and save. The same plugin also adds option for Project-based Matrix Authorization Strategy. This is an kind of extension to matrix based security.  It allows additional ACL matrix to be defined for each project separately (which is done on the job configuration screen).

We’ll explore how to secure Jenkins environment further in upcoming blog posts.