Re: dynamic ACLs

["Dane Foster" <dfoster@equitytg.com>]

Howard Chu wrote:
"From a convenience perspective I see the current static ACL situation as a
flaw,
but from a security perspective I don't think it's so bad. In fact I think
it's
a security advantage - if you have an environment where access control is
changed
so frequently that dynamic definition is an absolute requirement, then in my
opinion you're wasting your time because your system is no longer secure to
begin with. One distinct advantage of defining all ACLs in a static file is
that
it is feasible, pretty much trivial, to audit the security of your
directory, and
analyze who has access to what. It becomes more and more difficult to
perform
this kind of audit and analysis as you distribute the access control
information
and delegate the access control administration."


The need for dynamic ACLs does not have to revolve around changing existing
ACL rulez but (in my situation) the ability to add new rulez as the
directory changes.  This will does not compromise the security of the
directory.



Here is a scenario.  The WidgetExpress Company is a supplier of custom-built
widgets.  Its Heavy Equipment Widget (HEW) department produces widgets for,
tractors, dump trucks, bulldozers, etc built to customer specifications and
ship to local heavy equipment retailer (HER)s and contractors in the US,
Canada, and Mexico.  Instead of maintaining a direct sales force,
WidgetExpress partners with HERs who become certified to resell
WidgetExpress widgets.  HERs place orders for custom-build items, which are
manufactured at WidgetExpress' main factory and are shipped to the retailer
or directly to the customer's site.  HERs can become certified on any of a
number of different product lines and may sell only those products for which
they are authorized.



WidgetExpress currently has about 200 authorized retailers and that number
is expected to grow at a rate of 95% for the next 4-6 years.  To support
each of these retailers, updated product literature and price list are
shipped to each HER monthly.  Because the ordering process is quite complex
and varies from product to product, the literature includes worksheets that
describe the options available for each product and any measurements, which
must be supplied before the manufacturing process can begin.



HERs must call in or send an email to the customer rep to place orders.
This is prone to human errors (on both sides) and time consuming (return
calls, etc).  WidgetExpress wants to improve service to HERs and customers
and to lower costs by increasing inefficiency and reducing costly errors.
The powers that be at WidgetExpress decided an extranet web-based
application could accomplish this.  The drivers for using a directory
service over a relational database include the following:



_Extranet applications must be manageable through delegation_ - Because of
the large number (and growing) HERs, each of which has several employees
authorized to sell WidgetExpress products, it is expected that there will be
at least several thousand user entries in the database at any time.  To
further complicate the management of this user information, each HER is an
independent business with its own employees.  Clearly, to make it possible
to manage user information, the creation, deletion, and maintenance of user
account information must be delegated to the individual retailers.



_User information must be shared among multiple applications_ - There are
several different web-apps (components) (i.e. order entry, personalized
product notice generation, etc) that would comprise the extranet suite, each
of which needs to authenticate users and store customization information.  A
directory is the best place to store shared user information across a
network.



The extranet application directory sub-tree may look like this.

dn:
_IndividualRetailerEntry_=_someUniqueID_,ou=WigetExpressRetailers,ou=Extrane
t, dc=WidgetExpress,dc=com



>From the above DN you can see that there would be a different sub-tree added
under ou=WidgetExpressRetailers for each new retailer.  There would need to
be ACL rulez added at that point that would allow the HER to modify and read
their own information but prevent them from accessing anyone else.  Also ACL
rulez at that location would give the HER the power to add employees (info)
who are certified to resell WidgetExpress widgets.  This information may not
change often but is subject to change as employees become certified in
multiple WidgetExpress widgets.



Mr. Chu, please tell me how you implement this with a static ACL system and
also point out why this cannot be implemented without violating the security
of the directory service.


Dane Foster
Equity Technology Group, Inc
http://www.equitytg.com.
954.360.9800
----- Original Message -----
From: "Howard Chu" <hyc@highlandsun.com>
To: "Dane Foster" <dfoster@equitytg.com>; <openldap-software@OpenLDAP.org>
Sent: Sunday, September 09, 2001 12:31 AM
Subject: RE: dynamic ACLs


