How security works in a replicated database

Replicate the database, and then replicate the appropriate security file.

There are two file formats for iBase security files:
  • Microsoft™ Access (which cannot be replicated)
  • Microsoft SQL Server (a more secure format that can be replicated)

When you select SQL Server format for the security file, you create an SQL Server database that contains the data, and a connection file that stores the connection information. Keep the security connection file in the iBase database folder alongside the connection files for the iBase databases that use it.

Replicating a security file

Replicating the security data enables your organization to implement a global security system whereby the following are identical:
  • Security policy
  • User groups
  • User accounts
  • Access rights derived from membership of the user groups
The advantages of replicating the security data are:
  • Reduced administration for the security administrator as replication synchronizes the security data at the different sites.
  • Any security administrator at any site can maintain the security data. You control access to the local copies of the security file in the usual way.
  • Usernames and contact details are always consistent and up-to-date, which assists analysts who use the audit log, record properties, or owner details in iBase.

    Non-replicated databases can continue to use a replicated security file, provided the databases are using the same version of iBase.

Why you must replicate the security file

Using a replicated iBase database with an unreplicated security file reduces the security of your system - if you are replicating the database, you must implement a unified and global security system. This is important if users can log on remotely to any server in the iBase system. Local security systems can potentially give users access to different commands and data depending on the server they log on to.

The facility to control who can view the audit log generated by users that work on sensitive data requires you to replicate the security file.

Attention: If you use iBase with Extended Access Control, then it is essential to replicate the security file and failure to do so undermines the additional security provided by Extended Access Control.

Importance of the security file at the publisher site

All sites must have a copy of the security file or database used at the publisher site because this is the security file associated with the database that is replicated. You can only open this database, or the subscription databases created from it, using the user accounts defined in its replicated security file.

It is not possible for the subscriber sites to create their own security file for use with a replicated database. Each site must either start with a copy of the publisher security file and convert this from Microsoft Access format to SQL Server, or start with a duplicate of the publisher security database created by restoring from an SQL Server backup provided by the publisher site.

Attention: You should keep a copy of the security file in Microsoft Access format in case you need to add new subscriber sites in the future.