RE: dynamic ACLs

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Dane Foster

>
> There are a few grammatical errors in my original post that may severely
> hamper the meaning of the sentences.  I've changed them below
>
> Dane Foster
> Equity Technology Group, Inc
> http://www.equitytg.com.
> 954.360.9800
> ----- Original Message -----
> From: "Dane Foster" <dfoster@equitytg.com>
> To: "Howard Chu" <hyc@highlandsun.com>
> Cc: <openldap-software@OpenLDAP.org>

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

> _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 and remove
> 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.

It is not my job to do your thinking for you. I will demonstrate a solution
to prove the point, but if you want a detailed example, you have to make it
worth my while to spend my time on the details. All the information required
to do what you want is already well documented:
http://www.openldap.org/doc/admin/slapdconfig.html#Access%20Control

First of all, realize that even though you are creating new branches of your
tree, they are each functionally equivalent. As such, you don't need to
create
a new set of rules every time a branch is added, just use one set:

	access to
dn="(.*,)?ou=WigetExpressRetailers,ou=Extranet,dc=WidgetExpress,dc=com"
		by self write
		by
group="cn=admin,ou=groups,(.*,)?ou=WigetExpressRetailers,ou=Extranet,dc=Widg
etExpress,dc=com" write

All you have to do when a new HER is added is create their subtree, create
one user under that tree for bootstrapping purposes, create one admin group
containing the bootstrap user, and tell the new company how to login as the
bootstrap user. After
that you're done, and they are free to go off and create users as needed,
delegate
rights as needed, etc. Of course, with this scheme, you *do* have to dictate
at
least part of their tree structure: My example assumes that each HER will
have
           o=MyCompany,ou=WigetExpressRetailers,...
           ou=users,o=Mycompany,ou=WigetExpressRetailers,...
           ou=groups,o=Mycompany,ou=WigetExpressRetailers,...
           cn=admin,ou=groups,o=Mycompany,ou=WigetExpressRetailers,...

The above example is of course extremely simplified, but you can expand it
to be
as detailed as you wish.

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