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 Management, Compliance, Data Privacy, Etc) implements this module in slightly different ways; this is why it is important that while you understand the theory presented here and how the module is operated (add, edit, etc) 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.

• There is no implementation phase (the operation is embedded in the theory), 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.

LLMs

Statistically, most people don’t "read" — and certainly don’t fully "understand" — documentation. If you’re planning to take this course be assured you will get in trouble

You can use LLMs to clarify doubts from what you "read" to make sure you "understand", you simply need to copy the URL and paste it into your preferred LLM (OpenAI, Gemini, etc.) together with the prompt below

I’m trying to understand how Access Management works and how it’s implemented in Eramba. This is their documentation. If you’re able to review it, can you answer any quick questions I may have? This is the URL: (paste url here)

If you are somewhat diligent and careful on your questions you will get a lot of support from your LLM

You can then ask questions a bit like if you would be asking them on a demo call:

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

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

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.

Add/Edit/Delete Groups

You can create, edit, and delete (only if the group has not been assigned to user accounts or items) groups at System / Settings / Organisation & Access / Groups.

You will find multiple pre-defined groups. We recommend not modifying them. These groups serve the majority of use cases.

Add/Edit/Delete Access Lists

Once your group is created, by default it includes no permitted ACLs. Remember you should not need to adjust “Department” groups.

You can add or remove permissions for a group at System / Settings / Organisation & Access / Access Control. At the top of the screen, simply select the group that you would like to work with and then enable or disable features.

You will first select the module, then the sub-module, and for that sub-module you can enable or disable features. Feature names clearly indicate what service they provide; for example, “Index” is accessing the module altogether, Create New Item, etc.

Changes take effect after you make any modification. Users will have to log out and log in again to see these changes.

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.

When creating a user account, you must select whether it will authenticate locally or remotely. If the account is set to “Local,” you must define the password in Eramba; otherwise, the password is stored in your IdP. You can configure Eramba authentication as “Remote” (with an IdP) and still authenticate accounts locally, as long as they have the local option enabled and a local password set.

Connectors

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.

After the connector is created and tested, you can enable it on the “Main” portal. All user accounts that have the “Local Account” flag disabled will automatically start authenticating using the remote directory.

Users Accounts

Create Account

As you begin the implementation journey, we strongly advise you not to create accounts other than those 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. Remember always to assign at least two groups and only allow the minimum number of Portals possible.

• 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. Review the CSV documentation to learn how to use this method.

• 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

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 is not possible to delete a user until this reassignment 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.

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.