directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From conflue...@apache.org
Subject [CONF] Apache Directory Server v1.5 > 3.2. Basic authorization
Date Wed, 28 Oct 2009 19:54:02 GMT
<html>
<head>
    <base href="http://cwiki.apache.org/confluence">
            <link rel="stylesheet" href="/confluence/s/1519/1/1/_/styles/combined.css?spaceKey=DIRxSRVx11&amp;forWysiwyg=true"
type="text/css">
    </head>
<body style="background-color: white" bgcolor="white">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
     <h2><a href="http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.2.+Basic+authorization">3.2.
Basic authorization</a></h2>
     <h4>Page <b>edited</b> by             <a href="http://cwiki.apache.org/confluence/display/~seelmann">Stefan
Seelmann</a>
    </h4>
     
          <br/>
     <div class="notificationGreySide">
         <div class='panelMacro'><table class='noteMacro'><colgroup><col
width='24'><col></colgroup><tr><td valign='top'><img src="/confluence/images/icons/emoticons/warning.gif"
width="16" height="16" align="absmiddle" alt="" border="0"></td><td><b>Work
in progress</b><br /><p>This site is in the process of being reviewed and
updated.</p></td></tr></table></div>
<style type='text/css'>/*<![CDATA[*/
table.ScrollbarTable  {border: none;padding: 3px;width: 100%;padding: 3px;margin: 0px;background-color:
#f0f0f0}
table.ScrollbarTable td.ScrollbarPrevIcon {text-align: center;width: 16px;border: none;}
table.ScrollbarTable td.ScrollbarPrevName {text-align: left;border: none;}
table.ScrollbarTable td.ScrollbarParent {text-align: center;border: none;}
table.ScrollbarTable td.ScrollbarNextName {text-align: right;border: none;}
table.ScrollbarTable td.ScrollbarNextIcon {text-align: center;width: 16px;border: none;}

/*]]>*/</style><div class="Scrollbar"><table class='ScrollbarTable'><tr><td
class='ScrollbarPrevIcon'><a href="/confluence/display/DIRxSRVx11/3.1.+Authentication+options"><img
border='0' align='middle' src='/confluence/images/icons/back_16.gif' width='16' height='16'></a></td><td
width='33%' class='ScrollbarPrevName'><a href="/confluence/display/DIRxSRVx11/3.1.+Authentication+options">3.1.
Authentication options</a>&nbsp;</td><td width='33%' class='ScrollbarParent'><sup><a
href="/confluence/display/DIRxSRVx11/3.+Basic+Security"><img border='0' align='middle'
src='/confluence/images/icons/up_16.gif' width='8' height='8'></a></sup><a
href="/confluence/display/DIRxSRVx11/3.+Basic+Security">3. Basic Security</a></td><td
width='33%' class='ScrollbarNextName'>&nbsp;<a href="/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL">3.3.
How to enable SSL</a></td><td class='ScrollbarNextIcon'><a href="/confluence/display/DIRxSRVx11/3.3.+How+to+enable+SSL"><img
border='0' align='middle' src='/confluence/images/icons/forwd_16.gif' width='16' height='16'></a></td></tr></table></div>

<h1><a name="3.2.Basicauthorization-Basicauthorization"></a>Basic authorization</h1>

<p>This section describes the default authorization functionality of ApacheDS 1.5, which
is very simple. On the other hand, it is inadequate for most serious deployments. Therefore
a basic example to the "real" authorization subsystem is provided as well.</p>

<div>
<ul>
    <li><a href='#3.2.Basicauthorization-Whatisauthorization%3F'>What is authorization?</a></li>
    <li><a href='#3.2.Basicauthorization-Defaultauthorizationbehaviorfordirectoryoperations'>Default
authorization behavior for directory operations</a></li>
    <li><a href='#3.2.Basicauthorization-SimpleexamplefortheACIsubsystem'>Simple
example for the ACI subsystem</a></li>
    <li><a href='#3.2.Basicauthorization-Verification%2Cthatitworks'>Verification,
that it works</a></li>
    <li><a href='#3.2.Basicauthorization-Resources'>Resources</a></li>
</ul></div>

<h2><a name="3.2.Basicauthorization-Whatisauthorization%3F"></a>What is
authorization?</h2>

<p>After authentication of a user or an application (or more generally an LDAP client)
against the directory server (or attaining anonymous access respectively), certain LDAP operations
will be granted or rejected, according to configuration and certain rules. This process of
granting access is called authorization.</p>

<p>Authorization for directory operations is not strictly standardized in the LDAP world,
<a href="http://www.faqs.org/rfcs/rfc2829.html" title="RFC 2829 - Authentication Methods
for LDAP" rel="nofollow">RFC 2829</a> describes various scenarios and concepts, but
does not enforce a concrete implementation. Thus each product comes with its own authorization
feature. So does ApacheDS. A powerful authorization subsystem is provided since version 0.9.3,
but disabled as a default.</p>

<h3><a name="3.2.Basicauthorization-Authorizationfordirectoryoperationsvs.groupmembership"></a>Authorization
for directory operations vs. group membership</h3>

<p>In order to accomplish their authorization functionality, software components often
take advantage of LDAP groups stored within the directory. <em>groupOfNames</em>
and <em>groupOfUniqueNames</em> are common object classes for groups entries;
they contain the DNs of their members (users, other groups) as attribute values. </p>

<p>In order to illustrate this, the "Seven Seas" example partition contains such group
entries below "ou=groups,o=sevenSeas". Here the entry of a group describing the HMS Bounty
crew (before the mutiny) in LDIF format.</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
dn: cn=HMS Bounty,ou=crews,ou=groups,o=sevenSeas
objectclass: groupOfUniqueNames
objectclass: top
cn: HMS Bounty
uniquemember: cn=William Bligh,ou=people,o=sevenSeas
uniquemember: cn=Fletcher Christian,ou=people,o=sevenSeas
uniquemember: cn=John Fryer,ou=people,o=sevenSeas
...
</pre>
</div></div>

<p>In such a scenario, a user, who is directly or indirectly member of a certain group
is permitted to do something. The software component acts as a normal LDAP client and determines
group belonging with the help of ordinary search operations. This is widely used but has nothing
to do with the authorization for directory operations as described in this section (except
that the client needs the permission to search the data). Learn more about best practices
in this area in the article <a href="http://middleware.internet2.edu/dir/groups/docs/internet2-mace-dir-groups-best-practices-200210.htm"
rel="nofollow">Practices in Directory Groups</a>. Further examples in this guide
are the Tomcat and Apache HTTPD integration sections.</p>

<h2><a name="3.2.Basicauthorization-Defaultauthorizationbehaviorfordirectoryoperations"></a>Default
authorization behavior for directory operations</h2>

<p>Without access controls enabled all entries are accessible and alterable by all:
even anonymous users. There are however some minimal built-in rules for protecting users and
groups within the server without having to turn on the ACI subsystem.</p>

<h3><a name="3.2.Basicauthorization-Sampledatawithin%22ou%3Dusers%2Cou%3Dsystem%22"></a>Sample
data within "ou=users,ou=system"</h3>

<p>In addition to our brave sailors below <em>ou=people,o=sevenSeas</em>,
assume the following to entries present within <em>ou=users,ou=system</em>:</p>

<p><img src="/confluence/download/attachments/55244/authorization_sample_entries.png"
align="absmiddle" border="0" /></p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>dn: cn=Tori Amos,ou=users,ou=system
objectclass: person
objectclass: top
sn: Amos
cn: Tori Amos
userpassword: amos

dn: cn=Kate Bush,ou=users,ou=system
objectclass: person
objectclass: top
sn: Bush
cn: Kate Bush
userpassword: bush
</pre>
</div></div>

<p>They are used in the following examples, in conjunction with <em>o=sevenSeas</em>,
to describe the default authorization rules.</p>

<h3><a name="3.2.Basicauthorization-Rulesandsampleoperations"></a>Rules
and sample operations</h3>

<p>Without ACIs the server automatically protects, hides, the admin user from everyone
but the admin user. Here a sample search operation in order to demonstrate this protection.
The same command is submitted three times with different users.</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>$ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w secret \\
    -b "ou=system" -s one "(uid=admin)" dn
version: 1
dn: uid=admin,ou=system

$ ldapsearch -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\
    -b "ou=system" -s one "(uid=admin)" dn

$ ldapsearch -h zanzibar -p 10389 -D "cn=Tori Amos,ou=users,ou=system" -w amos \\
    -b "ou=system" -s one "(uid=admin)" dn

$
</pre>
</div></div>

<p>Users cannot see other user entries under the 'ou=users,ou=system' entry. So placing
new users there automatically protects them. Placing new users anywhere else exposes them.</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>$ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w secret \\
    -b "ou=users,ou=system" -s one "(objectclass=*)" dn
version: 1
dn: cn=Tori Amos,ou=users,ou=system

dn: cn=Kate Bush,ou=users,ou=system

$ ldapsearch -h zanzibar -p 10389 -D "cn=Kate Bush,ou=users,ou=system" -w bush \\
    -b "ou=users,ou=system" -s one "(objectclass=*)" dn
version: 1
dn: cn=Kate Bush,ou=users,ou=system

$ ldapsearch -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\
    -b "ou=users,ou=system" -s one "(objectclass=*)" dn

$ ldapsearch -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\
    -b "ou=people,o=sevenSeas" -s one "(objectclass=*)" dn
version: 1
dn: cn=Horatio Hornblower,ou=people,o=sevenSeas

dn: cn=William Bush,ou=people,o=sevenSeas

dn: cn=Thomas Masterman Hardy,ou=people,o=sevenSeas

dn: cn=Cornelius Buckley,ou=people,o=sevenSeas

dn: cn=William Bligh,ou=people,o=sevenSeas
...
$
</pre>
</div></div>

<p>Groups defined using <em>groupOfNames</em> or <em>groupOfUniqueNames</em>
under the 'ou=groups,ou=system' are also protected from access or alteration by anyone other
than the admin user. Again this protection is not allowed anywhere else but under these entries.</p>

<h3><a name="3.2.Basicauthorization-Isthissufficient%3F"></a>Is this sufficient?</h3>

<p>For simple configurations the described rules should provide adequate protection
but it lacks flexibility. For advanced configurations users should enable the ACI subsystem.
This however shuts down access to everything by everyone except the admin user which bypasses
the ACI subsystem. Directory administrators should look at the documentation on how to specify
access control information in the Advanced User's Guide.</p>

<h2><a name="3.2.Basicauthorization-SimpleexamplefortheACIsubsystem"></a>Simple
example for the ACI subsystem</h2>

<p>As an appetizer for the stunning ACI subsystem (ACI = access control item) within
ApacheDS, we provide a simple yet realistic example. It manifests the following requirements</p>

<h3><a name="3.2.Basicauthorization-Requirementsmet"></a>Requirements met</h3>

<ol>
	<li>Suffix "o=sevenSeas" used as Access Control Specific Area</li>
	<li>User "cn=Horatio Nelson,ou=people,o=sevenSeas" should be able to perform all operations
(delete, add, ...) below the base "o=sevenSeas"</li>
	<li>Other users and anonymous users should only be able to search and compare (no add,
modify etc.)</li>
	<li>Other users and anonymous users should not be able to read the userPassword attribute</li>
</ol>


<h3><a name="3.2.Basicauthorization-EnabletheACISubsystem"></a>Enable the
ACI Subsystem</h3>

<p>The authorization (ACI) subsystem is disabled by default. If you use the server standalone
configured with a <em>server.xml</em> file, you can enable it by changing the
value for property <em>accessControlEnabled</em> in the Spring bean definition
for bean <em>defaultDirectoryService</em>, as depicted in the following fragment:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-xml">
  &lt;defaultDirectoryService id=<span class="code-quote">"directoryService"</span>
instanceId=<span class="code-quote">"default"</span>
                           ...
                           accessControlEnabled=<span class="code-quote">"true"</span>
                           ...&gt;
</pre>
</div></div>

<p>A restart of the server is necessary for this change to take effect. </p>

<h3><a name="3.2.Basicauthorization-Furtherconfigurationtaskstoperformafterwards"></a>Further
configuration tasks to perform afterwards</h3>

<p>1. Create an operational attribute <em>administrativeRole</em> with value
"accessControlSpecificArea" in the entry "o=sevenSeas".<br/>
2. Create a subentry subordinate to "o=sevenSeas" to grant all operations' permissions to
"cn=Horatio Nelson,ou=people,o=sevenSeas", who acts as directory manager </p>

<p>The subentry should contain the following attributes and values:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>cn="sevenSeasAuthorizationRequirementsACISubentry"
subtreeSpecification="{}"
prescriptiveACI="{
                   identificationTag "directoryManagerFullAccessACI",
                   precedence 11,
                   authenticationLevel simple,
                   itemOrUserFirst userFirst:
                   {
                     userClasses
                     {
                       name { "cn=Horatio Nelson,ou=people,o=sevenSeas" }
                     },
                     userPermissions
                     { 
                       {
                         protectedItems
                         {
                           entry, allUserAttributeTypesAndValues
                         },
                         grantsAndDenials
                         {
                           grantAdd, grantDiscloseOnError, grantRead,
                           grantRemove, grantBrowse, grantExport, grantImport,
                           grantModify, grantRename, grantReturnDN,
                           grantCompare, grantFilterMatch, grantInvoke
                         } 
                       }
                     }
                   } 
                 }"
