Dataverse: OIDC: make use of attribute "email_verified"

[poikilotherm]

When we introduced OpenID Connect support back in #5974 and PR #6433, we left out a few things. One of those was support for the email verified status of new user accounts.

Currently, only the Shibboleth provider offers support for this:

https://github.com/IQSS/dataverse/blob/9ce4aa00603d9fd9233a5c4d99b527ed230af1ce/src/main/java/edu/harvard/iq/dataverse/authorization/AuthenticationServiceBean.java#L609-L618

Within OpenID Connect, we have a defined scope email attribute email_verified, which can be set by the provider. (This is one of the points where OIDC offers more that OAuth2 only...).
We should start to support this, as it makes the process more easy, when the IDM/IAM/OIDC provider already did the verification for us.

I'm not sure if UI/UX team is involved here, as there is no UI change necessary.

[djbrooke]

@poikilotherm, sorry if this is a naive question, but is there a security risk in letting the provider set the email_verified status? Some providers ostensibly would be more trustworthy than others. Would we want the installation admin to set this instead?

[pdurbin]

Related:

• Shibboleth users who predate Shibboleth are assumed to be email-verified but aren't #5663
• Email confirmation: user account restriction #3300

[poikilotherm]

Hi @djbrooke,
obviously you will need to trust your provider :wink:

To provide an example: https://login.helmholtz-data-federation.de which we are using for Jülich DATA, is an IDM based on Unity. It has rules configured that people signing in via SAML, having the IdP send an email address and originating from inside DFN AAI (German Research Network), have set the attribute email_verified to true. Anyone else is untrusted.
That's fine for us, but obviously your mileage may vary.

I am more than happy to make this configurable, so the admin can decide whether the provider shouldn't be trusted at all. There already is an attribute in AuthenticationProvider, which looks like a perfect match to me:
https://github.com/IQSS/dataverse/blob/9ce4aa00603d9fd9233a5c4d99b527ed230af1ce/src/main/java/edu/harvard/iq/dataverse/authorization/AuthenticationProvider.java#L49-L53

So when setting the attribute, it would be a simple && comparison with this attribute. We should leave this as false for a sane default (better safe than sorry).

I'll create another issue at this point about refactoring the configuration, as this should be done before this then.

[pdurbin]

@poikilotherm out of curiosity, are you going to let your users change their email addresses within Dataverse? Please see my related comment at https://github.com/IQSS/dataverse/issues/6515#issuecomment-575132599 (for context) or below:

"Right now the rule is that only Shibboleth users have their email, name, affiliation, etc, overwritten every time. If we're going to let Shibboleth users update their name, affiliation, etc (as I think we should), we're going to need to prevent these automatic updates from occurring."

I bring this up because the ideas of preventing users from updating their email address within Dataverse and marking that email address as verified feel related.

[poikilotherm]

@pdurbin good catch! I just looked at that and found that the mail address change indeed is allowed. Need to dig into the code, as this should indeed not be possible (or at least configurable per provider).

[pdurbin]

configurable per provider

I love this idea. Can you please leave a comment about this on #6515?

[djbrooke]

@poikilotherm thanks. If we can set this up so that users from some providers in an installation can be considered verified (like Shib in Harvard Dataverse) and others not verified (like Orcid, Github, Google in Harvard Dataverse) then we'll welcome a PR for this.

I know we aren't using the OIDC flavors of the above in Harvard Dataverse, but I'm just mentioning them as an example.

[poikilotherm]

Hi @djbrooke, #6694 is a blocker for this. I would appreciate any feedback on that issue, as I would likely fix that first to be able to make this actually configurable. :smile:

[djbrooke]

@poikilotherm got it, thanks. I just responded there.