Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / products / directory / directory data access /

Sodium - Access Control User Interface

Quick guide to access control

Each X.501 BAC (Basic Access Control) subtree is controlled by the administrative entry at the top of that subtree.  For example, c=US would typically provide the ACI (Access Control Information) for the entire subtree from c=US downwards.

Administrative entries are a special type of entry which cannot be created by Sodium (at the moment) -- EDM must be used to create  them.

ACI Rules

ACI rules determine which permissions are granted or denied for different operations within the subtree.  The ACI rules for normal entries are stored in two places:

1. The administrative entry stores Prescriptive ACI which affects the whole of the subtree.
2. Each individual entry may also store Entry ACI which affects only the entry that it is found on.

The various groups of ACI rules that affect a given entry are always listed near the top of the ACI tab for that entry.

Entry and Attribute scope

A single ACI rule may control either entry or attribute access. Both types of access must be granted for a user to reach a given attribute, so in general both an entry grant rule and an attribute grant rule must be created.

Subentries

Subentries are hidden entries associated with an administrative entry.

Access control subentries store the Prescriptive ACI for the administrative entry.  There are also other types of subentry used for other admin functions, such as defining collective attributes.

Subentries may be shown by selecting Browse Subentries from the ACI tab or from the DIT context menu.

Each subentry by default affects the entire subtree at and below the administrative entry.  However it may be limited to affect only certain entries by setting up a subtree specification. This may limit the influence to a certain area of the subtree, or to certain objectclasses or depths.

Multiple access control subentries may be used to apply different sets of Prescriptive ACI rules to different parts of the subtree.

The ACI rules that control access to the subentries themselves (to read or modify the contents of the subentries) are shown in the ACI tab of each subentry.  There may be contributions from three places:

1. The administrative entry stores Subentry ACI which affects the immediate subentries.
2. Each individual subentry may also store Entry ACI which affects only the subentry that it is found on.
3. Superior administrative entries, excluding the immediate parent, may provide Prescriptive ACI.  This only has an effect in the case of subentries of ACIA administrative entries (see below).

Administrative entry types

ACSA (Access Control Specific Area) administrative entries are the type most often used.  These start a new subtree that is completely independent from all superior entries, and which does not inherit any ACI rules at all from them.

ACIA (Access Control Inner Area) administrative entries may be used to add extra ACI rules for a particular subtree below a superior ACSA. Prescriptive ACI on the ACIA combines with Prescriptive ACI from superior ACIA and ACSA administrative entries up to and including the nearest parent ACSA.

Note that creating an ACIA administrative entry and setting up Prescriptive ACI for it has the same effect (in access-control terms) as setting up Prescriptive ACI in new access control subentries on the top-level ACSA, using suitable subtree specifications to limit their effect to the required subtree.

Simplified Access Control

Apart from Basic Access Control (BAC), there is a simpler type of X.501 ACI called Simplified Access Control (SAC).  Simplified Access Control makes these changes to BAC:

• All Entry ACI is ignored
• ACIA administrative points are ignored

The only ACI rules that have an effect are:

• The Prescriptive ACI stored in subentries of the ACSA administrative entry
• The Subentry ACI stored on the ACSA administrative entry itself

To enable SAC for an administrative area using Sodium, browse to the administrative entry with the Op-Attrs tab turned on, find the  accessControlScheme attribute in that tab, change 2.5.28.1 (BAC)  to 2.5.28.2 (SAC) and apply the change.

ACI Rule Editor: Sorting

The rules may be sorted by three aspects:

• Scope: sort all Entry rules before Attribute rules, useful when the display is collapsed.
• Prec: sort by precedence, with highest-precedence rules first.
• Name: sort by rulename.

ACI Rule Editor: Rule Header Buttons

The components of a header line in the ACI editor are as follows below.  Note that tooltips are provided in the GUI as a quick reminder.

• The precedence: 0 to 255.  Higher-precedence rules override lower-precedence rules.
• The authentication and signing levels that this rule applies to:
  • A: anonymous bind,
  • P: simple (password) bind,
  • S: strong bind, and
  • S': strong bind with signed operations.
• Whether the rule Grants or Denies access.
• Whether the rule governs Entry or Attribute access.
• The access permissions granted or denied.

The permissions are grouped as follows:

• Permission to read and report back: Read, Browse, Compare, Filter Match, Return DN and Disclose on Error.
• Permission to make changes: Add, Delete and Modify.
• Permission to modify DNs: Rename, Export and Import.  Note that Rename applies when the RDN is changed, and Export and Import apply when the superior DN is changed.