Access control overview
Multitiered access control model
BMC Helix Innovation Suite uses a multitiered approach to control access broadly at the highest levels, such as at server and form levels, and narrowly at the request and field levels. Because you can refine your data access criteria at multiple levels, you can use a single form for different purposes by setting the appropriate permissions. You can restrict access at the following levels:
Access level | Description |
|---|---|
Server | When users start a BMC Helix Innovation Suite client, they must enter a user name and a password, which are checked against every AR System server with which the client is trying to connect. After a connection is made, each request that goes between the client and the server has the current user name and password checked to verify that the values are still valid. |
Form or Table | In addition to having a unique user name and password on a server, every user is a member of zero or more groups. Groups are defined and maintained with the Group form, where each record is a different group definition. For example, there might be groups defined for First-Level Support, Back-Line Support, and Support Management. Groups are used to control information access to forms, requests, fields, active links, and active link guides. Generally, the Public groups might have the most users. You can also configure a hierarchical relationship between groups to allow the child group to inherit the permissions of the parent group. You might use group access to forms so that a particular form is visible to users in the Support Management group, but not to users in the First-Level Support and Back-Line Support groups. For a particular form, an administrator can define that certain requests are accessible only by members of one group and that other requests are accessible by members of a different group. |
Field or Column | In addition, every field on a form has access control. Set field permissions when you define the field properties in Developer Studio. Each field can have a list of groups that can view the field and the data entered into it. Some or all of the groups with View permission might also have Change access so that they can enter and modify the data. If a user opens a form on their workstation and the groups that they are a part of do not have View access to some of the fields, those fields are not displayed on the form. A field can also be visible or hidden so that it is accessible only through workflow. |
Request or Row | You can strictly control who can access requests associated with a form. For example, you might want only managers to access requests with confidential employee information. For example, if you provide an outsourcing service, where you use BMC Helix Innovation Suite as the central service desk for several companies, and you do not want one company to see requests from another company, use the request level restrictions to secure the information. |
Client-side workflows (Active link and Active link guide) | Finally, each active link and active link guide has its access control assigned when it is created. A user who has access to an active link does not automatically have access to the field associated with it. Similarly, a user who has access to a guide does not automatically have access to the active links in the guide. |
Access control in BMC Helix Innovation Suite is additive. Each user starts out with no access permissions, and administrators add permissions as needed. In this way, BMC Helix Innovation Suite implements strict access control. Administrators must make a conscious decision to grant access to specific groups on a case-by-case basis. However, if desired, the default permissions can be changed.
Only BMC Helix Innovation Suite administrators or sub administrators can modify security parameters.
The following topics describe user and group access, role-based access, multitiered access, and how licensing affects access control:
Action | Reference |
|---|---|
Assign access control groups to registered AR System users. | |
Define roles for an application and associate with the groups that are available on the server where the application is deployed. | |
Enable users to access multiple applications without having to separately assign them to multiple groups. |