edoc automate Guide
Breadcrumbs

Restrict access to a view

In this example scenario, you will learn how you can restrict access to views using permissions.

The access restriction means that all users must authenticate themselves when accessing the view. You can also specify that only users with certain roles and permissions can access the view. Users without sufficient permissions receive a message that they do not have the appropriate permissions.

Prerequisites for this example scenario

  • You have already created an app with at least one view and are familiar with the basic functions of edoc automate.

  • You have the knowledge and permissions to manage and create users and groups in Keycloak.

For more information about managing users and groups in Keycloak see the Keycloak administration guide at: https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-users_server_administration_guide

You can access the Keycloak interface via <server>/auth.

Restrict access to a view using roles

You can define individually for each view whether users must authenticate themselves or have certain permissions. You can first create roles in your app. The roles can be automatically added to the connected Keycloak if they do not yet exist.

Here's how

  1. Open the desired view to which you want to restrict access.

  2. Click on Permissions in the menu bar.

  3. Enter the name for a new role in the Role field in the Execute section.

  4. Press Enter or click on Add to add the new role.

  5. Click on Apply.

Be sure to save the view before you continue.

If the role does not yet exist in Keycloak, you still need to assign users or groups to this role.

For more information about assigning permissions using roles and groups see the Keycloak administration guide at: https://www.keycloak.org/docs/latest/server_admin/index.html#assembly-managing-users_server_administration_guide

Things to know about access restrictions for integrated views

If a view is reused within another view and access restrictions have been defined, these are automatically inherited by the integrating view.

This means the following:

  • A view without its own permissions automatically takes over the permissions of all integrated views.

  • If several integrated views require different roles or permissions, a user must have all the necessary roles to be able to call up the higher-level view.

  • If one of the necessary permissions is missing, access to the integrating view is not possible, even if no direct restrictions have been defined for it.

Example:

Let's suppose, view A contains view B and view C:

  • View B is only accessible to users in the Editor role.

  • View C requires the Manager role.

If view A itself does not have its own permissions, a user requires both the Editor and Manager roles to be able to open view A.

Tips

  • When integrating views, check which permissions the views have in order to avoid unwanted access restrictions.

  • If necessary, you can adjust permissions specifically or select alternative approaches to control the desired access.