Acegi
We'll use Acegi for authentication and authorization.
It uses web filters for authentication and url based authorization, AOP for method or instance based authorization.
Supports several ways of authentication wich can be plugged in as needed through configuration.
Definitions
Some concepts are
- Role: A application level permission, eg. ROLE_ADMINISTRATOR
- ACL: pairs with (object class, object instance id, user id, permission - customizable -)
Acegi provides three places where to enforce security
- URLs - urls can be protected by defining the url pattern (Ant or regexp) in the configuration. eg. */secure/* requires ROLE_ADMINISTRATOR
- Method invocation - eg. MyClass.removeUser() requires ROLE_ADMINISTRATOR
- Object Instance - using ACLs, individual instances can have different permissions for each user
Authentication
By default Continuum will authenticate against the DB bundled through JDO as in 1.0.x. It'll get usernames, passwords and user roles from there.
See the Reference documentation for other possible authentication options.
Authorization
Project level
For each project we'll need to keep permissions for each project and user. ACLs can be used to implement this functionality, see Acegi Domain ACLs
Possible permissions
- Show - see the project and project info
- Edit - edit the project info
- Delete - delete the project
- Build - force a build
We have also add/edit/delete operations over
- build definitions
- notifiers
but i think they can be associated to the corresponding project, if you have edit permissions over the project you can do anything with build definitions and notifiers, and if you have show permission over the project you can see also notifiers and build definitions.
User level
Users must be able to edit themselves
I think this can be achieved with the Run As Authentication Replacement
Special users
We'll keep the roles from 1.0.x for the portions that require role authorization
- addProject
- manageConfiguration
- manageSchedule
- manageUsers
We can protect those pages with URL authorization using user roles.

3 Comments
Hide/Show CommentsJul 11, 2006
Joakim Erdfelt
Grrrr. Curses the PEBKAC error.
The proposed Configuration Screen:
--- (snip) ---
Group Name: Sample Group Name
Can View All projects (admin only option)
Can Administer security. (admin only option)
Can Add Projects (to continuum).
Project
View
Edit
Remove
Manual Build
maven-project-info-reports-plugin
maven-repository-manager
maven-shared-io
--- (snip) ---
Using this as an example of what the user sees, the underlying implementation would see the following roles.
--- (snip) ---
Group Name: Sample Group Name
[ROLE_VIEW_ALL] Can View All projects (admin only option [ROLE_ADMIN] )
[ROLE_ADMIN_SECURITY] Can Administer security. (admin only option [ROLE_ADMIN] )
[ROLE_ADMIN_ADD] Can Add Projects (to continuum).
Project
View
Edit
Remove
Manual Build
maven-project-info-reports-plugin
maven-repository-manager
maven-shared-io
--- (snip) ---
The way I see it, the roles should be sufficient to provide the security desired. (I could be missing something)
Jul 18, 2006
Brett Porter
It seems like everything we have to this point can be covered by action-based restrictions. I'm not sure we need to be using the domain object ACLs if I understand correctly.
Can we separate the Acegi implementation details from the role design that Joakim has added?
Jul 18, 2006
Brett Porter
In response to Joakim's comment: I'm not sure its feasible to implement in the way you've proposed (there are typically hundreds of projects). It may be better to do something similar to:
1) groups (ROLE_GROUP_/groupName/)
2) schemes (a named map of 1..N groups having 1..N permissions, eg "Project Build Monkey" can hit the build button and view)
3) application of schemes to projects (MPIR) or project groups (MRM)
Other than this, it all looks good.