Webes API-kat hívó asztali alkalmazás: Jogkivonat beszerzése integrált Windows-hitelesítéssel

Ha tartományi felhasználót szeretne bejelentkezni egy tartományba vagy a Microsoft Entra-hoz csatlakoztatott gépen, használja az integrált Windows-hitelesítést (IWA).

Megszorítások

  • Az integrált Windows-hitelesítés csak összevont felhasználók számára érhető el, azaz az Active Directoryban létrehozott és a Microsoft Entra ID által támogatott felhasználók számára. Ezt a hitelesítési folyamatot nem használhatják azok a felhasználók, amelyeket közvetlenül a Microsoft Entra ID-ban hoztak létre Active Directory-háttérrendszer nélkül, más néven felügyelt felhasználók. Ez a korlátozás nem befolyásolja a felhasználónév és a jelszó áramlását.

  • Az IWA nem kerüli meg a többtényezős hitelesítést (MFA). Ha az MFA konfigurálva van, az IWA meghiúsulhat, ha MFA-feladatra van szükség, mert az MFA felhasználói beavatkozást igényel.

    Az IWA nem interaktív, de az MFA felhasználói interaktivitást igényel. Nem szabályozhatja, hogy az identitásszolgáltató mikor kéri az MFA végrehajtását, a bérlői rendszergazda igen. Megfigyeléseink szerint az MFA-ra akkor van szükség, ha egy másik országból/régióból jelentkezik be, amikor nem vpn-en keresztül csatlakozik egy vállalati hálózathoz, és néha még akkor is, ha VPN-en keresztül csatlakozik. Ne várjon determinisztikus szabálykészletet. A Microsoft Entra ID AI használatával folyamatosan tanulja meg, hogy szükség van-e MFA-ra. Ha az IWA meghiúsul, térjen vissza egy felhasználói kéréshez, például az interaktív hitelesítéshez vagy az eszköz kódfolyamatához.

  • Az átadott PublicClientApplicationBuilder hatóságnak a következőnek kell lennie:

    • Az űrlap https://login.microsoftonline.com/{tenant}/bérlője, ahol tenant a bérlőazonosítót vagy a bérlőhöz társított tartományt képviselő GUID azonosító található.
    • Minden munkahelyi és iskolai fiók esetén: https://login.microsoftonline.com/organizations/.
    • A Microsoft személyes fiókjai nem támogatottak. A /common vagy /consumers bérlők nem használhatók.
  • Mivel az integrált Windows-hitelesítés csendes folyamat:

    • Az alkalmazás felhasználójának korábban hozzá kell adnia az alkalmazás használatához.
    • Vagy a bérlői rendszergazdának korábban hozzá kell adnia, hogy a bérlő összes felhasználója használja az alkalmazást.
    • Más szóval:
      • Ön fejlesztőként az Azure PortalOn kiválasztotta a Grant gombot.
      • Vagy egy bérlői rendszergazda az alkalmazás regisztrációjának API-engedélyek lapján kiválasztotta a(z) {tenant domain}rendszergazdai hozzájárulásának megadását/visszavonását. További információ: Engedélyek hozzáadása a webes API eléréséhez.
      • Vagy megadta a módját, hogy a felhasználók hozzájáruljanak az alkalmazáshoz. További információ: Egyéni felhasználói hozzájárulás kérése.
      • Vagy megadta a bérlői rendszergazda számára, hogy hozzájáruljon az alkalmazáshoz. További információ: Rendszergazda hozzájárulás.
  • Ez a folyamat engedélyezve van a .NET asztali, .NET- és UWP-alkalmazásokhoz.

A hozzájárulással kapcsolatos további információkért lásd az Microsoft Identitásplatform engedélyeket és hozzájárulásokat.

Ismerje meg, hogyan használhatja

A MSAL.NET használja a következőt:

AcquireTokenByIntegratedWindowsAuth(IEnumerable<string> scopes)

