directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: ApacheDS as a provisioning platform
Date Thu, 18 Oct 2007 23:05:08 GMT
Hey cool.  I'm a boater how can I help you :). More in line:

On 10/18/07, Yuriy Zubarev <> wrote:
> Greetings,
> I guess I will start off with a brief description of requirements. They
> are quite typical. A system should support a hierarchy of our customers.
> We have "companies", each company have "offices" and each office have
> "employees". Each employee have a set of permissions either assigned
> directly or through roles. Both companies and offices may also be
> assigned permissions either directly or through the roles. If a company
> has a certain permission then all offices for this company and
> subsequently employees would inherit this permission. In the same
> fashion, if an office has a certain permission assigned to it then all
> employees of that office would also inherit this permission.

How about thinking of your same thoughts in terms of Roles:

(1) Each company has a base employee Role (i.e. YamahaEmployee,
(2) Roles are a set of permissions and a set of other Roles
    - that they inherit the permissions of roles (multiple inheritence)
(3) Create Roles associated with specific departmental (office) tasks with
some global
     permissions in your application that would apply to any company
employee in that
     role (i.e. AccountManager, SalesRepresentative ...)
(4) If you need to add specific permissions for an department in a specific
company then
     just create a role for that company that extends the company employee
role and the
     department role.  Then add additional permissions for the specific
rights they will have.
(5) Create static and dynamic Groups of Users
(6) Create role assignments which assign Roles to Users, and Groups

In the end you have a nice Role Based Access Control Authorization scheme.
This is one
of the capabilities we tried to build btw with Triplesec here:

However there are several shortcomings that have not reached the ideas
outlined above. We
are seeing ways in which we can improve upon Triplesec and build a bigger
community around
it so we can allow it to achieve these goals out of the box for any company
looking for a solid
authorization manager.  Even though Triplesec at this stage is an experiment
with some ugly
points it does have a lot going for it in terms of the ideas it tested.  Now
we know how to make
it much better.

After having read
> and I
> couldn't  get rid of a feeling that LDAP is exactly what we need. At the
> same time we don't have any hard-core LDAP experience here and the
> project time lines cannot afford lots of time for R&D.

Ahh I see.  Sound to me like what you need is an authorization manager.  If
need something immediately take a look at Microsoft's AzMan which does this.

Therefore I would like to ask if there any white paper or comprehensive
> examples on how to use LDAP as a basis for a commercial system and
> create a web application on top of it. I'm not talking about on how to
> use LDAP just to authenticate users for a web app deployed on Tomcat or
> something like this. I'm talking about a need for a web front-end where
> CSRs and "admins" would manage LDAP hierarchies (CRUD for
> company/office/person) and manage roles/permissions associated to those
> entities.

Take a look at AzMan it's specifically designed for these considerations.
In fact
for the policy editor there is a admin mode and a developer mode to using

> It's relatively easy to build such web front-end on top of a
> database but what about LDAP server?

We're close.  Triplesec's Authorization Manager is the answer to doing
simple RBAC
with LDAP.  I think also according to the subject of this email it will be
even more impressive
once we enable the use of triggers and stored procedures.  Different things
can be triggered
when roles and permissions are manipulated to effect the users authorization
profile across
several systems.

Do we just give them LDAP client?

IMO that's giving them too many degrees of freedom to be effective but I
guess that depends
on who we are referring to.  For people in the NOC or at a help desk who
admin these policies
perhaps an LDAP client is a bit too dangerous unless you can restrict what
can be done with
ACI's which is possible in ApacheDS.

Obviously the system we are building is not dedicated to managing roles
> and permissions but to selling "widgets".

Ooops ... ;) yep widgets.

Roles and permissions are here
> just to make managing of "widgets" more granular. These "widgets" and
> everything that is associated with them are stored in DB. Then the next
> question is how to integrate info from LDAP and DB.

This is not a problem and can be done in most cases but it all depends on
database schema.

In essence, I have a very limited experience with LDAP and while I
> understand its ideas and benefits (or I think that I do), I cannot see
> how to practically apply LDAP to our problem domain. This is not a
> question about ApacheDS in particular but an inquiry about relevant
> documentation.

Sounds to me like you have a catelog of goods being sold by your storefront
several suppliers which need access to these goods to manage information
about them
that they are allowed to manage.  It's a simple B2B requirement to be able
to work with
your suppliers.  Catelogs are great for LDAP because it's essentially a
directory.  It
is read more than it is written.  You need to replicate it and delegated
of various aspects to the proper authorities (suppliers).  Then with the
Directory vision
you need to react to these changes to enable among other things

So I think you're on the right track but your questions have a number of
things intertwined
in them.  First you're mixing the desire to have a RBAC based authorization
model for
your application while you want manage the catelog in a directory.  I think
you might
want to divide and conquer these concerns a little bit to just make it
easier to chew one
off at a time.  Perhaps you're already doing that and just added all the
to this mail.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message