From commits-return-20367-apmail-directory-commits-archive=directory.apache.org@directory.apache.org Wed Nov 19 22:18:06 2008 Return-Path: Delivered-To: apmail-directory-commits-archive@www.apache.org Received: (qmail 73757 invoked from network); 19 Nov 2008 22:18:03 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 19 Nov 2008 22:18:03 -0000 Received: (qmail 41854 invoked by uid 500); 19 Nov 2008 22:18:11 -0000 Delivered-To: apmail-directory-commits-archive@directory.apache.org Received: (qmail 41815 invoked by uid 500); 19 Nov 2008 22:18:11 -0000 Mailing-List: contact commits-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@directory.apache.org Delivered-To: mailing list commits@directory.apache.org Received: (qmail 41801 invoked by uid 99); 19 Nov 2008 22:18:11 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Nov 2008 14:18:11 -0800 X-ASF-Spam-Status: No, hits=-1994.3 required=10.0 tests=ALL_TRUSTED,HTML_MESSAGE,MIME_HTML_ONLY X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 19 Nov 2008 22:16:47 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 0ACA9234C297 for ; Wed, 19 Nov 2008 14:17:00 -0800 (PST) Message-ID: <1512356768.1227133020038.JavaMail.www-data@brutus> Date: Wed, 19 Nov 2008 14:17:00 -0800 (PST) From: confluence@apache.org To: commits@directory.apache.org Subject: [CONF] Apache Directory Server v1.5: 2.5. Authorization (page edited) MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org
Page Edited : DIRxSRVx11 : 2.5. Authorization

2.5. Authorization has been edited by Emmanuel L=C3=83=C2=A9charny (Nov 19, 2008).

=20

= (View changes)

Content:
<= colgroup>=
3D""= Work in progress

This site is in the process of being reviewed and updated.

ApacheDS uses an adaptation of the X.500 basic access control scheme in = combination with X.500 subentries to control access to entries and attribut= es within the DIT. This document will show you how to enable the basic acce= ss control mechanism and how to define access control information to manage= access to protected resources.

Enabling = Basic Access Controls

By default the access control subsystem is turned off. Once enabled ever= ything is tightly locked down. Only the special admin user, 'uid=3Dadmin= ,ou=3Dsystem', is not affected by permissions. Access to all operations= are denied by default until enabled using an ACIItem. For this reason enab= ling basic access controls is a configuration option.

To turn on the basic access control mechanism you need to set the acc= essControlEnabled property in the configuration to true. This can be se= t programatically on the StartupConfiguration or via the server.xml.

= Types of ACI (Access Control Information)

Three different types of ACI exist. All types use the same specification= syntax for an ACIITem. These types differ in their placement and manner of= use within the directory.

Entry ACI

Entry ACI are access controls added to entries to protect that entry spe= cifically. Meaning the protoected entry is the entry where the ACI resides.= When performing an operation on an entry, ApacheDS checks for the presence= of the multivalued operational attribute, entryACI. The values of t= he entryACI attribute contain ACIItems.

3D""

There is one exception to the rule of consulting entryACI attributes wit= hin ApacheDS: add operations do not consult the entryACI within the entry b= eing added. This is a security precaution. If allowed users can arbitrarily= add entries where they wanted by putting entryACI into the new entry being= added. This could comprimise the DSA.

Prescriptive ACI

Prescriptive ACI are access controls that are applied to a collection of= entries, not just to a single entry. Collections of entries are defined by= the subtreeSpecifications of subentries. Hence prescriptive ACI are added = to subentries as attributes and are applied by ApacheDS to the entries sele= cted by the subentry's subtreeSpecification. ApacheDS uses the prescript= iveACI multivalued operational attribute within subentries to contain A= CIItems that apply to the entry collection.

Prescriptive ACI can save much effort when trying to control access to a= collection of resources. Prescriptive ACI can even be specified to apply a= ccess controls to entries that do not yet exist within the DIT. They are a = very powerful mechanism and for this reason they are the prefered mechanism= for managing access to protected resources. ApacheDS is optimized specific= ally for managing access to collections of entries rather than point entrie= s themselves.

Users should try to avoid entry ACIs whenever possible, and use prescrip= tive ACIs instead. Entry ACIs are more for managing exceptional cases and s= hould not be used excessively.

3D""How it works!

For every type of LDAP operation ApacheDS checks to see if any access co= ntrol subentries include the protected entry in their collection. The set o= f subentries which include the protected entry are discovered very rapidly = by the subentry subsystem. The subentry subsystem caches subtreeSpecificati= ons for all subentries within the server so inclusion checks are fast.

For each access control subentry in the set, ApacheDS checks within a pr= escriptive ACI cache for ACI tuples. ApacheDS also caches prescriptive ACI = information in a special form called ACI tuples. This is done so ACIItem pa= rsing and conversion to an optimal representations for evaluation is not re= quired at access time. This way access based on prescriptive ACIs is determ= ined very rapidly.

Subentry ACI

Access to subentries also needs to be controlled. Subentries are special= in ApacheDS. Although they subordinate to an administrative entry (entry o= f an Administrative Point), they are technically considered to be in the sa= me context as their administrative entry. ApacheDS considers the perscripti= ve ACI applied to the administrative entry, to also apply to its subentries= .

This however is not the most intuitive mechanism to use for explicitly c= ontrolling access to subentries. A more explicit mechanism is used to speci= fy ACIs specifically for protecting subentries. ApacheDS uses the multivalu= ed operational attribute, subentryACI, within administrative entries= to control access to immediately subordinate subentries.

Protection policies for ACIs themselves can be managed within the entry = of an administrative point.

Some Simple Exampl= es

The ACIItem syntax is very expressive and that makes it extremely powerf= ul for specifying complex access control policies. However the syntax is no= t very easy to grasp for beginners. For this reason we start with simple ex= amples that focus on different protection mechanisms offered by the ACIItem= syntax. We do this instead of specifying the grammar which is not the best= way to learn a language.

3D""Before you go any further...

Please don't go any further until you have read up on the use of Subentries<= img class=3D"rendericon" src=3D"/confluence/images/icons/plus.gif" height= =3D"7" width=3D"7" align=3D"absmiddle" alt=3D"" border=3D"0"/>. Knowledge of subentries, subtreeSpecifications, administrative areas,= and administrative roles are required to properly digest the following mat= terial.

Before going on to these trails you might want to set up an Administrati= ve Area for managing access control via prescriptiveACI. Both subentryACI = and prescriptiveACI require the presence of an Administrative Point entry. = For more information and code examples see ACAreas.

ACI Trails

Here are some trails that resemble simple HOWTO guides. They're ordered= with the most pragmatic usage first. We will add to these trails over tim= e.

Trail Description
EnableSearchForAllUser= s Enabling access to browse and read all entries a= nd their attributes by authenticated users.
DenySubentryAccess (TBW) Protecting access to subentries themselves.
AllowSelfPasswordModif= y Granting users the rights needed to change their= own passwords.
GrantAddDelModToGroup (TBW) Granting add, delete, and modify permissions to = a group of users.
GrantModToEntry (TBW) Applying ACI to a single entry.