[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]


Directory-Specific Access Control Implementation

The supported directories (for example, DirX, and Sun ONE) have complex mechanisms for controlling access, depending on the user bound to the directory.

DirX stores the access control lists in subentries that conform to the X.500 standard. You create the access control subentries by using the DirX client dirxcp. These access control subentries are replicated in a shadowing scenario.

Sun ONE stores the access control lists in the directory. Sun ONE extends the standard object class top by the optional attribute aci, which is used to store the access control lists. This means that the access control information (ACI) can be added through LDAP. The aci values are replicated to the slave directory.

DirX Directory Server

DirX access control information is stored in subentries that are from the type subentry and acceSDXontrolSubentry. These subentries include the information about the target (that is, what is controlled), precedence (that is, higher precedence overwrites lower precedence), and the access control information (that is, prescriptive ACI) that includes the user class (that is, who is affected by the control parameters) and the permissions on entry and attribute level.

Access control subentries can contain many prescriptive ACIs with a list of one or more items to be protected, such as entries and sets of operation or user attributes.

The UMCdirxa package includes a TCL file, called acldefs.tcl, which defines the following variables for the permissions:

The UMCdirxa package includes the file access.cp, which sets the access controls for the SRC software.

Figure 34 shows a TCL script with an explanation of the various parts.


Figure 34: Creation of an Access Control Subentry Example in DirX

Sun ONE Directory Server

Access control information is stored in the aci attribute of each directory entry. Because the access control information is stored in the directory, it can be managed by means of LDIF files.

ACIs take the following form:

aci: (<target>) (version 3.0;aci "<name>";<permission><bind rule>;)

where

<target> defines the object, attribute, or filter that you are using to define what resource to control access to. The target can be a distinguished name, one or more attributes, and/or a single LDAP filter.

version 3.0 is a required string that identifies the ACI version.

aci "<name>" is a name for the ACI. <name> can be any string that identifies the ACI. The ACI name is required.

<permission> defines the actual access rights and whether they are to be allowed or denied.

<bind rules> identify the circumstances under which the directory login must occur for the ACI to take effect.

The UMCiDSa package includes the LDIF file access.ldif, which implements the SDX access control scheme.

Figure 35 shows the LDIF file for implementing the same kind of access level as previously depicted with a Sun ONE directory.


Figure 35: Creation of Access Control List Example in Sun ONE


[Contents] [Prev] [Next] [Index] [Report an Error] [No Frames]