Support for User Groups with Separate Authentication Configurations
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.
-
Michael Gerlach commented
This is also crucial for **break-glass access** when using e.g. Okta for Identity Federation.
Our DRPs forsee emergency access in an incident scenario of the Identity Provider. -
Matthias commented
Feature is needed for our company which is having several divisions and more than 10.000+ employees.
-
Stefan commented
Same issue here. With big companies (like ours) having several divisions, where each division is handling the Mongo projects separately, but sharing the same domain name it's very important to have this feature work correctly.
-
Matt commented
We really need this feature - without it, we cannot manage our 100 Atlas users with Okta - they all have to have named accounts. It is a huge pain. Thanks.
-
Kyle commented
We would like this feature as well, if not just for a "backdoor" user to be able to use Atlas auth in case SSO is broken.
-
Stewart commented
I ran into the same issue. Ideally there'd be an option where the Atlas login page doesn't forward users with emails in my domain to my IdP, but I can still log in using my IdP's Login URL.