On this page:

8.4LDAP Inbound Security Module


The LDAP Inbound Security module can be used to delegate authentication decisions to an external user directory – such as a Microsoft Active Directory server or an OpenLDAP directory.

Unlike the Local Inbound Security module, the LDAP Inbound Security module authenticates against an external directory, and it does not store any passwords in the Smile CDR database.

This type of authentication is useful when deploying Smile CDR in an enterprise context since many organizations have a corporate user directory that allows users to use the same credentials across multiple servers.

Note that each user account that is successfully authenticated by the LDAP server will have a corresponding entry created in the Smile CDR User Database. This locally stored account will not store credentials and cannot be used directly for authentication but it is needed in order to provide a reference point for audit log entries, etc.



In order to connect to an LDAP server, Smile CDR requires credentials for a system account in the server that it will use to locate accounts, look up groups, etc.

Mandatory Group

If only a subset of users in the LDAP server should have access to Smile CDR, you may wish to create a group in the directory for this purpose, and add all relevant users to this group. The CN for this group should then be listed in the authenticator.require_group_membership.dn configuration property.

In this scenario, any user who is not a member of the given group will not be permitted to authenticate via this module even if they supply correct credentials.



In most cases, simply authenticating is not sufficient to provide useful functionality. A user also requires permissions in order to perform actions within Smile CDR.

There are several ways that a user can be granted permissions:

  • Global Permissions – Any permissions configured as global permissions will be automatically granted to any users who authenticate via this module.
  • Native Permissions – An LDAP user attribute may be declared in Smile CDR configuration to be a native permission user attribute. With this setting, values in this attribute will be treated as Smile CDR permissions that should be granted to that user. For example, if the smileCdrPermission LDAP attribute is configured as a native permission attribute and a user in the LDAP server has a smileCdrPermission attribute with a value of FHIR_ALL_READ, that user will be granted the FHIR_ALL_READ permission.
  • Local Permissions – After a user has successfully authenticated at least once, they will have an entry in the Smile CDR User Database. Permissions may be directly assigned to the user via the Web Admin Console or the JSON Admin API User Management Endpoint.

8.4.3Callback Scripts


If Authentication Callback Scripts are being used by this module, the context object will have functionality that can be used to directly examine attributes in the LDAP record that the user authenticated with.

See SecurityInLdapAuthenticationContext for the available properties and functions on the context object.

The context.getStringAttributes(theAttributeName) method returns an array of attributes for a given LDAP attribute name. For example:

function onAuthenticateSuccess(theOutcome, theOutcomeFactory, theContext) {
   if (theContext.getStringAttributes(\"adminUser\").contains(\"true\")) {
   return theOutcome;



A complete reference of configuration items follows: