Access control overview

Keeping information secure can be a major undertaking in client/server environments. It is sometimes a balancing act for administrators. You want to rigorously control who can access data, yet you do not want security to be so complex that it intrudes on your user community or is difficult for you to implement or maintain.  Action Request System  provides a rich set of features that protect your data from unauthorized access. In addition, it has a logical, multitiered access control structure that is straightforward for you to implement and for users to understand.

AR System  enables you to meet these seemingly opposing security goals. It enables you to control which users can access data and perform certain actions such as modifying a request or triggering an active link. The following conditions determine user access:

• The groups to which users belong
• The licenses users are granted

AR System  uses a multitiered approach to control access at these points:

• Server
• Form (or table)
• Field (or column)
• Active link and active link guide
• Request (or row)

This approach provides a wide range of control over data access, enabling you to restrict access broadly at the highest levels (server and form) and narrowly at the request and field levels. Because you can refine your data access criteria so precisely, you can use a single form for many different purposes simply by setting the appropriate permissions.

When users start a AR System  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.

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. You can also configure a hierarchical relationship between groups to allow the parent group to inherit the permissions of the child group. As a practical matter, most users are likely to belong to the Public 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 determine that certain requests are accessible only by members of one group and that other requests are accessible by members of a different group.

In addition, every field on a form has access control. You 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 his or her workstation and the groups he or she is 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 to users or hidden so that it is accessible only through workflow.

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 AR System  is additive. Each user starts out with no access permissions, and administrators add permissions as needed. In this way, AR System  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.

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. Or you might provide an outsourcing service, where you use AR System  as the central service desk for several companies, and you do not want one company to see requests from the other company.

Only AR System  administrators or subadministrators can modify security parameters.

This section describes user and group access, role-based access, multitiered access, and how licensing affects access control. Topics include:

• Roles and permissions in BMC Helix Innovation Suite
• User and group access overview
• Role-based access overview
• IS Persona overview
• Multitiered access control model
• How licensing affects access control