I’m not that sure if this would totally erode the purpose of the CSRF protection (yet I do not claim to totally understand CSRF).
From CodeIgntiter’s CSRF Security manual, the whitelisting is at least specifically implemented for this job:
Select URIs can be whitelisted from csrf protection (for example API endpoints expecting externally POSTed content).
Right now the normal login page is generated with a valid CSRF token which is passed as _ip_csrf cookie to the IDP. The IDP takes it over, generates the SAML response and redirects to the newly defined API endpoint of InvoicePlane (sessions/samlauth). The cookies is still send over but not accepted by csrf, using the exclude_csrf_uri at least lets me directly sign in via SAML. Subsequent communication is reusing directly the csrf protection again.
I would anyways prefer also a better solution, keeping especially CSRF active during authentication. From the POST side the IDP implementation is fixed, so all I would do here for correct separation is modifying the IP plugin. And for the moment I would prefer to not implement a secret API key per user…
The SSO part of the plugin works flawlessly here and is merged to the master branch in case anybody would like to check it out - the plugin is developed for the current InvoicePlane git master branch, not the web zip package. Logout is untested and might not work, my IDP solution right now does not support logout requests. Still a lot to do in future.
There is still a question about licensing because of some lines of code. As soon as this is fixed I might consider making a pull request to InvoicePlane, at least I’m thinking that a SAML plugin might be useful. Surely the CSRF question should also be solved beforehand.