Re: multiple tenancy/scoped roles in ISIS security

[Jeroen van der Wal]

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 
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 AbstractMyProjectObject>
> extends AbstractDomainObject implements Comparable,
> 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 {
>
>[…]
>
> // {{ 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 {
>
>[…]
>
> @Override
> @Programmatic
> public String tenancyPath() {
> return TENANT_PATH_UNIVERSAL;
> }
> }
>
>
> When an entity returns a “tenancyPath” of “/accounts/” 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 
> 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  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 

Re: multiple tenancy/scoped roles in ISIS security

[Óscar Bou - GOVERTIS]

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>
extends AbstractDomainObject implements Comparable, 
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 {

   […]

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

   […]

@Override
@Programmatic
public String tenancyPath() {
return TENANT_PATH_UNIVERSAL;
}
}


When an entity returns a “tenancyPath” of “/accounts/” 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
 






> El 23 feb 2016, a las 18:37, Jeroen van der Wal  
> 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  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

[Jeroen van der Wal]

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

multiple tenancy/scoped roles in ISIS security

[David Soff]

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: Overriding a field in a view model

[Vishma Senadhi Dias]

Thanks Dan. It worked. Using a mixin is much better for my approach.

Thanks a lot.
On 2/23/2016 12:15 PM, Dan Haywood wrote:

Hi Vishma,

It you can't change the original class - because it was written for some
other purpose - then perhaps it might be better to wrap it in a view model
of your own control.  I'm not certain that overriding getBookType() is
going to work, because it would impact any other users of that view model.

One way to achieve your objective would be to use LibraryMember.layout.json
to hide the original getBookType(), and then define a mixin to expose your
decode.

@Mixin
public class LibraryMember_decodedBookType {
  private final LibraryMember libraryMember;
  public LibraryMember_decodedBookType(LibraryMember lm) {
this.libraryMember = lm; }

  @Action(semanticsOf=SAFE)
  @ActionLayout(contributed=AS.Association)
  public String bookTypeDecoded() {
  return libraryMember.getBookType().equals("N") ? "Novel": "Misc";
 }
}

HTH
Dan






On 23 February 2016 at 06:30, Vishma Senadhi Dias 
wrote:


Hi all,

I have a jaxb annotated view model which have several fields with getters
and setters. I want to override the getter of a specific field so that
different value will appear on the UI. But the original getter should not
be changed.

example:

|public class LibraryMember { private String bookType; public String
getBookType() { ... } public void setBoookType(String bookType) { ... } }|


In the above example, can I override getBookType() so that a different
value will render on the wicket viewer? I should be able to update the
getter like this,

|public String updateBookType( if(this.getBookType.equals("N")) return
"novel"; else return "Misc";  }|



I have restrictions like I cannot change the original class. Can I use a
DomainService or some other inbuilt implementation of ISIS to achieve my
objective without altering my original class?
Any help would be highly appreciated.

Thanks in advance,
Vishma.