Hudson Security Plugin

[John Smart-2]

On Kohsuke's request, I am reposting this message to the development list:

John Smart wrote:
> Hi Kohsuke,
>
> First of all, congratulations on your work on Hudson - it is a fine
> product. You might be interested to know that I've included a (fairly
> large) chapter about Hudson in the upcoming Java Power Tools book (see
> also http://www.javapowertools.com) on Hudson. Java Power Tools is due
> out in March next year.

That's a great news. I'd be looking forward to see the book in nearest
Burns&Nobles.

> Working for one of my clients, I'm looking into writing a Hudson plugin
> to allow role-based security management in Hudson. My basic requirement
> is that, on a given Hudson installation, you can define roles for
> projects or groups of projects, and only users with the appropriate
> roles can manage builds for these projects. Continuum 1.1 now has a
> feature somewhat like this. My idea for an initial implementation was to
> add a field in the project configuration screen where you can specify a
> required role for your project, and use basic Tomcat authentication (eg
> tomcat-users.xml) to configure user roles.

This is actually very timely, as I have started integrating Acegi into
Hudson since the last week or so.

Since I haven't done any real security related work in the past, I'd
love to get some feedback about the design while we can still change
this, and getting help from people like you on this would be excellent.

Could you repost this in the [hidden email]? I'd like to have
this kind of discussion in public so that other people benefit.

 

---

John Smart | Wakaleo Consulting Ltd  | [phone]
Optimizing your software development process

---

---

Make the switch to the world's best email. Get the new Yahoo!7 Mail now.

[Kohsuke Kawaguchi]

John Smart wrote:

>> Working for one of my clients, I'm looking into writing a Hudson
>  plugin
>> to allow role-based security management in Hudson. My basic
>  requirement
>> is that, on a given Hudson installation, you can define roles for
>> projects or groups of projects, and only users with the appropriate
>> roles can manage builds for these projects. Continuum 1.1 now has a
>> feature somewhat like this. My idea for an initial implementation was
>  to
>> add a field in the project configuration screen where you can specify
>  a
>> required role for your project, and use basic Tomcat authentication
>  (eg
>> tomcat-users.xml) to configure user roles.
>
> This is actually very timely, as I have started integrating Acegi into
> Hudson since the last week or so.
>
> Since I haven't done any real security related work in the past, I'd
> love to get some feedback about the design while we can still change
> this, and getting help from people like you on this would be excellent.

Yes, thank you. So here's the progress report on the new security
implementation so far.

Previously this whole thing used to be a boolean switch. If the security
is off, everyone gets to do anything. If it's on, you are either admin
or not, and if you are admin you get to do anything, but if you are not,
you can only browse. The authentication was done by the container.

Starting 1.160 or so, I slowly started implementing the security
support. This is not yet exposed, but if you check out the workspace you
should be able to see the code in the hudson.security package.


The new work borrows some code from Acegi. I've been long thinking about
whether this is worth it (especially given that it brings in Spring ---
unnecessarily in our case), but in the end I liked the fact that I don't
have to rewrite everything, even if it means adding more dependencies
than necessary (and unlike remoting code, I found security to be
somewhat boring!)

The new infrastructure introduces three extension points.


The first is SecurityRealm that performs authentication. This
pluggability allows people to connect to different user database source,
from the container authentication to LDAP to OpenSSO. I'm hoping that
most such concrete implementations that deal with the protocol part is
available on Acegi, but SecurityRealm class builds on top of that and
provides necessary hook for Hudson to provide GUI.

The second is AuthorizationStrategy. This controls how authorization is
done, and so that we can have "no authorization" strategy (where
everyone has full access like today), to role-based model, or very
fine-grained object-level ACL where you can say Alice has access to
project X but not Y. Again, this extension point should control the
relevant UI.

The third is a Permission object. We define several of them, and before
activities happen, the code will check if the current user (determined
by SecurityRealm) is authorized to do it (determined by
AuthorizationStrategy.)



In the trunk, the new code is already used to emulate the old security
behavior.

I have to run now, so I'll write a follow-up e-mail and describe the
area where I could use your help. Feedback appreciated.

--
Kohsuke Kawaguchi
Sun Microsystems                   [hidden email]