plugin engine for issuers
Summary
Some of our users have extremely specific needs for their SAML/OIDC/CAS flows.
A few examples off the top of my head:
- Fine-grained control on the
audiencefield of OIDC tokens - Triggering reauthentication on every login for SAML service provider that does NOT set forceAuthn=true
- Fixing encoding of SAML attributes for one provider, but not the others
Usually we implement this by adding config options, but we cannot add a new option for every corner case that only one user in the entire world needs!
I think we could benefit from a plugin system in the issuers. Each issuer would call hooks at various points of processing, for example:
- When receiving the SAML Auth request, call a hook that lets the user modify the incoming Auth request
- When about to send the SAML login response, call a hook that lets the user modify the outgoing Auth response
- In /oauth2/userinfo route, call a hook that lets a user modify the userinfo response
etc.
Design proposition
The portal currently has one array for each entry point, that contains subroutines that call the appropriate function in each plugin that hooks this entrypoint. When loadPlugin is called, findEP dispatches the plugin's entrypoints in the right array.
I'm not sure how to extend this to issuers. Should issuer plugins be treated like normal plugins (in which case findEP has to be modified)? Or a special type of plugin that gets loaded by each issuer module?
@guimard I could use your advice with this