Reusable authentication

[XanderVertegaal]

(Discussed at the structuuroverleg of March 6th, 2024)

When we start to implement user authentication, we should set this op generically in such a way that we can use it in other, future cookiecutter-based applications.

We can take iAnalyzer as an example, where SAML is also implemented.

Berit indicated that she would be able help to extract the backend/Django part from iAnalyzer and turn it into a package.

[jgonggrijp]

If possible, please implement the frontend part in a separate package as well.

[lukavdplas]

I don't think lettercraft has any needs for SAML authentication (?), so I think our ambition here would be to to build a "basic" user system, which could be expanded with optional SAML integration in the future.

[lukavdplas]

To work this out a bit further: to build a basic user system with email verification in an application straight from our cookiecutter, I think it needs the following to be ready for use.

Implementation details are based on I-analyzer.

Backend:

• It's good practice to create a CustomUser model at the start of development. Make this the AUTH_USER_MODEL in settings.
• Add dj-rest-auth[with_social] to requirements
• Configure ACCOUNT_EMAIL_VERIFICATION = 'mandatory' and ACCOUNT_EMAIL_REQUIRED = True in settings.
• Endpoints for the following. Note that some of these come built-in with dj-rest-auth.
  • Register a new user
  • Log in
  • Log out
  • Request (your own) user details
  • E-mail verification link
  • Request a password reset email
  • Reset password (after following the above email)
  • Change password
  • Change e-mail and/or username
  • Delete user account

Frontend:

• A UserService that connects to the API. It should have a user$ observable to reflect the current user, and methods like login(), changePassword(), etc. for handling user-related actions.
• When not logged in: site navigation should show "Register" and "Sign in" links
• When logged in: site navigation should show "Sign out" and "Settings" links.
• The following components must be implemented:
  • Registration
  • Log in
  • Request a "reset password" email
  • Configure a new password after following the "reset password" email
  • User settings with options to change your e-mail, username, and password, and to delete your account.
  • Alert a user that their e-mail has not been verified
  • A page with a privacy statement that is configured in the environment
  • If included in the environment, a page with a terms of service statement
• Most of the components listed above would be separate pages, which must be included in the router