directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: [TSec convos]
Date Tue, 30 Oct 2007 21:51:41 GMT

On Oct 30, 2007, at 9:22 AM, Alex Karasulu wrote:

> Hi Emmanuel,
>
> On 10/29/07, Emmanuel Lecharny <elecharny@gmail.com> wrote:
> Hi David, Alex,
>
> I just read a dozen of mails about TSec and very high level discussion
> about what is a Role, User, Permission, Group, etc...
>
> Those mails are really interesting, but there is some things that  
> bugs me :
> - I don't see any alignement coming from those mails
>
> We're trying hard.  I had a conversation with David over Skype the  
> other day.
> I think we have some fundamental differences regarding how we will  
> use Roles
> and Groups.

I can't tell if we have fundamental differences because I think we  
are nearly completely failing to communicate our ideas to each  
other.  I'm pretty sure I'm not getting my ideas across to you, and I  
suspect I'm misinterpreting your ideas.  To me it seems like I am  
thinking in terms of an abstract model that can be implemented in  
several ways including using existing concepts such as AD groups and  
that you are thinking that the model has to have the same concepts as  
existing systems, which seems to me to be a lower level of  
abstraction.  Anyway instead of trying to write an essay that perhaps  
no one will understand let me see if I can respond to what you've  
written here.

>
> David:
>     Summary: Groups should be modeled as Roles.
>
>     Users will be added to roles which only have users, i.e.  
> Roles<Users>, and roles
>     with only permissions Role<Permission> are assigned to  
> Roles<Users> to make
>     them obtain the permissions associated with the  
> Role<Permission> through Role
>     hierarchy.

I don't know what you mean by Roles<Users> and Role<Permission>.  I'm  
proposing that we think of a role as a named thingy that has  
permissions associated with it, users associated with it, and "sub- 
roles" associated with it.  The "sub-roles" set up an inheritance  
relationship among the roles.  It is possible for roles to have no  
users associated with them, no permissions associated with them, or  
no sub- or super-roles associated with them; however unless they have  
at least 2 of these they won't be useful for connecting users with  
permissions.  I'm not saying anything about how the data store behind  
this is set up or how much of it is in a tsec schema or editable  
through tsec.  I'm also not saying anything about how roles are  
presented in any UI tsec may have.  For instance, I have no problem  
with calling roles groups whenever you are associating users and roles.

>
> Alex:
>    Summary: Groups are distinct from Roles.  Roles should not  
> contain Users and
>                    are merely a set of permissions or permissions  
> and other roles.
>
>     User can be added to groups: Group<Users>.  A user or a  
> Group<User> can be
>     associated with something called a RoleAssignment which assigns  
> one or more
>     Role<Permissions> to that user or group.  Roles only contain  
> permissions.  Groups
>     contain users with clear separation.

The last time we talked I thought you were proposing allowing user- 
role assignments as well.

To me there are 2 separate questions that we should consider separately:
1. as abstract models, which one is simpler and more flexible?
2. how hard is it to implement each model so it interoperates with  
existing systems such as AD and existing admins will be willing to  
use it?

It seems to me that after we have some ideas about answers to both  
these questions we will be better able to pick what to do.  For  
instance, if we decide one model is simpler, more flexible, and  
easier to implement, its the obvious choice.  If one model is more  
complicated and limited but easier to implement in a way acceptable  
to admins, we have a harder choice.

1. I think its pretty clear the roles-only model is simpler.  It has  
one fewer kind of entity (no groups) and depending on whether the  
group model has group hierarchies and direct user-role associations  
one, two, or three fewer kinds of association. (group-role  
associations, group-group containment, and user-role association).   
Next,  here's how to convert a group-roles model to a roles-only model:

- all the groups become roles.  user-group associations thus turn  
into user-role associations.
- the group-role associations become role-role inheritance relations.
- the (optional?) group containment relations turn into role-role  
inheritance.  Note that the relationships might appear to go the  
other way now :-).  The more users, the fewer permissions, and the  
more permissions, the fewer users.

So, I think this means that any group-roles model setup can be  
thought of in terms of the roles-only model without losing capabilities.

Furthermore, all these setups from groups-roles have a constraint on  
them: some of the roles don't have any permissions (the ones that  
used to be groups).  By at least conceptually allowing for any role  
to have permissions associated to it we've made the model more flexible.

