Tag Archives: Azure AD

Blazor WASM: Unsupported connection to AAD using the standard auth-library (Microsoft.AspNetCore.Components.WebAssembly.Authentication)

Leave a reply

If you (like me) were hoping to “easily” create a Blazor application that connects to a generic OIDC identity-provider using the Microsoft.AspNetCore.Components.WebAssembly.Authentication library, while also supporting connections to Azure Active Directory (AAD) this way, you’ll be disappointed.

The idea is simple, AAD does support OIDC and therefore now why shouldn’t a generic OIDC client be able to connect to AAD as well. Unfortunately the hurdles are more than you would like to overcome.

While the Microsoft.Authentication.WebAssembly.Msal library for AAD is an extension of the underlying Microsoft.AspNetCore.Components.WebAssembly.Authentication library, it does a lot more than just boilerplate configuration of the underlying generic OIDC.

The basic difference can be found, for example, in the “interop” part with the underlying oidc-client JavaScript module.

  • AuthenticationService.ts in Microsoft.AspNetCore.Components.WebAssembly.Authentication,
  • AuthenticationService.ts in Microsoft.Authentication.WebAssembly.Msal.
    This is manifested for example when retrieving access-tokens. The MSAL version “fixes” the AAD specificity that when querying a token endpoint does not always return an access-token with all required scopes (the details are for a broader discussion, but e.g. you don’t get a token that has User.Read scope in it along with the custom-scope of your API, etc.).

The base library uses the “caching” of tokens in the oidc-client UserManager and relies on the assumption “If token-endpoint returned an access-token, then that token has all the required scopes in it.” (i.e., it stores the required scopes for the retrieved token, and then returns the already retrieved token the next time the same scopes are requested).

The “fixed” MSAL library knows this shortcoming of the underlying oidc-client and knows that while it claims to have a token for some set of scopes, the access-token may not actually have those scopes. Therefore, it “turns off” caching at this level and always gets the token again.

Managing your Microsoft Account-owned Azure Subscription with your Organizational Account (AAD)

1 Reply

There might be a situation where

  • you have an existing Azure Subscription associated with your Microsoft Account,
  • you want to manage the subscription using your Organizational Account(s) (Azure AD),
  • you don’t want to or cannot transfer the ownership of the subscription to the Organizational Account – e.g. it is a sponsored subscription where the sponsorship is related to a specific Microsoft Account (Microsoft Partner Network, MSDN Subscription, MVP Sponsorship, etc.).

The trick here is to change the directory of the subscription to your Azure AD directory. Changing the subscription directory is a service-level operation. It doesn’t affect your subscription billing ownership, and the Account Admin still remains the original Microsoft Account.

There are only a few simple steps to follow:

1. Invite the Microsoft Account to your Azure AD as a guest user

To be able to change the directory, your Microsoft Account owning the subscription must exist in the target Azure AD. To associate the MSA with the AAD:

  • Login to Azure Portal as the Azure AD administrator of the target AAD.
  • Open the Azure Active Directory blade.
  • Go to the Users section.
  • Click the + New guest user button at the top of the blade.
  • Invite your Microsoft Account to the Azure Active Directory.

2018-03-26_9-50-53

2. Accept the invitation of your Microsoft Account to AAD

Now you have to accept the invitation…

  • You will receive an invitation e-mail to the mailbox associated with your Microsoft Account.
  • Do not click the Accept Invitation button from your e-mail client as it usually opens the web page in your browser where you are logged in using your Organizational Account and the invitation acceptance will fail.
  • Instead, copy the target URL of the button and open it in a New incognito window  (or In-private window or whatever it is called in your browser). (Alternatively you can sign out from your Organizational Account.)
  • Login using your Microsoft Account when asked for the credentials.
  • After accepting the invitation you will probably end up at the Applications page of the AAD (often empty), which might be a little confusing, but the association is done. You can close this browser window.

3. Change the directory of the subscription

Now you can change the directory of the subscription:

  • Sign in to Azure Portal using your Microsoft Account.
  • Navigate to your subscription and open the Subscriptions blade (you can type “subscription” in the search box).
  • Click the Change directory button in the top-row of the blade.
  • In the Change the directory panel you should have an option to select your Azure AD as a target directory for your subscription.
  • Confirm the change (Change button below).

Now you have to wait up to 10 minutes for the change to take effect.

2018-03-26_9-49-25

4. Add permissions to your Organizational Account

To be able to manage the subscription by your Organizational Account, you have to add permissions to it (still signed in with the original Microsoft Account).

  • In the Subscription blade switch to the Access control (AIM) section.
  • Add your Organizational Account with an Owner role to the subscription level.
  • Right-click the Organizational Account added and click Add as co-administrator in the context menu. (An optional step for legacy scenarios where the co-administrator privilege is still needed).

2018-03-26_9-22-25

5. Done

  • Sign-out from your Microsoft Account and sign up using your Organizational Account to verify you are able to manage your subscription from there.