Securing Metabase & Bahmni Mart Analytics Tool

Since Metabase might be configured to access OpenMRS DB or Mart DB, containing personal, sensitive, medical information, it is imperative to ensure you have permissions & restrictions in place that ensure people can only access the data they are supposed to access.

Metabase has options to control who can access which data, collection, tables, etc. In general, you would set defaults to restricted, and then only allow certain groups to have specific permissions. Then add users to appropriate groups so they get the correct access. A user can be added to more than one group in metabase.

Users (belong to) → Groups (which have) → Permissions (which control access to functionality)

Please read about Metabase permission strategy and authorization options here:

Recommendations regarding Bahmni Metabase security setup

The following are suggested recommendations regarding Bahmni Metabase setup. Please read the Metabase documentation for further guidance.

  1. Limit Access to Admin/All Users Group: Bahmni comes out of the box with two groups:

    1. Administrators: Any user part of this group has ADMIN rights to perform ALL Functions in Metabase. Make sure you LIMIT the number of users to this group to a bare minimum. You can’t edit/reduce permissions of Administrator group. They always have FULL ACCESS to all connected databases, tables and collections! Don’t share ADMIN credentials, to avoid malicious activity.

    2. All Users: Every metabase user is automatically also a part of this group. You cannot remove any member from this group. Therefore, it is recommended to REVOKE all permissions for this group, so that whenever a user is added to Metabase, they don’t get access to any database tables/collections, just because they have become part of the “All Users” group. People should always be explicitly added to an authorization group. See images below:

      ALL Users – No access to “Bahmni Analytics” collections
      ALL Users - No access to Database exploration or SQL
  2. Create your own group: Create one or more reporting groups, for instance: “Report Users” Group. Map the users to this group while creating a new user, so that the user receives only those permissions that are associated with this new group. You can create groups like “Mental Health Reports”, “Facility Reports”, “Financial Reports”, etc depending on whether you want to give different users access to different collections, or not. For simplicity, you can start with one group, and later create more if you like. A user can be added to more than one group, and they inherit the most “permissible” access across groups.

  3. Control Access to DB Tables: Ensure that you give “Granular” access to databases, so you can control which tables are visible. You can start by giving “No Self Service” at the DB level, and then click on the DB, to view all tables, and then give access, “Unrestricted” to individual tables. This will ensure, that users can only query the tables they have access to. Alternatively, you can give “Granular” access at DB level, and then restrict access to a limited table set. Note: Once, the DB is set to Granular/No-Self Service, if a new table is added to DB, by default, users won’t have access to that table, until it is granted to the group.

  4. Restrict access especially for OpenMRS db. (sensitive data tables).

  5. In OpenMRS DB, there are some sensitive tables, that should be not accessible by report users – for instance those containing user login details, or patient sensitive address details, global configurations, etc. Restricting access to these tables, as mentioned in step above, is highly recommended. See the list of tables which should NOT HAVE ACCESS are:

Tables in OpenMRS which should not be accessible

Tables in OpenMRS which should not be accessible

Idgen Identifier Source
User Property
Global property
Scheduler Task Config
Scheduler Task Config Property table
Bahmni Config table
Role table
User Role table
Role Privilege table
Privilege table
Markers table
Role Role table
EventRecordsOffsetMarker table
EventRecordsQueue table
FailedEventsRetryLog table
EventRecords table
Liquibasechangelog table
Liquibasechangeloglock table
FormPrivilege table
Bahmni Config Version table

Note: A user can view “reports” they have been given access to in collections, even if they don’t have access to the underlying tables. So withdrawing access to tables, does not break any reports. They continue to work. Read more here:

The Bahmni documentation is licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0)