Metadata

As with other plugins, the metadata is made up of two parts, the entityInfo and schema. See the documentation on Metadata for more high level details on how these are used. Continue reading for LDAP specifics.

More examples can be found in the lightblue-ldap-integration-test module.

entityInfo

Attributes:

• backend - Name of the datasource provider to use. Should always be "ldap".
• database - Name of database to associate this entity too. Should match the database attribute in datasources.json.
• basedn - The base dn for where the entities should live within the LDAP directory structure.
• uniqueaddr - The LDAP attribute that will indicate uniqueness for instances of this entity. Lightblue-LDAP will use this in the dn when creating or reading entities. For example (based on below): uid=jdoe.ou=Users,dc=example,dc=com

{
    "entityInfo": {
        "name": "entityName",
        "datastore": {
            "backend":"ldap",
            "database": "LdapDatabaseName",
            "basedn": "ou=Users,dc=example,dc=com",
            "uniqueattr": "uid"
        }
    },
    "schema": {...}
}

Alias Attribute Names

You may also alias attribute names if you wish for the entity fields to be different. To do so, simply add an ldap section to the entityInfo and define the mappings.

In the following example, the LDAP attribute "LdapAttributeName" will be aliased as "EntityFieldName" in the remainder of the metadata definition and in all CRUD operations.

NOTE: The actual attributed name will no longer be available for use and can only be referenced by the aliased name.

EXCEPTION TO ABOVE NOTE: The uniqueattr MUST continue to be the actual attribute name, but can be aliased for field definitions and CRUD operations.

{
    "entityInfo": {
        "name": "...",
        "datastore": {...}
        "ldap": {
            "fieldsToAttributes": [
                {
                    "field": "EntityFieldName",
                    "attribute": "LdapAttributeName"
                },
                ...
            ]
        }
    },
    "schema": {...}
}

schema

Nothing too interesting here, as this follows the standard schema definition.

From an LDAP perspective, you might notice that dn and objectClass are not included in the fields list, and that is because they will automatically be added and available for CRUD operations. You are welcome to specify them yourself if you prefer, but it is unnecessary.

NOTE: The attribute identified as the uniqueattr in the entityInfo section is required to be defined in the fields list.

NOTE: If you chose to alias the field names in the entityInfo section, then the field names would be the "EntityFieldName" as in the earlier example.

{
    "entityInfo": {...}
    "schema": {
        "name": "entityName",
        "version": {
            "value": "1.0.0",
            "changelog": "blahblah"
        },
        "status": {
            "value": "active"
        },
        "access" : {
             "insert": ["anyone"],
             "update": ["anyone"],
             "delete": ["anyone"],
             "find": ["anyone"]
        },
        "fields": {
            "uid": {"type": "string"},
            "givenName": {"type": "string"},
            "sn": {"type": "string"},
            "cn": {"type": "string"}
        }
    }
}