Allow to set teams to users by Federated Authentication
When an Atlas User logs in by a Federated Authentication (like Okta) there is only a "Default User Role" to control its permission, so all users get the same role. And after that, we must manually add to teams, or change their roles. It would be better to allow the IdP to set (and update) the groups/teams for each user automatically.
Do you have a scheduled date. I read that we are announcing for this year and we are in November now?
Ideally, it would be interesting to associate "Atlas" roles with a security group from our AD. Also, for high privileged accounts, we use the "Privileged Identity Management" feature in Azure to elevate our privileges right at the time of action. This prevents our accounts from having administrative privileges at all times. Could you integrate these improvements into the "MongoDB Cloud" connector.
Same Issue here!
Would be nice to have permission assignment via AD-Group membership.
Thanks for implementing!
Not sure if this is part of the scope of this change. But it would be nice to create an Atlas role that is associated to security group of the authenticated user. example if we created an Atlas support team roles and related that to a security group in our domain (group could be passed as an attributes of the Federated Authenication) the they would have the roles without having to be individually created. And we would have an other Atlas Role like Atlas Read-Only and they would have a different set of Atlas permission and it would map to a different security group in our domain.
There are two possible behaviors with the current SAML implementation:
1. Federated Authentication is configured to not map a default role to a new user
2. Federated Authentication is configured to map a default role to a new user
Pain points of #1
- For every new user who sings-in via SAML, an admin has to manually assign him/her a role. Ideally I would the role mapping in the SAML assertion
- This behavior makes the first time login experience bumpy
Pain points of #2
- Any authenticated user in the IdP can login. The default role gets assigned to him/her.
It would be useful to be able to add extra role assertions, and have those role assertions map to the valid MongoDB roles (rather than having a default role).
It would also be useful, if we could add role assertions, that could map to specific project roles also.
If role assignments change (different assertions are received), then the roles a user has should also be updated..
This is planned for later this year