directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pike <clp...@psu.edu>
Subject Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)
Date Wed, 12 Oct 2016 19:19:51 GMT
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" <smckinney@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 <clp207@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?

Mime
View raw message