Securing Metabase & Bahmni Mart Analytics Tool
Please read about Metabase permission strategy and authorization options here: https://www.metabase.com/learn/permissions/strategy
Recommendations regarding Bahmni Metabase security setup
The following are suggested recommendations regarding Bahmni Metabase setup. Please read the Metabase documentation for further guidance.
- Limit Access to Admin/All Users Group: Bahmni comes out of the box with two groups: 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.
- 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” collectionsALL Users - No access to Database exploration or SQL


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.

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.
Restrict access especially for OpenMRS db. (sensitive data tables).

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 |
|---|
| Person_address Users idgen_remote_source Idgen Identifier Source Patient_identifier_type Person_name 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 |
Bahmni Wiki · CC BY-SA 4.0