I know I haven't been expressing myself very well but this is most of  
what I've been trying to talk to alex about.  I must be leaving out  
some big background about my presuppositions since this much seems  
fairly clear to me.  Remembering that at this point I am explicitly  
not talking about how the data might be stored or where or how any  
management UIs might look or refer to concepts here I wonder what  
people think of this reasoning.

2. So, I think the role-only model is conceptually simpler and more  
flexible, but I really don't know how practical it is to implement so  
e.g. AD groups appear as (read-only) roles in tsec and any UIs are  
similar enough to what admins are used to so they are happy using  
them.  I have a lot of ideas, but there's no point discussing them if  
no one else is willing to consider the possibility that considering  
implementing a roles-only model partly on top of say AD is a  
reasonable idea.

Lets look for a moment at one possible integration of AD with Tsec.   
All the users are in AD, and they are organized into (hierarchical?)  
AD groups. Tsec will need to store a AD group- tsec Role association,  
and an AD user - tsec Role association (at least for roles-only  
tsec).    When we write code to deal with this data, in the role-only  
model the ldap AD-groups and tsec-roles would all go into role  
objects, the AD-group to AD-group containment, the AD-group to tsec- 
role and tsec-role to tsec-role inheritance would all go into the  
role-role graph, and the AD-user to AD-groups and AD-user to tsec- 
roles would both go into the user-roles association.  In the group- 
role model, we'd have more kinds of objects but simpler ldap-code  
mapping.

On the other hand, if someone wants to use tsec without any  
integration to an existing system,  in the role-only model the tsec- 
ldap to object mapping would be completely straightforward and,  
having fewer things to deal with, simpler than the group-role tsec  
model.

I don't know which approach would be better, but I do think it is  
worth considering.


>
> - we do have a working version of TSec, but it only works with ADS  
> 1.0,
> so I think that the urgence is to get TSec migrated to fit ADS 2.0
>
> Yes this would be a good path and this is what I originally  
> suggested we do with
> David. I don't think this interested him very much.

I've been working on and off for almost a year on my sandbox branch  
and it works with ADS trunk and implements a lot of features I think  
we want such as hierarchical roles.  I'd prefer that my work get  
reviewed and considered before being thrown out.

>
> - I'm not sure that changing a hell lot of code in a branch will  
> help a
> lot, unless if used as a proof of concept.
>
> +1
>
> I understand that some of use need to code to expose their ideas, and
> that other really like to write doco before coding, we are all
> different. The problem is that at some point, there is an existing
> project, called Tsec, which is stalling. If there is no alignement of
> ideas, no common agenda, no baby steps done, then there is no way  
> to get
> the job doen, as it will end as a battle of ego.
>
> I agree with everything up to the ego part :).  I don't care how  
> (my or another person's
> way) we do this as long as we get it relatively right.
>
> We're trying to settle a disagreement in how to proceed.  Again  
> it's less about doing it
> my way than really screwing up Triplesec. David IMHO is a bit  
> myopic but I don't blame him
> since there is a lot of material that makes it hard to see the big  
> picture especially to
> validate what we're doing at lower levels.  However what  
> disappoints me is his reluctance
> to see some basics to push in a certain direction.  I think he  
> thinks I'm myopic because I
> resisted the XBean changes initially but I don't think he realizes  
> that this was just
> due to a lack of time to evaluate his proposal.  He has  
> insufficient data yet by
> forcing himself to make conclusions now he's coming to the wrong ones.
>
> I know without a doubt that if we go with David's approach we're  
> going to shoot ourselves
> in the foot.  From the administration point of view no organization  
> is going to manage users
> in Roles instead of Groups.  Then merge those Role<User> objects  
> with Role<Permission>
> objects to grant users roles.  This is just suicide from a product  
> viability standpoint.
>
> Plus this creates serious issues when integrating with external  
> systems which serve as the
> credential store and database of record for the enterprise.  Active  
> Directory is used 90+% of
> the time and we need to allow for Triplesec to refer to the groups  
> and users defined there.
> We simply cannot model our groups as Roles without lots of  
> unnecessary work to migrate
> Active Directory (LDAP) Groups into our internal Role representation.

To me it seems like you are assuming some implementation decisions  
and ruling out the possibility of a point of view or model based on  
those assumed decisions.  There are lots and lots of possible  
implementations and some may be more appropriate in different  
situations. I implemented one possibility that seems reasonably  
appropriate for a tsec-only system or when its used as a jacc  
provider with external group data replicated into a local tsec- 
adapted copy.  I outlined another possibility above.

