OIDC en eIDAS ondersteuning uitbreiden

[joeribekker]

This epic will cover making OIDC more generic - in order to support Yivi, among others. It will also cover retrieving attributes from eIDAS, which will include SAML-support for eIDAS.

This is partially covered in a library: maykinmedia/mozilla-django-oidc-db#97

Once all sub issues are completed, explore a truly generic plugin/implementation.

[sergei-maertens]

Meeting notes from today + Silvia's notes

Library rework

@SilviaAmAm will work on the mozilla-django-oidc-db rework, including processing the changes in the downstream django-digid-eherkenning library and OIP project. A rough estimate for needed time is 4 weeks.

Open Forms changes

@robinmolen will (in parallel) start working on the changes needed in Open Forms.

• Update/rework the architecture a bit of the authentication module. In particular, we need to be able to receive form/plugin-specific options in the start_login and handle_return hooks of the BasePlugin. The DigiD plugin currently uses the check_requirements hook for this, this could/should be adopted.
• Extend the openforms.authentication models so that we can capture arbitrary key/value pairs from the obtained OIDC claims (e.g. first/last name, date of birth, ...). This includes being able to configure claim mappings on a per-form level for the OIDC-based plugins (eIDAS, Yivi)
• Add plugins for eidas-oidc and yivi-oidc - making it possible to authenticate with these plugins and the captured attributes/claims need to be stored in the new model from the previous step
• Support prefill - components/form variables need to be able to be prefilled from the obtained eIDAS/Yivi claims, the mechanism here will be the same as the product prefill (objects API) prefill.

Total estimate was put at 7 weeks for this.

[WietekeNijmegen]

@sergei-maertens @SilviaAmAm @robinmolen

First of all, thank you for the Epic and issues.
Great to see the global claims mapping on a form basis when needed.

We are wondering if this is abstract enough. You are a better judge of the possibilities.

Why yivi and eidas plugins and not a generic oidc plugin?
If at all possible we would like to add the NL Wallet and other OIDC connections in the future without having to build another plugin.

Our goal is to be ready for future developments, being able to quickly add new OIDC authentication configs with:

• a login option for the oidc config on the form's start page
• claims mapping to prefill
• specific claims mapping for each form if needed

Yivi (conditional) and Eidas are some use cases. Some of the most complex use cases, but to us they are just that: use cases for a generic OIDC flow. Our goal right now is Yivi on the short term, but flexibility of adding new ID-wallets and other OIDC connections quickly and easily is our long term goal.

[joeribekker]

From what I understand, we will focus on making OIDC (more) generic but, usually, just making things more generic is not a proper businesscase. So, it was described as: To enable Yivi support, we need to make OIDC more generic (instead of the other way around). There will be some eIDAS and/or wallet specific properties or "type" setting, to give Open Forms an indication what it can expect from OIDC. But I'll let the devs comment further :)

[sergei-maertens]

To add to this, it's important for development to keep things tangible and avoid exposing all kinds of internal implementation details to the outside world, because that seriously limits what future changes we can make while staying backwards compatible. We generally follow the rule of three in these kind of situations - once a third variant shows up, we can identify the common/generic patterns and refactor based on that to figure out how to properly make it generic.

On top of that, whenever we claim that we support X or Y, this is backed by automated tests showcasing this particular case. It's hard to write tests proving that something works with Yivi/eIDAS/NL Wallet without actually implementing/talking to the real services, and we're a fan of hard guarantees.

The technical foundation will be so that it becomes very simple to add support for other plugins, be it through point-and-click configuration or through minimal code additions, and the latter can take the form of a core plugin or a plugin provided via a custom extension that interested parties can develop and maintain themselves.

[WietekeNijmegen]

@sergei-maertens

We generally follow the rule of three in these kind of situations - once a third variant shows up, we can identify the common/generic patterns and refactor based on that to figure out how to properly make it generic.

I agree with your argumentation that a pattern is required.
I would argue that the pattern is OIDC and it has an unlimited amount of variations.

The specific open forms limitation here when it comes to variety is:

• A representation in the front-end to authenticate (A button like DigiD)
• Mapping of claims to a form for prefill purposes

However, this already has more than three varieties as well, because DigiD and Eherkenning already function in this way as well.

• Front end button on startpage as an auth option
• Option in a form to enable the auth option
• Basic settings of OIDC like endpoints, client id, secret, scopes, etc...
• Mapping of claims to form fields (and additionaly sometimes extra api calls that fill form fields, but this can be done outside the OIDC scope)

We are asking the option to override specific claim to form field mapping for each form, which indeed is different and novel in that regard.

However, when it comes to the OIDC auth settings, I would argue it already is generic and has many variations.
Digid OIDC is one of the implementations in such a case, which would give one of the cases to be tested.

How this is added is indeed up to you, because it is application specific and needs to account for more application specific context. An easy plugin might be an option, but we would love to know what the requisites for those plugins would be.

The new European Eidas 2.0 Regulation will require flexibility and agility from municipalities. We will have to add different options for citizens to identify themselves with different wallets and other means: https://www.european-digital-identity-regulation.com/ Which is why we want to be ready to comply. Yivi is just one of many authentication/id options.

[sergei-maertens]

I understand and we will take it into account at the end of the described steps. I'm estimating another few weeks to handle this as we cannot blindly replace the existing OIDC based plugins - that would break existing forms that use them and would break exports of forms, so we need a migration/conversion for those.

Implementation-wise I'm still convinced that implementing specific plugins and then generalizing it is essential to keep it manageable for the development team and have checkpoints in the process to track how things are going rather than ending up in a big bang all or nothing situation.

[WietekeNijmegen]

Implementation-wise I'm still convinced that implementing specific plugins and then generalizing it is essential to keep it manageable

Valid argument to keep configuration manageble. I suppose what we really want to know is what that looks like on our end when we want to implement.
Once again, you have a complete overview of the software, I a merely looking at what the results will be and how we can work with them.
If easier OIDC auth plugins with claims mapping means we will have issues implementing new options, that would be an issue. If it is easy to add new plugins and the hours involved from your side can be limited when we want to use a new variety, I am definitely open to the concept.
Hence my emphasis on the option to have flexibility in the changing auth landscape for governments due to the Eidas 2.0 regulation.