Right now Mongo Atlas allows you to assign two types of roles to all the users: Organization and Project, and for each set it gives you some predefined roles.

The problem with this is you can't have any kind of granular control of what permission is assigned to each user. (e.g. to allow a user to create a trigger through Mongo Stitch it needs the Project Owner role).

This is a major setback as I'm giving my coworkers more access than needed.

A good solution would be to have something like the database access control in this part so we can create our own custom roles to assign to he users.

Hello,

I think it would be a good idea to have team management at project level.
We have many projects and members in our Atlas account.
I'm a organization owner. The people in my organization use the Altas service. I create
a project for them and give my colleagues the project owner authorizations.

Project owners can invite other members. This is good. But it's a little inconsistent that
they are not able to create groups or teams within their projects They have to manage the permissions for each member separately.

We can't use organization teams, because they are located at the organizational level. Therefore, only the owner of an organization can create teams.
And only the owner of an organization can add or remove members from a team.

Much like built-in roles have the ability to target all databases/any database, it would be ideal if collection actions could also target any database. Similarly to how, when adding collection actions to a custom role, if you leave the "collection" field blank, it applies to all collections in the specified DB, it would be great if you could leave the "database" field blank too (or add an "any database" option) and have the actions associated with the role be allowed on any database.

This feature gap creates unnecessary maintenance overhead for clusters with large numbers of databases. This is particularly impactful if databases are added/removed/migrated frequently, creating the need for frequent manual maintenance or some kind of API-based automation to keep the role updated so that the actions can be performed on all databases that currently exist on the cluster.

We are using MongoDB-AWS for authentication, and have set up the audit log to log events taken by AWS roles. However, there is insufficient information in the logs to identify who is doing those actions, as roles can be assumed by multiple people.

An example log line in the current audit log:
{ "atype" : "authenticate", "ts" : { "$date" : "2021-01-05T00:21:52.628+00:00" }, "local" : { "ip" : "192.168.248.203", "port" : 27017 }, "remote" : { "ip" : "172.31.0.5", "port" : 54195 }, "users" : [ { "user" : "arn:aws:sts::555555555555:assumed-role/developer-role/", "db" : "$external" } ], "roles" : [ { "role" : "readWriteAnyDatabase", "db" : "admin" }, { "role" : "clusterMonitor", "db" : "admin" }, { "role" : "backup", "db" : "admin" }, { "role" : "atlasAdmin", "db" : "admin" }, { "role" : "dbAdminAnyDatabase", "db" : "admin" }, { "role" : "enableSharding", "db" : "admin" } ], "param" : { "user" : "arn:aws:sts::555555555555:assumed-role/developer-role/", "db" : "$external", "mechanism" : "MONGODB-AWS" }, "result" : 0 }

The user is identified as "arn:aws:sts::555555555555:assumed-role/developer-role/*", but the true ARN of the user is more like "arn:aws:sts::555555555555:assumed-role/developer-role/first.last@company.com", where the role session name carries identifying information.

In order to make the audit logs more useful, since multiple entities can assume a role, the audit logs should contain the full role ARN with the session name or the UserID of the assumed role.

At some point in the past, the logs contained the access key ID used to access the cluster, which could be correlated back to an individual user using Cloudtrail.

We would like to use the new role mapping feature for federated authentication to assign Atlas roles based on LDAP groups assigned to our users.

However, we frequently create new projects programmatically and would need to manage the permissions to these new projects using role mapping. However, there is no public API available to manage role mappings programmatically. In addition, enabling role mapping disables the ability to manage roles for federated users with the API. So, at present, role mappings and permissions can only be managed manually through the UI.

We would like to request the ability to modify role mappings (and possibly other federation features) through the Atlas API.

Currently Atlas only uses a single (flat) user group which only allows for 1 type of authentication per Organization.

However if Federated Authentication is enabled, the authentication mechanism in Atlas is bypassed for the IdP based on the domain name of the user and the configuration of Atlas Authentication.

This causes a problem if there are multiple groups of users who all share a domain name, some of whom are registered in an IdP, and some of whom are not registered in an IdP (for example users in 2 divisions of the same company).

In this scenario, users who are not registered in the IdP are not able to log in.

Proposed Solution:
Implement User Groups in Atlas with separate configuration settings, so that if 1 group enables Federated Authentication, they will not impact any other groups, even if they all share the same domain name in the user accounts.