Security in Vision App Maker is handled centrally by the platform, separately from business logic. Every portal, mobile app, info kiosk and API built with App Maker uses the same identity, authentication and authorization model.
How security is organized
Requests pass through three layers: the front-end clients, the API Gateway and the backend microservices. The API Gateway is the central control point. It validates sessions, tokens, cookies and permissions before a request reaches the services, and the services receive the user's identity and rights through secure mechanisms.
Portals run over HTTPS with SSL/TLS sessions. For external access, public components can sit in a DMZ and reach the internal network through a reverse proxy, without exposing databases or internal services directly.
Authentication methods
Each portal can use a different method, so employees, administrators, citizens, customers and partners can follow different policies. Methods are selected and configured in the application security settings, without code changes.
| Method | Typical use | What it provides |
|---|---|---|
| Vault (built-in) | Organizations that manage identities in the platform; external portals whose users are not in the internal directory | Local accounts created, edited, verified and blocked by administrators; two-step authentication per account |
| Active Directory / LDAP | Internal portals that use existing corporate accounts | Sign-in with directory credentials; optional mapping of directory groups to App Maker groups |
| Keycloak | Organizations with central identity and access management | Single sign-on, multi-factor authentication, OpenID Connect, OAuth 2.0, SAML 2.0, identity federation |
Active Directory and LDAP
The integration can work in two modes:
- the directory authenticates users and access rights are managed in App Maker;
- the directory authenticates users and also supplies their groups, which are mapped to App Maker groups.
Users can be created automatically at their first successful sign-in or imported in bulk.
Keycloak
The configuration includes the Keycloak server URL, realm, client, client secret, default groups for new users and the mapping of Keycloak groups to App Maker groups. Identity and authentication policies stay in Keycloak; App Maker applies access rights to portals, features, workflows, forms and resources.
Multi-factor authentication
Vault accounts can use two-step authentication, enabled per user. With Keycloak, the platform uses the MFA policies configured there, such as OTP apps, verification codes or hardware tokens. MFA can be applied by user profile, role, risk level or organizational policy.
Authorization model
Access is based on users, groups, roles, permissions, organizational units and the organization chart.
| Element | Role in access control |
|---|---|
| Users | Internal or external accounts with profile, contact data, organizational unit, groups, language, account status and security settings |
| Groups | Logical sets of users, defined locally or taken from Active Directory or Keycloak and mapped to internal groups |
| Roles and permissions | What a user can access: start a workflow, approve a step, view a document, edit data, administer configuration |
| Organizational units and org chart | The real structure of the organization; used for access control, task routing and approvals that depend on manager, department or reporting line |
Permissions control access to menus, pages, forms, workflows, activities, documents, actions, resources, administrative features and configured services. They can apply globally or in context, for example by workflow state, activity, organizational unit or group membership. This supports role-based access control (RBAC) and finer policies built on business rules.
Interface-level security
Menus, pages, buttons, form sections and actions are shown or hidden according to the user's rights. On a form, each field can be visible or hidden, editable or read-only, mandatory or optional, conditioned dynamically and validated by rules. Users see only the information and actions their rights allow.
Workflow-level security
Access rules apply to activities, states, transitions, forms and actions. A workflow defines who can start the process, view an instance, edit data, approve, reject, sign, upload or download documents, see the history and complete a step. Access can depend on roles, groups, organizational units, business rules or the context of the instance.
Internal and external portals
The internal portal holds the standard administration, security, configuration and content management features and is used by employees, operators, administrators and configurators. The external portal serves citizens, customers or partners. Administrative and configuration features are not available in the external portal, which reduces the attack surface and keeps separate policies for internal and external users.
API Gateway protections
The API Gateway intercepts incoming requests, checks authentication, validates tokens or cookies, applies authorization rules and forwards only permitted requests. It provides:
- session and token validation, permission checks;
- request validation;
- rate limiting, throttling and an IP allow-list;
- CORS and SSL termination;
- logging and monitoring.
Microservices can validate access rights again, so security does not depend on a single layer.
Data protection and continuity
The platform protects data in transit and at rest and supports continuity of operation.
- External traffic is encrypted with TLS.
- Documents are encrypted at rest and in transit.
- In the cluster, network policies isolate components and RBAC controls access.
- Container images can optionally be scanned, for example with Trivy or Clair.
- Backup policies cover the database, files and configuration.
- Every component can run in high-availability mode.
Sessions
- Sessions use tokens or cookies with HttpOnly and Secure attributes; tokens can carry identity, roles, groups and other claims needed for authorization.
- Users are signed out automatically after an inactivity period set in minutes.
- Session validity and the maximum number of concurrent users are configurable; above the limit, users can wait in a queue.
- Administrators can monitor active sessions and users in the queue.
