How access to tickets and resources works in BMC Helix ITSM

In BMC Helix ITSM, functional role and permissions are not enough to access tickets and resources. Considering the fact that every user belongs to a company, and is part of one or more support groups, to resolve tickets, service desk agents sometimes might need access to other support groups of their own company or another company. Thus, access to tickets and resources depends on your access to the company, support groups, your functional role, and permissions. Your access to tickets also depends on the support group to whom the ticket is assigned, and how you are related to the ticket.

To a great extent, the way in which your company is structured, and support groups are organized decide your access to tickets and resources.

This topic focuses on the model that governs your access to tickets and resources in BMC Helix ITSM.

Overview of the data access model

For IT organizations, maintaining information secure, and controlling data access to appropriate users are the two major challenges. When controlling data access, the data access rules must not be so complex that they hurdle user's functioning, or become difficult for the company to implement and maintain. BMC Helix ITSM data access model helps companies to overcome these challenges. The data access model controls the user's access to data, and also keeps the information secure. Note that there is no change in the user's functional role, permissions, or support groups. The data access model consists of the following features:

Row-level security (RLS)

The RLS feature belongs to Action Request System. It controls access to ticket data in BMC Helix ITSM. RLS is based on the principle that only those associated with the ticket must have access to the ticket. InAction Request System, every form contains a set of core fields. The permissions defined for the fields determine ticket access. Accordingly, users and groups included in the Assignee Group (field 112), and Submitter (field 2) in Action Request System can access and view that ticket. Users who can access and edit tickets are defined in other fields such as Assignee (field 4), Assignee Group Parent (field 60989) and so on. To learn more about fields that provide access to tickets and for additional information about field 112, see Access control with implicit groups: Row-level security.

Important

Assignee Group is a field in Action Request System. BMC Helix ITSM does not support this field.

Hierarchical groups

In BMC Helix ITSM, the hierarchy in which support groups are organized is based on the hierarchical group feature in Action Request System. It is a structure that enables you to organize groups, especially larger groups in hierarchical order. Groups are organized in hierarchy, and user's access to ticket data depends on where they are placed in the hierarchy. In this structure, groups are organized in parent and child hierarchy. Parent groups have larger access as compared to child groups.

Impact of RLS on access to tickets and resources

With the implementation of RLS in BMC Helix ITSM, access to ticket data is streamlined and only those users who are directly related to tickets and resources can access it. This section covers the impact of RLS on BMC Helix ITSMas per the released versions of BMC Helix ITSM.

Access to ticket data is restricted only to users who are directly connected to the ticket or to a support group associated with the ticket.

Users can access tickets on the basis of support group or company and support group. In BMC Helix ITSM, on the System Settings form, in the Applications Permissions Model list, the administrator can select one of the two options:

Support Group—Ticket data access is managed on the basis of individuals (for example, submitter, on behalf of, and assignee) and support groups associated with tickets. This restricts ticket access to only those users who are directly connected to tickets or to support groups associated with tickets. If you select Support Group, the field 112 displays Support Group ID. Support Group includes the following users:
- Submitter of the ticket.
- Assignee of the ticket.
- Owner group who owns the ticket.
- Members of the support group associated with the ticket (child support group).
- Members of the group that is the parent of a support group associated with the ticket (parent group of the child support group).

Support Group and Company—Ticket data access is based on the support group and company that are associated with the ticket. If you select Support Group and Company, the field 112 displays Support Group ID, Company ID, Contact Name, and Customer name. It includes the following users:

- Users who are part of the Support Group (listed under Support Group).
- All the members of a location and customer company referenced on the ticket.
- All the members of a parent group of the location and customer companies.

Note

On the System Settings form, the setting is applied to data that is created after changing the setting. It does not affect existing tickets.

Example

Allen Allbrook creates an incident ticket with the following details:

Submitter—Allen Allbrook, member of the IT Services support group, and belongs to Company A.
Assignee—John Rambo, member of the Backoffice support group, and belongs to Company A.
Owner—Ian Plyment, member of the Service Desk support group, and belongs to Company B.
Customer—Mary Mann belongs to Company C.
Contact—Bob Baxter belongs to Company C.
Vendor support group—Front Desk support group.
Location company—Company C.
Owner company—Company B.

