DMPRoadmap / roadmap

DCC/UC3 collaboration for a data management planning tool
MIT License
102 stars 109 forks source link

[FEATURE] Disable mandatory account creation when signing in with institutional credentials. #3290

Closed Danny-dK closed 1 year ago

Danny-dK commented 1 year ago

For institutes that have institutional access and have their own page and theme (such as dmp.wur.nl), their users can sign-in using institutional credentials. First time users have to create a DMP account to link with the institutional credentials. This is odd behaviour to me and our institute. In theory, someone working for an institution that is required to create a DMP for a project within that institute, should only require an institutional account. If they would require a private – non-institutional account (to have access to their DMP after employment), they would need to create an account themselves as an extra step (this in my view should not be prompted for first time users when signing in with institutional credentials as a mandatory field). Once people decided that they need a personal DMP account, decided to create their own account, they can then share their DMP’s themselves with their own personal account to have access to them.

The mandatory account creation and linking invites yet another online account to be created, which may have a chosen poor password, and of which the account could then possibly be accessed by people with wrong intentions leading to possible unauthorized access to sensitive information. It additionally requires users to yet again regularly update a self-chosen password to keep an online account secure, whereas users are automatically prompted to update the institutional password regularly.

Please consider disabling the automatic mandatory DMPonline account creation and linking to the institutional account upon signing in for institutes. Or at least make it optional.

briri commented 1 year ago

Hi @Danny-dK

Each fork of the DMPRoadmap codebase typically customizes the sign in/up workflow (along with the ability to link/unlink that account on the profile page) to suit their needs since each fork's audience differs. Some forks support one institution while others are open to any users.

This makes it incredibly difficult for us to provide a single solution that works for all. The information each institution's identity provider returns to the application also varies (e.g. some include first name and last name, others return a single name field and still others do not return a name at all) which further complicates our ability to provide a one-size-fits-all solution.

Since it sounds like you're working with a single institution, it should be fairly straightforward for you to modify the workflow to eliminate the need for a password. The Devise gem we use for security requires a password to be present in order to create an entry in the users table in the database. To get around this restraint, you could auto-generate random unique passwords for these SSO users and just hide the field on the sign up form along with the profile page.

Danny-dK commented 1 year ago

@briri Interesting! Thanks for the information. We are not implementing DMPonline ourselves, but use the hosted version of DMPonline at Edinburgh University. I'm not sure how much they are able to configure per institute that they are providing institutional access for. I asked the DCC helpdesk as well about customizing the login page and the workflow that there initially should only be a institutional login without the need to create a personal account by default (they should only create a personal account when they desire to). They indicated:

"We can't customise the login page to show the SSO button only." "You seem to be suggesting that users should create separate personal accounts and professional accounts? This is not viable and very confusing for the user. Users would find it difficult to remember whether they own a plan or not, and in which account. It would result in a lot of duplicate accounts thus skewing usage statistics for organizations." "In our current data model, users own their accounts and their plans and are free to move between institutions. The institution doesn't own users and their plans."

So I'm assuming configuring different instances is (understandably) not viable for them at the moment.

I will discuss internally here (and close the issue for now). Thanks again!