Two days ago, I was thinking to take on the approach number 1. But I have to make it easier to develop, perhaps by Automating the role creation by XDoclets, I don't know yet. Then the roles associated with each method are seen as permissions by the application, I think that way things will be a lot easier.
I guess I'm gonna take a shot at it. PD: the fact is I don't have the time either to contribute as I'm very busy right now with my own project, perhaps another time. Thanks for everything On Mon, 2006-12-04 at 14:31 -0800, David Jencks wrote: > On Dec 2, 2006, at 7:27 PM, Diego L Espiñeira wrote: > > > Hi, thanks for your reply > > The roles associated with each EJB method are defined at deployment > > time > > (via deployment plan), but I need to let the users, such as a sysadmin > > (with not much experience on J2EE), to grant access for some EJB > > methods > > to existent roles and to create new roles too using the web user > > interface of my application. Do I need to modify the deployment > > plan to > > grant to a new role permissions for execution of an EJB method? Is > > this > > feasible/reliable/good practice? Do I have to start looking at JACC? > > If that is the case, I didn't find much information about JACC. Can > > you > > give me some tips? or just to point me in the right direction for that > > info? > > I wrote up some stuff on JACC at http://cwiki.apache.org/confluence/ > display/GMOxDEV/JACC+Guide, maybe I'll figure out how to link to it > from an existing page :-) > > There are a lot of ways to deal with this, and I have no idea which > if any would be suitable. I really don't understand from the specs > what is intended as far as changing roles and their definitions while > the app is deployed. Everything in the specs except some of the > PolicyConfiguration interfaces seem to state unequivocally that you > have to change the deployment descriptors to change the role - > permission mapping, but the JACC spec and interfaces seem to allow > and encourage changing them from some unspecified admin interface. > Anyway geronimo doesn't have an admin interface for this right now. > > It may not be entirely clear but the default geronimo jacc > implementation kind of has 3 layers for getting from the user's > identity to the permissions they get: > > - the login configuration for the app constructs a Subject containing > Principals. You can adjust the login module's backing store at any > time to change what principals go with each user. There's no > geronimo administration at all for this AFAIK (there might be a way > to modify a properties realm, but I doubt a serious app is going to > be using a properties realm) > > - the principal-role mapping specified in some xml following geronimo- > security-1.2.xsd, somewhere in your plan. At the moment the only way > to modify this is to change the plan and redeploy. It would be > possible to write an admin interface such as a console portlet for > this. I expect this would be generally useful. > > - the role-permission mapping specified in the spec deployment > descriptors. Again, the only way to change this currently is to > change the dds and redeploy, but a generic interface to modify this > mapping is certainly possible. > > With both of these last two mappings, one major problem is that > when you restart the app, you lose the changes. Avoiding this would > take a lot of work. > > Here are a few ideas for how to solve this problem: > > 1. Start out with enough roles, such as one per ejb method, and one > principal per role, with an obvious principal role mapping. Then you > can completely control a user's permissions in the login > configuration. For instance if it's in a sql table, you can just > edit the table's entries. This is really simple and doesn't require > anyone to write more code, but is apt IMO to be difficult to manage. > > 2. Help get TripleSec integrated. This should provide a GUI > (currently swing based IIUC) to do exactly what you want. However, I > think this is going to be a long term project. The apache ds guys > haven't even imported the triplesec code into apache yet :-( > > 3. write one or both of the runtime management features mentioned > above, either the principal-role editor or the role-permissions > editor. I don't know how hard the editors would be, but I certainly > don't have a solution for the persistence problem at this time. > > Hmmm, I might have just expanded on my previous response..... anyway > these might give you some more ideas. > > thanks > david jencks > > > > > > Thank you very much > > > > > > On Sat, 2006-12-02 at 17:11 -0800, David Jencks wrote: > >> We don't have a way to do this at the moment. Can you be more > >> specific about what you need to do? Would it be sufficient to change > >> the principals that the login module adds to the user's Subject, > >> while keeping the principle-role mapping and role-permission mappings > >> the same? That would just involve writing an interface into whatever > >> is backing your LoginModules. > >> > >> Something that might be similar to what you need that I'm hoping to > >> get integrated into geronimo fairly soon is TripleSec, which is > >> supposed to move into the Apache Directory project any day now :-). > >> > >> thanks > >> david jencks > >> > >> On Dec 2, 2006, at 4:47 PM, Diego L Espiñeira wrote: > >> > >>> How can I modify EJB security settings from an enterprise > >>> application?. > >>> I need to allow the user to assign permissions to users from the > >>> commodity of my web app's user interface ;) > >>> > >>> __________________________________________________ > >>> Correo Yahoo! > >>> Espacio para todos tus mensajes, antivirus y antispam ¡gratis! > >>> ¡Abrà tu cuenta ya! - http://correo.yahoo.com.ar > >> > > > > __________________________________________________ > > Correo Yahoo! > > Espacio para todos tus mensajes, antivirus y antispam ¡gratis! > > ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam �gratis! �Abr� tu cuenta ya! - http://correo.yahoo.com.ar
