Acegi- Basic Question

[john017]

Hello Acegi Developers,
I have been looking at Acegi for integrating into my application and I have the following questions (Non acegi-specific but user security oriented) and am unsure how to implement them using acegi:
1. A user is associated with a set of authorities as I understand it which are populated in the Authentication object? But, at one time, the user is only on one role, for example, with a userid john017, i could be logged on as Admin authority at one time and Devloper authority at another time.
Since the AuthenticationProvider goes through the entire list of authorities and though john017 is in Developer role, he still has access as Admin?. Do I need to write my own AuthenticationProvider or does such a provider already exist or am I fundamentally wrong.
2. Since every method specifies the role for which it has access, how can this work in a deployed environment with Role definitions changing. For example, I could define the roles as ROLE_USER,ROLE_ADMIN but a specific role called ROLE_POWER_USERS can be later added after the application has been deployed.
Regards,
John Alvez

[Ben Alex]

Typically a principal is identified by a username, and the principal has a set of reasonably static GrantedAuthortiy[]s. By reasonably static I mean they can be added and removed from a database, for example, but the authentication process does not selectively disregard certain authorities. If say principal "joedoe" needed to "act" in different roles, it would probably be better to model this at a username level. So, "joedoe-administrator" and "joedoe-developer", with each having separate GrantedAuthority[]s. You could write a custom AbstractProcessingFilter which looked at some "act as" HTTP property and appended to the login name appropriately. However, I would consider whether this "act as" functionality is an actual requirement, and why "joedoe" can't simply have both ROLE_DEVELOPER and ROLE_ADMIN given the same person can act in both roles. By using a custom AbstractProcessingFilter you avoid changing other areas of Acegi Security. Having said that, you could write a new AuthenticationProvider as well if you needed a more comprehensive solution.

If using an AbstractSecurityInterceptor, such as MethodSecurityInterceptor, you will need to define the configuration attributes for each secure object invocation. This is actually defined in an ObjectDefinitionSource, with a PropertyEditor translating the IoC XML defined Strings into the applicable concrete ObjectDefinitionSource. As such, if you wanted to add a new role after Acegi Security deployment, you would need to provide a custom ObjectDefinitionSource that derived the said configuration attributes from some sort of dynamic source, such as a database. This is assuming, of course, that the deployer could not just edit the XML and redeploy.

We have considered adding a database-driven ObjectDefinitionSource although have not done so as yet.

[jasonab]

We have considered adding a database-driven ObjectDefinitionSource although have not done so as yet.

Alex, has there been any more thought on this? I'd love to be able to define roles and "resources" (methods and tags) dynamically.

[Ben Alex]

As Spring's roadmap includes database-sourced bean configuration, I have held-off for now. There are higher prioriety features like JDK 1.5 annotation support etc. We really need to get JIRA. If you needed to get DB-sourced ObjectDefinitionSource support, there's some other posts which discuss it and give a pretty good feel for the design. IIRC someone even wrote a suitable class and didn't find it too difficult. Generally 80% of the time people can use ACL capabilities where they would otherwise have sought DB-based ObjectDefinitionSources.