15.3    Inbound Security Module
  • Security
  • 15.0 Security in Smile CDR
  • 15.1 Authentication Protocols
  • 15.2 Authorization and Consent
  • 15.3 Inbound Security Module
  • 15.4 Local Inbound Security Module
  • 15.5 LDAP Inbound Security Module
  • 15.6 Scripted Inbound Security Module
  • 15.7 SAML Inbound Security Module
  • 15.8 Trusted Client Mode
  • 15.9 Roles and Permissions
  • 15.10 Callback Scripts
  • 15.11 Anonymous Access
  • 15.12 Consent Service
  • 15.13 Consent Service: JavaScript API
  • 15.14 Consent Service: Java API
  • 15.15 Security Recipes
  • 15.16 Two Factor Authentication
  • 15.17 Troubleshooting Security
    • 15.5    LDAP Inbound Security Module   
       Table of Contents

    Local Inbound Security Module

    15.4.1Local Inbound Security Module

     

    The Local Inbound Security module stores user accounts locally in Smile CDR's administrative database. When using this module, Smile CDR acts as a completely self-contained CDR and User Management system. This can be useful when deploying Smile CDR in circumstances where no existing user database or identity management platform is present.

    By default Smile CDR creates a Local Inbound Security module, and seeds it with a single administrative user named admin. You may use the Web Admin Console or the JSON Admin API to create and modify users.

    15.4.2Configuration: Credentials

      Credentials

    When storing usernames in the database, the module can optionally normalize them so that checks will be case insensitive. This is disabled by default, and it can be enabled by setting Username Case Sensitive to true.

    When storing passwords in the database, the module can optionally normalize them so that checks will be case insensitive. This is enabled by default, and it can be disabled by setting Password Case Sensitive to false.

    Passwords will be stored in the database using a salted hash, and the salt is randomly generated for each individual password. By default the hashing algorithm used is a 10-round bcrypt. This can be changed by modifying the Password Encoding Scheme value.

    15.4.3Caching

     

    One important thing to note when updating user accounts is that the system caches user credential hashes for a short period of time in order to improve performance. Any changes to a user account (i.e. changing a password, modifying the user's permissions, etc.) may take a few seconds to propagate across the cluster.

    15.4.4User Self Registration

     

    This module can optionally be configured to allow users to self-register. Self registration is available via the SMART Outbound Security module when it is paired with the Local Inbound Security module.

    To enable self registration, the Self Registration Enabled setting must be enabled. In addition, a callback script must be supplied using the User Self Registration Script properties.

    15.4.4.1Hide the SignUp Button

    The user can provide a list of comma separated URLs that will hide the SignUp button on the Login page when the referer URL of the Login page is in the list.

    A place where this feature can be useful is for App Gallery setup. For example, http://localhost:19300/console/ can be provided in this field to disable user registration for the App Gallery Admin Console.

    15.4.4.2Function: onUserSelfRegistrationRequest

    This function is called when a user requests a self-registration. It is used to generate an account for the new user.

    15.4.4.2.1Parameters

    15.4.4.2.2Example

    function onUserSelfRegistrationRequest(theInputUser, theOutputUser) {

    // Copy standard demographics
    theOutputUser.familyName = theInputUser.familyName;
    theOutputUser.givenName = theInputUser.givenName;
    theOutputUser.email = theInputUser.email;

    // Add any permissions you want the user to have by default
    // in a newly created account. Be very careful not to 
    // assign permissions that would be inappropriate for a new
    // user to have!
    theOutputUser.addAuthority('FHIR_CAPABILITIES');

}

    15.4.4.3Resetting User Password

    The user self registration landing page provides the capability for existing users to reset their password. Upon requesting a password reset, the user will be asked to provide the username that he/she usually log in with. Following successful username validation, a one time use and user specific 6-digit code is sent to the email address linked with the account. Entering the provided identification code will allow the user to supply a new login password.

    Notes regarding password reset:

    • As mentioned above, a user specific 6-digit identification code can only be used once;
    • Requesting a new identification code will void any issued and unused user specific identification code;
    • At any point during the reset password flow, the user can decide to cancel the operation without affecting their account status.
       15.3    Inbound Security Module
  • Security
  • 15.0 Security in Smile CDR
  • 15.1 Authentication Protocols
  • 15.2 Authorization and Consent
  • 15.3 Inbound Security Module
  • 15.4 Local Inbound Security Module
  • 15.5 LDAP Inbound Security Module
  • 15.6 Scripted Inbound Security Module
  • 15.7 SAML Inbound Security Module
  • 15.8 Trusted Client Mode
  • 15.9 Roles and Permissions
  • 15.10 Callback Scripts
  • 15.11 Anonymous Access
  • 15.12 Consent Service
  • 15.13 Consent Service: JavaScript API
  • 15.14 Consent Service: Java API
  • 15.15 Security Recipes
  • 15.16 Two Factor Authentication
  • 15.17 Troubleshooting Security
    • 15.5    LDAP Inbound Security Module