iPlanet Directory Server IDDS Transition Guide: Chapter 5 Access Control

Previous Contents Next

iPlanet Directory Server IDDS Transition Guide

Chapter 5 Access Control

This chapter documents the differences in the access control models and syntax between IDDS and iPlanet Directory Server and gives some simple examples. This will help you implement equivalent access control on your data in iPlanet Directory Server as you have in IDDS. This chapter contains the following sections:

Migrating Access Control

A Quick Comparison of Syntax and Semantics

Evaluating Access Control

Groups

Examples

Specifying the Entries and Attributes Subject to Access Control

Specifying the Users to Whom Access is Granted

Specifying Access Permissions to Grant

Migrating Access Control

The migration process for access control is as follows:

Rewrite IDDS access directives as iPlanet Directory Server Access Control Instructions (ACIs).

Optionally, convert groups into preferred groupOfUniqueNames format.

Import the ACI into the iPlanet Directory Server directory tree.

Verify the behavior of the ACIs.
IDDS access directives must be rewritten as a set of iPlanet Directory Server ACIs. You can create ACIs in LDIF form or you may create them using the iPlanet Directory Server Console (or a combination of both methods). If you write in LDIF form, you have the choice of inserting them into the LDIF file that will be used to initialize the database or adding them afterwards with ldapmodify or the console once the database has been initialized. The console has a specialized ACI editor but it can also handle ACI in LDIF form.
The recommended approach is to insert ACIs with a text editor into the LDIF file used to load the database. Then use the console to quickly experiment with and tweak the ACIs.

A Quick Comparison of Syntax and Semantics

IDDS access directives are written in the sls.conf configuration file. They can be specific to a backend database or global to all backend databases.
iPlanet Directory Server ACIs, on the other hand, are stored in the directory as attributes of entries. If an entry containing an ACI is a leaf entry, then the ACI applies to that entry only. Otherwise the ACI applies to the entry itself and all entries below it.
If there is one database suffix superior to all others, then that suffix entry is a common ancestor entry into which the global ACIs can be placed. Otherwise the global ACIs can be duplicated in the suffix entry of each database backend. A database's local ACIs can be placed in the database suffix entry.
The syntax of IDDS access directives and iPlanet Directory Server ACIs are quite different. The syntax of an IDDS access directive is:
access to <what> [ by <who> <access> ]+
The syntax of an iPlanet Directory Server ACI value is:
(<target>)(version 3.0; acl "name"; [ <permission> <bind_rule>; ]+)
Comparing these syntaxes, <what> is analogous to <target>, <who> is analogous to <bind_rule>, and <access> is analogous to <permission>. Each of these are discussed in more detail later.
ACIs may be given a descriptive name for ease of management and comprehension, for example, "Default anonymous access."
IDDS allows regular expressions in some places. However, only wildcards may be used in iPlanet Directory Server. The most common IDDS regular expression construct ".*" may be represented in iPlanet Directory Server using the "*" wildcard.
IDDS has a hierarchy where each level implies all lower levels of access. For example, granting read access also grants search and compare. In iPlanet Directory Server, rights are granted independently of one another (but note that "all" is shorthand for all rights other than proxy).
In IDDS write access is used for attributes and also for entry addition and deletion. In iPlanet Directory Server write is only used for attributes; there are separate add and delete permissions for entry addition and deletion.

Evaluating Access Control

In IDDS, access directives local to the current database are examined first, followed by global access directives. The order of evaluation of access directives makes their placement in the configuration file important.
In iPlanet Directory Server, the server compiles a list of the ACIs present on the entry and on the parent entries up to the top level entry. ACIs are evaluated across all databases for a server. The evaluation of the list of ACIs is done based on the semantics of the ACIs, not on their placement in the directory tree. The most restrictive ACI in the list takes precedence.
For more information, see the iPlanet Directory Server Administrator's Guide.

Groups

A group may be defined as an entry of objectclass groupOfNames or groupOfUniqueNames, the difference being that an optional unique identifier may be assigned to DN's contained in the latter. These groups are called static groups in iPlanet Directory Server terminology. For example, consider the following entry of objectclass groupOfNames:
dn: cn=mgrs,dc=innosoft,dc=com
objectclass: groupOfNames
cn: mgrs
member: cn=John Smith,dc=innosoft,dc=com
member: cn=Jane Doe,dc=innosoft,dc=com
Both IDDS and iPlanet Directory Server permit groups of either objectclass to be referenced in access control statements. However, it is easier to manage a static group in the iPlanet Directory Server Console if it is a groupOfUniqueNames because there is a specialized editor for such entries. You may wish to convert all your groups into this form. The same example group expressed as a groupOfUniqueNames would look like this:
dn: cn=mgrs,dc=innosoft,dc=com
objectclass: groupOfUniqueNames
cn: mgrs
uniquemember: cn=John Smith,dc=innosoft,dc=com
uniquemember: cn=Jane Doe,dc=innosoft,dc=com

