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 <[email protected]> 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 <
[email protected]>
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 <[email protected]> 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 <
[email protected]
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
<[email protected]>
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
