Work in progress

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

Introduction

This guide will show you how to create an Access Control Specific Area and Access Control Inner Areas for administering access controls within ApacheDS. Basic knowledge of the X.500 administrative model is presumed along with an understanding of the Basic Access Control Scheme in X.501. For quick primers please take a look at the following documentation:

Creating Access Control Specific Areas (ACSA)

An access control specific area is an Autonomous Administrative Area (AAA) for managing access control specific aspects of a subtree within the DIT. Like all administrative areas, an access control specific area is rooted at a vertex entry called the Administrative Point (AP). The ACSA spans down until leaf entries are encountered or until another ACSA is encountered. Access control specific areas do not overlap.

Under the AP, you can add subentries that contain prescriptiveACI attributes. Zero or more subentries can be added, each with one or more prescriptiveACI. These subentries apply access control information (ACI) in these prescriptiveACI attributes to collections of entries within the ACSA.

Adding an 'administrativeRole' Attribute

An entry becomes an AP when it has an administrativeRole attribute added to it with the appropriate value(s). For an ACSA, we need to add the 'accessControlSpecificArea' value to this attribute.

Most of the time users will create partitions in the server and set the root context of the partition (its suffix) to be the AP for a ACSA. For example the default server.xml for ApacheDS ships with a partition with the suffix, 'dc=example,dc=com'. We can use this suffix entry as the AP and our ACSA can cover all entries under and including 'dc=example,dc=com'.

The code below binds to the server as admin ('uid=admin,ou=system') and modifies the suffix entry to become an ACSA. Note that we check to make sure the attribute does not already exist before attempting the add operation.

  ...
  // Get a DirContext on the dc=example,dc=com entry
  Hashtable env = new Hashtable();
  env.put( "java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory" );
  env.put( "java.naming.provider.url", "ldap://localhost:389/dc=example,dc=com" );
  env.put( "java.naming.security.principal", "uid=admin,ou=system" );
  env.put( "java.naming.security.credentials", "secret" );
  env.put( "java.naming.security.authentication", "simple" );
  ctx = new InitialDirContext( env );

  // Lookup the administrativeRole specifically since it is operational
  Attributes ap = ctx.getAttributes( "", new String[] { "administrativeRole" } );
  Attribute administrativeRole = ap.get( "administrativeRole" );

  // If it does not exist or has no ACSA value then add the attribute
  if ( administrativeRole == null || ! administrativeRole.contains( "accessControlSpecificArea" ) )
  {
    Attributes changes = new BasicAttributes( "administrativeRole", "accessControlSpecificArea", true );
    ctx.modifyAttributes( "", DirContext.ADD_ATTRIBUTE, changes );
  }
  ...

This simple modification of adding the value 'accessControlSpecificArea' to the administrativeRole makes the suffix entry 'dc=example,dc=com' an AP for an access control specific area. Now you can add subentries to your heart's content which subordinate to the AP.

Creating an Access Control Inner Administrative Area

Creating an inner area involves the same process. In fact the same code can be used by changing the value added to the administrativeRole attribute. To create the inner area just add 'accessControlInnerArea' for the administrativeRole within the AP: same steps, same code, different value for the administrativeRole.

Access Control Subentries

After creating the access control area you can create subentries that subordinate to this AP for managing access to it and anything below. Access control subentries are entries with the objectClasses: 'subentry' and 'accessControlSubentry'. An access control subentry must contain 3 attributes other than the obvious objectClass attribute. These required attributes are listed below:

Attribute

SINGLE-VALUED

Description

cn

no

The name of the subentry used as its RDN

subtreeSpecification

yes

The specification for the collection of entries the ACI is to be applied to.

prescriptiveACI

no

The attribute holding the ACIItem

  • No labels