2.0 to 3.0 + oaut to azure sso (OpenID)

Administrators
1

Hi all,

I just finished the installation of a new Indico 3.2 and imported all data and DB from a v2.0 instance.

SSO works fine for new users but old users seems to be unusable (e-mail already in use) due to some info in the users database related to the old integration().

Would it be possible to clean that data so we can reuse the same users (shib-sso).

Thanks

2

Did you rename the identity provider dict key in the config by any chance?

In any case, as long as there is an email match people will be able to re-link their account. Or is the email coming from your SSO not marked as trusted by any chance [1]? Maybe we have some edge case where we still check if the email is in use instead of validating and then offer to link… But if you use a decent SSO provider that gives you a known-to-be-verified email, then you can simply set it as trusted and skip the repeated email validation on the Indico side.

Anyway, I need some details on how they are “unusable”. Any specific error they get?

[1] From the docs:

  • trusted_email – Set this to True if all email addresses
    received from the provider are trustworthy, i.e. if it is guaranteed
    that an email address actually belongs to the user (either because
    it’s coming from a trusted employee database or the provider is known
    to send verification emails). If an email is trusted, Indico will
    use it immediately to start the signup process or associate an
    existing account with a matching email address. Otherwise a
    verification email is sent to prove that the user has access to the
    email address, which is less user-friendly but extremely important
    to prevent malicious takeovers of Indico accounts.
3

Hi ThiefMaster,

I created a new config file and named the new sso with a different name. Then I realized the users have a provider associated so I renamed to the old one but the problem is still there. trusted_email is also ‘true’

If I try to log in (from SSO login) with a user that was imported from the old version, I can enter user pass details. After that, I am redirected to the Indico user registration page.

At that point, I enter the e-mail of the account that already exists and it fails with the error ‘This email address is already in use’.

Thanks

4

That sounds weird.

First of all, if the old and new SSO use the same unique identifier for users, you should use the same dict key. That way no re-linking is needed.

Then, can you take screenshots of every step when logging in with such a user? What you explain sounds really strange, especially the “enter user pass details” part… At no time you should be required to enter a username or password on the Indico site when using SSO.

5

Yes, it is weird for me as well.

I send you the complete sequence in a picture since I am not allowed to upload one per post.
User/pass details are asked if I am not looged to office365. Otherwise it redirects me directly to the last page (User registration)

image
image1897×911 97.7 KB

Thanks

6

Looks like trusted_email is not correctly set. Can you share your IDENTITY_PROVIDERS config (censor any secrets of course)?

PS: I removed the “new user” restrictions from your account so you should be able to post multiple pictures in the future. Anyway, the single one containing everything was pretty convenient as well :wink:

7

Thank you for the change!

This is the current config:

image
image1183×527 18.3 KB

8

Umm are you actually receiving an email address from the SSO (at least it’s not in the mapping)?

9

That is correct, I was not receiving anything. It was not so clear to me how to fill in that config file…

I added the email to the mapping and also:
‘identifier_field’: ‘email’

And it looks much better now:

image
image1199×450 60.7 KB

Thanks again!

10

Yes, that looks much better indeed!

Note: email is only a good identifier if it never changes. If your users can change the email address on the SSO side, then it’s better to rely on some unique ID (i don’t know what exactly azure ad provides there) as the identifier instead.

11

Yes, I needed to keep this for the moment but I will try to use some more unique id after the migration is completed.
Thanks

12

Just keep in mind that if you change it again, people will need to go through the “new authentication method” prompt again.

PS: You may want to change the identity provider title to something like “SSO” instead of “Login with SSO” (that title is more suitable for the authentication provider).

13

I will. Thank you for the helpful advice!