Data Access Control groups

Data Access Control (DAC) groups control permissions related to entity types, link types, fields, and records in each database. This allows a very fine control of how individual items of data are made visible to, or changed by, groups of users.

Among the possibilities are:

Denying all access or change to all records for a particular entity type or link type. For example, you could deny access to all witness statements if those statements are stored in a particular entity type.
Hiding administrative fields in records or making administrative fields read-only to certain groups of users.
With SQL Server databases only, making selected records of various entity types or link types inaccessible according to the security classification (SC) code given to each record. For example, you could create DAC security groups called Public and Security Cleared, then use Data Access Control to deny the Public group access to records given an SCC level of Secret.

Note: New users are automatically made a member of all the existing Data Access Controls groups. This automatically gives them the lowest level of permissions defined for the database. You should review this default group membership whenever you add new users.

Note: After you make changes to a Data Access Control group in a database that uses alerting, log off and reopen the database as soon as possible, in either iBase or iBase Designer. This applies the security changes to any existing alert definitions.

Implications of using Data Access Control groups

You should consider carefully how you might want to use a scheme using conditional access.

A simple scheme with few combinations of access permissions is likely to work better than a scheme that implements many levels of restriction. Remember each combination of restricted data access has potential consequences for users by blocking access to queries using those restricted entities, links, or fields. This is true of all folder objects related to data items, not just queries.

You can start with a simple scheme and increase its complexity if needed.

What the user sees in iBase

The consequences of placing a user in a Data Access Control group can be wide ranging and can mean that different users see different databases.

A selection of the effects upon a user in a group with each of the possible restrictions:
Restriction	Details
Denied tables (entity types and link types) are entirely invisible to the user	This means that the user does not see the records for those types, and does not see even that the entity or link types exist. They are not able to run queries or reports for the denied entity or link type.
Read-only tables appear as normal, but do not have editing or creation options	For example a read-only entity does not have New command in the shortcut menu and the New and Edit buttons are unavailable in Show dialogs and data sheets for that entity.
Denied fields are entirely invisible to the user	For example, a denied field does not appear in Show dialogs, datasheets or when setting up browse definitions.
Read-only fields appear in data entry forms in the same form as equivalent system or calculated fields	For example, a read-only text field appears with a gray background even when other fields are editable.
Denied records (entities and links), denied because of an SC code, are made invisible on a record by record basis, so other entity and link records remain visible	For example, if there are some Crime entity records denied to a user, they may see other Crime records and they will always see that the Crime entity type exists, even if all records are denied to them. For details of further limitations that apply to matching records and merged entities, see Using Security Classification Codes.

The effects mentioned previously are direct and predictable. There are also effects that may seem less predictable, but are required to avoid users deducing what is hidden from them:

All folder objects with references to denied tables become unavailable to the user. For example, users cannot see or use a query that refers to a denied entity or link.
Users see data sheets, statistics, and design reports that match the entities and links that they see. Denied fields, entities, and links do not appear.
If there are denied fields, users see a Show dialog without those fields. Users do not have access to a data sheet using a denied field.

What the administrator sees in iBase

You might see the following effects where users do things that are reasonable given their view of the database:

Duplicate records that are created by users who have entities or links hidden by SCC restrictions.
Users creating private queries to perform related tasks.
Users in different Data Access Control groups see different results from performing the same analysis.

Creating Data Access Control groups

To create a Data Access Control group:

In iBase Designer, log on and open the database for which you want to set up Data Access Control. You do not have to open the database to create the group and add members to it but you do need to open it to define the permissions for the group.
Use the Security Manager dialog to create one or more Data Access Control groups, and make users into members of those groups. See Creating the optional types of group for details.
From the Security menu, select Data Access Control.
In the Data Access Control dialog, select the group and then define the group's access. You must repeat these steps in each database that is secured by the security file— the groups are defined in the security file but the permissions of each group are defined in the database.

The different types of access:
Page	Description
Tables	Lists the entity and link types in the database schema. To hide all records for a specific entity or link type, turn on the check box.
Fields	Lists the fields of all the entity and link types in the database schema, including standard fields and mandatory fields. To hide a field in records of a specific entity or link type, turn on the appropriate check box. Note: You are warned if you deny access to a mandatory field (or if you make a denied field mandatory). If you choose to deny access to this field (or make a denied field mandatory), you prevent members of the group from adding records of the entity or link type. Note: Users who plot data on maps might need write access to the fields containing coordinate values if an iBase or Microsoft Access geocoding database is used.
Read-Only Tables	On this page, records are visible to members of the selected security group but are protected from change.
Read-Only Fields	On this page, data in the specified field is visible to members of the selected security group but are protected from change. Note: Users who plot data on maps need write access to the fields containing coordinate values if an iBase or Microsoft Access geocoding database is used, unless a more powerful user populates those fields for them.
Security Classification Codes	The Security Classification Codes page lists the SC codes defined in the database schema. Turn on check boxes for all classifications that you wish to be denied to members of the selected security group. If any classification name appears in more than one SCC list, the denial of records applies to all records with that classification regardless of the list in which it appears. For further information, see Using Security Classification Codes. There is no Security Classification Codes page if you open an Access database or if the database is case controlled.

Where Data Access Control groups are stored

The relationship to database contents means that the full definition of a Data Access Control group is stored in two parts. The name and membership of each group is stored in the security file. The restrictions on members of each group are stored in the database, because it is in the database that the restrictions and their linkages to entities, links, and fields are stored.

If you create a new database from a template based on a database with DAC restrictions, the new database has no data access restrictions, but it does have access to the security groups in the relevant security file and any SCC lists in the template. This allows you to reproduce the security settings more easily than at first creation.