Multitiered access control model
Action Request System uses a multitiered approach to control data access. At each access level, a user's permissions are checked. If access is permitted, the user proceeds to the next level. If access is denied at any point (except active links and active link guides—workflow), the user cannot proceed. (If access is denied at workflow, the user might be able to proceed, but data access capabilities are limited.) For example, if a user is denied access to a form, the user cannot see any fields associated with the form. Additionally, a user's ability to access a request depends on whether that user belongs to a group that has access to the Request ID field.
Access control in Remedy AR System
The access control model consists of the following levels:
Access level | Description |
|---|---|
AR System server | Users must pass an initial checkpoint when they start a AR System client, such as a browser. At this point, users must enter a valid user name, a password, and, optionally, an authentication string. AR System server checks the user name, password, and authentication string each time a client requests a transaction, such as when opening a form or changing a field. If your AR System server is configured to allow guest users, such users can log in to the server without a valid user name or password. See Creating-and-modifying-users. |
Form | As an administrator, you give groups access to forms according to each group's need to view or change information in the form. Visible access enables users to access a form from the Object List. Hidden access makes a form available only through workflow. Static permissions inheritance and dynamic permissions inheritance properties control access to the form for parent groups. If a group is not given access to a form, members of that group cannot view the form or change the requests that it contains. |
Field | You can control access to each field on a form, including nondata fields such as trim fields, table fields, and active link control fields. You can make a field visible to users or hide the field so that it is accessible only through workflow. For data fields, you also specify whether a group can only view field information or also change it. If a group cannot access a field, the field does not appear when members of the group open the form. |
Active link | In addition to controlling access to form and field data, you can control access to active links, which trigger a variety of workflow actions. For example, you might allow support staff to trigger several active links appropriate to their work but not allow other users to trigger those active links. Groups do not automatically have access to the field associated with an active link. You must grant them access to the active link and to the field. For active links that run when users click a button or choose a menu item, the users must have access to both the button or menu item and the active link to trigger the active link. |
Active link guide | When you create an active link guide, you specify the groups that have access to it. To access an active link guide, a user must have permission to each active link in the guide and to the guide itself. If a user has access to all active links in a guide but not to the guide, the guide does not appear. |
Request | 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 in which you use AR System as the central service desk for several companies, and you do not want one company to see requests from another company. |