Type: New Feature
Affects Version/s: 4.0.0
Fix Version/s: None
Support Ticket IDs:
The goal of this feature is to provide a dynamic mode for Rest2LDAP which does not require a static attribute mapper configuration. Instead, Rest2LDAP provides a dynamic automatically generated RESTful view of an LDAP subtree.
Rest2LDAP will be configured using an LDAP base DN and an endpoint. The endpoint will have a resource representation that corresponds to the base DN entry. For example, given the base DN "cn=config" and the endpoint "config" then performing an HTTP GET against "/config" will return the contents of "cn=config".
Subordinate LDAP entries will have corresponding subordinate JSON resources with names derived from the relative DN of the entry with respect to the base DN. Resource path elements will not contain the RDN attribute type. For example, the DN "ds-cfg-backend-id=userRoot,cn=Backends,cn=config" will have the resource path "/config/Backends/userRoot".
When creating resources the LDAP RDN will be derived from the resource's path elements. By default the RDN attribute type will be assumed to be "cn" unless there is an applicable LDAP name form. Attempts to create a resource for which there is no well-defined attribute will fail. For example, if the object class does not allow the "cn" attribute or if there are multiple applicable name forms or the name form allows or requires multiple attribute types in the RDN.
All resources will have a "schema" field identifying which schemas apply to the resource. The schema field will be a URI whose value is derived automatically from the LDAP object class of the entry as specified in the entry's structuralObjectClass operational attribute. We may support auxiliary object classes.
The URI will take the form of a URL or URN. We should allow users to template the representation, e.g. a URN "urn:forgerock:schemas:1.0:%s" or the URL "http://forgerock.org/schemas/1.0/%s".
We'll support resource creation by requiring the client to provide a schema field in their JSON resource. The object class will be assumed to be the last component of the schema URN or URL. Rest2LDAP should leverage DIT structure rules and name forms in order to infer which resources may be created for a given parent resource.
It will be possible to identify JSON resources using their "_id" field or their "_externalId" field in order to make the REST API more user-friendly. For example, the following relative URL could all be aliases for the same resource:
- using "_id" only for naming: 66ceef12-f0d6-355e-9e9b-9bdcfe536d8c/26176404-8825-3f77-9efd-c52bd4061f3b/80faa47a-77d6-3c78-a3c1-ea6ccbd2f735
- using a mix of "_id" and "_externalId": config/backends/80faa47a-77d6-3c78-a3c1-ea6ccbd2f735
- using "_externalId" only: config/backends/userRoot
The LDAP "objectClass" attribute will be mapped to the JSON "schemas" field, although it will only contain the structural object class and any auxiliary object classes.
The LDAP "etag" operational attribute will be mapped to the JSON "_rev" field.
The LDAP "entryUUID" operational attribute will be mapped to the JSON "_id" field.
The LDAP RDN attribute, e.g. "cn" or "uid", will be mapped to the JSON "_externalId" attribute.
The LDAP create/modify timestamps will be mapped to similarly named JSON fields within a parent "_meta" field.
The remaining LDAP user attributes will be mapped to identically named JSON fields. The attribute values will be transformed to a representation that is appropriate for HTTP based applications. For example, timestamps will be converted to W3C timestamps and we should attempt to convert DN valued attributes to relative URLs.