Azure AD B2X is here ! (yes B2X, not B2C or B2B) – Debugging and insights

Now that we are past the click-bait title (B2X), lets dig into Azure AD External Identities which was unveiled at MSBuild20. For me its the first time I see subset of features bridged from Azure AD B2C to Azure AD, giving legitimacy for the B2X reference :)…

So what is Azure AD External Identities?

Sign-up mechanism that benefits from Access and Identity governance features already present in Azure AD

Essentially Azure AD External Identities enables modified sign-in flow to a pre-defined app/apps for existing Azure AD users in another tenants. The self-service sign-up feature works without the need of invite process, by exposing the ”create one” option – It could be better named as ”sign-up with existing Azure AD identity”

• on-boarding of the app previously required invite of the guest user to the tenant (you could work-around previously this with set of multi-tenant and single-tenant apps, and trigger the invite via API, but this obviously required separate maintenance, and was not a feature you could clearly see exposed from Azure AD Side)

What other B2C features there are?

For those who are familiar with B2C, its good to know, that features such like ad-hoc creation of local account via sign up is not part of this feature set, neither are most of other B2C features. I see it positioned to an entirely different user cases heavily towards external IAM, not consumer IAM.

• Its fair to mention that while my blog details the sign-up process for existing Azure AD identities, you could do really comprehensive set of scenarios with the direct federation feature, not to forget that there is Google and Facebook IDP possibility also part of the external identities! 🙂

Benefits for Azure AD External Identities from my perspective

• Easier approach for pure External IAM / Internal IAM scenarios
  • Same Azure AD tenant features for Identity and Access Governance cover also the external identities when applicable for features such as (this is the same benefit you get without self-service sign-up, but needs to be highlighted here)
    • Conditional Access
    • Access reviews

Configuration

• I saw few blogs already released of the configuration, so I’ve just added my insights below. If there are some takeaways for configuration, they are:
  • use Azure Portal, instead of Azure AD portal
  • have the sign-up feature enabled

Insights brain dump

• The self service is registered for Client, not for an API (raising this as separate point, more details few bullets later)
  • Wait few minutes before you try the new flow, and have existing test account ready for another tenant

• 

• 

• Dont try to sign in with existing user to the first form. Use the ”Create one!” which is correct option

• The main feature which I was after works just as intended, existing user in another Azure AD tenant can now sign-up without invite:

• 

• 

• 

• 

• 

More insights

• I am trying to find some reasoning to use this as any other than single tenant app, but for me it makes only sense as single tenant app, as it forces the sign-in method via guest account. If you enable this for multi-tenant app, the user could bypass the sign-in URI, and just sign-in using the Multitenant feature (Obviously on the back-end end side you can still trigger another on-boarding flow)

• If you get ”AADSTS50020” then check that you are requesting access to non-microsoft API, and at least the client is registered for the self service flow.
  • The resource or scope parameter cant be like ”https://graph.microsoft.com” – It has to be your own App which registered as API, or the client ID, which is requesting tokens for itself
  • Wont work: resource:”https://graph.microsoft.com”, client_id:”1197495f-4fa3-481b-97fb-af2a9dfa6f60″,
  • Works:resource:”1197495f-4fa3-481b-97fb-af2a9dfa6f60″,client_id:”1197495f-4fa3-481b-97fb-af2a9dfa6f60″,
  • Works:  resource:”https://b2x.dewi.red”,client_id:”1197495f-4fa3-481b-97fb-af2a9dfa6f60″,
  • Also if you have just created AAD user in the guest tenant, ensure that user has signed in at least once to its own tenant (there might be some back-end propagation delay)
  • I didn’t do extensive checking how well the flow supports consent approvals, but if you are having problems, try to add admin consent for the application ( I did admin consent on all my tests before trying the full flow. The problem below might have something to do with the fact, that no consent can be recorded for user that has not been on-boarded to the tenant. If you are doing self sign-up, the consent flow cant be presented, because the object doesn’t yet exist)
  • If you don’t see tenant switched before sign-in with existing Azure AD account you will see the following error AADSTS50020

AADSTS50020: User account 'testuser1447869464@m365.dewi.red' from identity provider 'https://sts.windows.net/f996ef8a-f93b-47e5-9ed9-a9d5e5b95245/' does not exist in tenant 'dewired' and cannot access the application '1197495f-4fa3-481b-97fb-af2a9dfa6f60'(b2xClientApp) in that tenant. The account needs to be added as an external user in the tenant first. Sign out and sign in again with a different Azure Active Directory user account.

• If you have both API and Client as separate app registrations, at least the client needs to be enabled as enabled for the sign-in flow. Both need to enabled if you plan to use the API also as the client for web sign-in
  • Correlation ID: ee11e28b-10e5-4073-83c4-eb8622a74051Timestamp: 2020-06-08 06:41:02ZAADB2C90011: The client id ’1197495f-4fa3-481b-97fb-af2a9dfa6f60’ provided in the request does not match client id ’4829629c-4ae8-42a5-9def-bd28fbfd6992’ registered in policy.

• If you are having trouble exposing the new flow to client, you can try an force it by appending parameter &Policy={policyName}, to the end of the authorization request URL.
  • &policy=B2X_1_securefileshare
  • I wouldn’t recommend this approach, but it might good for testing and debugging

• In order to get the B2X flows associated with new application I had to update the applications for B2X flows with powershell, instead of using the browser. (Later I didn’t have this problem, but if you face the same problem you could also copy the client side call from Browser to PS )
  • For some unknown reason any new applications selected from the App Selection picker, wouldn’t trigger the browser side call to IAM API, which then enables the app for B2X flow (Didn’t have time to debug the SPA filtering for the picker function in browser, so I had to use PowerShell to complete that call)

• 

• 

Aad.portal.azure.com vs portal.azure.com use

• This has now been fixed, as commented on the articles earlier, this part is only for reference here

• its recommended, to add &prompt=login to any apps login flow, that is registered for self-service portal. this will allow the selection of ’create one’ option ’var loginurl = `${authorization_endpoint}?client_id=${client_id}&redirect_uri=${redirect_uri}&scope=${scope}&response_mode=${response_mode}&response_type=${response_type}&prompt=login`’

This is where the insights dump ends 🙂