You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by David Soff <da...@soff.nl> on 2016/02/23 15:36:15 UTC
multiple tenancy/scoped roles in ISIS security
Hello,
I have been playing with ISIS some more and have a question concerning
multiple tenancies for a single user.
The application I am working on is a rowing regatta management system.
I would like users to have scoped roles so that
user A can be:
- a general admin for regatta A
- a financial admin for regatta B
- a normal user (without privileges) for regatta C
user B can be:
- a general admin for regatta B
- a financial admin for regatta C
- a normal user (without privileges) for regatta A
There are no necessary commonalities between the regattas.
Is a setup like this possible using ISIS-security or will I have to build
something from scratch?
thanks a million,
David
Re: multiple tenancy/scoped roles in ISIS security
Posted by Jeroen van der Wal <je...@stromboli.it>.
Thanks for adding some food for thought Oscar.
There are more ways that lead to Rome [1] but with the given scenario I
still would model it as part of the domain, rely on database queries for
performance and maybe use app tenancy as a safeguard. Just a matter of
taste I guess.
[1] https://en.wiktionary.org/wiki/all_roads_lead_to_Rome
On 23 February 2016 at 20:59, Óscar Bou - GOVERTIS <o....@govertis.com>
wrote:
>
> Hi David and Jeroen,
>
> Current Isis Security add-on has an interface, "WithApplicationTenancy”,
> that can also be used to apply custom domain/business logic to resolve the
> Application Tenancy to assign to a given entity.
> By means of the tenancy path returned, you can determine the permissions
> that the different roles or users will be over that entity.
> That way, perhaps your need can be modeled by using custom-defined
> “tenancy paths”, that allow to determine to whom allow to see a given
> Entity.
> See [1] for further details.
>
> So basically if, when you’re computing the Domain Object’s tenancy path,
> you consider if current Isis logged user is associated with the general
> admin, financial admin or user, you can properly return a string that
> allows to view, edit or hide that domain object to the logged user.
>
>
>
>
> An example implementation of overriding the tenancy path we have in
> production is the next one.
> Please, notice that the “Account” entity is linked to an ApplicationUser
> as defined in the isis-module-security add-on.
>
> That way, the “security user” has an associated Domain Entity that can be
> used to define business logic in the domain.
>
>
>
>
> public abstract class AbstractMyProjectObject<T extends
> AbstractMyProjectObject<T>>
> extends AbstractDomainObject implements Comparable<T>,
> WithApplicationTenancy {
>
> // //////////////////////////////////////
> // Application Tenancy.
> // //////////////////////////////////////
>
> protected static String TENANT_PATH_UNIVERSAL = "/";
>
> @Property(hidden = Where.EVERYWHERE)
> @Override
> public ApplicationTenancy getApplicationTenancy() {
> final ApplicationTenancy applicationTenancy =
> this.applicationTenancies.findTenancyByPath(this.tenancyPath());
>
> if (applicationTenancy == null) {
> throw new FatalException("Domain Object without Application
> Tenancy !!! That's forbidden.");
> }
>
> return applicationTenancy;
> }
>
> @Programmatic
> public abstract String tenancyPath();
>
> […]
> }
>
>
> public class Account extends AbstractMyProjectObject<Account> {
>
> […]
>
> // {{ ApplicationUser (property)
> private ApplicationUser applicationUser;
>
> // Acts as a Title because ApplicationUser has #title() impl
> @Column(allowsNull = "false")
> @PropertyLayout(hidden = Where.ANYWHERE)
> public ApplicationUser getApplicationUser() {
> return this.applicationUser;
> }
>
> public void setApplicationUser(final ApplicationUser applicationUser) {
> this.applicationUser = applicationUser;
> }
>
> // }}
>
> @Override
> @Programmatic
> public String tenancyPath() {
> if (this.getApplicationUser() != null) {
> return "/accounts/" + this.getApplicationUser().getName();
> } else {
> return TenantMyProjectInternalUsers.TENANT_PATH_MyProject_ONLY;
> }
> }
> }
>
>
> public abstract class extends AbstractMyProjectObject<IE> {
>
> […]
>
> @Override
> @Programmatic
> public String tenancyPath() {
> return TENANT_PATH_UNIVERSAL;
> }
> }
>
>
> When an entity returns a “tenancyPath” of “/accounts/xxxx” only specific
> users are allowed to see it.
>
> All entities whose “tenancyPath” is simply “/“ can be viewed by anybody.
>
>
>
>
> HTH,
>
> Oscar
>
>
>
> [1] https://github.com/isisaddons/isis-module-security#application-tenancy
> <
> https://github.com/isisaddons/isis-module-security#applicationtenancypathevaluator
> >
>
>
>
>
>
> > El 23 feb 2016, a las 18:37, Jeroen van der Wal <je...@stromboli.it>
> escribió:
> >
> > Hi David,
> >
> > Currently in isis-module-security a user can have multiple roles (general
> > admin, financial admin, etc) and a single application tenancy (your
> > regatta) which is not a perfect match for your requirements. Personally I
> > would model an tuple entity like RegattaRole to specify the user, regatta
> > and role type and use the security module for system roles like admin and
> > user.
> >
> > Cheers,
> >
> > Jeroen
> >
> >
> > On 23 February 2016 at 15:36, David Soff <da...@soff.nl> wrote:
> >
> >> Hello,
> >>
> >> I have been playing with ISIS some more and have a question concerning
> >> multiple tenancies for a single user.
> >>
> >> The application I am working on is a rowing regatta management system.
> >> I would like users to have scoped roles so that
> >> user A can be:
> >> - a general admin for regatta A
> >> - a financial admin for regatta B
> >> - a normal user (without privileges) for regatta C
> >>
> >> user B can be:
> >> - a general admin for regatta B
> >> - a financial admin for regatta C
> >> - a normal user (without privileges) for regatta A
> >>
> >> There are no necessary commonalities between the regattas.
> >>
> >> Is a setup like this possible using ISIS-security or will I have to
> build
> >> something from scratch?
> >>
> >> thanks a million,
> >>
> >> David
> >>
>
>
Re: multiple tenancy/scoped roles in ISIS security
Posted by Óscar Bou - GOVERTIS <o....@govertis.com>.
Hi David and Jeroen,
Current Isis Security add-on has an interface, "WithApplicationTenancy”, that can also be used to apply custom domain/business logic to resolve the Application Tenancy to assign to a given entity.
By means of the tenancy path returned, you can determine the permissions that the different roles or users will be over that entity.
That way, perhaps your need can be modeled by using custom-defined “tenancy paths”, that allow to determine to whom allow to see a given Entity.
See [1] for further details.
So basically if, when you’re computing the Domain Object’s tenancy path, you consider if current Isis logged user is associated with the general admin, financial admin or user, you can properly return a string that allows to view, edit or hide that domain object to the logged user.
An example implementation of overriding the tenancy path we have in production is the next one.
Please, notice that the “Account” entity is linked to an ApplicationUser as defined in the isis-module-security add-on.
That way, the “security user” has an associated Domain Entity that can be used to define business logic in the domain.
public abstract class AbstractMyProjectObject<T extends AbstractMyProjectObject<T>>
extends AbstractDomainObject implements Comparable<T>, WithApplicationTenancy {
// //////////////////////////////////////
// Application Tenancy.
// //////////////////////////////////////
protected static String TENANT_PATH_UNIVERSAL = "/";
@Property(hidden = Where.EVERYWHERE)
@Override
public ApplicationTenancy getApplicationTenancy() {
final ApplicationTenancy applicationTenancy = this.applicationTenancies.findTenancyByPath(this.tenancyPath());
if (applicationTenancy == null) {
throw new FatalException("Domain Object without Application Tenancy !!! That's forbidden.");
}
return applicationTenancy;
}
@Programmatic
public abstract String tenancyPath();
[…]
}
public class Account extends AbstractMyProjectObject<Account> {
[…]
// {{ ApplicationUser (property)
private ApplicationUser applicationUser;
// Acts as a Title because ApplicationUser has #title() impl
@Column(allowsNull = "false")
@PropertyLayout(hidden = Where.ANYWHERE)
public ApplicationUser getApplicationUser() {
return this.applicationUser;
}
public void setApplicationUser(final ApplicationUser applicationUser) {
this.applicationUser = applicationUser;
}
// }}
@Override
@Programmatic
public String tenancyPath() {
if (this.getApplicationUser() != null) {
return "/accounts/" + this.getApplicationUser().getName();
} else {
return TenantMyProjectInternalUsers.TENANT_PATH_MyProject_ONLY;
}
}
}
public abstract class extends AbstractMyProjectObject<IE> {
[…]
@Override
@Programmatic
public String tenancyPath() {
return TENANT_PATH_UNIVERSAL;
}
}
When an entity returns a “tenancyPath” of “/accounts/xxxx” only specific users are allowed to see it.
All entities whose “tenancyPath” is simply “/“ can be viewed by anybody.
HTH,
Oscar
[1] https://github.com/isisaddons/isis-module-security#application-tenancy
<https://github.com/isisaddons/isis-module-security#applicationtenancypathevaluator>
> El 23 feb 2016, a las 18:37, Jeroen van der Wal <je...@stromboli.it> escribió:
>
> Hi David,
>
> Currently in isis-module-security a user can have multiple roles (general
> admin, financial admin, etc) and a single application tenancy (your
> regatta) which is not a perfect match for your requirements. Personally I
> would model an tuple entity like RegattaRole to specify the user, regatta
> and role type and use the security module for system roles like admin and
> user.
>
> Cheers,
>
> Jeroen
>
>
> On 23 February 2016 at 15:36, David Soff <da...@soff.nl> wrote:
>
>> Hello,
>>
>> I have been playing with ISIS some more and have a question concerning
>> multiple tenancies for a single user.
>>
>> The application I am working on is a rowing regatta management system.
>> I would like users to have scoped roles so that
>> user A can be:
>> - a general admin for regatta A
>> - a financial admin for regatta B
>> - a normal user (without privileges) for regatta C
>>
>> user B can be:
>> - a general admin for regatta B
>> - a financial admin for regatta C
>> - a normal user (without privileges) for regatta A
>>
>> There are no necessary commonalities between the regattas.
>>
>> Is a setup like this possible using ISIS-security or will I have to build
>> something from scratch?
>>
>> thanks a million,
>>
>> David
>>
Re: multiple tenancy/scoped roles in ISIS security
Posted by Jeroen van der Wal <je...@stromboli.it>.
Hi David,
Currently in isis-module-security a user can have multiple roles (general
admin, financial admin, etc) and a single application tenancy (your
regatta) which is not a perfect match for your requirements. Personally I
would model an tuple entity like RegattaRole to specify the user, regatta
and role type and use the security module for system roles like admin and
user.
Cheers,
Jeroen
On 23 February 2016 at 15:36, David Soff <da...@soff.nl> wrote:
> Hello,
>
> I have been playing with ISIS some more and have a question concerning
> multiple tenancies for a single user.
>
> The application I am working on is a rowing regatta management system.
> I would like users to have scoped roles so that
> user A can be:
> - a general admin for regatta A
> - a financial admin for regatta B
> - a normal user (without privileges) for regatta C
>
> user B can be:
> - a general admin for regatta B
> - a financial admin for regatta C
> - a normal user (without privileges) for regatta A
>
> There are no necessary commonalities between the regattas.
>
> Is a setup like this possible using ISIS-security or will I have to build
> something from scratch?
>
> thanks a million,
>
> David
>