Should we include some authentication usable by all without hassle?

[jmaassen]

In the hands-on sessions with the guys from GFZ, it became clear that our current authentication using SurfConext is a bit of a barrier when someone outside of our team tries to run a local copy of the RSD.

Maybe it could be an option to enable some (very simple) fallback authentication mechanism for demo purposes?

[markusbradke]

I would be in favour of this idea. Just to summarise what would be needed for the implementation:

• Registration page (name, email, password)
• Verification of the email address
• Independent login page
• Password reset function
• Profile page
• Email server

[jmaassen]

This is one of the features we already have on our todo list for the longer term. We're not 100% sure yet if this would fit our initial use-cases, in which we generally work with an organization (like you guys) that want to use the organization's login mechanism.

It probably good to discuss this as part of the bigger 'login and profile' discussion, where we mail also want to add the option to use orcid, github, gitlab, etc. as a login mechanism.

[dmijatovic]

We created test provider that can be enabled in .env file for testing purposes only. It will accept any username provided and generate valid token. When using the same username it is able to resume user session and ownership of software, projects and organisations.