External Kernel Providers - Using vscode-mssql as a Connection Manager/Kernel Proxy

[cjohnsto-nz]

I have a lot of interest in improving the Polyglot experience for ADS refugees.
I know a lot of analysts that feel dismissed by the push to use Polyglot in its current state as a replacement for ADS. Polyglot and vscode is far more technical and developer centric than ADS ever was.

The solutions provided by the team to do things like managing passwords for connection strings turn off a lot of people, and encourage risky behaviour like saving connection strings in your notebooks.

I have been exploring using the mssql extension as a connection manager/kernel provider for Polyglot.

I explored a few options.
There is already a connection sharing API in mssql-vscode, but it is a bit limited.
It supports connecting to a saved connection profile, and executing a basic query.
It can provide connection string details, but with passwords removed.

Connecting to an mssql server from a Polyglot notebook often requires as many as 4 separate browser authentication events every time the notebook is opened, if you are using Azure MFA auth.

I created a fork of mssql that exposes passwords and access tokens via the connection sharing API, and allows you to designate a primary connection profile per notebook. The UX here is fantastic, but there are clear security concerns around exposing these methods in the mssql extension that could leak sensitive data if a user granted permission to a malicious extension.

I am now exploring modifying the mssql extension to act as a kernel provider, and exposing connection profiles as virtual/proxy kernels. This way, vscode-mssql can keep it's secrets, keep managing silent auth and cached tokens.

This will mean adding support for execution, intellisense, discovery, and anything else I find along the way. For Polyglot, this will likely mean detecting the presence of the mssql extension, and doing virtual kernel discovery.

I was wondering if there are any existing patterns for this. Any other pathways I should consider?
My primary objective here is to have polyglot use configured mssql profiles without having to constantly reauthenticate, and to maintain security of saved credentials and secrets.
I have many team members that need an acceptable SQL notebook experience before ADS is retired, so I would love to have a discussion on what the best path forward for me to contribute a solution here would be that is likely to get merged.