Enable SSO capabilities with the Windows signed in user while on Dev Box

[rub8n]

As part of broad push towards optimizing the developer experience for the new Microsoft Dev Box service, we'd like to make sure the Azure Dev Ops (ADO) identity experience for GCM is optimal while on Dev Box. From that standpoint, we'd like to work with you to minimize ADO sign in prompts by potentially enabling SSO capabilities with the Windows signed in user while on Dev Box.

For example, today whenever a user attempts to clone an ADO repo from the Visual Studio (VS) UI, GCM prompts for credentials for each and every repo regardless of the identities available on the VS keychain or even selected from the clone's dialog account picker.

While the VS team already has feedback about the overall UX model, right now we'd like to primarily focus on the Dev Box experience as that scenario has potentially overall less friction and could be streamlined based on the signed in Windows account via the WAM capabilities currently available for GCM.

Happy to share more context as needed and/or schedule a meeting to discuss further.

[vtbassmatt]

Sounds interesting, thanks for raising it!

Git is unfortunately a resource-based system, not an identity-based one, which helps explain why (in normal scenarios) the user always gets prompted. We have no way of knowing what credentials are going to work against a given repo, and we don't get multiple shots at it without user intervention.

However, in a constrained scenario like Dev Box, it definitely seems like we could do better. You mention WAM – we have experimental support already in GCM for WAM integration. It has some rough edges in general use but may be enough here. Have you given that a try?

[rub8n]

WAM is part of the story but doesn't get us all the way there, as it would just replace the existing prompt with a new one (WAM).

The idea would be to leverage WAM to enable SSO with the Windows signed in user. That way, rather than always default to prompting, we can validate the signed in user creds are enough to interact with ADO repos before resorting to prompting for a different set of credentials.

[mjcheetham]

[..] validate the signed in user creds are enough to interact with ADO repos [..]

Herein lies the difficult part. I'm not sure there's a way for us to test if a user accounts' token is either allowed to perform "the operation" Git is about to do, or has tried to do.

Git doesn't tell us what is happening, beyond "we need a credential for <hostname>". If we pick the wrong user account, then we are stuck somewhat. Git doesn't give us the opportunity to retry.

To make matters worse, we are only told the previously supplied credentials were bad as a separate process invocation, meaning we have lost any context built in the initial request to record "don't pick that account again".

The other problem is that the user may indeed have multiple accounts that are allowed to perform the operation on the remote repository (clone/fetch, push) but the one we select is the "wrong" one. We have had customers who's Windows user account is not the same one they are required to use to push changes to the repository.

There are some changes that I've proposed to the Git project to help us move in a direction where this sort of automatic account selection would be more feasible, starting with getting Git to pass authentication challenge headers to credential helpers. This would allow us to know at least the correct authority, and potentially any OAuth scope requirements:

https://lore.kernel.org/git/pull.1352.v2.git.1666372083.gitgitgadget@gmail.com/

Another change (not yet designed or planned) that may help would be to teach Git that credential helpers have the ability to retry a credential request. This change would require more careful thought than the above authentication header changes.

Now... that's not to say there isn't something we can do to prevent a prompt.

[..] or even selected from the clone's dialog account picker.

GCM today will attempt to silently use an account if it's told about one externally!

You can include the AAD/MSA user in the remote URL, or set some Git configuration to "bind" or "assign" a particular UPN to a remote URL or Azure DevOps org:

https://github.com/GitCredentialManager/git-credential-manager/blob/main/docs/azrepos-users-and-tokens.md#user-accounts

If VS wanted to provide a UPN as context to us during a git clone invoked from inside of VS, you can do that today:

git clone https://<UPN>@dev.azure.com/<org>/<project>/_git/<repo>

For example, to tell GCM to try and use alice@example.com silently:

git clone https://alice%40example.com@dev.azure.com/<org>/<project>/_git/<repo>