</pre>
</div></div>

<p>3. A new attribute value should added to the previously created Subentry's prescriptiveACI
attribute to grant search and compare permissions to all users.</p>

<p>The new value:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>prescriptiveACI="{
                   identificationTag "allUsersSearchAndCompareACI",
                   precedence 10,
                   authenticationLevel simple,
                   itemOrUserFirst userFirst:
                   {
                     userClasses
                     {
                       allUsers
                     },
                     userPermissions
                     { 
                       {
                         protectedItems
                         {
                           entry, allUserAttributeTypesAndValues
                         },
                         grantsAndDenials
                         {
                           grantRead, grantBrowse, grantReturnDN,
                           grantCompare, grantFilterMatch, grantDiscloseOnError 
                         } 
                       }
                     }
                   } 
                 }"
</pre>
</div></div>

<p>4. A new attribute value should added to the previously created Subentry's prescriptiveACI
attribute to deny search and compare permissions for <em>userPassword</em> attribute
to all users.</p>

<p>The new value:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>prescriptiveACI="{
                   identificationTag "preventAllUsersFromReadingUserPasswordAttributeACI",
                   precedence 10,
                   authenticationLevel simple,
                   itemOrUserFirst userFirst:
                   {
                     userClasses
                     {
                       allUsers
                     },
                     userPermissions
                     { 
                       {
                         protectedItems
                         {
                           attributeType { userPassword }
                         },
                         grantsAndDenials
                         {
                           denyRead, denyCompare, denyFilterMatch
                         } 
                       }
                     }
                   } 
                 }"
