How to Setup the Data Partition

Implementing Policy › Policy Implementation › CA SDM Integration › Data Partition Associations › How to Setup the Data Partition

How to Setup the Data Partition

The data partition is a subset of CA SDM database that controls a user access to tickets and other data records based on their content.

For example, you can restrict a user view of the database to only those configuration items that are assigned to the user organization. You can also restrict a user to update only assigned tickets and allow read-only access to other configuration items.

A data partition consists of a set of constraints. The data partition constraints identify the table that is being controlled by the data partition and the constraint type. The constraint types specify what the user can do, such as create, delete, update, view, and so forth, within the data partition. After you assign a data partition to an access type, which you in turn assign to a user contact record, the constraints and constraint types are what control the user access to the records in the CA SDM database table.

You can also view constraints independent of the data partition using them. For example, you want to view all constraints for a specific table, regardless of the data partition.

Verify the Prerequisites

Before you set up the data partition, verify the following prerequisites:

Data Security Structure and Policy

Planning data security involves enforcing restrictions to access the specific portion of the database. These restrictions can be enforced on individual contacts either through roles or access types:

Roles: Defines the functionality that users in the role are allowed to access. You can assign one or more roles to an individual contact record, or to an access type to define the functional access for all of the access types who are associated with contacts.
Access Type: Defines how contacts are authenticated when they log in to the web interface. For example, an access type decides whether the contacts can modify web forms or the database schema using Web Screen Painter and which roles are available for the contacts.

As a service desk administrator, you can modify the predefined access types and also create new ones. You can enforce the restriction to the individual users or a group of users through Roles.

Identify the following:

The objects and the type of restrictions you want to enforce on these objects.
The Users or Roles on whom the Data Partition are applied. Data Partitions can be applied to contacts directly, but the preferred method is to assign data partitions based on the role and assign this role to all the contacts directly or through the access type.

Data Partitions Setup Specifications

You can define an unlimited number of data partitions. Each data partition consists of a set of constraints and validations on each database table that is restricted by the data partition. For each table in a data partition, you can specify independent authorizations to view, update, create, or delete records using criteria that are specified in a format similar to an SQL WHERE clause. You can base the restriction on any attribute in the record being accessed, combined with any data in the user contact record. This allows considerable flexibility when defining data partitions. For example, using the Vendor field in the Contact table allows data partition restrictions to be placed on vendors that are permitted to access CA SDM directly.

For performance reasons, CA SDM does not allow a data partition constraint to contain a Cartesian join. A Cartesian join results from a constraint containing an “OR” that does fully restrict all joined tables on both sides of the OR. To ensure that your data partition constraint does not produce a Cartesian product join, enter the following command:

Windows

bop_cmd -f $NX_ROOT\bopcfg\interp\bop_diag.frg "check_queries()"

UNIX

bop_cmd -f $NX_ROOT/bopcfg/interp/bop_diag.frg "check_queries()"

Important! Any data partitions that are flagged by this program must be updated appropriately.

Constraint Specifications

You specify constraints and validation tests in Majic using the object definition metalanguage.

Note: For information, see the Technical Reference Guide.

Constraints that are defined in Majic closely resemble an SQL WHERE clause, with the following exceptions:

Attribute names in the constraint are object attribute names, not the database attribute name from the schema.
You can refer to the value of an attribute in the contact record for the logged‑in user with a name of the following form, where att_name is the Majic name of the desired attribute:
```
@root.att_name
```
For example, specifying @root.location refers to the location ID of the current contact.

You specify joins with a specification of the following form, where the foreign-key is the Majic name of the SREL attribute in the table for which you are writing the data partition constraint, and attribute-in-referenced-table is the Majic name of the attribute in the table being joined:
```
foreign-key.attribute-in-referenced-table
```
For example, to refer to the maintenance vendor of the asset that is associated with an incident report, specify the following:
```
resource.vendor_repair
```
This specification is recursive. For example, you could refer to the name of the vendor with the following name:
```
resource.vendor_repair.name
```

The following table contains examples of valid constraints to use for the Change_Request table, used to store change order information:

Constraint Type

Code and Description

View

assignee.organization = @root.organization

Specifies the user can only view change orders where the assignee’s organization is the same as the user’s organization.

Pre-Update

requestor = @root.id

Specifies the user can only update the change orders where he is the caller or requester.

