Managing access control

Access control on the Platform plays a critical role in ensuring security and convenience. It allows restricting access to resources only to authorized users, minimizing the risk of confidential information leakage and unauthorized use. At the same time, it contributes to efficiency, as users have quick access to what they need without wasting time searching or waiting for permissions. This approach strikes a balance between protecting against potential threats and creating a user-friendly environment for interacting with the Platform.

Key terms and concepts related to access control include:

Access control principles establish basic guidelines and approaches for implementing security and efficiency in access management on the registry Platform.

The Platform for state registries builds its authorization model using the following access control methods:

Access management on the Platform for state registries is achieved through four key components:

An external identity provider in the User and User and role management service (Keycloak). Through the use of ISEI, the Platform’s cabinet allows users to undergo e-identification using electronic signatures (file-based, cloud-based, or other secure media) and MobileID or BankID NBU.

Access rights segregation on the Platform is implemented based on roles, which are further divided into two types: system and regulatory roles. System roles come with corresponding permissions and are delivered with the platform. Regulatory roles are designed to provide flexibility in the rights segregation process and offer developers the ability to cover all necessary needs in various registries.

Citizen (service recipient):

The authentication process for service recipients concludes with their entry into the corresponding portal. During the initial authentication process for citizens, their profile is created in the KeyCloak Realm, and their attributes are populated with information obtained from the electronic signature and data integration with the Unified state register. The system automatically assigns one of three system roles based on the user’s attributes:

unregistered_individual — an individual unregistered_entrepreneur — an individual entrepreneur or representative unregistered_legal — a legal entity representative

These listed system roles grant service recipients access to their data and the single available business process, which is onboarding. Once a user completes the onboarding process, the temporary role with the UNREGISTERED prefix is replaced with the corresponding permanent role:

individual - an individual entrepreneur -an individual entrepreneur or representative legal - a legal entity representative

The mechanism for granting citizens access to business processes in their portal relies on these specified roles. The authorization rules for these roles in business processes are defined by the regulations developer.

Officers (service providers):

Service provider roles can be assigned during self-registration if enabled at the registry level, created directly through KeyCloak, created during batch user uploads, or acquired through a regulations process.

During self-registration, service providers authenticate themselves and enter their portal. In this process, their profile is created in KeyCloak and enriched with the appropriate attributes. Upon successful authentication, service providers are assigned the temporary role unregistered-officer. The transition from this role to the system role officer for automatically created service providers is managed entirely within the scope of business process modeling. To enhance convenience and flexibility in the authorization system, there is the option to create fully automatic (business processes that confirm the user and change the temporary role to a system role) and semi-automatic (business processes that require registry managers' intervention in the access confirmation process) business processes.

Additionally, following the principle of least privilege, default roles specified in the registry configuration are assigned to service providers created during authentication.

Administrators:

When creating a Platform administrator or registry administrator, they are assigned standard corresponding roles by default, following the principles of the Principle of Least Privilege and Need-to-Know Principle. This ensures they have access only to the information necessary to perform their duties.

Furthermore, additional roles for platform and registry administrative services can be added via KeyCloak.

The Platform for state registries provides the capability to expand the list of roles for Officers and Citizens through regulations roles. In the future, regulations roles can be used to configure access control at the physical model level or to adjust access to specific regulations business processes.

The Platform for state registries offers the ability to establish a hierarchical model of data object access based on the levels of the hierarchical structure and user roles. This enables control over access to objects based on their hierarchical position and user roles.

The hierarchical model consists of three main components:

The model allows regulatory process developers to design permission assignments for accessing registry data, taking into account the complexity of the organizational structure. An illustrative example of using the hierarchical model is the structure of a Codifier of administrative-territorial units and territories of territorial communities (UA-specific).

When the hierarchical model is used, effective data access permissions can be visualized as shown in the diagram.

Session management and its provision are of great importance in the context of security and the proper functioning of the Platform for state registries. A session is a temporary dialog between the user and the system that occurs during user authentication and authorization. Session management allows tracking user activity, authenticating them, setting time limits, and, if necessary, forcibly terminating user sessions.

The users and roles management subsystem is configured as follows:

All administrative services and user portals initiate a complete logout sequence when a logout event is initiated. Session storage is designed securely and reliably. On the client side, sessions are stored in cookies, configured to only transmit over secure channels to prevent interception. Protection against unauthorized access by client scripts, such as JavaScript, is implemented to reduce the risk of cookie interception or XSS attacks. Additionally, protection against CSRF attacks is configured to ensure that cookies are used only on the intended website.

On the backend side, user sessions are stored in у Redis Sentinel.