Skip to end of metadata
Go to start of metadata

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.

Reference documentation

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.

Labels
  • None
  1. Jul 11, 2006

    Grrrr.  Curses the PEBKAC error.

    The proposed Configuration Screen:

    --- (snip) --- 

    Group Name: Sample Group Name
    (minus) Can View All projects (admin only option)
    (plus) Can Administer security. (admin only option)
    (plus) Can Add Projects (to continuum).

    Project 

    View

    Edit

    Remove

    Manual Build

    maven-project-info-reports-plugin

    (plus)

    (minus)

    (minus)

    (plus)

    maven-repository-manager

    (minus)

    (minus)

    (minus)

    (minus)

    maven-shared-io

    (plus)

    (plus)

    (plus)

    (plus)

    --- (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
    (minus) [ROLE_VIEW_ALL] Can View All projects (admin only option [ROLE_ADMIN] )
    (plus) [ROLE_ADMIN_SECURITY] Can Administer security. (admin only option [ROLE_ADMIN] )
    (plus) [ROLE_ADMIN_ADD] Can Add Projects (to continuum).

    Project 

    View

    Edit

    Remove

    Manual Build

    maven-project-info-reports-plugin

    (plus) [ROLE_MPIR_VIEW]

    (minus) [ROLE_MPIR_EDIT]

    (minus) [ROLE_MPIR_REMOVE]

    (plus)[ROLE_MPIR_BUILD]

    maven-repository-manager

    (minus) [ROLE_MRM_VIEW]

    (minus) [ROLE_MRM_EDIT]

    (minus) [ROLE_MRM_REMOVE]

    (minus) [ROLE_MRM_BUILD]

    maven-shared-io

    (plus) [ROLE_MSIO_VIEW]

    (plus) [ROLE_MSIO_EDIT]

    (plus) [ROLE_MSIO_REMOVE]

    (plus) [ROLE_MSIO_BUILD]

    --- (snip) ---

    The way I see it, the roles should be sufficient to provide the security desired. (I could be missing something) 

  2. Jul 18, 2006

    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?

  3. Jul 18, 2006

    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.