REST to LDAP Reference
DS software offers these alternatives for HTTP access to directory data:
REST to LDAP Gateway | DS Server | |
---|---|---|
Implementation |
The gateway is a servlet that connects to remote LDAP server(s). |
The DS server exposes RESTful HTTP APIs to its directory data. |
Base Configuration Directory |
|
|
Connection Configuration |
A single configuration file defines how the gateway connects and authenticates to LDAP servers. For details, see Gateway LDAP Connections. |
The server uses an internal connection. Identity mappers define how HTTP user identities map to LDAP user identities. For details, see Identity Mappers. |
Gateway Configuration |
A single configuration file defines which LDAP features the gateway uses. For details, see Gateway LDAP Features. |
The server configuration defines which LDAP features are enabled. |
API Configuration |
In both cases, one or more configuration files define the HTTP APIs that map JSON resources to LDAP entries. For details, see API Configuration. |
Unlike standard JSON, REST to LDAP JSON configuration files permit //
-style comments.
Gateway LDAP Connections
A single config.json
file defines how the gateway connects and authenticates to LDAP servers.
The top-level fields are:
{
// Secure connections to remote LDAP servers.
"security": {},
// Connect and authenticate to remote LDAP servers.
"ldapConnectionFactories": {},
// Set authorization policies for access to directory data.
"authorization": {}
}
Security
The "security"
field covers the parameters for secure connections to remote servers:
More information
{
"security": {
// Specifies the policy for trusting server certificates exchanged
// during SSL/StartTLS negotiation. This setting and the following
// trust policy settings will be ignored if there is no connection
// security. Acceptable values are:
//
// "trustAll" - blindly trust all server certificates (not secure)
// "jvm" - only certificates signed by the authorities
// associated with the host JVM will be accepted (default)
// "file" - use a file-based trust store for validating
// certificates. This option requires the following
// "fileBasedTrustManager*" settings to be configured.
//
"trustManager": "jvm",
// File based trust manager configuration (see above).
"fileBasedTrustManagerType": "JKS",
"fileBasedTrustManagerFile": "/path/to/truststore",
"fileBasedTrustManagerPasswordFile": "/path/to/pinfile",
// Specifies the key-manager for TLS client authentication
// (mutual TLS, mTLS) against the remote server.
// Acceptable values are:
//
// "none" - disables TLS client authentication,
// no client certificates will be used. (default)
// "jvm" - use the JVM's default keystore
// for retrieving client certificates.
// "file" - use a file-based key store
// for retrieving client certificates.
// "pkcs11" - use a PKCS#11 token
// for retrieving client certificates.
"keyManager": "none",
// Keystore based key manager configuration (see above).
"fileBasedKeyManagerType": "JKS",
"fileBasedKeyManagerFile": "/path/to/keystore",
"fileBasedKeyManagerPasswordFile": "/path/to/pinfile",
// PKCS11 based key manager configuration
"pkcs11KeyManagerPasswordFile": "/path/to/pinfile"
}
}
LDAP Connection Factories
The "ldapConnectionFactories"
field configures connection and authentication to remote servers:
More information
{
"ldapConnectionFactories": {
// Unauthenticated connections used for performing bind requests.
"bind": {
// Indicates whether LDAP connections should be secured using
// SSL or StartTLS. Acceptable values are:
//
// "none" - use plain LDAP connections (default)
// "ssl" - secure connection using LDAPS
// "startTLS" - secure connection using LDAP+StartTLS
//
"connectionSecurity": "none",
// This alias references a client SSL key-pair which will be used
// for performing client authentication (mutual TLS or mTLS) between
// between this gateway and the remote LDAP server.
"sslCertAlias": "client-cert",
// Re-usable pool of 24 connections per server.
"connectionPoolSize": 24,
// Check pooled connections are alive every 30 seconds with a 500ms
// heart beat timeout.
"heartBeatIntervalSeconds": 30,
"heartBeatTimeoutMilliSeconds": 500,
// The preferred load-balancing pool.
"primaryLdapServers": [{
"hostname": "localhost",
"port": 1389
}],
// The fail-over load-balancing pool (optional).
"secondaryLdapServers": [
// Empty.
]
},
// Authenticated connections which will be used for searches during
// authentication and proxied operations (if enabled). This factory
// will re-use the server "bind" configuration.
"root": {
"inheritFrom": "bind",
// Defines how authentication should be performed. Only simple
// and SASL/External authentication are supported at the moment.
// If the OAuth 2.0 authorization policy is configured below,
// then the directory service must be configured
// to allow the user configured here to perform proxied authorization.
"authentication": {
// The type of LDAP bind request to use, which must be "simple"
// (the default), "sasl-scram" or "sasl-external".
"policy": "simple",
"simple": {
"bindDn": "uid=admin",
"bindPassword": "password"
},
// SASL SCRAM mechanisms require the user's password
// to be stored using a compatible storage scheme.
"sasl-scram": {
// The SCRAM mechanism name, which defaults to SCRAM-SHA-256.
"scramMechanism": "SCRAM-SHA-256",
"bindDn": "uid=admin",
"bindPassword": "password"
// Optionally: "scramMinIterations": 2048
// to reduce the accepted minimum number of iterations.
}
// SASL/External does not have any configurable parameters.
}
}
}
}
Authorization
The "authorization"
field sets authorization policies for access to directory data.
It has the following top-level fields:
{
"authorization": {
// Authorization policies to use. One of "anonymous", "basic", or "oauth2".
"policies": [],
// Perform all operations using a pre-authorized connection.
"anonymous": {},
// Use HTTP Basic authentication's information to bind to the LDAP server.
"basic": {},
// Use an OAuth2 authorization method.
"oauth2": {}
}
}
The "anonymous"
object has the following settings:
More information
{
"anonymous": {
// Specify the connection factory to use to perform LDAP operations.
// If missing, the "root" factory will be used.
"ldapConnectionFactory": "root"
}
}
The "basic"
object has the following settings:
More information
{
"basic": {
// Indicates whether the filter should allow alternative authentication
// and, if so, which HTTP headers it should obtain the username and
// password from.
"supportAltAuthentication": true,
"altAuthenticationUsernameHeader": "X-OpenIDM-Username",
"altAuthenticationPasswordHeader": "X-OpenIDM-Password",
// Define which LDAP bind mechanism to use
// Supported mechanisms are "simple", "sasl-plain", "sasl-scram", or "search"
"bind": "search",
// Bind to the LDAP server using the DN built from the HTTP Basic's username
"simple": {
// Connection factory used to perform the bind operation.
// If missing, "bind" factory will be used.
"ldapConnectionFactory": "bind",
// The Bind DN Template containing a single {username},
// which will be replaced by the authenticating user's name.
// (For example: uid={username},ou=People,dc=example,dc=com)
// If missing, "{username}" is used.
"bindDnTemplate": "uid={username},ou=People,dc=example,dc=com"
},
// Bind to the LDAP server using a SASL Plain bind request
"sasl-plain": {
// Connection factory used to perform the bind operation.
// If missing, "bind" factory will be used.
"ldapConnectionFactory": "bind",
// Authorization identity template containing a single {username},
// which will be replaced by the authenticating user's name.
// (For example: u:{username})
"authzIdTemplate": "u:{username}"
},
// Bind to the LDAP server using a SASL SCRAM bind request.
// SASL SCRAM mechanisms require the user's password to be stored
// using a compatible storage scheme.
"sasl-scram": {
// Connection factory used to perform the bind operation.
// If missing, "bind" factory will be used.
"ldapConnectionFactory": "bind",
// The SCRAM mechanism name, which defaults to SCRAM-SHA-256.
"scramMechanism": "SCRAM-SHA-256",
// Authorization identity template containing a single {username}
// which will be replaced by the authenticating user's name.
// (For example: u:{username})
"authzIdTemplate": "u:{username}"
},
// Bind to the LDAP server using the resulting DN of a search request.
"search": {
// Connection factory used to perform the search operation.
// If missing, "root" factory will be used.
"searchLdapConnectionFactory": "root",
// Connection factory used to perform the bind operation.
// If missing, "bind" factory will be used.
"bindLdapConnectionFactory": "bind",
// The {username} filter format parameters will be substituted
// with the client-provided username,
// using LDAP filter string character escaping.
"baseDn": "ou=people,dc=example,dc=com",
"scope": "sub", // Or "one".
"filterTemplate": "(&(uid={username})(objectClass=inetOrgPerson))"
}
}
}
The "oauth2"
object has the following settings:
More information
{
"oauth2": {
// Access tokens associated realm.
// This attribute is optional and has a string syntax.
"realm": "myrealm",
// Defines the list of required scopes required to access the service.
// This field is required and cannot be empty.
"requiredScopes": [ "read", "write", "uid" ],
// Specify the resolver to use to resolve OAuth2 access token.
// This attribute is required and its value must be one of "openam", "rfc7662", "cts".
// Note that the JSON object corresponding to this attribute value must be present
// and well formed in the "oauth2" JSON attribute.
"resolver": "openam",
// Configures caching of access token introspection results.
// This attribute is optional, if it is not present, no token caching
// will be performed.
"accessTokenCache": {
// Indicates whether the access token caching should be used.
// This attribute is optional (default value is false)
// and must have a boolean syntax.
"enabled": false,
// Specifies the maximal caching duration for an access token.
// Once this delay is over, token will be refreshed from an access token resolver
// (see "oauth2/resolver").
// This attribute is optional, its default value is "5 minutes".
// The duration syntax supports all human readable notations from day
// ("days", "day", "d") to nanosecond ("nanoseconds", "nanosecond", "nanosec",
// "nanos", "nano", "ns")
// Any negative or zero values are incorrect.
"cacheExpiration": "5 minutes"
},
// The OpenAM access token resolver configuration.
// This attribute must be present if the "oauth2/resolver" is equal to "openam".
// If "oauth2/resolver" is set to another resolver, this attribute will be ignored.
"openam": {
// Defines the OpenAM endpoint URL where the request should be sent.
// This attribute is required and must have a string syntax.
"endpointUrl": "http://openam.example.com:8080/openam/oauth2/tokeninfo",
// This alias points at an existing certificate that is used for TLS authentication
// for secure communication between this gateway
// and the OpenAM access-token resolver.
"sslCertAlias": "client-cert",
// The default authzIdTemplate demonstrates how an authorization DN
// may be constructed from the "uid" field in the following example
// OpenAM tokeninfo response:
// {
// "scope":["uid"],
// "realm":"/",
// "expires_in":45,
// "uid" : "bjensen",
// }
// This attribute is required and has a string syntax.
// It must start with either 'dn:' or 'u:'.
"authzIdTemplate": "dn:uid={uid},ou=People,dc=example,dc=com"
},
// The RFC-7662 (see https://tools.ietf.org/html/rfc7662)
// access token resolver configuration.
// This attribute must be present if the "oauth2/resolver" is equal to "rfc7662".
// If "oauth2/resolver" is set to another resolver, this attribute will be ignored.
"rfc7662": {
// Defines the token introspection endpoint URL where the request should be sent.
// This attribute is required and must have a string syntax.
"endpointUrl": "http://openam.example.com:8080/openam/oauth2/myrealm/introspect",
// This alias points at an existing certificate that is used for TLS authentication
// for secure communication between this gateway and the introspection
// access-token resolver.
"sslCertAlias": "client-cert",
// Token introspect endpoint requires authentication.
// It should support HTTP basic authorization
// (a base64-encoded string of clientId:clientSecret)
// These attributes are mandatory.
"clientId": "client_id",
"clientSecret": "client_secret",
// The default authzIdTemplate demonstrates how an authorization DN
// may be constructed from the "username" field in the following example
// introspect response:
// {
// "active": true,
// "token_type": "access_token",
// "exp": 3524,
// "username" : "bjensen",
// }
// This attribute is required and has a string syntax.
// It must start with either 'dn:' or 'u:'.
"authzIdTemplate": "dn:uid={username},ou=People,dc=example,dc=com"
},
// The CTS access token resolver.
// This attribute must be present if the "oauth2/resolver" is equal to "cts".
// If "oauth2/resolver" is set to another resolver, this attribute will be ignored.
// Note: You can use {userName/0} in authzIdTemplate configuration to access
// user id from the default CTS access token content config.
"cts": {
// The connection factory to use to access CTS.
// This attribute must reference a connection factory
// defined in the "ldapConnectionFactories" section.
// Default value: "root"
// (That is, the "root" connection factory will be used to access the CTS).
"ldapConnectionFactory": "root",
// The access token base DN.
// This attribute is required and must have a string syntax.
"baseDn": "ou=famrecords,ou=openam-session,ou=tokens,dc=example,dc=com",
// The default authzIdTemplate demonstrates how an authorization DN
// may be constructed from the "userName" field in the following example
// CTS access token entry:
// {
// "active": true,
// "tokenName": ["access_token"],
// "exp": [3524],
// "userName" : ["bjensen"],
// }
// This attribute is required and has a string syntax.
// It must start with either 'dn:' or 'u:'.
"authzIdTemplate": "dn:uid={userName/0},ou=People,dc=example,dc=com"
},
// ONLY FOR TESTING: A file-based access token resolver.
// This attribute must be present if the "oauth2/resolver" is equal to "file".
// If "oauth2/resolver" is set to another resolver, this attribute will be ignored.
"file": {
// Directory containing token files.
// You can test the rest2ldap OAuth2 authorization support
// by providing JSON token files under
// the directory set in the configuration below.
// File names must be equal to the token strings.
// The file content must a JSON object with the following attributes:
// 'scope', 'expireTime' and all the field(s) needed to resolve the authzIdTemplate.
"folderPath": "/path/to/test/folder",
// The default authzIdTemplate demonstrates an authorization DN constructed
// from the "uid" field in a fake token file:
// {
// "scope": ["read", "uid", "write"],
// "expireTime": 1961336698000,
// "uid": "bjensen"
// }
// This attribute is required and has string syntax.
// It must start with either 'dn:' or 'u:'.
"authzIdTemplate": "dn:uid={uid},ou=People,dc=example,dc=com"
}
}
}
Gateway LDAP Features
A single rest2ldap/rest2ldap.json
file defines the LDAP features that the gateway uses.
The settings have the following defaults:
{
"useMvcc": true,
"mvccAttribute": "etag",
"readOnUpdatePolicy": "controls",
"useSubtreeDelete": true,
"usePermissiveModify": true,
"useServerSideSortForJson": true,
"returnNullForMissingProperties": false,
"localSortMaxEntries" : 1000
}
More information
Field | Description |
---|---|
|
Whether the gateway supports multi-version concurrency control (MVCC). If |
|
The LDAP attribute to use for MVCC. This lets a client application check whether this is the correct version of the resource with the header: If-Match: mvcc-value |
|
Specifies the policy for reading an entry after addition, after modification, and before deletion. One of the following:
|
|
Whether to use the LDAP Subtree Delete request control (OID: Client applications deleting resources with children must have access to use the control. When |
|
Whether to use the LDAP Permissive Modify request control (OID: Set this to |
|
Whether to use the LDAP Server-Side Sort request control (OID: When |
|
Whether missing (unmapped) JSON properties should be included in JSON resources. By default, a REST to LDAP mapping omits JSON fields for LDAP attributes that have no values. |
|
The maximum number of entries supported by the local sort mechanism. When a request includes a
|
API Configuration
Mapping files define APIs by defining how JSON resources map to LDAP entries. REST to LDAP lets you define multiple APIs, and multiple versions for each API.
A mapping file name has the form rest2ldap/endpoints/base-path/root-resource.json
:
-
The base-path must match the Rest2ldap endpoint
base-path
setting in the DS server configuration. -
The root-resource matches the root resource name in the API’s
"resourceTypes"
. -
Each file defines a single version of the API.
The sample API file rest2ldap/endpoints/api/example-v1.json
has the following structure:
{
"version": "1.0", // (Optional) version for this API.
"resourceTypes": { // (Required) resources for this API.
"example-v1": { // (Required) root resource type. Name must match file basename.
"subResources": { // (Required) The base path, /api, is implicit.
"users": {}, // All resource collections, such as /api/users/ and
"groups": {} // /api/groups/ are explicitly defined here.
}
},
// The sample also defines the resource types used by the root's "subResources".
// This is optional, but critical to readability of the "subResources" definition.
// Keep resource type names unique to avoid clashes with definitions elsewhere.
// See the full text of the sample to view how inheritance works.
"frapi:opendj:rest2ldap:object:1.0": {}, // Parent type of all objects.
"frapi:opendj:rest2ldap:user:1.0": {}, // Basic user type, parent of
"frapi:opendj:rest2ldap:posixUser:1.0": {}, // user with uid, gid, home dir.
"frapi:opendj:rest2ldap:group:1.0": {} // Basic group type.
}
}
The example API defines the following resource collections:
-
"users"
-
"groups"
For reference information, see Subresources.
The example API defines the following resource types:
-
"frapi:opendj:rest2ldap:object:1.0"
-
"frapi:opendj:rest2ldap:user:1.0"
-
"frapi:opendj:rest2ldap:posixUser:1.0"
-
"frapi:opendj:rest2ldap:group:1.0"
For reference information, see Resource Types.
Version
The optional "version"
field specifies the version of the root resource of the API.
For multiple versions of the same API, use multiple mapping files.
More information
Valid version strings include:
-
"*"
(Default, no version specified.) -
"integer"
-
"integer.integer"
Each integer is a positive decimal integer.
A client application requests a specific version by setting the request header:
Accept-API-Version: resource=version
If more than one version of the API is available, but the client does not specify a version header, REST to LDAP uses the latest version of the API.
Subresources
The "subResources"
object specifies the API under the current path.
A "subResources"
object has the following fields, shown with their default values:
{
"name": {
"type": "collection || singleton", // Required
"dnTemplate": "",
"glueObjectClasses": [],
"isReadOnly": false,
"namingStrategy": {},
"resource": ""
}
}
More information
Field | Description |
---|---|
|
The type, either A collection is a container for other resources that clients can create, read, update, delete, patch, and query.
When
A singleton is a resource with no children. When
|
|
The relative DN template where the LDAP entries are located. If this is an empty string, the LDAP entries are located directly beneath the parent LDAP entry. DN templates can use variables in braces |
|
One or more LDAP object classes associated with intermediate "glue" entries forming the DN template. Required if the DN template contains one or more RDNs. |
|
Whether this resource is read-only. |
|
How to map LDAP entry names to JSON resources. LDAP entries mapped to JSON resources must be immediate subordinates of the REST to LDAP supports the following naming strategies:
|
|
The resource type name of the subresource. A collection can contain objects of different types as long as all types inherit from the same super type. In that case, set |
Resource Types
The required "resourceTypes"
object maps resource type names to resource type definitions.
One of the resource type names must match the basename of the mapping file. This resource is referred to as the root resource of the API.
More information
You can reuse a resource type name when specifying the same definition in different mapping files.
For example, all mapping files might define the abstract base type frapi:opendj:rest2ldap:object:1.0
,
and use this everywhere as the superType
for other resource types.
If the definitions differ, however, you must use a different resource type name for the changed resource type.
For example, if you add a new user type in another API based on frapi:opendj:rest2ldap:user:1.0
,
but with a different definition.
If you still use the original resource type in your APIs, you must also use a different name for your new user type.
Examples in the sample mapping file use the namespace prefix frapi:opendj:rest2ldap:
.
You may use any string allowed in JSON.
REST to LDAP does not provide a mechanism for inheriting resource types between mapping files. To reuse a resource type from another mapping file, manually copy its name and definition, taking care to change the name if you change the definition.
A resource type definition object has the following fields. All fields are optional, and have the default values shown here:
{
"unique-name": {
"properties": {},
"subResources": {},
"isAbstract": false,
"superType": "",
"objectClasses": [],
"supportedActions": [],
"includeAllUserAttributesByDefault": false,
"excludedDefaultUserAttributes": []
}
}
More information
Field | Description |
---|---|
|
Map of property names to property definitions. For details, see Properties. |
|
Map of subresource names to subresource definitions. The names are URL path templates, setting the relative path where the subresources are located.
URL path templates can set variables in braces
You can define a DN template, Given the paths relative paths:
REST to LDAP substitutes For details, see Subresources. |
|
Whether this is an abstract resource type used only for inheritance. |
|
The resource type that this resource type extends. Resource types that extend another type inherit properties and subresource definitions. |
|
LDAP object classes names for the LDAP entries underlying the JSON resource. On creation, REST to LDAP adds these to the object classes on the LDAP entry. The LDAP object classes are never visible in the JSON resource. |
|
Names of the DS-specific ForgeRock® Common REST actions that this resource type supports. Action names must match the actions allowed on the resource in the underlying implementation:
|
|
Whether to include all LDAP user attributes as properties of the JSON resource. When |
|
LDAP user attributes to exclude when |
Properties
The "properties"
object specifies how the JSON resource maps to the underlying LDAP entries.
A "properties"
object has the following fields, shown with their default values:
{
"name": {
"type": "See the list below.", // Required
"baseDn": "",
"defaultJsonValue": "",
"extensibleJsonOrderingMatchingRule": "",
"isBinary": false,
"isMultiValued": false,
"isRequired": false,
"jsonQueryEqualityMatchingRule": "caseIgnoreJsonQueryMatch",
"ldapAttribute": "name",
"mapper": {},
"optionalJsonPropertyName": "",
"primaryKey": "",
"propertyName": "",
"resourcePath": "",
"schema": "",
"searchFilter": "(objectClass=*)",
"value": "",
"writability": "readWrite"
}
}
The "type"
must be one of the following:
-
"constant"
-
"json"
-
"object"
-
"reference"
-
"reverseReference"
-
"resourceType"
-
"simple"
More information
Field | Description |
---|---|
|
The type, which determines the fields the object has:
|
|
The base LDAP DN where REST to LDAP finds entries referenced by the JSON resource. Base DN values can be literal values, such as
|
|
A JSON value to return if no corresponding LDAP attribute is present. |
|
The JSON ordering matching rule to use when requesting an extensible server-side sort. The default rule will ignore case and whitespace when sorting values of JSON fields. For a description of the extended server-side sort syntax, see Server-Side Sort. |
|
Whether the underlying LDAP attribute holds a binary value, such as a JPEG photo or a digital certificate. When |
|
Whether the field can take an array value. Most LDAP attributes are multi-valued. A literal-minded mapping from LDAP to JSON would be full of array properties, many with only one value. To minimize inconvenience, REST to LDAP returns single value scalars by default, even when the underlying LDAP attribute is multi-valued. By default, the JSON resource gets the first value returned for a multi-valued LDAP attribute. When |
|
Whether the LDAP attribute is mandatory and must be provided to create the resource. |
|
When a query filter in the HTTP request uses a JSON path that points to a field in a JSON attribute value, it uses the matching rule specified by this property to compare the query filter with attribute values:
|
|
The attribute in the LDAP entry underlying the JSON resource. By default, REST to LDAP assumes the JSON field name matches the LDAP attribute name. |
|
How the referenced entry content maps to the content of this JSON field. A mapper object can have all the fields described in this table. |
|
Use this when creating a reference for an attribute that has REST to LDAP returns optional JSON from the attribute as the value of a property having the name you specify.
For example, if you configure Suppose the LDAP entry contains an attribute with this syntax,
|
|
Indicates which LDAP attribute in the mapper holds the primary key to the referenced entry. |
|
Name of another field of the JSON resource. |
|
A path to another JSON resource. Resource path values use the following notation:
|
|
Specifies a JSON Schema that applies values of type When no schema is specified, REST to LDAP accepts arbitrary JSON values. |
|
The LDAP filter to use when searching for a referenced entry. |
|
Use with |
|
Whether the mapping supports updates:
|