Hi, Jeroen. Looking into this thread again, I've discovered also this link [1], telling how to integrate Fortress on a Wicket app.
I'm sure Martin will have interest on it :) I agree that it would be quite "heavy" to use a full RBAC authorization system based on LDAP. I'm going to have the opportunity yo integrate the Isis Security addon on a project soon. I'll provide feedback. Regards, Oscar [1] http://iamfortress.org/WicketRbac > El 20/11/2014, a las 16:11, Jeroen van der Wal <jer...@stromboli.it> escribió: > > Martin: > Thanks for the compliments and keep us updated on your progress. > > Oscar: > Dan and I are on Holiday too: speaking at ApacheCon. Fortunately for us > laptops are obliged here :-) > > All good stuff that you mentioned, send more when you have time, a domain > model maybe. As the security module is very fresh with little users It > shouldn't be hard to refactor it to accommodate more scenarios. Apache > Fortress is also acting in this space but I don't want to bring in an > additional component at this stage. But we might want to "borrow" some of > their concepts. > > Cheers, > > Jeroen > > > > On Thu, Nov 20, 2014 at 2:23 PM, GESCONSULTOR <o....@gesconsultor.com> > wrote: > >> Hi all! >> >> I'm following the thread with a lot of interest. >> >> Problem is that this week I'm on holidays without access to the laptop >> (first time ever and it's being great :) >> >> I find some points here, nearly all them mentioned before: >> - The need for a Tenant / Tenancy entity. >> - The need for an interface or abstract base entity that allows to know >> the Tenant associated with an entity. >> - the need for the concept of "ownership", that in our case could be >> associated at least with a role (and perhaps with a specific user? If >> that's the case perhaps a common abstract parent entity for >> User and Role should be needed). >> - and probably the need for Role compositions (parent-child relationships >> or preferably m-n relationships - extended RBAC- for nested roles). >> - A property like "ownerByDefault" or similar that should reference the >> owning Role (or User?) assigned by default to any entity created by this >> user (it could be changed or not afterwards depending on business logic). >> >> Adding something like that to current great implementation should allow >> for easy (and really fine-grained) domain security. >> >> I don't have access to my list of other implementations so it could change >> a bit, but basically that was the basis. >> >> HTH, >> >> Oscar >> >> >> >>> El 20/11/2014, a las 6:22, Jeroen van der Wal <jer...@stromboli.it> >> escribió: >>> >>> Hi Martin B, >>> >>> We added Tenancy to the security module which, in our case, represents a >>> different legal entity and a users are assigned to a tenancy. We've >> looked >>> at RBAC [1] but were very pragmatic while implementing the module ;-) >>> There's certainly room for improvement so if you can share your thoughts, >>> requirements or entity model here we can perhaps align efforts. >>> >>> Oscar Bou, one of our other committers was very keen on this subject too. >>> Oscar: perhaps you want to pitch in too? >>> >>> And yes, please you can always fork it! >>> >>> Cheers, >>> >>> Jeroen >>> >>> [1] http://en.wikipedia.org/wiki/Role-based_access_control >>> >>> >>> >>> >>> >>> On Thu, Nov 20, 2014 at 9:48 AM, Martin Balmaceda < >>> martin.balmac...@gmail.com> wrote: >>> >>>> Im not sure how using a Shiro role would work since they are predefined >> yet >>>> organizations can be added/removed dynamically >>>> >>>> On Thu, Nov 20, 2014 at 10:37 AM, Martin Grigorov <mgrigo...@apache.org >>> >>>> wrote: >>>> >>>>> Hi, >>>>> >>>>> I am not familiar with isis security module but isn't it possible to >> use >>>> a >>>>> (Shiro) Role as an Organization ? >>>>> >>>>> Martin Grigorov >>>>> Wicket Training and Consulting >>>>> https://twitter.com/mtgrigorov >>>>> >>>>>> On Thu, Nov 20, 2014 at 10:31 AM, <johandoornen...@filternet.nl> >> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> - Hi Martin, maybe you can try a solution that I made and that works >>>> for >>>>>> me at the moment; >>>>>> I defined a 'an abstrat secure object' that has the properties you are >>>>>> looking for [1] >>>>>> >>>>>> [1] >>>> >> https://github.com/johandoornenbal/matching/blob/master/dom/src/main/java/info/matchingservice/dom/MatchingSecureMutableObject.java >>>>>> >>>>>> Thanks I agree, option 1 is much better. >>>>>> >>>>>> As for my user case: I have a system that hosts a number or >>>> organizations >>>>>> orthogonally. What I need to do is associate each user to exactly 1 >> org >>>>> so >>>>>> that he/she can only see and modify information belonging to that org. >>>>>> >>>>>> After looking at the problem, I figure that the best way to do it >> would >>>>> be >>>>>> to use the security module and add an Organization property to >>>>>> ApplicationUser. Unfortunately it seems I would have to fork the >> module >>>>> and >>>>>> add my custom Orgnization domain object to it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 19, 2014 at 5:54 PM, Dan Haywood >>>>>> wrote: >>>>>> >>>>>>>> On 19 November 2014 16:41, Jeroen van der Wal wrote: >>>>>>>> >>>>>>>> Just double-checked: the master branch of isis-module-security uses >>>>> the >>>>>>>> latest and greatest version of Isis, 1.8.0-SNAPSHOT >>>>>>>> >>>>>>>> [1] >>>> >> https://github.com/isisaddons/isis-module-security/blob/master/pom.xml#L32-L36 >>>>>>> (though the screenshots in the README are still of 1.7.0) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Wed, Nov 19, 2014 at 4:33 PM, Jeroen van der Wal > >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Martin, >>>>>>>>> >>>>>>>>> I would advice against option 2 because you lose an easy update >>>>> path >>>>>> to >>>>>>>>> newer versions of the security module. >>>>>>> >>>>>>> +1 to that advice. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Tell us more about your use-case so we can see what the options >>>>> are. >>>>>>> >>>>>>> In particular, is the additional information you need to store >>>>> mandatory >>>>>>> with no sensible default (ie would need to prompt for it), or would >>>> the >>>>>>> current signatures of the methods in ApplicationUsers domain service >>>>>>> suffice? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> >>>>>>>>> Jeroen >>>>>>>>> >>>>>>>>> On Wed, Nov 19, 2014 at 2:24 PM, Martin Balmaceda < >>>>>>>>> martin.balmac...@gmail.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> to do is to be. dobedobedo >>>> >>>> >>>> >>>> -- >>>> to do is to be. dobedobedo >>>> >> Óscar Bou Bou Responsable de Producto Auditor Jefe de Certificación ISO 27001 en BSI CISA, CRISC, APMG ISO 20000, ITIL-F 902 900 231 / 620 267 520 http://www.twitter.com/oscarbou <http://www.twitter.com/oscarbou> http://es.linkedin.com/in/oscarbou <http://es.linkedin.com/in/oscarbou> http://www.GesConsultor.com <http://www.gesconsultor.com/> Este mensaje y los ficheros anexos son confidenciales. Los mismos contienen información reservada que no puede ser difundida. Si usted ha recibido este correo por error, tenga la amabilidad de eliminarlo de su sistema y avisar al remitente mediante reenvío a su dirección electrónica; no deberá copiar el mensaje ni divulgar su contenido a ninguna persona. Su dirección de correo electrónico junto a sus datos personales constan en un fichero titularidad de Gesdatos Software, S.L. cuya finalidad es la de mantener el contacto con Ud. Si quiere saber de qué información disponemos de Ud., modificarla, y en su caso, cancelarla, puede hacerlo enviando un escrito al efecto, acompañado de una fotocopia de su D.N.I. a la siguiente dirección: Gesdatos Software, S.L. , Paseo de la Castellana, 153 bajo - 28046 (Madrid), y Avda. Cortes Valencianas num. 50, 1ºC - 46015 (Valencia). Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.
