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 >>
