Customize and extend self-service sign-up for guest users with Power Automate flow

External Identities are a new feature in Azure AD. We had already B2B, B2C and now we have B2X (see blog post, blog post). The default identity providor is Azure AD but this can be extended with other identity providers like Google, Facebook, etc. B2X offers self-service sign-up user flows (preview) that can be used to give external users access to your apps, based on a guest user account that’s added as result. A self-service sign-up user flow creates a sign-up experience for your external users through the application you want to share. Here’s an example of self-service sign-up.
During the sign-up experience additional information about the external user can be collected and mapped to standard and custom attributes in Azure AD and added to the created guest user account in the host Azure AD.

External Identities is a set of capabilities that enables organizations to secure and manage any external user, including customers and partners. Building on B2B collaboration, External Identities gives you more ways to interact and connect with users outside your organization.

Microsoft Docs

We can use API connectors to integrate self-service sign-up user flows with external systems by leveraging web APIs. Wouldn’t it be great if we could call Power Automate flow with an API connector? That would open up the possibility to use Power Automate flow to perform identity verification of the external user and validate user input data. To configure an API connector we need an endpoint URL of the API; this could be the HTTP POST URL of a ‘When a HTTP request is received’ trigger in Power Automate flow. But only Basic Authentication is currently supported and that won’t work with flow. Fortunately we’re able to expose the flow with Basis Authentication enabled by using Azure API Management. I found an old blog post by Serge Luca how to set up an new API to call the HTTP POST URL of a flow. To make this work with the API connector we need to secure it with Basic Authentication only, so the standard subscription key should be disabled.

The Basic Authentication is enabled by adding a policy to the inbound processing via the policy code editor.

The Base64 encoded string ‘username:password’ is added to the value element after ‘Basic ‘. It might be a better idea to store the username and password in the Azure key vault. See this blog post for more information. The Authorization header is deleted before it’s passed to the backend, the flow itself.

<inbound>
    <base />
    <check-header name="Authorization" failed-check-httpcode="401" failed-check-error-message="Not authorized" ignore-case="false">
        <value>Basic dXNlcm5hbWU6cGFzc3dvcmQ</value>
    </check-header>
    <set-header name="Authorization" exists-action="delete" />
</inbound>

I’ve created a simple test flow with the ‘When a HTTP request is received’ trigger and Response action.

Now we’re set to test it by calling the Base URL from Postman with Basic Authentication enabled. And it works!

Now we know it’s possible to call Power Automate flow with an API connector from a self-service sign-up user flow we can look for use cases. One use case I came up with is the self-service sign-up user flow for Power Apps Portal, where we can use Power Automate flow to perform identity verification of the external user based on the e-mail address/domain of a matching Contact/Account record in Dataverse. That will be the subject of my next blog post.