Managing security

Managing security in a replicated database is similar to an unreplicated database. However, the security file must be SQL Server format.

Replication ensures that your iBase security setup is identical at all sites. When you are using a replicated security file, any change that is made by a security administrator at one site is replicated to all the other sites, whether adding or modifying user groups, defining permissions for those groups, or adding or modifying users. Updates are replicated to all the sites at a frequency that is agreed with the SQL Server administrator and might, for example, be anything from every minute to once a day.

If one site requires slightly different security arrangements, you must set up user groups and users that are site-specific.

Each analyst should have their own user account, and any naming convention for these should include a location identifier in the user name. See Updating User Data for details.

Note: To refresh the user groups and users displayed in the Security Manager, close and reopen the Security Manager— updates to user groups and users from other sites are not otherwise displayed.

iBase system roles

iBase administrators that work with security files, database properties, and the Conflict Viewer require different iBase system roles:

Required permissions to perform tasks
Tasks	Required permissions
Work with the security file and set up groups and users	You need to be able to log on as a security administrator. Your user account must be a member of a group with the security administrator system role. This enables you to: Upsize the security file to SQL Server Change the properties of the security file (anyone with access to iBase Designer can view the properties of the security file but only a security administrator can change them) Display the Security Manager (and check for duplicate groups or users) Define the permissions for groups
Initialize a database for replication and use the options on the Replication menu Note: Allows you to display but not review conflicts	You need to be able to log on as a database administrator. Your user account must be a member of a group with the database administrator system role. This enables you to: Initialize a database for replication (in iBase Designer) In iBase, run all the commands on the Replication menu. You are able to display conflicts in the Conflict Viewer but not review them. Note: You also need permission to access the SQL Server conflict tables in the database. Contact your SQL Server administrator if you cannot display the Conflict Viewer but appear to have the correct iBase permissions.
Use the Conflict Viewer to review conflicts	Your user account must be a member of a group with the database administrator system role, and also have add, update, and delete permissions for entity and link records, including entity and link records created by other users. Note: You also need permission to access the SQL Server conflict tables in the database. Contact your SQL Server administrator if you cannot display the Conflict Viewer but appear to have the correct iBase permissions.
Change database properties	You need to be able to log on as a system administrator. Your user account must be a member of a group with both the security administrator and database administrator roles.

Maintaining System Commands Access Control (SCAC) groups

In a replicated database, you can deny access to iBase commands using System Command Access Control groups. You create the groups for the whole organization using the Security Manager and assign permissions using the System Commands Access Control command at the following times:

In the Microsoft Access security file before you distribute the security files to the subscriber sites.
In the publication database, either before or after the security file is configured for replication.
In the subscription database, after replication is configured for the security file at the subscriber sites.

Before you define permissions for System Command Access Control groups, you should review how the following access controls are assigned:


Group	Notes
Soft Delete	Denies users access to the commands for purging and restoring soft deleted records. These commands are only available in the publication database, after all current conflicts are resolved.
Batch Modification	Denies users access to Batch Edit and Batch Delete which, when used especially on entities with large numbers of links, can introduce conflicts into your data. This group also denies access to Merge Entities. Conflicts arising from merging cannot be handled in the iBase Conflict Viewer and must therefore be avoided by good working practices. See Merging Entities for details.
Show User Information	Denies access to the User Information and Select User dialogs. This is available in the following places: On the File menu In the Conflict Viewer by clicking the user name In the Properties dialog by clicking the User Information button In the Show dialog and datasheets by clicking the user name (if owner hyperlink fields are used in the entity and link types) Note: If this group is not displayed in the System Commands Access Control dialog, update the SCAC groups by selecting Update Command Groups from the Tools menu.

If a particular group of users at one site requires different permissions to similar users at another site, then you need to assign their user accounts to a separate SCAC group.

Maintaining Data Access Control groups

Extended Access Control (EAC) gives the ability to assign rights to Data Access Control groups (DAC groups). In a replicated database, you create the groups for the whole organization using the Security Manager and deny access to specific tables and fields on the database using the Data Access Control command at the following times:

In the Microsoft Access security file before you distribute the security files to the subscriber sites, if the publication database exists. However, you are not able to deny access based on Security Classification Code lists as these are a feature of SQL Server databases.
In the publication database, either before or after the security file is configured for replication, if the publication database exists.
In the subscription database, after replication is configured for the security file at the subscriber sites, if the subscription database exists.

You need to open the database to define the permissions for Data Access Control groups. However, empty groups can be created and users assigned even if the database does not yet exist.

If a particular group of users at one site requires different permissions to similar users at another site, then you need to assign their user accounts to a separate Data Access Control group.