Security and RBAC Overview
Lanview uses role-based access control (RBAC) to manage who can sign in, which areas of Lanview Studio they can see, and which administrative actions they can perform.
Lanview Server manages authentication, users, roles, permissions, two-factor authentication policy and audit records.
Security model
Lanview security is based on these core concepts:
| Concept | Meaning |
|---|---|
| User | A Lanview account used to sign in and perform administration. |
| Role | A named collection of permissions. |
| Permission | A specific right to view an area or perform an action. |
| Effective permissions | The final set of permissions granted to a user through their enabled roles. |
A user can have one or more roles. Lanview combines the permissions from those roles to determine what the user can do.
Permission enforcement
Lanview Studio uses permissions to restrict access to the interface, and Lanview Server checks permissions when actions are requested.
This applies to Studio administration, Server-handled commands and sensitive operations.
First administrator
A new Lanview Server installation requires an initial administrator account.
The first administrator is created through the supported Server bootstrap process. After the first administrator exists, user and role management should be performed through Lanview Studio by authorised administrators.
Lanview does not use shared public default credentials for normal first sign in.
Studio access
The studio.login permission allows a user to sign in to Lanview Studio.
Other permissions control which modules and actions are available after sign in.
A user may be able to sign in but still have limited access if their roles lack the required module or action permissions.
Module permissions
Module permissions control which main areas of Lanview Studio are visible.
Examples include:
- Devices.
- Groups.
- Tasks.
- Packages and deployments.
- Scripts.
- Monitoring.
- Security.
- Settings.
- Studio Console and AdminConsole.
Module permissions should be combined with action permissions. Showing a module does not automatically mean every action inside that module is allowed.
Action permissions
Action permissions control specific operations.
Examples include:
- Approving or rejecting devices.
- Running remote support actions.
- Managing packages and deployments.
- Running remote commands or tasks.
- Viewing or exporting audit records.
- Managing users and roles.
- Changing Server settings.
- Using AdminConsole.
Assign high-impact permissions only to roles that genuinely require them.
Full control
The system.full_control permission grants unrestricted access across Lanview administration features.
Use this permission sparingly. It should normally be limited to the smallest practical number of trusted administrators.
Two-factor authentication
Lanview can require two-factor authentication for Studio sign in.
Two-factor authentication helps protect Lanview accounts if a password is compromised.
Depending on the configuration, users may be asked to set up or verify a second factor when signing in. Authorised administrators can reset a user’s two-factor authentication state where required.
Password and account administration
Authorised administrators can manage Lanview users and roles from the Security module in Studio.
Common tasks include:
- Creating users.
- Enabling or disabling users.
- Resetting passwords.
- Assigning or removing roles.
- Creating roles.
- Changing role permissions.
- Resetting two-factor authentication for a user.
These actions are security sensitive and should be assigned only to appropriate roles.
Reasons and audit prompts
Lanview can require a reason before allowing certain sensitive actions.
Reason prompts can apply to activities such as security administration, remote support, device lifecycle changes and other privileged operations.
The organisation using Lanview decides what is considered a valid reason. Lanview records the reason supplied by the operator and applies the minimum reason length configured on Lanview Server.
What gets audited
Lanview Server records audit events for security and administration activity.
Audit records may include:
- Sign in success, failure and rejection.
- Sign out or session end.
- Permission denied events.
- Missing required reason events.
- User creation, update, disable, delete and password reset.
- Role creation, update, copy, delete and permission changes.
- Two-factor authentication setup and reset activity.
- Authentication and audit policy changes.
Audit records help administrators review who performed an action, what was changed and whether the action was allowed or denied.
Recommended role design
Start with a small number of clear roles and expand only when needed.
Typical role groups might include:
| Role type | Typical access |
|---|---|
| Viewer | Can view devices or inventory but cannot perform administrative actions. |
| Technician | Can perform common support actions within defined limits. |
| Senior technician | Can perform higher impact support actions where required. |
| Security administrator | Can manage users, roles, permissions and authentication settings. |
| Server administrator | Can manage Server settings, recovery operations and high-impact features. |
Role names should match the organisation’s own structure. The important point is to give users the minimum number of permissions to allow them to conduct their role and review them regularly.
Break glass access
Some Server-level recovery actions are intended for local emergency use only.
These should be documented in internal administrator procedures and protected by normal Server access controls. They should not be treated as everyday administration tools.