</pre>
</div></div>

<p>The two values given in 3 and 4 can be combined in a single value as:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>prescriptiveACI="{
                   identificationTag "allUsersACI",
                   precedence 10,
                   authenticationLevel none,
                   itemOrUserFirst userFirst:
                   {
                     userClasses
                     {
                       allUsers
                     },
                     userPermissions
                     { 
                       {
                         protectedItems { entry, allUserAttributeTypesAndValues },
                         grantsAndDenials { grantRead, grantBrowse, grantReturnDN,
                                            grantCompare, grantFilterMatch, grantDiscloseOnError
} 
                       },
                       {
                         protectedItems { attributeType { userPassword } },
                         grantsAndDenials { denyRead, denyCompare, denyFilterMatch }
                       }
                     }
                   } 
                 }"
</pre>
</div></div>

<h3><a name="3.2.Basicauthorization-LDIFforthisconfiguration"></a>LDIF for
this configuration</h3>

<p>The following LDIF file (<a href="/confluence/download/attachments/55244/authz_sevenSeas.ldif?version=1">authz_sevenSeas.ldif</a>)
provides a set of changes made to directory entries in the "Seven Seas" data. In total it
performs the steps described above.  </p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
# File authz_sevenSeas.ldif
#
# Create an operational attribute "administrativeRole"
# with value "accessControlSpecificArea" in the entry "o=sevenSeas".
#
dn: o=sevenSeas
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea

