ACL Processing & Translation
Relevant source files
The following files were used as context for generating this wiki page:
ACL Processing & Translation in the flext-ldif library provides a standardized framework for extracting, parsing, evaluating, and migrating Access Control Lists (ACLs) across diverse LDAP server environments. The system abstracts vendor-specific formats—such as OpenLDAP's olcAccess, Oracle Internet Directory's (OID) orclaci, and Oracle Unified Directory's (OUD) RFC 4876 aci—into a unified Acl domain model.
The architecture leverages a service-oriented approach where the AclService orchestrates high-level operations, supported by specialized server-specific implementations and utility classes. This enables seamless translation between different security models, ensuring data integrity and permission parity during server migrations.
Sources: examples/06_acl_processing.py:1-15, src/flext_ldif/_utilities/acl.py:12-25
Architectural Overview
The ACL system is built upon a hierarchy of server-specific handlers that inherit from a base ACL schema class. These handlers manage the low-level parsing of raw strings and the generation of vendor-specific LDIF output.
Component Relationship
The diagram above illustrates the inheritance structure of ACL handlers. Each server implementation overrides logic to handle specific attribute names and string patterns unique to that vendor.
Sources: src/flext_ldif/servers/_base/acl.py:18-35, src/flext_ldif/servers/openldap.py:155-165, src/flext_ldif/servers/_oid/acl.py:23-35
ACL Extraction and Parsing
The library identifies ACL attributes within LDIF entries based on server-specific constants. Once identified, raw strings are passed to the appropriate server handler's parser.
Supported ACL Attributes by Server Type
| Server Type | Primary Attributes |
|---|---|
| RFC | aci, acl, olcAccess, aclRights, aclEntry |
| OID | orclaci, orclentrylevelaci, acl |
| OUD | aci, orclaci, orclentrylevelaci |
| OpenLDAP | olcAccess |
| AD | nTSecurityDescriptor, aci |
Sources: src/flext_ldif/_utilities/acl.py:34-51, src/flext_ldif/servers/openldap.py:31-35
Parsing Logic Flow
The parsing process decomposes a raw ACL string into components: Target, Subject, and Permissions.
For instance, OpenLDAP ACLs are parsed by extracting "to" (Target) and "by" (Subject/Permission) clauses. OID ACLs utilize specialized regex patterns to extract target filters and bind modes.
Sources: src/flext_ldif/servers/openldap.py:228-260, src/flext_ldif/servers/_oid/acl.py:175-200, src/flext_ldif/_utilities/acl.py:465-480
ACL Evaluation
The AclService provides mechanisms to evaluate existing ACLs against a required permission set. This is used to determine if an entry's security configuration meets specific criteria.
evaluate_acl_context(acls, required_perms): Evaluates a list of ACL models against a mapping of required boolean permissions.extract_acls_from_entry(entry, server_type): A high-level helper that scans an entry for recognized ACL attributes and returns a collection ofAclmodels.
Sources: examples/06_acl_processing.py:45-55, src/flext_ldif/servers/_base/acl.py:130-145
Cross-Server Translation
Translation between server types requires mapping permission sets and subject formats that do not have a 1:1 correlation between vendors.
Permission Mapping (OID to OUD)
OID permissions like browse and selfwrite must be translated to OUD/RFC compliant terms like read, search, and write.
# Internal mapping logic example
mapping = {
"browse": ["read", "search"],
"selfwrite": ["write"]
}
Sources: src/flext_ldif/_utilities/acl.py:435-460, src/flext_ldif/servers/_oid/acl.py:120-140
Metadata Preservation
During translation, the system utilizes the metadata.extensions field of the Acl model to store vendor-specific features that cannot be mapped directly to the RFC model, such as:
bindipfilter: IP-based access restrictions (OID).added_object_constraint: Content-based restrictions (OID).ssf: Security Strength Factor requirements (OUD).
Sources: src/flext_ldif/servers/_oid/acl.py:205-230, src/flext_ldif/servers/_oud/acl.py:195-210
Implementation Examples
Extracting and Evaluating ACLs
Developers can use the ldif() facade to process ACLs within an LDIF pipeline.
from flext_ldif import ldif
api = ldif()
# entry obtained from api.parse_ldif()
acl_result = api.extract_acls_from_entry(entry, server_type="openldap")
if acl_result.success:
acls = acl_result.unwrap().acls
required_perms = {"read": True, "write": True}
eval_result = api.evaluate_acl_context(acls, required_perms)
Sources: examples/06_acl_processing.py:38-58
Formatting ACI Lines
The FlextLdifUtilitiesACL provides low-level formatting for generating complex ACI strings.
# Internal utility usage for OUD format
aci_line = FlextLdifUtilitiesACL.format_aci_line(
settings=m.Ldif.AciLineFormatConfig(
name="Allow read",
target_clause='(targetattr="*")',
permissions_clause="allow (read,search)",
bind_rule='userdn="ldap:///anyone"'
)
)
Sources: src/flext_ldif/_utilities/acl.py:408-418, src/flext_ldif/_models/_settings_acl.py:26-44
Summary
ACL Processing & Translation in flext-ldif serves as a bridge between idiosyncratic LDAP security implementations. By decomposing complex strings into a structured domain model and utilizing extensible metadata, the library allows for robust auditing and conversion of access controls. This system is critical for enterprise-grade LDIF migrations where preserving security posture is paramount.
Sources: src/flext_ldif/servers/_base/acl.py:18-40, examples/06_acl_processing.py:85-95