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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]