Team admins can't set MFA or SSO when managing team users in the UI

[iansltx]

Fleet version: 4.61.0 for MFA, much earlier for SSO

---

💥  Actual behavior

MFA and SSO checkboxes are limited to global admins in the UI even though team admins have permissions in the API to revise both of them for existing users, or create users with either of them.

🧑‍💻  Steps to reproduce

1. Create a team.
2. Create an admin for that team.
3. Log in as the team admin.
4. Go to team settings and click Create user

🕯️ More info

The likely reason the SSO settings isn't visible is we currently hide all SMTP and SSO settings from team admins (#11266, #12180). MFA ran into the same issue (#24623). So we'll need to make "is this enabled" global conflg flags visible for both SSO and SMTP for team admins in order to get this to work, without spilling additional config information. @jacobshandling has started work on this in #24632.

🛠️ To fix

• On backend

  • expose in the API whether
    • SSO and
    • SMTP are configured (and only those flags) for team admins.
  • update tests

• On frontend, drop the "global admin only" guards for both

  • [ ] SSO (tbc, don't think this is there in the first place) not gated by UI, with new fields from API response works as desired
  • and MFA selection,
  • and handle any tweaks to password field show/hide as part of this.
  • confirm UI handles all expected interface changes implemented here

[rachaelshaw]

@iansltx I think we can keep the tooltip the same for team admins; there's precedent for saying "_____ can be updated in org settings" even when the user doesn't have permission (the thinking being that they can point an admin toward the setting that needs to be changed)

[iansltx]

Cool. For posterity, here's what I'm removing from the ticket description in To Fix:

---

Also on frontend, team admins need different disabled-input messages for the global email flag since team admins can't actually fix the problem. SSO is covered with sufficiently versatile copy.

Second paragraph of the MFA tooltip for global admins is currently:

SMTP can be configured in Settings > Organization settings.

Team admins can probably be:

SMTP can be configured by a global administrator.

---

Tagged with product to confirm desired copy, after which this can be actioned.

[jacobshandling]

drop the "global admin only" guards for both SSO and MFA selection

@iansltx, are you sure SSO selection is being gated by this?

[iansltx]

@jacobshandling SSO settings are gated to global admins, and SSO can be toggled in the API by team admins.

[iansltx]

...and yeah, SSO doesn't show up in the UI for team admins editing users right now, per recent testing.

[lukeheath]

@jacobshandling @iansltx @sharon-fdm Triaging this as an unreleased bug.

[sharon-fdm]

Thanks @lukeheath.

[jacobshandling]

@rachaelshaw @noahtalerman due to some complexity that wasn't immediately obvious going into this, I met with @lucasmrod to brainstorm a few possible approaches and associated risks/tradeoffs. We slightly prefer option 2 or even 1 for its simplicity, but all of these are doable, though 5 is probably unnecessarily messy. What do you think?

Option 1

Remove dependence of the UI on these fields and always have these options enabled. If SSO and/or SMTP needs to be configured, the user is told this via an informative error flash message.
- pros: Simplest solution, requires no API updates, can be completed easily and quickly
- cons: Slightly less smooth UX, having to wait for the error message instead of seeing the option(s) disabled to begin with

Option 2

Selectively include fields as described in this ticket. Because of implementation details, this would also mean excluding the other SSO and SMTP-related unset/empty fields from the API response for global admins as well. That is, where a global admin currently sees:

  "smtp_settings": {
    "enable_smtp": false,
    "configured": false,
    "sender_address": "",
    "server": "",
    "port": 0,
    "authentication_type": "authtype_none",
    "user_name": "",
    "password": "",
    "enable_ssl_tls": false,
    "authentication_method": "authmethod_plain",
    "domain": "",
    "verify_ssl_certs": true,
    "enable_start_tls": true
  }

and

  "sso_settings": {
    "entity_id": "",
    "issuer_uri": "",
    "metadata": "",
    "metadata_url": "",
    "idp_name": "",
    "idp_image_url": "",
    "enable_sso": false,
    "enable_sso_idp_login": false,
    "enable_jit_provisioning": false,
    "enable_jit_role_sync": false
  }

they would now see:

  "smtp_settings": {
    "enable_smtp": false,
    "configured": false,
    "authentication_type": "authtype_none",
    "authentication_method": "authmethod_plain",
    "verify_ssl_certs": true,
    "enable_start_tls": true
  }

and

  "sso_settings": {
    "enable_sso": false,
  }

pros:
- provides smooth UX - options are disabled if the team admin can't perform them (sso/smtp not configured)
- arguably cleaner (values are just omited when they are not set, instead of returned with "" etc.)
cons:
- could be considered breaking the API, in a sense, since we are technically removing fields

Options 3 and 4

Add new fields for indicating smtp enabled, smtp configured, and sso enabled, in either (option 3) the current config response or (option 4) a new dedicated team admin config endpoint.
- pros:
- only adding to current response or to new endpoint, so in no sense breaking the API
- simplifies test updates (especially option 4), decreasing required capacity invested here and increasing dev speed
- cons:
- slightly redundant to include same data in multiple places

Option 5

Include empty fields in config response for team-level admins for all fields, even if they are actually set, except desired enabled/configured fields. So instead of giving a team-level admin this (original spec here):

  "smtp_settings": {
    "enable_smtp": false,
    "configured": false,
  }

and

  "sso_settings": {
    "enable_sso": false,
  }

, they would get something close to:

  "smtp_settings": {
    "enable_smtp": false,
    "configured": false,
    "sender_address": "",
    "server": "",
    "port": 0,
    "authentication_type": "",
    "user_name": "",
    "password": "",
    "enable_ssl_tls": false,
    "authentication_method": "",
    "domain": "",
    "verify_ssl_certs": false,
    "enable_start_tls": false,
  }

and

  "sso_settings": {
    "enable_sso": false,
    "entity_id": "",
    "issuer_uri": "",
    "metadata": "",
    "metadata_url": "",
    "idp_name": "",
    "idp_image_url": "",
    "enable_sso_idp_login": false,
    "enable_jit_provisioning": false,
    "enable_jit_role_sync": false
  }

[jacobshandling]

^ cc @sharon-fdm

[noahtalerman]

@jacobshandling when chatting about this issue we ran into these two other bugs:

• Frontend validation issues when editing the SMTP settings. User can save without editing other fields.
• "NOT CONFIGURED" copy shows up when SMTP isn't configured. I think we want to remove this.

Tracked in #25009

[noahtalerman]

@lucasmrod, @jacobshandling and I chatted about the options above. I think that the best choice is to allow team admins to read SSO and SMTP settings like we allow global teams today:

That way, the Edit user modal for team admins and global admins can show the SSO and MFA options as disabled. This is the best UX.

Jacob and I don't know of a strong reason for not allowing team admins to view these settings. We tried to look back in GitHub history and found this. Even at the time it sounds like we didn't know of a good reason.

What we've learned is that users are accepting of permissions changes when they're clearly documented.

Please let us know if you think that's the wrong call.

[lucasmrod]

IIRC the reason was so that team admins did not have access to global settings like SMTP passwords or SSO credentials (you probably want only global admins to be able to access such a thing).

PS: This is following the Principle of least privilege. Do team admins need access to global SMTP passwords or SSO credentials?

[jacobshandling]

We are going to wait until Noah gets back from vacation to confirm he is okay with above security/access concerns raised by @lucasmrod before implementing, which pushes this ticket to the next release cc @sharon-fdm