Examples

The following examples have some lines folded for readability. This line folding is supported in both the IDDS configuration file and the LDIF format used to write ACIs in iPlanet Directory Server.

General Read Access

IDDS
access to * by * read
iPlanet Directory Server
aci: (targetattr=*)(version 3.0; acl "anyone read";
   allow (read,search,compare) userdn="ldap:///anyone";)
This ACI must be placed in the suffix entry of the database to which it applies.

Access to Subtrees

IDDS
access to dnsub="ou=sales,dc=innosoft,dc=com" by * search
   access to dnsub="dc=innosoft,dc=com" by * read
iPlanet Directory Server
aci: (targetattr=*)(target="ldap:///ou=sales,dc=innosoft,dc=com")
   (version 3.0; acl "anyone search";
   allow (search,compare) userdn="ldap:///anyone";)
aci: (targetattr=*)(target="ldap:///dc=innosoft,dc=com")
   (version 3.0; acl "anyone read";
   allow (read,search,compare) userdn="ldap:///anyone";)

Access to a Specific Attribute

IDDS
access to dnsub="dc=innosoft,dc=com" attr=phone
   by self write
   by dnsub="dc=innosoft,dc=com" search
   by domain=.*\.innosoft\.com read
   by * compare
access to dnsub="dc=innosoft,dc=com"
   by self write
   by dnsub="dc=innosoft,dc=com" compare
   by * none
iPlanet Directory Server
aci:(targetattr="phone")(target="ldap:///dc=innosoft,dc=com")
   (version 3.0; acl "phone";
   allow (search,compare) userdn = "ldap:///*,dc=innosoft,dc=com";
   allow (read,search,compare) dns = "*.innosoft.com";
   allow (compare) userdn = "ldap:///anyone";)
aci: (targetattr=*)(target="ldap:///dc=innosoft,dc=com")
   (version 3.0; acl "default";
   allow (all) userdn = "ldap:///self";
   allow (compare) userdn = "ldap:///*,dc=innosoft,dc=com";)
Note that there is no need to translate the "by * none" portion of the IDDS directive because by default users are denied access. Also note that there is no need to translate "by self write" in the phone ACI since that is already in the default ACI applying to all attributes—unlike IDDS, both ACIs are considered when looking at the phone attribute.

Group Management

IDDS
access to attr=member,entry by dnattr=member selfwrite
iPlanet Directory Server
aci: (targetattr=member)(version 3.0; acl "self-remove group";
   allow (selfwrite) userattr = "member#USERDN";)
The above ACI allows any group member to remove themselves from a group.

Access By a Group

IDDS
access to * by dnbase="cn=admin,dc=innosoft,dc=com" write
   by group="cn=mgrs,dc=innosoft,dc=com" write
   by * read
iPlanet Directory Server
aci: (targetattr=*)(version 3.0; acl "mgrs write";
   allow (all) userdn = "ldap:///cn=admin,dc=innosoft,dc=com";
   allow (all) groupdn = "ldap:///cn=mgrs,dc=innosoft,dc=com";
   allow (read,search,compare) userdn = "ldap:///anyone";)

Specifying the Entries and Attributes Subject to Access Control

In IDDS terminology this is known as <what> and in iPlanet Directory Server terminology <target>.

Everything

IDDS

to *

iPlanet Directory Server

(target="<suffix>")(targetattr=*)

There is no direct equivalent in iPlanet Directory Server to target all entries. Instead, for each database suffix you must have an ACI targeting the suffix. For example, for the database suffix "dc=innosoft,dc=com", use an ACI containing:

(target="ldap:///dc=innosoft,dc=com")

If the ACI is in the database suffix entry, then you may omit the target specification entirely, but not the targetattr keyword. In iPlanet Directory Server, when you target an entry, the target does not include all of the attributes under that entry.

A Specific Entry

IDDS

to dnbase=<dn>

iPlanet Directory Server

(targetfilter=(<rdn>))

Targeting a single directory entry is not as straightforward in iPlanet Directory Server. The iPlanet Directory Server Administrator's Guide discusses several possibilities, one of which is to use targetfilter=(<rdn>). For example:

dnbase="dc=innosoft,dc=com"

becomes:

(targetfilter=(dc=innosoft))

The above example works provided none of the entries below the target entry contain the attribute dc=innosoft.

All Entries in a Subtree

IDDS

to dnsub=<dn>

iPlanet Directory Server

