Add OpenIDC auth support

[mikkonie]

We need to add OpenIDC auth support for SODAR et al. The Django part will obviously go here.

I've done some research and the most promising package to use for OpenIDC with Django seems to be social-app-django, which is a plugin for python-social-auth. As a downside, it contains a lot of social media auth integrations we certainly don't need, but I'd figure they can be ignored.

Other options would include mozilla-django-oidc, django-oidc-provider and django-allauth, but python-social-auth seems to be well documented, widely used and often recommended. Starting with that one then.

I'm a total noob when it comes to OpenID and OpenIDC, so this will most likely be a trial-and-error experience.

Resources

• Installation doc
• General configuration
• Documentation for social-app-django configuration
• OIDC backend code
• Dedicated Elixir backend
  • Just extends OpenIdConnectAuth with specific endpoint URL and extras
  • Refers to old "Elixir" name and URLs, should probably be upgraded to LS AAI
  • We should just use the generic OpenIDC backend, unless some specific reason prevents us from doing so
• LS AAI documentation
  • Relevant to our use case in SODAR, but no LS AAI specific stuff should go under this repo
• LS AAI endpoint URL: https://login.aai.lifescience-ri.eu/oidc
  • This was surprisingly hard to find :)

Spec

• Set up auth dependency
• Set up necessary backends and Django settings
• Add auth element in login view
  • This should be made customizable depending on the provider
• Come up with way to try out OIDC loging in dev
  • LS AAI requires registering with an existing site before any testing can be performed
  • Keycloak works, using that
• Implement proper mapping of OpenIDC users to Django user objects
  • social_django mostly does this, rest can be handled via signals
  • Username is configurable with SOCIAL_AUTH_OIDC_USERNAME_KEY
• Update user type handling
  • Differentiate between local, ldap and oidc using user groups
  • Update model API accordingly
  • Update usage in code (where we now only differentiate between local and ldap)
• Update invite handling (see comments)
• Update remote sync
  • Need to pass user groups in user sync
  • TODO: Need to test if a "local" user can be "updated" by social_django into an OIDC user on the fly or if there'll be a conflict
    • Confirmed to work without issues
• Register client with LS AAI
  • Can be done later in SODAR
• Test
• Document

Tasks

• [x] Set up auth backend
• [x] Add customizable login element
• [x] Set up OIDC dev environment
• [x] Update user auth type and group handling
• [x] Update invite handling
• [x] Update user remote sync
• [x] Add/update tests
• [x] Document

[mikkonie]

The first issue encountered: the install docs tell us the following..

To enable any of the extras options to bring the dependencies for OpenIDConnect: pip install "social-auth-core[openidconnect]"

However, attempting to do this results in:

WARNING: social-auth-core 4.5.3 does not provide the extra 'openidconnect'

Furthermore, attempting to install [all] fails with:

ERROR: Could not build wheels for xmlsec, which is required to install pyproject.toml-based projects

The docs also state: "OpenIDConnect support requires the use of the openidconnect extra."

UPDATE: I opened a ticket in social-auth-core, let's see if someone has an idea. Could be just the matter of outdated documentation, or a stupid user error..

Also, I noticed there is discussion about stagnated development in the repos. Perhaps this is not the optimal 3rd party library after all.

UPDATE 2: I received confirmation that installing the extras is no longer needed in the current version. This is a case of outdated documentation. I'll proceed forward after Easter..

[mikkonie]

Note to self, the following migrations are added for social_django:

  Applying social_django.0001_initial... OK
  Applying social_django.0002_add_related_name... OK
  Applying social_django.0003_alter_email_max_length... OK
  Applying social_django.0004_auto_20160423_0400... OK
  Applying social_django.0005_auto_20160727_2333... OK
  Applying social_django.0006_partial... OK
  Applying social_django.0007_code_timestamp... OK
  Applying social_django.0008_partial_timestamp... OK
  Applying social_django.0009_auto_20191118_0520... OK
  Applying social_django.0010_uid_db_index... OK
  Applying social_django.0011_alter_id_fields... OK
  Applying social_django.0012_usersocialauth_extra_data_new... OK
  Applying social_django.0013_migrate_extra_data... OK
  Applying social_django.0014_remove_usersocialauth_extra_data... OK
  Applying social_django.0015_rename_extra_data_new_usersocialauth_extra_data... OK

[mikkonie]

The issue with invites is that they are solely based on the email address. If the site allows for both local users and OIDC auth, the code cannot know from the email address alone whether the invite is intended for a local user or a OIDC single sign-on user.

Also, for local users we provide a user form to choose their username, password etc. For OIDC users we naturally don't want this, as user details are determined by the identity provider on login.

Invite processing is handled in two views, ProjectInviteProcessLDAPView for LDAP users and ProjectInviteProcessLocalView for local ones.

The easiest way to add handling for OIDC users is to modify ProjectInviteProcessLocalView as follows:

• IF both local users and OIDC auth are enabled
  • Display user form, add link to OIDC login on top of it
  • If user logs in via OIDC, redirect to either of the process views to create assignment, then forward to project detail view
• ELSE IF only OIDC is enabled
  • Redirect straight to logged-in assignment creation view (similar to what is done with LDAP now)

Note: This whole two-view-thing is very convoluted to begin with, but I probably don't want to refactor the whole thing right now. Probably..

If needed, in the future we could e.g. add a field for invites to set whether they are intended for OIDC or local users.

[mikkonie]

Done.