Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Shawn McKinney]

> On Oct 13, 2016, at 9:16 AM, Chris Pike  wrote:
> 
> I think it would be worth us having a phone call and walk you through some of 
> our screen mock ups so you can get a better idea of what we are trying to 
> accomplish.

Agreed with the product of that discussion a document that describes these use 
cases, and corresponding sample data, so others may follow along.  As the 
saying goes, if it didn’t happen on a public mailing list, …

Thanks,
Shawn

Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Chris Pike]

Shawn,

I think it would be worth us having a phone call and walk you through some of 
our screen mock ups so you can get a better idea of what we are trying to 
accomplish.



- Original Message -
From: "Shawn McKinney" <smckin...@apache.org>
To: fortress@directory.apache.org
Sent: Thursday, October 13, 2016 9:15:53 AM
Subject: Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

> 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

Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Shawn McKinney]

> On Oct 12, 2016, at 2:19 PM, Chris Pike  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  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  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

Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Chris Pike]

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

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. 



- Original Message -
From: "Shawn McKinney" <smckin...@apache.org>
To: fortress@directory.apache.org
Sent: Wednesday, October 12, 2016 10:18:44 AM
Subject: Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

> On Oct 12, 2016, at 9:03 AM, Chris Pike <clp...@psu.edu> wrote:
> 
> If the Permission is added to existing PermOUs, then any ARBAC roles pointing 
> at that PermOU don't need updated.

So what about this new approach helps with adding new perms - why is it better?

Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Chris Pike]

If the Permission is added to existing PermOUs, then any ARBAC roles pointing 
at that PermOU don't need updated.



- Original Message -
From: "Shawn McKinney" <smckin...@apache.org>
To: fortress@directory.apache.org
Sent: Wednesday, October 12, 2016 9:03:53 AM
Subject: Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

> 
> On Oct 12, 2016, at 7:52 AM, Chris Pike <clp...@psu.edu> wrote:
> 
> 
> To answer your question, a new permission would be in a new PermOU that no 
> existing ARBAC role could have jurisdiction over. So every relevant ARBAC 
> role would have to be updated.

Wouldn't that situation still occur regardless?  What about a multioccur ou 
that bypasses this problem?

Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Shawn McKinney]

> 
> On Oct 12, 2016, at 7:52 AM, Chris Pike  wrote:
> 
> 
> To answer your question, a new permission would be in a new PermOU that no 
> existing ARBAC role could have jurisdiction over. So every relevant ARBAC 
> role would have to be updated.

Wouldn't that situation still occur regardless?  What about a multioccur ou 
that bypasses this problem?

Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

[Chris Pike]

I created two new issues, FC-195 and FC-196

To answer your question, a new permission would be in a new PermOU that no 
existing ARBAC role could have jurisdiction over. So every relevant ARBAC role 
would have to be updated.


- Original Message -
From: "Shawn McKinney" <smckin...@apache.org>
To: fortress@directory.apache.org
Sent: Tuesday, October 11, 2016 6:21:45 PM
Subject: Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)

Ok this is good.  Let’s get a ticket opened with this info.  That way of we 
don’t have to fish around our email for it later.

I’m still working my way thru it but had a quick question below….

> On Oct 11, 2016, at 4:11 PM, Chris Pike <clp...@psu.edu> wrote:
> 
> 
> End State:
>   account.create.do -> POU1
>   account.reset.do -> POU2
>   account.delete.do -> POU3
>   AR1 -> POU1
>   AR2 -> POU2, POU3
>   AR3 -> POU1, POU2, POU3
> 
> Issues / Notes:
>   - A one to one mapping between Permissions and PermOUs
>   - Adding a new permission may require updating many ARBAC roles

Why would adding a new permission require updating many roles?

Thanks,
Shawn