You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Martin <mw...@gmail.com> on 2016/09/23 06:07:35 UTC
object level ownership / tenancy
Hello,
We want to give ownership of specific objects in the domain model to a
subset of users.
Example: an application to manage concerts, and a subset of the users is
the concert organization committee. The members of
the organization committee can be added and removed at runtime or defined
when creating a new concert object. A user can be assigned to be a member
of multiple committees, and the members of a concerts organization
committee should be granted permissions to manipulate the concert and its
associated objects.
I looked at the isis-security-module (
https://github.com/isisaddons/isis-module-security) and also at the
tenancy, but I had trouble figuring out if this could actually serve our
needs.
How would one go about this with apache isis?
Thanks and regards,
Martin
Re: object level ownership / tenancy
Posted by David Tildesley <da...@yahoo.co.nz.INVALID>.
Hi Dan,
imho I don't think it is that cut and dried (but willing to learn
otherwise). When a system user is also a <<Party>> with <<Role>> to
<<moment-interval>> it is appropriate to ask the domain whether the
system user identified as a <<Party>> in the system is allowed to play
the <<Role>> wrt the <<moment-interval>>.
The domain may have to do some non-trivial checking e.g. the Person must
be in the <<Role>> of ConcertOrganiser wrt Concert (or be a member of an
OrganisingCommittee which has a <<Role>> of ConcertOrganiser wrt to
Concert) AND have a current practicing "concert organiser
certification" AND be a current member of the "concert organisers" trade
union AND be formally delegated the authority by the OrganisingCommittee
in a minuted meeting, before they are allowed to manage the Concert.
Maybe Stephen R. Palmer's article [1] helps to shed some light on this.
But as Stephen mentions, sometimes it is appropriate to "externalize"
the decision partly or fully to a policy engine.
[1] http://www.step-10.com/SoftwareDesign/ModellingInColour/Role.html
Regards,
David.
On 27-Sep-16 9:12 PM, Dan Haywood wrote:
> within
>
>
>
> On 27 September 2016 at 04:25, Martin <mw...@gmail.com> wrote:
>
>> I was wondering whether instead of checking for role name / concert name
>> equality as in the "ApplicationTenancyEvaluatorForConcerts" it would also
>> make sense to associate the ApplicationUser entity with a Concert through
>> some Committee (n:m) and then make the decision based on
>> navigability/reachability?
>
> You could do it that way, but my strong preference is not to; I feel that
> the authorization concerns should be layered on top of the domain model,
> not something that the domain objects such as Concert know anything about.
>
> You can use domain event subscribers on the actions of your domain objects
> to veto or respond to interactions within your domain, see [1]
>
>
>
>> Or is that seen as bad design because entities
>> from external plugins/packages should not be associated to the plain domain
>> entities?
>>
>>
> exactly
>
>
>
>> Another question I need some clarification on: in case the ApplicationUsers
>> that can see the Concert are assigned different roles within the Committee,
>> the decision on whether a user can edit certain properties has be taken in
>> the entity itself (through hideXxxx etc...) or does this require another
>> evaluator?
>>
>>
> No, you should just be able to manage this using the
> roles/permissions/features of the security module [2]. Again, while you
> *could* do this using the hideXxx methods (eg using the UserService to
> obtain the identity of the current user), I don't think you should embed
> this security knowledge in your core domain.
>
> HTH
> Dan
>
>
> PS: could you subscribe to the users mailing list [3] so that I don't have
> to keep moderating your posts? thx.
>
> [1] http://isis.apache.org/guides/rgant.html#_rgant-Action_domainEvent
> [2]
> https://github.com/isisaddons/isis-module-security#add-permission-at-different-scopes
> [3] http://isis.apache.org/support.html#how-to-subscribe
>
>
>
>
>
>> On Mon, Sep 26, 2016 at 11:46 PM, Dan Haywood <
>> dan@haywood-associates.co.uk>
>> wrote:
>>
>>> Hi Bilgin,
>>>
>>> Good catch.
>>>
>>> It's because the HomePageViewModel#getObjects() is calling the
>>> ConcertRepository directly, rather than using the WrapperFactory. If the
>>> domain service is wrapped, then the objects that it returns are in effect
>>> filtered with respect to the current user. You can see this also in the
>>> integration tests 1].
>>>
>>>
>>> I've made the fix [2].
>>>
>>>
>>> Cheers
>>> Dan
>>>
>>> [1]
>>> https://github.com/danhaywood/security-generalized-tenancy-
>>> app/blob/master/integtests/src/test/java/domainapp/
>>> integtests/tests/modules/simple/Concert_IntegTest.java#L78
>>> [2]
>>> https://github.com/danhaywood/security-generalized-tenancy-app/commit/
>>> 64282dc9110b7428835af7a671c962b2be7c9398#diff-
>>> 4ef1fac0cff7edc209b038f93834dde6R41
>>>
>>>
>>> On 26 September 2016 at 17:36, Bilgin Ibryam <bi...@gmail.com> wrote:
>>>
>>>> Hi Dan,
>>>>
>>>> great timing. I was looking at multi tenancy today and wanted to see
>>>> something different than the path concept (which is not very common
>>>> for implementing multi tenancy).
>>>>
>>>> In your demo app, users bill/joe see the correct number of entities
>>>> (2), but the home page shows description "3 objects". I wonder why?
>>>>
>>>>
>>>> Thanks,
>>>> Bilgin
>>>>
>>>> On 26 September 2016 at 15:38, Dan Haywood <
>> dan@haywood-associates.co.uk
>>>> wrote:
>>>>> Hi Martin,
>>>>>
>>>>> Your post has prompted me to push out a new version of security
>> module
>>>> [1],
>>>>> 1.13.3. (We also had a related requirement in Estatio, so a matter
>> of
>>>>> killing two bird with one stone).
>>>>>
>>>>> So, there is now a more general optional SPI service which doesn't
>>> depend
>>>>> on the concept of application tenancy paths, instead it just gives
>> the
>>>>> service the two objects to evaluate and asks it to say if they are
>>>> visible
>>>>> (or hidden) and editable (or disabled):
>>>>>
>>>>>
>>>>> public interface ApplicationTenancyEvaluator {
>>>>> boolean handles(Class<?> cls);
>>>> (1)
>>>>> String hides(Object domainObject, ApplicationUser
>> applicationUser);
>>>> (2)
>>>>> String disables(Object domainObject, ApplicationUser
>>>> applicationUser); (3)
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> To test this, I knocked up a demo app; it's implementation of this
>>>> service
>>>>> is:
>>>>>
>>>>> @DomainService(nature = NatureOfService.DOMAIN)public class
>>>>> ApplicationTenancyEvaluatorForConcerts implements
>>>>> ApplicationTenancyEvaluator {
>>>>> public boolean handles(Class<?> cls) {
>>>>> return Concert.class.isAssignableFrom(cls);
>>>>> }
>>>>> public String hides(Object domainObject, ApplicationUser
>>>> applicationUser) {
>>>>> if (!(domainObject instanceof Concert)) {
>>>>> return null;
>>>>> }
>>>>> final Concert concert = (Concert) domainObject;
>>>>>
>>>>> final Optional<ApplicationRole> roleIfAny =
>>>>> applicationUser.getRoles()
>>>>> .stream()
>>>>> .filter(role ->
>> Objects.equals(role.getName(),
>>>>> concert.getName())) (1)
>>>>> .findAny();
>>>>>
>>>>> return roleIfAny.isPresent()? null: "Requires role " +
>>>>> concert.getName();
>>>>> }
>>>>> public String disables(Object domainObject, ApplicationUser
>>>>> applicationUser) {
>>>>> return null;
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> Hope that makes sense, let us know how you get on.
>>>>>
>>>>> Cheers
>>>>> Dan
>>>>>
>>>>>
>>>>> [1] https://github.com/isisaddons/isis-module-security
>>>>> [2] https://github.com/danhaywood/security-generalized-tenancy-app
>>>>>
>>>>>
>>>>>
>>>>> On 24 September 2016 at 23:53, David Tildesley
>>>> <da...@yahoo.co.nz.invalid>
>>>>> wrote:
>>>>>
>>>>>> Just read my own post. Sorry those chevrons were meant to be double,
>>> and
>>>>>> they are only indicating color modelling "archetypes"[1] - force of
>>>> habit -
>>>>>> helps me conceptualize problem domains.
>>>>>>
>>>>>> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 24-Sep-16 3:59 PM, David Tildesley wrote:
>>>>>>
>>>>>>> Hi Martin,
>>>>>>>
>>>>>>> You haven't described a tenancy problem so I wouldn't necessarily
>>> try
>>>>>>> and bend that to your problem. I would model it in the domain and
>> use
>>>>>>> domain behavior. The behaviour checks if the user is a member of a
>>>>>>> committee (<ppt>Committee) in the role of managing
>>>> (<role>ConcertManager)
>>>>>>> the concert (<moment-interval>Concert) before allowing operations
>> on
>>>> the
>>>>>>> concert component.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> David.
>>>>>>>
>>>>>>>
>>>>>>> On 23-Sep-16 6:07 PM, Martin wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> We want to give ownership of specific objects in the domain model
>>> to a
>>>>>>>> subset of users.
>>>>>>>>
>>>>>>>> Example: an application to manage concerts, and a subset of the
>>> users
>>>> is
>>>>>>>> the concert organization committee. The members of
>>>>>>>> the organization committee can be added and removed at runtime or
>>>> defined
>>>>>>>> when creating a new concert object. A user can be assigned to be a
>>>> member
>>>>>>>> of multiple committees, and the members of a concerts organization
>>>>>>>> committee should be granted permissions to manipulate the concert
>>> and
>>>> its
>>>>>>>> associated objects.
>>>>>>>>
>>>>>>>> I looked at the isis-security-module (
>>>>>>>> https://github.com/isisaddons/isis-module-security) and also at
>> the
>>>>>>>> tenancy, but I had trouble figuring out if this could actually
>> serve
>>>> our
>>>>>>>> needs.
>>>>>>>>
>>>>>>>> How would one go about this with apache isis?
>>>>>>>>
>>>>>>>> Thanks and regards,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>
>>>>
>>>> --
>>>> Bilgin Ibryam
>>>> Camel Committer at ASF & Integration Architect at Red Hat
>>>> Blog: http://ofbizian.com | Twitter: @bibryam
>>>>
>>>> Camel Design Patterns https://leanpub.com/camel-design-patterns
>>>> Instant Apache Camel Message Routing http://www.amazon.com/dp/
>> 1783283475
Re: object level ownership / tenancy
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
within
On 27 September 2016 at 04:25, Martin <mw...@gmail.com> wrote:
>
> I was wondering whether instead of checking for role name / concert name
> equality as in the "ApplicationTenancyEvaluatorForConcerts" it would also
> make sense to associate the ApplicationUser entity with a Concert through
> some Committee (n:m) and then make the decision based on
> navigability/reachability?
You could do it that way, but my strong preference is not to; I feel that
the authorization concerns should be layered on top of the domain model,
not something that the domain objects such as Concert know anything about.
You can use domain event subscribers on the actions of your domain objects
to veto or respond to interactions within your domain, see [1]
> Or is that seen as bad design because entities
> from external plugins/packages should not be associated to the plain domain
> entities?
>
>
exactly
> Another question I need some clarification on: in case the ApplicationUsers
> that can see the Concert are assigned different roles within the Committee,
> the decision on whether a user can edit certain properties has be taken in
> the entity itself (through hideXxxx etc...) or does this require another
> evaluator?
>
>
No, you should just be able to manage this using the
roles/permissions/features of the security module [2]. Again, while you
*could* do this using the hideXxx methods (eg using the UserService to
obtain the identity of the current user), I don't think you should embed
this security knowledge in your core domain.
HTH
Dan
PS: could you subscribe to the users mailing list [3] so that I don't have
to keep moderating your posts? thx.
[1] http://isis.apache.org/guides/rgant.html#_rgant-Action_domainEvent
[2]
https://github.com/isisaddons/isis-module-security#add-permission-at-different-scopes
[3] http://isis.apache.org/support.html#how-to-subscribe
>
> On Mon, Sep 26, 2016 at 11:46 PM, Dan Haywood <
> dan@haywood-associates.co.uk>
> wrote:
>
> > Hi Bilgin,
> >
> > Good catch.
> >
> > It's because the HomePageViewModel#getObjects() is calling the
> > ConcertRepository directly, rather than using the WrapperFactory. If the
> > domain service is wrapped, then the objects that it returns are in effect
> > filtered with respect to the current user. You can see this also in the
> > integration tests 1].
> >
> >
> > I've made the fix [2].
> >
> >
> > Cheers
> > Dan
> >
> > [1]
> > https://github.com/danhaywood/security-generalized-tenancy-
> > app/blob/master/integtests/src/test/java/domainapp/
> > integtests/tests/modules/simple/Concert_IntegTest.java#L78
> > [2]
> > https://github.com/danhaywood/security-generalized-tenancy-app/commit/
> > 64282dc9110b7428835af7a671c962b2be7c9398#diff-
> > 4ef1fac0cff7edc209b038f93834dde6R41
> >
> >
> > On 26 September 2016 at 17:36, Bilgin Ibryam <bi...@gmail.com> wrote:
> >
> > > Hi Dan,
> > >
> > > great timing. I was looking at multi tenancy today and wanted to see
> > > something different than the path concept (which is not very common
> > > for implementing multi tenancy).
> > >
> > > In your demo app, users bill/joe see the correct number of entities
> > > (2), but the home page shows description "3 objects". I wonder why?
> > >
> > >
> > > Thanks,
> > > Bilgin
> > >
> > > On 26 September 2016 at 15:38, Dan Haywood <
> dan@haywood-associates.co.uk
> > >
> > > wrote:
> > > > Hi Martin,
> > > >
> > > > Your post has prompted me to push out a new version of security
> module
> > > [1],
> > > > 1.13.3. (We also had a related requirement in Estatio, so a matter
> of
> > > > killing two bird with one stone).
> > > >
> > > > So, there is now a more general optional SPI service which doesn't
> > depend
> > > > on the concept of application tenancy paths, instead it just gives
> the
> > > > service the two objects to evaluate and asks it to say if they are
> > > visible
> > > > (or hidden) and editable (or disabled):
> > > >
> > > >
> > > > public interface ApplicationTenancyEvaluator {
> > > > boolean handles(Class<?> cls);
> > > (1)
> > > > String hides(Object domainObject, ApplicationUser
> applicationUser);
> > > (2)
> > > > String disables(Object domainObject, ApplicationUser
> > > applicationUser); (3)
> > > > }
> > > >
> > > >
> > > >
> > > > To test this, I knocked up a demo app; it's implementation of this
> > > service
> > > > is:
> > > >
> > > > @DomainService(nature = NatureOfService.DOMAIN)public class
> > > > ApplicationTenancyEvaluatorForConcerts implements
> > > > ApplicationTenancyEvaluator {
> > > > public boolean handles(Class<?> cls) {
> > > > return Concert.class.isAssignableFrom(cls);
> > > > }
> > > > public String hides(Object domainObject, ApplicationUser
> > > applicationUser) {
> > > > if (!(domainObject instanceof Concert)) {
> > > > return null;
> > > > }
> > > > final Concert concert = (Concert) domainObject;
> > > >
> > > > final Optional<ApplicationRole> roleIfAny =
> > > > applicationUser.getRoles()
> > > > .stream()
> > > > .filter(role ->
> Objects.equals(role.getName(),
> > > > concert.getName())) (1)
> > > > .findAny();
> > > >
> > > > return roleIfAny.isPresent()? null: "Requires role " +
> > > > concert.getName();
> > > > }
> > > > public String disables(Object domainObject, ApplicationUser
> > > > applicationUser) {
> > > > return null;
> > > > }
> > > > }
> > > >
> > > >
> > > >
> > > > Hope that makes sense, let us know how you get on.
> > > >
> > > > Cheers
> > > > Dan
> > > >
> > > >
> > > > [1] https://github.com/isisaddons/isis-module-security
> > > > [2] https://github.com/danhaywood/security-generalized-tenancy-app
> > > >
> > > >
> > > >
> > > > On 24 September 2016 at 23:53, David Tildesley
> > > <da...@yahoo.co.nz.invalid>
> > > > wrote:
> > > >
> > > >> Just read my own post. Sorry those chevrons were meant to be double,
> > and
> > > >> they are only indicating color modelling "archetypes"[1] - force of
> > > habit -
> > > >> helps me conceptualize problem domains.
> > > >>
> > > >> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> On 24-Sep-16 3:59 PM, David Tildesley wrote:
> > > >>
> > > >>> Hi Martin,
> > > >>>
> > > >>> You haven't described a tenancy problem so I wouldn't necessarily
> > try
> > > >>> and bend that to your problem. I would model it in the domain and
> use
> > > >>> domain behavior. The behaviour checks if the user is a member of a
> > > >>> committee (<ppt>Committee) in the role of managing
> > > (<role>ConcertManager)
> > > >>> the concert (<moment-interval>Concert) before allowing operations
> on
> > > the
> > > >>> concert component.
> > > >>>
> > > >>> Regards,
> > > >>>
> > > >>> David.
> > > >>>
> > > >>>
> > > >>> On 23-Sep-16 6:07 PM, Martin wrote:
> > > >>>
> > > >>>> Hello,
> > > >>>>
> > > >>>> We want to give ownership of specific objects in the domain model
> > to a
> > > >>>> subset of users.
> > > >>>>
> > > >>>> Example: an application to manage concerts, and a subset of the
> > users
> > > is
> > > >>>> the concert organization committee. The members of
> > > >>>> the organization committee can be added and removed at runtime or
> > > defined
> > > >>>> when creating a new concert object. A user can be assigned to be a
> > > member
> > > >>>> of multiple committees, and the members of a concerts organization
> > > >>>> committee should be granted permissions to manipulate the concert
> > and
> > > its
> > > >>>> associated objects.
> > > >>>>
> > > >>>> I looked at the isis-security-module (
> > > >>>> https://github.com/isisaddons/isis-module-security) and also at
> the
> > > >>>> tenancy, but I had trouble figuring out if this could actually
> serve
> > > our
> > > >>>> needs.
> > > >>>>
> > > >>>> How would one go about this with apache isis?
> > > >>>>
> > > >>>> Thanks and regards,
> > > >>>> Martin
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> > >
> > > --
> > > Bilgin Ibryam
> > > Camel Committer at ASF & Integration Architect at Red Hat
> > > Blog: http://ofbizian.com | Twitter: @bibryam
> > >
> > > Camel Design Patterns https://leanpub.com/camel-design-patterns
> > > Instant Apache Camel Message Routing http://www.amazon.com/dp/
> 1783283475
> > >
> >
>
Re: object level ownership / tenancy
Posted by Martin <mw...@gmail.com>.
Thanks for all the replies! I will give it a try this way.
I was wondering whether instead of checking for role name / concert name
equality as in the "ApplicationTenancyEvaluatorForConcerts" it would also
make sense to associate the ApplicationUser entity with a Concert through
some Committee (n:m) and then make the decision based on
navigability/reachability? Or is that seen as bad design because entities
from external plugins/packages should not be associated to the plain domain
entities?
Another question I need some clarification on: in case the ApplicationUsers
that can see the Concert are assigned different roles within the Committee,
the decision on whether a user can edit certain properties has be taken in
the entity itself (through hideXxxx etc...) or does this require another
evaluator?
Thanks and regards,
Martin
On Mon, Sep 26, 2016 at 11:46 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi Bilgin,
>
> Good catch.
>
> It's because the HomePageViewModel#getObjects() is calling the
> ConcertRepository directly, rather than using the WrapperFactory. If the
> domain service is wrapped, then the objects that it returns are in effect
> filtered with respect to the current user. You can see this also in the
> integration tests 1].
>
>
> I've made the fix [2].
>
>
> Cheers
> Dan
>
> [1]
> https://github.com/danhaywood/security-generalized-tenancy-
> app/blob/master/integtests/src/test/java/domainapp/
> integtests/tests/modules/simple/Concert_IntegTest.java#L78
> [2]
> https://github.com/danhaywood/security-generalized-tenancy-app/commit/
> 64282dc9110b7428835af7a671c962b2be7c9398#diff-
> 4ef1fac0cff7edc209b038f93834dde6R41
>
>
> On 26 September 2016 at 17:36, Bilgin Ibryam <bi...@gmail.com> wrote:
>
> > Hi Dan,
> >
> > great timing. I was looking at multi tenancy today and wanted to see
> > something different than the path concept (which is not very common
> > for implementing multi tenancy).
> >
> > In your demo app, users bill/joe see the correct number of entities
> > (2), but the home page shows description "3 objects". I wonder why?
> >
> >
> > Thanks,
> > Bilgin
> >
> > On 26 September 2016 at 15:38, Dan Haywood <dan@haywood-associates.co.uk
> >
> > wrote:
> > > Hi Martin,
> > >
> > > Your post has prompted me to push out a new version of security module
> > [1],
> > > 1.13.3. (We also had a related requirement in Estatio, so a matter of
> > > killing two bird with one stone).
> > >
> > > So, there is now a more general optional SPI service which doesn't
> depend
> > > on the concept of application tenancy paths, instead it just gives the
> > > service the two objects to evaluate and asks it to say if they are
> > visible
> > > (or hidden) and editable (or disabled):
> > >
> > >
> > > public interface ApplicationTenancyEvaluator {
> > > boolean handles(Class<?> cls);
> > (1)
> > > String hides(Object domainObject, ApplicationUser applicationUser);
> > (2)
> > > String disables(Object domainObject, ApplicationUser
> > applicationUser); (3)
> > > }
> > >
> > >
> > >
> > > To test this, I knocked up a demo app; it's implementation of this
> > service
> > > is:
> > >
> > > @DomainService(nature = NatureOfService.DOMAIN)public class
> > > ApplicationTenancyEvaluatorForConcerts implements
> > > ApplicationTenancyEvaluator {
> > > public boolean handles(Class<?> cls) {
> > > return Concert.class.isAssignableFrom(cls);
> > > }
> > > public String hides(Object domainObject, ApplicationUser
> > applicationUser) {
> > > if (!(domainObject instanceof Concert)) {
> > > return null;
> > > }
> > > final Concert concert = (Concert) domainObject;
> > >
> > > final Optional<ApplicationRole> roleIfAny =
> > > applicationUser.getRoles()
> > > .stream()
> > > .filter(role -> Objects.equals(role.getName(),
> > > concert.getName())) (1)
> > > .findAny();
> > >
> > > return roleIfAny.isPresent()? null: "Requires role " +
> > > concert.getName();
> > > }
> > > public String disables(Object domainObject, ApplicationUser
> > > applicationUser) {
> > > return null;
> > > }
> > > }
> > >
> > >
> > >
> > > Hope that makes sense, let us know how you get on.
> > >
> > > Cheers
> > > Dan
> > >
> > >
> > > [1] https://github.com/isisaddons/isis-module-security
> > > [2] https://github.com/danhaywood/security-generalized-tenancy-app
> > >
> > >
> > >
> > > On 24 September 2016 at 23:53, David Tildesley
> > <da...@yahoo.co.nz.invalid>
> > > wrote:
> > >
> > >> Just read my own post. Sorry those chevrons were meant to be double,
> and
> > >> they are only indicating color modelling "archetypes"[1] - force of
> > habit -
> > >> helps me conceptualize problem domains.
> > >>
> > >> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
> > >>
> > >>
> > >>
> > >>
> > >> On 24-Sep-16 3:59 PM, David Tildesley wrote:
> > >>
> > >>> Hi Martin,
> > >>>
> > >>> You haven't described a tenancy problem so I wouldn't necessarily
> try
> > >>> and bend that to your problem. I would model it in the domain and use
> > >>> domain behavior. The behaviour checks if the user is a member of a
> > >>> committee (<ppt>Committee) in the role of managing
> > (<role>ConcertManager)
> > >>> the concert (<moment-interval>Concert) before allowing operations on
> > the
> > >>> concert component.
> > >>>
> > >>> Regards,
> > >>>
> > >>> David.
> > >>>
> > >>>
> > >>> On 23-Sep-16 6:07 PM, Martin wrote:
> > >>>
> > >>>> Hello,
> > >>>>
> > >>>> We want to give ownership of specific objects in the domain model
> to a
> > >>>> subset of users.
> > >>>>
> > >>>> Example: an application to manage concerts, and a subset of the
> users
> > is
> > >>>> the concert organization committee. The members of
> > >>>> the organization committee can be added and removed at runtime or
> > defined
> > >>>> when creating a new concert object. A user can be assigned to be a
> > member
> > >>>> of multiple committees, and the members of a concerts organization
> > >>>> committee should be granted permissions to manipulate the concert
> and
> > its
> > >>>> associated objects.
> > >>>>
> > >>>> I looked at the isis-security-module (
> > >>>> https://github.com/isisaddons/isis-module-security) and also at the
> > >>>> tenancy, but I had trouble figuring out if this could actually serve
> > our
> > >>>> needs.
> > >>>>
> > >>>> How would one go about this with apache isis?
> > >>>>
> > >>>> Thanks and regards,
> > >>>> Martin
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
> >
> > --
> > Bilgin Ibryam
> > Camel Committer at ASF & Integration Architect at Red Hat
> > Blog: http://ofbizian.com | Twitter: @bibryam
> >
> > Camel Design Patterns https://leanpub.com/camel-design-patterns
> > Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
> >
>
Re: object level ownership / tenancy
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Bilgin,
Good catch.
It's because the HomePageViewModel#getObjects() is calling the
ConcertRepository directly, rather than using the WrapperFactory. If the
domain service is wrapped, then the objects that it returns are in effect
filtered with respect to the current user. You can see this also in the
integration tests 1].
I've made the fix [2].
Cheers
Dan
[1]
https://github.com/danhaywood/security-generalized-tenancy-app/blob/master/integtests/src/test/java/domainapp/integtests/tests/modules/simple/Concert_IntegTest.java#L78
[2]
https://github.com/danhaywood/security-generalized-tenancy-app/commit/64282dc9110b7428835af7a671c962b2be7c9398#diff-4ef1fac0cff7edc209b038f93834dde6R41
On 26 September 2016 at 17:36, Bilgin Ibryam <bi...@gmail.com> wrote:
> Hi Dan,
>
> great timing. I was looking at multi tenancy today and wanted to see
> something different than the path concept (which is not very common
> for implementing multi tenancy).
>
> In your demo app, users bill/joe see the correct number of entities
> (2), but the home page shows description "3 objects". I wonder why?
>
>
> Thanks,
> Bilgin
>
> On 26 September 2016 at 15:38, Dan Haywood <da...@haywood-associates.co.uk>
> wrote:
> > Hi Martin,
> >
> > Your post has prompted me to push out a new version of security module
> [1],
> > 1.13.3. (We also had a related requirement in Estatio, so a matter of
> > killing two bird with one stone).
> >
> > So, there is now a more general optional SPI service which doesn't depend
> > on the concept of application tenancy paths, instead it just gives the
> > service the two objects to evaluate and asks it to say if they are
> visible
> > (or hidden) and editable (or disabled):
> >
> >
> > public interface ApplicationTenancyEvaluator {
> > boolean handles(Class<?> cls);
> (1)
> > String hides(Object domainObject, ApplicationUser applicationUser);
> (2)
> > String disables(Object domainObject, ApplicationUser
> applicationUser); (3)
> > }
> >
> >
> >
> > To test this, I knocked up a demo app; it's implementation of this
> service
> > is:
> >
> > @DomainService(nature = NatureOfService.DOMAIN)public class
> > ApplicationTenancyEvaluatorForConcerts implements
> > ApplicationTenancyEvaluator {
> > public boolean handles(Class<?> cls) {
> > return Concert.class.isAssignableFrom(cls);
> > }
> > public String hides(Object domainObject, ApplicationUser
> applicationUser) {
> > if (!(domainObject instanceof Concert)) {
> > return null;
> > }
> > final Concert concert = (Concert) domainObject;
> >
> > final Optional<ApplicationRole> roleIfAny =
> > applicationUser.getRoles()
> > .stream()
> > .filter(role -> Objects.equals(role.getName(),
> > concert.getName())) (1)
> > .findAny();
> >
> > return roleIfAny.isPresent()? null: "Requires role " +
> > concert.getName();
> > }
> > public String disables(Object domainObject, ApplicationUser
> > applicationUser) {
> > return null;
> > }
> > }
> >
> >
> >
> > Hope that makes sense, let us know how you get on.
> >
> > Cheers
> > Dan
> >
> >
> > [1] https://github.com/isisaddons/isis-module-security
> > [2] https://github.com/danhaywood/security-generalized-tenancy-app
> >
> >
> >
> > On 24 September 2016 at 23:53, David Tildesley
> <da...@yahoo.co.nz.invalid>
> > wrote:
> >
> >> Just read my own post. Sorry those chevrons were meant to be double, and
> >> they are only indicating color modelling "archetypes"[1] - force of
> habit -
> >> helps me conceptualize problem domains.
> >>
> >> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
> >>
> >>
> >>
> >>
> >> On 24-Sep-16 3:59 PM, David Tildesley wrote:
> >>
> >>> Hi Martin,
> >>>
> >>> You haven't described a tenancy problem so I wouldn't necessarily try
> >>> and bend that to your problem. I would model it in the domain and use
> >>> domain behavior. The behaviour checks if the user is a member of a
> >>> committee (<ppt>Committee) in the role of managing
> (<role>ConcertManager)
> >>> the concert (<moment-interval>Concert) before allowing operations on
> the
> >>> concert component.
> >>>
> >>> Regards,
> >>>
> >>> David.
> >>>
> >>>
> >>> On 23-Sep-16 6:07 PM, Martin wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> We want to give ownership of specific objects in the domain model to a
> >>>> subset of users.
> >>>>
> >>>> Example: an application to manage concerts, and a subset of the users
> is
> >>>> the concert organization committee. The members of
> >>>> the organization committee can be added and removed at runtime or
> defined
> >>>> when creating a new concert object. A user can be assigned to be a
> member
> >>>> of multiple committees, and the members of a concerts organization
> >>>> committee should be granted permissions to manipulate the concert and
> its
> >>>> associated objects.
> >>>>
> >>>> I looked at the isis-security-module (
> >>>> https://github.com/isisaddons/isis-module-security) and also at the
> >>>> tenancy, but I had trouble figuring out if this could actually serve
> our
> >>>> needs.
> >>>>
> >>>> How would one go about this with apache isis?
> >>>>
> >>>> Thanks and regards,
> >>>> Martin
> >>>>
> >>>>
> >>>
> >>
>
>
>
> --
> Bilgin Ibryam
> Camel Committer at ASF & Integration Architect at Red Hat
> Blog: http://ofbizian.com | Twitter: @bibryam
>
> Camel Design Patterns https://leanpub.com/camel-design-patterns
> Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
>
Re: object level ownership / tenancy
Posted by Bilgin Ibryam <bi...@gmail.com>.
Hi Dan,
great timing. I was looking at multi tenancy today and wanted to see
something different than the path concept (which is not very common
for implementing multi tenancy).
In your demo app, users bill/joe see the correct number of entities
(2), but the home page shows description "3 objects". I wonder why?
Thanks,
Bilgin
On 26 September 2016 at 15:38, Dan Haywood <da...@haywood-associates.co.uk> wrote:
> Hi Martin,
>
> Your post has prompted me to push out a new version of security module [1],
> 1.13.3. (We also had a related requirement in Estatio, so a matter of
> killing two bird with one stone).
>
> So, there is now a more general optional SPI service which doesn't depend
> on the concept of application tenancy paths, instead it just gives the
> service the two objects to evaluate and asks it to say if they are visible
> (or hidden) and editable (or disabled):
>
>
> public interface ApplicationTenancyEvaluator {
> boolean handles(Class<?> cls); (1)
> String hides(Object domainObject, ApplicationUser applicationUser); (2)
> String disables(Object domainObject, ApplicationUser applicationUser); (3)
> }
>
>
>
> To test this, I knocked up a demo app; it's implementation of this service
> is:
>
> @DomainService(nature = NatureOfService.DOMAIN)public class
> ApplicationTenancyEvaluatorForConcerts implements
> ApplicationTenancyEvaluator {
> public boolean handles(Class<?> cls) {
> return Concert.class.isAssignableFrom(cls);
> }
> public String hides(Object domainObject, ApplicationUser applicationUser) {
> if (!(domainObject instanceof Concert)) {
> return null;
> }
> final Concert concert = (Concert) domainObject;
>
> final Optional<ApplicationRole> roleIfAny =
> applicationUser.getRoles()
> .stream()
> .filter(role -> Objects.equals(role.getName(),
> concert.getName())) (1)
> .findAny();
>
> return roleIfAny.isPresent()? null: "Requires role " +
> concert.getName();
> }
> public String disables(Object domainObject, ApplicationUser
> applicationUser) {
> return null;
> }
> }
>
>
>
> Hope that makes sense, let us know how you get on.
>
> Cheers
> Dan
>
>
> [1] https://github.com/isisaddons/isis-module-security
> [2] https://github.com/danhaywood/security-generalized-tenancy-app
>
>
>
> On 24 September 2016 at 23:53, David Tildesley <da...@yahoo.co.nz.invalid>
> wrote:
>
>> Just read my own post. Sorry those chevrons were meant to be double, and
>> they are only indicating color modelling "archetypes"[1] - force of habit -
>> helps me conceptualize problem domains.
>>
>> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
>>
>>
>>
>>
>> On 24-Sep-16 3:59 PM, David Tildesley wrote:
>>
>>> Hi Martin,
>>>
>>> You haven't described a tenancy problem so I wouldn't necessarily try
>>> and bend that to your problem. I would model it in the domain and use
>>> domain behavior. The behaviour checks if the user is a member of a
>>> committee (<ppt>Committee) in the role of managing (<role>ConcertManager)
>>> the concert (<moment-interval>Concert) before allowing operations on the
>>> concert component.
>>>
>>> Regards,
>>>
>>> David.
>>>
>>>
>>> On 23-Sep-16 6:07 PM, Martin wrote:
>>>
>>>> Hello,
>>>>
>>>> We want to give ownership of specific objects in the domain model to a
>>>> subset of users.
>>>>
>>>> Example: an application to manage concerts, and a subset of the users is
>>>> the concert organization committee. The members of
>>>> the organization committee can be added and removed at runtime or defined
>>>> when creating a new concert object. A user can be assigned to be a member
>>>> of multiple committees, and the members of a concerts organization
>>>> committee should be granted permissions to manipulate the concert and its
>>>> associated objects.
>>>>
>>>> I looked at the isis-security-module (
>>>> https://github.com/isisaddons/isis-module-security) and also at the
>>>> tenancy, but I had trouble figuring out if this could actually serve our
>>>> needs.
>>>>
>>>> How would one go about this with apache isis?
>>>>
>>>> Thanks and regards,
>>>> Martin
>>>>
>>>>
>>>
>>
--
Bilgin Ibryam
Camel Committer at ASF & Integration Architect at Red Hat
Blog: http://ofbizian.com | Twitter: @bibryam
Camel Design Patterns https://leanpub.com/camel-design-patterns
Instant Apache Camel Message Routing http://www.amazon.com/dp/1783283475
Re: object level ownership / tenancy
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Martin,
Your post has prompted me to push out a new version of security module [1],
1.13.3. (We also had a related requirement in Estatio, so a matter of
killing two bird with one stone).
So, there is now a more general optional SPI service which doesn't depend
on the concept of application tenancy paths, instead it just gives the
service the two objects to evaluate and asks it to say if they are visible
(or hidden) and editable (or disabled):
public interface ApplicationTenancyEvaluator {
boolean handles(Class<?> cls); (1)
String hides(Object domainObject, ApplicationUser applicationUser); (2)
String disables(Object domainObject, ApplicationUser applicationUser); (3)
}
To test this, I knocked up a demo app; it's implementation of this service
is:
@DomainService(nature = NatureOfService.DOMAIN)public class
ApplicationTenancyEvaluatorForConcerts implements
ApplicationTenancyEvaluator {
public boolean handles(Class<?> cls) {
return Concert.class.isAssignableFrom(cls);
}
public String hides(Object domainObject, ApplicationUser applicationUser) {
if (!(domainObject instanceof Concert)) {
return null;
}
final Concert concert = (Concert) domainObject;
final Optional<ApplicationRole> roleIfAny =
applicationUser.getRoles()
.stream()
.filter(role -> Objects.equals(role.getName(),
concert.getName())) (1)
.findAny();
return roleIfAny.isPresent()? null: "Requires role " +
concert.getName();
}
public String disables(Object domainObject, ApplicationUser
applicationUser) {
return null;
}
}
Hope that makes sense, let us know how you get on.
Cheers
Dan
[1] https://github.com/isisaddons/isis-module-security
[2] https://github.com/danhaywood/security-generalized-tenancy-app
On 24 September 2016 at 23:53, David Tildesley <da...@yahoo.co.nz.invalid>
wrote:
> Just read my own post. Sorry those chevrons were meant to be double, and
> they are only indicating color modelling "archetypes"[1] - force of habit -
> helps me conceptualize problem domains.
>
> [1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
>
>
>
>
> On 24-Sep-16 3:59 PM, David Tildesley wrote:
>
>> Hi Martin,
>>
>> You haven't described a tenancy problem so I wouldn't necessarily try
>> and bend that to your problem. I would model it in the domain and use
>> domain behavior. The behaviour checks if the user is a member of a
>> committee (<ppt>Committee) in the role of managing (<role>ConcertManager)
>> the concert (<moment-interval>Concert) before allowing operations on the
>> concert component.
>>
>> Regards,
>>
>> David.
>>
>>
>> On 23-Sep-16 6:07 PM, Martin wrote:
>>
>>> Hello,
>>>
>>> We want to give ownership of specific objects in the domain model to a
>>> subset of users.
>>>
>>> Example: an application to manage concerts, and a subset of the users is
>>> the concert organization committee. The members of
>>> the organization committee can be added and removed at runtime or defined
>>> when creating a new concert object. A user can be assigned to be a member
>>> of multiple committees, and the members of a concerts organization
>>> committee should be granted permissions to manipulate the concert and its
>>> associated objects.
>>>
>>> I looked at the isis-security-module (
>>> https://github.com/isisaddons/isis-module-security) and also at the
>>> tenancy, but I had trouble figuring out if this could actually serve our
>>> needs.
>>>
>>> How would one go about this with apache isis?
>>>
>>> Thanks and regards,
>>> Martin
>>>
>>>
>>
>
Re: object level ownership / tenancy
Posted by David Tildesley <da...@yahoo.co.nz.INVALID>.
Just read my own post. Sorry those chevrons were meant to be double, and
they are only indicating color modelling "archetypes"[1] - force of
habit - helps me conceptualize problem domains.
[1] http://www.nebulon.com/articles/fdd/download/adspostera3.pdf
On 24-Sep-16 3:59 PM, David Tildesley wrote:
> Hi Martin,
>
> You haven't described a tenancy problem so I wouldn't necessarily try
> and bend that to your problem. I would model it in the domain and use
> domain behavior. The behaviour checks if the user is a member of a
> committee (<ppt>Committee) in the role of managing
> (<role>ConcertManager) the concert (<moment-interval>Concert) before
> allowing operations on the concert component.
>
> Regards,
>
> David.
>
>
> On 23-Sep-16 6:07 PM, Martin wrote:
>> Hello,
>>
>> We want to give ownership of specific objects in the domain model to a
>> subset of users.
>>
>> Example: an application to manage concerts, and a subset of the users is
>> the concert organization committee. The members of
>> the organization committee can be added and removed at runtime or
>> defined
>> when creating a new concert object. A user can be assigned to be a
>> member
>> of multiple committees, and the members of a concerts organization
>> committee should be granted permissions to manipulate the concert and
>> its
>> associated objects.
>>
>> I looked at the isis-security-module (
>> https://github.com/isisaddons/isis-module-security) and also at the
>> tenancy, but I had trouble figuring out if this could actually serve our
>> needs.
>>
>> How would one go about this with apache isis?
>>
>> Thanks and regards,
>> Martin
>>
>
Re: object level ownership / tenancy
Posted by David Tildesley <da...@yahoo.co.nz.INVALID>.
Hi Martin,
You haven't described a tenancy problem so I wouldn't necessarily try
and bend that to your problem. I would model it in the domain and use
domain behavior. The behaviour checks if the user is a member of a
committee (<ppt>Committee) in the role of managing
(<role>ConcertManager) the concert (<moment-interval>Concert) before
allowing operations on the concert component.
Regards,
David.
On 23-Sep-16 6:07 PM, Martin wrote:
> Hello,
>
> We want to give ownership of specific objects in the domain model to a
> subset of users.
>
> Example: an application to manage concerts, and a subset of the users is
> the concert organization committee. The members of
> the organization committee can be added and removed at runtime or defined
> when creating a new concert object. A user can be assigned to be a member
> of multiple committees, and the members of a concerts organization
> committee should be granted permissions to manipulate the concert and its
> associated objects.
>
> I looked at the isis-security-module (
> https://github.com/isisaddons/isis-module-security) and also at the
> tenancy, but I had trouble figuring out if this could actually serve our
> needs.
>
> How would one go about this with apache isis?
>
> Thanks and regards,
> Martin
>
Re: object level ownership / tenancy
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi, Martin.
We discussed about this recently.
Please, read this thread [1] and determine if it can be helpful for your use case or need more detail.
Regards,
Oscar
[1] https://lists.apache.org/thread.html/%3C9D9B9075-C6B8-4637-80A3-0D4801BFA350@govertis.com%3E <https://lists.apache.org/thread.html/%3C9D9B9075-C6B8-4637-80A3-0D4801BFA350@govertis.com%3E>
> El 23 sept 2016, a las 8:07, Martin <mw...@gmail.com> escribió:
>
> Hello,
>
> We want to give ownership of specific objects in the domain model to a
> subset of users.
>
> Example: an application to manage concerts, and a subset of the users is
> the concert organization committee. The members of
> the organization committee can be added and removed at runtime or defined
> when creating a new concert object. A user can be assigned to be a member
> of multiple committees, and the members of a concerts organization
> committee should be granted permissions to manipulate the concert and its
> associated objects.
>
> I looked at the isis-security-module (
> https://github.com/isisaddons/isis-module-security) and also at the
> tenancy, but I had trouble figuring out if this could actually serve our
> needs.
>
> How would one go about this with apache isis?
>
> Thanks and regards,
> Martin
Óscar Bou Bou
Socio - IT & GRC Management Services Director
m: +34 620 267 520
s: <http://www.govertis.com/>www.govertis.com <http://www.govertis.com/> e: o.bou@govertis.com <ma...@govertis.com>
LinkedIn: https://www.linkedin.com/in/oscarbou <https://www.linkedin.com/in/oscarbou>
Twitter: @oscarbou <https://twitter.com/oscarbou>
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 GOVERTIS ADVISORY SERVICES, 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: GOVERTIS ADVISORY SERVICES, S.L. Avda Cortes Valencianas, 58 – 8º - 6ª. 46015 - Valencia, y Paseo de la Castellana, 153, 28045 - MADRID. Asimismo, es su responsabilidad comprobar que este mensaje o sus archivos adjuntos no contengan virus informáticos, y en caso que los tuvieran eliminarlos.