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.

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:

      Open

      

      ALL Users – No access to “Bahmni Analytics” collections
      Open

      

      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: