Security Permissions (Reference) define access control groups that determine what users can edit in the Designer and execute during runtime. Permission groups provide:
- Module-level access control
- Designer editing restrictions
- Runtime operation permissions
- Hierarchical security levels
- Role-based authorization
Permissions are assigned to users through group membership, allowing granular control over solution access.
In this page:
Pre-Defined Permission Groups
Seven standard groups are configured by default:
Group | Typical Use | Default Permissions |
---|---|---|
Administrator | Full system control | Unrestricted access |
Guest | Anonymous access | View-only, minimal rights |
User | Basic authenticated access | Standard operations |
Engineering | Solution development | Edit modules, test |
Supervisor | Operations oversight | Monitor, reports, alarms |
Maintenance | System upkeep | Diagnostics, tag values |
Operator | Daily operations | Displays, acknowledge alarms |
Configuration Properties
Property | Description | Required |
---|---|---|
Name | Unique group identifier | Yes |
Edit | Designer editing permissions | Yes |
Run | Runtime execution permissions | Yes |
Level | Hierarchical tier (0-255) | No |
Category | Group classification | No |
Description | Documentation text | No |
Edit Permissions
Controls access to Designer modules:
Permission | Description | Affects |
---|---|---|
Unrestricted | All editing rights | Complete Designer access |
EditTags | Modify existing tags | UNS tag properties |
CreateTags | Add new tags | UNS structure |
Security | User management | Users, permissions, policies |
Scripts | Code editing | Tasks, classes, expressions |
Datasets | Database configuration | Queries, tables, connections |
Displays | Screen development | Pages, popups, symbols |
Reports | Report design | Forms, WebData |
Historian | Data logging setup | Tables, triggers |
Alarms | Alarm configuration | Items, groups, areas |
Devices | Communication setup | Channels, nodes, points |
Startup | Runtime configuration | Execution settings |
Publish | Deploy solutions | Build and distribute |
Settings | Solution properties | Global configuration |
Notes | Documentation | Solution notes |
Run Permissions
Controls runtime operations:
Permission | Description | Impact |
---|---|---|
Unrestricted | All runtime rights | Complete control |
Test | Execute test mode | Debug capabilities |
Startup | Start server modules | Scripts, datasets, devices |
Shutdown | Stop application | Terminate runtime |
ClientStart | Start client modules | Displays, local devices |
ClientShutdown | Stop client | Close displays |
StartTools | Launch diagnostics | PropertyWatch, TraceWindow |
ToolsSetValues | Modify via tools | Write tag values |
CreateUsers | Add runtime users | Dynamic user creation |
SwitchApplication | Change context | Alt-Tab, taskbar access |
WebAccess | Web client login | HTML5 display access |
Configuring Permissions
Access Requirements
- Login as Administrator
- Navigate to Security → Permissions
- Administrator password required for changes
Setting Group Permissions
- Select permission group row
- Configure Edit permissions:
- Check modules user can modify
- Uncheck restricted areas
- Configure Run permissions:
- Enable allowed operations
- Disable restricted functions
- Save changes
Permission Inheritance
Users inherit combined permissions from all assigned groups:
User: John
Groups: Operator, Maintenance
Result: Union of both group permissions
Example combinations:
- Operator + Maintenance = Displays + Diagnostics
- Engineering + Supervisor = Development + Monitoring
- User + WebAccess = Basic rights + Web client
Runtime Permission Checks
Checking Current Permissions
csharp
// Current user's groups
string permissions = @Client.Permissions;
// Check specific permission
bool canEdit = @Security.HasPermission("EditDisplays");
bool canShutdown = @Security.HasPermission("Shutdown");
// Check multiple permissions
bool isAdmin = @Client.Permissions.Contains("Administrator");
Conditional UI Elements
csharp
// Show/hide based on permissions
if (@Security.HasPermission("StartTools"))
{
btnDiagnostics.Visible = true;
}
// Enable/disable functions
btnShutdown.Enabled = @Security.HasPermission("Shutdown");
Security Levels
Hierarchical access control using Level property:
Level Range | Typical Use |
---|---|
0-25 | View only |
26-50 | Basic operator |
51-75 | Advanced operator |
76-100 | Supervisor |
101-150 | Engineer |
151-200 | Manager |
201-255 | Administrator |
Usage:
csharp
// Check user level
if (@Client.Level >= 100)
{
// Show supervisor features
}
Best Practices
- Principle of least privilege - Grant minimum required permissions
- Use groups not individuals - Manage through group membership
- Document group purposes - Clear role descriptions
- Regular audits - Review permission assignments
- Test permission sets - Verify restrictions work
- Separate development/operations - Different groups for each
- Protect Administrator - Limit admin group membership
Common Permission Sets
Operator Standard
- Edit: None
- Run: ClientStart, WebAccess
- Use: Daily operations
Maintenance Technician
- Edit: EditTags
- Run: StartTools, ToolsSetValues
- Use: Troubleshooting
Shift Supervisor
- Edit: Alarms, Reports
- Run: Unrestricted except Shutdown
- Use: Operations management
System Engineer
- Edit: Unrestricted except Security
- Run: Test, StartTools
- Use: Development and testing
Troubleshooting
Cannot edit module:
- Check Edit permissions
- Verify group membership
- Confirm logged in correctly
- Not using Guest account
Runtime function disabled:
- Review Run permissions
- Check user's groups
- Verify permission spelling
- Test with Administrator
Permission not working:
- Clear permission cache
- Restart runtime
- Check group assignment
- Review permission conflicts
In this section...