>
> In my new approach, which I have modified from studying 3 other  
> commercial systems,
> I found that referring to groups and users in a RoleAssignment is  
> the best option.  In the
> end we have 3 kinds of actors:
>
> (1) operators/administrators
>      - add, remove users
>      - add, remove users from groups
>      - often use tools for external systems (mainly ActiveDirectory  
> in enterprise) to do this
Can these people assign any user to any group or are there  
permissions they need for some groups?   For instance, is there ever  
a situation where there's a "distribute executive bonus" group, and  
joe peon the admin can't assign the new mailroom employee to that group?

In the role-only model this would be
- add, remove users
- add, remove users to roles (which might be called groups whenever  
you see a user and role together; this is a UI question)
- if AD groups are viewed in tsec as roles, the AD tools would still  
work on their portion of the data.

>
> (2) policy makers (technical security officers??)
>      - determine which groups are assigned to specific roles
>        (will make the RoleAssignments)

In the role-only model this would correspond to setting up the role  
inheritance hierarchy.
>
> (3) developers/app architects
>      - determine the roles and permissions in their applications
makes sense to me.
>
> This is the division of labor most commonly encountered.  I've seen  
> it repeatedly across the
> enterprise. Together these folks manage the aspects of  
> authorization policy in moderate to
> large scale companies.
>
> Triplesec must not force operators (1), to use Triplesec when they  
> use AD.

I surely never meant to say they did.  I do think we ought to support  
tsec-only systems as well, which I think means we need to supply  
tools for user admin and user-[role-or-group] assignment as well.

> This and other
> requirements are not even on David's radar.  He's thinking in a  
> vacuum when he needs to
> look at the big picture.  He thinks users can be forced to change.   
> This is not a philosophy
> that works well.
>
> May I suggest that we start porting TSec to get a ADS-trunk
> compatinbility right now, and then trying to make it work smoothly as
> is? I would also appreciate that before doing any change in this code,
> there is at least a minimal agreement reached, otherwise it will end
> with 3 or 4 different incompatible versions...
>
> Yes I agree with this approach.
>
> So far, this is the way we have successfully worked in the past 3  
> years,
> without any single argument, and I wish it is possible to continue  
> like
> this...
>
> Yes indeed we've done well.
>
> I've concluded I am wasting too much time now.  I could have fixed  
> Triplesec
> in trunk and corrected some of it's known flaws by now.  However  
> this is
> important from a community standpoint.
>
> I would add that Tsec has been written by Alex, and so far, as he also
> started ADS, which is quite a pretty smart piece of software, I'm
> inclined to think that Alex is trustable... Alex also is good at
> considering other people's view points giving them a chance to
> participate and drive development, and he knows he makes mistakes and
> listens to others, which is one of the reasons why we stand by him.
>
> Unfortunately I don't think this will factor into David's decision  
> regarding
> Roles and Groups being one and the same. David is very convinced  
> about his
> approach.  Let me point out he is very polite but just very  
> stubborn :).  I like him
> a lot though so I keep trying to understand his view points.
>
> But at some point I'm going to have to stop because it's consuming  
> too much
> time.
>
> Bottom line, there is nothing personnal about it.
>
> +1 not at all.  Actually our discussions are fun and we laugh about  
> the differences.
> We're still having fun and that's the indicator that there is no  
> issue at all. Well besides
> the fact that we're all bound by time.
>
> It's just that we have
> an agenda, which is pretty heavy, and we need to keep some focus. I'm
> afraid that losing time discussing on the very basis of Tsec just make
> Alex losing a lot of time, and this harms the whole project. This is
> pretty much more a priority issue...
>
> Yes as you know I could not help a couple of you guys because of  
> the time lost just debating
> the same things back and fourth.
>
> At this point we need some feedback from others to help us get out  
> of this deadlock.  David
> promised to just discuss the problem within my threads on the topic  
> in clear language not
> intended to be a specification without being biased by the NIST  
> paper.  We're just going to
> discuss the problem and the entities that exists to manage  
> authorization policy today using
> the IT vernacular.
>
> I will keep looking at his branch while we (off line) review the  
> NIST paper together paragraph by
> paragraph to settle our misaligned interpretations. I think this is  
> the best I can do at this point.
>
> Input from you and others will also help us.  What people's  
> thoughts regarding Roles and
> Groups?

More input would be great. In particular I really want to know if  
I've missed something in my arguments.

thanks
david jencks

>
> Alex
>
>
>
>
>


Mime
View raw message