Security Secrets Reference

Securely store credentials and secrets.

Reference → Modules → Security → UI → RuntimeUsers | Users | Permissions | Policies | Secrets | Monitor

Configuration Properties

Access at: Security → Secrets

Important: Only administrators can view or edit SecretValue. Standard users can reference secrets in configurations but cannot see the actual values.

Secret Types

Usage in Configurations

Datasets Integration

When configuring database connections:

1. Navigate to Datasets → DBs
2. In connection settings, select Use Secret
3. Choose from dropdown list of configured secrets
4. Connection uses encrypted value at runtime

Example:

Database: RuntimeUsers
Authentication: SQL Server Auth
Username: dbuser
Password: [Secret: DBRuntimePass]

Device/TagProvider Integration

For MQTT, OPC UA, and other protocols:

1. Navigate to Devices → Channels or TagProviders
2. In authentication fields, use secret reference syntax
3. Format: /secret-<SecretName>

Example:

MQTT Broker Authentication:
Username: mqttuser
Password: /secret-MQTTBrokerPass

Script Access

Secrets can be referenced in scripts:

csharp

// Get secret value (requires admin permission)
string password = @Security.GetSecret("DBPassword");

// Use in connection string
string connStr = $"Server=localhost;User={user};Password={password}";

Configuration Examples

Basic Secret Setup

Runtime Users Database Example

1. Create secret:
   • Name: RuntimeUsersDBPass
   • Type: Password
   • Value: [encrypted]
   • Description: RuntimeUsers SQL authentication
2. Use in Dataset:
   • Go to Datasets → DBs → RuntimeUsers
   • Set Password field to: [Secret: RuntimeUsersDBPass]

Security Considerations

Access Control Matrix

Encryption Details

• Values encrypted using AES-256
• Stored encrypted in solution file
• Decrypted only at runtime when needed
• Never logged in plain text
• Not included in solution exports

Best Practices

Naming Conventions

Implementation Guidelines

1. Create secrets before configuration
   • Define all secrets in Security module first
   • Then reference in other modules
2. Use descriptive names
   • Good: ProductionSQLPass
   • Bad: Secret1
3. Document usage
   • Always fill Description field
   • Include where secret is used
   • Note rotation schedule if applicable
4. Regular rotation
   • Change production secrets periodically
   • Update all references after rotation
   • Test thoroughly after changes
5. Environment separation
   • Use different secrets for Dev/Test/Production
   • Name accordingly: DevDBPass, ProdDBPass

Migration and Portability

Exporting Solutions

When exporting solutions:

• Secret names and types are exported
• Secret values are NOT exported
• Target system must recreate values

Import Process

1. Import solution to new system
2. Navigate to Security → Secrets
3. For each secret, enter appropriate value
4. Test all connections

Environment Variables Alternative

For containerized deployments:

FRAMEWORKX_SECRET_DBPassword=actualpassword
FRAMEWORKX_SECRET_MQTTKey=actualkey

Troubleshooting

Common Issues

Validation

Test secret configuration:

1. Create test secret
2. Reference in test connection
3. Verify connection succeeds
4. Check runtime logs for errors

Audit Trail

Secret operations are logged:

• Creation/modification timestamp
• User who made changes
• NOT the actual values

See Also

• Security Module (Reference) - Complete security documentation
• Datasets Configuration (How-to) - Using secrets in databases
• Device Connections (How-to) - Using secrets in devices
• Security Best Practices (Guide) - Security guidelines

In this section...