Re: [Triplesec] [AuthZ] Role Assignment

[Alex Karasulu <ak...@apache.org>]

Hi David,

Again I am condensing out the agreed to points ...

On 10/31/07, David Jencks < david_jencks@yahoo.com> wrote:
>
>
> On Oct 30, 2007, at 10:32 PM, Alex Karasulu wrote:
>
> Hi David,
>
> On 10/30/07, David Jencks < david_jencks@yahoo.com> wrote:
>
>
...

I figure that if we decide that groups as distinct from roles are not
> conceptually necessary, even though they are in most existing systems, we
> can then think about whether it's practical to write code that only uses
> roles, not groups.
>

We can do that but do we want to?  Will it be beneficial?

This is an optimization problem so we can give up clarity in the model's
ability to represent real entities to make implementing that model in code
easier.  This is what
you are proposing.

We can create any model we want to.

However my whole point is, I don't want to give up clarity no matter how
easy the code gets.
That's not an option for me.

My turn to flame :-),

<flame>

I don't know if this is practical,
>

OK so respectfully then, I ask that you stop wasting time pushing this
point. You admit
here that you don't know if it is practical.

And please stop presuming I don't know what I am talking about. I do know
that it is
not practical.  I'm not lying here guy.

 but I think it's worth thinking about without throwing up our hands and
> saying its too hard.
>

(1) I've been thinking about this for weeks giving you the time you
requested to discuss
     your points and consider your views.

(2) I think you mentioned yourself that it is harder to code with my
approach which differentiates
     groups from roles.  Note its also easier to code a model where
permissions can only be directly
     added to users but I'm not going to do that since the result would not
be optimal nor RBAC.

I stepped back and put down my inherent leverage as a senior member here and
as one who
has done this several times.  I have a long history along these lines where
I've learned from
several mistakes.

I humbly engaged you for a long time.  I dropped any advantage that a
meritocracy gives me.
I could have at any point after having in earnest tried to understand you,
say OK sorry but I'm
going to have to do it this other way due to time constraints.  I even tried
hard to get third parties to
say something in case I'm totally out of my gourd.  I hope you see that I'm
willing to be
corrected.  At this point I'd rather be shown I am wrong, then continue
pissing away time.
Unfortunately there is nothing that shows my being incorrect in your points.

So let me be clear. I don't have to "throw my hands up" and say anything at
this point.
</flame>

For instance, it might be possible for our role objects to be backed by
> either tsec roles (in the part of ldap we control) or AD groups.  Obviously
> the role objects backed by AD groups are likely to be read-only from tsec.
>

Hmmm read-only ... maybe there's a way around that :).

Plus it's just not natural. Groups exist.  Roles exist.  They are not the
> same to the majority
> of administrators out there.  So why push it if it's going to alienate
> people and create more
> problems and work for us.
>
>
> Isn't this a UI question?
>

Not if we consider more than just administrators.  People like me are going
to have
to deal with translating natural concepts into the convoluted optimization
you've found
to make the code easier to manage for you.

Administrators are not likely to be poking around in our code to see what we
> named our objects.
>

Well I will and others will.

What if whenever you get to group users together or construct a "group
> hierarchy" we call the unnameable object a group and whenever you get to
> associate permissions to it or construct a "permission hierarchy" we call it
> a role?
>

This is fine if it is across the board.  It's a problem when this is only in
a GUI.  These things
will be reflected in public APIs.

So the exposure has greater surface area and is more than just the GUI.


> My approach now after analyzing existing products is to use a
> role-assignment
> not only to users but to groups.  Hence a role-assignment associates
> either a user
> or a group with a set of roles.
>
>
> If we have groups, we obviously need to associate groups with roles.  If
> we agree to call the "groups" roles, the group-role association becomes part
> of the role hierarchy.
>

I understand that from the standpoint of simple mechanics, this will work.
However from the
standpoint of model clarity and consistency with our users, administrators
and the majority
of developers using our API's (not to mention us) it will not fit.  It will
create more chaos
than it's worth.  Let's grok the code and make sure we have no problem.

> Now if I
> > understand what you are proposing it is to have a "group" which has a
> > set of users associated with it (like a role) and has roles
> > associated with it.
>
>
> No the group is just a group.  It sits out there.  The role-assignment is
> what is our
> join table used to associate the group with the roles.
>
>
> I'm not claiming that the association is stored in any particular place.
> If you want to claim that the role-assignment is an object then we will have
> to make all the associations objects so we don't bias the discussion by
> implementation details about which end of an n-n relationship we store the
> pointers.
>

This is not making sense to me here.

The creation of a role-assignment object is the least bias you can have
since it removes the
directionality by putting the associations in objects other than groups or
roles.  It decouples
us from being at a particular "end of an n-n relationship."

Did I miss something?

...

> It's not just some ONE else.  It's the majority of systems out there.  I'm
> telling
> you that by pissing straight against the wind on this one your going to
> have us wet
> and dirty :).
>
> Let's look again at the division of labor:
>
> (1) operator/administrator
>
>      - creates, deletes, modifies users
>      - creates, and deletes groups
>      - adds and removes users from groups
>
>
> so AFAICT the model I'm talking about supports this just fine, provided
> the UI these people use labels the roles "groups".
>

What about our API's?  Are our API users going to need API's that refer to
roles or groups?  Where
does this end?

When you hire joe, you have to  group him with the other people who do the
> same kind of work.  Whether we call the object a role or a group, its the
> same amount of work.
>

Regardless of the amount of work point which you seem to flip-flop on it is
confusing.

(2) policy maker (technical security officers)
>
>      - create, delete, role assignments
>
> I think these are the group-role associations?  To me these are some of
> the role-role hierarchy relationships.
>

Yes these are group-role or user-role associations.

>      - create, delete role exclusions (for static separation of duty)
>
> (3) application architects (engineers & developers)
>
>      - create, delete, modify permissions
>      - create, delete, modify role names
>      - add, remove permissions from roles
>
>      With role hierarchies:
>
>      - add, remove roles from roles
>
>
> I agree with all these tasks.  I don't agree that they favor or disfavor
> having groups in the model.
>

...

> Having multiple named role-assignments accomplishes this same goal.
>
>
> Maybe.  If these are group-role assignments I think this is a much more
> complicated harder to understand way of implementing separation of duty
> constraints.
>

Perhaps but it works for user-role assignments since this defaults to what
we call a profile.

If we have groups I think having a session that contains the currently
> active groups and (directly assigned roles) will be much easier to implement
> and understand than trying to do SOD at the group-role assignment level. I
> could be wrong but I think this might well outweigh the difficulties in
> writing java-ldap mapping code from a role object to both ldap roles and
> groups.
>
> Anyway I'm not sure we need to implement all of SOD right away.
>

Maybe but we should think about it so we don't prevent it's proper
implementation down
the line when we're ready to introduce it.

Well I'm sure you completely agree with my arguments by now :-)
>

:-)  Sorry I don't but I sure wish I did - it would cost much less.

but in case you don't :-D I wonder if we can move forward anyway?
>

Yes I think it's time now to move forward and do it the way I and others
seem to agree with.
Are you on board?

Alex