Request failed with status code 502

Access Management

The beginning of your implementation begins by setting up users, groups and access lists - long

  • Episodes10
  • Duration37m 46s
  • LanguagesEN
Episode 2

Basic Concepts

Users, Groups, Visualisations, Etc.

Introduction

There are two types of users:

  • Those that run GRC and have an interest in populating eramba with information (Risks, Controls, Etc). We typically call them "Administrators".
  • Those that provide feedback - Risk Reviews, Control Evidence, Etc. We typically call them "Users".

While all of them need to access eramba, what they can "Do" and what they can "See" will differ. First, let's make a clear difference between what we mean by "Do" and "See".

In the screenshot above you can see in red boxes what you can "Do" in eramba, this is modules on the left, a menu bar on the top and options for every item on the section (in this example, Risks). Anything you can "Click" falls under the "Do" definition.

In green what data users can "See", in this example Risks. In short, data.

The screenshot above shows what another user can "Do" and "See". As you can see this user has access to fewer modules, does not get a menu bar on the top and on the items is only allowed to access Comments and Attachments. The user can only see two risks, that are related to the logged-in user (Esteban Ribicic).

Is important you realize the difference between these two things because you are expected to configure the system in a way that suits what your users need to "Do" and "See".

Users

You will need to create user accounts in eramba regardless of the authentication method you choose. You can create user accounts in three ways:

  • One by one
  • Using CSV imports
  • LDAP Synchronization.

All user management actions are performed under "System" > "Settings" > "User Management".

Groups

Users must belong to at least one group (defined under "System" > "Settings" > "Groups"). Groups define what users can "Do", so the more groups you grant to a user typically the more things the user can "Do". Eramba ships with typical groups, for example: View Risks, View Policies, Create Comments & Attachments. If you granted these three groups to a user, the user would be able to "See" Risks but not Edit or Delete them (because these groups only let users "View"). 

We also assign groups to users in reference to what they do in your organisation, for example: IT, Finance, HR, Etc. When you create groups by default they give access to nothing, so you will create these groups and leave them as is (without any access). A typical user then might have assigned the following groups:

  • View Risks (gives some permissions)
  • Add Comments & Attachments (gives some permissions)
  • Finance (tells us where the user works in the organization)

The first two groups will be used to determine what the user can do, and the third group to know he/she belongs to Finance. You always assign to users these two types of groups, at least one of each type:

  • Where you work
  • Where you can click

Groups are made of "Access Lists". Any click in eramba is an "Access List", so as you can imagine, there are many to choose from. Under "System" > "Settings" > "Authorization", you can there define, for each group, what permissions (access lists) you want to Allow or Deny. Remember by default any new group you create won't have any Allow permission.

Visualizations

When users log into eramba and assume they belong to a group that allows them to access some module, you need to ask yourself what they will "See". By default, eramba will show what relates to them.

Everything in eramba has some form of "Role", for example, if you create a Policy, you need to tell eramba who the "Owner" is, and who the "Reviewer" of that policy is. Eramba then knows who owns what, and logged users will only be shown what they own.

We call this the Visualisation principle, and it is enabled by default. You can adjust Visualisation rules under "System" > "Settings" > "Visualisation", you can override this setting on every module for any given user. You could say Esteban Ribicic on the Risk module can see all items, not just his Risks. By default, only members of the Admin group can "See" everything.

Generally speaking, we recommend you assign to items (Risks, Policies, Controls, Etc) groups (Finance, IT, HR, Etc) and not users (Esteban Ribicic, Etc). All members of the group will be able to see the item, and since you can add more than one user to the group, you will be able to have some redundancy.

Portals

Eramba has some functionalities that have a portal of their own. For example, the "Policy Portal" is accessed through a special URL and therefore is separated from the "Main" portal. The Awareness Program, Account Review, and Online Assessment modules all have their own portal, with their own login screen, that once authenticated, show specific features.

You can control which users access these portals because you define the authentication methodology for each one of them under "System" > "Settings" > "Authentication".

With the exception of the Policy and Awareness portal, when you create a user you must also define what portals users can access. This provides a second layer of isolation in between portals. By default all portals with the exception of the "Main" portal are disabled.

Authentication

eramba supports three authentication methods:

  • Local (eramba holds the user password on its database)
  • LDAP (eramba passes credentials to an LDAP directory of your choice)
  • SAML (eramba passes credentials to a SAML service provider of your choice)

Whatever authentication option you define for the "Main" portal will be inherited by the Account Reviews, Online Assessment portals. The Policy and Awareness Portal only support LDAP.

SAML and LDAP require special "Connectors" you must define in order for eramba to interact with this authentication providers.