Running inside WSL2 with saml_provider = browser can't launch browser

[stoopkidddd]

When running inside WSL2 with saml_provider = browser, aws-runas fails to launch any browser, regardless if you pick chrome or msedge.

I think what needs to happen here is that an option for wslview needs to be added from the wslu package.

Or maybe if no auth_browser is provided, or it is set to "default" it could just use the $BROWSER environment variable?

Debug log with -v flag just hangs here:

2023/02/11 09:25:37 DEBUG configuring SAML client
2023/02/11 09:25:37 DEBUG no jump role found, only configuring SAML client
2023/02/11 09:25:37 DEBUG Detected expired or unset saml role credentials, refreshing
2023/02/11 09:25:37 DEBUG Starting a browser to authenticate..
2023/02/11 09:25:37 DEBUG Browser specified from config [ msedge ] (Chrome is default)

[stoopkidddd]

The code in question that has the bug is roughly here:

aws-runas/client/external/browser_client.go

Lines 74 to 128 in cd5313f

	dir += `/.aws/.browser`
	// Remove the default option for headless
	opts := chromedp.DefaultExecAllocatorOptions[0:1]
	c.Logger.Debugf("Browser specified from config [ %s ] (Chrome is default)", c.AuthBrowser)
	switch c.AuthBrowser {
	case "msedge":
	if runtime.GOOS == `windows` {
	browserExec = WinOSEdge
	} else {
	browserExec = MacOSEdge
	}
	opts = append(opts,
	chromedp.ExecPath(browserExec),
	)
	case `chrome`:
	// Chrome is the effective default
	case ``:
	// Unspecified invokes the default of Chrome
	default:
	// Should never get here with validation on the config
	c.Logger.Infof("browser %s not supported using chrome if available.", c.AuthBrowser)
	}
	opts = append(opts,
	chromedp.UserDataDir(dir),
	chromedp.Flag(`profile-directory`, `aws-runas`),
	chromedp.WindowSize(400, 700),
	chromedp.NoDefaultBrowserCheck,
	)
	allocCtx, cancel := chromedp.NewExecAllocator(context.Background(), opts...)
	defer cancel()
	// also set up a custom error logger
	taskCtx, cancel := chromedp.NewContext(allocCtx, chromedp.WithLogf(c.Logger.Errorf))
	defer cancel()
	// Waitgroup to wait on the browser SAMLResponse
	done.Add(1)
	// Setup a listener to be called for each browser event in a separate go routine
	chromedp.ListenTarget(taskCtx, c.targetListener)
	// ensure that the browser process is started and navigate to auth page
	if err = chromedp.Run(taskCtx,
	chromedp.Navigate(c.authUrl.String()),
	); err != nil {
	done.Done()
	_ = chromedp.Cancel(taskCtx)
	return err
	}
	// Wait for SAMLResponse from Browser
	done.Wait()
	_ = chromedp.Cancel(taskCtx)
	c.Logger.Debugf("Authentication Finished.")
	return nil

[mmmorris1975]

Part of the functionality of this provider is intercepting the request chain which is happening in the browser between the IdP and AWS in order to get the SAML response that aws-runas needs to store to be able to fetch STS credential from AWS. This is accomplished by that chromedp library, which can hook in to Chrome-based browsers to get that info.

The layer of abstraction from WSL means that getting back to an OS-layer browser will be tricky. (Tricky for me at least, I don't use Windows, hence have no way to see how WSL could handle this). The wslview utility won't be much help here, since I don't think we can use that to launch a browser and still be able to get into its guts to intercept the request chain processing.

The $BROWSER usage is intriguing. Is that something intrinsic to WSL, or would someone need to set that ahead of time to point to an executable? Could probably add some logic around line 93 of that snippet and call chromedp.ExecPath(), like with the msedge case, and set the argument to the value for the env var (if it's found)