Your data is securely stored in your database and we want to ensure that it keeps secure when integrating with your content manager. We have designed our solution to meet stringent security criteria and ensure only authorized entities can access the data. In addition, we have defined a very strict process in the information life cycle in order to ensure data integrity.

From a security standpoint our design criteria is tight integration with the database security model. This ensures a predictable security schema where the security principles of your application are not broken by the fact that a new content repository is added to the equation.

Data access

Going through the details:

  • Database schemas: we only create one additional schema and user (docxtend) where only configuration information and a shared secret mechanism is stored. The only external entity that is required to connect to the database with this user is the docXtend agent. The user credentials are explicitly defined at setup (so you can ensure they follow your organization specific security policies) and stored encrypted. In any case, this user has minimal grants and, very important, has no access to any actual application data schema.
  • Shared secret and key pair: the docXtend agent requires authentication credentials for any BLOB read operations. Those shared secrets are securely generated and stored at the database so, only the docXtend agent and the database schema owner has access to read it. This connection (database to docXtend agent) can be configured to use https protocol so the content connections are encrypted. In addition, some operations are secured with a public/private key pair created and stored at the database during setup.
  • CLI operations: All the CLI operations (move, rollback …) that move actual data to the content manager, requires database schema credentials (the credentials of the database user the data belongs to). This way, we ensure only a user with those credentials can execute those operations. Those credentials can optionally be stored for convenience in a user profile specific file in the server where we run the CLI (this way you do not have to specify the credentials in every command); in that case, they are stored encrypted. By default, keys are not stored and are requested for any CLI operation.
  • Content manager credentials: docXtend stores content at the content manager with specific user credentials (that can be customized in a per table basis). This way, any content moved to the content manager can be secured and access policies defined at the ECM platform level for ensuring the correct visibility.

Data integrity

Our solution design is ensuring we don’t break DB transactional consistency in common application operations. We ensure transactional consistency at database level both in normal CRUD operations (insert, read, update, delete) and through move/rollback processes (“move” is the operation of transferring content from the database to the content manager; “rollback”, in this specific context is the reverse operation, it has nothing to do with the database transactions).

SQL inserts or updates issued by your application will leverage the same transactional boundaries as before and committed by the database. Only after that, the operation is logged for content transfer and a recurring job will be activated (every minute) for moving that content to the document manager. Again, opening an isolated transaction; so if any problem arises with that operation, it is rolled back and retried later on. In fact, when moving the content to the content manager the operation is only confirmed after trying to retrieve it through the database successfully and checking that the content retrieved is the same. Updated content, depending on your license, configuration and ECM platform capabilities will be versioned (however, your application will allways retrieve the latest version).

SQL delete sentences issued by your application on tables with archived BLOBs will be logged. In the case of a transaction rollback, the content is unaltered and the application can keep reading it as ever. If the transaction is committed the object is inaccessible by the application (as it would do if docXtend were not installed) and the operation is reproduced at the content manager with a configurable delay (depends on your license; free version will use only a “no delay” configuration). If your ECM platform uses a ‘trash can’ the deleted content will be moved to it.