directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [TSec convos]
Date Tue, 30 Oct 2007 16:22:18 GMT
Hi Emmanuel,

On 10/29/07, Emmanuel Lecharny <> 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
I think we have some fundamental differences regarding how we will use Roles
and Groups.

    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
    them obtain the permissions associated with the Role<Permission> through

   Summary: Groups are distinct from Roles.  Roles should not contain Users
                   are merely a set of permissions or permissions and other

    User can be added to groups: Group<Users>.  A user or a Group<User> can
    associated with something called a RoleAssignment which assigns one or
    Role<Permissions> to that user or group.  Roles only contain
permissions.  Groups
    contain users with clear separation.

- 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
David. I don't think this interested him very much.

- 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.


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
objects to grant users roles.  This is just suicide from a product viability

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.

In my new approach, which I have modified from studying 3 other commercial
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

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

(3) developers/app architects
     - determine the roles and permissions in their applications

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.
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

Bottom line, there is nothing personnal about it.

+1 not at all.  Actually our discussions are fun and we laugh about the
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


View raw message