Based on the option selected on the System Settings form, the following users can access this incident ticket.

When the Support Group option is selected	When the Support Group and Company option is selected
Allen, John, Ian, Mary, Bob, and members of the Front Desk support group.	Allen, John, Ian, Mary, Bob, and members of the Front Desk support group.
Members of the Backoffice support group and Service Desk support group.	Members of the Backoffice support group and Service Desk support group.
Users with unrestricted access.	Users with unrestricted access.
Members of parent support group of Backoffice, Service Desk, and Front Desk support groups.	Members of parent support group of Backoffice, Service Desk, and Front Desk support groups.
	All members of Company A, Company B, and Company C.

Impact of hierarchical groups on access to tickets and resources

Hierarchical groups is a structure that enables you to organize larger groups in a hierarchical order. Groups are organized in a hierarchy, and users' access to ticket data depends on the where they are placed in the hierarchy. In this structure, groups are organized in the parent and child hierarchy. Parent groups have larger access as compared to child groups.

Important features of the parent and child hierarchical groups are:

Child groups can access their own tickets.
Parent groups can access their own tickets and tickets of their respective child groups.
All permissions assigned to a child group are passed on to its parent group.

Example

Mary creates an incident ticket with the following details:

Customer—Allen
Direct Contact—Ian
Assigned Group—Backoffice Support (parent of Backoffice Support is IT Data Access)
Owner Group—Service Desk (parent of Service Desk is IT Data Access)

In this case, the following users can access the incident ticket:

Mary
Allen
Ian
Members of Backoffice Support, Service Desk, and IT Data Access (Assigned support group, Owner support group, parent of Assigned and Owner support groups)

Security configuration options

BMC Helix ITSM provides the following configuration options to secure data:

Area	Option	Description
Openfire chat data	Cross-domain-policy	If you have implemented chat, you can also configure Openfire to limit the domains that have access to BMC Helix ITSM chat data. The default setting in Openfire chat allows access to data from all domains. Best practice: BMC recommends that you change the value to allow access only from a specific domain (or domains).
File attachment types	Attachment Security	You can configure Action Request System server to prevent users from attaching certain file types to BMC Helix ITSM records. For example, you might want to block users from attaching executable files or scripts to the Activity feed to prevent malicious code from executing when the attachment is opened. If you restrict attachment file types, an error message is displayed when users try to attach those file types in the following context: Ticket details (for example, when adding an attachment to the Description field on incidents, work orders, problem investigations, and known errors) Asset profiles (for example, profile images) People profiles (for example, profile images) Activity feed Email Broadcasts Change request documents Knowledge articles By default, the Attachment Security settings are blank, which allow all attachment types. For more information about these settings, see Restricting users from uploading and viewing files with specific extensions.
Content security policy	CSP properties	You can configure the content security policy option in Central Configuration. BMC Helix ITSM uses this Content Security Policy (CSP) to determine which resources are allowed to load in the application UI. Use of a CSP reduces the risk of cross-site scripting (XSS) attacks. The CSP is defined as a set of properties stored in the SHARE:Application_Properties form. For example, the CSP defines the source domains that are valid for loading scripts and objects. Smart IT supports the connect-src, object-src, script-src, img-src, and media-src directives, which are described in the Content Security Policy (CSP) Quick Reference Guide at http://content-security-policy.com/. Central Configuration includes out-of-the-box directives that are defined in the following properties: smartItCsp_connect-src_0, smartItCsp_object-src_0, and smartItCsp_script-src_0. You must not remove or update these properties. You can add your own directives to the CSP, according to the requirements of your organization. For example, you might want to allow users to add images from external sources to knowledge articles.
Strict-Transport-Security response header	Strict-Transport-Security	You can enable the Strict-Transport-Security response header for BMC Helix ITSM to tell browsers that it should only be accessed by using HTTPS, instead of HTTP. Otherwise, even when you configure HTTPS, browsers can connect by both HTTP and HTTPS.
Secured connection to access BMC Helix ITSMandroid application	usesCleartextTraffic	The default setting for this property is true. This property is available in the AndroidManifest.xml file. We recommend using TLS 1.2 connections to the BMC Helix ITSM server in production.