However, you cannot write a constraint that uses joins on both sides of the expression, as shown in the following example:

assignee.org = requestor.org

View the Data Partitions Controlled Tables

A controlled table is a list of tables on which a service desk administrator can enforce restrictions using the data partitions. These tables give you an idea of the objects and tables for which you can restrict the user access.

Note: You cannot add or delete controlled tables or change their object names.

Follow these steps:

Select Security and Role Management, Data Partitions, Data Partitions Controlled Tables on the Administration tab.
The Controlled Tables list opens.
(Optional) Click Show Filter and complete one or more of the search fields.
Select the name of the table you want to view.
The Data Partition Controlled Table Detail page opens.

Create a Data Partition Constraint

Data partition constraints restrict the database record access for users that are assigned to the data partition.

Follow these steps:

Select Security and Role Management, Data Partitions, Data Partition Constraints on the Administration tab.
The Data Partition Constraints List page opens.
Click Create New.
The Create New Data Partition Constraint page opens.
Complete the data partition constraint fields, as appropriate.
Complete the information in the tabs, as appropriate:

Constraint

Specifies the criteria that controls the records in the table and can be viewed, created, updated, or deleted by a user that is assigned to the data partition. For example, you can specify that users can only update issues that are assigned to them. When a user in the data partition requests a record that does not match the condition then the record is read-only.

Limit: 4000 bytes

SQL Translation

Displays the constraint definition in SQL format. The condition that you entered on the Constraint tab is validated, and the underlying SQL WHERE clause is built. This translation is displayed on the SQL Translation tab for the verification.
Click Save.
The constraint is saved and added to the data partition.

Example: Create a Data Partition Constraint for CAB Assignments

You can create a data partition constraint that lets users update only change orders that are assigned to a CAB to which the logged in user belongs.

To create a data partition constraint for CAB change order user assignments, assign the following constraint values for a Change_Request controlled table in a data partition:

Constraint type: Pre-Update
Constraint specification: cab.[group]group_list.member IN (@root.id)

The logged in user can only update change orders that are assigned to a CAB to which the user belongs.

See Also

Data Partition Constraints Fields

Constraint Definition

Data Partition Constraints Fields

Complete the following fields to add or modify the data partition constraint fields:

Data Partition Name

Specifies the name of the data partition for which the constraint being defined.

Table Name

Specifies the database table that is controlled by the constraint.

Constraint Type

The type of constraint being defined. There are six constraint types for each table in a data partition.

Create

Specifies the criteria that must be met before creating a record. When a user in the data partition attempts to create a record that does not match the create test condition, CA SDM displays the error message that is associated with the constraint and does not save the record.

Defaults

Specifies one or more assignment statements, separated by semicolons, defining values to be assigned to empty fields in a new record at the time the record is stored. The syntax of each assignment statement is, where att_name is the name of a Majic attribute from the record, and value can be an integer, a string that is enclosed in quotes, or a reference in the form @root.att_name to a Majic attribute in the contact record for the current user:

att_name=value

For tables updated for tickets, default values are placed into the record at the time it is displayed and are shown on the initial display of a new record. You can assign a default value to a reference field (a Majic SREL) by coding it in the form of a persistent ID. A persistent ID is an object name followed by a colon and an integer ID. For example, you can set a default value for category by including the following in the defaults specification, where PCAT is the target of the SREL (as shown in the Majic file) and 12345 is the ID number of the desired category:

category='PCAT:12345'

You can list persistent IDs for an object using a command of the form:

bop_odump domsrvr pcat "" sym

Delete

Specifies the criteria that must be met to delete a record. When a user in the data partition attempts to delete a record that does not match the delete condition, CA SDM displays the error message that is associated with the constraint and does not delete the record.

Pre-Update

Specifies the records in the controlled table that a user can update in the data partition. When a user in the data partition requests a record that does not match the pre-update condition, CA SDM makes the record read-only and displays the error message that is defined with the constraint.

Update

Specifies the criteria that must be met when a record is saved. When a user in the data partition attempts to save a record that does not match the update condition, CA SDM displays the error message that is associated with the constraint and does not save the record.

View

Specifies the records in the controlled table that a user can view in the data partition. This constraint is automatically applied to all lists selected by a user in this data partition, in addition to any selection criteria explicitly specified by the user.

