There is no example application (that i know of) showing what you want.
Let me recap what i think you want:
You have an application (probably with a basic set of roles)
You want to add plugins (probably containing several pages each
requiring there own special permissions to do stuff)
The extra permissions for the plugin need to be picked up dynamically
from the plugin itself.
This is certainly more complex than what we typically use in our
applications but i think i have an idea of how i would approach this:
My choice would be to use swarm as it is designed to be flexible.
First off i assume you have some kind off registry for you plugins so
that your applications knows what is available. and that they have
some kind of life cycle (init, destroy).
It should not matter much if new plugins are installed while the
application is running or not.
Normally i would store my principals in the database and the
permissions for each principal are stored in the ACL file. This has
the advantage that i can use the principals to build dynamic roles
(also stored in the database) and easily maintain a hierarchy between
my principals ( meaning if i grant principal A i automatically get
principal B).
It isn't that difficult to replace the acl file with an acl database
but it means your plugin is then depending on something external
instead of everything being contained in the plugin jar.
If you don't care about external dependencies you can go ahead and do
this, if however you want the plugin to be self contained and don't
want anything remaining after you have removed the plugin you could
try the following:
Since principals are uniquely identified by there class and name you
can use just those as reference in your roles instead of foraign keys.
The roles can be stored in the database without problems.
I have mentioned permissions, principals and roles lets see how that
picture fits together:
Users are granted roles, a role is nothing more then a set of
principals. Principals are dictated by the system, roles can be
created dynamically by users (application manager usually) and new
roles will need to be created and assigned to users after a plugin has
become available. You could have the plugin create a set of default
roles but they still need to be assigned to users.
A principal is a set of permissions, permissions are hardcoded in your
acl. the same permission might apply to several principals.
So what happens if the system detects a new plugin:
The plugin exposes the location of the extra acl, the system then
reloads the acl, adding the extra location. the appropriate life cycle
events of the plugin are triggered allowing it if necessary to create
the required entries in the database.
The system then continues its normal operation.
To summarize, this is what i would do in a situation like this:
-Each plugin has there own acl file containing the standard swarm
permissions (ComponentPermission and optionally DataPermission) and
maybe some of your own permissions.
-The plugin either defines there own Principal class or uses the one
from the application.
-Principals are only referenced by class and name, not stored in a database.
-The application defines a set of default Roles.
-Roles are stored in a database and contain a set of Principals.
-Roles can be dynamically created by selecting one or more of the
available Principals.
-When installing a new plugin the Hive (swarm acl) needs to be
reloaded so the acl file from the plugin can be added.
Let me know if this comes close to what you wanted and if it helps you or not.
Maurice
On Jan 27, 2008 2:34 AM, Ned Collyer [EMAIL PROTECTED] wrote:
With wicket security (either wasp/swarm, or wicket-auth-roles) can things
like Roles and Permissions be created through a web interface?
Eg,
I need a system whereby I can add new roles (or principals) through the web
interface, and define their permission to a ACLs which are determined by
which which plugins the system is configured to use.
Each plugin will implement some interface, and expose the ACLs that it has
available. - these will not be manually configured, and should not require
any java code change when I add a plugin to the system.
I'm having trouble mapping this to either swarm or wicket-auth-roles. (and
trouble explaining it well ;))
I believe wicket-auth-roles is more component oriented, but reading about
this stuff makes my head swim.
Can anyone either steer me in the right direction, or point at an example
that gets these ACLs and roles from a datastore at run time.
--
View this message in context:
http://www.nabble.com/Wicket-Security---runtime-ACLs-and-Groups-help-plz-tp15115011p15115011.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
