Introduction to Access Permissions

This section is intended for system administrators who are responsible for controlling user access to SL1 systems. This manual describes the access permissions system used in SL1. This system comprises a selection of Access Hooks that control individual actions and user-defined Access Keys, that group together Access Hooks and are granted to users. This manual includes step-by-step instructions on how to create Access Keys and how to select appropriate Access Hooks.

Use the following menu options to navigate the SL1 user interface:

• To view a pop-out list of menu options, click the menu icon ().
• To view a page containing all the menu options, click the Advanced menu icon ().

This section includes the following topics:

What is an Access Hook?

An Access Hook controls access to a specific action that can be performed in the user interface for SL1. These actions include navigating to a page, viewing information about an entity in the system, and editing entities in the system. Each Access Hook is designed to be highly granular, providing access to only one action on one specific entity or page.

Access Hooks are not granted to users directly; instead Access Hooks are grouped together to form an Access Key, which can be granted to a user.

What is an Access Key?

Because there are several hundred Access Hooks provided in SL1, granting each individual Access Hook to a user or user policy would be a time-consuming process.

Therefore, SL1 requires that Access Hooks be grouped together in an Access Key that can be granted to users either directly or through a user policy. By default, the Access Key "Grant All" is included with SL1. Every Access Hook, except for the Access Hook that controls the Access Key Manager, is aligned to the "Grant All" Access Key. SL1 also includes default Access Keys for the most common user profiles and common tasks in SL1.

Other Restrictions on User Access

In addition to the Access Hook and Access Key system, user access to SL1 systems is also controlled by organization memberships and the user type hierarchy.

Access Hooks and Access Keys control the pages users can navigate to and the actions they can perform; however, user access is further controlled by organization membership. Users can view and interact only with entities associated with organizations they have membership to. For example, a system might have three organizations, Org A, Org B, and Org C. If user is a member of Org A and Org B and has access to the Device Manager page or Devices page, the user will see only devices in Org A and Org B in the Device Manager page or Devices page. The user will not be able to see or interact with entities associated with Org C.

If a user is able to view the Access Hooks and Access Keys pages, the user interface is restricted so no navigation links are given to those pages. See the Navigation Access Hooks section for more information.

If a user is able to modify user accounts, user hierarchy is also enforced in the following ways:

• Users of type "user" cannot modify administrator accounts.
• Users of type "user" cannot make themselves or another user an administrator.
• Users cannot grant or remove Access Keys that they have not been granted.