Course Introduction

Access Management in eramba defines how users authenticate, what they are allowed to do, and what data they are allowed to see across the platform.

This is considered a "Common Functionality" because it is used across all modules in the software. Each Use Case (Risk, Compliance, etc.) implements this module in slightly different ways; this is why it is important that while you understand the theory presented here, you always follow the specific implementation guides.

This documentation is structured as:

• Theory concepts that explain what you need to know in order to implement this module.

• Operations covers the steps required to use these theory concepts in eramba.

• There is no implementation phase as these tasks will come from the specific use case guides (Risk, Compliance, etc.).

Typical Scenarios

This chapter describes common access management scenarios:

• Users only view the items that relate to them.

• Allowing GRC administrators full access across all modules.

• Granting auditors read-only access to all items, regardless of ownership.

• Restricting access to specific modules.

• Controlling which parts of the interface users can interact with and which actions they are allowed to perform.

• Restricting access between different portals (Main, Policy, Awareness, Account Reviews, Online Assessments).

• Integrating eramba with external identity providers using SAML, LDAP, or Google OAuth.

Supported Versions

This guide applies to both on-premise and cloud deployments, and is valid for Enterprise and Community versions of eramba.

Scope

Access Management applies globally across eramba. All "Use Cases" and "Supporting Modules" require access management concepts in slightly different ways; these modules include the steps required to implement access depending on the specific module you are working with.

Theory

Groups

Groups are the foundation of access management in eramba. Every user account in eramba must have at least two groups, each one of them defining:

• Where the user works (departments, for example: Finance, HR, IT, Etc) and therefore what data they can see. We will call them "Department" groups.

• Where the user can access to the system, where they can or can not click. We call them "Permission" groups.

In the end, both Departments and Permission Groups are defined in the same place under System / Organization & Access / Groups and every user account you create in eramba will need at least two of them, one that tells you where that person works and the other that tells us where that person can Access in the software.

The diagram above illustrates a few typical scenarios:

• Mary has four groups assigned to her: two groups describe where she works (for example, IT Team and Board Member), and two groups describe what she is allowed to do in Eramba.
• John has two groups assigned to him: one that describes where he works (IT Team) and one that defines what he can do in Eramba.

When managing groups, Eramba does not distinguish between Department groups and Permission groups. The difference is identified solely by the group name and the naming convention you use.

There is a tendency to mix departments (IT) with roles (CTO); initially, only focus on departments and leave roles to the very end when you understand eramba better.

Department Groups

Every item created in Eramba (such as Policies, Controls, and similar objects) must be assigned to one or more Groups.

For example, when creating a Policy, you must define the GRC Contact and Policy Reviewer Contact, and these roles are always assigned using groups, not individual users.

By doing this, Eramba can determine which data should be visible to each user when they log in. For instance, a user who belongs to the IT group will be able to see the Software Development Lifecycle policy because it is associated with the IT group, while items related to other groups will not be visible.

While assigning items to specific user accounts is possible, in the long run it is much, much more difficult to maintain.

Members of the Admin group can see all data, regardless of which group it is assigned to. This is especially useful during the implementation phase, which is why its use is recommended at the beginning.

This is why is soo important that when you create an account, you assign a group that tells eramba where that person works.

When creating Department groups we recommend:

• Create groups for departments that consist of a manager and their team. This structure is essential because these managers are typically the individuals from whom you need to obtain feedback during the assessment process.

• Focus on Departments, Not Roles: Do not create groups for specific job titles like "Finance Manager" or "CEO." Instead, create groups for the departments or functional units those people lead.

• Use Consistent Naming Conventions: Use clear identifiers to distinguish between locations or functions. For example, use UK_Finance or Germany_Finance. If the Risks for example you will create you know affect them all and you will get Risk acceptance from a manager of all those financial deparments, then is best just to create a Finance group.

• Cross-Functional Teams: For teams that operate across multiple departments or countries, use their functional name directly, such as GRC or DevOps.

 

Permissions Groups

These groups are used to control what user accounts can do in Eramba. For example, can they click on "Add" or "Delete" or access the "Risk" modules?

Every Permission Group requires an "Access Control" definition that determines where users are allowed to navigate and what actions they can perform. Eramba includes multiple default Permission Groups with commonly used permissions, which simplifies configuration and reduces the need for custom setups.

When a group is created it has all these permissions blocked, for that reason if you create a Department group called "IT" and you assign it to a user, that user won't be able to access or do anything to eramba. Removing permissions will hide the features from the system making it a lot simpler (there will be less places where to click).

To see what Access Control permissions a group has, you need to go to System / Organization & Access / Access Controls. You can there select a group and see what permissions it has enabled and disabled.

Continuing the previous example, Mary has four groups assigned to her. Two of them are Department groups, which do not grant any access controls, and the other two are Permission groups, each providing a set of permissions. The effective access Mary has in Eramba is the sum of all granted permissions across her groups.

If two Permission groups conflict, granted permissions take precedence. For example, if Group A allows creating Policies and Group B denies it, and Mary is assigned to both groups, she will be able to create Policies.

Module Roles

Every module in Eramba (such as Risks, Controls, Policies, and others) defines one or more Roles that establish the relationship between users or groups and the items within that module. As mentioned earlier, the Policy module includes two roles: GRC Contact and Policy Reviewer Contact.

These roles can be renamed, and additional roles can be added if needed, using the common Customization common feature.

It is critical to assign groups, not individual user accounts, to these Roles and to ensure the correct groups are selected. Failing to do so will directly affect:

