How to convert account from one sso method (shib) to another (CIlogon)?

[MM - ADA]

Hi Team,

I am wondering if there is a way for a current dataverse user using shib to sign in (sso) to convert their account to a different authentication platform (cilogon/aaf+edugain).

ADA has implemented SSO with shib/AAF and now wants to switch from shib/AAF to CIlogon. To do this requires a user to convert their account. But to convert your account you need an email and password. Since you are a shib user, there is no password, and a password reset is not possible.

Is there something I am missing here? Or is there a workaround?

One option is to convert all shib users back to builtin users and ask them to re-convert from builtin to CILogon but that could be very confusing to those users. And difficult to explain.

Another option may be to preload existing dataverse shib users into the CILogon infrastructure to create their CILogon identifiers, then update the dataverse table with those identifiers. But that seems not ideal.

Any advice would be appreciated.

Thank you!

[Philip Durbin]

Hi! This is somewhat related to the need for an API to update the persistentUserId when a Shibboleth entityId changes: https://github.com/IQSS/dataverse/issues/10446

In practice, Don Richards (who opened that issue), did something like this:

UPDATE authenticateduserlookup SET persistentuserid = REPLACE(persistentuserid, 'https://old_url.jh.edu/shibboleth', 'https://new_url.jh.edu/shibboleth') WHERE authenticationproviderid = 'shib';

Your situation is unique, of course. It sounds like you're moving from Shib to OIDC, from a quick look at the CILogon docs. As you suspect, it's probably going to take some database hacking. If you can imagine what your ideal API would look like, an API that would update your user records from Shib to OIDC, please feel free to describe it here or open an issue about it. I'm curious what the inputs would be.

As you say, yes, you could convert a user's account from Shib to builtin, give them a password, and then have them convert that builtin account to CILogon/OIDC but I agree it would result in mass confusion. We do have a documented procedure for this but it's intended for a single user, not a bulk migration: https://guides.dataverse.org/en/6.5/installation/shibboleth.html#converting-shibboleth-users-to-local

I hope this helps!

Phil

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/818e05b6-0ab5-44fa-9d76-b9d8aa68f204n%40googlegroups.com.

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin

[MM - ADA]

Thanks Phil - you are correct, we are (trying) to switch shib/SAML authentication users to be CILogon/OIDC authentication users.

In thinking about it more, I was hoping that dataverse would allow multiple ways to authenticate by allowing multiple entries into the authenticateduserlookup table for a single user by creating a unique constraint for (authenticatediuser_id, persistentuserid, authenticationproviderid) so multiple methods, but only 1 entry per each authentication type per user.

Then, based on the authentication type selected by the user (builtin, shib, oidc, ...), the authentication object would know what to look for in the authenticateduserlookup table and authenticate them with the user-selected method. That way, a user wouldn't ever have to convert their account as needs to happen now, but select one (of potentially multiple) ways to authenticate.

Sadly, it appears that a unique constraint has been placed on the authenticateduser_id field in the authenticateduserlookup table so only one row per user is allowed.

Is it feasible to change this unique constraint in the table to be the 3 columns, and allow multiple choices for a user to authenticate? So I could potentially have a builtin login, a shib login, a cilogon (oidc) login...
There is likely a complicating factor with the actual API and UI classes involved in authentication that won't allow this, but it would be great (IMO) if multiple authentication methods could be facilitated.

Thanks!

[Philip Durbin]

Sadly, we had this in our original auth design for Dataverse 4.0 but lost it. https://github.com/IQSS/dataverse/issues/3487 tells the sad story of how in the great "auth branch merge party" of 2014, for expediency, we got rid of the idea of allowing multiple login methods to map to the same user account.

If you check out screenshots in that issue (down a bit) you'll see that one approach is to delegate the combining of login methods to an identity management (IdM) platform. For you this would be CILogon. In the issue, Unity IdM is shown. In development we are using Keycloak and might even require Keycloak or some sort of IdM in the future when the new React frontend is rolled out (see https://github.com/IQSS/dataverse-frontend/issues/517 ).

I say all this about IdMs and Keycloak because while I wish we had multiple logins to the same accounts natively in Dataverse as originally designed for 4.0, the auth landscape has changed (especially since we are rewriting the UI in React) and we don't have any plans to revisit that decision in 2014. That said, you are very welcome to play around with reverting that commit ( https://github.com/IQSS/dataverse/commit/fe8e41a484fcf02fff498c297633bdfe287fc754 ) and let us know how feasible you think it might be to bring back that feature!

To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/501132cb-4740-475a-85a8-3dcf5b7d7746n%40googlegroups.com.