Extracting ACL databases from LDAP

[vanrein]

ACL implementations are efficient for individuals and even groups because of the way the databases are keyed. For configuration, the information is stored in LDAP, however.

LDAP information is located with the resources that they protect. The following handling information details how to identify an object in ACLs,

objectClass: resourceInstanceObject
resourceClassUUID: 904dfdb5-6b34-3818-b580-b9a0b4f7e7a9
resourceInstanceKey: 90-365-17273

and the same object also reveals ACL information,

objectClass: accessControlledObject
accessControlList: 10 rwkov @orvelte.nep
accessControlList: 20 cdrwkov bakker@orvelte.nep
accessControlList: 30 drwkov slager@orvelte.nep someone@else.where

So, the LDAP is edited in terms of objects, with ACL information attached. The Resource ACL however, is indexed by the addresses on the list (and resource identification). For the Communication ACL a similar thing applies, just with different object data (based on objectClass: uidObject and not objectClass: resourceInstanceObject or objectClass: resourceClassObject).

Another difference is the location where this management data is edited (the Service DIT) and where it is used (anywhere a service is running). LDAP is used to pass the information; SyncRepl is the mechanism used for instant updates.

So: The wish is to use SteamWorks Pulley to extract this information from LDAP and store it into a service-local database for use with the ACL logic.

[vanrein]

Alternative identification for ACLs stem from

objectClass: resourceClassObject
resourceClassUUID: 904dfdb5-6b34-3818-b580-b9a0b4f7e7a9

This is a complete class, and might for instance represent access to a domain's user base, for which no individual instances are necessary. If this is the case then, again, ACL information would be attached for objectClass: accessControlledObject

For the Communication ACL, the format would be as setup for IdentityHub. There, the DN already holds the desired information:

uid=bakker,ou=Users,associatedDomain=orvelte.nep,ou=IdentityHub,o=arpa2.net,ou=InternetWide

The shells are meant to provide interactive examples, notably arpa2acl, arpa2reservoir and arpa2id. The LDAP schemes can be found there too, as part of their server setup.