Oscar, Jeroen and I were discussing isis-module-security... archiving to the dev@ list .
Thursday, 4 September 2014: > *Dan Haywood* - 08:21 > Hi Oscar, Jeroen and I were just discussing what you meant by "priority" > for resolving permission conflicts. > Have you the time right now just to explain? > > *Óscar Bou* - 08:22 > I was just writing an email :)) > to the Isis list > I'm going to copy here what I had > > I think there are potential conflicts like the ones: > > 1. - If we use the principle of "Security by Default", a user is vetoed > from using all features. So needs to be assigned to one or more roles to > being able to do "anything". > 2. - Features have an explicit hierarchy we can use for precedence: > - Level 1: Package directives/permissions. > - Level 2: Class permissions. > - Level 3: Properties / collections / actions. > > I can only imagine conflicts between: > - Contradictory permissions at the same level in two different > ApplicationRoles assigned to the Application Users (i.e., Role > "Administrative" is vetoed to access any class on the "com.todo" package, > while Role "Administrative Manager can see it). > - Contradictory permissions at different levels of the hierarchy (i.e., a > Role "Administrative" is vetoed to access any class on the "com.todo" > package, while Role "Administrative Manager can "change" > "com.todo.ToDoItem" ). > > *Dan Haywood* - 08:27 > Regarding (1), we have that already. A user can do nothing if has no > roles. > Regarding (2), we also have that. Member permissions take precedence over > class permissions, that take precedence over package level. > > *Óscar Bou* - 08:27 > that's perfect > nice > > *Dan Haywood* - 08:28 > A conflict could arise if the user had two permissoins at the same level, > eg VETO Customer#firstName and ALLOW Customer#firstName. > Right now the ALLOW wins. > But, we could easily externalize that algorithm into an optional pluggable > domain service. > > *Óscar Bou* - 08:29 > ok, but perhaps a global option indicating if in case of conflict VETO or > CHANGING takes precedence would be enough for most use cases > > *Dan Haywood* - 08:31 > Yeah... well registering a simple service would be equivalent. The issue > with a global option is simply that we haven't really defined a domain > service for reading out of isis.properties. > > *Óscar Bou* - 08:31 > that's perfect > I had more suggestions > - Due to multi-tenancy, Roles (optionally) by Tenant. Perhaps > an optional "Tenancy" property is enough to "mark" a Role as a "global" > role (for all multi-tenants) or as a specific "tenant role". > each tenant must be seen as an "isolated" customer. So possibly it will > want to create it > its own roles, permissions, etc. > Despite that, "global administrators" will need "global permissions" > over all tenants > > *Dan Haywood* - 08:36 > hmm, interesting thought. > > *Óscar Bou* - 08:37 > ok. so also Roles hierarchy (Hierarchical RBAC), meaning a Role can have > "sub-Roles". That way, you can model roles as equivalent hierarchical > structures on your company > On this document a lot of RBAC-based designs are discussed and compared: > http://csrc.nist.gov/rbac/rbac-std-ncits.pdf > <http://www.google.com/url?q=http%3A%2F%2Fcsrc.nist.gov%2Frbac%2Frbac-std-ncits.pdf&sa=D&sntz=1&usg=AFQjCNHcfwJLwS-myOdT2Gd5uU4rxOxPIg> > > *Dan Haywood* - 08:38 > Tenanted roles and perms makes sense, > Hierarchical roles I thought about, but it's pushing the scope of what we > need right now in Estatio. Trying to apply a bit of YAGNI. > > *Óscar Bou* - 08:42 > ok > - Per-instance security. It should introduce the concept of > "owner" of an instance (the one that created), and perhaps the concept of > "team" or "group" (being the set of users/roles with access to that > instance). > > *Dan Haywood* - 08:43 > Yeah, we're just discussing this now. > In Estatio we have Italian shopping centres (Properties), French, Swedish. > If evaluating whether a user can view a particular feature of an Italian > Property, should evaluate all permissions of their italian roles and of > their global roles. > Should ignore any swedish or french roles etc. > To do that requires extending Isis' Shiro integration. > Currently Isis constructs a string representing the feature to be > viewed/changed, eg "org.estatio.assets.Property#description" > That would need to be extended to indicate the tenancy, eg: > ITALY:org.estatio.assets.Property#description. > I think it's quite doable > In isis.properties, this tenancy-aware authorizor would need to be > registered, ie: > isis.authorizor=org.isisaddons.module.security.TenancyAwareAuthorizor > or something like that. > > *Óscar Bou* - 08:46 > I like it, and found absolutely needed to identify the tenant > regarding "excluding" roles from evaluation as you told before, I thought > it was just a matter of evaluating the roles assigned to the user. The > "italian user" will not be assigned to any "swedish" roles (despite can be > assigned to "global" roles). So the "swedish" role will not be evaluated > simply because it will not be included in the user's roles collection, > isn't it? > > *Dan Haywood* - 08:48 > Just discussing all the different permutations here online with Jeroen. > It could all get quite complicated. > I'd rather do the above, and then tighten up the rules about whether an > italian user can have swedish roles etc later. > > *Óscar Bou* - 08:51 > ok. To one user only "global" roles or roles from its same tenant can be > assigned > > *Dan Haywood* - 08:52 > The way I'm considering this right now is that an "Italian user" really > means that the application itself (not the security subsystem) can use that > information to filter the data that's available to them. > So an italian user can only see italian Properties. > But we wouldn't prevent an italian user to be assigned a swedish role. > It'd be a bit nonsensical, because that role would never be applied. > But it wouldn't cause any harm. > > *Óscar Bou* - 08:53 > Sure it wouldn't hurt, as the user would never be logged in as a > "swedish". > That was the next question. Multi-tenant repositories > That implies that a filter is applied mandatory to any query (unless we > admit "global" users) > > *Dan Haywood* - 08:55 > OK. Finishing off the above conversation, we'll add "tenancy" as an > attribute of role; all permissions of that role are for that tenancy and > are used in the evaluation of access to a tenanted piece of data, eg > italian property. > > *Óscar Bou* - 08:56 > ok > > *Dan Haywood* - 08:56 > Slight possible snag... need to ensure that Isis' authorizor is able to > get the information about the target object as being italian, swedish etc. > Need to confirm the internal Isis APIs there. > > *Óscar Bou* - 08:57 > Only one thing. With the current design, a Permission will refer to ALL > instances of a given entity > so it's still not possible to have per-instance security > > *Dan Haywood* - 08:58 > Yeah, indeed. > > *Óscar Bou* - 08:58 > there's no way to specify a permission as an evaluation over the current > instance > > *Dan Haywood* - 08:58 > Think that multi-tenancy per-instance security might be something to add > to a later release. > > *Óscar Bou* - 08:59 > in a similar way the string interpolator evaluates strings, it would be > needed to evaluate expressions that returns a boolean > > *Dan Haywood* - 08:59 > There's enough useful stuff to release, and making it available means we > can learn more by using it. > > *Óscar Bou* - 08:59 > sure! > > *Dan Haywood* - 09:01 > OK, very useful. I'll archive this hangout as the basis for a couple of > new tickets on [isis-module-security] > > *Óscar Bou* - 09:01 > ok > Thanks! > > *Dan Haywood* - 09:02 > Cheers. Bye for now. > > *Óscar Bou* - 09:02 > Bye! > sorry! simply a link perhaps you find interesting > https://www.mind-it.info/nist-rbac-data-model/ > <https://www.google.com/url?q=https%3A%2F%2Fwww.mind-it.info%2Fnist-rbac-data-model%2F&sa=D&sntz=1&usg=AFQjCNFUIdur54ODqiy3N4ZiP2XKzy3-QA> > bye ! > And the second version > https://www.mind-it.info/nist-rbac-data-model-update/ > <https://www.google.com/url?q=https%3A%2F%2Fwww.mind-it.info%2Fnist-rbac-data-model-update%2F&sa=D&sntz=1&usg=AFQjCNFwamluMPSso9FEsU2V-W2HWffsdg> > cheers!
