Well we got past the error, simply by regenerating the key. Looks like there a bug in the code, maybe it’s not being escaped properly, but it’s hard given there isn’t much to tell us that in the logs. There another issue though, it looks like the email is not being pulled across in the bootstrap process.
Yes, I’ve tried ‘openid email’ and 'openid email profile" and all combinations of the two. It is getting some information because it’s populating the name. Could there be something in the logs I can look for?
Thanks a tonne, I will wait for that. While I have you, one last question. If we can get this working, the next part will be to migrate an existing instance, where we were just using plain-old LDAP for auth. Is there a bulk approach to link existing users to an OIDC associated account? How would be go about making this a simple transition for existing users? We don’t want to lose all the content. Thoughts?
If the email addresses match, then accounts will be linked up automatically. If not, then you can use the rails console to migrate the associations - that would rely on the UIDs being the same for OpenID-connect as LDAP
Interestingly, we use the same configuration for other apps where Azure AD is the IDP and those applications seem to pull the email just fine. Admittedly, I don’t know all the details of those products and how they accomplish that.
Note that the e-mail address may not be returned in an email claim: in my case (once I got it working) it’s coming back in a name claim.
That is indeed what we’re seeing - so it sounds like AD does not quite comply with the openid-connect specification . If you can manage to configure AD to return it in the email claim, that would be the best solution. However, it looks like even microsoft’s own ruby implementation hacks around the problem:
If you really want to use the openid-connect plugin, you could write another plugin to ‘trick’ our openid-connect plugin into using the upn for the email address. Note that this would not be a ‘supported’ configuration, but if you have some ruby experience you could do something like this (not tested):
def after_authenticate(auth_token, existing_account: nil)
auth_token[:info][:email] = auth_token[:extra][:raw_info][:upn]
Would it not make sense to add that or condition to the base plugin given that make people will be using Azure AD as their provider? I know it’s not pure, but I’m guessing that’s how the other clients do it so that they can support Azure AD, which is probably the most widely used IDP in the corporate world?