# Create a subentry subordinate to "o=sevenSeas" to grant all operations' permissions 
# to "cn=Horatio Nelson,ou=people,o=sevenSeas", to grant search and compare permissions
# to all users and to deny search and compare permissions for userPassword attribute to all
users. 
#
dn: cn=sevenSeasAuthorizationRequirementsACISubentry,o=sevenSeas
changetype: add
objectclass: top
objectclass: subentry
objectclass: accessControlSubentry
cn: sevenSeasAuthorizationRequirementsACISubentry
subtreeSpecification: {}
prescriptiveACI: {
    identificationTag "directoryManagerFullAccessACI",
    precedence 11,
    authenticationLevel simple,
    itemOrUserFirst userFirst:
    {
      userClasses
      {
        name { "cn=Horatio Nelson,ou=people,o=sevenSeas" }
      },
      userPermissions
      { 
        {
          protectedItems
          {
            entry, allUserAttributeTypesAndValues
          },
          grantsAndDenials
          {
            grantAdd, grantDiscloseOnError, grantRead,
            grantRemove, grantBrowse, grantExport, grantImport,
            grantModify, grantRename, grantReturnDN,
            grantCompare, grantFilterMatch, grantInvoke
          } 
        }
      }
    } 
  }
prescriptiveACI: {
    identificationTag "allUsersACI",
    precedence 10,
    authenticationLevel none,
    itemOrUserFirst userFirst:
    {
      userClasses
      {
        allUsers
      },
      userPermissions
      { 
        {
          protectedItems { entry, allUserAttributeTypesAndValues },
          grantsAndDenials { grantRead, grantBrowse, grantReturnDN,
                             grantCompare, grantFilterMatch, grantDiscloseOnError } 
        },
        {
          protectedItems { attributeType { userPassword } },
          grantsAndDenials { denyRead, denyCompare, denyFilterMatch }
        }
      }
    }
  }
