saml idp support (db-backed service providers)

[jaspermayone]

Why

Hack Club-scale means enterprise SPs (Slack Enterprise Grid, Airtable, HR tools) eventually want SAML. Backlog until a real SP shows up — but designed right when it does.

What (design constraints, learned from hackclub/auth's implementation)

• DB-backed SP registry — their config/saml.yml approach requires a redeploy per SP; ours should be admin-manageable. Per-SP: entity_id, ACS URL/binding, requested attributes, attribute filter, email allow-list, signing cert, idp-initiated toggle.
• Use a maintained signing path — they hand-rolled XML-DSig (enveloped, exclusive C14N, RSA-SHA256) over Nokogiri to control canonicalization; that is a maintenance risk we should not inherit. Prefer the saml2 gem's (or ruby-saml's) signing, and only drop lower if interop forces it.
• Keep their security controls: AuthnRequest signature verification, replay cache on request IDs (checked after auth so it survives the login redirect), Destination/IssueInstant validation, HTTPS-only ACS in prod, per-SP attribute filtering, persistent NameID derived from public id.
• Feature-flag the whole surface (Flipper) as they do.

Reference

• https://github.com/hackclub/auth/blob/main/app/controllers/saml_controller.rb
• https://github.com/hackclub/auth/tree/main/app/services/saml_service