Skip to main content

Hudson project-based matrix security is out!

Posted by johnsmart on September 2, 2008 at 2:13 PM PDT

One feature that I've been waiting for a long time to see in Hudson is project-level security. To be able to say that certain projects can only be built by certain users. This comes in very handy if certain builds jobs should only be executed by certain people, for security or auditing purposes, for example. A release into QA (or even production) might come under this category.

TeamCity has this feature. Contiuum has some pretty refined user management as well. But, up until recently, Hudson only had project-level user rights. Now, however, you can setup project-specific rights in Hudson as well. And I have to say, this is one of the more exiting Hudson features to have come out in a while (and that's saying something!).

You can check this new feature out in the latest Hudson build. Let's take a quick tour of this new feature.

First, you need to activate security. You do this in the Configure System screen (in the "Manage Hudson" section). For more advanced setups, you can hook into an LDAP server or use the underlying servlet container's security, but to start off, it's easier to use Hudson's own user database.

One tip that you should remember: make sure you tick the "Anyone can do anything" checkbox before you proceed, as otherwise you might end up locking yourself out! (If you do lock yourself out, just edit the config.xml file in your .hudson directory and change the "useSecurity" entry to false).

Once you're done, save this screen. You will see a "sign up" link in the top right-hand corner of the screen. This goes to a screen where users can sign up. Use this screen to add a few users, starting with "admin" (it is always a good idea to create an "admin" user first).






hudson-enable-security.png

Now go back to the Configure System screen and pick "Project-based Matrix Authorization Strategy". At first glance, this bares a striking resemblance to the standard "Matrix-based security". Do not be troubled! This section lets you define application-wide rights, such as for adminitrations and anonymous users. You can add users to the matrix by typing a user name in the "User/group to add". Here, don't forget to add a row for the administrator with everything ticked. Also, if you want a user to be able to build a project anywhere, give them build authorisations here. In fact, the same applies for all of the job-level authorisations.

hudson-project-security.png

For more sophisticated environments, the same approach works fine with LDAP integration as well.

Now the fun starts. Go to one of your projects, and click on "Enable project-based security". Now you can assign project-level authorisations for this project to your users. In the screenshot below, Jane can do anything on this project, whereas Bob can only build.

hudson-project-security-details.png

One thing that is important to remember is that project-level rights overrule application-level rights. If bob has application-wide build authorisation, but does not have project-level build authorisation for a particular project, then he won't be able to build that project. Hudson also seems to get confused if you assign . So, in a nutshell, give your users full rights at an application level by default, then limit their access to particular projects in the project-level build configuration.

This feature is still fairly new, and there are still a few bugs to be ironed out. For example, I've come across the odd bug in the last few releases during the sign-on process - you occasionally get an error when you try to log on with a new user. For testing purposes, just go back to the previous page - in this case, you are in fact logged on. I'm sure Kosuke will sort that one out soon ;-). Still, nice work Kosuke!

"Best development course I have been on in a very long time...Greatly enjoyed the course...A 'must' course for serious Java developers..." - Read what people are saying about the Java Power Tools Bootcamps.

Comments

more restrictive application level rights

It seems to me that the reverse is true for this statement - "One thing that is important to remember is that project-level rights overrule application-level rights. If bob has application-wide build authorisation, but does not have project-level build authorisation for a particular project, then he won't be able to build that project. ". In my tests, I found that if I gave 'all' rights to a user in the application-level rights, and then restricted it for a project to only 'read' for that project, it didn't work. The user was still able to do everything that was permitted at the application-level. The other way round works. Be more restrictive at the application-level. Open up specific project rights if the user needs it. Btw, this is with ver 1.316.

Correct

Yes, this seems to be the case now - application-wide authorisations override project-level authorisations. This blog entry was written when the feature first came out, so I assume that was changed since then (as it was fairly counter-intuitive). Thanks for pointing this out!