directory-fortress mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn McKinney <>
Subject Re: ARBAC Perm OU change proposal (was Access Manager Role Filtering)
Date Tue, 11 Oct 2016 18:58:00 GMT

what you are proposing is not trivial and will require a bunch of work.  That being said I
want to make sure that your use case is broadly applicable before we commit a bunch of work
and possibly break existing functionality.

Which is why I am playing the skeptic here so bear with me...


So we are saying the role groups have now become a necessary part of your model?  If ‘no’
what then becomes of this use case wrt multi-occurring permous?  How do we ensure that we
don’t introduce inconsistencies to how it works today?

As long as we’re asking open ended questions…

Have you exhausted all possibilities of the existing model?

To answer this question let’s walk away from the contrived use case and move into one that
is relevant.  Describe a use case you are facing today that won’t work with current model
but will with this proposed change.

One more request.  Have you looked at the ARBAC02 paper?  Maybe there is something there that
we have missed that will help.  How does your change fit in with the original model.  Does
it compliment or detract?

I guess what I am trying to say is let’s make sure the existing model is broke before we
invent a new one.  If we change it, we own it, and are forever on the hook for the ‘why’
rather than just sending a link to the model and saying we do that.


> On Oct 11, 2016, at 12:08 PM, Chris Pike <> wrote:
> AR1 could only revoke R1, R2, and R3 if it's role range (or role group, which we plan
on adding to add to ARBAC roles) allowed.
> Role Groups: RG1, RG2, RG3
> Roles: R1 (RG1), R2 (RG2), R3 (RG3)
> AdminRoles
> AR1 - P01 / RG1
> AR2 - P02 / RG2
> AR3 - P01, P02, P03 / RG3
> Only someone in AR1 could remove "sleeper" from R1
> Only someone in AR2 could remove "sleeper" from R2
> Only someone in AR3 could remove "sleeper" from R3
> ----- Original Message -----
> From: "Shawn McKinney" <>
> To:
> Sent: Tuesday, October 11, 2016 9:35:30 AM
> Subject: Re: Access Manager Role Filtering
>> On Oct 11, 2016, at 7:24 AM, Chris Pike <> wrote:
>> Not sure if I understand your questions about how can one set of roles be associated
with a perm with multiple OUs. The Perm OUs are just an ARBAC thing correct?
> Yes, but there are semantics here that need to be understood.  
> This discussion is too complicated in the abstract.  We need use cases.
> For example:
> Roles:  R1, R2, R3
> Perm OUs : P01, P02, P03
> AdminRoles
> AR1 - P01
> AR2 - P02
> AR3 - P01, P02, P03
> Perms
> PermObj: foo
> op: fighter: ous:(P01), roles(R1)
> op: eater: ous:P02), roles:(R2)
> op: sleeper: ous(P01, P02, P03) roles(R1, R2, R3)
> So we have 3 perms, the first two are typical, the last one, foo.sleeper is not as it
has multiple perm ous associated with it.
> Now let us consider the operation:
> boolean canRevoke(Session session, Role role, Permission perm) throws SecurityException
> Any administrator that has any of the adminroles listed could revoke any of foo.sleeper’s
roles.  e.g. admin AR1, could revoke R1, R2 and R3.  Is that desirable behavior?
> Shawn

View raw message