Extracted broker auth into new doc #48046
Conversation
Co-authored-by: Genevieve Warren <24882762+gewarren@users.noreply.github.com>
Co-authored-by: Scott Addie <10702007+scottaddie@users.noreply.github.com>
Co-authored-by: Scott Addie <10702007+scottaddie@users.noreply.github.com>
|
|
||
| Consider the following sample code from a Windows Forms app that passes the credential to an instance of [BlobServiceClient](/dotnet/api/azure.storage.blobs.blobserviceclient): | ||
|
|
||
| :::code language="csharp" source="../snippets/authentication/additional-auth/interactive/InteractiveBrokeredAuth.cs" highlight="16-20"::: |
There was a problem hiding this comment.
The placeholder names mentioned in the code comment here need to be updated.
Co-authored-by: Scott Addie <10702007+scottaddie@users.noreply.github.com>
| Brokered authentication collects user credentials using the system authentication broker to authenticate an application with <xref:Azure.Identity.InteractiveBrowserCredential>. A system authentication broker is an app running on a user's machine that manages the authentication handshakes and token maintenance for all connected accounts. | ||
|
|
||
| > [!NOTE] | ||
| > Currently, only the Windows authentication broker, Web Account Manager (WAM), is supported. Users on macOS and Linux will be authenticated through the [non-brokered interactive browser flow](additional-methods.md#interactive-browser-authentication). |
There was a problem hiding this comment.
What is the context for this statement? We do support Mac and Linux for brokered authentication currently - see the changelog here
There was a problem hiding this comment.
Perhaps this note could be improved by mentioning that Windows is supported natively with WAM, while MacOS and Linux require to install other tools like MS Intune.
There was a problem hiding this comment.
Let's remove the note. In step 1 of the "Implement the code" section, we should add a note saying that macOS and Linux support exists in Azure.Identity.Broker versions 1.3.0 and later.
| 1. In **Custom redirect URIs**, enter the following WAM redirect URI: | ||
|
|
||
| ```text | ||
| ms-appx-web://Microsoft.AAD.BrokerPlugin/{client_id} |
There was a problem hiding this comment.
This redirect URI differs by OS: https://github.com/Azure/azure-sdk-for-net/tree/main/sdk/identity/Azure.Identity.Broker#redirect-uris. When you add the OS zone pivot, no need to list WSL. That detail should appear when Linux is selected. Linux broker prereqs are listed at https://learn.microsoft.com/en-us/entra/msal/dotnet/acquiring-tokens/desktop-mobile/linux-dotnet-sdk.
| Brokered authentication collects user credentials using the system authentication broker to authenticate an application with <xref:Azure.Identity.InteractiveBrowserCredential>. A system authentication broker is an app running on a user's machine that manages the authentication handshakes and token maintenance for all connected accounts. | ||
|
|
||
| > [!NOTE] | ||
| > Currently, only the Windows authentication broker, Web Account Manager (WAM), is supported. Users on macOS and Linux will be authenticated through the [non-brokered interactive browser flow](additional-methods.md#interactive-browser-authentication). |
There was a problem hiding this comment.
Let's remove the note. In step 1 of the "Implement the code" section, we should add a note saying that macOS and Linux support exists in Azure.Identity.Broker versions 1.3.0 and later.
| > [!NOTE] | ||
| > For more information about retrieving window handles, see [Parent window handles](/entra/msal/dotnet/acquiring-tokens/desktop-mobile/wam#parent-window-handles) and [Retrieve a window handle](/windows/apps/develop/ui-input/retrieve-hwnd). | ||
|
|
||
| For the code to run successfully, your user account must be assigned an Azure RBAC role on the storage account that allows access to blob containers, such as **Storage Account Data Contributor**. If an app is specified, it must have API permissions set for **user_impersonation Access Azure Storage** (step 6 in the previous section). This API permission allows the app to access Azure storage on behalf of the signed-in user after consent is granted during sign-in. |
There was a problem hiding this comment.
If you decide to stick with Key Vault Secrets in the apps I sent, your user account must be assigned an Azure RBAC role on the Key Vault resource that permits it to read secrets, such as Key Vault Secrets User. To create the secret, role Key Vault Secrets Officer is needed.
I also wonder if this content should move to an "Assign roles" section. After all, it's not something you do in the code.
Summary
Describe your changes here.
Fixes #Issue_Number (if available)
Internal previews