As a Dataverse admin, I would like to hook up my installation to an IDM/IAM

[poikilotherm]

After some recent chat on IRC with @pdurbin here and here, I am opening this issue quickly, as @pdurbin pointed out slide 32 by @djbrooke regarding future changes on the auth flow.

Motivation

We have had a discussion at FZJ about what auth methods we will allow and the result was that we will need to provide multiple options, including reusing the already existing accounts from AD. We are part of DFN AAI/eduGain, so there is a SAML IdP present, too.

While working on IQSS/dataverse-kubernetes, I tried to integrate the SAML IdP in gdcc/dataverse-kubernetes#14 using mod_auth_mellon instead of Shibboleth. Shibboleth as an SP IMHO is a nightmare. You can only use it with mod_shib, have to run it on the same host/container as Apache does and for usage with Dataverse, you are tied to using mod_ajp. As Dataverse is very tightly integrated with Shibboleth specials (reading sessions, etc), I had no luck with mod_auth_mellon... 😢

Proposal

All of this is not very container friendly, which is why I would like to propose integrating a "new" option: usage of an IDM/IAM.

Most existing solutions are capable of OAuth2 and/or OpenID Connect. At least OAuth2 support is already present in Dataverse.

Steps to be taken:

1. Use current OAuth2 lib to read OpenID Connect data:
   • Provide integration tests for Github, Google and ORCID to ensure nothing breaks (using stubs) See Providing testing for current OAuth2 implementations #5985
   • Update to latest version (6.6.3) from v3.1.0 (See Upgrade ScribeJava to latest version #5991)
   • Write new AuthenticationProvider for interaction with a custom endpoint (see Implement first (simple/PoC) version of a OIDC auth provider #6432)
   • Receive and parse user data following Open ID connect standard (see Implement first (simple/PoC) version of a OIDC auth provider #6432)
   • Provide documenation on usage and technical details (see Implement first (simple/PoC) version of a OIDC auth provider #6432)
   • Stick with current "flow" based on first login page, etc for this first step.
   • This might be referred to as "OpenID Connect Core".
2. Create automated testing with Unity IDM provided by Helmholz Data Federation
3. Make use of email adress verification status claim available from OIDC
4. Make non-interactive signup via OA2/OIDC possible (OAuth2FirstLoginPage) w/ fallback when missing required
5. Introduce OpenID Connect as an emerging standard (also supported by Google, ORCID, but not by GitHub yet). [1]
6. Maybe more. Placeholder.

Benefits

1. Open ID Connect support is also benefical without using an IDM, as it is the appropriate standard for authn via OAuth2.
2. Using an IDM could be a solution to Permit multiple login options to the same Dataverse account #3487.
3. Offloading the hard work for authentication with upstream IdPs and services to an IDM might be a solution for As a Dataverse Installation Administrator, I want to add an alternative OAuth provider as a plugin, so that I don't have to fork the core code #4383
4. Many IDM solutions offer LDAP support as auth backend, so existing directories can be reused. No need to implement this in Dataverse.
5. Integrations might benefit from an IDM, too. Instead of creating multiple service points for SAML, etc. they can use easier OAuth2 for integration with Dataverse.
6. Most certainly even more.

Things for later optimization

• Refactor to remove some unused functions
• Refactor OAuth2 infrastructure to be named as "flow" or "token" or similar to be clearer
• Refactor AbstractOAuth2Authentication Provider into proper interfaced contracts for usage in the bean and reflect the clearer naming above
• Refactor ORCID provider, see Refactor ORCID OAuth2 and OAuth2TokenData #6329
• Refactor JSON files for providers: make factoryData proper JSON for ease of parsing, etc.
• Refactor OAuth2UserRecord creation to use factory/decorator pattern.

Costs

Minor(?) dev effort for Dataverse side, as lots of things are already present.

Examples

You might take a look at B2SHARE using B2ACCESS, also featuring X509 logins. This is based on Unity IDM, see here. Other, bigger examples for open source IDMs are Gluu and FreeIPA.

Footnotes

[1]: Current usage of ScribeJava should be replaced at least longterm, as it has no proper support for this.

[djbrooke]

Thanks @poikilotherm for the thoughtful writeup here.

We'd like to revisit our sign up flow in the future, one of the big points being better scalability of signup options from a UI/UX standpoint. Sorry for a possibly dumb question, but would this consist of just backend changes or would this require frontend changes as well?

[poikilotherm]

The change about the non-interactive signup is kind of frontend, as it relates UX, but not necessarily UI. The communication between the IDM and Dataverse could be seen as frontend, too, depending on the OA/OIDC flow in use... So I lean towards yes, frontend changes.

[pdurbin]

At tech hours today with @scolapasta @sekmiller and @mheppler I talked about this issue and the plan above and the "in focus" column at https://github.com/orgs/IQSS/projects/4#column-5769388

There seems to be agreement that

• At the feature and product level, we should get @djbrooke involved.
• At a technical level, we should continue to discuss the plan above at tech hours or elsewhere. We don't have a formal process but perhaps a video chat would be good.

[djbrooke]

@poikilotherm thanks for the discussion and the detailed explanation (pretty much what's above :)) on Friday. Thanks @pdurbin and @scolapasta for joining. I'm excited about this because one of our strategic goals is to drive adoption and a big part of that is allowing more sign up and log in options. We've received a few requests for additional log in options and we've not implemented them because it would require us to implement and take ownership of the custom code for that provider.

My three main questions were:

• What is the UI implication when new login methods are added?
• Are we taking on any custom code?
• How evolved is this OpenID Connect standard?

I heard from that new login methods would require adding a button that directs to some outside system, similar to what happens upon institution selection on Shibboleth now. We'd not take on any custom code, as new auth methods could be added as configuration options. I did a little bit of reading on OpenID Connect and it seems to be well established. So, I'm happy enough. 👍

I moved the first step of this to Code Review (#5991). Keep them coming and get in touch if you have questions or need additional guidance. Thank you for the work here!

[TaniaSchlatter]

Images of Harvard and others' log in pages are in this working doc.

[pdurbin]

@poikilotherm pull request #6192 was just merged!! 🎉 🎉 🎉

I believe this means you can check off at least one of the boxes above under "Steps to be taken". Have the steps changed at all? Please let us know how we can help! 😄

Also, do you have any thoughts on how the UI would look? Have you mocked anything up?

Thanks!