Some offhand comments...

There is of course interest in implementing dynamic ACLs. Search through the
archives for "ACI" and you should find plenty of discussion on the topic, as
well as the current state of that code.

I personally grew up on systems that supported ACLs and I'm very comfortable
using them, but I don't see any actual *need* for them. You can achieve
pretty
good dynamic access control by defining a good set of static rules and
assigning
privileges to groups - your dynamic control arises from dynamically
controlling
the group memberships. Algebraically the two approaches are equivalent.

>From a convenience perspective I see the current static ACL situation as a
flaw,
but from a security perspective I don't think it's so bad. In fact I think
it's
a security advantage - if you have an environment where access control is
changed
so frequently that dynamic definition is an absolute requirement, then in my
opinion you're wasting your time because your system is no longer secure to
begin with. One distinct advantage of defining all ACLs in a static file is
that
it is feasible, pretty much trivial, to audit the security of your
directory, and
analyze who has access to what. It becomes more and more difficult to
perform
this kind of audit and analysis as you distribute the access control
information
and delegate the access control administration.

>From another perspective - an LDAP directory is not a filesystem - it is not
intended for general storage of both private and shared material. By and
large, the reason
you store things in an LDAP directory is to share them. As such, if you find
yourself
needing all of the security flexibility that you're accustomed to in a
filesystem
context, I believe you're misusing the technology.

Obviously this is all my personal opinion. From a perspective of design
elegance,
it makes sense to me that the access control information should be
distributed and
as easily accessible and manageable as the actual data objects. This is a
feature
of the original X.500 spec as well, and it's logical to support it. But when
you
leave the abstract world of design and get into the harsh reality of
implementation,
perspectives change, and what seemed like a good idea at first turns out to
have
many unforeseen complexities and drawbacks. There are performance issues,
security
issues, etc. etc. etc...

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Dane Foster
> Sent: Saturday, September 08, 2001 4:59 PM
> To: openldap-software@OpenLDAP.org
> Subject: dynamic ACLs
>
>
> Hello all.  I'm new to the OpenLDAP list (subscribed today) and
> new to LDAP
> in general.  I'm currently involved in projects that require the
> implementation of a directory service.  After doing massive amounts of
> reading I believe I have a half-way decent idea of what LDAP is and more
> importantly how it can and will fit into the projects that we (my
> employer)
> are involved in.  After much web-surfing/research I have concluded that
> OpenLDAP is my best option for satisfying our directory requirements.  The
> primary reason for OpenLDAP's selection is it has the best
> price/performance
> (its free and stable) ratio of any LDAP implementation that I researched.
> That being said, there is one major shortcoming that I found in OpenLDAP
> that directly affects our directory service; you cannot do on the fly ACL
> additions or modifications.  As part of my research I dug into LDAP.org's
> mailing list archives.  What I couldn't find in the archives was any
> concrete direction regarding implementing a more dynamic ACL architecture.
> Unfortunately, I'm not a C programmer (I do Java) so I'm unable to
> contribute via C code.  It seems that if I, or anyone for that
> matter, want
> dynamic ACL in OpenLDAP, it will have to happen at the application level
> instead of in OpenLDAP.
> Due to the needs of an extranet application I'm involved in
> dynamic ACL is a
> must.  I'm currently thinking about creating a lightweight Java
> library that
> I will be able to drop into any -java-application that need dynamic ACL
> capability.  This brings me to the core reason for posting this message, I
> would like to know if there are other java developers on this
> list who need
> the same or similar functionality and would like to _informally_
> participate
> in developing such a library?  Please note the emphasis on
> informal.  I have
> no interest in incurring the overhead of a full-blown project for two
> reasons (1) I don't have the time because my hands are full and
> (2) I don't
> think the solution requires it.  If no one is interested that is fine with
> me but at a minimum I hope to inspire discussion on how to
> satisfy the need
> for dynamic ACL capability in OpenLDAP.
>
> Thanx for reading :-)
>
> Dane Foster
> Equity Technology Group, Inc
> http://www.equitytg.com.
> 954.360.9800
>