</pre>
</div></div>

<p>To apply this configuration to the sample data partition, you can perform an <em>ldapmodify</em>
with the LDIF as agrument:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent
panelContent">
<pre>$ ldapmodify -h zanzibar -p 10389 -D "uid=admin,ou=system" -w secret -f authz_sevenSeas.ldif
modifying entry o=sevenSeas

adding new entry cn=sevenSeasAuthorizationRequirementsACISubentry,o=sevenSeas
$
</pre>
</div></div>

<p>It is also possible to use graphical tools; some of them offer the feature to perform
operations given in LDIF.</p>

<h2><a name="3.2.Basicauthorization-Verification%2Cthatitworks"></a>Verification,
that it works</h2>

<p>After successfully applying the changes to the sample partition, one may ask how
to check whether it works. We therefore perform some operations with the help of command line
tools. Some will be permitted, some will not (and cause an appropriate error message). It
would also be able to check this with the help of graphical tools (you might like to do this
instead). But it is easier to document the parameters used with the help command line arguments.
 </p>

<h3><a name="3.2.Basicauthorization-Performingsomesearchoperationsinordertoreaddata"></a>Performing
some search operations in order to read data</h3>

<p>Bind as user "William Bush" and search for entries which match "(uid=hhornblo)".
Expected behavior: We are able to read the attributes of entry "cn=Horatio Hornblower,ou=people,o=sevenSeas"
(the only entry which matches the filter). The password attribute should not be visible. It
works as desired: </p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapsearch -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\
    -b "o=sevenSeas" -s sub "(uid=hhornblo)"
version: 1
dn: cn=Horatio Hornblower,ou=people,o=sevenSeas
mail: hhornblo@royalnavy.mod.uk
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: top
cn: Horatio Hornblower
uid: hhornblo
givenname: Horatio
description: Capt. Horatio Hornblower, R.N
sn: Hornblower
</pre>
</div></div>

<p>In the described configuration, the user "Horatio Nelson" acts as a directory manager
below "o=sevenSeas". Hence he should basically be allowed to do everything. He should even
be able to see other users' <em>userPassword</em> values. In our case, the hash
function <em>SHA</em> was applied to them:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapsearch -h zanzibar -p 10389 -D "cn=Horatio Nelson,ou=people,o=sevenSeas" -w pass \\
    -b "o=sevenSeas" -s sub "(objectclass=person)
" uid userPassword
version: 1
dn: cn=Horatio Hornblower,ou=people,o=sevenSeas
userpassword: {SHA}nU4eI71bcnBGqeO0t9tXvY1u5oQ=
uid: hhornblo

dn: cn=William Bush,ou=people,o=sevenSeas
userpassword: {SHA}nU4eI71bcnBGqeO0t9tXvY1u5oQ=
uid: wbush

dn: cn=Thomas Quist,ou=people,o=sevenSeas
userpassword: {SHA}nU4eI71bcnBGqeO0t9tXvY1u5oQ=
uid: tquist
...
</pre>
</div></div>

