In the dungeons of Azure AD B2B: prevented that external can have multiple active guest accounts on alternative email addresses

A charm of Azure AD B2B is that the responsibility for guests account management is federated to the external context of invited person. But with this charm inevitable also comes lesser direct control, as within the inviting tenant you have no insight on the federated account in the external Azure Active Directory. I wrote already on a negative effect that can result from this: properties of external Azure AD account might block creation of guest account.

Recent I experienced a peculiar variant of this issue. An external was successful invited, and able to redeem the provisioned guest account and use that to access resources in the inviting tenant. At a later moment, the same external was reinvited via New-AzureADMSInvitation cmdlet on an alternative email address as identity. This was also successful and resulted in a second guest account provisioned in the inviting tenant. But when trying to resend the redeem invitation from Azure Portal, this failed as the new guest account on deeper level is referring to the same federated external identity as the original provisioned guest account. Thus although it looked in the inviting tenant that the 2 guest accounts were isolated from each other, in the reality of the actual identity source of the invited external the 2 alternative emails are administrated as proxy addresses within the same external Azure AD account.

I consider it as correct behavior by Azure AD B2B to recognize this, and prevent that multiple guest accounts can federate to the same single external Azure AD account.

Same external invited with 2 separate guest accounts in inviting tenant

Initial guest account successful accepted and activated

Later provisioned guest account cannot be accepted

Reinvite via Azure Portal blocked as guest account is referring to same external Azure AD account

Developer inconvenience: Deploy Isolated WebPart with webApiPermissionRequests fails unless permission to create new Azure AD App Registration

In real-life enterprise context, it is advised to tag any SPFx webparts that will invoke an Azure AD protected API as isolated. This to prevent that other script running in same page, can abuse the OAuth access token assigned to the SPFx webpart and invoke any tenant-wide API permissions on behalf of current user.

However, you need to be aware of some deployment implications with Isolated WebParts. The first one is that in the Microsoft design, you can only deploy Isolated WebParts via the tenant AppCatalog. It is not possible to deploy an Isolated WebPart (only) to the site App Catalog where it will actualy be used. I suspect this is due that each Isolated SPFx WebPart creates a new Azure AD App Registration on tenant level, and for consistency the SPFx WebPart must therefore also be installed on tenant level. Negative result is that every site-specific customization is visible on all others sites where it likely is unusable. Luckily this visibility is initial limited to only the site owners in "Add an App". Only after a site owner explicit adds the Isolated WebPart to the site, then it will be visible in page editing mode in the available WebParts.

An even more significant inconvenience is that to successful deploy an Isolated WebPart, you need to have the authorization to create a new Azure AD App Registration. Without that permission, the deployment in tenant AppCatalog will fail with the generic error 'Deployment failed. Correlation Id ....'. Implication is that in effect the dependency on Ops is unnecessarily increased: a developer must reach out to a Global Admin for the deployment of SPFx solution containing Isolated WebPart. But the better option is that you request that Global Admin to assign your account the Application Developer role, then you are empowered to do this 'Ops' part yourself.

Simple pattern to ensure unique element ID inside SPFx React WebPart

When you build a SharePoint WebPart, you must take into account that the business user can add multiple instances of that webpart on a single page. So the operational execution must be robust for that. In case your webpart relies on HTML element ID, e.g. via 'getElementbyId', then you must ensure that the element ID of each instance is unique. A simple pattern I applied is to derive the ID of the inner React Component on that of the unique ID of the parent React WebPart.

Part 1: Extend the React WebPart Properties interface with a property for unique ID

Part 2: Parent React WebPart derives unique ID from its own, and pushes to the inner React Component

Part 3: Inner React Control applies the received unique ID in its rendering + operation