> On Oct 12, 2016, at 2:19 PM, Chris Pike <clp...@psu.edu> wrote:
> 
> We need ability to delegate permission->role assignment in any conceivable 
> way. The only way to do that currently would be to make permission objects 
> unique (account.reset) and have "dummy" operations (do) with unique Perm OUs 
> (IMO this is an incorrect usage pattern for Perm Objects and would require us 
> to basically ignore operations). 

Chris, I realize you don’t mean this literally, no way our delegation model 
will ever work in every way.  What can it do today, or perhaps more aptly, what 
should it do is the question we’re pondering.

The only way to answer is by applying the design to concrete use cases that 
capture the scope and complexity of the problem.  Next we’ll ‘whiteboard' an 
entity model that solves the exact problem as described, look at its pros/cons, 
examine alternatives, and decide whether to implement.

Right now we’re prescribing changes to an entity model without a clear 
description of the problem.  It’s not that I doubt that this problem is valid, 
I don’t.  It’s that I don’t understand it, and can’t help in the solution.

> 
> On Oct 12, 2016, at 2:19 PM, Chris Pike <clp...@psu.edu> wrote:
> 
> Since this will be used in the enterprise with 1000's of permissions, this 
> would result in 1000's of PermOUs and ARBAC roles that each point at dozens 
> of PermOUs (at this point, why even have PermOUs? we could just make ARBAC 
> roles point directly at permissions).

This is better, we’re getting into specifics.  Let’s take a sampling of 10 or 
20 of these permissions, along with their associated data elements and use that 
as our sample use case to build a solution.

> 
> On Oct 12, 2016, at 2:19 PM, Chris Pike <clp...@psu.edu> wrote:
> 
> As to if it is better for adding new perms... it moves pain point of having 
> to update ARBAC roles to having to update the new permissions PermOU list. 
> This may or may not be better depending on how fortress is being used.

Exactly.  It depends.  But we can set limits.  For example, we can’t break 
existing arbac funcs.  We don’t want to introduce new pain points either.  So 
the goal is to produce a use case that proves to us that data fans out 
unacceptably, and with the proposed changes it doesn’t.

Thanks,
Shawn

Reply via email to