org-oidc auth plugin employee login

[robinmolen]

Closes #4863

Changes

This should solve the problem of employee login on forms with the org-oidc auth plugin.

Currently this is a WIP. I'm not sure if this is the right approach, and solves the right issue (this might be a very superficial solution, but im not sure). This currently contains:

• Test that showcases the failing scenario
• Solution for employee_id authentication
  (Which is highly experimental, and probably should/will change)

This that still should be done:

• Add employee id to user
• Use employee_id as identifier for employee case in to_auth_context_data
  (I think this requires passing employee id from the org-oidc plugin handle_return())

Checklist

Check off the items that are completed or not relevant.

• Impact on features

  • Checked copying a form
  • Checked import/export of a form
  • Config checks in the configuration overview admin page
  • Problem detection in the admin email digest is handled

• Release management

  • I have labelled the PR as "needs-backport" accordingly

• I have updated the translations assets (you do NOT need to provide translations)

  • Ran ./bin/makemessages_js.sh
  • Ran ./bin/compilemessages_js.sh

• Dockerfile/scripts

  • Updated the Dockerfile with the necessary scripts from the ./bin folder

• Commit hygiene

  • Commit messages refer to the relevant Github issue
  • Commit messages explain the "why" of change, not the how

[sergei-maertens]

Some background to explain more about how things work in Open Forms!

The model AuthInfo (which defines the to_auth_context_data method) captures who is authenticated for the submission. This means that if an employee of the organization (after OIDC login) logs in for the form for themselves (the other flow I will describe below), they are the authorizee.legalSubject (representing themselves). This is a rather simple setup of employee context that needs to be returned if we follow the established pattern (where representee is implied from the authorizee/legal subject).

{
  "source": "custom",
  "loa": "unknown",
  "authorizee": {
    "legalSubject": {
      "identifierType": "opaque",
      "identifier": self.value
    }
  }
}

Identifier type opaque means you can't derive any meaning/format validation from it.

The other flow is where an employee is logged in with OIDC, and they enter the BSN or KVK of the customer. In the code, this brings you to openforms.authentication.signals.set_auth_attribute_on_session in the branch with if registrator_subject. In that situation, on the AuthInfo instance not the employee details are stored, but the BSN/KVK nr of the actual customer, and the attribute is then set to bsn or kvk rather than employee_id, so you can never end up in this case in those flows. Meaning, the to_auth_context_data only needs to consider the situation where an employee is acting on their own behalf which is nice because it simplifies things a bit.

Looking at the Sentry error, this is the right place to patch this up.

So, key takeaways:

• the context dict/shape here needs to use authorizee > legalSubject structure, similar to DigiD without machtigen (first case)
• we don't need to consider "acting on behalf of someone else" for employee_id attribute

[robinmolen]

Okay.. I think i'm starting to understand this a bit more..

Should the context then not also contain the representee data? (Although this would probably be the same information.., right?)

[sergei-maertens]

if no representee is specified, it is indeed (implicitly) equal to authorizee.legalSubject. Therefore, this information is not duplicated.

[sergei-maertens]

I'd use either opaque or custom here. I gravitate towards the former because it's already used for the eHerkenning acting subject too

[robinmolen]

Check, yeah i'll use opaque then it that case, to keep things consistent 👍

[sergei-maertens]

this isn't necessary, since you can populate the user model field from already existing claims, see the documentation: https://open-forms.readthedocs.io/en/stable/configuration/authentication/oidc_org.html#configuring-oidc-for-login-of-organization-members

In these cases I would probably just map the sub or username or email claim to the employee_id field.

[robinmolen]

But isn't this needed for the login itself?

[sergei-maertens]

you can use the admin/admin user for that :)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.62%. Comparing base (e11c687) to head (147b2cf).
Report is 6 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #4947   +/-   ##
=======================================
  Coverage   96.61%   96.62%           
=======================================
  Files         760      760           
  Lines       25825    25837   +12     
  Branches     3384     3385    +1     
=======================================
+ Hits        24952    24964   +12     
  Misses        608      608           
  Partials      265      265           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[sergei-maertens]

Backports:

• 2.8.x: d428e39
• 2.7.x: a6568b9