Re: object level ownership / tenancy

[David Tildesley]

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 <> with <> to 
<> it is appropriate to ask the domain whether the 
system user identified as a <> in the system is allowed to play 
the <> wrt the <>.


The domain may have to do some non-trivial checking e.g. the Person must 
be in the <> of ConcertOrganiser wrt Concert (or be a member of an 
OrganisingCommittee which has a <> 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  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 <
d...@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  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 <

d...@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 

Re: object level ownership / tenancy

[Bilgin Ibryam]

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  
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 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 
> 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 (Committee) in the role of managing (ConcertManager)
>>> the concert (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

[Dan Haywood]

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 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 
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 (Committee) in the role of managing (ConcertManager)
>> the concert (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

[David Tildesley]

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 (Committee) in the role of managing 
(ConcertManager) the concert (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

[David Tildesley]

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 (Committee) in the role of managing 
(ConcertManager) the concert (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

[Óscar Bou - GOVERTIS]

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-0d4801bfa...@govertis.com%3E
 




> El 23 sept 2016, a las 8:07, Martin  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:  www.govertis.com  e: 
o@govertis.com 

LinkedIn: https://www.linkedin.com/in/oscarbou 

Twitter:@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.

object level ownership / tenancy

[Martin]

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