• Who can see the items

• Who will receive important email notifications sent by Eramba

• GRC accountability, including clear ownership and responsibility

Portals

Some sections in Eramba use portals, which are modules with a separate login page where you can perform activities related to that section. By default, only the Main Portal is enabled.

You can enable portals under: Settings / Authentication Methods / Authentication Methods

Once the portal is enabled, the authentication applied to that portal is inherited from the authentication defined on the Main portal.

When you create a user, you must define which specific portals they can access. This provides a second layer of isolation between portals, ensuring users only see the environments relevant to their role.

Visualisations 

As explained earlier, assigning Department groups to items is essential to control who can see what in Eramba. Can this user see all Policies or just the ones related to that user? the answer is always that with the exception of Admin (and Admin group members) user accounts can only see data that relates to them. 

This principle is referred to as Visualizations, and it is enabled by default in every module. If you need to exempt a specific user or group from this rule, you can do so under System / Organization & Access / Visualizations.

Granting an exception allows that specific user or group to see all items in the section, regardless of whether those items are assigned to them or not. This is particularly useful for auditors or global administrators who require oversight across all assessments.

For example, the CISO group and the user Fabian Lachta shown above can view all Internal Controls, even if those controls are not assigned to them.

Authentication

Accounts in eramba can be authenticated in two ways: locally, where user credentials are stored directly in eramba, and remotely, which authenticate users against an external Identity Provider.

Non-local accounts, the user’s password is managed by the Identity Provider and cannot be changed within eramba.

When creating a user account, you must select whether it will authenticate locally or remotely. Eramba supports a mix of local and remote authentication: accounts with the local authentication flag enabled will authenticate locally, while all others will authenticate remotely.

To authenticate users remotely, you must choose which authentication provider to use. Eramba supports the following options:

• LDAP: Eramba passes user credentials to an LDAP directory service of your choice, such as Active Directory (Video)

• SAML: Eramba passes authentication requests to a SAML service provider of your choice (Video)

• Google OAuth: Eramba uses Google OAuth to authenticate users (Video)

These connectors must be configured in advance under Settings / Authentication Methods, and only one connector can be active at a time.

Users Accounts

Broadly speaking, there are two types of user accounts in eramba

• GRC Users: These users are responsible for creating and managing policies, controls, risks, and other core GRC items. Every member of your team needs an account in Eramba.

• Departmental Users: These users are associated with departments across your organization. They are assigned specific items and are expected to provide feedback on them. Towards the end of the implementation, you will typically assign one or two user accounts to each of these departmental groups.

The following key concepts are important to highlight

• Groups
• Portals
• API Accounts
• Authentication

Create Account:

We strongly advise you NOT TO CREATE accounts other than the ones needed by your GRC department to implement eramba. At the end of the implementation, and just before the operational phase of eramba, you will create accounts and assign them to the groups previously created.

You can create accounts in Eramba using Forms, CSV Import, or LDAP Sync:

• Form: Complete the required values such as name, surname, username, email, and local account directly in the Eramba form.
• CSV Import: Fill out the template downloaded from Eramba and upload it back into the system. CSV imports are only for adding new users; they cannot be used to update or edit existing accounts.
• LDAP Sync: Create accounts by syncing your LDAP environment. To do this, you must have the LDAP connectors configured and create a sync under: Settings / Organization & Access / LDAP Synchronizations

LDAP syncs are based on LDAP groups, allowing you to select which Eramba groups and portals to assign to users in each LDAP group.

If the sync finds users in your LDAP that already exist in Eramba, you can select the action to take:

• Disable: Disables the account in Eramba without deleting it.

• Delete: Permanently deletes the account from Eramba.

• Ignore: Leaves the existing account in Eramba unchanged.

Delete Account

Accounts can be deleted as long as they do not have items assigned. If you try to delete an account that has items assigned, you will be prompted to reassign these items to a new user or group. It’s not possible to delete a user until this inheritance process is completed. Once this is done, the user will be deleted.

The default admin account cannot be deleted.

Change password

If you have a local account, you can change your password from User Settings (top-right corner, user profile). If you are an admin, you can also change passwords for other local users under: Settings / Organization & Access / Users

If you are using a non-local account, the password comes from your IdP, which means it cannot be changed directly in Eramba.

API Settings

To make API calls, you need a local account with the REST APIs checkbox enabled. Additionally, you must have the appropriate authorizations (assigned via a Permissions Group) for the specific sections you intend to access.

Always remember to log in to Eramba through the web interface with your API account before using it for REST requests. You will be required to change the password upon your initial login before the account becomes fully active for API calls.

Brute Force

By default, all locally authenticated accounts are protected by Brute Force protection. This means that if a user enters incorrect credentials while attempting to log into Eramba, the system will block further login attempts. Brute Force protection can be configured under Settings / Organization & Access / Brute Force Protection.

Blocked accounts can be unlocked by navigating to Settings / Organization & Access / User Bans.

Operation

Groups

Groups that have no user accounts associated can be added, edited, or deleted from Settings / Organization & Access / Groups. When a group is cloned, the new group inherits all Access Control definitions from the original group.

The association between groups and user accounts is managed in the User Account module, not in the Group module.

Access Controls

Once a group has been created, you can configure its access controls either by selecting Configure Access List from the Group module or by navigating to Settings / Organization & Access / Access Control and choosing the group you want to manage.

Changes on these settings are saved but not imposed inmediately, the user must logout and login for them to take effect.