<p>But "Horation Nelson" is not able to perform searches in other areas than "o=sevenSeas"
to see the entries. Of course our global ApacheDS administrator "uid=admin,ou=system" is still
able to see them:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapsearch -h zanzibar -p 10389 -D "cn=Horatio Nelson,ou=people,o=sevenSeas" -w pass \\
    -b "ou=system" -s sub "(objectclass=person)"

$ ldapsearch -h zanzibar -p 10389 -D "uid=admin,ou=system" -w secret \\
    -b "ou=system" -s sub "(objectclass=person)"
version: 1
dn: uid=admin,ou=system
sn: administrator
cn: system administrator
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
userpassword: secret
uid: admin
displayName: Directory Superuser

dn: cn=Tori Amos,ou=users,ou=system
cn: Tori Amos
userpassword: amos
objectclass: person
objectclass: top
sn: Amos
...
</pre>
</div></div>

<h3><a name="3.2.Basicauthorization-Tryingtomanipulatedata"></a>Trying to
manipulate data</h3>

<p>Until now the authorization only hided data (entries, attributes) from users with
insufficient access rights. Let's perform some operations which try to manipulate the directory
data! </p>

<h4><a name="3.2.Basicauthorization-Addinganentry"></a>Adding an entry</h4>

<p>First we try to add a new user to the "Seven Seas" partition. The data for the entry
is inspired by "Peter Pan" and provided by this LDIF file (<a href="/confluence/download/attachments/55244/captain_hook.ldif?version=1">captain_hook.ldif</a>):
</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
# File captain_hook.ldif
dn: cn=James Hook,ou=people,o=sevenSeas
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
cn: James Hook
description: A pirate captain and Peter Pan's nemesis
sn: Hook
mail: jhook@neverland
userpassword: peterPan
</pre>
</div></div>

<p>An anonymous user is not allowed to create new entries, as the following error message
shows:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapmodify -h zanzibar -p 10389 -a -f captain_hook.ldif
adding new entry cn=James Hook,ou=people,o=sevenSeas
ldap_add: Insufficient access
ldap_add: additional info: failed to add entry cn=James Hook,ou=people,o=sevenSeas: null
$
</pre>
</div></div>

<p>The same holds true for all "Seven Seas"-user other than "Horatio Nelson". The latter
is permitted to do so:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapmodify -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\
    -a -f captain_hook.ldif
adding new entry cn=James Hook,ou=people,o=sevenSeas
ldap_add: Insufficient access
ldap_add: additional info: failed to add entry cn=James Hook,ou=people,o=sevenSeas: null

$ ldapmodify -h zanzibar -p 10389 -D "cn=Horatio Nelson,ou=people,o=sevenSeas" -w pass \\
    -a -f captain_hook.ldif
adding new entry cn=James Hook,ou=people,o=sevenSeas
$
</pre>
</div></div>

<p>Afterwards a new entry is successfully created within the "Seven Seas" partition
by user "Horatio Nelson". The '+' sign in the attributes list of the <em>ldapsearch</em>
command causes ApacheDS to return the operational attributes, which demonstrate this.</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapsearch -h zanzibar -p 10389 -b "o=sevenSeas" -s sub "(cn=James Hook)" +
version: 1
dn: cn=James Hook,ou=people,o=sevenSeas
accessControlSubentries: cn=sevenSeasAuthorizationRequirementsACISubentry,o=sevenSeas
creatorsName: cn=Horatio Nelson,ou=people,o=sevenSeas
createTimestamp: 20061203140109Z
</pre>
</div></div>

<h4><a name="3.2.Basicauthorization-Modifyinganentry"></a>Modifying an entry</h4>

<p>As a further example which tries to write to the directory, we add a new value to
the description attribute of the freshly created entry for Captain Hook. With a change entry
in an LDIF file, it looks like this (file <a href="/confluence/download/attachments/55244/captain_hook_modify.ldif?version=1">captain_hook_modify.ldif</a>):</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
# File captain_hook_modify.ldif
dn: cn=James Hook,ou=people,o=sevenSeas
changetype: modify
add: description
description: Wears an iron hook in place of his right hand
-
</pre>
</div></div>

<p>Performing the modification with the <em>ldapmodify</em> command line
tool again fails for users other than "Horation Nelson" (who is allowed to due to the authorization
configuration) and "uid=admin,ou=system".</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapmodify -h zanzibar -p 10389 -f captain_hook_modify.ldif
modifying entry cn=James Hook,ou=people,o=sevenSeas
ldap_modify: Insufficient access
ldap_modify: additional info: failed to modify entry cn=James Hook,ou=people,o=sevenSeas:
null

