This
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 of the menu options, click the Advanced menu icon (
).
What is an Access Hook?
An access hook controls access to a specific action that can be performed in the SL1 user interface. These actions include navigating to a page, viewing information about an element in the system, and editing elements in the system. Each access hooks is designed to be highly granular, providing access to only one action on one specific entity or page. Because of this granularity, there are hundreds of access hooks available in SL1.
Access hooks are not granted to users directly; instead, access hooks are grouped together to form an access key, which can be granted to users either directly through their user account or indirectly through a user policy.
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.
Role-Based Access Control Restrictions
Role-based access control (RBAC) is a methodology that enables SL1 administrators to determine which end users have access to which features within the system. It has three primary components:
-
Organization memberships
-
Access hooks and access keys
-
User accounts and user policies
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 elements associated with organizations to which they have membership.
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 is assigned the appropriate access keys to view the Devices page or Device Manager page, the user will see only devices in Org A and Org B on those pages. The user will not be able to see or interact with elements 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:
- Non-administrator users cannot modify administrator accounts.
- Non-administrator users cannot make themselves or another user an administrator.
- Users cannot grant or remove access keys that they have not also been granted.
For more information about RBAC, see