Evaluating Entra External Id

Open Forum
1

See Evaluating external identity providers [draft] for the background.

Entra External ID is a totally separate instance. In “external tenants” mode it’s dedicated to interactions with users outside of your company. For us this would be NHS users for clinical audit platforms, developers integrating with our APIs etc.

Logging in with an external OpenID provider

This is the biggest glaring omission, blocking our adoption today. Azure B2C does support this which is frustrating - I believe on balance we should try and adopt the newer Microsoft technology if we adopt anything at all. Otherwise we’re just setting ourselves up for a migration within 5 years.

That said, the pros say it’s coming in 2024:

So I think it’s reasonable to evaluate it as if this feature were available.

You can create a user flow that allows sign up or force it only to work with existing users only using a nasty Microsoft Graph API call. I’m not sure exactly how this would work as we would really want to require RCPCH users to authenticate against our internal AD.

:question: How would we force some users to use a federated provider rather than username and password?

You can customise the branding as we do with the RCPCH internal AD login.

Managing OAuth credentials

We would need two sets of app registrations in our external tenant:

  • The API you want to consume (eg NPDA patient data POST)
  • Your app registration as a holder for your client ID and secrets

You can grant

Obtaining a token is a straight forward OAuth client credentials call, see the example here (private link).

In Azure APIM it’s easy to verify a token once obtained using validate-azure-ad-token in the policy:

<policies>
    <!-- Throttle, authorize, validate, cache, or transform the requests -->
    <inbound>
        <validate-azure-ad-token tenant-id="{{tenant-id}}">
            <audiences>
              <audience>{{client ID of the API you want to consume}}</audience>
            </audiences>
        </validate-azure-ad-token>
        <base />
    </inbound>

You grant access to the API by adding an app role in the API to be consumed and adding it in the API permissions section of the app registration for the client.

In the application itself we must then verify the token to ensure unauthorised access is not possible even if we keep the app itself exposed on the internet and not behind the APIM instance. See example here (private link).

For the future there is an API for managing applications, including creating client secrets.However this is via the Microsoft Graph API and you cannot access resources cross tenant using a managed identity. This leaves us managing a self generated certificate, as whatever instance of our code (eg our discourse-apim plugin) will necessarily be running in a different Entra tenant.

You must specifically request the scopes to perform such requests, otherwise they fail even if the user you log in as can do them in the admin UI