On Oct 30, 2007, at 9:22 AM, Alex Karasulu wrote:
Hi Emmanuel,
On 10/29/07, Emmanuel Lecharny <[EMAIL PROTECTED]> 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