View can include joins to other tables and references in the form @root.att_name to Majic attributes in the contact record for the current or logged-in user. The valid examples are:

requestor.organization = @root.organization

requestor.organization.name = 'MIS'

assignee = @root.id

assignee.organization = @root.organization

Note: The Create, Delete, Pre-Update, and Update constraint types now support joins to other tables. They can also include references in the form @root.attribute to attributes in the contact record for the current user.

Record Status

Indicates whether the constraint is active or inactive.

Error Message

Specifies the message returned to the user, if the constraint criteria is not met. For example, "You can only update issues assigned to you" or, "You can only create issues for your organization" or, "You can update your contact record but cannot change the data partition."

Constraint Definition

Specify the condition in Majic format (the metalanguage used to define CA SDM objects).

If the Constraint Type is View, the condition can include joins to other tables and references in the form @root.att_name to Majic attributes in the contact record for the logged-in user. Otherwise, it cannot include joins to other tables, but it can include references in the form @root.att_name to Majic attributes in the contact record for the logged-in user.

If the Constraint Type is Defaults, you may specify one or more assignment statements, separated by semicolons, which specify values to be assigned to empty fields in a new record at the time the record is stored. The syntax of each assignment statement is:

att_name=value

where att_name is the name of a Majic attribute from the record, and value can be an integer, a string enclosed in quotes, or a reference in the form @root.att_name to a Majic attribute in the contact record for the logged-in user. The way CA SDM uses default values depends on the table they affect.

For tables updated by CA SDM, such as Issues, default values are placed into the record at the time it is displayed, and are shown on the initial display of a new record. A default value can be assigned to a reference field (a Majic SREL) by coding it in the form of a persistent ID (a table name followed by a colon and an integer ID). For example, you might set a default value for category by including the following in the Defaults specification:

category='PCAT:12345'

where 'PCAT' is the target of the SREL, as shown in the Majic file, and 12345 is the ID number of the desired category. You can list persistent IDs for a table with a command of the form:

bop_odump domsrvr pcat "" sym

Create a Data Partition

A data partition is a subset of a CA SDM database that controls a user access to tickets and other data records based on their content.

Follow these steps:

Select Security and Role Management, Data Partitions, Data Partitions List on the Administration tab.
The Data Partition List page opens.
Click Create New.
The Create New Data Partition page opens.
Complete the fields as appropriate:

Data Partition

Specifies a unique identifier for the data partition.

Record Status

Indicates whether the partition is active or inactive.
Click Save.
Click New Constraint and attach constraint definitions to the partition.
Click Save.
The data partition is saved with the data partition constraint.

Create an Access Type

The access types define all aspects of security. Several predefined access types are included, and you can modify them or can define new ones. Each access type for a user controls the following aspects of system behavior:

How CA SDM performs the web authentication when the user logs in.
The access level for the user.
Whether the user can modify web forms or the database schema using Web Screen Painter.
What are the roles available to the user.

Follow these steps:

Select Security and Role Management, Access Types on the Administration tab.
The Access Type List page opens.

Default: 15
Click Create New and complete the access type fields, as appropriate, on the Create New Access Type page.
Use the tabs to complete the following tasks:
Click Save.
The access type is created.

Access Type Fields

The following fields appear on the Create Access Type, Access Type Detail, and Update Access Type pages.

Symbol

Specifies a unique identifier for the access type.

Default?

Indicates whether this access type is the default that is associated with contacts.

Record Status

Specifies whether this access type is Active or Inactive.

Description

Describes the access type. Use this field to help identify the characteristics of the access type.

Receive Internal Notification

Determines whether the contacts associated with the access type receive internal notification of activities that are related to tickets.

Access Level

Determines which access types a user can grant to another user. A user can assign an access type to the contact record of another user only if the access level of the access type they are attempting to assign is ranked the same as or lower than the grant level for their own access type. The levels are ranked as follows:

Admin (highest)
Analyst
Cust/Emp
None (lowest)

Licensed?

Determines whether this contact is a licensed access type. Contacts assigned to unlicensed access types can only view or update their own personal data.

Note: KPIs count the concurrent usages of the users from the system (for example, CA SDM Web UI, SOAP Web Services, REST Web Services, and so on). For example, the webConcurrentLicenseCt KPI counts the maximum number of unique users (with the "Licensed?" option selected) logged in to the CA SDM Web UI during the interval. For more information about logged in and licensed user counts, see the Administration Guide.