(target="ldap:///<dn>")

Entries Whose DNs Have a Common Pattern

IDDS

to dn=<regular expression>

iPlanet Directory Server

(target="ldap:///<wildcard-dn>")

Only wildcards may be used in iPlanet Directory Server targets. For example:

dn="uid=.*,ou=.*,dc=siroe,dc=com"

becomes:

(target="ldap:///uid=*,ou=*,dc=siroe,dc=com")

Entries Satisfying an LDAP Filter

IDDS

filter=<ldap filter>

iPlanet Directory Server

(targetfilter = "<ldap filter>")

Specific Attributes

IDDS

attrs=<attribute list>
attr=<attribute list>

iPlanet Directory Server

(targetattr = "attribute1 || attribute2 ... || attributen")

For example:

attr=cn,sn,uid

becomes

(targetattr = "cn || sn || uid")

The IDDS pseudo-attributes entry and children are not needed in iPlanet Directory Server. You do not need explicit access to the entry in addition to its attributes. To delete an entry you must be granted the "Delete" right. To add an entry you must be granted the "Add" right.

Specifying the Users to Whom Access is Granted

In IDDS terminology this is known as <who> and in iPlanet Directory Server terminology <bind_rule>.

Everyone

IDDS

*

iPlanet Directory Server

userdn = "ldap:///anyone"

Self

IDDS

self

iPlanet Directory Server

userdn = "ldap:///self";
userdn = "ldap:///all"

In iPlanet Directory Server, the anyone keyword grants anonymous access; the all keyword grants access to all authenticated users.

Users Whose DNs Have a Common Pattern

IDDS

dn=<regular expression>

iPlanet Directory Server

userdn = "ldap:///<wildcard-dn>";

Only wildcards may be used in iPlanet Directory Server. For example:

dn="uid=.*,ou=.*,dc=siroe,dc=com"

becomes:

userdn = "ldap:///uid=*,ou=*,dc=siroe,dc=com";

A Specific User

IDDS

dnbase=<dn>

iPlanet Directory Server

userdn = "ldap:///<dn>";

Users Whose DN is Under a Specific Subtree

IDDS

dnsub=<dn>

iPlanet Directory Server

userdn = "ldap:///*,<dn>";

Users Connecting From a Specific Network Location

IDDS

addr=<regular expression>

iPlanet Directory Server

ip = "<wildcard-ip-address>";

Only wildcards may be used in iPlanet Directory Server. For example:

addr=129\.153\.129\..*

becomes

ip = "129.153.129.*";

Users in a Specific DNS Domain

IDDS

domain=<regular expression>

iPlanet Directory Server

dns = "<wildcard-domain>";

For example:

domain=.*\.innosoft\.com

becomes:

dns = "*.innosoft.com";

Users Whose DN Matches an Attribute Value

IDDS

dnattr=<dn-valued attribute name>

iPlanet Directory Server

userattr = "<dn-valued attribute name>#USERDN";

Users Belonging to a Specific Group

IDDS

group=<dn>

iPlanet Directory Server

groupdn = "ldap:///<dn>";

There is no need to change the directory group entry referenced by <dn>.

Specifying Access Permissions to Grant

In IDDS terminology this is known as <access> and in iPlanet Directory Server terminology <permission>, defined as allow | deny (<rights>).
IDDS has the following levels of access:

none | compare | search | read | selfwrite | write

iPlanet Directory Server has the following rights:

read | write | add | delete | search | compare | selfwrite | proxy | all

IDDS has a hierarchy where each level implies all lower levels of access. For example, granting read access also grants search and compare. In iPlanet Directory Server, rights are granted independently of one another (but note that "all" is shorthand for all rights except proxy).
Compare, search, read, and selfwrite have the same meaning in IDDS and iPlanet Directory Server. So, read access in IDDS can be replaced with (read, search, compare) rights in iPlanet Directory Server. Write access in IDDS can be replaced with (all) rights in iPlanet Directory Server.
In IDDS write access is used for attributes and also for entry addition and deletion. In iPlanet Directory Server write is only used for attributes; there are separate add and delete permissions for entry addition and deletion.

To Add, Delete, or Modify an Attribute

IDDS: You must have write access to the attribute and to the entry itself through the "entry" attribute.
iPlanet Directory Server: You must have write permission to the attribute. You do not need separate write permission to the entry itself.

To Add an Entry

IDDS: You must have write access to the "children" attribute of the parent.
iPlanet Directory Server: You must have add permission on the entry (inherited of course from an ACI higher in the tree).

To Delete an Entry

IDDS: You must have write access to the "entry" attribute.
iPlanet Directory Server: You must have delete permission on the entry.

Previous Contents Next
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated June 19, 2001