Security includes: The Authentication of users to ensure only the right users are allowed into the system, Privacy to ensure no-one is listening in on authenticated users and hijacking sensitive data, and Authorization to set up detailed access rules for authenticated users and to restrict their access to specific data records, documents and fields.

Digital-Clay offers the following security features for authenticating users:

• Username/password authentication using a challenge-response protocol.
• Hashed/encrypted passwords. Clear passwords are never sent to or stored by ClayCentral.
• A secure authentication protocol that thwarts eavesdroppers and replay attacks.
• Strong hashing techniques that make rainbow attacks impossible, and brute force or dictionary attacks difficult.
• Optional enforcement of password policy rules:
  • Password minimum length.
  • Password minimum complexity.
  • Automatic password expiration.
  • Password histories to prevent password re-use.
  • Manual password expiration.

Keep in mind that even the strongest authentication mechanism is only as strong as its weakest link. Digital-Clay ensures that the authentication procedure is secure, but the following must be handled by the administrator to ensure security:

• Use as many of the above password policy enforcement rules as possible. Never add users with blank passwords.
• Ensure users do not share or write down their passwords. If they forget their passwords, they should simply ask for new ones.
• Restrict access to the machine running Central both physically and remotely over the network.
• If you are using SQL Server, ensure that only ClayCentral can access the database and that remote access to the database is disabled (unless ClayCentral is on another machine). At the very least, use a secure SQL Server password.
• Make sure that all backups and copies of the database are secured as well.
• Restrict access to machines running Digital-Clay clients with secure Windows usernames/passwords etc. This is to secure the data in offline databases. If the client machines are not secure, you should not use the Remember Password feature in the Digital-Clay Login dialog.
• Use smart network switches and the latest networking firmware to make packet sniffers, hijackers and spoofed addresses difficult.

Note that the only absolute foolproof way to verify end-to-end communications with any program is by using SSL with mutual signed certificates at both ends using certificate authorities, or by manually managing and verifying each client's public key. This functionality would mean much more manual adminstration work and may be supported by Digital-Clay in the future, but careful implementation of the above techniques should block practically all hacking attempts.

Digital-Clay offers optional encryption of data sent via TCP/Mail. Data is normally never sent as clear-text over the network, and passwords are always sent in a secure fashion regardless of the encryption setting, but on networks where the data is sensitive and eavesdropping hackers are a concern, this ClayCentral setting should be switched on. Data will then be encrypted using secure session keys.

Also see above regarding securing the database, including remote access to SQL Server. Only ClayCentral needs to have any access to its database.

Authorization for accessing or changing data can be configured using multiple levels of permissions. Authorization permissions include the following elements and layers:

• The Role defines which set of Permission rules apply to a user. Roles are set up using the Roles tool in ClayStudio, and by selecting a Role in the User's role drop-down.
• The Permissions define access rules per Role per Table. Permissions are set using the Permissions tool in ClayStudio.
• The Action defines what exactly the Role/User is allowed to do based on the Permission.
• The Relationship of the User to the data defines which permission rules apply per record. See below for more details regarding Relationships.
• The User's Primary and Associated Workgroup fields, together with the User field(s) per record defines the User's Relationship to the data.
• Field Properties like Read-Only or Hidden Value define Permissions at a field level per Table per Role. See below for more details.
• Document Type permissions define read-access for individual Attachments/Documents per Role. This is configured in ClayStudio via the Data/Document Types menu.
• Repository Folders each have their own Role permissions. This is configured using the Document Repository tool in any Digital-Clay client.

Using all the above, very fine-tuned permissions can be setup. Examples:

• A Team Member (role) can View (action) all of his Workgroup's (relationship) Contacts (table), but can only Change (action) his Own (relationship).
• A Manager can change all Tasks of people belonging to his Workgroup, but can view Opportunities that belong to any of his Associated Workgroups (e.g. Sales from other regions that he is associated with).
• An Analyst can view all Customer records belonging to Workgroups he is associated with but can't open Price Quotes (Document Type) attached to those Customers.
• A Restricted User can read all Contacts, but not see the Hidden-Value Email field for those Contacts.

Note that in addition to security permissions, Automation Validation rules can be setup to block adding, changing or deleting of data based on advanced filters!

As mentioned above, relationships define the connection between a user and an individual record. Each record may have different values such as a different Owner or a different Manager, and the relationship to this specific record is defined by how the current user is linked to that specific Owner or Manager.

For example, let's say that permissions in the Contacts table needs to be defined by either the Contact's Owner, or the Contact's Customer's Assignee. A role called 'Restricted' may be set up that only allows users from this role to read Contacts either if they are the Owner of the Contact, OR if they belong to the same Workgroup as the Assignee. This would allow users to read either Contacts that they own, or that are assigned to their department.

Note that up to version 9.2, relationships could only be defined using the built-in Owner/Assignee/Team fields in each record. As of 9.2, relationships may be defined using ANY custom field that is a linked field to the Users table, even custom fields that are in linked tables. So, for instance in the above example, a custom field can be added to the Contact's Customer called 'Manager' and permissions may be set based on that field as well.

A user may have the following relationships to another user:

• 'Any' means regardless of the relationship, the user can run the action on the record.
• 'Self/Owner' means that the user himself is set in the field and record he is trying to act on. E.g. the current user IS the Owner, or he IS the Manager of that record.
• 'Own Workgroup' means that the user in the record belongs to the same primary Workgroup as the user who is running the action. For example, the Assignee of the Customer is in the same department as the current user trying to access the record.
• 'Associated Workgroups' means that the user in the record belongs to a primary Workgroup which the user is Associated with (via the 'Associated Workgroups' field in the User table). Note that Associated Workgroups is a many-to-many field which allows extra permissions to be added to a user. E.g. a User can belong to the Sales department, but can be given access to Projects from the R&D department by adding R&D as one of his Associated Workgroups.

The following field properties are security related and are enforced by ClayCentral:

• Read-only: The user/role can see the field value, but can't change it even though he has Change permissions.
• Hidden-Value: The user can't see the field value and can't change it. This includes lists or aggregated analysis results!

'Required' is a validation field property. 'Hidden' is only a client-based GUI property that makes the field invisible on the data form, and does not affect security.

Field security is checked along with record permissions so that even if the user is able to view a record, he may not be able to view a specific field value inside that record.

Documents attached to a record depend on the permissions for the record itself as well as specific Document Type permissions. I.e.:

• A user may only open the attachment if he has read permissions for the record to which it is attached.
• A user may only change/add/delete attachments if he has Change permissions for the record.
• Even if he can view the record, individual Attachments in that record may be blocked from viewing using the Document Type Permissions per Role. E.g. a document of type 'Price Quote' can be blocked for all users of Role 'Restricted User' even though they can view the Opportunity and all of the other Opportunity Attachments. Note that the user will see the document listed but will not be able to view its contents.

Documents stored in a public folder in the Document Repository are similar to the above regarding authorization and depend on the permissions set for that specific folder as well as specific Document Type permissions.

Merging is a special action performed on records and in order to successfully perform a merge, a user must have the following permissions:

• Merge permission on the source record (the record being deleted and merged into another record).
• Change permission on the destination record
• Automation Validation Change rules must pass for both the source AND destination records.
• Any of the fields being changed due to the merge must not have a Read-Only/Hidden Value field property set.