Security Settings
| Info |
|---|
Security settings allow a user to configure policies governing security-related system features, ranging from creating API keys for client applications, to setting-up user roles and inviting users. The configurable security settings vary depending on the logged-in user’s organisation level (i.e. a user logged-in at Service Owner level will not see the same configuration options as someone logged-in at Business level). |
Security features are configured and managed via the Settings option. This manual covers all available security settings from Cloud Operator level to Merchant level with an indication of which options are available per organisation.
To configure your Security settings click on your logged-in user name in the top right-hand-corner of the screen > Settings > Security.
User Roles and Users
| Status | ||
|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
Users are the people who perform the day-to-day tasks (e.g. process service requests/orders, monitor performance, setup configuration), either through the User Interface or Web APIs, subject to business network and security restrictions.
User Roles are a group of permissions assigned to users and define the access that users have throughout the system (e.g. to manage Contacts, to configure Reward Offers).
Admin User Role
Upon creation of an Organisation (e.g. Service Owner, Business, Merchant/Service Provider), an Admin (owner) user role with full access permissions granted is automatically created. Such a User Role is assigned to each user who registers an Organisation, or explicitly to users who are invited to join an organisation.
User Roles
Create new User Roles and assign the relevant permissions, prior to inviting users to join the Organisation.
Navigate to Settings > Security > User Roles > Create User Role
Provide a unique name for the User Role
Enable the respective toggle to allow access to a particular area of the system
Access can be restricted to specific actions too
Save your User Role
Ensure that you have considered all available options and enabled/disabled access accordingly.
Users
Inviting a User to join your Organisation in effect creates a User with permissions to navigate the system based on the User Role assigned to them.
Settings > Security > Users > Invite User
Complete the user details
Select the User Role
Save to submit the invitation
The new user will receive an email informing them that they have been invited to join an Organisation, they must follow the email verification procedure in order to create a password and be able to access the system. The user's credentials for signing-in to the system is the email they have been invited with, and the password they have chosen.
Users have the ability to access their ‘owned by’ Organisation’s data, and any other child Organisations data ‘owned by’ their Organisation (using masquerade). Refer to the Business Network manual for further details on masquerading.
API Keys
| Status | ||
|---|---|---|
|
| Status | ||||
|---|---|---|---|---|
|
API Keys
API Keys are unique identifiers that allow a client application (e.g. mobile app, external system) to consume CRM.COM’s Web APIs (back-office/self-service).
Navigate to Settings > Security > API Keys
Public Keyis used solely as an organisation identification allowing users to consume self-service APIs, e.g. you’ll need such a key if your customers will be using a consumer app
Secret Key should be kept confidential and is used for performing business actions in CRM.COM, such keys fall under security restrictions and permissions
Multiple public and private keys are supported.
| Anchor | ||||
|---|---|---|---|---|
|
A webhook is an automated call to a server providing real time information for a CRM.COM entity, without requiring additional integration. These calls are triggered when a specific event happens.
Each webhook request can be protected with additional authentication security, such as username/password or API Key.
A webhook request can have one of the following states:
Pending - The webhook request has been created and awaiting to be sent (queued)
Success - The webhook request was successfully sent and received by the external application
Failed - The webhook request was not sent to the external application successfully (an error description is logged for investigation purposes)
Refer to the Automations manual for more information on Events and Webhooks.
Advanced
| Status | ||||
|---|---|---|---|---|
|
Password Policy
Service Owner users have the option to enable a password expiration policy whereby users must reset their passwords upon expiration.
Concurrent Session Policy
Service Owner users have the option to enable a concurrent session policy whereby users are enforced to have a maximum number of active sessions.
Core Behaviour
The following security features are not configurable by the system users, but are implemented as part of CRM.COM core behaviour of the system.
Strong Password Policy
This is a mechanism that provides the ability to support only strong passwords for contacts and users alike.
Contact Strong Password Policy Rules
Maintain an 8-character minimum length
Support alphanumeric characters
Support special characters
Do not allow
a A sequence of characters or numbers (e.g. “abcdefg” or “123456”)
the The previously used password
User Strong Password Policy Rules
Maintain an 8-character minimum length
Support alphanumeric characters
Support special characters
Mandatory to have at least
one One upper and lower case character
one One number
Do not allow
a A sequence of characters or numbers (e.g. “abcdefg” or “123456”)
the The previously used password
Password Lockout
This is a mechanism that provides the ability to lockout a user after a number of invalid login attempts. When a user is locked out they are not able to login for a pre-defined period of time.
User Password Lockout Policy Rules
After 5 failed attempts to authenticate using an invalid password (given that username is valid) and such attempts are made within 15 minutes, the user is put under lockout and cannot authenticate (even with correct username/password)
User lockout period is lifted automatically after 30 minutes or manually by an another authorised user
Two-Factor Authentication (2FA)
2FA is an extra layer of security whereby two distinct forms of identification are required in order to provide a user access to a system, e.g. aside from a username and password, users will be required to provide another piece of information that can be retrieved either by an external authentication application (e.g. Google Authenticator), or in the form of an OTP (via phone or email) to gain access to a system.
2FA can be configured at the Service Owner level or the Business level. Eligible users have the ability to configure one or multiple 2FA methods.
Reference Material
You may also find it useful to refer to the following manuals for further reading in relation to Security.
Business Network
TABLE OF CONTENTS
| Table of Contents |
|---|