Általában csak egy paraméterre (scopes) van szükség. Attól függően, hogy a Windows-rendszergazda hogyan állította be a szabályzatokat, előfordulhat, hogy a Windows-gépen lévő alkalmazások nem kereshetik meg a bejelentkezett felhasználót. Ebben az esetben használjon egy második metódust, .WithUsername()és adja meg a bejelentkezett felhasználó felhasználónevét UPN formátumban, például joe@contoso.com.

Az alábbi minta a legfrissebb esetet mutatja be, a lehetséges kivételek típusának és azok kockázatcsökkentéseinek magyarázatával.

static async Task GetATokenForGraph()
{
 string authority = "https://login.microsoftonline.com/contoso.com";
 string[] scopes = new string[] { "user.read" };
 IPublicClientApplication app = PublicClientApplicationBuilder
      .Create(clientId)
      .WithAuthority(authority)
      .Build();

 var accounts = await app.GetAccountsAsync();

 AuthenticationResult result = null;
 if (accounts.Any())
 {
  result = await app.AcquireTokenSilent(scopes, accounts.FirstOrDefault())
      .ExecuteAsync();
 }
 else
 {
  try
  {
   result = await app.AcquireTokenByIntegratedWindowsAuth(scopes)
      .ExecuteAsync(CancellationToken.None);
  }
  catch (MsalUiRequiredException ex)
  {
   // MsalUiRequiredException: AADSTS65001: The user or administrator has not consented to use the application
   // with ID '{appId}' named '{appName}'.Send an interactive authorization request for this user and resource.

   // you need to get user consent first. This can be done, if you are not using .NET (which does not have any Web UI)
   // by doing (once only) an AcquireToken interactive.

   // If you are using .NET or don't want to do an AcquireTokenInteractive, you might want to suggest the user to navigate
   // to a URL to consent: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={clientId}&response_type=code&scope=user.read

   // AADSTS50079: The user is required to use multi-factor authentication.
   // There is no mitigation - if MFA is configured for your tenant and AAD decides to enforce it,
   // you need to fallback to an interactive flows such as AcquireTokenInteractive or AcquireTokenByDeviceCode
   }
   catch (MsalServiceException ex)
   {
    // Kind of errors you could have (in ex.Message)

    // MsalServiceException: AADSTS90010: The grant type is not supported over the /common or /consumers endpoints. Please use the /organizations or tenant-specific endpoint.
    // you used common.
    // Mitigation: as explained in the message from Azure AD, the authority needs to be tenanted or otherwise organizations

    // MsalServiceException: AADSTS70002: The request body must contain the following parameter: 'client_secret or client_assertion'.
    // Explanation: this can happen if your application was not registered as a public client application in Azure AD
    // Mitigation: in the Azure portal, edit the manifest for your application and set the `allowPublicClient` to `true`
   }
   catch (MsalClientException ex)
   {
      // Error Code: unknown_user Message: Could not identify logged in user
      // Explanation: the library was unable to query the current Windows logged-in user or this user is not AD or AAD
      // joined (work-place joined users are not supported).

      // Mitigation 1: on UWP, check that the application has the following capabilities: Enterprise Authentication,
      // Private Networks (Client and Server), User Account Information

      // Mitigation 2: Implement your own logic to fetch the username (e.g. john@contoso.com) and use the
      // AcquireTokenByIntegratedWindowsAuth form that takes in the username

      // Error Code: integrated_windows_auth_not_supported_managed_user
      // Explanation: This method relies on a protocol exposed by Active Directory (AD). If a user was created in Azure
      // Active Directory without AD backing ("managed" user), this method will fail. Users created in AD and backed by
      // AAD ("federated" users) can benefit from this non-interactive method of authentication.
      // Mitigation: Use interactive authentication
   }
 }

 Console.WriteLine(result.Account.Username);
}

A AcquireTokenByIntegratedWindowsAuthentication lehetséges módosítóinak listáját lásd: AcquireTokenByIntegratedWindowsAuthParameterBuilder.

Következő lépések

Lépjen tovább a következő cikkre ebben a forgatókönyvben: Webes API meghívása az asztali alkalmazásból.