Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Security RuntimeUsers (Reference) 

extend solution access dynamically during runtime, allowing user management without modifying the solution configuration. RuntimeUsers provide:

  • Dynamic user creation during runtime
  • External database integration
  • Active Directory/LDAP authentication
  • Temporary or permanent user accounts
  • Script-based user management

RuntimeUsers combined with SecurityUsers form the complete Solution Users.

In

The RuntimeUsers allows to extend the Users with authorization to access the Solution when it is running, dynamically extending the list of the solution's users.

The RuntimeUsers can be enabled from the following sources:

  • Creating RuntimeUsers with Scripts, using the Security namespace 
  • From External SQL databases (As defined in the Dataset.DB.RuntimeUsers connections)
  • Integration with AD or LDAP server
On

this page:

Table of Contents
maxLevel

3

2
minLevel2
indent10px
excludeSteps
stylenone

Understanding RuntimeUsers

The combination of the Runtime Users and the ones defined at the SecurityUsers table are called Solution Users.

Note

The main difference between the two is that engineering users can access the software's engineering mode, allowing them to design and configure the project. In contrast, runtime users only can use the application, they cannot change the project configuration or design since they don't have access to the engineering mode.

Another distinction is that the regular Users are defined within the Solution file itself, as the Runtime Users are defined in external Security Servers or databases.

RuntimeUsers SQL Table

At Security / RuntimeUsers, you can access the contents of the RuntimeUsers defined on the external SQL database. 

That database is defined by the configuration of the object Dataset.DB.RuntimeUsers.

When the solution is created, by default that table is created using a SQLite database.

This table is Read-Only for the Designer, to modify the list of Users, you must modify the source Database directly, or use the Script CreateUser methods.

Property

Description (Read-only)

ID

Displays the unique identifier of the runtime user as defined in the system.

Name

Displays the name of the runtime user as registered in the system.

LockState

Displays the current lock state of the runtime user's account according to the system's security protocols.

Permissions

Displays the list of permissions granted to the runtime user, as specified in the security permissions table.

Password

Displays the runtime user's password in a secure, encrypted format.

PasswordHint

Displays the hint associated with the runtime user's password, as set during account creation or update.

Policy

Displays the security policy applied to the runtime user, as defined in the security policies table.

Blocked

Displays whether the runtime user is currently blocked from accessing the system, based on security settings.

Deleted

Displays if the runtime user's account has been marked for deletion in the system.

DateModified

Displays the date and time when the runtime user's details were last modified in the system.

DateCreated

Displays the date and time when the runtime user's account was created in the system.

ContactInfo

Displays the runtime user's contact information as recorded in the system.

Level

Displays the runtime user's level or rank, as designated in the user management system.

Category

Displays the category of the runtime user, reflecting their role or type as defined in the system.

Alias

Displays an alternate name or identifier for the runtime user, as set in the system.

Company

Displays the company or organization linked to the runtime user, as recorded in the system.

UserGroup

Displays the group or department to which the runtime user is assigned, as specified in the system.

InvalidAttempts

Displays the count of invalid login attempts by the runtime user, as tracked by the system.

LastChangePasswordUTC_Ticks

Displays the timestamp in UTC ticks of the last password change by the runtime user, as logged by the system.

ChangePasswordRequired

Displays whether the runtime user is required to change their password at the next login, as per system policy.

LastBlockedUserUTC_Ticks

Displays the timestamp in UTC ticks when the runtime user was last blocked, as logged in the system.

RuntimeUsers vs SecurityUsers

AspectSecurityUsersRuntimeUsers
CreationDesign-time onlyRuntime only
StorageSolution fileExternal database
Engineering AccessYesNo
Modify SolutionYesNo
Runtime AccessYesYes
SourceInternalExternal/Scripts

<ac:structured-macro ac:name="note"> ac:rich-text-body RuntimeUsers cannot access Engineering mode or modify solution configuration. They are application users only. </ac:rich-text-body> </ac:structured-macro>


Configuration Sources

1. Script Creation

csharp

// Create user programmatically
@Security.CreateUser(
    "john.doe",
    "password123",
    "Operator,Maintenance",
    "Enhanced"
);

2. External SQL Database

Configure at Datasets → DBs → RuntimeUsers

  • Default: SQLite database
  • Supports: SQL Server, MySQL, PostgreSQL
  • Auto-created table structure

