fix: Better explanation of the interaction between users/roles and multi-tenancy (#1516)

* fix: HA reference architectures link (#1513)

* better user/role explanation

* multi-role <-> multi-tenant fixes

---------

Co-authored-by: Andi Skrgat <andi8647@gmail.com>
Co-authored-by: Matea Pesic <80577904+matea16@users.noreply.github.com>

Author: 3 people

pages/database-management/authentication-and-authorization/multiple-roles.mdx

@@ -336,20 +336,22 @@ The special logic ensures that when accessing a specific database, only roles
 assigned to that database are considered:
 
 ```cypher
--- Role with access to multiple databases
-CREATE ROLE multi_db_role;
-GRANT DATABASE db1 TO multi_db_role;
-GRANT DATABASE db2 TO multi_db_role;
-GRANT MATCH, CREATE ON db1 TO multi_db_role;
-GRANT MATCH ON db2 TO multi_db_role;
-
--- User with this role
+-- Create roles with different permissions
+CREATE ROLE read_write_role;
+GRANT MATCH, CREATE TO read_write_role;
+GRANT DATABASE db1 TO read_write_role;
+
+CREATE ROLE read_only_role;
+GRANT MATCH TO read_only_role;
+GRANT DATABASE db2 TO read_only_role;
+
+-- User with different roles on different databases
 CREATE USER user1 IDENTIFIED BY 'password';
-SET ROLE multi_db_role FOR user1 ON db1;
-SET ROLE multi_db_role FOR user1 ON db2;
+SET ROLE read_write_role FOR user1 ON db1;
+SET ROLE read_only_role FOR user1 ON db2;
 
--- When accessing db1: has MATCH, CREATE
--- When accessing db2: has only MATCH
+-- When accessing db1: has MATCH, CREATE (from read_write_role)
+-- When accessing db2: has only MATCH (from read_only_role)
 ```
 
 ## Best practices for multi-tenant environments

pages/database-management/multi-tenancy.mdx

@@ -16,11 +16,13 @@ In the current version, all isolated databases share the underlying resources so
 there is no provision to restrict CPU or RAM usage for a specific database.
 Instead, global limitations are imposed on Memgraph as a whole.
 
-## Default database
+## Default (memgraph) database
 
-A default database named `memgraph` is automatically created during startup. New
-users are granted access only to this default database. The default
-database name cannot be altered.
+A default database named `memgraph` is automatically created during startup.
+When you create a user or role, they have access to the default database
+(memgraph) by default. The default database name cannot be altered.
+
+To remove this default access, you should use `REVOKE DATABASE memgraph FROM role_name;`. Using `REVOKE` removes the default grant but allows the role to potentially receive access through other means (e.g., if combined with another role that has access). Using `DENY` would explicitly forbid access regardless of other roles.
 
 ### Default database best practices
 
@@ -41,8 +43,8 @@ access to other databases but not the default one.
 
 #### Recommended setup
 
-1. **Restrict memgraph database access**: Only grant access to the "memgraph"
-   database to privileged users who need to perform system administration tasks
+1. **Restrict memgraph database access**: Treat the "memgraph" database as a
+   system database and allow only administrators to have access to it
 2. **Use tenant-specific databases**: Store all application data in dedicated
    tenant databases
 3. **Separate concerns**: Keep user management, role management, system
@@ -59,9 +61,13 @@ GRANT DATABASE memgraph TO system_admin;
 
 -- Create tenant-specific roles (no access to memgraph database)
 CREATE ROLE tenant1_admin;
+REVOKE DATABASE memgraph FROM tenant1_admin;
 CREATE ROLE tenant1_user;
+REVOKE DATABASE memgraph FROM tenant1_user;
 CREATE ROLE tenant2_admin;
+REVOKE DATABASE memgraph FROM tenant2_admin;
 CREATE ROLE tenant2_user;
+REVOKE DATABASE memgraph FROM tenant2_user;
 
 -- Grant appropriate permissions to tenant roles
 GRANT MATCH, CREATE, MERGE, SET, DELETE, INDEX TO tenant1_admin;
@@ -78,8 +84,10 @@ GRANT CREATE, READ, UPDATE, DELETE ON NODES CONTAINING LABELS * TO tenant2_user;
 GRANT CREATE, READ, UPDATE, DELETE ON EDGES CONTAINING TYPES * TO tenant2_user;
 
 -- Grant access only to tenant databases
-GRANT DATABASE tenant1_db TO tenant1_admin, tenant1_user;
-GRANT DATABASE tenant2_db TO tenant2_admin, tenant2_user;
+GRANT DATABASE tenant1_db TO tenant1_admin;
+GRANT DATABASE tenant1_db TO tenant1_user;
+GRANT DATABASE tenant2_db TO tenant2_admin;
+GRANT DATABASE tenant2_db TO tenant2_user;
 
 -- Create users
 CREATE USER system_admin_user IDENTIFIED BY 'admin_password';
@@ -144,14 +152,32 @@ Users interact with multi-tenant features through specialized Cypher queries:
 5. `SHOW DATABASES`: Shows only the existing set of multitenant databases.
 6. `USE DATABASE name`: Switches focus to a specific database (disabled during
    transactions).
-7. `GRANT DATABASE name TO user`: Grants a user access to a specified database.
-8. `DENY DATABASE name FROM user`: Denies a user's access to a specified
-   database.
-9. `REVOKE DATABASE name FROM user`: Removes database from user's authentication
-   context.
+7. `GRANT DATABASE name TO user_or_role`: Grants a user or role access to a
+   specified database.
+8. `DENY DATABASE name FROM user_or_role`: Explicitly denies a user or role
+   access to a specified database.
+9. `REVOKE DATABASE name FROM user_or_role`: Removes the database from the
+   user's or role's database access list.
 10. `SET MAIN DATABASE name FOR user`: Sets a user's default (landing) database.
 11. `SHOW DATABASE PRIVILEGES FOR user`: Lists a user's database access rights.
 
+### Removing database access: DENY vs REVOKE
+
+There are two ways to remove access to a database: `DENY DATABASE x` or `REVOKE
+DATABASE x`. They behave differently:
+
+- **DENY** explicitly bans the user or role from the database. If any role that
+  a user has (or the user itself) is denied access to a database, the user
+  cannot access it. Deny trumps any other access granted—no combination of
+  grants can override a deny.
+- **REVOKE** removes the database from the user's or role's database access
+  list. It does not block access: if the user has other roles (or the user
+  itself has access through another path) that still have access to that
+  database, the user can still use it when connected to that database
+  (tenant).
+
+Use **DENY** when you need to explicitly forbid access to a database for any user with that role, regardless of their other roles. Use **REVOKE** when you simply want to remove the default access (like the default "memgraph" database access) or a previously granted access, allowing the user to potentially access the database if another of their roles grants it.
+
 ### DROP DATABASE with FORCE
 
 The `DROP DATABASE` command removes an existing database. You can optionally