John is an experienced consultant specialising in Enterprise Java, Web Development, and Open Source technologies, currently based in Sydney, Australia. Well known in the Java community for his many published articles, and as author of Java Power Tools and Jenkins: The Definitive Guide, and founder of the open source Thucydides Automated Acceptance Test Library project, John helps organisations to optimize their Java development processes and infrastructures and provides training and mentoring in agile development, automated testing practices, continuous integration and delivery, and open source technologies in general. John is the CEO of Wakaleo Consulting, and runs several Training Courses on open source Java development tools and best practices. John is a DZone MVB and is not an employee of DZone and has posted 117 posts at DZone. You can read more from them at their website. View Full User Profile

Hudson Project-Based Matrix Security is Out!

09.04.2008
| 5865 views |
  • submit to reddit

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).

http://java.dzone.com/sites/all/files/fig-1_4.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.

http://java.dzone.com/sites/all/files/fig-2_3.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.

http://java.dzone.com/sites/all/files/fig-3_0.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!

From http://weblogs.java.net/blog/johnsmart/

AttachmentSize
fig-1.png31.95 KB
fig-2.png49.91 KB
fig-3.png38.45 KB
Published at DZone with permission of John Ferguson Smart, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Gian Franco Casula replied on Fri, 2008/09/05 - 5:14am

Hi John,

Thanks for the update!

Gian

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.