Research: Effort required to implement SAML authentication into unboxing flow

[lukeheath]

Tasks

• Research the level of effort to implement the specs in #10689
• Time box to two hours.
• Determine point estimate for the entire story as spec'd.

Research

https://user-images.githubusercontent.com/4419992/227311113-fb9b3c87-d32f-4d87-a10c-61da6028a634.mov

Note: I had to write some code to validate if the ideas we had actually worked in practice or not, draft PR: https://github.com/fleetdm/fleet/pull/10722/files#

Back-end

Note: other solutions use OpenID Connect instead of SAML to manage this, both fulfill similar needs, but via different mediums. This describes how to integrate SAML because that was the ask of the task and it would certainly be lower effort given some of the logic we already have in place.

• We can leverage a good chunk of our existing SAML logic:
  • Everything related to initiating the SSO flow (POST /api/v1/fleet/sso) can be reused, but we need a different endpoint that handles DEP-specific authentication (ie: we can't just reuse that endpoint)
  • The callback portion of the flow (POST /api/v1/fleet/sso/callback) is a bit different but it only needs to:
    • Validate that the response from the IdP is valid
    • Serve HTML that redirects to an URL where the profile can be downloaded, or if an EULA is present, show the EULA and include the URL to download the configuration profile as a query parameter. For the PoC, the profile is gated behind a token, we need to evaluate if this is enough, otherwise we'll have to set a cookie or explore the possibility of responding with an enrollment profile directly in the SSO callback (cc: @lukeheath)
• Configuration (cc: @noahtalerman)
  • We could reuse the SSO configuration that's set in /settings/organization/sso, but we need to double check with IT admins first if this is okay. It would mean that:
    1. They have allow people to use the same SSO entity (eg: Okta App) for both Fleet logins and DEP.
    2. They have to add an extra ACS URL to in their IdP, for example in Okta it looks like this:
  • Alternatively, provide another set of configs, exactly the same as the ones in /settings/organization/sso (identity provider name, entity ID, issuer URI, metadata URL)
  • We want this option. More context here (noahtalerman)
• Account creation
  • For password enforcement, we need to deliver a profile before releasing the device, requires https://github.com/fleetdm/fleet/issues/10577
  • To pre-populate the username, when we get the SAML response from the device, send an AccountConfiguration like we did in #10210 using the email we get from the SAML response. Similarly to that issue too, we probably need to use mdm_idp_accounts to keep a reference of the host being authenticated.

Front-end

• We need a new page to handle the SSO login transactions, this page is almost invisible to the user except:
  • While we do the first request to the Fleet server, we need a loading state here (purple screen around 0:30 in the video)
  • When the "initiate SSO" request is completed, we need to redirect the user to the IdP
  • If there's an error initiating SSO, or during the SSO callback, we need to be prepared to display an error in this page
  • A prototype of this component without error handling can be found here.
• We need another page (or the same, using different query params) to show the EULA, this page:
  • Receives an URL to redirect the user when the EULA is accepted
  • Shows the EULA and redirect the user to the provided URL when accepted

[lukeheath]

@roperzh I created this research ticket to investigate the effort required to implement SAML authentication into our MDM unboxing flow.

Please let me know if me or anyone else on the team can provide support.

[roperzh]

@lukeheath done, reassigning back to you.

[noahtalerman]

We could reuse the SSO configuration that's set in /settings/organization/sso... Alternatively, provide another set of configs, exactly the same as the ones in /settings/organization/sso...

@roperzh hmm, I think from a UX perspective we want to provide another set of configs. Maybe in some future iteration we'd add UX around using the same values from the existing SSO configuration. Something like a "Use the same SSO you use to log in to Fleet" button.

Roberto, did you get the chance to look into level of effort for these requirements (from #10689)?

• [ ] End user must agree to end user license agreement (EULA) to continue to next step in set up flow
• [ ] During local account creation step in set up flow, the username is set to the end user's username from the IdP
• [ ] During local account creation step in set up flow, the password field requires the password requirements set by a configuration profile (if there is one)

[roperzh]

@noahtalerman sounds good, and thanks for the heads up. I'll update the issue with that.

[roperzh]

@lukeheath @noahtalerman I updated the issue, the only one that I haven't research (apologies) is:

During local account creation step in set up flow, the password field requires the password requirements set by a configuration profile (if there is one)

we can send a profile, but I don't know if it will enforce the settings when the account is created. I'll have to give that a try.

[roperzh]

@lukeheath @noahtalerman sorry for the back-and-forth. I did a (hopefully) final edit to include the items related to the account creation.

[noahtalerman]

@lukeheath @roperzh closing this issue because the research is done.

[fleet-release]

Unboxing flows ease, SAML authentication, Sky-cities merge paths.