feat(sso): Add IdP encryption configuration step

[enmande]

🎟️ Tracking

PM-43087

📔 Objective

Adds documentation for local SimpleSaml assertion encryption configuration.

See also: server PR 8319. These should be merged simultaneously.

[cloudflare-workers-and-pages]

Deploying contributing-docs with    Cloudflare Pages

Latest commit:	27f2da1
Status:	✅  Deploy successful!
Preview URL:	https://b507d9bc.contributing-docs.pages.dev
Branch Preview URL:	https://auth-local-sso-saml-assertio.contributing-docs.pages.dev

View logs

[github-actions]

🤖 Bitwarden Claude Code Review

Overall Assessment: APPROVE

Documentation-only change adding a step to docs/getting-started/server/sso/index.md for copying saml20-sp-remote.php.example and enabling SimpleSAMLphp assertion encryption. Cross-checked against the companion server PR 8319: the example filename, copy target, bind-mount path, and .gitignore entry all match, and the certificate referenced in the example file (dev/identity_server_dev.crt) is the one produced by the existing certificate step. Step renumbering (9 → 11) is internally consistent, and no other page cross-references the renumbered steps. Prose wrapping and list indentation match the repository's Prettier settings, and the new prose introduces no words missing from custom-words.txt.

No findings.

[eliykat]

I suggest this is marked as optional, as you don't need it unless you want to test assertion encryption specifically.

EDIT: that might need the server PR to be updated so that Aspire doesn't try to bind a non-existent file though... let me know if you disagree.

[enmande]

@eliykat I agree. I would prefer it to be optional. I've wrestled a bit with how to handle this while accommodating both Aspire and Docker Compose, as their capabilities are somewhat different.

It should not be necessary to configure assertion behavior outside of testing these scenarios, as you point out. But we would like to offer that capability in a consistent way.

Aspire is the easier to accommodate by skipping the file bind if it does not exist, or by automating a copy if it does not exist in C#. Docker Compose is less flexible. It requires a file's unconditional existence to add it to bind volumes, else it makes a directory behind the scenes which could be problematic to debug later. For Compose binding support, the PHP file must exist, or we accept the directory-creating default behavior.

I have an idea to add an entrypoint in the idp image definition for Docker Compose. It would script a copy of the *.example to an un-configured *.php file if it does not exist, and then bind it to the container's metadata volume. It would be silent for developers, but would force the existence of the (un-tracked) *.php file. If configuration is desired, the un-tracked, auto-generated PHP file could then be edited in place. If we do this, I think Aspire behavior should be the same: use C# to check/copy the file for the bind volume.

What do you think about such a solution? It works nicely in local testing, but is a necessary deviation from, e.g., how we handle authsources.php, as it is required in all scenarios to use idp.

[eliykat]

I see, that's a bit tricky. Your suggestion is reasonable but I might be sending you down a rabbit hole to support different configuration options across our (unfortunately) multiple competing dev setup environments. It's your call, but I'm also OK with just making it mandatory so everyone has a consistent setup (and we don't have to go editing docker compose definitions here :)