By default a running CDP system can be accessed (connected, inspected and administrated) by anyone who has access to the network where the system is running.
For mission critical systems the access should be limited to the authorized personnel only - this can be done using Security configuration.
The Security configuration allows you to configure users and their authentication and authorization and also configure the communication encryption.
The Security configuration can be found in Configure mode by clicking on the Security configuration tab .
Note: If your CDP system is too old, you might need to upgrade its version first to activate the Security configuration tab.
Encryption and Privacy
In the Encryption and Privacy settings table you can configure communication encryption.
|Use Encryption||Check this option to make CDP encrypt data exchanged via StudioAPI (e.g. via CDP Studio online connect). Encryption ensures that the communication can not be revealed by eavesdroppers.|
|Server Certificate File and Server Private Key File||StudioAPI server TLS certificate and corresponding private key file name. Key-pair and corresponding self-signed certificate will be auto-generated at application startup if they are missing from the application folder. In multi-application system, every application has its own unique private key and certificate. CDP Studio will remember the application certificate at first connect and will warn you in case the certificate has been changed later on.|
|CA Certificate File||Certificate issuer TLS certificate authority (CA) file name. This setting can be used by organizations that have separate key and certificate management systems and a certificate authority in place. When the CA Certificate File is set then the CDP application TLS certificate will be verified at every connect to be signed by that CA certificate.|
|System Use Notification||When configured, a connect confirmation prompt with this text will be displayed to all users on connect. Subset of HTML can be used to format the text, like:|
Note: All certificate files have to be in PEM format.
If you use CA Certificate File and/or your own Server Certificate File and Server Private Key File you have to deploy the files to the application folder. The files can be set up for automatic deploy by CDP Studio like this:
- copy the certificate and key files into the corresponding CDP application folder (using any file management tool)
- add the files to the application project in CDP Studio by right-clicking in Code mode onto application name and then choosing Add Existing Files...
In the Authentication settings table you can configure the user authentication parameters.
|Require Authentication||Check this option to make CDP to allow only users configured in Users table to connect via StudioAPI (e.g. CDP Studio online connect). When authentication is set required, then any connection attempts without correct credentials provided will be denied.|
|Invalid Attempt Limit||Number of invalid login attempts after the user new login attempts will be blocked. Set to 0 to allow users to endlessly try to login in.|
|Blockout Period||Number of seconds to prevent the user for trying new logins, after invalid login attempt count has been reached.|
|Idle Lockout Period||Number of seconds after which session will be locked out and will need re-authentication. Set to 0 for session to never lock out being idle. Enabling session lockout period also disables the possibility to temporarily remember the password in client applications (like CDP Studio).|
|Audit Log||Specify what type of events need to be logged. On Linux logs are posted to Syslog (auth facility more specifically). On Windows logs are posted to Event Log (the "CDPTech" under "Application and Services Logs" more specifically). When using Windows Event Log, CDP applications must be started once with administrator privileges, to allow writing to Event Log.|
Note: You can not set Require Authentication when there are no valid users configured as this would make system inaccessible. Note, that the user will become valid only after the password is set and at least one role is assigned.
In the Password Settings table you can configure the password parameters.
|Minimum Length||Minimum password length. Passwords having a number of symbols less than this minimum can not be set.|
|Expiry Time||Number of days after a password will expire and needs to be changed. Set to 0 for passwords to never expire.|
|Warn Time||Number of days before the password change deadline, when the system will start warning users about the need to change the password.|
|Complexity Check||Do not allow to set too simple passwords that are too easily crackable (are too simplistic, too commonly used or are based on a dictionary word).|
|History Length||Number or recently used passwords that user cannot re-use.|
The Users table lets you administrate (i.e. add, remove or change) an unlimited number of users who can log in to the running CDP system.
|Username||Unique Username of the user. This Username together with other credentials (like password) is used to identify the user at login time.|
|First Name and Last Name||Set given names of the user.|
|Disabled||Set this flag to temporarily disable the user access.|
|No Expiry for Password||Use this flag to override the default password expiry rule set (so that this user password will never expire).|
|Set Password||Use this button to set the user password.|
Note: When administrating other people's accounts and setting their passwords you should use the flag Temporary (to be changed at first login) - this forces the other user to change the password at first login, therefore making it known only by him/her.
User roles are used to separate two different security aspects - the authentication (i.e. determining who a user is) from the authorization (i.e. determining what the user is allowed to do in the system).
In the Roles table you can configure what are the different roles that different users can have in the CDP system. Each role has some default permissions for all CDP nodes. In addition to the default permissions, it is possible to assign different permissions for different roles for every CDP node (e.g. every component, signal, operator etc.) (see also RolePermissions).
|Name||Unique name of the Role. This name is used to refer to the role in the Role Mappings table and also while adjusting role permissions by RolePermissions field.|
|Default Permissions||Default permissions for the role. These permissions apply for nodes that have no specific permission configuration for this role.|
|Description||Text field, that can be used by an administrator do describe the purpose of the role|
The following default permissions can be enabled for every role:
|B - Browse||Allows to see node children list|
|R - Read||Allows to read node value|
|W - Write (Excluding Permissions)||Allows to write node value. This permission does not allow to change node permissions in running CDP system (see permission P).|
|C - Add and Remove Children||Allows to add or remove children (for nodes that have adding or removing support in running CDP system)|
|P - Permission Write||Allows to change permissions in running CDP system|
Default Permissions field can be edited by toggling checkboxes - then the permission letters in the field are altered accordingly.
Every fresh CDP System has 5 roles predefined:
|ConfigureAdmin||By default allows to view, change and add/remove everything but permissions|
|SecurityAdmin||By default allows to change only permissions|
|EndUserAdmin||Intended to manage (including add/remove) all users except system users (those having ConfigureAdmin or SecurityAdmin role)|
|Operator||By default allows to view and change everything (but no add/remove)|
|Observer||By default allows to view everything|
Note: Note, that these predefined roles can be changed (or even removed) in any way for your specific needs.
One or many different roles can be assigned to user depending on what host the user is logging in from. Every user must have at least one role assigned to be able to log in.
Role Mappings table can be used to add role assignment rules to users.
|Role Name||Role name assigned to user (or multiple users)|
|Usernames||One username or semicolon separated list of usernames that apply via this mapping|
|From Hosts||Host IP address, semicolon separated list of IP addresses or IP address match pattern. Defaults to asterisk sign (*), which maps the role regardless of the host that the user is logged in from. Host specific role mapping can be used to map some mission-critical role (e.g. SecurityAdmin) to the user only when he/she logs in from some specific host.|
|Disabled||Can be used by administrator to temporarily disable this role mapping|
|Description||Text field, that can be used by administrator do add notes to the role mapping|
To assign a new role to the user, first choose one from existing role names from the selection box , then press to add the mapping and then edit the added empty mapping - type in the username (or semicolon separated list of usernames), and modify from host match pattern if needed.
Note: Note, that for easy role mapping rules verification currently mapped roles can be inspected in the Users table column Roles Mapped and in Role table column Users Mapped .
Different CDP nodes (e.g. components, signals, operator etc.) can be configured to have different permissions for different roles. For example, system can be configured so that some signals (or components or operators) are read-only for some less privileged user roles and totally hidden for even less privileged roles.
To accomplish that, a granular permissions node-level RolePermissions field has to be configured.
RolePermissions field is a semicolon separated list of expressions in form:
When user logs into the CDP system, effective permissions for every role mapped for him/her are calculated as follow:
- When RolePermissions field is not set then its parent node permissions apply
- When no parent has RolePermissions field set then the role default permissions apply
- RolePermissions field sets the permissions only for the roles implicitly mentioned. For example, expression Permissions="Operator=R" does not change the permissions for other roles than Operator - they will be the same the parent node has. If you need to change all roles permissions, then special All notation can be used (for example, to remove permissions from all roles except for ConfigureAdmin use expression RolePermissions="ConfigureAdmin=*,All=").
- The operator + in front of permission letters causes the following permissions to be added to the existing permissions
- The operator - in front of permission letters causes the following permissions to be removed from the existing permissions
This effective permission calculation is illustrated in the following diagram.
In CDP Studio you can edit the RolePermissions field expression conveniently just by checking permission checkboxes. In this editor you can see what permissions are effective at current node level via inheriting. These inherited but unchanged permissions are shown as greyed out checkboxes. You can toggle (remove or add) any permission checkbox of any role to be different from that inherited state - then RolePermissions expression is altered accordingly for you and checkbox turns to be not greyed out any more. There is also a separate column to toggle all permissions for roles and also a row to change a permission for all roles. Finally, there is also a checkbox to toggle all permissions for all roles.
Note: You can see the state of the inherited permissions even without opening the editor - from the tooltip that pops up when you hover the field with mouse.