OpenID reconcile not executing?

donal

Hi,

I recently installed and configured FusionAuth using the Helm Chart here.

I am trying to test SSO from an AzureAD directory and needed to use a reconcile lambda to populate email address (since it is not returned in the userinfo response from Azure in our case, however appears to be present in the id token).

I have enabled an OpenID reconcile lambda with the following code (and set "Debug enabled" to true):

function reconcile(user, registration, jwt) {
  console.info(JSON.stringify(jwt, null, 2));
}

I confirmed this lambda is selected as the reconcile lambda on the IDP edit page. I also set "Debug enabled" to true for both the IDP and the application.

However, the only output I see in the event logs are the "OpenID Connect IdP Response Debug Log" for each attempted log in. I'm not filtering the logs by type or date. I'm not sure if the reconcile lambda is executing and not logging to the event log, or just not executing at all. I expect that some other logs should be written to the Event Log, based on the debug settings described above?

I wonder if anyone else has run into this before?

Thanks,
Dónal

egis

I am currently testing a multi-tenant Azure AD via OpenID connect identity provider in FusionAuth too. Did you add openid scope to the OpenID Connect identity provider? Also check the contents of the access/id tokens you are getting from Azure AD if email is in there.

If I understand correctly FusionAuth is trying to find an email claim first and only when it does that successfully it will run a reconcile lambda. So if it cannot find an email claim it will not run your lambda. At least thats what I experienced.

I am currently trying to find a way to populate jwt with additional claims (tid - tenant id) from the Azure AD tokens and it seems that reconcile lambda does not have access to those either.

donal

I have the scope set to 'openid email'. I also tried just 'openid'. I also tried setting the linking strategy to 'Create a pending link'.

In all cases, it appears either the reconciler is not executing or nothing is being logged out.

I extracted the id_token from the "OpenID Connect IdP Response Debug Log" and inspected it. There is an email address in the "preferred_username" field in the id_token, but it is not returned in the userinfo response.

joshua

@donal @egis

Sorry to hear that you are having trouble!

Can you confirm that you have followed the instructions on this tutorial?
https://site-local.fusionauth.io/docs/v1/tech/identity-providers/openid-connect/azure-ad/

The reason that I mention it, is that I ran through this configuration and set up recently and everything was functional. That said, things can change over time

Also, can you confirm if this works by removing the variable of helm/k8s? Running FusionAuth locally and testing the same behavior would rule out one more variable.

Thanks and let us know!

Thanks,
Josh

donal

Hi @Joshua,

It seems this is working as expected as @egis described. FusionAuth needs to find an email claim in the response from the userinfo endpoint (or username, depending on the linking method) before running the reconcile lambda. I confirmed this by linking on username instead and setting preferred_username to sub and was able to confirm that the reconcile lambda executed. I had mistakenly thought that the lambda ran before linking occurred and could be used to populate email.

In my case, the issue is that my IDP (AzureAD) does not return email from the userinfo endpoint. AzureAD is very restricted in what it returns from the userinfo endpoint and allows not customization or claim mapping. It seems AzureAD populates the email claim with Primary SMTP email address, which is reserved field from Exchange, however we don't use Exchange/Outlook365 as our email service provider.

In Azure, claim mapping can only be applied to the access and id tokens and not what is returned from the userinfo endpoint. However, these tokens are not available to the lambdas.

I believe there is already a Github issue created for this:
https://github.com/FusionAuth/fusionauth-issues/issues/323

In the meantime, I'm using SAML instead, because AzureAD allows me to map email address to user.mail which is where it is stored in our case.