Feature Idea: SAML SSO Enhancements

The SAML SSO implementation in New Relic is very basic. Yes it allows my users to use their same password as they do for their corporate accounts, however, when I go to the initial New Relic URI it prompts me for userid/password, then takes me to my corporate signin page where I enter the same details again (SSO this isn’t!).
It doesn’t support groups, so I still need to manually add all users to New Relic in the correct group, and doesn’t support auto-enrollment of new users so I can’t add a user to my corporate Active Directory and have New Relic automatically create this user, most SSO implementations allow this.

Are there any plans to enhance the SSO capability, the current implementation is (almost) not worth the effort implementing1

New Relic edit

We take feature ideas seriously and our product managers review every one when plotting their roadmaps. However, there is no guarantee this feature will be implemented. This post ensures the idea is put on the table and discussed though. So please vote and share your extra details with our team.

Hi again @carl.dunk! Keep the ideas coming—you have provided us with excellent feedback here.

I can’t speak much about the specific plans for improving SSO, however, I can bring your use cases to our Product Management team for review.

I have added a poll so the rest of the community can jump in as well. Thanks!

Bumping this up, as this is also exactly what I would want. I think the term is LDAP integration; having users being able to sign into New Relic using corporate domain credentials is nice, and an important first step, but in order for this tool to become enterprise- and culture-wide, the administration of users (adding, putting into the right groups, deleting) needs to not be manual inside of New Relic itself. Our internal operations engineers should be creating groups in our corporate Active Directory (eg, New Relic Users, New Relic Owners, etc) and adding users to that, and then that same access level being honored inside NR itself when users sign on. This is especially true for high-turnover areas such as customer service, etc. Please reach out to me if you need any more info for a use-case. Thanks.

Hey @Stephen.Savitski - Thanks for adding your feedback here. I have passed that on to the product teams.

Note that updates to our authentication methods are currently on the radar of our product teams. This is all part of our plans to continuously improve our Roles Based Access Control (RBAC) implementation. While I can’t speak to specifics, or a timeline, getting your feedback in will definitely get it in front of the right people.

To make this worth the effort I’d at least need SSO to sync AD groups that can be bound to a default base role and whatever combination of add-on roles are needed (bonus points for enabling these groups that are syncing to the root account the ability to also allow or deny sub accounts granularly), making the management just an automated onboarding task i can maintain in my own infra. The current need to follow up with employees accounts after they attempt to log in in order to adjust permissions isn’t scalable or reasonable imo.

Thanks for jumping in here with you ruse case, @bciaraldi! I will pass your specific use case along—be sure to also vote!