When inviting new Atlas Users to organizations via the API, the invite email says that the invite was sent by the API public key that performed the API call. This makes the invitation emails read like this:

"You have been invited by tfqzvwrs to join the Example - Atlas organization on MongoDB Atlas."

The ability to customize this (e.g. using an additional field in the request body) would be ideal since the random string being shown as the sender of the invite could make the email look suspect.

Hello,

We absolutely need a more modern authentication method than using LDAPS to authenticate users against the MongoDB databases that we deploy with Atlas. When will we see a modern authentication service at this level? Ideally, we want cloud functionality equivalent to AWS IAM but on Azure.

When trying to implement Atlas infrastructure for Organization/Project users, the Teams functionality is useless unless we can add pending users to a Team. Right now, if a new user doesn't login for two weeks, we can't assign them to a Team until two weeks after the implementation was supposed to be configured.

Billing should be limited to organization owners only and not viewable by the entire organization.

I access Mongo Cloud / Atlas very frequently. However, almost every day I need to re-login using my Google account. It doesn't seem to "remember" my session.
I would love if I can extend the default, and let me (and other members) stay logged in for a longer period of time.

Similarly to how database user data access permissions can be configured on a per-database or per-collection basis, it would be ideal if Atlas user data access permissions (as they apply to Data Explorer) could be configured on a more granular basis as well.

Ability to change your username after registration and be able to re-use it should you need to.

We were given this idea from a security audit.

From a security-in-depth perspective we would like to be able to restrict logins on the atlas portal to only whitelisted IP's, this would be analog as to how API whitelisting works at the organization level.
This is to prevent login's other than from our permitted sites.

It would be great to be able to transfer users with their credentials and permissions from our on-premises deployment to Atlas during migration to avoid having to recreate those users using the Atlas interface or API.

Session timeout value in Atlas UI defaults at 12h. Allow it to be configurable per Project or Organization, with the minimum value being 15 minutes. All Atlas users within an organization that have been idle for the duration of the configured session timeout should be automatically logged out.

Please add the capability to enforce 2FA (As a setting) for any user invited to join a team. This would be a good step towards better security management

Currently the list of privileges assignable for Custom Roles is only a subset of privileges available to Built-in Roles This request is to add the missing privileges to both the REST API and Atlas UI which are available to Built-in Roles

The first set of privileges requested by a customer is from the Cluster Monitor role

Expanded prioritized privileges requested:

checkFreeMonitoringStatus
getCmdLineOpts
getLog
getParameter
getShardMap
hostInfo
inprog
listShards
netstat
replSetGetConfig
replSetGetStatus
setFreeMonitoring
shardingState

When we do SOC2 reviews, we have to take screenshots of the permissions various users have. Currently, a specific "team" in Atlas only shows 5 users at a time and is paginated. Taking screenshots of 5 users at a time is pretty tedious, so it would be amazing to have a page with the full list.

It would be incredibly helpful to have some sort of capability that allows users within the Atlas portal to be able to see what privileges are needed to perform various actions. For example, we have users that are not able to configure alerts, or other users that are not able to add users to a project. It isn't always clear what privileges are needed in order to give users those capabilities. Either some sort of tool would be helpful, or very clear documentation on privileges that are needed for each capability within Atlas.

Please consider adding 2FA support for hardware keys (Yubikey). Our company started enforcing this in our compliance policy for accessing production environments.

It would be great to add more granularity when creating an Atlas-managed X.509 certificate for a MongoDB user, i mean by day at least.
Thank you

It would be good if users are able to modify their First and Last Name after account creation.

1)User A login inot Mongo Portal
2) He selects an organization and sends an invitation to User B
3) Now in the Activity Feed menu we can see User B was invited to the organization
4)Before the user B accepts the invitation , User A goes and deletes the pending invitation
5)Nothing is shown in activity feed.

This would help products which are integrating with MongoDB atlas to get the true status of pending invitations.

Based on the documentation it appears there is no option available to disable automatic account creation when Federated Authentication is used.

The business case for disabling automatic account creation is to allow a limited set of users from the Identity Provider to have access to Atlas and the databases, while not allowing anyone with an account in the same domain to create an Atlas/Database account.