Add on error pipeline [GRA-791]

[john-sonz]

User description

This PR adds the on_error_pipeline option to the IDP config data.

• The pipeline enables custom handling of SAML errors
• on_error_pipeline is a plug pipeline and follows the same behaviour as pre_session_create_pipeline
• If on_error_pipeline is not provided, then the default Samly behaviour is not affected

---

Generated description

Below is a concise technical summary of the changes proposed in this PR:
Enhances SSO security and user experience by introducing a customizable error handling pipeline for SAML authentication failures. Updates the SpHandler to execute a plug-based on_error_pipeline, preventing the exposure of technical error details on a blank screen.

Topic	Details
Error Handling Flow	Modifies SpHandler to catch SAML errors, populate the Plug.Conn private storage with error details, and trigger the custom error pipeline if configured. Modified files (2) README.md lib/samly/sp_handler.ex Latest Contributors(0) User Commit Date
SSO Config Updates	Introduces the on_error_pipeline field to the IdpData struct and includes logic to load this configuration from the Identity Provider settings. Modified files (2) lib/samly/idp_data.ex test/samly_idp_data_test.exs Latest Contributors(0) User Commit Date

This pull request is reviewed by Baz. Review like a pro on (Baz).

[baz-reviewer]

Spec Reviewer Report    📬

Checkout in Baz

0 / 2 Requirements met for ticket:

Make SSO error messages secure & user friendly (Best Buy committment)

2 unmet requirement(s)

#	Requirement	Explanation
1	SSO access_denied errors must render the default dscout Oops template - Not Met	When no error pipeline halts the response, the handler still returns the raw access_denied payload instead of the Oops page, and Samly’s configuration leaves `on_error_pipeline` nil by default so no automatic Oops renderer runs. evidence `lib/samly/sp_handler.ex:84-93` still falls back to sending a raw 403 response containing the technical error (debug or plain text) when the error pipeline does not halt the connection. `lib/samly/idp_data.ex:13-21` keeps `on_error_pipeline` as nil by default, so the new hook is never invoked unless manually configured and there is no default Oops renderer wired in.
2	SSO error responses hide technical details - Not Met	Even though an error pipeline hook was added, any request that escapes or omits that pipeline still hits the fallback branch and emits the inspected `reason` (and raw SAML payload in debug mode), so the user-visible page keeps leaking the technical failure details. evidence lib/samly/sp_handler.ex:78-89 → after invoking the optional on_error_pipeline, the fallback branch still reaches a 403 response whose body prints the inspected `reason` and, in debug mode, the raw SAML response, exposing the exact error details.

---

Used resources:
Hash: 30db459 | Ticket: link

[rpylipow]

Changes look good. Could you please also document this new functionality in the README.md?

[john-sonz]

@rpylipow README.md updated ✅

[john-sonz]

@rpylipow How does the release process work for this library? Do we need to do anything else besides merging?

[rpylipow]

@john-sonz Our axon application runs again the main branch of this

{:samly, git: "https://github.com/dscout/samly.git"},

So my suggestion is waiting to merge this until after you tested the axon integration with it incase you need to make changes. You should be able to test locally/staging on axon using something like

# I forget the exact syntax. It might be branch, or commit sha 
{:samly, git: "https://github.com/dscout/samly.git", branch: "your-branch-name"},