$ ldapmodify -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\ 
    -f captain_hook_modify.ldif
modifying entry cn=James Hook,ou=people,o=sevenSeas
ldap_modify: Insufficient access
ldap_modify: additional info: failed to modify entry cn=James Hook,ou=people,o=s
evenSeas: null

$ ldapmodify -h zanzibar -p 10389 -D "cn=Horatio Nelson,ou=people,o=sevenSeas" -w pass \\
    -f captain_hook_modify.ldif
modifying entry cn=James Hook,ou=people,o=sevenSeas

</pre>
</div></div>

<h4><a name="3.2.Basicauthorization-Deletinganentry"></a>Deleting an entry</h4>

<p>Now it is finale time. A demonstration on how to delete the villain's entry from
the directory. With an LDIF file (<a href="/confluence/download/attachments/55244/captain_hook_delete.ldif?version=1">captain_hook_delete.ldif</a>)
with an appropriate change entry, this can easily be accomplished, if the bind user is allowed
to do so. </p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
# File captain_hook_delete.ldif
dn: cn=James Hook,ou=people,o=sevenSeas
changetype: delete
</pre>
</div></div>

<p>Applying this file with the help of <em>ldapmodify</em> results in a
behavior comparable to the modification. Anonymous or "normal" users (like "William Bush")
are not permitted to delete Captain Hook's entry. The user "Horatio Nelson", our directory
manager for "Seven Seas", is:</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="code-none">
$ ldapmodify -h zanzibar -p 10389 -f captain_hook_delete.ldif
deleting entry cn=James Hook,ou=people,o=sevenSeas
ldap_delete: Insufficient access
ldap_delete: additional info: failed to delete entry cn=James Hook,ou=people,o=sevenSeas:
null

$ ldapmodify -h zanzibar -p 10389 -D "cn=William Bush,ou=people,o=sevenSeas" -w pass \\
    -f captain_hook_delete.ldif
deleting entry cn=James Hook,ou=people,o=sevenSeas
ldap_delete: Insufficient access
ldap_delete: additional info: failed to delete entry cn=James Hook,ou=people,o=sevenSeas:
null

$ ldapmodify -h zanzibar -p 10389 -D "cn=Horatio Nelson,ou=people,o=sevenSeas" -w pass \\
    -f captain_hook_delete.ldif
deleting entry cn=James Hook,ou=people,o=sevenSeas
$
</pre>
</div></div>

<p>The entry "cn=James Hook,ou=people,o=sevenSeas" has been successfully deleted from
the partition. Our little demonstration on how the ACI subsystem with a realistic configuration
behaves end here. Learn more about it in the Advanced User's Guide.</p>

<p><a name="3.2.Basicauthorization-Resources"></a></p>

<h2><a name="3.2.Basicauthorization-Resources"></a>Resources </h2>

<ul>
	<li><a href="http://middleware.internet2.edu/dir/groups/docs/internet2-mace-dir-groups-best-practices-200210.htm"
rel="nofollow">Practices in Directory Groups</a> describes how to use groups within
LDAP directories. Highly recommended.</li>
	<li>The <a href="/confluence/pages/createpage.action?spaceKey=DIRxSRVx11&amp;title=ApacheDS+v1.0+Advanced+User%27s+Guide&amp;linkCreation=true&amp;fromPageId=55244"
class="createlink">ApacheDS v1.0 Advanced User's Guide</a> provides a detailed authorization
chapter</li>
	<li><a href="http://www.faqs.org/rfcs/rfc2849.html" rel="nofollow">RFC 2849</a>
The LDAP Data Interchange Format (LDIF) is used extensively in this section</li>
</ul>

     </div>
     <div id="commentsSection" class="wiki-content pageSection">
       <div style="float: right;">
            <a href="http://cwiki.apache.org/confluence/users/viewnotifications.action"
class="grey">Change Notification Preferences</a>
       </div>

       <a href="http://cwiki.apache.org/confluence/display/DIRxSRVx11/3.2.+Basic+authorization">View
Online</a>
       |
       <a href="http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=55244&revisedVersion=5&originalVersion=4">View
Change</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>

Mime
View raw message