Skip to content

Support Microsoft SAML attribute names by default redux

Drew Blessing requested to merge dblessing_support_ms_attributes_take2 into master

What does this MR do and why?

Related to #420766 (closed). Support Microsoft SAML attribute names by default (!135770 - merged) redux.

Support Microsoft SAML attribute names by default

Add default attribute_statements to support Microsoft SAML attribute format. Microsoft uses a URL format by default. Prior to this change self-managed instances had to manually configure attribute statements and SaaS users had to add custom attributes to their SAML responses. This makes both self-managed and SaaS work out of the box with Microsoft.

Prior to this change we were merging defaults on top of user configuration. Now we need to make sure we merge user configuration on top of defaults so user configuration takes precedence. In the past this likely wasn't a big issue because defaults contained lower level configuration that GitLab needed to work properly with a given provider. But with the addition of SAML defaults, there's a strong likelihood users will override this configuration, and their configuration should take precedence.

For self-managed, if something goes wrong they can revert to the previous method of merging defaults on top of user configuration by setting the ENV variable REVERT_OMNIAUTH_DEFAULT_MERGING to 'true' or '1'. In either case the new default attributes will be used.

If problems arise due to the new defaults themselves, self-managed instances will need to override attribute_statements in gitlab.yml or gitlab.rb to set specific name, email, first_name and last_name. The ENV variable must be unset or set to 'false' or '0' for the user settings to take precedence rather than defaults.

For SaaS, we can manage the behavior through the saml_microsoft_attribute_names feature flag, which is also scoped by group.

In addition to the docs updates in this MR, @jglassman has removed some relevant notes in !136449 (closed)

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Drew Blessing

Merge request reports