About User - Role - Action security implementation from DB

Hi all

I have a project with a security idea like that (all from database that can be modified at runtime)

User -> List of roles

Role -> List of actions (Each action have a url)

Then each Role contain a list of Actions that have permited to launch, a User that have that Role associated can launch that url.

In acegi we have a bean "filterInvocationInterceptor" that contain a property named "objectDefinitionSource" that with regular expressions we can define the url patterns that certain Role can access, there is a way to make that property to load the struture defined in the Relation between Role -> Action?. I´m reading the documentation in the new version 0.70 and read about a RoleVoter and AclManager but for method invocation.

Any idea or example will be preciated. Before I post i see another post where Ben talk about the posibility to implement the ObjectDefinitionSource interface to acomplish that, i going to work in that now, but would be useful if anyone post some example or hint.

Regards Rodney

FilterInvocationDefinitionSource is the web-specific marker interface for ObjectDefinitionSource. Its main function is to return a ConfigAttributeDefiniton (a holder of ConfigAttributes) relevant for a given web URI. The ConfigAttributes are recognised by your voters in access grant or deny decisions. So, Acegi Security works at the URI level.

Your proposal on the other is to work at the Action level. Acegi Security doesn't have an Action interceptor, but as it's web-related, the URI model above is just a simple abstraction that should prove sufficient.

To bridge the gap between the URI pattern and Action name, you need to write a custom FilterInvocationDefinitionSource and inject it via the IoC container. Ideally the custom implementation would be able to access some registry class that translates a given URI mapping to the relevant Action name. Your implementation would then probably return the roles (in the form of ConfigAttributes) that apply to that Action/URI mapping.

Hope this makes sense. :-)

Ben, I also have dudes about tha idea but maybe makes sense i the context of define new roles at runtime from existing actions, here i put the code that i wrote yesterday implementing the FilterInvocationDefinitionSource interface, it works but i have to tested and acomodate to the project is just a test to take an idea about what can be do with acegi

Any opinion will be preciated
Regards Rodney

package com.rdk.security.intercept.web;

import net.sf.acegisecurity.intercept.web.FilterInvocatio nDefinitionSource;
import net.sf.acegisecurity.intercept.web.AbstractFilterI nvocationDefinitionSource;
import net.sf.acegisecurity.ConfigAttributeDefinition;
import net.sf.acegisecurity.SecurityConfig;

import java.util.Iterator;

import com.rdk.security.persistence.ActionDao;
import com.rdk.security.domain.Action;
import com.rdk.security.domain.RoleAction;
import com.rdk.core.NullParameterException;
import org.springframework.dao.IncorrectResultSizeDataAcc essException;

/**
* Clase encargada de implementar la propiedad ObjectDefinitionSource para la clase de acegi
* FilterSecurityInterceptor esta implementacion le entrega el objeto ConfigAttributeDefinition
* con los roles permitidos a acceder a la url pasada como parametro.
* User: Rodney Gallart (rodney@radikalsystems.com)
* Date: Jan 25, 2005
* Time: 4:20:04 PM
*/
public class DaoBasedFilterInvocationDefinitionSource
extends AbstractFilterInvocationDefinitionSource
implements FilterInvocationDefinitionSource {

private ActionDao actionDao;
/**
* Implementacion dao de los objetos de tipo Action
* @param actionDao
*/
public void setActionDao(ActionDao actionDao) {
this.actionDao = actionDao;
}

/**
* A este metodo se le pasa como parametro la url que se quiere acceder y devuelve el objeto
* ConfigAttributeDefinition donde vienen los roles que pueden acceder a esa url
*
* ConfigifAttributeDefinition contiene una lista de objetos que implementan la interfaz ConfigAttribute
* puede ser SecurityConfig (Roles como String)
*
* Ahora con la url pasada como parametro debe hacerse una busqueda en una lista de acciones cuando se encuentre
* la accion a la cual pertenece la url entonces se devuelve la lista de Roles
* TODO Analizar la posibilidad de implementar un mecanismo de cache Mapa(url, Action) y bajo que condiciones vaciarlo
* @param url Pasada como paremetro para buscar sus roles permitidos
* @return ConfigAttributeDefinition
*/
public ConfigAttributeDefinition lookupAttributes(String url) {
if (url == null)
throw new NullParameterException("Parametro url null");
try {
url = url.toLowerCase();
url = url.substring(1);
if (url.contains("&"))
url = url.substring(0, url.indexOf("&"));
Action act = actionDao.findByUrl(url);
return obtainRolesInConfigAttributeDefinitionObject(act);
}
catch (IncorrectResultSizeDataAccessException ex) {
return null;
}
}

/**
* En este metodo se van a obtener los roles asociados a la accion y se va a crear el
* objeto de tipo ConfigAttributeDefinition con la lista de objetos SecurityConfig
* @param act
* @return
*/
private ConfigAttributeDefinition obtainRolesInConfigAttributeDefinitionObject(Actio n act) {
ConfigAttributeDefinition cad = new ConfigAttributeDefinition();
Iterator it = act.getRoles().iterator();
while(it.hasNext()) {
RoleAction ra = (RoleAction) it.next();
SecurityConfig sc = new SecurityConfig(ra.getRole().getName());
cad.addConfigAttribute(sc);
}
return cad;
}

public Iterator getConfigAttributeDefinitions() {
return null;
}

}

Looks OK to me, but I'd just be sure to comprehensively unit test the handling of both valid and invalid URL specifications. eg change the & to & etc.