3. AD/LDAP Integration

  • Users validated against directory
  • Created in memory only
  • No database storage
  • See [Windows AD/LDAP Server]

RuntimeUsers Table Properties

Access read-only view at Security → RuntimeUsers:

PropertyDescriptionModifiable
NameUnique usernameVia script/DB
PasswordEncrypted credentialVia script/DB
PermissionsGroup assignmentsVia script/DB
PolicySecurity policyVia script/DB
BlockedAccess denied flagVia script/DB
DeletedSoft delete markerVia script/DB
InvalidAttemptsFailed login countAuto-updated
ChangePasswordRequiredForce password changeVia script/DB
LastChangePasswordUTC_TicksPassword change timestampAuto-updated
LastBlockedUserUTC_TicksBlock timestampAuto-updated
LevelHierarchical accessVia script/DB
CategoryUser classificationVia script/DB
ContactInfoEmail/phoneVia script/DB
CompanyOrganizationVia script/DB
UserGroupDepartmentVia script/DB

Database Configuration

Default SQLite Structure

Location: <SolutionPath>.dbRuntimeUsers

Table automatically created with:

  • User authentication fields
  • Permission assignments
  • Policy enforcement
  • Audit tracking

Custom Database

  1. Configure Datasets → DBs → RuntimeUsers
  2. Set connection string
  3. System creates table if missing
  4. Maintain schema compatibility

Script Management

Creating Users

csharp

public void CreateOperator(string username, string password)
{
    bool success = @Security.CreateUser(
        username,
        password,
        "Operator",  // Permissions
        "Default"    // Policy
    );
    
    if (success)
    {
        @Info.Trace($"User {username} created");
    }
}

Modifying Users

csharp

// Change password
@Security.ChangePassword("john.doe", "newPassword");

// Update permissions
@Security.SetUserPermissions("john.doe", "Operator,Supervisor");

// Block user
@Security.BlockUser("john.doe");

Deleting Users

csharp

// Soft delete (mark as deleted)
@Security.DeleteUser("john.doe", softDelete: true);

// Hard delete (remove from database)
@Security.DeleteUser("john.doe", softDelete: false);

AD/LDAP Users

Characteristics

  • No database storage
  • Memory-only during runtime
  • Permissions from AD groups
  • Automatic authentication
  • Session-based existence

Configuration

csharp

// Enable AD authentication
@Security.AuthenticationMode = "WindowsAD";
@Security.ADDomain = "company.local";

// Map AD groups to permissions
@Security.ADGroupMapping["Domain Users"] = "Operator";
@Security.ADGroupMapping["Domain Admins"] = "Administrator";

Runtime Behavior

User Validation Order

  1. Check SecurityUsers (internal)
  2. Query RuntimeUsers database
  3. Validate against AD/LDAP
  4. Apply Guest if no match

Session Management

csharp

// Get all active users
var users = @Security.GetActiveUsers();

// Check if RuntimeUser
bool isRuntimeUser = @Security.IsRuntimeUser(username);

// Get user source
string source = @Security.GetUserSource(username); 
// Returns: "Internal", "Database", "AD"

Best Practices

  1. Use appropriate source - AD for enterprise, DB for standalone
  2. Set permissions carefully - RuntimeUsers can't be admins
  3. Implement audit trail - Track user creation/modification
  4. Regular cleanup - Remove inactive RuntimeUsers
  5. Secure database - Protect RuntimeUsers table
  6. Document user sources - Clear origin tracking
  7. Test authentication - Verify all paths work

Troubleshooting

User not found:

  • Check database connection
  • Verify table exists
  • Review AD connectivity
  • Confirm username format

Cannot create user:

  • Verify CreateUsers permission
  • Check database write access
  • Review policy restrictions
  • Confirm unique username

AD users not working:

  • Test domain connectivity
  • Verify group mappings
  • Check authentication mode
  • Review domain credentials

Database errors:

  • Verify connection string
  • Check table schema
  • Review permissions
  • Test database access




In this section...

Page Tree
root@parent
spaces93DRAF

RuntimeUsers from AD or LDAP

RuntimeUsers who access the Solution based on AD/LDAP validation will not appear in the RuntimeUsers Database. These users are created directly in memory while the Solution is running, as their usernames and permissions are managed by external security servers

For Information to use AD/LDAP go to Windows AD / LDAP Server.

In this section:

Page Tree
rootV10:@parent
spacesV10