Configure Web Authentication for an Access Type

You can configure the web authentication and validation type to specify how roles assigned to this access type are authenticated when users attempt to access the CA products. Complete the following fields in the Web Authentication tab.

Allow External Authentication

Select this check box if you want to allow contacts to be authenticated externally, for example by the HTTPD server or the operating system. If you select this option, users with this access type are validated by the appropriate external method as configured during installation. Checks ensure that no external validation has taken place (for example, that the user has not attempted access through a non-secure server) and that the user is defined as a valid contact in the system using the login ID. Then, it uses the access type to determine the correct interface to use.

Validation Type

Defines how users are authenticated when an external authorization is either not permitted or fails (for example, if the user is attempting access through a non-secure server). The available options are:

No Access: Denies access to CA products unless external authentication is allowed and is valid.
Open: Access to the CA products are always allowed, with no additional authentication required.
OS: Access to the CA products are allowed through operating system user name and password.
PIN / PIN Number: Users of this type can access only if they enter the correct value for the PIN field in their contact record. If you select the PIN option, you can choose which field in the contact record stores the PIN by entering the field attribute name in the PIN Field edit box.
CA EEM: Access to the CA products are allowed through CA EEM. This option is available only if CA SDM is integrated with CA EEM.

Assign Web Screen Painter Permissions to an Access Type

The Web Screen Painter (WSP) utility allows CA SDM users to build and publish web forms and schemas. The Web Screen Painter tab also controls the database access for Web Screen Painter preview sessions. For the details about WSP, see the Web Screen Painter Online Help.

Select the permissions that you want to allow for an access type in the Web Screen Painter tab.

Modify Forms: Allows the users to do the changes to existing forms without doing the changes available to all users.
Modify Schema: Allows the users to do the changes to an existing schema without doing the changes available to all users.
Publish Forms: Allows the users to make their modified forms available to all users.
Publish Schema: Allows the users to make their modified schema available to all users.
Preview Session Can Update Database: Allows the users to do the changes to the database during a preview session. By default, database changes are not allowed during a preview session.

Assign Roles to an Access Type

Assign the roles to an access type limits the access to functional areas for the contacts that are assigned to the roles.

Follow these steps:

Select the following roles for this access type:

Reporting Role

Defines the reporting access for this type.

REST Web Service API Role

Defines the access to the REST web services for this type.

SOAP Web Service API Role

Defines the access to the SOAP web services for this type.

Command Line Utility Role

Defines the access to the command-line utilities for this type.
Click Update Roles.
The Role Search page opens.
Enter any search criteria that you want to limit the list to the roles of interest, and then click Search.
The Roles Assigned - Update page opens, listing the roles that matched the search criteria.
Select the roles that you want to assign to this access type from the list on the left. To select multiple items, hold down the CTRL key while clicking the left mouse button.
Click the double right-directional arrows, after you have selected all the roles that you want.
The selected roles move to the Roles Assigned list on the right.
Click OK.
The Access Type Detail page opens, with the assigned roles listed on the Roles tab.
Click Save.
The Access Type Detail page opens, with a confirmation message that your changes have been saved.
Select the role that you want to be the default for this access type upon login, and then click Set Default Role.
Your selection for the default role is saved.

Add the Data Partition to a Role

Switch to the role to which the data partition was linked. The role has access to only that data partition which is assigned to it.

Follow these steps:

Select Security and Role Management, Role Management, Role List on the Administration tab.
The Role List page opens.
Select a role and click Edit.
Go to the Authorization tab and click Data Partition Name.
Search and select the data partition name from the data partition list.
On the Authorization tab, select the Override Contact Data Partition?. When Override Contact Data Partition is checked, role data partition is enforced, else, contact data partition is enforced.
Click Save.

Test the Data Partition Constraints

Test the data partition constraints to ensure that the restriction that you created is enforced appropriately on the contacts. Attempt to view or edit data records for which the data partition constraint is supposed to restrict access.

Follow these steps:

Log in to CA SDM using the contact for which you have enforced the data partition restrictions.
Try to access the objects data on which data partitions constraints are enforced.
If the restrictions work as you had designed, it indicates that the data partition is successfully created and applied.